From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org
Cc: thomas.petazzoni@free-electrons.com, zmxu@marvell.com,
devicetree@vger.kernel.org,
"Antoine Ténart" <antoine.tenart@free-electrons.com>,
linux-kernel@vger.kernel.org, kishon@ti.com,
linux-ide@vger.kernel.org, alexandre.belloni@free-electrons.com,
jszhang@marvell.com, tj@kernel.org
Subject: Re: [PATCH v3 1/6] phy: add a driver for the Berlin SATA PHY
Date: Wed, 14 May 2014 20:56:29 +0200 [thread overview]
Message-ID: <5373BC5D.7010300@gmail.com> (raw)
In-Reply-To: <17808571.N5ZGjXFEVP@wuerfel>
On 05/14/2014 08:51 PM, Arnd Bergmann wrote:
> On Wednesday 14 May 2014 20:42:16 Sebastian Hesselbarth wrote:
>>>> For the driver, Antoine then would have to squeeze all PHY register
>>>> mangling in phy-berlin2.c and see how to make ahci-platform aware of
>>>> individual port nodes (I haven't looked up if it already exists, sorry)
>>>> and announce only enabled port child nodes, right?
>>>
>>> I've been thinking some more about this aspect. I don't actually have
>>> a strong opinion on whether it's better to use the generic ahci-platform
>>> driver, or to keep the multi-phy support as a special variant for
>>> berlin. If we do the latter, it would however be good to define the
>>> binding in a way that lets us later merge things into the generic phy
>>> driver in case we get more of the same.
>>
>> Hmm, IMHO multi-phy support is orthogonal to ahci-platform, isn't it?
>> ahci-platform needs to know about the phy property and calls some
>> helper that deals with the phy-specifier?
>>
>> About a generic _phy_ driver, I am not so sure if berlin is the best
>> template right now
>>
>> So, my call would be:
>> - make ahci-platform aware of port sub-nodes and phy properties
>> - have a berlin specific PHY driver
>
> I'm not sure if we need sub-nodes per port, it should be enough
> to have an array of phys, plus a way to match them up with the
> ports.
Actually, I'd love to see sub-nodes per port as it will allow to
disabled unused ports on a per-board basis.
I have this in mind for a long time for Kirkwood's SATA node already:
Consider a board where you have the one available SATA plug connected
to port 1. How would that work out with status = "disabled"/"okay" that
doesn't allow array of strings obviously?
Sebastian
WARNING: multiple messages have this Message-ID (diff)
From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/6] phy: add a driver for the Berlin SATA PHY
Date: Wed, 14 May 2014 20:56:29 +0200 [thread overview]
Message-ID: <5373BC5D.7010300@gmail.com> (raw)
In-Reply-To: <17808571.N5ZGjXFEVP@wuerfel>
On 05/14/2014 08:51 PM, Arnd Bergmann wrote:
> On Wednesday 14 May 2014 20:42:16 Sebastian Hesselbarth wrote:
>>>> For the driver, Antoine then would have to squeeze all PHY register
>>>> mangling in phy-berlin2.c and see how to make ahci-platform aware of
>>>> individual port nodes (I haven't looked up if it already exists, sorry)
>>>> and announce only enabled port child nodes, right?
>>>
>>> I've been thinking some more about this aspect. I don't actually have
>>> a strong opinion on whether it's better to use the generic ahci-platform
>>> driver, or to keep the multi-phy support as a special variant for
>>> berlin. If we do the latter, it would however be good to define the
>>> binding in a way that lets us later merge things into the generic phy
>>> driver in case we get more of the same.
>>
>> Hmm, IMHO multi-phy support is orthogonal to ahci-platform, isn't it?
>> ahci-platform needs to know about the phy property and calls some
>> helper that deals with the phy-specifier?
>>
>> About a generic _phy_ driver, I am not so sure if berlin is the best
>> template right now
>>
>> So, my call would be:
>> - make ahci-platform aware of port sub-nodes and phy properties
>> - have a berlin specific PHY driver
>
> I'm not sure if we need sub-nodes per port, it should be enough
> to have an array of phys, plus a way to match them up with the
> ports.
Actually, I'd love to see sub-nodes per port as it will allow to
disabled unused ports on a per-board basis.
I have this in mind for a long time for Kirkwood's SATA node already:
Consider a board where you have the one available SATA plug connected
to port 1. How would that work out with status = "disabled"/"okay" that
doesn't allow array of strings obviously?
Sebastian
next prev parent reply other threads:[~2014-05-14 18:56 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 9:48 [PATCH v3 0/6] ARM: berlin: add AHCI support Antoine Ténart
2014-05-14 9:48 ` Antoine Ténart
2014-05-14 9:48 ` [PATCH v3 1/6] phy: add a driver for the Berlin SATA PHY Antoine Ténart
2014-05-14 9:48 ` Antoine Ténart
2014-05-14 10:13 ` Kishon Vijay Abraham I
2014-05-14 10:13 ` Kishon Vijay Abraham I
2014-05-14 10:13 ` Kishon Vijay Abraham I
2014-05-14 10:21 ` Antoine Ténart
2014-05-14 10:21 ` Antoine Ténart
2014-05-15 6:15 ` Kishon Vijay Abraham I
2014-05-15 6:15 ` Kishon Vijay Abraham I
2014-05-15 6:15 ` Kishon Vijay Abraham I
2014-05-14 13:02 ` Arnd Bergmann
2014-05-14 13:02 ` Arnd Bergmann
2014-05-14 14:50 ` Antoine Ténart
2014-05-14 14:50 ` Antoine Ténart
2014-05-14 15:31 ` Arnd Bergmann
2014-05-14 15:31 ` Arnd Bergmann
2014-05-14 15:31 ` Arnd Bergmann
2014-05-14 15:49 ` Antoine Ténart
2014-05-14 15:49 ` Antoine Ténart
2014-05-14 16:11 ` Arnd Bergmann
2014-05-14 16:11 ` Arnd Bergmann
2014-05-14 16:57 ` Antoine Ténart
2014-05-14 16:57 ` Antoine Ténart
2014-05-14 17:57 ` Sebastian Hesselbarth
2014-05-14 17:57 ` Sebastian Hesselbarth
2014-05-14 17:57 ` Sebastian Hesselbarth
2014-05-14 18:12 ` Arnd Bergmann
2014-05-14 18:12 ` Arnd Bergmann
2014-05-14 18:42 ` Sebastian Hesselbarth
2014-05-14 18:42 ` Sebastian Hesselbarth
2014-05-14 18:51 ` Arnd Bergmann
2014-05-14 18:51 ` Arnd Bergmann
2014-05-14 18:56 ` Sebastian Hesselbarth [this message]
2014-05-14 18:56 ` Sebastian Hesselbarth
2014-05-14 19:10 ` Arnd Bergmann
2014-05-14 19:10 ` Arnd Bergmann
2014-05-15 6:45 ` Kishon Vijay Abraham I
2014-05-15 6:45 ` Kishon Vijay Abraham I
2014-05-15 7:02 ` Sebastian Hesselbarth
2014-05-15 7:02 ` Sebastian Hesselbarth
2014-05-15 8:46 ` Kishon Vijay Abraham I
2014-05-15 8:46 ` Kishon Vijay Abraham I
[not found] ` <53747F03.5030206-l0cyMroinI0@public.gmane.org>
2014-05-15 9:17 ` Sebastian Hesselbarth
2014-05-15 9:17 ` Sebastian Hesselbarth
2014-05-15 9:17 ` Sebastian Hesselbarth
2014-05-15 9:25 ` Kishon Vijay Abraham I
2014-05-15 9:25 ` Kishon Vijay Abraham I
2014-05-14 9:48 ` [PATCH v3 2/6] Documentation: bindings: add " Antoine Ténart
2014-05-14 9:48 ` Antoine Ténart
2014-05-14 9:48 ` Antoine Ténart
[not found] ` <1400060942-10588-1-git-send-email-antoine.tenart-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-05-14 9:48 ` [PATCH v3 3/6] ata: ahci: add AHCI support for the Berlin BG2Q Antoine Ténart
2014-05-14 9:48 ` Antoine Ténart
2014-05-14 9:48 ` Antoine Ténart
2014-05-14 9:49 ` [PATCH v3 4/6] Documentation: bindings: add the berlin-ahci compatible to the ahci platform Antoine Ténart
2014-05-14 9:49 ` Antoine Ténart
2014-05-14 9:49 ` Antoine Ténart
2014-05-14 9:49 ` [PATCH v3 5/6] ARM: berlin: add the AHCI node for the BG2Q Antoine Ténart
2014-05-14 9:49 ` Antoine Ténart
2014-05-14 9:49 ` [PATCH v3 6/6] ARM: berlin: enable the eSATA interface on the BG2Q DMP Antoine Ténart
2014-05-14 9:49 ` Antoine Ténart
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=5373BC5D.7010300@gmail.com \
--to=sebastian.hesselbarth@gmail.com \
--cc=alexandre.belloni@free-electrons.com \
--cc=antoine.tenart@free-electrons.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=jszhang@marvell.com \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas.petazzoni@free-electrons.com \
--cc=tj@kernel.org \
--cc=zmxu@marvell.com \
/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.