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;
From:   Fabien DESSENNE <fabien.dessenne@st.com>
To:     Pavel Machek <pavel@denx.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>,
        Hugues FRUCHET <hugues.fruchet@st.com>,
        Hans Verkuil <hverkuil-cisco@xs4all.nl>,
        "Mauro Carvalho Chehab" <mchehab+samsung@kernel.org>,
        Sasha Levin <sashal@kernel.org>
Subject: Re: [PATCH 4.19 070/276] media: stm32-dcmi: return appropriate error
 codes during probe
Thread-Topic: [PATCH 4.19 070/276] media: stm32-dcmi: return appropriate error
 codes during probe
Thread-Index: AQHVFpYZYgpvcJwbS0WT+YmI1l46AKaExGkAgAAFjoA=
Date:   Fri, 31 May 2019 08:39:18 +0000
Message-ID: <180d29ba-74cc-08ae-35f6-cb58c1d79297@st.com>
References: <20190530030523.133519668@linuxfoundation.org>
 <20190530030530.607146114@linuxfoundation.org> <20190531081924.GA19447@amd>
In-Reply-To: <20190531081924.GA19447@amd>
Accept-Language: fr-FR, en-US
Content-Language: en-US
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.0
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.75.127.45]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <BE3CF23C01D54B46B16CCA9520F56C74@st.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-05-31_05:,,
 signatures=0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Pavel


On 31/05/2019 10:19 AM, Pavel Machek wrote:
> Hi!
>
>> [ Upstream commit b5b5a27bee5884860798ffd0f08e611a3942064b ]
>>
>> During probe, return the provided errors value instead of -ENODEV.
>> This allows the driver to be deferred probed if needed.
> This is not correct AFAICT.


The driver gets defer probed *if needed*. *if needed* is for the case=20
where platform_get_irq returns -EPROBE_DEFER, which happens if the irq=20
controller is not ready yet.

Of course, for the other cases, the probe would just fail.


>
>
>> --- a/drivers/media/platform/stm32/stm32-dcmi.c
>> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
>> @@ -1673,8 +1673,9 @@ static int dcmi_probe(struct platform_device *pdev=
)
>>  =20
>>   	irq =3D platform_get_irq(pdev, 0);
>>   	if (irq <=3D 0) {
>> -		dev_err(&pdev->dev, "Could not get irq\n");
>> -		return -ENODEV;
>> +		if (irq !=3D -EPROBE_DEFER)
>> +			dev_err(&pdev->dev, "Could not get irq\n");
>> +		return irq;
>>   	}
>>  =20
>>   	dcmi->res =3D platform_get_resource(pdev, IORESOURCE_MEM, 0);
> irq =3D=3D 0 is clearly means error here, but will be interpretted as
> success when returned to the caller.


Thank you for pointing this.

It shall be 'return irq ? irq : -ENXIO;'=A0 I will send a fix for this.


>
> As device is not initialized at that point, I'd expect some kind of
> crash later.
> 									Pavel=