Hi,
Markus Pargmann writes:
> On Sat, Sep 14, 2013 at 01:28:09PM +0100, Russell King - ARM Linux wrote:
> > On Sat, Sep 14, 2013 at 05:17:29AM -0700, Greg Kroah-Hartman wrote:
> > > On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
> > > > 3. We could fix up all drivers that change
On Sat, Sep 14, 2013 at 12:20:56PM +0100, Russell King - ARM Linux wrote:
> On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
> > I think there are three options to solve this:
> >
> > 1. Break out of the driver list iteration loop as soon as a driver probe
> >function fails.
On Sat, Sep 14, 2013 at 01:28:09PM +0100, Russell King - ARM Linux wrote:
> On Sat, Sep 14, 2013 at 05:17:29AM -0700, Greg Kroah-Hartman wrote:
> > On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
> > > 3. We could fix up all drivers that change the of_node. But there are
> > >
On Sat, Sep 14, 2013 at 01:28:09PM +0100, Russell King - ARM Linux wrote:
On Sat, Sep 14, 2013 at 05:17:29AM -0700, Greg Kroah-Hartman wrote:
On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
3. We could fix up all drivers that change the of_node. But there are
ARM DT
On Sat, Sep 14, 2013 at 12:20:56PM +0100, Russell King - ARM Linux wrote:
On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
I think there are three options to solve this:
1. Break out of the driver list iteration loop as soon as a driver probe
function fails. This way
Hi,
Markus Pargmann writes:
On Sat, Sep 14, 2013 at 01:28:09PM +0100, Russell King - ARM Linux wrote:
On Sat, Sep 14, 2013 at 05:17:29AM -0700, Greg Kroah-Hartman wrote:
On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
3. We could fix up all drivers that change the
On Sat, Sep 14, 2013 at 05:17:29AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
> > 3. We could fix up all drivers that change the of_node. But there are
> >ARM DT frameworks that require a device struct as parameter instead
> >of a
On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
> I think there are three options to solve this:
>
> 1. Break out of the driver list iteration loop as soon as a driver probe
>function fails. This way there is no possibility for another driver
>to be probed with a device
On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
I think there are three options to solve this:
1. Break out of the driver list iteration loop as soon as a driver probe
function fails. This way there is no possibility for another driver
to be probed with a device struct
On Sat, Sep 14, 2013 at 05:17:29AM -0700, Greg Kroah-Hartman wrote:
On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
3. We could fix up all drivers that change the of_node. But there are
ARM DT frameworks that require a device struct as parameter instead
of a
On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
> > Ok, so what do you suggest we do for stuff like this? Fix up the musb
> > driver? Or something else?
>
> I think there are three options to solve this:
>
> 1. Break out of the driver list iteration loop as soon as a driver
On Fri, Sep 13, 2013 at 10:10:46AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Sep 13, 2013 at 05:53:31PM +0200, Markus Pargmann wrote:
> > Hi,
> >
> > I ran into a serious problem with overwriting device of_node property as
> > it is done in many drivers for ARM. If probing fails in such a
> >
On Fri, Sep 13, 2013 at 10:10:46AM -0700, Greg Kroah-Hartman wrote:
On Fri, Sep 13, 2013 at 05:53:31PM +0200, Markus Pargmann wrote:
Hi,
I ran into a serious problem with overwriting device of_node property as
it is done in many drivers for ARM. If probing fails in such a
situation,
On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
Ok, so what do you suggest we do for stuff like this? Fix up the musb
driver? Or something else?
I think there are three options to solve this:
1. Break out of the driver list iteration loop as soon as a driver probe
On Fri, Sep 13, 2013 at 05:53:31PM +0200, Markus Pargmann wrote:
> Hi,
>
> I ran into a serious problem with overwriting device of_node property as
> it is done in many drivers for ARM. If probing fails in such a
> situation, the device could be loaded with a different driver.
>
> This is an
On Fri, Sep 13, 2013 at 05:53:31PM +0200, Markus Pargmann wrote:
Hi,
I ran into a serious problem with overwriting device of_node property as
it is done in many drivers for ARM. If probing fails in such a
situation, the device could be loaded with a different driver.
This is an example
16 matches
Mail list logo
