mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Sebastian Reichel <sebastian.reichel@collabora.co.uk>,
	Kees Cook <keescook@chromium.org>,
	Hans de Goede <hdegoede@redhat.com>,
	andresx7@gmail.com, torvalds@linux-foundation.org
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Vinod Koul" <vkoul@kernel.org>,
	dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH 0/2] Avoid firmware warning in imx-sdma
Date: Thu, 28 Jun 2018 05:13:32 +0200	[thread overview]
Message-ID: <20180628031332.GE21242@wotan.suse.de> (raw)
In-Reply-To: <20180622144951.17464-1-sebastian.reichel@collabora.co.uk>

On Fri, Jun 22, 2018 at 04:49:49PM +0200, Sebastian Reichel wrote:
> Subject: Avoid firmware warning in imx-sdma
> 
> Hi,
> 
> I grabbed the first patch from patchwork from an 2017 patch series. As far as I
> could see, their usecase vanished due to switching to sync FW API (that already
> supports NOWARN). This series fixes a kernel warning in imx-sdma driver, which
> works fine with ROM firmware (and already prints an info message about ROM
> firmware being used due to missing firmware file). This has been tested on
> arch/arm/boot/dts/imx53-ppd.dts.

Please read these threads about the state of affairs with respect to data
driven Vs functional API evolution on the firmware API [0] and my latests
recommendation for what to do for the async firmware API [1].

Then, recently I've come to realize that perhaps the best thing actually
is to *break* the cycle for the async API and make it more functional driven.

For instance the call to not use the uevent should be made a separate
call as only two drivers use it:

  o CONFIG_LEDS_LP55XX_COMMON
  o CONFIG_DELL_RBU

Using a struct would make it data driven. A flags approach would make it
more flexible and I although I think this is reasonable, if we wanted
to match the sync API, we'd have one call per variation.

It is therefore subjective whether or not to keep a flags based mechanism
for the async API or not. If we at least use flags, we'd just break away
from the sync approach.

I'll let Kees and Greg pick and choose how they would prefer to see this
broken down now as I am off on vacation today and won't be back until the
middle of next month.
                                                                                
[0] https://lkml.kernel.org/r/20180421173650.GW14440@wotan.suse.de              
[1] https://lkml.kernel.org/r/20180422202609.GX14440@wotan.suse.de 

  Luis

      parent reply	other threads:[~2018-06-28  3:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-22 14:49 Sebastian Reichel
2018-06-22 14:49 ` [PATCH 1/2] firmware: add more flexible request_firmware_async function Sebastian Reichel
2018-06-23  0:52   ` kbuild test robot
2018-06-22 14:49 ` [PATCH 2/2] dmaengine: imx-sdma: request firmware with FW_OPT_NO_WARN Sebastian Reichel
2018-06-28  3:13 ` Luis R. Rodriguez [this message]

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=20180628031332.GE21242@wotan.suse.de \
    --to=mcgrof@kernel.org \
    --cc=andresx7@gmail.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafal@milecki.pl \
    --cc=sebastian.reichel@collabora.co.uk \
    --cc=torvalds@linux-foundation.org \
    --cc=vkoul@kernel.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

all inboxes | Powered by JetHome®