lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 2 Nov 2013 13:47:09 -0400
From:	Matt Porter <>
To:	Kishon Vijay Abraham I <>
Cc:	Tomasz Figa <>,, Felipe Balbi <>,
	Greg Kroah-Hartman <>,
	Rob Herring <>,
	Pawel Moll <>,
	Mark Rutland <>,
	Kumar Gala <>,
	Ian Campbell <>,
	Christian Daudt <>,
	Paul Zimmerman <>,
	Devicetree List <>,
	Linux USB List <>,
	Linux Kernel Mailing List <>,
	Linaro Patches <>
Subject: Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width()

On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
> Hi Tomasz,
> On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> >Hi Matt,
> >
> >On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> >>This adds a pair of APIs that allows the generic PHY subsystem to
> >>provide information on the PHY bus width. The PHY provider driver may
> >>use phy_set_bus_width() to set the bus width that the PHY supports.
> >>The controller driver may then use phy_get_bus_width() to fetch the
> >>PHY bus width in order to properly configure the controller.
> >
> >I somehow does not like this. If we take this path for any further
> >properties that we may need, we will end up with a lot of consumer
> >specific properties stored in a PHY object having their own accessor
> >functions.
> Only after all of us feel that a property is *generic* enough, we
> allow it to be added in the PHY object.

I also want to note that this was discussed over in another thread [2]
where you did consider my rough stab at a more generic attribute
accessor. It was definitely my first reaction as the way to do it like
Tomasz has said. The specific accessors are more readable to me besides
the justification you mention above.



> >Since this is just an integration detail, what about simply adding this as
> >a property in device tree node of the OTG controller (and pdata if
> >considering non-DT support)?
> We already had a discussion about this and the dt maintainers
> suggested the property should be in the PHY. [1]
> [1] ->
> Thanks
> Kishon
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists