Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

2013-03-19 Thread Fabio Porcedda
On Mon, Mar 18, 2013 at 12:28 PM, Arnd Bergmann wrote: > On Monday 18 March 2013, Fabio Porcedda wrote: >> >> On Mon, Mar 18, 2013 at 11:58 AM, Arnd Bergmann wrote: >> > On Monday 18 March 2013, Fabio Porcedda wrote: >> >> Since by using platform_driver_probe() the function >> >> ep93xx_pwm_prob

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

2013-03-19 Thread Geert Uytterhoeven
On Tue, Mar 19, 2013 at 9:55 AM, Fabio Porcedda wrote: > On Mon, Mar 18, 2013 at 12:28 PM, Arnd Bergmann wrote: >> On Monday 18 March 2013, Fabio Porcedda wrote: >>> On Mon, Mar 18, 2013 at 11:58 AM, Arnd Bergmann wrote: >>> > On Monday 18 March 2013, Fabio Porcedda wrote: >>> >> Since by using

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

2013-03-19 Thread Arnd Bergmann
On Tuesday 19 March 2013, Geert Uytterhoeven wrote: > Hmm, so we may have drivers that (now) work perfectly fine with > module_platform_driver_probe()/platform_driver_probe(), but will start > failing suddenly in the future? They will fail if someone changes the initialization order. That would al

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

2013-03-19 Thread Fabio Porcedda
On Tue, Mar 19, 2013 at 5:48 PM, Arnd Bergmann wrote: > On Tuesday 19 March 2013, Geert Uytterhoeven wrote: >> Hmm, so we may have drivers that (now) work perfectly fine with >> module_platform_driver_probe()/platform_driver_probe(), but will start >> failing suddenly in the future? > > They will

Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()

2013-03-19 Thread Arnd Bergmann
On Tuesday 19 March 2013, Fabio Porcedda wrote: > On Tue, Mar 19, 2013 at 5:48 PM, Arnd Bergmann wrote: > > On Tuesday 19 March 2013, Geert Uytterhoeven wrote: > >> Hmm, so we may have drivers that (now) work perfectly fine with > >> module_platform_driver_probe()/platform_driver_probe(), but will

Re: [PATCH 1/7] HID: input: don't register unmapped input devices

2013-03-19 Thread Henrik Rydberg
Hi Benjamin, > There is no need to register an input device containing no events. > This allows drivers using the quirk MULTI_INPUT to register one input > per report effectively used. > > For backward compatibility, we need to add a quirk to request > this behavior. > > Signed-off-by: Benjamin

Re: [PATCH 4/7] HID: multitouch: add handling for pen in dual-sensors device

2013-03-19 Thread Henrik Rydberg
Hi Benjamin, > Dual sensors devices reports pen and touch on two different reports. > Using the quirk HID_QUIRK_MULTI_INPUT allows us to create a new input > device to forward pen events. > > The quirk HID_QUIRK_NO_EMPTY_INPUT avoids the creation of input devices > for the not used mouse emulatio

Re: [PATCH 6/7] HID: multitouch: append " Pen" to the name of the stylus input

2013-03-19 Thread Henrik Rydberg
Hi Benjamin, > This is not just cosmetics, it can help to write udev and X.org > rules. > > Signed-off-by: Benjamin Tissoires > --- > drivers/hid/hid-multitouch.c | 24 +++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > diff --git a/drivers/hid/hid-multitouch.c b/dr

Re: [PATCH 0/7] HID: multitouch: support of hybrid finger/pen devices

2013-03-19 Thread Henrik Rydberg
Hi Jiri, Benjamin, > > So the solution consists in relying inconditionaly to the quirk MULTI_INPUT > > for > > hid-multitouch. Before registering the input device in hid-input, we can > > test if > > it has been populated, and if not, then we simply don't register it. In > > order to > > preven

Re: [PATCH 2/4] Input: cyapa - Firmware update via request firmware

2013-03-19 Thread Henrik Rydberg
Hi Benson, > On Sat, Mar 16, 2013 at 1:00 PM, Henrik Rydberg wrote: > >> Userspace can initiate the firmware update procedure by copying cyapa.bin > >> to /lib/firmware, and then writing anything to the device sysfs attribute: > >> /sys/bus/i2c/devices/7-0067/update_fw > > > > Why do you need t

Re: [RFC/RFT] Reset bcm5974 into wellspring mode when it forgets

2013-03-19 Thread Henrik Rydberg
Hi David, > On Sat, 2013-03-16 at 20:31 +0100, Henrik Rydberg wrote: > > What do you mean by "fix for this on suspend/resume"? The driver > > always returns to normal mode at suspend, and sets wellspring mode at > > resume. > > Yes, that's exactly what I mean. And in the early days when the drive

Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support

2013-03-19 Thread Samuel Ortiz
Hi Simon, On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote: > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3 > connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interru

Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support

2013-03-19 Thread Samuel Ortiz
On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote: > Hi Simon, > > On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote: > > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation > > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3 >

Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support

2013-03-19 Thread Simon Glass
Hi Samuel, On Tue, Mar 19, 2013 at 6:12 PM, Samuel Ortiz wrote: > On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote: >> Hi Simon, >> >> On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote: >> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation >> > used