* [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()'
@ 2019-09-12 20:44 Christophe JAILLET
2019-09-13 7:14 ` walter harms
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Christophe JAILLET @ 2019-09-12 20:44 UTC (permalink / raw)
To: mripard, mchehab
Cc: linux-media, linux-kernel, kernel-janitors, Christophe JAILLET
The 2nd parameter of 'find_first_zero_bit()' is a number of bits, not of
bytes. So use 'BITS_PER_LONG' instead of 'sizeof(lanes_used)'.
Fixes: 1fc3b37f34f6 ("media: v4l: cadence: Add Cadence MIPI-CSI2 RX driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This patch is purely speculative. Using BITS_PER_LONG looks logical to me,
but I'm not 100% sure that it is what is expected here. 'csi2rx->max_lanes'
could also be a good candidate.
---
drivers/media/platform/cadence/cdns-csi2rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c b/drivers/media/platform/cadence/cdns-csi2rx.c
index 31ace114eda1..28765ccb1b12 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -129,7 +129,7 @@ static int csi2rx_start(struct csi2rx_priv *csi2rx)
*/
for (i = csi2rx->num_lanes; i < csi2rx->max_lanes; i++) {
unsigned int idx = find_first_zero_bit(&lanes_used,
- sizeof(lanes_used));
+ BITS_PER_LONG);
set_bit(idx, &lanes_used);
reg |= CSI2RX_STATIC_CFG_DLANE_MAP(i, i + 1);
}
--
2.20.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()'
2019-09-12 20:44 [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()' Christophe JAILLET
@ 2019-09-13 7:14 ` walter harms
2019-09-13 7:57 ` Maxime Ripard
2019-09-17 7:52 ` Marc Gonzalez
2 siblings, 0 replies; 7+ messages in thread
From: walter harms @ 2019-09-13 7:14 UTC (permalink / raw)
To: Christophe JAILLET
Cc: mripard, mchehab, linux-media, linux-kernel, kernel-janitors
Am 12.09.2019 22:44, schrieb Christophe JAILLET:
> The 2nd parameter of 'find_first_zero_bit()' is a number of bits, not of
> bytes. So use 'BITS_PER_LONG' instead of 'sizeof(lanes_used)'.
>
> Fixes: 1fc3b37f34f6 ("media: v4l: cadence: Add Cadence MIPI-CSI2 RX driver")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> This patch is purely speculative. Using BITS_PER_LONG looks logical to me,
> but I'm not 100% sure that it is what is expected here. 'csi2rx->max_lanes'
> could also be a good candidate.
> ---
> drivers/media/platform/cadence/cdns-csi2rx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c b/drivers/media/platform/cadence/cdns-csi2rx.c
> index 31ace114eda1..28765ccb1b12 100644
> --- a/drivers/media/platform/cadence/cdns-csi2rx.c
> +++ b/drivers/media/platform/cadence/cdns-csi2rx.c
> @@ -129,7 +129,7 @@ static int csi2rx_start(struct csi2rx_priv *csi2rx)
> */
> for (i = csi2rx->num_lanes; i < csi2rx->max_lanes; i++) {
> unsigned int idx = find_first_zero_bit(&lanes_used,
> - sizeof(lanes_used));
> + BITS_PER_LONG);
why not CHAR_BIT*sizeof(lanes_used) ?
this would have the advantage that it is independent of future changes of lanes_used.
re,
wh
> set_bit(idx, &lanes_used);
> reg |= CSI2RX_STATIC_CFG_DLANE_MAP(i, i + 1);
> }
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()'
2019-09-12 20:44 [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()' Christophe JAILLET
2019-09-13 7:14 ` walter harms
@ 2019-09-13 7:57 ` Maxime Ripard
2019-09-16 6:28 ` Dan Carpenter
2019-09-17 7:52 ` Marc Gonzalez
2 siblings, 1 reply; 7+ messages in thread
From: Maxime Ripard @ 2019-09-13 7:57 UTC (permalink / raw)
To: Christophe JAILLET; +Cc: mchehab, linux-media, linux-kernel, kernel-janitors
Hi Christophe,
On Thu, Sep 12, 2019 at 10:44:50PM +0200, Christophe JAILLET wrote:
> The 2nd parameter of 'find_first_zero_bit()' is a number of bits, not of
> bytes. So use 'BITS_PER_LONG' instead of 'sizeof(lanes_used)'.
>
> Fixes: 1fc3b37f34f6 ("media: v4l: cadence: Add Cadence MIPI-CSI2 RX driver")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> This patch is purely speculative. Using BITS_PER_LONG looks logical to me,
> but I'm not 100% sure that it is what is expected here. 'csi2rx->max_lanes'
> could also be a good candidate.
Yeah, csi2rx->max_lanes would make more sense in that context. Could
you resend a new version?
Thanks!
Maxime
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()'
2019-09-13 7:57 ` Maxime Ripard
@ 2019-09-16 6:28 ` Dan Carpenter
2019-09-16 19:24 ` Christophe JAILLET
0 siblings, 1 reply; 7+ messages in thread
From: Dan Carpenter @ 2019-09-16 6:28 UTC (permalink / raw)
To: Maxime Ripard
Cc: Christophe JAILLET, mchehab, linux-media, linux-kernel, kernel-janitors
On Fri, Sep 13, 2019 at 09:57:09AM +0200, Maxime Ripard wrote:
> Hi Christophe,
>
> On Thu, Sep 12, 2019 at 10:44:50PM +0200, Christophe JAILLET wrote:
> > The 2nd parameter of 'find_first_zero_bit()' is a number of bits, not of
> > bytes. So use 'BITS_PER_LONG' instead of 'sizeof(lanes_used)'.
> >
> > Fixes: 1fc3b37f34f6 ("media: v4l: cadence: Add Cadence MIPI-CSI2 RX driver")
> > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> > ---
> > This patch is purely speculative. Using BITS_PER_LONG looks logical to me,
> > but I'm not 100% sure that it is what is expected here. 'csi2rx->max_lanes'
> > could also be a good candidate.
>
> Yeah, csi2rx->max_lanes would make more sense in that context. Could
> you resend a new version?
This is sort of unrelated, but for Smatch purposes the csi2rx->max_lanes
comes from the firmware in csi2rx_parse_dt() and it could be any u8
value.
I sort of wish that people would write code which was known to be
correct just from reading the kernel code, without looking at the
firmware... I guess I could mark v4l2_fwnode_endpoint_parse() as always
giving us valid data, but that still wouldn't tell us what the valid
data is. It's hard to know the right answer from a static analysis
point of view.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()'
2019-09-16 6:28 ` Dan Carpenter
@ 2019-09-16 19:24 ` Christophe JAILLET
2019-09-17 7:06 ` Dan Carpenter
0 siblings, 1 reply; 7+ messages in thread
From: Christophe JAILLET @ 2019-09-16 19:24 UTC (permalink / raw)
To: Dan Carpenter, Maxime Ripard
Cc: mchehab, linux-media, linux-kernel, kernel-janitors
Le 16/09/2019 à 08:28, Dan Carpenter a écrit :
> On Fri, Sep 13, 2019 at 09:57:09AM +0200, Maxime Ripard wrote:
>> Hi Christophe,
>>
>> On Thu, Sep 12, 2019 at 10:44:50PM +0200, Christophe JAILLET wrote:
>>> The 2nd parameter of 'find_first_zero_bit()' is a number of bits, not of
>>> bytes. So use 'BITS_PER_LONG' instead of 'sizeof(lanes_used)'.
>>>
>>> Fixes: 1fc3b37f34f6 ("media: v4l: cadence: Add Cadence MIPI-CSI2 RX driver")
>>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>>> ---
>>> This patch is purely speculative. Using BITS_PER_LONG looks logical to me,
>>> but I'm not 100% sure that it is what is expected here. 'csi2rx->max_lanes'
>>> could also be a good candidate.
>> Yeah, csi2rx->max_lanes would make more sense in that context. Could
>> you resend a new version?
> This is sort of unrelated, but for Smatch purposes the csi2rx->max_lanes
> comes from the firmware in csi2rx_parse_dt() and it could be any u8
> value.
Hi Dan,
not sure to follow you.
csi2rx_probe()
--> csi2rx_get_resources()
--> ...
dev_cfg = readl(csi2rx->base + CSI2RX_DEVICE_CFG_REG);
...
csi2rx->max_lanes = dev_cfg & 7;
if (csi2rx->max_lanes > CSI2RX_LANES_MAX) {
dev_err(&pdev->dev, "Invalid number of lanes: %u\n",
csi2rx->max_lanes);
return -EINVAL;
}
So I guess, that we can trust max_lanes because of the 'if (... >
CSI2RX_LANES_MAX)' check.
Did I miss something?
> I sort of wish that people would write code which was known to be
> correct just from reading the kernel code, without looking at the
> firmware... I guess I could mark v4l2_fwnode_endpoint_parse() as always
> giving us valid data, but that still wouldn't tell us what the valid
> data is. It's hard to know the right answer from a static analysis
> point of view.
>
> regards,
> dan carpenter
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()'
2019-09-16 19:24 ` Christophe JAILLET
@ 2019-09-17 7:06 ` Dan Carpenter
0 siblings, 0 replies; 7+ messages in thread
From: Dan Carpenter @ 2019-09-17 7:06 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Maxime Ripard, mchehab, linux-media, linux-kernel, kernel-janitors
On Mon, Sep 16, 2019 at 09:24:26PM +0200, Christophe JAILLET wrote:
> Le 16/09/2019 à 08:28, Dan Carpenter a écrit :
> > On Fri, Sep 13, 2019 at 09:57:09AM +0200, Maxime Ripard wrote:
> > > Hi Christophe,
> > >
> > > On Thu, Sep 12, 2019 at 10:44:50PM +0200, Christophe JAILLET wrote:
> > > > The 2nd parameter of 'find_first_zero_bit()' is a number of bits, not of
> > > > bytes. So use 'BITS_PER_LONG' instead of 'sizeof(lanes_used)'.
> > > >
> > > > Fixes: 1fc3b37f34f6 ("media: v4l: cadence: Add Cadence MIPI-CSI2 RX driver")
> > > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> > > > ---
> > > > This patch is purely speculative. Using BITS_PER_LONG looks logical to me,
> > > > but I'm not 100% sure that it is what is expected here. 'csi2rx->max_lanes'
> > > > could also be a good candidate.
> > > Yeah, csi2rx->max_lanes would make more sense in that context. Could
> > > you resend a new version?
> > This is sort of unrelated, but for Smatch purposes the csi2rx->max_lanes
> > comes from the firmware in csi2rx_parse_dt() and it could be any u8
> > value.
>
> Hi Dan,
>
> not sure to follow you.
>
> csi2rx_probe()
> --> csi2rx_get_resources()
> --> ...
> dev_cfg = readl(csi2rx->base + CSI2RX_DEVICE_CFG_REG);
> ...
> csi2rx->max_lanes = dev_cfg & 7;
> if (csi2rx->max_lanes > CSI2RX_LANES_MAX) {
> dev_err(&pdev->dev, "Invalid number of lanes: %u\n",
> csi2rx->max_lanes);
> return -EINVAL;
> }
>
> So I guess, that we can trust max_lanes because of the 'if (... >
> CSI2RX_LANES_MAX)' check.
>
> Did I miss something?
Ugh... I was looking at ->num_lanes and I was also just totally wrong.
Smatch parses that badly. Smatch actually parses ->max_lanes correctly
though so that's ok.
Sorry for the noise on this.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()'
2019-09-12 20:44 [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()' Christophe JAILLET
2019-09-13 7:14 ` walter harms
2019-09-13 7:57 ` Maxime Ripard
@ 2019-09-17 7:52 ` Marc Gonzalez
2 siblings, 0 replies; 7+ messages in thread
From: Marc Gonzalez @ 2019-09-17 7:52 UTC (permalink / raw)
To: Christophe JAILLET; +Cc: linux-media
On 12/09/2019 22:44, Christophe JAILLET wrote:
> Subject: [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()'
s/unsued/unused
> The 2nd parameter of 'find_first_zero_bit()' is a number of bits, not of
> bytes. So use 'BITS_PER_LONG' instead of 'sizeof(lanes_used)'.
>
> Fixes: 1fc3b37f34f6 ("media: v4l: cadence: Add Cadence MIPI-CSI2 RX driver")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-09-17 7:52 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-12 20:44 [PATCH] media: v4l: cadence: Fix how unsued lanes are handled in 'csi2rx_start()' Christophe JAILLET
2019-09-13 7:14 ` walter harms
2019-09-13 7:57 ` Maxime Ripard
2019-09-16 6:28 ` Dan Carpenter
2019-09-16 19:24 ` Christophe JAILLET
2019-09-17 7:06 ` Dan Carpenter
2019-09-17 7:52 ` Marc Gonzalez
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).