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, 14 Jan 2014 16:38:49 +0200
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Kishon Vijay Abraham I <kishon@...com>
Cc:	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH 4/5] arm: omap3: twl: use the new lookup method with usb
 phy

On Tue, Jan 07, 2014 at 06:31:52PM +0530, Kishon Vijay Abraham I wrote:
> > In any case, having two device names to deal with does not add any
> > more risk. These associations should always be made in the place where
> > the phy device is created so you will always know it's device name.
> 
> huh.. we should also know the 'controller' device name while defining these
> associations and in some cases the controller device and phy device are created
> in entirely different places.

If you don't want to use the controller device name to do the
matching, we can use the con_id string as well. I believe the lookup
method I use in this set just needs a small change.

Is that OK with you?


> > Normally the platform code creates these associations in the same
> > place it creates the platform devices, so you definitely know what the
> > device names will be.
> > 
> > In this case it's actually created in drivers/mfd/twl-core.c, so I do
> > need to update this and move the lookup table there. We can still
> > deliver the user name as platform data, though I believe it's always
> > "musb". Maybe we could actually skip that and just hard code the name?
> 
> I would rather leave the way it is modelled now.

Do you mean, leave it in the platform code? Why? We would reduce the
platform code by moving it to the mfd driver. Or did I misunderstood
something?

Hope I'm not forgetting something we have talked before my vacation.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