[PATCH v1 3/3] soc: rockchip: power-domain: add power domain support for rk3366

2017-07-14 Thread Elaine Zhang
This driver is modified to support RK3366 SoC.

Signed-off-by: Elaine Zhang 
---
 drivers/soc/rockchip/pm_domains.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c 
b/drivers/soc/rockchip/pm_domains.c
index 796c46a6cbe7..40b75748835f 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -730,6 +731,16 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
[RK3328_PD_VPU] = DOMAIN_RK3328(-1, 9, 9, false),
 };
 
+static const struct rockchip_domain_info rk3366_pm_domains[] = {
+   [RK3366_PD_PERI]= DOMAIN_RK3368(10, 10, 6, true),
+   [RK3366_PD_VIO] = DOMAIN_RK3368(14, 14, 8, false),
+   [RK3366_PD_VIDEO]   = DOMAIN_RK3368(13, 13, 7, false),
+   [RK3366_PD_RKVDEC]  = DOMAIN_RK3368(11, 11, 7, false),
+   [RK3366_PD_WIFIBT]  = DOMAIN_RK3368(8, 8, 9, false),
+   [RK3366_PD_VPU] = DOMAIN_RK3368(12, 12, 7, false),
+   [RK3366_PD_GPU] = DOMAIN_RK3368(15, 15, 2, false),
+};
+
 static const struct rockchip_domain_info rk3368_pm_domains[] = {
[RK3368_PD_PERI]= DOMAIN_RK3368(13, 12, 6, true),
[RK3368_PD_VIO] = DOMAIN_RK3368(15, 14, 8, false),
@@ -794,6 +805,23 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
.domain_info = rk3328_pm_domains,
 };
 
+static const struct rockchip_pmu_info rk3366_pmu = {
+   .pwr_offset = 0x0c,
+   .status_offset = 0x10,
+   .req_offset = 0x3c,
+   .idle_offset = 0x40,
+   .ack_offset = 0x40,
+
+   .core_pwrcnt_offset = 0x48,
+   .gpu_pwrcnt_offset = 0x50,
+
+   .core_power_transition_time = 24,
+   .gpu_power_transition_time = 24,
+
+   .num_domains = ARRAY_SIZE(rk3366_pm_domains),
+   .domain_info = rk3366_pm_domains,
+};
+
 static const struct rockchip_pmu_info rk3368_pmu = {
.pwr_offset = 0x0c,
.status_offset = 0x10,
@@ -834,6 +862,10 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
.data = (void *)&rk3328_pmu,
},
{
+   .compatible = "rockchip,rk3366-power-controller",
+   .data = (void *)&rk3366_pmu,
+   },
+   {
.compatible = "rockchip,rk3368-power-controller",
.data = (void *)&rk3368_pmu,
},
-- 
1.9.1




Re: [RFC V2 1/6] cpufreq: Replace "max_transition_latency" with "dynamic_switching"

2017-07-14 Thread Dominik Brodowski
On Thu, Jul 13, 2017 at 06:19:53PM +0200, Rafael J. Wysocki wrote:
> On Thu, Jul 13, 2017 at 7:40 AM, Viresh Kumar  wrote:
> > There is no limitation in the ondemand or conservative governors which
> > disallow the transition_latency to be greater than 10 ms.
> >
> > The max_transition_latency field is rather used to disallow automatic
> > dynamic frequency switching for platforms which didn't wanted these
> > governors to run.
> >
> > Replace max_transition_latency with a boolean (dynamic_switching) and
> > check for transition_latency == CPUFREQ_ETERNAL along with that. This
> > makes it pretty straight forward to read/understand now.
> 
> Well, using CPUFREQ_ETERNAL for that on the driver side is still not
> particularly straightforward IMO, so maybe add a
> "no_dynamic_switching" to the driver structure and set it to "true"
> for the one driver in question?

IIRC it's not just one driver which sets the latency to CPUFREQ_ETERNAL, and
where dynamic switching might be harmful or at least lead to undefined
behavior.

Best,
Dominik


[PATCH v2] arm64: dts: ls1012a: add USB host controller nodes

2017-07-14 Thread Ran Wang
LS1012A has one USB 3.0(DWC3) controller and
one USB 2.0 controller.

Signed-off-by: Ran Wang 
---
Change in v2:
Move node usb2@860 to the back of sata@320 to keep nodes
sorted in unit-address.

 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index b1554cb..df83915 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -444,6 +444,15 @@
 <&clockgen 4 3>;
};
 
+   usb0: usb3@2f0 {
+   compatible = "snps,dwc3";
+   reg = <0x0 0x2f0 0x0 0x1>;
+   interrupts = <0 60 0x4>;
+   dr_mode = "host";
+   snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
+   };
+
sata: sata@320 {
compatible = "fsl,ls1012a-ahci", "fsl,ls1043a-ahci";
reg = <0x0 0x320 0x0 0x1>,
@@ -454,5 +463,13 @@
dma-coherent;
status = "disabled";
};
+
+   usb1: usb2@860 {
+   compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
+   reg = <0x0 0x860 0x0 0x1000>;
+   interrupts = <0 139 0x4>;
+   dr_mode = "host";
+   phy_type = "ulpi";
+   };
};
 };
-- 
2.1.0.27.g96db324



Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

2017-07-14 Thread Christoph Hellwig
On Thu, Jul 13, 2017 at 02:43:14PM -0700, Linus Torvalds wrote:
> On Thu, Jul 13, 2017 at 2:16 PM, Anna Schumaker
>  wrote:
> >
> >   git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.13-1
> 
> Btw, your key seems to have expired, and doing a refresh on it doesn't fix it.
> 
> I'm sure you've refreshed your key, but apparently that refresh hasn't
> been percolated to the public keyservers?

As someone who has run into an issue in that area recently:  I manually
had to refresh and re-upload my signing subkey and not just the primary
key, which wa rather confusing and took a long time to sort out.


Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG

2017-07-14 Thread Wei Wang

On 07/14/2017 04:19 AM, Michael S. Tsirkin wrote:

On Thu, Jul 13, 2017 at 03:42:35PM +0800, Wei Wang wrote:

On 07/12/2017 09:56 PM, Michael S. Tsirkin wrote:

So the way I see it, there are several issues:

- internal wait - forces multiple APIs like kick/kick_sync
note how kick_sync can fail but your code never checks return code
- need to re-write the last descriptor - might not work
for alternative layouts which always expose descriptors
immediately

Probably it wasn't clear. Please let me explain the two functions here:

1) virtqueue_add_chain_desc(vq, head_id, prev_id,..):
grabs a desc from the vq and inserts it to the chain tail (which is indexed
by
prev_id, probably better to call it tail_id). Then, the new added desc
becomes
the tail (i.e. the last desc). The _F_NEXT flag is cleared for each desc
when it's
added to the chain, and set when another desc comes to follow later.

And this only works if there are multiple rings like
avail + descriptor ring.
It won't work e.g. with the proposed new layout where
writing out a descriptor exposes it immediately.


I think it can support the 1.1 proposal, too. But before getting
into that, I think we first need to deep dive into the implementation
and usage of _first/next/last. The usage would need to lock the vq
from the first to the end (otherwise, the returned info about the number
of available desc in the vq, i.e. num_free, would be invalid):

lock(vq);
add_first();
add_next();
add_last();
unlock(vq);

However, I think the case isn't this simple, since we need to check more 
things
after each add_xx() step. For example, if only one entry is available at 
the time
we start to use the vq, that is, num_free is 0 after add_first(), we 
wouldn't be

able to add_next and add_last. So, it would work like this:

start:
...get free page block..
lock(vq)
retry:
ret = add_first(..,&num_free,);
if(ret == -ENOSPC) {
goto retry;
} else if (!num_free) {
add_chain_head();
unlock(vq);
kick & wait;
goto start;
}
next_one:
...get free page block..
add_next(..,&num_free,);
if (!num_free) {
add_chain_head();
unlock(vq);
kick & wait;
goto start;
} if (num_free == 1) {
...get free page block..
add_last(..);
unlock(vq);
kick & wait;
goto start;
} else {
goto next_one;
}

The above seems unnecessary to me to have three different APIs.
That's the reason to combine them into one virtqueue_add_chain_desc().

-- or, do you have a different thought about using the three APIs?


Implementation Reference:

struct desc_iterator {
unsigned int head;
unsigned int tail;
};

add_first(*vq, *desc_iterator, *num_free, ..)
{
if (vq->vq.num_free < 1)
return -ENOSPC;
get_desc(&desc_id);
desc[desc_id].flag &= ~_F_NEXT;
desc_iterator->head = desc_id
desc_iterator->tail = desc_iterator->head;
*num_free = vq->vq.num_free;
}

add_next(vq, desc_iterator, *num_free,..)
{
get_desc(&desc_id);
desc[desc_id].flag &= ~_F_NEXT;
desc[desc_iterator.tail].next = desc_id;
desc[desc_iterator->tail].flag |= _F_NEXT;
desc_iterator->tail = desc_id;
*num_free = vq->vq.num_free;
}

add_last(vq, desc_iterator,..)
{
get_desc(&desc_id);
desc[desc_id].flag &= ~_F_NEXT;
desc[desc_iterator.tail].next = desc_id;
desc_iterator->tail = desc_id;

add_chain_head(); // put the desc_iterator.head to the ring
}


Best,
Wei




Re: [PATCH v11 3/4] i2c: aspeed: added driver for Aspeed I2C

2017-07-14 Thread Wolfram Sang

> Basically what I was asking is whether I could use i2c_generic_scl_recovery
> in the case where SCL is hung.

The name is a bit misleading, I am afraid. Recovery can only be used when
SDA is stuck low. And to fix this it *uses* SCL toggling to get out of
it. And 'generic_scl' means 'gimme some SCL to control and I will toggle
it'. Compared to 'gpio_recovery' which will do all the GPIO handling for
you.

When SCL is hung, you can only reset the device which forces SCL low.

> I think I have a pretty good idea of what to do, I should probably just put
> together an RFC patch.

Sure.



signature.asc
Description: PGP signature


drm/edid: api to register cea modes if no edid supported

2017-07-14 Thread Saurabh Sengar
Adding drm_add_modes_noedid_cea API for supporting cea modes
for drm devices which does not have panel framework or edid
support.
Protocols like SDI whic have minimal support in linux kernel can
benifit from this.

There is already a API drm_add_modes_noedid, but that supports only
dmt modes.

Signed-off-by: Saurabh Sengar 
---
 drivers/gpu/drm/drm_edid.c | 48 ++
 include/drm/drm_edid.h |  2 ++
 2 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ec77bd3..08cfd9d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4110,6 +4110,54 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
 EXPORT_SYMBOL(drm_add_edid_modes);
 
 /**
+ * drm_add_modes_noedid_cea - add cea modes for the connectors without EDID
+ * @connector: connector we're probing
+ * @hdisplay: the horizontal display limit
+ * @vdisplay: the vertical display limit
+ *
+ * Add the cea modes to the connector's mode list. Only when the
+ * hdisplay/vdisplay is not beyond the given limit, it will be added.
+ *
+ * Return: The number of modes added or 0 if we couldn't find any.
+ */
+int drm_add_modes_noedid_cea(struct drm_connector *connector,
+   int hdisplay, int vdisplay)
+{
+   int i, count, num_modes = 0;
+   struct drm_display_mode *mode;
+   struct drm_device *dev = connector->dev;
+
+   count = ARRAY_SIZE(edid_cea_modes);
+   if (hdisplay < 0)
+   hdisplay = 0;
+   if (vdisplay < 0)
+   vdisplay = 0;
+
+   for (i = 0; i < count; i++) {
+   const struct drm_display_mode *ptr = &edid_cea_modes[i];
+   if (hdisplay && vdisplay) {
+   /*
+* Only when two are valid, they will be used to check
+* whether the mode should be added to the mode list of
+* the connector.
+*/
+   if (ptr->hdisplay > hdisplay ||
+   ptr->vdisplay > vdisplay)
+   continue;
+   }
+   if (drm_mode_vrefresh(ptr) > 61)
+   continue;
+   mode = drm_mode_duplicate(dev, ptr);
+   if (mode) {
+   drm_mode_probed_add(connector, mode);
+   num_modes++;
+   }
+   }
+   return num_modes;
+}
+EXPORT_SYMBOL(drm_add_modes_noedid_cea);
+
+/**
  * drm_add_modes_noedid - add modes for the connectors without EDID
  * @connector: connector we're probing
  * @hdisplay: the horizontal display limit
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index c3a7d44..67f4c26 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -445,6 +445,8 @@ bool drm_detect_monitor_audio(struct edid *edid);
 bool drm_rgb_quant_range_selectable(struct edid *edid);
 int drm_add_modes_noedid(struct drm_connector *connector,
 int hdisplay, int vdisplay);
+int drm_add_modes_noedid_cea(struct drm_connector *connector,
+int hdisplay, int vdisplay);
 void drm_set_preferred_mode(struct drm_connector *connector,
int hpref, int vpref);
 
-- 
2.1.1



[PATCH][-next] RDMA/bnxt_re: fix spelling mistake: "Deallocte" -> "Deallocate"

2017-07-14 Thread Colin King
From: Colin Ian King 

Trivial fix to spelling mistake in dev_err error message

Signed-off-by: Colin Ian King 
---
 drivers/infiniband/hw/bnxt_re/ib_verbs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c 
b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
index e1211c822894..dbf9ac8b1eb1 100644
--- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
+++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
@@ -3432,7 +3432,7 @@ int bnxt_re_dealloc_ucontext(struct ib_ucontext *ib_uctx)
&rdev->qplib_res.dpi_tbl,
&uctx->dpi);
if (rc)
-   dev_err(rdev_to_dev(rdev), "Deallocte HW DPI failed!");
+   dev_err(rdev_to_dev(rdev), "Deallocate HW DPI failed!");
/* Don't fail, continue*/
uctx->dpi.dbr = NULL;
}
-- 
2.11.0



Re: [PATCH 1/1 V2] media: usb: uvc: Fix incorrect timeout for Get Request

2017-07-14 Thread Laurent Pinchart
Hi Jim,

On Friday 14 Jul 2017 09:58:11 Jim Lin wrote:
> On 2017年07月11日 03:47, Laurent Pinchart wrote:
> > On Monday 10 Jul 2017 14:43:49 Jim Lin wrote:
> >> Section 9.2.6.4 of USB 2.0/3.x specification describes that
> >> "device must be able to return the first data packet to host within
> >> 500 ms of receipt of the request. For subsequent data packet, if any,
> >> the device must be able to return them within 500 ms".
> >> 
> >> This is to fix incorrect timeout and change it from 300 ms to 500 ms
> >> to meet the timing specified by specification for Get Request.
> >> 
> >> Signed-off-by: Jim Lin 
> > 
> > The patch looks good to me, so
> > 
> > Reviewed-by: Laurent Pinchart 
> > 
> > but I'm curious, have you noticed issues with some devices in practice ?
> 
> Sometimes this device takes about 360 ms to respond.
> 
> usb 1-2: new high-speed USB device number 16
> usb 1-2: New USB device found, idVendor=045e, idProduct=0772
> usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> usb 1-2: Product: Microsoft�® LifeCam Studio(TM)
> usb 1-2: Manufacturer: Microsoft
> 
> uvcvideo: Failed to query (GET_DEF) UVC control 2 on unit 4: -110 (exp. 2).
> 
> And it will be working well with correct timeout value.

Thank you for the information.

I've applied the patch to my tree and will push it to v4.14.

-- 
Regards,

Laurent Pinchart



