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




[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: 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: [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] 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] 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



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


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

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

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 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");
+   }

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



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


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


Re: linux-next: build failure after merge of the rdma tree

2016-09-27 Thread Stephen Rothwell
Hi Stephen,

On Tue, 27 Sep 2016 11:23:34 +1000 Stephen Rothwell  
wrote:
>
> Hi Doug,
> 
> After merging the rdma tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function 
> 'kiblnd_hdev_setup_mrs':
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:7: error: implicit 
> declaration of function 'ib_get_dma_mr' 
> [-Werror=implicit-function-declaration]
>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
>^
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:5: warning: 
> assignment makes pointer from integer without a cast [-Wint-conversion]
>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
>  ^
> 
> Caused by commit
> 
>   5ef990f06bd7 ("IB/core: remove ib_get_dma_mr")
> 
> I have used the rdma tree from next-20160923 for today.

As pointed out by Christoph, I should have just disabled the driver in
staging, so today I just applied the patch below.  Doug, that should
probably be applied to the rdma tree so that you don't break Linus'
tree when it gets merged.

From: Stephen Rothwell 
Date: Wed, 28 Sep 2016 11:35:28 +1000
Subject: [PATCH] starging/lustre: disable LNET infiniband support

Commit 5ef990f06bd7 ("IB/core: remove ib_get_dma_mr") broke the
lustre LNET infiniband support.  Since this is in drivers/staging,
lets just disable it for now until ti can be fixed properly.

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/lustre/lnet/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/lustre/lnet/Kconfig 
b/drivers/staging/lustre/lnet/Kconfig
index 2b5930150cda..13b43278a38d 100644
--- a/drivers/staging/lustre/lnet/Kconfig
+++ b/drivers/staging/lustre/lnet/Kconfig
@@ -35,6 +35,7 @@ config LNET_SELFTEST
 config LNET_XPRT_IB
tristate "LNET infiniband support"
depends on LNET && INFINIBAND && INFINIBAND_ADDR_TRANS
+   depends on BROKEN
default LNET && INFINIBAND
help
  This option allows the LNET users to use infiniband as an
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell


Re: [PATCH v5] powerpc: Do not make the entire heap executable

2016-09-27 Thread Michael Ellerman
Denys Vlasenko  writes:

> On 32-bit powerpc the ELF PLT sections of binaries (built with --bss-plt,
> or with a toolchain which defaults to it) look like this:

Or (it seems), for all programs built with -pg (profiling).

>   [17] .sbss NOBITS  0002aff8 01aff8 14 00  WA  0   0 
>  4
>   [18] .plt  NOBITS  0002b00c 01aff8 84 00 WAX  0   0 
>  4
>   [19] .bss  NOBITS  0002b090 01aff8 a4 00  WA  0   0 
>  4
>
> Which results in an ELF load header:
>
>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD   0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x1
>
> This is all correct, the load region containing the PLT is marked as
> executable. Note that the PLT starts at 0002b00c but the file mapping ends at
> 0002aff8, so the PLT falls in the 0 fill section described by the load header,
> and after a page boundary.
>
> Unfortunately the generic ELF loader ignores the X bit in the load headers
> when it creates the 0 filled non-file backed mappings. It assumes all of these
> mappings are RW BSS sections, which is not the case for PPC.
>
> gcc/ld has an option (--secure-plt) to not do this, this is said to incur
> a small performance penalty.
>
> Currently, to support 32-bit binaries with PLT in BSS kernel maps *entire
> brk area* with executable rights for all binaries, even --secure-plt ones.
>
> Stop doing that.
>
> Teach the ELF loader to check the X bit in the relevant load header
> and create 0 filled anonymous mappings that are executable
> if the load header requests that.
...
>
> Signed-off-by: Jason Gunthorpe 
> Signed-off-by: Denys Vlasenko 
> Reviewed-by: Kees Cook 
> CC: Michael Ellerman 

This looks OK to me, I've tested it with --bss-plt and --secure-plt and
also -pg.

So for the powerpc part I'll give you an:

Acked-by: Michael Ellerman 

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.

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?

Also here: https://patchwork.ozlabs.org/patch/661595/

cheers

> ---
> Changes since v4:
> * if (current->personality & READ_IMPLIES_EXEC), still use VM_EXEC
>   for 32-bit executables.
>
> Changes since v3:
> * typo fix in commit message
> * rebased to current Linus tree
>
> Changes since v2:
> * moved capability to map with VM_EXEC into vm_brk_flags()
>
> Changes since v1:
> * wrapped lines to not exceed 79 chars
> * improved comment
> * expanded CC list
>
>  arch/powerpc/include/asm/page.h |  3 ++-
>  fs/binfmt_elf.c | 30 ++
>  include/linux/mm.h  |  1 +
>  mm/mmap.c   | 21 -
>  4 files changed, 41 insertions(+), 14 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 56398e7..d188f51 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -230,7 +230,9 @@ extern long long virt_phys_offset;
>   * and needs to be executable.  This means the whole heap ends
>   * up being executable.
>   */
> -#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)
>  
>  #define VM_DATA_DEFAULT_FLAGS64  (VM_READ | VM_WRITE | \
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 7f6aff3f..2b57b5a 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -91,12 +91,18 @@ static struct linux_binfmt elf_format = {
>  
>  #define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE)
>  
> -static int set_brk(unsigned long start, unsigned long end)
> +static int set_brk(unsigned long start, unsigned long end, int prot)
>  {
>   start = ELF_PAGEALIGN(start);
>   end = ELF_PAGEALIGN(end);
>   if (end > start) {
> - int error = vm_brk(start, end - start);
> + /*
> +  * Map the last of the bss segment.
> +  * If the header is requesting these pages to be
> +  * executable, honour that (ppc32 needs this).
> +  */
> + int error = vm_brk_flags(start, end - start,
> + prot & PROT_EXEC ? VM_EXEC : 0);
>   if (error)
>   return error;
>   }
> @@ -524,6 +530,7 @@ static unsigned long load_elf_interp(struct elfhdr 
> *interp_elf_ex,
>   unsigned 

Regression in mobility grouping?

2016-09-27 Thread Johannes Weiner
Hi guys,

we noticed what looks like a regression in page mobility grouping
during an upgrade from 3.10 to 4.0. Identical machines, workloads, and
uptime, but /proc/pagetypeinfo on 3.10 looks like this:

Number of blocks type Unmovable  Reclaimable  Movable  Reserve  
Isolate 
Node 1, zone   Normal  815  433315182   
 0 

and on 4.0 like this:

Number of blocks type Unmovable  Reclaimable  Movable  Reserve  
CMA  Isolate 
Node 1, zone   Normal 3880 3530253562   
 00 

4.0 is either polluting pageblocks more aggressively at allocation, or
is not able to make pageblocks movable again when the reclaimable and
unmovable allocations are released. Invoking compaction manually
(/proc/sys/vm/compact_memory) is not bringing them back, either.

The problem we are debugging is that these machines have a very high
rate of order-3 allocations (fdtable during fork, network rx), and
after the upgrade allocstalls have increased dramatically. I'm not
entirely sure this is the same issue, since even order-0 allocations
are struggling, but the mobility grouping in itself looks problematic.

I'm still going through the changes relevant to mobility grouping in
that timeframe, but if this rings a bell for anyone, it would help. I
hate blaming random patches, but these caught my eye:

9c0415e mm: more aggressive page stealing for UNMOVABLE allocations
3a1086f mm: always steal split buddies in fallback allocations
99592d5 mm: when stealing freepages, also take pages created by splitting buddy 
page

The changelog states that by aggressively stealing split buddy pages
during a fallback allocation we avoid subsequent stealing. But since
there are generally more movable/reclaimable pages available, and so
less falling back and stealing freepages on behalf of movable, won't
this mean that we could expect exactly that result - growing numbers
of unmovable blocks, while rarely stealing them back in movable alloc
fallbacks? And the expansion of !MOVABLE blocks would over time make
compaction less and less effective too, seeing as it doesn't consider
anything !MOVABLE suitable migration targets?

Attached are the full /proc/pagetypeinfo and /proc/buddyinfo from both
kernels on machines with similar uptimes and directly after invoking
compaction. As you can see, the buddy lists are much more fragmented
on 4.0, with unmovable/reclaimable allocations polluting more blocks.

Any thoughts on this would be greatly appreciated. I can test patches.

Thanks!
Node 0, zone  DMA  0  0  0  1  2  1  1  0   
   1  1  3 
Node 0, zoneDMA32   1062   1491   1641   1725478 77  5  1   
   0  0  0 
Node 0, zone   Normal  10436  16239   5903696130729   1298550   
 109  0  0 
Node 1, zone   Normal   5956 15  5 28 11  8  2  0   
   0  0  0 
Node 0, zone  DMA  1  1  0  1  1  1  1  0   
   0  1  3 
Node 0, zoneDMA32   9462   6148   2297 27  0  0  0  0   
   0  0  0 
Node 0, zone   Normal 130376  36589   3777 94  1  0  0  0   
   0  0  0 
Node 1, zone   Normal 190988  77269   3896332  6  0  0  0   
   0  0  0 
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order   0  1  2  3  4  
5  6  7  8  9 10 
Node0, zone  DMA, typeUnmovable  0  0  0  1  2  
1  1  0  1  0  0 
Node0, zone  DMA, type  Reclaimable  0  0  0  0  0  
0  0  0  0  0  0 
Node0, zone  DMA, type  Movable  0  0  0  0  0  
0  0  0  0  0  3 
Node0, zone  DMA, type  Reserve  0  0  0  0  0  
0  0  0  0  1  0 
Node0, zone  DMA, type  Isolate  0  0  0  0  0  
0  0  0  0  0  0 
Node0, zoneDMA32, typeUnmovable488221286  0  0  
0  0  0  0  0  0 
Node0, zoneDMA32, type  Reclaimable  1725741  0  0  
0  0  0  0  0  0 
Node0, zoneDMA32, type  Movable431   1735   1073105  0  
0  0  0  0  0  0 
Node0, zoneDMA32, type  Reserve  0  0  0 17  1  
0  0  0  0  0  0 
Node0, zoneDMA32, type  Isolate  0  0  0  0  0  
0  0  0  0  0  0 
Node0, zone   Normal, typeUnmovable   1922 16  1 19  0  
0  0  0  0  0  0 
Node0, zone   Normal, type  Reclaimable   4549  0  0  

Re: [PATCH v5 5/8] iommu/amd: copy old trans table from old kernel

2016-09-27 Thread Baoquan He
Hi Joerg,

On 09/20/16 at 02:40pm, Joerg Roedel wrote:
> > +   if ( !is_pre_enabled) {
> > +   for_each_iommu(iommu)
> > +   early_enable_iommu(iommu);
> > +   } else {
> > +   if (copy_dev_tables()) {
> > +   pr_err("Failed to copy DEV table from previous 
> > kernel.\n");
> > +   /*
> > +* If failed to copy dev tables from old kernel, 
> > continue to proceed
> > +* as it does in normal kernel.
> > +*/
> > +   for_each_iommu(iommu) {
> > +   clear_translation_pre_enabled(iommu);
> > +   early_enable_iommu(iommu);
> > +   }
> > +   } else {
> > +   pr_info("Copied DEV table from previous kernel.\n");
> > +   for_each_iommu(iommu) {
> > +   iommu_feature_disable(iommu, CONTROL_CMDBUF_EN);
> > +   iommu_feature_disable(iommu, 
> > CONTROL_EVT_LOG_EN);
> 
> Could you move that into new helpers (iommu_disable_command_buffer...)?

Did you mean wraping iommu_feature_disable(iommu, CONTROL_CMDBUF_EN) into a
helper function like iommu_disable_command_buffer(), and wraping
iommu_feature_disable(iommu, CONTROL_EVT_LOG_EN) into
iommu_disable_event_buffer()?

I retest with not disabling command buffer and event log here, it works
on amd iommu v1 and v2 systems. So if I understand your comment
correctly, there's no need to add "iommu_feature_disable(iommu,
CONTROL_CMDBUF_EN)"  and "iommu_feature_disable(iommu,
CONTROL_EVT_LOG_EN)" here. I remember I added them here because more
IO_PAGE_FAULT messages are printed without them. But now it seems not to
related to them. So I will remove above two lines of code.

> 
> > +   iommu_enable_command_buffer(iommu);
> > +   iommu_enable_event_buffer(iommu);
> > +   iommu_set_device_table(iommu);
> > +   iommu_flush_all_caches(iommu);
> > +   }
> > +   }
> > +   }
> >  }
> >  
> >  static void enable_iommus_v2(void)
> > -- 
> > 2.5.5
> > 


Re: [PATCH] of: thermal: Fixed governor at each thermal zone

2016-09-27 Thread Zhang Rui
Hi, Javi, Lukasz and Eduardo,

thanks for your input.

thanks,
rui

On 二, 2016-09-27 at 06:22 -0700, Eduardo Valentin wrote:
> Hello, Lukasz, Inhyuk, Javi,
> 
> On Tue, Sep 27, 2016 at 12:52:04PM +0100, Lukasz Luba wrote:
> > 
> > 
> > On 27/09/16 02:46, Zhang Rui wrote:
> > > 
> > > On 一, 2016-09-19 at 10:18 +0900, Inhyuk Kang wrote:
> > > > 
> > > > It is necessary to be added governor at each thermal_zone.
> > > > Because some governors should be operated in the during the
> > > > kernel
> > > > booting
> > > > in order to avoid heating problem.
> > > > 
> > > > Default governor cannot be covered all thermal zones policy
> > > > because
> > > > some thermal zones want to apply different one.
> > > > For example, the power allocator governor operates differently
> > > > with
> > > > step wise governor.
> > > > Hence, it is better to parse governor parameter from the device
> > > > tree.
> > > > 
> > > > Signed-off-by: Inhyuk Kang 
> > > > 
> > > The patch looks okay to me.
> > > Eduardo, what do you think of this patch?
> > Hi Rui,
> > 
> > Beside the fact which Javi pointed out in his email, there is an
> > issue in
> > the patch itself.
> > The idea behind the patch is good, but the patch should have some
> > improvements, i.e:
> > - strncpy instead of strcpy,
> > - if the governor name is not found in the registered governor's
> > list by
> > __find_governor (and then null is set) we should probably switch to
> > default
> > governor,
> > - add DT documentation,
> Also, the idea of the patch is good, almost tempting to do it, but
> unfortunately, not acceptable from DT perspective. The patch
> infringes
> two of the DT conceptual and design decision of:
> (a) DT should describe hardware, not policy;
> (b) DT should describe hardware, not OS specific implementations.
> 
> As already pointed by Javi, this patch has already been proposed
> (more
> than one time by different people), but, it still continues to be
> unacceptable.
> 
> Cheers,
> 
> 
> > 
> > 
> > Regards,
> > Lukasz
> > 


Re: [RFC 0/5] printk: Implement WARN_*DEFERRED()

2016-09-27 Thread Sergey Senozhatsky
On (09/27/16 18:02), Petr Mladek wrote:
> The main trick is that we replace the per-CPU function pointer
> by a preempt_count-like variable that could track the printk context.
> 
> I know that Sergey has another ideas in this area. But I wanted to see
> how this approach would look like.

well, yes. I was looking at WARN_*_DEFERRED [1] for some time, and, I
think, the maintenance cost of that solution is just too high:

a) every existing WARN_* in sched/timekeeping/who knows where else
   must be evaluated to ensure that in can't be called from printk()
   path. if `false' - then the corresponding macro must be replaced
   with _DEFERRED flavor.

b) any patch that adds new WARN_* usages must be additionally checked
   to ensure that each of new WARN_* macros cannot be called from printk
   path. if `false' -- the corresponding macro must be replaced with
   _DEFERRED flavor.

c) any patch that refactors the code or moves some function calls around
   etc. must be additionally checked for any accidental WARN_* from printk
   path. even though if none of the patches added any new WARN_* to the code.

b) apart from WARN_* there can be `accidental' pr_err/pr_debug/etc. not
   necessarily newly added (see 'c').


that's too much.
for example [not blaming anyone], a recent patch [2] that added a reasonable
WARN_ON_ONCE to assert_clock_updated() which, however, can result in a
possible printk() deadlock scenario that you, Petr, outlined [3]:

:+ printk()
:  + vprintk_func -> vprintk_default()
:+ vprinkt_emit()
:  + console_unlock()
:+ up_console_sem()
:  + up()# takes >lock
:+ __up()
:  + wake_up_process()
:+ try_to_wake_up()
:  + ttwu_queue()
:+ ttwu_do_activate()
:  + ttwu_do_wakeup()
:+ rq_clock()
:  + lockdep_assert_held()
:+ WARN_ON_ONCE()
:  + printk()
:+ vprintk_func -> vprintk_default()
:  + vprintk_emit()
:+ console_try_lock()
:  + down_trylock_console_sem()
:+ __down_trylock_console_sem()
:  + down_trylock()


it takes a lot of additional effort, because both reviewer and contributor
must consider printk() internals. and, what's worse, if something goes
unnoticed we end up having a printk() deadlock again.

so I decided to address some of printk() issues in printk.c, not in
kernel/time/timekeeping.c or kernel/sched/core.c or anywhere else.


> Mid-air collision:
>
> I have just realized that Sergey sent another patchset that was
> more generic, complicated, and had some similarities, see
> https://lkml.kernel.org/r/20160927142237.5539-1-sergey.senozhat...@gmail.com

yeah, I should have Cc-ed a wider audience. do I need to resend the
patch set with the `extended' Cc list?


