| Message ID | 20200921215359.45003-1-alex.dewar90@gmail.com |
|---|---|
| Headers | show |
| Series | atomisp: Fixes and cleanups | expand |
Em Mon, 21 Sep 2020 22:53:49 +0100 Alex Dewar <alex.dewar90@gmail.com> escreveu: > Hi Mauro, > > Over the last month I've sent a few scattered patches to fix various > warnings from static analysers, but they seem to have fallen through the > cracks? I'm reposting them here as a series to make them easier to > review. If you do have any feedback that'd be great :) Usually, there's no need to re-send the patches, as we pick them from a patchwork queue. However, only one of the patches actually applied against the linux-media tree. So, please rebased the remaining patches on the top of it. Thanks, Mauro
On 22/09/2020 09:11, Mauro Carvalho Chehab wrote: > Em Mon, 21 Sep 2020 22:53:49 +0100 > Alex Dewar <alex.dewar90@gmail.com> escreveu: > >> Hi Mauro, >> >> Over the last month I've sent a few scattered patches to fix various >> warnings from static analysers, but they seem to have fallen through the >> cracks? I'm reposting them here as a series to make them easier to >> review. If you do have any feedback that'd be great :) > Usually, there's no need to re-send the patches, as we pick them > from a patchwork queue. > > However, only one of the patches actually applied against the > linux-media tree. > > So, please rebased the remaining patches on the top of it. > > Thanks, > Mauro That's weird. They applied cleanly against yesterday's linux-next for me... I'll rebase on linux-media and resend. Best, Alex
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