Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 21 May 2021 13:31:04 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Zheyu Ma <zheyuma97@gmail.com>
Cc:     cernekee@gmail.com, jirislaby@kernel.org,
        linux-serial@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] serial: rp2: use 'request_firmware' instead of
 'request_firmware_nowait'
Message-ID: <YKeZ+JMvlQ8YvDuw@kroah.com>
References: <1621577323-1541-1-git-send-email-zheyuma97@gmail.com>
 <YKdYZF8zDGl0hxeX@kroah.com>
 <CAMhUBjkeXn=Yf+dsdKo5_H1Tko3Qhfr+y=9b47XtHA04k2smXg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMhUBjkeXn=Yf+dsdKo5_H1Tko3Qhfr+y=9b47XtHA04k2smXg@mail.gmail.com>
Precedence: bulk

On Fri, May 21, 2021 at 07:15:21PM +0800, Zheyu Ma wrote:
> On Fri, May 21, 2021 at 2:51 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, May 21, 2021 at 06:08:43AM +0000, Zheyu Ma wrote:
> > > In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls
> > > 'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the
> > > firmware don't exists, function just return without initializing ports
> > > of 'rp2_card'. But now the interrupt handler function has been
> > > registered, and when an interrupt comes, 'rp2_uart_interrupt' may access
> > > those ports then causing NULL pointer dereference or other bugs.
> > >
> > > Because the driver does some initialization work in 'rp2_fw_cb', in
> > > order to make the driver ready to handle interrupts, 'request_firmware'
> > > should be used instead of asynchronous 'request_firmware_nowait'.
> >
> > You just now slowed down the probe function.  Are you _sure_ this is ok?
> 
> Sorry, I'm not an expert in the field, but from my point of view, the
> previous function 'rp2_fw_cb' does some initialization work that is
> not suitable for asynchronous execution. Because after these initial
> work, the driver can work normally (including preparing to handle
> interrupts).
> 
> > Do you have this hardware to test this?  If so, what is the init time
> > before and after this change?
> 
> To be honest, I don't have real hardware, I tested it with QEMU. I
> made a total of 5 attempts. Before this change, the average boot time
> required by kernel is 6.382s, the time required for insmoding this
> module is 0.139s; After this change, the average boot time required by
> kernel is 6.426s, the time required for insmoding this module is
> 0.160s. This change really slowed down the probe function.

Ok, at least you've tested it :)

I'll take a slower init over a broken init any day.  I'll go queue this
up, thanks.

greg k-h