All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Robert Schlabbach <robert_s@gmx.net>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH 3/3] media: si2157: rework the firmware load logic
Date: Thu, 9 Dec 2021 12:34:22 +0100	[thread overview]
Message-ID: <20211209123422.054175cd@coco.lan> (raw)
In-Reply-To: <trinity-7e7d5b59-e213-481b-9b1b-ae9d0819a33c-1639003053723@3c-app-gmx-bap08>

Em Wed, 8 Dec 2021 23:37:33 +0100
Robert Schlabbach <robert_s@gmx.net> escreveu:

> > Loading a firmware file should not be mandatory, as devices
> > could work with an eeprom firmware, if available.
> >
> > Yet, using the eeprom firmware could lead into unpredictable
> > results, so the best is to warn about that.
> 
> As there is no proof of an EEPROM being involved in any of
> that, but strong evidence that all these devices actually have
> an embedded firmware ROM, I propose changing that to "ROM"
> instead.

Agreed. Will do such changes on patch 4, to be added to this series.

> > + bool warn_firmware_not_loaded = false;
> > unsigned int chip_id, xtal_trim;
> > - unsigned int fw_required;
> > + bool fw_required = true;
> 
> To me, this is getting too ugly. All these per-model special
> flags set somewhere in the code.
> 
> I propose removing BOTH these flags. Review of the SiLabs code
> revealed:
> 
> 1. ALL of the tuner models this driver supports have a firmware
>    patch from SiLabs available.

OK.

> 2. NONE of them seems to require it. At least all the SiLabs
>    drivers allow disabling the download.

Not true. if you check the code for si2148, it doesn't have
an option to skip firmware load.

The same is also true for other currently unsupported models.

> So my proposal is:
> 
> 1. Add firmware download support to all tuner models (this
>    means adding some new firmware file names)

Ok.

> 2. When a firmware file is not available, log an info (not
>    warning) message and proceed.

I guess this shouldn't be allowed for si2148 devices.

> None of the above boolean flags are needed then. The
> dont_load_firmware flag from the config should of course be
> kept as it is.
> 
> > + dev_warn(&client->dev, "firmware file '%s' not found. Using firmware from eeprom.\n",
> 
> Aside from using dev_info instead and changing the text to
> "ROM firmware will be used.", this would also be a duplicate
> message, as firmware_request() also logs a message when a
> requested firmware file is not found.
> 
> So I propose also changing the firmware_request() call to
> request_firmware_nowarn() instead to suppress the message
> from the firmware loader.

I can't see a request_firmware_nowarn() function, but year, the
printed messages can be simplified.

Thanks,
Mauro

  reply	other threads:[~2021-12-09 11:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01 21:10 [PATCH 2/2] media: si2157: Add optional firmware download Robert Schlabbach
2021-12-06 14:00 ` Mauro Carvalho Chehab
2021-12-07 23:07   ` Aw: " Robert Schlabbach
2021-12-08  8:52     ` Mauro Carvalho Chehab
2021-12-08 15:42       ` Aw: " Robert Schlabbach
2021-12-08 10:13   ` [PATCH 0/3] media: si2157: rework firmware load logic Mauro Carvalho Chehab
2021-12-08 10:13     ` [PATCH 1/3] media: si2157: move firmware load to a separate function Mauro Carvalho Chehab
2021-12-08 16:40       ` Robert Schlabbach
2021-12-08 17:03         ` Mauro Carvalho Chehab
2021-12-08 10:13     ` [PATCH 2/3] media: si2157: Add optional firmware download Mauro Carvalho Chehab
2021-12-08 16:45       ` Robert Schlabbach
2021-12-08 17:09         ` Mauro Carvalho Chehab
2021-12-08 10:13     ` [PATCH 3/3] media: si2157: rework the firmware load logic Mauro Carvalho Chehab
2021-12-08 22:37       ` Robert Schlabbach
2021-12-09 11:34         ` Mauro Carvalho Chehab [this message]
2021-12-09 19:37           ` Robert Schlabbach
2021-12-10  6:45             ` Mauro Carvalho Chehab

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=20211209123422.054175cd@coco.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=robert_s@gmx.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.