Re: [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing

2016-09-27 Thread Peter Ujfalusi
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

2016-09-27 Thread Peter Ujfalusi
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

2016-09-27 Thread Shah, Nehal-bakulchandra
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

2016-09-27 Thread Shah, Nehal-bakulchandra
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()

2016-09-27 Thread Joonsoo Kim
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()

2016-09-27 Thread Joonsoo Kim
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

2016-09-27 Thread Kiwoong Kim
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




RE: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

2016-09-27 Thread Kiwoong Kim
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

2016-09-27 Thread Songjun Wu
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

2016-09-27 Thread Songjun Wu
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

2016-09-27 Thread Joonsoo Kim
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

2016-09-27 Thread Joonsoo Kim
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)

2016-09-27 Thread Krzysztof Hałasa
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: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

2016-09-27 Thread Krzysztof Hałasa
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

2016-09-27 Thread Martin K. Petersen
> "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: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

2016-09-27 Thread Martin K. Petersen
> "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

2016-09-27 Thread Martin K. Petersen
> "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: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

2016-09-27 Thread Martin K. Petersen
> "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

2016-09-27 Thread Borislav Petkov
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

2016-09-27 Thread Borislav Petkov
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

2016-09-27 Thread Martin K. Petersen
> "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] scsi: be2iscsi: mark symbols static where possible

2016-09-27 Thread Martin K. Petersen
> "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

2016-09-27 Thread Borislav Petkov
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

2016-09-27 Thread Borislav Petkov
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

2016-09-27 Thread Leo Li


> -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

2016-09-27 Thread Leo Li


> -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

2016-09-27 Thread Peter Rosin
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



Re: [PATCH v2] pinctrl: Add SX150X GPIO Extender Pinctrl Driver

2016-09-27 Thread Peter Rosin
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

2016-09-27 Thread Stephen Rothwell
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

2016-09-27 Thread Stephen Rothwell
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

2016-09-27 Thread Vladislav Naumov
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 2/2] hid: input: add HID_QUIRK_REUSE_AXES and fix dragonrise

2016-09-27 Thread Vladislav Naumov
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

2016-09-27 Thread Dave Chinner
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

2016-09-27 Thread Dave Chinner
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

2016-09-27 Thread Viresh Kumar
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

2016-09-27 Thread Viresh Kumar
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

2016-09-27 Thread Wang Nan
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] perf tools: Fix building in 32 bit platform

2016-09-27 Thread Wang Nan
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Stefan Agner
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

2016-09-27 Thread Stefan Agner
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Zhao Qiang
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

2016-09-27 Thread Tony Lindgren
* 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

2016-09-27 Thread Tony Lindgren
* 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

2016-09-27 Thread Chen Yu
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 2/2] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily

2016-09-27 Thread Chen Yu
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

2016-09-27 Thread Chen Yu
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

2016-09-27 Thread Chen Yu
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

2016-09-27 Thread Chen Yu
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");
+   }

[PATCH 1/2] PM / sleep: Return RPM_SUSPENDED to keep devices in runtime-suspended

2016-09-27 Thread Chen Yu
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

2016-09-27 Thread Vinod Koul
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

2016-09-27 Thread Vinod Koul
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'")

2016-09-27 Thread Matthew Kilgore

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'")

2016-09-27 Thread Matthew Kilgore

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

2016-09-27 Thread Vinod Koul
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

2016-09-27 Thread Vinod Koul
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

2016-09-27 Thread Mike Christie
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

2016-09-27 Thread Joe Perches
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

2016-09-27 Thread Mike Christie
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

2016-09-27 Thread Joe Perches
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

2016-09-27 Thread Jason Gunthorpe
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

2016-09-27 Thread Jason Gunthorpe
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

2016-09-27 Thread Herbert Xu
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

2016-09-27 Thread Herbert Xu
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

2016-09-27 Thread Herbert Xu
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: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-27 Thread Herbert Xu
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

2016-09-27 Thread Al Viro
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

2016-09-27 Thread Al Viro
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.

2016-09-27 Thread David Miller
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.

2016-09-27 Thread David Miller
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

2016-09-27 Thread Stephen Rothwell
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

2016-09-27 Thread Stephen Rothwell
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

2016-09-27 Thread David Miller
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 1/2] bpf: clean up put_cpu_var usage

2016-09-27 Thread David Miller
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

2016-09-27 Thread David Miller
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 trival -resend 2/2] lib: clean up put_cpu_var usage

2016-09-27 Thread David Miller
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

2016-09-27 Thread Dmitry Torokhov
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!"

2016-09-27 Thread David Miller
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 v5 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

2016-09-27 Thread Dmitry Torokhov
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!"

2016-09-27 Thread David Miller
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

2016-09-27 Thread Christoph Hellwig
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

2016-09-27 Thread Christoph Hellwig
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

2016-09-27 Thread Viresh Kumar
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

2016-09-27 Thread Viresh Kumar
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

2016-09-27 Thread Stephen Rothwell
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

2016-09-27 Thread Stephen Rothwell
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


  1   2   3   4   5   6   7   8   9   10   >