| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The mcp2221_raw_event retrieves the value and direction of gpio on the
same command, by setting the value on mcp->status and the direction on
mcp->gpio_dir; and the offset at which they are read is based on
mcp->gp_idx, set by the gpiochip callbacks.
However, the individual gpiochip calls set the index to look for
directly on the field they want to track. This create a "double offset"
in the final read in the response report.
Align the behaviour of mcp2221_raw_event and
mcp_gpio_get/mcp_gpio_get_direction by putting gp_idx on those calls to
the base offset of the gpio status struct.
Signed-off-by: Louis Morhet <lmorhet@kalrayinc.com>
Link: https://lore.kernel.org/r/dd0b23800a79d2a464e1e9ed429b018b69fd5df2.1680602387.git.lmorhet@kalrayinc.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
|
The documentation of the component (section 3.1.12 GET GPIO VALUES)
describes the hid report structure with two fields per gpio:
its value, followed by its direction.
However, the driver describes it with a wrong order:
direction followed by value.
Fix the structure representing the report answered by the chip to the
GET GPIO VALUES command.
Fixes commit 567b8e9fed8a ("HID: mcp2221: Fix GPIO output handling")
Signed-off-by: Louis Morhet <lmorhet@kalrayinc.com>
Link: https://lore.kernel.org/r/945967fbab56d53f9630ad3844b64734f8c3107e.1680602387.git.lmorhet@kalrayinc.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
|
If the device is plugged/unplugged without giving time for mcp_init_work()
to complete, we might kick in the devm free code path and thus have
unavailable struct mcp_2221 while in delayed work.
Canceling the delayed_work item is enough to solve the issue, because
cancel_delayed_work_sync will prevent the work item to requeue itself.
Fixes: 960f9df7c620 ("HID: mcp2221: add ADC/DAC support via iio subsystem")
CC: stable@vger.kernel.org
Acked-by: Jiri Kosina <jkosina@suse.cz>
Link: https://lore.kernel.org/r/20230215-wip-mcp2221-v2-1-109f71fd036e@redhat.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
|
The MCP2221 driver should not connect to the hidraw userspace interface,
as it needs exclusive access to the chip.
If you want to use /dev/hidrawX with the MCP2221, you need to avoid
binding this driver to the device and use the hid generic driver instead
(e.g. using udev rules).
Cc: stable@vger.kernel.org
Reported-by: Sven Zühlsdorf <sven.zuehlsdorf@vigem.de>
Signed-off-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20221103222714.21566-2-Enrik.Berkhan@inka.de
|
|
Singular #ifdef IS_REACHABLE(CONFIG_GPIOLIB) weren't covering all the
gpiolib functions that were being referenced.
Update the code regions that are commented out when CONFIG_GPIOLIB isn't
enabled to avoid errors.
Fixes: 960f9df7c620 ("HID: mcp2221: add ADC/DAC support via iio subsystem")
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Use (__force __le16) cast for adc_values le16_to_cpu conversion to correct following sparse
warnings:
drivers/hid/hid-mcp2221.c:950:32: sparse: sparse: cast to restricted __le16
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 960f9df7c620 ("HID: mcp2221: add ADC/DAC support via iio subsystem")
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
In mcp2221_raw_event(), 'tmp' is used only conditionally. Move
the declaration into the conditional block in order to prevent
unused variable warning.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 960f9df7c620 ("HID: mcp2221: add ADC/DAC support via iio subsystem")
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Add support for 3x 10-bit ADC and 1x DAC channels registered via the iio
subsystem.
To prevent breakage and unexpected dependencies this support only is
only built if CONFIG_IIO is enabled, and is only weakly referenced by
'imply IIO' within the respective Kconfig.
Additionally the iio device only gets registered if at least one channel
is enabled in the power-on configuration read from SRAM.
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
To avoid recursive dependencies on GPIOLIB when 'imply IIO' is requested
with other drivers we should switch GPIOLIB to an imply.
This isn't the most ideal solution but avoids modifiying the Kconfig for
other drivers, and only requires a singular IS_REACHABLE(CONFIG_GPIOLIB)
check.
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Switch from i2c_add_adapter() to resource managed devm_i2c_add_adapter()
for matching rest of driver initialization, and more concise code.
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Smatch Warning:
drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy()
'&mcp->txbuf[5]' too small (59 vs 255)
drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() 'buf'
too small (34 vs 255)
The 'len' variable can take a value between 0-255 as it can come from
data->block[0] and it is user data. So add an bound check to prevent a
buffer overflow in memcpy().
Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge")
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The mcp2221 driver GPIO output handling has has several issues.
* A wrong value is used for the GPIO direction.
* Wrong offsets are calculated for some GPIO set value/set direction
operations, when offset is larger than 0.
This has been fixed by introducing proper manifest constants for the
direction encoding, and using 'offsetof' when calculating GPIO
register offsets.
The updated driver has been tested with the Sparx5 pcb134/pcb135
board, which has the mcp2221 device with several (output) GPIO's.
Fixes: 328de1c519c5c092 ("HID: mcp2221: add GPIO functionality support")
Reviewed-by: Rishi Gupta <gupt21@gmail.com>
Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
MCP2221 has 4 pins that can be used as GPIO or configured
for alternate functionality such as clock generation and
IRQ detection. This patch adds support for GPIO functionality.
To set direction of a pin or to toggle its state after it
has been configured as GPIO, driver sends command to mcp2221
and parses response received from mcp2221. Based on this
response either 0 or appropriate error code is returned to
GPIO framework.
To get the direction or current state of a pin, driver
sends command and read response from the device. Based on
the response received from device direction or value
is sent to the GPIO framework.
Command from driver to mcp2221 device are output report.
Response received from mcp2221 is input report.
Datasheet (page 45-48) contains details about how to decode
the response received from device:
http://ww1.microchip.com/downloads/en/DeviceDoc/20005565B.pdf
Signed-off-by: Rishi Gupta <gupt21@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
MCP2221 is a USB HID to I2C/SMbus host bridge device. This
commit implements i2c and smbus host adapter support. 7-bit
address and i2c multi-message transaction is also supported.
Signed-off-by: Rishi Gupta <gupt21@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
