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;
MIME-Version: 1.0
References: <1621577323-1541-1-git-send-email-zheyuma97@gmail.com> <YKdYZF8zDGl0hxeX@kroah.com>
In-Reply-To: <YKdYZF8zDGl0hxeX@kroah.com>
From:   Zheyu Ma <zheyuma97@gmail.com>
Date:   Fri, 21 May 2021 19:15:21 +0800
Message-ID: <CAMhUBjkeXn=Yf+dsdKo5_H1Tko3Qhfr+y=9b47XtHA04k2smXg@mail.gmail.com>
Subject: Re: [PATCH v2] serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait'
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     cernekee@gmail.com, jirislaby@kernel.org,
        linux-serial@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.

Thank you for your patient comments.

Zheyu Ma