| Message ID | 20200922090914.20702-1-alex.dewar90@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | atomisp: Rebased fixes | expand |
Em Tue, 22 Sep 2020 10:09:07 +0100 Alex Dewar <alex.dewar90@gmail.com> escreveu: > Hi Mauro, > > I've rebased the patches now, but there is a slight hiccup. For patches 2 > and 3 of this series there will now be a conflict with commit 9289cdf39992 > ("staging: media: atomisp: Convert to GPIO descriptors") in Greg's tree. > > I'm not sure what the best way to handle this is? The merge conflicts > will be trivial (due to a conversion between the gpio_* and gpiod_* > APIs), but I could alternatively send these last two patches in via > Greg's tree if that's easier for people. Let me know what works. Maybe the best would be to re-send those after the merge window, when both patches will arrive upstream. Thanks, Mauro
On 22/09/2020 10:27, Mauro Carvalho Chehab wrote: > Em Tue, 22 Sep 2020 10:09:07 +0100 > Alex Dewar <alex.dewar90@gmail.com> escreveu: > >> Hi Mauro, >> >> I've rebased the patches now, but there is a slight hiccup. For patches 2 >> and 3 of this series there will now be a conflict with commit 9289cdf39992 >> ("staging: media: atomisp: Convert to GPIO descriptors") in Greg's tree. >> >> I'm not sure what the best way to handle this is? The merge conflicts >> will be trivial (due to a conversion between the gpio_* and gpiod_* >> APIs), but I could alternatively send these last two patches in via >> Greg's tree if that's easier for people. Let me know what works. > Maybe the best would be to re-send those after the merge window, when > both patches will arrive upstream. > > Thanks, > Mauro That sounds more sensible. I've also just noticed that I introduced a bug in the first patch when rebasing it :-/, so let's hold off on the whole series and I'll do a proper tidy and resend after the next merge window. Best, Alex
On Tue, Sep 22, 2020 at 12:02:33PM +0100, Alex Dewar wrote: > On 22/09/2020 10:27, Mauro Carvalho Chehab wrote: > > Em Tue, 22 Sep 2020 10:09:07 +0100 > > Alex Dewar <alex.dewar90@gmail.com> escreveu: > > > > > Hi Mauro, > > > > > > I've rebased the patches now, but there is a slight hiccup. For patches 2 > > > and 3 of this series there will now be a conflict with commit 9289cdf39992 > > > ("staging: media: atomisp: Convert to GPIO descriptors") in Greg's tree. > > > > > > I'm not sure what the best way to handle this is? The merge conflicts > > > will be trivial (due to a conversion between the gpio_* and gpiod_* > > > APIs), but I could alternatively send these last two patches in via > > > Greg's tree if that's easier for people. Let me know what works. > > Maybe the best would be to re-send those after the merge window, when > > both patches will arrive upstream. > > > > Thanks, > > Mauro > That sounds more sensible. I've also just noticed that I introduced a bug in > the first patch when rebasing it :-/, so let's hold off on the whole series > and I'll do a proper tidy and resend after the next merge window. Is the bug the memory leak if lm3554_platform_data_func() fails? regards, dan carpenter
[snip] > > That sounds more sensible. I've also just noticed that I introduced a bug in > > the first patch when rebasing it :-/, so let's hold off on the whole series > > and I'll do a proper tidy and resend after the next merge window. > > Is the bug the memory leak if lm3554_platform_data_func() fails? > > regards, > dan carpenter > > Nope. I put a "return ret" for the last check instead of "goto err_del_timer"... The version of this code in linux-next does the correct "if (PTR_ERR(...))" check after calling lm3554_platform_data_func(), but this patch doesn't seem to have made its way into linux-media yet. All the more reason to resend my patches after the merge window, I suppose. Best, Alex
Hi Mauro, I've rebased the patches now, but there is a slight hiccup. For patches 2 and 3 of this series there will now be a conflict with commit 9289cdf39992 ("staging: media: atomisp: Convert to GPIO descriptors") in Greg's tree. I'm not sure what the best way to handle this is? The merge conflicts will be trivial (due to a conversion between the gpio_* and gpiod_* APIs), but I could alternatively send these last two patches in via Greg's tree if that's easier for people. Let me know what works. Best, Alex