lkml.org 
[lkml]   [2015]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Patch 1/3] firmware: dmi_scan: rename dmi_table to dmi_decode_table


On 17.04.15 11:54, Jean Delvare wrote:
> Hi Ivan,
>
> On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:
>> On 16.04.15 11:35, Jean Delvare wrote:
>>> On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:
>>>> Jean, do you want me to pick this patch up or are you going to?
>>> Good question, we need to agree on a strategy.
>>>
>>> There are 3 patch sets to consider here.
>>>
>>> 1* My patch fixing the UUID ordering bug. It must go in first and
>>> immediately, as it fixes a regression and will have to be backported
>>> to stable branches.
>> ||
>> V
>>
>>> 2* 2 older patches from Ivan which are currently in your efi-next tree
>>> if I'm not mistaken. Both were based on an old tree so they do not
>>> apply cleanly on kernel v4.0, I had to fix them up manually. I have
>> They are in master tree already.
>>
>>> no idea if git would be able to merge them properly, as the fix
>>> above changed the context even more.
>> Current efi-next already merged, so you should base your patches on
>> top of last changes.
> Correct. I looked at the result and the merge looks correct. I'll turn
> my objections into fixup patches to apply on top, where still worth it.
> In particular I'll start with the ".x" revert, as it will make
> backporting the bug fix easier.
>
>>> 3* The 3 new patches from Ivan which I am reviewing now, which are not
>>> applied in any public tree AFAIK.
>> It shouldn't happen,
>> I've been verifying just now once again.
>> They are applied on top of linux_next cleanly.
>> Equal as on efi/next.
> I can't see them at
> http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=next
>
> To clarify: I do not claim that they can't be applied, I'm only saying
> they're not there yet (which is OK as they were still pending my
> review.) They do apply just fine, no problem with this.
>
>>> I don't really care who picks these patches up and sends them to Linus,
>>> but I think they should all follow the same route so that Linus has as
>>> little merge work to do as possible. So either you pick them all, or I
>>> do. If I do, you'll have to drop the 2 patches you have in efi-next.
>>> Again I'm fine either way, so please let me know what makes your life
>>> easier and let's do that.
>> I'm going to base my series
>> "firmware: dmi_scan: add SBMIOS entry point and DMI tables"
>> on top of linux next unless you have already your tree to pick up changes.
>> Please let me know, if you have one.
> I have no formal tree yet, but my current patch set can be seen at:
> http://jdelvare.nerim.net/devel/linux-3/jdelvare-dmi/
>
> First 2 patches from you are already upstream. You should rebase your
> updated patch series on top of upstream + patches 03 and 04, as they
> will go in first.
>
> Thanks,

Not sure that's a good idea to base on patches that doesn't path any
review and
no one cannot apply. At least it be good you send them that I can point
on them in
commit message.

--
Regards,
Ivan Khoronzhuk



\
 
 \ /
  Last update: 2015-04-17 12:41    [W:0.053 / U:0.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site