Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi, On Mon, Aug 19, 2013 at 10:58:09AM +0530, Kishon Vijay Abraham I wrote: > >> So maybe let's stop solving an already solved problem and just state that > >> you need to explicitly assign device ID to use this framework? > > > > Felipe, > > Can we have it the way I had in my v10 patch series till we find a better > > way? > > I think this *non-dt* stuff shouldn't be blocking as most of the users are > > dt only? I don't have a lot of things against it, but preventing driver authors to use PLATFORM_DEVID_AUTO just to use the framework is likely going to piss some people off. Perhaps we can start with this approach and fix things later ? At least it ungates all the PHY drivers which are depending on this framework (quite a few already). If everybody agrees with this approach, I'd be ok with it too. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi, On Mon, Aug 19, 2013 at 10:58:09AM +0530, Kishon Vijay Abraham I wrote: So maybe let's stop solving an already solved problem and just state that you need to explicitly assign device ID to use this framework? Felipe, Can we have it the way I had in my v10 patch series till we find a better way? I think this *non-dt* stuff shouldn't be blocking as most of the users are dt only? I don't have a lot of things against it, but preventing driver authors to use PLATFORM_DEVID_AUTO just to use the framework is likely going to piss some people off. Perhaps we can start with this approach and fix things later ? At least it ungates all the PHY drivers which are depending on this framework (quite a few already). If everybody agrees with this approach, I'd be ok with it too. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Felipe,
ping..
On Wednesday 14 August 2013 08:35 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Wednesday 14 August 2013 04:34 AM, Tomasz Figa wrote:
>> On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
>>> W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
> On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
>> On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
>>> On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I
>> wrote:
> IMHO we need a lookup method for PHYs, just like for clocks,
> regulators, PWMs or even i2c busses because there are complex
> cases
> when passing just a name using platform data will not work. I
> would
> second what Stephen said [1] and define a structure doing
> things
> in a
> DT-like way.
>
> Example;
>
> [platform code]
>
> static const struct phy_lookup my_phy_lookup[] = {
>
> PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1",
> "phy.2"),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change
and
PHY_LOOKUP wont be useful.
>>>
>>> I don't think this is a problem. All the existing lookup
>>> methods
>>> already
>>> use ID to identify devices (see regulators, clkdev, PWMs, i2c,
>>> ...). You
>>> can simply add a requirement that the ID must be assigned
>>> manually,
>>> without using PLATFORM_DEVID_AUTO to use PHY lookup.
>>
>> And I'm saying that this idea, of using a specific name and id,
>> is
>> frought with fragility and will break in the future in various
>> ways
>> when
>> devices get added to systems, making these strings constantly
>> have
>> to be
>> kept up to date with different board configurations.
>>
>> People, NEVER, hardcode something like an id. The fact that
>> this
>> happens today with the clock code, doesn't make it right, it
>> makes
>> the
>> clock code wrong. Others have already said that this is wrong
>> there
>> as
>> well, as systems change and dynamic ids get used more and more.
>>
>> Let's not repeat the same mistakes of the past just because we
>> refuse to
>> learn from them...
>>
>> So again, the "find a phy by a string" functions should be
>> removed,
>> the
>> device id should be automatically created by the phy core just
>> to
>> make
>> things unique in sysfs, and no driver code should _ever_ be
>> reliant
>> on
>> the number that is being created, and the pointer to the phy
>> structure
>> should be used everywhere instead.
>>
>> With those types of changes, I will consider merging this
>> subsystem,
>> but
>> without them, sorry, I will not.
>
> I'll agree with Greg here, the very fact that we see people
> trying to
> add a requirement of *NOT* using PLATFORM_DEVID_AUTO already
> points
> to a big problem in the framework.
>
> The fact is that if we don't allow PLATFORM_DEVID_AUTO we will
> end up
> adding similar infrastructure to the driver themselves to make
> sure
> we
> don't end up with duplicate names in sysfs in case we have
> multiple
> instances of the same IP in the SoC (or several of the same PCIe
> card).
> I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we
can
give the correct binding information to the PHY framework. I think
we
can drop having this non-dt support in PHY framework? I see only
one
platform (OMAP3) going to be needing this non-dt support and we
can
use the USB PHY library for it.>
>>>
>>> you shouldn't drop support for non-DT platform, in any case we
>>> lived
>>> without DT (and still do) for years. Gotta find a better way ;-)
>>
>> hmm..
>>
>> how about passing the device names of PHY in platform data of the
>> controller? It should be deterministic as the PHY framework assigns
>> its
>> own id and we *don't* want to add any requirement that the ID must
>> be
>> assigned manually without using PLATFORM_DEVID_AUTO. We can get rid
>> of
>> *phy_init_data* in the v10 patch
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Felipe,
ping..
On Wednesday 14 August 2013 08:35 PM, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 14 August 2013 04:34 AM, Tomasz Figa wrote:
On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I
wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing
things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1,
phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change
and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup
methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned
manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id,
is
frought with fragility and will break in the future in various
ways
when
devices get added to systems, making these strings constantly
have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that
this
happens today with the clock code, doesn't make it right, it
makes
the
clock code wrong. Others have already said that this is wrong
there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be
removed,
the
device id should be automatically created by the phy core just
to
make
things unique in sysfs, and no driver code should _ever_ be
reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this
subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people
trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already
points
to a big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will
end up
adding similar infrastructure to the driver themselves to make
sure
we
don't end up with duplicate names in sysfs in case we have
multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we
can
give the correct binding information to the PHY framework. I think
we
can drop having this non-dt support in PHY framework? I see only
one
platform (OMAP3) going to be needing this non-dt support and we
can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we
lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns
its
own id and we *don't* want to add any requirement that the ID must
be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid
of
*phy_init_data* in the v10 patch series.
OK, so the PHY device name would have a fixed part, passed as
platform data of the controller and a variable part appended
by the PHY core, depending on the number of registered PHYs ?
Then same PHY names would be passed as the PHY provider driver's
platform data ?
Then if there are 2 instances of the above (same names in platform
data) how would be determined which PHY controller is linked to
which PHY supplier ?
I guess you want each device instance to have different PHY device
names already in platform data ? That might work. We probably will
be focused mostly on DT anyway. It seem without DT we are trying
to find some layer that would allow us to couple relevant devices
and overcome driver core inconvenience that it provides to means
to identify specific devices in advance. :) Your proposal sounds
reasonable, however I might be missing some details or corner cases.
What about slightly altering the concept of v9 to pass a pointer to
struct device instead of device name inside phy_init_data?
As Felipe said, we don't want to pass pointers in platform_data
to/from random subsystems. We pass data, passing pointers would
be a total mess IMHO.
Well,
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Wednesday 14 August 2013 04:34 AM, Tomasz Figa wrote:
> On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
>> W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
>>> On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
> On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
>> On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I
> wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing
things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1",
"phy.2"),
>>>
>>> The only problem here is that if *PLATFORM_DEVID_AUTO* is used
>>> while
>>> creating the device, the ids in the device name would change
>>> and
>>> PHY_LOOKUP wont be useful.
>>
>> I don't think this is a problem. All the existing lookup
>> methods
>> already
>> use ID to identify devices (see regulators, clkdev, PWMs, i2c,
>> ...). You
>> can simply add a requirement that the ID must be assigned
>> manually,
>> without using PLATFORM_DEVID_AUTO to use PHY lookup.
>
> And I'm saying that this idea, of using a specific name and id,
> is
> frought with fragility and will break in the future in various
> ways
> when
> devices get added to systems, making these strings constantly
> have
> to be
> kept up to date with different board configurations.
>
> People, NEVER, hardcode something like an id. The fact that
> this
> happens today with the clock code, doesn't make it right, it
> makes
> the
> clock code wrong. Others have already said that this is wrong
> there
> as
> well, as systems change and dynamic ids get used more and more.
>
> Let's not repeat the same mistakes of the past just because we
> refuse to
> learn from them...
>
> So again, the "find a phy by a string" functions should be
> removed,
> the
> device id should be automatically created by the phy core just
> to
> make
> things unique in sysfs, and no driver code should _ever_ be
> reliant
> on
> the number that is being created, and the pointer to the phy
> structure
> should be used everywhere instead.
>
> With those types of changes, I will consider merging this
> subsystem,
> but
> without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people
trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already
points
to a big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will
end up
adding similar infrastructure to the driver themselves to make
sure
we
don't end up with duplicate names in sysfs in case we have
multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
>>>
>>> If we are using PLATFORM_DEVID_AUTO, then I dont see any way we
>>> can
>>> give the correct binding information to the PHY framework. I think
>>> we
>>> can drop having this non-dt support in PHY framework? I see only
>>> one
>>> platform (OMAP3) going to be needing this non-dt support and we
>>> can
>>> use the USB PHY library for it.>
>>
>> you shouldn't drop support for non-DT platform, in any case we
>> lived
>> without DT (and still do) for years. Gotta find a better way ;-)
>
> hmm..
>
> how about passing the device names of PHY in platform data of the
> controller? It should be deterministic as the PHY framework assigns
> its
> own id and we *don't* want to add any requirement that the ID must
> be
> assigned manually without using PLATFORM_DEVID_AUTO. We can get rid
> of
> *phy_init_data* in the v10 patch series.
>>
>> OK, so the PHY device name would have a fixed part, passed as
>> platform data of the controller and a variable part appended
>> by the PHY core, depending on the number of registered PHYs ?
>>
>> Then
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Wednesday 14 August 2013 04:34 AM, Tomasz Figa wrote:
On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I
wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing
things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1,
phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change
and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup
methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned
manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id,
is
frought with fragility and will break in the future in various
ways
when
devices get added to systems, making these strings constantly
have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that
this
happens today with the clock code, doesn't make it right, it
makes
the
clock code wrong. Others have already said that this is wrong
there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be
removed,
the
device id should be automatically created by the phy core just
to
make
things unique in sysfs, and no driver code should _ever_ be
reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this
subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people
trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already
points
to a big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will
end up
adding similar infrastructure to the driver themselves to make
sure
we
don't end up with duplicate names in sysfs in case we have
multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we
can
give the correct binding information to the PHY framework. I think
we
can drop having this non-dt support in PHY framework? I see only
one
platform (OMAP3) going to be needing this non-dt support and we
can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we
lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns
its
own id and we *don't* want to add any requirement that the ID must
be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid
of
*phy_init_data* in the v10 patch series.
OK, so the PHY device name would have a fixed part, passed as
platform data of the controller and a variable part appended
by the PHY core, depending on the number of registered PHYs ?
Then same PHY names would be passed as the PHY provider driver's
platform data ?
Then if there are 2 instances of the above (same names in platform
data) how would be determined which PHY controller is linked to
which PHY supplier ?
I guess you want each device instance to have different PHY device
names already in platform data ? That might work. We probably will
be focused mostly on DT anyway. It seem without DT we are trying
to find some layer that would allow us to couple relevant devices
and overcome driver core inconvenience that it provides to means
to identify specific devices in advance. :) Your proposal sounds
reasonable, however I might be missing some details or corner cases.
What about slightly altering the concept of v9 to pass a pointer to
struct device instead of device name inside phy_init_data?
As Felipe said, we don't want to pass pointers in platform_data
to/from random subsystems. We pass data, passing pointers would
be a total mess IMHO.
Well, this is a total mess anyway... I don't really get the point of using
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
> W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
> > On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
> >> On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
> >>> On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
> On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I
wrote:
> >> IMHO we need a lookup method for PHYs, just like for clocks,
> >> regulators, PWMs or even i2c busses because there are complex
> >> cases
> >> when passing just a name using platform data will not work. I
> >> would
> >> second what Stephen said [1] and define a structure doing
> >> things
> >> in a
> >> DT-like way.
> >>
> >> Example;
> >>
> >> [platform code]
> >>
> >> static const struct phy_lookup my_phy_lookup[] = {
> >>
> >>PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1",
> >>"phy.2"),
> >
> > The only problem here is that if *PLATFORM_DEVID_AUTO* is used
> > while
> > creating the device, the ids in the device name would change
> > and
> > PHY_LOOKUP wont be useful.
>
> I don't think this is a problem. All the existing lookup
> methods
> already
> use ID to identify devices (see regulators, clkdev, PWMs, i2c,
> ...). You
> can simply add a requirement that the ID must be assigned
> manually,
> without using PLATFORM_DEVID_AUTO to use PHY lookup.
> >>>
> >>> And I'm saying that this idea, of using a specific name and id,
> >>> is
> >>> frought with fragility and will break in the future in various
> >>> ways
> >>> when
> >>> devices get added to systems, making these strings constantly
> >>> have
> >>> to be
> >>> kept up to date with different board configurations.
> >>>
> >>> People, NEVER, hardcode something like an id. The fact that
> >>> this
> >>> happens today with the clock code, doesn't make it right, it
> >>> makes
> >>> the
> >>> clock code wrong. Others have already said that this is wrong
> >>> there
> >>> as
> >>> well, as systems change and dynamic ids get used more and more.
> >>>
> >>> Let's not repeat the same mistakes of the past just because we
> >>> refuse to
> >>> learn from them...
> >>>
> >>> So again, the "find a phy by a string" functions should be
> >>> removed,
> >>> the
> >>> device id should be automatically created by the phy core just
> >>> to
> >>> make
> >>> things unique in sysfs, and no driver code should _ever_ be
> >>> reliant
> >>> on
> >>> the number that is being created, and the pointer to the phy
> >>> structure
> >>> should be used everywhere instead.
> >>>
> >>> With those types of changes, I will consider merging this
> >>> subsystem,
> >>> but
> >>> without them, sorry, I will not.
> >>
> >> I'll agree with Greg here, the very fact that we see people
> >> trying to
> >> add a requirement of *NOT* using PLATFORM_DEVID_AUTO already
> >> points
> >> to a big problem in the framework.
> >>
> >> The fact is that if we don't allow PLATFORM_DEVID_AUTO we will
> >> end up
> >> adding similar infrastructure to the driver themselves to make
> >> sure
> >> we
> >> don't end up with duplicate names in sysfs in case we have
> >> multiple
> >> instances of the same IP in the SoC (or several of the same PCIe
> >> card).
> >> I really don't want to go back to that.
> >
> > If we are using PLATFORM_DEVID_AUTO, then I dont see any way we
> > can
> > give the correct binding information to the PHY framework. I think
> > we
> > can drop having this non-dt support in PHY framework? I see only
> > one
> > platform (OMAP3) going to be needing this non-dt support and we
> > can
> > use the USB PHY library for it.>
>
> you shouldn't drop support for non-DT platform, in any case we
> lived
> without DT (and still do) for years. Gotta find a better way ;-)
> >>>
> >>> hmm..
> >>>
> >>> how about passing the device names of PHY in platform data of the
> >>> controller? It should be deterministic as the PHY framework assigns
> >>> its
> >>> own id and we *don't* want to add any requirement that the ID must
> >>> be
> >>> assigned manually without using PLATFORM_DEVID_AUTO. We can get rid
> >>> of
> >>> *phy_init_data* in the v10 patch series.
>
> OK, so the PHY device name would have a fixed part, passed as
> platform data of the controller and a variable part appended
> by the PHY core, depending on the number of registered PHYs ?
>
> Then same PHY names would be passed as the PHY provider
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways
when
devices get added to systems, making these strings constantly have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes
the
clock code wrong. Others have already said that this is wrong there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the "find a phy by a string" functions should be removed,
the
device id should be automatically created by the phy core just to
make
things unique in sysfs, and no driver code should _ever_ be reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
to a big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure
we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
give the correct binding information to the PHY framework. I think we
can drop having this non-dt support in PHY framework? I see only one
platform (OMAP3) going to be needing this non-dt support and we can
use the USB PHY library for it.>
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns its
own id and we *don't* want to add any requirement that the ID must be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
*phy_init_data* in the v10 patch series.
OK, so the PHY device name would have a fixed part, passed as
platform data of the controller and a variable part appended
by the PHY core, depending on the number of registered PHYs ?
Then same PHY names would be passed as the PHY provider driver's
platform data ?
Then if there are 2 instances of the above (same names in platform
data) how would be determined which PHY controller is linked to
which PHY supplier ?
I guess you want each device instance to have different PHY device
names already in platform data ? That might work. We probably will
be focused mostly on DT anyway. It seem without DT we are trying
to find some layer that would allow us to couple relevant devices
and overcome driver core inconvenience that it provides to means
to identify specific devices in advance. :) Your proposal sounds
reasonable, however I might be missing some details or corner cases.
What about slightly altering the concept of v9 to pass a pointer to struct
device instead of device name inside phy_init_data?
As Felipe said, we don't want to pass pointers in platform_data
to/from random subsystems. We pass data, passing pointers would
be a total mess IMHO.
The problem is device might be created very late. (For example in omap4, usb2
phy device gets created when ocp2scp bus is probed). And we have to pass the
init data in board file.
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
> On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
> IMHO we need a lookup method for PHYs, just like for clocks,
> regulators, PWMs or even i2c busses because there are complex
> cases
> when passing just a name using platform data will not work. I
> would
> second what Stephen said [1] and define a structure doing things
> in a
> DT-like way.
>
> Example;
>
> [platform code]
>
> static const struct phy_lookup my_phy_lookup[] = {
>
> PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
>>>
>>> I don't think this is a problem. All the existing lookup methods
>>> already
>>> use ID to identify devices (see regulators, clkdev, PWMs, i2c,
>>> ...). You
>>> can simply add a requirement that the ID must be assigned manually,
>>> without using PLATFORM_DEVID_AUTO to use PHY lookup.
>>
>> And I'm saying that this idea, of using a specific name and id, is
>> frought with fragility and will break in the future in various ways
>> when
>> devices get added to systems, making these strings constantly have
>> to be
>> kept up to date with different board configurations.
>>
>> People, NEVER, hardcode something like an id. The fact that this
>> happens today with the clock code, doesn't make it right, it makes
>> the
>> clock code wrong. Others have already said that this is wrong there
>> as
>> well, as systems change and dynamic ids get used more and more.
>>
>> Let's not repeat the same mistakes of the past just because we
>> refuse to
>> learn from them...
>>
>> So again, the "find a phy by a string" functions should be removed,
>> the
>> device id should be automatically created by the phy core just to
>> make
>> things unique in sysfs, and no driver code should _ever_ be reliant
>> on
>> the number that is being created, and the pointer to the phy
>> structure
>> should be used everywhere instead.
>>
>> With those types of changes, I will consider merging this subsystem,
>> but
>> without them, sorry, I will not.
>
> I'll agree with Greg here, the very fact that we see people trying to
> add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
> to a
> big problem in the framework.
>
> The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
> adding similar infrastructure to the driver themselves to make sure
> we
> don't end up with duplicate names in sysfs in case we have multiple
> instances of the same IP in the SoC (or several of the same PCIe
> card).
> I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
give the correct binding information to the PHY framework. I think we
can drop having this non-dt support in PHY framework? I see only one
platform (OMAP3) going to be needing this non-dt support and we can
use the USB PHY library for it.>
>>> you shouldn't drop support for non-DT platform, in any case we lived
>>> without DT (and still do) for years. Gotta find a better way ;-)
>>
>> hmm..
>>
>> how about passing the device names of PHY in platform data of the
>> controller? It should be deterministic as the PHY framework assigns its
>> own id and we *don't* want to add any requirement that the ID must be
>> assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
>> *phy_init_data* in the v10 patch series.
>
> What about slightly altering the concept of v9 to pass a pointer to struct
> device instead of device name inside phy_init_data?
The problem is device might be created very late. (For example in omap4, usb2
phy device gets created when ocp2scp bus is probed). And we have to pass the
init data in board file.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
> Hi,
>
> On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
> >>> IMHO we need a lookup method for PHYs, just like for clocks,
> >>> regulators, PWMs or even i2c busses because there are complex
> >>> cases
> >>> when passing just a name using platform data will not work. I
> >>> would
> >>> second what Stephen said [1] and define a structure doing things
> >>> in a
> >>> DT-like way.
> >>>
> >>> Example;
> >>>
> >>> [platform code]
> >>>
> >>> static const struct phy_lookup my_phy_lookup[] = {
> >>>
> >>> PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
> >>
> >> The only problem here is that if *PLATFORM_DEVID_AUTO* is used
> >> while
> >> creating the device, the ids in the device name would change and
> >> PHY_LOOKUP wont be useful.
> >
> > I don't think this is a problem. All the existing lookup methods
> > already
> > use ID to identify devices (see regulators, clkdev, PWMs, i2c,
> > ...). You
> > can simply add a requirement that the ID must be assigned manually,
> > without using PLATFORM_DEVID_AUTO to use PHY lookup.
>
> And I'm saying that this idea, of using a specific name and id, is
> frought with fragility and will break in the future in various ways
> when
> devices get added to systems, making these strings constantly have
> to be
> kept up to date with different board configurations.
>
> People, NEVER, hardcode something like an id. The fact that this
> happens today with the clock code, doesn't make it right, it makes
> the
> clock code wrong. Others have already said that this is wrong there
> as
> well, as systems change and dynamic ids get used more and more.
>
> Let's not repeat the same mistakes of the past just because we
> refuse to
> learn from them...
>
> So again, the "find a phy by a string" functions should be removed,
> the
> device id should be automatically created by the phy core just to
> make
> things unique in sysfs, and no driver code should _ever_ be reliant
> on
> the number that is being created, and the pointer to the phy
> structure
> should be used everywhere instead.
>
> With those types of changes, I will consider merging this subsystem,
> but
> without them, sorry, I will not.
> >>>
> >>> I'll agree with Greg here, the very fact that we see people trying to
> >>> add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
> >>> to a
> >>> big problem in the framework.
> >>>
> >>> The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
> >>> adding similar infrastructure to the driver themselves to make sure
> >>> we
> >>> don't end up with duplicate names in sysfs in case we have multiple
> >>> instances of the same IP in the SoC (or several of the same PCIe
> >>> card).
> >>> I really don't want to go back to that.
> >>
> >> If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
> >> give the correct binding information to the PHY framework. I think we
> >> can drop having this non-dt support in PHY framework? I see only one
> >> platform (OMAP3) going to be needing this non-dt support and we can
> >> use the USB PHY library for it.>
> > you shouldn't drop support for non-DT platform, in any case we lived
> > without DT (and still do) for years. Gotta find a better way ;-)
>
> hmm..
>
> how about passing the device names of PHY in platform data of the
> controller? It should be deterministic as the PHY framework assigns its
> own id and we *don't* want to add any requirement that the ID must be
> assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
> *phy_init_data* in the v10 patch series.
What about slightly altering the concept of v9 to pass a pointer to struct
device instead of device name inside phy_init_data?
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
>>> IMHO we need a lookup method for PHYs, just like for clocks,
>>> regulators, PWMs or even i2c busses because there are complex cases
>>> when passing just a name using platform data will not work. I would
>>> second what Stephen said [1] and define a structure doing things in a
>>> DT-like way.
>>>
>>> Example;
>>>
>>> [platform code]
>>>
>>> static const struct phy_lookup my_phy_lookup[] = {
>>>
>>> PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
>>
>> The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
>> creating the device, the ids in the device name would change and
>> PHY_LOOKUP wont be useful.
>
> I don't think this is a problem. All the existing lookup methods already
> use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
> can simply add a requirement that the ID must be assigned manually,
> without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways when
devices get added to systems, making these strings constantly have to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes the
clock code wrong. Others have already said that this is wrong there as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we refuse to
learn from them...
So again, the "find a phy by a string" functions should be removed, the
device id should be automatically created by the phy core just to make
things unique in sysfs, and no driver code should _ever_ be reliant on
the number that is being created, and the pointer to the phy structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem, but
without them, sorry, I will not.
>>>
>>> I'll agree with Greg here, the very fact that we see people trying to
>>> add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points to a
>>> big problem in the framework.
>>>
>>> The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
>>> adding similar infrastructure to the driver themselves to make sure we
>>> don't end up with duplicate names in sysfs in case we have multiple
>>> instances of the same IP in the SoC (or several of the same PCIe card).
>>> I really don't want to go back to that.
>>
>> If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can give the
>> correct binding information to the PHY framework. I think we can drop having
>> this non-dt support in PHY framework? I see only one platform (OMAP3) going
>> to
>> be needing this non-dt support and we can use the USB PHY library for it.
>
> you shouldn't drop support for non-DT platform, in any case we lived
> without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the controller?
It should be deterministic as the PHY framework assigns its own id and we
*don't* want to add any requirement that the ID must be assigned manually
without using PLATFORM_DEVID_AUTO. We can get rid of *phy_init_data* in the v10
patch series.
Thanks
Kishon
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex cases
when passing just a name using platform data will not work. I would
second what Stephen said [1] and define a structure doing things in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods already
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways when
devices get added to systems, making these strings constantly have to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes the
clock code wrong. Others have already said that this is wrong there as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we refuse to
learn from them...
So again, the find a phy by a string functions should be removed, the
device id should be automatically created by the phy core just to make
things unique in sysfs, and no driver code should _ever_ be reliant on
the number that is being created, and the pointer to the phy structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem, but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points to a
big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can give the
correct binding information to the PHY framework. I think we can drop having
this non-dt support in PHY framework? I see only one platform (OMAP3) going
to
be needing this non-dt support and we can use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the controller?
It should be deterministic as the PHY framework assigns its own id and we
*don't* want to add any requirement that the ID must be assigned manually
without using PLATFORM_DEVID_AUTO. We can get rid of *phy_init_data* in the v10
patch series.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways
when
devices get added to systems, making these strings constantly have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes
the
clock code wrong. Others have already said that this is wrong there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be removed,
the
device id should be automatically created by the phy core just to
make
things unique in sysfs, and no driver code should _ever_ be reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
to a
big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure
we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
give the correct binding information to the PHY framework. I think we
can drop having this non-dt support in PHY framework? I see only one
platform (OMAP3) going to be needing this non-dt support and we can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns its
own id and we *don't* want to add any requirement that the ID must be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
*phy_init_data* in the v10 patch series.
What about slightly altering the concept of v9 to pass a pointer to struct
device instead of device name inside phy_init_data?
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways
when
devices get added to systems, making these strings constantly have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes
the
clock code wrong. Others have already said that this is wrong there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be removed,
the
device id should be automatically created by the phy core just to
make
things unique in sysfs, and no driver code should _ever_ be reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
to a
big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure
we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
give the correct binding information to the PHY framework. I think we
can drop having this non-dt support in PHY framework? I see only one
platform (OMAP3) going to be needing this non-dt support and we can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns its
own id and we *don't* want to add any requirement that the ID must be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
*phy_init_data* in the v10 patch series.
What about slightly altering the concept of v9 to pass a pointer to struct
device instead of device name inside phy_init_data?
The problem is device might be created very late. (For example in omap4, usb2
phy device gets created when ocp2scp bus is probed). And we have to pass the
init data in board file.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways
when
devices get added to systems, making these strings constantly have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes
the
clock code wrong. Others have already said that this is wrong there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be removed,
the
device id should be automatically created by the phy core just to
make
things unique in sysfs, and no driver code should _ever_ be reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
to a big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure
we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
give the correct binding information to the PHY framework. I think we
can drop having this non-dt support in PHY framework? I see only one
platform (OMAP3) going to be needing this non-dt support and we can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns its
own id and we *don't* want to add any requirement that the ID must be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
*phy_init_data* in the v10 patch series.
OK, so the PHY device name would have a fixed part, passed as
platform data of the controller and a variable part appended
by the PHY core, depending on the number of registered PHYs ?
Then same PHY names would be passed as the PHY provider driver's
platform data ?
Then if there are 2 instances of the above (same names in platform
data) how would be determined which PHY controller is linked to
which PHY supplier ?
I guess you want each device instance to have different PHY device
names already in platform data ? That might work. We probably will
be focused mostly on DT anyway. It seem without DT we are trying
to find some layer that would allow us to couple relevant devices
and overcome driver core inconvenience that it provides to means
to identify specific devices in advance. :) Your proposal sounds
reasonable, however I might be missing some details or corner cases.
What about slightly altering the concept of v9 to pass a pointer to struct
device instead of device name inside phy_init_data?
As Felipe said, we don't want to pass pointers in platform_data
to/from random subsystems. We pass data, passing pointers would
be a total mess IMHO.
The problem is device might be created very late. (For example in omap4, usb2
phy device gets created when ocp2scp bus is probed). And we have to pass the
init data in board file.
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I
wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing
things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1,
phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change
and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup
methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned
manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id,
is
frought with fragility and will break in the future in various
ways
when
devices get added to systems, making these strings constantly
have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that
this
happens today with the clock code, doesn't make it right, it
makes
the
clock code wrong. Others have already said that this is wrong
there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be
removed,
the
device id should be automatically created by the phy core just
to
make
things unique in sysfs, and no driver code should _ever_ be
reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this
subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people
trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already
points
to a big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will
end up
adding similar infrastructure to the driver themselves to make
sure
we
don't end up with duplicate names in sysfs in case we have
multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we
can
give the correct binding information to the PHY framework. I think
we
can drop having this non-dt support in PHY framework? I see only
one
platform (OMAP3) going to be needing this non-dt support and we
can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we
lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns
its
own id and we *don't* want to add any requirement that the ID must
be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid
of
*phy_init_data* in the v10 patch series.
OK, so the PHY device name would have a fixed part, passed as
platform data of the controller and a variable part appended
by the PHY core, depending on the number of registered PHYs ?
Then same PHY names would be passed as the PHY provider driver's
platform data ?
Then if there are 2 instances of the above (same names in platform
data) how would be determined which PHY controller is linked to
which PHY supplier ?
I guess you want each device instance to have different PHY device
names already in platform data ? That might work. We probably will
be focused mostly on DT anyway. It seem without DT we are trying
to find some layer that would allow us to couple relevant devices
and overcome driver core inconvenience that it provides to means
to identify specific devices in advance. :) Your proposal sounds
reasonable, however I might be missing some details or corner cases.
What about slightly altering the concept of v9 to pass a pointer to
struct device instead of device name inside phy_init_data?
As Felipe said, we don't want to pass pointers in platform_data
to/from random subsystems. We pass data, passing pointers would
be a total mess IMHO.
Well, this
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
> > IMHO we need a lookup method for PHYs, just like for clocks,
> > regulators, PWMs or even i2c busses because there are complex cases
> > when passing just a name using platform data will not work. I would
> > second what Stephen said [1] and define a structure doing things in a
> > DT-like way.
> >
> > Example;
> >
> > [platform code]
> >
> > static const struct phy_lookup my_phy_lookup[] = {
> >
> > PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
>
> The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
> creating the device, the ids in the device name would change and
> PHY_LOOKUP wont be useful.
> >>>
> >>> I don't think this is a problem. All the existing lookup methods already
> >>> use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
> >>> can simply add a requirement that the ID must be assigned manually,
> >>> without using PLATFORM_DEVID_AUTO to use PHY lookup.
> >>
> >> And I'm saying that this idea, of using a specific name and id, is
> >> frought with fragility and will break in the future in various ways when
> >> devices get added to systems, making these strings constantly have to be
> >> kept up to date with different board configurations.
> >>
> >> People, NEVER, hardcode something like an id. The fact that this
> >> happens today with the clock code, doesn't make it right, it makes the
> >> clock code wrong. Others have already said that this is wrong there as
> >> well, as systems change and dynamic ids get used more and more.
> >>
> >> Let's not repeat the same mistakes of the past just because we refuse to
> >> learn from them...
> >>
> >> So again, the "find a phy by a string" functions should be removed, the
> >> device id should be automatically created by the phy core just to make
> >> things unique in sysfs, and no driver code should _ever_ be reliant on
> >> the number that is being created, and the pointer to the phy structure
> >> should be used everywhere instead.
> >>
> >> With those types of changes, I will consider merging this subsystem, but
> >> without them, sorry, I will not.
> >
> > I'll agree with Greg here, the very fact that we see people trying to
> > add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points to a
> > big problem in the framework.
> >
> > The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
> > adding similar infrastructure to the driver themselves to make sure we
> > don't end up with duplicate names in sysfs in case we have multiple
> > instances of the same IP in the SoC (or several of the same PCIe card).
> > I really don't want to go back to that.
>
> If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can give the
> correct binding information to the PHY framework. I think we can drop having
> this non-dt support in PHY framework? I see only one platform (OMAP3) going to
> be needing this non-dt support and we can use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex cases
when passing just a name using platform data will not work. I would
second what Stephen said [1] and define a structure doing things in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods already
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways when
devices get added to systems, making these strings constantly have to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes the
clock code wrong. Others have already said that this is wrong there as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we refuse to
learn from them...
So again, the find a phy by a string functions should be removed, the
device id should be automatically created by the phy core just to make
things unique in sysfs, and no driver code should _ever_ be reliant on
the number that is being created, and the pointer to the phy structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem, but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points to a
big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can give the
correct binding information to the PHY framework. I think we can drop having
this non-dt support in PHY framework? I see only one platform (OMAP3) going to
be needing this non-dt support and we can use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Tuesday 30 July 2013 12:41 PM, Felipe Balbi wrote:
> On Sun, Jul 21, 2013 at 08:46:53AM -0700, Greg KH wrote:
>> On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
>>> On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
Hi,
On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
> Hi,
>
> On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
>> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
>>> On Sat, 20 Jul 2013, Greg KH wrote:
>>> That should be passed using platform data.
>>
>> Ick, don't pass strings around, pass pointers. If you have
>> platform
>> data you can get to, then put the pointer there, don't use a
>> "name".
>
> I don't think I understood you here :-s We wont have phy pointer
> when we create the device for the controller no?(it'll be done in
> board file). Probably I'm missing something.
Why will you not have that pointer? You can't rely on the "name"
as
the device id will not match up, so you should be able to rely on
the pointer being in the structure that the board sets up, right?
Don't use names, especially as ids can, and will, change, that is
going
to cause big problems. Use pointers, this is C, we are supposed to
be
doing that :)
>>>
>>> Kishon, I think what Greg means is this: The name you are using
>>> must
>>> be stored somewhere in a data structure constructed by the board
>>> file,
>>> right? Or at least, associated with some data structure somehow.
>>> Otherwise the platform code wouldn't know which PHY hardware
>>> corresponded to a particular name.
>>>
>>> Greg's suggestion is that you store the address of that data
>>> structure
>>> in the platform data instead of storing the name string. Have the
>>> consumer pass the data structure's address when it calls phy_create,
>>> instead of passing the name. Then you don't have to worry about two
>>> PHYs accidentally ending up with the same name or any other similar
>>> problems.
>>
>> Close, but the issue is that whatever returns from phy_create()
>> should
>> then be used, no need to call any "find" functions, as you can just
>> use
>> the pointer that phy_create() returns. Much like all other class api
>> functions in the kernel work.
>
> I think there is a confusion here about who registers the PHYs.
>
> All platform code does is registering a platform/i2c/whatever device,
> which causes a driver (located in drivers/phy/) to be instantiated.
> Such drivers call phy_create(), usually in their probe() callbacks,
> so platform_code has no way (and should have no way, for the sake of
> layering) to get what phy_create() returns.
>>
>> Why not put pointers in the platform data structure that can hold these
>> pointers? I thought that is why we created those structures in the
>> first place. If not, what are they there for?
>
> heh, IMO we shouldn't pass pointers of any kind through platform_data,
> we want to pass data :-)
>
> Allowing to pass pointers through that, is one of the reasons which got
> us in such a big mess in ARM land, well it was much easier for a
> board-file/driver writer to pass a function pointer then to create a
> generic framework :-)
>
> IMHO we need a lookup method for PHYs, just like for clocks,
> regulators, PWMs or even i2c busses because there are complex cases
> when passing just a name using platform data will not work. I would
> second what Stephen said [1] and define a structure doing things in a
> DT-like way.
>
> Example;
>
> [platform code]
>
> static const struct phy_lookup my_phy_lookup[] = {
>
> PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
>>>
>>> I don't think this is a problem. All the existing lookup methods already
>>> use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
>>> can simply add a requirement that the ID must be assigned manually,
>>> without using PLATFORM_DEVID_AUTO to use PHY lookup.
>>
>> And I'm saying that this idea, of using a specific name and id, is
>> frought with fragility and will break in the future in various ways when
>> devices get added to systems, making these strings constantly have to be
>> kept up to date with different board configurations.
>>
>> People, NEVER, hardcode something like an id. The fact that this
>> happens today with the clock code, doesn't make it right, it makes the
>> clock code wrong. Others have already said that this is wrong there as
>> well, as systems change and dynamic ids get
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sun, Jul 21, 2013 at 08:46:53AM -0700, Greg KH wrote:
> On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
> > On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
> > > Hi,
> > >
> > > On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
> > > > Hi,
> > > >
> > > > On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
> > > >> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
> > > >>> On Sat, 20 Jul 2013, Greg KH wrote:
> > > >>> That should be passed using platform data.
> > > >>
> > > >> Ick, don't pass strings around, pass pointers. If you have
> > > >> platform
> > > >> data you can get to, then put the pointer there, don't use a
> > > >> "name".
> > > >
> > > > I don't think I understood you here :-s We wont have phy pointer
> > > > when we create the device for the controller no?(it'll be done in
> > > > board file). Probably I'm missing something.
> > >
> > > Why will you not have that pointer? You can't rely on the "name"
> > > as
> > > the device id will not match up, so you should be able to rely on
> > > the pointer being in the structure that the board sets up, right?
> > >
> > > Don't use names, especially as ids can, and will, change, that is
> > > going
> > > to cause big problems. Use pointers, this is C, we are supposed to
> > > be
> > > doing that :)
> > > >>>
> > > >>> Kishon, I think what Greg means is this: The name you are using
> > > >>> must
> > > >>> be stored somewhere in a data structure constructed by the board
> > > >>> file,
> > > >>> right? Or at least, associated with some data structure somehow.
> > > >>> Otherwise the platform code wouldn't know which PHY hardware
> > > >>> corresponded to a particular name.
> > > >>>
> > > >>> Greg's suggestion is that you store the address of that data
> > > >>> structure
> > > >>> in the platform data instead of storing the name string. Have the
> > > >>> consumer pass the data structure's address when it calls phy_create,
> > > >>> instead of passing the name. Then you don't have to worry about two
> > > >>> PHYs accidentally ending up with the same name or any other similar
> > > >>> problems.
> > > >>
> > > >> Close, but the issue is that whatever returns from phy_create()
> > > >> should
> > > >> then be used, no need to call any "find" functions, as you can just
> > > >> use
> > > >> the pointer that phy_create() returns. Much like all other class api
> > > >> functions in the kernel work.
> > > >
> > > > I think there is a confusion here about who registers the PHYs.
> > > >
> > > > All platform code does is registering a platform/i2c/whatever device,
> > > > which causes a driver (located in drivers/phy/) to be instantiated.
> > > > Such drivers call phy_create(), usually in their probe() callbacks,
> > > > so platform_code has no way (and should have no way, for the sake of
> > > > layering) to get what phy_create() returns.
>
> Why not put pointers in the platform data structure that can hold these
> pointers? I thought that is why we created those structures in the
> first place. If not, what are they there for?
heh, IMO we shouldn't pass pointers of any kind through platform_data,
we want to pass data :-)
Allowing to pass pointers through that, is one of the reasons which got
us in such a big mess in ARM land, well it was much easier for a
board-file/driver writer to pass a function pointer then to create a
generic framework :-)
> > > > IMHO we need a lookup method for PHYs, just like for clocks,
> > > > regulators, PWMs or even i2c busses because there are complex cases
> > > > when passing just a name using platform data will not work. I would
> > > > second what Stephen said [1] and define a structure doing things in a
> > > > DT-like way.
> > > >
> > > > Example;
> > > >
> > > > [platform code]
> > > >
> > > > static const struct phy_lookup my_phy_lookup[] = {
> > > >
> > > > PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
> > >
> > > The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
> > > creating the device, the ids in the device name would change and
> > > PHY_LOOKUP wont be useful.
> >
> > I don't think this is a problem. All the existing lookup methods already
> > use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
> > can simply add a requirement that the ID must be assigned manually,
> > without using PLATFORM_DEVID_AUTO to use PHY lookup.
>
> And I'm saying that this idea, of using a specific name and id, is
> frought with fragility and will break in the future in various ways when
> devices get added to systems, making these strings constantly have to be
> kept up to date with different board configurations.
>
> People, NEVER, hardcode something like an id. The fact that this
> happens today with the clock code, doesn't make it right, it makes the
> clock code wrong. Others have already
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sun, Jul 21, 2013 at 08:46:53AM -0700, Greg KH wrote:
On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
Hi,
On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
Hi,
On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
On Sat, 20 Jul 2013, Greg KH wrote:
That should be passed using platform data.
Ick, don't pass strings around, pass pointers. If you have
platform
data you can get to, then put the pointer there, don't use a
name.
I don't think I understood you here :-s We wont have phy pointer
when we create the device for the controller no?(it'll be done in
board file). Probably I'm missing something.
Why will you not have that pointer? You can't rely on the name
as
the device id will not match up, so you should be able to rely on
the pointer being in the structure that the board sets up, right?
Don't use names, especially as ids can, and will, change, that is
going
to cause big problems. Use pointers, this is C, we are supposed to
be
doing that :)
Kishon, I think what Greg means is this: The name you are using
must
be stored somewhere in a data structure constructed by the board
file,
right? Or at least, associated with some data structure somehow.
Otherwise the platform code wouldn't know which PHY hardware
corresponded to a particular name.
Greg's suggestion is that you store the address of that data
structure
in the platform data instead of storing the name string. Have the
consumer pass the data structure's address when it calls phy_create,
instead of passing the name. Then you don't have to worry about two
PHYs accidentally ending up with the same name or any other similar
problems.
Close, but the issue is that whatever returns from phy_create()
should
then be used, no need to call any find functions, as you can just
use
the pointer that phy_create() returns. Much like all other class api
functions in the kernel work.
I think there is a confusion here about who registers the PHYs.
All platform code does is registering a platform/i2c/whatever device,
which causes a driver (located in drivers/phy/) to be instantiated.
Such drivers call phy_create(), usually in their probe() callbacks,
so platform_code has no way (and should have no way, for the sake of
layering) to get what phy_create() returns.
Why not put pointers in the platform data structure that can hold these
pointers? I thought that is why we created those structures in the
first place. If not, what are they there for?
heh, IMO we shouldn't pass pointers of any kind through platform_data,
we want to pass data :-)
Allowing to pass pointers through that, is one of the reasons which got
us in such a big mess in ARM land, well it was much easier for a
board-file/driver writer to pass a function pointer then to create a
generic framework :-)
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex cases
when passing just a name using platform data will not work. I would
second what Stephen said [1] and define a structure doing things in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods already
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways when
devices get added to systems, making these strings constantly have to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes the
clock code wrong. Others have already said that this is wrong there as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we refuse to
learn from them...
So again, the find a phy by a string functions should be removed, the
device id should be automatically created by the phy core just to make
things unique in sysfs, and no driver code should _ever_ be reliant on
the number that is being created, and the pointer
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Tuesday 30 July 2013 12:41 PM, Felipe Balbi wrote:
On Sun, Jul 21, 2013 at 08:46:53AM -0700, Greg KH wrote:
On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
Hi,
On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
Hi,
On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
On Sat, 20 Jul 2013, Greg KH wrote:
That should be passed using platform data.
Ick, don't pass strings around, pass pointers. If you have
platform
data you can get to, then put the pointer there, don't use a
name.
I don't think I understood you here :-s We wont have phy pointer
when we create the device for the controller no?(it'll be done in
board file). Probably I'm missing something.
Why will you not have that pointer? You can't rely on the name
as
the device id will not match up, so you should be able to rely on
the pointer being in the structure that the board sets up, right?
Don't use names, especially as ids can, and will, change, that is
going
to cause big problems. Use pointers, this is C, we are supposed to
be
doing that :)
Kishon, I think what Greg means is this: The name you are using
must
be stored somewhere in a data structure constructed by the board
file,
right? Or at least, associated with some data structure somehow.
Otherwise the platform code wouldn't know which PHY hardware
corresponded to a particular name.
Greg's suggestion is that you store the address of that data
structure
in the platform data instead of storing the name string. Have the
consumer pass the data structure's address when it calls phy_create,
instead of passing the name. Then you don't have to worry about two
PHYs accidentally ending up with the same name or any other similar
problems.
Close, but the issue is that whatever returns from phy_create()
should
then be used, no need to call any find functions, as you can just
use
the pointer that phy_create() returns. Much like all other class api
functions in the kernel work.
I think there is a confusion here about who registers the PHYs.
All platform code does is registering a platform/i2c/whatever device,
which causes a driver (located in drivers/phy/) to be instantiated.
Such drivers call phy_create(), usually in their probe() callbacks,
so platform_code has no way (and should have no way, for the sake of
layering) to get what phy_create() returns.
Why not put pointers in the platform data structure that can hold these
pointers? I thought that is why we created those structures in the
first place. If not, what are they there for?
heh, IMO we shouldn't pass pointers of any kind through platform_data,
we want to pass data :-)
Allowing to pass pointers through that, is one of the reasons which got
us in such a big mess in ARM land, well it was much easier for a
board-file/driver writer to pass a function pointer then to create a
generic framework :-)
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex cases
when passing just a name using platform data will not work. I would
second what Stephen said [1] and define a structure doing things in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods already
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways when
devices get added to systems, making these strings constantly have to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes the
clock code wrong. Others have already said that this is wrong there as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we refuse to
learn from them...
So again, the find a phy by a string functions should be removed, the
device id should be automatically created by the phy core just to make
things unique in sysfs, and no driver code should _ever_ be reliant on
the number that is being created, and the pointer to the phy structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem, but
without them, sorry, I will not.
I'll agree with Greg
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thu, Jul 25, 2013 at 01:00:49PM +0200, Arnd Bergmann wrote: > I'm not saying that we can't support legacy board files with the common > PHY framework, but I'd expect things to be much easier if we focus on those > platforms that are actively being worked on for now, to bring an end to the > pointless API discussion. Well, it seemed like Greg's concerns had already been addressed anyway. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Arnd, On Thursday 25 July 2013 13:00:49 Arnd Bergmann wrote: > On Thursday 25 July 2013, Laurent Pinchart wrote: > > On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: > > > On Tuesday 23 July 2013, Tomasz Figa wrote: > > > > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > > > > > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > > > > Where would you want to have those phy_address arrays stored? > > > > > > There are no board files when booting with DT. Not even saying > > > > > > that you don't need to use any hacky schemes like this when you > > > > > > have DT that nicely specifies relations between devices. > > > > > > > > > > If everybody agrees DT has a nice scheme for specifying relations > > > > > between devices, why not use that same scheme in the PHY core? > > > > > > > > It is already used, for cases when consumer device has a DT node > > > > attached. In non-DT case this kind lookup translates loosely to > > > > something that is being done in regulator framework - you can't bind > > > > devices by pointers, because you don't have those pointers, so you > > > > need to use device names. > > > > > > Sorry for jumping in to the middle of the discussion, but why does a new > > > framework even bother defining an interface for board files? > > > > > > Can't we just drop any interfaces for platform data passing in the phy > > > framework and put the burden of adding those to anyone who actually > > > needs them? All the platforms we are concerned with here (exynos and > > > omap, plus new platforms) can be booted using DT anyway. > > > > What about non-DT architectures such as MIPS (still widely used in > > consumer networking equipments from what I've heard) ? > > * Vendors of such equipment have started moving on to ARM (e.g. Broadcom > bcm47xx) > * Some of the modern MIPS platforms are now using DT > * Legacy platforms probably won't migrate to either DT or the generic PHY > framework > > I'm not saying that we can't support legacy board files with the common PHY > framework, but I'd expect things to be much easier if we focus on those > platforms that are actively being worked on for now, to bring an end to the > pointless API discussion. Fair enough :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Laurent Pinchart wrote: > On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: > > On Tuesday 23 July 2013, Tomasz Figa wrote: > > > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > > > > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > > > Where would you want to have those phy_address arrays stored? There > > > > > are no board files when booting with DT. Not even saying that you > > > > > don't need to use any hacky schemes like this when you have DT that > > > > > nicely specifies relations between devices. > > > > > > > > If everybody agrees DT has a nice scheme for specifying relations > > > > between devices, why not use that same scheme in the PHY core? > > > > > > It is already used, for cases when consumer device has a DT node attached. > > > In non-DT case this kind lookup translates loosely to something that is > > > being done in regulator framework - you can't bind devices by pointers, > > > because you don't have those pointers, so you need to use device names. > > > > Sorry for jumping in to the middle of the discussion, but why does a new > > framework even bother defining an interface for board files? > > > > Can't we just drop any interfaces for platform data passing in the phy > > framework and put the burden of adding those to anyone who actually needs > > them? All the platforms we are concerned with here (exynos and omap, plus > > new platforms) can be booted using DT anyway. > > What about non-DT architectures such as MIPS (still widely used in consumer > networking equipments from what I've heard) ? * Vendors of such equipment have started moving on to ARM (e.g. Broadcom bcm47xx) * Some of the modern MIPS platforms are now using DT * Legacy platforms probably won't migrate to either DT or the generic PHY framework I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Arnd, On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: > On Tuesday 23 July 2013, Tomasz Figa wrote: > > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > > > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > > Where would you want to have those phy_address arrays stored? There > > > > are no board files when booting with DT. Not even saying that you > > > > don't need to use any hacky schemes like this when you have DT that > > > > nicely specifies relations between devices. > > > > > > If everybody agrees DT has a nice scheme for specifying relations > > > between devices, why not use that same scheme in the PHY core? > > > > It is already used, for cases when consumer device has a DT node attached. > > In non-DT case this kind lookup translates loosely to something that is > > being done in regulator framework - you can't bind devices by pointers, > > because you don't have those pointers, so you need to use device names. > > Sorry for jumping in to the middle of the discussion, but why does a *new* > framework even bother defining an interface for board files? > > Can't we just drop any interfaces for platform data passing in the phy > framework and put the burden of adding those to anyone who actually needs > them? All the platforms we are concerned with here (exynos and omap, plus > new platforms) can be booted using DT anyway. What about non-DT architectures such as MIPS (still widely used in consumer networking equipments from what I've heard) ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On 07/24/2013 08:32 PM, Arnd Bergmann wrote: > On Tuesday 23 July 2013, Tomasz Figa wrote: >> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: >>> On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. >>> >>> If everybody agrees DT has a nice scheme for specifying relations >>> between devices, why not use that same scheme in the PHY core? >> >> It is already used, for cases when consumer device has a DT node attached. >> In non-DT case this kind lookup translates loosely to something that is >> being done in regulator framework - you can't bind devices by pointers, >> because you don't have those pointers, so you need to use device names. >> > > Sorry for jumping in to the middle of the discussion, but why does a *new* > framework even bother defining an interface for board files? > > Can't we just drop any interfaces for platform data passing in the phy > framework and put the burden of adding those to anyone who actually needs > them? All the platforms we are concerned with here (exynos and omap, > plus new platforms) can be booted using DT anyway. Indeed, I was also a bit surprised we still need non-dt support, since migration to this generic PHY framework in case of exynos was solely part of migration of the whole platform to DT. Two of the drivers that are being converted are also used on s5pv210, but there is currently no boards in mainline that would use devices covered by those drivers and s5pv210 will very likely get DT support in v3.13 anyway. But it seems omap still needs non-dt support in the PHY framework. --- Thanks, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Wed, Jul 24, 2013 at 08:32:03PM +0200, Arnd Bergmann wrote: > Sorry for jumping in to the middle of the discussion, but why does a *new* > framework even bother defining an interface for board files? > Can't we just drop any interfaces for platform data passing in the phy > framework and put the burden of adding those to anyone who actually needs > them? All the platforms we are concerned with here (exynos and omap, > plus new platforms) can be booted using DT anyway. There's a bunch of non-DT architectures that are in active use (blackfin for example) and I'd really hope that this is useful for some of them. The pushback here was about the fact that the subsystem was doing odd things with selecting device names which is odd in itself, I don't know if that had bled over into the DT bindings but it sounded like it might've done so. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Kishon Vijay Abraham I wrote: > On Thursday 25 July 2013 12:02 AM, Arnd Bergmann wrote: > > On Tuesday 23 July 2013, Tomasz Figa wrote: > >> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > >>> On Tue, 23 Jul 2013, Tomasz Figa wrote: > Where would you want to have those phy_address arrays stored? There > are no board files when booting with DT. Not even saying that you > don't need to use any hacky schemes like this when you have DT that > nicely specifies relations between devices. > >>> > >>> If everybody agrees DT has a nice scheme for specifying relations > >>> between devices, why not use that same scheme in the PHY core? > >> > >> It is already used, for cases when consumer device has a DT node attached. > >> In non-DT case this kind lookup translates loosely to something that is > >> being done in regulator framework - you can't bind devices by pointers, > >> because you don't have those pointers, so you need to use device names. > >> > > > > Sorry for jumping in to the middle of the discussion, but why does a new > > framework even bother defining an interface for board files? > > > > Can't we just drop any interfaces for platform data passing in the phy > > framework and put the burden of adding those to anyone who actually needs > > them? All the platforms we are concerned with here (exynos and omap, > > plus new platforms) can be booted using DT anyway. > > The OMAP3 platforms still needs to be supported for non-dt :-s Can't you leave the existing PHY handling for legacy OMAP3 USB PHY until they are all converted? I don't expect that to take a long time now that the OMAP4 board files have been removed. Are there still drivers without DT bindings that hold up the removal of the OMAP3 board files? Otherwise I'd suggest delaying the phy subsystem by another merge window, until that is resolved. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Kishon Vijay Abraham I wrote: On Thursday 25 July 2013 12:02 AM, Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a new framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. The OMAP3 platforms still needs to be supported for non-dt :-s Can't you leave the existing PHY handling for legacy OMAP3 USB PHY until they are all converted? I don't expect that to take a long time now that the OMAP4 board files have been removed. Are there still drivers without DT bindings that hold up the removal of the OMAP3 board files? Otherwise I'd suggest delaying the phy subsystem by another merge window, until that is resolved. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Wed, Jul 24, 2013 at 08:32:03PM +0200, Arnd Bergmann wrote: Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. There's a bunch of non-DT architectures that are in active use (blackfin for example) and I'd really hope that this is useful for some of them. The pushback here was about the fact that the subsystem was doing odd things with selecting device names which is odd in itself, I don't know if that had bled over into the DT bindings but it sounded like it might've done so. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On 07/24/2013 08:32 PM, Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. Indeed, I was also a bit surprised we still need non-dt support, since migration to this generic PHY framework in case of exynos was solely part of migration of the whole platform to DT. Two of the drivers that are being converted are also used on s5pv210, but there is currently no boards in mainline that would use devices covered by those drivers and s5pv210 will very likely get DT support in v3.13 anyway. But it seems omap still needs non-dt support in the PHY framework. --- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Arnd, On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. What about non-DT architectures such as MIPS (still widely used in consumer networking equipments from what I've heard) ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Laurent Pinchart wrote: On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a new framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. What about non-DT architectures such as MIPS (still widely used in consumer networking equipments from what I've heard) ? * Vendors of such equipment have started moving on to ARM (e.g. Broadcom bcm47xx) * Some of the modern MIPS platforms are now using DT * Legacy platforms probably won't migrate to either DT or the generic PHY framework I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Arnd, On Thursday 25 July 2013 13:00:49 Arnd Bergmann wrote: On Thursday 25 July 2013, Laurent Pinchart wrote: On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a new framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. What about non-DT architectures such as MIPS (still widely used in consumer networking equipments from what I've heard) ? * Vendors of such equipment have started moving on to ARM (e.g. Broadcom bcm47xx) * Some of the modern MIPS platforms are now using DT * Legacy platforms probably won't migrate to either DT or the generic PHY framework I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. Fair enough :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thu, Jul 25, 2013 at 01:00:49PM +0200, Arnd Bergmann wrote: I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. Well, it seemed like Greg's concerns had already been addressed anyway. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 July 2013, Tomasz Figa wrote: > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > Where would you want to have those phy_address arrays stored? There > > > are no board files when booting with DT. Not even saying that you > > > don't need to use any hacky schemes like this when you have DT that > > > nicely specifies relations between devices. > > > > If everybody agrees DT has a nice scheme for specifying relations > > between devices, why not use that same scheme in the PHY core? > > It is already used, for cases when consumer device has a DT node attached. > In non-DT case this kind lookup translates loosely to something that is > being done in regulator framework - you can't bind devices by pointers, > because you don't have those pointers, so you need to use device names. > Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 12:44:23PM -0700, Greg KH wrote: > On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote: > > statement. In any case this is why the APIs doing lookups do the > > lookups in the context of the requesting device - devices ask for > > whatever name they use locally. > What do you mean by "locally"? Within themselves - for example a regulator consumer asks for a given supply on the device in terms of the supply names the device has. > The problem with the api was that the phy core wanted a id and a name to > create a phy, and then later other code was doing a "lookup" based on > the name and id (mushed together), because it "knew" that this device > was the one it wanted. Ah, that sounds like the API is missing a component to link things together. But I could be wrong. What I would expect to see is that the consumer says "I want the PHY called X" and the PHY driver says "I provide this set of PHYs" with a layer in between that plugs those together. This would normally involve talking about the parent device rather than the PHY itself. > I think, that if you create a device, then just carry around the pointer > to that device (in this case a phy) and pass it to whatever other code > needs it. No need to do lookups on "known names" or anything else, just > normal pointers, with no problems for multiple devices, busses, or > naming issues. I think you're not really talking about the lookup API at all here but rather about one way in which the matching code can be written. What everything *really* wants to do is work in terms of resources namespaced within struct devices since every bit of hardware in the system should have one of those it can use and if you have a struct device you can do useful things like call dev_printk() and find the device tree data to do device tree based lookups. Unfortunately for a number of buses even when statically registering the struct device doesn't get allocated until the device is probed so what everyone fell back on doing was using dev_name() in cases where the struct device wasn't there yet, or just always using it for consistency since for most of the affected buses dev_name() is fixed for human interface reasons. I think this is the issue you're concerned about here since if the dev_name() is dynamically allocated this breaks down. This only affects board files, DT and ACPI can both use their own data structures to do the mapping. I had thought you were talking about picking the names that the consumers use (which isn't actually that big a deal, it's just a bit annoying for the clock API). > > It's adding platform data in the first place that gets tedious - and of > > course there's also DT and ACPI to worry about, it's not just a case of > > platform data and then you're done. Pushing the lookup into library > > code means that drivers don't have to worry about any of this stuff. > I agree, so just pass around the pointer to the phy and all is good. No > need to worry about DT or ACPI or anything else. No, in practice passing around the pointer gets tricky if you're using something other than board files (or even are doing any kind of dynamic stuff with board files) since the two devices need to find each other and if you're using platform data then the code doing the matching has to know about the platform data for every device it might need to match which is just miserable. Something would need to do something like allocate the PHY objects and then arrange for them to be passed to both provider and consumer devices prior to those being registered, knowing where to place the pointers in the platform data for each device. This is straightforward with board files but not otherwise, people have tried this before. > > For most of the APIs doing this there is a clear and unambiguous name in > > the hardware that can be used (and for hardware process reasons is > > unlikely to get changed). The major exception to this is the clock API > > since it is relatively rare to have clear, segregated IP level > > information for IPs baked into larger chips. The other APIs tend to be > > establishing chip to chip links. > The clock api is having problems with multiple "names" due to dynamic > devices from what I was told. I want to prevent the PHY interface from > having that same issue. I think the underlying issue here is that we don't have a good enough general way for board files (or other C code but mostly them) to talk about devices prior to their being registered - rather than have the pointer you're talking about be the PHY object itself have the pointer be something which allows us to match the struct device when it's created. This should be transparent to drivers and would be usable by all the existing APIs. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > If you want to keep the phy struct completely separate from the > > > board > > > file, there's an easy way to do it. Let's say the board file knows > > > about N different PHYs in the system. Then you define an array of N > > > pointers to phys: > > > > > > struct phy *(phy_address[N]); > > > > > > In the platform data for both PHY j and its controller, store > > > > > > _address[j]. The PHY provider passes this cookie to phy_create: > > > cookie = pdev->dev.platform_data; > > > ret = phy_create(phy, cookie); > > > > > > and phy_create simply stores: *cookie = phy. The PHY consumer does > > > > > > much the same the same thing: > > > cookie = pdev->dev.platform_data; > > > phy = phy_get(cookie); > > > > > > phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. > > > > OK, this can work. Again, just technically, because it's rather ugly. > > There's no reason the phy_address things have to be arrays. A separate > individual pointer for each PHY would work just as well. > > > Where would you want to have those phy_address arrays stored? There > > are no board files when booting with DT. Not even saying that you > > don't need to use any hacky schemes like this when you have DT that > > nicely specifies relations between devices. > > If everybody agrees DT has a nice scheme for specifying relations > between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. > > Anyway, board file should not be considered as a method to exchange > > data between drivers. It should be used only to pass data from it to > > drivers, not the other way. Ideally all data in a board file should > > be marked as const and __init and dropped after system > > initialization. > > The phy_address things don't have to be defined or allocated in the > board file; they could be set up along with the platform data. There is no platform data when booting with DT. > In any case, this was simply meant to be a suggestion to show that it > is relatively easy to do what you need without using name or ID > strings. Sure. It's good to have different options discussed as well. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 11:05:48PM +0200, Tomasz Figa wrote: > > That's not so bad, as long as you let the phy core use whatever name it > > wants for the device when it registers it with sysfs. > > Yes, in regulator core consumer names are completely separated from this. > Regulator core simply assigns a sequential integer ID to each regulator > and registers /sys/class/regulator/regulator.ID for each regulator. Yes, that's fine. > > Use the name you > > are requesting as a "tag" or some such "hint" as to what the phy can be > > looked up by. > > > > Good luck handling duplicate "tags" :) > > The tag alone is not a key. Lookup key consists of two components, > consumer device name and consumer tag. What kind of duplicate tags can be > a problem here? Ok, I didn't realize it looked at both parts, that makes sense, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 13:50:07 Greg KH wrote:
> On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
> > > On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > > > > You don't "know" the id of the device you are looking up, due to
> > > > > multiple devices being in the system (dynamic ids, look back
> > > > > earlier
> > > > > in
> > > > > this thread for details about that.)
> > > >
> > > > I got copied in very late so don't have most of the thread I'm
> > > > afraid,
> > > > I did try looking at web archives but didn't see a clear problem
> > > > statement. In any case this is why the APIs doing lookups do the
> > > > lookups in the context of the requesting device - devices ask for
> > > > whatever name they use locally.
> > >
> > > What do you mean by "locally"?
> > >
> > > The problem with the api was that the phy core wanted a id and a
> > > name to create a phy, and then later other code was doing a
> > > "lookup" based on the name and id (mushed together), because it
> > > "knew" that this device was the one it wanted.
> > >
> > > Just like the clock api, which, for multiple devices, has proven to
> > > cause problems. I don't want to see us accept an api that we know
> > > has
> > > issues in it now, I'd rather us fix it up properly.
> > >
> > > Subsystems should be able to create ids how ever they want to, and
> > > not
> > > rely on the code calling them to specify the names of the devices
> > > that
> > > way, otherwise the api is just too fragile.
> > >
> > > I think, that if you create a device, then just carry around the
> > > pointer to that device (in this case a phy) and pass it to whatever
> > > other code needs it. No need to do lookups on "known names" or
> > > anything else, just normal pointers, with no problems for multiple
> > > devices, busses, or naming issues.
> >
> > PHY object is not a device, it is something that a device driver
> > creates (one or more instances of) when it is being probed.
>
> But you created a 'struct device' for it, so I think of it as a "device"
> be it "virtual" or "real" :)
Keep in mind that those virtual devices are created by PHY driver bound to
a real device and one real device can have multiple virtual devices behind
it.
> > You don't have a clean way to export this PHY object to other driver,
> > other than keeping this PHY on a list inside PHY core with some
> > well-known ID (e.g. device name + consumer port name/index, like in
> > regulator core) and then to use this well-known ID inside consumer
> > driver as a lookup key passed to phy_get();
> >
> > Actually I think for PHY case, exactly the same way as used for
> > regulators might be completely fine:
> >
> > 1. Each PHY would have some kind of platform, non-unique name, that is
> > just used to print some messages (like the platform/board name of a
> > regulator).
> > 2. Each PHY would have an array of consumers. Consumer specifier would
> > consist of consumer device name and consumer port name - just like in
> > regulator subsystem.
> > 3. PHY driver receives an array of, let's say, phy_init_data inside
> > its
> > platform data that it would use to register its PHYs.
> > 4. Consumer drivers would have constant consumer port names and
> > wouldn't receive any information about PHYs from platform code.
> >
> > Code example:
> >
> > [Board file]
> >
> > static const struct phy_consumer_data usb_20_phy0_consumers[] = {
> >
> > {
> >
> > .devname = "foo-ehci",
> > .port = "usbphy",
> >
> > },
> >
> > };
> >
> > static const struct phy_consumer_data usb_20_phy1_consumers[] = {
> >
> > {
> >
> > .devname = "foo-otg",
> > .port = "otgphy",
> >
> > },
> >
> > };
> >
> > static const struct phy_init_data my_phys[] = {
> >
> > {
> >
> > .name = "USB 2.0 PHY 0",
> > .consumers = usb_20_phy0_consumers,
> > .num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
> >
> > },
> > {
> >
> > .name = "USB 2.0 PHY 1",
> > .consumers = usb_20_phy1_consumers,
> > .num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
> >
> > },
> > { }
> >
> > };
> >
> > static const struct platform_device usb_phy_pdev = {
> >
> > .name = "foo-usbphy",
> > .id = -1,
> > .dev = {
> >
> > .platform_data = my_phys,
> >
> > },
> >
> > };
> >
> > [PHY driver]
> >
> > static int foo_usbphy_probe(pdev)
> > {
> >
> > struct foo_usbphy *foo;
> > struct phy_init_data *init_data = pdev->dev.platform_data;
> > /* ... */
> > // for each PHY in init_data {
> >
> > phy_register(>phy[i], _data[i]);
> >
> > // }
> > /* ... */
> >
> > }
> >
> > [EHCI driver]
> >
> > static int foo_ehci_probe(pdev)
> > {
> >
> > struct phy *phy;
> > /* ... */
> >
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote: > > If you want to keep the phy struct completely separate from the board > > file, there's an easy way to do it. Let's say the board file knows > > about N different PHYs in the system. Then you define an array of N > > pointers to phys: > > > > struct phy *(phy_address[N]); > > > > In the platform data for both PHY j and its controller, store > > _address[j]. The PHY provider passes this cookie to phy_create: > > > > cookie = pdev->dev.platform_data; > > ret = phy_create(phy, cookie); > > > > and phy_create simply stores: *cookie = phy. The PHY consumer does > > much the same the same thing: > > > > cookie = pdev->dev.platform_data; > > phy = phy_get(cookie); > > > > phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. > > OK, this can work. Again, just technically, because it's rather ugly. There's no reason the phy_address things have to be arrays. A separate individual pointer for each PHY would work just as well. > Where would you want to have those phy_address arrays stored? There are no > board files when booting with DT. Not even saying that you don't need to > use any hacky schemes like this when you have DT that nicely specifies > relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? > Anyway, board file should not be considered as a method to exchange data > between drivers. It should be used only to pass data from it to drivers, > not the other way. Ideally all data in a board file should be marked as > const and __init and dropped after system initialization. The phy_address things don't have to be defined or allocated in the board file; they could be set up along with the platform data. In any case, this was simply meant to be a suggestion to show that it is relatively easy to do what you need without using name or ID strings. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 16:53:55 Alan Stern wrote: > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > That's what I was going to suggest too. The struct phy is defined > > > in > > > the board file, which already knows about all the PHYs that exist in > > > the system. (Or perhaps it is allocated dynamically, so that when > > > many > > > board files are present in the same kernel, only the entries listed > > > in > > > the board file for the current system get created.) > > > > Well, such dynamic allocation is a must. We don't accept > > non-multiplatform aware code anymore, not even saying about > > multiboard. > > > > > Then the > > > structure's address is stored in the platform data and made > > > available > > > to both the provider and the consumer. > > > > Yes, technically this can work. You would still have to perform some > > kind of synchronization to make sure that the PHY bound to this > > structure is actually present. This is again technically doable (e.g. > > a list of registered struct phys inside PHY core). > > The synchronization takes place inside phy_get. If phy_create hasn't > been called for this structure by the time phy_get runs, phy_get will > return an error. Yes, this is the solution that I had in mind when saying that this is doable. > > > Even though the struct phy is defined (or allocated) in the board > > > file, > > > its contents don't get filled in until the PHY driver provides the > > > details. > > > > You can't assure this. Board file is free to do whatever it wants with > > this struct. A clean solution would prevent this. > > I'm not sure what you mean here. Of course I can't prevent a board > file from messing up a data structure. I can't prevent it from causing > memory access violations either; in fact, I can't prevent any bugs in > other people's code. > > Besides, why do you say the board file is free to do whatever it wants > with the struct phy? Currently the struct phy is created by the PHY > provider and the PHY core, right? It's not even mentioned in the board > file. I mean, if you have a struct type of which full declaration is available for some code, this code can access any memeber of it without any hacks, which is not something that we want to have in board files. The phy struct should be opaque for them. > > > > It's technically correct, but quality of this solution isn't > > > > really > > > > nice, because it's a layering violation (at least if I understood > > > > what you mean). This is because you need to have full definition > > > > of > > > > struct phy in board file and a structure that is used as private > > > > data > > > > in PHY core comes from platform code. > > > > > > You don't have to have a full definition in the board file. Just a > > > partial definition -- most of the contents can be filled in later, > > > when > > > the PHY driver is ready to store the private data. > > > > > > It's not a layering violation for one region of the kernel to store > > > private data in a structure defined by another part of the kernel. > > > This happens all the time (e.g., dev_set_drvdata). > > > > Not really. The phy struct is something that _is_ private data of PHY > > subsystem, not something that can store private data of PHY subsystem > > (sure it can store private data of particular PHY driver, but that's > > another story) and only PHY subsystem should have access to its > > contents. > If you want to keep the phy struct completely separate from the board > file, there's an easy way to do it. Let's say the board file knows > about N different PHYs in the system. Then you define an array of N > pointers to phys: > > struct phy *(phy_address[N]); > > In the platform data for both PHY j and its controller, store > _address[j]. The PHY provider passes this cookie to phy_create: > > cookie = pdev->dev.platform_data; > ret = phy_create(phy, cookie); > > and phy_create simply stores: *cookie = phy. The PHY consumer does > much the same the same thing: > > cookie = pdev->dev.platform_data; > phy = phy_get(cookie); > > phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. OK, this can work. Again, just technically, because it's rather ugly. > > By the way, we need to consider other cases here as well, for example > > it would be nice to have a single phy_get() function that works for > > both non- DT and DT cases to make the consumer driver not have to > > worry whether it's being probed from DT or not. > > You ought to be able to adapt this scheme to work with DT. Maybe by > having multiple "phy_address" arrays. Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. Anyway, board file should not be considered as a method to exchange data between drivers. It should be used only to
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote: > > That's what I was going to suggest too. The struct phy is defined in > > the board file, which already knows about all the PHYs that exist in > > the system. (Or perhaps it is allocated dynamically, so that when many > > board files are present in the same kernel, only the entries listed in > > the board file for the current system get created.) > > Well, such dynamic allocation is a must. We don't accept non-multiplatform > aware code anymore, not even saying about multiboard. > > > Then the > > structure's address is stored in the platform data and made available > > to both the provider and the consumer. > > Yes, technically this can work. You would still have to perform some kind > of synchronization to make sure that the PHY bound to this structure is > actually present. This is again technically doable (e.g. a list of > registered struct phys inside PHY core). The synchronization takes place inside phy_get. If phy_create hasn't been called for this structure by the time phy_get runs, phy_get will return an error. > > Even though the struct phy is defined (or allocated) in the board file, > > its contents don't get filled in until the PHY driver provides the > > details. > > You can't assure this. Board file is free to do whatever it wants with > this struct. A clean solution would prevent this. I'm not sure what you mean here. Of course I can't prevent a board file from messing up a data structure. I can't prevent it from causing memory access violations either; in fact, I can't prevent any bugs in other people's code. Besides, why do you say the board file is free to do whatever it wants with the struct phy? Currently the struct phy is created by the PHY provider and the PHY core, right? It's not even mentioned in the board file. > > > It's technically correct, but quality of this solution isn't really > > > nice, because it's a layering violation (at least if I understood > > > what you mean). This is because you need to have full definition of > > > struct phy in board file and a structure that is used as private data > > > in PHY core comes from platform code. > > > > You don't have to have a full definition in the board file. Just a > > partial definition -- most of the contents can be filled in later, when > > the PHY driver is ready to store the private data. > > > > It's not a layering violation for one region of the kernel to store > > private data in a structure defined by another part of the kernel. > > This happens all the time (e.g., dev_set_drvdata). > > Not really. The phy struct is something that _is_ private data of PHY > subsystem, not something that can store private data of PHY subsystem > (sure it can store private data of particular PHY driver, but that's > another story) and only PHY subsystem should have access to its contents. If you want to keep the phy struct completely separate from the board file, there's an easy way to do it. Let's say the board file knows about N different PHYs in the system. Then you define an array of N pointers to phys: struct phy *(phy_address[N]); In the platform data for both PHY j and its controller, store _address[j]. The PHY provider passes this cookie to phy_create: cookie = pdev->dev.platform_data; ret = phy_create(phy, cookie); and phy_create simply stores: *cookie = phy. The PHY consumer does much the same the same thing: cookie = pdev->dev.platform_data; phy = phy_get(cookie); phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. > By the way, we need to consider other cases here as well, for example it > would be nice to have a single phy_get() function that works for both non- > DT and DT cases to make the consumer driver not have to worry whether it's > being probed from DT or not. You ought to be able to adapt this scheme to work with DT. Maybe by having multiple "phy_address" arrays. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
> On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
> > On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > > > You don't "know" the id of the device you are looking up, due to
> > > > multiple devices being in the system (dynamic ids, look back earlier
> > > > in
> > > > this thread for details about that.)
> > >
> > > I got copied in very late so don't have most of the thread I'm afraid,
> > > I did try looking at web archives but didn't see a clear problem
> > > statement. In any case this is why the APIs doing lookups do the
> > > lookups in the context of the requesting device - devices ask for
> > > whatever name they use locally.
> >
> > What do you mean by "locally"?
> >
> > The problem with the api was that the phy core wanted a id and a name to
> > create a phy, and then later other code was doing a "lookup" based on
> > the name and id (mushed together), because it "knew" that this device
> > was the one it wanted.
> >
> > Just like the clock api, which, for multiple devices, has proven to
> > cause problems. I don't want to see us accept an api that we know has
> > issues in it now, I'd rather us fix it up properly.
> >
> > Subsystems should be able to create ids how ever they want to, and not
> > rely on the code calling them to specify the names of the devices that
> > way, otherwise the api is just too fragile.
> >
> > I think, that if you create a device, then just carry around the pointer
> > to that device (in this case a phy) and pass it to whatever other code
> > needs it. No need to do lookups on "known names" or anything else,
> > just normal pointers, with no problems for multiple devices, busses, or
> > naming issues.
>
> PHY object is not a device, it is something that a device driver creates
> (one or more instances of) when it is being probed.
But you created a 'struct device' for it, so I think of it as a "device"
be it "virtual" or "real" :)
> You don't have a clean way to export this PHY object to other driver,
> other than keeping this PHY on a list inside PHY core with some
> well-known ID (e.g. device name + consumer port name/index, like in
> regulator core) and then to use this well-known ID inside consumer
> driver as a lookup key passed to phy_get();
>
> Actually I think for PHY case, exactly the same way as used for
> regulators might be completely fine:
>
> 1. Each PHY would have some kind of platform, non-unique name, that is
> just used to print some messages (like the platform/board name of a
> regulator).
> 2. Each PHY would have an array of consumers. Consumer specifier would
> consist of consumer device name and consumer port name - just like in
> regulator subsystem.
> 3. PHY driver receives an array of, let's say, phy_init_data inside its
> platform data that it would use to register its PHYs.
> 4. Consumer drivers would have constant consumer port names and wouldn't
> receive any information about PHYs from platform code.
>
> Code example:
>
> [Board file]
>
> static const struct phy_consumer_data usb_20_phy0_consumers[] = {
> {
> .devname = "foo-ehci",
> .port = "usbphy",
> },
> };
>
> static const struct phy_consumer_data usb_20_phy1_consumers[] = {
> {
> .devname = "foo-otg",
> .port = "otgphy",
> },
> };
>
> static const struct phy_init_data my_phys[] = {
> {
> .name = "USB 2.0 PHY 0",
> .consumers = usb_20_phy0_consumers,
> .num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
> },
> {
> .name = "USB 2.0 PHY 1",
> .consumers = usb_20_phy1_consumers,
> .num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
> },
> { }
> };
>
> static const struct platform_device usb_phy_pdev = {
> .name = "foo-usbphy",
> .id = -1,
> .dev = {
> .platform_data = my_phys,
> },
> };
>
> [PHY driver]
>
> static int foo_usbphy_probe(pdev)
> {
> struct foo_usbphy *foo;
> struct phy_init_data *init_data = pdev->dev.platform_data;
> /* ... */
> // for each PHY in init_data {
> phy_register(>phy[i], _data[i]);
> // }
> /* ... */
> }
>
> [EHCI driver]
>
> static int foo_ehci_probe(pdev)
> {
> struct phy *phy;
> /* ... */
> phy = phy_get(>dev, "usbphy");
> /* ... */
> }
>
> [OTG driver]
>
> static int foo_otg_probe(pdev)
> {
> struct phy *phy;
> /* ... */
> phy = phy_get(>dev, "otgphy");
> /* ... */
> }
That's not so bad, as long as you let the phy core use whatever name it
wants for the device when it registers it with sysfs. Use the name you
are requesting as a "tag" or some such "hint" as to what the phy can be
looked up by.
Good luck handling duplicate "tags" :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 11:04:14 Greg KH wrote:
> On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
> > > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > > > > Ick, no. Why can't you just pass the pointer to the phy itself?
> > > > > If
> > > > > you
> > > > > had a "priv" pointer to search from, then you could have just
> > > > > passed
> > > > > the
> > > > > original phy pointer in the first place, right?
> > > >
> > > > IMHO it would be better if you provided some code example, but
> > > > let's
> > > > try to check if I understood you correctly.
> > >
> > > It's not my code that I want to have added, so I don't have to write
> > > examples, I just get to complain about the existing stuff :)
> >
> > Still, I think that some small code snippets illustrating the idea are
> > really helpful.
> >
> > > > 8><---
> > > > -
> > > >
> > > >
> > > > [Board file]
> > > >
> > > > static struct phy my_phy;
> > > >
> > > > static struct platform_device phy_pdev = {
> > > >
> > > > /* ... */
> > > > .platform_data = _phy;
> > > > /* ... */
> > > >
> > > > };
> > > >
> > > > static struct platform_device phy_pdev = {
> > > >
> > > > /* ... */
> > > > .platform_data = _phy;
> > > > /* ... */
> > > >
> > > > };
> > > >
> > > > [Provider driver]
> > > >
> > > > struct phy *phy = pdev->dev.platform_data;
> > > >
> > > > ret = phy_create(phy);
> > > >
> > > > [Consumer driver]
> > > >
> > > > struct phy *phy = pdev->dev.platform_data;
> > > >
> > > > ret = phy_get(>dev, phy);
> > > >
> > > > --
> > > > -
> > > > -><8
> > > >
> > > > Is this what you mean?
> > >
> > > No. Well, kind of. What's wrong with using the platform data
> > > structure unique to the board to have the pointer?
> > >
> > > For example (just randomly picking one), the ata-pxa driver would
> > > change include/linux/platform_data/ata-pxa.h to have a phy pointer
> > > in it:
> > >
> > > struct phy;
> > >
> > > struct pata_pxa_pdata {
> > >
> > > /* PXA DMA DREQ<0:2> pin */
> > > uint32_tdma_dreq;
> > > /* Register shift */
> > > uint32_treg_shift;
> > > /* IRQ flags */
> > > uint32_tirq_flags;
> > > /* PHY */
> > > struct phy *phy;
> > >
> > > };
> > >
> > > Then, when you create the platform, set the phy* pointer with a call
> > > to
> > > phy_create(). Then you can use that pointer wherever that plaform
> > > data
> > > is available (i.e. whereever platform_data is at).
> >
> > Hmm? So, do you suggest to call phy_create() from board file? What
> > phy_ops struct and other hardware parameters would it take?
> >
> > > > > The issue is that a string "name" is not going to scale at all,
> > > > > as it
> > > > > requires hard-coded information that will change over time (as
> > > > > the
> > > > > existing clock interface is already showing.)
> > > >
> > > > I fully agree that a simple, single string will not scale even in
> > > > some,
> > > > not so uncommon cases, but there is already a lot of existing
> > > > lookup
> > > > solutions over the kernel and so there is no point in introducing
> > > > another one.
> > >
> > > I'm trying to get _rid_ of lookup "solutions" and just use a real
> > > pointer, as you should. I'll go tackle those other ones after this
> > > one
> > > is taken care of, to show how the others should be handled as well.
> >
> > There was a reason for introducing lookup solutions. The reason was
> > that in board file there is no way to get a pointer to something that
> > is going to be created much later in time. We don't do time travel
> > ;-).
> >
> > > > > Please just pass the real "phy" pointer around, that's what it
> > > > > is
> > > > > there
> > > > > for. Your "board binding" logic/code should be able to handle
> > > > > this,
> > > > > as
> > > > > it somehow was going to do the same thing with a "name".
> > > >
> > > > It's technically correct, but quality of this solution isn't
> > > > really
> > > > nice, because it's a layering violation (at least if I understood
> > > > what
> > > > you mean). This is because you need to have full definition of
> > > > struct
> > > > phy in board file and a structure that is used as private data in
> > > > PHY
> > > > core comes from platform code.
> > >
> > > No, just a pointer, you don't need the "full" structure until you
> > > get to some .c code that actually manipulates the phy itself, for
> > > all other places, you are just dealing with a pointer and a
> > > structure you never reference.
> > >
> > > Does that make more sense?
> >
> > Well, to the point that I think I now understood your suggestion.
> > Unfortunately the suggestion alone isn't really something that can be
> > done, considering how driver core and generic
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 15:36:00 Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > IMHO it would be better if you provided some code example, but let's
> > try to check if I understood you correctly.
> >
> > 8><---
> > -
> >
> > [Board file]
> >
> > static struct phy my_phy;
> >
> > static struct platform_device phy_pdev = {
> >
> > /* ... */
> > .platform_data = _phy;
> > /* ... */
> >
> > };
> >
> > static struct platform_device phy_pdev = {
>
> This should be controller_pdev, not phy_pdev, yes?
Right. A copy-pasto.
>
> > /* ... */
> > .platform_data = _phy;
> > /* ... */
> >
> > };
> >
> > [Provider driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_create(phy);
> >
> > [Consumer driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_get(>dev, phy);
>
> Or even just phy_get(>dev), because phy_get() could be smart
> enough to to set phy = dev->platform_data.
Unless you need more than one PHY in this driver...
>
> > --
> > --><8
> >
> > Is this what you mean?
>
> That's what I was going to suggest too. The struct phy is defined in
> the board file, which already knows about all the PHYs that exist in
> the system. (Or perhaps it is allocated dynamically, so that when many
> board files are present in the same kernel, only the entries listed in
> the board file for the current system get created.)
Well, such dynamic allocation is a must. We don't accept non-multiplatform
aware code anymore, not even saying about multiboard.
> Then the
> structure's address is stored in the platform data and made available
> to both the provider and the consumer.
Yes, technically this can work. You would still have to perform some kind
of synchronization to make sure that the PHY bound to this structure is
actually present. This is again technically doable (e.g. a list of
registered struct phys inside PHY core).
> Even though the struct phy is defined (or allocated) in the board file,
> its contents don't get filled in until the PHY driver provides the
> details.
You can't assure this. Board file is free to do whatever it wants with
this struct. A clean solution would prevent this.
> > It's technically correct, but quality of this solution isn't really
> > nice, because it's a layering violation (at least if I understood
> > what you mean). This is because you need to have full definition of
> > struct phy in board file and a structure that is used as private data
> > in PHY core comes from platform code.
>
> You don't have to have a full definition in the board file. Just a
> partial definition -- most of the contents can be filled in later, when
> the PHY driver is ready to store the private data.
>
> It's not a layering violation for one region of the kernel to store
> private data in a structure defined by another part of the kernel.
> This happens all the time (e.g., dev_set_drvdata).
Not really. The phy struct is something that _is_ private data of PHY
subsystem, not something that can store private data of PHY subsystem
(sure it can store private data of particular PHY driver, but that's
another story) and only PHY subsystem should have access to its contents.
By the way, we need to consider other cases here as well, for example it
would be nice to have a single phy_get() function that works for both non-
DT and DT cases to make the consumer driver not have to worry whether it's
being probed from DT or not.
I'd suggest simply reusing the lookup method of regulator framework, just
as I suggested here:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=101661
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > > You don't "know" the id of the device you are looking up, due to
> > > multiple devices being in the system (dynamic ids, look back earlier
> > > in
> > > this thread for details about that.)
> >
> > I got copied in very late so don't have most of the thread I'm afraid,
> > I did try looking at web archives but didn't see a clear problem
> > statement. In any case this is why the APIs doing lookups do the
> > lookups in the context of the requesting device - devices ask for
> > whatever name they use locally.
>
> What do you mean by "locally"?
>
> The problem with the api was that the phy core wanted a id and a name to
> create a phy, and then later other code was doing a "lookup" based on
> the name and id (mushed together), because it "knew" that this device
> was the one it wanted.
>
> Just like the clock api, which, for multiple devices, has proven to
> cause problems. I don't want to see us accept an api that we know has
> issues in it now, I'd rather us fix it up properly.
>
> Subsystems should be able to create ids how ever they want to, and not
> rely on the code calling them to specify the names of the devices that
> way, otherwise the api is just too fragile.
>
> I think, that if you create a device, then just carry around the pointer
> to that device (in this case a phy) and pass it to whatever other code
> needs it. No need to do lookups on "known names" or anything else,
> just normal pointers, with no problems for multiple devices, busses, or
> naming issues.
PHY object is not a device, it is something that a device driver creates
(one or more instances of) when it is being probed. You don't have a clean
way to export this PHY object to other driver, other than keeping this PHY
on a list inside PHY core with some well-known ID (e.g. device name +
consumer port name/index, like in regulator core) and then to use this
well-known ID inside consumer driver as a lookup key passed to phy_get();
Actually I think for PHY case, exactly the same way as used for regulators
might be completely fine:
1. Each PHY would have some kind of platform, non-unique name, that is
just used to print some messages (like the platform/board name of a
regulator).
2. Each PHY would have an array of consumers. Consumer specifier would
consist of consumer device name and consumer port name - just like in
regulator subsystem.
3. PHY driver receives an array of, let's say, phy_init_data inside its
platform data that it would use to register its PHYs.
4. Consumer drivers would have constant consumer port names and wouldn't
receive any information about PHYs from platform code.
Code example:
[Board file]
static const struct phy_consumer_data usb_20_phy0_consumers[] = {
{
.devname = "foo-ehci",
.port = "usbphy",
},
};
static const struct phy_consumer_data usb_20_phy1_consumers[] = {
{
.devname = "foo-otg",
.port = "otgphy",
},
};
static const struct phy_init_data my_phys[] = {
{
.name = "USB 2.0 PHY 0",
.consumers = usb_20_phy0_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
},
{
.name = "USB 2.0 PHY 1",
.consumers = usb_20_phy1_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
},
{ }
};
static const struct platform_device usb_phy_pdev = {
.name = "foo-usbphy",
.id = -1,
.dev = {
.platform_data = my_phys,
},
};
[PHY driver]
static int foo_usbphy_probe(pdev)
{
struct foo_usbphy *foo;
struct phy_init_data *init_data = pdev->dev.platform_data;
/* ... */
// for each PHY in init_data {
phy_register(>phy[i], _data[i]);
// }
/* ... */
}
[EHCI driver]
static int foo_ehci_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(>dev, "usbphy");
/* ... */
}
[OTG driver]
static int foo_otg_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(>dev, "otgphy");
/* ... */
}
> > > > Having to write platform data for everything gets old fast and the
> > > > code
> > > > duplication is pretty tedious...
> > >
> > > Adding a single pointer is "tedious"? Where is the "name" that you
> > > are
> > > going to lookup going to come from? That code doesn't write
> > > itself...
> >
> > It's adding platform data in the first place that gets tedious - and
> > of
> > course there's also DT and ACPI to worry about, it's not just a case
> > of
> > platform data and then you're done. Pushing the lookup into library
> > code means that drivers don't have to worry about any of this stuff.
>
> I agree, so just pass around the pointer to the phy and all is good. No
> need
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote: > > You don't "know" the id of the device you are looking up, due to > > multiple devices being in the system (dynamic ids, look back earlier in > > this thread for details about that.) > > I got copied in very late so don't have most of the thread I'm afraid, > I did try looking at web archives but didn't see a clear problem > statement. In any case this is why the APIs doing lookups do the > lookups in the context of the requesting device - devices ask for > whatever name they use locally. What do you mean by "locally"? The problem with the api was that the phy core wanted a id and a name to create a phy, and then later other code was doing a "lookup" based on the name and id (mushed together), because it "knew" that this device was the one it wanted. Just like the clock api, which, for multiple devices, has proven to cause problems. I don't want to see us accept an api that we know has issues in it now, I'd rather us fix it up properly. Subsystems should be able to create ids how ever they want to, and not rely on the code calling them to specify the names of the devices that way, otherwise the api is just too fragile. I think, that if you create a device, then just carry around the pointer to that device (in this case a phy) and pass it to whatever other code needs it. No need to do lookups on "known names" or anything else, just normal pointers, with no problems for multiple devices, busses, or naming issues. > > > Having to write platform data for everything gets old fast and the code > > > duplication is pretty tedious... > > > Adding a single pointer is "tedious"? Where is the "name" that you are > > going to lookup going to come from? That code doesn't write itself... > > It's adding platform data in the first place that gets tedious - and of > course there's also DT and ACPI to worry about, it's not just a case of > platform data and then you're done. Pushing the lookup into library > code means that drivers don't have to worry about any of this stuff. I agree, so just pass around the pointer to the phy and all is good. No need to worry about DT or ACPI or anything else. > For most of the APIs doing this there is a clear and unambiguous name in > the hardware that can be used (and for hardware process reasons is > unlikely to get changed). The major exception to this is the clock API > since it is relatively rare to have clear, segregated IP level > information for IPs baked into larger chips. The other APIs tend to be > establishing chip to chip links. The clock api is having problems with multiple "names" due to dynamic devices from what I was told. I want to prevent the PHY interface from having that same issue. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote:
> IMHO it would be better if you provided some code example, but let's try to
> check if I understood you correctly.
>
> 8><
>
> [Board file]
>
> static struct phy my_phy;
>
> static struct platform_device phy_pdev = {
> /* ... */
> .platform_data = _phy;
> /* ... */
> };
>
> static struct platform_device phy_pdev = {
This should be controller_pdev, not phy_pdev, yes?
> /* ... */
> .platform_data = _phy;
> /* ... */
> };
>
> [Provider driver]
>
> struct phy *phy = pdev->dev.platform_data;
>
> ret = phy_create(phy);
>
> [Consumer driver]
>
> struct phy *phy = pdev->dev.platform_data;
>
> ret = phy_get(>dev, phy);
Or even just phy_get(>dev), because phy_get() could be smart
enough to to set phy = dev->platform_data.
> ><8
>
> Is this what you mean?
That's what I was going to suggest too. The struct phy is defined in
the board file, which already knows about all the PHYs that exist in
the system. (Or perhaps it is allocated dynamically, so that when many
board files are present in the same kernel, only the entries listed in
the board file for the current system get created.) Then the
structure's address is stored in the platform data and made available
to both the provider and the consumer.
Even though the struct phy is defined (or allocated) in the board file,
its contents don't get filled in until the PHY driver provides the
details.
> It's technically correct, but quality of this solution isn't really nice,
> because it's a layering violation (at least if I understood what you mean).
> This is because you need to have full definition of struct phy in board file
> and a structure that is used as private data in PHY core comes from
> platform code.
You don't have to have a full definition in the board file. Just a
partial definition -- most of the contents can be filled in later, when
the PHY driver is ready to store the private data.
It's not a layering violation for one region of the kernel to store
private data in a structure defined by another part of the kernel.
This happens all the time (e.g., dev_set_drvdata).
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 11:01:10AM -0700, Greg KH wrote: > On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote: > > What are the problems you are seeing with doing things with lookups? > You don't "know" the id of the device you are looking up, due to > multiple devices being in the system (dynamic ids, look back earlier in > this thread for details about that.) I got copied in very late so don't have most of the thread I'm afraid, I did try looking at web archives but didn't see a clear problem statement. In any case this is why the APIs doing lookups do the lookups in the context of the requesting device - devices ask for whatever name they use locally. > > Having to write platform data for everything gets old fast and the code > > duplication is pretty tedious... > Adding a single pointer is "tedious"? Where is the "name" that you are > going to lookup going to come from? That code doesn't write itself... It's adding platform data in the first place that gets tedious - and of course there's also DT and ACPI to worry about, it's not just a case of platform data and then you're done. Pushing the lookup into library code means that drivers don't have to worry about any of this stuff. For most of the APIs doing this there is a clear and unambiguous name in the hardware that can be used (and for hardware process reasons is unlikely to get changed). The major exception to this is the clock API since it is relatively rare to have clear, segregated IP level information for IPs baked into larger chips. The other APIs tend to be establishing chip to chip links. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
> On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
> > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > > > Ick, no. Why can't you just pass the pointer to the phy itself? If
> > > > you
> > > > had a "priv" pointer to search from, then you could have just passed
> > > > the
> > > > original phy pointer in the first place, right?
> > >
> > > IMHO it would be better if you provided some code example, but let's
> > > try to check if I understood you correctly.
> >
> > It's not my code that I want to have added, so I don't have to write
> > examples, I just get to complain about the existing stuff :)
>
> Still, I think that some small code snippets illustrating the idea are
> really helpful.
>
> > > 8><
> > >
> > >
> > > [Board file]
> > >
> > > static struct phy my_phy;
> > >
> > > static struct platform_device phy_pdev = {
> > >
> > > /* ... */
> > > .platform_data = _phy;
> > > /* ... */
> > >
> > > };
> > >
> > > static struct platform_device phy_pdev = {
> > >
> > > /* ... */
> > > .platform_data = _phy;
> > > /* ... */
> > >
> > > };
> > >
> > > [Provider driver]
> > >
> > > struct phy *phy = pdev->dev.platform_data;
> > >
> > > ret = phy_create(phy);
> > >
> > > [Consumer driver]
> > >
> > > struct phy *phy = pdev->dev.platform_data;
> > >
> > > ret = phy_get(>dev, phy);
> > >
> > > ---
> > > -><8
> > >
> > > Is this what you mean?
> >
> > No. Well, kind of. What's wrong with using the platform data structure
> > unique to the board to have the pointer?
> >
> > For example (just randomly picking one), the ata-pxa driver would change
> > include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
> >
> > struct phy;
> >
> > struct pata_pxa_pdata {
> > /* PXA DMA DREQ<0:2> pin */
> > uint32_tdma_dreq;
> > /* Register shift */
> > uint32_treg_shift;
> > /* IRQ flags */
> > uint32_tirq_flags;
> > /* PHY */
> > struct phy *phy;
> > };
> >
> > Then, when you create the platform, set the phy* pointer with a call to
> > phy_create(). Then you can use that pointer wherever that plaform data
> > is available (i.e. whereever platform_data is at).
>
> Hmm? So, do you suggest to call phy_create() from board file? What phy_ops
> struct and other hardware parameters would it take?
>
> > > > The issue is that a string "name" is not going to scale at all, as it
> > > > requires hard-coded information that will change over time (as the
> > > > existing clock interface is already showing.)
> > >
> > > I fully agree that a simple, single string will not scale even in some,
> > > not so uncommon cases, but there is already a lot of existing lookup
> > > solutions over the kernel and so there is no point in introducing
> > > another one.
> > I'm trying to get _rid_ of lookup "solutions" and just use a real
> > pointer, as you should. I'll go tackle those other ones after this one
> > is taken care of, to show how the others should be handled as well.
>
> There was a reason for introducing lookup solutions. The reason was that in
> board file there is no way to get a pointer to something that is going to be
> created much later in time. We don't do time travel ;-).
>
> > > > Please just pass the real "phy" pointer around, that's what it is
> > > > there
> > > > for. Your "board binding" logic/code should be able to handle this,
> > > > as
> > > > it somehow was going to do the same thing with a "name".
> > >
> > > It's technically correct, but quality of this solution isn't really
> > > nice, because it's a layering violation (at least if I understood what
> > > you mean). This is because you need to have full definition of struct
> > > phy in board file and a structure that is used as private data in PHY
> > > core comes from platform code.
> >
> > No, just a pointer, you don't need the "full" structure until you get to
> > some .c code that actually manipulates the phy itself, for all other
> > places, you are just dealing with a pointer and a structure you never
> > reference.
> >
> > Does that make more sense?
>
> Well, to the point that I think I now understood your suggestion.
> Unfortunately the suggestion alone isn't really something that can be done,
> considering how driver core and generic frameworks work.
Ok, given that I seem to be totally confused as to exactly how the
board-specific frameworks work, I'll take your word for it.
But again, I will not accept "lookup by name" type solutions, when the
"name" is dynamic and will change. Because you are using a "name", you
can deal with a pointer, putting it _somewhere_ in your board-specific
data structures, as you are going to need to store it anyway (hint, you
had to get that "name" from somewhere, right?)
And maybe
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote: > On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote: > > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote: > > > > I fully agree that a simple, single string will not scale even in some, > > > not > > > so uncommon cases, but there is already a lot of existing lookup > > > solutions > > > over the kernel and so there is no point in introducing another one. > > > I'm trying to get _rid_ of lookup "solutions" and just use a real > > pointer, as you should. I'll go tackle those other ones after this one > > is taken care of, to show how the others should be handled as well. > > What are the problems you are seeing with doing things with lookups? You don't "know" the id of the device you are looking up, due to multiple devices being in the system (dynamic ids, look back earlier in this thread for details about that.) > Having to write platform data for everything gets old fast and the code > duplication is pretty tedious... Adding a single pointer is "tedious"? Where is the "name" that you are going to lookup going to come from? That code doesn't write itself... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
> On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > > Ick, no. Why can't you just pass the pointer to the phy itself? If
> > > you
> > > had a "priv" pointer to search from, then you could have just passed
> > > the
> > > original phy pointer in the first place, right?
> >
> > IMHO it would be better if you provided some code example, but let's
> > try to check if I understood you correctly.
>
> It's not my code that I want to have added, so I don't have to write
> examples, I just get to complain about the existing stuff :)
Still, I think that some small code snippets illustrating the idea are
really helpful.
> > 8><
> >
> >
> > [Board file]
> >
> > static struct phy my_phy;
> >
> > static struct platform_device phy_pdev = {
> >
> > /* ... */
> > .platform_data = _phy;
> > /* ... */
> >
> > };
> >
> > static struct platform_device phy_pdev = {
> >
> > /* ... */
> > .platform_data = _phy;
> > /* ... */
> >
> > };
> >
> > [Provider driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_create(phy);
> >
> > [Consumer driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_get(>dev, phy);
> >
> > ---
> > -><8
> >
> > Is this what you mean?
>
> No. Well, kind of. What's wrong with using the platform data structure
> unique to the board to have the pointer?
>
> For example (just randomly picking one), the ata-pxa driver would change
> include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
>
> struct phy;
>
> struct pata_pxa_pdata {
> /* PXA DMA DREQ<0:2> pin */
> uint32_tdma_dreq;
> /* Register shift */
> uint32_treg_shift;
> /* IRQ flags */
> uint32_tirq_flags;
> /* PHY */
> struct phy *phy;
> };
>
> Then, when you create the platform, set the phy* pointer with a call to
> phy_create(). Then you can use that pointer wherever that plaform data
> is available (i.e. whereever platform_data is at).
Hmm? So, do you suggest to call phy_create() from board file? What phy_ops
struct and other hardware parameters would it take?
> > > The issue is that a string "name" is not going to scale at all, as it
> > > requires hard-coded information that will change over time (as the
> > > existing clock interface is already showing.)
> >
> > I fully agree that a simple, single string will not scale even in some,
> > not so uncommon cases, but there is already a lot of existing lookup
> > solutions over the kernel and so there is no point in introducing
> > another one.
> I'm trying to get _rid_ of lookup "solutions" and just use a real
> pointer, as you should. I'll go tackle those other ones after this one
> is taken care of, to show how the others should be handled as well.
There was a reason for introducing lookup solutions. The reason was that in
board file there is no way to get a pointer to something that is going to be
created much later in time. We don't do time travel ;-).
> > > Please just pass the real "phy" pointer around, that's what it is
> > > there
> > > for. Your "board binding" logic/code should be able to handle this,
> > > as
> > > it somehow was going to do the same thing with a "name".
> >
> > It's technically correct, but quality of this solution isn't really
> > nice, because it's a layering violation (at least if I understood what
> > you mean). This is because you need to have full definition of struct
> > phy in board file and a structure that is used as private data in PHY
> > core comes from platform code.
>
> No, just a pointer, you don't need the "full" structure until you get to
> some .c code that actually manipulates the phy itself, for all other
> places, you are just dealing with a pointer and a structure you never
> reference.
>
> Does that make more sense?
Well, to the point that I think I now understood your suggestion.
Unfortunately the suggestion alone isn't really something that can be done,
considering how driver core and generic frameworks work.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote: > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote: > > I fully agree that a simple, single string will not scale even in some, not > > so uncommon cases, but there is already a lot of existing lookup solutions > > over the kernel and so there is no point in introducing another one. > I'm trying to get _rid_ of lookup "solutions" and just use a real > pointer, as you should. I'll go tackle those other ones after this one > is taken care of, to show how the others should be handled as well. What are the problems you are seeing with doing things with lookups? Having to write platform data for everything gets old fast and the code duplication is pretty tedious... signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:37:05AM -0400, Alan Stern wrote: > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > > Okay. Are PHYs _always_ platform devices? > > > They can be i2c, spi or any other device types as well. > In those other cases, presumably there is no platform data associated > with the PHY since it isn't a platform device. Then how does the > kernel know which controller is attached to the PHY? Is this spelled > out in platform data associated with the PHY's i2c/spi/whatever parent? Platform data is nothing to do with the platform bus - it's board specific data (ie, data for the platform) and can be done with any device. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > Ick, no. Why can't you just pass the pointer to the phy itself? If you
> > had a "priv" pointer to search from, then you could have just passed the
> > original phy pointer in the first place, right?
>
> IMHO it would be better if you provided some code example, but let's try to
> check if I understood you correctly.
It's not my code that I want to have added, so I don't have to write
examples, I just get to complain about the existing stuff :)
> 8><
>
> [Board file]
>
> static struct phy my_phy;
>
> static struct platform_device phy_pdev = {
> /* ... */
> .platform_data = _phy;
> /* ... */
> };
>
> static struct platform_device phy_pdev = {
> /* ... */
> .platform_data = _phy;
> /* ... */
> };
>
> [Provider driver]
>
> struct phy *phy = pdev->dev.platform_data;
>
> ret = phy_create(phy);
>
> [Consumer driver]
>
> struct phy *phy = pdev->dev.platform_data;
>
> ret = phy_get(>dev, phy);
>
> ><8
>
> Is this what you mean?
No. Well, kind of. What's wrong with using the platform data structure
unique to the board to have the pointer?
For example (just randomly picking one), the ata-pxa driver would change
include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
struct phy;
struct pata_pxa_pdata {
/* PXA DMA DREQ<0:2> pin */
uint32_tdma_dreq;
/* Register shift */
uint32_treg_shift;
/* IRQ flags */
uint32_tirq_flags;
/* PHY */
struct phy *phy;
};
Then, when you create the platform, set the phy* pointer with a call to
phy_create(). Then you can use that pointer wherever that plaform data
is available (i.e. whereever platform_data is at).
> > The issue is that a string "name" is not going to scale at all, as it
> > requires hard-coded information that will change over time (as the
> > existing clock interface is already showing.)
>
> I fully agree that a simple, single string will not scale even in some, not
> so uncommon cases, but there is already a lot of existing lookup solutions
> over the kernel and so there is no point in introducing another one.
I'm trying to get _rid_ of lookup "solutions" and just use a real
pointer, as you should. I'll go tackle those other ones after this one
is taken care of, to show how the others should be handled as well.
> > Please just pass the real "phy" pointer around, that's what it is there
> > for. Your "board binding" logic/code should be able to handle this, as
> > it somehow was going to do the same thing with a "name".
>
> It's technically correct, but quality of this solution isn't really nice,
> because it's a layering violation (at least if I understood what you mean).
> This is because you need to have full definition of struct phy in board file
> and a structure that is used as private data in PHY core comes from
> platform code.
No, just a pointer, you don't need the "full" structure until you get to
some .c code that actually manipulates the phy itself, for all other
places, you are just dealing with a pointer and a structure you never
reference.
Does that make more sense?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 09:18:46 Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > >> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > >>> Hi Alan,
> > >
> > > Thanks for helping to clarify the issues here.
> > >
> > Okay. Are PHYs _always_ platform devices?
> > >>>
> > >>> They can be i2c, spi or any other device types as well.
> > >
> > > In those other cases, presumably there is no platform data associated
> > > with the PHY since it isn't a platform device. Then how does the
> > > kernel know which controller is attached to the PHY? Is this spelled
> > > out in platform data associated with the PHY's i2c/spi/whatever
> > > parent?
> >
> > Yes. I think we could use i2c_board_info for passing platform data.
> >
> > >> PHY. Currently this information is represented by name or
> > >>
> > >> ID
> > >>
> > >> strings embedded in platform data.
> > >
> > > right. It's embedded in the platform data of the controller.
> >
> > It must also be embedded in the PHY's platform data somehow.
> > Otherwise, how would the kernel know which PHY to use?
> > >>>
> > >>> By using a PHY lookup as Stephen and I suggested in our previous
> > >>> replies. Without any extra data in platform data. (I have even
> > >>> posted a
> > >>> code example.)
> > >
> > > I don't understand, because I don't know what "a PHY lookup" does.
> >
> > It is how the PHY framework finds a PHY, when the controller (say
> > USB)requests a PHY from the PHY framework.
> >
> > In this case, it doesn't matter where the platform_device
> > structures
> > are created or where the driver source code is. Let's take a
> > simple
> > example. Suppose the system design includes a PHY named "foo".
> > Then
> > the board file could contain:
> >
> > struct phy_info { ... } phy_foo;
> > EXPORT_SYMBOL_GPL(phy_foo);
> >
> > and a header file would contain:
> >
> > extern struct phy_info phy_foo;
> >
> > The PHY supplier could then call phy_create(_foo), and the PHY
> > client could call phy_find(_foo). Or something like that;
> > make up
> > your own structure tags and function names.
> >
> > It's still possible to have conflicts, but now two PHYs with the
> > same
> > name (or a misspelled name somewhere) will cause an error at link
> > time.
> > >>>
> > >>> This is incorrect, sorry. First of all it's a layering violation -
> > >>> you
> > >>> export random driver-specific symbols from one driver to another.
> > >>> Then
> > >
> > > No, that's not what I said. Neither the PHY driver nor the
> > > controller
> > > driver exports anything to the other. Instead, both drivers use data
> > > exported by the board file.
> >
> > I think instead we can use the same data while creating the platform
> > data of the controller and the PHY.
> > The PHY driver while creating the PHY (using PHY framework) will also
> > pass the *data* it actually got from the platform data to the
> > framework. The PHY user driver (USB), while requesting for the PHY
> > (from the PHY framework) will pass the *data* it got from its platform
> > data.
> > The PHY framework can do a comparison of the *data* pointers it has and
> > return the appropriate PHY to the controller.
> >
> > >>> imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
> > >>> and
> > >>> there are two types of consumer drivers (e.g. USB host
> > >>> controllers). Now
> > >>> consider following mapping:
> > >>>
> > >>> SoC PHY consumer
> > >>> A PHY1HOST1
> > >>> B PHY1HOST2
> > >>> C PHY2HOST1
> > >>> D PHY2HOST2
> > >>>
> > >>> So we have to be able to use any of the PHYs with any of the host
> > >>> drivers. This means you would have to export symbol with the same
> > >>> name
> > >>> from both PHY drivers, which obviously would not work in this case,
> > >>> because having both drivers enabled (in a multiplatform aware
> > >>> configuration) would lead to linking conflict.
> > >
> > > You're right; the scheme was too simple. Instead, the board file
> > > must
> > > export two types of data structures, one for PHYs and one for
> > > controllers. Like this:
> > >
> > > struct phy_info {
> > >
> > > /* Info for the controller attached to this PHY */
> > > struct controller_info *hinfo;
> > >
> > > };
> > >
> > > struct controller_info {
> > >
> > > /* Info for the PHY which this controller is attached to */
> > > struct phy_info *pinfo;
> > >
> > > };
> > >
> > > The board file for SoC A would contain:
> > >
> > > struct phy_info phy1 = {);
> > > EXPORT_SYMBOL(phy1);
> > > struct controller_info host1 = {};
> > > EXPORT_SYMBOL(host1);
> > >
> > > The board file for SoC B
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 09:58:34PM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
>
> On Tuesday 23 July 2013 09:48 PM, Greg KH wrote:
> > On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
> >> Hi,
> >>
> >> On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> >>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> >>>
> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > Hi Alan,
> >>>
> >>> Thanks for helping to clarify the issues here.
> >>>
> >> Okay. Are PHYs _always_ platform devices?
> >
> > They can be i2c, spi or any other device types as well.
> >>>
> >>> In those other cases, presumably there is no platform data associated
> >>> with the PHY since it isn't a platform device. Then how does the
> >>> kernel know which controller is attached to the PHY? Is this spelled
> >>> out in platform data associated with the PHY's i2c/spi/whatever parent?
> .
> .
>
> .
> .
> >>
> >>static struct phy *phy_lookup(void *priv) {
> >>.
> >>.
> >>if (phy->priv==priv) //instead of string comparison, we'll use
> >> pointer
> >>return phy;
> >>}
> >>
> >> PHY driver should be like
> >>phy_create((dev, ops, pdata->info);
> >>
> >> The controller driver would do
> >>phy_get(dev, NULL, pdata->info);
> >>
> >> Now the PHY framework will check for a match of *priv* pointer and return
> >> the PHY.
> >>
> >> I think this should be possible?
> >
> > Ick, no. Why can't you just pass the pointer to the phy itself? If you
> > had a "priv" pointer to search from, then you could have just passed the
> > original phy pointer in the first place, right?
> >
> > The issue is that a string "name" is not going to scale at all, as it
> > requires hard-coded information that will change over time (as the
> > existing clock interface is already showing.)
> >
> > Please just pass the real "phy" pointer around, that's what it is there
> > for. Your "board binding" logic/code should be able to handle this, as
> > it somehow was going to do the same thing with a "name".
>
> The problem is the board file won't have the *phy* pointer. *phy* pointer is
> created at a much later time when the phy driver is probed.
Ok, then save it then, as no one could have used it before then, right?
All I don't want to see is any "get by name/void *" functions in the
api, as that way is fragile and will break, as people have already
shown.
Just pass the real pointer around. If that is somehow a problem, then
something larger is a problem with how board devices are tied together :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Greg,
On Tuesday 23 July 2013 09:48 PM, Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
>>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
>>>
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> Hi Alan,
>>>
>>> Thanks for helping to clarify the issues here.
>>>
>> Okay. Are PHYs _always_ platform devices?
>
> They can be i2c, spi or any other device types as well.
>>>
>>> In those other cases, presumably there is no platform data associated
>>> with the PHY since it isn't a platform device. Then how does the
>>> kernel know which controller is attached to the PHY? Is this spelled
>>> out in platform data associated with the PHY's i2c/spi/whatever parent?
.
.
.
.
>>
>> static struct phy *phy_lookup(void *priv) {
>> .
>> .
>> if (phy->priv==priv) //instead of string comparison, we'll use
>> pointer
>> return phy;
>> }
>>
>> PHY driver should be like
>> phy_create((dev, ops, pdata->info);
>>
>> The controller driver would do
>> phy_get(dev, NULL, pdata->info);
>>
>> Now the PHY framework will check for a match of *priv* pointer and return
>> the PHY.
>>
>> I think this should be possible?
>
> Ick, no. Why can't you just pass the pointer to the phy itself? If you
> had a "priv" pointer to search from, then you could have just passed the
> original phy pointer in the first place, right?
>
> The issue is that a string "name" is not going to scale at all, as it
> requires hard-coded information that will change over time (as the
> existing clock interface is already showing.)
>
> Please just pass the real "phy" pointer around, that's what it is there
> for. Your "board binding" logic/code should be able to handle this, as
> it somehow was going to do the same thing with a "name".
The problem is the board file won't have the *phy* pointer. *phy* pointer is
created at a much later time when the phy driver is probed.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> >
> >> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> >>> Hi Alan,
> >
> > Thanks for helping to clarify the issues here.
> >
> Okay. Are PHYs _always_ platform devices?
> >>>
> >>> They can be i2c, spi or any other device types as well.
> >
> > In those other cases, presumably there is no platform data associated
> > with the PHY since it isn't a platform device. Then how does the
> > kernel know which controller is attached to the PHY? Is this spelled
> > out in platform data associated with the PHY's i2c/spi/whatever parent?
>
> Yes. I think we could use i2c_board_info for passing platform data.
> >
> >>PHY. Currently this information is represented by name or
> >> ID
> >>strings embedded in platform data.
> >
> > right. It's embedded in the platform data of the controller.
>
> It must also be embedded in the PHY's platform data somehow.
> Otherwise, how would the kernel know which PHY to use?
> >>>
> >>> By using a PHY lookup as Stephen and I suggested in our previous
> >>> replies. Without any extra data in platform data. (I have even posted a
> >>> code example.)
> >
> > I don't understand, because I don't know what "a PHY lookup" does.
>
> It is how the PHY framework finds a PHY, when the controller (say USB)requests
> a PHY from the PHY framework.
> >
> In this case, it doesn't matter where the platform_device structures
> are created or where the driver source code is. Let's take a simple
> example. Suppose the system design includes a PHY named "foo". Then
> the board file could contain:
>
> struct phy_info { ... } phy_foo;
> EXPORT_SYMBOL_GPL(phy_foo);
>
> and a header file would contain:
>
> extern struct phy_info phy_foo;
>
> The PHY supplier could then call phy_create(_foo), and the PHY
> client could call phy_find(_foo). Or something like that; make up
> your own structure tags and function names.
>
> It's still possible to have conflicts, but now two PHYs with the same
> name (or a misspelled name somewhere) will cause an error at link
> time.
> >>>
> >>> This is incorrect, sorry. First of all it's a layering violation - you
> >>> export random driver-specific symbols from one driver to another. Then
> >
> > No, that's not what I said. Neither the PHY driver nor the controller
> > driver exports anything to the other. Instead, both drivers use data
> > exported by the board file.
>
> I think instead we can use the same data while creating the platform data of
> the controller and the PHY.
> The PHY driver while creating the PHY (using PHY framework) will also pass the
> *data* it actually got from the platform data to the framework.
> The PHY user driver (USB), while requesting for the PHY (from the PHY
> framework) will pass the *data* it got from its platform data.
> The PHY framework can do a comparison of the *data* pointers it has and return
> the appropriate PHY to the controller.
> >
> >>> imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
> >>> there are two types of consumer drivers (e.g. USB host controllers). Now
> >>> consider following mapping:
> >>>
> >>> SoC PHY consumer
> >>> A PHY1HOST1
> >>> B PHY1HOST2
> >>> C PHY2HOST1
> >>> D PHY2HOST2
> >>>
> >>> So we have to be able to use any of the PHYs with any of the host
> >>> drivers. This means you would have to export symbol with the same name
> >>> from both PHY drivers, which obviously would not work in this case,
> >>> because having both drivers enabled (in a multiplatform aware
> >>> configuration) would lead to linking conflict.
> >
> > You're right; the scheme was too simple. Instead, the board file must
> > export two types of data structures, one for PHYs and one for
> > controllers. Like this:
> >
> > struct phy_info {
> > /* Info for the controller attached to this PHY */
> > struct controller_info *hinfo;
> > };
> >
> > struct controller_info {
> > /* Info for the PHY which this controller is attached to */
> > struct phy_info *pinfo;
> > };
> >
> > The board file for SoC A would contain:
> >
> > struct phy_info phy1 = {);
> > EXPORT_SYMBOL(phy1);
> > struct controller_info host1 = {};
> > EXPORT_SYMBOL(host1);
> >
> > The board file for SoC B would contain:
> >
> > struct phy_info phy1 = {);
> > EXPORT_SYMBOL(phy1);
> > struct controller_info host2 = {};
> > EXPORT_SYMBOL(host2);
>
> I meant something like this
> struct phy_info {
> const char *name;
> };
>
> struct phy_platform_data {
> .
> .
> struct phy_info *info;
> };
>
> struct usb_controller_platform_data {
> .
> .
> struct phy_info *info;
> };
>
> struct phy_info phy_info;
>
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
>
>> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
>>> Hi Alan,
>
> Thanks for helping to clarify the issues here.
>
Okay. Are PHYs _always_ platform devices?
>>>
>>> They can be i2c, spi or any other device types as well.
>
> In those other cases, presumably there is no platform data associated
> with the PHY since it isn't a platform device. Then how does the
> kernel know which controller is attached to the PHY? Is this spelled
> out in platform data associated with the PHY's i2c/spi/whatever parent?
Yes. I think we could use i2c_board_info for passing platform data.
>
>> PHY. Currently this information is represented by name or
>> ID
>> strings embedded in platform data.
>
> right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
>>>
>>> By using a PHY lookup as Stephen and I suggested in our previous
>>> replies. Without any extra data in platform data. (I have even posted a
>>> code example.)
>
> I don't understand, because I don't know what "a PHY lookup" does.
It is how the PHY framework finds a PHY, when the controller (say USB)requests
a PHY from the PHY framework.
>
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named "foo". Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(_foo), and the PHY
client could call phy_find(_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link
time.
>>>
>>> This is incorrect, sorry. First of all it's a layering violation - you
>>> export random driver-specific symbols from one driver to another. Then
>
> No, that's not what I said. Neither the PHY driver nor the controller
> driver exports anything to the other. Instead, both drivers use data
> exported by the board file.
I think instead we can use the same data while creating the platform data of
the controller and the PHY.
The PHY driver while creating the PHY (using PHY framework) will also pass the
*data* it actually got from the platform data to the framework.
The PHY user driver (USB), while requesting for the PHY (from the PHY
framework) will pass the *data* it got from its platform data.
The PHY framework can do a comparison of the *data* pointers it has and return
the appropriate PHY to the controller.
>
>>> imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
>>> there are two types of consumer drivers (e.g. USB host controllers). Now
>>> consider following mapping:
>>>
>>> SoC PHY consumer
>>> A PHY1HOST1
>>> B PHY1HOST2
>>> C PHY2HOST1
>>> D PHY2HOST2
>>>
>>> So we have to be able to use any of the PHYs with any of the host
>>> drivers. This means you would have to export symbol with the same name
>>> from both PHY drivers, which obviously would not work in this case,
>>> because having both drivers enabled (in a multiplatform aware
>>> configuration) would lead to linking conflict.
>
> You're right; the scheme was too simple. Instead, the board file must
> export two types of data structures, one for PHYs and one for
> controllers. Like this:
>
> struct phy_info {
> /* Info for the controller attached to this PHY */
> struct controller_info *hinfo;
> };
>
> struct controller_info {
> /* Info for the PHY which this controller is attached to */
> struct phy_info *pinfo;
> };
>
> The board file for SoC A would contain:
>
> struct phy_info phy1 = {);
> EXPORT_SYMBOL(phy1);
> struct controller_info host1 = {};
> EXPORT_SYMBOL(host1);
>
> The board file for SoC B would contain:
>
> struct phy_info phy1 = {);
> EXPORT_SYMBOL(phy1);
> struct controller_info host2 = {};
> EXPORT_SYMBOL(host2);
I meant something like this
struct phy_info {
const char *name;
};
struct phy_platform_data {
.
.
struct phy_info *info;
};
struct usb_controller_platform_data {
.
.
struct phy_info *info;
};
struct phy_info phy_info;
While creating the phy device
struct phy_platform_data phy_data;
phy_data.info =
platform_device_add_data(pdev, _data, sizeof(*phy_data))
platform_device_add();
While creating the controller device
struct usb_controller_platform_data controller_data;
controller_data.info =
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 10:37:05 Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > > Hi Alan,
>
> Thanks for helping to clarify the issues here.
>
> > > > Okay. Are PHYs _always_ platform devices?
> > >
> > > They can be i2c, spi or any other device types as well.
>
> In those other cases, presumably there is no platform data associated
> with the PHY since it isn't a platform device. Then how does the
> kernel know which controller is attached to the PHY? Is this spelled
> out in platform data associated with the PHY's i2c/spi/whatever parent?
>
> > > > > > PHY. Currently this information is represented by name or
> >
> > ID
> >
> > > > > > strings embedded in platform data.
> > > > >
> > > > > right. It's embedded in the platform data of the controller.
> > > >
> > > > It must also be embedded in the PHY's platform data somehow.
> > > > Otherwise, how would the kernel know which PHY to use?
> > >
> > > By using a PHY lookup as Stephen and I suggested in our previous
> > > replies. Without any extra data in platform data. (I have even posted
> > > a
> > > code example.)
>
> I don't understand, because I don't know what "a PHY lookup" does.
I have provided a code example in [1]. Feel free to ask questions about
those code snippets.
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=20889
> > > > In this case, it doesn't matter where the platform_device
> > > > structures
> > > > are created or where the driver source code is. Let's take a
> > > > simple
> > > > example. Suppose the system design includes a PHY named "foo".
> > > > Then
> > > > the board file could contain:
> > > >
> > > > struct phy_info { ... } phy_foo;
> > > > EXPORT_SYMBOL_GPL(phy_foo);
> > > >
> > > > and a header file would contain:
> > > >
> > > > extern struct phy_info phy_foo;
> > > >
> > > > The PHY supplier could then call phy_create(_foo), and the PHY
> > > > client could call phy_find(_foo). Or something like that; make
> > > > up
> > > > your own structure tags and function names.
> > > >
> > > > It's still possible to have conflicts, but now two PHYs with the
> > > > same
> > > > name (or a misspelled name somewhere) will cause an error at link
> > > > time.
> > >
> > > This is incorrect, sorry. First of all it's a layering violation -
> > > you
> > > export random driver-specific symbols from one driver to another.
> > > Then
>
> No, that's not what I said. Neither the PHY driver nor the controller
> driver exports anything to the other. Instead, both drivers use data
> exported by the board file.
It's still a random, driver-specific global symbol exported from board file
to drivers.
> > > imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
> > > and
> > > there are two types of consumer drivers (e.g. USB host controllers).
> > > Now
> > > consider following mapping:
> > >
> > > SoC PHY consumer
> > > A PHY1HOST1
> > > B PHY1HOST2
> > > C PHY2HOST1
> > > D PHY2HOST2
> > >
> > > So we have to be able to use any of the PHYs with any of the host
> > > drivers. This means you would have to export symbol with the same
> > > name
> > > from both PHY drivers, which obviously would not work in this case,
> > > because having both drivers enabled (in a multiplatform aware
> > > configuration) would lead to linking conflict.
>
> You're right; the scheme was too simple. Instead, the board file must
> export two types of data structures, one for PHYs and one for
> controllers. Like this:
>
> struct phy_info {
> /* Info for the controller attached to this PHY */
> struct controller_info *hinfo;
> };
>
> struct controller_info {
> /* Info for the PHY which this controller is attached to */
> struct phy_info *pinfo;
> };
>
> The board file for SoC A would contain:
>
> struct phy_info phy1 = {);
> EXPORT_SYMBOL(phy1);
> struct controller_info host1 = {};
> EXPORT_SYMBOL(host1);
>
> The board file for SoC B would contain:
>
> struct phy_info phy1 = {);
> EXPORT_SYMBOL(phy1);
> struct controller_info host2 = {};
> EXPORT_SYMBOL(host2);
>
> And so on. This explicitly gives the connection between PHYs and
> controllers. The PHY providers would use or , and the PHY
> consumers would use or
This could work assuming that only one SoC and one board is supported in
single kernel image. However it's not the case.
We've used to support multiple boards since a long time already and now for
selected platforms we even support multiplatform, i.e. multiple SoCs in
single zImage. Such solution will not work.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote:
> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > Hi Alan,
Thanks for helping to clarify the issues here.
> > > Okay. Are PHYs _always_ platform devices?
> >
> > They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
> > > > > PHY. Currently this information is represented by name or
> ID
> > > > > strings embedded in platform data.
> > > >
> > > > right. It's embedded in the platform data of the controller.
> > >
> > > It must also be embedded in the PHY's platform data somehow.
> > > Otherwise, how would the kernel know which PHY to use?
> >
> > By using a PHY lookup as Stephen and I suggested in our previous
> > replies. Without any extra data in platform data. (I have even posted a
> > code example.)
I don't understand, because I don't know what "a PHY lookup" does.
> > > In this case, it doesn't matter where the platform_device structures
> > > are created or where the driver source code is. Let's take a simple
> > > example. Suppose the system design includes a PHY named "foo". Then
> > > the board file could contain:
> > >
> > > struct phy_info { ... } phy_foo;
> > > EXPORT_SYMBOL_GPL(phy_foo);
> > >
> > > and a header file would contain:
> > >
> > > extern struct phy_info phy_foo;
> > >
> > > The PHY supplier could then call phy_create(_foo), and the PHY
> > > client could call phy_find(_foo). Or something like that; make up
> > > your own structure tags and function names.
> > >
> > > It's still possible to have conflicts, but now two PHYs with the same
> > > name (or a misspelled name somewhere) will cause an error at link
> > > time.
> >
> > This is incorrect, sorry. First of all it's a layering violation - you
> > export random driver-specific symbols from one driver to another. Then
No, that's not what I said. Neither the PHY driver nor the controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
> > imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
> > there are two types of consumer drivers (e.g. USB host controllers). Now
> > consider following mapping:
> >
> > SoC PHY consumer
> > A PHY1HOST1
> > B PHY1HOST2
> > C PHY2HOST1
> > D PHY2HOST2
> >
> > So we have to be able to use any of the PHYs with any of the host
> > drivers. This means you would have to export symbol with the same name
> > from both PHY drivers, which obviously would not work in this case,
> > because having both drivers enabled (in a multiplatform aware
> > configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {};
EXPORT_SYMBOL(host2);
And so on. This explicitly gives the connection between PHYs and
controllers. The PHY providers would use or , and the PHY
consumers would use or
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
[Fixed address of devicetree mailing list and added more people on CC.]
For reference, full thread can be found under following link:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813
Best regards,
Tomasz
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> Hi Alan,
>
> On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
> > On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
> > > > The PHY and the controller it is attached to are both
physical
> > > > devices.
> > > >
> > > > The connection between them is hardwired by the system
> > > > manufacturer and cannot be changed by software.
> > > >
> > > > PHYs are generally described by fixed system-specific
board
> > > > files or by Device Tree information. Are they ever
discovered
> > > > dynamically?
> > >
> > > No. They are created just like any other platform devices are
> > > created.
> >
> > Okay. Are PHYs _always_ platform devices?
>
> They can be i2c, spi or any other device types as well.
>
> > > > Is the same true for the controllers attached to the PHYs?
> > > > If not -- if both a PHY and a controller are discovered
> > > > dynamically -- how does the kernel know whether they are
> > > > connected to each other?
> > >
> > > No differences here. Both PHY and controller will have dt
> > > information
> > > or hwmod data using which platform devices will be created.
> > >
> > > > The kernel needs to know which controller is attached to
which
> > > > PHY. Currently this information is represented by name or
ID
> > > > strings embedded in platform data.
> > >
> > > right. It's embedded in the platform data of the controller.
> >
> > It must also be embedded in the PHY's platform data somehow.
> > Otherwise, how would the kernel know which PHY to use?
>
> By using a PHY lookup as Stephen and I suggested in our previous
> replies. Without any extra data in platform data. (I have even posted a
> code example.)
>
> > > > The PHY's driver (the supplier) uses the platform data to
> > > > construct a platform_device structure that represents the
PHY.
> > >
> > > Currently the driver assigns static labels (corresponding to the
> > > label
> > > used in the platform data of the controller).
> > >
> > > > Until this is done, the controller's driver (the client)
cannot
> > > > use the PHY.
> > >
> > > right.
> > >
> > > > Since there is no parent-child relation between the PHY
and the
> > > > controller, there is no guarantee that the PHY's driver
will be
> > > > ready when the controller's driver wants to use it. A
deferred
> > > > probe may be needed.
> > >
> > > right.
> > >
> > > > The issue (or one of the issues) in this discussion is
that
> > > > Greg does not like the idea of using names or IDs to
associate
> > > > PHYs with controllers, because they are too prone to
> > > > duplications or other errors. Pointers are more reliable.
> > > >
> > > > But pointers to what? Since the only data known to be
> > > > available to both the PHY driver and controller driver is
the
> > > > platform data, the obvious answer is a pointer to platform
data
> > > > (either for the PHY or for the controller, or maybe both).
> > >
> > > hmm.. it's not going to be simple though as the platform device for
> > > the PHY and controller can be created in entirely different places.
> > > e.g., in some cases the PHY device is a child of some mfd core
> > > device
> > > (the device will be created in drivers/mfd) and the controller
> > > driver
> > > (usually) is created in board file. I guess then we have to come up
> > > with something to share a pointer in two different files.
> >
> > The ability for two different source files to share a pointer to a
> > data
> > item defined in a third source file has been around since long before
> > the C language was invented. :-)
> >
> > In this case, it doesn't matter where the platform_device structures
> > are created or where the driver source code is. Let's take a simple
> > example. Suppose the system design includes a PHY named "foo". Then
> > the board file could contain:
> >
> > struct phy_info { ... } phy_foo;
> > EXPORT_SYMBOL_GPL(phy_foo);
> >
> > and a header file would contain:
> >
> > extern struct phy_info phy_foo;
> >
> > The PHY supplier could then call phy_create(_foo), and the PHY
> > client could call phy_find(_foo). Or something like that; make up
> > your own structure tags and function names.
> >
> > It's still possible to have conflicts, but now two PHYs with the same
> > name (or a misspelled name somewhere) will cause an error at link
> > time.
>
> This is incorrect, sorry. First of all it's a layering violation - you
> export random driver-specific symbols from one driver to another.
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Alan,
On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
> On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
> > > The PHY and the controller it is attached to are both physical
> > > devices.
> > >
> > > The connection between them is hardwired by the system
> > > manufacturer and cannot be changed by software.
> > >
> > > PHYs are generally described by fixed system-specific board
> > > files or by Device Tree information. Are they ever discovered
> > > dynamically?
> >
> > No. They are created just like any other platform devices are created.
>
> Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
> > > Is the same true for the controllers attached to the PHYs?
> > > If not -- if both a PHY and a controller are discovered
> > > dynamically -- how does the kernel know whether they are
> > > connected to each other?
> >
> > No differences here. Both PHY and controller will have dt information
> > or hwmod data using which platform devices will be created.
> >
> > > The kernel needs to know which controller is attached to which
> > > PHY. Currently this information is represented by name or ID
> > > strings embedded in platform data.
> >
> > right. It's embedded in the platform data of the controller.
>
> It must also be embedded in the PHY's platform data somehow.
> Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous replies.
Without any extra data in platform data. (I have even posted a code
example.)
> > > The PHY's driver (the supplier) uses the platform data to
> > > construct a platform_device structure that represents the PHY.
> >
> > Currently the driver assigns static labels (corresponding to the label
> > used in the platform data of the controller).
> >
> > > Until this is done, the controller's driver (the client) cannot
> > > use the PHY.
> >
> > right.
> >
> > > Since there is no parent-child relation between the PHY and the
> > > controller, there is no guarantee that the PHY's driver will be
> > > ready when the controller's driver wants to use it. A deferred
> > > probe may be needed.
> >
> > right.
> >
> > > The issue (or one of the issues) in this discussion is that
> > > Greg does not like the idea of using names or IDs to associate
> > > PHYs with controllers, because they are too prone to
> > > duplications or other errors. Pointers are more reliable.
> > >
> > > But pointers to what? Since the only data known to be
> > > available to both the PHY driver and controller driver is the
> > > platform data, the obvious answer is a pointer to platform data
> > > (either for the PHY or for the controller, or maybe both).
> >
> > hmm.. it's not going to be simple though as the platform device for
> > the PHY and controller can be created in entirely different places.
> > e.g., in some cases the PHY device is a child of some mfd core device
> > (the device will be created in drivers/mfd) and the controller driver
> > (usually) is created in board file. I guess then we have to come up
> > with something to share a pointer in two different files.
>
> The ability for two different source files to share a pointer to a data
> item defined in a third source file has been around since long before
> the C language was invented. :-)
>
> In this case, it doesn't matter where the platform_device structures
> are created or where the driver source code is. Let's take a simple
> example. Suppose the system design includes a PHY named "foo". Then
> the board file could contain:
>
> struct phy_info { ... } phy_foo;
> EXPORT_SYMBOL_GPL(phy_foo);
>
> and a header file would contain:
>
> extern struct phy_info phy_foo;
>
> The PHY supplier could then call phy_create(_foo), and the PHY
> client could call phy_find(_foo). Or something like that; make up
> your own structure tags and function names.
>
> It's still possible to have conflicts, but now two PHYs with the same
> name (or a misspelled name somewhere) will cause an error at link time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host drivers.
This means you would have to export symbol with the same name from both
PHY drivers, which obviously would not work in this case, because having
both drivers enabled (in a multiplatform aware configuration) would lead
to linking conflict.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Alan,
On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
The PHY and the controller it is attached to are both physical
devices.
The connection between them is hardwired by the system
manufacturer and cannot be changed by software.
PHYs are generally described by fixed system-specific board
files or by Device Tree information. Are they ever discovered
dynamically?
No. They are created just like any other platform devices are created.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
Is the same true for the controllers attached to the PHYs?
If not -- if both a PHY and a controller are discovered
dynamically -- how does the kernel know whether they are
connected to each other?
No differences here. Both PHY and controller will have dt information
or hwmod data using which platform devices will be created.
The kernel needs to know which controller is attached to which
PHY. Currently this information is represented by name or ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous replies.
Without any extra data in platform data. (I have even posted a code
example.)
The PHY's driver (the supplier) uses the platform data to
construct a platform_device structure that represents the PHY.
Currently the driver assigns static labels (corresponding to the label
used in the platform data of the controller).
Until this is done, the controller's driver (the client) cannot
use the PHY.
right.
Since there is no parent-child relation between the PHY and the
controller, there is no guarantee that the PHY's driver will be
ready when the controller's driver wants to use it. A deferred
probe may be needed.
right.
The issue (or one of the issues) in this discussion is that
Greg does not like the idea of using names or IDs to associate
PHYs with controllers, because they are too prone to
duplications or other errors. Pointers are more reliable.
But pointers to what? Since the only data known to be
available to both the PHY driver and controller driver is the
platform data, the obvious answer is a pointer to platform data
(either for the PHY or for the controller, or maybe both).
hmm.. it's not going to be simple though as the platform device for
the PHY and controller can be created in entirely different places.
e.g., in some cases the PHY device is a child of some mfd core device
(the device will be created in drivers/mfd) and the controller driver
(usually) is created in board file. I guess then we have to come up
with something to share a pointer in two different files.
The ability for two different source files to share a pointer to a data
item defined in a third source file has been around since long before
the C language was invented. :-)
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named foo. Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host drivers.
This means you would have to export symbol with the same name from both
PHY drivers, which obviously would not work in this case, because having
both drivers enabled (in a multiplatform aware configuration) would lead
to linking conflict.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
[Fixed address of devicetree mailing list and added more people on CC.]
For reference, full thread can be found under following link:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813
Best regards,
Tomasz
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
The PHY and the controller it is attached to are both
physical
devices.
The connection between them is hardwired by the system
manufacturer and cannot be changed by software.
PHYs are generally described by fixed system-specific
board
files or by Device Tree information. Are they ever
discovered
dynamically?
No. They are created just like any other platform devices are
created.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
Is the same true for the controllers attached to the PHYs?
If not -- if both a PHY and a controller are discovered
dynamically -- how does the kernel know whether they are
connected to each other?
No differences here. Both PHY and controller will have dt
information
or hwmod data using which platform devices will be created.
The kernel needs to know which controller is attached to
which
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even posted a
code example.)
The PHY's driver (the supplier) uses the platform data to
construct a platform_device structure that represents the
PHY.
Currently the driver assigns static labels (corresponding to the
label
used in the platform data of the controller).
Until this is done, the controller's driver (the client)
cannot
use the PHY.
right.
Since there is no parent-child relation between the PHY
and the
controller, there is no guarantee that the PHY's driver
will be
ready when the controller's driver wants to use it. A
deferred
probe may be needed.
right.
The issue (or one of the issues) in this discussion is
that
Greg does not like the idea of using names or IDs to
associate
PHYs with controllers, because they are too prone to
duplications or other errors. Pointers are more reliable.
But pointers to what? Since the only data known to be
available to both the PHY driver and controller driver is
the
platform data, the obvious answer is a pointer to platform
data
(either for the PHY or for the controller, or maybe both).
hmm.. it's not going to be simple though as the platform device for
the PHY and controller can be created in entirely different places.
e.g., in some cases the PHY device is a child of some mfd core
device
(the device will be created in drivers/mfd) and the controller
driver
(usually) is created in board file. I guess then we have to come up
with something to share a pointer in two different files.
The ability for two different source files to share a pointer to a
data
item defined in a third source file has been around since long before
the C language was invented. :-)
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named foo. Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even posted a
code example.)
I don't understand, because I don't know what a PHY lookup does.
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named foo. Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
No, that's not what I said. Neither the PHY driver nor the controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host
drivers. This means you would have to export symbol with the same name
from both PHY drivers, which obviously would not work in this case,
because having both drivers enabled (in a multiplatform aware
configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {phy1};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {phy1};
EXPORT_SYMBOL(host2);
And so on. This explicitly gives the connection between PHYs and
controllers. The PHY providers would use phy1 or phy2, and the PHY
consumers would use host1 or host2.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 10:37:05 Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even posted
a
code example.)
I don't understand, because I don't know what a PHY lookup does.
I have provided a code example in [1]. Feel free to ask questions about
those code snippets.
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=20889
In this case, it doesn't matter where the platform_device
structures
are created or where the driver source code is. Let's take a
simple
example. Suppose the system design includes a PHY named foo.
Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make
up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the
same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation -
you
export random driver-specific symbols from one driver to another.
Then
No, that's not what I said. Neither the PHY driver nor the controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
It's still a random, driver-specific global symbol exported from board file
to drivers.
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
and
there are two types of consumer drivers (e.g. USB host controllers).
Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host
drivers. This means you would have to export symbol with the same
name
from both PHY drivers, which obviously would not work in this case,
because having both drivers enabled (in a multiplatform aware
configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {phy1};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {phy1};
EXPORT_SYMBOL(host2);
And so on. This explicitly gives the connection between PHYs and
controllers. The PHY providers would use phy1 or phy2, and the PHY
consumers would use host1 or host2.
This could work assuming that only one SoC and one board is supported in
single kernel image. However it's not the case.
We've used to support multiple boards since a long time already and now for
selected platforms we even support multiplatform, i.e. multiple SoCs in
single zImage. Such solution will not work.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
Yes. I think we could use i2c_board_info for passing platform data.
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even posted a
code example.)
I don't understand, because I don't know what a PHY lookup does.
It is how the PHY framework finds a PHY, when the controller (say USB)requests
a PHY from the PHY framework.
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named foo. Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
No, that's not what I said. Neither the PHY driver nor the controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
I think instead we can use the same data while creating the platform data of
the controller and the PHY.
The PHY driver while creating the PHY (using PHY framework) will also pass the
*data* it actually got from the platform data to the framework.
The PHY user driver (USB), while requesting for the PHY (from the PHY
framework) will pass the *data* it got from its platform data.
The PHY framework can do a comparison of the *data* pointers it has and return
the appropriate PHY to the controller.
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host
drivers. This means you would have to export symbol with the same name
from both PHY drivers, which obviously would not work in this case,
because having both drivers enabled (in a multiplatform aware
configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {phy1};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {phy1};
EXPORT_SYMBOL(host2);
I meant something like this
struct phy_info {
const char *name;
};
struct phy_platform_data {
.
.
struct phy_info *info;
};
struct usb_controller_platform_data {
.
.
struct phy_info *info;
};
struct phy_info phy_info;
While creating the phy device
struct phy_platform_data phy_data;
phy_data.info = info;
platform_device_add_data(pdev, phy_data, sizeof(*phy_data))
platform_device_add();
While creating the controller device
struct usb_controller_platform_data controller_data;
controller_data.info = info;
platform_device_add_data(pdev, controller_data,
sizeof(*controller_data))
platform_device_add();
Then modify PHY framework API phy create
phy_create((struct device *dev, const struct phy_ops
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
Yes. I think we could use i2c_board_info for passing platform data.
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even posted a
code example.)
I don't understand, because I don't know what a PHY lookup does.
It is how the PHY framework finds a PHY, when the controller (say USB)requests
a PHY from the PHY framework.
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named foo. Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
No, that's not what I said. Neither the PHY driver nor the controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
I think instead we can use the same data while creating the platform data of
the controller and the PHY.
The PHY driver while creating the PHY (using PHY framework) will also pass the
*data* it actually got from the platform data to the framework.
The PHY user driver (USB), while requesting for the PHY (from the PHY
framework) will pass the *data* it got from its platform data.
The PHY framework can do a comparison of the *data* pointers it has and return
the appropriate PHY to the controller.
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host
drivers. This means you would have to export symbol with the same name
from both PHY drivers, which obviously would not work in this case,
because having both drivers enabled (in a multiplatform aware
configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {phy1};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {phy1};
EXPORT_SYMBOL(host2);
I meant something like this
struct phy_info {
const char *name;
};
struct phy_platform_data {
.
.
struct phy_info *info;
};
struct usb_controller_platform_data {
.
.
struct phy_info *info;
};
struct phy_info phy_info;
While creating the phy device
struct phy_platform_data phy_data;
phy_data.info = info;
platform_device_add_data(pdev, phy_data, sizeof(*phy_data))
platform_device_add();
While creating the controller device
struct usb_controller_platform_data controller_data;
controller_data.info = info;
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Greg,
On Tuesday 23 July 2013 09:48 PM, Greg KH wrote:
On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
.
.
snip
.
.
static struct phy *phy_lookup(void *priv) {
.
.
if (phy-priv==priv) //instead of string comparison, we'll use
pointer
return phy;
}
PHY driver should be like
phy_create((dev, ops, pdata-info);
The controller driver would do
phy_get(dev, NULL, pdata-info);
Now the PHY framework will check for a match of *priv* pointer and return
the PHY.
I think this should be possible?
Ick, no. Why can't you just pass the pointer to the phy itself? If you
had a priv pointer to search from, then you could have just passed the
original phy pointer in the first place, right?
The issue is that a string name is not going to scale at all, as it
requires hard-coded information that will change over time (as the
existing clock interface is already showing.)
Please just pass the real phy pointer around, that's what it is there
for. Your board binding logic/code should be able to handle this, as
it somehow was going to do the same thing with a name.
The problem is the board file won't have the *phy* pointer. *phy* pointer is
created at a much later time when the phy driver is probed.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 09:58:34PM +0530, Kishon Vijay Abraham I wrote:
Hi Greg,
On Tuesday 23 July 2013 09:48 PM, Greg KH wrote:
On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
.
.
snip
.
.
static struct phy *phy_lookup(void *priv) {
.
.
if (phy-priv==priv) //instead of string comparison, we'll use
pointer
return phy;
}
PHY driver should be like
phy_create((dev, ops, pdata-info);
The controller driver would do
phy_get(dev, NULL, pdata-info);
Now the PHY framework will check for a match of *priv* pointer and return
the PHY.
I think this should be possible?
Ick, no. Why can't you just pass the pointer to the phy itself? If you
had a priv pointer to search from, then you could have just passed the
original phy pointer in the first place, right?
The issue is that a string name is not going to scale at all, as it
requires hard-coded information that will change over time (as the
existing clock interface is already showing.)
Please just pass the real phy pointer around, that's what it is there
for. Your board binding logic/code should be able to handle this, as
it somehow was going to do the same thing with a name.
The problem is the board file won't have the *phy* pointer. *phy* pointer is
created at a much later time when the phy driver is probed.
Ok, then save it then, as no one could have used it before then, right?
All I don't want to see is any get by name/void * functions in the
api, as that way is fragile and will break, as people have already
shown.
Just pass the real pointer around. If that is somehow a problem, then
something larger is a problem with how board devices are tied together :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 09:18:46 Greg KH wrote:
On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever
parent?
Yes. I think we could use i2c_board_info for passing platform data.
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even
posted a
code example.)
I don't understand, because I don't know what a PHY lookup does.
It is how the PHY framework finds a PHY, when the controller (say
USB)requests a PHY from the PHY framework.
In this case, it doesn't matter where the platform_device
structures
are created or where the driver source code is. Let's take a
simple
example. Suppose the system design includes a PHY named foo.
Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that;
make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the
same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation -
you
export random driver-specific symbols from one driver to another.
Then
No, that's not what I said. Neither the PHY driver nor the
controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
I think instead we can use the same data while creating the platform
data of the controller and the PHY.
The PHY driver while creating the PHY (using PHY framework) will also
pass the *data* it actually got from the platform data to the
framework. The PHY user driver (USB), while requesting for the PHY
(from the PHY framework) will pass the *data* it got from its platform
data.
The PHY framework can do a comparison of the *data* pointers it has and
return the appropriate PHY to the controller.
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
and
there are two types of consumer drivers (e.g. USB host
controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host
drivers. This means you would have to export symbol with the same
name
from both PHY drivers, which obviously would not work in this case,
because having both drivers enabled (in a multiplatform aware
configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file
must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {phy1};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {phy1};
EXPORT_SYMBOL(host2);
I meant something like this
struct phy_info {
const char *name;
};
struct phy_platform_data {
.
.
struct phy_info *info;
};
struct usb_controller_platform_data {
.
.
struct phy_info *info;
};
struct phy_info phy_info;
While creating the phy device
struct phy_platform_data phy_data;
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
Ick, no. Why can't you just pass the pointer to the phy itself? If you
had a priv pointer to search from, then you could have just passed the
original phy pointer in the first place, right?
IMHO it would be better if you provided some code example, but let's try to
check if I understood you correctly.
It's not my code that I want to have added, so I don't have to write
examples, I just get to complain about the existing stuff :)
8
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
8
Is this what you mean?
No. Well, kind of. What's wrong with using the platform data structure
unique to the board to have the pointer?
For example (just randomly picking one), the ata-pxa driver would change
include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
struct phy;
struct pata_pxa_pdata {
/* PXA DMA DREQ0:2 pin */
uint32_tdma_dreq;
/* Register shift */
uint32_treg_shift;
/* IRQ flags */
uint32_tirq_flags;
/* PHY */
struct phy *phy;
};
Then, when you create the platform, set the phy* pointer with a call to
phy_create(). Then you can use that pointer wherever that plaform data
is available (i.e. whereever platform_data is at).
The issue is that a string name is not going to scale at all, as it
requires hard-coded information that will change over time (as the
existing clock interface is already showing.)
I fully agree that a simple, single string will not scale even in some, not
so uncommon cases, but there is already a lot of existing lookup solutions
over the kernel and so there is no point in introducing another one.
I'm trying to get _rid_ of lookup solutions and just use a real
pointer, as you should. I'll go tackle those other ones after this one
is taken care of, to show how the others should be handled as well.
Please just pass the real phy pointer around, that's what it is there
for. Your board binding logic/code should be able to handle this, as
it somehow was going to do the same thing with a name.
It's technically correct, but quality of this solution isn't really nice,
because it's a layering violation (at least if I understood what you mean).
This is because you need to have full definition of struct phy in board file
and a structure that is used as private data in PHY core comes from
platform code.
No, just a pointer, you don't need the full structure until you get to
some .c code that actually manipulates the phy itself, for all other
places, you are just dealing with a pointer and a structure you never
reference.
Does that make more sense?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:37:05AM -0400, Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Okay. Are PHYs _always_ platform devices? They can be i2c, spi or any other device types as well. In those other cases, presumably there is no platform data associated with the PHY since it isn't a platform device. Then how does the kernel know which controller is attached to the PHY? Is this spelled out in platform data associated with the PHY's i2c/spi/whatever parent? Platform data is nothing to do with the platform bus - it's board specific data (ie, data for the platform) and can be done with any device. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote: On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote: I fully agree that a simple, single string will not scale even in some, not so uncommon cases, but there is already a lot of existing lookup solutions over the kernel and so there is no point in introducing another one. I'm trying to get _rid_ of lookup solutions and just use a real pointer, as you should. I'll go tackle those other ones after this one is taken care of, to show how the others should be handled as well. What are the problems you are seeing with doing things with lookups? Having to write platform data for everything gets old fast and the code duplication is pretty tedious... signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
Ick, no. Why can't you just pass the pointer to the phy itself? If
you
had a priv pointer to search from, then you could have just passed
the
original phy pointer in the first place, right?
IMHO it would be better if you provided some code example, but let's
try to check if I understood you correctly.
It's not my code that I want to have added, so I don't have to write
examples, I just get to complain about the existing stuff :)
Still, I think that some small code snippets illustrating the idea are
really helpful.
8
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
---
-8
Is this what you mean?
No. Well, kind of. What's wrong with using the platform data structure
unique to the board to have the pointer?
For example (just randomly picking one), the ata-pxa driver would change
include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
struct phy;
struct pata_pxa_pdata {
/* PXA DMA DREQ0:2 pin */
uint32_tdma_dreq;
/* Register shift */
uint32_treg_shift;
/* IRQ flags */
uint32_tirq_flags;
/* PHY */
struct phy *phy;
};
Then, when you create the platform, set the phy* pointer with a call to
phy_create(). Then you can use that pointer wherever that plaform data
is available (i.e. whereever platform_data is at).
Hmm? So, do you suggest to call phy_create() from board file? What phy_ops
struct and other hardware parameters would it take?
The issue is that a string name is not going to scale at all, as it
requires hard-coded information that will change over time (as the
existing clock interface is already showing.)
I fully agree that a simple, single string will not scale even in some,
not so uncommon cases, but there is already a lot of existing lookup
solutions over the kernel and so there is no point in introducing
another one.
I'm trying to get _rid_ of lookup solutions and just use a real
pointer, as you should. I'll go tackle those other ones after this one
is taken care of, to show how the others should be handled as well.
There was a reason for introducing lookup solutions. The reason was that in
board file there is no way to get a pointer to something that is going to be
created much later in time. We don't do time travel ;-).
Please just pass the real phy pointer around, that's what it is
there
for. Your board binding logic/code should be able to handle this,
as
it somehow was going to do the same thing with a name.
It's technically correct, but quality of this solution isn't really
nice, because it's a layering violation (at least if I understood what
you mean). This is because you need to have full definition of struct
phy in board file and a structure that is used as private data in PHY
core comes from platform code.
No, just a pointer, you don't need the full structure until you get to
some .c code that actually manipulates the phy itself, for all other
places, you are just dealing with a pointer and a structure you never
reference.
Does that make more sense?
Well, to the point that I think I now understood your suggestion.
Unfortunately the suggestion alone isn't really something that can be done,
considering how driver core and generic frameworks work.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote: On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote: On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote: I fully agree that a simple, single string will not scale even in some, not so uncommon cases, but there is already a lot of existing lookup solutions over the kernel and so there is no point in introducing another one. I'm trying to get _rid_ of lookup solutions and just use a real pointer, as you should. I'll go tackle those other ones after this one is taken care of, to show how the others should be handled as well. What are the problems you are seeing with doing things with lookups? You don't know the id of the device you are looking up, due to multiple devices being in the system (dynamic ids, look back earlier in this thread for details about that.) Having to write platform data for everything gets old fast and the code duplication is pretty tedious... Adding a single pointer is tedious? Where is the name that you are going to lookup going to come from? That code doesn't write itself... thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
Ick, no. Why can't you just pass the pointer to the phy itself? If
you
had a priv pointer to search from, then you could have just passed
the
original phy pointer in the first place, right?
IMHO it would be better if you provided some code example, but let's
try to check if I understood you correctly.
It's not my code that I want to have added, so I don't have to write
examples, I just get to complain about the existing stuff :)
Still, I think that some small code snippets illustrating the idea are
really helpful.
8
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
---
-8
Is this what you mean?
No. Well, kind of. What's wrong with using the platform data structure
unique to the board to have the pointer?
For example (just randomly picking one), the ata-pxa driver would change
include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
struct phy;
struct pata_pxa_pdata {
/* PXA DMA DREQ0:2 pin */
uint32_tdma_dreq;
/* Register shift */
uint32_treg_shift;
/* IRQ flags */
uint32_tirq_flags;
/* PHY */
struct phy *phy;
};
Then, when you create the platform, set the phy* pointer with a call to
phy_create(). Then you can use that pointer wherever that plaform data
is available (i.e. whereever platform_data is at).
Hmm? So, do you suggest to call phy_create() from board file? What phy_ops
struct and other hardware parameters would it take?
The issue is that a string name is not going to scale at all, as it
requires hard-coded information that will change over time (as the
existing clock interface is already showing.)
I fully agree that a simple, single string will not scale even in some,
not so uncommon cases, but there is already a lot of existing lookup
solutions over the kernel and so there is no point in introducing
another one.
I'm trying to get _rid_ of lookup solutions and just use a real
pointer, as you should. I'll go tackle those other ones after this one
is taken care of, to show how the others should be handled as well.
There was a reason for introducing lookup solutions. The reason was that in
board file there is no way to get a pointer to something that is going to be
created much later in time. We don't do time travel ;-).
Please just pass the real phy pointer around, that's what it is
there
for. Your board binding logic/code should be able to handle this,
as
it somehow was going to do the same thing with a name.
It's technically correct, but quality of this solution isn't really
nice, because it's a layering violation (at least if I understood what
you mean). This is because you need to have full definition of struct
phy in board file and a structure that is used as private data in PHY
core comes from platform code.
No, just a pointer, you don't need the full structure until you get to
some .c code that actually manipulates the phy itself, for all other
places, you are just dealing with a pointer and a structure you never
reference.
Does that make more sense?
Well, to the point that I think I now understood your suggestion.
Unfortunately the suggestion alone isn't really something that can be done,
considering how driver core and generic frameworks work.
Ok, given that I seem to be totally confused as to exactly how the
board-specific frameworks work, I'll take your word for it.
But again, I will not accept lookup by name type solutions, when the
name is dynamic and will change. Because you are using a name, you
can deal with a pointer, putting it _somewhere_ in your board-specific
data structures, as you are going to need to store it anyway (hint, you
had to get that name from somewhere, right?)
And maybe the way that these generic frameworks are created is wrong,
given that you don't feel that a generic pointer can be passed to the
needed devices. That seems like a huge problem, one that has already
been pointed out is causing issues with other subsystems.
So maybe they need to be fixed?
thanks,
greg k-h
--
To
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 11:01:10AM -0700, Greg KH wrote: On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote: What are the problems you are seeing with doing things with lookups? You don't know the id of the device you are looking up, due to multiple devices being in the system (dynamic ids, look back earlier in this thread for details about that.) I got copied in very late so don't have most of the thread I'm afraid, I did try looking at web archives but didn't see a clear problem statement. In any case this is why the APIs doing lookups do the lookups in the context of the requesting device - devices ask for whatever name they use locally. Having to write platform data for everything gets old fast and the code duplication is pretty tedious... Adding a single pointer is tedious? Where is the name that you are going to lookup going to come from? That code doesn't write itself... It's adding platform data in the first place that gets tedious - and of course there's also DT and ACPI to worry about, it's not just a case of platform data and then you're done. Pushing the lookup into library code means that drivers don't have to worry about any of this stuff. For most of the APIs doing this there is a clear and unambiguous name in the hardware that can be used (and for hardware process reasons is unlikely to get changed). The major exception to this is the clock API since it is relatively rare to have clear, segregated IP level information for IPs baked into larger chips. The other APIs tend to be establishing chip to chip links. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote:
IMHO it would be better if you provided some code example, but let's try to
check if I understood you correctly.
8
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
This should be controller_pdev, not phy_pdev, yes?
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
Or even just phy_get(pdev-dev), because phy_get() could be smart
enough to to set phy = dev-platform_data.
8
Is this what you mean?
That's what I was going to suggest too. The struct phy is defined in
the board file, which already knows about all the PHYs that exist in
the system. (Or perhaps it is allocated dynamically, so that when many
board files are present in the same kernel, only the entries listed in
the board file for the current system get created.) Then the
structure's address is stored in the platform data and made available
to both the provider and the consumer.
Even though the struct phy is defined (or allocated) in the board file,
its contents don't get filled in until the PHY driver provides the
details.
It's technically correct, but quality of this solution isn't really nice,
because it's a layering violation (at least if I understood what you mean).
This is because you need to have full definition of struct phy in board file
and a structure that is used as private data in PHY core comes from
platform code.
You don't have to have a full definition in the board file. Just a
partial definition -- most of the contents can be filled in later, when
the PHY driver is ready to store the private data.
It's not a layering violation for one region of the kernel to store
private data in a structure defined by another part of the kernel.
This happens all the time (e.g., dev_set_drvdata).
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote: You don't know the id of the device you are looking up, due to multiple devices being in the system (dynamic ids, look back earlier in this thread for details about that.) I got copied in very late so don't have most of the thread I'm afraid, I did try looking at web archives but didn't see a clear problem statement. In any case this is why the APIs doing lookups do the lookups in the context of the requesting device - devices ask for whatever name they use locally. What do you mean by locally? The problem with the api was that the phy core wanted a id and a name to create a phy, and then later other code was doing a lookup based on the name and id (mushed together), because it knew that this device was the one it wanted. Just like the clock api, which, for multiple devices, has proven to cause problems. I don't want to see us accept an api that we know has issues in it now, I'd rather us fix it up properly. Subsystems should be able to create ids how ever they want to, and not rely on the code calling them to specify the names of the devices that way, otherwise the api is just too fragile. I think, that if you create a device, then just carry around the pointer to that device (in this case a phy) and pass it to whatever other code needs it. No need to do lookups on known names or anything else, just normal pointers, with no problems for multiple devices, busses, or naming issues. Having to write platform data for everything gets old fast and the code duplication is pretty tedious... Adding a single pointer is tedious? Where is the name that you are going to lookup going to come from? That code doesn't write itself... It's adding platform data in the first place that gets tedious - and of course there's also DT and ACPI to worry about, it's not just a case of platform data and then you're done. Pushing the lookup into library code means that drivers don't have to worry about any of this stuff. I agree, so just pass around the pointer to the phy and all is good. No need to worry about DT or ACPI or anything else. For most of the APIs doing this there is a clear and unambiguous name in the hardware that can be used (and for hardware process reasons is unlikely to get changed). The major exception to this is the clock API since it is relatively rare to have clear, segregated IP level information for IPs baked into larger chips. The other APIs tend to be establishing chip to chip links. The clock api is having problems with multiple names due to dynamic devices from what I was told. I want to prevent the PHY interface from having that same issue. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
You don't know the id of the device you are looking up, due to
multiple devices being in the system (dynamic ids, look back earlier
in
this thread for details about that.)
I got copied in very late so don't have most of the thread I'm afraid,
I did try looking at web archives but didn't see a clear problem
statement. In any case this is why the APIs doing lookups do the
lookups in the context of the requesting device - devices ask for
whatever name they use locally.
What do you mean by locally?
The problem with the api was that the phy core wanted a id and a name to
create a phy, and then later other code was doing a lookup based on
the name and id (mushed together), because it knew that this device
was the one it wanted.
Just like the clock api, which, for multiple devices, has proven to
cause problems. I don't want to see us accept an api that we know has
issues in it now, I'd rather us fix it up properly.
Subsystems should be able to create ids how ever they want to, and not
rely on the code calling them to specify the names of the devices that
way, otherwise the api is just too fragile.
I think, that if you create a device, then just carry around the pointer
to that device (in this case a phy) and pass it to whatever other code
needs it. No need to do lookups on known names or anything else,
just normal pointers, with no problems for multiple devices, busses, or
naming issues.
PHY object is not a device, it is something that a device driver creates
(one or more instances of) when it is being probed. You don't have a clean
way to export this PHY object to other driver, other than keeping this PHY
on a list inside PHY core with some well-known ID (e.g. device name +
consumer port name/index, like in regulator core) and then to use this
well-known ID inside consumer driver as a lookup key passed to phy_get();
Actually I think for PHY case, exactly the same way as used for regulators
might be completely fine:
1. Each PHY would have some kind of platform, non-unique name, that is
just used to print some messages (like the platform/board name of a
regulator).
2. Each PHY would have an array of consumers. Consumer specifier would
consist of consumer device name and consumer port name - just like in
regulator subsystem.
3. PHY driver receives an array of, let's say, phy_init_data inside its
platform data that it would use to register its PHYs.
4. Consumer drivers would have constant consumer port names and wouldn't
receive any information about PHYs from platform code.
Code example:
[Board file]
static const struct phy_consumer_data usb_20_phy0_consumers[] = {
{
.devname = foo-ehci,
.port = usbphy,
},
};
static const struct phy_consumer_data usb_20_phy1_consumers[] = {
{
.devname = foo-otg,
.port = otgphy,
},
};
static const struct phy_init_data my_phys[] = {
{
.name = USB 2.0 PHY 0,
.consumers = usb_20_phy0_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
},
{
.name = USB 2.0 PHY 1,
.consumers = usb_20_phy1_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
},
{ }
};
static const struct platform_device usb_phy_pdev = {
.name = foo-usbphy,
.id = -1,
.dev = {
.platform_data = my_phys,
},
};
[PHY driver]
static int foo_usbphy_probe(pdev)
{
struct foo_usbphy *foo;
struct phy_init_data *init_data = pdev-dev.platform_data;
/* ... */
// for each PHY in init_data {
phy_register(foo-phy[i], init_data[i]);
// }
/* ... */
}
[EHCI driver]
static int foo_ehci_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, usbphy);
/* ... */
}
[OTG driver]
static int foo_otg_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, otgphy);
/* ... */
}
Having to write platform data for everything gets old fast and the
code
duplication is pretty tedious...
Adding a single pointer is tedious? Where is the name that you
are
going to lookup going to come from? That code doesn't write
itself...
It's adding platform data in the first place that gets tedious - and
of
course there's also DT and ACPI to worry about, it's not just a case
of
platform data and then you're done. Pushing the lookup into library
code means that drivers don't have to worry about any of this stuff.
I agree, so just pass around the pointer to the phy and all is good. No
need to worry about DT or ACPI or anything else.
With Device Tree we don't have board files anymore. How would
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 15:36:00 Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
IMHO it would be better if you provided some code example, but let's
try to check if I understood you correctly.
8---
-
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
This should be controller_pdev, not phy_pdev, yes?
Right. A copy-pasto.
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
Or even just phy_get(pdev-dev), because phy_get() could be smart
enough to to set phy = dev-platform_data.
Unless you need more than one PHY in this driver...
--
--8
Is this what you mean?
That's what I was going to suggest too. The struct phy is defined in
the board file, which already knows about all the PHYs that exist in
the system. (Or perhaps it is allocated dynamically, so that when many
board files are present in the same kernel, only the entries listed in
the board file for the current system get created.)
Well, such dynamic allocation is a must. We don't accept non-multiplatform
aware code anymore, not even saying about multiboard.
Then the
structure's address is stored in the platform data and made available
to both the provider and the consumer.
Yes, technically this can work. You would still have to perform some kind
of synchronization to make sure that the PHY bound to this structure is
actually present. This is again technically doable (e.g. a list of
registered struct phys inside PHY core).
Even though the struct phy is defined (or allocated) in the board file,
its contents don't get filled in until the PHY driver provides the
details.
You can't assure this. Board file is free to do whatever it wants with
this struct. A clean solution would prevent this.
It's technically correct, but quality of this solution isn't really
nice, because it's a layering violation (at least if I understood
what you mean). This is because you need to have full definition of
struct phy in board file and a structure that is used as private data
in PHY core comes from platform code.
You don't have to have a full definition in the board file. Just a
partial definition -- most of the contents can be filled in later, when
the PHY driver is ready to store the private data.
It's not a layering violation for one region of the kernel to store
private data in a structure defined by another part of the kernel.
This happens all the time (e.g., dev_set_drvdata).
Not really. The phy struct is something that _is_ private data of PHY
subsystem, not something that can store private data of PHY subsystem
(sure it can store private data of particular PHY driver, but that's
another story) and only PHY subsystem should have access to its contents.
By the way, we need to consider other cases here as well, for example it
would be nice to have a single phy_get() function that works for both non-
DT and DT cases to make the consumer driver not have to worry whether it's
being probed from DT or not.
I'd suggest simply reusing the lookup method of regulator framework, just
as I suggested here:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=101661
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 11:04:14 Greg KH wrote:
On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
Ick, no. Why can't you just pass the pointer to the phy itself?
If
you
had a priv pointer to search from, then you could have just
passed
the
original phy pointer in the first place, right?
IMHO it would be better if you provided some code example, but
let's
try to check if I understood you correctly.
It's not my code that I want to have added, so I don't have to write
examples, I just get to complain about the existing stuff :)
Still, I think that some small code snippets illustrating the idea are
really helpful.
8---
-
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
--
-
-8
Is this what you mean?
No. Well, kind of. What's wrong with using the platform data
structure unique to the board to have the pointer?
For example (just randomly picking one), the ata-pxa driver would
change include/linux/platform_data/ata-pxa.h to have a phy pointer
in it:
struct phy;
struct pata_pxa_pdata {
/* PXA DMA DREQ0:2 pin */
uint32_tdma_dreq;
/* Register shift */
uint32_treg_shift;
/* IRQ flags */
uint32_tirq_flags;
/* PHY */
struct phy *phy;
};
Then, when you create the platform, set the phy* pointer with a call
to
phy_create(). Then you can use that pointer wherever that plaform
data
is available (i.e. whereever platform_data is at).
Hmm? So, do you suggest to call phy_create() from board file? What
phy_ops struct and other hardware parameters would it take?
The issue is that a string name is not going to scale at all,
as it
requires hard-coded information that will change over time (as
the
existing clock interface is already showing.)
I fully agree that a simple, single string will not scale even in
some,
not so uncommon cases, but there is already a lot of existing
lookup
solutions over the kernel and so there is no point in introducing
another one.
I'm trying to get _rid_ of lookup solutions and just use a real
pointer, as you should. I'll go tackle those other ones after this
one
is taken care of, to show how the others should be handled as well.
There was a reason for introducing lookup solutions. The reason was
that in board file there is no way to get a pointer to something that
is going to be created much later in time. We don't do time travel
;-).
Please just pass the real phy pointer around, that's what it
is
there
for. Your board binding logic/code should be able to handle
this,
as
it somehow was going to do the same thing with a name.
It's technically correct, but quality of this solution isn't
really
nice, because it's a layering violation (at least if I understood
what
you mean). This is because you need to have full definition of
struct
phy in board file and a structure that is used as private data in
PHY
core comes from platform code.
No, just a pointer, you don't need the full structure until you
get to some .c code that actually manipulates the phy itself, for
all other places, you are just dealing with a pointer and a
structure you never reference.
Does that make more sense?
Well, to the point that I think I now understood your suggestion.
Unfortunately the suggestion alone isn't really something that can be
done, considering how driver core and generic frameworks work.
Ok, given that I seem to be totally confused as to exactly how the
board-specific frameworks work, I'll take your word for it.
Well, they are working in a way that keeps separation of layers, making
things clean. Platform code should not (well, there might exist some in
tree hacks, but this should not be propagated) used to exchange data
between drivers, but rather to specify board specific parameters for
generic drivers. If drivers need to cooperate, there must be a dedicated
interface for
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
You don't know the id of the device you are looking up, due to
multiple devices being in the system (dynamic ids, look back earlier
in
this thread for details about that.)
I got copied in very late so don't have most of the thread I'm afraid,
I did try looking at web archives but didn't see a clear problem
statement. In any case this is why the APIs doing lookups do the
lookups in the context of the requesting device - devices ask for
whatever name they use locally.
What do you mean by locally?
The problem with the api was that the phy core wanted a id and a name to
create a phy, and then later other code was doing a lookup based on
the name and id (mushed together), because it knew that this device
was the one it wanted.
Just like the clock api, which, for multiple devices, has proven to
cause problems. I don't want to see us accept an api that we know has
issues in it now, I'd rather us fix it up properly.
Subsystems should be able to create ids how ever they want to, and not
rely on the code calling them to specify the names of the devices that
way, otherwise the api is just too fragile.
I think, that if you create a device, then just carry around the pointer
to that device (in this case a phy) and pass it to whatever other code
needs it. No need to do lookups on known names or anything else,
just normal pointers, with no problems for multiple devices, busses, or
naming issues.
PHY object is not a device, it is something that a device driver creates
(one or more instances of) when it is being probed.
But you created a 'struct device' for it, so I think of it as a device
be it virtual or real :)
You don't have a clean way to export this PHY object to other driver,
other than keeping this PHY on a list inside PHY core with some
well-known ID (e.g. device name + consumer port name/index, like in
regulator core) and then to use this well-known ID inside consumer
driver as a lookup key passed to phy_get();
Actually I think for PHY case, exactly the same way as used for
regulators might be completely fine:
1. Each PHY would have some kind of platform, non-unique name, that is
just used to print some messages (like the platform/board name of a
regulator).
2. Each PHY would have an array of consumers. Consumer specifier would
consist of consumer device name and consumer port name - just like in
regulator subsystem.
3. PHY driver receives an array of, let's say, phy_init_data inside its
platform data that it would use to register its PHYs.
4. Consumer drivers would have constant consumer port names and wouldn't
receive any information about PHYs from platform code.
Code example:
[Board file]
static const struct phy_consumer_data usb_20_phy0_consumers[] = {
{
.devname = foo-ehci,
.port = usbphy,
},
};
static const struct phy_consumer_data usb_20_phy1_consumers[] = {
{
.devname = foo-otg,
.port = otgphy,
},
};
static const struct phy_init_data my_phys[] = {
{
.name = USB 2.0 PHY 0,
.consumers = usb_20_phy0_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
},
{
.name = USB 2.0 PHY 1,
.consumers = usb_20_phy1_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
},
{ }
};
static const struct platform_device usb_phy_pdev = {
.name = foo-usbphy,
.id = -1,
.dev = {
.platform_data = my_phys,
},
};
[PHY driver]
static int foo_usbphy_probe(pdev)
{
struct foo_usbphy *foo;
struct phy_init_data *init_data = pdev-dev.platform_data;
/* ... */
// for each PHY in init_data {
phy_register(foo-phy[i], init_data[i]);
// }
/* ... */
}
[EHCI driver]
static int foo_ehci_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, usbphy);
/* ... */
}
[OTG driver]
static int foo_otg_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, otgphy);
/* ... */
}
That's not so bad, as long as you let the phy core use whatever name it
wants for the device when it registers it with sysfs. Use the name you
are requesting as a tag or some such hint as to what the phy can be
looked up by.
Good luck handling duplicate tags :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote: That's what I was going to suggest too. The struct phy is defined in the board file, which already knows about all the PHYs that exist in the system. (Or perhaps it is allocated dynamically, so that when many board files are present in the same kernel, only the entries listed in the board file for the current system get created.) Well, such dynamic allocation is a must. We don't accept non-multiplatform aware code anymore, not even saying about multiboard. Then the structure's address is stored in the platform data and made available to both the provider and the consumer. Yes, technically this can work. You would still have to perform some kind of synchronization to make sure that the PHY bound to this structure is actually present. This is again technically doable (e.g. a list of registered struct phys inside PHY core). The synchronization takes place inside phy_get. If phy_create hasn't been called for this structure by the time phy_get runs, phy_get will return an error. Even though the struct phy is defined (or allocated) in the board file, its contents don't get filled in until the PHY driver provides the details. You can't assure this. Board file is free to do whatever it wants with this struct. A clean solution would prevent this. I'm not sure what you mean here. Of course I can't prevent a board file from messing up a data structure. I can't prevent it from causing memory access violations either; in fact, I can't prevent any bugs in other people's code. Besides, why do you say the board file is free to do whatever it wants with the struct phy? Currently the struct phy is created by the PHY provider and the PHY core, right? It's not even mentioned in the board file. It's technically correct, but quality of this solution isn't really nice, because it's a layering violation (at least if I understood what you mean). This is because you need to have full definition of struct phy in board file and a structure that is used as private data in PHY core comes from platform code. You don't have to have a full definition in the board file. Just a partial definition -- most of the contents can be filled in later, when the PHY driver is ready to store the private data. It's not a layering violation for one region of the kernel to store private data in a structure defined by another part of the kernel. This happens all the time (e.g., dev_set_drvdata). Not really. The phy struct is something that _is_ private data of PHY subsystem, not something that can store private data of PHY subsystem (sure it can store private data of particular PHY driver, but that's another story) and only PHY subsystem should have access to its contents. If you want to keep the phy struct completely separate from the board file, there's an easy way to do it. Let's say the board file knows about N different PHYs in the system. Then you define an array of N pointers to phys: struct phy *(phy_address[N]); In the platform data for both PHY j and its controller, store phy_address[j]. The PHY provider passes this cookie to phy_create: cookie = pdev-dev.platform_data; ret = phy_create(phy, cookie); and phy_create simply stores: *cookie = phy. The PHY consumer does much the same the same thing: cookie = pdev-dev.platform_data; phy = phy_get(cookie); phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. By the way, we need to consider other cases here as well, for example it would be nice to have a single phy_get() function that works for both non- DT and DT cases to make the consumer driver not have to worry whether it's being probed from DT or not. You ought to be able to adapt this scheme to work with DT. Maybe by having multiple phy_address arrays. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 16:53:55 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: That's what I was going to suggest too. The struct phy is defined in the board file, which already knows about all the PHYs that exist in the system. (Or perhaps it is allocated dynamically, so that when many board files are present in the same kernel, only the entries listed in the board file for the current system get created.) Well, such dynamic allocation is a must. We don't accept non-multiplatform aware code anymore, not even saying about multiboard. Then the structure's address is stored in the platform data and made available to both the provider and the consumer. Yes, technically this can work. You would still have to perform some kind of synchronization to make sure that the PHY bound to this structure is actually present. This is again technically doable (e.g. a list of registered struct phys inside PHY core). The synchronization takes place inside phy_get. If phy_create hasn't been called for this structure by the time phy_get runs, phy_get will return an error. Yes, this is the solution that I had in mind when saying that this is doable. Even though the struct phy is defined (or allocated) in the board file, its contents don't get filled in until the PHY driver provides the details. You can't assure this. Board file is free to do whatever it wants with this struct. A clean solution would prevent this. I'm not sure what you mean here. Of course I can't prevent a board file from messing up a data structure. I can't prevent it from causing memory access violations either; in fact, I can't prevent any bugs in other people's code. Besides, why do you say the board file is free to do whatever it wants with the struct phy? Currently the struct phy is created by the PHY provider and the PHY core, right? It's not even mentioned in the board file. I mean, if you have a struct type of which full declaration is available for some code, this code can access any memeber of it without any hacks, which is not something that we want to have in board files. The phy struct should be opaque for them. It's technically correct, but quality of this solution isn't really nice, because it's a layering violation (at least if I understood what you mean). This is because you need to have full definition of struct phy in board file and a structure that is used as private data in PHY core comes from platform code. You don't have to have a full definition in the board file. Just a partial definition -- most of the contents can be filled in later, when the PHY driver is ready to store the private data. It's not a layering violation for one region of the kernel to store private data in a structure defined by another part of the kernel. This happens all the time (e.g., dev_set_drvdata). Not really. The phy struct is something that _is_ private data of PHY subsystem, not something that can store private data of PHY subsystem (sure it can store private data of particular PHY driver, but that's another story) and only PHY subsystem should have access to its contents. If you want to keep the phy struct completely separate from the board file, there's an easy way to do it. Let's say the board file knows about N different PHYs in the system. Then you define an array of N pointers to phys: struct phy *(phy_address[N]); In the platform data for both PHY j and its controller, store phy_address[j]. The PHY provider passes this cookie to phy_create: cookie = pdev-dev.platform_data; ret = phy_create(phy, cookie); and phy_create simply stores: *cookie = phy. The PHY consumer does much the same the same thing: cookie = pdev-dev.platform_data; phy = phy_get(cookie); phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. OK, this can work. Again, just technically, because it's rather ugly. By the way, we need to consider other cases here as well, for example it would be nice to have a single phy_get() function that works for both non- DT and DT cases to make the consumer driver not have to worry whether it's being probed from DT or not. You ought to be able to adapt this scheme to work with DT. Maybe by having multiple phy_address arrays. Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. Anyway, board file should not be considered as a method to exchange data between drivers. It should be used only to pass data from it to drivers, not the other way. Ideally all data in a board file should be marked as const and __init and dropped after system initialization. Best regards, Tomasz -- To
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote: If you want to keep the phy struct completely separate from the board file, there's an easy way to do it. Let's say the board file knows about N different PHYs in the system. Then you define an array of N pointers to phys: struct phy *(phy_address[N]); In the platform data for both PHY j and its controller, store phy_address[j]. The PHY provider passes this cookie to phy_create: cookie = pdev-dev.platform_data; ret = phy_create(phy, cookie); and phy_create simply stores: *cookie = phy. The PHY consumer does much the same the same thing: cookie = pdev-dev.platform_data; phy = phy_get(cookie); phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. OK, this can work. Again, just technically, because it's rather ugly. There's no reason the phy_address things have to be arrays. A separate individual pointer for each PHY would work just as well. Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? Anyway, board file should not be considered as a method to exchange data between drivers. It should be used only to pass data from it to drivers, not the other way. Ideally all data in a board file should be marked as const and __init and dropped after system initialization. The phy_address things don't have to be defined or allocated in the board file; they could be set up along with the platform data. In any case, this was simply meant to be a suggestion to show that it is relatively easy to do what you need without using name or ID strings. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 13:50:07 Greg KH wrote:
On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
You don't know the id of the device you are looking up, due to
multiple devices being in the system (dynamic ids, look back
earlier
in
this thread for details about that.)
I got copied in very late so don't have most of the thread I'm
afraid,
I did try looking at web archives but didn't see a clear problem
statement. In any case this is why the APIs doing lookups do the
lookups in the context of the requesting device - devices ask for
whatever name they use locally.
What do you mean by locally?
The problem with the api was that the phy core wanted a id and a
name to create a phy, and then later other code was doing a
lookup based on the name and id (mushed together), because it
knew that this device was the one it wanted.
Just like the clock api, which, for multiple devices, has proven to
cause problems. I don't want to see us accept an api that we know
has
issues in it now, I'd rather us fix it up properly.
Subsystems should be able to create ids how ever they want to, and
not
rely on the code calling them to specify the names of the devices
that
way, otherwise the api is just too fragile.
I think, that if you create a device, then just carry around the
pointer to that device (in this case a phy) and pass it to whatever
other code needs it. No need to do lookups on known names or
anything else, just normal pointers, with no problems for multiple
devices, busses, or naming issues.
PHY object is not a device, it is something that a device driver
creates (one or more instances of) when it is being probed.
But you created a 'struct device' for it, so I think of it as a device
be it virtual or real :)
Keep in mind that those virtual devices are created by PHY driver bound to
a real device and one real device can have multiple virtual devices behind
it.
You don't have a clean way to export this PHY object to other driver,
other than keeping this PHY on a list inside PHY core with some
well-known ID (e.g. device name + consumer port name/index, like in
regulator core) and then to use this well-known ID inside consumer
driver as a lookup key passed to phy_get();
Actually I think for PHY case, exactly the same way as used for
regulators might be completely fine:
1. Each PHY would have some kind of platform, non-unique name, that is
just used to print some messages (like the platform/board name of a
regulator).
2. Each PHY would have an array of consumers. Consumer specifier would
consist of consumer device name and consumer port name - just like in
regulator subsystem.
3. PHY driver receives an array of, let's say, phy_init_data inside
its
platform data that it would use to register its PHYs.
4. Consumer drivers would have constant consumer port names and
wouldn't receive any information about PHYs from platform code.
Code example:
[Board file]
static const struct phy_consumer_data usb_20_phy0_consumers[] = {
{
.devname = foo-ehci,
.port = usbphy,
},
};
static const struct phy_consumer_data usb_20_phy1_consumers[] = {
{
.devname = foo-otg,
.port = otgphy,
},
};
static const struct phy_init_data my_phys[] = {
{
.name = USB 2.0 PHY 0,
.consumers = usb_20_phy0_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
},
{
.name = USB 2.0 PHY 1,
.consumers = usb_20_phy1_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
},
{ }
};
static const struct platform_device usb_phy_pdev = {
.name = foo-usbphy,
.id = -1,
.dev = {
.platform_data = my_phys,
},
};
[PHY driver]
static int foo_usbphy_probe(pdev)
{
struct foo_usbphy *foo;
struct phy_init_data *init_data = pdev-dev.platform_data;
/* ... */
// for each PHY in init_data {
phy_register(foo-phy[i], init_data[i]);
// }
/* ... */
}
[EHCI driver]
static int foo_ehci_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, usbphy);
/* ... */
}
[OTG driver]
static int foo_otg_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, otgphy);
/* ... */
}
That's not so bad, as long as you let the phy core use whatever name it
wants for the device when it registers it with sysfs.
Yes, in regulator core
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 11:05:48PM +0200, Tomasz Figa wrote: That's not so bad, as long as you let the phy core use whatever name it wants for the device when it registers it with sysfs. Yes, in regulator core consumer names are completely separated from this. Regulator core simply assigns a sequential integer ID to each regulator and registers /sys/class/regulator/regulator.ID for each regulator. Yes, that's fine. Use the name you are requesting as a tag or some such hint as to what the phy can be looked up by. Good luck handling duplicate tags :) The tag alone is not a key. Lookup key consists of two components, consumer device name and consumer tag. What kind of duplicate tags can be a problem here? Ok, I didn't realize it looked at both parts, that makes sense, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: If you want to keep the phy struct completely separate from the board file, there's an easy way to do it. Let's say the board file knows about N different PHYs in the system. Then you define an array of N pointers to phys: struct phy *(phy_address[N]); In the platform data for both PHY j and its controller, store phy_address[j]. The PHY provider passes this cookie to phy_create: cookie = pdev-dev.platform_data; ret = phy_create(phy, cookie); and phy_create simply stores: *cookie = phy. The PHY consumer does much the same the same thing: cookie = pdev-dev.platform_data; phy = phy_get(cookie); phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. OK, this can work. Again, just technically, because it's rather ugly. There's no reason the phy_address things have to be arrays. A separate individual pointer for each PHY would work just as well. Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Anyway, board file should not be considered as a method to exchange data between drivers. It should be used only to pass data from it to drivers, not the other way. Ideally all data in a board file should be marked as const and __init and dropped after system initialization. The phy_address things don't have to be defined or allocated in the board file; they could be set up along with the platform data. There is no platform data when booting with DT. In any case, this was simply meant to be a suggestion to show that it is relatively easy to do what you need without using name or ID strings. Sure. It's good to have different options discussed as well. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 12:44:23PM -0700, Greg KH wrote: On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote: statement. In any case this is why the APIs doing lookups do the lookups in the context of the requesting device - devices ask for whatever name they use locally. What do you mean by locally? Within themselves - for example a regulator consumer asks for a given supply on the device in terms of the supply names the device has. The problem with the api was that the phy core wanted a id and a name to create a phy, and then later other code was doing a lookup based on the name and id (mushed together), because it knew that this device was the one it wanted. Ah, that sounds like the API is missing a component to link things together. But I could be wrong. What I would expect to see is that the consumer says I want the PHY called X and the PHY driver says I provide this set of PHYs with a layer in between that plugs those together. This would normally involve talking about the parent device rather than the PHY itself. I think, that if you create a device, then just carry around the pointer to that device (in this case a phy) and pass it to whatever other code needs it. No need to do lookups on known names or anything else, just normal pointers, with no problems for multiple devices, busses, or naming issues. I think you're not really talking about the lookup API at all here but rather about one way in which the matching code can be written. What everything *really* wants to do is work in terms of resources namespaced within struct devices since every bit of hardware in the system should have one of those it can use and if you have a struct device you can do useful things like call dev_printk() and find the device tree data to do device tree based lookups. Unfortunately for a number of buses even when statically registering the struct device doesn't get allocated until the device is probed so what everyone fell back on doing was using dev_name() in cases where the struct device wasn't there yet, or just always using it for consistency since for most of the affected buses dev_name() is fixed for human interface reasons. I think this is the issue you're concerned about here since if the dev_name() is dynamically allocated this breaks down. This only affects board files, DT and ACPI can both use their own data structures to do the mapping. I had thought you were talking about picking the names that the consumers use (which isn't actually that big a deal, it's just a bit annoying for the clock API). It's adding platform data in the first place that gets tedious - and of course there's also DT and ACPI to worry about, it's not just a case of platform data and then you're done. Pushing the lookup into library code means that drivers don't have to worry about any of this stuff. I agree, so just pass around the pointer to the phy and all is good. No need to worry about DT or ACPI or anything else. No, in practice passing around the pointer gets tricky if you're using something other than board files (or even are doing any kind of dynamic stuff with board files) since the two devices need to find each other and if you're using platform data then the code doing the matching has to know about the platform data for every device it might need to match which is just miserable. Something would need to do something like allocate the PHY objects and then arrange for them to be passed to both provider and consumer devices prior to those being registered, knowing where to place the pointers in the platform data for each device. This is straightforward with board files but not otherwise, people have tried this before. For most of the APIs doing this there is a clear and unambiguous name in the hardware that can be used (and for hardware process reasons is unlikely to get changed). The major exception to this is the clock API since it is relatively rare to have clear, segregated IP level information for IPs baked into larger chips. The other APIs tend to be establishing chip to chip links. The clock api is having problems with multiple names due to dynamic devices from what I was told. I want to prevent the PHY interface from having that same issue. I think the underlying issue here is that we don't have a good enough general way for board files (or other C code but mostly them) to talk about devices prior to their being registered - rather than have the pointer you're talking about be the PHY object itself have the pointer be something which allows us to match the struct device when it's created. This should be transparent to drivers and would be usable by all the existing APIs. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Monday 22 July 2013 08:14 PM, Alan Stern wrote:
> On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
>
>>> The PHY and the controller it is attached to are both physical
>>> devices.
>>>
>>> The connection between them is hardwired by the system
>>> manufacturer and cannot be changed by software.
>>>
>>> PHYs are generally described by fixed system-specific board
>>> files or by Device Tree information. Are they ever discovered
>>> dynamically?
>>
>> No. They are created just like any other platform devices are created.
>
> Okay. Are PHYs _always_ platform devices?
Not always. It can be any other device also.
>
>>> Is the same true for the controllers attached to the PHYs?
>>> If not -- if both a PHY and a controller are discovered
>>> dynamically -- how does the kernel know whether they are
>>> connected to each other?
>>
>> No differences here. Both PHY and controller will have dt information or
>> hwmod
>> data using which platform devices will be created.
>>>
>>> The kernel needs to know which controller is attached to which
>>> PHY. Currently this information is represented by name or ID
>>> strings embedded in platform data.
>>
>> right. It's embedded in the platform data of the controller.
>
> It must also be embedded in the PHY's platform data somehow.
> Otherwise, how would the kernel know which PHY to use?
>
>>> The PHY's driver (the supplier) uses the platform data to
>>> construct a platform_device structure that represents the PHY.
>>
>> Currently the driver assigns static labels (corresponding to the label used
>> in
>> the platform data of the controller).
>>> Until this is done, the controller's driver (the client) cannot
>>> use the PHY.
>>
>> right.
>>>
>>> Since there is no parent-child relation between the PHY and the
>>> controller, there is no guarantee that the PHY's driver will be
>>> ready when the controller's driver wants to use it. A deferred
>>> probe may be needed.
>>
>> right.
>>>
>>> The issue (or one of the issues) in this discussion is that
>>> Greg does not like the idea of using names or IDs to associate
>>> PHYs with controllers, because they are too prone to
>>> duplications or other errors. Pointers are more reliable.
>>>
>>> But pointers to what? Since the only data known to be
>>> available to both the PHY driver and controller driver is the
>>> platform data, the obvious answer is a pointer to platform data
>>> (either for the PHY or for the controller, or maybe both).
>>
>> hmm.. it's not going to be simple though as the platform device for the PHY
>> and
>> controller can be created in entirely different places. e.g., in some cases
>> the
>> PHY device is a child of some mfd core device (the device will be created in
>> drivers/mfd) and the controller driver (usually) is created in board file. I
>> guess then we have to come up with something to share a pointer in two
>> different files.
>
> The ability for two different source files to share a pointer to a data
> item defined in a third source file has been around since long before
> the C language was invented. :-)
>
> In this case, it doesn't matter where the platform_device structures
> are created or where the driver source code is. Let's take a simple
> example. Suppose the system design includes a PHY named "foo". Then
> the board file could contain:
>
> struct phy_info { ... } phy_foo;
> EXPORT_SYMBOL_GPL(phy_foo);
>
> and a header file would contain:
>
> extern struct phy_info phy_foo;
>
> The PHY supplier could then call phy_create(_foo), and the PHY
> client could call phy_find(_foo). Or something like that; make up
> your own structure tags and function names.
Alright. Thanks for the hint :-)
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi, On Monday 22 July 2013 08:34 PM, Greg KH wrote: > On Mon, Jul 22, 2013 at 12:55:18PM +0530, Kishon Vijay Abraham I wrote: >>> The issue (or one of the issues) in this discussion is that >>> Greg does not like the idea of using names or IDs to associate >>> PHYs with controllers, because they are too prone to >>> duplications or other errors. Pointers are more reliable. >>> >>> But pointers to what? Since the only data known to be >>> available to both the PHY driver and controller driver is the >>> platform data, the obvious answer is a pointer to platform data >>> (either for the PHY or for the controller, or maybe both). >> >> hmm.. it's not going to be simple though as the platform device for the PHY >> and >> controller can be created in entirely different places. e.g., in some cases >> the >> PHY device is a child of some mfd core device (the device will be created in >> drivers/mfd) and the controller driver (usually) is created in board file. I >> guess then we have to come up with something to share a pointer in two >> different files. > > What's wrong with using the platform_data structure that is unique to > all boards (see include/platform_data/ for examples)? Isn't that what > this structure is there for? Alright. I got some ideas from Alan Stern. I'll use it with platform_data and repost the series. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Mon, Jul 22, 2013 at 12:55:18PM +0530, Kishon Vijay Abraham I wrote: > > The issue (or one of the issues) in this discussion is that > > Greg does not like the idea of using names or IDs to associate > > PHYs with controllers, because they are too prone to > > duplications or other errors. Pointers are more reliable. > > > > But pointers to what? Since the only data known to be > > available to both the PHY driver and controller driver is the > > platform data, the obvious answer is a pointer to platform data > > (either for the PHY or for the controller, or maybe both). > > hmm.. it's not going to be simple though as the platform device for the PHY > and > controller can be created in entirely different places. e.g., in some cases > the > PHY device is a child of some mfd core device (the device will be created in > drivers/mfd) and the controller driver (usually) is created in board file. I > guess then we have to come up with something to share a pointer in two > different files. What's wrong with using the platform_data structure that is unique to all boards (see include/platform_data/ for examples)? Isn't that what this structure is there for? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
> > The PHY and the controller it is attached to are both physical
> > devices.
> >
> > The connection between them is hardwired by the system
> > manufacturer and cannot be changed by software.
> >
> > PHYs are generally described by fixed system-specific board
> > files or by Device Tree information. Are they ever discovered
> > dynamically?
>
> No. They are created just like any other platform devices are created.
Okay. Are PHYs _always_ platform devices?
> > Is the same true for the controllers attached to the PHYs?
> > If not -- if both a PHY and a controller are discovered
> > dynamically -- how does the kernel know whether they are
> > connected to each other?
>
> No differences here. Both PHY and controller will have dt information or hwmod
> data using which platform devices will be created.
> >
> > The kernel needs to know which controller is attached to which
> > PHY. Currently this information is represented by name or ID
> > strings embedded in platform data.
>
> right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
> > The PHY's driver (the supplier) uses the platform data to
> > construct a platform_device structure that represents the PHY.
>
> Currently the driver assigns static labels (corresponding to the label used in
> the platform data of the controller).
> > Until this is done, the controller's driver (the client) cannot
> > use the PHY.
>
> right.
> >
> > Since there is no parent-child relation between the PHY and the
> > controller, there is no guarantee that the PHY's driver will be
> > ready when the controller's driver wants to use it. A deferred
> > probe may be needed.
>
> right.
> >
> > The issue (or one of the issues) in this discussion is that
> > Greg does not like the idea of using names or IDs to associate
> > PHYs with controllers, because they are too prone to
> > duplications or other errors. Pointers are more reliable.
> >
> > But pointers to what? Since the only data known to be
> > available to both the PHY driver and controller driver is the
> > platform data, the obvious answer is a pointer to platform data
> > (either for the PHY or for the controller, or maybe both).
>
> hmm.. it's not going to be simple though as the platform device for the PHY
> and
> controller can be created in entirely different places. e.g., in some cases
> the
> PHY device is a child of some mfd core device (the device will be created in
> drivers/mfd) and the controller driver (usually) is created in board file. I
> guess then we have to come up with something to share a pointer in two
> different files.
The ability for two different source files to share a pointer to a data
item defined in a third source file has been around since long before
the C language was invented. :-)
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named "foo". Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(_foo), and the PHY
client could call phy_find(_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link time.
> > Probably some of the details above are wrong; please indicate where I
> > have gone astray. Also, I'm not clear about the role played by various
> > APIs. For example, where does phy_create() fit into this picture?
>
> phy_create is the API by which the PHY's driver (the supplier) hook into the
> PHY framework. It's like the controller driver will always interact with the
> PHY driver through the PHY framework.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