[1] https://marc.info/?l=linux-kernel=147158843319944
[2] https://marc.info/?l=linux-kernel=147446511924573
[3] https://marc.info/?l=linux-kernel=147447352127741

-ss


Re: [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend

2016-09-27 Thread Brian Norris
Hi Marc,

Thanks again for the help. I was checking with Rockchip on the details.

On Tue, Sep 20, 2016 at 08:47:07AM +0100, Marc Zyngier wrote:
> The counter is allowed to be clocked at a different rate, as long as it
> is incremented by the frequency ratio on each tick of the new frequency.
> In your case, the counter should increment by 750 on each tick of the
> 32kHz clock. If the rk3399 implementation doesn't do this, then this is
> a bug, and we need a quirk to work around it.

I had hope that we could find a switch that would do the above for
rk3399, since other parts of the system (e.g., the PMU itself) support
switching from the 24MHz to 32KHz clock, but Rockchip confirmed that it
is indeed a HW quirk that the arch timer's counter does not support
clocking out ticks based on the 32KHz clock. So I'm planning to send a
v2 that adds a "arm,no-tick-in-suspend" property.


rk3288 (ARMv7 system widely used for our Chromebooks) has the same
issue, except the kernel we're using for production (based on v3.14)
doesn't have the following commit, which stopped utilizing the RTC:

commit 0fa88cb4b82b5cf7429bc1cef9db006ca035754e
Author: Xunlei Pang 
Date:   Wed Apr 1 20:34:38 2015 -0700

time, drivers/rtc: Don't bother with rtc_resume() for the nonstop 
clocksource

And any mainline testing on rk3288 doesn't see the problem, because
mainline doesn't support its lowest-power sleep modes well enough (see
ROCKCHIP_ARM_OFF_LOGIC_DEEP in arch/arm/mach-rockchip/pm.c).


> Note that such a quirk will have some other impacts, such as the
> gettimeofday implementation in the VDSO (which relies on the counter
> making forward progress). There could be other issues in the timer
> subsystem as well... This doesn't look like a pleasant thing to fix.

How sure are you of these problems? I'm a bit new to the kernel
timekeeping subsystem, but doesn't this kind of code already have to
handle time adjustments like this when reprogramming the system time
(settimeofday())? And might we be covered for the suspend/resume case
when we allow the kernel to fall back to the RTC instead, which adjusts
the sleep delta with timekeeping_inject_sleeptime64()? And (weaker
evidence here) we haven't seen problems on rk3288 so far, at least
without the above referenced rtc commit 0fa88cb4b82. But admittedly
there are some differences between arch/{arm,arm64}/.

Regards,
Brian


Re: [PATCH v2 2/4] mfd: lpc_ich: Do not create iTCO watchdog when WDAT table exists

2016-09-27 Thread Rafael J. Wysocki
On Wednesday, September 28, 2016 02:09:41 AM Lee Jones wrote:
> On Wed, 28 Sep 2016, Rafael J. Wysocki wrote:
> 
> > On Tuesday, September 27, 2016 08:41:14 PM Lee Jones wrote:
> > > On Tue, 20 Sep 2016, Mika Westerberg wrote:
> > > 
> > > > ACPI WDAT table is the preferred way to use hardware watchdog over the
> > > > native iTCO_wdt. Windows only uses this table for its hardware watchdog
> > > > implementation so we should be relatively safe to trust it has been
> > > > validated by OEMs
> > > > 
> > > > Prevent iTCO watchdog creation if we detect that there is ACPI WDAT 
> > > > table.
> > > > 
> > > > Signed-off-by: Mika Westerberg 
> > > > Reviewed-by: Guenter Roeck 
> > > > ---
> > > >  drivers/mfd/lpc_ich.c | 4 
> > > >  1 file changed, 4 insertions(+)
> > > 
> > > Applied, thanks.
> > 
> > Well, I applied this too.
> 
> How can you apply this without an MFD Ack?

First, Guenter has reviewed it.

Second, there was no response to this:

http://marc.info/?l=linux-acpi=147467687316117=4

> > And it depends on the [1/4], doesn't it?
> 
> Yes, I just found that out myself. :)
> 
> Well I only have 4 lines of changes in drivers/mfd/lpc_ich.c, so I
> guess it'll be okay to apply this without the fear of conflicts.
> 
> Do that end, please apply my:
> 
> Acked-by: Lee Jones 

Thanks!

Best,
Rafael



Re: [PATCH v2 2/4] mfd: lpc_ich: Do not create iTCO watchdog when WDAT table exists

2016-09-27 Thread Lee Jones
On Wed, 28 Sep 2016, Rafael J. Wysocki wrote:

> On Tuesday, September 27, 2016 08:41:14 PM Lee Jones wrote:
> > On Tue, 20 Sep 2016, Mika Westerberg wrote:
> > 
> > > ACPI WDAT table is the preferred way to use hardware watchdog over the
> > > native iTCO_wdt. Windows only uses this table for its hardware watchdog
> > > implementation so we should be relatively safe to trust it has been
> > > validated by OEMs
> > > 
> > > Prevent iTCO watchdog creation if we detect that there is ACPI WDAT table.
> > > 
> > > Signed-off-by: Mika Westerberg 
> > > Reviewed-by: Guenter Roeck 
> > > ---
> > >  drivers/mfd/lpc_ich.c | 4 
> > >  1 file changed, 4 insertions(+)
> > 
> > Applied, thanks.
> 
> Well, I applied this too.

How can you apply this without an MFD Ack?

> And it depends on the [1/4], doesn't it?

Yes, I just found that out myself. :)

Well I only have 4 lines of changes in drivers/mfd/lpc_ich.c, so I
guess it'll be okay to apply this without the fear of conflicts.

Do that end, please apply my:

Acked-by: Lee Jones 
  
> > > diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
> > > index bd3aa4578346..c8dee47b45d9 100644
> > > --- a/drivers/mfd/lpc_ich.c
> > > +++ b/drivers/mfd/lpc_ich.c
> > > @@ -984,6 +984,10 @@ static int lpc_ich_init_wdt(struct pci_dev *dev)
> > >   int ret;
> > >   struct resource *res;
> > >  
> > > + /* If we have ACPI based watchdog use that instead */
> > > + if (acpi_has_watchdog())
> > > + return -ENODEV;
> > > +
> > >   /* Setup power management base register */
> > >   pci_read_config_dword(dev, priv->abase, _addr_cfg);
> > >   base_addr = base_addr_cfg & 0xff80;
> > 
> > 
> 
> Thanks,
> Rafael
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH v6 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

