* linux-next: manual merge of the uuid tree with the arm64 tree @ 2017-06-16 5:21 Stephen Rothwell 2017-06-16 6:09 ` Christoph Hellwig 2017-06-19 9:19 ` Will Deacon 0 siblings, 2 replies; 17+ messages in thread From: Stephen Rothwell @ 2017-06-16 5:21 UTC (permalink / raw) To: Christoph Hellwig, Catalin Marinas Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andy Shevchenko, Tyler Baicar, Will Deacon Hi all, Today's linux-next merge of the uuid tree got conflicts in: drivers/acpi/apei/ghes.c include/uapi/linux/uuid.h between commits: f4dccde3f9b9 ("ras: acpi/apei: cper: add support for generic data v3 structure") 476e4940c251 ("ras: acpi / apei: generate trace event for unrecognized CPER section") 8a0456ea3dec ("trace, ras: add ARM processor error trace event") from the arm64 tree and commit: 60927bc31436 ("uuid: remove uuid_be defintions from the uapi header") f9727a17db9b ("uuid: rename uuid types") 5b53696a30d5 ("ACPI / APEI: Switch to use new generic UUID API") from the uuid tree. I really can't fix this up, so can you guys get together and sort this out, please. For today, I have just dropped the uuid tree, sorry. -- Cheers, Stephen Rothwell ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-16 5:21 linux-next: manual merge of the uuid tree with the arm64 tree Stephen Rothwell @ 2017-06-16 6:09 ` Christoph Hellwig 2017-06-19 0:28 ` Stephen Rothwell 2017-06-19 9:19 ` Will Deacon 1 sibling, 1 reply; 17+ messages in thread From: Christoph Hellwig @ 2017-06-16 6:09 UTC (permalink / raw) To: Stephen Rothwell Cc: Christoph Hellwig, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List, Andy Shevchenko, Tyler Baicar, Will Deacon The uuid-types tree in uuid.git is immutable, please work on top of that for ACPI - in fact ACPI was on the of trees we explicitly did this for. So don't sneak any acpi bits in through the arm64 tree. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-16 6:09 ` Christoph Hellwig @ 2017-06-19 0:28 ` Stephen Rothwell 0 siblings, 0 replies; 17+ messages in thread From: Stephen Rothwell @ 2017-06-19 0:28 UTC (permalink / raw) To: Christoph Hellwig Cc: Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List, Andy Shevchenko, Tyler Baicar, Will Deacon Hi all, On Fri, 16 Jun 2017 08:09:01 +0200 Christoph Hellwig <hch@lst.de> wrote: > > The uuid-types tree in uuid.git is immutable, please work on top > of that for ACPI - in fact ACPI was on the of trees we explicitly did this > for. So don't sneak any acpi bits in through the arm64 tree. OK, I have moved the merging of the uuid tree to very early so the conflicts against the arm64 tree appear when I merge the arm64 tree. For today, I have merged the arm64 tree from next-20170615 (head commit c484f2564db1 "arm64: kconfig: allow support for memory failure handling"). -- Cheers, Stephen Rothwell ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-16 5:21 linux-next: manual merge of the uuid tree with the arm64 tree Stephen Rothwell 2017-06-16 6:09 ` Christoph Hellwig @ 2017-06-19 9:19 ` Will Deacon 2017-06-19 10:06 ` Andy Shevchenko 1 sibling, 1 reply; 17+ messages in thread From: Will Deacon @ 2017-06-19 9:19 UTC (permalink / raw) To: Stephen Rothwell Cc: Christoph Hellwig, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List, Andy Shevchenko, Tyler Baicar Hi Stephen, Christoph, Tyler, On Fri, Jun 16, 2017 at 03:21:36PM +1000, Stephen Rothwell wrote: > Today's linux-next merge of the uuid tree got conflicts in: > > drivers/acpi/apei/ghes.c > include/uapi/linux/uuid.h > > between commits: > > f4dccde3f9b9 ("ras: acpi/apei: cper: add support for generic data v3 structure") > 476e4940c251 ("ras: acpi / apei: generate trace event for unrecognized CPER section") > 8a0456ea3dec ("trace, ras: add ARM processor error trace event") > > from the arm64 tree and commit: > > 60927bc31436 ("uuid: remove uuid_be defintions from the uapi header") > f9727a17db9b ("uuid: rename uuid types") > 5b53696a30d5 ("ACPI / APEI: Switch to use new generic UUID API") > > from the uuid tree. > > I really can't fix this up, so can you guys get together and sort this > out, please. > > For today, I have just dropped the uuid tree, sorry. Apologies for this: I've just dropped the offending merge from the arm64 tree so you can include the uuid tree in -next again. Tyler: please rebase your patches on top of Christoph's uuid-types branch and send me a new series. Will ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-19 9:19 ` Will Deacon @ 2017-06-19 10:06 ` Andy Shevchenko 2017-06-19 10:22 ` Will Deacon 0 siblings, 1 reply; 17+ messages in thread From: Andy Shevchenko @ 2017-06-19 10:06 UTC (permalink / raw) To: Will Deacon, Stephen Rothwell Cc: Christoph Hellwig, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List, Tyler Baicar On Mon, 2017-06-19 at 10:19 +0100, Will Deacon wrote: > Hi Stephen, Christoph, Tyler, > On Fri, Jun 16, 2017 at 03:21:36PM +1000, Stephen Rothwell wrote: > > > Apologies for this: I've just dropped the offending merge from the > arm64 > tree so you can include the uuid tree in -next again. > > Tyler: please rebase your patches on top of Christoph's uuid-types > branch > and send me a new series. To have better coordination, please, look at my WIP branch regarding UUID stuff: http://bitbucket.org/andy-shev/linux/branch/topic%2Fuuid -- Andy Shevchenko <andriy.shevchenko@linux.intel.com> Intel Finland Oy ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-19 10:06 ` Andy Shevchenko @ 2017-06-19 10:22 ` Will Deacon 2017-06-19 18:41 ` Baicar, Tyler 0 siblings, 1 reply; 17+ messages in thread From: Will Deacon @ 2017-06-19 10:22 UTC (permalink / raw) To: Andy Shevchenko Cc: Stephen Rothwell, Christoph Hellwig, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List, Tyler Baicar On Mon, Jun 19, 2017 at 01:06:30PM +0300, Andy Shevchenko wrote: > On Mon, 2017-06-19 at 10:19 +0100, Will Deacon wrote: > > Hi Stephen, Christoph, Tyler, > > On Fri, Jun 16, 2017 at 03:21:36PM +1000, Stephen Rothwell wrote: > > > > > > Apologies for this: I've just dropped the offending merge from the > > arm64 > > tree so you can include the uuid tree in -next again. > > > > Tyler: please rebase your patches on top of Christoph's uuid-types > > branch > > and send me a new series. > > To have better coordination, please, look at my WIP branch regarding > UUID stuff: > http://bitbucket.org/andy-shev/linux/branch/topic%2Fuuid That link doesn't work for me. Is there anything specific Tyler should be paying attention to on that branch? Will ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-19 10:22 ` Will Deacon @ 2017-06-19 18:41 ` Baicar, Tyler 2017-06-19 19:22 ` Baicar, Tyler 2017-06-20 8:40 ` Will Deacon 0 siblings, 2 replies; 17+ messages in thread From: Baicar, Tyler @ 2017-06-19 18:41 UTC (permalink / raw) To: Will Deacon, Andy Shevchenko Cc: Stephen Rothwell, Christoph Hellwig, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List On 6/19/2017 4:22 AM, Will Deacon wrote: > On Mon, Jun 19, 2017 at 01:06:30PM +0300, Andy Shevchenko wrote: >> On Mon, 2017-06-19 at 10:19 +0100, Will Deacon wrote: >>> Hi Stephen, Christoph, Tyler, >>> On Fri, Jun 16, 2017 at 03:21:36PM +1000, Stephen Rothwell wrote: >>> Apologies for this: I've just dropped the offending merge from the >>> arm64 >>> tree so you can include the uuid tree in -next again. >>> >>> Tyler: please rebase your patches on top of Christoph's uuid-types >>> branch >>> and send me a new series. >> To have better coordination, please, look at my WIP branch regarding >> UUID stuff: >> http://bitbucket.org/andy-shev/linux/branch/topic%2Fuuid > That link doesn't work for me. Is there anything specific Tyler should be > paying attention to on that branch? That link doesn't work for me either, but I assume it is the topic/uuid branch here: https://bitbucket.org/andy-shev/linux/branches/ I'll rebase my patches on top of this branch and send them to you Will. Thanks, Tyler -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-19 18:41 ` Baicar, Tyler @ 2017-06-19 19:22 ` Baicar, Tyler 2017-06-20 8:40 ` Will Deacon 1 sibling, 0 replies; 17+ messages in thread From: Baicar, Tyler @ 2017-06-19 19:22 UTC (permalink / raw) To: Will Deacon, Andy Shevchenko Cc: Stephen Rothwell, Christoph Hellwig, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List On 6/19/2017 12:41 PM, Baicar, Tyler wrote: > On 6/19/2017 4:22 AM, Will Deacon wrote: >> On Mon, Jun 19, 2017 at 01:06:30PM +0300, Andy Shevchenko wrote: >>> On Mon, 2017-06-19 at 10:19 +0100, Will Deacon wrote: >>>> Hi Stephen, Christoph, Tyler, >>>> On Fri, Jun 16, 2017 at 03:21:36PM +1000, Stephen Rothwell wrote: >>>> Apologies for this: I've just dropped the offending merge from the >>>> arm64 >>>> tree so you can include the uuid tree in -next again. >>>> >>>> Tyler: please rebase your patches on top of Christoph's uuid-types >>>> branch >>>> and send me a new series. >>> To have better coordination, please, look at my WIP branch regarding >>> UUID stuff: >>> http://bitbucket.org/andy-shev/linux/branch/topic%2Fuuid >> That link doesn't work for me. Is there anything specific Tyler >> should be >> paying attention to on that branch? > That link doesn't work for me either, but I assume it is the > topic/uuid branch here: > > https://bitbucket.org/andy-shev/linux/branches/ > > I'll rebase my patches on top of this branch and send them to you Will. I'm trying to rebase my patches; however, this branch does not compile as is. It seems that the UUID changes in the APEI code are wrong: drivers/acpi/apei/ghes.c: In function 'ghes_do_proc': drivers/acpi/apei/ghes.c:438:12: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] sec_type = gdata->section_type; ^ I am just trying to compile the tip code in the topic/uuid branch from above. Tip commit is currently: commit ab4ea80ef9dc97878d60a4a3487fe9dacd0e6b3a Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: Fri Apr 21 16:36:06 2017 +0300 ASoC: Intel: Skylake: Use recently introduced uuid_le_cmp_p{p}() -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-19 18:41 ` Baicar, Tyler 2017-06-19 19:22 ` Baicar, Tyler @ 2017-06-20 8:40 ` Will Deacon 2017-06-20 8:43 ` Christoph Hellwig 1 sibling, 1 reply; 17+ messages in thread From: Will Deacon @ 2017-06-20 8:40 UTC (permalink / raw) To: Baicar, Tyler Cc: Andy Shevchenko, Stephen Rothwell, Christoph Hellwig, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List On Mon, Jun 19, 2017 at 12:41:38PM -0600, Baicar, Tyler wrote: > On 6/19/2017 4:22 AM, Will Deacon wrote: > >On Mon, Jun 19, 2017 at 01:06:30PM +0300, Andy Shevchenko wrote: > >>On Mon, 2017-06-19 at 10:19 +0100, Will Deacon wrote: > >>>Hi Stephen, Christoph, Tyler, > >>>On Fri, Jun 16, 2017 at 03:21:36PM +1000, Stephen Rothwell wrote: > >>>Apologies for this: I've just dropped the offending merge from the > >>>arm64 > >>>tree so you can include the uuid tree in -next again. > >>> > >>>Tyler: please rebase your patches on top of Christoph's uuid-types > >>>branch > >>>and send me a new series. > >>To have better coordination, please, look at my WIP branch regarding > >>UUID stuff: > >>http://bitbucket.org/andy-shev/linux/branch/topic%2Fuuid > >That link doesn't work for me. Is there anything specific Tyler should be > >paying attention to on that branch? > That link doesn't work for me either, but I assume it is the topic/uuid > branch here: > > https://bitbucket.org/andy-shev/linux/branches/ > > I'll rebase my patches on top of this branch and send them to you Will. The conflict in -next came from Christoph's tree: http://git.infradead.org/users/hch/uuid.git/heads hence why I mentioned the uuid-types branch above. It's not clear to me how Andy's branch fits in with this. Will ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-20 8:40 ` Will Deacon @ 2017-06-20 8:43 ` Christoph Hellwig 2017-06-20 8:47 ` Andy Shevchenko 0 siblings, 1 reply; 17+ messages in thread From: Christoph Hellwig @ 2017-06-20 8:43 UTC (permalink / raw) To: Will Deacon Cc: Baicar, Tyler, Andy Shevchenko, Stephen Rothwell, Christoph Hellwig, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List On Tue, Jun 20, 2017 at 09:40:08AM +0100, Will Deacon wrote: > > >>To have better coordination, please, look at my WIP branch regarding > > >>UUID stuff: > > >>http://bitbucket.org/andy-shev/linux/branch/topic%2Fuuid > > >That link doesn't work for me. Is there anything specific Tyler should be > > >paying attention to on that branch? > > That link doesn't work for me either, but I assume it is the topic/uuid > > branch here: > > > > https://bitbucket.org/andy-shev/linux/branches/ > > > > I'll rebase my patches on top of this branch and send them to you Will. > > The conflict in -next came from Christoph's tree: > > http://git.infradead.org/users/hch/uuid.git/heads > > hence why I mentioned the uuid-types branch above. It's not clear to me > how Andy's branch fits in with this. I think Andy is preparing various uuid conversion in it and wanted to make sure you don't do any work he already did or which conflicts with this work. For now please just base it on my uuid-types tree. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-20 8:43 ` Christoph Hellwig @ 2017-06-20 8:47 ` Andy Shevchenko 2017-06-20 18:13 ` Baicar, Tyler 0 siblings, 1 reply; 17+ messages in thread From: Andy Shevchenko @ 2017-06-20 8:47 UTC (permalink / raw) To: Christoph Hellwig, Will Deacon Cc: Baicar, Tyler, Stephen Rothwell, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List On Tue, 2017-06-20 at 10:43 +0200, Christoph Hellwig wrote: > On Tue, Jun 20, 2017 at 09:40:08AM +0100, Will Deacon wrote: > > > > > To have better coordination, please, look at my WIP branch > > > > > regarding > > > > > UUID stuff: > > > > > http://bitbucket.org/andy-shev/linux/branch/topic%2Fuuid > > > > > > > > That link doesn't work for me. Is there anything specific Tyler > > > > should be > > > > paying attention to on that branch? > > > > > > That link doesn't work for me either, but I assume it is the > > > topic/uuid > > > branch here: > > > > > > https://bitbucket.org/andy-shev/linux/branches/ > > > > > > I'll rebase my patches on top of this branch and send them to you > > > Will. > > > > The conflict in -next came from Christoph's tree: > > > > http://git.infradead.org/users/hch/uuid.git/heads > > > > hence why I mentioned the uuid-types branch above. It's not clear to > > me > > how Andy's branch fits in with this. > > I think Andy is preparing various uuid conversion in it and wanted to > make sure you don't do any work he already did or which conflicts with > this work. Thanks, Christoph, that's correct. > > For now please just base it on my uuid-types tree. Yeah, this is safest option for now. -- Andy Shevchenko <andriy.shevchenko@linux.intel.com> Intel Finland Oy ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-20 8:47 ` Andy Shevchenko @ 2017-06-20 18:13 ` Baicar, Tyler 2017-06-20 18:17 ` Andy Shevchenko 2017-06-20 18:20 ` Will Deacon 0 siblings, 2 replies; 17+ messages in thread From: Baicar, Tyler @ 2017-06-20 18:13 UTC (permalink / raw) To: Andy Shevchenko, Christoph Hellwig, Will Deacon Cc: Stephen Rothwell, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List On 6/20/2017 2:47 AM, Andy Shevchenko wrote: > On Tue, 2017-06-20 at 10:43 +0200, Christoph Hellwig wrote: >> On Tue, Jun 20, 2017 at 09:40:08AM +0100, Will Deacon wrote: >>>>>> To have better coordination, please, look at my WIP branch >>>>>> regarding >>>>>> UUID stuff: >>>>>> http://bitbucket.org/andy-shev/linux/branch/topic%2Fuuid >>>>> That link doesn't work for me. Is there anything specific Tyler >>>>> should be >>>>> paying attention to on that branch? >>>> That link doesn't work for me either, but I assume it is the >>>> topic/uuid >>>> branch here: >>>> >>>> https://bitbucket.org/andy-shev/linux/branches/ >>>> >>>> I'll rebase my patches on top of this branch and send them to you >>>> Will. >>> The conflict in -next came from Christoph's tree: >>> >>> http://git.infradead.org/users/hch/uuid.git/heads >>> >>> hence why I mentioned the uuid-types branch above. It's not clear to >>> me >>> how Andy's branch fits in with this. >> I think Andy is preparing various uuid conversion in it and wanted to >> make sure you don't do any work he already did or which conflicts with >> this work. > Thanks, Christoph, that's correct. > >> For now please just base it on my uuid-types tree. > Yeah, this is safest option for now. > Will, I have sent you the rebased patches. I took Christoph's uuid-types tree and added this patch onto it: 7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types") And then added my patches onto that. This will hopefully now avoid conflicts with any other patch. Andy, The patch that was causing compilation failures on your branch was: 22e31da efi: Switch to use new generic UUID API The failures were because of the removed guid_t * casts. Note that this patch will conflict with my patch series, so you may want to rebase it onto linux-next once they are in. Thanks, Tyler -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-20 18:13 ` Baicar, Tyler @ 2017-06-20 18:17 ` Andy Shevchenko 2017-06-20 18:20 ` Will Deacon 1 sibling, 0 replies; 17+ messages in thread From: Andy Shevchenko @ 2017-06-20 18:17 UTC (permalink / raw) To: Baicar, Tyler, Christoph Hellwig, Will Deacon Cc: Stephen Rothwell, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List On Tue, 2017-06-20 at 12:13 -0600, Baicar, Tyler wrote: > On 6/20/2017 2:47 AM, Andy Shevchenko wrote: > > On Tue, 2017-06-20 at 10:43 +0200, Christoph Hellwig wrote: > > > > Andy, > > The patch that was causing compilation failures on your branch was: > > 22e31da efi: Switch to use new generic UUID API > > The failures were because of the removed guid_t * casts. Note that > this > patch will conflict with my patch series, so you may want to rebase > it > onto linux-next once they are in. Thanks for pointing out. That branch is WIP, it's okay it fails to compile. -- Andy Shevchenko <andriy.shevchenko@linux.intel.com> Intel Finland Oy ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-20 18:13 ` Baicar, Tyler 2017-06-20 18:17 ` Andy Shevchenko @ 2017-06-20 18:20 ` Will Deacon 2017-06-20 18:26 ` Baicar, Tyler 1 sibling, 1 reply; 17+ messages in thread From: Will Deacon @ 2017-06-20 18:20 UTC (permalink / raw) To: Baicar, Tyler Cc: Andy Shevchenko, Christoph Hellwig, Stephen Rothwell, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List On Tue, Jun 20, 2017 at 12:13:13PM -0600, Baicar, Tyler wrote: > I have sent you the rebased patches. I took Christoph's uuid-types tree and > added this patch onto it: > > 7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types") > > And then added my patches onto that. This will hopefully now avoid conflicts > with any other patch. No, patch 6 fails to apply: On Tue, Jun 20, 2017 at 12:07:27PM -0600, Tyler Baicar wrote: > diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c > index 7e3ddbe..81ebb9b 100644 > --- a/drivers/acpi/apei/ghes.c > +++ b/drivers/acpi/apei/ghes.c > @@ -116,11 +116,7 @@ static inline bool is_hest_type_generic_v2(struct ghes *ghes) > * Two virtual pages are used, one for IRQ/PROCESS context, the other for > * NMI context (optionally). > */ > -#ifdef CONFIG_HAVE_ACPI_APEI_NMI > #define GHES_IOREMAP_PAGES 2 > -#else > -#define GHES_IOREMAP_PAGES 1 > -#endif > #define GHES_IOREMAP_IRQ_PAGE(base) (base) > #define GHES_IOREMAP_NMI_PAGE(base) ((base) + PAGE_SIZE) > > @@ -159,10 +155,14 @@ static void ghes_ioremap_exit(void) > static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn) > { > unsigned long vaddr; > + phys_addr_t paddr; > + pgprot_t prot; > > vaddr = (unsigned long)GHES_IOREMAP_NMI_PAGE(ghes_ioremap_area->addr); > - ioremap_page_range(vaddr, vaddr + PAGE_SIZE, > - pfn << PAGE_SHIFT, PAGE_KERNEL); > + > + paddr = pfn << PAGE_SHIFT; > + prot = arch_apei_get_mem_attribute(paddr); > + ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot); > > return (void __iomem *)vaddr; > } > @@ -774,6 +774,50 @@ static int ghes_notify_hed(struct notifier_block *this, unsigned long event, > .notifier_call = ghes_notify_hed, In Christoph's tree, this line is: .notifier_call = ghes_notify_sci, http://git.infradead.org/users/hch/uuid.git/blob/refs/heads/uuid-types:/drivers/acpi/apei/ghes.c#l720 so something still isn't right. What did you actually base your patches on? Will ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-20 18:20 ` Will Deacon @ 2017-06-20 18:26 ` Baicar, Tyler 2017-06-21 9:21 ` Will Deacon 0 siblings, 1 reply; 17+ messages in thread From: Baicar, Tyler @ 2017-06-20 18:26 UTC (permalink / raw) To: Will Deacon Cc: Andy Shevchenko, Christoph Hellwig, Stephen Rothwell, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List On 6/20/2017 12:20 PM, Will Deacon wrote: > On Tue, Jun 20, 2017 at 12:13:13PM -0600, Baicar, Tyler wrote: >> I have sent you the rebased patches. I took Christoph's uuid-types tree and >> added this patch onto it: >> >> 7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types") >> >> And then added my patches onto that. This will hopefully now avoid conflicts >> with any other patch. > No, patch 6 fails to apply: > > On Tue, Jun 20, 2017 at 12:07:27PM -0600, Tyler Baicar wrote: >> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c >> index 7e3ddbe..81ebb9b 100644 >> --- a/drivers/acpi/apei/ghes.c >> +++ b/drivers/acpi/apei/ghes.c >> @@ -116,11 +116,7 @@ static inline bool is_hest_type_generic_v2(struct ghes *ghes) >> * Two virtual pages are used, one for IRQ/PROCESS context, the other for >> * NMI context (optionally). >> */ >> -#ifdef CONFIG_HAVE_ACPI_APEI_NMI >> #define GHES_IOREMAP_PAGES 2 >> -#else >> -#define GHES_IOREMAP_PAGES 1 >> -#endif >> #define GHES_IOREMAP_IRQ_PAGE(base) (base) >> #define GHES_IOREMAP_NMI_PAGE(base) ((base) + PAGE_SIZE) >> >> @@ -159,10 +155,14 @@ static void ghes_ioremap_exit(void) >> static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn) >> { >> unsigned long vaddr; >> + phys_addr_t paddr; >> + pgprot_t prot; >> >> vaddr = (unsigned long)GHES_IOREMAP_NMI_PAGE(ghes_ioremap_area->addr); >> - ioremap_page_range(vaddr, vaddr + PAGE_SIZE, >> - pfn << PAGE_SHIFT, PAGE_KERNEL); >> + >> + paddr = pfn << PAGE_SHIFT; >> + prot = arch_apei_get_mem_attribute(paddr); >> + ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot); >> >> return (void __iomem *)vaddr; >> } >> @@ -774,6 +774,50 @@ static int ghes_notify_hed(struct notifier_block *this, unsigned long event, >> .notifier_call = ghes_notify_hed, > In Christoph's tree, this line is: > > .notifier_call = ghes_notify_sci, > > http://git.infradead.org/users/hch/uuid.git/blob/refs/heads/uuid-types:/drivers/acpi/apei/ghes.c#l720 > > so something still isn't right. What did you actually base your patches > on? Yes, that line is changed in this patch 7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types") It is the other patch that was conflicting with this patch series when we tried to marge although it was a trivial conflict. I applied this patch to Christoph's tree and then put my patches on top of that. commit 7bf130e4a0653f6cec83a387de5de0c2c9fa4dba Author: Shiju Jose <shiju.jose@huawei.com> Date: Fri May 19 11:39:11 2017 +0200 ACPI/APEI: Handle GSIV and GPIO notification types System Controller Interrupts are received by ACPI's error device, which in turn notifies the GHES code. The same is true of APEI's GSIV and GPIO notification types. Add support for GSIV and GPIO sharing the SCI register/unregister/notifier code. Rename the list and notifier to show this is no longer just SCI, but anything from the Hardware Error Device. Signed-off-by: Shiju Jose <shiju.jose@huawei.com> [ Rewrite commit log. ] Signed-off-by: James Morse <james.morse@arm.com> [ Some small cleanups ontop. ] Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Tyler Baicar <tbaicar@codeaurora.org> Reviewed-by: James Morse <james.morse@arm.com> Link: http://lkml.kernel.org/r/86258A5CC0A3704780874CF6004BA8A62E695201@FRAEML521-MBX.china.huawei.com Cc: "Guohanjun (Hanjun Guo)" <guohanjun@huawei.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: "Zhengqiang (turing)" <zhengqiang10@huawei.com> Cc: "fu.wei@linaro.org" <fu.wei@linaro.org> Cc: "xuwei (O)" <xuwei5@hisilicon.com> Cc: Gabriele Paoloni <gabriele.paoloni@huawei.com> Cc: Geliang Tang <geliangtang@gmail.com> Cc: John Garry <john.garry@huawei.com> Cc: Len Brown <lenb@kernel.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Punit Agrawal <punit.agrawal@arm.com> Cc: linux-acpi@vger.kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index d0855c0..d2c8a92 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -89,14 +89,14 @@ module_param_named(disable, ghes_disable, bool, 0); /* - * All error sources notified with SCI shares one notifier function, - * so they need to be linked and checked one by one. This is applied - * to NMI too. + * All error sources notified with HED (Hardware Error Device) share a + * single notifier callback, so they need to be linked and checked one + * by one. This holds true for NMI too. * * RCU is used for these lists, so ghes_list_mutex is only used for * list changing, not for traversing. */ -static LIST_HEAD(ghes_sci); +static LIST_HEAD(ghes_hed); static DEFINE_MUTEX(ghes_list_mutex); /* @@ -702,14 +702,14 @@ static irqreturn_t ghes_irq_func(int irq, void *data) return IRQ_HANDLED; } -static int ghes_notify_sci(struct notifier_block *this, - unsigned long event, void *data) +static int ghes_notify_hed(struct notifier_block *this, unsigned long event, + void *data) { struct ghes *ghes; int ret = NOTIFY_DONE; rcu_read_lock(); - list_for_each_entry_rcu(ghes, &ghes_sci, list) { + list_for_each_entry_rcu(ghes, &ghes_hed, list) { if (!ghes_proc(ghes)) ret = NOTIFY_OK; } @@ -718,8 +718,8 @@ static int ghes_notify_sci(struct notifier_block *this, return ret; } -static struct notifier_block ghes_notifier_sci = { - .notifier_call = ghes_notify_sci, +static struct notifier_block ghes_notifier_hed = { + .notifier_call = ghes_notify_hed, }; #ifdef CONFIG_HAVE_ACPI_APEI_NMI @@ -966,7 +966,10 @@ static int ghes_probe(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_POLLED: case ACPI_HEST_NOTIFY_EXTERNAL: case ACPI_HEST_NOTIFY_SCI: + case ACPI_HEST_NOTIFY_GSIV: + case ACPI_HEST_NOTIFY_GPIO: break; + case ACPI_HEST_NOTIFY_NMI: if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) { pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n", @@ -1024,13 +1027,17 @@ static int ghes_probe(struct platform_device *ghes_dev) goto err_edac_unreg; } break; + case ACPI_HEST_NOTIFY_SCI: + case ACPI_HEST_NOTIFY_GSIV: + case ACPI_HEST_NOTIFY_GPIO: mutex_lock(&ghes_list_mutex); - if (list_empty(&ghes_sci)) - register_acpi_hed_notifier(&ghes_notifier_sci); - list_add_rcu(&ghes->list, &ghes_sci); + if (list_empty(&ghes_hed)) + register_acpi_hed_notifier(&ghes_notifier_hed); + list_add_rcu(&ghes->list, &ghes_hed); mutex_unlock(&ghes_list_mutex); break; + case ACPI_HEST_NOTIFY_NMI: ghes_nmi_add(ghes); break; @@ -1066,14 +1073,18 @@ static int ghes_remove(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_EXTERNAL: free_irq(ghes->irq, ghes); break; + case ACPI_HEST_NOTIFY_SCI: + case ACPI_HEST_NOTIFY_GSIV: + case ACPI_HEST_NOTIFY_GPIO: mutex_lock(&ghes_list_mutex); list_del_rcu(&ghes->list); - if (list_empty(&ghes_sci)) - unregister_acpi_hed_notifier(&ghes_notifier_sci); + if (list_empty(&ghes_hed)) + unregister_acpi_hed_notifier(&ghes_notifier_hed); mutex_unlock(&ghes_list_mutex); synchronize_rcu(); break; + case ACPI_HEST_NOTIFY_NMI: ghes_nmi_remove(ghes); break; -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-20 18:26 ` Baicar, Tyler @ 2017-06-21 9:21 ` Will Deacon 2017-06-21 18:19 ` Baicar, Tyler 0 siblings, 1 reply; 17+ messages in thread From: Will Deacon @ 2017-06-21 9:21 UTC (permalink / raw) To: Baicar, Tyler Cc: Andy Shevchenko, Christoph Hellwig, Stephen Rothwell, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List Hi Tyler, On Tue, Jun 20, 2017 at 12:26:01PM -0600, Baicar, Tyler wrote: > On 6/20/2017 12:20 PM, Will Deacon wrote: > >On Tue, Jun 20, 2017 at 12:13:13PM -0600, Baicar, Tyler wrote: > >>I have sent you the rebased patches. I took Christoph's uuid-types tree and > >>added this patch onto it: > >> > >>7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types") > >> > >>And then added my patches onto that. This will hopefully now avoid conflicts > >>with any other patch. > >No, patch 6 fails to apply: > > > >On Tue, Jun 20, 2017 at 12:07:27PM -0600, Tyler Baicar wrote: > >>diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c > >>index 7e3ddbe..81ebb9b 100644 > >>--- a/drivers/acpi/apei/ghes.c > >>+++ b/drivers/acpi/apei/ghes.c > >>@@ -116,11 +116,7 @@ static inline bool is_hest_type_generic_v2(struct ghes *ghes) > >> * Two virtual pages are used, one for IRQ/PROCESS context, the other for > >> * NMI context (optionally). > >> */ > >>-#ifdef CONFIG_HAVE_ACPI_APEI_NMI > >> #define GHES_IOREMAP_PAGES 2 > >>-#else > >>-#define GHES_IOREMAP_PAGES 1 > >>-#endif > >> #define GHES_IOREMAP_IRQ_PAGE(base) (base) > >> #define GHES_IOREMAP_NMI_PAGE(base) ((base) + PAGE_SIZE) > >>@@ -159,10 +155,14 @@ static void ghes_ioremap_exit(void) > >> static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn) > >> { > >> unsigned long vaddr; > >>+ phys_addr_t paddr; > >>+ pgprot_t prot; > >> vaddr = (unsigned long)GHES_IOREMAP_NMI_PAGE(ghes_ioremap_area->addr); > >>- ioremap_page_range(vaddr, vaddr + PAGE_SIZE, > >>- pfn << PAGE_SHIFT, PAGE_KERNEL); > >>+ > >>+ paddr = pfn << PAGE_SHIFT; > >>+ prot = arch_apei_get_mem_attribute(paddr); > >>+ ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot); > >> return (void __iomem *)vaddr; > >> } > >>@@ -774,6 +774,50 @@ static int ghes_notify_hed(struct notifier_block *this, unsigned long event, > >> .notifier_call = ghes_notify_hed, > >In Christoph's tree, this line is: > > > > .notifier_call = ghes_notify_sci, > > > >http://git.infradead.org/users/hch/uuid.git/blob/refs/heads/uuid-types:/drivers/acpi/apei/ghes.c#l720 > > > >so something still isn't right. What did you actually base your patches > >on? > Yes, that line is changed in this patch 7bf130e4a065 ("ACPI/APEI: Handle > GSIV and GPIO notification types") Ok, but that's not in mainline, not in the arm64 tree and not in Christoph's branch. I don't want to pull in random cherry-picks that are already in -next via some other means (looks like this is via -tip?). > It is the other patch that was conflicting with this patch series when we > tried to marge although it was a trivial conflict. I applied this patch to > Christoph's tree and then put my patches on top of that. If the conflicts are trivial, just base on uuid-types (which I've merged into the arm64 for-next/ras-apei branch). If they're not trivial, then you need to co-ordinate better with other developers and I think this will have to wait another release. Will ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the uuid tree with the arm64 tree 2017-06-21 9:21 ` Will Deacon @ 2017-06-21 18:19 ` Baicar, Tyler 0 siblings, 0 replies; 17+ messages in thread From: Baicar, Tyler @ 2017-06-21 18:19 UTC (permalink / raw) To: Will Deacon Cc: Andy Shevchenko, Christoph Hellwig, Stephen Rothwell, Catalin Marinas, Linux-Next Mailing List, Linux Kernel Mailing List On 6/21/2017 3:21 AM, Will Deacon wrote: > Hi Tyler, > > On Tue, Jun 20, 2017 at 12:26:01PM -0600, Baicar, Tyler wrote: >> On 6/20/2017 12:20 PM, Will Deacon wrote: >>> On Tue, Jun 20, 2017 at 12:13:13PM -0600, Baicar, Tyler wrote: >>>> I have sent you the rebased patches. I took Christoph's uuid-types tree and >>>> added this patch onto it: >>>> >>>> 7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types") >>>> >>>> And then added my patches onto that. This will hopefully now avoid conflicts >>>> with any other patch. >>> No, patch 6 fails to apply: >>> >>> On Tue, Jun 20, 2017 at 12:07:27PM -0600, Tyler Baicar wrote: >>>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c >>>> index 7e3ddbe..81ebb9b 100644 >>>> --- a/drivers/acpi/apei/ghes.c >>>> +++ b/drivers/acpi/apei/ghes.c >>>> @@ -116,11 +116,7 @@ static inline bool is_hest_type_generic_v2(struct ghes *ghes) >>>> * Two virtual pages are used, one for IRQ/PROCESS context, the other for >>>> * NMI context (optionally). >>>> */ >>>> -#ifdef CONFIG_HAVE_ACPI_APEI_NMI >>>> #define GHES_IOREMAP_PAGES 2 >>>> -#else >>>> -#define GHES_IOREMAP_PAGES 1 >>>> -#endif >>>> #define GHES_IOREMAP_IRQ_PAGE(base) (base) >>>> #define GHES_IOREMAP_NMI_PAGE(base) ((base) + PAGE_SIZE) >>>> @@ -159,10 +155,14 @@ static void ghes_ioremap_exit(void) >>>> static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn) >>>> { >>>> unsigned long vaddr; >>>> + phys_addr_t paddr; >>>> + pgprot_t prot; >>>> vaddr = (unsigned long)GHES_IOREMAP_NMI_PAGE(ghes_ioremap_area->addr); >>>> - ioremap_page_range(vaddr, vaddr + PAGE_SIZE, >>>> - pfn << PAGE_SHIFT, PAGE_KERNEL); >>>> + >>>> + paddr = pfn << PAGE_SHIFT; >>>> + prot = arch_apei_get_mem_attribute(paddr); >>>> + ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot); >>>> return (void __iomem *)vaddr; >>>> } >>>> @@ -774,6 +774,50 @@ static int ghes_notify_hed(struct notifier_block *this, unsigned long event, >>>> .notifier_call = ghes_notify_hed, >>> In Christoph's tree, this line is: >>> >>> .notifier_call = ghes_notify_sci, >>> >>> http://git.infradead.org/users/hch/uuid.git/blob/refs/heads/uuid-types:/drivers/acpi/apei/ghes.c#l720 >>> >>> so something still isn't right. What did you actually base your patches >>> on? >> Yes, that line is changed in this patch 7bf130e4a065 ("ACPI/APEI: Handle >> GSIV and GPIO notification types") > Ok, but that's not in mainline, not in the arm64 tree and not in Christoph's > branch. I don't want to pull in random cherry-picks that are already in > -next via some other means (looks like this is via -tip?). > >> It is the other patch that was conflicting with this patch series when we >> tried to marge although it was a trivial conflict. I applied this patch to >> Christoph's tree and then put my patches on top of that. > If the conflicts are trivial, just base on uuid-types (which I've merged > into the arm64 for-next/ras-apei branch). If they're not trivial, then you > need to co-ordinate better with other developers and I think this will have > to wait another release. Hi Will, I just sent you the patches that are based on uuid-types without anything else. This is the e-mail I received about that other conflicting patch: " Today's linux-next merge of the tip tree got a conflict in: drivers/acpi/apei/ghes.c between commit: d0189b2eef2e ("acpi: apei: handle SEA notification type for ARMv8") from the arm64 tree and commit: 7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types") from the tip 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, Tyler -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2017-06-21 18:19 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-16 5:21 linux-next: manual merge of the uuid tree with the arm64 tree Stephen Rothwell 2017-06-16 6:09 ` Christoph Hellwig 2017-06-19 0:28 ` Stephen Rothwell 2017-06-19 9:19 ` Will Deacon 2017-06-19 10:06 ` Andy Shevchenko 2017-06-19 10:22 ` Will Deacon 2017-06-19 18:41 ` Baicar, Tyler 2017-06-19 19:22 ` Baicar, Tyler 2017-06-20 8:40 ` Will Deacon 2017-06-20 8:43 ` Christoph Hellwig 2017-06-20 8:47 ` Andy Shevchenko 2017-06-20 18:13 ` Baicar, Tyler 2017-06-20 18:17 ` Andy Shevchenko 2017-06-20 18:20 ` Will Deacon 2017-06-20 18:26 ` Baicar, Tyler 2017-06-21 9:21 ` Will Deacon 2017-06-21 18:19 ` Baicar, Tyler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).