[PATCH] common: Drop linux/printk.h from common header

[Simon Glass]

Hi Tom,

On Fri, 15 Sept 2023 at 15:54, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Sep 15, 2023 at 02:01:33PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 15 Sept 2023 at 13:48, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Thu, Sep 14, 2023 at 06:21:46PM -0600, Simon Glass wrote:
> > >
> > > > This old patch was marked as deferred. Bring it back to life, to continue
> > > > towards the removal of common.h
> > > >
> > > > Move this out of the common header and include it only where needed.
> > > >
> > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > [snip]
> > > >  317 files changed, 322 insertions(+), 3 deletions(-)
> > >
> > > So, going back to the original series here, how did you determine that
> > > the files changed here need <linux/printk.h> ? I can see how to get
> > > there with some grep'ing but I think my original complaint was that we
> > > added the new header too widely.
> >
> > Basically I used ctags to get the symbols from the header file, then
> > grepped files for them. For that one, it is:
> >
> > KERN_ALERT,KERN_CONT,KERN_CRIT,KERN_DEBUG,KERN_EMERG,KERN_ERR,KERN_INFO,KERN_NOTICE,KERN_WARNING,__KERNEL_PRINTK__,__printk,no_printk,pr_alert,pr_cont,pr_crit,pr_debug,pr_debug,pr_devel,pr_devel,pr_emerg,pr_err,pr_fmt,pr_info,pr_notice,pr_warn,pr_warning,printk,printk_once
>
> OK, good.
>
> > I was a little miffed that a comment along these lines from Heinrich,
> > with no actual evidence, and no response to my follow-up questions,
> > caused the series to be dropped. It isn't easy to do these sorts of
> > clean-ups.
>
> Well, I know earlier on I had concerns and spotted specific cases where
> it was off.
>
> > A lot of files include things like net.h and image.h which bring in
> > many headers...but we should clean up those header files up too
> > (particularly image.h). So I think the standard should be: "include
> > what you use".
>
> Yes, we should first get rid of common.h and then see what we can
> remove next.

Are you OK with this patch? If so I could send another, but should
perhaps wait until this is in -next ?

Regards,
Simon