2016-09-27 Thread Lee Jones
On Sat, 17 Sep 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 v6:
>  - update copyright
>  - add kernel-doc header for struct mxs-lradc
>  - add error message
>  - change EINVAL to ENODEV
>  - use PLATFORM_DEVID_NONE instead -1
>  - cosmetic fixes
> 
> 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   | 259 
> ++
>  include/linux/mfd/mxs-lradc.h | 203 +
>  4 files changed, 480 insertions(+)
>  create mode 100644 drivers/mfd/mxs-lradc.c
>  create mode 100644 include/linux/mfd/mxs-lradc.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 9ca66de..ffe14ef 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -271,6 +271,23 @@ config MFD_MC13XXX_I2C
>   help
> Select this if your MC13xxx is connected via an I2C bus.
>  
> +config MFD_MXS_LRADC
> + tristate "Freescale i.MX23/i.MX28 LRADC"
> + depends on ARCH_MXS || COMPILE_TEST
> + select MFD_CORE
> + select STMP_DEVICE
> + help
> +   Say yes here to build support for the Low Resolution
> +   Analog-to-Digital Converter (LRADC) found on the i.MX23 and i.MX28
> +   processors. This driver provides common support for accessing the
> +   device, additional drivers must be enabled in order to use the
> +   functionality of the device:
> + mxs-lradc-adc for ADC readings
> + mxs-lradc-ts  for touchscreen support
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called mxs-lradc.
> +
>  config MFD_HI6421_PMIC
>   tristate "HiSilicon Hi6421 PMU/Codec IC"
>   depends on OF
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 0f230a6..ecf6399 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -198,3 +198,4 @@ intel-soc-pmic-objs   := 
> intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC)   += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
>  obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +obj-$(CONFIG_MFD_MXS_LRADC)  += mxs-lradc.o
> diff --git a/drivers/mfd/mxs-lradc.c b/drivers/mfd/mxs-lradc.c
> new file mode 100644
> index 000..05ae894
> --- /dev/null
> +++ b/drivers/mfd/mxs-lradc.c
> @@ -0,0 +1,259 @@
> +/*
> + * Freescale MXS LRADC driver

Please use the full name here.  It's helpful if people are trying to
figure out what LRADC actually means.

> + * Copyright (c) 2012 DENX Software Engineering, GmbH.
> + * Copyright (c) 2016 Ksenija Stanojevic 
> + *
> + * Authors:
> + *  Marek Vasut 
> + *  Ksenija Stanojevic 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MXS_LRADC_BASE   0x8005
> +
> +enum 

Re: [PATCH 4/3] g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio

2016-09-27 Thread Finn Thain

On Sun, 25 Sep 2016, Ondrej Zary wrote:

> Merge the PIO and MMIO code (with the help of ioport_map) in g_NCR5380 and
> delete g_NCR5380_mmio.
> 
> Signed-off-by: Ondrej Zary 
> ---
>  drivers/scsi/Kconfig  |   32 ++---
>  drivers/scsi/g_NCR5380.c  |  257 
> +++--
>  drivers/scsi/g_NCR5380.h  |   33 ++
>  drivers/scsi/g_NCR5380_mmio.c |   10 --
>  4 files changed, 135 insertions(+), 197 deletions(-)
>  delete mode 100644 drivers/scsi/g_NCR5380_mmio.c
> 
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 7d1b431..fd1bca1 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -780,40 +780,22 @@ config SCSI_ISCI
> control unit found in the Intel(R) C600 series chipset.
>  
>  config SCSI_GENERIC_NCR5380
> - tristate "Generic NCR5380/53c400 SCSI PIO support"
> + tristate "Generic NCR5380/53c400 SCSI"
>   depends on ISA && SCSI
>   select SCSI_SPI_ATTRS
>   ---help---
> -   This is a driver for the old NCR 53c80 series of SCSI controllers
> -   on boards using PIO. Most boards such as the Trantor T130 fit this
> -   category, along with a large number of ISA 8bit controllers shipped
> -   for free with SCSI scanners. If you have a PAS16, T128 or DMX3191
> -   you should select the specific driver for that card rather than
> -   generic 5380 support.
> +   This is a driver for the old NCR 53c80 series of SCSI controllers.
> +   Most boards such as the Trantor T130 fit this category, along with
> +   a large number of ISA 8bit controllers shipped for free with SCSI
> +   scanners. If you have a PAS16, T128 or DMX3191 you should select the
> +   specific driver for that card rather than generic 5380 support.

The pas16 and t128 drivers were removed (see 4.9/scsi-queue). The DMX3191 
isn't an ISA card, so it isn't relevant.

>  
> It is explained in section 3.8 of the SCSI-HOWTO, available from
> -   .  If it doesn't work out
> -   of the box, you may have to change some settings in
> -   .
> +   .

I didn't find anything useful at that url.

Therefore, please change the help text as follows:

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 98e5d51..928d937 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -780,21 +780,14 @@ config SCSI_ISCI
  control unit found in the Intel(R) C600 series chipset.
 
 config SCSI_GENERIC_NCR5380
-   tristate "Generic NCR5380/53c400 SCSI PIO support"
+   tristate "Generic NCR5380/53C400 ISA card SCSI controller support"
depends on ISA && SCSI
select SCSI_SPI_ATTRS
---help---
- This is a driver for the old NCR 53c80 series of SCSI controllers
- on boards using PIO. Most boards such as the Trantor T130 fit this
- category, along with a large number of ISA 8bit controllers shipped
- for free with SCSI scanners. If you have a PAS16, T128 or DMX3191
- you should select the specific driver for that card rather than
- generic 5380 support.
-
- It is explained in section 3.8 of the SCSI-HOWTO, available from
- .  If it doesn't work out
- of the box, you may have to change some settings in
- .
+ This is a driver for old ISA card SCSI controllers based on the
+ NCR 5380, 53C80, 53C400 and 53C400A, and compatible DTC devices.
+ Most boards such as the Trantor T130 fit this category, along
+ with various 8-bit and 16-bit ISA cards bundled with SCSI scanners.
 
  To compile this driver as a module, choose M here: the
  module will be called g_NCR5380.


The rest of the patch looks good (aside from the missing module alias that 
Chrisoph mentioned).

Thanks.

-- 


Re: [RFC/RFT][PATCH v3 0/5] Functional dependencies between devices

2016-09-27 Thread Rafael J. Wysocki
On Tuesday, September 27, 2016 02:34:29 PM Lukas Wunner wrote:
> [+cc corbet]
> 
> To whom it may concern,
> 
> I made some notes while reviewing the state machine in patch 2 of this
> series and thought, why not rework it into something that could eventually
> go into the Documentation/ tree?
> 
> So here's an initial draft.  There's some introductory text plus
> a description of the state machine.  Just putting this out there now
> to ease reviewers' lives, despite the obvious WIP status.  I'll try to
> amend it as the series converges.
> 
> This is already rst-formatted but I haven't actually run it through
> sphinx yet.

Thanks a lot for doing this!

It looks good to me in general.  I think it would be good to add it to the
series at one point (if you don't mind).

I'm only a bit reluctant about advertising the usage of links between children
and parents, because that doesn't look like the right tool for the purpose
(as I said before, I'd prefer to add a device flag causing the parent driver
to be probed before the child one if needed).

Thanks,
Rafael


> -- >8 --
> 
> Subject: [PATCH] Documentation: device links: Add initial documentation
> 
> Signed-off-by: Lukas Wunner 
> ---
>  Documentation/driver-model/device_link.rst | 95 
> ++
>  1 file changed, 95 insertions(+)
>  create mode 100644 Documentation/driver-model/device_link.rst
> 
> diff --git a/Documentation/driver-model/device_link.rst 
> b/Documentation/driver-model/device_link.rst
> new file mode 100644
> index 000..ba911b4
> --- /dev/null
> +++ b/Documentation/driver-model/device_link.rst
> @@ -0,0 +1,95 @@
> +
> +Device links
> +
> +
> +By default, the driver core only enforces dependencies between devices
> +that are borne out of a parent/child relationship within the device
> +hierarchy: When suspending, resuming or shutting down the system, devices
> +are ordered based on this relationship, i.e. children are always suspended
> +before their parent, and the parent is always resumed before its children.
> +
> +Sometimes there is a need to represent device dependencies beyond the
> +mere parent/child relationship, e.g. between siblings, and have the
> +driver core automatically take care of them.
> +
> +Secondly, the driver core by default does not enforce any driver presence
> +dependencies, i.e. that one device must be bound to a driver before
> +another one can probe or function correctly.
> +
> +Often these two dependency types come together, so a device depends on
> +another one both with regards to driver presence *and* with regards to
> +suspend/resume and shutdown ordering.
> +
> +Device links allow representation of such dependencies in the driver core.
> +
> +In its standard form, a device link combines *both* dependency types:
> +It guarantees correct suspend/resume and shutdown ordering between a
> +"supplier" device and its "consumer" devices, and it guarantees driver
> +presence on the supplier:  The consumer devices are not probed before the
> +supplier is bound to a driver, and they're unbound before the supplier
> +is unbound.
> +
> +When driver presence on the supplier is irrelevant and only correct
> +suspend/resume and shutdown ordering is needed, the device link may
> +simply be set up with the DEVICE_LINK_STATELESS flag.
> +
> +A driver presence dependency between parent and child, i.e. within the
> +regular device hierarchy, could in principle also be represented in the
> +driver core using a device link.
> +
> +If a device link is set up with the DEVICE_LINK_AUTOREMOVE flag, it is
> +automatically purged when the consumer fails to probe or later unbinds.
> +This is handy when adding a device link from the consumer's ->probe hook,
> +as it obviates the need to delete the link in the ->remove hook or in
> +the error path of the ->probe hook.
> +
> +
> +State machine
> +=
> +
> +"""
> +.=.
> +| |
> +v |
> +DORMANT <=> AVAILABLE <=> CONSUMER_PROBE => ACTIVE
> +   ^  |
> +   |  |
> +   ' SUPPLIER_UNBIND <'
> +"""
> +
> +* The initial state of a device link is passed in to device_link_add().
> +  If the link is created before any devices are probed, it must be set to
> +  DEVICE_LINK_DORMANT.
> +
> +* When a supplier device is bound to a driver, links to its consumers
> +  progress to DEVICE_LINK_AVAILABLE.
> +  (Call to device_links_driver_bound() from driver_bound().)
> +
> +* Before a consumer device is probed, presence of supplier drivers is
> +  verified by checking that links to suppliers are in DEVICE_LINK_AVAILABLE
> +  state.  The state of the links is updated to DEVICE_LINK_CONSUMER_PROBE.
> +  (Call to device_links_check_suppliers() from driver_probe_device().)
> +  This prevents the supplier 

Re: NMI for ARC

2016-09-27 Thread Vineet Gupta
Hi Peter,

On 11/17/2015 05:15 AM, Peter Zijlstra wrote:
> On Tue, Nov 17, 2015 at 06:23:21PM +0530, Vineet Gupta wrote:
>> On Tuesday 17 November 2015 05:55 PM, Peter Zijlstra wrote:
>>
>>> This is assuming you now have these NMIs we talked about earlier. If all
>>> you have are regular IRQs this is not possible, for we should be calling
>>> ->read() with IRQs disabled.
>>>
>>
>> No we don't yet. The first stab at it fell flat on floor.
>>
>> The NMI support from hardware is that is it provides different priorities, 
>> higher
>> one obviously able to interrupt lower one. However instructions like CLRI 
>> (disable
>> interrupts) will still lock out all interrupts.
>>
>> Thus local_irq_save()/restore() and local_irq_enable()/disable() now need to 
>> be
>> contextual.
>>
>>   - When running in prio 0 mode, they only need to enable 0
>>   - In prio 1, they need to enable both 0 and 1
>>
>> For irq_save()/restore() this is achievable by doing an additional STATUS32 
>> read
>> at the time of save and passing that value to restore - so there's an 
>> additional
>> overhead - but ignoring that for now.
>>
>> Bummer is irq_disable()/enable() case: there's need to pass old prio state 
>> from
>> enable to disabled, so we need some sort of global state tracking - which in 
>> case
>> of SMP needs to be per cpu either keep something hot in a reg or pay the 
>> cost
>> of additional mem/cache line miss.
>>
>> I've not investigated how other arches do that. PPC seems to be using some 
>> sort of
>> soft irq state anyways.
> 
> Yeah, Sparc64 might be a better example, it more closely matches your
> hardware. See
> arch/sparc/include/asm/irqflags_64.h:arch_local_irq_save().

So I finally got around to doing this and as expected has turned out to be quite
some fun. I have a couple of questions and would really appreciate your inputs 
there.

1. Is it OK in general to short-circuit preemption off irq checks for NMI style
interrupts. The issue is we can get nested interrupts (timer followed by perf)
and one of them can cause resched_curr() to a user task - but we can't return to
user mode from inner interrupt. So it becomes easy if we don't even bother
checking for TIF_NEED_RESCHED in perf intr path. This also has slight advantage
that perf intr returns quickly. Implementation wise this requires a hack to bump
preemption count in the low level nmi handler - and revert that in nmi return 
path.

2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode
require interrupt safety, does that need to be NMI safe as well. We ofcourse 
want
the very late register restore parts to be non-interruptible, but is this 
required
before we call prrempt_schedule_irq() off of asm code.

Thx,
-Vineet


Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware

2016-09-27 Thread Ian Kent
On Tue, 2016-09-27 at 08:14 -0500, Eric W. Biederman wrote:
> Ian Kent  writes:
> 
> > On Mon, 2016-09-26 at 11:05 -0500, Eric W. Biederman wrote:
> > > Ian Kent  writes:
> > > 
> > > > On Fri, 2016-09-23 at 14:15 -0500, Eric W. Biederman wrote:
> > > > > Ian Kent  writes:
> > > > > 
> > > > > 2> On Thu, 2016-09-22 at 20:37 -0500, Eric W. Biederman wrote:
> > > > > > > Ian Kent  writes:
> > > > > > > 
> > > > > > > > On Thu, 2016-09-22 at 10:43 -0500, Eric W. Biederman wrote:
> > > > > > > > > Ian Kent  writes:
> > > > > > > > > 
> > > > > > > > > > Eric, Mateusz, I appreciate your spending time on this and
> > > > > > > > > > particularly
> > > > > > > > > > pointing
> > > > > > > > > > out my embarrassingly stupid is_local_mountpoint() usage
> > > > > > > > > > mistake.
> > > > > > > > > > 
> > > > > > > > > > Please accept my apology for the inconvenience.
> > > > > > > > > > 
> > > > > > > > > > If all goes well (in testing) I'll have follow up patches to
> > > > > > > > > > correct
> > > > > > > > > > this
> > > > > > > > > > fairly
> > > > > > > > > > soon.
> > > > > > > > > 
> > > > > > > > > Related question.  Do you happen to know how many mounts per
> > > > > > > > > mount
> > > > > > > > > namespace tend to be used?  It looks like it is going to be
> > > > > > > > > wise
> > > > > > > > > to
> > > > > > > > > put
> > > > > > > > > a configurable limit on that number.  And I would like the
> > > > > > > > > default
> > > > > > > > > to
> > > > > > > > > be
> > > > > > > > > something high enough most people don't care.  I believe
> > > > > > > > > autofs is
> > > > > > > > > likely where people tend to use the most mounts.
> > > > > > 
> > > > > > Yes, I agree, I did want to try and avoid changing the parameters to
> > > > > > ->d_mamange() but passing a struct path pointer might be better in
> > > > > > the
> > > > > > long
> > > > > > run
> > > > > > anyway.
> > > > > 
> > > > > Given that there is exactly one implementation of d_manage in the tree
> > > > > I
> > > > > don't imagine it will be disruptive to change that.
> > > > 
> > > > Yes, but it could be used by external modules.
> > > > 
> > > > And there's also have_submounts().
> > > 
> > > Good point about have_submounts.
> > > 
> > > > I can update that using the existing d_walk() infrastructure or take it
> > > > (mostly)
> > > > into the autofs module and get rid of have_submounts().
> > > > 
> > > > I'll go with the former to start with and see what people think.
> > > 
> > > That will be interesting to so.  It is not clear to me that if d_walk
> > > needs to be updated, and if d_walk doesn't need to be updated I would
> > > be surprised to see it take into autofs.  But I am happy to look at the
> > > end result and see what you come up with.
> > 
> > I didn't mean d_walk() itself, just the have_submounts() function that's
> > used
> > only by autofs these days. That's all I'll be changing.
> > 
> > To take this functionality into the autofs module shouldn't be a big deal as
> > it
> > amounts to a directory traversal with a check at each node.
> > 
> > But I vaguely remember talk of wanting to get rid of have_submounts() and
> > autofs
> > being the only remaining user.
> > 
> > So I mentioned it to try and elicit a comment, ;)
> 
> From my perspective the key detail is that d_walk is private to dcache.c
> 
> That said you want to look at may_umount_tree, or may_umount that
> are already exported from fs/namespace.c, and already used by autofs.
> One of those may already do the job you are trying to do.

Right, I'm aware of them, autofs uses may_umount() when asking if an autofs
mount can be umounted, and it uses may_umount_tree() to check busyness in its
expire.

may_umount_tree() (and may_umount()) won't tell you if there are any mounts
within the directory tree, only that there is an elevated reference count, for
example an open file or working directory etc., ie. busy.

OTOH, have_submounts() will return true as soon as it encounters a
d_mountpoint() dentry in the directory tree which is what's needed where it's
used and why it can return a false positive for the problem case.

I get that a function, say, path_has_submounts() probably shouldn't be placed in
dcache.c and that's another reason to take the traversal into autofs. 

But if there's no word from Al on that I'd prefer to use d_walk() and put it
there.

Ian


RE: [PATCH 1/2 v2] pci-hyperv: properly handle pci bus remove

2016-09-27 Thread Long Li


> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Tuesday, September 27, 2016 12:30 PM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Bjorn Helgaas ;
> de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Long Li 
> Subject: Re: [PATCH 1/2 v2] pci-hyperv: properly handle pci bus remove
> 
> On Wed, Sep 14, 2016 at 07:10:01PM -0700, Long Li wrote:
> > From: Long Li 
> >
> > hv_pci_devices_present is called in hv_pci_remove when we remove a PCI
> device from host (e.g. by disabling SRIOV on a device). In hv_pci_remove,
> the bus is already removed before the call, so we don't need to rescan the
> bus in the workqueue scheduled from hv_pci_devices_present. By
> introducing status hv_pcibus_removed, we can avoid this situation.
> >
> > The patch fixes the following kernel panic.
> >
> > [  383.853124] Workqueue: events pci_devices_present_work [pci_hyperv]
> > [  383.853124] task: 88007f5f8000 ti: 88007f60 task.ti:
> > 88007f60
> > [  383.853124] RIP: 0010:[]  []
> > pci_is_pcie+0x6/0x20
> > [  383.853124] RSP: 0018:88007f603d38  EFLAGS: 00010206 [
> > 383.853124] RAX: 88007f5f8000 RBX: 642f3d4854415056 RCX:
> > 88007f603fd8
> > [  383.853124] RDX:  RSI:  RDI:
> > 642f3d4854415056
> > [  383.853124] RBP: 88007f603d68 R08: 0246 R09:
> > a045eb9e
> > [  383.853124] R10: 88007b419a80 R11: ea0001c0ef40 R12:
> > 880003ee1c00
> > [  383.853124] R13: 63702f30303a3137 R14:  R15:
> > 0246
> > [  383.853124] FS:  () GS:88007b40()
> > knlGS:
> > [  383.853124] CS:  0010 DS:  ES:  CR0: 80050033 [
> > 383.853124] CR2: 7f68b3f52350 CR3: 03546000 CR4:
> > 000406f0
> > [  383.853124] DR0:  DR1:  DR2:
> > 
> > [  383.853124] DR3:  DR6: 0ff0 DR7:
> > 0400
> > [  383.853124] Stack:
> > [  383.853124]  88007f603d68 8134db17 0008
> > 880003ee1c00
> > [  383.853124]  63702f30303a3137 880003d8edb8 88007f603da0
> > 8134ee2d [  383.853124]  880003d8ed00 88007f603dd8
> > 880075fec320
> > 880003d8edb8
> > [  383.853124] Call Trace:
> > [  383.853124]  [] ? pci_scan_slot+0x27/0x140 [
> > 383.853124]  [] pci_scan_child_bus+0x3d/0x150 [
> > 383.853124]  []
> > pci_devices_present_work+0x3ea/0x400 [pci_hyperv] [  383.853124]
> > [] process_one_work+0x17b/0x470 [  383.853124]
> > [] worker_thread+0x126/0x410 [  383.853124]
> > [] ? rescuer_thread+0x460/0x460 [  383.853124]
> > [] kthread+0xcf/0xe0 [  383.853124]
> > [] ?
> > kthread_create_on_node+0x140/0x140
> > [  383.853124]  [] ret_from_fork+0x58/0x90 [
> > 383.853124]  [] ?
> > kthread_create_on_node+0x140/0x140
> > [  383.853124] Code: 89 e5 5d 25 f0 00 00 00 c1 f8 04 c3 66 0f 1f 84
> > 00
> > 00 00 00 00 66 66 66 66 90 55 0f b6 47 4a 48 89 e5 5d c3 90 66 66 66
> > 66
> > 90 55 <80> 7f 4a 00 48 89 e5 5d 0f 95 c0 c3 0f 1f 40 00 66 2e 0f 1f 84
> > [  383.853124] RIP  [] pci_is_pcie+0x6/0x20 [
> > 383.853124]  RSP 
> 
> Personally, I would remove the timestamps and addresses from this trace
> because I don't think they contribute to diagnosing the problem.

Thanks Bjorn. I will remove those kernel traces and send a v3 patch.

> 
> > Signed-off-by: Long Li 
> 
> I'm ready to apply these but am waiting for an ack from the maintainers listed
> in MAINTAINERS (feel free to update that if it's out of date).
> 
> > ---
> >  drivers/pci/host/pci-hyperv.c | 20 +---
> >  1 file changed, 17 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-hyperv.c
> > b/drivers/pci/host/pci-hyperv.c index a8deeca..4a37598 100644
> > --- a/drivers/pci/host/pci-hyperv.c
> > +++ b/drivers/pci/host/pci-hyperv.c
> > @@ -348,6 +348,7 @@ enum hv_pcibus_state {
> > hv_pcibus_init = 0,
> > hv_pcibus_probed,
> > hv_pcibus_installed,
> > +   hv_pcibus_removed,
> > hv_pcibus_maximum
> >  };
> >
> > @@ -1481,13 +1482,24 @@ static void pci_devices_present_work(struct
> work_struct *work)
> > put_pcichild(hpdev, hv_pcidev_ref_initial);
> > }
> >
> > -   /* Tell the core to rescan bus because there may have been changes.
> */
> > -   if (hbus->state == hv_pcibus_installed) {
> > +   switch (hbus->state) {
> > +   case hv_pcibus_installed:
> > +   /*
> > +* Tell the core to rescan bus
> > +* because there may have been changes.
> > +*/
> > pci_lock_rescan_remove();
> > pci_scan_child_bus(hbus->pci_bus);
> > pci_unlock_rescan_remove();
> > -   } else {
> > +   break;
> > +
> > +   case 

Re: [PATCH 3/3] g_NCR5380: Stop using scsi_module.c

2016-09-27 Thread Finn Thain

On Tue, 27 Sep 2016, Ondrej Zary wrote:

> On Monday 26 September 2016, Finn Thain wrote:
> 
> [...]
> 
> > > @@ -364,7 +304,7 @@ static int generic_NCR5380_release_resources(struct
> > > Scsi_Host *instance) release_mem_region(instance->base,
> > > hostdata->iomem_size);
> > >   }
> > >  #endif
> > > - return 0;
> > > + scsi_host_put(instance);
> >
> > The sequence of operations here should be the same as the error path
> > above.
> 
> I put scsi_host_put() call at the end because the release_mem_region 
> code (in the MMIO case) dereferences the hostdata pointer. I don't think 
> it's safe to do after scsi_host_put().

It's funny you say that, I already fixed a few of those use-after-free 
bugs in the other 5380 drivers. To avoid the bug, you'd need to use a 
temporary variable, like the fixes I did elsewhere.

Don't worry about changing it, this part of the driver gets revisited in 
my existing patch queue anyway.

> 
> [...]
> 
> > > +static int pnp_registered;
> > > +#endif /* !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP) */
> > > +
> > > +static int __init generic_NCR5380_init(void)
> > > +{
> > > + int ret = 0;
> > > +
> > > +#if !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP)
> > > + ret = pnp_register_driver(_NCR5380_pnp_driver);
> > > + if (!ret)
> > > + pnp_registered = 1;
> > >  #endif
> > > + ret = isa_register_driver(_NCR5380_isa_driver, MAX_CARDS);
> > > + if (!ret)
> > > + isa_registered = 1;
> > > +
> > > +#if !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP)
> > > + if (pnp_registered)
> > > + ret = 0;
> > > +#endif
> > > + if (isa_registered)
> > > + ret = 0;
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static void __exit generic_NCR5380_exit(void)
> > > +{
> > > +#if !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP)
> > > + if (pnp_registered)
> > > + pnp_unregister_driver(_NCR5380_pnp_driver);
> > > +#endif
> > > + if (isa_registered)
> > > + isa_unregister_driver(_NCR5380_isa_driver);
> > > +}
> > > +
> >
> > I find that hard to follow. This should be equivalent and simpler:
> >
> > static int __init generic_NCR5380_init(void)
> > {
> > isa_ret = isa_register_driver(_NCR5380_isa_driver, MAX_CARDS);
> > #if !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP)
> > pnp_ret = pnp_register_driver(_NCR5380_pnp_driver);
> > return pnp_ret ? isa_ret : 0;
> > #endif
> > return isa_ret;
> > }
> >
> > static void __exit generic_NCR5380_exit(void)
> > {
> > if (!isa_ret)
> > isa_unregister_driver(_NCR5380_isa_driver);
> > #if !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP)
> > if (!pnp_ret)
> > pnp_unregister_driver(_NCR5380_pnp_driver);
> > #endif
> > }
> 
> Doesn't make it any better, IMHO. Good that it's shorter but not cleaner - 
> especially this:
> > return pnp_ret ? isa_ret : 0;

The problem with that line is that pnp_ret is always discarded, same as in 
your version. I think my version makes that clear, which is what matters 
to me.

> 
> Also looking at the _exit function, meaning of isa_ret and pnp_ret is not 
> obvious there.
> 
> Maybe we should have a module_isa_pnp_driver() macro.
> 
> 

FWIW I would hope that the hypothetical definition of this 
`module_isa_pnp_driver' macro would have the same properties as my 
version: shorter, uses no temporaries and uses one less #ifdef, and is 
generally easier for me to read.

-- 


Re: [PATCH 1/3] arm: dts: imx7: Update #pwm-cells for PWM polarity control

2016-09-27 Thread Bhuvanchandra DV

On 09/23/16 23:22, Rob Herring wrote:


On Mon, Sep 19, 2016 at 07:53:45PM +0530, Bhuvanchandra DV wrote:

Update #pwm-cells to 3 in order to support PWM signal polarity control.

Signed-off-by: Bhuvanchandra DV 
---
  Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +++---
  arch/arm/boot/dts/imx7s.dtsi  | 8 
  2 files changed, 7 insertions(+), 7 deletions(-)

The driver will still work with old DTs, right? If so,


This patchset actually depends on the v6 patchset[1] from Lothar.
Some how that patchset got stalled in ML. I will re-spin the v6
patchset with the suggestions/changes from Lukasz in this patch[2]
after testing.

[1]http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/294027.html
[2]https://www.spinics.net/lists/arm-kernel/msg530818.html



Acked-by: Rob Herring 




[PATCH 1/2] Input: introduce ABS_MAX2/CNT2 and friends

2016-09-27 Thread Roderick Colenbrander
From: Roderick Colenbrander 

David Herrmann's original patch was ported over to a modern Linux kernel.
In the process, we went over all the feedback to the original patch series
and added various improvements:

- evdev_handle_get_abs2 returns valid_cnt instead of 0 when succesfull
- Updated documentation of EVIOCGABS2/EVIOCSABS2 ioctls based.
- Clarified language around ABS_MAX2 definition, to state the *ABS2 ioctls
  should be used for the full range.

[PATCH 2/4] Input: introduce ABS_MAX2/CNT2 and friends

David Herrmann 
Tue Dec 17 07:48:52 PST 2013
Previous message: [PATCH 1/4] Input: uinput: add full absinfo support
Next message: [PATCH 2/4] Input: introduce ABS_MAX2/CNT2 and friends
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
As we painfully noticed during the 3.12 merge-window our
EVIOCGABS/EVIOCSABS API is limited to ABS_MAX<=0x3f. We tried several
hacks to work around it but if we ever decide to increase ABS_MAX, the
EVIOCSABS ioctl ABI might overflow into the next byte causing horrible
misinterpretations in the kernel that we cannot catch.

Therefore, we decided to go with ABS_MAX2/CNT2 and introduce two new
ioctls to get/set abs-params. They no longer encode the ABS code in the
ioctl number and thus allow up to 4 billion ABS codes.

The new API also allows to query multiple ABS values with one call. To
allow EVIOCSABS2(code = 0, cnt = ABS_CNT2) we need to silently ignore
writes to ABS_MT_SLOT. Furthermore, for better compatibility with
newer user-space, we ignore writes to unknown codes. Hence, if we ever
increase ABS_MAX2, new user-space will work with code=0,cnt=ABS_CNT2 just
fine even on old kernels.

Note that we also need to increase EV_VERSION so user-space can reliably
know whether ABS2 is supported. Unfortunately, we return EINVAL instead of
ENOSYS for unknown evdev ioctls so it's nearly impossible to catch
reliably without EVIOCGVERSION.

Signed-off-by: David Herrmann 
Signed-off-by: Roderick Colenbrander 
---
 drivers/hid/hid-debug.c  |  2 +-
 drivers/hid/hid-input.c  |  2 +-
 drivers/input/evdev.c| 95 +++-
 drivers/input/input.c| 14 ++---
 drivers/input/keyboard/goldfish_events.c |  6 +-
 drivers/input/keyboard/hil_kbd.c |  2 +-
 drivers/input/misc/uinput.c  |  8 +--
 include/linux/hid.h  |  2 +-
 include/linux/input.h|  6 +-
 include/linux/mod_devicetable.h  |  2 +-
 include/uapi/linux/input-event-codes.h   | 14 -
 include/uapi/linux/input.h   | 37 -
 12 files changed, 165 insertions(+), 25 deletions(-)

diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index acfb522..7205d4a 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -963,7 +963,7 @@ static const char *relatives[REL_MAX + 1] = {
[REL_WHEEL] = "Wheel",  [REL_MISC] = "Misc",
 };
 
-static const char *absolutes[ABS_CNT] = {
+static const char *absolutes[ABS_CNT2] = {
[ABS_X] = "X",  [ABS_Y] = "Y",
[ABS_Z] = "Z",  [ABS_RX] = "Rx",
[ABS_RY] = "Ry",[ABS_RZ] = "Rz",
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index bcfaf32..26b161d 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1411,7 +1411,7 @@ static bool hidinput_has_been_populated(struct hid_input 
*hidinput)
for (i = 0; i < BITS_TO_LONGS(REL_CNT); i++)
r |= hidinput->input->relbit[i];
 
-   for (i = 0; i < BITS_TO_LONGS(ABS_CNT); i++)
+   for (i = 0; i < BITS_TO_LONGS(ABS_CNT2); i++)
r |= hidinput->input->absbit[i];
 
for (i = 0; i < BITS_TO_LONGS(MSC_CNT); i++)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index e9ae3d5..569e425 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -815,7 +815,7 @@ static int handle_eviocgbit(struct input_dev *dev,
case  0: bits = dev->evbit;  len = EV_MAX;  break;
case EV_KEY: bits = dev->keybit; len = KEY_MAX; break;
case EV_REL: bits = dev->relbit; len = REL_MAX; break;
-   case EV_ABS: bits = dev->absbit; len = ABS_MAX; break;
+   case EV_ABS: bits = dev->absbit; len = ABS_MAX2; break;
case EV_MSC: bits = dev->mscbit; len = MSC_MAX; break;
case EV_LED: bits = dev->ledbit; len = LED_MAX; break;
case EV_SND: bits = dev->sndbit; len = SND_MAX; break;
@@ -827,6 +827,93 @@ static int handle_eviocgbit(struct input_dev *dev,
return bits_to_user(bits, len, size, p, compat_mode);
 }
 
+static int evdev_handle_get_abs2(struct input_dev *dev, void __user *p)
+{
+   u32 code, cnt, valid_cnt, i;
+   struct input_absinfo2 __user *pinfo = p;
+   struct input_absinfo abs;
+
+   if (copy_from_user(, >code, 

[PATCH 2/2] Input: add motion-tracking ABS_* bits and docs

2016-09-27 Thread Roderick Colenbrander
From: Roderick Colenbrander 

This patch introduces new axes for acceleration and angular velocity.
David Herrmann's work served as a base, but we extended the specification
with various changes inspired by real devices and challenges we see
when doing motion tracking.

- Changed unit of acceleration to G instead of m/s^2. We felt that m/s^2
  is not the appropriate unit to return, because accelerometers are most
  often calibrated based on gravity. They return values in multiples of
  G and since we don't know the device location on earth, we should not
  blindly multiply by '9.8' for accuracy reasons. Such conversion is left
  to userspace.
- Resolution field is used for acceleration and gyro to report precision.
  The previous spec, specified to map 1 unit to e.g. 0.001 deg/s or 0.001 m/s^2.
  This is of course simpler for applications, but unit definition is a bit
  arbitrary. Previous axes definitions used the resolution field, which
  felt more consistent.
- Added section on timestamps, which are important for accurate motion
  tracking purposes. The use of MSC_TIMESTAMP was recommended in this
  situation to get access to the hardware timestamp if available.
- Changed motion axes to be defined as a right-handed coordinate system.
  Due to this change the gyro vectors are now defined as counter-clockwise.
  The overall changes makes the definitions consistent with computer graphics.

[PATCH 4/4] Input: add motion-tracking ABS_* bits and docs
David Herrmann 
Tue Dec 17 07:48:54 PST 2013

Motion sensors are getting quite common in mobile devices. To avoid
returning accelerometer data via ABS_X/Y/Z and irritating the Xorg
mouse-driver, this adds separate ABS_* bits for that.

This is needed if gaming devices want to report their normal data plus
accelerometer/gyro data. Usually, ABS_X/Y are already used by analog
sticks, so need separate definitions, anyway.

Signed-off-by: David Herrmann 
Signed-off-by: Roderick Colenbrander 
---
 Documentation/input/gamepad.txt |   9 +-
 Documentation/input/motion-tracking.txt | 176 
 include/uapi/linux/input-event-codes.h  |   7 ++
 3 files changed, 190 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/input/motion-tracking.txt

diff --git a/Documentation/input/gamepad.txt b/Documentation/input/gamepad.txt
index 3f6d8a5..ed13782 100644
--- a/Documentation/input/gamepad.txt
+++ b/Documentation/input/gamepad.txt
@@ -57,6 +57,9 @@ Most gamepads have the following features:
   - Rumble
 Many devices provide force-feedback features. But are mostly just
 simple rumble motors.
+  - Motion-tracking
+Gamepads may include motion-tracking sensors like accelerometers and
+gyroscopes.
 
 3. Detection
 
@@ -138,8 +141,6 @@ Triggers:
   Upper trigger buttons are reported as BTN_TR or ABS_HAT1X (right) and BTN_TL
   or ABS_HAT1Y (left). Lower trigger buttons are reported as BTN_TR2 or
   ABS_HAT2X (right/ZR) and BTN_TL2 or ABS_HAT2Y (left/ZL).
-  If only one trigger-button combination is present (upper+lower), they are
-  reported as "right" triggers (BTN_TR/ABS_HAT1X).
 (ABS trigger values start at 0, pressure is reported as positive values)
 
 Menu-Pad:
@@ -155,5 +156,9 @@ Menu-Pad:
 Rumble:
   Rumble is advertised as FF_RUMBLE.
 
+Motion-tracking:
+  Motion-tracking is defined in ./Documentation/input/motion-tracking.txt and
+  gamepads shall comply to the rules defined there.
+
 
   Written 2013 by David Herrmann 
diff --git a/Documentation/input/motion-tracking.txt 
b/Documentation/input/motion-tracking.txt
new file mode 100644
index 000..d34a290
--- /dev/null
+++ b/Documentation/input/motion-tracking.txt
@@ -0,0 +1,176 @@
+   Motion Tracking API
+
+
+1. Intro
+
+Motion tracking devices produce device motion events generated from an
+accelerometer, gyroscope or compass. These data can be returned to user-space
+via input events. This document defines how these data are reported.
+
+2. Devices
+~~
+In this document, a "device" is one of:
+ - accelerometer
+ - gyroscope
+ - compass
+
+These devices returned their information via different APIs in the past. To
+unify them and define a common API, a set of input evdev codes was created. Old
+drivers might continue using their API, but developers are encouraged to use
+the input evdev API for new drivers.
+
+2.1 Axes
+
+Movement data is usually returned as absolute data for the 3 axes of a device.
+In this context, the three axes are defined in a right-handed coordinate
+system as:
+ - X: Axis goes from the left to the right side of the device
+ - Y: Axis goes from the bottom to the top of the device
+ - Z: Axis goes 

Re: [PATCH 2/2] mfd: arizona: Handle probe deferral for reset GPIO

2016-09-27 Thread Lee Jones
On Tue, 20 Sep 2016, Charles Keepax wrote:

> The Arizona CODECs will generally function correctly without a reset line
> although it is strongly advised to have one, as such we do allow the system
> to boot if the reset gpio is missing or incorrectly specified.  However
> we should fail probe if we get a probe deferral request, this patch adds
> handling for this case.
> 
> Reported-by: Richard Fitzgerald 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/arizona-core.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index f466f29..d18f3b1 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -813,7 +813,9 @@ static int arizona_of_get_core_pdata(struct arizona 
> *arizona)
>   int count = 0;
>  
>   pdata->reset = of_get_named_gpio(arizona->dev->of_node, "wlf,reset", 0);
> - if (pdata->reset < 0) {
> + if (pdata->reset == -EPROBE_DEFER) {
> + return pdata->reset;
> + } else if (pdata->reset < 0) {
>   dev_err(arizona->dev, "Reset gpio missing/malformed: %d\n",
>   pdata->reset);
>  
> @@ -1011,11 +1013,14 @@ int arizona_dev_init(struct arizona *arizona)
>   dev_set_drvdata(arizona->dev, arizona);
>   mutex_init(>clk_lock);
>  
> - if (dev_get_platdata(arizona->dev))
> + if (dev_get_platdata(arizona->dev)) {
>   memcpy(>pdata, dev_get_platdata(arizona->dev),
>  sizeof(arizona->pdata));
> - else
> - arizona_of_get_core_pdata(arizona);
> + } else {
> + ret = arizona_of_get_core_pdata(arizona);
> + if (ret < 0)
> + return ret;
> + }
>  
>   BUILD_BUG_ON(ARRAY_SIZE(arizona->mclk) != ARRAY_SIZE(mclk_name));
>   for (i = 0; i < ARRAY_SIZE(arizona->mclk); i++) {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 1/2] mfd: arizona: Remove arizona_of_get_named_gpio helper function

2016-09-27 Thread Lee Jones
On Tue, 20 Sep 2016, Charles Keepax wrote:

> This function is only used in a single place and no new users will be
> added as all the devices other required GPIOs are already handled. As
> such just merge the code back into the calling function.
> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/arizona-core.c   | 27 +++
>  include/linux/mfd/arizona/core.h |  3 ---
>  2 files changed, 7 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index 4c18c8e..f466f29 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -803,25 +803,6 @@ unsigned long arizona_of_get_type(struct device *dev)
>  }
>  EXPORT_SYMBOL_GPL(arizona_of_get_type);
>  
> -int arizona_of_get_named_gpio(struct arizona *arizona, const char *prop,
> -   bool mandatory)
> -{
> - int gpio;
> -
> - gpio = of_get_named_gpio(arizona->dev->of_node, prop, 0);
> - if (gpio < 0) {
> - if (mandatory)
> - dev_err(arizona->dev,
> - "Mandatory DT gpio %s missing/malformed: %d\n",
> - prop, gpio);
> -
> - gpio = 0;
> - }
> -
> - return gpio;
> -}
> -EXPORT_SYMBOL_GPL(arizona_of_get_named_gpio);
> -
>  static int arizona_of_get_core_pdata(struct arizona *arizona)
>  {
>   struct arizona_pdata *pdata = >pdata;
> @@ -831,7 +812,13 @@ static int arizona_of_get_core_pdata(struct arizona 
> *arizona)
>   int ret, i;
>   int count = 0;
>  
> - pdata->reset = arizona_of_get_named_gpio(arizona, "wlf,reset", true);
> + pdata->reset = of_get_named_gpio(arizona->dev->of_node, "wlf,reset", 0);
> + if (pdata->reset < 0) {
> + dev_err(arizona->dev, "Reset gpio missing/malformed: %d\n",

gpio should be GPIO.

I'll probably just fix this up myself though.

Applied, thanks.

> + pdata->reset);
> +
> + pdata->reset = 0;
> + }
>  
>   ret = of_property_read_u32_array(arizona->dev->of_node,
>"wlf,gpio-defaults",
> diff --git a/include/linux/mfd/arizona/core.h 
> b/include/linux/mfd/arizona/core.h
> index b9909bb..b31b3be 100644
> --- a/include/linux/mfd/arizona/core.h
> +++ b/include/linux/mfd/arizona/core.h
> @@ -191,7 +191,4 @@ int cs47l24_patch(struct arizona *arizona);
>  int wm8997_patch(struct arizona *arizona);
>  int wm8998_patch(struct arizona *arizona);
>  
> -extern int arizona_of_get_named_gpio(struct arizona *arizona, const char 
> *prop,
> -  bool mandatory);
> -
>  #endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [RFC 1/2] power: power_supply: add new property POWER_SUPPLY_PROP_POLL_INTERVAL

2016-09-27 Thread Matt Ranostay
On Wed, Sep 21, 2016 at 10:52 PM, Matt Ranostay  wrote:
> Add new POWER_SUPPLY_PROP_POLL_INTERVAL property to display/set update
> interval in milliseconds of the device.

Should be seconds.
>
> Signed-off-by: Matt Ranostay 
> ---
>  Documentation/power/power_supply_class.txt | 1 +
>  drivers/power/power_supply_sysfs.c | 1 +
>  include/linux/power_supply.h   | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/Documentation/power/power_supply_class.txt 
> b/Documentation/power/power_supply_class.txt
> index 82dacc06e355..c2e97872374a 100644
> --- a/Documentation/power/power_supply_class.txt
> +++ b/Documentation/power/power_supply_class.txt
> @@ -158,6 +158,7 @@ while battery powers a load)
>  TIME_TO_FULL - seconds left for battery to be considered full (i.e.
>  while battery is charging)
>
> +POLL_INTERVAL - seconds between battery stats querying
>
>  Battery <-> external power supply interaction
>  ~
> diff --git a/drivers/power/power_supply_sysfs.c 
> b/drivers/power/power_supply_sysfs.c
> index 80fed98832f9..df66fad322c2 100644
> --- a/drivers/power/power_supply_sysfs.c
> +++ b/drivers/power/power_supply_sysfs.c
> @@ -198,6 +198,7 @@ static struct device_attribute power_supply_attrs[] = {
> POWER_SUPPLY_ATTR(scope),
> POWER_SUPPLY_ATTR(charge_term_current),
> POWER_SUPPLY_ATTR(calibrate),
> +   POWER_SUPPLY_ATTR(poll_interval),
> /* Properties of type `const char *' */
> POWER_SUPPLY_ATTR(model_name),
> POWER_SUPPLY_ATTR(manufacturer),
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 751061790626..5d45ac511a64 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -148,6 +148,7 @@ enum power_supply_property {
> POWER_SUPPLY_PROP_SCOPE,
> POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
> POWER_SUPPLY_PROP_CALIBRATE,
> +   POWER_SUPPLY_PROP_POLL_INTERVAL, /* in seconds! */
> /* Properties of type `const char *' */
> POWER_SUPPLY_PROP_MODEL_NAME,
> POWER_SUPPLY_PROP_MANUFACTURER,
> --
> 2.7.4
>


Re: [PATCH v7 0/8] power: add power sequence library

2016-09-27 Thread Peter Chen
On Wed, Sep 28, 2016 at 01:30:17AM +0200, Maciej S. Szmigiero wrote:
> On 20.09.2016 05:36, Peter Chen wrote:
> > Hi all,
> > 
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >  
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
> > driver).
> > 
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> > 
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> > 
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> > 
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> 
> Just tested this patch set on UDOO board again to make sure that it still
> works after all changes done since it was last tested there and can confirm
> that it does work correctly.
> 

Thanks, Maciej.

-- 

Best Regards,
Peter Chen


[PATCH 0/2] Input: ABS2 and motion tracking

2016-09-27 Thread Roderick Colenbrander
From: Roderick Colenbrander 

For some input driver work we have been doing, we were limited by not
having a wide enough ABS range in evdev. The current ABS range is mostly
full and due to limitations on the ioctl design, it can't be extended.

About 3 years ago, David Herrmann did work in this area to address this
problem for similar reasons as us. However his patches at the time didn't
make it in.

Since we have a need for this kind of functionality, we took over his
patches and are submitting them again with various improvements based
on feedback to the original patches and some new functionality for motion
tracking we are interested in ourselves. The patchset is simpler than before,
because at the time a uinput overhaul was needed, before uinput could even
support ABS_MAX2, which has happened since then.

The patches have been tested with some David's libevdev branch which
supports the new APIs. In addition we verified the new APIs in some
of internal software.

Thanks,
Roderick Colenbrander
Gaikai Inc, a Sony Interactive Entertainment Company

Roderick Colenbrander (2):
  Input: introduce ABS_MAX2/CNT2 and friends
  Input: add motion-tracking ABS_* bits and docs

 Documentation/input/gamepad.txt  |   9 +-
 Documentation/input/motion-tracking.txt  | 176 +++
 drivers/hid/hid-debug.c  |   2 +-
 drivers/hid/hid-input.c  |   2 +-
 drivers/input/evdev.c|  95 -
 drivers/input/input.c|  14 +--
 drivers/input/keyboard/goldfish_events.c |   6 +-
 drivers/input/keyboard/hil_kbd.c |   2 +-
 drivers/input/misc/uinput.c  |   8 +-
 include/linux/hid.h  |   2 +-
 include/linux/input.h|   6 +-
 include/linux/mod_devicetable.h  |   2 +-
 include/uapi/linux/input-event-codes.h   |  21 +++-
 include/uapi/linux/input.h   |  37 ++-
 14 files changed, 355 insertions(+), 27 deletions(-)
 create mode 100644 Documentation/input/motion-tracking.txt

-- 
2.7.4



[GIT PULL] cgroup fixes for v4.8-rc8

2016-09-27 Thread Tejun Heo
Hello, Linus.

Three late fixes for cgroup.  Two cpuset ones, one trivial and the
other pretty obscure, and a cgroup core fix for a bug which impacts
cgroup v2 namespace users.

Thanks.

The following changes since commit 568ac888215c7fb2fabe8ea739b00ec3c1f5d440:

  cgroup: reduce read locked section of cgroup_threadgroup_rwsem during fork 
(2016-08-17 09:54:52 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-4.8-fixes

for you to fetch changes up to 9157056da8f8c4a6305f15619e269f164b63a6de:

  cgroup: fix invalid controller enable rejections with cgroup namespace 
(2016-09-23 16:55:49 -0400)


Joonwoo Park (1):
  cpuset: handle race between CPU hotplug and cpuset_hotplug_work

Tejun Heo (1):
  cgroup: fix invalid controller enable rejections with cgroup namespace

Wei Yongjun (1):
  cpuset: fix non static symbol warning

 kernel/cgroup.c | 29 +
 kernel/cpuset.c | 19 +++
 2 files changed, 40 insertions(+), 8 deletions(-)

-- 
tejun


Re: [PATCH v7 0/8] power: add power sequence library

2016-09-27 Thread Maciej S. Szmigiero
On 20.09.2016 05:36, Peter Chen wrote:
> Hi all,
> 
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> power sequence instances will be added at postcore_initcall, the match
> criteria is compatible string first, if the compatible string is not
> matched between dts and library, it will try to use generic power sequence.
>
> The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence instance is needed, for more power sequences
> are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
> driver).
> 
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
> 
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
> 
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
> 
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html

Just tested this patch set on UDOO board again to make sure that it still
works after all changes done since it was last tested there and can confirm
that it does work correctly.

Maciej



Re: [PATCH trival -resend 2/2] lib: clean up put_cpu_var usage

2016-09-27 Thread Tejun Heo
On Tue, Sep 27, 2016 at 08:42:42AM -0700, Shaohua Li wrote:
> 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 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun


Re: [PATCH trival -resend 1/2] bpf: clean up put_cpu_var usage

2016-09-27 Thread Tejun Heo
On Tue, Sep 27, 2016 at 08:42:41AM -0700, Shaohua Li wrote:
> 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 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun


mmotm 2016-09-27-16-08 uploaded

2016-09-27 Thread akpm
The mm-of-the-moment snapshot 2016-09-27-16-08 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.8-rc8:
(patches marked "*" will be included in linux-next)

  i-need-old-gcc.patch
* mmksm-fix-endless-looping-in-allocating-memory-when-ksm-enable.patch
* dma-mappingh-preserve-unmap-info-for-config_dma_api_debug.patch
* scripts-recordmcountc-account-for-softirqentrytext.patch
* mem-hotplug-use-nodes-that-contain-memory-as-mask-in-new_node_page.patch
* 
mm-workingset-fix-crash-in-shadow-node-shrinker-caused-by-replace_page_cache_page.patch
* ocfs2-fix-deadlock-on-mmapped-page-in-ocfs2_write_begin_nolock.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* fsnotify-drop-notification_mutex-before-destroying-event.patch
* fsnotify-convert-notification_mutex-to-a-spinlock.patch
* fsnotify-convert-notification_mutex-to-a-spinlock-fix.patch
* fanotify-use-notification_lock-instead-of-access_lock.patch
* fanotify-fix-possible-false-warning-when-freeing-events.patch
* fsnotify-cleanup-spinlock-assertions.patch
* kbuild-simpler-generation-of-assembly-constants.patch
* fs-ocfs2-dlmfs-remove-deprecated-create_singlethread_workqueue.patch
* fs-ocfs2-cluster-remove-deprecated-create_singlethread_workqueue.patch
* fs-ocfs2-super-remove-deprecated-create_singlethread_workqueue.patch
* fs-ocfs2-dlm-remove-deprecated-create_singlethread_workqueue.patch
* ocfs2-fix-undefined-struct-variable-in-inodeh.patch
* ocfs2-free-the-mle-while-the-res-had-one-to-avoid-mle-memory-leak.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
* fs-select-add-vmalloc-fallback-for-select2.patch
* kernel-watchdog-use-nmi-registers-snapshot-in-hardlockup-handler.patch
  mm.patch
* mm-oom-deduplicate-victim-selection-code-for-memcg-and-global-oom.patch
* mm-zsmalloc-add-trace-events-for-zs_compact.patch
* mm-zsmalloc-add-per-class-compact-trace-event.patch
* mm-vmalloc-fix-align-value-calculation-error.patch
* mm-vmalloc-fix-align-value-calculation-error-fix.patch
* mm-vmalloc-fix-align-value-calculation-error-v2.patch
* mm-vmalloc-fix-align-value-calculation-error-v2-fix.patch
* mm-vmalloc-fix-align-value-calculation-error-v2-fix-fix.patch
* mm-vmalloc-fix-align-value-calculation-error-v2-fix-fix-fix.patch
* mm-memcontrol-add-sanity-checks-for-memcg-idref-on-get-put.patch
* mm-oom_killc-fix-task_will_free_mem-comment.patch
* mm-compaction-make-whole_zone-flag-ignore-cached-scanner-positions.patch
* 
mm-compaction-make-whole_zone-flag-ignore-cached-scanner-positions-checkpatch-fixes.patch
* mm-compaction-cleanup-unused-functions.patch
* mm-compaction-rename-compact_partial-to-compact_success.patch
* 

Re: UFS API in the kernel

2016-09-27 Thread subhashj

Hi Joao,


On 2016-09-26 18:10, Kiwoong Kim wrote:

Hi.

If you want to declare some things for user interface,
is it be better to put those thing include/uapi/linux/ than 
include/linux?


Agreed with Mr. Pinto's opinion with respect to implementing additional 
ioctls.


Yes, "scsi_host_template" allows the LLD's to export their ioctl 
callback and then you can use the sg interface to issue UFS specific 
ioctls. We had implemented similar ioctl for our use, here is the 
reference code: 
https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/scsi/ufs/ufshcd.c?h=LA.HB.1.1.1.c2#n6791. 
This was mainly done to  export the UFS query request interface to user 
space. Declarations where exported under include/uapi/scsi/ufs/ . If you 
want to build upon this already existing functionality, i can post the 
formal patch on mailing list.


Regards,
Subhash




Regards.


-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Shaun Tancheff
Sent: Tuesday, September 27, 2016 4:23 AM
To: Joao Pinto
Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: UFS API in the kernel

On Thu, Sep 22, 2016 at 10:21 AM, Joao Pinto 
wrote:
> Hi!
>
> I am designing an application that has the goal to be an utility for
> Unipro and UFS testing purposes. This application is going to run on
> top of a recent Linux Kernel containing the new UFS stack (including the
new DWC drivers).
>
> I am considering doing the following:
> a) Create a new config item called CONFIG_UFS_CHARDEV which is going
> to create a char device responsible to make some IOCTL available for
> user-space applications
> b) Create a linux/ufs.h header file that contains data structures
> declarations that will be needed in user-space applications

