[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADVatmPwa+Ey-jrwZyQ4cgTX962ue1qDJxJc4PG=DoU5gVtJtw@mail.gmail.com>
Date: Fri, 6 Mar 2020 13:49:11 +0000
From: Sudip Mukherjee <sudipm.mukherjee@...il.com>
To: Joe Perches <joe@...ches.com>
Cc: Randy Dunlap <rdunlap@...radead.org>,
linux-parisc <linux-parisc@...r.kernel.org>,
"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
Helge Deller <deller@....de>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/7] parport: Use generic kernel logging styles
On Sat, Feb 29, 2020 at 7:35 PM Joe Perches <joe@...ches.com> wrote:
>
> On Sat, 2020-02-29 at 08:40 -0800, Randy Dunlap wrote:
> > On 2/28/20 12:32 AM, Joe Perches wrote:
> > > Well, if the parport logging is getting some generic fixing,
> > > here's some more generic logging fixing...
> > >
> > > Joe Perches (7):
> > > parport: Convert printk(KERN_<LEVEL> to pr_<level>(
> > > parport: Use more comon logging styles
> > > parport: daisy: Convert DPRINTK to pr_debug
> > > parport_amiga: Convert DPRINTK to pr_debug
> > > parport_mfc3: Convert DPRINTK to pr_debug
> > > parport_pc: Convert DPRINTK to pr_debug
> > > parport: Standardize use of printmode
> >
> > Reviewed-by: Randy Dunlap <rdunlap@...radead.org>
>
> btw: Sudip
>
> After this recent daisy change:
> ---------------------------------------------------------------------
>
> commit 60f8a59ddcdc7fb7c17180ba10d9c49bc91156c7
> Author: Sudip Mukherjee <sudipm.mukherjee@...il.com>
> Date: Wed Oct 16 15:45:40 2019 +0100
>
> parport: daisy: use new parport device model
>
> Modify parport daisy driver to use the new parallel port device model.
>
> Last attempt was '1aec4211204d ("parport: daisy: use new parport device
> model")' which failed as daisy was also trying to load the low level
> driver and that resulted in a deadlock.
>
> ---------------------------------------------------------------------
>
> parport_register_device is no longer in use and
> parport_register_dev_model is used instead.
Yes, I will do the cleanup, if you have not done that already. ;-)
This last change was done after a failed attempt where the previous
change had to be reverted by Linus for a regression.
So, just thought it to be safe to wait for a cycle for any regression
report before I remove the last bits.
--
Regards
Sudip
Powered by blists - more mailing lists