| Message ID | 1463075104-26924-1-git-send-email-rklein@nvidia.com |
|---|---|
| State | Accepted |
| Headers | show |
On Thursday 12 May 2016 11:15 PM, Rhyland Klein wrote: > When configuring FPS during probe, assuming a DT node is present for > FPS, the code can run into a problem with the switch statements in > max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, > in the case of chip->chip_id == MAX77620, it will set > fps_[mix|max]_period but then fall through to the default switch case > and return -EINVAL. Returning this from max77620_config_fps() will > cause probe to fail. > Thanks for fixes. Missed when converting if-else to switch. Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com> -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 5/12/2016 1:52 PM, Laxman Dewangan wrote: > > On Thursday 12 May 2016 11:15 PM, Rhyland Klein wrote: >> When configuring FPS during probe, assuming a DT node is present for >> FPS, the code can run into a problem with the switch statements in >> max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, >> in the case of chip->chip_id == MAX77620, it will set >> fps_[mix|max]_period but then fall through to the default switch case >> and return -EINVAL. Returning this from max77620_config_fps() will >> cause probe to fail. >> > > Thanks for fixes. > Missed when converting if-else to switch. > > Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com> > Lee, I noticed this hasn't been merged yet, but without it platforms using the max77620 can easily (if it has FPS nodes) fail to probe. Is there anything blocking it? -rhyland
On Fri, 27 May 2016, Rhyland Klein wrote: > On 5/12/2016 1:52 PM, Laxman Dewangan wrote: > > > > On Thursday 12 May 2016 11:15 PM, Rhyland Klein wrote: > >> When configuring FPS during probe, assuming a DT node is present for > >> FPS, the code can run into a problem with the switch statements in > >> max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, > >> in the case of chip->chip_id == MAX77620, it will set > >> fps_[mix|max]_period but then fall through to the default switch case > >> and return -EINVAL. Returning this from max77620_config_fps() will > >> cause probe to fail. > >> > > > > Thanks for fixes. > > Missed when converting if-else to switch. > > > > Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com> > > > > Lee, I noticed this hasn't been merged yet, but without it platforms > using the max77620 can easily (if it has FPS nodes) fail to probe. Is > there anything blocking it? Yes, it was sent too late in the cycle.
On 5/31/2016 3:30 AM, Lee Jones wrote: > On Fri, 27 May 2016, Rhyland Klein wrote: > >> On 5/12/2016 1:52 PM, Laxman Dewangan wrote: >>> >>> On Thursday 12 May 2016 11:15 PM, Rhyland Klein wrote: >>>> When configuring FPS during probe, assuming a DT node is present for >>>> FPS, the code can run into a problem with the switch statements in >>>> max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, >>>> in the case of chip->chip_id == MAX77620, it will set >>>> fps_[mix|max]_period but then fall through to the default switch case >>>> and return -EINVAL. Returning this from max77620_config_fps() will >>>> cause probe to fail. >>>> >>> >>> Thanks for fixes. >>> Missed when converting if-else to switch. >>> >>> Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com> >>> >> >> Lee, I noticed this hasn't been merged yet, but without it platforms >> using the max77620 can easily (if it has FPS nodes) fail to probe. Is >> there anything blocking it? > > Yes, it was sent too late in the cycle. > Ok, thanks. -rhyland
On Tue, May 31, 2016 at 08:30:22AM +0100, Lee Jones wrote: > On Fri, 27 May 2016, Rhyland Klein wrote: > > > On 5/12/2016 1:52 PM, Laxman Dewangan wrote: > > > > > > On Thursday 12 May 2016 11:15 PM, Rhyland Klein wrote: > > >> When configuring FPS during probe, assuming a DT node is present for > > >> FPS, the code can run into a problem with the switch statements in > > >> max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, > > >> in the case of chip->chip_id == MAX77620, it will set > > >> fps_[mix|max]_period but then fall through to the default switch case > > >> and return -EINVAL. Returning this from max77620_config_fps() will > > >> cause probe to fail. > > >> > > > > > > Thanks for fixes. > > > Missed when converting if-else to switch. > > > > > > Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com> > > > > > > > Lee, I noticed this hasn't been merged yet, but without it platforms > > using the max77620 can easily (if it has FPS nodes) fail to probe. Is > > there anything blocking it? > > Yes, it was sent too late in the cycle. Can we still have this for v4.7? It's clearly -rc material. Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com>
On Thu, 12 May 2016, Rhyland Klein wrote: > When configuring FPS during probe, assuming a DT node is present for > FPS, the code can run into a problem with the switch statements in > max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, > in the case of chip->chip_id == MAX77620, it will set > fps_[mix|max]_period but then fall through to the default switch case > and return -EINVAL. Returning this from max77620_config_fps() will > cause probe to fail. > > Signed-off-by: Rhyland Klein <rklein@nvidia.com> > --- > drivers/mfd/max77620.c | 2 ++ > 1 file changed, 2 insertions(+) Applied to -fixes with Thierry and Laxman's Acks. > diff --git a/drivers/mfd/max77620.c b/drivers/mfd/max77620.c > index 199d261990be..f32fbb8e8129 100644 > --- a/drivers/mfd/max77620.c > +++ b/drivers/mfd/max77620.c > @@ -203,6 +203,7 @@ static int max77620_get_fps_period_reg_value(struct max77620_chip *chip, > break; > case MAX77620: > fps_min_period = MAX77620_FPS_PERIOD_MIN_US; > + break; > default: > return -EINVAL; > } > @@ -236,6 +237,7 @@ static int max77620_config_fps(struct max77620_chip *chip, > break; > case MAX77620: > fps_max_period = MAX77620_FPS_PERIOD_MAX_US; > + break; > default: > return -EINVAL; > }
On 6/7/2016 4:05 AM, Lee Jones wrote: > On Thu, 12 May 2016, Rhyland Klein wrote: > >> When configuring FPS during probe, assuming a DT node is present for >> FPS, the code can run into a problem with the switch statements in >> max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, >> in the case of chip->chip_id == MAX77620, it will set >> fps_[mix|max]_period but then fall through to the default switch case >> and return -EINVAL. Returning this from max77620_config_fps() will >> cause probe to fail. >> >> Signed-off-by: Rhyland Klein <rklein@nvidia.com> >> --- >> drivers/mfd/max77620.c | 2 ++ >> 1 file changed, 2 insertions(+) > > Applied to -fixes with Thierry and Laxman's Acks. > I don't see this in linux-next yet (as of 20160614). Can we get this merged there to. -rhyland
On Wed, Jun 15, 2016 at 1:50 AM, Rhyland Klein <rklein@nvidia.com> wrote: > On 6/7/2016 4:05 AM, Lee Jones wrote: >> On Thu, 12 May 2016, Rhyland Klein wrote: >> >>> When configuring FPS during probe, assuming a DT node is present for >>> FPS, the code can run into a problem with the switch statements in >>> max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, >>> in the case of chip->chip_id == MAX77620, it will set >>> fps_[mix|max]_period but then fall through to the default switch case >>> and return -EINVAL. Returning this from max77620_config_fps() will >>> cause probe to fail. >>> >>> Signed-off-by: Rhyland Klein <rklein@nvidia.com> >>> --- >>> drivers/mfd/max77620.c | 2 ++ >>> 1 file changed, 2 insertions(+) >> >> Applied to -fixes with Thierry and Laxman's Acks. >> > > I don't see this in linux-next yet (as of 20160614). Can we get this > merged there to. Was about to say the same thing. FWIW: Tested-by: Alexandre Courbot <acourbot@nvidia.com> -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/mfd/max77620.c b/drivers/mfd/max77620.c index 199d261990be..f32fbb8e8129 100644 --- a/drivers/mfd/max77620.c +++ b/drivers/mfd/max77620.c @@ -203,6 +203,7 @@ static int max77620_get_fps_period_reg_value(struct max77620_chip *chip, break; case MAX77620: fps_min_period = MAX77620_FPS_PERIOD_MIN_US; + break; default: return -EINVAL; } @@ -236,6 +237,7 @@ static int max77620_config_fps(struct max77620_chip *chip, break; case MAX77620: fps_max_period = MAX77620_FPS_PERIOD_MAX_US; + break; default: return -EINVAL; }
When configuring FPS during probe, assuming a DT node is present for FPS, the code can run into a problem with the switch statements in max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, in the case of chip->chip_id == MAX77620, it will set fps_[mix|max]_period but then fall through to the default switch case and return -EINVAL. Returning this from max77620_config_fps() will cause probe to fail. Signed-off-by: Rhyland Klein <rklein@nvidia.com> --- drivers/mfd/max77620.c | 2 ++ 1 file changed, 2 insertions(+)