I am not very familiar with UFS devices, that said you should have an 
sgX

chardev being created already so you can handle SG_IO requests.
There also appear to be some sysfs entries being created.

So between sg and sysfs you should be able to handle any user-space 
out of

band requests without resorting to making a new chardev.

Adding more sysfs entries, if you need them, should be fine.

You may find it easier to expand on the existing interfaces than to 
get

consensus on a new driver and ioctls.

Hope this helps,
Shaun

> Could you please advise me about what the correct approach should be
> to make it as standard as possible and usable in the future?
>
> Thank you very much for your help!
>
> regards,
> Joao
> --
> 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
> https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_ma
> jordomo-2Dinfo.html=DQICaQ=IGDlg0lD0b-nebmJJ0Kp8A=Wg5NqlNlVTT7Ug
> l8V50qIHLe856QW0qfG3WVYGOrWzA=vJFB6pCywWtdvkgHz9Vc0jQz0xzeyZlr-7eCWY
> u88nM=yiQLPFpqmMrbqLZz1Jb3aNqOje2dRMLJHEzUDobwcXc=



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



--
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: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

2016-09-27 Thread Sinan Kaya
On 9/27/2016 6:58 PM, Rafael J. Wysocki wrote:
>> :04 04 9bf16c388d23bb66e087809f069eafed18e46a8c 
>> bcac95fb33ee834aec7d23eab9eb0dc5e330c68c M  drivers
> OK
> 
> Sinan, can you help, please?
> 
> 

