Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v1] driver core: Fix handling of fw_devlink=permissive
To:     Saravana Kannan <saravanak@google.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>
Cc:     kernel-team@android.com, linux-kernel@vger.kernel.org
From:   Marek Szyprowski <m.szyprowski@samsung.com>
Message-ID: <781eefdc-c926-7566-5305-bb9633e6fac0@samsung.com>
Date:   Tue, 31 Mar 2020 07:43:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
        Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200331022832.209618-1-saravanak@google.com>
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <CGME20200331022842eucas1p29e52dc93c4bd0b6e470c41aef19c9a86@eucas1p2.samsung.com>
        <20200331022832.209618-1-saravanak@google.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

On 2020-03-31 04:28, Saravana Kannan wrote:
> When commit 8375e74f2bca ("driver core: Add fw_devlink kernel
> commandline option") added fw_devlink, it didn't implement "permissive"
> mode correctly.
>
> That commit got the device links flags correct to make sure unprobed
> suppliers don't block the probing of a consumer. However, if a consumer
> is waiting for mandatory suppliers to register, that could still block a
> consumer from probing.
>
> This commit fixes that by making sure in permissive mode, all suppliers
> to a consumer are treated as a optional suppliers. So, even if a
> consumer is waiting for suppliers to register and link itself (using the
> DL_FLAG_SYNC_STATE_ONLY flag) to the supplier, the consumer is never
> blocked from probing.
>
> Fixes: 8375e74f2bca ("driver core: Add fw_devlink kernel commandline option")
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---
> Hi Marek,
>
> If you pull in this patch and then add back in my patch that created the
> boot problem for you, can you see if that fixes the boot issue for you?

Indeed, this fixes booting on my Raspberry Pi3/4 boards with linux 
next-20200327. Thanks! :)

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

>
> Thanks,
> Saravana
>
>   drivers/base/core.c | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 5e3cc1651c78..1be26a7f0866 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2370,6 +2370,11 @@ u32 fw_devlink_get_flags(void)
>   	return fw_devlink_flags;
>   }
>   
> +static bool fw_devlink_is_permissive(void)
> +{
> +	return fw_devlink_flags == DL_FLAG_SYNC_STATE_ONLY;
> +}
> +
>   /**
>    * device_add - add device to device hierarchy.
>    * @dev: device.
> @@ -2524,7 +2529,7 @@ int device_add(struct device *dev)
>   	if (fw_devlink_flags && is_fwnode_dev &&
>   	    fwnode_has_op(dev->fwnode, add_links)) {
>   		fw_ret = fwnode_call_int_op(dev->fwnode, add_links, dev);
> -		if (fw_ret == -ENODEV)
> +		if (fw_ret == -ENODEV && !fw_devlink_is_permissive())
>   			device_link_wait_for_mandatory_supplier(dev);
>   		else if (fw_ret)
>   			device_link_wait_for_optional_supplier(dev);

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland