* Re: [PATCH v3 4/6] dt-bindings: touchscreen: fsl,imx6ul-tsc: support glitch thresold
From: Conor Dooley @ 2025-09-16 19:27 UTC (permalink / raw)
To: Frank Li
Cc: Dario Binacchi, linux-kernel, linux-amarula, Conor Dooley,
Dmitry Torokhov, Fabio Estevam, Haibo Chen, Krzysztof Kozlowski,
Pengutronix Kernel Team, Rob Herring, Sascha Hauer, Shawn Guo,
devicetree, imx, linux-arm-kernel, linux-input
In-Reply-To: <20250916-auction-angelfish-0239691a54e5@spud>
[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]
On Tue, Sep 16, 2025 at 08:25:53PM +0100, Conor Dooley wrote:
> On Tue, Sep 16, 2025 at 11:55:17AM -0400, Frank Li wrote:
> > On Mon, Sep 15, 2025 at 09:53:06PM +0200, Dario Binacchi wrote:
> > > Support the touchscreen-glitch-threshold-ns property. Unlike the
> > > generic description in touchscreen.yaml, this controller maps the
> > > provided value to one of four discrete thresholds internally.
> > >
> > > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> > >
> > > ---
> > >
> > > Changes in v3:
> > > - Remove the final part of the description that refers to
> > > implementation details.
> > >
> > > .../bindings/input/touchscreen/fsl,imx6ul-tsc.yaml | 12 ++++++++++++
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > > index 678756ad0f92..6214d8be5a99 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > > @@ -62,6 +62,18 @@ properties:
> > > description: Number of data samples which are averaged for each read.
> > > enum: [ 1, 4, 8, 16, 32 ]
> > >
> > > + touchscreen-glitch-threshold-ns:
> > > + description: |
> > > + Unlike the generic property defined in touchscreen.yaml, this
> > > + controller does not allow arbitrary values. Internally the value is
> > > + converted to IPG clock cycles and mapped to one of four discrete
> > > + thresholds exposed by the TSC_DEBUG_MODE2 register:
> > > +
> > > + 0: 8191 IPG cycles
> > > + 1: 4095 IPG cycles
> > > + 2: 2047 IPG cycles
> > > + 3: 1023 IPG cycles
> > > +
> >
> > You have to use ns here. You can caculate in driver to match to closed one.
>
> That is what he is saying it is doing - "internally the value is
> converted to IPG clock cycles" and so on. Your repeated misunderstanding
> of this though points out that maybe the description is still lacking?
>
> Dario, how about:
> | The gitch threshold in nanoseconds. Drivers must convert this value to
Or maybe instead of what I did here for the first sentence, yoink the text
from [3/6] instead and re-use it.
> | IPG clock cycles and map it to one of the four discrete thresholds
> | exposed by the TSC_DEBUG_MODE2 register:
> |
> | 0: 8191 IPG cycles
> | 1: 4095 IPG cycles
> | 2: 2047 IPG cycles
> | 3: 1023 IPG cycles
> ?
> I dropped the bit about arbitrary values, due to my comment on the other
> version a few mins ago.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 4/6] dt-bindings: touchscreen: fsl,imx6ul-tsc: support glitch thresold
From: Conor Dooley @ 2025-09-16 19:25 UTC (permalink / raw)
To: Frank Li
Cc: Dario Binacchi, linux-kernel, linux-amarula, Conor Dooley,
Dmitry Torokhov, Fabio Estevam, Haibo Chen, Krzysztof Kozlowski,
Pengutronix Kernel Team, Rob Herring, Sascha Hauer, Shawn Guo,
devicetree, imx, linux-arm-kernel, linux-input
In-Reply-To: <aMmIZTMqr0rtiP6z@lizhi-Precision-Tower-5810>
[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]
On Tue, Sep 16, 2025 at 11:55:17AM -0400, Frank Li wrote:
> On Mon, Sep 15, 2025 at 09:53:06PM +0200, Dario Binacchi wrote:
> > Support the touchscreen-glitch-threshold-ns property. Unlike the
> > generic description in touchscreen.yaml, this controller maps the
> > provided value to one of four discrete thresholds internally.
> >
> > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> >
> > ---
> >
> > Changes in v3:
> > - Remove the final part of the description that refers to
> > implementation details.
> >
> > .../bindings/input/touchscreen/fsl,imx6ul-tsc.yaml | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > index 678756ad0f92..6214d8be5a99 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > @@ -62,6 +62,18 @@ properties:
> > description: Number of data samples which are averaged for each read.
> > enum: [ 1, 4, 8, 16, 32 ]
> >
> > + touchscreen-glitch-threshold-ns:
> > + description: |
> > + Unlike the generic property defined in touchscreen.yaml, this
> > + controller does not allow arbitrary values. Internally the value is
> > + converted to IPG clock cycles and mapped to one of four discrete
> > + thresholds exposed by the TSC_DEBUG_MODE2 register:
> > +
> > + 0: 8191 IPG cycles
> > + 1: 4095 IPG cycles
> > + 2: 2047 IPG cycles
> > + 3: 1023 IPG cycles
> > +
>
> You have to use ns here. You can caculate in driver to match to closed one.
That is what he is saying it is doing - "internally the value is
converted to IPG clock cycles" and so on. Your repeated misunderstanding
of this though points out that maybe the description is still lacking?
Dario, how about:
| The gitch threshold in nanoseconds. Drivers must convert this value to
| IPG clock cycles and map it to one of the four discrete thresholds
| exposed by the TSC_DEBUG_MODE2 register:
|
| 0: 8191 IPG cycles
| 1: 4095 IPG cycles
| 2: 2047 IPG cycles
| 3: 1023 IPG cycles
?
I dropped the bit about arbitrary values, due to my comment on the other
version a few mins ago.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/6] dt-bindings: touchscreen: fsl,imx6ul-tsc: support glitch thresold
From: Conor Dooley @ 2025-09-16 18:34 UTC (permalink / raw)
To: Frank Li
Cc: Dario Binacchi, linux-kernel, linux-amarula, Conor Dooley,
Dmitry Torokhov, Fabio Estevam, Haibo Chen, Krzysztof Kozlowski,
Pengutronix Kernel Team, Rob Herring, Sascha Hauer, Shawn Guo,
devicetree, imx, linux-arm-kernel, linux-input
In-Reply-To: <aMmKNYjxolrCb1yC@lizhi-Precision-Tower-5810>
[-- Attachment #1: Type: text/plain, Size: 2796 bytes --]
On Tue, Sep 16, 2025 at 12:03:01PM -0400, Frank Li wrote:
> On Mon, Sep 15, 2025 at 06:42:13PM +0100, Conor Dooley wrote:
> > On Mon, Sep 15, 2025 at 10:30:26AM -0400, Frank Li wrote:
> > > On Sun, Sep 14, 2025 at 07:16:01PM +0200, Dario Binacchi wrote:
> > > > Support the touchscreen-glitch-threshold-ns property. Unlike the
> > > > generic description in touchscreen.yaml, this controller maps the
> > > > provided value to one of four discrete thresholds internally.
> > > >
> > > > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> > > > ---
> > > >
> > > > (no changes since v1)
> > > >
> > > > .../input/touchscreen/fsl,imx6ul-tsc.yaml | 15 +++++++++++++++
> > > > 1 file changed, 15 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > > > index 678756ad0f92..310af56a0be6 100644
> > > > --- a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > > > @@ -62,6 +62,21 @@ properties:
> > > > description: Number of data samples which are averaged for each read.
> > > > enum: [ 1, 4, 8, 16, 32 ]
> > > >
> > > > + touchscreen-glitch-threshold-ns:
> > > > + description: |
> > > > + Unlike the generic property defined in touchscreen.yaml, this
> > > > + controller does not allow arbitrary values. Internally the value is
> > > > + converted to IPG clock cycles and mapped to one of four discrete
> > > > + thresholds exposed by the TSC_DEBUG_MODE2 register:
> > > > +
> > > > + 0: 8191 IPG cycles
> > > > + 1: 4095 IPG cycles
> > > > + 2: 2047 IPG cycles
> > > > + 3: 1023 IPG cycles
> > >
> > > you should use ns
> > > enum:
> > > - 1023
> > > - 2047
> > > - 4095
> > > - 8191
> > >
> > > you can limit only 4 values, but unit have to ns. your driver map it to
> > > register value.
> >
> > Looking at the driver change, I think Dario is already doing that. The
> > text here is just talking about how the controller doesn't support
> > anything other than these 4 glitch threshold and mapping must be done in
> > some way.
>
> Thanks, but descripton is confused.
> "Unlike the generic property defined in touchscreen.yaml", which let me
> think value is 0..3, instead of ns.
>
> Suggest Remove
>
> "Unlike the generic property defined in touchscreen.yaml, this
> controller does not allow arbitrary values"
Yeah, I agree this should be removed. It's unlikely that /any/
touchscreen will support completely arbitrary values, so stating it is
redundant.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v10 5/6] power: supply: pf1550: add battery charger support
From: Sebastian Reichel @ 2025-09-16 18:15 UTC (permalink / raw)
To: samuel.kayode
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Dmitry Torokhov, Frank Li, imx,
devicetree, linux-kernel, linux-input, linux-pm, Abel Vesa,
Abel Vesa, Robin Gong, Robin Gong, Enric Balletbo i Serra,
Sean Nyekjaer, Christophe JAILLET
In-Reply-To: <20250820-pf1550-v10-5-4c0b6e4445e3@savoirfairelinux.com>
[-- Attachment #1: Type: text/plain, Size: 23137 bytes --]
Hi,
On Wed, Aug 20, 2025 at 04:44:40PM -0400, Samuel Kayode via B4 Relay wrote:
> From: Samuel Kayode <samuel.kayode@savoirfairelinux.com>
>
> Add support for the battery charger for pf1550 PMIC.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Tested-by: Sean Nyekjaer <sean@geanix.com>
> Signed-off-by: Samuel Kayode <samuel.kayode@savoirfairelinux.com>
> ---
> v9:
> - Fix thermal regulation temperature ranges
> - Fix default thermal regulation temperature
> - Drop unused `data` variable in reg_init
> - Select charger operation mode based on application - suggested by Sean
> v8:
> - Drop PF1550_CHARGER_NAME
> - Drop unnecessary POWER_SUPPLY_STATUS_CHARGING s
> - Replace POWER_SUPPLY_HEALTH_DEAD with POWER_SUPPLY_HEALTH_NO_BATTERY
> - Drop check for charger in delayed_work s
> - Use dev_warn when battery is over-voltage
> - Define two power supplies: charger and battery
> - Use devm_delayed_work_autocancel to automate cleanup and fix race
> condition
> v7:
> - Use reverse christmas tree order
> - Drop unecessary 0 in id table's driver data field
> - Store virqs to avoid reinvoking platform_get_irq in the interrupt
> service routine
> - Drop manufacturer and model global variables
> v6:
> - Drop lock entirely
> - Reverse christmas tree order for variables defined in probe as
> suggested by Frank
> - return pf1550_reg_init
> v5:
> - Drop lock for battery and charger delayed_work
> - More conservative locking in vbus delayed_work
> - Apply lock when setting power supply type during register initialization
> v4:
> - Finish handling of some interrupts in threaded irq handler
> - Use platform_get_irq
> v3:
> - Use struct power_supply_get_battery_info to get constant charge
> voltage if specified
> - Use virqs mapped in MFD driver
> v2:
> - Address feedback from Enric Balletbo Serra
> ---
> drivers/power/supply/Kconfig | 11 +
> drivers/power/supply/Makefile | 1 +
> drivers/power/supply/pf1550-charger.c | 636 ++++++++++++++++++++++++++++++++++
> 3 files changed, 648 insertions(+)
>
> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
> index 79ddb006e2dad6bf96b71ed570a37c006b5f9433..6d0c872edac1f45da314632e671af1aeda4c87b8 100644
> --- a/drivers/power/supply/Kconfig
> +++ b/drivers/power/supply/Kconfig
> @@ -471,6 +471,17 @@ config CHARGER_88PM860X
> help
> Say Y here to enable charger for Marvell 88PM860x chip.
>
> +config CHARGER_PF1550
> + tristate "NXP PF1550 battery charger driver"
> + depends on MFD_PF1550
> + help
> + Say Y to enable support for the NXP PF1550 battery charger.
> + The device is a single cell Li-Ion/Li-Polymer battery charger for
> + portable application.
> +
> + This driver can also be built as a module. If so, the module will be
> + called pf1550-charger.
> +
> config BATTERY_RX51
> tristate "Nokia RX-51 (N900) battery driver"
> depends on TWL4030_MADC
> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
> index 4f5f8e3507f80da02812f0d08c2d81ddff0a272f..7f68380099c59dab71b73120150612a23e16a745 100644
> --- a/drivers/power/supply/Makefile
> +++ b/drivers/power/supply/Makefile
> @@ -64,6 +64,7 @@ obj-$(CONFIG_CHARGER_RT9467) += rt9467-charger.o
> obj-$(CONFIG_CHARGER_RT9471) += rt9471.o
> obj-$(CONFIG_BATTERY_TWL4030_MADC) += twl4030_madc_battery.o
> obj-$(CONFIG_CHARGER_88PM860X) += 88pm860x_charger.o
> +obj-$(CONFIG_CHARGER_PF1550) += pf1550-charger.o
> obj-$(CONFIG_BATTERY_RX51) += rx51_battery.o
> obj-$(CONFIG_AB8500_BM) += ab8500_bmdata.o ab8500_charger.o ab8500_fg.o ab8500_btemp.o ab8500_chargalg.o
> obj-$(CONFIG_CHARGER_CPCAP) += cpcap-charger.o
> diff --git a/drivers/power/supply/pf1550-charger.c b/drivers/power/supply/pf1550-charger.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..2c43cc086a18239b46c73553d73a85a60ba7c41e
> --- /dev/null
> +++ b/drivers/power/supply/pf1550-charger.c
> @@ -0,0 +1,636 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * charger driver for the PF1550
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Robin Gong <yibin.gong@freescale.com>
> + *
> + * Portions Copyright (c) 2025 Savoir-faire Linux Inc.
> + * Samuel Kayode <samuel.kayode@savoirfairelinux.com>
> + */
> +
> +#include <linux/devm-helpers.h>
> +#include <linux/interrupt.h>
> +#include <linux/mfd/pf1550.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/power_supply.h>
> +
> +#define PF1550_DEFAULT_CONSTANT_VOLT 4200000
> +#define PF1550_DEFAULT_MIN_SYSTEM_VOLT 3500000
> +#define PF1550_DEFAULT_THERMAL_TEMP 95
> +#define PF1550_CHARGER_IRQ_NR 5
> +
> +struct pf1550_charger {
> + struct device *dev;
> + const struct pf1550_ddata *pf1550;
> + struct power_supply *charger;
> + struct power_supply *battery;
> + struct delayed_work vbus_sense_work;
> + struct delayed_work chg_sense_work;
> + struct delayed_work bat_sense_work;
> + int virqs[PF1550_CHARGER_IRQ_NR];
> +
> + u32 constant_volt;
> + u32 min_system_volt;
> + u32 thermal_regulation_temp;
> +};
> +
> +static int pf1550_get_charger_state(struct regmap *regmap, int *val)
> +{
> + unsigned int data;
> + int ret;
> +
> + ret = regmap_read(regmap, PF1550_CHARG_REG_CHG_SNS, &data);
> + if (ret < 0)
> + return ret;
> +
> + data &= PF1550_CHG_SNS_MASK;
> +
> + switch (data) {
> + case PF1550_CHG_PRECHARGE:
> + case PF1550_CHG_CONSTANT_CURRENT:
> + case PF1550_CHG_CONSTANT_VOL:
> + case PF1550_CHG_EOC:
> + *val = POWER_SUPPLY_STATUS_CHARGING;
> + break;
> + case PF1550_CHG_DONE:
> + *val = POWER_SUPPLY_STATUS_FULL;
> + break;
> + case PF1550_CHG_TIMER_FAULT:
> + case PF1550_CHG_SUSPEND:
> + *val = POWER_SUPPLY_STATUS_NOT_CHARGING;
> + break;
> + case PF1550_CHG_OFF_INV:
> + case PF1550_CHG_OFF_TEMP:
> + case PF1550_CHG_LINEAR_ONLY:
> + *val = POWER_SUPPLY_STATUS_DISCHARGING;
> + break;
> + default:
> + *val = POWER_SUPPLY_STATUS_UNKNOWN;
> + }
> +
> + return 0;
> +}
> +
> +static int pf1550_get_charge_type(struct regmap *regmap, int *val)
> +{
> + unsigned int data;
> + int ret;
> +
> + ret = regmap_read(regmap, PF1550_CHARG_REG_CHG_SNS, &data);
> + if (ret < 0)
> + return ret;
> +
> + data &= PF1550_CHG_SNS_MASK;
> +
> + switch (data) {
> + case PF1550_CHG_SNS_MASK:
> + *val = POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
> + break;
> + case PF1550_CHG_CONSTANT_CURRENT:
> + case PF1550_CHG_CONSTANT_VOL:
> + case PF1550_CHG_EOC:
> + *val = POWER_SUPPLY_CHARGE_TYPE_FAST;
> + break;
> + case PF1550_CHG_DONE:
> + case PF1550_CHG_TIMER_FAULT:
> + case PF1550_CHG_SUSPEND:
> + case PF1550_CHG_OFF_INV:
> + case PF1550_CHG_BAT_OVER:
> + case PF1550_CHG_OFF_TEMP:
> + case PF1550_CHG_LINEAR_ONLY:
> + *val = POWER_SUPPLY_CHARGE_TYPE_NONE;
> + break;
> + default:
> + *val = POWER_SUPPLY_CHARGE_TYPE_UNKNOWN;
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Supported health statuses:
> + * - POWER_SUPPLY_HEALTH_DEAD
> + * - POWER_SUPPLY_HEALTH_GOOD
> + * - POWER_SUPPLY_HEALTH_OVERVOLTAGE
> + * - POWER_SUPPLY_HEALTH_UNKNOWN
> + */
> +static int pf1550_get_battery_health(struct regmap *regmap, int *val)
> +{
> + unsigned int data;
> + int ret;
> +
> + ret = regmap_read(regmap, PF1550_CHARG_REG_BATT_SNS, &data);
> + if (ret < 0)
> + return ret;
> +
> + data &= PF1550_BAT_SNS_MASK;
> +
> + switch (data) {
> + case PF1550_BAT_NO_DETECT:
> + *val = POWER_SUPPLY_HEALTH_NO_BATTERY;
> + break;
> + case PF1550_BAT_NO_VBUS:
> + case PF1550_BAT_LOW_THAN_PRECHARG:
> + case PF1550_BAT_CHARG_FAIL:
> + case PF1550_BAT_HIGH_THAN_PRECHARG:
> + *val = POWER_SUPPLY_HEALTH_GOOD;
> + break;
> + case PF1550_BAT_OVER_VOL:
> + *val = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
> + break;
> + default:
> + *val = POWER_SUPPLY_HEALTH_UNKNOWN;
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static int pf1550_get_present(struct regmap *regmap, int *val)
> +{
> + unsigned int data;
> + int ret;
> +
> + ret = regmap_read(regmap, PF1550_CHARG_REG_BATT_SNS, &data);
> + if (ret < 0)
> + return ret;
> +
> + data &= PF1550_BAT_SNS_MASK;
> + *val = (data == PF1550_BAT_NO_DETECT) ? 0 : 1;
> +
> + return 0;
> +}
> +
> +static int pf1550_get_online(struct regmap *regmap, int *val)
> +{
> + unsigned int data;
> + int ret;
> +
> + ret = regmap_read(regmap, PF1550_CHARG_REG_VBUS_SNS, &data);
> + if (ret < 0)
> + return ret;
> +
> + *val = (data & PF1550_VBUS_VALID) ? 1 : 0;
> +
> + return 0;
> +}
> +
> +static void pf1550_chg_bat_work(struct work_struct *work)
> +{
> + struct pf1550_charger *chg = container_of(to_delayed_work(work),
> + struct pf1550_charger,
> + bat_sense_work);
> + unsigned int data;
> +
> + if (regmap_read(chg->pf1550->regmap, PF1550_CHARG_REG_BATT_SNS, &data)) {
> + dev_err(chg->dev, "Read BATT_SNS error.\n");
> + return;
> + }
> +
> + switch (data & PF1550_BAT_SNS_MASK) {
> + case PF1550_BAT_NO_VBUS:
> + dev_dbg(chg->dev, "No valid VBUS input.\n");
> + break;
> + case PF1550_BAT_LOW_THAN_PRECHARG:
> + dev_dbg(chg->dev, "VBAT < VPRECHG.LB.\n");
> + break;
> + case PF1550_BAT_CHARG_FAIL:
> + dev_dbg(chg->dev, "Battery charging failed.\n");
> + break;
> + case PF1550_BAT_HIGH_THAN_PRECHARG:
> + dev_dbg(chg->dev, "VBAT > VPRECHG.LB.\n");
> + break;
> + case PF1550_BAT_OVER_VOL:
> + dev_dbg(chg->dev, "VBAT > VBATOV.\n");
> + break;
> + case PF1550_BAT_NO_DETECT:
> + dev_dbg(chg->dev, "Battery not detected.\n");
> + break;
> + default:
> + dev_err(chg->dev, "Unknown value read:%x\n",
> + data & PF1550_CHG_SNS_MASK);
> + }
> +}
> +
> +static void pf1550_chg_chg_work(struct work_struct *work)
> +{
> + struct pf1550_charger *chg = container_of(to_delayed_work(work),
> + struct pf1550_charger,
> + chg_sense_work);
> + unsigned int data;
> +
> + if (regmap_read(chg->pf1550->regmap, PF1550_CHARG_REG_CHG_SNS, &data)) {
> + dev_err(chg->dev, "Read CHG_SNS error.\n");
> + return;
> + }
> +
> + switch (data & PF1550_CHG_SNS_MASK) {
> + case PF1550_CHG_PRECHARGE:
> + dev_dbg(chg->dev, "In pre-charger mode.\n");
> + break;
> + case PF1550_CHG_CONSTANT_CURRENT:
> + dev_dbg(chg->dev, "In fast-charge constant current mode.\n");
> + break;
> + case PF1550_CHG_CONSTANT_VOL:
> + dev_dbg(chg->dev, "In fast-charge constant voltage mode.\n");
> + break;
> + case PF1550_CHG_EOC:
> + dev_dbg(chg->dev, "In EOC mode.\n");
> + break;
> + case PF1550_CHG_DONE:
> + dev_dbg(chg->dev, "In DONE mode.\n");
> + break;
> + case PF1550_CHG_TIMER_FAULT:
> + dev_info(chg->dev, "In timer fault mode.\n");
> + break;
> + case PF1550_CHG_SUSPEND:
> + dev_info(chg->dev, "In thermistor suspend mode.\n");
> + break;
> + case PF1550_CHG_OFF_INV:
> + dev_info(chg->dev, "Input invalid, charger off.\n");
> + break;
> + case PF1550_CHG_BAT_OVER:
> + dev_warn(chg->dev, "Battery over-voltage.\n");
> + break;
> + case PF1550_CHG_OFF_TEMP:
> + dev_info(chg->dev, "Temp high, charger off.\n");
> + break;
> + case PF1550_CHG_LINEAR_ONLY:
> + dev_dbg(chg->dev, "In Linear mode, not charging.\n");
> + break;
> + default:
> + dev_err(chg->dev, "Unknown value read:%x\n",
> + data & PF1550_CHG_SNS_MASK);
> + }
> +}
> +
> +static void pf1550_chg_vbus_work(struct work_struct *work)
> +{
> + struct pf1550_charger *chg = container_of(to_delayed_work(work),
> + struct pf1550_charger,
> + vbus_sense_work);
> + unsigned int data;
> +
> + if (regmap_read(chg->pf1550->regmap, PF1550_CHARG_REG_VBUS_SNS, &data)) {
> + dev_err(chg->dev, "Read VBUS_SNS error.\n");
> + return;
> + }
> +
> + if (data & PF1550_VBUS_UVLO) {
> + dev_dbg(chg->dev, "VBUS detached.\n");
> + power_supply_changed(chg->battery);
> + }
> + if (data & PF1550_VBUS_IN2SYS)
> + dev_dbg(chg->dev, "VBUS_IN2SYS_SNS.\n");
> + if (data & PF1550_VBUS_OVLO)
> + dev_dbg(chg->dev, "VBUS_OVLO_SNS.\n");
> + if (data & PF1550_VBUS_VALID) {
> + dev_dbg(chg->dev, "VBUS attached.\n");
> + power_supply_changed(chg->charger);
> + }
> +}
> +
> +static irqreturn_t pf1550_charger_irq_handler(int irq, void *data)
> +{
> + struct pf1550_charger *chg = data;
> + struct device *dev = chg->dev;
> + int i, irq_type = -1;
> +
> + for (i = 0; i < PF1550_CHARGER_IRQ_NR; i++)
> + if (irq == chg->virqs[i])
> + irq_type = i;
> +
> + switch (irq_type) {
> + case PF1550_CHARG_IRQ_BAT2SOCI:
> + dev_info(dev, "BAT to SYS Overcurrent interrupt.\n");
> + break;
> + case PF1550_CHARG_IRQ_BATI:
> + schedule_delayed_work(&chg->bat_sense_work,
> + msecs_to_jiffies(10));
> + break;
> + case PF1550_CHARG_IRQ_CHGI:
> + schedule_delayed_work(&chg->chg_sense_work,
> + msecs_to_jiffies(10));
> + break;
> + case PF1550_CHARG_IRQ_VBUSI:
> + schedule_delayed_work(&chg->vbus_sense_work,
> + msecs_to_jiffies(10));
> + break;
> + case PF1550_CHARG_IRQ_THMI:
> + dev_info(dev, "Thermal interrupt.\n");
> + break;
> + default:
> + dev_err(dev, "unknown interrupt occurred.\n");
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static enum power_supply_property pf1550_charger_props[] = {
> + POWER_SUPPLY_PROP_STATUS,
> + POWER_SUPPLY_PROP_CHARGE_TYPE,
> + POWER_SUPPLY_PROP_HEALTH,
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_ONLINE,
> + POWER_SUPPLY_PROP_MODEL_NAME,
> + POWER_SUPPLY_PROP_MANUFACTURER,
> +};
static enum power_supply_property pf1550_charger_props[] = {
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
};
static enum power_supply_property pf1550_battery_props[] = {
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_CHARGE_TYPE,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
};
> +
> +static int pf1550_charger_get_property(struct power_supply *psy,
> + enum power_supply_property psp,
> + union power_supply_propval *val)
> +{
> + struct pf1550_charger *chg = power_supply_get_drvdata(psy);
> + struct regmap *regmap = chg->pf1550->regmap;
> + int ret = 0;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_STATUS:
> + ret = pf1550_get_charger_state(regmap, &val->intval);
> + break;
> + case POWER_SUPPLY_PROP_CHARGE_TYPE:
> + ret = pf1550_get_charge_type(regmap, &val->intval);
> + break;
> + case POWER_SUPPLY_PROP_HEALTH:
> + ret = pf1550_get_battery_health(regmap, &val->intval);
> + break;
> + case POWER_SUPPLY_PROP_PRESENT:
> + ret = pf1550_get_present(regmap, &val->intval);
> + break;
> + case POWER_SUPPLY_PROP_ONLINE:
> + ret = pf1550_get_online(regmap, &val->intval);
> + break;
> + case POWER_SUPPLY_PROP_MODEL_NAME:
> + val->strval = "PF1550";
> + break;
> + case POWER_SUPPLY_PROP_MANUFACTURER:
> + val->strval = "NXP";
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return ret;
> +}
> +
> +static const struct power_supply_desc pf1550_charger_desc = {
> + .name = "pf1550-charger",
> + .type = POWER_SUPPLY_TYPE_MAINS,
> + .properties = pf1550_charger_props,
> + .num_properties = ARRAY_SIZE(pf1550_charger_props),
> + .get_property = pf1550_charger_get_property,
> +};
> +
> +static const struct power_supply_desc pf1550_battery_desc = {
> + .name = "pf1550-battery",
> + .type = POWER_SUPPLY_TYPE_BATTERY,
> + .properties = pf1550_charger_props,
> + .num_properties = ARRAY_SIZE(pf1550_charger_props),
.properties = pf1550_battery_props,
.num_properties = ARRAY_SIZE(pf1550_battery_props),
Otherwise LGTM.
Greetings,
-- Sebastian
> + .get_property = pf1550_charger_get_property,
> +};
> +
> +static int pf1550_set_constant_volt(struct pf1550_charger *chg,
> + unsigned int uvolt)
> +{
> + unsigned int data;
> +
> + if (uvolt >= 3500000 && uvolt <= 4440000)
> + data = 8 + (uvolt - 3500000) / 20000;
> + else
> + return dev_err_probe(chg->dev, -EINVAL,
> + "Wrong value for constant voltage\n");
> +
> + dev_dbg(chg->dev, "Charging constant voltage: %u (0x%x)\n", uvolt,
> + data);
> +
> + return regmap_update_bits(chg->pf1550->regmap,
> + PF1550_CHARG_REG_BATT_REG,
> + PF1550_CHARG_REG_BATT_REG_CHGCV_MASK, data);
> +}
> +
> +static int pf1550_set_min_system_volt(struct pf1550_charger *chg,
> + unsigned int uvolt)
> +{
> + unsigned int data;
> +
> + switch (uvolt) {
> + case 3500000:
> + data = 0x0;
> + break;
> + case 3700000:
> + data = 0x1;
> + break;
> + case 4300000:
> + data = 0x2;
> + break;
> + default:
> + return dev_err_probe(chg->dev, -EINVAL,
> + "Wrong value for minimum system voltage\n");
> + }
> +
> + data <<= PF1550_CHARG_REG_BATT_REG_VMINSYS_SHIFT;
> +
> + dev_dbg(chg->dev, "Minimum system regulation voltage: %u (0x%x)\n",
> + uvolt, data);
> +
> + return regmap_update_bits(chg->pf1550->regmap,
> + PF1550_CHARG_REG_BATT_REG,
> + PF1550_CHARG_REG_BATT_REG_VMINSYS_MASK, data);
> +}
> +
> +static int pf1550_set_thermal_regulation_temp(struct pf1550_charger *chg,
> + unsigned int cells)
> +{
> + unsigned int data;
> +
> + switch (cells) {
> + case 80:
> + data = 0x0;
> + break;
> + case 95:
> + data = 0x1;
> + break;
> + case 110:
> + data = 0x2;
> + break;
> + case 125:
> + data = 0x3;
> + break;
> + default:
> + return dev_err_probe(chg->dev, -EINVAL,
> + "Wrong value for thermal temperature\n");
> + }
> +
> + data <<= PF1550_CHARG_REG_THM_REG_CNFG_REGTEMP_SHIFT;
> +
> + dev_dbg(chg->dev, "Thermal regulation loop temperature: %u (0x%x)\n",
> + cells, data);
> +
> + return regmap_update_bits(chg->pf1550->regmap,
> + PF1550_CHARG_REG_THM_REG_CNFG,
> + PF1550_CHARG_REG_THM_REG_CNFG_REGTEMP_MASK,
> + data);
> +}
> +
> +/*
> + * Sets charger registers to proper and safe default values.
> + */
> +static int pf1550_reg_init(struct pf1550_charger *chg)
> +{
> + struct power_supply_battery_info *info;
> + struct device *dev = chg->dev;
> + int ret;
> +
> + /* Unmask charger interrupt, mask DPMI and reserved bit */
> + ret = regmap_write(chg->pf1550->regmap, PF1550_CHARG_REG_CHG_INT_MASK,
> + PF1550_CHG_INT_MASK);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Error unmask charger interrupt\n");
> +
> + ret = pf1550_set_constant_volt(chg, chg->constant_volt);
> + if (ret)
> + return ret;
> +
> + ret = pf1550_set_min_system_volt(chg, chg->min_system_volt);
> + if (ret)
> + return ret;
> +
> + ret = pf1550_set_thermal_regulation_temp(chg,
> + chg->thermal_regulation_temp);
> + if (ret)
> + return ret;
> +
> + /*
> + * The PF1550 charger has 3 modes of operation. By default, the charger
> + * is in mode 1; it remains off. Appropriate for applications not using
> + * a battery. The other supported mode is mode 2, the charger is turned
> + * on to charge a battery when present.
> + */
> + if (power_supply_get_battery_info(chg->charger, &info)) {
> + ret = regmap_write(chg->pf1550->regmap,
> + PF1550_CHARG_REG_CHG_OPER,
> + PF1550_CHG_BAT_ON);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Error turn on charger\n");
> + }
> +
> + return 0;
> +}
> +
> +static void pf1550_dt_parse_dev_info(struct pf1550_charger *chg)
> +{
> + struct power_supply_battery_info *info;
> + struct device *dev = chg->dev;
> +
> + if (device_property_read_u32(dev->parent, "nxp,min-system-microvolt",
> + &chg->min_system_volt))
> + chg->min_system_volt = PF1550_DEFAULT_MIN_SYSTEM_VOLT;
> +
> + if (device_property_read_u32(dev->parent,
> + "nxp,thermal-regulation-celsius",
> + &chg->thermal_regulation_temp))
> + chg->thermal_regulation_temp = PF1550_DEFAULT_THERMAL_TEMP;
> +
> + if (power_supply_get_battery_info(chg->charger, &info))
> + chg->constant_volt = PF1550_DEFAULT_CONSTANT_VOLT;
> + else
> + chg->constant_volt = info->constant_charge_voltage_max_uv;
> +}
> +
> +static int pf1550_charger_probe(struct platform_device *pdev)
> +{
> + const struct pf1550_ddata *pf1550 = dev_get_drvdata(pdev->dev.parent);
> + struct power_supply_config psy_cfg = {};
> + struct pf1550_charger *chg;
> + int i, irq, ret;
> +
> + chg = devm_kzalloc(&pdev->dev, sizeof(*chg), GFP_KERNEL);
> + if (!chg)
> + return -ENOMEM;
> +
> + chg->dev = &pdev->dev;
> + chg->pf1550 = pf1550;
> +
> + if (!chg->pf1550->regmap)
> + return dev_err_probe(&pdev->dev, -ENODEV,
> + "failed to get regmap\n");
> +
> + platform_set_drvdata(pdev, chg);
> +
> + ret = devm_delayed_work_autocancel(chg->dev, &chg->vbus_sense_work,
> + pf1550_chg_vbus_work);
> + if (ret)
> + return dev_err_probe(chg->dev, ret,
> + "failed to add vbus sense work\n");
> +
> + ret = devm_delayed_work_autocancel(chg->dev, &chg->chg_sense_work,
> + pf1550_chg_chg_work);
> + if (ret)
> + return dev_err_probe(chg->dev, ret,
> + "failed to add charger sense work\n");
> +
> + ret = devm_delayed_work_autocancel(chg->dev, &chg->bat_sense_work,
> + pf1550_chg_bat_work);
> + if (ret)
> + return dev_err_probe(chg->dev, ret,
> + "failed to add battery sense work\n");
> +
> + for (i = 0; i < PF1550_CHARGER_IRQ_NR; i++) {
> + irq = platform_get_irq(pdev, i);
> + if (irq < 0)
> + return irq;
> +
> + chg->virqs[i] = irq;
> +
> + ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
> + pf1550_charger_irq_handler,
> + IRQF_NO_SUSPEND,
> + "pf1550-charger", chg);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "failed irq request\n");
> + }
> +
> + psy_cfg.drv_data = chg;
> +
> + chg->charger = devm_power_supply_register(&pdev->dev,
> + &pf1550_charger_desc,
> + &psy_cfg);
> + if (IS_ERR(chg->charger))
> + return dev_err_probe(&pdev->dev, PTR_ERR(chg->charger),
> + "failed: power supply register\n");
> +
> + chg->battery = devm_power_supply_register(&pdev->dev,
> + &pf1550_battery_desc,
> + &psy_cfg);
> + if (IS_ERR(chg->battery))
> + return dev_err_probe(&pdev->dev, PTR_ERR(chg->battery),
> + "failed: power supply register\n");
> +
> + pf1550_dt_parse_dev_info(chg);
> +
> + return pf1550_reg_init(chg);
> +}
> +
> +static const struct platform_device_id pf1550_charger_id[] = {
> + { "pf1550-charger", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(platform, pf1550_charger_id);
> +
> +static struct platform_driver pf1550_charger_driver = {
> + .driver = {
> + .name = "pf1550-charger",
> + },
> + .probe = pf1550_charger_probe,
> + .id_table = pf1550_charger_id,
> +};
> +module_platform_driver(pf1550_charger_driver);
> +
> +MODULE_AUTHOR("Robin Gong <yibin.gong@freescale.com>");
> +MODULE_DESCRIPTION("PF1550 charger driver");
> +MODULE_LICENSE("GPL");
>
> --
> 2.50.1
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 4/8] mfd: mc13xxx: Use devm_mfd_add_devices and devm_regmap_add_irq_chip
From: Dmitry Torokhov @ 2025-09-16 18:09 UTC (permalink / raw)
To: Alexander Kurz
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dzmitry Sankouski, Dr. David Alan Gilbert, Heiko Stuebner,
Uwe Kleine-König, devicetree, linux-input, linux-kernel
In-Reply-To: <20250914193723.10544-5-akurz@blala.de>
Hi Alexander,
On Sun, Sep 14, 2025 at 07:37:19PM +0000, Alexander Kurz wrote:
> Use devm_mfd_add_devices() for adding MFD child devices and
> devm_regmap_add_irq_chip() for IRQ chip registration.
>
> This reduces the amount of required cleanup.
>
> Signed-off-by: Alexander Kurz <akurz@blala.de>
> ---
> drivers/mfd/mc13xxx-core.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
> index 920797b806ce..091c9171b2b7 100644
> --- a/drivers/mfd/mc13xxx-core.c
> +++ b/drivers/mfd/mc13xxx-core.c
> @@ -381,7 +381,7 @@ static int mc13xxx_add_subdevice_pdata(struct mc13xxx *mc13xxx,
> if (!cell.name)
> return -ENOMEM;
>
> - return mfd_add_devices(mc13xxx->dev, -1, &cell, 1, NULL, 0,
> + return devm_mfd_add_devices(mc13xxx->dev, -1, &cell, 1, NULL, 0,
> regmap_irq_get_domain(mc13xxx->irq_data));
> }
>
> @@ -455,8 +455,9 @@ int mc13xxx_common_init(struct device *dev)
> mc13xxx->irq_chip.irqs = mc13xxx->irqs;
> mc13xxx->irq_chip.num_irqs = ARRAY_SIZE(mc13xxx->irqs);
>
> - ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq, IRQF_ONESHOT,
> - 0, &mc13xxx->irq_chip, &mc13xxx->irq_data);
> + ret = devm_regmap_add_irq_chip(dev, mc13xxx->regmap, mc13xxx->irq,
> + IRQF_ONESHOT, 0, &mc13xxx->irq_chip,
> + &mc13xxx->irq_data);
> if (ret)
> return ret;
>
> @@ -502,8 +503,6 @@ void mc13xxx_common_exit(struct device *dev)
> {
> struct mc13xxx *mc13xxx = dev_get_drvdata(dev);
>
> - mfd_remove_devices(dev);
> - regmap_del_irq_chip(mc13xxx->irq, mc13xxx->irq_data);
> mutex_destroy(&mc13xxx->lock);
This causes the mutex be destroyed while the sub-devices are still
present. The power button will try to call mc13xxx_lock() and
mc13xxx_unlock() and of mutex debugging is enabled you'll get errors.
I'd remove mutex_destroy() as well (and transitively get rid of
mc13xxx_common_exit()) and then look into getting rid of mc13xxx_lock()
and mc13xxx_unlock() because, as I mentioned in another email, they are
IMO not needed.
But this version of the patch is broken as far as I can tell.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v2 1/1] dt-bindings: input: convert tca8418_keypad.txt to yaml format
From: Frank Li @ 2025-09-16 17:13 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
Convert tca8418_keypad.txt to yaml format.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2
- add TCA8418 to title
---
.../bindings/input/tca8418_keypad.txt | 10 ---
.../devicetree/bindings/input/ti,tca8418.yaml | 61 +++++++++++++++++++
2 files changed, 61 insertions(+), 10 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/tca8418_keypad.txt
create mode 100644 Documentation/devicetree/bindings/input/ti,tca8418.yaml
diff --git a/Documentation/devicetree/bindings/input/tca8418_keypad.txt b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
deleted file mode 100644
index 2551850091678..0000000000000
--- a/Documentation/devicetree/bindings/input/tca8418_keypad.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-This binding is based on the matrix-keymap binding with the following
-changes:
-
-keypad,num-rows and keypad,num-columns are required.
-
-Required properties:
-- compatible: "ti,tca8418"
-- reg: the I2C address
-- interrupts: IRQ line number, should trigger on falling edge
-- linux,keymap: Keys definitions, see keypad-matrix.
diff --git a/Documentation/devicetree/bindings/input/ti,tca8418.yaml b/Documentation/devicetree/bindings/input/ti,tca8418.yaml
new file mode 100644
index 0000000000000..624a1830d0b0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,tca8418.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ti,tca8418.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TCA8418 I2C/SMBus keypad scanner
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,tca8418
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: matrix-keymap.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ keypad@34 {
+ compatible = "ti,tca8418";
+ reg = <0x34>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ keypad,num-rows = <4>;
+ keypad,num-columns = <4>;
+ linux,keymap = < MATRIX_KEY(0x00, 0x01, BTN_0)
+ MATRIX_KEY(0x00, 0x00, BTN_1)
+ MATRIX_KEY(0x01, 0x01, BTN_2)
+ MATRIX_KEY(0x01, 0x00, BTN_3)
+ MATRIX_KEY(0x02, 0x00, BTN_4)
+ MATRIX_KEY(0x00, 0x03, BTN_5)
+ MATRIX_KEY(0x00, 0x02, BTN_6)
+ MATRIX_KEY(0x01, 0x03, BTN_7)
+ MATRIX_KEY(0x01, 0x02, BTN_8)
+ MATRIX_KEY(0x02, 0x02, BTN_9)
+ >;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 4/6] dt-bindings: touchscreen: fsl,imx6ul-tsc: support glitch thresold
From: Frank Li @ 2025-09-16 16:03 UTC (permalink / raw)
To: Conor Dooley
Cc: Dario Binacchi, linux-kernel, linux-amarula, Conor Dooley,
Dmitry Torokhov, Fabio Estevam, Haibo Chen, Krzysztof Kozlowski,
Pengutronix Kernel Team, Rob Herring, Sascha Hauer, Shawn Guo,
devicetree, imx, linux-arm-kernel, linux-input
In-Reply-To: <20250915-tinker-music-03cff49a41a7@spud>
On Mon, Sep 15, 2025 at 06:42:13PM +0100, Conor Dooley wrote:
> On Mon, Sep 15, 2025 at 10:30:26AM -0400, Frank Li wrote:
> > On Sun, Sep 14, 2025 at 07:16:01PM +0200, Dario Binacchi wrote:
> > > Support the touchscreen-glitch-threshold-ns property. Unlike the
> > > generic description in touchscreen.yaml, this controller maps the
> > > provided value to one of four discrete thresholds internally.
> > >
> > > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> > > ---
> > >
> > > (no changes since v1)
> > >
> > > .../input/touchscreen/fsl,imx6ul-tsc.yaml | 15 +++++++++++++++
> > > 1 file changed, 15 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > > index 678756ad0f92..310af56a0be6 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> > > @@ -62,6 +62,21 @@ properties:
> > > description: Number of data samples which are averaged for each read.
> > > enum: [ 1, 4, 8, 16, 32 ]
> > >
> > > + touchscreen-glitch-threshold-ns:
> > > + description: |
> > > + Unlike the generic property defined in touchscreen.yaml, this
> > > + controller does not allow arbitrary values. Internally the value is
> > > + converted to IPG clock cycles and mapped to one of four discrete
> > > + thresholds exposed by the TSC_DEBUG_MODE2 register:
> > > +
> > > + 0: 8191 IPG cycles
> > > + 1: 4095 IPG cycles
> > > + 2: 2047 IPG cycles
> > > + 3: 1023 IPG cycles
> >
> > you should use ns
> > enum:
> > - 1023
> > - 2047
> > - 4095
> > - 8191
> >
> > you can limit only 4 values, but unit have to ns. your driver map it to
> > register value.
>
> Looking at the driver change, I think Dario is already doing that. The
> text here is just talking about how the controller doesn't support
> anything other than these 4 glitch threshold and mapping must be done in
> some way.
Thanks, but descripton is confused.
"Unlike the generic property defined in touchscreen.yaml", which let me
think value is 0..3, instead of ns.
Suggest Remove
"Unlike the generic property defined in touchscreen.yaml, this
controller does not allow arbitrary values"
Frank
>
> > > +
> > > + Any value provided in device tree is converted to cycles and rounded
> > > + up to the next supported threshold, or to 8191 if above 4095.
>
> This seems to be the implementation details of one particular driver,
> and does not belong in a binding.
>
> > > +
> > > required:
> > > - compatible
> > > - reg
> > > --
> > > 2.43.0
> > >
^ permalink raw reply
* Re: [PATCH v3 4/6] dt-bindings: touchscreen: fsl,imx6ul-tsc: support glitch thresold
From: Frank Li @ 2025-09-16 15:55 UTC (permalink / raw)
To: Dario Binacchi
Cc: linux-kernel, linux-amarula, Conor Dooley, Dmitry Torokhov,
Fabio Estevam, Haibo Chen, Krzysztof Kozlowski,
Pengutronix Kernel Team, Rob Herring, Sascha Hauer, Shawn Guo,
devicetree, imx, linux-arm-kernel, linux-input
In-Reply-To: <20250915195335.1710780-5-dario.binacchi@amarulasolutions.com>
On Mon, Sep 15, 2025 at 09:53:06PM +0200, Dario Binacchi wrote:
> Support the touchscreen-glitch-threshold-ns property. Unlike the
> generic description in touchscreen.yaml, this controller maps the
> provided value to one of four discrete thresholds internally.
>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
>
> ---
>
> Changes in v3:
> - Remove the final part of the description that refers to
> implementation details.
>
> .../bindings/input/touchscreen/fsl,imx6ul-tsc.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> index 678756ad0f92..6214d8be5a99 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
> @@ -62,6 +62,18 @@ properties:
> description: Number of data samples which are averaged for each read.
> enum: [ 1, 4, 8, 16, 32 ]
>
> + touchscreen-glitch-threshold-ns:
> + description: |
> + Unlike the generic property defined in touchscreen.yaml, this
> + controller does not allow arbitrary values. Internally the value is
> + converted to IPG clock cycles and mapped to one of four discrete
> + thresholds exposed by the TSC_DEBUG_MODE2 register:
> +
> + 0: 8191 IPG cycles
> + 1: 4095 IPG cycles
> + 2: 2047 IPG cycles
> + 3: 1023 IPG cycles
> +
You have to use ns here. You can caculate in driver to match to closed one.
Frank
> required:
> - compatible
> - reg
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 1/2] Driver: hv: Add CONFIG_HYPERV_VMBUS option
From: Bjorn Helgaas @ 2025-09-16 15:50 UTC (permalink / raw)
To: Mukesh Rathor
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250915234604.3256611-2-mrathor@linux.microsoft.com>
On Mon, Sep 15, 2025 at 04:46:03PM -0700, Mukesh Rathor wrote:
> At present VMBus driver is hinged off of CONFIG_HYPERV which entails
> lot of builtin code and encompasses too much. It's not always clear
> what depends on builtin hv code and what depends on VMBus. Setting
> CONFIG_HYPERV as a module and fudging the Makefile to switch to builtin
> adds even more confusion. VMBus is an independent module and should have
> its own config option. Also, there are scenarios like baremetal dom0/root
> where support is built in with CONFIG_HYPERV but without VMBus. Lastly,
> there are more features coming down that use CONFIG_HYPERV and add more
> dependencies on it.
>
> So, create a fine grained HYPERV_VMBUS option and update Kconfigs for
> dependency on VMBus.
>
> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> # drivers/pci
> ---
> drivers/gpu/drm/Kconfig | 2 +-
> drivers/hid/Kconfig | 2 +-
> drivers/hv/Kconfig | 11 +++++++++--
> drivers/hv/Makefile | 2 +-
> drivers/input/serio/Kconfig | 4 ++--
> drivers/net/hyperv/Kconfig | 2 +-
> drivers/pci/Kconfig | 2 +-
> drivers/scsi/Kconfig | 2 +-
> drivers/uio/Kconfig | 2 +-
> drivers/video/fbdev/Kconfig | 2 +-
> include/asm-generic/mshyperv.h | 8 +++++---
> net/vmw_vsock/Kconfig | 2 +-
> 12 files changed, 25 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index f7ea8e895c0c..58f34da061c6 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"
>
> config DRM_HYPERV
> tristate "DRM Support for Hyper-V synthetic video device"
> - depends on DRM && PCI && HYPERV
> + depends on DRM && PCI && HYPERV_VMBUS
> select DRM_CLIENT_SELECTION
> select DRM_KMS_HELPER
> select DRM_GEM_SHMEM_HELPER
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index a57901203aeb..fe3dc8c0db99 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -1162,7 +1162,7 @@ config GREENASIA_FF
>
> config HID_HYPERV_MOUSE
> tristate "Microsoft Hyper-V mouse driver"
> - depends on HYPERV
> + depends on HYPERV_VMBUS
> help
> Select this option to enable the Hyper-V mouse driver.
>
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index e24f6299c376..29f8637f441a 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -45,18 +45,25 @@ config HYPERV_TIMER
>
> config HYPERV_UTILS
> tristate "Microsoft Hyper-V Utilities driver"
> - depends on HYPERV && CONNECTOR && NLS
> + depends on HYPERV_VMBUS && CONNECTOR && NLS
> depends on PTP_1588_CLOCK_OPTIONAL
> help
> Select this option to enable the Hyper-V Utilities.
>
> config HYPERV_BALLOON
> tristate "Microsoft Hyper-V Balloon driver"
> - depends on HYPERV
> + depends on HYPERV_VMBUS
> select PAGE_REPORTING
> help
> Select this option to enable Hyper-V Balloon driver.
>
> +config HYPERV_VMBUS
> + tristate "Microsoft Hyper-V VMBus driver"
> + depends on HYPERV
> + default HYPERV
> + help
> + Select this option to enable Hyper-V Vmbus driver.
> +
> config MSHV_ROOT
> tristate "Microsoft Hyper-V root partition support"
> depends on HYPERV && (X86_64 || ARM64)
> diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
> index 976189c725dc..4bb41663767d 100644
> --- a/drivers/hv/Makefile
> +++ b/drivers/hv/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_HYPERV) += hv_vmbus.o
> +obj-$(CONFIG_HYPERV_VMBUS) += hv_vmbus.o
> obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
> obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
> obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
> index 17edc1597446..c7ef347a4dff 100644
> --- a/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -276,8 +276,8 @@ config SERIO_OLPC_APSP
>
> config HYPERV_KEYBOARD
> tristate "Microsoft Synthetic Keyboard driver"
> - depends on HYPERV
> - default HYPERV
> + depends on HYPERV_VMBUS
> + default HYPERV_VMBUS
> help
> Select this option to enable the Hyper-V Keyboard driver.
>
> diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
> index c8cbd85adcf9..982964c1a9fb 100644
> --- a/drivers/net/hyperv/Kconfig
> +++ b/drivers/net/hyperv/Kconfig
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config HYPERV_NET
> tristate "Microsoft Hyper-V virtual network driver"
> - depends on HYPERV
> + depends on HYPERV_VMBUS
> select UCS2_STRING
> select NLS
> help
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 9a249c65aedc..7065a8e5f9b1 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -221,7 +221,7 @@ config PCI_LABEL
>
> config PCI_HYPERV
> tristate "Hyper-V PCI Frontend"
> - depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
> + depends on ((X86 && X86_64) || ARM64) && HYPERV_VMBUS && PCI_MSI && SYSFS
> select PCI_HYPERV_INTERFACE
> select IRQ_MSI_LIB
> help
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 5522310bab8d..19d0884479a2 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -589,7 +589,7 @@ config XEN_SCSI_FRONTEND
>
> config HYPERV_STORAGE
> tristate "Microsoft Hyper-V virtual storage driver"
> - depends on SCSI && HYPERV
> + depends on SCSI && HYPERV_VMBUS
> depends on m || SCSI_FC_ATTRS != m
> default HYPERV
> help
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index b060dcd7c635..6f86a61231e6 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -140,7 +140,7 @@ config UIO_MF624
>
> config UIO_HV_GENERIC
> tristate "Generic driver for Hyper-V VMBus"
> - depends on HYPERV
> + depends on HYPERV_VMBUS
> help
> Generic driver that you can bind, dynamically, to any
> Hyper-V VMBus device. It is useful to provide direct access
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index c21484d15f0c..72c63eaeb983 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -1774,7 +1774,7 @@ config FB_BROADSHEET
>
> config FB_HYPERV
> tristate "Microsoft Hyper-V Synthetic Video support"
> - depends on FB && HYPERV
> + depends on FB && HYPERV_VMBUS
> select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
> select FB_IOMEM_HELPERS_DEFERRED
> help
> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
> index dbd4c2f3aee3..64ba6bc807d9 100644
> --- a/include/asm-generic/mshyperv.h
> +++ b/include/asm-generic/mshyperv.h
> @@ -163,6 +163,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
> return guest_id;
> }
>
> +#if IS_ENABLED(CONFIG_HYPERV_VMBUS)
> /* Free the message slot and signal end-of-message if required */
> static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
> {
> @@ -198,6 +199,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
> }
> }
>
> +extern int vmbus_interrupt;
> +extern int vmbus_irq;
> +#endif /* CONFIG_HYPERV_VMBUS */
> +
> int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
>
> void hv_setup_vmbus_handler(void (*handler)(void));
> @@ -211,9 +216,6 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
> void hv_remove_crash_handler(void);
> void hv_setup_mshv_handler(void (*handler)(void));
>
> -extern int vmbus_interrupt;
> -extern int vmbus_irq;
> -
> #if IS_ENABLED(CONFIG_HYPERV)
> /*
> * Hypervisor's notion of virtual processor ID is different from
> diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
> index 56356d2980c8..8e803c4828c4 100644
> --- a/net/vmw_vsock/Kconfig
> +++ b/net/vmw_vsock/Kconfig
> @@ -72,7 +72,7 @@ config VIRTIO_VSOCKETS_COMMON
>
> config HYPERV_VSOCKETS
> tristate "Hyper-V transport for Virtual Sockets"
> - depends on VSOCKETS && HYPERV
> + depends on VSOCKETS && HYPERV_VMBUS
> help
> This module implements a Hyper-V transport for Virtual Sockets.
>
> --
> 2.36.1.vfs.0.0
>
^ permalink raw reply
* Re: (subset) [PATCH v4 4/8] mfd: mc13xxx: Use devm_mfd_add_devices and devm_regmap_add_irq_chip
From: Lee Jones @ 2025-09-16 14:44 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Dzmitry Sankouski, Dr. David Alan Gilbert,
Heiko Stuebner, Uwe Kleine-König, devicetree, linux-input,
Alexander Kurz
Cc: linux-kernel
In-Reply-To: <20250914193723.10544-5-akurz@blala.de>
On Sun, 14 Sep 2025 19:37:19 +0000, Alexander Kurz wrote:
> Use devm_mfd_add_devices() for adding MFD child devices and
> devm_regmap_add_irq_chip() for IRQ chip registration.
>
> This reduces the amount of required cleanup.
>
>
Applied, thanks!
[4/8] mfd: mc13xxx: Use devm_mfd_add_devices and devm_regmap_add_irq_chip
commit: c5f395868781099e54a220bd5d6dc60c698c8c72
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v14 00/10] Add support for MAX7360
From: Lee Jones @ 2025-09-16 14:35 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kamel Bouhara,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov,
Uwe Kleine-König, Michael Walle, Mark Brown,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mathieu Dubois-Briand
Cc: devicetree, linux-kernel, linux-gpio, linux-input, linux-pwm,
andriy.shevchenko, Grégory Clement, Thomas Petazzoni,
Krzysztof Kozlowski, Andy Shevchenko, Bartosz Golaszewski
In-Reply-To: <175803329065.3832522.18087850599111439891.b4-ty@kernel.org>
On Tue, 16 Sep 2025, Lee Jones wrote:
> On Sun, 24 Aug 2025 13:57:19 +0200, Mathieu Dubois-Briand wrote:
> > This series implements a set of drivers allowing to support the Maxim
> > Integrated MAX7360 device.
> >
> > The MAX7360 is an I2C key-switch and led controller, with following
> > functionalities:
> > - Keypad controller for a key matrix of up to 8 rows and 8 columns.
> > - Rotary encoder support, for a single rotary encoder.
> > - Up to 8 PWM outputs.
> > - Up to 8 GPIOs with support for interrupts and 6 GPOs.
> >
> > [...]
>
> Applied, thanks!
>
> [01/10] dt-bindings: mfd: gpio: Add MAX7360
> commit: aee814458fb98819876442f0261fad0bb9842224
> [02/10] mfd: Add max7360 support
> commit: a22ddeef55c4df847d9ac862b6192da774948fe1
> [03/10] pinctrl: Add MAX7360 pinctrl driver
> commit: b4b993c0e39436ffb3a9b21cabf62b5df085b2e1
> [04/10] pwm: max7360: Add MAX7360 PWM support
> commit: d93a75d94b79ba3e664f7236ee05790e8b1d0e4b
> [05/10] gpio: regmap: Allow to allocate regmap-irq device
> commit: 553b75d4bfe9264f631d459fe9996744e0672b0e
> [06/10] gpio: regmap: Allow to provide init_valid_mask callback
> commit: 0627b71fa5508ab605b6e9fd74baed40805cfdda
> [07/10] gpio: max7360: Add MAX7360 gpio support
> commit: b1a7433d857edb14b993161af9ed1ee98d4c9cee
> [08/10] input: keyboard: Add support for MAX7360 keypad
> commit: fa6a23f1c59c67de9160b4acc5a8651ad2106fa8
> [09/10] input: misc: Add support for MAX7360 rotary
> commit: 229c15e9a69cb3d6a303a9e20b10fb991b66895d
> [10/10] MAINTAINERS: Add entry on MAX7360 driver
> commit: 32d4cedd24ed346edbe063323ed495d685e033df
Send for build testing. If all is well, I'll submit a PR shortly.
Note to self: ib-mfd-gpio-input-pinctrl-pwm-6.18
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v14 00/10] Add support for MAX7360
From: Lee Jones @ 2025-09-16 14:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kamel Bouhara, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Uwe Kleine-König, Michael Walle, Mark Brown,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mathieu Dubois-Briand
Cc: devicetree, linux-kernel, linux-gpio, linux-input, linux-pwm,
andriy.shevchenko, Grégory Clement, Thomas Petazzoni,
Krzysztof Kozlowski, Andy Shevchenko, Bartosz Golaszewski
In-Reply-To: <20250824-mdb-max7360-support-v14-0-435cfda2b1ea@bootlin.com>
On Sun, 24 Aug 2025 13:57:19 +0200, Mathieu Dubois-Briand wrote:
> This series implements a set of drivers allowing to support the Maxim
> Integrated MAX7360 device.
>
> The MAX7360 is an I2C key-switch and led controller, with following
> functionalities:
> - Keypad controller for a key matrix of up to 8 rows and 8 columns.
> - Rotary encoder support, for a single rotary encoder.
> - Up to 8 PWM outputs.
> - Up to 8 GPIOs with support for interrupts and 6 GPOs.
>
> [...]
Applied, thanks!
[01/10] dt-bindings: mfd: gpio: Add MAX7360
commit: aee814458fb98819876442f0261fad0bb9842224
[02/10] mfd: Add max7360 support
commit: a22ddeef55c4df847d9ac862b6192da774948fe1
[03/10] pinctrl: Add MAX7360 pinctrl driver
commit: b4b993c0e39436ffb3a9b21cabf62b5df085b2e1
[04/10] pwm: max7360: Add MAX7360 PWM support
commit: d93a75d94b79ba3e664f7236ee05790e8b1d0e4b
[05/10] gpio: regmap: Allow to allocate regmap-irq device
commit: 553b75d4bfe9264f631d459fe9996744e0672b0e
[06/10] gpio: regmap: Allow to provide init_valid_mask callback
commit: 0627b71fa5508ab605b6e9fd74baed40805cfdda
[07/10] gpio: max7360: Add MAX7360 gpio support
commit: b1a7433d857edb14b993161af9ed1ee98d4c9cee
[08/10] input: keyboard: Add support for MAX7360 keypad
commit: fa6a23f1c59c67de9160b4acc5a8651ad2106fa8
[09/10] input: misc: Add support for MAX7360 rotary
commit: 229c15e9a69cb3d6a303a9e20b10fb991b66895d
[10/10] MAINTAINERS: Add entry on MAX7360 driver
commit: 32d4cedd24ed346edbe063323ed495d685e033df
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Mavroudis Chatzilazaridis @ 2025-09-16 14:05 UTC (permalink / raw)
To: Stuart; +Cc: jikos, linux-input, hadess, lains, benjamin.tissoires
In-Reply-To: <CALTg27kat6CReAvU8nXsVzqKEtzytT+_wf9dZ07OFSke=ipYLQ@mail.gmail.com>
On 2025-09-16 15:30, Stuart wrote:
>> Can you also try the following on top of v4?
>
> Working just as well as the previous patch, compiled on top of the
> latest hid.git
Great!
>> Please test this one thoroughly (modifiers, lock keys, ISO backslash/
>> Intl keys) as I've modified the keyboard report descriptor.
>
> Tested every key and alternate key shown, modifier keys, function keys,
> media keys, lock keys. All working, including the battery reporting.
> I don't really know what you mean by ISO backslash or international keys,
> but the backslash on my UK layout works just fine.
Yes, the UK slash key is what I had in mind. It is only present on ISO
layout keyboards, the UK layout being ISO. I wasn't sure what layout
your keyboard was.
>> If this works as well, I will submit a v5, and you can send a Tested-by
>> on that one.
>
> Sure
>
> I'm heading back to uni in a few days, so I might not be able to test
> revisions as quickly, but I'm still happy to test anything that's required.
Thanks a lot, I appreciate all the help. Good luck with your studies!
>
> Thanks,
> Stuart
^ permalink raw reply
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Stuart @ 2025-09-16 12:30 UTC (permalink / raw)
To: Mavroudis Chatzilazaridis
Cc: jikos, linux-input, hadess, lains, benjamin.tissoires
In-Reply-To: <7a4c4678-bb75-4aa7-8f4f-706deba7e72b@protonmail.com>
> Can you also try the following on top of v4?
Working just as well as the previous patch, compiled on top of the
latest hid.git
> Please test this one thoroughly (modifiers, lock keys, ISO backslash/
> Intl keys) as I've modified the keyboard report descriptor.
Tested every key and alternate key shown, modifier keys, function keys,
media keys, lock keys. All working, including the battery reporting.
I don't really know what you mean by ISO backslash or international keys,
but the backslash on my UK layout works just fine.
> If this works as well, I will submit a v5, and you can send a Tested-by
> on that one.
Sure
I'm heading back to uni in a few days, so I might not be able to test
revisions as quickly, but I'm still happy to test anything that's required.
Thanks,
Stuart
^ permalink raw reply
* Re: [PATCH RESEND v5 0/7] Input: synaptics-rmi4 - add quirks for third party touchscreen controllers
From: David Heidelberg @ 2025-09-16 9:29 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Kaustabh Chakraborty, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, linux-input, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Casey Connolly, Krzysztof Kozlowski
In-Reply-To: <aggtzmlxvj4so6t7trlo5ianjcbq2jrsodv6hlkhtrvgl2qpqj@gflvqocxjckb>
On 07/08/2025 06:29, Dmitry Torokhov wrote:
> Hi David,
>
> On Thu, Jul 31, 2025 at 11:06:50PM +0200, David Heidelberg via B4 Relay wrote:
>> With the growing popularity of running upstream Linux on mobile devices,
>> we're beginning to run into more and more edgecases. The OnePlus 6 is a
>> fairly well supported 2018 era smartphone, selling over a million units
>> in it's first 22 days. With this level of popularity, it's almost
>> inevitable that we get third party replacement displays, and as a
>> result, replacement touchscreen controllers.
>>
>> The OnePlus 6 shipped with an extremely usecase specific touchscreen
>> driver, it implemented only the bare minimum parts of the highly generic
>> rmi4 protocol, instead hardcoding most of the register addresses.
>>
>> As a result, the third party touchscreen controllers that are often
>> found in replacement screens, implement only the registers that the
>> downstream driver reads from. They additionally have other restrictions
>> such as heavy penalties on unaligned reads.
>>
>> This series attempts to implement the necessary workaround to support
>> some of these chips with the rmi4 driver. Although it's worth noting
>> that at the time of writing there are other unofficial controllers in
>> the wild that don't work even with these patches.
>>
>> We have been shipping these patches in postmarketOS for the last several
>> years, and they are known to not cause any regressions on the OnePlus
>> 6/6T (with the official Synaptics controller), however I don't own any
>> other rmi4 hardware to further validate this.
>
> Sorry for not handling the patches in the last few submissions. I am
> planning on addressing them once merge window opens.
Hello Dmitry, kind reminder about the patch series as the window is open.
If you'll find a time, there is also one small, but important patchset
improving the Linux phones/tablets experience here:
https://patchwork.kernel.org/project/linux-input/list/?series=987495&state=*&archive=both
David
>
> Thanks.
>
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Resolve touchpad issues on Dell systems during S4
From: Benjamin Tissoires @ 2025-09-16 8:26 UTC (permalink / raw)
To: mario.limonciello, jikos, Mario Limonciello (AMD); +Cc: linux-input
In-Reply-To: <20250909110012.1218226-1-superm1@kernel.org>
On Tue, 09 Sep 2025 06:00:06 -0500, Mario Limonciello (AMD) wrote:
> Dell systems utilize an EC-based touchpad emulation when the ACPI
> touchpad _DSM is not invoked. This emulation acts as a secondary
> master on the I2C bus, designed for scenarios where the I2C touchpad
> driver is absent, such as in BIOS menus. Typically, loading the
> i2c-hid module triggers the _DSM at initialization, disabling the
> EC-based emulation.
>
> [...]
Applied to hid/hid.git (for-6.18/i2c-hid), thanks!
[1/1] HID: i2c-hid: Resolve touchpad issues on Dell systems during S4
https://git.kernel.org/hid/hid/c/7d62beb102d6
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Mavroudis Chatzilazaridis @ 2025-09-16 7:09 UTC (permalink / raw)
To: Stuart; +Cc: jikos, linux-input, hadess, lains, benjamin.tissoires
In-Reply-To: <CALTg27mH1rzyaNXEq7SowZcVYMiWUgejQCFgdDCHACUm9j+3SQ@mail.gmail.com>
On 2025-09-10 02:24, Stuart wrote:
> Yep, this on top of the v4 patch works as expected.
I'm glad to hear it.
> Thank you for getting this working.
Thank you for taking the time to test all this.
> Tested-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
>
> Thanks,
> Stuart
I thought about it a bit more and came up with another solution that I
believe is the correct way of approaching this. Can you also try the
following on top of v4?
Please test this one thoroughly (modifiers, lock keys, ISO backslash/
Intl keys) as I've modified the keyboard report descriptor.
If this works as well, I will submit a v5, and you can send a Tested-by
on that one.
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 00a975b70f59..6d3733dde1e8 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -226,17 +226,7 @@ static const char kbd_lightspeed_1_3_descriptor[] = {
0x75, 0x01, /* Report Size (1) */
0x95, 0x08, /* Report Count (8) */
0x81, 0x02, /* Input (Data,Var) */
- 0x95, 0x05, /* Report Count (5) */
- 0x05, 0x08, /* Usage Page (LEDs) */
- 0x19, 0x01, /* Usage Minimum (Num Lock) */
- 0x29, 0x05, /* Usage Maximum (Kana) */
- 0x91, 0x02, /* Output (Data,Var,Abs) */
- 0x95, 0x01, /* Report Count (1) */
- 0x75, 0x03, /* Report Size (3) */
- 0x91, 0x03, /* Output (Const,Var,Abs) */
0x95, 0x70, /* Report Count (112) */
- 0x75, 0x01, /* Report Size (1) */
- 0x05, 0x07, /* Usage Page (Kbrd/Keypad) */
0x19, 0x04, /* Usage Minimum (0x04) */
0x29, 0x73, /* Usage Maximum (0x73) */
0x81, 0x02, /* Input (Data,Var,Abs) */
@@ -248,6 +238,15 @@ static const char kbd_lightspeed_1_3_descriptor[] = {
0x19, 0x90, /* Usage Minimum (0x90) */
0x29, 0x92, /* Usage Maximum (0x92) */
0x81, 0x02, /* Input (Data,Var,Abs) */
+ 0x95, 0x05, /* Report Count (5) */
+ 0x85, 0x0E, /* Report ID (14) */
+ 0x05, 0x08, /* Usage Page (LEDs) */
+ 0x19, 0x01, /* Usage Minimum (Num Lock) */
+ 0x29, 0x05, /* Usage Maximum (Kana) */
+ 0x91, 0x02, /* Output (Data,Var,Abs) */
+ 0x95, 0x01, /* Report Count (1) */
+ 0x75, 0x03, /* Report Size (3) */
+ 0x91, 0x03, /* Output (Const,Var,Abs) */
0xC0, /* End Collection */
};
@@ -1459,12 +1458,19 @@ static int logi_dj_ll_raw_request(struct hid_device *hid,
return -EINVAL;
if (djrcv_dev->type != recvr_type_dj && count >= 2) {
+ unsigned char led_report_id = 0;
+
if (!djrcv_dev->keyboard) {
hid_warn(hid, "Received REPORT_TYPE_LEDS request before the keyboard interface was enumerated\n");
return 0;
}
+
+ /* This Lightspeed receiver expects LED reports with report ID 1 */
+ if (djrcv_dev->type == recvr_type_gaming_hidpp_ls_1_3)
+ led_report_id = 1;
+
/* usbhid overrides the report ID and ignores the first byte */
- return hid_hw_raw_request(djrcv_dev->keyboard, 0, buf, count,
+ return hid_hw_raw_request(djrcv_dev->keyboard, led_report_id, buf, count,
report_type, reqtype);
}
^ permalink raw reply related
* Hiring Linux Gurus for Next Microsoft/Apple Now!
From: info @ 2025-09-16 5:15 UTC (permalink / raw)
To: linux-kernel, linux-arch, linux-input, linux-hotplug
In-Reply-To: <ec28ecc24919963b2e5f9edd77e55262@unitedcomputing.tech>
Dear Linux experts/developers,
We are AGGRESSIVELY HIRING a team of Linux gurus for our business United
Computing Inc., most promising like next Microsoft/Apple, to own and
build our Linux platforms like ZorinOS & Ubuntu and dominate
mobile/desktop/embedded/workstation/server/cloud or all computing
domains with Linux existing domination over all domains except for
shrinking Windows desktop computing, and our LinuxAll innovations for
work & play in any pose/time/place and replacing today's
phones/tablets/PCs/gaming/AR/VR devices. LinuxAll includes XR glasses
for multiple virtual screens/windows, physical or virtual
keyboards/multi-touch/3D inputs, Linux gaming computer tablet phones,
and optional power banks, etc. These addictive products will hit the
market like iPhone 1+ for sure. We own this top tech innovation since
mid 2008 out of our AR/VR research and the disrupted PC industry by the
release of iPhone with small screen and limited OS/inputs. Tech giants
built their XR products but all failed, and can't steal them from us due
to cross competitions, let alone others. LinuxAll Gen 1/2 products,
especially many Birdbath and Waveguide AR glasses, are on sale at
https://www.unitedcomputing.org/shop.
Below is a list of our LinuxAll components and products:
1) Birdbath XR Glasses: Legion Glasses 2, Rayneo Air 3s Pro, Viture Luma
XR, Xreal One Pro/Air 2 Ultra/Pro, Rokid AR Lite, StarV View, InAir 2
Pro
2) Waveguide XR Glasses: Inmo Air 3, Rayneo X3 Pro, Oppo Air Glass 3,
Rokid Glasses, Orion AR, Myvu Discovery, Lumus Optical, Cellid, PVG,
JioGlass, Mirza AR, StarV Air2
3) Mini Gaming PCs: Legion Go, Ling Long Foldable Keyboard PC, Khadas
Mind 2, Rog Ally, Steam Deck, OneXPlayer 2 Pro, GPD WIN4, Ayaneo, Mini
PCs, etc.
4) Computer Phones: 5.5'/6'/6.5'/7'/8' rugged gaming phone tablet PCs
from Sincoole, rugged-pda, njynwei, and MactronGroup
5) Physical/virtual Inputs: Foldable/mini/projection keyboards, TapXR
wearable keyboard, and Leap Motion or XR cameras based virtual inputs
6) Laptop Power Banks: Psooo 65w 5/80k power bank, Zkpilse 65w 50k power
bank, offgrid power products, etc.
It's critical and necessary for our business to own and build our OS
platforms, otherwise there will be endless US/world crisis and huge
fights over this matter that must be settled ASAP. As the WinAll deal
with Microsoft and $1 billion for ZorinOS & Ubuntu acquisition aren't
there, we are contacting Linux developer communities to own and build
our Linux platforms together instead. Our Linux developers will match
employees building Ubuntu & ZorinOS with various job functions. They
will add the HCI and system components/features for
phone/tablet/PC/gaming/AR/VR convergence, new XR/AI features matching
new hardware/devices, and our Linux platforms to dominate all computing
domains. They will build core apps, tools, frameworks, etc. for our
Linux platforms too. OS businesses are quite mature and crowded so we
shall be able to absorb abundant Linux resources soon. By leveraging
abundant PC/mobile hardware/chip vendor resources, we don't need to
invest a lot in our Linux & LinuxAll ownership and development as well.
Interested candidates please email us their resumes and roles at
info@unitedcomputing.tech ASAP or contact us for any question. This is
really a great opportunity for Linux to defeat Windows/MacOS/Android/iOS
and dominate/shine for ever. The sooner you join us, the sooner we go
big together!
More information:
https://www.facebook.com/marketplace/profile/100095444238325/
https://www.unitedcomputing.org/linuxall > UCPitchDeck.pdf
https://b23.tv/9h73RDV
Thanks & Regards,
Shirley Zhou
Founder & CEO
United Computing Inc.
https://www.unitedcomputing.org
Phone/WhatsApp: +1 9096309408
Email: info@unitedcomputing.tech
Address: 6203 San Ignacio Ave Ste 110, San Jose, CA, USA, 95119
^ permalink raw reply
* [PATCH v2] HID: cp2112: Add parameter validation to data length
From: Deepak Sharma @ 2025-09-16 5:10 UTC (permalink / raw)
To: jikos
Cc: linux-input, linux-kernel, linux-kernel-mentees, Deepak Sharma,
syzbot+7617e19c8a59edfbd879
This is v2 for the earlier patch, where a few bounds check were
unnecessarily strict. This patch also removes the use of magic numbers
Syzkaller reported a stack OOB access in cp2112_write_req caused by lack
of parameter validation for the user input in I2C SMBUS ioctl codeflow
in the report
I2C device drivers are "responsible for checking all the parameters that
come from user-space for validity" as specified at Documentation/i2c/dev-interface
Add the parameter validation for the data->block[0] to be bounded by
I2C_SMBUS_BLOCK_MAX + the additional compatibility padding
Reported-by: syzbot+7617e19c8a59edfbd879@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7617e19c8a59edfbd879
Signed-off-by: Deepak Sharma <deepak.sharma.472935@gmail.com>
---
drivers/hid/hid-cp2112.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index 482f62a78c41..13dcd2470d92 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -689,7 +689,14 @@ static int cp2112_xfer(struct i2c_adapter *adap, u16 addr,
count = cp2112_write_read_req(buf, addr, read_length,
command, NULL, 0);
} else {
- count = cp2112_write_req(buf, addr, command,
+ /* Copy starts from data->block[1] so the length can
+ * be at max I2C_SMBUS_CLOCK_MAX + 1
+ */
+
+ if (data->block[0] > I2C_SMBUS_BLOCK_MAX + 1)
+ count = -EINVAL;
+ else
+ count = cp2112_write_req(buf, addr, command,
data->block + 1,
data->block[0]);
}
@@ -700,7 +707,14 @@ static int cp2112_xfer(struct i2c_adapter *adap, u16 addr,
I2C_SMBUS_BLOCK_MAX,
command, NULL, 0);
} else {
- count = cp2112_write_req(buf, addr, command,
+ /* data_length here is data->block[0] + 1
+ * so make sure that the data->block[0] is
+ * less than or equals I2C_SMBUS_BLOCK_MAX + 1
+ */
+ if (data->block[0] > I2C_SMBUS_BLOCK_MAX + 1)
+ count = -EINVAL;
+ else
+ count = cp2112_write_req(buf, addr, command,
data->block,
data->block[0] + 1);
}
@@ -709,7 +723,14 @@ static int cp2112_xfer(struct i2c_adapter *adap, u16 addr,
size = I2C_SMBUS_BLOCK_DATA;
read_write = I2C_SMBUS_READ;
- count = cp2112_write_read_req(buf, addr, I2C_SMBUS_BLOCK_MAX,
+ /* data_length is data->block[0] + 1, so
+ * so data->block[0] should be less than or
+ * equal to the I2C_SMBUS_BLOCK_MAX + 1
+ */
+ if (data->block[0] > I2C_SMBUS_BLOCK_MAX + 1)
+ count = -EINVAL;
+ else
+ count = cp2112_write_read_req(buf, addr, I2C_SMBUS_BLOCK_MAX,
command, data->block,
data->block[0] + 1);
break;
--
2.51.0
^ permalink raw reply related
* [PATCH v3] hid: intel-thc-hid: intel-quicki2c: support ACPI config for advanced features
From: Xinpeng Sun @ 2025-09-16 2:57 UTC (permalink / raw)
To: jikos, bentiss
Cc: srinivas.pandruvada, linux-input, linux-kernel, even.xu,
Xinpeng Sun, Rui Zhang
There is a new BIOS enhancement that adds the capability to configure the
following two features of I2C subsystem introduced in commit 1ed0b48
("Intel-thc: Introduce max input size control") and commit 3f2a921
("Intel-thc: Introduce interrupt delay control"):
- Max input size control
- Interrupt delay control
As BIOS is used for the configuration of these two features, change driver
data usage to indicate hardware capability, and add corresponding ACPI
configuration support in QuickI2C driver.
Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com>
Tested-by: Rui Zhang <rui1.zhang@intel.com>
---
.../intel-quicki2c/pci-quicki2c.c | 39 +++++++++++++++----
.../intel-quicki2c/quicki2c-dev.h | 24 +++++++++++-
2 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
index 854926b3cfd4..3ce5a692b92b 100644
--- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
+++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
@@ -23,6 +23,7 @@
static struct quicki2c_ddata ptl_ddata = {
.max_detect_size = MAX_RX_DETECT_SIZE_PTL,
+ .max_interrupt_delay = MAX_RX_INTERRUPT_DELAY,
};
/* THC QuickI2C ACPI method to get device properties */
@@ -200,6 +201,21 @@ static int quicki2c_get_acpi_resources(struct quicki2c_device *qcdev)
return -EOPNOTSUPP;
}
+ if (qcdev->ddata) {
+ qcdev->i2c_max_frame_size_enable = i2c_config.FSEN;
+ qcdev->i2c_int_delay_enable = i2c_config.INDE;
+
+ if (i2c_config.FSVL <= qcdev->ddata->max_detect_size)
+ qcdev->i2c_max_frame_size = i2c_config.FSVL;
+ else
+ qcdev->i2c_max_frame_size = qcdev->ddata->max_detect_size;
+
+ if (i2c_config.INDV <= qcdev->ddata->max_interrupt_delay)
+ qcdev->i2c_int_delay = i2c_config.INDV;
+ else
+ qcdev->i2c_int_delay = qcdev->ddata->max_interrupt_delay;
+ }
+
return 0;
}
@@ -441,17 +457,24 @@ static void quicki2c_dma_adv_enable(struct quicki2c_device *qcdev)
* max input length <= THC detect capability, enable the feature with device
* max input length.
*/
- if (qcdev->ddata->max_detect_size >=
- le16_to_cpu(qcdev->dev_desc.max_input_len)) {
- thc_i2c_set_rx_max_size(qcdev->thc_hw,
- le16_to_cpu(qcdev->dev_desc.max_input_len));
+ if (qcdev->i2c_max_frame_size_enable) {
+ if (qcdev->i2c_max_frame_size >=
+ le16_to_cpu(qcdev->dev_desc.max_input_len)) {
+ thc_i2c_set_rx_max_size(qcdev->thc_hw,
+ le16_to_cpu(qcdev->dev_desc.max_input_len));
+ } else {
+ dev_warn(qcdev->dev,
+ "Max frame size is smaller than hid max input length!");
+ thc_i2c_set_rx_max_size(qcdev->thc_hw,
+ le16_to_cpu(qcdev->i2c_max_frame_size));
+ }
thc_i2c_rx_max_size_enable(qcdev->thc_hw, true);
}
/* If platform supports interrupt delay feature, enable it with given delay */
- if (qcdev->ddata->interrupt_delay) {
+ if (qcdev->i2c_int_delay_enable) {
thc_i2c_set_rx_int_delay(qcdev->thc_hw,
- qcdev->ddata->interrupt_delay);
+ qcdev->i2c_int_delay * 10);
thc_i2c_rx_int_delay_enable(qcdev->thc_hw, true);
}
}
@@ -464,10 +487,10 @@ static void quicki2c_dma_adv_enable(struct quicki2c_device *qcdev)
*/
static void quicki2c_dma_adv_disable(struct quicki2c_device *qcdev)
{
- if (qcdev->ddata->max_detect_size)
+ if (qcdev->i2c_max_frame_size_enable)
thc_i2c_rx_max_size_enable(qcdev->thc_hw, false);
- if (qcdev->ddata->interrupt_delay)
+ if (qcdev->i2c_int_delay_enable)
thc_i2c_rx_int_delay_enable(qcdev->thc_hw, false);
}
diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
index d412eafcf9ea..0d423d5dd7a7 100644
--- a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
+++ b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
@@ -38,6 +38,8 @@
/* PTL Max packet size detection capability is 255 Bytes */
#define MAX_RX_DETECT_SIZE_PTL 255
+/* Max interrupt delay capability is 2.56ms */
+#define MAX_RX_INTERRUPT_DELAY 256
/* Default interrupt delay is 1ms, suitable for most devices */
#define DEFAULT_INTERRUPT_DELAY_US (1 * USEC_PER_MSEC)
@@ -101,6 +103,10 @@ struct quicki2c_subip_acpi_parameter {
* @HMTD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line Transmit HOLD Period
* @HMRD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line Receive HOLD Period
* @HMSL: Maximum length (in ic_clk_cycles) of suppressed spikes in High Speed Mode
+ * @FSEN: Maximum Frame Size Feature Enable Control
+ * @FSVL: Maximum Frame Size Value (unit in Bytes)
+ * @INDE: Interrupt Delay Feature Enable Control
+ * @INDV: Interrupt Delay Value (unit in 10 us)
*
* Those properties get from QUICKI2C_ACPI_METHOD_NAME_ISUB method, used for
* I2C timing configure.
@@ -127,17 +133,22 @@ struct quicki2c_subip_acpi_config {
u64 HMTD;
u64 HMRD;
u64 HMSL;
+
+ u64 FSEN;
+ u64 FSVL;
+ u64 INDE;
+ u64 INDV;
u8 reserved;
};
/**
* struct quicki2c_ddata - Driver specific data for quicki2c device
* @max_detect_size: Identify max packet size detect for rx
- * @interrupt_delay: Identify interrupt detect delay for rx
+ * @interrupt_delay: Identify max interrupt detect delay for rx
*/
struct quicki2c_ddata {
u32 max_detect_size;
- u32 interrupt_delay;
+ u32 max_interrupt_delay;
};
struct device;
@@ -170,6 +181,10 @@ struct acpi_device;
* @report_len: The length of input/output report packet
* @reset_ack_wq: Workqueue for waiting reset response from device
* @reset_ack: Indicate reset response received or not
+ * @i2c_max_frame_size_enable: Indicate max frame size feature enabled or not
+ * @i2c_max_frame_size: Max RX frame size (unit in Bytes)
+ * @i2c_int_delay_enable: Indicate interrupt delay feature enabled or not
+ * @i2c_int_delay: Interrupt detection delay value (unit in 10 us)
*/
struct quicki2c_device {
struct device *dev;
@@ -200,6 +215,11 @@ struct quicki2c_device {
wait_queue_head_t reset_ack_wq;
bool reset_ack;
+
+ u32 i2c_max_frame_size_enable;
+ u32 i2c_max_frame_size;
+ u32 i2c_int_delay_enable;
+ u32 i2c_int_delay;
};
#endif /* _QUICKI2C_DEV_H_ */
--
2.40.1
^ permalink raw reply related
* [PATCH] HID: cp2112: Add parameter validation to data length
From: Deepak Sharma @ 2025-09-16 0:54 UTC (permalink / raw)
To: jikos
Cc: linux-input, linux-kernel, linux-kernel-mentees, Deepak Sharma,
syzbot+7617e19c8a59edfbd879
Syzkaller reported a stack OOB access in cp2112_write_req caused by lack
of parameter validation for the user input in I2C SMBUS ioctl codeflow
in the report
I2C device drivers are "responsible for checking all the parameters that
come from user-space for validity" as specified at Documentation/i2c/dev-interface
Add the parameter validation for the data->block[0] to be bounded by 32
or return EINVAL
Reported-by: syzbot+7617e19c8a59edfbd879@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7617e19c8a59edfbd879
Signed-off-by: Deepak Sharma <deepak.sharma.472935@gmail.com>
---
drivers/hid/hid-cp2112.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index 482f62a78c41..90292ce3d363 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -689,7 +689,10 @@ static int cp2112_xfer(struct i2c_adapter *adap, u16 addr,
count = cp2112_write_read_req(buf, addr, read_length,
command, NULL, 0);
} else {
- count = cp2112_write_req(buf, addr, command,
+ if (data->block[0] > 32)
+ count = -EINVAL;
+ else
+ count = cp2112_write_req(buf, addr, command,
data->block + 1,
data->block[0]);
}
@@ -700,7 +703,10 @@ static int cp2112_xfer(struct i2c_adapter *adap, u16 addr,
I2C_SMBUS_BLOCK_MAX,
command, NULL, 0);
} else {
- count = cp2112_write_req(buf, addr, command,
+ if (data->block[0] > 32)
+ count = -EINVAL;
+ else
+ count = cp2112_write_req(buf, addr, command,
data->block,
data->block[0] + 1);
}
@@ -709,7 +715,10 @@ static int cp2112_xfer(struct i2c_adapter *adap, u16 addr,
size = I2C_SMBUS_BLOCK_DATA;
read_write = I2C_SMBUS_READ;
- count = cp2112_write_read_req(buf, addr, I2C_SMBUS_BLOCK_MAX,
+ if (data->block[0] > 32)
+ count = -EINVAL;
+ else
+ count = cp2112_write_read_req(buf, addr, I2C_SMBUS_BLOCK_MAX,
command, data->block,
data->block[0] + 1);
break;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 2/2] Input: edt-ft5x06 - rename sysfs attribute report_rate to report_rate_hz
From: Dmitry Torokhov @ 2025-09-16 0:38 UTC (permalink / raw)
To: Dario Binacchi
Cc: linux-kernel, linux-amarula, Al Viro, Oliver Graute, Wolfram Sang,
Yu Jiaoliang, linux-input
In-Reply-To: <20250915201748.1712822-2-dario.binacchi@amarulasolutions.com>
Hi Dario,
On Mon, Sep 15, 2025 at 10:16:32PM +0200, Dario Binacchi wrote:
> The sysfs attribute has been renamed to report_rate_hz to match the
> report-rate-hz property from device tree, making it clear that the same
> parameter can be set via sysfs or device tree and behaves identically.
No, this attribute was defined since forever and we should avoid
gratuitous renames: they will break existing users.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v2 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Mukesh Rathor @ 2025-09-15 23:46 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250915234604.3256611-1-mrathor@linux.microsoft.com>
With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
hypervisor support, such as hypercalls, clocks/timers, Confidential
Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
devices.
Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
drivers/Makefile | 2 +-
drivers/hv/Kconfig | 2 +-
drivers/hv/Makefile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index b5749cf67044..7ad5744db0b6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -161,7 +161,7 @@ obj-$(CONFIG_SOUNDWIRE) += soundwire/
# Virtualization drivers
obj-$(CONFIG_VIRT_DRIVERS) += virt/
-obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
+obj-$(CONFIG_HYPERV) += hv/
obj-$(CONFIG_PM_DEVFREQ) += devfreq/
obj-$(CONFIG_EXTCON) += extcon/
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 29f8637f441a..0b8c391a0342 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -3,7 +3,7 @@
menu "Microsoft Hyper-V guest support"
config HYPERV
- tristate "Microsoft Hyper-V client drivers"
+ bool "Microsoft Hyper-V core hypervisor support"
depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
|| (ARM64 && !CPU_BIG_ENDIAN)
select PARAVIRT
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index 4bb41663767d..1a1677bf4dac 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -16,5 +16,5 @@ mshv_root-y := mshv_root_main.o mshv_synic.o mshv_eventfd.o mshv_irq.o \
mshv_root_hv_call.o mshv_portid_table.o
# Code that must be built-in
-obj-$(subst m,y,$(CONFIG_HYPERV)) += hv_common.o
+obj-$(CONFIG_HYPERV) += hv_common.o
obj-$(subst m,y,$(CONFIG_MSHV_ROOT)) += hv_proc.o mshv_common.o
--
2.36.1.vfs.0.0
^ permalink raw reply related
* [PATCH v2 1/2] Driver: hv: Add CONFIG_HYPERV_VMBUS option
From: Mukesh Rathor @ 2025-09-15 23:46 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250915234604.3256611-1-mrathor@linux.microsoft.com>
At present VMBus driver is hinged off of CONFIG_HYPERV which entails
lot of builtin code and encompasses too much. It's not always clear
what depends on builtin hv code and what depends on VMBus. Setting
CONFIG_HYPERV as a module and fudging the Makefile to switch to builtin
adds even more confusion. VMBus is an independent module and should have
its own config option. Also, there are scenarios like baremetal dom0/root
where support is built in with CONFIG_HYPERV but without VMBus. Lastly,
there are more features coming down that use CONFIG_HYPERV and add more
dependencies on it.
So, create a fine grained HYPERV_VMBUS option and update Kconfigs for
dependency on VMBus.
Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/hid/Kconfig | 2 +-
drivers/hv/Kconfig | 11 +++++++++--
drivers/hv/Makefile | 2 +-
drivers/input/serio/Kconfig | 4 ++--
drivers/net/hyperv/Kconfig | 2 +-
drivers/pci/Kconfig | 2 +-
drivers/scsi/Kconfig | 2 +-
drivers/uio/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
include/asm-generic/mshyperv.h | 8 +++++---
net/vmw_vsock/Kconfig | 2 +-
12 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f7ea8e895c0c..58f34da061c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"
config DRM_HYPERV
tristate "DRM Support for Hyper-V synthetic video device"
- depends on DRM && PCI && HYPERV
+ depends on DRM && PCI && HYPERV_VMBUS
select DRM_CLIENT_SELECTION
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a57901203aeb..fe3dc8c0db99 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1162,7 +1162,7 @@ config GREENASIA_FF
config HID_HYPERV_MOUSE
tristate "Microsoft Hyper-V mouse driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
help
Select this option to enable the Hyper-V mouse driver.
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index e24f6299c376..29f8637f441a 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -45,18 +45,25 @@ config HYPERV_TIMER
config HYPERV_UTILS
tristate "Microsoft Hyper-V Utilities driver"
- depends on HYPERV && CONNECTOR && NLS
+ depends on HYPERV_VMBUS && CONNECTOR && NLS
depends on PTP_1588_CLOCK_OPTIONAL
help
Select this option to enable the Hyper-V Utilities.
config HYPERV_BALLOON
tristate "Microsoft Hyper-V Balloon driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
select PAGE_REPORTING
help
Select this option to enable Hyper-V Balloon driver.
+config HYPERV_VMBUS
+ tristate "Microsoft Hyper-V VMBus driver"
+ depends on HYPERV
+ default HYPERV
+ help
+ Select this option to enable Hyper-V Vmbus driver.
+
config MSHV_ROOT
tristate "Microsoft Hyper-V root partition support"
depends on HYPERV && (X86_64 || ARM64)
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index 976189c725dc..4bb41663767d 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_HYPERV) += hv_vmbus.o
+obj-$(CONFIG_HYPERV_VMBUS) += hv_vmbus.o
obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 17edc1597446..c7ef347a4dff 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -276,8 +276,8 @@ config SERIO_OLPC_APSP
config HYPERV_KEYBOARD
tristate "Microsoft Synthetic Keyboard driver"
- depends on HYPERV
- default HYPERV
+ depends on HYPERV_VMBUS
+ default HYPERV_VMBUS
help
Select this option to enable the Hyper-V Keyboard driver.
diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
index c8cbd85adcf9..982964c1a9fb 100644
--- a/drivers/net/hyperv/Kconfig
+++ b/drivers/net/hyperv/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config HYPERV_NET
tristate "Microsoft Hyper-V virtual network driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
select UCS2_STRING
select NLS
help
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 9a249c65aedc..7065a8e5f9b1 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -221,7 +221,7 @@ config PCI_LABEL
config PCI_HYPERV
tristate "Hyper-V PCI Frontend"
- depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
+ depends on ((X86 && X86_64) || ARM64) && HYPERV_VMBUS && PCI_MSI && SYSFS
select PCI_HYPERV_INTERFACE
select IRQ_MSI_LIB
help
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 5522310bab8d..19d0884479a2 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -589,7 +589,7 @@ config XEN_SCSI_FRONTEND
config HYPERV_STORAGE
tristate "Microsoft Hyper-V virtual storage driver"
- depends on SCSI && HYPERV
+ depends on SCSI && HYPERV_VMBUS
depends on m || SCSI_FC_ATTRS != m
default HYPERV
help
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index b060dcd7c635..6f86a61231e6 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -140,7 +140,7 @@ config UIO_MF624
config UIO_HV_GENERIC
tristate "Generic driver for Hyper-V VMBus"
- depends on HYPERV
+ depends on HYPERV_VMBUS
help
Generic driver that you can bind, dynamically, to any
Hyper-V VMBus device. It is useful to provide direct access
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index c21484d15f0c..72c63eaeb983 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1774,7 +1774,7 @@ config FB_BROADSHEET
config FB_HYPERV
tristate "Microsoft Hyper-V Synthetic Video support"
- depends on FB && HYPERV
+ depends on FB && HYPERV_VMBUS
select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
select FB_IOMEM_HELPERS_DEFERRED
help
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index dbd4c2f3aee3..64ba6bc807d9 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -163,6 +163,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
return guest_id;
}
+#if IS_ENABLED(CONFIG_HYPERV_VMBUS)
/* Free the message slot and signal end-of-message if required */
static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
{
@@ -198,6 +199,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
}
}
+extern int vmbus_interrupt;
+extern int vmbus_irq;
+#endif /* CONFIG_HYPERV_VMBUS */
+
int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
void hv_setup_vmbus_handler(void (*handler)(void));
@@ -211,9 +216,6 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
void hv_remove_crash_handler(void);
void hv_setup_mshv_handler(void (*handler)(void));
-extern int vmbus_interrupt;
-extern int vmbus_irq;
-
#if IS_ENABLED(CONFIG_HYPERV)
/*
* Hypervisor's notion of virtual processor ID is different from
diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
index 56356d2980c8..8e803c4828c4 100644
--- a/net/vmw_vsock/Kconfig
+++ b/net/vmw_vsock/Kconfig
@@ -72,7 +72,7 @@ config VIRTIO_VSOCKETS_COMMON
config HYPERV_VSOCKETS
tristate "Hyper-V transport for Virtual Sockets"
- depends on VSOCKETS && HYPERV
+ depends on VSOCKETS && HYPERV_VMBUS
help
This module implements a Hyper-V transport for Virtual Sockets.
--
2.36.1.vfs.0.0
^ permalink raw reply related
* [PATCH v2 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh Rathor @ 2025-09-15 23:46 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV
for hv subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
hv_common.c that is needed for the drivers. Moreover, vmbus driver is
built if CONFIG_HYPER is set, either loadable or builtin.
This is not a good approach. CONFIG_HYPERV is really an umbrella
config that encompasses builtin code and various other things and not
a dedicated config option for VMBus. VMBus should really have a config
option just like CONFIG_HYPERV_BALLOON etc. This small series introduces
CONFIG_HYPERV_VMBUS to build VMBus driver and make that distinction
explicit. With that CONFIG_HYPERV could be changed to bool.
For now, hv_common.c is left as is to reduce conflicts for upcoming
patches, but once merges are mostly done, that and some others should
be moved to virt/hyperv directory.
V2:
o rebased on hyper-next: commit 553d825fb2f0
("x86/hyperv: Switch to msi_create_parent_irq_domain()")
V1:
o Change subject from hyper-v to "Drivers: hv:"
o Rewrite commit messages paying attention to VMBus and not vmbus
o Change some wordings in Kconfig
o Make new VMBUS config option default to HYPERV option for a smoother
transition
Mukesh Rathor (2):
Driver: hv: Add CONFIG_HYPERV_VMBUS option
Drivers: hv: Make CONFIG_HYPERV bool
drivers/Makefile | 2 +-
drivers/gpu/drm/Kconfig | 2 +-
drivers/hid/Kconfig | 2 +-
drivers/hv/Kconfig | 13 ++++++++++---
drivers/hv/Makefile | 4 ++--
drivers/input/serio/Kconfig | 4 ++--
drivers/net/hyperv/Kconfig | 2 +-
drivers/pci/Kconfig | 2 +-
drivers/scsi/Kconfig | 2 +-
drivers/uio/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
include/asm-generic/mshyperv.h | 8 +++++---
net/vmw_vsock/Kconfig | 2 +-
13 files changed, 28 insertions(+), 19 deletions(-)
--
2.36.1.vfs.0.0
^ 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