Sure, let's see what's going on. I was writing an email. 

Can we apply this and collect the kernel log? It also helps to see the kernel 
log from a working
combination.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.
From 9181f4b9ab405bc6c9412133aefef7676899733c Mon Sep 17 00:00:00 2001
From: Sinan Kaya 
Date: Tue, 27 Sep 2016 18:35:15 -0400
Subject: [PATCH] acpi: pci_link: debug aids

Change-Id: I6c459cb5888d95f5f1ef7c0e2f138fb9c65f40e5
---
 drivers/acpi/pci_link.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index c983bf7..44937f93 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -508,6 +508,8 @@ static int acpi_irq_get_penalty(int irq)
penalty += PIRQ_PENALTY_ISA_ALWAYS;
else
penalty += PIRQ_PENALTY_PCI_USING;
+
+   pr_info("%s:%d adding SCI penalty: %d\n", __func__, __LINE__, 
penalty);
}
 
if (irq < ACPI_MAX_ISA_IRQS)
@@ -604,6 +606,12 @@ static int acpi_pci_link_allocate(struct acpi_pci_link 
*link)
}
}
if (acpi_irq_get_penalty(irq) >= PIRQ_PENALTY_ISA_ALWAYS) {
+   for (i = (link->irq.possible_count - 1); i >= 0; i--) {
+   pr_info("penalty[%d] = 0x%x\n",
+   link->irq.possible[i],
+   acpi_irq_get_penalty(link->irq.possible[i]));
+   }
+
printk(KERN_ERR PREFIX "No IRQ available for %s [%s]. "
"Try pci=noacpi or acpi=off\n",
acpi_device_name(link->device),
@@ -870,9 +878,12 @@ static int __init acpi_irq_penalty_update(char *str, int 
used)
  */
 void acpi_penalize_isa_irq(int irq, int active)
 {
-   if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
+   if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty))) {
acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
  (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
+   pr_info("%s:%d acpi_isa_irq_penalty[%d]=0x%x active = %d\n", 
__func__,
+   __LINE__, irq,  acpi_irq_get_penalty(irq), 
active);
+   }
 }
 
 bool acpi_isa_irq_available(int irq)
-- 
1.9.1



Re: [PATCH 2/3] kvm: x86: do not use KVM_REQ_EVENT for APICv interrupt injection

2016-09-27 Thread Michael S. Tsirkin
On Tue, Sep 27, 2016 at 11:20:12PM +0200, Paolo Bonzini wrote:
> Since bf9f6ac8d749 ("KVM: Update Posted-Interrupts Descriptor when vCPU
> is blocked", 2015-09-18) the posted interrupt descriptor is checked
> unconditionally for PIR.ON.  Therefore we don't need KVM_REQ_EVENT to
> trigger the scan and, if NMIs or SMIs are not involved, we can avoid
> the complicated event injection path.
> 
> However, there is a race between vmx_deliver_posted_interrupt and
> vcpu_enter_guest.  Fix it by disabling interrupts before vcpu->mode is
> set to IN_GUEST_MODE.

Could you describe the race a bit more please?
I'm surprised that locally disabling irqs
fixes a race with a different CPUs.

> 
> Calling kvm_vcpu_kick if PIR.ON=1 is also useless, though it has been
> there since APICv was introduced.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/kvm/lapic.c | 2 --
>  arch/x86/kvm/vmx.c   | 8 +---
>  arch/x86/kvm/x86.c   | 9 +++--
>  3 files changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 63a442aefc12..be8b7ad56dd1 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -356,8 +356,6 @@ void kvm_apic_update_irr(struct kvm_vcpu *vcpu, u32 *pir)
>   struct kvm_lapic *apic = vcpu->arch.apic;
>  
>   __kvm_apic_update_irr(pir, apic->regs);
> -
> - kvm_make_request(KVM_REQ_EVENT, vcpu);
>  }
>  EXPORT_SYMBOL_GPL(kvm_apic_update_irr);
>  
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index b33eee395b00..207b9aa32915 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -4844,9 +4844,11 @@ static void vmx_deliver_posted_interrupt(struct 
> kvm_vcpu *vcpu, int vector)
>   if (pi_test_and_set_pir(vector, >pi_desc))
>   return;
>  
> - r = pi_test_and_set_on(>pi_desc);
> - kvm_make_request(KVM_REQ_EVENT, vcpu);
> - if (r || !kvm_vcpu_trigger_posted_interrupt(vcpu))

so the logic here was reversed - kick was not called
when PIR=OFF previously. It's a bug but what was it's effect?
I'm guessing - extra latency where VCPU won't get
woken up correctly?

> + /* If a previous notification has sent the IPI, nothing to do.  */
> + if (pi_test_and_set_on(>pi_desc))
> + return;
> +
> + if (!kvm_vcpu_trigger_posted_interrupt(vcpu))
>   kvm_vcpu_kick(vcpu);
>  }
>  
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 3ee8a91a78c3..604cfbfc5bee 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -6658,6 +6658,13 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>   kvm_x86_ops->prepare_guest_switch(vcpu);
>   if (vcpu->fpu_active)
>   kvm_load_guest_fpu(vcpu);
> +
> + /*
> +  * Disable IRQs before setting IN_GUEST_MODE, so that
> +  * posted interrupts with vcpu->mode == IN_GUEST_MODE
> +  * always result in virtual interrupt delivery.
> +  */
> + local_irq_disable();
>   vcpu->mode = IN_GUEST_MODE;
>  
>   srcu_read_unlock(>kvm->srcu, vcpu->srcu_idx);
> @@ -6671,8 +6678,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>*/
>   smp_mb__after_srcu_read_unlock();
>  
> - local_irq_disable();
> -
>   if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
>   || need_resched() || signal_pending(current)) {
>   vcpu->mode = OUTSIDE_GUEST_MODE;
> -- 
> 1.8.3.1
> 


Question on kzalloc and GFP_DMA32

2016-09-27 Thread Ben Greear


I have been running this patch for a while:

ath10k:  Use GPF_DMA32 for firmware swap memory.

This fixes OS crash when using QCA 9984 NIC on x86-64 system
without vt-d enabled.

Also tested on ea8500 with 9980, and x86-64 with 9980 and 9880.

All tests were with CT firmware.

Signed-off-by: Ben Greear 

 drivers/net/wireless/ath/ath10k/wmi.c 
index e20aa39..727b3aa 100644
@@ -4491,7 +4491,7 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32 
req_id,
 if (!pool_size)
 return -EINVAL;

-vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN);
+vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN | GFP_DMA32);
 if (!vaddr)
 num_units /= 2;
 }


