Linux commits
My contributions to the Linux kernel, as present in the linux-next repo.
- USB: add RESET_RESUME quirk for NVIDIA Jetson devices in RCM
- docs: submitting-patches: clarify the role of LKML
- docs: gpio: explain GPIOD_OUT_* values and toggling active low
- iio: adis: set GPIO reset pin direction
- USB: cdc-acm: blacklist Heimann USB Appset device
commit fc4ade55c617dc73c7e9756b57f3230b4ff24540
Author: Hannu Hartikainen <hannu@hrtk.in>
Date: Mon Sep 19 20:16:10 2022 +0300
USB: add RESET_RESUME quirk for NVIDIA Jetson devices in RCM
NVIDIA Jetson devices in Force Recovery mode (RCM) do not support
suspending, ie. flashing fails if the device has been suspended. The
devices are still visible in lsusb and seem to work otherwise, making
the issue hard to debug. This has been discovered in various forum
posts, eg. [1].
The patch has been tested on NVIDIA Jetson AGX Xavier, but I'm adding
all the Jetson models listed in [2] on the assumption that they all
behave similarly.
[1]: https://forums.developer.nvidia.com/t/flashing-not-working/72365
[2]: https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3271/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/quick_start.html
Signed-off-by: Hannu Hartikainen <hannu@hrtk.in>
Cc: stable <stable@kernel.org> # after 6.1-rc3
Link: https://lore.kernel.org/r/20220919171610.30484-1-hannu@hrtk.in
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 77167b966b7e671d8ab308b1e31ebfed97986402
Author: Hannu Hartikainen <hannu@hrtk.in>
Date: Wed Jul 7 16:36:35 2021 +0300
docs: submitting-patches: clarify the role of LKML
The documentation previously stated that LKML should be used as *last
resort*. However, scripts/get_maintainer.pl always suggests it and in a
discussion about changing that[0] it turned out that LKML should in fact
receive all patches.
Update documentation to make it clear that all patches should be sent to
LKML by default, in addition to any subsystem-specific lists.
[0]: https://lore.kernel.org/lkml/19a701a8d5837088aa7d8ba594c228c0e040e747.camel@perches.com/
Signed-off-by: Hannu Hartikainen <hannu@hrtk.in>
Link: https://lore.kernel.org/r/20210707133634.286840-1-hannu@hrtk.in
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
commit f3f1017a98f91355671feb0e741391999a43b55d
Author: Hannu Hartikainen <hannu@hrtk.in>
Date: Thu Jul 8 18:20:54 2021 +0300
docs: gpio: explain GPIOD_OUT_* values and toggling active low
I was confused about the gpiod_flags values and thought that
GPIOD_OUT_LOW and GPIOD_OUT_HIGH set the line to be active low / active
high. This is not true, but I got the misconception because the flags
GPIOD_OUT_*_OPEN_DRAIN do change line configuration and there's a
subchapter about *active low* and *open drain* semantics.
Add an explicit mention that the initial value is a logical value (and
not the line configuration or physical line level). Also add a mention
of the function gpiod_toggle_active_low which was previously missing
from this document.
Signed-off-by: Hannu Hartikainen <hannu@hrtk.in>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
commit 7e77ef8b8d600cf8448a2bbd32f682c28884551f
Author: Antti Keränen <detegr@rbx.email>
Date: Thu Jul 8 12:54:29 2021 +0300
iio: adis: set GPIO reset pin direction
Set reset pin direction to output as the reset pin needs to be an active
low output pin.
Co-developed-by: Hannu Hartikainen <hannu@hrtk.in>
Signed-off-by: Hannu Hartikainen <hannu@hrtk.in>
Signed-off-by: Antti Keränen <detegr@rbx.email>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Fixes: ecb010d44108 ("iio: imu: adis: Refactor adis_initial_startup")
Link: https://lore.kernel.org/r/20210708095425.13295-1-detegr@rbx.email
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
commit 4897807753e078655a78de39ed76044d784f3e63
Author: Hannu Hartikainen <hannu@hrtk.in>
Date: Tue Jun 22 17:14:54 2021 +0300
USB: cdc-acm: blacklist Heimann USB Appset device
The device (32a7:0000 Heimann Sensor GmbH USB appset demo) claims to be
a CDC-ACM device in its descriptors but in fact is not. If it is run
with echo disabled it returns garbled data, probably due to something
that happens in the TTY layer. And when run with echo enabled (the
default), it will mess up the calibration data of the sensor the first
time any data is sent to the device.
In short, I had a bad time after connecting the sensor and trying to get
it to work. I hope blacklisting it in the cdc-acm driver will save
someone else a bit of trouble.
Signed-off-by: Hannu Hartikainen <hannu@hrtk.in>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210622141454.337948-1-hannu@hrtk.in
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>