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
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
43 matches
Mail list logo
