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 We
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:
> > 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, C
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 it
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
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 10:33:2
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 unbi
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 properly
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
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 he
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:
> > >
> > > > Whil
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 gen
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
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
> > > r
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 wo
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 kin
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 dri
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 pe
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 p
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 t
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 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 tha
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 d
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
> mic
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 this
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
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 poss
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
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 12
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 doesn
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 s
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
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
>
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 tha
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 p
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,
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 create
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
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 this
45 matches
Mail list logo