Re: [PATCH v5 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU

2017-07-14 Thread Guillaume Tucker

On 14/07/17 07:41, Guillaume Tucker wrote:

Hi Brian,

On 12/07/17 18:26, Brian Norris wrote:

Hi Guillaume,

I know this has already been merged, but I figured here was an OK place
to note (inline):

On Wed, May 03, 2017 at 10:56:25AM +0100, Guillaume Tucker wrote:


[...]


diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
new file mode 100644
index ..d3b6e1a4713a
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt


^^ This file name implies we're talking about a base "arm,mali-midgard"
compatible property.


@@ -0,0 +1,86 @@
+ARM Mali Midgard GPU
+
+
+Required properties:
+
+- compatible :
+  * Must contain one of the following:
++ "arm,mali-t604"
++ "arm,mali-t624"
++ "arm,mali-t628"
++ "arm,mali-t720"
++ "arm,mali-t760"
++ "arm,mali-t820"
++ "arm,mali-t830"
++ "arm,mali-t860"
++ "arm,mali-t880"
+  * which must be preceded by one of the following vendor specifics:
++ "amlogic,meson-gxm-mali"
++ "rockchip,rk3288-mali"


But it's not listed here.


+
+- reg : Physical base address of the device and length of the register area.
+
+- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
+
+- interrupt-names : Contains the names of IRQ resources in the order they were
+  provided in the interrupts property. Must contain: "job", "mmu", "gpu".
+
+
+Optional properties:
+
+- clocks : Phandle to clock for the Mali Midgard device.
+
+- mali-supply : Phandle to regulator for the Mali device. Refer to
+  Documentation/devicetree/bindings/regulator/regulator.txt for details.
+
+- operating-points-v2 : Refer to 
Documentation/devicetree/bindings/power/opp.txt
+  for details.
+
+
+Example for a Mali-T760:
+
+gpu@ffa3 {
+compatible = "rockchip,rk3288-mali", "arm,mali-t760", "arm,mali-midgard";


And it *is* used here in this example.

So, should it be used/documented or not?


The important part is that having only arm,mali-midgard in the
gpu node is not enough to accurately describe the hardware, which
is why it is not listed in the required compatible strings.  On
the other hand, it does help with describing the hardware, so
it's fine to use it.  If people find this confusing then I guess
we could add something to say that arm,mali-midgard can be used
optionally in addition to the specific ones.

Also, if you look at the 64-bit ARM CPUs for example, they
typically have armv8 in their node although armv8 is not
mentioned anywhere in the bindings documentation...


Sorry I've only just seen Heiko's other emails and patches about
removing arm,mali-midgard from the example.

Guillaume


Re: [PATCH v3 4/7] libsas: add sas event wait-complete support

2017-07-14 Thread wangyijing


在 2017/7/14 14:51, Hannes Reinecke 写道:
> On 07/10/2017 09:06 AM, Yijing Wang wrote:
>> Introduce wait-complete for libsas sas event processing,
>> execute sas port create/destruct in sync.
>>
>> Signed-off-by: Yijing Wang 
>> CC: John Garry 
>> CC: Johannes Thumshirn 
>> CC: Ewan Milne 
>> CC: Christoph Hellwig 
>> CC: Tomas Henzl 
>> CC: Dan Williams 
>> ---
>>  drivers/scsi/libsas/sas_discover.c | 41 
>> --
>>  drivers/scsi/libsas/sas_internal.h | 34 +++
>>  drivers/scsi/libsas/sas_port.c |  4 
>>  include/scsi/libsas.h  |  5 -
>>  4 files changed, 72 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/scsi/libsas/sas_discover.c 
>> b/drivers/scsi/libsas/sas_discover.c
>> index 60de662..5d4a3a8 100644
>> --- a/drivers/scsi/libsas/sas_discover.c
>> +++ b/drivers/scsi/libsas/sas_discover.c
>> @@ -525,16 +525,43 @@ static void sas_revalidate_domain(struct work_struct 
>> *work)
>>  mutex_unlock(&ha->disco_mutex);
>>  }
>>  
>> +static const work_func_t sas_event_fns[DISC_NUM_EVENTS] = {
>> +[DISCE_DISCOVER_DOMAIN] = sas_discover_domain,
>> +[DISCE_REVALIDATE_DOMAIN] = sas_revalidate_domain,
>> +[DISCE_PROBE] = sas_probe_devices,
>> +[DISCE_SUSPEND] = sas_suspend_devices,
>> +[DISCE_RESUME] = sas_resume_devices,
>> +[DISCE_DESTRUCT] = sas_destruct_devices,
>> +};
>> +
>> +/* a simple wrapper for sas discover event funtions */
>> +static void sas_discover_common_fn(struct work_struct *work)
>> +{
>> +struct sas_discovery_event *ev = to_sas_discovery_event(work);
>> +struct asd_sas_port *port = ev->port;
>> +
>> +sas_event_fns[ev->type](work);
>> +sas_port_put(port);
>> +}
>> +
>> +
>>  /* -- Events -- */
>>  
>>  static void sas_chain_work(struct sas_ha_struct *ha, struct sas_work *sw)
>>  {
>> +int ret;
>> +struct sas_discovery_event *ev = to_sas_discovery_event(&sw->work);
>> +struct asd_sas_port *port = ev->port;
>> +
>>  /* chained work is not subject to SA_HA_DRAINING or
>>   * SAS_HA_REGISTERED, because it is either submitted in the
>>   * workqueue, or known to be submitted from a context that is
>>   * not racing against draining
>>   */
>> -scsi_queue_work(ha->core.shost, &sw->work);
>> +sas_port_get(port);
>> +ret = scsi_queue_work(ha->core.shost, &sw->work);
>> +if (ret != 1)
>> +sas_port_put(port);
>>  }
>>  
>>  static void sas_chain_event(int event, unsigned long *pending,
>> @@ -575,18 +602,10 @@ void sas_init_disc(struct sas_discovery *disc, struct 
>> asd_sas_port *port)
>>  {
>>  int i;
>>  
>> -static const work_func_t sas_event_fns[DISC_NUM_EVENTS] = {
>> -[DISCE_DISCOVER_DOMAIN] = sas_discover_domain,
>> -[DISCE_REVALIDATE_DOMAIN] = sas_revalidate_domain,
>> -[DISCE_PROBE] = sas_probe_devices,
>> -[DISCE_SUSPEND] = sas_suspend_devices,
>> -[DISCE_RESUME] = sas_resume_devices,
>> -[DISCE_DESTRUCT] = sas_destruct_devices,
>> -};
>> -
>>  disc->pending = 0;
>>  for (i = 0; i < DISC_NUM_EVENTS; i++) {
>> -INIT_SAS_WORK(&disc->disc_work[i].work, sas_event_fns[i]);
>> +INIT_SAS_WORK(&disc->disc_work[i].work, sas_discover_common_fn);
>>  disc->disc_work[i].port = port;
>> +disc->disc_work[i].type = i;
>>  }
>>  }
>> diff --git a/drivers/scsi/libsas/sas_internal.h 
>> b/drivers/scsi/libsas/sas_internal.h
>> index f03ce64..890b5d26 100644
>> --- a/drivers/scsi/libsas/sas_internal.h
>> +++ b/drivers/scsi/libsas/sas_internal.h
>> @@ -100,6 +100,40 @@ void sas_free_device(struct kref *kref);
>>  extern const work_func_t sas_phy_event_fns[PHY_NUM_EVENTS];
>>  extern const work_func_t sas_port_event_fns[PORT_NUM_EVENTS];
>>  
>> +static void sas_complete_event(struct kref *kref)
>> +{
>> +struct asd_sas_port *port = container_of(kref, struct asd_sas_port, 
>> ref);
>> +
>> +complete_all(&port->completion);
>> +}
>> +
>> +static inline void sas_port_put(struct asd_sas_port *port)
>> +{
>> +if (port->is_sync)
>> +kref_put(&port->ref, sas_complete_event);
>> +}
>> +
>> +static inline void sas_port_wait_init(struct asd_sas_port *port)
>> +{
>> +init_completion(&port->completion);
>> +kref_init(&port->ref);
>> +port->is_sync = true;
>> +}
>> +
>> +static inline void sas_port_wait_completion(
>> +struct asd_sas_port *port)
>> +{
>> +sas_port_put(port);
>> +wait_for_completion(&port->completion);
>> +port->is_sync = false;
>> +}
>> +
>> +static inline void sas_port_get(struct asd_sas_port *port)
>> +{
>> +if (port && port->is_sync)
>> +kref_get(&port->ref);
>> +}
>> +
>>  #ifdef CONFIG_SCSI_SAS_HOST_SMP
>>  extern int sas_smp_host_handler(struct Scsi_Host *shost, struct request 
>> *req,
>>  struct request *rsp);
>> diff --git a/drivers/scsi/libsas/sas_p

Re: [PATCH 13/18] dt-bindings: vendor: Add Huarui Lighting

2017-07-14 Thread Chen-Yu Tsai
On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard
 wrote:
> Huarui Lighting makes display panel, add it to the list of panels.

I could not find any information on "Huarui Lighting" within the
context of LCD panels. The company I found makes LED lighting
fixtures, floodlights, and high power LED drivers.

This might not be a legitimate branding?

ChenYu

>
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index afbb47ce50dd..cc5850a325f8 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -142,6 +142,7 @@ holtHolt Integrated Circuits, Inc.
>  honeywell  Honeywell
>  hp Hewlett Packard
>  holtek Holtek Semiconductor, Inc.
> +huarui Huarui Lighting Co. Ltd
>  hwacom HwaCom Systems Inc.
>  i2se   I2SE GmbH
>  ibmInternational Business Machines (IBM)
> --
> git-series 0.9.1


Re: [PATCH 0/2] i2c: move include files out of include/linux/i2c

2017-07-14 Thread Wolfram Sang
Hi peda,

> I don't seem to have this series in my inbox and not in my i2c folder either?

You have been CCed on the patches, but not on the cover-letter. Sorry
about that.

> patchwork and then I found it in the branch too, but in patchwork it has the
> expected "i2c: mux: " prefix so I'm not sure what you are talking about
> *exactly*.

Hmm, looks like I forgot to push out the updated branch. Sorry again.
But it is the same patch which originally got an imperfect prefix from
my automated script.

> But I'm sure you'll do something sensible, just go ahead.

I hope so :) Thanks!

> PS. Please Cc me if you want a faster reaction, I didn't notice this
> yesterday.

Yup, same issue as above. I was wrong in that I assumed you have been on
CC for the cover-letter as well. I should have checked again.

Thanks,

   Wolfram



signature.asc
Description: PGP signature


[PATCH 6/9] mm, page_alloc: simplify zonelist initialization

2017-07-14 Thread Michal Hocko
From: Michal Hocko 

build_zonelists gradually builds zonelists from the nearest to the most
distant node. As we do not know how many populated zones we will have in
each node we rely on the _zoneref to terminate initialized part of the
zonelist by a NULL zone. While this is functionally correct it is quite
suboptimal because we cannot allow updaters to race with zonelists
users because they could see an empty zonelist and fail the allocation
or hit the OOM killer in the worst case.

We can do much better, though. We can store the node ordering into an
already existing node_order array and then give this array to
build_zonelists_in_node_order and do the whole initialization at once.
zonelists consumers still might see halfway initialized state but that
should be much more tolerateable because the list will not be empty and
they would either see some zone twice or skip over some zone(s) in the
worst case which shouldn't lead to immediate failures.

This patch alone doesn't introduce any functional change yet, though, it
is merely a preparatory work for later changes.

Signed-off-by: Michal Hocko 
---
 mm/page_alloc.c | 42 ++
 1 file changed, 18 insertions(+), 24 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 00e117922b3f..78bd62418380 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4913,17 +4913,20 @@ static int find_next_best_node(int node, nodemask_t 
*used_node_mask)
  * This results in maximum locality--normal zone overflows into local
  * DMA zone, if any--but risks exhausting DMA zone.
  */
-static void build_zonelists_in_node_order(pg_data_t *pgdat, int node)
+static void build_zonelists_in_node_order(pg_data_t *pgdat, int *node_order)
 {
-   int j;
struct zonelist *zonelist;
+   int i, zoneref_idx = 0;
 
zonelist = &pgdat->node_zonelists[ZONELIST_FALLBACK];
-   for (j = 0; zonelist->_zonerefs[j].zone != NULL; j++)
-   ;
-   j = build_zonelists_node(NODE_DATA(node), zonelist, j);
-   zonelist->_zonerefs[j].zone = NULL;
-   zonelist->_zonerefs[j].zone_idx = 0;
+
+   for (i = 0; i < MAX_NUMNODES; i++) {
+   pg_data_t *node = NODE_DATA(node_order[i]);
+
+   zoneref_idx = build_zonelists_node(node, zonelist, zoneref_idx);
+   }
+   zonelist->_zonerefs[zoneref_idx].zone = NULL;
+   zonelist->_zonerefs[zoneref_idx].zone_idx = 0;
 }
 
 /*
@@ -4931,13 +4934,13 @@ static void build_zonelists_in_node_order(pg_data_t 
*pgdat, int node)
  */
 static void build_thisnode_zonelists(pg_data_t *pgdat)
 {
-   int j;
struct zonelist *zonelist;
+   int zoneref_idx = 0;
 
zonelist = &pgdat->node_zonelists[ZONELIST_NOFALLBACK];
-   j = build_zonelists_node(pgdat, zonelist, 0);
-   zonelist->_zonerefs[j].zone = NULL;
-   zonelist->_zonerefs[j].zone_idx = 0;
+   zoneref_idx = build_zonelists_node(pgdat, zonelist, zoneref_idx);
+   zonelist->_zonerefs[zoneref_idx].zone = NULL;
+   zonelist->_zonerefs[zoneref_idx].zone_idx = 0;
 }
 
 /*
@@ -4946,21 +4949,13 @@ static void build_thisnode_zonelists(pg_data_t *pgdat)
  * exhausted, but results in overflowing to remote node while memory
  * may still exist in local DMA zone.
  */
-static int node_order[MAX_NUMNODES];
 
 static void build_zonelists(pg_data_t *pgdat)
 {
-   int i, node, load;
+   static int node_order[MAX_NUMNODES];
+   int node, load, i = 0;
nodemask_t used_mask;
int local_node, prev_node;
-   struct zonelist *zonelist;
-
-   /* initialize zonelists */
-   for (i = 0; i < MAX_ZONELISTS; i++) {
-   zonelist = pgdat->node_zonelists + i;
-   zonelist->_zonerefs[0].zone = NULL;
-   zonelist->_zonerefs[0].zone_idx = 0;
-   }
 
/* NUMA-aware ordering of nodes */
local_node = pgdat->node_id;
@@ -4969,8 +4964,6 @@ static void build_zonelists(pg_data_t *pgdat)
nodes_clear(used_mask);
 
memset(node_order, 0, sizeof(node_order));
-   i = 0;
-
while ((node = find_next_best_node(local_node, &used_mask)) >= 0) {
/*
 * We don't want to pressure a particular node.
@@ -4981,11 +4974,12 @@ static void build_zonelists(pg_data_t *pgdat)
node_distance(local_node, prev_node))
node_load[node] = load;
 
+   node_order[i++] = node;
prev_node = node;
load--;
-   build_zonelists_in_node_order(pgdat, node);
}
 
+   build_zonelists_in_node_order(pgdat, node_order);
build_thisnode_zonelists(pgdat);
 }
 
-- 
2.11.0



[PATCH 4/9] mm, memory_hotplug: drop zone from build_all_zonelists

2017-07-14 Thread Michal Hocko
From: Michal Hocko 

build_all_zonelists gets a zone parameter to initialize zone's
pagesets. There is only a single user which gives a non-NULL
zone parameter and that one doesn't really need the rest of the
build_all_zonelists (see 6dcd73d7011b ("memory-hotplug: allocate zone's
pcp before onlining pages")).

Therefore remove setup_zone_pageset from build_all_zonelists and call it
from its only user directly. This will also remove a pointless zonlists
rebuilding which is always good.

Cc: Wen Congyang 
Signed-off-by: Michal Hocko 
---
 include/linux/mmzone.h |  2 +-
 init/main.c|  2 +-
 mm/internal.h  |  1 +
 mm/memory_hotplug.c| 10 +-
 mm/page_alloc.c| 12 +++-
 5 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index fc14b8b3f6ce..97f0f42e9f2a 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -771,7 +771,7 @@ static inline bool is_dev_zone(const struct zone *zone)
 #include 
 
 extern struct mutex zonelists_mutex;
-void build_all_zonelists(pg_data_t *pgdat, struct zone *zone);
+void build_all_zonelists(pg_data_t *pgdat);
 void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx);
 bool __zone_watermark_ok(struct zone *z, unsigned int order, unsigned long 
mark,
 int classzone_idx, unsigned int alloc_flags,
diff --git a/init/main.c b/init/main.c
index f866510472d7..e1baf6544d15 100644
--- a/init/main.c
+++ b/init/main.c
@@ -519,7 +519,7 @@ asmlinkage __visible void __init start_kernel(void)
boot_cpu_state_init();
smp_prepare_boot_cpu(); /* arch-specific boot-cpu hooks */
 
-   build_all_zonelists(NULL, NULL);
+   build_all_zonelists(NULL);
page_alloc_init();
 
pr_notice("Kernel command line: %s\n", boot_command_line);
diff --git a/mm/internal.h b/mm/internal.h
index 24d88f084705..19d1f35aa6d7 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -522,4 +522,5 @@ static inline bool is_migrate_highatomic_page(struct page 
*page)
return get_pageblock_migratetype(page) == MIGRATE_HIGHATOMIC;
 }
 
+void setup_zone_pageset(struct zone *zone);
 #endif /* __MM_INTERNAL_H */
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index d620d0427b6b..639b8af37c45 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -952,7 +952,7 @@ int __ref online_pages(unsigned long pfn, unsigned long 
nr_pages, int online_typ
mutex_lock(&zonelists_mutex);
if (!populated_zone(zone)) {
need_zonelists_rebuild = 1;
-   build_all_zonelists(NULL, zone);
+   setup_zone_pageset(zone);
}
 
ret = walk_system_ram_range(pfn, nr_pages, &onlined_pages,
@@ -973,7 +973,7 @@ int __ref online_pages(unsigned long pfn, unsigned long 
nr_pages, int online_typ
if (onlined_pages) {
node_states_set_node(nid, &arg);
if (need_zonelists_rebuild)
-   build_all_zonelists(NULL, NULL);
+   build_all_zonelists(NULL);
else
zone_pcp_update(zone);
}
@@ -1051,7 +1051,7 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, u64 
start)
 * to access not-initialized zonelist, build here.
 */
mutex_lock(&zonelists_mutex);
-   build_all_zonelists(pgdat, NULL);
+   build_all_zonelists(pgdat);
mutex_unlock(&zonelists_mutex);
 
/*
@@ -1107,7 +1107,7 @@ int try_online_node(int nid)
 
if (pgdat->node_zonelists->_zonerefs->zone == NULL) {
mutex_lock(&zonelists_mutex);
-   build_all_zonelists(NULL, NULL);
+   build_all_zonelists(NULL);
mutex_unlock(&zonelists_mutex);
}
 
@@ -1727,7 +1727,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
if (!populated_zone(zone)) {
zone_pcp_reset(zone);
mutex_lock(&zonelists_mutex);
-   build_all_zonelists(NULL, NULL);
+   build_all_zonelists(NULL);
mutex_unlock(&zonelists_mutex);
} else
zone_pcp_update(zone);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ebc3311555b1..00e117922b3f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5065,7 +5065,6 @@ static void build_zonelists(pg_data_t *pgdat)
 static void setup_pageset(struct per_cpu_pageset *p, unsigned long batch);
 static DEFINE_PER_CPU(struct per_cpu_pageset, boot_pageset);
 static DEFINE_PER_CPU(struct per_cpu_nodestat, boot_nodestats);
-static void setup_zone_pageset(struct zone *zone);
 
 /*
  * Global mutex to protect against size modification of zonelists
@@ -5146,19 +5145,14 @@ build_all_zonelists_init(void)
  * unless system_state == SYSTEM_BOOTING.
  *
  * __ref due to (1) call of __meminit annotated setup_zone_pageset
- * [we're only called with non-NULL zone through __meminit paths] and
- * (2) call of __init annotated

[PATCH 9/9] mm, sparse, page_ext: drop ugly N_HIGH_MEMORY branches for allocations

2017-07-14 Thread Michal Hocko
From: Michal Hocko 

f52407ce2dea ("memory hotplug: alloc page from other node in memory
online") has introduced N_HIGH_MEMORY checks to only use NUMA aware
allocations when there is some memory present because the respective
node might not have any memory yet at the time and so it could fail
or even OOM. Things have changed since then though. Zonelists are
now always initialized before we do any allocations even for hotplug
(see 959ecc48fc75 ("mm/memory_hotplug.c: fix building of node hotplug
zonelist")). Therefore these checks are not really needed. In fact
caller of the allocator should never care about whether the node is
populated because that might change at any time.

Cc: Shaohua Li 
Cc: joonsoo kim 
Signed-off-by: Michal Hocko 
---
 mm/page_ext.c   |  5 +
 mm/sparse-vmemmap.c | 11 +++
 mm/sparse.c | 10 +++---
 3 files changed, 7 insertions(+), 19 deletions(-)

diff --git a/mm/page_ext.c b/mm/page_ext.c
index 88ccc044b09a..714ce79256c5 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -222,10 +222,7 @@ static void *__meminit alloc_page_ext(size_t size, int nid)
return addr;
}
 
-   if (node_state(nid, N_HIGH_MEMORY))
-   addr = vzalloc_node(size, nid);
-   else
-   addr = vzalloc(size);
+   addr = vzalloc_node(size, nid);
 
return addr;
 }
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index c50b1a14d55e..d1a39b8051e0 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -54,14 +54,9 @@ void * __meminit vmemmap_alloc_block(unsigned long size, int 
node)
if (slab_is_available()) {
struct page *page;
 
-   if (node_state(node, N_HIGH_MEMORY))
-   page = alloc_pages_node(
-   node, GFP_KERNEL | __GFP_ZERO | 
__GFP_RETRY_MAYFAIL,
-   get_order(size));
-   else
-   page = alloc_pages(
-   GFP_KERNEL | __GFP_ZERO | __GFP_RETRY_MAYFAIL,
-   get_order(size));
+   page = alloc_pages_node(node,
+   GFP_KERNEL | __GFP_ZERO | __GFP_RETRY_MAYFAIL,
+   get_order(size));
if (page)
return page_address(page);
return NULL;
diff --git a/mm/sparse.c b/mm/sparse.c
index 7b4be3fd5cac..a9783acf2bb9 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -65,14 +65,10 @@ static noinline struct mem_section __ref 
*sparse_index_alloc(int nid)
unsigned long array_size = SECTIONS_PER_ROOT *
   sizeof(struct mem_section);
 
-   if (slab_is_available()) {
-   if (node_state(nid, N_HIGH_MEMORY))
-   section = kzalloc_node(array_size, GFP_KERNEL, nid);
-   else
-   section = kzalloc(array_size, GFP_KERNEL);
-   } else {
+   if (slab_is_available())
+   section = kzalloc_node(array_size, GFP_KERNEL, nid);
+   else
section = memblock_virt_alloc_node(array_size, nid);
-   }
 
return section;
 }
-- 
2.11.0



[PATCH 8/9] mm, memory_hotplug: get rid of zonelists_mutex

2017-07-14 Thread Michal Hocko
From: Michal Hocko 

zonelists_mutex has been introduced by 4eaf3f64397c ("mem-hotplug: fix
potential race while building zonelist for new populated zone") to
protect zonelist building from races. This is no longer needed though
because both memory online and offline are fully serialized. New users
have grown since then.

Notably setup_per_zone_wmarks wants to prevent from races between memory
hotplug, khugepaged setup and manual min_free_kbytes update via sysctl
(see cfd3da1e49bb ("mm: Serialize access to min_free_kbytes"). Let's
add a private lock for that purpose. This will not prevent from seeing
halfway through memory hotplug operation but that shouldn't be a big
deal becuse memory hotplug will update watermarks explicitly so we will
eventually get a full picture. The lock just makes sure we won't race
when updating watermarks leading to weird results.

Also __build_all_zonelists manipulates global data so add a private lock
for it as well. This doesn't seem to be necessary today but it is more
robust to have a lock there.

While we are at it make sure we document that memory online/offline
depends on a full serialization either via mem_hotplug_begin() or
device_lock.

Signed-off-by: Michal Hocko 
---
 include/linux/mmzone.h |  1 -
 mm/memory_hotplug.c| 12 ++--
 mm/page_alloc.c| 18 +-
 3 files changed, 11 insertions(+), 20 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 97f0f42e9f2a..3b638f989b7b 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -770,7 +770,6 @@ static inline bool is_dev_zone(const struct zone *zone)
 
 #include 
 
-extern struct mutex zonelists_mutex;
 void build_all_zonelists(pg_data_t *pgdat);
 void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx);
 bool __zone_watermark_ok(struct zone *z, unsigned int order, unsigned long 
mark,
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 0d2f6a11075c..c1b0077eb9d1 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -917,7 +917,7 @@ static struct zone * __meminit move_pfn_range(int 
online_type, int nid,
return zone;
 }
 
-/* Must be protected by mem_hotplug_begin() */
+/* Must be protected by mem_hotplug_begin() or a device_lock */
 int __ref online_pages(unsigned long pfn, unsigned long nr_pages, int 
online_type)
 {
unsigned long flags;
@@ -949,7 +949,6 @@ int __ref online_pages(unsigned long pfn, unsigned long 
nr_pages, int online_typ
 * This means the page allocator ignores this zone.
 * So, zonelist must be updated after online.
 */
-   mutex_lock(&zonelists_mutex);
if (!populated_zone(zone)) {
need_zonelists_rebuild = 1;
setup_zone_pageset(zone);
@@ -960,7 +959,6 @@ int __ref online_pages(unsigned long pfn, unsigned long 
nr_pages, int online_typ
if (ret) {
if (need_zonelists_rebuild)
zone_pcp_reset(zone);
-   mutex_unlock(&zonelists_mutex);
goto failed_addition;
}
 
@@ -978,8 +976,6 @@ int __ref online_pages(unsigned long pfn, unsigned long 
nr_pages, int online_typ
zone_pcp_update(zone);
}
 
-   mutex_unlock(&zonelists_mutex);
-
init_per_zone_wmark_min();
 
if (onlined_pages) {
@@ -1050,9 +1046,7 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, u64 
start)
 * The node we allocated has no zone fallback lists. For avoiding
 * to access not-initialized zonelist, build here.
 */
-   mutex_lock(&zonelists_mutex);
build_all_zonelists(pgdat);
-   mutex_unlock(&zonelists_mutex);
 
/*
 * zone->managed_pages is set to an approximate value in
@@ -1719,9 +1713,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
 
if (!populated_zone(zone)) {
zone_pcp_reset(zone);
-   mutex_lock(&zonelists_mutex);
build_all_zonelists(NULL);
-   mutex_unlock(&zonelists_mutex);
} else
zone_pcp_update(zone);
 
@@ -1747,7 +1739,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
return ret;
 }
 
-/* Must be protected by mem_hotplug_begin() */
+/* Must be protected by mem_hotplug_begin() or a device_lock */
 int offline_pages(unsigned long start_pfn, unsigned long nr_pages)
 {
return __offline_pages(start_pfn, start_pfn + nr_pages, 120 * HZ);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 217889ecd13f..dd4c96edcec3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5060,17 +5060,14 @@ static void setup_pageset(struct per_cpu_pageset *p, 
unsigned long batch);
 static DEFINE_PER_CPU(struct per_cpu_pageset, boot_pageset);
 static DEFINE_PER_CPU(struct per_cpu_nodestat, boot_nodestats);
 
-/*
- * Global mutex to protect against size modification of zonelists
- * as well as to serialize pageset setup for the new populated zone.
- *

[PATCH 7/9] mm, page_alloc: remove stop_machine from build_all_zonelists

2017-07-14 Thread Michal Hocko
From: Michal Hocko 

build_all_zonelists has been (ab)using stop_machine to make sure that
zonelists do not change while somebody is looking at them. This is
is just a gross hack because a) it complicates the context from which
we can call build_all_zonelists (see 3f906ba23689 ("mm/memory-hotplug:
switch locking to a percpu rwsem")) and b) is is not really necessary
especially after "mm, page_alloc: simplify zonelist initialization".

Updates of the zonelists happen very seldom, basically only when a zone
becomes populated during memory online or when it loses all the memory
during offline. A racing iteration over zonelists could either miss a
zone or try to work on one zone twice. Both of these are something we
can live with occasionally because there will always be at least one
zone visible so we are not likely to fail allocation too easily for
example.

Signed-off-by: Michal Hocko 
---
 mm/page_alloc.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 78bd62418380..217889ecd13f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5066,8 +5066,7 @@ static DEFINE_PER_CPU(struct per_cpu_nodestat, 
boot_nodestats);
  */
 DEFINE_MUTEX(zonelists_mutex);
 
-/* return values int just for stop_machine() */
-static int __build_all_zonelists(void *data)
+static void __build_all_zonelists(void *data)
 {
int nid;
int cpu;
@@ -5103,8 +5102,6 @@ static int __build_all_zonelists(void *data)
set_cpu_numa_mem(cpu, 
local_memory_node(cpu_to_node(cpu)));
 #endif
}
-
-   return 0;
 }
 
 static noinline void __init
@@ -5147,9 +5144,7 @@ void __ref build_all_zonelists(pg_data_t *pgdat)
if (system_state == SYSTEM_BOOTING) {
build_all_zonelists_init();
} else {
-   /* we have to stop all cpus to guarantee there is no user
-  of zonelist */
-   stop_machine_cpuslocked(__build_all_zonelists, pgdat, NULL);
+   __build_all_zonelists(pgdat);
/* cpuset refresh routine should be here */
}
vm_total_pages = nr_free_pagecache_pages();
-- 
2.11.0



[PATCH 0/9] cleanup zonelists initialization

2017-07-14 Thread Michal Hocko
Hi,
this is aimed at cleaning up the zonelists initialization code we have
but the primary motivation was bug report [1] which got resolved but
the usage of stop_machine is just too ugly to live. Most patches are
straightforward but 3 of them need a special consideration.

Patch 1 removes zone ordered zonelists completely. I am CCing linux-api
because this is a user visible change. As I argue in the patch
description I do not think we have a strong usecase for it these days.
I have kept sysctl in place and warn into the log if somebody tries to
configure zone lists ordering. If somebody has a real usecase for it
we can revert this patch but I do not expect anybody will actually notice
runtime differences. This patch is not strictly needed for the rest but
it made patch 6 easier to implement.

Patch 7 removes stop_machine from build_all_zonelists without adding any
special synchronization between iterators and updater which I _believe_
is acceptable as explained in the changelog. I hope I am not missing
anything.

Patch 8 then removes zonelists_mutex which is kind of ugly as well and
not really needed AFAICS but a care should be taken when double checking
my thinking.

This has passed my light testing but I currently do not have a HW to
test hotadd_new_pgdat path (aka a completely new node added to the
system in runtime).

This is based on the current mmomt git tree (mmotm-2017-07-12-15-11).
Any feedback is highly appreciated.

The diffstat looks really promissing
 include/linux/mmzone.h |   3 +-
 init/main.c|   2 +-
 kernel/sysctl.c|   2 -
 mm/internal.h  |   1 +
 mm/memory_hotplug.c|  27 +
 mm/page_alloc.c| 293 -
 mm/page_ext.c  |   5 +-
 mm/sparse-vmemmap.c|  11 +-
 mm/sparse.c|  10 +-
 9 files changed, 89 insertions(+), 265 deletions(-)

Shortlog says
Michal Hocko (9):
  mm, page_alloc: rip out ZONELIST_ORDER_ZONE
  mm, page_alloc: remove boot pageset initialization from memory hotplug
  mm, page_alloc: do not set_cpu_numa_mem on empty nodes initialization
  mm, memory_hotplug: drop zone from build_all_zonelists
  mm, memory_hotplug: remove explicit build_all_zonelists from 
try_online_node
  mm, page_alloc: simplify zonelist initialization
  mm, page_alloc: remove stop_machine from build_all_zonelists
  mm, memory_hotplug: get rid of zonelists_mutex
  mm, sparse, page_ext: drop ugly N_HIGH_MEMORY branches for allocations

[1] http://lkml.kernel.org/r/alpine.DEB.2.20.1706291803380.1861@nanos



[PATCH 1/9] mm, page_alloc: rip out ZONELIST_ORDER_ZONE

2017-07-14 Thread Michal Hocko
From: Michal Hocko 

Supporting zone ordered zonelists costs us just a lot of code while
the usefulness is arguable if existent at all. Mel has already made
node ordering default on 64b systems. 32b systems are still using
ZONELIST_ORDER_ZONE because it is considered better to fallback to
a different NUMA node rather than consume precious lowmem zones.

This argument is, however, weaken by the fact that the memory reclaim
has been reworked to be node rather than zone oriented. This means
that lowmem requests have to skip over all highmem pages on LRUs already
and so zone ordering doesn't save the reclaim time much. So the only
advantage of the zone ordering is under a light memory pressure when
highmem requests do not ever hit into lowmem zones and the lowmem
pressure doesn't need to reclaim.

Considering that 32b NUMA systems are rather suboptimal already and
it is generally advisable to use 64b kernel on such a HW I believe we
should rather care about the code maintainability and just get rid of
ZONELIST_ORDER_ZONE altogether. Keep systcl in place and warn if
somebody tries to set zone ordering either from kernel command line
or the sysctl.

Cc: 
Signed-off-by: Michal Hocko 
---
 kernel/sysctl.c |   2 -
 mm/page_alloc.c | 178 
 2 files changed, 23 insertions(+), 157 deletions(-)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 655686d546cb..0cbce40f5426 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1553,8 +1553,6 @@ static struct ctl_table vm_table[] = {
 #ifdef CONFIG_NUMA
{
.procname   = "numa_zonelist_order",
-   .data   = &numa_zonelist_order,
-   .maxlen = NUMA_ZONELIST_ORDER_LEN,
.mode   = 0644,
.proc_handler   = numa_zonelist_order_handler,
},
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 80e4adb4c360..d9f4ea057e74 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4791,52 +4791,18 @@ static int build_zonelists_node(pg_data_t *pgdat, 
struct zonelist *zonelist,
return nr_zones;
 }
 
-
-/*
- *  zonelist_order:
- *  0 = automatic detection of better ordering.
- *  1 = order by ([node] distance, -zonetype)
- *  2 = order by (-zonetype, [node] distance)
- *
- *  If not NUMA, ZONELIST_ORDER_ZONE and ZONELIST_ORDER_NODE will create
- *  the same zonelist. So only NUMA can configure this param.
- */
-#define ZONELIST_ORDER_DEFAULT  0
-#define ZONELIST_ORDER_NODE 1
-#define ZONELIST_ORDER_ZONE 2
-
-/* zonelist order in the kernel.
- * set_zonelist_order() will set this to NODE or ZONE.
- */
-static int current_zonelist_order = ZONELIST_ORDER_DEFAULT;
-static char zonelist_order_name[3][8] = {"Default", "Node", "Zone"};
-
-
 #ifdef CONFIG_NUMA
-/* The value user specified changed by config */
-static int user_zonelist_order = ZONELIST_ORDER_DEFAULT;
-/* string for sysctl */
-#define NUMA_ZONELIST_ORDER_LEN16
-char numa_zonelist_order[16] = "default";
-
-/*
- * interface for configure zonelist ordering.
- * command line option "numa_zonelist_order"
- * = "[dD]efault   - default, automatic configuration.
- * = "[nN]ode  - order by node locality, then by zone within node
- * = "[zZ]one  - order by zone, then by locality within zone
- */
 
 static int __parse_numa_zonelist_order(char *s)
 {
-   if (*s == 'd' || *s == 'D') {
-   user_zonelist_order = ZONELIST_ORDER_DEFAULT;
-   } else if (*s == 'n' || *s == 'N') {
-   user_zonelist_order = ZONELIST_ORDER_NODE;
-   } else if (*s == 'z' || *s == 'Z') {
-   user_zonelist_order = ZONELIST_ORDER_ZONE;
-   } else {
-   pr_warn("Ignoring invalid numa_zonelist_order value:  %s\n", s);
+   /*
+* We used to support different zonlists modes but they turned
+* out to be just not useful. Let's keep the warning in place
+* if somebody still use the cmd line parameter so that we do
+* not fail it silently
+*/
+   if (!(*s == 'd' || *s == 'D' || *s == 'n' || *s == 'N')) {
+   pr_warn("Ignoring unsupported numa_zonelist_order value:  
%s\n", s);
return -EINVAL;
}
return 0;
@@ -4844,16 +4810,10 @@ static int __parse_numa_zonelist_order(char *s)
 
 static __init int setup_numa_zonelist_order(char *s)
 {
-   int ret;
-
if (!s)
return 0;
 
-   ret = __parse_numa_zonelist_order(s);
-   if (ret == 0)
-   strlcpy(numa_zonelist_order, s, NUMA_ZONELIST_ORDER_LEN);
-
-   return ret;
+   return __parse_numa_zonelist_order(s);
 }
 early_param("numa_zonelist_order", setup_numa_zonelist_order);
 
@@ -4864,40 +4824,22 @@ int numa_zonelist_order_handler(struct ctl_table 
*table, int write,
void __user *buffer, size_t *length,
loff_t *ppos)
 {
-   char saved_string[NUMA_ZONELIST_ORDER_LEN];
+   char *str;
 

[PATCH 5/9] mm, memory_hotplug: remove explicit build_all_zonelists from try_online_node

2017-07-14 Thread Michal Hocko
From: Michal Hocko 

try_online_node calls hotadd_new_pgdat which already calls
build_all_zonelists. So the additional call is redundant.  Even though
hotadd_new_pgdat will only initialize zonelists of the new node this is
the right thing to do because such a node doesn't have any memory so
other zonelists would ignore all the zones from this node anyway.

Cc: Toshi Kani 
Signed-off-by: Michal Hocko 
---
 mm/memory_hotplug.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 639b8af37c45..0d2f6a11075c 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1104,13 +1104,6 @@ int try_online_node(int nid)
node_set_online(nid);
ret = register_one_node(nid);
BUG_ON(ret);
-
-   if (pgdat->node_zonelists->_zonerefs->zone == NULL) {
-   mutex_lock(&zonelists_mutex);
-   build_all_zonelists(NULL);
-   mutex_unlock(&zonelists_mutex);
-   }
-
 out:
mem_hotplug_done();
return ret;
-- 
2.11.0



[PATCH 2/9] mm, page_alloc: remove boot pageset initialization from memory hotplug

2017-07-14 Thread Michal Hocko
From: Michal Hocko 

boot_pageset is a boot time hack which gets superseded by normal
pagesets later in the boot process. It makes zero sense to reinitialize
it again and again during memory hotplug.

Signed-off-by: Michal Hocko 
---
 mm/page_alloc.c | 38 +-
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d9f4ea057e74..7746824a425d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5098,23 +5098,8 @@ static int __build_all_zonelists(void *data)
}
}
 
-   /*
-* Initialize the boot_pagesets that are going to be used
-* for bootstrapping processors. The real pagesets for
-* each zone will be allocated later when the per cpu
-* allocator is available.
-*
-* boot_pagesets are used also for bootstrapping offline
-* cpus if the system is already booted because the pagesets
-* are needed to initialize allocators on a specific cpu too.
-* F.e. the percpu allocator needs the page allocator which
-* needs the percpu allocator in order to allocate its pagesets
-* (a chicken-egg dilemma).
-*/
-   for_each_possible_cpu(cpu) {
-   setup_pageset(&per_cpu(boot_pageset, cpu), 0);
-
 #ifdef CONFIG_HAVE_MEMORYLESS_NODES
+   for_each_possible_cpu(cpu) {
/*
 * We now know the "local memory node" for each node--
 * i.e., the node of the first zone in the generic zonelist.
@@ -5125,8 +5110,8 @@ static int __build_all_zonelists(void *data)
 */
if (cpu_online(cpu))
set_cpu_numa_mem(cpu, 
local_memory_node(cpu_to_node(cpu)));
-#endif
}
+#endif
 
return 0;
 }
@@ -5134,7 +5119,26 @@ static int __build_all_zonelists(void *data)
 static noinline void __init
 build_all_zonelists_init(void)
 {
+   int cpu;
+
__build_all_zonelists(NULL);
+
+   /*
+* Initialize the boot_pagesets that are going to be used
+* for bootstrapping processors. The real pagesets for
+* each zone will be allocated later when the per cpu
+* allocator is available.
+*
+* boot_pagesets are used also for bootstrapping offline
+* cpus if the system is already booted because the pagesets
+* are needed to initialize allocators on a specific cpu too.
+* F.e. the percpu allocator needs the page allocator which
+* needs the percpu allocator in order to allocate its pagesets
+* (a chicken-egg dilemma).
+*/
+   for_each_possible_cpu(cpu)
+   setup_pageset(&per_cpu(boot_pageset, cpu), 0);
+
mminit_verify_zonelist();
cpuset_init_current_mems_allowed();
 }
-- 
2.11.0



[PATCH 3/9] mm, page_alloc: do not set_cpu_numa_mem on empty nodes initialization

2017-07-14 Thread Michal Hocko
From: Michal Hocko 

__build_all_zonelists reinitializes each online cpu local node for
CONFIG_HAVE_MEMORYLESS_NODES. This makes sense because previously memory
less nodes could gain some memory during memory hotplug and so the local
node should be changed for CPUs close to such a node. It makes less
sense to do that unconditionally for a newly creaded NUMA node which is
still offline and without any memory.

Let's also simplify the cpu loop and use for_each_online_cpu instead of
an explicit cpu_online check for all possible cpus.

Signed-off-by: Michal Hocko 
---
 mm/page_alloc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7746824a425d..ebc3311555b1 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5096,10 +5096,8 @@ static int __build_all_zonelists(void *data)
 
build_zonelists(pgdat);
}
-   }
 
 #ifdef CONFIG_HAVE_MEMORYLESS_NODES
-   for_each_possible_cpu(cpu) {
/*
 * We now know the "local memory node" for each node--
 * i.e., the node of the first zone in the generic zonelist.
@@ -5108,10 +5106,10 @@ static int __build_all_zonelists(void *data)
 * secondary cpus' numa_mem as they come on-line.  During
 * node/memory hotplug, we'll fixup all on-line cpus.
 */
-   if (cpu_online(cpu))
+   for_each_online_cpu(cpu)
set_cpu_numa_mem(cpu, 
local_memory_node(cpu_to_node(cpu)));
-   }
 #endif
+   }
 
return 0;
 }
-- 
2.11.0



Re: [PATCH] MAINTAINERS: move the befs tree to kernel.org

2017-07-14 Thread Luis de Bethencourt

On 07/12/2017 11:00 PM, Andrew Morton wrote:

On Wed, 12 Jul 2017 23:40:53 +0200 "Luis R. Rodriguez"  
wrote:


A soft bump to see if this can make it before the merge window closes.
Which is probably too late for already.


I've bounced a copy to Andrew. Andrew can this go through your tree this late?


Sure.



I should've tought of CC'ing Andrew from the beginning. My bad.

Thanks Luis and Andrew :)

Luis


[PATCH] zsmalloc: zs_page_migrate: not check inuse if migrate_mode is not MIGRATE_ASYNC

2017-07-14 Thread Hui Zhu
Got some -EBUSY from zs_page_migrate that will make migration
slow (retry) or fail (zs_page_putback will schedule_work free_work,
but it cannot ensure the success).

And I didn't find anything that make zs_page_migrate cannot work with
a ZS_EMPTY zspage.
So make the patch to not check inuse if migrate_mode is not
MIGRATE_ASYNC.

Signed-off-by: Hui Zhu 
---
 mm/zsmalloc.c | 66 +--
 1 file changed, 37 insertions(+), 29 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index d41edd2..c298e5c 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1982,6 +1982,7 @@ int zs_page_migrate(struct address_space *mapping, struct 
page *newpage,
unsigned long old_obj, new_obj;
unsigned int obj_idx;
int ret = -EAGAIN;
+   int inuse;
 
VM_BUG_ON_PAGE(!PageMovable(page), page);
VM_BUG_ON_PAGE(!PageIsolated(page), page);
@@ -1996,21 +1997,24 @@ int zs_page_migrate(struct address_space *mapping, 
struct page *newpage,
offset = get_first_obj_offset(page);
 
spin_lock(&class->lock);
-   if (!get_zspage_inuse(zspage)) {
+   inuse = get_zspage_inuse(zspage);
+   if (mode == MIGRATE_ASYNC && !inuse) {
ret = -EBUSY;
goto unlock_class;
}
 
pos = offset;
s_addr = kmap_atomic(page);
-   while (pos < PAGE_SIZE) {
-   head = obj_to_head(page, s_addr + pos);
-   if (head & OBJ_ALLOCATED_TAG) {
-   handle = head & ~OBJ_ALLOCATED_TAG;
-   if (!trypin_tag(handle))
-   goto unpin_objects;
+   if (inuse) {
+   while (pos < PAGE_SIZE) {
+   head = obj_to_head(page, s_addr + pos);
+   if (head & OBJ_ALLOCATED_TAG) {
+   handle = head & ~OBJ_ALLOCATED_TAG;
+   if (!trypin_tag(handle))
+   goto unpin_objects;
+   }
+   pos += class->size;
}
-   pos += class->size;
}
 
/*
@@ -2020,20 +2024,22 @@ int zs_page_migrate(struct address_space *mapping, 
struct page *newpage,
memcpy(d_addr, s_addr, PAGE_SIZE);
kunmap_atomic(d_addr);
 
-   for (addr = s_addr + offset; addr < s_addr + pos;
-   addr += class->size) {
-   head = obj_to_head(page, addr);
-   if (head & OBJ_ALLOCATED_TAG) {
-   handle = head & ~OBJ_ALLOCATED_TAG;
-   if (!testpin_tag(handle))
-   BUG();
-
-   old_obj = handle_to_obj(handle);
-   obj_to_location(old_obj, &dummy, &obj_idx);
-   new_obj = (unsigned long)location_to_obj(newpage,
-   obj_idx);
-   new_obj |= BIT(HANDLE_PIN_BIT);
-   record_obj(handle, new_obj);
+   if (inuse) {
+   for (addr = s_addr + offset; addr < s_addr + pos;
+   addr += class->size) {
+   head = obj_to_head(page, addr);
+   if (head & OBJ_ALLOCATED_TAG) {
+   handle = head & ~OBJ_ALLOCATED_TAG;
+   if (!testpin_tag(handle))
+   BUG();
+
+   old_obj = handle_to_obj(handle);
+   obj_to_location(old_obj, &dummy, &obj_idx);
+   new_obj = (unsigned long)
+   location_to_obj(newpage, obj_idx);
+   new_obj |= BIT(HANDLE_PIN_BIT);
+   record_obj(handle, new_obj);
+   }
}
}
 
@@ -2055,14 +2061,16 @@ int zs_page_migrate(struct address_space *mapping, 
struct page *newpage,
 
ret = MIGRATEPAGE_SUCCESS;
 unpin_objects:
-   for (addr = s_addr + offset; addr < s_addr + pos;
+   if (inuse) {
+   for (addr = s_addr + offset; addr < s_addr + pos;
addr += class->size) {
-   head = obj_to_head(page, addr);
-   if (head & OBJ_ALLOCATED_TAG) {
-   handle = head & ~OBJ_ALLOCATED_TAG;
-   if (!testpin_tag(handle))
-   BUG();
-   unpin_tag(handle);
+   head = obj_to_head(page, addr);
+   if (head & OBJ_ALLOCATED_TAG) {
+   handle = head & ~OBJ_ALLOCATED_TAG;
+   if (!testpin_tag(handle))
+   BUG();
+   unpin_tag(handle);
+   

[PATCH v5 1/3] pinctrl: Add sleep related state to indicate sleep related configs

2017-07-14 Thread Baolin Wang
In some scenarios, we should set some pins as input/output/pullup/pulldown
when the specified system goes into deep sleep mode, then when the system
goes into deep sleep mode, these pins will be set automatically by hardware.

That means some pins are not controlled by any specific driver in the OS, but
need to be controlled when entering sleep mode. Thus we introduce one sleep
state config into pinconf-generic for users to configure.

Signed-off-by: Baolin Wang 
---
Changes since v4:
 - Add sleep-hardware-state config to indicate sleep related configs.
---
 .../bindings/pinctrl/pinctrl-bindings.txt  |2 ++
 drivers/pinctrl/pinconf-generic.c  |2 ++
 include/linux/pinctrl/pinconf-generic.h|2 ++
 3 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index bf3f7b0..2365a21 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -236,6 +236,8 @@ low-power-enable- enable low power mode
 low-power-disable  - disable low power mode
 output-low - set the pin to output mode with low level
 output-high- set the pin to output mode with high level
+sleep-hardware-state   - indicate this is sleep related state which will be 
programmed
+ into the registers for the sleep state.
 slew-rate  - set the slew rate
 
 For example:
diff --git a/drivers/pinctrl/pinconf-generic.c 
b/drivers/pinctrl/pinconf-generic.c
index ce3335a..9a7f168 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -46,6 +46,7 @@
PCONFDUMP(PIN_CONFIG_LOW_POWER_MODE, "pin low power", "mode", true),
PCONFDUMP(PIN_CONFIG_OUTPUT, "pin output", "level", true),
PCONFDUMP(PIN_CONFIG_POWER_SOURCE, "pin power source", "selector", 
true),
+   PCONFDUMP(PIN_CONFIG_SLEEP_HARDWARE_STATE, "sleep hardware state", 
NULL, false),
PCONFDUMP(PIN_CONFIG_SLEW_RATE, "slew rate", NULL, true),
 };
 
@@ -175,6 +176,7 @@ void pinconf_generic_dump_config(struct pinctrl_dev 
*pctldev,
{ "output-high", PIN_CONFIG_OUTPUT, 1, },
{ "output-low", PIN_CONFIG_OUTPUT, 0, },
{ "power-source", PIN_CONFIG_POWER_SOURCE, 0 },
+   { "sleep-hardware-state", PIN_CONFIG_SLEEP_HARDWARE_STATE, 0 },
{ "slew-rate", PIN_CONFIG_SLEW_RATE, 0 },
 };
 
diff --git a/include/linux/pinctrl/pinconf-generic.h 
b/include/linux/pinctrl/pinconf-generic.h
index 7620eb1..a5d0fb4 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -80,6 +80,7 @@
  * @PIN_CONFIG_POWER_SOURCE: if the pin can select between different power
  * supplies, the argument to this parameter (on a custom format) tells
  * the driver which alternative power source to use.
+ * @PIN_CONFIG_SLEEP_HARDWARE_STATE: indicate this is sleep related state.
  * @PIN_CONFIG_SLEW_RATE: if the pin can select slew rate, the argument to
  * this parameter (on a custom format) tells the driver which alternative
  * slew rate to use.
@@ -107,6 +108,7 @@ enum pin_config_param {
PIN_CONFIG_LOW_POWER_MODE,
PIN_CONFIG_OUTPUT,
PIN_CONFIG_POWER_SOURCE,
+   PIN_CONFIG_SLEEP_HARDWARE_STATE,
PIN_CONFIG_SLEW_RATE,
PIN_CONFIG_END = 0x7F,
PIN_CONFIG_MAX = 0xFF,
-- 
1.7.9.5



[PATCH v5 3/3] pinctrl: sprd: Add Spreadtrum pin control driver

2017-07-14 Thread Baolin Wang
This patch adds the pin control driver for Spreadtrum SC9860 platform.

Signed-off-by: Baolin Wang 
---
Changes since v4:
 - Remove sleep configs.
 - Use one standard sleep hardware state config to indicate sleep configs.

Changes since v3:
 - Use the generic "bia-pull-up" config.
 - Use some generic sleep related config.

Changes since v2:
 - Fix some compile warnings.
 - Reimplement the pin_config_get() callback and add debug function.

Changes since v1:
 - Remove magic numbers and use generic pin control bindings.
---
 drivers/pinctrl/Kconfig|1 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/sprd/Kconfig   |   17 +
 drivers/pinctrl/sprd/Makefile  |2 +
 drivers/pinctrl/sprd/pinctrl-sprd-sc9860.c |  972 
 drivers/pinctrl/sprd/pinctrl-sprd.c| 1113 
 drivers/pinctrl/sprd/pinctrl-sprd.h|   67 ++
 7 files changed, 2173 insertions(+)
 create mode 100644 drivers/pinctrl/sprd/Kconfig
 create mode 100644 drivers/pinctrl/sprd/Makefile
 create mode 100644 drivers/pinctrl/sprd/pinctrl-sprd-sc9860.c
 create mode 100644 drivers/pinctrl/sprd/pinctrl-sprd.c
 create mode 100644 drivers/pinctrl/sprd/pinctrl-sprd.h

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 8f8c2af..681e593 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -304,6 +304,7 @@ source "drivers/pinctrl/ti/Kconfig"
 source "drivers/pinctrl/uniphier/Kconfig"
 source "drivers/pinctrl/vt8500/Kconfig"
 source "drivers/pinctrl/mediatek/Kconfig"
+source "drivers/pinctrl/sprd/Kconfig"
 
 config PINCTRL_XWAY
bool
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a251f43..006e352 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -57,3 +57,4 @@ obj-y += ti/
 obj-$(CONFIG_PINCTRL_UNIPHIER) += uniphier/
 obj-$(CONFIG_ARCH_VT8500)  += vt8500/
 obj-$(CONFIG_PINCTRL_MTK)  += mediatek/
+obj-y  += sprd/
diff --git a/drivers/pinctrl/sprd/Kconfig b/drivers/pinctrl/sprd/Kconfig
new file mode 100644
index 000..6f4a7f9
--- /dev/null
+++ b/drivers/pinctrl/sprd/Kconfig
@@ -0,0 +1,17 @@
+#
+# Spreadtrum pin control drivers
+#
+
+config PINCTRL_SPRD
+   bool "Spreadtrum pinctrl driver"
+   select PINMUX
+   select PINCONF
+   select GENERIC_PINCONF
+   select GENERIC_PINMUX_FUNCTIONS
+   help
+ Say Y here to enable Spreadtrum pinctrl driver
+
+config PINCTRL_SPRD_SC9860
+   bool "Spreadtrum SC9860 pinctrl driver"
+   help
+ Say Y here to enable Spreadtrum SC9860 pinctrl driver
diff --git a/drivers/pinctrl/sprd/Makefile b/drivers/pinctrl/sprd/Makefile
new file mode 100644
index 000..b6caa8c
--- /dev/null
+++ b/drivers/pinctrl/sprd/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_PINCTRL_SPRD) += pinctrl-sprd.o
+obj-$(CONFIG_PINCTRL_SPRD_SC9860)  += pinctrl-sprd-sc9860.o
diff --git a/drivers/pinctrl/sprd/pinctrl-sprd-sc9860.c 
b/drivers/pinctrl/sprd/pinctrl-sprd-sc9860.c
new file mode 100644
index 000..3cdad8b
--- /dev/null
+++ b/drivers/pinctrl/sprd/pinctrl-sprd-sc9860.c
@@ -0,0 +1,972 @@
+/*
+ * Spreadtrum pin controller driver
+ * Copyright (C) 2017 Spreadtrum  - http://www.spreadtrum.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 "pinctrl-sprd.h"
+
+enum sprd_sc9860_pins {
+   /* pin global control register 0 */
+   SC9860_VIO28_0_IRTE = SPRD_PIN_INFO(0, GLOBAL_CTRL_PIN, 11, 1, 0),
+   SC9860_VIO_SD2_IRTE = SPRD_PIN_INFO(1, GLOBAL_CTRL_PIN, 10, 1, 0),
+   SC9860_VIO_SD0_IRTE = SPRD_PIN_INFO(2, GLOBAL_CTRL_PIN, 9, 1, 0),
+   SC9860_VIO_SIM2_IRTE = SPRD_PIN_INFO(3, GLOBAL_CTRL_PIN, 8, 1, 0),
+   SC9860_VIO_SIM1_IRTE = SPRD_PIN_INFO(4, GLOBAL_CTRL_PIN, 7, 1, 0),
+   SC9860_VIO_SIM0_IRTE = SPRD_PIN_INFO(5, GLOBAL_CTRL_PIN, 6, 1, 0),
+   SC9860_VIO28_0_MS = SPRD_PIN_INFO(6, GLOBAL_CTRL_PIN, 5, 1, 0),
+   SC9860_VIO_SD2_MS = SPRD_PIN_INFO(7, GLOBAL_CTRL_PIN, 4, 1, 0),
+   SC9860_VIO_SD0_MS = SPRD_PIN_INFO(8, GLOBAL_CTRL_PIN, 3, 1, 0),
+   SC9860_VIO_SIM2_MS = SPRD_PIN_INFO(9, GLOBAL_CTRL_PIN, 2, 1, 0),
+   SC9860_VIO_SIM1_MS = SPRD_PIN_INFO(10, GLOBAL_CTRL_PIN, 1, 1, 0),
+   SC9860_VIO_SIM0_MS = SPRD_PIN_INFO(11, GLOBAL_CTRL_PIN, 0, 1, 0),
+
+   /* pin global control register 2 */
+   SC9860_SPSPI_PIN_IN_SEL = SPRD_PIN_INFO(12, GLOBAL_CTRL_PIN, 31, 1, 2),
+   SC9860_UART1_USB30_PHY_SEL = SPRD_PIN_INFO(13, GLOBAL_CTRL_PIN, 30, 1, 
2),
+

[PATCH v5 2/3] dt-bindings: pinctrl: Add Spreadtrum SC9860 pin controller

2017-07-14 Thread Baolin Wang
This patch adds the binding documentation for Spreadtrum SC9860 pin
controller device.

Signed-off-by: Baolin Wang 
---
Changes since v4:
 - Remove these sleep related configs and only introduce one sleep
   state config to indicate this is sleep state.

Changes since v3:
 - Use generic "bias-pull-up" instead of "sprd,pull-up".
 - Change subject name.
 - Use generic sleep related config.
 - Add more explanation for sleep related configuration and sleep mode.

Changes since v2:
 - No updates.

Changes since v1:
 - Remove magic numbers and get to use the standard bindings.
 - Fix some typos.
---
 .../devicetree/bindings/pinctrl/sprd,pinctrl.txt   |   83 
 .../bindings/pinctrl/sprd,sc9860-pinctrl.txt   |   70 +
 2 files changed, 153 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/sprd,sc9860-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt
new file mode 100644
index 000..b1cea7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt
@@ -0,0 +1,83 @@
+* Spreadtrum Pin Controller
+
+The Spreadtrum pin controller are organized in 3 blocks (types).
+
+The first block comprises some global control registers, and each
+register contains several bit fields with one bit or several bits
+to configure for some global common configuration, such as domain
+pad driving level, system control select and so on ("domain pad
+driving level": One pin can output 3.0v or 1.8v, depending on the
+related domain pad driving selection, if the related domain pad
+slect 3.0v, then the pin can output 3.0v. "system control" is used
+to choose one function (like: UART0) for which system, since we
+have several systems (AP/CP/CM4) on one SoC.).
+
+There are too much various configuration that we can not list all
+of them, so we can not make every Spreadtrum-special configuration
+as one generic configuration, and maybe it will add more strange
+global configuration in future. Then we add one "sprd,control" to
+set these various global control configuration, and we need use
+magic number for this property.
+
+Moreover we recognise every fields comprising one bit or several
+bits in one global control register as one pin, thus we should
+record every pin's bit offset, bit width and register offset to
+configure this field (pin).
+
+The second block comprises some common registers which have unified
+register definition, and each register described one pin is used
+to configure the pin sleep mode, function select and sleep related
+configuration.
+
+Now we have 4 systems for sleep mode on SC9860 SoC: AP system,
+PUBCP system, TGLDSP system and AGDSP system. And the pin sleep
+related configuration are:
+- input-enable
+- input-disable
+- output-high
+- output-low
+- bias-pull-up
+- bias-pull-down
+
+In some situation we need set the pin sleep mode and pin sleep related
+configuration, to set the pin sleep related configuration automatically
+by hardware when the system specified by sleep mode goes into deep
+sleep mode. For example, if we set the pin sleep mode as PUBCP_SLEEP
+and set the pin sleep related configuration as "input-enable", which
+means when PUBCP system goes into deep sleep mode, this pin will be set
+input enable automatically.
+
+Moreover we can not use the "sleep" state, since some systems (like:
+PUBCP system) do not run linux kernel OS (only AP system run linux
+kernel on SC9860 platform), then we can not select "sleep" state
+when the PUBCP system goes into deep sleep mode. Thus we introduce
+"sprd,sleep-mode" property to set pin sleep mode.
+
+The last block comprises some misc registers which also have unified
+register definition, and each register described one pin is used to
+configure drive strength, pull up/down and so on. Especially for pull
+up, we have two kind pull up resistor: 20K and 4.7K.
+
+Required properties for Spreadtrum pin controller:
+- compatible: "sprd,-pinctrl"
+  Please refer to each sprd,-pinctrl.txt binding doc for supported SoCs.
+- reg: The register address of pin controller device.
+- pins : An array of pin names.
+
+Optional properties:
+- function: Specified the function name.
+- drive-strength: Drive strength in mA.
+- input-schmitt-disable: Enable schmitt-trigger mode.
+- input-schmitt-enable: Disable schmitt-trigger mode.
+- bias-disable: Disable pin bias.
+- bias-pull-down: Pull down on pin.
+- bias-pull-up: Pull up on pin.
+- input-enable: Enable pin input.
+- input-disable: Enable pin output.
+- output-high: Set the pin as an output level high.
+- output-low: Set the pin as an output level low.
+- sleep-hardware-state: Indicate these configs in this state are sleep related.
+- sprd,control: Control values referring to databook for global control pins.
+- sprd,sleep-mode: Sleep mode selection.
+
+Please refer to ea

Re: [PATCH v3 0/7] Enhance libsas hotplug feature

2017-07-14 Thread wangyijing
Hi, I'm sorry to say that I have to stop the libsas hotplug improvement work, I 
will resign from
Huawei, so I have no time and hardware to continue to work at this issue. John 
is very familiar with
this work, and provide a lot of good suggestions. So if John like, I am glad he 
could join to work
at this issues, And my colleague Jason Yan could also provide helps.


Thanks!
Yijing.


在 2017/7/10 15:06, Yijing Wang 写道:
> This patchset is based Johannes's patch
> "scsi: sas: scsi_queue_work can fail, so make callers aware"
> 
> Now the libsas hotplug has some issues, Dan Williams report
> a similar bug here before
> https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html
> 
> The issues we have found
> 1. if LLDD burst reports lots of phy-up/phy-down sas events, some events
>may lost because a same sas events is pending now, finally libsas topo
>may different the hardware.
> 2. receive a phy down sas event, libsas call sas_deform_port to remove
>devices, it would first delete the sas port, then put a destruction
>discovery event in a new work, and queue it at the tail of workqueue,
>once the sas port be deleted, its children device will be deleted too,
>when the destruction work start, it will found the target device has
>been removed, and report a sysfs warnning.
> 3. since a hotplug process will be devided into several works, if a phy up
>sas event insert into phydown works, like
>destruction work  ---> PORTE_BYTES_DMAED (sas_form_port) 
> >PHYE_LOSS_OF_SIGNAL
>the hot remove flow would broken by PORTE_BYTES_DMAED event, it's not
>we expected, and issues would occur.
> 
> The first patch fix the sas events lost, and the second one introudce 
> wait-complete
> to fix the hotplug order issues.
> 
> v2->v3: some code improvements suggested by Johannes and John,
>   split v2 patch 2 into several small pathes.
> v1->v2: some code improvements suggested by John Garry
> 
> Yijing Wang (7):
>   libsas: Use static sas event pool to appease sas event lost
>   libsas: remove unused port_gone_completion
>   libsas: Use new workqueue to run sas event
>   libsas: add sas event wait-complete support
>   libsas: add a new workqueue to run probe/destruct discovery event
>   libsas: add wait-complete support to sync discovery event
>   libsas: release disco mutex during waiting in sas_ex_discover_end_dev
> 
>  drivers/scsi/libsas/sas_discover.c |  58 +++---
>  drivers/scsi/libsas/sas_event.c| 212 
> -
>  drivers/scsi/libsas/sas_expander.c |  22 +++-
>  drivers/scsi/libsas/sas_init.c |  21 ++--
>  drivers/scsi/libsas/sas_internal.h |  64 +++
>  drivers/scsi/libsas/sas_phy.c  |  48 +++--
>  drivers/scsi/libsas/sas_port.c |  22 ++--
>  include/scsi/libsas.h  |  27 +++--
>  8 files changed, 373 insertions(+), 101 deletions(-)
> 



[PATCH 0/4] constify scsi attribute_group structures.

2017-07-14 Thread Arvind Yadav
attribute_groups are not supposed to change at runtime.
So mark the non-const structs as const.

Arvind Yadav (4):
  [PATCH 1/4] scsi: scsi_transport_iscsi: constify attribute_group structures.
  [PATCH 2/4] scsi: iscsi_boot_sysfs: constify attribute_group structures.
  [PATCH 3/4] scsi: scsi_transport_fc: constify attribute_group structures.
  [PATCH 4/4] scsi: scsi_transport_spi: constify attribute_group structures.

 drivers/scsi/iscsi_boot_sysfs.c | 10 +-
 drivers/scsi/scsi_transport_fc.c|  2 +-
 drivers/scsi/scsi_transport_iscsi.c | 12 ++--
 drivers/scsi/scsi_transport_spi.c   |  4 ++--
 include/linux/iscsi_boot_sysfs.h|  2 +-
 5 files changed, 15 insertions(+), 15 deletions(-)

-- 
1.9.1


[PATCH 1/4] scsi: scsi_transport_iscsi: constify attribute_group structures.

2017-07-14 Thread Arvind Yadav
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  40380   10422  44   50846c69e scsi/scsi_transport_iscsi.o

File size After adding 'const':
   textdata bss dec hex filename
  40764   10070  44   50878c6be scsi/scsi_transport_iscsi.o

Signed-off-by: Arvind Yadav 
---
 drivers/scsi/scsi_transport_iscsi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index a424eae..55393b3 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -139,7 +139,7 @@ static void iscsi_transport_release(struct device *dev)
NULL,
 };
 
-static struct attribute_group iscsi_transport_group = {
+static const struct attribute_group iscsi_transport_group = {
.attrs = iscsi_transport_attrs,
 };
 
@@ -177,7 +177,7 @@ static void iscsi_endpoint_release(struct device *dev)
NULL,
 };
 
-static struct attribute_group iscsi_endpoint_group = {
+static const struct attribute_group iscsi_endpoint_group = {
.attrs = iscsi_endpoint_attrs,
 };
 
@@ -680,7 +680,7 @@ static umode_t iscsi_iface_attr_is_visible(struct kobject 
*kobj,
NULL,
 };
 
-static struct attribute_group iscsi_iface_group = {
+static const struct attribute_group iscsi_iface_group = {
.attrs = iscsi_iface_attrs,
.is_visible = iscsi_iface_attr_is_visible,
 };
@@ -3922,7 +3922,7 @@ static umode_t iscsi_conn_attr_is_visible(struct kobject 
*kobj,
return t->attr_is_visible(ISCSI_PARAM, param);
 }
 
-static struct attribute_group iscsi_conn_group = {
+static const struct attribute_group iscsi_conn_group = {
.attrs = iscsi_conn_attrs,
.is_visible = iscsi_conn_attr_is_visible,
 };
@@ -4217,7 +4217,7 @@ static umode_t iscsi_session_attr_is_visible(struct 
kobject *kobj,
return t->attr_is_visible(ISCSI_PARAM, param);
 }
 
-static struct attribute_group iscsi_session_group = {
+static const struct attribute_group iscsi_session_group = {
.attrs = iscsi_session_attrs,
.is_visible = iscsi_session_attr_is_visible,
 };
@@ -4285,7 +4285,7 @@ static umode_t iscsi_host_attr_is_visible(struct kobject 
*kobj,
return priv->iscsi_transport->attr_is_visible(ISCSI_HOST_PARAM, param);
 }
 
-static struct attribute_group iscsi_host_group = {
+static const struct attribute_group iscsi_host_group = {
.attrs = iscsi_host_attrs,
.is_visible = iscsi_host_attr_is_visible,
 };
-- 
1.9.1



[PATCH 4/4] scsi: scsi_transport_spi: constify attribute_group structures.

2017-07-14 Thread Arvind Yadav
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by 
and  work with const attribute_group. So mark the non-const
structs as const.

File size before:
   textdata bss dec hex filename
  154441616   0   1706042a4 drivers/scsi/scsi_transport_spi.o

File size After adding 'const':
   textdata bss dec hex filename
  155721488   0   1706042a4 drivers/scsi/scsi_transport_spi.o

Signed-off-by: Arvind Yadav 
---
 drivers/scsi/scsi_transport_spi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/scsi_transport_spi.c 
b/drivers/scsi/scsi_transport_spi.c
index d0219e3..ec723b2 100644
--- a/drivers/scsi/scsi_transport_spi.c
+++ b/drivers/scsi/scsi_transport_spi.c
@@ -1426,7 +1426,7 @@ static DECLARE_ANON_TRANSPORT_CLASS(spi_device_class,
NULL
 };
 
-static struct attribute_group host_attribute_group = {
+static const struct attribute_group host_attribute_group = {
.attrs = host_attributes,
 };
 
@@ -1536,7 +1536,7 @@ static umode_t target_attribute_is_visible(struct kobject 
*kobj,
NULL
 };
 
-static struct attribute_group target_attribute_group = {
+static const struct attribute_group target_attribute_group = {
.attrs = target_attributes,
.is_visible = target_attribute_is_visible,
 };
-- 
1.9.1



[PATCH 2/4] scsi: iscsi_boot_sysfs: constify attribute_group structures.

2017-07-14 Thread Arvind Yadav
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   25481768   0431610dc drivers/scsi/iscsi_boot_sysfs.o

File size After adding 'const':
   textdata bss dec hex filename
   28041512   0431610dc drivers/scsi/iscsi_boot_sysfs.o

Signed-off-by: Arvind Yadav 
---
 drivers/scsi/iscsi_boot_sysfs.c  | 10 +-
 include/linux/iscsi_boot_sysfs.h |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/iscsi_boot_sysfs.c b/drivers/scsi/iscsi_boot_sysfs.c
index d453667..9670a04 100644
--- a/drivers/scsi/iscsi_boot_sysfs.c
+++ b/drivers/scsi/iscsi_boot_sysfs.c
@@ -157,7 +157,7 @@ static umode_t iscsi_boot_tgt_attr_is_visible(struct 
kobject *kobj,
return 0;
 }
 
-static struct attribute_group iscsi_boot_target_attr_group = {
+static const struct attribute_group iscsi_boot_target_attr_group = {
.attrs = target_attrs,
.is_visible = iscsi_boot_tgt_attr_is_visible,
 };
@@ -243,7 +243,7 @@ static umode_t iscsi_boot_eth_attr_is_visible(struct 
kobject *kobj,
return 0;
 }
 
-static struct attribute_group iscsi_boot_ethernet_attr_group = {
+static const struct attribute_group iscsi_boot_ethernet_attr_group = {
.attrs = ethernet_attrs,
.is_visible = iscsi_boot_eth_attr_is_visible,
 };
@@ -301,7 +301,7 @@ static umode_t iscsi_boot_ini_attr_is_visible(struct 
kobject *kobj,
return 0;
 }
 
-static struct attribute_group iscsi_boot_initiator_attr_group = {
+static const struct attribute_group iscsi_boot_initiator_attr_group = {
.attrs = initiator_attrs,
.is_visible = iscsi_boot_ini_attr_is_visible,
 };
@@ -337,14 +337,14 @@ static umode_t iscsi_boot_acpitbl_attr_is_visible(struct 
kobject *kobj,
return 0;
 }
 
-static struct attribute_group iscsi_boot_acpitbl_attr_group = {
+static const struct attribute_group iscsi_boot_acpitbl_attr_group = {
.attrs = acpitbl_attrs,
.is_visible = iscsi_boot_acpitbl_attr_is_visible,
 };
 
 static struct iscsi_boot_kobj *
 iscsi_boot_create_kobj(struct iscsi_boot_kset *boot_kset,
-  struct attribute_group *attr_group,
+  const struct attribute_group *attr_group,
   const char *name, int index, void *data,
   ssize_t (*show) (void *data, int type, char *buf),
   umode_t (*is_visible) (void *data, int type),
diff --git a/include/linux/iscsi_boot_sysfs.h b/include/linux/iscsi_boot_sysfs.h
index 10923d7..3fb07e0 100644
--- a/include/linux/iscsi_boot_sysfs.h
+++ b/include/linux/iscsi_boot_sysfs.h
@@ -74,7 +74,7 @@ enum iscsi_boot_acpitbl_properties_enum {
 
 struct iscsi_boot_kobj {
struct kobject kobj;
-   struct attribute_group *attr_group;
+   const struct attribute_group *attr_group;
struct list_head list;
 
/*
-- 
1.9.1



[PATCH 3/4] scsi: scsi_transport_fc: constify attribute_group structures.

2017-07-14 Thread Arvind Yadav
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by 
work with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  341221932   4   360588cda drivers/scsi/scsi_transport_fc.o

File size After adding 'const':
   textdata bss dec hex filename
  341861868   4   360588cda drivers/scsi/scsi_transport_fc.o

Signed-off-by: Arvind Yadav 
---
 drivers/scsi/scsi_transport_fc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 7e24aa3..eda39cc 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -1808,7 +1808,7 @@ static FC_DEVICE_ATTR(host, reset_statistics, S_IWUSR, 
NULL,
NULL
 };
 
-static struct attribute_group fc_statistics_group = {
+static const struct attribute_group fc_statistics_group = {
.name = "statistics",
.attrs = fc_statistics_attrs,
 };
-- 
1.9.1



Re: [PATCH] mm/mremap: Fail map duplication attempts for private mappings

2017-07-14 Thread Michal Hocko
On Thu 13-07-17 15:33:47, Mike Kravetz wrote:
> On 07/13/2017 12:11 PM, Vlastimil Babka wrote:
> > [+CC linux-api]
> > 
> > On 07/13/2017 05:58 PM, Mike Kravetz wrote:
> >> mremap will create a 'duplicate' mapping if old_size == 0 is
> >> specified.  Such duplicate mappings make no sense for private
> >> mappings.  If duplication is attempted for a private mapping,
> >> mremap creates a separate private mapping unrelated to the
> >> original mapping and makes no modifications to the original.
> >> This is contrary to the purpose of mremap which should return
> >> a mapping which is in some way related to the original.
> >>
> >> Therefore, return EINVAL in the case where if an attempt is
> >> made to duplicate a private mapping.
> >>
> >> Signed-off-by: Mike Kravetz 
> > 
> > Acked-by: Vlastimil Babka 
> > 
> 
> In another e-mail thread, Andrea makes the case that mremap(old_size == 0)
> of private file backed mappings could possibly be used for something useful.
> For example to create a private COW mapping.

What does this mean exactly? I do not see it would force CoW so again
the new mapping could fail with the basic invariant that the content
of the new mapping should match the old one (e.g. old mapping already
CoWed some pages the new mapping would still contain the origin content
unless I am missing something).

[...]
> + /*
> +  * !old_len  is a special case where a mapping is 'duplicated'.
> +  * Do not allow this for private anon mappings.
> +  */
> + if (!old_len && vma_is_anonymous(vma) &&
> + !(vma->vm_flags & (VM_SHARED | VM_MAYSHARE)))
> + return ERR_PTR(-EINVAL);

Why is vma_is_anonymous() without VM_*SHARE* check insufficient?
-- 
Michal Hocko
SUSE Labs


Re: [PATCH v3 7/7] libsas: release disco mutex during waiting in sas_ex_discover_end_dev

2017-07-14 Thread John Garry

On 14/07/2017 02:44, wangyijing wrote:



在 2017/7/14 0:10, John Garry 写道:

On 10/07/2017 08:06, Yijing Wang wrote:

Disco mutex was introudced to prevent domain rediscovery competing
with ata error handling(87c8331). If we have already hold the lock
in sas_revalidate_domain and sync executing probe, deadlock caused,
because, sas_probe_sata() also need hold disco_mutex. Since disco mutex
use to prevent revalidata domain happen during ata error handler,
it should be safe to release disco mutex when sync probe, because
no new revalidate domain event would be process until the sync return,
and the current sas revalidate domain finish.



So with your changes we have a chain of synchronised events, running in 
separate queues. In theory it sounds ok.

Then, as you said in the commit message, sas_revalidate_domain() holds the 
disco mutex while *all* these chained events occur; so we will continue to hold 
the mutex until we have revalidated the domain, meaning until we have finished 
destroying or probing new devices.

But in the domain revalidation when you discover a new ATA device, function 
sas_probe_sata() wants to grab the disco mutex and you just temporarily release 
it, even though adding a new ATA device kicks in EH. This defeats the principal 
of using a mutex at all, which is (according to 87c8331 commit message) to 
mutually exclude the domain re-discovery (which has not actually finished) and 
the ATA EH (and device destruction).

Anyway, since we are synchronising this series of events (broadcast event, 
domain rediscovery, and device destruction), surely it should be possible to 
include the ATA EH as well, so we can actually get rid of the disco mutex 
finally, right?


Yes, disco mutex make this issue complex, I checked the commit history, Dan 
introudce disco mutex and probe/destruct discovery event, so it seems to
need a big rework to the libsas process logic, I am so sorry that I have no 
more time to deal with it, I will leave today, if you like, you could
rework my patchset or add additional changes based this patchset.




Since we are now synchronising everything, we should work on removing 
the disco mutex. After all, that is what a mutex is for - synchronising.


But the devil is in the detail...





Note: I think that there is a problem which you have not seen. Consider 
removing a ATA disk with IO active conncted to an expander:
- LLDD sends brodcast event
- sas_revalidate_domain(), which grabs disco mutex
- revalidate finds dev is gone
- destruct device, which calls sas_rphy_delete
- this waits on command queue to drain
- commands time out and EH thread kicks in
- sas_ata_strategy_handler() called
- domain revalidation disable attempted
- try to grab disco mutex = Deadlock.


Yes, it's a issue I haven't found.


Thanks!
Yijing.




Hi John, I also agree to rework disco mutex




Thanks,
John


Signed-off-by: Yijing Wang 
CC: John Garry 
CC: Johannes Thumshirn 
CC: Ewan Milne 
CC: Christoph Hellwig 
CC: Tomas Henzl 
CC: Dan Williams 
---
 drivers/scsi/libsas/sas_expander.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/scsi/libsas/sas_expander.c 
b/drivers/scsi/libsas/sas_expander.c
index 9d26c28..077024e 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -776,6 +776,7 @@ static struct domain_device *sas_ex_discover_end_dev(
 struct ex_phy *phy = &parent_ex->ex_phy[phy_id];
 struct domain_device *child = NULL;
 struct sas_rphy *rphy;
+bool prev_lock;
 int res;

 if (phy->attached_sata_host || phy->attached_sata_ps)
@@ -803,6 +804,7 @@ static struct domain_device *sas_ex_discover_end_dev(
 sas_ex_get_linkrate(parent, child, phy);
 sas_device_set_phy(child, phy->port);

+prev_lock = mutex_is_locked(&child->port->ha->disco_mutex);
 #ifdef CONFIG_SCSI_SAS_ATA
 if ((phy->attached_tproto & SAS_PROTOCOL_STP) || phy->attached_sata_dev) {
 res = sas_get_ata_info(child, phy);
@@ -832,7 +834,11 @@ static struct domain_device *sas_ex_discover_end_dev(
 SAS_ADDR(parent->sas_addr), phy_id, res);
 goto out_list_del;
 }
+if (prev_lock)
+mutex_unlock(&child->port->ha->disco_mutex);
 sas_disc_wait_completion(child->port, DISCE_PROBE);
+if (prev_lock)
+mutex_lock(&child->port->ha->disco_mutex);

 } else
 #endif
@@ -861,7 +867,11 @@ static struct domain_device *sas_ex_discover_end_dev(
 SAS_ADDR(parent->sas_addr), phy_id, res);
 goto out_list_del;
 }
+if (prev_lock)
+mutex_unlock(&child->port->ha->disco_mutex);
 sas_disc_wait_completion(child->port, DISCE_PROBE);
+if (prev_lock)
+mutex_lock(&child->port->ha->disco_mutex);
 } else {
 SAS_DPRINTK("target proto 0x%x at %016llx:0x%x not handled\n",
 phy->attached_tproto, SAS_ADDR(parent->sas_addr),





.




.






Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

2017-07-14 Thread Ingo Molnar

* Josh Poimboeuf  wrote:

> For user space stack unwinding, the kernel could emulate what the kernel
> 'guess' unwinder does by scanning the user space stack and returning all
> the text addresses it finds.

User-space stacks tend to be much larger than kernel stacks, the cost of doing 
such a full scan on every PMI would kill a lot of profiling workloads.

Thanks,

Ingo


Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

2017-07-14 Thread Ingo Molnar

* Josh Poimboeuf  wrote:

> > > The results wouldn't be 100% accurate, but they could end up being useful 
> > > over time.
> > 
> > And to expound further on the bad idea, maybe the "bad" addresses could be 
> > filtered out somehow in post-processing (insert lots of hand waving).
> 
> And some details on the post-processing: in most cases it should be possible 
> to 
> determine which of the found stack addresses are valid by looking at the call 
> instructions immediately preceding the stack text addresses, and making sure 
> the 
> call target points to the same function as the previously found address.  But 
> of 
> course that wouldn't work for indirect calls.

I believe this is similar to how OProfile did graph/dwarf profiling, by saving 
a 
copy of the stack and post-processing it.

By my best recollection (but I haven't used OProfile that much) it was both a 
performance nightmare, was limited (because it only saved a part of the stack), 
and was rather fragile as well, because it depended on the task VM being 
post-processable.

I think the highest quality implementation is to generate the call trace either 
in 
hardware (LBR), or as close to the event as possible: generate the kernel call 
chain in the PMI context, and the user-space call chain before user-space 
executes 
again (at the latest). Call chain generation should be roughly O(chain_depth), 
which both FP and ORC ensures.

Thanks,

Ingo


Re: [PATCH 1/5 v2] Extend the request_region() infrastructure

2017-07-14 Thread Boszormenyi Zoltan

2017-06-22 15:21 keltezéssel, Zoltán Böszörményi írta:

Add a new IORESOURCE_ALLOCATED flag that is automatically used
when alloc_resource() is used internally in kernel/resource.c
and free_resource() now takes this flag into account.

The core of __request_region() was factored out into a new function
called __request_declared_region() that needs struct resource *
instead of the (start, n, name) triplet.

These changes allow using statically declared struct resource
data coupled with the pre-existing DEFINE_RES_IO_NAMED() static
initializer macro. The new macro exploiting
__request_declared_region() is request_declared_muxed_region()

v2:

Fixed checkpatch.pl warnings and errors and extended the macro
API with request_declared_region() and release_declared_region()

Reversed the order of __request_declared_region and __request_region

Added high level description of the muxed and declared variants
of the macros.

Signed-off-by: Zoltán Böszörményi 
---
  include/linux/ioport.h | 14 ++
  kernel/resource.c  | 40 +---
  2 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 6230064..6ebcd39 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -52,6 +52,7 @@ struct resource {
  #define IORESOURCE_MEM_64 0x0010
  #define IORESOURCE_WINDOW 0x0020  /* forwarded by bridge */
  #define IORESOURCE_MUXED  0x0040  /* Resource is software muxed */
+#define IORESOURCE_ALLOCATED   0x0080  /* Resource was allocated */
  
  #define IORESOURCE_EXT_TYPE_BITS 0x0100	/* Resource extended types */

  #define IORESOURCE_SYSRAM 0x0100  /* System RAM (modifier) */
@@ -215,7 +216,14 @@ static inline bool resource_contains(struct resource *r1, 
struct resource *r2)
  
  /* Convenience shorthand with allocation */

  #define request_region(start,n,name)  
__request_region(&ioport_resource, (start), (n), (name), 0)
+#define request_declared_region(res)   __request_region( \
+   &ioport_resource, \
+   (res), 0)
  #define request_muxed_region(start,n,name)
__request_region(&ioport_resource, (start), (n), (name), IORESOURCE_MUXED)
+#define request_declared_muxed_region(res) __request_declared_region( \
+   &ioport_resource, \
+   (res), \
+   IORESOURCE_MUXED)
  #define __request_mem_region(start,n,name, excl) 
__request_region(&iomem_resource, (start), (n), (name), excl)
  #define request_mem_region(start,n,name) __request_region(&iomem_resource, 
(start), (n), (name), 0)
  #define request_mem_region_exclusive(start,n,name) \
@@ -227,8 +235,14 @@ extern struct resource * __request_region(struct resource 
*,
resource_size_t n,
const char *name, int flags);
  
+extern struct resource *__request_declared_region(struct resource *parent,

+   struct resource *res, int flags);
+
  /* Compatibility cruft */
  #define release_region(start,n)   __release_region(&ioport_resource, 
(start), (n))
+#define release_declared_region(res)   __release_region(&ioport_resource, \
+   (res)->start, \
+   (res)->end - (res)->start + 1)
  #define release_mem_region(start,n)   __release_region(&iomem_resource, 
(start), (n))
  
  extern void __release_region(struct resource *, resource_size_t,

diff --git a/kernel/resource.c b/kernel/resource.c
index 9b5f044..2be7029 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -184,6 +184,9 @@ static void free_resource(struct resource *res)
if (!res)
return;
  
+	if (!(res->flags & IORESOURCE_ALLOCATED))

+   return;
+
if (!PageSlab(virt_to_head_page(res))) {
spin_lock(&bootmem_resource_lock);
res->sibling = bootmem_resource_free;
@@ -210,6 +213,8 @@ static struct resource *alloc_resource(gfp_t flags)
else
res = kzalloc(sizeof(struct resource), flags);
  
+	res->flags = IORESOURCE_ALLOCATED;

+
return res;
  }
  
@@ -1110,8 +1115,19 @@ resource_size_t resource_alignment(struct resource *res)

   * the IO flag meanings (busy etc).
   *
   * request_region creates a new busy region.
+ * The resource descriptor is allocated by this function.
+ *
+ * request_declared_region creates a new busy region
+ * described in an existing resource descriptor.
+ *
+ * request_muxed_region creates a new shared busy region.
+ * The resource descriptor is allocated by this function.
+ *
+ * request_declared_muxed_region creates a new shared busy region
+ * de

Re: [PATCH 3/5 v4] usb: pci-quirks: Protect the I/O port pair of SB800

2017-07-14 Thread Boszormenyi Zoltan

2017-06-22 15:21 keltezéssel, Zoltán Böszörményi írta:

This patch uses the previously introduced macro called
request_declared_muxed_region() to synchronize access to
the I/O port pair 0xcd6 / 0xcd7 on SB800.

These I/O ports are also used by i2c-piix4 and sp5100_tco,
so synchronization is necessary. The other drivers will also
be modified to use the new macro in subsequest patched.

v1: Started with a common mutex in a C source file.

v2: Declared the common mutex in drivers/usb/host/pci-quirks.c
 instead of in a common C file.

v3: Switched to using the new request_declared_muxed_region
 macro.

v4: Fixed checkpatch.pl warnings and use the new
 release_declared_region() macro.

Signed-off-by: Zoltán Böszörményi 
---
  drivers/usb/host/pci-quirks.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index a9a1e4c..593942a 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -279,6 +279,8 @@ bool usb_amd_prefetch_quirk(void)
  }
  EXPORT_SYMBOL_GPL(usb_amd_prefetch_quirk);
  
+static struct resource sb800_res = DEFINE_RES_IO_NAMED(0xcd6, 2, "SB800 USB");

+
  /*
   * The hardware normally enables the A-link power management feature, which
   * lets the system lower the power consumption in idle states.
@@ -314,11 +316,13 @@ static void usb_amd_quirk_pll(int disable)
if (amd_chipset.sb_type.gen == AMD_CHIPSET_SB800 ||
amd_chipset.sb_type.gen == AMD_CHIPSET_HUDSON2 ||
amd_chipset.sb_type.gen == AMD_CHIPSET_BOLTON) {
+   request_declared_muxed_region(&sb800_res);
outb_p(AB_REG_BAR_LOW, 0xcd6);
addr_low = inb_p(0xcd7);
outb_p(AB_REG_BAR_HIGH, 0xcd6);
addr_high = inb_p(0xcd7);
addr = addr_high << 8 | addr_low;
+   release_declared_region(&sb800_res);
  
  		outl_p(0x30, AB_INDX(addr));

outl_p(0x40, AB_DATA(addr));





Re: [PATCH 5/5 v4] watchdog: sp5100_tco: Use request_declared_muxed_region()

2017-07-14 Thread Boszormenyi Zoltan

2017-06-22 15:21 keltezéssel, Zoltán Böszörményi írta:

Use the new request_declared_muxed_region() macro to synchronize
accesses to the SB800 I/O port pair (0xcd6 / 0xcd7) with the
PCI quirk for isochronous USB transfers and with the i2c-piix4
driver.

At the same time, remove the long lifetime request_region() call
to reserve these I/O ports, similarly to i2c-piix4 so the code is
now uniform across the three drivers.

v1: Started with a common mutex in a C source file.

v2: Referenced the common mutex from drivers/usb/host/pci-quirks.c

v3: Switched to using the new request_declared_muxed_region
 macro.

v4: Fixed checkpatch.pl warnings and use the new
 release_declared_region() macro.

Signed-off-by: Zoltán Böszörményi 
---
  drivers/watchdog/sp5100_tco.c | 28 +++-
  1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 028618c..cb42b72 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -48,7 +48,6 @@
  static u32 tcobase_phys;
  static u32 tco_wdt_fired;
  static void __iomem *tcobase;
-static unsigned int pm_iobase;
  static DEFINE_SPINLOCK(tco_lock); /* Guards the hardware */
  static unsigned long timer_alive;
  static char tco_expect_close;
@@ -70,6 +69,11 @@ module_param(nowayout, bool, 0);
  MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started."
" (default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
  
+/* synchronized access to the I/O port pair */

+static struct resource sp5100_res = DEFINE_RES_IO_NAMED(SB800_IO_PM_INDEX_REG,
+   SP5100_PM_IOPORTS_SIZE,
+   TCO_MODULE_NAME);
+
  /*
   * Some TCO specific functions
   */
@@ -139,6 +143,7 @@ static void tco_timer_enable(void)
if (!tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
/* For SB800 or later */
/* Set the Watchdog timer resolution to 1 sec */
+   request_declared_muxed_region(&sp5100_res);
outb(SB800_PM_WATCHDOG_CONFIG, SB800_IO_PM_INDEX_REG);
val = inb(SB800_IO_PM_DATA_REG);
val |= SB800_PM_WATCHDOG_SECOND_RES;
@@ -150,6 +155,7 @@ static void tco_timer_enable(void)
val |= SB800_PCI_WATCHDOG_DECODE_EN;
val &= ~SB800_PM_WATCHDOG_DISABLE;
outb(val, SB800_IO_PM_DATA_REG);
+   release_declared_region(&sp5100_res);
} else {
/* For SP5100 or SB7x0 */
/* Enable watchdog decode bit */
@@ -164,11 +170,13 @@ static void tco_timer_enable(void)
   val);
  
  		/* Enable Watchdog timer and set the resolution to 1 sec */

+   request_declared_muxed_region(&sp5100_res);
outb(SP5100_PM_WATCHDOG_CONTROL, SP5100_IO_PM_INDEX_REG);
val = inb(SP5100_IO_PM_DATA_REG);
val |= SP5100_PM_WATCHDOG_SECOND_RES;
val &= ~SP5100_PM_WATCHDOG_DISABLE;
outb(val, SP5100_IO_PM_DATA_REG);
+   release_declared_region(&sp5100_res);
}
  }
  
@@ -361,16 +369,10 @@ static unsigned char sp5100_tco_setupdevice(void)

base_addr = SB800_PM_WATCHDOG_BASE;
}
  
-	/* Request the IO ports used by this driver */

-   pm_iobase = SP5100_IO_PM_INDEX_REG;
-   if (!request_region(pm_iobase, SP5100_PM_IOPORTS_SIZE, dev_name)) {
-   pr_err("I/O address 0x%04x already in use\n", pm_iobase);
-   goto exit;
-   }
-
/*
 * First, Find the watchdog timer MMIO address from indirect I/O.
 */
+   request_declared_muxed_region(&sp5100_res);
outb(base_addr+3, index_reg);
val = inb(data_reg);
outb(base_addr+2, index_reg);
@@ -380,6 +382,7 @@ static unsigned char sp5100_tco_setupdevice(void)
outb(base_addr+0, index_reg);
/* Low three bits of BASE are reserved */
val = val << 8 | (inb(data_reg) & 0xf8);
+   release_declared_region(&sp5100_res);
  
  	pr_debug("Got 0x%04x from indirect I/O\n", val);
  
@@ -400,6 +403,7 @@ static unsigned char sp5100_tco_setupdevice(void)

  SP5100_SB_RESOURCE_MMIO_BASE, &val);
} else {
/* Read SBResource_MMIO from AcpiMmioEn(PM_Reg: 24h) */
+   request_declared_muxed_region(&sp5100_res);
outb(SB800_PM_ACPI_MMIO_EN+3, SB800_IO_PM_INDEX_REG);
val = inb(SB800_IO_PM_DATA_REG);
outb(SB800_PM_ACPI_MMIO_EN+2, SB800_IO_PM_INDEX_REG);
@@ -408,6 +412,7 @@ static unsigned char sp5100_tco_setupdevice(void)
val = val << 8 | inb(SB800_IO_PM_DATA_REG);
outb(SB800_PM_ACPI_MMIO_EN+0, SB800_IO_PM_INDEX_REG);
val = val << 8 | inb(SB800_IO_PM_DATA_REG);
+   release_declared_region(&sp

Re: A udev rule to serve the change event of ACPI container?

2017-07-14 Thread Michal Hocko
On Thu 13-07-17 20:45:21, Joey Lee wrote:
> On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote:
> > On Thu 13-07-17 14:58:06, Joey Lee wrote:
[...]
> > > If BIOS emits ejection event for a ACPI0004 container, someone needs
> > > to handle the offline/eject jobs of container. Either kernel or user
> > > space.
> > > 
> > > Only sending uevent to individual child device can simplify udev rule,
> > > but it also means that the kernel needs to offline/eject container
> > > after all children devices are offlined.
> > 
> > Why cannot kernel send this eject command to the BIOS if the whole
> > container is offline? If it is not then the kernel would send EBUSY to
> 
> Current kernel container hot-remove process:
> 
>   BIOS -> SCI event -> Kernel ACPI -> uevent -> userland
>   
> Then, kernel just calls _OST to expose state to BIOS, then process is
> stopped. Kernel doesn't wait there for userland to offline each child
> devices. Either BIOS or userland needs to trigger the container
> ejection.
> 
> > container is offline? If it is not then the kernel would send EBUSY to
> > the BIOS and BIOS would have to retry after some timeout. Or is it a
> 
> The d429e5c122 patch is merged to mainline. So kernel will send
> DEVICE_BUSY to BIOS after it emits uevent to userland. BIOS can choice
> to apply the retry approach until OS returns process failure exactly or
> BIOS timeout.
> 
> > problem that currently implemented BIOS firmwares do not implement this
> > retry?
> 
> Yes, we should consider the behavior of old BIOS. Old BIOS doesn't
> retry/resend the ejection event. So kernel or userland need to take the
> retry job. Obviously userland runs the retry since the caa73ea15 patch
> is merged.
> 
> IMHO there have two different expectation from user space application.
> 
> Applications like DVD player or Burner expect that kernel should
> info userspace for the ejection, then application can do their cleaning
> job and re-trigger ejection from userland.

I am not sure I understand the DVD example because I do not see how it
fits into the container and online/offline scenario.

> But, some other applications like database don't want that their service
> be stopped when the devices offline/eject. The hot-remove sholud be done by
> kernel transparently.
> 
> We need a way for fill two situations.

Hmm, so can we trigger the eject from the _kernel_ when the last child
is offlined?
-- 
Michal Hocko
SUSE Labs


[RESEND PATCH] nvmem: rockchip-efuse: amend compatible rk322x-efuse to rk3228-efuse

2017-07-14 Thread Frank Wang
As the comments from Heiko Stuebner  that compatible
should not contain any placeholders, this patch fix it for rk3228 SoC.

Note that this is a fix for v4.13, due to fixing the current non-standard
binding name that should not become part of an official kernel release.

Signed-off-by: Frank Wang 
Acked-by: Rob Herring 
Reviewed-by: Heiko Stuebner 
---
 Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt | 2 +-
 drivers/nvmem/rockchip-efuse.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt 
b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt
index 194926f..1ff02afd 100644
--- a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt
+++ b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt
@@ -4,7 +4,7 @@ Required properties:
 - compatible: Should be one of the following.
   - "rockchip,rk3066a-efuse" - for RK3066a SoCs.
   - "rockchip,rk3188-efuse" - for RK3188 SoCs.
-  - "rockchip,rk322x-efuse" - for RK322x SoCs.
+  - "rockchip,rk3228-efuse" - for RK3228 SoCs.
   - "rockchip,rk3288-efuse" - for RK3288 SoCs.
   - "rockchip,rk3399-efuse" - for RK3399 SoCs.
 - reg: Should contain the registers location and exact eFuse size
diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c
index a0d4ede..63e3eb5 100644
--- a/drivers/nvmem/rockchip-efuse.c
+++ b/drivers/nvmem/rockchip-efuse.c
@@ -170,7 +170,7 @@ static const struct of_device_id rockchip_efuse_match[] = {
.data = (void *)&rockchip_rk3288_efuse_read,
},
{
-   .compatible = "rockchip,rk322x-efuse",
+   .compatible = "rockchip,rk3228-efuse",
.data = (void *)&rockchip_rk3288_efuse_read,
},
{
-- 
2.0.0




Re: [PATCH v3 4/7] libsas: add sas event wait-complete support

2017-07-14 Thread John Garry

On 14/07/2017 07:51, Hannes Reinecke wrote:

 #ifdef CONFIG_SCSI_SAS_HOST_SMP
>  extern int sas_smp_host_handler(struct Scsi_Host *shost, struct request *req,
>struct request *rsp);
> diff --git a/drivers/scsi/libsas/sas_port.c b/drivers/scsi/libsas/sas_port.c
> index 9326628..d589adb 100644
> --- a/drivers/scsi/libsas/sas_port.c
> +++ b/drivers/scsi/libsas/sas_port.c
> @@ -191,7 +191,9 @@ static void sas_form_port(struct asd_sas_phy *phy)
>if (si->dft->lldd_port_formed)
>si->dft->lldd_port_formed(phy);
>
> +  sas_port_wait_init(port);
>sas_discover_event(phy->port, DISCE_DISCOVER_DOMAIN);
> +  sas_port_wait_completion(port);
>  }
>
>  /**
> @@ -218,7 +220,9 @@ void sas_deform_port(struct asd_sas_phy *phy, int gone)
>dev->pathways--;
>


Hannes thanks for checking.


>if (port->num_phys == 1) {
> +  sas_port_wait_init(port);
>sas_unregister_domain_devices(port, gone);
> +  sas_port_wait_completion(port);
>sas_port_delete(port->port);
>port->port = NULL;
>} else {

I would rather use the standard on-stack completion here;
like this:

DECLARE_COMPLETION_ONSTACK(complete);
port->completion = &complete;
sas_unregister_domain_devices(port, gone);
wait_for_completion(&complete);
sas_port_delete(port->port);

which would simplify the above helpers to:

static inline void sas_port_put(struct asd_sas_port *port)
{
if (port->completion)
kref_put(&port->ref, sas_complete_event);
}

and you could do away with the 'is_sync' helper.



I did wonder if we could avoid using completion altogether and just 
flush the respective queue which the work item is being processed in. 
But, due to the intricacy of SCSI/ATA EH, and since we still use shost 
workqueue for the libsas hotplug processing, maybe it best to keep it 
straightforward and keep using completions.


Anyway, The idea to declare the completion on the stack seems sound. 
And, for patch 6/7, I don't think the is_sync element is even required 
without any change to declaration of completion in struct 
sas_discovery_event.


John


Cheers,

Hannes
--





Re: [PATCH 2/4] thermal: imx: Add support for reading OCOTP through nvmem

2017-07-14 Thread Srinivas Kandagatla



On 12/07/17 07:36, Shawn Guo wrote:
  
+static int nvmem_cell_read_u32(struct device* dev, const char *cell_id, u32 *val)

+{
+   struct nvmem_cell *cell;
+   void *buf;
+   size_t len;
+
+   cell = nvmem_cell_get(dev, cell_id);
+   if (IS_ERR(cell))
+   return PTR_ERR(cell);
+
+   buf = nvmem_cell_read(cell, &len);
+   if (IS_ERR(buf)) {
+   nvmem_cell_put(cell);
+   return PTR_ERR(buf);
+   }
+   if (len != sizeof(*val)) {
+   kfree(buf);
+   nvmem_cell_put(cell);
+   return -EINVAL;
+   }
+   memcpy(val, buf, sizeof(*val));


This can overflow the memory allocated to val, we should be careful here 
not to do so.
limit this to sizeof(u32) should be good. Also add some sanity checks to 
make sure that len is atleast 4 bytes.




+
+   kfree(buf);
+   nvmem_cell_put(cell);
+   return 0;
+}

The function looks nothing IMX specific, and could be a nvmem core
function?

@Srinivas, thoughts?

Yep, this function looks generic, can be moved to nvmem layer.

Thanks,
srini


Re: [PATCH 4/4] drm/sun4i: make sure we don't have a commit pending

2017-07-14 Thread Chen-Yu Tsai
Hi,

On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard
 wrote:
> In the earlier display engine designs, any register access while a commit
> is pending is forbidden.
>
> One of the symptoms is that reading a register will return another, random,
> register value which can lead to register corruptions if we ever do a
> read/modify/write cycle.

Alternatively, if changes to the backend (layers) are guaranteed to happen
while the CRTC is disabled (which seems to be the case after looking at
drm_atomic_helper_commit_planes and drm_atomic_helper_commit_tail), we
could just turn on register auto-commit all the time and not deal with
this.

ChenYu

>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_backend.c | 14 ++
>  drivers/gpu/drm/sun4i/sun4i_crtc.c|  1 +
>  2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index cf480218daa5..ce1f40f7511e 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -67,6 +67,19 @@ static void sun4i_backend_commit(struct sunxi_engine 
> *engine)
>  SUN4I_BACKEND_REGBUFFCTL_LOADCTL);
>  }
>
> +static int sun4i_backend_commit_poll(struct sunxi_engine *engine)
> +{
> +   u32 val;
> +
> +   DRM_DEBUG_DRIVER("Polling for the commit to end\n");
> +
> +   return regmap_read_poll_timeout(engine->regs,
> +   SUN4I_BACKEND_REGBUFFCTL_REG,
> +   val,
> +   !(val & 
> SUN4I_BACKEND_REGBUFFCTL_LOADCTL),
> +   100, 5);
> +}
> +
>  void sun4i_backend_layer_enable(struct sun4i_backend *backend,
> int layer, bool enable)
>  {
> @@ -330,6 +343,7 @@ static int sun4i_backend_of_get_id(struct device_node 
> *node)
>
>  static const struct sunxi_engine_ops sun4i_backend_engine_ops = {
> .commit = sun4i_backend_commit,
> +   .commit_poll= sun4i_backend_commit_poll,
> .layers_init= sun4i_layers_init,
> .apply_color_correction = 
> sun4i_backend_apply_color_correction,
> .disable_color_correction   = 
> sun4i_backend_disable_color_correction,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c 
> b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> index 2eba1d8639d8..31550493fa1d 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> @@ -34,6 +34,7 @@ static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state)
>  {
> struct sun4i_crtc *scrtc = drm_crtc_to_sun4i_crtc(crtc);
> +   struct sunxi_engine *engine = scrtc->engine;
> struct drm_device *dev = crtc->dev;
> unsigned long flags;
>
> --
> git-series 0.9.1


[GIT PULL] sound fixes for 4.13-rc1

2017-07-14 Thread Takashi Iwai
Linus,

please pull sound fixes for v4.13-rc1 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
tags/sound-fix-4.13-rc1

The topmost commit is b9091b1c654953cc9615f282704a6df8e31549cf



sound fixes for 4.13-rc1

Small last-minute fixes for 4.13-rc1: a couple of PCM fixes for m68k,
a cleanup work for legacy ISA msnd driver, and a few HD-audio new IDs
and quirks.



Geert Uytterhoeven (1):
  ALSA: pcm: Protect call to dma_mmap_coherent() by check for HAS_DMA

Hui Wang (1):
  ALSA: hda/realtek - change the location for one of two front microphones

Joe Perches (1):
  ALSA: opl4: Move inline before return type

Kailang Yang (1):
  ALSA: hda/realtek - New codec device ID for ALC1220

Subhransu S. Prusty (1):
  ALSA: hda - Add hdmi id for a Geminilake variant

Takashi Iwai (2):
  ALSA: msnd: Optimize / harden DSP and MIDI loops
  ALSA: pcm: Simplify check for dma_mmap_coherent() availability

---
 sound/core/pcm_native.c|  8 +++-
 sound/drivers/opl4/opl4_lib.c  |  2 +-
 sound/isa/msnd/msnd_midi.c | 30 +++---
 sound/isa/msnd/msnd_pinnacle.c | 23 ---
 sound/pci/hda/patch_hdmi.c |  5 -
 sound/pci/hda/patch_realtek.c  | 16 
 6 files changed, 51 insertions(+), 33 deletions(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index b3d5bed75029..22995cb3bd44 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -238,10 +238,8 @@ static bool hw_support_mmap(struct snd_pcm_substream 
*substream)
 {
if (!(substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP))
return false;
-   /* check architectures that return -EINVAL from dma_mmap_coherent() */
-   /* FIXME: this should be some global flag */
-#if defined(CONFIG_C6X) || defined(CONFIG_FRV) || defined(CONFIG_MN10300) ||\
-   defined(CONFIG_PARISC) || defined(CONFIG_XTENSA)
+   /* architecture supports dma_mmap_coherent()? */
+#if defined(CONFIG_ARCH_NO_COHERENT_DMA_MMAP) || !defined(CONFIG_HAS_DMA)
if (!substream->ops->mmap &&
substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
return false;
@@ -3502,7 +3500,7 @@ int snd_pcm_lib_default_mmap(struct snd_pcm_substream 
*substream,
}
 #endif /* CONFIG_GENERIC_ALLOCATOR */
 #ifndef CONFIG_X86 /* for avoiding warnings arch/x86/mm/pat.c */
-   if (!substream->ops->page &&
+   if (IS_ENABLED(CONFIG_HAS_DMA) && !substream->ops->page &&
substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
return dma_mmap_coherent(substream->dma_buffer.dev.dev,
 area,
diff --git a/sound/drivers/opl4/opl4_lib.c b/sound/drivers/opl4/opl4_lib.c
index bc345d564f8d..db76a5bf2bd2 100644
--- a/sound/drivers/opl4/opl4_lib.c
+++ b/sound/drivers/opl4/opl4_lib.c
@@ -29,7 +29,7 @@ MODULE_AUTHOR("Clemens Ladisch ");
 MODULE_DESCRIPTION("OPL4 driver");
 MODULE_LICENSE("GPL");
 
-static void inline snd_opl4_wait(struct snd_opl4 *opl4)
+static inline void snd_opl4_wait(struct snd_opl4 *opl4)
 {
int timeout = 10;
while ((inb(opl4->fm_port) & OPL4_STATUS_BUSY) && --timeout > 0)
diff --git a/sound/isa/msnd/msnd_midi.c b/sound/isa/msnd/msnd_midi.c
index 912b5a9ccbab..013d8d1170fe 100644
--- a/sound/isa/msnd/msnd_midi.c
+++ b/sound/isa/msnd/msnd_midi.c
@@ -120,24 +120,24 @@ void snd_msndmidi_input_read(void *mpuv)
unsigned long flags;
struct snd_msndmidi *mpu = mpuv;
void *pwMIDQData = mpu->dev->mappedbase + MIDQ_DATA_BUFF;
+   u16 head, tail, size;
 
spin_lock_irqsave(&mpu->input_lock, flags);
-   while (readw(mpu->dev->MIDQ + JQS_wTail) !=
-  readw(mpu->dev->MIDQ + JQS_wHead)) {
-   u16 wTmp, val;
-   val = readw(pwMIDQData + 2 * readw(mpu->dev->MIDQ + JQS_wHead));
-
-   if (test_bit(MSNDMIDI_MODE_BIT_INPUT_TRIGGER,
-&mpu->mode))
-   snd_rawmidi_receive(mpu->substream_input,
-   (unsigned char *)&val, 1);
-
-   wTmp = readw(mpu->dev->MIDQ + JQS_wHead) + 1;
-   if (wTmp > readw(mpu->dev->MIDQ + JQS_wSize))
-   writew(0,  mpu->dev->MIDQ + JQS_wHead);
-   else
-   writew(wTmp,  mpu->dev->MIDQ + JQS_wHead);
+   head = readw(mpu->dev->MIDQ + JQS_wHead);
+   tail = readw(mpu->dev->MIDQ + JQS_wTail);
+   size = readw(mpu->dev->MIDQ + JQS_wSize);
+   if (head > size || tail > size)
+   goto out;
+   while (head != tail) {
+   unsigned char val = readw(pwMIDQData + 2 * head);
+
+   if (test_bit(MSNDMIDI_MODE_BIT_INPUT_TRIGGER, &mpu->mode))
+   snd_rawmidi_recei

[PATCH] [media] vimc: set id_table for platform drivers

2017-07-14 Thread Javier Martinez Canillas
The vimc platform drivers define a platform device ID table but these
are not set to the .id_table field in the platform driver structure.

So the platform device ID table is only used to fill the aliases in
the module but are not used for matching (works because the platform
subsystem fallbacks to the driver's name if no .id_table is set).

But this also means that the platform device ID table isn't used if
the driver is built-in, which leads to the following build warning:

This causes the following build warnings when the driver is built-in:

drivers/media/platform/vimc//vimc-capture.c:528:40: warning: 
‘vimc_cap_driver_ids’ defined but not used [-Wunused-const-variable=]
 static const struct platform_device_id vimc_cap_driver_ids[] = {
^~~
drivers/media/platform/vimc//vimc-debayer.c:588:40: warning: 
‘vimc_deb_driver_ids’ defined but not used [-Wunused-const-variable=]
 static const struct platform_device_id vimc_deb_driver_ids[] = {
^~~
drivers/media/platform/vimc//vimc-scaler.c:442:40: warning: 
‘vimc_sca_driver_ids’ defined but not used [-Wunused-const-variable=]
 static const struct platform_device_id vimc_sca_driver_ids[] = {
^~~
drivers/media/platform/vimc//vimc-sensor.c:376:40: warning: 
‘vimc_sen_driver_ids’ defined but not used [-Wunused-const-variable=]
 static const struct platform_device_id vimc_sen_driver_ids[] = {
^~~

Reported-by: Mauro Carvalho Chehab 
Suggested-by: Sakari Ailus 
Signed-off-by: Javier Martinez Canillas 

---

 drivers/media/platform/vimc/vimc-capture.c | 15 ---
 drivers/media/platform/vimc/vimc-debayer.c | 15 ---
 drivers/media/platform/vimc/vimc-scaler.c  | 15 ---
 drivers/media/platform/vimc/vimc-sensor.c  | 15 ---
 4 files changed, 32 insertions(+), 28 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index 14cb32e21130..88a1e5670c72 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -517,21 +517,22 @@ static int vimc_cap_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct platform_device_id vimc_cap_driver_ids[] = {
+   {
+   .name   = VIMC_CAP_DRV_NAME,
+   },
+   { }
+};
+
 static struct platform_driver vimc_cap_pdrv = {
.probe  = vimc_cap_probe,
.remove = vimc_cap_remove,
+   .id_table   = vimc_cap_driver_ids,
.driver = {
.name   = VIMC_CAP_DRV_NAME,
},
 };
 
-static const struct platform_device_id vimc_cap_driver_ids[] = {
-   {
-   .name   = VIMC_CAP_DRV_NAME,
-   },
-   { }
-};
-
 module_platform_driver(vimc_cap_pdrv);
 
 MODULE_DEVICE_TABLE(platform, vimc_cap_driver_ids);
diff --git a/drivers/media/platform/vimc/vimc-debayer.c 
b/drivers/media/platform/vimc/vimc-debayer.c
index 35b15bd4d61d..033a131f67af 100644
--- a/drivers/media/platform/vimc/vimc-debayer.c
+++ b/drivers/media/platform/vimc/vimc-debayer.c
@@ -577,21 +577,22 @@ static int vimc_deb_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct platform_device_id vimc_deb_driver_ids[] = {
+   {
+   .name   = VIMC_DEB_DRV_NAME,
+   },
+   { }
+};
+
 static struct platform_driver vimc_deb_pdrv = {
.probe  = vimc_deb_probe,
.remove = vimc_deb_remove,
+   .id_table   = vimc_deb_driver_ids,
.driver = {
.name   = VIMC_DEB_DRV_NAME,
},
 };
 
-static const struct platform_device_id vimc_deb_driver_ids[] = {
-   {
-   .name   = VIMC_DEB_DRV_NAME,
-   },
-   { }
-};
-
 module_platform_driver(vimc_deb_pdrv);
 
 MODULE_DEVICE_TABLE(platform, vimc_deb_driver_ids);
diff --git a/drivers/media/platform/vimc/vimc-scaler.c 
b/drivers/media/platform/vimc/vimc-scaler.c
index fe77505d2679..0a3e086e12f3 100644
--- a/drivers/media/platform/vimc/vimc-scaler.c
+++ b/drivers/media/platform/vimc/vimc-scaler.c
@@ -431,21 +431,22 @@ static int vimc_sca_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct platform_device_id vimc_sca_driver_ids[] = {
+   {
+   .name   = VIMC_SCA_DRV_NAME,
+   },
+   { }
+};
+
 static struct platform_driver vimc_sca_pdrv = {
.probe  = vimc_sca_probe,
.remove = vimc_sca_remove,
+   .id_table   = vimc_sca_driver_ids,
.driver = {
.name   = VIMC_SCA_DRV_NAME,
},
 };
 
-static const struct platform_device_id vimc_sca_driver_ids[] = {
-   {
-   .name   = VIMC_SCA_DRV_NAME,
-   },
-   { }
-};
-
 module_platform_dr

[GIT PULL] Please pull *a* befs change for Linux 4.13

2017-07-14 Thread Luis de Bethencourt

Hi Linus,

Very little activity in the befs file system this time since I'm busy
settling into a new job.
Hence the new-car-smell shiny address [0].

Merged one patch from Tommy Nguyen related to documentation.

Thank you very much,
Luis

[0] https://lkml.org/lkml/2017/7/9/37


The following changes since commit 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c:

  Linux 4.12 (2017-07-02 16:07:02 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/luisbg/linux-befs.git 
tags/befs-v4.13-rc1


for you to fetch changes up to 799ce1dbb9bba56ff21733838a05070787fdcde5:

  befs: add kernel-doc formatting for befs_bt_read_super() (2017-07-09 
10:42:50 +0100)



befs fixes for 4.13-rc1


Tommy Nguyen (1):
  befs: add kernel-doc formatting for befs_bt_read_super()

 fs/befs/btree.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)


Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

2017-07-14 Thread Jani Nikula
On Thu, 13 Jul 2017, Stéphane Marchesin  wrote:
> So, if you think this is wrong, can you fix this warning in a way that
> you'd like?

As I replied previously [1], with more background, fixing the warnings
properly, in a way that actually improves the code instead of making it
worse, would mean a bunch of churn that's not just purely mechanical
conversion.

Unless you can point out a bug which is actually caused by mixing the
types (which is mostly intentional, see the background) I have a hard
time telling people this should be a priority. Definitely something we'd
like to do in the long run and pedantically correct (and I tend to
prefer code that way) but we certainly have more important things to do.

BR,
Jani.

[1] http://mid.mail-archive.com/87wp9rahjy.fsf@intel.com


-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH] ppdev: remove unused ROUND_UP macro

2017-07-14 Thread Guoqing Jiang
This macro is not used after commit 3b9ab374a1e6
("ppdev: convert to y2038 safe"), so let's remove
it.

Signed-off-by: Guoqing Jiang 
---
 drivers/char/ppdev.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/char/ppdev.c b/drivers/char/ppdev.c
index 3e73bcd..d256110 100644
--- a/drivers/char/ppdev.c
+++ b/drivers/char/ppdev.c
@@ -101,9 +101,6 @@ static DEFINE_IDA(ida_index);
 #define PP_BUFFER_SIZE 1024
 #define PARDEVICE_MAX 8
 
-/* ROUND_UP macro from fs/select.c */
-#define ROUND_UP(x,y) (((x)+(y)-1)/(y))
-
 static DEFINE_MUTEX(pp_do_mutex);
 
 /* define fixed sized ioctl cmd for y2038 migration */
-- 
2.6.6



[RESEND PATCH v4 2/2] i2c: Add Spreadtrum I2C controller driver

2017-07-14 Thread Baolin Wang
This patch adds the I2C controller driver for Spreadtrum SC9860 platform.

Signed-off-by: Baolin Wang 
Reviewed-by: Andy Shevchenko 
---
Changes since v3:
 - Use SPDX-License-Identifier tag instead.

Changes since v2:
 - Remove some redundant comments and parens.
 - Define macros instead of magic number.
 - Add some comments to explain clock formula.
 - Change of_clk_get_by_name() to devm_clk_get().
 - Deal with other frequency.
 - Change register definiton to low case.
 - Change is_last_msg to boolean.
 - Other optimization.

Changes sice v1:
 - Power on I2C device in probe().
 - Remove redundant macros and usb __maybe_unused.
 - Remove redundant 'of_match_ptr'.
 - Modify return values and check the return value for 'clk_prepare_enable'.
---
 drivers/i2c/busses/Kconfig|7 +
 drivers/i2c/busses/Makefile   |1 +
 drivers/i2c/busses/i2c-sprd.c |  676 +
 3 files changed, 684 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-sprd.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 8adc0f1..86476b9 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -877,6 +877,13 @@ config I2C_SIRF
  This driver can also be built as a module.  If so, the module
  will be called i2c-sirf.
 
+config I2C_SPRD
+   bool "Spreadtrum I2C interface"
+   depends on ARCH_SPRD
+   help
+ If you say yes to this option, support will be included for the
+ Spreadtrum I2C interface.
+
 config I2C_ST
tristate "STMicroelectronics SSC I2C support"
depends on ARCH_STI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 30b6085..dd46c21 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_I2C_SH7760)  += i2c-sh7760.o
 obj-$(CONFIG_I2C_SH_MOBILE)+= i2c-sh_mobile.o
 obj-$(CONFIG_I2C_SIMTEC)   += i2c-simtec.o
 obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o
+obj-$(CONFIG_I2C_SPRD) += i2c-sprd.o
 obj-$(CONFIG_I2C_ST)   += i2c-st.o
 obj-$(CONFIG_I2C_STM32F4)  += i2c-stm32f4.o
 obj-$(CONFIG_I2C_STU300)   += i2c-stu300.o
diff --git a/drivers/i2c/busses/i2c-sprd.c b/drivers/i2c/busses/i2c-sprd.c
new file mode 100644
index 000..4193f4d
--- /dev/null
+++ b/drivers/i2c/busses/i2c-sprd.c
@@ -0,0 +1,676 @@
+/*
+ * Copyright (C) 2017 Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define I2C_CTL0x00
+#define I2C_ADDR_CFG   0x04
+#define I2C_COUNT  0x08
+#define I2C_RX 0x0c
+#define I2C_TX 0x10
+#define I2C_STATUS 0x14
+#define I2C_HSMODE_CFG 0x18
+#define I2C_VERSION0x1c
+#define ADDR_DVD0  0x20
+#define ADDR_DVD1  0x24
+#define ADDR_STA0_DVD  0x28
+#define ADDR_RST   0x2c
+
+/* I2C_CTL */
+#define STP_EN BIT(20)
+#define FIFO_AF_LVL_MASK   GENMASK(19, 16)
+#define FIFO_AF_LVL16
+#define FIFO_AE_LVL_MASK   GENMASK(15, 12)
+#define FIFO_AE_LVL12
+#define I2C_DMA_EN BIT(11)
+#define FULL_INTEN BIT(10)
+#define EMPTY_INTENBIT(9)
+#define I2C_DVD_OPTBIT(8)
+#define I2C_OUT_OPTBIT(7)
+#define I2C_TRIM_OPT   BIT(6)
+#define I2C_HS_MODEBIT(4)
+#define I2C_MODE   BIT(3)
+#define I2C_EN BIT(2)
+#define I2C_INT_EN BIT(1)
+#define I2C_START  BIT(0)
+
+/* I2C_STATUS */
+#define SDA_IN BIT(21)
+#define SCL_IN BIT(20)
+#define FIFO_FULL  BIT(4)
+#define FIFO_EMPTY BIT(3)
+#define I2C_INTBIT(2)
+#define I2C_RX_ACK BIT(1)
+#define I2C_BUSY   BIT(0)
+
+/* ADDR_RST */
+#define I2C_RSTBIT(0)
+
+#define I2C_FIFO_DEEP  12
+#define I2C_FIFO_FULL_THLD 15
+#define I2C_FIFO_EMPTY_THLD4
+#define I2C_DATA_STEP  8
+#define I2C_ADDR_DVD0_CALC(high, low)  \
+   high) & GENMASK(15, 0)) << 16) | ((low) & GENMASK(15, 0)))
+#define I2C_ADDR_DVD1_CALC(high, low)  \
+   (((high) & GENMASK(31, 16)) | (((low) & GENMASK(31, 16)) >> 16))
+
+/* timeout (ms) for pm runtime autosuspend */
+#define SPRD_I2C_PM_TIMEOUT1000
+
+/* SPRD i2c data structure */
+struct sprd_i2c {
+   struct i2c_adapter adap;
+   struct device *dev;
+   void __iomem *base;
+   struct i2c_msg *msg;
+   struct clk *clk;
+   unsigned int src_clk;
+   unsigned int bus_freq;
+   struct completion complete;
+   u8 *buf;
+   u16 count;
+   int irq;
+   int err;
+};
+
+static void sprd_i2c_dump_reg(struct sprd_i2c *i2c_dev)
+{
+   dev_err(&i2c_d

Re: [PATCH] scsi: qedf: Limit number of CQs

2017-07-14 Thread Johannes Thumshirn

Looks good,
Reviewed-by: Johannes Thumshirn 
-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850


[RESEND PATCH v4 1/2] dt-bindings: i2c: Add Spreadtrum I2C controller documentation

2017-07-14 Thread Baolin Wang
This patch adds the binding documentation for Spreadtrum I2C
controller device.

Signed-off-by: Baolin Wang 
Acked-by: Rob Herring 
---
Changes since v3:
 - Add Ack from RobH.

Changes since v2:
 - Change compatible strings to be SoC specific.

Changes since v1:
 - No updates.
---
 Documentation/devicetree/bindings/i2c/i2c-sprd.txt |   31 
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sprd.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-sprd.txt 
b/Documentation/devicetree/bindings/i2c/i2c-sprd.txt
new file mode 100644
index 000..60b7cda
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-sprd.txt
@@ -0,0 +1,31 @@
+I2C for Spreadtrum platforms
+
+Required properties:
+- compatible: Should be "sprd,sc9860-i2c".
+- reg: Specify the physical base address of the controller and length
+  of memory mapped region.
+- interrupts: Should contain I2C interrupt.
+- clock-names: Should contain following entries:
+  "i2c" for I2C clock,
+  "source" for I2C source (parent) clock,
+  "enable" for I2C module enable clock.
+- clocks: Should contain a clock specifier for each entry in clock-names.
+- clock-frequency: Constains desired I2C bus clock frequency in Hz.
+- #address-cells: Should be 1 to describe address cells for I2C device address.
+- #size-cells: Should be 0 means no size cell for I2C device address.
+
+Optional properties:
+- Child nodes conforming to I2C bus binding
+
+Examples:
+i2c0: i2c@7050 {
+   compatible = "sprd,sc9860-i2c";
+   reg = <0 0x7050 0 0x1000>;
+   interrupts = ;
+   clock-names = "i2c", "source", "enable";
+   clocks = <&clk_i2c3>, <&ext_26m>, <&clk_ap_apb_gates 11>;
+   clock-frequency = <40>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+};
+
-- 
1.7.9.5



Re: "mm: use early_pfn_to_nid in page_ext_init" broken on some configurations?

2017-07-14 Thread Michal Hocko
On Fri 07-07-17 14:00:03, Vlastimil Babka wrote:
> On 07/04/2017 07:17 AM, Joonsoo Kim wrote:
> >> 
> >> Still, backporting b8f1a75d61d8 fixes this:
> >> 
> >> [1.538379] allocated 738197504 bytes of page_ext
> >> [1.539340] Node 0, zone  DMA: page owner found early allocated 0 
> >> pages
> >> [1.540179] Node 0, zoneDMA32: page owner found early allocated 33 
> >> pages
> >> [1.611173] Node 0, zone   Normal: page owner found early allocated 
> >> 96755 pages
> >> [1.683167] Node 1, zone   Normal: page owner found early allocated 
> >> 96575 pages
> >> 
> >> No panic, notice how it allocated more for page_ext, and found smaller 
> >> number of
> >> early allocated pages.
> >> 
> >> Now backporting fe53ca54270a on top:
> >> 
> >> [0.00] allocated 738197504 bytes of page_ext
> >> [0.00] Node 0, zone  DMA: page owner found early allocated 0 
> >> pages
> >> [0.00] Node 0, zoneDMA32: page owner found early allocated 33 
> >> pages
> >> [0.00] Node 0, zone   Normal: page owner found early allocated 
> >> 2842622 pages
> >> [0.00] Node 1, zone   Normal: page owner found early allocated 
> >> 3694362 pages
> >> 
> >> Again no panic, and same amount of page_ext usage. But the "early 
> >> allocated" numbers
> >> seem bogus to me. I think it's because init_pages_in_zone() is running and 
> >> inspecting
> >> struct pages that have not been yet initialized. It doesn't end up 
> >> crashing, but
> >> still doesn't seem correct?
> > 
> > Numbers looks sane to me. fe53ca54270a makes init_pages_in_zone()
> > called before page_alloc_init_late(). So, there would be many
> > uninitialized pages with PageReserved(). Page owner regarded these
> > PageReserved() page as allocated page.
> 
> That seems incorrect for two reasons:
> - init_pages_in_zone() actually skips PageReserved() pages
> - the pages don't have PageReserved() flag, until the deferred struct page 
> init
> thread processes them via deferred_init_memmap() -> __init_single_page() 
> AFAICS
> 
> Now I've found out why upstream reports much less early allocated pages than 
> our
> kernel. We're missing 9d43f5aec950 ("mm/page_owner: add zone range overlapping
> check") which adds a "page_zone(page) != zone" check. I think this only works
> because the pages are not initialized and thus have no nid/zone links. 
> Probably
> page_zone() only doesn't break because it's all zeroed. I don't think it's 
> safe
> to rely on this?

Yes, if anything PageReserved should be checked before the zone check.

-- 
Michal Hocko
SUSE Labs


[tip:x86/urgent] x86/platform/uv/BAU: Fix congested_response_us not taking effect

2017-07-14 Thread tip-bot for Justin Ernst
Commit-ID:  91b2082ee3382fd58b605f1c75c88dff2fd5769b
Gitweb: http://git.kernel.org/tip/91b2082ee3382fd58b605f1c75c88dff2fd5769b
Author: Justin Ernst 
AuthorDate: Thu, 13 Jul 2017 13:33:23 -0500
Committer:  Ingo Molnar 
CommitDate: Fri, 14 Jul 2017 10:23:04 +0200

x86/platform/uv/BAU: Fix congested_response_us not taking effect

Bug fix for the BAU tunable congested_cycles not being set to the user
defined value. Instead of referencing a global variable when deciding
on BAU shutdown, a node will reference its own tunable set
value ( cong_response_us). This results in the user set
tunable value congested_response_us taking effect correctly.

Signed-off-by: Justin Ernst 
Acked-by: Andrew Banman 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: mike.tra...@hpe.com
Cc: sivan...@hpe.com
Link: 
http://lkml.kernel.org/r/1499970803-282432-1-git-send-email-justin.er...@hpe.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/platform/uv/tlb_uv.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index d4a61dd..fd87591 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -40,7 +40,6 @@ static int timeout_base_ns[] = {
 static int timeout_us;
 static bool nobau = true;
 static int nobau_perm;
-static cycles_t congested_cycles;
 
 /* tunables: */
 static int max_concurr = MAX_BAU_CONCURRENT;
@@ -829,10 +828,10 @@ static void record_send_stats(cycles_t time1, cycles_t 
time2,
if ((completion_status == FLUSH_COMPLETE) && (try == 1)) {
bcp->period_requests++;
bcp->period_time += elapsed;
-   if ((elapsed > congested_cycles) &&
+   if ((elapsed > usec_2_cycles(bcp->cong_response_us)) &&
(bcp->period_requests > bcp->cong_reps) &&
((bcp->period_time / bcp->period_requests) >
-   congested_cycles)) {
+   usec_2_cycles(bcp->cong_response_us))) {
stat->s_congested++;
disable_for_period(bcp, stat);
}
@@ -2228,7 +2227,6 @@ static int __init uv_bau_init(void)
}
 
nuvhubs = uv_num_possible_blades();
-   congested_cycles = usec_2_cycles(congested_respns_us);
 
uv_base_pnode = 0x7fff;
for (uvhub = 0; uvhub < nuvhubs; uvhub++) {


[PATCH] drivers/video/fbdev/omap/lcd_mipid.c: add const to lcd_panel structure

2017-07-14 Thread Bhumika Goyal
Make lcd_panel structure const as it is only copied to some object.
As the only usage of this structure is a copy operation, so it can be
made const.

Signed-off-by: Bhumika Goyal 
---
 drivers/video/fbdev/omap/lcd_mipid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap/lcd_mipid.c 
b/drivers/video/fbdev/omap/lcd_mipid.c
index df9e6eb..e3a8543 100644
--- a/drivers/video/fbdev/omap/lcd_mipid.c
+++ b/drivers/video/fbdev/omap/lcd_mipid.c
@@ -496,7 +496,7 @@ static void mipid_cleanup(struct lcd_panel *panel)
mipid_esd_stop_check(md);
 }
 
-static struct lcd_panel mipid_panel = {
+static const struct lcd_panel mipid_panel = {
.config = OMAP_LCDC_PANEL_TFT,
 
.bpp= 16,
-- 
1.9.1



[tip:sched/urgent] sched/cputime: Don't use smp_processor_id() in preemptible context

2017-07-14 Thread tip-bot for Wanpeng Li
Commit-ID:  0e4097c3354e2f5a5ad8affd9dc7f7f7d00bb6b9
Gitweb: http://git.kernel.org/tip/0e4097c3354e2f5a5ad8affd9dc7f7f7d00bb6b9
Author: Wanpeng Li 
AuthorDate: Sun, 9 Jul 2017 00:40:28 -0700
Committer:  Ingo Molnar 
CommitDate: Fri, 14 Jul 2017 10:27:15 +0200

sched/cputime: Don't use smp_processor_id() in preemptible context

Recent kernels trigger this warning:

 BUG: using smp_processor_id() in preemptible [] code: 99-trinity/181
 caller is debug_smp_processor_id+0x17/0x19
 CPU: 0 PID: 181 Comm: 99-trinity Not tainted 4.12.0-01059-g2a42eb9 #1
 Call Trace:
  dump_stack+0x82/0xb8
  check_preemption_disabled()
  debug_smp_processor_id()
  vtime_delta()
  task_cputime()
  thread_group_cputime()
  thread_group_cputime_adjusted()
  wait_consider_task()
  do_wait()
  SYSC_wait4()
  do_syscall_64()
  entry_SYSCALL64_slow_path()

As Frederic pointed out:

| Although those sched_clock_cpu() things seem to only matter when the
| sched_clock() is unstable. And that stability is a condition for nohz_full
| to work anyway. So probably sched_clock() alone would be enough.

This patch fixes it by replacing sched_clock_cpu() with sched_clock() to
avoid calling smp_processor_id() in a preemptible context.

Reported-by: Xiaolong Ye 
Signed-off-by: Wanpeng Li 
Cc: Frederic Weisbecker 
Cc: Linus Torvalds 
Cc: Luiz Capitulino 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1499586028-7402-1-git-send-email-wanpeng...@hotmail.com
[ Prettified the changelog. ]
Signed-off-by: Ingo Molnar 
---
 kernel/sched/cputime.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 6e3ea4a..14d2dbf 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -683,7 +683,7 @@ static u64 vtime_delta(struct vtime *vtime)
 {
unsigned long long clock;
 
-   clock = sched_clock_cpu(smp_processor_id());
+   clock = sched_clock();
if (clock < vtime->starttime)
return 0;
 
@@ -814,7 +814,7 @@ void arch_vtime_task_switch(struct task_struct *prev)
 
write_seqcount_begin(&vtime->seqcount);
vtime->state = VTIME_SYS;
-   vtime->starttime = sched_clock_cpu(smp_processor_id());
+   vtime->starttime = sched_clock();
write_seqcount_end(&vtime->seqcount);
 }
 
@@ -826,7 +826,7 @@ void vtime_init_idle(struct task_struct *t, int cpu)
local_irq_save(flags);
write_seqcount_begin(&vtime->seqcount);
vtime->state = VTIME_SYS;
-   vtime->starttime = sched_clock_cpu(cpu);
+   vtime->starttime = sched_clock();
write_seqcount_end(&vtime->seqcount);
local_irq_restore(flags);
 }


[tip:sched/urgent] sched/deadline: Fix confusing comments about selection of top pi-waiter

2017-07-14 Thread tip-bot for Joel Fernandes
Commit-ID:  193be41e33168a3a06eb9d356d9e39c69de161d2
Gitweb: http://git.kernel.org/tip/193be41e33168a3a06eb9d356d9e39c69de161d2
Author: Joel Fernandes 
AuthorDate: Wed, 12 Jul 2017 19:24:29 -0700
Committer:  Ingo Molnar 
CommitDate: Fri, 14 Jul 2017 10:35:16 +0200

sched/deadline: Fix confusing comments about selection of top pi-waiter

This comment in the code is incomplete, and I believe it begs a definition of
dl_boosted to make sense of the condition that follows. Rewrite the comment and
also rearrange the condition that follows to reflect the first condition "we
have a top pi-waiter which is a SCHED_DEADLINE task" in that order. Also fix a
typo that follows.

Signed-off-by: Joel Fernandes 
Reviewed-by: Daniel Bristot de Oliveira 
Acked-by: Juri Lelli 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20170713022429.10307-1-joe...@google.com
Signed-off-by: Ingo Molnar 
---
 kernel/sched/deadline.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index a84299f..755bd3f 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1392,17 +1392,19 @@ static void enqueue_task_dl(struct rq *rq, struct 
task_struct *p, int flags)
struct sched_dl_entity *pi_se = &p->dl;
 
/*
-* Use the scheduling parameters of the top pi-waiter
-* task if we have one and its (absolute) deadline is
-* smaller than our one... OTW we keep our runtime and
-* deadline.
+* Use the scheduling parameters of the top pi-waiter task if:
+* - we have a top pi-waiter which is a SCHED_DEADLINE task AND
+* - our dl_boosted is set (i.e. the pi-waiter's (absolute) deadline is
+*   smaller than our deadline OR we are a !SCHED_DEADLINE task getting
+*   boosted due to a SCHED_DEADLINE pi-waiter).
+* Otherwise we keep our runtime and deadline.
 */
-   if (pi_task && p->dl.dl_boosted && dl_prio(pi_task->normal_prio)) {
+   if (pi_task && dl_prio(pi_task->normal_prio) && p->dl.dl_boosted) {
pi_se = &pi_task->dl;
} else if (!dl_prio(p->normal_prio)) {
/*
 * Special case in which we have a !SCHED_DEADLINE task
-* that is going to be deboosted, but exceedes its
+* that is going to be deboosted, but exceeds its
 * runtime while doing so. No point in replenishing
 * it, as it's going to return back to its original
 * scheduling class after this.


Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode

2017-07-14 Thread Ulf Hansson
On 14 July 2017 at 08:42, Chen-Yu Tsai  wrote:
> The register for the "new timing mode" also has bit fields for setting
> output and sample timing phases. According to comments in Allwinner's
> BSP kernel, the default values are good enough.
>
> Keep the default values already in the hardware when setting new timing
> mode, instead of overwriting the whole register.
>
> Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
>   controllers")
> Signed-off-by: Chen-Yu Tsai 

It looks like this change doesn't depend on anything else? Do you want
me to pick it up for fixes and adding stable tag?

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index d6fa2214aaae..0fb4e4c119e1 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -793,8 +793,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
> *host,
> }
> mmc_writel(host, REG_CLKCR, rval);
>
> -   if (host->cfg->needs_new_timings)
> -   mmc_writel(host, REG_SD_NTSR, SDXC_2X_TIMING_MODE);
> +   if (host->cfg->needs_new_timings) {
> +   /* Don't touch the delay bits */
> +   rval = mmc_readl(host, REG_SD_NTSR);
> +   rval |= SDXC_2X_TIMING_MODE;
> +   mmc_writel(host, REG_SD_NTSR, rval);
> +   }
>
> ret = sunxi_mmc_clk_set_phase(host, ios, rate);
> if (ret)
> --
> 2.13.2
>


[PATCH v2] spi: loopback-test: provide loop_req option.

2017-07-14 Thread Oleksij Rempel
Provide a module parameter to request internal loop by the SPI master
controller.
This should make loop testing easier without extra HW modification.

For test automation can be also used logic analyzer.
If some one wish to reproduce my test. Here is used setup:
  i.MX6S RIoRBoard   Logic Analyzer
  -
  (J13  4) GND - GND
  (J13  6) CSPI3-CLK --> PIN 3
  (J13  8) CSPI3-MOSI <- PIN 2
 ^ - internal loop configured by SPI_LOOP
 |
  (J13 10) CSPI3-MISO -> PIN 1

grub some data and decode it:
sigrok-cli -d fx2lafw --time 16 --config samplerate=10m  \
  --channels 0-2 -o dump.sr
sigrok-cli -i dump.sr -P spi:mosi=1:clk=2 > result_for_regression_tests

Signed-off-by: Oleksij Rempel 
---
v2:
- some spelling fixes
- add more background about testing setup
- reword error message.

 drivers/spi/spi-loopback-test.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/spi/spi-loopback-test.c b/drivers/spi/spi-loopback-test.c
index f4875f177df0..cfc7222f0a85 100644
--- a/drivers/spi/spi-loopback-test.c
+++ b/drivers/spi/spi-loopback-test.c
@@ -51,6 +51,12 @@ MODULE_PARM_DESC(loopback,
 "is checked to match tx_buf after the spi_message "\
 "is executed");
 
+int loop_req;
+module_param(loop_req, int, 0);
+MODULE_PARM_DESC(loop_req,
+"if set controller will be asked to enable test loop mode. " \
+"If controller supported it, MISO and MOSI will be connected");
+
 /* run only a specific test */
 int run_only_test = -1;
 module_param(run_only_test, int, 0);
@@ -313,6 +319,16 @@ static int spi_loopback_test_probe(struct spi_device *spi)
 {
int ret;
 
+   if (loop_req) {
+   spi->mode = SPI_LOOP | spi->mode;
+   ret = spi_setup(spi);
+   if (ret) {
+   dev_err(&spi->dev, "SPI setup with SPI_LOOP failed 
(%d)\n",
+   ret);
+   return ret;
+   }
+   }
+
dev_info(&spi->dev, "Executing spi-loopback-tests\n");
 
ret = spi_test_run_tests(spi, spi_tests);
-- 
2.11.0



Re: [PATCH 15/18] drm/panel: Add Huarui LHR050H41 panel driver

2017-07-14 Thread Andrzej Hajda
On 13.07.2017 16:13, Maxime Ripard wrote:
> The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic. Add a
> driver for it.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/panel/Kconfig  |   9 +-
>  drivers/gpu/drm/panel/Makefile |   1 +-
>  drivers/gpu/drm/panel/panel-huarui-lhr050h41.c | 444 ++-
>  3 files changed, 454 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-huarui-lhr050h41.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index d84a031fae24..eaa6e102775a 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -28,6 +28,15 @@ config DRM_PANEL_SIMPLE
> that it can be automatically turned off when the panel goes into a
> low power state.
>  
> +config DRM_PANEL_HUARUI_LHR050H41
> + tristate "Huarui LHR050H41 panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y if you want to enable support for the Huarui Lighting
> +   LHR05041 DSI panel. The panel has a 1280x720 resolution.
> +
>  config DRM_PANEL_INNOLUX_P079ZCA
>   tristate "Innolux P079ZCA panel"
>   depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 9f6610d08b00..58de7a853898 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
>  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
> +obj-$(CONFIG_DRM_PANEL_HUARUI_LHR050H41) += panel-huarui-lhr050h41.o
>  obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
>  obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
>  obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> diff --git a/drivers/gpu/drm/panel/panel-huarui-lhr050h41.c 
> b/drivers/gpu/drm/panel/panel-huarui-lhr050h41.c
> new file mode 100644
> index ..eb675eb9ee7d
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-huarui-lhr050h41.c
> @@ -0,0 +1,444 @@

No copyright/license/description at the beginning of the file.


> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 

It can be put in alphabetical order.

> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct lhr050h41 {
> + struct drm_panelpanel;
> + struct mipi_dsi_device  *dsi;
> +
> + struct backlight_device *backlight;
> + struct gpio_desc*power;
> + struct gpio_desc*reset;
> +};
> +
> +static inline struct lhr050h41 *panel_to_lhr050h41(struct drm_panel *panel)
> +{
> + return container_of(panel, struct lhr050h41, panel);
> +}
> +
> +static int lhr050h41_switch_page(struct lhr050h41 *ctx, u8 page)
> +{
> + u8 buf[4] = { 0xff, 0x98, 0x81, page };
> +
> + return mipi_dsi_dcs_write_buffer(ctx->dsi, buf, sizeof(buf));
> +}
> +
> +static int lhr050h41_send_cmd_data(struct lhr050h41 *ctx, u8 cmd, u8 data)
> +{
> + u8 buf[2] = { cmd, data };
> +
> + return mipi_dsi_dcs_write_buffer(ctx->dsi, buf, sizeof(buf));
> +}
> +
> +static int lhr050h41_send_init_sequence(struct lhr050h41 *ctx)
> +{
> + lhr050h41_switch_page(ctx, 3);

No error checking, here and below in most places.

> +
> + lhr050h41_send_cmd_data(ctx, 0x01, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x02, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x03, 0x73);
> + lhr050h41_send_cmd_data(ctx, 0x04, 0x03);
> + lhr050h41_send_cmd_data(ctx, 0x05, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x06, 0x06);
> + lhr050h41_send_cmd_data(ctx, 0x07, 0x06);
> + lhr050h41_send_cmd_data(ctx, 0x08, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x09, 0x18);
> + lhr050h41_send_cmd_data(ctx, 0x0a, 0x04);
> + lhr050h41_send_cmd_data(ctx, 0x0b, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x0c, 0x02);
> + lhr050h41_send_cmd_data(ctx, 0x0d, 0x03);
> + lhr050h41_send_cmd_data(ctx, 0x0e, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x0f, 0x25);
> + lhr050h41_send_cmd_data(ctx, 0x10, 0x25);
> + lhr050h41_send_cmd_data(ctx, 0x11, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x12, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x13, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x14, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x15, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x16, 0x0C);
> + lhr050h41_send_cmd_data(ctx, 0x17, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x18, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x19, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x1a, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x1b, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x1c, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x1d, 0x00);
> + lhr050h41_send_cmd_data(ctx, 0x1e, 0xC0);
> + lhr050h41_send_cmd_data(ctx, 0x1f, 0x80);
> + lhr050h41_send_cmd_data(ctx, 0x20, 0x04);
> + lhr050h41_send_cmd_data(ctx, 0x2

Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings

2017-07-14 Thread Ulf Hansson
On 14 July 2017 at 08:42, Chen-Yu Tsai  wrote:
> On the SoCs that introduced the new timing mode for MMC controllers,
> both the old (where the clock delays are set in the CCU) and new
> (where the clock delays are set in the MMC controller) timing modes
> are available, and we have to support them both. However there are
> two bits that control which mode is active. One is in the CCU, the
> other is in the MMC controller. The settings on both sides must be
> the same, or nothing will work.
>
> The CCU's get/set_phase callbacks return -ENOTSUPP when the new
> timing mode is active. This provides a way to know which mode is
> active on that side, and we can set the bit on the MMC controller
> side accordingly.
>
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/mmc/host/sunxi-mmc.c | 34 ++
>  1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 0fb4e4c119e1..56e45c65b52d 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -22,6 +22,7 @@
>  #include 
>
>  #include 
> +#include 

I don't like this. This looks like an SoC specific hack.

>  #include 
>  #include 
>  #include 
> @@ -259,7 +260,7 @@ struct sunxi_mmc_cfg {
> /* Does DATA0 needs to be masked while the clock is updated */
> bool mask_data0;
>
> -   bool needs_new_timings;
> +   bool has_new_timings;
>  };
>
>  struct sunxi_mmc_host {
> @@ -293,6 +294,9 @@ struct sunxi_mmc_host {
>
> /* vqmmc */
> boolvqmmc_enabled;
> +
> +   /* timings */
> +   booluse_new_timings;
>  };
>
>  static int sunxi_mmc_reset_host(struct sunxi_mmc_host *host)
> @@ -714,7 +718,7 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host 
> *host,
>  {
> int index;
>
> -   if (!host->cfg->clk_delays)
> +   if (host->use_new_timings)
> return 0;
>
> /* determine delays */
> @@ -765,6 +769,15 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
> *host,
> ios->bus_width == MMC_BUS_WIDTH_8)
> clock <<= 1;
>
> +   if (host->use_new_timings) {
> +   ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);

Can't this be solved through some other generic API/interface?

> +   if (ret) {
> +   dev_err(mmc_dev(mmc),
> +   "error setting new timing mode\n");
> +   return ret;
> +   }
> +   }
> +

[...]

Kind regards
Uffe


[PATCH 00/14] gcc-7 warnings

2017-07-14 Thread Arnd Bergmann
This series should shut up all warnings introduced by gcc-6 or gcc-7 on
today's linux-next, as observed in "allmodconfig" builds on x86,
arm and arm64.

I have sent some of these before, but some others are new, as I had
at some point disabled the -Wint-in-bool-context warning in my
randconfig testing and did not notice the other warnings.

I have another series to address all -Wformat-overflow warnings,
and one more patch to turn off the -Wformat-truncation warnings
unless we build with "make W=1". I'll send that separately.

Most of these are consist of trivial refactoring of the code to
shut up false-positive warnings, the one exception being
"staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read",
which fixes a regression against linux-3.1 that has gone
unnoticed since then. Still, review from subsystem maintainers
would be appreciated.

I would suggest that Andrew Morton can pick these up into linux-mm
so we can make sure they all make it into the release. Alternatively
Linus might feel like picking them all up himself.

While I did not mark the harmless ones for stable backports,
Greg may also want to pick them up once they go upstream, to
help build-test the stable kernels with gcc-7.

  Arnd

Arnd Bergmann (14):
  [SUBMITTED 20170511] ide: avoid warning for timings calculation
  [SUBMITTED 20170511] ata: avoid gcc-7 warning in ata_timing_quantize
  [SUBMITTED 20170314] drm/vmwgfx: avoid gcc-7 parentheses warning
  x86: math-emu: avoid -Wint-in-bool-context warning
  isdn: isdnloop: suppress a gcc-7 warning
  acpi: thermal: fix gcc-6/ccache warning
  proc/kcore: hide a harmless warning
  Input: adxl34x - fix gcc-7 -Wint-in-bool-context warning
  SFI: fix tautological-compare warning
  staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read
  IB/uverbs: fix gcc-7 type warning
  drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning
  iopoll: avoid -Wint-in-bool-context warning
  [media] fix warning on v4l2_subdev_call() result interpreted as bool

 arch/x86/math-emu/fpu_emu.h  |  2 +-
 drivers/acpi/processor_thermal.c |  6 --
 drivers/ata/libata-core.c| 20 ++--
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c  |  6 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |  2 +-
 drivers/ide/ide-timings.c| 18 +-
 drivers/infiniband/core/uverbs.h | 14 --
 drivers/input/misc/adxl34x.c |  2 +-
 drivers/isdn/isdnloop/isdnloop.c |  2 +-
 drivers/media/pci/cx18/cx18-ioctl.c  |  6 --
 drivers/media/pci/saa7146/mxb.c  |  5 +++--
 drivers/media/platform/atmel/atmel-isc.c |  4 ++--
 drivers/media/platform/atmel/atmel-isi.c |  4 ++--
 drivers/media/platform/blackfin/bfin_capture.c   |  4 ++--
 drivers/media/platform/omap3isp/ispccdc.c|  5 +++--
 drivers/media/platform/pxa_camera.c  |  3 ++-
 drivers/media/platform/rcar-vin/rcar-core.c  |  2 +-
 drivers/media/platform/rcar-vin/rcar-dma.c   |  4 +++-
 drivers/media/platform/soc_camera/soc_camera.c   |  4 ++--
 drivers/media/platform/stm32/stm32-dcmi.c|  4 ++--
 drivers/media/platform/ti-vpe/cal.c  |  6 --
 drivers/sfi/sfi_core.c   |  9 ++---
 drivers/staging/iio/resolver/ad2s1210.c  |  2 +-
 .../staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 13 +++--
 fs/proc/kcore.c  | 10 ++
 include/linux/iopoll.h   |  6 --
 include/linux/regmap.h   |  2 +-
 27 files changed, 93 insertions(+), 72 deletions(-)

-- 
2.9.0



[PATCH, RESEND 02/14] ata: avoid gcc-7 warning in ata_timing_quantize

2017-07-14 Thread Arnd Bergmann
gcc-7 warns about the result of a constant multiplication used as
a boolean:

drivers/ata/libata-core.c: In function 'ata_timing_quantize':
drivers/ata/libata-core.c:3164:30: warning: '*' in boolean context, suggest 
'&&' instead [-Wint-in-bool-context]

This slightly rearranges the macro to simplify the code and avoid
the warning at the same time.

Signed-off-by: Arnd Bergmann 
---
 drivers/ata/libata-core.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index fa7dd4394c02..450059dd06ba 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3231,19 +3231,19 @@ static const struct ata_timing ata_timing[] = {
 };
 
 #define ENOUGH(v, unit)(((v)-1)/(unit)+1)
-#define EZ(v, unit)((v)?ENOUGH(v, unit):0)
+#define EZ(v, unit)((v)?ENOUGH(((v) * 1000), unit):0)
 
 static void ata_timing_quantize(const struct ata_timing *t, struct ata_timing 
*q, int T, int UT)
 {
-   q->setup= EZ(t->setup  * 1000,  T);
-   q->act8b= EZ(t->act8b  * 1000,  T);
-   q->rec8b= EZ(t->rec8b  * 1000,  T);
-   q->cyc8b= EZ(t->cyc8b  * 1000,  T);
-   q->active   = EZ(t->active * 1000,  T);
-   q->recover  = EZ(t->recover* 1000,  T);
-   q->dmack_hold   = EZ(t->dmack_hold * 1000,  T);
-   q->cycle= EZ(t->cycle  * 1000,  T);
-   q->udma = EZ(t->udma   * 1000, UT);
+   q->setup= EZ(t->setup,   T);
+   q->act8b= EZ(t->act8b,   T);
+   q->rec8b= EZ(t->rec8b,   T);
+   q->cyc8b= EZ(t->cyc8b,   T);
+   q->active   = EZ(t->active,  T);
+   q->recover  = EZ(t->recover, T);
+   q->dmack_hold   = EZ(t->dmack_hold,  T);
+   q->cycle= EZ(t->cycle,   T);
+   q->udma = EZ(t->udma,   UT);
 }
 
 void ata_timing_merge(const struct ata_timing *a, const struct ata_timing *b,
-- 
2.9.0



[PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

2017-07-14 Thread Arnd Bergmann
gcc-7 warns about slightly suspicious code in vmw_cmd_invalid:

drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_invalid':
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:23: error: the omitted middle 
operand in ?: will always be 'true', suggest explicit middle operand 
[-Werror=parentheses]

The problem is that it is mixing boolean and integer values here.
I assume that the code actually works correctly, so making it use
a literal '1' instead of the implied 'true' makes it more readable
and avoids the warning.

The code has been in this file since the start, but it could
make sense to backport this patch to stable to make it build cleanly
with gcc-7.

Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Reviewed-by: Sinclair Yeh 
Signed-off-by: Arnd Bergmann 
---
Originally submitted on Nov 16, but for some reason it never appeared
upstream. The patch is still needed as of v4.11-rc2
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index c7b53d987f06..3f343e55972a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -519,7 +519,7 @@ static int vmw_cmd_invalid(struct vmw_private *dev_priv,
   struct vmw_sw_context *sw_context,
   SVGA3dCmdHeader *header)
 {
-   return capable(CAP_SYS_ADMIN) ? : -EINVAL;
+   return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL;
 }
 
 static int vmw_cmd_ok(struct vmw_private *dev_priv,
-- 
2.9.0



[PATCH, RESEND 01/14] ide: avoid warning for timings calculation

2017-07-14 Thread Arnd Bergmann
gcc-7 warns about the result of a constant multiplication used as
a boolean:

drivers/ide/ide-timings.c: In function 'ide_timing_quantize':
drivers/ide/ide-timings.c:112:24: error: '*' in boolean context, suggest '&&' 
instead [-Werror=int-in-bool-context]
  q->setup   = EZ(t->setup   * 1000,  T);

This slightly rearranges the macro to simplify the code and avoid
the warning at the same time.

Signed-off-by: Arnd Bergmann 
---
 drivers/ide/ide-timings.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/ide/ide-timings.c b/drivers/ide/ide-timings.c
index 0e05f75934c9..1858e3ce3993 100644
--- a/drivers/ide/ide-timings.c
+++ b/drivers/ide/ide-timings.c
@@ -104,19 +104,19 @@ u16 ide_pio_cycle_time(ide_drive_t *drive, u8 pio)
 EXPORT_SYMBOL_GPL(ide_pio_cycle_time);
 
 #define ENOUGH(v, unit)(((v) - 1) / (unit) + 1)
-#define EZ(v, unit)((v) ? ENOUGH(v, unit) : 0)
+#define EZ(v, unit)((v) ? ENOUGH((v) * 1000, unit) : 0)
 
 static void ide_timing_quantize(struct ide_timing *t, struct ide_timing *q,
int T, int UT)
 {
-   q->setup   = EZ(t->setup   * 1000,  T);
-   q->act8b   = EZ(t->act8b   * 1000,  T);
-   q->rec8b   = EZ(t->rec8b   * 1000,  T);
-   q->cyc8b   = EZ(t->cyc8b   * 1000,  T);
-   q->active  = EZ(t->active  * 1000,  T);
-   q->recover = EZ(t->recover * 1000,  T);
-   q->cycle   = EZ(t->cycle   * 1000,  T);
-   q->udma= EZ(t->udma* 1000, UT);
+   q->setup   = EZ(t->setup,   T);
+   q->act8b   = EZ(t->act8b,   T);
+   q->rec8b   = EZ(t->rec8b,   T);
+   q->cyc8b   = EZ(t->cyc8b,   T);
+   q->active  = EZ(t->active,  T);
+   q->recover = EZ(t->recover, T);
+   q->cycle   = EZ(t->cycle,   T);
+   q->udma= EZ(t->udma,UT);
 }
 
 void ide_timing_merge(struct ide_timing *a, struct ide_timing *b,
-- 
2.9.0



[PATCH 05/14] isdn: isdnloop: suppress a gcc-7 warning

2017-07-14 Thread Arnd Bergmann
We test whether a bit is set in a mask here, which is correct
but gcc warns about it as it thinks it might be confusing:

drivers/isdn/isdnloop/isdnloop.c:412:37: error: ?: using integer constants in 
boolean context, the expression will always evaluate to 'true' 
[-Werror=int-in-bool-context]

This replaces the negation of an integer with an equivalent
comparison to zero, which gets rid of the warning.

Signed-off-by: Arnd Bergmann 
---
 drivers/isdn/isdnloop/isdnloop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/isdn/isdnloop/isdnloop.c b/drivers/isdn/isdnloop/isdnloop.c
index 6ffd13466b8c..5792928b944d 100644
--- a/drivers/isdn/isdnloop/isdnloop.c
+++ b/drivers/isdn/isdnloop/isdnloop.c
@@ -409,7 +409,7 @@ isdnloop_sendbuf(int channel, struct sk_buff *skb, 
isdnloop_card *card)
return -EINVAL;
}
if (len) {
-   if (!(card->flags & (channel) ? ISDNLOOP_FLAGS_B2ACTIVE : 
ISDNLOOP_FLAGS_B1ACTIVE))
+   if ((card->flags & (channel) ? ISDNLOOP_FLAGS_B2ACTIVE : 
ISDNLOOP_FLAGS_B1ACTIVE) == 0)
return 0;
if (card->sndcount[channel] > ISDNLOOP_MAX_SQUEUE)
return 0;
-- 
2.9.0



Re: [PATCH v2 07/22] fpga: intel: pcie: parse feature list and create platform device for features.

2017-07-14 Thread Wu Hao
On Thu, Jul 13, 2017 at 12:52:30PM -0500, Alan Tull wrote:
> On Sun, Jun 25, 2017 at 8:52 PM, Wu Hao  wrote:
> > From: Xiao Guangrong 
> >
> > Device Feature List structure creates a link list of feature headers
> > within the MMIO space to provide an extensible way of adding features.
> >
> > The Intel FPGA PCIe driver walks through the feature headers to enumerate
> > feature devices, FPGA Management Engine (FME) and FPGA Port for Accelerated
> > Function Unit (AFU), and their private sub features. For feature devices,
> > it creates the platform devices and linked the private sub features into
> > their platform data.
> >
> > Signed-off-by: Tim Whisonant 
> > Signed-off-by: Enno Luebbers 
> > Signed-off-by: Shiva Rao 
> > Signed-off-by: Christopher Rauer 
> > Signed-off-by: Kang Luwei 
> > Signed-off-by: Zhang Yi 
> > Signed-off-by: Xiao Guangrong 
> > Signed-off-by: Wu Hao 
> > ---
> > v2: moved the code to drivers/fpga folder as suggested by Alan Tull.
> > switched to GPLv2 license.
> > fixed comments from Moritz Fischer.
> > fixed kbuild warning, typos and clean up the code.
> > ---
> >  drivers/fpga/Makefile|   2 +-
> >  drivers/fpga/intel-feature-dev.c | 130 ++
> >  drivers/fpga/intel-feature-dev.h | 341 
> >  drivers/fpga/intel-pcie.c| 841 
> > ++-
> >  4 files changed, 1311 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/fpga/intel-feature-dev.c
> >  create mode 100644 drivers/fpga/intel-feature-dev.h
> >
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index 5613133..ad24b3d 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -31,4 +31,4 @@ obj-$(CONFIG_OF_FPGA_REGION)  += of-fpga-region.o
> >  # Intel FPGA Support
> >  obj-$(CONFIG_INTEL_FPGA_PCI)   += intel-fpga-pci.o
> >
> > -intel-fpga-pci-objs := intel-pcie.o
> > +intel-fpga-pci-objs := intel-pcie.o intel-feature-dev.o
> > diff --git a/drivers/fpga/intel-feature-dev.c 
> > b/drivers/fpga/intel-feature-dev.c
> > new file mode 100644
> > index 000..68f9cba
> > --- /dev/null
> > +++ b/drivers/fpga/intel-feature-dev.c
> > @@ -0,0 +1,130 @@
> > +/*
> > + * Intel FPGA Feature Device Driver
> > + *
> > + * Copyright (C) 2017 Intel Corporation, Inc.
> > + *
> > + * Authors:
> > + *   Kang Luwei 
> > + *   Zhang Yi 
> > + *   Wu Hao 
> > + *   Xiao Guangrong 
> > + *
> > + * This work is licensed under the terms of the GNU GPL version 2. See
> > + * the COPYING file in the top-level directory.
> > + */
> > +
> > +#include "intel-feature-dev.h"
> > +
> > +void feature_platform_data_add(struct feature_platform_data *pdata,
> > +  int index, const char *name,
> > +  int resource_index, void __iomem *ioaddr)
> > +{
> > +   WARN_ON(index >= pdata->num);
> > +
> > +   pdata->features[index].name = name;
> > +   pdata->features[index].resource_index = resource_index;
> > +   pdata->features[index].ioaddr = ioaddr;
> > +}
> > +
> > +struct feature_platform_data *
> > +feature_platform_data_alloc_and_init(struct platform_device *dev, int num)
> > +{
> > +   struct feature_platform_data *pdata;
> > +
> > +   pdata = kzalloc(feature_platform_data_size(num), GFP_KERNEL);
> > +   if (pdata) {
> > +   pdata->dev = dev;
> > +   pdata->num = num;
> > +   mutex_init(&pdata->lock);
> > +   }
> > +
> > +   return pdata;
> > +}
> > +
> > +int fme_feature_num(void)
> > +{
> > +   return FME_FEATURE_ID_MAX;
> > +}
> > +
> > +int port_feature_num(void)
> > +{
> > +   return PORT_FEATURE_ID_MAX;
> > +}
> > +
> > +int fpga_port_id(struct platform_device *pdev)
> > +{
> > +   struct feature_port_header *port_hdr;
> > +   struct feature_port_capability capability;
> > +
> > +   port_hdr = get_feature_ioaddr_by_index(&pdev->dev,
> > +  PORT_FEATURE_ID_HEADER);
> > +   WARN_ON(!port_hdr);
> > +
> > +   capability.csr = readq(&port_hdr->capability);
> > +   return capability.port_number;
> > +}
> > +EXPORT_SYMBOL_GPL(fpga_port_id);
> > +
> > +/*
> > + * Enable Port by clear the port soft reset bit, which is set by default.
> > + * The User AFU is unable to respond to any MMIO access while in reset.
> > + * __fpga_port_enable function should only be used after 
> > __fpga_port_disable
> > + * function.
> > + */
> > +void __fpga_port_enable(struct platform_device *pdev)
> > +{
> > +   struct feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
> > +   struct feature_port_header *port_hdr;
> > +   struct feature_port_control control;
> > +
> > +   WARN_ON(!pdata->disable_count);
> > +
> > +   if (--pdata->disable_count != 0)
> > +   return;
> > +
> > +   port_hdr = get_feature_ioaddr_by_index(&pdev->dev,
> > +  PORT_FEATURE_ID_HEADE

[PATCH 08/14] Input: adxl34x - fix gcc-7 -Wint-in-bool-context warning

2017-07-14 Thread Arnd Bergmann
FIFO_MODE is an macro expression with a '<<' operator, which
gcc points out could be misread as a '<':

drivers/input/misc/adxl34x.c: In function 'adxl34x_probe':
drivers/input/misc/adxl34x.c:799:36: error: '<<' in boolean context, did you 
mean '<' ? [-Werror=int-in-bool-context]

This converts the test to an explicit comparison with zero,
making it clearer to gcc and the reader what is intended.

Fixes: e27c729219ad ("Input: add driver for ADXL345/346 Digital Accelerometers")
Signed-off-by: Arnd Bergmann 
---
 drivers/input/misc/adxl34x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/misc/adxl34x.c b/drivers/input/misc/adxl34x.c
index 2b2d02f408bb..e0caaa0de454 100644
--- a/drivers/input/misc/adxl34x.c
+++ b/drivers/input/misc/adxl34x.c
@@ -796,7 +796,7 @@ struct adxl34x *adxl34x_probe(struct device *dev, int irq,
 
if (pdata->watermark) {
ac->int_mask |= WATERMARK;
-   if (!FIFO_MODE(pdata->fifo_mode))
+   if (FIFO_MODE(pdata->fifo_mode) == 0)
ac->pdata.fifo_mode |= FIFO_STREAM;
} else {
ac->int_mask |= DATA_READY;
-- 
2.9.0



[PATCH 07/14] proc/kcore: hide a harmless warning

2017-07-14 Thread Arnd Bergmann
gcc warns when MODULES_VADDR/END is defined to the same value as
VMALLOC_START/VMALLOC_END, e.g. on x86-32:

fs/proc/kcore.c: In function ‘add_modules_range’:
fs/proc/kcore.c:622:161: error: self-comparison always evaluates to false 
[-Werror=tautological-compare]
  if (/*MODULES_VADDR != VMALLOC_START && */MODULES_END != VMALLOC_END) {

The code is correct as it is required for most other configurations.
The best workaround I found for shutting up that warning is to make
it a little more complex by adding a temporary variable. The compiler
will still optimize away the code as it finds the two to be identical,
but it no longer warns because it doesn't condider the comparison
"tautological" any more.

Signed-off-by: Arnd Bergmann 
---
 fs/proc/kcore.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 45629f4b5402..c503ad657c46 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -620,12 +620,14 @@ static void __init proc_kcore_text_init(void)
 /*
  * MODULES_VADDR has no intersection with VMALLOC_ADDR.
  */
-struct kcore_list kcore_modules;
+static struct kcore_list kcore_modules;
 static void __init add_modules_range(void)
 {
-   if (MODULES_VADDR != VMALLOC_START && MODULES_END != VMALLOC_END) {
-   kclist_add(&kcore_modules, (void *)MODULES_VADDR,
-   MODULES_END - MODULES_VADDR, KCORE_VMALLOC);
+   void *start = (void *)MODULES_VADDR;
+   size_t len = MODULES_END - MODULES_VADDR;
+
+   if (start != (void *)VMALLOC_START && len != VMALLOC_END - 
VMALLOC_START) {
+   kclist_add(&kcore_modules, start, len, KCORE_VMALLOC);
}
 }
 #else
-- 
2.9.0



[PATCH 04/14] x86: math-emu: avoid -Wint-in-bool-context warning

2017-07-14 Thread Arnd Bergmann
The setsign() macro gets called with an integer argument in a
few places, leading to a harmless warning in gcc-7:

arch/x86/math-emu/reg_add_sub.c: In function 'FPU_add':
arch/x86/math-emu/reg_add_sub.c:80:48: error: ?: using integer constants in 
boolean context [-Werror=int-in-bool-context]

This turns the integer into a boolean expression by comparing it
to zero.

Signed-off-by: Arnd Bergmann 
---
 arch/x86/math-emu/fpu_emu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/math-emu/fpu_emu.h b/arch/x86/math-emu/fpu_emu.h
index afbc4d805d66..c9c320dccca1 100644
--- a/arch/x86/math-emu/fpu_emu.h
+++ b/arch/x86/math-emu/fpu_emu.h
@@ -157,7 +157,7 @@ extern u_char const data_sizes_16[32];
 
 #define signbyte(a) (((u_char *)(a))[9])
 #define getsign(a) (signbyte(a) & 0x80)
-#define setsign(a,b) { if (b) signbyte(a) |= 0x80; else signbyte(a) &= 0x7f; }
+#define setsign(a,b) { if ((b) != 0) signbyte(a) |= 0x80; else signbyte(a) &= 
0x7f; }
 #define copysign(a,b) { if (getsign(a)) signbyte(b) |= 0x80; \
 else signbyte(b) &= 0x7f; }
 #define changesign(a) { signbyte(a) ^= 0x80; }
-- 
2.9.0



[PATCH 06/14] acpi: thermal: fix gcc-6/ccache warning

2017-07-14 Thread Arnd Bergmann
In some configurations, topology_physical_package_id() is trivially
defined as '-1' for any input, resulting a comparison that is
always true:

drivers/acpi/processor_thermal.c: In function ‘cpufreq_set_cur_state’:
drivers/acpi/processor_thermal.c:137:36: error: self-comparison always 
evaluates to true [-Werror=tautological-compare]

By introducing a temporary variable, we can tell gcc that this is
intentional.

Signed-off-by: Arnd Bergmann 
---
 drivers/acpi/processor_thermal.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/processor_thermal.c b/drivers/acpi/processor_thermal.c
index 59c3a5d1e600..411f3a7f4a7c 100644
--- a/drivers/acpi/processor_thermal.c
+++ b/drivers/acpi/processor_thermal.c
@@ -122,20 +122,22 @@ static int cpufreq_get_cur_state(unsigned int cpu)
 static int cpufreq_set_cur_state(unsigned int cpu, int state)
 {
int i;
+   int id;
 
if (!cpu_has_cpufreq(cpu))
return 0;
 
reduction_pctg(cpu) = state;
 
+   id = topology_physical_package_id(cpu);
+
/*
 * Update all the CPUs in the same package because they all
 * contribute to the temperature and often share the same
 * frequency.
 */
for_each_online_cpu(i) {
-   if (topology_physical_package_id(i) ==
-   topology_physical_package_id(cpu))
+   if (topology_physical_package_id(i) == id)
cpufreq_update_policy(i);
}
return 0;
-- 
2.9.0



[PATCH 09/14] SFI: fix tautological-compare warning

2017-07-14 Thread Arnd Bergmann
With ccache in combination with gcc-6, we get a harmless warning for the sfi 
subsystem,
as ccache only sees the preprocessed source:

drivers/sfi/sfi_core.c: In function ‘sfi_map_table’:
drivers/sfi/sfi_core.c:175:53: error: self-comparison always evaluates to true 
[-Werror=tautological-compare]

Using an inline function to do the comparison tells the compiler what is
going on even for preprocessed files, and avoids the warning.

Signed-off-by: Arnd Bergmann 
---
 drivers/sfi/sfi_core.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 296db7a69c27..a8f2313a2613 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -71,9 +71,12 @@
 
 #include "sfi_core.h"
 
-#define ON_SAME_PAGE(addr1, addr2) \
-   (((unsigned long)(addr1) & PAGE_MASK) == \
-   ((unsigned long)(addr2) & PAGE_MASK))
+static inline bool on_same_page(unsigned long addr1, unsigned long addr2)
+{
+   return (addr1 & PAGE_MASK) == (addr2 & PAGE_MASK);
+}
+
+#define ON_SAME_PAGE(addr1, addr2) on_same_page((unsigned long)addr1, 
(unsigned long)addr2)
 #define TABLE_ON_PAGE(page, table, size) (ON_SAME_PAGE(page, table) && \
ON_SAME_PAGE(page, table + size))
 
-- 
2.9.0



Re: [PATCH 3.18 00/22] 3.18.61-stable review

2017-07-14 Thread Greg Kroah-Hartman
On Thu, Jul 13, 2017 at 06:26:28PM -0700, Guenter Roeck wrote:
> On 07/13/2017 08:42 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.61 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Jul 15 15:39:17 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 136 pass: 135 fail: 1
> Failed builds:
>   mips:bcm47xx_defconfig
> Qemu test results:
>   total: 111 pass: 111 fail: 0
> 
> Build failure:
> 
> drivers/net/ethernet/broadcom/bgmac.c: In function ‘bgmac_dma_rx_read’:
> drivers/net/ethernet/broadcom/bgmac.c:376:14: error: 'BGMAC_RX_ALLOC_SIZE’ 
> undeclared
> drivers/net/ethernet/broadcom/bgmac.c:379:32: error: ‘buf’ undeclared
> 
> Details are available at http://kerneltests.org/builders.

Ick, problem is in patch bgmac-add-check-for-oversized-packets.patch
from Amit.

Amit, how did you test this it obviously doesn't build :(

I'm dropping it from the tree now...

thanks,

greg k-h


Re: [PATCH v8 06/10] mm: thp: check pmd migration entry in common path

2017-07-14 Thread Naoya Horiguchi
On Sat, Jul 01, 2017 at 09:40:04AM -0400, Zi Yan wrote:
> From: Zi Yan 
> 
> If one of callers of page migration starts to handle thp,
> memory management code start to see pmd migration entry, so we need
> to prepare for it before enabling. This patch changes various code
> point which checks the status of given pmds in order to prevent race
> between thp migration and the pmd-related works.
> 
> ChangeLog v1 -> v2:
> - introduce pmd_related() (I know the naming is not good, but can't
>   think up no better name. Any suggesntion is welcomed.)
> 
> Signed-off-by: Naoya Horiguchi 
> 
> ChangeLog v2 -> v3:
> - add is_swap_pmd()
> - a pmd entry should be pmd pointing to pte pages, is_swap_pmd(),
>   pmd_trans_huge(), pmd_devmap(), or pmd_none()
> - pmd_none_or_trans_huge_or_clear_bad() and pmd_trans_unstable() return
>   true on pmd_migration_entry, so that migration entries are not
>   treated as pmd page table entries.
> 
> ChangeLog v4 -> v5:
> - add explanation in pmd_none_or_trans_huge_or_clear_bad() to state
>   the equivalence of !pmd_present() and is_pmd_migration_entry()
> - fix migration entry wait deadlock code (from v1) in follow_page_mask()
> - remove unnecessary code (from v1) in follow_trans_huge_pmd()
> - use is_swap_pmd() instead of !pmd_present() for pmd migration entry,
>   so it will not be confused with pmd_none()
> - change author information
> 
> ChangeLog v5 -> v7
> - use macro to disable the code when thp migration is not enabled
> 
> ChangeLog v7 -> v8
> - remove not used code in do_huge_pmd_wp_page()
> - copy the comment from change_pte_range() on downgrading
>   write migration entry to read to change_huge_pmd()
> 
> Signed-off-by: Zi Yan 
> Cc: Kirill A. Shutemov 
> ---
>  arch/x86/mm/gup.c |  7 +++--
>  fs/proc/task_mmu.c| 33 ++---
>  include/asm-generic/pgtable.h | 17 ++-
>  include/linux/huge_mm.h   | 14 +++--
>  mm/gup.c  | 22 --
>  mm/huge_memory.c  | 67 
> +++
>  mm/memcontrol.c   |  5 
>  mm/memory.c   | 12 ++--
>  mm/mprotect.c |  4 +--
>  mm/mremap.c   |  2 +-
>  10 files changed, 154 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/x86/mm/gup.c b/arch/x86/mm/gup.c
> index 456dfdfd2249..096bbcc801e6 100644
> --- a/arch/x86/mm/gup.c
> +++ b/arch/x86/mm/gup.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -243,9 +244,11 @@ static int gup_pmd_range(pud_t pud, unsigned long addr, 
> unsigned long end,
>   pmd_t pmd = *pmdp;
>  
>   next = pmd_addr_end(addr, end);
> - if (pmd_none(pmd))
> + if (!pmd_present(pmd)) {
> + VM_BUG_ON(is_swap_pmd(pmd) && 
> IS_ENABLED(CONFIG_MIGRATION) &&
> +   !is_pmd_migration_entry(pmd));

This VM_BUG_ON() triggers when gup is called on hugetlb hwpoison entry.
I think that in such case kernel falls into the gup slow path, and
a page fault in follow_hugetlb_page() can properly report the error to
affected processes, so no need to alarm with BUG_ON.

Could you make this VM_BUG_ON more specific, or just remove it?

Thanks,
Naoya Horiguchi

>   return 0;
> - if (unlikely(pmd_large(pmd) || !pmd_present(pmd))) {
> + } else if (unlikely(pmd_large(pmd))) {
>   /*
>* NUMA hinting faults need to be handled in the GUP
>* slowpath for accounting purposes and so that they



[PATCH 10/14] staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read

2017-07-14 Thread Arnd Bergmann
gcc-7 points out an older regression:

drivers/staging/iio/resolver/ad2s1210.c: In function 'ad2s1210_read_raw':
drivers/staging/iio/resolver/ad2s1210.c:515:42: error: '<<' in boolean context, 
did you mean '<' ? [-Werror=int-in-bool-context]

The original code had 'unsigned short' here, but incorrectly got
converted to 'bool'. This reverts the regression and uses a normal
type instead.

Fixes: 29148543c521 ("staging:iio:resolver:ad2s1210 minimal chan spec 
conversion.")
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/iio/resolver/ad2s1210.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/resolver/ad2s1210.c 
b/drivers/staging/iio/resolver/ad2s1210.c
index a6a8393d6664..3e00df74b18c 100644
--- a/drivers/staging/iio/resolver/ad2s1210.c
+++ b/drivers/staging/iio/resolver/ad2s1210.c
@@ -472,7 +472,7 @@ static int ad2s1210_read_raw(struct iio_dev *indio_dev,
 long m)
 {
struct ad2s1210_state *st = iio_priv(indio_dev);
-   bool negative;
+   u16 negative;
int ret = 0;
u16 pos;
s16 vel;
-- 
2.9.0



[PATCH 11/14] IB/uverbs: fix gcc-7 type warning

2017-07-14 Thread Arnd Bergmann
When using ccache, we get a harmless warning about the fact that
we use the result of a multiplication as a condition:

drivers/infiniband/core/uverbs_main.c: In function 'ib_uverbs_write':
drivers/infiniband/core/uverbs_main.c:787:40: error: '*' in boolean context, 
suggest '&&' instead [-Werror=int-in-bool-context]
drivers/infiniband/core/uverbs_main.c:787:117: error: '*' in boolean context, 
suggest '&&' instead [-Werror=int-in-bool-context]
drivers/infiniband/core/uverbs_main.c:790:50: error: '*' in boolean context, 
suggest '&&' instead [-Werror=int-in-bool-context]
drivers/infiniband/core/uverbs_main.c:790:151: error: '*' in boolean context, 
suggest '&&' instead [-Werror=int-in-bool-context]

This changes the macro to explicitly check the number for a positive
length, which avoids the warning.

Fixes: a96e4e2ffe43 ("IB/uverbs: New macro to set pointers to NULL if length is 
0 in INIT_UDATA()")
Signed-off-by: Arnd Bergmann 
---
 drivers/infiniband/core/uverbs.h | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/infiniband/core/uverbs.h b/drivers/infiniband/core/uverbs.h
index 64d494a64daf..364d7de05721 100644
--- a/drivers/infiniband/core/uverbs.h
+++ b/drivers/infiniband/core/uverbs.h
@@ -55,12 +55,14 @@
(udata)->outlen = (olen);   \
} while (0)
 
-#define INIT_UDATA_BUF_OR_NULL(udata, ibuf, obuf, ilen, olen)  
\
-   do {
\
-   (udata)->inbuf  = (ilen) ? (const void __user *) (ibuf) : NULL; 
\
-   (udata)->outbuf = (olen) ? (void __user *) (obuf) : NULL;   
\
-   (udata)->inlen  = (ilen);   
\
-   (udata)->outlen = (olen);   
\
+#define INIT_UDATA_BUF_OR_NULL(udata, ibuf, obuf, ilen, olen)  \
+   do {\
+   (udata)->inbuf  = (ilen) > 0 ?  \
+ (const void __user *) (ibuf) : NULL;  \
+   (udata)->outbuf = (olen) > 0 ?  \
+ (void __user *) (obuf) : NULL;\
+   (udata)->inlen  = (ilen);   \
+   (udata)->outlen = (olen);   \
} while (0)
 
 /*
-- 
2.9.0



[PATCH 13/14] iopoll: avoid -Wint-in-bool-context warning

2017-07-14 Thread Arnd Bergmann
When we pass the result of a multiplication as the timeout, we
can get a warning:

drivers/mmc/host/bcm2835.c:596:149: error: '*' in boolean context, suggest '&&' 
instead [-Werror=int-in-bool-context]
drivers/mfd/arizona-core.c:247:195: error: '*' in boolean context, suggest '&&' 
instead [-Werror=int-in-bool-context]

This is easy to avoid by comparing the timeout to zero instead,
making it a boolean expression.

Signed-off-by: Arnd Bergmann 
---
 include/linux/iopoll.h | 6 --
 include/linux/regmap.h | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
index d29e1e21bf3f..7a17ba02253b 100644
--- a/include/linux/iopoll.h
+++ b/include/linux/iopoll.h
@@ -48,7 +48,8 @@
(val) = op(addr); \
if (cond) \
break; \
-   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+   if ((timeout_us) > 0 && \
+   ktime_compare(ktime_get(), timeout) > 0) { \
(val) = op(addr); \
break; \
} \
@@ -82,7 +83,8 @@
(val) = op(addr); \
if (cond) \
break; \
-   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+   if ((timeout_us) > 0 && \
+   ktime_compare(ktime_get(), timeout) > 0) { \
(val) = op(addr); \
break; \
} \
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 1474ab0a3922..0889dbf37161 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -129,7 +129,7 @@ struct reg_sequence {
break; \
if (cond) \
break; \
-   if ((timeout_us) && \
+   if ((timeout_us) > 0 && \
ktime_compare(ktime_get(), __timeout) > 0) { \
__ret = regmap_read((map), (addr), &(val)); \
break; \
-- 
2.9.0



[PATCH 12/14] drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning

2017-07-14 Thread Arnd Bergmann
gcc thinks that interpreting a multiplication result as a bool
is confusing:

drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll':
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean 
context, suggest '&&' instead [-Werror=int-in-bool-context]

In this instance, I think using multiplication is more intuitive
than '&&', so I'm adding a comparison to zero instead to shut up
the warning. To further improve readability, I also make the
error case indented and leave the normal case as the final 'return'
statement.

Fixes: 7632b30e4b8b ("drm/nouveau/clk: namespace + nvidia gpu names (no binary 
change)")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
index 96e0941c8edd..04b4f4ccf186 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
@@ -130,10 +130,10 @@ read_pll(struct gt215_clk *clk, int idx, u32 pll)
sclk = read_clk(clk, 0x10 + idx, false);
}
 
-   if (M * P)
-   return sclk * N / (M * P);
+   if (M * P == 0)
+   return 0;
 
-   return 0;
+   return sclk * N / (M * P);
 }
 
 static int
-- 
2.9.0



Re: "mm: use early_pfn_to_nid in page_ext_init" broken on some configurations?

2017-07-14 Thread Vlastimil Babka
On 07/14/2017 11:13 AM, Michal Hocko wrote:
> On Fri 07-07-17 14:00:03, Vlastimil Babka wrote:
>> On 07/04/2017 07:17 AM, Joonsoo Kim wrote:

 Still, backporting b8f1a75d61d8 fixes this:

 [1.538379] allocated 738197504 bytes of page_ext
 [1.539340] Node 0, zone  DMA: page owner found early allocated 0 
 pages
 [1.540179] Node 0, zoneDMA32: page owner found early allocated 33 
 pages
 [1.611173] Node 0, zone   Normal: page owner found early allocated 
 96755 pages
 [1.683167] Node 1, zone   Normal: page owner found early allocated 
 96575 pages

 No panic, notice how it allocated more for page_ext, and found smaller 
 number of
 early allocated pages.

 Now backporting fe53ca54270a on top:

 [0.00] allocated 738197504 bytes of page_ext
 [0.00] Node 0, zone  DMA: page owner found early allocated 0 
 pages
 [0.00] Node 0, zoneDMA32: page owner found early allocated 33 
 pages
 [0.00] Node 0, zone   Normal: page owner found early allocated 
 2842622 pages
 [0.00] Node 1, zone   Normal: page owner found early allocated 
 3694362 pages

 Again no panic, and same amount of page_ext usage. But the "early 
 allocated" numbers
 seem bogus to me. I think it's because init_pages_in_zone() is running and 
 inspecting
 struct pages that have not been yet initialized. It doesn't end up 
 crashing, but
 still doesn't seem correct?
>>>
>>> Numbers looks sane to me. fe53ca54270a makes init_pages_in_zone()
>>> called before page_alloc_init_late(). So, there would be many
>>> uninitialized pages with PageReserved(). Page owner regarded these
>>> PageReserved() page as allocated page.
>>
>> That seems incorrect for two reasons:
>> - init_pages_in_zone() actually skips PageReserved() pages
>> - the pages don't have PageReserved() flag, until the deferred struct page 
>> init
>> thread processes them via deferred_init_memmap() -> __init_single_page() 
>> AFAICS
>>
>> Now I've found out why upstream reports much less early allocated pages than 
>> our
>> kernel. We're missing 9d43f5aec950 ("mm/page_owner: add zone range 
>> overlapping
>> check") which adds a "page_zone(page) != zone" check. I think this only works
>> because the pages are not initialized and thus have no nid/zone links. 
>> Probably
>> page_zone() only doesn't break because it's all zeroed. I don't think it's 
>> safe
>> to rely on this?
> 
> Yes, if anything PageReserved should be checked before the zone check.

That wouldn't change anything, because we skip PageReserved and it's not
set. Perhaps we could skip pages that have the raw page flags value
zero, but then a) we should make sure that the allocation of the struct
page array zeroes the range, and b) the first modification of struct
page in the initialization is setting the PageReserved flag.



Re: [PATCH 1/9] mm, page_alloc: rip out ZONELIST_ORDER_ZONE

2017-07-14 Thread Mel Gorman
On Fri, Jul 14, 2017 at 09:59:58AM +0200, Michal Hocko wrote:
> From: Michal Hocko 
> 
> Supporting zone ordered zonelists costs us just a lot of code while
> the usefulness is arguable if existent at all. Mel has already made
> node ordering default on 64b systems. 32b systems are still using
> ZONELIST_ORDER_ZONE because it is considered better to fallback to
> a different NUMA node rather than consume precious lowmem zones.
> 
> This argument is, however, weaken by the fact that the memory reclaim
> has been reworked to be node rather than zone oriented. This means
> that lowmem requests have to skip over all highmem pages on LRUs already
> and so zone ordering doesn't save the reclaim time much. So the only
> advantage of the zone ordering is under a light memory pressure when
> highmem requests do not ever hit into lowmem zones and the lowmem
> pressure doesn't need to reclaim.
> 
> Considering that 32b NUMA systems are rather suboptimal already and
> it is generally advisable to use 64b kernel on such a HW I believe we
> should rather care about the code maintainability and just get rid of
> ZONELIST_ORDER_ZONE altogether. Keep systcl in place and warn if
> somebody tries to set zone ordering either from kernel command line
> or the sysctl.
> 
> Cc: 
> Signed-off-by: Michal Hocko 
> index 80e4adb4c360..d9f4ea057e74 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4864,40 +4824,22 @@ int numa_zonelist_order_handler(struct ctl_table 
> *table, int write,
>   void __user *buffer, size_t *length,
>   loff_t *ppos)
>  {
> - char saved_string[NUMA_ZONELIST_ORDER_LEN];
> + char *str;
>   int ret;
> - static DEFINE_MUTEX(zl_order_mutex);
>  
> - mutex_lock(&zl_order_mutex);
> - if (write) {
> - if (strlen((char *)table->data) >= NUMA_ZONELIST_ORDER_LEN) {
> - ret = -EINVAL;
> - goto out;
> - }
> - strcpy(saved_string, (char *)table->data);
> + if (!write) {
> + int len = sizeof("Default");
> + if (copy_to_user(buffer, "Default", len))
> + return -EFAULT;
> + return len;
>   }

That should to be "default" because the original code would have the proc
entry display "default" unless it was set at runtime. Pretty weird I
know but it's always possible someone is parsing the original default
and not handling it properly.

Otherwise I think we're way past the point where large memory 32-bit
NUMA machines are a thing so

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs


Re: [PATCH 2/2] x86/idle: use dynamic halt poll

2017-07-14 Thread Alexander Graf



On 13.07.17 13:49, Yang Zhang wrote:

On 2017/7/4 22:13, Radim Krčmář wrote:

2017-07-03 17:28+0800, Yang Zhang:

The background is that we(Alibaba Cloud) do get more and more complaints
from our customers in both KVM and Xen compare to bare-mental.After
investigations, the root cause is known to us: big cost in message 
passing

workload(David show it in KVM forum 2015)

A typical message workload like below:
vcpu 0 vcpu 1
1. send ipi 2.  doing hlt
3. go into idle 4.  receive ipi and wake up from hlt
5. write APIC time twice6.  write APIC time twice to
   to stop sched timer  reprogram sched timer


One write is enough to disable/re-enable the APIC timer -- why does
Linux use two?


One is to remove the timer and another one is to reprogram the timer. 
Normally, only one write to remove the timer.But in some cases, it will 
reprogram it.





7. doing hlt8.  handle task and send ipi to
vcpu 0
9. same to 4.   10. same to 3

One transaction will introduce about 12 vmexits(2 hlt and 10 msr 
write). The

cost of such vmexits will degrades performance severely.


Yeah, sounds like too much ... I understood that there are

  IPI from 1 to 2
  4 * APIC timer
  IPI from 2 to 1

which adds to 6 MSR writes -- what are the other 4?


In the worst case, each timer will touch APIC timer twice.So it will add 
additional 4 msr writse. But this is  not always true.





 Linux kernel
already provide idle=poll to mitigate the trend. But it only 
eliminates the

IPI and hlt vmexit. It has nothing to do with start/stop sched timer. A
compromise would be to turn off NOHZ kernel, but it is not the default
config for new distributions. Same for halt-poll in KVM, it only 
solve the

cost from schedule in/out in host and can not help such workload much.

The purpose of this patch we want to improve current idle=poll 
mechanism to


Please aim to allow MWAIT instead of idle=poll -- MWAIT doesn't slow
down the sibling hyperthread.  MWAIT solves the IPI problem, but doesn't
get rid of the timer one.


Yes, i can try it. But MWAIT will not yield CPU, it only helps the 
sibling hyperthread as you mentioned.


If you implement proper MWAIT emulation that conditionally gets en- or 
disabled depending on the same halt poll dynamics that we already have 
for in-host HLT handling, it will also yield the CPU.


As for the timer - are you sure the problem is really the overhead of 
the timer configuration, not the latency that it takes to actually fire 
the guest timer?


One major problem I see is that we configure the host hrtimer to fire at 
the point in time when the guest wants to see a timer event. But in a 
virtual environment, the point in time when we have to start switching 
to the VM really should be a bit *before* the guest wants to be woken 
up, as it takes quite some time to switch back into the VM context.



Alex


[PATCH] KVM: VMX: Fix losing blocking by NMI in the guest interruptibility-state field

2017-07-14 Thread Wanpeng Li
From: Wanpeng Li 

Run kvm-unit-tests/eventinj.flat in L1 w/ ept=0 on both L0 and L1:

Before NMI IRET test
Sending NMI to self
NMI isr running stack 0x461000
Sending nested NMI to self
After nested NMI to self
Nested NMI isr running rip=40038e
After iret
After NMI to self
FAIL: NMI

Reference SDM 31.7.1.2:

 If the “virtual NMIs” VM-execution control is 1, bit 12 of the VM-exit 
 interruption-information field indicates that the VM exit was due to a fault 
 encountered during an execution of the IRET instruction that removed 
virtual-NMI 
 blocking. In particular, it provides this indication if the following are both 
 true:
 
  - Bit 31 (valid) in the IDT-vectoring information field is 0.
  - The value of bits 7:0 (vector) of the VM-exit interruption-information 
field is not 8 (the VM exit is not due to a double-fault exception).
 
 If both are true and bit 12 of the VM-exit interruption-information field is 
1, 
 there was virtual-NMI blocking before guest software executed the IRET 
instruction 
 that caused the fault that caused the VM exit. The VMM should set bit 3 
(blocking 
 by NMI) in the interruptibility-state field (using VMREAD and VMWRITE) before 
 resuming guest software.

However, commit 0be9c7a89f750 (KVM: VMX: set "blocked by NMI" flag if EPT 
violation happens during IRET from NMI) just fixes the fault due to EPT 
violation. 
This patch tries to fix the fault due to the page fault of shadow page table. 

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 84e62ac..32ca063 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5709,6 +5709,11 @@ static int handle_exception(struct kvm_vcpu *vcpu)
}
 
if (is_page_fault(intr_info)) {
+
+   if (!(to_vmx(vcpu)->idt_vectoring_info & 
VECTORING_INFO_VALID_MASK) &&
+   (intr_info & INTR_INFO_UNBLOCK_NMI))
+   vmcs_set_bits(GUEST_INTERRUPTIBILITY_INFO, 
GUEST_INTR_STATE_NMI);
+
cr2 = vmcs_readl(EXIT_QUALIFICATION);
/* EPT won't cause page fault directly */
WARN_ON_ONCE(!vcpu->arch.apf.host_apf_reason && enable_ept);
-- 
2.7.4



[PATCH] kmemleak: add oom= runtime parameter

2017-07-14 Thread shuwang
From: Shu Wang 

When running memory stress tests, kmemleak could be easily disabled in
function create_object as system is out of memory and kmemleak failed to
alloc from object_cache. Since there's no way to enable kmemleak after
it's off, simply ignore the object_cache alloc failure will just loses
track of some memory objects, but could increase the usability of kmemleak
under memory stress.

The default action for oom is still disable kmemleak,
echo oom=ignore > /sys/kernel/debug/kmemleak can change to action to
ignore oom.

Signed-off-by: Shu Wang 
---
 Documentation/dev-tools/kmemleak.rst |  5 +
 mm/kmemleak.c| 10 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/dev-tools/kmemleak.rst 
b/Documentation/dev-tools/kmemleak.rst
index cb88626..3013809 100644
--- a/Documentation/dev-tools/kmemleak.rst
+++ b/Documentation/dev-tools/kmemleak.rst
@@ -60,6 +60,11 @@ Memory scanning parameters can be modified at run-time by 
writing to the
 or free all kmemleak objects if kmemleak has been disabled.
 - dump=
 dump information about the object found at 
+- oom=disable
+disable kmemleak after system out of memory (default)
+- oom=ignore
+do not disable kmemleak after system out of memory
+(useful for memory stress test, but will lose some objects)
 
 Kmemleak can also be disabled at boot-time by passing ``kmemleak=off`` on
 the kernel command line.
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 7780cd8..a58080f 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -236,6 +236,9 @@ static DEFINE_MUTEX(scan_mutex);
 static int kmemleak_skip_disable;
 /* If there are leaks that can be reported */
 static bool kmemleak_found_leaks;
+/* If disable kmemleak after out of memory */
+static bool kmemleak_oom_disable = true;
+
 
 /*
  * Early object allocation/freeing logging. Kmemleak is initialized after the
@@ -556,7 +559,8 @@ static struct kmemleak_object *create_object(unsigned long 
ptr, size_t size,
object = kmem_cache_alloc(object_cache, gfp_kmemleak_mask(gfp));
if (!object) {
pr_warn("Cannot allocate a kmemleak_object structure\n");
-   kmemleak_disable();
+   if (kmemleak_oom_disable)
+   kmemleak_disable();
return NULL;
}
 
@@ -1888,6 +1892,10 @@ static ssize_t kmemleak_write(struct file *file, const 
char __user *user_buf,
kmemleak_scan();
else if (strncmp(buf, "dump=", 5) == 0)
ret = dump_str_object_info(buf + 5);
+   else if (strncmp(buf, "oom=ignore", 10))
+   kmemleak_oom_disable = false;
+   else if (strncmp(buf, "oom=disable", 11))
+   kmemleak_oom_disable = true;
else
ret = -EINVAL;
 
-- 
2.5.0



Re: [PATCH 2/9] mm, page_alloc: remove boot pageset initialization from memory hotplug

2017-07-14 Thread Mel Gorman
On Fri, Jul 14, 2017 at 09:59:59AM +0200, Michal Hocko wrote:
> From: Michal Hocko 
> 
> boot_pageset is a boot time hack which gets superseded by normal
> pagesets later in the boot process. It makes zero sense to reinitialize
> it again and again during memory hotplug.
> 
> Signed-off-by: Michal Hocko 

You could also go slightly further and remove the batch parameter to
setupo_pageset because it's always 0. Otherwise

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs


Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings

2017-07-14 Thread Chen-Yu Tsai
On Fri, Jul 14, 2017 at 5:26 PM, Ulf Hansson  wrote:
> On 14 July 2017 at 08:42, Chen-Yu Tsai  wrote:
>> On the SoCs that introduced the new timing mode for MMC controllers,
>> both the old (where the clock delays are set in the CCU) and new
>> (where the clock delays are set in the MMC controller) timing modes
>> are available, and we have to support them both. However there are
>> two bits that control which mode is active. One is in the CCU, the
>> other is in the MMC controller. The settings on both sides must be
>> the same, or nothing will work.
>>
>> The CCU's get/set_phase callbacks return -ENOTSUPP when the new
>> timing mode is active. This provides a way to know which mode is
>> active on that side, and we can set the bit on the MMC controller
>> side accordingly.

Argh... I forgot to update the commit log... :(

>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  drivers/mmc/host/sunxi-mmc.c | 34 ++
>>  1 file changed, 30 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>> index 0fb4e4c119e1..56e45c65b52d 100644
>> --- a/drivers/mmc/host/sunxi-mmc.c
>> +++ b/drivers/mmc/host/sunxi-mmc.c
>> @@ -22,6 +22,7 @@
>>  #include 
>>
>>  #include 
>> +#include 
>
> I don't like this. This looks like an SoC specific hack.
>
>>  #include 
>>  #include 
>>  #include 
>> @@ -259,7 +260,7 @@ struct sunxi_mmc_cfg {
>> /* Does DATA0 needs to be masked while the clock is updated */
>> bool mask_data0;
>>
>> -   bool needs_new_timings;
>> +   bool has_new_timings;
>>  };
>>
>>  struct sunxi_mmc_host {
>> @@ -293,6 +294,9 @@ struct sunxi_mmc_host {
>>
>> /* vqmmc */
>> boolvqmmc_enabled;
>> +
>> +   /* timings */
>> +   booluse_new_timings;
>>  };
>>
>>  static int sunxi_mmc_reset_host(struct sunxi_mmc_host *host)
>> @@ -714,7 +718,7 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host 
>> *host,
>>  {
>> int index;
>>
>> -   if (!host->cfg->clk_delays)
>> +   if (host->use_new_timings)
>> return 0;
>>
>> /* determine delays */
>> @@ -765,6 +769,15 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
>> *host,
>> ios->bus_width == MMC_BUS_WIDTH_8)
>> clock <<= 1;
>>
>> +   if (host->use_new_timings) {
>> +   ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
>
> Can't this be solved through some other generic API/interface?

The old discussion is here: https://lkml.org/lkml/2017/5/5/77

It is possible to piggy back on existing API, but as Maxime mentioned
back in the discussion, it is confusing.

IIRC Mike said (via Maxime) an SoC specific call was the easy way
to handle this. I don't think there's anything generic about this.
Even if you could have a _set_mode callback for the clks, the modes
would be SoC specific anyway.

ChenYu

>
>> +   if (ret) {
>> +   dev_err(mmc_dev(mmc),
>> +   "error setting new timing mode\n");
>> +   return ret;
>> +   }
>> +   }
>> +
>
> [...]
>
> Kind regards
> Uffe


[PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

2017-07-14 Thread Arnd Bergmann
v4l2_subdev_call is a macro returning whatever the callback return
type is, usually 'int'. With gcc-7 and ccache, this can lead to
many wanings like:

media/platform/pxa_camera.c: In function 'pxa_mbus_build_fmts_xlate':
media/platform/pxa_camera.c:766:27: error: ?: using integer constants in 
boolean context [-Werror=int-in-bool-context]
  while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, &code)) {
media/atomisp/pci/atomisp2/atomisp_cmd.c: In function 'atomisp_s_ae_window':
media/atomisp/pci/atomisp2/atomisp_cmd.c:6414:52: error: ?: using integer 
constants in boolean context [-Werror=int-in-bool-context]
  if (v4l2_subdev_call(isp->inputs[asd->input_curr].camera,

The best workaround I could come up with is to change all the
callers that use the return code from v4l2_subdev_call() in an
'if' or 'while' condition.

In case of simple 'if' checks, adding a temporary variable is
usually ok, and sometimes this can be used to propagate or
print an error code, so I do that.

For the 'while' loops, I ended up adding an otherwise useless
comparison with zero, which unfortunately makes the code a little
uglied.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/pci/cx18/cx18-ioctl.c  |  6 --
 drivers/media/pci/saa7146/mxb.c  |  5 +++--
 drivers/media/platform/atmel/atmel-isc.c |  4 ++--
 drivers/media/platform/atmel/atmel-isi.c |  4 ++--
 drivers/media/platform/blackfin/bfin_capture.c   |  4 ++--
 drivers/media/platform/omap3isp/ispccdc.c|  5 +++--
 drivers/media/platform/pxa_camera.c  |  3 ++-
 drivers/media/platform/rcar-vin/rcar-core.c  |  2 +-
 drivers/media/platform/rcar-vin/rcar-dma.c   |  4 +++-
 drivers/media/platform/soc_camera/soc_camera.c   |  4 ++--
 drivers/media/platform/stm32/stm32-dcmi.c|  4 ++--
 drivers/media/platform/ti-vpe/cal.c  |  6 --
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 13 +++--
 13 files changed, 37 insertions(+), 27 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-ioctl.c 
b/drivers/media/pci/cx18/cx18-ioctl.c
index 80b902b12a78..1803f28fc501 100644
--- a/drivers/media/pci/cx18/cx18-ioctl.c
+++ b/drivers/media/pci/cx18/cx18-ioctl.c
@@ -188,6 +188,7 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
void *fh,
 {
struct cx18 *cx = fh2id(fh)->cx;
struct v4l2_sliced_vbi_format *vbifmt = &fmt->fmt.sliced;
+   int ret;
 
/* sane, V4L2 spec compliant, defaults */
vbifmt->reserved[0] = 0;
@@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
void *fh,
 * digitizer/slicer.  Note, cx18_av_vbi() wipes the passed in
 * fmt->fmt.sliced under valid calling conditions
 */
-   if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced))
-   return -EINVAL;
+   ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced);
+   if (ret)
+   return ret;
 
vbifmt->service_set = cx18_get_service_set(vbifmt);
return 0;
diff --git a/drivers/media/pci/saa7146/mxb.c b/drivers/media/pci/saa7146/mxb.c
index 504d78807639..d2d843c38579 100644
--- a/drivers/media/pci/saa7146/mxb.c
+++ b/drivers/media/pci/saa7146/mxb.c
@@ -525,8 +525,9 @@ static int vidioc_s_input(struct file *file, void *fh, 
unsigned int input)
return err;
 
/* switch video in saa7111a */
-   if (saa7111a_call(mxb, video, s_routing, i, SAA7111_FMT_CCIR, 0))
-   pr_err("VIDIOC_S_INPUT: could not address saa7111a\n");
+   err = saa7111a_call(mxb, video, s_routing, i, SAA7111_FMT_CCIR, 0);
+   if (err)
+   pr_err("VIDIOC_S_INPUT: could not address saa7111a: %d\n", err);
 
mxb->cur_audinput = video_audio_connect[input];
/* switch the audio-source only if necessary */
diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index d6534252cdcd..704b34a0cc00 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -1475,8 +1475,8 @@ static int isc_formats_init(struct isc_device *isc)
fmt++;
}
 
-   while (!v4l2_subdev_call(subdev, pad, enum_mbus_code,
-  NULL, &mbus_code)) {
+   while (v4l2_subdev_call(subdev, pad, enum_mbus_code,
+  NULL, &mbus_code) == 0) {
mbus_code.index++;
fmt = find_format_by_code(mbus_code.code, &i);
if (!fmt)
diff --git a/drivers/media/platform/atmel/atmel-isi.c 
b/drivers/media/platform/atmel/atmel-isi.c
index 891fa2505efa..30b7e6f298ed 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -1013,8 +1013,8 @@ static int isi_formats_init(struct atmel_isi *isi)
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
 
-

[PATCH v3] spi: loopback-test: provide loop_req option.

2017-07-14 Thread Oleksij Rempel
Provide a module parameter to request internal loop by the SPI master
controller.
This should make loop testing easier without extra HW modification.

For test automation a logic analyzer is recommended for host
controller-independent verification.
An example test rig configuration and procedure:
  i.MX6S RIoRBoard   Logic Analyzer
  -
  (J13  4) GND - GND
  (J13  6) CSPI3-CLK --> PIN 3
  (J13  8) CSPI3-MOSI <- PIN 2
 ^ - internal loop configured by SPI_LOOP
 |   or can be user external jamper.
  (J13 10) CSPI3-MISO -> PIN 1

grab some data and decode it:
sigrok-cli -d fx2lafw --time 16 --config samplerate=10m  \
  --channels 0-2 -o dump.sr
sigrok-cli -i dump.sr -P spi:mosi=1:clk=2 > result_for_regression_tests

Signed-off-by: Oleksij Rempel 
---
v3:
- more rewording after feed back provided by Paul Ferster 

v2:
- some spelling fixes
- add more background about testing setup
- reword error message.

 drivers/spi/spi-loopback-test.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/spi/spi-loopback-test.c b/drivers/spi/spi-loopback-test.c
index f4875f177df0..cfc7222f0a85 100644
--- a/drivers/spi/spi-loopback-test.c
+++ b/drivers/spi/spi-loopback-test.c
@@ -51,6 +51,12 @@ MODULE_PARM_DESC(loopback,
 "is checked to match tx_buf after the spi_message "\
 "is executed");
 
+int loop_req;
+module_param(loop_req, int, 0);
+MODULE_PARM_DESC(loop_req,
+"if set controller will be asked to enable test loop mode. " \
+"If controller supported it, MISO and MOSI will be connected");
+
 /* run only a specific test */
 int run_only_test = -1;
 module_param(run_only_test, int, 0);
@@ -313,6 +319,16 @@ static int spi_loopback_test_probe(struct spi_device *spi)
 {
int ret;
 
+   if (loop_req) {
+   spi->mode = SPI_LOOP | spi->mode;
+   ret = spi_setup(spi);
+   if (ret) {
+   dev_err(&spi->dev, "SPI setup with SPI_LOOP failed 
(%d)\n",
+   ret);
+   return ret;
+   }
+   }
+
dev_info(&spi->dev, "Executing spi-loopback-tests\n");
 
ret = spi_test_run_tests(spi, spi_tests);
-- 
2.11.0



[linux-next][bisected 1c0eaf0f] Today's next kernel fails to boot on ppc bare-metal

2017-07-14 Thread Abdul Haleem
Hi 

Today's linux-next fails to boot on ppc bare-metal

Test: Boot
Machine: Power 8 bare-metal
kernel: 4.12.0-next-20170713
gcc: version 4.8.5
config : Tul-NV-config attached.

boot logs:
--
OPAL nvram setup, 1048576 bytes
Zone ranges:
  DMA  [mem 0x-0x000f]
  DMA32empty
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x-0x0007]
  node   1: [mem 0x0008-0x000f]
Initmem setup node 0 [mem 0x-0x0007]

Machine boot is stuck after this.

Possible first bad commit looks to be :

1c0eaf0f56d6128af7f0f252855173fcee85d202 is the first bad commit
commit 1c0eaf0f56d6128af7f0f252855173fcee85d202
Author: Benjamin Herrenschmidt 
Date:   Fri Jun 30 17:37:32 2017 -0500

powerpc/powernv: Tell OPAL about our MMU mode on POWER9

That will allow OPAL to configure the CPU in an optimal way.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Michael Neuling 
Signed-off-by: Michael Ellerman 

:04 04 6605393385631357131c0701795e1d51c8e458c8 

git bisect start
# good: [a2b313034fc5c6870ddf2d116f16d45e38c6a64e] Merge branch 'pci-pm'
into linux-next
git bisect good a2b313034fc5c6870ddf2d116f16d45e38c6a64e
# bad: [4f318fb1406897652aedea36d062b89b33adcab3] Merge branch
'akpm-current/current'
git bisect bad 4f318fb1406897652aedea36d062b89b33adcab3
# bad: [8f3788ee212bb8089f3c8c69577f53790a17cc4e] Merge remote-tracking
branch 'vfs/for-next'
git bisect bad 8f3788ee212bb8089f3c8c69577f53790a17cc4e
# bad: [b7190d530867970e917c76033e4725e57d6d2c08] Merge remote-tracking
branch 'sparc/master'
git bisect bad b7190d530867970e917c76033e4725e57d6d2c08
# good: [3bf7878f0f7d60c394f6d6631bb179e86f09f73c] Merge tag
'ceph-for-4.13-rc1' of git://github.com/ceph/ceph-client
git bisect good 3bf7878f0f7d60c394f6d6631bb179e86f09f73c
# good: [6b1c776d3efbda31085b6a9f3bc7f774511fafd9] Merge branch
'overlayfs-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs
git bisect good 6b1c776d3efbda31085b6a9f3bc7f774511fafd9
# good: [fb4e3beeffa47619985f190663c6ef424f063a22] Merge tag
'iommu-updates-v4.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
git bisect good fb4e3beeffa47619985f190663c6ef424f063a22
# good: [606fd2788b0fce6f5138078a4fbe8979ecba5697] i2c: algo-bit: add
support for I2C_M_STOP
git bisect good 606fd2788b0fce6f5138078a4fbe8979ecba5697
# good: [9809cb831c9645d61ee9501c308045bb3d8afd31] i2c: designware: fix
spelling mistakes
git bisect good 9809cb831c9645d61ee9501c308045bb3d8afd31
# good: [6be1d03c529d922c7d65608638f4431a85272aa9] Merge remote-tracking
branch 'arc-current/for-curr'
git bisect good 6be1d03c529d922c7d65608638f4431a85272aa9
# bad: [3a6a04706fd08eb5677fdfc086e26fcd5eb154f4] powerpc/mm/radix:
Synchronize updates to the process table
git bisect bad 3a6a04706fd08eb5677fdfc086e26fcd5eb154f4
# bad: [1c0eaf0f56d6128af7f0f252855173fcee85d202] powerpc/powernv: Tell
OPAL about our MMU mode on POWER9
git bisect bad 1c0eaf0f56d6128af7f0f252855173fcee85d202
# good: [1e2a516e89fc412a754327522ab271b42f99c6b4] powerpc/kexec: Fix
radix to hash kexec due to IAMR/AMOR
git bisect good 1e2a516e89fc412a754327522ab271b42f99c6b4
# first bad commit: [1c0eaf0f56d6128af7f0f252855173fcee85d202]
powerpc/powernv: Tell OPAL about our MMU mode on POWER9

-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre


#
# Automatically generated file; DO NOT EDIT.
# Linux/powerpc 4.10.0-rc2 Kernel Configuration
#
CONFIG_PPC64=y

#
# Processor support
#
CONFIG_PPC_BOOK3S_64=y
# CONFIG_PPC_BOOK3E_64 is not set
# CONFIG_POWER7_CPU is not set
CONFIG_POWER8_CPU=y
CONFIG_PPC_BOOK3S=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_VSX=y
# CONFIG_PPC_ICSWX is not set
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_64=y
CONFIG_PPC_RADIX_MMU=y
CONFIG_PPC_MM_SLICES=y
CONFIG_PPC_HAVE_PMU_SUPPORT=y
CONFIG_PPC_PERF_CTRS=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2048
CONFIG_PPC_DOORBELL=y
# CONFIG_CPU_BIG_ENDIAN is not set
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_PPC64_BOOT_WRAPPER=y
CONFIG_64BIT=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NR_IRQS=512
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK=y
CONFIG_PPC=y
CONFIG_GENERIC_CSUM=y
CONFIG_EARLY_PRINTK=y
CONFIG_PANIC_TIMEOUT=180
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_EPAPR_BOOT=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
# CONFIG_PPC_OF_PLATFORM

Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode

2017-07-14 Thread Chen-Yu Tsai
On Fri, Jul 14, 2017 at 5:16 PM, Ulf Hansson  wrote:
> On 14 July 2017 at 08:42, Chen-Yu Tsai  wrote:
>> The register for the "new timing mode" also has bit fields for setting
>> output and sample timing phases. According to comments in Allwinner's
>> BSP kernel, the default values are good enough.
>>
>> Keep the default values already in the hardware when setting new timing
>> mode, instead of overwriting the whole register.
>>
>> Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
>>   controllers")
>> Signed-off-by: Chen-Yu Tsai 
>
> It looks like this change doesn't depend on anything else? Do you want
> me to pick it up for fixes and adding stable tag?

Yes, please.

ChenYu

>
> Kind regards
> Uffe
>
>> ---
>>  drivers/mmc/host/sunxi-mmc.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>> index d6fa2214aaae..0fb4e4c119e1 100644
>> --- a/drivers/mmc/host/sunxi-mmc.c
>> +++ b/drivers/mmc/host/sunxi-mmc.c
>> @@ -793,8 +793,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
>> *host,
>> }
>> mmc_writel(host, REG_CLKCR, rval);
>>
>> -   if (host->cfg->needs_new_timings)
>> -   mmc_writel(host, REG_SD_NTSR, SDXC_2X_TIMING_MODE);
>> +   if (host->cfg->needs_new_timings) {
>> +   /* Don't touch the delay bits */
>> +   rval = mmc_readl(host, REG_SD_NTSR);
>> +   rval |= SDXC_2X_TIMING_MODE;
>> +   mmc_writel(host, REG_SD_NTSR, rval);
>> +   }
>>
>> ret = sunxi_mmc_clk_set_phase(host, ios, rate);
>> if (ret)
>> --
>> 2.13.2
>>


Re: [PATCH 11/14] IB/uverbs: fix gcc-7 type warning

2017-07-14 Thread Leon Romanovsky
On Fri, Jul 14, 2017 at 11:31:04AM +0200, Arnd Bergmann wrote:
> When using ccache, we get a harmless warning about the fact that
> we use the result of a multiplication as a condition:
>
> drivers/infiniband/core/uverbs_main.c: In function 'ib_uverbs_write':
> drivers/infiniband/core/uverbs_main.c:787:40: error: '*' in boolean context, 
> suggest '&&' instead [-Werror=int-in-bool-context]
> drivers/infiniband/core/uverbs_main.c:787:117: error: '*' in boolean context, 
> suggest '&&' instead [-Werror=int-in-bool-context]
> drivers/infiniband/core/uverbs_main.c:790:50: error: '*' in boolean context, 
> suggest '&&' instead [-Werror=int-in-bool-context]
> drivers/infiniband/core/uverbs_main.c:790:151: error: '*' in boolean context, 
> suggest '&&' instead [-Werror=int-in-bool-context]
>
> This changes the macro to explicitly check the number for a positive
> length, which avoids the warning.
>
> Fixes: a96e4e2ffe43 ("IB/uverbs: New macro to set pointers to NULL if length 
> is 0 in INIT_UDATA()")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/infiniband/core/uverbs.h | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
>

Thanks,
Reviewed-by: Leon Romanovsky 


signature.asc
Description: PGP signature


Re: [PATCH 3/9] mm, page_alloc: do not set_cpu_numa_mem on empty nodes initialization

2017-07-14 Thread Mel Gorman
On Fri, Jul 14, 2017 at 10:00:00AM +0200, Michal Hocko wrote:
> From: Michal Hocko 
> 
> __build_all_zonelists reinitializes each online cpu local node for
> CONFIG_HAVE_MEMORYLESS_NODES. This makes sense because previously memory
> less nodes could gain some memory during memory hotplug and so the local
> node should be changed for CPUs close to such a node. It makes less
> sense to do that unconditionally for a newly creaded NUMA node which is
> still offline and without any memory.
> 
> Let's also simplify the cpu loop and use for_each_online_cpu instead of
> an explicit cpu_online check for all possible cpus.
> 
> Signed-off-by: Michal Hocko 
> ---
>  mm/page_alloc.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7746824a425d..ebc3311555b1 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5096,10 +5096,8 @@ static int __build_all_zonelists(void *data)
>  
>   build_zonelists(pgdat);
>   }
> - }
>  
>  #ifdef CONFIG_HAVE_MEMORYLESS_NODES
> - for_each_possible_cpu(cpu) {
>   /*
>* We now know the "local memory node" for each node--
>* i.e., the node of the first zone in the generic zonelist.
> @@ -5108,10 +5106,10 @@ static int __build_all_zonelists(void *data)
>* secondary cpus' numa_mem as they come on-line.  During
>* node/memory hotplug, we'll fixup all on-line cpus.
>*/
> - if (cpu_online(cpu))
> + for_each_online_cpu(cpu)
>   set_cpu_numa_mem(cpu, 
> local_memory_node(cpu_to_node(cpu)));
> - }
>  #endif
> + }
>  

This is not as clear a benefit. For each online node, we now go through
all online CPUs once per node. There would be some rationale for using
for_each_online_cpu.

-- 
Mel Gorman
SUSE Labs


Re: [PATCH 4.4 00/57] 4.4.77-stable review

2017-07-14 Thread Greg Kroah-Hartman
On Thu, Jul 13, 2017 at 06:33:06PM -0700, Guenter Roeck wrote:
> On 07/13/2017 08:42 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.77 release.
> > There are 57 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Jul 15 15:39:40 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 145 pass: 143 fail: 2
> Failed builds:
>   arm:allmodconfig
>   arm:shmobile_defconfig
> Qemu test results:
>   total: 115 pass: 103 fail: 12
> Failed tests:
>   arm:beagle:multi_v7_defconfig:omap3-beagle
>   arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
>   arm:overo:multi_v7_defconfig:omap3-overo-tobi
>   arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
>   arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>   arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
>   arm:midway:multi_v7_defconfig:ecx-2000
>   arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
> 
> Build failures:
> 
> drivers/pinctrl/sh-pfc/pfc-r8a7791.c:1096:2: error: implicit declaration of 
> function 'PINMUX_IPSR_GPSR'
> drivers/pinctrl/sh-pfc/pfc-r8a7791.c:1096:19: error: 'IP6_2_0' undeclared here
> drivers/pinctrl/sh-pfc/pfc-r8a7791.c:1096:28: error: 'DVC_MUTE' undeclared 
> here
> 
> The build failures are also the cause of the qemu test failures.

Ok, I've found the bad patch, the author marked that it should have
applied for this kernel, but obviously it didn't :)

Now dropped, so all should be well.

thanks,

greg k-h


Re: [PATCH 10/18] drm/sun4i: tcon: Move out the tcon0 common setup

2017-07-14 Thread kbuild test robot
Hi Maxime,

[auto build test ERROR on next-20170710]
[cannot apply to mripard/sunxi/for-next robh/for-next regmap/for-next v4.12 
v4.12-rc7 v4.12-rc6 v4.12]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-sun4i-Allwinner-MIPI-DSI-support/20170714-123103
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/sun4i/sun4i_tcon.c: In function 
'sun4i_tcon0_mode_set_common':
>> drivers/gpu/drm/sun4i/sun4i_tcon.c:132:2: error: implicit declaration of 
>> function 'clk_set_rate_protect' [-Werror=implicit-function-declaration]
 clk_set_rate_protect(tcon->dclk, mode->crtc_clock * 1000);
 ^~~~
   cc1: some warnings being treated as errors

vim +/clk_set_rate_protect +132 drivers/gpu/drm/sun4i/sun4i_tcon.c

   127  
   128  static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
   129  struct drm_display_mode *mode)
   130  {
   131  /* Configure the dot clock */
 > 132  clk_set_rate_protect(tcon->dclk, mode->crtc_clock * 1000);
   133  
   134  /* Set the resolution */
   135  regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
   136   SUN4I_TCON0_BASIC0_X(mode->crtc_hdisplay) |
   137   SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
   138  }
   139  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH 4.4 00/57] 4.4.77-stable review

2017-07-14 Thread Greg Kroah-Hartman
On Thu, Jul 13, 2017 at 02:07:45PM -0700, kernelci.org bot wrote:
> stable-rc/linux-4.4.y boot: 99 boots: 1 failed, 92 passed with 5 offline, 1 
> conflict (v4.4.76-58-g1a12e8e8a429)

Any idea how 0-day and Guenter's system found problems with this
release, but you all didn't?  Do you not have any SH systems in
kernelci?

thanks,

greg k-h


Re: [PATCH 4.12 00/10] 4.12.2-stable review

2017-07-14 Thread Greg Kroah-Hartman
On Thu, Jul 13, 2017 at 07:08:54PM -0700, Guenter Roeck wrote:
> On 07/13/2017 08:40 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.12.2 release.
> > There are 10 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Jul 15 15:40:02 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 145 pass: 145 fail: 0
> Qemu test results:
>   total: 122 pass: 122 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h


Re: [PATCH 4.12 00/10] 4.12.2-stable review

2017-07-14 Thread Greg Kroah-Hartman
On Thu, Jul 13, 2017 at 03:07:46PM -0700, kernelci.org bot wrote:
> stable-rc/linux-4.12.y boot: 226 boots: 5 failed, 216 passed with 4 offline, 
> 1 conflict (v4.12.1-11-g28917cd49df9)

Should I be concerned about these 5 failures?  No other test systems
shows any problems...

thanks,

greg k-h


Re: [PATCH 4.9 00/25] 4.9.38-stable review

2017-07-14 Thread Greg Kroah-Hartman
On Thu, Jul 13, 2017 at 01:47:46PM -0700, kernelci.org bot wrote:
> stable-rc/linux-4.9.y boot: 246 boots: 6 failed, 237 passed with 2 offline, 1 
> conflict (v4.9.37-26-g996828f64cac)

Are these 6 failures "ok" to ignore?

thanks,

greg k-h


[GIT PULL] MMC fixes for v.4.13 rc1

2017-07-14 Thread Ulf Hansson
Hi Linus,

Here are a couple of mmc fixes intended for v4.13 rc1. They are based
on a commit from your tree earlier during the merge window and have
been tested in linux-next for a few days.

Details are as usual found in the signed tag. Please pull this in!

Kind regards
Ulf Hansson


The following changes since commit 9967468c0a109644e4a1f5b39b39bf86fe7507a7:

  Merge branch 'akpm' (patches from Andrew) (2017-07-10 16:58:42 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v4.13-2

for you to fetch changes up to 9c284c41c0886f09e75c323a16278b6d353b0b4a:

  mmc: tmio-mmc: fix bad pointer math (2017-07-13 11:56:35 +0200)


MMC core:
 - Restore some behaviour of MMC_IOC_MULTI_CMD commands
 - Fix using un-initialized variable in mmc_blk_issue_drv_op()
 - Fix mmc block queue cleanup

MMC host:
 - sdhci-acpi: Workaround conflict with PCI wifi on GPD Win handheld
 - tmio-mmc: Fix bad pointer math


Adrian Hunter (1):
  mmc: sdhci-acpi: Workaround conflict with PCI wifi on GPD Win handheld

Chris Brandt (1):
  mmc: tmio-mmc: fix bad pointer math

Geert Uytterhoeven (2):
  mmc: block: Initialize ret in mmc_blk_issue_drv_op() for MMC_DRV_OP_IOCTL
  mmc: block: Let MMC_IOC_MULTI_CMD return zero again for zero entries

Grzegorz Sluja (1):
  mmc: block: Prevent new req entering queue after its cleanup

 drivers/mmc/core/block.c |  6 +++-
 drivers/mmc/host/sdhci-acpi.c| 70 
 drivers/mmc/host/tmio_mmc_core.c | 19 ++-
 3 files changed, 78 insertions(+), 17 deletions(-)


  1   2   3   4   5   6   7   8   >