Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1366266 > unrolled thread

[RFC PATCH 0/3] ahci: add ports-implemented dt bindings.

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH 0/3] ahci: add ports-implemented dt bindings. Srinivas Kandagatla <srinivas.kandagatla@linaro.org> - 2016-03-29 15:20 +0200
    [RFC PATCH 1/3] libahci: save port map for forced port map Srinivas Kandagatla <srinivas.kandagatla@linaro.org> - 2016-03-29 15:20 +0200
      Re: [RFC PATCH 1/3] libahci: save port map for forced port map Tejun Heo <tj@kernel.org> - 2016-03-30 21:00 +0200
        Re: [RFC PATCH 1/3] libahci: save port map for forced port map Srinivas Kandagatla <srinivas.kandagatla@linaro.org> - 2016-03-31 18:00 +0200
          Re: [RFC PATCH 1/3] libahci: save port map for forced port map Tejun Heo <tj@kernel.org> - 2016-03-31 18:50 +0200
            Re: [RFC PATCH 1/3] libahci: save port map for forced port map Srinivas Kandagatla <srinivas.kandagatla@linaro.org> - 2016-03-31 19:00 +0200
    [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt bindings. Srinivas Kandagatla <srinivas.kandagatla@linaro.org> - 2016-03-29 15:20 +0200
      Re: [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt bindings. Rob Herring <robh+dt@kernel.org> - 2016-03-29 16:20 +0200
        Re: [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt  bindings. Srinivas Kandagatla <srinivas.kandagatla@linaro.org> - 2016-03-29 16:50 +0200
          Re: [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt bindings. Rob Herring <robh+dt@kernel.org> - 2016-03-29 19:10 +0200
            Re: [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt  bindings. Srinivas Kandagatla <srinivas.kandagatla@linaro.org> - 2016-03-29 19:20 +0200

#1366266 — [RFC PATCH 0/3] ahci: add ports-implemented dt bindings.

Hi Tejun,

On some SOCs PORTS_IMPL register value is never programmed by the BIOS
and left at zero value. Which means that no sata ports are available for
software. AHCI driver used to cope up with this by fabricating the
port_map if the PORTS_IMPL register is read zero, but recent patch [1]
broke this workaround as zero value was valid for nvme disks.

This patch adds ports-implemented dt bindings as workaround for this issue
in a way that DT can dictate the port_map incase where the SOCs does not
program it already.

Am sure that there are more than one SOC that hits this issue.

Without this patchset, ACHI on APQ8064 Qualcomm platform is broken in mainline.
With the below patchset am able to get back the functionality.

Thanks,
srini
[1] 566d18 "libata: disable forced PORTS_IMPL for >= AHCI 1.3"

Srinivas Kandagatla (3):
  libahci: save port map for forced port map
  ata: ahci-platform: Add ports-implemented dt bindings.
  ARM: dts: apq8064: add ahci ports-implemented mask

 Documentation/devicetree/bindings/ata/ahci-platform.txt | 11 +++++++++++
 arch/arm/boot/dts/qcom-apq8064.dtsi                     |  1 +
 drivers/ata/ahci_platform.c                             |  4 ++++
 drivers/ata/libahci.c                                   |  1 +
 4 files changed, 17 insertions(+)

-- 
2.5.0

[toc] | [next] | [standalone]

#1366268 — [RFC PATCH 1/3] libahci: save port map for forced port map

In usecases where force_port_map is used saved_port_map is never set,
resulting in not programming the PORTS_IMPL register as part of intial
config. This patch fixes this by setting it to port_map even in case
where force_port_map is used, making it more inline with other parts of
the code.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 drivers/ata/libahci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 3982054..a5d7c1c 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -507,6 +507,7 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
 		dev_info(dev, "forcing port_map 0x%x -> 0x%x\n",
 			 port_map, hpriv->force_port_map);
 		port_map = hpriv->force_port_map;
+		hpriv->saved_port_map = port_map;
 	}
 
 	if (hpriv->mask_port_map) {
-- 
2.5.0

[toc] | [prev] | [next] | [standalone]

#1367521 — Re: [RFC PATCH 1/3] libahci: save port map for forced port map

Hello,

On Tue, Mar 29, 2016 at 02:11:13PM +0100, Srinivas Kandagatla wrote:
> In usecases where force_port_map is used saved_port_map is never set,
> resulting in not programming the PORTS_IMPL register as part of intial
> config. This patch fixes this by setting it to port_map even in case
> where force_port_map is used, making it more inline with other parts of
> the code.
> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
>  drivers/ata/libahci.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> index 3982054..a5d7c1c 100644
> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
> @@ -507,6 +507,7 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
>  		dev_info(dev, "forcing port_map 0x%x -> 0x%x\n",
>  			 port_map, hpriv->force_port_map);
>  		port_map = hpriv->force_port_map;
> +		hpriv->saved_port_map = port_map;

So, the only change it'd cause is making the driver write the forced
value to the PI register.  Does that make sense?

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1368415 — Re: [RFC PATCH 1/3] libahci: save port map for forced port map

On 30/03/16 19:57, Tejun Heo wrote:
> Hello,
>
> On Tue, Mar 29, 2016 at 02:11:13PM +0100, Srinivas Kandagatla wrote:
>> In usecases where force_port_map is used saved_port_map is never set,
>> resulting in not programming the PORTS_IMPL register as part of intial
>> config. This patch fixes this by setting it to port_map even in case
>> where force_port_map is used, making it more inline with other parts of
>> the code.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>>   drivers/ata/libahci.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
>> index 3982054..a5d7c1c 100644
>> --- a/drivers/ata/libahci.c
>> +++ b/drivers/ata/libahci.c
>> @@ -507,6 +507,7 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
>>   		dev_info(dev, "forcing port_map 0x%x -> 0x%x\n",
>>   			 port_map, hpriv->force_port_map);
>>   		port_map = hpriv->force_port_map;
>> +		hpriv->saved_port_map = port_map;
>
> So, the only change it'd cause is making the driver write the forced
> value to the PI register.  Does that make sense?

Yes, that is the intention, I guess, This was done exactly in case where 
the port number was fabricated too.

Without this I could not get the sata working on my board with forced 
port map option.

--srini


>
> Thanks.
>

[toc] | [prev] | [next] | [standalone]

#1368442 — Re: [RFC PATCH 1/3] libahci: save port map for forced port map

Hello,

On Thu, Mar 31, 2016 at 04:58:27PM +0100, Srinivas Kandagatla wrote:
> Yes, that is the intention, I guess, This was done exactly in case where the
> port number was fabricated too.
> 
> Without this I could not get the sata working on my board with forced port
> map option.

I see.  Looks good to me then.  Can you please respin the patches with
the updates for the review points in the second patch?  I'll apply
them to libata/for-3.6-fixes.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1368451 — Re: [RFC PATCH 1/3] libahci: save port map for forced port map

On 31/03/16 17:43, Tejun Heo wrote:
> Hello,
>
> On Thu, Mar 31, 2016 at 04:58:27PM +0100, Srinivas Kandagatla wrote:
>> Yes, that is the intention, I guess, This was done exactly in case where the
>> port number was fabricated too.
>>
>> Without this I could not get the sata working on my board with forced port
>> map option.
>
> I see.  Looks good to me then.  Can you please respin the patches with
> the updates for the review points in the second patch?  I'll apply
> them to libata/for-3.6-fixes.

Thanks, I will do it now.

--srini
>
> Thanks.
>

[toc] | [prev] | [next] | [standalone]

#1366277 — [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt bindings.

On some SOCs PORTS_IMPL register value is never programmed by the BIOS
and left at zero value. Which means that no sata ports are avaiable for
software. AHCI driver used to cope up with this by fabricating the
port_map if the PORTS_IMPL register is read zero, but recent patch
broke this workaround as zero value was valid for nvme disks.

This patch adds ports-implemented dt bindings as workaround for this issue
in a way that DT can dictate the port_map incase where the SOCs does not
program it already.

Fixes: 566d1827df2e ("libata: disable forced PORTS_IMPL for >= AHCI 1.3)
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 Documentation/devicetree/bindings/ata/ahci-platform.txt | 11 +++++++++++
 drivers/ata/ahci_platform.c                             |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index 30df832..8165db3 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -32,6 +32,10 @@ Optional properties:
 - target-supply     : regulator for SATA target power
 - phys              : reference to the SATA PHY node
 - phy-names         : must be "sata-phy"
+- ports-implemented : Mask that indicates which ports that the HBA supports
+		      are available for software to use. Useful if PORTS_IMPL
+		      is not programmed by the BIOS, which is true with
+		      some embedded SOC's.
 
 Required properties when using sub-nodes:
 - #address-cells    : number of cells to encode an address
@@ -59,6 +63,13 @@ Examples:
 		target-supply = <&reg_ahci_5v>;
 	};
 
+	sata0: sata@29000000 { /* Qualcomm APQ8064 */
+		compatible = "generic-ahci";
+		reg = <0x29000000 0x180>;
+		interrupts = <GIC_SPI 209 IRQ_TYPE_NONE>;
+		ports-implemented = <0x1>;
+	};
+
 With sub-nodes:
 	sata@f7e90000 {
 		compatible = "marvell,berlin2q-achi", "generic-ahci";
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 4044233..ec8db80 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -42,6 +42,7 @@ static int ahci_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct ahci_host_priv *hpriv;
 	int rc;
+	u32 ports_impl;
 
 	hpriv = ahci_platform_get_resources(pdev);
 	if (IS_ERR(hpriv))
@@ -51,6 +52,9 @@ static int ahci_probe(struct platform_device *pdev)
 	if (rc)
 		return rc;
 
+	of_property_read_u32(dev->of_node,
+			     "ports-implemented", &hpriv->force_port_map);
+
 	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
 		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
 
-- 
2.5.0

[toc] | [prev] | [next] | [standalone]

#1366322 — Re: [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt bindings.

On Tue, Mar 29, 2016 at 8:11 AM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> On some SOCs PORTS_IMPL register value is never programmed by the BIOS

s/BIOS/firmware/

You do plan to fix this in your firmware/bootloader, too, right?

> and left at zero value. Which means that no sata ports are avaiable for
> software. AHCI driver used to cope up with this by fabricating the
> port_map if the PORTS_IMPL register is read zero, but recent patch
> broke this workaround as zero value was valid for nvme disks.

s/nvme/NVMe/

>
> This patch adds ports-implemented dt bindings as workaround for this issue

s/dt/DT/

> in a way that DT can dictate the port_map incase where the SOCs does not
> program it already.

port_map is a Linux term.

...can override the PORTS_IMPL register in cases where the firmware
did not program it already.

>
> Fixes: 566d1827df2e ("libata: disable forced PORTS_IMPL for >= AHCI 1.3)
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
>  Documentation/devicetree/bindings/ata/ahci-platform.txt | 11 +++++++++++
>  drivers/ata/ahci_platform.c                             |  4 ++++
>  2 files changed, 15 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
> index 30df832..8165db3 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
> +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
> @@ -32,6 +32,10 @@ Optional properties:
>  - target-supply     : regulator for SATA target power
>  - phys              : reference to the SATA PHY node
>  - phy-names         : must be "sata-phy"
> +- ports-implemented : Mask that indicates which ports that the HBA supports
> +                     are available for software to use. Useful if PORTS_IMPL
> +                     is not programmed by the BIOS, which is true with
> +                     some embedded SOC's.
>
>  Required properties when using sub-nodes:
>  - #address-cells    : number of cells to encode an address
> @@ -59,6 +63,13 @@ Examples:
>                 target-supply = <&reg_ahci_5v>;
>         };
>
> +       sata0: sata@29000000 { /* Qualcomm APQ8064 */

Do you really need another example just for this?

> +               compatible = "generic-ahci";

Where's your chip specific compatible string? You would not require a
DT update to fix this if you had that.

> +               reg = <0x29000000 0x180>;
> +               interrupts = <GIC_SPI 209 IRQ_TYPE_NONE>;
> +               ports-implemented = <0x1>;
> +       };
> +
>  With sub-nodes:
>         sata@f7e90000 {
>                 compatible = "marvell,berlin2q-achi", "generic-ahci";
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 4044233..ec8db80 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -42,6 +42,7 @@ static int ahci_probe(struct platform_device *pdev)
>         struct device *dev = &pdev->dev;
>         struct ahci_host_priv *hpriv;
>         int rc;
> +       u32 ports_impl;
>
>         hpriv = ahci_platform_get_resources(pdev);
>         if (IS_ERR(hpriv))
> @@ -51,6 +52,9 @@ static int ahci_probe(struct platform_device *pdev)
>         if (rc)
>                 return rc;
>
> +       of_property_read_u32(dev->of_node,
> +                            "ports-implemented", &hpriv->force_port_map);
> +
>         if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
>                 hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>
> --
> 2.5.0
>

[toc] | [prev] | [next] | [standalone]

#1366352 — Re: [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt bindings.

On 29/03/16 15:11, Rob Herring wrote:
> On Tue, Mar 29, 2016 at 8:11 AM, Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
>> On some SOCs PORTS_IMPL register value is never programmed by the BIOS
>
> s/BIOS/firmware/
BIOS is the word used in the AHCI SPECS so want to stick to this.
>
> You do plan to fix this in your firmware/bootloader, too, right?

No. This feature was working just before v4.5, we have no plans to fix 
this in firmware as of today.
>
>> and left at zero value. Which means that no sata ports are avaiable for
>> software. AHCI driver used to cope up with this by fabricating the
>> port_map if the PORTS_IMPL register is read zero, but recent patch
>> broke this workaround as zero value was valid for nvme disks.
>
> s/nvme/NVMe/

Yep, will fix it.
>
>>
>> This patch adds ports-implemented dt bindings as workaround for this issue
>
> s/dt/DT/
Ok, will fix it.

>
>> in a way that DT can dictate the port_map incase where the SOCs does not
>> program it already.
>
> port_map is a Linux term.
Yes, I can rephrase it to ports implemented.
>
> ...can override the PORTS_IMPL register in cases where the firmware
> did not program it already.
>
>>
>> Fixes: 566d1827df2e ("libata: disable forced PORTS_IMPL for >= AHCI 1.3)
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>>   Documentation/devicetree/bindings/ata/ahci-platform.txt | 11 +++++++++++
>>   drivers/ata/ahci_platform.c                             |  4 ++++
>>   2 files changed, 15 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
>> index 30df832..8165db3 100644
>> --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
>> +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
>> @@ -32,6 +32,10 @@ Optional properties:
>>   - target-supply     : regulator for SATA target power
>>   - phys              : reference to the SATA PHY node
>>   - phy-names         : must be "sata-phy"
>> +- ports-implemented : Mask that indicates which ports that the HBA supports
>> +                     are available for software to use. Useful if PORTS_IMPL
>> +                     is not programmed by the BIOS, which is true with
>> +                     some embedded SOC's.
>>
>>   Required properties when using sub-nodes:
>>   - #address-cells    : number of cells to encode an address
>> @@ -59,6 +63,13 @@ Examples:
>>                  target-supply = <&reg_ahci_5v>;
>>          };
>>
>> +       sata0: sata@29000000 { /* Qualcomm APQ8064 */
>
> Do you really need another example just for this?
>
>> +               compatible = "generic-ahci";
>
> Where's your chip specific compatible string? You would not require a
> DT update to fix this if you had that.

Possibly, But we really are not doing anything specific in the ahci 
driver which is not generic, that might be the reason why we skipped 
this in the first place.

I agree we could solve this issue in more than one way, The only 
advantage of this new bindings would be to other platforms benefiting 
from this workaround would not have to keep adding a new compatible 
string into the ahci-platform driver.

Like Annapurna Alpine platform seems to have the same issue.

Am ok to do it either way.


thanks,
srini

>
>> +               reg = <0x29000000 0x180>;
>> +               interrupts = <GIC_SPI 209 IRQ_TYPE_NONE>;
>> +               ports-implemented = <0x1>;
>> +       };
>> +
>>   With sub-nodes:
>>          sata@f7e90000 {
>>                  compatible = "marvell,berlin2q-achi", "generic-ahci";
>> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
>> index 4044233..ec8db80 100644
>> --- a/drivers/ata/ahci_platform.c
>> +++ b/drivers/ata/ahci_platform.c
>> @@ -42,6 +42,7 @@ static int ahci_probe(struct platform_device *pdev)
>>          struct device *dev = &pdev->dev;
>>          struct ahci_host_priv *hpriv;
>>          int rc;
>> +       u32 ports_impl;
>>
>>          hpriv = ahci_platform_get_resources(pdev);
>>          if (IS_ERR(hpriv))
>> @@ -51,6 +52,9 @@ static int ahci_probe(struct platform_device *pdev)
>>          if (rc)
>>                  return rc;
>>
>> +       of_property_read_u32(dev->of_node,
>> +                            "ports-implemented", &hpriv->force_port_map);
>> +
>>          if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
>>                  hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>>
>> --
>> 2.5.0
>>

[toc] | [prev] | [next] | [standalone]

#1366484 — Re: [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt bindings.

On Tue, Mar 29, 2016 at 9:43 AM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>
>
> On 29/03/16 15:11, Rob Herring wrote:
>>
>> On Tue, Mar 29, 2016 at 8:11 AM, Srinivas Kandagatla
>> <srinivas.kandagatla@linaro.org> wrote:
>>>
>>> On some SOCs PORTS_IMPL register value is never programmed by the BIOS
>>
>>
>> s/BIOS/firmware/
>
> BIOS is the word used in the AHCI SPECS so want to stick to this.

The spec being Intel's also says it is a PCI device... BIOS is a type
of firmware.

[...]

>>> +       sata0: sata@29000000 { /* Qualcomm APQ8064 */
>>
>>
>> Do you really need another example just for this?
>>
>>> +               compatible = "generic-ahci";
>>
>>
>> Where's your chip specific compatible string? You would not require a
>> DT update to fix this if you had that.
>
>
> Possibly, But we really are not doing anything specific in the ahci driver
> which is not generic, that might be the reason why we skipped this in the
> first place.
>
> I agree we could solve this issue in more than one way, The only advantage
> of this new bindings would be to other platforms benefiting from this
> workaround would not have to keep adding a new compatible string into the
> ahci-platform driver.
>
> Like Annapurna Alpine platform seems to have the same issue.
>
> Am ok to do it either way.

I'm saying do both. Adding ports-implemented is fine, but add an SoC
compatible string (in the dts, not the driver).

Rob

[toc] | [prev] | [next] | [standalone]

#1366489 — Re: [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt bindings.

On 29/03/16 18:07, Rob Herring wrote:
> On Tue, Mar 29, 2016 at 9:43 AM, Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
>>
>>
>> On 29/03/16 15:11, Rob Herring wrote:
>>>
>>> On Tue, Mar 29, 2016 at 8:11 AM, Srinivas Kandagatla
>>> <srinivas.kandagatla@linaro.org> wrote:
>>>>
>>>> On some SOCs PORTS_IMPL register value is never programmed by the BIOS
>>>
>>>
>>> s/BIOS/firmware/
>>
>> BIOS is the word used in the AHCI SPECS so want to stick to this.
>
> The spec being Intel's also says it is a PCI device... BIOS is a type
> of firmware.
Ofcourse.
>
> [...]
>
>>>> +       sata0: sata@29000000 { /* Qualcomm APQ8064 */
>>>
>>>
>>> Do you really need another example just for this?
>>>
>>>> +               compatible = "generic-ahci";
>>>
>>>
>>> Where's your chip specific compatible string? You would not require a
>>> DT update to fix this if you had that.
>>
>>
>> Possibly, But we really are not doing anything specific in the ahci driver
>> which is not generic, that might be the reason why we skipped this in the
>> first place.
>>
>> I agree we could solve this issue in more than one way, The only advantage
>> of this new bindings would be to other platforms benefiting from this
>> workaround would not have to keep adding a new compatible string into the
>> ahci-platform driver.
>>
>> Like Annapurna Alpine platform seems to have the same issue.
>>
>> Am ok to do it either way.
>
> I'm saying do both. Adding ports-implemented is fine, but add an SoC
> compatible string (in the dts, not the driver).
That sounds Good, I will add compatible string in DT and implement 
ports-implemented.

--srini
>
> Rob
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web