linux-kernel - Re: [RFC PATCH 0/7] usb: musb: add driver for control module

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:	Wed, 16 Jan 2013 09:13:51 +0200
From:	Felipe Balbi <balbi@...com>
To:	kishon <kishon@...com>
CC:	"B, Ravi" <ravibabu@...com>, "Balbi, Felipe" <balbi@...com>,
	Arnd Bergmann <arnd@...db.de>,
	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"Cousson, Benoit" <b-cousson@...com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"rob@...dley.net" <rob@...dley.net>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"tony@...mide.com" <tony@...mide.com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>
Subject: Re: [RFC PATCH 0/7] usb: musb: add driver for control module

On Wed, Jan 16, 2013 at 11:31:32AM +0530, kishon wrote:
> Hi Ravi,
> 
> On Tuesday 15 January 2013 09:36 PM, B, Ravi wrote:
> >>Hi,
> >>
> >>On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:
> >>>Hi Arnd,
> >>>
> >>>On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
> >>>>On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
> >>>>>Added a new driver for the usb part of control module.
> >>This has an
> >>>>>API to power on the USB2 phy and an API to write to the mailbox
> >>>>>depending on whether MUSB has to act in host mode or in
> >>device mode.
> >>>>>
> >>>>>Writing to control module registers for doing the above
> >>task which
> >>>>>was previously done in omap glue and in omap-usb2 phy is removed.
> >>>>>
> >>>>>Also added the dt data to get MUSB working in OMAP platforms.
> >>>>>This series has patches for both drivers and ARCH
> >>folders, so If it
> >>>>>has to be split I'll do it.
> >>>>>
> >>>>
> >>>>The series looks good to me, I just had a minor comment on
> >>one patch.
> >>>>
> >>>>One a somewhat related topic, I wonder whether there are
> >>any plans on
> >>>>your side to change this driver to support multiple bus
> >>glues to be
> >>>>built for one kernel image. With a multiplatform kernel,
> >>we may need
> >>>>all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.
> >>>
> >>>We don't have plans as of now. I actually don't expect any
> >>changes in
> >>>the driver other than the Kconfig changes. Anyways the
> >>probe of glue's
> >>>other than the platform it's running won't get called. right Felipe?
> >
> >If understand correctly the control module driver used to configure the respective usb phy of SoC to respective usb modes using the common set of control module APIs.
> What if, if control module interface (register defintions) varies b/w
> different revision or spin of same type of SoCs, if usbphy type is
> changed.
> Well in that case, we can write to the registers based on the IP
> revision check (I think thats the common practice to do).
> 
> In this case whether the single instance of control module driver is
> good enough to cater of all cpu types of same SoC series ?
> Of course. I don't see why we can't have the same driver to handle
> different versions of the same IP.
> The only reason where we might need multiple instance is if the SoC
> have multiple control module which Arnd already pointed out.
> 
> >Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM driver?
> Not needed at all IMHO. We can use revision register to differentiate.
> 
> Btw I think Felipe looped you for a different reason ;-)

right, it was to look at removing <mach/*> inclusion from all
davinci-link glue layers (they should be combined, btw).

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)