From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Weifeng Liu <weifeng.liu.z@gmail.com>
Cc: platform-driver-x86@vger.kernel.org,
linux-serial@vger.kernel.org,
Maximilian Luz <luzmaximilian@gmail.com>,
Hans de Goede <hdegoede@redhat.com>
Subject: Re: [RFC PATCH 1/2] platform/surface: aggregator: Defer probing when serdev is not ready
Date: Thu, 2 May 2024 18:19:33 +0300 [thread overview]
Message-ID: <ZjOvBeNi-R81EX63@smile.fi.intel.com> (raw)
In-Reply-To: <20240502040255.655957-3-weifeng.liu.z@gmail.com>
On Thu, May 02, 2024 at 12:02:46PM +0800, Weifeng Liu wrote:
> This is an attempt to alleviate race conditions in the SAM driver where
> essential resources like serial device and GPIO pins are not ready at
> the time ssam_serial_hub_probe() is called. Instead of giving up
> probing, a better way would be to defer the probing by returning
> -EPROBE_DEFER, allowing the kernel try again later.
>
> However, there is no way of identifying all such cases from other real
> errors in a few days. So let's take a gradual approach identify and
> address these cases as they arise. This commit marks the initial step
> in this process.
...
> + /* The following step can fail when it's called too early before the
> + * underlying uart device is ready (in this case -ENXIO is returned).
UART
> + * Instead of simply giving up and losing everything, we can defer
> + * the probing by returning -EPROBE_DEFER so that the kernel would be
> + * able to retry later. */
/*
* Use correct style for the comments.
* Here is the example.
*/
> status = serdev_device_open(serdev);
> - if (status)
> + if (status == -ENXIO)
> + status = -EPROBE_DEFER;
> + if (status) {
> + dev_err_probe(&serdev->dev, status,
> + "failed to open serdev device\n");
> goto err_devopen;
> + }
...
Hans, not sure if it helps, but we added similar into I²C and SPI code.
2dea645ffc21 ("i2c: acpi: Return error pointers from i2c_acpi_new_device()")
9c22ec4ac27b ("spi: Return deferred probe error when controller isn't yet available")
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-05-02 15:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 4:02 [RFC PATCH 0/2] Defer probing of SAM if serdev device is not ready Weifeng Liu
2024-05-02 4:02 ` [RFC PATCH 1/2] platform/surface: aggregator: Defer probing when serdev " Weifeng Liu
2024-05-02 15:19 ` Andy Shevchenko [this message]
2024-05-02 4:02 ` [RFC PATCH 2/2] platform/surface: aggregator: Log critical errors during SAM probing Weifeng Liu
2024-05-02 15:15 ` Andy Shevchenko
2024-05-02 8:38 ` [RFC PATCH 0/2] Defer probing of SAM if serdev device is not ready Hans de Goede
2024-05-02 20:03 ` Maximilian Luz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZjOvBeNi-R81EX63@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=hdegoede@redhat.com \
--cc=linux-serial@vger.kernel.org \
--cc=luzmaximilian@gmail.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=weifeng.liu.z@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.