* Re: [PATCH v2 00/19] backlight: Constify lcd_ops
From: Lee Jones @ 2024-05-03 9:43 UTC (permalink / raw)
To: Daniel Thompson, Jingoo Han, Helge Deller, Bruno Prémont,
Jiri Kosina, Benjamin Tissoires, Alexander Shiyan, Sascha Hauer,
Pengutronix Kernel Team, Shawn Guo, Fabio Estevam,
Krzysztof Kozlowski
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Thomas Zimmermann,
Thomas Weißschuh
In-Reply-To: <171472928415.1323021.3458121588308140519.b4-ty@kernel.org>
On Fri, 03 May 2024, Lee Jones wrote:
> On Wed, 24 Apr 2024 08:33:26 +0200, Krzysztof Kozlowski wrote:
> > Changes in v2:
> > - Collect tags, including wrongly places Thomas' tag (which requires me
> > to manually edit 15 other patches to drop it).
> > - Combine here checkpatch patch:
> > https://lore.kernel.org/all/20240414185440.288812-1-krzk@kernel.org/
> > - Link to v1: https://lore.kernel.org/r/20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org
> >
> > [...]
>
> Applied, thanks!
>
> [01/19] backlight: Constify lcd_ops
> commit: 9258e31adebf0ccf0797867841f3f9800695dba2
> [02/19] backlight: ams369fg06: Constify lcd_ops
> commit: 8053c4fa200c3fef07859bac9469ad3f26f5aba1
> [03/19] backlight: corgi_lcd: Constify lcd_ops
> commit: 18c5d4ab9f6312f2c9c6c409287d552112db810a
> [04/19] backlight: hx8357: Constify lcd_ops
> commit: 1d669c1998b559393ec2eaac0449f4989a255049
> [05/19] backlight: ili922x: Constify lcd_ops
> commit: e77fef89de954b1557cb91b64696cd4fc06c80ad
> [06/19] backlight: ili9320: Constify lcd_ops
> commit: 06cfc92faa1eabb2ea226c58d6fd0b5ab117ee39
> [07/19] backlight: jornada720_lcd: Constify lcd_ops
> commit: a54b4999dc204bc5839bb70602078c7c8e4a5010
> [08/19] backlight: l4f00242t03: Constify lcd_ops
> commit: 657e6c1b270e9f4a890059f5d08a08ea842fa1a8
> [09/19] backlight: lms283gf05: Constify lcd_ops
> commit: 66e5a10818fd332e973d36429e36f4c436a86a91
> [10/19] backlight: lms501kf03: Constify lcd_ops
> commit: 31c205d1e8426dd0cce0143c500ff1ff71fe64d1
> [11/19] backlight: ltv350qv: Constify lcd_ops
> commit: 24424f84d7568d9d794657622e080b1cba1e9290
> [12/19] backlight: otm3225a: Constify lcd_ops
> commit: 02949072ee8fb6141cd8ac2be9867ef466580ddb
> [13/19] backlight: platform_lcd: Constify lcd_ops
> commit: d217a8d5a39851caa16996756682715c9debb4a9
> [14/19] backlight: tdo24m: Constify lcd_ops
> commit: c7a1809d1982f671e66a4b1c1ffd8bdd5ba260aa
> [15/19] HID: picoLCD: Constify lcd_ops
> commit: 238724635763e7c5d82c0581b0c49e5dfdd5505a
> [16/19] fbdev: clps711x: Constify lcd_ops
> commit: 55d9a955375af3b3fd5725a9b5cbc658d4bdd244
> [17/19] fbdev: imx: Constify lcd_ops
> commit: a6abbb5783345c4c7cc9fbd583b81e167bd0207d
> [18/19] fbdev: omap: lcd_ams_delta: Constify lcd_ops
> commit: ca991e8e096c9f0cff0300289e2d4813192b8ef3
> [19/19] const_structs.checkpatch: add lcd_ops
> commit: f02aeccbec6108d768f54d31e7cb48b06c0e3814
Please ensure you use checkpatch.pl before submitting:
====
ERROR: Does not appear to be a unified-diff format patch
total: 1 errors, 0 warnings, 0 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
"[PATCH v2 19/19] const_structs.checkpatch: add lcd_ops" has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
WARNING: Missing commit description - Add an appropriate one
ERROR: Missing Signed-off-by: line(s)
total: 1 errors, 1 warnings, 7 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
Your patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
====
Some of them are a little odd. I fixed the relevant ones
Submitted for build testing.
If successful, I'll submit a PR for the other maintainers soon.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 00/19] backlight: Constify lcd_ops
From: Lee Jones @ 2024-05-03 9:41 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam, Krzysztof Kozlowski
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Thomas Zimmermann,
Thomas Weißschuh
In-Reply-To: <20240424-video-backlight-lcd-ops-v2-0-1aaa82b07bc6@kernel.org>
On Wed, 24 Apr 2024 08:33:26 +0200, Krzysztof Kozlowski wrote:
> Changes in v2:
> - Collect tags, including wrongly places Thomas' tag (which requires me
> to manually edit 15 other patches to drop it).
> - Combine here checkpatch patch:
> https://lore.kernel.org/all/20240414185440.288812-1-krzk@kernel.org/
> - Link to v1: https://lore.kernel.org/r/20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org
>
> [...]
Applied, thanks!
[01/19] backlight: Constify lcd_ops
commit: 9258e31adebf0ccf0797867841f3f9800695dba2
[02/19] backlight: ams369fg06: Constify lcd_ops
commit: 8053c4fa200c3fef07859bac9469ad3f26f5aba1
[03/19] backlight: corgi_lcd: Constify lcd_ops
commit: 18c5d4ab9f6312f2c9c6c409287d552112db810a
[04/19] backlight: hx8357: Constify lcd_ops
commit: 1d669c1998b559393ec2eaac0449f4989a255049
[05/19] backlight: ili922x: Constify lcd_ops
commit: e77fef89de954b1557cb91b64696cd4fc06c80ad
[06/19] backlight: ili9320: Constify lcd_ops
commit: 06cfc92faa1eabb2ea226c58d6fd0b5ab117ee39
[07/19] backlight: jornada720_lcd: Constify lcd_ops
commit: a54b4999dc204bc5839bb70602078c7c8e4a5010
[08/19] backlight: l4f00242t03: Constify lcd_ops
commit: 657e6c1b270e9f4a890059f5d08a08ea842fa1a8
[09/19] backlight: lms283gf05: Constify lcd_ops
commit: 66e5a10818fd332e973d36429e36f4c436a86a91
[10/19] backlight: lms501kf03: Constify lcd_ops
commit: 31c205d1e8426dd0cce0143c500ff1ff71fe64d1
[11/19] backlight: ltv350qv: Constify lcd_ops
commit: 24424f84d7568d9d794657622e080b1cba1e9290
[12/19] backlight: otm3225a: Constify lcd_ops
commit: 02949072ee8fb6141cd8ac2be9867ef466580ddb
[13/19] backlight: platform_lcd: Constify lcd_ops
commit: d217a8d5a39851caa16996756682715c9debb4a9
[14/19] backlight: tdo24m: Constify lcd_ops
commit: c7a1809d1982f671e66a4b1c1ffd8bdd5ba260aa
[15/19] HID: picoLCD: Constify lcd_ops
commit: 238724635763e7c5d82c0581b0c49e5dfdd5505a
[16/19] fbdev: clps711x: Constify lcd_ops
commit: 55d9a955375af3b3fd5725a9b5cbc658d4bdd244
[17/19] fbdev: imx: Constify lcd_ops
commit: a6abbb5783345c4c7cc9fbd583b81e167bd0207d
[18/19] fbdev: omap: lcd_ams_delta: Constify lcd_ops
commit: ca991e8e096c9f0cff0300289e2d4813192b8ef3
[19/19] const_structs.checkpatch: add lcd_ops
commit: f02aeccbec6108d768f54d31e7cb48b06c0e3814
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: HID: i2c-hid: elan: add 'no-reset-on-power-off' property
From: Johan Hovold @ 2024-05-03 9:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Johan Hovold, Jiri Kosina, Benjamin Tissoires, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Linus Walleij, Douglas Anderson, linux-input,
devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <48ec0bb5-a06e-4f18-97c3-1370b7facea4@kernel.org>
On Fri, May 03, 2024 at 11:11:16AM +0200, Krzysztof Kozlowski wrote:
> On 02/05/2024 11:56, Johan Hovold wrote:
> > On Thu, Apr 25, 2024 at 11:39:24AM +0200, Krzysztof Kozlowski wrote:
> >> It seems it is common problem. LEDs have property
> >> "retain-state-shutdown", to indicate that during system shutdown we
> >> should not touch them (like power off). Would some variant be applicable
> >> here? First, do we talk here about power off like system shutdown or
> >> runtime PM, thus suspend?
> >
> > A name like 'retain-state-shutdown' would also be too specific as what
> > I'm describing here is that the reset line should be (or can be) left
> > deasserted whenever the OS wants to power off the device.
>
> I don't think it is more specific than yours. It is actually more
> generic. First, shutdown=poweroff, so that part is the same.
My point is that 'shutdown' is a specific OS concept (i.e. turning the
whole system off), while powering off a *device* can be done for a
number of reasons including closing a character device, suspend and
system-wide shutdown.
The policy decision of when to power off a device is left up to kernel
(e.g. if a device needs to be kept on as it is currently configured as a
wakeup device).
Johan
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: HID: i2c-hid: elan: add 'no-reset-on-power-off' property
From: Krzysztof Kozlowski @ 2024-05-03 9:11 UTC (permalink / raw)
To: Johan Hovold
Cc: Johan Hovold, Jiri Kosina, Benjamin Tissoires, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Linus Walleij, Douglas Anderson, linux-input,
devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <ZjNjMBNMegmTgN5B@hovoldconsulting.com>
On 02/05/2024 11:56, Johan Hovold wrote:
> Hi Krzysztof,
>
> and sorry about the late reply. Got side-tracked.
>
> On Thu, Apr 25, 2024 at 11:39:24AM +0200, Krzysztof Kozlowski wrote:
>> On 24/04/2024 09:34, Johan Hovold wrote:
>>> On Tue, Apr 23, 2024 at 06:29:44PM +0200, Krzysztof Kozlowski wrote:
>>>> On 23/04/2024 15:46, Johan Hovold wrote:
>>>>> When the power supply is shared with other peripherals the reset line
>>>>> can be wired in such a way that it can remain deasserted regardless of
>>>>> whether the supply is on or not.
>
>>>>> This is important as it can be used to avoid holding the controller in
>>>>> reset for extended periods of time when it remains powered, something
>>>>> which can lead to increased power consumption. Leaving reset deasserted
>>>>> also avoids leaking current through the reset circuitry pull-up
>>>>> resistors.
>>>>>
>>>>> Add a new 'no-reset-on-power-off' devicetree property which can be used
>>>>> by the OS to determine when reset needs to be asserted on power down.
>>>>>
>>>>> Note that this property can also be used when the supply cannot be
>>>>> turned off by the OS at all.
>>>
>>>>> reset-gpios:
>>>>> description: Reset GPIO; not all touchscreens using eKTH6915 hook this up.
>>>>>
>>>>> + no-reset-on-power-off:
>
>>>> Anyway, the property sounds like what the OS should be doing, which is
>>>> not what we want. You basically instruct driver what to do. We want a
>>>> described hardware configuration or hardware specifics.
>>>
>>> Right, and this was why I at first rejected a property name like this in
>>> favour of 'reset-pulled-to-supply' in my first draft. That name
>>> obviously does not work as the 'supply' suffix is already claimed, but I
>>> also realised that it doesn't really describe the hardware property that
>>> allows the reset line to remain asserted.
>>>
>>> The key feature in this hardware design is that the reset line will not
>>> just be pulled to the supply voltage (what other voltage would it be
>>> pulled to), but that it is also pulled to ground when the supply is
>>> disabled.
>>
>> OK, if the property was specific to the hardware, then I would propose
>> something more hardware-related, e.g. "reset-supply-tied". However :
>>
>>> Rather than trying to encode this in the property name, I settled on the
>>> descriptive 'no-reset-on-power-off' after the seeing the prior art in
>>> 'goodix,no-reset-during-suspend' property. The latter is too specific
>>> and encodes policy, but the former could still be considered hardware
>>> description and would also apply to other designs which have the
>>> property that the reset line should be left deasserted.
>>>
>>> One such example is when the supply can not be disabled at all (e.g. the
>>> Goodix case), but I can imagine there being more than one way to design
>>> such reset circuits.
>>
>> It seems it is common problem. LEDs have property
>> "retain-state-shutdown", to indicate that during system shutdown we
>> should not touch them (like power off). Would some variant be applicable
>> here? First, do we talk here about power off like system shutdown or
>> runtime PM, thus suspend?
>
> A name like 'retain-state-shutdown' would also be too specific as what
> I'm describing here is that the reset line should be (or can be) left
> deasserted whenever the OS wants to power off the device.
I don't think it is more specific than yours. It is actually more
generic. First, shutdown=poweroff, so that part is the same.
retain-state means keep things enabled, asserted, deasserted, etc, so
multiple cases. Your wording is specific - only one state is kept during
power off: reset deassert.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: HID: i2c-hid: elan: add 'no-reset-on-power-off' property
From: Johan Hovold @ 2024-05-03 8:47 UTC (permalink / raw)
To: Linus Walleij
Cc: Johan Hovold, Jiri Kosina, Benjamin Tissoires, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Douglas Anderson, linux-input, devicetree,
linux-arm-msm, linux-kernel
In-Reply-To: <CACRpkdYXfZwBdLSTTPbruD9qynOPuQBOZjCwA_6eE+1MUBCkgA@mail.gmail.com>
On Fri, May 03, 2024 at 09:40:43AM +0200, Linus Walleij wrote:
> On Tue, Apr 23, 2024 at 3:46 PM Johan Hovold <johan+linaro@kernel.org> wrote:
>
> > When the power supply is shared with other peripherals the reset line
> > can be wired in such a way that it can remain deasserted regardless of
> > whether the supply is on or not.
> >
> > This is important as it can be used to avoid holding the controller in
> > reset for extended periods of time when it remains powered, something
> > which can lead to increased power consumption. Leaving reset deasserted
> > also avoids leaking current through the reset circuitry pull-up
> > resistors.
>
> So the reset line in this case is a GPIO as seen from the context above.
>
> To me that means that the line should have the GPIO_OPEN_DRAIN flag
> set in the device tree node for reset-gpios. As it has pull-up resistors,
> setting the line to high impedance takes the device out of reset, and
> thus it is effectively open drain.
If you look at the devicetree patch later in the series this is exactly
what is done.
> > Add a new 'no-reset-on-power-off' devicetree property which can be used
> > by the OS to determine when reset needs to be asserted on power down.
>
> If the above holds true, the driver can then just check for the open drain flag
> in the reset-gpios phandle, and if that is set, conclude that it should not
> actively drive the line low in the poweroff state.
That is an alternative I considered but rejected as just knowing that
the gpio is open-drain is not necessarily sufficient, for example, if
the reset line is pulled to always-on rail while power to the device can
be cut.
Perhaps no one would ever construct hardware like that, but it does not
seem like the hardware property I'm trying to encode necessarily follows
from having an open-drain reset line.
And then the OS should probably not make assumptions like that either,
especially since getting it wrong can potentially lead to damaged
hardware.
Johan
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: HID: i2c-hid: elan: add 'no-reset-on-power-off' property
From: Linus Walleij @ 2024-05-03 7:40 UTC (permalink / raw)
To: Johan Hovold
Cc: Jiri Kosina, Benjamin Tissoires, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Douglas Anderson, linux-input, devicetree, linux-arm-msm,
linux-kernel
In-Reply-To: <20240423134611.31979-4-johan+linaro@kernel.org>
Hi Johan,
thanks for your patch!
On Tue, Apr 23, 2024 at 3:46 PM Johan Hovold <johan+linaro@kernel.org> wrote:
> When the power supply is shared with other peripherals the reset line
> can be wired in such a way that it can remain deasserted regardless of
> whether the supply is on or not.
>
> This is important as it can be used to avoid holding the controller in
> reset for extended periods of time when it remains powered, something
> which can lead to increased power consumption. Leaving reset deasserted
> also avoids leaking current through the reset circuitry pull-up
> resistors.
So the reset line in this case is a GPIO as seen from the context above.
To me that means that the line should have the GPIO_OPEN_DRAIN flag
set in the device tree node for reset-gpios. As it has pull-up resistors,
setting the line to high impedance takes the device out of reset, and
thus it is effectively open drain.
> Add a new 'no-reset-on-power-off' devicetree property which can be used
> by the OS to determine when reset needs to be asserted on power down.
If the above holds true, the driver can then just check for the open drain flag
in the reset-gpios phandle, and if that is set, conclude that it should not
actively drive the line low in the poweroff state.
I'd like Krzysztof's input on this though, as he's been all over the reset
code recently and knows it better than me.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: touchscreen: convert elan,ektf2127 to json-schema
From: Krzysztof Kozlowski @ 2024-05-03 7:07 UTC (permalink / raw)
To: Andreas Kemnade, dmitry.torokhov, robh, krzk+dt, conor+dt,
hdegoede, andy.shevchenko, u.kleine-koenig, siebren.vroegindeweij,
linux-input, devicetree, linux-kernel
In-Reply-To: <20240502185819.788716-2-andreas@kemnade.info>
On 02/05/2024 20:58, Andreas Kemnade wrote:
> Convert EKTF2127 infrared touchscreen controller binding to DT schema
> and add ektf2232 compatible.
This should be two commits.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
> .../bindings/input/touchscreen/ektf2127.txt | 25 --------
> .../input/touchscreen/elan,ektf2127.yaml | 59 +++++++++++++++++++
> 2 files changed, 59 insertions(+), 25 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/elan,ektf2127.yaml
>
...
> +allOf:
> + - $ref: touchscreen.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - elan,ektf2127
> + - elan,ektf2132
> + - elan,ektf2232
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + power-gpios:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - power-gpios
> +
> +unevaluatedProperties: false
> +
> +
Just one blank line.
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] Input: ektf2127 - add ektf2232 support
From: Andy Shevchenko @ 2024-05-03 3:37 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andreas Kemnade, robh, krzk+dt, conor+dt, hdegoede,
u.kleine-koenig, siebren.vroegindeweij, linux-input, devicetree,
linux-kernel
In-Reply-To: <ZjQdWdpmqoXhJeek@google.com>
On Fri, May 3, 2024 at 2:10 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, May 02, 2024 at 10:16:01PM +0300, Andy Shevchenko wrote:
> > On Thu, May 2, 2024 at 9:58 PM Andreas Kemnade <andreas@kemnade.info> wrote:
...
> > > + if (ts->shifted_status) {
>
> Instead of the flag I think it would be better if you had
> ts->status_shift and did
>
> status = buf[7] >> ts->status_shift;
> ektf2127_report2_contact(ts, 0, &buf[1], status & BIT(0));
> ektf2127_report2_contact(ts, 1, &buf[4], status & BIT(1));
>
> > > + ektf2127_report2_contact(ts, 0, &buf[1], !!(buf[7] & 1));
> > > + ektf2127_report2_contact(ts, 1, &buf[4], !!(buf[7] & 2));
> >
> > BIT(0)
> > BIT(1)
> >
> > > + } else {
> > > + ektf2127_report2_contact(ts, 0, &buf[1], !!(buf[7] & 2));
> > > + ektf2127_report2_contact(ts, 1, &buf[4], !!(buf[7] & 4));
> >
> > BIT(1)
> > BIT(2)
> >
> > > + }
...
> > > + if (dev->of_node &&
> > > + of_device_is_compatible(dev->of_node, "elan,ektf2232"))
> >
> > if (device_is_compatible(...))
>
> Actually I think this better come from data obtained via
> device_get_match_data().
>
> > > + ts->shifted_status = true;
I agree with your comments. Hopefully the author as well.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 01/10] selftests/sgx: Compile with -D_GNU_SOURCE
From: Jarkko Sakkinen @ 2024-05-03 1:46 UTC (permalink / raw)
To: Edward Liaw, shuah, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Jiri Kosina, Benjamin Tissoires, Sean Christopherson,
Paolo Bonzini, Bongsu Jeon, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alexandre Belloni, Dave Hansen,
Andrew Morton, Muhammad Usama Anjum
Cc: linux-kernel, linux-kselftest, kernel-team, linux-sound,
linux-input, kvm, netdev, linux-rtc, linux-sgx, kernel test robot
In-Reply-To: <20240430235057.1351993-2-edliaw@google.com>
On Wed May 1, 2024 at 2:50 AM EEST, Edward Liaw wrote:
> 809216233555 ("selftests/harness: remove use of LINE_MAX") introduced
> asprintf into kselftest_harness.h, which is a GNU extension and needs
> _GNU_SOURCE to either be defined prior to including headers or with the
> -D_GNU_SOURCE flag passed to the compiler.
>
> Fixes: 809216233555 ("selftests/harness: remove use of LINE_MAX")
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Closes: https://lore.kernel.org/oe-lkp/202404301040.3bea5782-oliver.sang@intel.com
> Signed-off-by: Edward Liaw <edliaw@google.com>
> ---
> tools/testing/selftests/sgx/Makefile | 2 +-
> tools/testing/selftests/sgx/sigstruct.c | 2 --
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/sgx/Makefile b/tools/testing/selftests/sgx/Makefile
> index 867f88ce2570..272da790d9ae 100644
> --- a/tools/testing/selftests/sgx/Makefile
> +++ b/tools/testing/selftests/sgx/Makefile
> @@ -12,7 +12,7 @@ OBJCOPY := $(CROSS_COMPILE)objcopy
> endif
>
> INCLUDES := -I$(top_srcdir)/tools/include
> -HOST_CFLAGS := -Wall -Werror -g $(INCLUDES) -fPIC
> +HOST_CFLAGS := -Wall -Werror -g $(INCLUDES) -fPIC -D_GNU_SOURCE
> HOST_LDFLAGS := -z noexecstack -lcrypto
> ENCL_CFLAGS += -Wall -Werror -static-pie -nostdlib -ffreestanding -fPIE \
> -fno-stack-protector -mrdrnd $(INCLUDES)
> diff --git a/tools/testing/selftests/sgx/sigstruct.c b/tools/testing/selftests/sgx/sigstruct.c
> index d73b29becf5b..a0c2de7c5302 100644
> --- a/tools/testing/selftests/sgx/sigstruct.c
> +++ b/tools/testing/selftests/sgx/sigstruct.c
> @@ -1,7 +1,5 @@
> // SPDX-License-Identifier: GPL-2.0
> /* Copyright(c) 2016-20 Intel Corporation. */
> -
> -#define _GNU_SOURCE
> #include <assert.h>
> #include <getopt.h>
> #include <stdbool.h>
> --
> 2.45.0.rc0.197.gbae5840b3b-goog
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] Input: elantech - fix touchpad state on resume for Lenovo N24
From: Dmitry Torokhov @ 2024-05-02 23:13 UTC (permalink / raw)
To: Jonathan Denose; +Cc: LKML, linux-input, Greg Kroah-Hartman, Jeffery Miller
In-Reply-To: <20240501140231.1.Ifa0e25ebf968d8f307f58d678036944141ab17e6@changeid>
On Wed, May 01, 2024 at 02:02:32PM +0000, Jonathan Denose wrote:
> The Lenovo N24 on resume becomes stuck in a state where it
> sends incorrect packets, causing elantech_packet_check_v4 to fail.
> The only way for the device to resume sending the correct packets is for
> it to be disabled and then re-enabled.
>
> This change adds a dmi check to trigger this behavior on resume.
> Signed-off-by: Jonathan Denose <jdenose@google.com>
> ---
>
> drivers/input/mouse/elantech.c | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 4e38229404b4b..e0f3095b4227e 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1476,6 +1476,23 @@ static void elantech_disconnect(struct psmouse *psmouse)
> psmouse->private = NULL;
> }
>
> +/*
> + * Some hw_version 4 models fail to properly activate absolute mode on
> + * resume without going through disable/enable cycle.
> + */
> +static const struct dmi_system_id elantech_needs_reenable[] = {
> +#if defined(CONFIG_DMI) && defined(CONFIG_X86)
> + {
> + /* Lenovo N24 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "81AF"),
> + },
> + },
> +#endif
> + { }
> +};
> +
> /*
> * Put the touchpad back into absolute mode when reconnecting
> */
> @@ -1486,6 +1503,22 @@ static int elantech_reconnect(struct psmouse *psmouse)
> if (elantech_detect(psmouse, 0))
> return -1;
>
> + if (dmi_check_system(elantech_needs_reenable)) {
> + int err;
> +
> + err = ps2_sendbyte(&psmouse->ps2dev, PSMOUSE_CMD_DISABLE, NULL);
This and below should be ps2_command().
> +
> + if (err)
> + psmouse_warn(psmouse, "Failed to deactivate mouse on %s: %d\n",
> + psmouse->ps2dev.serio->phys, err);
> +
> + err = ps2_sendbyte(&psmouse->ps2dev, PSMOUSE_CMD_ENABLE, NULL);
> +
> + if (err)
> + psmouse_warn(psmouse, "Failed to reactivate mouse on %s: %d\n",
> + psmouse->ps2dev.serio->phys, err);
> + }
> +
> if (elantech_set_absolute_mode(psmouse)) {
> psmouse_err(psmouse,
> "failed to put touchpad back into absolute mode.\n");
> --
> 2.45.0.rc0.197.gbae5840b3b-goog
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] Input: ektf2127 - add ektf2232 support
From: Dmitry Torokhov @ 2024-05-02 23:10 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Andreas Kemnade, robh, krzk+dt, conor+dt, hdegoede,
u.kleine-koenig, siebren.vroegindeweij, linux-input, devicetree,
linux-kernel
In-Reply-To: <CAHp75Vd1A8sy2Oky9TENUTAj0SCCyVQ8Zh49AN3X7t9cK2F+iw@mail.gmail.com>
On Thu, May 02, 2024 at 10:16:01PM +0300, Andy Shevchenko wrote:
> On Thu, May 2, 2024 at 9:58 PM Andreas Kemnade <andreas@kemnade.info> wrote:
> >
> > The chip is similar, but has status bits at different positions,
> > so use the correct bits.
>
> ...
>
> > + if (ts->shifted_status) {
Instead of the flag I think it would be better if you had
ts->status_shift and did
status = buf[7] >> ts->status_shift;
ektf2127_report2_contact(ts, 0, &buf[1], status & BIT(0));
ektf2127_report2_contact(ts, 1, &buf[4], status & BIT(1));
> > + ektf2127_report2_contact(ts, 0, &buf[1], !!(buf[7] & 1));
> > + ektf2127_report2_contact(ts, 1, &buf[4], !!(buf[7] & 2));
>
> BIT(0)
> BIT(1)
>
> > + } else {
> > + ektf2127_report2_contact(ts, 0, &buf[1], !!(buf[7] & 2));
> > + ektf2127_report2_contact(ts, 1, &buf[4], !!(buf[7] & 4));
>
> BIT(1)
> BIT(2)
>
> > + }
>
> ...
>
> > + if (dev->of_node &&
> > + of_device_is_compatible(dev->of_node, "elan,ektf2232"))
>
> if (device_is_compatible(...))
Actually I think this better come from data obtained via
device_get_match_data().
>
> > + ts->shifted_status = true;
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 00/10] Define _GNU_SOURCE for sources using
From: Kees Cook @ 2024-05-02 22:41 UTC (permalink / raw)
To: Sean Christopherson
Cc: Mark Brown, Edward Liaw, shuah, Jaroslav Kysela, Takashi Iwai,
Jiri Kosina, Benjamin Tissoires, Paolo Bonzini, Bongsu Jeon,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexandre Belloni, Jarkko Sakkinen, Dave Hansen, Andrew Morton,
Muhammad Usama Anjum, linux-kernel, linux-kselftest, kernel-team,
linux-sound, linux-input, kvm, netdev, linux-rtc, linux-sgx
In-Reply-To: <ZjJClMYEIyGEo37e@google.com>
On Wed, May 01, 2024 at 06:24:36AM -0700, Sean Christopherson wrote:
> On Wed, May 01, 2024, Mark Brown wrote:
> > On Tue, Apr 30, 2024 at 11:50:09PM +0000, Edward Liaw wrote:
> > > 809216233555 ("selftests/harness: remove use of LINE_MAX") introduced
> > > asprintf into kselftest_harness.h, which is a GNU extension and needs
> > > _GNU_SOURCE to either be defined prior to including headers or with the
> > > -D_GNU_SOURCE flag passed to the compiler.
> >
> > This seems like something that should be handled centrally rather than
> > having to go round and audit the users every time some update is made.
>
> +1.
>
> And if for some reason unilaterally defining _GNU_SOURCE in
> tools/testing/selftests/lib.mk isn't an option, we should at least have
> kselftest_harness.h assert instead of making a futile attempt to provide its own
> definition, e.g.
>
> diff --git a/tools/testing/selftests/kselftest_harness.h b/tools/testing/selftests/kselftest_harness.h
> index 4fd735e48ee7..6741b4f20f25 100644
> --- a/tools/testing/selftests/kselftest_harness.h
> +++ b/tools/testing/selftests/kselftest_harness.h
> @@ -51,7 +51,7 @@
> #define __KSELFTEST_HARNESS_H
>
> #ifndef _GNU_SOURCE
> -#define _GNU_SOURCE
> +static_assert(0, "Using the kselftests harness requires building with _GNU_SOURCE");
> #endif
> #include <asm/types.h>
> #include <ctype.h>
Yeah, let's fix centrally. I like this approach.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] Input: elantech - fix touchpad state on resume for Lenovo N24
From: kernel test robot @ 2024-05-02 19:57 UTC (permalink / raw)
To: Jonathan Denose, LKML
Cc: oe-kbuild-all, linux-input, Jonathan Denose, Dmitry Torokhov,
Greg Kroah-Hartman, Jeffery Miller
In-Reply-To: <20240501140231.1.Ifa0e25ebf968d8f307f58d678036944141ab17e6@changeid>
Hi Jonathan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on dtor-input/next]
[also build test WARNING on dtor-input/for-linus hid/for-next linus/master v6.9-rc6 next-20240502]
[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/Jonathan-Denose/Input-elantech-fix-touchpad-state-on-resume-for-Lenovo-N24/20240501-220739
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link: https://lore.kernel.org/r/20240501140231.1.Ifa0e25ebf968d8f307f58d678036944141ab17e6%40changeid
patch subject: [PATCH] Input: elantech - fix touchpad state on resume for Lenovo N24
config: powerpc64-randconfig-r122-20240502 (https://download.01.org/0day-ci/archive/20240503/202405030346.3Q7ixiBD-lkp@intel.com/config)
compiler: powerpc64-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20240503/202405030346.3Q7ixiBD-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/202405030346.3Q7ixiBD-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/input/mouse/elantech.c:1509:75: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected unsigned int timeout @@ got void * @@
drivers/input/mouse/elantech.c:1509:75: sparse: expected unsigned int timeout
drivers/input/mouse/elantech.c:1509:75: sparse: got void *
drivers/input/mouse/elantech.c:1515:74: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected unsigned int timeout @@ got void * @@
drivers/input/mouse/elantech.c:1515:74: sparse: expected unsigned int timeout
drivers/input/mouse/elantech.c:1515:74: sparse: got void *
vim +1509 drivers/input/mouse/elantech.c
1495
1496 /*
1497 * Put the touchpad back into absolute mode when reconnecting
1498 */
1499 static int elantech_reconnect(struct psmouse *psmouse)
1500 {
1501 psmouse_reset(psmouse);
1502
1503 if (elantech_detect(psmouse, 0))
1504 return -1;
1505
1506 if (dmi_check_system(elantech_needs_reenable)) {
1507 int err;
1508
> 1509 err = ps2_sendbyte(&psmouse->ps2dev, PSMOUSE_CMD_DISABLE, NULL);
1510
1511 if (err)
1512 psmouse_warn(psmouse, "Failed to deactivate mouse on %s: %d\n",
1513 psmouse->ps2dev.serio->phys, err);
1514
1515 err = ps2_sendbyte(&psmouse->ps2dev, PSMOUSE_CMD_ENABLE, NULL);
1516
1517 if (err)
1518 psmouse_warn(psmouse, "Failed to reactivate mouse on %s: %d\n",
1519 psmouse->ps2dev.serio->phys, err);
1520 }
1521
1522 if (elantech_set_absolute_mode(psmouse)) {
1523 psmouse_err(psmouse,
1524 "failed to put touchpad back into absolute mode.\n");
1525 return -1;
1526 }
1527
1528 return 0;
1529 }
1530
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/2] Input: ektf2127 - add ektf2232 support
From: Andy Shevchenko @ 2024-05-02 19:16 UTC (permalink / raw)
To: Andreas Kemnade
Cc: dmitry.torokhov, robh, krzk+dt, conor+dt, hdegoede,
u.kleine-koenig, siebren.vroegindeweij, linux-input, devicetree,
linux-kernel
In-Reply-To: <20240502185819.788716-3-andreas@kemnade.info>
On Thu, May 2, 2024 at 9:58 PM Andreas Kemnade <andreas@kemnade.info> wrote:
>
> The chip is similar, but has status bits at different positions,
> so use the correct bits.
...
> + if (ts->shifted_status) {
> + ektf2127_report2_contact(ts, 0, &buf[1], !!(buf[7] & 1));
> + ektf2127_report2_contact(ts, 1, &buf[4], !!(buf[7] & 2));
BIT(0)
BIT(1)
> + } else {
> + ektf2127_report2_contact(ts, 0, &buf[1], !!(buf[7] & 2));
> + ektf2127_report2_contact(ts, 1, &buf[4], !!(buf[7] & 4));
BIT(1)
BIT(2)
> + }
...
> + if (dev->of_node &&
> + of_device_is_compatible(dev->of_node, "elan,ektf2232"))
if (device_is_compatible(...))
> + ts->shifted_status = true;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] Input: elantech - fix touchpad state on resume for Lenovo N24
From: kernel test robot @ 2024-05-02 19:03 UTC (permalink / raw)
To: Jonathan Denose, LKML
Cc: oe-kbuild-all, linux-input, Jonathan Denose, Dmitry Torokhov,
Greg Kroah-Hartman, Jeffery Miller
In-Reply-To: <20240501140231.1.Ifa0e25ebf968d8f307f58d678036944141ab17e6@changeid>
Hi Jonathan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on dtor-input/next]
[also build test WARNING on dtor-input/for-linus hid/for-next linus/master v6.9-rc6 next-20240502]
[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/Jonathan-Denose/Input-elantech-fix-touchpad-state-on-resume-for-Lenovo-N24/20240501-220739
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link: https://lore.kernel.org/r/20240501140231.1.Ifa0e25ebf968d8f307f58d678036944141ab17e6%40changeid
patch subject: [PATCH] Input: elantech - fix touchpad state on resume for Lenovo N24
config: x86_64-rhel-8.3 (https://download.01.org/0day-ci/archive/20240503/202405030210.izdCj8wZ-lkp@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240503/202405030210.izdCj8wZ-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/202405030210.izdCj8wZ-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from include/uapi/linux/posix_types.h:5,
from include/uapi/linux/types.h:14,
from include/linux/types.h:6,
from include/linux/math.h:5,
from include/linux/delay.h:22,
from drivers/input/mouse/elantech.c:10:
drivers/input/mouse/elantech.c: In function 'elantech_reconnect':
>> include/linux/stddef.h:8:14: warning: passing argument 3 of 'ps2_sendbyte' makes integer from pointer without a cast [-Wint-conversion]
8 | #define NULL ((void *)0)
| ^~~~~~~~~~~
| |
| void *
drivers/input/mouse/elantech.c:1509:75: note: in expansion of macro 'NULL'
1509 | err = ps2_sendbyte(&psmouse->ps2dev, PSMOUSE_CMD_DISABLE, NULL);
| ^~~~
In file included from drivers/input/mouse/elantech.c:19:
include/linux/libps2.h:64:63: note: expected 'unsigned int' but argument is of type 'void *'
64 | int ps2_sendbyte(struct ps2dev *ps2dev, u8 byte, unsigned int timeout);
| ~~~~~~~~~~~~~^~~~~~~
>> include/linux/stddef.h:8:14: warning: passing argument 3 of 'ps2_sendbyte' makes integer from pointer without a cast [-Wint-conversion]
8 | #define NULL ((void *)0)
| ^~~~~~~~~~~
| |
| void *
drivers/input/mouse/elantech.c:1515:74: note: in expansion of macro 'NULL'
1515 | err = ps2_sendbyte(&psmouse->ps2dev, PSMOUSE_CMD_ENABLE, NULL);
| ^~~~
include/linux/libps2.h:64:63: note: expected 'unsigned int' but argument is of type 'void *'
64 | int ps2_sendbyte(struct ps2dev *ps2dev, u8 byte, unsigned int timeout);
| ~~~~~~~~~~~~~^~~~~~~
drivers/input/mouse/elantech.c: In function 'elantech_setup_ps2':
drivers/input/mouse/elantech.c:2123:65: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
2123 | snprintf(etd->tp_phys, sizeof(etd->tp_phys), "%s/input1",
| ^~~~~~~
drivers/input/mouse/elantech.c:2123:17: note: 'snprintf' output between 8 and 39 bytes into a destination of size 32
2123 | snprintf(etd->tp_phys, sizeof(etd->tp_phys), "%s/input1",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2124 | psmouse->ps2dev.serio->phys);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/ps2_sendbyte +8 include/linux/stddef.h
^1da177e4c3f41 Linus Torvalds 2005-04-16 6
^1da177e4c3f41 Linus Torvalds 2005-04-16 7 #undef NULL
^1da177e4c3f41 Linus Torvalds 2005-04-16 @8 #define NULL ((void *)0)
6e218287432472 Richard Knutsson 2006-09-30 9
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH 1/2] dt-bindings: touchscreen: convert elan,ektf2127 to json-schema
From: Andreas Kemnade @ 2024-05-02 18:58 UTC (permalink / raw)
To: dmitry.torokhov, robh, krzk+dt, conor+dt, andreas, hdegoede,
andy.shevchenko, u.kleine-koenig, siebren.vroegindeweij,
linux-input, devicetree, linux-kernel
In-Reply-To: <20240502185819.788716-1-andreas@kemnade.info>
Convert EKTF2127 infrared touchscreen controller binding to DT schema
and add ektf2232 compatible.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
.../bindings/input/touchscreen/ektf2127.txt | 25 --------
.../input/touchscreen/elan,ektf2127.yaml | 59 +++++++++++++++++++
2 files changed, 59 insertions(+), 25 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/elan,ektf2127.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt b/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
deleted file mode 100644
index c9f2c9f578e34..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Elan eKTF2127 I2C touchscreen controller
-
-Required properties:
- - compatible : "elan,ektf2127" or "elan,ektf2132"
- - reg : I2C slave address of the chip (0x40)
- - interrupts : interrupt specification for the ektf2127 interrupt
- - power-gpios : GPIO specification for the pin connected to the
- ektf2127's wake input. This needs to be driven high
- to take ektf2127 out of its low power state
-
-For additional optional properties see: touchscreen.txt
-
-Example:
-
-i2c@00000000 {
- ektf2127: touchscreen@15 {
- compatible = "elan,ektf2127";
- reg = <0x15>;
- interrupt-parent = <&pio>;
- interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>
- power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>;
- touchscreen-inverted-x;
- touchscreen-swapped-x-y;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/elan,ektf2127.yaml b/Documentation/devicetree/bindings/input/touchscreen/elan,ektf2127.yaml
new file mode 100644
index 0000000000000..66cda99a2ddd0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/elan,ektf2127.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/elan,ektf2127.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Elan eKTF2127 I2C touchscreen controller
+
+maintainers:
+ - Siebren Vroegindeweij <siebren.vroegindeweij@hotmail.com>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - elan,ektf2127
+ - elan,ektf2132
+ - elan,ektf2232
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ power-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - power-gpios
+
+unevaluatedProperties: false
+
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@15 {
+ compatible = "elan,ektf2127";
+ reg = <0x15>;
+ interrupt-parent = <&pio>;
+ interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>;
+ power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>;
+ touchscreen-inverted-x;
+ touchscreen-swapped-x-y;
+ };
+ };
+...
--
2.39.2
^ permalink raw reply related
* [PATCH 0/2] Input: Add ektf2232 support
From: Andreas Kemnade @ 2024-05-02 18:58 UTC (permalink / raw)
To: dmitry.torokhov, robh, krzk+dt, conor+dt, andreas, hdegoede,
andy.shevchenko, u.kleine-koenig, siebren.vroegindeweij,
linux-input, devicetree, linux-kernel
Add support for the EKTF2232 to the ektf2127 driver which
contains support for similar chips.
Add the needed compatible to bindings and convert them.
Andreas Kemnade (2):
dt-bindings: touchscreen: convert elan,ektf2127 to json-schema
Input: ektf2127 - add ektf2232 support
.../bindings/input/touchscreen/ektf2127.txt | 25 --------
.../input/touchscreen/elan,ektf2127.yaml | 59 +++++++++++++++++++
drivers/input/touchscreen/ektf2127.c | 15 ++++-
3 files changed, 72 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/elan,ektf2127.yaml
--
2.39.2
^ permalink raw reply
* [PATCH 2/2] Input: ektf2127 - add ektf2232 support
From: Andreas Kemnade @ 2024-05-02 18:58 UTC (permalink / raw)
To: dmitry.torokhov, robh, krzk+dt, conor+dt, andreas, hdegoede,
andy.shevchenko, u.kleine-koenig, siebren.vroegindeweij,
linux-input, devicetree, linux-kernel
In-Reply-To: <20240502185819.788716-1-andreas@kemnade.info>
The chip is similar, but has status bits at different positions,
so use the correct bits.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
drivers/input/touchscreen/ektf2127.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/ektf2127.c b/drivers/input/touchscreen/ektf2127.c
index cc3103b9cbfba..5c2a6bfc63d84 100644
--- a/drivers/input/touchscreen/ektf2127.c
+++ b/drivers/input/touchscreen/ektf2127.c
@@ -46,6 +46,7 @@ struct ektf2127_ts {
struct input_dev *input;
struct gpio_desc *power_gpios;
struct touchscreen_properties prop;
+ bool shifted_status;
};
static void ektf2127_parse_coordinates(const u8 *buf, unsigned int touch_count,
@@ -112,8 +113,13 @@ static void ektf2127_report2_contact(struct ektf2127_ts *ts, int slot,
static void ektf2127_report2_event(struct ektf2127_ts *ts, const u8 *buf)
{
- ektf2127_report2_contact(ts, 0, &buf[1], !!(buf[7] & 2));
- ektf2127_report2_contact(ts, 1, &buf[4], !!(buf[7] & 4));
+ if (ts->shifted_status) {
+ ektf2127_report2_contact(ts, 0, &buf[1], !!(buf[7] & 1));
+ ektf2127_report2_contact(ts, 1, &buf[4], !!(buf[7] & 2));
+ } else {
+ ektf2127_report2_contact(ts, 0, &buf[1], !!(buf[7] & 2));
+ ektf2127_report2_contact(ts, 1, &buf[4], !!(buf[7] & 4));
+ }
input_mt_sync_frame(ts->input);
input_sync(ts->input);
@@ -303,6 +309,10 @@ static int ektf2127_probe(struct i2c_client *client)
return error;
ts->input = input;
+ if (dev->of_node &&
+ of_device_is_compatible(dev->of_node, "elan,ektf2232"))
+ ts->shifted_status = true;
+
input_set_drvdata(input, ts);
error = devm_request_threaded_irq(dev, client->irq,
@@ -329,6 +339,7 @@ static int ektf2127_probe(struct i2c_client *client)
static const struct of_device_id ektf2127_of_match[] = {
{ .compatible = "elan,ektf2127" },
{ .compatible = "elan,ektf2132" },
+ { .compatible = "elan,ektf2232" },
{}
};
MODULE_DEVICE_TABLE(of, ektf2127_of_match);
--
2.39.2
^ permalink raw reply related
* [PATCH v3 11/11] HID: hexLIN: Implement ability to update lin mode
From: Christoph Fritz @ 2024-05-02 18:28 UTC (permalink / raw)
To: Jiri Slaby, Oliver Hartkopp, Marc Kleine-Budde, Vincent Mailhol,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jiri Kosina,
Benjamin Tissoires, Greg Kroah-Hartman, Sebastian Reichel,
Linus Walleij
Cc: Andreas Lauser, Jonathan Corbet, Pavel Pisa, linux-can, netdev,
devicetree, linux-input, linux-serial
In-Reply-To: <20240502182804.145926-1-christoph.fritz@hexdev.de>
This patch enhances the hexLIN driver by implementing the newly
introduced update_lin_mode() callback. So that either commander or
responder mode can be configured on this hardware.
Signed-off-by: Christoph Fritz <christoph.fritz@hexdev.de>
---
drivers/hid/hid-hexdev-hexlin.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/hid/hid-hexdev-hexlin.c b/drivers/hid/hid-hexdev-hexlin.c
index 1ddc1e00ab2da..1723b272138ba 100644
--- a/drivers/hid/hid-hexdev-hexlin.c
+++ b/drivers/hid/hid-hexdev-hexlin.c
@@ -180,6 +180,8 @@ HEXLIN_GET_CMD(get_baudrate, HEXLIN_GET_BAUDRATE)
}
HEXLIN_VAL_CMD(send_break, HEXLIN_SEND_BREAK, hexlin_val8_req, u8)
+HEXLIN_VAL_CMD(set_mode_controller, HEXLIN_SET_MODE_CONTROLLER, hexlin_val8_req,
+ bool)
static int hexlin_queue_frames_insert(struct hexlin_priv_data *priv,
const u8 *raw_data, int sz)
@@ -346,6 +348,14 @@ static int hexlin_ldo_tx(struct lin_device *ldev,
return ret;
}
+static int hexlin_update_lin_mode(struct lin_device *ldev, enum lin_mode lm)
+{
+ struct hid_device *hdev = to_hid_device(ldev->dev);
+ struct hexlin_priv_data *priv = hid_get_drvdata(hdev);
+
+ return hexlin_set_mode_controller(priv, lm == LINBUS_COMMANDER);
+}
+
static int hexlin_update_bitrate(struct lin_device *ldev, u16 bitrate)
{
struct hid_device *hdev = to_hid_device(ldev->dev);
@@ -417,6 +427,7 @@ static const struct lin_device_ops hexlin_ldo = {
.ldo_open = hexlin_open,
.ldo_stop = hexlin_stop,
.ldo_tx = hexlin_ldo_tx,
+ .update_lin_mode = hexlin_update_lin_mode,
.update_bitrate = hexlin_update_bitrate,
.get_responder_answer = hexlin_get_responder_answer,
.update_responder_answer = hexlin_update_resp_answer,
--
2.39.2
^ permalink raw reply related
* [PATCH v3 10/11] can: lin: Support setting LIN mode
From: Christoph Fritz @ 2024-05-02 18:28 UTC (permalink / raw)
To: Jiri Slaby, Oliver Hartkopp, Marc Kleine-Budde, Vincent Mailhol,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jiri Kosina,
Benjamin Tissoires, Greg Kroah-Hartman, Sebastian Reichel,
Linus Walleij
Cc: Andreas Lauser, Jonathan Corbet, Pavel Pisa, linux-can, netdev,
devicetree, linux-input, linux-serial
In-Reply-To: <20240502182804.145926-1-christoph.fritz@hexdev.de>
A LIN node can work as commander or responder. This patch is introducing
a new control mode (CAN_CTRLMODE_LIN_COMMANDER), so that e.g. the ip
tool from iproute2 can turn on commander mode when the device is being
brought up.
Signed-off-by: Christoph Fritz <christoph.fritz@hexdev.de>
---
drivers/net/can/lin.c | 40 +++++++++++++++++++++++++++++++-
include/net/lin.h | 7 ++++++
include/uapi/linux/can/netlink.h | 1 +
3 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/lin.c b/drivers/net/can/lin.c
index ee2ebea2c865f..96cd016228fea 100644
--- a/drivers/net/can/lin.c
+++ b/drivers/net/can/lin.c
@@ -271,11 +271,40 @@ static netdev_tx_t lin_start_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
}
+static int lin_update_mode(struct net_device *ndev)
+{
+ struct lin_device *ldev = netdev_priv(ndev);
+ u32 ctrlmode = ldev->can.ctrlmode;
+ enum lin_mode lm;
+ int ret = 0;
+
+ lm = (ctrlmode & CAN_CTRLMODE_LIN_COMMANDER) ? LINBUS_COMMANDER :
+ LINBUS_RESPONDER;
+ if (ldev->lmode != lm) {
+ if (!ldev->ldev_ops->update_lin_mode) {
+ netdev_err(ndev, "setting lin mode unsupported\n");
+ return -EINVAL;
+ }
+ ret = ldev->ldev_ops->update_lin_mode(ldev, lm);
+ if (ret) {
+ netdev_err(ndev, "Failed to set lin mode: %d\n", ret);
+ return ret;
+ }
+ ldev->lmode = lm;
+ }
+
+ return ret;
+}
+
static int lin_open(struct net_device *ndev)
{
struct lin_device *ldev = netdev_priv(ndev);
int ret;
+ ret = lin_update_mode(ndev);
+ if (ret)
+ return ret;
+
ldev->tx_busy = false;
ret = open_candev(ndev);
@@ -451,7 +480,7 @@ struct lin_device *register_lin(struct device *dev,
ndev->mtu = CANFD_MTU;
ldev->can.bittiming.bitrate = LIN_DEFAULT_BAUDRATE;
ldev->can.ctrlmode = CAN_CTRLMODE_LIN;
- ldev->can.ctrlmode_supported = 0;
+ ldev->can.ctrlmode_supported = CAN_CTRLMODE_LIN_COMMANDER;
ldev->can.bitrate_const = lin_bitrate;
ldev->can.bitrate_const_cnt = ARRAY_SIZE(lin_bitrate);
ldev->can.do_set_bittiming = lin_set_bittiming;
@@ -466,6 +495,15 @@ struct lin_device *register_lin(struct device *dev,
goto exit_candev;
}
+ ldev->lmode = LINBUS_RESPONDER;
+ if (ldev->ldev_ops->update_lin_mode) {
+ ret = ldev->ldev_ops->update_lin_mode(ldev, ldev->lmode);
+ if (ret) {
+ netdev_err(ndev, "updating lin mode failed\n");
+ goto exit_candev;
+ }
+ }
+
ret = register_candev(ndev);
if (ret)
goto exit_candev;
diff --git a/include/net/lin.h b/include/net/lin.h
index e7c7c820a6e18..e80a4509b7a8c 100644
--- a/include/net/lin.h
+++ b/include/net/lin.h
@@ -36,6 +36,11 @@ struct lin_attr {
struct lin_device *ldev;
};
+enum lin_mode {
+ LINBUS_RESPONDER = 0,
+ LINBUS_COMMANDER,
+};
+
struct lin_device {
struct can_priv can; /* must be the first member */
struct net_device *ndev;
@@ -47,6 +52,7 @@ struct lin_device {
struct sk_buff *tx_skb;
struct kobject *lin_ids_kobj;
struct lin_attr sysfs_entries[LIN_NUM_IDS];
+ enum lin_mode lmode;
};
enum lin_checksum_mode {
@@ -73,6 +79,7 @@ struct lin_device_ops {
int (*ldo_open)(struct lin_device *ldev);
int (*ldo_stop)(struct lin_device *ldev);
int (*ldo_tx)(struct lin_device *ldev, const struct lin_frame *frame);
+ int (*update_lin_mode)(struct lin_device *ldev, enum lin_mode lm);
int (*update_bitrate)(struct lin_device *ldev, u16 bitrate);
int (*update_responder_answer)(struct lin_device *ldev,
const struct lin_responder_answer *answ);
diff --git a/include/uapi/linux/can/netlink.h b/include/uapi/linux/can/netlink.h
index 51b0e2a7624e4..6c84a7666c646 100644
--- a/include/uapi/linux/can/netlink.h
+++ b/include/uapi/linux/can/netlink.h
@@ -104,6 +104,7 @@ struct can_ctrlmode {
#define CAN_CTRLMODE_TDC_AUTO 0x200 /* CAN transiver automatically calculates TDCV */
#define CAN_CTRLMODE_TDC_MANUAL 0x400 /* TDCV is manually set up by user */
#define CAN_CTRLMODE_LIN 0x800 /* LIN bus mode */
+#define CAN_CTRLMODE_LIN_COMMANDER 0x1000 /* LIN bus specific commander mode */
/*
* CAN device statistics
--
2.39.2
^ permalink raw reply related
* [PATCH v3 09/11] can: lin: Handle rx offload config frames
From: Christoph Fritz @ 2024-05-02 18:28 UTC (permalink / raw)
To: Jiri Slaby, Oliver Hartkopp, Marc Kleine-Budde, Vincent Mailhol,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jiri Kosina,
Benjamin Tissoires, Greg Kroah-Hartman, Sebastian Reichel,
Linus Walleij
Cc: Andreas Lauser, Jonathan Corbet, Pavel Pisa, linux-can, netdev,
devicetree, linux-input, linux-serial
In-Reply-To: <20240502182804.145926-1-christoph.fritz@hexdev.de>
The CAN Broadcast Manager now has the capability to dispatch CANFD
frames marked with the id LINBUS_RXOFFLOAD_ID. This patch introduces
functionality to interpret these specific frames, enabling the
configuration of RX offloading within the LIN driver.
Signed-off-by: Christoph Fritz <christoph.fritz@hexdev.de>
---
drivers/net/can/lin.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/net/can/lin.c b/drivers/net/can/lin.c
index 95906003666fb..ee2ebea2c865f 100644
--- a/drivers/net/can/lin.c
+++ b/drivers/net/can/lin.c
@@ -194,6 +194,27 @@ static void lin_remove_sysfs_id_files(struct net_device *ndev)
}
}
+static int lin_setup_rxoffload(struct lin_device *ldev,
+ struct canfd_frame *cfd)
+{
+ struct lin_responder_answer answ;
+
+ if (!(cfd->flags & CANFD_FDF))
+ return -EMSGSIZE;
+
+ BUILD_BUG_ON(sizeof(struct lin_responder_answer) > sizeof(cfd->data));
+ memcpy(&answ, cfd->data, sizeof(struct lin_responder_answer));
+
+ answ.lf.checksum_mode = (cfd->can_id & LIN_ENHANCED_CKSUM_FLAG) ?
+ LINBUS_ENHANCED : LINBUS_CLASSIC;
+
+ if (answ.lf.lin_id > LIN_ID_MASK ||
+ answ.event_associated_id > LIN_ID_MASK)
+ return -EINVAL;
+
+ return ldev->ldev_ops->update_responder_answer(ldev, &answ);
+}
+
static void lin_tx_work_handler(struct work_struct *ws)
{
struct lin_device *ldev = container_of(ws, struct lin_device,
@@ -206,6 +227,14 @@ static void lin_tx_work_handler(struct work_struct *ws)
ldev->tx_busy = true;
cfd = (struct canfd_frame *)ldev->tx_skb->data;
+
+ if (cfd->can_id & LIN_RXOFFLOAD_DATA_FLAG) {
+ ret = lin_setup_rxoffload(ldev, cfd);
+ if (ret < 0)
+ netdev_err(ndev, "setting up rx failed %d\n", ret);
+ goto lin_tx_out;
+ }
+
lf.checksum_mode = (cfd->can_id & LIN_ENHANCED_CKSUM_FLAG) ?
LINBUS_ENHANCED : LINBUS_CLASSIC;
lf.lin_id = cfd->can_id & LIN_ID_MASK;
--
2.39.2
^ permalink raw reply related
* [PATCH v3 08/11] can: bcm: Add LIN answer offloading for responder mode
From: Christoph Fritz @ 2024-05-02 18:28 UTC (permalink / raw)
To: Jiri Slaby, Oliver Hartkopp, Marc Kleine-Budde, Vincent Mailhol,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jiri Kosina,
Benjamin Tissoires, Greg Kroah-Hartman, Sebastian Reichel,
Linus Walleij
Cc: Andreas Lauser, Jonathan Corbet, Pavel Pisa, linux-can, netdev,
devicetree, linux-input, linux-serial
In-Reply-To: <20240502182804.145926-1-christoph.fritz@hexdev.de>
Enhance CAN broadcast manager with RX_LIN_SETUP and RX_LIN_DELETE
operations to setup automatic LIN frame responses in responder mode.
Additionally, the patch introduces the LIN_EVENT_FRAME flag to
setup event-triggered LIN frames.
Signed-off-by: Christoph Fritz <christoph.fritz@hexdev.de>
---
include/uapi/linux/can/bcm.h | 5 ++-
net/can/bcm.c | 74 +++++++++++++++++++++++++++++++++++-
2 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/can/bcm.h b/include/uapi/linux/can/bcm.h
index f1e45f533a72c..c46268a114078 100644
--- a/include/uapi/linux/can/bcm.h
+++ b/include/uapi/linux/can/bcm.h
@@ -86,7 +86,9 @@ enum {
TX_EXPIRED, /* notification on performed transmissions (count=0) */
RX_STATUS, /* reply to RX_READ request */
RX_TIMEOUT, /* cyclic message is absent */
- RX_CHANGED /* updated CAN frame (detected content change) */
+ RX_CHANGED, /* updated CAN frame (detected content change) */
+ RX_LIN_SETUP, /* create auto-response for LIN frame */
+ RX_LIN_DELETE, /* remove auto-response for LIN frame */
};
#define SETTIMER 0x0001
@@ -101,5 +103,6 @@ enum {
#define TX_RESET_MULTI_IDX 0x0200
#define RX_RTR_FRAME 0x0400
#define CAN_FD_FRAME 0x0800
+#define LIN_EVENT_FRAME 0x1000
#endif /* !_UAPI_CAN_BCM_H */
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 27d5fcf0eac9d..a717e594234d1 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -59,6 +59,7 @@
#include <linux/can/bcm.h>
#include <linux/slab.h>
#include <net/sock.h>
+#include <net/lin.h>
#include <net/net_namespace.h>
/*
@@ -1330,6 +1331,59 @@ static int bcm_tx_send(struct msghdr *msg, int ifindex, struct sock *sk,
return cfsiz + MHSIZ;
}
+static int bcm_lin_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
+ int ifindex, struct sock *sk, int cfsiz, int is_active)
+{
+ struct lin_responder_answer answ;
+ struct net_device *dev;
+ struct sk_buff *skb;
+ struct canfd_frame cf;
+ netdevice_tracker tracker;
+ size_t sz;
+ int ret;
+
+ if (msg_head->nframes > 1)
+ return -EINVAL;
+
+ if (!(msg_head->flags & CAN_FD_FRAME))
+ return -EINVAL;
+
+ ret = memcpy_from_msg(&cf, msg, cfsiz);
+ if (ret < 0)
+ return ret;
+
+ answ.lf.lin_id = cf.can_id & LIN_ID_MASK;
+ answ.is_active = is_active;
+ answ.is_event_frame = !!(msg_head->flags & LIN_EVENT_FRAME);
+ answ.event_associated_id = msg_head->can_id;
+ answ.lf.len = min(cf.len, LIN_MAX_DLEN);
+ memcpy(answ.lf.data, cf.data, answ.lf.len);
+ sz = min(sizeof(struct lin_responder_answer), sizeof(cf.data));
+ cf.can_id |= LIN_RXOFFLOAD_DATA_FLAG;
+ memcpy(cf.data, &answ, sz);
+
+ dev = netdev_get_by_index(sock_net(sk), ifindex, &tracker, GFP_KERNEL);
+ if (!dev)
+ return -ENODEV;
+
+ skb = alloc_skb(cfsiz + sizeof(struct can_skb_priv), gfp_any());
+ if (!skb)
+ goto lin_out;
+
+ can_skb_reserve(skb);
+ can_skb_prv(skb)->ifindex = dev->ifindex;
+ can_skb_prv(skb)->skbcnt = 0;
+ skb_put_data(skb, &cf, cfsiz);
+
+ skb->dev = dev;
+ can_skb_set_owner(skb, sk);
+ ret = can_send(skb, 1); /* send with loopback */
+
+lin_out:
+ netdev_put(dev, &tracker);
+ return ret;
+}
+
/*
* bcm_sendmsg - process BCM commands (opcodes) from the userspace
*/
@@ -1429,12 +1483,30 @@ static int bcm_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
case TX_SEND:
/* we need exactly one CAN frame behind the msg head */
- if ((msg_head.nframes != 1) || (size != cfsiz + MHSIZ))
+ if (msg_head.nframes != 1 || size != cfsiz + MHSIZ)
ret = -EINVAL;
else
ret = bcm_tx_send(msg, ifindex, sk, cfsiz);
break;
+ case RX_LIN_SETUP:
+ /* we need exactly one CAN frame behind the msg head */
+ if (msg_head.nframes != 1 || size != cfsiz + MHSIZ)
+ ret = -EINVAL;
+ else
+ ret = bcm_lin_setup(&msg_head, msg, ifindex, sk, cfsiz,
+ 1);
+ break;
+
+ case RX_LIN_DELETE:
+ /* we need exactly one CAN frame behind the msg head */
+ if (msg_head.nframes != 1 || size != cfsiz + MHSIZ)
+ ret = -EINVAL;
+ else
+ ret = bcm_lin_setup(&msg_head, msg, ifindex, sk, cfsiz,
+ 0);
+ break;
+
default:
ret = -EINVAL;
break;
--
2.39.2
^ permalink raw reply related
* [PATCH v3 07/11] can: Add support for serdev LIN adapters
From: Christoph Fritz @ 2024-05-02 18:28 UTC (permalink / raw)
To: Jiri Slaby, Oliver Hartkopp, Marc Kleine-Budde, Vincent Mailhol,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jiri Kosina,
Benjamin Tissoires, Greg Kroah-Hartman, Sebastian Reichel,
Linus Walleij
Cc: Andreas Lauser, Jonathan Corbet, Pavel Pisa, linux-can, netdev,
devicetree, linux-input, linux-serial
In-Reply-To: <20240502182804.145926-1-christoph.fritz@hexdev.de>
This commit introduces LIN-Bus support for UART devices equipped with
LIN transceivers, utilizing the Serial Device Bus (serdev) interface.
For more details on an adapter, visit: https://hexdev.de/hexlin#tty
Signed-off-by: Christoph Fritz <christoph.fritz@hexdev.de>
---
drivers/net/can/Kconfig | 16 ++
drivers/net/can/Makefile | 1 +
drivers/net/can/lin-serdev.c | 500 +++++++++++++++++++++++++++++++++++
3 files changed, 517 insertions(+)
create mode 100644 drivers/net/can/lin-serdev.c
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 0934bbf8d03b2..91c6cdeefe440 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -181,6 +181,22 @@ config CAN_LIN
Actual device drivers need to be enabled too.
+config CAN_LIN_SERDEV
+ tristate "Serial LIN Adaptors"
+ depends on CAN_LIN && SERIAL_DEV_BUS && OF
+ help
+ LIN-Bus support for serial devices equipped with LIN transceievers.
+ This device driver is using CAN_LIN for a userland connection on
+ one side and the kernel its serial device bus (serdev) interface
+ on the other side.
+
+ If you have a hexlin tty adapter, say Y here and see
+ <https://hexdev.de/hexlin#tty>.
+
+ This driver can also be built as a module. If so, the module will be
+ called lin-serdev.ko.
+
+
config CAN_SLCAN
tristate "Serial / USB serial CAN Adaptors (slcan)"
depends on TTY
diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
index 0093ee9219ca8..21ca514a42439 100644
--- a/drivers/net/can/Makefile
+++ b/drivers/net/can/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_CAN_IFI_CANFD) += ifi_canfd/
obj-$(CONFIG_CAN_JANZ_ICAN3) += janz-ican3.o
obj-$(CONFIG_CAN_KVASER_PCIEFD) += kvaser_pciefd.o
obj-$(CONFIG_CAN_LIN) += lin.o
+obj-$(CONFIG_CAN_LIN_SERDEV) += lin-serdev.o
obj-$(CONFIG_CAN_MSCAN) += mscan/
obj-$(CONFIG_CAN_M_CAN) += m_can/
obj-$(CONFIG_CAN_PEAK_PCIEFD) += peak_canfd/
diff --git a/drivers/net/can/lin-serdev.c b/drivers/net/can/lin-serdev.c
new file mode 100644
index 0000000000000..13fd9a54c6c93
--- /dev/null
+++ b/drivers/net/can/lin-serdev.c
@@ -0,0 +1,500 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2024 hexDEV GmbH - https://hexdev.de */
+
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/kfifo.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/serdev.h>
+#include <linux/slab.h>
+#include <linux/tty.h>
+#include <net/lin.h>
+
+#define LINSER_SAMPLES_PER_CHAR 10
+#define LINSER_TX_BUFFER_SIZE 11
+#define LINSER_RX_FIFO_SIZE 256
+#define LINSER_PARSE_BUFFER 24
+
+struct linser_rx {
+ u8 data;
+ u8 flag;
+};
+
+enum linser_rx_status {
+ NEED_MORE = -1,
+ MODE_OK = 0,
+ NEED_FORCE,
+};
+
+struct linser_priv {
+ struct lin_device *lin_dev;
+ struct serdev_device *serdev;
+ DECLARE_KFIFO_PTR(rx_fifo, struct linser_rx);
+ struct delayed_work rx_work;
+ unsigned long break_usleep_min;
+ unsigned long break_usleep_max;
+ unsigned long post_break_usleep_min;
+ unsigned long post_break_usleep_max;
+ unsigned long force_timeout_jfs;
+ struct lin_responder_answer respond_answ[LIN_NUM_IDS];
+ struct mutex resp_lock; /* protects respond_answ */
+ bool is_stopped;
+};
+
+static int linser_open(struct lin_device *ldev)
+{
+ struct serdev_device *serdev = to_serdev_device(ldev->dev);
+ struct linser_priv *priv = serdev_device_get_drvdata(serdev);
+ int ret;
+
+ if (priv->is_stopped) {
+ ret = serdev_device_open(serdev);
+ if (ret) {
+ dev_err(&serdev->dev, "Unable to open device\n");
+ return ret;
+ }
+
+ serdev_device_set_flow_control(serdev, false);
+ serdev_device_set_break_detection(serdev, true);
+
+ priv->is_stopped = false;
+ }
+
+ return 0;
+}
+
+static int linser_stop(struct lin_device *ldev)
+{
+ struct serdev_device *serdev = to_serdev_device(ldev->dev);
+ struct linser_priv *priv = serdev_device_get_drvdata(serdev);
+
+ if (priv->is_stopped)
+ return 0;
+
+ serdev_device_close(serdev);
+ priv->is_stopped = true;
+
+ return 0;
+}
+
+static int linser_send_break(struct linser_priv *priv)
+{
+ struct serdev_device *serdev = priv->serdev;
+ int ret;
+
+ ret = serdev_device_break_ctl(serdev, -1);
+ if (ret)
+ return ret;
+
+ usleep_range(priv->break_usleep_min, priv->break_usleep_max);
+
+ ret = serdev_device_break_ctl(serdev, 0);
+ if (ret)
+ return ret;
+
+ usleep_range(priv->post_break_usleep_min, priv->post_break_usleep_max);
+
+ return 0;
+}
+
+static int linser_ldo_tx(struct lin_device *ldev, const struct lin_frame *lf)
+{
+ struct serdev_device *serdev = to_serdev_device(ldev->dev);
+ struct linser_priv *priv = serdev_device_get_drvdata(serdev);
+ u8 pid = LIN_FORM_PID(lf->lin_id);
+ u8 buf[LINSER_TX_BUFFER_SIZE];
+ ssize_t written_len, total_len;
+ u8 checksum;
+ int ret;
+
+ if (lf->len + 3 > LINSER_TX_BUFFER_SIZE) {
+ dev_err(&serdev->dev, "Frame length %u exceeds buffer size\n", lf->len);
+ return -EINVAL;
+ }
+
+ buf[0] = LIN_SYNC_BYTE;
+ buf[1] = pid;
+ total_len = 2;
+
+ if (lf->len) {
+ memcpy(&buf[2], lf->data, lf->len);
+ checksum = lin_get_checksum(pid, lf->len, lf->data,
+ lf->checksum_mode);
+ buf[lf->len + 2] = checksum;
+ total_len += lf->len + 1;
+ }
+
+ ret = linser_send_break(priv);
+ if (ret)
+ return ret;
+
+ written_len = serdev_device_write(serdev, buf, total_len, 0);
+ if (written_len < total_len)
+ return written_len < 0 ? (int)written_len : -EIO;
+
+ dev_dbg(&serdev->dev, "sent out: %*ph\n", (int)total_len, buf);
+
+ serdev_device_wait_until_sent(serdev, 0);
+
+ return 0;
+}
+
+static void linser_derive_timings(struct linser_priv *priv, u16 bitrate)
+{
+ unsigned long break_baud = (bitrate * 2) / 3;
+ unsigned long timeout_us;
+
+ priv->break_usleep_min = (USEC_PER_SEC * LINSER_SAMPLES_PER_CHAR) /
+ break_baud;
+ priv->break_usleep_max = priv->break_usleep_min + 50;
+ priv->post_break_usleep_min = (USEC_PER_SEC * 1 /* 1 bit */) / break_baud;
+ priv->post_break_usleep_max = priv->post_break_usleep_min + 30;
+
+ timeout_us = DIV_ROUND_CLOSEST(USEC_PER_SEC * 256 /* bit */, bitrate);
+ priv->force_timeout_jfs = usecs_to_jiffies(timeout_us);
+}
+
+static int linser_update_bitrate(struct lin_device *ldev, u16 bitrate)
+{
+ struct serdev_device *serdev = to_serdev_device(ldev->dev);
+ struct linser_priv *priv = serdev_device_get_drvdata(serdev);
+ unsigned int speed;
+ int ret;
+
+ ret = linser_open(ldev);
+ if (ret)
+ return ret;
+
+ speed = serdev_device_set_baudrate(serdev, bitrate);
+ if (!bitrate || speed != bitrate)
+ return -EINVAL;
+
+ linser_derive_timings(priv, bitrate);
+
+ return 0;
+}
+
+static int linser_get_responder_answer(struct lin_device *ldev, u8 id,
+ struct lin_responder_answer *answ)
+{
+ struct serdev_device *serdev = to_serdev_device(ldev->dev);
+ struct linser_priv *priv = serdev_device_get_drvdata(serdev);
+ struct lin_responder_answer *r = &priv->respond_answ[id];
+
+ if (!answ)
+ return -EINVAL;
+
+ mutex_lock(&priv->resp_lock);
+ memcpy(answ, r, sizeof(struct lin_responder_answer));
+ mutex_unlock(&priv->resp_lock);
+
+ return 0;
+}
+
+static int linser_update_resp_answer(struct lin_device *ldev,
+ const struct lin_responder_answer *answ)
+{
+ struct serdev_device *serdev = to_serdev_device(ldev->dev);
+ struct linser_priv *priv = serdev_device_get_drvdata(serdev);
+ struct lin_responder_answer *r = &priv->respond_answ[answ->lf.lin_id];
+
+ if (!answ)
+ return -EINVAL;
+
+ mutex_lock(&priv->resp_lock);
+ memcpy(r, answ, sizeof(struct lin_responder_answer));
+ r->lf.checksum = lin_get_checksum(LIN_FORM_PID(answ->lf.lin_id),
+ answ->lf.len,
+ answ->lf.data,
+ answ->lf.checksum_mode);
+ mutex_unlock(&priv->resp_lock);
+
+ return 0;
+}
+
+static struct lin_device_ops linser_lindev_ops = {
+ .ldo_open = linser_open,
+ .ldo_stop = linser_stop,
+ .ldo_tx = linser_ldo_tx,
+ .update_bitrate = linser_update_bitrate,
+ .get_responder_answer = linser_get_responder_answer,
+ .update_responder_answer = linser_update_resp_answer,
+};
+
+static bool linser_tx_frame_as_responder(struct linser_priv *priv, u8 id)
+{
+ struct lin_responder_answer *answ = &priv->respond_answ[id];
+ struct serdev_device *serdev = priv->serdev;
+ u8 buf[LINSER_TX_BUFFER_SIZE];
+ u8 checksum, count, n;
+ ssize_t write_len;
+
+ mutex_lock(&priv->resp_lock);
+
+ if (!answ->is_active) {
+ mutex_unlock(&priv->resp_lock);
+ return false;
+ }
+
+ if (answ->is_event_frame) {
+ struct lin_responder_answer *e_answ;
+
+ e_answ = &priv->respond_answ[answ->event_associated_id];
+ n = min(e_answ->lf.len, LIN_MAX_DLEN);
+ if (memcmp(answ->lf.data, e_answ->lf.data, n) != 0) {
+ memcpy(answ->lf.data, e_answ->lf.data, n);
+ checksum = lin_get_checksum(LIN_FORM_PID(answ->lf.lin_id),
+ n, e_answ->lf.data,
+ answ->lf.checksum_mode);
+ answ = e_answ;
+ } else {
+ mutex_unlock(&priv->resp_lock);
+ return false;
+ }
+ } else {
+ checksum = answ->lf.checksum;
+ }
+
+ count = min(answ->lf.len, LIN_MAX_DLEN);
+ memcpy(&buf[0], answ->lf.data, count);
+ buf[count] = checksum;
+
+ mutex_unlock(&priv->resp_lock);
+
+ write_len = serdev_device_write(serdev, buf, count + 1, 0);
+ if (write_len < count + 1)
+ return false;
+
+ serdev_device_wait_until_sent(serdev, 0);
+
+ return true;
+}
+
+static void linser_pop_fifo(struct linser_priv *priv, size_t n)
+{
+ for (size_t i = 0; i < n; i++)
+ kfifo_skip(&priv->rx_fifo);
+}
+
+static int linser_fill_frame(struct linser_priv *priv, struct lin_frame *lf)
+{
+ struct serdev_device *serdev = priv->serdev;
+ struct linser_rx buf[LINSER_PARSE_BUFFER];
+ unsigned int count, i, brk = 0;
+
+ count = kfifo_out_peek(&priv->rx_fifo, buf, LINSER_PARSE_BUFFER);
+
+ memset(lf, 0, sizeof(struct lin_frame));
+
+ for (i = 0; i < count; i++) {
+ dev_dbg(&serdev->dev, "buf[%d]: data=%02x, flag=%02x\n",
+ i, buf[i].data, buf[i].flag);
+ }
+
+ if (count < 3)
+ return NEED_MORE;
+
+ if (buf[0].flag != TTY_BREAK || buf[1].data != LIN_SYNC_BYTE) {
+ linser_pop_fifo(priv, 1); /* pop incorrect start */
+ return NEED_MORE;
+ } else if (!LIN_CHECK_PID(buf[2].data)) {
+ linser_pop_fifo(priv, 3); /* pop incorrect header */
+ return NEED_MORE;
+ }
+
+ lf->lin_id = LIN_GET_ID(buf[2].data);
+
+ /* from here on we do have a correct LIN header */
+
+ if (count == 3)
+ return linser_tx_frame_as_responder(priv, lf->lin_id) ?
+ NEED_MORE : NEED_FORCE;
+
+ for (i = 3; i < count && i < LINSER_PARSE_BUFFER && i < 12; i++) {
+ if (buf[i].flag == TTY_BREAK) {
+ brk = i;
+ break;
+ }
+ lf->len++;
+ }
+ if (lf->len)
+ lf->len -= 1; /* account for checksum */
+
+ if (brk == 3)
+ return MODE_OK;
+
+ if (brk == 4) {
+ /* suppress wrong answer data-byte in between PID and break
+ * because checksum is missing
+ */
+ return MODE_OK;
+ }
+
+ for (i = 0; i < lf->len; i++)
+ lf->data[i] = buf[3 + i].data;
+ lf->checksum = buf[2 + lf->len + 1].data;
+ mutex_lock(&priv->resp_lock);
+ lf->checksum_mode = priv->respond_answ[lf->lin_id].lf.checksum_mode;
+ mutex_unlock(&priv->resp_lock);
+
+ dev_dbg(&serdev->dev, "brk:%i, len:%u, data:%*ph, checksum:%x (%s)\n",
+ brk, lf->len, lf->len, lf->data, lf->checksum,
+ lf->checksum_mode ? "enhanced" : "classic");
+
+ if (brk > 4)
+ return MODE_OK; /* frame in between two breaks: so complete */
+
+ if (lf->len == 8)
+ return MODE_OK;
+
+ return NEED_FORCE;
+}
+
+static int linser_process_frame(struct linser_priv *priv, bool force)
+{
+ struct serdev_device *serdev = priv->serdev;
+ struct lin_frame lf;
+ size_t bytes_to_pop;
+ int ret = NEED_MORE;
+
+ while (kfifo_len(&priv->rx_fifo) >= LIN_HEADER_SIZE) {
+ ret = linser_fill_frame(priv, &lf);
+
+ if (ret == MODE_OK || (ret == NEED_FORCE && force)) {
+ dev_dbg(&serdev->dev, "lin_rx: %s\n",
+ force ? "force" : "normal");
+ lin_rx(priv->lin_dev, &lf);
+ bytes_to_pop = LIN_HEADER_SIZE + lf.len +
+ (lf.len ? 1 : 0);
+ linser_pop_fifo(priv, bytes_to_pop);
+ force = false;
+ ret = MODE_OK;
+ } else {
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+static void linser_process_delayed(struct work_struct *work)
+{
+ struct linser_priv *priv = container_of(work, struct linser_priv,
+ rx_work.work);
+
+ linser_process_frame(priv, true);
+}
+
+static ssize_t linser_receive_buf_fp(struct serdev_device *serdev,
+ const u8 *data, const u8 *fp,
+ size_t count)
+{
+ struct linser_priv *priv = serdev_device_get_drvdata(serdev);
+ enum linser_rx_status rx_status;
+ ssize_t n = 0;
+ int i;
+
+ cancel_delayed_work_sync(&priv->rx_work);
+
+ for (i = 0; i < count; i++) {
+ struct linser_rx rx;
+
+ rx.data = data[i];
+ rx.flag = (fp ? fp[i] : 0);
+ n += kfifo_in(&priv->rx_fifo, &rx, 1);
+ dev_dbg(&serdev->dev, "%s: n:%zd, flag:0x%02x, data:0x%02x\n",
+ __func__, n, rx.flag, data[i]);
+ }
+
+ rx_status = linser_process_frame(priv, false);
+
+ if (rx_status == NEED_FORCE)
+ schedule_delayed_work(&priv->rx_work, priv->force_timeout_jfs);
+
+ return n;
+}
+
+static const struct serdev_device_ops linser_ops = {
+ .receive_buf_fp = linser_receive_buf_fp,
+ .write_wakeup = serdev_device_write_wakeup,
+};
+
+static int linser_probe(struct serdev_device *serdev)
+{
+ struct linser_priv *priv;
+ int ret;
+
+ priv = devm_kzalloc(&serdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ ret = kfifo_alloc(&priv->rx_fifo, LINSER_RX_FIFO_SIZE, GFP_KERNEL);
+ if (ret)
+ return ret;
+
+ INIT_DELAYED_WORK(&priv->rx_work, linser_process_delayed);
+
+ priv->serdev = serdev;
+ serdev_device_set_drvdata(serdev, priv);
+ serdev_device_set_client_ops(serdev, &linser_ops);
+
+ ret = serdev_device_open(serdev);
+ if (ret) {
+ dev_err(&serdev->dev, "Unable to open device\n");
+ goto err_open;
+ }
+
+ serdev_device_set_flow_control(serdev, false);
+ serdev_device_set_break_detection(serdev, true);
+ linser_derive_timings(priv, LIN_DEFAULT_BAUDRATE);
+
+ mutex_init(&priv->resp_lock);
+
+ priv->lin_dev = register_lin(&serdev->dev, &linser_lindev_ops);
+ if (IS_ERR_OR_NULL(priv->lin_dev)) {
+ ret = PTR_ERR(priv->lin_dev);
+ goto err_register_lin;
+ }
+
+ serdev_device_close(serdev);
+ priv->is_stopped = true;
+
+ return 0;
+
+err_register_lin:
+ serdev_device_close(serdev);
+err_open:
+ kfifo_free(&priv->rx_fifo);
+ return ret;
+}
+
+static void linser_remove(struct serdev_device *serdev)
+{
+ struct linser_priv *priv = serdev_device_get_drvdata(serdev);
+
+ unregister_lin(priv->lin_dev);
+}
+
+static const struct of_device_id linser_of_match[] = {
+ {
+ .compatible = "hexdev,lin-serdev",
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(of, linser_of_match);
+
+static struct serdev_device_driver linser_driver = {
+ .probe = linser_probe,
+ .remove = linser_remove,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = linser_of_match,
+ }
+};
+
+module_serdev_device_driver(linser_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Christoph Fritz <christoph.fritz@hexdev.de>");
+MODULE_DESCRIPTION("LIN-Bus serdev driver");
--
2.39.2
^ permalink raw reply related
* [PATCH v3 06/11] dt-bindings: net/can: Add serial (serdev) LIN adapter
From: Christoph Fritz @ 2024-05-02 18:27 UTC (permalink / raw)
To: Jiri Slaby, Oliver Hartkopp, Marc Kleine-Budde, Vincent Mailhol,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jiri Kosina,
Benjamin Tissoires, Greg Kroah-Hartman, Sebastian Reichel,
Linus Walleij
Cc: Andreas Lauser, Jonathan Corbet, Pavel Pisa, linux-can, netdev,
devicetree, linux-input, linux-serial
In-Reply-To: <20240502182804.145926-1-christoph.fritz@hexdev.de>
Add dt-bindings for serial LIN bus adapters. These adapters are
basically just LIN transceivers that are hard-wired to serial devices.
Signed-off-by: Christoph Fritz <christoph.fritz@hexdev.de>
---
.../bindings/net/can/hexdev,lin-serdev.yaml | 32 +++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/can/hexdev,lin-serdev.yaml
diff --git a/Documentation/devicetree/bindings/net/can/hexdev,lin-serdev.yaml b/Documentation/devicetree/bindings/net/can/hexdev,lin-serdev.yaml
new file mode 100644
index 0000000000000..c178eb9be1391
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/hexdev,lin-serdev.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/can/hexdev,lin-serdev.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Serial LIN Adapter
+
+description:
+ LIN transceiver, mostly hard-wired to a serial device, used for communication
+ on a LIN bus.
+ For more details on an adapter, visit <https://hexdev.de/hexlin#tty>.
+
+maintainers:
+ - Christoph Fritz <christoph.fritz@hexdev.de>
+
+properties:
+ compatible:
+ const: hexdev,lin-serdev
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ serial {
+ linbus {
+ compatible = "hexdev,lin-serdev";
+ };
+ };
--
2.39.2
^ permalink raw reply related
* [PATCH v3 05/11] dt-bindings: vendor-prefixes: Add hexDEV
From: Christoph Fritz @ 2024-05-02 18:27 UTC (permalink / raw)
To: Jiri Slaby, Oliver Hartkopp, Marc Kleine-Budde, Vincent Mailhol,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jiri Kosina,
Benjamin Tissoires, Greg Kroah-Hartman, Sebastian Reichel,
Linus Walleij
Cc: Andreas Lauser, Jonathan Corbet, Pavel Pisa, linux-can, netdev,
devicetree, linux-input, linux-serial
In-Reply-To: <20240502182804.145926-1-christoph.fritz@hexdev.de>
Add vendor prefix for hexDEV GmbH. Website: https://hexdev.de
Signed-off-by: Christoph Fritz <christoph.fritz@hexdev.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 08b241825f8b6..1a8cfc5c7350d 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -601,6 +601,8 @@ patternProperties:
description: Hardkernel Co., Ltd
"^hechuang,.*":
description: Shenzhen Hechuang Intelligent Co.
+ "^hexdev,.*":
+ description: hexDEV GmbH
"^hideep,.*":
description: HiDeep Inc.
"^himax,.*":
--
2.39.2
^ permalink raw reply related
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