* [PATCH v2 1/4] dt-bindings: input: Add Himax HX83102J touchscreen
From: Allen_Lin @ 2024-04-02 10:49 UTC (permalink / raw)
To: dmitry.torokhov, robh, krzysztof.kozlowski+dt, conor, jikos,
benjamin.tissoires, linux-input, devicetree, linux-kernel
Cc: Allen_Lin
In-Reply-To: <20240402104930.1053016-1-allencl_lin@hotmail.com>
Add the HX83102j touchscreen device tree bindings documents.
HX83102j is a Himax TDDI touchscreen controller.
It's power sequence should be bound with a lcm driver, thus it
needs to be a panel follower. Others are the same as normal SPI
touchscreen controller.
Signed-off-by: Allen_Lin <allencl_lin@hotmail.com>
---
.../input/touchscreen/himax,hx83102j.yaml | 100 ++++++++++++++++++
MAINTAINERS | 6 ++
2 files changed, 106 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml b/Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml
new file mode 100644
index 000000000000..fe79129f704a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/himax,hx83102j.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax hx83102j touchscreen
+
+maintainers:
+ - Allen Lin <allencl_lin@hotmail.com>
+
+description:
+ This Himax hx83102j touchscreen uses the spi protocol.
+
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: himax,hx83102j
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ vccd-supply:
+ description: A phandle for the regualtor supplying IO power.
+
+ vsn-supply:
+ description: Negative supply regulator.
+
+ vsp-supply:
+ description: Positive supply regulator.
+
+ ddreset-gpios:
+ description: A phandle of gpio for display reset controlled by the LCD driver.
+ This is the master reset, if this reset is triggered, the TP reset will
+ also be triggered.
+
+ spi-cpha: true
+
+ spi-cpol: true
+
+ spi-max-frequency: true
+
+ panel: true
+
+ himax,firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Specify the file name for firmware loading.
+
+ himax,pid:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ PID for HID device, used to validate firmware.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - reset-gpios
+ - panel
+ - vccd-supply
+ - vsn-supply
+ - vsp-supply
+ - ddreset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ap_ts: touchscreen@0 {
+ compatible = "himax,hx83102j";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&touch_int0 &touch_reset>;
+ reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
+ spi-cpha;
+ spi-cpol;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ panel = <&panel>;
+ vccd-supply = <®ulator>;
+ vsn-supply = <®ulator>;
+ vsp-supply = <®ulator>;
+ ddreset-gpios = <&gpio1>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 43b39956694a..aa51c60fd66d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9669,6 +9669,12 @@ L: linux-kernel@vger.kernel.org
S: Maintained
F: drivers/misc/hisi_hikey_usb.c
+HIMAX HID HX83102J TOUCHSCREEN
+M: Allen Lin <allencl_lin@hotmail.com>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml
+
HIMAX HX83112B TOUCHSCREEN SUPPORT
M: Job Noorman <job@noorman.info>
L: linux-input@vger.kernel.org
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/4] HID: Add support for Himax HX83102j touchscreen
From: Allen_Lin @ 2024-04-02 10:49 UTC (permalink / raw)
To: dmitry.torokhov, robh, krzysztof.kozlowski+dt, conor, jikos,
benjamin.tissoires, linux-input, devicetree, linux-kernel
Cc: Allen_Lin
Hi,
This driver implements for Himax HID touchscreen HX83102j.
Using SPI interface to receive/send HID packets.
Changes in v2 :
-Added power description in YAML document.
-Added ddreset-gpios property in YAML document.
-Added firmware-name property in YAML document.
-Modified the description of pid.
-Modified the example.
Allen_Lin (4):
dt-bindings: input: Add Himax HX83102J touchscreen
HID: Add Himax HX83102J touchscreen driver
HID: Add DRM panel follower function
HID: Load firmware directly from file to IC
.../input/touchscreen/himax,hx83102j.yaml | 100 +
MAINTAINERS | 7 +
drivers/hid/Kconfig | 7 +
drivers/hid/Makefile | 2 +
drivers/hid/hid-himax-83102j.c | 3071 +++++++++++++++++
drivers/hid/hid-himax-83102j.h | 460 +++
6 files changed, 3647 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml
create mode 100644 drivers/hid/hid-himax-83102j.c
create mode 100644 drivers/hid/hid-himax-83102j.h
--
2.34.1
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Russell King (Oracle) @ 2024-04-02 10:15 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <ZgvaFNLTqgQrPeiO@shell.armlinux.org.uk>
On Tue, Apr 02, 2024 at 11:12:36AM +0100, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 12:04:07PM +0200, Krzysztof Kozlowski wrote:
> > You brought no argument for keeping the kernel-version-header
> > requirement nowadays, yet you call me of not working constructively. I
>
> So add inability to read to your failings, because I _did_ state that
> _I_ still _use_ it.
>
> End of discussion, I'm not engaging with you in your current
> confrontational mood where you clearly don't want to understand
> anything (or intentionally misinterpreting) I'm writing - making it
> pointless to continue.
>
> I even think you're intentionally misinterpreting the responses
> from the patch system.
>
> Overall, I can only draw the conclusion that you are playing politics
> and want the patch system gone, and you want me to use "standard"
> tooling that will _increase_ the amount of effort I need to put in.
> No, that's not going to happen.
... and this is your final chance to change to a constructive discourse,
if not, you are going to end up in my kill file. Whether you do is
entirely up to the tone of your reply to this email.
I am always more than willing to work with a submitter to diagnose
what the problem is, but the tone of your emails make me want to
ignore you.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Russell King (Oracle) @ 2024-04-02 10:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <65f0ed39-4c2f-4cea-b488-2a8ba6fdbeff@linaro.org>
On Tue, Apr 02, 2024 at 12:04:07PM +0200, Krzysztof Kozlowski wrote:
> You brought no argument for keeping the kernel-version-header
> requirement nowadays, yet you call me of not working constructively. I
So add inability to read to your failings, because I _did_ state that
_I_ still _use_ it.
End of discussion, I'm not engaging with you in your current
confrontational mood where you clearly don't want to understand
anything (or intentionally misinterpreting) I'm writing - making it
pointless to continue.
I even think you're intentionally misinterpreting the responses
from the patch system.
Overall, I can only draw the conclusion that you are playing politics
and want the patch system gone, and you want me to use "standard"
tooling that will _increase_ the amount of effort I need to put in.
No, that's not going to happen.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-04-02 10:04 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <ZgvWfhSEYIUaIn6h@shell.armlinux.org.uk>
On 02/04/2024 11:57, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 11:48:08AM +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 10:56, Russell King (Oracle) wrote:
>>> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>>>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>>>> Merging
>>>>> =======
>>>>> All further patches depend on the first amba patch, therefore please ack
>>>>> and this should go via one tree.
>>>>>
>>>>> Description
>>>>> ===========
>>>>> Modules registering driver with amba_driver_register() often forget to
>>>>> set .owner field.
>>>>>
>>>>> Solve the problem by moving this task away from the drivers to the core
>>>>> amba bus code, just like we did for platform_driver in commit
>>>>> 9447057eaff8 ("platform_device: use a macro instead of
>>>>> platform_driver_register").
>>>>>
>>>>> Best regards,
>>>>
>>>> I tried to submit this series to Russell patch tracker and failed. This
>>>> is ridiculous. It's 2024 and instead of normal process, like every other
>>>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>>>> standard patches.
>>>
>>> Sorry but no. Stop being offensive.
>>>
>>>> First, it depends some weird, duplicated signed-off-by's.
>>>
>>> Eh? There is no such logic in there.
>>
>> In the web system there is - read the error message I pasted. It wants
>> another SoB from the unrelated email account, the one used purely for
>> registering in some web system, not the one used for code handling.
>
> So you're disagreeing with the author of this system. Of course you
> know best, you know the code behind it. I have only one word for
> that kind of attitude: idiotic.
I pasted you the error which the system reported to me.
>
>>>> Second it > submitting patch-by-patch, all with clicking on some web
>>>> (!!!) interface.
>>>
>>> Again, no it doesn't, and you're just throwing crap out because you
>>> failed. Unlike most of the "normal" processes, the patch system allows
>>> you to submit both by *email* and also by *web* for those cases where
>>
>> The email one requires additional steps, so this is unnecessary work
>> confusing submitters. I submit dozens or hundreds of patches every
>> release cycle. That's the only subsystem which is odd to use.
>
> Lots of people use it without issue. People even send patches to the
> mailing list copied to the patch system.
>
I will try that.
>>> the emails get screwed up by ones company mail server. That's why the
>>> web interface exists - to give people *flexibility*.
>>
>> No, they are not. None of my emails are screwed by my company system.
>
> So why are you using the web interface?
>
>>> Why does it want the kernel version? Because when we were running 2.4
>>> and 2.5 kernel versions in parallel, it was important to know which
>>> tree the patch was being submitted for. It has continued to be required
>>
>> Which is absolutely ridiculous now. Expecting submitters to adhere to
>> some rule for 20 year old kernel is not reasonable.
>
> You aren't listening to me, so it's pointless discussing this further.
> You have a bee in your bonet and you want to make it a huge issue
Well, all my comments were about the actual topic - patch submission
process made for ARM subsystem by you. Your replies include comments
about me and what do I have in my bonet.
You brought no argument for keeping the kernel-version-header
requirement nowadays, yet you call me of not working constructively. I
brought that argument - it is redundant and it is an obstacle for the
contributor.
> rather than work constructively. Sorry but no, I'm not going to continue
> this confrontational exchange.
>
> You clearly don't want to understand anything.
I understood a lot, although I did not answer under every point "I
understand this part, I disagree here".
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Russell King (Oracle) @ 2024-04-02 9:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <324e9c02-c005-4e18-9872-8408695fb1fe@linaro.org>
On Tue, Apr 02, 2024 at 11:48:08AM +0200, Krzysztof Kozlowski wrote:
> On 02/04/2024 10:56, Russell King (Oracle) wrote:
> > On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
> >> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> >>> Merging
> >>> =======
> >>> All further patches depend on the first amba patch, therefore please ack
> >>> and this should go via one tree.
> >>>
> >>> Description
> >>> ===========
> >>> Modules registering driver with amba_driver_register() often forget to
> >>> set .owner field.
> >>>
> >>> Solve the problem by moving this task away from the drivers to the core
> >>> amba bus code, just like we did for platform_driver in commit
> >>> 9447057eaff8 ("platform_device: use a macro instead of
> >>> platform_driver_register").
> >>>
> >>> Best regards,
> >>
> >> I tried to submit this series to Russell patch tracker and failed. This
> >> is ridiculous. It's 2024 and instead of normal process, like every other
> >> maintainer, so b4 or Patchwork, we have some unusable system rejecting
> >> standard patches.
> >
> > Sorry but no. Stop being offensive.
> >
> >> First, it depends some weird, duplicated signed-off-by's.
> >
> > Eh? There is no such logic in there.
>
> In the web system there is - read the error message I pasted. It wants
> another SoB from the unrelated email account, the one used purely for
> registering in some web system, not the one used for code handling.
So you're disagreeing with the author of this system. Of course you
know best, you know the code behind it. I have only one word for
that kind of attitude: idiotic.
> >> Second it > submitting patch-by-patch, all with clicking on some web
> >> (!!!) interface.
> >
> > Again, no it doesn't, and you're just throwing crap out because you
> > failed. Unlike most of the "normal" processes, the patch system allows
> > you to submit both by *email* and also by *web* for those cases where
>
> The email one requires additional steps, so this is unnecessary work
> confusing submitters. I submit dozens or hundreds of patches every
> release cycle. That's the only subsystem which is odd to use.
Lots of people use it without issue. People even send patches to the
mailing list copied to the patch system.
> > the emails get screwed up by ones company mail server. That's why the
> > web interface exists - to give people *flexibility*.
>
> No, they are not. None of my emails are screwed by my company system.
So why are you using the web interface?
> > Why does it want the kernel version? Because when we were running 2.4
> > and 2.5 kernel versions in parallel, it was important to know which
> > tree the patch was being submitted for. It has continued to be required
>
> Which is absolutely ridiculous now. Expecting submitters to adhere to
> some rule for 20 year old kernel is not reasonable.
You aren't listening to me, so it's pointless discussing this further.
You have a bee in your bonet and you want to make it a huge issue
rather than work constructively. Sorry but no, I'm not going to continue
this confrontational exchange.
You clearly don't want to understand anything.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-04-02 9:57 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <ZgvKh/Cwudh3gCDr@shell.armlinux.org.uk>
On 02/04/2024 11:06, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 09:56:17AM +0100, Russell King (Oracle) wrote:
>> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>>
>>>> Description
>>>> ===========
>>>> Modules registering driver with amba_driver_register() often forget to
>>>> set .owner field.
>>>>
>>>> Solve the problem by moving this task away from the drivers to the core
>>>> amba bus code, just like we did for platform_driver in commit
>>>> 9447057eaff8 ("platform_device: use a macro instead of
>>>> platform_driver_register").
>>>>
>>>> Best regards,
>>>
>>> I tried to submit this series to Russell patch tracker and failed. This
>>> is ridiculous. It's 2024 and instead of normal process, like every other
>>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>>> standard patches.
>>
>> Sorry but no. Stop being offensive.
>>
>>> First, it depends some weird, duplicated signed-off-by's.
>>
>> Eh? There is no such logic in there.
>>
>>> Second it > submitting patch-by-patch, all with clicking on some web
>>> (!!!) interface.
>>
>> Again, no it doesn't, and you're just throwing crap out because you
>> failed. Unlike most of the "normal" processes, the patch system allows
>> you to submit both by *email* and also by *web* for those cases where
>> the emails get screwed up by ones company mail server. That's why the
>> web interface exists - to give people *flexibility*.
>>
>> The fact is, the web interface is merely a front end interface that
>> generates an email and submits it in the usual way by email - an
>> email that you can perfectly well generate that is *very* close to
>> the standard email that git format-patch generates.
>>
>> The *only* difference is that the patch system wants a KernelVersion:
>> tag in the email _somewhere_ and it doesn't matter where it appears.
>> Git even has support to do this.
>>
>> git format-patch --add-header="KernelVersion: $foo"
>>
>> Why does it want the kernel version? Because when we were running 2.4
>> and 2.5 kernel versions in parallel, it was important to know which
>> tree the patch was being submitted for. It has continued to be required
>> because it means when there's problems applying a patch, it gives me
>> the additional information about the base used for the patch (and it
>> keeps on being useful to have.)
>>
>>> That's the response:
>>> -------------
>>> Your patch has not been logged because:
>>>
>>> Error: Please supply a summary subject line briefly describing
>>> your patch.
>>>
>>>
>>> Error: Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
>>> "---".
>>>
>>> Error: the patch you are submitting has one or more missing or incorrect
>>> Signed-off-by lines:
>>>
>>> - author signoff <krzkreg@gmail.com> is missing.
>>>
>>> Please see the file Documentation/SubmittingPatches, section 11
>>> for details on signing off patches.
>>
>> Lots of people use it without a problem. I've just run the parser
>> through its offline tests, and it parses email content correctly.
>> I've no idea what you're doing wrong, but it looks like something
>> pretty serious if it didn't parse the subject line.
>>
>> Rather than getting stressed about it, why don't you send me an email
>> the first time something goes wrong so I can investigate, turn on
>> debugging to capture the problem email?
>
> ... and I'll also point out one of the biggest problems is people.
> People who think it's more complex than it is, or who can't read
> instructions.
We all read submitting-patches instructions (and many more). A need to
learn one more set of instructions for one more process leads to people
needing to learn 100 different processes for 100 different subsystems.
That's not the way how people should be contributing to Linux kernel.
>
> For example, trying to tell people to use the standard format subject
> line:
>
> [PATCH ...] blah
>
> has proven to be hopeless - unless one states to them the exact
> sequence of keys on their keyboard to press - yes, it *really* takes
> that patronising level to get everyone to understand. If one tries to
> do it any other way, then you get stuff like:
>
> "[PATCH ...] ..."
>
> with the quotes. Or some other stupid variation.
>
> The patch system is as forgiving as possible. It takes standard git
> formatted patches (with the exception of wanting an additional tag).
The additional tag about kernel version is redundant and not helping
anyone. I doubt you apply patches on top of linux-next or top of
previous release (e.g. v6.8-rc1). Almost every maintainer applies on top
of current RC, so v6.9-rc1 currently, thus version is just unnecessary
obstacle.
>
> It is possible that bugs creep in - particularly when Debian updates
> get applied and change the way Perl works, but I don't think that's
> what has happened with your situation.
>
> I _guess_ you're putting the entire email-like output from git
> format-patch as the patch file. That won't work - that isn't a "patch
> file", that is an email/email template, and the patch system will
> attempt to parse that as the patch itself.
Yes, that's what every sane person's workflow is. git format-patch -19
(cover letter goes from branch description).
>
> I suppose you term "patch" to be the email as well, rather than what
> I interpret it to be, which is only the output of "diff" - call me
> old fashioned but that's what a patch file used to be before the
> waters got muddied by git "patch files".
Well, world is now using git as a standard. It's true there is quilt out
there, but even Andrew I think is going slowly towards git in some parts
of his workflow.
But then even Andrew accepted standard patch from the mailing lists. No
need for any other step, no need for any double submission (one public,
second to patches@armlinux or webform) with any other requirement.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-04-02 9:48 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <ZgvIMRDfeQaeVxYt@shell.armlinux.org.uk>
On 02/04/2024 10:56, Russell King (Oracle) wrote:
> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>> Merging
>>> =======
>>> All further patches depend on the first amba patch, therefore please ack
>>> and this should go via one tree.
>>>
>>> Description
>>> ===========
>>> Modules registering driver with amba_driver_register() often forget to
>>> set .owner field.
>>>
>>> Solve the problem by moving this task away from the drivers to the core
>>> amba bus code, just like we did for platform_driver in commit
>>> 9447057eaff8 ("platform_device: use a macro instead of
>>> platform_driver_register").
>>>
>>> Best regards,
>>
>> I tried to submit this series to Russell patch tracker and failed. This
>> is ridiculous. It's 2024 and instead of normal process, like every other
>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>> standard patches.
>
> Sorry but no. Stop being offensive.
>
>> First, it depends some weird, duplicated signed-off-by's.
>
> Eh? There is no such logic in there.
In the web system there is - read the error message I pasted. It wants
another SoB from the unrelated email account, the one used purely for
registering in some web system, not the one used for code handling.
>
>> Second it > submitting patch-by-patch, all with clicking on some web
>> (!!!) interface.
>
> Again, no it doesn't, and you're just throwing crap out because you
> failed. Unlike most of the "normal" processes, the patch system allows
> you to submit both by *email* and also by *web* for those cases where
The email one requires additional steps, so this is unnecessary work
confusing submitters. I submit dozens or hundreds of patches every
release cycle. That's the only subsystem which is odd to use.
> the emails get screwed up by ones company mail server. That's why the
> web interface exists - to give people *flexibility*.
No, they are not. None of my emails are screwed by my company system.
>
> The fact is, the web interface is merely a front end interface that
> generates an email and submits it in the usual way by email - an
> email that you can perfectly well generate that is *very* close to
> the standard email that git format-patch generates.
>
> The *only* difference is that the patch system wants a KernelVersion:
> tag in the email _somewhere_ and it doesn't matter where it appears.
> Git even has support to do this.
>
> git format-patch --add-header="KernelVersion: $foo"
>
> Why does it want the kernel version? Because when we were running 2.4
> and 2.5 kernel versions in parallel, it was important to know which
> tree the patch was being submitted for. It has continued to be required
Which is absolutely ridiculous now. Expecting submitters to adhere to
some rule for 20 year old kernel is not reasonable.
> because it means when there's problems applying a patch, it gives me
> the additional information about the base used for the patch (and it
> keeps on being useful to have.)
>
>> That's the response:
>> -------------
>> Your patch has not been logged because:
>>
>> Error: Please supply a summary subject line briefly describing
>> your patch.
>>
>>
>> Error: Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
>> "---".
>>
>> Error: the patch you are submitting has one or more missing or incorrect
>> Signed-off-by lines:
>>
>> - author signoff <krzkreg@gmail.com> is missing.
^^^ here you have additional SoB expectation.
>>
>> Please see the file Documentation/SubmittingPatches, section 11
>> for details on signing off patches.
>
> Lots of people use it without a problem. I've just run the parser
> through its offline tests, and it parses email content correctly.
> I've no idea what you're doing wrong, but it looks like something
> pretty serious if it didn't parse the subject line.
>
> Rather than getting stressed about it, why don't you send me an email
> the first time something goes wrong so I can investigate, turn on
> debugging to capture the problem email?
I don't know any person who enjoyed working with your patch workflow.
From few people I talked, it was always "now I have to learn this weird
system" or "I need to get through this process which is different than
everything in the kernel".
Plus you entirely ignored poor usability of this system which:
1. Allows submitting patches only 1-by-1, so 19 useless steps in my case.
2. Accepts the first/second/all patches without problem encouraging me
to submit the rest... and then tells me via email they were wrong and
could not be accepted.
This is the poorest user-experience one can imagine. If you put effort
into some web form, make it at least helpful so reject the patch if it
does not match your expectations.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Russell King (Oracle) @ 2024-04-02 9:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <ZgvIMRDfeQaeVxYt@shell.armlinux.org.uk>
On Tue, Apr 02, 2024 at 09:56:17AM +0100, Russell King (Oracle) wrote:
> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
> > On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> > > Merging
> > > =======
> > > All further patches depend on the first amba patch, therefore please ack
> > > and this should go via one tree.
> > >
> > > Description
> > > ===========
> > > Modules registering driver with amba_driver_register() often forget to
> > > set .owner field.
> > >
> > > Solve the problem by moving this task away from the drivers to the core
> > > amba bus code, just like we did for platform_driver in commit
> > > 9447057eaff8 ("platform_device: use a macro instead of
> > > platform_driver_register").
> > >
> > > Best regards,
> >
> > I tried to submit this series to Russell patch tracker and failed. This
> > is ridiculous. It's 2024 and instead of normal process, like every other
> > maintainer, so b4 or Patchwork, we have some unusable system rejecting
> > standard patches.
>
> Sorry but no. Stop being offensive.
>
> > First, it depends some weird, duplicated signed-off-by's.
>
> Eh? There is no such logic in there.
>
> > Second it > submitting patch-by-patch, all with clicking on some web
> > (!!!) interface.
>
> Again, no it doesn't, and you're just throwing crap out because you
> failed. Unlike most of the "normal" processes, the patch system allows
> you to submit both by *email* and also by *web* for those cases where
> the emails get screwed up by ones company mail server. That's why the
> web interface exists - to give people *flexibility*.
>
> The fact is, the web interface is merely a front end interface that
> generates an email and submits it in the usual way by email - an
> email that you can perfectly well generate that is *very* close to
> the standard email that git format-patch generates.
>
> The *only* difference is that the patch system wants a KernelVersion:
> tag in the email _somewhere_ and it doesn't matter where it appears.
> Git even has support to do this.
>
> git format-patch --add-header="KernelVersion: $foo"
>
> Why does it want the kernel version? Because when we were running 2.4
> and 2.5 kernel versions in parallel, it was important to know which
> tree the patch was being submitted for. It has continued to be required
> because it means when there's problems applying a patch, it gives me
> the additional information about the base used for the patch (and it
> keeps on being useful to have.)
>
> > That's the response:
> > -------------
> > Your patch has not been logged because:
> >
> > Error: Please supply a summary subject line briefly describing
> > your patch.
> >
> >
> > Error: Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
> > "---".
> >
> > Error: the patch you are submitting has one or more missing or incorrect
> > Signed-off-by lines:
> >
> > - author signoff <krzkreg@gmail.com> is missing.
> >
> > Please see the file Documentation/SubmittingPatches, section 11
> > for details on signing off patches.
>
> Lots of people use it without a problem. I've just run the parser
> through its offline tests, and it parses email content correctly.
> I've no idea what you're doing wrong, but it looks like something
> pretty serious if it didn't parse the subject line.
>
> Rather than getting stressed about it, why don't you send me an email
> the first time something goes wrong so I can investigate, turn on
> debugging to capture the problem email?
... and I'll also point out one of the biggest problems is people.
People who think it's more complex than it is, or who can't read
instructions.
For example, trying to tell people to use the standard format subject
line:
[PATCH ...] blah
has proven to be hopeless - unless one states to them the exact
sequence of keys on their keyboard to press - yes, it *really* takes
that patronising level to get everyone to understand. If one tries to
do it any other way, then you get stuff like:
"[PATCH ...] ..."
with the quotes. Or some other stupid variation.
The patch system is as forgiving as possible. It takes standard git
formatted patches (with the exception of wanting an additional tag).
It is possible that bugs creep in - particularly when Debian updates
get applied and change the way Perl works, but I don't think that's
what has happened with your situation.
I _guess_ you're putting the entire email-like output from git
format-patch as the patch file. That won't work - that isn't a "patch
file", that is an email/email template, and the patch system will
attempt to parse that as the patch itself.
I suppose you term "patch" to be the email as well, rather than what
I interpret it to be, which is only the output of "diff" - call me
old fashioned but that's what a patch file used to be before the
waters got muddied by git "patch files".
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Russell King (Oracle) @ 2024-04-02 8:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <f514d9e1-61fa-4c55-aea1-d70c955bb96a@linaro.org>
On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> > Merging
> > =======
> > All further patches depend on the first amba patch, therefore please ack
> > and this should go via one tree.
> >
> > Description
> > ===========
> > Modules registering driver with amba_driver_register() often forget to
> > set .owner field.
> >
> > Solve the problem by moving this task away from the drivers to the core
> > amba bus code, just like we did for platform_driver in commit
> > 9447057eaff8 ("platform_device: use a macro instead of
> > platform_driver_register").
> >
> > Best regards,
>
> I tried to submit this series to Russell patch tracker and failed. This
> is ridiculous. It's 2024 and instead of normal process, like every other
> maintainer, so b4 or Patchwork, we have some unusable system rejecting
> standard patches.
Sorry but no. Stop being offensive.
> First, it depends some weird, duplicated signed-off-by's.
Eh? There is no such logic in there.
> Second it > submitting patch-by-patch, all with clicking on some web
> (!!!) interface.
Again, no it doesn't, and you're just throwing crap out because you
failed. Unlike most of the "normal" processes, the patch system allows
you to submit both by *email* and also by *web* for those cases where
the emails get screwed up by ones company mail server. That's why the
web interface exists - to give people *flexibility*.
The fact is, the web interface is merely a front end interface that
generates an email and submits it in the usual way by email - an
email that you can perfectly well generate that is *very* close to
the standard email that git format-patch generates.
The *only* difference is that the patch system wants a KernelVersion:
tag in the email _somewhere_ and it doesn't matter where it appears.
Git even has support to do this.
git format-patch --add-header="KernelVersion: $foo"
Why does it want the kernel version? Because when we were running 2.4
and 2.5 kernel versions in parallel, it was important to know which
tree the patch was being submitted for. It has continued to be required
because it means when there's problems applying a patch, it gives me
the additional information about the base used for the patch (and it
keeps on being useful to have.)
> That's the response:
> -------------
> Your patch has not been logged because:
>
> Error: Please supply a summary subject line briefly describing
> your patch.
>
>
> Error: Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
> "---".
>
> Error: the patch you are submitting has one or more missing or incorrect
> Signed-off-by lines:
>
> - author signoff <krzkreg@gmail.com> is missing.
>
> Please see the file Documentation/SubmittingPatches, section 11
> for details on signing off patches.
Lots of people use it without a problem. I've just run the parser
through its offline tests, and it parses email content correctly.
I've no idea what you're doing wrong, but it looks like something
pretty serious if it didn't parse the subject line.
Rather than getting stressed about it, why don't you send me an email
the first time something goes wrong so I can investigate, turn on
debugging to capture the problem email?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: (subset) [PATCH 0/9] enabled -Wformat-truncation for clang
From: Martin K. Petersen @ 2024-04-02 1:48 UTC (permalink / raw)
To: llvm, Arnd Bergmann
Cc: Martin K . Petersen, Arnd Bergmann, Dmitry Torokhov,
Claudiu Manoil, Vladimir Oltean, Jakub Kicinski, Saeed Mahameed,
Leon Romanovsky, Ariel Elior, Manish Chopra, Hans de Goede,
Ilpo Järvinen, Maximilian Luz, Hannes Reinecke, Helge Deller,
Masahiro Yamada, Nathan Chancellor, Nicolas Schier, Johannes Berg,
Jaroslav Kysela, Takashi Iwai, Nick Desaulniers, Bill Wendling,
Justin Stitt, linux-input, linux-kernel, netdev, linux-rdma,
platform-driver-x86, linux-scsi, linux-fbdev, dri-devel,
linux-kbuild, linuxppc-dev, alsa-devel, linux-sound
In-Reply-To: <20240326223825.4084412-1-arnd@kernel.org>
On Tue, 26 Mar 2024 23:37:59 +0100, Arnd Bergmann wrote:
> With randconfig build testing, I found only eight files that produce
> warnings with clang when -Wformat-truncation is enabled. This means
> we can just turn it on by default rather than only enabling it for
> "make W=1".
>
> Unfortunately, gcc produces a lot more warnings when the option
> is enabled, so it's not yet possible to turn it on both both
> compilers.
>
> [...]
Applied to 6.9/scsi-fixes, thanks!
[7/9] scsi: mylex: fix sysfs buffer lengths
https://git.kernel.org/mkp/scsi/c/1197c5b2099f
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: mfd: twl: Convert trivial subdevices to json-schema
From: Rob Herring @ 2024-04-01 15:17 UTC (permalink / raw)
To: Andreas Kemnade
Cc: krzysztof.kozlowski+dt, linux, devicetree, wim, linux-input,
dmitry.torokhov, linux-rtc, lee, conor+dt, linux-watchdog, sre,
linux-kernel, alexandre.belloni
In-Reply-To: <20240401081831.456828-1-andreas@kemnade.info>
On Mon, 01 Apr 2024 10:18:31 +0200, Andreas Kemnade wrote:
> Convert subdevices with just an interrupt and compatbile to
> json-schema and wire up already converted subdevices.
> RTC is available in all variants, so allow it unconditionally.
> GPADC binding for TWL603X uses two different compatibles, so
> specify just the compatible and do not include it.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> Acked-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Changes in v3:
> - added Ack
> (apparantly many recipients did not receive the V2 patch,
> so there is a need for a resend)
>
> Changes in v2:
> - style cleanup
> - absolute paths
> - unevalutedProperties instead of additionalProperties
> due to not accepting things in if: clauses without it
>
> .../bindings/input/twl4030-pwrbutton.txt | 21 ------
> .../devicetree/bindings/mfd/ti,twl.yaml | 72 ++++++++++++++++++-
> .../devicetree/bindings/rtc/twl-rtc.txt | 11 ---
> .../bindings/watchdog/twl4030-wdt.txt | 10 ---
> 4 files changed, 71 insertions(+), 43 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
> delete mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
> delete mode 100644 Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v8 0/3] Add support for vibrator in multiple PMICs
From: Fenglin Wu via B4 Relay @ 2024-04-01 8:38 UTC (permalink / raw)
To: kernel, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-input, linux-kernel, devicetree, Fenglin Wu,
Krzysztof Kozlowski
Add SW support for the vibrator module inside PMI632, PM7250B, PM7325B, PM7550BA.
It is very similar to the vibrator module inside PM8916 which is supported in
pm8xxx-vib driver but just the drive amplitude is controlled with 2 registers,
and the register base offset in each PMIC is different.
Changes in v8:
1. Remove hw_type, and still keep the register info in match data
2. Update to use register offset in pm8xxx_regs, and the base address
defined in DT for SPMI vibrator will be added in register access
3. Update voltage output range for SPMI vibrator which has 2 bytes drive
registers
Changes in v7:
1. Fix a typo: SSBL_VIB_DRV_REG --> SSBI_VIB_DRV_REG
2. Move the hw_type switch case in pm8xxx_vib_set() to the refactoring
change.
Changes in v6:
1. Add "qcom,pmi632-vib" as a standalone compatible string.
Changes in v5:
1. Drop "qcom,spmi-vib-gen2" generic compatible string as requested
and use device specific compatible strings only.
Changes in v4:
1. Update to use the combination of the HW type and register offset
as the constant match data, the register base address defined in
'reg' property will be added when accessing SPMI registers using
regmap APIs.
2. Remove 'qcom,spmi-vib-gen1' generic compatible string.
Changes in v3:
1. Refactor the driver to support different type of the vibrators with
better flexibility by introducing the HW type with corresponding
register fields definitions.
2. Add 'qcom,spmi-vib-gen1' and 'qcom,spmi-vib-gen2' compatible
strings, and add PMI632, PM7250B, PM7325B, PM7550BA as compatbile as
spmi-vib-gen2.
Changes in v2:
Remove the "pm7550ba-vib" compatible string as it's compatible with pm7325b.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
Fenglin Wu (3):
input: pm8xxx-vibrator: refactor to support new SPMI vibrator
dt-bindings: input: qcom,pm8xxx-vib: add new SPMI vibrator module
input: pm8xxx-vibrator: add new SPMI vibrator support
.../devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 16 +++-
drivers/input/misc/pm8xxx-vibrator.c | 87 ++++++++++++++++------
2 files changed, 78 insertions(+), 25 deletions(-)
---
base-commit: 650cda2ce25f08e8fae391b3ba6be27e7296c6a5
change-id: 20240328-pm8xxx-vibrator-new-design-e5811ad59e8a
Best regards,
--
Fenglin Wu <quic_fenglinw@quicinc.com>
^ permalink raw reply
* [PATCH v8 3/3] input: pm8xxx-vibrator: add new SPMI vibrator support
From: Fenglin Wu via B4 Relay @ 2024-04-01 8:38 UTC (permalink / raw)
To: kernel, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-input, linux-kernel, devicetree, Fenglin Wu
In-Reply-To: <20240401-pm8xxx-vibrator-new-design-v8-0-6f2b8b03b4c7@quicinc.com>
From: Fenglin Wu <quic_fenglinw@quicinc.com>
Add support for a new SPMI vibrator module which is very similar
to the vibrator module inside PM8916 but has a finer drive voltage
step and different output voltage range, its drive level control
is expanded across 2 registers. The vibrator module can be found
in following Qualcomm PMICs: PMI632, PM7250B, PM7325B, PM7550BA.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
drivers/input/misc/pm8xxx-vibrator.c | 49 +++++++++++++++++++++++++++++-------
1 file changed, 40 insertions(+), 9 deletions(-)
diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
index 3b6a2e949f30..59548cd9331c 100644
--- a/drivers/input/misc/pm8xxx-vibrator.c
+++ b/drivers/input/misc/pm8xxx-vibrator.c
@@ -12,9 +12,9 @@
#include <linux/regmap.h>
#include <linux/slab.h>
-#define VIB_MAX_LEVEL_mV (3100)
-#define VIB_MIN_LEVEL_mV (1200)
-#define VIB_MAX_LEVELS (VIB_MAX_LEVEL_mV - VIB_MIN_LEVEL_mV)
+#define VIB_MAX_LEVEL_mV(vib) (vib->drv2_addr ? (3544) : (3100))
+#define VIB_MIN_LEVEL_mV(vib) (vib->drv2_addr ? (1504) : (1200))
+#define VIB_MAX_LEVELS(vib) (VIB_MAX_LEVEL_mV(vib) - VIB_MIN_LEVEL_mV(vib))
#define MAX_FF_SPEED 0xff
@@ -25,6 +25,9 @@ struct pm8xxx_regs {
unsigned int drv_offset;
unsigned int drv_mask;
unsigned int drv_shift;
+ unsigned int drv2_offset;
+ unsigned int drv2_mask;
+ unsigned int drv2_shift;
unsigned int drv_en_manual_mask;
};
@@ -44,6 +47,18 @@ static struct pm8xxx_regs pm8916_regs = {
.drv_en_manual_mask = 0,
};
+static struct pm8xxx_regs pmi632_regs = {
+ .enable_offset = 0x46,
+ .enable_mask = BIT(7),
+ .drv_offset = 0x40,
+ .drv_mask = 0xFF,
+ .drv_shift = 0,
+ .drv2_offset = 0x41,
+ .drv2_mask = 0x0F,
+ .drv2_shift = 8,
+ .drv_en_manual_mask = 0,
+};
+
/**
* struct pm8xxx_vib - structure to hold vibrator data
* @vib_input_dev: input device supporting force feedback
@@ -52,6 +67,7 @@ static struct pm8xxx_regs pm8916_regs = {
* @regs: registers' info
* @enable_addr: vibrator enable register
* @drv_addr: vibrator drive strength register
+ * @drv2_addr: vibrator drive strength upper byte register
* @speed: speed of vibration set from userland
* @active: state of vibrator
* @level: level of vibration to set in the chip
@@ -64,6 +80,7 @@ struct pm8xxx_vib {
const struct pm8xxx_regs *regs;
unsigned int enable_addr;
unsigned int drv_addr;
+ unsigned int drv2_addr;
int speed;
int level;
bool active;
@@ -92,6 +109,16 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
vib->reg_vib_drv = val;
+ if (regs->drv2_mask) {
+ if (on)
+ val = (vib->level << regs->drv2_shift) & regs->drv2_mask;
+ else
+ val = 0;
+ rc = regmap_write(vib->regmap, vib->drv2_addr, val);
+ if (rc < 0)
+ return rc;
+ }
+
if (regs->enable_mask)
rc = regmap_update_bits(vib->regmap, vib->enable_addr,
regs->enable_mask, on ? ~0 : 0);
@@ -114,19 +141,22 @@ static void pm8xxx_work_handler(struct work_struct *work)
return;
/*
- * pmic vibrator supports voltage ranges from 1.2 to 3.1V, so
+ * pmic vibrator supports voltage ranges from MIN_LEVEL to MAX_LEVEL, so
* scale the level to fit into these ranges.
*/
if (vib->speed) {
vib->active = true;
- vib->level = ((VIB_MAX_LEVELS * vib->speed) / MAX_FF_SPEED) +
- VIB_MIN_LEVEL_mV;
- vib->level /= 100;
+ vib->level = ((VIB_MAX_LEVELS(vib) * vib->speed) / MAX_FF_SPEED) +
+ VIB_MIN_LEVEL_mV(vib);
} else {
vib->active = false;
- vib->level = VIB_MIN_LEVEL_mV / 100;
+ vib->level = VIB_MIN_LEVEL_mV(vib);
+
}
+ if (!vib->drv2_addr)
+ vib->level /= 100;
+
pm8xxx_vib_set(vib, vib->active);
}
@@ -202,7 +232,7 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
vib->enable_addr = reg_base + regs->enable_offset;
vib->drv_addr = reg_base + regs->drv_offset;
-
+ vib->drv2_addr = reg_base + regs->drv2_offset;
/* operate in manual mode */
error = regmap_read(vib->regmap, vib->drv_addr, &val);
if (error < 0)
@@ -256,6 +286,7 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
{ .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
{ .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
{ .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
+ { .compatible = "qcom,pmi632-vib", .data = &pmi632_regs },
{ }
};
MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
--
2.25.1
^ permalink raw reply related
* [PATCH v8 1/3] input: pm8xxx-vibrator: refactor to support new SPMI vibrator
From: Fenglin Wu via B4 Relay @ 2024-04-01 8:38 UTC (permalink / raw)
To: kernel, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-input, linux-kernel, devicetree, Fenglin Wu
In-Reply-To: <20240401-pm8xxx-vibrator-new-design-v8-0-6f2b8b03b4c7@quicinc.com>
From: Fenglin Wu <quic_fenglinw@quicinc.com>
Currently, vibrator control register addresses are hard coded,
including the base address and offsets, it's not flexible to
support new SPMI vibrator module which is usually included in
different PMICs with different base address. Refactor it by using
the base address defined in devicetree.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
drivers/input/misc/pm8xxx-vibrator.c | 40 ++++++++++++++++++++++++------------
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
index 04cb87efd799..3b6a2e949f30 100644
--- a/drivers/input/misc/pm8xxx-vibrator.c
+++ b/drivers/input/misc/pm8xxx-vibrator.c
@@ -19,26 +19,26 @@
#define MAX_FF_SPEED 0xff
struct pm8xxx_regs {
- unsigned int enable_addr;
+ unsigned int enable_offset;
unsigned int enable_mask;
- unsigned int drv_addr;
+ unsigned int drv_offset;
unsigned int drv_mask;
unsigned int drv_shift;
unsigned int drv_en_manual_mask;
};
static const struct pm8xxx_regs pm8058_regs = {
- .drv_addr = 0x4A,
+ .drv_offset = 0x4A,
.drv_mask = 0xf8,
.drv_shift = 3,
.drv_en_manual_mask = 0xfc,
};
static struct pm8xxx_regs pm8916_regs = {
- .enable_addr = 0xc046,
+ .enable_offset = 0x46,
.enable_mask = BIT(7),
- .drv_addr = 0xc041,
+ .drv_offset = 0x41,
.drv_mask = 0x1F,
.drv_shift = 0,
.drv_en_manual_mask = 0,
@@ -50,6 +50,8 @@ static struct pm8xxx_regs pm8916_regs = {
* @work: work structure to set the vibration parameters
* @regmap: regmap for register read/write
* @regs: registers' info
+ * @enable_addr: vibrator enable register
+ * @drv_addr: vibrator drive strength register
* @speed: speed of vibration set from userland
* @active: state of vibrator
* @level: level of vibration to set in the chip
@@ -60,6 +62,8 @@ struct pm8xxx_vib {
struct work_struct work;
struct regmap *regmap;
const struct pm8xxx_regs *regs;
+ unsigned int enable_addr;
+ unsigned int drv_addr;
int speed;
int level;
bool active;
@@ -82,14 +86,14 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
else
val &= ~regs->drv_mask;
- rc = regmap_write(vib->regmap, regs->drv_addr, val);
+ rc = regmap_write(vib->regmap, vib->drv_addr, val);
if (rc < 0)
return rc;
vib->reg_vib_drv = val;
if (regs->enable_mask)
- rc = regmap_update_bits(vib->regmap, regs->enable_addr,
+ rc = regmap_update_bits(vib->regmap, vib->enable_addr,
regs->enable_mask, on ? ~0 : 0);
return rc;
@@ -102,11 +106,10 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
static void pm8xxx_work_handler(struct work_struct *work)
{
struct pm8xxx_vib *vib = container_of(work, struct pm8xxx_vib, work);
- const struct pm8xxx_regs *regs = vib->regs;
- int rc;
unsigned int val;
+ int rc;
- rc = regmap_read(vib->regmap, regs->drv_addr, &val);
+ rc = regmap_read(vib->regmap, vib->drv_addr, &val);
if (rc < 0)
return;
@@ -169,7 +172,7 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
struct pm8xxx_vib *vib;
struct input_dev *input_dev;
int error;
- unsigned int val;
+ unsigned int val, reg_base = 0;
const struct pm8xxx_regs *regs;
vib = devm_kzalloc(&pdev->dev, sizeof(*vib), GFP_KERNEL);
@@ -189,13 +192,24 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
regs = of_device_get_match_data(&pdev->dev);
+ if (regs->enable_offset != 0) {
+ error = fwnode_property_read_u32(pdev->dev.fwnode, "reg", ®_base);
+ if (error < 0) {
+ dev_err(&pdev->dev, "Failed to read reg address, rc=%d\n", error);
+ return error;
+ }
+ }
+
+ vib->enable_addr = reg_base + regs->enable_offset;
+ vib->drv_addr = reg_base + regs->drv_offset;
+
/* operate in manual mode */
- error = regmap_read(vib->regmap, regs->drv_addr, &val);
+ error = regmap_read(vib->regmap, vib->drv_addr, &val);
if (error < 0)
return error;
val &= regs->drv_en_manual_mask;
- error = regmap_write(vib->regmap, regs->drv_addr, val);
+ error = regmap_write(vib->regmap, vib->drv_addr, val);
if (error < 0)
return error;
--
2.25.1
^ permalink raw reply related
* [PATCH v8 2/3] dt-bindings: input: qcom,pm8xxx-vib: add new SPMI vibrator module
From: Fenglin Wu via B4 Relay @ 2024-04-01 8:38 UTC (permalink / raw)
To: kernel, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-input, linux-kernel, devicetree, Fenglin Wu,
Krzysztof Kozlowski
In-Reply-To: <20240401-pm8xxx-vibrator-new-design-v8-0-6f2b8b03b4c7@quicinc.com>
From: Fenglin Wu <quic_fenglinw@quicinc.com>
Add compatible strings to support vibrator module inside PMI632,
PMI7250B, PM7325B, PM7550BA.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
.../devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
index c8832cd0d7da..2025d6a5423e 100644
--- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
@@ -11,10 +11,18 @@ maintainers:
properties:
compatible:
- enum:
- - qcom,pm8058-vib
- - qcom,pm8916-vib
- - qcom,pm8921-vib
+ oneOf:
+ - enum:
+ - qcom,pm8058-vib
+ - qcom,pm8916-vib
+ - qcom,pm8921-vib
+ - qcom,pmi632-vib
+ - items:
+ - enum:
+ - qcom,pm7250b-vib
+ - qcom,pm7325b-vib
+ - qcom,pm7550ba-vib
+ - const: qcom,pmi632-vib
reg:
maxItems: 1
--
2.25.1
^ permalink raw reply related
* [PATCH v3] dt-bindings: mfd: twl: Convert trivial subdevices to json-schema
From: Andreas Kemnade @ 2024-04-01 8:18 UTC (permalink / raw)
To: dmitry.torokhov, robh, krzysztof.kozlowski+dt, conor+dt, lee,
alexandre.belloni, wim, linux, andreas, linux-input, devicetree,
linux-kernel, linux-rtc, linux-watchdog, sre
Convert subdevices with just an interrupt and compatbile to
json-schema and wire up already converted subdevices.
RTC is available in all variants, so allow it unconditionally.
GPADC binding for TWL603X uses two different compatibles, so
specify just the compatible and do not include it.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Acked-by: Guenter Roeck <linux@roeck-us.net>
---
Changes in v3:
- added Ack
(apparantly many recipients did not receive the V2 patch,
so there is a need for a resend)
Changes in v2:
- style cleanup
- absolute paths
- unevalutedProperties instead of additionalProperties
due to not accepting things in if: clauses without it
.../bindings/input/twl4030-pwrbutton.txt | 21 ------
.../devicetree/bindings/mfd/ti,twl.yaml | 72 ++++++++++++++++++-
.../devicetree/bindings/rtc/twl-rtc.txt | 11 ---
.../bindings/watchdog/twl4030-wdt.txt | 10 ---
4 files changed, 71 insertions(+), 43 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
delete mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
delete mode 100644 Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
diff --git a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
deleted file mode 100644
index 6c201a2ba8acf..0000000000000
--- a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Texas Instruments TWL family (twl4030) pwrbutton module
-
-This module is part of the TWL4030. For more details about the whole
-chip see Documentation/devicetree/bindings/mfd/ti,twl.yaml.
-
-This module provides a simple power button event via an Interrupt.
-
-Required properties:
-- compatible: should be one of the following
- - "ti,twl4030-pwrbutton": For controllers compatible with twl4030
-- interrupts: should be one of the following
- - <8>: For controllers compatible with twl4030
-
-Example:
-
-&twl {
- twl_pwrbutton: pwrbutton {
- compatible = "ti,twl4030-pwrbutton";
- interrupts = <8>;
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/ti,twl.yaml b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
index 52ed228fb1e7e..c2357fecb56cc 100644
--- a/Documentation/devicetree/bindings/mfd/ti,twl.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
@@ -15,6 +15,67 @@ description: |
USB transceiver or Audio amplifier.
These chips are connected to an i2c bus.
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,twl4030
+ then:
+ properties:
+ madc:
+ type: object
+ $ref: /schemas/iio/adc/ti,twl4030-madc.yaml
+ unevaluatedProperties: false
+
+ bci:
+ type: object
+ $ref: /schemas/power/supply/twl4030-charger.yaml
+ unevaluatedProperties: false
+
+ pwrbutton:
+ type: object
+ additionalProperties: false
+ properties:
+ compatible:
+ const: ti,twl4030-pwrbutton
+ interrupts:
+ items:
+ - items:
+ const: 8
+
+ watchdog:
+ type: object
+ additionalProperties: false
+ properties:
+ compatible:
+ const: ti,twl4030-wdt
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,twl6030
+ then:
+ properties:
+ gpadc:
+ type: object
+ properties:
+ compatible:
+ const: ti,twl6030-gpadc
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,twl6032
+ then:
+ properties:
+ gpadc:
+ type: object
+ properties:
+ compatible:
+ const: ti,twl6032-gpadc
+
properties:
compatible:
description:
@@ -42,7 +103,16 @@ properties:
"#clock-cells":
const: 1
-additionalProperties: false
+ rtc:
+ type: object
+ additionalProperties: false
+ properties:
+ compatible:
+ const: ti,twl4030-rtc
+ interrupts:
+ maxItems: 1
+
+unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/rtc/twl-rtc.txt b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
deleted file mode 100644
index 8f9a94f2f8969..0000000000000
--- a/Documentation/devicetree/bindings/rtc/twl-rtc.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-* Texas Instruments TWL4030/6030 RTC
-
-Required properties:
-- compatible : Should be "ti,twl4030-rtc"
-- interrupts : Should be the interrupt number.
-
-Example:
- rtc {
- compatible = "ti,twl4030-rtc";
- interrupts = <11>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt b/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
deleted file mode 100644
index 80a37193c0b86..0000000000000
--- a/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Device tree bindings for twl4030-wdt driver (TWL4030 watchdog)
-
-Required properties:
- compatible = "ti,twl4030-wdt";
-
-Example:
-
-watchdog {
- compatible = "ti,twl4030-wdt";
-};
--
2.39.2
^ permalink raw reply related
* RE: [PATCH] input/touchscreen: synaptics_tcm_oncell: add driver
From: Marge Yang @ 2024-04-01 6:18 UTC (permalink / raw)
To: friederhannenheim@riseup.net, Dmitry Torokhov, Scott Lin
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Vincent Huang
In-Reply-To: <5dcfdc9c77b1dcd73815b8eaec8a4717@riseup.net>
Loop Scott Lin
Scott Lin is responsible for mobile products.
Thanks
Marge Yang
-----Original Message-----
From: friederhannenheim@riseup.net <friederhannenheim@riseup.net>
Sent: Sunday, March 31, 2024 4:35 AM
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Marge Yang <Marge.Yang@tw.synaptics.com>; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] input/touchscreen: synaptics_tcm_oncell: add driver
CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
On 2024-03-28 18:53, Dmitry Torokhov wrote:
> [ now CCing for real ]
>
> Hi Frieder,
>
> On Wed, Mar 27, 2024 at 10:39:12PM +0100, Frieder Hannenheim wrote:
>> This is a bit of a stripped down and partially reworked driver for
>> the synaptics_tcm_oncell touchscreen. I based my work off the driver
>> in the LineageOS kernel found at
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Linea
>> geOS_android-5Fkernel-5Foneplus-5Fsm8250&d=DwICAg&c=7dfBJ8cXbWjhc0BhI
>> mu8wVIoUFmBzj1s88r8EGyM0UY&r=ddk_91asmhyAjxFmXHNIQZ2mVcW0D_eq4tb4409nZ94&m=2_iuhvyQkYcT-qsozPf_h9irH_AlUtaQ020UAxVQhZ3SuHgXYihgVocHyTV-zNSV&s=FT4Hkpxkhqktmhyz4RWC9lGAD4DvNBS06wQnn4ofQkk&e= branch lineage-20. The code was originally written by OnePlus developers but I'm not sure how to credit them correctly.
>
> So the first question is: does this device not use Synaptics RMI4
> protocol?
>
> I am CCing Marge Yang of Synaptics who may shed some light on the kind
> of touch controller this is.
>
> Thanks.
Hi Dmitri,
the synaptics-s3908 uses a command based protocol whereas rmi4 is register-based (as far as I understand it, I haven't been able to read up on it properly since information on the internet is sparse). So I'm pretty sure that it can not be controlled via rmi4.
Best wishes,
Frieder
^ permalink raw reply
* Re: [PATCH] HID: indent config option help text
From: P J P @ 2024-04-01 5:05 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input@vger.kernel.org
In-Reply-To: <20240323105302.1828426-1-ppandit@redhat.com>
>On Saturday, 23 March, 2024 at 04:23:25 pm IST, Prasad Pandit wrote:
>From: Prasad Pandit <pjp@fedoraproject.org>
>
>Fix indentation of config option's help text by adding
>leading spaces. Generally help text is indented by couple
>of spaces more beyond the leading tab <\t> character.
>It helps Kconfig parsers to read file without error.
>
>---
>drivers/hid/Kconfig | 633 ++++++++++++++++++++++----------------------
>1 file changed, 321 insertions(+), 312 deletions(-)
>
Ping...!
---
-Prasad
^ permalink raw reply
* [PATCH] HID: uclogic: Remove useless loop
From: Stefan Berzl @ 2024-04-01 0:47 UTC (permalink / raw)
To: jikos; +Cc: linux-input, linux-kernel, Stefan Berzl
The while in question does nothing except provide the possibility
to have an infinite loop in case the subreport id is actually the same
as the pen id.
Signed-off-by: Stefan Berzl <stefanberzl@gmail.com>
---
drivers/hid/hid-uclogic-core.c | 55 ++++++++++++++++------------------
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/hid/hid-uclogic-core.c b/drivers/hid/hid-uclogic-core.c
index ad74cbc9a0aa..a56f4de216de 100644
--- a/drivers/hid/hid-uclogic-core.c
+++ b/drivers/hid/hid-uclogic-core.c
@@ -431,40 +431,35 @@ static int uclogic_raw_event(struct hid_device *hdev,
if (uclogic_exec_event_hook(params, data, size))
return 0;
- while (true) {
- /* Tweak pen reports, if necessary */
- if ((report_id == params->pen.id) && (size >= 2)) {
- subreport_list_end =
- params->pen.subreport_list +
- ARRAY_SIZE(params->pen.subreport_list);
- /* Try to match a subreport */
- for (subreport = params->pen.subreport_list;
- subreport < subreport_list_end; subreport++) {
- if (subreport->value != 0 &&
- subreport->value == data[1]) {
- break;
- }
- }
- /* If a subreport matched */
- if (subreport < subreport_list_end) {
- /* Change to subreport ID, and restart */
- report_id = data[0] = subreport->id;
- continue;
- } else {
- return uclogic_raw_event_pen(drvdata, data, size);
+ /* Tweak pen reports, if necessary */
+ if ((report_id == params->pen.id) && (size >= 2)) {
+ subreport_list_end =
+ params->pen.subreport_list +
+ ARRAY_SIZE(params->pen.subreport_list);
+ /* Try to match a subreport */
+ for (subreport = params->pen.subreport_list;
+ subreport < subreport_list_end; subreport++) {
+ if (subreport->value != 0 &&
+ subreport->value == data[1]) {
+ break;
}
}
-
- /* Tweak frame control reports, if necessary */
- for (i = 0; i < ARRAY_SIZE(params->frame_list); i++) {
- if (report_id == params->frame_list[i].id) {
- return uclogic_raw_event_frame(
- drvdata, ¶ms->frame_list[i],
- data, size);
- }
+ /* If a subreport matched */
+ if (subreport < subreport_list_end) {
+ /* Change to subreport ID, and restart */
+ report_id = data[0] = subreport->id;
+ } else {
+ return uclogic_raw_event_pen(drvdata, data, size);
}
+ }
- break;
+ /* Tweak frame control reports, if necessary */
+ for (i = 0; i < ARRAY_SIZE(params->frame_list); i++) {
+ if (report_id == params->frame_list[i].id) {
+ return uclogic_raw_event_frame(
+ drvdata, ¶ms->frame_list[i],
+ data, size);
+ }
}
return 0;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] input/touchscreen: synaptics_tcm_oncell: add driver
From: Caleb Connolly @ 2024-03-31 23:11 UTC (permalink / raw)
To: Frieder Hannenheim, dmitry.torokhov, linux-input, linux-kernel
In-Reply-To: <20240327214643.7055-1-friederhannenheim@riseup.net>
Hi,
Thanks for working on this! I've been doing panel bringup for the 8T,
it'll be great to get everything working.
I gave this a spin and hit a null pointer in the irq handler during
probe about 50% of the time, so I think there's some kind of race
condition going on here.
Please run checkpatch (and maybe some other linter like clang-format?).
I'd recommend giving this a read
https://wiki.postmarketos.org/wiki/Submitting_Patches
In general, the way this driver was written by OnePlus is pretty
unmaintainable imo. It does a poor job at modelling the hardware and
seems to be pretty fragile and hard to follow.
On 27/03/2024 22:39, Frieder Hannenheim wrote:
> This is a bit of a stripped down and partially reworked driver for the
> synaptics_tcm_oncell touchscreen. I based my work off the driver in the
> LineageOS kernel found at
> https://github.com/LineageOS/android_kernel_oneplus_sm8250 branch
> lineage-20. The code was originally written by OnePlus developers but
> I'm not sure how to credit them correctly.
>
> Currently the driver is in a pretty good shape, the only thing that is
> not working is setting a report config. To me it looks like some data is
> sent by the touchscreen firmware after setting the report config that is
> making the irq handler crash. Sadly I haven't been able to test out why.
> The driver works fine also with the default touch report config so maybe
> we can just use that and not set our own.
>
> Signed-off-by: Frieder Hannenheim <friederhannenheim@riseup.net>
> ---
> .../input/touchscreen/syna,s3908.yaml | 63 +
> drivers/input/touchscreen/Kconfig | 11 +
> drivers/input/touchscreen/Makefile | 1 +
> .../input/touchscreen/synaptics_tcm_oncell.c | 1104 +++++++++++++++++
> 4 files changed, 1179 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/syna,s3908.yaml
> create mode 100644 drivers/input/touchscreen/synaptics_tcm_oncell.c
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/syna,s3908.yaml b/Documentation/devicetree/bindings/input/touchscreen/syna,s3908.yaml
> new file mode 100644
> index 000000000000..1a85747e2f52
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/syna,s3908.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/touchscreen/synaptics,s3908.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synaptics s3908 touchscreen controller
> +
> +maintainers:
> + - Frieder Hannenheim <frieder.hannenheim@riseup.net>
> +
> +allOf:
> + - $ref: touchscreen.yaml#
> +
> +properties:
> + compatible:
> + const: syna,s3908
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + reset-gpios:
> + maxItems: 1
> + description: reset gpio the chip is connected to.
> +
> + vdd-supply: true
> + vcc-supply: true
> +
> + max-objects: true
> +
> +unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - reset-gpios
> + - vdd-supply
> + - vcc-supply
> + - max-objects
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + touchscreen@48 {
> + compatible = "syna,s3908";
> + reg = <0x48>;
> + interrupt-parent = <&gpa1>;
> + interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
> + reset-gpios = <38 0>;
> + vdd-supply = <&ldo30_reg>;
> + vcc-supply = <&ldo31_reg>;
> +
> + max-objects = <10>;
> + };
> + };
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index 1f8b33c2b03d..eba31ae27391 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -502,6 +502,17 @@ config TOUCHSCREEN_S6SY761
>
> To compile this driver as module, choose M here: the
> module will be called s6sy761.
> +
> +config TOUCHSCREEN_SYNA_TCM_ONCELL
> + tristate "Synaptics TCM Oncell Touchscreen driver"
> + depends on I2C
> + help
> + Say Y if you have the Synaptics TCM Oncell driver
> +
> + If unsure, say N
> +
> + To compile this driver as module, choose M here: the
> + module will be called synaptics_tcm_oncell.
>
> config TOUCHSCREEN_GUNZE
> tristate "Gunze AHL-51S touchscreen"
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index 7d52592f4290..f5395ccf09d5 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -86,6 +86,7 @@ obj-$(CONFIG_TOUCHSCREEN_STMPE) += stmpe-ts.o
> obj-$(CONFIG_TOUCHSCREEN_SUN4I) += sun4i-ts.o
> obj-$(CONFIG_TOUCHSCREEN_SUR40) += sur40.o
> obj-$(CONFIG_TOUCHSCREEN_SURFACE3_SPI) += surface3_spi.o
> +obj-$(CONFIG_TOUCHSCREEN_SYNA_TCM_ONCELL) += synaptics_tcm_oncell.o
> obj-$(CONFIG_TOUCHSCREEN_TI_AM335X_TSC) += ti_am335x_tsc.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
> diff --git a/drivers/input/touchscreen/synaptics_tcm_oncell.c b/drivers/input/touchscreen/synaptics_tcm_oncell.c
> new file mode 100644
> index 000000000000..b874287f37af
> --- /dev/null
> +++ b/drivers/input/touchscreen/synaptics_tcm_oncell.c
> @@ -0,0 +1,1104 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Driver for Synaptics TCM Oncell Touchscreens
> + *
> + * Copyright (c) 2024 Frieder Hannenheim <friederhannenheim@riseup.net>
You should keep the previous "oplus" copyright and just add yours below it.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/input.h>
> +#include <linux/input/touchscreen.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/property.h>
> +#include <asm/unaligned.h>
> +#include <linux/delay.h>
> +#include <linux/input/mt.h>
> +#include <linux/input/touchscreen.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/of_gpio.h>
> +#include <linux/module.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regulator/consumer.h>
> +
> +/* Meta Information */
you can remove all the comments like ("meta comments?")
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Frieder Hannenheim");
> +MODULE_DESCRIPTION("A driver for Synaptics TCM Oncell Touchpanels");
> +
> +#define TOUCHPANEL_DEVICE "syna-tcm"
> +
> +#define POWERUP_TO_RESET_TIME 10
> +#define RESET_TO_NORMAL_TIME 80
> +
> +#define RESPONSE_TIMEOUT_MS 1000
> +
> +#define MESSAGE_HEADER_SIZE 4
> +#define MESSAGE_MARKER 0xA5
> +#define MESSAGE_PADDING 0x5A
> +
> +#define READ_LENGTH 9
> +#define MAX_I2C_RETRY_TIME 4
> +
> +#define RD_CHUNK_SIZE 0 /* read length limit in bytes, 0 = unlimited */
> +#define WR_CHUNK_SIZE 0 /* write length limit in bytes, 0 = unlimited */
> +
> +#define APP_STATUS_POLL_MS 100
> +#define TOUCH_REPORT_CONFIG_SIZE 128
> +
> +enum command {
> + CMD_NONE = 0x00,
> + CMD_CONTINUE_WRITE = 0x01,
> + CMD_IDENTIFY = 0x02,
> + CMD_RESET = 0x04,
> + CMD_ENABLE_REPORT = 0x05,
> + CMD_DISABLE_REPORT = 0x06,
> + CMD_GET_BOOT_INFO = 0x10,
> + CMD_ERASE_FLASH = 0x11,
> + CMD_WRITE_FLASH = 0x12,
> + CMD_READ_FLASH = 0x13,
> + CMD_RUN_APPLICATION_FIRMWARE = 0x14,
> + CMD_SPI_MASTER_WRITE_THEN_READ = 0x15,
> + CMD_REBOOT_TO_ROM_BOOTLOADER = 0x16,
> + CMD_RUN_BOOTLOADER_FIRMWARE = 0x1f,
> + CMD_GET_APPLICATION_INFO = 0x20,
> + CMD_GET_STATIC_CONFIG = 0x21,
> + CMD_SET_STATIC_CONFIG = 0x22,
> + CMD_GET_DYNAMIC_CONFIG = 0x23,
> + CMD_SET_DYNAMIC_CONFIG = 0x24,
> + CMD_GET_TOUCH_REPORT_CONFIG = 0x25,
> + CMD_SET_TOUCH_REPORT_CONFIG = 0x26,
> + CMD_REZERO = 0x27,
> + CMD_COMMIT_CONFIG = 0x28,
> + CMD_DESCRIBE_DYNAMIC_CONFIG = 0x29,
> + CMD_PRODUCTION_TEST = 0x2a,
> + CMD_SET_CONFIG_ID = 0x2b,
> + CMD_ENTER_DEEP_SLEEP = 0x2c,
> + CMD_EXIT_DEEP_SLEEP = 0x2d,
> + CMD_GET_TOUCH_INFO = 0x2e,
> + CMD_GET_DATA_LOCATION = 0x2f,
> + CMD_DOWNLOAD_CONFIG = 0xc0,
> + CMD_GET_NSM_INFO = 0xc3,
> + CMD_EXIT_ESD = 0xc4,
> +};
> +
> +enum touch_report_code {
> + TOUCH_END = 0,
> + TOUCH_FOREACH_ACTIVE_OBJECT = 1,
> + TOUCH_FOREACH_OBJECT = 2,
> + TOUCH_FOREACH_END = 3,
> + TOUCH_PAD_TO_NEXT_BYTE = 4,
> + TOUCH_TIMESTAMP = 5,
> + TOUCH_OBJECT_N_INDEX = 6,
> + TOUCH_OBJECT_N_CLASSIFICATION = 7,
> + TOUCH_OBJECT_N_X_POSITION = 8,
> + TOUCH_OBJECT_N_Y_POSITION = 9,
> + TOUCH_OBJECT_N_Z = 10,
> + TOUCH_OBJECT_N_X_WIDTH = 11,
> + TOUCH_OBJECT_N_Y_WIDTH = 12,
> + TOUCH_OBJECT_N_TX_POSITION_TIXELS = 13,
> + TOUCH_OBJECT_N_RX_POSITION_TIXELS = 14,
> + TOUCH_0D_BUTTONS_STATE = 15,
> + TOUCH_GESTURE_DOUBLE_TAP = 16,
> + TOUCH_FRAME_RATE = 17,
> + TOUCH_POWER_IM = 18,
> + TOUCH_CID_IM = 19,
> + TOUCH_RAIL_IM = 20,
> + TOUCH_CID_VARIANCE_IM = 21,
> + TOUCH_NSM_FREQUENCY = 22,
> + TOUCH_NSM_STATE = 23,
> + TOUCH_NUM_OF_ACTIVE_OBJECTS = 23,
> + TOUCH_NUM_OF_CPU_CYCLES_USED_SINCE_LAST_FRAME = 24,
> + TOUCH_TUNING_GAUSSIAN_WIDTHS = 0x80,
> + TOUCH_TUNING_SMALL_OBJECT_PARAMS = 0x81,
> + TOUCH_TUNING_0D_BUTTONS_VARIANCE = 0x82,
> + TOUCH_REPORT_GESTURE_SWIPE = 193,
> + TOUCH_REPORT_GESTURE_CIRCLE = 194,
> + TOUCH_REPORT_GESTURE_UNICODE = 195,
> + TOUCH_REPORT_GESTURE_VEE = 196,
> + TOUCH_REPORT_GESTURE_TRIANGLE = 197,
> + TOUCH_REPORT_GESTURE_INFO = 198,
> + TOUCH_REPORT_GESTURE_COORDINATE = 199,
> + TOUCH_REPORT_CUSTOMER_GRIP_INFO = 203,
> +};
> +
> +enum touch_status {
> + LIFT = 0,
> + FINGER = 1,
> + GLOVED_FINGER = 2,
> + NOP = -1,
> +};
> +
> +enum status_code {
> + STATUS_IDLE = 0x00,
> + STATUS_OK = 0x01,
> + STATUS_BUSY = 0x02,
> + STATUS_CONTINUED_READ = 0x03,
> + STATUS_RECEIVE_BUFFER_OVERFLOW = 0x0c,
> + STATUS_PREVIOUS_COMMAND_PENDING = 0x0d,
> + STATUS_NOT_IMPLEMENTED = 0x0e,
> + STATUS_ERROR = 0x0f,
> + STATUS_INVALID = 0xff,
> +};
> +
> +enum report_type {
> + REPORT_IDENTIFY = 0x10,
> + REPORT_TOUCH = 0x11,
> + REPORT_DELTA = 0x12,
> + REPORT_RAW = 0x13,
> + REPORT_DEBUG = 0x14,
> + REPORT_LOG = 0x1d,
> + REPORT_TOUCH_HOLD = 0x20,
> +};
> +
> +enum syna_tcm_oncell_regulators {
> + SYNA_TCM_ONCELL_REGULATOR_VDD,
> + SYNA_TCM_ONCELL_REGULATOR_VCC,
> +};
> +
> +enum boot_mode {
> + MODE_APPLICATION = 0x01,
> + MODE_HOST_DOWNLOAD = 0x02,
> + MODE_BOOTLOADER = 0x0b,
> + MODE_TDDI_BOOTLOADER = 0x0c,
> +};
> +
> +enum app_status {
> + APP_STATUS_OK = 0x00,
> + APP_STATUS_BOOTING = 0x01,
> + APP_STATUS_UPDATING = 0x02,
> + APP_STATUS_BAD_APP_CONFIG = 0xff,
> +};
> +
> +struct syna_tcm_app_info {
> + unsigned char version[2];
> + unsigned char status[2];
> + unsigned char static_config_size[2];
> + unsigned char dynamic_config_size[2];
> + unsigned char app_config_start_write_block[2];
> + unsigned char app_config_size[2];
> + unsigned char max_touch_report_config_size[2];
> + unsigned char max_touch_report_payload_size[2];
> + unsigned char customer_config_id[16];
> + unsigned char max_x[2];
> + unsigned char max_y[2];
> + unsigned char max_objects[2];
> + unsigned char num_of_buttons[2];
> + unsigned char num_of_image_rows[2];
> + unsigned char num_of_image_cols[2];
> + unsigned char has_hybrid_data[2];
> +};
> +
> +struct syna_tcm_identification {
> + unsigned char version;
> + unsigned char mode;
> + unsigned char part_number[16];
> + unsigned char build_id[4];
> + unsigned char max_write_size[2];
> +};
> +
> +struct syna_tcm_message_header {
> + unsigned char marker;
> + unsigned char code;
> + unsigned char length[2];
> +};
> +
> +struct touch_data {
> + unsigned char status;
> + unsigned int x_pos;
> + unsigned int y_pos;
> + unsigned int x_width;
> + unsigned int y_width;
> + unsigned int z;
> +};
> +
> +struct syna_tcm_data {
> + struct i2c_client *client;
> + struct regulator_bulk_data regulators[2];
> + struct input_dev *input;
> + struct gpio_desc *reset_gpio;
> + struct touchscreen_properties prop;
> + struct syna_tcm_identification id_info;
> + struct syna_tcm_app_info app_info;
> +
> + unsigned char *response_buf;
> + unsigned int response_length; // Response length including header
> +
> + unsigned int app_status;
> +
> + unsigned char *report_config;
> + unsigned int report_size;
> +
> + bool initialize_done;
This value is never read.
> +
> + unsigned int touchpanel_max_objects;
> +};
> +
> +DECLARE_COMPLETION(response_complete);
> +
> +static inline unsigned int le2_to_uint(const unsigned char *src)
> +{
> + return (unsigned int)src[0] + (unsigned int)src[1] * 0x100;
Shouldn't this just be a cast?
> +}
> +
> +static inline unsigned int ceil_div(unsigned int dividend, unsigned int divisor)
> +{
> + return (dividend + divisor - 1) / divisor;
> +}
> +
> +static int touch_i2c_continue_read(struct i2c_client *client,
> + unsigned char *data, unsigned short length)
> +{
> + int retval;
> + unsigned char retry;
> + struct i2c_msg msg;
> +
> + msg.addr = client->addr;
> + msg.flags = I2C_M_RD;
> + msg.len = length;
> + msg.buf = data;
> +
> + for (retry = 0; retry < MAX_I2C_RETRY_TIME; retry++) {
> + if (i2c_transfer(client->adapter, &msg, 1) == 1) {
> + retval = length;
> + break;
> + }
> + msleep(20);
> + }
> + if (retry == MAX_I2C_RETRY_TIME) {
> + pr_warn("%s: I2C read over retry limit\n", __func__);
> + retval = -EIO;
> + }
> + return retval;
> +}
> +
> +static int touch_i2c_continue_write(struct i2c_client *client,
> + unsigned char *data, unsigned short length)
> +{
> + int retval;
> + unsigned char retry;
> + struct i2c_msg msg;
> +
> + msg.addr = client->addr;
> + msg.flags = 0;
> + msg.buf = data;
> + msg.len = length;
> +
> + for (retry = 0; retry < MAX_I2C_RETRY_TIME; retry++) {
> + if (i2c_transfer(client->adapter, &msg, 1) == 1) {
> + retval = length;
> + break;
> + }
> + msleep(20);
> + }
> + if (retry == MAX_I2C_RETRY_TIME) {
> + pr_warn("%s: I2C write over retry limit\n", __func__);
> + retval = -EIO;
> + }
> + return retval;
> +}
> +
> +static int syna_tcm_continued_read(struct syna_tcm_data *tcm_info,
continue_write and continueD_read, please make these consistent.
> + unsigned int payload_length,
> + unsigned char *message_buffer)
> +{
> + int retval = 0;
> + unsigned char marker = 0, code = 0;
> + unsigned int total_length = 0, remaining_length = 0;
> + unsigned char *temp_buffer;
> +
> + total_length = MESSAGE_HEADER_SIZE + payload_length + 1;
> + remaining_length = total_length - READ_LENGTH;
> +
> + temp_buffer = kmalloc(remaining_length + 2, GFP_KERNEL);
> + if (!temp_buffer)
> + return -ENOMEM;
> +
> + retval = touch_i2c_continue_read(tcm_info->client, temp_buffer,
> + remaining_length + 2);
> + if (retval < 0) {
> + pr_warn("touch_i2c_continue_read failed");
dev_err??
> + return retval;
> + }
> +
> + marker = temp_buffer[0];
> + code = temp_buffer[1];
> +
> + if (marker != MESSAGE_MARKER) {
> + pr_warn("incorrect header marker (0x%02x)\n", marker);
> + return -EIO;
> + }
> +
> + if (code != STATUS_CONTINUED_READ) {
> + pr_warn("incorrect header code (0x%02x)\n", code);
> + return -EIO;
> + }
> +
> + memcpy(&message_buffer[READ_LENGTH], &temp_buffer[2], remaining_length);
> + message_buffer[total_length - 1] = MESSAGE_PADDING;
> + kfree(temp_buffer);
> +
> + return 0;
> +}
> +
> +/**
> + * syna_tcm_raw_write() - write command/data to device without receiving
> + * response
> + *
> + * @tcm_info: handle of core module
> + * @command: command to send to device
> + * @data: data to send to device
> + * @length: length of data in bytes
> + * @add_length: wether the length of the message should be added after the command
> + *
> + * A command and its data, if any, are sent to the device.
> + */
> +static int syna_tcm_raw_write(struct syna_tcm_data *tcm_info,
> + unsigned char command, unsigned char *data,
> + unsigned int length, bool add_length)
> +{
> + int retval = 0;
> + unsigned char *out_buf;
> +
> + unsigned int header_size = add_length && length ? 3 : 1;
> +
> + out_buf = kmalloc(length + header_size, GFP_KERNEL);
> + if (retval < 0)
> + return retval;
> +
> + out_buf[0] = command;
> + if (add_length && length) {
> + out_buf[1] = (unsigned char)length;
> + out_buf[2] = (unsigned char)(length >> 8);
> + }
> +
> + if (length)
> + memcpy(&out_buf[header_size], data, length);
> +
> + retval = touch_i2c_continue_write(tcm_info->client, out_buf,
> + length + header_size);
> + if (retval < 0) {
> + kfree(out_buf);
> + return retval;
> + }
> +
> + kfree(out_buf);
> + return 0;
> +}
> +
> +/**
> + * syna_tcm_read_message() - read message from device
> + *
> + * @tcm_info: handle of core module
> + * @length: length of data in bytes in raw read mode
> + */
> +static int syna_tcm_read_message(struct syna_tcm_data *tcm_info,
> + unsigned int length)
> +{
> + int retval = 0;
> + unsigned int total_length = 0, payload_length = 0;
> + unsigned char *message_buffer;
> + struct syna_tcm_message_header *header = NULL;
> +
> + message_buffer = kmalloc(READ_LENGTH, GFP_KERNEL);
> + if (!message_buffer)
> + return -ENOMEM;
> +
> + retval = touch_i2c_continue_read(tcm_info->client, message_buffer,
> + READ_LENGTH);
> + if (retval < 0)
> + return retval;
> +
> + header = (struct syna_tcm_message_header *)message_buffer;
> + if (header->marker != MESSAGE_MARKER) {
> + pr_warn("wrong header marker:0x%02x\n", header->marker);
> + return -ENXIO;
> + }
> +
> + unsigned char report_code = header->code;
> +
> + payload_length = le2_to_uint(header->length);
> +
> + if (report_code <= STATUS_ERROR || report_code == STATUS_INVALID) {
> + switch (report_code) {
> + case STATUS_OK:
> + break;
> + case STATUS_CONTINUED_READ:
> + case STATUS_IDLE:
> + case STATUS_BUSY:
> + payload_length = 0;
> + kfree(message_buffer);
> + return 0;
> + default:
> + if (report_code != STATUS_ERROR) {
> + pr_warn("IO ERROR");
> + kfree(message_buffer);
> + return -EIO;
> + }
> + }
> + }
> +
> + total_length = MESSAGE_HEADER_SIZE + payload_length + 1;
> +
> + unsigned char *temp_buffer = message_buffer;
> +
> + message_buffer = kmalloc(total_length, GFP_KERNEL);
> + if (!message_buffer)
> + return -ENOMEM;
> +
> + // Copy data already read to message_buffer
> + memcpy(message_buffer, temp_buffer, READ_LENGTH);
> + kfree(temp_buffer);
> +
> + if (payload_length == 0) {
> + message_buffer[total_length - 1] = MESSAGE_PADDING;
> + goto check_padding;
> + }
> +
> + if (MESSAGE_HEADER_SIZE + payload_length > READ_LENGTH) {
> + retval = syna_tcm_continued_read(tcm_info, payload_length,
> + message_buffer);
> + if (retval < 0) {
> + pr_warn("failed to do continued read\n");
> + return retval;
> + };
> + }
> +
> +check_padding:
> + if (message_buffer[total_length - 1] != MESSAGE_PADDING) {
> + pr_warn("missing message padding");
> + return -EIO;
> + }
> +
> + if (tcm_info->response_buf != NULL)
> + kfree(tcm_info->response_buf);
> +
> + tcm_info->response_buf = message_buffer;
> + tcm_info->response_length = total_length;
> +
> + return 0;
> +}
> +
> +static int syna_tcm_write_message(struct syna_tcm_data *tcm_info,
> + unsigned char command, unsigned char *payload,
> + unsigned int length, unsigned char **resp_buf,
> + unsigned int *resp_length)
> +{
> + int retval = 0;
> +
> + if (resp_buf == NULL) {
> + retval = syna_tcm_raw_write(tcm_info, command, payload, length,
> + false);
> + goto exit;
> + }
> + reinit_completion(&response_complete);
> +
> + tcm_info->response_buf = *resp_buf;
> + tcm_info->response_length = *resp_length;
> +
> + // Here write command to device
Please follow kernel comment style (/* ... */)
> + retval = syna_tcm_raw_write(tcm_info, command, payload, length, true);
> + if (retval != 0)
> + goto exit;
> +
> + retval = wait_for_completion_timeout(&response_complete,
> + RESPONSE_TIMEOUT_MS);
> + if (retval == 0) {
> + pr_warn("timed out waiting for response (command 0x%02x)\n",
> + command);
> + retval = -EIO;
> + }
> +
> +exit:
> + if (tcm_info->response_length < 0)
> + return -1;
> + if (resp_buf != NULL) {
> + *resp_buf = tcm_info->response_buf;
> + *resp_length = tcm_info->response_length;
> + }
> +
> + return retval;
> +}
> +
> +static int syna_tcm_set_normal_report_config(struct syna_tcm_data *tcm_info)
This prints a warning on every compile because it's unused. Add the
__maybe_unused attribute and a comment explaining what it does and why
it's not used if it's really useful to have it here, or just remove it
from this version of the driver.
> +{
> + int retval;
> + unsigned int idx = 0;
> + unsigned int length;
> +
> + length = le2_to_uint(tcm_info->app_info.max_touch_report_config_size);
> +
> + if (length < TOUCH_REPORT_CONFIG_SIZE) {
> + pr_warn("invalid maximum touch report config size: %d\n",
> + length);
> + return -EINVAL;
> + }
> +
> + unsigned char *report_buf = kmalloc(length, GFP_KERNEL);
> +
> + if (!report_buf)
> + return -ENOMEM;
> +
> + report_buf[idx++] = TOUCH_FOREACH_ACTIVE_OBJECT;
> + report_buf[idx++] = TOUCH_OBJECT_N_INDEX;
> + report_buf[idx++] = 4;
> + report_buf[idx++] = TOUCH_OBJECT_N_CLASSIFICATION;
> + report_buf[idx++] = 4;
> + report_buf[idx++] = TOUCH_OBJECT_N_X_POSITION;
> + report_buf[idx++] = 16;
> + report_buf[idx++] = TOUCH_OBJECT_N_Y_POSITION;
> + report_buf[idx++] = 16;
> + report_buf[idx++] = TOUCH_OBJECT_N_X_WIDTH;
> + report_buf[idx++] = 12;
> + report_buf[idx++] = TOUCH_OBJECT_N_Y_WIDTH;
> + report_buf[idx++] = 12;
> + report_buf[idx++] = TOUCH_FOREACH_END;
> + report_buf[idx++] = TOUCH_END;
> +
> + unsigned char *resp_buf = NULL;
> + unsigned int resp_length = 0;
> +
> + retval = syna_tcm_write_message(tcm_info, CMD_SET_TOUCH_REPORT_CONFIG,
> + report_buf, length, &resp_buf,
> + &resp_length);
> + if (retval < 0) {
> + pr_warn("failed to set report config");
> + return retval;
> + }
> +
> + kfree(resp_buf);
> +
> + return retval;
> +}
> +
> +static int syna_tcm_get_report_config(struct syna_tcm_data *tcm_info)
> +{
> + int retval;
> + unsigned char *resp_buf = NULL;
> + unsigned int resp_length = 0;
> +
> + retval = syna_tcm_write_message(tcm_info, CMD_GET_TOUCH_REPORT_CONFIG,
> + NULL, 0, &resp_buf, &resp_length);
> + if (retval < 0) {
> + pr_warn("failed to write command 0x%02x\n",
> + CMD_GET_TOUCH_REPORT_CONFIG);
> + return retval;
> + }
> +
> + tcm_info->report_size = resp_length - MESSAGE_HEADER_SIZE - 1;
> +
> + kfree(tcm_info->report_config);
> + tcm_info->report_config = kmalloc(tcm_info->report_size, GFP_KERNEL);
> +
> + memcpy(tcm_info->report_config, &resp_buf[MESSAGE_HEADER_SIZE],
> + tcm_info->report_size);
> +
> + return 0;
> +}
> +
> +static int syna_tcm_get_app_info(struct syna_tcm_data *tcm_info)
> +{
> + int retval = 0;
> + unsigned char *resp_buf = NULL;
> + unsigned int resp_length = 0;
> + unsigned int timeout = RESPONSE_TIMEOUT_MS;
> +
> +get_app_info:
> + retval = syna_tcm_write_message(tcm_info, CMD_GET_APPLICATION_INFO,
> + NULL, 0, &resp_buf, &resp_length);
> + if (retval < 0) {
> + pr_warn("failed to write command 0x%02x\n",
> + CMD_GET_APPLICATION_INFO);
> + goto exit;
> + }
> +
> + memcpy(&tcm_info->app_info, &resp_buf[MESSAGE_HEADER_SIZE],
> + sizeof(tcm_info->app_info));
> +
> + tcm_info->app_status = le2_to_uint(tcm_info->app_info.status);
> +
> + if (tcm_info->app_status == APP_STATUS_BOOTING ||
> + tcm_info->app_status == APP_STATUS_UPDATING) {
> + if (timeout > 0) {
> + msleep(APP_STATUS_POLL_MS);
> + timeout -= APP_STATUS_POLL_MS;
> + goto get_app_info;
> + }
> + }
> +
> + retval = 0;
> +
> +exit:
> + kfree(resp_buf);
> +
> + return retval;
> +}
> +
> +static int syna_tcm_identify(struct syna_tcm_data *tcm_info)
> +{
> + int retval = 0;
> + unsigned char *resp_buf = NULL;
> + unsigned int resp_length = 0;
> +
> + retval = syna_tcm_write_message(tcm_info, CMD_IDENTIFY, NULL, 0,
> + &resp_buf, &resp_length);
> + if (retval < 0)
> + goto exit;
> +
> + memcpy(&tcm_info->id_info, &resp_buf[MESSAGE_HEADER_SIZE],
> + sizeof(tcm_info->id_info));
> +
> + if (tcm_info->id_info.mode == MODE_APPLICATION)
> + retval = syna_tcm_get_app_info(tcm_info);
> +
> +exit:
> + kfree(resp_buf);
> +
> + return retval;
> +}
> +
> +static int syna_tcm_run_application_firmware(struct syna_tcm_data *tcm_info)
> +{
> + int retval = 0;
> + unsigned int retry = 3;
> + unsigned char *resp_buf = NULL;
> + unsigned int resp_length = 0;
> +
> +retry:
> + retval = syna_tcm_write_message(tcm_info, CMD_RUN_APPLICATION_FIRMWARE,
> + NULL, 0, &resp_buf, &resp_length);
> +
> + if (retval < 0) {
> + if (retry--)
> + goto retry;
> + goto exit;
> + }
> +
> + retval = syna_tcm_identify(tcm_info);
> + if (retval < 0) {
> + if (retry--)
> + goto retry;
> + goto exit;
> + }
> +
> + pr_info("syna_tcm: boot_mode: 0x%02x", tcm_info->id_info.mode);
> +
> + if (tcm_info->id_info.mode != MODE_APPLICATION) {
> + if (retry--)
> + goto retry;
> + retval = -EINVAL;
> + goto exit;
> + } else if (tcm_info->app_status != APP_STATUS_OK) {
> + pr_warn("syna_tcm: application status = 0x%02x\n",
> + tcm_info->app_status);
> + if (retry--)
> + goto retry;
> + }
> +
> + retval = 0;
> +
> +exit:
> + kfree(resp_buf);
> +
> + return retval;
> +}
> +
> +/*
> + * syna_get_report_data - Retrieve data from touch report
> + *
> + * @tcm_info: handle of tcm module
> + * @offset: start bit of retrieved data
> + * @bits: total bits of retrieved data
> + * @data: pointer of data, at most 4 byte
> + * Retrieve data from the touch report based on the bit offset and bit length
> + * information from the touch report configuration.
> + */
> +static int syna_tcm_get_report_data(unsigned char *report_buf,
> + unsigned int report_buf_length,
> + unsigned int offset, unsigned int num_bits,
> + unsigned int *data)
> +{
> + unsigned char mask = 0;
> + unsigned char byte_data = 0;
> + unsigned int output_data = 0;
> + unsigned int bit_offset = offset % 8;
> + unsigned int byte_offset = offset / 8;
> + unsigned int data_bits = 0;
> + unsigned int available_bits = 0;
> + unsigned int remaining_bits = num_bits;
> +
> + if (num_bits == 0 || num_bits > 32) {
> + pr_warn("report value larger than 32 bits: %d\n", num_bits);
> + memcpy(data, &report_buf[byte_offset], num_bits / 8);
> + return 0;
> + }
> +
> + if ((offset + num_bits) > report_buf_length * 8) {
> + pr_warn("report: offset and bits beyond total read length: %d vs %d bits",
> + offset + num_bits, report_buf_length * 8);
> + *data = 0;
> + return -1;
> + }
> +
> + while (remaining_bits) {
> + byte_data = report_buf[byte_offset];
> + byte_data >>= bit_offset;
> +
> + available_bits = 8 - bit_offset;
> + data_bits = available_bits < remaining_bits ? available_bits :
> + remaining_bits;
> + mask = 0xff >> (8 - data_bits);
> +
> + byte_data &= mask;
> +
> + output_data |= byte_data << (num_bits - remaining_bits);
> +
> + bit_offset = 0;
> + byte_offset += 1;
> + remaining_bits -= data_bits;
> + }
> +
> + *data = output_data;
> +
> + return 0;
> +}
> +
> +static int syna_tcm_parse_touch_report(struct syna_tcm_data *tcm_info)
> +{
> + int config_data_pointer = 0, obj = 0, foreach_start = 0, foreach_end,
> + retval;
> + unsigned int offset = 0, num_bits, data = 0;
> + unsigned char *report_config = tcm_info->report_config;
> + unsigned int config_size = tcm_info->report_size;
> +
> + unsigned char *report = &tcm_info->response_buf[MESSAGE_HEADER_SIZE];
> + unsigned int report_size =
> + tcm_info->response_length - MESSAGE_HEADER_SIZE - 1;
> + unsigned char code;
> +
> + struct touch_data *touch_data =
> + kmalloc(sizeof(touch_data) * tcm_info->touchpanel_max_objects,
> + GFP_KERNEL);
Calling kmalloc in the hot patch for every single touch event is not
great, we have IRQF_ONESHOT so it's fine to have a buffer allocated once
and re-use it here, you don't need any locking.
> + memset(touch_data, 0,
> + sizeof(touch_data) * tcm_info->touchpanel_max_objects);
> +
> + while (config_data_pointer < config_size) {
> + code = report_config[config_data_pointer++];
> + switch (code) {
> + case TOUCH_END:
> + goto exit;
> + case TOUCH_FOREACH_ACTIVE_OBJECT:
> + obj = 0;
> + foreach_start = config_data_pointer;
> + if (offset >= report_size * 8)
> + goto exit;
> + break;
> + case TOUCH_FOREACH_END:
> + foreach_end = config_data_pointer;
> + if (offset < report_size * 8)
> + config_data_pointer = foreach_start;
> + break;
> + // Ignored
> + case TOUCH_OBJECT_N_TX_POSITION_TIXELS:
> + case TOUCH_OBJECT_N_RX_POSITION_TIXELS:
> + case TOUCH_FRAME_RATE:
> + case TOUCH_0D_BUTTONS_STATE:
> + case 30: // I don't know what command 30 is and it isn't in the downstream driver. After it comes a length of 8 bits and this is ignored
> + num_bits = report_config[config_data_pointer++];
> + offset += num_bits;
> + break;
> + case TOUCH_PAD_TO_NEXT_BYTE:
> + offset = ceil_div(offset, 8) * 8;
> + break;
> + case TOUCH_OBJECT_N_INDEX:
> + num_bits = report_config[config_data_pointer++];
> + retval = syna_tcm_get_report_data(
> + report, report_size, offset, num_bits, &obj);
> + if (retval < 0) {
> + pr_warn("failed to get object index\n");
> + return retval;
> + }
> + offset += num_bits;
> + break;
> + case TOUCH_OBJECT_N_CLASSIFICATION:
> + num_bits = report_config[config_data_pointer++];
> + retval = syna_tcm_get_report_data(
> + report, report_size, offset, num_bits, &data);
> + if (retval < 0) {
> + pr_warn("failed to get object classification\n");
> + return retval;
> + }
> + if (obj >= tcm_info->touchpanel_max_objects) {
> + pr_warn("too many objects\n");
> + return -1;
> + }
> + touch_data[obj].status = data;
> + offset += num_bits;
> + break;
> + case TOUCH_OBJECT_N_X_POSITION:
> + num_bits = report_config[config_data_pointer++];
> + retval = syna_tcm_get_report_data(
> + report, report_size, offset, num_bits, &data);
> + if (retval < 0) {
> + pr_warn("failed to get object x position\n");
> + return retval;
> + }
> + touch_data[obj].x_pos = data;
> + offset += num_bits;
> + break;
> + case TOUCH_OBJECT_N_Y_POSITION:
> + num_bits = report_config[config_data_pointer++];
> + retval = syna_tcm_get_report_data(
> + report, report_size, offset, num_bits, &data);
> + if (retval < 0) {
> + pr_warn("failed to get object y position\n");
> + return retval;
> + }
> + touch_data[obj].y_pos = data;
> + offset += num_bits;
> + break;
> + case TOUCH_OBJECT_N_Z:
> + num_bits = report_config[config_data_pointer++];
> + retval = syna_tcm_get_report_data(
> + report, report_size, offset, num_bits, &data);
> + if (retval < 0) {
> + pr_warn("failed to get object z\n");
> + return retval;
> + }
> + touch_data[obj].z = data;
> + offset += num_bits;
> + break;
> + case TOUCH_OBJECT_N_X_WIDTH:
> + num_bits = report_config[config_data_pointer++];
> + retval = syna_tcm_get_report_data(
> + report, report_size, offset, num_bits, &data);
> + if (retval < 0) {
> + pr_warn("failed to get object x width\n");
> + return retval;
> + }
> + touch_data[obj].x_width = data;
> + offset += num_bits;
> + break;
> + case TOUCH_OBJECT_N_Y_WIDTH:
> + num_bits = report_config[config_data_pointer++];
> + retval = syna_tcm_get_report_data(
> + report, report_size, offset, num_bits, &data);
> + if (retval < 0) {
> + pr_warn("failed to get object y width\n");
> + return retval;
> + }
> + touch_data[obj].y_width = data;
> + offset += num_bits;
> + break;
> + default:
> + pr_notice("unrecognized touch report config code: %d",
> + code);
This should be a debug print
> + }
> + }
> +
> +exit:
> + for (int i = 0; i < tcm_info->touchpanel_max_objects; i++) {
> + if (touch_data[i].status == NOP)
> + continue;
> +
> + bool lift = touch_data[i].status == LIFT ? true : false;
> +
> + input_mt_slot(tcm_info->input, i);
> + input_mt_report_slot_state(tcm_info->input, MT_TOOL_FINGER,
> + !lift);
> +
> + int x_width = touch_data[i].x_width;
> + int y_width = touch_data[i].y_width;
> + int major_width = x_width > y_width ? x_width : y_width;
> + int minor_width = x_width > y_width ? y_width : x_width;
> + int x_is_major = x_width > y_width ? true : false;
> +
> + if (!lift) {
> + input_report_abs(tcm_info->input, ABS_MT_POSITION_X,
> + touch_data[i].x_pos);
> + input_report_abs(tcm_info->input, ABS_MT_POSITION_Y,
> + touch_data[i].y_pos);
> + input_report_abs(tcm_info->input, ABS_MT_TOUCH_MAJOR,
> + major_width);
> + input_report_abs(tcm_info->input, ABS_MT_TOUCH_MINOR,
> + minor_width);
> + input_report_abs(tcm_info->input, ABS_MT_ORIENTATION,
> + x_is_major);
> + input_report_abs(tcm_info->input, ABS_MT_PRESSURE,
> + touch_data[i].z);
> + }
> +
> + input_sync(tcm_info->input);
> + }
> +
> + kfree(touch_data);
> + return 0;
> +}
> +
> +static irqreturn_t syna_irq_handler(int irq, void *dev)
> +{
> + int retval;
> + struct syna_tcm_data *tcm_info = dev;
> +
> + retval = syna_tcm_read_message(tcm_info, 0);
> + if (retval < 0) {
> + tcm_info->response_length = -1;
> + goto exit;
> + }
> +
> + if (tcm_info->response_buf[1] == REPORT_TOUCH)
Aha, found your bug... I see places where response_buf gets free'd
(why??) and I guess you're hitting this codepath after it's free. The
null pointer is actually address 0x1.
> + syna_tcm_parse_touch_report(tcm_info);
> +
> +exit:
> + if (tcm_info->response_buf[1] <= REPORT_IDENTIFY)
Or here...
> + complete(&response_complete);
I'll leave it here for now, I'd appreciate it if you CC me in the next
revision (and the other lists as Krzyzstof said -- don't forget
phone-devel!).
Kind regards,
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int syna_tcm_power_on(struct syna_tcm_data *tcm_info)
> +{
> + int ret;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(tcm_info->regulators),
> + tcm_info->regulators);
> + if (ret)
> + return ret;
> +
> + gpiod_set_value(tcm_info->reset_gpio, false);
> + msleep(POWERUP_TO_RESET_TIME);
> + gpiod_set_value(tcm_info->reset_gpio, true);
> + msleep(RESET_TO_NORMAL_TIME);
> +
> + return 0;
> +}
> +
> +static int syna_tcm_probe(struct i2c_client *client)
> +{
> + struct syna_tcm_data *tcm_info;
> + int err;
> +
> + pr_info("starting probe for syna_tcm_oncell touchscreen");
> +
> + if (!i2c_check_functionality(client->adapter,
> + I2C_FUNC_I2C | I2C_FUNC_SMBUS_BYTE_DATA |
> + I2C_FUNC_SMBUS_I2C_BLOCK))
> + return -ENODEV;
> +
> + tcm_info = devm_kzalloc(&client->dev, sizeof(*tcm_info), GFP_KERNEL);
> + if (!tcm_info)
> + return -ENOMEM;
> +
> + i2c_set_clientdata(client, tcm_info);
> + tcm_info->client = client;
> + tcm_info->response_buf = NULL;
> +
> + of_property_read_u32(client->dev.of_node, "max-objects",
> + &tcm_info->touchpanel_max_objects);
> +
> + tcm_info->reset_gpio =
> + gpiod_get_index(&client->dev, "reset", 0, GPIOD_OUT_HIGH);
> +
> + tcm_info->regulators[SYNA_TCM_ONCELL_REGULATOR_VDD].supply = "vdd";
> + tcm_info->regulators[SYNA_TCM_ONCELL_REGULATOR_VCC].supply = "vcc";
> + err = devm_regulator_bulk_get(&client->dev,
> + ARRAY_SIZE(tcm_info->regulators),
> + tcm_info->regulators);
> + if (err)
> + return err;
> +
> + // TODO: uncomment once syna_tcm_power_off is implemented
> + // err = devm_add_action_or_reset(&client->dev, syna_tcm_oncell_power_off, tcm_info);
> + // if (err)
> + // return err;
> +
> + err = syna_tcm_power_on(tcm_info);
> + if (err < 0)
> + return err;
> +
> + // This needs to happen before the first write to the device
> + err = devm_request_threaded_irq(&client->dev, client->irq, NULL,
> + syna_irq_handler,
> + IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> + "syna_tcm_oncell_irq", tcm_info);
> + if (err)
> + return err;
> +
> + err = syna_tcm_run_application_firmware(tcm_info);
> + if (err < 0)
> + return err;
> +
> + // err = syna_tcm_set_normal_report_config(tcm_info);
> + // if (err < 0)
> + // pr_err("syna_tcm: failed to set normal touch report config")
> +
> + err = syna_tcm_get_report_config(tcm_info);
> + if (err < 0)
> + return err;
> +
> + tcm_info->input = devm_input_allocate_device(&client->dev);
> + if (!tcm_info->input)
> + return -ENOMEM;
> +
> + tcm_info->input->name = TOUCHPANEL_DEVICE;
> + tcm_info->input->id.bustype = BUS_I2C;
> +
> + input_set_abs_params(tcm_info->input, ABS_MT_POSITION_X, 0,
> + le2_to_uint(tcm_info->app_info.max_x), 0, 0);
> + input_set_abs_params(tcm_info->input, ABS_MT_POSITION_Y, 0,
> + le2_to_uint(tcm_info->app_info.max_y), 0, 0);
> + input_set_abs_params(tcm_info->input, ABS_MT_TOUCH_MAJOR, 0, 255, 0, 0);
> + input_set_abs_params(tcm_info->input, ABS_MT_TOUCH_MINOR, 0, 255, 0, 0);
> + input_set_abs_params(tcm_info->input, ABS_MT_PRESSURE, 0, 255, 0, 0);
> +
> + touchscreen_parse_properties(tcm_info->input, true, &tcm_info->prop);
> +
> + err = input_mt_init_slots(tcm_info->input,
> + tcm_info->touchpanel_max_objects,
> + INPUT_MT_DIRECT);
> + if (err)
> + return err;
> +
> + input_set_drvdata(tcm_info->input, tcm_info);
> +
> + err = input_register_device(tcm_info->input);
> + if (err)
> + return err;
> +
> + pr_info("syna_tcm: probe done");
> + tcm_info->initialize_done = true;
> +
> + return 0;
> +}
> +
> +static const struct of_device_id syna_driver_ids[] = {
> + {
> + .compatible = "syna,s3908",
> + },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, syna_driver_ids);
> +
> +static const struct i2c_device_id syna_i2c_ids[] = { { TOUCHPANEL_DEVICE, 0 },
> + {} };
> +MODULE_DEVICE_TABLE(i2c, syna_i2c_ids);
> +
> +// static const struct dev_pm_ops syna_pm_ops = {
> +// .suspend = syna_i2c_suspend,
> +// .resume = syna_i2c_resume,
> +// };
> +
> +static struct i2c_driver syna_i2c_driver = {
> + .probe = syna_tcm_probe,
> + // .remove = syna_i2c_remove,
> + // .shutdown = syna_tp_shutdown,
> + .id_table = syna_i2c_ids,
> + .driver = {
> + .name = TOUCHPANEL_DEVICE,
> + .of_match_table = syna_driver_ids,
> + // .pm = &syna_pm_ops,
> + },
> +};
> +
> +module_i2c_driver(syna_i2c_driver);
--
// Caleb (they/them)
^ permalink raw reply
* [PATCH v2] HID: i2c-hid: Revert to await reset ACK before reading report descriptor
From: Kenny Levinsen @ 2024-03-31 18:24 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Douglas Anderson, Hans de Goede, linux-input, linux-kernel,
Kenny Levinsen
In af93a167eda9, i2c_hid_parse was changed to continue with reading the
report descriptor before waiting for reset to be acknowledged.
This has lead to two regressions:
1. We fail to handle reset acknowledgement if it happens while reading
the report descriptor. The transfer sets I2C_HID_READ_PENDING, which
causes the IRQ handler to return without doing anything.
This affects both a Wacom touchscreen and a Sensel touchpad.
2. On a Sensel touchpad, reading the report descriptor this quickly
after reset results in all zeroes or partial zeroes.
The issues were observed on the Lenovo Thinkpad Z16 Gen 2.
The change in question was made based on a Microsoft article[0] stating
that Windows 8 *may* read the report descriptor in parallel with
awaiting reset acknowledgement, intended as a slight reset performance
optimization. Perhaps they only do this if reset is not completing
quickly enough for their tastes?
As the code is not currently ready to read registers in parallel with a
pending reset acknowledgement, and as reading quickly breaks the report
descriptor on the Sensel touchpad, revert to waiting for reset
acknowledgement before proceeding to read the report descriptor.
[0]: https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/plug-and-play-support-and-power-management
Fixes: af93a167eda9 ("HID: i2c-hid: Move i2c_hid_finish_hwreset() to after reading the report-descriptor")
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
---
drivers/hid/i2c-hid/i2c-hid-core.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index 2df1ab3c31cc..72d2bccf5621 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -735,9 +735,12 @@ static int i2c_hid_parse(struct hid_device *hid)
mutex_lock(&ihid->reset_lock);
do {
ret = i2c_hid_start_hwreset(ihid);
- if (ret)
+ if (ret == 0)
+ ret = i2c_hid_finish_hwreset(ihid);
+ else
msleep(1000);
} while (tries-- > 0 && ret);
+ mutex_unlock(&ihid->reset_lock);
if (ret)
goto abort_reset;
@@ -767,16 +770,8 @@ static int i2c_hid_parse(struct hid_device *hid)
}
}
- /*
- * Windows directly reads the report-descriptor after sending reset
- * and then waits for resets completion afterwards. Some touchpads
- * actually wait for the report-descriptor to be read before signalling
- * reset completion.
- */
- ret = i2c_hid_finish_hwreset(ihid);
abort_reset:
clear_bit(I2C_HID_RESET_PENDING, &ihid->flags);
- mutex_unlock(&ihid->reset_lock);
if (ret)
goto out;
--
2.44.0
^ permalink raw reply related
* Re: [PATCH] HID: i2c-hid: Revert to await reset ACK before reading report descriptor
From: Kenny Levinsen @ 2024-03-31 18:23 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Douglas Anderson, Hans de Goede, linux-input, linux-kernel
In-Reply-To: <20240331132332.6694-1-kl@kl.wtf>
On 3/31/24 3:23 PM, Kenny Levinsen wrote:
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 2df1ab3c31cc..be5d661dde41 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -737,7 +737,9 @@ static int i2c_hid_parse(struct hid_device *hid)
> ret = i2c_hid_start_hwreset(ihid);
> if (ret)
> msleep(1000);
> + ret = i2c_hid_finish_hwreset(ihid);
Ah, missed the check to only call i2c_hid_finish_hwreset if
i2c_hid_start_hwreset succeeded, v2 incoming.
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-03-30 12:19 UTC (permalink / raw)
To: Suzuki K Poulose, Russell King, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Eric Auger,
Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with coresight conversion to platform driver? Worst
>
> Yes.
>
>> case it is solveable: just drop .owner.
>
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.
I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.
Best regards,
Krzysztof
X-sender: <linux-kernel+bounces-125722-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com
X-CreatedBy: MSExchange15
X-HeloDomain: mbx-essen-01.secunet.de
X-ExtendedProps: BQBjAAoAh4ymlidQ3AgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwA/AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5EaXJlY3RvcnlEYXRhLk1haWxEZWxpdmVyeVByaW9yaXR5DwADAAAATG93
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 10.53.40.197
X-EndOfInjectedXHeaders: 14356
Received: from mbx-essen-01.secunet.de (10.53.40.197) by
mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Sat, 30 Mar 2024 13:19:38 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-01.secunet.de
(10.53.40.201) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
Transport; Sat, 30 Mar 2024 13:19:38 +0100
Received: from localhost (localhost [127.0.0.1])
by b.mx.secunet.com (Postfix) with ESMTP id B23AF20322
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 13:19:38 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=unavailable autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
dkim=pass (2048-bit key) header.d=linaro.org
Received: from b.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1O3XCRA_zcxq for <steffen.klassert@secunet.com>;
Sat, 30 Mar 2024 13:19:38 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.199.223; helo=ny.mirrors.kernel.org; envelope-from=linux-kernel+bounces-125722-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com 116D82025D
Authentication-Results: b.mx.secunet.com;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by b.mx.secunet.com (Postfix) with ESMTPS id 116D82025D
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 13:19:38 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id D1F5C1C21191
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 12:19:36 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 3604138FA0;
Sat, 30 Mar 2024 12:19:14 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4CAFA2BB14
for <linux-kernel@vger.kernel.org>; Sat, 30 Mar 2024 12:19:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711801151; cv=none; b=ixWxAGCKInnwN9unufhlFm4eAhpYUIq+/6LEl1krKKFhGpqzIW5e+Y9A3K0uVDPfwZRETY/bp/yIu8C4oSkudbcxI9GyR73I1UGo4plKoJMQbj+1vTT9AsLo1kCO6VLsJHW4NCEw/RaL21NQSxLjgXQetxtfysU8jtSss5eZpOA=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711801151; c=relaxed/simple;
bh=gnEUiTCGAKgaizTXQISk0bLTxTnE9U1qA4LHHyfKv8g=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=kHVv3D3H5HIwGFTnVbXfF40naFVBZJQDZSYEDmA16BRv+z5Wr4eaM0kfcQw2lPi96USyLJ8eO1hOcJgGs71zEqUUv0iViM3O5enW6crZGDfvgHUZNMrTYcwlrQaRJeaLjcaOWe5EnTC4c0kracol+FUJ9RGnTHYKqhbhPUKkXzs=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=bTDp6mzS; arc=none smtp.client-ip=209.85.221.42
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org
Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-33ddd1624beso1664582f8f.1
for <linux-kernel@vger.kernel.org>; Sat, 30 Mar 2024 05:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=linaro.org; s=google; t=1711801148; x=1712405948; darn=vger.kernel.org;
h=content-transfer-encoding:in-reply-to:autocrypt:from
:content-language:references:cc:to:subject:user-agent:mime-version
:date:message-id:from:to:cc:subject:date:message-id:reply-to;
bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
b=bTDp6mzSAuWx4lL5cooxcDpZ9W1mea8O0kdKPspePGuynZIKtNZ/QodKPUZUYN6Sxn
bqgHPtu7au3ng4zlAbkXPtudj/aOo+e/SYgeh3gbkQs3UFieCRn6QafMakiJalsq+lK3
hRdc3OS2wTijyLDh8yYEofGgKTNGupdxOeqdDR9HQGdzBeiJpnXWjIZ/5X/bPmICFzv6
Q7CGGrTCphDqmfQ7M/Vv0ypdsFDyCkarg5/LBvAAefhoqAV1HezQHE9XBLoiN1+Ekq9f
QadJbIRoslyjrl6gukO+WRurbyLtrkeopHU0OJvO2+HQbPl8W+KV2yiYvjnied+VaIHN
I0vA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1711801148; x=1712405948;
h=content-transfer-encoding:in-reply-to:autocrypt:from
:content-language:references:cc:to:subject:user-agent:mime-version
:date:message-id:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
b=Uyrhl0iS+HHVPcHD9JlplLUc3LKvZC+9zSGrS2p4ngVUqA6Loz5ajRMtwiNehHz8ce
7ZWBmNfUzCuFmBy1kU8kDWGP2aTESYuKYABKEI1oUkOKzhtQJfLz7u2czRFbTK/5KxCT
X0x4hsD7Xbxk4oj6Lb+MYe4iq+Ybpt9ja83fE4NRPcMWBltsCZ/RQqbWpPlry1/K+YsV
WSChQjhDeFn3PozhiA4eVndXL3m5YAy/R9mJqfnGg7ztADohvFX02HnZbGAm5bZubyhg
IKaaInkPEzpN+ptYDCcu/nzP6K+caGfu3zhYn/Jtc5zC9qnAz+3pvhkSPaPrss1uFl7/
2ybw==
X-Gm-Message-State: AOJu0YxZ4OKcnV48ikILJpVo5WNPXxvrQrDAoY76tNm4EwGlI8iPL9Bi
8IxHqIZkR/GrquTBwdosOuZ+cANUxsESnEUWp8mQ1Ss2/sTp/7VUYlbF+HKGiLQ=
X-Google-Smtp-Source: AGHT+IGxitXr7L7h8CUcKtleeDnrSZmBoUk9QkYBw9ltjVABur0LBmd4a6MEByPy5E4LS7vzmYpyOA==
X-Received: by 2002:adf:f403:0:b0:343:39a6:93bc with SMTP id g3-20020adff403000000b0034339a693bcmr3335018wro.11.1711801147697;
Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Received: from [192.168.1.20] ([178.197.223.16])
by smtp.gmail.com with ESMTPSA id v17-20020adfe291000000b0034174566ec4sm6339522wri.16.2024.03.30.05.19.05
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Message-ID: <edd167fb-df0c-4434-8f9f-7c4016b87d83@linaro.org>
Date: Sat, 30 Mar 2024 13:19:05 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 00/19] amba: store owner from modules with
amba_driver_register()
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
Russell King <linux@armlinux.org.uk>, Mike Leach <mike.leach@linaro.org>,
James Clark <james.clark@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Linus Walleij <linus.walleij@linaro.org>, Andi Shyti
<andi.shyti@kernel.org>, Olivia Mackall <olivia@selenic.com>,
Herbert Xu <herbert@gondor.apana.org.au>, Vinod Koul <vkoul@kernel.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Michal Simek <michal.simek@amd.com>, Eric Auger <eric.auger@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>
Cc: linux-kernel@vger.kernel.org, coresight@lists.linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com, linux-i2c@vger.kernel.org,
linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
linux-input@vger.kernel.org, kvm@vger.kernel.org
References: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
<3f61d6d3-a0d6-4c49-b094-6ba62d09ab14@arm.com>
<f23f2e60-e5c0-4c3c-9722-dba63a6e7ef6@linaro.org>
<d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Language: en-US
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Autocrypt: addr=krzysztof.kozlowski@linaro.org; keydata=
xsFNBFVDQq4BEAC6KeLOfFsAvFMBsrCrJ2bCalhPv5+KQF2PS2+iwZI8BpRZoV+Bd5kWvN79
cFgcqTTuNHjAvxtUG8pQgGTHAObYs6xeYJtjUH0ZX6ndJ33FJYf5V3yXqqjcZ30FgHzJCFUu
JMp7PSyMPzpUXfU12yfcRYVEMQrmplNZssmYhiTeVicuOOypWugZKVLGNm0IweVCaZ/DJDIH
gNbpvVwjcKYrx85m9cBVEBUGaQP6AT7qlVCkrf50v8bofSIyVa2xmubbAwwFA1oxoOusjPIE
J3iadrwpFvsZjF5uHAKS+7wHLoW9hVzOnLbX6ajk5Hf8Pb1m+VH/E8bPBNNYKkfTtypTDUCj
NYcd27tjnXfG+SDs/EXNUAIRefCyvaRG7oRYF3Ec+2RgQDRnmmjCjoQNbFrJvJkFHlPeHaeS
BosGY+XWKydnmsfY7SSnjAzLUGAFhLd/XDVpb1Een2XucPpKvt9ORF+48gy12FA5GduRLhQU
vK4tU7ojoem/G23PcowM1CwPurC8sAVsQb9KmwTGh7rVz3ks3w/zfGBy3+WmLg++C2Wct6nM
Pd8/6CBVjEWqD06/RjI2AnjIq5fSEH/BIfXXfC68nMp9BZoy3So4ZsbOlBmtAPvMYX6U8VwD
TNeBxJu5Ex0Izf1NV9CzC3nNaFUYOY8KfN01X5SExAoVTr09ewARAQABzTRLcnp5c3p0b2Yg
S296bG93c2tpIDxrcnp5c3p0b2Yua296bG93c2tpQGxpbmFyby5vcmc+wsGUBBMBCgA+FiEE
m9B+DgxR+NWWd7dUG5NDfTtBYpsFAmI+BxMCGwMFCRRfreEFCwkIBwIGFQoJCAsCBBYCAwEC
HgECF4AACgkQG5NDfTtBYptgbhAAjAGunRoOTduBeC7V6GGOQMYIT5n3OuDSzG1oZyM4kyvO
XeodvvYv49/ng473E8ZFhXfrre+c1olbr1A8pnz9vKVQs9JGVa6wwr/6ddH7/yvcaCQnHRPK
mnXyP2BViBlyDWQ71UC3N12YCoHE2cVmfrn4JeyK/gHCvcW3hUW4i5rMd5M5WZAeiJj3rvYh
v8WMKDJOtZFXxwaYGbvFJNDdvdTHc2x2fGaWwmXMJn2xs1ZyFAeHQvrp49mS6PBQZzcx0XL5
cU9ZjhzOZDn6Apv45/C/lUJvPc3lo/pr5cmlOvPq1AsP6/xRXsEFX/SdvdxJ8w9KtGaxdJuf
rpzLQ8Ht+H0lY2On1duYhmro8WglOypHy+TusYrDEry2qDNlc/bApQKtd9uqyDZ+rx8bGxyY
qBP6bvsQx5YACI4p8R0J43tSqWwJTP/R5oPRQW2O1Ye1DEcdeyzZfifrQz58aoZrVQq+innR
aDwu8qDB5UgmMQ7cjDSeAQABdghq7pqrA4P8lkA7qTG+aw8Z21OoAyZdUNm8NWJoQy8m4nUP
gmeeQPRc0vjp5JkYPgTqwf08cluqO6vQuYL2YmwVBIbO7cE7LNGkPDA3RYMu+zPY9UUi/ln5
dcKuEStFZ5eqVyqVoZ9eu3RTCGIXAHe1NcfcMT9HT0DPp3+ieTxFx6RjY3kYTGLOwU0EVUNc
NAEQAM2StBhJERQvgPcbCzjokShn0cRA4q2SvCOvOXD+0KapXMRFE+/PZeDyfv4dEKuCqeh0
hihSHlaxTzg3TcqUu54w2xYskG8Fq5tg3gm4kh1Gvh1LijIXX99ABA8eHxOGmLPRIBkXHqJY
oHtCvPc6sYKNM9xbp6I4yF56xVLmHGJ61KaWKf5KKWYgA9kfHufbja7qR0c6H79LIsiYqf92
H1HNq1WlQpu/fh4/XAAaV1axHFt/dY/2kU05tLMj8GjeQDz1fHas7augL4argt4e+jum3Nwt
yupodQBxncKAUbzwKcDrPqUFmfRbJ7ARw8491xQHZDsP82JRj4cOJX32sBg8nO2N5OsFJOcd
5IE9v6qfllkZDAh1Rb1h6DFYq9dcdPAHl4zOj9EHq99/CpyccOh7SrtWDNFFknCmLpowhct9
5ZnlavBrDbOV0W47gO33WkXMFI4il4y1+Bv89979rVYn8aBohEgET41SpyQz7fMkcaZU+ok/
+HYjC/qfDxT7tjKXqBQEscVODaFicsUkjheOD4BfWEcVUqa+XdUEciwG/SgNyxBZepj41oVq
FPSVE+Ni2tNrW/e16b8mgXNngHSnbsr6pAIXZH3qFW+4TKPMGZ2rZ6zITrMip+12jgw4mGjy
5y06JZvA02rZT2k9aa7i9dUUFggaanI09jNGbRA/ABEBAAHCwXwEGAEKACYCGwwWIQSb0H4O
DFH41ZZ3t1Qbk0N9O0FimwUCYDzvagUJFF+UtgAKCRAbk0N9O0Fim9JzD/0auoGtUu4mgnna
oEEpQEOjgT7l9TVuO3Qa/SeH+E0m55y5Fjpp6ZToc481za3xAcxK/BtIX5Wn1mQ6+szfrJQ6
59y2io437BeuWIRjQniSxHz1kgtFECiV30yHRgOoQlzUea7FgsnuWdstgfWi6LxstswEzxLZ
Sj1EqpXYZE4uLjh6dW292sO+j4LEqPYr53hyV4I2LPmptPE9Rb9yCTAbSUlzgjiyyjuXhcwM
qf3lzsm02y7Ooq+ERVKiJzlvLd9tSe4jRx6Z6LMXhB21fa5DGs/tHAcUF35hSJrvMJzPT/+u
/oVmYDFZkbLlqs2XpWaVCo2jv8+iHxZZ9FL7F6AHFzqEFdqGnJQqmEApiRqH6b4jRBOgJ+cY
qc+rJggwMQcJL9F+oDm3wX47nr6jIsEB5ZftdybIzpMZ5V9v45lUwmdnMrSzZVgC4jRGXzsU
EViBQt2CopXtHtYfPAO5nAkIvKSNp3jmGxZw4aTc5xoAZBLo0OV+Ezo71pg3AYvq0a3/oGRG
KQ06ztUMRrj8eVtpImjsWCd0bDWRaaR4vqhCHvAG9iWXZu4qh3ipie2Y0oSJygcZT7H3UZxq
fyYKiqEmRuqsvv6dcbblD8ZLkz1EVZL6djImH5zc5x8qpVxlA0A0i23v5QvN00m6G9NFF0Le
D2GYIS41Kv4Isx2dEFh+/Q==
In-Reply-To: <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Return-Path: linux-kernel+bounces-125722-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 12:19:38.7569
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: 9ded166d-4895-4afd-90c2-08dc50b3ab91
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.201
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-01.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=cas-essen-01.secunet.de:TOTAL-FE=0.004|SMR=0.004(SMRPI=0.002(SMRPI-FrontendProxyAgent=0.002));2024-03-30T12:19:38.760Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-01.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-OriginalSize: 13811
X-MS-Exchange-Organization-Transport-Properties: DeliveryPriority=Low
X-MS-Exchange-Organization-Prioritization: 2:ShadowRedundancy
X-MS-Exchange-Organization-IncludeInSla: False:ShadowRedundancy
On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with coresight conversion to platform driver? Worst
>
> Yes.
>
>> case it is solveable: just drop .owner.
>
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.
I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-03-30 12:19 UTC (permalink / raw)
To: Suzuki K Poulose, Russell King, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Eric Auger,
Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with coresight conversion to platform driver? Worst
>
> Yes.
>
>> case it is solveable: just drop .owner.
>
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.
I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.
Best regards,
Krzysztof
X-sender: <kvm+bounces-13146-martin.weber=secunet.com@vger.kernel.org>
X-Receiver: <martin.weber@secunet.com> ORCPT=rfc822;martin.weber@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAJuYHy0vkvxLoOu7fW2WcxcPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAF4AAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249V2ViZXIgTWFydGluOTU1BQALABcAvgAAALMpUnVJ4+pPsL47FHo+lvtDTj1EQjIsQ049RGF0YWJhc2VzLENOPUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpLENOPUFkbWluaXN0cmF0aXZlIEdyb3VwcyxDTj1zZWN1bmV0LENOPU1pY3Jvc29mdCBFeGNoYW5nZSxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXNlY3VuZXQsREM9ZGUFAA4AEQBACf3SYEkDT461FZzDv+B7BQAdAA8ADAAAAG1ieC1lc3Nlbi0wMQUAPAACAAAPADYAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0Lk1haWxSZWNpcGllbnQuRGlzcGxheU5hbWUPAA0AAABXZWJlciwgTWFydGluBQAMAAIAAAUAbAACAAAFAFgAFwBGAAAAm5gfLS+S/Eug67t9bZZzF0NOPVdlYmVyIE1hcnRpbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAJtXp8x1Q3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAGIACgA9AAAAmooAAAUABAAUIAEAAAAYAAAAbWFydGluLndlYmVyQHNlY3VuZXQuY29tBQAGAAIAAQUAKQACAAEPAAkAAABDSUF1ZGl0ZWQCAAEFAAIABwABAAAABQADAAcAAAAAAAUABQACAAEFAGQADwADAAAASHVi
X-Source: SMTP:Default MBX-DRESDEN-01
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 19175
Received: from cas-essen-02.secunet.de (10.53.40.202) by
mbx-dresden-01.secunet.de (10.53.40.199) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Sat, 30 Mar 2024 13:19:27 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
(10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
Transport; Sat, 30 Mar 2024 13:19:27 +0100
Received: from localhost (localhost [127.0.0.1])
by b.mx.secunet.com (Postfix) with ESMTP id 8E14520322
for <martin.weber@secunet.com>; Sat, 30 Mar 2024 13:19:27 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
dkim=pass (2048-bit key) header.d=linaro.org
Received: from b.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 5WslB2upGwc9 for <martin.weber@secunet.com>;
Sat, 30 Mar 2024 13:19:27 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.199.223; helo=ny.mirrors.kernel.org; envelope-from=kvm+bounces-13146-martin.weber=secunet.com@vger.kernel.org; receiver=martin.weber@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com D48FF2025D
Authentication-Results: b.mx.secunet.com;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by b.mx.secunet.com (Postfix) with ESMTPS id D48FF2025D
for <martin.weber@secunet.com>; Sat, 30 Mar 2024 13:19:26 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id E49EB1C20DE9
for <martin.weber@secunet.com>; Sat, 30 Mar 2024 12:19:25 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 3E9FF38DDC;
Sat, 30 Mar 2024 12:19:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bTDp6mzS"
X-Original-To: kvm@vger.kernel.org
Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id E6C3B2C68A
for <kvm@vger.kernel.org>; Sat, 30 Mar 2024 12:19:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711801151; cv=none; b=d6PD/glIB0e+aV4qe4FjDLsN6JJt4dnVYomxLVEDXRi6fJ6zZNDUZ/KV6bTMXyqD9HZIud2rK4IBVnYSGVICsgrmxJswGg4y7+jDJwNyNzo1EotyDaVuk3hz6nln38Tm//4wgHYyBv4odbXJA/sAZLX7tMZtqcU4U/JEFvGEhGQ=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711801151; c=relaxed/simple;
bh=gnEUiTCGAKgaizTXQISk0bLTxTnE9U1qA4LHHyfKv8g=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=kHVv3D3H5HIwGFTnVbXfF40naFVBZJQDZSYEDmA16BRv+z5Wr4eaM0kfcQw2lPi96USyLJ8eO1hOcJgGs71zEqUUv0iViM3O5enW6crZGDfvgHUZNMrTYcwlrQaRJeaLjcaOWe5EnTC4c0kracol+FUJ9RGnTHYKqhbhPUKkXzs=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=bTDp6mzS; arc=none smtp.client-ip=209.85.221.41
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org
Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-33ed4dd8659so2362095f8f.0
for <kvm@vger.kernel.org>; Sat, 30 Mar 2024 05:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=linaro.org; s=google; t=1711801148; x=1712405948; darn=vger.kernel.org;
h=content-transfer-encoding:in-reply-to:autocrypt:from
:content-language:references:cc:to:subject:user-agent:mime-version
:date:message-id:from:to:cc:subject:date:message-id:reply-to;
bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
b=bTDp6mzSAuWx4lL5cooxcDpZ9W1mea8O0kdKPspePGuynZIKtNZ/QodKPUZUYN6Sxn
bqgHPtu7au3ng4zlAbkXPtudj/aOo+e/SYgeh3gbkQs3UFieCRn6QafMakiJalsq+lK3
hRdc3OS2wTijyLDh8yYEofGgKTNGupdxOeqdDR9HQGdzBeiJpnXWjIZ/5X/bPmICFzv6
Q7CGGrTCphDqmfQ7M/Vv0ypdsFDyCkarg5/LBvAAefhoqAV1HezQHE9XBLoiN1+Ekq9f
QadJbIRoslyjrl6gukO+WRurbyLtrkeopHU0OJvO2+HQbPl8W+KV2yiYvjnied+VaIHN
I0vA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1711801148; x=1712405948;
h=content-transfer-encoding:in-reply-to:autocrypt:from
:content-language:references:cc:to:subject:user-agent:mime-version
:date:message-id:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=pwRsl4tW7J5i09nNsaEN0WbRHBKT2ZFbRiuCSTzWq2c=;
b=nrEPfS8m/1Q8AAv+F6rrqA1pQVMNjiEpRL85VAehzxQcVpnkjpsleMxHXm8kOMRhVV
iSLZ351P7D13Aivz5ssnue7RQ48O14GQjSFZGI7EXq7HCSMaP2kRO4cWXfEhCzD7zaCI
GFwvDeB1q0t1XXuvwelGbRPC3OkkEkPw5WtfiuXP8dyyIExRMi5ik4mCewjvn15sKr8k
Fy8eMWEGOfx2lAIW0lhw8n5ddOnu+QO37mAGtcMgFrbuqOSlBdRowi+QaO9mFlDE5gwY
Ka/3gffnS/5JYEYvy6uCh5Xz8O3h2Q0UhssghW406N5rrsxWd3OmtJxWWUbm4kpXXgSd
yAFw==
X-Forwarded-Encrypted: i=1; AJvYcCXH3yO8LUdZmKjRiLMtHQef13pO4YQJjFuFtue8+UJDLWQKRLIgPJ0xNw7FW2Vp2BuWAKUaiz0NkS0/hpSsfxQWyAxU
X-Gm-Message-State: AOJu0Yyu73rgiEIPrgi3GyTka1OR/FGILwL/NmhxKjX4mvZLR6p67Arh
PYsX00nagjZCFP6nZtT8SPugth6Ot7ziZCiVulQ9IiypG3IFezpdXeDgLTZAP6A=
X-Google-Smtp-Source: AGHT+IGxitXr7L7h8CUcKtleeDnrSZmBoUk9QkYBw9ltjVABur0LBmd4a6MEByPy5E4LS7vzmYpyOA==
X-Received: by 2002:adf:f403:0:b0:343:39a6:93bc with SMTP id g3-20020adff403000000b0034339a693bcmr3335018wro.11.1711801147697;
Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Received: from [192.168.1.20] ([178.197.223.16])
by smtp.gmail.com with ESMTPSA id v17-20020adfe291000000b0034174566ec4sm6339522wri.16.2024.03.30.05.19.05
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sat, 30 Mar 2024 05:19:07 -0700 (PDT)
Message-ID: <edd167fb-df0c-4434-8f9f-7c4016b87d83@linaro.org>
Date: Sat, 30 Mar 2024 13:19:05 +0100
Precedence: bulk
X-Mailing-List: kvm@vger.kernel.org
List-Id: <kvm.vger.kernel.org>
List-Subscribe: <mailto:kvm+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:kvm+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 00/19] amba: store owner from modules with
amba_driver_register()
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
Russell King <linux@armlinux.org.uk>, Mike Leach <mike.leach@linaro.org>,
James Clark <james.clark@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Linus Walleij <linus.walleij@linaro.org>, Andi Shyti
<andi.shyti@kernel.org>, Olivia Mackall <olivia@selenic.com>,
Herbert Xu <herbert@gondor.apana.org.au>, Vinod Koul <vkoul@kernel.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Michal Simek <michal.simek@amd.com>, Eric Auger <eric.auger@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>
Cc: linux-kernel@vger.kernel.org, coresight@lists.linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com, linux-i2c@vger.kernel.org,
linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
linux-input@vger.kernel.org, kvm@vger.kernel.org
References: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
<3f61d6d3-a0d6-4c49-b094-6ba62d09ab14@arm.com>
<f23f2e60-e5c0-4c3c-9722-dba63a6e7ef6@linaro.org>
<d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Language: en-US
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Autocrypt: addr=krzysztof.kozlowski@linaro.org; keydata=
xsFNBFVDQq4BEAC6KeLOfFsAvFMBsrCrJ2bCalhPv5+KQF2PS2+iwZI8BpRZoV+Bd5kWvN79
cFgcqTTuNHjAvxtUG8pQgGTHAObYs6xeYJtjUH0ZX6ndJ33FJYf5V3yXqqjcZ30FgHzJCFUu
JMp7PSyMPzpUXfU12yfcRYVEMQrmplNZssmYhiTeVicuOOypWugZKVLGNm0IweVCaZ/DJDIH
gNbpvVwjcKYrx85m9cBVEBUGaQP6AT7qlVCkrf50v8bofSIyVa2xmubbAwwFA1oxoOusjPIE
J3iadrwpFvsZjF5uHAKS+7wHLoW9hVzOnLbX6ajk5Hf8Pb1m+VH/E8bPBNNYKkfTtypTDUCj
NYcd27tjnXfG+SDs/EXNUAIRefCyvaRG7oRYF3Ec+2RgQDRnmmjCjoQNbFrJvJkFHlPeHaeS
BosGY+XWKydnmsfY7SSnjAzLUGAFhLd/XDVpb1Een2XucPpKvt9ORF+48gy12FA5GduRLhQU
vK4tU7ojoem/G23PcowM1CwPurC8sAVsQb9KmwTGh7rVz3ks3w/zfGBy3+WmLg++C2Wct6nM
Pd8/6CBVjEWqD06/RjI2AnjIq5fSEH/BIfXXfC68nMp9BZoy3So4ZsbOlBmtAPvMYX6U8VwD
TNeBxJu5Ex0Izf1NV9CzC3nNaFUYOY8KfN01X5SExAoVTr09ewARAQABzTRLcnp5c3p0b2Yg
S296bG93c2tpIDxrcnp5c3p0b2Yua296bG93c2tpQGxpbmFyby5vcmc+wsGUBBMBCgA+FiEE
m9B+DgxR+NWWd7dUG5NDfTtBYpsFAmI+BxMCGwMFCRRfreEFCwkIBwIGFQoJCAsCBBYCAwEC
HgECF4AACgkQG5NDfTtBYptgbhAAjAGunRoOTduBeC7V6GGOQMYIT5n3OuDSzG1oZyM4kyvO
XeodvvYv49/ng473E8ZFhXfrre+c1olbr1A8pnz9vKVQs9JGVa6wwr/6ddH7/yvcaCQnHRPK
mnXyP2BViBlyDWQ71UC3N12YCoHE2cVmfrn4JeyK/gHCvcW3hUW4i5rMd5M5WZAeiJj3rvYh
v8WMKDJOtZFXxwaYGbvFJNDdvdTHc2x2fGaWwmXMJn2xs1ZyFAeHQvrp49mS6PBQZzcx0XL5
cU9ZjhzOZDn6Apv45/C/lUJvPc3lo/pr5cmlOvPq1AsP6/xRXsEFX/SdvdxJ8w9KtGaxdJuf
rpzLQ8Ht+H0lY2On1duYhmro8WglOypHy+TusYrDEry2qDNlc/bApQKtd9uqyDZ+rx8bGxyY
qBP6bvsQx5YACI4p8R0J43tSqWwJTP/R5oPRQW2O1Ye1DEcdeyzZfifrQz58aoZrVQq+innR
aDwu8qDB5UgmMQ7cjDSeAQABdghq7pqrA4P8lkA7qTG+aw8Z21OoAyZdUNm8NWJoQy8m4nUP
gmeeQPRc0vjp5JkYPgTqwf08cluqO6vQuYL2YmwVBIbO7cE7LNGkPDA3RYMu+zPY9UUi/ln5
dcKuEStFZ5eqVyqVoZ9eu3RTCGIXAHe1NcfcMT9HT0DPp3+ieTxFx6RjY3kYTGLOwU0EVUNc
NAEQAM2StBhJERQvgPcbCzjokShn0cRA4q2SvCOvOXD+0KapXMRFE+/PZeDyfv4dEKuCqeh0
hihSHlaxTzg3TcqUu54w2xYskG8Fq5tg3gm4kh1Gvh1LijIXX99ABA8eHxOGmLPRIBkXHqJY
oHtCvPc6sYKNM9xbp6I4yF56xVLmHGJ61KaWKf5KKWYgA9kfHufbja7qR0c6H79LIsiYqf92
H1HNq1WlQpu/fh4/XAAaV1axHFt/dY/2kU05tLMj8GjeQDz1fHas7augL4argt4e+jum3Nwt
yupodQBxncKAUbzwKcDrPqUFmfRbJ7ARw8491xQHZDsP82JRj4cOJX32sBg8nO2N5OsFJOcd
5IE9v6qfllkZDAh1Rb1h6DFYq9dcdPAHl4zOj9EHq99/CpyccOh7SrtWDNFFknCmLpowhct9
5ZnlavBrDbOV0W47gO33WkXMFI4il4y1+Bv89979rVYn8aBohEgET41SpyQz7fMkcaZU+ok/
+HYjC/qfDxT7tjKXqBQEscVODaFicsUkjheOD4BfWEcVUqa+XdUEciwG/SgNyxBZepj41oVq
FPSVE+Ni2tNrW/e16b8mgXNngHSnbsr6pAIXZH3qFW+4TKPMGZ2rZ6zITrMip+12jgw4mGjy
5y06JZvA02rZT2k9aa7i9dUUFggaanI09jNGbRA/ABEBAAHCwXwEGAEKACYCGwwWIQSb0H4O
DFH41ZZ3t1Qbk0N9O0FimwUCYDzvagUJFF+UtgAKCRAbk0N9O0Fim9JzD/0auoGtUu4mgnna
oEEpQEOjgT7l9TVuO3Qa/SeH+E0m55y5Fjpp6ZToc481za3xAcxK/BtIX5Wn1mQ6+szfrJQ6
59y2io437BeuWIRjQniSxHz1kgtFECiV30yHRgOoQlzUea7FgsnuWdstgfWi6LxstswEzxLZ
Sj1EqpXYZE4uLjh6dW292sO+j4LEqPYr53hyV4I2LPmptPE9Rb9yCTAbSUlzgjiyyjuXhcwM
qf3lzsm02y7Ooq+ERVKiJzlvLd9tSe4jRx6Z6LMXhB21fa5DGs/tHAcUF35hSJrvMJzPT/+u
/oVmYDFZkbLlqs2XpWaVCo2jv8+iHxZZ9FL7F6AHFzqEFdqGnJQqmEApiRqH6b4jRBOgJ+cY
qc+rJggwMQcJL9F+oDm3wX47nr6jIsEB5ZftdybIzpMZ5V9v45lUwmdnMrSzZVgC4jRGXzsU
EViBQt2CopXtHtYfPAO5nAkIvKSNp3jmGxZw4aTc5xoAZBLo0OV+Ezo71pg3AYvq0a3/oGRG
KQ06ztUMRrj8eVtpImjsWCd0bDWRaaR4vqhCHvAG9iWXZu4qh3ipie2Y0oSJygcZT7H3UZxq
fyYKiqEmRuqsvv6dcbblD8ZLkz1EVZL6djImH5zc5x8qpVxlA0A0i23v5QvN00m6G9NFF0Le
D2GYIS41Kv4Isx2dEFh+/Q==
In-Reply-To: <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Return-Path: kvm+bounces-13146-martin.weber=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 12:19:27.6209
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: cb55eba9-97a5-4e15-7fd3-08dc50b3a4ee
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-dresden-01.secunet.de:TOTAL-HUB=0.422|SMR=0.342(SMRDE=0.035|SMRC=0.307(SMRCL=0.101|X-SMRCR=0.306))|CAT=0.078(CATOS=0.012
(CATSM=0.012(CATSM-Malware
Agent=0.011))|CATRESL=0.039(CATRESLP2R=0.036)|CATORES=0.024
(CATRS=0.024(CATRS-Index Routing Agent=0.023)));2024-03-30T12:19:28.067Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-dresden-01.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 13859
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-02.secunet.de:TOTAL-FE=0.024|SMR=0.007(SMRPI=0.004(SMRPI-FrontendProxyAgent=0.004))|SMS=0.018
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Organization-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAVsDAAAPAAADH4sIAAAAAAAEAIVTzY8TNxT3bjL5GIhaVT
30wOGJCyBFYRugSCuxaOmlaIVAcKg4OjOejLvOOLI9ibJ/Oqf+/DyT
hW1LEysZP7/3+3h+82XyvqHly6dnz54uz5bP6dez8+VyTp/am/Za0x
V9sK2xXtHe2aDOZ/kFfZt/9uL8xcs5Xbmbg78JtqIre2Ps3qP4WPKP
GnA8/x4HKv7Qt5gcSeEI9NsRaAmgZ/9Hjqp3yq11s+52r9Kn210aQ1
XrQq0cbWUoauWpVFvVlGQbQpgq7XwguVnJlDCPUacq6xRtjZJQLovr
Dk6iLtTak6/hqqS1pZ2WgFIUnFKLr7xcov5gW5Irg0NLW2d3ugQY+c
CxlZNNUdNehzpSgqcXaJsi1W5bYyIad/ktlbZdBfzvNVytFG2ScVa0
QBz/zXWyUlhQrS3AQu1su67pY+u9MmbR411E0g3pJop72Dt4SNE8va
Y/FdVyp6ioZbMGTGE3kardcgX6VqBBXq/r0IGheE77WkdL3JvCNpXR
RTg6PGIxxePaOqdX5vDktmvs8zOMb5Rs7gDcEsaDnXJeW9a+NTLgtj
ZUOo0wpFvcKKDiOH9WfpEeL6iId6kDxeuzZqfiLZzTXy2uv3R2Swu7
b5Tr0um9g51oM3qJnVbs4Xeo+JRUdG4ey9hkdSAJV05JYw7U2CiAZF
WpIqiSVgcuxgyAc9ONkHIa5XgK7sDXaEmWJUz6J6gMmFjURJhVFN7T
mTiDuIPLd28u5zx938rq5nCWv32EKemnjifxzuSBr1KYuDg6exnfi0
rJTm03LY/8LOepBCzegqjSH3xQG2Z4o9A6p9bSlX4+y796o+NXiFMx
OD0RORYexGB4kmUnIhNY45EYn4jTsZhkIv9O2lTkWJm49y85d3HuIz
4VP/9XZg81G4sHAzFECRbKkYNtJkZDkaU0BAciRxCRYwJvf+wfMgRR
DuoRa+DaESJ44IQZjhDB7zF5yNtElBZr+CklnHbIOI2M6TSxJwFT8Q
NOM14TMU1ECXYifkmqOD6ChZw7hu2IOzMQ93sWtOgeswNnBlJEEiZT
5GMxTezYch/GE470XF1D0i+SuXCc1CaKIUMltCHrxBG2x14xY7w1BB
M4JCVTI9Y2xk39DXCU4RO5BgAAAQKrDDw/eG1sIHZlcnNpb249IjEu
MCIgZW5jb2Rpbmc9InV0Zi0xNiI/Pg0KPFRhc2tTZXQ+DQogIDxWZX
JzaW9uPjE1LjAuMC4wPC9WZXJzaW9uPg0KICA8VGFza3M+DQogICAg
PFRhc2sgU3RhcnRJbmRleD0iNjg3Ij4NCiAgICAgIDxUYXNrU3RyaW
5nPiZndDsmZ3Q7IFlvdSBtZWFuIGNvbmZsaWN0IHdpdGggIGNvcmVz
aWdodCBjb252ZXJzaW9uIHRvIHBsYXRmb3JtIGRyaXZlcj88L1Rhc2
tTdHJpbmc+DQogICAgICA8QXNzaWduZWVzPg0KICAgICAgICA8RW1h
aWxVc2VyIElkPSJzdXp1a2kucG91bG9zZUBhcm0uY29tIj5TdXp1a2
kgSyBQb3Vsb3NlPC9FbWFpbFVzZXI+DQogICAgICAgIDxFbWFpbFVz
ZXIgSWQ9ImxpbnV4QGFybWxpbnV4Lm9yZy51ayI+UnVzc2VsbCBLaW
5nPC9FbWFpbFVzZXI+DQogICAgICAgIDxFbWFpbFVzZXIgSWQ9Im1p
a2UubGVhY2hAbGluYXJvLm9yZyI+TWlrZSBMZWFjaDwvRW1haWxVc2
VyPg0KICAgICAgICA8RW1haWxVc2VyIElkPSJqYW1lcy5jbGFya0Bh
cm0uY29tIj5KYW1lcyBDbGFyazwvRW1haWxVc2VyPg0KICAgICAgIC
A8RW1haWxVc2VyIElkPSJhbGV4YW5kZXIuc2hpc2hraW5AbGludXgu
aW50ZWwuY29tIj5BbGV4YW5kZXIgU2hpc2hraW48L0VtYWlsVXNlcj
4NCiAgICAgICAgPEVtYWlsVXNlciBJZD0ibWNvcXVlbGluLnN0bTMy
QGdtYWlsLmNvbSI+TWF4aW1lIENvcXVlbGluPC9FbWFpbFVzZXI+DQ
ogICAgICAgIDxFbWFpbFVzZXIgSWQ9ImFsZXhhbmRyZS50b3JndWVA
Zm9zcy5zdC5jb20iPkFsZXhhbmRyZSBUb3JndWU8L0VtYWlsVXNlcj
4NCiAgICAgICAgPEVtYWlsVXNlciBJZD0ibGludXMud2FsbGVpakBs
aW5hcm8ub3JnIj5MaW51cyBXYWxsZWlqPC9FbWFpbFVzZXI+DQogIC
AgICAgIDxFbWFpbFVzZXIgSWQ9ImFuZGkuc2h5dGlAa2VybmVsLm9y
ZyI+QW5kaSBTaHl0aTwvRW1haWxVc2VyPg0KICAgICAgICA8RW1haW
xVc2VyIElkPSJvbGl2aWFAc2VsZW5pYy5jb20iPk9saXZpYSBNYWNr
YWxsPC9FbWFpbFVzZXI+DQogICAgICAgIDxFbWFpbFVzZXIgSWQ9Im
hlcmJlcnRAZ29uZG9yLmFwYW5hLm9yZy5hdSI+SGVyYmVydCBYdTwv
RW1haWxVc2VyPg0KICAgICAgICA8RW1haWxVc2VyIElkPSJ2a291bE
BrZXJuZWwub3JnIj5WaW5vZCBLb3VsPC9FbWFpbFVzZXI+DQogICAg
ICAgIDxFbWFpbFVzZXIgSWQ9ImRtaXRyeS50b3Jva2hvdkBnbWFpbC
5jb20iPkRtaXRyeSBUb3Jva2hvdjwvRW1haWxVc2VyPg0KICAgICAg
ICA8RW1haWxVc2VyIElkPSJtaXF1ZWwucmF5bmFsQGJvb3RsaW4uY2
9tIj5NaXF1ZWwgUmF5bmFsPC9FbWFpbFVzZXI+DQogICAgICAgIDxF
bWFpbFVzZXIgSWQ9Im1pY2hhbC5zaW1la0BhbWQuY29tIj5NaWNoYW
wgU2ltZWs8L0VtYWlsVXNlcj4NCiAgICAgICAgPEVtYWlsVXNlciBJ
ZD0iZXJpYy5hdWdlckByZWRoYXQuY29tIj5FcmljIEF1Z2VyPC9FbW
FpbFVzZXI+DQogICAgICAgIDxFbWFpbFVzZXIgSWQ9ImFsZXgud2ls
bGlhbXNvbkByZWRoYXQuY29tIj5BbGV4IFdpbGxpYW1zb248L0VtYW
lsVXNlcj4NCiAgICAgIDwvQXNzaWduZWVzPg0KICAgIDwvVGFzaz4N
CiAgPC9UYXNrcz4NCjwvVGFza1NldD4BDs8BUmV0cmlldmVyT3Blcm
F0b3IsMTAsMDtSZXRyaWV2ZXJPcGVyYXRvciwxMSwxO1Bvc3REb2NQ
YXJzZXJPcGVyYXRvciwxMCwwO1Bvc3REb2NQYXJzZXJPcGVyYXRvci
wxMSwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRvciwx
MCwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRvciwxMS
wwO1RyYW5zcG9ydFdyaXRlclByb2R1Y2VyLDIwLDE0
X-MS-Exchange-Forest-IndexAgent: 1 2664
X-MS-Exchange-Forest-EmailMessageHash: CDDC1A99
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent
On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with coresight conversion to platform driver? Worst
>
> Yes.
>
>> case it is solveable: just drop .owner.
>
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.
I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.
Best regards,
Krzysztof
^ 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