* Re: [PATCH v6 2/2] dt-bindings: mfd: mediatek: mt6397: Convert to DT schema format
From: Macpaul Lin @ 2024-09-23 10:43 UTC (permalink / raw)
To: Alexandre Belloni, AngeloGioacchino Del Regno
Cc: Andrew Lunn, Florian Fainelli, Vladimir Oltean, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Liam Girdwood, Mark Brown, Sean Wang, Sen Chu, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Dmitry Torokhov,
Pavel Machek, Lee Jones, Sebastian Reichel, Chen Zhong,
linux-input, linux-leds, linux-pm, linux-rtc, linux-sound,
Alexandre Mergnat, Bear Wang, Pablo Sun, Macpaul Lin,
Chris-qj chen, MediaTek Chromebook Upstream, Chen-Yu Tsai
In-Reply-To: <202409201337500284902d@mail.local>
On 9/20/24 21:37, Alexandre Belloni wrote:
[snip]
>> > > > > - RTC:
>> > > > > - Drop "start-year"
>> > > >
[snip]
>> >
>>
>> Alexandre, I definitely agree with you on the fact that the MTK PMIC RTC driver
>> can (and needs to) be improved, and that it can make use of some nice cleanup...
>>
>> ... but!
>>
>> This series performs a conversion to schema, and the previous txt file didn't
>> say anything about the start-year property - which was not mandatory to support
>> at that time (nor now, afaik?), so adding support for that is out of scope for
>> this series.
>
> It is mandatory now. I agree this can be done in a subsequent series.
>
Thanks you all for helping with the review and kindly understanding the
situation. I see that Angelo has already submitted the RTC patch set.
I'll check it with the internal driver owner. It seems okay with a quick
glance.
>>
>> Eventually, that can come as a series on top, adding support for that in the
>> binding (and, of course, in the driver).
>>
>> I should be able to tackle that... most probably next week - but still, the
>> improvements would come as a series on top of this one.
>>
>> Cheers,
>> Angelo
>
Thanks
Macpaul Lin
^ permalink raw reply
* Re: [PATCH v6 2/2] dt-bindings: mfd: mediatek: mt6397: Convert to DT schema format
From: AngeloGioacchino Del Regno @ 2024-09-23 9:53 UTC (permalink / raw)
To: Macpaul Lin, Andrew Lunn, Florian Fainelli, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Liam Girdwood, Mark Brown, Sean Wang, Sen Chu, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Dmitry Torokhov,
Pavel Machek, Lee Jones, Sebastian Reichel, Alexandre Belloni,
Chen Zhong, linux-input, linux-leds, linux-pm, linux-rtc,
linux-sound, Alexandre Mergnat
Cc: Bear Wang, Pablo Sun, Macpaul Lin, Chris-qj chen,
MediaTek Chromebook Upstream, Chen-Yu Tsai
In-Reply-To: <20240918064955.6518-2-macpaul.lin@mediatek.com>
Il 18/09/24 08:49, Macpaul Lin ha scritto:
> Convert the mfd: mediatek: mt6397 binding to DT schema format.
>
> MT6323, MT6358, and MT6397 are PMIC devices with multiple function
> subdevices. They share a common PMIC design but have variations in
> subdevice combinations.
>
> Key updates in this conversion:
>
> 1. RTC:
> - Convert rtc-mt6397.txt and merge into parent MT6397 PMIC DT schema.
>
> 2. Regulators:
> - Align to generic name "regulators".
> - Update references from .txt to .yaml for mt6323, mt6358, and mt6397
> regulators.
> - Simplify regulator name labels in device tree examples.
>
> 3. Audio Codec:
> - Convert sound/mt6358.txt and merge into parent MT6397 PMIC DT schema.
> - Align to generic name "audio-codec" for codec and sound subdevices.
> - Add "mediatek,dmic-mode" and "Avdd-supply" properties.
>
> 4. Clocks:
> - Align to generic name "clocks" for clockbuffer subdevices.
>
> 5. LEDs:
> - Convert leds-mt6323.txt and merge into parent MT6397 PMIC DT schema.
> - Update LED binding.
>
> 6. Keys:
> - Add detailed descriptions for power and home keys.
> - Add compatible: mediatek,mt6358-keys.
>
> 7. Power Controller:
> - Convert mt6323-poweroff.txt and merge into parent MT6397 PMIC DT
> schema.
> - Add #power-domain-cells property to fix dt-binding check error.
> - Clarify "BBPU" as "Baseband power up".
>
> 8. Pinctrl:
> - Align to generic name "pinctrl" instead of "pin-controller".
>
> 9. Compatible:
> - Drop "mediatek,mt6357" since there is a separated DT Schema
> for PMIC MT6357.
>
> 10. Examples:
> - MT6323: Retain complete examples for this PMIC.
> - MT6358 and MT6397: simplify settings in regulators.
> - Preserve "audio-codec", "clocks", "pinctrl", "rtc", and "keys"
> sections as they contain typical settings for different PMICs.
>
> Additional updates:
> - MAINTAINERS: Add co-maintainers and reference to
> mfd/mediatek,mt6397.yaml for LED and power-controller drivers.
> - input/mediatek,pmic-keys.yaml: Update reference to
> mfd/mediatek,mt6397.yaml.
>
> Signed-off-by: Sen Chu <sen.chu@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v12 00/38] ep93xx device tree conversion
From: Linus Walleij @ 2024-09-23 9:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Nikita Shubin, Andy Shevchenko, Hartley Sweeten,
Alexander Sverdlin, Russell King, Lukasz Majewski,
Bartosz Golaszewski, Andy Shevchenko, Michael Turquette,
Stephen Boyd, Sebastian Reichel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Wim Van Sebroeck, Guenter Roeck,
Thierry Reding, Uwe Kleine-König, Mark Brown,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Damien Le Moal, Sergey Shtylyov, Dmitry Torokhov, Liam Girdwood,
Jaroslav Kysela, Takashi Iwai, Ralf Baechle, Aaron Wu, Lee Jones,
Olof Johansson, Niklas Cassel, linux-arm-kernel, linux-kernel,
open list:GPIO SUBSYSTEM, linux-clk, linux-pm, devicetree,
dmaengine, linux-watchdog, linux-pwm, linux-spi, Netdev,
linux-mtd, linux-ide, linux-input, linux-sound,
Bartosz Golaszewski, Krzysztof Kozlowski, Andy Shevchenko,
Andrew Lunn
In-Reply-To: <cff6b9b6-6ede-435a-9271-829fde82550d@app.fastmail.com>
On Wed, Sep 11, 2024 at 5:13 PM Arnd Bergmann <arnd@arndb.de> wrote:
> I've merged the series into the for-next branch of the arm-soc
> tree now. The timing isn't great as I was still waiting for
> that final Ack, but it seem better to have it done than to keep
> respinning the series.
>
> I won't send it with the initial pull requests this week
> but hope to send this one once I get beck from LPC, provided
> there are no surprises that require a rebase.
Thanks for picking it up! This is a long awaited patch set.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 15/27] regulator: add s2dos05 regulator support
From: Krzysztof Kozlowski @ 2024-09-23 9:07 UTC (permalink / raw)
To: Dzmitry Sankouski
Cc: Sebastian Reichel, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Neil Armstrong, Jessica Zhang, Sam Ravnborg,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Dmitry Torokhov, Pavel Machek, Liam Girdwood, Mark Brown,
Uwe Kleine-König, Chanwoo Choi, Simona Vetter,
cros-qcom-dts-watchers, Konrad Dybcio, Simona Vetter, linux-pm,
linux-kernel, linux-arm-msm, linux-clk, dri-devel, devicetree,
linux-input, linux-leds, linux-pwm, linux-samsung-soc
In-Reply-To: <CABTCjFCNuMKTeF8YyqCHGQ2CCQ76C1djL_3rja7itLfBM5vogQ@mail.gmail.com>
On 19/09/2024 16:28, Dzmitry Sankouski wrote:
>>> diff --git a/include/linux/regulator/s2dos05.h b/include/linux/regulator/s2dos05.h
>>> new file mode 100644
>>> index 000000000000..2e89fcbce769
>>> --- /dev/null
>>> +++ b/include/linux/regulator/s2dos05.h
>>> @@ -0,0 +1,73 @@
>>> +/* SPDX-License-Identifier: GPL-2.0+ */
>>
>> Are you sure that here (and other places) you want any newer GPL? This
>> is quite odd. Does original code (from which you took 2016 copyrights)
>> have this as well?
>>
> Original code permits redistribution under 2+ license [1].
> Is 2+ preferable over 2 only?
>
> [1]: https://github.com/klabit87/twrp_android_samsung_kernel_sdm845/blob/android-8.0/include/linux/regulator/s2dos05.h#L9
For new code we usually suggest 2-only, but your work looks like
derivative, so keeping 2+ is fine.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] HID: ishtp-hid-client: replace fake-flex arrays with flex-array members
From: Kees Cook @ 2024-09-23 0:22 UTC (permalink / raw)
To: srinivas pandruvada
Cc: Kees Cook, Erick Archer, Jiri Kosina, Benjamin Tissoires,
linux-kernel, linux-input, linux-hardening
From: Erick Archer <erick.archer@outlook.com>
One-element arrays as fake flex arrays are deprecated[1] as the kernel
has switched to C99 flexible-array members instead. This case, however,
has more complexity because it is a flexible array of flexible arrays
and this patch needs to be ready to enable the new compiler flag
-Wflex-array-member-not-at-end (coming in GCC-14) globally.
So, define a new struct type for the single reports:
struct report {
uint16_t size;
struct hostif_msg_hdr msg;
} __packed;
but without the payload (flex array) in it. And add this payload to the
"hostif_msg" structure. This way, in the "report_list" structure we can
declare a flex array of single reports which now do not contain another
flex array.
struct report_list {
[...]
struct report reports[];
} __packed;
Therefore, the "struct hostif_msg" is now made up of a header and a
payload. And the "struct report" uses only the "hostif_msg" header.
The perfect solution would be for the "report" structure to use the
whole "hostif_msg" structure but this is not possible due to nested
flexible arrays. Anyway, the end result is equivalent since this patch
does attempt to change the behaviour of the code.
Now as well, we have more clarity after the cast from the raw bytes to
the new structures. Refactor the code accordingly to use the new
structures.
Also, use "container_of()" whenever we need to retrieve a pointer to
the flexible structure, through which we can access the flexible array
if needed.
Link: https://www.kernel.org/doc/html/next/process/deprecated.html#zero-length-and-one-element-arrays [1]
Closes: https://github.com/KSPP/linux/issues/333
Signed-off-by: Erick Archer <erick.archer@outlook.com>
Link: https://lore.kernel.org/r/AS8PR02MB723760CB93942370E92F00638BF72@AS8PR02MB7237.eurprd02.prod.outlook.com
[kees: tweaked commit log and dropped struct_size() uses]
Signed-off-by: Kees Cook <kees@kernel.org>
---
v2: - update based on feedback
rfc: https://lore.kernel.org/lkml/AS8PR02MB723760CB93942370E92F00638BF72@AS8PR02MB7237.eurprd02.prod.outlook.com/
---
drivers/hid/intel-ish-hid/ishtp-hid-client.c | 25 ++++++++++----------
drivers/hid/intel-ish-hid/ishtp-hid.h | 11 +++++----
2 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
index fbd4f8ea1951..cb04cd1d980b 100644
--- a/drivers/hid/intel-ish-hid/ishtp-hid-client.c
+++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
@@ -70,10 +70,10 @@ static void process_recv(struct ishtp_cl *hid_ishtp_cl, void *recv_buf,
unsigned char *payload;
struct device_info *dev_info;
int i, j;
- size_t payload_len, total_len, cur_pos, raw_len;
+ size_t payload_len, total_len, cur_pos, raw_len, msg_len;
int report_type;
struct report_list *reports_list;
- char *reports;
+ struct report *report;
size_t report_len;
struct ishtp_cl_data *client_data = ishtp_get_client_data(hid_ishtp_cl);
int curr_hid_dev = client_data->cur_hid_dev;
@@ -280,14 +280,13 @@ static void process_recv(struct ishtp_cl *hid_ishtp_cl, void *recv_buf,
case HOSTIF_PUBLISH_INPUT_REPORT_LIST:
report_type = HID_INPUT_REPORT;
reports_list = (struct report_list *)payload;
- reports = (char *)reports_list->reports;
+ report = reports_list->reports;
for (j = 0; j < reports_list->num_of_reports; j++) {
- recv_msg = (struct hostif_msg *)(reports +
- sizeof(uint16_t));
- report_len = *(uint16_t *)reports;
- payload = reports + sizeof(uint16_t) +
- sizeof(struct hostif_msg_hdr);
+ recv_msg = container_of(&report->msg,
+ struct hostif_msg, hdr);
+ report_len = report->size;
+ payload = recv_msg->payload;
payload_len = report_len -
sizeof(struct hostif_msg_hdr);
@@ -304,7 +303,7 @@ static void process_recv(struct ishtp_cl *hid_ishtp_cl, void *recv_buf,
0);
}
- reports += sizeof(uint16_t) + report_len;
+ report += sizeof(*report) + payload_len;
}
break;
default:
@@ -316,12 +315,12 @@ static void process_recv(struct ishtp_cl *hid_ishtp_cl, void *recv_buf,
}
- if (!cur_pos && cur_pos + payload_len +
- sizeof(struct hostif_msg) < total_len)
+ msg_len = payload_len + sizeof(struct hostif_msg);
+ if (!cur_pos && cur_pos + msg_len < total_len)
++client_data->multi_packet_cnt;
- cur_pos += payload_len + sizeof(struct hostif_msg);
- payload += payload_len + sizeof(struct hostif_msg);
+ cur_pos += msg_len;
+ payload += msg_len;
} while (cur_pos < total_len);
}
diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.h b/drivers/hid/intel-ish-hid/ishtp-hid.h
index 35dddc5015b3..2bc19e8ba13e 100644
--- a/drivers/hid/intel-ish-hid/ishtp-hid.h
+++ b/drivers/hid/intel-ish-hid/ishtp-hid.h
@@ -31,6 +31,7 @@ struct hostif_msg_hdr {
struct hostif_msg {
struct hostif_msg_hdr hdr;
+ uint8_t payload[];
} __packed;
struct hostif_msg_to_sensor {
@@ -52,15 +53,17 @@ struct ishtp_version {
uint16_t build;
} __packed;
+struct report {
+ uint16_t size;
+ struct hostif_msg_hdr msg;
+} __packed;
+
/* struct for ISHTP aggregated input data */
struct report_list {
uint16_t total_size;
uint8_t num_of_reports;
uint8_t flags;
- struct {
- uint16_t size_of_report;
- uint8_t report[1];
- } __packed reports[1];
+ struct report reports[];
} __packed;
/* HOSTIF commands */
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v27 01/32] xhci: add helper to stop endpoint and wait for completion
From: Michał Pecio @ 2024-09-22 23:23 UTC (permalink / raw)
To: Wesley Cheng
Cc: mathias.nyman, Thinh.Nguyen, alsa-devel, bgoswami, broonie,
conor+dt, corbet, devicetree, dmitry.torokhov, gregkh, krzk+dt,
lgirdwood, linux-arm-msm, linux-doc, linux-input, linux-kernel,
linux-sound, linux-usb, mathias.nyman, perex,
pierre-louis.bossart, robh, srinivas.kandagatla, tiwai
In-Reply-To: <182938da-da86-49a4-800a-446954cc6c60@quicinc.com>
Hi,
> So what I ended up doing was to split off the context error handling
> into a separate helper API, which can be also called for the sync ep
> stop API. From there, based on say....the helper re queuing the stop
> EP command, it would return a specific value to signify that it has
> done so. The sync based API will then re-wait for the completion of
> the subsequent stop endpoint command that was queued.
AFAIK retries are only necessary on buggy hardware. I don't see them on
my controllers except for two old ones, both with the same buggy chip.
> In all other context error cases, it'd return the error to the caller,
> and its up to them to handle it accordingly.
For the record, all existing callers end up ignoring this return value.
Honestly, I don't know if improving this function is worth your effort
if it's working for you as-is. There are no users except xhci-sideband
and probably shouldn't be - besides failing to fix stalled endpoints,
this function also does nothing to prevent automatic restart of the EP
when new URBs are submitted through xhci_hcd, so it is mainly relevant
for sideband users who never submit URBs the usual way.
My issue with this function is that it is simply poorly documented what
it is or isn't expected to achieve (both here and in the calling code
in xhci-sideband.c), and the changelog message is wrong to suggest that
the default completion handler will run (unless somewhere there are
patches to make it happen), making it look like this code can do things
that it really cannot do. And this is apparently a public, exported API.
Regards,
Michal
^ permalink raw reply
* [dtor-input:for-linus] BUILD REGRESSION b2142a22ef22466575feaccc74a2995c62cae7e8
From: kernel test robot @ 2024-09-22 22:15 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: b2142a22ef22466575feaccc74a2995c62cae7e8 Input: hynitron_cstxxx - drop explicit initialization of struct i2c_device_id::driver_data to 0
Error/Warning (recently discovered and may have been fixed):
https://lore.kernel.org/oe-kbuild-all/202409230614.BBJikfMj-lkp@intel.com
arch/arm/mach-pxa/spitz.c:406:9: error: implicit declaration of function 'PROPERTY_ENTRY_ARRAY_U32'; did you mean 'PROPERTY_ENTRY_U8_ARRAY_LEN'? [-Wimplicit-function-declaration]
arch/arm/mach-pxa/spitz.c:406:9: error: initialization of 'const char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
arch/arm/mach-pxa/spitz.c:406:9: error: initializer element is not constant
Error/Warning ids grouped by kconfigs:
recent_errors
`-- arm-randconfig-001-20240923
|-- arch-arm-mach-pxa-spitz.c:error:implicit-declaration-of-function-PROPERTY_ENTRY_ARRAY_U32
|-- arch-arm-mach-pxa-spitz.c:error:initialization-of-const-char-from-int-makes-pointer-from-integer-without-a-cast
`-- arch-arm-mach-pxa-spitz.c:error:initializer-element-is-not-constant
elapsed time: 791m
configs tested: 168
configs skipped: 4
tested configs:
alpha alldefconfig clang-20
alpha allnoconfig gcc-14.1.0
alpha allyesconfig clang-20
arc allmodconfig clang-20
arc allnoconfig gcc-14.1.0
arc allyesconfig clang-20
arc randconfig-001-20240922 clang-20
arc randconfig-002-20240922 clang-20
arm allmodconfig clang-20
arm allnoconfig gcc-14.1.0
arm allyesconfig clang-20
arm davinci_all_defconfig clang-20
arm h3600_defconfig clang-20
arm milbeaut_m10v_defconfig clang-20
arm mvebu_v7_defconfig clang-20
arm qcom_defconfig clang-20
arm randconfig-001-20240922 clang-20
arm randconfig-002-20240922 clang-20
arm randconfig-003-20240922 clang-20
arm randconfig-004-20240922 clang-20
arm sama7_defconfig clang-20
arm64 allmodconfig clang-20
arm64 allnoconfig gcc-14.1.0
arm64 randconfig-001-20240922 clang-20
arm64 randconfig-002-20240922 clang-20
arm64 randconfig-003-20240922 clang-20
arm64 randconfig-004-20240922 clang-20
csky allnoconfig gcc-14.1.0
csky randconfig-001-20240922 clang-20
csky randconfig-002-20240922 clang-20
hexagon allmodconfig clang-20
hexagon allnoconfig gcc-14.1.0
hexagon allyesconfig clang-20
hexagon randconfig-001-20240922 clang-20
hexagon randconfig-002-20240922 clang-20
i386 allmodconfig clang-18
i386 allmodconfig gcc-12
i386 allnoconfig clang-18
i386 allnoconfig gcc-12
i386 allyesconfig clang-18
i386 allyesconfig gcc-12
i386 buildonly-randconfig-001-20240922 gcc-12
i386 buildonly-randconfig-002-20240922 gcc-12
i386 buildonly-randconfig-003-20240922 gcc-12
i386 buildonly-randconfig-004-20240922 gcc-12
i386 buildonly-randconfig-005-20240922 gcc-12
i386 buildonly-randconfig-006-20240922 gcc-12
i386 defconfig clang-18
i386 randconfig-001-20240922 gcc-12
i386 randconfig-002-20240922 gcc-12
i386 randconfig-003-20240922 gcc-12
i386 randconfig-004-20240922 gcc-12
i386 randconfig-005-20240922 gcc-12
i386 randconfig-006-20240922 gcc-12
i386 randconfig-011-20240922 gcc-12
i386 randconfig-012-20240922 gcc-12
i386 randconfig-013-20240922 gcc-12
i386 randconfig-014-20240922 gcc-12
i386 randconfig-015-20240922 gcc-12
i386 randconfig-016-20240922 gcc-12
loongarch allmodconfig gcc-14.1.0
loongarch allnoconfig gcc-14.1.0
loongarch randconfig-001-20240922 clang-20
loongarch randconfig-002-20240922 clang-20
m68k allmodconfig gcc-14.1.0
m68k allnoconfig gcc-14.1.0
m68k allyesconfig gcc-14.1.0
microblaze allmodconfig gcc-14.1.0
microblaze allnoconfig gcc-14.1.0
microblaze allyesconfig gcc-14.1.0
mips allnoconfig gcc-14.1.0
mips decstation_r4k_defconfig clang-20
mips mtx1_defconfig clang-20
mips pic32mzda_defconfig clang-20
nios2 allnoconfig gcc-14.1.0
nios2 randconfig-001-20240922 clang-20
nios2 randconfig-002-20240922 clang-20
openrisc allnoconfig clang-20
openrisc allnoconfig gcc-14.1.0
openrisc allyesconfig gcc-14.1.0
openrisc defconfig gcc-12
parisc allmodconfig gcc-14.1.0
parisc allnoconfig clang-20
parisc allnoconfig gcc-14.1.0
parisc allyesconfig gcc-14.1.0
parisc defconfig gcc-12
parisc randconfig-001-20240922 clang-20
parisc randconfig-002-20240922 clang-20
powerpc allmodconfig gcc-14.1.0
powerpc allnoconfig clang-20
powerpc allnoconfig gcc-14.1.0
powerpc allyesconfig gcc-14.1.0
powerpc powernv_defconfig clang-20
powerpc randconfig-002-20240922 clang-20
powerpc64 randconfig-001-20240922 clang-20
powerpc64 randconfig-002-20240922 clang-20
powerpc64 randconfig-003-20240922 clang-20
riscv allmodconfig gcc-14.1.0
riscv allnoconfig clang-20
riscv allnoconfig gcc-14.1.0
riscv allyesconfig gcc-14.1.0
riscv defconfig gcc-12
riscv nommu_virt_defconfig clang-20
riscv randconfig-001-20240922 clang-20
riscv randconfig-002-20240922 clang-20
s390 allmodconfig gcc-14.1.0
s390 allnoconfig clang-20
s390 allyesconfig gcc-14.1.0
s390 defconfig gcc-12
s390 randconfig-001-20240922 clang-20
s390 randconfig-002-20240922 clang-20
sh allmodconfig gcc-14.1.0
sh allnoconfig gcc-14.1.0
sh allyesconfig gcc-14.1.0
sh defconfig gcc-12
sh hp6xx_defconfig clang-20
sh landisk_defconfig clang-20
sh randconfig-001-20240922 clang-20
sh randconfig-002-20240922 clang-20
sh secureedge5410_defconfig clang-20
sh sh7785lcr_32bit_defconfig clang-20
sparc allmodconfig gcc-14.1.0
sparc64 defconfig gcc-12
sparc64 randconfig-001-20240922 clang-20
sparc64 randconfig-002-20240922 clang-20
um allmodconfig clang-20
um allnoconfig clang-17
um allnoconfig clang-20
um allyesconfig clang-20
um defconfig gcc-12
um i386_defconfig gcc-12
um randconfig-001-20240922 clang-20
um randconfig-002-20240922 clang-20
um x86_64_defconfig gcc-12
x86_64 allnoconfig clang-18
x86_64 allyesconfig clang-18
x86_64 buildonly-randconfig-001-20240922 clang-18
x86_64 buildonly-randconfig-002-20240922 clang-18
x86_64 buildonly-randconfig-003-20240922 clang-18
x86_64 buildonly-randconfig-004-20240922 clang-18
x86_64 buildonly-randconfig-005-20240922 clang-18
x86_64 buildonly-randconfig-006-20240922 clang-18
x86_64 defconfig clang-18
x86_64 defconfig gcc-11
x86_64 kexec clang-18
x86_64 randconfig-001-20240922 clang-18
x86_64 randconfig-002-20240922 clang-18
x86_64 randconfig-003-20240922 clang-18
x86_64 randconfig-004-20240922 clang-18
x86_64 randconfig-005-20240922 clang-18
x86_64 randconfig-006-20240922 clang-18
x86_64 randconfig-011-20240922 clang-18
x86_64 randconfig-012-20240922 clang-18
x86_64 randconfig-013-20240922 clang-18
x86_64 randconfig-014-20240922 clang-18
x86_64 randconfig-015-20240922 clang-18
x86_64 randconfig-016-20240922 clang-18
x86_64 randconfig-071-20240922 clang-18
x86_64 randconfig-072-20240922 clang-18
x86_64 randconfig-073-20240922 clang-18
x86_64 randconfig-074-20240922 clang-18
x86_64 randconfig-075-20240922 clang-18
x86_64 randconfig-076-20240922 clang-18
x86_64 rhel-8.3 gcc-12
x86_64 rhel-8.3-rust clang-18
xtensa allnoconfig gcc-14.1.0
xtensa randconfig-001-20240922 clang-20
xtensa randconfig-002-20240922 clang-20
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:for-linus 4/40] arch/arm/mach-pxa/spitz.c:406:9: error: implicit declaration of function 'PROPERTY_ENTRY_ARRAY_U32'; did you mean 'PROPERTY_ENTRY_U8_ARRAY_LEN'?
From: kernel test robot @ 2024-09-22 22:12 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: oe-kbuild-all, linux-input, Linus Walleij
tree: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
head: b2142a22ef22466575feaccc74a2995c62cae7e8
commit: 1b05a701375107b2c2beae9c518b8e1a3819e086 [4/40] ARM: spitz: Use software nodes/properties for the matrix keypad
config: arm-randconfig-001-20240923 (https://download.01.org/0day-ci/archive/20240923/202409230614.BBJikfMj-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 14.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240923/202409230614.BBJikfMj-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202409230614.BBJikfMj-lkp@intel.com/
All errors (new ones prefixed by >>):
>> arch/arm/mach-pxa/spitz.c:406:9: error: implicit declaration of function 'PROPERTY_ENTRY_ARRAY_U32'; did you mean 'PROPERTY_ENTRY_U8_ARRAY_LEN'? [-Wimplicit-function-declaration]
406 | PROPERTY_ENTRY_ARRAY_U32("linux,keymap", spitz_keymap),
| ^~~~~~~~~~~~~~~~~~~~~~~~
| PROPERTY_ENTRY_U8_ARRAY_LEN
>> arch/arm/mach-pxa/spitz.c:406:9: error: initialization of 'const char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
arch/arm/mach-pxa/spitz.c:406:9: note: (near initialization for 'spitz_mkp_properties[0].name')
>> arch/arm/mach-pxa/spitz.c:406:9: error: initializer element is not constant
arch/arm/mach-pxa/spitz.c:406:9: note: (near initialization for 'spitz_mkp_properties[0].name')
vim +406 arch/arm/mach-pxa/spitz.c
404
405 static const struct property_entry spitz_mkp_properties[] = {
> 406 PROPERTY_ENTRY_ARRAY_U32("linux,keymap", spitz_keymap),
407 PROPERTY_ENTRY_REF_ARRAY("row-gpios", spitz_mkp_row_gpios),
408 PROPERTY_ENTRY_REF_ARRAY("col-gpios", spitz_mkp_col_gpios),
409 PROPERTY_ENTRY_U32("col-scan-delay-us", 10),
410 PROPERTY_ENTRY_U32("debounce-delay-ms", 10),
411 PROPERTY_ENTRY_BOOL("wakeup-source"),
412 { }
413 };
414
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] Input: hynitron_cstxxx - Drop explicit initialization of struct i2c_device_id::driver_data to 0
From: Dmitry Torokhov @ 2024-09-22 9:47 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: linux-input
In-Reply-To: <20240920153430.503212-12-u.kleine-koenig@baylibre.com>
On Fri, Sep 20, 2024 at 05:34:30PM +0200, Uwe Kleine-König wrote:
> These drivers don't use the driver_data member of struct i2c_device_id,
> so don't explicitly initialize this member.
>
> This prepares putting driver_data in an anonymous union which requires
> either no initialization or named designators. But it's also a nice
> cleanup on its own.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] platform/x86: ideapad-laptop: Stop calling i8042_command()
From: Maxim Mikityanskiy @ 2024-09-22 8:35 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Hans de Goede, Ike Panhc, Ilpo Järvinen, Andy Shevchenko,
platform-driver-x86, linux-input, Jonathan Denose, stable
In-Reply-To: <ZteiClP9jabjHFkG@google.com>
On Tue, 03 Sep 2024 at 16:55:54 -0700, Dmitry Torokhov wrote:
> On Tue, Aug 20, 2024 at 10:28:24PM -0700, Dmitry Torokhov wrote:
> > On Wed, Aug 21, 2024 at 12:40:34AM +0300, Maxim Mikityanskiy wrote:
> > > On Tue, 20 Aug 2024 at 13:46:53 +0300, Maxim Mikityanskiy wrote:
> > > > On Sun, 18 Aug 2024 at 13:30:37 -0700, Dmitry Torokhov wrote:
> > > > >
> > > > > Maybe something like below can work?
> > > >
> > > > Great patch, thank you, I'll test it and report the results. See some
> > > > minor comments below.
> > > >
> > > > >
> > > > >
> > > > > platform/x86: ideapad-laptop: do not poke keyboard controller
> > > > >
> > > > > From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > > >
> > > > > On Ideapad Z570 the driver tries to disable and reenable data coming
> > > > > from the touchpad by poking directly into 8042 keyboard controller.
> > > > > This may coincide with the controller resuming and leads to spews in
> > > > > dmesg and potentially other instabilities.
> > > > >
> > > > > Instead of using i8042_command() to control the touchpad state create a
> > > > > input handler that serves as a filter and drop events coming from the
> > > > > touchpad when it is supposed to be off.
> > > > >
> > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > > > ---
> > > > > drivers/platform/x86/ideapad-laptop.c | 171 ++++++++++++++++++++++++++++++++-
> > > > > 1 file changed, 168 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/ideapad-laptop.c
> > > > > index fcf13d88fd6e..2f40feefd5e3 100644
> > > > > --- a/drivers/platform/x86/ideapad-laptop.c
> > > > > +++ b/drivers/platform/x86/ideapad-laptop.c
> > > > > @@ -17,7 +17,6 @@
> > > > > #include <linux/device.h>
> > > > > #include <linux/dmi.h>
> > > > > #include <linux/fb.h>
> > > > > -#include <linux/i8042.h>
> > > > > #include <linux/init.h>
> > > > > #include <linux/input.h>
> > > > > #include <linux/input/sparse-keymap.h>
> > > > > @@ -157,6 +156,13 @@ struct ideapad_private {
> > > > > struct led_classdev led;
> > > > > unsigned int last_brightness;
> > > > > } fn_lock;
> > > > > + struct {
> > > > > + bool initialized;
> > > > > + bool active;
> > > > > + struct input_handler handler;
> > > > > + struct input_dev *tp_dev;
> > > > > + spinlock_t lock;
> > > > > + } tp_switch;
> > > > > };
> > > > >
> > > > > static bool no_bt_rfkill;
> > > > > @@ -1236,6 +1242,158 @@ static void ideapad_check_special_buttons(struct ideapad_private *priv)
> > > > > }
> > > > > }
> > > > >
> > > > > +struct ideapad_tpswitch_handle {
> > > > > + struct input_handle handle;
> > > > > + struct ideapad_private *priv;
> > > > > +};
> > > > > +
> > > > > +#define to_tpswitch_handle(h) \
> > > > > + container_of(h, struct ideapad_tpswitch_handle, handle);
> > > > > +
> > > > > +static int ideapad_tpswitch_connect(struct input_handler *handler,
> > > > > + struct input_dev *dev,
> > > > > + const struct input_device_id *id)
> > > > > +{
> > > > > + struct ideapad_private *priv =
> > > > > + container_of(handler, struct ideapad_private, tp_switch.handler);
> > > > > + struct ideapad_tpswitch_handle *h;
> > > > > + int error;
> > > > > +
> > > > > + h = kzalloc(sizeof(*h), GFP_KERNEL);
> > > > > + if (!h)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + h->priv = priv;
> > > > > + h->handle.dev = dev;
> > > > > + h->handle.handler = handler;
> > > > > + h->handle.name = "ideapad-tpswitch";
> > > > > +
> > > > > + error = input_register_handle(&h->handle);
> > > > > + if (error)
> > > > > + goto err_free_handle;
> > > > > +
> > > > > + /*
> > > > > + * FIXME: ideally we do not want to open the input device here
> > > > > + * if there are no other users. We need a notion of "observer"
> > > > > + * handlers in the input core.
> > > > > + */
> > > > > + error = input_open_device(&h->handle);
> > > > > + if (error)
> > > > > + goto err_unregister_handle;
> > > > > +
> > > > > + scoped_guard(spinlock_irq, &priv->tp_switch.lock)
> > > > > + priv->tp_switch.tp_dev = dev;
> > > > > +
> > > > > + return 0;
> > > > > +
> > > > > + err_unregister_handle:
> > > > > + input_unregister_handle(&h->handle);
> > > > > +err_free_handle:
> > > > > + kfree(h);
> > > > > + return error;
> > > > > +}
> > > > > +
> > > > > +static void ideapad_tpswitch_disconnect(struct input_handle *handle)
> > > > > +{
> > > > > + struct ideapad_tpswitch_handle *h = to_tpswitch_handle(handle);
> > > > > + struct ideapad_private *priv = h->priv;
> > > > > +
> > > > > + scoped_guard(spinlock_irq, &priv->tp_switch.lock)
> > > >
> > > > Nice syntax, I didn't know about it before.
> > > >
> > > > > + priv->tp_switch.tp_dev = NULL;
> > > > > +
> > > > > + input_close_device(handle);
> > > > > + input_unregister_handle(handle);
> > > > > + kfree(h);
> > > > > +}
> > > > > +
> > > > > +static bool ideapad_tpswitch_filter(struct input_handle *handle,
> > > > > + unsigned int type, unsigned int code,
> > > > > + int value)
> > > > > +{
> > > > > + struct ideapad_tpswitch_handle *h = to_tpswitch_handle(handle);
> > > > > + struct ideapad_private *priv = h->priv;
> > > > > +
> > > > > + if (!priv->tp_switch.active)
> > > >
> > > > This check seems inverted. ideapad_tpswitch_toggle assigns true when the
> > > > touchpad is enabled.
> > >
> > > I tested the patch on Z570 (with this check inverted), and it seems to
> > > work great.
> > >
> > > Also tested what happens on resume from suspend: the laptop reenables
> > > the touchpad (the LED turns off on suspend and blinks briefly on
> > > resume), and the driver handles it properly.
> >
> > Great, thank you! Give me a couple of days and I think I will implement
> > observer/passive handler support and we can figure out how to merge
> > this...
>
> OK, so if you could try the patch below that would be great.
> Don't forget to set ".passive_observer = 1" in the ideapad handler.
Sorry for the slow response. I tested the patches, setting
passive_observer in ideapad_tpswitch_init and inverting the check in
ideapad_tpswitch_filter - all seems to work perfectly!
> Thanks!
>
> --
> Dmitry
>
>
> Input: introduce notion of passive observers for input handlers
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/input.c | 7 +++++++
> include/linux/input.h | 5 +++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 54c57b267b25..60a9445d78d5 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -605,6 +605,9 @@ int input_open_device(struct input_handle *handle)
>
> handle->open++;
>
> + if (handle->handler->passive_observer)
> + goto out;
> +
> if (dev->users++ || dev->inhibited) {
> /*
> * Device is already opened and/or inhibited,
> @@ -668,6 +671,9 @@ void input_close_device(struct input_handle *handle)
>
> __input_release_device(handle);
>
> + if (handle->handler->passive_observer)
> + goto out;
> +
> if (!--dev->users && !dev->inhibited) {
> if (dev->poller)
> input_dev_poller_stop(dev->poller);
> @@ -684,6 +690,7 @@ void input_close_device(struct input_handle *handle)
> synchronize_rcu();
> }
>
> +out:
> mutex_unlock(&dev->mutex);
> }
> EXPORT_SYMBOL(input_close_device);
> diff --git a/include/linux/input.h b/include/linux/input.h
> index 89a0be6ee0e2..6437c35f0796 100644
> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> @@ -286,6 +286,10 @@ struct input_handle;
> * @start: starts handler for given handle. This function is called by
> * input core right after connect() method and also when a process
> * that "grabbed" a device releases it
> + * @passive_observer: set to %true by drivers only interested in observing
> + * data stream from devices if there are other users present. Such
> + * drivers will not result in starting underlying hardware device
> + * when input_open_device() is called for their handles
> * @legacy_minors: set to %true by drivers using legacy minor ranges
> * @minor: beginning of range of 32 legacy minors for devices this driver
> * can provide
> @@ -321,6 +325,7 @@ struct input_handler {
> void (*disconnect)(struct input_handle *handle);
> void (*start)(struct input_handle *handle);
>
> + bool passive_observer;
> bool legacy_minors;
> int minor;
> const char *name;
^ permalink raw reply
* Re: [PATCH] Input: ims-pcu - fix a mutex usage error
From: Dmitry Torokhov @ 2024-09-22 7:58 UTC (permalink / raw)
To: Donglin Peng; +Cc: javier.carrasco.cruz, kees, linux-input, linux-kernel
In-Reply-To: <20240921071501.263450-1-dolinux.peng@gmail.com>
Hi Donglin,
On Sat, Sep 21, 2024 at 03:15:01PM +0800, Donglin Peng wrote:
> The mutex_lock_interruptible should be switched to scoped_cond_guard(mutex_intr, ...)
> instead of scoped_cond_guard(mutex, ..).
Thank you for the patch but I already got a fix for this issue:
https://lore.kernel.org/r/20240910-input-misc-ims-pcu-fix-mutex-intr-v1-1-bdd983685c43@baylibre.com
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 07/27] drm/panel: Add support for S6E3HA8 panel driver
From: Dmitry Baryshkov @ 2024-09-21 20:34 UTC (permalink / raw)
To: Dzmitry Sankouski
Cc: Sebastian Reichel, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Neil Armstrong, Jessica Zhang, Sam Ravnborg,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Dmitry Torokhov, Pavel Machek, Liam Girdwood, Mark Brown,
Uwe Kleine-König, Krzysztof Kozlowski, Chanwoo Choi,
Simona Vetter, cros-qcom-dts-watchers, Konrad Dybcio,
Simona Vetter, linux-pm, linux-kernel, linux-arm-msm, linux-clk,
dri-devel, devicetree, linux-input, linux-leds, linux-pwm,
linux-samsung-soc
In-Reply-To: <20240913-starqltechn_integration_upstream-v4-7-2d2efd5c5877@gmail.com>
On Fri, Sep 13, 2024 at 06:07:50PM GMT, Dzmitry Sankouski wrote:
> Add support for MIPI-DSI based S6E3HA8 AMOLED panel
> driver. This panel has 1440x2960 resolution, 5.8-inch physical
> size, and can be found in starqltechn device.
> Brightness regulation is not yet supported.
>
> Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com>
>
> Changes in v4:
> - inline power related functions
> - rework driver using new mipi_dsi_dcs_write_seq_multi macro
> - use drm_connector_helper_get_modes_fixed for modes
> - remove excessive compression setting
> ---
> MAINTAINERS | 1 +
> drivers/gpu/drm/panel/Kconfig | 7 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-samsung-s6e3ha8.c | 350 ++++++++++++++++++++++++++
> 4 files changed, 359 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 92135252264a..65cb2511ba22 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7385,6 +7385,7 @@ DRM DRIVER FOR SAMSUNG S6E3HA8 PANELS
> M: Dzmitry Sankouski <dsankouski@gmail.com>
> S: Maintained
> F: Documentation/devicetree/bindings/display/panel/samsung,s6e3ha8.yaml
> +F: drivers/gpu/drm/panel/panel-samsung-s6e3ha8.c
>
> DRM DRIVER FOR SITRONIX ST7586 PANELS
> M: David Lechner <david@lechnology.com>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index d3a9a9fafe4e..65fb3a466e39 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -689,6 +689,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
> depends on BACKLIGHT_CLASS_DEVICE
> select VIDEOMODE_HELPERS
>
> +config DRM_PANEL_SAMSUNG_S6E3HA8
> + tristate "Samsung S6E3HA8 DSI video mode panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + select VIDEOMODE_HELPERS
> +
> config DRM_PANEL_SAMSUNG_S6E63J0X03
> tristate "Samsung S6E63J0X03 DSI command mode panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 987a08702410..8ee28f5a2213 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -70,6 +70,7 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D27A1) += panel-samsung-s6d27a1.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D7AA0) += panel-samsung-s6d7aa0.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3FA7) += panel-samsung-s6e3fa7.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA8) += panel-samsung-s6e3ha8.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63M0) += panel-samsung-s6e63m0.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63M0_SPI) += panel-samsung-s6e63m0-spi.o
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha8.c b/drivers/gpu/drm/panel/panel-samsung-s6e3ha8.c
> new file mode 100644
> index 000000000000..e69943f0527e
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha8.c
> @@ -0,0 +1,350 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +//
> +// Generated with linux-mdss-dsi-panel-driver-generator from vendor device tree:
> +// Copyright (c) 2013, The Linux Foundation. All rights reserved.
> +// Copyright (c) 2024 Dzmitry Sankouski <dsankouski@gmail.com>
> +
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <drm/display/drm_dsc.h>
> +#include <drm/display/drm_dsc_helper.h>
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_probe_helper.h>
> +#include <drm/drm_panel.h>
> +
> +struct s6e3ha8 {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + struct drm_dsc_config dsc;
> + struct gpio_desc *reset_gpio;
> + struct regulator_bulk_data supplies[3];
> +};
> +
> +static inline
> +struct s6e3ha8 *to_s6e3ha8_amb577px01_wqhd(struct drm_panel *panel)
> +{
> + return container_of(panel, struct s6e3ha8, panel);
> +}
> +
> +#define s6e3ha8_test_key_on_lvl2(ctx) \
> + mipi_dsi_dcs_write_seq_multi(ctx, 0xf0, 0x5a, 0x5a)
> +#define s6e3ha8_test_key_off_lvl2(ctx) \
> + mipi_dsi_dcs_write_seq_multi(ctx, 0xf0, 0xa5, 0xa5)
> +#define s6e3ha8_test_key_on_lvl3(ctx) \
> + mipi_dsi_dcs_write_seq_multi(ctx, 0xfc, 0x5a, 0x5a)
> +#define s6e3ha8_test_key_off_lvl3(ctx) \
> + mipi_dsi_dcs_write_seq_multi(ctx, 0xfc, 0xa5, 0xa5)
> +#define s6e3ha8_test_key_on_lvl1(ctx) \
> + mipi_dsi_dcs_write_seq_multi(ctx, 0x9f, 0xa5, 0xa5)
> +#define s6e3ha8_test_key_off_lvl1(ctx) \
> + mipi_dsi_dcs_write_seq_multi(ctx, 0x9f, 0x5a, 0x5a)
> +#define s6e3ha8_afc_off(ctx) \
> + mipi_dsi_dcs_write_seq_multi(ctx, 0xe2, 0x00, 0x00)
> +
> +static void s6e3ha8_amb577px01_wqhd_reset(struct s6e3ha8 *priv)
> +{
> + gpiod_set_value_cansleep(priv->reset_gpio, 1);
> + usleep_range(5000, 6000);
> + gpiod_set_value_cansleep(priv->reset_gpio, 0);
> + usleep_range(5000, 6000);
> + gpiod_set_value_cansleep(priv->reset_gpio, 1);
> + usleep_range(5000, 6000);
> +}
> +
> +static int s6e3ha8_amb577px01_wqhd_on(struct s6e3ha8 *priv)
> +{
> + struct mipi_dsi_device *dsi = priv->dsi;
> + struct device *dev = &dsi->dev;
> + struct mipi_dsi_multi_context ctx = { .dsi = dsi };
> + int ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + s6e3ha8_test_key_on_lvl1(&ctx);
> + s6e3ha8_test_key_on_lvl2(&ctx);
> +
> + ret = mipi_dsi_compression_mode(dsi, true);
> + if (ret < 0) {
> + dev_err(dev, "Failed to set compression mode: %d\n", ret);
> + return ret;
> + }
> +
> + s6e3ha8_test_key_off_lvl2(&ctx);
> +
> + ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> + if (ret < 0) {
> + dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
> + return ret;
> + }
> + usleep_range(5000, 6000);
> +
> + s6e3ha8_test_key_on_lvl2(&ctx);
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xf2, 0x13);
> + s6e3ha8_test_key_off_lvl2(&ctx);
> +
> + usleep_range(10000, 11000);
> +
> + s6e3ha8_test_key_on_lvl2(&ctx);
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xf2, 0x13);
> + s6e3ha8_test_key_off_lvl2(&ctx);
> +
> + /* OMOK setting 1 (Initial setting) - Scaler Latch Setting Guide */
> + s6e3ha8_test_key_on_lvl2(&ctx);
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xb0, 0x07);
> + /* latch setting 1 : Scaler on/off & address setting & PPS setting -> Image update latch */
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xf2, 0x3c, 0x10);
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xb0, 0x0b);
> + /* latch setting 2 : Ratio change mode -> Image update latch */
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xf2, 0x30);
> + /* OMOK setting 2 - Seamless setting guide : WQHD */
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0x2a, 0x00, 0x00, 0x05, 0x9f); /* CASET */
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0x2b, 0x00, 0x00, 0x0b, 0x8f); /* PASET */
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xba, 0x01); /* scaler setup : scaler off */
> + s6e3ha8_test_key_off_lvl2(&ctx);
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0x35, 0x00); /* TE Vsync ON */
> + s6e3ha8_test_key_on_lvl2(&ctx);
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xed, 0x4c); /* ERR_FG */
> + s6e3ha8_test_key_off_lvl2(&ctx);
> + s6e3ha8_test_key_on_lvl3(&ctx);
> + /* FFC Setting 897.6Mbps */
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xc5, 0x0d, 0x10, 0xb4, 0x3e, 0x01);
> + s6e3ha8_test_key_off_lvl3(&ctx);
> + s6e3ha8_test_key_on_lvl2(&ctx);
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xb9,
> + 0x00, 0xb0, 0x81, 0x09, 0x00, 0x00, 0x00,
> + 0x11, 0x03); /* TSP HSYNC Setting */
> + s6e3ha8_test_key_off_lvl2(&ctx);
> + s6e3ha8_test_key_on_lvl2(&ctx);
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xb0, 0x03);
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xf6, 0x43);
> + s6e3ha8_test_key_off_lvl2(&ctx);
> + s6e3ha8_test_key_on_lvl2(&ctx);
> + /* Brightness condition set */
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xca,
> + 0x07, 0x00, 0x00, 0x00, 0x80, 0x80, 0x80,
> + 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
> + 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
> + 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
> + 0x80, 0x80, 0x80, 0x00, 0x00, 0x00);
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xb1, 0x00, 0x0c); /* AID Set : 0% */
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xb5,
> + 0x19, 0xdc, 0x16, 0x01, 0x34, 0x67, 0x9a,
> + 0xcd, 0x01, 0x22, 0x33, 0x44, 0x00, 0x00,
> + 0x05, 0x55, 0xcc, 0x0c, 0x01, 0x11, 0x11,
> + 0x10); /* MPS/ELVSS Setting */
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xf4, 0xeb, 0x28); /* VINT */
> + mipi_dsi_dcs_write_seq_multi(&ctx, 0xf7, 0x03); /* Gamma, LTPS(AID) update */
> + s6e3ha8_test_key_off_lvl2(&ctx);
> + s6e3ha8_test_key_off_lvl1(&ctx);
> +
> + return 0;
return ctx.accum_err;
> +}
> +
> +static int s6e3ha8_enable(struct drm_panel *panel)
> +{
> + struct s6e3ha8 *priv = to_s6e3ha8_amb577px01_wqhd(panel);
> + struct mipi_dsi_device *dsi = priv->dsi;
> + struct mipi_dsi_multi_context ctx = { .dsi = dsi };
> +
> + s6e3ha8_test_key_on_lvl1(&ctx);
> + ctx.accum_err = mipi_dsi_dcs_set_display_on(dsi);
> + s6e3ha8_test_key_off_lvl1(&ctx);
> +
> + return ctx.accum_err;
> +}
> +
> +static int s6e3ha8_disable(struct drm_panel *panel)
> +{
> + struct s6e3ha8 *priv = to_s6e3ha8_amb577px01_wqhd(panel);
> + struct mipi_dsi_device *dsi = priv->dsi;
> + struct mipi_dsi_multi_context ctx = { .dsi = dsi };
> +
> + s6e3ha8_test_key_on_lvl1(&ctx);
> + ctx.accum_err = mipi_dsi_dcs_set_display_off(dsi);
> + s6e3ha8_test_key_off_lvl1(&ctx);
> + msleep(20);
> +
> + s6e3ha8_test_key_on_lvl2(&ctx);
> + s6e3ha8_afc_off(&ctx);
> + s6e3ha8_test_key_off_lvl2(&ctx);
> +
> + msleep(160);
> +
> + return 0;
> +}
> +
> +static int s6e3ha8_amb577px01_wqhd_prepare(struct drm_panel *panel)
> +{
> + struct s6e3ha8 *priv = to_s6e3ha8_amb577px01_wqhd(panel);
> + struct mipi_dsi_device *dsi = priv->dsi;
> + struct device *dev = &dsi->dev;
> + struct mipi_dsi_multi_context ctx = { .dsi = dsi };
> + struct drm_dsc_picture_parameter_set pps;
> + int ret;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(priv->supplies), priv->supplies);
> + if (ret < 0)
> + return ret;
> + msleep(120);
> + s6e3ha8_amb577px01_wqhd_reset(priv);
empty line
> + ret = s6e3ha8_amb577px01_wqhd_on(priv);
> +
no empty line
> + if (ret < 0) {
> + dev_err(dev, "Failed to initialize panel: %d\n", ret);
_multi functions will say that for you already.
> + gpiod_set_value_cansleep(priv->reset_gpio, 1);
> + goto err;
> + }
> +
> + drm_dsc_pps_payload_pack(&pps, &priv->dsc);
> +
> + s6e3ha8_test_key_on_lvl1(&ctx);
> + ret = mipi_dsi_picture_parameter_set(priv->dsi, &pps);
Probably we should add _multi version here, could you please add it?
Otherwise you might have missed the fact that previous function has
failed.
> + if (ret < 0) {
> + dev_err(panel->dev, "failed to transmit PPS: %d\n", ret);
> + return ret;
> + }
> + s6e3ha8_test_key_off_lvl1(&ctx);
> +
> + msleep(28);
mipi_dsi_msleep
> +
> + return 0;
handle ctx.accum_err please.
> +err:
> + regulator_bulk_disable(ARRAY_SIZE(priv->supplies), priv->supplies);
> + return ret;
> +}
> +
> +static int s6e3ha8_amb577px01_wqhd_unprepare(struct drm_panel *panel)
> +{
> + struct s6e3ha8 *priv = to_s6e3ha8_amb577px01_wqhd(panel);
> +
> + return regulator_bulk_disable(ARRAY_SIZE(priv->supplies), priv->supplies);
> +}
> +
> +static const struct drm_display_mode s6e3ha8_amb577px01_wqhd_mode = {
> + .clock = (1440 + 116 + 44 + 120) * (2960 + 120 + 80 + 124) * 60 / 1000,
> + .hdisplay = 1440,
> + .hsync_start = 1440 + 116,
> + .hsync_end = 1440 + 116 + 44,
> + .htotal = 1440 + 116 + 44 + 120,
> + .vdisplay = 2960,
> + .vsync_start = 2960 + 120,
> + .vsync_end = 2960 + 120 + 80,
> + .vtotal = 2960 + 120 + 80 + 124,
> + .width_mm = 64,
> + .height_mm = 132,
> +};
> +
> +static int s6e3ha8_amb577px01_wqhd_get_modes(struct drm_panel *panel,
> + struct drm_connector *connector)
> +{
> + return drm_connector_helper_get_modes_fixed(connector, &s6e3ha8_amb577px01_wqhd_mode);
> +}
> +
> +static const struct drm_panel_funcs s6e3ha8_amb577px01_wqhd_panel_funcs = {
> + .prepare = s6e3ha8_amb577px01_wqhd_prepare,
> + .unprepare = s6e3ha8_amb577px01_wqhd_unprepare,
> + .get_modes = s6e3ha8_amb577px01_wqhd_get_modes,
> + .enable = s6e3ha8_enable,
> + .disable = s6e3ha8_disable,
> +};
> +
> +static int s6e3ha8_amb577px01_wqhd_probe(struct mipi_dsi_device *dsi)
> +{
> + struct device *dev = &dsi->dev;
> + struct s6e3ha8 *priv;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->supplies[0].supply = "vdd3";
> + priv->supplies[1].supply = "vci";
> + priv->supplies[2].supply = "vddr";
> +
> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(priv->supplies),
> + priv->supplies);
> + if (ret < 0) {
> + dev_err(dev, "failed to get regulators: %d\n", ret);
> + return ret;
> + }
> +
> + priv->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->reset_gpio))
> + return dev_err_probe(dev, PTR_ERR(priv->reset_gpio),
> + "Failed to get reset-gpios\n");
> +
> + priv->dsi = dsi;
> + mipi_dsi_set_drvdata(dsi, priv);
> +
> + dsi->lanes = 4;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS |
> + MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
> + MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
> +
> + drm_panel_init(&priv->panel, dev, &s6e3ha8_amb577px01_wqhd_panel_funcs,
> + DRM_MODE_CONNECTOR_DSI);
> + priv->panel.prepare_prev_first = true;
> +
> + drm_panel_add(&priv->panel);
> +
> + /* This panel only supports DSC; unconditionally enable it */
> + dsi->dsc = &priv->dsc;
> +
> + priv->dsc.dsc_version_major = 1;
> + priv->dsc.dsc_version_minor = 1;
> +
> + priv->dsc.slice_height = 40;
> + priv->dsc.slice_width = 720;
> + WARN_ON(1440 % priv->dsc.slice_width);
> + priv->dsc.slice_count = 1440 / priv->dsc.slice_width;
> + priv->dsc.bits_per_component = 8;
> + priv->dsc.bits_per_pixel = 8 << 4; /* 4 fractional bits */
> + priv->dsc.block_pred_enable = true;
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret < 0) {
> + dev_err(dev, "Failed to attach to DSI host: %d\n", ret);
> + drm_panel_remove(&priv->panel);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void s6e3ha8_amb577px01_wqhd_remove(struct mipi_dsi_device *dsi)
> +{
> + struct s6e3ha8 *priv = mipi_dsi_get_drvdata(dsi);
> + int ret;
> +
> + ret = mipi_dsi_detach(dsi);
> + if (ret < 0)
> + dev_err(&dsi->dev, "Failed to detach from DSI host: %d\n", ret);
> +
> + drm_panel_remove(&priv->panel);
> +}
> +
> +static const struct of_device_id s6e3ha8_amb577px01_wqhd_of_match[] = {
> + { .compatible = "samsung,s6e3ha8" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, s6e3ha8_amb577px01_wqhd_of_match);
> +
> +static struct mipi_dsi_driver s6e3ha8_amb577px01_wqhd_driver = {
> + .probe = s6e3ha8_amb577px01_wqhd_probe,
> + .remove = s6e3ha8_amb577px01_wqhd_remove,
> + .driver = {
> + .name = "panel-s6e3ha8",
> + .of_match_table = s6e3ha8_amb577px01_wqhd_of_match,
> + },
> +};
> +module_mipi_dsi_driver(s6e3ha8_amb577px01_wqhd_driver);
> +
> +MODULE_AUTHOR("Dzmitry Sankouski <dsankouski@gmail.com>");
> +MODULE_DESCRIPTION("DRM driver for S6E3HA8 panel");
> +MODULE_LICENSE("GPL");
>
> --
> 2.39.2
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/3] Drivers: hv: vmbus: Disable Suspend-to-Idle for VMBus
From: Erni Sri Satya Vennela @ 2024-09-21 19:09 UTC (permalink / raw)
To: Naman Jain
Cc: kys, haiyangz, wei.liu, decui, jikos, bentiss, dmitry.torokhov,
linux-hyperv, linux-input, linux-kernel, ernis, Saurabh Sengar
In-Reply-To: <b480a355-dbfa-4422-ad3c-65ec931a3ba0@linux.microsoft.com>
On Fri, Sep 13, 2024 at 12:49:27PM +0530, Naman Jain wrote:
>
>
> On 9/13/2024 2:57 AM, Erni Sri Satya Vennela wrote:
> >If the Virtual Machine Connection window is focused,
> >a Hyper-V VM user can unintentionally touch the keyboard/mouse
> >when the VM is hibernating or resuming, and consequently the
> >hibernation or resume operation can be aborted unexpectedly.
> >Fix the issue by no longer registering the keyboard/mouse as
> >wakeup devices (see the other two patches for the
> >changes to drivers/input/serio/hyperv-keyboard.c and
> >drivers/hid/hid-hyperv.c).
> >
> >The keyboard/mouse were registered as wakeup devices because the
> >VM needs to be woken up from the Suspend-to-Idle state after
> >a user runs "echo freeze > /sys/power/state". It seems like
> >the Suspend-to-Idle feature has no real users in practice, so
> >let's no longer support that by returning -EOPNOTSUPP if a
> >user tries to use that.
> >
>
> Maybe it would be good to capture here the kind of VMs that this is
> going to be not supported - HyperV based VMs. You mentioned it in cover
> letter, but it would be good to add it here as well, as cover letter
> does not go to git log.
>
Sure, I'll specify this in the next version of the patch.
> Also, the subject suggests that we are disabling suspend-to-idle for
> vmbus specifically, but from commit description, it suggests that
> "suspend to idle" feature itself is no longer supported on these
> particular VMs. Please rephrase it based on what exactly we are trying
> to do here. IIUC, we are now returning an error (EOPNOTSUPP) in vmbus
> driver callback, which insures that we don't support Suspend-to-Idle in
> these VMs.
>
Yes, that's correct.
> >Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
> >Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
> >---
> > drivers/hv/vmbus_drv.c | 15 ++++++++++++++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> >index 965d2a4efb7e..4efd8856392f 100644
> >--- a/drivers/hv/vmbus_drv.c
> >+++ b/drivers/hv/vmbus_drv.c
> >@@ -900,6 +900,19 @@ static void vmbus_shutdown(struct device *child_device)
> > }
> > #ifdef CONFIG_PM_SLEEP
> >+/*
> >+ * vmbus_freeze - Suspend-to-Idle
> >+ */
> >+static int vmbus_freeze(struct device *child_device)
> >+{
> >+/*
> >+ * Do not support Suspend-to-Idle ("echo freeze > /sys/power/state") as
> >+ * that would require registering the Hyper-V synthetic mouse/keyboard
> >+ * devices as wakeup devices, which can abort hibernation/resume unexpectedly.
> >+ */
> >+ return -EOPNOTSUPP;
> >+}
> >+
> > /*
> > * vmbus_suspend - Suspend a vmbus device
> > */
> >@@ -969,7 +982,7 @@ static void vmbus_device_release(struct device *device)
> > */
> > static const struct dev_pm_ops vmbus_pm = {
> >- .suspend_noirq = NULL,
> >+ .suspend_noirq = vmbus_freeze,
> > .resume_noirq = NULL,
> > .freeze_noirq = vmbus_suspend,
>
> I am not sure if this is OK or how it works, but this naming scheme
> seems a bit confusing to me -
> *suspend* -> vmbus_*freeze*
> *freeze* -> vmbus_*suspend*
> and we are removing support for "freeze" by returning EOPNOTSUPP in
> suspend callback.
AFAIU, suspend_noirq is used for Suspend-to-Idle operation and we use
"freeze > /sys/power/state" for the same. Maybe the naming convention
comes that way.
The key point to understand here is suspend_noirq prepares the machine
to low power state and freeze_noirq prepares the machine for hibernation
(saving state to disk).
>
> I'll try to understand more on this, but just see if its OK.
>
> > .thaw_noirq = vmbus_resume,
>
> Regards,
> Naman
Yes, thaw_noirq is to restore devices from hibernation state.
^ permalink raw reply
* [PATCH] Input: ims-pcu - fix a mutex usage error
From: Donglin Peng @ 2024-09-21 7:15 UTC (permalink / raw)
To: dmitry.torokhov
Cc: javier.carrasco.cruz, kees, linux-input, linux-kernel,
Donglin Peng
The mutex_lock_interruptible should be switched to scoped_cond_guard(mutex_intr, ...)
instead of scoped_cond_guard(mutex, ..).
Fixes: 703f12672e1f ("Input: ims-pcu - switch to using cleanup functions")
Signed-off-by: Donglin Peng <dolinux.peng@gmail.com>
---
drivers/input/misc/ims-pcu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
index c086dadb45e3..058f3470b7ae 100644
--- a/drivers/input/misc/ims-pcu.c
+++ b/drivers/input/misc/ims-pcu.c
@@ -1067,7 +1067,7 @@ static ssize_t ims_pcu_attribute_store(struct device *dev,
if (data_len > attr->field_length)
return -EINVAL;
- scoped_cond_guard(mutex, return -EINTR, &pcu->cmd_mutex) {
+ scoped_cond_guard(mutex_intr, return -EINTR, &pcu->cmd_mutex) {
memset(field, 0, attr->field_length);
memcpy(field, buf, data_len);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] hid: hid-lenovo: Supporting TP-X12-TAB-1/2 Kbd Hotkeys using raw events.
From: kernel test robot @ 2024-09-21 6:18 UTC (permalink / raw)
To: Vishnu Sankar, jikos, bentiss, linux-input, linux-kernel
Cc: oe-kbuild-all, mpearson-lenovo, vsankar, Vishnu Sankar
In-Reply-To: <20240917100432.10887-1-vishnuocv@gmail.com>
Hi Vishnu,
kernel test robot noticed the following build errors:
[auto build test ERROR on hid/for-next]
[also build test ERROR on linus/master next-20240920]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Vishnu-Sankar/hid-hid-lenovo-Supporting-TP-X12-TAB-1-2-Kbd-Hotkeys-using-raw-events/20240917-180639
base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link: https://lore.kernel.org/r/20240917100432.10887-1-vishnuocv%40gmail.com
patch subject: [PATCH] hid: hid-lenovo: Supporting TP-X12-TAB-1/2 Kbd Hotkeys using raw events.
config: i386-randconfig-062-20240921 (https://download.01.org/0day-ci/archive/20240921/202409211318.ZsE7JGOi-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240921/202409211318.ZsE7JGOi-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202409211318.ZsE7JGOi-lkp@intel.com/
All errors (new ones prefixed by >>, old ones prefixed by <<):
WARNING: modpost: missing MODULE_DESCRIPTION() in kernel/locking/test-ww_mutex.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_powersave.o
>> ERROR: modpost: "platform_profile_cycle" [drivers/hid/hid-lenovo.ko] undefined!
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS eb017f4ea13b1a5ad7f4332279f2e4c67b44bdea
From: kernel test robot @ 2024-09-21 1:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: eb017f4ea13b1a5ad7f4332279f2e4c67b44bdea Input: adp5588-keys - fix check on return code
elapsed time: 956m
configs tested: 134
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-14.1.0
alpha allyesconfig clang-20
alpha defconfig gcc-14.1.0
arc allmodconfig clang-20
arc allnoconfig gcc-14.1.0
arc allyesconfig clang-20
arc defconfig gcc-14.1.0
arc tb10x_defconfig gcc-14.1.0
arm allmodconfig clang-20
arm allnoconfig gcc-14.1.0
arm allyesconfig clang-20
arm assabet_defconfig gcc-14.1.0
arm defconfig gcc-14.1.0
arm multi_v7_defconfig gcc-14.1.0
arm64 allmodconfig clang-20
arm64 allnoconfig gcc-14.1.0
arm64 defconfig gcc-14.1.0
csky allnoconfig gcc-14.1.0
csky defconfig gcc-14.1.0
hexagon allmodconfig clang-20
hexagon allnoconfig gcc-14.1.0
hexagon allyesconfig clang-20
hexagon defconfig gcc-14.1.0
i386 allmodconfig clang-18
i386 allnoconfig clang-18
i386 allyesconfig clang-18
i386 buildonly-randconfig-001-20240921 clang-18
i386 buildonly-randconfig-002-20240921 clang-18
i386 buildonly-randconfig-003-20240921 clang-18
i386 buildonly-randconfig-004-20240921 clang-18
i386 buildonly-randconfig-005-20240921 clang-18
i386 buildonly-randconfig-006-20240921 clang-18
i386 defconfig clang-18
i386 randconfig-001-20240921 clang-18
i386 randconfig-002-20240921 clang-18
i386 randconfig-003-20240921 clang-18
i386 randconfig-004-20240921 clang-18
i386 randconfig-005-20240921 clang-18
i386 randconfig-006-20240921 clang-18
i386 randconfig-011-20240921 clang-18
i386 randconfig-012-20240921 clang-18
i386 randconfig-013-20240921 clang-18
i386 randconfig-014-20240921 clang-18
i386 randconfig-015-20240921 clang-18
i386 randconfig-016-20240921 clang-18
loongarch allmodconfig gcc-14.1.0
loongarch allnoconfig gcc-14.1.0
loongarch defconfig gcc-14.1.0
m68k allmodconfig gcc-14.1.0
m68k allnoconfig gcc-14.1.0
m68k allyesconfig gcc-14.1.0
m68k defconfig gcc-14.1.0
m68k m5275evb_defconfig gcc-14.1.0
m68k m5475evb_defconfig gcc-14.1.0
microblaze allmodconfig gcc-14.1.0
microblaze allnoconfig gcc-14.1.0
microblaze allyesconfig gcc-14.1.0
microblaze defconfig gcc-14.1.0
mips allnoconfig gcc-14.1.0
mips ip28_defconfig gcc-14.1.0
nios2 allnoconfig gcc-14.1.0
nios2 defconfig gcc-14.1.0
openrisc allnoconfig clang-20
openrisc allyesconfig gcc-14.1.0
openrisc defconfig gcc-12
parisc allmodconfig gcc-14.1.0
parisc allnoconfig clang-20
parisc allyesconfig gcc-14.1.0
parisc defconfig gcc-12
parisc64 defconfig gcc-14.1.0
powerpc allmodconfig gcc-14.1.0
powerpc allnoconfig clang-20
powerpc allyesconfig gcc-14.1.0
powerpc arches_defconfig gcc-14.1.0
powerpc currituck_defconfig gcc-14.1.0
powerpc ppc6xx_defconfig gcc-14.1.0
powerpc storcenter_defconfig gcc-14.1.0
powerpc64 alldefconfig gcc-14.1.0
riscv allmodconfig gcc-14.1.0
riscv allnoconfig clang-20
riscv allyesconfig gcc-14.1.0
riscv defconfig gcc-12
s390 allmodconfig gcc-14.1.0
s390 allnoconfig clang-20
s390 allyesconfig gcc-14.1.0
s390 defconfig gcc-12
sh allmodconfig gcc-14.1.0
sh allnoconfig gcc-14.1.0
sh allyesconfig gcc-14.1.0
sh defconfig gcc-12
sh r7780mp_defconfig gcc-14.1.0
sh sh7724_generic_defconfig gcc-14.1.0
sh titan_defconfig gcc-14.1.0
sparc allmodconfig gcc-14.1.0
sparc64 defconfig gcc-12
um allmodconfig clang-20
um allnoconfig clang-20
um allyesconfig clang-20
um defconfig gcc-12
um i386_defconfig gcc-12
um x86_64_defconfig gcc-12
x86_64 allnoconfig clang-18
x86_64 allyesconfig clang-18
x86_64 buildonly-randconfig-001-20240921 clang-18
x86_64 buildonly-randconfig-002-20240921 clang-18
x86_64 buildonly-randconfig-003-20240921 clang-18
x86_64 buildonly-randconfig-004-20240921 clang-18
x86_64 buildonly-randconfig-005-20240921 clang-18
x86_64 buildonly-randconfig-006-20240921 clang-18
x86_64 defconfig clang-18
x86_64 kexec clang-18
x86_64 kexec gcc-12
x86_64 randconfig-001-20240921 clang-18
x86_64 randconfig-002-20240921 clang-18
x86_64 randconfig-003-20240921 clang-18
x86_64 randconfig-004-20240921 clang-18
x86_64 randconfig-005-20240921 clang-18
x86_64 randconfig-006-20240921 clang-18
x86_64 randconfig-011-20240921 clang-18
x86_64 randconfig-012-20240921 clang-18
x86_64 randconfig-013-20240921 clang-18
x86_64 randconfig-014-20240921 clang-18
x86_64 randconfig-015-20240921 clang-18
x86_64 randconfig-016-20240921 clang-18
x86_64 randconfig-071-20240921 clang-18
x86_64 randconfig-072-20240921 clang-18
x86_64 randconfig-073-20240921 clang-18
x86_64 randconfig-074-20240921 clang-18
x86_64 randconfig-075-20240921 clang-18
x86_64 randconfig-076-20240921 clang-18
x86_64 rhel-8.3 gcc-12
x86_64 rhel-8.3-rust clang-18
xtensa allnoconfig gcc-14.1.0
xtensa audio_kc705_defconfig gcc-14.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v27 01/32] xhci: add helper to stop endpoint and wait for completion
From: Wesley Cheng @ 2024-09-20 23:49 UTC (permalink / raw)
To: Michał Pecio
Cc: mathias.nyman, Thinh.Nguyen, alsa-devel, bgoswami, broonie,
conor+dt, corbet, devicetree, dmitry.torokhov, gregkh, krzk+dt,
lgirdwood, linux-arm-msm, linux-doc, linux-input, linux-kernel,
linux-sound, linux-usb, mathias.nyman, perex,
pierre-louis.bossart, robh, srinivas.kandagatla, tiwai
In-Reply-To: <20240915095514.6b01fefb@foxbook>
Hi Michal,
On 9/15/2024 12:55 AM, Michał Pecio wrote:
> Hi,
>
>> Maybe the last sentence is not needed. When we are using the
>> secondary interrupters, at least in the offload use case that I've
>> verified with, the XHCI is completely unaware of what TDs have been
>> queued, etc... So technically, even if we did call the default
>> handler (ie xhci_handle_cmd_stop_ep), most of the routines to
>> invalidate TDs are going to be no-ops.
> Yes, the cancellation machinery will return immediately if there are
> no TDs queued by xhci_hcd itself.
>
> But xhci_handle_cmd_stop_ep() does a few more things for you - it
> checks if the command has actually succeeded, clears any halt condition
> which may be preventing stopping the endpoint, and it sometimes retries
> the command (only on "bad" chips, AFAIK).
>
> This new code does none of the above, so in the general case it can't
> even guarantee that the endpoint is stopped when it returns zero. This
> should ideally be documented in some way, or fixed, before somebody is
> tempted to call it with unrealistically high expectations ;)
>
> As far as I see, it only works for you because isochronous never halts
> and Qualcomm HW is (hopefully) free of those stop-after-restart bugs.
> There will be problems if the SB tries to use any other endpoint type.
So what I ended up doing was to split off the context error handling into a separate helper API, which can be also called for the sync ep stop API. From there, based on say....the helper re queuing the stop EP command, it would return a specific value to signify that it has done so. The sync based API will then re-wait for the completion of the subsequent stop endpoint command that was queued. In all other context error cases, it'd return the error to the caller, and its up to them to handle it accordingly.
Thanks
Wesley Cheng
^ permalink raw reply
* Re: [PATCH] hid: hid-lenovo: Supporting TP-X12-TAB-1/2 Kbd Hotkeys using raw events.
From: kernel test robot @ 2024-09-20 23:08 UTC (permalink / raw)
To: Vishnu Sankar, jikos, bentiss, linux-input, linux-kernel
Cc: oe-kbuild-all, mpearson-lenovo, vsankar, Vishnu Sankar
In-Reply-To: <20240917100432.10887-1-vishnuocv@gmail.com>
Hi Vishnu,
kernel test robot noticed the following build errors:
[auto build test ERROR on hid/for-next]
[also build test ERROR on linus/master next-20240920]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Vishnu-Sankar/hid-hid-lenovo-Supporting-TP-X12-TAB-1-2-Kbd-Hotkeys-using-raw-events/20240917-180639
base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link: https://lore.kernel.org/r/20240917100432.10887-1-vishnuocv%40gmail.com
patch subject: [PATCH] hid: hid-lenovo: Supporting TP-X12-TAB-1/2 Kbd Hotkeys using raw events.
config: parisc-randconfig-r062-20240921 (https://download.01.org/0day-ci/archive/20240921/202409210619.eaTT5ACU-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 14.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240921/202409210619.eaTT5ACU-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202409210619.eaTT5ACU-lkp@intel.com/
All errors (new ones prefixed by >>):
hppa-linux-ld: drivers/hid/hid-lenovo.o: in function `lenovo_raw_event':
>> hid-lenovo.c:(.text+0x1958): undefined reference to `platform_profile_cycle'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] Input: hynitron_cstxxx - Drop explicit initialization of struct i2c_device_id::driver_data to 0
From: Uwe Kleine-König @ 2024-09-20 15:34 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
drivers/input/touchscreen/hynitron_cstxxx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/hynitron_cstxxx.c b/drivers/input/touchscreen/hynitron_cstxxx.c
index 05946fee4fd4..f72834859282 100644
--- a/drivers/input/touchscreen/hynitron_cstxxx.c
+++ b/drivers/input/touchscreen/hynitron_cstxxx.c
@@ -470,7 +470,7 @@ static const struct hynitron_ts_chip_data cst3xx_data = {
};
static const struct i2c_device_id hyn_tpd_id[] = {
- { .name = "hynitron_ts", 0 },
+ { .name = "hynitron_ts" },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(i2c, hyn_tpd_id);
base-commit: 62f92d634458a1e308bb699986b9147a6d670457
--
2.45.2
^ permalink raw reply related
* [PATCH] HID: i2c-hid-of: Drop explicit initialization of struct i2c_device_id::driver_data to 0
From: Uwe Kleine-König @ 2024-09-20 15:34 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Johan Hovold, Douglas Anderson, linux-input
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
While touching the initializer, also remove the comma after the sentinel
entry.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
drivers/hid/i2c-hid/i2c-hid-of.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-of.c b/drivers/hid/i2c-hid/i2c-hid-of.c
index 8be4d576da77..57379b77e977 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of.c
@@ -144,9 +144,9 @@ MODULE_DEVICE_TABLE(of, i2c_hid_of_match);
#endif
static const struct i2c_device_id i2c_hid_of_id_table[] = {
- { "hid", 0 },
- { "hid-over-i2c", 0 },
- { },
+ { "hid" },
+ { "hid-over-i2c" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, i2c_hid_of_id_table);
base-commit: 62f92d634458a1e308bb699986b9147a6d670457
--
2.45.2
^ permalink raw reply related
* [PATCH] docs: fix spelling and grammar mistakes
From: SurajSonawane2415 @ 2024-09-20 15:07 UTC (permalink / raw)
To: jikos, bentiss, corbet, linux-usb, linux-input, linux-doc,
linux-kernel
Cc: SurajSonawane2415
Fix grammatical and spelling errors in the HID documentation files.
Signed-off-by: SurajSonawane2415 <surajsonawane0215@gmail.com>
---
Documentation/hid/hiddev.rst | 4 ++--
Documentation/hid/intel-ish-hid.rst | 2 +-
Documentation/hid/uhid.rst | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
index 9b82c7f89..073485f84 100644
--- a/Documentation/hid/hiddev.rst
+++ b/Documentation/hid/hiddev.rst
@@ -15,10 +15,10 @@ To support these disparate requirements, the Linux USB system provides
HID events to two separate interfaces:
* the input subsystem, which converts HID events into normal input
device interfaces (such as keyboard, mouse and joystick) and a
-normalised event interface - see Documentation/input/input.rst
+normalized event interface - see Documentation/input/input.rst
* the hiddev interface, which provides fairly raw HID events
-The data flow for a HID event produced by a device is something like
+The data flow for an HID event produced by a device is something like
the following::
usb.c ---> hid-core.c ----> hid-input.c ----> [keyboard/mouse/joystick/event]
diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst
index 2adc174fb..fdabf6ec6 100644
--- a/Documentation/hid/intel-ish-hid.rst
+++ b/Documentation/hid/intel-ish-hid.rst
@@ -21,7 +21,7 @@ mainly use HID over I2C or USB. But ISH doesn't use either I2C or USB.
Overview
========
-Using a analogy with a usbhid implementation, the ISH follows a similar model
+Using an analogy with a usbhid implementation, the ISH follows a similar model
for a very high speed communication::
----------------- ----------------------
diff --git a/Documentation/hid/uhid.rst b/Documentation/hid/uhid.rst
index 2243a6b75..2681038cd 100644
--- a/Documentation/hid/uhid.rst
+++ b/Documentation/hid/uhid.rst
@@ -106,7 +106,7 @@ UHID_INPUT2:
UHID_GET_REPORT_REPLY:
If you receive a UHID_GET_REPORT request you must answer with this request.
- You must copy the "id" field from the request into the answer. Set the "err"
+ You must copy the "id" field from the request into the answer. Set the "err"
field to 0 if no error occurred or to EIO if an I/O error occurred.
If "err" is 0 then you should fill the buffer of the answer with the results
of the GET_REPORT request and set "size" correspondingly.
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v6 2/2] dt-bindings: mfd: mediatek: mt6397: Convert to DT schema format
From: Alexandre Belloni @ 2024-09-20 13:37 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Macpaul Lin, Andrew Lunn, Florian Fainelli, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Liam Girdwood, Mark Brown, Sean Wang, Sen Chu, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Dmitry Torokhov,
Pavel Machek, Lee Jones, Sebastian Reichel, Chen Zhong,
linux-input, linux-leds, linux-pm, linux-rtc, linux-sound,
Alexandre Mergnat, Bear Wang, Pablo Sun, Macpaul Lin,
Chris-qj chen, MediaTek Chromebook Upstream, Chen-Yu Tsai
In-Reply-To: <d8b90ddf-efbc-4434-9ad0-4be6942d51a5@collabora.com>
On 20/09/2024 09:31:24+0200, AngeloGioacchino Del Regno wrote:
> Il 18/09/24 16:18, Macpaul Lin ha scritto:
> >
> > On 9/18/24 19:56, Alexandre Belloni wrote:
> > >
> > > On 18/09/2024 13:51:51+0200, Alexandre Belloni wrote:
> > > > > Changes for v4:
> > > > > - Remove "mediatek,mt6357" from PMIC's compatible string since there is a
> > > > > seperated DT schema for PMIC mt6357.
> > > > > > Changes for v5:
> > > > > - Rebase to next-20240913 (linux-next/master).
> > > > > - Fix the "title" (device type) of mfd/mediatek,mt6397.yaml to "PMIC".
> > > > > - RTC:
> > > > > - Drop "start-year"
> > > >
> > > > Maybe, instead of dropping the property, you should add support in the
> > > > driver by setting range_min and range_max.
> > >
> > > Looking at this even more, the driver can probably be simplified by
> > > setting start_year in probe and dropping RTC_MIN_YEAR_OFFSET.
> >
> > Thank you for pointing out where and how the driver should be changed.
> > However, I'm wondering if this should be a fix with a separated
> > patchset (bindings and the driver)? The board or SoC's device trees
> > should be reviewed as well. I'll need to get someone's help (permission)
> > inside MediaTek to check those dts and construct the patch for RTC
> > driver.
> > That will take sometime.
> >
>
> Alexandre, I definitely agree with you on the fact that the MTK PMIC RTC driver
> can (and needs to) be improved, and that it can make use of some nice cleanup...
>
> ... but!
>
> This series performs a conversion to schema, and the previous txt file didn't
> say anything about the start-year property - which was not mandatory to support
> at that time (nor now, afaik?), so adding support for that is out of scope for
> this series.
It is mandatory now. I agree this can be done in a subsequent series.
>
> Eventually, that can come as a series on top, adding support for that in the
> binding (and, of course, in the driver).
>
> I should be able to tackle that... most probably next week - but still, the
> improvements would come as a series on top of this one.
>
> Cheers,
> Angelo
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v6 2/2] dt-bindings: mfd: mediatek: mt6397: Convert to DT schema format
From: Krzysztof Kozlowski @ 2024-09-20 13:07 UTC (permalink / raw)
To: Macpaul Lin, Andrew Lunn, Florian Fainelli, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Mark Brown, Sean Wang,
Sen Chu, netdev, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Dmitry Torokhov, Pavel Machek, Lee Jones,
Sebastian Reichel, Alexandre Belloni, Chen Zhong, linux-input,
linux-leds, linux-pm, linux-rtc, linux-sound, Alexandre Mergnat
Cc: Bear Wang, Pablo Sun, Macpaul Lin, Chris-qj chen,
MediaTek Chromebook Upstream, Chen-Yu Tsai
In-Reply-To: <20240918064955.6518-2-macpaul.lin@mediatek.com>
On 18/09/2024 08:49, Macpaul Lin wrote:
> Convert the mfd: mediatek: mt6397 binding to DT schema format.
>
> MT6323, MT6358, and MT6397 are PMIC devices with multiple function
> subdevices. They share a common PMIC design but have variations in
> subdevice combinations.
>
> Key updates in this conversion:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/2] regulator: dt-bindings: mt6323: Convert to DT schema
From: Mark Brown @ 2024-09-20 12:08 UTC (permalink / raw)
To: Macpaul Lin
Cc: Andrew Lunn, Florian Fainelli, Vladimir Oltean, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Sean Wang, Sen Chu,
netdev, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Dmitry Torokhov, Pavel Machek, Lee Jones,
Sebastian Reichel, Alexandre Belloni, Chen Zhong, linux-input,
linux-leds, linux-pm, linux-rtc, linux-sound, Alexandre Mergnat,
Bear Wang, Pablo Sun, Macpaul Lin, Chris-qj chen,
MediaTek Chromebook Upstream, Chen-Yu Tsai
In-Reply-To: <20240918064955.6518-1-macpaul.lin@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
On Wed, Sep 18, 2024 at 02:49:54PM +0800, Macpaul Lin wrote:
> Convert the MT6323 regulator binding from the old text-based format to
> the new DT schema style. The property "regulator-name" has been added
> as required property to reflect current usage in mt6323.dtsi.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] Input: adp5588-keys: fix check on return code
From: Nuno Sá @ 2024-09-20 11:07 UTC (permalink / raw)
To: Dmitry Torokhov, nuno.sa; +Cc: Andy Shevchenko, linux-input, Michael Hennerich
In-Reply-To: <Zu0vq0ogr2HzXWv7@google.com>
On Fri, 2024-09-20 at 08:17 +0000, Dmitry Torokhov wrote:
> On Fri, Sep 20, 2024 at 09:22:52AM +0200, Nuno Sa via B4 Relay wrote:
> > From: Nuno Sa <nuno.sa@analog.com>
> >
> > During adp5588_setup(), we read all the events to clear the event FIFO.
> > However, adp5588_read() just calls i2c_smbus_read_byte_data() which
> > returns the byte read in case everything goes well. Hence, we need to
> > explicitly check for a negative error code instead of checking for
> > something different than 0.
> >
> > Fixes: e960309ce318 ("Input: adp5588-keys - bail out on returned error")
> > Signed-off-by: Nuno Sa <nuno.sa@analog.com>
> > ---
> > drivers/input/keyboard/adp5588-keys.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/keyboard/adp5588-keys.c
> > b/drivers/input/keyboard/adp5588-keys.c
> > index b5f4becf5cb6f..d25d63a807f23 100644
> > --- a/drivers/input/keyboard/adp5588-keys.c
> > +++ b/drivers/input/keyboard/adp5588-keys.c
> > @@ -620,7 +620,7 @@ static int adp5588_setup(struct adp5588_kpad *kpad)
> >
> > for (i = 0; i < KEYP_MAX_EVENT; i++) {
> > ret = adp5588_read(client, KEY_EVENTA);
> > - if (ret)
> > + if (ret < 0)
> > return ret;
> > }
>
> Hmm... There are a bunch of places where we do not check result of
> adp5588_read(). I wonder if we should:
>
> 1. add the checks
> 2. change it to return error or 0 and return the value through a pointer
> argument.
It does make sense. I can take care of that.
And similar work will be needed in the adp5589 driver. I'll include it in the series
I'm preparing for the FW properties.
- Nuno Sá
^ 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