* [PATCH v2 1/4] Input: da9063 - Simplify obtaining OF match data
From: Biju Das @ 2023-12-13 21:48 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Biju Das, Support Opensource, linux-input, Geert Uytterhoeven,
Prabhakar Mahadev Lad, Biju Das, linux-renesas-soc
In-Reply-To: <20231213214803.9931-1-biju.das.jz@bp.renesas.com>
Simplify probe() by replacing of_match_node() for retrieving match data by
device_get_match_data().
Some minor cleanups:
* Remove the trailing comma in the terminator entry for the OF
table making code robust against (theoretical) misrebases or other
similar things where the new entry goes _after_ the termination without
the compiler noticing.
* Move OF table near to the user.
* Arrange variables in reverse xmas tree order in probe().
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v1->v2:
* No change.
---
drivers/input/misc/da9063_onkey.c | 27 ++++++++++++---------------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/input/misc/da9063_onkey.c b/drivers/input/misc/da9063_onkey.c
index 74808bae326a..9351ce0bb405 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -74,13 +74,6 @@ static const struct da906x_chip_config da9062_regs = {
.name = "da9062-onkey",
};
-static const struct of_device_id da9063_compatible_reg_id_table[] = {
- { .compatible = "dlg,da9063-onkey", .data = &da9063_regs },
- { .compatible = "dlg,da9062-onkey", .data = &da9062_regs },
- { },
-};
-MODULE_DEVICE_TABLE(of, da9063_compatible_reg_id_table);
-
static void da9063_poll_on(struct work_struct *work)
{
struct da9063_onkey *onkey = container_of(work,
@@ -187,14 +180,8 @@ static irqreturn_t da9063_onkey_irq_handler(int irq, void *data)
static int da9063_onkey_probe(struct platform_device *pdev)
{
struct da9063_onkey *onkey;
- const struct of_device_id *match;
- int irq;
int error;
-
- match = of_match_node(da9063_compatible_reg_id_table,
- pdev->dev.of_node);
- if (!match)
- return -ENXIO;
+ int irq;
onkey = devm_kzalloc(&pdev->dev, sizeof(struct da9063_onkey),
GFP_KERNEL);
@@ -203,7 +190,10 @@ static int da9063_onkey_probe(struct platform_device *pdev)
return -ENOMEM;
}
- onkey->config = match->data;
+ onkey->config = device_get_match_data(&pdev->dev);
+ if (!onkey->config)
+ return -ENXIO;
+
onkey->dev = &pdev->dev;
onkey->regmap = dev_get_regmap(pdev->dev.parent, NULL);
@@ -270,6 +260,13 @@ static int da9063_onkey_probe(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id da9063_compatible_reg_id_table[] = {
+ { .compatible = "dlg,da9063-onkey", .data = &da9063_regs },
+ { .compatible = "dlg,da9062-onkey", .data = &da9062_regs },
+ { }
+};
+MODULE_DEVICE_TABLE(of, da9063_compatible_reg_id_table);
+
static struct platform_driver da9063_onkey_driver = {
.probe = da9063_onkey_probe,
.driver = {
--
2.25.1
^ permalink raw reply related
* [PATCH v2 2/4] Input: da9063 - Drop redundant prints in probe()
From: Biju Das @ 2023-12-13 21:48 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Biju Das, Support Opensource, linux-input, Geert Uytterhoeven,
Prabhakar Mahadev Lad, Biju Das, linux-renesas-soc
In-Reply-To: <20231213214803.9931-1-biju.das.jz@bp.renesas.com>
The memory allocation core code already prints error message in case of
OOM. So, drop additional print messages for OOM cases.
While at it, input_register_device() is already printing error messages on
failure. Drop the redundant print.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v2:
* New patch.
---
drivers/input/misc/da9063_onkey.c | 23 ++++-------------------
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/input/misc/da9063_onkey.c b/drivers/input/misc/da9063_onkey.c
index 9351ce0bb405..80878274204e 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -185,10 +185,8 @@ static int da9063_onkey_probe(struct platform_device *pdev)
onkey = devm_kzalloc(&pdev->dev, sizeof(struct da9063_onkey),
GFP_KERNEL);
- if (!onkey) {
- dev_err(&pdev->dev, "Failed to allocate memory.\n");
+ if (!onkey)
return -ENOMEM;
- }
onkey->config = device_get_match_data(&pdev->dev);
if (!onkey->config)
@@ -206,10 +204,8 @@ static int da9063_onkey_probe(struct platform_device *pdev)
"dlg,disable-key-power");
onkey->input = devm_input_allocate_device(&pdev->dev);
- if (!onkey->input) {
- dev_err(&pdev->dev, "Failed to allocated input device.\n");
+ if (!onkey->input)
return -ENOMEM;
- }
onkey->input->name = onkey->config->name;
snprintf(onkey->phys, sizeof(onkey->phys), "%s/input0",
@@ -221,12 +217,8 @@ static int da9063_onkey_probe(struct platform_device *pdev)
error = devm_delayed_work_autocancel(&pdev->dev, &onkey->work,
da9063_poll_on);
- if (error) {
- dev_err(&pdev->dev,
- "Failed to add cancel poll action: %d\n",
- error);
+ if (error)
return error;
- }
irq = platform_get_irq_byname(pdev, "ONKEY");
if (irq < 0)
@@ -250,14 +242,7 @@ static int da9063_onkey_probe(struct platform_device *pdev)
else
device_init_wakeup(&pdev->dev, true);
- error = input_register_device(onkey->input);
- if (error) {
- dev_err(&pdev->dev,
- "Failed to register input device: %d\n", error);
- return error;
- }
-
- return 0;
+ return input_register_device(onkey->input);
}
static const struct of_device_id da9063_compatible_reg_id_table[] = {
--
2.25.1
^ permalink raw reply related
* [PATCH v2 3/4] Input: da9063 - Use dev_err_probe()
From: Biju Das @ 2023-12-13 21:48 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Biju Das, Support Opensource, linux-input, Geert Uytterhoeven,
Prabhakar Mahadev Lad, Biju Das, linux-renesas-soc
In-Reply-To: <20231213214803.9931-1-biju.das.jz@bp.renesas.com>
Replace dev_err()->dev_err_probe() to simplify probe().
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v1->v2:
* Fixed typo in commit description
* Updated the print message for irq allocation failure.
---
drivers/input/misc/da9063_onkey.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/input/misc/da9063_onkey.c b/drivers/input/misc/da9063_onkey.c
index 80878274204e..b18232e91844 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -195,10 +195,9 @@ static int da9063_onkey_probe(struct platform_device *pdev)
onkey->dev = &pdev->dev;
onkey->regmap = dev_get_regmap(pdev->dev.parent, NULL);
- if (!onkey->regmap) {
- dev_err(&pdev->dev, "Parent regmap unavailable.\n");
- return -ENXIO;
- }
+ if (!onkey->regmap)
+ return dev_err_probe(&pdev->dev, -ENXIO,
+ "Parent regmap unavailable.\n");
onkey->key_power = !of_property_read_bool(pdev->dev.of_node,
"dlg,disable-key-power");
@@ -228,11 +227,9 @@ static int da9063_onkey_probe(struct platform_device *pdev)
NULL, da9063_onkey_irq_handler,
IRQF_TRIGGER_LOW | IRQF_ONESHOT,
"ONKEY", onkey);
- if (error) {
- dev_err(&pdev->dev,
- "Failed to request IRQ %d: %d\n", irq, error);
- return error;
- }
+ if (error)
+ return dev_err_probe(&pdev->dev, error,
+ "Failed to allocate onkey IRQ\n");
error = dev_pm_set_wake_irq(&pdev->dev, irq);
if (error)
--
2.25.1
^ permalink raw reply related
* [PATCH v2 4/4] Input: da9063 - Add polling support
From: Biju Das @ 2023-12-13 21:48 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Biju Das, Support Opensource, linux-input, Geert Uytterhoeven,
Prabhakar Mahadev Lad, Biju Das, linux-renesas-soc
In-Reply-To: <20231213214803.9931-1-biju.das.jz@bp.renesas.com>
On some platforms (eg: RZ/{G2UL,Five} SMARC EVK), there is no
onkey IRQ populated by default. Add polling support.
While at it, doing some cleanups in da9063_poll_on()
as regmap_read() and dev_err() can fit in single line.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v1->v2:
* Updated commit description
* Fixed the logical mistake for optional IRQ handling.
---
drivers/input/misc/da9063_onkey.c | 89 +++++++++++++++++++++++--------
1 file changed, 66 insertions(+), 23 deletions(-)
diff --git a/drivers/input/misc/da9063_onkey.c b/drivers/input/misc/da9063_onkey.c
index b18232e91844..734cee9e9253 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -19,6 +19,8 @@
#include <linux/mfd/da9062/core.h>
#include <linux/mfd/da9062/registers.h>
+#define DA9062_KEY_THRESHOLD_MSEC (200)
+
struct da906x_chip_config {
/* REGS */
int onkey_status;
@@ -42,6 +44,8 @@ struct da9063_onkey {
const struct da906x_chip_config *config;
char phys[32];
bool key_power;
+ unsigned int poll_interval;
+ unsigned int key_threshold_release_time;
};
static const struct da906x_chip_config da9063_regs = {
@@ -86,15 +90,27 @@ static void da9063_poll_on(struct work_struct *work)
int error;
/* Poll to see when the pin is released */
- error = regmap_read(onkey->regmap,
- config->onkey_status,
- &val);
+ error = regmap_read(onkey->regmap, config->onkey_status, &val);
if (error) {
- dev_err(onkey->dev,
- "Failed to read ON status: %d\n", error);
+ dev_err(onkey->dev, "Failed to read ON status: %d\n", error);
goto err_poll;
}
+ if (onkey->poll_interval &&
+ onkey->key_threshold_release_time <= DA9062_KEY_THRESHOLD_MSEC) {
+ /* detect short or long key press */
+ if (!(val & config->onkey_nonkey_mask)) {
+ input_report_key(onkey->input, KEY_POWER, 0);
+ input_sync(onkey->input);
+ onkey->key_threshold_release_time = 0;
+ dev_dbg(onkey->dev, "KEY_POWER short press.\n");
+ } else {
+ schedule_delayed_work(&onkey->work, msecs_to_jiffies(50));
+ onkey->key_threshold_release_time += 50;
+ }
+ return;
+ }
+
if (!(val & config->onkey_nonkey_mask)) {
error = regmap_update_bits(onkey->regmap,
config->onkey_pwr_signalling,
@@ -177,6 +193,21 @@ static irqreturn_t da9063_onkey_irq_handler(int irq, void *data)
return IRQ_HANDLED;
}
+static void da9063_onkey_polled_poll(struct input_dev *input)
+{
+ struct da9063_onkey *onkey = input_get_drvdata(input);
+ const struct da906x_chip_config *config = onkey->config;
+ unsigned int val;
+ int error;
+
+ error = regmap_read(onkey->regmap, config->onkey_status, &val);
+ if (onkey->key_power && !error && (val & config->onkey_nonkey_mask)) {
+ input_report_key(onkey->input, KEY_POWER, 1);
+ input_sync(onkey->input);
+ schedule_delayed_work(&onkey->work, 0);
+ }
+}
+
static int da9063_onkey_probe(struct platform_device *pdev)
{
struct da9063_onkey *onkey;
@@ -219,25 +250,37 @@ static int da9063_onkey_probe(struct platform_device *pdev)
if (error)
return error;
- irq = platform_get_irq_byname(pdev, "ONKEY");
- if (irq < 0)
+ irq = platform_get_irq_byname_optional(pdev, "ONKEY");
+ if (irq >= 0) {
+ error = devm_request_threaded_irq(&pdev->dev, irq,
+ NULL, da9063_onkey_irq_handler,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ "ONKEY", onkey);
+ if (error)
+ return dev_err_probe(&pdev->dev, error,
+ "Failed to allocate onkey irq\n");
+
+ error = dev_pm_set_wake_irq(&pdev->dev, irq);
+ if (error)
+ dev_warn(&pdev->dev,
+ "Failed to set IRQ %d as a wake IRQ: %d\n",
+ irq, error);
+ else
+ device_init_wakeup(&pdev->dev, true);
+ } else if (irq != -ENXIO) {
return irq;
-
- error = devm_request_threaded_irq(&pdev->dev, irq,
- NULL, da9063_onkey_irq_handler,
- IRQF_TRIGGER_LOW | IRQF_ONESHOT,
- "ONKEY", onkey);
- if (error)
- return dev_err_probe(&pdev->dev, error,
- "Failed to allocate onkey IRQ\n");
-
- error = dev_pm_set_wake_irq(&pdev->dev, irq);
- if (error)
- dev_warn(&pdev->dev,
- "Failed to set IRQ %d as a wake IRQ: %d\n",
- irq, error);
- else
- device_init_wakeup(&pdev->dev, true);
+ } else {
+ input_set_drvdata(onkey->input, onkey);
+ device_property_read_u32(&pdev->dev, "poll-interval",
+ &onkey->poll_interval);
+ error = input_setup_polling(onkey->input,
+ da9063_onkey_polled_poll);
+ if (error)
+ return dev_err_probe(&pdev->dev, error,
+ "unable to set up polling\n");
+
+ input_set_poll_interval(onkey->input, onkey->poll_interval);
+ }
return input_register_device(onkey->input);
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] irq: Resolve that mask_irq/unmask_irq may not be called in pairs
From: xiongxin @ 2023-12-14 1:54 UTC (permalink / raw)
To: Thomas Gleixner, jikos, benjamin.tissoires
Cc: linux-input, stable, Riwen Lu, hoan, fancer.lancer, linus.walleij,
brgl, andy, linux-gpio, linux-kernel
In-Reply-To: <875y12p2r0.ffs@tglx>
在 2023/12/13 22:59, Thomas Gleixner 写道:
> On Wed, Dec 13 2023 at 10:29, xiongxin wrote:
>> 在 2023/12/12 23:17, Thomas Gleixner 写道:
>> Sorry, the previous reply may not have clarified the BUG process. I
>> re-debugged and confirmed it yesterday. The current BUG execution
>> sequence is described as follows:
>
> It's the sequence how this works and it works correctly.
>
> Just because it does not work on your machine it does not mean that this
> is incorrect and a BUG.
>
> You are trying to fix a symptom and thereby violating guarantees of the
> core code.
>
>> That is, there is a time between the 1:handle_level_irq() and
>> 3:irq_thread_fn() calls for the 2:disable_irq() call to acquire the lock
>> and then implement the irq_state_set_disabled() operation. When finally
>> call irq_thread_fn()->irq_finalize_oneshot(), it cannot enter the
>> unmask_thread_irq() process.
>
> Correct, because the interrupt has been DISABLED in the mean time.
>
>> In this case, the gpio irq_chip irq_mask()/irq_unmask() callback pairs
>> are not called in pairs, so I think this is a BUG, but not necessarily
>> fixed from the irq core code layer.
>
> No. It is _NOT_ a BUG. unmask() is not allowed to be invoked when the
> interrupt is DISABLED. That's the last time I'm going to tell you that.
> Only enable_irq() can undo the effect of disable_irq(), period.
>
>> Next, when the gpio controller driver calls the suspend/resume process,
>> it is as follows:
>>
>> suspend process:
>> dwapb_gpio_suspend()
>> ctx->int_mask = dwapb_read(gpio, GPIO_INTMASK);
>>
>> resume process:
>> dwapb_gpio_resume()
>> dwapb_write(gpio, GPIO_INTMASK, ctx->int_mask);
>
> Did you actually look at the sequence I gave you?
>
> Suspend:
>
> i2c_hid_core_suspend()
> disable_irq(); <- Marks it disabled and eventually
> masks it.
>
> gpio_irq_suspend()
> save_registers(); <- Saves masked interrupt
>
> Resume:
>
> gpio_irq_resume()
> restore_registers(); <- Restores masked interrupt
>
> i2c_hid_core_resume()
> enable_irq(); <- Unmasks interrupt and removes the
> disabled marker
>
>
> Have you verified that this order of invocations is what happens on
> your machine?
>
> Thanks,
>
> tglx
As described earlier, in the current situation, the irq_mask() callback
of gpio irq_chip is called in mask_irq(), followed by the disable_irq()
in i2c_hid_core_suspend(), unmask_irq() will not be executed.
Then call enable_irq() in i2c_hid_core_resume(). Since gpio irq_chip
does not implement the irq_startup() callback, it ends up calling
irq_enable().
The irq_enable() function is then implemented as follows:
irq_state_clr_disabled(desc);
if (desc->irq_data.chip->irq_enable) {
desc->irq_data.chip->irq_enable(&desc->irq_data);
irq_state_clr_masked(desc);
} else {
unmask_irq(desc);
}
Because gpio irq_chip implements irq_enable(), unmask_irq() is not
executed, and gpio irq_chip's irq_unmask() callback is not called.
Instead, irq_state_clr_masked() was called to clear the masked flag.
The irq masked behavior is actually controlled by the
irq_mask()/irq_unmask() callback function pairs in gpio irq_chip. When
the whole situation occurs, there is one more irq_mask() operation, or
one less irq_unmask() operation. This ends the i2c hid resume and the
gpio corresponding i2c hid interrupt is also masked.
Please help confirm whether the current situation is a BUG, or suggest
other solutions to fix it.
^ permalink raw reply
* Re: [PATCH v4 2/4] Input: cs40l50 - Add cirrus haptics base support
From: Jeff LaBundy @ 2023-12-14 2:11 UTC (permalink / raw)
To: James Ogletree
Cc: James Ogletree, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Lee Jones, Fred Treven, Ben Bright, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <95C3C010-DA09-4848-A5AB-635AD93DCDC3@cirrus.com>
Hi James,
Apologies for the delayed response.
On Wed, Nov 29, 2023 at 10:22:16PM +0000, James Ogletree wrote:
>
> >>>> +
> >>>> + words = kcalloc(haptics->dsp.pseq_size, sizeof(u32), GFP_KERNEL);
> >>>> + if (!words)
> >>>> + return -ENOMEM;
> >>>> +
> >>>> + error = regmap_bulk_read(haptics->regmap, haptics->dsp.pseq_reg,
> >>>> + words, haptics->dsp.pseq_size);
> >>>> + if (error)
> >>>> + goto err_free;
> >>>> +
> >>>> + for (i = 0; i < haptics->dsp.pseq_size; i += num_words) {
> >>>> + operation = FIELD_GET(PSEQ_OP_MASK, words[i]);
> >>>> + switch (operation) {
> >>>> + case PSEQ_OP_END:
> >>>> + case PSEQ_OP_WRITE_UNLOCK:
> >>>> + num_words = PSEQ_OP_END_WORDS;
> >>>> + break;
> >>>> + case PSEQ_OP_WRITE_ADDR8:
> >>>> + case PSEQ_OP_WRITE_H16:
> >>>> + case PSEQ_OP_WRITE_L16:
> >>>> + num_words = PSEQ_OP_WRITE_X16_WORDS;
> >>>> + break;
> >>>> + case PSEQ_OP_WRITE_FULL:
> >>>> + num_words = PSEQ_OP_WRITE_FULL_WORDS;
> >>>> + break;
> >>>> + default:
> >>>> + error = -EINVAL;
> >>>> + dev_err(haptics->dev, "Unsupported op: %u\n", operation);
> >>>> + goto err_free;
> >>>> + }
> >>>> +
> >>>> + op = devm_kzalloc(haptics->dev, sizeof(*op), GFP_KERNEL);
> >>>> + if (!op) {
> >>>> + error = -ENOMEM;
> >>>> + goto err_free;
> >>>> + }
> >>>> +
> >>>> + op->size = num_words * sizeof(u32);
> >>>> + memcpy(op->words, &words[i], op->size);
> >>>> + op->offset = i * sizeof(u32);
> >>>> + op->operation = operation;
> >>>> + list_add(&op->list, &haptics->pseq_head);
> >>>> +
> >>>> + if (operation == PSEQ_OP_END)
> >>>> + break;
> >>>> + }
> >>>> +
> >>>> + if (operation != PSEQ_OP_END)
> >>>> + error = -ENOENT;
> >>>> +
> >>>> +err_free:
> >>>> + kfree(words);
> >>>> +
> >>>> + return error;
> >>>> +}
> >>>
> >>> My first thought as I reviewed this patch was that this and the lot
> >>> of pseq-related functions are not necessarily related to haptics, but
> >>> rather CS40L50 register access and housekeeping in general.
> >>>
> >>> I seem to recall on L25 and friends that the the power-on sequencer,
> >>> i.e. PSEQ, is more or less a "tape recorder" of sorts in DSP memory
> >>> that can play back a series of address/data pairs when the device
> >>> comes out of hibernation, and any registers written during runtime
> >>> must also be mirrored to the PSEQ for "playback" later. Is that still
> >>> the case here?
> >>>
> >>> Assuming so, these functions seem like they belong in the MFD, not
> >>> an input-specific library, because they will presumably be used by
> >>> the codec driver as well, since that driver will write registers to
> >>> set BCLK/LRCK ratio, etc.
> >>>
> >>> Therefore, I think it makes more sense for these functions to move to
> >>> the MFD, which can then export them for use by the input/FF and codec
> >>> children.
> >>
> >> I think the problem with moving the write sequencer code to the MFD
> >> driver is that it would go unused in a codec-only environment. We only
> >> need to write to the PSEQ when we want to maintain register settings
> >> throughout hibernation cycles, and it isn’t possible to hibernate when
> >> there is data streaming to the device. So the PSEQ will never be used
> >> in the codec driver.
> >
> > I agree that in practice, the write sequencer would technically go unused
> > in a codec-only implementation. However, that is because the ASoC core
> > happens to write all pertinent registers ahead-of-time each time a stream
> > starts. That is a property of the ASoC core and not L50; my feeling is that
> > the driver should not be structured based on what one of the subsystems
> > associated with it happens to do, but rather the nature of the hardware.
> >
> > Some specific reasons I think the MFD is a better home for the pseq code:
> >
> > 1. The write sequencer is a housekeeping function derived from the way
> > the hardware implements its power management; it doesn't have anything
> > to do with haptics. My opinion is that facilities supporting application-
> > agnostic functions belong in the MFD, for all children to access, even
> > if only one happens to do so today.
> >
> > 2. Over the course of the IC's life, you may be required to add errata
> > writes after the IC is taken out of reset; these presumably would need
> > to be "scheduled" in the write sequencer as well. These wouldn't make
> > logical sense to add in the input driver, and they would be missed in
> > the theoretical codec-only case.
> >
> > 3. This device has a programmable DSP; it wouldn't be unheard of for a
> > customer to ask for a new function down the road that begets a third
> > child device. Perhaps a customer asks for a special .wmfw file that
> > repurposes the SDOUT pin as a PWM output for an LED, and now you must
> > add a pwm child. That's a made-up example of course, but in general we
> > want to structure things in such a way that rip-up is minimal in case
> > requirements change in the future.
>
> Great points. I agree now that the write sequencer code ought not to go in
> cirrus_haptics.c. After talking it over with the internal team, I am considering
> moving the write sequencer interface to cs_dsp.c. It’s an already existing
> library with both Cirrus haptics and audio users. It seems to dodge your
> concerns above and avoids a new common library as you suggested
> below. Do you have any concerns on this approach over putting it in MFD?
I think that's a great idea. Not every DSP-equipped device has a write
sequencer, but most, if not all write-sequencer-equipped devices have
a DSP. Adding the write sequencer code to cs_dsp.c seems like a natural
union of the two facilities.
>
>
> >>> This leaves cirrus_haptics.* with only a few functions related to
> >>> starting and stopping work, which seem specific enough to just live
> >>> in cs40l50-vibra.c. Presumably many of those could be re-used by
> >>> the L30 down the road, but in that case I think we'd be looking to
> >>> actually re-use the L50 driver and simply add a compatible string
> >>> for L30.
> >>>
> >>> I recall L30 has some overhead that L50 does not, which may make
> >>> it hairy for cs40l50-vibra.c to support both. But in that case,
> >>> you could always fork a cs40l30-vibra.c with its own compatible
> >>> string, then have the L50 MFD selectively load the correct child
> >>> based on device ID. To summarize, we should have:
> >>>
> >>> * drivers/mfd/cs40l50-core.c: MFD cell definition, device discovery,
> >>> IRQ handling, exported PSEQ functions, etc.
> >>> * sound/soc/codecs/cs40l50.c: codec driver, uses PSEQ library from
> >>> the MFD.
> >>> * drivers/input/misc/cs40l50-vibra.c: input/FF driver, start/stop
> >>> work, also uses PSEQ library from the MFD.
> >>>
> >>> And down the road, depending on complexity, maybe we also have:
> >>>
> >>> * drivers/input/misc/cs40l30-vibra.c: another input/FF driver that
> >>> includes other functionality that didn't really fit in cs40l50-vibra.c;
> >>> also uses PSEQ library from, and is loaded by, the original L50 MFD.
> >>> If this driver duplicates small bits of cs40l50-vibra.c, it's not the
> >>> end of the world.
> >>>
> >>> All of these files would #include include/linux/mfd/cs40l50.h. And
> >>> finally, cirrus_haptics.* simply go away. Same idea, just slightly
> >>> more scalable, and closer to common design patterns.
> >>
> >>
> >> I understand that it is a common design pattern to selectively load
> >> devices from the MFD driver. If I could summarize my thoughts on why
> >> that would not be fitting here, it’s that the L26 and L50 share a ton of
> >> input FF related work, and not enough “MFD core” related work.
> >> Between errata differences, power supply configurations, regmap
> >> configurations, interrupt register differences, it would seem to make for
> >> a very awkward, scrambled MFD driver. Moreover, I think I will be moving
> >> firmware download to the MFD driver, and that alone constitutes a
> >> significant incompatibility because firmware downloading is compulsory
> >> on L26, not so on L50.
> >>
> >> On the other hand, I want to emphasize the amount that L26 and
> >> L50 share when it comes to the Input FF callbacks. The worker
> >> functions in cirrus_haptics.c are bare-bones for this first
> >> submission, but were designed to be totally generic and scalable to
> >> the needs of L26 and all future Cirrus input drivers. While it might appear
> >> too specific for L26, everything currently in cirrus_haptics is usable by
> >> L26 as-is.
> >>
> >> For the above reasons I favor the current approach.
> >>
> >
> > Likewise, if the input-related functions of L26 and L50 are nearly identical,
> > then it's also perfectly acceptable for both drivers/mfd/cs40l26.c and
> > drivers/mfd/cs40l50.c to load drivers/input/misc/cs40l50-vibra.c, which
> > supports both L26 and L50 haptics-related functions. You're already doing
> > something similar, but I disagree on the following:
> >
> > 1. Rather than have a library referenced by two drivers that support children
> > which are largely the same in a logcial sense, just have a single driver that
> > supports two children.
>
> Your point here is clear and makes sense to me, especially now with the write
> sequencer interface moving out. After considering the similarities and
> differences closer, I am still a little wary. Maybe you can help me with these
> concerns:
>
> 1. In the current implementation, drivers would be able to configure their own
> input FF capabilities, and selectively register to input FF callbacks. L50 does
> not register to the set_gain callback, whereas L26 does. I anticipate future
> divergences, such as one driver supporting different effect types (see
> the L50-specific error checking in cs40l50_add()). This would be exacerbated
> by any future additional children.
>
> 2. This may be my lack of imagination, but in the current implementation it
> seems much easier to develop new haptic features that don’t apply to all the
> users of the library. One would simply wrap the feature in a boolean in
> cirrus_haptics, which clients can take or leave. In the one driver
> implementation, it seems you would have to find some clever, generalized
> way of determining whether or not a feature can be used. This would also
> seem to be exacerbated by any future additional children.
>
> 3. The current implementation provides for the individual drivers to setup
> the haptics interface in whatever way peculiar to that device, whether that
> interface be static (L50) or dependent on the loaded firmware (L26).
>
Maybe the solution here is to define a "descriptor", that is a struct which
reserves members for all things that can vary based on device (FF callback
pointers, input device capabilities, etc.). You then define an array of such
structs, with L50 being the only member, and L26 and others to come. Then,
cs40l50_vibra_probe() would simply parse the array index based on the device
ID hinted to it by the parent MFD.
As the person not doing the actual work, my naive opinion is that you face the
same problems whether two different drivers reference a library, or a common
driver supports two devices. The problem is therefore cosmetic, and if so, we
should tend toward a design pattern that seems to be most common in the input
subsystem, which is to support as many devices as possible with a single driver.
> Since I am moving around a lot of code in and out of both -vibra.c and the
> library for the next version, I think it would be helpful for me to wait until the
> next version is submitted to decide on this. Would that be acceptable?
I very much support moving in incremental steps; if you still feel strongly
against my suggestion, let us by all means evaluate your approach in the
context of the other changes.
>
> >
> >
> >>
> >>>> +static void cs_hap_vibe_stop_worker(struct work_struct *work)
> >>>> +{
> >>>> + struct cs_hap *haptics = container_of(work, struct cs_hap,
> >>>> + vibe_stop_work);
> >>>> + int error;
> >>>> +
> >>>> + if (haptics->runtime_pm) {
> >>>> + error = pm_runtime_resume_and_get(haptics->dev);
> >>>> + if (error < 0) {
> >>>> + haptics->stop_error = error;
> >>>> + return;
> >>>> + }
> >>>> + }
> >>>> +
> >>>> + mutex_lock(&haptics->lock);
> >>>> + error = regmap_write(haptics->regmap, haptics->dsp.mailbox_reg,
> >>>> + haptics->dsp.stop_cmd);
> >>>> + mutex_unlock(&haptics->lock);
> >>>> +
> >>>> + if (haptics->runtime_pm) {
> >>>> + pm_runtime_mark_last_busy(haptics->dev);
> >>>> + pm_runtime_put_autosuspend(haptics->dev);
> >>>> + }
> >>>> +
> >>>> + haptics->stop_error = error;
> >>>
> >>> This seems like another argument for not separating the input/FF child
> >>> from the meat of the driver; it just seems messy to pass around error
> >>> codes within a driver's private data like this.
> >>
> >> I removed the start_error and stop_error members. However I think the
> >> erase_error and add_error need to stay. I think this is more of a symptom
> >> of the Input FF layer requiring error reporting and having to use workqueues
> >> for those Input FF callbacks, than it is to do with the separation of these
> >> functions from the driver. Point being, even if these were moved, we would still
> >> need these *_error members. Let me know if I understood you right here.
> >
> > Sure, but why do adding and removing waveforms require workqueues? The DA7280
> > driver doesn't do this; what is different in this case? (That's a genuine
> > question, not an assertion that what you have is wrong, although it seems
> > unique based on my limited search).
>
> The reason why we have worker items for upload and erase input FF callbacks is
> because we need to ensure their ordering with playback worker items, and we need
> those worker items because the Input FF layer calls playbacks in atomic context.
Got it, that makes sense. Presumably, the act of adding or deleting waveforms
directly manipulates XMEM and YMEM regions of the DSP, and we cannot do so while
they are actively being read during playback. Acknowledged on all counts.
>
> Best,
> James
>
>
Kind regards,
Jeff LaBundy
^ permalink raw reply
* Re: [PATCH v6] Fix freeze in lm8333 i2c keyboard driver
From: Jeff LaBundy @ 2023-12-14 2:24 UTC (permalink / raw)
To: Tomas Mudrunka; +Cc: dmitry.torokhov, linux-input, linux-kernel
In-Reply-To: <20231114123023.95570-1-tomas.mudrunka@gmail.com>
Hi Tomas,
On Tue, Nov 14, 2023 at 01:30:23PM +0100, Tomas Mudrunka wrote:
> LM8333 uses gpio interrupt line which is active-low.
> When interrupt is set to FALLING edge and button is pressed
> before driver loads, driver will miss the edge and never respond.
> To fix this we should handle ONESHOT LOW interrupt rather than edge.
>
> Rather than hardcoding this, we simply remove the override from
> driver by calling request_threaded_irq() with IRQF_TRIGGER_NONE flag.
> This will keep interrupt trigger configuration as per devicetree. eg.:
>
> lm8333@51 {
> compatible = "ti,lm8333";
> interrupt-parent = <&gpio1>;
> interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
> ...
> }
>
> Signed-off-by: Tomas Mudrunka <tomas.mudrunka@gmail.com>
> ---
> drivers/input/keyboard/lm8333.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/lm8333.c b/drivers/input/keyboard/lm8333.c
> index 7457c3220..c5770ebb2 100644
> --- a/drivers/input/keyboard/lm8333.c
> +++ b/drivers/input/keyboard/lm8333.c
> @@ -179,7 +179,7 @@ static int lm8333_probe(struct i2c_client *client)
> }
>
> err = request_threaded_irq(client->irq, NULL, lm8333_irq_thread,
> - IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> + IRQF_TRIGGER_NONE | IRQF_ONESHOT,
This seems like the best approach; it solves the original problem, and
adopts the correct design pattern of allowing the dts to specify details
about the interrupt polarity and sensitivity.
My only feedback is that I think you can simply drop IRQF_TRIGGER_FALLING
altogether instead of replacing it with IRQF_TRIGGER_NONE; it is pointless
to bitwise OR against zero, and almost no drivers do this. It really should
only be used unless there are quite literally no flags to use. Passing only
IRQF_ONESHOT is sufficient here.
Assuming you agree with this change, please feel free to add the following
for v7:
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
> "lm8333", lm8333);
> if (err)
> goto free_mem;
> --
> 2.40.0
Kind regards,
Jeff LaBundy
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS c3d1610345b79cbe29ef6ca04a4780eff0d360c7
From: kernel test robot @ 2023-12-14 4:22 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: c3d1610345b79cbe29ef6ca04a4780eff0d360c7 Input: xpad - add Razer Wolverine V2 support
Warning ids grouped by kconfigs:
gcc_recent_errors
|-- riscv-allmodconfig
| |-- WARNING:modpost:vmlinux:section-mismatch-in-reference:xrv64i2p1_m2p0_a2p1_c2p0_zicsr2p0_zifencei2p0_zihintpause2p0_zmmul1p0-(section:.text.unlikely.event_trigger_unlock_commit)-event_trace_file-(secti
| `-- WARNING:modpost:vmlinux:section-mismatch-in-reference:xrv64i2p1_m2p0_a2p1_c2p0_zicsr2p0_zifencei2p0_zihintpause2p0_zmmul1p0-(section:.text.unlikely.set_bit)-numa_nodes_parsed-(section:.init.data)
`-- riscv-allyesconfig
|-- WARNING:modpost:vmlinux:section-mismatch-in-reference:xrv64i2p1_m2p0_a2p1_c2p0_zicsr2p0_zifencei2p0_zihintpause2p0_zmmul1p0-(section:.text.unlikely.bitmap_copy)-bitmap-(section:.init.data)
|-- WARNING:modpost:vmlinux:section-mismatch-in-reference:xrv64i2p1_m2p0_a2p1_c2p0_zicsr2p0_zifencei2p0_zihintpause2p0_zmmul1p0-(section:.text.unlikely.bitmap_copy)-cp-(section:.init.data)
|-- WARNING:modpost:vmlinux:section-mismatch-in-reference:xrv64i2p1_m2p0_a2p1_c2p0_zicsr2p0_zifencei2p0_zihintpause2p0_zmmul1p0-(section:.text.unlikely.event_trigger_unlock_commit)-event_trace_file-(secti
`-- WARNING:modpost:vmlinux:section-mismatch-in-reference:xrv64i2p1_m2p0_a2p1_c2p0_zicsr2p0_zifencei2p0_zihintpause2p0_zmmul1p0-(section:.text.unlikely.set_bit)-numa_nodes_parsed-(section:.init.data)
elapsed time: 1479m
configs tested: 178
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20231213 gcc
arc randconfig-002-20231213 gcc
arm allmodconfig gcc
arm allnoconfig gcc
arm allyesconfig gcc
arm defconfig clang
arm ep93xx_defconfig clang
arm randconfig-001-20231213 clang
arm randconfig-002-20231213 clang
arm randconfig-003-20231213 clang
arm randconfig-004-20231213 clang
arm spear3xx_defconfig clang
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20231213 clang
arm64 randconfig-002-20231213 clang
arm64 randconfig-003-20231213 clang
arm64 randconfig-004-20231213 clang
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20231213 gcc
csky randconfig-002-20231213 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20231213 clang
hexagon randconfig-002-20231213 clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 buildonly-randconfig-001-20231213 clang
i386 buildonly-randconfig-002-20231213 clang
i386 buildonly-randconfig-003-20231213 clang
i386 buildonly-randconfig-004-20231213 clang
i386 buildonly-randconfig-005-20231213 clang
i386 buildonly-randconfig-006-20231213 clang
i386 defconfig gcc
i386 randconfig-001-20231213 clang
i386 randconfig-002-20231213 clang
i386 randconfig-003-20231213 clang
i386 randconfig-004-20231213 clang
i386 randconfig-005-20231213 clang
i386 randconfig-006-20231213 clang
i386 randconfig-011-20231213 gcc
i386 randconfig-012-20231213 gcc
i386 randconfig-013-20231213 gcc
i386 randconfig-014-20231213 gcc
i386 randconfig-015-20231213 gcc
i386 randconfig-016-20231213 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20231213 gcc
loongarch randconfig-002-20231213 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k mac_defconfig gcc
m68k stmark2_defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig clang
mips allyesconfig gcc
mips bcm63xx_defconfig clang
mips maltaup_xpa_defconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20231213 gcc
nios2 randconfig-002-20231213 gcc
openrisc alldefconfig gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20231213 gcc
parisc randconfig-002-20231213 gcc
parisc64 defconfig gcc
powerpc allmodconfig clang
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc asp8347_defconfig gcc
powerpc bluestone_defconfig clang
powerpc mpc834x_itx_defconfig gcc
powerpc randconfig-001-20231213 clang
powerpc randconfig-002-20231213 clang
powerpc randconfig-003-20231213 clang
powerpc warp_defconfig gcc
powerpc64 randconfig-001-20231213 clang
powerpc64 randconfig-002-20231213 clang
powerpc64 randconfig-003-20231213 clang
riscv allmodconfig gcc
riscv allnoconfig clang
riscv allyesconfig gcc
riscv defconfig gcc
riscv randconfig-001-20231213 clang
riscv randconfig-002-20231213 clang
riscv rv32_defconfig clang
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-001-20231213 gcc
s390 randconfig-002-20231213 gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh lboxre2_defconfig gcc
sh migor_defconfig gcc
sh randconfig-001-20231213 gcc
sh randconfig-002-20231213 gcc
sh se7780_defconfig gcc
sh ul2_defconfig gcc
sparc allmodconfig gcc
sparc sparc32_defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20231213 gcc
sparc64 randconfig-002-20231213 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20231213 clang
um randconfig-002-20231213 clang
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20231214 gcc
x86_64 buildonly-randconfig-002-20231214 gcc
x86_64 buildonly-randconfig-003-20231214 gcc
x86_64 buildonly-randconfig-004-20231214 gcc
x86_64 buildonly-randconfig-005-20231214 gcc
x86_64 buildonly-randconfig-006-20231214 gcc
x86_64 defconfig gcc
x86_64 randconfig-001-20231214 clang
x86_64 randconfig-002-20231214 clang
x86_64 randconfig-003-20231214 clang
x86_64 randconfig-004-20231214 clang
x86_64 randconfig-005-20231214 clang
x86_64 randconfig-006-20231214 clang
x86_64 randconfig-011-20231214 gcc
x86_64 randconfig-012-20231214 gcc
x86_64 randconfig-013-20231214 gcc
x86_64 randconfig-014-20231214 gcc
x86_64 randconfig-015-20231214 gcc
x86_64 randconfig-016-20231214 gcc
x86_64 randconfig-071-20231214 gcc
x86_64 randconfig-072-20231214 gcc
x86_64 randconfig-073-20231214 gcc
x86_64 randconfig-074-20231214 gcc
x86_64 randconfig-075-20231214 gcc
x86_64 randconfig-076-20231214 gcc
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa randconfig-001-20231213 gcc
xtensa randconfig-002-20231213 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 302393f6def10a5b28157b5d366ac2506578a049
From: kernel test robot @ 2023-12-14 5:05 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 302393f6def10a5b28157b5d366ac2506578a049 Input: vivaldi - convert to use sysfs_emit_at() API
Warning ids grouped by kconfigs:
gcc_recent_errors
|-- nios2-allmodconfig
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
`-- riscv-allmodconfig
|-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
`-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
clang_recent_errors
`-- x86_64-allmodconfig
|-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
`-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
elapsed time: 1304m
configs tested: 174
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc axs103_defconfig gcc
arc defconfig gcc
arc randconfig-001-20231213 gcc
arc randconfig-002-20231213 gcc
arm allmodconfig gcc
arm allnoconfig gcc
arm allyesconfig gcc
arm bcm2835_defconfig clang
arm defconfig clang
arm gemini_defconfig gcc
arm imxrt_defconfig gcc
arm integrator_defconfig gcc
arm randconfig-001-20231213 clang
arm randconfig-002-20231213 clang
arm randconfig-003-20231213 clang
arm randconfig-004-20231213 clang
arm vexpress_defconfig clang
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20231213 clang
arm64 randconfig-002-20231213 clang
arm64 randconfig-003-20231213 clang
arm64 randconfig-004-20231213 clang
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20231213 gcc
csky randconfig-002-20231213 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20231213 clang
hexagon randconfig-002-20231213 clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 buildonly-randconfig-001-20231213 clang
i386 buildonly-randconfig-002-20231213 clang
i386 buildonly-randconfig-003-20231213 clang
i386 buildonly-randconfig-004-20231213 clang
i386 buildonly-randconfig-005-20231213 clang
i386 buildonly-randconfig-006-20231213 clang
i386 defconfig gcc
i386 randconfig-001-20231213 clang
i386 randconfig-002-20231213 clang
i386 randconfig-003-20231213 clang
i386 randconfig-004-20231213 clang
i386 randconfig-005-20231213 clang
i386 randconfig-006-20231213 clang
i386 randconfig-011-20231213 gcc
i386 randconfig-012-20231213 gcc
i386 randconfig-013-20231213 gcc
i386 randconfig-014-20231213 gcc
i386 randconfig-015-20231213 gcc
i386 randconfig-016-20231213 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20231213 gcc
loongarch randconfig-002-20231213 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig clang
mips allyesconfig gcc
mips cavium_octeon_defconfig clang
mips rs90_defconfig clang
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20231213 gcc
nios2 randconfig-002-20231213 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20231213 gcc
parisc randconfig-002-20231213 gcc
parisc64 defconfig gcc
powerpc allmodconfig clang
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc lite5200b_defconfig clang
powerpc randconfig-001-20231213 clang
powerpc randconfig-002-20231213 clang
powerpc randconfig-003-20231213 clang
powerpc64 randconfig-001-20231213 clang
powerpc64 randconfig-002-20231213 clang
powerpc64 randconfig-003-20231213 clang
riscv allmodconfig gcc
riscv allnoconfig clang
riscv allyesconfig gcc
riscv defconfig gcc
riscv randconfig-001-20231213 clang
riscv randconfig-002-20231213 clang
riscv rv32_defconfig clang
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-001-20231213 gcc
s390 randconfig-002-20231213 gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh randconfig-001-20231213 gcc
sh randconfig-002-20231213 gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20231213 gcc
sparc64 randconfig-002-20231213 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20231213 clang
um randconfig-002-20231213 clang
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20231214 gcc
x86_64 buildonly-randconfig-002-20231214 gcc
x86_64 buildonly-randconfig-003-20231214 gcc
x86_64 buildonly-randconfig-004-20231214 gcc
x86_64 buildonly-randconfig-005-20231214 gcc
x86_64 buildonly-randconfig-006-20231214 gcc
x86_64 defconfig gcc
x86_64 randconfig-001-20231214 clang
x86_64 randconfig-002-20231214 clang
x86_64 randconfig-003-20231214 clang
x86_64 randconfig-004-20231214 clang
x86_64 randconfig-005-20231214 clang
x86_64 randconfig-006-20231214 clang
x86_64 randconfig-011-20231214 gcc
x86_64 randconfig-012-20231214 gcc
x86_64 randconfig-013-20231214 gcc
x86_64 randconfig-014-20231214 gcc
x86_64 randconfig-015-20231214 gcc
x86_64 randconfig-016-20231214 gcc
x86_64 randconfig-071-20231214 gcc
x86_64 randconfig-072-20231214 gcc
x86_64 randconfig-073-20231214 gcc
x86_64 randconfig-074-20231214 gcc
x86_64 randconfig-075-20231214 gcc
x86_64 randconfig-076-20231214 gcc
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa randconfig-001-20231213 gcc
xtensa randconfig-002-20231213 gcc
xtensa virt_defconfig gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [linux-next:master] BUILD REGRESSION 48e8992e33abf054bcc0bb2e77b2d43bb899212e
From: kernel test robot @ 2023-12-14 5:49 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Memory Management List, amd-gfx, linux-afs, linux-arch,
linux-bcachefs, linux-csky, linux-hwmon, linux-input, linux-leds,
linux-scsi, mpi3mr-linuxdrv.pdl, ntfs3, rcu, sparclinux
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 48e8992e33abf054bcc0bb2e77b2d43bb899212e Add linux-next specific files for 20231213
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202312131758.NED6TvQK-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202312131823.hO2NP34f-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202312131907.mnyTUNnO-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202312140633.nmHowPIh-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202312140939.zA3tdSi2-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202312141227.C2h1IzfI-lkp@intel.com
Error/Warning: (recently discovered and may have been fixed)
drivers/hid/hid-nintendo.c:371:13: error: initializer element is not constant
fs/afs/callback.c:106:(.text+0x308): undefined reference to `__generic_xchg_called_with_bad_pointer'
fs/afs/rotate.c:69:(.text+0x26c): undefined reference to `__generic_xchg_called_with_bad_pointer'
fs/bcachefs/btree_iter.c:1442:28: warning: variable 'path' set but not used [-Wunused-but-set-variable]
include/asm-generic/cmpxchg.h:76:(.text+0x1f6): undefined reference to `__generic_xchg_called_with_bad_pointer'
include/linux/rcupdate.h:301:(.text+0x5cb2): relocation truncated to fit: R_CKCORE_PCREL_IMM16BY4 against `__jump_table'
kernel/rcu/tree.c:2965:(.text+0x5b44): relocation truncated to fit: R_CKCORE_PCREL_IMM16BY4 against `__jump_table'
ld.lld: error: undefined symbol: __bad_xchg
Unverified Error/Warning (likely false positive, please contact us if interested):
callback.c:(.text+0x214): relocation truncated to fit: R_NIOS2_CALL26 against `__generic_xchg_called_with_bad_pointer'
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn35/dcn35_hwseq.c:1127: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
drivers/scsi/mpi3mr/mpi3mr_app.c:1091 mpi3mr_map_data_buffer_dma() warn: returning -1 instead of -ENOMEM is sloppy
drivers/scsi/mpi3mr/mpi3mr_app.c:712 mpi3mr_bsg_build_sgl() warn: missing unwind goto?
fs/bcachefs/inode.c:1171 bch2_delete_dead_inodes() error: potentially using uninitialized 'ret'.
rotate.c:(.text+0x20c): relocation truncated to fit: R_NIOS2_CALL26 against `__generic_xchg_called_with_bad_pointer'
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- alpha-allyesconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- arc-allmodconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- arc-allyesconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- arc-randconfig-r112-20231213
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- arc-randconfig-r131-20231212
| `-- drivers-hwmon-max31827.c:sparse:sparse:dubious:x-y
|-- arm-allmodconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- arm-allyesconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- csky-allmodconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- csky-allyesconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- csky-buildonly-randconfig-r005-20221115
| |-- fs-afs-callback.c:(.text):undefined-reference-to-__generic_xchg_called_with_bad_pointer
| |-- fs-afs-rotate.c:(.text):undefined-reference-to-__generic_xchg_called_with_bad_pointer
| `-- include-asm-generic-cmpxchg.h:(.text):undefined-reference-to-__generic_xchg_called_with_bad_pointer
|-- csky-randconfig-002-20231213
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- csky-randconfig-r013-20230826
| |-- include-linux-rcupdate.h:(.text):relocation-truncated-to-fit:R_CKCORE_PCREL_IMM16BY4-against-__jump_table
| `-- kernel-rcu-tree.c:(.text):relocation-truncated-to-fit:R_CKCORE_PCREL_IMM16BY4-against-__jump_table
|-- csky-randconfig-r111-20231213
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
| |-- arch-csky-kernel-vdso-vgettimeofday.c:sparse:sparse:function-__vdso_clock_gettime-with-external-linkage-has-definition
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- csky-randconfig-r113-20231213
| |-- arch-csky-kernel-vdso-vgettimeofday.c:sparse:sparse:function-__vdso_clock_gettime-with-external-linkage-has-definition
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- csky-randconfig-r121-20231213
| |-- arch-csky-kernel-vdso-vgettimeofday.c:sparse:sparse:function-__vdso_clock_gettime-with-external-linkage-has-definition
| |-- fs-bcachefs-btree_iter.c:warning:variable-path-set-but-not-used
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| |-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- i386-randconfig-014-20231213
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- i386-randconfig-015-20231213
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- i386-randconfig-016-20231213
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- loongarch-allmodconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- loongarch-defconfig
| `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-hwss-dcn35-dcn35_hwseq.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst
|-- loongarch-randconfig-001-20231213
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- m68k-allmodconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- m68k-allyesconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- microblaze-allmodconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- microblaze-allyesconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- mips-allyesconfig
| |-- fs-bcachefs-btree_iter.c:warning:variable-path-set-but-not-used
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- mips-decstation_r4k_defconfig
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
|-- nios2-allmodconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- nios2-allyesconfig
| |-- callback.c:(.text):relocation-truncated-to-fit:R_NIOS2_CALL26-against-__generic_xchg_called_with_bad_pointer
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| |-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- rotate.c:(.text):relocation-truncated-to-fit:R_NIOS2_CALL26-against-__generic_xchg_called_with_bad_pointer
|-- nios2-randconfig-001-20231213
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- nios2-randconfig-r112-20231213
| |-- fs-afs-main.c:sparse:sparse:cast-removes-address-space-__rcu-of-expression
| `-- fs-afs-main.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-struct-callback_head-head-got-struct-callback_head-noderef-__rcu
|-- openrisc-allyesconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- openrisc-randconfig-r122-20231213
| |-- fs-bcachefs-btree_iter.c:warning:variable-path-set-but-not-used
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| |-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- openrisc-randconfig-r131-20231213
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- parisc-allmodconfig
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-tty-serial-8250_parisc.o
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- parisc-allyesconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- parisc-randconfig-002-20231213
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- powerpc64-randconfig-r132-20231213
| |-- fs-bcachefs-btree_iter.c:warning:variable-path-set-but-not-used
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| |-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
| |-- lib-raid6-altivec4.c:sparse:incomplete-type-static-toplevel-unative_t
| |-- lib-raid6-altivec4.c:sparse:int-static-signed-toplevel-__preempt_count_sub(-...-)
| |-- lib-raid6-altivec4.c:sparse:int-static-signed-toplevel-disable_kernel_altivec(-...-)
| |-- lib-raid6-altivec4.c:sparse:int-static-toplevel-unative_t
| |-- lib-raid6-altivec8.c:sparse:incomplete-type-static-toplevel-unative_t
| |-- lib-raid6-altivec8.c:sparse:int-static-signed-toplevel-__preempt_count_sub(-...-)
| |-- lib-raid6-altivec8.c:sparse:int-static-signed-toplevel-disable_kernel_altivec(-...-)
| |-- lib-raid6-altivec8.c:sparse:int-static-toplevel-unative_t
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- powerpc64-randconfig-r133-20231213
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- riscv-allmodconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- riscv-allyesconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- s390-allmodconfig
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-s390-block-dasd_diag_mod.o
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-s390-block-dasd_eckd_mod.o
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-s390-block-dasd_fba_mod.o
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- s390-allyesconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- s390-defconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- s390-randconfig-001-20231213
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- sh-allmodconfig
| |-- fs-bcachefs-btree_iter.c:warning:variable-path-set-but-not-used
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- sh-allyesconfig
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- sparc-allmodconfig
| |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
| |-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- sparc-allnoconfig
| |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
| `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-defconfig
| |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
| |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
| `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-randconfig-001-20231213
| |-- (.head.text):relocation-truncated-to-fit:R_SPARC_WDISP22-against-init.text
| |-- (.init.text):relocation-truncated-to-fit:R_SPARC_WDISP22-against-symbol-leon_smp_cpu_startup-defined-in-.text-section-in-arch-sparc-kernel-trampoline_32.o
| |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
| `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-randconfig-002-20231213
| |-- (.head.text):relocation-truncated-to-fit:R_SPARC_WDISP22-against-init.text
| |-- (.init.text):relocation-truncated-to-fit:R_SPARC_WDISP22-against-symbol-leon_smp_cpu_startup-defined-in-.text-section-in-arch-sparc-kernel-trampoline_32.o
| |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
| |-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
| |-- parport_pc.c:(.text):undefined-reference-to-ebus_dma_irq_enable
| |-- parport_pc.c:(.text):undefined-reference-to-ebus_dma_register
| |-- sparc-linux-ld:parport_pc.c:(.text):undefined-reference-to-ebus_dma_irq_enable
| |-- sparc-linux-ld:parport_pc.c:(.text):undefined-reference-to-ebus_dma_unregister
| `-- sparc-linux-ld:parport_pc.c:(.text):undefined-reference-to-ns87303_lock
|-- sparc-randconfig-r123-20231213
| |-- (.head.text):relocation-truncated-to-fit:R_SPARC_WDISP22-against-init.text
| |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
| |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
| |-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
| |-- fs-ntfs3-ntfs.h:sparse:sparse:static-assertion-failed:sizeof(struct-ATTR_LIST_ENTRY)
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- sparc-sparc32_defconfig
| |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
| |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
| `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-sparc64_defconfig
| |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
| `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-allmodconfig
| |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
| |-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- sparc64-allyesconfig
| |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
| |-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- sparc64-defconfig
| |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
| `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-randconfig-001-20231213
| |-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
| |-- fs-bcachefs-btree_iter.c:warning:variable-path-set-but-not-used
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- sparc64-randconfig-002-20231213
| |-- fs-bcachefs-btree_iter.c:warning:variable-path-set-but-not-used
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
|-- x86_64-allnoconfig
| `-- Warning:MAINTAINERS-references-a-file-that-doesn-t-exist:Documentation-devicetree-bindings-display-panel-synaptics-r63353.yaml
|-- x86_64-randconfig-016-20231214
| `-- drivers-hid-hid-nintendo.c:error:initializer-element-is-not-constant
|-- x86_64-randconfig-122-20231213
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- x86_64-randconfig-123-20231213
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| |-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- x86_64-randconfig-161-20231214
| |-- drivers-scsi-mpi3mr-mpi3mr_app.c-mpi3mr_bsg_build_sgl()-warn:missing-unwind-goto
| `-- drivers-scsi-mpi3mr-mpi3mr_app.c-mpi3mr_map_data_buffer_dma()-warn:returning-instead-of-ENOMEM-is-sloppy
|-- xtensa-randconfig-001-20231213
| |-- fs-bcachefs-btree_iter.c:warning:variable-path-set-but-not-used
| |-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
| `-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
`-- xtensa-randconfig-002-20231213
|-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
|-- fs-bcachefs-btree_iter.c:warning:variable-path-set-but-not-used
|-- fs-bcachefs-chardev.c:warning:function-run_thread_with_file-might-be-a-candidate-for-gnu_printf-format-attribute
`-- fs-bcachefs-super.c:warning:function-__bch2_print-might-be-a-candidate-for-gnu_printf-format-attribute
clang_recent_errors
|-- arm-defconfig
| |-- WARNING:modpost:vmlinux:section-mismatch-in-reference:at91_poweroff_probe-(section:.text)-at91_wakeup_status-(section:.init.text)
| `-- WARNING:modpost:vmlinux:section-mismatch-in-reference:at91_shdwc_probe-(section:.text)-at91_wakeup_status-(section:.init.text)
|-- arm-randconfig-003-20231213
| `-- ld.lld:error:undefined-symbol:__bad_xchg
|-- arm64-allmodconfig
| `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- arm64-allyesconfig
| `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- hexagon-allmodconfig
| `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- hexagon-allyesconfig
| `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- i386-allmodconfig
| |-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
| `-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
|-- i386-allyesconfig
| |-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
| `-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
|-- i386-buildonly-randconfig-001-20231213
| `-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
|-- i386-buildonly-randconfig-002-20231213
| `-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
|-- i386-randconfig-001-20231213
| `-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
|-- i386-randconfig-002-20231213
| `-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
|-- i386-randconfig-003-20231213
| `-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
|-- i386-randconfig-004-20231213
| `-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
|-- i386-randconfig-006-20231213
| `-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
|-- i386-randconfig-054-20231213
| `-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
|-- i386-randconfig-062-20231213
| |-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- i386-randconfig-063-20231213
| |-- fs-ntfs3-ntfs.h:error:static-assertion-failed-due-to-requirement-sizeof(struct-ATTR_LIST_ENTRY):sizeof(struct-ATTR_LIST_ENTRY)
| `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- i386-randconfig-141-20231213
| |-- lib-zstd-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
| |-- lib-zstd-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
| |-- lib-zstd-decompress-..-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
| |-- lib-zstd-decompress-..-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
| `-- lib-zstd-decompress-..-common-bits.h-ZSTD_countTrailingZeros64()-warn:inconsistent-indenting
|-- powerpc-allmodconfig
| `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- powerpc-allyesconfig
| `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- powerpc-randconfig-003-20231213
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
|-- x86_64-allmodconfig
| `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- x86_64-allyesconfig
| `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- x86_64-buildonly-randconfig-002-20231213
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
`-- x86_64-randconfig-161-20231213
|-- fs-bcachefs-inode.c-bch2_delete_dead_inodes()-error:potentially-using-uninitialized-ret-.
|-- lib-zstd-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
|-- lib-zstd-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
|-- lib-zstd-compress-..-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
|-- lib-zstd-compress-..-common-bits.h-ZSTD_countLeadingZeros64()-warn:inconsistent-indenting
|-- lib-zstd-compress-..-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
|-- lib-zstd-compress-..-common-bits.h-ZSTD_countTrailingZeros64()-warn:inconsistent-indenting
|-- lib-zstd-decompress-..-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
`-- lib-zstd-decompress-..-common-bits.h-ZSTD_countTrailingZeros64()-warn:inconsistent-indenting
elapsed time: 1477m
configs tested: 178
configs skipped: 2
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20231213 gcc
arc randconfig-002-20231213 gcc
arm allmodconfig gcc
arm allnoconfig gcc
arm allyesconfig gcc
arm axm55xx_defconfig gcc
arm defconfig clang
arm hisi_defconfig gcc
arm imx_v4_v5_defconfig clang
arm lpc18xx_defconfig gcc
arm randconfig-001-20231213 clang
arm randconfig-002-20231213 clang
arm randconfig-003-20231213 clang
arm randconfig-004-20231213 clang
arm spear3xx_defconfig clang
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20231213 clang
arm64 randconfig-002-20231213 clang
arm64 randconfig-003-20231213 clang
arm64 randconfig-004-20231213 clang
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20231213 gcc
csky randconfig-002-20231213 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20231213 clang
hexagon randconfig-002-20231213 clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 buildonly-randconfig-001-20231213 clang
i386 buildonly-randconfig-002-20231213 clang
i386 buildonly-randconfig-003-20231213 clang
i386 buildonly-randconfig-004-20231213 clang
i386 buildonly-randconfig-005-20231213 clang
i386 buildonly-randconfig-006-20231213 clang
i386 defconfig gcc
i386 randconfig-001-20231213 clang
i386 randconfig-002-20231213 clang
i386 randconfig-003-20231213 clang
i386 randconfig-004-20231213 clang
i386 randconfig-005-20231213 clang
i386 randconfig-006-20231213 clang
i386 randconfig-011-20231213 gcc
i386 randconfig-012-20231213 gcc
i386 randconfig-013-20231213 gcc
i386 randconfig-014-20231213 gcc
i386 randconfig-015-20231213 gcc
i386 randconfig-016-20231213 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20231213 gcc
loongarch randconfig-002-20231213 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig clang
mips allyesconfig gcc
mips decstation_r4k_defconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20231213 gcc
nios2 randconfig-002-20231213 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20231213 gcc
parisc randconfig-002-20231213 gcc
parisc64 defconfig gcc
powerpc acadia_defconfig clang
powerpc allmodconfig clang
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc randconfig-001-20231213 clang
powerpc randconfig-002-20231213 clang
powerpc randconfig-003-20231213 clang
powerpc tqm8541_defconfig gcc
powerpc tqm8xx_defconfig gcc
powerpc64 randconfig-001-20231213 clang
powerpc64 randconfig-002-20231213 clang
powerpc64 randconfig-003-20231213 clang
riscv allmodconfig gcc
riscv allnoconfig clang
riscv allyesconfig gcc
riscv defconfig gcc
riscv nommu_k210_defconfig gcc
riscv randconfig-001-20231213 clang
riscv randconfig-002-20231213 clang
riscv rv32_defconfig clang
s390 alldefconfig clang
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-001-20231213 gcc
s390 randconfig-002-20231213 gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh randconfig-001-20231213 gcc
sh randconfig-002-20231213 gcc
sh rsk7264_defconfig gcc
sh sdk7786_defconfig gcc
sh se7619_defconfig gcc
sparc allmodconfig gcc
sparc sparc32_defconfig gcc
sparc sparc64_defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20231213 gcc
sparc64 randconfig-002-20231213 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20231213 clang
um randconfig-002-20231213 clang
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20231213 clang
x86_64 buildonly-randconfig-002-20231213 clang
x86_64 buildonly-randconfig-003-20231213 clang
x86_64 buildonly-randconfig-004-20231213 clang
x86_64 buildonly-randconfig-005-20231213 clang
x86_64 buildonly-randconfig-006-20231213 clang
x86_64 defconfig gcc
x86_64 randconfig-001-20231213 gcc
x86_64 randconfig-002-20231213 gcc
x86_64 randconfig-003-20231213 gcc
x86_64 randconfig-004-20231213 gcc
x86_64 randconfig-005-20231213 gcc
x86_64 randconfig-006-20231213 gcc
x86_64 randconfig-011-20231213 clang
x86_64 randconfig-012-20231213 clang
x86_64 randconfig-013-20231213 clang
x86_64 randconfig-014-20231213 clang
x86_64 randconfig-015-20231213 clang
x86_64 randconfig-016-20231213 clang
x86_64 randconfig-071-20231213 clang
x86_64 randconfig-072-20231213 clang
x86_64 randconfig-073-20231213 clang
x86_64 randconfig-074-20231213 clang
x86_64 randconfig-075-20231213 clang
x86_64 randconfig-076-20231213 clang
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa randconfig-001-20231213 gcc
xtensa randconfig-002-20231213 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v6 0/8] Convert DA906{1,2} bindings to json-schema
From: Biju Das @ 2023-12-14 8:09 UTC (permalink / raw)
To: Lee Jones, Wim Van Sebroeck, Guenter Roeck, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Biju Das, Support Opensource, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Steve Twiss, linux-input, devicetree,
linux-pm, linux-watchdog, Geert Uytterhoeven,
Prabhakar Mahadev Lad, Biju Das, linux-renesas-soc
Convert the below bindings to json-schema
1) DA906{1,2} mfd bindings
2) DA906{1,2,3} onkey bindings
3) DA906{1,2,3} thermal bindings
Also add fallback for DA9061 watchdog device and document
DA9063 watchdog device.
Document missing gpio child node for da9062 and update MAINTAINERS entries.
Merge strategy:
Since there is binding dependency between input, thermal, watchdog and MFD
subsystem. it is decided that this series will go through the MFD tree.
So once the respective subsystem maintainers, DT and Renesas are happy
with the patch they can give an ack/rb tag, so that it can be applied to
MFD tree.
Note:
This patch series is same as v3.1 as it allows the tools (PW, b4)
to compare against previous versions.
The review comments/tags received for v4 + (a.k.a v3.1) will be
addressed in the next version(v5).
Link to v3.1: https://lore.kernel.org/all/20231204172510.35041-1-biju.das.jz@bp.renesas.com/
v5->v6:
* Added Rb tag from Guenter Roeck for watchdog binding patches.
* Updated commit description related to "gpio-controller" and
"#gpio-cells" properties defined in parent node.
* Added Rb tag from Krzysztof Kozlowski for patch#8.
v4->v5:
* Updated cover letter with merging strategy.
* Added fixes tag for patch#1
* Added Rb tags from Geert and Krzysztof for patch#1
* Added Ack from Conor for patch#1
* Added Rb tag from Geert and Ack from Conor for patch#2
* Drop items and just use enum as it is easier to read for compatibles.
* Retained the tags for patch#2 as it is trivial change.
* Added Rb tag from Geert for patch#3
* Updated commit header and description by replacing
'watchdog property'->'watchdog child node'
* Added Rb tag from Geert for patch#4.
* Added Rb tag from Krzysztof and Conor for patch#5
* Dropped Items, Just enum as it is easier to read compatibles.
* Retained tags for patch#5 as the changes are trivial.
* Updated commit description for patch#8
* Dropped unnecessary ref from gpio child node.
* Added gpio-hog pattern property
* Moved gpio-controller,gpio-cells above child nodes
* Sorted compatible in rtc child node.
* Dropped status from example.
* Updated the example.
v3->v4:
* Patch#1 is merge of patch#1 from v2 + patch#8 from v2.
* Dropped comment for d9061 watchdog fallback
* Replaced enum->const for dlg,da9061-watchdog and its fallback.
* Restored patch#4 in series 1 and dropped the thermal example
* Added Ack from Conor Dooley for da9063 watchdog binding support.
* Updated title DA9062/61->DA906{1,2,3} as it supports DA9063.
* Retained Rb tag since the changes are trivial.
* Added Ack from Conor for updating watchdog property
* Dropped link to product information.
* Patch#5(onkey) is squashed with patch#6 and patch#9 from v2.
* Replaced enum->const for dlg,da9061-onkey and its fallback.
* Dropped example
* Restored the thermal binding patch from v2.
* Dropped example
* Replaced enum->const for compatible property.
* Added Rb tag from Rob and retained Rb tag as changes are trivial.
* Added Ack from Conor Dooley for patch#7.
* Split the thermal binding patch separate
* Updated the description
v2->v3:
* Updated Maintainer entries for watchdog,onkey and thermal bindings
* Fixed bot errors related to MAINTAINERS entry, invalid doc
references and thermal examples by merging patch#4.
v1->v2:
Link: https://lore.kernel.org/all/20231201110840.37408-5-biju.das.jz@bp.renesas.com/
* DA9062 and DA9061 merged with DA9063
* Sorted the child devices
* mfd,onkey and thermal are pointing to child bindings
Biju Das (8):
dt-bindings: mfd: da9062: Update watchdog description
dt-bindings: watchdog: dlg,da9062-watchdog: Add fallback for DA9061
watchdog
dt-bindings: watchdog: dlg,da9062-watchdog: Document DA9063 watchdog
dt-bindings: mfd: dlg,da9063: Update watchdog child node
dt-bindings: input: Convert da906{1,2,3} onkey to json-schema
dt-bindings: thermal: Convert da906{1,2} thermal to json-schema
dt-bindings: mfd: dlg,da9063: Sort child devices
dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
.../bindings/input/da9062-onkey.txt | 47 ----
.../bindings/input/dlg,da9062-onkey.yaml | 38 +++
.../devicetree/bindings/mfd/da9062.txt | 124 ---------
.../devicetree/bindings/mfd/dlg,da9063.yaml | 248 +++++++++++++++---
.../bindings/thermal/da9062-thermal.txt | 36 ---
.../bindings/thermal/dlg,da9062-thermal.yaml | 35 +++
.../watchdog/dlg,da9062-watchdog.yaml | 12 +-
MAINTAINERS | 6 +-
8 files changed, 298 insertions(+), 248 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt
create mode 100644 Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/da9062.txt
delete mode 100644 Documentation/devicetree/bindings/thermal/da9062-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml
--
2.39.2
^ permalink raw reply
* [PATCH v6 5/8] dt-bindings: input: Convert da906{1,2,3} onkey to json-schema
From: Biju Das @ 2023-12-14 8:09 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Biju Das, Support Opensource, linux-input, devicetree,
Geert Uytterhoeven, Prabhakar Mahadev Lad, Biju Das,
linux-renesas-soc, Conor Dooley, Krzysztof Kozlowski
In-Reply-To: <20231214080911.23359-1-biju.das.jz@bp.renesas.com>
Convert the da906{1,2,3} onkey device tree binding documentation to
json-schema.
Update MAINTAINERS entries, description and onkey property by
referring to dlg,da9062-onkey binding file.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
v5->v6:
* No change.
v4->v5:
* Added Rb tag from Krzysztof and Conor
* Dropped Items, Just enum as it is easier to read compatibles.
* Retained tags as the changes are trivial.
v3->v4:
* Squashed with patch#6 and patch#9 from v2.
* Replaced enum->const for dlg,da9061-onkey and its fallback.
* Dropped example
v2->v3:
* Updated MAINTAINERS entries.
v2:
* New patch
---
.../bindings/input/da9062-onkey.txt | 47 -------------------
.../bindings/input/dlg,da9062-onkey.yaml | 39 +++++++++++++++
.../devicetree/bindings/mfd/da9062.txt | 2 +-
.../devicetree/bindings/mfd/dlg,da9063.yaml | 15 +-----
MAINTAINERS | 2 +-
5 files changed, 42 insertions(+), 63 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt
create mode 100644 Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt b/Documentation/devicetree/bindings/input/da9062-onkey.txt
deleted file mode 100644
index e5eef59a93dc..000000000000
--- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Dialog DA9061/62/63 OnKey Module
-
-This module is part of the DA9061/DA9062/DA9063. For more details about entire
-DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
-For DA9063 see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
-
-This module provides the KEY_POWER event.
-
-Required properties:
-
-- compatible: should be one of the following valid compatible string lines:
- "dlg,da9061-onkey", "dlg,da9062-onkey"
- "dlg,da9062-onkey"
- "dlg,da9063-onkey"
-
-Optional properties:
-
-- dlg,disable-key-power : Disable power-down using a long key-press. If this
- entry exists the OnKey driver will remove support for the KEY_POWER key
- press when triggered using a long press of the OnKey.
-
-Example: DA9063
-
- pmic0: da9063@58 {
- onkey {
- compatible = "dlg,da9063-onkey";
- dlg,disable-key-power;
- };
- };
-
-Example: DA9062
-
- pmic0: da9062@58 {
- onkey {
- compatible = "dlg,da9062-onkey";
- dlg,disable-key-power;
- };
- };
-
-Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
-
- pmic0: da9061@58 {
- onkey {
- compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";
- dlg,disable-key-power;
- };
- };
diff --git a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
new file mode 100644
index 000000000000..757a522c102c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/dlg,da9062-onkey.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog DA9061/62/63 OnKey Module
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ This module is part of the DA9061/DA9062/DA9063. For more details about entire
+ DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
+ For DA9063 see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
+
+ This module provides the KEY_POWER event.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - dlg,da9062-onkey
+ - dlg,da9063-onkey
+ - items:
+ - const: dlg,da9061-onkey
+ - const: dlg,da9062-onkey
+
+ dlg,disable-key-power:
+ type: boolean
+ description:
+ Disable power-down using a long key-press. If this entry exists
+ the OnKey driver will remove support for the KEY_POWER key press
+ when triggered using a long press of the OnKey.
+
+required:
+ - compatible
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt
index 18463b7fbb42..154c31fa4443 100644
--- a/Documentation/devicetree/bindings/mfd/da9062.txt
+++ b/Documentation/devicetree/bindings/mfd/da9062.txt
@@ -84,7 +84,7 @@ Sub-nodes:
with the DA9062. There are currently no entries in this binding, however
compatible = "dlg,da9062-rtc" should be added if a node is created.
-- onkey : See ../input/da9062-onkey.txt
+- onkey : See ../input/dlg,da9062-onkey.yaml
- watchdog: See ../watchdog/dlg,da9062-watchdog.yaml
diff --git a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
index ce81e0b029cc..1e5a847a6be2 100644
--- a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
+++ b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
@@ -44,20 +44,7 @@ properties:
const: dlg,da9063-rtc
onkey:
- type: object
- $ref: /schemas/input/input.yaml#
- unevaluatedProperties: false
- properties:
- compatible:
- const: dlg,da9063-onkey
-
- dlg,disable-key-power:
- type: boolean
- description: |
- Disable power-down using a long key-press.
- If this entry does not exist then by default the key-press triggered
- power down is enabled and the OnKey will support both KEY_POWER and
- KEY_SLEEP.
+ $ref: /schemas/input/dlg,da9062-onkey.yaml
regulators:
type: object
diff --git a/MAINTAINERS b/MAINTAINERS
index 093a8270a752..70bea5ff209a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6112,8 +6112,8 @@ DIALOG SEMICONDUCTOR DRIVERS
M: Support Opensource <support.opensource@diasemi.com>
S: Supported
W: http://www.dialog-semiconductor.com/products
-F: Documentation/devicetree/bindings/input/da90??-onkey.txt
F: Documentation/devicetree/bindings/input/dlg,da72??.txt
+F: Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
F: Documentation/devicetree/bindings/mfd/da90*.txt
F: Documentation/devicetree/bindings/mfd/dlg,da90*.yaml
F: Documentation/devicetree/bindings/regulator/da92*.txt
--
2.39.2
^ permalink raw reply related
* [PATCH v6 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
From: Biju Das @ 2023-12-14 8:09 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones
Cc: Biju Das, Support Opensource, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Steve Twiss, linux-input, devicetree,
linux-pm, Geert Uytterhoeven, Prabhakar Mahadev Lad, Biju Das,
linux-renesas-soc, Krzysztof Kozlowski
In-Reply-To: <20231214080911.23359-1-biju.das.jz@bp.renesas.com>
Convert the da9062 PMIC device tree binding documentation to json-schema.
Document the missing gpio child node for da9062.
While at it, update description with link to product information and
example.
The missing child node with of_compatible defined in MFD_CELL_OF is
causing the below warning message:
da9062-gpio: Failed to locate of_node [id: -1]
So, make all child nodes with of_compatible defined in struct mfd_cell
as required property for da906{1,2} devices.
The "gpio-controller" and "#gpio-cells" properties are defined in the
parent instead of gpio child node as there are existing driver users
based on these parent properties.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
v5->v6:
* Updated commit description related to "gpio-controller" and
"#gpio-cells" properties defined in parent node.
* Added Rb tag from Krzysztof Kozlowski.
v4->v5:
* Updated commit description
* Dropped unnecessary ref from gpio child node.
* Added gpio-hog pattern property
* Moved gpio-controller,gpio-cells above child nodes
* Sorted compatible in rtc child node.
* Dropped status from example.
* Updated the example.
v3->v4:
* Split the thermal binding patch separate.
* Updated the description.
v2->v3:
* Fixed bot errors related to MAINTAINERS entry, invalid doc
references and thermal examples by merging patch#4.
v2:
* New patch
---
.../bindings/input/dlg,da9062-onkey.yaml | 3 +-
.../devicetree/bindings/mfd/da9062.txt | 124 ----------
.../devicetree/bindings/mfd/dlg,da9063.yaml | 215 +++++++++++++++++-
.../bindings/thermal/dlg,da9062-thermal.yaml | 2 +-
4 files changed, 212 insertions(+), 132 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mfd/da9062.txt
diff --git a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
index 757a522c102c..1480d95421e1 100644
--- a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
+++ b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
@@ -11,8 +11,7 @@ maintainers:
description: |
This module is part of the DA9061/DA9062/DA9063. For more details about entire
- DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
- For DA9063 see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
+ DA906{1,2,3} chips see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
This module provides the KEY_POWER event.
diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt
deleted file mode 100644
index c8a7f119ac84..000000000000
--- a/Documentation/devicetree/bindings/mfd/da9062.txt
+++ /dev/null
@@ -1,124 +0,0 @@
-* Dialog DA9062 Power Management Integrated Circuit (PMIC)
-
-Product information for the DA9062 and DA9061 devices can be found here:
-- https://www.dialog-semiconductor.com/products/da9062
-- https://www.dialog-semiconductor.com/products/da9061
-
-The DA9062 PMIC consists of:
-
-Device Supply Names Description
------- ------------ -----------
-da9062-regulator : : LDOs & BUCKs
-da9062-rtc : : Real-Time Clock
-da9062-onkey : : On Key
-da9062-watchdog : : Watchdog Timer
-da9062-thermal : : Thermal
-da9062-gpio : : GPIOs
-
-The DA9061 PMIC consists of:
-
-Device Supply Names Description
------- ------------ -----------
-da9062-regulator : : LDOs & BUCKs
-da9062-onkey : : On Key
-da9062-watchdog : : Watchdog Timer
-da9062-thermal : : Thermal
-
-======
-
-Required properties:
-
-- compatible : Should be
- "dlg,da9062" for DA9062
- "dlg,da9061" for DA9061
-- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
- modified to match the chip's OTP settings).
-
-Optional properties:
-
-- gpio-controller : Marks the device as a gpio controller.
-- #gpio-cells : Should be two. The first cell is the pin number and the
- second cell is used to specify the gpio polarity.
-
-See Documentation/devicetree/bindings/gpio/gpio.txt for further information on
-GPIO bindings.
-
-- interrupts : IRQ line information.
-- interrupt-controller
-
-See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
-further information on IRQ bindings.
-
-Sub-nodes:
-
-- regulators : This node defines the settings for the LDOs and BUCKs.
- The DA9062 regulators are bound using their names listed below:
-
- buck1 : BUCK_1
- buck2 : BUCK_2
- buck3 : BUCK_3
- buck4 : BUCK_4
- ldo1 : LDO_1
- ldo2 : LDO_2
- ldo3 : LDO_3
- ldo4 : LDO_4
-
- The DA9061 regulators are bound using their names listed below:
-
- buck1 : BUCK_1
- buck2 : BUCK_2
- buck3 : BUCK_3
- ldo1 : LDO_1
- ldo2 : LDO_2
- ldo3 : LDO_3
- ldo4 : LDO_4
-
- The component follows the standard regulator framework and the bindings
- details of individual regulator device can be found in:
- Documentation/devicetree/bindings/regulator/regulator.txt
-
- regulator-initial-mode may be specified for buck regulators using mode values
- from include/dt-bindings/regulator/dlg,da9063-regulator.h.
-
-- rtc : This node defines settings required for the Real-Time Clock associated
- with the DA9062. There are currently no entries in this binding, however
- compatible = "dlg,da9062-rtc" should be added if a node is created.
-
-- onkey : See ../input/dlg,da9062-onkey.yaml
-
-- watchdog: See ../watchdog/dlg,da9062-watchdog.yaml
-
-- thermal : See ../thermal/dlg,da9062-thermal.yaml
-
-Example:
-
- pmic0: da9062@58 {
- compatible = "dlg,da9062";
- reg = <0x58>;
- interrupt-parent = <&gpio6>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
- interrupt-controller;
-
- rtc {
- compatible = "dlg,da9062-rtc";
- };
-
- regulators {
- DA9062_BUCK1: buck1 {
- regulator-name = "BUCK1";
- regulator-min-microvolt = <300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <500000>;
- regulator-max-microamp = <2000000>;
- regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
- regulator-boot-on;
- };
- DA9062_LDO1: ldo1 {
- regulator-name = "LDO_1";
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <3600000>;
- regulator-boot-on;
- };
- };
- };
-
diff --git a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
index 676b4f2566ae..da741c999445 100644
--- a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
+++ b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/dlg,da9063.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Dialog DA9063/DA9063L Power Management Integrated Circuit (PMIC)
+title: Dialog DA906{3L,3,2,1} Power Management Integrated Circuit (PMIC)
maintainers:
- Steve Twiss <stwiss.opensource@diasemi.com>
@@ -17,10 +17,17 @@ description: |
moment where all voltage monitors are disabled. Next, as da9063 only supports
UV *and* OV monitoring, both must be set to the same severity and value
(0: disable, 1: enable).
+ Product information for the DA906{3L,3,2,1} devices can be found here:
+ - https://www.dialog-semiconductor.com/products/da9063l
+ - https://www.dialog-semiconductor.com/products/da9063
+ - https://www.dialog-semiconductor.com/products/da9062
+ - https://www.dialog-semiconductor.com/products/da9061
properties:
compatible:
enum:
+ - dlg,da9061
+ - dlg,da9062
- dlg,da9063
- dlg,da9063l
@@ -35,6 +42,18 @@ properties:
"#interrupt-cells":
const: 2
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio:
+ type: object
+ additionalProperties: false
+ properties:
+ compatible:
+ const: dlg,da9062-gpio
+
onkey:
$ref: /schemas/input/dlg,da9062-onkey.yaml
@@ -42,7 +61,7 @@ properties:
type: object
additionalProperties: false
patternProperties:
- "^(ldo([1-9]|1[01])|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged)$":
+ "^(ldo([1-9]|1[01])|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged|buck[1-4])$":
$ref: /schemas/regulator/regulator.yaml
unevaluatedProperties: false
@@ -52,16 +71,85 @@ properties:
unevaluatedProperties: false
properties:
compatible:
- const: dlg,da9063-rtc
+ enum:
+ - dlg,da9062-rtc
+ - dlg,da9063-rtc
+
+ thermal:
+ $ref: /schemas/thermal/dlg,da9062-thermal.yaml
watchdog:
$ref: /schemas/watchdog/dlg,da9062-watchdog.yaml
+patternProperties:
+ "^(.+-hog(-[0-9]+)?)$":
+ type: object
+
+ required:
+ - gpio-hog
+
required:
- compatible
- reg
- - interrupts
- - interrupt-controller
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - dlg,da9063
+ - dlg,da9063l
+ then:
+ properties:
+ gpio-controller: false
+ "#gpio-cells": false
+ gpio: false
+ regulators:
+ patternProperties:
+ "^buck[1-4]$": false
+ thermal: false
+ required:
+ - interrupts
+ - interrupt-controller
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - dlg,da9062
+ then:
+ properties:
+ regulators:
+ patternProperties:
+ "^(ldo([5-9]|10|11)|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged)$": false
+ required:
+ - gpio
+ - onkey
+ - rtc
+ - thermal
+ - watchdog
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - dlg,da9061
+ then:
+ properties:
+ gpio-controller: false
+ "#gpio-cells": false
+ gpio: false
+ regulators:
+ patternProperties:
+ "^(ldo([5-9]|10|11)|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged|buck4)$": false
+ rtc: false
+ required:
+ - onkey
+ - thermal
+ - watchdog
additionalProperties: false
@@ -118,4 +206,121 @@ examples:
};
};
};
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/regulator/dlg,da9063-regulator.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic@58 {
+ compatible = "dlg,da9062";
+ reg = <0x58>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ sd0-pwr-sel-hog {
+ gpio-hog;
+ gpios = <1 0>;
+ input;
+ line-name = "SD0_PWR_SEL";
+ };
+
+ sd1-pwr-sel-hog {
+ gpio-hog;
+ gpios = <2 0>;
+ input;
+ line-name = "SD1_PWR_SEL";
+ };
+
+ sw-et0-en-hog {
+ gpio-hog;
+ gpios = <3 0>;
+ input;
+ line-name = "SW_ET0_EN#";
+ };
+
+ pmic-good-hog {
+ gpio-hog;
+ gpios = <4 0>;
+ output-high;
+ line-name = "PMIC_PGOOD";
+ };
+
+ gpio {
+ compatible = "dlg,da9062-gpio";
+ };
+
+ onkey {
+ compatible = "dlg,da9062-onkey";
+ };
+
+ regulators {
+ buck1 {
+ regulator-name = "vdd_arm";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ buck2 {
+ regulator-name = "vdd_soc";
+ regulator-min-microvolt = <1150000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ buck3 {
+ regulator-name = "vdd_ddr3";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ buck4 {
+ regulator-name = "vdd_eth";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ ldo1 {
+ regulator-name = "vdd_snvs";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+ ldo2 {
+ regulator-name = "vdd_high";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+ ldo3 {
+ regulator-name = "vdd_eth_io";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+ ldo4 {
+ regulator-name = "vdd_emmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+ };
+
+ rtc {
+ compatible = "dlg,da9062-rtc";
+ };
+
+ thermal {
+ compatible = "dlg,da9062-thermal";
+ };
+
+ watchdog {
+ compatible = "dlg,da9062-watchdog";
+ dlg,use-sw-pm;
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml b/Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml
index 206635f74850..e8b2cac41084 100644
--- a/Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml
@@ -11,7 +11,7 @@ maintainers:
description: |
This module is part of the DA9061/DA9062. For more details about entire
- DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
+ DA906{1,2} chips see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
Junction temperature thermal module uses an interrupt signal to identify
high THERMAL_TRIP_HOT temperatures for the PMIC device.
--
2.39.2
^ permalink raw reply related
* Re: [PATCH] irq: Resolve that mask_irq/unmask_irq may not be called in pairs
From: Serge Semin @ 2023-12-14 10:06 UTC (permalink / raw)
To: xiongxin, Thomas Gleixner
Cc: jikos, benjamin.tissoires, linux-input, stable, Riwen Lu, hoan,
linus.walleij, brgl, andy, linux-gpio, linux-kernel
In-Reply-To: <1844c927-2dd4-49b4-a6c4-c4c176b1f75d@kylinos.cn>
Hi Thomas, Xiong
On Thu, Dec 14, 2023 at 09:54:06AM +0800, xiongxin wrote:
> 在 2023/12/13 22:59, Thomas Gleixner 写道:
> > On Wed, Dec 13 2023 at 10:29, xiongxin wrote:
> > > 在 2023/12/12 23:17, Thomas Gleixner 写道:
> > > Sorry, the previous reply may not have clarified the BUG process. I
> > > re-debugged and confirmed it yesterday. The current BUG execution
> > > sequence is described as follows:
> >
> > It's the sequence how this works and it works correctly.
> >
> > Just because it does not work on your machine it does not mean that this
> > is incorrect and a BUG.
> >
> > You are trying to fix a symptom and thereby violating guarantees of the
> > core code.
> >
> > > That is, there is a time between the 1:handle_level_irq() and
> > > 3:irq_thread_fn() calls for the 2:disable_irq() call to acquire the lock
> > > and then implement the irq_state_set_disabled() operation. When finally
> > > call irq_thread_fn()->irq_finalize_oneshot(), it cannot enter the
> > > unmask_thread_irq() process.
> >
> > Correct, because the interrupt has been DISABLED in the mean time.
> >
> > > In this case, the gpio irq_chip irq_mask()/irq_unmask() callback pairs
> > > are not called in pairs, so I think this is a BUG, but not necessarily
> > > fixed from the irq core code layer.
> >
> > No. It is _NOT_ a BUG. unmask() is not allowed to be invoked when the
> > interrupt is DISABLED. That's the last time I'm going to tell you that.
> > Only enable_irq() can undo the effect of disable_irq(), period.
> >
> > > Next, when the gpio controller driver calls the suspend/resume process,
> > > it is as follows:
> > >
> > > suspend process:
> > > dwapb_gpio_suspend()
> > > ctx->int_mask = dwapb_read(gpio, GPIO_INTMASK);
> > >
> > > resume process:
> > > dwapb_gpio_resume()
> > > dwapb_write(gpio, GPIO_INTMASK, ctx->int_mask);
> >
> > Did you actually look at the sequence I gave you?
> >
> > Suspend:
> >
> > i2c_hid_core_suspend()
> > disable_irq(); <- Marks it disabled and eventually
> > masks it.
> >
> > gpio_irq_suspend()
> > save_registers(); <- Saves masked interrupt
> >
> > Resume:
> >
> > gpio_irq_resume()
> > restore_registers(); <- Restores masked interrupt
> >
> > i2c_hid_core_resume()
> > enable_irq(); <- Unmasks interrupt and removes the
> > disabled marker
> >
> >
> > Have you verified that this order of invocations is what happens on
> > your machine?
> >
> > Thanks,
> >
> > tglx
>
> As described earlier, in the current situation, the irq_mask() callback of
> gpio irq_chip is called in mask_irq(), followed by the disable_irq() in
> i2c_hid_core_suspend(), unmask_irq() will not be executed.
>
> Then call enable_irq() in i2c_hid_core_resume(). Since gpio irq_chip does
> not implement the irq_startup() callback, it ends up calling irq_enable().
>
> The irq_enable() function is then implemented as follows:
>
> irq_state_clr_disabled(desc);
> if (desc->irq_data.chip->irq_enable) {
> desc->irq_data.chip->irq_enable(&desc->irq_data);
> irq_state_clr_masked(desc);
> } else {
> unmask_irq(desc);
> }
>
> Because gpio irq_chip implements irq_enable(), unmask_irq() is not executed,
> and gpio irq_chip's irq_unmask() callback is not called. Instead,
> irq_state_clr_masked() was called to clear the masked flag.
>
> The irq masked behavior is actually controlled by the
> irq_mask()/irq_unmask() callback function pairs in gpio irq_chip. When the
> whole situation occurs, there is one more irq_mask() operation, or one less
> irq_unmask() operation. This ends the i2c hid resume and the gpio
> corresponding i2c hid interrupt is also masked.
>
> Please help confirm whether the current situation is a BUG, or suggest other
> solutions to fix it.
>
I has just been Cc'ed to this thread from the very start of the thread
so not sure whether I fully understand the problem. But a while ago an
IRQ disable/undisable-mask/unmask-unpairing problem was reported for
DW APB GPIO driver implementation, but in a another context though:
https://lore.kernel.org/linux-gpio/1606728979-44259-1-git-send-email-luojiaxing@huawei.com/
We didn't come to a final conclusion back then, so the patch got lost
in the emails archive. Xiong, is it related to the problem in your
case?
-Serge(y)
^ permalink raw reply
* element sizes in input_event struct on riscv32
From: Antonios Salios @ 2023-12-14 10:11 UTC (permalink / raw)
To: dmitry.torokhov
Cc: rydberg, linux-input, linux-kernel, Jan Henrik Weinstock,
Lukas Jünger
Hi all.
I'm having trouble getting evdev to run in a simulated Buildroot
environment on riscv32. Evtest (and the x11 driver) seems to be
receiving garbage data from input devices.
Analyzing the input_event struct shows that the kernel uses 32-bit (aka
__kernel_ulong_t) values for __sec & __usec.
Evtest on the other hand interprets these variables as 64-bit time_t
values in a timeval struct, resulting in a mismatch between the kernel
and userspace.
What would be the correct size for these values on a 32-bit
architecture that uses 64-bit time_t values?
Kind regards
--
Antonios Salios
Student Employee
MachineWare GmbH | www.machineware.de
Hühnermarkt 19, 52062 Aachen, Germany
Amtsgericht Aachen HRB25734
Geschäftsführung
Lukas Jünger
Dr.-Ing. Jan Henrik Weinstock
^ permalink raw reply
* Re: [PATCH] irq: Resolve that mask_irq/unmask_irq may not be called in pairs
From: Thomas Gleixner @ 2023-12-14 10:13 UTC (permalink / raw)
To: xiongxin, jikos, benjamin.tissoires
Cc: linux-input, stable, Riwen Lu, hoan, fancer.lancer, linus.walleij,
brgl, andy, linux-gpio, linux-kernel
In-Reply-To: <1844c927-2dd4-49b4-a6c4-c4c176b1f75d@kylinos.cn>
On Thu, Dec 14 2023 at 09:54, xiongxin wrote:
> 在 2023/12/13 22:59, Thomas Gleixner 写道:
>> Did you actually look at the sequence I gave you?
>>
>> Suspend:
>>
>> i2c_hid_core_suspend()
>> disable_irq(); <- Marks it disabled and eventually
>> masks it.
>>
>> gpio_irq_suspend()
>> save_registers(); <- Saves masked interrupt
>>
>> Resume:
>>
>> gpio_irq_resume()
>> restore_registers(); <- Restores masked interrupt
>>
>> i2c_hid_core_resume()
>> enable_irq(); <- Unmasks interrupt and removes the
>> disabled marker
>>
>>
>> Have you verified that this order of invocations is what happens on
>> your machine?
>
> As described earlier, in the current situation, the irq_mask() callback
> of gpio irq_chip is called in mask_irq(), followed by the disable_irq()
> in i2c_hid_core_suspend(), unmask_irq() will not be executed.
Which is correct.
> Then call enable_irq() in i2c_hid_core_resume(). Since gpio irq_chip
> does not implement the irq_startup() callback, it ends up calling
> irq_enable().
>
> The irq_enable() function is then implemented as follows:
>
> irq_state_clr_disabled(desc);
> if (desc->irq_data.chip->irq_enable) {
> desc->irq_data.chip->irq_enable(&desc->irq_data);
> irq_state_clr_masked(desc);
> } else {
> unmask_irq(desc);
> }
>
> Because gpio irq_chip implements irq_enable(), unmask_irq() is not
> executed, and gpio irq_chip's irq_unmask() callback is not called.
> Instead, irq_state_clr_masked() was called to clear the masked flag.
>
> The irq masked behavior is actually controlled by the
> irq_mask()/irq_unmask() callback function pairs in gpio irq_chip. When
> the whole situation occurs, there is one more irq_mask() operation, or
> one less irq_unmask() operation. This ends the i2c hid resume and the
> gpio corresponding i2c hid interrupt is also masked.
>
> Please help confirm whether the current situation is a BUG, or suggest
> other solutions to fix it.
Again, I already explained to you in great detail why the core code is
correct and does not have a bug.
But as you insist that the bug is in the core code you obviously failed
to validate what I asked you to validate:
>> i2c_hid_core_resume()
>> enable_irq(); <- Unmasks interrupt and removes the
>> disabled marker
The keyword to validate here is 'Unmasks'.
As gpio_dwapb implements the irq_enable() callback enable_irq() is not
going to end up invoking the irq_unmask() callback. But the irq_enable()
callback is required to be a superset of irq_unmask(). I.e. the core
code expects it to do:
1) Some preparatory work to enable the interrupt line
2) Unmask the interrupt, which is why the masked state is cleared
by the core after invoking the irq_enable() callback.
which is pretty obvious because if an interrupt chip does not implement
the irq_enable() callback the core defaults to irq_unmask()
Correspondingly the core expects from the irq_disable() callback:
1) To mask the interrupt
2) To do some extra work to disable the interrupt line
which is obvious again because the core defaults to irq_mask() if the
irq_disable() callback is not implemented by the interrupt chip.
I'm pretty sure that with the previous provided information and the
extra information above you can figure out yourself that:
1) the core code is correct as is
2) where exactly the problem is located and how to fix it
No?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v6 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
From: Conor Dooley @ 2023-12-14 15:59 UTC (permalink / raw)
To: Biju Das
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Support Opensource, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Steve Twiss, linux-input, devicetree,
linux-pm, Geert Uytterhoeven, Prabhakar Mahadev Lad, Biju Das,
linux-renesas-soc, Krzysztof Kozlowski
In-Reply-To: <20231214080911.23359-9-biju.das.jz@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
On Thu, Dec 14, 2023 at 08:09:11AM +0000, Biju Das wrote:
> Convert the da9062 PMIC device tree binding documentation to json-schema.
>
> Document the missing gpio child node for da9062.
>
> While at it, update description with link to product information and
> example.
>
> The missing child node with of_compatible defined in MFD_CELL_OF is
> causing the below warning message:
> da9062-gpio: Failed to locate of_node [id: -1]
>
> So, make all child nodes with of_compatible defined in struct mfd_cell
> as required property for da906{1,2} devices.
>
> The "gpio-controller" and "#gpio-cells" properties are defined in the
> parent instead of gpio child node as there are existing driver users
> based on these parent properties.
Thanks for updating the commit message :)
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] irq: Resolve that mask_irq/unmask_irq may not be called in pairs
From: Andy Shevchenko @ 2023-12-14 16:11 UTC (permalink / raw)
To: Serge Semin
Cc: xiongxin, Thomas Gleixner, jikos, benjamin.tissoires, linux-input,
stable, Riwen Lu, hoan, linus.walleij, brgl, linux-gpio,
linux-kernel
In-Reply-To: <f5vtfoqylht5ijj6tdvxee3f3u6ywps2it7kv3fhmfsx75od2y@ftjlt4t4z4dk>
On Thu, Dec 14, 2023 at 01:06:23PM +0300, Serge Semin wrote:
> On Thu, Dec 14, 2023 at 09:54:06AM +0800, xiongxin wrote:
> > 在 2023/12/13 22:59, Thomas Gleixner 写道:
> > > On Wed, Dec 13 2023 at 10:29, xiongxin wrote:
> > > > 在 2023/12/12 23:17, Thomas Gleixner 写道:
> > > > Sorry, the previous reply may not have clarified the BUG process. I
> > > > re-debugged and confirmed it yesterday. The current BUG execution
> > > > sequence is described as follows:
> > >
> > > It's the sequence how this works and it works correctly.
> > >
> > > Just because it does not work on your machine it does not mean that this
> > > is incorrect and a BUG.
> > >
> > > You are trying to fix a symptom and thereby violating guarantees of the
> > > core code.
> > >
> > > > That is, there is a time between the 1:handle_level_irq() and
> > > > 3:irq_thread_fn() calls for the 2:disable_irq() call to acquire the lock
> > > > and then implement the irq_state_set_disabled() operation. When finally
> > > > call irq_thread_fn()->irq_finalize_oneshot(), it cannot enter the
> > > > unmask_thread_irq() process.
> > >
> > > Correct, because the interrupt has been DISABLED in the mean time.
> > >
> > > > In this case, the gpio irq_chip irq_mask()/irq_unmask() callback pairs
> > > > are not called in pairs, so I think this is a BUG, but not necessarily
> > > > fixed from the irq core code layer.
> > >
> > > No. It is _NOT_ a BUG. unmask() is not allowed to be invoked when the
> > > interrupt is DISABLED. That's the last time I'm going to tell you that.
> > > Only enable_irq() can undo the effect of disable_irq(), period.
> > >
> > > > Next, when the gpio controller driver calls the suspend/resume process,
> > > > it is as follows:
> > > >
> > > > suspend process:
> > > > dwapb_gpio_suspend()
> > > > ctx->int_mask = dwapb_read(gpio, GPIO_INTMASK);
> > > >
> > > > resume process:
> > > > dwapb_gpio_resume()
> > > > dwapb_write(gpio, GPIO_INTMASK, ctx->int_mask);
> > >
> > > Did you actually look at the sequence I gave you?
> > >
> > > Suspend:
> > >
> > > i2c_hid_core_suspend()
> > > disable_irq(); <- Marks it disabled and eventually
> > > masks it.
> > >
> > > gpio_irq_suspend()
> > > save_registers(); <- Saves masked interrupt
> > >
> > > Resume:
> > >
> > > gpio_irq_resume()
> > > restore_registers(); <- Restores masked interrupt
> > >
> > > i2c_hid_core_resume()
> > > enable_irq(); <- Unmasks interrupt and removes the
> > > disabled marker
> > >
> > >
> > > Have you verified that this order of invocations is what happens on
> > > your machine?
> > >
> > > Thanks,
> > >
> > > tglx
> >
> > As described earlier, in the current situation, the irq_mask() callback of
> > gpio irq_chip is called in mask_irq(), followed by the disable_irq() in
> > i2c_hid_core_suspend(), unmask_irq() will not be executed.
> >
> > Then call enable_irq() in i2c_hid_core_resume(). Since gpio irq_chip does
> > not implement the irq_startup() callback, it ends up calling irq_enable().
> >
> > The irq_enable() function is then implemented as follows:
> >
> > irq_state_clr_disabled(desc);
> > if (desc->irq_data.chip->irq_enable) {
> > desc->irq_data.chip->irq_enable(&desc->irq_data);
> > irq_state_clr_masked(desc);
> > } else {
> > unmask_irq(desc);
> > }
> >
> > Because gpio irq_chip implements irq_enable(), unmask_irq() is not executed,
> > and gpio irq_chip's irq_unmask() callback is not called. Instead,
> > irq_state_clr_masked() was called to clear the masked flag.
> >
> > The irq masked behavior is actually controlled by the
> > irq_mask()/irq_unmask() callback function pairs in gpio irq_chip. When the
> > whole situation occurs, there is one more irq_mask() operation, or one less
> > irq_unmask() operation. This ends the i2c hid resume and the gpio
> > corresponding i2c hid interrupt is also masked.
> >
> > Please help confirm whether the current situation is a BUG, or suggest other
> > solutions to fix it.
>
> I has just been Cc'ed to this thread from the very start of the thread
> so not sure whether I fully understand the problem. But a while ago an
> IRQ disable/undisable-mask/unmask-unpairing problem was reported for
> DW APB GPIO driver implementation, but in a another context though:
> https://lore.kernel.org/linux-gpio/1606728979-44259-1-git-send-email-luojiaxing@huawei.com/
> We didn't come to a final conclusion back then, so the patch got lost
> in the emails archive. Xiong, is it related to the problem in your
> case?
From what explained it sounds to me that GPIO driver has missing part and
this seems the missing patch (in one or another form). Perhaps we can get
a second round of review,
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] HID: nintendo: fix initializer element is not constant error
From: Ryan McClelland @ 2023-12-14 17:25 UTC (permalink / raw)
To: lkp, linux-input
Cc: jkosina, linux-mm, oe-kbuild-all, djogorchock, benjamin.tissoires,
jikos, Ryan McClelland
In-Reply-To: <202312141227.C2h1IzfI-lkp@intel.com>
With gcc-7 builds, an error happens with the controller button values being
defined as const. Change to a define.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312141227.C2h1IzfI-lkp@intel.com/
Signed-off-by: Ryan McClelland <rymcclel@gmail.com>
---
drivers/hid/hid-nintendo.c | 44 +++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
index 47af111ef3a2..2987083785f9 100644
--- a/drivers/hid/hid-nintendo.c
+++ b/drivers/hid/hid-nintendo.c
@@ -336,28 +336,28 @@ struct joycon_imu_cal {
* All the controller's button values are stored in a u32.
* They can be accessed with bitwise ANDs.
*/
-static const u32 JC_BTN_Y = BIT(0);
-static const u32 JC_BTN_X = BIT(1);
-static const u32 JC_BTN_B = BIT(2);
-static const u32 JC_BTN_A = BIT(3);
-static const u32 JC_BTN_SR_R = BIT(4);
-static const u32 JC_BTN_SL_R = BIT(5);
-static const u32 JC_BTN_R = BIT(6);
-static const u32 JC_BTN_ZR = BIT(7);
-static const u32 JC_BTN_MINUS = BIT(8);
-static const u32 JC_BTN_PLUS = BIT(9);
-static const u32 JC_BTN_RSTICK = BIT(10);
-static const u32 JC_BTN_LSTICK = BIT(11);
-static const u32 JC_BTN_HOME = BIT(12);
-static const u32 JC_BTN_CAP = BIT(13); /* capture button */
-static const u32 JC_BTN_DOWN = BIT(16);
-static const u32 JC_BTN_UP = BIT(17);
-static const u32 JC_BTN_RIGHT = BIT(18);
-static const u32 JC_BTN_LEFT = BIT(19);
-static const u32 JC_BTN_SR_L = BIT(20);
-static const u32 JC_BTN_SL_L = BIT(21);
-static const u32 JC_BTN_L = BIT(22);
-static const u32 JC_BTN_ZL = BIT(23);
+#define JC_BTN_Y BIT(0)
+#define JC_BTN_X BIT(1)
+#define JC_BTN_B BIT(2)
+#define JC_BTN_A BIT(3)
+#define JC_BTN_SR_R BIT(4)
+#define JC_BTN_SL_R BIT(5)
+#define JC_BTN_R BIT(6)
+#define JC_BTN_ZR BIT(7)
+#define JC_BTN_MINUS BIT(8)
+#define JC_BTN_PLUS BIT(9)
+#define JC_BTN_RSTICK BIT(10)
+#define JC_BTN_LSTICK BIT(11)
+#define JC_BTN_HOME BIT(12)
+#define JC_BTN_CAP BIT(13) /* capture button */
+#define JC_BTN_DOWN BIT(16)
+#define JC_BTN_UP BIT(17)
+#define JC_BTN_RIGHT BIT(18)
+#define JC_BTN_LEFT BIT(19)
+#define JC_BTN_SR_L BIT(20)
+#define JC_BTN_SL_L BIT(21)
+#define JC_BTN_L BIT(22)
+#define JC_BTN_ZL BIT(23)
struct joycon_ctlr_button_mapping {
u32 code;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] irq: Resolve that mask_irq/unmask_irq may not be called in pairs
From: xiongxin @ 2023-12-15 2:18 UTC (permalink / raw)
To: Andy Shevchenko, Serge Semin, Thomas Gleixner
Cc: jikos, benjamin.tissoires, linux-input, stable, Riwen Lu, hoan,
linus.walleij, brgl, linux-gpio, linux-kernel
In-Reply-To: <ZXspNGWszB9jAown@smile.fi.intel.com>
在 2023/12/15 00:11, Andy Shevchenko 写道:
> On Thu, Dec 14, 2023 at 01:06:23PM +0300, Serge Semin wrote:
>> On Thu, Dec 14, 2023 at 09:54:06AM +0800, xiongxin wrote:
>>> 在 2023/12/13 22:59, Thomas Gleixner 写道:
>>>> On Wed, Dec 13 2023 at 10:29, xiongxin wrote:
>>>>> 在 2023/12/12 23:17, Thomas Gleixner 写道:
>>>>> Sorry, the previous reply may not have clarified the BUG process. I
>>>>> re-debugged and confirmed it yesterday. The current BUG execution
>>>>> sequence is described as follows:
>>>>
>>>> It's the sequence how this works and it works correctly.
>>>>
>>>> Just because it does not work on your machine it does not mean that this
>>>> is incorrect and a BUG.
>>>>
>>>> You are trying to fix a symptom and thereby violating guarantees of the
>>>> core code.
>>>>
>>>>> That is, there is a time between the 1:handle_level_irq() and
>>>>> 3:irq_thread_fn() calls for the 2:disable_irq() call to acquire the lock
>>>>> and then implement the irq_state_set_disabled() operation. When finally
>>>>> call irq_thread_fn()->irq_finalize_oneshot(), it cannot enter the
>>>>> unmask_thread_irq() process.
>>>>
>>>> Correct, because the interrupt has been DISABLED in the mean time.
>>>>
>>>>> In this case, the gpio irq_chip irq_mask()/irq_unmask() callback pairs
>>>>> are not called in pairs, so I think this is a BUG, but not necessarily
>>>>> fixed from the irq core code layer.
>>>>
>>>> No. It is _NOT_ a BUG. unmask() is not allowed to be invoked when the
>>>> interrupt is DISABLED. That's the last time I'm going to tell you that.
>>>> Only enable_irq() can undo the effect of disable_irq(), period.
>>>>
>>>>> Next, when the gpio controller driver calls the suspend/resume process,
>>>>> it is as follows:
>>>>>
>>>>> suspend process:
>>>>> dwapb_gpio_suspend()
>>>>> ctx->int_mask = dwapb_read(gpio, GPIO_INTMASK);
>>>>>
>>>>> resume process:
>>>>> dwapb_gpio_resume()
>>>>> dwapb_write(gpio, GPIO_INTMASK, ctx->int_mask);
>>>>
>>>> Did you actually look at the sequence I gave you?
>>>>
>>>> Suspend:
>>>>
>>>> i2c_hid_core_suspend()
>>>> disable_irq(); <- Marks it disabled and eventually
>>>> masks it.
>>>>
>>>> gpio_irq_suspend()
>>>> save_registers(); <- Saves masked interrupt
>>>>
>>>> Resume:
>>>>
>>>> gpio_irq_resume()
>>>> restore_registers(); <- Restores masked interrupt
>>>>
>>>> i2c_hid_core_resume()
>>>> enable_irq(); <- Unmasks interrupt and removes the
>>>> disabled marker
>>>>
>>>>
>>>> Have you verified that this order of invocations is what happens on
>>>> your machine?
>>>>
>>>> Thanks,
>>>>
>>>> tglx
>>>
>>> As described earlier, in the current situation, the irq_mask() callback of
>>> gpio irq_chip is called in mask_irq(), followed by the disable_irq() in
>>> i2c_hid_core_suspend(), unmask_irq() will not be executed.
>>>
>>> Then call enable_irq() in i2c_hid_core_resume(). Since gpio irq_chip does
>>> not implement the irq_startup() callback, it ends up calling irq_enable().
>>>
>>> The irq_enable() function is then implemented as follows:
>>>
>>> irq_state_clr_disabled(desc);
>>> if (desc->irq_data.chip->irq_enable) {
>>> desc->irq_data.chip->irq_enable(&desc->irq_data);
>>> irq_state_clr_masked(desc);
>>> } else {
>>> unmask_irq(desc);
>>> }
>>>
>>> Because gpio irq_chip implements irq_enable(), unmask_irq() is not executed,
>>> and gpio irq_chip's irq_unmask() callback is not called. Instead,
>>> irq_state_clr_masked() was called to clear the masked flag.
>>>
>>> The irq masked behavior is actually controlled by the
>>> irq_mask()/irq_unmask() callback function pairs in gpio irq_chip. When the
>>> whole situation occurs, there is one more irq_mask() operation, or one less
>>> irq_unmask() operation. This ends the i2c hid resume and the gpio
>>> corresponding i2c hid interrupt is also masked.
>>>
>>> Please help confirm whether the current situation is a BUG, or suggest other
>>> solutions to fix it.
>>
>> I has just been Cc'ed to this thread from the very start of the thread
>> so not sure whether I fully understand the problem. But a while ago an
>> IRQ disable/undisable-mask/unmask-unpairing problem was reported for
>> DW APB GPIO driver implementation, but in a another context though:
>> https://lore.kernel.org/linux-gpio/1606728979-44259-1-git-send-email-luojiaxing@huawei.com/
>> We didn't come to a final conclusion back then, so the patch got lost
>> in the emails archive. Xiong, is it related to the problem in your
>> case?
>
> From what explained it sounds to me that GPIO driver has missing part and
> this seems the missing patch (in one or another form). Perhaps we can get
> a second round of review,
>
Yes, the current case is exactly the situation described in the link,
and the specific implementation process is as described in my previous
email. After adding the patch for retest, the exception can be
effectively solved. And at present, can the patch be incorporated?
Thank you Thomas for your kind advice!
My previous focus has been locked until mask_irq()/unmask_irq() is not
called in pairs, in fact, it can turn on the corresponding irq masked in
enable_irq. Looking at the irq_enable() callback implementation of other
GPIO interrupt controllers, there are indeed operations on masked registers.
Thank you all!
^ permalink raw reply
* [RFC] dt-bindings: input: Clarify that abs_min must be less than abs_max
From: Chris Morgan @ 2023-12-15 2:40 UTC (permalink / raw)
To: linux-input
Cc: devicetree, contact, conor+dt, krzysztof.kozlowski+dt, robh+dt,
dmitry.torokhov, Chris Morgan
From: Chris Morgan <macromorgan@hotmail.com>
uinput refuses to work with abs devices where the min value is greater
than the max value. uinput_validate_absinfo() returns -EINVAL if this
is the case and prevents using uinput on such a device. Since uinput
has worked this way since at least kernel 2.6 (or prior) I presume that
this is the correct way of doing things, and that this documentation
needs to be clarified that min must always be less than max.
uinput is used in my use case to bind together adc-joystick devices
with gpio-keys devices to create a single unified gamepad for
userspace.
Note that there are several boards that will need to be corrected,
all but a few of them I maintain. Submitting as an RFC for now to get
comments from the input team and the original author in case there is
something I am missing.
Fixes: 7956b0d4694f ("dt-bindings: input: Add docs for ADC driven joystick")
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
Documentation/devicetree/bindings/input/adc-joystick.yaml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/adc-joystick.yaml b/Documentation/devicetree/bindings/input/adc-joystick.yaml
index 6c244d66f8ce..8f5cdd5ef190 100644
--- a/Documentation/devicetree/bindings/input/adc-joystick.yaml
+++ b/Documentation/devicetree/bindings/input/adc-joystick.yaml
@@ -73,8 +73,9 @@ patternProperties:
description: >
Minimum and maximum values produced by the axis.
For an ABS_X axis this will be the left-most and right-most
- inclination of the joystick. If min > max, it is left to userspace to
- treat the axis as inverted.
+ inclination of the joystick. The axis must always be expressed as
+ min < max, if the axis is inverted it is left to userspace to handle
+ the inversion.
This property is interpreted as two signed 32 bit values.
abs-fuzz:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/2] Input: uinput - Allow uinput_request_submit wait interrupting
From: Vicki Pfau @ 2023-12-15 3:04 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
In-Reply-To: <b54584c2-9db8-4715-966a-6fdf57fdee1a@endrift.com>
Hi Dmitry
On 12/8/23 19:24, Vicki Pfau wrote:
> Hi Dmitry,
>
> On 12/8/23 11:32, Dmitry Torokhov wrote:
>> Hi Vicki,
>>
>> On Wed, Dec 06, 2023 at 10:34:05PM -0800, Vicki Pfau wrote:
>>> Currently, uinput_request_submit will only fail if the request wait times out.
>>> However, in other places this wait is interruptable, and in this specific
>>> location it can lead to issues, such as causing system suspend to hang until
>>> the request times out.
>>
>> Could you please explain how a sleeping process can cause suspend to
>> hang?
>
> While I'm not 100% sure how it happens, given I found this by reproducing it before I came up with a theory for why it happened, my guess is that as it's trying to suspend all of userspace programs, it suspends the process that owns the uinput handle, so it can't continue to service requests, while the other process hangs in the uninterruptable call, blocking suspend for 30 seconds until the call times out.
>
>>
>>> Since the timeout is so long, this can cause the
>>> appearance of a total system freeze. Making the wait interruptable resolves
>>> this and possibly further issues.
>>
>> I think you are trying to find a justification too hard and it does not
>> make sense, however I agree that allowing to kill the process issuing
>> the request without waiting for the timeout to expire if the other side
>> is stuck might be desirable.
>
> This isn't reaching. As I said above, I discovered the patched line of code *after* observing suspend hanging for 30 seconds while trying to reproduce another bug. I wrote this patch, retested, and found that it now suspended immediately, leading to a visible -ERESTARTSYS in strace on coming back from suspend.
>
> I can post the reproduction case somewhere, but the test program is only the evdev client end, with the uinput side being Steam, which I don't have source code for.
>
>>
>> I think the best way to use wait_for_completion_killable_timeout()
>> so that stray signals do not disturb userspace, but the processes can
>> still be terminated.
>
> There's already a mutex_lock_interruptable in uinput_request_send that could cause this to fall back to userspace under similar circumstances. The only difference I can find, which is admittedly a bug in this patch now that I look at it again, is that uinput_dev_event would get called twice, leading to the request getting duplicated.
After further investigation, it seems this would still be the case even if the request times out--an invalid request would get left in the buffer, which means that while this is a new way to trigger the issue, it's not actually a new issue.
It seems to me that this driver could use a lot of love to get it into better shape, which I could work on, but I'm not actually sure where to begin. Especially if we don't want to break ABI.
>
> If there's a better way to handle the suspend case let me know, but this is not a hypothetical issue.
>
>>
>> Thanks.
>>
>
> Vicki
Vici
^ permalink raw reply
* [PATCH RESEND v11 1/2] dt-bindings: input: bindings for Adafruit Seesaw Gamepad
From: Anshul Dalal @ 2023-12-15 3:11 UTC (permalink / raw)
To: linux-input, devicetree
Cc: Anshul Dalal, Conor Dooley, Dmitry Torokhov,
Thomas Weißschuh, linux-kernel, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Jeff LaBundy,
linux-kernel-mentees
Adds bindings for the Adafruit Seesaw Gamepad.
The gamepad functions as an i2c device with the default address of 0x50
and has an IRQ pin that can be enabled in the driver to allow for a rising
edge trigger on each button press or joystick movement.
Product page:
https://www.adafruit.com/product/5743
Arduino driver:
https://github.com/adafruit/Adafruit_Seesaw
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
---
Changes for v11:
- no updates
Changes for v10:
- Added interrupt-controller/irq.h header
Changes for v9:
- Added interrupt in example
Changes for v8:
- no updates
Changes for v7:
- no updates
Changes for v6:
- no updates
Changes for v5:
- Added link to the datasheet
Changes for v4:
- Fixed the URI for the id field
- Added `interrupts` property
Changes for v3:
- Updated id field to reflect updated file name from previous version
- Added `reg` property
Changes for v2:
- Renamed file to `adafruit,seesaw-gamepad.yaml`
- Removed quotes for `$id` and `$schema`
- Removed "Bindings for" from the description
- Changed node name to the generic name "joystick"
- Changed compatible to 'adafruit,seesaw-gamepad' instead of
'adafruit,seesaw_gamepad'
Previous versions:
v11: https://lore.kernel.org/lkml/20231127161158.1651716-1-anshulusr@gmail.com/
v10: https://lore.kernel.org/lkml/20231121123409.2231115-1-anshulusr@gmail.com/
v9: https://lore.kernel.org/lkml/20231121101751.2189965-1-anshulusr@gmail.com/
v8: https://lore.kernel.org/lkml/20231108005337.45069-1-anshulusr@gmail.com/
v7: https://lore.kernel.org/lkml/20231106164134.114668-1-anshulusr@gmail.com/
v6: https://lore.kernel.org/lkml/20231027051819.81333-1-anshulusr@gmail.com/
v5: https://lore.kernel.org/lkml/20231017034356.1436677-1-anshulusr@gmail.com/
v4: https://lore.kernel.org/lkml/20231010184827.1213507-1-anshulusr@gmail.com/
v3: https://lore.kernel.org/linux-input/20231008185709.2448423-1-anshulusr@gmail.com/
v2: https://lore.kernel.org/linux-input/20231008172435.2391009-1-anshulusr@gmail.com/
v1: https://lore.kernel.org/linux-input/20231007144052.1535417-1-anshulusr@gmail.com/
---
.../input/adafruit,seesaw-gamepad.yaml | 63 +++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
diff --git a/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml b/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
new file mode 100644
index 000000000000..5e86f6de6978
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/adafruit,seesaw-gamepad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Adafruit Mini I2C Gamepad with seesaw
+
+maintainers:
+ - Anshul Dalal <anshulusr@gmail.com>
+
+description: |
+ Adafruit Mini I2C Gamepad
+
+ +-----------------------------+
+ | ___ |
+ | / \ (X) |
+ | | S | __ __ (Y) (A) |
+ | \___/ |ST| |SE| (B) |
+ | |
+ +-----------------------------+
+
+ S -> 10-bit precision bidirectional analog joystick
+ ST -> Start
+ SE -> Select
+ X, A, B, Y -> Digital action buttons
+
+ Datasheet: https://cdn-learn.adafruit.com/downloads/pdf/gamepad-qt.pdf
+ Product page: https://www.adafruit.com/product/5743
+ Arduino Driver: https://github.com/adafruit/Adafruit_Seesaw
+
+properties:
+ compatible:
+ const: adafruit,seesaw-gamepad
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description:
+ The gamepad's IRQ pin triggers a rising edge if interrupts are enabled.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ joystick@50 {
+ compatible = "adafruit,seesaw-gamepad";
+ interrupts = <18 IRQ_TYPE_EDGE_RISING>;
+ reg = <0x50>;
+ };
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH RESEND v11 2/2] input: joystick: driver for Adafruit Seesaw Gamepad
From: Anshul Dalal @ 2023-12-15 3:11 UTC (permalink / raw)
To: linux-input, devicetree
Cc: Anshul Dalal, Conor Dooley, Dmitry Torokhov,
Thomas Weißschuh, linux-kernel, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Jeff LaBundy,
linux-kernel-mentees
In-Reply-To: <20231215031125.284939-1-anshulusr@gmail.com>
Adds a driver for a mini gamepad that communicates over i2c, the gamepad
has bidirectional thumb stick input and six buttons.
The gamepad chip utilizes the open framework from Adafruit called 'Seesaw'
to transmit the ADC data for the joystick and digital pin state for the
buttons. I have only implemented the functionality required to receive the
thumb stick and button state.
Steps in reading the gamepad state over i2c:
1. Reset the registers
2. Set the pin mode of the pins specified by the `BUTTON_MASK` to input
`BUTTON_MASK`: A bit-map for the six digital pins internally
connected to the joystick buttons.
3. Enable internal pullup resistors for the `BUTTON_MASK`
4. Bulk set the pin state HIGH for `BUTTON_MASK`
5. Poll the device for button and joystick state done by:
`seesaw_read_data(struct i2c_client *client, struct seesaw_data *data)`
Product page:
https://www.adafruit.com/product/5743
Arduino driver:
https://github.com/adafruit/Adafruit_Seesaw
Driver tested on RPi Zero 2W
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
---
Changes for v11:
- Removed `of_match_ptr` to prevent warning:
'seesaw_of_table' defined but not used
on non OF platforms
Changes for v10:
- no updates
Changes for v9:
- Added of_device_id
Changes for v8:
- Updated invalid references to `adafruit_seesaw` to `adafruit-seesaw`
Changes for v7:
adafruit-seesaw.c
- Fixed formatting for macro definitions
- Made SEESAW_BUTTON_MASK static const
- Removed __be16 type for x and y fields of seesaw_data
- Used sparse_keymap implementation instead of custom keymap
- Used i2c_msg instead of i2c_master_send and recv in
seesaw_register_read
- Use temporary variable `adc_data` to store data received from ADC
- Changed read_buf from u8[4] to __be32
- Use usleep_range instead of msleep
- Removed 'Reviewed-by: Thomas Weißschuh' due to large number of changes
since last review
Kconfig:
- Added `select INPUT_SPARSEKMAP`
Changes for v6:
- Added TODO
- Removed `clang-format` directives
- Namespaced device buttons
- Removed `char physical_path[32]` field from `struct seesaw_gamepad`
- Added `packed` attribute to `struct seesaw_data`
- Moved from having booleans per button to single `u32 button_state`
- Added `seesaw_button_description` array to directly associate device
buttons with respective keycodes
- Added wrapper functions `seesaw_register_` around `i2c_master_` API
- Ratelimited input error reporting with `dev_err_ratelimited`
- Removed `of_device_id`
Changes for v5:
- Added link to the datasheet
- Added debug log message when `seesaw_read_data` fails
Changes for v4:
- Changed `1UL << BUTTON_` to BIT(BUTTON_)
- Removed `hardware_id` field from `struct seesaw_gamepad`
- Removed redundant checks for the number of bytes written and received by
`i2c_master_send` and `i2c_master_recv`
- Used `get_unaligned_be32` to instantiate `u32 result` from `read_buf`
- Changed `result & (1UL << BUTTON_)` to
`test_bit(BUTTON_, (long *)&result)`
- Changed `KBUILD_MODNAME` in id-tables to `SEESAW_DEVICE_NAME`
- Fixed formatting issues
- Changed button reporting:
Since the gamepad had the action buttons in a non-standard layout:
(X)
(Y) (A)
(B)
Therefore moved to using generic directional action button event codes
instead of BTN_[ABXY].
Changes for v3:
- no updates
Changes for v2:
adafruit-seesaw.c:
- Renamed file from 'adafruit_seesaw.c'
- Changed device name from 'seesaw_gamepad' to 'seesaw-gamepad'
- Changed count parameter for receiving joystick x on line 118:
`2` to `sizeof(write_buf)`
- Fixed invalid buffer size on line 123 and 126:
`data->y` to `sizeof(data->y)`
- Added comment for the `mdelay(10)` on line 169
- Changed inconsistent indentation on line 271
Kconfig:
- Fixed indentation for the help text
- Updated module name
Makefile:
- Updated module object file name
MAINTAINERS:
- Updated file name for the driver and bindings
Previous versions:
v11: https://lore.kernel.org/lkml/20231127161158.1651716-2-anshulusr@gmail.com/
v10: https://lore.kernel.org/lkml/20231121123409.2231115-2-anshulusr@gmail.com/
v9: https://lore.kernel.org/lkml/20231121101751.2189965-2-anshulusr@gmail.com/
v8: https://lore.kernel.org/lkml/20231108005337.45069-2-anshulusr@gmail.com/
v7: https://lore.kernel.org/lkml/20231106164134.114668-2-anshulusr@gmail.com/
v6: https://lore.kernel.org/lkml/20231027051819.81333-2-anshulusr@gmail.com/
v5: https://lore.kernel.org/lkml/20231017034356.1436677-2-anshulusr@gmail.com/
v4: https://lore.kernel.org/lkml/20231010184827.1213507-2-anshulusr@gmail.com/
v3: https://lore.kernel.org/linux-input/20231008185709.2448423-2-anshulusr@gmail.com/
v2: https://lore.kernel.org/linux-input/20231008172435.2391009-2-anshulusr@gmail.com/
v1: https://lore.kernel.org/linux-input/20231007144052.1535417-2-anshulusr@gmail.com/
---
MAINTAINERS | 7 +
drivers/input/joystick/Kconfig | 10 +
drivers/input/joystick/Makefile | 1 +
drivers/input/joystick/adafruit-seesaw.c | 318 +++++++++++++++++++++++
4 files changed, 336 insertions(+)
create mode 100644 drivers/input/joystick/adafruit-seesaw.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 81d5fc0bba68..b3f101edc24b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -441,6 +441,13 @@ W: http://wiki.analog.com/AD7879
W: https://ez.analog.com/linux-software-drivers
F: drivers/input/touchscreen/ad7879.c
+ADAFRUIT MINI I2C GAMEPAD
+M: Anshul Dalal <anshulusr@gmail.com>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
+F: drivers/input/joystick/adafruit-seesaw.c
+
ADDRESS SPACE LAYOUT RANDOMIZATION (ASLR)
M: Jiri Kosina <jikos@kernel.org>
S: Maintained
diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index ac6925ce8366..7755e5b454d2 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -412,4 +412,14 @@ config JOYSTICK_SENSEHAT
To compile this driver as a module, choose M here: the
module will be called sensehat_joystick.
+config JOYSTICK_SEESAW
+ tristate "Adafruit Mini I2C Gamepad with Seesaw"
+ depends on I2C
+ select INPUT_SPARSEKMAP
+ help
+ Say Y here if you want to use the Adafruit Mini I2C Gamepad.
+
+ To compile this driver as a module, choose M here: the module will be
+ called adafruit-seesaw.
+
endif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 3937535f0098..9976f596a920 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_JOYSTICK_N64) += n64joy.o
obj-$(CONFIG_JOYSTICK_PSXPAD_SPI) += psxpad-spi.o
obj-$(CONFIG_JOYSTICK_PXRC) += pxrc.o
obj-$(CONFIG_JOYSTICK_QWIIC) += qwiic-joystick.o
+obj-$(CONFIG_JOYSTICK_SEESAW) += adafruit-seesaw.o
obj-$(CONFIG_JOYSTICK_SENSEHAT) += sensehat-joystick.o
obj-$(CONFIG_JOYSTICK_SIDEWINDER) += sidewinder.o
obj-$(CONFIG_JOYSTICK_SPACEBALL) += spaceball.o
diff --git a/drivers/input/joystick/adafruit-seesaw.c b/drivers/input/joystick/adafruit-seesaw.c
new file mode 100644
index 000000000000..0f4a54c9519e
--- /dev/null
+++ b/drivers/input/joystick/adafruit-seesaw.c
@@ -0,0 +1,318 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2023 Anshul Dalal <anshulusr@gmail.com>
+ *
+ * Driver for Adafruit Mini I2C Gamepad
+ *
+ * Based on the work of:
+ * Oleh Kravchenko (Sparkfun Qwiic Joystick driver)
+ *
+ * Datasheet: https://cdn-learn.adafruit.com/downloads/pdf/gamepad-qt.pdf
+ * Product page: https://www.adafruit.com/product/5743
+ * Firmware and hardware sources: https://github.com/adafruit/Adafruit_Seesaw
+ *
+ * TODO:
+ * - Add interrupt support
+ */
+
+#include <asm/unaligned.h>
+#include <linux/bits.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/input/sparse-keymap.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+#define SEESAW_DEVICE_NAME "seesaw-gamepad"
+
+#define SEESAW_STATUS_BASE 0x00
+#define SEESAW_GPIO_BASE 0x01
+#define SEESAW_ADC_BASE 0x09
+
+#define SEESAW_GPIO_DIRCLR_BULK 0x03
+#define SEESAW_GPIO_BULK 0x04
+#define SEESAW_GPIO_BULK_SET 0x05
+#define SEESAW_GPIO_PULLENSET 0x0b
+
+#define SEESAW_STATUS_HW_ID 0x01
+#define SEESAW_STATUS_SWRST 0x7f
+
+#define SEESAW_ADC_OFFSET 0x07
+
+#define SEESAW_BUTTON_A 0x05
+#define SEESAW_BUTTON_B 0x01
+#define SEESAW_BUTTON_X 0x06
+#define SEESAW_BUTTON_Y 0x02
+#define SEESAW_BUTTON_START 0x10
+#define SEESAW_BUTTON_SELECT 0x00
+
+#define SEESAW_ANALOG_X 0x0e
+#define SEESAW_ANALOG_Y 0x0f
+
+#define SEESAW_JOYSTICK_MAX_AXIS 1023
+#define SEESAW_JOYSTICK_FUZZ 2
+#define SEESAW_JOYSTICK_FLAT 4
+
+#define SEESAW_GAMEPAD_POLL_INTERVAL 16
+#define SEESAW_GAMEPAD_POLL_MIN 8
+#define SEESAW_GAMEPAD_POLL_MAX 32
+
+#define MSEC_PER_USEC 1000
+
+static const u32 SEESAW_BUTTON_MASK =
+ BIT(SEESAW_BUTTON_A) | BIT(SEESAW_BUTTON_B) | BIT(SEESAW_BUTTON_X) |
+ BIT(SEESAW_BUTTON_Y) | BIT(SEESAW_BUTTON_START) |
+ BIT(SEESAW_BUTTON_SELECT);
+
+struct seesaw_gamepad {
+ struct input_dev *input_dev;
+ struct i2c_client *i2c_client;
+};
+
+struct seesaw_data {
+ u16 x;
+ u16 y;
+ u32 button_state;
+};
+
+static const struct key_entry seesaw_buttons_new[] = {
+ { KE_KEY, SEESAW_BUTTON_A, .keycode = BTN_SOUTH },
+ { KE_KEY, SEESAW_BUTTON_B, .keycode = BTN_EAST },
+ { KE_KEY, SEESAW_BUTTON_X, .keycode = BTN_NORTH },
+ { KE_KEY, SEESAW_BUTTON_Y, .keycode = BTN_WEST },
+ { KE_KEY, SEESAW_BUTTON_START, .keycode = BTN_START },
+ { KE_KEY, SEESAW_BUTTON_SELECT, .keycode = BTN_SELECT },
+ { KE_END, 0 }
+};
+
+static int seesaw_register_read(struct i2c_client *client, u8 register_high,
+ u8 register_low, char *buf, int count)
+{
+ int ret;
+ u8 register_buf[2] = { register_high, register_low };
+
+ struct i2c_msg message_buf[2] = {
+ {
+ .addr = client->addr,
+ .flags = client->flags,
+ .len = sizeof(register_buf),
+ .buf = register_buf,
+ },
+ {
+ .addr = client->addr,
+ .flags = client->flags | I2C_M_RD,
+ .len = count,
+ .buf = buf,
+ },
+ };
+ ret = i2c_transfer(client->adapter, message_buf,
+ ARRAY_SIZE(message_buf));
+
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int seesaw_register_write_u8(struct i2c_client *client, u8 register_high,
+ u8 register_low, u8 value)
+{
+ int ret;
+ u8 write_buf[3] = { register_high, register_low, value };
+
+ ret = i2c_master_send(client, write_buf, sizeof(write_buf));
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int seesaw_register_write_u32(struct i2c_client *client,
+ u8 register_high, u8 register_low,
+ u32 value)
+{
+ int ret;
+ u8 write_buf[6] = { register_high, register_low };
+
+ put_unaligned_be32(value, write_buf + 2);
+ ret = i2c_master_send(client, write_buf, sizeof(write_buf));
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int seesaw_read_data(struct i2c_client *client, struct seesaw_data *data)
+{
+ int ret;
+ __be16 adc_data;
+ __be32 read_buf;
+
+ ret = seesaw_register_read(client, SEESAW_GPIO_BASE, SEESAW_GPIO_BULK,
+ (char *)&read_buf, sizeof(read_buf));
+ if (ret)
+ return ret;
+
+ data->button_state = ~be32_to_cpu(read_buf);
+
+ ret = seesaw_register_read(client, SEESAW_ADC_BASE,
+ SEESAW_ADC_OFFSET + SEESAW_ANALOG_X,
+ (char *)&adc_data, sizeof(adc_data));
+ if (ret)
+ return ret;
+ /*
+ * ADC reads left as max and right as 0, must be reversed since kernel
+ * expects reports in opposite order.
+ */
+ data->x = SEESAW_JOYSTICK_MAX_AXIS - be16_to_cpu(adc_data);
+
+ ret = seesaw_register_read(client, SEESAW_ADC_BASE,
+ SEESAW_ADC_OFFSET + SEESAW_ANALOG_Y,
+ (char *)&adc_data, sizeof(adc_data));
+ if (ret)
+ return ret;
+ data->y = be16_to_cpu(adc_data);
+
+ return 0;
+}
+
+static void seesaw_poll(struct input_dev *input)
+{
+ int err, i;
+ struct seesaw_gamepad *private = input_get_drvdata(input);
+ struct seesaw_data data;
+
+ err = seesaw_read_data(private->i2c_client, &data);
+ if (err) {
+ dev_err_ratelimited(&input->dev,
+ "failed to read joystick state: %d\n", err);
+ return;
+ }
+
+ input_report_abs(input, ABS_X, data.x);
+ input_report_abs(input, ABS_Y, data.y);
+
+ for_each_set_bit(i, (long *)&SEESAW_BUTTON_MASK,
+ BITS_PER_TYPE(SEESAW_BUTTON_MASK)) {
+ if (!sparse_keymap_report_event(
+ input, i, data.button_state & BIT(i), false)) {
+ dev_err_ratelimited(&input->dev,
+ "failed to report keymap event");
+ };
+ }
+
+ input_sync(input);
+}
+
+static int seesaw_probe(struct i2c_client *client)
+{
+ int ret;
+ u8 hardware_id;
+ struct seesaw_gamepad *seesaw;
+
+ ret = seesaw_register_write_u8(client, SEESAW_STATUS_BASE,
+ SEESAW_STATUS_SWRST, 0xFF);
+ if (ret)
+ return ret;
+
+ /* Wait for the registers to reset before proceeding */
+ usleep_range(10 * MSEC_PER_USEC, 15 * MSEC_PER_USEC);
+
+ seesaw = devm_kzalloc(&client->dev, sizeof(*seesaw), GFP_KERNEL);
+ if (!seesaw)
+ return -ENOMEM;
+
+ ret = seesaw_register_read(client, SEESAW_STATUS_BASE,
+ SEESAW_STATUS_HW_ID, &hardware_id,
+ sizeof(hardware_id));
+ if (ret)
+ return ret;
+
+ dev_dbg(&client->dev, "Adafruit Seesaw Gamepad, Hardware ID: %02x\n",
+ hardware_id);
+
+ /* Set Pin Mode to input and enable pull-up resistors */
+ ret = seesaw_register_write_u32(client, SEESAW_GPIO_BASE,
+ SEESAW_GPIO_DIRCLR_BULK,
+ SEESAW_BUTTON_MASK);
+ if (ret)
+ return ret;
+ ret = seesaw_register_write_u32(client, SEESAW_GPIO_BASE,
+ SEESAW_GPIO_PULLENSET,
+ SEESAW_BUTTON_MASK);
+ if (ret)
+ return ret;
+ ret = seesaw_register_write_u32(client, SEESAW_GPIO_BASE,
+ SEESAW_GPIO_BULK_SET,
+ SEESAW_BUTTON_MASK);
+ if (ret)
+ return ret;
+
+ seesaw->i2c_client = client;
+ seesaw->input_dev = devm_input_allocate_device(&client->dev);
+ if (!seesaw->input_dev)
+ return -ENOMEM;
+
+ seesaw->input_dev->id.bustype = BUS_I2C;
+ seesaw->input_dev->name = "Adafruit Seesaw Gamepad";
+ seesaw->input_dev->phys = "i2c/" SEESAW_DEVICE_NAME;
+ input_set_drvdata(seesaw->input_dev, seesaw);
+ input_set_abs_params(seesaw->input_dev, ABS_X, 0,
+ SEESAW_JOYSTICK_MAX_AXIS, SEESAW_JOYSTICK_FUZZ,
+ SEESAW_JOYSTICK_FLAT);
+ input_set_abs_params(seesaw->input_dev, ABS_Y, 0,
+ SEESAW_JOYSTICK_MAX_AXIS, SEESAW_JOYSTICK_FUZZ,
+ SEESAW_JOYSTICK_FLAT);
+
+ ret = sparse_keymap_setup(seesaw->input_dev, seesaw_buttons_new, NULL);
+ if (ret) {
+ dev_err(&client->dev,
+ "failed to set up input device keymap: %d\n", ret);
+ return ret;
+ }
+
+ ret = input_setup_polling(seesaw->input_dev, seesaw_poll);
+ if (ret) {
+ dev_err(&client->dev, "failed to set up polling: %d\n", ret);
+ return ret;
+ }
+
+ input_set_poll_interval(seesaw->input_dev, SEESAW_GAMEPAD_POLL_INTERVAL);
+ input_set_max_poll_interval(seesaw->input_dev, SEESAW_GAMEPAD_POLL_MAX);
+ input_set_min_poll_interval(seesaw->input_dev, SEESAW_GAMEPAD_POLL_MIN);
+
+ ret = input_register_device(seesaw->input_dev);
+ if (ret) {
+ dev_err(&client->dev, "failed to register joystick: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct i2c_device_id seesaw_id_table[] = {
+ { SEESAW_DEVICE_NAME },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(i2c, seesaw_id_table);
+
+static const struct of_device_id seesaw_of_table[] = {
+ { .compatible = "adafruit,seesaw-gamepad"},
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, seesaw_of_table);
+
+static struct i2c_driver seesaw_driver = {
+ .driver = {
+ .name = SEESAW_DEVICE_NAME,
+ .of_match_table = seesaw_of_table,
+ },
+ .id_table = seesaw_id_table,
+ .probe = seesaw_probe,
+};
+module_i2c_driver(seesaw_driver);
+
+MODULE_AUTHOR("Anshul Dalal <anshulusr@gmail.com>");
+MODULE_DESCRIPTION("Adafruit Mini I2C Gamepad driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 0/9] Support light color temperature and chromaticity
From: Linux regression tracking (Thorsten Leemhuis) @ 2023-12-15 10:04 UTC (permalink / raw)
To: Jonathan Cameron, Thomas Weißschuh
Cc: Basavaraj Natikar, jikos, benjamin.tissoires, lars,
srinivas.pandruvada, linux-input, linux-iio, regressions
In-Reply-To: <20231210110735.52f8dc53@jic23-huawei>
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
Thomas, Jonathan, was any progress made to resolve below regression?
Side note: vormally I would not prod you at this time of the cycle, but
with the festive season coming up I thought it would be wise to ask a
bit earlier for a status update.
Ciao, Thorsten
On 10.12.23 12:07, Jonathan Cameron wrote:
> On Thu, 7 Dec 2023 00:39:28 +0100
> Thomas Weißschuh <thomas@t-8ch.de> wrote:
>> On 2023-09-19 13:40:45+0530, Basavaraj Natikar wrote:
>>> This series adds support for light color temperature and chromaticity.
>[...]
>>> Basavaraj Natikar (9):
>>> iio: hid-sensor-als: Use channel index to support more hub attributes
>>> iio: Add channel type light color temperature
>>> iio: hid-sensor-als: Add light color temperature support
>>> HID: amd_sfh: Add support for light color temperature
>>> HID: amd_sfh: Add support for SFH1.1 light color temperature
>>> iio: Add channel type for chromaticity
>>> iio: hid-sensor-als: Add light chromaticity support
>>> HID: amd_sfh: Add light chromaticity support
>>> HID: amd_sfh: Add light chromaticity for SFH1.1
>>
>> This series is breaking probing of hid-sensor-als on Framework 13 AMD
>> laptops [0].
>> The problem is that the patches require hid-sensors-als sensors to also
>> report chromaticity and color temparature which they don't.
> Gah. Missed that in review. Sorry about that and thanks for digging into
> this.
>>
>> When I remove the 'if (ret < 0) return ret;' checks in
>> als_parse_report() probing works and the illuminance/intensity channels
>> that show up behave as expected.
>> Unfortunately this still leaves behind a bunch of unusable channels.
>> A nice fix would be to have something like sysfs/hwmon .is_visible()
>> callback but that's not supported by IIO.
>
> It's tricky to do because there is no simple association between
> what is registered as channels and the resulting attribute. We could probably
> make it work, but not a simple thing to do.
>
>>
>> One aproach would be to detect the usable channels in als_parse_report()
>> and then adapt the indio_dev->channels based on that information.
>>
>> [0] https://bugzilla.kernel.org/show_bug.cgi?id=218223
>
> Agreed that adapting the channels is the way to go.
> Easiest option probably to set the relevant masks to 0 if the chromacity and
> temp channels aren't there + set their scan index values to -1.
> That 'should' suppress any attributes being created.
> Having a gap in scan indexes is common anyway so any userspace should cope
> with the timestamp being after a gap.
>
> Alternatives would be to rebuild the chan_spec array to not have the entries,
> or pass in and fill in two copies of the array, picking the relevant one only
> on discovering if the temp and chromacity channels are present.
>
> Jonathan
>
>>
>> #regzbot introduced: 5f05285df691b1e82108eead7165feae238c95ef
>> #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=218223
>>
>
>
>
^ 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