Re: [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing
Vinod, On 09/28/16 06:26, Vinod Koul wrote: > On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote: >> Hi, >> >> Changes since v2: >> - Instead of converting to use enum for the of_device_id data parameter the >> two >> patch for edma and ti-dma-crossbar is using pointers to u32 variables to >> make >> sure that the code compile (and in theory work) on all architectures. >> - fixed issue in the ti-dma-crossbar driver I have made with the enum change >> to >> not handle the DMA offset parameters correctly. >> >> Changes since v1: >> - added the compiler warning message to ti-dma-crossbar enum type patch >> - moved the Kconfig patches at the end of the seris >> >> The following series will enable unconditional COMPILE_TEST coverage for the >> following drivers: omap-dma, edma and ti-dma-crossbar >> >> The series includes fixes noticed when compiling the drivers for x86_64 and >> aarch64. > > I have applied the series after fixing code style nit-picks. > > Also applied the edma patch and reordered the series to have that come > before compile test enable patch > > Please verify. Looks good, thank you! -- Péter
Re: [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing
Vinod, On 09/28/16 06:26, Vinod Koul wrote: > On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote: >> Hi, >> >> Changes since v2: >> - Instead of converting to use enum for the of_device_id data parameter the >> two >> patch for edma and ti-dma-crossbar is using pointers to u32 variables to >> make >> sure that the code compile (and in theory work) on all architectures. >> - fixed issue in the ti-dma-crossbar driver I have made with the enum change >> to >> not handle the DMA offset parameters correctly. >> >> Changes since v1: >> - added the compiler warning message to ti-dma-crossbar enum type patch >> - moved the Kconfig patches at the end of the seris >> >> The following series will enable unconditional COMPILE_TEST coverage for the >> following drivers: omap-dma, edma and ti-dma-crossbar >> >> The series includes fixes noticed when compiling the drivers for x86_64 and >> aarch64. > > I have applied the series after fixing code style nit-picks. > > Also applied the edma patch and reordered the series to have that come > before compile test enable patch > > Please verify. Looks good, thank you! -- Péter
RE: ATA failure regression
Hi Can someone please help me to debug this issue? Regards Nehal -Original Message- From: Shah, Nehal-bakulchandra Sent: Monday, September 26, 2016 3:45 PM To: 'Bharat Kumar Gogada'Cc: Deucher, Alexander ; linux-...@vger.kernel.org; hol...@ahsoftware.de; t...@kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: RE: ATA failure regression Hi Bharat Thanks for the reply. I have observed following thing If IOMMU is enabled in BIOS and I use following option FCH SATA Debug Options --> Unused SATA Port Auto Shut Down Disabled. Issue is not happening. I have attached dmesg and lspci output with this option Also I have attached lspci log with IOMMU disabled. When issue is happening I am not able to take lspci logs as it stops in initramfs itself. I will try to get. Thanks Nehal -Original Message- From: Bharat Kumar Gogada [mailto:bharat.kumar.gog...@xilinx.com] Sent: Friday, September 23, 2016 3:40 PM To: Shah, Nehal-bakulchandra ; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; hol...@ahsoftware.de; t...@kernel.org; linux-...@vger.kernel.org Cc: Deucher, Alexander Subject: RE: ATA failure regression > Hi All, > > Resending this wider audience > > Currently I am working on AMD future platform. I am hitting the same > bug of ATA Failure Regression reported in past. > (https://patchwork.kernel.org/patch/6875661/) or > http://lkml.iu.edu/hypermail/linux/kernel/1507.3/01961.html > > I am newbie to this and because of this Ubuntu 16.04 is not booting. > If disable IOMMU and MSI obviously it works but that is not solution. > Even when I bisected it boiled to same place which was mentioned in past > discussion. > So here when you are disabling MSI, it is working with legacy interrupts or MSI-X. Can you post the end sata device lscpi -xxx -vvv content. Bharat
RE: ATA failure regression
Hi Can someone please help me to debug this issue? Regards Nehal -Original Message- From: Shah, Nehal-bakulchandra Sent: Monday, September 26, 2016 3:45 PM To: 'Bharat Kumar Gogada' Cc: Deucher, Alexander ; linux-...@vger.kernel.org; hol...@ahsoftware.de; t...@kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: RE: ATA failure regression Hi Bharat Thanks for the reply. I have observed following thing If IOMMU is enabled in BIOS and I use following option FCH SATA Debug Options --> Unused SATA Port Auto Shut Down Disabled. Issue is not happening. I have attached dmesg and lspci output with this option Also I have attached lspci log with IOMMU disabled. When issue is happening I am not able to take lspci logs as it stops in initramfs itself. I will try to get. Thanks Nehal -Original Message- From: Bharat Kumar Gogada [mailto:bharat.kumar.gog...@xilinx.com] Sent: Friday, September 23, 2016 3:40 PM To: Shah, Nehal-bakulchandra ; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; hol...@ahsoftware.de; t...@kernel.org; linux-...@vger.kernel.org Cc: Deucher, Alexander Subject: RE: ATA failure regression > Hi All, > > Resending this wider audience > > Currently I am working on AMD future platform. I am hitting the same > bug of ATA Failure Regression reported in past. > (https://patchwork.kernel.org/patch/6875661/) or > http://lkml.iu.edu/hypermail/linux/kernel/1507.3/01961.html > > I am newbie to this and because of this Ubuntu 16.04 is not booting. > If disable IOMMU and MSI obviously it works but that is not solution. > Even when I bisected it boiled to same place which was mentioned in past > discussion. > So here when you are disabling MSI, it is working with legacy interrupts or MSI-X. Can you post the end sata device lscpi -xxx -vvv content. Bharat
Re: [RFC] mm: a question about high-order check in __zone_watermark_ok()
On Mon, Sep 26, 2016 at 01:02:31PM +0200, Michal Hocko wrote: > On Mon 26-09-16 18:17:50, Xishi Qiu wrote: > > On 2016/9/26 17:43, Michal Hocko wrote: > > > > > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > > >> On 2016/9/26 16:58, Michal Hocko wrote: > > >> > > >>> On Mon 26-09-16 16:47:57, Xishi Qiu wrote: > > commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > > (mm, page_alloc: only enforce watermarks for order-0 allocations) > > rewrite the high-order check in __zone_watermark_ok(), but I think it > > quietly fix a bug. Please see the following. > > > > Before this patch, the high-order check is this: > > __zone_watermark_ok() > > ... > > for (o = 0; o < order; o++) { > > /* At the next order, this order's pages become > > unavailable */ > > free_pages -= z->free_area[o].nr_free << o; > > > > /* Require fewer higher order pages to be free */ > > min >>= 1; > > > > if (free_pages <= min) > > return false; > > } > > ... > > > > If we have cma memory, and we alloc a high-order movable page, then > > it's right. > > > > But if we alloc a high-order unmovable page(e.g. alloc kernel stack in > > dup_task_struct()), > > and there are a lot of high-order cma pages, but little high-order > > unmovable > > pages, the it is still return *true*, but we will alloc *failed* > > finally, because > > we cannot fallback from migrate_unmovable to migrate_cma, right? > > >>> > > >>> AFAIR CMA wmark check was always tricky and the above commit has made > > >>> the situation at least a bit more clear. Anyway IIRC > > >>> > > >>> #ifdef CONFIG_CMA > > >>> /* If allocation can't use CMA areas don't use free CMA pages */ > > >>> if (!(alloc_flags & ALLOC_CMA)) > > >>> free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); > > >>> #endif > > >>> > > >>> if (free_pages - free_cma <= min + > > >>> z->lowmem_reserve[classzone_idx]) > > >>> return false; > > >>> > > >>> should reduce the prioblem because a lot of CMA pages should just get us > > >>> below the wmark + reserve boundary. > > >> > > >> Hi Michal, > > >> > > >> If we have many high-order cma pages, and the left pages > > >> (unmovable/movable/reclaimable) > > >> are also enough, but they are fragment, then it will triger the problem. > > >> If we alloc a high-order unmovable page, water mark check return *true*, > > >> but we > > >> will alloc *failed*, right? > > > > > > As Vlastimil has written. There were known issues with the wmark checks > > > and high order requests. > > > > Shall we backport to stable? > > I dunno, it was a part of a larger series with high atomic reserves and > changes which sound a bit intrusive for the stable kernel. Considering > that CMA was known to be problematic and there are still some issues > left I do not think this is worth the trouble/risk. CMA problem is known one. I mentioned it on my ZONE_CMA series v1 but removed due to Mel's high atomic reserve series. That series is rather large and has some problems so I think that it is not suitable for stable tree. Thanks.
Re: [RFC] mm: a question about high-order check in __zone_watermark_ok()
On Mon, Sep 26, 2016 at 01:02:31PM +0200, Michal Hocko wrote: > On Mon 26-09-16 18:17:50, Xishi Qiu wrote: > > On 2016/9/26 17:43, Michal Hocko wrote: > > > > > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > > >> On 2016/9/26 16:58, Michal Hocko wrote: > > >> > > >>> On Mon 26-09-16 16:47:57, Xishi Qiu wrote: > > commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1 > > (mm, page_alloc: only enforce watermarks for order-0 allocations) > > rewrite the high-order check in __zone_watermark_ok(), but I think it > > quietly fix a bug. Please see the following. > > > > Before this patch, the high-order check is this: > > __zone_watermark_ok() > > ... > > for (o = 0; o < order; o++) { > > /* At the next order, this order's pages become > > unavailable */ > > free_pages -= z->free_area[o].nr_free << o; > > > > /* Require fewer higher order pages to be free */ > > min >>= 1; > > > > if (free_pages <= min) > > return false; > > } > > ... > > > > If we have cma memory, and we alloc a high-order movable page, then > > it's right. > > > > But if we alloc a high-order unmovable page(e.g. alloc kernel stack in > > dup_task_struct()), > > and there are a lot of high-order cma pages, but little high-order > > unmovable > > pages, the it is still return *true*, but we will alloc *failed* > > finally, because > > we cannot fallback from migrate_unmovable to migrate_cma, right? > > >>> > > >>> AFAIR CMA wmark check was always tricky and the above commit has made > > >>> the situation at least a bit more clear. Anyway IIRC > > >>> > > >>> #ifdef CONFIG_CMA > > >>> /* If allocation can't use CMA areas don't use free CMA pages */ > > >>> if (!(alloc_flags & ALLOC_CMA)) > > >>> free_cma = zone_page_state(z, NR_FREE_CMA_PAGES); > > >>> #endif > > >>> > > >>> if (free_pages - free_cma <= min + > > >>> z->lowmem_reserve[classzone_idx]) > > >>> return false; > > >>> > > >>> should reduce the prioblem because a lot of CMA pages should just get us > > >>> below the wmark + reserve boundary. > > >> > > >> Hi Michal, > > >> > > >> If we have many high-order cma pages, and the left pages > > >> (unmovable/movable/reclaimable) > > >> are also enough, but they are fragment, then it will triger the problem. > > >> If we alloc a high-order unmovable page, water mark check return *true*, > > >> but we > > >> will alloc *failed*, right? > > > > > > As Vlastimil has written. There were known issues with the wmark checks > > > and high order requests. > > > > Shall we backport to stable? > > I dunno, it was a part of a larger series with high atomic reserves and > changes which sound a bit intrusive for the stable kernel. Considering > that CMA was known to be problematic and there are still some issues > left I do not think this is worth the trouble/risk. CMA problem is known one. I mentioned it on my ZONE_CMA series v1 but removed due to Mel's high atomic reserve series. That series is rather large and has some problems so I think that it is not suitable for stable tree. Thanks.
RE: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR
Hi, Martin. I think that the patch is correct. UFS spec says "The Data Segment area is empty" for Read Descriptor. I have been using similar code with it and it works. That have been already applied in Android kernel. Reviewed-by: Kiwoong KimRegards. > -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Martin K. Petersen > Sent: Wednesday, September 28, 2016 2:14 PM > To: subha...@codeaurora.org > Cc: Zang Leigang; vinholika...@gmail.com; j...@linux.vnet.ibm.com; > martin.peter...@oracle.com; linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org; linux-scsi-ow...@vger.kernel.org > Subject: Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR > > > "Subhash" == subhashj writes: > > Subhash> Looks good to me. > > > - /* Data segment length */ > > - ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD( > > - 0, 0, len >> 8, (u8)len); > > + /* Data segment length only need for WRITE_DESC */ > > + if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC) > > + ucd_req_ptr->header.dword_2 = > > + UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len); > > + else > > + ucd_req_ptr->header.dword_2 = 0; > > What about READ_DESC? > > -- > Martin K. PetersenOracle Linux Engineering > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR
Hi, Martin. I think that the patch is correct. UFS spec says "The Data Segment area is empty" for Read Descriptor. I have been using similar code with it and it works. That have been already applied in Android kernel. Reviewed-by: Kiwoong Kim Regards. > -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Martin K. Petersen > Sent: Wednesday, September 28, 2016 2:14 PM > To: subha...@codeaurora.org > Cc: Zang Leigang; vinholika...@gmail.com; j...@linux.vnet.ibm.com; > martin.peter...@oracle.com; linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org; linux-scsi-ow...@vger.kernel.org > Subject: Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR > > > "Subhash" == subhashj writes: > > Subhash> Looks good to me. > > > - /* Data segment length */ > > - ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD( > > - 0, 0, len >> 8, (u8)len); > > + /* Data segment length only need for WRITE_DESC */ > > + if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC) > > + ucd_req_ptr->header.dword_2 = > > + UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len); > > + else > > + ucd_req_ptr->header.dword_2 = 0; > > What about READ_DESC? > > -- > Martin K. PetersenOracle Linux Engineering > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html
[PATCH] [media] atmel-isc: start dma in some scenario
If a new vb buf is added to vb queue, the queue is empty and steaming, dma should be started. Signed-off-by: Songjun Wu--- drivers/media/platform/atmel/atmel-isc.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c index ccfe13b..8e25d3f 100644 --- a/drivers/media/platform/atmel/atmel-isc.c +++ b/drivers/media/platform/atmel/atmel-isc.c @@ -617,7 +617,13 @@ static void isc_buffer_queue(struct vb2_buffer *vb) unsigned long flags; spin_lock_irqsave(>dma_queue_lock, flags); - list_add_tail(>list, >dma_queue); + if (!isc->cur_frm && list_empty(>dma_queue) && + vb2_is_streaming(vb->vb2_queue)) { + isc->cur_frm = buf; + isc_start_dma(isc->regmap, isc->cur_frm, + isc->current_fmt->reg_dctrl_dview); + } else + list_add_tail(>list, >dma_queue); spin_unlock_irqrestore(>dma_queue_lock, flags); } -- 2.7.4
[PATCH] [media] atmel-isc: start dma in some scenario
If a new vb buf is added to vb queue, the queue is empty and steaming, dma should be started. Signed-off-by: Songjun Wu --- drivers/media/platform/atmel/atmel-isc.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c index ccfe13b..8e25d3f 100644 --- a/drivers/media/platform/atmel/atmel-isc.c +++ b/drivers/media/platform/atmel/atmel-isc.c @@ -617,7 +617,13 @@ static void isc_buffer_queue(struct vb2_buffer *vb) unsigned long flags; spin_lock_irqsave(>dma_queue_lock, flags); - list_add_tail(>list, >dma_queue); + if (!isc->cur_frm && list_empty(>dma_queue) && + vb2_is_streaming(vb->vb2_queue)) { + isc->cur_frm = buf; + isc_start_dma(isc->regmap, isc->cur_frm, + isc->current_fmt->reg_dctrl_dview); + } else + list_add_tail(>list, >dma_queue); spin_unlock_irqrestore(>dma_queue_lock, flags); } -- 2.7.4
Re: [PATCH v5 3/6] mm/cma: populate ZONE_CMA
On Thu, Sep 22, 2016 at 05:59:46PM +0200, Vlastimil Babka wrote: > On 09/22/2016 08:50 AM, Joonsoo Kim wrote: > >On Thu, Sep 22, 2016 at 02:45:46PM +0900, Joonsoo Kim wrote: > >>> > >>> > /* Free whole pageblock and set its migration type to MIGRATE_CMA. */ > >>> > void __init init_cma_reserved_pageblock(struct page *page) > >>> > { > >>> > unsigned i = pageblock_nr_pages; > >>> >+unsigned long pfn = page_to_pfn(page); > >>> > struct page *p = page; > >>> >+int nid = page_to_nid(page); > >>> >+ > >>> >+/* > >>> >+ * ZONE_CMA will steal present pages from other zones by > >>> >changing > >>> >+ * page links so page_zone() is changed. Before that, > >>> >+ * we need to adjust previous zone's page count first. > >>> >+ */ > >>> >+adjust_present_page_count(page, -pageblock_nr_pages); > >>> > > >>> > do { > >>> > __ClearPageReserved(p); > >>> > set_page_count(p, 0); > >>> >-} while (++p, --i); > >>> >+ > >>> >+/* Steal pages from other zones */ > >>> >+set_page_links(p, ZONE_CMA, nid, pfn); > >>> >+} while (++p, ++pfn, --i); > >>> >+ > >>> >+adjust_present_page_count(page, pageblock_nr_pages); > >>> > >>> This seems to assign pages to ZONE_CMA on the proper node, which is > >>> good. But then ZONE_CMA on multiple nodes will have unnecessary > >>> holes in the spanned pages, as each will contain only a subset. > >> > >>True, I will fix it and respin the series. > > > >I now realize that it's too late to send full series for next > >merge window. I will send full series after next merge window is closed. > > I think there might still be rc8 thus another week. Indeed. I will send full series, soon. > > >Anyway, I'd like to confirm that following incremental patch will solve > >your concern. > > Yeah that should work, as long as single cma areas don't include multiple > nodes? Single cma areas cannot include multiple nodes at least until now. There is a check that single cma area is on a single zone. Thanks. > > >Thanks. > > > > > >-->8-- > > mm/cma.c | 25 - > > 1 file changed, 16 insertions(+), 9 deletions(-) > > > >diff --git a/mm/cma.c b/mm/cma.c > >index d69bdf7..8375554 100644 > >--- a/mm/cma.c > >+++ b/mm/cma.c > >@@ -146,22 +146,29 @@ static int __init cma_init_reserved_areas(void) > > { > >int i; > >struct zone *zone; > >- unsigned long start_pfn = UINT_MAX, end_pfn = 0; > >+ pg_data_t *pgdat; > > > >if (!cma_area_count) > >return 0; > > > >- for (i = 0; i < cma_area_count; i++) { > >- if (start_pfn > cma_areas[i].base_pfn) > >- start_pfn = cma_areas[i].base_pfn; > >- if (end_pfn < cma_areas[i].base_pfn + cma_areas[i].count) > >- end_pfn = cma_areas[i].base_pfn + cma_areas[i].count; > >- } > >+ for_each_online_pgdat(pgdat) { > >+ unsigned long start_pfn = UINT_MAX, end_pfn = 0; > > > >- for_each_zone(zone) { > >- if (!is_zone_cma(zone)) > >+ for (i = 0; i < cma_area_count; i++) { > >+ if (page_to_nid(pfn_to_page(cma_areas[i].base_pfn)) > >!= > > We have pfn_to_nid() (although the implementation is just like this). Will fix. Thanks.
Re: [PATCH v5 3/6] mm/cma: populate ZONE_CMA
On Thu, Sep 22, 2016 at 05:59:46PM +0200, Vlastimil Babka wrote: > On 09/22/2016 08:50 AM, Joonsoo Kim wrote: > >On Thu, Sep 22, 2016 at 02:45:46PM +0900, Joonsoo Kim wrote: > >>> > >>> > /* Free whole pageblock and set its migration type to MIGRATE_CMA. */ > >>> > void __init init_cma_reserved_pageblock(struct page *page) > >>> > { > >>> > unsigned i = pageblock_nr_pages; > >>> >+unsigned long pfn = page_to_pfn(page); > >>> > struct page *p = page; > >>> >+int nid = page_to_nid(page); > >>> >+ > >>> >+/* > >>> >+ * ZONE_CMA will steal present pages from other zones by > >>> >changing > >>> >+ * page links so page_zone() is changed. Before that, > >>> >+ * we need to adjust previous zone's page count first. > >>> >+ */ > >>> >+adjust_present_page_count(page, -pageblock_nr_pages); > >>> > > >>> > do { > >>> > __ClearPageReserved(p); > >>> > set_page_count(p, 0); > >>> >-} while (++p, --i); > >>> >+ > >>> >+/* Steal pages from other zones */ > >>> >+set_page_links(p, ZONE_CMA, nid, pfn); > >>> >+} while (++p, ++pfn, --i); > >>> >+ > >>> >+adjust_present_page_count(page, pageblock_nr_pages); > >>> > >>> This seems to assign pages to ZONE_CMA on the proper node, which is > >>> good. But then ZONE_CMA on multiple nodes will have unnecessary > >>> holes in the spanned pages, as each will contain only a subset. > >> > >>True, I will fix it and respin the series. > > > >I now realize that it's too late to send full series for next > >merge window. I will send full series after next merge window is closed. > > I think there might still be rc8 thus another week. Indeed. I will send full series, soon. > > >Anyway, I'd like to confirm that following incremental patch will solve > >your concern. > > Yeah that should work, as long as single cma areas don't include multiple > nodes? Single cma areas cannot include multiple nodes at least until now. There is a check that single cma area is on a single zone. Thanks. > > >Thanks. > > > > > >-->8-- > > mm/cma.c | 25 - > > 1 file changed, 16 insertions(+), 9 deletions(-) > > > >diff --git a/mm/cma.c b/mm/cma.c > >index d69bdf7..8375554 100644 > >--- a/mm/cma.c > >+++ b/mm/cma.c > >@@ -146,22 +146,29 @@ static int __init cma_init_reserved_areas(void) > > { > >int i; > >struct zone *zone; > >- unsigned long start_pfn = UINT_MAX, end_pfn = 0; > >+ pg_data_t *pgdat; > > > >if (!cma_area_count) > >return 0; > > > >- for (i = 0; i < cma_area_count; i++) { > >- if (start_pfn > cma_areas[i].base_pfn) > >- start_pfn = cma_areas[i].base_pfn; > >- if (end_pfn < cma_areas[i].base_pfn + cma_areas[i].count) > >- end_pfn = cma_areas[i].base_pfn + cma_areas[i].count; > >- } > >+ for_each_online_pgdat(pgdat) { > >+ unsigned long start_pfn = UINT_MAX, end_pfn = 0; > > > >- for_each_zone(zone) { > >- if (!is_zone_cma(zone)) > >+ for (i = 0; i < cma_area_count; i++) { > >+ if (page_to_nid(pfn_to_page(cma_areas[i].base_pfn)) > >!= > > We have pfn_to_nid() (although the implementation is just like this). Will fix. Thanks.
Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)
Andrey Utkinwrites: > Lockup happens only on 6010. In provided log you can see that 6110 > passes just fine right before 6010. Also if 6010 PCI ID is removed from > solo6x10 driver's devices list, the freeze doesn't happen. Probably explains why I don't see lockups :-) I will have a look. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)
Andrey Utkin writes: > Lockup happens only on 6010. In provided log you can see that 6110 > passes just fine right before 6010. Also if 6010 PCI ID is removed from > solo6x10 driver's devices list, the freeze doesn't happen. Probably explains why I don't see lockups :-) I will have a look. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR
> "Subhash" == subhashjwrites: Subhash> Looks good to me. > - /* Data segment length */ > - ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD( > - 0, 0, len >> 8, (u8)len); > + /* Data segment length only need for WRITE_DESC */ > + if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC) > + ucd_req_ptr->header.dword_2 = > + UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len); > + else > + ucd_req_ptr->header.dword_2 = 0; What about READ_DESC? -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR
> "Subhash" == subhashj writes: Subhash> Looks good to me. > - /* Data segment length */ > - ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD( > - 0, 0, len >> 8, (u8)len); > + /* Data segment length only need for WRITE_DESC */ > + if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC) > + ucd_req_ptr->header.dword_2 = > + UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len); > + else > + ucd_req_ptr->header.dword_2 = 0; What about READ_DESC? -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers
> "Lee" == Lee Duncanwrites: Lee> Yes, that would be great. Thank you. Applied to 4.9/scsi-queue. >> Is it your plan to go through the SCSI tree? Lee> Yes, the iscsi initiator kernel code updates have been going Lee> through the Linux SCSI mailing list and repository for a while, Lee> now. Yep. Just wanted to make sure. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers
> "Lee" == Lee Duncan writes: Lee> Yes, that would be great. Thank you. Applied to 4.9/scsi-queue. >> Is it your plan to go through the SCSI tree? Lee> Yes, the iscsi initiator kernel code updates have been going Lee> through the Linux SCSI mailing list and repository for a while, Lee> now. Yep. Just wanted to make sure. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event
On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote: > Yes. But *where* is it relative to the cores and socket(s)? And you need that information because... > > If you need to show the package id, you still iterate over the core > > numbers in an increasing order and show '*' for the offlined ones. > > > > Explain this in more detail please? Just s/package id/core id/ and then it makes sense - I meant "core id". -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event
On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote: > Yes. But *where* is it relative to the cores and socket(s)? And you need that information because... > > If you need to show the package id, you still iterate over the core > > numbers in an increasing order and show '*' for the offlined ones. > > > > Explain this in more detail please? Just s/package id/core id/ and then it makes sense - I meant "core id". -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: [PATCH] scsi: be2iscsi: mark symbols static where possible
> "Baoyou" == Baoyou Xiewrites: Baoyou> We get 6 warnings when building kernel with W=1: Baoyou> drivers/scsi/be2iscsi/be_main.c:65:1: warning: no previous Baoyou> prototype for 'beiscsi_log_enable_disp' [-Wmissing-prototypes] Baoyou> drivers/scsi/be2iscsi/be_main.c:78:1: warning: no previous Baoyou> prototype for 'beiscsi_log_enable_change' [-Wmissing-prototypes] Baoyou> drivers/scsi/be2iscsi/be_main.c:97:1: warning: no previous Baoyou> prototype for 'beiscsi_log_enable_store' [-Wmissing-prototypes] Baoyou> drivers/scsi/be2iscsi/be_main.c:116:1: warning: no previous Baoyou> prototype for 'beiscsi_log_enable_init' [-Wmissing-prototypes] Baoyou> drivers/scsi/be2iscsi/be_main.c:4587:5: warning: no previous Baoyou> prototype for 'beiscsi_iotask_v2' [-Wmissing-prototypes] Baoyou> drivers/scsi/be2iscsi/be_main.c:4976:6: warning: no previous Baoyou> prototype for 'beiscsi_hba_attrs_init' [-Wmissing-prototypes] Applied to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: be2iscsi: mark symbols static where possible
> "Baoyou" == Baoyou Xie writes: Baoyou> We get 6 warnings when building kernel with W=1: Baoyou> drivers/scsi/be2iscsi/be_main.c:65:1: warning: no previous Baoyou> prototype for 'beiscsi_log_enable_disp' [-Wmissing-prototypes] Baoyou> drivers/scsi/be2iscsi/be_main.c:78:1: warning: no previous Baoyou> prototype for 'beiscsi_log_enable_change' [-Wmissing-prototypes] Baoyou> drivers/scsi/be2iscsi/be_main.c:97:1: warning: no previous Baoyou> prototype for 'beiscsi_log_enable_store' [-Wmissing-prototypes] Baoyou> drivers/scsi/be2iscsi/be_main.c:116:1: warning: no previous Baoyou> prototype for 'beiscsi_log_enable_init' [-Wmissing-prototypes] Baoyou> drivers/scsi/be2iscsi/be_main.c:4587:5: warning: no previous Baoyou> prototype for 'beiscsi_iotask_v2' [-Wmissing-prototypes] Baoyou> drivers/scsi/be2iscsi/be_main.c:4976:6: warning: no previous Baoyou> prototype for 'beiscsi_hba_attrs_init' [-Wmissing-prototypes] Applied to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event
On Tue, Sep 27, 2016 at 11:26:14AM -0400, Prarit Bhargava wrote: > I see now that the issue is not understanding the difference between physical > and soft thread removal. I will write that up and get back to everyone. No need - we understand the issue. What I don't understand is what information you need *exactly* in sysfs from the offlined cores and why. Something like "I need to know the id of the thread on core X on socket Y because..." I've been trying to get it out of you but I've failed so far at it. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event
On Tue, Sep 27, 2016 at 11:26:14AM -0400, Prarit Bhargava wrote: > I see now that the issue is not understanding the difference between physical > and soft thread removal. I will write that up and get back to everyone. No need - we understand the issue. What I don't understand is what information you need *exactly* in sysfs from the offlined cores and why. Something like "I need to know the id of the thread on core X on socket Y because..." I've been trying to get it out of you but I've failed so far at it. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
RE: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready
> -Original Message- > From: Stefan Agner [mailto:ste...@agner.ch] > Sent: Monday, September 26, 2016 7:19 PM > To: w...@the-dreams.de > Cc: Leo Li; linux-...@vger.kernel.org; u.kleine- > koe...@pengutronix.de; linux-kernel@vger.kernel.org; Stefan Agner > > Subject: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready > > Some SoC might load the GPIO driver after the I2C driver and > using the I2C bus recovery mechanism via GPIOs. In this case > it is crucial to defer probing if the GPIO request functions > do so, otherwise the I2C driver gets loaded without recovery > mechanisms enabled. > > Signed-off-by: Stefan Agner Acked-by: Li Yang > --- > This is an actual issue on NXP Vybrid devices on which the GPIO > driver gets loaded rather later. > > -- > Stefan > > drivers/i2c/busses/i2c-imx.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c > index 592a8f2..47fc1f1 100644 > --- a/drivers/i2c/busses/i2c-imx.c > +++ b/drivers/i2c/busses/i2c-imx.c > @@ -1009,10 +1009,13 @@ static int i2c_imx_init_recovery_info(struct > imx_i2c_struct *i2c_imx, > rinfo->sda_gpio = of_get_named_gpio(pdev->dev.of_node, "sda-gpios", > 0); > rinfo->scl_gpio = of_get_named_gpio(pdev->dev.of_node, "scl-gpios", > 0); > > - if (!gpio_is_valid(rinfo->sda_gpio) || > - !gpio_is_valid(rinfo->scl_gpio) || > - IS_ERR(i2c_imx->pinctrl_pins_default) || > - IS_ERR(i2c_imx->pinctrl_pins_gpio)) { > + if (rinfo->sda_gpio == -EPROBE_DEFER || > + rinfo->scl_gpio == -EPROBE_DEFER) { > + return -EPROBE_DEFER; > + } else if (!gpio_is_valid(rinfo->sda_gpio) || > +!gpio_is_valid(rinfo->scl_gpio) || > +IS_ERR(i2c_imx->pinctrl_pins_default) || > +IS_ERR(i2c_imx->pinctrl_pins_gpio)) { > dev_dbg(>dev, "recovery information incomplete\n"); > return 0; > } > -- > 2.10.0
RE: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready
> -Original Message- > From: Stefan Agner [mailto:ste...@agner.ch] > Sent: Monday, September 26, 2016 7:19 PM > To: w...@the-dreams.de > Cc: Leo Li ; linux-...@vger.kernel.org; u.kleine- > koe...@pengutronix.de; linux-kernel@vger.kernel.org; Stefan Agner > > Subject: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready > > Some SoC might load the GPIO driver after the I2C driver and > using the I2C bus recovery mechanism via GPIOs. In this case > it is crucial to defer probing if the GPIO request functions > do so, otherwise the I2C driver gets loaded without recovery > mechanisms enabled. > > Signed-off-by: Stefan Agner Acked-by: Li Yang > --- > This is an actual issue on NXP Vybrid devices on which the GPIO > driver gets loaded rather later. > > -- > Stefan > > drivers/i2c/busses/i2c-imx.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c > index 592a8f2..47fc1f1 100644 > --- a/drivers/i2c/busses/i2c-imx.c > +++ b/drivers/i2c/busses/i2c-imx.c > @@ -1009,10 +1009,13 @@ static int i2c_imx_init_recovery_info(struct > imx_i2c_struct *i2c_imx, > rinfo->sda_gpio = of_get_named_gpio(pdev->dev.of_node, "sda-gpios", > 0); > rinfo->scl_gpio = of_get_named_gpio(pdev->dev.of_node, "scl-gpios", > 0); > > - if (!gpio_is_valid(rinfo->sda_gpio) || > - !gpio_is_valid(rinfo->scl_gpio) || > - IS_ERR(i2c_imx->pinctrl_pins_default) || > - IS_ERR(i2c_imx->pinctrl_pins_gpio)) { > + if (rinfo->sda_gpio == -EPROBE_DEFER || > + rinfo->scl_gpio == -EPROBE_DEFER) { > + return -EPROBE_DEFER; > + } else if (!gpio_is_valid(rinfo->sda_gpio) || > +!gpio_is_valid(rinfo->scl_gpio) || > +IS_ERR(i2c_imx->pinctrl_pins_default) || > +IS_ERR(i2c_imx->pinctrl_pins_gpio)) { > dev_dbg(>dev, "recovery information incomplete\n"); > return 0; > } > -- > 2.10.0
Re: [PATCH v2] pinctrl: Add SX150X GPIO Extender Pinctrl Driver
On 2016-09-27 17:48, Neil Armstrong wrote: > Since the I2C sx150x GPIO expander driver uses platform_data to manage > the pins configurations, rewrite the driver as a pinctrl driver using > pinconf to get/set pin configurations from DT or debugfs. > > The pinctrl driver is functionnally equivalent as the gpio-only driver > and can use DT for pinconf. The platform_data confirmation is dropped. > > This patchset removed the gpio-only driver and selects the Pinctrl driver > config instead. This patchset also migrates the gpio dt-bindings to pinctrl > and add the pinctrl optional properties. > > The driver was tested with a SX1509 device on a BeagleBone black with > interrupt support and on an X86_64 machine over an I2C to USB converter. > > Signed-off-by: Neil ArmstrongWorks here for sx1502 (without interrupts) on a custom arm board (SAMA5D3). Tested-by: Peter Rosin Cheers, Peter
Re: [PATCH v2] pinctrl: Add SX150X GPIO Extender Pinctrl Driver
On 2016-09-27 17:48, Neil Armstrong wrote: > Since the I2C sx150x GPIO expander driver uses platform_data to manage > the pins configurations, rewrite the driver as a pinctrl driver using > pinconf to get/set pin configurations from DT or debugfs. > > The pinctrl driver is functionnally equivalent as the gpio-only driver > and can use DT for pinconf. The platform_data confirmation is dropped. > > This patchset removed the gpio-only driver and selects the Pinctrl driver > config instead. This patchset also migrates the gpio dt-bindings to pinctrl > and add the pinctrl optional properties. > > The driver was tested with a SX1509 device on a BeagleBone black with > interrupt support and on an X86_64 machine over an I2C to USB converter. > > Signed-off-by: Neil Armstrong Works here for sx1502 (without interrupts) on a custom arm board (SAMA5D3). Tested-by: Peter Rosin Cheers, Peter
linux-next: manual merge of the staging tree with the vfs-miklos tree
Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/lustre/lustre/llite/file.c between commit: 302d50e7203e ("switch generic_file_splice_read() to use of ->read_iter()") from the vfs-miklos tree and commits: 5b8a39c53a16 ("staging: lustre: llite: Replace write mutex with range lock") ee5532436a7d ("staging: lustre: lov: remove LL_IOC_RECREATE_{FID, OBJ}") from the staging tree. I fixed it up (I think - 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/staging/lustre/lustre/llite/file.c index d1d1efac1431,6e3a188baaae.. --- a/drivers/staging/lustre/lustre/llite/file.c +++ b/drivers/staging/lustre/lustre/llite/file.c @@@ -1141,8 -1121,8 +1121,8 @@@ ll_file_io_generic(const struct lu_env struct cl_io *io; ssize_tresult; - CDEBUG(D_VFSTRACE, "file: %pD, type: %d ppos: %llu, count: %zd\n", - CDEBUG(D_VFSTRACE, "file: %s, type: %d ppos: %llu, count: %zu\n", - file->f_path.dentry->d_name.name, iot, *ppos, count); ++ CDEBUG(D_VFSTRACE, "file: %pD, type: %d ppos: %llu, count: %zu\n", + file, iot, *ppos, count); restart: io = vvp_env_thread_io(env); @@@ -1150,26 -1130,59 +1130,45 @@@ if (cl_io_rw_init(env, io, iot, *ppos, count) == 0) { struct vvp_io *vio = vvp_env_io(env); - int write_mutex_locked = 0; + bool range_locked = false; + + if (file->f_flags & O_APPEND) + range_lock_init(, 0, LUSTRE_EOF); + else + range_lock_init(, *ppos, *ppos + count - 1); vio->vui_fd = LUSTRE_FPRIVATE(file); - vio->vui_io_subtype = args->via_io_subtype; + vio->vui_iter = args->u.normal.via_iter; + vio->vui_iocb = args->u.normal.via_iocb; - if ((iot == CIT_WRITE) && ++ /* ++ * Direct IO reads must also take range lock, ++ * or multiple reads will try to work on the same pages ++ * See LU-6227 for details. ++ */ ++ if (((iot == CIT_WRITE) || ++ (iot == CIT_READ && (file->f_flags & O_DIRECT))) && + !(vio->vui_fd->fd_flags & LL_FILE_GROUP_LOCKED)) { - if (mutex_lock_interruptible(>lli_write_mutex)) { - result = -ERESTARTSYS; ++ CDEBUG(D_VFSTRACE, "Range lock [%llu, %llu]\n", ++ range.rl_node.in_extent.start, ++ range.rl_node.in_extent.end); ++ result = range_lock(>lli_write_tree, ++ ); ++ if (result < 0) + goto out; - } - write_mutex_locked = 1; + - switch (vio->vui_io_subtype) { - case IO_NORMAL: - vio->vui_iter = args->u.normal.via_iter; - vio->vui_iocb = args->u.normal.via_iocb; - /* - * Direct IO reads must also take range lock, - * or multiple reads will try to work on the same pages - * See LU-6227 for details. - */ - if (((iot == CIT_WRITE) || - (iot == CIT_READ && (file->f_flags & O_DIRECT))) && - !(vio->vui_fd->fd_flags & LL_FILE_GROUP_LOCKED)) { - CDEBUG(D_VFSTRACE, "Range lock [%llu, %llu]\n", - range.rl_node.in_extent.start, - range.rl_node.in_extent.end); - result = range_lock(>lli_write_tree, - ); - if (result < 0) - goto out; - - range_locked = true; - } - down_read(>lli_trunc_sem); - break; - case IO_SPLICE: - vio->u.splice.vui_pipe = args->u.splice.via_pipe; - vio->u.splice.vui_flags = args->u.splice.via_flags; - break; - default: - CERROR("Unknown IO type - %u\n", vio->vui_io_subtype); - LBUG(); ++ range_locked = true; } +
linux-next: manual merge of the staging tree with the vfs-miklos tree
Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/lustre/lustre/llite/file.c between commit: 302d50e7203e ("switch generic_file_splice_read() to use of ->read_iter()") from the vfs-miklos tree and commits: 5b8a39c53a16 ("staging: lustre: llite: Replace write mutex with range lock") ee5532436a7d ("staging: lustre: lov: remove LL_IOC_RECREATE_{FID, OBJ}") from the staging tree. I fixed it up (I think - 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/staging/lustre/lustre/llite/file.c index d1d1efac1431,6e3a188baaae.. --- a/drivers/staging/lustre/lustre/llite/file.c +++ b/drivers/staging/lustre/lustre/llite/file.c @@@ -1141,8 -1121,8 +1121,8 @@@ ll_file_io_generic(const struct lu_env struct cl_io *io; ssize_tresult; - CDEBUG(D_VFSTRACE, "file: %pD, type: %d ppos: %llu, count: %zd\n", - CDEBUG(D_VFSTRACE, "file: %s, type: %d ppos: %llu, count: %zu\n", - file->f_path.dentry->d_name.name, iot, *ppos, count); ++ CDEBUG(D_VFSTRACE, "file: %pD, type: %d ppos: %llu, count: %zu\n", + file, iot, *ppos, count); restart: io = vvp_env_thread_io(env); @@@ -1150,26 -1130,59 +1130,45 @@@ if (cl_io_rw_init(env, io, iot, *ppos, count) == 0) { struct vvp_io *vio = vvp_env_io(env); - int write_mutex_locked = 0; + bool range_locked = false; + + if (file->f_flags & O_APPEND) + range_lock_init(, 0, LUSTRE_EOF); + else + range_lock_init(, *ppos, *ppos + count - 1); vio->vui_fd = LUSTRE_FPRIVATE(file); - vio->vui_io_subtype = args->via_io_subtype; + vio->vui_iter = args->u.normal.via_iter; + vio->vui_iocb = args->u.normal.via_iocb; - if ((iot == CIT_WRITE) && ++ /* ++ * Direct IO reads must also take range lock, ++ * or multiple reads will try to work on the same pages ++ * See LU-6227 for details. ++ */ ++ if (((iot == CIT_WRITE) || ++ (iot == CIT_READ && (file->f_flags & O_DIRECT))) && + !(vio->vui_fd->fd_flags & LL_FILE_GROUP_LOCKED)) { - if (mutex_lock_interruptible(>lli_write_mutex)) { - result = -ERESTARTSYS; ++ CDEBUG(D_VFSTRACE, "Range lock [%llu, %llu]\n", ++ range.rl_node.in_extent.start, ++ range.rl_node.in_extent.end); ++ result = range_lock(>lli_write_tree, ++ ); ++ if (result < 0) + goto out; - } - write_mutex_locked = 1; + - switch (vio->vui_io_subtype) { - case IO_NORMAL: - vio->vui_iter = args->u.normal.via_iter; - vio->vui_iocb = args->u.normal.via_iocb; - /* - * Direct IO reads must also take range lock, - * or multiple reads will try to work on the same pages - * See LU-6227 for details. - */ - if (((iot == CIT_WRITE) || - (iot == CIT_READ && (file->f_flags & O_DIRECT))) && - !(vio->vui_fd->fd_flags & LL_FILE_GROUP_LOCKED)) { - CDEBUG(D_VFSTRACE, "Range lock [%llu, %llu]\n", - range.rl_node.in_extent.start, - range.rl_node.in_extent.end); - result = range_lock(>lli_write_tree, - ); - if (result < 0) - goto out; - - range_locked = true; - } - down_read(>lli_trunc_sem); - break; - case IO_SPLICE: - vio->u.splice.vui_pipe = args->u.splice.via_pipe; - vio->u.splice.vui_flags = args->u.splice.via_flags; - break; - default: - CERROR("Unknown IO type - %u\n", vio->vui_io_subtype); - LBUG(); ++ range_locked = true; } +
Re: [PATCH 2/2] hid: input: add HID_QUIRK_REUSE_AXES and fix dragonrise
On Tue, Sep 27, 2016 at 10:44 PM, Ioan-Adrian Ratiuwrote: > Can you please wait a little until I post v2 later today and test v2 > directly? Because the change in it's current form has no effect on > 0079:0011 (the current quirk is enabled only for 0006). Sure thing! Just drop me a line when it's ready.
Re: [PATCH 2/2] hid: input: add HID_QUIRK_REUSE_AXES and fix dragonrise
On Tue, Sep 27, 2016 at 10:44 PM, Ioan-Adrian Ratiu wrote: > Can you please wait a little until I post v2 later today and test v2 > directly? Because the change in it's current form has no effect on > 0079:0011 (the current quirk is enabled only for 0006). Sure thing! Just drop me a line when it's ready.
Re: [PATCH v3 00/11] re-enable DAX PMD support
On Tue, Sep 27, 2016 at 07:08:42PM -0700, Christoph Hellwig wrote: > On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote: > > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > > locking. This series allows DAX PMDs to participate in the DAX radix tree > > based locking scheme so that they can be re-enabled. > > > > Jan and Christoph, can you please help review these changes? > > About to get on a plane, so it might take a bit to do a real review. > In general this looks fine, but I guess the first two ext4 patches > should just go straight to Ted independent of the rest? > > Also Jan just posted a giant DAX patchbomb, we'll need to find a way > to integrate all that work, and maybe prioritize things if we want > to get bits into 4.9 still. I'm not going to have time to do much review or testing of the DAX changes (apart from the cursor comments I've already made) because of the huge pile of XFS reflink changes I've got ot get through first. However, I've already got the iomap dax bits in the XFS tree so I can pull everything through there if review and testing is covered otherwise.. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH v3 00/11] re-enable DAX PMD support
On Tue, Sep 27, 2016 at 07:08:42PM -0700, Christoph Hellwig wrote: > On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote: > > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > > locking. This series allows DAX PMDs to participate in the DAX radix tree > > based locking scheme so that they can be re-enabled. > > > > Jan and Christoph, can you please help review these changes? > > About to get on a plane, so it might take a bit to do a real review. > In general this looks fine, but I guess the first two ext4 patches > should just go straight to Ted independent of the rest? > > Also Jan just posted a giant DAX patchbomb, we'll need to find a way > to integrate all that work, and maybe prioritize things if we want > to get bits into 4.9 still. I'm not going to have time to do much review or testing of the DAX changes (apart from the cursor comments I've already made) because of the huge pile of XFS reflink changes I've got ot get through first. However, I've already got the iomap dax bits in the XFS tree so I can pull everything through there if review and testing is covered otherwise.. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO
On 27-09-16, 20:38, Stefan Agner wrote: > The i.MX I2C driver touches the pinctrl in its prepare/unprepare > callbacks. > > So, on a i.MX or Vybrid, the call chain looks like this: > > i2c_generic_gpio_recovery > -> i2c_get_gpios_for_recovery >-> gpio_request_one > -> i2c_generic_recovery >-> prepare_recovery (i2c_imx_prepare_recovery) > -> pinctrl_select_state [gpio] Why is this done here? And not in gpio_request_one? >-> unprepare_recovery (i2c_imx_unprepare_recovery) > -> pinctrl_select_state [default] > -> i2c_put_gpios_for_recovery >-> gpio_free > > > And for the pinctrl/GPIO driver of Vybrid this is actually a problem > because gpio_free disables the output driver of the pad, and when that > happens after the (I2C) default pinctrl state gets selected the pad is > no longer active. > > -- > Stefan -- viresh
Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO
On 27-09-16, 20:38, Stefan Agner wrote: > The i.MX I2C driver touches the pinctrl in its prepare/unprepare > callbacks. > > So, on a i.MX or Vybrid, the call chain looks like this: > > i2c_generic_gpio_recovery > -> i2c_get_gpios_for_recovery >-> gpio_request_one > -> i2c_generic_recovery >-> prepare_recovery (i2c_imx_prepare_recovery) > -> pinctrl_select_state [gpio] Why is this done here? And not in gpio_request_one? >-> unprepare_recovery (i2c_imx_unprepare_recovery) > -> pinctrl_select_state [default] > -> i2c_put_gpios_for_recovery >-> gpio_free > > > And for the pinctrl/GPIO driver of Vybrid this is actually a problem > because gpio_free disables the output driver of the pad, and when that > happens after the (I2C) default pinctrl state gets selected the pad is > no longer active. > > -- > Stefan -- viresh
[PATCH] perf tools: Fix building in 32 bit platform
On ARM32 building it report following error: util/data-convert-bt.c: In function 'add_bpf_output_values': util/data-convert-bt.c:440:3: error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Werror=format] cc1: all warnings being treated as errors Fix it by changing %lu to %zu. Signed-off-by: Wang NanCc: Arnaldo Carvalho de Melo Cc: Jiri Olsa --- tools/perf/util/data-convert-bt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/data-convert-bt.c b/tools/perf/util/data-convert-bt.c index 4f979bb..7123f4d 100644 --- a/tools/perf/util/data-convert-bt.c +++ b/tools/perf/util/data-convert-bt.c @@ -437,7 +437,7 @@ add_bpf_output_values(struct bt_ctf_event_class *event_class, int ret; if (nr_elements * sizeof(u32) != raw_size) - pr_warning("Incorrect raw_size (%u) in bpf output event, skip %lu bytes\n", + pr_warning("Incorrect raw_size (%u) in bpf output event, skip %zu bytes\n", raw_size, nr_elements * sizeof(u32) - raw_size); len_type = bt_ctf_event_class_get_field_by_name(event_class, "raw_len"); -- 1.8.3.4
[PATCH] perf tools: Fix building in 32 bit platform
On ARM32 building it report following error: util/data-convert-bt.c: In function 'add_bpf_output_values': util/data-convert-bt.c:440:3: error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Werror=format] cc1: all warnings being treated as errors Fix it by changing %lu to %zu. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa --- tools/perf/util/data-convert-bt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/data-convert-bt.c b/tools/perf/util/data-convert-bt.c index 4f979bb..7123f4d 100644 --- a/tools/perf/util/data-convert-bt.c +++ b/tools/perf/util/data-convert-bt.c @@ -437,7 +437,7 @@ add_bpf_output_values(struct bt_ctf_event_class *event_class, int ret; if (nr_elements * sizeof(u32) != raw_size) - pr_warning("Incorrect raw_size (%u) in bpf output event, skip %lu bytes\n", + pr_warning("Incorrect raw_size (%u) in bpf output event, skip %zu bytes\n", raw_size, nr_elements * sizeof(u32) - raw_size); len_type = bt_ctf_event_class_get_field_by_name(event_class, "raw_len"); -- 1.8.3.4
[PATCH 3/3] bindings: add compatible "fsl,ls1043-ucc-hdlc" to bindings
Signed-off-by: Zhao Qiang--- Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt index 03c7416..325e3e2 100644 --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt @@ -45,7 +45,7 @@ Example: * HDLC Currently defined compatibles: -- fsl,ucc-hdlc +- "fsl,ucc-hdlc", "fsl,ls1043-ucc-hdlc" Properties for fsl,ucc-hdlc: - rx-clock-name -- 2.1.0.27.g96db324
[PATCH 3/3] bindings: add compatible "fsl,ls1043-ucc-hdlc" to bindings
Signed-off-by: Zhao Qiang --- Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt index 03c7416..325e3e2 100644 --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt @@ -45,7 +45,7 @@ Example: * HDLC Currently defined compatibles: -- fsl,ucc-hdlc +- "fsl,ucc-hdlc", "fsl,ls1043-ucc-hdlc" Properties for fsl,ucc-hdlc: - rx-clock-name -- 2.1.0.27.g96db324
[PATCH v6 2/4] irqchip/qeic: merge qeic init code from platforms to a common function
The codes of qe_ic init from a variety of platforms are redundant, merge them to a common function and put it to irqchip/irq-qeic.c For non-p1021_mds mpc85xx_mds boards, use "qe_ic_init(np, 0, qe_ic_cascade_low_mpic, qe_ic_cascade_high_mpic);" instead of "qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);". qe_ic_cascade_muxed_mpic was used for boards has the same interrupt number for low interrupt and high interrupt, qe_ic_init has checked if "low interrupt == high interrupt" Signed-off-by: Zhao Qiang--- Changes for v2: - modify subject and commit msg - add check for qeic by type Changes for v3: - na Changes for v4: - na Changes for v5: - na Changes for v6: - rebase arch/powerpc/platforms/83xx/misc.c| 15 --- arch/powerpc/platforms/85xx/corenet_generic.c | 9 - arch/powerpc/platforms/85xx/mpc85xx_mds.c | 14 -- arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 arch/powerpc/platforms/85xx/twr_p102x.c | 14 -- drivers/irqchip/irq-qeic.c| 16 6 files changed, 16 insertions(+), 68 deletions(-) diff --git a/arch/powerpc/platforms/83xx/misc.c b/arch/powerpc/platforms/83xx/misc.c index d75c981..c09a135 100644 --- a/arch/powerpc/platforms/83xx/misc.c +++ b/arch/powerpc/platforms/83xx/misc.c @@ -93,24 +93,9 @@ void __init mpc83xx_ipic_init_IRQ(void) } #ifdef CONFIG_QUICC_ENGINE -void __init mpc83xx_qe_init_IRQ(void) -{ - struct device_node *np; - - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic"); - if (!np) { - np = of_find_node_by_type(NULL, "qeic"); - if (!np) - return; - } - qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic); - of_node_put(np); -} - void __init mpc83xx_ipic_and_qe_init_IRQ(void) { mpc83xx_ipic_init_IRQ(); - mpc83xx_qe_init_IRQ(); } #endif /* CONFIG_QUICC_ENGINE */ diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c index 1179115..1d96c3f 100644 --- a/arch/powerpc/platforms/85xx/corenet_generic.c +++ b/arch/powerpc/platforms/85xx/corenet_generic.c @@ -41,8 +41,6 @@ void __init corenet_gen_pic_init(void) unsigned int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU | MPIC_NO_RESET; - struct device_node *np; - if (ppc_md.get_irq == mpic_get_coreint_irq) flags |= MPIC_ENABLE_COREINT; @@ -50,13 +48,6 @@ void __init corenet_gen_pic_init(void) BUG_ON(mpic == NULL); mpic_init(mpic); - - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic"); - if (np) { - qe_ic_init(np, 0, qe_ic_cascade_low_mpic, - qe_ic_cascade_high_mpic); - of_node_put(np); - } } /* diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c index d7e440e..06f34a9 100644 --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c @@ -283,20 +283,6 @@ static void __init mpc85xx_mds_qeic_init(void) of_node_put(np); return; } - - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic"); - if (!np) { - np = of_find_node_by_type(NULL, "qeic"); - if (!np) - return; - } - - if (machine_is(p1021_mds)) - qe_ic_init(np, 0, qe_ic_cascade_low_mpic, - qe_ic_cascade_high_mpic); - else - qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL); - of_node_put(np); } #else static void __init mpc85xx_mds_qe_init(void) { } diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c index 1006950..000d385 100644 --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c @@ -48,10 +48,6 @@ void __init mpc85xx_rdb_pic_init(void) { struct mpic *mpic; -#ifdef CONFIG_QUICC_ENGINE - struct device_node *np; -#endif - if (of_machine_is_compatible("fsl,MPC85XXRDB-CAMP")) { mpic = mpic_alloc(NULL, 0, MPIC_NO_RESET | MPIC_BIG_ENDIAN | @@ -66,18 +62,6 @@ void __init mpc85xx_rdb_pic_init(void) BUG_ON(mpic == NULL); mpic_init(mpic); - -#ifdef CONFIG_QUICC_ENGINE - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic"); - if (np) { - qe_ic_init(np, 0, qe_ic_cascade_low_mpic, - qe_ic_cascade_high_mpic); - of_node_put(np); - - } else - pr_err("%s: Could not find qe-ic node\n", __func__); -#endif - } /* diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c index 360f625..6be9b33 100644 ---
[PATCH 2/3] ls1043ardb: add ds26522 node to dts
add ds26522 node to fsl-ls1043a-rdb.dts Signed-off-by: Zhao Qiang--- arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 1 file changed, 16 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts index 4fc60e7..206a8f5 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts @@ -122,6 +122,22 @@ reg = <0>; spi-max-frequency = <100>; /* input clock */ }; + + slic@2 { + compatible = "maxim,ds26522"; + reg = <2>; + spi-max-frequency = <200>; + fsl,spi-cs-sck-delay = <100>; + fsl,spi-sck-cs-delay = <50>; + }; + + slic@3 { + compatible = "maxim,ds26522"; + reg = <3>; + spi-max-frequency = <200>; + fsl,spi-cs-sck-delay = <100>; + fsl,spi-sck-cs-delay = <50>; + }; }; { -- 2.1.0.27.g96db324
[PATCH v6 2/4] irqchip/qeic: merge qeic init code from platforms to a common function
The codes of qe_ic init from a variety of platforms are redundant, merge them to a common function and put it to irqchip/irq-qeic.c For non-p1021_mds mpc85xx_mds boards, use "qe_ic_init(np, 0, qe_ic_cascade_low_mpic, qe_ic_cascade_high_mpic);" instead of "qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);". qe_ic_cascade_muxed_mpic was used for boards has the same interrupt number for low interrupt and high interrupt, qe_ic_init has checked if "low interrupt == high interrupt" Signed-off-by: Zhao Qiang --- Changes for v2: - modify subject and commit msg - add check for qeic by type Changes for v3: - na Changes for v4: - na Changes for v5: - na Changes for v6: - rebase arch/powerpc/platforms/83xx/misc.c| 15 --- arch/powerpc/platforms/85xx/corenet_generic.c | 9 - arch/powerpc/platforms/85xx/mpc85xx_mds.c | 14 -- arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 arch/powerpc/platforms/85xx/twr_p102x.c | 14 -- drivers/irqchip/irq-qeic.c| 16 6 files changed, 16 insertions(+), 68 deletions(-) diff --git a/arch/powerpc/platforms/83xx/misc.c b/arch/powerpc/platforms/83xx/misc.c index d75c981..c09a135 100644 --- a/arch/powerpc/platforms/83xx/misc.c +++ b/arch/powerpc/platforms/83xx/misc.c @@ -93,24 +93,9 @@ void __init mpc83xx_ipic_init_IRQ(void) } #ifdef CONFIG_QUICC_ENGINE -void __init mpc83xx_qe_init_IRQ(void) -{ - struct device_node *np; - - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic"); - if (!np) { - np = of_find_node_by_type(NULL, "qeic"); - if (!np) - return; - } - qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic); - of_node_put(np); -} - void __init mpc83xx_ipic_and_qe_init_IRQ(void) { mpc83xx_ipic_init_IRQ(); - mpc83xx_qe_init_IRQ(); } #endif /* CONFIG_QUICC_ENGINE */ diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c index 1179115..1d96c3f 100644 --- a/arch/powerpc/platforms/85xx/corenet_generic.c +++ b/arch/powerpc/platforms/85xx/corenet_generic.c @@ -41,8 +41,6 @@ void __init corenet_gen_pic_init(void) unsigned int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU | MPIC_NO_RESET; - struct device_node *np; - if (ppc_md.get_irq == mpic_get_coreint_irq) flags |= MPIC_ENABLE_COREINT; @@ -50,13 +48,6 @@ void __init corenet_gen_pic_init(void) BUG_ON(mpic == NULL); mpic_init(mpic); - - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic"); - if (np) { - qe_ic_init(np, 0, qe_ic_cascade_low_mpic, - qe_ic_cascade_high_mpic); - of_node_put(np); - } } /* diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c index d7e440e..06f34a9 100644 --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c @@ -283,20 +283,6 @@ static void __init mpc85xx_mds_qeic_init(void) of_node_put(np); return; } - - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic"); - if (!np) { - np = of_find_node_by_type(NULL, "qeic"); - if (!np) - return; - } - - if (machine_is(p1021_mds)) - qe_ic_init(np, 0, qe_ic_cascade_low_mpic, - qe_ic_cascade_high_mpic); - else - qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL); - of_node_put(np); } #else static void __init mpc85xx_mds_qe_init(void) { } diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c index 1006950..000d385 100644 --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c @@ -48,10 +48,6 @@ void __init mpc85xx_rdb_pic_init(void) { struct mpic *mpic; -#ifdef CONFIG_QUICC_ENGINE - struct device_node *np; -#endif - if (of_machine_is_compatible("fsl,MPC85XXRDB-CAMP")) { mpic = mpic_alloc(NULL, 0, MPIC_NO_RESET | MPIC_BIG_ENDIAN | @@ -66,18 +62,6 @@ void __init mpc85xx_rdb_pic_init(void) BUG_ON(mpic == NULL); mpic_init(mpic); - -#ifdef CONFIG_QUICC_ENGINE - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic"); - if (np) { - qe_ic_init(np, 0, qe_ic_cascade_low_mpic, - qe_ic_cascade_high_mpic); - of_node_put(np); - - } else - pr_err("%s: Could not find qe-ic node\n", __func__); -#endif - } /* diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c index 360f625..6be9b33 100644 ---
[PATCH 2/3] ls1043ardb: add ds26522 node to dts
add ds26522 node to fsl-ls1043a-rdb.dts Signed-off-by: Zhao Qiang --- arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 1 file changed, 16 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts index 4fc60e7..206a8f5 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts @@ -122,6 +122,22 @@ reg = <0>; spi-max-frequency = <100>; /* input clock */ }; + + slic@2 { + compatible = "maxim,ds26522"; + reg = <2>; + spi-max-frequency = <200>; + fsl,spi-cs-sck-delay = <100>; + fsl,spi-sck-cs-delay = <50>; + }; + + slic@3 { + compatible = "maxim,ds26522"; + reg = <3>; + spi-max-frequency = <200>; + fsl,spi-cs-sck-delay = <100>; + fsl,spi-sck-cs-delay = <50>; + }; }; { -- 2.1.0.27.g96db324
[PATCH 1/3] ls1043ardb: add qe node to ls1043ardb
Signed-off-by: Zhao Qiang--- arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++ arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 66 +++ 2 files changed, 82 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts index 4084631..4fc60e7 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts @@ -124,6 +124,22 @@ }; }; + { + ucc_hdlc: ucc@2000 { + compatible = "fsl,ls1043-ucc-hdlc", "fsl,ucc-hdlc"; + rx-clock-name = "clk8"; + tx-clock-name = "clk9"; + fsl,rx-sync-clock = "rsync_pin"; + fsl,tx-sync-clock = "tsync_pin"; + fsl,tx-timeslot-mask = <0xfffe>; + fsl,rx-timeslot-mask = <0xfffe>; + fsl,tdm-framer-type = "e1"; + fsl,tdm-id = <0>; + fsl,siram-entry-id = <0>; + fsl,tdm-interface; + }; +}; + { status = "okay"; }; diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi index e669fbd..f6b6775 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi @@ -388,6 +388,72 @@ #interrupt-cells = <2>; }; + uqe: uqe@240 { + #address-cells = <1>; + #size-cells = <1>; + device_type = "qe"; + compatible = "fsl,qe", "simple-bus"; + ranges = <0x0 0x0 0x240 0x4>; + reg = <0x0 0x240 0x0 0x480>; + brg-frequency = <1>; + bus-frequency = <2>; + + fsl,qe-num-riscs = <1>; + fsl,qe-num-snums = <28>; + + qeic: qeic@80 { + compatible = "fsl,qe-ic"; + reg = <0x80 0x80>; + #address-cells = <0>; + interrupt-controller; + #interrupt-cells = <1>; + interrupts = <0 77 0x04 0 77 0x04>; + }; + + si1: si@700 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,ls1043-qe-si", + "fsl,t1040-qe-si"; + reg = <0x700 0x80>; + }; + + siram1: siram@1000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,ls1043-qe-siram", + "fsl,t1040-qe-siram"; + reg = <0x1000 0x800>; + }; + + ucc@2000 { + cell-index = <1>; + reg = <0x2000 0x200>; + interrupts = <32>; + interrupt-parent = <>; + }; + + ucc@2200 { + cell-index = <3>; + reg = <0x2200 0x200>; + interrupts = <34>; + interrupt-parent = <>; + }; + + muram@1 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,qe-muram", "fsl,cpm-muram"; + ranges = <0x0 0x1 0x6000>; + + data-only@0 { + compatible = "fsl,qe-muram-data", + "fsl,cpm-muram-data"; + reg = <0x0 0x6000>; + }; + }; + }; + lpuart0: serial@295 { compatible = "fsl,ls1021a-lpuart"; reg = <0x0 0x295 0x0 0x1000>; -- 2.1.0.27.g96db324
[PATCH 1/3] ls1043ardb: add qe node to ls1043ardb
Signed-off-by: Zhao Qiang --- arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++ arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 66 +++ 2 files changed, 82 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts index 4084631..4fc60e7 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts @@ -124,6 +124,22 @@ }; }; + { + ucc_hdlc: ucc@2000 { + compatible = "fsl,ls1043-ucc-hdlc", "fsl,ucc-hdlc"; + rx-clock-name = "clk8"; + tx-clock-name = "clk9"; + fsl,rx-sync-clock = "rsync_pin"; + fsl,tx-sync-clock = "tsync_pin"; + fsl,tx-timeslot-mask = <0xfffe>; + fsl,rx-timeslot-mask = <0xfffe>; + fsl,tdm-framer-type = "e1"; + fsl,tdm-id = <0>; + fsl,siram-entry-id = <0>; + fsl,tdm-interface; + }; +}; + { status = "okay"; }; diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi index e669fbd..f6b6775 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi @@ -388,6 +388,72 @@ #interrupt-cells = <2>; }; + uqe: uqe@240 { + #address-cells = <1>; + #size-cells = <1>; + device_type = "qe"; + compatible = "fsl,qe", "simple-bus"; + ranges = <0x0 0x0 0x240 0x4>; + reg = <0x0 0x240 0x0 0x480>; + brg-frequency = <1>; + bus-frequency = <2>; + + fsl,qe-num-riscs = <1>; + fsl,qe-num-snums = <28>; + + qeic: qeic@80 { + compatible = "fsl,qe-ic"; + reg = <0x80 0x80>; + #address-cells = <0>; + interrupt-controller; + #interrupt-cells = <1>; + interrupts = <0 77 0x04 0 77 0x04>; + }; + + si1: si@700 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,ls1043-qe-si", + "fsl,t1040-qe-si"; + reg = <0x700 0x80>; + }; + + siram1: siram@1000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,ls1043-qe-siram", + "fsl,t1040-qe-siram"; + reg = <0x1000 0x800>; + }; + + ucc@2000 { + cell-index = <1>; + reg = <0x2000 0x200>; + interrupts = <32>; + interrupt-parent = <>; + }; + + ucc@2200 { + cell-index = <3>; + reg = <0x2200 0x200>; + interrupts = <34>; + interrupt-parent = <>; + }; + + muram@1 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,qe-muram", "fsl,cpm-muram"; + ranges = <0x0 0x1 0x6000>; + + data-only@0 { + compatible = "fsl,qe-muram-data", + "fsl,cpm-muram-data"; + reg = <0x0 0x6000>; + }; + }; + }; + lpuart0: serial@295 { compatible = "fsl,ls1021a-lpuart"; reg = <0x0 0x295 0x0 0x1000>; -- 2.1.0.27.g96db324
[PATCH v6 4/4] irqchip/qeic: remove PPCisms for QEIC
QEIC was supported on PowerPC, and dependent on PPC, Now it is supported on other platforms, so remove PPCisms. Signed-off-by: Zhao Qiang--- Changes for v6: - new added drivers/irqchip/irq-qeic.c | 28 +--- include/soc/fsl/qe/qe_ic.h | 12 ++-- 2 files changed, 23 insertions(+), 17 deletions(-) diff --git a/drivers/irqchip/irq-qeic.c b/drivers/irqchip/irq-qeic.c index 4f49d4b..98a8b38 100644 --- a/drivers/irqchip/irq-qeic.c +++ b/drivers/irqchip/irq-qeic.c @@ -18,7 +18,10 @@ #include #include #include +#include #include +#include +#include #include #include #include @@ -266,13 +269,13 @@ static struct qe_ic_info qe_ic_info[] = { static inline u32 qe_ic_read(volatile __be32 __iomem * base, unsigned int reg) { - return in_be32(base + (reg >> 2)); + return ioread32be(base + (reg >> 2)); } static inline void qe_ic_write(volatile __be32 __iomem * base, unsigned int reg, u32 value) { - out_be32(base + (reg >> 2), value); + iowrite32be(value, base + (reg >> 2)); } static inline struct qe_ic *qe_ic_from_irq(unsigned int virq) @@ -374,7 +377,7 @@ static const struct irq_domain_ops qe_ic_host_ops = { .xlate = irq_domain_xlate_onetwocell, }; -/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */ +/* Return an interrupt vector or 0 if no interrupt is pending. */ unsigned int qe_ic_get_low_irq(struct qe_ic *qe_ic) { int irq; @@ -385,12 +388,12 @@ unsigned int qe_ic_get_low_irq(struct qe_ic *qe_ic) irq = qe_ic_read(qe_ic->regs, QEIC_CIVEC) >> 26; if (irq == 0) - return NO_IRQ; + return 0; return irq_linear_revmap(qe_ic->irqhost, irq); } -/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */ +/* Return an interrupt vector or 0 if no interrupt is pending. */ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic) { int irq; @@ -401,7 +404,7 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic) irq = qe_ic_read(qe_ic->regs, QEIC_CHIVEC) >> 26; if (irq == 0) - return NO_IRQ; + return 0; return irq_linear_revmap(qe_ic->irqhost, irq); } @@ -447,7 +450,7 @@ static int __init qe_ic_init(unsigned int flags) qe_ic->virq_high = irq_of_parse_and_map(node, 0); qe_ic->virq_low = irq_of_parse_and_map(node, 1); - if (qe_ic->virq_low == NO_IRQ) { + if (qe_ic->virq_low == 0) { pr_err("Failed to map QE_IC low IRQ\n"); ret = -ENOMEM; goto err_domain_remove; @@ -479,7 +482,7 @@ static int __init qe_ic_init(unsigned int flags) irq_set_handler_data(qe_ic->virq_low, qe_ic); irq_set_chained_handler(qe_ic->virq_low, qe_ic_cascade_low_mpic); - if (qe_ic->virq_high != NO_IRQ && + if (qe_ic->virq_high != 0 && qe_ic->virq_high != qe_ic->virq_low) { irq_set_handler_data(qe_ic->virq_high, qe_ic); irq_set_chained_handler(qe_ic->virq_high, @@ -500,7 +503,8 @@ err_put_node: void qe_ic_set_highest_priority(unsigned int virq, int high) { struct qe_ic *qe_ic = qe_ic_from_irq(virq); - unsigned int src = virq_to_hw(virq); + struct irq_data *irq_data = irq_get_irq_data(virq); + irq_hw_number_t src = WARN_ON(!irq_data) ? 0 : irq_data->hwirq; u32 temp = 0; temp = qe_ic_read(qe_ic->regs, QEIC_CICR); @@ -518,7 +522,8 @@ void qe_ic_set_highest_priority(unsigned int virq, int high) int qe_ic_set_priority(unsigned int virq, unsigned int priority) { struct qe_ic *qe_ic = qe_ic_from_irq(virq); - unsigned int src = virq_to_hw(virq); + struct irq_data *irq_data = irq_get_irq_data(virq); + irq_hw_number_t src = WARN_ON(!irq_data) ? 0 : irq_data->hwirq; u32 temp; if (priority > 8 || priority == 0) @@ -548,7 +553,8 @@ int qe_ic_set_priority(unsigned int virq, unsigned int priority) int qe_ic_set_high_priority(unsigned int virq, unsigned int priority, int high) { struct qe_ic *qe_ic = qe_ic_from_irq(virq); - unsigned int src = virq_to_hw(virq); + struct irq_data *irq_data = irq_get_irq_data(virq); + irq_hw_number_t src = WARN_ON(!irq_data) ? 0 : irq_data->hwirq; u32 temp, control_reg = QEIC_CICNR, shift = 0; if (priority > 2 || priority == 0) diff --git a/include/soc/fsl/qe/qe_ic.h b/include/soc/fsl/qe/qe_ic.h index 6113699..863cfec 100644 --- a/include/soc/fsl/qe/qe_ic.h +++ b/include/soc/fsl/qe/qe_ic.h @@ -76,7 +76,7 @@ static inline void qe_ic_cascade_low_ipic(struct irq_desc *desc) struct qe_ic *qe_ic = irq_desc_get_handler_data(desc); unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic); - if (cascade_irq != NO_IRQ) + if (cascade_irq != 0) generic_handle_irq(cascade_irq); } @@ -85,7 +85,7 @@
[PATCH v6 1/4] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe
move the driver from drivers/soc/fsl/qe to drivers/irqchip, merge qe_ic.h and qe_ic.c into irq-qeic.c. Signed-off-by: Zhao Qiang--- Changes for v2: - modify the subject and commit msg Changes for v3: - merge .h file to .c, rename it with irq-qeic.c Changes for v4: - modify comments Changes for v5: - disable rename detection Changes for v6: - rebase drivers/irqchip/Makefile | 1 + drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} | 95 ++- drivers/soc/fsl/qe/Makefile| 2 +- drivers/soc/fsl/qe/qe_ic.h | 103 - 4 files changed, 94 insertions(+), 107 deletions(-) rename drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} (85%) delete mode 100644 drivers/soc/fsl/qe/qe_ic.h diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile index 4c203b6..face608 100644 --- a/drivers/irqchip/Makefile +++ b/drivers/irqchip/Makefile @@ -71,3 +71,4 @@ obj-$(CONFIG_MVEBU_ODMI) += irq-mvebu-odmi.o obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o obj-$(CONFIG_EZNPS_GIC)+= irq-eznps.o obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o +obj-$(CONFIG_QUICC_ENGINE) += irq-qeic.o diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/irqchip/irq-qeic.c similarity index 85% rename from drivers/soc/fsl/qe/qe_ic.c rename to drivers/irqchip/irq-qeic.c index ec2ca86..48ceded 100644 --- a/drivers/soc/fsl/qe/qe_ic.c +++ b/drivers/irqchip/irq-qeic.c @@ -1,7 +1,7 @@ /* - * arch/powerpc/sysdev/qe_lib/qe_ic.c + * drivers/irqchip/irq-qeic.c * - * Copyright (C) 2006 Freescale Semiconductor, Inc. All rights reserved. + * Copyright (C) 2016 Freescale Semiconductor, Inc. All rights reserved. * * Author: Li Yang * Based on code from Shlomi Gridish @@ -30,7 +30,96 @@ #include #include -#include "qe_ic.h" +#define NR_QE_IC_INTS 64 + +/* QE IC registers offset */ +#define QEIC_CICR 0x00 +#define QEIC_CIVEC 0x04 +#define QEIC_CRIPNR0x08 +#define QEIC_CIPNR 0x0c +#define QEIC_CIPXCC0x10 +#define QEIC_CIPYCC0x14 +#define QEIC_CIPWCC0x18 +#define QEIC_CIPZCC0x1c +#define QEIC_CIMR 0x20 +#define QEIC_CRIMR 0x24 +#define QEIC_CICNR 0x28 +#define QEIC_CIPRTA0x30 +#define QEIC_CIPRTB0x34 +#define QEIC_CRICR 0x3c +#define QEIC_CHIVEC0x60 + +/* Interrupt priority registers */ +#define CIPCC_SHIFT_PRI0 29 +#define CIPCC_SHIFT_PRI1 26 +#define CIPCC_SHIFT_PRI2 23 +#define CIPCC_SHIFT_PRI3 20 +#define CIPCC_SHIFT_PRI4 13 +#define CIPCC_SHIFT_PRI5 10 +#define CIPCC_SHIFT_PRI6 7 +#define CIPCC_SHIFT_PRI7 4 + +/* CICR priority modes */ +#define CICR_GWCC 0x0004 +#define CICR_GXCC 0x0002 +#define CICR_GYCC 0x0001 +#define CICR_GZCC 0x0008 +#define CICR_GRTA 0x0020 +#define CICR_GRTB 0x0040 +#define CICR_HPIT_SHIFT8 +#define CICR_HPIT_MASK 0x0300 +#define CICR_HP_SHIFT 24 +#define CICR_HP_MASK 0x3f00 + +/* CICNR */ +#define CICNR_WCC1T_SHIFT 20 +#define CICNR_ZCC1T_SHIFT 28 +#define CICNR_YCC1T_SHIFT 12 +#define CICNR_XCC1T_SHIFT 4 + +/* CRICR */ +#define CRICR_RTA1T_SHIFT 20 +#define CRICR_RTB1T_SHIFT 28 + +/* Signal indicator */ +#define SIGNAL_MASK3 +#define SIGNAL_HIGH2 +#define SIGNAL_LOW 0 + +struct qe_ic { + /* Control registers offset */ + volatile u32 __iomem *regs; + + /* The remapper for this QEIC */ + struct irq_domain *irqhost; + + /* The "linux" controller struct */ + struct irq_chip hc_irq; + + /* VIRQ numbers of QE high/low irqs */ + unsigned int virq_high; + unsigned int virq_low; +}; + +/* + * QE interrupt controller internal structure + */ +struct qe_ic_info { + /* location of this source at the QIMR register. */ + u32 mask; + + /* Mask register offset */ + u32 mask_reg; + + /* +* for grouped interrupts sources - the interrupt +* code as appears at the group priority register +*/ + u8 pri_code; + + /* Group priority register offset */ + u32 pri_reg; +}; static DEFINE_RAW_SPINLOCK(qe_ic_lock); diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile index 2031d38..51e4726 100644 --- a/drivers/soc/fsl/qe/Makefile +++ b/drivers/soc/fsl/qe/Makefile @@ -1,7 +1,7 @@ # # Makefile for the linux ppc-specific parts of QE # -obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o +obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o
[PATCH v6 4/4] irqchip/qeic: remove PPCisms for QEIC
QEIC was supported on PowerPC, and dependent on PPC, Now it is supported on other platforms, so remove PPCisms. Signed-off-by: Zhao Qiang --- Changes for v6: - new added drivers/irqchip/irq-qeic.c | 28 +--- include/soc/fsl/qe/qe_ic.h | 12 ++-- 2 files changed, 23 insertions(+), 17 deletions(-) diff --git a/drivers/irqchip/irq-qeic.c b/drivers/irqchip/irq-qeic.c index 4f49d4b..98a8b38 100644 --- a/drivers/irqchip/irq-qeic.c +++ b/drivers/irqchip/irq-qeic.c @@ -18,7 +18,10 @@ #include #include #include +#include #include +#include +#include #include #include #include @@ -266,13 +269,13 @@ static struct qe_ic_info qe_ic_info[] = { static inline u32 qe_ic_read(volatile __be32 __iomem * base, unsigned int reg) { - return in_be32(base + (reg >> 2)); + return ioread32be(base + (reg >> 2)); } static inline void qe_ic_write(volatile __be32 __iomem * base, unsigned int reg, u32 value) { - out_be32(base + (reg >> 2), value); + iowrite32be(value, base + (reg >> 2)); } static inline struct qe_ic *qe_ic_from_irq(unsigned int virq) @@ -374,7 +377,7 @@ static const struct irq_domain_ops qe_ic_host_ops = { .xlate = irq_domain_xlate_onetwocell, }; -/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */ +/* Return an interrupt vector or 0 if no interrupt is pending. */ unsigned int qe_ic_get_low_irq(struct qe_ic *qe_ic) { int irq; @@ -385,12 +388,12 @@ unsigned int qe_ic_get_low_irq(struct qe_ic *qe_ic) irq = qe_ic_read(qe_ic->regs, QEIC_CIVEC) >> 26; if (irq == 0) - return NO_IRQ; + return 0; return irq_linear_revmap(qe_ic->irqhost, irq); } -/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */ +/* Return an interrupt vector or 0 if no interrupt is pending. */ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic) { int irq; @@ -401,7 +404,7 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic) irq = qe_ic_read(qe_ic->regs, QEIC_CHIVEC) >> 26; if (irq == 0) - return NO_IRQ; + return 0; return irq_linear_revmap(qe_ic->irqhost, irq); } @@ -447,7 +450,7 @@ static int __init qe_ic_init(unsigned int flags) qe_ic->virq_high = irq_of_parse_and_map(node, 0); qe_ic->virq_low = irq_of_parse_and_map(node, 1); - if (qe_ic->virq_low == NO_IRQ) { + if (qe_ic->virq_low == 0) { pr_err("Failed to map QE_IC low IRQ\n"); ret = -ENOMEM; goto err_domain_remove; @@ -479,7 +482,7 @@ static int __init qe_ic_init(unsigned int flags) irq_set_handler_data(qe_ic->virq_low, qe_ic); irq_set_chained_handler(qe_ic->virq_low, qe_ic_cascade_low_mpic); - if (qe_ic->virq_high != NO_IRQ && + if (qe_ic->virq_high != 0 && qe_ic->virq_high != qe_ic->virq_low) { irq_set_handler_data(qe_ic->virq_high, qe_ic); irq_set_chained_handler(qe_ic->virq_high, @@ -500,7 +503,8 @@ err_put_node: void qe_ic_set_highest_priority(unsigned int virq, int high) { struct qe_ic *qe_ic = qe_ic_from_irq(virq); - unsigned int src = virq_to_hw(virq); + struct irq_data *irq_data = irq_get_irq_data(virq); + irq_hw_number_t src = WARN_ON(!irq_data) ? 0 : irq_data->hwirq; u32 temp = 0; temp = qe_ic_read(qe_ic->regs, QEIC_CICR); @@ -518,7 +522,8 @@ void qe_ic_set_highest_priority(unsigned int virq, int high) int qe_ic_set_priority(unsigned int virq, unsigned int priority) { struct qe_ic *qe_ic = qe_ic_from_irq(virq); - unsigned int src = virq_to_hw(virq); + struct irq_data *irq_data = irq_get_irq_data(virq); + irq_hw_number_t src = WARN_ON(!irq_data) ? 0 : irq_data->hwirq; u32 temp; if (priority > 8 || priority == 0) @@ -548,7 +553,8 @@ int qe_ic_set_priority(unsigned int virq, unsigned int priority) int qe_ic_set_high_priority(unsigned int virq, unsigned int priority, int high) { struct qe_ic *qe_ic = qe_ic_from_irq(virq); - unsigned int src = virq_to_hw(virq); + struct irq_data *irq_data = irq_get_irq_data(virq); + irq_hw_number_t src = WARN_ON(!irq_data) ? 0 : irq_data->hwirq; u32 temp, control_reg = QEIC_CICNR, shift = 0; if (priority > 2 || priority == 0) diff --git a/include/soc/fsl/qe/qe_ic.h b/include/soc/fsl/qe/qe_ic.h index 6113699..863cfec 100644 --- a/include/soc/fsl/qe/qe_ic.h +++ b/include/soc/fsl/qe/qe_ic.h @@ -76,7 +76,7 @@ static inline void qe_ic_cascade_low_ipic(struct irq_desc *desc) struct qe_ic *qe_ic = irq_desc_get_handler_data(desc); unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic); - if (cascade_irq != NO_IRQ) + if (cascade_irq != 0) generic_handle_irq(cascade_irq); } @@ -85,7 +85,7 @@ static inline void
[PATCH v6 1/4] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe
move the driver from drivers/soc/fsl/qe to drivers/irqchip, merge qe_ic.h and qe_ic.c into irq-qeic.c. Signed-off-by: Zhao Qiang --- Changes for v2: - modify the subject and commit msg Changes for v3: - merge .h file to .c, rename it with irq-qeic.c Changes for v4: - modify comments Changes for v5: - disable rename detection Changes for v6: - rebase drivers/irqchip/Makefile | 1 + drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} | 95 ++- drivers/soc/fsl/qe/Makefile| 2 +- drivers/soc/fsl/qe/qe_ic.h | 103 - 4 files changed, 94 insertions(+), 107 deletions(-) rename drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} (85%) delete mode 100644 drivers/soc/fsl/qe/qe_ic.h diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile index 4c203b6..face608 100644 --- a/drivers/irqchip/Makefile +++ b/drivers/irqchip/Makefile @@ -71,3 +71,4 @@ obj-$(CONFIG_MVEBU_ODMI) += irq-mvebu-odmi.o obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o obj-$(CONFIG_EZNPS_GIC)+= irq-eznps.o obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o +obj-$(CONFIG_QUICC_ENGINE) += irq-qeic.o diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/irqchip/irq-qeic.c similarity index 85% rename from drivers/soc/fsl/qe/qe_ic.c rename to drivers/irqchip/irq-qeic.c index ec2ca86..48ceded 100644 --- a/drivers/soc/fsl/qe/qe_ic.c +++ b/drivers/irqchip/irq-qeic.c @@ -1,7 +1,7 @@ /* - * arch/powerpc/sysdev/qe_lib/qe_ic.c + * drivers/irqchip/irq-qeic.c * - * Copyright (C) 2006 Freescale Semiconductor, Inc. All rights reserved. + * Copyright (C) 2016 Freescale Semiconductor, Inc. All rights reserved. * * Author: Li Yang * Based on code from Shlomi Gridish @@ -30,7 +30,96 @@ #include #include -#include "qe_ic.h" +#define NR_QE_IC_INTS 64 + +/* QE IC registers offset */ +#define QEIC_CICR 0x00 +#define QEIC_CIVEC 0x04 +#define QEIC_CRIPNR0x08 +#define QEIC_CIPNR 0x0c +#define QEIC_CIPXCC0x10 +#define QEIC_CIPYCC0x14 +#define QEIC_CIPWCC0x18 +#define QEIC_CIPZCC0x1c +#define QEIC_CIMR 0x20 +#define QEIC_CRIMR 0x24 +#define QEIC_CICNR 0x28 +#define QEIC_CIPRTA0x30 +#define QEIC_CIPRTB0x34 +#define QEIC_CRICR 0x3c +#define QEIC_CHIVEC0x60 + +/* Interrupt priority registers */ +#define CIPCC_SHIFT_PRI0 29 +#define CIPCC_SHIFT_PRI1 26 +#define CIPCC_SHIFT_PRI2 23 +#define CIPCC_SHIFT_PRI3 20 +#define CIPCC_SHIFT_PRI4 13 +#define CIPCC_SHIFT_PRI5 10 +#define CIPCC_SHIFT_PRI6 7 +#define CIPCC_SHIFT_PRI7 4 + +/* CICR priority modes */ +#define CICR_GWCC 0x0004 +#define CICR_GXCC 0x0002 +#define CICR_GYCC 0x0001 +#define CICR_GZCC 0x0008 +#define CICR_GRTA 0x0020 +#define CICR_GRTB 0x0040 +#define CICR_HPIT_SHIFT8 +#define CICR_HPIT_MASK 0x0300 +#define CICR_HP_SHIFT 24 +#define CICR_HP_MASK 0x3f00 + +/* CICNR */ +#define CICNR_WCC1T_SHIFT 20 +#define CICNR_ZCC1T_SHIFT 28 +#define CICNR_YCC1T_SHIFT 12 +#define CICNR_XCC1T_SHIFT 4 + +/* CRICR */ +#define CRICR_RTA1T_SHIFT 20 +#define CRICR_RTB1T_SHIFT 28 + +/* Signal indicator */ +#define SIGNAL_MASK3 +#define SIGNAL_HIGH2 +#define SIGNAL_LOW 0 + +struct qe_ic { + /* Control registers offset */ + volatile u32 __iomem *regs; + + /* The remapper for this QEIC */ + struct irq_domain *irqhost; + + /* The "linux" controller struct */ + struct irq_chip hc_irq; + + /* VIRQ numbers of QE high/low irqs */ + unsigned int virq_high; + unsigned int virq_low; +}; + +/* + * QE interrupt controller internal structure + */ +struct qe_ic_info { + /* location of this source at the QIMR register. */ + u32 mask; + + /* Mask register offset */ + u32 mask_reg; + + /* +* for grouped interrupts sources - the interrupt +* code as appears at the group priority register +*/ + u8 pri_code; + + /* Group priority register offset */ + u32 pri_reg; +}; static DEFINE_RAW_SPINLOCK(qe_ic_lock); diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile index 2031d38..51e4726 100644 --- a/drivers/soc/fsl/qe/Makefile +++ b/drivers/soc/fsl/qe/Makefile @@ -1,7 +1,7 @@ # # Makefile for the linux ppc-specific parts of QE # -obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o +obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_io.o obj-$(CONFIG_CPM) += qe_common.o obj-$(CONFIG_UCC)
Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO
On 2016-09-27 19:00, Viresh Kumar wrote: > On 27-09-16, 12:34, Stefan Agner wrote: >> Added Viresh Kumar to the discussion, he implemented the I2C recovery >> functions. >> >> Yes, reordering the pinctrl/gpio_free calls would fix the problem too. >> >> However, I guess there is no explicit rule to that ("request/free GPIOs >> only when they are muxed as GPIO"), so I think of it that the issue is >> actually in the pinctrl driver. >> >> On top of that it is not entirely trivial to reorder the calls the way >> i2c_generic_gpio_recovery and i2c_generic_recovery are set up right now. > > AFAICT, these routines don't touch the muxing part at all. Perhaps it is done > internally by the GPIO calls. Can you please elaborate the exact change you > are > hinting towards here ? The i.MX I2C driver touches the pinctrl in its prepare/unprepare callbacks. So, on a i.MX or Vybrid, the call chain looks like this: i2c_generic_gpio_recovery -> i2c_get_gpios_for_recovery -> gpio_request_one -> i2c_generic_recovery -> prepare_recovery (i2c_imx_prepare_recovery) -> pinctrl_select_state [gpio] -> unprepare_recovery (i2c_imx_unprepare_recovery) -> pinctrl_select_state [default] -> i2c_put_gpios_for_recovery -> gpio_free And for the pinctrl/GPIO driver of Vybrid this is actually a problem because gpio_free disables the output driver of the pad, and when that happens after the (I2C) default pinctrl state gets selected the pad is no longer active. -- Stefan
Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO
On 2016-09-27 19:00, Viresh Kumar wrote: > On 27-09-16, 12:34, Stefan Agner wrote: >> Added Viresh Kumar to the discussion, he implemented the I2C recovery >> functions. >> >> Yes, reordering the pinctrl/gpio_free calls would fix the problem too. >> >> However, I guess there is no explicit rule to that ("request/free GPIOs >> only when they are muxed as GPIO"), so I think of it that the issue is >> actually in the pinctrl driver. >> >> On top of that it is not entirely trivial to reorder the calls the way >> i2c_generic_gpio_recovery and i2c_generic_recovery are set up right now. > > AFAICT, these routines don't touch the muxing part at all. Perhaps it is done > internally by the GPIO calls. Can you please elaborate the exact change you > are > hinting towards here ? The i.MX I2C driver touches the pinctrl in its prepare/unprepare callbacks. So, on a i.MX or Vybrid, the call chain looks like this: i2c_generic_gpio_recovery -> i2c_get_gpios_for_recovery -> gpio_request_one -> i2c_generic_recovery -> prepare_recovery (i2c_imx_prepare_recovery) -> pinctrl_select_state [gpio] -> unprepare_recovery (i2c_imx_unprepare_recovery) -> pinctrl_select_state [default] -> i2c_put_gpios_for_recovery -> gpio_free And for the pinctrl/GPIO driver of Vybrid this is actually a problem because gpio_free disables the output driver of the pad, and when that happens after the (I2C) default pinctrl state gets selected the pad is no longer active. -- Stefan
[PATCH v7] QE: remove PPCisms for QE
QE was supported on PowerPC, and dependent on PPC, Now it is supported on other platforms. so remove PPCisms. Signed-off-by: Zhao Qiang--- Changes for v2: - na Changes for v3: - add NO_IRQ Changes for v4: - modify spin_event_timeout to opencoded timeout loop - remove NO_IRQ - modify virq_to_hw to opencoed code Changes for v5: - modify commit msg - modify depends of QUICC_ENGINE - add kerneldoc header for qe_issue_cmd Changes for v6: - add dependency on FSL_SOC and PPC32 for drivers depending on QUICC_ENGING but not available on ARM Changes for v7: - split qeic part to another patch - rebase drivers/net/ethernet/freescale/Kconfig | 10 ++--- drivers/soc/fsl/qe/Kconfig | 2 +- drivers/soc/fsl/qe/qe.c| 80 -- drivers/soc/fsl/qe/qe_io.c | 42 -- drivers/soc/fsl/qe/qe_tdm.c| 8 ++-- drivers/soc/fsl/qe/ucc.c | 10 ++--- drivers/soc/fsl/qe/ucc_fast.c | 68 ++--- drivers/tty/serial/Kconfig | 2 +- drivers/usb/gadget/udc/Kconfig | 2 +- drivers/usb/host/Kconfig | 2 +- include/soc/fsl/qe/qe.h| 1 - 11 files changed, 118 insertions(+), 109 deletions(-) diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig index d1ca45f..6677aff 100644 --- a/drivers/net/ethernet/freescale/Kconfig +++ b/drivers/net/ethernet/freescale/Kconfig @@ -5,10 +5,10 @@ config NET_VENDOR_FREESCALE bool "Freescale devices" default y - depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \ - M523x || M527x || M5272 || M528x || M520x || M532x || \ - ARCH_MXC || ARCH_MXS || (PPC_MPC52xx && PPC_BESTCOMM) || \ - ARCH_LAYERSCAPE + depends on FSL_SOC || (QUICC_ENGINE && PPC32) || CPM1 || CPM2 || \ + PPC_MPC512x || M523x || M527x || M5272 || M528x || M520x || \ + M532x || ARCH_MXC || ARCH_MXS || \ + (PPC_MPC52xx && PPC_BESTCOMM) || ARCH_LAYERSCAPE ---help--- If you have a network (Ethernet) card belonging to this class, say Y. @@ -72,7 +72,7 @@ config FSL_XGMAC_MDIO config UCC_GETH tristate "Freescale QE Gigabit Ethernet" - depends on QUICC_ENGINE + depends on QUICC_ENGINE && FSL_SOC && PPC32 select FSL_PQ_MDIO select PHYLIB ---help--- diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig index 73a2e08..b26b643 100644 --- a/drivers/soc/fsl/qe/Kconfig +++ b/drivers/soc/fsl/qe/Kconfig @@ -4,7 +4,7 @@ config QUICC_ENGINE bool "Freescale QUICC Engine (QE) Support" - depends on FSL_SOC && PPC32 + depends on OF && HAS_IOMEM select GENERIC_ALLOCATOR select CRC32 help diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index 2707a82..2b53e85 100644 --- a/drivers/soc/fsl/qe/qe.c +++ b/drivers/soc/fsl/qe/qe.c @@ -33,8 +33,6 @@ #include #include #include -#include -#include static void qe_snums_init(void); static int qe_sdma_init(void); @@ -109,15 +107,27 @@ void qe_reset(void) panic("sdma init failed!"); } +/* issue commands to QE, return 0 on success while -EIO on error + * + * @cmd: the command code, should be QE_INIT_TX_RX, QE_STOP_TX and so on + * @device: which sub-block will run the command, QE_CR_SUBBLOCK_UCCFAST1 - 8 + * , QE_CR_SUBBLOCK_UCCSLOW1 - 8, QE_CR_SUBBLOCK_MCC1 - 3, + * QE_CR_SUBBLOCK_IDMA1 - 4 and such on. + * @mcn_protocol: specifies mode for the command for non-MCC, should be + * QE_CR_PROTOCOL_HDLC_TRANSPARENT, QE_CR_PROTOCOL_QMC, QE_CR_PROTOCOL_UART + * and such on. + * @cmd_input: command related data. + */ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input) { unsigned long flags; u8 mcn_shift = 0, dev_shift = 0; - u32 ret; + int ret; + int i; spin_lock_irqsave(_lock, flags); if (cmd == QE_RESET) { - out_be32(_immr->cp.cecr, (u32) (cmd | QE_CR_FLG)); + iowrite32be((cmd | QE_CR_FLG), _immr->cp.cecr); } else { if (cmd == QE_ASSIGN_PAGE) { /* Here device is the SNUM, not sub-block */ @@ -134,20 +144,26 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input) mcn_shift = QE_CR_MCN_NORMAL_SHIFT; } - out_be32(_immr->cp.cecdr, cmd_input); - out_be32(_immr->cp.cecr, -(cmd | QE_CR_FLG | ((u32) device << dev_shift) | (u32) - mcn_protocol << mcn_shift)); + iowrite32be(cmd_input, _immr->cp.cecdr); + iowrite32be((cmd | QE_CR_FLG | ((u32)device << dev_shift) | +
[PATCH v7] QE: remove PPCisms for QE
QE was supported on PowerPC, and dependent on PPC, Now it is supported on other platforms. so remove PPCisms. Signed-off-by: Zhao Qiang --- Changes for v2: - na Changes for v3: - add NO_IRQ Changes for v4: - modify spin_event_timeout to opencoded timeout loop - remove NO_IRQ - modify virq_to_hw to opencoed code Changes for v5: - modify commit msg - modify depends of QUICC_ENGINE - add kerneldoc header for qe_issue_cmd Changes for v6: - add dependency on FSL_SOC and PPC32 for drivers depending on QUICC_ENGING but not available on ARM Changes for v7: - split qeic part to another patch - rebase drivers/net/ethernet/freescale/Kconfig | 10 ++--- drivers/soc/fsl/qe/Kconfig | 2 +- drivers/soc/fsl/qe/qe.c| 80 -- drivers/soc/fsl/qe/qe_io.c | 42 -- drivers/soc/fsl/qe/qe_tdm.c| 8 ++-- drivers/soc/fsl/qe/ucc.c | 10 ++--- drivers/soc/fsl/qe/ucc_fast.c | 68 ++--- drivers/tty/serial/Kconfig | 2 +- drivers/usb/gadget/udc/Kconfig | 2 +- drivers/usb/host/Kconfig | 2 +- include/soc/fsl/qe/qe.h| 1 - 11 files changed, 118 insertions(+), 109 deletions(-) diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig index d1ca45f..6677aff 100644 --- a/drivers/net/ethernet/freescale/Kconfig +++ b/drivers/net/ethernet/freescale/Kconfig @@ -5,10 +5,10 @@ config NET_VENDOR_FREESCALE bool "Freescale devices" default y - depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \ - M523x || M527x || M5272 || M528x || M520x || M532x || \ - ARCH_MXC || ARCH_MXS || (PPC_MPC52xx && PPC_BESTCOMM) || \ - ARCH_LAYERSCAPE + depends on FSL_SOC || (QUICC_ENGINE && PPC32) || CPM1 || CPM2 || \ + PPC_MPC512x || M523x || M527x || M5272 || M528x || M520x || \ + M532x || ARCH_MXC || ARCH_MXS || \ + (PPC_MPC52xx && PPC_BESTCOMM) || ARCH_LAYERSCAPE ---help--- If you have a network (Ethernet) card belonging to this class, say Y. @@ -72,7 +72,7 @@ config FSL_XGMAC_MDIO config UCC_GETH tristate "Freescale QE Gigabit Ethernet" - depends on QUICC_ENGINE + depends on QUICC_ENGINE && FSL_SOC && PPC32 select FSL_PQ_MDIO select PHYLIB ---help--- diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig index 73a2e08..b26b643 100644 --- a/drivers/soc/fsl/qe/Kconfig +++ b/drivers/soc/fsl/qe/Kconfig @@ -4,7 +4,7 @@ config QUICC_ENGINE bool "Freescale QUICC Engine (QE) Support" - depends on FSL_SOC && PPC32 + depends on OF && HAS_IOMEM select GENERIC_ALLOCATOR select CRC32 help diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index 2707a82..2b53e85 100644 --- a/drivers/soc/fsl/qe/qe.c +++ b/drivers/soc/fsl/qe/qe.c @@ -33,8 +33,6 @@ #include #include #include -#include -#include static void qe_snums_init(void); static int qe_sdma_init(void); @@ -109,15 +107,27 @@ void qe_reset(void) panic("sdma init failed!"); } +/* issue commands to QE, return 0 on success while -EIO on error + * + * @cmd: the command code, should be QE_INIT_TX_RX, QE_STOP_TX and so on + * @device: which sub-block will run the command, QE_CR_SUBBLOCK_UCCFAST1 - 8 + * , QE_CR_SUBBLOCK_UCCSLOW1 - 8, QE_CR_SUBBLOCK_MCC1 - 3, + * QE_CR_SUBBLOCK_IDMA1 - 4 and such on. + * @mcn_protocol: specifies mode for the command for non-MCC, should be + * QE_CR_PROTOCOL_HDLC_TRANSPARENT, QE_CR_PROTOCOL_QMC, QE_CR_PROTOCOL_UART + * and such on. + * @cmd_input: command related data. + */ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input) { unsigned long flags; u8 mcn_shift = 0, dev_shift = 0; - u32 ret; + int ret; + int i; spin_lock_irqsave(_lock, flags); if (cmd == QE_RESET) { - out_be32(_immr->cp.cecr, (u32) (cmd | QE_CR_FLG)); + iowrite32be((cmd | QE_CR_FLG), _immr->cp.cecr); } else { if (cmd == QE_ASSIGN_PAGE) { /* Here device is the SNUM, not sub-block */ @@ -134,20 +144,26 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input) mcn_shift = QE_CR_MCN_NORMAL_SHIFT; } - out_be32(_immr->cp.cecdr, cmd_input); - out_be32(_immr->cp.cecr, -(cmd | QE_CR_FLG | ((u32) device << dev_shift) | (u32) - mcn_protocol << mcn_shift)); + iowrite32be(cmd_input, _immr->cp.cecdr); + iowrite32be((cmd | QE_CR_FLG | ((u32)device << dev_shift) | +
[PATCH v6 3/4] irqchip/qeic: merge qeic_of_init into qe_ic_init
qeic_of_init just get device_node of qeic from dtb and call qe_ic_init, pass the device_node to qe_ic_init. So merge qeic_of_init into qe_ic_init to get the qeic node in qe_ic_init. Signed-off-by: Zhao Qiang--- Changes for v2: - modify subject and commit msg - return 0 and add put node when return in qe_ic_init Changes for v3: - na Changes for v4: - na Changes for v5: - na Changes for v6: - rebase drivers/irqchip/irq-qeic.c | 91 +- include/soc/fsl/qe/qe_ic.h | 7 2 files changed, 50 insertions(+), 48 deletions(-) diff --git a/drivers/irqchip/irq-qeic.c b/drivers/irqchip/irq-qeic.c index 1463731..4f49d4b 100644 --- a/drivers/irqchip/irq-qeic.c +++ b/drivers/irqchip/irq-qeic.c @@ -406,27 +406,38 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic) return irq_linear_revmap(qe_ic->irqhost, irq); } -void __init qe_ic_init(struct device_node *node, unsigned int flags, - void (*low_handler)(struct irq_desc *desc), - void (*high_handler)(struct irq_desc *desc)) +static int __init qe_ic_init(unsigned int flags) { + struct device_node *node; struct qe_ic *qe_ic; struct resource res; - u32 temp = 0, ret, high_active = 0; + u32 temp = 0, high_active = 0; + int ret = 0; + + node = of_find_compatible_node(NULL, NULL, "fsl,qe-ic"); + if (!node) { + node = of_find_node_by_type(NULL, "qeic"); + if (!node) + return -ENODEV; + } ret = of_address_to_resource(node, 0, ); - if (ret) - return; + if (ret) { + ret = -ENODEV; + goto err_put_node; + } qe_ic = kzalloc(sizeof(*qe_ic), GFP_KERNEL); - if (qe_ic == NULL) - return; + if (qe_ic == NULL) { + ret = -ENOMEM; + goto err_put_node; + } qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS, _ic_host_ops, qe_ic); if (qe_ic->irqhost == NULL) { - kfree(qe_ic); - return; + ret = -ENOMEM; + goto err_free_qe_ic; } qe_ic->regs = ioremap(res.start, resource_size()); @@ -437,9 +448,9 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags, qe_ic->virq_low = irq_of_parse_and_map(node, 1); if (qe_ic->virq_low == NO_IRQ) { - printk(KERN_ERR "Failed to map QE_IC low IRQ\n"); - kfree(qe_ic); - return; + pr_err("Failed to map QE_IC low IRQ\n"); + ret = -ENOMEM; + goto err_domain_remove; } /* default priority scheme is grouped. If spread mode is*/ @@ -466,13 +477,24 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags, qe_ic_write(qe_ic->regs, QEIC_CICR, temp); irq_set_handler_data(qe_ic->virq_low, qe_ic); - irq_set_chained_handler(qe_ic->virq_low, low_handler); + irq_set_chained_handler(qe_ic->virq_low, qe_ic_cascade_low_mpic); if (qe_ic->virq_high != NO_IRQ && qe_ic->virq_high != qe_ic->virq_low) { irq_set_handler_data(qe_ic->virq_high, qe_ic); - irq_set_chained_handler(qe_ic->virq_high, high_handler); + irq_set_chained_handler(qe_ic->virq_high, + qe_ic_cascade_high_mpic); } + of_node_put(node); + return 0; + +err_domain_remove: + irq_domain_remove(qe_ic->irqhost); +err_free_qe_ic: + kfree(qe_ic); +err_put_node: + of_node_put(node); + return ret; } void qe_ic_set_highest_priority(unsigned int virq, int high) @@ -579,39 +601,26 @@ static struct device device_qe_ic = { .bus = _ic_subsys, }; -static int __init init_qe_ic_sysfs(void) +static int __init init_qe_ic(void) { - int rc; + int ret; - printk(KERN_DEBUG "Registering qe_ic with sysfs...\n"); + ret = qe_ic_init(0); + if (ret) + return ret; - rc = subsys_system_register(_ic_subsys, NULL); - if (rc) { - printk(KERN_ERR "Failed registering qe_ic sys class\n"); + ret = subsys_system_register(_ic_subsys, NULL); + if (ret) { + pr_err("Failed registering qe_ic sys class\n"); return -ENODEV; } - rc = device_register(_qe_ic); - if (rc) { - printk(KERN_ERR "Failed registering qe_ic sys device\n"); + ret = device_register(_qe_ic); + if (ret) { + pr_err("Failed registering qe_ic sys device\n"); return -ENODEV; } - return 0; -} - -static int __init qeic_of_init(void) -{ - struct device_node *np; - np =
[PATCH v6 3/4] irqchip/qeic: merge qeic_of_init into qe_ic_init
qeic_of_init just get device_node of qeic from dtb and call qe_ic_init, pass the device_node to qe_ic_init. So merge qeic_of_init into qe_ic_init to get the qeic node in qe_ic_init. Signed-off-by: Zhao Qiang --- Changes for v2: - modify subject and commit msg - return 0 and add put node when return in qe_ic_init Changes for v3: - na Changes for v4: - na Changes for v5: - na Changes for v6: - rebase drivers/irqchip/irq-qeic.c | 91 +- include/soc/fsl/qe/qe_ic.h | 7 2 files changed, 50 insertions(+), 48 deletions(-) diff --git a/drivers/irqchip/irq-qeic.c b/drivers/irqchip/irq-qeic.c index 1463731..4f49d4b 100644 --- a/drivers/irqchip/irq-qeic.c +++ b/drivers/irqchip/irq-qeic.c @@ -406,27 +406,38 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic) return irq_linear_revmap(qe_ic->irqhost, irq); } -void __init qe_ic_init(struct device_node *node, unsigned int flags, - void (*low_handler)(struct irq_desc *desc), - void (*high_handler)(struct irq_desc *desc)) +static int __init qe_ic_init(unsigned int flags) { + struct device_node *node; struct qe_ic *qe_ic; struct resource res; - u32 temp = 0, ret, high_active = 0; + u32 temp = 0, high_active = 0; + int ret = 0; + + node = of_find_compatible_node(NULL, NULL, "fsl,qe-ic"); + if (!node) { + node = of_find_node_by_type(NULL, "qeic"); + if (!node) + return -ENODEV; + } ret = of_address_to_resource(node, 0, ); - if (ret) - return; + if (ret) { + ret = -ENODEV; + goto err_put_node; + } qe_ic = kzalloc(sizeof(*qe_ic), GFP_KERNEL); - if (qe_ic == NULL) - return; + if (qe_ic == NULL) { + ret = -ENOMEM; + goto err_put_node; + } qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS, _ic_host_ops, qe_ic); if (qe_ic->irqhost == NULL) { - kfree(qe_ic); - return; + ret = -ENOMEM; + goto err_free_qe_ic; } qe_ic->regs = ioremap(res.start, resource_size()); @@ -437,9 +448,9 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags, qe_ic->virq_low = irq_of_parse_and_map(node, 1); if (qe_ic->virq_low == NO_IRQ) { - printk(KERN_ERR "Failed to map QE_IC low IRQ\n"); - kfree(qe_ic); - return; + pr_err("Failed to map QE_IC low IRQ\n"); + ret = -ENOMEM; + goto err_domain_remove; } /* default priority scheme is grouped. If spread mode is*/ @@ -466,13 +477,24 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags, qe_ic_write(qe_ic->regs, QEIC_CICR, temp); irq_set_handler_data(qe_ic->virq_low, qe_ic); - irq_set_chained_handler(qe_ic->virq_low, low_handler); + irq_set_chained_handler(qe_ic->virq_low, qe_ic_cascade_low_mpic); if (qe_ic->virq_high != NO_IRQ && qe_ic->virq_high != qe_ic->virq_low) { irq_set_handler_data(qe_ic->virq_high, qe_ic); - irq_set_chained_handler(qe_ic->virq_high, high_handler); + irq_set_chained_handler(qe_ic->virq_high, + qe_ic_cascade_high_mpic); } + of_node_put(node); + return 0; + +err_domain_remove: + irq_domain_remove(qe_ic->irqhost); +err_free_qe_ic: + kfree(qe_ic); +err_put_node: + of_node_put(node); + return ret; } void qe_ic_set_highest_priority(unsigned int virq, int high) @@ -579,39 +601,26 @@ static struct device device_qe_ic = { .bus = _ic_subsys, }; -static int __init init_qe_ic_sysfs(void) +static int __init init_qe_ic(void) { - int rc; + int ret; - printk(KERN_DEBUG "Registering qe_ic with sysfs...\n"); + ret = qe_ic_init(0); + if (ret) + return ret; - rc = subsys_system_register(_ic_subsys, NULL); - if (rc) { - printk(KERN_ERR "Failed registering qe_ic sys class\n"); + ret = subsys_system_register(_ic_subsys, NULL); + if (ret) { + pr_err("Failed registering qe_ic sys class\n"); return -ENODEV; } - rc = device_register(_qe_ic); - if (rc) { - printk(KERN_ERR "Failed registering qe_ic sys device\n"); + ret = device_register(_qe_ic); + if (ret) { + pr_err("Failed registering qe_ic sys device\n"); return -ENODEV; } - return 0; -} - -static int __init qeic_of_init(void) -{ - struct device_node *np; - np = of_find_compatible_node(NULL,
Re: [PATCH 2/3] DT: EVM: add LEDs
* H. Nikolaus Schaller[160927 13:11]: > > Am 27.09.2016 um 21:49 schrieb Tony Lindgren : > > How about this for defaults: > > > > - heartbeat for led3 > > - cpu0 for led4 > > - cpu1 for led5 > > Good idea. Will try. > > What I don't exactly know is if these gpios based on an I2C-expander > can handle cpu activity triggers or if they are locked up if this i2c > processing triggers another cpu activity... Oh right, if the GPIOs are on the i2c bus it's probably not a good idea :) Or at least will be inaccurate if the bus can sleep. Regards, Tony
Re: [PATCH 2/3] DT: EVM: add LEDs
* H. Nikolaus Schaller [160927 13:11]: > > Am 27.09.2016 um 21:49 schrieb Tony Lindgren : > > How about this for defaults: > > > > - heartbeat for led3 > > - cpu0 for led4 > > - cpu1 for led5 > > Good idea. Will try. > > What I don't exactly know is if these gpios based on an I2C-expander > can handle cpu activity triggers or if they are locked up if this i2c > processing triggers another cpu activity... Oh right, if the GPIOs are on the i2c bus it's probably not a good idea :) Or at least will be inaccurate if the bus can sleep. Regards, Tony
[PATCH 2/2] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily
We have report that the intel_lpss_prepare() takes too much time during suspend, and this is because we first resume the devices from runtime suspend by resume_lpss_device(), to make sure they are in proper state before system suspend, which takes 100ms for each LPSS devices(PCI power state from D3_cold to D0). And since resume_lpss_device() resumes the devices synchronously, we might get huge latency if we have many LPSS devices. So first try is to use pm_request_resume() instead, to make the runtime resume process asynchronously. Unfortunately the asynchronous runtime resume relies on pm_wq, which is freezed at early stage. So we choose another method, that is to avoid resuming runtime-suspended devices, if they are already runtime suspended. This is safe because for LPSS driver, the runtime suspend and system suspend are of the same hook - i.e., intel_lpss_suspend(). And moreover, this device is neither runtime wakeup source nor system wakeup source. Acked-by: Mika WesterbergReviewed-by: Andy Shevchenko Cc: Andy Shevchenko Cc: Mika Westerberg Cc: Rafael J. Wysocki Signed-off-by: Chen Yu --- drivers/mfd/intel-lpss.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c index 41b1138..2ba8d19 100644 --- a/drivers/mfd/intel-lpss.c +++ b/drivers/mfd/intel-lpss.c @@ -485,6 +485,15 @@ static int resume_lpss_device(struct device *dev, void *data) int intel_lpss_prepare(struct device *dev) { /* +* This is safe because: +* 1. The runtime suspend and system suspend +* are of the same hook. +* 2. This device is neither runtime wakeup source +* nor system wakeup source. +*/ + if (pm_runtime_status_suspended(dev)) + return RPM_SUSPENDED; + /* * Resume both child devices before entering system sleep. This * ensures that they are in proper state before they get suspended. */ -- 2.7.4
[PATCH 2/2] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily
We have report that the intel_lpss_prepare() takes too much time during suspend, and this is because we first resume the devices from runtime suspend by resume_lpss_device(), to make sure they are in proper state before system suspend, which takes 100ms for each LPSS devices(PCI power state from D3_cold to D0). And since resume_lpss_device() resumes the devices synchronously, we might get huge latency if we have many LPSS devices. So first try is to use pm_request_resume() instead, to make the runtime resume process asynchronously. Unfortunately the asynchronous runtime resume relies on pm_wq, which is freezed at early stage. So we choose another method, that is to avoid resuming runtime-suspended devices, if they are already runtime suspended. This is safe because for LPSS driver, the runtime suspend and system suspend are of the same hook - i.e., intel_lpss_suspend(). And moreover, this device is neither runtime wakeup source nor system wakeup source. Acked-by: Mika Westerberg Reviewed-by: Andy Shevchenko Cc: Andy Shevchenko Cc: Mika Westerberg Cc: Rafael J. Wysocki Signed-off-by: Chen Yu --- drivers/mfd/intel-lpss.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c index 41b1138..2ba8d19 100644 --- a/drivers/mfd/intel-lpss.c +++ b/drivers/mfd/intel-lpss.c @@ -485,6 +485,15 @@ static int resume_lpss_device(struct device *dev, void *data) int intel_lpss_prepare(struct device *dev) { /* +* This is safe because: +* 1. The runtime suspend and system suspend +* are of the same hook. +* 2. This device is neither runtime wakeup source +* nor system wakeup source. +*/ + if (pm_runtime_status_suspended(dev)) + return RPM_SUSPENDED; + /* * Resume both child devices before entering system sleep. This * ensures that they are in proper state before they get suspended. */ -- 2.7.4
[PATCH 0/2] Define positive return value to RPM_SUSPEND for runtime-suspended devices
This patch set is to define the positive value returned by device .prepare() callbacks, which is used to indicate the devices are OK to remain in runtime-suspended during system sleep. A precise return value would make the code more readable. Based on this definition, optimized the suspend process in intel-lpss driver. Chen Yu (2): PM / sleep: Return RPM_SUSPENDED to keep devices in runtime-suspended mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily Documentation/power/devices.txt| 8 Documentation/power/runtime_pm.txt | 2 +- drivers/base/power/main.c | 8 ++-- drivers/mfd/intel-lpss.c | 9 + 4 files changed, 20 insertions(+), 7 deletions(-) -- 2.7.4
[PATCH 0/2] Define positive return value to RPM_SUSPEND for runtime-suspended devices
This patch set is to define the positive value returned by device .prepare() callbacks, which is used to indicate the devices are OK to remain in runtime-suspended during system sleep. A precise return value would make the code more readable. Based on this definition, optimized the suspend process in intel-lpss driver. Chen Yu (2): PM / sleep: Return RPM_SUSPENDED to keep devices in runtime-suspended mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily Documentation/power/devices.txt| 8 Documentation/power/runtime_pm.txt | 2 +- drivers/base/power/main.c | 8 ++-- drivers/mfd/intel-lpss.c | 9 + 4 files changed, 20 insertions(+), 7 deletions(-) -- 2.7.4
[PATCH 1/2] PM / sleep: Return RPM_SUSPENDED to keep devices in runtime-suspended
Currently if the ->prepare() callback of a device returns a positive number, the PM core will regard that as an indication that it may leave the device runtime-suspended. However it would be more convenient to define this positive number then makes it more maintainable. Consider there might be already some device drivers using different positive values, this patch prints a warning if the positive value is other than RPM_SUSPENDED, and hoping driver developers would adjust their return values to RPM_SUSPENDED, then at last we can modify the code to only enable this feature for values return of RPM_SUSPENDED rather than arbitrary positive value. Suggested-by: Lee JonesSuggested-by: Rafael J. Wysocki Signed-off-by: Chen Yu --- Documentation/power/devices.txt| 8 Documentation/power/runtime_pm.txt | 2 +- drivers/base/power/main.c | 8 ++-- 3 files changed, 11 insertions(+), 7 deletions(-) diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 8ba6625..fc585a5 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -331,8 +331,8 @@ the phases are: prepare callback can be used to indicate to the PM core that it may safely leave the device in runtime suspend (if runtime-suspended already), provided that all of the device's descendants are also left in - runtime suspend. Namely, if the prepare callback returns a positive - number and that happens for all of the descendants of the device too, + runtime suspend. Namely, if the prepare callback returns RPM_SUSPENDED + and that happens for all of the descendants of the device too, and all of them (including the device itself) are runtime-suspended, the PM core will skip the suspend, suspend_late and suspend_noirq suspend phases as well as the resume_noirq, resume_early and resume phases of @@ -344,7 +344,7 @@ the phases are: Note that this direct-complete procedure applies even if the device is disabled for runtime PM; only the runtime-PM status matters. It follows that if a device has system-sleep callbacks but does not support runtime - PM, then its prepare callback must never return a positive value. This + PM, then its prepare callback must never return RPM_SUSPENDED. This is because all devices are initially set to runtime-suspended with runtime PM disabled. @@ -422,7 +422,7 @@ When resuming from freeze, standby or memory sleep, the phases are: the resume callbacks occur; it's not necessary to wait until the complete phase. - Moreover, if the preceding prepare callback returned a positive number, + Moreover, if the preceding prepare callback returned RPM_SUSPENDED, the device may have been left in runtime suspend throughout the whole system suspend and resume (the suspend, suspend_late, suspend_noirq phases of system suspend and the resume_noirq, resume_early, resume diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 1fd1fbe..5316daf 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -667,7 +667,7 @@ suspend began in the suspended state. To this end, the PM core provides a mechanism allowing some coordination between different levels of device hierarchy. Namely, if a system suspend .prepare() -callback returns a positive number for a device, that indicates to the PM core +callback returns RPM_SUSPENDED for a device, that indicates to the PM core that the device appears to be runtime-suspended and its state is fine, so it may be left in runtime suspend provided that all of its descendants are also left in runtime suspend. If that happens, the PM core will not execute any diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index e44944f..03a047e 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -1603,14 +1603,18 @@ unlock: return ret; } /* -* A positive return value from ->prepare() means "this device appears +* A return value of RPM_SUSPENDED from ->prepare() means "this device appears * to be runtime-suspended and its state is fine, so if it really is * runtime-suspended, you can leave it in that state provided that you * will do the same thing with all of its descendants". This only * applies to suspend transitions, however. */ spin_lock_irq(>power.lock); - dev->power.direct_complete = ret > 0 && state.event == PM_EVENT_SUSPEND; + if (ret > 0 && state.event == PM_EVENT_SUSPEND) { + dev->power.direct_complete = true; + if (ret != RPM_SUSPENDED) + dev_warn(dev, "->prepare() should return RPM_SUSPENDED.\n"); + }
[PATCH 1/2] PM / sleep: Return RPM_SUSPENDED to keep devices in runtime-suspended
Currently if the ->prepare() callback of a device returns a positive number, the PM core will regard that as an indication that it may leave the device runtime-suspended. However it would be more convenient to define this positive number then makes it more maintainable. Consider there might be already some device drivers using different positive values, this patch prints a warning if the positive value is other than RPM_SUSPENDED, and hoping driver developers would adjust their return values to RPM_SUSPENDED, then at last we can modify the code to only enable this feature for values return of RPM_SUSPENDED rather than arbitrary positive value. Suggested-by: Lee Jones Suggested-by: Rafael J. Wysocki Signed-off-by: Chen Yu --- Documentation/power/devices.txt| 8 Documentation/power/runtime_pm.txt | 2 +- drivers/base/power/main.c | 8 ++-- 3 files changed, 11 insertions(+), 7 deletions(-) diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 8ba6625..fc585a5 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -331,8 +331,8 @@ the phases are: prepare callback can be used to indicate to the PM core that it may safely leave the device in runtime suspend (if runtime-suspended already), provided that all of the device's descendants are also left in - runtime suspend. Namely, if the prepare callback returns a positive - number and that happens for all of the descendants of the device too, + runtime suspend. Namely, if the prepare callback returns RPM_SUSPENDED + and that happens for all of the descendants of the device too, and all of them (including the device itself) are runtime-suspended, the PM core will skip the suspend, suspend_late and suspend_noirq suspend phases as well as the resume_noirq, resume_early and resume phases of @@ -344,7 +344,7 @@ the phases are: Note that this direct-complete procedure applies even if the device is disabled for runtime PM; only the runtime-PM status matters. It follows that if a device has system-sleep callbacks but does not support runtime - PM, then its prepare callback must never return a positive value. This + PM, then its prepare callback must never return RPM_SUSPENDED. This is because all devices are initially set to runtime-suspended with runtime PM disabled. @@ -422,7 +422,7 @@ When resuming from freeze, standby or memory sleep, the phases are: the resume callbacks occur; it's not necessary to wait until the complete phase. - Moreover, if the preceding prepare callback returned a positive number, + Moreover, if the preceding prepare callback returned RPM_SUSPENDED, the device may have been left in runtime suspend throughout the whole system suspend and resume (the suspend, suspend_late, suspend_noirq phases of system suspend and the resume_noirq, resume_early, resume diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 1fd1fbe..5316daf 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -667,7 +667,7 @@ suspend began in the suspended state. To this end, the PM core provides a mechanism allowing some coordination between different levels of device hierarchy. Namely, if a system suspend .prepare() -callback returns a positive number for a device, that indicates to the PM core +callback returns RPM_SUSPENDED for a device, that indicates to the PM core that the device appears to be runtime-suspended and its state is fine, so it may be left in runtime suspend provided that all of its descendants are also left in runtime suspend. If that happens, the PM core will not execute any diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index e44944f..03a047e 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -1603,14 +1603,18 @@ unlock: return ret; } /* -* A positive return value from ->prepare() means "this device appears +* A return value of RPM_SUSPENDED from ->prepare() means "this device appears * to be runtime-suspended and its state is fine, so if it really is * runtime-suspended, you can leave it in that state provided that you * will do the same thing with all of its descendants". This only * applies to suspend transitions, however. */ spin_lock_irq(>power.lock); - dev->power.direct_complete = ret > 0 && state.event == PM_EVENT_SUSPEND; + if (ret > 0 && state.event == PM_EVENT_SUSPEND) { + dev->power.direct_complete = true; + if (ret != RPM_SUSPENDED) + dev_warn(dev, "->prepare() should return RPM_SUSPENDED.\n"); + } spin_unlock_irq(>power.lock); return 0; } -- 2.7.4
Re: [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing
On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote: > Hi, > > Changes since v2: > - Instead of converting to use enum for the of_device_id data parameter the > two > patch for edma and ti-dma-crossbar is using pointers to u32 variables to > make > sure that the code compile (and in theory work) on all architectures. > - fixed issue in the ti-dma-crossbar driver I have made with the enum change > to > not handle the DMA offset parameters correctly. > > Changes since v1: > - added the compiler warning message to ti-dma-crossbar enum type patch > - moved the Kconfig patches at the end of the seris > > The following series will enable unconditional COMPILE_TEST coverage for the > following drivers: omap-dma, edma and ti-dma-crossbar > > The series includes fixes noticed when compiling the drivers for x86_64 and > aarch64. I have applied the series after fixing code style nit-picks. Also applied the edma patch and reordered the series to have that come before compile test enable patch Please verify. Thanks -- ~Vinod
Re: [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing
On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote: > Hi, > > Changes since v2: > - Instead of converting to use enum for the of_device_id data parameter the > two > patch for edma and ti-dma-crossbar is using pointers to u32 variables to > make > sure that the code compile (and in theory work) on all architectures. > - fixed issue in the ti-dma-crossbar driver I have made with the enum change > to > not handle the DMA offset parameters correctly. > > Changes since v1: > - added the compiler warning message to ti-dma-crossbar enum type patch > - moved the Kconfig patches at the end of the seris > > The following series will enable unconditional COMPILE_TEST coverage for the > following drivers: omap-dma, edma and ti-dma-crossbar > > The series includes fixes noticed when compiling the drivers for x86_64 and > aarch64. I have applied the series after fixing code style nit-picks. Also applied the edma patch and reordered the series to have that come before compile test enable patch Please verify. Thanks -- ~Vinod
[PATCH] Fixes: 3d44a78f0d8b ("staging: rtl8712: Remove unnecessary 'else'")
An "unnecessary" 'else' was removed due to complains from checkpatch.pl as it is preceded by a 'return', however the 'else' branch is necessary as an earlier branch of the 'if' falls through. By removing the 'else', that route now hits the 'break' and the 'while' loop exits prematurely. This commit reverts that change and puts the original 'else' back in place. Signed-off-by: Matthew Kilgore--- drivers/staging/rtl8712/rtl8712_recv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/rtl8712/rtl8712_recv.c b/drivers/staging/rtl8712/rtl8712_recv.c index cf46592be472..66f0e0a35167 100644 --- a/drivers/staging/rtl8712/rtl8712_recv.c +++ b/drivers/staging/rtl8712/rtl8712_recv.c @@ -508,7 +508,8 @@ static int enqueue_reorder_recvframe(struct recv_reorder_ctrl *preorder_ctrl, plist = plist->next; else if (SN_EQUAL(pnextattrib->seq_num, pattrib->seq_num)) return false; - break; + else + break; } list_del_init(&(prframe->u.hdr.list)); list_add_tail(&(prframe->u.hdr.list), plist); -- 2.10.0
[PATCH] Fixes: 3d44a78f0d8b ("staging: rtl8712: Remove unnecessary 'else'")
An "unnecessary" 'else' was removed due to complains from checkpatch.pl as it is preceded by a 'return', however the 'else' branch is necessary as an earlier branch of the 'if' falls through. By removing the 'else', that route now hits the 'break' and the 'while' loop exits prematurely. This commit reverts that change and puts the original 'else' back in place. Signed-off-by: Matthew Kilgore --- drivers/staging/rtl8712/rtl8712_recv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/rtl8712/rtl8712_recv.c b/drivers/staging/rtl8712/rtl8712_recv.c index cf46592be472..66f0e0a35167 100644 --- a/drivers/staging/rtl8712/rtl8712_recv.c +++ b/drivers/staging/rtl8712/rtl8712_recv.c @@ -508,7 +508,8 @@ static int enqueue_reorder_recvframe(struct recv_reorder_ctrl *preorder_ctrl, plist = plist->next; else if (SN_EQUAL(pnextattrib->seq_num, pattrib->seq_num)) return false; - break; + else + break; } list_del_init(&(prframe->u.hdr.list)); list_add_tail(&(prframe->u.hdr.list), plist); -- 2.10.0
Re: [PATCH v3 6/9] dmaengine: ti-dma-crossbar: Fix of_device_id data parameter usage
On Wed, Sep 21, 2016 at 03:41:32PM +0300, Peter Ujfalusi wrote: > @@ -395,7 +403,7 @@ static int ti_dra7_xbar_probe(struct platform_device > *pdev) > > xbar->dmarouter.dev = >dev; > xbar->dmarouter.route_free = ti_dra7_xbar_free; > - xbar->dma_offset = (u32)match->data; > + xbar->dma_offset = *(u32*)match->data; we need space between u32 and * > mutex_init(>mutex); > platform_set_drvdata(pdev, xbar); > @@ -428,7 +436,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev) > if (unlikely(!match)) > return -EINVAL; > > - switch ((u32)match->data) { > + switch (*(u32*)match->data) { here too please -- ~Vinod
Re: [PATCH v3 6/9] dmaengine: ti-dma-crossbar: Fix of_device_id data parameter usage
On Wed, Sep 21, 2016 at 03:41:32PM +0300, Peter Ujfalusi wrote: > @@ -395,7 +403,7 @@ static int ti_dra7_xbar_probe(struct platform_device > *pdev) > > xbar->dmarouter.dev = >dev; > xbar->dmarouter.route_free = ti_dra7_xbar_free; > - xbar->dma_offset = (u32)match->data; > + xbar->dma_offset = *(u32*)match->data; we need space between u32 and * > mutex_init(>mutex); > platform_set_drvdata(pdev, xbar); > @@ -428,7 +436,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev) > if (unlikely(!match)) > return -EINVAL; > > - switch ((u32)match->data) { > + switch (*(u32*)match->data) { here too please -- ~Vinod
Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers
On 09/26/2016 05:25 PM, Lee Duncan wrote: > Chris Leech and I are taking over as open-iscsi maintainers. > > Changes since v1: > * Updated URL to open-iscsi.com > * Removed git repository, since code in tree > --- > MAINTAINERS | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 01bff8ea28d8..81384a2562e7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6448,10 +6448,10 @@ S:Maintained > F: drivers/firmware/iscsi_ibft* > > ISCSI > -M: Mike Christie> +M: Lee Duncan > +M: Chris Leech > L: open-is...@googlegroups.com > -W: www.open-iscsi.org > -T: git > git://git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git > +W: www.open-iscsi.com > S: Maintained > F: drivers/scsi/*iscsi* > F: include/scsi/*iscsi* > After over 10 years, I will get to take a vacation where I do not have to think about iSCSI :) Reviewed-by: Mike Christie
[PATCH V2] checkpatch: Improve the octal permissions tests
The function calls with octal permissions commonly span multiple lines. The current test is line oriented and fails to find some matches. Make the test use the $stat variable instead of the $line variable to span multiple lines. Also add a few functions to the known functions with permissions list. Move the SYMBOLIC_PERMS test to a separate section to find all the S_ permissions in any form not just those that have specific function names. This can now find and fix permissions uses like: .mode = S_ | S_; Signed-off-by: Joe Perches--- V2: Move the SYMBOLIC_PERMS test. scripts/checkpatch.pl | 60 +-- 1 file changed, 44 insertions(+), 16 deletions(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 0ef3d837f2aa..22055004c56a 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -524,7 +524,11 @@ our @mode_permission_funcs = ( ["module_param_array_named", 5], ["debugfs_create_(?:file|u8|u16|u32|u64|x8|x16|x32|x64|size_t|atomic_t|bool|blob|regset32|u32_array)", 2], ["proc_create(?:_data|)", 2], - ["(?:CLASS|DEVICE|SENSOR)_ATTR", 2], + ["(?:CLASS|DEVICE|SENSOR|SENSOR_DEVICE|IIO_DEVICE)_ATTR", 2], + ["IIO_DEV_ATTR_[A-Z_]+", 1], + ["SENSOR_(?:DEVICE_|)ATTR_2", 2], + ["SENSOR_TEMPLATE(?:_2|)", 3], + ["__ATTR", 2], ); #Create a search pattern for all these functions to speed up a loop below @@ -6079,45 +6083,69 @@ sub process { # Mode permission misuses where it seems decimal should be octal # This uses a shortcut match to avoid unnecessary uses of a slow foreach loop if ($^V && $^V ge 5.10.0 && + defined $stat && $line =~ /$mode_perms_search/) { foreach my $entry (@mode_permission_funcs) { my $func = $entry->[0]; my $arg_pos = $entry->[1]; + my $lc = $stat =~ tr@\n@@; + $lc = $lc + $linenr; + my $stat_real = raw_line($linenr, 0); + for (my $count = $linenr + 1; $count <= $lc; $count++) { + $stat_real = $stat_real . "\n" . raw_line($count, 0); + } + my $skip_args = ""; if ($arg_pos > 1) { $arg_pos--; $skip_args = "(?:\\s*$FuncArg\\s*,\\s*){$arg_pos,$arg_pos}"; } my $test = "\\b$func\\s*\\(${skip_args}($FuncArg(?:\\|\\s*$FuncArg)*)\\s*[,\\)]"; - if ($line =~ /$test/) { + if ($stat =~ /$test/) { my $val = $1; $val = $6 if ($skip_args ne ""); if (($val =~ /^$Int$/ && $val !~ /^$Octal$/) || ($val =~ /^$Octal$/ && length($val) ne 4)) { ERROR("NON_OCTAL_PERMISSIONS", - "Use 4 digit octal (0777) not decimal permissions\n" . $herecurr); + "Use 4 digit octal (0777) not decimal permissions\n" . "$here\n" . $stat_real); } if ($val =~ /^$Octal$/ && (oct($val) & 02)) { ERROR("EXPORTED_WORLD_WRITABLE", - "Exporting writable files is usually an error. Consider more restrictive permissions.\n" . $herecurr); - } - if ($val =~ /\b$mode_perms_string_search\b/) { - my $to = 0; - while ($val =~ /\b($mode_perms_string_search)\b(?:\s*\|\s*)?\s*/g) { - $to |= $mode_permission_string_types{$1}; - } - my $new = sprintf("%04o", $to); - if (WARN("SYMBOLIC_PERMS", -"Symbolic permissions are not preferred. Consider using octal permissions $new.\n" . $herecurr) && - $fix) { - $fixed[$fixlinenr] =~ s/\Q$val\E/$new/; - } + "Exporting writable files is usually an error.
Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers
On 09/26/2016 05:25 PM, Lee Duncan wrote: > Chris Leech and I are taking over as open-iscsi maintainers. > > Changes since v1: > * Updated URL to open-iscsi.com > * Removed git repository, since code in tree > --- > MAINTAINERS | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 01bff8ea28d8..81384a2562e7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6448,10 +6448,10 @@ S:Maintained > F: drivers/firmware/iscsi_ibft* > > ISCSI > -M: Mike Christie > +M: Lee Duncan > +M: Chris Leech > L: open-is...@googlegroups.com > -W: www.open-iscsi.org > -T: git > git://git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git > +W: www.open-iscsi.com > S: Maintained > F: drivers/scsi/*iscsi* > F: include/scsi/*iscsi* > After over 10 years, I will get to take a vacation where I do not have to think about iSCSI :) Reviewed-by: Mike Christie
[PATCH V2] checkpatch: Improve the octal permissions tests
The function calls with octal permissions commonly span multiple lines. The current test is line oriented and fails to find some matches. Make the test use the $stat variable instead of the $line variable to span multiple lines. Also add a few functions to the known functions with permissions list. Move the SYMBOLIC_PERMS test to a separate section to find all the S_ permissions in any form not just those that have specific function names. This can now find and fix permissions uses like: .mode = S_ | S_; Signed-off-by: Joe Perches --- V2: Move the SYMBOLIC_PERMS test. scripts/checkpatch.pl | 60 +-- 1 file changed, 44 insertions(+), 16 deletions(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 0ef3d837f2aa..22055004c56a 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -524,7 +524,11 @@ our @mode_permission_funcs = ( ["module_param_array_named", 5], ["debugfs_create_(?:file|u8|u16|u32|u64|x8|x16|x32|x64|size_t|atomic_t|bool|blob|regset32|u32_array)", 2], ["proc_create(?:_data|)", 2], - ["(?:CLASS|DEVICE|SENSOR)_ATTR", 2], + ["(?:CLASS|DEVICE|SENSOR|SENSOR_DEVICE|IIO_DEVICE)_ATTR", 2], + ["IIO_DEV_ATTR_[A-Z_]+", 1], + ["SENSOR_(?:DEVICE_|)ATTR_2", 2], + ["SENSOR_TEMPLATE(?:_2|)", 3], + ["__ATTR", 2], ); #Create a search pattern for all these functions to speed up a loop below @@ -6079,45 +6083,69 @@ sub process { # Mode permission misuses where it seems decimal should be octal # This uses a shortcut match to avoid unnecessary uses of a slow foreach loop if ($^V && $^V ge 5.10.0 && + defined $stat && $line =~ /$mode_perms_search/) { foreach my $entry (@mode_permission_funcs) { my $func = $entry->[0]; my $arg_pos = $entry->[1]; + my $lc = $stat =~ tr@\n@@; + $lc = $lc + $linenr; + my $stat_real = raw_line($linenr, 0); + for (my $count = $linenr + 1; $count <= $lc; $count++) { + $stat_real = $stat_real . "\n" . raw_line($count, 0); + } + my $skip_args = ""; if ($arg_pos > 1) { $arg_pos--; $skip_args = "(?:\\s*$FuncArg\\s*,\\s*){$arg_pos,$arg_pos}"; } my $test = "\\b$func\\s*\\(${skip_args}($FuncArg(?:\\|\\s*$FuncArg)*)\\s*[,\\)]"; - if ($line =~ /$test/) { + if ($stat =~ /$test/) { my $val = $1; $val = $6 if ($skip_args ne ""); if (($val =~ /^$Int$/ && $val !~ /^$Octal$/) || ($val =~ /^$Octal$/ && length($val) ne 4)) { ERROR("NON_OCTAL_PERMISSIONS", - "Use 4 digit octal (0777) not decimal permissions\n" . $herecurr); + "Use 4 digit octal (0777) not decimal permissions\n" . "$here\n" . $stat_real); } if ($val =~ /^$Octal$/ && (oct($val) & 02)) { ERROR("EXPORTED_WORLD_WRITABLE", - "Exporting writable files is usually an error. Consider more restrictive permissions.\n" . $herecurr); - } - if ($val =~ /\b$mode_perms_string_search\b/) { - my $to = 0; - while ($val =~ /\b($mode_perms_string_search)\b(?:\s*\|\s*)?\s*/g) { - $to |= $mode_permission_string_types{$1}; - } - my $new = sprintf("%04o", $to); - if (WARN("SYMBOLIC_PERMS", -"Symbolic permissions are not preferred. Consider using octal permissions $new.\n" . $herecurr) && - $fix) { - $fixed[$fixlinenr] =~ s/\Q$val\E/$new/; - } + "Exporting writable files is usually an error. Consider more
Re: [PATCH v5] powerpc: Do not make the entire heap executable
On Wed, Sep 28, 2016 at 11:42:11AM +1000, Michael Ellerman wrote: > But this is not really a powerpc patch, and I'm not an ELF expert. So > I'm not comfortable merging it via the powerpc tree. It doesn't look > like we really have a maintainer for binfmt_elf.c, so I'm not sure who > should be acking that part. Thanks a bunch for looking at this Michael. > I've added Al Viro to Cc, he maintains fs/ and might be interested. > I've also added Andrew Morton who might be happy to put this in his > tree, and see if anyone complains? For those added to the CC, I would re-state my original commit message more clearly. My research showed that the ELF loader bug fixed in this patch is the root cause bug fix required to implement this hunk: > > -#define VM_DATA_DEFAULT_FLAGS32(VM_READ | VM_WRITE | VM_EXEC | \ > > +#define VM_DATA_DEFAULT_FLAGS32 \ > > + (((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0) | \ > > +VM_READ | VM_WRITE | \ > > VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) Eg that 32 bit powerpc currently unconditionally injects writable, executable pages into a user space process. This critically undermines all the W^X security work that has been done in the tool chain and user space by the PPC community. I would encourage people to view this as an important security patch for 32 bit powerpc environments. Regards, Jason
Re: [PATCH v5] powerpc: Do not make the entire heap executable
On Wed, Sep 28, 2016 at 11:42:11AM +1000, Michael Ellerman wrote: > But this is not really a powerpc patch, and I'm not an ELF expert. So > I'm not comfortable merging it via the powerpc tree. It doesn't look > like we really have a maintainer for binfmt_elf.c, so I'm not sure who > should be acking that part. Thanks a bunch for looking at this Michael. > I've added Al Viro to Cc, he maintains fs/ and might be interested. > I've also added Andrew Morton who might be happy to put this in his > tree, and see if anyone complains? For those added to the CC, I would re-state my original commit message more clearly. My research showed that the ELF loader bug fixed in this patch is the root cause bug fix required to implement this hunk: > > -#define VM_DATA_DEFAULT_FLAGS32(VM_READ | VM_WRITE | VM_EXEC | \ > > +#define VM_DATA_DEFAULT_FLAGS32 \ > > + (((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0) | \ > > +VM_READ | VM_WRITE | \ > > VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) Eg that 32 bit powerpc currently unconditionally injects writable, executable pages into a user space process. This critically undermines all the W^X security work that has been done in the tool chain and user space by the PPC community. I would encourage people to view this as an important security patch for 32 bit powerpc environments. Regards, Jason
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote: > > Can you check if the problem occurs with this patch? In light of the fact that padlock-sha is the correct example to follow, you only need to add one line to the init_tfm fucntion to update the descsize based on that of the fallback. Thanks, -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote: > > Can you check if the problem occurs with this patch? In light of the fact that padlock-sha is the correct example to follow, you only need to add one line to the init_tfm fucntion to update the descsize based on that of the fallback. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
On Tue, Sep 27, 2016 at 05:01:03AM -0400, Jan Stancek wrote: > > Also, does that mean that padlock_sha has similar problem? > It does not seem to reserve any space for fallback __ctx and it calls > init()/update()/export() with padlock_sha_desc's fallback: > > struct padlock_sha_desc { > struct shash_desc fallback; > }; > > static struct shash_alg sha1_alg = { > .descsize = sizeof(struct padlock_sha_desc), Actually I was wrong when I said that the API couldn't handle a dynamic fallback. It can and padlock-sha does the right thing by updating descsize in the cra_init function. So this is what vmx should do too. Thanks, -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
On Tue, Sep 27, 2016 at 05:01:03AM -0400, Jan Stancek wrote: > > Also, does that mean that padlock_sha has similar problem? > It does not seem to reserve any space for fallback __ctx and it calls > init()/update()/export() with padlock_sha_desc's fallback: > > struct padlock_sha_desc { > struct shash_desc fallback; > }; > > static struct shash_alg sha1_alg = { > .descsize = sizeof(struct padlock_sha_desc), Actually I was wrong when I said that the API couldn't handle a dynamic fallback. It can and padlock-sha does the right thing by updating descsize in the cra_init function. So this is what vmx should do too. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 00/17] clean up readlinks
On Tue, Sep 27, 2016 at 11:38:33AM +0200, Miklos Szeredi wrote: > > I have no problem with "let's get rid of generic_readlink" - not > > that > > it bought us much, but sure, if you want to have decision made based upon > > the combination of flags, let's do it. Just make NULL ->readlink + non-NULL > > ->get_link() mean generic_readlink(), and we are done. > > Indeed. Except it really should be the other way round: > > - .get_link always returning the symlink body > - only proc setting .jump_link to do its thing > - RIP .readlink > But that's an extra branch in the symlink following. I was worried > about that and hence gone for the unification of the two. Symlink traversal is a much hotter path than readlink() would ever be. What's more, we do have jumps on normal symlink traversal - after all, absolute symlinks are exactly that; it's "jump to root, then traverse the following sequence of components". So having ->get_link() that includes jumps is not that much of a stretch (note that it could both jump and return a relative pathname to traverse after that; none of the procfs-style ones do that, but there's no reason to prohibit that). What I'd prefer is * it's a symlink iff it has ->get_link() * readlink(2) on a symlink is normally just using generic_readlink() * that can be overridden by supplying a ->readlink() method. * the first time readlink() hits a symlink it will check both ->get_link() and ->readlink() presence. Then, if it's a normal symlink, the inode will get marked as such and all subsequent calls will just call generic_readlink(). IOW, I would go for if (unlikely(!marked)) { if ->readlink is present call ->readlink and return if ->get_link is absent fail mark } call generic_readlink > Yeah. We can do your above suggestion, it's certainly less brittle. > But I think it's rather confusing, having ->get_link normally do > readlink, except for proc, where readlink is done by ->readlink. ->readlink() is just an override for the cases when readlink(2) wants to fake something (or, as in case of AFS ugliness, is used on non-symlinks). The primary function of symlinks is traversal, not readlink...
Re: [PATCH 00/17] clean up readlinks
On Tue, Sep 27, 2016 at 11:38:33AM +0200, Miklos Szeredi wrote: > > I have no problem with "let's get rid of generic_readlink" - not > > that > > it bought us much, but sure, if you want to have decision made based upon > > the combination of flags, let's do it. Just make NULL ->readlink + non-NULL > > ->get_link() mean generic_readlink(), and we are done. > > Indeed. Except it really should be the other way round: > > - .get_link always returning the symlink body > - only proc setting .jump_link to do its thing > - RIP .readlink > But that's an extra branch in the symlink following. I was worried > about that and hence gone for the unification of the two. Symlink traversal is a much hotter path than readlink() would ever be. What's more, we do have jumps on normal symlink traversal - after all, absolute symlinks are exactly that; it's "jump to root, then traverse the following sequence of components". So having ->get_link() that includes jumps is not that much of a stretch (note that it could both jump and return a relative pathname to traverse after that; none of the procfs-style ones do that, but there's no reason to prohibit that). What I'd prefer is * it's a symlink iff it has ->get_link() * readlink(2) on a symlink is normally just using generic_readlink() * that can be overridden by supplying a ->readlink() method. * the first time readlink() hits a symlink it will check both ->get_link() and ->readlink() presence. Then, if it's a normal symlink, the inode will get marked as such and all subsequent calls will just call generic_readlink(). IOW, I would go for if (unlikely(!marked)) { if ->readlink is present call ->readlink and return if ->get_link is absent fail mark } call generic_readlink > Yeah. We can do your above suggestion, it's certainly less brittle. > But I think it's rather confusing, having ->get_link normally do > readlink, except for proc, where readlink is done by ->readlink. ->readlink() is just an override for the cases when readlink(2) wants to fake something (or, as in case of AFS ugliness, is used on non-symlinks). The primary function of symlinks is traversal, not readlink...
Re: [PATCH v3] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.
From:Date: Tue, 27 Sep 2016 09:57:50 -0600 > From: Chris Roth > > From Allan Chou > From: Chris Roth Three From lines, it's actually quite amazing how you were able to achieve this. Please take some time, and carefully craft your patch emails but don't send them to the list. Instead, email yourself, and look at what you receive. Do not post this patch to the list until the test emails you send to yourself look correct. Thank you.
Re: [PATCH v3] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.
From: Date: Tue, 27 Sep 2016 09:57:50 -0600 > From: Chris Roth > > From Allan Chou > From: Chris Roth Three From lines, it's actually quite amazing how you were able to achieve this. Please take some time, and carefully craft your patch emails but don't send them to the list. Instead, email yourself, and look at what you receive. Do not post this patch to the list until the test emails you send to yourself look correct. Thank you.
linux-next: manual merge of the drm-misc tree with the drm tree
Hi all, Today's linux-next merge of the drm-misc tree got conflicts in: drivers/gpu/drm/sti/sti_dvo.c drivers/gpu/drm/sti/sti_hqvdp.c drivers/gpu/drm/sti/sti_mixer.c between commits: bdfd36ef8e64 ("drm/sti: Fix sparse warnings") b4bba92dfbe2 ("drm/sti: remove stih415-416 platform support") from the drm tree and commit: bd233af436ba ("drm/sti: mark symbols static where possible") from the drm-misc tree. I fixed it up (I just used the drm-misc tree versions and removed the comflicting function in the sti_mixer.c case) 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
linux-next: manual merge of the drm-misc tree with the drm tree
Hi all, Today's linux-next merge of the drm-misc tree got conflicts in: drivers/gpu/drm/sti/sti_dvo.c drivers/gpu/drm/sti/sti_hqvdp.c drivers/gpu/drm/sti/sti_mixer.c between commits: bdfd36ef8e64 ("drm/sti: Fix sparse warnings") b4bba92dfbe2 ("drm/sti: remove stih415-416 platform support") from the drm tree and commit: bd233af436ba ("drm/sti: mark symbols static where possible") from the drm-misc tree. I fixed it up (I just used the drm-misc tree versions and removed the comflicting function in the sti_mixer.c case) 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
Re: [PATCH trival -resend 1/2] bpf: clean up put_cpu_var usage
From: Shaohua LiDate: Tue, 27 Sep 2016 08:42:41 -0700 > put_cpu_var takes the percpu data, not the data returned from > get_cpu_var. > > This doesn't change the behavior. > > Cc: Tejun Heo > Cc: Alexei Starovoitov > Signed-off-by: Shaohua Li Applied.
Re: [PATCH trival -resend 1/2] bpf: clean up put_cpu_var usage
From: Shaohua Li Date: Tue, 27 Sep 2016 08:42:41 -0700 > put_cpu_var takes the percpu data, not the data returned from > get_cpu_var. > > This doesn't change the behavior. > > Cc: Tejun Heo > Cc: Alexei Starovoitov > Signed-off-by: Shaohua Li Applied.
Re: [PATCH trival -resend 2/2] lib: clean up put_cpu_var usage
From: Shaohua LiDate: Tue, 27 Sep 2016 08:42:42 -0700 > put_cpu_var takes the percpu data, not the data returned from > get_cpu_var. > > This doesn't change the behavior. > > Cc: Tejun Heo > Signed-off-by: Shaohua Li Applied.
Re: [PATCH trival -resend 2/2] lib: clean up put_cpu_var usage
From: Shaohua Li Date: Tue, 27 Sep 2016 08:42:42 -0700 > put_cpu_var takes the percpu data, not the data returned from > get_cpu_var. > > This doesn't change the behavior. > > Cc: Tejun Heo > Signed-off-by: Shaohua Li Applied.
Re: [PATCH v5 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD
On September 27, 2016 11:50:00 AM PDT, Lee Joneswrote: >On Sat, 17 Sep 2016, Ksenija Stanojević wrote: >> On Wed, Aug 31, 2016 at 2:05 PM, Lee Jones >wrote: >> > On Thu, 18 Aug 2016, Ksenija Stanojevic wrote: >> > >> > > Add core files for mxs-lradc MFD driver. >> > > >> > > Note: this patch won't compile in iio/testing without this >patch: >> > > a8f447be8056 ("mfd: Add resource managed APIs for >mfd_add_devices") >> > > >> > > Signed-off-by: Ksenija Stanojevic >> > > --- >> > > Changes in v5: >> > > - use DEFINE_RES_MEM >> > > - don't pass ioreammaped adress to platform cells >> > > - move comment outside of struct mxs_lradc >> > > - change type of argument in mxs_lradc_reg_set, >mxs_lradc_reg_clear, >> > >mxs_lradc_reg_wrt (struct mxs_lradc * -> void __iomem *) >> > > >> > > Changes in v4: >> > > - update copyright >> > > - use DEFINE_RES_IRQ_NAMED >> > > - remove mxs_lradc_add_device function >> > > - use struct mfd_cell in static form >> > > - improve spacing >> > > - remove unnecessary comment >> > > - remove platform_get_irq >> > > - remove touch_ret and use ret instead >> > > - rename use_touchscreen to touchscreen_wire >> > > - use goto statements >> > > - remove irq[13], irq_count and irq_name from struct mxs_lradc >> > > - remove all defines from inside the struct definition >> > > >> > > Changes in v3: >> > > - add note to commit message >> > > - move switch statement into if(touch_ret == 0) branch >> > > - add MODULE_AUTHOR >> > > >> > > Changes in v2: >> > > - do not change spacing in Kconfig >> > > - make struct mfd_cell part of struct mxs_lradc >> > > - use switch instead of if in mxs_lradc_irq_mask >> > > - use only necessary header files in mxs_lradc.h >> > > - use devm_mfd_add_device >> > > - use separate function to register mfd device >> > > - change licence to GPL >> > > - add copyright >> > > >> > > drivers/mfd/Kconfig | 17 +++ >> > > drivers/mfd/Makefile | 1 + >> > > drivers/mfd/mxs-lradc.c | 255 >++ >> > > include/linux/mfd/mxs-lradc.h | 194 > >> > > 4 files changed, 467 insertions(+) >> > > create mode 100644 drivers/mfd/mxs-lradc.c >> > > create mode 100644 include/linux/mfd/mxs-lradc.h > >[...] > >> > > +static int mxs_lradc_probe(struct platform_device *pdev) >> > > +{ >> > > + const struct of_device_id *of_id; >> > > + struct device *dev = >dev; >> > > + struct device_node *node = dev->of_node; >> > > + struct mxs_lradc *lradc; >> > > + struct mfd_cell *cells = NULL; >> > > + int ret = 0; >> > > + u32 ts_wires = 0; >> > > + >> > > + lradc = devm_kzalloc(>dev, sizeof(*lradc), >GFP_KERNEL); >> > > + if (!lradc) >> > > + return -ENOMEM; >> > > + >> > > + of_id = of_match_device(mxs_lradc_dt_ids, >dev); >> > > + lradc->soc = (enum mxs_lradc_id)of_id->data; >> > >> > Unnecessary cast. >> >> If I remove the cast I get this error: >> drivers/mfd/mxs-lradc.c:148:13: error: incompatible types when >> assigning to type ‘enum mxs_lradc_id’ from type ‘const void * const’ > >Ah, because it's a const. Fair enough. No, it's because void * has to be cast to a non-pointer data type explicitly. Thanks. -- Dmitry
Re: kernel BUG at net/unix/garbage.c:149!"
From: Nikolay BorisovDate: Tue, 27 Sep 2016 17:16:27 +0300 > What's the status of https://patchwork.ozlabs.org/patch/664062/ , is > this going to be picked up ? Why would I apply a patch that's an RFC, doesn't have a proper commit message, lacks a proper signoff, and also lacks ACK's and feedback from other knowledgable developers?
Re: [PATCH v5 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD
On September 27, 2016 11:50:00 AM PDT, Lee Jones wrote: >On Sat, 17 Sep 2016, Ksenija Stanojević wrote: >> On Wed, Aug 31, 2016 at 2:05 PM, Lee Jones >wrote: >> > On Thu, 18 Aug 2016, Ksenija Stanojevic wrote: >> > >> > > Add core files for mxs-lradc MFD driver. >> > > >> > > Note: this patch won't compile in iio/testing without this >patch: >> > > a8f447be8056 ("mfd: Add resource managed APIs for >mfd_add_devices") >> > > >> > > Signed-off-by: Ksenija Stanojevic >> > > --- >> > > Changes in v5: >> > > - use DEFINE_RES_MEM >> > > - don't pass ioreammaped adress to platform cells >> > > - move comment outside of struct mxs_lradc >> > > - change type of argument in mxs_lradc_reg_set, >mxs_lradc_reg_clear, >> > >mxs_lradc_reg_wrt (struct mxs_lradc * -> void __iomem *) >> > > >> > > Changes in v4: >> > > - update copyright >> > > - use DEFINE_RES_IRQ_NAMED >> > > - remove mxs_lradc_add_device function >> > > - use struct mfd_cell in static form >> > > - improve spacing >> > > - remove unnecessary comment >> > > - remove platform_get_irq >> > > - remove touch_ret and use ret instead >> > > - rename use_touchscreen to touchscreen_wire >> > > - use goto statements >> > > - remove irq[13], irq_count and irq_name from struct mxs_lradc >> > > - remove all defines from inside the struct definition >> > > >> > > Changes in v3: >> > > - add note to commit message >> > > - move switch statement into if(touch_ret == 0) branch >> > > - add MODULE_AUTHOR >> > > >> > > Changes in v2: >> > > - do not change spacing in Kconfig >> > > - make struct mfd_cell part of struct mxs_lradc >> > > - use switch instead of if in mxs_lradc_irq_mask >> > > - use only necessary header files in mxs_lradc.h >> > > - use devm_mfd_add_device >> > > - use separate function to register mfd device >> > > - change licence to GPL >> > > - add copyright >> > > >> > > drivers/mfd/Kconfig | 17 +++ >> > > drivers/mfd/Makefile | 1 + >> > > drivers/mfd/mxs-lradc.c | 255 >++ >> > > include/linux/mfd/mxs-lradc.h | 194 > >> > > 4 files changed, 467 insertions(+) >> > > create mode 100644 drivers/mfd/mxs-lradc.c >> > > create mode 100644 include/linux/mfd/mxs-lradc.h > >[...] > >> > > +static int mxs_lradc_probe(struct platform_device *pdev) >> > > +{ >> > > + const struct of_device_id *of_id; >> > > + struct device *dev = >dev; >> > > + struct device_node *node = dev->of_node; >> > > + struct mxs_lradc *lradc; >> > > + struct mfd_cell *cells = NULL; >> > > + int ret = 0; >> > > + u32 ts_wires = 0; >> > > + >> > > + lradc = devm_kzalloc(>dev, sizeof(*lradc), >GFP_KERNEL); >> > > + if (!lradc) >> > > + return -ENOMEM; >> > > + >> > > + of_id = of_match_device(mxs_lradc_dt_ids, >dev); >> > > + lradc->soc = (enum mxs_lradc_id)of_id->data; >> > >> > Unnecessary cast. >> >> If I remove the cast I get this error: >> drivers/mfd/mxs-lradc.c:148:13: error: incompatible types when >> assigning to type ‘enum mxs_lradc_id’ from type ‘const void * const’ > >Ah, because it's a const. Fair enough. No, it's because void * has to be cast to a non-pointer data type explicitly. Thanks. -- Dmitry
Re: kernel BUG at net/unix/garbage.c:149!"
From: Nikolay Borisov Date: Tue, 27 Sep 2016 17:16:27 +0300 > What's the status of https://patchwork.ozlabs.org/patch/664062/ , is > this going to be picked up ? Why would I apply a patch that's an RFC, doesn't have a proper commit message, lacks a proper signoff, and also lacks ACK's and feedback from other knowledgable developers?
Re: [PATCH v3 00/11] re-enable DAX PMD support
On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote: > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > locking. This series allows DAX PMDs to participate in the DAX radix tree > based locking scheme so that they can be re-enabled. > > Jan and Christoph, can you please help review these changes? About to get on a plane, so it might take a bit to do a real review. In general this looks fine, but I guess the first two ext4 patches should just go straight to Ted independent of the rest? Also Jan just posted a giant DAX patchbomb, we'll need to find a way to integrate all that work, and maybe prioritize things if we want to get bits into 4.9 still.
Re: [PATCH v3 00/11] re-enable DAX PMD support
On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote: > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > locking. This series allows DAX PMDs to participate in the DAX radix tree > based locking scheme so that they can be re-enabled. > > Jan and Christoph, can you please help review these changes? About to get on a plane, so it might take a bit to do a real review. In general this looks fine, but I guess the first two ext4 patches should just go straight to Ted independent of the rest? Also Jan just posted a giant DAX patchbomb, we'll need to find a way to integrate all that work, and maybe prioritize things if we want to get bits into 4.9 still.
Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO
On 27-09-16, 12:34, Stefan Agner wrote: > Added Viresh Kumar to the discussion, he implemented the I2C recovery > functions. > > Yes, reordering the pinctrl/gpio_free calls would fix the problem too. > > However, I guess there is no explicit rule to that ("request/free GPIOs > only when they are muxed as GPIO"), so I think of it that the issue is > actually in the pinctrl driver. > > On top of that it is not entirely trivial to reorder the calls the way > i2c_generic_gpio_recovery and i2c_generic_recovery are set up right now. AFAICT, these routines don't touch the muxing part at all. Perhaps it is done internally by the GPIO calls. Can you please elaborate the exact change you are hinting towards here ? -- viresh
Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO
On 27-09-16, 12:34, Stefan Agner wrote: > Added Viresh Kumar to the discussion, he implemented the I2C recovery > functions. > > Yes, reordering the pinctrl/gpio_free calls would fix the problem too. > > However, I guess there is no explicit rule to that ("request/free GPIOs > only when they are muxed as GPIO"), so I think of it that the issue is > actually in the pinctrl driver. > > On top of that it is not entirely trivial to reorder the calls the way > i2c_generic_gpio_recovery and i2c_generic_recovery are set up right now. AFAICT, these routines don't touch the muxing part at all. Perhaps it is done internally by the GPIO calls. Can you please elaborate the exact change you are hinting towards here ? -- viresh
linux-next: manual merge of the drm tree with Linus' tree
Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/drm_crtc.c between commit: 6f00975c6190 ("drm: Reject page_flip for !DRIVER_MODESET") from Linus' tree and commit: 43968d7b806d ("drm: Extract drm_plane.[hc]") from the drm tree. I fixed it up (the latter takes the former into account, so I just used the drm tree version) 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
linux-next: manual merge of the drm tree with Linus' tree
Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/drm_crtc.c between commit: 6f00975c6190 ("drm: Reject page_flip for !DRIVER_MODESET") from Linus' tree and commit: 43968d7b806d ("drm: Extract drm_plane.[hc]") from the drm tree. I fixed it up (the latter takes the former into account, so I just used the drm tree version) 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