Re: linux-next: manual merge of the drivers-x86 tree with Linus' tree
On Mon, Oct 29, 2018 at 5:29 AM Stephen Rothwell wrote: > > Hi all, > > Today's linux-next merge of the drivers-x86 tree got a conflict in: > > drivers/platform/x86/intel_telemetry_debugfs.c > > between commit: > > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") > > from Linus' tree and commit: > > 1a7938a632ce ("platform/x86: intel_telemetry: Get rid of custom macro") > > from the drivers-x86 tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. Thanks! This looks correct to me. > > -- > Cheers, > Stephen Rothwell > > diff --cc drivers/platform/x86/intel_telemetry_debugfs.c > index cee08f236292,30988e31c713.. > --- a/drivers/platform/x86/intel_telemetry_debugfs.c > +++ b/drivers/platform/x86/intel_telemetry_debugfs.c > @@@ -319,8 -308,8 +308,8 @@@ static struct telemetry_debugfs_conf te > }; > > static const struct x86_cpu_id telemetry_debugfs_cpu_ids[] = { > - TELEM_DEBUGFS_CPU(INTEL_FAM6_ATOM_GOLDMONT, telem_apl_debugfs_conf), > - TELEM_DEBUGFS_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, > telem_apl_debugfs_conf), > + INTEL_CPU_FAM6(ATOM_GOLDMONT, telem_apl_debugfs_conf), > - INTEL_CPU_FAM6(ATOM_GEMINI_LAKE, telem_apl_debugfs_conf), > ++ INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, telem_apl_debugfs_conf), > {} > }; > -- With Best Regards, Andy Shevchenko
linux-next: manual merge of the drivers-x86 tree with Linus' tree
Hi all, Today's linux-next merge of the drivers-x86 tree got a conflict in: drivers/platform/x86/intel_telemetry_debugfs.c between commit: f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming") from Linus' tree and commit: 1a7938a632ce ("platform/x86: intel_telemetry: Get rid of custom macro") from the drivers-x86 tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/platform/x86/intel_telemetry_debugfs.c index cee08f236292,30988e31c713.. --- a/drivers/platform/x86/intel_telemetry_debugfs.c +++ b/drivers/platform/x86/intel_telemetry_debugfs.c @@@ -319,8 -308,8 +308,8 @@@ static struct telemetry_debugfs_conf te }; static const struct x86_cpu_id telemetry_debugfs_cpu_ids[] = { - TELEM_DEBUGFS_CPU(INTEL_FAM6_ATOM_GOLDMONT, telem_apl_debugfs_conf), - TELEM_DEBUGFS_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, telem_apl_debugfs_conf), + INTEL_CPU_FAM6(ATOM_GOLDMONT, telem_apl_debugfs_conf), - INTEL_CPU_FAM6(ATOM_GEMINI_LAKE, telem_apl_debugfs_conf), ++ INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, telem_apl_debugfs_conf), {} }; pgpwPx4zj0j1z.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the drivers-x86 tree with Linus' tree
Hi Darren, On Tue, 2 Jun 2015 20:27:50 -0700 Darren Hart wrote: > > Thanks for the heads' up. This happens because my -next branch is based on > *-rc1 > as I think was recommended at the last kernel summit. Since rc1 I sent Linus > the > G50-30, but by rc6 I didn't feel good about sending the similar G50-30 fix, so > that is in my rc1 branch. > > I am happy to rebase my -next on rc6 to avoid the conflict, but I believe the > rebase is considered poor practice. This is a fairly trivial conflict and Linus will have no trouble fixing it up as well when he merges your tree in the next window > You said no action required, but if there is something I can do to avoid this > kind of manual effort on your part (and a manual merge by Linus in the > upcoming > merge window), I'm happy to update my process to accommodate. This is fine. git rerere remembers these conflict resolutions for me, so I only have to fix them once (usually). For a more complex conflict, you might consider merging the branch that you had Linus merge (or a later -rc) with, of course, a nice explanation in the merge commit message, but in this case that would be overkill. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpiKDzycOKL1.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the drivers-x86 tree with Linus' tree
On Tue, Jun 02, 2015 at 04:07:23PM +1000, Stephen Rothwell wrote: > Hi Darren, > > Today's linux-next merge of the drivers-x86 tree got a conflict in > drivers/platform/x86/ideapad-laptop.c between commit 9b071a43553d > ("ideapad_laptop: Add Lenovo G40-30 to devices without radio switch") > from Linus' tree and commit 4fa9dabcffc8 ("ideapad_laptop: Lenovo > G50-30 fix rfkill reports wireless blocked") from the drivers-x86 tree. > > I fixed it up (see below) and can carry the fix as necessary (no action > is required). Thanks for the heads' up. This happens because my -next branch is based on *-rc1 as I think was recommended at the last kernel summit. Since rc1 I sent Linus the G50-30, but by rc6 I didn't feel good about sending the similar G50-30 fix, so that is in my rc1 branch. I am happy to rebase my -next on rc6 to avoid the conflict, but I believe the rebase is considered poor practice. You said no action required, but if there is something I can do to avoid this kind of manual effort on your part (and a manual merge by Linus in the upcoming merge window), I'm happy to update my process to accommodate. Thanks, -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drivers-x86 tree with Linus' tree
Hi Darren, Today's linux-next merge of the drivers-x86 tree got a conflict in drivers/platform/x86/ideapad-laptop.c between commit 9b071a43553d ("ideapad_laptop: Add Lenovo G40-30 to devices without radio switch") from Linus' tree and commit 4fa9dabcffc8 ("ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blocked") from the drivers-x86 tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/platform/x86/ideapad-laptop.c index b496db87bc05,1db3d2176d56.. --- a/drivers/platform/x86/ideapad-laptop.c +++ b/drivers/platform/x86/ideapad-laptop.c @@@ -830,13 -830,13 +830,20 @@@ static void ideapad_acpi_notify(acpi_ha */ static const struct dmi_system_id no_hw_rfkill_list[] = { { + .ident = "Lenovo G40-30", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo G40-30"), + }, + }, + { + .ident = "Lenovo G50-30", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo G50-30"), + }, + }, + { .ident = "Lenovo Yoga 2 11 / 13 / Pro", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), pgpxZjwim2DoL.pgp Description: OpenPGP digital signature