It sometimes works, on some systems, but then it also often fails with the splat
below, especially with several NICs in the system.

pool_size is relatively large (maybe 256k or so).

Any idea for a more proper way to do this?


gfp: 4
[ cut here ]
kernel BUG at /home/greearb/git/linux-4.7.dev.y/mm/slub.c:1508!
invalid opcode:  [#1] PREEMPT SMP
Modules linked in: coretemp hwmon ath9k intel_rapl ath10k_pci x86_pkg_temp_thermal ath9k_common ath10k_core intel_powerclamp ath9k_hw ath kvm iTCO_wdt mac80211 
iTCO_vendor_support irqbypass snd_hda_codec_hdmi 6

CPU: 2 PID: 268 Comm: kworker/u8:5 Not tainted 4.7.2+ #16
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 
4.6.5 06/07/2013
Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core]
task: 880036433a00 ti: 88003644 task.ti: 88003644
RIP: 0010:[]  [] new_slab+0x39a/0x410
RSP: 0018:880036443b58  EFLAGS: 00010092
RAX: 0006 RBX: 024082c4 RCX: 
RDX: 0006 RSI: 88021e30dd08 RDI: 88021e30dd08
RBP: 880036443b90 R08:  R09: 
R10:  R11: 0372 R12: 88021dc01200
R13: 88021dc00cc0 R14: 88021dc01200 R15: 0001
FS:  () GS:88021e30() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f3e65c1c730 CR3: 01e06000 CR4: 001406e0
Stack:
 8127a4fc 0a01ff10 024082c4 88021dc01200
 88021dc00cc0 88021dc01200 0001 880036443c58
 81247ac6 88021e31b360 880036433a00 880036433a00
Call Trace:
 [] ? __d_lookup+0x9c/0x160
 [] ___slab_alloc+0x396/0x4a0
 [] ? ath10k_wmi_event_service_ready_work+0x5ad/0x800 
[ath10k_core]
 [] ? alloc_kmem_pages+0x9/0x10
 [] ? kmalloc_order+0x13/0x40
 [] ? ath10k_wmi_event_service_ready_work+0x5ad/0x800 
[ath10k_core]
 [] __slab_alloc.isra.72+0x26/0x40
 [] __kmalloc+0x147/0x1b0
 [] ath10k_wmi_event_service_ready_work+0x5ad/0x800 
[ath10k_core]
 [] ? dequeue_entity+0x261/0xac0
 [] process_one_work+0x148/0x420
 [] worker_thread+0x49/0x480
 [] ? rescuer_thread+0x330/0x330
 [] kthread+0xc4/0xe0
 [] ret_from_fork+0x1f/0x40
 [] ? kthread_create_on_node+0x170/0x170
Code: e9 65 fd ff ff 49 8b 57 20 48 8d 42 ff 83 e2 01 49 0f 44 c7 f0 80 08 40 e9 6f fd ff ff 89 c6 48 c7 c7 01 36 c7 81 e8 e8 40 fa ff <0f> 0b ba 00 10 00 00 be 
5a 00 00 00 48 89 c7 48 d3 e2 e8 bf 18

RIP  [] new_slab+0x39a/0x410
 RSP 
---[ end trace ea3b0043b2911d93 ]---


static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
{
if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
BUG();
}

return allocate_slab(s,
flags & (GFP_RECLAIM_MASK | GFP_CONSTRAINT_MASK), node);
}


Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com



Re: [PATCH trival -resend 1/2] bpf: clean up put_cpu_var usage

2016-09-27 Thread Alexei Starovoitov
On Tue, Sep 27, 2016 at 08:42:41AM -0700, Shaohua Li wrote:
> 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 

Acked-by: Alexei Starovoitov 



Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

2016-09-27 Thread Rafael J. Wysocki
On Wednesday, September 28, 2016 12:23:31 AM Ondrej Zary wrote:
> On Tuesday 27 September 2016 23:32:26 Rafael J. Wysocki wrote:
> > On Tuesday, September 27, 2016 11:02:22 PM Ondrej Zary wrote:
> > > On Monday 26 September 2016 14:23:01 Rafael J. Wysocki wrote:
> > > > On Sunday, September 25, 2016 03:12:05 PM Ondrej Zary wrote:
> > > > > Hello,
> > > > > I've upgraded kernel (Debian Squeeze - backports) from 4.6
> > > > > (4.6.4-1~bpo8+1) to 4.7 (4.7.2-1~bpo8+1) and IRQs stopped working
> > > > > with error messages like this:
> > > > >
> > > > > ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi
> > > > > or acpi=off
> > > > >
> > > > > The same thing appeared on two different machines. Is it a
> > > > > known/fixed bug?
> > > >
> > > > Well, maybe.
> > > >
> > > > Can you try 4.8-rc8, please?
> > >
> > > Just tested 4.8-rc8 on another (3rd) machine with the same problem. The
> > > bug is still present in 4.8-rc8.
> >
> > The problem wasn't known then.
> >
> > > All machines are Pentium 3 PCI/ISA systems.
> >
> > This probably is related to the way the ISA IRQs are handled.
> >
> > Here's a list of commits to revert, in this order:
> >
> > f7eca374f000 ACPI,PCI,IRQ: separate ISA penalty calculation
> > 487cf917ed0d Revert "ACPI, PCI, IRQ: remove redundant code in
> > acpi_irq_penalty_init()" 4a6e68bf96c1 ACPI,PCI,IRQ: factor in PCI possible
> > 54794580f594 ACPI,PCI,IRQ: correct operator precedence
> > 9e5ed6d1fb87 ACPI,PCI,IRQ: remove SCI penalize function
> > 1fcb6a813c4f ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()
> > 5c5087a55390 ACPI,PCI,IRQ: reduce static IRQ array size to 16
> > 103544d86976 ACPI,PCI,IRQ: reduce resource requirements
> >
> > Please try to revert the first 5 first and see if that helps.
> 
> Bisected it to this:
> 
> 103544d86976338057d6a91f721b49d3acc7df7f is the first bad commit
> commit 103544d86976338057d6a91f721b49d3acc7df7f
> Author: Sinan Kaya 
> Date:   Sun Apr 17 13:36:53 2016 -0400
> 
> ACPI,PCI,IRQ: reduce resource requirements
> 
> Code has been redesigned to calculate penalty requirements on the fly. 
> This
> significantly simplifies the implementation and removes some of the init
> calls from x86 architecture.
> 
> Signed-off-by: Sinan Kaya 
> Acked-by: Bjorn Helgaas 
> Signed-off-by: Rafael J. Wysocki 
> 
> :04 04 9bf16c388d23bb66e087809f069eafed18e46a8c 
> bcac95fb33ee834aec7d23eab9eb0dc5e330c68c M  drivers

OK

Sinan, can you help, please?


> > > [0.00] Linux version 4.8.0-rc8+ (zary@gsql) (gcc version 4.7.2
> > > (Debian 4.7.2-5) ) #84 SMP Tue Sep 27 22:37:05 CEST 2016 [0.00]
> > > x86/fpu: Legacy x87 FPU detected.
> > > [0.00] x86/fpu: Using 'eager' FPU context switches.
> > > [0.00] e820: BIOS-provided physical RAM map:
> > > [0.00] BIOS-e820: [mem 0x-0x0009fbff]
> > > usable [0.00] BIOS-e820: [mem
> > > 0x0009fc00-0x0009] reserved [0.00] BIOS-e820:
> > > [mem 0x000f-0x000f] reserved [0.00]
> > > BIOS-e820: [mem 0x0010-0x1ffe] usable [   
> > > 0.00] BIOS-e820: [mem 0x1fff-0x1fff2fff] ACPI NVS
> > > [0.00] BIOS-e820: [mem 0x1fff3000-0x1fff]
> > > ACPI data [0.00] BIOS-e820: [mem
> > > 0x-0x] reserved [0.00] Notice: NX
> > > (Execute Disable) protection missing in CPU! [0.00] SMBIOS 2.2
> > > present.
> > > [0.00] DMI: VIA Technologies, Inc. VT82C694X/694X, BIOS 6.00 PG
> > > 02/19/2002 [0.00] e820: update [mem 0x-0x0fff] usable
> > > ==> reserved [0.00] e820: remove [mem 0x000a-0x000f]
> > > usable
> > > [0.00] e820: last_pfn = 0x1fff0 max_arch_pfn = 0x10
> > > [0.00] MTRR default type: uncachable
> > > [0.00] MTRR fixed ranges enabled:
> > > [0.00]   0-9 write-back
> > > [0.00]   A-A uncachable
> > > [0.00]   B-B write-combining
> > > [0.00]   C-C9FFF write-protect
> > > [0.00]   CA000-E uncachable
> > > [0.00]   F-F7FFF write-through
> > > [0.00]   F8000-F8FFF uncachable
> > > [0.00]   F9000-F write-through
> > > [0.00] MTRR variable ranges enabled:
> > > [0.00]   0 base 0 mask FE000 write-back
> > > [0.00]   1 base 0E000 mask FFC00 write-combining
> > > [0.00]   2 disabled
> > > [0.00]   3 disabled
> > > [0.00]   4 disabled
> > > [0.00]   5 disabled
> > > [0.00]   6 disabled
> > > [0.00]   7 disabled
> > > [0.00] x86/PAT: PAT not supported by CPU.
> > > [0.00] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC-
> > > UC [0.00] initial 

Re: [PATCH v5 0/5] Introduce current_time() api

2016-09-27 Thread Al Viro
On Wed, Sep 14, 2016 at 09:45:55AM -0700, Linus Torvalds wrote:
> On Wed, Sep 14, 2016 at 7:48 AM, Deepa Dinamani  
> wrote:
> > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC 
> > macros.
> > The macros are not y2038 safe. There is no plan to transition them into 
> > being
> > y2038 safe.
> 
> This version looks ok to me.
> 
> Al, would you be willing to queue this up for 4.9?

Applied.


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

2016-09-27 Thread subhashj

Looks good to me.
Reviewed-by: Subhash Jadavani 

On 2016-08-25 02:39, Zang Leigang wrote:
Some device may cause a compatibility issue while receiving a Query 
UPIU

with Data Segment which does not expected.

Signed-off-by: Zang Leigang 
---
 drivers/scsi/ufs/ufshcd.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f08d41a..9b21d88 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1266,9 +1266,12 @@ static void
