* Re: Suspected bug in hid-microsoft.c
From: Taco Jerkface @ 2024-01-31 19:27 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Siarhei Vishniakou, linux-input, jikos
In-Reply-To: <CAO-hwJ+OFxRqoL4RYaKMR_PfmpBJuyWUGcDXRrp7jWuYfT=CyQ@mail.gmail.com>
Thanks for the response!
I put some diagnostic info below, but please let me know if I can do
anything else to help.
Thank you.
hid-recorder does not see the controller when connected with USB.
sudo hid-recorder
Available devices:
/dev/hidraw0: DLL07D1:01 044E:120B
Select the device event number [0-0]:
When connected with Bluetooth, hid-recorder sees the device as "Xbox
Wireless Controler" and the dump is below:
sudo hid-recorder
Available devices:
/dev/hidraw0: DLL07D1:01 044E:120B
/dev/hidraw1: Xbox Wireless Controller
Select the device event number [0-1]: 1
# Xbox Wireless Controller
# 0x05, 0x01, // Usage Page (Generic Desktop) 0
# 0x09, 0x05, // Usage (Game Pad) 2
# 0xa1, 0x01, // Collection (Application) 4
# 0x85, 0x01, // Report ID (1) 6
# 0x09, 0x01, // Usage (Pointer) 8
# 0xa1, 0x00, // Collection (Physical) 10
# 0x09, 0x30, // Usage (X) 12
# 0x09, 0x31, // Usage (Y) 14
# 0x15, 0x00, // Logical Minimum (0) 16
# 0x27, 0xff, 0xff, 0x00, 0x00, // Logical Maximum (65535) 18
# 0x95, 0x02, // Report Count (2) 23
# 0x75, 0x10, // Report Size (16) 25
# 0x81, 0x02, // Input (Data,Var,Abs) 27
# 0xc0, // End Collection 29
# 0x09, 0x01, // Usage (Pointer) 30
# 0xa1, 0x00, // Collection (Physical) 32
# 0x09, 0x32, // Usage (Z) 34
# 0x09, 0x35, // Usage (Rz) 36
# 0x15, 0x00, // Logical Minimum (0) 38
# 0x27, 0xff, 0xff, 0x00, 0x00, // Logical Maximum (65535) 40
# 0x95, 0x02, // Report Count (2) 45
# 0x75, 0x10, // Report Size (16) 47
# 0x81, 0x02, // Input (Data,Var,Abs) 49
# 0xc0, // End Collection 51
# 0x05, 0x02, // Usage Page (Simulation Controls) 52
# 0x09, 0xc5, // Usage (Brake) 54
# 0x15, 0x00, // Logical Minimum (0) 56
# 0x26, 0xff, 0x03, // Logical Maximum (1023) 58
# 0x95, 0x01, // Report Count (1) 61
# 0x75, 0x0a, // Report Size (10) 63
# 0x81, 0x02, // Input (Data,Var,Abs) 65
# 0x15, 0x00, // Logical Minimum (0) 67
# 0x25, 0x00, // Logical Maximum (0) 69
# 0x75, 0x06, // Report Size (6) 71
# 0x95, 0x01, // Report Count (1) 73
# 0x81, 0x03, // Input (Cnst,Var,Abs) 75
# 0x05, 0x02, // Usage Page (Simulation Controls) 77
# 0x09, 0xc4, // Usage (Accelerator) 79
# 0x15, 0x00, // Logical Minimum (0) 81
# 0x26, 0xff, 0x03, // Logical Maximum (1023) 83
# 0x95, 0x01, // Report Count (1) 86
# 0x75, 0x0a, // Report Size (10) 88
# 0x81, 0x02, // Input (Data,Var,Abs) 90
# 0x15, 0x00, // Logical Minimum (0) 92
# 0x25, 0x00, // Logical Maximum (0) 94
# 0x75, 0x06, // Report Size (6) 96
# 0x95, 0x01, // Report Count (1) 98
# 0x81, 0x03, // Input (Cnst,Var,Abs) 100
# 0x05, 0x01, // Usage Page (Generic Desktop) 102
# 0x09, 0x39, // Usage (Hat switch) 104
# 0x15, 0x01, // Logical Minimum (1) 106
# 0x25, 0x08, // Logical Maximum (8) 108
# 0x35, 0x00, // Physical Minimum (0) 110
# 0x46, 0x3b, 0x01, // Physical Maximum (315) 112
# 0x66, 0x14, 0x00, // Unit (EnglishRotation: deg) 115
# 0x75, 0x04, // Report Size (4) 118
# 0x95, 0x01, // Report Count (1) 120
# 0x81, 0x42, // Input (Data,Var,Abs,Null) 122
# 0x75, 0x04, // Report Size (4) 124
# 0x95, 0x01, // Report Count (1) 126
# 0x15, 0x00, // Logical Minimum (0) 128
# 0x25, 0x00, // Logical Maximum (0) 130
# 0x35, 0x00, // Physical Minimum (0) 132
# 0x45, 0x00, // Physical Maximum (0) 134
# 0x65, 0x00, // Unit (None) 136
# 0x81, 0x03, // Input (Cnst,Var,Abs) 138
# 0x05, 0x09, // Usage Page (Button) 140
# 0x19, 0x01, // Usage Minimum (1) 142
# 0x29, 0x0f, // Usage Maximum (15) 144
# 0x15, 0x00, // Logical Minimum (0) 146
# 0x25, 0x01, // Logical Maximum (1) 148
# 0x75, 0x01, // Report Size (1) 150
# 0x95, 0x0f, // Report Count (15) 152
# 0x81, 0x02, // Input (Data,Var,Abs) 154
# 0x15, 0x00, // Logical Minimum (0) 156
# 0x25, 0x00, // Logical Maximum (0) 158
# 0x75, 0x01, // Report Size (1) 160
# 0x95, 0x01, // Report Count (1) 162
# 0x81, 0x03, // Input (Cnst,Var,Abs) 164
# 0x05, 0x0c, // Usage Page (Consumer Devices) 166
# 0x0a, 0xb2, 0x00, // Usage (Record) 168
# 0x15, 0x00, // Logical Minimum (0) 171
# 0x25, 0x01, // Logical Maximum (1) 173
# 0x95, 0x01, // Report Count (1) 175
# 0x75, 0x01, // Report Size (1) 177
# 0x81, 0x02, // Input (Data,Var,Abs) 179
# 0x15, 0x00, // Logical Minimum (0) 181
# 0x25, 0x00, // Logical Maximum (0) 183
# 0x75, 0x07, // Report Size (7) 185
# 0x95, 0x01, // Report Count (1) 187
# 0x81, 0x03, // Input (Cnst,Var,Abs) 189
# 0x05, 0x0c, // Usage Page (Consumer Devices) 191
# 0x09, 0x01, // Usage (Consumer Control) 193
# 0xa1, 0x01, // Collection (Application) 195
# 0x0a, 0x85, 0x00, // Usage (Order Movie) 197
# 0x15, 0x00, // Logical Minimum (0) 200
# 0x26, 0xff, 0x00, // Logical Maximum (255) 202
# 0x95, 0x01, // Report Count (1) 205
# 0x75, 0x08, // Report Size (8) 207
# 0x81, 0x02, // Input (Data,Var,Abs) 209
# 0x0a, 0x99, 0x00, // Usage (Media Select Security) 211
# 0x15, 0x00, // Logical Minimum (0) 214
# 0x26, 0xff, 0x00, // Logical Maximum (255) 216
# 0x95, 0x01, // Report Count (1) 219
# 0x75, 0x04, // Report Size (4) 221
# 0x81, 0x02, // Input (Data,Var,Abs) 223
# 0x15, 0x00, // Logical Minimum (0) 225
# 0x25, 0x00, // Logical Maximum (0) 227
# 0x95, 0x01, // Report Count (1) 229
# 0x75, 0x04, // Report Size (4) 231
# 0x81, 0x03, // Input (Cnst,Var,Abs) 233
# 0x0a, 0x81, 0x00, // Usage (Assign Selection) 235
# 0x15, 0x00, // Logical Minimum (0) 238
# 0x26, 0xff, 0x00, // Logical Maximum (255) 240
# 0x95, 0x01, // Report Count (1) 243
# 0x75, 0x04, // Report Size (4) 245
# 0x81, 0x02, // Input (Data,Var,Abs) 247
# 0x15, 0x00, // Logical Minimum (0) 249
# 0x25, 0x00, // Logical Maximum (0) 251
# 0x95, 0x01, // Report Count (1) 253
# 0x75, 0x04, // Report Size (4) 255
# 0x81, 0x03, // Input (Cnst,Var,Abs) 257
# 0xc0, // End Collection 259
# 0x05, 0x0f, // Usage Page (Vendor Usage Page 0x0f) 260
# 0x09, 0x21, // Usage (Vendor Usage 0x21) 262
# 0x85, 0x03, // Report ID (3) 264
# 0xa1, 0x02, // Collection (Logical) 266
# 0x09, 0x97, // Usage (Vendor Usage 0x97) 268
# 0x15, 0x00, // Logical Minimum (0) 270
# 0x25, 0x01, // Logical Maximum (1) 272
# 0x75, 0x04, // Report Size (4) 274
# 0x95, 0x01, // Report Count (1) 276
# 0x91, 0x02, // Output (Data,Var,Abs) 278
# 0x15, 0x00, // Logical Minimum (0) 280
# 0x25, 0x00, // Logical Maximum (0) 282
# 0x75, 0x04, // Report Size (4) 284
# 0x95, 0x01, // Report Count (1) 286
# 0x91, 0x03, // Output (Cnst,Var,Abs) 288
# 0x09, 0x70, // Usage (Vendor Usage 0x70) 290
# 0x15, 0x00, // Logical Minimum (0) 292
# 0x25, 0x64, // Logical Maximum (100) 294
# 0x75, 0x08, // Report Size (8) 296
# 0x95, 0x04, // Report Count (4) 298
# 0x91, 0x02, // Output (Data,Var,Abs) 300
# 0x09, 0x50, // Usage (Vendor Usage 0x50) 302
# 0x66, 0x01, 0x10, // Unit (SILinear: s) 304
# 0x55, 0x0e, // Unit Exponent (-2) 307
# 0x15, 0x00, // Logical Minimum (0) 309
# 0x26, 0xff, 0x00, // Logical Maximum (255) 311
# 0x75, 0x08, // Report Size (8) 314
# 0x95, 0x01, // Report Count (1) 316
# 0x91, 0x02, // Output (Data,Var,Abs) 318
# 0x09, 0xa7, // Usage (Vendor Usage 0xa7) 320
# 0x15, 0x00, // Logical Minimum (0) 322
# 0x26, 0xff, 0x00, // Logical Maximum (255) 324
# 0x75, 0x08, // Report Size (8) 327
# 0x95, 0x01, // Report Count (1) 329
# 0x91, 0x02, // Output (Data,Var,Abs) 331
# 0x65, 0x00, // Unit (None) 333
# 0x55, 0x00, // Unit Exponent (0) 335
# 0x09, 0x7c, // Usage (Vendor Usage 0x7c) 337
# 0x15, 0x00, // Logical Minimum (0) 339
# 0x26, 0xff, 0x00, // Logical Maximum (255) 341
# 0x75, 0x08, // Report Size (8) 344
# 0x95, 0x01, // Report Count (1) 346
# 0x91, 0x02, // Output (Data,Var,Abs) 348
# 0xc0, // End Collection 350
# 0x05, 0x0c, // Usage Page (Consumer Devices) 351
# 0x09, 0x01, // Usage (Consumer Control) 353
# 0x85, 0x0c, // Report ID (12) 355
# 0xa1, 0x01, // Collection (Application) 357
# 0x0a, 0x9e, 0x00, // Usage (Media Select SAP) 359
# 0x15, 0x00, // Logical Minimum (0) 362
# 0x26, 0xff, 0x00, // Logical Maximum (255) 364
# 0x95, 0x01, // Report Count (1) 367
# 0x75, 0x08, // Report Size (8) 369
# 0x81, 0x02, // Input (Data,Var,Abs) 371
# 0x0a, 0xa1, 0x00, // Usage (Once) 373
# 0x15, 0x00, // Logical Minimum (0) 376
# 0x26, 0xff, 0x00, // Logical Maximum (255) 378
# 0x95, 0x01, // Report Count (1) 381
# 0x75, 0x08, // Report Size (8) 383
# 0x81, 0x02, // Input (Data,Var,Abs) 385
# 0x0a, 0xa2, 0x00, // Usage (Daily) 387
# 0x15, 0x00, // Logical Minimum (0) 390
# 0x26, 0xff, 0x00, // Logical Maximum (255) 392
# 0x95, 0x01, // Report Count (1) 395
# 0x75, 0x08, // Report Size (8) 397
# 0x81, 0x02, // Input (Data,Var,Abs) 399
# 0x0a, 0xa3, 0x00, // Usage (Weekly) 401
# 0x15, 0x00, // Logical Minimum (0) 404
# 0x26, 0xff, 0x00, // Logical Maximum (255) 406
# 0x95, 0x01, // Report Count (1) 409
# 0x75, 0x08, // Report Size (8) 411
# 0x81, 0x02, // Input (Data,Var,Abs) 413
# 0xc0, // End Collection 415
# 0xc0, // End Collection 416
# 0x05, 0x01, // Usage Page (Generic Desktop) 417
# 0x09, 0x06, // Usage (Keyboard) 419
# 0xa1, 0x01, // Collection (Application) 421
# 0x85, 0x05, // Report ID (5) 423
# 0x05, 0x07, // Usage Page (Keyboard) 425
# 0x19, 0xe0, // Usage Minimum (224) 427
# 0x29, 0xe7, // Usage Maximum (231) 429
# 0x15, 0x00, // Logical Minimum (0) 431
# 0x25, 0x01, // Logical Maximum (1) 433
# 0x75, 0x01, // Report Size (1) 435
# 0x95, 0x08, // Report Count (8) 437
# 0x81, 0x02, // Input (Data,Var,Abs) 439
# 0x95, 0x01, // Report Count (1) 441
# 0x75, 0x08, // Report Size (8) 443
# 0x81, 0x03, // Input (Cnst,Var,Abs) 445
# 0x95, 0x06, // Report Count (6) 447
# 0x75, 0x08, // Report Size (8) 449
# 0x15, 0x00, // Logical Minimum (0) 451
# 0x25, 0x65, // Logical Maximum (101) 453
# 0x05, 0x07, // Usage Page (Keyboard) 455
# 0x19, 0x00, // Usage Minimum (0) 457
# 0x29, 0x65, // Usage Maximum (101) 459
# 0x81, 0x00, // Input (Data,Arr,Abs) 461
# 0xc0, // End Collection 463
#
R: 464 05 01 09 05 a1 01 85 01 09 01 a1 00 09 30 09 31 15 00 27 ff ff
00 00 95 02 75 10 81 02 c0 09 01 a1 00 09 32 09 35 15 00 27 ff ff 00
00 95 02 75 10 81 02 c0 05 02 09 c5 15 00 26 ff 03 95 01 75 0a
81 02 15 00 25 00 75 06 95 01 81 03 05 02 09 c4 15 00 26 ff 03 95 01
75 0a 81 02 15 00 25 00 75 06 95 01 81 03 05 01 09 39 15 01 25 08 35
00 46 3b 01 66 14 00 75 04 95 01 81 42 75 04 95 01 15 00 25 00
35 00 45 00 65 00 81 03 05 09 19 01 29 0f 15 00 25 01 75 01 95 0f 81
02 15 00 25 00 75 01 95 01 81 03 05 0c 0a b2 00 15 00 25 01 95 01 75
01 81 02 15 00 25 00 75 07 95 01 81 03 05 0c 09 01 a1 01 0a 85
00 15 00 26 ff 00 95 01 75 08 81 02 0a 99 00 15 00 26 ff 00 95 01 75
04 81 02 15 00 25 00 95 01 75 04 81 03 0a 81 00 15 00 26 ff 00 95 01
75 04 81 02 15 00 25 00 95 01 75 04 81 03 c0 05 0f 09 21 85 03
a1 02 09 97 15 00 25 01 75 04 95 01 91 02 15 00 25 00 75 04 95 01 91
03 09 70 15 00 25 64 75 08 95 04 91 02 09 50 66 01 10 55 0e 15 00 26
ff 00 75 08 95 01 91 02 09 a7 15 00 26 ff 00 75 08 95 01 91 02
65 00 55 00 09 7c 15 00 26 ff 00 75 08 95 01 91 02 c0 05 0c 09 01 85
0c a1 01 0a 9e 00 15 00 26 ff 00 95 01 75 08 81 02 0a a1 00 15 00 26
ff 00 95 01 75 08 81 02 0a a2 00 15 00 26 ff 00 95 01 75 08 81
02 0a a3 00 15 00 26 ff 00 95 01 75 08 81 02 c0 c0 05 01 09 06 a1 01
85 05 05 07 19 e0 29 e7 15 00 25 01 75 01 95 08 81 02 95 01 75 08 81
03 95 06 75 08 15 00 25 65 05 07 19 00 29 65 81 00 c0
N: Xbox Wireless Controller
I: 5 045e 0b22
On Wed, Jan 31, 2024 at 2:57 AM Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> Hi,
>
> [Adding Siarhei who added support for those controllers in the kernel]
>
> On Wed, Jan 31, 2024 at 7:27 AM Taco Jerkface <tacodog311@gmail.com> wrote:
> >
> > Resending without HTML:
> >
> > Hi,
> >
> > I hope this is the correct contact for this report, I found you as the
> > maintainer in the hid-microsoft.c.
> >
> > I believe there is a bug in the microsoft bluetooth driver for the
> > Xbox Elite Series 2 controller. I have been experiencing issues with
> > it that I initially thought were SDL related. However the SDL team
> > seems to think this is driver related. My SDL bug report information
> > is here:
> >
> > https://github.com/libsdl-org/SDL/issues/8907
>
> Hard to say anything with that bug report because we don't know what
> those tools are supposed to do, and how they access the device (hidraw
> or evdev).
>
> Note that the bluetooth version is using uhid because it's a BLE controller.
> Basically when there is a BLE controller, bluez handles the transport
> layer from userspace, and injects the events through uhid so that it's
> handled as a normal kernel device.
>
> So there is no "uhid userspace driver", bluez just blindly forwards
> the events/reports/commands as it is told.
>
> >
> > Basically, SDL reads the controller correctly when connected by USB,
> > and if I run "controllermap" with root permission, but with user
> > permissions it misreads
>
> Using root or not shouldn't change the way your program sees the
> device: if you are capable of opening it, then you should get the same
> output.
>
> However, the immediate explanation that would come to my mind is that
> you are not using the "same" controller in both cases:
> - maybe that when you use it with root you are talking to the device
> through hidraw
> - maybe when you are not root you are talking to the device through evdev
>
> Again, not knowing the tools doesn't help me here :(
>
> > the number of buttons as 122, the first paddle
> > button on the back seems to act like the "screenshot" button from the
> > 1914 controller, and the other paddle buttons are not read. All
> > buttons read fine with evites, but the paddle buttons "KEY_UNKNOWN"
> >
> > type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
> >
> > Please let me know if there is a better contact for this, or if there
> > is anything I can do to help identify the problem.
> >
>
> Ideally I'd like Siarhei to answer here. But in the meantime, we could
> fetch some logs from the device itself which would allow me to better
> understand the issue:
> please use hid-recorder from hid-tools[1] to get the logs, and attach
> the whole output, with a recording of the events that are problematic:
> $> pip3 install hid-tools
> $> sudo hid-recorder
>
> Please dump 2 hid-recorder outputs, one with USB, and one with
> Bluetooth, with the same event sequence if possible so we can compare
> between the 2.
>
> Cheers,
> Benjamin
>
> [1] https://gitlab.freedesktop.org/libevdev/hid-tools
>
^ permalink raw reply
* Re: [PATCH 1/3] Input: matrix_keypad - avoid repeatedly converting GPIO to IRQ
From: Dmitry Torokhov @ 2024-01-31 18:48 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: linux-input, Dan Carpenter, linux-kernel
In-Reply-To: <CACMJSetrYPaXOr5abHtP1mjsyH3nB3=6CwxWfviN1BP0rhgEhg@mail.gmail.com>
On Mon, Jan 22, 2024 at 09:19:56AM +0100, Bartosz Golaszewski wrote:
> On Sun, 21 Jan 2024 at 06:32, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >
> > gpio_to_irq() is getting more expensive and may require sleeping.
>
> This is no longer true, the relevant commit was reverted and I have
> now a working series where I'm using SRCU for lockless list traversal
> so if anything it will actually become cheaper.
>
> > Convert row GPIOs to interrupt numbers once in probe() and use
> > this information when the driver needs to enable or disable given
> > interrupt line.
>
> That being said, I'm not against this change, though this may not be
> very useful after all.
OK, then I'll tone down the patch description and apply.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
From: Kamel Bouhara @ 2024-01-31 17:14 UTC (permalink / raw)
To: Jeff LaBundy
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, catalin.popescu, mark.satterthwaite, bartp,
hannah.rossiter, Thomas Petazzoni, Gregory Clement,
bsp-development.geo
In-Reply-To: <ZY5An58Rffrcpfpn@nixie71>
On Thu, Dec 28, 2023 at 09:44:31PM -0600, Jeff LaBundy wrote:
> Hi Kamel,
>
Hello Jeff,
[...]
> > +
> > +/*
> > + * Support function to axiom_process_u41_report.
> > + * Generates input-subsystem events for every target.
> > + * After calling this function the caller shall issue
> > + * a Sync to the input sub-system.
> > + */
> > +static bool axiom_process_u41_report_target(struct axiom_data *ts,
> > + struct axiom_target_report *target)
> > +{
> > + struct input_dev *input_dev = ts->input_dev;
> > + struct axiom_u41_target *target_prev_state;
> > + enum axiom_target_state current_state;
> > + bool update = false;
> > + int slot;
> > +
> > + /* Verify the target index */
> > + if (target->index >= AXIOM_U41_MAX_TARGETS) {
> > + dev_dbg(ts->dev, "Invalid target index! %u\n", target->index);
>
> Should this be dev_err()?
>
> > + return false;
> > + }
> > +
> > + target_prev_state = &ts->targets[target->index];
> > +
> > + current_state = AXIOM_TARGET_STATE_NOT_PRESENT;
> > +
> > + if (target->present) {
> > + if (target->z >= 0)
> > + current_state = AXIOM_TARGET_STATE_TOUCHING;
> > + else if (target->z > AXIOM_PROX_LEVEL && target->z < 0)
> > + current_state = AXIOM_TARGET_STATE_HOVER;
> > + else if (target->z == AXIOM_PROX_LEVEL)
> > + current_state = AXIOM_TARGET_STATE_PROX;
> > + }
> > +
> > + if (target_prev_state->state == current_state &&
> > + target_prev_state->x == target->x &&
> > + target_prev_state->y == target->y &&
> > + target_prev_state->z == target->z) {
> > + return false;
> > + }
>
> No need for curly braces here; please refer to the kernel style guidelines.
>
> > +
> > + slot = target->index;
> > +
> > + dev_dbg(ts->dev, "U41 Target T%u, slot:%u present:%u, x:%u, y:%u, z:%d\n",
> > + target->index, slot, target->present,
> > + target->x, target->y, target->z);
> > +
> > + switch (current_state) {
> > + case AXIOM_TARGET_STATE_NOT_PRESENT:
> > + case AXIOM_TARGET_STATE_PROX:
> > + if (!target_prev_state->insert)
> > + break;
> > + update = true;
> > + target_prev_state->insert = false;
> > + input_mt_slot(input_dev, slot);
> > +
> > + if (!slot)
> > + input_report_key(input_dev, BTN_TOUCH, 0);
> > +
> > + input_mt_report_slot_inactive(input_dev);
> > + /*
> > + * make sure the previous coordinates are
> > + * all off screen when the finger comes back
> > + */
> > + target->x = 65535;
> > + target->y = 65535;
> > + target->z = AXIOM_PROX_LEVEL;
> > + break;
> > + case AXIOM_TARGET_STATE_HOVER:
> > + case AXIOM_TARGET_STATE_TOUCHING:
> > + target_prev_state->insert = true;
> > + update = true;
> > + input_mt_slot(input_dev, slot);
> > + input_report_abs(input_dev, ABS_MT_TRACKING_ID, slot);
> > + input_report_abs(input_dev, ABS_MT_POSITION_X, target->x);
> > + input_report_abs(input_dev, ABS_X, target->x);
>
> You do not need to explicitly report ABS_X and ABS_Y values, as calling
> input_mt_sync_frame() effectively takes care of this by way of pointer
> emulation.
>
After double checking/testing this, it doesn't seems to
report ABS_X/Y values anymore, are you sure about this ? Maybe I missed
some extra flag in input_mt_init_slots() for that ?
Regards,
--
Kamel Bouhara, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v1 7/7] HID: playstation: DS4: Add VID/PID for SZ-MYPOWER controllers
From: Roderick Colenbrander @ 2024-01-31 16:34 UTC (permalink / raw)
To: Max Staudt
Cc: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <d5d301c6-172d-4204-88cc-2dc9b351e693@enpas.org>
On Wed, Jan 31, 2024 at 6:48 AM Max Staudt <max@enpas.org> wrote:
>
> On 1/31/24 06:07, Roderick Colenbrander wrote:
> > Hmpf, euhm euhm I'm not entirely sure what makes sense. From the
> > sounds of it are somewhat broken devices (buggy firmwares on them) or
> > perhaps one of your controllers (the one with not working touch) is
> > perhaps broken.
> >
> > Some of the patches like handling report id 0x1 (minimal) won't hurt,
> > the LED fixes won't either. It makes it easier to add more devices. I
> > wonder if we have fully have enough data.
> >
> > Need to think a bit...
>
> Yeah, maybe for now, let's focus on the patches that you don't see much trouble with. Better to enable some devices, than none.
>
> I suggest dropping this here patch (enabling 7545:0104) for now, and if there's ever a change of mind, we can just pick it from the LKML archives :)
>
>
> You can also drop the other patch that you're uneasy about, since I believe these 7545:0104 devices are the only ones I've observed to not implement the what-is-your-MAC-address command.
>
>
>
> Max
>
I agree it sounds like a good idea for now to drop just those 2 paches
and just see what other devices are out there (SDL2 has a good ds4
implementation too and they dealt with a lot of devices). May need to
get some of the 8bitdo and many others to see some patterns.
Thanks,
Roderick
^ permalink raw reply
* Re: Future handling of complex RGB devices on Linux
From: Roderick Colenbrander @ 2024-01-31 15:52 UTC (permalink / raw)
To: Werner Sembach
Cc: Hans de Goede, Pavel Machek, Lee Jones, jikos, linux-kernel,
Jelle van der Waa, Miguel Ojeda, dri-devel@lists.freedesktop.org,
linux-input, ojeda, linux-leds
In-Reply-To: <e21a7d87-3059-4a51-af04-1062dac977d2@tuxedocomputers.com>
On Wed, Jan 31, 2024 at 3:42 AM Werner Sembach <wse@tuxedocomputers.com> wrote:
>
> Hi,
>
> so I combined Hans last draft, with the discussion since then and the comments
> from the OpenRGB maintainers from here
> https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916 and my own experience
> and came up witrh this rough updated draft for the new uapi:
>
> Future handling of complex RGB devices on Linux:
>
> Optional: Provide a basic leds-subsystem driver:
> - The whole device is treated as a singular RGB led in the current leds uapi
> - Backwards compatibility
> - Have something work out-of-the-box and during boot time
> - The driver also registers a misc device with a singluar sysfs attribute
> select_uapi
> - reading this gives back "[leds] none"
> - the current active uapi can be selected by writing it to that attribute
> - switching the uapi means deregistering the device from that entirely
> and registering and initializing it with the new one froms scratch
> - selecting none only does the deregistering
>
> If the device is already reachable by userspace directly, e.g. via hidraw, the
> kernel will only offer this basic implementation and a more complex driver has
> to be implemented in userspace.
> - This driver has to use the select_uapi attribute first and select "none"
> to avoid undefined behaviour caused by accessing the leds upai and hidraw to
> control the lighting at the same time
> - Question: How to best associate the select_uapi attribute to the
> corresponding hidraw (or other) direct access channel? So that a userspace
> driver can reliable check whether or not this has to be set.
>
> Devices not reachable by userspace directly, e.g. because they are controled via
> a wmi interface, can also be implemented in the new rgbledstring-subsystem
> (working title) for more complex control
> - a rgbledstring device provides an ioctl interface (ioctl only no r/w)
> using /dev/rgbledstring0, /dev/rgbledstring1, etc. registered as a misc chardev.
> - get-device-info ioctl which returns in a single struct:
> - char name[64] /* Device model name /
> identifier, preferable human readable. For keyboards, if known to the driver,
> physical layout (or even printed layout) should be separated here */
> - enum device_type /* e.g. keyboard, mouse,
> lightbar, etc. */
> - char firmware_version_string[64] /* if known to the driver,
> empty otherwise */
> - char serial_number[64] /* if known to the driver,
> empty otherwise */
> - enum supported_modes[64] /* modes supported by the
> firmware e.g. static/direct, breathing, scan, raindrops, etc. */
> - get-mode-info icotl, RFC here: Hans thinks it is better to have the
> modes and their inputs staticly defined and have, if required, something like
> breathing_clevo_1, breathing_clevo_2, breathing_tongfang_1 if the inputs vary
> between vendors. I think a dynamic approach could be useful where userspace just
> queries the struct required for each individual mode.
> - input: a mode from the supported_modes extracted from get-device-info
> - output: static information about the mode, e.g.
> max_animation_speed, max_brightness, etc.
> - output: the struct/a list of attributes and their types required
> to configure the mode
> - set-mode ioctl takes a single struct:
> - enum mode /* from supported_modes */
> - union data
> - char raw[3072]
> - <all structs returned by get-mode-info>
> - The driver also registers a singluar sysfs attribute select_uapi
> - reading this gives back "[leds] rgbledstring none" or
> "[rgbledstring] none" respectifly
> - Discussion question: should select_uapi instead be use_leds_uapi
> - if 1: use basic leds driver
> - if 0: if device is userspace accessible no kernel driver is
> active, if device ist not userspace accessible register rgbledstring (aka
> implicit separation between rgbledstring and none instead of explicit one)
>
> Zone configuration would be seen as a subset of mode configuration, as I suspect
> not every mode needs the zone configuration even on devices that offer it?
>
> The most simple mode would be static/direct and the set-mode struct would look
> like this:
> {
> enum mode, /* = static */
> {
> uint8 brightness, /* global brightness, some keyboards offer this */
> uint8 color[<number_of_leds>*3]
> }
> }
>
> Question: Are there modes that have a separate setup command that is only
> required once and then a continuous stream of update information? If yes, should
> we reflect that by splitting set-mode into set-mode-setup and set-mode-update
> (with get-mode-info returning one struct for each)? Or should userspace just
> always send setup and update information and it's up to the kernel driver to
> only resend the setup command when something has changed? In the former case
> set-mode-update might be a noop in most cases.
>
> Discussion on this might also happen here:
> https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1751170108
>
> Regards,
>
> Werner
>
>
Hi Werner,
I don't have a particular opinion as I don't know too much about RGB
keyboards. I just want to provide some food for thought and provide
some extra context of other devices. Just to challenge the discussion
and make sure than any API is flexible enough as it is hard to change
kernel interfaces later on.
At Sony our PlayStation controllers historically had a variety of LEDs
whether basic indicator ones (e.g. used to pick a player number) as
well as RGB leds. The devices are all HID based, but we do custom
parsing in hid-playstation to break out them out through LED framework
(regular leds and leds-class-multicolor for RGB). They were a bit of a
nightmare for applications to discover as crawling sysfs isn't fun (we
wrote a lot of code for Android's input framework to do this for our
own peripherals, but others too).
I'm not entirely sure where your RGB proposal is headed, but if one of
the higher goals is making dealing with LEDs and input devices easier,
maybe this extra info helps some of the discussion.
Thanks,
Roderick Colenbrander
^ permalink raw reply
* Re: [PATCH v1 2/7] HID: playstation: DS4: Don't fail on MAC address request
From: Max Staudt @ 2024-01-31 15:05 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <CAEc3jaDp-GRoZs9Pp0XxCeARfPx0xFq5SdNkignGeCu0P2+Fdw@mail.gmail.com>
On 1/31/24 05:59, Roderick Colenbrander wrote:
> I remember on the console side that we support a number of controllers
> including our official model and some licensed controllers. I recall
> them taking some different codepaths and HID reports differently. It
> has been a while, so I don't recall the details. If I remember it
> could be that all of the licensed ones were USB-only (of course there
> are some Bluetooth capable clones).
Now that is an interesting tidbit... if you learn more, I'd be curious to hear about it if possible!
> I'm not sure about the best way to handle this. I have kind of been
> leaning towards doing a vid/pid like check for this case even though I
> really hate it. It could be within dualshock4_get_mac_address as we do
> some other special handling there too (although having the caller of
> dualshock4_get_mac_address do it is an option too, but I think within
> get_mac_address is slightly nicer for now).
As suggested in the 7545:0104 patch, how about dropping this patch as well, until we encounter a device we really want to add and that does not provide a MAC address?
If it's okay for you, I'd send a v2 of everything after hearing your comment on the patch to make controllers work that don't provide gyro calibration data.
Max
^ permalink raw reply
* Re: [PATCH v1 7/7] HID: playstation: DS4: Add VID/PID for SZ-MYPOWER controllers
From: Max Staudt @ 2024-01-31 14:48 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <CAEc3jaCifoWW3ZXHvySSfgwhVm1AffYe=z7HRP9RjmYyu53w7Q@mail.gmail.com>
On 1/31/24 06:07, Roderick Colenbrander wrote:
> Hmpf, euhm euhm I'm not entirely sure what makes sense. From the
> sounds of it are somewhat broken devices (buggy firmwares on them) or
> perhaps one of your controllers (the one with not working touch) is
> perhaps broken.
>
> Some of the patches like handling report id 0x1 (minimal) won't hurt,
> the LED fixes won't either. It makes it easier to add more devices. I
> wonder if we have fully have enough data.
>
> Need to think a bit...
Yeah, maybe for now, let's focus on the patches that you don't see much trouble with. Better to enable some devices, than none.
I suggest dropping this here patch (enabling 7545:0104) for now, and if there's ever a change of mind, we can just pick it from the LKML archives :)
You can also drop the other patch that you're uneasy about, since I believe these 7545:0104 devices are the only ones I've observed to not implement the what-is-your-MAC-address command.
Max
^ permalink raw reply
* [PATCH v7 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
From: Kamel Bouhara @ 2024-01-31 14:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy
Cc: catalin.popescu, mark.satterthwaite, Thomas Petazzoni,
Gregory Clement, bsp-development.geo, Kamel Bouhara
In-Reply-To: <20240131141158.3350344-1-kamel.bouhara@bootlin.com>
Add a new driver for the TouchNetix's axiom family of
touchscreen controllers. This driver only supports i2c
and can be later adapted for SPI and USB support.
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
---
MAINTAINERS | 1 +
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/touchnetix_axiom.c | 666 +++++++++++++++++++
4 files changed, 680 insertions(+)
create mode 100644 drivers/input/touchscreen/touchnetix_axiom.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4b3ed2f22b89..de5fad8f317a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22262,6 +22262,7 @@ M: Kamel Bouhara <kamel.bouhara@bootlin.com>
L: linux-input@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
+F: drivers/input/touchscreen/touchnetix_axiom.c
TPM DEVICE DRIVER
M: Peter Huewe <peterhuewe@gmx.de>
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index e3e2324547b9..f36bee8d8696 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -803,6 +803,18 @@ config TOUCHSCREEN_MIGOR
To compile this driver as a module, choose M here: the
module will be called migor_ts.
+config TOUCHSCREEN_TOUCHNETIX_AXIOM
+ tristate "TouchNetix AXIOM based touchscreen controllers"
+ depends on I2C
+ help
+ Say Y here if you have a axiom touchscreen connected to
+ your system.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called axiom.
+
config TOUCHSCREEN_TOUCHRIGHT
tristate "Touchright serial touchscreen"
select SERIO
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 62bd24f3ac8e..8e32a2df5e18 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_TOUCHSCREEN_SUR40) += sur40.o
obj-$(CONFIG_TOUCHSCREEN_SURFACE3_SPI) += surface3_spi.o
obj-$(CONFIG_TOUCHSCREEN_TI_AM335X_TSC) += ti_am335x_tsc.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o
+obj-$(CONFIG_TOUCHSCREEN_TOUCHNETIX_AXIOM) += touchnetix_axiom.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
obj-$(CONFIG_TOUCHSCREEN_TS4800) += ts4800-ts.o
diff --git a/drivers/input/touchscreen/touchnetix_axiom.c b/drivers/input/touchscreen/touchnetix_axiom.c
new file mode 100644
index 000000000000..49bdb7652c1f
--- /dev/null
+++ b/drivers/input/touchscreen/touchnetix_axiom.c
@@ -0,0 +1,666 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TouchNetix axiom Touchscreen Driver
+ *
+ * Copyright (C) 2020-2023 TouchNetix Ltd.
+ *
+ * Author(s): Bart Prescott <bartp@baasheep.co.uk>
+ * Pedro Torruella <pedro.torruella@touchnetix.com>
+ * Mark Satterthwaite <mark.satterthwaite@touchnetix.com>
+ * Hannah Rossiter <hannah.rossiter@touchnetix.com>
+ * Kamel Bouhara <kamel.bouhara@bootlin.com>
+ *
+ */
+#include <linux/bitfield.h>
+#include <linux/crc16.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/input/mt.h>
+#include <linux/input/touchscreen.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/regmap.h>
+
+#include <asm/unaligned.h>
+#define AXIOM_PROX_LEVEL -128
+#define AXIOM_DMA_OPS_DELAY_USEC 250
+#define AXIOM_STARTUP_TIME_MS 110
+/*
+ * Register group u31 has 2 pages for usage table entries.
+ */
+#define AXIOM_U31_MAX_USAGES 0xff
+#define AXIOM_U31_BYTES_PER_USAGE 6
+#define AXIOM_U31_PAGE0_LENGTH 0x0C
+#define AXIOM_U31_BOOTMODE_MASK BIT(7)
+#define AXIOM_U31_DEVID_MASK GENMASK(14, 0)
+
+#define AXIOM_MAX_REPORT_LEN 0x7f
+
+#define AXIOM_CMD_HEADER_READ_MASK BIT(15)
+#define AXIOM_U41_MAX_TARGETS 10
+
+#define AXIOM_U46_AUX_CHANNELS 4
+#define AXIOM_U46_AUX_MASK GENMASK(11, 0)
+
+#define AXIOM_COMMS_MAX_USAGE_PAGES 3
+#define AXIOM_COMMS_PAGE_SIZE 256
+#define AXIOM_COMMS_REPORT_LEN_MASK GENMASK(6, 0)
+
+#define AXIOM_REPORT_USAGE_ID 0x34
+#define AXIOM_DEVINFO_USAGE_ID 0x31
+#define AXIOM_USAGE_2HB_REPORT_ID 0x01
+#define AXIOM_USAGE_2AUX_REPORT_ID 0x46
+#define AXIOM_USAGE_2DCTS_REPORT_ID 0x41
+
+#define AXIOM_PAGE_OFFSET_MASK GENMASK(6, 0)
+
+struct axiom_devinfo {
+ __le16 device_id;
+ u8 fw_minor;
+ u8 fw_major;
+ u8 fw_info_extra;
+ u8 tcp_revision;
+ u8 bootloader_fw_minor;
+ u8 bootloader_fw_major;
+ __le16 jedec_id;
+ u8 num_usages;
+} __packed;
+
+/*
+ * Describes parameters of a specific usage, essentially a single element of
+ * the "Usage Table"
+ */
+struct axiom_usage_entry {
+ u8 id;
+ u8 is_report;
+ u8 start_page;
+ u8 num_pages;
+};
+
+/*
+ * Represents state of a touch or target when detected prior to a touch (eg.
+ * hover or proximity events).
+ */
+enum axiom_target_state {
+ AXIOM_TARGET_STATE_NOT_PRESENT = 0,
+ AXIOM_TARGET_STATE_PROX = 1,
+ AXIOM_TARGET_STATE_HOVER = 2,
+ AXIOM_TARGET_STATE_TOUCHING = 3,
+};
+
+struct axiom_u41_target {
+ enum axiom_target_state state;
+ u16 x;
+ u16 y;
+ s8 z;
+ bool insert;
+ bool touch;
+};
+
+struct axiom_target_report {
+ u8 index;
+ u8 present;
+ u16 x;
+ u16 y;
+ s8 z;
+};
+
+struct axiom_cmd_header {
+ __le16 target_address;
+ __le16 length;
+} __packed;
+
+struct axiom_data {
+ struct axiom_devinfo devinfo;
+ struct device *dev;
+ struct gpio_desc *reset_gpio;
+ struct i2c_client *client;
+ struct input_dev *input_dev;
+ u32 max_report_len;
+ u8 rx_buf[AXIOM_COMMS_MAX_USAGE_PAGES * AXIOM_COMMS_PAGE_SIZE];
+ struct axiom_u41_target targets[AXIOM_U41_MAX_TARGETS];
+ struct axiom_usage_entry usage_table[AXIOM_U31_MAX_USAGES];
+ bool usage_table_populated;
+ struct regulator *vdda;
+ struct regulator *vddi;
+ struct regmap *regmap;
+ struct touchscreen_properties prop;
+};
+
+static const struct regmap_config axiom_i2c_regmap_config = {
+ .reg_bits = 32,
+ .reg_format_endian = REGMAP_ENDIAN_LITTLE,
+ .val_bits = 8,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE,
+};
+
+/*
+ * axiom devices are typically configured to report touches at a rate
+ * of 100Hz (10ms) for systems that require polling for reports.
+ * When reports are polled, it will be expected to occasionally
+ * observe the overflow bit being set in the reports.
+ * This indicates that reports are not being read fast enough.
+ */
+#define POLL_INTERVAL_DEFAULT_MS 10
+
+/* Translate usage/page/offset triplet into physical address. */
+static u16 axiom_usage_to_target_address(struct axiom_data *ts, u8 usage, u8 page,
+ char offset)
+{
+ /* At the moment the convention is that u31 is always at physical address 0x0 */
+ if (!ts->usage_table_populated) {
+ if (usage == AXIOM_DEVINFO_USAGE_ID)
+ return ((page << 8) + offset);
+ else
+ return 0xffff;
+ }
+
+ if (page >= ts->usage_table[usage].num_pages) {
+ dev_err(ts->dev, "Invalid usage table! usage: u%02x, page: %02x, offset: %02x\n",
+ usage, page, offset);
+ return 0xffff;
+ }
+
+ return ((ts->usage_table[usage].start_page + page) << 8) + offset;
+}
+
+static int axiom_read(struct axiom_data *ts, u8 usage, u8 page, void *buf, u16 len)
+{
+ struct axiom_cmd_header cmd_header;
+ __le32 preamble;
+ int ret;
+
+ cmd_header.target_address = cpu_to_le16(axiom_usage_to_target_address(ts, usage, page, 0));
+ cmd_header.length = cpu_to_le16(len | AXIOM_CMD_HEADER_READ_MASK);
+
+ preamble = get_unaligned_le32((u8 *)&cmd_header);
+
+ ret = regmap_write(ts->regmap, preamble, 0);
+ if (ret) {
+ dev_err(ts->dev, "failed to write preamble, error %d\n", ret);
+ return ret;
+ }
+
+ ret = regmap_raw_read(ts->regmap, 0, buf, len);
+ if (ret) {
+ dev_err(ts->dev, "failed to read target address %04x, error %d\n",
+ cmd_header.target_address, ret);
+ return ret;
+ }
+
+ /* Wait device's DMA operations */
+ usleep_range(AXIOM_DMA_OPS_DELAY_USEC, AXIOM_DMA_OPS_DELAY_USEC + 50);
+
+ return 0;
+}
+
+/*
+ * One of the main purposes for reading the usage table is to identify
+ * which usages reside at which target address.
+ * When performing subsequent reads or writes to AXIOM, the target address
+ * is used to specify which usage is being accessed.
+ * Consider the following discovery code which will build up the usage table.
+ */
+static u32 axiom_populate_usage_table(struct axiom_data *ts)
+{
+ struct axiom_usage_entry *usage_table;
+ u8 *rx_data = ts->rx_buf;
+ u32 max_report_len = 0;
+ u32 usage_id;
+ int error;
+
+ usage_table = ts->usage_table;
+
+ /* Read the second page of usage u31 to get the usage table */
+ error = axiom_read(ts, AXIOM_DEVINFO_USAGE_ID, 1, rx_data,
+ (AXIOM_U31_BYTES_PER_USAGE * ts->devinfo.num_usages));
+
+ if (error)
+ return error;
+
+ for (usage_id = 0; usage_id < ts->devinfo.num_usages; usage_id++) {
+ u16 offset = (usage_id * AXIOM_U31_BYTES_PER_USAGE);
+ u8 id = rx_data[offset + 0];
+ u8 start_page = rx_data[offset + 1];
+ u8 num_pages = rx_data[offset + 2];
+ u32 max_offset = ((rx_data[offset + 3] & AXIOM_PAGE_OFFSET_MASK) + 1) * 2;
+
+ usage_table[id].is_report = !num_pages;
+
+ /* Store the entry into the usage table */
+ usage_table[id].id = id;
+ usage_table[id].start_page = start_page;
+ usage_table[id].num_pages = num_pages;
+
+ dev_dbg(ts->dev, "Usage u%02x Info: %*ph\n", id, AXIOM_U31_BYTES_PER_USAGE,
+ &rx_data[offset]);
+
+ /* Identify the max report length the module will receive */
+ if (usage_table[id].is_report && max_offset > max_report_len)
+ max_report_len = max_offset;
+ }
+
+ ts->usage_table_populated = true;
+
+ return max_report_len;
+}
+
+static int axiom_discover(struct axiom_data *ts)
+{
+ int error;
+
+ /*
+ * Fetch the first page of usage u31 to get the
+ * device information and the number of usages
+ */
+ error = axiom_read(ts, AXIOM_DEVINFO_USAGE_ID, 0, &ts->devinfo, AXIOM_U31_PAGE0_LENGTH);
+ if (error)
+ return error;
+
+ dev_dbg(ts->dev, " Boot Mode : %s\n",
+ FIELD_GET(AXIOM_U31_BOOTMODE_MASK,
+ le16_to_cpu(ts->devinfo.device_id)) ? "BLP" : "TCP");
+ dev_dbg(ts->dev, " Device ID : %04lx\n",
+ FIELD_GET(AXIOM_U31_DEVID_MASK, le16_to_cpu(ts->devinfo.device_id)));
+ dev_dbg(ts->dev, " Firmware Rev : %02x.%02x\n", ts->devinfo.fw_major,
+ ts->devinfo.fw_minor);
+ dev_dbg(ts->dev, " Bootloader Rev : %02x.%02x\n", ts->devinfo.bootloader_fw_major,
+ ts->devinfo.bootloader_fw_minor);
+ dev_dbg(ts->dev, " FW Extra Info : %04x\n", ts->devinfo.fw_info_extra);
+ dev_dbg(ts->dev, " Silicon : %04x\n", le16_to_cpu(ts->devinfo.jedec_id));
+ dev_dbg(ts->dev, " Number usages : %04x\n", ts->devinfo.num_usages);
+
+ ts->max_report_len = axiom_populate_usage_table(ts);
+ if (!ts->max_report_len || !ts->devinfo.num_usages ||
+ ts->max_report_len > AXIOM_MAX_REPORT_LEN) {
+ dev_err(ts->dev, "Invalid report length or usages number");
+ return -EINVAL;
+ }
+
+ dev_dbg(ts->dev, "Max Report Length: %u\n", ts->max_report_len);
+
+ return 0;
+}
+
+/*
+ * Support function to axiom_process_u41_report.
+ * Generates input-subsystem events for every target.
+ * After calling this function the caller shall issue
+ * a Sync to the input sub-system.
+ */
+static bool axiom_process_u41_report_target(struct axiom_data *ts,
+ struct axiom_target_report *target)
+{
+ struct input_dev *input_dev = ts->input_dev;
+ struct axiom_u41_target *target_prev_state;
+ enum axiom_target_state current_state;
+ int slot;
+
+ /* Verify the target index */
+ if (target->index >= AXIOM_U41_MAX_TARGETS) {
+ dev_err(ts->dev, "Invalid target index! %u\n", target->index);
+ return false;
+ }
+
+ target_prev_state = &ts->targets[target->index];
+
+ current_state = AXIOM_TARGET_STATE_NOT_PRESENT;
+
+ if (target->present) {
+ if (target->z >= 0)
+ current_state = AXIOM_TARGET_STATE_TOUCHING;
+ else if (target->z > AXIOM_PROX_LEVEL && target->z < 0)
+ current_state = AXIOM_TARGET_STATE_HOVER;
+ else if (target->z == AXIOM_PROX_LEVEL)
+ current_state = AXIOM_TARGET_STATE_PROX;
+ }
+
+ if (target_prev_state->state == current_state &&
+ target_prev_state->x == target->x &&
+ target_prev_state->y == target->y &&
+ target_prev_state->z == target->z)
+ return false;
+
+ slot = target->index;
+
+ dev_dbg(ts->dev, "U41 Target T%u, slot:%u present:%u, x:%u, y:%u, z:%d\n",
+ target->index, slot, target->present,
+ target->x, target->y, target->z);
+
+ switch (current_state) {
+ case AXIOM_TARGET_STATE_NOT_PRESENT:
+ case AXIOM_TARGET_STATE_PROX:
+ if (!target_prev_state->insert)
+ break;
+ target_prev_state->insert = false;
+ input_mt_slot(input_dev, slot);
+
+ if (!slot)
+ input_report_key(input_dev, BTN_TOUCH, 0);
+
+ input_mt_report_slot_inactive(input_dev);
+ /*
+ * make sure the previous coordinates are
+ * all off screen when the finger comes back
+ */
+ target->x = 65535;
+ target->y = 65535;
+ target->z = AXIOM_PROX_LEVEL;
+ break;
+ case AXIOM_TARGET_STATE_HOVER:
+ case AXIOM_TARGET_STATE_TOUCHING:
+ target_prev_state->insert = true;
+ input_mt_slot(input_dev, slot);
+ input_report_abs(input_dev, ABS_MT_TRACKING_ID, slot);
+ input_report_abs(input_dev, ABS_MT_POSITION_X, target->x);
+ input_report_abs(input_dev, ABS_MT_POSITION_Y, target->y);
+
+ if (current_state == AXIOM_TARGET_STATE_TOUCHING) {
+ input_report_abs(input_dev, ABS_MT_DISTANCE, 0);
+ input_report_abs(input_dev, ABS_DISTANCE, 0);
+ input_report_abs(input_dev, ABS_MT_PRESSURE, target->z);
+ input_report_abs(input_dev, ABS_PRESSURE, target->z);
+ } else {
+ input_report_abs(input_dev, ABS_MT_DISTANCE, -target->z);
+ input_report_abs(input_dev, ABS_DISTANCE, -target->z);
+ input_report_abs(input_dev, ABS_MT_PRESSURE, 0);
+ input_report_abs(input_dev, ABS_PRESSURE, 0);
+ }
+
+ if (!slot)
+ input_report_key(input_dev, BTN_TOUCH, (current_state ==
+ AXIOM_TARGET_STATE_TOUCHING));
+ break;
+ default:
+ break;
+ }
+
+ target_prev_state->state = current_state;
+ target_prev_state->x = target->x;
+ target_prev_state->y = target->y;
+ target_prev_state->z = target->z;
+
+ return true;
+}
+
+/*
+ * U41 is the output report of the 2D CTS and contains the status of targets
+ * (including contacts and pre-contacts) along with their X,Y,Z values.
+ * When a target has been removed (no longer detected),
+ * the corresponding X,Y,Z values will be zeroed.
+ */
+static bool axiom_process_u41_report(struct axiom_data *ts, u8 *rx_buf)
+{
+ struct axiom_target_report target;
+ bool update_done = false;
+ u16 target_status;
+ int i;
+
+ target_status = get_unaligned_le16(rx_buf + 1);
+
+ for (i = 0; i < AXIOM_U41_MAX_TARGETS; i++) {
+ u8 *target_step = &rx_buf[i * 4];
+
+ target.index = i;
+ target.present = ((target_status & (1 << i)) != 0) ? 1 : 0;
+ target.x = get_unaligned_le16(target_step + 3);
+ target.y = get_unaligned_le16(target_step + 5);
+ target.z = (s8)(rx_buf[i + 43]);
+ update_done |= axiom_process_u41_report_target(ts, &target);
+ }
+
+ return update_done;
+}
+
+/*
+ * U46 report contains a low level measurement data generated by the capacitive
+ * displacement sensor (CDS) algorithms from the auxiliary channels.
+ * This information is useful when tuning multi-press to assess mechanical
+ * consistency in the unit's construction.
+ */
+static void axiom_process_u46_report(struct axiom_data *ts, u8 *rx_buf)
+{
+ struct input_dev *input_dev = ts->input_dev;
+ u32 event_value;
+ u16 aux_value;
+ int i;
+
+ for (i = 0; i < AXIOM_U46_AUX_CHANNELS; i++) {
+ u8 *target_step = &rx_buf[i * 2];
+
+ aux_value = get_unaligned_le16(target_step + 1) & AXIOM_U46_AUX_MASK;
+ event_value = (i << 16) | (aux_value);
+ input_event(input_dev, EV_MSC, MSC_RAW, event_value);
+ }
+}
+
+/*
+ * Validates the crc and demultiplexes the axiom reports to the appropriate
+ * report handler
+ */
+static int axiom_handle_events(struct axiom_data *ts)
+{
+ struct input_dev *input_dev = ts->input_dev;
+ u8 *report_data = ts->rx_buf;
+ struct device *dev = ts->dev;
+ u16 crc_report;
+ u8 *crc_bytes;
+ u16 crc_calc;
+ int error;
+ u8 len;
+
+ error = axiom_read(ts, AXIOM_REPORT_USAGE_ID, 0, report_data, ts->max_report_len);
+ if (error)
+ return error;
+
+ len = (report_data[0] & AXIOM_COMMS_REPORT_LEN_MASK) << 1;
+ if (len <= 2) {
+ dev_err(dev, "Zero length report discarded.\n");
+ return -ENODATA;
+ }
+
+ /* Validate the report CRC */
+ crc_bytes = &report_data[len];
+
+ crc_report = get_unaligned_le16(crc_bytes - 2);
+ /* Length is in 16 bit words and remove the size of the CRC16 itself */
+ crc_calc = crc16(0, report_data, (len - 2));
+
+ if (crc_calc != crc_report) {
+ dev_err(dev,
+ "CRC mismatch! Expected: %#x, Calculated CRC: %#x.\n",
+ crc_report, crc_calc);
+ return -EINVAL;
+ }
+
+ switch (report_data[1]) {
+ case AXIOM_USAGE_2DCTS_REPORT_ID:
+ if (axiom_process_u41_report(ts, &report_data[1])) {
+ input_mt_sync_frame(input_dev);
+ input_sync(input_dev);
+ }
+ break;
+
+ case AXIOM_USAGE_2AUX_REPORT_ID:
+ /* This is an aux report (force) */
+ axiom_process_u46_report(ts, &report_data[1]);
+ input_mt_sync(input_dev);
+ input_sync(input_dev);
+ break;
+
+ case AXIOM_USAGE_2HB_REPORT_ID:
+ /* This is a heartbeat report */
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void axiom_i2c_poll(struct input_dev *input_dev)
+{
+ struct axiom_data *ts = input_get_drvdata(input_dev);
+
+ axiom_handle_events(ts);
+}
+
+static irqreturn_t axiom_irq(int irq, void *dev_id)
+{
+ struct axiom_data *ts = dev_id;
+
+ axiom_handle_events(ts);
+
+ return IRQ_HANDLED;
+}
+
+static void axiom_reset(struct gpio_desc *reset_gpio)
+{
+ gpiod_set_value_cansleep(reset_gpio, 1);
+ usleep_range(1000, 2000);
+ gpiod_set_value_cansleep(reset_gpio, 0);
+ msleep(AXIOM_STARTUP_TIME_MS);
+}
+
+static int axiom_i2c_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct input_dev *input_dev;
+ struct axiom_data *ts;
+ u32 poll_interval;
+ int target;
+ int error;
+
+ ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
+ if (!ts)
+ return -ENOMEM;
+
+ i2c_set_clientdata(client, ts);
+ ts->client = client;
+ ts->dev = dev;
+
+ ts->regmap = devm_regmap_init_i2c(client, &axiom_i2c_regmap_config);
+ error = PTR_ERR_OR_ZERO(ts->regmap);
+ if (error) {
+ dev_err(dev, "Failed to initialize regmap: %d\n", error);
+ return error;
+ }
+
+ ts->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ts->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(ts->reset_gpio), "failed to get reset GPIO\n");
+
+ if (ts->reset_gpio)
+ axiom_reset(ts->reset_gpio);
+
+ ts->vddi = devm_regulator_get_optional(dev, "vddi");
+ if (!IS_ERR(ts->vddi)) {
+ error = devm_regulator_get_enable(dev, "vddi");
+ if (error)
+ return dev_err_probe(&client->dev, error,
+ "Failed to enable vddi regulator\n");
+ }
+
+ ts->vdda = devm_regulator_get_optional(dev, "vdda");
+ if (!IS_ERR(ts->vdda)) {
+ error = devm_regulator_get_enable(dev, "vdda");
+ if (error)
+ return dev_err_probe(&client->dev, error,
+ "Failed to enable vdda regulator\n");
+ msleep(AXIOM_STARTUP_TIME_MS);
+ }
+
+ error = axiom_discover(ts);
+ if (error)
+ return dev_err_probe(dev, error, "Failed touchscreen discover\n");
+
+ input_dev = devm_input_allocate_device(ts->dev);
+ if (!input_dev)
+ return -ENOMEM;
+
+ input_dev->name = "TouchNetix axiom Touchscreen";
+ input_dev->phys = "input/axiom_ts";
+
+ input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, 65535, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, 65535, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_TOOL_TYPE, 0, MT_TOOL_MAX, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_DISTANCE, 0, 127, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, 127, 0, 0);
+
+ touchscreen_parse_properties(input_dev, true, &ts->prop);
+
+ /* Registers the axiom device as a touchscreen instead of a mouse pointer */
+ error = input_mt_init_slots(input_dev, AXIOM_U41_MAX_TARGETS, INPUT_MT_DIRECT);
+ if (error)
+ return error;
+
+ /* Enables the raw data for up to 4 force channels to be sent to the input subsystem */
+ set_bit(EV_REL, input_dev->evbit);
+ set_bit(EV_MSC, input_dev->evbit);
+ /* Declare that we support "RAW" Miscellaneous events */
+ set_bit(MSC_RAW, input_dev->mscbit);
+
+ ts->input_dev = input_dev;
+ input_set_drvdata(ts->input_dev, ts);
+
+ /* Ensure that all reports are initialised to not be present. */
+ for (target = 0; target < AXIOM_U41_MAX_TARGETS; target++)
+ ts->targets[target].state = AXIOM_TARGET_STATE_NOT_PRESENT;
+
+ error = devm_request_threaded_irq(dev, client->irq, NULL,
+ axiom_irq, IRQF_ONESHOT, dev_name(dev), ts);
+ if (error) {
+ dev_info(dev, "Request irq failed, falling back to polling mode");
+
+ error = input_setup_polling(input_dev, axiom_i2c_poll);
+ if (error)
+ return dev_err_probe(ts->dev, error, "Unable to set up polling mode\n");
+
+ if (!device_property_read_u32(ts->dev, "poll-interval", &poll_interval))
+ input_set_poll_interval(input_dev, poll_interval);
+ else
+ input_set_poll_interval(input_dev, POLL_INTERVAL_DEFAULT_MS);
+ }
+
+ error = input_register_device(input_dev);
+ if (error)
+ return dev_err_probe(ts->dev, error,
+ "Could not register with Input Sub-system.\n");
+
+ return 0;
+}
+
+static const struct i2c_device_id axiom_i2c_id_table[] = {
+ { "ax54a" },
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, axiom_i2c_id_table);
+
+static const struct of_device_id axiom_i2c_of_match[] = {
+ { .compatible = "touchnetix,ax54a", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, axiom_i2c_of_match);
+
+static struct i2c_driver axiom_i2c_driver = {
+ .driver = {
+ .name = "axiom",
+ .of_match_table = axiom_i2c_of_match,
+ },
+ .id_table = axiom_i2c_id_table,
+ .probe = axiom_i2c_probe,
+};
+module_i2c_driver(axiom_i2c_driver);
+
+MODULE_AUTHOR("Bart Prescott <bartp@baasheep.co.uk>");
+MODULE_AUTHOR("Pedro Torruella <pedro.torruella@touchnetix.com>");
+MODULE_AUTHOR("Mark Satterthwaite <mark.satterthwaite@touchnetix.com>");
+MODULE_AUTHOR("Hannah Rossiter <hannah.rossiter@touchnetix.com>");
+MODULE_AUTHOR("Kamel Bouhara <kamel.bouhara@bootlin.com>");
+MODULE_DESCRIPTION("TouchNetix axiom touchscreen I2C bus driver");
+MODULE_LICENSE("GPL");
--
2.25.1
^ permalink raw reply related
* [PATCH v7 1/3] dt-bindings: vendor-prefixes: Add TouchNetix AS
From: Kamel Bouhara @ 2024-01-31 14:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy
Cc: catalin.popescu, mark.satterthwaite, Thomas Petazzoni,
Gregory Clement, bsp-development.geo, Kamel Bouhara,
Krzysztof Kozlowski
In-Reply-To: <20240131141158.3350344-1-kamel.bouhara@bootlin.com>
Add vendor prefix for TouchNetix AS (https://www.touchnetix.com/products/).
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 1a0dc04f1db4..88954a286107 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1444,6 +1444,8 @@ patternProperties:
description: Toradex AG
"^toshiba,.*":
description: Toshiba Corporation
+ "^touchnetix,.*":
+ description: TouchNetix AS
"^toumaz,.*":
description: Toumaz
"^tpk,.*":
--
2.25.1
^ permalink raw reply related
* [PATCH v7 2/3] dt-bindings: input: Add TouchNetix axiom touchscreen
From: Kamel Bouhara @ 2024-01-31 14:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy
Cc: catalin.popescu, mark.satterthwaite, Thomas Petazzoni,
Gregory Clement, bsp-development.geo, Kamel Bouhara
In-Reply-To: <20240131141158.3350344-1-kamel.bouhara@bootlin.com>
Add the TouchNetix axiom I2C touchscreen device tree bindings
documentation.
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
---
.../input/touchscreen/touchnetix,ax54a.yaml | 62 +++++++++++++++++++
MAINTAINERS | 6 ++
2 files changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
new file mode 100644
index 000000000000..66229a4d6f15
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/touchnetix,ax54a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TouchNetix Axiom series touchscreen controller
+
+maintainers:
+ - Kamel Bouhara <kamel.bouhara@bootlin.com>
+
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
+ - $ref: /schemas/input/input.yaml#
+
+properties:
+ compatible:
+ const: touchnetix,ax54a
+
+ reg:
+ const: 0x66
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ vdda-supply:
+ description: Analog power supply regulator on VDDA pin
+
+ vddi-supply:
+ description: I/O power supply regulator on VDDI pin
+
+required:
+ - compatible
+ - reg
+ - vdda-supply
+ - vddi-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@66 {
+ compatible = "touchnetix,ax54a";
+ reg = <0x66>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+ vdda-supply = <&vdda_reg>;
+ vddi-supply = <&vddi_reg>;
+ poll-interval = <20>;
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index c4828ab15f1a..4b3ed2f22b89 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22257,6 +22257,12 @@ L: platform-driver-x86@vger.kernel.org
S: Maintained
F: drivers/platform/x86/toshiba-wmi.c
+TOUCHNETIX AXIOM I2C TOUCHSCREEN DRIVER
+M: Kamel Bouhara <kamel.bouhara@bootlin.com>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
+
TPM DEVICE DRIVER
M: Peter Huewe <peterhuewe@gmx.de>
M: Jarkko Sakkinen <jarkko@kernel.org>
--
2.25.1
^ permalink raw reply related
* [PATCH v7 0/3] Input: Add TouchNetix axiom touchscreen driver
From: Kamel Bouhara @ 2024-01-31 14:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy
Cc: catalin.popescu, mark.satterthwaite, Thomas Petazzoni,
Gregory Clement, bsp-development.geo, Kamel Bouhara
Add a new driver for the TouchNetix's axiom family of touchscreen
controller. This driver only support i2c and can be later adapted for
SPI and USB support.
---
Changes in v2:
- Add device tree binding documentation
- Move core functions in axiom_i2c as we only care about i2c support now
- Use static function when required
- Use syntax dev_err_probe()
- Add an hardware based reset
Changes in v3:
- Remove irq-gpios property in dt-binding
- Use a generic node name
- Fix issues reported in https://lore.kernel.org/oe-kbuild-all/202310100300.oAC2M62R-lkp@intel.com/
Changes in v4:
- Cleanup unused headers and macros
- Use standard kernel type
- Namespace structures and functions
- Use packed struct when possible to avoid bitfield operators
- Fix missing break when address is found in axiom_populate_target_address()
- Split reads in two steps for the reports, first length then report
itself so we only read required bytes
- Get poll-interval from devicetree
- Add VDDI/VDDA regulators
- Add a startup delay of 110 ms required after VDDA/VDDI is applied
- Remove axiom_i2c_write() as it is no more used
Changes in v5:
- Fix wrong message constructed in axiom_i2c_read
- Delay required between i2c reads is >= 250us
- Do not split report reading in two phases as we'll
have to wait 500us
- Use lower-case in properties names
- Make regulators properties are required in dt-binding
- Fix bug report: https://lore.kernel.org/lkml/202312051457.y3N1q3sZ-lkp@intel.com/
- Fix bug report: https://lore.kernel.org/lkml/6f8e3b64-5b21-4a50-8680-063ef7a93bdb@suswa.mountain/
Changes in v6:
- Fix missing unevaluatedProperties.in dt-binding
- Use __le16 to correctly deal with device endianness
- Use standart kernel types s/char/u8/
- Use regmap api as driver might support spi later
- Use get_unaligned_le16() for the sake of clarity
- Use devm_regulator_enable_optional()
Changes in v7:
- Remove startup time from dt-binding
- Fix usage table not correctly populated
Kamel Bouhara (3):
dt-bindings: vendor-prefixes: Add TouchNetix AS
dt-bindings: input: Add TouchNetix axiom touchscreen
Input: Add TouchNetix axiom i2c touchscreen driver
.../input/touchscreen/touchnetix,ax54a.yaml | 62 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 +
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/touchnetix_axiom.c | 666 ++++++++++++++++++
6 files changed, 750 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
create mode 100644 drivers/input/touchscreen/touchnetix_axiom.c
--
2.25.1
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 3aa182bbc5b657329a8b85fa5303b8af0f461636
From: kernel test robot @ 2024-01-31 11:52 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 3aa182bbc5b657329a8b85fa5303b8af0f461636 Input: goodix-berlin - add SPI support for Goodix Berlin Touchscreen IC
elapsed time: 728m
configs tested: 178
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240131 gcc
arc randconfig-002-20240131 gcc
arc tb10x_defconfig gcc
arm allmodconfig gcc
arm allnoconfig gcc
arm allyesconfig gcc
arm defconfig clang
arm randconfig-001-20240131 clang
arm randconfig-002-20240131 clang
arm randconfig-003-20240131 clang
arm randconfig-004-20240131 clang
arm wpcm450_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240131 clang
arm64 randconfig-002-20240131 clang
arm64 randconfig-003-20240131 clang
arm64 randconfig-004-20240131 clang
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240131 gcc
csky randconfig-002-20240131 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20240131 clang
hexagon randconfig-002-20240131 clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 buildonly-randconfig-001-20240131 clang
i386 buildonly-randconfig-002-20240131 clang
i386 buildonly-randconfig-003-20240131 clang
i386 buildonly-randconfig-004-20240131 clang
i386 buildonly-randconfig-005-20240131 clang
i386 buildonly-randconfig-006-20240131 clang
i386 defconfig gcc
i386 randconfig-001-20240131 clang
i386 randconfig-002-20240131 clang
i386 randconfig-003-20240131 clang
i386 randconfig-004-20240131 clang
i386 randconfig-005-20240131 clang
i386 randconfig-006-20240131 clang
i386 randconfig-011-20240131 gcc
i386 randconfig-012-20240131 gcc
i386 randconfig-013-20240131 gcc
i386 randconfig-014-20240131 gcc
i386 randconfig-015-20240131 gcc
i386 randconfig-016-20240131 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240131 gcc
loongarch randconfig-002-20240131 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k m5249evb_defconfig gcc
m68k m5275evb_defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig clang
mips allyesconfig gcc
mips loongson1b_defconfig gcc
mips maltasmvp_eva_defconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240131 gcc
nios2 randconfig-002-20240131 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240131 gcc
parisc randconfig-002-20240131 gcc
parisc64 defconfig gcc
powerpc allmodconfig clang
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc cm5200_defconfig gcc
powerpc holly_defconfig gcc
powerpc randconfig-001-20240131 clang
powerpc randconfig-002-20240131 clang
powerpc randconfig-003-20240131 clang
powerpc64 randconfig-001-20240131 clang
powerpc64 randconfig-002-20240131 clang
powerpc64 randconfig-003-20240131 clang
riscv allmodconfig gcc
riscv allnoconfig clang
riscv allyesconfig gcc
riscv defconfig gcc
riscv randconfig-001-20240131 clang
riscv randconfig-002-20240131 clang
riscv rv32_defconfig clang
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-001-20240131 gcc
s390 randconfig-002-20240131 gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh apsh4a3a_defconfig gcc
sh defconfig gcc
sh dreamcast_defconfig gcc
sh edosk7760_defconfig gcc
sh randconfig-001-20240131 gcc
sh randconfig-002-20240131 gcc
sh shx3_defconfig gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240131 gcc
sparc64 randconfig-002-20240131 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20240131 clang
um randconfig-002-20240131 clang
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240131 clang
x86_64 buildonly-randconfig-002-20240131 clang
x86_64 buildonly-randconfig-003-20240131 clang
x86_64 buildonly-randconfig-004-20240131 clang
x86_64 buildonly-randconfig-005-20240131 clang
x86_64 buildonly-randconfig-006-20240131 clang
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-001-20240131 gcc
x86_64 randconfig-002-20240131 gcc
x86_64 randconfig-003-20240131 gcc
x86_64 randconfig-004-20240131 gcc
x86_64 randconfig-005-20240131 gcc
x86_64 randconfig-006-20240131 gcc
x86_64 randconfig-011-20240131 clang
x86_64 randconfig-012-20240131 clang
x86_64 randconfig-013-20240131 clang
x86_64 randconfig-014-20240131 clang
x86_64 randconfig-015-20240131 clang
x86_64 randconfig-016-20240131 clang
x86_64 randconfig-071-20240131 clang
x86_64 randconfig-072-20240131 clang
x86_64 randconfig-073-20240131 clang
x86_64 randconfig-074-20240131 clang
x86_64 randconfig-075-20240131 clang
x86_64 randconfig-076-20240131 clang
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa allnoconfig gcc
xtensa randconfig-001-20240131 gcc
xtensa randconfig-002-20240131 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Future handling of complex RGB devices on Linux
From: Werner Sembach @ 2024-01-31 11:41 UTC (permalink / raw)
To: Hans de Goede, Pavel Machek
Cc: Lee Jones, jikos, linux-kernel, Jelle van der Waa, Miguel Ojeda,
dri-devel@lists.freedesktop.org, linux-input, ojeda, linux-leds
In-Reply-To: <477d30ee-247e-47e6-bc74-515fd87fdc13@redhat.com>
Hi,
so I combined Hans last draft, with the discussion since then and the comments
from the OpenRGB maintainers from here
https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916 and my own experience
and came up witrh this rough updated draft for the new uapi:
Future handling of complex RGB devices on Linux:
Optional: Provide a basic leds-subsystem driver:
- The whole device is treated as a singular RGB led in the current leds uapi
- Backwards compatibility
- Have something work out-of-the-box and during boot time
- The driver also registers a misc device with a singluar sysfs attribute
select_uapi
- reading this gives back "[leds] none"
- the current active uapi can be selected by writing it to that attribute
- switching the uapi means deregistering the device from that entirely
and registering and initializing it with the new one froms scratch
- selecting none only does the deregistering
If the device is already reachable by userspace directly, e.g. via hidraw, the
kernel will only offer this basic implementation and a more complex driver has
to be implemented in userspace.
- This driver has to use the select_uapi attribute first and select "none"
to avoid undefined behaviour caused by accessing the leds upai and hidraw to
control the lighting at the same time
- Question: How to best associate the select_uapi attribute to the
corresponding hidraw (or other) direct access channel? So that a userspace
driver can reliable check whether or not this has to be set.
Devices not reachable by userspace directly, e.g. because they are controled via
a wmi interface, can also be implemented in the new rgbledstring-subsystem
(working title) for more complex control
- a rgbledstring device provides an ioctl interface (ioctl only no r/w)
using /dev/rgbledstring0, /dev/rgbledstring1, etc. registered as a misc chardev.
- get-device-info ioctl which returns in a single struct:
- char name[64] /* Device model name /
identifier, preferable human readable. For keyboards, if known to the driver,
physical layout (or even printed layout) should be separated here */
- enum device_type /* e.g. keyboard, mouse,
lightbar, etc. */
- char firmware_version_string[64] /* if known to the driver,
empty otherwise */
- char serial_number[64] /* if known to the driver,
empty otherwise */
- enum supported_modes[64] /* modes supported by the
firmware e.g. static/direct, breathing, scan, raindrops, etc. */
- get-mode-info icotl, RFC here: Hans thinks it is better to have the
modes and their inputs staticly defined and have, if required, something like
breathing_clevo_1, breathing_clevo_2, breathing_tongfang_1 if the inputs vary
between vendors. I think a dynamic approach could be useful where userspace just
queries the struct required for each individual mode.
- input: a mode from the supported_modes extracted from get-device-info
- output: static information about the mode, e.g.
max_animation_speed, max_brightness, etc.
- output: the struct/a list of attributes and their types required
to configure the mode
- set-mode ioctl takes a single struct:
- enum mode /* from supported_modes */
- union data
- char raw[3072]
- <all structs returned by get-mode-info>
- The driver also registers a singluar sysfs attribute select_uapi
- reading this gives back "[leds] rgbledstring none" or
"[rgbledstring] none" respectifly
- Discussion question: should select_uapi instead be use_leds_uapi
- if 1: use basic leds driver
- if 0: if device is userspace accessible no kernel driver is
active, if device ist not userspace accessible register rgbledstring (aka
implicit separation between rgbledstring and none instead of explicit one)
Zone configuration would be seen as a subset of mode configuration, as I suspect
not every mode needs the zone configuration even on devices that offer it?
The most simple mode would be static/direct and the set-mode struct would look
like this:
{
enum mode, /* = static */
{
uint8 brightness, /* global brightness, some keyboards offer this */
uint8 color[<number_of_leds>*3]
}
}
Question: Are there modes that have a separate setup command that is only
required once and then a continuous stream of update information? If yes, should
we reflect that by splitting set-mode into set-mode-setup and set-mode-update
(with get-mode-info returning one struct for each)? Or should userspace just
always send setup and update information and it's up to the kernel driver to
only resend the setup command when something has changed? In the former case
set-mode-update might be a noop in most cases.
Discussion on this might also happen here:
https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1751170108
Regards,
Werner
^ permalink raw reply
* Re: [RFC PATCH 2/5] mfd: add 88pm88x driver
From: Lee Jones @ 2024-01-31 11:03 UTC (permalink / raw)
To: Karel Balej
Cc: Karel Balej, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-input, devicetree, linux-kernel,
Duje Mihanović, ~postmarketos/upstreaming, phone-devel
In-Reply-To: <CYQ8MEQRJELE.2GB9316NZA998@gimli.ms.mff.cuni.cz>
On Sun, 28 Jan 2024, Karel Balej wrote:
> > > + /* GPIO1: DVC, GPIO0: input */
> > > + REG_SEQ0(PM88X_REG_GPIO_CTRL1, 0x40),
> >
> > Shouldn't you set these up using Pintrl?
>
> You mean to add a new MFD cell for the pins and write the respective
> driver? The downstream implementation has no such thing so I'm not sure
> if I would be able to do that from scratch.
This is not a Pinctrl driver.
Isn't there a generic API you can use?
> > > + /* GPIO2: input */
> > > + REG_SEQ0(PM88X_REG_GPIO_CTRL2, 0x00),
> > > + /* DVC2, DVC1 */
> >
> > Please unify all of the comments.
> >
> > They all use a different structure.
> >
> > > + REG_SEQ0(PM88X_REG_GPIO_CTRL3, 0x44),
> > > + /* GPIO5V_1:input, GPIO5V_2: input */
> > > + REG_SEQ0(PM88X_REG_GPIO_CTRL4, 0x00),
> > > + /* output 32 kHz from XO */
> > > + REG_SEQ0(PM88X_REG_AON_CTRL2, 0x2a),
> > > + /* OSC_FREERUN = 1, to lock FLL */
> > > + REG_SEQ0(PM88X_REG_BK_OSC_CTRL1, 0x0f),
> > > + /* XO_LJ = 1, enable low jitter for 32 kHz */
> > > + REG_SEQ0(PM88X_REG_LOWPOWER2, 0x20),
> > > + /* OV_VSYS and UV_VSYS1 comparators on VSYS disabled, VSYS_OVER_TH : 5.6V */
> > > + REG_SEQ0(PM88X_REG_LOWPOWER4, 0xc8),
> > > + /* set the duty cycle of charger DC/DC to max */
> > > + REG_SEQ0(PM88X_REG_BK_OSC_CTRL3, 0xc0),
> >
> > These all looks like they should be handled in their respective drivers?
> >
> > "patch"ing these in seems like a hack.
>
> To be honest, I don't really know why these are required and what effect
> they have -- the comments above taken from the downstream version are
> the only thing I have to go by. I might try removing them to see if
> there is any noticable change and whether they could be added only later
> with the respective drivers.
If you don't know that they are or what they do and you haven't tested
them, they should not be submitted upstream.
> > > +static struct mfd_cell pm88x_devs[] = {
> > > + {
> > > + .name = "88pm88x-onkey",
> > > + .num_resources = ARRAY_SIZE(onkey_resources),
> > > + .resources = onkey_resources,
> > > + .id = -1,
> > > + },
> > > +};
> >
> > It's not an MFD if it only supports a single device.
>
> As I have noted above with respect to the IRQ enum and also in the
> commit message, I have so far only added the parts which there is
> already use for. I intend to add the other parts along with the
> respective subdevice drivers, please see my regulator series [1] for an
> example.
>
> I thought this approach would make for shorter and simpler patches and
> also would allow me to make more informed decisions as I familiarize
> myself with the downstream subdevice drivers more closely one by one.
One device doesn't warrant an MFD. Please add more devices.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v6 2/3] dt-bindings: input: Add TouchNetix axiom touchscreen
From: Krzysztof Kozlowski @ 2024-01-31 10:59 UTC (permalink / raw)
To: Kamel Bouhara
Cc: Rob Herring, Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy, catalin.popescu, mark.satterthwaite,
Thomas Petazzoni, Gregory Clement, bsp-development.geo
In-Reply-To: <20240131090652.GB3004909@kb-xps>
On 31/01/2024 10:06, Kamel Bouhara wrote:
> Hello,
>
> On Wed, Jan 31, 2024 at 08:28:43AM +0100, Krzysztof Kozlowski wrote:
>> On 30/01/2024 23:28, Rob Herring wrote:
>>> On Fri, Jan 26, 2024 at 12:46:16PM +0100, Krzysztof Kozlowski wrote:
>>>> On 25/01/2024 17:58, Kamel Bouhara wrote:
>>>>> + reset-gpios:
>>>>> + maxItems: 1
>>>>> +
>>>>> + vdda-supply:
>>>>> + description: Analog power supply regulator on VDDA pin
>>>>> +
>>>>> + vddi-supply:
>>>>> + description: I/O power supply regulator on VDDI pin
>>>>> +
>>>>> + startup-time-ms:
>>>>> + description: delay after power supply regulator is applied in ms
>>>>
>>>> That's a regulator property - ramp up time.
>>>
>>> I'm sure there's an existing property name that could be used.
>>>
>>> But why is it needed? Is it variable per board with the same device? If
>>> not, it should be implied by the compatible.
>>
>> I meant, that regulators have such property. Unless this is coming from
>> the device needs, not from the regulator?
>>
>
> After looking again into the device's datasheet [1], the delay (startup
> time) is not really optional and it shouldn't be set through devicetree.
>
> IIUC, it have to be set unconditionally after a device reset or
> a vdda assertion.
>
> [1]: https://www.touchnetix.com/media/dgnjohor/tnxd00394-a3-axiom_ax54a_2d_touch_controller_datasheet.pdf
> --
OK, then it's not a regulator ramp up, but rather part of device driver
(deduced from compatible).
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v6 0/8] Convert DA906{1,2} bindings to json-schema
From: Biju Das @ 2024-01-31 10:47 UTC (permalink / raw)
To: Lee Jones
Cc: Wim Van Sebroeck, Guenter Roeck, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Support Opensource,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Steve Twiss, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
linux-watchdog@vger.kernel.org, Geert Uytterhoeven,
Prabhakar Mahadev Lad, biju.das.au,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <20240131084924.GD8551@google.com>
Hi Lee Jones,
Thanks for the feedback.
> -----Original Message-----
> From: Lee Jones <lee@kernel.org>
> Sent: Wednesday, January 31, 2024 8:49 AM
> Subject: Re: [PATCH v6 0/8] Convert DA906{1,2} bindings to json-schema
>
> On Mon, 29 Jan 2024, Biju Das wrote:
>
> > Hi Lee Jones,
> >
> > > -----Original Message-----
> > > From: Lee Jones <lee@kernel.org>
> > > Sent: Thursday, December 21, 2023 2:33 PM
> > > Subject: Re: [PATCH v6 0/8] Convert DA906{1,2} bindings to
> > > json-schema
> > >
> > > On Thu, 21 Dec 2023, Lee Jones wrote:
> > >
> > > > On Thu, 14 Dec 2023 08:09:03 +0000, Biju Das wrote:
> > > > > Convert the below bindings to json-schema
> > > > > 1) DA906{1,2} mfd bindings
> > > > > 2) DA906{1,2,3} onkey bindings
> > > > > 3) DA906{1,2,3} thermal bindings
> > > > >
> > > > > Also add fallback for DA9061 watchdog device and document
> > > > > DA9063 watchdog device.
> > > > >
> > > > > [...]
> > > >
> > > > Applied, thanks!
> > > >
> > > > [1/8] dt-bindings: mfd: da9062: Update watchdog description
> > > > commit: 9e7b13b805bcbe5335c2936d4c7ea0323ac69a81
> > > > [2/8] dt-bindings: watchdog: dlg,da9062-watchdog: Add fallback for
> > > DA9061 watchdog
> > > > commit: 28d34db7772f18490b52328f04a3bf69ed5390d2
> > > > [3/8] dt-bindings: watchdog: dlg,da9062-watchdog: Document DA9063
> > > watchdog
> > > > commit: d2a7dbb808870c17cffa2749ea877f61f298d098
> > > > [4/8] dt-bindings: mfd: dlg,da9063: Update watchdog child node
> > > > commit: d4018547a15a94c7e865b2cef82bff1cd43a32b3
> > > > [5/8] dt-bindings: input: Convert da906{1,2,3} onkey to json-schema
> > > > commit: db459d3da7bb9c37cb86897c7b321a49f8e40968
> > > > [6/8] dt-bindings: thermal: Convert da906{1,2} thermal to json-
> schema
> > > > commit: 998f499c843e360bcd9ee1fe9addc3b5d32f1234
> > > > [7/8] dt-bindings: mfd: dlg,da9063: Sort child devices
> > > > commit: 2bbf9d2a8e3bc933703dfda87cac953bed458496
> > > > [8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
> > > > commit: 522225161830f6a93f2aaabda99226c1ffddc8c4
> > >
> > > Submitted for testing. Pull-request to follow.
> >
> > The commit dc805ea058c0e ("MAINTAINERS: rectify entry for DIALOG
> > SEMICONDUCTOR DRIVERS") in mainline will give a conflict for patch#1.
> >
> > Patch#2 and patch#3 are already in mainline.
> >
> >
> > Please let me know if you want me to rebase and resend the patch
> > series
>
> That would be helpful, thanks.
>
> Please ensure all of the patches have my:
>
> Acked-by: Lee Jones <lee@kernel.org>
>
> ... applied, then I'll know to just apply them again.
OK, Resend the series[1] with Ack tag and Rb tag from Conor for patch#6
[1]
https://lore.kernel.org/all/20240131102656.3379-1-biju.das.jz@bp.renesas.com/
Cheers,
Biju
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS 80441f76ee67002437db61f3b317ed80cce085d2
From: kernel test robot @ 2024-01-31 10:41 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 80441f76ee67002437db61f3b317ed80cce085d2 Input: xpad - add Lenovo Legion Go controllers
elapsed time: 731m
configs tested: 155
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240131 gcc
arc randconfig-002-20240131 gcc
arm allmodconfig gcc
arm allnoconfig gcc
arm allyesconfig gcc
arm defconfig clang
arm randconfig-001-20240131 clang
arm randconfig-002-20240131 clang
arm randconfig-003-20240131 clang
arm randconfig-004-20240131 clang
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240131 clang
arm64 randconfig-002-20240131 clang
arm64 randconfig-003-20240131 clang
arm64 randconfig-004-20240131 clang
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240131 gcc
csky randconfig-002-20240131 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20240131 clang
hexagon randconfig-002-20240131 clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 buildonly-randconfig-001-20240131 clang
i386 buildonly-randconfig-002-20240131 clang
i386 buildonly-randconfig-003-20240131 clang
i386 buildonly-randconfig-004-20240131 clang
i386 buildonly-randconfig-005-20240131 clang
i386 buildonly-randconfig-006-20240131 clang
i386 defconfig gcc
i386 randconfig-001-20240131 clang
i386 randconfig-002-20240131 clang
i386 randconfig-003-20240131 clang
i386 randconfig-004-20240131 clang
i386 randconfig-005-20240131 clang
i386 randconfig-006-20240131 clang
i386 randconfig-011-20240131 gcc
i386 randconfig-012-20240131 gcc
i386 randconfig-013-20240131 gcc
i386 randconfig-014-20240131 gcc
i386 randconfig-015-20240131 gcc
i386 randconfig-016-20240131 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240131 gcc
loongarch randconfig-002-20240131 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig clang
mips allyesconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240131 gcc
nios2 randconfig-002-20240131 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240131 gcc
parisc randconfig-002-20240131 gcc
parisc64 defconfig gcc
powerpc allmodconfig clang
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc randconfig-001-20240131 clang
powerpc randconfig-002-20240131 clang
powerpc randconfig-003-20240131 clang
powerpc64 randconfig-001-20240131 clang
powerpc64 randconfig-002-20240131 clang
powerpc64 randconfig-003-20240131 clang
riscv allmodconfig gcc
riscv allnoconfig clang
riscv allyesconfig gcc
riscv defconfig gcc
riscv randconfig-001-20240131 clang
riscv randconfig-002-20240131 clang
riscv rv32_defconfig clang
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-001-20240131 gcc
s390 randconfig-002-20240131 gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh randconfig-001-20240131 gcc
sh randconfig-002-20240131 gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240131 gcc
sparc64 randconfig-002-20240131 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20240131 clang
um randconfig-002-20240131 clang
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240131 clang
x86_64 buildonly-randconfig-002-20240131 clang
x86_64 buildonly-randconfig-003-20240131 clang
x86_64 buildonly-randconfig-004-20240131 clang
x86_64 buildonly-randconfig-005-20240131 clang
x86_64 buildonly-randconfig-006-20240131 clang
x86_64 defconfig gcc
x86_64 randconfig-001-20240131 gcc
x86_64 randconfig-002-20240131 gcc
x86_64 randconfig-003-20240131 gcc
x86_64 randconfig-004-20240131 gcc
x86_64 randconfig-005-20240131 gcc
x86_64 randconfig-006-20240131 gcc
x86_64 randconfig-011-20240131 clang
x86_64 randconfig-012-20240131 clang
x86_64 randconfig-014-20240131 clang
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa randconfig-001-20240131 gcc
xtensa randconfig-002-20240131 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 0/3] HID: bpf: couple of upstream fixes
From: Benjamin Tissoires @ 2024-01-31 10:38 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Dan Carpenter, Daniel Borkmann,
Andrii Nakryiko, Benjamin Tissoires
Cc: linux-input, linux-kernel, bpf, stable
In-Reply-To: <20240124-b4-hid-bpf-fixes-v2-0-052520b1e5e6@kernel.org>
On Wed, 24 Jan 2024 12:26:56 +0100, Benjamin Tissoires wrote:
> This is the v2 of this series of HID-BPF fixes.
> I have forgotten to include a Fixes tag in the first patch
> and got a review from Andrii on patch 2.
>
> And this first patch made me realize that something was fishy
> in the refcount of the hid devices. I was not crashing the system
> even if I accessed the struct hid_device after hid_destroy_device()
> was called, which was suspicious to say the least. So after some
> debugging I found the culprit and realized that I had a pretty
> nice memleak as soon as one HID-BPF program was attached to a HID
> device.
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-6.8/upstream-fixes), thanks!
[1/3] HID: bpf: remove double fdget()
https://git.kernel.org/hid/hid/c/7cdd2108903a
[2/3] HID: bpf: actually free hdev memory after attaching a HID-BPF program
https://git.kernel.org/hid/hid/c/89be8aa5b0ec
[3/3] HID: bpf: use __bpf_kfunc instead of noinline
https://git.kernel.org/hid/hid/c/764ad6b02777
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
From: Kamel Bouhara @ 2024-01-31 10:33 UTC (permalink / raw)
To: POPESCU Catalin
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Marco Felsch, Jeff LaBundy, mark.satterthwaite@touchnetix.com,
Thomas Petazzoni, Gregory Clement, GEO-CHHER-bsp-development
In-Reply-To: <b466d75c-944f-4c45-80f3-993b1fe40d7a@leica-geosystems.com>
On Tue, Jan 30, 2024 at 05:32:54PM +0000, POPESCU Catalin wrote:
> Hi Kamel,
>
Hi,
> I have a few remarks regarding the population of the usage table
> function, see inline.
>
> On 25.01.24 17:58, Kamel Bouhara wrote:
> > [Some people who received this message don't often get email from kamel.bouhara@bootlin.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.
> >
> >
> > Add a new driver for the TouchNetix's axiom family of
> > touchscreen controllers. This driver only supports i2c
> > and can be later adapted for SPI and USB support.
> >
> > Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
> > ---
> > MAINTAINERS | 1 +
> > drivers/input/touchscreen/Kconfig | 12 +
> > drivers/input/touchscreen/Makefile | 1 +
> > drivers/input/touchscreen/touchnetix_axiom.c | 664 +++++++++++++++++++
> > 4 files changed, 678 insertions(+)
> > create mode 100644 drivers/input/touchscreen/touchnetix_axiom.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 4752d8436dbb..337ddac6c74b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -21436,6 +21436,7 @@ M: Kamel Bouhara <kamel.bouhara@bootlin.com>
> > L: linux-input@vger.kernel.org
> > S: Maintained
> > F: Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
> > +F: drivers/input/touchscreen/touchnetix_axiom.c
> >
> > THUNDERBOLT DMA TRAFFIC TEST DRIVER
> > M: Isaac Hazan <isaac.hazan@intel.com>
> > diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> > index e3e2324547b9..f36bee8d8696 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -803,6 +803,18 @@ config TOUCHSCREEN_MIGOR
> > To compile this driver as a module, choose M here: the
> > module will be called migor_ts.
> >
> > +config TOUCHSCREEN_TOUCHNETIX_AXIOM
> > + tristate "TouchNetix AXIOM based touchscreen controllers"
> > + depends on I2C
> > + help
> > + Say Y here if you have a axiom touchscreen connected to
> > + your system.
> > +
> > + If unsure, say N.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called axiom.
> > +
> > config TOUCHSCREEN_TOUCHRIGHT
> > tristate "Touchright serial touchscreen"
> > select SERIO
> > diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> > index 62bd24f3ac8e..8e32a2df5e18 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -88,6 +88,7 @@ obj-$(CONFIG_TOUCHSCREEN_SUR40) += sur40.o
> > obj-$(CONFIG_TOUCHSCREEN_SURFACE3_SPI) += surface3_spi.o
> > obj-$(CONFIG_TOUCHSCREEN_TI_AM335X_TSC) += ti_am335x_tsc.o
> > obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o
> > +obj-$(CONFIG_TOUCHSCREEN_TOUCHNETIX_AXIOM) += touchnetix_axiom.o
> > obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
> > obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
> > obj-$(CONFIG_TOUCHSCREEN_TS4800) += ts4800-ts.o
> > diff --git a/drivers/input/touchscreen/touchnetix_axiom.c b/drivers/input/touchscreen/touchnetix_axiom.c
> > new file mode 100644
> > index 000000000000..cbb5525b83f5
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/touchnetix_axiom.c
> > @@ -0,0 +1,664 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * TouchNetix axiom Touchscreen Driver
> > + *
> > + * Copyright (C) 2020-2023 TouchNetix Ltd.
> > + *
> > + * Author(s): Bart Prescott <bartp@baasheep.co.uk>
> > + * Pedro Torruella <pedro.torruella@touchnetix.com>
> > + * Mark Satterthwaite <mark.satterthwaite@touchnetix.com>
> > + * Hannah Rossiter <hannah.rossiter@touchnetix.com>
> > + * Kamel Bouhara <kamel.bouhara@bootlin.com>
> > + *
> > + */
> > +#include <linux/bitfield.h>
> > +#include <linux/crc16.h>
> > +#include <linux/delay.h>
> > +#include <linux/device.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/i2c.h>
> > +#include <linux/input.h>
> > +#include <linux/input/mt.h>
> > +#include <linux/input/touchscreen.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/regmap.h>
> > +
> > +#include <asm/unaligned.h>
> > +#define AXIOM_PROX_LEVEL -128
> > +#define AXIOM_DMA_OPS_DELAY_USEC 250
> > +/*
> > + * Register group u31 has 2 pages for usage table entries.
> > + */
> > +#define AXIOM_U31_MAX_USAGES 0xff
> > +#define AXIOM_U31_BYTES_PER_USAGE 6
> > +#define AXIOM_U31_PAGE0_LENGTH 0x0C
> > +#define AXIOM_U31_BOOTMODE_MASK BIT(7)
> > +#define AXIOM_U31_DEVID_MASK GENMASK(14, 0)
> > +
> > +#define AXIOM_MAX_REPORT_LEN 0x7f
> > +
> > +#define AXIOM_CMD_HEADER_READ_MASK BIT(15)
> > +#define AXIOM_U41_MAX_TARGETS 10
> > +
> > +#define AXIOM_U46_AUX_CHANNELS 4
> > +#define AXIOM_U46_AUX_MASK GENMASK(11, 0)
> > +
> > +#define AXIOM_COMMS_MAX_USAGE_PAGES 3
> > +#define AXIOM_COMMS_PAGE_SIZE 256
> > +#define AXIOM_COMMS_REPORT_LEN_MASK GENMASK(6, 0)
> > +
> > +#define AXIOM_REPORT_USAGE_ID 0x34
> > +#define AXIOM_DEVINFO_USAGE_ID 0x31
> > +#define AXIOM_USAGE_2HB_REPORT_ID 0x01
> > +#define AXIOM_USAGE_2AUX_REPORT_ID 0x46
> > +#define AXIOM_USAGE_2DCTS_REPORT_ID 0x41
> > +
> > +#define AXIOM_PAGE_OFFSET_MASK GENMASK(6, 0)
> > +
> > +struct axiom_devinfo {
> > + __le16 device_id;
> > + u8 fw_minor;
> > + u8 fw_major;
> > + u8 fw_info_extra;
> > + u8 tcp_revision;
> > + u8 bootloader_fw_minor;
> > + u8 bootloader_fw_major;
> > + __le16 jedec_id;
> > + u8 num_usages;
> > +} __packed;
> > +
> > +/*
> > + * Describes parameters of a specific usage, essentially a single element of
> > + * the "Usage Table"
> > + */
> > +struct axiom_usage_entry {
> > + u8 id;
> > + u8 is_report;
> > + u8 start_page;
> > + u8 num_pages;
> > +};
> > +
> > +/*
> > + * Represents state of a touch or target when detected prior to a touch (eg.
> > + * hover or proximity events).
> > + */
> > +enum axiom_target_state {
> > + AXIOM_TARGET_STATE_NOT_PRESENT = 0,
> > + AXIOM_TARGET_STATE_PROX = 1,
> > + AXIOM_TARGET_STATE_HOVER = 2,
> > + AXIOM_TARGET_STATE_TOUCHING = 3,
> > +};
> > +
> > +struct axiom_u41_target {
> > + enum axiom_target_state state;
> > + u16 x;
> > + u16 y;
> > + s8 z;
> > + bool insert;
> > + bool touch;
> > +};
> > +
> > +struct axiom_target_report {
> > + u8 index;
> > + u8 present;
> > + u16 x;
> > + u16 y;
> > + s8 z;
> > +};
> > +
> > +struct axiom_cmd_header {
> > + __le16 target_address;
> > + __le16 length;
> > +} __packed;
> > +
> > +struct axiom_data {
> > + struct axiom_devinfo devinfo;
> > + struct device *dev;
> > + struct gpio_desc *reset_gpio;
> > + struct i2c_client *client;
> > + struct input_dev *input_dev;
> > + u32 max_report_len;
> > + u8 rx_buf[AXIOM_COMMS_MAX_USAGE_PAGES * AXIOM_COMMS_PAGE_SIZE];
> > + struct axiom_u41_target targets[AXIOM_U41_MAX_TARGETS];
> > + struct axiom_usage_entry usage_table[AXIOM_U31_MAX_USAGES];
> > + bool usage_table_populated;
> > + struct regulator *vdda;
> > + struct regulator *vddi;
> > + struct regmap *regmap;
> > + struct touchscreen_properties prop;
> > +};
> > +
> > +static const struct regmap_config axiom_i2c_regmap_config = {
> > + .reg_bits = 32,
> > + .reg_format_endian = REGMAP_ENDIAN_LITTLE,
> > + .val_bits = 8,
> > + .val_format_endian = REGMAP_ENDIAN_LITTLE,
> > +};
> > +
> > +/*
> > + * axiom devices are typically configured to report touches at a rate
> > + * of 100Hz (10ms) for systems that require polling for reports.
> > + * When reports are polled, it will be expected to occasionally
> > + * observe the overflow bit being set in the reports.
> > + * This indicates that reports are not being read fast enough.
> > + */
> > +#define POLL_INTERVAL_DEFAULT_MS 10
> > +
> > +/* Translate usage/page/offset triplet into physical address. */
> > +static u16 axiom_usage_to_target_address(struct axiom_data *ts, u8 usage, u8 page,
> > + char offset)
> > +{
> > + /* At the moment the convention is that u31 is always at physical address 0x0 */
> > + if (!ts->usage_table_populated) {
> > + if (usage == AXIOM_DEVINFO_USAGE_ID)
> > + return ((page << 8) + offset);
> > + else
> > + return 0xffff;
> > + }
> > +
> > + if (page >= ts->usage_table[usage].num_pages) {
> > + dev_err(ts->dev, "Invalid usage table! usage: u%02x, page: %02x, offset: %02x\n",
> > + usage, page, offset);
> > + return 0xffff;
> > + }
> > +
> > + return ((ts->usage_table[usage].start_page + page) << 8) + offset;
> > +}
> > +
> > +static int axiom_read(struct axiom_data *ts, u8 usage, u8 page, void *buf, u16 len)
> > +{
> > + struct axiom_cmd_header cmd_header;
> > + int ret;
> > +
> > + cmd_header.target_address = cpu_to_le16(axiom_usage_to_target_address(ts, usage, page, 0));
> > + cmd_header.length = cpu_to_le16(len | AXIOM_CMD_HEADER_READ_MASK);
> > +
> > + __le32 preamble = get_unaligned_le32((u8 *)&cmd_header);
> > +
> > + ret = regmap_write(ts->regmap, preamble, 0);
> > + if (ret) {
> > + dev_err(ts->dev, "failed to write preamble, error %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = regmap_raw_read(ts->regmap, 0, buf, len);
> > + if (ret) {
> > + dev_err(ts->dev, "failed to read target address %04x, error %d\n",
> > + cmd_header.target_address, ret);
> > + return ret;
> > + }
> > +
> > + /* Wait device's DMA operations */
> > + usleep_range(AXIOM_DMA_OPS_DELAY_USEC, AXIOM_DMA_OPS_DELAY_USEC + 50);
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * One of the main purposes for reading the usage table is to identify
> > + * which usages reside at which target address.
> > + * When performing subsequent reads or writes to AXIOM, the target address
> > + * is used to specify which usage is being accessed.
> > + * Consider the following discovery code which will build up the usage table.
> > + */
> > +static u32 axiom_populate_usage_table(struct axiom_data *ts)
> > +{
> > + struct axiom_usage_entry *usage_table;
> > + u8 *rx_data = ts->rx_buf;
> > + u32 max_report_len;
> please force initialization of max_report_len to 0.
Fixed, thanks !
> > + u32 usage_id;
> > + int error;
> > +
> > + usage_table = ts->usage_table;
> > +
> > + /* Read the second page of usage u31 to get the usage table */
> > + error = axiom_read(ts, AXIOM_DEVINFO_USAGE_ID, 1, rx_data,
> > + (AXIOM_U31_BYTES_PER_USAGE * ts->devinfo.num_usages));
> > +
> > + if (error)
> > + return error;
> > +
> > + for (usage_id = 1; usage_id < AXIOM_U31_MAX_USAGES; usage_id++) {
>
> usage_id should start at 0, since it's used to compute the offset in the
> page 1 of u31.
> if you start with usage_id=1, then whatever is the 1st usage of the
> usage table gets jumped out...
You're right, first usage id is u01, I think that's what induced my
mistake here.
> also, you should stop the loop at num_usages, otherwise you're going to
> read garbage after the end of rx_data buffer...
> this garbage would end up in wrong computation of max_report_len then in
> failure of reading any touch report.
>
Reading num_usages is indeed a more clever choice here, thanks again !
> > + u16 offset = (usage_id * AXIOM_U31_BYTES_PER_USAGE);
> > + u8 id = rx_data[offset + 0];
> > + u8 start_page = rx_data[offset + 1];
> > + u8 num_pages = rx_data[offset + 2];
> > + u32 max_offset = ((rx_data[offset + 3] & AXIOM_PAGE_OFFSET_MASK) + 1) * 2;
> > +
> > + if (!num_pages)
> > + usage_table[id].is_report = true;
> please add an else statement to set is_report to false.
Fixed in v7, thanks.
> > +
> > + /* Store the entry into the usage table */
> > + usage_table[id].id = id;
> > + usage_table[id].start_page = start_page;
> > + usage_table[id].num_pages = num_pages;
> > +
> > + dev_dbg(ts->dev, "Usage u%02x Info: %*ph\n", id, AXIOM_U31_BYTES_PER_USAGE,
> > + &rx_data[offset]);
> > +
> > + /* Identify the max report length the module will receive */
> > + if (usage_table[id].is_report && max_offset > max_report_len)
> > + max_report_len = max_offset;
> > + }
> > +
> > + ts->usage_table_populated = true;
> > +
> > + return max_report_len;
> > +}
> > +
> > +static int axiom_discover(struct axiom_data *ts)
> > +{
> > + int error;
> > +
> > + /*
> > + * Fetch the first page of usage u31 to get the
> > + * device information and the number of usages
> > + */
> > + error = axiom_read(ts, AXIOM_DEVINFO_USAGE_ID, 0, &ts->devinfo, AXIOM_U31_PAGE0_LENGTH);
> > + if (error)
> > + return error;
> > +
> > + dev_dbg(ts->dev, " Boot Mode : %s\n",
> > + FIELD_GET(AXIOM_U31_BOOTMODE_MASK,
> > + le16_to_cpu(ts->devinfo.device_id)) ? "BLP" : "TCP");
> > + dev_dbg(ts->dev, " Device ID : %04lx\n",
> > + FIELD_GET(AXIOM_U31_DEVID_MASK, le16_to_cpu(ts->devinfo.device_id)));
> > + dev_dbg(ts->dev, " Firmware Rev : %02x.%02x\n", ts->devinfo.fw_major,
> > + ts->devinfo.fw_minor);
> > + dev_dbg(ts->dev, " Bootloader Rev : %02x.%02x\n", ts->devinfo.bootloader_fw_major,
> > + ts->devinfo.bootloader_fw_minor);
> > + dev_dbg(ts->dev, " FW Extra Info : %04x\n", ts->devinfo.fw_info_extra);
> > + dev_dbg(ts->dev, " Silicon : %04x\n", le16_to_cpu(ts->devinfo.jedec_id));
> > + dev_dbg(ts->dev, " Number usages : %04x\n", ts->devinfo.num_usages);
> > +
> > + ts->max_report_len = axiom_populate_usage_table(ts);
> > + if (!ts->max_report_len || !ts->devinfo.num_usages ||
> > + ts->max_report_len > AXIOM_MAX_REPORT_LEN) {
> > + dev_err(ts->dev, "Invalid report length or usages number");
> > + return -EINVAL;
> > + }
> > +
> > + dev_dbg(ts->dev, "Max Report Length: %u\n", ts->max_report_len);
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Support function to axiom_process_u41_report.
> > + * Generates input-subsystem events for every target.
> > + * After calling this function the caller shall issue
> > + * a Sync to the input sub-system.
> > + */
> > +static bool axiom_process_u41_report_target(struct axiom_data *ts,
> > + struct axiom_target_report *target)
> > +{
> > + struct input_dev *input_dev = ts->input_dev;
> > + struct axiom_u41_target *target_prev_state;
> > + enum axiom_target_state current_state;
> > + int slot;
> > +
> > + /* Verify the target index */
> > + if (target->index >= AXIOM_U41_MAX_TARGETS) {
> > + dev_err(ts->dev, "Invalid target index! %u\n", target->index);
> > + return false;
> > + }
> > +
> > + target_prev_state = &ts->targets[target->index];
> > +
> > + current_state = AXIOM_TARGET_STATE_NOT_PRESENT;
> > +
> > + if (target->present) {
> > + if (target->z >= 0)
> > + current_state = AXIOM_TARGET_STATE_TOUCHING;
> > + else if (target->z > AXIOM_PROX_LEVEL && target->z < 0)
> > + current_state = AXIOM_TARGET_STATE_HOVER;
> > + else if (target->z == AXIOM_PROX_LEVEL)
> > + current_state = AXIOM_TARGET_STATE_PROX;
> > + }
> > +
> > + if (target_prev_state->state == current_state &&
> > + target_prev_state->x == target->x &&
> > + target_prev_state->y == target->y &&
> > + target_prev_state->z == target->z)
> > + return false;
> > +
> > + slot = target->index;
> > +
> > + dev_dbg(ts->dev, "U41 Target T%u, slot:%u present:%u, x:%u, y:%u, z:%d\n",
> > + target->index, slot, target->present,
> > + target->x, target->y, target->z);
> > +
> > + switch (current_state) {
> > + case AXIOM_TARGET_STATE_NOT_PRESENT:
> > + case AXIOM_TARGET_STATE_PROX:
> > + if (!target_prev_state->insert)
> > + break;
> > + target_prev_state->insert = false;
> > + input_mt_slot(input_dev, slot);
> > +
> > + if (!slot)
> > + input_report_key(input_dev, BTN_TOUCH, 0);
> > +
> > + input_mt_report_slot_inactive(input_dev);
> > + /*
> > + * make sure the previous coordinates are
> > + * all off screen when the finger comes back
> > + */
> > + target->x = 65535;
> > + target->y = 65535;
> > + target->z = AXIOM_PROX_LEVEL;
> > + break;
> > + case AXIOM_TARGET_STATE_HOVER:
> > + case AXIOM_TARGET_STATE_TOUCHING:
> > + target_prev_state->insert = true;
> > + input_mt_slot(input_dev, slot);
> > + input_report_abs(input_dev, ABS_MT_TRACKING_ID, slot);
> > + input_report_abs(input_dev, ABS_MT_POSITION_X, target->x);
> > + input_report_abs(input_dev, ABS_MT_POSITION_Y, target->y);
> > +
> > + if (current_state == AXIOM_TARGET_STATE_TOUCHING) {
> > + input_report_abs(input_dev, ABS_MT_DISTANCE, 0);
> > + input_report_abs(input_dev, ABS_DISTANCE, 0);
> > + input_report_abs(input_dev, ABS_MT_PRESSURE, target->z);
> > + input_report_abs(input_dev, ABS_PRESSURE, target->z);
> > + } else {
> > + input_report_abs(input_dev, ABS_MT_DISTANCE, -target->z);
> > + input_report_abs(input_dev, ABS_DISTANCE, -target->z);
> > + input_report_abs(input_dev, ABS_MT_PRESSURE, 0);
> > + input_report_abs(input_dev, ABS_PRESSURE, 0);
> > + }
> > +
> > + if (!slot)
> > + input_report_key(input_dev, BTN_TOUCH, (current_state ==
> > + AXIOM_TARGET_STATE_TOUCHING));
> > + break;
> > + default:
> > + break;
> > + }
> > +
> > + target_prev_state->state = current_state;
> > + target_prev_state->x = target->x;
> > + target_prev_state->y = target->y;
> > + target_prev_state->z = target->z;
> > +
> > + return true;
> > +}
> > +
> > +/*
> > + * U41 is the output report of the 2D CTS and contains the status of targets
> > + * (including contacts and pre-contacts) along with their X,Y,Z values.
> > + * When a target has been removed (no longer detected),
> > + * the corresponding X,Y,Z values will be zeroed.
> > + */
> > +static bool axiom_process_u41_report(struct axiom_data *ts, u8 *rx_buf)
> > +{
> > + struct axiom_target_report target;
> > + bool update_done = false;
> > + u16 target_status;
> > + int i;
> > +
> > + target_status = get_unaligned_le16(rx_buf + 1);
> > +
> > + for (i = 0; i < AXIOM_U41_MAX_TARGETS; i++) {
> > + u8 *target_step = &rx_buf[i * 4];
> > +
> > + target.index = i;
> > + target.present = ((target_status & (1 << i)) != 0) ? 1 : 0;
> > + target.x = get_unaligned_le16(target_step + 3);
> > + target.y = get_unaligned_le16(target_step + 5);
> > + target.z = (s8)(rx_buf[i + 43]);
> > + update_done |= axiom_process_u41_report_target(ts, &target);
> > + }
> > +
> > + return update_done;
> > +}
> > +
> > +/*
> > + * U46 report contains a low level measurement data generated by the capacitive
> > + * displacement sensor (CDS) algorithms from the auxiliary channels.
> > + * This information is useful when tuning multi-press to assess mechanical
> > + * consistency in the unit's construction.
> > + */
> > +static void axiom_process_u46_report(struct axiom_data *ts, u8 *rx_buf)
> > +{
> > + struct input_dev *input_dev = ts->input_dev;
> > + u32 event_value;
> > + u16 aux_value;
> > + int i;
> > +
> > + for (i = 0; i < AXIOM_U46_AUX_CHANNELS; i++) {
> > + u8 *target_step = &rx_buf[i * 2];
> > +
> > + aux_value = get_unaligned_le16(target_step + 1) & AXIOM_U46_AUX_MASK;
> > + event_value = (i << 16) | (aux_value);
> > + input_event(input_dev, EV_MSC, MSC_RAW, event_value);
> > + }
> > +}
> > +
> > +/*
> > + * Validates the crc and demultiplexes the axiom reports to the appropriate
> > + * report handler
> > + */
> > +static int axiom_handle_events(struct axiom_data *ts)
> > +{
> > + struct input_dev *input_dev = ts->input_dev;
> > + u8 *report_data = ts->rx_buf;
> > + struct device *dev = ts->dev;
> > + u16 crc_report;
> > + u16 crc_calc;
> > + int error;
> > + u8 len;
> > +
> > + error = axiom_read(ts, AXIOM_REPORT_USAGE_ID, 0, report_data, ts->max_report_len);
> > + if (error)
> > + return error;
> > +
> > + len = (report_data[0] & AXIOM_COMMS_REPORT_LEN_MASK) << 1;
> > + if (len <= 2) {
> > + dev_err(dev, "Zero length report discarded.\n");
> > + return -ENODATA;
> > + }
> > +
> > + /* Validate the report CRC */
> > + u8 *crc_bytes = &report_data[len];
> > +
> > + crc_report = get_unaligned_le16(crc_bytes - 2);
> > + /* Length is in 16 bit words and remove the size of the CRC16 itself */
> > + crc_calc = crc16(0, report_data, (len - 2));
> > +
> > + if (crc_calc != crc_report) {
> > + dev_err(dev,
> > + "CRC mismatch! Expected: %#x, Calculated CRC: %#x.\n",
> > + crc_report, crc_calc);
> > + return -EINVAL;
> > + }
> > +
> > + switch (report_data[1]) {
> > + case AXIOM_USAGE_2DCTS_REPORT_ID:
> > + if (axiom_process_u41_report(ts, &report_data[1])) {
> > + input_mt_sync_frame(input_dev);
> > + input_sync(input_dev);
> > + }
> > + break;
> > +
> > + case AXIOM_USAGE_2AUX_REPORT_ID:
> > + /* This is an aux report (force) */
> > + axiom_process_u46_report(ts, &report_data[1]);
> > + input_mt_sync(input_dev);
> > + input_sync(input_dev);
> > + break;
> > +
> > + case AXIOM_USAGE_2HB_REPORT_ID:
> > + /* This is a heartbeat report */
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void axiom_i2c_poll(struct input_dev *input_dev)
> > +{
> > + struct axiom_data *ts = input_get_drvdata(input_dev);
> > +
> > + axiom_handle_events(ts);
> > +}
> > +
> > +static irqreturn_t axiom_irq(int irq, void *dev_id)
> > +{
> > + struct axiom_data *ts = dev_id;
> > +
> > + axiom_handle_events(ts);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static void axiom_reset(struct gpio_desc *reset_gpio)
> > +{
> > + gpiod_set_value_cansleep(reset_gpio, 1);
> > + usleep_range(1000, 2000);
> > + gpiod_set_value_cansleep(reset_gpio, 0);
> > + msleep(110);
> > +}
> > +
> > +static int axiom_i2c_probe(struct i2c_client *client)
> > +{
> > + u32 poll_interval = POLL_INTERVAL_DEFAULT_MS;
> > + struct device *dev = &client->dev;
> > + struct input_dev *input_dev;
> > + struct axiom_data *ts;
> > + u32 startup_delay_ms;
> > + int target;
> > + int error;
> > +
> > + ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
> > + if (!ts)
> > + return -ENOMEM;
> > +
> > + i2c_set_clientdata(client, ts);
> > + ts->client = client;
> > + ts->dev = dev;
> > +
> > + ts->regmap = devm_regmap_init_i2c(client, &axiom_i2c_regmap_config);
> > + error = PTR_ERR_OR_ZERO(ts->regmap);
> > + if (error) {
> > + dev_err(dev, "Failed to initialize regmap: %d\n", error);
> > + return error;
> > + }
> > +
> > + ts->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> > + if (IS_ERR(ts->reset_gpio))
> > + return dev_err_probe(dev, PTR_ERR(ts->reset_gpio), "failed to get reset GPIO\n");
> > +
> > + if (ts->reset_gpio)
> > + axiom_reset(ts->reset_gpio);
> > +
> > + ts->vddi = devm_regulator_get_optional(dev, "vddi");
> > + if (!IS_ERR(ts->vddi)) {
> > + error = devm_regulator_get_enable(dev, "vddi");
> > + if (error)
> > + return dev_err_probe(&client->dev, error,
> > + "Failed to enable vddi regulator\n");
> > + }
> > +
> > + ts->vdda = devm_regulator_get_optional(dev, "vdda");
> > + if (!IS_ERR(ts->vdda)) {
> > + error = devm_regulator_get_enable(dev, "vdda");
> > + if (error)
> > + return dev_err_probe(&client->dev, error,
> > + "Failed to enable vdda regulator\n");
> > + if (!device_property_read_u32(dev, "startup-time-ms", &startup_delay_ms))
> > + msleep(startup_delay_ms);
> > + }
> > +
> > + error = axiom_discover(ts);
> > + if (error)
> > + return dev_err_probe(dev, error, "Failed touchscreen discover\n");
> > +
> > + input_dev = devm_input_allocate_device(ts->dev);
> > + if (!input_dev)
> > + return -ENOMEM;
> > +
> > + input_dev->name = "TouchNetix axiom Touchscreen";
> > + input_dev->phys = "input/axiom_ts";
> > +
> > + input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, 65535, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, 65535, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_TOOL_TYPE, 0, MT_TOOL_MAX, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_DISTANCE, 0, 127, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, 127, 0, 0);
> > +
> > + touchscreen_parse_properties(input_dev, true, &ts->prop);
> > +
> > + /* Registers the axiom device as a touchscreen instead of a mouse pointer */
> > + error = input_mt_init_slots(input_dev, AXIOM_U41_MAX_TARGETS, INPUT_MT_DIRECT);
> > + if (error)
> > + return error;
> > +
> > + /* Enables the raw data for up to 4 force channels to be sent to the input subsystem */
> > + set_bit(EV_REL, input_dev->evbit);
> > + set_bit(EV_MSC, input_dev->evbit);
> > + /* Declare that we support "RAW" Miscellaneous events */
> > + set_bit(MSC_RAW, input_dev->mscbit);
> > +
> > + ts->input_dev = input_dev;
> > + input_set_drvdata(ts->input_dev, ts);
> > +
> > + /* Ensure that all reports are initialised to not be present. */
> > + for (target = 0; target < AXIOM_U41_MAX_TARGETS; target++)
> > + ts->targets[target].state = AXIOM_TARGET_STATE_NOT_PRESENT;
> > +
> > + error = input_register_device(input_dev);
> > + if (error)
> > + return dev_err_probe(ts->dev, error,
> > + "Could not register with Input Sub-system.\n");
> > +
> > + error = devm_request_threaded_irq(dev, client->irq, NULL,
> > + axiom_irq, IRQF_ONESHOT, dev_name(dev), ts);
> > + if (error) {
> > + dev_info(dev, "Request irq failed, falling back to polling mode");
> > +
> > + error = input_setup_polling(input_dev, axiom_i2c_poll);
> > + if (error)
> > + return dev_err_probe(ts->dev, error, "Unable to set up polling mode\n");
> > +
> > + if (!device_property_read_u32(ts->dev, "poll-interval", &poll_interval))
> > + input_set_poll_interval(input_dev, poll_interval);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static const struct i2c_device_id axiom_i2c_id_table[] = {
> > + { "ax54a" },
> > + { },
> > +};
> > +MODULE_DEVICE_TABLE(i2c, axiom_i2c_id_table);
> > +
> > +static const struct of_device_id axiom_i2c_of_match[] = {
> > + { .compatible = "touchnetix,ax54a", },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, axiom_i2c_of_match);
> > +
> > +static struct i2c_driver axiom_i2c_driver = {
> > + .driver = {
> > + .name = "axiom",
> > + .of_match_table = axiom_i2c_of_match,
> > + },
> > + .id_table = axiom_i2c_id_table,
> > + .probe = axiom_i2c_probe,
> > +};
> > +module_i2c_driver(axiom_i2c_driver);
> > +
> > +MODULE_AUTHOR("Bart Prescott <bartp@baasheep.co.uk>");
> > +MODULE_AUTHOR("Pedro Torruella <pedro.torruella@touchnetix.com>");
> > +MODULE_AUTHOR("Mark Satterthwaite <mark.satterthwaite@touchnetix.com>");
> > +MODULE_AUTHOR("Hannah Rossiter <hannah.rossiter@touchnetix.com>");
> > +MODULE_AUTHOR("Kamel Bouhara <kamel.bouhara@bootlin.com>");
> > +MODULE_DESCRIPTION("TouchNetix axiom touchscreen I2C bus driver");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.25.1
> >
>
--
Kamel Bouhara, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v6 RESEND 6/6] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
From: Biju Das @ 2024-01-31 10:26 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones
Cc: Biju Das, Support Opensource, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Steve Twiss, linux-input, devicetree,
linux-pm, Geert Uytterhoeven, Prabhakar Mahadev Lad, Biju Das,
linux-renesas-soc, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20240131102656.3379-1-biju.das.jz@bp.renesas.com>
Convert the da9062 PMIC device tree binding documentation to json-schema.
Document the missing gpio child node for da9062.
While at it, update description with link to product information and
example.
The missing child node with of_compatible defined in MFD_CELL_OF is
causing the below warning message:
da9062-gpio: Failed to locate of_node [id: -1]
So, make all child nodes with of_compatible defined in struct mfd_cell
as required property for da906{1,2} devices.
The "gpio-controller" and "#gpio-cells" properties are defined in the
parent instead of gpio child node as there are existing driver users
based on these parent properties.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Lee Jones <lee@kernel.org>
---
v6->v6 Resend:
* Added Rb tag from Conor Dooley and Ack from Lee Jones.
v5->v6:
* Updated commit description related to "gpio-controller" and
"#gpio-cells" properties defined in parent node.
* Added Rb tag Krzysztof Kozlowski.
v4->v5:
* Updated commit description
* Dropped unnecessary ref from gpio child node.
* Added gpio-hog pattern property
* Moved gpio-controller,gpio-cells above child nodes
* Sorted compatible in rtc child node.
* Dropped status from example.
* Updated the example.
v3->v4:
* Split the thermal binding patch separate.
* Updated the description.
v2->v3:
* Fixed bot errors related to MAINTAINERS entry, invalid doc
references and thermal examples by merging patch#4.
v2:
* New patch
---
.../bindings/input/dlg,da9062-onkey.yaml | 3 +-
.../devicetree/bindings/mfd/da9062.txt | 124 ----------
.../devicetree/bindings/mfd/dlg,da9063.yaml | 215 +++++++++++++++++-
.../bindings/thermal/dlg,da9062-thermal.yaml | 2 +-
4 files changed, 212 insertions(+), 132 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mfd/da9062.txt
diff --git a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
index 757a522c102c..1480d95421e1 100644
--- a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
+++ b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
@@ -11,8 +11,7 @@ maintainers:
description: |
This module is part of the DA9061/DA9062/DA9063. For more details about entire
- DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
- For DA9063 see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
+ DA906{1,2,3} chips see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
This module provides the KEY_POWER event.
diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt
deleted file mode 100644
index c8a7f119ac84..000000000000
--- a/Documentation/devicetree/bindings/mfd/da9062.txt
+++ /dev/null
@@ -1,124 +0,0 @@
-* Dialog DA9062 Power Management Integrated Circuit (PMIC)
-
-Product information for the DA9062 and DA9061 devices can be found here:
-- https://www.dialog-semiconductor.com/products/da9062
-- https://www.dialog-semiconductor.com/products/da9061
-
-The DA9062 PMIC consists of:
-
-Device Supply Names Description
------- ------------ -----------
-da9062-regulator : : LDOs & BUCKs
-da9062-rtc : : Real-Time Clock
-da9062-onkey : : On Key
-da9062-watchdog : : Watchdog Timer
-da9062-thermal : : Thermal
-da9062-gpio : : GPIOs
-
-The DA9061 PMIC consists of:
-
-Device Supply Names Description
------- ------------ -----------
-da9062-regulator : : LDOs & BUCKs
-da9062-onkey : : On Key
-da9062-watchdog : : Watchdog Timer
-da9062-thermal : : Thermal
-
-======
-
-Required properties:
-
-- compatible : Should be
- "dlg,da9062" for DA9062
- "dlg,da9061" for DA9061
-- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
- modified to match the chip's OTP settings).
-
-Optional properties:
-
-- gpio-controller : Marks the device as a gpio controller.
-- #gpio-cells : Should be two. The first cell is the pin number and the
- second cell is used to specify the gpio polarity.
-
-See Documentation/devicetree/bindings/gpio/gpio.txt for further information on
-GPIO bindings.
-
-- interrupts : IRQ line information.
-- interrupt-controller
-
-See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
-further information on IRQ bindings.
-
-Sub-nodes:
-
-- regulators : This node defines the settings for the LDOs and BUCKs.
- The DA9062 regulators are bound using their names listed below:
-
- buck1 : BUCK_1
- buck2 : BUCK_2
- buck3 : BUCK_3
- buck4 : BUCK_4
- ldo1 : LDO_1
- ldo2 : LDO_2
- ldo3 : LDO_3
- ldo4 : LDO_4
-
- The DA9061 regulators are bound using their names listed below:
-
- buck1 : BUCK_1
- buck2 : BUCK_2
- buck3 : BUCK_3
- ldo1 : LDO_1
- ldo2 : LDO_2
- ldo3 : LDO_3
- ldo4 : LDO_4
-
- The component follows the standard regulator framework and the bindings
- details of individual regulator device can be found in:
- Documentation/devicetree/bindings/regulator/regulator.txt
-
- regulator-initial-mode may be specified for buck regulators using mode values
- from include/dt-bindings/regulator/dlg,da9063-regulator.h.
-
-- rtc : This node defines settings required for the Real-Time Clock associated
- with the DA9062. There are currently no entries in this binding, however
- compatible = "dlg,da9062-rtc" should be added if a node is created.
-
-- onkey : See ../input/dlg,da9062-onkey.yaml
-
-- watchdog: See ../watchdog/dlg,da9062-watchdog.yaml
-
-- thermal : See ../thermal/dlg,da9062-thermal.yaml
-
-Example:
-
- pmic0: da9062@58 {
- compatible = "dlg,da9062";
- reg = <0x58>;
- interrupt-parent = <&gpio6>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
- interrupt-controller;
-
- rtc {
- compatible = "dlg,da9062-rtc";
- };
-
- regulators {
- DA9062_BUCK1: buck1 {
- regulator-name = "BUCK1";
- regulator-min-microvolt = <300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <500000>;
- regulator-max-microamp = <2000000>;
- regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
- regulator-boot-on;
- };
- DA9062_LDO1: ldo1 {
- regulator-name = "LDO_1";
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <3600000>;
- regulator-boot-on;
- };
- };
- };
-
diff --git a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
index 676b4f2566ae..da741c999445 100644
--- a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
+++ b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/dlg,da9063.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Dialog DA9063/DA9063L Power Management Integrated Circuit (PMIC)
+title: Dialog DA906{3L,3,2,1} Power Management Integrated Circuit (PMIC)
maintainers:
- Steve Twiss <stwiss.opensource@diasemi.com>
@@ -17,10 +17,17 @@ description: |
moment where all voltage monitors are disabled. Next, as da9063 only supports
UV *and* OV monitoring, both must be set to the same severity and value
(0: disable, 1: enable).
+ Product information for the DA906{3L,3,2,1} devices can be found here:
+ - https://www.dialog-semiconductor.com/products/da9063l
+ - https://www.dialog-semiconductor.com/products/da9063
+ - https://www.dialog-semiconductor.com/products/da9062
+ - https://www.dialog-semiconductor.com/products/da9061
properties:
compatible:
enum:
+ - dlg,da9061
+ - dlg,da9062
- dlg,da9063
- dlg,da9063l
@@ -35,6 +42,18 @@ properties:
"#interrupt-cells":
const: 2
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio:
+ type: object
+ additionalProperties: false
+ properties:
+ compatible:
+ const: dlg,da9062-gpio
+
onkey:
$ref: /schemas/input/dlg,da9062-onkey.yaml
@@ -42,7 +61,7 @@ properties:
type: object
additionalProperties: false
patternProperties:
- "^(ldo([1-9]|1[01])|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged)$":
+ "^(ldo([1-9]|1[01])|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged|buck[1-4])$":
$ref: /schemas/regulator/regulator.yaml
unevaluatedProperties: false
@@ -52,16 +71,85 @@ properties:
unevaluatedProperties: false
properties:
compatible:
- const: dlg,da9063-rtc
+ enum:
+ - dlg,da9062-rtc
+ - dlg,da9063-rtc
+
+ thermal:
+ $ref: /schemas/thermal/dlg,da9062-thermal.yaml
watchdog:
$ref: /schemas/watchdog/dlg,da9062-watchdog.yaml
+patternProperties:
+ "^(.+-hog(-[0-9]+)?)$":
+ type: object
+
+ required:
+ - gpio-hog
+
required:
- compatible
- reg
- - interrupts
- - interrupt-controller
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - dlg,da9063
+ - dlg,da9063l
+ then:
+ properties:
+ gpio-controller: false
+ "#gpio-cells": false
+ gpio: false
+ regulators:
+ patternProperties:
+ "^buck[1-4]$": false
+ thermal: false
+ required:
+ - interrupts
+ - interrupt-controller
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - dlg,da9062
+ then:
+ properties:
+ regulators:
+ patternProperties:
+ "^(ldo([5-9]|10|11)|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged)$": false
+ required:
+ - gpio
+ - onkey
+ - rtc
+ - thermal
+ - watchdog
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - dlg,da9061
+ then:
+ properties:
+ gpio-controller: false
+ "#gpio-cells": false
+ gpio: false
+ regulators:
+ patternProperties:
+ "^(ldo([5-9]|10|11)|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged|buck4)$": false
+ rtc: false
+ required:
+ - onkey
+ - thermal
+ - watchdog
additionalProperties: false
@@ -118,4 +206,121 @@ examples:
};
};
};
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/regulator/dlg,da9063-regulator.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic@58 {
+ compatible = "dlg,da9062";
+ reg = <0x58>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ sd0-pwr-sel-hog {
+ gpio-hog;
+ gpios = <1 0>;
+ input;
+ line-name = "SD0_PWR_SEL";
+ };
+
+ sd1-pwr-sel-hog {
+ gpio-hog;
+ gpios = <2 0>;
+ input;
+ line-name = "SD1_PWR_SEL";
+ };
+
+ sw-et0-en-hog {
+ gpio-hog;
+ gpios = <3 0>;
+ input;
+ line-name = "SW_ET0_EN#";
+ };
+
+ pmic-good-hog {
+ gpio-hog;
+ gpios = <4 0>;
+ output-high;
+ line-name = "PMIC_PGOOD";
+ };
+
+ gpio {
+ compatible = "dlg,da9062-gpio";
+ };
+
+ onkey {
+ compatible = "dlg,da9062-onkey";
+ };
+
+ regulators {
+ buck1 {
+ regulator-name = "vdd_arm";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ buck2 {
+ regulator-name = "vdd_soc";
+ regulator-min-microvolt = <1150000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ buck3 {
+ regulator-name = "vdd_ddr3";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ buck4 {
+ regulator-name = "vdd_eth";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ ldo1 {
+ regulator-name = "vdd_snvs";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+ ldo2 {
+ regulator-name = "vdd_high";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+ ldo3 {
+ regulator-name = "vdd_eth_io";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+ ldo4 {
+ regulator-name = "vdd_emmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+ };
+
+ rtc {
+ compatible = "dlg,da9062-rtc";
+ };
+
+ thermal {
+ compatible = "dlg,da9062-thermal";
+ };
+
+ watchdog {
+ compatible = "dlg,da9062-watchdog";
+ dlg,use-sw-pm;
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml b/Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml
index 206635f74850..e8b2cac41084 100644
--- a/Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml
@@ -11,7 +11,7 @@ maintainers:
description: |
This module is part of the DA9061/DA9062. For more details about entire
- DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
+ DA906{1,2} chips see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
Junction temperature thermal module uses an interrupt signal to identify
high THERMAL_TRIP_HOT temperatures for the PMIC device.
--
2.39.2
^ permalink raw reply related
* [PATCH v6 RESEND 3/6] dt-bindings: input: Convert da906{1,2,3} onkey to json-schema
From: Biju Das @ 2024-01-31 10:26 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Biju Das, Support Opensource, linux-input, devicetree,
Geert Uytterhoeven, Prabhakar Mahadev Lad, Biju Das,
linux-renesas-soc, Conor Dooley, Krzysztof Kozlowski, Lee Jones
In-Reply-To: <20240131102656.3379-1-biju.das.jz@bp.renesas.com>
Convert the da906{1,2,3} onkey device tree binding documentation to
json-schema.
Update MAINTAINERS entries, description and onkey property by
referring to dlg,da9062-onkey binding file.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Lee Jones <lee@kernel.org>
---
v6->v6 resend:
* Added Ack from Lee Jones.
v5->v6:
* No change.
v4->v5:
* Added Rb tag from Krzysztof and Conor
* Dropped Items, Just enum as it is easier to read compatibles.
* Retained tags as the changes are trivial.
v3->v4:
* Squashed with patch#6 and patch#9 from v2.
* Replaced enum->const for dlg,da9061-onkey and its fallback.
* Dropped example
v2->v3:
* Updated MAINTAINERS entries.
v2:
* New patch
---
.../bindings/input/da9062-onkey.txt | 47 -------------------
.../bindings/input/dlg,da9062-onkey.yaml | 39 +++++++++++++++
.../devicetree/bindings/mfd/da9062.txt | 2 +-
.../devicetree/bindings/mfd/dlg,da9063.yaml | 15 +-----
MAINTAINERS | 2 +-
5 files changed, 42 insertions(+), 63 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt
create mode 100644 Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt b/Documentation/devicetree/bindings/input/da9062-onkey.txt
deleted file mode 100644
index e5eef59a93dc..000000000000
--- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Dialog DA9061/62/63 OnKey Module
-
-This module is part of the DA9061/DA9062/DA9063. For more details about entire
-DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
-For DA9063 see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
-
-This module provides the KEY_POWER event.
-
-Required properties:
-
-- compatible: should be one of the following valid compatible string lines:
- "dlg,da9061-onkey", "dlg,da9062-onkey"
- "dlg,da9062-onkey"
- "dlg,da9063-onkey"
-
-Optional properties:
-
-- dlg,disable-key-power : Disable power-down using a long key-press. If this
- entry exists the OnKey driver will remove support for the KEY_POWER key
- press when triggered using a long press of the OnKey.
-
-Example: DA9063
-
- pmic0: da9063@58 {
- onkey {
- compatible = "dlg,da9063-onkey";
- dlg,disable-key-power;
- };
- };
-
-Example: DA9062
-
- pmic0: da9062@58 {
- onkey {
- compatible = "dlg,da9062-onkey";
- dlg,disable-key-power;
- };
- };
-
-Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
-
- pmic0: da9061@58 {
- onkey {
- compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";
- dlg,disable-key-power;
- };
- };
diff --git a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
new file mode 100644
index 000000000000..757a522c102c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/dlg,da9062-onkey.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog DA9061/62/63 OnKey Module
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ This module is part of the DA9061/DA9062/DA9063. For more details about entire
+ DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
+ For DA9063 see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
+
+ This module provides the KEY_POWER event.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - dlg,da9062-onkey
+ - dlg,da9063-onkey
+ - items:
+ - const: dlg,da9061-onkey
+ - const: dlg,da9062-onkey
+
+ dlg,disable-key-power:
+ type: boolean
+ description:
+ Disable power-down using a long key-press. If this entry exists
+ the OnKey driver will remove support for the KEY_POWER key press
+ when triggered using a long press of the OnKey.
+
+required:
+ - compatible
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt
index 18463b7fbb42..154c31fa4443 100644
--- a/Documentation/devicetree/bindings/mfd/da9062.txt
+++ b/Documentation/devicetree/bindings/mfd/da9062.txt
@@ -84,7 +84,7 @@ Sub-nodes:
with the DA9062. There are currently no entries in this binding, however
compatible = "dlg,da9062-rtc" should be added if a node is created.
-- onkey : See ../input/da9062-onkey.txt
+- onkey : See ../input/dlg,da9062-onkey.yaml
- watchdog: See ../watchdog/dlg,da9062-watchdog.yaml
diff --git a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
index ce81e0b029cc..1e5a847a6be2 100644
--- a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
+++ b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
@@ -44,20 +44,7 @@ properties:
const: dlg,da9063-rtc
onkey:
- type: object
- $ref: /schemas/input/input.yaml#
- unevaluatedProperties: false
- properties:
- compatible:
- const: dlg,da9063-onkey
-
- dlg,disable-key-power:
- type: boolean
- description: |
- Disable power-down using a long key-press.
- If this entry does not exist then by default the key-press triggered
- power down is enabled and the OnKey will support both KEY_POWER and
- KEY_SLEEP.
+ $ref: /schemas/input/dlg,da9062-onkey.yaml
regulators:
type: object
diff --git a/MAINTAINERS b/MAINTAINERS
index e0091af90973..2aab4f5d634a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6163,8 +6163,8 @@ DIALOG SEMICONDUCTOR DRIVERS
M: Support Opensource <support.opensource@diasemi.com>
S: Supported
W: http://www.dialog-semiconductor.com/products
-F: Documentation/devicetree/bindings/input/da90??-onkey.txt
F: Documentation/devicetree/bindings/input/dlg,da72??.txt
+F: Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
F: Documentation/devicetree/bindings/mfd/da90*.txt
F: Documentation/devicetree/bindings/mfd/dlg,da90*.yaml
F: Documentation/devicetree/bindings/regulator/da92*.txt
--
2.39.2
^ permalink raw reply related
* [PATCH v6 RESEND 0/6] Convert DA906{1,2} bindings to json-schema
From: Biju Das @ 2024-01-31 10:26 UTC (permalink / raw)
To: Lee Jones, Wim Van Sebroeck, Guenter Roeck, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Biju Das, Support Opensource, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Steve Twiss, linux-input, devicetree,
linux-pm, linux-watchdog, Geert Uytterhoeven,
Prabhakar Mahadev Lad, Biju Das, linux-renesas-soc
Convert the below bindings to json-schema
1) DA906{1,2} mfd bindings
2) DA906{1,2,3} onkey bindings
3) DA906{1,2,3} thermal bindings
Document missing gpio child node for da9062 and update MAINTAINERS entries.
Merge strategy:
Since there is binding dependency between input, thermal and MFD
subsystem. it is decided that this series will go through the MFD tree.
So once the respective subsystem maintainers, DT and Renesas are happy
with the patch they can give an ack/rb tag, so that it can be applied to
MFD tree.
v6->v6 Resend:
* Dropped Patch#2 and patch#3 from this series as it hits mainline.
* Added Ack from Lee Jones for all the patches.
* Fixed merge conflict on MAINTAINERS file for patch#1
* Added Rb tag from Conor for patch#6.
v5->v6:
* Added Rb tag from Guenter Roeck for watchdog binding patches.
* Updated commit description related to "gpio-controller" and
"#gpio-cells" properties defined in parent node.
* Added Rb tag from Krzysztof Kozlowski for patch#8.
v4->v5:
* Updated cover letter with merging strategy.
* Added fixes tag for patch#1
* Added Rb tags from Geert and Krzysztof for patch#1
* Added Ack from Conor for patch#1
* Added Rb tag from Geert and Ack from Conor for patch#2
* Drop items and just use enum as it is easier to read for compatibles.
* Retained the tags for patch#2 as it is trivial change.
* Added Rb tag from Geert for patch#3
* Updated commit header and description by replacing
'watchdog property'->'watchdog child node'
* Added Rb tag from Geert for patch#4.
* Added Rb tag from Krzysztof and Conor for patch#5
* Dropped Items, Just enum as it is easier to read compatibles.
* Retained tags for patch#5 as the changes are trivial.
* Updated commit description for patch#8
* Dropped unnecessary ref from gpio child node.
* Added gpio-hog pattern property
* Moved gpio-controller,gpio-cells above child nodes
* Sorted compatible in rtc child node.
* Dropped status from example.
* Updated the example.
v3->v4:
* Patch#1 is merge of patch#1 from v2 + patch#8 from v2.
* Dropped comment for d9061 watchdog fallback
* Replaced enum->const for dlg,da9061-watchdog and its fallback.
* Restored patch#4 in series 1 and dropped the thermal example
* Added Ack from Conor Dooley for da9063 watchdog binding support.
* Updated title DA9062/61->DA906{1,2,3} as it supports DA9063.
* Retained Rb tag since the changes are trivial.
* Added Ack from Conor for updating watchdog property
* Dropped link to product information.
* Patch#5(onkey) is squashed with patch#6 and patch#9 from v2.
* Replaced enum->const for dlg,da9061-onkey and its fallback.
* Dropped example
* Restored the thermal binding patch from v2.
* Dropped example
* Replaced enum->const for compatible property.
* Added Rb tag from Rob and retained Rb tag as changes are trivial.
* Added Ack from Conor Dooley for patch#7.
* Split the thermal binding patch separate
* Updated the description
v2->v3:
* Updated Maintainer entries for watchdog,onkey and thermal bindings
* Fixed bot errors related to MAINTAINERS entry, invalid doc
references and thermal examples by merging patch#4.
v1->v2:
Link: https://lore.kernel.org/all/20231201110840.37408-5-biju.das.jz@bp.renesas.com/
* DA9062 and DA9061 merged with DA9063
* Sorted the child devices
* mfd,onkey and thermal are pointing to child bindings
Biju Das (6):
dt-bindings: mfd: da9062: Update watchdog description
dt-bindings: mfd: dlg,da9063: Update watchdog child node
dt-bindings: input: Convert da906{1,2,3} onkey to json-schema
dt-bindings: thermal: Convert da906{1,2} thermal to json-schema
dt-bindings: mfd: dlg,da9063: Sort child devices
dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
.../bindings/input/da9062-onkey.txt | 47 ----
.../bindings/input/dlg,da9062-onkey.yaml | 38 +++
.../devicetree/bindings/mfd/da9062.txt | 124 ---------
.../devicetree/bindings/mfd/dlg,da9063.yaml | 248 +++++++++++++++---
.../bindings/thermal/da9062-thermal.txt | 36 ---
.../bindings/thermal/dlg,da9062-thermal.yaml | 35 +++
MAINTAINERS | 6 +-
7 files changed, 290 insertions(+), 244 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt
create mode 100644 Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/da9062.txt
delete mode 100644 Documentation/devicetree/bindings/thermal/da9062-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml
--
2.39.2
^ permalink raw reply
* Re: Suspected bug in hid-microsoft.c
From: Benjamin Tissoires @ 2024-01-31 9:57 UTC (permalink / raw)
To: Taco Jerkface, Siarhei Vishniakou; +Cc: linux-input, jikos
In-Reply-To: <CAEQPD4RSFJN5TvU2vwHL=w1TkMzxD+v1=jxyyNzZDMyPane=BQ@mail.gmail.com>
Hi,
[Adding Siarhei who added support for those controllers in the kernel]
On Wed, Jan 31, 2024 at 7:27 AM Taco Jerkface <tacodog311@gmail.com> wrote:
>
> Resending without HTML:
>
> Hi,
>
> I hope this is the correct contact for this report, I found you as the
> maintainer in the hid-microsoft.c.
>
> I believe there is a bug in the microsoft bluetooth driver for the
> Xbox Elite Series 2 controller. I have been experiencing issues with
> it that I initially thought were SDL related. However the SDL team
> seems to think this is driver related. My SDL bug report information
> is here:
>
> https://github.com/libsdl-org/SDL/issues/8907
Hard to say anything with that bug report because we don't know what
those tools are supposed to do, and how they access the device (hidraw
or evdev).
Note that the bluetooth version is using uhid because it's a BLE controller.
Basically when there is a BLE controller, bluez handles the transport
layer from userspace, and injects the events through uhid so that it's
handled as a normal kernel device.
So there is no "uhid userspace driver", bluez just blindly forwards
the events/reports/commands as it is told.
>
> Basically, SDL reads the controller correctly when connected by USB,
> and if I run "controllermap" with root permission, but with user
> permissions it misreads
Using root or not shouldn't change the way your program sees the
device: if you are capable of opening it, then you should get the same
output.
However, the immediate explanation that would come to my mind is that
you are not using the "same" controller in both cases:
- maybe that when you use it with root you are talking to the device
through hidraw
- maybe when you are not root you are talking to the device through evdev
Again, not knowing the tools doesn't help me here :(
> the number of buttons as 122, the first paddle
> button on the back seems to act like the "screenshot" button from the
> 1914 controller, and the other paddle buttons are not read. All
> buttons read fine with evites, but the paddle buttons "KEY_UNKNOWN"
>
> type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
>
> Please let me know if there is a better contact for this, or if there
> is anything I can do to help identify the problem.
>
Ideally I'd like Siarhei to answer here. But in the meantime, we could
fetch some logs from the device itself which would allow me to better
understand the issue:
please use hid-recorder from hid-tools[1] to get the logs, and attach
the whole output, with a recording of the events that are problematic:
$> pip3 install hid-tools
$> sudo hid-recorder
Please dump 2 hid-recorder outputs, one with USB, and one with
Bluetooth, with the same event sequence if possible so we can compare
between the 2.
Cheers,
Benjamin
[1] https://gitlab.freedesktop.org/libevdev/hid-tools
^ permalink raw reply
* Re: [PATCH bpf-next v4 0/3] Annotate kfuncs in .BTF_ids section
From: Jiri Olsa @ 2024-01-31 9:47 UTC (permalink / raw)
To: Daniel Xu
Cc: linux-trace-kernel, coreteam, bpf, linux-input, cgroups, netdev,
linux-stm32, linux-kselftest, linux-doc, fsverity, linux-kernel,
linux-arm-kernel, netfilter-devel, alexei.starovoitov, olsajiri,
quentin, alan.maguire, memxor
In-Reply-To: <cover.1706491398.git.dxu@dxuuu.xyz>
On Sun, Jan 28, 2024 at 06:24:05PM -0700, Daniel Xu wrote:
> === Description ===
>
> This is a bpf-treewide change that annotates all kfuncs as such inside
> .BTF_ids. This annotation eventually allows us to automatically generate
> kfunc prototypes from bpftool.
>
> We store this metadata inside a yet-unused flags field inside struct
> btf_id_set8 (thanks Kumar!). pahole will be taught where to look.
>
> More details about the full chain of events are available in commit 3's
> description.
>
> The accompanying pahole and bpftool changes can be viewed
> here on these "frozen" branches [0][1].
>
> [0]: https://github.com/danobi/pahole/tree/kfunc_btf-v3-mailed
> [1]: https://github.com/danobi/linux/tree/kfunc_bpftool-mailed
>
> === Changelog ===
>
> Changes from v3:
> * Rebase to bpf-next and add missing annotation on new kfunc
Acked-by: Jiri Olsa <jolsa@kernel.org>
jirka
>
> Changes from v2:
> * Only WARN() for vmlinux kfuncs
>
> Changes from v1:
> * Move WARN_ON() up a call level
> * Also return error when kfunc set is not properly tagged
> * Use BTF_KFUNCS_START/END instead of flags
> * Rename BTF_SET8_KFUNC to BTF_SET8_KFUNCS
>
> Daniel Xu (3):
> bpf: btf: Support flags for BTF_SET8 sets
> bpf: btf: Add BTF_KFUNCS_START/END macro pair
> bpf: treewide: Annotate BPF kfuncs in BTF
>
> Documentation/bpf/kfuncs.rst | 8 +++----
> drivers/hid/bpf/hid_bpf_dispatch.c | 8 +++----
> fs/verity/measure.c | 4 ++--
> include/linux/btf_ids.h | 21 +++++++++++++++----
> kernel/bpf/btf.c | 8 +++++++
> kernel/bpf/cpumask.c | 4 ++--
> kernel/bpf/helpers.c | 8 +++----
> kernel/bpf/map_iter.c | 4 ++--
> kernel/cgroup/rstat.c | 4 ++--
> kernel/trace/bpf_trace.c | 8 +++----
> net/bpf/test_run.c | 8 +++----
> net/core/filter.c | 20 +++++++++---------
> net/core/xdp.c | 4 ++--
> net/ipv4/bpf_tcp_ca.c | 4 ++--
> net/ipv4/fou_bpf.c | 4 ++--
> net/ipv4/tcp_bbr.c | 4 ++--
> net/ipv4/tcp_cubic.c | 4 ++--
> net/ipv4/tcp_dctcp.c | 4 ++--
> net/netfilter/nf_conntrack_bpf.c | 4 ++--
> net/netfilter/nf_nat_bpf.c | 4 ++--
> net/xfrm/xfrm_interface_bpf.c | 4 ++--
> net/xfrm/xfrm_state_bpf.c | 4 ++--
> .../selftests/bpf/bpf_testmod/bpf_testmod.c | 8 +++----
> 23 files changed, 87 insertions(+), 66 deletions(-)
>
> --
> 2.42.1
>
^ permalink raw reply
* Re: [PATCH bpf-next v4 3/3] bpf: treewide: Annotate BPF kfuncs in BTF
From: Benjamin Tissoires @ 2024-01-31 9:24 UTC (permalink / raw)
To: Daniel Xu
Cc: mhiramat, daniel, edumazet, fw, hannes, tytso, ast, eddyz87, kuba,
tj, steffen.klassert, yonghong.song, hawk, rostedt,
john.fastabend, pablo, pabeni, jikos, davem, alexandre.torgue,
Herbert Xu, song, dsahern, mcoquelin.stm32, corbet, lizefan.x,
andrii, martin.lau, benjamin.tissoires, ebiggers, kadlec, shuah,
alexei.starovoitov, olsajiri, quentin, alan.maguire, memxor,
kpsingh, sdf, haoluo, jolsa, mathieu.desnoyers, mykolal, bpf,
linux-doc, linux-kernel, linux-input, fsverity, cgroups,
linux-trace-kernel, netdev, netfilter-devel, coreteam,
linux-kselftest, linux-stm32, linux-arm-kernel
In-Reply-To: <e55150ceecbf0a5d961e608941165c0bee7bc943.1706491398.git.dxu@dxuuu.xyz>
On Jan 28 2024, Daniel Xu wrote:
> This commit marks kfuncs as such inside the .BTF_ids section. The upshot
> of these annotations is that we'll be able to automatically generate
> kfunc prototypes for downstream users. The process is as follows:
>
> 1. In source, use BTF_KFUNCS_START/END macro pair to mark kfuncs
> 2. During build, pahole injects into BTF a "bpf_kfunc" BTF_DECL_TAG for
> each function inside BTF_KFUNCS sets
> 3. At runtime, vmlinux or module BTF is made available in sysfs
> 4. At runtime, bpftool (or similar) can look at provided BTF and
> generate appropriate prototypes for functions with "bpf_kfunc" tag
>
> To ensure future kfunc are similarly tagged, we now also return error
> inside kfunc registration for untagged kfuncs. For vmlinux kfuncs,
> we also WARN(), as initcall machinery does not handle errors.
>
> Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
> ---
> Documentation/bpf/kfuncs.rst | 8 ++++----
> drivers/hid/bpf/hid_bpf_dispatch.c | 8 ++++----
For the HID changes (they shouldn't conflict with our current branch):
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Cheers,
Benjamin
> fs/verity/measure.c | 4 ++--
> kernel/bpf/btf.c | 8 ++++++++
> kernel/bpf/cpumask.c | 4 ++--
> kernel/bpf/helpers.c | 8 ++++----
> kernel/bpf/map_iter.c | 4 ++--
> kernel/cgroup/rstat.c | 4 ++--
> kernel/trace/bpf_trace.c | 8 ++++----
> net/bpf/test_run.c | 8 ++++----
> net/core/filter.c | 20 +++++++++----------
> net/core/xdp.c | 4 ++--
> net/ipv4/bpf_tcp_ca.c | 4 ++--
> net/ipv4/fou_bpf.c | 4 ++--
> net/ipv4/tcp_bbr.c | 4 ++--
> net/ipv4/tcp_cubic.c | 4 ++--
> net/ipv4/tcp_dctcp.c | 4 ++--
> net/netfilter/nf_conntrack_bpf.c | 4 ++--
> net/netfilter/nf_nat_bpf.c | 4 ++--
> net/xfrm/xfrm_interface_bpf.c | 4 ++--
> net/xfrm/xfrm_state_bpf.c | 4 ++--
> .../selftests/bpf/bpf_testmod/bpf_testmod.c | 8 ++++----
> 22 files changed, 70 insertions(+), 62 deletions(-)
>
> diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst
> index 7985c6615f3c..a8f5782bd833 100644
> --- a/Documentation/bpf/kfuncs.rst
> +++ b/Documentation/bpf/kfuncs.rst
> @@ -177,10 +177,10 @@ In addition to kfuncs' arguments, verifier may need more information about the
> type of kfunc(s) being registered with the BPF subsystem. To do so, we define
> flags on a set of kfuncs as follows::
>
> - BTF_SET8_START(bpf_task_set)
> + BTF_KFUNCS_START(bpf_task_set)
> BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
> BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
> - BTF_SET8_END(bpf_task_set)
> + BTF_KFUNCS_END(bpf_task_set)
>
> This set encodes the BTF ID of each kfunc listed above, and encodes the flags
> along with it. Ofcourse, it is also allowed to specify no flags.
> @@ -347,10 +347,10 @@ Once the kfunc is prepared for use, the final step to making it visible is
> registering it with the BPF subsystem. Registration is done per BPF program
> type. An example is shown below::
>
> - BTF_SET8_START(bpf_task_set)
> + BTF_KFUNCS_START(bpf_task_set)
> BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
> BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
> - BTF_SET8_END(bpf_task_set)
> + BTF_KFUNCS_END(bpf_task_set)
>
> static const struct btf_kfunc_id_set bpf_task_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
> index d9ef45fcaeab..02c441aaa217 100644
> --- a/drivers/hid/bpf/hid_bpf_dispatch.c
> +++ b/drivers/hid/bpf/hid_bpf_dispatch.c
> @@ -172,9 +172,9 @@ hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned int offset, const size_t rdwr
> * The following set contains all functions we agree BPF programs
> * can use.
> */
> -BTF_SET8_START(hid_bpf_kfunc_ids)
> +BTF_KFUNCS_START(hid_bpf_kfunc_ids)
> BTF_ID_FLAGS(func, hid_bpf_get_data, KF_RET_NULL)
> -BTF_SET8_END(hid_bpf_kfunc_ids)
> +BTF_KFUNCS_END(hid_bpf_kfunc_ids)
>
> static const struct btf_kfunc_id_set hid_bpf_kfunc_set = {
> .owner = THIS_MODULE,
> @@ -440,12 +440,12 @@ static const struct btf_kfunc_id_set hid_bpf_fmodret_set = {
> };
>
> /* for syscall HID-BPF */
> -BTF_SET8_START(hid_bpf_syscall_kfunc_ids)
> +BTF_KFUNCS_START(hid_bpf_syscall_kfunc_ids)
> BTF_ID_FLAGS(func, hid_bpf_attach_prog)
> BTF_ID_FLAGS(func, hid_bpf_allocate_context, KF_ACQUIRE | KF_RET_NULL)
> BTF_ID_FLAGS(func, hid_bpf_release_context, KF_RELEASE)
> BTF_ID_FLAGS(func, hid_bpf_hw_request)
> -BTF_SET8_END(hid_bpf_syscall_kfunc_ids)
> +BTF_KFUNCS_END(hid_bpf_syscall_kfunc_ids)
>
> static const struct btf_kfunc_id_set hid_bpf_syscall_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/fs/verity/measure.c b/fs/verity/measure.c
> index bf7a5f4cccaf..3969d54158d1 100644
> --- a/fs/verity/measure.c
> +++ b/fs/verity/measure.c
> @@ -159,9 +159,9 @@ __bpf_kfunc int bpf_get_fsverity_digest(struct file *file, struct bpf_dynptr_ker
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(fsverity_set_ids)
> +BTF_KFUNCS_START(fsverity_set_ids)
> BTF_ID_FLAGS(func, bpf_get_fsverity_digest, KF_TRUSTED_ARGS)
> -BTF_SET8_END(fsverity_set_ids)
> +BTF_KFUNCS_END(fsverity_set_ids)
>
> static int bpf_get_fsverity_digest_filter(const struct bpf_prog *prog, u32 kfunc_id)
> {
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index edef96ceffa3..bc446f37530c 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -8041,6 +8041,14 @@ int register_btf_kfunc_id_set(enum bpf_prog_type prog_type,
> {
> enum btf_kfunc_hook hook;
>
> + /* All kfuncs need to be tagged as such in BTF.
> + * WARN() for initcall registrations that do not check errors.
> + */
> + if (!(kset->set->flags & BTF_SET8_KFUNCS)) {
> + WARN_ON(!kset->owner);
> + return -EINVAL;
> + }
> +
> hook = bpf_prog_type_to_kfunc_hook(prog_type);
> return __register_btf_kfunc_id_set(hook, kset);
> }
> diff --git a/kernel/bpf/cpumask.c b/kernel/bpf/cpumask.c
> index 2e73533a3811..dad0fb1c8e87 100644
> --- a/kernel/bpf/cpumask.c
> +++ b/kernel/bpf/cpumask.c
> @@ -424,7 +424,7 @@ __bpf_kfunc u32 bpf_cpumask_weight(const struct cpumask *cpumask)
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(cpumask_kfunc_btf_ids)
> +BTF_KFUNCS_START(cpumask_kfunc_btf_ids)
> BTF_ID_FLAGS(func, bpf_cpumask_create, KF_ACQUIRE | KF_RET_NULL)
> BTF_ID_FLAGS(func, bpf_cpumask_release, KF_RELEASE)
> BTF_ID_FLAGS(func, bpf_cpumask_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
> @@ -450,7 +450,7 @@ BTF_ID_FLAGS(func, bpf_cpumask_copy, KF_RCU)
> BTF_ID_FLAGS(func, bpf_cpumask_any_distribute, KF_RCU)
> BTF_ID_FLAGS(func, bpf_cpumask_any_and_distribute, KF_RCU)
> BTF_ID_FLAGS(func, bpf_cpumask_weight, KF_RCU)
> -BTF_SET8_END(cpumask_kfunc_btf_ids)
> +BTF_KFUNCS_END(cpumask_kfunc_btf_ids)
>
> static const struct btf_kfunc_id_set cpumask_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index bcb951a2ecf4..4db1c658254c 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2544,7 +2544,7 @@ __bpf_kfunc void bpf_throw(u64 cookie)
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(generic_btf_ids)
> +BTF_KFUNCS_START(generic_btf_ids)
> #ifdef CONFIG_KEXEC_CORE
> BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE)
> #endif
> @@ -2573,7 +2573,7 @@ BTF_ID_FLAGS(func, bpf_task_get_cgroup1, KF_ACQUIRE | KF_RCU | KF_RET_NULL)
> #endif
> BTF_ID_FLAGS(func, bpf_task_from_pid, KF_ACQUIRE | KF_RET_NULL)
> BTF_ID_FLAGS(func, bpf_throw)
> -BTF_SET8_END(generic_btf_ids)
> +BTF_KFUNCS_END(generic_btf_ids)
>
> static const struct btf_kfunc_id_set generic_kfunc_set = {
> .owner = THIS_MODULE,
> @@ -2589,7 +2589,7 @@ BTF_ID(struct, cgroup)
> BTF_ID(func, bpf_cgroup_release_dtor)
> #endif
>
> -BTF_SET8_START(common_btf_ids)
> +BTF_KFUNCS_START(common_btf_ids)
> BTF_ID_FLAGS(func, bpf_cast_to_kern_ctx)
> BTF_ID_FLAGS(func, bpf_rdonly_cast)
> BTF_ID_FLAGS(func, bpf_rcu_read_lock)
> @@ -2618,7 +2618,7 @@ BTF_ID_FLAGS(func, bpf_dynptr_is_null)
> BTF_ID_FLAGS(func, bpf_dynptr_is_rdonly)
> BTF_ID_FLAGS(func, bpf_dynptr_size)
> BTF_ID_FLAGS(func, bpf_dynptr_clone)
> -BTF_SET8_END(common_btf_ids)
> +BTF_KFUNCS_END(common_btf_ids)
>
> static const struct btf_kfunc_id_set common_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/kernel/bpf/map_iter.c b/kernel/bpf/map_iter.c
> index 6abd7c5df4b3..9575314f40a6 100644
> --- a/kernel/bpf/map_iter.c
> +++ b/kernel/bpf/map_iter.c
> @@ -213,9 +213,9 @@ __bpf_kfunc s64 bpf_map_sum_elem_count(const struct bpf_map *map)
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(bpf_map_iter_kfunc_ids)
> +BTF_KFUNCS_START(bpf_map_iter_kfunc_ids)
> BTF_ID_FLAGS(func, bpf_map_sum_elem_count, KF_TRUSTED_ARGS)
> -BTF_SET8_END(bpf_map_iter_kfunc_ids)
> +BTF_KFUNCS_END(bpf_map_iter_kfunc_ids)
>
> static const struct btf_kfunc_id_set bpf_map_iter_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c
> index a8350d2d63e6..07e2284bb499 100644
> --- a/kernel/cgroup/rstat.c
> +++ b/kernel/cgroup/rstat.c
> @@ -562,10 +562,10 @@ void cgroup_base_stat_cputime_show(struct seq_file *seq)
> }
>
> /* Add bpf kfuncs for cgroup_rstat_updated() and cgroup_rstat_flush() */
> -BTF_SET8_START(bpf_rstat_kfunc_ids)
> +BTF_KFUNCS_START(bpf_rstat_kfunc_ids)
> BTF_ID_FLAGS(func, cgroup_rstat_updated)
> BTF_ID_FLAGS(func, cgroup_rstat_flush, KF_SLEEPABLE)
> -BTF_SET8_END(bpf_rstat_kfunc_ids)
> +BTF_KFUNCS_END(bpf_rstat_kfunc_ids)
>
> static const struct btf_kfunc_id_set bpf_rstat_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 64fdaf79d113..241ddf5e3895 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -1412,14 +1412,14 @@ __bpf_kfunc int bpf_verify_pkcs7_signature(struct bpf_dynptr_kern *data_ptr,
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(key_sig_kfunc_set)
> +BTF_KFUNCS_START(key_sig_kfunc_set)
> BTF_ID_FLAGS(func, bpf_lookup_user_key, KF_ACQUIRE | KF_RET_NULL | KF_SLEEPABLE)
> BTF_ID_FLAGS(func, bpf_lookup_system_key, KF_ACQUIRE | KF_RET_NULL)
> BTF_ID_FLAGS(func, bpf_key_put, KF_RELEASE)
> #ifdef CONFIG_SYSTEM_DATA_VERIFICATION
> BTF_ID_FLAGS(func, bpf_verify_pkcs7_signature, KF_SLEEPABLE)
> #endif
> -BTF_SET8_END(key_sig_kfunc_set)
> +BTF_KFUNCS_END(key_sig_kfunc_set)
>
> static const struct btf_kfunc_id_set bpf_key_sig_kfunc_set = {
> .owner = THIS_MODULE,
> @@ -1475,9 +1475,9 @@ __bpf_kfunc int bpf_get_file_xattr(struct file *file, const char *name__str,
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(fs_kfunc_set_ids)
> +BTF_KFUNCS_START(fs_kfunc_set_ids)
> BTF_ID_FLAGS(func, bpf_get_file_xattr, KF_SLEEPABLE | KF_TRUSTED_ARGS)
> -BTF_SET8_END(fs_kfunc_set_ids)
> +BTF_KFUNCS_END(fs_kfunc_set_ids)
>
> static int bpf_get_file_xattr_filter(const struct bpf_prog *prog, u32 kfunc_id)
> {
> diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> index dfd919374017..5535f9adc658 100644
> --- a/net/bpf/test_run.c
> +++ b/net/bpf/test_run.c
> @@ -617,21 +617,21 @@ CFI_NOSEAL(bpf_kfunc_call_memb_release_dtor);
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(bpf_test_modify_return_ids)
> +BTF_KFUNCS_START(bpf_test_modify_return_ids)
> BTF_ID_FLAGS(func, bpf_modify_return_test)
> BTF_ID_FLAGS(func, bpf_modify_return_test2)
> BTF_ID_FLAGS(func, bpf_fentry_test1, KF_SLEEPABLE)
> -BTF_SET8_END(bpf_test_modify_return_ids)
> +BTF_KFUNCS_END(bpf_test_modify_return_ids)
>
> static const struct btf_kfunc_id_set bpf_test_modify_return_set = {
> .owner = THIS_MODULE,
> .set = &bpf_test_modify_return_ids,
> };
>
> -BTF_SET8_START(test_sk_check_kfunc_ids)
> +BTF_KFUNCS_START(test_sk_check_kfunc_ids)
> BTF_ID_FLAGS(func, bpf_kfunc_call_test_release, KF_RELEASE)
> BTF_ID_FLAGS(func, bpf_kfunc_call_memb_release, KF_RELEASE)
> -BTF_SET8_END(test_sk_check_kfunc_ids)
> +BTF_KFUNCS_END(test_sk_check_kfunc_ids)
>
> static void *bpf_test_init(const union bpf_attr *kattr, u32 user_size,
> u32 size, u32 headroom, u32 tailroom)
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 358870408a51..524adf1fa6d0 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -11982,21 +11982,21 @@ int bpf_dynptr_from_skb_rdonly(struct sk_buff *skb, u64 flags,
> return 0;
> }
>
> -BTF_SET8_START(bpf_kfunc_check_set_skb)
> +BTF_KFUNCS_START(bpf_kfunc_check_set_skb)
> BTF_ID_FLAGS(func, bpf_dynptr_from_skb)
> -BTF_SET8_END(bpf_kfunc_check_set_skb)
> +BTF_KFUNCS_END(bpf_kfunc_check_set_skb)
>
> -BTF_SET8_START(bpf_kfunc_check_set_xdp)
> +BTF_KFUNCS_START(bpf_kfunc_check_set_xdp)
> BTF_ID_FLAGS(func, bpf_dynptr_from_xdp)
> -BTF_SET8_END(bpf_kfunc_check_set_xdp)
> +BTF_KFUNCS_END(bpf_kfunc_check_set_xdp)
>
> -BTF_SET8_START(bpf_kfunc_check_set_sock_addr)
> +BTF_KFUNCS_START(bpf_kfunc_check_set_sock_addr)
> BTF_ID_FLAGS(func, bpf_sock_addr_set_sun_path)
> -BTF_SET8_END(bpf_kfunc_check_set_sock_addr)
> +BTF_KFUNCS_END(bpf_kfunc_check_set_sock_addr)
>
> -BTF_SET8_START(bpf_kfunc_check_set_tcp_reqsk)
> +BTF_KFUNCS_START(bpf_kfunc_check_set_tcp_reqsk)
> BTF_ID_FLAGS(func, bpf_sk_assign_tcp_reqsk, KF_TRUSTED_ARGS)
> -BTF_SET8_END(bpf_kfunc_check_set_tcp_reqsk)
> +BTF_KFUNCS_END(bpf_kfunc_check_set_tcp_reqsk)
>
> static const struct btf_kfunc_id_set bpf_kfunc_set_skb = {
> .owner = THIS_MODULE,
> @@ -12075,9 +12075,9 @@ __bpf_kfunc int bpf_sock_destroy(struct sock_common *sock)
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(bpf_sk_iter_kfunc_ids)
> +BTF_KFUNCS_START(bpf_sk_iter_kfunc_ids)
> BTF_ID_FLAGS(func, bpf_sock_destroy, KF_TRUSTED_ARGS)
> -BTF_SET8_END(bpf_sk_iter_kfunc_ids)
> +BTF_KFUNCS_END(bpf_sk_iter_kfunc_ids)
>
> static int tracing_iter_filter(const struct bpf_prog *prog, u32 kfunc_id)
> {
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 4869c1c2d8f3..034fb80f3fbe 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -771,11 +771,11 @@ __bpf_kfunc int bpf_xdp_metadata_rx_vlan_tag(const struct xdp_md *ctx,
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(xdp_metadata_kfunc_ids)
> +BTF_KFUNCS_START(xdp_metadata_kfunc_ids)
> #define XDP_METADATA_KFUNC(_, __, name, ___) BTF_ID_FLAGS(func, name, KF_TRUSTED_ARGS)
> XDP_METADATA_KFUNC_xxx
> #undef XDP_METADATA_KFUNC
> -BTF_SET8_END(xdp_metadata_kfunc_ids)
> +BTF_KFUNCS_END(xdp_metadata_kfunc_ids)
>
> static const struct btf_kfunc_id_set xdp_metadata_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/net/ipv4/bpf_tcp_ca.c b/net/ipv4/bpf_tcp_ca.c
> index 834edc18463a..7f518ea5f4ac 100644
> --- a/net/ipv4/bpf_tcp_ca.c
> +++ b/net/ipv4/bpf_tcp_ca.c
> @@ -201,13 +201,13 @@ bpf_tcp_ca_get_func_proto(enum bpf_func_id func_id,
> }
> }
>
> -BTF_SET8_START(bpf_tcp_ca_check_kfunc_ids)
> +BTF_KFUNCS_START(bpf_tcp_ca_check_kfunc_ids)
> BTF_ID_FLAGS(func, tcp_reno_ssthresh)
> BTF_ID_FLAGS(func, tcp_reno_cong_avoid)
> BTF_ID_FLAGS(func, tcp_reno_undo_cwnd)
> BTF_ID_FLAGS(func, tcp_slow_start)
> BTF_ID_FLAGS(func, tcp_cong_avoid_ai)
> -BTF_SET8_END(bpf_tcp_ca_check_kfunc_ids)
> +BTF_KFUNCS_END(bpf_tcp_ca_check_kfunc_ids)
>
> static const struct btf_kfunc_id_set bpf_tcp_ca_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/net/ipv4/fou_bpf.c b/net/ipv4/fou_bpf.c
> index 4da03bf45c9b..06e5572f296f 100644
> --- a/net/ipv4/fou_bpf.c
> +++ b/net/ipv4/fou_bpf.c
> @@ -100,10 +100,10 @@ __bpf_kfunc int bpf_skb_get_fou_encap(struct __sk_buff *skb_ctx,
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(fou_kfunc_set)
> +BTF_KFUNCS_START(fou_kfunc_set)
> BTF_ID_FLAGS(func, bpf_skb_set_fou_encap)
> BTF_ID_FLAGS(func, bpf_skb_get_fou_encap)
> -BTF_SET8_END(fou_kfunc_set)
> +BTF_KFUNCS_END(fou_kfunc_set)
>
> static const struct btf_kfunc_id_set fou_bpf_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/net/ipv4/tcp_bbr.c b/net/ipv4/tcp_bbr.c
> index 22358032dd48..05dc2d05bc7c 100644
> --- a/net/ipv4/tcp_bbr.c
> +++ b/net/ipv4/tcp_bbr.c
> @@ -1155,7 +1155,7 @@ static struct tcp_congestion_ops tcp_bbr_cong_ops __read_mostly = {
> .set_state = bbr_set_state,
> };
>
> -BTF_SET8_START(tcp_bbr_check_kfunc_ids)
> +BTF_KFUNCS_START(tcp_bbr_check_kfunc_ids)
> #ifdef CONFIG_X86
> #ifdef CONFIG_DYNAMIC_FTRACE
> BTF_ID_FLAGS(func, bbr_init)
> @@ -1168,7 +1168,7 @@ BTF_ID_FLAGS(func, bbr_min_tso_segs)
> BTF_ID_FLAGS(func, bbr_set_state)
> #endif
> #endif
> -BTF_SET8_END(tcp_bbr_check_kfunc_ids)
> +BTF_KFUNCS_END(tcp_bbr_check_kfunc_ids)
>
> static const struct btf_kfunc_id_set tcp_bbr_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
> index 0fd78ecb67e7..44869ea089e3 100644
> --- a/net/ipv4/tcp_cubic.c
> +++ b/net/ipv4/tcp_cubic.c
> @@ -485,7 +485,7 @@ static struct tcp_congestion_ops cubictcp __read_mostly = {
> .name = "cubic",
> };
>
> -BTF_SET8_START(tcp_cubic_check_kfunc_ids)
> +BTF_KFUNCS_START(tcp_cubic_check_kfunc_ids)
> #ifdef CONFIG_X86
> #ifdef CONFIG_DYNAMIC_FTRACE
> BTF_ID_FLAGS(func, cubictcp_init)
> @@ -496,7 +496,7 @@ BTF_ID_FLAGS(func, cubictcp_cwnd_event)
> BTF_ID_FLAGS(func, cubictcp_acked)
> #endif
> #endif
> -BTF_SET8_END(tcp_cubic_check_kfunc_ids)
> +BTF_KFUNCS_END(tcp_cubic_check_kfunc_ids)
>
> static const struct btf_kfunc_id_set tcp_cubic_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/net/ipv4/tcp_dctcp.c b/net/ipv4/tcp_dctcp.c
> index bb23bb5b387a..e33fbe4933e4 100644
> --- a/net/ipv4/tcp_dctcp.c
> +++ b/net/ipv4/tcp_dctcp.c
> @@ -260,7 +260,7 @@ static struct tcp_congestion_ops dctcp_reno __read_mostly = {
> .name = "dctcp-reno",
> };
>
> -BTF_SET8_START(tcp_dctcp_check_kfunc_ids)
> +BTF_KFUNCS_START(tcp_dctcp_check_kfunc_ids)
> #ifdef CONFIG_X86
> #ifdef CONFIG_DYNAMIC_FTRACE
> BTF_ID_FLAGS(func, dctcp_init)
> @@ -271,7 +271,7 @@ BTF_ID_FLAGS(func, dctcp_cwnd_undo)
> BTF_ID_FLAGS(func, dctcp_state)
> #endif
> #endif
> -BTF_SET8_END(tcp_dctcp_check_kfunc_ids)
> +BTF_KFUNCS_END(tcp_dctcp_check_kfunc_ids)
>
> static const struct btf_kfunc_id_set tcp_dctcp_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/net/netfilter/nf_conntrack_bpf.c b/net/netfilter/nf_conntrack_bpf.c
> index 475358ec8212..d2492d050fe6 100644
> --- a/net/netfilter/nf_conntrack_bpf.c
> +++ b/net/netfilter/nf_conntrack_bpf.c
> @@ -467,7 +467,7 @@ __bpf_kfunc int bpf_ct_change_status(struct nf_conn *nfct, u32 status)
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(nf_ct_kfunc_set)
> +BTF_KFUNCS_START(nf_ct_kfunc_set)
> BTF_ID_FLAGS(func, bpf_xdp_ct_alloc, KF_ACQUIRE | KF_RET_NULL)
> BTF_ID_FLAGS(func, bpf_xdp_ct_lookup, KF_ACQUIRE | KF_RET_NULL)
> BTF_ID_FLAGS(func, bpf_skb_ct_alloc, KF_ACQUIRE | KF_RET_NULL)
> @@ -478,7 +478,7 @@ BTF_ID_FLAGS(func, bpf_ct_set_timeout, KF_TRUSTED_ARGS)
> BTF_ID_FLAGS(func, bpf_ct_change_timeout, KF_TRUSTED_ARGS)
> BTF_ID_FLAGS(func, bpf_ct_set_status, KF_TRUSTED_ARGS)
> BTF_ID_FLAGS(func, bpf_ct_change_status, KF_TRUSTED_ARGS)
> -BTF_SET8_END(nf_ct_kfunc_set)
> +BTF_KFUNCS_END(nf_ct_kfunc_set)
>
> static const struct btf_kfunc_id_set nf_conntrack_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/net/netfilter/nf_nat_bpf.c b/net/netfilter/nf_nat_bpf.c
> index 6e3b2f58855f..481be15609b1 100644
> --- a/net/netfilter/nf_nat_bpf.c
> +++ b/net/netfilter/nf_nat_bpf.c
> @@ -54,9 +54,9 @@ __bpf_kfunc int bpf_ct_set_nat_info(struct nf_conn___init *nfct,
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(nf_nat_kfunc_set)
> +BTF_KFUNCS_START(nf_nat_kfunc_set)
> BTF_ID_FLAGS(func, bpf_ct_set_nat_info, KF_TRUSTED_ARGS)
> -BTF_SET8_END(nf_nat_kfunc_set)
> +BTF_KFUNCS_END(nf_nat_kfunc_set)
>
> static const struct btf_kfunc_id_set nf_bpf_nat_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/net/xfrm/xfrm_interface_bpf.c b/net/xfrm/xfrm_interface_bpf.c
> index 7d5e920141e9..5ea15037ebd1 100644
> --- a/net/xfrm/xfrm_interface_bpf.c
> +++ b/net/xfrm/xfrm_interface_bpf.c
> @@ -93,10 +93,10 @@ __bpf_kfunc int bpf_skb_set_xfrm_info(struct __sk_buff *skb_ctx, const struct bp
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(xfrm_ifc_kfunc_set)
> +BTF_KFUNCS_START(xfrm_ifc_kfunc_set)
> BTF_ID_FLAGS(func, bpf_skb_get_xfrm_info)
> BTF_ID_FLAGS(func, bpf_skb_set_xfrm_info)
> -BTF_SET8_END(xfrm_ifc_kfunc_set)
> +BTF_KFUNCS_END(xfrm_ifc_kfunc_set)
>
> static const struct btf_kfunc_id_set xfrm_interface_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/net/xfrm/xfrm_state_bpf.c b/net/xfrm/xfrm_state_bpf.c
> index 9e20d4a377f7..2248eda741f8 100644
> --- a/net/xfrm/xfrm_state_bpf.c
> +++ b/net/xfrm/xfrm_state_bpf.c
> @@ -117,10 +117,10 @@ __bpf_kfunc void bpf_xdp_xfrm_state_release(struct xfrm_state *x)
>
> __bpf_kfunc_end_defs();
>
> -BTF_SET8_START(xfrm_state_kfunc_set)
> +BTF_KFUNCS_START(xfrm_state_kfunc_set)
> BTF_ID_FLAGS(func, bpf_xdp_get_xfrm_state, KF_RET_NULL | KF_ACQUIRE)
> BTF_ID_FLAGS(func, bpf_xdp_xfrm_state_release, KF_RELEASE)
> -BTF_SET8_END(xfrm_state_kfunc_set)
> +BTF_KFUNCS_END(xfrm_state_kfunc_set)
>
> static const struct btf_kfunc_id_set xfrm_state_xdp_kfunc_set = {
> .owner = THIS_MODULE,
> diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> index 8befaf17d454..53f73fc86baa 100644
> --- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> +++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> @@ -343,12 +343,12 @@ static struct bin_attribute bin_attr_bpf_testmod_file __ro_after_init = {
> .write = bpf_testmod_test_write,
> };
>
> -BTF_SET8_START(bpf_testmod_common_kfunc_ids)
> +BTF_KFUNCS_START(bpf_testmod_common_kfunc_ids)
> BTF_ID_FLAGS(func, bpf_iter_testmod_seq_new, KF_ITER_NEW)
> BTF_ID_FLAGS(func, bpf_iter_testmod_seq_next, KF_ITER_NEXT | KF_RET_NULL)
> BTF_ID_FLAGS(func, bpf_iter_testmod_seq_destroy, KF_ITER_DESTROY)
> BTF_ID_FLAGS(func, bpf_kfunc_common_test)
> -BTF_SET8_END(bpf_testmod_common_kfunc_ids)
> +BTF_KFUNCS_END(bpf_testmod_common_kfunc_ids)
>
> static const struct btf_kfunc_id_set bpf_testmod_common_kfunc_set = {
> .owner = THIS_MODULE,
> @@ -494,7 +494,7 @@ __bpf_kfunc static u32 bpf_kfunc_call_test_static_unused_arg(u32 arg, u32 unused
> return arg;
> }
>
> -BTF_SET8_START(bpf_testmod_check_kfunc_ids)
> +BTF_KFUNCS_START(bpf_testmod_check_kfunc_ids)
> BTF_ID_FLAGS(func, bpf_testmod_test_mod_kfunc)
> BTF_ID_FLAGS(func, bpf_kfunc_call_test1)
> BTF_ID_FLAGS(func, bpf_kfunc_call_test2)
> @@ -520,7 +520,7 @@ BTF_ID_FLAGS(func, bpf_kfunc_call_test_ref, KF_TRUSTED_ARGS | KF_RCU)
> BTF_ID_FLAGS(func, bpf_kfunc_call_test_destructive, KF_DESTRUCTIVE)
> BTF_ID_FLAGS(func, bpf_kfunc_call_test_static_unused_arg)
> BTF_ID_FLAGS(func, bpf_kfunc_call_test_offset)
> -BTF_SET8_END(bpf_testmod_check_kfunc_ids)
> +BTF_KFUNCS_END(bpf_testmod_check_kfunc_ids)
>
> static int bpf_testmod_ops_init(struct btf *btf)
> {
> --
> 2.42.1
>
^ 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