Hi Bartosz, On Tue, Dec 01 2020, Bartosz Golaszewski wrote: > On Thu, Nov 19, 2020 at 2:47 PM Baruch Siach <baruch@xxxxxxxxxx> wrote: >> On Thu, Nov 19 2020, Andrew Lunn wrote: >> >> >> @@ -1200,6 +1235,13 @@ static int mvebu_gpio_probe(struct platform_device *pdev) >> >> >> >> >> >> devm_gpiochip_add_data(&pdev->dev, &mvchip->chip, mvchip); >> >> >> >> >> >> + /* Some MVEBU SoCs have simple PWM support for GPIO lines */ >> >> >> + if (IS_ENABLED(CONFIG_PWM)) { >> >> >> + err = mvebu_pwm_probe(pdev, mvchip, id); >> >> >> + if (err) >> >> >> + return err; >> >> >> + } >> >> >> + >> >> > >> >> > The existing error handling looks odd here. Why is there no goto >> >> > err_domain when probing the PWMs fails? I wonder if this a bug from me >> >> > from a long time again? >> >> >> >> What would you release under the err_domain label? As far as I can see >> >> all resources are allocated using devres, and released automatically on >> >> failure exit. >> > >> > The IRQ domain is still registers. So once the memory is automatically >> > freed, don't we have a potential use after free? >> >> This patch moves PWM registration before IRQ domain registration for >> another reason as mentioned in the commit log. So this might >> incidentally fix the bug. >> >> Would you prefer a separate patch for that with a 'Fixes: >> 757642f9a584e8' tag? > > Baruch: does this series conflict with the fix you sent? I'm thinking > about how to take it through the next and fixes trees. Yes, It conflicts. I can send in a single series v3 of the fix along with the other patches rebased on top. Would that work for you? Thanks, baruch -- ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@xxxxxxxxxx - tel: +972.52.368.4656, http://www.tkos.co.il -