devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: lee@kernel.org, jikos@kernel.org, jic23@kernel.org,
	Kees Bakker <kees@ijzerbout.nl>
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
	jdelvare@suse.com, linux@roeck-us.net,
	srinivas.pandruvada@linux.intel.com, bentiss@kernel.org,
	dmitry.torokhov@gmail.com, pavel@ucw.cz, ukleinek@debian.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-hwmon@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-input@vger.kernel.org,
	linux-iio@vger.kernel.org, linux-leds@vger.kernel.org
Subject: Re: [PATCH v9 4/9] mfd: add base driver for qnap-mcu devices
Date: Thu, 19 Dec 2024 20:43:08 +0100	[thread overview]
Message-ID: <3130486.CbtlEUcBR6@diego> (raw)
In-Reply-To: <5d1ddf7e-2df5-4563-81e5-e0cfa7ef58da@ijzerbout.nl>

Hi Kees,

Am Donnerstag, 19. Dezember 2024, 20:18:38 CET schrieb Kees Bakker:
> Op 07-11-2024 om 12:47 schreef Heiko Stuebner:
> > 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       | 338 +++++++++++++++++++++++++++++++++++
> >   include/linux/mfd/qnap-mcu.h |  26 +++
> >   5 files changed, 385 insertions(+)
> >   create mode 100644 drivers/mfd/qnap-mcu.c
> >   create mode 100644 include/linux/mfd/qnap-mcu.h
> >
> > [...]
> > diff --git a/drivers/mfd/qnap-mcu.c b/drivers/mfd/qnap-mcu.c
> > new file mode 100644
> > index 000000000000..4be39d8b2905
> > --- /dev/null
> > +++ b/drivers/mfd/qnap-mcu.c
> > [...]
> > +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);
> > +
> > +	serdev_device_wait_until_sent(mcu->serdev, msecs_to_jiffies(QNAP_MCU_TIMEOUT_MS));
> > +
> > +	if (!wait_for_completion_timeout(&reply->done, msecs_to_jiffies(QNAP_MCU_TIMEOUT_MS))) {
> > +		dev_err(&mcu->serdev->dev, "Command timeout\n");
> > +		ret = -ETIMEDOUT;
> > +	} else {
> > +		u8 crc = qnap_mcu_csum(rx, reply_data_size);
> Here `rx` is still not initialized.

The MCU works in a way that a sent command always causes "reply_data_size"
bytes to be returned.

So for each qnap_mcu_write() above we know that this amount of bytes has
been returned (and thus written into rx) if the completion above finishes
sucessfully.

"rx" is assigned to reply->data above (same as the expected received size).
When characters are received on the serial line, this will trigger
qnap_mcu_receive_buf() from the serdev and thus fill those elements in rx.

So if we land at the qnap_mcu_csum() call, we do have received the expected
amount of bytes from the serdev and thus rx is filled accordingly.

If we don't receive the needed amount of bytes, we end up in the timeout
above that.

What did I miss?


Heiko

> > +
> > +		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);
> > +		}
> > +	}
> > +
> > +	mutex_unlock(&mcu->bus_lock);
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(qnap_mcu_exec);
> >
> 





  reply	other threads:[~2024-12-19 19:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-07 11:47 [PATCH v9 0/9] Drivers to support the MCU on QNAP NAS devices Heiko Stuebner
2024-11-07 11:47 ` [PATCH v9 1/9] HID: hid-sensor-hub: don't use stale platform-data on remove Heiko Stuebner
2024-11-07 12:59   ` Jiri Kosina
2024-11-07 13:50     ` Heiko Stübner
2024-11-07 14:34       ` Jiri Kosina
2024-11-12 14:37         ` Lee Jones
2024-12-11 12:17           ` Lee Jones
2024-12-11 12:24             ` Jiri Kosina
2024-12-11 13:01               ` Heiko Stübner
2024-12-11 13:11                 ` Jiri Kosina
2024-12-12 15:55                   ` Lee Jones
2024-12-11 14:23               ` srinivas pandruvada
2024-11-07 11:47 ` [PATCH v9 2/9] mfd: core: make platform_data pointer const in struct mfd_cell Heiko Stuebner
2024-11-07 11:47 ` [PATCH v9 3/9] dt-bindings: mfd: add binding for qnap,ts433-mcu devices Heiko Stuebner
2024-11-07 11:47 ` [PATCH v9 4/9] mfd: add base driver for qnap-mcu devices Heiko Stuebner
2024-12-19 19:18   ` Kees Bakker
2024-12-19 19:43     ` Heiko Stübner [this message]
2024-12-19 19:51       ` Kees Bakker
2024-12-19 20:01         ` Heiko Stübner
2024-11-07 11:47 ` [PATCH v9 5/9] leds: add driver for LEDs from " Heiko Stuebner
2024-11-07 11:47 ` [PATCH v9 6/9] Input: add driver for the input part of " Heiko Stuebner
2024-11-07 11:47 ` [PATCH v9 7/9] hwmon: add driver for the hwmon parts " Heiko Stuebner
2024-11-07 11:47 ` [PATCH v9 8/9] arm64: dts: rockchip: hook up the MCU on the QNAP TS433 Heiko Stuebner
2024-11-07 11:47 ` [PATCH v9 9/9] arm64: dts: rockchip: set hdd led labels on qnap-ts433 Heiko Stuebner
2024-12-12 17:17 ` [PATCH v9 0/9] Drivers to support the MCU on QNAP NAS devices Lee Jones
2024-12-12 17:19   ` Lee Jones
2024-12-12 17:19   ` Lee Jones
2024-12-18 22:49     ` Heiko Stübner
2024-12-17 13:16 ` [GIT PULL] Immutable branch between MFD, HID, HWMON, Input and LEDs due for the v6.14 merge window Lee Jones
2024-12-18 21:06 ` (subset) [PATCH v9 0/9] Drivers to support the MCU on QNAP NAS devices Heiko Stuebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3130486.CbtlEUcBR6@diego \
    --to=heiko@sntech.de \
    --cc=bentiss@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jdelvare@suse.com \
    --cc=jic23@kernel.org \
    --cc=jikos@kernel.org \
    --cc=kees@ijzerbout.nl \
    --cc=krzk+dt@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@roeck-us.net \
    --cc=pavel@ucw.cz \
    --cc=robh@kernel.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=ukleinek@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).