Devicetree
 help / color / mirror / Atom feed
From: Marco Felsch <m.felsch@pengutronix.de>
To: Russ Weight <russ.weight@linux.dev>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Kamel Bouhara <kamel.bouhara@bootlin.com>,
	Marco Felsch <kernel@pengutronix.de>,
	Henrik Rydberg <rydberg@bitmath.org>,
	Danilo Krummrich <dakr@redhat.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-input@vger.kernel.org
Subject: Re: [PATCH 2/5] firmware_loader: add support to handle FW_UPLOAD_ERR_SKIP
Date: Wed, 20 Nov 2024 18:30:37 +0100	[thread overview]
Message-ID: <20241120173037.x6cro7r2wh5aoadg@pengutronix.de> (raw)
In-Reply-To: <20241120165049.jzsveoms2unxt3m6@4VRSMR2-DT.corp.robot.car>

Hi,

On 24-11-20, Russ Weight wrote:
> On Tue, Nov 19, 2024 at 11:33:51PM +0100, Marco Felsch wrote:
> > It's no error if a driver indicates that the firmware is already
> > up-to-date and the update can be skipped.
> > 
> > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > ---
> >  drivers/base/firmware_loader/sysfs_upload.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/base/firmware_loader/sysfs_upload.c b/drivers/base/firmware_loader/sysfs_upload.c
> > index b3cbe5b156e3..44f3d8fa5e64 100644
> > --- a/drivers/base/firmware_loader/sysfs_upload.c
> > +++ b/drivers/base/firmware_loader/sysfs_upload.c
> > @@ -174,6 +174,10 @@ static void fw_upload_main(struct work_struct *work)
> >  	fw_upload_update_progress(fwlp, FW_UPLOAD_PROG_PREPARING);
> >  	ret = fwlp->ops->prepare(fwl, fwlp->data, fwlp->remaining_size);
> >  	if (ret != FW_UPLOAD_ERR_NONE) {
> > +		if (ret == FW_UPLOAD_ERR_SKIP) {
> > +			dev_info(fw_dev, "firmware already up-to-date, skip update\n");
> > +			ret = FW_UPLOAD_ERR_NONE;
> > +		}
> 
> If you change the error-code from FW_UPLOAD_ERR_SKIP to
> FW_UPLOAD_ERR_NONE, then the "skip" string provided in the previous
> patch will never be seen. There are currently no other instances where

Do we really need to set it? As explained within the commit message,
it's no error if FW_UPLOAD_ERR_SKIP is returned. The previous patch just
added all pieces which may be required later on.

> an error code requires special-case modifications to the fw_upload
> code and I don't think it is necessary to add it here.

Because at the moment no one is checking it except for the gb-beagleplay
driver. This driver prints a dev_warn() string and returns a failure.
Now the userspace needs some heuristic by parsing dmesg to check the
reason. This is rather complex and very error prone as the sting can be
changed in the future.

Therefore I added the support to have a simple error code which can be
returned by a driver. I'm open to return "skip" as error instead of
casting it to none. Both is fine for me since both allow the userspace
to easily check if the error is a 'real' error or if the fw-update was
just skipped due to already-up-to-date.

I wouldn't say that this is a special case, it is very common but no one
is performing a fw-version check. Therefore I added this to the common
code, to make it easier for driver devs.

> The dev_info() message above can be provided by the device driver
> that is using this API.
> 
> I think you can either:
> 
> (1) allow "skip" to be treated as an error. The update didn't happen...

Please see above.

> -or-
> 
> (2) The prepare function could detect the situation and set
>     a flag in the same device driver. Your write function could
>     set *written to the full data size and return without writing
>     anything. Your poll_complete handler could also return
>     FW_UPLOAD_ERR_NONE. Then you don't need to add FW_UPLOAD_ERR_SKIP
>     at all. You would get the info message from the device driver
>     and fw_upload would exit without an error.

Please see above. I don't think that this is special case and why making
the life hard for driver devs instead of having a well known fw
behaviour?

Regards,
  Marco

> 
> Thanks,
> - Russ
> 
> >  		fw_upload_set_error(fwlp, ret);
> >  		goto putdev_exit;
> >  	}
> > 
> > -- 
> > 2.39.5
> > 
> 

  reply	other threads:[~2024-11-20 17:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-19 22:33 [PATCH 0/5] Input: Add support for TouchNetix aXiom touchscreen Marco Felsch
2024-11-19 22:33 ` [PATCH 1/5] firmware_loader: expand firmware error codes with skip error Marco Felsch
2024-11-19 22:33 ` [PATCH 2/5] firmware_loader: add support to handle FW_UPLOAD_ERR_SKIP Marco Felsch
2024-11-20 16:50   ` Russ Weight
2024-11-20 17:30     ` Marco Felsch [this message]
2024-11-20 18:56       ` Russ Weight
2024-11-21  8:41         ` Marco Felsch
2024-11-19 22:33 ` [PATCH 3/5] dt-bindings: vendor-prefixes: Add TouchNetix AS Marco Felsch
2024-11-20  7:50   ` Krzysztof Kozlowski
2024-11-20  8:15     ` Marco Felsch
2024-11-21  7:47       ` Krzysztof Kozlowski
2024-11-21  8:09         ` Kamel BOUHARA
2024-11-21  8:45           ` Marco Felsch
2024-11-21 10:00             ` Krzysztof Kozlowski
2024-11-19 22:33 ` [PATCH 4/5] dt-bindings: input: Add TouchNetix axiom touchscreen Marco Felsch
2024-11-19 22:33 ` [PATCH 5/5] Input: Add TouchNetix aXiom I2C Touchscreen support Marco Felsch
2024-12-02  9:44   ` Marco Felsch
2024-12-02  9:56     ` Greg Kroah-Hartman
2024-12-02 10:02       ` Marco Felsch
2024-11-21  8:13 ` [PATCH 0/5] Input: Add support for TouchNetix aXiom touchscreen Kamel BOUHARA

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=20241120173037.x6cro7r2wh5aoadg@pengutronix.de \
    --to=m.felsch@pengutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=conor+dt@kernel.org \
    --cc=dakr@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kamel.bouhara@bootlin.com \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=russ.weight@linux.dev \
    --cc=rydberg@bitmath.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