On Wed, May 13, 2015 at 7:33 PM, Greg Kroah-Hartman
wrote:
> On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:
>> On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
>> > On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
>> > > Hi Greg,
>> > >
>> > > On
On Wed, May 13, 2015 at 7:33 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:
On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
Hi Greg,
On Wed, May 13, 2015 at 03:33:31PM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:
> > On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
> > > On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
> > > > Hi Greg,
> > > >
On Wed, May 13, 2015 at 03:33:31PM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:
On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
Hi Greg,
On Wed,
On Wed, May 13, 2015 at 03:33:31PM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:
> > Our use case is this one: we want to export spidev files so that "dev
> > boards" with a header that allows to plug virtually anything on it
> > (Raspberry Pi,
On Wed, May 13, 2015 at 03:33:31PM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:
Our use case is this one: we want to export spidev files so that dev
boards with a header that allows to plug virtually anything on it
(Raspberry Pi,
On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:
> On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
> > > Hi Greg,
> > >
> > > On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
>
On Wed, May 13, 2015 at 09:10:48PM +0200, Geert Uytterhoeven wrote:
> On Wed, May 13, 2015 at 2:51 PM, Maxime Ripard
> wrote:
> >> > This also adds an i2cdev-like feeling, where you get all the
> >> > spidev devices all the time, without any modification.
> >>
> >> I2C is a bit safer here since
On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
> > Hi Greg,
> >
> > On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
> > > On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> > > >
On Wed, May 13, 2015 at 8:17 PM, Greg Kroah-Hartman
wrote:
> On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
>> On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
>> > On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
>> > > On Tue, May 12, 2015 at
On Wed, May 13, 2015 at 07:51:49PM +0100, Mark Brown wrote:
> On Wed, May 13, 2015 at 11:36:53AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2015 at 07:32:11PM +0100, Mark Brown wrote:
>
> > > Oh, right. For this to be useful here we'd need to implement a new_id
> > > file, bind and
On Wed, May 13, 2015 at 2:51 PM, Maxime Ripard
wrote:
>> > This also adds an i2cdev-like feeling, where you get all the
>> > spidev devices all the time, without any modification.
>>
>> I2C is a bit safer here since it's a shared bus so you can't do
>> anything to devices not connected to the bus
On Wed, May 13, 2015 at 03:36:10PM +0100, Mark Brown wrote:
> On Wed, May 13, 2015 at 02:51:02PM +0200, Maxime Ripard wrote:
>
> > I'd say we're also ok because if we delegate the device driving logic
> > to userspace, we should expect it to know what it does to first drive
> > the device
On Wed, May 13, 2015 at 11:36:53AM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 07:32:11PM +0100, Mark Brown wrote:
> > Oh, right. For this to be useful here we'd need to implement a new_id
> > file, bind and unbind don't do anything helpful here. I think I'd have
> > expected
On Wed, May 13, 2015 at 07:32:11PM +0100, Mark Brown wrote:
> On Wed, May 13, 2015 at 11:16:31AM -0700, Greg Kroah-Hartman wrote:
>
> > It should "just work" for all busses, but if you want to add a "new_id"
> > sysfs file, you need to add the logic for that to your bus. It's the
> > bind/unbind
On Wed, May 13, 2015 at 11:16:31AM -0700, Greg Kroah-Hartman wrote:
> It should "just work" for all busses, but if you want to add a "new_id"
> sysfs file, you need to add the logic for that to your bus. It's the
> bind/unbind files in the driver directories.
Oh, right. For this to be useful
On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
> Hi Greg,
>
> On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> > > On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
> > >
> > > >
On Wed, May 13, 2015 at 06:39:22PM +0100, Mark Brown wrote:
> On Wed, May 13, 2015 at 10:20:28AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2015 at 06:13:00PM +0100, Mark Brown wrote:
>
> > > So, that was my original suggestion too but people were complaining that
> > > this wasn't a
On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
> On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
> > That doesn't really work. I've been talking to the ACPI people about
> > this, and the problem is "don't otherwise have a driver for" is an
> > impossible
Hi Greg,
On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> > On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
> >
> > > While this is nicer than the DT solution because of its accurate hardware
> > >
On Wed, May 13, 2015 at 05:31:05PM +0200, Michal Suchanek wrote:
> But you know, unused i2c bus can be also connected to "make the board
> catch fire" trace and nobody would notice until somebody has the great
> idea to probe it. Incidentally, both i2c and spi cs are active-low
> iirc.
Someone
On Wed, May 13, 2015 at 10:20:28AM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 06:13:00PM +0100, Mark Brown wrote:
> > So, that was my original suggestion too but people were complaining that
> > this wasn't a generally supported feature and requires specific support
> > of some
On Wed, May 13, 2015 at 06:13:00PM +0100, Mark Brown wrote:
> On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
>
> > You can easily bind drivers to devices today from userspace, why not
> > just use the built-in functionality you have today if you "know" that
> > there is no
On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
> You can easily bind drivers to devices today from userspace, why not
> just use the built-in functionality you have today if you "know" that
> there is no driver for this hardware.
So, that was my original suggestion too but
On 13 May 2015 at 17:37, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
>> On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
>>
>> > While this is nicer than the DT solution because of its accurate hardware
>> > representation, it's still not
On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
>
> > While this is nicer than the DT solution because of its accurate hardware
> > representation, it's still not perfect because you might not have access to
> > the
> >
On 13 May 2015 at 16:36, Mark Brown wrote:
> On Wed, May 13, 2015 at 02:51:02PM +0200, Maxime Ripard wrote:
>
>> I'd say we're also ok because if we delegate the device driving logic
>> to userspace, we should expect it to know what it does to first drive
>> the device properly, but also to open
On Wed, May 13, 2015 at 02:51:02PM +0200, Maxime Ripard wrote:
> I'd say we're also ok because if we delegate the device driving logic
> to userspace, we should expect it to know what it does to first drive
> the device properly, but also to open the right device for this.
> What's the worst
On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
> > Solve this by registering automatically spidev devices for all the unused
> > chip
> > selects when a master registers itself against the spi core.
>
> So, aside from the concern about this being generic the other thing here
> is
On 13 May 2015 at 13:26, Mark Brown wrote:
> On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
>
>> While this is nicer than the DT solution because of its accurate hardware
>> representation, it's still not perfect because you might not have access to
>> the
>> DT, or you might be
On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
> While this is nicer than the DT solution because of its accurate hardware
> representation, it's still not perfect because you might not have access to
> the
> DT, or you might be driving a completely generic device (such as a
>
On 13 May 2015 at 13:26, Mark Brown broo...@kernel.org wrote:
On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
While this is nicer than the DT solution because of its accurate hardware
representation, it's still not perfect because you might not have access to
the
DT, or you
On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
Solve this by registering automatically spidev devices for all the unused
chip
selects when a master registers itself against the spi core.
So, aside from the concern about this being generic the other thing here
is that we
On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
While this is nicer than the DT solution because of its accurate hardware
representation, it's still not perfect because you might not have access to
the
DT, or you might be driving a completely generic device (such as a
On Wed, May 13, 2015 at 02:51:02PM +0200, Maxime Ripard wrote:
I'd say we're also ok because if we delegate the device driving logic
to userspace, we should expect it to know what it does to first drive
the device properly, but also to open the right device for this.
What's the worst that
On Wed, May 13, 2015 at 03:36:10PM +0100, Mark Brown wrote:
On Wed, May 13, 2015 at 02:51:02PM +0200, Maxime Ripard wrote:
I'd say we're also ok because if we delegate the device driving logic
to userspace, we should expect it to know what it does to first drive
the device properly, but
On Wed, May 13, 2015 at 11:16:31AM -0700, Greg Kroah-Hartman wrote:
It should just work for all busses, but if you want to add a new_id
sysfs file, you need to add the logic for that to your bus. It's the
bind/unbind files in the driver directories.
Oh, right. For this to be useful here
On Wed, May 13, 2015 at 07:32:11PM +0100, Mark Brown wrote:
On Wed, May 13, 2015 at 11:16:31AM -0700, Greg Kroah-Hartman wrote:
It should just work for all busses, but if you want to add a new_id
sysfs file, you need to add the logic for that to your bus. It's the
bind/unbind files in
On Wed, May 13, 2015 at 11:36:53AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 07:32:11PM +0100, Mark Brown wrote:
Oh, right. For this to be useful here we'd need to implement a new_id
file, bind and unbind don't do anything helpful here. I think I'd have
expected this to
On Wed, May 13, 2015 at 2:51 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
This also adds an i2cdev-like feeling, where you get all the
spidev devices all the time, without any modification.
I2C is a bit safer here since it's a shared bus so you can't do
anything to devices not
On Wed, May 13, 2015 at 07:51:49PM +0100, Mark Brown wrote:
On Wed, May 13, 2015 at 11:36:53AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 07:32:11PM +0100, Mark Brown wrote:
Oh, right. For this to be useful here we'd need to implement a new_id
file, bind and unbind don't
On Wed, May 13, 2015 at 09:10:48PM +0200, Geert Uytterhoeven wrote:
On Wed, May 13, 2015 at 2:51 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
This also adds an i2cdev-like feeling, where you get all the
spidev devices all the time, without any modification.
I2C is a bit
On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
Hi Greg,
On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
On Tue, May 12,
On Wed, May 13, 2015 at 8:17 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
On Tue, May
On Wed, May 13, 2015 at 09:26:40PM +0200, Maxime Ripard wrote:
On Wed, May 13, 2015 at 11:17:36AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
Hi Greg,
On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
On Wed,
On 13 May 2015 at 17:37, Greg Kroah-Hartman gre...@linuxfoundation.org wrote:
On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
While this is nicer than the DT solution because of its accurate hardware
representation,
On 13 May 2015 at 16:36, Mark Brown broo...@kernel.org wrote:
On Wed, May 13, 2015 at 02:51:02PM +0200, Maxime Ripard wrote:
I'd say we're also ok because if we delegate the device driving logic
to userspace, we should expect it to know what it does to first drive
the device properly, but
On Wed, May 13, 2015 at 06:13:00PM +0100, Mark Brown wrote:
On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
You can easily bind drivers to devices today from userspace, why not
just use the built-in functionality you have today if you know that
there is no driver for
On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
You can easily bind drivers to devices today from userspace, why not
just use the built-in functionality you have today if you know that
there is no driver for this hardware.
So, that was my original suggestion too but people
On Wed, May 13, 2015 at 10:20:28AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 06:13:00PM +0100, Mark Brown wrote:
So, that was my original suggestion too but people were complaining that
this wasn't a generally supported feature and requires specific support
of some kind in
On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
While this is nicer than the DT solution because of its accurate hardware
representation, it's still not perfect because you might not have access to
the
DT, or
On Wed, May 13, 2015 at 05:31:05PM +0200, Michal Suchanek wrote:
But you know, unused i2c bus can be also connected to make the board
catch fire trace and nobody would notice until somebody has the great
idea to probe it. Incidentally, both i2c and spi cs are active-low
iirc.
Someone would
Hi Greg,
On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
While this is nicer than the DT solution because of its accurate hardware
On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
That doesn't really work. I've been talking to the ACPI people about
this, and the problem is don't otherwise have a driver for is an
impossible thing to
On Wed, May 13, 2015 at 06:39:22PM +0100, Mark Brown wrote:
On Wed, May 13, 2015 at 10:20:28AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 06:13:00PM +0100, Mark Brown wrote:
So, that was my original suggestion too but people were complaining that
this wasn't a generally
On Wed, May 13, 2015 at 07:50:34PM +0200, Maxime Ripard wrote:
Hi Greg,
On Wed, May 13, 2015 at 08:37:40AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 13, 2015 at 12:26:04PM +0100, Mark Brown wrote:
On Tue, May 12, 2015 at 10:33:24PM +0200, Maxime Ripard wrote:
While this is
spidev device registration has always been a controversial subject since the
move to DT.
Obviously, a spidev node has nothing to do in the DT, and the position so far
has been to add the compatible of the devices to drive through spidev to the
list of the compatibles spidev can handle.
While
spidev device registration has always been a controversial subject since the
move to DT.
Obviously, a spidev node has nothing to do in the DT, and the position so far
has been to add the compatible of the devices to drive through spidev to the
list of the compatibles spidev can handle.
While
On Mon, May 05, 2014 at 12:17:23PM -0700, Mark Brown wrote:
> On Sun, May 04, 2014 at 11:21:47PM -0500, Maxime Ripard wrote:
> > On Fri, May 02, 2014 at 10:40:48AM -0700, Mark Brown wrote:
> > > > i2c-dev works great in these cases, because you always have access to
> > > > all the bus, and all
On Mon, May 05, 2014 at 12:17:23PM -0700, Mark Brown wrote:
On Sun, May 04, 2014 at 11:21:47PM -0500, Maxime Ripard wrote:
On Fri, May 02, 2014 at 10:40:48AM -0700, Mark Brown wrote:
i2c-dev works great in these cases, because you always have access to
all the bus, and all the devices,
On Mon, May 05, 2014 at 09:10:43AM +0200, Geert Uytterhoeven wrote:
> On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard
> > Not really, because you can't declare a spidev device in the DT.
> Yes you can. I've done it before.
> See also "git grep -w spidev -- arch/arm/*/dts/".
It is technically
On Sun, May 04, 2014 at 11:21:47PM -0500, Maxime Ripard wrote:
> On Fri, May 02, 2014 at 10:40:48AM -0700, Mark Brown wrote:
> > > i2c-dev works great in these cases, because you always have access to
> > > all the bus, and all the devices, except if the device is already used
> > > by someone.
Hi Alexandre,
On Mon, May 5, 2014 at 3:57 PM, Alexandre Belloni
wrote:
> On 05/05/2014 at 09:10:43 +0200, Geert Uytterhoeven wrote :
>> On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard
>> wrote:
>> > On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
>> >> On Fri, May 2, 2014 at
On 05/05/2014 at 09:10:43 +0200, Geert Uytterhoeven wrote :
> Hi Maxime,
>
> On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard
> wrote:
> > On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
> >> On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
> >> wrote:
> >> > But it actually
Hi Maxime,
On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard
wrote:
> On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
>> On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
>> wrote:
>> > But it actually doesn't work in a case where you can't really predict
>> > what is on the other
Hi Maxime,
On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
But it actually doesn't work in a case
On 05/05/2014 at 09:10:43 +0200, Geert Uytterhoeven wrote :
Hi Maxime,
On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
Hi Alexandre,
On Mon, May 5, 2014 at 3:57 PM, Alexandre Belloni
alexandre.bell...@free-electrons.com wrote:
On 05/05/2014 at 09:10:43 +0200, Geert Uytterhoeven wrote :
On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Fri, May 02, 2014 at 01:28:26AM
On Sun, May 04, 2014 at 11:21:47PM -0500, Maxime Ripard wrote:
On Fri, May 02, 2014 at 10:40:48AM -0700, Mark Brown wrote:
i2c-dev works great in these cases, because you always have access to
all the bus, and all the devices, except if the device is already used
by someone. The patch I
On Mon, May 05, 2014 at 09:10:43AM +0200, Geert Uytterhoeven wrote:
On Mon, May 5, 2014 at 6:17 AM, Maxime Ripard
Not really, because you can't declare a spidev device in the DT.
Yes you can. I've done it before.
See also git grep -w spidev -- arch/arm/*/dts/.
It is technically possible
On Fri, May 02, 2014 at 10:40:48AM -0700, Mark Brown wrote:
> > i2c-dev works great in these cases, because you always have access to
> > all the bus, and all the devices, except if the device is already used
> > by someone. The patch I suggested is an attempt to mimic this.
>
> It seems better
Hi Geert
On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
> wrote:
> > But it actually doesn't work in a case where you can't really predict
> > what is on the other side of the bus. Either because, on the board
Hi Geert
On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
Hi Maxime,
On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
But it actually doesn't work in a case where you can't really predict
what is on the other side of the bus.
On Fri, May 02, 2014 at 10:40:48AM -0700, Mark Brown wrote:
i2c-dev works great in these cases, because you always have access to
all the bus, and all the devices, except if the device is already used
by someone. The patch I suggested is an attempt to mimic this.
It seems better to
On Thu, May 01, 2014 at 03:36:29PM -0700, Maxime Ripard wrote:
> But it actually doesn't work in a case where you can't really predict
> what is on the other side of the bus. Either because, on the board
> you're using the pins are exposed and it's pretty much up to the user
> to know what to put
On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
> And then you want spidev to bind to it. Would it help if DT offered a feature
> to add a compatible entry to a driver at runtime, cfr.
> /sys/bus/pci/drivers/.../new_id on PCI?
Yes, that's what I'd been under the impression
On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote:
And then you want spidev to bind to it. Would it help if DT offered a feature
to add a compatible entry to a driver at runtime, cfr.
/sys/bus/pci/drivers/.../new_id on PCI?
Yes, that's what I'd been under the impression that
On Thu, May 01, 2014 at 03:36:29PM -0700, Maxime Ripard wrote:
But it actually doesn't work in a case where you can't really predict
what is on the other side of the bus. Either because, on the board
you're using the pins are exposed and it's pretty much up to the user
to know what to put on
Hi Maxime,
On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
wrote:
> But it actually doesn't work in a case where you can't really predict
> what is on the other side of the bus. Either because, on the board
> you're using the pins are exposed and it's pretty much up to the user
> to know what to
On Wed, Apr 30, 2014 at 06:18:11PM -0700, Mark Brown wrote:
> On Wed, Apr 30, 2014 at 11:06:09AM -0700, Maxime Ripard wrote:
> > On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:
>
> > > Why can we not handle this by using sysfs to bind spidev to the
> > > device?
>
> > I just tried
On Wed, Apr 30, 2014 at 06:18:11PM -0700, Mark Brown wrote:
On Wed, Apr 30, 2014 at 11:06:09AM -0700, Maxime Ripard wrote:
On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:
Why can we not handle this by using sysfs to bind spidev to the
device?
I just tried it, and
Hi Maxime,
On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
But it actually doesn't work in a case where you can't really predict
what is on the other side of the bus. Either because, on the board
you're using the pins are exposed and it's pretty much up
On Wed, Apr 30, 2014 at 11:06:09AM -0700, Maxime Ripard wrote:
> On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:
> > Why can we not handle this by using sysfs to bind spidev to the
> > device?
> I just tried it, and apparently, you can't really use this, since spi
> devices are
Hi Mark
On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:
> On Mon, Apr 28, 2014 at 10:22:54AM -0700, Maxime Ripard wrote:
>
> > spidev device registration has always been a controversial subject
> > since the move to DT.
>
> Why can we not handle this by using sysfs to bind spidev to
Hi Mark
On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:
On Mon, Apr 28, 2014 at 10:22:54AM -0700, Maxime Ripard wrote:
spidev device registration has always been a controversial subject
since the move to DT.
Why can we not handle this by using sysfs to bind spidev to the
On Wed, Apr 30, 2014 at 11:06:09AM -0700, Maxime Ripard wrote:
On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:
Why can we not handle this by using sysfs to bind spidev to the
device?
I just tried it, and apparently, you can't really use this, since spi
devices are created from
On Mon, Apr 28, 2014 at 10:22:54AM -0700, Maxime Ripard wrote:
> spidev device registration has always been a controversial subject since the
> move to DT.
Why can we not handle this by using sysfs to bind spidev to the device?
signature.asc
Description: Digital signature
On Mon, Apr 28, 2014 at 10:22:54AM -0700, Maxime Ripard wrote:
spidev device registration has always been a controversial subject since the
move to DT.
Why can we not handle this by using sysfs to bind spidev to the device?
signature.asc
Description: Digital signature
spidev device registration has always been a controversial subject since the
move to DT.
Obviously, a spidev node has nothing to do in the DT, and the position so far
has been to add the compatible of the devices to drive through spidev to the
list of the compatibles spidev can handle.
While
spidev device registration has always been a controversial subject since the
move to DT.
Obviously, a spidev node has nothing to do in the DT, and the position so far
has been to add the compatible of the devices to drive through spidev to the
list of the compatibles spidev can handle.
While
90 matches
Mail list logo
