* Re: [PATCH 01/22] mfd/ti_am335x_tscadc: remove regmap
From: Mark Brown @ 2013-07-04 10:45 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Samuel Ortiz, Lee Jones, Benoît Cousson, Tony Lindgren,
Jonathan Cameron, Dmitry Torokhov, Felipe Balbi, linux-kernel,
linux-omap, linux-iio, linux-input
In-Reply-To: <51D53A31.3080704@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
On Thu, Jul 04, 2013 at 11:02:41AM +0200, Sebastian Andrzej Siewior wrote:
> The driver here does not use atomic updates but read followed by write
> so your locking here is futile. So the API/regmap alone does not make
Doesn't that sound like the driver ought to be using a r/m/w primitive
though?
> it right. And look: the MFD part uses regmap. Its children (IIO &
> input) do not use it. After I told this Samuel he said that it is okay.
Again I think the point here was that they probably ought to do so.
But I guess if you're saying there's no problem that's fine...
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: One USB mouse problem with runtime power management enabled
From: Peter Chen @ 2013-07-04 10:22 UTC (permalink / raw)
To: Alan Stern; +Cc: Jiri Kosina, linux-input, linux-usb
In-Reply-To: <Pine.LNX.4.44L0.1307031117410.1241-100000@iolanthe.rowland.org>
On Wed, Jul 03, 2013 at 12:29:08PM -0400, Alan Stern wrote:
> On Wed, 3 Jul 2013, Peter Chen wrote:
>
> > Hi Jiri and Alan,
> >
> > I have run below below at 3.5.7 kernel, but after checking upstream
> > kernel, it may also be existed.
> >
> > 1. evtest /dev/input/event1 &
> > 2. Let mouse auto suspend, enable mouse as wakeup source, and let
> > the system enters suspend.
> > echo auto > /sys/bus/usb/devices/1-1/power/control
> >
> > echo enabled > /sys/bus/platform/devices/2184000.usb/power/wakeup
> > echo enabled > /sys/bus/usb/devices/usb1/power/wakeup
>
> You probably don't need this one. The root hub ought to respond to the
> mouse's wakeup request, even if it isn't enabled for wakeup itself.
>
Yes, it doesn't need for remote wakeup, but it is needed for
WKCN/WKDN(wakeup on connect/disconnect), my script need to take
all usb wakeup into account.
> > echo enabled > /sys/bus/usb/devices/1-1/power/wakeup
> > echo enabled > /sys/bus/platform/devices/ci_hdrc.0/power/wakeup
> >
> > sleep 3
> > echo mem > /sys/power/state
> >
> > 3. Resume system with USB mouse button.
> >
> > 4. Console output endless with below message
> > hub 1-0:1.0: port 1 nyet suspended
> > hub 1-0:1.0: usb_suspend_interface: status -16
> > usb usb1: usb_suspend_both: status -16
>
> This looks like the PM core thinks the mouse is runtime suspended when
> it really isn't.
>
> I tried doing the same thing on a slightly modified 3.10 kernel. It
> worked okay. But my mouse was attached to a UHCI controller rather
> than EHCI, which may make a difference.
>
> Have you tried running this test with 3.10?
>
Have you opened the mouse by apps (like evtest)?, for USB mouse,
the usbhid->intf->needs_remote_wakeup is only set at .open/.close
API. That means if you have not opened mouse, the runtime pm status
for mouse will changed to RPM_ACTIVE (choose_wakeup -> pm_runtime_resume)
If you have opened the mouse, the runtime pm status is RPM_SUSPENDED.
> > 5. The reason for above message
> > After system goes to suspend, the roothub is RPM_SUSPENDED
> > At hub_events it will auto resume roothub, then auto suspend
> > roothub after system resumes. When it tries to auto suspend roothub,
> > it will print above message. But usbhid interface is resumed
> > by system resume, so its can_submit is 1.
>
> That's right. The PM core should realize that the usbhid interface
> is resumed, so it shouldn't try to suspend the root hub.
You mean runtime pm core? I find the runtime pm core doesn't know
the device has already resumed by system resume. For this case,
the pm_runtime_set_active(dev) has returned -EBUSY at usb_resume,
(I am still checking why, should be related to parent->power.disable_depth),
so the usbhid is still RPM_SUSPENDED.
> >
> > 6. It will not affect evtest, but the USBHID mouse seems will not do
> > auto-resume/auto-suspend again even the mouse's button is pressed.
> > Then the USBHID has always been active (although it is RPM_SUSPENDED)
>
> It is supposed to be RPM_ACTIVE. How did it become RPM_SUSPENDED?
Yes, the same with above, it needs to check why
pm_runtime_set_active(dev) has returned -EBUSY.
>
> > From my point, this problem may need to be fixed:
> > 1. At usbhid/input layer:
> > Since the usbhid device has auto suspended before system suspend, then,
> > it should still auto suspended after system resume.
>
> No; almost all devices get resumed during system resume, even if they
> were runtime-suspended beforehand. If they want to autosuspend later
> on, they can.
>
> You can see this in drivers/usb/core/driver.c:usb_resume():
>
> status = usb_resume_both(udev, msg);
> if (status == 0) {
> pm_runtime_disable(dev);
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
> unbind_no_reset_resume_drivers_interfaces(udev);
> }
>
> The pm_runtime_set_active() call tells the PM core that the device is
> RPM_ACTIVE.
>
> > 2. At USB layer:
> > It can do auto resume and auto suspend USB device
> > after system resume to keep the usb device runtime pm status correct.
>
> The runtime PM status should be correct -- it should indicate that the
> device is active after a system resume.
Then, who should take the responsibility to put the device to autosuspend
if the device has auto-suspended before the system suspend, we can
see the ../power/control is still "auto".
Thanks.
--
Best Regards,
Peter Chen
^ permalink raw reply
* Re: [PATCH 01/22] mfd/ti_am335x_tscadc: remove regmap
From: Sebastian Andrzej Siewior @ 2013-07-04 9:02 UTC (permalink / raw)
To: Mark Brown
Cc: Samuel Ortiz, Lee Jones, Benoît Cousson, Tony Lindgren,
Jonathan Cameron, Dmitry Torokhov, Felipe Balbi, linux-kernel,
linux-omap, linux-iio, linux-input
In-Reply-To: <20130617160326.GE1403@sirena.org.uk>
Sorry for the long pause…
On 06/17/2013 06:03 PM, Mark Brown wrote:
>> This is a lot of for a simple mmio access. In terms of
>> performance: If I add a trace point to my read and write I have
>> still less code which is called and it can be disabled. This
>> regmap overhead is always there chasing pointers.
>
> Equally well what you're implementing here is support for
> something that's typically implemented with an I2C or SPI control
> interface so you're already going to be quite a way ahead of the
> norm. This is part of what's confusing me, usually for this
> application things aren't that bad performance wise even on a
> massively slower bus.
>
> If all you're saying here is that there's some overhead that's fine
> if a bit surprising, but the way you're talking made it sound like
> there was some issue that made the API actually unusable.
No, sorry for that confusion. I had a problem with the locking in irq
context, changed the driver & pointed out the problem, been told that
there is a fix, applied it, never complained again.
This is simply about I am forced to use regmap and I don't agree with
it.
>> As I said before: I doubt that you get this regmap access in an
>> one GiB network driver and in turn remove their trace points to
>> register access.
>
> Well, of course for that sort of thing the general trick is not to
> talk to the hardware at all and do as much as possible with memory
> that the hardware can DMA - there's actually still non-trivial
> costs in talking over the buses.
That is true but even while doing DMA you have enough handshake with
the HW to trigger the transfer and if you are lucky your DMA
descriptors are in cached memory.
>> Please don't get me wrong: It is still nice for slow buses and
>> this ADC driver isn't anything close to high performance like a
>> 1GiB network driver but it adds a lot of unwanted overhead which
>> I prefer not to have.
>
> OK, but equally well remember that from a subsystem maintainer
> point of view having things factored out is a win in itself; for
> example with the MFDs locking on the register I/O has been a
> persistent issue in the past.
I agree with that. But:
The driver here does not use atomic updates but read followed by write
so your locking here is futile. So the API/regmap alone does not make
it right. And look: the MFD part uses regmap. Its children (IIO &
input) do not use it. After I told this Samuel he said that it is okay.
So here I am. Using regmap in MFD which is only used once on init and
never again. It has regmap.
The register access in both child driver is split making sure they do
not use the same ones. I added one function which writes a common
register. That one is reset after an operation and needs to be written
by the currently active child so the HW continues to work. Haven't seen
anything close to it in regmap.
I ask, politely I hope, to get this patch in and remove regmap since
none of its features are used in this driver.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Input: cyttsp4 - use 16bit address for I2C/SPI communication
From: Ferruh Yigit @ 2013-07-03 20:36 UTC (permalink / raw)
To: Dan Carpenter, Dmitry Torokhov
Cc: ttdrivers, Javier Martinez Canillas, linux-input, Ferruh Yigit
In-Reply-To: <20130703135248.GV5714@mwanda>
In TSG4, register map is 512bytes long and to access all of it,
one bit from address byte is used (which bit to use differs for
I2C and SPI);
Since common code used for TSG3 and TSG4 for I2C, this parameter
wrongly used as u8. TSG3 does not access beyond 255 bytes
but TSG4 may.
Signed-off-by: Ferruh Yigit <fery@cypress.com>
Tested-on: TMA3XX DVB && TMA4XX DVB
---
drivers/input/touchscreen/cyttsp4_core.h | 12 +++++-----
drivers/input/touchscreen/cyttsp4_spi.c | 20 ++++++++---------
drivers/input/touchscreen/cyttsp_core.h | 8 +++----
drivers/input/touchscreen/cyttsp_i2c_common.c | 30 ++++++++++++++++++-------
drivers/input/touchscreen/cyttsp_spi.c | 6 ++---
5 files changed, 44 insertions(+), 32 deletions(-)
diff --git a/drivers/input/touchscreen/cyttsp4_core.h b/drivers/input/touchscreen/cyttsp4_core.h
index 86a2543..8e0d4d4 100644
--- a/drivers/input/touchscreen/cyttsp4_core.h
+++ b/drivers/input/touchscreen/cyttsp4_core.h
@@ -369,9 +369,9 @@ struct cyttsp4 {
struct cyttsp4_bus_ops {
u16 bustype;
- int (*write)(struct device *dev, u8 *xfer_buf, u8 addr, u8 length,
+ int (*write)(struct device *dev, u8 *xfer_buf, u16 addr, u8 length,
const void *values);
- int (*read)(struct device *dev, u8 *xfer_buf, u8 addr, u8 length,
+ int (*read)(struct device *dev, u8 *xfer_buf, u16 addr, u8 length,
void *values);
};
@@ -448,13 +448,13 @@ enum cyttsp4_event_id {
/* y-axis, 0:origin is on top side of panel, 1: bottom */
#define CY_PCFG_ORIGIN_Y_MASK 0x80
-static inline int cyttsp4_adap_read(struct cyttsp4 *ts, u8 addr, int size,
+static inline int cyttsp4_adap_read(struct cyttsp4 *ts, u16 addr, int size,
void *buf)
{
return ts->bus_ops->read(ts->dev, ts->xfer_buf, addr, size, buf);
}
-static inline int cyttsp4_adap_write(struct cyttsp4 *ts, u8 addr, int size,
+static inline int cyttsp4_adap_write(struct cyttsp4 *ts, u16 addr, int size,
const void *buf)
{
return ts->bus_ops->write(ts->dev, ts->xfer_buf, addr, size, buf);
@@ -463,9 +463,9 @@ static inline int cyttsp4_adap_write(struct cyttsp4 *ts, u8 addr, int size,
extern struct cyttsp4 *cyttsp4_probe(const struct cyttsp4_bus_ops *ops,
struct device *dev, u16 irq, size_t xfer_buf_size);
extern int cyttsp4_remove(struct cyttsp4 *ts);
-int cyttsp_i2c_write_block_data(struct device *dev, u8 *xfer_buf, u8 addr,
+int cyttsp_i2c_write_block_data(struct device *dev, u8 *xfer_buf, u16 addr,
u8 length, const void *values);
-int cyttsp_i2c_read_block_data(struct device *dev, u8 *xfer_buf, u8 addr,
+int cyttsp_i2c_read_block_data(struct device *dev, u8 *xfer_buf, u16 addr,
u8 length, void *values);
extern const struct dev_pm_ops cyttsp4_pm_ops;
diff --git a/drivers/input/touchscreen/cyttsp4_spi.c b/drivers/input/touchscreen/cyttsp4_spi.c
index f8f891b..a71e114 100644
--- a/drivers/input/touchscreen/cyttsp4_spi.c
+++ b/drivers/input/touchscreen/cyttsp4_spi.c
@@ -44,7 +44,7 @@
#define CY_SPI_DATA_BUF_SIZE (CY_SPI_CMD_BYTES + CY_SPI_DATA_SIZE)
static int cyttsp_spi_xfer(struct device *dev, u8 *xfer_buf,
- u8 op, u8 reg, u8 *buf, int length)
+ u8 op, u16 reg, u8 *buf, int length)
{
struct spi_device *spi = to_spi_device(dev);
struct spi_message msg;
@@ -63,14 +63,12 @@ static int cyttsp_spi_xfer(struct device *dev, u8 *xfer_buf,
memset(wr_buf, 0, CY_SPI_DATA_BUF_SIZE);
memset(rd_buf, 0, CY_SPI_CMD_BYTES);
- if (reg > 255)
- wr_buf[0] = op + CY_SPI_A8_BIT;
- else
- wr_buf[0] = op;
- if (op == CY_SPI_WR_OP)
- wr_buf[1] = reg % 256;
- if (op == CY_SPI_WR_OP && length > 0)
- memcpy(wr_buf + CY_SPI_CMD_BYTES, buf, length);
+ wr_buf[0] = op + (((reg >> 8) & 0x1) ? CY_SPI_A8_BIT : 0);
+ if (op == CY_SPI_WR_OP) {
+ wr_buf[1] = reg & 0xFF;
+ if (length > 0)
+ memcpy(wr_buf + CY_SPI_CMD_BYTES, buf, length);
+ }
memset(xfer, 0, sizeof(xfer));
spi_message_init(&msg);
@@ -130,7 +128,7 @@ static int cyttsp_spi_xfer(struct device *dev, u8 *xfer_buf,
}
static int cyttsp_spi_read_block_data(struct device *dev, u8 *xfer_buf,
- u8 addr, u8 length, void *data)
+ u16 addr, u8 length, void *data)
{
int rc;
@@ -143,7 +141,7 @@ static int cyttsp_spi_read_block_data(struct device *dev, u8 *xfer_buf,
}
static int cyttsp_spi_write_block_data(struct device *dev, u8 *xfer_buf,
- u8 addr, u8 length, const void *data)
+ u16 addr, u8 length, const void *data)
{
return cyttsp_spi_xfer(dev, xfer_buf, CY_SPI_WR_OP, addr, (void *)data,
length);
diff --git a/drivers/input/touchscreen/cyttsp_core.h b/drivers/input/touchscreen/cyttsp_core.h
index 0cf564a..0707411 100644
--- a/drivers/input/touchscreen/cyttsp_core.h
+++ b/drivers/input/touchscreen/cyttsp_core.h
@@ -112,9 +112,9 @@ struct cyttsp;
struct cyttsp_bus_ops {
u16 bustype;
- int (*write)(struct device *dev, u8 *xfer_buf, u8 addr, u8 length,
+ int (*write)(struct device *dev, u8 *xfer_buf, u16 addr, u8 length,
const void *values);
- int (*read)(struct device *dev, u8 *xfer_buf, u8 addr, u8 length,
+ int (*read)(struct device *dev, u8 *xfer_buf, u16 addr, u8 length,
void *values);
};
@@ -145,9 +145,9 @@ struct cyttsp *cyttsp_probe(const struct cyttsp_bus_ops *bus_ops,
struct device *dev, int irq, size_t xfer_buf_size);
void cyttsp_remove(struct cyttsp *ts);
-int cyttsp_i2c_write_block_data(struct device *dev, u8 *xfer_buf, u8 addr,
+int cyttsp_i2c_write_block_data(struct device *dev, u8 *xfer_buf, u16 addr,
u8 length, const void *values);
-int cyttsp_i2c_read_block_data(struct device *dev, u8 *xfer_buf, u8 addr,
+int cyttsp_i2c_read_block_data(struct device *dev, u8 *xfer_buf, u16 addr,
u8 length, void *values);
extern const struct dev_pm_ops cyttsp_pm_ops;
diff --git a/drivers/input/touchscreen/cyttsp_i2c_common.c b/drivers/input/touchscreen/cyttsp_i2c_common.c
index 07c553f..1d7b6f1 100644
--- a/drivers/input/touchscreen/cyttsp_i2c_common.c
+++ b/drivers/input/touchscreen/cyttsp_i2c_common.c
@@ -32,18 +32,20 @@
#include <linux/types.h>
int cyttsp_i2c_read_block_data(struct device *dev, u8 *xfer_buf,
- u8 addr, u8 length, void *values)
+ u16 addr, u8 length, void *values)
{
struct i2c_client *client = to_i2c_client(dev);
+ u8 client_addr = client->addr | ((addr >> 8) & 0x1);
+ u8 addr_lo = addr & 0xFF;
struct i2c_msg msgs[] = {
{
- .addr = client->addr,
+ .addr = client_addr,
.flags = 0,
.len = 1,
- .buf = &addr,
+ .buf = &addr_lo,
},
{
- .addr = client->addr,
+ .addr = client_addr,
.flags = I2C_M_RD,
.len = length,
.buf = values,
@@ -60,17 +62,29 @@ int cyttsp_i2c_read_block_data(struct device *dev, u8 *xfer_buf,
EXPORT_SYMBOL_GPL(cyttsp_i2c_read_block_data);
int cyttsp_i2c_write_block_data(struct device *dev, u8 *xfer_buf,
- u8 addr, u8 length, const void *values)
+ u16 addr, u8 length, const void *values)
{
struct i2c_client *client = to_i2c_client(dev);
+ u8 client_addr = client->addr | ((addr >> 8) & 0x1);
+ u8 addr_lo = addr & 0xFF;
+ struct i2c_msg msgs[] = {
+ {
+ .addr = client_addr,
+ .flags = 0,
+ .len = length + 1,
+ .buf = xfer_buf,
+ },
+ };
int retval;
- xfer_buf[0] = addr;
+ xfer_buf[0] = addr_lo;
memcpy(&xfer_buf[1], values, length);
- retval = i2c_master_send(client, xfer_buf, length + 1);
+ retval = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
+ if (retval < 0)
+ return retval;
- return retval < 0 ? retval : 0;
+ return retval != ARRAY_SIZE(msgs) ? -EIO : 0;
}
EXPORT_SYMBOL_GPL(cyttsp_i2c_write_block_data);
diff --git a/drivers/input/touchscreen/cyttsp_spi.c b/drivers/input/touchscreen/cyttsp_spi.c
index 1df6253..4728bcb 100644
--- a/drivers/input/touchscreen/cyttsp_spi.c
+++ b/drivers/input/touchscreen/cyttsp_spi.c
@@ -41,7 +41,7 @@
#define CY_SPI_BITS_PER_WORD 8
static int cyttsp_spi_xfer(struct device *dev, u8 *xfer_buf,
- u8 op, u8 reg, u8 *buf, int length)
+ u8 op, u16 reg, u8 *buf, int length)
{
struct spi_device *spi = to_spi_device(dev);
struct spi_message msg;
@@ -126,14 +126,14 @@ static int cyttsp_spi_xfer(struct device *dev, u8 *xfer_buf,
}
static int cyttsp_spi_read_block_data(struct device *dev, u8 *xfer_buf,
- u8 addr, u8 length, void *data)
+ u16 addr, u8 length, void *data)
{
return cyttsp_spi_xfer(dev, xfer_buf, CY_SPI_RD_OP, addr, data,
length);
}
static int cyttsp_spi_write_block_data(struct device *dev, u8 *xfer_buf,
- u8 addr, u8 length, const void *data)
+ u16 addr, u8 length, const void *data)
{
return cyttsp_spi_xfer(dev, xfer_buf, CY_SPI_WR_OP, addr, (void *)data,
length);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] Input: cyttsp4 - kfree xfer_buf on error path in probe()
From: Ferruh Yigit @ 2013-07-03 17:14 UTC (permalink / raw)
To: Dan Carpenter
Cc: Dmitry Torokhov, ttdrivers, Javier Martinez Canillas, linux-input,
kernel-janitors, Ferruh Yigit
In-Reply-To: <51D42CD3.2000705@cypress.com>
If probe() fails after cd->xfer_buf allocated, it will not freed.
Added kfree(cd->xfer_buf) with and error label.
Signed-off-by: Ferruh Yigit <fery@cypress.com>
---
drivers/input/touchscreen/cyttsp4_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/cyttsp4_core.c b/drivers/input/touchscreen/cyttsp4_core.c
index a7987e1..edcf799 100644
--- a/drivers/input/touchscreen/cyttsp4_core.c
+++ b/drivers/input/touchscreen/cyttsp4_core.c
@@ -2049,7 +2049,7 @@ struct cyttsp4 *cyttsp4_probe(const struct cyttsp4_bus_ops *ops,
cd->irq = gpio_to_irq(cd->cpdata->irq_gpio);
if (cd->irq < 0) {
rc = -EINVAL;
- goto error_free_cd;
+ goto error_free_xfer;
}
dev_set_drvdata(dev, cd);
@@ -2117,6 +2117,8 @@ error_request_irq:
if (cd->cpdata->init)
cd->cpdata->init(cd->cpdata, 0, dev);
dev_set_drvdata(dev, NULL);
+error_free_xfer:
+ kfree(cd->xfer_buf);
error_free_cd:
kfree(cd);
error_alloc_data:
--
1.7.9.5
^ permalink raw reply related
* Re: One USB mouse problem with runtime power management enabled
From: Alan Stern @ 2013-07-03 16:29 UTC (permalink / raw)
To: Peter Chen; +Cc: Jiri Kosina, linux-input, linux-usb
In-Reply-To: <20130703024324.GA17349@nchen-desktop>
On Wed, 3 Jul 2013, Peter Chen wrote:
> Hi Jiri and Alan,
>
> I have run below below at 3.5.7 kernel, but after checking upstream
> kernel, it may also be existed.
>
> 1. evtest /dev/input/event1 &
> 2. Let mouse auto suspend, enable mouse as wakeup source, and let
> the system enters suspend.
> echo auto > /sys/bus/usb/devices/1-1/power/control
>
> echo enabled > /sys/bus/platform/devices/2184000.usb/power/wakeup
> echo enabled > /sys/bus/usb/devices/usb1/power/wakeup
You probably don't need this one. The root hub ought to respond to the
mouse's wakeup request, even if it isn't enabled for wakeup itself.
> echo enabled > /sys/bus/usb/devices/1-1/power/wakeup
> echo enabled > /sys/bus/platform/devices/ci_hdrc.0/power/wakeup
>
> sleep 3
> echo mem > /sys/power/state
>
> 3. Resume system with USB mouse button.
>
> 4. Console output endless with below message
> hub 1-0:1.0: port 1 nyet suspended
> hub 1-0:1.0: usb_suspend_interface: status -16
> usb usb1: usb_suspend_both: status -16
This looks like the PM core thinks the mouse is runtime suspended when
it really isn't.
I tried doing the same thing on a slightly modified 3.10 kernel. It
worked okay. But my mouse was attached to a UHCI controller rather
than EHCI, which may make a difference.
Have you tried running this test with 3.10?
> 5. The reason for above message
> After system goes to suspend, the roothub is RPM_SUSPENDED
> At hub_events it will auto resume roothub, then auto suspend
> roothub after system resumes. When it tries to auto suspend roothub,
> it will print above message. But usbhid interface is resumed
> by system resume, so its can_submit is 1.
That's right. The PM core should realize that the usbhid interface
is resumed, so it shouldn't try to suspend the root hub.
> Unlike the USB Keyboard, the mouse doesn't have any event after system
> resume, so it will not restart OUT/CTRL queues. So the USB mouse will
> not do autoresume and autosuspend.
These things are handled by the USB core, not by the usbhid driver.
> For hid keyboard, it has below message at its usb_hidinput_input_event
> after system resume:
> hid-generic 0003:413C:2105.0002: type:17, code:0, value:0
> hid-generic 0003:413C:2105.0002: type:17, code:1, value:0
> hid-generic 0003:413C:2105.0002: type:17, code:2, value:0
> hid-generic 0003:413C:2105.0002: type:20, code:1, value:33
> hid-generic 0003:413C:2105.0002: type:20, code:0, value:250
>
> 6. It will not affect evtest, but the USBHID mouse seems will not do
> auto-resume/auto-suspend again even the mouse's button is pressed.
> Then the USBHID has always been active (although it is RPM_SUSPENDED)
It is supposed to be RPM_ACTIVE. How did it become RPM_SUSPENDED?
> From my point, this problem may need to be fixed:
> 1. At usbhid/input layer:
> Since the usbhid device has auto suspended before system suspend, then,
> it should still auto suspended after system resume.
No; almost all devices get resumed during system resume, even if they
were runtime-suspended beforehand. If they want to autosuspend later
on, they can.
You can see this in drivers/usb/core/driver.c:usb_resume():
status = usb_resume_both(udev, msg);
if (status == 0) {
pm_runtime_disable(dev);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
unbind_no_reset_resume_drivers_interfaces(udev);
}
The pm_runtime_set_active() call tells the PM core that the device is
RPM_ACTIVE.
> 2. At USB layer:
> It can do auto resume and auto suspend USB device
> after system resume to keep the usb device runtime pm status correct.
The runtime PM status should be correct -- it should indicate that the
device is active after a system resume.
Alan Stern
^ permalink raw reply
* Re: Patch -- HID definitions for MacBook Air 6,2 keyboard
From: Jiri Kosina @ 2013-07-03 16:19 UTC (permalink / raw)
To: Linus G Thiel; +Cc: linux-input, linux-kernel
In-Reply-To: <CAG4XgJSu53FKuYQG+H95wx0pM9UJr1h9SLqVrR3EE6cDhuu4qw@mail.gmail.com>
On Wed, 3 Jul 2013, Linus G Thiel wrote:
> Hi,
>
> Please see attached a patch for the MacBook Air 6,2 keyboard.
>
> Changelog:
>
> * add definitions for new MacBook Air 6,2 keyboard with device id
> 0x05ac:0x0291
>
> I'm not sure about the name I chose for the keyboard -- I just made it the
> "next" wellspring, whatever that means. If it's wrong, let me know and I
> will make it right.
>
> Signed-off-by: Linus G Thiel <linus@hanssonlarsson.se>
Hi Linus,
thanks for the patch.
Henrik Rydberg however beat you with it, it has been queued in
input.git#for-linus already.
BTW, please make sure that your future patch submissions follow the rules
in Documentation/SubmittingPatches.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: kye: Add report fixup for Genius Gila Gaming mouse
From: Jiri Kosina @ 2013-07-03 16:16 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <1372781409-5356-1-git-send-email-benjamin.tissoires@redhat.com>
On Tue, 2 Jul 2013, Benjamin Tissoires wrote:
> Genius Gila Gaming Mouse presents an obviously wrong report descriptor.
> the Consumer control (report ID 3) is the following:
> 0x05, 0x0c, // Usage Page (Consumer Devices) 105
> 0x09, 0x01, // Usage (Consumer Control) 107
> 0xa1, 0x01, // Collection (Application) 109
> 0x85, 0x03, // Report ID (3) 111
> 0x19, 0x00, // Usage Minimum (0) 113
> 0x2a, 0xff, 0x7f, // Usage Maximum (32767) 115
> 0x15, 0x00, // Logical Minimum (0) 118
> 0x26, 0xff, 0x7f, // Logical Maximum (32767) 120
> 0x75, 0x10, // Report Size (16) 123
> 0x95, 0x03, // Report Count (3) 125
> 0x81, 0x00, // Input (Data,Arr,Abs) 127
> 0x75, 0x08, // Report Size (8) 129
> 0x95, 0x01, // Report Count (1) 131
> 0x81, 0x01, // Input (Cnst,Arr,Abs) 133
> 0xc0, // End Collection 135
>
> So the first input whithin this report has a count of 3 but a usage range
> of 32768. So this value is obviously wrong as it should not be greater than
> the report count.
>
> Fixes:
> https://bugzilla.redhat.com/show_bug.cgi?id=959721
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
> Hi Jiri,
>
> I know the window just opened and you don't really like receiving patches at
> that time. Still, my patch queue is growing, and I would like you to consider
> this patch for 3.11.
This one is really easy enough to go into even post -rc1 :) Now applied
for the Linus merge I am going to do shortly.
Thanks a lot, Benjamin.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [patch 3/3] Input: cyttsp4 - leak on error path in probe()
From: Ferruh Yigit @ 2013-07-03 13:53 UTC (permalink / raw)
To: Dan Carpenter
Cc: Javier Martinez Canillas, Dmitry Torokhov, linux-input,
kernel-janitors
In-Reply-To: <20130703135013.GU5714@mwanda>
On 07/03/2013 04:50 PM, Dan Carpenter wrote:
> On Wed, Jul 03, 2013 at 04:12:48PM +0300, Ferruh Yigit wrote:
>> On 07/03/2013 12:44 AM, Dan Carpenter wrote:
>>> We leak "cd" if the cd->xfer_buf allocation fails. It was weird to
>>> "goto error_gpio_irq" so I changed the label name. (Label names should
>>> reflect the label location not the goto location otherwise you get an
>>> "all roads lead to Rome problem").
>>>
>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>>
>> xfer_buf still may not be freed, I propose following one instead:
>>
> That's a good point. I missed that leak. The problem is that my
> patch was already applied so this patch would have to be re-written
> on top of that. Also this patch is whitespace dammaged and won't
> apply.
OK, I am preparing the patch over previous one.
Thanks,
ferruh
This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
^ permalink raw reply
* Re: Input: cyttsp4 - SPI driver for Cypress TMA4XX touchscreen devices
From: Dan Carpenter @ 2013-07-03 13:52 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: linux-input
In-Reply-To: <51D42602.5030001@cypress.com>
On Wed, Jul 03, 2013 at 04:24:18PM +0300, Ferruh Yigit wrote:
> I have a patch for this, but should I create it against previous patch I
> have sent or against latest next tree?
>
Latest linux-next.
regards,
dan carpenter
^ permalink raw reply
* Re: [patch 3/3] Input: cyttsp4 - leak on error path in probe()
From: Dan Carpenter @ 2013-07-03 13:50 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Javier Martinez Canillas, Dmitry Torokhov, linux-input,
kernel-janitors
In-Reply-To: <51D42350.10504@cypress.com>
On Wed, Jul 03, 2013 at 04:12:48PM +0300, Ferruh Yigit wrote:
> On 07/03/2013 12:44 AM, Dan Carpenter wrote:
> >We leak "cd" if the cd->xfer_buf allocation fails. It was weird to
> >"goto error_gpio_irq" so I changed the label name. (Label names should
> >reflect the label location not the goto location otherwise you get an
> >"all roads lead to Rome problem").
> >
> >Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >
> xfer_buf still may not be freed, I propose following one instead:
>
That's a good point. I missed that leak. The problem is that my
patch was already applied so this patch would have to be re-written
on top of that. Also this patch is whitespace dammaged and won't
apply.
regards,
dan carpenter
^ permalink raw reply
* Re: Input: cyttsp4 - SPI driver for Cypress TMA4XX touchscreen devices
From: Ferruh Yigit @ 2013-07-03 13:24 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-input
In-Reply-To: <20130702214731.GD1598@elgon.mountain>
On 07/03/2013 12:47 AM, Dan Carpenter wrote:
> Hello Ferruh Yigit,
>
> The patch 67bf12ca50d5: "Input: cyttsp4 - SPI driver for Cypress
> TMA4XX touchscreen devices" from Jun 30, 2013, leads to the following
> Smatch warning:
> "drivers/input/touchscreen/cyttsp4_spi.c:66 cyttsp_spi_xfer()
> warn: impossible condition '(reg > 255) => (0-255 > 255)'"
>
> drivers/input/touchscreen/cyttsp4_spi.c
> 66 if (reg > 255)
> ^^^^^^^^^
> "reg" is unsigned char so 255 is the max it can be.
> 67 wr_buf[0] = op + CY_SPI_A8_BIT;
> 68 else
> 69 wr_buf[0] = op;
>
> regards,
> dan carpenter
>
Hi Dan,
Shortly, check is correct and address should be 16 bit, parameter size
is wrong.
In TSG4, register map is 512bytes long and to access all of it, one bit
from address byte is used (which bit to use differs for I2C and SPI),
the code you marked is doing that check.
Since common code used TSG3 and TSG4 for I2C, this parameter wrongly
used as u8. TSG3 does not access beyond 255 bytes but TSG4 may.
I have a patch for this, but should I create it against previous patch I
have sent or against latest next tree?
--
Thanks,
ferruh
This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
^ permalink raw reply
* Re: [patch 3/3] Input: cyttsp4 - leak on error path in probe()
From: Ferruh Yigit @ 2013-07-03 13:12 UTC (permalink / raw)
To: Dan Carpenter
Cc: Javier Martinez Canillas, Dmitry Torokhov, linux-input,
kernel-janitors
In-Reply-To: <20130702214455.GC1598@elgon.mountain>
On 07/03/2013 12:44 AM, Dan Carpenter wrote:
> We leak "cd" if the cd->xfer_buf allocation fails. It was weird to
> "goto error_gpio_irq" so I changed the label name. (Label names should
> reflect the label location not the goto location otherwise you get an
> "all roads lead to Rome problem").
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
xfer_buf still may not be freed, I propose following one instead:
From: Ferruh Yigit <fery@cypress.com>
Date: Wed, 3 Jul 2013 15:59:54 +0300
Subject: [PATCH] Input: cyttsp4 - free xfer_buf in error path
Label for xfer_buf error is wrong and causing mem leak for cd.
Updated label for xfer_buf alloc failure and add kfree for xfer_buf
Signed-off-by: Ferruh Yigit <fery@cypress.com>
---
drivers/input/touchscreen/cyttsp4_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/cyttsp4_core.c
b/drivers/input/touchscreen/cyttsp4_core.c
index 69c9cff..219e32d 100644
--- a/drivers/input/touchscreen/cyttsp4_core.c
+++ b/drivers/input/touchscreen/cyttsp4_core.c
@@ -2034,7 +2034,7 @@ struct cyttsp4 *cyttsp4_probe(const struct
cyttsp4_bus_ops *ops,
if (!cd->xfer_buf) {
dev_err(dev, "%s: Error, kzalloc\n", __func__);
rc = -ENOMEM;
- goto error_alloc_data;
+ goto error_alloc_xfer;
}
/* Initialize device info */
@@ -2127,6 +2127,8 @@ error_request_irq:
cd->cpdata->init(cd->cpdata, 0, dev);
dev_set_drvdata(dev, NULL);
error_gpio_irq:
+ kfree(cd->xfer_buf);
+error_alloc_xfer:
kfree(cd);
error_alloc_data:
error_no_pdata:
--
1.7.9.5
This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
^ permalink raw reply related
* Re: [patch 2/3] Input: cyttsp4 - silence NULL dereference warning
From: Ferruh Yigit @ 2013-07-03 12:33 UTC (permalink / raw)
To: Dan Carpenter
Cc: Javier Martinez Canillas, Dmitry Torokhov, linux-input,
kernel-janitors
In-Reply-To: <20130702214107.GB1598@elgon.mountain>
On 07/03/2013 12:41 AM, Dan Carpenter wrote:
> If "cd" were NULL then we would dereference it when we print the error
> message. Fortunately enough, it can't ever be NULL so we can remove
> those lines.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/input/touchscreen/cyttsp4_core.c b/drivers/input/touchscreen/cyttsp4_core.c
> index 7aa4a34..851e3ff 100644
> --- a/drivers/input/touchscreen/cyttsp4_core.c
> +++ b/drivers/input/touchscreen/cyttsp4_core.c
> @@ -1450,11 +1450,6 @@ static void cyttsp4_watchdog_work(struct work_struct *work)
> u8 *mode;
> int retval;
>
> - if (cd == NULL) {
> - dev_err(cd->dev, "%s: NULL context pointer\n", __func__);
> - return;
> - }
> -
> mutex_lock(&cd->system_lock);
> retval = cyttsp4_load_status_regs(cd);
> if (retval < 0) {
You are right, cd dereference is wrong in error message.
And agree on removing block, cd will not be NULL in this context.
--
Thanks,
ferruh
This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
^ permalink raw reply
* Re: Logitech M705: Thumb button (was Re: [PATCH v4] HID: Add full support for Logitech Unifying receivers)
From: Nestor Lopez Casado @ 2013-07-03 10:46 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Markus Trippelsdorf, Dmitry Torokhov,
Richard Titmuss, Olivier Gay, open list:HID CORE LAYER,
linux-kernel@vger.kernel.org, Jean-Daniel Zanone,
František Fuka
In-Reply-To: <alpine.LNX.2.00.1306271513180.3538@pobox.suse.cz>
Hi all,
Sorry it took me some time to answer.
I extended the Logitech HIDPP10 specification here:
https://drive.google.com/folderview?id=0BxbRzx7vEV7eWmgwazJ3NUFfQ28&usp=sharing
The document "Logitech_hidpp10_specification_draft_Unifying_devices_receivers.doc"
now contains most of the relevant hidpp10 registers and notifications
needed to interact with older Logitech devices that support hidpp10 as
well as the Unifying receiver.
In particular I added the specifications for the registers that enable
retrieving the FW version information for devices/receivers. This will
become relevant below.
Cheers,
Nestor
On Thu, Jun 27, 2013 at 3:16 PM, Jiri Kosina <jkosina@suse.cz> wrote:
>
>
> [ Frantisek Fuka added to CC ]
>
> On Wed, 14 Sep 2011, Benjamin Tissoires wrote:
>
> > >> Nice. Does this mean I will be able to use the thumb-button of my M705
> > >> mouse in the near future?
> > >>
> > >> (Someone asked the same question 1.5 years ago, but nothing happened
> > >> till then: http://thread.gmane.org/gmane.linux.kernel.input/11791 )
> > >
> > > This is quite weird. I was going to say that it will work, but with
> > > the M705 I've got at home,this thumb button doesn't work at all
> > > (anything is emitted from the usb, even with this driver).
> > > But I'm pretty sure I made it work with the one I got at work.
> > >
> > > I'll give a try on Monday unless people at Logitech gave us the solution.
>
> > I got some information for you. Apparently, it won't be possible to
> > enable this thumb button right now.
> > To enable it, the Windows driver put the mouse in a kind of debug mode
> > that need to be handled properly, which is not the case as of today.
> >
> > I was able to make it work at home because there were different series
> > of M705, the latest sending the thumb button by default.
>
> Let me resurrect this 2 years old thread, as I have received multiple
> reports since then, stating that some revisions of M705 don't have working
> thumb button.
>
> Question mostly to the Logitech guys: Nestor, Olivier, could you please
> provide us with the sequence that needs to be sent to (certain revisisons
> of) M705 to let enter the debug mode, making the thumb button actually
> emit a USB message?
There are two versions of FW in the field:
1) Version 17.01.Build 0017.
This version reports the thumb button by default as HID button 6.
2) Version 17.00.Build 0015
This version does not report the thumb button by default.
It is possible to enable the M705 with FW 17.00.Build 0015 to send the
thumb button as HID button 6 via HIDPP10 command. But this will have a
(undesirable ?) side effect.
Once the button 6 is enabled, the buttons aside to the wheel (tilt
buttons) will no longer be reported as AC pan HID usage, they will be
reported as buttons 7 & 8. This might disrupt some users that rely on
the mouse AC pan feature.
To enable HID button 6 reporting from thumb button we need to clear
the bit 1 (Special button function) in register 0x01 on the M705
READ register: 10 IDX 81 01 r0 r1 r2
Clear Bit1: r0 &= 0xFD;
Write back register: 10 IDX 80 01 r0 r1 r2
IDX is the device index on the Unifying receiver.
Note that if the command is sent to all M705 devices, users that have
the 17.01.Build 0017 will lose the Ac pan and will gain nothing.
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch 1/3] Input: cyttsp4 - silence shift wrap warning
From: Dmitry Torokhov @ 2013-07-03 3:37 UTC (permalink / raw)
To: Dan Carpenter
Cc: Javier Martinez Canillas, Ferruh Yigit, linux-input,
kernel-janitors
In-Reply-To: <20130702214019.GA1598@elgon.mountain>
On Wed, Jul 03, 2013 at 12:40:19AM +0300, Dan Carpenter wrote:
> "*max" is a size_t (long) type but "1" is an int so static checkers
> complain that the shift could wrap.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied all 3, thank you Dan.
>
> diff --git a/drivers/input/touchscreen/cyttsp4_core.c b/drivers/input/touchscreen/cyttsp4_core.c
> index 963da05..7aa4a34 100644
> --- a/drivers/input/touchscreen/cyttsp4_core.c
> +++ b/drivers/input/touchscreen/cyttsp4_core.c
> @@ -153,7 +153,7 @@ static int cyttsp4_hw_reset(struct cyttsp4 *cd)
> */
> static int cyttsp4_bits_2_bytes(unsigned int nbits, size_t *max)
> {
> - *max = 1 << nbits;
> + *max = 1UL << nbits;
> return (nbits + 7) / 8;
> }
>
--
Dmitry
^ permalink raw reply
* One USB mouse problem with runtime power management enabled
From: Peter Chen @ 2013-07-03 2:43 UTC (permalink / raw)
To: Jiri Kosina, Alan Stern
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Hi Jiri and Alan,
I have run below below at 3.5.7 kernel, but after checking upstream
kernel, it may also be existed.
1. evtest /dev/input/event1 &
2. Let mouse auto suspend, enable mouse as wakeup source, and let
the system enters suspend.
echo auto > /sys/bus/usb/devices/1-1/power/control
echo enabled > /sys/bus/platform/devices/2184000.usb/power/wakeup
echo enabled > /sys/bus/usb/devices/usb1/power/wakeup
echo enabled > /sys/bus/usb/devices/1-1/power/wakeup
echo enabled > /sys/bus/platform/devices/ci_hdrc.0/power/wakeup
sleep 3
echo mem > /sys/power/state
3. Resume system with USB mouse button.
4. Console output endless with below message
hub 1-0:1.0: port 1 nyet suspended
hub 1-0:1.0: usb_suspend_interface: status -16
usb usb1: usb_suspend_both: status -16
5. The reason for above message
After system goes to suspend, the roothub is RPM_SUSPENDED
At hub_events it will auto resume roothub, then auto suspend
roothub after system resumes. When it tries to auto suspend roothub,
it will print above message. But usbhid interface is resumed
by system resume, so its can_submit is 1.
Unlike the USB Keyboard, the mouse doesn't have any event after system
resume, so it will not restart OUT/CTRL queues. So the USB mouse will
not do autoresume and autosuspend.
For hid keyboard, it has below message at its usb_hidinput_input_event
after system resume:
hid-generic 0003:413C:2105.0002: type:17, code:0, value:0
hid-generic 0003:413C:2105.0002: type:17, code:1, value:0
hid-generic 0003:413C:2105.0002: type:17, code:2, value:0
hid-generic 0003:413C:2105.0002: type:20, code:1, value:33
hid-generic 0003:413C:2105.0002: type:20, code:0, value:250
6. It will not affect evtest, but the USBHID mouse seems will not do
auto-resume/auto-suspend again even the mouse's button is pressed.
Then the USBHID has always been active (although it is RPM_SUSPENDED)
>From my point, this problem may need to be fixed:
1. At usbhid/input layer:
Since the usbhid device has auto suspended before system suspend, then,
it should still auto suspended after system resume.
2. At USB layer:
It can do auto resume and auto suspend USB device
after system resume to keep the usb device runtime pm status correct.
Thanks.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] hid: add driver for IBM/Lenovo ScrollPoint mice
From: Peter De Wachter @ 2013-07-02 22:42 UTC (permalink / raw)
To: linux-input; +Cc: Jiri Kosina, linux-kernel, Peter De Wachter
IBM Scrollpoint have a trackpoint-like gizmo instead of a scroll wheel,
which allows for two-dimensional scrolling. This driver provides an
input mapping to make that work.
The scrollpoint is also much more sensitive than a typical mouse wheel.
X can use this to provide smooth scrolling, but the kernel doesn't seem
to have a way to communicate this fact. As a result this mouse simply
scrolls way too fast. For now I've created an xorg patch to provide a
manual setting (fdo #48118).
Signed-off-by: Peter De Wachter <pdewacht@gmail.com>
---
drivers/hid/Kconfig | 8 ++++++
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 7 +++++
drivers/hid/hid-ids.h | 7 +++++
drivers/hid/hid-scrollpoint.c | 67 +++++++++++++++++++++++++++++++++++++++++++
5 files changed, 90 insertions(+)
create mode 100644 drivers/hid/hid-scrollpoint.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index fb52f3f..fdc49ca 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -593,6 +593,14 @@ config HID_SAMSUNG
---help---
Support for Samsung InfraRed remote control or keyboards.
+config HID_SCROLLPOINT
+ tristate "IBM/Lenovo ScrollPoint mice"
+ depends on HID
+ ---help---
+ Support for IBM/Lenovo ScrollPoint mice.
+ Say Y here if you have a ScrollPoint mouse and want horizontal
+ scrolling to work.
+
config HID_SONY
tristate "Sony PS3 controller"
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 2065694..4a4c279 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_HID_ROCCAT) += hid-roccat.o hid-roccat-common.o \
hid-roccat-lua.o hid-roccat-pyra.o hid-roccat-savu.o
obj-$(CONFIG_HID_SAITEK) += hid-saitek.o
obj-$(CONFIG_HID_SAMSUNG) += hid-samsung.o
+obj-$(CONFIG_HID_SCROLLPOINT) += hid-scrollpoint.o
obj-$(CONFIG_HID_SMARTJOYPLUS) += hid-sjoy.o
obj-$(CONFIG_HID_SONY) += hid-sony.o
obj-$(CONFIG_HID_SPEEDLINK) += hid-speedlink.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 264f550..003f419 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1584,6 +1584,13 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_GYRATION, USB_DEVICE_ID_GYRATION_REMOTE_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK, USB_DEVICE_ID_HOLTEK_ON_LINE_GRIP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD) },
+#if IS_ENABLED(CONFIG_HID_SCROLLPOINT)
+ { HID_USB_DEVICE(USB_VENDOR_ID_IBM, USB_DEVICE_ID_IBM_SCROLLPOINT_III) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_IBM, USB_DEVICE_ID_IBM_SCROLLPOINT_PRO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_IBM, USB_DEVICE_ID_IBM_SCROLLPOINT_OPTICAL) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_IBM, USB_DEVICE_ID_IBM_SCROLLPOINT_800DPI_OPTICAL) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_IBM, USB_DEVICE_ID_IBM_SCROLLPOINT_800DPI_OPTICAL_PRO) },
+#endif
{ HID_USB_DEVICE(USB_VENDOR_ID_JESS2, USB_DEVICE_ID_JESS2_COLOR_RUMBLE_PAD) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ION, USB_DEVICE_ID_ICADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 38535c9..f813fab 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -441,6 +441,13 @@
#define USB_VENDOR_ID_HOLTEK_ALT 0x04d9
#define USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD 0xa055
+#define USB_VENDOR_ID_IBM 0x04b3
+#define USB_DEVICE_ID_IBM_SCROLLPOINT_III 0x3100
+#define USB_DEVICE_ID_IBM_SCROLLPOINT_PRO 0x3103
+#define USB_DEVICE_ID_IBM_SCROLLPOINT_OPTICAL 0x3105
+#define USB_DEVICE_ID_IBM_SCROLLPOINT_800DPI_OPTICAL 0x3108
+#define USB_DEVICE_ID_IBM_SCROLLPOINT_800DPI_OPTICAL_PRO 0x3109
+
#define USB_VENDOR_ID_IMATION 0x0718
#define USB_DEVICE_ID_DISC_STAKKA 0xd000
diff --git a/drivers/hid/hid-scrollpoint.c b/drivers/hid/hid-scrollpoint.c
new file mode 100644
index 0000000..48e7696
--- /dev/null
+++ b/drivers/hid/hid-scrollpoint.c
@@ -0,0 +1,67 @@
+/*
+ * HID driver for IBM/Lenovo ScrollPoint mice
+ *
+ * Copyright (c) 2012 Peter De Wachter <pdewacht@gmail.com>
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include <linux/device.h>
+#include <linux/hid.h>
+#include <linux/module.h>
+
+#include "hid-ids.h"
+
+static int scrollpoint_input_mapping(struct hid_device *hdev,
+ struct hid_input *hi, struct hid_field *field,
+ struct hid_usage *usage, unsigned long **bit, int *max)
+{
+ if (usage->hid == HID_GD_Z) {
+ hid_map_usage(hi, usage, bit, max, EV_REL, REL_HWHEEL);
+ return 1;
+ }
+ return 0;
+}
+
+static const struct hid_device_id scrollpoint_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_IBM,
+ USB_DEVICE_ID_IBM_SCROLLPOINT_III) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_IBM,
+ USB_DEVICE_ID_IBM_SCROLLPOINT_PRO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_IBM,
+ USB_DEVICE_ID_IBM_SCROLLPOINT_OPTICAL) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_IBM,
+ USB_DEVICE_ID_IBM_SCROLLPOINT_800DPI_OPTICAL) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_IBM,
+ USB_DEVICE_ID_IBM_SCROLLPOINT_800DPI_OPTICAL_PRO) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, scrollpoint_devices);
+
+static struct hid_driver scrollpoint_driver = {
+ .name = "scrollpoint",
+ .id_table = scrollpoint_devices,
+ .input_mapping = scrollpoint_input_mapping
+};
+
+static int __init scrollpoint_init(void)
+{
+ return hid_register_driver(&scrollpoint_driver);
+}
+
+static void __exit scrollpoint_exit(void)
+{
+ hid_unregister_driver(&scrollpoint_driver);
+}
+
+module_init(scrollpoint_init);
+module_exit(scrollpoint_exit);
+
+MODULE_AUTHOR("Peter De Wachter");
+MODULE_DESCRIPTION("IBM/Lenovo ScrollPoint mouse driver");
+MODULE_LICENSE("GPL");
--
1.8.3.2
^ permalink raw reply related
* re: Input: cyttsp4 - SPI driver for Cypress TMA4XX touchscreen devices
From: Dan Carpenter @ 2013-07-02 21:47 UTC (permalink / raw)
To: fery; +Cc: linux-input
Hello Ferruh Yigit,
The patch 67bf12ca50d5: "Input: cyttsp4 - SPI driver for Cypress
TMA4XX touchscreen devices" from Jun 30, 2013, leads to the following
Smatch warning:
"drivers/input/touchscreen/cyttsp4_spi.c:66 cyttsp_spi_xfer()
warn: impossible condition '(reg > 255) => (0-255 > 255)'"
drivers/input/touchscreen/cyttsp4_spi.c
66 if (reg > 255)
^^^^^^^^^
"reg" is unsigned char so 255 is the max it can be.
67 wr_buf[0] = op + CY_SPI_A8_BIT;
68 else
69 wr_buf[0] = op;
regards,
dan carpenter
^ permalink raw reply
* [patch 3/3] Input: cyttsp4 - leak on error path in probe()
From: Dan Carpenter @ 2013-07-02 21:44 UTC (permalink / raw)
To: Javier Martinez Canillas, Ferruh Yigit
Cc: Dmitry Torokhov, linux-input, kernel-janitors
We leak "cd" if the cd->xfer_buf allocation fails. It was weird to
"goto error_gpio_irq" so I changed the label name. (Label names should
reflect the label location not the goto location otherwise you get an
"all roads lead to Rome problem").
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/input/touchscreen/cyttsp4_core.c b/drivers/input/touchscreen/cyttsp4_core.c
index 851e3ff..a7987e1 100644
--- a/drivers/input/touchscreen/cyttsp4_core.c
+++ b/drivers/input/touchscreen/cyttsp4_core.c
@@ -2025,7 +2025,7 @@ struct cyttsp4 *cyttsp4_probe(const struct cyttsp4_bus_ops *ops,
if (!cd->xfer_buf) {
dev_err(dev, "%s: Error, kzalloc\n", __func__);
rc = -ENOMEM;
- goto error_alloc_data;
+ goto error_free_cd;
}
/* Initialize device info */
@@ -2049,7 +2049,7 @@ struct cyttsp4 *cyttsp4_probe(const struct cyttsp4_bus_ops *ops,
cd->irq = gpio_to_irq(cd->cpdata->irq_gpio);
if (cd->irq < 0) {
rc = -EINVAL;
- goto error_gpio_irq;
+ goto error_free_cd;
}
dev_set_drvdata(dev, cd);
@@ -2117,7 +2117,7 @@ error_request_irq:
if (cd->cpdata->init)
cd->cpdata->init(cd->cpdata, 0, dev);
dev_set_drvdata(dev, NULL);
-error_gpio_irq:
+error_free_cd:
kfree(cd);
error_alloc_data:
error_no_pdata:
^ permalink raw reply related
* [patch 2/3] Input: cyttsp4 - silence NULL dereference warning
From: Dan Carpenter @ 2013-07-02 21:41 UTC (permalink / raw)
To: Javier Martinez Canillas, Ferruh Yigit
Cc: Dmitry Torokhov, linux-input, kernel-janitors
If "cd" were NULL then we would dereference it when we print the error
message. Fortunately enough, it can't ever be NULL so we can remove
those lines.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/input/touchscreen/cyttsp4_core.c b/drivers/input/touchscreen/cyttsp4_core.c
index 7aa4a34..851e3ff 100644
--- a/drivers/input/touchscreen/cyttsp4_core.c
+++ b/drivers/input/touchscreen/cyttsp4_core.c
@@ -1450,11 +1450,6 @@ static void cyttsp4_watchdog_work(struct work_struct *work)
u8 *mode;
int retval;
- if (cd == NULL) {
- dev_err(cd->dev, "%s: NULL context pointer\n", __func__);
- return;
- }
-
mutex_lock(&cd->system_lock);
retval = cyttsp4_load_status_regs(cd);
if (retval < 0) {
^ permalink raw reply related
* [patch 1/3] Input: cyttsp4 - silence shift wrap warning
From: Dan Carpenter @ 2013-07-02 21:40 UTC (permalink / raw)
To: Javier Martinez Canillas, Ferruh Yigit
Cc: Dmitry Torokhov, linux-input, kernel-janitors
"*max" is a size_t (long) type but "1" is an int so static checkers
complain that the shift could wrap.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/input/touchscreen/cyttsp4_core.c b/drivers/input/touchscreen/cyttsp4_core.c
index 963da05..7aa4a34 100644
--- a/drivers/input/touchscreen/cyttsp4_core.c
+++ b/drivers/input/touchscreen/cyttsp4_core.c
@@ -153,7 +153,7 @@ static int cyttsp4_hw_reset(struct cyttsp4 *cd)
*/
static int cyttsp4_bits_2_bytes(unsigned int nbits, size_t *max)
{
- *max = 1 << nbits;
+ *max = 1UL << nbits;
return (nbits + 7) / 8;
}
^ permalink raw reply related
* [PATCH] HID: kye: Add report fixup for Genius Gila Gaming mouse
From: Benjamin Tissoires @ 2013-07-02 16:10 UTC (permalink / raw)
To: Benjamin Tissoires, Jiri Kosina, linux-input, linux-kernel
Genius Gila Gaming Mouse presents an obviously wrong report descriptor.
the Consumer control (report ID 3) is the following:
0x05, 0x0c, // Usage Page (Consumer Devices) 105
0x09, 0x01, // Usage (Consumer Control) 107
0xa1, 0x01, // Collection (Application) 109
0x85, 0x03, // Report ID (3) 111
0x19, 0x00, // Usage Minimum (0) 113
0x2a, 0xff, 0x7f, // Usage Maximum (32767) 115
0x15, 0x00, // Logical Minimum (0) 118
0x26, 0xff, 0x7f, // Logical Maximum (32767) 120
0x75, 0x10, // Report Size (16) 123
0x95, 0x03, // Report Count (3) 125
0x81, 0x00, // Input (Data,Arr,Abs) 127
0x75, 0x08, // Report Size (8) 129
0x95, 0x01, // Report Count (1) 131
0x81, 0x01, // Input (Cnst,Arr,Abs) 133
0xc0, // End Collection 135
So the first input whithin this report has a count of 3 but a usage range
of 32768. So this value is obviously wrong as it should not be greater than
the report count.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=959721
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Hi Jiri,
I know the window just opened and you don't really like receiving patches at
that time. Still, my patch queue is growing, and I would like you to consider
this patch for 3.11.
FYI, my patch queue is the following:
- one hid-multitouch patch which set the quirk NO_INIT_REPORTS for mt devices
- few hidp cleanup related to the wrong init_report called during start
- re-implement the hidinput_input_event callback in hidp to allow LEDs to work with BT keyboards
- some trivial devm conversions for some special HID drivers
- add devm_hid_allocate_device which allow to devm-ize i2c-hid
All of these are cleanups/enhancements, so I think we can postpone those patches
to 3.12 to get a maximum testing time.
Cheers,
Benjamin
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-kye.c | 21 +++++++++++++++++++++
3 files changed, 23 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 0951a9a..e39dac6 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1593,6 +1593,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ION, USB_DEVICE_ID_ICADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KEYTOUCH, USB_DEVICE_ID_KEYTOUCH_IEC) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_ERGO_525V) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_I405X) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2afa99a..c5aea29 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -478,6 +478,7 @@
#define USB_VENDOR_ID_KYE 0x0458
#define USB_DEVICE_ID_KYE_ERGO_525V 0x0087
+#define USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE 0x0138
#define USB_DEVICE_ID_KYE_GPEN_560 0x5003
#define USB_DEVICE_ID_KYE_EASYPEN_I405X 0x5010
#define USB_DEVICE_ID_KYE_MOUSEPEN_I608X 0x5011
diff --git a/drivers/hid/hid-kye.c b/drivers/hid/hid-kye.c
index 6af90db..1e2ee2aa 100644
--- a/drivers/hid/hid-kye.c
+++ b/drivers/hid/hid-kye.c
@@ -314,6 +314,25 @@ static __u8 *kye_report_fixup(struct hid_device *hdev, __u8 *rdesc,
*rsize = sizeof(easypen_m610x_rdesc_fixed);
}
break;
+ case USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE:
+ /*
+ * the fixup that need to be done:
+ * - change Usage Maximum in the Comsumer Control
+ * (report ID 3) to a reasonable value
+ */
+ if (*rsize >= 135 &&
+ /* Usage Page (Consumer Devices) */
+ rdesc[104] == 0x05 && rdesc[105] == 0x0c &&
+ /* Usage (Consumer Control) */
+ rdesc[106] == 0x09 && rdesc[107] == 0x01 &&
+ /* Usage Maximum > 12287 */
+ rdesc[114] == 0x2a && rdesc[116] > 0x2f) {
+ hid_info(hdev,
+ "fixing up Genius Gila Gaming Mouse "
+ "report descriptor\n");
+ rdesc[116] = 0x2f;
+ }
+ break;
}
return rdesc;
}
@@ -407,6 +426,8 @@ static const struct hid_device_id kye_devices[] = {
USB_DEVICE_ID_KYE_MOUSEPEN_I608X) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE,
USB_DEVICE_ID_KYE_EASYPEN_M610X) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_KYE,
+ USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE) },
{ }
};
MODULE_DEVICE_TABLE(hid, kye_devices);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 2/3] Input: tps6507x-ts - remove vref from platform data
From: Kevin Hilman @ 2013-07-02 15:49 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, davinci-linux-open-source
In-Reply-To: <1370843627-30823-2-git-send-email-dmitry.torokhov@gmail.com>
On Sun, Jun 9, 2013 at 10:53 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Although defined in platform data, vref is not used anywhere.
>
> Also remove model, irq, and clear_penirq as they are not used either.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Actually, it's used in arch/arm/mach-davinci/board-da850-evm.c.
The following should be folded into this patch. Found by build
failure in linux-next building da8xx_omapl_defconfig for ARM.
Kevin
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 8a24b6c..bea6793 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -985,7 +985,6 @@ static struct regulator_init_data
tps65070_regulator_data[] = {
static struct touchscreen_init_data tps6507x_touchscreen_data = {
.poll_period = 30, /* ms between touch samples */
.min_pressure = 0x30, /* minimum pressure to trigger touch */
- .vref = 0, /* turn off vref when not using A/D */
.vendor = 0, /* /sys/class/input/input?/id/vendor */
.product = 65070, /* /sys/class/input/input?/id/product */
.version = 0x100, /* /sys/class/input/input?/id/version */
^ permalink raw reply related
* Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interface via sysfs
From: Mark Brown @ 2013-07-02 10:11 UTC (permalink / raw)
To: Nick Dyer
Cc: Dmitry Torokhov, Daniel Kurtz, Henrik Rydberg, Joonyoung Shim,
Alan.Bowens, linux-input, linux-kernel, pmeerw, bleung, olofj
In-Reply-To: <51C47C50.8000606@itdev.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]
On Fri, Jun 21, 2013 at 09:16:16AM -0700, Nick Dyer wrote:
> Mark Brown wrote:
> > Yes, to be honest. I'd hope it wouldn't be increasing the number of
> > read/write operations...
> For some operations it does. For example updating the whole chip config
> (which is a common thing to want to do), it would turn a couple of write
> operations into ~20 on recent chips.
Is that really happening on peformance critical paths other than initial
power up (which could be handled more neatly anyway).
> > That still sounds like something the driver can handle (for example, by
> > eating the first error silently if it knows the chip is powered down)
> We've tried to implement this idea of tracking the chip power state in
> the driver and only eating the first error silently when necessary. But
> there are various entertaining corner cases (for example, it may or may
> not be in sleep on probe, how do you deal with intermittent i2c glitch). It
> would end up either being very brittle or an extremely complex mechanism
> involving tracking state and timers, the result of which is only to
> suppress a dmesg debug output saying "i2c retry", and to fail very slightly
> earlier in the normal i2c failure case. The normal fast path through
> this code is exactly the same.
It seems very suspicous that this device has all these problems but
others don't...
> > and of course a system integrator may choose not to copy the reference
> > design in this respect, it does seem a bit odd after all.
> You're being a bit optimistic there. Examples of devices that require
> this are Samsung Galaxy Tab 10.1, Asus Transformer TF101.
If absoluely nobody has used the separate wakeup pin then the hardware
designers are wasting a pin there... my point isn't that nobody would
use the reference design it's that some boards will have the separate
signal.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox