* Re: [PATCH] Input: keypad-nomadik-ske - remove the driver
From: Nuno Sá @ 2024-09-06 8:38 UTC (permalink / raw)
To: Dmitry Torokhov, Arnd Bergmann, Michael Hennerich
Cc: Linus Walleij, linux-input, linux-kernel, Lee Jones,
linux-arm-kernel, Utsav Agarwal
In-Reply-To: <ZsNcpom_Fm5uCyEj@google.com>
On Mon, 2024-08-19 at 07:54 -0700, Dmitry Torokhov wrote:
> On Mon, Aug 19, 2024 at 11:29:32AM +0200, Arnd Bergmann wrote:
> > On Fri, Aug 16, 2024, at 20:54, Dmitry Torokhov wrote:
> > > The users of this driver were removed in 2013 in commit 28633c54bda6
> > > ("ARM: ux500: Rip out keypad initialisation which is no longer used").
> > >
> > > Remove the driver as well.
> > >
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > ---
> > > drivers/input/keyboard/Kconfig | 11 -
> > > drivers/input/keyboard/Makefile | 1 -
> > > drivers/input/keyboard/nomadik-ske-keypad.c | 378 ------------------
> > > .../linux/platform_data/keypad-nomadik-ske.h | 50 ---
> > > 4 files changed, 440 deletions(-)
> > >
> >
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> >
> > I have a list of drivers that I determined to be likely
> > unused as well and found a few more input drivers
> > that were unused in 2022:
> >
> > CONFIG_KEYBOARD_ADP5520/CONFIG_PMIC_ADP5520
> > CONFIG_KEYBOARD_ADP5589
> > CONFIG_INPUT_AD714X
> > CONFIG_TOUCHSCREEN_AD7877
> >
> > As far as I can tell, these all lost their last device
> > definition, or they never had one and are impossible to
> > be used with device tree data.
>
> I asked Analog Devices folks (CCed) about 5589 and Nuno said that it is
> still relevant and promised to do conversion to DT similar to adp5588.
>
> Nuno, Michale, what about the other drivers that Arnd listed?
>
Hi Dmitry,
This is not forgotten and I plan to start working on this early next week.
One thing I noticed and I might as well just ask before starting the work, is that
the platform data allows, in theory, for you to have holes in your keymap [1]. Like
enabling row 1 and 3 skipping 2. AFAICT, the matrix stuff does not allow this out of
the box as we just define the number of rows/cols and then without any other property
we assume (I think) that the map is contiguous.
This is just early thinking but one way to support the current behavior would be 2
custom DT properties that would be 2 u32 arrays specifying the enabled columns and
rows. Out of it, we could build row and col masks and get the total number of cols
and rows that we could pass to matrix_keypad_build_keymap().
The question is... is it worth it? I'm aware that if we just assume a contiguous
keymap we could break some old users. But I guess it would be only out of tree ones
as we don't have any in kernel user of the platform data. On top of it, I guess it's
sane to assume that one just wants a contiguous keymap...
[1]: https://elixir.bootlin.com/linux/v6.10.8/source/drivers/input/keyboard/adp5589-keys.c#L630
Thanks!
- Nuno Sá
^ permalink raw reply
* Re: [PATCH v2] HID: lg: constify fixed up report descriptor
From: Benjamin Tissoires @ 2024-09-06 8:07 UTC (permalink / raw)
To: Jiri Kosina, Marcus Folkesson, Thomas Weißschuh
Cc: linux-input, linux-kernel
In-Reply-To: <20240905-hid-const-fixup-2-v2-1-70915e0cc1c7@weissschuh.net>
On Thu, 05 Sep 2024 17:48:38 +0200, Thomas Weißschuh wrote:
> Now that the HID core can handle const report descriptors,
> constify them where possible.
>
>
Applied to hid/hid.git (for-6.12/constify-rdesc), thanks!
[1/1] HID: lg: constify fixed up report descriptor
https://git.kernel.org/hid/hid/c/9f5305ed8010
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH] Input: goodix-berlin - Fix VDDIO regulator name according to dt-bindings
From: neil.armstrong @ 2024-09-06 7:59 UTC (permalink / raw)
To: Dmitry Torokhov, Danila Tikhonov
Cc: hadess, hdegoede, jeff, krzk, linux-input, linux-kernel, linux
In-Reply-To: <ZtqTTZizT7nAaYzq@google.com>
Hi,
On 06/09/2024 07:29, Dmitry Torokhov wrote:
> Hi Danila,
>
> On Mon, Aug 05, 2024 at 06:58:06PM +0300, Danila Tikhonov wrote:
>> The dt-bindings specify the regulator as "vddio" instead of "iovdd".
>>
>> This patch fixes the regulator name from "iovdd" to "vddio" in the
>> driver code to align with the dt-bindings. Fixing the dt-bindings
>> would break ABI, hence the fix is made in the driver instead.
>>
>> There are no users of this regulator сurrently.
>
> If there are no users (and the binding is pretty new) we should consider
> all options. Do you know the name of the supply in the datasheet?
The names comes from the downstream driver & bindings, but we don't
declare them on the Qualcomm platforms using the berlin touch ICs.
Perhaps someone from Goodix or someone with access to datasheet could confirm...
Anyway, this aligns with bindings so it's a correct patch.
Neil
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH] Input: goodix-berlin - Fix VDDIO regulator name according to dt-bindings
From: neil.armstrong @ 2024-09-06 7:57 UTC (permalink / raw)
To: Danila Tikhonov, hadess, hdegoede, dmitry.torokhov, jeff, krzk
Cc: linux-input, linux-kernel, linux
In-Reply-To: <20240805155806.16203-1-danila@jiaxyga.com>
On 05/08/2024 17:58, Danila Tikhonov wrote:
> The dt-bindings specify the regulator as "vddio" instead of "iovdd".
>
> This patch fixes the regulator name from "iovdd" to "vddio" in the
> driver code to align with the dt-bindings. Fixing the dt-bindings
> would break ABI, hence the fix is made in the driver instead.
>
> There are no users of this regulator сurrently.
>
> Fixes: 44362279bdd4 ("Input: add core support for Goodix Berlin Touchscreen IC")
> Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
> ---
> .../input/touchscreen/goodix_berlin_core.c | 26 +++++++++----------
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/input/touchscreen/goodix_berlin_core.c b/drivers/input/touchscreen/goodix_berlin_core.c
> index 0bfca897ce5a..b5d6e6360fff 100644
> --- a/drivers/input/touchscreen/goodix_berlin_core.c
> +++ b/drivers/input/touchscreen/goodix_berlin_core.c
> @@ -165,7 +165,7 @@ struct goodix_berlin_core {
> struct device *dev;
> struct regmap *regmap;
> struct regulator *avdd;
> - struct regulator *iovdd;
> + struct regulator *vddio;
> struct gpio_desc *reset_gpio;
> struct touchscreen_properties props;
> struct goodix_berlin_fw_version fw_version;
> @@ -248,22 +248,22 @@ static int goodix_berlin_power_on(struct goodix_berlin_core *cd)
> {
> int error;
>
> - error = regulator_enable(cd->iovdd);
> + error = regulator_enable(cd->vddio);
> if (error) {
> - dev_err(cd->dev, "Failed to enable iovdd: %d\n", error);
> + dev_err(cd->dev, "Failed to enable vddio: %d\n", error);
> return error;
> }
>
> - /* Vendor waits 3ms for IOVDD to settle */
> + /* Vendor waits 3ms for VDDIO to settle */
> usleep_range(3000, 3100);
>
> error = regulator_enable(cd->avdd);
> if (error) {
> dev_err(cd->dev, "Failed to enable avdd: %d\n", error);
> - goto err_iovdd_disable;
> + goto err_vddio_disable;
> }
>
> - /* Vendor waits 15ms for IOVDD to settle */
> + /* Vendor waits 15ms for VDDIO to settle */
> usleep_range(15000, 15100);
>
> gpiod_set_value_cansleep(cd->reset_gpio, 0);
> @@ -283,8 +283,8 @@ static int goodix_berlin_power_on(struct goodix_berlin_core *cd)
> err_dev_reset:
> gpiod_set_value_cansleep(cd->reset_gpio, 1);
> regulator_disable(cd->avdd);
> -err_iovdd_disable:
> - regulator_disable(cd->iovdd);
> +err_vddio_disable:
> + regulator_disable(cd->vddio);
> return error;
> }
>
> @@ -292,7 +292,7 @@ static void goodix_berlin_power_off(struct goodix_berlin_core *cd)
> {
> gpiod_set_value_cansleep(cd->reset_gpio, 1);
> regulator_disable(cd->avdd);
> - regulator_disable(cd->iovdd);
> + regulator_disable(cd->vddio);
> }
>
> static int goodix_berlin_read_version(struct goodix_berlin_core *cd)
> @@ -744,10 +744,10 @@ int goodix_berlin_probe(struct device *dev, int irq, const struct input_id *id,
> return dev_err_probe(dev, PTR_ERR(cd->avdd),
> "Failed to request avdd regulator\n");
>
> - cd->iovdd = devm_regulator_get(dev, "iovdd");
> - if (IS_ERR(cd->iovdd))
> - return dev_err_probe(dev, PTR_ERR(cd->iovdd),
> - "Failed to request iovdd regulator\n");
> + cd->vddio = devm_regulator_get(dev, "vddio");
> + if (IS_ERR(cd->vddio))
> + return dev_err_probe(dev, PTR_ERR(cd->vddio),
> + "Failed to request vddio regulator\n");
>
> error = goodix_berlin_power_on(cd);
> if (error) {
My bad on this one...
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* Re: [PATCH] Input: alps - use guard notation when acquiring mutex
From: Dmitry Torokhov @ 2024-09-06 5:51 UTC (permalink / raw)
To: Pali Rohár; +Cc: linux-input, Erick Archer, linux-kernel
In-Reply-To: <20240905154414.5cnp5ozwflefp36l@pali>
On Thu, Sep 05, 2024 at 05:44:14PM +0200, Pali Rohár wrote:
> On Thursday 29 August 2024 10:57:41 Dmitry Torokhov wrote:
> > Hi Pali,
> >
> > On Sun, Aug 25, 2024 at 10:13:47PM +0200, Pali Rohár wrote:
> > >
> > > Hello, I'm not familiar with new guards and their usage. But if this is
> > > a preferred way for handling mutexes then go ahead.
> > >
> > > I just looked at the code and I do not see any obvious error neither in
> > > old nor in new version.
> >
> > Is this a Reviewed-by or Acked-by? If neither that is fine too, just
> > want to make sure.
> >
> > Thanks.
> >
> > --
> > Dmitry
>
> Hello, I have looked at it again, and you can add my:
> Acked-by: Pali Rohár <pali@kernel.org>
Thanks Pali.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 00/18] zforse_ts: assorted cleanups
From: Dmitry Torokhov @ 2024-09-06 5:49 UTC (permalink / raw)
To: Andreas Kemnade; +Cc: Heiko Stübner, linux-input, linux-kernel
In-Reply-To: <20240902100805.2148ccea@akair>
On Mon, Sep 02, 2024 at 10:08:05AM +0200, Andreas Kemnade wrote:
> Hi Dmitry,
>
> Am Fri, 23 Aug 2024 22:50:24 -0700
> schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>
> > Hi,
> >
> > This is a set of somewhat random cleanups for the zforce_ts driver.
> >
> > Heiko, Andreas, if you still have access to the hardware it would be
> > great if you could give it a spin.
> >
> > Thanks!
> >
> nice cleanup,
> I tested a bit on the Toline Shine 2HD without gui (have not rebased my
> other stuff to 6.11 yet)
>
> A short move on the touchscreen gives this:
> Event: time 1725264307.093542, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 24
> Event: time 1725264307.093542, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 1159
> Event: time 1725264307.093542, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 596
> Event: time 1725264307.093542, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 11
> Event: time 1725264307.093542, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 11
> Event: time 1725264307.093542, type 3 (EV_ABS), code 52 (ABS_MT_ORIENTATION), value 0
> Event: time 1725264307.093542, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
> Event: time 1725264307.093542, type 3 (EV_ABS), code 0 (ABS_X), value 1159
> Event: time 1725264307.093542, type 3 (EV_ABS), code 1 (ABS_Y), value 596
> Event: time 1725264307.093542, -------------- SYN_REPORT ------------
> Event: time 1725264307.096361, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 1039
> Event: time 1725264307.096361, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 607
> Event: time 1725264307.096361, type 3 (EV_ABS), code 0 (ABS_X), value 1039
> Event: time 1725264307.096361, type 3 (EV_ABS), code 1 (ABS_Y), value 607
> Event: time 1725264307.096361, -------------- SYN_REPORT ------------
> Event: time 1725264307.112426, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 934
> Event: time 1725264307.112426, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 637
> Event: time 1725264307.112426, type 3 (EV_ABS), code 0 (ABS_X), value 934
> Event: time 1725264307.112426, type 3 (EV_ABS), code 1 (ABS_Y), value 637
> Event: time 1725264307.112426, -------------- SYN_REPORT ------------
> Event: time 1725264307.131523, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 859
> Event: time 1725264307.131523, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 661
> Event: time 1725264307.131523, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 12
> Event: time 1725264307.131523, type 3 (EV_ABS), code 0 (ABS_X), value 859
> Event: time 1725264307.131523, type 3 (EV_ABS), code 1 (ABS_Y), value 661
> Event: time 1725264307.131523, -------------- SYN_REPORT ------------
> Event: time 1725264307.150540, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 795
> Event: time 1725264307.150540, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 671
> Event: time 1725264307.150540, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 13
> Event: time 1725264307.150540, type 3 (EV_ABS), code 0 (ABS_X), value 795
> Event: time 1725264307.150540, type 3 (EV_ABS), code 1 (ABS_Y), value 671
> Event: time 1725264307.150540, -------------- SYN_REPORT ------------
> Event: time 1725264307.169589, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 760
> Event: time 1725264307.169589, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 675
> Event: time 1725264307.169589, type 3 (EV_ABS), code 0 (ABS_X), value 760
> Event: time 1725264307.169589, type 3 (EV_ABS), code 1 (ABS_Y), value 675
> Event: time 1725264307.169589, -------------- SYN_REPORT ------------
> Event: time 1725264307.188157, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
> Event: time 1725264307.188157, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
> Event: time 1725264307.188157, -------------- SYN_REPORT ------------
>
> So,
>
> Tested-by: Andreas Kemnade <andreas@kemnade.info> # Tolino Shine2HD
Thank you for giving it a spin!
--
Dmitry
^ permalink raw reply
* [PATCH] treewide: Correct the typo 'retun'
From: WangYuli @ 2024-09-06 5:40 UTC (permalink / raw)
To: aaro.koskinen, andreas, khilman, rogerq, tony, linux, jgg, leon,
wangyuli, gustavoars, mitr, dmitry.torokhov, miquel.raynal,
richard, vigneshr, anil.gurumurthy, sudarsana.kalluru,
James.Bottomley, martin.petersen, obdclark, quic_abhinavk,
dmitry.baryshkov, sean, marijn.suijten, airlied, daniel
Cc: linux-omap, linux-arm-kernel, linux-kernel, linux-rdma,
linux-input, linux-mtd, linux-scsi, linux-arm-msm, dri-devel,
freedreno, abhinavk, architt, chandanu, jsanka, jcrouse, ryadav,
skolluku, seanpaul, robdclark, anil_ravindranath, standby24x7,
jkosina, don.hiatt, ira.weiny, dasaratharaman.chandramouli,
dledford, eric.piel, akpm, dtor, vijaykumar, dwmw2, kgudipat,
James.Bottomley, guanwentao, zhanjun
There are some spelling mistakes of 'retun' in comments which
should be instead of 'return'.
Signed-off-by: WangYuli <wangyuli@uniontech.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 +-
drivers/infiniband/core/sa_query.c | 2 +-
drivers/input/misc/wistron_btns.c | 2 +-
drivers/mtd/nand/raw/nandsim.c | 2 +-
drivers/scsi/bfa/bfa_fcs.c | 2 +-
drivers/scsi/pmcraid.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 7ad74db951f6..f18ef45e2fe1 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -333,7 +333,7 @@ int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
omap_pm_ops.scu_prepare(cpu, power_state);
/*
- * CPU never retuns back if targeted power state is OFF mode.
+ * CPU never returns back if targeted power state is OFF mode.
* CPU ONLINE follows normal CPU ONLINE ptah via
* omap4_secondary_startup().
*/
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index b26d5fe40c72..febc3e764a63 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -231,7 +231,7 @@ struct dpu_crtc_state {
container_of(x, struct dpu_crtc_state, base)
/**
- * dpu_crtc_frame_pending - retun the number of pending frames
+ * dpu_crtc_frame_pending - return the number of pending frames
* @crtc: Pointer to drm crtc object
*/
static inline int dpu_crtc_frame_pending(struct drm_crtc *crtc)
diff --git a/drivers/infiniband/core/sa_query.c b/drivers/infiniband/core/sa_query.c
index 8175dde60b0a..53571e6b3162 100644
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -1420,7 +1420,7 @@ enum opa_pr_supported {
/*
* opa_pr_query_possible - Check if current PR query can be an OPA query.
*
- * Retuns PR_NOT_SUPPORTED if a path record query is not
+ * Returns PR_NOT_SUPPORTED if a path record query is not
* possible, PR_OPA_SUPPORTED if an OPA path record query
* is possible and PR_IB_SUPPORTED if an IB path record
* query is possible.
diff --git a/drivers/input/misc/wistron_btns.c b/drivers/input/misc/wistron_btns.c
index 5c4956678cd0..39d6f642cd19 100644
--- a/drivers/input/misc/wistron_btns.c
+++ b/drivers/input/misc/wistron_btns.c
@@ -1075,7 +1075,7 @@ static void wistron_led_init(struct device *parent)
}
if (leds_present & FE_MAIL_LED) {
- /* bios_get_default_setting(MAIL) always retuns 0, so just turn the led off */
+ /* bios_get_default_setting(MAIL) always returns 0, so just turn the led off */
wistron_mail_led.brightness = LED_OFF;
if (led_classdev_register(parent, &wistron_mail_led))
leds_present &= ~FE_MAIL_LED;
diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c
index 179b28459b4b..df48b7d01d16 100644
--- a/drivers/mtd/nand/raw/nandsim.c
+++ b/drivers/mtd/nand/raw/nandsim.c
@@ -1381,7 +1381,7 @@ static inline union ns_mem *NS_GET_PAGE(struct nandsim *ns)
}
/*
- * Retuns a pointer to the current byte, within the current page.
+ * Returns a pointer to the current byte, within the current page.
*/
static inline u_char *NS_PAGE_BYTE_OFF(struct nandsim *ns)
{
diff --git a/drivers/scsi/bfa/bfa_fcs.c b/drivers/scsi/bfa/bfa_fcs.c
index 5023c0ab4277..e52ce9b01f49 100644
--- a/drivers/scsi/bfa/bfa_fcs.c
+++ b/drivers/scsi/bfa/bfa_fcs.c
@@ -1431,7 +1431,7 @@ bfa_cb_lps_flogo_comp(void *bfad, void *uarg)
* param[in] vf_id - VF_ID
*
* return
- * If lookup succeeds, retuns fcs vf object, otherwise returns NULL
+ * If lookup succeeds, returns fcs vf object, otherwise returns NULL
*/
bfa_fcs_vf_t *
bfa_fcs_vf_lookup(struct bfa_fcs_s *fcs, u16 vf_id)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index a2a084c8075e..72a4c6e3d0c8 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4009,7 +4009,7 @@ static void pmcraid_tasklet_function(unsigned long instance)
* This routine un-registers registered interrupt handler and
* also frees irqs/vectors.
*
- * Retun Value
+ * Return Value
* None
*/
static
--
2.43.4
^ permalink raw reply related
* Re: [PATCH] Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table
From: Dmitry Torokhov @ 2024-09-06 5:34 UTC (permalink / raw)
To: Werner Sembach; +Cc: linux-input, linux-kernel
In-Reply-To: <20240905164851.771578-1-wse@tuxedocomputers.com>
On Thu, Sep 05, 2024 at 06:48:51PM +0200, Werner Sembach wrote:
> Some TongFang barebones have touchpad and/or keyboard issues after
> suspend, fixable with nomux + reset + noloop + nopnp. Luckily, none of
> them have an external PS/2 port so this can safely be set for all of
> them.
>
> I'm not entirely sure if every device listed really needs all four quirks,
> but after testing and production use, no negative effects could be
> observed when setting all four.
>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> Cc: stable@vger.kernel.org
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: tegra: Use of_property_read_variable_u32_array() and of_property_present()
From: Dmitry Torokhov @ 2024-09-06 5:33 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Laxman Dewangan, Jonathan Hunter, linux-input, linux-tegra,
linux-kernel, Thierry Reding
In-Reply-To: <Zs4SovPgLmlrVOJr@google.com>
On Tue, Aug 27, 2024 at 10:53:38AM -0700, Dmitry Torokhov wrote:
> >
> > Applied, thank you.
>
> Oh, wait, can I get your SOB please?
Rob, I am still waiting on your SOB please.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: input: convert rotary-encoder to yaml
From: Dmitry Torokhov @ 2024-09-06 5:30 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, imx
In-Reply-To: <20240811214656.3773098-1-Frank.Li@nxp.com>
On Sun, Aug 11, 2024 at 05:46:55PM -0400, Frank Li wrote:
> Convert binding doc rotary-encoder.txt to yaml format.
>
> Additional change:
> - Only keep one example.
>
> Fix below warning:
> arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dtb: /rotary-encoder:
> failed to match any schema with compatible: ['rotary-encoder']
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: goodix-berlin - Fix VDDIO regulator name according to dt-bindings
From: Dmitry Torokhov @ 2024-09-06 5:29 UTC (permalink / raw)
To: Danila Tikhonov
Cc: hadess, hdegoede, neil.armstrong, jeff, krzk, linux-input,
linux-kernel, linux
In-Reply-To: <20240805155806.16203-1-danila@jiaxyga.com>
Hi Danila,
On Mon, Aug 05, 2024 at 06:58:06PM +0300, Danila Tikhonov wrote:
> The dt-bindings specify the regulator as "vddio" instead of "iovdd".
>
> This patch fixes the regulator name from "iovdd" to "vddio" in the
> driver code to align with the dt-bindings. Fixing the dt-bindings
> would break ABI, hence the fix is made in the driver instead.
>
> There are no users of this regulator сurrently.
If there are no users (and the binding is pretty new) we should consider
all options. Do you know the name of the supply in the datasheet?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/5] Remove support for platform data from matrix keypad driver
From: Dmitry Torokhov @ 2024-09-06 5:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Haojian Zhuang, Daniel Mack, Robert Jarzmik, soc,
linux-arm-kernel, linux-kernel, linux-input
In-Reply-To: <513f718b-b964-4af1-9c51-9e0ba3809225@app.fastmail.com>
On Thu, Sep 05, 2024 at 02:36:15PM +0000, Arnd Bergmann wrote:
> On Mon, Aug 26, 2024, at 08:52, Linus Walleij wrote:
> > On Fri, Aug 23, 2024 at 6:02 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> >
> >> I'm glad that we agree that we do not want the elaborate merge process
> >> and instead push the changes through one tree in one shot we just need
> >> to decide which one - soc or input. I am fine with using either.
> >
> > I'm also fine with either, but let's take the input tree because the
> > you're in direct control of it so it will be easier.
>
> Sorry I dropped the ball here, I just saw that these five patches
> are still in the patchwork waiting for me to apply them.
>
> I'm also happy for them to go through the input tree, and have
> marked them as not-for-us in patchwork now. Dmitry, please add
> my
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> and pick them up in your tree. I've checked that there are no
> conflicts against contents of the SoC tree. If you prefer me to
> pick them up after all, that is also fine, but please resend in
> that case.
I made an immutable branch off of 6.11-rc6 with the changesi and merged
it into my 'next' branch for the upcoming merge window. Please feel free
to also pull it - it does not have any unrelated changes:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git ib/6.11-rc6-matrix-keypad-spitz
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH -next 15/19] hwmon: (corsair-psu) Use devm_hid_hw_start_and_open in corsairpsu_probe()
From: Wilken Gottwalt @ 2024-09-06 4:03 UTC (permalink / raw)
To: Li Zetao
Cc: jikos, bentiss, michael.zaidman, gupt21, djogorchock, rrameshbabu,
bonbons, roderick.colenbrander, david, savicaleksa83, me,
jdelvare, linux, mail, jonas, mezin.alexander, linux-input,
linux-i2c, linux-hwmon
In-Reply-To: <20240904123607.3407364-16-lizetao1@huawei.com>
On Wed, 4 Sep 2024 20:36:03 +0800
Li Zetao <lizetao1@huawei.com> wrote:
> Currently, the corsair-psu module needs to maintain hid resources
> by itself. Consider using devm_hid_hw_start_and_open helper to ensure
> that hid resources are consistent with the device life cycle, and release
> hid resources before device is released. At the same time, it can avoid
> the goto-release encoding, drop the fail_and_close and fail_and_stop
> lables, and directly return the error code when an error occurs.
>
> Signed-off-by: Li Zetao <lizetao1@huawei.com>
> ---
> drivers/hwmon/corsair-psu.c | 24 +++++-------------------
> 1 file changed, 5 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/hwmon/corsair-psu.c b/drivers/hwmon/corsair-psu.c
> index f8f22b8a67cd..b574ec9cd00f 100644
> --- a/drivers/hwmon/corsair-psu.c
> +++ b/drivers/hwmon/corsair-psu.c
> @@ -787,14 +787,10 @@ static int corsairpsu_probe(struct hid_device *hdev, const struct
> hid_device_id if (ret)
> return ret;
>
> - ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
> + ret = devm_hid_hw_start_and_open(hdev, HID_CONNECT_HIDRAW);
> if (ret)
> return ret;
>
> - ret = hid_hw_open(hdev);
> - if (ret)
> - goto fail_and_stop;
> -
> priv->hdev = hdev;
> hid_set_drvdata(hdev, priv);
> mutex_init(&priv->lock);
> @@ -805,13 +801,13 @@ static int corsairpsu_probe(struct hid_device *hdev, const struct
> hid_device_id ret = corsairpsu_init(priv);
> if (ret < 0) {
> dev_err(&hdev->dev, "unable to initialize device (%d)\n", ret);
> - goto fail_and_stop;
> + return ret;
> }
>
> ret = corsairpsu_fwinfo(priv);
> if (ret < 0) {
> dev_err(&hdev->dev, "unable to query firmware (%d)\n", ret);
> - goto fail_and_stop;
> + return ret;
> }
>
> corsairpsu_get_criticals(priv);
> @@ -820,20 +816,12 @@ static int corsairpsu_probe(struct hid_device *hdev, const struct
> hid_device_id priv->hwmon_dev = hwmon_device_register_with_info(&hdev->dev, "corsairpsu", priv,
> &corsairpsu_chip_info, NULL);
>
> - if (IS_ERR(priv->hwmon_dev)) {
> - ret = PTR_ERR(priv->hwmon_dev);
> - goto fail_and_close;
> - }
> + if (IS_ERR(priv->hwmon_dev))
> + return PTR_ERR(priv->hwmon_dev);
>
> corsairpsu_debugfs_init(priv);
>
> return 0;
> -
> -fail_and_close:
> - hid_hw_close(hdev);
> -fail_and_stop:
> - hid_hw_stop(hdev);
> - return ret;
> }
>
> static void corsairpsu_remove(struct hid_device *hdev)
> @@ -842,8 +830,6 @@ static void corsairpsu_remove(struct hid_device *hdev)
>
> debugfs_remove_recursive(priv->debugfs);
> hwmon_device_unregister(priv->hwmon_dev);
> - hid_hw_close(hdev);
> - hid_hw_stop(hdev);
> }
>
> static int corsairpsu_raw_event(struct hid_device *hdev, struct hid_report *report, u8 *data,
So far looks fine to me.
Reviewed-by: Wilken Gottwalt <wilken.gottwalt@posteo.net>
greetings,
Wilken
^ permalink raw reply
* Re: [RFC PATCH] HID: wacom: Stop mangling tool IDs
From: Peter Hutterer @ 2024-09-05 23:33 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Gerecke, Jason, linux-input, Benjamin Tissoires,
Dmitry Torokhov, Ping Cheng, Tobita, Tatsunosuke, Erin Skomra,
Joshua Dickens, Jason Gerecke
In-Reply-To: <73s746uhpe7d6dazdve43s7s63t46dr5a2dtwh5json6wywrdi@soh7iqmzgtuj>
On Thu, Sep 05, 2024 at 11:01:58AM +0200, Benjamin Tissoires wrote:
> On Sep 05 2024, Jiri Kosina wrote:
> > On Tue, 3 Sep 2024, Gerecke, Jason wrote:
> >
> > > From: Jason Gerecke <jason.gerecke@wacom.com>
> > >
> > > In ancient times, an off-by-one-nybble error resulted in the Wacom
> > > driver sending "mangled" tool IDs to userspace. This mangling behavior
> > > was later enshrined into a function so that devices using the then-new
> > > generic codepath could share the same broken behavior. The mangled IDs
> > > have not historically been a major problem for userspace since few
> > > applications care about the exact numeric value of the IDs. As long as
> > > the IDs were unique it didn't much matter. Some programs (cross-
> > > platform and remote-desktop applications in particular) /do/ rely on
> > > the IDs being correct, however.
> > >
> > > This patch rids the driver of the mangling behavior.
> > >
> > > Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
> > > References: 493630b20389 ("Input: wacom - fix serial number handling on Cintiq 21UX2")
> > > References: 82527da319ee ("HID: wacom: Read and internally use corrected Intuos tool IDs")
> > > ---
> > > I'd like to get the opinion of the kernel maintainers on making a
> > > change like this at some point in the future. There are _very_ few
> > > userspace uses of these IDs (primarily: drivers, compositors, and
> > > tablet control panels) and my plan is to update those bits and then
> > > give some time for the changes to roll out to users before re-
> > > submitting this for real. I don't expect any kind of breakage since
> > > we'll be taking our time with the rollout and userspace needs to
> > > have handling for "unknown" IDs anyway (since Wacom periodically
> > > releases new pens).
> >
> > As you are in control of the whole ecosystem anyway (because it's Wacom
> > specific), I don't see it as particularly problematic.
> >
>
> Yeah, same here. And that change doesn't impact the basic functionality
> of the styluses: they'll still be handled properly as pointers, but only
> the configuration panel IIUC. Peter mentioned about some slight
> differences in libinput which shouldn't impact the users as well IIRC.
Assuming libwacom is updated (and used) before this happens in the
kernel, then there won't be a difference in libinput behaviour at all.
And that's the plan for this anyway, have libwacom updated well before
the kernel update ships.
Otherwise, the only difference in libinput will be that it is treated as
an unknown stylus. Those default to capabilities matching the kernel
evdev codes (i.e. "everything") whereas a known stylus will only
initialize capabilities that the stylus actually has. IOW you may get a
libinput_tablet_tool that e.g. claims to support rotation and has a
wheel when it doesn't. Not the end of the world either.
Cheers,
Peter
^ permalink raw reply
* [PATCH v7 3/8] mfd: add base driver for qnap-mcu devices
From: Heiko Stuebner @ 2024-09-05 18:52 UTC (permalink / raw)
To: lee
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, heiko, dmitry.torokhov,
pavel, ukleinek, devicetree, linux-kernel, linux-hwmon,
linux-arm-kernel, linux-rockchip, linux-input, linux-leds
In-Reply-To: <20240905185232.2899464-1-heiko@sntech.de>
These microcontroller units are used in network-attached-storage devices
made by QNAP and provide additional functionality to the system.
This adds the base driver that implements the serial protocol via
serdev and additionally hooks into the poweroff handlers to turn
off the parts of the system not supplied by the general PMIC.
Turning off (at least the TSx33 devices using Rockchip SoCs) consists of
two separate actions. Turning off the MCU alone does not turn off the main
SoC and turning off only the SoC/PMIC does not turn off the hard-drives.
Also if the MCU is not turned off, the system also won't start again until
it is unplugged from power.
So on shutdown the MCU needs to be turned off separately before the
main PMIC.
The protocol spoken by the MCU is sadly not documented, but was
obtained by listening to the chatter on the serial port, as thankfully
the "hal_app" program from QNAPs firmware allows triggering all/most
MCU actions from the command line.
The implementation of how to talk to the serial device got some
inspiration from the rave-sp servdev driver.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
MAINTAINERS | 6 +
drivers/mfd/Kconfig | 13 ++
drivers/mfd/Makefile | 2 +
drivers/mfd/qnap-mcu.c | 332 +++++++++++++++++++++++++++++++++++
include/linux/mfd/qnap-mcu.h | 26 +++
5 files changed, 379 insertions(+)
create mode 100644 drivers/mfd/qnap-mcu.c
create mode 100644 include/linux/mfd/qnap-mcu.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7889addb8949..ee6e98ba2e6f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18679,6 +18679,12 @@ L: linux-media@vger.kernel.org
S: Odd Fixes
F: drivers/media/tuners/qm1d1c0042*
+QNAP MCU DRIVER
+M: Heiko Stuebner <heiko@sntech.de>
+S: Maintained
+F: drivers/mfd/qnap-mcu.c
+F: include/linux/qnap-mcu.h
+
QNX4 FILESYSTEM
M: Anders Larsen <al@alarsen.net>
S: Maintained
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index bc8be2e593b6..63d51cc45891 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2362,6 +2362,19 @@ config MFD_INTEL_M10_BMC_PMCI
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_QNAP_MCU
+ tristate "QNAP microcontroller unit core driver"
+ depends on SERIAL_DEV_BUS
+ select MFD_CORE
+ help
+ Select this to get support for the QNAP MCU device found in
+ several devices of QNAP network attached storage products that
+ implements additional functionality for the device, like fan
+ and LED control.
+
+ This driver implements the base serial protocol to talk to the
+ device and provides functions for the other parts to hook into.
+
config MFD_RSMU_I2C
tristate "Renesas Synchronization Management Unit with I2C"
depends on I2C && OF
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 02b651cd7535..fc8b825725ff 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -286,5 +286,7 @@ obj-$(CONFIG_MFD_INTEL_M10_BMC_PMCI) += intel-m10-bmc-pmci.o
obj-$(CONFIG_MFD_ATC260X) += atc260x-core.o
obj-$(CONFIG_MFD_ATC260X_I2C) += atc260x-i2c.o
+obj-$(CONFIG_MFD_QNAP_MCU) += qnap-mcu.o
+
obj-$(CONFIG_MFD_RSMU_I2C) += rsmu_i2c.o rsmu_core.o
obj-$(CONFIG_MFD_RSMU_SPI) += rsmu_spi.o rsmu_core.o
diff --git a/drivers/mfd/qnap-mcu.c b/drivers/mfd/qnap-mcu.c
new file mode 100644
index 000000000000..2a52ac01f5fc
--- /dev/null
+++ b/drivers/mfd/qnap-mcu.c
@@ -0,0 +1,332 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Core driver for the microcontroller unit in QNAP NAS devices that is
+ * connected via a dedicated UART port.
+ *
+ * Copyright (C) 2024 Heiko Stuebner <heiko@sntech.de>
+ */
+
+#include <linux/cleanup.h>
+#include <linux/export.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/qnap-mcu.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/reboot.h>
+#include <linux/serdev.h>
+#include <linux/slab.h>
+
+/* The longest command found so far is 5 bytes long */
+#define QNAP_MCU_MAX_CMD_SIZE 5
+#define QNAP_MCU_MAX_DATA_SIZE 36
+#define QNAP_MCU_CHECKSUM_SIZE 1
+
+#define QNAP_MCU_RX_BUFFER_SIZE \
+ (QNAP_MCU_MAX_DATA_SIZE + QNAP_MCU_CHECKSUM_SIZE)
+
+#define QNAP_MCU_TX_BUFFER_SIZE \
+ (QNAP_MCU_MAX_CMD_SIZE + QNAP_MCU_CHECKSUM_SIZE)
+
+#define QNAP_MCU_ACK_LEN 2
+#define QNAP_MCU_VERSION_LEN 4
+
+/**
+ * struct qnap_mcu_reply - Reply to a command
+ *
+ * @data: Buffer to store reply payload in
+ * @length: Expected reply length, including the checksum
+ * @received: Received number of bytes, so far
+ * @done: Triggered when the entire reply has been received
+ */
+struct qnap_mcu_reply {
+ u8 *data;
+ size_t length;
+ size_t received;
+ struct completion done;
+};
+
+/**
+ * struct qnap_mcu - QNAP NAS embedded controller
+ *
+ * @serdev: Pointer to underlying serdev
+ * @bus_lock: Lock to serialize access to the device
+ * @reply: Reply data structure
+ * @variant: Device variant specific information
+ * @version: MCU firmware version
+ */
+struct qnap_mcu {
+ struct serdev_device *serdev;
+ struct mutex bus_lock;
+ struct qnap_mcu_reply reply;
+ const struct qnap_mcu_variant *variant;
+ u8 version[QNAP_MCU_VERSION_LEN];
+};
+
+/*
+ * The QNAP-MCU uses a basic XOR checksum.
+ * It is always the last byte and XORs the whole previous message.
+ */
+static u8 qnap_mcu_csum(const u8 *buf, size_t size)
+{
+ u8 csum = 0;
+
+ while (size--)
+ csum ^= *buf++;
+
+ return csum;
+}
+
+static int qnap_mcu_write(struct qnap_mcu *mcu, const u8 *data, u8 data_size)
+{
+ unsigned char tx[QNAP_MCU_TX_BUFFER_SIZE];
+ size_t length = data_size + QNAP_MCU_CHECKSUM_SIZE;
+
+ if (length > sizeof(tx)) {
+ dev_err(&mcu->serdev->dev, "data too big for transmit buffer");
+ return -EINVAL;
+ }
+
+ memcpy(tx, data, data_size);
+ tx[data_size] = qnap_mcu_csum(data, data_size);
+
+ return serdev_device_write(mcu->serdev, tx, length, HZ);
+}
+
+static size_t qnap_mcu_receive_buf(struct serdev_device *serdev, const u8 *buf, size_t size)
+{
+ struct device *dev = &serdev->dev;
+ struct qnap_mcu *mcu = dev_get_drvdata(dev);
+ struct qnap_mcu_reply *reply = &mcu->reply;
+ const u8 *src = buf;
+ const u8 *end = buf + size;
+
+ if (!reply->length) {
+ dev_warn(dev, "Received %zu bytes, we were not waiting for\n", size);
+ return size;
+ }
+
+ while (src < end) {
+ reply->data[reply->received] = *src++;
+ reply->received++;
+
+ if (reply->received == reply->length) {
+ complete(&reply->done);
+
+ /*
+ * We report the consumed number of bytes. If there
+ * are still bytes remaining (though there shouldn't)
+ * the serdev layer will re-execute this handler with
+ * the remainder of the Rx bytes.
+ */
+ return src - buf;
+ }
+ }
+
+ /*
+ * The only way to get out of the above loop and end up here
+ * is through consuming all of the supplied data, so here we
+ * report that we processed it all.
+ */
+ return size;
+}
+
+static const struct serdev_device_ops qnap_mcu_serdev_device_ops = {
+ .receive_buf = qnap_mcu_receive_buf,
+ .write_wakeup = serdev_device_write_wakeup,
+};
+
+int qnap_mcu_exec(struct qnap_mcu *mcu,
+ const u8 *cmd_data, size_t cmd_data_size,
+ u8 *reply_data, size_t reply_data_size)
+{
+ unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE];
+ size_t length = reply_data_size + QNAP_MCU_CHECKSUM_SIZE;
+ struct qnap_mcu_reply *reply = &mcu->reply;
+ int ret = 0;
+
+ if (length > sizeof(rx)) {
+ dev_err(&mcu->serdev->dev, "expected data too big for receive buffer");
+ return -EINVAL;
+ }
+
+ mutex_lock(&mcu->bus_lock);
+
+ reply->data = rx,
+ reply->length = length,
+ reply->received = 0,
+ reinit_completion(&reply->done);
+
+ qnap_mcu_write(mcu, cmd_data, cmd_data_size);
+
+ if (!wait_for_completion_timeout(&reply->done, msecs_to_jiffies(500))) {
+ dev_err(&mcu->serdev->dev, "Command timeout\n");
+ ret = -ETIMEDOUT;
+ } else {
+ u8 crc = qnap_mcu_csum(rx, reply_data_size);
+
+ if (crc != rx[reply_data_size]) {
+ dev_err(&mcu->serdev->dev,
+ "Invalid Checksum received\n");
+ ret = -EIO;
+ } else {
+ memcpy(reply_data, rx, reply_data_size);
+ }
+ }
+
+ /* We don't expect any characters from the device now */
+ reply->length = 0;
+
+ mutex_unlock(&mcu->bus_lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(qnap_mcu_exec);
+
+int qnap_mcu_exec_with_ack(struct qnap_mcu *mcu,
+ const u8 *cmd_data, size_t cmd_data_size)
+{
+ u8 ack[QNAP_MCU_ACK_LEN];
+ int ret;
+
+ ret = qnap_mcu_exec(mcu, cmd_data, cmd_data_size, ack, sizeof(ack));
+ if (ret)
+ return ret;
+
+ /* Should return @0 */
+ if (ack[0] != 0x40 || ack[1] != 0x30) {
+ dev_err(&mcu->serdev->dev, "Did not receive ack\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(qnap_mcu_exec_with_ack);
+
+static int qnap_mcu_get_version(struct qnap_mcu *mcu)
+{
+ const u8 cmd[] = { '%', 'V' };
+ u8 rx[14];
+ int ret;
+
+ /* Reply is the 2 command-bytes + 4 bytes describing the version */
+ ret = qnap_mcu_exec(mcu, cmd, sizeof(cmd), rx, QNAP_MCU_VERSION_LEN + 2);
+ if (ret)
+ return ret;
+
+ memcpy(mcu->version, &rx[2], QNAP_MCU_VERSION_LEN);
+
+ return 0;
+}
+
+/*
+ * The MCU controls power to the peripherals but not the CPU.
+ *
+ * So using the PMIC to power off the system keeps the MCU and hard-drives
+ * running. This also then prevents the system from turning back on until
+ * the MCU is turned off by unplugging the power cable.
+ * Turning off the MCU alone on the other hand turns off the hard drives,
+ * LEDs, etc while the main SoC stays running - including its network ports.
+ */
+static int qnap_mcu_power_off(struct sys_off_data *data)
+{
+ const u8 cmd[] = { '@', 'C', '0' };
+ struct qnap_mcu *mcu = data->cb_data;
+ int ret;
+
+ ret = qnap_mcu_exec_with_ack(mcu, cmd, sizeof(cmd));
+ if (ret) {
+ dev_err(&mcu->serdev->dev, "MCU poweroff failed %d\n", ret);
+ return NOTIFY_STOP;
+ }
+
+ return NOTIFY_DONE;
+}
+
+static const struct qnap_mcu_variant qnap_ts433_mcu = {
+ .baud_rate = 115200,
+ .num_drives = 4,
+ .fan_pwm_min = 51, /* Specified in original model.conf */
+ .fan_pwm_max = 255,
+ .usb_led = true,
+};
+
+static struct mfd_cell qnap_mcu_cells[] = {
+ { .name = "qnap-mcu-input", },
+ { .name = "qnap-mcu-leds", },
+ { .name = "qnap-mcu-hwmon", }
+};
+
+static int qnap_mcu_probe(struct serdev_device *serdev)
+{
+ struct device *dev = &serdev->dev;
+ struct qnap_mcu *mcu;
+ int ret;
+
+ mcu = devm_kzalloc(dev, sizeof(*mcu), GFP_KERNEL);
+ if (!mcu)
+ return -ENOMEM;
+
+ mcu->serdev = serdev;
+ dev_set_drvdata(dev, mcu);
+
+ mcu->variant = of_device_get_match_data(dev);
+ if (!mcu->variant)
+ return -ENODEV;
+
+ mutex_init(&mcu->bus_lock);
+ init_completion(&mcu->reply.done);
+
+ serdev_device_set_client_ops(serdev, &qnap_mcu_serdev_device_ops);
+ ret = devm_serdev_device_open(dev, serdev);
+ if (ret)
+ return ret;
+
+ serdev_device_set_baudrate(serdev, mcu->variant->baud_rate);
+ serdev_device_set_flow_control(serdev, false);
+
+ ret = serdev_device_set_parity(serdev, SERDEV_PARITY_NONE);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to set parity\n");
+
+ ret = qnap_mcu_get_version(mcu);
+ if (ret)
+ return ret;
+
+ ret = devm_register_sys_off_handler(dev,
+ SYS_OFF_MODE_POWER_OFF_PREPARE,
+ SYS_OFF_PRIO_DEFAULT,
+ &qnap_mcu_power_off, mcu);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to register poweroff handler\n");
+
+ for (int i = 0; i < ARRAY_SIZE(qnap_mcu_cells); i++) {
+ qnap_mcu_cells[i].platform_data = mcu->variant;
+ qnap_mcu_cells[i].pdata_size = sizeof(*mcu->variant);
+ }
+
+ ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, qnap_mcu_cells,
+ ARRAY_SIZE(qnap_mcu_cells), NULL, 0, NULL);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to add child devices\n");
+
+ return 0;
+}
+
+static const struct of_device_id qnap_mcu_dt_ids[] = {
+ { .compatible = "qnap,ts433-mcu", .data = &qnap_ts433_mcu },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, qnap_mcu_dt_ids);
+
+static struct serdev_device_driver qnap_mcu_drv = {
+ .probe = qnap_mcu_probe,
+ .driver = {
+ .name = "qnap-mcu",
+ .of_match_table = qnap_mcu_dt_ids,
+ },
+};
+module_serdev_device_driver(qnap_mcu_drv);
+
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_DESCRIPTION("QNAP MCU core driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/qnap-mcu.h b/include/linux/mfd/qnap-mcu.h
new file mode 100644
index 000000000000..8d48c212fd44
--- /dev/null
+++ b/include/linux/mfd/qnap-mcu.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Core definitions for QNAP MCU MFD driver.
+ * Copyright (C) 2024 Heiko Stuebner <heiko@sntech.de>
+ */
+
+#ifndef _LINUX_QNAP_MCU_H_
+#define _LINUX_QNAP_MCU_H_
+
+struct qnap_mcu;
+
+struct qnap_mcu_variant {
+ u32 baud_rate;
+ int num_drives;
+ int fan_pwm_min;
+ int fan_pwm_max;
+ bool usb_led;
+};
+
+int qnap_mcu_exec(struct qnap_mcu *mcu,
+ const u8 *cmd_data, size_t cmd_data_size,
+ u8 *reply_data, size_t reply_data_size);
+int qnap_mcu_exec_with_ack(struct qnap_mcu *mcu,
+ const u8 *cmd_data, size_t cmd_data_size);
+
+#endif /* _LINUX_QNAP_MCU_H_ */
--
2.43.0
^ permalink raw reply related
* [PATCH v7 4/8] leds: add driver for LEDs from qnap-mcu devices
From: Heiko Stuebner @ 2024-09-05 18:52 UTC (permalink / raw)
To: lee
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, heiko, dmitry.torokhov,
pavel, ukleinek, devicetree, linux-kernel, linux-hwmon,
linux-arm-kernel, linux-rockchip, linux-input, linux-leds
In-Reply-To: <20240905185232.2899464-1-heiko@sntech.de>
This adds a driver that connects to the qnap-mcu mfd driver and provides
access to the LEDs on it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
MAINTAINERS | 1 +
drivers/leds/Kconfig | 11 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-qnap-mcu.c | 227 +++++++++++++++++++++++++++++++++++
4 files changed, 240 insertions(+)
create mode 100644 drivers/leds/leds-qnap-mcu.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ee6e98ba2e6f..943905cbcf62 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18682,6 +18682,7 @@ F: drivers/media/tuners/qm1d1c0042*
QNAP MCU DRIVER
M: Heiko Stuebner <heiko@sntech.de>
S: Maintained
+F: drivers/leds/leds-qnap-mcu.c
F: drivers/mfd/qnap-mcu.c
F: include/linux/qnap-mcu.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 8d9d8da376e4..9a337478dd80 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -580,6 +580,17 @@ config LEDS_PCA995X
LED driver chips accessed via the I2C bus. Supported
devices include PCA9955BTW, PCA9952TW and PCA9955TW.
+config LEDS_QNAP_MCU
+ tristate "LED Support for QNAP MCU controllers"
+ depends on LEDS_CLASS
+ depends on MFD_QNAP_MCU
+ help
+ This option enables support for LEDs available on embedded
+ controllers used in QNAP NAS devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called qnap-mcu-leds.
+
config LEDS_WM831X_STATUS
tristate "LED support for status LEDs on WM831x PMICs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 18afbb5a23ee..c6f74865d729 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_LEDS_PCA995X) += leds-pca995x.o
obj-$(CONFIG_LEDS_PM8058) += leds-pm8058.o
obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
obj-$(CONFIG_LEDS_PWM) += leds-pwm.o
+obj-$(CONFIG_LEDS_QNAP_MCU) += leds-qnap-mcu.o
obj-$(CONFIG_LEDS_REGULATOR) += leds-regulator.o
obj-$(CONFIG_LEDS_SC27XX_BLTC) += leds-sc27xx-bltc.o
obj-$(CONFIG_LEDS_SUN50I_A100) += leds-sun50i-a100.o
diff --git a/drivers/leds/leds-qnap-mcu.c b/drivers/leds/leds-qnap-mcu.c
new file mode 100644
index 000000000000..4e4709456261
--- /dev/null
+++ b/drivers/leds/leds-qnap-mcu.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for LEDs found on QNAP MCU devices
+ *
+ * Copyright (C) 2024 Heiko Stuebner <heiko@sntech.de>
+ */
+
+#include <linux/leds.h>
+#include <linux/mfd/qnap-mcu.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <uapi/linux/uleds.h>
+
+enum qnap_mcu_err_led_mode {
+ QNAP_MCU_ERR_LED_ON = 0,
+ QNAP_MCU_ERR_LED_OFF = 1,
+ QNAP_MCU_ERR_LED_BLINK_FAST = 2,
+ QNAP_MCU_ERR_LED_BLINK_SLOW = 3,
+};
+
+struct qnap_mcu_err_led {
+ struct qnap_mcu *mcu;
+ struct led_classdev cdev;
+ char name[LED_MAX_NAME_SIZE];
+ u8 num;
+ u8 mode;
+};
+
+static inline struct qnap_mcu_err_led *
+ cdev_to_qnap_mcu_err_led(struct led_classdev *led_cdev)
+{
+ return container_of(led_cdev, struct qnap_mcu_err_led, cdev);
+}
+
+static int qnap_mcu_err_led_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct qnap_mcu_err_led *err_led = cdev_to_qnap_mcu_err_led(led_cdev);
+ u8 cmd[] = { '@', 'R', '0' + err_led->num, '0' };
+
+ /* Don't disturb a possible set blink-mode if LED stays on */
+ if (brightness != 0 && err_led->mode >= QNAP_MCU_ERR_LED_BLINK_FAST)
+ return 0;
+
+ err_led->mode = brightness ? QNAP_MCU_ERR_LED_ON : QNAP_MCU_ERR_LED_OFF;
+ cmd[3] = '0' + err_led->mode;
+
+ return qnap_mcu_exec_with_ack(err_led->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_err_led_blink_set(struct led_classdev *led_cdev,
+ unsigned long *delay_on,
+ unsigned long *delay_off)
+{
+ struct qnap_mcu_err_led *err_led = cdev_to_qnap_mcu_err_led(led_cdev);
+ u8 cmd[] = { '@', 'R', '0' + err_led->num, '0' };
+
+ /* LED is off, nothing to do */
+ if (err_led->mode == QNAP_MCU_ERR_LED_OFF)
+ return 0;
+
+ if (*delay_on < 500) {
+ *delay_on = 100;
+ *delay_off = 100;
+ err_led->mode = QNAP_MCU_ERR_LED_BLINK_FAST;
+ } else {
+ *delay_on = 500;
+ *delay_off = 500;
+ err_led->mode = QNAP_MCU_ERR_LED_BLINK_SLOW;
+ }
+
+ cmd[3] = '0' + err_led->mode;
+
+ return qnap_mcu_exec_with_ack(err_led->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_register_err_led(struct device *dev, struct qnap_mcu *mcu, int num_err_led)
+{
+ struct qnap_mcu_err_led *err_led;
+ int ret;
+
+ err_led = devm_kzalloc(dev, sizeof(*err_led), GFP_KERNEL);
+ if (!err_led)
+ return -ENOMEM;
+
+ err_led->mcu = mcu;
+ err_led->num = num_err_led;
+ err_led->mode = QNAP_MCU_ERR_LED_OFF;
+
+ scnprintf(err_led->name, LED_MAX_NAME_SIZE, "hdd%d:red:status", num_err_led + 1);
+ err_led->cdev.name = err_led->name;
+
+ err_led->cdev.brightness_set_blocking = qnap_mcu_err_led_set;
+ err_led->cdev.blink_set = qnap_mcu_err_led_blink_set;
+ err_led->cdev.brightness = 0;
+ err_led->cdev.max_brightness = 1;
+
+ ret = devm_led_classdev_register(dev, &err_led->cdev);
+ if (ret)
+ return ret;
+
+ return qnap_mcu_err_led_set(&err_led->cdev, 0);
+}
+
+enum qnap_mcu_usb_led_mode {
+ QNAP_MCU_USB_LED_ON = 1,
+ QNAP_MCU_USB_LED_OFF = 3,
+ QNAP_MCU_USB_LED_BLINK = 2,
+};
+
+struct qnap_mcu_usb_led {
+ struct qnap_mcu *mcu;
+ struct led_classdev cdev;
+ u8 mode;
+};
+
+static inline struct qnap_mcu_usb_led *
+ cdev_to_qnap_mcu_usb_led(struct led_classdev *led_cdev)
+{
+ return container_of(led_cdev, struct qnap_mcu_usb_led, cdev);
+}
+
+static int qnap_mcu_usb_led_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct qnap_mcu_usb_led *usb_led = cdev_to_qnap_mcu_usb_led(led_cdev);
+ u8 cmd[] = { '@', 'C', 0 };
+
+ /* Don't disturb a possible set blink-mode if LED stays on */
+ if (brightness != 0 && usb_led->mode == QNAP_MCU_USB_LED_BLINK)
+ return 0;
+
+ usb_led->mode = brightness ? QNAP_MCU_USB_LED_ON : QNAP_MCU_USB_LED_OFF;
+
+ /*
+ * Byte 3 is shared between the usb led target on/off/blink
+ * and also the buzzer control (in the input driver)
+ */
+ cmd[2] = 'D' + usb_led->mode;
+
+ return qnap_mcu_exec_with_ack(usb_led->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_usb_led_blink_set(struct led_classdev *led_cdev,
+ unsigned long *delay_on,
+ unsigned long *delay_off)
+{
+ struct qnap_mcu_usb_led *usb_led = cdev_to_qnap_mcu_usb_led(led_cdev);
+ u8 cmd[] = { '@', 'C', 0 };
+
+ /* LED is off, nothing to do */
+ if (usb_led->mode == QNAP_MCU_USB_LED_OFF)
+ return 0;
+
+ *delay_on = 250;
+ *delay_off = 250;
+ usb_led->mode = QNAP_MCU_USB_LED_BLINK;
+
+ /*
+ * Byte 3 is shared between the USB LED target on/off/blink
+ * and also the buzzer control (in the input driver)
+ */
+ cmd[2] = 'D' + usb_led->mode;
+
+ return qnap_mcu_exec_with_ack(usb_led->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_register_usb_led(struct device *dev, struct qnap_mcu *mcu)
+{
+ struct qnap_mcu_usb_led *usb_led;
+ int ret;
+
+ usb_led = devm_kzalloc(dev, sizeof(*usb_led), GFP_KERNEL);
+ if (!usb_led)
+ return -ENOMEM;
+
+ usb_led->mcu = mcu;
+ usb_led->mode = QNAP_MCU_USB_LED_OFF;
+ usb_led->cdev.name = "usb:blue:disk";
+ usb_led->cdev.brightness_set_blocking = qnap_mcu_usb_led_set;
+ usb_led->cdev.blink_set = qnap_mcu_usb_led_blink_set;
+ usb_led->cdev.brightness = 0;
+ usb_led->cdev.max_brightness = 1;
+
+ ret = devm_led_classdev_register(dev, &usb_led->cdev);
+ if (ret)
+ return ret;
+
+ return qnap_mcu_usb_led_set(&usb_led->cdev, 0);
+}
+
+static int qnap_mcu_leds_probe(struct platform_device *pdev)
+{
+ struct qnap_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
+ const struct qnap_mcu_variant *variant = pdev->dev.platform_data;
+ int ret;
+
+ for (int i = 0; i < variant->num_drives; i++) {
+ ret = qnap_mcu_register_err_led(&pdev->dev, mcu, i);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "failed to register error LED %d\n", i);
+ }
+
+ if (variant->usb_led) {
+ ret = qnap_mcu_register_usb_led(&pdev->dev, mcu);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "failed to register USB LED\n");
+ }
+
+ return 0;
+}
+
+static struct platform_driver qnap_mcu_leds_driver = {
+ .probe = qnap_mcu_leds_probe,
+ .driver = {
+ .name = "qnap-mcu-leds",
+ },
+};
+module_platform_driver(qnap_mcu_leds_driver);
+
+MODULE_ALIAS("platform:qnap-mcu-leds");
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_DESCRIPTION("QNAP MCU LEDs driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v7 5/8] Input: add driver for the input part of qnap-mcu devices
From: Heiko Stuebner @ 2024-09-05 18:52 UTC (permalink / raw)
To: lee
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, heiko, dmitry.torokhov,
pavel, ukleinek, devicetree, linux-kernel, linux-hwmon,
linux-arm-kernel, linux-rockchip, linux-input, linux-leds
In-Reply-To: <20240905185232.2899464-1-heiko@sntech.de>
The MCU controls the power-button and beeper, so expose them as input
device. There is of course no interrupt line, so the status of the
power-button needs to be polled. To generate an event the power-button
also needs to be held for 1-2 seconds, so the polling interval does
not need to be overly fast.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
MAINTAINERS | 1 +
drivers/input/misc/Kconfig | 12 +++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/qnap-mcu-input.c | 153 ++++++++++++++++++++++++++++
4 files changed, 167 insertions(+)
create mode 100644 drivers/input/misc/qnap-mcu-input.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 943905cbcf62..cc5ef91d019e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18682,6 +18682,7 @@ F: drivers/media/tuners/qm1d1c0042*
QNAP MCU DRIVER
M: Heiko Stuebner <heiko@sntech.de>
S: Maintained
+F: drivers/input/misc/qnap-mcu-input.c
F: drivers/leds/leds-qnap-mcu.c
F: drivers/mfd/qnap-mcu.c
F: include/linux/qnap-mcu.h
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6a852c76331b..13d135257e06 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -917,6 +917,18 @@ config INPUT_HISI_POWERKEY
To compile this driver as a module, choose M here: the
module will be called hisi_powerkey.
+config INPUT_QNAP_MCU
+ tristate "Input Support for QNAP MCU controllers"
+ depends on MFD_QNAP_MCU
+ help
+ This option enables support for input elements available on
+ embedded controllers used in QNAP NAS devices.
+
+ This includes a polled power-button as well as a beeper.
+
+ To compile this driver as a module, choose M here: the
+ module will be called qnap-mcu-input.
+
config INPUT_RAVE_SP_PWRBUTTON
tristate "RAVE SP Power button Driver"
depends on RAVE_SP_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 4f7f736831ba..6d91804d0a6f 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_PWM_VIBRA) += pwm-vibra.o
+obj-$(CONFIG_INPUT_QNAP_MCU) += qnap-mcu-input.o
obj-$(CONFIG_INPUT_RAVE_SP_PWRBUTTON) += rave-sp-pwrbutton.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
diff --git a/drivers/input/misc/qnap-mcu-input.c b/drivers/input/misc/qnap-mcu-input.c
new file mode 100644
index 000000000000..76e62f0816c1
--- /dev/null
+++ b/drivers/input/misc/qnap-mcu-input.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Driver for input events on QNAP-MCUs
+ *
+ * Copyright (C) 2024 Heiko Stuebner <heiko@sntech.de>
+ */
+
+#include <linux/input.h>
+#include <linux/mfd/qnap-mcu.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <uapi/linux/input-event-codes.h>
+
+/*
+ * The power-key needs to be pressed for a while to create an event,
+ * so there is no use for overly frequent polling.
+ */
+#define POLL_INTERVAL 500
+
+struct qnap_mcu_input_dev {
+ struct input_dev *input;
+ struct qnap_mcu *mcu;
+ struct device *dev;
+
+ struct work_struct beep_work;
+ int beep_type;
+};
+
+static void qnap_mcu_input_poll(struct input_dev *input)
+{
+ struct qnap_mcu_input_dev *idev = input_get_drvdata(input);
+ static const u8 cmd[] = { '@', 'C', 'V' };
+ u8 reply[4];
+ int state, ret;
+
+ /* poll the power button */
+ ret = qnap_mcu_exec(idev->mcu, cmd, sizeof(cmd), reply, sizeof(reply));
+ if (ret)
+ return;
+
+ /* First bytes must mirror the sent command */
+ if (memcmp(cmd, reply, sizeof(cmd))) {
+ dev_err(idev->dev, "malformed data received\n");
+ return;
+ }
+
+ state = reply[3] - 0x30;
+ input_event(input, EV_KEY, KEY_POWER, state);
+ input_sync(input);
+}
+
+static void qnap_mcu_input_beeper_work(struct work_struct *work)
+{
+ struct qnap_mcu_input_dev *idev =
+ container_of(work, struct qnap_mcu_input_dev, beep_work);
+ const u8 cmd[] = { '@', 'C', (idev->beep_type == SND_TONE) ? '3' : '2' };
+
+ qnap_mcu_exec_with_ack(idev->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_input_event(struct input_dev *input, unsigned int type,
+ unsigned int code, int value)
+{
+ struct qnap_mcu_input_dev *idev = input_get_drvdata(input);
+
+ if (type != EV_SND || (code != SND_BELL && code != SND_TONE))
+ return -EOPNOTSUPP;
+
+ if (value < 0)
+ return -EINVAL;
+
+ /* beep runtime is determined by the MCU */
+ if (value == 0)
+ return 0;
+
+ /* Schedule work to actually turn the beeper on */
+ idev->beep_type = code;
+ schedule_work(&idev->beep_work);
+
+ return 0;
+}
+
+static void qnap_mcu_input_close(struct input_dev *input)
+{
+ struct qnap_mcu_input_dev *idev = input_get_drvdata(input);
+
+ cancel_work_sync(&idev->beep_work);
+}
+
+static int qnap_mcu_input_probe(struct platform_device *pdev)
+{
+ struct qnap_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
+ struct qnap_mcu_input_dev *idev;
+ struct device *dev = &pdev->dev;
+ struct input_dev *input;
+ int ret;
+
+ idev = devm_kzalloc(dev, sizeof(*idev), GFP_KERNEL);
+ if (!idev)
+ return -ENOMEM;
+
+ input = devm_input_allocate_device(dev);
+ if (!input)
+ return dev_err_probe(dev, -ENOMEM, "no memory for input device\n");
+
+ idev->input = input;
+ idev->dev = dev;
+ idev->mcu = mcu;
+
+ input_set_drvdata(input, idev);
+
+ input->name = "qnap-mcu";
+ input->phys = "qnap-mcu-input/input0";
+ input->id.bustype = BUS_HOST;
+ input->id.vendor = 0x0001;
+ input->id.product = 0x0001;
+ input->id.version = 0x0100;
+ input->event = qnap_mcu_input_event;
+ input->close = qnap_mcu_input_close;
+
+ input_set_capability(input, EV_KEY, KEY_POWER);
+ input_set_capability(input, EV_SND, SND_BELL);
+ input_set_capability(input, EV_SND, SND_TONE);
+
+ INIT_WORK(&idev->beep_work, qnap_mcu_input_beeper_work);
+
+ ret = input_setup_polling(input, qnap_mcu_input_poll);
+ if (ret)
+ return dev_err_probe(dev, ret, "unable to set up polling\n");
+
+ input_set_poll_interval(input, POLL_INTERVAL);
+
+ ret = input_register_device(input);
+ if (ret)
+ return dev_err_probe(dev, ret, "unable to register input device\n");
+
+ return 0;
+}
+
+static struct platform_driver qnap_mcu_input_driver = {
+ .probe = qnap_mcu_input_probe,
+ .driver = {
+ .name = "qnap-mcu-input",
+ },
+};
+module_platform_driver(qnap_mcu_input_driver);
+
+MODULE_ALIAS("platform:qnap-mcu-input");
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_DESCRIPTION("QNAP MCU input driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v7 1/8] mfd: core: make platform_data pointer const in struct mfd_cell
From: Heiko Stuebner @ 2024-09-05 18:52 UTC (permalink / raw)
To: lee
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, heiko, dmitry.torokhov,
pavel, ukleinek, devicetree, linux-kernel, linux-hwmon,
linux-arm-kernel, linux-rockchip, linux-input, linux-leds
In-Reply-To: <20240905185232.2899464-1-heiko@sntech.de>
The content of the platform_data of a struct mfd_cell is simply passed on
to the platform_device_add_data() call in mfd_add_device() .
platform_device_add_data() already handles the data behind that pointer
as const, so there is no reason to not extend this to struct mfd_cell.
This allows to pass structs gathered from of_device_get_match_data()
as platform-data to sub-devices - which is retrieved as const already.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
include/linux/mfd/core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index e8bcad641d8c..faeea7abd688 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -72,7 +72,7 @@ struct mfd_cell {
int (*resume)(struct platform_device *dev);
/* platform data passed to the sub devices drivers */
- void *platform_data;
+ const void *platform_data;
size_t pdata_size;
/* Matches ACPI */
--
2.43.0
^ permalink raw reply related
* [PATCH v7 0/8] Drivers to support the MCU on QNAP NAS devices
From: Heiko Stuebner @ 2024-09-05 18:52 UTC (permalink / raw)
To: lee
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, heiko, dmitry.torokhov,
pavel, ukleinek, devicetree, linux-kernel, linux-hwmon,
linux-arm-kernel, linux-rockchip, linux-input, linux-leds
This implements a set of drivers for the MCU used on QNAP NAS devices.
Of course no documentation for the serial protocol is available, so
thankfully QNAP has a tool on their rescue-inird to talk to the MCU and
I found interceptty [0] to listen to what goes over the serial connection.
In general it looks like there are two different generations in general,
an "EC" device and now this "MCU" - referenced in the strings of the
userspace handlers for those devices.
For the MCU "SPEC3" and "SPEC4" are listed which is configured in
the model.conf of the device. When setting the value from SPEC4 to
SPEC3 on my TS433, the supported commands change, but the command
interface stays the same and especially the version command is the
same.
The binding also does not expose any interals of the device that
might change, so hopefully there shouldn't be big roadblocks to
support different devices, apart from possibly adapting the commands.
changes in v7:
- use ASCII representation in commands where possible instead of hex vals
- drop get_variant function and use mfd platform-data instead
mfd:
- a lot of style improvements
leds:
- name variables better (value -> brightness, num -> num_err_led)
- handle preservation of blink mode more effectively
- snprintf -> scnprintf
- drop duplicate "failed to register ... LED" messages
changes in v6:
- format mcu commands arrays in single lines (Lee)
mfd:
- drop obsolete remain kdoc for the removed
reply_lock (kernel test robot)
changes in v5:
binding:
- add Conor's Reviewed-by
mfd:
Address comments from Lee
- improve commit message
- improve Kconfig help text
- sort headers alphabetical
- style and spelling improvements
- constants for magic numbers
- drop reply assignment, the mcu only replies to commands sent to it,
so there should only ever be one command in fligth.
hwmon:
Add Acked-by from Guenter and address some remarks
- don't allow empty fan subnode
- use num var directly when getting cooling levels, without using ret
intermediate
- use dev_err_probe in thermal init function
changes in v4:
binding:
- move cooling properties into a fan subnode and reference
fan-common.yaml (Rob)
- dropped Krzysztof's Ack because of this
mfd:
- use correct format-string for size_t (kernel test robot)
input:
- added Dmitry's Ack
hwmon:
- adapted to fan-subnode when reading cooling properties
- dropped Guenter's Ack because of this
changes in v3:
mfd
- use correct power-off priority: default
- constify the cmd-data array in command functions (Dmitry)
leds:
- don't point to temporary buffers for cdev->name (Florian Eckert)
hwmon:
- use clamp_val(), don't try to reimplement (Guenter)
- add Guenter's Ack
input:
address Dmitry's comments
- constify some cmd arrays
- add input-close callback to cancel beep worker
- drop initial input event report
changes in v2:
binding:
- rename to qnap,ts433-mcu.yaml (Krzysztof)
- drop "preserve formatting" indicator (Krzysztof)
- add Krzysztof's Review tag
mfd:
- fix checkpatch --strict CHECKs
- add a MAINTAINERS entry for all qnap-mcu-parts
Heiko Stuebner (8):
mfd: core: make platform_data pointer const in struct mfd_cell
dt-bindings: mfd: add binding for qnap,ts433-mcu devices
mfd: add base driver for qnap-mcu devices
leds: add driver for LEDs from qnap-mcu devices
Input: add driver for the input part of qnap-mcu devices
hwmon: add driver for the hwmon parts of qnap-mcu devices
arm64: dts: rockchip: hook up the MCU on the QNAP TS433
arm64: dts: rockchip: set hdd led labels on qnap-ts433
.../bindings/mfd/qnap,ts433-mcu.yaml | 42 ++
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/qnap-mcu-hwmon.rst | 27 ++
MAINTAINERS | 9 +
.../boot/dts/rockchip/rk3568-qnap-ts433.dts | 61 +++
drivers/hwmon/Kconfig | 12 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/qnap-mcu-hwmon.c | 364 ++++++++++++++++++
drivers/input/misc/Kconfig | 12 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/qnap-mcu-input.c | 153 ++++++++
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-qnap-mcu.c | 227 +++++++++++
drivers/mfd/Kconfig | 13 +
drivers/mfd/Makefile | 2 +
drivers/mfd/qnap-mcu.c | 332 ++++++++++++++++
include/linux/mfd/core.h | 2 +-
include/linux/mfd/qnap-mcu.h | 26 ++
19 files changed, 1296 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
create mode 100644 Documentation/hwmon/qnap-mcu-hwmon.rst
create mode 100644 drivers/hwmon/qnap-mcu-hwmon.c
create mode 100644 drivers/input/misc/qnap-mcu-input.c
create mode 100644 drivers/leds/leds-qnap-mcu.c
create mode 100644 drivers/mfd/qnap-mcu.c
create mode 100644 include/linux/mfd/qnap-mcu.h
--
2.43.0
^ permalink raw reply
* [PATCH v7 2/8] dt-bindings: mfd: add binding for qnap,ts433-mcu devices
From: Heiko Stuebner @ 2024-09-05 18:52 UTC (permalink / raw)
To: lee
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, heiko, dmitry.torokhov,
pavel, ukleinek, devicetree, linux-kernel, linux-hwmon,
linux-arm-kernel, linux-rockchip, linux-input, linux-leds,
Conor Dooley
In-Reply-To: <20240905185232.2899464-1-heiko@sntech.de>
These MCUs can be found in network attached storage devices made by QNAP.
They are connected to a serial port of the host device and provide
functionality like LEDs, power-control and temperature monitoring.
LEDs, buttons, etc are all elements of the MCU firmware itself, so don't
need devicetree input, though the fan gets its cooling settings from
a fan-0 subnode.
A binding for the LEDs for setting the linux-default-trigger may come
later, once all the LEDs are understood and ATA controllers actually
can address individual port-LEDs, but are really optional.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
.../bindings/mfd/qnap,ts433-mcu.yaml | 42 +++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
diff --git a/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml b/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
new file mode 100644
index 000000000000..877078ac172f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/qnap,ts433-mcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QNAP NAS on-board Microcontroller
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+description:
+ QNAP embeds a microcontroller on their NAS devices adding system feature
+ as PWM Fan control, additional LEDs, power button status and more.
+
+properties:
+ compatible:
+ enum:
+ - qnap,ts433-mcu
+
+patternProperties:
+ "^fan-[0-9]+$":
+ $ref: /schemas/hwmon/fan-common.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ uart {
+ mcu {
+ compatible = "qnap,ts433-mcu";
+
+ fan-0 {
+ #cooling-cells = <2>;
+ cooling-levels = <0 64 89 128 166 204 221 238>;
+ };
+ };
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v7 7/8] arm64: dts: rockchip: hook up the MCU on the QNAP TS433
From: Heiko Stuebner @ 2024-09-05 18:52 UTC (permalink / raw)
To: lee
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, heiko, dmitry.torokhov,
pavel, ukleinek, devicetree, linux-kernel, linux-hwmon,
linux-arm-kernel, linux-rockchip, linux-input, linux-leds
In-Reply-To: <20240905185232.2899464-1-heiko@sntech.de>
The MCU is an important part of the device functionality. It provides
functionality like fan-control, more leds, etc and even more important
without it, the NAS-device cannot even fully turned off.
Hook up the serial device to its uart and hook into the thermal
management to control the fan according to the cpu temperature.
While the MCU also provides a temperature sensor for the case, this one
is just polled and does not provide functionality for handling trip
points in hardware, so a lot of polling would be involved.
As the cpu is only cooled passively in these devices, it's temperature
rising will indicate the temperature level of the system just earlier.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
.../boot/dts/rockchip/rk3568-qnap-ts433.dts | 57 +++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts b/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
index e601d9271ba8..4bc5f5691d45 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
@@ -483,6 +483,54 @@ rgmii_phy0: ethernet-phy@0 {
};
};
+/*
+ * The MCU can provide system temperature too, but only by polling and of
+ * course also cannot set trip points. So attach to the cpu thermal-zone
+ * instead to control the fan.
+ */
+&cpu_thermal {
+ trips {
+ case_fan0: case-fan0 {
+ hysteresis = <2000>;
+ temperature = <35000>;
+ type = "active";
+ };
+
+ case_fan1: case-fan1 {
+ hysteresis = <2000>;
+ temperature = <45000>;
+ type = "active";
+ };
+
+ case_fan2: case-fan2 {
+ hysteresis = <2000>;
+ temperature = <65000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ /*
+ * Always provide some air movement, due to small case
+ * full of harddrives.
+ */
+ map1 {
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ trip = <&case_fan0>;
+ };
+
+ map2 {
+ cooling-device = <&fan 2 3>;
+ trip = <&case_fan1>;
+ };
+
+ map3 {
+ cooling-device = <&fan 4 THERMAL_NO_LIMIT>;
+ trip = <&case_fan2>;
+ };
+ };
+};
+
&pcie30phy {
data-lanes = <1 2>;
status = "okay";
@@ -582,6 +630,15 @@ &tsadc {
*/
&uart0 {
status = "okay";
+
+ mcu {
+ compatible = "qnap,ts433-mcu";
+
+ fan: fan-0 {
+ #cooling-cells = <2>;
+ cooling-levels = <0 64 89 128 166 204 221 238>;
+ };
+ };
};
/*
--
2.43.0
^ permalink raw reply related
* [PATCH v7 6/8] hwmon: add driver for the hwmon parts of qnap-mcu devices
From: Heiko Stuebner @ 2024-09-05 18:52 UTC (permalink / raw)
To: lee
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, heiko, dmitry.torokhov,
pavel, ukleinek, devicetree, linux-kernel, linux-hwmon,
linux-arm-kernel, linux-rockchip, linux-input, linux-leds
In-Reply-To: <20240905185232.2899464-1-heiko@sntech.de>
The MCU can be found on network-attached-storage devices made by QNAP
and provides access to fan control including reading back its RPM as
well as reading the temperature of the NAS case.
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/qnap-mcu-hwmon.rst | 27 ++
MAINTAINERS | 1 +
drivers/hwmon/Kconfig | 12 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/qnap-mcu-hwmon.c | 364 +++++++++++++++++++++++++
6 files changed, 406 insertions(+)
create mode 100644 Documentation/hwmon/qnap-mcu-hwmon.rst
create mode 100644 drivers/hwmon/qnap-mcu-hwmon.c
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 913c11390a45..7adbe23f0659 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -199,6 +199,7 @@ Hardware Monitoring Kernel Drivers
pxe1610
pwm-fan
q54sj108a2
+ qnap-mcu-hwmon
raspberrypi-hwmon
sbrmi
sbtsi_temp
diff --git a/Documentation/hwmon/qnap-mcu-hwmon.rst b/Documentation/hwmon/qnap-mcu-hwmon.rst
new file mode 100644
index 000000000000..83407e3408f2
--- /dev/null
+++ b/Documentation/hwmon/qnap-mcu-hwmon.rst
@@ -0,0 +1,27 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver qnap-mcu-hwmon
+============================
+
+This driver enables the use of the hardware monitoring and fan control
+of the MCU used on some QNAP network attached storage devices.
+
+Author: Heiko Stuebner <heiko@sntech.de>
+
+Description
+-----------
+
+The driver implements a simple interface for driving the fan controlled by
+setting its PWM output value and exposes the fan rpm and case-temperature
+to user space through hwmon's sysfs interface.
+
+The fan rotation speed returned via the optional 'fan1_input' is calculated
+inside the MCU device.
+
+The driver provides the following sensor accesses in sysfs:
+
+=============== ======= =======================================================
+fan1_input ro fan tachometer speed in RPM
+pwm1 rw relative speed (0-255), 255=max. speed.
+temp1_input ro Measured temperature in millicelsius
+=============== ======= =======================================================
diff --git a/MAINTAINERS b/MAINTAINERS
index cc5ef91d019e..8c35c994d0b0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18682,6 +18682,7 @@ F: drivers/media/tuners/qm1d1c0042*
QNAP MCU DRIVER
M: Heiko Stuebner <heiko@sntech.de>
S: Maintained
+F: drivers/hwmon/qnap-mcu-hwmon.c
F: drivers/input/misc/qnap-mcu-input.c
F: drivers/leds/leds-qnap-mcu.c
F: drivers/mfd/qnap-mcu.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index b60fe2e58ad6..0118ad91057e 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1793,6 +1793,18 @@ config SENSORS_PWM_FAN
This driver can also be built as a module. If so, the module
will be called pwm-fan.
+config SENSORS_QNAP_MCU_HWMON
+ tristate "QNAP MCU hardware monitoring"
+ depends on MFD_QNAP_MCU
+ depends on THERMAL || THERMAL=n
+ help
+ Say yes here to enable support for fan and temperature sensor
+ connected to a QNAP MCU, as found in a number of QNAP network
+ attached storage devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called qnap-mcu-hwmon.
+
config SENSORS_RASPBERRYPI_HWMON
tristate "Raspberry Pi voltage monitor"
depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index b1c7056c37db..d60f46a03cc9 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -187,6 +187,7 @@ obj-$(CONFIG_SENSORS_POWERZ) += powerz.o
obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
obj-$(CONFIG_SENSORS_PT5161L) += pt5161l.o
obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
+obj-$(CONFIG_SENSORS_QNAP_MCU_HWMON) += qnap-mcu-hwmon.o
obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON) += raspberrypi-hwmon.o
obj-$(CONFIG_SENSORS_SBTSI) += sbtsi_temp.o
obj-$(CONFIG_SENSORS_SBRMI) += sbrmi.o
diff --git a/drivers/hwmon/qnap-mcu-hwmon.c b/drivers/hwmon/qnap-mcu-hwmon.c
new file mode 100644
index 000000000000..29057514739c
--- /dev/null
+++ b/drivers/hwmon/qnap-mcu-hwmon.c
@@ -0,0 +1,364 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Driver for hwmon elements found on QNAP-MCU devices
+ *
+ * Copyright (C) 2024 Heiko Stuebner <heiko@sntech.de>
+ */
+
+#include <linux/fwnode.h>
+#include <linux/hwmon.h>
+#include <linux/mfd/qnap-mcu.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/thermal.h>
+
+struct qnap_mcu_hwmon {
+ struct qnap_mcu *mcu;
+ struct device *dev;
+
+ unsigned int pwm_min;
+ unsigned int pwm_max;
+
+ struct fwnode_handle *fan_node;
+ unsigned int fan_state;
+ unsigned int fan_max_state;
+ unsigned int *fan_cooling_levels;
+
+ struct thermal_cooling_device *cdev;
+ struct hwmon_chip_info info;
+};
+
+static int qnap_mcu_hwmon_get_rpm(struct qnap_mcu_hwmon *hwm)
+{
+ static const u8 cmd[] = { '@', 'F', 'A' };
+ u8 reply[6];
+ int ret;
+
+ /* poll the fan rpm */
+ ret = qnap_mcu_exec(hwm->mcu, cmd, sizeof(cmd), reply, sizeof(reply));
+ if (ret)
+ return ret;
+
+ /* First 2 bytes must mirror the sent command */
+ if (memcmp(cmd, reply, 2))
+ return -EIO;
+
+ return reply[4] * 30;
+}
+
+static int qnap_mcu_hwmon_get_pwm(struct qnap_mcu_hwmon *hwm)
+{
+ static const u8 cmd[] = { '@', 'F', 'Z', '0' }; /* 0 = fan-id? */
+ u8 reply[4];
+ int ret;
+
+ /* poll the fan pwm */
+ ret = qnap_mcu_exec(hwm->mcu, cmd, sizeof(cmd), reply, sizeof(reply));
+ if (ret)
+ return ret;
+
+ /* First 3 bytes must mirror the sent command */
+ if (memcmp(cmd, reply, 3))
+ return -EIO;
+
+ return reply[3];
+}
+
+static int qnap_mcu_hwmon_set_pwm(struct qnap_mcu_hwmon *hwm, u8 pwm)
+{
+ const u8 cmd[] = { '@', 'F', 'W', '0', pwm }; /* 0 = fan-id?, pwm 0-255 */
+
+ /* set the fan pwm */
+ return qnap_mcu_exec_with_ack(hwm->mcu, cmd, sizeof(cmd));
+}
+
+static int qnap_mcu_hwmon_get_temp(struct qnap_mcu_hwmon *hwm)
+{
+ static const u8 cmd[] = { '@', 'T', '3' };
+ u8 reply[4];
+ int ret;
+
+ /* poll the fan rpm */
+ ret = qnap_mcu_exec(hwm->mcu, cmd, sizeof(cmd), reply, sizeof(reply));
+ if (ret)
+ return ret;
+
+ /* First bytes must mirror the sent command */
+ if (memcmp(cmd, reply, sizeof(cmd)))
+ return -EIO;
+
+ /*
+ * There is an unknown bit set in bit7.
+ * Bits [6:0] report the actual temperature as returned by the
+ * original qnap firmware-tools, so just drop bit7 for now.
+ */
+ return (reply[3] & 0x7f) * 1000;
+}
+
+static int qnap_mcu_hwmon_write(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long val)
+{
+ struct qnap_mcu_hwmon *hwm = dev_get_drvdata(dev);
+
+ switch (attr) {
+ case hwmon_pwm_input:
+ if (val < 0 || val > 255)
+ return -EINVAL;
+
+ if (val != 0)
+ val = clamp_val(val, hwm->pwm_min, hwm->pwm_max);
+
+ return qnap_mcu_hwmon_set_pwm(hwm, val);
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+static int qnap_mcu_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ struct qnap_mcu_hwmon *hwm = dev_get_drvdata(dev);
+ int ret;
+
+ switch (type) {
+ case hwmon_pwm:
+ switch (attr) {
+ case hwmon_pwm_input:
+ ret = qnap_mcu_hwmon_get_pwm(hwm);
+ if (ret < 0)
+ return ret;
+
+ *val = ret;
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ case hwmon_fan:
+ ret = qnap_mcu_hwmon_get_rpm(hwm);
+ if (ret < 0)
+ return ret;
+
+ *val = ret;
+ return 0;
+ case hwmon_temp:
+ ret = qnap_mcu_hwmon_get_temp(hwm);
+ if (ret < 0)
+ return ret;
+
+ *val = ret;
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static umode_t qnap_mcu_hwmon_is_visible(const void *data,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ switch (type) {
+ case hwmon_temp:
+ return 0444;
+
+ case hwmon_pwm:
+ return 0644;
+
+ case hwmon_fan:
+ return 0444;
+
+ default:
+ return 0;
+ }
+}
+
+static const struct hwmon_ops qnap_mcu_hwmon_hwmon_ops = {
+ .is_visible = qnap_mcu_hwmon_is_visible,
+ .read = qnap_mcu_hwmon_read,
+ .write = qnap_mcu_hwmon_write,
+};
+
+/* thermal cooling device callbacks */
+static int qnap_mcu_hwmon_get_max_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct qnap_mcu_hwmon *hwm = cdev->devdata;
+
+ if (!hwm)
+ return -EINVAL;
+
+ *state = hwm->fan_max_state;
+
+ return 0;
+}
+
+static int qnap_mcu_hwmon_get_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct qnap_mcu_hwmon *hwm = cdev->devdata;
+
+ if (!hwm)
+ return -EINVAL;
+
+ *state = hwm->fan_state;
+
+ return 0;
+}
+
+static int qnap_mcu_hwmon_set_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long state)
+{
+ struct qnap_mcu_hwmon *hwm = cdev->devdata;
+ int ret;
+
+ if (!hwm || state > hwm->fan_max_state)
+ return -EINVAL;
+
+ if (state == hwm->fan_state)
+ return 0;
+
+ ret = qnap_mcu_hwmon_set_pwm(hwm, hwm->fan_cooling_levels[state]);
+ if (ret)
+ return ret;
+
+ hwm->fan_state = state;
+
+ return ret;
+}
+
+static const struct thermal_cooling_device_ops qnap_mcu_hwmon_cooling_ops = {
+ .get_max_state = qnap_mcu_hwmon_get_max_state,
+ .get_cur_state = qnap_mcu_hwmon_get_cur_state,
+ .set_cur_state = qnap_mcu_hwmon_set_cur_state,
+};
+
+static void devm_fan_node_release(void *data)
+{
+ struct qnap_mcu_hwmon *hwm = data;
+
+ fwnode_handle_put(hwm->fan_node);
+}
+
+static int qnap_mcu_hwmon_get_cooling_data(struct device *dev, struct qnap_mcu_hwmon *hwm)
+{
+ struct fwnode_handle *fwnode;
+ int num, i, ret;
+
+ fwnode = device_get_named_child_node(dev->parent, "fan-0");
+ if (!fwnode)
+ return 0;
+
+ /* if we found the fan-node, we're keeping it until device-unbind */
+ hwm->fan_node = fwnode;
+ ret = devm_add_action_or_reset(dev, devm_fan_node_release, hwm);
+ if (ret)
+ return ret;
+
+ num = fwnode_property_count_u32(fwnode, "cooling-levels");
+ if (num <= 0)
+ return dev_err_probe(dev, num ? : -EINVAL,
+ "Failed to count elements in 'cooling-levels'\n");
+
+ hwm->fan_cooling_levels = devm_kcalloc(dev, num, sizeof(u32),
+ GFP_KERNEL);
+ if (!hwm->fan_cooling_levels)
+ return -ENOMEM;
+
+ ret = fwnode_property_read_u32_array(fwnode, "cooling-levels",
+ hwm->fan_cooling_levels, num);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to read 'cooling-levels'\n");
+
+ for (i = 0; i < num; i++) {
+ if (hwm->fan_cooling_levels[i] > hwm->pwm_max)
+ return dev_err_probe(dev, -EINVAL, "fan state[%d]:%d > %d\n", i,
+ hwm->fan_cooling_levels[i], hwm->pwm_max);
+ }
+
+ hwm->fan_max_state = num - 1;
+
+ return 0;
+}
+
+static const struct hwmon_channel_info * const qnap_mcu_hwmon_channels[] = {
+ HWMON_CHANNEL_INFO(pwm, HWMON_PWM_INPUT),
+ HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT),
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
+ NULL
+};
+
+static int qnap_mcu_hwmon_probe(struct platform_device *pdev)
+{
+ struct qnap_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
+ const struct qnap_mcu_variant *variant = pdev->dev.platform_data;
+ struct qnap_mcu_hwmon *hwm;
+ struct thermal_cooling_device *cdev;
+ struct device *dev = &pdev->dev;
+ struct device *hwmon;
+ int ret;
+
+ hwm = devm_kzalloc(dev, sizeof(*hwm), GFP_KERNEL);
+ if (!hwm)
+ return -ENOMEM;
+
+ hwm->mcu = mcu;
+ hwm->dev = &pdev->dev;
+ hwm->pwm_min = variant->fan_pwm_min;
+ hwm->pwm_max = variant->fan_pwm_max;
+
+ platform_set_drvdata(pdev, hwm);
+
+ /*
+ * Set duty cycle to maximum allowed.
+ */
+ ret = qnap_mcu_hwmon_set_pwm(hwm, hwm->pwm_max);
+ if (ret)
+ return ret;
+
+ hwm->info.ops = &qnap_mcu_hwmon_hwmon_ops;
+ hwm->info.info = qnap_mcu_hwmon_channels;
+
+ ret = qnap_mcu_hwmon_get_cooling_data(dev, hwm);
+ if (ret)
+ return ret;
+
+ hwm->fan_state = hwm->fan_max_state;
+
+ hwmon = devm_hwmon_device_register_with_info(dev, "qnapmcu",
+ hwm, &hwm->info, NULL);
+ if (IS_ERR(hwmon))
+ return dev_err_probe(dev, PTR_ERR(hwmon), "Failed to register hwmon device\n");
+
+ /*
+ * Only register cooling device when we found cooling-levels.
+ * qnap_mcu_hwmon_get_cooling_data() will fail when reading malformed
+ * levels and only succeed with either no or correct cooling levels.
+ */
+ if (IS_ENABLED(CONFIG_THERMAL) && hwm->fan_cooling_levels) {
+ cdev = devm_thermal_of_cooling_device_register(dev,
+ to_of_node(hwm->fan_node), "qnap-mcu-hwmon",
+ hwm, &qnap_mcu_hwmon_cooling_ops);
+ if (IS_ERR(cdev))
+ return dev_err_probe(dev, PTR_ERR(cdev),
+ "Failed to register qnap-mcu-hwmon as cooling device\n");
+ hwm->cdev = cdev;
+ }
+
+ return 0;
+}
+
+static struct platform_driver qnap_mcu_hwmon_driver = {
+ .probe = qnap_mcu_hwmon_probe,
+ .driver = {
+ .name = "qnap-mcu-hwmon",
+ },
+};
+module_platform_driver(qnap_mcu_hwmon_driver);
+
+MODULE_ALIAS("platform:qnap-mcu-hwmon");
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_DESCRIPTION("QNAP MCU hwmon driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v7 8/8] arm64: dts: rockchip: set hdd led labels on qnap-ts433
From: Heiko Stuebner @ 2024-09-05 18:52 UTC (permalink / raw)
To: lee
Cc: robh, krzk+dt, conor+dt, jdelvare, linux, heiko, dmitry.torokhov,
pavel, ukleinek, devicetree, linux-kernel, linux-hwmon,
linux-arm-kernel, linux-rockchip, linux-input, linux-leds
In-Reply-To: <20240905185232.2899464-1-heiko@sntech.de>
The automatically generated names for the LEDs from color and function
do not match nicely for the 4 hdds, so set them manually per the label
property to also match the LEDs generated from the MCU.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts b/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
index 4bc5f5691d45..7bd32d230ad2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts
@@ -50,6 +50,7 @@ led-0 {
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_DISK;
gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_LOW>;
+ label = "hdd1:green:disk";
linux,default-trigger = "disk-activity";
pinctrl-names = "default";
pinctrl-0 = <&hdd1_led_pin>;
@@ -59,6 +60,7 @@ led-1 {
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_DISK;
gpios = <&gpio1 RK_PD6 GPIO_ACTIVE_LOW>;
+ label = "hdd2:green:disk";
linux,default-trigger = "disk-activity";
pinctrl-names = "default";
pinctrl-0 = <&hdd2_led_pin>;
@@ -68,6 +70,7 @@ led-2 {
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_DISK;
gpios = <&gpio1 RK_PD7 GPIO_ACTIVE_LOW>;
+ label = "hdd3:green:disk";
linux,default-trigger = "disk-activity";
pinctrl-names = "default";
pinctrl-0 = <&hdd3_led_pin>;
@@ -77,6 +80,7 @@ led-3 {
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_DISK;
gpios = <&gpio2 RK_PA0 GPIO_ACTIVE_LOW>;
+ label = "hdd4:green:disk";
linux,default-trigger = "disk-activity";
pinctrl-names = "default";
pinctrl-0 = <&hdd4_led_pin>;
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/1] HID: debug: Remove duplicates from 'keys'
From: Andy Shevchenko @ 2024-09-05 18:43 UTC (permalink / raw)
To: Thomas Kuehne, linux-input, linux-kernel, llvm
Cc: Jiri Kosina, Benjamin Tissoires, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Andy Shevchenko
Duplicates in 'keys prevents kernel builds with clang, `make W=1` and
CONFIG_WERROR=y, for example:
drivers/hid/hid-debug.c:3443:18: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides]
3443 | [KEY_HANGEUL] = "HanGeul", [KEY_HANGUP_PHONE] = "HangUpPhone",
| ^~~~~~~~~
drivers/hid/hid-debug.c:3217:18: note: previous initialization is here
3217 | [KEY_HANGUEL] = "Hangeul", [KEY_HANJA] = "Hanja",
| ^~~~~~~~~
Fix this by removing them.
The logic of removal is that, remove...
1) if there is a constant that uses another defined constant, OR
2) the one that appears later in the list.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/hid/hid-debug.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index d5abfe652fb5..618ebaa3bfc0 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -3214,7 +3214,7 @@ static const char *keys[KEY_MAX + 1] = {
[KEY_VOLUMEUP] = "VolumeUp", [KEY_POWER] = "Power",
[KEY_KPEQUAL] = "KPEqual", [KEY_KPPLUSMINUS] = "KPPlusMinus",
[KEY_PAUSE] = "Pause", [KEY_KPCOMMA] = "KPComma",
- [KEY_HANGUEL] = "Hangeul", [KEY_HANJA] = "Hanja",
+ [KEY_HANJA] = "Hanja",
[KEY_YEN] = "Yen", [KEY_LEFTMETA] = "LeftMeta",
[KEY_RIGHTMETA] = "RightMeta", [KEY_COMPOSE] = "Compose",
[KEY_STOP] = "Stop", [KEY_AGAIN] = "Again",
@@ -3309,9 +3309,9 @@ static const char *keys[KEY_MAX + 1] = {
[KEY_EPG] = "EPG", [KEY_PVR] = "PVR",
[KEY_MHP] = "MHP", [KEY_LANGUAGE] = "Language",
[KEY_TITLE] = "Title", [KEY_SUBTITLE] = "Subtitle",
- [KEY_ANGLE] = "Angle", [KEY_ZOOM] = "Zoom",
+ [KEY_ANGLE] = "Angle",
[KEY_MODE] = "Mode", [KEY_KEYBOARD] = "Keyboard",
- [KEY_SCREEN] = "Screen", [KEY_PC] = "PC",
+ [KEY_PC] = "PC",
[KEY_TV] = "TV", [KEY_TV2] = "TV2",
[KEY_VCR] = "VCR", [KEY_VCR2] = "VCR2",
[KEY_SAT] = "Sat", [KEY_SAT2] = "Sat2",
@@ -3409,8 +3409,7 @@ static const char *keys[KEY_MAX + 1] = {
[BTN_TRIGGER_HAPPY35] = "TriggerHappy35", [BTN_TRIGGER_HAPPY36] = "TriggerHappy36",
[BTN_TRIGGER_HAPPY37] = "TriggerHappy37", [BTN_TRIGGER_HAPPY38] = "TriggerHappy38",
[BTN_TRIGGER_HAPPY39] = "TriggerHappy39", [BTN_TRIGGER_HAPPY40] = "TriggerHappy40",
- [BTN_DIGI] = "Digi", [BTN_STYLUS3] = "Stylus3",
- [BTN_TOOL_QUINTTAP] = "ToolQuintTap", [BTN_WHEEL] = "Wheel",
+ [BTN_STYLUS3] = "Stylus3", [BTN_TOOL_QUINTTAP] = "ToolQuintTap",
[KEY_10CHANNELSDOWN] = "10ChannelsDown",
[KEY_10CHANNELSUP] = "10ChannelsUp",
[KEY_3D_MODE] = "3DMode", [KEY_ADDRESSBOOK] = "Addressbook",
--
2.43.0.rc1.1336.g36b5255a03ac
^ permalink raw reply related
* [PATCH] Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table
From: Werner Sembach @ 2024-09-05 16:48 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Werner Sembach, linux-input, linux-kernel
Some TongFang barebones have touchpad and/or keyboard issues after
suspend, fixable with nomux + reset + noloop + nopnp. Luckily, none of
them have an external PS/2 port so this can safely be set for all of
them.
I'm not entirely sure if every device listed really needs all four quirks,
but after testing and production use, no negative effects could be
observed when setting all four.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: stable@vger.kernel.org
---
drivers/input/serio/i8042-acpipnpio.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/input/serio/i8042-acpipnpio.h b/drivers/input/serio/i8042-acpipnpio.h
index bad238f69a7af..1d73391f127bc 100644
--- a/drivers/input/serio/i8042-acpipnpio.h
+++ b/drivers/input/serio/i8042-acpipnpio.h
@@ -1120,6 +1120,29 @@ static const struct dmi_system_id i8042_dmi_quirk_table[] __initconst = {
},
.driver_data = (void *)(SERIO_QUIRK_NOLOOP)
},
+ /*
+ * Some TongFang barebones have touchpad and/or keyboard issues after
+ * suspend fixable with nomux + reset + noloop + nopnp. Luckily, none of
+ * them have an external PS/2 port so this can safely be set for all of
+ * them.
+ * TongFang barebones come with board_vendor and/or system_vendor set to
+ * a different value for each individual reseller. The only somewhat
+ * universal way to identify them is by board_name.
+ */
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "GM6XGxX"),
+ },
+ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
+ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "GMxXGxX"),
+ },
+ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
+ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
+ },
/*
* A lot of modern Clevo barebones have touchpad and/or keyboard issues
* after suspend fixable with nomux + reset + noloop + nopnp. Luckily,
--
2.34.1
^ 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