All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Rob Herring <robh+dt@kernel.org>
Cc: Tejun Heo <tj@kernel.org>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	Andy Gross <andy.gross@linaro.org>,
	Hans de Goede <hdegoede@redhat.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-soc@vger.kernel.org,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	jmaggard10@gmail.com
Subject: Re: [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt bindings.
Date: Tue, 29 Mar 2016 18:10:03 +0100	[thread overview]
Message-ID: <56FAB6EB.6040802@linaro.org> (raw)
In-Reply-To: <CAL_JsqLR2GFuveVJj9u9RPAyHvgrF=TUPQXFVBH_BO3BXNx_vw@mail.gmail.com>



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
>

WARNING: multiple messages have this Message-ID (diff)
From: srinivas.kandagatla@linaro.org (Srinivas Kandagatla)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt bindings.
Date: Tue, 29 Mar 2016 18:10:03 +0100	[thread overview]
Message-ID: <56FAB6EB.6040802@linaro.org> (raw)
In-Reply-To: <CAL_JsqLR2GFuveVJj9u9RPAyHvgrF=TUPQXFVBH_BO3BXNx_vw@mail.gmail.com>



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 at 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
>

  reply	other threads:[~2016-03-29 17:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 13:11 [RFC PATCH 0/3] ahci: add ports-implemented dt bindings Srinivas Kandagatla
2016-03-29 13:11 ` Srinivas Kandagatla
2016-03-29 13:11 ` [RFC PATCH 1/3] libahci: save port map for forced port map Srinivas Kandagatla
2016-03-29 13:11   ` Srinivas Kandagatla
2016-03-30 18:57   ` Tejun Heo
2016-03-30 18:57     ` Tejun Heo
2016-03-31 15:58     ` Srinivas Kandagatla
2016-03-31 15:58       ` Srinivas Kandagatla
2016-03-31 16:43       ` Tejun Heo
2016-03-31 16:43         ` Tejun Heo
2016-03-31 16:51         ` Srinivas Kandagatla
2016-03-31 16:51           ` Srinivas Kandagatla
2016-03-29 13:11 ` [RFC PATCH 2/3] ata: ahci-platform: Add ports-implemented dt bindings Srinivas Kandagatla
2016-03-29 13:11   ` Srinivas Kandagatla
2016-03-29 14:11   ` Rob Herring
2016-03-29 14:11     ` Rob Herring
2016-03-29 14:43     ` Srinivas Kandagatla
2016-03-29 14:43       ` Srinivas Kandagatla
2016-03-29 14:43       ` Srinivas Kandagatla
2016-03-29 17:07       ` Rob Herring
2016-03-29 17:07         ` Rob Herring
2016-03-29 17:10         ` Srinivas Kandagatla [this message]
2016-03-29 17:10           ` Srinivas Kandagatla
2016-03-29 13:11 ` [RFC PATCH 3/3] ARM: dts: apq8064: add ahci ports-implemented mask Srinivas Kandagatla
2016-03-29 13:11   ` Srinivas Kandagatla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56FAB6EB.6040802@linaro.org \
    --to=srinivas.kandagatla@linaro.org \
    --cc=andy.gross@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=jmaggard10@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-soc@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.