* [PATCH 4/5] Input: cs40l26 - Load multiple coefficient files
From: Fred Treven @ 2023-05-26 0:04 UTC (permalink / raw)
To: Fred Treven, Ben Bright, James Ogletree, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Simon Trimmer, Charles Keepax,
Richard Fitzgerald, patches, linux-input, devicetree,
linux-kernel
Cc: lee
In-Reply-To: <1685059471-9598-1-git-send-email-fred.treven@cirrus.com>
Enable the driver to load all necessary coefficient tuning
files: cs40l26.bin (wavetable)
cs40l26-svc.bin (Sensorless Velocity Control)
cs40l26-dvl.bin (Dynamic Voltage Limiter)
Signed-off-by: Fred Treven <fred.treven@cirrus.com>
---
drivers/input/misc/cs40l26.c | 31 +++++++++++++++++++++++--------
include/linux/input/cs40l26.h | 3 ++-
2 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/input/misc/cs40l26.c b/drivers/input/misc/cs40l26.c
index 1959438dfe31..12c29cbd4ff0 100644
--- a/drivers/input/misc/cs40l26.c
+++ b/drivers/input/misc/cs40l26.c
@@ -2006,6 +2006,12 @@ static const struct cs_dsp_client_ops cs40l26_cs_dsp_client_ops = {
.post_run = cs40l26_cs_dsp_post_run,
};
+static struct cs_dsp_coeff_desc cs40l26_coeffs[] = {
+ { .coeff_firmware = NULL, .coeff_filename = "cs40l26.bin", .optional = false },
+ { .coeff_firmware = NULL, .coeff_filename = "cs40l26-svc.bin", .optional = true },
+ { .coeff_firmware = NULL, .coeff_filename = "cs40l26-dvl.bin", .optional = true },
+};
+
static int cs40l26_cs_dsp_init(struct cs40l26_private *cs40l26)
{
int error;
@@ -2035,14 +2041,16 @@ static int cs40l26_cs_dsp_init(struct cs40l26_private *cs40l26)
static void cs40l26_dsp_start(struct cs40l26_private *cs40l26)
{
struct device *dev = cs40l26->dev;
+ int i;
if (cs40l26_dsp_pre_config(cs40l26))
goto err_rls_fw;
mutex_lock(&cs40l26->lock);
- if (cs_dsp_power_up(&cs40l26->dsp, cs40l26->wmfw, "cs40l26.wmfw",
- cs40l26->bin, "cs40l26.bin", "cs40l26"))
+ if (cs_dsp_power_up_multiple(&cs40l26->dsp, cs40l26->wmfw, "cs40l26.wmfw",
+ cs40l26_coeffs, CS40L26_NUM_COEFF_FILES,
+ "cs40l26"))
goto err_mutex;
if (cs40l26->dsp.fw_id != CS40L26_FW_ID) {
@@ -2062,7 +2070,9 @@ static void cs40l26_dsp_start(struct cs40l26_private *cs40l26)
mutex_unlock(&cs40l26->lock);
err_rls_fw:
- release_firmware(cs40l26->bin);
+ for (i = 0; i < CS40L26_NUM_COEFF_FILES; i++)
+ release_firmware(cs40l26_coeffs[i].coeff_firmware);
+
release_firmware(cs40l26->wmfw);
cs40l26_pm_runtime_setup(cs40l26);
@@ -2074,17 +2084,20 @@ static void cs40l26_coeff_upload(const struct firmware *bin, void *context)
if (!bin) {
dev_err(cs40l26->dev, "Failed to request coefficient file\n");
+ cs40l26->ncoeffs++;
return;
}
- cs40l26->bin = bin;
+ cs40l26_coeffs[cs40l26->ncoeffs++].coeff_firmware = bin;
- cs40l26_dsp_start(cs40l26);
+ if (cs40l26->ncoeffs == CS40L26_NUM_COEFF_FILES)
+ cs40l26_dsp_start(cs40l26);
}
static void cs40l26_fw_upload(const struct firmware *wmfw, void *context)
{
struct cs40l26_private *cs40l26 = (struct cs40l26_private *)context;
+ int i;
if (!wmfw) {
dev_err(cs40l26->dev, "Failed to request firmware file\n");
@@ -2098,9 +2111,11 @@ static void cs40l26_fw_upload(const struct firmware *wmfw, void *context)
cs40l26->wmfw = wmfw;
- request_firmware_nowait(THIS_MODULE, FW_ACTION_UEVENT,
- "cs40l26.bin", cs40l26->dev, GFP_KERNEL,
- cs40l26, cs40l26_coeff_upload);
+ for (i = 0; i < CS40L26_NUM_COEFF_FILES; i++)
+ request_firmware_nowait(THIS_MODULE, FW_ACTION_UEVENT,
+ "cs40l26.bin", cs40l26->dev,
+ GFP_KERNEL, cs40l26,
+ cs40l26_coeff_upload);
}
static inline int cs40l26_worker_init(struct cs40l26_private *cs40l26)
diff --git a/include/linux/input/cs40l26.h b/include/linux/input/cs40l26.h
index bc0acec9cf23..2f74ef61b952 100644
--- a/include/linux/input/cs40l26.h
+++ b/include/linux/input/cs40l26.h
@@ -231,6 +231,7 @@
/* Firmware Handling */
#define CS40L26_FW_ID 0x1800D4
#define CS40L26_FW_ID_VERSION_MIN 0x070237
+#define CS40L26_NUM_COEFF_FILES 3
/* Algorithms */
#define CS40L26_BUZZGEN_ALGO_ID 0x0004F202
@@ -473,8 +474,8 @@ struct cs40l26_private {
unsigned int vbst_uv;
bool exploratory_mode_enabled;
const struct firmware *wmfw;
- const struct firmware *bin;
bool dsp_initialized;
+ int ncoeffs;
};
int cs40l26_probe(struct cs40l26_private *cs40l26);
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 5/5] mfd: cs40l26: Add CODEC driver component
From: Fred Treven @ 2023-05-26 0:04 UTC (permalink / raw)
To: Fred Treven, Ben Bright, James Ogletree, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Simon Trimmer, Charles Keepax,
Richard Fitzgerald, patches, linux-input, devicetree,
linux-kernel
Cc: lee
In-Reply-To: <1685059471-9598-1-git-send-email-fred.treven@cirrus.com>
Use MFD interface to load the CODEC driver along
with the Input FF driver.
Signed-off-by: Fred Treven <fred.treven@cirrus.com>
---
drivers/input/misc/cs40l26.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/input/misc/cs40l26.c b/drivers/input/misc/cs40l26.c
index 12c29cbd4ff0..35d15a6c2230 100644
--- a/drivers/input/misc/cs40l26.c
+++ b/drivers/input/misc/cs40l26.c
@@ -13,6 +13,7 @@
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
+#include <linux/mfd/core.h>
#include <linux/pm_runtime.h>
#include <linux/string.h>
#include <linux/firmware/cirrus/wmfw.h>
@@ -2136,6 +2137,10 @@ static inline int cs40l26_worker_init(struct cs40l26_private *cs40l26)
return 0;
}
+static const struct mfd_cell cs40l26_devs[] = {
+ { .name = "cs40l26-codec" },
+};
+
static struct regulator_bulk_data cs40l26_supplies[] = {
{ .supply = "VP" },
{ .supply = "VA" },
@@ -2275,6 +2280,12 @@ int cs40l26_probe(struct cs40l26_private *cs40l26)
if (error)
goto err;
+ error = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, cs40l26_devs, 1, NULL, 0, NULL);
+ if (error) {
+ dev_err(dev, "Failed to MFD add device %s: %d\n", cs40l26_devs[0].name, error);
+ goto err;
+ }
+
return 0;
err:
cs40l26_remove(cs40l26);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] firmware: cs_dsp: Add ability to loa multiple coefficient files
From: Fred Treven @ 2023-05-26 0:04 UTC (permalink / raw)
To: Fred Treven, Ben Bright, James Ogletree, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Simon Trimmer, Charles Keepax,
Richard Fitzgerald, patches, linux-input, devicetree,
linux-kernel
Cc: lee
In-Reply-To: <1685059471-9598-1-git-send-email-fred.treven@cirrus.com>
Add cs_dsp_power_up_multiple() which accepts an array of
cs_dsp_coeff_desc firmware-filename pairs to load.
This enables the user to load more than one tuning file
along with the associated firmware.
Change cs_dsp_power_up() to make use of the new function
with a single coefficient file.
Signed-off-by: Fred Treven <fred.treven@cirrus.com>
---
drivers/firmware/cirrus/cs_dsp.c | 61 ++++++++++++++++++++++++++--------
include/linux/firmware/cirrus/cs_dsp.h | 20 +++++++++--
2 files changed, 66 insertions(+), 15 deletions(-)
diff --git a/drivers/firmware/cirrus/cs_dsp.c b/drivers/firmware/cirrus/cs_dsp.c
index f558b390fbfe..3242095c1b13 100644
--- a/drivers/firmware/cirrus/cs_dsp.c
+++ b/drivers/firmware/cirrus/cs_dsp.c
@@ -2515,28 +2515,30 @@ static void cs_dsp_halo_stop_watchdog(struct cs_dsp *dsp)
}
/**
- * cs_dsp_power_up() - Downloads firmware to the DSP
- * @dsp: pointer to DSP structure
+ * cs_dsp_power_up_multiple() - Downloads firmware and multiple coefficient files to the DSP
+ * @dsp: pointer to the DSP structure
* @wmfw_firmware: the firmware to be sent
* @wmfw_filename: file name of firmware to be sent
- * @coeff_firmware: the coefficient data to be sent
- * @coeff_filename: file name of coefficient to data be sent
+ * @coeffs: coefficient data and filename pairs to be sent
+ * @num_coeffs: number of coefficient files to be sent
* @fw_name: the user-friendly firmware name
*
* This function is used on ADSP2 and Halo DSP cores, it powers-up the DSP core
* and downloads the firmware but does not start the firmware running. The
* cs_dsp booted flag will be set once completed and if the core has a low-power
* memory retention mode it will be put into this state after the firmware is
- * downloaded.
+ * downloaded. Differs from cs_dsp_power_up() in that it allows for multiple
+ * coefficient files to be downloaded.
*
* Return: Zero for success, a negative number on error.
+ *
+ *
*/
-int cs_dsp_power_up(struct cs_dsp *dsp,
- const struct firmware *wmfw_firmware, char *wmfw_filename,
- const struct firmware *coeff_firmware, char *coeff_filename,
- const char *fw_name)
+int cs_dsp_power_up_multiple(struct cs_dsp *dsp, const struct firmware *wmfw_firmware,
+ char *wmfw_filename, struct cs_dsp_coeff_desc *coeffs, int num_coeffs,
+ const char *fw_name)
{
- int ret;
+ int i, ret;
mutex_lock(&dsp->pwr_lock);
@@ -2562,9 +2564,12 @@ int cs_dsp_power_up(struct cs_dsp *dsp,
if (ret != 0)
goto err_ena;
- ret = cs_dsp_load_coeff(dsp, coeff_firmware, coeff_filename);
- if (ret != 0)
- goto err_ena;
+ for (i = 0; i < num_coeffs; i++) {
+ ret = cs_dsp_load_coeff(dsp, coeffs[i].coeff_firmware,
+ coeffs[i].coeff_filename);
+ if (ret != 0 && !coeffs[i].optional)
+ goto err_ena;
+ }
/* Initialize caches for enabled and unset controls */
ret = cs_dsp_coeff_init_control_caches(dsp);
@@ -2590,6 +2595,36 @@ int cs_dsp_power_up(struct cs_dsp *dsp,
return ret;
}
+EXPORT_SYMBOL_NS_GPL(cs_dsp_power_up_multiple, FW_CS_DSP);
+
+/**
+ * cs_dsp_power_up() - Downloads firmware to the DSP
+ * @dsp: pointer to DSP structure
+ * @wmfw_firmware: the firmware to be sent
+ * @wmfw_filename: file name of firmware to be sent
+ * @coeff_firmware: the coefficient data to be sent
+ * @coeff_filename: file name of coefficient data to be sent
+ * @fw_name: the user-friendly firmware name
+ *
+ * This function is used on ADSP2 and Halo DSP cores, it powers-up the DSP core
+ * and downloads the firmware but does not start the firmware running. The
+ * cs_dsp booted flag will be set once completed and if the core has a low-power
+ * memory retention mode it will be put into this state after the firmware is
+ * downloaded.
+ *
+ * Return: Zero for success, a negative number on error.
+ */
+int cs_dsp_power_up(struct cs_dsp *dsp, const struct firmware *wmfw_firmware, char *wmfw_filename,
+ const struct firmware *coeff_firmware, char *coeff_filename, const char *fw_name)
+{
+ struct cs_dsp_coeff_desc coeff_desc;
+
+ coeff_desc.coeff_firmware = coeff_firmware;
+ coeff_desc.coeff_filename = coeff_filename;
+ coeff_desc.optional = false;
+
+ return cs_dsp_power_up_multiple(dsp, wmfw_firmware, wmfw_filename, &coeff_desc, 1, fw_name);
+}
EXPORT_SYMBOL_NS_GPL(cs_dsp_power_up, FW_CS_DSP);
/**
diff --git a/include/linux/firmware/cirrus/cs_dsp.h b/include/linux/firmware/cirrus/cs_dsp.h
index cad828e21c72..1fda4104140c 100644
--- a/include/linux/firmware/cirrus/cs_dsp.h
+++ b/include/linux/firmware/cirrus/cs_dsp.h
@@ -43,6 +43,18 @@
#define CS_DSP_ACKED_CTL_MAX_VALUE 0xFFFFFF
/**
+ * struct cs_dsp_coeff_desc - Describes a coeff. file + filename pair
+ * @coeff_firmware: Firmware struct to populate with coeff. data
+ * @coeff_filename: File from which coeff. data is loaded
+ * @optional: Designates whether or not to error out if file fails to load
+ */
+struct cs_dsp_coeff_desc {
+ const struct firmware *coeff_firmware;
+ char *coeff_filename;
+ bool optional;
+};
+
+/**
* struct cs_dsp_region - Describes a logical memory region in DSP address space
* @type: Memory region type
* @base: Address of region
@@ -217,10 +229,14 @@ int cs_dsp_adsp1_power_up(struct cs_dsp *dsp,
const struct firmware *coeff_firmware, char *coeff_filename,
const char *fw_name);
void cs_dsp_adsp1_power_down(struct cs_dsp *dsp);
-int cs_dsp_power_up(struct cs_dsp *dsp,
+int cs_dsp_power_up_multiple(struct cs_dsp *dsp,
const struct firmware *wmfw_firmware, char *wmfw_filename,
- const struct firmware *coeff_firmware, char *coeff_filename,
+ struct cs_dsp_coeff_desc *coeffs, int num_coeffs,
const char *fw_name);
+int cs_dsp_power_up(struct cs_dsp *dsp,
+ const struct firmware *wmfw_firmware, char *wmfw_filename,
+ const struct firmware *coeff_firmware, char *coeff_filename,
+ const char *fw_name);
void cs_dsp_power_down(struct cs_dsp *dsp);
int cs_dsp_run(struct cs_dsp *dsp);
void cs_dsp_stop(struct cs_dsp *dsp);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/5] dt-bindings: input: cirrus,cs40l26: Support for CS40L26
From: Fred Treven @ 2023-05-26 0:04 UTC (permalink / raw)
To: Fred Treven, Ben Bright, James Ogletree, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Simon Trimmer, Charles Keepax,
Richard Fitzgerald, patches, linux-input, devicetree,
linux-kernel
Cc: lee
Introduce required basic devicetree parameters for the
initial commit of CS40L26.
Signed-off-by: Fred Treven <fred.treven@cirrus.com>
---
.../devicetree/bindings/input/cirrus,cs40l26.yaml | 102 +++++++++++++++++++++
MAINTAINERS | 10 ++
2 files changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/cirrus,cs40l26.yaml
diff --git a/Documentation/devicetree/bindings/input/cirrus,cs40l26.yaml b/Documentation/devicetree/bindings/input/cirrus,cs40l26.yaml
new file mode 100644
index 000000000000..9cbc964ebded
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cirrus,cs40l26.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/cirrus,cs40l26.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS40L26 Boosted Haptic Amplifier
+
+maintainers:
+ - Fred Treven <fred.treven@cirrus.com>
+
+description:
+ CS40L26 is a Boosted Haptic Driver with Integrated DSP and Waveform Memory
+ with Advanced Closed Loop Algorithms and LRA protection
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs40l26a
+ - cirrus,cs40l26b
+ - cirrus,cs40l27a
+ - cirrus,cs40l27b
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ VA-supply:
+ description: Regulator for VA analog voltage
+
+ VP-supply:
+ description: Regulator for VP peak voltage
+
+ cirrus,bst-ipk-microamp:
+ description:
+ Maximum amount of current that can be drawn by the device's boost converter.
+ multipleOf: 50000
+ minimum: 1600000
+ maximum: 4800000
+ default: 4500000
+
+ cirrus,bst-ctl-microvolt:
+ description: Maximum target voltage to which DSP may increase the VBST supply.
+ multipleOf: 50000
+ minimum: 2550000
+ maximum: 11000000
+ default: 11000000
+
+ cirrus,bst-exploratory-mode-disable:
+ description:
+ Disable boost exploratory mode.
+
+ In exploratory mode the analog maximum peak current limit of 4.5 A
+ (tolerance of + 160 mA) will be applied. This is required for the
+ device to successfully detect a boost inductor short.
+
+ Boost exploratory mode allows the device to overshoot the set boost peak
+ current limit (i.e. if current peak limit is set to 2.5 A to protect the
+ battery inductor, the current limit will be opened up to 4.5 A for
+ several milliseconds at boost startup).
+ This has potential to damage the boost inductor.
+
+ Disabling this mode will prevent this from happening; it will also
+ prevent the device from detecting boost inductor short errors.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cs40l26@58 {
+ compatible = "cirrus,cs40l26a";
+ reg = <0x58>;
+ interrupt-parent = <&gpio>;
+ interrupts = <57 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio 54 GPIO_ACTIVE_LOW>;
+ VA-supply = <&dummy_vreg>;
+ VP-supply = <&dummy_vreg>;
+ cirrus,bst-ctl-microvolt = <2600000>;
+ cirrus,bst-ipk-microamp = <1650000>;
+ cirrus,bst-exploratory-mode-disable;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2b073facf399..d72ed4957b0b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4926,6 +4926,16 @@ L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/cirrus/ep93xx_eth.c
+CIRRUS LOGIC HAPTICS DRIVER
+M: Fred Treven <fred.treven@cirrus.com>
+M: Ben Bright <ben.bright@cirrus.com>
+M: James Ogletree <james.ogletree@cirrus.com>
+L: patches@opensource.cirrus.com
+S: Supported
+W: https://github.com/CirrusLogic/linux-drivers/wiki
+T: git https://github.com/CirrusLogic/linux-drivers.git
+F: Documentation/devicetree/bindings/input/cirrus,cs40l26.yaml
+
CIRRUS LOGIC LOCHNAGAR DRIVER
M: Charles Keepax <ckeepax@opensource.cirrus.com>
M: Richard Fitzgerald <rf@opensource.cirrus.com>
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] HID: i2c-hid: Switch i2c drivers back to use .probe()
From: Doug Anderson @ 2023-05-25 20:36 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jiri Kosina, Benjamin Tissoires, Andy Shevchenko, Raul E Rangel,
Dmitry Torokhov, Matthias Kaehlcke, Stephen Kitt, Hans de Goede,
linux-input, kernel
In-Reply-To: <20230525203202.646669-1-u.kleine-koenig@pengutronix.de>
Hi,
On Thu, May 25, 2023 at 1:32 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type"), all drivers being converted to .probe_new() and then
> 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
> back to (the new) .probe() to be able to eventually drop .probe_new() from
> struct i2c_driver.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/hid/i2c-hid/i2c-hid-acpi.c | 2 +-
> drivers/hid/i2c-hid/i2c-hid-of-elan.c | 2 +-
> drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 2 +-
> drivers/hid/i2c-hid/i2c-hid-of.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
In case it's useful:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* [PATCH] HID: i2c-hid: Switch i2c drivers back to use .probe()
From: Uwe Kleine-König @ 2023-05-25 20:32 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Andy Shevchenko, Raul E Rangel, Dmitry Torokhov,
Matthias Kaehlcke, Stephen Kitt, Douglas Anderson, Hans de Goede,
linux-input, kernel
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/hid/i2c-hid/i2c-hid-acpi.c | 2 +-
drivers/hid/i2c-hid/i2c-hid-of-elan.c | 2 +-
drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 2 +-
drivers/hid/i2c-hid/i2c-hid-of.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index 3a7e2bcb5412..ac918a9ea8d3 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -118,7 +118,7 @@ static struct i2c_driver i2c_hid_acpi_driver = {
.acpi_match_table = i2c_hid_acpi_match,
},
- .probe_new = i2c_hid_acpi_probe,
+ .probe = i2c_hid_acpi_probe,
.remove = i2c_hid_core_remove,
.shutdown = i2c_hid_core_shutdown,
};
diff --git a/drivers/hid/i2c-hid/i2c-hid-of-elan.c b/drivers/hid/i2c-hid/i2c-hid-of-elan.c
index 76ddc8be1cbb..029045d9661c 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of-elan.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of-elan.c
@@ -118,7 +118,7 @@ static struct i2c_driver elan_i2c_hid_ts_driver = {
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
.of_match_table = of_match_ptr(elan_i2c_hid_of_match),
},
- .probe_new = i2c_hid_of_elan_probe,
+ .probe = i2c_hid_of_elan_probe,
.remove = i2c_hid_core_remove,
.shutdown = i2c_hid_core_shutdown,
};
diff --git a/drivers/hid/i2c-hid/i2c-hid-of-goodix.c b/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
index 0060e3dcd775..06edb90ab7c0 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
@@ -114,7 +114,7 @@ static struct i2c_driver goodix_i2c_hid_ts_driver = {
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
.of_match_table = of_match_ptr(goodix_i2c_hid_of_match),
},
- .probe_new = i2c_hid_of_goodix_probe,
+ .probe = i2c_hid_of_goodix_probe,
.remove = i2c_hid_core_remove,
.shutdown = i2c_hid_core_shutdown,
};
diff --git a/drivers/hid/i2c-hid/i2c-hid-of.c b/drivers/hid/i2c-hid/i2c-hid-of.c
index 855f53092f4e..c4e1fa0273c8 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of.c
@@ -157,7 +157,7 @@ static struct i2c_driver i2c_hid_of_driver = {
.of_match_table = of_match_ptr(i2c_hid_of_match),
},
- .probe_new = i2c_hid_of_probe,
+ .probe = i2c_hid_of_probe,
.remove = i2c_hid_core_remove,
.shutdown = i2c_hid_core_shutdown,
.id_table = i2c_hid_of_id_table,
base-commit: ac9a78681b921877518763ba0e89202254349d1b
--
2.39.2
^ permalink raw reply related
* Re: [regression] Since kernel 6.3.1 logitech unify receiver not working properly
From: Benjamin Tissoires @ 2023-05-25 11:19 UTC (permalink / raw)
To: Jiri Kosina
Cc: Linus Torvalds, Linux regressions mailing list, Bagas Sanjaya,
Filipe Laíns, Bastien Nocera, open list:HID CORE LAYER, LKML,
guy.b
In-Reply-To: <nycvar.YFH.7.76.2305251308471.29760@cbobk.fhfr.pm>
On Thu, May 25, 2023 at 1:10 PM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Wed, 24 May 2023, Benjamin Tissoires wrote:
>
> > > > That bug is pre-existing (ie the problem was not introduced by that
> > > > commit), but who knows if the retry makes things worse (ie if it then
> > > > triggers on a retry, the response data will be the *previous* response).
> > > >
> > > > The whole "goto exit" games should be removed too, because we're in a
> > > > for-loop, and instead of "goto exit" it should just do "break".
> > > >
> > > > IOW, something like this might be worth testing.
> > > >
> > > > That said, while I think the code is buggy, I doubt this is the actual
> > > > cause of the problem people are reporting. But it would be lovely to
> > > > hear if the attached patch makes any difference, and I think this is
> > > > fixing a real - but unlikely - problem anyway.
> >
> > FWIW, Linus, your patch is
> > Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> >
> > Feel free to submit it to us or to apply it directly if you prefer as
> > this is clearly a fix for a code path issue.
>
> It would be nice to hear from the people who were able to reproduce the
> issue whether this makes any observable difference in behavior though. I
> don't currently think it would, as it fixes a potential NULL pointer
> dereference, which is not what has been reported.
Well, yes, I didn't mean it would fix the bug. But this is an obvious
fix that we need to take given that we now see it :)
>
> Has anyone of the affected people tried to bisect the issue?
I just checked the BZ linked above, and... it still doesn't work
(which is not surprising):
https://bugzilla.kernel.org/show_bug.cgi?id=217412#c33
Cheers,
Benjamin
^ permalink raw reply
* Re: [regression] Since kernel 6.3.1 logitech unify receiver not working properly
From: Jiri Kosina @ 2023-05-25 11:10 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Linus Torvalds, Linux regressions mailing list, Bagas Sanjaya,
Filipe Laíns, Bastien Nocera, open list:HID CORE LAYER, LKML,
guy.b
In-Reply-To: <CAO-hwJ+MTRu9KxqwQc7UYFBsa0kkrnYfwVB30KsLZnw=wfcOMg@mail.gmail.com>
On Wed, 24 May 2023, Benjamin Tissoires wrote:
> > > That bug is pre-existing (ie the problem was not introduced by that
> > > commit), but who knows if the retry makes things worse (ie if it then
> > > triggers on a retry, the response data will be the *previous* response).
> > >
> > > The whole "goto exit" games should be removed too, because we're in a
> > > for-loop, and instead of "goto exit" it should just do "break".
> > >
> > > IOW, something like this might be worth testing.
> > >
> > > That said, while I think the code is buggy, I doubt this is the actual
> > > cause of the problem people are reporting. But it would be lovely to
> > > hear if the attached patch makes any difference, and I think this is
> > > fixing a real - but unlikely - problem anyway.
>
> FWIW, Linus, your patch is
> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> Feel free to submit it to us or to apply it directly if you prefer as
> this is clearly a fix for a code path issue.
It would be nice to hear from the people who were able to reproduce the
issue whether this makes any observable difference in behavior though. I
don't currently think it would, as it fixes a potential NULL pointer
dereference, which is not what has been reported.
Has anyone of the affected people tried to bisect the issue?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: (subset) [PATCH 0/4] Add haptics support to Nexus 5 using pwm-vibra driver
From: Bjorn Andersson @ 2023-05-25 4:54 UTC (permalink / raw)
To: Krzysztof Kozlowski, Brian Masney, Konrad Dybcio, Rob Herring,
Andy Gross, Luca Weiss, Dmitry Torokhov,
~postmarketos/upstreaming, Sebastian Reichel, phone-devel
Cc: linux-kernel, linux-arm-msm, linux-input, devicetree
In-Reply-To: <20230427-hammerhead-vibra-v1-0-e87eeb94da51@z3ntu.xyz>
On Thu, 27 Apr 2023 22:34:25 +0200, Luca Weiss wrote:
> A while ago Brian Masney sent some patches for a clk-vibrator which was
> then succeeded by the idea of a clk-pwm driver that "converts" a clock
> into a PWM and to use the existing pwm-vibra driver.
>
> Since clk-pwm has landed last year we can finally add haptics support
> upstream.
>
> [...]
Applied, thanks!
[4/4] ARM: dts: qcom: msm8974-hammerhead: Add vibrator
commit: e0a6590d8ceb7d6c4e35b5b5eb368d9fb800487f
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 7/9] HID: i2c-hid: Support being a panel follower
From: Doug Anderson @ 2023-05-24 17:29 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Sam Ravnborg, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann
Cc: dri-devel, linux-input, Dmitry Torokhov, hsinyi, devicetree,
yangcong5, linux-kernel, Daniel Vetter, linux-arm-msm,
cros-qcom-dts-watchers
In-Reply-To: <20230523122802.7.Ib1a98309c455cd7e26b931c69993d4fba33bbe15@changeid>
Hi,
On Tue, May 23, 2023 at 12:31 PM Douglas Anderson <dianders@chromium.org> wrote:
>
> As talked about in the patch ("drm/panel: Add a way for other devices
> to follow panel state"), we really want to keep the power states of a
> touchscreen and the panel it's attached to in sync with each other. In
> that spirit, add support to i2c-hid to be a panel follower. This will
> let the i2c-hid driver get informed when the panel is powered on and
> off. From there we can match the i2c-hid device's power state to that
> of the panel.
>
> NOTE: this patch specifically _doesn't_ use pm_runtime to keep track
> of / manage the power state of the i2c-hid device, even though my
> first instinct said that would be the way to go. Specific problems
> with using pm_runtime():
> * The initial power up couldn't happen in a runtime resume function
> since it create sub-devices and, apparently, that's not good to do
> in your resume function.
> * Managing our power state with pm_runtime meant fighting to make the
> right thing happen at system suspend to prevent the system from
> trying to resume us only to suspend us again. While this might be
> able to be solved, it added complexity.
> Overall the code without pm_runtime() ended up being smaller and
> easier to understand.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> drivers/hid/i2c-hid/i2c-hid-core.c | 82 +++++++++++++++++++++++++++++-
> 1 file changed, 81 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 34c0d98b4976..f1bb89377e8d 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -38,6 +38,8 @@
> #include <linux/mutex.h>
> #include <asm/unaligned.h>
>
> +#include <drm/drm_panel.h>
> +
> #include "../hid-ids.h"
> #include "i2c-hid.h"
>
> @@ -107,6 +109,8 @@ struct i2c_hid {
> struct mutex reset_lock;
>
> struct i2chid_ops *ops;
> + struct drm_panel_follower panel_follower;
> + bool is_panel_follower;
> };
>
> static const struct i2c_hid_quirks {
> @@ -1058,6 +1062,34 @@ int i2c_hid_core_initial_power_up(struct i2c_hid *ihid)
> return ret;
> }
>
> +int i2c_hid_core_panel_prepared(struct drm_panel_follower *follower)
As pointed out by the kernel test robot, I clearly missed making
several functions "static" in this patch series. :( I'll fix that in
v2, but for now I'll hold off sending v2 to wait for additional
feedback.
-Doug
^ permalink raw reply
* Re: [PATCH 2/9] drm/panel: Check for already prepared/enabled in drm_panel
From: Doug Anderson @ 2023-05-24 17:04 UTC (permalink / raw)
To: Chris Morgan
Cc: Jiri Kosina, Benjamin Tissoires, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Sam Ravnborg, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
dri-devel, linux-input, Dmitry Torokhov, hsinyi, devicetree,
yangcong5, linux-kernel, Daniel Vetter, linux-arm-msm,
cros-qcom-dts-watchers
In-Reply-To: <646e391f.810a0220.214ce.d680@mx.google.com>
Hi,
On Wed, May 24, 2023 at 9:19 AM Chris Morgan <macroalpha82@gmail.com> wrote:
>
> Thank you for looking into this more. It's one of the last QOL bugs
> for some devices I'm working on, even if the end result is no big
> deal (the other QOL bug involves a WARN on probing a rotated panel).
Glad it'll be helpful!
For the WARN on probing a rotated panel I thought there was some
progress on that front. Commit e3ea1806e4ad ("drm/bridge: panel: Set
orientation on panel_bridge connector") or commit 15b9ca1641f0 ("drm:
Config orientation property if panel provides it") didn't help you?
^ permalink raw reply
* Re: [PATCH 2/9] drm/panel: Check for already prepared/enabled in drm_panel
From: Doug Anderson @ 2023-05-24 16:57 UTC (permalink / raw)
To: neil.armstrong
Cc: Jiri Kosina, Benjamin Tissoires, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sam Ravnborg,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, dri-devel,
linux-input, Dmitry Torokhov, hsinyi, devicetree, yangcong5,
linux-kernel, Daniel Vetter, linux-arm-msm,
cros-qcom-dts-watchers
In-Reply-To: <21041738-e23f-45bc-580b-4139c0cb87d9@linaro.org>
Hi,
On Wed, May 24, 2023 at 2:52 AM Neil Armstrong
<neil.armstrong@linaro.org> wrote:
>
> Hi,
>
> On 23/05/2023 21:27, Douglas Anderson wrote:
> > In a whole pile of panel drivers, we have code to make the
> > prepare/unprepare/enable/disable callbacks behave as no-ops if they've
> > already been called. It's silly to have this code duplicated
> > everywhere. Add it to the core instead so that we can eventually
> > delete it from all the drivers. Note: to get some idea of the
> > duplicated code, try:
> > git grep 'if.*>prepared' -- drivers/gpu/drm/panel
> > git grep 'if.*>enabled' -- drivers/gpu/drm/panel
> >
> > NOTE: arguably, the right thing to do here is actually to skip this
> > patch and simply remove all the extra checks from the individual
> > drivers. Perhaps the checks were needed at some point in time in the
> > past but maybe they no longer are? Certainly as we continue
> > transitioning over to "panel_bridge" then we expect there to be much
> > less variety in how these calls are made. When we're called as part of
> > the bridge chain, things should be pretty simple. In fact, there was
> > some discussion in the past about these checks [1], including a
> > discussion about whether the checks were needed and whether the calls
> > ought to be refcounted. At the time, I decided not to mess with it
> > because it felt too risky.
> >
> > Looking closer at it now, I'm fairly certain that nothing in the
> > existing codebase is expecting these calls to be refcounted. The only
> > real question is whether someone is already doing something to ensure
> > prepare()/unprepare() match and enabled()/disable() match. I would say
> > that, even if there is something else ensuring that things match,
> > there's enough complexity that adding an extra bool and an extra
> > double-check here is a good idea. Let's add a drm_warn() to let people
> > know that it's considered a minor error to take advantage of
> > drm_panel's double-checking but we'll still make things work fine.
> >
> > [1] https://lore.kernel.org/r/20210416153909.v4.27.I502f2a92ddd36c3d28d014dd75e170c2d405a0a5@changeid
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> > drivers/gpu/drm/drm_panel.c | 49 ++++++++++++++++++++++++++++++++-----
> > include/drm/drm_panel.h | 14 +++++++++++
> > 2 files changed, 57 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> > index f634371c717a..4e1c4e42575b 100644
> > --- a/drivers/gpu/drm/drm_panel.c
> > +++ b/drivers/gpu/drm/drm_panel.c
> > @@ -105,11 +105,22 @@ EXPORT_SYMBOL(drm_panel_remove);
> > */
> > int drm_panel_prepare(struct drm_panel *panel)
> > {
> > + int ret;
> > +
> > if (!panel)
> > return -EINVAL;
> >
> > - if (panel->funcs && panel->funcs->prepare)
> > - return panel->funcs->prepare(panel);
> > + if (panel->prepared) {
> > + dev_warn(panel->dev, "Skipping prepare of already prepared panel\n");
> > + return 0;
> > + }
> > +
> > + if (panel->funcs && panel->funcs->prepare) {
> > + ret = panel->funcs->prepare(panel);
> > + if (ret < 0)
> > + return ret;
> > + }
> > + panel->prepared = true;
> >
> > return 0;
> > }
> > @@ -128,11 +139,22 @@ EXPORT_SYMBOL(drm_panel_prepare);
> > */
> > int drm_panel_unprepare(struct drm_panel *panel)
> > {
> > + int ret;
> > +
> > if (!panel)
> > return -EINVAL;
> >
> > - if (panel->funcs && panel->funcs->unprepare)
> > - return panel->funcs->unprepare(panel);
> > + if (!panel->prepared) {
> > + dev_warn(panel->dev, "Skipping unprepare of already unprepared panel\n");
> > + return 0;
> > + }
> > +
> > + if (panel->funcs && panel->funcs->unprepare) {
> > + ret = panel->funcs->unprepare(panel);
> > + if (ret < 0)
> > + return ret;
> > + }
> > + panel->prepared = false;
> >
> > return 0;
> > }
> > @@ -155,11 +177,17 @@ int drm_panel_enable(struct drm_panel *panel)
> > if (!panel)
> > return -EINVAL;
> >
> > + if (panel->enabled) {
> > + dev_warn(panel->dev, "Skipping enable of already enabled panel\n");
> > + return 0;
> > + }
> > +
> > if (panel->funcs && panel->funcs->enable) {
> > ret = panel->funcs->enable(panel);
> > if (ret < 0)
> > return ret;
> > }
> > + panel->enabled = true;
> >
> > ret = backlight_enable(panel->backlight);
> > if (ret < 0)
> > @@ -187,13 +215,22 @@ int drm_panel_disable(struct drm_panel *panel)
> > if (!panel)
> > return -EINVAL;
> >
> > + if (!panel->enabled) {
> > + dev_warn(panel->dev, "Skipping disable of already disabled panel\n");
> > + return 0;
> > + }
> > +
> > ret = backlight_disable(panel->backlight);
> > if (ret < 0)
> > DRM_DEV_INFO(panel->dev, "failed to disable backlight: %d\n",
> > ret);
> >
> > - if (panel->funcs && panel->funcs->disable)
> > - return panel->funcs->disable(panel);
> > + if (panel->funcs && panel->funcs->disable) {
> > + ret = panel->funcs->disable(panel);
> > + if (ret < 0)
> > + return ret;
> > + }
> > + panel->enabled = false;
> >
> > return 0;
> > }
> > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > index 432fab2347eb..c6cf75909389 100644
> > --- a/include/drm/drm_panel.h
> > +++ b/include/drm/drm_panel.h
> > @@ -198,6 +198,20 @@ struct drm_panel {
> > * the panel is powered up.
> > */
> > bool prepare_prev_first;
> > +
> > + /**
> > + * @prepared:
> > + *
> > + * If true then the panel has been prepared.
> > + */
> > + bool prepared;
> > +
> > + /**
> > + * @enabled:
> > + *
> > + * If true then the panel has been enabled.
> > + */
> > + bool enabled;
> > };
> >
> > void drm_panel_init(struct drm_panel *panel, struct device *dev,
>
> LGTM and let's cleanup the panel drivers
>
> Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks! For now I'll hold off on landing to see where this series ends
up. If the series ends up looking good we'll have to coordinate
landing the various bits between the drm and the hid trees and the
second drm patch in my series depends on this one>
If my series implodes I'll land this one on its own with your Ack. In
any case, once this lands somewhere I'll take an AI to cleanup the
panels.
-Doug
^ permalink raw reply
* [PATCH 1/2] Input: novatek-nvt-ts - fix input_register_device() failure error message
From: Hans de Goede @ 2023-05-24 16:29 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Hans de Goede, linux-input
Fix input_register_device() failure logging "failed to request irq"
as error message.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/touchscreen/novatek-nvt-ts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/novatek-nvt-ts.c b/drivers/input/touchscreen/novatek-nvt-ts.c
index 3e551f9d31d7..e7f30eeb91ca 100644
--- a/drivers/input/touchscreen/novatek-nvt-ts.c
+++ b/drivers/input/touchscreen/novatek-nvt-ts.c
@@ -272,7 +272,7 @@ static int nvt_ts_probe(struct i2c_client *client)
error = input_register_device(input);
if (error) {
- dev_err(dev, "failed to request irq: %d\n", error);
+ dev_err(dev, "failed to register input device: %d\n", error);
return error;
}
--
2.40.1
^ permalink raw reply related
* [PATCH 2/2] Input: novatek-nvt-ts - add touchscreen model number to description
From: Hans de Goede @ 2023-05-24 16:29 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Hans de Goede, linux-input
In-Reply-To: <20230524162935.734255-1-hdegoede@redhat.com>
A phoronix forum member actual found documentation on what the model
number for the touchscreen controller on the Acer Iconia One 7 B1-750 is.
Update the driver's description to include this.
Link: https://www.phoronix.com/forums/forum/hardware/general-hardware/1382535-10-years-later-linux-getting-a-touchscreen-driver-for-a-once-popular-tablet?p=1384707#post1384707
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/touchscreen/Kconfig | 4 ++--
drivers/input/touchscreen/novatek-nvt-ts.c | 8 +++-----
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 143ff43c67ae..6527abc155c9 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -655,10 +655,10 @@ config TOUCHSCREEN_MTOUCH
module will be called mtouch.
config TOUCHSCREEN_NOVATEK_NVT_TS
- tristate "Novatek NVT-ts touchscreen support"
+ tristate "Novatek NT11205 touchscreen support"
depends on I2C
help
- Say Y here if you have a Novatek NVT-ts touchscreen.
+ Say Y here if you have a Novatek NT11205 touchscreen.
If unsure, say N.
To compile this driver as a module, choose M here: the
diff --git a/drivers/input/touchscreen/novatek-nvt-ts.c b/drivers/input/touchscreen/novatek-nvt-ts.c
index e7f30eeb91ca..c06b67d221f4 100644
--- a/drivers/input/touchscreen/novatek-nvt-ts.c
+++ b/drivers/input/touchscreen/novatek-nvt-ts.c
@@ -1,9 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * Driver for Novatek i2c touchscreen controller as found on
- * the Acer Iconia One 7 B1-750 tablet. The Touchscreen controller
- * model-number is unknown. Android calls this a "NVT-ts" touchscreen,
- * but that may apply to other Novatek controller models too.
+ * Driver for Novatek NT11205 i2c touchscreen controller as found
+ * on the Acer Iconia One 7 B1-750 tablet.
*
* Copyright (c) 2023 Hans de Goede <hdegoede@redhat.com>
*/
@@ -296,6 +294,6 @@ static struct i2c_driver nvt_ts_driver = {
module_i2c_driver(nvt_ts_driver);
-MODULE_DESCRIPTION("Novatek NVT-ts touchscreen driver");
+MODULE_DESCRIPTION("Novatek NT11205 touchscreen driver");
MODULE_AUTHOR("Hans de Goede <hdegoede@redhat.com>");
MODULE_LICENSE("GPL");
--
2.40.1
^ permalink raw reply related
* Re: [PATCH 2/9] drm/panel: Check for already prepared/enabled in drm_panel
From: Chris Morgan @ 2023-05-24 16:19 UTC (permalink / raw)
To: Douglas Anderson
Cc: Jiri Kosina, Benjamin Tissoires, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Sam Ravnborg, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
dri-devel, linux-input, Dmitry Torokhov, hsinyi, devicetree,
yangcong5, linux-kernel, Daniel Vetter, linux-arm-msm,
cros-qcom-dts-watchers
In-Reply-To: <20230523122802.2.I59b417d4c29151cc2eff053369ec4822b606f375@changeid>
On Tue, May 23, 2023 at 12:27:56PM -0700, Douglas Anderson wrote:
> In a whole pile of panel drivers, we have code to make the
> prepare/unprepare/enable/disable callbacks behave as no-ops if they've
> already been called. It's silly to have this code duplicated
> everywhere. Add it to the core instead so that we can eventually
> delete it from all the drivers. Note: to get some idea of the
> duplicated code, try:
> git grep 'if.*>prepared' -- drivers/gpu/drm/panel
> git grep 'if.*>enabled' -- drivers/gpu/drm/panel
>
> NOTE: arguably, the right thing to do here is actually to skip this
> patch and simply remove all the extra checks from the individual
> drivers. Perhaps the checks were needed at some point in time in the
> past but maybe they no longer are? Certainly as we continue
For some reason I haven't dug into in greater detail on my RK3326 and
RK3568 boards I hit an issue on suspend/shutdown whereby the unprepare
is called multiple times. I suspect it's the dw-mipi-dsi-rockchip.c
driver and the dw-mipi-dsi.c drivers both calling the unprepare, but
I haven't been able to debug it completely yet.
> transitioning over to "panel_bridge" then we expect there to be much
> less variety in how these calls are made. When we're called as part of
> the bridge chain, things should be pretty simple. In fact, there was
> some discussion in the past about these checks [1], including a
> discussion about whether the checks were needed and whether the calls
> ought to be refcounted. At the time, I decided not to mess with it
> because it felt too risky.
>
> Looking closer at it now, I'm fairly certain that nothing in the
> existing codebase is expecting these calls to be refcounted. The only
Regulator unbalanced disables are a bane of my existence. For the
panel-newvision-nv3051d.c driver I upstreamed a few releases ago I was
told to not include the is_enabled logic and as a result I get a
warning on suspend or shutdown when it disables the panel. Unprepare
gets called twice and that results in an unbalanced regulator disable.
> real question is whether someone is already doing something to ensure
> prepare()/unprepare() match and enabled()/disable() match. I would say
> that, even if there is something else ensuring that things match,
> there's enough complexity that adding an extra bool and an extra
> double-check here is a good idea. Let's add a drm_warn() to let people
> know that it's considered a minor error to take advantage of
> drm_panel's double-checking but we'll still make things work fine.
>
> [1] https://lore.kernel.org/r/20210416153909.v4.27.I502f2a92ddd36c3d28d014dd75e170c2d405a0a5@changeid
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> drivers/gpu/drm/drm_panel.c | 49 ++++++++++++++++++++++++++++++++-----
> include/drm/drm_panel.h | 14 +++++++++++
> 2 files changed, 57 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index f634371c717a..4e1c4e42575b 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -105,11 +105,22 @@ EXPORT_SYMBOL(drm_panel_remove);
> */
> int drm_panel_prepare(struct drm_panel *panel)
> {
> + int ret;
> +
> if (!panel)
> return -EINVAL;
>
> - if (panel->funcs && panel->funcs->prepare)
> - return panel->funcs->prepare(panel);
> + if (panel->prepared) {
> + dev_warn(panel->dev, "Skipping prepare of already prepared panel\n");
> + return 0;
> + }
> +
> + if (panel->funcs && panel->funcs->prepare) {
> + ret = panel->funcs->prepare(panel);
> + if (ret < 0)
> + return ret;
> + }
> + panel->prepared = true;
>
> return 0;
> }
> @@ -128,11 +139,22 @@ EXPORT_SYMBOL(drm_panel_prepare);
> */
> int drm_panel_unprepare(struct drm_panel *panel)
> {
> + int ret;
> +
> if (!panel)
> return -EINVAL;
>
> - if (panel->funcs && panel->funcs->unprepare)
> - return panel->funcs->unprepare(panel);
> + if (!panel->prepared) {
> + dev_warn(panel->dev, "Skipping unprepare of already unprepared panel\n");
> + return 0;
> + }
> +
> + if (panel->funcs && panel->funcs->unprepare) {
> + ret = panel->funcs->unprepare(panel);
> + if (ret < 0)
> + return ret;
> + }
> + panel->prepared = false;
>
> return 0;
> }
> @@ -155,11 +177,17 @@ int drm_panel_enable(struct drm_panel *panel)
> if (!panel)
> return -EINVAL;
>
> + if (panel->enabled) {
> + dev_warn(panel->dev, "Skipping enable of already enabled panel\n");
> + return 0;
> + }
> +
> if (panel->funcs && panel->funcs->enable) {
> ret = panel->funcs->enable(panel);
> if (ret < 0)
> return ret;
> }
> + panel->enabled = true;
>
> ret = backlight_enable(panel->backlight);
> if (ret < 0)
> @@ -187,13 +215,22 @@ int drm_panel_disable(struct drm_panel *panel)
> if (!panel)
> return -EINVAL;
>
> + if (!panel->enabled) {
> + dev_warn(panel->dev, "Skipping disable of already disabled panel\n");
> + return 0;
> + }
> +
> ret = backlight_disable(panel->backlight);
> if (ret < 0)
> DRM_DEV_INFO(panel->dev, "failed to disable backlight: %d\n",
> ret);
>
> - if (panel->funcs && panel->funcs->disable)
> - return panel->funcs->disable(panel);
> + if (panel->funcs && panel->funcs->disable) {
> + ret = panel->funcs->disable(panel);
> + if (ret < 0)
> + return ret;
> + }
> + panel->enabled = false;
>
> return 0;
> }
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 432fab2347eb..c6cf75909389 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -198,6 +198,20 @@ struct drm_panel {
> * the panel is powered up.
> */
> bool prepare_prev_first;
> +
> + /**
> + * @prepared:
> + *
> + * If true then the panel has been prepared.
> + */
> + bool prepared;
> +
> + /**
> + * @enabled:
> + *
> + * If true then the panel has been enabled.
> + */
> + bool enabled;
> };
>
> void drm_panel_init(struct drm_panel *panel, struct device *dev,
> --
> 2.40.1.698.g37aff9b760-goog
>
Thank you for looking into this more. It's one of the last QOL bugs
for some devices I'm working on, even if the end result is no big
deal (the other QOL bug involves a WARN on probing a rotated panel).
^ permalink raw reply
* Re: [regression] Since kernel 6.3.1 logitech unify receiver not working properly
From: Benjamin Tissoires @ 2023-05-24 15:27 UTC (permalink / raw)
To: Jiri Kosina
Cc: Linus Torvalds, Linux regressions mailing list, Bagas Sanjaya,
Filipe Laíns, Bastien Nocera, open list:HID CORE LAYER, LKML,
guy.b
In-Reply-To: <nycvar.YFH.7.76.2305231422180.29760@cbobk.fhfr.pm>
On Tue, May 23, 2023 at 2:31 PM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Mon, 22 May 2023, Linus Torvalds wrote:
>
> > > FWIW, in case anybody is interested in a status update: one reporter
> > > bisected the problem down to 586e8fede79 ("HID: logitech-hidpp: Retry
> > > commands when device is busy"); reverting that commit on-top of 6.3
> > > fixes the problem for that reporter. For that reporter things also work
> > > on 6.4-rc; but for someone else that is affected that's not the case.
>
> FWIW, I was pretty much away for past few weeks as well, same as Benjamin
> as Bastien. Which is unfortunate timing, but that's how things pan out
> sometimes.
>
> > Hmm. It's likely timing-dependent.
> >
> > But that code is clearly buggy.
> >
> > If the wait_event_timeout() returns early, the device hasn't replied,
> > but the code does
> >
> > if (!wait_event_timeout(hidpp->wait, hidpp->answer_available,
> > 5*HZ)) {
> > dbg_hid("%s:timeout waiting for response\n", __func__);
> > memset(response, 0, sizeof(struct hidpp_report));
> > ret = -ETIMEDOUT;
> > }
> >
> > and then continues to look at the response _anyway_.
>
> Yeah; we are zeroing it out, but that doesn't really make things any
> better in principle, given all the dereferences later.
>
> The issue seems to be existing ever since 2f31c52529 ("HID: Introduce
> hidpp, a module to handle Logitech hid++ devices") when this whole driver
> was introduced, as far as I can tell.
Yep, that was on me. But the weird part is that I should be able to
reproduce this locally then, but I don't.
>
> > Now, depending on out hardening options, that response may have been
> > initialized by the compiler, or may just be random stack contents.
>
> Again, as in case of timeout the buffer is just zeroed out, I'd just much
> more expect NULL pointer dereference in such case. Which is not what we
> are seeing here.
Returning -ETIMEDOUT seems good to me FWIW.
>
> > That bug is pre-existing (ie the problem was not introduced by that
> > commit), but who knows if the retry makes things worse (ie if it then
> > triggers on a retry, the response data will be the *previous* response).
> >
> > The whole "goto exit" games should be removed too, because we're in a
> > for-loop, and instead of "goto exit" it should just do "break".
> >
> > IOW, something like this might be worth testing.
> >
> > That said, while I think the code is buggy, I doubt this is the actual
> > cause of the problem people are reporting. But it would be lovely to
> > hear if the attached patch makes any difference, and I think this is
> > fixing a real - but unlikely - problem anyway.
FWIW, Linus, your patch is
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Feel free to submit it to us or to apply it directly if you prefer as
this is clearly a fix for a code path issue.
I am barely struggling with everything now that I am back from last
week, being sick at the beginning of the week and still not feeling
completely well doesn't help.
Cheers,
Benjamin
> >
> > And obviously it might be helpful to actually enable those dbg_hid()
> > messages, but I didn't look at what the magic config option to do so
> > was.
>
> dbg_hid() is just pr_debug(), which means that on kernels with
> CONFIG_DYNAMIC_DEBUG, this makes use of the dynamic debug facility;
> otherwsie it just becomes printk(KERN_DEBUG...).
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
^ permalink raw reply
* Fwd: ASUS TUF FA617 [laptop] PS/2 keyboard woes
From: Nathan Schulte @ 2023-05-24 15:21 UTC (permalink / raw)
To: linux-input, Dmitry Torokhov; +Cc: Greg Kroah-Hartman, linux-acpi
In-Reply-To: <CAO78Kho+xuhUeUY9cd26j_1g2ctspnBUdb+viBemf3qKOB13Vg@mail.gmail.com>
Hello. Myself and others are experiencing issues with recent hardware
from ASUS; keyboards in laptops such as model FA617XT, FA617NS, etc.
seem to not work with Linux. The keyboards appear to work fine enough
with the BIOS and GRUB, but choke under Linux of various recent
versions (5.19, 6.1, 6.3).
An existing Kernel.org Bugzilla bug exists
(https://bugzilla.kernel.org/show_bug.cgi?id=217336) though it's noted
likely the INPUT subsystem does not use this tracker. Various logs
with i8042 debug are available there, as is some testing notes from
various patches about the interrupt configuration, though it seems
without success.
I'd like to diagnose the issue with the FA617XT if possible;
assistance with things to trial would be appreciated.
Paul Menzel suggests to not support ASUS by returning the device, and
I'm inclined to agree, however it seems ASUS is the only vendor
currently offering the latest AMD Ryzen 7000 chips in conjunction with
AMD Radeon discrete graphics, which I _would_ like to support. I am
honestly surprised there's any issue at all, given this model is the
"AMD Advantage Edition" and ought to have been thoroughly tested and
vetted in partnership with AMD. None-the-less, ASUS claims to "not
support the Linux operating system."
Thank you for your time and any assistance with this issue.
--
Nate
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS b00315628095075da4af8d6d519d85d95117de09
From: kernel test robot @ 2023-05-24 10:35 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: INFO setup_repo_specs: /db/releases/20230524154417/lkp-src/repo/*/dtor-input
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: b00315628095075da4af8d6d519d85d95117de09 Input: tests - add test to cover all input_grab_device() function
elapsed time: 720m
configs tested: 205
configs skipped: 17
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha buildonly-randconfig-r002-20230521 gcc
alpha defconfig gcc
alpha randconfig-r012-20230521 gcc
alpha randconfig-r025-20230522 gcc
alpha randconfig-r036-20230522 gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-r015-20230521 gcc
arc randconfig-r026-20230521 gcc
arc randconfig-r043-20230521 gcc
arc randconfig-r043-20230522 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm buildonly-randconfig-r004-20230522 gcc
arm buildonly-randconfig-r005-20230521 clang
arm defconfig gcc
arm randconfig-r013-20230522 gcc
arm randconfig-r031-20230521 gcc
arm randconfig-r034-20230522 clang
arm randconfig-r046-20230521 clang
arm randconfig-r046-20230522 gcc
arm64 allyesconfig gcc
arm64 buildonly-randconfig-r006-20230521 clang
arm64 defconfig gcc
arm64 randconfig-r005-20230521 clang
arm64 randconfig-r022-20230522 clang
csky buildonly-randconfig-r003-20230522 gcc
csky defconfig gcc
csky randconfig-r014-20230521 gcc
csky randconfig-r025-20230521 gcc
hexagon buildonly-randconfig-r001-20230521 clang
hexagon randconfig-r013-20230521 clang
hexagon randconfig-r025-20230521 clang
hexagon randconfig-r026-20230522 clang
hexagon randconfig-r041-20230521 clang
hexagon randconfig-r041-20230522 clang
hexagon randconfig-r045-20230521 clang
hexagon randconfig-r045-20230522 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230522 gcc
i386 randconfig-a002-20230522 gcc
i386 randconfig-a003-20230522 gcc
i386 randconfig-a004-20230522 gcc
i386 randconfig-a005-20230522 gcc
i386 randconfig-a006-20230522 gcc
i386 randconfig-a011-20230522 clang
i386 randconfig-a012-20230522 clang
i386 randconfig-a013-20230522 clang
i386 randconfig-a014-20230522 clang
i386 randconfig-a015-20230522 clang
i386 randconfig-a016-20230522 clang
i386 randconfig-r004-20230522 gcc
i386 randconfig-r011-20230522 clang
ia64 allmodconfig gcc
ia64 buildonly-randconfig-r001-20230522 gcc
ia64 buildonly-randconfig-r003-20230522 gcc
ia64 buildonly-randconfig-r006-20230521 gcc
ia64 defconfig gcc
ia64 randconfig-r022-20230521 gcc
ia64 randconfig-r031-20230521 gcc
ia64 randconfig-r035-20230522 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-r004-20230522 gcc
loongarch randconfig-r014-20230522 gcc
loongarch randconfig-r016-20230521 gcc
loongarch randconfig-r021-20230521 gcc
loongarch randconfig-r023-20230522 gcc
loongarch randconfig-r026-20230521 gcc
m68k allmodconfig gcc
m68k defconfig gcc
m68k randconfig-r036-20230522 gcc
microblaze randconfig-r006-20230521 gcc
microblaze randconfig-r012-20230522 gcc
microblaze randconfig-r013-20230522 gcc
microblaze randconfig-r021-20230521 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips buildonly-randconfig-r002-20230522 clang
mips randconfig-r004-20230521 gcc
mips randconfig-r011-20230522 gcc
mips randconfig-r012-20230521 clang
mips randconfig-r013-20230521 clang
mips randconfig-r033-20230522 clang
nios2 defconfig gcc
nios2 randconfig-r015-20230521 gcc
nios2 randconfig-r026-20230522 gcc
openrisc buildonly-randconfig-r003-20230521 gcc
openrisc randconfig-r002-20230522 gcc
openrisc randconfig-r033-20230521 gcc
openrisc randconfig-r036-20230521 gcc
parisc buildonly-randconfig-r001-20230521 gcc
parisc buildonly-randconfig-r004-20230522 gcc
parisc defconfig gcc
parisc randconfig-r001-20230522 gcc
parisc randconfig-r002-20230521 gcc
parisc randconfig-r015-20230522 gcc
parisc randconfig-r023-20230521 gcc
parisc randconfig-r024-20230522 gcc
parisc randconfig-r032-20230521 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc randconfig-r006-20230522 gcc
powerpc randconfig-r011-20230521 gcc
powerpc randconfig-r024-20230521 gcc
powerpc randconfig-r034-20230521 clang
powerpc randconfig-r034-20230522 gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r004-20230521 gcc
riscv buildonly-randconfig-r005-20230522 clang
riscv buildonly-randconfig-r006-20230522 clang
riscv defconfig gcc
riscv randconfig-r021-20230522 clang
riscv randconfig-r022-20230522 clang
riscv randconfig-r031-20230522 gcc
riscv randconfig-r036-20230521 clang
riscv randconfig-r042-20230521 gcc
riscv randconfig-r042-20230522 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r001-20230521 clang
s390 randconfig-r002-20230521 clang
s390 randconfig-r016-20230521 gcc
s390 randconfig-r034-20230521 clang
s390 randconfig-r044-20230521 gcc
s390 randconfig-r044-20230522 clang
sh allmodconfig gcc
sh buildonly-randconfig-r004-20230521 gcc
sh buildonly-randconfig-r005-20230522 gcc
sh randconfig-r002-20230522 gcc
sh randconfig-r006-20230521 gcc
sh randconfig-r015-20230522 gcc
sh randconfig-r035-20230521 gcc
sparc defconfig gcc
sparc randconfig-r005-20230522 gcc
sparc randconfig-r012-20230522 gcc
sparc randconfig-r014-20230522 gcc
sparc randconfig-r016-20230522 gcc
sparc randconfig-r024-20230522 gcc
sparc64 buildonly-randconfig-r002-20230522 gcc
sparc64 randconfig-r001-20230522 gcc
sparc64 randconfig-r003-20230521 gcc
sparc64 randconfig-r006-20230522 gcc
sparc64 randconfig-r023-20230522 gcc
sparc64 randconfig-r024-20230521 gcc
sparc64 randconfig-r032-20230521 gcc
sparc64 randconfig-r032-20230522 gcc
sparc64 randconfig-r033-20230521 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230522 gcc
x86_64 randconfig-a002-20230522 gcc
x86_64 randconfig-a003-20230522 gcc
x86_64 randconfig-a004-20230522 gcc
x86_64 randconfig-a005-20230522 gcc
x86_64 randconfig-a006-20230522 gcc
x86_64 randconfig-a011-20230522 clang
x86_64 randconfig-a012-20230522 clang
x86_64 randconfig-a013-20230522 clang
x86_64 randconfig-a014-20230522 clang
x86_64 randconfig-a015-20230522 clang
x86_64 randconfig-a016-20230522 clang
x86_64 randconfig-x051-20230522 clang
x86_64 randconfig-x052-20230522 clang
x86_64 randconfig-x053-20230522 clang
x86_64 randconfig-x054-20230522 clang
x86_64 randconfig-x055-20230522 clang
x86_64 randconfig-x056-20230522 clang
x86_64 randconfig-x061-20230522 clang
x86_64 randconfig-x062-20230522 clang
x86_64 randconfig-x063-20230522 clang
x86_64 randconfig-x064-20230522 clang
x86_64 randconfig-x065-20230522 clang
x86_64 randconfig-x066-20230522 clang
x86_64 randconfig-x071-20230522 gcc
x86_64 randconfig-x072-20230522 gcc
x86_64 randconfig-x073-20230522 gcc
x86_64 randconfig-x074-20230522 gcc
x86_64 randconfig-x075-20230522 gcc
x86_64 randconfig-x076-20230522 gcc
x86_64 randconfig-x081-20230522 gcc
x86_64 randconfig-x082-20230522 gcc
x86_64 randconfig-x083-20230522 gcc
x86_64 randconfig-x084-20230522 gcc
x86_64 randconfig-x085-20230522 gcc
x86_64 randconfig-x086-20230522 gcc
x86_64 rhel-8.3 gcc
xtensa buildonly-randconfig-r001-20230522 gcc
xtensa buildonly-randconfig-r005-20230521 gcc
xtensa randconfig-r001-20230521 gcc
xtensa randconfig-r003-20230522 gcc
xtensa randconfig-r014-20230521 gcc
xtensa randconfig-r032-20230522 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS feee70f4568650cf44c573488798ffc0a2faeea3
From: kernel test robot @ 2023-05-24 10:35 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: INFO setup_repo_specs: /db/releases/20230524154417/lkp-src/repo/*/dtor-input
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: feee70f4568650cf44c573488798ffc0a2faeea3 Input: xpad - delete a Razer DeathAdder mouse VID/PID entry
elapsed time: 720m
configs tested: 183
configs skipped: 15
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha buildonly-randconfig-r002-20230522 gcc
alpha buildonly-randconfig-r003-20230522 gcc
alpha defconfig gcc
alpha randconfig-r013-20230521 gcc
alpha randconfig-r013-20230523 gcc
alpha randconfig-r014-20230523 gcc
alpha randconfig-r025-20230521 gcc
alpha randconfig-r033-20230522 gcc
arc allyesconfig gcc
arc axs101_defconfig gcc
arc buildonly-randconfig-r004-20230521 gcc
arc buildonly-randconfig-r006-20230522 gcc
arc defconfig gcc
arc hsdk_defconfig gcc
arc nsimosci_defconfig gcc
arc randconfig-r015-20230521 gcc
arc randconfig-r024-20230521 gcc
arc randconfig-r034-20230522 gcc
arc randconfig-r035-20230521 gcc
arc randconfig-r036-20230521 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm imx_v6_v7_defconfig gcc
arm randconfig-r024-20230522 gcc
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r011-20230523 gcc
arm64 randconfig-r021-20230522 clang
arm64 randconfig-r023-20230521 gcc
csky buildonly-randconfig-r002-20230522 gcc
csky defconfig gcc
csky randconfig-r012-20230521 gcc
csky randconfig-r014-20230521 gcc
csky randconfig-r022-20230522 gcc
csky randconfig-r026-20230521 gcc
csky randconfig-r026-20230522 gcc
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230522 gcc
i386 randconfig-a002-20230522 gcc
i386 randconfig-a003-20230522 gcc
i386 randconfig-a004-20230522 gcc
i386 randconfig-a005-20230522 gcc
i386 randconfig-a006-20230522 gcc
i386 randconfig-i051-20230524 gcc
i386 randconfig-i052-20230524 gcc
i386 randconfig-i053-20230524 gcc
i386 randconfig-i054-20230524 gcc
i386 randconfig-i055-20230524 gcc
i386 randconfig-i056-20230524 gcc
i386 randconfig-i061-20230523 clang
i386 randconfig-i062-20230523 clang
i386 randconfig-i063-20230523 clang
i386 randconfig-i064-20230523 clang
i386 randconfig-i065-20230523 clang
i386 randconfig-i066-20230523 clang
ia64 allmodconfig gcc
ia64 buildonly-randconfig-r001-20230521 gcc
ia64 defconfig gcc
ia64 randconfig-r013-20230522 gcc
ia64 randconfig-r015-20230523 gcc
ia64 randconfig-r016-20230521 gcc
ia64 randconfig-r021-20230521 gcc
ia64 randconfig-r023-20230521 gcc
ia64 randconfig-r025-20230522 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch buildonly-randconfig-r003-20230521 gcc
loongarch buildonly-randconfig-r006-20230521 gcc
loongarch defconfig gcc
loongarch randconfig-r012-20230522 gcc
loongarch randconfig-r012-20230523 gcc
loongarch randconfig-r022-20230521 gcc
loongarch randconfig-r022-20230522 gcc
m68k allmodconfig gcc
m68k buildonly-randconfig-r003-20230522 gcc
m68k defconfig gcc
m68k randconfig-r011-20230522 gcc
m68k randconfig-r024-20230522 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips buildonly-randconfig-r006-20230521 gcc
mips malta_qemu_32r6_defconfig clang
mips randconfig-r032-20230521 gcc
mips randconfig-r036-20230522 clang
nios2 buildonly-randconfig-r001-20230522 gcc
nios2 buildonly-randconfig-r005-20230521 gcc
nios2 defconfig gcc
nios2 randconfig-r016-20230522 gcc
nios2 randconfig-r025-20230521 gcc
openrisc buildonly-randconfig-r001-20230522 gcc
openrisc buildonly-randconfig-r004-20230521 gcc
openrisc randconfig-r015-20230522 gcc
openrisc randconfig-r031-20230522 gcc
openrisc randconfig-r034-20230521 gcc
parisc defconfig gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc buildonly-randconfig-r002-20230521 gcc
powerpc chrp32_defconfig gcc
powerpc randconfig-r023-20230522 clang
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv defconfig gcc
riscv randconfig-r035-20230521 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r033-20230521 clang
sh allmodconfig gcc
sh buildonly-randconfig-r005-20230522 gcc
sh randconfig-r014-20230522 gcc
sh randconfig-r035-20230522 gcc
sh se7705_defconfig gcc
sh sh7710voipgw_defconfig gcc
sparc buildonly-randconfig-r004-20230522 gcc
sparc buildonly-randconfig-r005-20230522 gcc
sparc defconfig gcc
sparc randconfig-r011-20230521 gcc
sparc randconfig-r013-20230521 gcc
sparc randconfig-r015-20230521 gcc
sparc randconfig-r023-20230522 gcc
sparc64 randconfig-r012-20230522 gcc
um defconfig gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230522 gcc
x86_64 randconfig-a002-20230522 gcc
x86_64 randconfig-a003-20230522 gcc
x86_64 randconfig-a004-20230522 gcc
x86_64 randconfig-a005-20230522 gcc
x86_64 randconfig-a006-20230522 gcc
x86_64 randconfig-a011-20230522 clang
x86_64 randconfig-a012-20230522 clang
x86_64 randconfig-a013-20230522 clang
x86_64 randconfig-a014-20230522 clang
x86_64 randconfig-a015-20230522 clang
x86_64 randconfig-a016-20230522 clang
x86_64 randconfig-r015-20230522 clang
x86_64 randconfig-x051-20230522 clang
x86_64 randconfig-x052-20230522 clang
x86_64 randconfig-x052 clang
x86_64 randconfig-x053-20230522 clang
x86_64 randconfig-x054-20230522 clang
x86_64 randconfig-x054 clang
x86_64 randconfig-x055-20230522 clang
x86_64 randconfig-x056-20230522 clang
x86_64 randconfig-x056 clang
x86_64 randconfig-x061-20230522 clang
x86_64 randconfig-x062-20230522 clang
x86_64 randconfig-x063-20230522 clang
x86_64 randconfig-x064-20230522 clang
x86_64 randconfig-x065-20230522 clang
x86_64 randconfig-x066-20230522 clang
x86_64 randconfig-x071-20230522 gcc
x86_64 randconfig-x072-20230522 gcc
x86_64 randconfig-x073-20230522 gcc
x86_64 randconfig-x074-20230522 gcc
x86_64 randconfig-x075-20230522 gcc
x86_64 randconfig-x076-20230522 gcc
x86_64 randconfig-x081-20230522 gcc
x86_64 randconfig-x082-20230522 gcc
x86_64 randconfig-x083-20230522 gcc
x86_64 randconfig-x084-20230522 gcc
x86_64 randconfig-x085-20230522 gcc
x86_64 randconfig-x086-20230522 gcc
x86_64 randconfig-x091-20230524 clang
x86_64 randconfig-x092-20230524 clang
x86_64 randconfig-x093-20230524 clang
x86_64 randconfig-x094-20230524 clang
x86_64 randconfig-x095-20230524 clang
x86_64 randconfig-x096-20230524 clang
x86_64 rhel-8.3 gcc
xtensa randconfig-r016-20230521 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* Re: amd_sfh driver causes kernel oops during boot
From: Bagas Sanjaya @ 2023-05-24 10:10 UTC (permalink / raw)
To: Haochen Tong, stable; +Cc: regressions, linux-input, Basavaraj Natikar
In-Reply-To: <ee2c30a5-3927-d892-2a66-00cd513c3899@hexchain.org>
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
On Wed, May 24, 2023 at 02:10:31PM +0800, Haochen Tong wrote:
> > What last kernel version before this regression occurs? Do you mean
> > v6.2?
> >
>
> I was using 6.2.12 (Arch Linux distro kernel) before seeing this regression.
Can you perform bisection to find the culprit that introduces the
regression? Since you're on Arch Linux, see its wiki article [1] for
instructions.
Thanks.
[1]: https://wiki.archlinux.org/title/Bisecting_bugs_with_Git
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: amd_sfh driver causes kernel oops during boot
From: Bagas Sanjaya @ 2023-05-24 10:08 UTC (permalink / raw)
To: Haochen Tong, stable
Cc: Linux Regressions, Linux Input Devices, Basavaraj Natikar,
Jiri Kosina, Benjamin Tissoires
In-Reply-To: <f40e3897-76f1-2cd0-2d83-e48d87130eab@hexchain.org>
[-- Attachment #1: Type: text/plain, Size: 10214 bytes --]
On Wed, May 24, 2023 at 01:27:57AM +0800, Haochen Tong wrote:
> Hi,
>
> Since kernel 6.3.0 (and also 6.4rc3), on a ThinkPad Z13 system with Arch
> Linux, I've noticed that the amd_sfh driver spews a lot of stack traces
> during boot. Sometimes it is an oops:
>
> BUG: unable to handle page fault for address: 000000000001000f
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: 0000 [#1] PREEMPT SMP NOPTI
> CPU: 8 PID: 457 Comm: (udev-worker) Not tainted 6.3.3-arch1-1 #1
> fa7b7e0107004b3021a57a74b951e0a25e7e8584
> Hardware name: LENOVO 21D2CTO1WW/21D2CTO1WW, BIOS N3GET47W (1.27 )
> 12/08/2022
> RIP: 0010:amd_sfh_get_report+0x1e/0x110 [amd_sfh]
> Code: 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 57
> 41 56 41 55 41 54 55 53 48 8b 87 60 1d 00 00 48 8b 68 08 <8b> 45 10 85 c0 0f
> 84 a9 00 00 00 49 89 fc 41 89 f7 41 89 d6 31 db
> RSP: 0018:ffffb164426f3a20 EFLAGS: 00010246
> RAX: ffff9b0ae6b7bd00 RBX: ffff9b0ac0f46000 RCX: 0000000000000000
> RDX: 0000000000000002 RSI: 0000000000000002 RDI: ffff9b0ac0f46000
> RBP: 000000000000ffff R08: ffffb164426f3ab8 R09: ffffb164426f3ab8
> R10: 000000000020031b R11: ffff9b0ace40ac00 R12: ffff9b0ace40ac00
> R13: 0000000000000002 R14: 0000000000000002 R15: ffff9b0acd213010
> FS: 00007fe9ceb82200(0000) GS:ffff9b1122000000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000000000001000f CR3: 000000010940c000 CR4: 0000000000750ee0
> PKRU: 55555554
> Call Trace:
> <TASK>
> amdtp_hid_request+0x36/0x50 [amd_sfh
> 2e3095779aada9fdb1764f08ca578ccb14e41fe4]
> sensor_hub_get_feature+0xad/0x170 [hid_sensor_hub
> d6157999c9d260a1bfa6f27d4a0dc2c3e2c5654e]
> hid_sensor_parse_common_attributes+0x217/0x310 [hid_sensor_iio_common
> 07a7935272aa9c7a28193b574580b3e953a64ec4]
> hid_gyro_3d_probe+0x7f/0x2e0 [hid_sensor_gyro_3d
> 9f2eb51294a1f0c0315b365f335617cbaef01eab]
> platform_probe+0x44/0xa0
> really_probe+0x19e/0x3e0
> ? __pfx___driver_attach+0x10/0x10
> __driver_probe_device+0x78/0x160
> driver_probe_device+0x1f/0x90
> __driver_attach+0xd2/0x1c0
> bus_for_each_dev+0x88/0xd0
> bus_add_driver+0x116/0x220
> driver_register+0x59/0x100
> ? __pfx_init_module+0x10/0x10 [hid_sensor_gyro_3d
> 9f2eb51294a1f0c0315b365f335617cbaef01eab]
> do_one_initcall+0x5d/0x240
> do_init_module+0x4a/0x200
> __do_sys_init_module+0x17f/0x1b0
> do_syscall_64+0x60/0x90
> ? ksys_read+0x6f/0xf0
> ? syscall_exit_to_user_mode+0x1b/0x40
> ? do_syscall_64+0x6c/0x90
> ? exc_page_fault+0x7c/0x180
> entry_SYSCALL_64_after_hwframe+0x72/0xdc
> RIP: 0033:0x7fe9ce721f9e
> Code: 48 8b 0d bd ed 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00
> 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff
> 73 01 c3 48 8b 0d 8a ed 0c 00 f7 d8 64 89 01 48
> RSP: 002b:00007ffd280dd828 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
> RAX: ffffffffffffffda RBX: 000055b72a37f630 RCX: 00007fe9ce721f9e
> RDX: 00007fe9cec7a343 RSI: 00000000000077f8 RDI: 000055b72a56c7f0
> RBP: 00007fe9cec7a343 R08: 00000000000077f8 R09: 0000000000000000
> R10: 000000000001a0a1 R11: 0000000000000246 R12: 0000000000020000
> R13: 000055b72a363b90 R14: 000055b72a37f630 R15: 000055b72a36a070
> </TASK>
> Modules linked in: hid_sensor_accel_3d(+) hid_sensor_gyro_3d(+) qrtr
> hid_sensor_trigger snd_sof industrialio_triggered_buffer ath11k_pci(+)
> kfifo_buf snd_sof_utils hid_sensor_iio_common joydev ath11k industrialio
> snd_soc_core mousedev qmi_helpers snd_compress hid_sensor_hub
> snd_hda_scodec_cs35l41_spi ac97_bus snd_hda_codec_realtek(+)
> snd_pcm_dmaengine intel_rapl_msr snd_hda_codec_hdmi snd_hda_codec_generic
> intel_rapl_common mac80211 snd_pci_ps btusb snd_rpl_pci_acp6x btrtl
> snd_hda_intel edac_mce_amd uvcvideo btbcm snd_acp_pci snd_intel_dspcfg
> snd_pci_acp6x videobuf2_vmalloc snd_intel_sdw_acpi libarc4 uvc btintel
> snd_usb_audio(+) snd_pci_acp5x videobuf2_memops btmtk snd_hda_codec kvm_amd
> videobuf2_v4l2 snd_hda_scodec_cs35l41_i2c snd_usbmidi_lib
> snd_hda_scodec_cs35l41 snd_rn_pci_acp3x ucsi_acpi bluetooth videodev
> snd_hda_core typec_ucsi snd_acp_config snd_hda_cs_dsp_ctls wacom(+)
> hid_multitouch cfg80211 snd_rawmidi sp5100_tco kvm snd_seq_device cs_dsp
> videobuf2_common typec ecdh_generic snd_soc_acpi
> think_lmi snd_hwdep snd_pcm irqbypass crc16 snd_soc_cs35l41_lib mhi
> thunderbolt firmware_attributes_class snd_pci_acp3x amd_sfh(+) k10temp
> psmouse roles rapl i2c_piix4 mc snd_timer wmi_bmof serial_multi_instantiate
> i2c_hid_acpi acpi_tad i2c_hid amd_pmf amd_pmc mac_hid sch_fq tcp_bbr
> dm_multipath i2c_dev crypto_user fuse loop zram ip_tables x_tables xfs
> libcrc32c crc32c_generic dm_crypt cbc encrypted_keys trusted asn1_encoder
> tee usbhid dm_mod amdgpu i2c_algo_bit serio_raw thinkpad_acpi drm_ttm_helper
> atkbd libps2 crct10dif_pclmul vivaldi_fmap crc32_pclmul ledtrig_audio
> crc32c_intel polyval_clmulni ttm polyval_generic drm_buddy nvme gf128mul
> platform_profile gpu_sched ghash_clmulni_intel sha512_ssse3 snd aesni_intel
> soundcore drm_display_helper crypto_simd rfkill nvme_core xhci_pci cryptd
> cec ccp xhci_pci_renesas i8042 video nvme_common serio wmi
> CR2: 000000000001000f
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:amd_sfh_get_report+0x1e/0x110 [amd_sfh]
> Code: 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 57
> 41 56 41 55 41 54 55 53 48 8b 87 60 1d 00 00 48 8b 68 08 <8b> 45 10 85 c0 0f
> 84 a9 00 00 00 49 89 fc 41 89 f7 41 89 d6 31 db
> RSP: 0018:ffffb164426f3a20 EFLAGS: 00010246
> RAX: ffff9b0ae6b7bd00 RBX: ffff9b0ac0f46000 RCX: 0000000000000000
> RDX: 0000000000000002 RSI: 0000000000000002 RDI: ffff9b0ac0f46000
> RBP: 000000000000ffff R08: ffffb164426f3ab8 R09: ffffb164426f3ab8
> R10: 000000000020031b R11: ffff9b0ace40ac00 R12: ffff9b0ace40ac00
> R13: 0000000000000002 R14: 0000000000000002 R15: ffff9b0acd213010
> FS: 00007fe9ceb82200(0000) GS:ffff9b1122000000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000000000001000f CR3: 000000010940c000 CR4: 0000000000750ee0
> PKRU: 55555554
>
> Sometimes it is a list corruption in the same function with a similar stack:
>
> ------------[ cut here ]------------
> list_add corruption. next is NULL.
> WARNING: CPU: 5 PID: 433 at lib/list_debug.c:25 __list_add_valid+0x57/0xa0
> ...
> CPU: 5 PID: 433 Comm: (udev-worker) Not tainted 6.4.0-rc3-1-mainline #1
> b60166e85cb97a6631db26f9dcda0196ed7a0c93
> Hardware name: LENOVO 21D2CTO1WW/21D2CTO1WW, BIOS N3GET47W (1.27 )
> 12/08/2022
> RIP: 0010:__list_add_valid+0x57/0xa0
> Code: 01 00 00 00 c3 cc cc cc cc 48 c7 c7 58 91 e6 9a e8 1e b9 a8 ff 0f 0b
> 31 c0 c3 cc cc cc cc 48 c7 c7 80 91 e6 9a e8 09 b9 a8 ff <0f> 0b eb e9 48 89
> c1 48 c7 c7 a8 91 e6 9a e8 f6 b8 a8 ff 0f 0b eb
> RSP: 0018:ffffad9dc0c7bb10 EFLAGS: 00010286
> RAX: 0000000000000000 RBX: ffff92d5a8099448 RCX: 0000000000000027
> RDX: ffff92dbe1f61688 RSI: 0000000000000001 RDI: ffff92dbe1f61680
> RBP: ffff92d59ea93508 R08: 0000000000000000 R09: ffffad9dc0c7b9a0
> R10: 0000000000000003 R11: ffffffff9b6ca808 R12: 0000000000000000
> R13: ffff92d5a8099440 R14: ffff92d59ea93760 R15: 0000000000000002
> FS: 00007fbaf0262200(0000) GS:ffff92dbe1f40000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005651de666000 CR3: 000000011cfee000 CR4: 0000000000750ee0
> PKRU: 55555554
> Call Trace:
> <TASK>
> amd_sfh_get_report+0xba/0x110 [amd_sfh
> 78bf82e66cdb2ccf24cbe871a0835ef4eedddb17]
> amdtp_hid_request+0x36/0x50 [amd_sfh
> 78bf82e66cdb2ccf24cbe871a0835ef4eedddb17]
> sensor_hub_get_feature+0xad/0x170 [hid_sensor_hub
> 30e53e2c49ea1702e2482c0b3860e22265679e39]
> hid_sensor_parse_common_attributes+0x217/0x310 [hid_sensor_iio_common
> ed7fba7a4d4147d48156e6a4b2a034ad3fc94350]
> hid_gyro_3d_probe+0x7f/0x2e0 [hid_sensor_gyro_3d
> 10978a2cdfc8979f2a7366fcd005e0ea826088eb]
> platform_probe+0x44/0xa0
> really_probe+0x19e/0x3e0
> ? __pfx___driver_attach+0x10/0x10
> __driver_probe_device+0x78/0x160
> driver_probe_device+0x1f/0x90
> __driver_attach+0xd2/0x1c0
> bus_for_each_dev+0x88/0xd0
> bus_add_driver+0x116/0x220
> driver_register+0x59/0x100
> ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d
> 10978a2cdfc8979f2a7366fcd005e0ea826088eb]
> do_one_initcall+0x5d/0x240
> do_init_module+0x60/0x240
> __do_sys_init_module+0x17f/0x1b0
> do_syscall_64+0x60/0x90
> ? exc_page_fault+0x7f/0x180
> entry_SYSCALL_64_after_hwframe+0x72/0xdc
> RIP: 0033:0x7fbaf06c0f9e
> Code: 48 8b 0d bd ed 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00
> 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff
> 73 01 c3 48 8b 0d 8a ed 0c 00 f7 d8 64 89 01 48
> RSP: 002b:00007ffc5ce88528 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
> RAX: ffffffffffffffda RBX: 00005651de36dff0 RCX: 00007fbaf06c0f9e
> RDX: 00007fbaf0ba9343 RSI: 00000000000079f0 RDI: 00005651de646fe0
> RBP: 00007fbaf0ba9343 R08: 00000000000079f0 R09: 0000000000000000
> R10: 0000000000019fb1 R11: 0000000000000246 R12: 0000000000020000
> R13: 00005651de45fb10 R14: 00005651de36dff0 R15: 00005651de44d5f0
> </TASK>
> ---[ end trace 0000000000000000 ]---
>
> This occurs during almost every boot. When it happens there is usually a
> (udev-worker) process lingering forever, which is unkillable and even
> prevents shutdown.
>
> Looking at past journals it never happened before 6.3 so I believe it is a
> regression.
>
> Relevant device:
> 63:00.7 Signal processing controller [1180]: Advanced Micro Devices, Inc.
> [AMD] Sensor Fusion Hub [1022:15e4]
> Subsystem: Lenovo Sensor Fusion Hub [17aa:22f1]
> Kernel driver in use: pcie_mp2_amd
> Kernel modules: amd_sfh
>
Thanks for the bug report. I'm adding it to regzbot:
#regzbot ^introduced: v6.2..v6.3
#regzbot title: amd_sfh driver causes kernel oops (udev-worker becomes zombie) on ThinkPad Z13
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/9] drm/panel: Check for already prepared/enabled in drm_panel
From: Neil Armstrong @ 2023-05-24 9:52 UTC (permalink / raw)
To: Douglas Anderson, Jiri Kosina, Benjamin Tissoires,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sam Ravnborg, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: dri-devel, linux-input, Dmitry Torokhov, hsinyi, devicetree,
yangcong5, linux-kernel, Daniel Vetter, linux-arm-msm,
cros-qcom-dts-watchers
In-Reply-To: <20230523122802.2.I59b417d4c29151cc2eff053369ec4822b606f375@changeid>
Hi,
On 23/05/2023 21:27, Douglas Anderson wrote:
> In a whole pile of panel drivers, we have code to make the
> prepare/unprepare/enable/disable callbacks behave as no-ops if they've
> already been called. It's silly to have this code duplicated
> everywhere. Add it to the core instead so that we can eventually
> delete it from all the drivers. Note: to get some idea of the
> duplicated code, try:
> git grep 'if.*>prepared' -- drivers/gpu/drm/panel
> git grep 'if.*>enabled' -- drivers/gpu/drm/panel
>
> NOTE: arguably, the right thing to do here is actually to skip this
> patch and simply remove all the extra checks from the individual
> drivers. Perhaps the checks were needed at some point in time in the
> past but maybe they no longer are? Certainly as we continue
> transitioning over to "panel_bridge" then we expect there to be much
> less variety in how these calls are made. When we're called as part of
> the bridge chain, things should be pretty simple. In fact, there was
> some discussion in the past about these checks [1], including a
> discussion about whether the checks were needed and whether the calls
> ought to be refcounted. At the time, I decided not to mess with it
> because it felt too risky.
>
> Looking closer at it now, I'm fairly certain that nothing in the
> existing codebase is expecting these calls to be refcounted. The only
> real question is whether someone is already doing something to ensure
> prepare()/unprepare() match and enabled()/disable() match. I would say
> that, even if there is something else ensuring that things match,
> there's enough complexity that adding an extra bool and an extra
> double-check here is a good idea. Let's add a drm_warn() to let people
> know that it's considered a minor error to take advantage of
> drm_panel's double-checking but we'll still make things work fine.
>
> [1] https://lore.kernel.org/r/20210416153909.v4.27.I502f2a92ddd36c3d28d014dd75e170c2d405a0a5@changeid
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> drivers/gpu/drm/drm_panel.c | 49 ++++++++++++++++++++++++++++++++-----
> include/drm/drm_panel.h | 14 +++++++++++
> 2 files changed, 57 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index f634371c717a..4e1c4e42575b 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -105,11 +105,22 @@ EXPORT_SYMBOL(drm_panel_remove);
> */
> int drm_panel_prepare(struct drm_panel *panel)
> {
> + int ret;
> +
> if (!panel)
> return -EINVAL;
>
> - if (panel->funcs && panel->funcs->prepare)
> - return panel->funcs->prepare(panel);
> + if (panel->prepared) {
> + dev_warn(panel->dev, "Skipping prepare of already prepared panel\n");
> + return 0;
> + }
> +
> + if (panel->funcs && panel->funcs->prepare) {
> + ret = panel->funcs->prepare(panel);
> + if (ret < 0)
> + return ret;
> + }
> + panel->prepared = true;
>
> return 0;
> }
> @@ -128,11 +139,22 @@ EXPORT_SYMBOL(drm_panel_prepare);
> */
> int drm_panel_unprepare(struct drm_panel *panel)
> {
> + int ret;
> +
> if (!panel)
> return -EINVAL;
>
> - if (panel->funcs && panel->funcs->unprepare)
> - return panel->funcs->unprepare(panel);
> + if (!panel->prepared) {
> + dev_warn(panel->dev, "Skipping unprepare of already unprepared panel\n");
> + return 0;
> + }
> +
> + if (panel->funcs && panel->funcs->unprepare) {
> + ret = panel->funcs->unprepare(panel);
> + if (ret < 0)
> + return ret;
> + }
> + panel->prepared = false;
>
> return 0;
> }
> @@ -155,11 +177,17 @@ int drm_panel_enable(struct drm_panel *panel)
> if (!panel)
> return -EINVAL;
>
> + if (panel->enabled) {
> + dev_warn(panel->dev, "Skipping enable of already enabled panel\n");
> + return 0;
> + }
> +
> if (panel->funcs && panel->funcs->enable) {
> ret = panel->funcs->enable(panel);
> if (ret < 0)
> return ret;
> }
> + panel->enabled = true;
>
> ret = backlight_enable(panel->backlight);
> if (ret < 0)
> @@ -187,13 +215,22 @@ int drm_panel_disable(struct drm_panel *panel)
> if (!panel)
> return -EINVAL;
>
> + if (!panel->enabled) {
> + dev_warn(panel->dev, "Skipping disable of already disabled panel\n");
> + return 0;
> + }
> +
> ret = backlight_disable(panel->backlight);
> if (ret < 0)
> DRM_DEV_INFO(panel->dev, "failed to disable backlight: %d\n",
> ret);
>
> - if (panel->funcs && panel->funcs->disable)
> - return panel->funcs->disable(panel);
> + if (panel->funcs && panel->funcs->disable) {
> + ret = panel->funcs->disable(panel);
> + if (ret < 0)
> + return ret;
> + }
> + panel->enabled = false;
>
> return 0;
> }
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 432fab2347eb..c6cf75909389 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -198,6 +198,20 @@ struct drm_panel {
> * the panel is powered up.
> */
> bool prepare_prev_first;
> +
> + /**
> + * @prepared:
> + *
> + * If true then the panel has been prepared.
> + */
> + bool prepared;
> +
> + /**
> + * @enabled:
> + *
> + * If true then the panel has been enabled.
> + */
> + bool enabled;
> };
>
> void drm_panel_init(struct drm_panel *panel, struct device *dev,
LGTM and let's cleanup the panel drivers
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* Re: amd_sfh driver causes kernel oops during boot
From: Haochen Tong @ 2023-05-24 6:10 UTC (permalink / raw)
To: Bagas Sanjaya, stable; +Cc: regressions, linux-input, Basavaraj Natikar
In-Reply-To: <ZG2LXN2+Sa2PWJqz@debian.me>
Hi,
On 5/24/23 11:58, Bagas Sanjaya wrote:
> On Wed, May 24, 2023 at 01:27:57AM +0800, Haochen Tong wrote:
>> Hi,
>>
>> Since kernel 6.3.0 (and also 6.4rc3), on a ThinkPad Z13 system with Arch
>> Linux, I've noticed that the amd_sfh driver spews a lot of stack traces
>> during boot. Sometimes it is an oops:
>
> What last kernel version before this regression occurs? Do you mean
> v6.2?
>
I was using 6.2.12 (Arch Linux distro kernel) before seeing this regression.
Thanks.
^ permalink raw reply
* Re: amd_sfh driver causes kernel oops during boot
From: Bagas Sanjaya @ 2023-05-24 3:58 UTC (permalink / raw)
To: Haochen Tong, stable; +Cc: regressions, linux-input, Basavaraj Natikar
In-Reply-To: <f40e3897-76f1-2cd0-2d83-e48d87130eab@hexchain.org>
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
On Wed, May 24, 2023 at 01:27:57AM +0800, Haochen Tong wrote:
> Hi,
>
> Since kernel 6.3.0 (and also 6.4rc3), on a ThinkPad Z13 system with Arch
> Linux, I've noticed that the amd_sfh driver spews a lot of stack traces
> during boot. Sometimes it is an oops:
What last kernel version before this regression occurs? Do you mean
v6.2?
Thanks.
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH RESEND v4 2/2] HID: i2c-hid: goodix: Add support for "goodix,no-reset-during-suspend" property
From: Fei Shao @ 2023-05-24 3:42 UTC (permalink / raw)
To: Jiri Kosina
Cc: Rob Herring, Matthias Brugger, Jeff LaBundy, Douglas Anderson,
Fei Shao, Benjamin Tissoires, Dmitry Torokhov, Matthias Kaehlcke,
Stephen Kitt, linux-input, linux-kernel
In-Reply-To: <20230524114233.RESEND.v4.2.I424e840ae6de3cdbd67394cf4efd24534f6434ba@changeid>
In the beginning, commit 18eeef46d359 ("HID: i2c-hid: goodix: Tie the
reset line to true state of the regulator") introduced a change to tie
the reset line of the Goodix touchscreen to the state of the regulator
to fix a power leakage issue in suspend.
After some time, the change was deemed unnecessary and was reverted in
commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the reset line to
the regulator") due to difficulties in managing regulator notifiers for
designs like Evoker, which provides a second power rail to touchscreen.
However, the revert caused a power regression on another Chromebook
device Steelix in the field, which has a dedicated always-on regulator
for touchscreen and was covered by the workaround in the first commit.
To address both cases, this patch adds the support for the new
"goodix,no-reset-during-suspend" property in the driver:
- When set to true, the driver does not assert the reset GPIO during
power-down.
Instead, the GPIO will be asserted during power-up to ensure the
touchscreen always has a clean start and consistent behavior after
resuming.
This is for designs with a dedicated always-on regulator.
- When set to false or unset, the driver uses the original control flow
and asserts GPIO and disables regulators normally.
This is for the two-regulator and shared-regulator designs.
Signed-off-by: Fei Shao <fshao@chromium.org>
Suggested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
---
Changes in v4:
- Minor coding style improvement
Changes in v3:
- In power-down, only skip the GPIO but not the regulator calls if the
flag is set
Changes in v2:
- Drop the change to regulator_enable logic during power-up
drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-of-goodix.c b/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
index 0060e3dcd775..db4639db9840 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
@@ -28,6 +28,7 @@ struct i2c_hid_of_goodix {
struct regulator *vdd;
struct regulator *vddio;
struct gpio_desc *reset_gpio;
+ bool no_reset_during_suspend;
const struct goodix_i2c_hid_timing_data *timings;
};
@@ -37,6 +38,14 @@ static int goodix_i2c_hid_power_up(struct i2chid_ops *ops)
container_of(ops, struct i2c_hid_of_goodix, ops);
int ret;
+ /*
+ * We assert reset GPIO here (instead of during power-down) to ensure
+ * the device will have a clean state after powering up, just like the
+ * normal scenarios will have.
+ */
+ if (ihid_goodix->no_reset_during_suspend)
+ gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1);
+
ret = regulator_enable(ihid_goodix->vdd);
if (ret)
return ret;
@@ -60,7 +69,9 @@ static void goodix_i2c_hid_power_down(struct i2chid_ops *ops)
struct i2c_hid_of_goodix *ihid_goodix =
container_of(ops, struct i2c_hid_of_goodix, ops);
- gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1);
+ if (!ihid_goodix->no_reset_during_suspend)
+ gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1);
+
regulator_disable(ihid_goodix->vddio);
regulator_disable(ihid_goodix->vdd);
}
@@ -91,6 +102,9 @@ static int i2c_hid_of_goodix_probe(struct i2c_client *client)
if (IS_ERR(ihid_goodix->vddio))
return PTR_ERR(ihid_goodix->vddio);
+ ihid_goodix->no_reset_during_suspend =
+ of_property_read_bool(client->dev.of_node, "goodix,no-reset-during-suspend");
+
ihid_goodix->timings = device_get_match_data(&client->dev);
return i2c_hid_core_probe(client, &ihid_goodix->ops, 0x0001, 0);
--
2.40.1.698.g37aff9b760-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox