Re: [PATCH 04/23] dmaengine: sdxi: Feature discovery and initial configuration
From: Lynch, Nathan
Date: Mon Apr 20 2026 - 15:32:16 EST
On 4/20/2026 1:51 AM, Frank Li wrote:
> On Fri, Apr 10, 2026 at 08:07:14AM -0500, Nathan Lynch wrote:
>> After bus-specific initialization, force the SDXI function to stopped
>> state. This is the expected state from reset, but kexec or driver bugs
>> can leave a function in other states from which the initialization
>> code must be able to recover.
>
> Move this paragraph to last because this major funciton is
> "Discover via the capability register ..."
>
OK.
>> +/* Get the device to the GSV_STOP state. */
>> +static int sdxi_dev_stop(struct sdxi_dev *sdxi)
>> +{
>> + unsigned long deadline = jiffies + msecs_to_jiffies(1000);
>> + bool reset_issued = false;
>> +
>> + do {
>> + enum sdxi_fn_gsv status = sdxi_dev_gsv(sdxi);
>> +
>> + sdxi_dbg(sdxi, "%s: function state: %s\n", __func__, gsv_str(status));
>> +
>> + switch (status) {
>> + case SDXI_GSV_ACTIVE:
>> + sdxi_write_fn_gsr(sdxi, SDXI_GSRV_STOP_SF);
>> + break;
>> + case SDXI_GSV_ERROR:
>> + if (!reset_issued) {
>> + sdxi_info(sdxi,
>> + "function in error state, issuing reset\n");
>> + sdxi_write_fn_gsr(sdxi, SDXI_GSRV_RESET);
>> + reset_issued = true;
>> + } else {
>> + fsleep(1000);
>> + }
>> + break;
>> + case SDXI_GSV_STOP:
>> + return 0;
>> + case SDXI_GSV_INIT:
>> + case SDXI_GSV_STOPG_SF:
>> + case SDXI_GSV_STOPG_HD:
>> + /* transitional states, wait */
>> + sdxi_dbg(sdxi, "waiting for stop (gsv = %u)\n",
>> + status);
>> + fsleep(1000);
>> + break;
>> + default:
>> + sdxi_err(sdxi, "unknown gsv %u, giving up\n", status);
>> + return -EIO;
>> + }
>> + } while (time_before(jiffies, deadline));
>
> does read_poll_timeout() work?
Maybe so. Thanks for the pointer.
>> +#define sdxi_dbg(s, fmt, ...) dev_dbg(sdxi_to_dev(s), fmt, ## __VA_ARGS__)
>> +#define sdxi_info(s, fmt, ...) dev_info(sdxi_to_dev(s), fmt, ## __VA_ARGS__)
>> +#define sdxi_err(s, fmt, ...) dev_err(sdxi_to_dev(s), fmt, ## __VA_ARGS__)
>
> suggest direct use dev_*
OK. I guess these would be more justified if the driver were adding
SDXI-specific information such as group ID or sfunc to the messages, but
it's not as of now.