linux-kernel - Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions

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:	Fri, 18 Jan 2013 21:08:16 +0200
From:	Luciano Coelho <coelho@...com>
To:	Tony Lindgren <tony@...mide.com>
CC:	"Cousson, Benoit" <b-cousson@...com>,
	Peter Ujfalusi <peter.ujfalusi@...com>, <balbi@...com>,
	<linux-omap@...r.kernel.org>, <linux@....linux.org.uk>,
	<linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport
 power functions

On Fri, 2013-01-18 at 09:36 -0800, Tony Lindgren wrote:
> * Luciano Coelho <coelho@...com> [130118 01:03]:
> > On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
> > > * Luciano Coelho <coelho@...com> [130117 10:04]:
> > > > But this patch is pretty small and simple, so why not include it to at
> > > > least fix the breakage in 3.7 and 3.8? Whether you take it or not now
> > > > won't make any difference in the 5k LOC in these kernel versions.
> > > 
> > > Well we are planning to drop the non-DT support for omap4 as soon as it's
> > > usable with DT. For omap4 we are only carrying SDP and panda support to
> > > make this transition easier. The only bindings missing AFAIK are wl12xx and
> > > USB.
> > 
> > In my view this is a regression and it should be fixed with as simple a
> > patch as possible.  The alternative to my solution is to revert the
> > patch that removed the enable/disable from the ti-st driver *and* fix
> > u-boot, because if it doesn't mux the UART2 pins properly (and it
> > doesn't) the shared transport still won't work.
> 
> Fixing the muxing here makes sense naturally as we cannot do that in the driver
> until we've flipped things over to use DT.
> 
> But I don't think we should fix the driver regression by adding more platform
> callbacks as we are getting rid of them anyways.

Okay, you're right.  We need at least to pass the GPIO number from the
board file to the driver so that it knows what to switch.  This is also
something that it will need from DT in the future.


> > > If we add this, then it implies we're somehow supporting it, which is not
> > > the way to go IMHO as we need to get rid of these platform callbacks instead.
> > 
> > It's a regression fix, not a new feature.  I also think these callbacks
> > are silly, but it's the quickest solution I found for 3.7 and 3.8.
> 
> Right, so how about let's fix the regression in the driver, and add the
> muxing to platform init code? 

Agreed.  I'll cook up a patch to revert the changes in eccf2979 (it
doesn't revert cleanly) and change the panda board file to do the muxing
and set the gpio number in the pdata for the driver to use.

 
> > > What's your estimate of having minimal wl12xx WLAN DT binding available?
> > 
> > To tell you the truth, I haven't even started looking into DT for wl12xx
> > myself.  So I have no idea when it will be ready.  Benoit has been
> > looking into it, but I don't know how far he is.
> 
> If it's going to take long we should just init the platform data for
> it temporarily even in the DT boot case until the binding is available.

I'll start looking into this now.  It's not going to be that simple, I'm
sure, but I need to look more into DT in general to be able to say
something more accurate.  I'll let you know as soon as I know more. :)

--
Cheers,
Luca.

--
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/