linux-kernel - Re: [PATCH v3] driver core: Add CONFIG_FW_DEVLINK_SYNC_STATE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGETcx8nSE+-GmSpFNnXGPVmuLPSy6-ex23sE=bkD--tTzE7Xg@mail.gmail.com>
Date:   Fri, 17 Mar 2023 13:47:27 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Doug Anderson <dianders@...omium.org>, kernel-team@...roid.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] driver core: Add CONFIG_FW_DEVLINK_SYNC_STATE_TIMEOUT

On Fri, Mar 17, 2023 at 11:11 AM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> On Fri, Mar 17, 2023 at 10:19:42AM -0700, Saravana Kannan wrote:
> > Add a build time equivalent of fw_devlink.sync_state=timeout so that
> > board specific kernels could enable it and not have to deal with setting
> > or cluttering the kernel commandline.
> >
> > Cc: Doug Anderson <dianders@...omium.org>
> > Signed-off-by: Saravana Kannan <saravanak@...gle.com>
> > ---
> >  drivers/base/Kconfig | 12 ++++++++++++
> >  drivers/base/core.c  |  5 +++++
> >  2 files changed, 17 insertions(+)
> >
> > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> > index 6f04b831a5c0..2b8fd6bb7da0 100644
> > --- a/drivers/base/Kconfig
> > +++ b/drivers/base/Kconfig
> > @@ -230,4 +230,16 @@ config GENERIC_ARCH_NUMA
> >         Enable support for generic NUMA implementation. Currently, RISC-V
> >         and ARM64 use it.
> >
> > +config FW_DEVLINK_SYNC_STATE_TIMEOUT
> > +     bool "sync_state() behavior defaults to timeout instead of strict"
> > +     help
> > +       This is build time equivalent of adding kernel command line parameter
> > +       "fw_devlink.sync_state=timeout". Give up waiting on consumers and
> > +       call sync_state() on any devices that haven't yet received their
> > +       sync_state() calls after deferred_probe_timeout has expired or by
> > +       late_initcall() if !CONFIG_MODULES. You should almost always want to
> > +       select N here unless you have already successfully tested with the
> > +       command line option on every system/board your kernel is expected to
> > +       work on.
> > +
> >  endmenu
> > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > index fe74a786e2c3..adc81871829f 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -1672,7 +1672,12 @@ early_param("fw_devlink.strict", fw_devlink_strict_setup);
> >  #define FW_DEVLINK_SYNC_STATE_STRICT 0
> >  #define FW_DEVLINK_SYNC_STATE_TIMEOUT        1
> >
> > +#ifndef CONFIG_FW_DEVLINK_SYNC_STATE_TIMEOUT
> >  static int fw_devlink_sync_state;
> > +#else
> > +static int fw_devlink_sync_state = FW_DEVLINK_SYNC_STATE_TIMEOUT;
> > +#endif
> > +
> >  static int __init fw_devlink_sync_state_setup(char *arg)
> >  {
> >       if (!arg)
> > --
> > 2.40.0.rc2.332.ga46443480c-goog
> >
>
> Hi,
>
> This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
> a patch that has triggered this response.  He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
> created.  Hopefully you will not take offence and will fix the problem
> in your patch and resubmit it so that it can be accepted into the Linux
> kernel tree.
>
> You are receiving this message because of the following common error(s)
> as indicated below:
>
> - This looks like a new version of a previously submitted patch, but you
>   did not list below the --- line any changes from the previous version.
>   Please read the section entitled "The canonical patch format" in the
>   kernel file, Documentation/process/submitting-patches.rst for what
>   needs to be done here to properly describe this.

Ok, I'll send out a v4 with this added in. :)

-Saravana

>
> If you wish to discuss this problem further, or you have questions about
> how to resolve this issue, please feel free to respond to this email and
> Greg will reply once he has dug out from the pending patches received
> from other developers.
>
> thanks,
>
> greg k-h's patch email bot