ufshcd_prepare_utp_query_req_upiu(struct ufs_hba *hba,
ucd_req_ptr->header.dword_1 = UPIU_HEADER_DWORD(
0, query->request.query_func, 0, 0);

-   /* 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;

/* Copy the Query Request buffer as is */
memcpy(_req_ptr->qr, >request.upiu_req,


[PATCH v2] mlx5: Add ndo_poll_controller() implementation

2016-09-27 Thread Calvin Owens
This implements ndo_poll_controller in net_device_ops callback for mlx5,
which is necessary to use netconsole with this driver.

Cc: Saeed Mahameed 
Signed-off-by: Calvin Owens 
---
Changes in v2:
* Only iterate channels to avoid redundant napi_schedule() calls

drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 2459c7f..830b8d0 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -2786,6 +2786,20 @@ static void mlx5e_tx_timeout(struct net_device *dev)
schedule_work(>tx_timeout_work);
 }
 
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/* Fake "interrupt" called by netpoll (eg netconsole) to send skbs without
+ * reenabling interrupts.
+ */
+static void mlx5e_netpoll(struct net_device *dev)
+{
+   struct mlx5e_priv *priv = netdev_priv(dev);
+   int i;
+
+   for (i = 0; i < priv->params.num_channels; i++)
+   napi_schedule(>channel[i]->napi);
+}
+#endif
+
 static const struct net_device_ops mlx5e_netdev_ops_basic = {
.ndo_open= mlx5e_open,
.ndo_stop= mlx5e_close,
@@ -2805,6 +2819,9 @@ static const struct net_device_ops mlx5e_netdev_ops_basic 
= {
.ndo_rx_flow_steer   = mlx5e_rx_flow_steer,
 #endif
.ndo_tx_timeout  = mlx5e_tx_timeout,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+   .ndo_poll_controller = mlx5e_netpoll,
+#endif
 };
 
 static const struct net_device_ops mlx5e_netdev_ops_sriov = {
@@ -2836,6 +2853,9 @@ static const struct net_device_ops mlx5e_netdev_ops_sriov 
= {
.ndo_set_vf_link_state   = mlx5e_set_vf_link_state,
.ndo_get_vf_stats= mlx5e_get_vf_stats,
.ndo_tx_timeout  = mlx5e_tx_timeout,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+   .ndo_poll_controller = mlx5e_netpoll,
+#endif
 };
 
 static int mlx5e_check_required_hca_cap(struct mlx5_core_dev *mdev)
-- 
2.9.3



Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

2016-09-27 Thread Ondrej Zary
On Tuesday 27 September 2016 23:32:26 Rafael J. Wysocki wrote:
> On Tuesday, September 27, 2016 11:02:22 PM Ondrej Zary wrote:
> > On Monday 26 September 2016 14:23:01 Rafael J. Wysocki wrote:
> > > On Sunday, September 25, 2016 03:12:05 PM Ondrej Zary wrote:
> > > > Hello,
> > > > I've upgraded kernel (Debian Squeeze - backports) from 4.6
> > > > (4.6.4-1~bpo8+1) to 4.7 (4.7.2-1~bpo8+1) and IRQs stopped working
> > > > with error messages like this:
> > > >
> > > > ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi
> > > > or acpi=off
> > > >
> > > > The same thing appeared on two different machines. Is it a
> > > > known/fixed bug?
> > >
> > > Well, maybe.
> > >
> > > Can you try 4.8-rc8, please?
> >
> > Just tested 4.8-rc8 on another (3rd) machine with the same problem. The
> > bug is still present in 4.8-rc8.
>
> The problem wasn't known then.
>
> > All machines are Pentium 3 PCI/ISA systems.
>
> This probably is related to the way the ISA IRQs are handled.
>
> Here's a list of commits to revert, in this order:
>
> f7eca374f000 ACPI,PCI,IRQ: separate ISA penalty calculation
> 487cf917ed0d Revert "ACPI, PCI, IRQ: remove redundant code in
> acpi_irq_penalty_init()" 4a6e68bf96c1 ACPI,PCI,IRQ: factor in PCI possible
> 54794580f594 ACPI,PCI,IRQ: correct operator precedence
> 9e5ed6d1fb87 ACPI,PCI,IRQ: remove SCI penalize function
> 1fcb6a813c4f ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()
> 5c5087a55390 ACPI,PCI,IRQ: reduce static IRQ array size to 16
> 103544d86976 ACPI,PCI,IRQ: reduce resource requirements
>
> Please try to revert the first 5 first and see if that helps.

Bisected it to this:

103544d86976338057d6a91f721b49d3acc7df7f is the first bad commit
commit 103544d86976338057d6a91f721b49d3acc7df7f
Author: Sinan Kaya 
Date:   Sun Apr 17 13:36:53 2016 -0400

ACPI,PCI,IRQ: reduce resource requirements

Code has been redesigned to calculate penalty requirements on the fly. This
significantly simplifies the implementation and removes some of the init
calls from x86 architecture.

Signed-off-by: Sinan Kaya 
Acked-by: Bjorn Helgaas 
Signed-off-by: Rafael J. Wysocki 

:04 04 9bf16c388d23bb66e087809f069eafed18e46a8c 
bcac95fb33ee834aec7d23eab9eb0dc5e330c68c M  drivers




> > [0.00] Linux version 4.8.0-rc8+ (zary@gsql) (gcc version 4.7.2
> > (Debian 4.7.2-5) ) #84 SMP Tue Sep 27 22:37:05 CEST 2016 [0.00]
> > x86/fpu: Legacy x87 FPU detected.
> > [0.00] x86/fpu: Using 'eager' FPU context switches.
> > [0.00] e820: BIOS-provided physical RAM map:
> > [0.00] BIOS-e820: [mem 0x-0x0009fbff]
> > usable [0.00] BIOS-e820: [mem
> > 0x0009fc00-0x0009] reserved [0.00] BIOS-e820:
> > [mem 0x000f-0x000f] reserved [0.00]
> > BIOS-e820: [mem 0x0010-0x1ffe] usable [   
> > 0.00] BIOS-e820: [mem 0x1fff-0x1fff2fff] ACPI NVS
> > [0.00] BIOS-e820: [mem 0x1fff3000-0x1fff]
> > ACPI data [0.00] BIOS-e820: [mem
> > 0x-0x] reserved [0.00] Notice: NX
> > (Execute Disable) protection missing in CPU! [0.00] SMBIOS 2.2
> > present.
> > [0.00] DMI: VIA Technologies, Inc. VT82C694X/694X, BIOS 6.00 PG
> > 02/19/2002 [0.00] e820: update [mem 0x-0x0fff] usable
> > ==> reserved [0.00] e820: remove [mem 0x000a-0x000f]
> > usable
> > [0.00] e820: last_pfn = 0x1fff0 max_arch_pfn = 0x10
> > [0.00] MTRR default type: uncachable
> > [0.00] MTRR fixed ranges enabled:
> > [0.00]   0-9 write-back
> > [0.00]   A-A uncachable
> > [0.00]   B-B write-combining
> > [0.00]   C-C9FFF write-protect
> > [0.00]   CA000-E uncachable
> > [0.00]   F-F7FFF write-through
> > [0.00]   F8000-F8FFF uncachable
> > [0.00]   F9000-F write-through
> > [0.00] MTRR variable ranges enabled:
> > [0.00]   0 base 0 mask FE000 write-back
> > [0.00]   1 base 0E000 mask FFC00 write-combining
> > [0.00]   2 disabled
> > [0.00]   3 disabled
> > [0.00]   4 disabled
> > [0.00]   5 disabled
> > [0.00]   6 disabled
> > [0.00]   7 disabled
> > [0.00] x86/PAT: PAT not supported by CPU.
> > [0.00] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC-
> > UC [0.00] initial memory mapped: [mem 0x-0x01bf] [   
> > 0.00] Base memory trampoline at [c009b000] 9b000 size 16384 [   
> > 0.00] BRK [0x016b1000, 0x016b1fff] PGTABLE
> > [0.00] ACPI: Early table checksum verification disabled
> > [0.00] ACPI: RSDP 0x000F6C00 14 (v00 

Re: [PATCH] spmi: pmic-arb: Return an error code if sanity check fails

2016-09-27 Thread Stephen Boyd
On 09/26, Christophe JAILLET wrote:
> If the test 'if (channel > 5)' is true, then we will return 'err' which
> is known to be 0 at this point.
> Return -EINVAL instead.
> 
> Signed-off-by: Christophe JAILLET 
> ---

Reviewed-by: Stephen Boyd 

Looks right, thanks.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: [PATCH v3 09/11] dax: add struct iomap based DAX PMD support

2016-09-27 Thread Dave Chinner
On Tue, Sep 27, 2016 at 02:48:00PM -0600, Ross Zwisler wrote:
> DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
> locking.  This patch allows DAX PMDs to participate in the DAX radix tree
> based locking scheme so that they can be re-enabled using the new struct
> iomap based fault handlers.
> 
> There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
> mappings that have an associated block allocation, and 4k DAX empty
> entries.  The empty entries exist to provide locking for the duration of a
> given page fault.
> 
> This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
> entries, PMD DAX entries that have associated block allocations, and 2 MiB
> DAX empty entries.
> 
> Unlike the 4k case where we insert a struct page* into the radix tree for
> 4k zero pages, for HZP we insert a DAX exceptional entry with the new
> RADIX_DAX_HZP flag set.  This is because we use a single 2 MiB zero page in
> every 2MiB hole mapping, and it doesn't make sense to have that same struct
> page* with multiple entries in multiple trees.  This would cause contention
> on the single page lock for the one Huge Zero Page, and it would break the
> page->index and page->mapping associations that are assumed to be valid in
> many other places in the kernel.
> 
> One difficult use case is when one thread is trying to use 4k entries in
> radix tree for a given offset, and another thread is using 2 MiB entries
> for that same offset.  The current code handles this by making the 2 MiB
> user fall back to 4k entries for most cases.  This was done because it is
> the simplest solution, and because the use of 2MiB pages is already
> opportunistic.
> 
> If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
> we run into the problem of how we lock out 4k page faults for the entire
> 2MiB range while we clean out the radix tree so we can insert the 2MiB
> entry.  We can solve this problem if we need to, but I think that the cases
> where both 2MiB entries and 4K entries are being used for the same range
> will be rare enough and the gain small enough that it probably won't be
> worth the complexity.
> 
> Signed-off-by: Ross Zwisler 

> +#if defined(CONFIG_TRANSPARENT_HUGEPAGE)
> +/*
> + * The 'colour' (ie low bits) within a PMD of a page offset.  This comes up
> + * more often than one might expect in the below functions.
> + */
> +#define PG_PMD_COLOUR((PMD_SIZE >> PAGE_SHIFT) - 1)
> +
> +static void __dax_pmd_dbg(struct iomap *iomap, unsigned long address,
> + const char *reason, const char *fn)
> +{
> + if (iomap) {
> + char bname[BDEVNAME_SIZE];
> +
> + bdevname(iomap->bdev, bname);
> + pr_debug("%s: %s addr %lx dev %s type %#x blkno %ld "
> + "offset %lld length %lld fallback: %s\n", fn,
> + current->comm, address, bname, iomap->type,
> + iomap->blkno, iomap->offset, iomap->length, reason);
> + } else {
> + pr_debug("%s: %s addr: %lx fallback: %s\n", fn,
> + current->comm, address, reason);
> + }
> +}

Yuck! Tracepoints for debugging information like this, please, not
printk awfulness.

> +
> +#define dax_pmd_dbg(bh, address, reason) \
> + __dax_pmd_dbg(bh, address, reason, __func__)
> +
> +static int iomap_pmd_insert_mapping(struct vm_area_struct *vma, pmd_t *pmd,
> + struct vm_fault *vmf, unsigned long address,
> + struct iomap *iomap, loff_t pos, bool write, void **entryp)

Please put a "dax" in the function name. grepping, cscope, etc are
much easier when static function names are namespaced properly.

> +{
> + struct address_space *mapping = vma->vm_file->f_mapping;
> + struct block_device *bdev = iomap->bdev;
> + struct blk_dax_ctl dax = {
> + .sector = iomap_dax_sector(iomap, pos),
> + .size = PMD_SIZE,
> + };
> + long length = dax_map_atomic(bdev, );
> + void *ret;
> +
> + if (length < 0) {
> + dax_pmd_dbg(iomap, address, "dax-error fallback");
> + return VM_FAULT_FALLBACK;
> + }

Fails to unmap. Please use an goto based error stack. And
tracepoints make this much neater:

trace_dax_pmd_insert_mapping(iomap, address, , length);
if (length < 0)
goto unmap_fallback;
if (length < PMD_SIZE)
goto unmap_fallback;
.

trace_dax_pmd_insert_mapping_done(iomap, address, , length);
return vmf_insert_pfn_pmd(vma, address, pmd, dax.pfn, write);

unmap_fallback:
dax_unmap_atomic(bdev, );
fallback:
trace_dax_pmd_insert_fallback(iomap, address, , length);
return VM_FAULT_FALLBACK;
}

i.e. we don't need need all those debug printks to tell us what
failed - the first tracepoint tells use everything about the context
we are about to check, and the last tracepoint 

Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver

2016-09-27 Thread Rich Felker
On Mon, Sep 26, 2016 at 08:42:58PM -0400, Rich Felker wrote:
> On Mon, Sep 26, 2016 at 07:55:13PM -0400, Thomas Gleixner wrote:
> > On Mon, 26 Sep 2016, Rich Felker wrote:
> > > On Mon, Sep 26, 2016 at 11:27:14PM +0200, Daniel Lezcano wrote:
> > > Based on use of ftrace, I was able to see situations where a second
> > > timer hardirq happened immediately after one occurred, before the
> > > timer softirq could run. My theory is that this is causing some kind
> > > of feedback loop where new timer expirations keep getting scheduled
> > > with a very short interval such that the softirq never gets to run
> > > (until other interrupt activity disrups the feedback loop). I tried
> > > reverting 4e85876a9d2a977b4a07389da8c07edf76d10825 which seemed
> > > relevant and it didn't help, but on further review (right now) there
> > > seem to be a few related commits just before it that might be
> > > responsible for the regression. I'll see if I can dig up anything else
> > > useful.
> > 
> > Interesting theory, but lets look at the data from the other thread:
> > 
> >  -0 [001] d.h.  2646.702790: irq_handler_entry: irq=72 
> > name=jcore_pit
> >   -0 [001] d.h.  2646.703398: softirq_raise: vec=1 
> > [action=TIMER]
> >   -0 [001] d.h.  2646.703607: softirq_raise: vec=9 
> > [action=RCU]
> >   -0 [001] d.h.  2646.703884: softirq_raise: vec=7 
> > [action=SCHED]
> >   -0 [001] d.h.  2646.704191: irq_handler_exit: irq=72 
> > ret=handled
> > 
> > So it takes 1.4ms to finish the timer irq handler
> > 
> >   -0 [001] d.H.  2646.704509: irq_handler_entry: irq=72 
> > name=jcore_pit
> >   -0 [001] d.H.  2646.704990: softirq_raise: vec=1 
> > [action=TIMER]
> >   -0 [001] d.H.  2646.705182: softirq_raise: vec=9 
> > [action=RCU]
> >   -0 [001] d.H.  2646.705465: softirq_raise: vec=7 
> > [action=SCHED]
> >   -0 [001] d.H.  2646.705761: irq_handler_exit: irq=72 
> > ret=handled
> > 
> > And 1.2ms in this case
> >   
> > 
> >   -0 [001] d.H.  2646.706071: irq_handler_entry: irq=72 
> > name=jcore_pit
> >   -0 [001] d.H.  2646.706328: irq_handler_exit: irq=72 
> > ret=handled
> > 
> > So this one is actually short enough that the soft interrupt can excute and
> > obviously no new timer is scheduled close enough.
> > 
> >   -0 [001] ..s.  2646.706530: softirq_entry: vec=1 
> > [action=TIMER]
> > 
> > Now the obvious question arises: Why is that handler taking that long? And
> 
> I'm not sure. Even at our clock rate of 50 MHz, 1.2ms is 6 cycles.
> It's possible much of that overhead is coming from ftrace. I can play
> around again with just logging the minimum intervals that are
> programmed, and not using ftrace.
> 
> > sure the next event being programmed shortely after the other has to do
> > with various factors (HZ setting, High-resolution timers enabled?). W/o
> > having the corresponding hrtimer tracepoints available (start and expire)
> > it's hard to tell what's going on.
> 
> I do have hrtimers enabled. If it would be helpful I could try again
> with traces for them enabled too.
> 
> > But I can tell for sure that there is no feedback loop and its not
> > disrupted by some other interrupt.
> 
> FYI no rcu_sched messages or noticable stalls were observed with
> tracing active. The cpu load from tracing is so high that I would not
> expect to see the same behavior. I probably failed to make that clear
> before; sorry.

I've managed to get a trace with a stall. I'm not sure what the best
way to share the full thing is, since it's large, but here are the
potentially interesting parts.

The first is a big time gap with no events, from 82.446093 to
109.852709:

  -0 [001] .ns.82.431940: timer_expire_exit: 
timer=160a9eb0
  -0 [001] .ns.82.432088: softirq_exit: vec=1 
[action=TIMER]
  -0 [001] .ns.82.432180: softirq_entry: vec=7 
[action=SCHED]
  -0 [001] .ns.82.432380: softirq_exit: vec=7 
[action=SCHED]
 ksoftirqd/1-14[001] ..s.82.433042: softirq_entry: vec=1 
[action=TIMER]
 ksoftirqd/1-14[001] ..s.82.433166: softirq_exit: vec=1 
[action=TIMER]
 ksoftirqd/1-14[001] ..s.82.433258: softirq_entry: vec=7 
[action=SCHED]
 ksoftirqd/1-14[001] ..s.82.433428: softirq_exit: vec=7 
[action=SCHED]
   rcu_sched-7 [001] 82.434269: timer_init: timer=160a9eb0
   rcu_sched-7 [001] d...82.434410: timer_start: timer=160a9eb0 
function=process_timeout expires=4294945532 [timeout=1] flags=0x0001
 cat-394   [000] d.h.82.437621: irq_handler_entry: irq=16 
name=jcore_pit
 cat-394   [000] d.h.82.437851: hrtimer_cancel: hrtimer=109e949c
 cat-394   [000] d.h.82.438006: hrtimer_expire_entry: 
hrtimer=109e949c function=tick_sched_timer now=82350361520
 cat-394   [000] d.h.82.438555: 

Re: [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs

2016-09-27 Thread Stephen Boyd
On 09/26, Heiko Stuebner wrote:
> Am Montag, 26. September 2016, 09:25:11 CEST schrieb Viresh Kumar:
> > On 12-09-16, 14:55, Stephen Boyd wrote:
> > > On 08/29, Viresh Kumar wrote:
> > > > On 18-08-16, 16:52, Finlye Xiao wrote:
> > > > > +static int rockchip_adjust_opp_table(struct device *cpu_dev,
> > > > > +  struct cpufreq_frequency_table 
> > > > > *table,
> > > > > +  int volt)
> > > > > +{
> > > > > + struct opp_table *opp_table;
> > > > > + struct cpufreq_frequency_table *pos;
> > > > > + struct dev_pm_opp *opp;
> > > > > +
> > > > > + if (!volt)
> > > > > + return 0;
> > > > > +
> > > > > + rcu_read_lock();
> > > > > +
> > > > > + opp_table = _find_opp_table(cpu_dev);
> > > > > + if (IS_ERR(opp_table)) {
> > > > > + rcu_read_unlock();
> > > > > + return PTR_ERR(opp_table);
> > > > > + }
> > > > > +
> > > > > + cpufreq_for_each_valid_entry(pos, table) {
> > > > > + opp = dev_pm_opp_find_freq_exact(cpu_dev, 
> > > > > pos->frequency * 1000,
> > > > > +  true);
> > > > > + if (IS_ERR(opp))
> > > > > + continue;
> > > > > +
> > > > > + opp->u_volt += volt;
> > > > > + opp->u_volt_min += volt;
> > > > > + opp->u_volt_max += volt;
> > > > > + }
> > > > > +
> > > > > + rcu_read_unlock();
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > 
> > > > I wouldn't prefer altering the opp tables from individual drivers at
> > > > all. At the least, it should be done via some helpers exposed by the
> > > > core.
> > > > 
> > > > But before that I would like to hear from Stephen a bit as I recall he
> > > > was also working on something similar.
> > > 
> > > I had a patch to modify the voltage at runtime for the "current"
> > > OPP. Now that we have regulator and clk control inside OPP that
> > > became a little easier to do without having to do some notifier
> > > from the OPP layer to the consumers. I haven't had time to revive
> > > those patches though. Should we do that?
> > 
> > Perhaps yes, we should have a common place for doing all that.
> > 
> > > Does this need to modify
> > > anything besides the OPP the device is currently running at?
> > 
> > Finlye, can you please answer this ?
> 
> If I understand it correctly, depending on the leakage value stored in an 
> efuse, all opp voltages are reduced by a certain value. Right now the driver 
> does it in one go for the full opp table, but of course could also do it for 
> each new opp individually before it gets set.

Ok. Well either way that sounds fine. We could expose an API to
change each voltage and an API to change the current voltage and
update the table.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: [PATCH v2 2/4] mfd: lpc_ich: Do not create iTCO watchdog when WDAT table exists

2016-09-27 Thread Rafael J. Wysocki
On Tuesday, September 27, 2016 08:41:14 PM Lee Jones wrote:
> On Tue, 20 Sep 2016, Mika Westerberg wrote:
> 
> > ACPI WDAT table is the preferred way to use hardware watchdog over the
> > native iTCO_wdt. Windows only uses this table for its hardware watchdog
> > implementation so we should be relatively safe to trust it has been
> > validated by OEMs
> > 
> > Prevent iTCO watchdog creation if we detect that there is ACPI WDAT table.
> > 
> > Signed-off-by: Mika Westerberg 
> > Reviewed-by: Guenter Roeck 
> > ---
> >  drivers/mfd/lpc_ich.c | 4 
> >  1 file changed, 4 insertions(+)
> 
> Applied, thanks.

Well, I applied this too.

And it depends on the [1/4], doesn't it?

> 
> > diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
> > index bd3aa4578346..c8dee47b45d9 100644
> > --- a/drivers/mfd/lpc_ich.c
> > +++ b/drivers/mfd/lpc_ich.c
> > @@ -984,6 +984,10 @@ static int lpc_ich_init_wdt(struct pci_dev *dev)
> > int ret;
> > struct resource *res;
> >  
> > +   /* If we have ACPI based watchdog use that instead */
> > +   if (acpi_has_watchdog())
> > +   return -ENODEV;
> > +
> > /* Setup power management base register */
> > pci_read_config_dword(dev, priv->abase, _addr_cfg);
> > base_addr = base_addr_cfg & 0xff80;
> 
> 

Thanks,
Rafael



[RFC v2 0/4] Add support for led triggers on phy link state change

2016-09-27 Thread Zach Brown
Fix two net drivers that declared enum constants that conflict with enum
constants in linux/leds.h

Create function that encapsulates actions taken during the adjust phy link step
of phy state changes.

Add support for led triggers on phy link state changes by adding
a config option. When set the config option will create a set of led triggers
for each phy device. Users can use the led triggers to represent link state
changes on the phy.

v2:
 * New patch that creates phy_adjust_link function to encapsulate actions taken
   when adjusting phy link during phy state changes
 * led trigger speed strings changed to match existing phy speed strings
 * New function that maps speeds to led triggers
 * Replace magic constants with definitions when declaring trigger name buffer
   and number of triggers.

Josh Cartwright (1):
  phy,leds: add support for led triggers on phy link state change

Zach Brown (3):
  skge: Change LED_OFF to LED_REG_OFF in marvel skge driver to avoid
conflicts with leds namespace
  staging: rtl8712: Change _LED_STATE enum in rtl871x driver to avoid
conflicts with LED namespace
  phy: Encapsulate actions performed during link state changes into
function phy_adjust_link

 drivers/net/ethernet/marvell/skge.c   |   4 +-
 drivers/net/ethernet/marvell/skge.h   |   2 +-
 drivers/net/phy/Kconfig   |  13 +-
 drivers/net/phy/Makefile  |   1 +
 drivers/net/phy/phy.c |  22 +-
 drivers/net/phy/phy_device.c  |   4 +
 drivers/net/phy/phy_led_triggers.c| 121 +++
 drivers/staging/rtl8712/rtl8712_led.c | 388 +-
 include/linux/phy.h   |   9 +
 include/linux/phy_led_triggers.h  |  52 +
 10 files changed, 410 insertions(+), 206 deletions(-)
 create mode 100644 drivers/net/phy/phy_led_triggers.c
 create mode 100644 include/linux/phy_led_triggers.h

--
2.7.4



[RFC v2 1/4] skge: Change LED_OFF to LED_REG_OFF in marvel skge driver to avoid conflicts with leds namespace

2016-09-27 Thread Zach Brown
Adding led support for phy causes namespace conflicts for some
phy drivers.

The marvel skge driver declared an enum for representing the states of
Link LED Register. The enum contained constant LED_OFF which conflicted
with declartation found in linux/leds.h.
LED_OFF changed to LED_REG_OFF

Signed-off-by: Zach Brown 
---
 drivers/net/ethernet/marvell/skge.c | 4 ++--
 drivers/net/ethernet/marvell/skge.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/skge.c 
b/drivers/net/ethernet/marvell/skge.c
index 7173836..ff5a087 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -1062,7 +1062,7 @@ static void skge_link_up(struct skge_port *skge)
 
 static void skge_link_down(struct skge_port *skge)
 {
-   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_OFF);
+   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_REG_OFF);
netif_carrier_off(skge->netdev);
netif_stop_queue(skge->netdev);
 
@@ -2668,7 +2668,7 @@ static int skge_down(struct net_device *dev)
if (hw->ports == 1)
free_irq(hw->pdev->irq, hw);
 
-   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_OFF);
+   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_REG_OFF);
if (is_genesis(hw))
genesis_stop(skge);
else
diff --git a/drivers/net/ethernet/marvell/skge.h 
b/drivers/net/ethernet/marvell/skge.h
index a2eb341..ec054d3 100644
--- a/drivers/net/ethernet/marvell/skge.h
+++ b/drivers/net/ethernet/marvell/skge.h
@@ -663,7 +663,7 @@ enum {
LED_SYNC_ON = 1<<3, /* Use Sync Wire to switch LED */
LED_SYNC_OFF= 1<<2, /* Disable Sync Wire Input */
LED_ON  = 1<<1, /* switch LED on */
-   LED_OFF = 1<<0, /* switch LED off */
+   LED_REG_OFF = 1<<0, /* switch LED off */
 };
 
 /* Receive GMAC FIFO (YUKON) */
-- 
2.7.4



[RFC v2 3/4] phy: Encapsulate actions performed during link state changes into function phy_adjust_link

2016-09-27 Thread Zach Brown
During phy state machine state transitions some set of actions should
occur whenever the link state changes. These actions should be
encapsulated into a single function.

This patch adds the phy_adjust_link function, which is called whenever
phydev->adjust_link would have been called before. Actions that should
occur whenever the phy link is adjusted can now be added to the
phy_adjust_link function.

Signed-off-by: Zach Brown 
---
 drivers/net/phy/phy.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c6f6683..f5721db 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -893,6 +893,11 @@ void phy_start(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(phy_start);
 
+static void phy_adjust_link(struct phy_device *phydev)
+{
+   phydev->adjust_link(phydev->attached_dev);
+}
+
 /**
  * phy_state_machine - Handle the state machine
  * @work: work_struct that describes the work to be done
@@ -935,7 +940,7 @@ void phy_state_machine(struct work_struct *work)
if (!phydev->link) {
phydev->state = PHY_NOLINK;
netif_carrier_off(phydev->attached_dev);
-   phydev->adjust_link(phydev->attached_dev);
+   phy_adjust_link(phydev);
break;
}
 
@@ -948,7 +953,7 @@ void phy_state_machine(struct work_struct *work)
if (err > 0) {
phydev->state = PHY_RUNNING;
netif_carrier_on(phydev->attached_dev);
-   phydev->adjust_link(phydev->attached_dev);
+   phy_adjust_link(phydev);
 
} else if (0 == phydev->link_timeout--)
needs_aneg = true;
@@ -975,7 +980,7 @@ void phy_state_machine(struct work_struct *work)
}
phydev->state = PHY_RUNNING;
netif_carrier_on(phydev->attached_dev);
-   phydev->adjust_link(phydev->attached_dev);
+   phy_adjust_link(phydev);
}
break;
case PHY_FORCING:
@@ -991,7 +996,7 @@ void phy_state_machine(struct work_struct *work)
needs_aneg = true;
}
 
-   phydev->adjust_link(phydev->attached_dev);
+   phy_adjust_link(phydev);
break;
case PHY_RUNNING:
/* Only register a CHANGE if we are polling and link changed
@@ -1020,7 +1025,7 @@ void phy_state_machine(struct work_struct *work)
netif_carrier_off(phydev->attached_dev);
}
 
-   phydev->adjust_link(phydev->attached_dev);
+   phy_adjust_link(phydev);
 
if (phy_interrupt_is_valid(phydev))
err = phy_config_interrupt(phydev,
@@ -1030,7 +1035,7 @@ void phy_state_machine(struct work_struct *work)
if (phydev->link) {
phydev->link = 0;
netif_carrier_off(phydev->attached_dev);
-   phydev->adjust_link(phydev->attached_dev);
+   phy_adjust_link(phydev);
do_suspend = true;
}
break;
@@ -1054,7 +1059,7 @@ void phy_state_machine(struct work_struct *work)
} else  {
phydev->state = PHY_NOLINK;
}
-   phydev->adjust_link(phydev->attached_dev);
+   phy_adjust_link(phydev);
} else {
phydev->state = PHY_AN;
phydev->link_timeout = PHY_AN_TIMEOUT;
@@ -1070,7 +1075,7 @@ void phy_state_machine(struct work_struct *work)
} else  {
phydev->state = PHY_NOLINK;
}
-   phydev->adjust_link(phydev->attached_dev);
+   phy_adjust_link(phydev);
}
break;
}
-- 
2.7.4



[RFC v2 4/4] phy,leds: add support for led triggers on phy link state change

2016-09-27 Thread Zach Brown
From: Josh Cartwright 

Create an option CONFIG_LED_TRIGGER_PHY (default n), which will
create a set of led triggers for each instantiated PHY device.  There is
one LED trigger per link-speed, per-phy.

This allows for a user to configure their system to allow a set of LEDs
to represent link state changes on the phy.

Signed-off-by: Josh Cartwright 
Signed-off-by: Nathan Sullivan 
Signed-off-by: Zach Brown 
---
 drivers/net/phy/Kconfig|  13 +++-
 drivers/net/phy/Makefile   |   1 +
 drivers/net/phy/phy.c  |   1 +
 drivers/net/phy/phy_device.c   |   4 ++
 drivers/net/phy/phy_led_triggers.c | 121 +
 include/linux/phy.h|   9 +++
 include/linux/phy_led_triggers.h   |  52 
 7 files changed, 200 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/phy/phy_led_triggers.c
 create mode 100644 include/linux/phy_led_triggers.h

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 1c3e07c..f233625 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -25,6 +25,18 @@ config MDIO_BCM_IPROC
  This module provides a driver for the MDIO busses found in the
  Broadcom iProc SoC's.
 
+config LED_TRIGGER_PHY
+   bool "Support LED triggers for tracking link state"
+   depends on LEDS_TRIGGERS
+   ---help---
+ Adds support for a set of LED trigger events per-PHY.  Link
+ state change will trigger the events, for consumption by an
+ LED class driver.  There are triggers for each link speed,
+ and are of the form:
+  ::
+
+ Where speed is one of: 10Mbps, 100Mbps, 1Gbps, 2.5Gbps, or 10Gbps.
+
 config MDIO_BCM_UNIMAC
tristate "Broadcom UniMAC MDIO bus controller"
depends on HAS_IOMEM
@@ -40,7 +52,6 @@ config MDIO_BITBANG
  This module implements the MDIO bus protocol in software,
  for use by low level drivers that export the ability to
  drive the relevant pins.
-
  If in doubt, say N.
 
 config MDIO_BUS_MUX
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e58667d..86d12cd 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -2,6 +2,7 @@
 
 libphy-y   := phy.o phy_device.o mdio_bus.o mdio_device.o
 libphy-$(CONFIG_SWPHY) += swphy.o
+libphy-$(CONFIG_LED_TRIGGER_PHY)   += phy_led_triggers.o
 
 obj-$(CONFIG_PHYLIB)   += libphy.o
 
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index f5721db..e5f9fee7 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -896,6 +896,7 @@ EXPORT_SYMBOL(phy_start);
 static void phy_adjust_link(struct phy_device *phydev)
 {
phydev->adjust_link(phydev->attached_dev);
+   phy_led_trigger_change_speed(phydev);
 }
 
 /**
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index e977ba9..4671c13 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -57,6 +58,7 @@ static void phy_mdio_device_free(struct mdio_device *mdiodev)
 
 static void phy_device_release(struct device *dev)
 {
+   phy_led_triggers_unregister(to_phy_device(dev));
kfree(to_phy_device(dev));
 }
 
@@ -345,6 +347,8 @@ struct phy_device *phy_device_create(struct mii_bus *bus, 
int addr, int phy_id,
 
dev->state = PHY_DOWN;
 
+   phy_led_triggers_register(dev);
+
mutex_init(>lock);
INIT_DELAYED_WORK(>state_queue, phy_state_machine);
INIT_WORK(>phy_queue, phy_change);
diff --git a/drivers/net/phy/phy_led_triggers.c 
b/drivers/net/phy/phy_led_triggers.c
new file mode 100644
index 000..32326d7
--- /dev/null
+++ b/drivers/net/phy/phy_led_triggers.c
@@ -0,0 +1,121 @@
+/* Copyright (C) 2016 National Instruments Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+  * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+
+static struct phy_led_trigger *phy_speed_to_led_trigger(struct phy_device *phy,
+   unsigned int speed)
+{
+   switch (speed) {
+   case SPEED_10:
+   return >phy_led_trigger[0];
+   case SPEED_100:
+   return >phy_led_trigger[1];
+   case SPEED_1000:
+   return >phy_led_trigger[2];
+   case SPEED_2500:
+   return 

[RFC v2 2/4] staging: rtl8712: Change _LED_STATE enum in rtl871x driver to avoid conflicts with LED namespace

2016-09-27 Thread Zach Brown
Adding led support for phy causes namespace conflicts for some
phy drivers.

The rtl871 driver declared an enum for representing LED states. The enum
contains constant LED_OFF which conflicted with declaration found in
linux/leds.h. LED_OFF changed to LED_STATE_OFF
In order to avoid a possible future collision LED_ON was changed to
LED_STATE_ON as well.

Signed-off-by: Zach Brown 
---
 drivers/staging/rtl8712/rtl8712_led.c | 388 +-
 1 file changed, 194 insertions(+), 194 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_led.c 
b/drivers/staging/rtl8712/rtl8712_led.c
index 9055827..8a524ac 100644
--- a/drivers/staging/rtl8712/rtl8712_led.c
+++ b/drivers/staging/rtl8712/rtl8712_led.c
@@ -51,8 +51,8 @@
  */
 enum _LED_STATE_871x {
LED_UNKNOWN = 0,
-   LED_ON = 1,
-   LED_OFF = 2,
+   LED_STATE_ON = 1,
+   LED_STATE_OFF = 2,
LED_BLINK_NORMAL = 3,
LED_BLINK_SLOWLY = 4,
LED_POWER_ON_BLINK = 5,
@@ -92,7 +92,7 @@ static void InitLed871x(struct _adapter *padapter, struct 
LED_871x *pLed,
nic = padapter->pnetdev;
pLed->padapter = padapter;
pLed->LedPin = LedPin;
-   pLed->CurrLedState = LED_OFF;
+   pLed->CurrLedState = LED_STATE_OFF;
pLed->bLedOn = false;
pLed->bLedBlinkInProgress = false;
pLed->BlinkTimes = 0;
@@ -208,7 +208,7 @@ static void SwLedBlink(struct LED_871x *pLed)
u8 bStopBlinking = false;
 
/* Change LED according to BlinkingLedState specified. */
-   if (pLed->BlinkingLedState == LED_ON)
+   if (pLed->BlinkingLedState == LED_STATE_ON)
SwLedOn(padapter, pLed);
else
SwLedOff(padapter, pLed);
@@ -248,10 +248,10 @@ static void SwLedBlink(struct LED_871x *pLed)
pLed->bLedBlinkInProgress = false;
} else {
/* Assign LED state to toggle. */
-   if (pLed->BlinkingLedState == LED_ON)
-   pLed->BlinkingLedState = LED_OFF;
+   if (pLed->BlinkingLedState == LED_STATE_ON)
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
-   pLed->BlinkingLedState = LED_ON;
+   pLed->BlinkingLedState = LED_STATE_ON;
 
/* Schedule a timer to toggle LED state. */
switch (pLed->CurrLedState) {
@@ -288,7 +288,7 @@ static void SwLedBlink1(struct LED_871x *pLed)
if (peeprompriv->CustomerID == RT_CID_819x_CAMEO)
pLed = &(ledpriv->SwLed1);
/* Change LED according to BlinkingLedState specified. */
-   if (pLed->BlinkingLedState == LED_ON)
+   if (pLed->BlinkingLedState == LED_STATE_ON)
SwLedOn(padapter, pLed);
else
SwLedOff(padapter, pLed);
@@ -312,17 +312,17 @@ static void SwLedBlink1(struct LED_871x *pLed)
switch (pLed->CurrLedState) {
case LED_BLINK_SLOWLY:
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
-   pLed->BlinkingLedState = LED_ON;
+   pLed->BlinkingLedState = LED_STATE_ON;
mod_timer(>BlinkTimer, jiffies +
  msecs_to_jiffies(LED_BLINK_NO_LINK_INTERVAL_ALPHA));
break;
case LED_BLINK_NORMAL:
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
-   pLed->BlinkingLedState = LED_ON;
+   pLed->BlinkingLedState = LED_STATE_ON;
mod_timer(>BlinkTimer, jiffies +
  msecs_to_jiffies(LED_BLINK_LINK_INTERVAL_ALPHA));
break;
@@ -335,27 +335,27 @@ static void SwLedBlink1(struct LED_871x *pLed)
pLed->bLedLinkBlinkInProgress = true;
pLed->CurrLedState = LED_BLINK_NORMAL;
if (pLed->bLedOn)
-   pLed->BlinkingLedState = LED_OFF;
+   pLed->BlinkingLedState = LED_STATE_OFF;
else
-   pLed->BlinkingLedState = LED_ON;
+   pLed->BlinkingLedState = LED_STATE_ON;
mod_timer(>BlinkTimer, jiffies +
  
msecs_to_jiffies(LED_BLINK_LINK_INTERVAL_ALPHA));
} else if (!check_fwstate(pmlmepriv, _FW_LINKED)) {
pLed->bLedNoLinkBlinkInProgress = true;
pLed->CurrLedState = LED_BLINK_SLOWLY;
if (pLed->bLedOn)
-   

Re: [PATCH v3 04/11] ext2: remove support for DAX PMD faults

2016-09-27 Thread Dave Chinner
On Tue, Sep 27, 2016 at 02:47:55PM -0600, Ross Zwisler wrote:
> DAX PMD support was added via the following commit:
> 
> commit e7b1ea2ad658 ("ext2: huge page fault support")
> 
> I believe this path to be untested as ext2 doesn't reliably provide block
> allocations that are aligned to 2MiB.  In my testing I've been unable to
> get ext2 to actually fault in a PMD.  It always fails with a "pfn
> unaligned" message because the sector returned by ext2_get_block() isn't
> aligned.
> 
> I've tried various settings for the "stride" and "stripe_width" extended
> options to mkfs.ext2, without any luck.
> 
> Since we can't reliably get PMDs, remove support so that we don't have an
> untested code path that we may someday traverse when we happen to get an
> aligned block allocation.  This should also make 4k DAX faults in ext2 a
> bit faster since they will no longer have to call the PMD fault handler
> only to get a response of VM_FAULT_FALLBACK.
> 
> Signed-off-by: Ross Zwisler 

> @@ -154,7 +133,6 @@ static int ext2_dax_pfn_mkwrite(struct vm_area_struct 
> *vma,
>  
>  static const struct vm_operations_struct ext2_dax_vm_ops = {
>   .fault  = ext2_dax_fault,
> - .pmd_fault  = ext2_dax_pmd_fault,
>   .page_mkwrite   = ext2_dax_fault,
>   .pfn_mkwrite= ext2_dax_pfn_mkwrite,
>  };

Would it be better to put a comment mentioning this here? So as the
years go by, this reminds people not to bother trying to implement
it?

/*
 * .pmd_fault is not supported for DAX because allocation in ext2
 * cannot be reliably aligned to huge page sizes and so pmd faults
 * will always fail and fail back to regular faults.
 */

-- 
Dave Chinner
da...@fromorbit.com


  1   2   3   4   5   6   >