Add support for hardware which uses an I2C Serializer / Deserializer
(SerDes) to communicate with the zFroce touch driver. In this case the
SerDes will be configured as an interrupt controller and the zForce driver
will have no access to poll the GPIO line.
To support this, we add two dedicated ne
During unbinding the driver was dereferencing a pointer to memory
already freed by power_supply_unregister().
Driver was freeing its internal description of battery through pointers
stored in power_supply structure. However, because the core owns the
power supply instance, after calling power_supp
On 03.08.2015 09:01, Krzysztof Kozlowski wrote:
> During unbinding the driver was dereferencing a pointer to memory
> already freed by power_supply_unregister().
>
> Driver was freeing its internal description of battery through pointers
> stored in power_supply structure. However, because the cor
During unbinding the driver was dereferencing a pointer to memory
already freed by power_supply_unregister().
Driver was freeing its internal description of battery through pointers
stored in power_supply structure. However, because the core owns the
power supply instance, after calling power_supp
Currently CONFIG_ARCH_HAVE_CUSTOM_GPIO_H is defined for all MIPS
machines, and each machine type provides its own gpio.h. However
only a handful really implement the GPIO API, most just forward
everythings to gpiolib.
The Alchemy machine is notable as it provides a system to allow
implementing the
On Sunday 02 August 2015 17:43:52 Pavel Machek wrote:
> On Sat 2015-08-01 13:44:59, Pali Rohár wrote:
> > On Saturday 01 August 2015 13:22:51 Viresh Kumar wrote:
> > > On 31-07-15, 09:58, Dmitry Torokhov wrote:
> > > > On Fri, Jul 31, 2015 at 02:08:25PM +0530, Viresh Kumar wrote:
> > > > > IS_ERR(_
On Sat 2015-08-01 13:44:59, Pali Rohár wrote:
> On Saturday 01 August 2015 13:22:51 Viresh Kumar wrote:
> > On 31-07-15, 09:58, Dmitry Torokhov wrote:
> > > On Fri, Jul 31, 2015 at 02:08:25PM +0530, Viresh Kumar wrote:
> > > > IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and
> > > >
On Wed, Jul 29, 2015 at 07:45:11AM -0700, Dmitry Torokhov wrote:
> > This seems coming from evdev_flush(). As there is no fd leak, it's no
> > big problem per se. But, now the question is whether returning such
> > an error code is correct behavior at all. At least, it doesn't seem
> > defined i
On Sun, Aug 02, 2015 at 09:42:20AM +0200, Pavel Machek wrote:
> > This seems coming from evdev_flush(). As there is no fd leak, it's no
> > big problem per se. But, now the question is whether returning such
> > an error code is correct behavior at all. At least, it doesn't seem
> > defined in P
The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer
functionality only, can still be compiled if GPIOLIB is not enabled.
Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where
appropriate.
Sign
On Wed 2015-07-29 12:46:59, Takashi Iwai wrote:
> Hi,
>
> while debugging a problem of X and gdm with the old systemd-210, we
> encountered a sudden death of systemd-logind, and this turned out to
> be an unexpected errno from close(). The close() call for input
> devices returns ENODEV error. T
On Mon 2015-07-27 12:17:06, Reilly Grant wrote:
> In commit 30ba2fbde1840db44 an LED class driver for this device was
> added and at the same time it was blacklisted by the hid-generic
> driver. This patch removes the device from the hid-generic driver's
> blacklist if the LED class driver is not e
12 matches
Mail list logo
