Re: [Patch 1/3] firmware: dmi_scan: rename dmi_table to dmi_decode_table

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux