linux-kernel - Re: [PATCH 2/6] phy: improved lookup method

lists.openwall.net		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 linux-hardening linux-cve-announce 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:	Tue, 23 Sep 2014 14:43:53 +0300
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Kishon Vijay Abraham I <kishon@...com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Felipe Balbi <balbi@...com>,
	Vivek Gautam <gautam.vivek@...sung.com>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH 2/6] phy: improved lookup method

On Tue, Sep 23, 2014 at 04:33:09PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Tuesday 23 September 2014 04:23 PM, Heikki Krogerus wrote:
> > On Mon, Sep 22, 2014 at 05:07:55PM +0530, Kishon Vijay Abraham I wrote:
> >> On Thursday 18 September 2014 03:55 PM, Heikki Krogerus wrote:
> >>> On Mon, Sep 15, 2014 at 03:35:08PM +0300, Heikki Krogerus wrote:
> >>>> On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I wrote:
> >>>>> Assume you have 2 phys in your system..
> >>>>> static struct phy_lookup usb_lookup = {
> >>>>> 	.phy_name	= "phy-usb.0",
> >>>>> 	.dev_id		= "usb.0",
> >>>>> 	.con_id		= "usb",
> >>>>> };
> >>>>>
> >>>>> static struct phy_lookup sata_lookup = {
> >>>>> 	.phy_name	= "sata-usb.1",
> >>>>> 	.dev_id		= "sata.0",
> >>>>> 	.con_id		= "sata",
> >>>>> };
> >>>>>
> >>>>> First you do modprobe phy-usb, the probe of USB PHY driver gets invoked and it
> >>>>> creates the PHY. The phy-core will find a free id (now it will be 0) and then
> >>>>> name the phy as phy-usb.0.
> >>>>> Then with modprobe phy-sata, the phy-core will create phy-sata.1.
> >>>>>
> >>>>> This is an ideal case where the .phy_name in phy_lookup matches.
> >>>>>
> >>>>> Consider if the order is flipped and the user does modprobe phy-sata first. The
> >>>>> phy_names won't match anymore (the sata phy device name would be "sata-usb.0").
> >>>
> >>> Actually, I don't think there would be this problem if we used the
> >>> name of the actual device which is the parent of phy devices, right?
> >>
> >> hmm.. but if the parent is a multi-phy phy provider (like pipe3 PHY driver), we
> >> might end up with the same problem.
> > 
> > I'm not completely sure what you mean? If you are talking about
> > platforms with multiple instances of a single phy, I don't see how
> > there could ever be a scenario where we did not know the order in
> > which they were enumerated. Can you give an example again?
> 
> If a single IP implements multiple PHYs (phy-miphy365x.c in linux-phy next),
> the parent for all the phy devices would be the same.

OK, got it. So I guess we need to match to the phy dev and to the phy
name. First to the dev and then in case the phy name is defined in the
lookup, to that as well. That should cover both cases.


Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/