Re: [PATCH 1/3] fpga manager: Add cyclonespi driver for Altera fpgas

[atull]

On Fri, 7 Oct 2016, Moritz Fischer wrote:

> > +static inline u32 revbit8x4(u32 n)
> > +{
> > +   n = ((n & 0xF0F0F0F0UL) >> 4) | ((n & 0x0F0F0F0FUL) << 4);
> > +   n = ((n & 0xUL) >> 2) | ((n & 0xUL) << 2);
> > +   n = ((n & 0xUL) >> 1) | ((n & 0xUL) << 1);
> > +   return n;
> > +}
> 
> During the Zynq FPGA manager reviews we decided that manipulating the 
> bitstream
> to be consumable by the driver is userland's job.

Moritz, Can you remind me what that issue was there (or point me to
that email, I can't find it)?  I don't think I had a problem with that
in your case.  In general I think if these drivers can take the
bitstream that comes from the manufacturer's tools and stuff it into
the FPGA, then we are accomplishing what we want.  So I am OK with
this here.  The intent of the driver is to load a standard rbf, same
as the other Altera FPGA drivers.

There is a problem here though it will be easy to fix.  This call to
revbit8x4 should happen in cyclonespi_write(), not in
cyclonespi_write_init(). The reason for that is that write_init() may
just get the first chunk of the image (the header) and that write()
will be called multiple times for the remaining chunks.  The current
FPGA manager API won't show this problem since you have to give
fpga_mgr_buf_load the whole image buffer at once.  But it is easy to
imagine that some time in the future we may want to expand the FPGA
manager API to support streaming where we don't have the whole buffer.

Thanks for submitting, Joshua.  Will be looking at this over the
next several days.

Alan

Re: [PATCH] scripts/coccicheck: Update reference for the corresponding documentation

[Julia Lawall]

On Fri, 7 Oct 2016, SF Markus Elfring wrote:

> From: Markus Elfring 
> Date: Fri, 7 Oct 2016 16:06:15 +0200
>
> Use the current name (in a comment at the beginning of this script) for
> the file which was converted to the documentation format "reStructuredText"
> in August 2016.
>
> Fixes: 4b9033a33494ec9154d63e706e9e47f7eb3fd59e ("docs: sphinxify 
> coccinelle.txt and add it to dev-tools")
> Signed-off-by: Markus Elfring 

Acked-by: Julia Lawall 

> ---
>  scripts/coccicheck | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/coccicheck b/scripts/coccicheck
> index c92c1528..ec487b8 100755
> --- a/scripts/coccicheck
> +++ b/scripts/coccicheck
> @@ -1,7 +1,7 @@
>  #!/bin/bash
>  # Linux kernel coccicheck
>  #
> -# Read Documentation/coccinelle.txt
> +# Read Documentation/dev-tools/coccinelle.rst
>  #
>  # This script requires at least spatch
>  # version 1.0.0-rc11.
> --
> 2.10.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH][V2] nbd: add multi-connection support

[Pavel Machek]

On Thu 2016-09-15 10:43:54, Josef Bacik wrote:
> NBD can become contended on its single connection.  We have to serialize all
> writes and we can only process one read response at a time.  Fix this by
> allowing userspace to provide multiple connections to a single nbd device.  
> This
> coupled with block-mq drastically increases performance in multi-process 
> cases.
> Thanks,
> 
> Signed-off-by: Josef Bacik 

Idea is that it can now use multiple CPUs concurrently...?

Do you have a diff for the nbd-server, too?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH 13/34] staging:r8188eu: remove ExternalPA member of hal_data_8188e structure

[Ivan Safonov]

ExternalPA always is false.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/hal/rf.c   | 2 --
 drivers/staging/rtl8188eu/include/rtl8188e_hal.h | 1 -
 2 files changed, 3 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/rf.c 
b/drivers/staging/rtl8188eu/hal/rf.c
index 2f3edf0..eddd075 100644
--- a/drivers/staging/rtl8188eu/hal/rf.c
+++ b/drivers/staging/rtl8188eu/hal/rf.c
@@ -61,8 +61,6 @@ void rtl88eu_phy_rf6052_set_cck_txpower(struct adapter 
*adapt, u8 *powerlevel)
  (powerlevel[idx1]<<8) |
  (powerlevel[idx1]<<16) |
  (powerlevel[idx1]<<24);
-   if (tx_agc[idx1] > 0x20 && hal_data->ExternalPA)
-   tx_agc[idx1] = 0x20;
}
} else {
if (pdmpriv->DynamicTxHighPowerLvl == TxHighPwrLevel_Level1) {
diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_hal.h 
b/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
index 19264a2..942ce91 100644
--- a/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
+++ b/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
@@ -268,7 +268,6 @@ struct hal_data_8188e {
u32 AntennaTxPath;  /*  Antenna path Tx */
u32 AntennaRxPath;  /*  Antenna path Rx */
u8  BluetoothCoexist;
-   u8  ExternalPA;
 
u8  b1x1RecvCombine;/*  for 1T1R receive combining */
 
-- 
2.7.3

Re: [PATCH] Staging:fbtft/fb_s6d02a1.c: fixed 80 character line limit coding

[Nadim Almas]

why its seems worst to you i am just removing  "80 character line
limit coding style"
for the last 3 months I am trying to submit my first patch but patch
is not accepted by you by giving reason i can't able to understand
please help me

On Fri, Oct 7, 2016 at 10:37 PM, Greg KH  wrote:
> On Fri, Oct 07, 2016 at 08:43:02AM -0700, Nadim Almas wrote:
>> style issue
>>
>> Fixed coding style issue
>
> This does not seem like valid sentances that mean much to me.  Do they
> to you?
>
>>
>> Signed-off-by: Nadim Almas 
>> ---
>>  drivers/staging/fbtft/fb_s6d02a1.c | 30 --
>>  1 file changed, 20 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/staging/fbtft/fb_s6d02a1.c 
>> b/drivers/staging/fbtft/fb_s6d02a1.c
>> index 774b0ff..bc0c48f 100644
>> --- a/drivers/staging/fbtft/fb_s6d02a1.c
>> +++ b/drivers/staging/fbtft/fb_s6d02a1.c
>> @@ -30,20 +30,27 @@ static int default_init_sequence[] = {
>>
>>   -1, 0xfc, 0x5a, 0x5a,
>>
>> - -1, 0xfa, 0x02, 0x1f, 0x00, 0x10, 0x22, 0x30, 0x38, 0x3A, 0x3A, 0x3A, 
>> 0x3A, 0x3A, 0x3d, 0x02, 0x01,
>> + -1, 0xfa, 0x02, 0x1f, 0x00, 0x10, 0x22, 0x30, 0x38, 0x3A, 0x3A, 0x3A,
>> + 0x3A, 0x3A, 0x3d, 0x02, 0x01,
>
> This looks worse to me now, remember, checkpatch.pl is a "hint", not a
> hard-and-fast-rule.  Use it wisely.
>
> greg k-h

Re: [PATCH] tpm: don't destroy chip device prematurely

[Jason Gunthorpe]

On Fri, Oct 07, 2016 at 02:24:59PM +, Winkler, Tomas wrote:

> So here I'm to say I'm sorry for misleading this, after all the
> doubts I got back to debugging and traces.  One thing for a reason
> moving the device_del, had really made the problem go away, but the
> real problem was unbalance runtime_pm PUT/GET from the tpm_crb probe
> function.

Oh this is very good news, I'm glad this was resolved in crb!

Presumably the unbalanced put made the ref count go negative and the
balanced get caused it to go to zero, so pm locking was basically totally
broken? That would explain how an idle callback could run
concurrently with transmit_cmd.

Though a bit of a mystery why device_del had any impact? I'm still
very unclear exactly how the child device effects the parent - and
that seems like pretty important information going forward..

Thanks,
Jason

Re: [GIT PULL] trivial for 4.9

[Linus Torvalds]

On Fri, Oct 7, 2016 at 1:51 AM, Jiri Kosina  wrote:
> Colin Ian King (5):
>   netfilter: Add missing \n to pr_err() message
>   agp/intel: add missing \n to end of dev_emerg message
>   lightnvm: add missing \n to end of dev_err message
>   nvme: add missing \n to end of dev_warn message

We really shouldn't be needing these final '\n' characters any more, afaik.

If the next printk isn't done by the same process, and doesn't have a
KERN_CONT, the printk machinery should add the newline on its own.

I realize that people have been adding these '\n' characters for a
while, but is there actually any point to it? They make the code less
legible, imho. And we actually have a number of logging functions that
explicitly don't want the newline (eg ext4_warning/error()), so it's
actually more consistent to *not* have a newline than it is to have
one.

And if those '\n' characters actually make a difference, that should
be noted. Because that would imply that the printk logic isn't working
right.

Hmm?

   Linus

[PATCH] sound: soc: cygnus: add depends on HAS_DMA

[Scott Branden]

add depends on HAS_DMA to Kconfig.  This fixes error reported
by kbuild test robot when building for ARCH=m32r:
ERROR: "bad_dma_ops" [sound/soc/bcm/snd-soc-cygnus.ko] undefined!

Signed-off-by: Scott Branden 
---
 sound/soc/bcm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index d528aac..edf3671 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -11,6 +11,7 @@ config SND_BCM2835_SOC_I2S
 config SND_SOC_CYGNUS
tristate "SoC platform audio for Broadcom Cygnus chips"
depends on ARCH_BCM_CYGNUS || COMPILE_TEST
+   depends on HAS_DMA
help
  Say Y if you want to add support for ASoC audio on Broadcom
  Cygnus chips (bcm958300, bcm958305, bcm911360)
-- 
2.5.0

Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed

[Zach Brown]

On Thu, Oct 06, 2016 at 09:13:24AM +0300, Adrian Hunter wrote:
> On 06/10/16 04:34, Shawn Lin wrote:
> > On 2016/10/6 5:22, Julia Cartwright wrote:
> >> On Wed, Oct 05, 2016 at 03:03:44PM -0500, Rob Herring wrote:
> >>> On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson  
> >>> wrote:
>  On 23 September 2016 at 22:01, Zach Brown  wrote:
> > Certain board configurations can make highspeed malfunction due to
> > timing issues. In these cases a way is needed to force the controller
> > and card into standard speed even if they otherwise appear to be capable
> > of highspeed.
> >
> > The sd-broken-highspeed property will let the sdhci driver know that
> > highspeed will not work.
> >
> > Signed-off-by: Zach Brown 
> > ---
> >  Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt
> > b/Documentation/devicetree/bindings/mmc/mmc.txt
> > index 8a37782..59332ea 100644
> > --- a/Documentation/devicetree/bindings/mmc/mmc.txt
> > +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
> > @@ -52,6 +52,8 @@ Optional properties:
> >  - no-sdio: controller is limited to send sdio cmd during initialization
> >  - no-sd: controller is limited to send sd cmd during initialization
> >  - no-mmc: controller is limited to send mmc cmd during initialization
> > +- sd-broken-highspeed: Highspeed is broken, even if the controller and
> > card
> > +  themselves claim they support highspeed.
> 
>  Regarding a broken card, that is managed via the card quirks and not in 
>  DT.
> 
>  If this is about a controller limitation, we already have the option
>  to describe what it supports, so we don't need an option to tell what
>  it *not* supports.
> 
>  For example "cap-sd-highspeed" tells whether the controller supports
>  SD high-speed, please use that instead.
> >>>
> >>> If a controller has a capability register and it lies (perhaps the
> >>> board has limitations that the SoC does not), then you may need to
> >>> disable a feature.
> >>
> >> That's precisely the case here.  This is a board-level problem, not a
> >> card or controller problem.  As Zach mentioned in the cover letter, the
> >> trace length between controller and card on some of our boards is too
> >> long to meet high-speed timings, even though both card and controller
> >> advertise it.
> >
> > IIRC, I saw the same problem while using sdhci to bring up a
> > industrial board for vehicle. The trace length is so long that
> > I have to limit the max-frequency to make it works properly when
> > running at hishspeed.
> >
> > So could you try to limit the max-frequency in your DT to see
> > if it could work for you? I guess it should work as once reducing
> > the frequency, the timing per cycle will be large enough to meet
> > the spec. At least that helped me solve my problem.
> >
> > For further consideration, I deployed a mechanism called "tuning for
> > non UHS or non-hs200/400" for my donwstream tree at that time. The basic
> > concept is to ask devices to send ext_csd(or send status for SD case)
> > *repeatedly*. Some hosts, i.e. sdhci-of-arasan or dw_mmc-rockchip, can
> > manually set rx delay via some clock unit registers to capture the
> > working sample window and select the middle point of the longest good
> > phase region. The same for retune. But it is a little complicated, and
> > could only be applicable to the hosts who could adjust the rx delay
> > manually when claiming the caps of MMC_CAPS_CAN_TUNING_FOR_HS, whatever
> > the name is...
> >
> > I don't know if it is worth to add this, and I don't know if it's
> > a legit way. Anyway, I just share my thought(experience) for you and
> > linux-mmc to think more about how to deal with the case you meet rather
> > than sacrificing the performence by removing highspeed or reducing
> > frequency..
> >
>
> As Shawn points out, using max-frequency is a possibility. Did you consider
> that?
>

I hadn't. So I looked into it and, as I stated the issue using max-frequency
would work, but I forgot to add that, because we pass the signal through an
fpga it has to be standard speed. If the card and controller are not in
standard speed then it won't pass hold time. Specifically we need the data to
change on the falling edge of the clock.

I'll add this justification to the commit message.

> There are 2 high speed caps:
>   cap-sd-highspeed
>   cap-mmc-highspeed
>
> Yet patch in 2, the effect of sd-broken-highspeed is to suppress highspeed
> for both SD and MMC.  Should it then be called just broken-highspeed?
>

I agree, broken-highspeed makes more sense. Will change in the next version.

Re: [PATCHv2 1/2] Documentation: dt: spi: Add GPIO Slave Select Parameter

[Geert Uytterhoeven]

On Fri, Oct 7, 2016 at 4:56 PM,   wrote:
> From: Thor Thayer 
>
> Some SPI masters require the slave to be selected before a
> transaction can occur - even in the case of GPIO chip select.
>
> This patch adds a GPIO slave select parameter to indicate
> the slave needs to be selected in the GPIO CS case.
>
> Signed-off-by: Thor Thayer 
> ---
> v2  Add to SPI framework - add bindings.
> ---
>  Documentation/devicetree/bindings/spi/spi-bus.txt |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt 
> b/Documentation/devicetree/bindings/spi/spi-bus.txt
> index 4b1d6e7..3a006bc 100644
> --- a/Documentation/devicetree/bindings/spi/spi-bus.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
> @@ -24,6 +24,7 @@ support describing the chip select layout.
>  Optional properties:
>  - cs-gpios   - gpios chip select.
>  - num-cs - total number of chipselects.
> +- gpio-ss- use internal slave select with gpio chip select.
>
>  If cs-gpios is used the number of chip selects will be increased 
> automatically
>  with max(cs-gpios > hw cs).

To me, this looks more like a new flag the SPI controller driver should
set in spi_master.flags, instead of a DT property.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 0/2] [media] dvb-tc90522: Fine-tuning for two function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 7 Oct 2016 21:38:12 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Use kmalloc_array()
  Rename a jump label

 drivers/media/dvb-frontends/tc90522.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

-- 
2.10.1

Re: [PATCHv2 1/2] Documentation: dt: spi: Add GPIO Slave Select Parameter

[Thor Thayer]

On 10/07/2016 02:33 PM, Geert Uytterhoeven wrote:

On Fri, Oct 7, 2016 at 4:56 PM,   wrote:

From: Thor Thayer 

Some SPI masters require the slave to be selected before a
transaction can occur - even in the case of GPIO chip select.

This patch adds a GPIO slave select parameter to indicate
the slave needs to be selected in the GPIO CS case.

Signed-off-by: Thor Thayer 
---
v2  Add to SPI framework - add bindings.
---
 Documentation/devicetree/bindings/spi/spi-bus.txt |1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt 
b/Documentation/devicetree/bindings/spi/spi-bus.txt
index 4b1d6e7..3a006bc 100644
--- a/Documentation/devicetree/bindings/spi/spi-bus.txt
+++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -24,6 +24,7 @@ support describing the chip select layout.
 Optional properties:
 - cs-gpios   - gpios chip select.
 - num-cs - total number of chipselects.
+- gpio-ss- use internal slave select with gpio chip select.

 If cs-gpios is used the number of chip selects will be increased automatically
 with max(cs-gpios > hw cs).


To me, this looks more like a new flag the SPI controller driver should
set in spi_master.flags, instead of a DT property.

Yes, I see your point since this is SPI master specific. I'll respin as 
you suggest.


Thanks for reviewing!


Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] usb: dwc3: Fix size used in dma_free_coherent()

[Christophe JAILLET]

In commit 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support"), the
size of the memory allocated with 'dma_alloc_coherent()' has been modified
but the corresponding calls to 'dma_free_coherent()' have not been updated
accordingly.

This has been spotted with coccinelle, using the following script:

@r@
expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
@@

*   ret = dma_alloc_coherent(x0, y0, z0, t0);
...
*   dma_free_coherent(x1, y1, ret, t1);


@script:python@
y0 << r.y0;
y1 << r.y1;

@@
if y1.find(y0) == -1:
 print "WARNING: sizes look different:  '%s'   vs   '%s'" % (y0, y1)


Fixes: 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support")

Signed-off-by: Christophe JAILLET 
---
Untested
---
 drivers/usb/dwc3/gadget.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 07cc8929f271..01d388ea9115 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2980,7 +2980,7 @@ int dwc3_gadget_init(struct dwc3 *dwc)
kfree(dwc->setup_buf);
 
 err2:
-   dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+   dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
 
 err1:
@@ -3005,7 +3005,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
kfree(dwc->setup_buf);
kfree(dwc->zlp_buf);
 
-   dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+   dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
 
dma_free_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
-- 
2.7.4

Re: [PATCH 1/3] fpga manager: Add cyclonespi driver for Altera fpgas

[Moritz Fischer]

Hi Alan,

On Fri, Oct 7, 2016 at 11:21 AM, atull  wrote:

> Moritz, Can you remind me what that issue was there (or point me to
> that email, I can't find it)?  I don't think I had a problem with that
> in your case.  In general I think if these drivers can take the
> bitstream that comes from the manufacturer's tools and stuff it into
> the FPGA, then we are accomplishing what we want.  So I am OK with
> this here.  The intent of the driver is to load a standard rbf, same
> as the other Altera FPGA drivers.

My first version of the zynq fpga manager had byte swapping in there
and detection of which format was used. Greg even (accidentially)
merged my initial code
which I then cleaned up in 4d10eaff5bfc69997a769f9c83b749f0a8c542fa
("fpga: zynq-fpga: Change fw format to handle bin instead of bit.") to
address the review
comments.

I do see your point about useability, and if this is something that
keeps coming up
we could pull that into the framework with a flag to SWAP or as part
of the image_information
struct.

Thoughts?

Cheers,

Moritz

[1] https://mail-archive.com/linux-kernel@vger.kernel.org/msg995245.html

Re: [PATCH 1/2] power: bq27xxx_battery: add configurable poll_interval by sysfs

[Pavel Machek]

On Fri 2016-09-16 20:42:54, Matt Ranostay wrote:
> Allow the poll_interval to be runtime configurable via an sysfs entry.
> This is needed for udev control of the poll interval.
> 
> Signed-off-by: Matt Ranostay 

working mail address would be nice here.

sysfs files should be documented.

Also... what is it good for?

Do you have a device that needs non-standard interval?
Pavel

> ---
>  drivers/power/supply/bq27xxx_battery.c | 48 
> +-
>  1 file changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/power/supply/bq27xxx_battery.c 
> b/drivers/power/supply/bq27xxx_battery.c
> index 3f57dd54803a..955424e10ae2 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -395,6 +395,36 @@ module_param(poll_interval, uint, 0644);
>  MODULE_PARM_DESC(poll_interval,
>"battery poll interval in seconds - 0 disables polling");
>  
> +
> +static ssize_t show_poll_interval(struct device *dev,
> +   struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d\n", poll_interval);
> +}
> +
> +static ssize_t store_poll_interval(struct device *dev,
> +struct device_attribute *attr,
> +const char *buf, size_t size)
> +{
> + struct bq27xxx_device_info *di = dev_get_drvdata(dev);
> + int tmp = poll_interval;
> +
> + if (sscanf(buf, "%d\n", _interval) != 1)
> + return -EINVAL;
> +
> + if (poll_interval < 0)
> + return -EINVAL;
> +
> + if (tmp != poll_interval) {
> + cancel_delayed_work_sync(>work);
> + schedule_delayed_work(>work, 0);
> + }
> +
> + return size;
> +}
> +
> +static DEVICE_ATTR(poll_interval, 0644, show_poll_interval, 
> store_poll_interval);
> +
>  /*
>   * Common code for BQ27xxx devices
>   */
> @@ -946,6 +976,7 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
>  {
>   struct power_supply_desc *psy_desc;
>   struct power_supply_config psy_cfg = { .drv_data = di, };
> + int ret;
>  
>   INIT_DELAYED_WORK(>work, bq27xxx_battery_poll);
>   mutex_init(>lock);
> @@ -961,11 +992,19 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info 
> *di)
>   psy_desc->num_properties = bq27xxx_battery_props[di->chip].size;
>   psy_desc->get_property = bq27xxx_battery_get_property;
>   psy_desc->external_power_changed = bq27xxx_external_power_changed;
> + dev_set_drvdata(di->dev, di);
> +
> + ret = sysfs_create_file(>dev->kobj, _attr_poll_interval.attr);
> + if (ret) {
> + dev_err(di->dev, "failed to register poll_interval sysfs 
> entry");
> + return ret;
> + }
>  
>   di->bat = power_supply_register_no_ws(di->dev, psy_desc, _cfg);
>   if (IS_ERR(di->bat)) {
>   dev_err(di->dev, "failed to register battery\n");
> - return PTR_ERR(di->bat);
> + ret = PTR_ERR(di->bat);
> + goto err_out;
>   }
>  
>   dev_info(di->dev, "support ver. %s enabled\n", DRIVER_VERSION);
> @@ -973,6 +1012,11 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info 
> *di)
>   bq27xxx_battery_update(di);
>  
>   return 0;
> +
> +err_out:
> + sysfs_remove_file(>dev->kobj, _attr_poll_interval.attr);
> +
> + return ret;
>  }
>  EXPORT_SYMBOL_GPL(bq27xxx_battery_setup);
>  
> @@ -988,6 +1032,8 @@ void bq27xxx_battery_teardown(struct bq27xxx_device_info 
> *di)
>  
>   cancel_delayed_work_sync(>work);
>  
> + sysfs_remove_file(>dev->kobj, _attr_poll_interval.attr);
> +
>   power_supply_unregister(di->bat);
>  
>   mutex_destroy(>lock);

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH 31/34] staging:r8188eu: remove precv_frame_buf member of recv_priv structure

[Ivan Safonov]

precv_frame_buf is used as local variable only in one function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_recv.c| 4 +---
 drivers/staging/rtl8188eu/include/rtw_recv.h | 1 -
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_recv.c 
b/drivers/staging/rtl8188eu/core/rtw_recv.c
index f046c41..a1b30a5 100644
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -71,9 +71,7 @@ int _rtw_init_recv_priv(struct recv_priv *precvpriv, struct 
adapter *padapter)
if (!precvpriv->pallocated_frame_buf)
return _FAIL;
 
-   precvpriv->precv_frame_buf = PTR_ALIGN(precvpriv->pallocated_frame_buf, 
RXFRAME_ALIGN_SZ);
-
-   precvframe = (struct recv_frame *)precvpriv->precv_frame_buf;
+   precvframe = (struct recv_frame 
*)PTR_ALIGN(precvpriv->pallocated_frame_buf, RXFRAME_ALIGN_SZ);
 
for (i = 0; i < NR_RECVFRAME; i++) {
INIT_LIST_HEAD(&(precvframe->list));
diff --git a/drivers/staging/rtl8188eu/include/rtw_recv.h 
b/drivers/staging/rtl8188eu/include/rtw_recv.h
index ffbbbd1..979961d 100644
--- a/drivers/staging/rtl8188eu/include/rtw_recv.h
+++ b/drivers/staging/rtl8188eu/include/rtw_recv.h
@@ -165,7 +165,6 @@ struct recv_priv {
struct __queue recv_pending_queue;
struct __queue uc_swdec_pending_queue;
u8 *pallocated_frame_buf;
-   u8 *precv_frame_buf;
struct adapter  *adapter;
u32 bIsAnyNonBEPkts;
u64 rx_bytes;
-- 
2.7.3

Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping

[Yinghai Lu]

On Fri, Oct 7, 2016 at 6:00 AM, Thomas Gleixner  wrote:
> On Fri, 7 Oct 2016, Thomas Gleixner wrote:
>> On Fri, 7 Oct 2016, Dou Liyang wrote:
>> > Is it possible that the "-1/ox" could appear in the MADT which is 
>> > one
>> > of the ACPI tables?
>>
>> According to the SDM the x2apic id is a 32bit ID, so 0x is a
>> legitimate value.
>
> The ACPI spec says that bit 0 of the x2apic flags field tells whether the
> logical processor is present or not. So the proper check for x2apic is that
> flag.
>
> The lapic structure has the same flag, but the kernel ignores the flags for
> both lapic and x2apic.
>
> I'm going to apply the minimal fix of checking for id == 0xff in
> acpi_lapic_parse() for now, but this needs to be revisited and fixed
> proper.

Good to me. Thanks for fixing it.

Yinghai

Re: [PATCH 2/4][RFC v2] PM / sleep: Introduce arch-specific hook for disable/enable nonboot cpus

[Andy Lutomirski]

On 06/25/2016 09:18 AM, Chen Yu wrote:

There is requirement that we need to do some arch-specific
operations before putting the nonboot CPUs offline/online.
One of the requirements comes from the hibernation resume
process on x86_64, we need to kick all the offlin-CPUs
online and offline again, in order to put them in a safe
state, thus to avoid possible unwilling wake up during
hibernation resume.

Signed-off-by: Chen Yu 
---
 kernel/cpu.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index d25266e..ce6e5e4 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1017,6 +1017,16 @@ EXPORT_SYMBOL_GPL(cpu_up);
 #ifdef CONFIG_PM_SLEEP_SMP
 static cpumask_var_t frozen_cpus;

+void __weak arch_disable_nonboot_cpus_pre(void)


I don't like using __weak.  It penalizes code size on architectures that 
don't hook these functions.  My preferred pattern is:


include/linux/something.h:

#include 

#ifndef arch_do_xyz
static inline void arch_do_xyz() {}
#endif

arch/whatever/asm/something.h:

extern void arch_do_xyz();  /* or static inline... */
#define arch_do_xyz


This is totally free for architectures that don't have the hooks and it 
can potentially be inlined on architectures that do have the hooks. 
Everyone wins except that it's about five additional lines of code.


--Andy

[v4.8-rc1 Regression] sched/fair: Apply more PELT fixes

[Joseph Salisbury]

Hello Peter,

A kernel bug report was opened against Ubuntu [0].  After a kernel
bisect, it was found that reverting the following commit resolved this bug:

commit 3d30544f02120b884bba2a9466c87dba980e3be5
Author: Peter Zijlstra 
Date:   Tue Jun 21 14:27:50 2016 +0200

sched/fair: Apply more PELT fixes

The regression was introduced as of v4.8-rc1.  The bug can be reproduced
on an X1 Carbon with the following:
stress -c $your_total_cpu_cores

I was hoping to get your feedback, since you are the patch author.  Do
you think gathering any additional data will help diagnose this issue,
or would it be best to submit a revert request? 


Thanks,

Joe


[0] http://pad.lv/1627108

[PATCH 1/2] [media] dvb-tc90522: Use kmalloc_array() in tc90522_master_xfer()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 7 Oct 2016 21:07:43 +0200

A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/tc90522.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/tc90522.c 
b/drivers/media/dvb-frontends/tc90522.c
index 31cd325..c2d45f0 100644
--- a/drivers/media/dvb-frontends/tc90522.c
+++ b/drivers/media/dvb-frontends/tc90522.c
@@ -656,7 +656,7 @@ tc90522_master_xfer(struct i2c_adapter *adap, struct 
i2c_msg *msgs, int num)
for (i = 0; i < num; i++)
if (msgs[i].flags & I2C_M_RD)
rd_num++;
-   new_msgs = kmalloc(sizeof(*new_msgs) * (num + rd_num), GFP_KERNEL);
+   new_msgs = kmalloc_array(num + rd_num, sizeof(*new_msgs), GFP_KERNEL);
if (!new_msgs)
return -ENOMEM;
 
-- 
2.10.1

Re: tty, fbcon: use-after-free in fbcon_invert_region

[Dmitry Vyukov]

On Sat, Sep 3, 2016 at 9:20 PM, Dmitry Vyukov  wrote:
> Hello,
>
> The following program causes use-after-free in fbcon_invert_region:
>
> https://gist.githubusercontent.com/dvyukov/d657f9a9ca39f34c430dcf63ec1153ac/raw/04e1b94aef0fc9eb770d11373b568980ecaa7f34/gistfile1.txt
>
> ==
> BUG: KASAN: use-after-free in fbcon_invert_region+0x1cc/0x1f0 at addr
> 88006cc3f51e
> Read of size 2 by task a.out/4240
> CPU: 0 PID: 4240 Comm: a.out Not tainted 4.8.0-rc3-next-20160825+ #10
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  886b6fe0 88003699f790 82db3759 8a0ae640
>  fbfff10d6dfc 88003e800100 88006cc3f500 88006cc3f520
>   88006cc3f51e 88003699f7b8 81809e7c
>
> Call Trace:
>  [] __asan_report_load2_noabort+0x14/0x20
> mm/kasan/report.c:325
>  [] fbcon_invert_region+0x1cc/0x1f0
> drivers/video/console/fbcon.c:2750
>  [] invert_screen+0x192/0x630 drivers/tty/vt/vt.c:470
>  [< inline >] highlight drivers/tty/vt/selection.c:50
>  [] clear_selection+0x4c/0x60 drivers/tty/vt/selection.c:76
>  [] hide_cursor+0x24e/0x2d0 drivers/tty/vt/vt.c:599
>  [] redraw_screen+0x2e7/0x840 drivers/tty/vt/vt.c:682
>  [] vc_do_resize+0xebc/0x1160 drivers/tty/vt/vt.c:952
>  [] vt_resize+0xaa/0xe0 drivers/tty/vt/vt.c:992
>  [< inline >] tiocswinsz drivers/tty/tty_io.c:2378
>  [] tty_ioctl+0x10c1/0x21e0 drivers/tty/tty_io.c:2892
>  [< inline >] vfs_ioctl fs/ioctl.c:43
>  [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>  [< inline >] SYSC_ioctl fs/ioctl.c:690
>  [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>  [] entry_SYSCALL_64_fastpath+0x23/0xc1
> arch/x86/entry/entry_64.S:208
> Object at 88006cc3f500, in cache kmalloc-32 size: 32
>
> Allocated:
> PID = 3233
>  [< inline >] kmalloc ./include/linux/slab.h:490
>  [< inline >] kzalloc ./include/linux/slab.h:636
>  [] aa_alloc_task_context+0x54/0x90
> security/apparmor/context.c:40
>  [] apparmor_cred_prepare+0x1d/0xb0 
> security/apparmor/lsm.c:76
>  [] security_prepare_creds+0x7d/0xb0 security/security.c:912
>  [] prepare_kernel_cred+0x375/0x650 kernel/cred.c:630
>  [] call_usermodehelper_exec_async+0xb9/0x460
> kernel/kmod.c:232
>  [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
>
> Freed:
> PID = 1693
>  [< inline >] __cache_free mm/slab.c:3520
>  [] kfree+0xc3/0x2a0 mm/slab.c:3837
>  [] kzfree+0x28/0x30 mm/slab_common.c:1323
>  [] aa_free_task_context+0x121/0x1d0
> security/apparmor/context.c:54
>  [] apparmor_cred_free+0x39/0x80 security/apparmor/lsm.c:51
>  [] security_cred_free+0x48/0x80 security/security.c:907
>  [] put_cred_rcu+0xe4/0x3e0 kernel/cred.c:116
>  [< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
>  [< inline >] rcu_do_batch kernel/rcu/tree.c:2777
>  [< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3041
>  [< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3008
>  [] rcu_process_callbacks+0xdbb/0x1560 
> kernel/rcu/tree.c:3025
>  [] __do_softirq+0x25c/0xa3e kernel/softirq.c:273
> Memory state around the buggy address:
>  88006cc3f400: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
>  88006cc3f480: 00 00 fc fc fc fc fc fc fb fb fb fb fc fc fc fc
>>88006cc3f500: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
> ^
>  88006cc3f580: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
>  88006cc3f600: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
> ==
>
>
> I am also hitting similar bugs all over fbcon:
>
> BUG: KASAN: slab-out-of-bounds in fbcon_putcs+0x444/0x4b0 at addr
> 8800384e58a8
>
> https://gist.githubusercontent.com/dvyukov/645a5f48b735fb384de7ea35fe1748ea/raw/3690a8b2c82a3b8fd7d07f4602a166f5756c3749/gistfile1.txt
>
> BUG: KASAN: slab-out-of-bounds in bit_putcs+0xcd6/0xd70 at addr 
> 88006abad8e6
>
> https://gist.githubusercontent.com/dvyukov/2d909f2673eafbc35f7f17f95c395217/raw/83f4eb0193226d51c546015cddee4b6a697015b3/gistfile1.txt
>
> BUG: KASAN: use-after-free in fbcon_putcs+0x444/0x4b0 at addr 8800644bd820
>
> https://gist.githubusercontent.com/dvyukov/286cdf2d3f9c6956ec9055dad0cf7a2a/raw/f7e0a380be364afd0c2c4c54ff5661e451fb143d/gistfile1.txt
>
> BUG: KASAN: slab-out-of-bounds in do_update_region+0x642/0x670 at addr
> 8800661c56ac
>
> https://gist.githubusercontent.com/dvyukov/7fd9d858ea38e8131e21a0377435c32c/raw/5d59989e05b4e39bb5ee90f49658674fa9db89ad/gistfile1.txt
>
> On 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next.


A friendly ping. This still happens at insane rate on
a6930aaee06755d1bdcfd943fbf614e4d92bb0c7 (Oct 5).

RE: [PATCH] tpm: don't destroy chip device prematurely

[Winkler, Tomas]

> Subject: Re: [PATCH] tpm: don't destroy chip device prematurely
> 
> On Fri, Oct 07, 2016 at 02:24:59PM +, Winkler, Tomas wrote:
> 
> > So here I'm to say I'm sorry for misleading this, after all the doubts
> > I got back to debugging and traces.  One thing for a reason moving the
> > device_del, had really made the problem go away, but the real problem
> > was unbalance runtime_pm PUT/GET from the tpm_crb probe function.
> 
> Oh this is very good news, I'm glad this was resolved in crb!
> 
> Presumably the unbalanced put made the ref count go negative and the
> balanced get caused it to go to zero, so pm locking was basically totally
> broken? That would explain how an idle callback could run concurrently with
> transmit_cmd.

This is not due to locking and refcount, but similar. The usage_count went 
negative  and the idle callback kicked in from the pm work queue, and suspended 
the device.

> 
> Though a bit of a mystery why device_del had any impact? I'm still very
> unclear exactly how the child device effects the parent - and that seems like
> pretty important information going forward..

Yes, there is some dependency as if device_del is not called the idle callback 
doesn't kick in between send and receive and that was misleading.  I'm not sure 
but this could be due to scheduling of the pm worker, but I'm not sure.   In 
any case we hit the issue even w/o device_del if the device is exercise enough. 
 I will dig into that later.

Thanks
Tomas

Re: [PATCHv2] hwmon: Add tc654 driver

[Guenter Roeck]

On Fri, Oct 07, 2016 at 02:38:44PM +1300, Chris Packham wrote:
> Add support for the tc654 and tc655 fan controllers from Microchip.
> 
> http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
> 
> Signed-off-by: Chris Packham 
> ---
> 
> Changes in v2:
> - Add Documentation/hwmon/tc654
> - Incorporate most of the review comments from Guenter. Additional error
>   handling is added. Unused/unnecessary code is removed. I decided not
>   to go down the regmap path yet. I may circle back to it when I look at
>   using regmap in the adm9240 driver.
> 
>  .../devicetree/bindings/i2c/trivial-devices.txt|   2 +
>  Documentation/hwmon/tc654  |  26 ++
>  drivers/hwmon/Kconfig  |  11 +
>  drivers/hwmon/Makefile |   1 +
>  drivers/hwmon/tc654.c  | 513 
> +
>  5 files changed, 553 insertions(+)
>  create mode 100644 Documentation/hwmon/tc654
>  create mode 100644 drivers/hwmon/tc654.c
> 
> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> index 1416c6a0d2cd..833fb9f133d3 100644
> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> @@ -122,6 +122,8 @@ microchip,mcp4662-502 Microchip 8-bit Dual I2C 
> Digital Potentiometer with NV Mem
>  microchip,mcp4662-103Microchip 8-bit Dual I2C Digital Potentiometer 
> with NV Memory (10k)
>  microchip,mcp4662-503Microchip 8-bit Dual I2C Digital Potentiometer 
> with NV Memory (50k)
>  microchip,mcp4662-104Microchip 8-bit Dual I2C Digital Potentiometer 
> with NV Memory (100k)
> +microchip,tc654  PWM Fan Speed Controller With Fan Fault 
> Detection
> +microchip,tc655  PWM Fan Speed Controller With Fan Fault 
> Detection
>  national,lm63Temperature sensor with integrated fan control
>  national,lm75I2C TEMP SENSOR
>  national,lm80Serial Interface ACPI-Compatible Microprocessor 
> System Hardware Monitor
> diff --git a/Documentation/hwmon/tc654 b/Documentation/hwmon/tc654
> new file mode 100644
> index ..93796c5c7e79
> --- /dev/null
> +++ b/Documentation/hwmon/tc654
> @@ -0,0 +1,26 @@
> +Kernel driver tc654
> +===
> +
> +Supported chips:
> +  * Microship TC654 and TC655
> +Prefix: 'tc654'
> +Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
> +
> +Authors:
> +Chris Packham 
> +Masahiko Iwamoto 
> +
> +Description
> +---
> +This driver implements support for the Microchip TC654 and TC655.
> +
> +The TC654 used the 2-wire interface compatible with the SMBUS 2.0

uses

> +specification. The TC654 has two (2) inputs for measuring fan RPM and
> +one (1) PWM output which can be used for fan control.
> +
> +Configuration Notes
> +---
> +Ordinarily the pwm1_mode ABI is used for controlling the pwm output
> +mode.  However, for this chip the output is always pwm, and the
> +pwm1_mode determines if the pwm output is controlled via the pwm1 value
> +or via the Vin analog input.

Please describe the supported values here.

> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 45cef3d2c75c..8681bc65cde5 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -907,6 +907,17 @@ config SENSORS_MCP3021
> This driver can also be built as a module.  If so, the module
> will be called mcp3021.
>  
> +config SENSORS_TC654
> + tristate "Microchip TC654/TC655 and compatibles"
> + depends on I2C
> + help
> +   If you say yes here you get support for TC654 and TC655.
> +   The TC654 and TC655 are PWM mode fan speed controllers with
> +   FanSense technology for use with brushless DC fans.
> +
> +   This driver can also be built as a module.  If so, the module
> +   will be called tc654.
> +
>  config SENSORS_MENF21BMC_HWMON
>   tristate "MEN 14F021P00 BMC Hardware Monitoring"
>   depends on MFD_MENF21BMC
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index aecf4ba17460..c651f0f1d047 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -122,6 +122,7 @@ obj-$(CONFIG_SENSORS_MAX6697) += max6697.o
>  obj-$(CONFIG_SENSORS_MAX31790)   += max31790.o
>  obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
>  obj-$(CONFIG_SENSORS_MCP3021)+= mcp3021.o
> +obj-$(CONFIG_SENSORS_TC654)  += tc654.o
>  obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
>  obj-$(CONFIG_SENSORS_NCT6683)+= nct6683.o
>  obj-$(CONFIG_SENSORS_NCT6775)+= nct6775.o
> diff --git a/drivers/hwmon/tc654.c b/drivers/hwmon/tc654.c
> new file mode 100644
> index ..cba31cbd3383
> --- 

[PATCH 05/34] staging:r8188eu: remove skb data alignment in r8188eu driver code

[Ivan Safonov]

(__)netdev_alloc_skb align skb data.
Also this function set skb device.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c   | 10 +-
 drivers/staging/rtl8188eu/include/rtw_recv.h |  2 --
 drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c |  8 +---
 3 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c 
b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
index 67a765a..1c7a9a0 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
@@ -61,23 +61,15 @@ int rtw_hal_init_recv_priv(struct adapter *padapter)
skb_queue_head_init(>rx_skb_queue);
{
int i;
-   size_t tmpaddr = 0;
-   size_t alignm = 0;
struct sk_buff *pskb = NULL;
 
skb_queue_head_init(>free_recv_skb_queue);
 
for (i = 0; i < NR_PREALLOC_RECV_SKB; i++) {
pskb = __netdev_alloc_skb(padapter->pnetdev,
-   MAX_RECVBUF_SZ + RECVBUFF_ALIGN_SZ,
-   GFP_KERNEL);
+   MAX_RECVBUF_SZ, GFP_KERNEL);
if (pskb) {
kmemleak_not_leak(pskb);
-   pskb->dev = padapter->pnetdev;
-   tmpaddr = (size_t)pskb->data;
-   alignm = tmpaddr & (RECVBUFF_ALIGN_SZ-1);
-   skb_reserve(pskb, (RECVBUFF_ALIGN_SZ - alignm));
-
skb_queue_tail(>free_recv_skb_queue,
pskb);
}
diff --git a/drivers/staging/rtl8188eu/include/rtw_recv.h 
b/drivers/staging/rtl8188eu/include/rtw_recv.h
index a8874a2..c868863 100644
--- a/drivers/staging/rtl8188eu/include/rtw_recv.h
+++ b/drivers/staging/rtl8188eu/include/rtw_recv.h
@@ -139,8 +139,6 @@ struct rx_pkt_attrib {
 #define SN_EQUAL(a, b) (a == b)
 #define REORDER_WAIT_TIME  (50) /*  (ms) */
 
-#define RECVBUFF_ALIGN_SZ 8
-
 #define RXDESC_SIZE24
 #define RXDESC_OFFSET RXDESC_SIZE
 
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c 
b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
index d0d5915..b820482 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
@@ -457,8 +457,6 @@ u32 usb_read_port(struct adapter *adapter, u32 addr, u32 
cnt, u8 *rmem)
struct usb_device   *pusbd = pdvobj->pusbdev;
int err;
unsigned int pipe;
-   size_t tmpaddr = 0;
-   size_t alignment = 0;
u32 ret = _SUCCESS;
 
 
@@ -483,16 +481,12 @@ u32 usb_read_port(struct adapter *adapter, u32 addr, u32 
cnt, u8 *rmem)
 
/* re-assign for linux based on skb */
if ((!precvbuf->reuse) || (precvbuf->pskb == NULL)) {
-   precvbuf->pskb = netdev_alloc_skb(adapter->pnetdev, 
MAX_RECVBUF_SZ + RECVBUFF_ALIGN_SZ);
+   precvbuf->pskb = netdev_alloc_skb(adapter->pnetdev, 
MAX_RECVBUF_SZ);
if (precvbuf->pskb == NULL) {
RT_TRACE(_module_hci_ops_os_c_, _drv_err_, 
("init_recvbuf(): alloc_skb fail!\n"));
DBG_88E(" usb_read_port() alloc_skb fail!#\n");
return _FAIL;
}
-
-   tmpaddr = (size_t)precvbuf->pskb->data;
-   alignment = tmpaddr & (RECVBUFF_ALIGN_SZ-1);
-   skb_reserve(precvbuf->pskb, (RECVBUFF_ALIGN_SZ - alignment));
} else { /* reuse skb */
precvbuf->reuse = false;
}
-- 
2.7.3

[RELEASE] LTTng modules 2.9.0-rc1 "Joannès" (Linux kernel tracer)

[Mathieu Desnoyers]

We are proud to announce release candidate 1 of LTTng-modules 2.9.0.
Please test it within the coming month, and let us know if anything
goes unexpectedly before we proceed to the final release.

The LTTng modules provide Linux kernel tracing capability to the LTTng
2.9 tracer toolset.

New and Noteworthy for 2.9.0-rc1:

* Various performance improvements. Tested on x86-64 and ARM32.
* Add bitfield, enumeration, variant, structure, compound
  array/sequence types.
* Add custom field support.
* IPv4, IPv6, and TCP header data is now traced with the net_.
  tracepoints.
* Implement select, pselect6, poll, ppoll, epoll_wait, epoll_pwait,
  epoll_ctl, detailed system call tracing.
* The accept4() system call payload detail is now traced on x86-64.
* New "i2c" instrumentation. We introduce the module parameter
  "extract_sensitive_payload" for this probe. It is disabled by
  default. When enabled, it allows tracing i2c payload information
  which may contain sensitive data (e.g. keystrokes).
* When lttng-modules gets built into the kernel image, select
  TRACEPOINTS rather than depending on it.

Project website: http://lttng.org
Documentation: http://lttng.org/docs
Download link: http://lttng.org/download

The 2.9 release "Joannès" is named after a Berliner Weisse style
beer from the Trèfle Noir microbrewery in Rouyn-Noranda.

Changelog:

2016-10-07 (National Frappé Day) LTTng modules 2.9.0-rc1
* Fix: i2c: support kernels < 3.15
* Fix: show warning for broken clock work-around
* Bump minor ABI version
* Fix: work-around upstream Linux timekeeping bug
* Add support for i2c tracepoints
* Cleanup: makefile version checks with single "ge"
* Performance: special-case NULL in lttng_strlen_user_inatomic
* Fix: lttng_inline_memcpy does not take a __user argument
* Performance: implement lttng_inline_memcpy
* Performance: cache the backend pages pointer in context
* Cleanup: libringbuffer: remove duplicate pointer chasing in slow paths
* Performance: Only dereference commit index once
* Performance: Mark channel and buffer event disabled check unlikely
* Performance: Relax atomicity constraints for crash handling
* Performance: mark ring buffer do_copy callers always inline
* Performance: mark lib_ring_buffer_write always inline
* Kconfig: select TRACEPOINTS when built-in
* Performance: disable event counting by default
* Fix: handle large number of pages or subbuffers per buffer
* Fix: unregister cpu hotplug notifier on buffer alloc error
* Fix: sa_family is of type unsigned short
* Fix: check for sizeof sa_family to save sa_family in accept and 
connect
* Fix: use printk_once() for wrapper warning messages
* Fix: btrfs instrumentation for 4.8 kernel
* Fix: update mm_vmscan instrumentation for kernel 4.8
* Fix: napi instrumentation for 4.8 kernels
* Fix: update block instrumentation to compile on 4.8 kernels
* Cleanup: reuse code in accept() and accept4() instrumentation
* Add x86-64 override for accept4 syscall
* Fix: timer wrapper: support kernels >= 4.8
* Performance: split check deliver fast/slow paths
* Fix: x86-64 accept instrumentation
* Fix: Add support for 4.6.4-rt8 kernel
* Fix: update scsi instrumentation for 4.7+ kernels
* Fix: Use fs_initcall instead of rootfs_initcall
* Fix: Add kernel configuration for lttng clock plugin
* Fix: the clock plugin must be initiated before first use of the clock
* Fix: tests/Kbuild for older kernels
* Cleanup: __dynamic_len_idx set but not used warning
* Cleanup: coding style and comments of net.h
* net: Add TCP header data to net_* tracepoints
* net: Add IPv4/IPv6 header data to net_* tracepoints
* Fix: endianness for the container type of enum
* enumeration autoincrement: use if/else logic
* Cleanup trailing whitespaces
* lttng-test probe: test ctf_enum_auto()
* Add ctf_enum_auto() for autoincrementing enumeration values
* Implement session statedump command
* Fix: annotate bytecode interpreter for kernel stack validator
* Update version to 2.9.0-pre
* Fix: ring buffer: honor switch parameter type in remote switch
* Fix: only flush non-metadata channels
* Fix: don't perform extra flush on metadata channel
* select, poll and epoll_wait overrides on ARM 32-bit
* Fix: flush empty packets on snapshot channel
* Fix: do not generate packet at destroy after stop
* Fix: compat ioctl for flush/get metadata version
* Fix: ctf_string() should handle NULL pointers
* Fix: portability: no arith on void pointer
* Fix: add missing tests/Kbuild
* Test clock override plugin
* Fix: add modules target to 

Re: [GIT PULL] trivial for 4.9

[Joe Perches]

On Fri, 2016-10-07 at 12:22 -0700, Linus Torvalds wrote:
> On Fri, Oct 7, 2016 at 1:51 AM, Jiri Kosina  wrote:
> > Colin Ian King (5):
> >   netfilter: Add missing \n to pr_err() message
> >   agp/intel: add missing \n to end of dev_emerg message
> >   lightnvm: add missing \n to end of dev_err message
> >   nvme: add missing \n to end of dev_warn message
> 
> 
> We really shouldn't be needing these final '\n' characters any more, afaik.
> 
> If the next printk isn't done by the same process, and doesn't have a
> KERN_CONT, the printk machinery should add the newline on its own.
> 
> I realize that people have been adding these '\n' characters for a
> while, but is there actually any point to it? They make the code less
> legible, imho. And we actually have a number of logging functions that
> explicitly don't want the newline (eg ext4_warning/error()), so it's
> actually more consistent to *not* have a newline than it is to have
> one.

Not remotely true.

It's _way_ more consistent to use a newline termination.
Macros without the newline are _far_ less common than those
with newlines.

Any printk without a KERN_ prefix, and there
are still many of those, can cause random interleaving.

> And if those '\n' characters actually make a difference, that should
> be noted. Because that would imply that the printk logic isn't working
> right.

Not at all.  Until printk KERN_ uses are mandated,
then these newlines are still useful.

fs: WARNING in locks_unlink_lock_ctx (not holding proper lock)

[Dmitry Vyukov]

Hello,

I am hitting lots of the following warnings while running syzkaller
fuzzer. Seems that path does not hold proper lock.

WARNING: CPU: 1 PID: 12090 at fs/locks.c:610 locks_unlink_lock_ctx+0x2c7/0x370
CPU: 1 PID: 12090 Comm: syz-executor Not tainted 4.8.0+ #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 880038ba7728 82d2b849 0016 fbfff10971e8
 86e8c000 880038ba7800 86f42400 dc00
 0009 880038ba77f0 816a229a 41b58ab3
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x12e/0x185 lib/dump_stack.c:51
 [] panic+0x1e9/0x3f4 kernel/panic.c:153
 [] __warn+0x1c9/0x1e0 kernel/panic.c:509
 [] warn_slowpath_null+0x31/0x40 kernel/panic.c:552
 [< inline >] locks_delete_global_locks fs/locks.c:610
 [] locks_unlink_lock_ctx+0x2c7/0x370 fs/locks.c:739
 [] locks_delete_lock_ctx+0x1f/0x80 fs/locks.c:751
 [] lease_modify+0x229/0x2e0 fs/locks.c:1370
 [< inline >] locks_remove_lease fs/locks.c:2528
 [] locks_remove_file+0x2d8/0x380 fs/locks.c:2551
 [] __fput+0x1a6/0x780 fs/file_table.c:200
 [] fput+0x1a/0x20 fs/file_table.c:244
 [] task_work_run+0xf8/0x170 kernel/task_work.c:116
 [< inline >] exit_task_work include/linux/task_work.h:21
 [] do_exit+0x864/0x2ad0 kernel/exit.c:828
 [] do_group_exit+0x10d/0x330 kernel/exit.c:931
 [] get_signal+0x62f/0x15e0 kernel/signal.c:2307
 [] do_signal+0x84/0x18f0 arch/x86/kernel/signal.c:807
 [] exit_to_usermode_loop+0x13b/0x200
arch/x86/entry/common.c:156
 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
 [< inline >] syscall_return_slowpath arch/x86/entry/common.c:259
 [] do_syscall_64+0x49f/0x620 arch/x86/entry/common.c:285

On commit a6930aaee06755d1bdcfd943fbf614e4d92bb0c7 (Oct 5).

[GIT PULL] Please pull JSON perf event lists

[Sukadev Bhattiprolu]

Hi Arnaldo,

Please pull the JSON perf event lists for Powerpc and Intel CPUs.

The following changes since commit 1859e245e6ba91c0c46078622c5f0d6871b940f0:

  perf tools: Handle completion of upper case events (2016-10-06 17:00:04 -0300)

are available in the git repository at:
  g...@github.com:sukadev/linux json-data-files-v22

Andi Kleen (19):
  perf jevents: Add BroadwellDE V5 event file
  perf jevents: Add Broadwell V17 event file
  perf jevents: Add BroadwellX V10 event file
  perf jevents: Add Bonnell V4 event file
  perf jevents: Add Goldmont V8 event file
  perf jevents: Add Haswell V24 event file
  perf jevents: Add HaswellX V17 event file
  perf jevents: Add IvyBridge V18 event file
  perf jevents: Add IvyTown V19 event file
  perf jevents: Add Jaketown V20 event file
  perf jevents: Add KnightsLanding V9 event file
  perf jevents: Add NehalemEP V2 event file
  perf jevents: Add NehalemEX V2 event file
  perf jevents: Add Skylake V24 event file
  perf jevents: Add Silvermont V13 event file
  perf jevents: Add SandyBridge V15 event file
  perf jevents: Add WestmereEP-DP V2 event file
  perf jevents: Add WestmereEP-SP V2 event file
  perf jevents: Add WestmereEX V2 event file

Madhavan Srinivasan (1):
  perf jevents: support couple more POWER8 PVRs in mapfile

Sukadev Bhattiprolu (1):
  perf jevents: Add power8 PMU events

 tools/perf/pmu-events/arch/powerpc/mapfile.csv |   21 +
 .../perf/pmu-events/arch/powerpc/power8/Cache.json |  176 +
 .../arch/powerpc/power8/Floating-point.json|   14 +
 .../pmu-events/arch/powerpc/power8/Frontend.json   |  470 +++
 .../pmu-events/arch/powerpc/power8/Marked.json |  794 
 .../pmu-events/arch/powerpc/power8/Memory.json |  212 +
 .../perf/pmu-events/arch/powerpc/power8/Other.json | 4064 ++
 tools/perf/pmu-events/arch/powerpc/power8/PMC.json |  140 +
 .../pmu-events/arch/powerpc/power8/Pipeline.json   |  350 ++
 .../arch/powerpc/power8/Translation.json   |  176 +
 tools/perf/pmu-events/arch/x86/Bonnell/Cache.json  |  746 
 .../arch/x86/Bonnell/Floating-point.json   |  261 ++
 .../perf/pmu-events/arch/x86/Bonnell/Frontend.json |   83 +
 tools/perf/pmu-events/arch/x86/Bonnell/Memory.json |  154 +
 tools/perf/pmu-events/arch/x86/Bonnell/Other.json  |  450 ++
 .../perf/pmu-events/arch/x86/Bonnell/Pipeline.json |  364 ++
 .../arch/x86/Bonnell/Virtual-Memory.json   |  124 +
 .../perf/pmu-events/arch/x86/Broadwell/Cache.json  | 3198 +++
 .../arch/x86/Broadwell/Floating-point.json |  171 +
 .../pmu-events/arch/x86/Broadwell/Frontend.json|  286 ++
 .../perf/pmu-events/arch/x86/Broadwell/Memory.json | 2845 +
 .../perf/pmu-events/arch/x86/Broadwell/Other.json  |   44 +
 .../pmu-events/arch/x86/Broadwell/Pipeline.json| 1417 +++
 .../arch/x86/Broadwell/Virtual-Memory.json |  388 ++
 .../pmu-events/arch/x86/BroadwellDE/Cache.json |  774 
 .../arch/x86/BroadwellDE/Floating-point.json   |  171 +
 .../pmu-events/arch/x86/BroadwellDE/Frontend.json  |  286 ++
 .../pmu-events/arch/x86/BroadwellDE/Memory.json|  433 ++
 .../pmu-events/arch/x86/BroadwellDE/Other.json |   44 +
 .../pmu-events/arch/x86/BroadwellDE/Pipeline.json  | 1417 +++
 .../arch/x86/BroadwellDE/Virtual-Memory.json   |  388 ++
 .../perf/pmu-events/arch/x86/BroadwellX/Cache.json |  942 +
 .../arch/x86/BroadwellX/Floating-point.json|  171 +
 .../pmu-events/arch/x86/BroadwellX/Frontend.json   |  286 ++
 .../pmu-events/arch/x86/BroadwellX/Memory.json |  649 +++
 .../perf/pmu-events/arch/x86/BroadwellX/Other.json |   44 +
 .../pmu-events/arch/x86/BroadwellX/Pipeline.json   | 1417 +++
 .../arch/x86/BroadwellX/Virtual-Memory.json|  388 ++
 tools/perf/pmu-events/arch/x86/Goldmont/Cache.json | 1127 +
 .../pmu-events/arch/x86/Goldmont/Frontend.json |   52 +
 .../perf/pmu-events/arch/x86/Goldmont/Memory.json  |   34 +
 tools/perf/pmu-events/arch/x86/Goldmont/Other.json |   52 +
 .../pmu-events/arch/x86/Goldmont/Pipeline.json |  433 ++
 .../arch/x86/Goldmont/Virtual-Memory.json  |   75 +
 tools/perf/pmu-events/arch/x86/Haswell/Cache.json  | 1041 +
 .../arch/x86/Haswell/Floating-point.json   |   83 +
 .../perf/pmu-events/arch/x86/Haswell/Frontend.json |  294 ++
 tools/perf/pmu-events/arch/x86/Haswell/Memory.json |  655 +++
 tools/perf/pmu-events/arch/x86/Haswell/Other.json  |   43 +
 .../perf/pmu-events/arch/x86/Haswell/Pipeline.json | 1329 ++
 .../arch/x86/Haswell/Virtual-Memory.json   |  484 +++
 tools/perf/pmu-events/arch/x86/HaswellX/Cache.json | 1077 +
 .../arch/x86/HaswellX/Floating-point.json  |   83 +
 .../pmu-events/arch/x86/HaswellX/Frontend.json |  294 ++
 .../perf/pmu-events/arch/x86/HaswellX/Memory.json  |  739 
 tools/perf/pmu-events/arch/x86/HaswellX/Other.json |   43 +
 

Re: [PATCH 2/2] power: surface3_power: MSHW0011 rev-eng implementation

[Andy Shevchenko]

On Fri, Jul 29, 2016 at 6:49 PM, Benjamin Tissoires
 wrote:
> MSHW0011 replaces the battery firmware by using ACPI operation regions.
> The values have been obtained by reverse engineering, and are subject to
> errors. Looks like it works on overall pretty well.
>
> I couldn't manage to get the IRQ correctly triggered, so I am using a
> good old polling thread to check for changes.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=106231


> +/*
> + * This driver has been reverse-engineered by parsing the DSDT of the 
> Surface 3
> + * and looking at the registers of the chips.
> + *
> + * The DSDT allowed to find out that:
> + * - the driver is required for the ACPI BAT0 device to communicate to the 
> chip
> + *   through an operation region.
> + * - the various defines for the operation region functions to communicate 
> with
> + *   this driver
> + * - the DSM 3f99e367-6220-4955-8b0f-06ef2ae79412 allows to trigger ACPI
> + *   events to BAT0 (the code is all available in the DSDT).
> + *
> + * Further findings regarding the 2 chips declared in the MSHW0011 are:
> + * - there are 2 chips declared:
> + *   . 0x22 seems to control the ADP1 line status (and probably the charger)
> + *   . 0x55 controls the battery directly
> + * - the battery chip uses a SMBus protocol (using plain SMBus allows non
> + *   destructive commands):
> + *   . the commands/registers used are in the range 0x00..0x7F
> + *   . if bit 8 (0x80) is set in the SMBus command, the returned value is the
> + * same as when it is not set. There is a high chance this bit is the
> + * read/write
> + *   . the various registers semantic as been deduced by observing the 
> register
> + * dumps.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Alphabetical order?

> +
> +#include 
> +
> +#define POLL_INTERVAL  (HZ * 2)

(2 * HZ)

> +static int
> +mshw0011_notify(struct mshw0011_data *cdata, u8 arg1, u8 arg2,
> +   unsigned int *ret_value)
> +{
> +   static const u8 mshw0011_guid[] = {
> +   0x67, 0xE3, 0x99, 0x3F, 0x20, 0x62, 0x55, 0x49,
> +   0x8b, 0x0f, 0x06, 0xef, 0x2a, 0xe7, 0x94, 0x12,
> +   };

What about uuid_le?

> +   union acpi_object *obj;
> +   struct acpi_device *adev;
> +   acpi_handle handle;
> +   unsigned int i;
> +
> +   handle = ACPI_HANDLE(>adp1->dev);
> +   if (!handle || acpi_bus_get_device(handle, ))
> +   return -ENODEV;
> +
> +   obj = acpi_evaluate_dsm_typed(handle, mshw0011_guid, arg1, arg2, NULL,
> + ACPI_TYPE_BUFFER);
> +   if (!obj) {
> +   dev_err(>adp1->dev, "device _DSM execution failed\n");
> +   return -ENODEV;
> +   }
> +
> +   *ret_value = 0;
> +   for (i = 0; i < obj->buffer.length; i++)
> +   *ret_value |= obj->buffer.pointer[i] << (i * 8);
> +
> +   ACPI_FREE(obj);
> +   return 0;
> +}
> +

> +static const struct bix default_bix = {
> +   .revision = 0x00,
> +   .power_unit = 0x01,
> +   .design_capacity = 0x1dca,
> +   .last_full_charg_capacity = 0x1dca,
> +   .battery_technology = 0x01,
> +   .design_voltage = 0x10df,
> +   .design_capacity_of_warning = 0x8f,
> +   .design_capacity_of_low = 0x47,
> +   .cycle_count = 0x,

> +   .measurement_accuracy = 0x00015F90,
> +   .max_sampling_time = 0x03E8,
> +   .min_sampling_time = 0x03E8,
> +   .max_average_interval = 0x03E8,
> +   .min_average_interval = 0x03E8,

Capital vs. small letters for hex?

> +   .battery_capacity_granularity_1 = 0x45,
> +   .battery_capacity_granularity_2 = 0x11,
> +   .model = "P11G8M",
> +   .serial = "",
> +   .type = "LION",
> +   .OEM = "",
> +};

> +static int mshw0011_bix(struct mshw0011_data *cdata, struct bix *bix)
> +{
> +   struct i2c_client *client = cdata->bat0;

> +   int ret;
> +   char buf[10];

Exchange order?

> +static int mshw0011_poll_task(void *data)
> +{
> +   struct mshw0011_data *cdata = data;
> +   int ret = 0;
> +
> +   cdata->kthread_running = true;
> +
> +   set_freezable();
> +
> +   while (!kthread_should_stop()) {
> +   schedule_timeout_interruptible(POLL_INTERVAL);
> +   try_to_freeze();
> +   ret = mshw0011_isr(data);
> +   if (ret)
> +   goto out;

break; ?

> +   }
> +
> +out:
> +   cdata->kthread_running = false;
> +   return ret;
> +}
> +

> +static acpi_status
> +mshw0011_space_handler(u32 function, acpi_physical_address command,
> +   u32 bits, u64 *value64,
> +   void *handler_context, void *region_context)
> +{
> +   int status = 1;


> +   switch (gsb->cmd.arg1) {
> +   case MSHW0011_CMD_BAT0_STA:

> +   status = 1;

Already 1?

> +   ret = 0;
> +  

Re: [RFC 1/2] staging: jnx: Add Juniper connector driver

[Pantelis Antoniou]

Hi Joe,

> On Oct 7, 2016, at 19:25 , Joe Perches  wrote:
> 
> On Fri, 2016-10-07 at 18:16 +0300, Pantelis Antoniou wrote:
>> diff --git a/drivers/staging/jnx/jnx-connector.c 
>> b/drivers/staging/jnx/jnx-connector.c
> []
>> +struct jnx_conn_data {
>> +struct device *dev; /* parent (platform) device */
>> +const char *name[NUM_OVERLAYS]; /* overlay file names */
>> +bool enabled;   /* true if can handle interrupts */
>> +bool poweron;   /* true if assumed to be powered on */
> 
> maybe use pahole and remove some of the wasteful padding
> 

Yes, good idea; this structure sorta grew organically.

>> +int attention_button;   /* attention button gpio pin */
>> +bool have_attention_button; /* true if attention button exists */
>> +unsigned long attention_button_holdtime;/* button hold time, jiffies */
>> +bool attention_ignore;  /* true if handled by user space */
>> +int power_enable;   /* power enable gpio pin */
>> +bool auto_enable;   /* true if board should auto-enable */
>> +struct jnx_i2c_power_seq pon;   /* power-on sequence */
> []
>> +u32 gpio_flags;
>> +u16 assembly_id;
>> +int slot;   /* slot number */
>> +int type;   /* card type */
>> +bool static_assembly_id;/* true if assembly_id is static */
>> +bool assembly_id_valid; /* true if assembly_id is valid */
>> +int adapter;/* parent i2c adapter number */
> []
>> +struct mutex mutex; /* mutex to protect state changes */
>> +bool synchronous;   /* true if state changes are ok */
>> +struct mutex fdt_mutex; /* mutex to protect fdt accesses */
> []
>> +bool standby_to_master; /* standby:master_ev processing */
>> +};
> []
>> +/*
>> + * jnx_conn_insert_ideeprom()
>> + *   Inserts ideeprom with a parent from OF prop
>> + */
>> +static int jnx_conn_insert_ideeprom(struct jnx_conn_data *data,
>> +struct i2c_adapter *adap,
>> +struct device_node *node,
>> +struct i2c_board_info *info)
>> +{
>> +struct device *dev = data->dev;
>> +struct i2c_adapter *parent = NULL;
>> +struct i2c_client *client;
>> +struct device_node *anode;
>> +struct at24_platform_data at24_pdata = {
>> +.byte_len = 256,
>> +.page_size = 4,
>> +.setup = jnx_conn_at24_callback,
>> +.context = data,
>> +};
>> +
>> +info->platform_data = _pdata;
> 
> Assigning a temporary address through a pointer argument?
> Isn't there a better way?
> 

Yeah, it is weird; it works but its risky.

I’ll change it.

>> +/*
>> + * jnx_conn_verify_overlay()
>> + *
>> + * Verify if overlay is compatible with this board/slot
>> + */
>> +static int jnx_conn_verify_overlay(struct jnx_conn_data *data,
>> +   struct device_node *np)
>> +{
> []
>> +ret = of_property_read_u32(np, "type", );
>> +if (ret) {
>> +dev_err(dev, "Missing type property\n");
>> +return ret;
>> +}
>> +if (var != data->type) {
>> +dev_err(dev, "Wrong type: Expected %d, got %d\n",
>> +data->type, var);
>> +return -EINVAL;
>> +}
>> +
>> +/*
>> + * 'assembly-ids' property must exist, and one of its entries must match
>> + * the card assembly id
>> + */
>> +assembly_ids = of_get_property(np, "assembly-ids", );
>> +if (!assembly_ids || size < sizeof(u32)) {
>> +dev_err(dev, "Bad assembly-ids property\n");
>> +return -EINVAL;
>> +}
>> +ret = -EINVAL;
>> +for (i = 0; i < size / sizeof(u32); i++) {
>> +if (be32_to_cpu(assembly_ids[i]) == data->assembly_id) {
>> +ret = 0;
>> +break;
>> +}
>> +}
>> +if (ret) {
>> +dev_err(dev, "Assembly ID 0x%x not supported by overlay\n",
>> +data->assembly_id);
>> +return ret;
>> +}
> 
> Given all the direct returns above here, perhaps
> 
>   for (i = 0; i < size / sizeof(u32); i++) {
>   if (be32_to_cpu(assembly_ids[i]) == data->assembly_id)
>   return 0;
>   }
> 

It does look better.

>   dev_err(...);
>   return -EINVAL;
> 
> 


Regards

— Pantelis

Re: [GIT PULL] trivial for 4.9

[Linus Torvalds]

On Fri, Oct 7, 2016 at 1:04 PM, Joe Perches  wrote:
>
> Any printk without a KERN_ prefix, and there
> are still many of those, can cause random interleaving.

How about people actually work on *that* instead of working around it?

Because the above really should not be true.

> Not at all.  Until printk KERN_ uses are mandated,
> then these newlines are still useful.

The patches literally added those '\n' things to the pr_xyz() routines
that *enforce* KERN_.

So really. It's a step backwards. We shouldn't need them. We should
*remove* '\n' at the end, and then if that actually causes problems,
we should fix those problems.

 Linus

[PATCH v3 4/6] arm: dts: imx7: Update #pwm-cells for PWM polarity control

[Bhuvanchandra DV]

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

Signed-off-by: Bhuvanchandra DV 
Acked-by: Rob Herring 
---
 arch/arm/boot/dts/imx7s.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 0d7d5ac..8d1d471 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -601,7 +601,7 @@
clocks = < IMX7D_PWM1_ROOT_CLK>,
 < IMX7D_PWM1_ROOT_CLK>;
clock-names = "ipg", "per";
-   #pwm-cells = <2>;
+   #pwm-cells = <3>;
status = "disabled";
};
 
@@ -612,7 +612,7 @@
clocks = < IMX7D_PWM2_ROOT_CLK>,
 < IMX7D_PWM2_ROOT_CLK>;
clock-names = "ipg", "per";
-   #pwm-cells = <2>;
+   #pwm-cells = <3>;
status = "disabled";
};
 
@@ -623,7 +623,7 @@
clocks = < IMX7D_PWM3_ROOT_CLK>,
 < IMX7D_PWM3_ROOT_CLK>;
clock-names = "ipg", "per";
-   #pwm-cells = <2>;
+   #pwm-cells = <3>;
status = "disabled";
};
 
@@ -634,7 +634,7 @@
clocks = < IMX7D_PWM4_ROOT_CLK>,
 < IMX7D_PWM4_ROOT_CLK>;
clock-names = "ipg", "per";
-   #pwm-cells = <2>;
+   #pwm-cells = <3>;
status = "disabled";
};
 
-- 
2.10.0

Re: [GIT PULL] trivial for 4.9

[Joe Perches]

On Fri, 2016-10-07 at 13:13 -0700, Linus Torvalds wrote:
> On Fri, Oct 7, 2016 at 1:04 PM, Joe Perches  wrote:
> > Any printk without a KERN_ prefix, and there
> > are still many of those, can cause random interleaving.
> How about people actually work on *that* instead of working around it?
> Because the above really should not be true.
> > Not at all.  Until printk KERN_ uses are mandated,
> > then these newlines are still useful.
> The patches literally added those '\n' things to the pr_xyz() routines
> that *enforce* KERN_.

No, because any of those can be followed by a bare printk
or a pr_cont that continues the original line.

> So really. It's a step backwards. We shouldn't need them. We should
> *remove* '\n' at the end, and then if that actually causes problems,
> we should fix those problems.

$ git grep -w printk * | grep -v "^tools" | grep -v KERN | wc -l
13176

Have at it but here are _far_ fewer missing newlines
and it'd be much lower churn to fix those than remove
all the newlines and fix the missing continuations.

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[Michael Niewöhner]

Hi Felipe,

On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote:
> Hi,
> 
> Michael Niewöhner  writes:
> > 
> > > 
> > > The clocks are same across working/non-working.
> > > Is it possible to bisect the commit that's causing hang for 4.8x ?
> > 
> > 
> > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init 
> > and exit paths
> > This patch causes both the hang on reboot and the lsusb hang.
> 
> How to reproduce? Why don't we see this on x86 and TI boards? I'm
> guessing this is failed bisection, as I can't see anything in that
> commit that would cause reboot hang. Also, that code path is *NOT*
> executed when you run lsusb.
> 

I've tested this procedure multiple times to be sure:

- checkout c499ff71, compile, boot the odroid
- run lsusb -v => lsusb hangs, can't terminate with ctrl-c
- hard reset, after boot run poweroff or reboot => board does not completely 
power off / reboot (see log below)
- revert c499ff71, mrproper, compile, boot the odroid
- run lsusb -v => shows full output, not hanging
- run reboot or poweroff => board powers off / reboots just fine


dmesg poweroff not working:
...
[  120.733519] systemd-journald[144]: systemd-journald stopped as pid 144   
[  120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...   
[  120.769212] systemd-shutdown[1]: Unmounting file systems.
[  120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.   
[  120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. 
[  121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.101014] systemd-shutdown[1]: All filesystems unmounted.  
[  121.106523] systemd-shutdown[1]: Deactivating swaps. 
[  121.111585] systemd-shutdown[1]: All swaps deactivated.  
[  121.116661] systemd-shutdown[1]: Detaching loop devices. 
[  121.126395] systemd-shutdown[1]: All loop devices detached.  
[  121.130525] systemd-shutdown[1]: Detaching DM devices.   
[  121.135824] systemd-shutdown[1]: All DM devices detached.
[  121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. 
[  121.171739] systemd-shutdown[1]: Powering off.

=> at this point removing the sd card would show a message 
"removed mmc0" (not sure what the real message was...) so the board is not 
completely off.


dmesg poweroff working:
...
[  120.733519] systemd-journald[144]: systemd-journald stopped as pid 144   
[  120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...   
[  120.769212] systemd-shutdown[1]: Unmounting file systems.
[  120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.   
[  120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. 
[  121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.101014] systemd-shutdown[1]: All filesystems unmounted.  
[  121.106523] systemd-shutdown[1]: Deactivating swaps. 
[  121.111585] systemd-shutdown[1]: All swaps deactivated.  
[  121.116661] systemd-shutdown[1]: Detaching loop devices. 
[  121.126395] systemd-shutdown[1]: All loop devices detached.  
[  121.130525] systemd-shutdown[1]: Detaching DM devices.   
[  121.135824] systemd-shutdown[1]: All DM devices detached.
[  121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. 
[  121.171739] systemd-shutdown[1]: Powering off.
[  121.182331] rebo�



Best regards
Michael

[PATCH v3 1/3] dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq

[Markus Mayer]

Add the binding document for the new brcmstb-avs-cpufreq driver.

Signed-off-by: Markus Mayer 
Acked-by: Viresh Kumar 
---
 .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt | 76 ++
 MAINTAINERS|  7 ++
 2 files changed, 83 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt

diff --git 
a/Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt 
b/Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
new file mode 100644
index 000..23a2c3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
@@ -0,0 +1,76 @@
+Broadcom STB AVS CPUfreq driver bindings
+
+
+A total of three DT nodes are required. One node (brcm,avs-cpu-data-mem)
+references the mailbox register used to communicate with the AVS CPU[1]. The
+second node (brcm,avs-cpu-l2-intr) is required to trigger an interrupt on
+the AVS CPU. The interrupt tells the AVS CPU that it needs to process a
+command sent to it by a driver. Interrupting the AVS CPU is mandatory for
+commands to be processed.
+
+The interface also requires a reference to the AVS host interrupt controller,
+so a driver can react to interrupts generated by the AVS CPU whenever a command
+has been processed. See [2] for more information on the brcm,l2-intc node.
+
+[1] The AVS CPU is an independent co-processor that runs proprietary
+firmware. On some SoCs, this firmware supports DFS and DVFS in addition to
+Adaptive Voltage Scaling.
+
+[2] Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
+
+
+Node brcm,avs-cpu-data-mem
+--
+
+Required properties:
+- compatible: Sould be one of: brcm,avs-cpu-data-mem,
+  brcm,bcm7271-avs-cpu-data-mem or brcm,bcm7268-avs-cpu-data-mem
+- reg: Specifies base physical address and size of the registers.
+- interrupts: The interrupt that the AVS CPU will use to interrupt the host
+  when a command completed.
+- interrupt-parent: The interrupt controller the above interrupt is routed
+through.
+- interrupt-names: The name of the interrupt used to interrupt the host.
+
+Optional properties:
+- None
+
+Node brcm,avs-cpu-l2-intr
+-
+
+Required properties:
+- compatible: Sould be one of: brcm,avs-cpu-l2-intr,
+  brcm,bcm7271-avs-cpu-l2-intr or brcm,bcm7268-avs-cpu-l2-intr
+- reg: Specifies base physical address and size of the registers.
+
+Optional properties:
+- None
+
+
+Example
+===
+
+   avs_host_l2_intc: interrupt-controller@f04d1200 {
+   #interrupt-cells = <1>;
+   compatible = "brcm,l2-intc";
+   interrupt-parent = <>;
+   reg = <0xf04d1200 0x48>;
+   interrupt-controller;
+   interrupts = <0x0 0x19 0x0>;
+   interrupt-names = "avs";
+   };
+
+   avs-cpu-data-mem@f04c4000 {
+   compatible = "brcm,bcm7271-avs-cpu-data-mem",
+   "brcm,avs-cpu-data-mem";
+   reg = <0xf04c4000 0x60>;
+   interrupts = <0x1a>;
+   interrupt-parent = <_host_l2_intc>;
+   interrupt-names = "sw_intr";
+   };
+
+   avs-cpu-l2-intr@f04d1100 {
+   compatible = "brcm,bcm7271-avs-cpu-l2-intr",
+   "brcm,avs-cpu-l2-intr";
+   reg = <0xf04d1100 0x10>;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index f593300..75accd5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2701,6 +2701,13 @@ L:   bcm-kernel-feedback-l...@broadcom.com
 S: Maintained
 F: drivers/mtd/nand/brcmnand/
 
+BROADCOM STB AVS CPUFREQ DRIVER
+M: Markus Mayer 
+M: bcm-kernel-feedback-l...@broadcom.com
+L: linux...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
+
 BROADCOM SPECIFIC AMBA DRIVER (BCMA)
 M: Rafał Miłecki 
 L: linux-wirel...@vger.kernel.org
-- 
2.7.4

[PATCH v3 3/3] cpufreq: brcmstb-avs-cpufreq: add debugfs support

[Markus Mayer]

In order to aid debugging, we add a debugfs interface to the driver
that allows direct interaction with the AVS co-processor.

The debugfs interface provides a means for reading all and writing some
of the mailbox registers directly from the shell prompt and enables a
user to execute the communications protocol between ARM CPU and AVS CPU
step-by-step.

This interface should be used for debugging purposes only.

Signed-off-by: Markus Mayer 
Acked-by: Viresh Kumar 
---
 drivers/cpufreq/Kconfig.arm   |  10 ++
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 322 +-
 2 files changed, 331 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index d4e3795..43f261e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -23,6 +23,16 @@ config ARM_BRCMSTB_AVS_CPUFREQ
 
  Say Y, if you have a Broadcom SoC with AVS support for DFS or DVFS.
 
+config ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
+   bool "Broadcom STB AVS CPUfreq driver sysfs debug capability"
+   depends on ARM_BRCMSTB_AVS_CPUFREQ
+   help
+ Enabling this option turns on debug support via sysfs under
+ /sys/kernel/debug/brcmstb-avs-cpufreq. It is possible to read all and
+ write some AVS mailbox registers through sysfs entries.
+
+ If in doubt, say N.
+
 config ARM_DT_BL_CPUFREQ
tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
depends on ARM_BIG_LITTLE_CPUFREQ && OF
diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index d012d93..e27b7f2 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -49,6 +49,13 @@
 #include 
 #include 
 
+#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
+#include 
+#include 
+#include 
+#include 
+#endif
+
 /* Max number of arguments AVS calls take */
 #define AVS_MAX_CMD_ARGS   4
 /*
@@ -175,11 +182,88 @@ struct private_data {
void __iomem *base;
void __iomem *avs_intr_base;
struct device *dev;
+#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
+   struct dentry *debugfs;
+#endif
struct completion done;
struct semaphore sem;
struct pmap pmap;
 };
 
+#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
+
+enum debugfs_format {
+   DEBUGFS_NORMAL,
+   DEBUGFS_FLOAT,
+   DEBUGFS_REV,
+};
+
+struct debugfs_data {
+   struct debugfs_entry *entry;
+   struct private_data *priv;
+};
+
+struct debugfs_entry {
+   char *name;
+   u32 offset;
+   fmode_t mode;
+   enum debugfs_format format;
+};
+
+#define DEBUGFS_ENTRY(name, mode, format)  { \
+   #name, AVS_MBOX_##name, mode, format \
+}
+
+/*
+ * These are used for debugfs only. Otherwise we use AVS_MBOX_PARAM() directly.
+ */
+#define AVS_MBOX_PARAM1AVS_MBOX_PARAM(0)
+#define AVS_MBOX_PARAM2AVS_MBOX_PARAM(1)
+#define AVS_MBOX_PARAM3AVS_MBOX_PARAM(2)
+#define AVS_MBOX_PARAM4AVS_MBOX_PARAM(3)
+
+/*
+ * This table stores the name, access permissions and offset for each hardware
+ * register and is used to generate debugfs entries.
+ */
+static struct debugfs_entry debugfs_entries[] = {
+   DEBUGFS_ENTRY(COMMAND, S_IWUSR, DEBUGFS_NORMAL),
+   DEBUGFS_ENTRY(STATUS, S_IWUSR, DEBUGFS_NORMAL),
+   DEBUGFS_ENTRY(VOLTAGE0, 0, DEBUGFS_FLOAT),
+   DEBUGFS_ENTRY(TEMP0, 0, DEBUGFS_FLOAT),
+   DEBUGFS_ENTRY(PV0, 0, DEBUGFS_FLOAT),
+   DEBUGFS_ENTRY(MV0, 0, DEBUGFS_FLOAT),
+   DEBUGFS_ENTRY(PARAM1, S_IWUSR, DEBUGFS_NORMAL),
+   DEBUGFS_ENTRY(PARAM2, S_IWUSR, DEBUGFS_NORMAL),
+   DEBUGFS_ENTRY(PARAM3, S_IWUSR, DEBUGFS_NORMAL),
+   DEBUGFS_ENTRY(PARAM4, S_IWUSR, DEBUGFS_NORMAL),
+   DEBUGFS_ENTRY(REVISION, 0, DEBUGFS_REV),
+   DEBUGFS_ENTRY(PSTATE, 0, DEBUGFS_NORMAL),
+   DEBUGFS_ENTRY(HEARTBEAT, 0, DEBUGFS_NORMAL),
+   DEBUGFS_ENTRY(MAGIC, S_IWUSR, DEBUGFS_NORMAL),
+   DEBUGFS_ENTRY(SIGMA_HVT, 0, DEBUGFS_NORMAL),
+   DEBUGFS_ENTRY(SIGMA_SVT, 0, DEBUGFS_NORMAL),
+   DEBUGFS_ENTRY(VOLTAGE1, 0, DEBUGFS_FLOAT),
+   DEBUGFS_ENTRY(TEMP1, 0, DEBUGFS_FLOAT),
+   DEBUGFS_ENTRY(PV1, 0, DEBUGFS_FLOAT),
+   DEBUGFS_ENTRY(MV1, 0, DEBUGFS_FLOAT),
+   DEBUGFS_ENTRY(FREQUENCY, 0, DEBUGFS_NORMAL),
+};
+
+static int brcm_avs_target_index(struct cpufreq_policy *, unsigned int);
+
+static char *__strtolower(char *s)
+{
+   char *p;
+
+   for (p = s; *p; p++)
+   *p = tolower(*p);
+
+   return s;
+}
+
+#endif /* CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG */
+
 static void __iomem *__map_region(const char *name)
 {
struct device_node *np;
@@ -432,6 +516,238 @@ brcm_avs_get_freq_table(struct device *dev, struct 
private_data *priv)
return table;
 }
 
+#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
+
+#define MANT(x)(unsigned int)(abs((x)) / 1000)
+#define 

[PATCH] drivers: staging: greybus: Fixed CHECKS for brace issues

[Chase Metzger]

Added braces to else statements where checkpatch complained.

Signed-off-by: Chase Metzger 
---
 drivers/staging/greybus/audio_codec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/greybus/audio_codec.c 
b/drivers/staging/greybus/audio_codec.c
index 8a0744b..1bdf849 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -655,8 +655,10 @@ static int gbcodec_mute_stream(struct snd_soc_dai *dai, 
int mute, int stream)
ret = gb_audio_apbridgea_shutdown_rx(data->connection,
 0);
params->state = GBAUDIO_CODEC_STOP;
-   } else
+   } else {
ret = -EINVAL;
+   }
+
if (ret)
dev_err_ratelimited(dai->dev,
"%s:Error during %s %s stream:%d\n",
-- 
2.1.4

[PATCH v2 00/10] Start of skl watermark cleanup

[Lyude]

While it (mostly) works, the code for handling watermarks on Skylake has been
kind of ugly for a while. As well a lot of it isn't that friendly to atomic
transactions, Lots of copy paste, redundant wm values, etc. While this isn't a
full cleanup, it's a good start. As well, we add a couple of features for
making debugging watermarks a little easier.

Lyude (10):
  drm/i915/skl: Move per-pipe ddb allocations into crtc states
  drm/i915/skl: Remove linetime from skl_wm_values
  drm/i915/gen9: Make skl_wm_level per-plane
  drm/i915/gen9: Cleanup skl_pipe_wm_active_state
  drm/i915/gen9: Get rid of redundant watermark values
  drm/i915/gen9: Add ddb changes to atomic debug output
  drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable
  drm/i915/gen9: Add skl_wm_level_equals()
  drm/i915/gen9: Actually verify WM levels in verify_wm_state()
  drm/i915/gen9: Don't wrap strings in verify_wm_state()

 drivers/gpu/drm/i915/i915_drv.h  |  10 +-
 drivers/gpu/drm/i915/intel_display.c | 138 +++---
 drivers/gpu/drm/i915/intel_drv.h |  24 +-
 drivers/gpu/drm/i915/intel_pm.c  | 470 +--
 drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
 5 files changed, 357 insertions(+), 293 deletions(-)

-- 
2.7.4

[PATCH 04/10] drm/i915/gen9: Cleanup skl_pipe_wm_active_state

[Lyude]

This function is a wreck, let's help it get it's life back together and
cleanup all of the copy pasta here.

(adding Maarten's reviewed-by since this is just a split-up version of one
of the previous patches)

Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 52 +++--
 1 file changed, 14 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4c2ebcd..5dbaf12 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4267,46 +4267,22 @@ static void ilk_optimize_watermarks(struct 
intel_crtc_state *cstate)
 static void skl_pipe_wm_active_state(uint32_t val,
 struct skl_pipe_wm *active,
 bool is_transwm,
-bool is_cursor,
 int i,
 int level)
 {
+   struct skl_plane_wm *plane_wm = >planes[i];
bool is_enabled = (val & PLANE_WM_EN) != 0;
 
if (!is_transwm) {
-   if (!is_cursor) {
-   active->planes[i].wm[level].plane_en = is_enabled;
-   active->planes[i].wm[level].plane_res_b =
-   val & PLANE_WM_BLOCKS_MASK;
-   active->planes[i].wm[level].plane_res_l =
-   (val >> PLANE_WM_LINES_SHIFT) &
-   PLANE_WM_LINES_MASK;
-   } else {
-   active->planes[PLANE_CURSOR].wm[level].plane_en =
-   is_enabled;
-   active->planes[PLANE_CURSOR].wm[level].plane_res_b =
-   val & PLANE_WM_BLOCKS_MASK;
-   active->planes[PLANE_CURSOR].wm[level].plane_res_l =
-   (val >> PLANE_WM_LINES_SHIFT) &
-   PLANE_WM_LINES_MASK;
-   }
+   plane_wm->wm[level].plane_en = is_enabled;
+   plane_wm->wm[level].plane_res_b = val & PLANE_WM_BLOCKS_MASK;
+   plane_wm->wm[level].plane_res_l =
+   (val >> PLANE_WM_LINES_SHIFT) & PLANE_WM_LINES_MASK;
} else {
-   if (!is_cursor) {
-   active->planes[i].trans_wm.plane_en = is_enabled;
-   active->planes[i].trans_wm.plane_res_b =
-   val & PLANE_WM_BLOCKS_MASK;
-   active->planes[i].trans_wm.plane_res_l =
-   (val >> PLANE_WM_LINES_SHIFT) &
-   PLANE_WM_LINES_MASK;
-   } else {
-   active->planes[PLANE_CURSOR].trans_wm.plane_en =
-   is_enabled;
-   active->planes[PLANE_CURSOR].trans_wm.plane_res_b =
-   val & PLANE_WM_BLOCKS_MASK;
-   active->planes[PLANE_CURSOR].trans_wm.plane_res_l =
-   (val >> PLANE_WM_LINES_SHIFT) &
-   PLANE_WM_LINES_MASK;
-   }
+   plane_wm->trans_wm.plane_en = is_enabled;
+   plane_wm->trans_wm.plane_res_b = val & PLANE_WM_BLOCKS_MASK;
+   plane_wm->trans_wm.plane_res_l =
+   (val >> PLANE_WM_LINES_SHIFT) & PLANE_WM_LINES_MASK;
}
 }
 
@@ -4345,20 +4321,20 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)
for (level = 0; level <= max_level; level++) {
for (i = 0; i < intel_num_planes(intel_crtc); i++) {
temp = hw->plane[pipe][i][level];
-   skl_pipe_wm_active_state(temp, active, false,
-   false, i, level);
+   skl_pipe_wm_active_state(temp, active, false, i, level);
}
temp = hw->plane[pipe][PLANE_CURSOR][level];
-   skl_pipe_wm_active_state(temp, active, false, true, i, level);
+   skl_pipe_wm_active_state(temp, active, false, PLANE_CURSOR,
+level);
}
 
for (i = 0; i < intel_num_planes(intel_crtc); i++) {
temp = hw->plane_trans[pipe][i];
-   skl_pipe_wm_active_state(temp, active, true, false, i, 0);
+   skl_pipe_wm_active_state(temp, active, true, i, 0);
}
 
temp = hw->plane_trans[pipe][PLANE_CURSOR];
-   skl_pipe_wm_active_state(temp, active, true, true, i, 0);
+   skl_pipe_wm_active_state(temp, active, true, PLANE_CURSOR, 0);
 
intel_crtc->wm.active.skl = *active;
 }
-- 
2.7.4

[GIT PULL 6/8] ARM: DT updates for v4.9

[Arnd Bergmann]

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8:

  Linux 4.8-rc4 (2016-08-28 15:04:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-dt

for you to fetch changes up to adff807988f92d4646c50b601936e340a92d5455:

  Merge tag 'berlin-dt-for-v4.9-1' of 
git://git.infradead.org/users/hesselba/linux-berlin into next/dt (2016-10-02 
22:20:39 -0700)


ARM: DT updates for v4.9

These are as usual a very large number of mostly boring updates to
enable devices in existing machines, or to fix minor bugs.  Notably,
an ongoing treewide effort to fix warnings caused by an update to the
device tree compiler. These are enabled with "make W=1" at the moment
but can hopefully become the default once all issues have been addressed.

No new SoC platform is added this time around (Armada 395 and Orion
mv88f5181 are slight variations of existing ones), but a significant
number of new dts files are added, which I list by platform:

- Allwinner: Empire Electronix M712 and iNet d978 Rev2 tablets;
Orange Pi PC Plus, Orange Pi 2, Orange Pi Plus 2E,
Orange Pi Lite, Olimex A33-Olinuxino, and Nano Pi Neo
single-board computers

- ARM Realview: all supported machines (ported from board files)

- Broadcom: BCM958525er, BCM958522er, BCM988312hr, BCM958623hr and
BCM958622hr reference boards for Northstar platform;
Raspberry Pi Zero single-board computer

- Marvell EBU: Netgear WNR854T router (ported from board file);
Armada 395 SoC platform and GP board
Armada 390 DB development board

- NXP i.MX: imx7s Warp7 reference board;
Gateworks Ventana GW553x single-board computer,
Technologic Systems TS-4900 and
Engicam IMX6UL GEA M6UL computer-on-module,
Inverse Path USB armory board

- Qualcomm: LG Nexus 5 Phone

- Renesas: r8a7792/wheat and r7s72100/rskrza1 development boards

- Rockchip: Rockchip RK3288 Fennec reference board;
Firefly RK3288 Reload platform

- ST Microelectronics STi: B2260 (96boards) single-board computer

- TI Davinci: OMAP-L138 LCDK Development kit

- TI OMAP: beagleboard-x15 rev B1 single-board computer

Conflicts: vendor-prefixes.txt has conflicting additions, keep all of
them in alphabetical order.


Adam Ford (1):
  ARM: dts: Add LogicPD DM37/AM37 Torpedo and SOM-LV

Andrej Rosano (2):
  devicetree: Add vendor prefix for Inverse Path
  ARM: dts: imx53: add support for USB armory board

Andrew F. Davis (3):
  ARM: dts: keystone-k2g: Add device state controller node
  ARM: dts: keystone-k2g: Add keystone IRQ controller node
  ARM: dts: keystone-k2g: Add DSP GPIO controller node

Andy Yan (5):
  soc: rockchip: add reboot-mode header
  ARM: dts: rockchip: add syscon-reboot-mode DT node
  ARM: dts: rockchip: enable usbotg for Popemtal-rk3288 board
  ARM: dts: rockchip: fix L3G4200D i2c address on PopMetal-RK3288 board
  ARM: dts: rockchip: Add sensor-supplies on PopMetal-RK3288 board

Anson Huang (1):
  ARM: dts: imx6ul iomuxc syscon is compatible to imx6q

Arnd Bergmann (30):
  ARM: dts: mvebu: fix reference to a390 spi controller
  Merge tag 'renesas-dt-for-v4.9' of git://git.kernel.org/.../horms/renesas 
into next/dt
  Merge tag 'lpc18xx_dts_for_4.9' of https://github.com/manabian/linux-lpc 
into next/dt
  Merge tag 'samsung-dt-4.9' of git://git.kernel.org/.../krzk/linux into 
next/dt
  Merge tag 'uniphier-dt-v4.9' of 
git://git.kernel.org/.../masahiroy/linux-uniphier into next/dt
  Merge tag 'keystone_dts_for_4.9' of 
git://git.kernel.org/.../ssantosh/linux-keystone into next/dt
  Merge tag 'omap-for-v4.9/dt-pt1-signed' of 
git://git.kernel.org/.../tmlind/linux-omap into next/dt
  Merge tag 'sti-dt-for-v4.9-1' of git://git.kernel.org/.../pchotard/sti 
into next/dt
  Merge tag 'qcom-dts-for-4.9' of git://git.kernel.org/.../agross/linux 
into next/dt
  Merge tag 'mvebu-dt-4.9-1' of git://git.infradead.org/linux-mvebu into 
next/dt
  Merge tag 'lpc18xx_dts_for_4.9_part2' of 
https://github.com/manabian/linux-lpc into next/dt
  Merge tag 'renesas-dt2-for-v4.9' of 
git://git.kernel.org/.../horms/renesas into next/dt
  Merge tag 'sunxi-dt-for-4.9' of https://git.kernel.org/.../mripard/linux 
into next/dt
  Merge tag 'v4.9-rockchip-dts32-1' of 
git://git.kernel.org/.../mmind/linux-rockchip into next/dt
  Merge tag 'tegra-for-4.9-arm-dt' of git://git.kernel.org/.../tegra/linux 
into next/dt
  Merge tag 'realview-dts-split' of 
git://git.kernel.org/.../linusw/linux-integrator into next/dt
  Merge tag 'imx-dt-4.9' of git://git.kernel.org/.../shawnguo/linux into 
next/dt
  Merge tag 'clcd-nomadik' of git://git.kernel.org/.../linusw/linux-nomadik 
into next/dt
  Merge tag 

[GIT PULL 5/8] ARM: SoC driver updates for v4.9

[Arnd Bergmann]

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8:

  Linux 4.8-rc4 (2016-08-28 15:04:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-drivers

for you to fetch changes up to d6db68b2deaa0158d25b236edffcf6dd2117208f:

  bus: qcom-ebi2: depend on HAS_IOMEM (2016-10-02 22:23:57 -0700)


ARM: SoC driver updates for v4.9

Driver updates for ARM SoCs, including a couple of newly added drivers:

- The Qualcomm external bus interface 2 (EBI2), used in some of their
  mobile phone chips for connecting flash memory, LCD displays or
  other peripherals

- Secure monitor firmware for Amlogic SoCs, and an NVMEM driver for the
  EFUSE based on that firmware interface.

- Perf support for the AppliedMicro X-Gene performance monitor unit

- Reset driver for STMicroelectronics STM32

- Reset driver for SocioNext UniPhier SoCs

Aside from these, there are minor updates to SoC-specific bus,
clocksource, firmware, pinctrl, reset, rtc and pmic drivers.


Arnd Bergmann (14):
  Merge tag 'gpmc-omap-for-v4.9' of https://github.com/rogerq/linux into 
next/drivers
  Merge tag 'reset-for-4.9' of git://git.pengutronix.de/git/pza/linux into 
next/drivers
  Merge commit 'http://github.com/rogerq/linux gpmc-omap-v4.8-rc1' into 
next/drivers
  Merge tag 'amlogic-drivers' of 
git://git.kernel.org/.../khilman/linux-amlogic into next/drivers
  Merge tag 'v4.9-rockchip-drivers1' of 
git://git.kernel.org/.../mmind/linux-rockchip into next/drivers
  Merge tag 'at91-ab-4.9-drivers' of 
git://git.kernel.org/.../abelloni/linux into next/drivers
  Merge tag 'qcom-drivers-for-4.9' of git://git.kernel.org/.../agross/linux 
into next/drivers
  Merge tag 'tegra-for-4.9-bus' of git://git.kernel.org/.../tegra/linux 
into next/drivers
  Merge tag 'tegra-for-4.9-soc' of git://git.kernel.org/.../tegra/linux 
into next/drivers
  Merge tag 'v4.8-next-soc' of https://github.com/mbgg/linux-mediatek into 
next/drivers
  Merge tag 'samsung-drivers-4.9-2' of git://git.kernel.org/.../krzk/linux 
into next/drivers
  Merge tag 'xgene-drivers-for-4.9' of 
https://github.com/AppliedMicro/xgene-next into next/drivers
  Merge tag 'mvebu-drivers-4.9-1' of git://git.infradead.org/linux-mvebu 
into next/drivers
  Merge tag 'qcom-ebi2-arm-soc' of 
git://git.kernel.org/.../linusw/linux-integrator into next/drivers

Baoyou Xie (1):
  memory: omap-gpmc: make gpmc_clk_ticks_to_ns() static

Bjorn Andersson (5):
  soc: qcom: smd: Correct compile stub prototypes
  soc: qcom: smd: Simplify multi channel handling
  soc: qcom: smd: Request irqs after parsing properties
  soc: qcom: smd: Represent smd edges as devices
  soc: qcom: smd: Reset rx tail rather than tx

Carlo Caione (2):
  firmware: Amlogic: Add secure monitor driver
  nvmem: amlogic: Add Amlogic Meson EFUSE driver

Chanwoo Choi (2):
  clocksource: exynos_mct: Add the support for ARM64
  dt-bindings: EXYNOS: Add Exynos5433 PMU compatible

Elaine Zhang (1):
  soc: rockchip: support active_wakeup for rockchip power-domains

Gabriel Fernandez (1):
  ARM: dts: stm32f429: add missing #reset-cells of rcc

Henry Chen (1):
  soc: mediatek: PMIC wrap: Extend the waiting time to 10ms.

Jamie Lentin (2):
  clk: mvebu: Add clk support for the orion5x SoC mv88f5181
  pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181

Jon Hunter (1):
  bus: tegra-aconnect: Use of_pm_clk_add_clk()

LABBE Corentin (1):
  memory: atmel-sdramc: fix a possible NULL dereference

Linus Walleij (4):
  memory: omap-gpmc: use devm_gpiochip_add_data()
  bus: qcom: add EBI2 device tree bindings
  bus: qcom: add EBI2 driver
  bus: qcom-ebi2: depend on HAS_IOMEM

Markus Elfring (1):
  memory: omap-gpmc: Delete an unnecessary check before the function call 
"gpiochip_free_own_desc"

Masahiro Yamada (1):
  reset: uniphier: add reset controller driver for UniPhier SoCs

Maxime Coquelin (3):
  dt-bindings: mfd: Add STM32F4 RCC numeric constants into DT include file
  dt-bindings: Document the STM32 reset bindings
  drivers: reset: Add STM32 reset driver

Neil Armstrong (2):
  media: rc: meson-ir: Add support for newer versions of the IR decoder
  rtc: rtc-pm8xxx: Add support for pm8018 rtc

Paul Gortmaker (1):
  firmware: qcom_scm: make it explicitly non-modular

Philipp Zabel (13):
  reset: socfpga: no need to store modrst_offset
  reset: warn on invalid input to reset_control_reset/assert/deassert/status
  reset: ath79: add missing include
  reset: ath79: add driver Kconfig option
  reset: berlin: add driver Kconfig option
  reset: lpc18xx: add driver Kconfig option
  reset: meson: add driver Kconfig option
  reset: 

[GIT PULL 3/8] ARM: SoC defconfig changes for v4.9

[Arnd Bergmann]

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8:

  Linux 4.8-rc4 (2016-08-28 15:04:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-defconfig

for you to fetch changes up to 3f0958d8aea708019d52962a7a8fe827d9f9006c:

  ARM: multi_v7_defconfig: enable CONFIG_EFI (2016-09-19 17:16:34 +0200)


ARM: SoC defconfig updates for v4.9

Defconfig additions, removals, etc. Most of these are small changes adding
the options for newly upstreamed drivers, or drivers needed for new board
support. Nothing specifically sticks out this time.


Ard Biesheuvel (1):
  ARM: multi_v7_defconfig: enable CONFIG_EFI

Arnd Bergmann (6):
  Merge tag 'davinci-for-v4.9/defconfig' of 
git://git.kernel.org/.../nsekhar/linux-davinci into next/defconfig
  Merge tag 'samsung-defconfig-4.9' of git://git.kernel.org/.../krzk/linux 
into next/defconfig
  Merge tag 'omap-for-v4.9/defconfig-signed' of 
git://git.kernel.org/.../tmlind/linux-omap into next/defconfig
  Merge tag 'keystone_config_for_4.9' of 
git://git.kernel.org/.../ssantosh/linux-keystone into next/defconfig
  Merge tag 'mvebu-defconfig-4.9-1' of git://git.infradead.org/linux-mvebu 
into next/defconfig
  Merge tag 'imx-defconfig-4.9' of git://git.kernel.org/.../shawnguo/linux 
into next/defconfig

Borislav Petkov (1):
  ARM: s3c2410_defconfig: Remove CONFIG_IPV6_PRIVACY

Breno Lima (1):
  ARM: imx_v6_v7_defconfig: Add CONFIG_MPL3115

Chanwoo Choi (1):
  ARM: exynos_defconfig: Enable bus frequency scaling with devfreq

Fabian Frederick (1):
  ARM: mvebu_v5_defconfig: use MV88E6XXX

Fabio Estevam (2):
  ARM: imx_v6_v7_defconfig: Enable GPU support
  ARM: imx_v6_v7_defconfig: Select the wm8960 codec driver

Grzegorz Jaszczyk (2):
  ARM: mvebu: enable MTD command line partition table in mvebu_v7_defconfig
  ARM: mvebu: enable UBI and UBIFS in mvebu_v7_defconfig

Javier Martinez Canillas (1):
  ARM: multi_v7_defconfig: Build Atmel maXTouch driver as a module

Karl Beldan (4):
  ARM: davinci_all_defconfig: enable RTC driver as module
  ARM: davinci_all_defconfig: enable SMSC ethernet PHY
  ARM: davinci_all_defconfig: Enable AEMIF as a module
  ARM: davinci_all_defconfig: Enable some UBI modules

Kevin Hilman (2):
  ARM: davinci_all_defconfig: cleanup with savedefconfig
  ARM: davinci_all_defconfig: enable DA850 audio as modules

Krzysztof Kozlowski (4):
  ARM: exynos_defconfig: Enable PM_DEBUG
  ARM: exynos_defconfig: Enable SECCOMP
  ARM: multi_v7_defconfig: Enable SECCOMP
  Merge tag 'tags/samsung-defconfig-schedutil-4.9' into next/defconfig

Linus Walleij (2):
  ARM: omap2plus_defconfig: switch to the IIO BMP085 driver
  ARM: defconfig: update the Integrator defconfig

Peter Chen (1):
  ARM: imx_v6_v7_defconfig: enable more USB configurations

Roger Quadros (1):
  ARM: keystone: defconfig: Fix USB configuration

Tuomas Tynkkynen (2):
  ARM: multi_v7_defconfig: Enable AHCI_IMX
  ARM: multi_v7_defconfig: Enable ARM_IMX6Q_CPUFREQ

 arch/arm/configs/davinci_all_defconfig | 66 +-
 arch/arm/configs/exynos_defconfig  | 11 +-
 arch/arm/configs/imx_v6_v7_defconfig   | 17 +
 arch/arm/configs/integrator_defconfig  | 13 ++-
 arch/arm/configs/keystone_defconfig|  1 +
 arch/arm/configs/multi_v7_defconfig| 13 +--
 arch/arm/configs/mvebu_v5_defconfig|  5 +--
 arch/arm/configs/mvebu_v7_defconfig|  3 ++
 arch/arm/configs/omap2plus_defconfig   |  2 +-
 arch/arm/configs/s3c2410_defconfig |  1 -
 10 files changed, 66 insertions(+), 66 deletions(-)

[GIT PULL 7/8] ARM: 64-bit DT updates for v4.8

[Arnd Bergmann]

The following changes since commit f2a89d3b2b85b90b05453872aaabfdb412a21a03:

  arm64: dts: Fix broken architected timer interrupt trigger (2016-09-14 
22:47:22 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-dt64

for you to fetch changes up to c1fd2794a4111501027dc60b3fd9d2a29789ea47:

  Merge tag 'berlin64-dt-for-v4.9-1' of 
git://git.infradead.org/users/hesselba/linux-berlin into next/dt64 (2016-10-02 
22:21:33 -0700)


ARM: 64-bit DT updates for v4.8

The 64-bit DT changes are surprisingly small this time, we only add two
SoC platforms: the ZTE ZX296718 Set-top-box SoC and the SocioNext
UniPhier LD11 TV SoC, each with their reference boards.

There are three new machines added for existing SoC platforms:

- The Marvell Armada 8040 development board is an impressive quad-core
  Cortex-A72 machine with three 10gbit ethernet interfaces

- Qualcomms DragonBoard 820c single-board computer is their current
  high-end phone platform in the 96boards form factor

- Rockchip: Tronsmart Orion r86 set-top-box is a popular mid-range
  Android box based on the 8-core rk3368 SoC.


Alexander Graf (1):
  ARM64: zynqmp: Align gic ranges for 64k in device tree

Andy Yan (2):
  soc: rockchip: add reboot-mode header
  arm64: dts: rockchip: add syscon-reboot-mode DT node

Archit Taneja (2):
  arm64: dts: msm8916: Add display support
  arm64: dts: apq8016-sbc: Add HDMI display support

Arnd Bergmann (15):
  Merge tag 'uniphier-dt64-v4.9' of 
git://git.kernel.org/.../masahiroy/linux-uniphier into next/dt64
  Merge tag 'samsung-dt64-4.9' of git://git.kernel.org/.../krzk/linux into 
next/dt64
  Merge tag 'hisi-soc-dt-for-4.9' of git://github.com/hisilicon/linux-hisi 
into next/dt64
  Merge tag 'qcom-arm64-for-4.9' of git://git.kernel.org/.../agross/linux 
into next/dt64
  Merge tag 'mvebu-dt64-4.9-1' of git://git.infradead.org/linux-mvebu into 
next/dt64
  Merge tag 'arm-soc/for-4.9/devicetree-arm64' of 
http://github.com/Broadcom/stblinux into next/dt64
  Merge tag 'v4.9-rockchip-dts64-1' of 
git://git.kernel.org/.../mmind/linux-rockchip into next/dt64
  Merge tag 'tegra-for-4.9-arm64-dt' of 
git://git.kernel.org/.../tegra/linux into next/dt64
  Merge tag 'imx-dt64-4.9' of git://git.kernel.org/.../shawnguo/linux into 
next/dt64
  Merge tag 'v4.8-next-dts64' of https://github.com/mbgg/linux-mediatek 
into next/dt64
  Merge tag 'zynqmp-dt-for-4.9' of https://github.com/Xilinx/linux-xlnx 
into next/dt64
  Merge branch 'dt/irq-fix' into next/dt64
  Merge tag 'mvebu-dt64-4.9-2' of git://git.infradead.org/linux-mvebu into 
next/dt64
  Merge tag 'xgene-dts-for-v4.9' of 
https://github.com/AppliedMicro/xgene-next into next/dt64
  Merge tag 'zte-dt64-4.9' of git://git.kernel.org/.../shawnguo/linux into 
next/dt64

Bjorn Andersson (4):
  arm64: dts: qcom: msm8916: Add smsm and smp2p nodes
  arm64: dts: qcom: msm8916: Add mba memory reserve
  arm64: dts: qcom: msm8916: Make scm a reset-controller
  arm64: dts: qcom: msm8916: Add tcsr syscon

CK Hu (1):
  arm64: dts: mt8173: Add HDMI related nodes

Caesar Wang (5):
  arm64: dts: rockchip: add the saradc for rk3399
  arm64: dts: rockchip: add the gmac power domain on rk3399
  arm64: dts: rockchip: add the tcpc for rk3399 power domain
  arm64: dts: rockchip: change all interrupts cells to 4 on rk3399 SoCs
  arm64: dts: rockchip: support the pmu node for rk3399

Chris Zhong (1):
  arm64: dts: rockchip: add Type-C phy for RK3399

Douglas Anderson (1):
  arm64: dts: rockchip: Add pinctrl entry for 32k clock on rk3399

Duc Dang (2):
  arm64: dts: apm: Add APM X-Gene v2 SoC PMU DTS entries
  arm64: dts: apm: Fix interrupt polarity for X-Gene PCIe legacy interrupts

Elaine Zhang (1):
  arm64: dts: rockchip: add the power domain node for rk3399

Finley Xiao (1):
  arm64: dts: rockchip: add efuse0 device node for rk3399

Frank Wang (2):
  arm64: dts: rockchip: add usb2-phy support for rk3399
  arm64: dts: rockchip: configure usb2-phy support for rk3399-evb

Guodong Xu (3):
  arm64: dts: hikey: extend default cma size to 128MB
  arm64: dts: hi6220: add resets property into dwmmc nodes
  arm64: dts: hi6220: add sd-uhs- properties into dwmmc_1

Heiko Stuebner (1):
  Merge branch 'v4.9-shared/soc-hdr' into v4.9-armsoc/dts64

Jisheng Zhang (3):
  arm64: dts: berlin4ct: switch to Cortex-A53 specific pmu nodes
  arm64: dts: berlin4ct: enable all wdt nodes unconditionally
  arm64: dts: berlin4ct: Add L2 cache topology

John Stultz (2):
  arm64: dts: hikey: Add hikey support for syscon-reboot-mode
  arm64: dts: hikey: Add pstore support for HiKey

Jon Hunter (9):
  arm64: tegra: Drop clock and reset names for XUSB 

Re: [PATCH V1 04/10] watchdog: da9061: watchdog driver (RFC)

[Dmitry Torokhov]

On Fri, Oct 07, 2016 at 06:01:23PM +, Steve Twiss wrote:
> On 07 October 2016 18:02, Guenter Roeck wrote:
> 
> > > On 06 October 2016 19:49, Guenter Roeck wrote:
> > > > On Thu, Oct 06, 2016 at 04:28:14PM +, Steve Twiss wrote:
> > > > > I am using the compatible string to pick a different configuration 
> > > > > .data block:
> > > > > { .compatible = "dlg,da9062-watchdog", .data = _watchdog_info 
> > > > > },
> > > > > { .compatible = "dlg,da9061-watchdog", .data = _watchdog_info 
> > > > > },
> > > > >
> > > > > But, it is just my opinion to keep the "name" different.
> > > > > This will not be my decision if accepted into the Linux kernel, but I 
> > > > > would like to
> > > > > at least be consistent for DA9061 and DA9062 so ... is this an issue?
> > > >
> > > > FWIW the driver doesn't really need to be updated in the first place.
> > > > A compatible statement listing both da9061 and da9062 would do it.
> > >
> > > I will make the changes you requested: deprecate the existing 
> > > compatibility
> > > for da9062-watchdog and make a new compatibility string which combines 
> > > both
> > > da9061 and da9062.
> > >
> > That is not what I asked for.
> 
> Ok. Did you mean separate compatible statements with data sections pointing 
> at 
> the same structure?
> 
> Like this:
> { .compatible = "dlg,da9062-watchdog", .data = _watchdog_info },
> { .compatible = "dlg,da9061-watchdog", .data = _watchdog_info },
> 
> So this would be the only change needed in the device driver.

If there is no change in IP block then I do not see why we need to
introduce new names at all. The dts can specify fallback compatible
stting. Note, it is called *compatible* not "model" or "device id" or
whatever. So you can just say in DTS:

compatible = "dlg,da9061-watchdog", "dlg,da9062-watchdog";

and leave the driver alone. That goes for input part as well. You only
need to add new compatible to the driver when it in fact is
*incompatible* with the existing blocks.

Thanks.

-- 
Dmitry

Re: [GIT PULL] trivial for 4.9

[Linus Torvalds]

On Fri, Oct 7, 2016 at 4:09 PM, Tony Luck  wrote:
> On Fri, Oct 7, 2016 at 4:01 PM, Tony Luck  wrote:
>> What if there isn't a "next printk" call for hours, or days?
>>
>> That poor little message without a "\n" will sit in the kernel buffers,
>> and the user who might want to see the message can't, until some
>> unrelated thing happens to print something.
>
> Retracted ...  I'm sure that at some point in the past it happened
> like that ...  but I just retested on 4.8 and the first message (with
> no "\n") showed up on the serial port just fine without some other
> message to push it out.  When the next message came along, a "\n" was
> auto-inserted.

Yeah, that immediate printout has actually always worked fine - the
newline was never really a buffering thing.

The buffering actually came fairly late, with the "newfangled"
record-oriented logging facility (4+ years old by now).

Our kernel message log was historically just a plain buffer, and not
record-oriented at all. You'd just read and write it as a stream. In
that historical context, it made tons of sense to just write something
without a newline, and then continue writing on the same line: that's
how  always works.

But back in 2012, Kay Sievers wanted to make it record-based, because
reasons. That *really* doesn't play well with the whole "oh, you might
not get the whole thing in one go" model, and things were broken a few
times. It also made our printk implementation a lot more complex. But
there was some argument for a full-featured syslog facility.  Line
continuations suddenly weren't very natural any more, because now a
continuation printk was very much a "broken record".

Anyway, the complexity has had upsides too, and the "let's not require
'\n' at the end" actually came in through that (in fact, I think the
record-based internal format removes the newlines at the end of
characters). And there are some real advantages, both with timestamps
and with having per-record log levels. So it's definitely not all bad,
but there's a fair amount of complexity in there. The old model was
rather broken in other ways, though, so on the whole I think we're
doing fairly ok.

But yes, the line continuation that *used* to be very natural (but
always had problems with concurrent output from multiple contexts)
definitely makes for extra complexity in the record-based model. But
exactly *because* the record-based thing needs to be more careful
about those newlines, it actually ended up being why the explicit "\n"
thing at the end of a printk shouldn't really matter any more.

And not having it does make for nicer printk strings. "Just the facts".

 Linus

[PATCH v3 01/18] Documentation, ABI: Add a document entry for cache id

[Fenghua Yu]

From: Fenghua Yu 

Add an ABI document entry for /sys/devices/system/cpu/cpu*/cache/index*/id.

Signed-off-by: Fenghua Yu 
Signed-off-by: Tony Luck 
---
 Documentation/ABI/testing/sysfs-devices-system-cpu | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu 
b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 4987417..b1c3d69 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -272,6 +272,22 @@ Description:   Parameters for the CPU cache attributes
 the modified cache line is written to main
 memory only when it is replaced
 
+
+What:  /sys/devices/system/cpu/cpu*/cache/index*/id
+Date:  September 2016
+Contact:   Linux kernel mailing list 
+Description:   Cache id
+
+   The id provides a unique name for a specific instance of
+   a cache of a particular type. E.g. there may be a level
+   3 unified cache on each socket in a server and we may
+   assign them ids 0, 1, 2, ...
+
+   Note that id value may not be contiguous. E.g. level 1
+   caches typically exist per core, but there may not be a
+   power of two cores on a socket, so these caches may be
+   numbered 0, 1, 2, 3, 4, 5, 8, 9, 10, ...
+
 What:  /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/turbo_stat

/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/sub_turbo_stat
-- 
2.5.0

[PATCH v2 02/10] drm/i915/skl: Remove linetime from skl_wm_values

[Lyude]

Next part of cleaning up the watermark code for skl. This is easy, since
it seems that we never actually needed to keep track of the linetime in
the skl_wm_values struct anyway.

Signed-off-by: Lyude 
Reviewed-by: Paulo Zanoni 
Reviewed-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  | 1 -
 drivers/gpu/drm/i915/intel_display.c | 6 --
 drivers/gpu/drm/i915/intel_pm.c  | 7 +--
 3 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bb2de8d..e9d035ea 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1644,7 +1644,6 @@ struct skl_ddb_allocation {
 struct skl_wm_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
-   uint32_t wm_linetime[I915_MAX_PIPES];
uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
 };
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 17733af..a71d05a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14832,6 +14832,8 @@ static void intel_begin_crtc_commit(struct drm_crtc 
*crtc,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *intel_cstate =
+   to_intel_crtc_state(crtc->state);
struct intel_crtc_state *old_intel_state =
to_intel_crtc_state(old_crtc_state);
bool modeset = needs_modeset(crtc->state);
@@ -14848,13 +14850,13 @@ static void intel_begin_crtc_commit(struct drm_crtc 
*crtc,
intel_color_load_luts(crtc->state);
}
 
-   if (to_intel_crtc_state(crtc->state)->update_pipe)
+   if (intel_cstate->update_pipe)
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_GEN(dev_priv) >= 9) {
skl_detach_scalers(intel_crtc);
 
I915_WRITE(PIPE_WM_LINETIME(pipe),
-  dev_priv->wm.skl_hw.wm_linetime[pipe]);
+  intel_cstate->wm.skl.optimal.linetime);
}
 }
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 68355b0..cc5d5e9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3841,8 +3841,6 @@ static void skl_compute_wm_results(struct drm_device *dev,
temp |= PLANE_WM_EN;
 
r->plane_trans[pipe][PLANE_CURSOR] = temp;
-
-   r->wm_linetime[pipe] = p_wm->linetime;
 }
 
 static void skl_ddb_entry_write(struct drm_i915_private *dev_priv,
@@ -4077,7 +4075,6 @@ skl_copy_wm_for_pipe(struct skl_wm_values *dst,
 struct skl_wm_values *src,
 enum pipe pipe)
 {
-   dst->wm_linetime[pipe] = src->wm_linetime[pipe];
memcpy(dst->plane[pipe], src->plane[pipe],
   sizeof(dst->plane[pipe]));
memcpy(dst->plane_trans[pipe], src->plane_trans[pipe],
@@ -4328,8 +4325,6 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)
 
max_level = ilk_wm_max_level(dev);
 
-   hw->wm_linetime[pipe] = I915_READ(PIPE_WM_LINETIME(pipe));
-
for (level = 0; level <= max_level; level++) {
for (i = 0; i < intel_num_planes(intel_crtc); i++)
hw->plane[pipe][i][level] =
@@ -4346,7 +4341,7 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)
 
hw->dirty_pipes |= drm_crtc_mask(crtc);
 
-   active->linetime = hw->wm_linetime[pipe];
+   active->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
 
for (level = 0; level <= max_level; level++) {
for (i = 0; i < intel_num_planes(intel_crtc); i++) {
-- 
2.7.4

[PATCH v2 01/10] drm/i915/skl: Move per-pipe ddb allocations into crtc states

[Lyude]

First part of cleaning up all of the skl watermark code. This moves the
structures for storing the ddb allocations of each pipe into
intel_crtc_state, along with moving the structures for storing the
current ddb allocations active on hardware into intel_crtc.

Changes since v1:
- Don't replace alloc->start = alloc->end = 0;

Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_display.c | 16 ---
 drivers/gpu/drm/i915/intel_drv.h |  8 +---
 drivers/gpu/drm/i915/intel_pm.c  | 40 +++-
 4 files changed, 30 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a219a35..bb2de8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1637,7 +1637,6 @@ static inline bool skl_ddb_entry_equal(const struct 
skl_ddb_entry *e1,
 }
 
 struct skl_ddb_allocation {
-   struct skl_ddb_entry pipe[I915_MAX_PIPES];
struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* 
packed/uv */
struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
 };
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a366656..17733af 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14235,12 +14235,11 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
 unsigned int *crtc_vblank_mask)
 {
struct drm_device *dev = state->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_crtc *crtc;
+   struct intel_crtc *intel_crtc;
struct drm_crtc_state *old_crtc_state;
-   struct skl_ddb_allocation *new_ddb = _state->wm_results.ddb;
-   struct skl_ddb_allocation *cur_ddb = _priv->wm.skl_hw.ddb;
+   struct intel_crtc_state *cstate;
unsigned int updated = 0;
bool progress;
enum pipe pipe;
@@ -14258,12 +14257,14 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
bool vbl_wait = false;
unsigned int cmask = drm_crtc_mask(crtc);
-   pipe = to_intel_crtc(crtc)->pipe;
+
+   intel_crtc = to_intel_crtc(crtc);
+   cstate = to_intel_crtc_state(crtc->state);
+   pipe = intel_crtc->pipe;
 
if (updated & cmask || !crtc->state->active)
continue;
-   if (skl_ddb_allocation_overlaps(state, cur_ddb, new_ddb,
-   pipe))
+   if (skl_ddb_allocation_overlaps(state, intel_crtc))
continue;
 
updated |= cmask;
@@ -14274,7 +14275,8 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
 * then we need to wait for a vblank to pass for the
 * new ddb allocation to take effect.
 */
-   if (!skl_ddb_allocation_equals(cur_ddb, new_ddb, pipe) 
&&
+   if (!skl_ddb_entry_equal(>wm.skl.ddb,
+_crtc->hw_ddb) &&
!crtc->state->active_changed &&
intel_state->wm_results.dirty_pipes != updated)
vbl_wait = true;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f48e79a..35ba282 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -496,6 +496,7 @@ struct intel_crtc_wm_state {
struct {
/* gen9+ only needs 1-step wm programming */
struct skl_pipe_wm optimal;
+   struct skl_ddb_entry ddb;
 
/* cached plane data rate */
unsigned plane_data_rate[I915_MAX_PLANES];
@@ -733,6 +734,9 @@ struct intel_crtc {
bool cxsr_allowed;
} wm;
 
+   /* gen9+: ddb allocation currently being used */
+   struct skl_ddb_entry hw_ddb;
+
int scanline_offset;
 
struct {
@@ -1755,9 +1759,7 @@ bool skl_ddb_allocation_equals(const struct 
skl_ddb_allocation *old,
   const struct skl_ddb_allocation *new,
   enum pipe pipe);
 bool skl_ddb_allocation_overlaps(struct drm_atomic_state *state,
-const struct skl_ddb_allocation *old,
-   

[PATCH v2 03/10] drm/i915/gen9: Make skl_wm_level per-plane

[Lyude]

Having skl_wm_level contain all of the watermarks for each plane is
annoying since it prevents us from having any sort of object to
represent a single watermark level, something we take advantage of in
the next commit to cut down on all of the copy paste code in here.

Changes since v1:
- Style nitpicks
- Fix accidental usage of i vs. PLANE_CURSOR
- Split out skl_pipe_wm_active_state simplification into separate patch

Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |   6 +-
 drivers/gpu/drm/i915/intel_drv.h |   6 +-
 drivers/gpu/drm/i915/intel_pm.c  | 207 +++
 3 files changed, 111 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e9d035ea..0287c93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1649,9 +1649,9 @@ struct skl_wm_values {
 };
 
 struct skl_wm_level {
-   bool plane_en[I915_MAX_PLANES];
-   uint16_t plane_res_b[I915_MAX_PLANES];
-   uint8_t plane_res_l[I915_MAX_PLANES];
+   bool plane_en;
+   uint16_t plane_res_b;
+   uint8_t plane_res_l;
 };
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 35ba282..d684f4f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -468,9 +468,13 @@ struct intel_pipe_wm {
bool sprites_scaled;
 };
 
-struct skl_pipe_wm {
+struct skl_plane_wm {
struct skl_wm_level wm[8];
struct skl_wm_level trans_wm;
+};
+
+struct skl_pipe_wm {
+   struct skl_plane_wm planes[I915_MAX_PLANES];
uint32_t linetime;
 };
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index cc5d5e9..4c2ebcd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3670,67 +3670,52 @@ static int
 skl_compute_wm_level(const struct drm_i915_private *dev_priv,
 struct skl_ddb_allocation *ddb,
 struct intel_crtc_state *cstate,
+struct intel_plane *intel_plane,
 int level,
 struct skl_wm_level *result)
 {
struct drm_atomic_state *state = cstate->base.state;
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
-   struct drm_plane *plane;
-   struct intel_plane *intel_plane;
-   struct intel_plane_state *intel_pstate;
+   struct drm_plane *plane = _plane->base;
+   struct intel_plane_state *intel_pstate = NULL;
uint16_t ddb_blocks;
enum pipe pipe = intel_crtc->pipe;
int ret;
+   int i = skl_wm_plane_id(intel_plane);
+
+   if (state)
+   intel_pstate =
+   intel_atomic_get_existing_plane_state(state,
+ intel_plane);
 
/*
-* We'll only calculate watermarks for planes that are actually
-* enabled, so make sure all other planes are set as disabled.
+* Note: If we start supporting multiple pending atomic commits against
+* the same planes/CRTC's in the future, plane->state will no longer be
+* the correct pre-state to use for the calculations here and we'll
+* need to change where we get the 'unchanged' plane data from.
+*
+* For now this is fine because we only allow one queued commit against
+* a CRTC.  Even if the plane isn't modified by this transaction and we
+* don't have a plane lock, we still have the CRTC's lock, so we know
+* that no other transactions are racing with us to update it.
 */
-   memset(result, 0, sizeof(*result));
+   if (!intel_pstate)
+   intel_pstate = to_intel_plane_state(plane->state);
 
-   for_each_intel_plane_mask(_priv->drm,
- intel_plane,
- cstate->base.plane_mask) {
-   int i = skl_wm_plane_id(intel_plane);
-
-   plane = _plane->base;
-   intel_pstate = NULL;
-   if (state)
-   intel_pstate =
-   intel_atomic_get_existing_plane_state(state,
- 
intel_plane);
+   WARN_ON(!intel_pstate->base.fb);
 
-   /*
-* Note: If we start supporting multiple pending atomic commits
-* against the same planes/CRTC's in the future, plane->state
-* will no longer be the correct pre-state to use for the
-* calculations here and we'll need to change where we get the
-* 'unchanged' plane data from.
-*
-* For now this is fine because we 

[REGRESSION v4.7] i915 / drm crash when undocking from DP monitors

[Vadim Lobanov]

Hi folks,

I'm seeing a repeatable crash on my HP EliteBook 840 G2/2216 when
booting it while in a docking station connected to two external
DisplayPort monitors, undocking, and then either logging out or
shutting down -- regardless of whether I've redocked it beforehand or
not. Both logout and shutdown work great if I do not undock the laptop
at all, so the badness correlates with the DP monitors going away.

This is a regression introduced somewhere in the v4.6 -> v4.7
development timeframe: 4.6.0 works, 4.7.0 fails as described, and
4.8.0 crashes earlier still when undocking.

The graphics hardware involved is:

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500
(rev 09) (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company ZBook 15u G2 Mobile Workstation
Flags: bus master, fast devsel, latency 0, IRQ 49
Memory at c000 (64-bit, non-prefetchable) [size=16M]
Memory at b000 (64-bit, prefetchable) [size=256M]
I/O ports at 5000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915

And the crash that I see is similar to this:

Oct 07 17:47:16 localhost.localdomain kernel: BUG: unable to handle
kernel paging request at 00018c70
Oct 07 17:47:16 localhost.localdomain kernel: IP: []
queued_spin_lock_slowpath+0x108/0x190
Oct 07 17:47:16 localhost.localdomain kernel: PGD 0
Oct 07 17:47:16 localhost.localdomain kernel: Oops: 0002 [#1] SMP
Oct 07 17:47:16 localhost.localdomain kernel: Modules linked in:
rfcomm ccm xt_CHECKSUM tun ipt_MASQUERADE nf_nat_masquerade_ipv4
xt_addrtype nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_REJECT
nf_reject_
Oct 07 17:47:16 localhost.localdomain kernel:  sparse_keymap ppdev
irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel iwlwifi
intel_cstate intel_uncore intel_rapl_perf cfg80211 joydev uvcvideo
lpc_ich r
Oct 07 17:47:16 localhost.localdomain kernel: CPU: 2 PID: 855 Comm:
systemd-logind Not tainted 4.7.5-200.fc24.x86_64 #1
Oct 07 17:47:16 localhost.localdomain kernel: Hardware name:
Hewlett-Packard HP EliteBook 840 G2/2216, BIOS M71 Ver. 01.04
02/24/2015
Oct 07 17:47:16 localhost.localdomain kernel: task: 88043a12
ti: 880035d5 task.ti: 880035d5
Oct 07 17:47:16 localhost.localdomain kernel: RIP:
0010:[]  []
queued_spin_lock_slowpath+0x108/0x190
Oct 07 17:47:16 localhost.localdomain kernel: RSP:
0018:880035d53908  EFLAGS: 00010202
Oct 07 17:47:16 localhost.localdomain kernel: RAX: 00018c70
RBX: 880438716a50 RCX: 88044f498c40
Oct 07 17:47:16 localhost.localdomain kernel: RDX: 1b9a
RSI: 6e6f746f RDI: 880438716a54
Oct 07 17:47:16 localhost.localdomain kernel: RBP: 880035d53908
R08: 000c R09: 
Oct 07 17:47:16 localhost.localdomain kernel: R10: 880096e4e780
R11: 0898 R12: 88043ab3ec40
Oct 07 17:47:16 localhost.localdomain kernel: R13: 880438716a58
R14: 880427ebd800 R15: 8804396bd000
Oct 07 17:47:16 localhost.localdomain kernel: FS:
7f22e2cb5900() GS:88044f48()
knlGS:
Oct 07 17:47:16 localhost.localdomain kernel: CS:  0010 DS:  ES:
 CR0: 80050033
Oct 07 17:47:16 localhost.localdomain kernel: CR2: 00018c70
CR3: 00043a095000 CR4: 003406e0
Oct 07 17:47:16 localhost.localdomain kernel: DR0: 
DR1:  DR2: 
Oct 07 17:47:16 localhost.localdomain kernel: DR3: 
DR6: fffe0ff0 DR7: 0400
Oct 07 17:47:16 localhost.localdomain kernel: Stack:
Oct 07 17:47:16 localhost.localdomain kernel:  880035d53918
967ec350 880035d53940 967e9f2f
Oct 07 17:47:16 localhost.localdomain kernel:  88043ab3ec40
880438716a50 880438714800 880035d53970
Oct 07 17:47:16 localhost.localdomain kernel:  c00a155e
880427e49800 880438716800 880427ebd800
Oct 07 17:47:16 localhost.localdomain kernel: Call Trace:
Oct 07 17:47:16 localhost.localdomain kernel:  []
_raw_spin_lock+0x20/0x30
Oct 07 17:47:16 localhost.localdomain kernel:  []
__ww_mutex_lock+0x6f/0xa0
Oct 07 17:47:16 localhost.localdomain kernel:  []
drm_modeset_lock+0x4e/0xd0 [drm]
Oct 07 17:47:16 localhost.localdomain kernel:  []
drm_atomic_get_connector_state+0x34/0x1c0 [drm]
Oct 07 17:47:16 localhost.localdomain kernel:  []
__drm_atomic_helper_set_config+0x2a0/0x360 [drm_kms_helper]
Oct 07 17:47:16 localhost.localdomain kernel:  []
restore_fbdev_mode+0x22a/0x260 [drm_kms_helper]
Oct 07 17:47:16 localhost.localdomain kernel:  []
drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper]
Oct 07 17:47:16 localhost.localdomain kernel:  []
drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
Oct 07 17:47:16 localhost.localdomain kernel:  []

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

[Rich Felker]

On Fri, Sep 30, 2016 at 03:15:11PM +0200, Thomas Gleixner wrote:
> On Tue, 27 Sep 2016, Rich Felker wrote:
> > I've managed to get a trace with a stall. I'm not sure what the best
> > way to share the full thing is, since it's large, but here are the
> > potentially interesting parts.
> 
> Upload it somewhere.
>  
> > The first is a big time gap with no events, from 82.446093 to
> > 109.852709:
> > 
> 
> >   -0 [001] d.h.82.443398: irq_handler_entry: irq=16 
> > name=jcore_pit
> >   -0 [001] d.h.82.443573: hrtimer_cancel: 
> > hrtimer=109f449c
> >   -0 [001] d.h.82.443689: hrtimer_expire_entry: 
> > hrtimer=109f449c function=tick_sched_timer now=82356112320
> 
> Tick timer expires
> 
> >   -0 [001] d.h.82.443911: softirq_raise: vec=1 
> > [action=TIMER]
> >   -0 [001] d.h.82.444089: softirq_raise: vec=9 
> > [action=RCU]
> >   -0 [001] d.h.82.444306: softirq_raise: vec=7 
> > [action=SCHED]
> 
> Raises softirqs
> 
> >   -0 [001] d.h.82.48: hrtimer_expire_exit: 
> > hrtimer=109f449c
> >   -0 [001] d.h.82.444592: hrtimer_start: 
> > hrtimer=109f449c function=tick_sched_timer expires=8236000 
> > softexpires=8236000
> 
> Rearms the next period
> 
> >   -0 [001] d.h.82.444821: irq_handler_exit: irq=16 
> > ret=handled
> >   -0 [001] ..s.82.445034: softirq_entry: vec=1 
> > [action=TIMER]
> >   -0 [001] ..s.82.445222: softirq_exit: vec=1 
> > [action=TIMER]
> >   -0 [001] ..s.82.445341: softirq_entry: vec=7 
> > [action=SCHED]
> >   -0 [001] ..s.82.445745: softirq_exit: vec=7 
> > [action=SCHED]
> >   -0 [001] ..s.82.445880: softirq_entry: vec=9 
> > [action=RCU]
> >   -0 [001] ..s.82.446093: softirq_exit: vec=9 
> > [action=RCU]
> 
> Softirqs done and the machine vanishes into lala land 
> 
> And now after that gap we have a cancel/start on CPU 0
> 
> >   -0 [000] dn..   109.852709: hrtimer_cancel: 
> > hrtimer=109e949c
> >   -0 [000] dn..   109.853043: hrtimer_start: 
> > hrtimer=109e949c function=tick_sched_timer expires=10977000 
> > softexpires=10977000
> 
> >   sh-388   [000] d.h.   109.855851: irq_handler_entry: irq=18 
> > name=uartlite
> >   sh-388   [000] d.h.   109.856751: irq_handler_exit: irq=18 
> > ret=handled
> >   sh-388   [000] d.h.   109.857264: irq_handler_entry: irq=18 
> > name=uartlite
> >   sh-388   [000] d.h.   109.857458: irq_handler_exit: irq=18 
> > ret=unhandled
> >   -0 [001] d.h.   109.857684: irq_handler_entry: irq=16 
> > name=jcore_pit
> >   -0 [001] d.h.   109.857934: hrtimer_cancel: 
> > hrtimer=109f449c
> >   -0 [001] d.h.   109.858087: hrtimer_expire_entry: 
> > hrtimer=109f449c function=tick_sched_timer now=109770452820
> 
> And this expiry happens on CPU 1, but the expiry time looks like the one
> which got armed on CPU 0 above !?!?!
> 
> >   -0 [001] d.h.   109.858639: softirq_raise: vec=1 
> > [action=TIMER]
> >   -0 [001] d.h.   109.858839: softirq_raise: vec=9 
> > [action=RCU]
> >   -0 [001] d.h.   109.859097: softirq_raise: vec=7 
> > [action=SCHED]
> >   -0 [001] d.h.   109.859282: hrtimer_expire_exit: 
> > hrtimer=109f449c
> >   -0 [001] d.h.   109.859428: hrtimer_start: 
> > hrtimer=109f449c function=tick_sched_timer expires=10978000 
> > softexpires=10978000
> >   -0 [001] d.h.   109.859637: irq_handler_exit: irq=16 
> > ret=handled
> >   -0 [001] ..s.   109.859806: softirq_entry: vec=1 
> > [action=TIMER]
> >   -0 [001] ..s.   109.859984: softirq_exit: vec=1 
> > [action=TIMER]
> >   -0 [001] ..s.   109.860098: softirq_entry: vec=7 
> > [action=SCHED]
> >   -0 [001] ..s.   109.860533: softirq_exit: vec=7 
> > [action=SCHED]
> >   -0 [001] ..s.   109.860663: softirq_entry: vec=9 
> > [action=RCU]
> >   -0 [001] .ns.   109.861424: softirq_exit: vec=9 
> > [action=RCU]
> >   sh-388   [000] d.h.   109.861831: irq_handler_entry: irq=16 
> > name=jcore_pit
> >   sh-388   [000] d.h.   109.862071: hrtimer_cancel: 
> > hrtimer=109e949c
> >rcu_sched-7 [001]    109.862141: timer_init: timer=160a9eb0
> >   sh-388   [000] d.h.   109.862233: hrtimer_expire_entry: 
> > hrtimer=109e949c function=tick_sched_timer now=109774586740
> 
> And CPU0 has it's timer firing 4.5ms late .
> 
> >rcu_sched-7 [001] d...   109.862317: timer_start: timer=160a9eb0 
> > function=process_timeout expires=4294948275 [timeout=1] flags=0x0001
> > 
> > However no stall message appeared on the console here, and I suspect
> > it might have just been a gap in event recording because it doesn't
> > look terribly 

[GIT PULL] blk-mq irq/cpu mapping updates

[Jens Axboe]

Hi Linus,

This is the block-irq topic branch for 4.9-rc. It's mostly from
Christoph, and it allows drivers to specify their own mappings, and more
importantly, to share the blk-mq mappings with the IRQ affinity
mappings. It's a good step towards making this work better out of the
box.

This will throw a few merge conflicts with later patches in the main
branch that you already pulled. I kept this a private branch due to the
pci dependencies. I have attached the diff of how I resolved it, just in
case.

Please pull!


  git://git.kernel.dk/linux-block.git for-4.9/block-irq



Christoph Hellwig (8):
  blk-mq: don't redistribute hardware queues on a CPU hotplug event
  blk-mq: only allocate a single mq_map per tag_set
  blk-mq: remove ->map_queue
  blk-mq: allow the driver to pass in a queue mapping
  blk-mq: provide a default queue mapping for PCI device
  nvme: switch to use pci_alloc_irq_vectors
  nvme: remove the post_scan callout
  blk-mq: get rid of the cpumask in struct blk_mq_tags

Jens Axboe (2):
  Merge branch 'irq/for-block' of git://git.kernel.org/.../tip/tip 
into for-4.9/msi-irq

  blk-mq: kill unused blk_mq_create_mq_map()

Stephen Rothwell (1):
  blk_mq: linux/blk-mq.h does not include all the headers it depends on

 Documentation/block/biodoc.txt|   4 +-
 block/Kconfig |   5 +
 block/Makefile|   2 +-
 block/bio.c   |   2 +-
 block/blk-core.c  |  16 +-
 block/blk-flush.c |   6 +-
 block/blk-mq-cpumap.c |  25 +--
 block/blk-mq-pci.c|  47 +
 block/blk-mq-sysfs.c  |  15 +-
 block/blk-mq-tag.c|  11 +-
 block/blk-mq-tag.h|   1 -
 block/blk-mq.c| 117 +--
 block/blk-mq.h|  10 +-
 block/blk.h   |  11 +-
 drivers/block/loop.c  |   1 -
 drivers/block/mtip32xx/mtip32xx.c |   3 +-
 drivers/block/nbd.c   | 411 
+++---

 drivers/block/null_blk.c  |   1 -
 drivers/block/rbd.c   |   1 -
 drivers/block/virtio_blk.c|   1 -
 drivers/block/xen-blkfront.c  |   1 -
 drivers/md/dm-crypt.c |   2 +-
 drivers/md/dm-rq.c|   1 -
 drivers/mtd/ubi/block.c   |   1 -
 drivers/nvme/host/core.c  |   3 -
 drivers/nvme/host/nvme.h  |   1 -
 drivers/nvme/host/pci.c   | 109 --
 drivers/nvme/host/rdma.c  |   2 -
 drivers/nvme/target/loop.c|   2 -
 drivers/scsi/scsi_lib.c   |   1 -
 fs/befs/linuxvfs.c|   2 +-
 fs/block_dev.c|  11 +-
 fs/btrfs/inode.c  |   5 +-
 include/linux/bio.h   |   2 -
 include/linux/blk-mq-pci.h|   9 +
 include/linux/blk-mq.h|  26 ++-
 include/linux/blk_types.h |  21 +-
 include/linux/blkdev.h|   4 +-
 include/linux/ioprio.h|   1 -
 include/linux/workqueue.h |   1 +
 kernel/workqueue.c|  40 ++--
 41 files changed, 429 insertions(+), 506 deletions(-)
 create mode 100644 block/blk-mq-pci.c
 create mode 100644 include/linux/blk-mq-pci.h

--
Jens Axboe

diff --cc block/blk-mq-tag.c
index cef618f6fc92,2eae3d5f7145..
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@@ -412,9 -673,8 +406,8 @@@ struct blk_mq_tags *blk_mq_init_tags(un
  
  void blk_mq_free_tags(struct blk_mq_tags *tags)
  {
 -	bt_free(>bitmap_tags);
 -	bt_free(>breserved_tags);
 +	sbitmap_queue_free(>bitmap_tags);
 +	sbitmap_queue_free(>breserved_tags);
- 	free_cpumask_var(tags->cpumask);
  	kfree(tags);
  }
  
diff --cc block/blk-mq-tag.h
index 09f4cc0aaa84,556964134d1c..
--- a/block/blk-mq-tag.h
+++ b/block/blk-mq-tag.h
@@@ -17,8 -42,8 +17,6 @@@ struct blk_mq_tags 
  
  	struct request **rqs;
  	struct list_head page_list;
--
- 	cpumask_var_t cpumask;
 -	int alloc_policy;
  };
  
  
diff --cc block/blk-mq.c
index dc5f47f60931,f1c5263c44e8..
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@@ -224,11 -245,21 +224,11 @@@ struct request *blk_mq_alloc_request(st
  		return ERR_PTR(ret);
  
  	ctx = blk_mq_get_ctx(q);
- 	hctx = q->mq_ops->map_queue(q, ctx->cpu);
+ 	hctx = blk_mq_map_queue(q, ctx->cpu);
  	blk_mq_set_alloc_data(_data, q, flags, ctx, hctx);
 -
  	rq = __blk_mq_alloc_request(_data, rw, 0);
 -	if (!rq && !(flags & BLK_MQ_REQ_NOWAIT)) {
 -		__blk_mq_run_hw_queue(hctx);
 -		blk_mq_put_ctx(ctx);
 -
 -		ctx = blk_mq_get_ctx(q);
 -		hctx = blk_mq_map_queue(q, ctx->cpu);
 -		blk_mq_set_alloc_data(_data, q, flags, ctx, hctx);
 -		rq =  __blk_mq_alloc_request(_data, rw, 0);
 -		ctx = alloc_data.ctx;
 -	}
  	blk_mq_put_ctx(ctx);
 +
  	if (!rq) {
  		blk_queue_exit(q);
  		return ERR_PTR(-EWOULDBLOCK);

Re: [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER

[Masahiro Yamada]

2016-09-20 16:30 GMT+09:00 Philipp Zabel :
> Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
>> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
>> merged.  Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
>>
>> Signed-off-by: Masahiro Yamada 
>
> Acked-by: Philipp Zabel 
>
> regards
> Philipp


Applied.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 00/10] Introduce Juniper PTXPMB CPLD driver

[Frank Rowand]

On 10/07/16 16:39, Frank Rowand wrote:
> On 10/07/16 08:17, Pantelis Antoniou wrote:
>> Add Juniper's PTXPMB FPGA CPLD driver. Those FPGAs
>> are present in Juniper's PTX series of routers.
>>
>> The MFD driver provices watchdog/i2c/gpio/mtd devices.
>>
>> There are full device tree binding documents for the
>> master mfd driver and for all slave drivers.
>>
>> This patchset is against mainline as of today: v4.8-9431-g3477d16
>> and is dependent on the "Juniper prerequisites" and
>> "Juniper infrastructure" patchsets sent earlier.
> 
> Pointers to the patchsets please.
> 

Nevermind.  Found them.

-Frank

Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC

[Shawn Lin]

在 2016/10/7 23:22, Gregory CLEMENT 写道:

From: Ziji Hu 

Marvell Xenon eMMC/SD/SDIO Host Controller contains PHY.
Three types of PHYs are supported.

Add support to multiple types of PHYs init and configuration.
Add register definitions of PHYs.

Signed-off-by: Hu Ziji 
Reviewed-by: Gregory CLEMENT 
Signed-off-by: Gregory CLEMENT 
---
 MAINTAINERS|1 +-
 drivers/mmc/host/Makefile  |2 +-
 drivers/mmc/host/sdhci-xenon-phy.c | 1141 +-
 drivers/mmc/host/sdhci-xenon-phy.h |  157 -
 drivers/mmc/host/sdhci-xenon.c |4 +-
 drivers/mmc/host/sdhci-xenon.h |   17 +-
 6 files changed, 1321 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mmc/host/sdhci-xenon-phy.c
 create mode 100644 drivers/mmc/host/sdhci-xenon-phy.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 859420e5dfd3..b5673c2ee5f2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7583,6 +7583,7 @@ M:Ziji Hu 
 L: linux-...@vger.kernel.org
 S: Supported
 F: drivers/mmc/host/sdhci-xenon.*
+F: drivers/mmc/host/sdhci-xenon-phy.*


drivers/mmc/host/sdhci-xenon* shoube enough


 F: Documentation/devicetree/bindings/mmc/marvell,sdhci-xenon.txt

 MATROX FRAMEBUFFER DRIVER
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 75eaf743486c..4f2854556ff7 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -82,4 +82,4 @@ ifeq ($(CONFIG_CB710_DEBUG),y)
 endif

 obj-$(CONFIG_MMC_SDHCI_XENON)  += sdhci-xenon-driver.o
-sdhci-xenon-driver-y   += sdhci-xenon.o
+sdhci-xenon-driver-y   += sdhci-xenon.o sdhci-xenon-phy.o
diff --git a/drivers/mmc/host/sdhci-xenon-phy.c 
b/drivers/mmc/host/sdhci-xenon-phy.c
new file mode 100644
index ..4eb8fea1bec9
--- /dev/null
+++ b/drivers/mmc/host/sdhci-xenon-phy.c


Well, it's legit to use phy API and move your phy
operations to PHY subsystem. :)


@@ -0,0 +1,1141 @@
+/*
+ * PHY support for Xenon SDHC
+ *
+ * Copyright (C) 2016 Marvell, All Rights Reserved.
+ *
+ * Author: Hu Ziji 
+ * Date:   2016-8-24
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sdhci.h"
+#include "sdhci-pltfm.h"
+#include "sdhci-xenon.h"
+
+static const char * const phy_types[] = {
+   "sdh phy",
+   "emmc 5.0 phy",
+   "emmc 5.1 phy"
+};
+
+enum phy_type_enum {
+   SDH_PHY,
+   EMMC_5_0_PHY,
+   EMMC_5_1_PHY,
+   NR_PHY_TYPES
+};
+
+struct soc_pad_ctrl_table {
+   const char *soc;
+   void (*set_soc_pad)(struct sdhci_host *host,
+   unsigned char signal_voltage);
+};
+
+struct soc_pad_ctrl {
+   /* Register address of SOC PHY PAD ctrl */
+   void __iomem*reg;
+   /* SOC PHY PAD ctrl type */
+   enum soc_pad_ctrl_type pad_type;
+   /* SOC specific operation to set SOC PHY PAD */
+   void (*set_soc_pad)(struct sdhci_host *host,
+   unsigned char signal_voltage);
+};
+
+static struct xenon_emmc_phy_regs  xenon_emmc_5_0_phy_regs = {
+   .timing_adj = EMMC_5_0_PHY_TIMING_ADJUST,
+   .func_ctrl  = EMMC_5_0_PHY_FUNC_CONTROL,
+   .pad_ctrl   = EMMC_5_0_PHY_PAD_CONTROL,
+   .pad_ctrl2  = EMMC_5_0_PHY_PAD_CONTROL2,
+   .dll_ctrl   = EMMC_5_0_PHY_DLL_CONTROL,
+   .logic_timing_adj = EMMC_5_0_PHY_LOGIC_TIMING_ADJUST,
+   .delay_mask = EMMC_5_0_PHY_FIXED_DELAY_MASK,
+   .dll_update = DLL_UPDATE_STROBE_5_0,
+};
+
+static struct xenon_emmc_phy_regs  xenon_emmc_5_1_phy_regs = {
+   .timing_adj = EMMC_PHY_TIMING_ADJUST,
+   .func_ctrl  = EMMC_PHY_FUNC_CONTROL,
+   .pad_ctrl   = EMMC_PHY_PAD_CONTROL,
+   .pad_ctrl2  = EMMC_PHY_PAD_CONTROL2,
+   .dll_ctrl   = EMMC_PHY_DLL_CONTROL,
+   .logic_timing_adj = EMMC_PHY_LOGIC_TIMING_ADJUST,
+   .delay_mask = EMMC_PHY_FIXED_DELAY_MASK,
+   .dll_update = DLL_UPDATE,
+};
+
+static int xenon_delay_adj_test(struct mmc_card *card);
+
+/*
+ * eMMC PHY configuration and operations
+ */
+struct emmc_phy_params {
+   boolslow_mode;
+
+   u8  znr;
+   u8  zpr;
+
+   /* Nr of consecutive Sampling Points of a Valid Sampling Window */
+   u8  nr_tun_times;
+   /* Divider for calculating Tuning Step */
+   u8  tun_step_divider;
+
+   struct soc_pad_ctrl pad_ctrl;
+};
+
+static void xenon_emmc_phy_strobe_delay_adj(struct sdhci_host *host,
+   struct mmc_card *card);
+static int xenon_emmc_phy_fix_sampl_delay_adj(struct sdhci_host *host,
+   

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Leo Li]

On Thu, Sep 22, 2016 at 12:02 AM, Sriram Dash  wrote:
>>From: Arnd Bergmann [mailto:a...@arndb.de]
>>On Wednesday, September 21, 2016 11:43:59 AM CEST Sriram Dash wrote:
>>> >From: Arnd Bergmann [mailto:a...@arndb.de] On Wednesday, September
>>> >21, 2016 11:06:47 AM CEST Sriram Dash wrote:
>>>
>>> ==
>>> From 8b0dea1513e9e73a11dcfa802ddc71cca11d66f8 Mon Sep 17 00:00:00 2001
>>> From: Sriram Dash 
>>> Date: Wed, 21 Sep 2016 11:39:30 +0530
>>> Subject: [PATCH] usb: xhci: Fix the patch inherit dma configuration
>>> from  parent dev
>>>
>>> Fixes the patch https://patchwork.kernel.org/patch/9319527/
>>> ("usb: dwc3: host: inherit dma configuration from parent dev").
>>>
>>> Signed-off-by: Sriram Dash 
>>> ---
>>>  drivers/usb/host/xhci-mem.c | 12 ++--
>>>  drivers/usb/host/xhci.c | 20 ++--
>>>  2 files changed, 16 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
>>> index 6afe323..79608df 100644
>>> --- a/drivers/usb/host/xhci-mem.c
>>> +++ b/drivers/usb/host/xhci-mem.c
>>
>>All the changes you did to this file seem fine, I completely missed that part.
>>
>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index
>>> 01d96c9..9a1ff09 100644
>>> --- a/drivers/usb/host/xhci.c
>>> +++ b/drivers/usb/host/xhci.c
>
> Yes. Some sanity is required over this patch.

Hi Sriram,

Have you been able to do the sanity check on the patch?  I will be
good to have the formal patch submitted for integration as soon as
possible because the dwc3 USB functionality has been broken for a
while in upstream kernel.

Regards,
Leo

v4.8 cpufreq regression?

[Aaro Koskinen]

Hi,

I'm upgrading from v4.7 to v4.8 on MIPS/loongson2_cpufreq with
cpufreq/ondemand and I noticed that /proc/cpuinfo is always reporting
(regardless of system load):

BogoMIPS: 697150.20

and sysfs:

/sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq:797800
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:797800
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:199450
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:0
/sys/devices/system/cpu/cpufreq/policy0/related_cpus:0
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:199450 
299175 398900 498625 598350 698075 797800 
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:ondemand 
performance 
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:797800
/sys/devices/system/cpu/cpufreq/policy0/scaling_driver:loongson2
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:797800
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:199450
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:

although previously they reported (when idle):

BogoMIPS: 132.09

/sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq:199445
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:797780
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:199445
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:0
/sys/devices/system/cpu/cpufreq/policy0/related_cpus:0
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:199445 
299167 398890 498612 598335 698057 797780 
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:ondemand 
performance 
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:199445
/sys/devices/system/cpu/cpufreq/policy0/scaling_driver:loongson2
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:797780
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:199445
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:

and under full load:

BogoMIPS: 528.38

/sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq:797780
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:797780
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:199445
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:0
/sys/devices/system/cpu/cpufreq/policy0/related_cpus:0
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:199445 
299167 398890 498612 598335 698057 797780 
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:ondemand 
performance 
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:797780
/sys/devices/system/cpu/cpufreq/policy0/scaling_driver:loongson2
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:797780
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:199445
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:

The offeding commit (bisected) seems to be:

commit da0c6dc00c69d0adaae99c3b3d2ea0c869a3fb35
Author: Viresh Kumar 
Date:   Mon Jun 27 16:04:07 2016 +0530

cpufreq: Handle sorted frequency tables more efficiently

Any ideas?

A.

[RESEND PATCH v2 0/3] Broadcom AVS CPUfreq driver

[Markus Mayer]

This series contains the CPUfreq driver for Broadcom SoCs that use "AVS
Firmware" for voltage and frequency scaling. All voltage and frequency
transitions are performed by the firmware and are therefore hidden from
Linux.

The driver provides a standard CPUfreq interface to other kernel
components and to userland on the one hand and communicates with the
AVS co-processor on the other.

Communication between the two processors is via shared mailbox
registers and interrupts (ARM -> AVS to tell the firmware that there is
a command to process and AVS -> ARM to tell the driver that a command
finished executing).

lkml.org seems to be down for me. Here are patchwork links to the original
series:

https://patchwork.kernel.org/patch/9278119/
https://patchwork.kernel.org/patch/9278121/
https://patchwork.kernel.org/patch/9278127/

Changes from v1:
- renamed binding document 
- rewrote the introduction of the binding document
- created a new driver documentation file that contains Linux specific
  information that was previously part of the binding document
- renamed the driver (and related config options) to include a reference
  to "STB", since this implementation is primarily intended for use on
  set-top boxes
- improved comments
- updated function __map_region()
- updated struct private_data
- added code to unmap memory regions in the error and exit paths
- added new sysfs property to report frequency directly from the
  co-processor register

Markus Mayer (3):
  dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq
  cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs
  cpufreq: brcmstb-avs-cpufreq: add debugfs support

 Documentation/cpu-freq/brcmstb-avs-cpufreq.txt |   27 +
 .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt |   77 ++
 MAINTAINERS|9 +
 drivers/cpufreq/Kconfig.arm|   10 +
 drivers/cpufreq/Makefile   |1 +
 drivers/cpufreq/brcmstb-avs-cpufreq.c  | 1026 
 6 files changed, 1150 insertions(+)
 create mode 100644 Documentation/cpu-freq/brcmstb-avs-cpufreq.txt
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
 create mode 100644 drivers/cpufreq/brcmstb-avs-cpufreq.c

-- 
2.7.4

Re: fs: WARNING in locks_unlink_lock_ctx (not holding proper lock)

[Jeff Layton]

On Fri, 2016-10-07 at 22:03 +0200, Dmitry Vyukov wrote:
> Hello,
> 
> I am hitting lots of the following warnings while running syzkaller
> fuzzer. Seems that path does not hold proper lock.
> 
> WARNING: CPU: 1 PID: 12090 at fs/locks.c:610 locks_unlink_lock_ctx+0x2c7/0x370
> CPU: 1 PID: 12090 Comm: syz-executor Not tainted 4.8.0+ #28
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  880038ba7728 82d2b849 0016 fbfff10971e8
>  86e8c000 880038ba7800 86f42400 dc00
>  0009 880038ba77f0 816a229a 41b58ab3
> Call Trace:
>  [< inline >] __dump_stack lib/dump_stack.c:15
>  [] dump_stack+0x12e/0x185 lib/dump_stack.c:51
>  [] panic+0x1e9/0x3f4 kernel/panic.c:153
>  [] __warn+0x1c9/0x1e0 kernel/panic.c:509
>  [] warn_slowpath_null+0x31/0x40 kernel/panic.c:552
>  [< inline >] locks_delete_global_locks fs/locks.c:610
>  [] locks_unlink_lock_ctx+0x2c7/0x370 fs/locks.c:739
>  [] locks_delete_lock_ctx+0x1f/0x80 fs/locks.c:751
>  [] lease_modify+0x229/0x2e0 fs/locks.c:1370
>  [< inline >] locks_remove_lease fs/locks.c:2528
>  [] locks_remove_file+0x2d8/0x380 fs/locks.c:2551
>  [] __fput+0x1a6/0x780 fs/file_table.c:200
>  [] fput+0x1a/0x20 fs/file_table.c:244
>  [] task_work_run+0xf8/0x170 kernel/task_work.c:116
>  [< inline >] exit_task_work include/linux/task_work.h:21
>  [] do_exit+0x864/0x2ad0 kernel/exit.c:828
>  [] do_group_exit+0x10d/0x330 kernel/exit.c:931
>  [] get_signal+0x62f/0x15e0 kernel/signal.c:2307
>  [] do_signal+0x84/0x18f0 arch/x86/kernel/signal.c:807
>  [] exit_to_usermode_loop+0x13b/0x200
> arch/x86/entry/common.c:156
>  [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
>  [< inline >] syscall_return_slowpath arch/x86/entry/common.c:259
>  [] do_syscall_64+0x49f/0x620 arch/x86/entry/common.c:285
> 
> On commit a6930aaee06755d1bdcfd943fbf614e4d92bb0c7 (Oct 5).

(cc'ing Peter...)

Well spotted. Yeah, I think you're right. The assertion is this:

    percpu_rwsem_assert_held(_rwsem);

I'm guessing this is probably fallout from the lglock to rwsem
conversion (commit aba376607383).

>From a quick glance, I think we probably just need to down_read the
file_rwsem in locks_remove_lease, prior to taking the flc_lock, and
release it just afterward. I do want to go over the code a little more
closely though to make sure other codepaths aren't missing that lock
though.

Thanks,
-- 
Jeff Layton 

Re: [PATCH v2 2/3] KVM: VMX: join functions that disable x2apic msr intercepts

[Wanpeng Li]

2016-10-07 20:30 GMT+08:00 Radim Krčmář :
> 2016-09-30 10:29+0200, Paolo Bonzini:
>> On 29/09/2016 22:41, Radim Krčmář wrote:
>>>  for (msr = 0x800; msr <= 0x8ff; msr++) {
>>>  if (msr == 0x839 /* TMCCT */)
>>>  continue;
>>> -vmx_disable_intercept_msr_read_x2apic(msr, true);
>>> +vmx_disable_intercept_msr_x2apic(msr, MSR_TYPE_R, true);
>>>  }
>>>
>>>  /* TPR */
>>> -vmx_disable_intercept_msr_write_x2apic(0x808, true);
>>> +vmx_disable_intercept_msr_x2apic(0x808, MSR_TYPE_W, true);
>>>  /* EOI */
>>> -vmx_disable_intercept_msr_write_x2apic(0x80b, true);
>>> +vmx_disable_intercept_msr_x2apic(0x80b, MSR_TYPE_W, true);
>>>  /* SELF-IPI */
>>> -vmx_disable_intercept_msr_write_x2apic(0x83f, true);
>>> +vmx_disable_intercept_msr_x2apic(0x83f, MSR_TYPE_W, true);
>>>
>>>  /*
>>>   * (enable_apicv && !kvm_vcpu_apicv_active()) ||
>>>   *  !enable_apicv
>>>   */
>>>  /* TPR */
>>> -vmx_disable_intercept_msr_read_x2apic(0x808, false);
>>> -vmx_disable_intercept_msr_write_x2apic(0x808, false);
>>> +vmx_disable_intercept_msr_x2apic(0x808, MSR_TYPE_R | MSR_TYPE_W, 
>>> false);
>>
>> Alternatively you could place the two function calls for 0x808 together:
>>
>>   for (msr = 0x800; msr <= 0x8ff; msr++)
>>   vmx_disable_intercept_msr_x2apic(msr, MSR_TYPE_R, true);
>>
>>   /*
>>* TPR reads and writes can be virtualized even if virtual interrupt 
>> delivery
>>  * is not in use.
>>*/
>>   vmx_disable_intercept_msr_x2apic(0x808, MSR_TYPE_R | MSR_TYPE_W, 
>> false);
>>   vmx_disable_intercept_msr_x2apic(0x808, MSR_TYPE_W, true);
>>
>>   /* EOI */
>>   vmx_disable_intercept_msr_x2apic(0x80b, MSR_TYPE_W, true);
>>
>>   /* SELF-IPI */
>>   vmx_disable_intercept_msr_x2apic(0x83f, MSR_TYPE_W, true);
>
> I have performed this change, thanks, and applied to kvm/queue;
> please check the complete patch below:
> ---8<---
> vmx_disable_intercept_msr_read_x2apic() and
> vmx_disable_intercept_msr_write_x2apic() differed only in the type.
> Pass the type to a new function.
>
> [Ordered and commented TPR intercept according to Paolo's suggestion.]

Looks good to me. :)

Regards,
Wanpeng Li

> Signed-off-by: Radim Krčmář 
> ---
>  arch/x86/kvm/vmx.c | 51 +++
>  1 file changed, 15 insertions(+), 36 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 8c83268f6f4c..69ff1be3db7b 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -4656,33 +4656,18 @@ static void vmx_disable_intercept_for_msr(u32 msr, 
> bool longmode_only)
> msr, MSR_TYPE_R | MSR_TYPE_W);
>  }
>
> -static void vmx_disable_intercept_msr_read_x2apic(u32 msr, bool apicv_active)
> +static void vmx_disable_intercept_msr_x2apic(u32 msr, int type, bool 
> apicv_active)
>  {
> if (apicv_active) {
> 
> __vmx_disable_intercept_for_msr(vmx_msr_bitmap_legacy_x2apic_apicv,
> -   msr, MSR_TYPE_R);
> +   msr, type);
> 
> __vmx_disable_intercept_for_msr(vmx_msr_bitmap_longmode_x2apic_apicv,
> -   msr, MSR_TYPE_R);
> +   msr, type);
> } else {
> __vmx_disable_intercept_for_msr(vmx_msr_bitmap_legacy_x2apic,
> -   msr, MSR_TYPE_R);
> +   msr, type);
> 
> __vmx_disable_intercept_for_msr(vmx_msr_bitmap_longmode_x2apic,
> -   msr, MSR_TYPE_R);
> -   }
> -}
> -
> -static void vmx_disable_intercept_msr_write_x2apic(u32 msr, bool 
> apicv_active)
> -{
> -   if (apicv_active) {
> -   
> __vmx_disable_intercept_for_msr(vmx_msr_bitmap_legacy_x2apic_apicv,
> -   msr, MSR_TYPE_W);
> -   
> __vmx_disable_intercept_for_msr(vmx_msr_bitmap_longmode_x2apic_apicv,
> -   msr, MSR_TYPE_W);
> -   } else {
> -   __vmx_disable_intercept_for_msr(vmx_msr_bitmap_legacy_x2apic,
> -   msr, MSR_TYPE_W);
> -   
> __vmx_disable_intercept_for_msr(vmx_msr_bitmap_longmode_x2apic,
> -   msr, MSR_TYPE_W);
> +   msr, type);
> }
>  }
>
> @@ -6463,29 +6448,23 @@ static __init int hardware_setup(void)
>
> set_bit(0, vmx_vpid_bitmap); /* 0 is reserved for host */
>
> -   /*
> -* enable_apicv && kvm_vcpu_apicv_active()
> -*/
> for (msr = 0x800; msr <= 0x8ff; msr++) {
> if (msr == 0x839 /* TMCCT */)
> continue;
> -   vmx_disable_intercept_msr_read_x2apic(msr, true);
> +   

[RFC PATCH 19/18] x86/intel_rdt: Add support for L2 cache allocation

[Luck, Tony]

Just in case you think that part 0010 is a bit complex setting
up all that infrastructure for just the L3 cache and using
for_each_rdt_resource() all over the place to loop over just one
thing. Here's the payoff.

Untested because I don't have a machine handy that supports L2 ... but this
should be all that needs to change for L2 cache allocation (both as an
alternate to L3, or in combination with L3).

Next feature after L2 is not a cache - so rdt_resource will have to grow
some new flags, or perhaps some "->resource_ops()" functions to handle
the pieces that work a bit differently, but the fundamentals should still
apply.

Not-signed-off-yet: Tony Luck
---
 arch/x86/include/asm/intel_rdt.h |  2 ++
 arch/x86/kernel/cpu/intel_rdt.c  | 23 +++
 2 files changed, 25 insertions(+)

diff --git a/arch/x86/include/asm/intel_rdt.h b/arch/x86/include/asm/intel_rdt.h
index aefa3a655408..641d32db9d74 100644
--- a/arch/x86/include/asm/intel_rdt.h
+++ b/arch/x86/include/asm/intel_rdt.h
@@ -97,6 +97,7 @@ struct rdt_resource {
 
 #define IA32_L3_QOS_CFG0xc81
 #define IA32_L3_CBM_BASE   0xc90
+#define IA32_L2_CBM_BASE   0xd10
 
 /**
  * struct rdt_domain - group of cpus sharing an RDT resource
@@ -134,6 +135,7 @@ extern struct rdt_resource rdt_resources_all[];
 
 enum {
RDT_RESOURCE_L3,
+   RDT_RESOURCE_L2,
 };
 
 /* Maximum CLOSID allowed across all enabled resoources */
diff --git a/arch/x86/kernel/cpu/intel_rdt.c b/arch/x86/kernel/cpu/intel_rdt.c
index 1afca46e080d..c457641c49b6 100644
--- a/arch/x86/kernel/cpu/intel_rdt.c
+++ b/arch/x86/kernel/cpu/intel_rdt.c
@@ -50,6 +50,13 @@ struct rdt_resource rdt_resources_all[] = {
.cache_level= 3
},
{
+   .name   = "L2",
+   .domains= domain_init(RDT_RESOURCE_L2),
+   .msr_base   = IA32_L2_CBM_BASE,
+   .min_cbm_bits   = 1,
+   .cache_level= 2
+   },
+   {
/* NULL terminated */
}
 };
@@ -122,6 +129,22 @@ static inline bool get_rdt_resources(struct cpuinfo_x86 *c)
 
ret = true;
}
+   if (cpu_has(c, X86_FEATURE_CAT_L2)) {
+   union cpuid_0x10_1_eax eax;
+   union cpuid_0x10_1_edx edx;
+   u32 ebx, ecx;
+
+   /* CPUID 0x10.2 fields are same format at 0x10.1 */
+   r = _resources_all[RDT_RESOURCE_L2];
+   cpuid_count(0x0010, 2, , , , );
+   r->max_closid = edx.split.cos_max + 1;
+   r->num_closid = r->max_closid;
+   r->cbm_len = eax.split.cbm_len + 1;
+   r->max_cbm = BIT_MASK(eax.split.cbm_len + 1) - 1;
+   r->enabled = true;
+
+   ret = true;
+   }
 
return ret;
 }
-- 
2.5.0

[PATCH 07/10] drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable

[Lyude]

There's not much of a reason this should have the locations to read out
the hardware state hardcoded, so allow the caller to specify the
location and add this function to intel_drv.h. As well, we're going to
need this function to be reusable for the next patch.

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c  | 27 +--
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 958dc72..73a2d16d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1756,6 +1756,8 @@ void ilk_wm_get_hw_state(struct drm_device *dev);
 void skl_wm_get_hw_state(struct drm_device *dev);
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */);
+void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
+ struct skl_pipe_wm *out);
 bool intel_can_enable_sagv(struct drm_atomic_state *state);
 int intel_enable_sagv(struct drm_i915_private *dev_priv);
 int intel_disable_sagv(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9e53ff7..27a520ce 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4287,15 +4287,13 @@ static inline void skl_wm_level_from_reg_val(uint32_t 
val,
PLANE_WM_LINES_MASK;
 }
 
-static void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc)
+void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
+ struct skl_pipe_wm *out)
 {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct skl_wm_values *hw = _priv->wm.skl_hw;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
struct intel_plane *intel_plane;
-   struct skl_pipe_wm *active = >wm.skl.optimal;
struct skl_plane_wm *wm;
enum pipe pipe = intel_crtc->pipe;
int level, id, max_level = ilk_wm_max_level(dev);
@@ -4303,7 +4301,7 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)
 
for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
id = skl_wm_plane_id(intel_plane);
-   wm = >wm.skl.optimal.planes[id];
+   wm = >planes[id];
 
for (level = 0; level <= max_level; level++) {
if (id != PLANE_CURSOR)
@@ -4325,20 +4323,29 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)
if (!intel_crtc->active)
return;
 
-   hw->dirty_pipes |= drm_crtc_mask(crtc);
-   active->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
-   intel_crtc->wm.active.skl = *active;
+   out->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
 }
 
 void skl_wm_get_hw_state(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct skl_wm_values *hw = _priv->wm.skl_hw;
struct skl_ddb_allocation *ddb = _priv->wm.skl_hw.ddb;
struct drm_crtc *crtc;
+   struct intel_crtc *intel_crtc;
+   struct intel_crtc_state *cstate;
 
skl_ddb_get_hw_state(dev_priv, ddb);
-   list_for_each_entry(crtc, >mode_config.crtc_list, head)
-   skl_pipe_wm_get_hw_state(crtc);
+   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
+   intel_crtc = to_intel_crtc(crtc);
+   cstate = to_intel_crtc_state(crtc->state);
+
+   skl_pipe_wm_get_hw_state(crtc, >wm.skl.optimal);
+   intel_crtc->wm.active.skl = cstate->wm.skl.optimal;
+
+   if (!intel_crtc->active)
+   hw->dirty_pipes |= drm_crtc_mask(crtc);
+   }
 
if (dev_priv->active_crtcs) {
/* Fully recompute DDB on first atomic commit */
-- 
2.7.4

[PATCH v2 06/10] drm/i915/gen9: Add ddb changes to atomic debug output

[Lyude]

Finally, add some debugging output for ddb changes in the atomic debug
output. This makes it a lot easier to spot bugs from incorrect ddb
allocations.

Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 57 +
 1 file changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5cb537c..9e53ff7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4040,6 +4040,61 @@ skl_copy_wm_for_pipe(struct skl_wm_values *dst,
   sizeof(dst->ddb.plane[pipe]));
 }
 
+static void
+skl_print_wm_changes(const struct drm_atomic_state *state)
+{
+   const struct drm_device *dev = state->dev;
+   const struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct intel_atomic_state *intel_state =
+   to_intel_atomic_state(state);
+   const struct drm_crtc *crtc;
+   const struct drm_crtc_state *cstate;
+   const struct drm_plane *plane;
+   const struct intel_plane *intel_plane;
+   const struct drm_plane_state *pstate;
+   const struct skl_ddb_allocation *old_ddb = _priv->wm.skl_hw.ddb;
+   const struct skl_ddb_allocation *new_ddb = _state->wm_results.ddb;
+   enum pipe pipe;
+   int id;
+   int i, j;
+
+   for_each_crtc_in_state(state, crtc, cstate, i) {
+   if (!crtc->state)
+   continue;
+
+   pipe = to_intel_crtc(crtc)->pipe;
+
+   for_each_plane_in_state(state, plane, pstate, j) {
+   const struct skl_ddb_entry *old, *new;
+
+   intel_plane = to_intel_plane(plane);
+   id = skl_wm_plane_id(intel_plane);
+   old = _ddb->plane[pipe][id];
+   new = _ddb->plane[pipe][id];
+
+   if (intel_plane->pipe != pipe)
+   continue;
+
+   if (skl_ddb_entry_equal(old, new))
+   continue;
+
+   if (id != PLANE_CURSOR) {
+   DRM_DEBUG_ATOMIC("[PLANE:%d:plane %d%c] ddb (%d 
- %d) -> (%d - %d)\n",
+plane->base.id, id + 1,
+pipe_name(pipe),
+old->start, old->end,
+new->start, new->end);
+   } else {
+   DRM_DEBUG_ATOMIC("[PLANE:%d:cursor %c] ddb (%d 
- %d) -> (%d - %d)\n",
+plane->base.id,
+pipe_name(pipe),
+old->start, old->end,
+new->start, new->end);
+   }
+   }
+   }
+}
+
 static int
 skl_compute_wm(struct drm_atomic_state *state)
 {
@@ -4101,6 +4156,8 @@ skl_compute_wm(struct drm_atomic_state *state)
intel_cstate->update_wm_pre = true;
}
 
+   skl_print_wm_changes(state);
+
return 0;
 }
 
-- 
2.7.4

[PATCH 08/10] drm/i915/gen9: Add skl_wm_level_equals()

[Lyude]

Helper we're going to be using for implementing verification of the wm
levels in skl_verify_wm_level().

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c  | 14 ++
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 73a2d16d..3e6e9af 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1761,6 +1761,8 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
 bool intel_can_enable_sagv(struct drm_atomic_state *state);
 int intel_enable_sagv(struct drm_i915_private *dev_priv);
 int intel_disable_sagv(struct drm_i915_private *dev_priv);
+bool skl_wm_level_equals(const struct skl_wm_level *l1,
+const struct skl_wm_level *l2);
 bool skl_ddb_allocation_equals(const struct skl_ddb_allocation *old,
   const struct skl_ddb_allocation *new,
   enum pipe pipe);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27a520ce..6af1587 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3853,6 +3853,20 @@ void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
>plane[pipe][PLANE_CURSOR]);
 }
 
+bool skl_wm_level_equals(const struct skl_wm_level *l1,
+const struct skl_wm_level *l2)
+{
+   if (l1->plane_en != l2->plane_en)
+   return false;
+
+   /* If both planes aren't enabled, the rest shouldn't matter */
+   if (!l1->plane_en)
+   return true;
+
+   return (l1->plane_res_l == l2->plane_res_l &&
+   l1->plane_res_b == l2->plane_res_b);
+}
+
 static inline bool skl_ddb_entries_overlap(const struct skl_ddb_entry *a,
   const struct skl_ddb_entry *b)
 {
-- 
2.7.4

[PATCH 09/10] drm/i915/gen9: Actually verify WM levels in verify_wm_state()

[Lyude]

Thanks to Paulo Zanoni for indirectly pointing this out.

Looks like we never actually added any code for checking whether or not
we actually wrote watermark levels properly. Let's fix that.

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_display.c | 100 +--
 1 file changed, 84 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 39400a0..2c682bc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13444,30 +13444,66 @@ static void verify_wm_state(struct drm_crtc *crtc,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct skl_ddb_allocation hw_ddb, *sw_ddb;
-   struct skl_ddb_entry *hw_entry, *sw_entry;
+   struct skl_pipe_wm hw_wm, *sw_wm;
+   struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
+   struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
const enum pipe pipe = intel_crtc->pipe;
-   int plane;
+   int plane, level, max_level = ilk_wm_max_level(dev);
 
if (INTEL_INFO(dev)->gen < 9 || !new_state->active)
return;
 
+   skl_pipe_wm_get_hw_state(crtc, _wm);
+   sw_wm = _crtc->wm.active.skl;
+
skl_ddb_get_hw_state(dev_priv, _ddb);
sw_ddb = _priv->wm.skl_hw.ddb;
 
/* planes */
for_each_plane(dev_priv, pipe, plane) {
-   hw_entry = _ddb.plane[pipe][plane];
-   sw_entry = _ddb->plane[pipe][plane];
+   hw_plane_wm = _wm.planes[plane];
+   sw_plane_wm = _wm->planes[plane];
 
-   if (skl_ddb_entry_equal(hw_entry, sw_entry))
-   continue;
+   /* Watermarks */
+   for (level = 0; level <= max_level; level++) {
+   if (skl_wm_level_equals(_plane_wm->wm[level],
+   _plane_wm->wm[level]))
+   continue;
+
+   DRM_ERROR("mismatch in WM pipe %c plane %d level %d 
(expected e=%d b=%d l=%d, got e=%d b=%d l=%d)\n",
+ pipe_name(pipe), plane + 1, level,
+ sw_plane_wm->wm[level].plane_en,
+ sw_plane_wm->wm[level].plane_res_b,
+ sw_plane_wm->wm[level].plane_res_l,
+ hw_plane_wm->wm[level].plane_en,
+ hw_plane_wm->wm[level].plane_res_b,
+ hw_plane_wm->wm[level].plane_res_l);
+   }
 
-   DRM_ERROR("mismatch in DDB state pipe %c plane %d "
- "(expected (%u,%u), found (%u,%u))\n",
- pipe_name(pipe), plane + 1,
- sw_entry->start, sw_entry->end,
- hw_entry->start, hw_entry->end);
+   if (!skl_wm_level_equals(_plane_wm->trans_wm,
+_plane_wm->trans_wm)) {
+   DRM_ERROR("mismatch in trans WM pipe %c plane %d 
(expected e=%d b=%d l=%d, got e=%d b=%d l=%d)\n",
+ pipe_name(pipe), plane + 1,
+ sw_plane_wm->trans_wm.plane_en,
+ sw_plane_wm->trans_wm.plane_res_b,
+ sw_plane_wm->trans_wm.plane_res_l,
+ hw_plane_wm->trans_wm.plane_en,
+ hw_plane_wm->trans_wm.plane_res_b,
+ hw_plane_wm->trans_wm.plane_res_l);
+   }
+
+   /* DDB */
+   hw_ddb_entry = _ddb.plane[pipe][plane];
+   sw_ddb_entry = _ddb->plane[pipe][plane];
+
+   if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
+   DRM_ERROR("mismatch in DDB state pipe %c plane %d "
+ "(expected (%u,%u), found (%u,%u))\n",
+ pipe_name(pipe), plane + 1,
+ sw_ddb_entry->start, sw_ddb_entry->end,
+ hw_ddb_entry->start, hw_ddb_entry->end);
+   }
}
 
/*
@@ -13477,15 +13513,47 @@ static void verify_wm_state(struct drm_crtc *crtc,
 * once the plane becomes visible, we can skip this check
 */
if (intel_crtc->cursor_addr) {
-   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
-   sw_entry = _ddb->plane[pipe][PLANE_CURSOR];
+   hw_plane_wm = _wm.planes[PLANE_CURSOR];
+   sw_plane_wm = _wm->planes[PLANE_CURSOR];
+
+  

[PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

[Lyude]

Now that we've make skl_wm_levels make a little more sense, we can
remove all of the redundant wm information. Up until now we'd been
storing two copies of all of the skl watermarks: one being the
skl_pipe_wm structs, the other being the global wm struct in
drm_i915_private containing the raw register values. This is confusing
and problematic, since it means we're prone to accidentally letting the
two copies go out of sync. So, get rid of all of the functions
responsible for computing the register values and just use a single
helper, skl_write_wm_level(), to convert and write the new watermarks on
the fly.

Changes since v1:
- Fixup skl_write_wm_level()
- Fixup skl_wm_level_from_reg_val()
- Don't forget to copy *active to intel_crtc->wm.active.skl

Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |   2 -
 drivers/gpu/drm/i915/intel_display.c |  14 ++-
 drivers/gpu/drm/i915/intel_drv.h |   6 +-
 drivers/gpu/drm/i915/intel_pm.c  | 204 ---
 drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
 5 files changed, 90 insertions(+), 144 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0287c93..76583b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1644,8 +1644,6 @@ struct skl_ddb_allocation {
 struct skl_wm_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
-   uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
-   uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
 };
 
 struct skl_wm_level {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a71d05a..39400a0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3378,6 +3378,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
const struct skl_wm_values *wm = _priv->wm.skl_results;
+   const struct skl_plane_wm *p_wm =
+   _state->wm.skl.optimal.planes[0];
int pipe = intel_crtc->pipe;
u32 plane_ctl;
unsigned int rotation = plane_state->base.rotation;
@@ -3414,7 +3416,7 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
intel_crtc->adjusted_y = src_y;
 
if (wm->dirty_pipes & drm_crtc_mask(_crtc->base))
-   skl_write_plane_wm(intel_crtc, wm, 0);
+   skl_write_plane_wm(intel_crtc, p_wm, >ddb, 0);
 
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
@@ -3448,6 +3450,8 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
+   const struct skl_plane_wm *p_wm = >wm.skl.optimal.planes[0];
int pipe = intel_crtc->pipe;
 
/*
@@ -3455,7 +3459,8 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
 * plane's visiblity isn't actually changing neither is its watermarks.
 */
if (!crtc->primary->state->visible)
-   skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
+   skl_write_plane_wm(intel_crtc, p_wm,
+  _priv->wm.skl_results.ddb, 0);
 
I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
@@ -10819,12 +10824,15 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
const struct skl_wm_values *wm = _priv->wm.skl_results;
+   const struct skl_plane_wm *p_wm =
+   >wm.skl.optimal.planes[PLANE_CURSOR];
int pipe = intel_crtc->pipe;
uint32_t cntl = 0;
 
if (INTEL_GEN(dev_priv) >= 9 && wm->dirty_pipes & drm_crtc_mask(crtc))
-   skl_write_cursor_wm(intel_crtc, wm);
+   skl_write_cursor_wm(intel_crtc, p_wm, >ddb);
 
if (plane_state && plane_state->base.visible) {
cntl = MCURSOR_GAMMA_ENABLE;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d684f4f..958dc72 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1765,9 +1765,11 @@ bool skl_ddb_allocation_equals(const struct 
skl_ddb_allocation *old,
 

[PATCH 10/10] drm/i915/gen9: Don't wrap strings in verify_wm_state()

[Lyude]

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_display.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2c682bc..6191baf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13498,8 +13498,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
sw_ddb_entry = _ddb->plane[pipe][plane];
 
if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
-   DRM_ERROR("mismatch in DDB state pipe %c plane %d "
- "(expected (%u,%u), found (%u,%u))\n",
+   DRM_ERROR("mismatch in DDB state pipe %c plane %d 
(expected (%u,%u), found (%u,%u))\n",
  pipe_name(pipe), plane + 1,
  sw_ddb_entry->start, sw_ddb_entry->end,
  hw_ddb_entry->start, hw_ddb_entry->end);
@@ -13549,8 +13548,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
sw_ddb_entry = _ddb->plane[pipe][PLANE_CURSOR];
 
if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
-   DRM_ERROR("mismatch in DDB state pipe %c cursor "
- "(expected (%u,%u), found (%u,%u))\n",
+   DRM_ERROR("mismatch in DDB state pipe %c cursor 
(expected (%u,%u), found (%u,%u))\n",
  pipe_name(pipe),
  sw_ddb_entry->start, sw_ddb_entry->end,
  hw_ddb_entry->start, hw_ddb_entry->end);
-- 
2.7.4

Re: [PATCH V1 04/10] watchdog: da9061: watchdog driver (RFC)

[Guenter Roeck]

On 10/07/2016 04:35 PM, Dmitry Torokhov wrote:

On Fri, Oct 07, 2016 at 06:01:23PM +, Steve Twiss wrote:

On 07 October 2016 18:02, Guenter Roeck wrote:


On 06 October 2016 19:49, Guenter Roeck wrote:

On Thu, Oct 06, 2016 at 04:28:14PM +, Steve Twiss wrote:

I am using the compatible string to pick a different configuration .data block:
{ .compatible = "dlg,da9062-watchdog", .data = _watchdog_info },
{ .compatible = "dlg,da9061-watchdog", .data = _watchdog_info },

But, it is just my opinion to keep the "name" different.
This will not be my decision if accepted into the Linux kernel, but I would 
like to
at least be consistent for DA9061 and DA9062 so ... is this an issue?


FWIW the driver doesn't really need to be updated in the first place.
A compatible statement listing both da9061 and da9062 would do it.


I will make the changes you requested: deprecate the existing compatibility
for da9062-watchdog and make a new compatibility string which combines both
da9061 and da9062.


That is not what I asked for.


Ok. Did you mean separate compatible statements with data sections pointing at
the same structure?

Like this:
{ .compatible = "dlg,da9062-watchdog", .data = _watchdog_info },
{ .compatible = "dlg,da9061-watchdog", .data = _watchdog_info },

So this would be the only change needed in the device driver.


If there is no change in IP block then I do not see why we need to
introduce new names at all. The dts can specify fallback compatible
stting. Note, it is called *compatible* not "model" or "device id" or
whatever. So you can just say in DTS:

compatible = "dlg,da9061-watchdog", "dlg,da9062-watchdog";

and leave the driver alone. That goes for input part as well. You only
need to add new compatible to the driver when it in fact is
*incompatible* with the existing blocks.


Yes, exactly.

Thanks,
Guenter

Re: [PATCH 2/10] mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c

[Shawn Lin]

Hi,

在 2016/10/7 23:22, Gregory CLEMENT 写道:

From: Ziji Hu 

Export sdhci_start_signal_voltage_switch() from sdhci.c.
Thus vendor sdhci driver can implement its own signal voltage
switch routine.



You can overwtite this callback within your driver itself.
That is what other sdhci variant drivers did, so patch 1-3 are
unnecessary.


Signed-off-by: Hu Ziji 
Reviewed-by: Gregory CLEMENT 
Signed-off-by: Gregory CLEMENT 
---
 drivers/mmc/host/sdhci.c | 5 +++--
 drivers/mmc/host/sdhci.h | 2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index d4bb818c52d5..2250ea22231f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1828,8 +1828,8 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, 
int enable)
spin_unlock_irqrestore(>lock, flags);
 }

-static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
-struct mmc_ios *ios)
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
 {
struct sdhci_host *host = mmc_priv(mmc);
u16 ctrl;
@@ -1921,6 +1921,7 @@ static int sdhci_start_signal_voltage_switch(struct 
mmc_host *mmc,
return 0;
}
 }
+EXPORT_SYMBOL_GPL(sdhci_start_signal_voltage_switch);

 static int sdhci_card_busy(struct mmc_host *mmc)
 {
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 21dc80b8ae3d..c38ab65b9a97 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -687,6 +687,8 @@ void sdhci_set_bus_width(struct sdhci_host *host, int 
width);
 void sdhci_reset(struct sdhci_host *host, u8 mask);
 void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
 void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios);

 #ifdef CONFIG_PM
 extern int sdhci_suspend_host(struct sdhci_host *host);




--
Best Regards
Shawn Lin

Re: [PATCH V2 2/2] fs/super.c: don't fool lockdep in freeze_super() and thaw_super() paths

[Dave Chinner]

On Fri, Oct 07, 2016 at 07:15:18PM +0200, Oleg Nesterov wrote:
> On 10/07, Dave Chinner wrote:
> >
> > On Thu, Oct 06, 2016 at 07:17:58PM +0200, Oleg Nesterov wrote:
> > > Probably false positive? Although when I look at the comment above 
> > > xfs_sync_sb()
> > > I think that may be sometging like below makes sense, but I know 
> > > absolutely nothing
> > > about fs/ and XFS in particular.
> > >
> > > Oleg.
> > >
> > >
> > > --- x/fs/xfs/xfs_trans.c
> > > +++ x/fs/xfs/xfs_trans.c
> > > @@ -245,7 +245,8 @@ xfs_trans_alloc(
> > >   atomic_inc(>m_active_trans);
> > >
> > >   tp = kmem_zone_zalloc(xfs_trans_zone,
> > > - (flags & XFS_TRANS_NOFS) ? KM_NOFS : KM_SLEEP);
> > > + (flags & (XFS_TRANS_NOFS | XFS_TRANS_NO_WRITECOUNT))
> > > + ? KM_NOFS : KM_SLEEP);
> > >   tp->t_magic = XFS_TRANS_HEADER_MAGIC;
> > >   tp->t_flags = flags;
> > >   tp->t_mountp = mp;
> >
> > Brief examination says caller should set XFS_TRANS_NOFS, not change
> > the implementation to make XFS_TRANS_NO_WRITECOUNT flag to also mean
> > XFS_TRANS_NOFS.
> 
> I didn't mean the change above can fix the problem, and I don't really
> understand your suggestion.

xfs_syncsb() does:

tp = xfs_trans_alloc(... , XFS_TRANS_NO_WRITECOUNT, );

but it's running in a GFP_NOFS context when a freeze is being
finalised. SO, rather than changing what XFS_TRANS_NO_WRITECOUNT
does in xfs_trans_alloc(), we should tell it to do a GFP_NOFS
allocation. i.e.

tp = xfs_trans_alloc(... , XFS_TRANS_NOFS | XFS_TRANS_NO_WRITECOUNT, 
);

and nothing inside xfs_trans_alloc() changes at all.

> Obviously any GFP_FS allocation in xfs_fs_freeze()
> paths will trigger the same warning.

Of which there should be none except for that xfs_trans_alloc()
call.

> I added this hack
> 
>   --- a/fs/xfs/xfs_super.c
>   +++ b/fs/xfs/xfs_super.c
>   @@ -1333,10 +1333,15 @@ xfs_fs_freeze(
>   struct super_block  *sb)
>{
>   struct xfs_mount*mp = XFS_M(sb);
>   +   int ret;
>
>   +   current->flags |= PF_FSTRANS; // tell kmem_flags_convert() to 
> remove GFP_FS
>   xfs_save_resvblks(mp);
>   xfs_quiesce_attr(mp);
>   -   return xfs_sync_sb(mp, true);
>   +   ret = xfs_sync_sb(mp, true);
>   +   current->flags &= ~PF_FSTRANS;
>   +
>   +   return ret;
>}

/me shudders

> just for testing purposes and after that I got another warning below. I didn't
> read it carefully yet, but _at first glance_ it looks like the lock inversion
> uncovered by 2/2, although I can be easily wrong. 
> cancel_delayed_work_sync(l_work)
> under sb_internal can hang if xfs_log_worker() waits for this rwsem?`

Actually: I *can't read it*. I've got no fucking clue what lockdep
is trying to say here. This /looks/ like a lockdep is getting
confused between memory reclaim contexts (which /aren't locks/ but
overload interrupt levels) and freeze contexts (which /aren't locks/)
and workqueue locks which /aren't nested/ inside transactions or
freeze contexts. But, really, I can't follow it because I have to
guess at what "lock contexts" are not locks but are something else.

cheers,

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

Re: [GIT PULL] trivial for 4.9

[Tony Luck]

What if there isn't a "next printk" call for hours, or days?

That poor little message without a "\n" will sit in the kernel buffers,
and the user who might want to see the message can't, until some
unrelated thing happens to print something.

-Tony

Re: [GIT PULL] trivial for 4.9

[Tony Luck]

On Fri, Oct 7, 2016 at 4:01 PM, Tony Luck  wrote:
> What if there isn't a "next printk" call for hours, or days?
>
> That poor little message without a "\n" will sit in the kernel buffers,
> and the user who might want to see the message can't, until some
> unrelated thing happens to print something.

Retracted ... I'm sure that at some point in the past it happened like
that ... but
I just retested on 4.8 and the first message (with no "\n") showed up on the
serial port just fine without some other message to push it out. When the
next message came along, a "\n" was auto-inserted.

-Tony

[PATCH v3 0/3] Broadcom STB AVS CPUfreq driver

[Markus Mayer]

This series contains the CPUfreq driver for Broadcom SoCs that use "AVS
Firmware" for voltage and frequency scaling. All voltage and frequency
transitions are performed by the firmware and are therefore hidden from
Linux.

The driver provides a standard CPUfreq interface to other kernel
components and to userland on the one hand and communicates with the
AVS co-processor on the other.

Communication between the two processors is via shared mailbox
registers and interrupts (ARM -> AVS to tell the firmware that there is
a command to process and AVS -> ARM to tell the driver that a command
finished executing).

Changes from v2:
- removed file Documentation/cpu-freq/brcmstb-avs-cpufreq.txt, instead
  adding the text as comment in the driver itself
- wildcard match in MAINTAINERS file (drivers/cpufreq/brcmstb*)
- drivers/cpufreq/Kconfig.arm: have ARM_BRCMSTB_AVS_CPUFREQ default y
  for ARCH_BRCMSTB
- fixed naming and Kconfig entry for CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
- reordered and fixed include files
- made sure driver name doesn't exceed size of cpufreq_driver.name
- got rid of device_node pointers in struct private_data; there's no
  need for them, as we can call of_node_put() in __map_region()
- don't set driver_data for CPUFREQ_TABLE_END
- have brcm_avs_cpufreq_get() read from the firmware rather than return
  policy->cur
- don't update policy->cur in brcm_avs_target_index()
- created new function brcm_avs_prepare_init() to handle compatibility
  checks during initialization and moved corresponding code from
  brcm_avs_cpufreq_init() to the new function
- brcm_avs_prepare_init() is called from brcm_avs_cpufreq_probe() and
  therefore will only be called once, even in the case of an error,
  whereas brcm_avs_cpufreq_init() is called for every core if there is
  an error
- renamed brcm_avs_cpu_(init|exit) to brcm_avs_cpufreq_(init|exit)
- added platform_set_drvdata(pdev, NULL) upon deregistration
- fixed various style complaints by checkpatch.pl --strict
- fixed other style issues
- updated and improved some comments
- added Viresh's Acks to patches 1/3 and 3/3

Changes from v1:
- renamed binding document
- rewrote the introduction of the binding document
- created a new driver documentation file that contains Linux specific
  information that was previously part of the binding document
- renamed the driver (and related config options) to include a reference
  to "STB", since this implementation is primarily intended for use on
  set-top boxes
- improved comments
- updated function __map_region()
- updated struct private_data
- added code to unmap memory regions in the error and exit paths
- added new sysfs property to report frequency directly from the
  co-processor register


Markus Mayer (3):
  dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq
  cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs
  cpufreq: brcmstb-avs-cpufreq: add debugfs support

 .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt |   76 ++
 MAINTAINERS|8 +
 drivers/cpufreq/Kconfig.arm|   21 +
 drivers/cpufreq/Makefile   |1 +
 drivers/cpufreq/brcmstb-avs-cpufreq.c  | 1057 
 5 files changed, 1163 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
 create mode 100644 drivers/cpufreq/brcmstb-avs-cpufreq.c

-- 
2.7.4

[PATCH v3 2/3] cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs

[Markus Mayer]

This driver supports voltage and frequency scaling on Broadcom STB SoCs
using AVS firmware with DFS and DVFS support.

Actual frequency or voltage scaling is done exclusively by the AVS
firmware. The driver merely provides a standard CPUfreq interface to
other kernel components and userland, and instructs the AVS firmware to
perform frequency or voltage changes on its behalf.

Signed-off-by: Markus Mayer 
---
 MAINTAINERS   |   1 +
 drivers/cpufreq/Kconfig.arm   |  11 +
 drivers/cpufreq/Makefile  |   1 +
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 737 ++
 4 files changed, 750 insertions(+)
 create mode 100644 drivers/cpufreq/brcmstb-avs-cpufreq.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 75accd5..1605546 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2707,6 +2707,7 @@ M:bcm-kernel-feedback-l...@broadcom.com
 L: linux...@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
+F: drivers/cpufreq/brcmstb*
 
 BROADCOM SPECIFIC AMBA DRIVER (BCMA)
 M: Rafał Miłecki 
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index d89b8af..d4e3795 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -12,6 +12,17 @@ config ARM_BIG_LITTLE_CPUFREQ
help
  This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
 
+config ARM_BRCMSTB_AVS_CPUFREQ
+   tristate "Broadcom STB AVS CPUfreq driver"
+   depends on ARCH_BRCMSTB || COMPILE_TEST
+   default y
+   help
+ Some Broadcom STB SoCs use a co-processor running proprietary firmware
+ ("AVS") to handle voltage and frequency scaling. This driver provides
+ a standard CPUfreq interface to to the firmware.
+
+ Say Y, if you have a Broadcom SoC with AVS support for DFS or DVFS.
+
 config ARM_DT_BL_CPUFREQ
tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
depends on ARM_BIG_LITTLE_CPUFREQ && OF
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 0a9b6a09..ac54f64 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ)  += arm_big_little.o
 # LITTLE drivers, so that it is probed last.
 obj-$(CONFIG_ARM_DT_BL_CPUFREQ)+= arm_big_little_dt.o
 
+obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)  += brcmstb-avs-cpufreq.o
 obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)   += exynos5440-cpufreq.o
diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
b/drivers/cpufreq/brcmstb-avs-cpufreq.c
new file mode 100644
index 000..d012d93
--- /dev/null
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -0,0 +1,737 @@
+/*
+ * CPU frequency scaling for Broadcom SoCs with AVS firmware that
+ * supports DVS or DVFS
+ *
+ * Copyright (c) 2016 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * "AVS" is the name of a firmware developed at Broadcom. It derives
+ * its name from the technique called "Adaptive Voltage Scaling".
+ * Adaptive voltage scaling was the original purpose of this firmware.
+ * The AVS firmware still supports "AVS mode", where all it does is
+ * adaptive voltage scaling. However, on some newer Broadcom SoCs, the
+ * AVS Firmware, despite its unchanged name, also supports DFS mode and
+ * DVFS mode.
+ *
+ * In the context of this document and the related driver, "AVS" by
+ * itself always means the Broadcom firmware and never refers to the
+ * technique called "Adaptive Voltage Scaling".
+ *
+ * The Broadcom STB AVS CPUfreq driver provides voltage and frequency
+ * scaling on Broadcom SoCs using AVS firmware with support for DFS and
+ * DVFS. The AVS firmware is running on its own co-processor. The
+ * driver supports both uniprocessor (UP) and symmetric multiprocessor
+ * (SMP) systems which share clock and voltage across all CPUs.
+ *
+ * Actual voltage and frequency scaling is done solely by the AVS
+ * firmware. This driver does not change frequency or voltage itself.
+ * It provides a standard CPUfreq interface to the rest of the kernel
+ * and to userland. It interfaces with the AVS firmware to effect the
+ * requested changes and to report back the current system status in a
+ * way that is expected by existing tools.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Max number of 

Re: [RESEND PATCH v2 0/3] Broadcom AVS CPUfreq driver

[Markus Mayer]

My apologies. Please ignore this e-mail. Proper series coming up shortly.

Regards,
-Markus

On 7 October 2016 at 16:20, Markus Mayer  wrote:
> This series contains the CPUfreq driver for Broadcom SoCs that use "AVS
> Firmware" for voltage and frequency scaling. All voltage and frequency
> transitions are performed by the firmware and are therefore hidden from
> Linux.
>
> The driver provides a standard CPUfreq interface to other kernel
> components and to userland on the one hand and communicates with the
> AVS co-processor on the other.
>
> Communication between the two processors is via shared mailbox
> registers and interrupts (ARM -> AVS to tell the firmware that there is
> a command to process and AVS -> ARM to tell the driver that a command
> finished executing).
>
> lkml.org seems to be down for me. Here are patchwork links to the original
> series:
>
> https://patchwork.kernel.org/patch/9278119/
> https://patchwork.kernel.org/patch/9278121/
> https://patchwork.kernel.org/patch/9278127/
>
> Changes from v1:
> - renamed binding document
> - rewrote the introduction of the binding document
> - created a new driver documentation file that contains Linux specific
>   information that was previously part of the binding document
> - renamed the driver (and related config options) to include a reference
>   to "STB", since this implementation is primarily intended for use on
>   set-top boxes
> - improved comments
> - updated function __map_region()
> - updated struct private_data
> - added code to unmap memory regions in the error and exit paths
> - added new sysfs property to report frequency directly from the
>   co-processor register
>
> Markus Mayer (3):
>   dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq
>   cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs
>   cpufreq: brcmstb-avs-cpufreq: add debugfs support
>
>  Documentation/cpu-freq/brcmstb-avs-cpufreq.txt |   27 +
>  .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt |   77 ++
>  MAINTAINERS|9 +
>  drivers/cpufreq/Kconfig.arm|   10 +
>  drivers/cpufreq/Makefile   |1 +
>  drivers/cpufreq/brcmstb-avs-cpufreq.c  | 1026 
> 
>  6 files changed, 1150 insertions(+)
>  create mode 100644 Documentation/cpu-freq/brcmstb-avs-cpufreq.txt
>  create mode 100644 
> Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
>  create mode 100644 drivers/cpufreq/brcmstb-avs-cpufreq.c
>
> --
> 2.7.4
>

Re: [PATCH 01/01] drivers:input:byd fix greedy detection of Sentelic FSP by the BYD touchpad driver

[Dmitry Torokhov]

Hi Christophe,

On Fri, Oct 07, 2016 at 12:41:48PM +0800, Christophe Tordeux wrote:
> From: Christophe TORDEUX 
> 
> With kernel v4.6 and later, the Sentelic touchpad STL3888_C0 and
> probably other Sentelic FSP touchpads are detected as a BYD touchpad and
> lose multitouch features.
> 
> During the BYD handshake in the byd_detect function, the BYD driver
> mistakenly interprets a standard PS/2 protocol status request answer
> from the Sentelic touchpad as a successful handshake with a BYD
> touchpad. This is clearly a bug of the BYD driver.
> 
> Description of the patch: In byd_detect function, remove positive
> detection result based on standard PS/2 protocol status request answer.
> Replace it with positive detection based on handshake answers as they
> can be inferred from the BYD touchpad datasheets found on BYD website.
> 
> Signed-off-by: Christophe TORDEUX 

What devices was this tested on? Do you have both BYD and Sentelic
devices?

I am really concerned about docs on BYD side as they seem to contradict
each other... I wonder how accurate they are.

Thanks.

> 
> ---
> Resubmitting this patch because I got no feedback on my first 
> submission.
> Fixes kernel bug 175421 which is impacting multiple users.
> 
> ---
>  drivers/input/mouse/byd.c | 76 
>  ++-
>  1 file changed, 62 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/input/mouse/byd.c b/drivers/input/mouse/byd.c
> index b27aa63..b5acca0 100644
> --- a/drivers/input/mouse/byd.c
> +++ b/drivers/input/mouse/byd.c
> @@ -35,6 +35,18 @@
>   * BYD pad constants
>   */
>  
> +/* Handshake answer of BTP6034 */
> +#define BYD_MODEL_BTP60340x00E801
> +/* Handshake answer of BTP6740 */
> +#define BYD_MODEL_BTP67400x001155
> +/* Handshake answers of BTP8644, BTP10463 and BTP11484 */
> +#define BYD_MODEL_BTP86440x011155
> +
> +/* Handshake SETRES byte of BTP6034 and BTP6740 */
> +#define BYD_SHAKE_BYTE_A 0x00
> +/* Handshake SETRES byte of BTP8644, BTP10463 and BTP11484 */
> +#define BYD_SHAKE_BYTE_B 0x03
> +
>  /*
>   * True device resolution is unknown, however experiments show the
>   * resolution is about 111 units/mm.
> @@ -434,23 +446,59 @@ static void byd_disconnect(struct psmouse *psmouse)
>   }
>  }
>  
> +u32 byd_try_model(u32 model)
> +{
> + size_t i;
> +
> + u32 byd_model[] = {
> + BYD_MODEL_BTP6034,
> + BYD_MODEL_BTP6740,
> + BYD_MODEL_BTP8644
> + };
> +
> + for (i=0; i < ARRAY_SIZE(byd_model); i++) {
> + if (model ==  byd_model[i])
> + return model;
> + }
> +
> + return 0;
> +}
> +
>  int byd_detect(struct psmouse *psmouse, bool set_properties)
>  {
>   struct ps2dev *ps2dev = >ps2dev;
> - u8 param[4] = {0x03, 0x00, 0x00, 0x00};
> -
> - if (ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES))
> - return -1;
> - if (ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES))
> - return -1;
> - if (ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES))
> - return -1;
> - if (ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES))
> - return -1;
> - if (ps2_command(ps2dev, param, PSMOUSE_CMD_GETINFO))
> - return -1;
> -
> - if (param[1] != 0x03 || param[2] != 0x64)
> + size_t i;
> +
> + u8 byd_shbyte[] = {
> + BYD_SHAKE_BYTE_A,
> + BYD_SHAKE_BYTE_B
> + };
> +
> + bool detect = false;
> + for (i=0; i < ARRAY_SIZE(byd_shbyte); i++) {
> + u32 model;
> + u8 param[4] = {byd_shbyte[i], 0x00, 0x00, 0x00};
> +
> + if (ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES))
> + return -1;
> + if (ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES))
> + return -1;
> + if (ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES))
> + return -1;
> + if (ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES))
> + return -1;
> + if (ps2_command(ps2dev, param, PSMOUSE_CMD_GETINFO))
> + return -1;
> +
> + model = param[2];
> + model += param[1] << 8;
> + model += param[0] << 16;
> + model = byd_try_model(model);
> + if (model)
> + detect = true;
> + }
> +
> + if (!detect)
>   return -ENODEV;
>  
>   psmouse_dbg(psmouse, "BYD touchpad detected\n");



-- 
Dmitry

Re: [PATCH 00/14] libnvdimm: support sub-divisions of pmem for 4.9

[Dan Williams]

On Fri, Oct 7, 2016 at 2:42 PM, Linda Knippers  wrote:
>
>
> On 10/7/2016 3:52 PM, Dan Williams wrote:
>> On Fri, Oct 7, 2016 at 11:19 AM, Linda Knippers  
>> wrote:
>>> Hi Dan,
>>>
>>> A couple of general questions...
>>>
>>> On 10/7/2016 12:38 PM, Dan Williams wrote:
 With the arrival of the device-dax facility in 4.7 a pmem namespace can
 now be configured into a total of four distinct modes: 'raw', 'sector',
 'memory', and 'dax'. Where raw, sector, and memory are block device
 modes and dax supports the device-dax character device. With that degree
 of freedom in the use cases it is overly restrictive to continue the
 current limit of only one pmem namespace per-region, or "interleave-set"
 in ACPI 6+ terminology.
>>>
>>> If I understand correctly, at least some of the restrictions were
>>> part of the Intel NVDIMM Namespace spec rather than ACPI/NFIT restrictions.
>>> The most recent namespace spec on pmem.io hasn't been updated to remove
>>> those restrictions.  Is there a different public spec?
>>
>> Yes, this is Linux specific and use of this capability needs to be
>> cognizant that it could create a configuration that is not understood
>> by EFI, or other OSes (including older Linux implementations).  I plan
>> to add documentation to ndctl along these lines.  This is similar to
>> the current situation with 'pfn' and 'dax' info blocks that are also
>> Linux specific.  However, I should note that this implementation
>> changes none of the interpretation of the fields nor layout of the
>> existing label specification.  It simply allows two pmem labels that
>> happen to appear in the same region to result in two namespaces rather
>> than 0.
>
> Ok, but the namespace spec says that's not allowed.  It seemed like an odd
> restriction to be in the label spec but it is there.

The restriction greatly simplified the implementation back a couple
years ago when we assumed that partitioning of block devices could
handle any cases of needing distinct operation modes for different
sub-divisions of pmem.  If you look at the original implementation of
the btt, before it went upstream, it was designed as a stacked block
device driver.  In that arrangement you could theoretically have
/dev/pmem0 as the whole disk device and then create a btt
configuration on top of /dev/pmem0p1 but leave /dev/pmem0p2 as a plain
/ raw pmem device.

We killed that design during the review process and moved btt to be an
intrinsic property of the whole device.

Another development since that one-namespace-per-region restriction
was thought to be tenable was that we (the Linux community) decided
not to pursue raw-device-dax support for block devices.  Linux block
devices are tied in with the page cache and filesystems sometimes use
the block-device-inode page cache to submit metadata updates
(particularly ext4).  This collided with the msync/fsync dirty
cacheline tracking implementation.  We started to fix a few of those
collisions, but then decided it would be better to leave block devices
alone and move raw-device-dax support to its own / new device node
type.  That's the genesis of device-dax.

So the rationale of "don't allow sub-division because an
implementation can just use block device partitions for different use
case" no longer holds.

 This series adds support for reading and writing configurations that
 describe multiple pmem allocations within a region.  The new rules for
 allocating / validating the available capacity when blk and pmem regions
 alias are (quoting space_valid()):

BLK-space is valid as long as it does not precede a PMEM
allocation in a given region. PMEM-space must be contiguous
and adjacent to an existing existing allocation (if one
exists).
>>>
>>> Why is this new rule necessary?  Is this a HW-specific rule or something
>>> related to how Linux could possibly support something?  Why do we care
>>> whether blk-space is before or after pmem-space? If it's a HW-specific
>>> rule, then shouldn't the enforcement be in the management tool that
>>> configures the namespaces?
>>
>> It is not HW specific, and it's not new in the sense that we already
>> arrange for pmem to be allocated from low addresses and blk to be
>> allocated from high addresses.
>
> Who's the "we"?

"We" == the current Linux kernel implementation, i.e. we the Linux community.

> Does the location within the region come from the OS
> or from the tool that created the namespace?  (I should probably know
> this but not having labels, I've never looked at this.)

The location is chosen by the kernel.  Userspace only selects the size.

> If we're relaxing some of the rules, it seems like one could have
> pmem, then block, then free space, and later want to use free space
> for another pmem range.  If hardware supported it and the management
> tool created it, would the kernel allow it?

As long as external tooling 

[PATCH v3 15/18] x86/intel_rdt: Add tasks files

[Fenghua Yu]

From: Fenghua Yu 

The root directory all subdirectories are automatically populated
with a read/write (mode 0644) file named "tasks". When read it will
show all the task IDs assigned to the resource group. Tasks can be
added (one at a time) to a group by writing the task ID to the file.
E.g.

Membership in a resource group is indicated by a new field in the
task_struct "int closid" which holds the CLOSID for each task. The
default resource group uses CLOSID=0 which means that all existing
tasks when the resctrl file system is mounted belong to the default
group.

A resource group cannot be removed while there are tasks assigned
to it.

Signed-off-by: Fenghua Yu 
Signed-off-by: Tony Luck 
---
 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 173 +++
 include/linux/sched.h|   3 +
 2 files changed, 176 insertions(+)

diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c 
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 2a4e78a..e9e834b 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -261,6 +262,152 @@ unlock:
return ret ?: nbytes;
 }
 
+struct task_move_callback {
+   struct callback_head work;
+   struct rdtgroup *rdtgrp;
+};
+
+static void move_myself(struct callback_head *head)
+{
+   struct task_move_callback *callback;
+   struct rdtgroup *rdtgrp;
+
+   callback = container_of(head, struct task_move_callback, work);
+   rdtgrp = callback->rdtgrp;
+
+   /* Resource group might have been deleted before process runs */
+   if (atomic_dec_and_test(>waitcount) &&
+   (rdtgrp->flags & RDT_DELETED)) {
+   current->closid = 0;
+   kfree(rdtgrp);
+   }
+
+   kfree(callback);
+}
+
+static int __rdtgroup_move_task(struct task_struct *tsk,
+   struct rdtgroup *rdtgrp)
+{
+   struct task_move_callback *callback;
+   int ret;
+
+   callback = kzalloc(sizeof(*callback), GFP_KERNEL);
+   if (!callback)
+   return -ENOMEM;
+   callback->work.func = move_myself;
+   callback->rdtgrp = rdtgrp;
+   atomic_inc(>waitcount);
+   ret = task_work_add(tsk, >work, true);
+   if (ret) {
+   atomic_dec(>waitcount);
+   kfree(callback);
+   } else {
+   tsk->closid = rdtgrp->closid;
+   }
+   return ret;
+}
+
+static int rdtgroup_task_write_permission(struct task_struct *task,
+ struct kernfs_open_file *of)
+{
+   const struct cred *cred = current_cred();
+   const struct cred *tcred = get_task_cred(task);
+   int ret = 0;
+
+   /*
+* even if we're attaching all tasks in the thread group, we only
+* need to check permissions on one of them.
+*/
+   if (!uid_eq(cred->euid, GLOBAL_ROOT_UID) &&
+   !uid_eq(cred->euid, tcred->uid) &&
+   !uid_eq(cred->euid, tcred->suid))
+   ret = -EPERM;
+
+   put_cred(tcred);
+   return ret;
+}
+
+static int rdtgroup_move_task(pid_t pid, struct rdtgroup *rdtgrp,
+ struct kernfs_open_file *of)
+{
+   struct task_struct *tsk;
+   int ret;
+
+   rcu_read_lock();
+   if (pid) {
+   tsk = find_task_by_vpid(pid);
+   if (!tsk) {
+   ret = -ESRCH;
+   goto out_unlock_rcu;
+   }
+   } else {
+   tsk = current;
+   }
+
+   get_task_struct(tsk);
+   rcu_read_unlock();
+
+   ret = rdtgroup_task_write_permission(tsk, of);
+   if (!ret)
+   ret = __rdtgroup_move_task(tsk, rdtgrp);
+
+   put_task_struct(tsk);
+   return ret;
+
+out_unlock_rcu:
+   rcu_read_unlock();
+   return ret;
+}
+
+static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
+   char *buf, size_t nbytes, loff_t off)
+{
+   struct rdtgroup *rdtgrp;
+   pid_t pid;
+   int ret = 0;
+
+   if (kstrtoint(strstrip(buf), 0, ) || pid < 0)
+   return -EINVAL;
+   rdtgrp = rdtgroup_kn_lock_live(of->kn);
+
+   if (rdtgrp)
+   ret = rdtgroup_move_task(pid, rdtgrp, of);
+   else
+   ret = -ENOENT;
+
+   rdtgroup_kn_unlock(of->kn);
+
+   return ret ?: nbytes;
+}
+
+static void show_rdt_tasks(struct rdtgroup *r, struct seq_file *s)
+{
+   struct task_struct *p;
+
+   rcu_read_lock();
+   for_each_process(p) {
+   if (p->closid == r->closid)
+   seq_printf(s, "%d\n", p->pid);
+   }
+   rcu_read_unlock();
+}
+
+static int rdtgroup_tasks_show(struct kernfs_open_file *of,
+  struct seq_file *s, void *v)
+{
+   struct rdtgroup *rdtgrp;
+

[PATCH v3 16/18] x86/intel_rdt: Add schemata file

[Fenghua Yu]

From: Tony Luck 

Last of the per resource group files. Also mode 0644. This one shows
the resources available to the group. Syntax depends on whether the
"cdp" mount option was given. With code/data prioritization disabled
it is simply a list of masks for each cache domain. Initial value
allows access to all of the L3 cache on all domains. E.g. on a 2 socket
Broadwell:
L3:0=f;1=f
With CDP enabled, separate masks for data and instructions are provided:
L3:0=f,f;1=f,f

Signed-off-by: Tony Luck 
Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/intel_rdt.h |   6 +
 arch/x86/kernel/cpu/Makefile |   2 +-
 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c |   7 +
 arch/x86/kernel/cpu/intel_rdt_schemata.c | 260 +++
 4 files changed, 274 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/kernel/cpu/intel_rdt_schemata.c

diff --git a/arch/x86/include/asm/intel_rdt.h b/arch/x86/include/asm/intel_rdt.h
index 7c74272..c052652 100644
--- a/arch/x86/include/asm/intel_rdt.h
+++ b/arch/x86/include/asm/intel_rdt.h
@@ -67,6 +67,7 @@ struct rftype {
  * @cdp_capable:   Code/Data Prioritization available
  * @cdp_enabled:   Code/Data Prioritization enabled
  * @tmp_cbms:  Scratch space when updating schemata
+ * @num_cbms:  Number of CBMs in tmp_cbms
  * @cache_level:   Which cache level defines scope of this domain
  */
 struct rdt_resource {
@@ -83,6 +84,7 @@ struct rdt_resource {
boolcdp_capable;
boolcdp_enabled;
u32 *tmp_cbms;
+   int num_cbms;
int cache_level;
 };
 
@@ -155,4 +157,8 @@ DECLARE_PER_CPU_READ_MOSTLY(int, cpu_closid);
 void rdt_cbm_update(void *arg);
 struct rdtgroup *rdtgroup_kn_lock_live(struct kernfs_node *kn);
 void rdtgroup_kn_unlock(struct kernfs_node *kn);
+ssize_t rdtgroup_schemata_write(struct kernfs_open_file *of,
+   char *buf, size_t nbytes, loff_t off);
+int rdtgroup_schemata_show(struct kernfs_open_file *of,
+  struct seq_file *s, void *v);
 #endif /* _ASM_X86_INTEL_RDT_H */
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 963c54a..4d7e0e5 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -34,7 +34,7 @@ obj-$(CONFIG_CPU_SUP_CENTAUR) += centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)   += umc.o
 
-obj-$(CONFIG_INTEL_RDT)+= intel_rdt.o intel_rdt_rdtgroup.o
+obj-$(CONFIG_INTEL_RDT)+= intel_rdt.o intel_rdt_rdtgroup.o 
intel_rdt_schemata.o
 
 obj-$(CONFIG_X86_MCE)  += mcheck/
 obj-$(CONFIG_MTRR) += mtrr/
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c 
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index e9e834b..4740b7e 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -425,6 +425,13 @@ static struct rftype rdtgroup_base_files[] = {
.seq_show   = rdtgroup_tasks_show,
},
{
+   .name   = "schemata",
+   .mode   = 0644,
+   .kf_ops = _kf_single_ops,
+   .write  = rdtgroup_schemata_write,
+   .seq_show   = rdtgroup_schemata_show,
+   },
+   {
/* NULL terminated */
}
 };
diff --git a/arch/x86/kernel/cpu/intel_rdt_schemata.c 
b/arch/x86/kernel/cpu/intel_rdt_schemata.c
new file mode 100644
index 000..d666854
--- /dev/null
+++ b/arch/x86/kernel/cpu/intel_rdt_schemata.c
@@ -0,0 +1,260 @@
+/*
+ * Resource Director Technology(RDT)
+ * - Cache Allocation code.
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * Authors:
+ *Fenghua Yu 
+ *Tony Luck 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * More information about RDT be found in the Intel (R) x86 Architecture
+ * Software Developer Manual June 2016, volume 3, section 17.17.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Check whether a cache bit mask is valid. The SDM says:
+ * Please note that all (and only) contiguous '1' combinations
+ * are allowed (e.g. H, 0FF0H, 003CH, etc.).
+ * Additionally Haswell requires at least 

[PATCH v3 06/18] x86/intel_rdt: Add CONFIG, Makefile, and basic initialization

[Fenghua Yu]

From: Fenghua Yu 

Introduce CONFIG_INTEL_RDT (default: no, dependent on X86 and
CPU_SUP_INTEL) to control inclusion of Resource Director Technology in
the build.

Simple init() routine just checks which features are present. If they are
pr_info() one line summary for each feature.

Signed-off-by: Fenghua Yu 
Signed-off-by: Tony Luck 
---
 arch/x86/Kconfig| 12 +
 arch/x86/kernel/cpu/Makefile|  2 ++
 arch/x86/kernel/cpu/intel_rdt.c | 56 +
 3 files changed, 70 insertions(+)
 create mode 100644 arch/x86/kernel/cpu/intel_rdt.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2a1f0ce..cfca613 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -406,6 +406,18 @@ config GOLDFISH
def_bool y
depends on X86_GOLDFISH
 
+config INTEL_RDT
+   bool "Intel Resource Director Technology support"
+   default n
+   depends on X86 && CPU_SUP_INTEL
+   help
+ Select to enable resource allocation which is a sub-feature of
+ Intel Resource Director Technology(RDT). More information about
+ RDT can be found in the Intel x86 Architecture Software
+ Developer Manual June 2016, volume 3, section 17.17.
+
+ Say N if unsure.
+
 if X86_32
 config X86_EXTENDED_PLATFORM
bool "Support for extended (non-PC) x86 platforms"
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 4a8697f..5a791c8 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -34,6 +34,8 @@ obj-$(CONFIG_CPU_SUP_CENTAUR) += centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)   += umc.o
 
+obj-$(CONFIG_INTEL_RDT)+= intel_rdt.o
+
 obj-$(CONFIG_X86_MCE)  += mcheck/
 obj-$(CONFIG_MTRR) += mtrr/
 obj-$(CONFIG_MICROCODE)+= microcode/
diff --git a/arch/x86/kernel/cpu/intel_rdt.c b/arch/x86/kernel/cpu/intel_rdt.c
new file mode 100644
index 000..ebe8dae
--- /dev/null
+++ b/arch/x86/kernel/cpu/intel_rdt.c
@@ -0,0 +1,56 @@
+/*
+ * Resource Director Technology(RDT)
+ * - Cache Allocation code.
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * Authors:
+ *Fenghua Yu 
+ *Tony Luck 
+ *Vikas Shivappa 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * More information about RDT be found in the Intel (R) x86 Architecture
+ * Software Developer Manual June 2016, volume 3, section 17.17.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+
+static inline bool get_rdt_resources(struct cpuinfo_x86 *c)
+{
+   bool ret = false;
+
+   if (!cpu_has(c, X86_FEATURE_RDT_A))
+   return false;
+   if (cpu_has(c, X86_FEATURE_CAT_L3))
+   ret = true;
+
+   return ret;
+}
+
+static int __init intel_rdt_late_init(void)
+{
+   struct cpuinfo_x86 *c = _cpu_data;
+
+   if (!get_rdt_resources(c))
+   return -ENODEV;
+
+   pr_info("Intel cache allocation detected\n");
+   if (cpu_has(c, X86_FEATURE_CDP_L3))
+   pr_info("Intel code data prioritization detected\n");
+
+   return 0;
+}
+
+late_initcall(intel_rdt_late_init);
-- 
2.5.0

[PATCH v3 14/18] x86/intel_rdt: Add cpus file

[Fenghua Yu]

From: Tony Luck 

Now we populate each directory with a read/write (mode 0644) file
named "cpus". This is used to over-ride the resources available
to processes in the default resource group when running on specific
CPUs.  Each "cpus" file reads as a cpumask showing which CPUs belong
to this resource group. Initially all online CPUs are assigned to
the default group. They can be added to other groups by writing a
cpumask to the "cpus" file in the directory for the resource group
(which will remove them from the previous group to which they were
assigned). CPU online/offline operations will delete CPUs that go
offline from whatever group they are in and add new CPUs to the
default group.

If there are CPUs assigned to a group when the directory is removed,
they are returned to the default group.

Signed-off-by: Fenghua Yu 
Signed-off-by: Tony Luck 
---
 arch/x86/include/asm/intel_rdt.h |   5 ++
 arch/x86/kernel/cpu/intel_rdt.c  |  12 +++
 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 127 +++
 3 files changed, 144 insertions(+)

diff --git a/arch/x86/include/asm/intel_rdt.h b/arch/x86/include/asm/intel_rdt.h
index 99d8d14..7c74272 100644
--- a/arch/x86/include/asm/intel_rdt.h
+++ b/arch/x86/include/asm/intel_rdt.h
@@ -6,13 +6,16 @@
  * @kn:kernfs node
  * @rdtgroup_list: linked list for all rdtgroups
  * @closid:closid for this rdtgroup
+ * @cpu_mask:  CPUs assigned to this rdtgroup
  * @flags: status bits
  * @waitcount: how many cpus expect to find this
+ * group when they acquire rdtgroup_mutex
  */
 struct rdtgroup {
struct kernfs_node  *kn;
struct list_headrdtgroup_list;
int closid;
+   struct cpumask  cpu_mask;
int flags;
atomic_twaitcount;
 };
@@ -147,6 +150,8 @@ union cpuid_0x10_1_edx {
unsigned int full;
 };
 
+DECLARE_PER_CPU_READ_MOSTLY(int, cpu_closid);
+
 void rdt_cbm_update(void *arg);
 struct rdtgroup *rdtgroup_kn_lock_live(struct kernfs_node *kn);
 void rdtgroup_kn_unlock(struct kernfs_node *kn);
diff --git a/arch/x86/kernel/cpu/intel_rdt.c b/arch/x86/kernel/cpu/intel_rdt.c
index f6caabd..0b076d0 100644
--- a/arch/x86/kernel/cpu/intel_rdt.c
+++ b/arch/x86/kernel/cpu/intel_rdt.c
@@ -38,6 +38,8 @@ DEFINE_MUTEX(rdtgroup_mutex);
 
 int rdt_max_closid;
 
+DEFINE_PER_CPU_READ_MOSTLY(int, cpu_closid);
+
 #define domain_init(name) LIST_HEAD_INIT(rdt_resources_all[name].domains)
 
 struct rdt_resource rdt_resources_all[] = {
@@ -227,8 +229,11 @@ static int intel_rdt_online_cpu(unsigned int cpu)
struct rdt_resource *r;
 
mutex_lock(_mutex);
+   per_cpu(cpu_closid, cpu) = 0;
for_each_rdt_resource(r)
update_domain(cpu, r, 1);
+   /* The cpu is set in default rdtgroup after online. */
+   cpumask_set_cpu(cpu, _default.cpu_mask);
smp_call_function_single(cpu, rdt_reset_pqr_assoc_closid, NULL, 1);
mutex_unlock(_mutex);
 
@@ -238,10 +243,17 @@ static int intel_rdt_online_cpu(unsigned int cpu)
 static int intel_rdt_offline_cpu(unsigned int cpu)
 {
struct rdt_resource *r;
+   struct rdtgroup *rdtgrp;
+   struct list_head *l;
 
mutex_lock(_mutex);
for_each_rdt_resource(r)
update_domain(cpu, r, 0);
+   list_for_each(l, _all_groups) {
+   rdtgrp = list_entry(l, struct rdtgroup, rdtgroup_list);
+   if (cpumask_test_and_clear_cpu(cpu, >cpu_mask))
+   break;
+   }
mutex_unlock(_mutex);
 
return 0;
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c 
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index efcbfe7..2a4e78a 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -20,6 +20,7 @@
 
 #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -163,6 +164,117 @@ static struct kernfs_ops rdtgroup_kf_single_ops = {
.seq_show   = rdtgroup_seqfile_show,
 };
 
+static int rdtgroup_cpus_show(struct kernfs_open_file *of,
+ struct seq_file *s, void *v)
+{
+   struct rdtgroup *rdtgrp;
+   int ret = 0;
+
+   rdtgrp = rdtgroup_kn_lock_live(of->kn);
+
+   if (rdtgrp)
+   seq_printf(s, "%*pb\n", cpumask_pr_args(>cpu_mask));
+   else
+   ret = -ENOENT;
+   rdtgroup_kn_unlock(of->kn);
+
+   return ret;
+}
+
+static ssize_t rdtgroup_cpus_write(struct kernfs_open_file *of,
+  char *buf, size_t nbytes, loff_t off)
+{
+   struct rdtgroup *rdtgrp, *r;
+   cpumask_var_t tmpmask, newmask;
+   int ret, cpu;
+
+   if (!buf)
+   return -EINVAL;
+

[PATCH v3 03/18] x86, intel_cacheinfo: Enable cache id in x86

[Fenghua Yu]

From: Fenghua Yu 

Cache id is retrieved from APIC ID and CPUID leaf 4 on x86.

For more details see the section on "Cache ID Extraction Parameters" in
"Intel 64 Architecture Processor Topology Enumeration" at
https://software.intel.com/sites/default/files/63/1a/Kuo_CpuTopology_rc1.rh1.final.pdf

Also "Intel 64 and IA-32 Architectures Software Developer's Manual" volume 2,
table 3-18 "information Returned by CPUID Instruction" at
http://www.intel.com/sdm

Signed-off-by: Fenghua Yu 
Signed-off-by: Tony Luck 
---
 arch/x86/kernel/cpu/intel_cacheinfo.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index de6626c..8dc5720 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -153,6 +153,7 @@ struct _cpuid4_info_regs {
union _cpuid4_leaf_eax eax;
union _cpuid4_leaf_ebx ebx;
union _cpuid4_leaf_ecx ecx;
+   unsigned int id;
unsigned long size;
struct amd_northbridge *nb;
 };
@@ -894,6 +895,8 @@ static void __cache_cpumap_setup(unsigned int cpu, int 
index,
 static void ci_leaf_init(struct cacheinfo *this_leaf,
 struct _cpuid4_info_regs *base)
 {
+   this_leaf->id = base->id;
+   this_leaf->attributes = CACHE_ID;
this_leaf->level = base->eax.split.level;
this_leaf->type = cache_type_map[base->eax.split.type];
this_leaf->coherency_line_size =
@@ -920,6 +923,22 @@ static int __init_cache_level(unsigned int cpu)
return 0;
 }
 
+/*
+ * The max shared threads number comes from CPUID.4:EAX[25-14] with input
+ * ECX as cache index. Then right shift apicid by the number's order to get
+ * cache id for this cache node.
+ */
+static void get_cache_id(int cpu, struct _cpuid4_info_regs *id4_regs)
+{
+   struct cpuinfo_x86 *c = _data(cpu);
+   unsigned long num_threads_sharing;
+   int index_msb;
+
+   num_threads_sharing = 1 + id4_regs->eax.split.num_threads_sharing;
+   index_msb = get_count_order(num_threads_sharing);
+   id4_regs->id = c->apicid >> index_msb;
+}
+
 static int __populate_cache_leaves(unsigned int cpu)
 {
unsigned int idx, ret;
@@ -931,6 +950,7 @@ static int __populate_cache_leaves(unsigned int cpu)
ret = cpuid4_cache_lookup_regs(idx, _regs);
if (ret)
return ret;
+   get_cache_id(cpu, _regs);
ci_leaf_init(this_leaf++, _regs);
__cache_cpumap_setup(cpu, idx, _regs);
}
-- 
2.5.0

[PATCH v3 13/18] x86/intel_rdt: Add mkdir to resctrl file system

[Fenghua Yu]

From: Fenghua Yu 

Resource control groups are represented as directories in the resctrl
file system. The root directory describes the default resources available
to tasks that have not been assigned specific resources. Other directories
can be created at the root level to make new resource groups. It is not
permitted to make directories within other directories.

Hardware uses a CLOSID (Class of service ID) to determine which resource
limits are currently in effect. The exact number available is enumerated
by CPUID leaf 0x10, but on current implementations it is a small number.
We implement a simple bitmask allocator for CLOSIDs.

Each resource control group uses one CLOSID, which limits the total number
of directories that can be created.

Resource groups can be removed using rmdir.

Signed-off-by: Fenghua Yu 
Signed-off-by: Tony Luck 
---
 arch/x86/include/asm/intel_rdt.h |   9 ++
 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 222 +++
 2 files changed, 231 insertions(+)

diff --git a/arch/x86/include/asm/intel_rdt.h b/arch/x86/include/asm/intel_rdt.h
index 8e3fafc..99d8d14 100644
--- a/arch/x86/include/asm/intel_rdt.h
+++ b/arch/x86/include/asm/intel_rdt.h
@@ -6,13 +6,20 @@
  * @kn:kernfs node
  * @rdtgroup_list: linked list for all rdtgroups
  * @closid:closid for this rdtgroup
+ * @flags: status bits
+ * @waitcount: how many cpus expect to find this
  */
 struct rdtgroup {
struct kernfs_node  *kn;
struct list_headrdtgroup_list;
int closid;
+   int flags;
+   atomic_twaitcount;
 };
 
+/* rdtgroup.flags */
+#defineRDT_DELETED 1
+
 /* List of all resource groups */
 extern struct list_head rdt_all_groups;
 
@@ -141,4 +148,6 @@ union cpuid_0x10_1_edx {
 };
 
 void rdt_cbm_update(void *arg);
+struct rdtgroup *rdtgroup_kn_lock_live(struct kernfs_node *kn);
+void rdtgroup_kn_unlock(struct kernfs_node *kn);
 #endif /* _ASM_X86_INTEL_RDT_H */
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c 
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 28df92e..efcbfe7 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -36,6 +36,52 @@ struct kernfs_root *rdt_root;
 struct rdtgroup rdtgroup_default;
 LIST_HEAD(rdt_all_groups);
 
+/*
+ * Trivial allocator for CLOSIDs. Since h/w only supports
+ * a small number, we can keep a bitmap of free CLOSIDs in
+ * a single integer.
+ */
+static int closid_free_map;
+
+static void closid_init(void)
+{
+   closid_free_map = BIT_MASK(rdt_max_closid) - 1;
+
+   /* CLOSID 0 is always reserved for the default group */
+   closid_free_map &= ~1;
+}
+
+int closid_alloc(void)
+{
+   int closid = ffs(closid_free_map);
+
+   if (closid == 0)
+   return -ENOSPC;
+   closid--;
+   closid_free_map &= ~(1 << closid);
+
+   return closid;
+}
+
+static void closid_free(int closid)
+{
+   closid_free_map |= 1 << closid;
+}
+
+static struct rdtgroup *rdtgroup_alloc(void)
+{
+   struct rdtgroup *rdtgrp;
+
+   rdtgrp = kzalloc(sizeof(*rdtgrp), GFP_KERNEL);
+
+   return rdtgrp;
+}
+
+static void rdtgroup_free(struct rdtgroup *rdtgroup)
+{
+   kfree(rdtgroup);
+}
+
 /* set uid and gid of rdtgroup dirs and files to that of the creator */
 static int rdtgroup_kn_set_ugid(struct kernfs_node *kn)
 {
@@ -240,6 +286,54 @@ static int parse_rdtgroupfs_options(char *data, struct 
rdt_resource *r)
return 0;
 }
 
+/*
+ * We don't allow rdtgroup directories to be created anywhere
+ * except the root directory. Thus when looking for the rdtgroup
+ * structure for a kernfs node we are either looking at a directory,
+ * in which case the rdtgroup structure is pointed at by the "priv"
+ * field, otherwise we have a file, and need only look to the parent
+ * to find the rdtgroup.
+ */
+static struct rdtgroup *kernfs_to_rdtgroup(struct kernfs_node *kn)
+{
+   if (kernfs_type(kn) == KERNFS_DIR)
+   return kn->priv;
+   else
+   return kn->parent->priv;
+}
+
+struct rdtgroup *rdtgroup_kn_lock_live(struct kernfs_node *kn)
+{
+   struct rdtgroup *rdtgrp = kernfs_to_rdtgroup(kn);
+
+   atomic_inc(>waitcount);
+   kernfs_break_active_protection(kn);
+
+   mutex_lock(_mutex);
+
+   /* Was this group deleted while we waited? */
+   if (rdtgrp->flags & RDT_DELETED)
+   return NULL;
+
+   return rdtgrp;
+}
+
+void rdtgroup_kn_unlock(struct kernfs_node *kn)
+{
+   struct rdtgroup *rdtgrp = kernfs_to_rdtgroup(kn);
+
+   mutex_unlock(_mutex);
+
+   if (atomic_dec_and_test(>waitcount) &&
+   (rdtgrp->flags & RDT_DELETED)) {
+   kernfs_unbreak_active_protection(kn);
+   kernfs_put(kn);

[PATCH v3 05/18] Documentation, x86: Documentation for Intel resource allocation user interface

[Fenghua Yu]

From: Fenghua Yu 

The documentation describes user interface of how to allocate resource
in Intel RDT.

Please note that the documentation covers generic user interface. Current
patch set code only implemente CAT L3. CAT L2 code will be sent later.

Signed-off-by: Fenghua Yu 
Signed-off-by: Tony Luck 
---
 Documentation/x86/intel_rdt_ui.txt | 162 +
 1 file changed, 162 insertions(+)
 create mode 100644 Documentation/x86/intel_rdt_ui.txt

diff --git a/Documentation/x86/intel_rdt_ui.txt 
b/Documentation/x86/intel_rdt_ui.txt
new file mode 100644
index 000..ad51455
--- /dev/null
+++ b/Documentation/x86/intel_rdt_ui.txt
@@ -0,0 +1,162 @@
+User Interface for Resource Allocation in Intel Resource Director Technology
+
+Copyright (C) 2016 Intel Corporation
+
+Fenghua Yu 
+Tony Luck 
+
+This feature is enabled by the CONFIG_INTEL_RDT Kconfig and the
+X86 /proc/cpuinfo flag bits "rdt", "cat_l3" and "cdp_l3".
+
+To use the feature mount the file system:
+
+ # mount -t resctrl resctrl [-o cdp] /sys/fs/resctrl
+
+mount options are:
+
+"cdp": Enable code/data prioritization in L3 cache allocations.
+
+
+Resource groups
+---
+Resource groups are represented as directories in the resctrl file
+system. The default group is the root directory. Other groups may be
+created as desired by the system administrator using the "mkdir(1)"
+command, and removed using "rmdir(1)".
+
+There are three files associated with each group:
+
+"tasks": A list of tasks that belongs to this group. Tasks can be
+   added to a group by writing the task ID to the "tasks" file
+   (which will automatically remove them from the previous
+   group to which they belonged). New tasks created by fork(2)
+   and clone(2) are added to the same group as their parent.
+   If a pid is not in any sub partition, it is in root partition
+   (i.e. default partition).
+
+"cpus": A bitmask of logical CPUs assigned to this group. Writing
+   a new mask can add/remove CPUs from this group. Added CPUs
+   are removed from their previous group. Removed ones are
+   given to the default (root) group. You cannot remove CPUs
+   from the default group.
+
+"schemata": A list of all the resources available to this group.
+   Each resource has its own line and format - see below for
+   details.
+
+When a task is running the following rules define which resources
+are available to it:
+
+1) If the task is a member of a non-default group, then the schemata
+for that group is used.
+
+2) Else if the task belongs to the default group, but is running on a
+CPU that is assigned to some specific group, then the schemata for
+the CPU's group is used.
+
+3) Otherwise the schemata for the default group is used.
+
+
+Schemata files - general concepts
+-
+Each line in the file describes one resource. The line starts with
+the name of the resource, followed by specific values to be applied
+in each of the instances of that resource on the system.
+
+Cache IDs
+-
+On current generation systems there is one L3 cache per socket and L2
+caches are generally just shared by the hyperthreads on a core, but this
+isn't an architectural requirement. We could have multiple separate L3
+caches on a socket, multiple cores could share an L2 cache. So instead
+of using "socket" or "core" to define the set of logical cpus sharing
+a resource we use a "Cache ID". At a given cache level this will be a
+unique number across the whole system (but it isn't guaranteed to be a
+contiguous sequence, there may be gaps).  To find the ID for each logical
+CPU look in /sys/devices/system/cpu/cpu*/cache/index*/id
+
+Cache Bit Masks (CBM)
+-
+For cache resources we describe the portion of the cache that is available
+for allocation using a bitmask. The maximum value of the mask is defined
+by each cpu model (and may be different for different cache levels). It
+is found using CPUID, but is also provided in the "info" directory of
+the resctrl file system in "info/{resource}/max_cbm_val". X86 hardware
+requires that these masks have all the '1' bits in a contiguous block. So
+0x3, 0x6 and 0xC are legal 4-bit masks with two bits set, but 0x5, 0x9
+and 0xA are not.  On a system with a 20-bit mask each bit represents 5%
+of the capacity of the cache. You could partition the cache into four
+equal parts with masks: 0x1f, 0x3e0, 0x7c00, 0xf8000.
+
+
+L3 details (code and data prioritization disabled)
+--
+With CDP disabled the L3 schemata format is:
+
+   L3:=;=;...
+
+L3 details (CDP enabled via mount option to resctrl)
+
+When CDP is enabled, you need to specify separate cache bit masks for
+code and data access. The generic format is:
+
+   

[PATCH v3 04/18] x86/intel_rdt: Feature discovery

[Fenghua Yu]

From: Fenghua Yu 

Check CPUID leaves for all the Resource Director Technology (RDT)
Cache Allocation Technology (CAT) bits.

Prescence of allocation features:
  CPUID.(EAX=7H, ECX=0):EBX[bit 15] X86_FEATURE_RDT_A

L2 and L3 caches are each separately enabled:
  CPUID.(EAX=10H, ECX=0):EBX[bit 1] X86_FEATURE_CAT_L3
  CPUID.(EAX=10H, ECX=0):EBX[bit 2] X86_FEATURE_CAT_L2

L3 cache may support independent control of allocation for
code and data (CDP = Code/Data Prioritization):
  CPUID.(EAX=10H, ECX=1):ECX[bit 2] X86_FEATURE_CDP_L3

Signed-off-by: Fenghua Yu 
Signed-off-by: Tony Luck 
---
 arch/x86/include/asm/cpufeatures.h | 5 +
 arch/x86/kernel/cpu/scattered.c| 3 +++
 2 files changed, 8 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index 92a8308..64dd8274 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -196,6 +196,10 @@
 
 #define X86_FEATURE_INTEL_PT   ( 7*32+15) /* Intel Processor Trace */
 
+#define X86_FEATURE_CAT_L3 ( 7*32+16) /* Cache Allocation Technology L3 */
+#define X86_FEATURE_CAT_L2 ( 7*32+17) /* Cache Allocation Technology L2 */
+#define X86_FEATURE_CDP_L3 ( 7*32+18) /* Code and Data Prioritization L3 */
+
 /* Virtualization flags: Linux defined, word 8 */
 #define X86_FEATURE_TPR_SHADOW  ( 8*32+ 0) /* Intel TPR Shadow */
 #define X86_FEATURE_VNMI( 8*32+ 1) /* Intel Virtual NMI */
@@ -220,6 +224,7 @@
 #define X86_FEATURE_RTM( 9*32+11) /* Restricted Transactional 
Memory */
 #define X86_FEATURE_CQM( 9*32+12) /* Cache QoS Monitoring */
 #define X86_FEATURE_MPX( 9*32+14) /* Memory Protection 
Extension */
+#define X86_FEATURE_RDT_A  ( 9*32+15) /* Resource Director Technology 
Allocation */
 #define X86_FEATURE_AVX512F( 9*32+16) /* AVX-512 Foundation */
 #define X86_FEATURE_AVX512DQ   ( 9*32+17) /* AVX-512 DQ (Double/Quad granular) 
Instructions */
 #define X86_FEATURE_RDSEED ( 9*32+18) /* The RDSEED instruction */
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index 8cb57df..11f39a2 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -34,6 +34,9 @@ void init_scattered_cpuid_features(struct cpuinfo_x86 *c)
{ X86_FEATURE_INTEL_PT, CR_EBX,25, 0x0007, 0 },
{ X86_FEATURE_APERFMPERF,   CR_ECX, 0, 0x0006, 0 },
{ X86_FEATURE_EPB,  CR_ECX, 3, 0x0006, 0 },
+   { X86_FEATURE_CAT_L3,   CR_EBX, 1, 0x0010, 0 },
+   { X86_FEATURE_CAT_L2,   CR_EBX, 2, 0x0010, 0 },
+   { X86_FEATURE_CDP_L3,   CR_ECX, 2, 0x0010, 1 },
{ X86_FEATURE_HW_PSTATE,CR_EDX, 7, 0x8007, 0 },
{ X86_FEATURE_CPB,  CR_EDX, 9, 0x8007, 0 },
{ X86_FEATURE_PROC_FEEDBACK,CR_EDX,11, 0x8007, 0 },
-- 
2.5.0

[GIT PULL 1/8] ARM: SoC cleanups for v4.9

[Arnd Bergmann]

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8:

  Linux 4.8-rc4 (2016-08-28 15:04:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-cleanup

for you to fetch changes up to e13688fe618881dd407a68dfbd2295d70b21a445:

  ARM: select PCI_DOMAINS config from ARCH_MULTIPLATFORM (2016-09-21 22:45:13 
+0200)


ARM: SoC cleanups for v4.9

The cleanups for v4.9 are a little larger that usual, but thankfully
that is almost exclusively due to removing a significant number of
files that have become obsolete after the still ongoing conversion
of old board files to devicetree.

- for mach-omap2, which is still the largest platform in arch/arm/,
  the conversion to DT is finally complete after the Nokia N900 is
  now fully supported there, along with the omap3 LDP, and we can
  remove those two board files.
  If no regressions are found, another large cleanup for the platform
  will happen as a follow-up, removing dead code and restructuring
  the platform based on being DT-only.

- In mach-imx, similar work is ongoing, but has not come that far.
  This time, we remove the obsolete board file for the i.MX1
  generation, which like i.MX25, i.MX5, i.MX6, and i.MX7 is now DT-only.
  The remaining board files are for i.MX2 and i.MX3 machines
  based on old ARM926 or ARM1136 cores that should work with DT
  in principle.

- realview has just been converted from board files to DT, and a lot
  of code gets removed in the process. This is the last
  ARM/Keil/Versatile derived platform that was still using board
  files, the other ones being integrator, versatile and vexpress.
  We can probably merge the remaining code into a single directory
  in the near future.

- clps711x had completed the conversion in v4.8, but we accidentally
  left the files in place that should have been deleted then.

Conflicts: two files deleted here have been modified upstream,
the changes can be discarded.


Alexander Kurz (2):
  ARM: i.MX31 iomux: remove plain duplicates
  ARM: i.MX31 iomux: remove duplicates with alternate name

Alexander Shiyan (4):
  ARM: i.MX: Remove i.MX1 Armadeus APF9328 board support
  ARM: i.MX: Remove i.MX1 Synertronixx SCB9328 board support
  ARM: i.MX: Remove i.MX1 non-DT support
  ARM: i.MX: Move SOC_IMX1 into 'Device tree only'

Arnd Bergmann (5):
  Merge tag 'realview-broomstick-sweep' of 
git://git.kernel.org/.../linusw/linux-integrator into next/cleanup
  ARM: clps711x: remove extraneous files
  Merge tag 'omap-for-v4.8/legacy-signed' of 
git://git.kernel.org/.../tmlind/linux-omap into next/cleanup
  Merge tag 'omap-for-v4.9/soc-signed' of 
git://git.kernel.org/.../tmlind/linux-omap into next/cleanup
  Merge tag 'imx-cleanup-4.9' of git://git.kernel.org/.../shawnguo/linux 
into next/cleanup

Fabian Frederick (1):
  ARM: imx: remove platform-mxc_rnga

Javier Martinez Canillas (3):
  ARM: OMAP1: use IS_ENABLED() instead of checking for built-in or module
  ARM: OMAP2+: use IS_ENABLED() instead of checking for built-in or module
  ARM: imx: use IS_ENABLED() instead of checking for built-in or module

Kishon Vijay Abraham I (2):
  ARM: stop *MIGHT_HAVE_PCI* config from being selected redundantly
  ARM: select PCI_DOMAINS config from ARCH_MULTIPLATFORM

Linus Walleij (2):
  ARM: realview: delete the RealView board files
  ARM: realview: imply device tree boot

Lothar Waßmann (1):
  ARM: mxs: remove obsolete startup code for TX28

Martin Kaiser (1):
  ARM: imx: (trivial) fix typo and grammar

Tony Lindgren (3):
  Merge remote-tracking branch 'peter/peter/for-4.8_omapdss_part1' into 
omap-for-v4.8/legacy
  ARM: OMAP2+: Drop legacy board file for n900
  ARM: OMAP2+: Drop legacy board file for LDP

Vladimir Murzin (2):
  ARM: imx: no need to select SMP_ON_UP explicitly
  ARM: realview: no need to select SMP_ON_UP explicitly

 arch/arm/Kconfig  |4 +-
 arch/arm/configs/imx_v4_v5_defconfig  |3 +-
 arch/arm/configs/multi_v4t_defconfig  |4 +-
 arch/arm/mach-at91/Kconfig|1 -
 arch/arm/mach-axxia/Kconfig   |2 -
 arch/arm/mach-clps711x/Makefile.boot  |0
 arch/arm/mach-clps711x/board-autcpu12.c   |  275 --
 arch/arm/mach-clps711x/board-cdb89712.c   |  147 ---
 arch/arm/mach-clps711x/board-clep7312.c   |   45 -
 arch/arm/mach-clps711x/board-edb7211.c|  188 
 arch/arm/mach-clps711x/board-p720t.c  |  373 ---
 arch/arm/mach-clps711x/common.c   |   65 --
 arch/arm/mach-clps711x/common.h   |   23 -
 arch/arm/mach-clps711x/devices.c  |  149 ---
 arch/arm/mach-clps711x/devices.h  |   12 -
 

[GIT PULL 2/8] ARM: SoC platform updates for v4.9

[Arnd Bergmann]

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8:

  Linux 4.8-rc4 (2016-08-28 15:04:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-soc

for you to fetch changes up to e40454d3f444ba7f8cc78dd985a1414a5945757c:

  Merge tag 'mvebu-soc-4.9-1' of git://git.infradead.org/linux-mvebu into 
next/soc (2016-09-21 22:35:56 +0200)


ARM: SoC platform updates for v4.9

These are updates for platform specific code on 32-bit ARM machines,
essentially anything that can not (yet) be expressed using DT files.

Noteworthy changes include:

- We get support for running in big-endian mode on two platforms:
  sunxi (Allwinner) and s3c24xx (old Samsung).

- The recently added Uniphier platform now uses standard PSCI
  methods for SMP booting and we remove support for old bootloader
  versions that did not support it yet.

- In sunxi, we gain support for the "Nextthing GR8" SoC, which
  is a close relative of the Allwinner A13 and R8 chips.

- PXA completes its move over to the generic dmaengine framework
  and removes its old private API

- mach-bcm gains support for BCM47189/BCM53573, their first ARM
  SoC with integrated 802.11ac wireless networking.


Andy Gross (1):
  ARM: qcom: Cleanup/Remove unnecessary board file

Anson Huang (3):
  ARM: imx: rename imx6q_set_int_mem_clk_lpm() function
  ARM: imx: enable WAIT mode hardware workaround for imx6sx
  ARM: imx: add cpuidle support for i.mx6ul

Arnd Bergmann (16):
  Merge tag 'davinci-for-v4.9/soc' of 
git://git.kernel.org/.../nsekhar/linux-davinci into next/soc
  Merge tag 'samsung-soc-4.9' of git://git.kernel.org/.../krzk/linux into 
next/soc
  ARM: imx: build cpuidle-imx6sx.o for imx6ul
  ARM: mv78xx0: simplify ethernet device creation
  ARM: mvebu/orion: remove NO_IRQ check from device init
  ARM: orion: simplify orion_ge00_switch_init
  ARM: orion5x: remove extraneous NO_IRQ
  Merge tag 'qcom-soc-for-4.9' of git://git.kernel.org/.../agross/linux 
into next/soc
  Merge tag 'arm-soc/for-4.9/soc' of http://github.com/Broadcom/stblinux 
into next/soc
  Merge tag 'renesas-soc-for-v4.9' of 
git://git.kernel.org/.../horms/renesas into next/soc
  Merge tag 'pxa-for-4.9' of https://github.com/rjarzmik/linux into next/soc
  Merge tag 'sunxi-core-for-4.9' of 
https://git.kernel.org/.../mripard/linux into next/soc
  Merge tag 'imx-soc-4.9' of git://git.kernel.org/.../shawnguo/linux into 
next/soc
  Merge tag 'uniphier-soc-v4.9' of 
git://git.kernel.org/.../masahiroy/linux-uniphier into next/soc
  Merge tag 'imx-legacy-4.9' of git://git.kernel.org/.../shawnguo/linux 
into next/soc
  Merge tag 'mvebu-soc-4.9-1' of git://git.infradead.org/linux-mvebu into 
next/soc

Bartlomiej Zolnierkiewicz (4):
  arm: colibri_pxa270_defconfig: disable IDE subsystem
  arm: lpda270_defconfig: disable IDE subsystem
  arm: pxa255-idp_defconfig: disable IDE subsystem
  arm: trizeps4_defconfig: disable IDE subsystem

Ben Dooks (1):
  ARM: EXYNOS: Enable ARCH_SUPPORTS_BIG_ENDIAN explicitly

Florian Fainelli (1):
  ARM: brcmstb: Add earlyprintk support using run-time checks

Geert Uytterhoeven (1):
  ARM: debug-ll: Add support for r8a7992

Karl Beldan (1):
  ARM: davinci: da850: Add ti-aemif lookup for clock matching

Markus Elfring (2):
  ARM: s3c64xx: Delete unnecessary assignment for the field "owner"
  ARM: pxa: Use kmalloc_array() in pxa_pm_init()

Masahiro Yamada (1):
  ARM: uniphier: remove SoC-specific SMP code

Maxime Ripard (1):
  ARM: sunxi: Support the Nextthing GR8

Michael Weiser (1):
  ARM: sunxi: enable big-endian

Neil Armstrong (1):
  MAINTAINERS: update list of Oxnas maintainers

Pankaj Dubey (1):
  ARM: EXYNOS: Remove unused DMC and CMU offsets and their mappings

Petr Cvek (1):
  ARM: pxa: magician: Remove duplicated I2C pins declaration

Rafał Miłecki (1):
  ARM: BCM53573: Initial support for Broadcom BCM53573 SoCs

Robert Jarzmik (7):
  ARM: pxa: remove devicetree boards from pxa_defconfig
  ARM: pxa: remove platform dma code
  ARM: pxa: prepare pxa25x interrupts for device-tree platforms
  ARM: pxa: add pxa25x device-tree support
  ARM: pxa: fix GPIO double shifts
  ARM: pxa: remove irq init from dt machines
  ARM: pxa: pxa_cplds: fix interrupt handling

Sylwester Nawrocki (2):
  ARM: S3C24XX: Add dma_mask assignments for DMA devices
  ARM: S3C24XX: Add missing DMA device for Mini2440 board

Vladimir Zapolskiy (17):
  ARM: imx legacy: kzm: move peripheral initialization to .init_late
  ARM: imx legacy: mx31lite: move peripheral initialization to .init_late
  ARM: imx legacy: mx31ads: move peripheral initialization to .init_late
  ARM: imx legacy: 

[GIT PULL 4/8] ARM: SoC 64-bit changes for v4.9

[Arnd Bergmann]

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8:

  Linux 4.8-rc4 (2016-08-28 15:04:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-arm64

for you to fetch changes up to a119a2c4c093716193574675590ea4a7835fa277:

  Merge tag 'zte-defconfig64-4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into next/arm64 
(2016-09-19 22:35:21 +0200)


ARM: SoC 64-bit changes for v4.9

Changes to platform code for 64-bit ARM platforms.

Nearly all of these are defconfig updates to enable new drivers or old
drivers still used on these 64-bit platforms.

Aside from that, we gain initial support for two set-top-box platforms,
both of which already have 32-bit support in arch/arm:

- Broadcom adds abstract support for the bcm7xxx/brcmstb platform,
  presumably the respective dts files and more information will
  follow at a later point.

- The ZTE ZX296718 SoC for set-top-boxes, a relative of the 32-bit
  ZX296702 SoC that we already support.


Andre Przywara (1):
  arm64: sunxi: Kconfig: add essential pinctrl driver

Arnd Bergmann (8):
  Merge tag 'hisi-defconfig-for-4.9' of 
git://github.com/hisilicon/linux-hisi into next/arm64
  Merge tag 'qcom-arm64-defconfig-for-4.9' of 
git://git.kernel.org/.../agross/linux into next/arm64
  Merge tag 'mvebu-defconfig64-4.9-1' of 
git://git.infradead.org/linux-mvebu into next/arm64
  Merge tag 'renesas-arm64-defconfig-for-v4.9' of 
git://git.kernel.org/.../horms/renesas into next/arm64
  Merge tag 'arm-soc/for-4.9/soc-arm64' of 
http://github.com/Broadcom/stblinux into next/arm64
  Merge tag 'sunxi-config64-for-4.9' of 
https://git.kernel.org/.../mripard/linux into next/arm64
  Merge tag 'zte-soc64-4.9' of git://git.kernel.org/.../shawnguo/linux into 
next/arm64
  Merge tag 'zte-defconfig64-4.9' of 
git://git.kernel.org/.../shawnguo/linux into next/arm64

Christopher Covington (1):
  arm64: defconfig: Enable QDF2432 config options

Florian Fainelli (1):
  arm64: Add Broadcom Set Top Box Kconfig entry point

Gregory CLEMENT (1):
  arm64: configs: enable PCIe driver for Aardvark

Guodong Xu (3):
  arm64: defconfig: Enable HiSilicon kirin drm, adv7533 for HiKey
  arm64: defconfig: enable CONFIG_INPUT_HISI_POWERKEY for HiKey
  arm64: defconfig: enable bluetooth supports as modules

John Stultz (1):
  Kconfig: ARCH_HISI: Add PINCTRL to HISI platform

Jun Nie (2):
  arm64: defconfig: enable ZTE ZX related config
  arm64: add ZTE ZX SoC family

Kefeng Wang (1):
  arm64: defconfig: Enable Hisi SAS and HNS

Kevin Hilman (4):
  arm64: defconfig: enable HW random as module
  arm64: defconfig: enable meson WDT as modules
  arm64: defconfig: enable meson SPI as module
  arm64: defconfig: enable meson I2C

Leo Yan (1):
  arm64: defconfig: enable common modules for power management

Simon Horman (1):
  arm64: defconfig: Enable SDHI and GPIO_REGULATOR

Thomas Petazzoni (1):
  arm64: defconfig: enable xhci-platform

Yoshihiro Shimoda (1):
  arm64: defconfig: Add Renesas R-Car HSUSB driver support as module

 arch/arm64/Kconfig.platforms | 15 +++
 arch/arm64/configs/defconfig | 35 +--
 2 files changed, 48 insertions(+), 2 deletions(-)

[GIT PULL 0/8] ARM: SoC changes for v4.9

[Arnd Bergmann]

Hi Linus,

Here are 749 patches for ARM SoCs for this merge window, a bit less than
average this time. We support 29 new machines but all five SoCs we add
are in a family that is already supported.

Out of 165 developers contributing at least one patch, the most active
by number of patches are:

 46 Javier Martinez Canillas
 42 Sergei Shtylyov
 29 Linus Walleij
 25 Hans de Goede
 22 Krzysztof Kozlowski
 19 Vladimir Zapolskiy
 17 Patrice Chotard
 16 Grzegorz Jaszczyk
 14 Philipp Zabel
 14 Jon Mason
 14 Jisheng Zhang
 13 Vladimir Barinov

While according to Signed-off-by lines we get:

 87 Simon Horman
 86 Shawn Guo
 71 Tony Lindgren
 60 Maxime Ripard
 46 Javier Martinez Canillas
 45 Kevin Hilman
 44 Andy Gross
 42 Sergei Shtylyov
 40 Gregory CLEMENT
 35 Heiko Stuebner
 34 Krzysztof Kozlowski

The dirstat shows that once more the ARM32 dts changes dominate the
overall changes, surprisingly clearly this time showing how much
more work went into 32-bit platforms compared to 64-bit platforms:

   2.1% Documentation/devicetree/bindings/
  52.3% arch/arm/boot/dts/
   2.9% arch/arm/mach-clps711x/
   3.0% arch/arm/mach-imx/
   4.2% arch/arm/mach-omap2/
   9.9% arch/arm/mach-realview/
   4.2% arch/arm/
   2.2% arch/arm64/boot/dts/rockchip/
   9.2% arch/arm64/boot/dts/
   2.9% drivers/perf/
   5.5% drivers/
 742 files changed, 29317 insertions(+), 16385 deletions(-)

Ignoring dts and driver churn, we can see a nice cleanup, removing
almost 9000 lines of old platform code:

  12.2% arch/arm/mach-clps711x/
  12.7% arch/arm/mach-imx/
   1.4% arch/arm/mach-integrator/
  17.6% arch/arm/mach-omap2/
   1.4% arch/arm/mach-pxa/
  41.6% arch/arm/mach-realview/
   2.3% arch/arm/mach-uniphier/
   1.1% arch/arm/plat-orion/
   1.2% arch/arm/plat-pxa/include/plat/
   3.1% arch/arm/plat-pxa/
   4.6% arch/arm/
 172 files changed, 698 insertions(+), 9468 deletions(-)

Arnd

[GIT PULL 8/8] ARM: SoC: late DT updates for v4.9

[Arnd Bergmann]

The following changes since commit d63a5e7c713a68bd368016f2022326a1a91310d8:

  clk: sunxi-ng: Add hardware dependency (2016-09-10 11:41:21 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-late

for you to fetch changes up to 8185041f5fa6f02acf75229a590e16aac028fc5e:

  ARM: dts: lpc32xx: add device node for IRAM on-chip memory (2016-10-02 
22:08:11 -0700)


ARM: SoC: late DT updates for v4.9

These updates have been kept in a separate branch mostly because
they rely on updates to the respective clk drivers to keep the
shared header files in sync.

- The Renesas r8a7796 (R-Car M3-W) platform gets added, this is an
  automotive SoC similar to the ⅹ8a7795 chip we already support, but
  the dts changes rely on a clock driver change that has been
  merged for v4.9 through the clk tree.

- The Amlogic meson-gxbb (S905) platform gains support for a few
  drivers merged through our tree, in particular the network and
  usb driver changes are required and included here, and also
  the clk tree changes.

- The Allwinner platforms have seen a large-scale change to their
  clk drivers and the dts file updates must come after that.
  This includes the newly added Nextthing GR8 platform, which is
  derived from sun5i/A13.

- Some integrator (arm32) changes rely on clk driver changes.

- A single patch for lpc32xx has no such dependency but wasn't
  added until just before the merge window


Arnd Bergmann (8):
  Merge tag 'sunxi-dt-for-4.9-2' of 
https://git.kernel.org/.../mripard/linux into next/late
  Merge tag 'amlogic-dt64' of 
git://git.kernel.org/.../khilman/linux-amlogic into next/late
  Merge tag 'renesas-arm64-dt-for-v4.9' of 
git://git.kernel.org/.../horms/renesas into next/late
  Merge tag 'integrator-armsoc-1' of 
git://git.kernel.org/.../linusw/linux-integrator into next/late
  Merge tag 'amlogic-drivers-2' of 
git://git.kernel.org/.../khilman/linux-amlogic into next/late
  Merge tag 'amlogic-dt64-2' of 
git://git.kernel.org/.../khilman/linux-amlogic into next/late
  Merge tag 'sunxi-dt-for-4.9-3' of 
https://git.kernel.org/.../mripard/linux into next/late
  Merge branch 'next/late' into HEAD

Carlo Caione (4):
  documentation: Add secure monitor bindings documentation
  ARM64: dts: amlogic: gxbb: Enable secure monitor
  documentation: Add nvmem bindings documentation
  ARM64: dts: amlogic: gxbb: Enable NVMEM

Chen-Yu Tsai (7):
  ARM: dts: sun6i: switch A31/A31s to new CCU clock bindings
  ARM: dts: sun8i: Move A23/A33 usbphy and usb_otg nodes to common dtsi
  ARM: dts: sun9i: a80-optimus: Declare AXP809 SW regulator as unused
  ARM: dts: sun9i: cubieboard4: Declare AXP809 SW regulator as unused
  ARM: dts: sun9i: a80-optimus: Add AXP806 PMIC device node and regulators
  ARM: dts: sun9i: cubieboard4: Add AXP806 PMIC device node and regulators
  ARM: dts: sun9i: a80-optimus: Disable EHCI1

Geert Uytterhoeven (1):
  arm64: dts: r8a7795: Add SoC-specific compatible property to audio-dmac 
nodes

Hans de Goede (6):
  ARM: dts: sun8i: Add touchscreen node for sun8i-a23-gt90h
  ARM: dts: sun8i: Add touchscreen node for sun8i-a23-inet86dz
  ARM: dts: sun8i: Add touchscreen node for sun8i-a23-polaroid-mid2407pxe03
  ARM: dts: sun8i: Add touchscreen node for sun8i-a23-polaroid-mid2809pxe04
  ARM: dts: sun8i: Add touchscreen node for sun8i-a33-ga10h
  ARM: dts: sun8i: Add accelerometer to polaroid-mid2407pxe03

Icenowy Zheng (2):
  ARM: dts: sun8i: add pinmux for UART1 at PG
  ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board

Jerome Brunet (7):
  ARM64: dts: amlogic: add spi nor pins
  ARM64: dts: meson-gxbb: add pins for I2C
  ARM64: dts: gxbb: add i2c bus
  usb: dwc2: add support for Meson8b and GXBB SoCs
  clk: gxbb: expose spifc clock
  clk: gxbb: expose i2c clocks
  ARM64: dts: meson-gxbb-p20x: Enable USB Nodes

Joachim Eastwood (1):
  stmmac: introduce get_stmmac_bsp_priv() helper

Jorik Jonker (5):
  dts: sun8i-h3: add pinmux definitions for UART2-3
  dts: sun8i-h3: split off RTS/CTS for UART1 in seperate pinmux
  dts: sun8i-h3: associate exposed UARTs on Orange Pi Boards
  dts: sun8i-h3: add pinmux definitions for I2C0-2
  dts: sun8i-h3: add I2C0-2 peripherals to H3 SOC

Kevin Hilman (7):
  ARM64: DTS: meson-gxbb: switch ethernet to real clock
  Merge branch 'clk-meson-gxbb-ao' of git://git.kernel.org/.../clk/linux 
into v4.8/dt64
  ARM64: dts: amlogic: add the input pin for the IR remote
  ARM64: dts: meson-gxbb: Add PWM pinctrl nodes
  Merge branch 'clk-meson-gxbb' of git://git.kernel.org/.../clk/linux into 
v4.8/drivers
  Merge tag 'amlogic-drivers-2' into v4.8/dt64-2
  Merge branch 'v4.8/dt64' into v4.8/dt64-2

Re: [PATCH 4/10] MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers

[Ziji Hu]

Hi Joe,

On 2016/10/8 4:44, Joe Perches wrote:
> On Fri, 2016-10-07 at 17:22 +0200, Gregory CLEMENT wrote:
>> Add maintainer entry for Marvell Xenon eMMC/SD/SDIO Host
>> Controller drivers.
> []
>> diff --git a/MAINTAINERS b/MAINTAINERS
> []
>> @@ -7578,6 +7578,11 @@ M:Nicolas Pitre 
>>  S:  Odd Fixes
>>  F:  drivers/mmc/host/mvsdio.*
>>  
>> +MARVELL XENON MMC/SD/SDIO HOST CONTROLLER DRIVER
>> +M:  Ziji Hu 
>> +L:  linux-...@vger.kernel.org
>> +S:  Supported
> 
> You should really add F: file patterns here
> 
The specific file patterns will be added later when the corresponding 
file is included in patch.
Otherwise, it cannot pass checkpatch.pl.

Thank you.

Best regards,
Hu Ziji

Re: [PATCH 01/01] drivers:input:byd fix greedy detection of Sentelic FSP by the BYD touchpad driver

[Christophe Tordeux]

Hello,

On Friday 07 October 2016 at 04:37:26PM, Dmitry Torokhov has written:
> Hi Christophe,
> 
> On Fri, Oct 07, 2016 at 12:41:48PM +0800, Christophe Tordeux wrote:
> > From: Christophe TORDEUX 
> > 
> > With kernel v4.6 and later, the Sentelic touchpad STL3888_C0 and
> > probably other Sentelic FSP touchpads are detected as a BYD touchpad and
> > lose multitouch features.
> > 
> > During the BYD handshake in the byd_detect function, the BYD driver
> > mistakenly interprets a standard PS/2 protocol status request answer
> > from the Sentelic touchpad as a successful handshake with a BYD
> > touchpad. This is clearly a bug of the BYD driver.
> > 
> > Description of the patch: In byd_detect function, remove positive
> > detection result based on standard PS/2 protocol status request answer.
> > Replace it with positive detection based on handshake answers as they
> > can be inferred from the BYD touchpad datasheets found on BYD website.
> > 
> > Signed-off-by: Christophe TORDEUX 
> 
> What devices was this tested on? Do you have both BYD and Sentelic
> devices?
> 

I only have a Sentelic STL3888_C0 touchpad, I don't have any BYD 
touchpad.

> I am really concerned about docs on BYD side as they seem to contradict
> each other... I wonder how accurate they are.
> 

I agree, there's problems with each of their docs. I tried to infer the 
handshake answers based on the big picture that seems to emerge when 
reading all of them.

If ever that matters, I found out that my STL3888_C0 touchpad:
* answers E8/03/E8/03/E8/03/E8/03/E9 like standard PS/2 protocol
* answers E8/00/E8/00/E8/00/E8/00/E9 with 00/88/64

The latter does not look standard PS/2 so may be a kind of handshake 
from the Sentelic touchpad. And, in the BYD docs, part of the BYD 
devices also call for 00 during the handshake, others call for 03.

Things which can be considered in addition or in parallel to my patch:

1) in psmouse-base.c, move the detection of Sentelic touchpads above the 
detection of BYD touchpads. However based on the code comments could 
have adverse effects I don't know about.

2) Exit the byd_detect function without detection based on 
E8/00/E8/00/E8/00/E8/00/E9 being answered by 00/88/64. However while it 
would certainly fix my issue with my particular touchpad, it still would
leaves the byd_detect function being dirty and greedy otherwise, so I 
don't really like it.

3) take my patch, keep the 00 and 03 handshakes in sequence, add a 
detection based on the first byte of data being 01 regardless of the 
other bytes of data in the answer. It would probably fix the Sentelic 
detection issue... unless the user is pressing the left button during 
the BYD handshake. From the BYD docs "it is expected the get the value 
of 01 in the first byte data (...) and the first byte data is the only 
data needed to be checked". The issue with the docs is that this 
statement is sometimes contradicted by the sketch of the handshake... My 
patch is mostly based on the handshake sketches currently, but I could 
add a detection based on the first byte being 01, with no other test.

Let me know what looks best for you, for me the third choice is probably 
the most reasonable solution, either this or do it like in my initial 
patch.  If you know someone who has the kernel sources and a BYD 
touchpad, ask him to get the answer to E8/00/E8/00/E8/00/E8/00/E9 from 
BYD touchpads.

> Thanks.
> 
> > 
> > ---
> > Resubmitting this patch because I got no feedback on my first 
> > submission.
> > Fixes kernel bug 175421 which is impacting multiple users.
> > 
> > ---
> >  drivers/input/mouse/byd.c | 76 
> >  ++-
> >  1 file changed, 62 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/input/mouse/byd.c b/drivers/input/mouse/byd.c
> > index b27aa63..b5acca0 100644
> > --- a/drivers/input/mouse/byd.c
> > +++ b/drivers/input/mouse/byd.c
> > @@ -35,6 +35,18 @@
> >   * BYD pad constants
> >   */
> >  
> > +/* Handshake answer of BTP6034 */
> > +#define BYD_MODEL_BTP6034  0x00E801
> > +/* Handshake answer of BTP6740 */
> > +#define BYD_MODEL_BTP6740  0x001155
> > +/* Handshake answers of BTP8644, BTP10463 and BTP11484 */
> > +#define BYD_MODEL_BTP8644  0x011155
> > +
> > +/* Handshake SETRES byte of BTP6034 and BTP6740 */
> > +#define BYD_SHAKE_BYTE_A   0x00
> > +/* Handshake SETRES byte of BTP8644, BTP10463 and BTP11484 */
> > +#define BYD_SHAKE_BYTE_B   0x03
> > +
> >  /*
> >   * True device resolution is unknown, however experiments show the
> >   * resolution is about 111 units/mm.
> > @@ -434,23 +446,59 @@ static void byd_disconnect(struct psmouse *psmouse)
> > }
> >  }
> >  
> > +u32 byd_try_model(u32 model)
> > +{
> > +   size_t i;
> > +
> > +   u32 byd_model[] = {
> > +   BYD_MODEL_BTP6034,
> > +   BYD_MODEL_BTP6740,
> > +   BYD_MODEL_BTP8644
> > +   };
> > +
> > +   for (i=0; i < ARRAY_SIZE(byd_model); i++) {
> > +

[PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage

[Jarod Wilson]

With centralized MTU checking, there's nothing productive done by
eth_change_mtu that isn't already done in dev_set_mtu, so mark it as
deprecated and remove all usage of it in the kernel. All callers have been
audited for calls to alloc_etherdev* or ether_setup directly, which means
they all have a valid dev->min_mtu and dev->max_mtu. Now eth_change_mtu
prints out a netdev_warn about being deprecated, for the benefit of
out-of-tree drivers that might be utilizing it.

Of note, dvb_net.c actually had dev->mtu = 4096, while using
eth_change_mtu, meaning that if you ever tried changing it's mtu, you
couldn't set it above 1500 anymore. It's now getting dev->max_mtu also set
to 4096 to remedy that.

v2: fix up lantiq_etop, missed breakage due to drive not compiling on x86

CC: net...@vger.kernel.org
Signed-off-by: Jarod Wilson 
---
 arch/m68k/emu/nfeth.c |  1 -
 drivers/isdn/hysdn/hysdn_net.c|  1 -
 drivers/media/dvb-core/dvb_net.c  |  2 +-
 drivers/net/appletalk/ipddp.c |  1 -
 drivers/net/cris/eth_v10.c|  1 -
 drivers/net/ethernet/3com/3c509.c |  1 -
 drivers/net/ethernet/3com/3c515.c |  1 -
 drivers/net/ethernet/3com/3c574_cs.c  |  1 -
 drivers/net/ethernet/3com/3c589_cs.c  |  1 -
 drivers/net/ethernet/3com/3c59x.c |  2 --
 drivers/net/ethernet/3com/typhoon.c   |  1 -
 drivers/net/ethernet/8390/8390.c  |  1 -
 drivers/net/ethernet/8390/8390p.c |  1 -
 drivers/net/ethernet/8390/ax88796.c   |  1 -
 drivers/net/ethernet/8390/axnet_cs.c  |  1 -
 drivers/net/ethernet/8390/etherh.c|  1 -
 drivers/net/ethernet/8390/hydra.c |  1 -
 drivers/net/ethernet/8390/mac8390.c   |  1 -
 drivers/net/ethernet/8390/mcf8390.c   |  1 -
 drivers/net/ethernet/8390/ne2k-pci.c  |  1 -
 drivers/net/ethernet/8390/pcnet_cs.c  |  1 -
 drivers/net/ethernet/8390/smc-ultra.c |  1 -
 drivers/net/ethernet/8390/wd.c|  1 -
 drivers/net/ethernet/8390/zorro8390.c |  1 -
 drivers/net/ethernet/adaptec/starfire.c   |  1 -
 drivers/net/ethernet/adi/bfin_mac.c   |  1 -
 drivers/net/ethernet/allwinner/sun4i-emac.c   |  1 -
 drivers/net/ethernet/amd/a2065.c  |  1 -
 drivers/net/ethernet/amd/am79c961a.c  |  1 -
 drivers/net/ethernet/amd/ariadne.c|  1 -
 drivers/net/ethernet/amd/atarilance.c |  1 -
 drivers/net/ethernet/amd/au1000_eth.c |  1 -
 drivers/net/ethernet/amd/declance.c   |  1 -
 drivers/net/ethernet/amd/hplance.c|  1 -
 drivers/net/ethernet/amd/lance.c  |  1 -
 drivers/net/ethernet/amd/mvme147.c|  1 -
 drivers/net/ethernet/amd/ni65.c   |  1 -
 drivers/net/ethernet/amd/nmclan_cs.c  |  1 -
 drivers/net/ethernet/amd/pcnet32.c|  1 -
 drivers/net/ethernet/amd/sun3lance.c  |  1 -
 drivers/net/ethernet/amd/sunlance.c   |  1 -
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c  |  1 -
 drivers/net/ethernet/apple/bmac.c |  1 -
 drivers/net/ethernet/apple/mace.c |  1 -
 drivers/net/ethernet/apple/macmace.c  |  1 -
 drivers/net/ethernet/aurora/nb8800.c  |  1 -
 drivers/net/ethernet/cadence/macb.c   |  1 -
 drivers/net/ethernet/cirrus/cs89x0.c  |  1 -
 drivers/net/ethernet/cirrus/ep93xx_eth.c  |  1 -
 drivers/net/ethernet/cirrus/mac89x0.c |  1 -
 drivers/net/ethernet/davicom/dm9000.c |  1 -
 drivers/net/ethernet/dec/tulip/de2104x.c  |  1 -
 drivers/net/ethernet/dec/tulip/de4x5.c|  1 -
 drivers/net/ethernet/dec/tulip/dmfe.c |  1 -
 drivers/net/ethernet/dec/tulip/tulip_core.c   |  1 -
 drivers/net/ethernet/dec/tulip/uli526x.c  |  1 -
 drivers/net/ethernet/dec/tulip/winbond-840.c  |  1 -
 drivers/net/ethernet/dec/tulip/xircom_cb.c|  1 -
 drivers/net/ethernet/dnet.c   |  1 -
 drivers/net/ethernet/ec_bhf.c |  1 -
 drivers/net/ethernet/fealnx.c |  1 -
 drivers/net/ethernet/freescale/fec_main.c |  1 -
 drivers/net/ethernet/freescale/fec_mpc52xx.c  |  1 -
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c |  1 -
 drivers/net/ethernet/freescale/ucc_geth.c |  1 -
 drivers/net/ethernet/fujitsu/fmvj18x_cs.c |  1 -
 drivers/net/ethernet/hisilicon/hip04_eth.c 

[PATCH v3 net-next 1/2] net: centralize net_device min/max MTU checking

[Jarod Wilson]

While looking into an MTU issue with sfc, I started noticing that almost
every NIC driver with an ndo_change_mtu function implemented almost
exactly the same range checks, and in many cases, that was the only
practical thing their ndo_change_mtu function was doing. Quite a few
drivers have either 68, 64, 60 or 46 as their minimum MTU value checked,
and then various sizes from 1500 to 65535 for their maximum MTU value. We
can remove a whole lot of redundant code here if we simple store min_mtu
and max_mtu in net_device, and check against those in net/core/dev.c's
dev_set_mtu().

In theory, there should be zero functional change with this patch, it just
puts the infrastructure in place. Subsequent patches will attempt to start
using said infrastructure, with theoretically zero change in
functionality.

CC: net...@vger.kernel.org
Signed-off-by: Jarod Wilson 
---
v3: retain new_mtu < 0 check to prevent integral promotions,
as pointed out by Jakub Sitnicki.

 include/linux/netdevice.h |  4 
 net/core/dev.c| 13 +++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 136ae6bb..fbdf923 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1506,6 +1506,8 @@ enum netdev_priv_flags {
  * @if_port:   Selectable AUI, TP, ...
  * @dma:   DMA channel
  * @mtu:   Interface MTU value
+ * @min_mtu:   Interface Minimum MTU value
+ * @max_mtu:   Interface Maximum MTU value
  * @type:  Interface hardware type
  * @hard_header_len: Maximum hardware header length.
  *
@@ -1726,6 +1728,8 @@ struct net_device {
unsigned char   dma;
 
unsigned intmtu;
+   unsigned intmin_mtu;
+   unsigned intmax_mtu;
unsigned short  type;
unsigned short  hard_header_len;
 
diff --git a/net/core/dev.c b/net/core/dev.c
index f1fe26f..f376639 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6499,9 +6499,18 @@ int dev_set_mtu(struct net_device *dev, int new_mtu)
if (new_mtu == dev->mtu)
return 0;
 
-   /*  MTU must be positive.*/
-   if (new_mtu < 0)
+   /* MTU must be positive, and in range */
+   if (new_mtu < 0 || new_mtu < dev->min_mtu) {
+   net_err_ratelimited("%s: Invalid MTU %d requested, hw min %d\n",
+   dev->name, new_mtu, dev->min_mtu);
return -EINVAL;
+   }
+
+   if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
+   net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
+   dev->name, new_mtu, dev->min_mtu);
+   return -EINVAL;
+   }
 
if (!netif_device_present(dev))
return -ENODEV;
-- 
2.10.0

Re: [PATCH v2 00/18] perf clang: Support compiling BPF script on the fly

[Wangnan (F)]

On 2016/10/6 7:20, Arnaldo Carvalho de Melo wrote:

Em Mon, Sep 26, 2016 at 07:26:54AM +, Wang Nan escreveu:

This patch add builtin clang, allow perf compile BPF scripts on the fly.
This is the first step to implement what I announced at LinuxCon 2016 NA:

Ok, so I refreshed this series to apply against my latest perf/core and
put it in a tmp.perf/builtin-clang, will continue testing it tomorrow
after checking if fedora24 has those llvm-dev and libclang-dev that can
be used with this, do you know if it works on that distro?


Sorry for the late. I only tested on ubuntu.

I can see a llvm-static package for fedora:

https://apps.fedoraproject.org/packages/llvm-static/

but for clang I can find only dynamic libraries:

https://apps.fedoraproject.org/packages/clang-libs/

I think we can make it work by changing 'libclang$(l).a'
to 'libclang$(l).so' in commit 1125e7f6cf29.

Thank you.

[PATCH v3 net-next 0/2] net: centralize net_device MTU bounds checking

[Jarod Wilson]

Jarod Wilson (2):
  net: centralize net_device min/max MTU checking
  net: deprecate eth_change_mtu, remove usage

While looking into an MTU issue with sfc, I started noticing that almost
every NIC driver with an ndo_change_mtu function implemented almost
exactly the same range checks, and in many cases, that was the only
practical thing their ndo_change_mtu function was doing. Quite a few
drivers have either 68, 64, 60 or 46 as their minimum MTU value checked,
and then various sizes from 1500 to 65535 for their maximum MTU value. We
can remove a whole lot of redundant code here if we simple store min_mtu
and max_mtu in net_device, and check against those in net/core/dev.c's
dev_set_mtu().

This pair of patches looks to introduce centralized MTU range checking
infrastructure, while maintaining compatibility with all existing drivers,
and start to make use of it, converting all eth_change_mtu/ether_setup users
over to this new infra.

Assuming these pass review muster, I've got a ton of follow-on patches to
clean up MTU settings for everything in the kernel with an ndo_change_mtu.

This work is all staged in a (rebasing) git tree here:

https://github.com/jarodwilson/linux-muck

The master branch is based on net-next from Oct 7, and carries these two
patches, plus a ton of follow-on patches to eliminate MTU range checks
and change_mtu functions where possible. All patches were successfully
built across 160 various arch and config combos by the 0-day folks.
(Thanks to Andrew Lunn for the suggestion to get that going).

Jarod Wilson (2):
  net: centralize net_device min/max MTU checking
  net: deprecate eth_change_mtu, remove usage

CC: net...@vger.kernel.org
-- 
2.10.0

[PATCH v1 0/6] PMC Core driver new features

[Rajneesh Bhardwaj]

This patch series adds few new features to the Intel PMC Core driver
applicable for Skylake & Kabylake SoCs with Sunrise Point LP PCH. These new
features enhance the low power debug capabilities on Intel platforms. These
debug features can be used for platform power optimization. Please refer to
the commit messages of the individual patches and the 7th Generation Intel
Processor Families I/O for U/Y Platforms datasheet for more documentation.

New debug features:

1. PCH IP Power Gating Status
2. ModPhy Core Lanes Power Gating Status
3. ModPhy PLL (Common Lanes) clock Gating Status
4. LTR Ignore feature
5. Support for Kabylake SoC

Rajneesh Bhardwaj (6):
  intel_pmc_core: Fix PWRMBASE mask and mmio reg len
  intel_pmc_core: Add PCH IP Power Gating Status
  intel_pmc_core: ModPhy core lanes pg status
  intel_pmc_core: Add MPHY PLL clock gating status
  intel_pmc_core: Add LTR IGNORE debug feature
  intel_pmc_core: Add KBL CPUID support

 drivers/platform/x86/intel_pmc_core.c | 386 +-
 drivers/platform/x86/intel_pmc_core.h | 110 +-
 2 files changed, 490 insertions(+), 6 deletions(-)

-- 
1.9.1

[PATCH v1 3/6] intel_pmc_core: ModPhy core lanes pg status

[Rajneesh Bhardwaj]

The PCH implements a number of High Speed I/O (HSIO) lanes that are split
between PCIe*, USB 3.0, SATA, GbE, USB OTG and SSIC. This patch shows the
current power gating status of the available ModPhy Core lanes. This is
done by sending a message to the PMC (MTPMC) that contains the XRAM
register offset for the MPHY_CORE_STS_0 and MPHY_CORE_STS_1 and then by
reading the response sent by the PMC (MFPMC).

While enabling low power modes we often encounter situations when the
ModPhy lanes are not power gated and it becomes hard to debug which lane is
active and which is not in the absence of an external hardware debugger
(JTAG/ITP). This patch eliminates the dependency on an external hardware
debugger for reading the ModPhy Lanes power gating status.

This patch requires PMC_READ_DISABLE setting to be disabled in the platform
bios.

cat /sys/kernel/debug/pmc_core/mphy_lanes_power_gating_status

Signed-off-by: Rajneesh Bhardwaj 
---
 drivers/platform/x86/intel_pmc_core.c | 145 +-
 drivers/platform/x86/intel_pmc_core.h |  31 
 2 files changed, 175 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index d5efd6d..9245bc8 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -32,6 +33,26 @@
 
 static struct pmc_dev pmc;
 
+static const struct pmc_bit_map spt_mphy_map[] = {
+   {"MPHY CORE LANE 0",   SPT_PMC_BIT_MPHY_LANE0},
+   {"MPHY CORE LANE 1",   SPT_PMC_BIT_MPHY_LANE1},
+   {"MPHY CORE LANE 2",   SPT_PMC_BIT_MPHY_LANE2},
+   {"MPHY CORE LANE 3",   SPT_PMC_BIT_MPHY_LANE3},
+   {"MPHY CORE LANE 4",   SPT_PMC_BIT_MPHY_LANE4},
+   {"MPHY CORE LANE 5",   SPT_PMC_BIT_MPHY_LANE5},
+   {"MPHY CORE LANE 6",   SPT_PMC_BIT_MPHY_LANE6},
+   {"MPHY CORE LANE 7",   SPT_PMC_BIT_MPHY_LANE7},
+   {"MPHY CORE LANE 8",   SPT_PMC_BIT_MPHY_LANE8},
+   {"MPHY CORE LANE 9",   SPT_PMC_BIT_MPHY_LANE9},
+   {"MPHY CORE LANE 10",  SPT_PMC_BIT_MPHY_LANE10},
+   {"MPHY CORE LANE 11",  SPT_PMC_BIT_MPHY_LANE11},
+   {"MPHY CORE LANE 12",  SPT_PMC_BIT_MPHY_LANE12},
+   {"MPHY CORE LANE 13",  SPT_PMC_BIT_MPHY_LANE13},
+   {"MPHY CORE LANE 14",  SPT_PMC_BIT_MPHY_LANE14},
+   {"MPHY CORE LANE 15",  SPT_PMC_BIT_MPHY_LANE15},
+   {},
+};
+
 static const struct pmc_bit_map spt_pfear_map[] = {
{"PMC", SPT_PMC_BIT_PMC},
{"OPI-DMI", SPT_PMC_BIT_OPI},
@@ -78,6 +99,7 @@ static const struct pmc_bit_map spt_pfear_map[] = {
 
 static const struct pmc_reg_map spt_reg_map = {
.pfear_sts = spt_pfear_map,
+   .mphy_sts = spt_mphy_map,
 };
 
 static const struct pci_device_id pmc_pci_ids[] = {
@@ -96,6 +118,12 @@ static inline u32 pmc_core_reg_read(struct pmc_dev *pmcdev, 
int reg_offset)
return readl(pmcdev->regbase + reg_offset);
 }
 
+static inline void pmc_core_reg_write(struct pmc_dev *pmcdev, int
+   reg_offset, u32 val)
+{
+   writel(val, pmcdev->regbase + reg_offset);
+}
+
 static inline u32 pmc_core_adjust_slp_s0_step(u32 value)
 {
return value * SPT_PMC_SLP_S0_RES_COUNTER_STEP;
@@ -144,6 +172,16 @@ static int pmc_core_dev_state_get(void *data, u64 *val)
 
 DEFINE_DEBUGFS_ATTRIBUTE(pmc_core_dev_state, pmc_core_dev_state_get, NULL, 
"%llu\n");
 
+static int pmc_core_check_read_lock_bit(void)
+{
+   struct pmc_dev *pmcdev = 
+   u32 value;
+
+   value = pmc_core_reg_read(pmcdev, SPT_PMC_PM_CFG_OFFSET);
+   return test_bit(SPT_PMC_READ_DISABLE_BIT,
+   (unsigned long *));
+}
+
 #if IS_ENABLED(CONFIG_DEBUG_FS)
 static void pmc_core_display_map(struct seq_file *s, int index,
 u8 pf_reg, const struct pmc_bit_map *pf_map)
@@ -183,6 +221,102 @@ static const struct file_operations pmc_core_ppfear_ops = 
{
.release= single_release,
 };
 
+/* This function should return link status, 0 means ready */
+static int pmc_core_mtpmc_link_status(void)
+{
+   struct pmc_dev *pmcdev = 
+   u32 value;
+
+   value = pmc_core_reg_read(pmcdev, SPT_PMC_PM_STS_OFFSET);
+   return test_bit(SPT_PMC_MSG_FULL_STS_BIT,
+   (unsigned long *));
+}
+
+static int pmc_core_send_msg(u32 *addr_xram)
+{
+   struct pmc_dev *pmcdev = 
+   u32 dest;
+   int timeout;
+
+   for (timeout = NUM_RETRIES; timeout > 0; timeout--) {
+   if (pmc_core_mtpmc_link_status() == 0)
+   break;
+   msleep(5);
+   }
+
+   if (timeout <= 0 && pmc_core_mtpmc_link_status())
+   return -EBUSY;
+
+   dest = 

[PATCH v1 4/6] intel_pmc_core: Add MPHY PLL clock gating status

[Rajneesh Bhardwaj]

ModPhy Common lanes can provide the clock gating status for the important
system PLLs such as Gen2 USB3PCIE2 PLL, DMIPCIE3 PLL, SATA PLL and MIPI
PLL.

On SPT, in addition to the crystal oscillator clock, the 100Mhz Gen2
USB3PCI2 PLL clock is used as the PLL reference clock and Gen2 PLL idling
is a necessary condition for the platform to go into low power states like
PC10 and S0ix.

Signed-off-by: Rajneesh Bhardwaj 
---
 drivers/platform/x86/intel_pmc_core.c | 63 ++-
 drivers/platform/x86/intel_pmc_core.h |  7 
 2 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index 9245bc8..4840158 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -33,6 +33,14 @@
 
 static struct pmc_dev pmc;
 
+static const struct pmc_bit_map spt_pll_map[] = {
+   {"MIPI PLL",SPT_PMC_BIT_MPHY_CMN_LANE0},
+   {"GEN2 USB2PCIE2 PLL",  SPT_PMC_BIT_MPHY_CMN_LANE1},
+   {"DMIPCIE3 PLL",SPT_PMC_BIT_MPHY_CMN_LANE2},
+   {"SATA PLL",SPT_PMC_BIT_MPHY_CMN_LANE3},
+   {},
+};
+
 static const struct pmc_bit_map spt_mphy_map[] = {
{"MPHY CORE LANE 0",   SPT_PMC_BIT_MPHY_LANE0},
{"MPHY CORE LANE 1",   SPT_PMC_BIT_MPHY_LANE1},
@@ -100,6 +108,7 @@ static const struct pmc_bit_map spt_pfear_map[] = {
 static const struct pmc_reg_map spt_reg_map = {
.pfear_sts = spt_pfear_map,
.mphy_sts = spt_mphy_map,
+   .pll_sts = spt_pll_map,
 };
 
 static const struct pci_device_id pmc_pci_ids[] = {
@@ -317,6 +326,53 @@ static const struct file_operations pmc_core_mphy_pg_ops = 
{
.release= single_release,
 };
 
+static int pmc_core_pll_show(struct seq_file *s, void *unused)
+{
+   struct pmc_dev *pmcdev = s->private;
+   const struct pmc_bit_map *map = pmcdev->map->pll_sts;
+   u32 mphy_common_reg, val;
+   int index, err = 0;
+
+   if (pmcdev->pmc_xram_read_bit) {
+   seq_puts(s, "Access denied: please disable PMC_READ_DISABLE 
setting in BIOS.");
+   return 0;
+   }
+
+   mphy_common_reg  = (SPT_PMC_MPHY_COM_STS_0 << 16);
+   mutex_lock(>lock);
+
+   if (pmc_core_send_msg(_common_reg) != 0) {
+   err = -EBUSY;
+   goto out_unlock;
+   }
+
+   /* Observed PMC HW response latency for MTPMC-MFPMC is ~10 ms */
+   msleep(10);
+   val = pmc_core_reg_read(pmcdev, SPT_PMC_MFPMC_OFFSET);
+
+   for (index = 0; map[index].name ; index++) {
+   seq_printf(s, "%-32s\tState: %s\n",
+  map[index].name,
+  map[index].bit_mask & val ? "Active" : "Idle");
+   }
+
+out_unlock:
+   mutex_unlock(>lock);
+   return err;
+}
+
+static int pmc_core_pll_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, pmc_core_pll_show, inode->i_private);
+}
+
+static const struct file_operations pmc_core_pll_ops = {
+   .open   = pmc_core_pll_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
 static void pmc_core_dbgfs_unregister(struct pmc_dev *pmcdev)
 {
debugfs_remove_recursive(pmcdev->dbgfs_dir);
@@ -348,8 +404,13 @@ static int pmc_core_dbgfs_register(struct pmc_dev *pmcdev)
if (!file)
goto err;
 
-   return 0;
+   file = debugfs_create_file("pll_status",
+  S_IFREG | S_IRUGO, dir, pmcdev,
+  _core_pll_ops);
+   if (!file)
+   goto err;
 
+   return 0;
 err:
pmc_core_dbgfs_unregister(pmcdev);
return -ENODEV;
diff --git a/drivers/platform/x86/intel_pmc_core.h 
b/drivers/platform/x86/intel_pmc_core.h
index 62fe5d1..07161fb 100644
--- a/drivers/platform/x86/intel_pmc_core.h
+++ b/drivers/platform/x86/intel_pmc_core.h
@@ -32,6 +32,7 @@
 #define SPT_PMC_MFPMC_OFFSET   0x38
 #define SPT_PMC_MPHY_CORE_STS_00x1143
 #define SPT_PMC_MPHY_CORE_STS_10x1142
+#define SPT_PMC_MPHY_COM_STS_0 0x1155
 #define SPT_PMC_MMIO_REG_LEN   0x1000
 #define SPT_PMC_SLP_S0_RES_COUNTER_STEP0x64
 #define PMC_BASE_ADDR_MASK ~(SPT_PMC_MMIO_REG_LEN - 1)
@@ -113,6 +114,11 @@ enum ppfear_regs {
 #define SPT_PMC_BIT_MPHY_LANE14BIT(6)
 #define SPT_PMC_BIT_MPHY_LANE15BIT(7)
 
+#define SPT_PMC_BIT_MPHY_CMN_LANE0 BIT(0)
+#define SPT_PMC_BIT_MPHY_CMN_LANE1 BIT(1)
+#define SPT_PMC_BIT_MPHY_CMN_LANE2 BIT(2)
+#define SPT_PMC_BIT_MPHY_CMN_LANE3 BIT(3)
+
 struct pmc_bit_map {
const char *name;
u32 bit_mask;
@@ -121,6 +127,7 @@ 

[PATCH v1 5/6] intel_pmc_core: Add LTR IGNORE debug feature

[Rajneesh Bhardwaj]

SPT LTR_IGN register provides a means to make the PMC ignore the LTR values
reported by the individual PCH devices.

echo  > /sys/kernel/debug/pmc_core/ltr_ignore.

When a particular IP Offset bit is set the PMC will ignore the LTR value
reported by the corresponding IP when the PMC performs the latency
coalescing.

IP Offset   IP Name
0   SPA
1   SPB
2   SATA
3   GBE
4   XHCI
5   RSVD
6   ME
7   EVA
8   SPC
9   Azalia/ADSP
10  RSVD
11  LPSS
12  SPD
13  SPE
14  Camera
15  ESPI
16  SCC
17  ISH

Signed-off-by: Rajneesh Bhardwaj 
---
 drivers/platform/x86/intel_pmc_core.c | 57 ++-
 drivers/platform/x86/intel_pmc_core.h |  2 ++
 2 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index 4840158..5b867b7 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -19,11 +19,12 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
@@ -373,6 +374,53 @@ static const struct file_operations pmc_core_pll_ops = {
.release= single_release,
 };
 
+static ssize_t pmc_core_ltr_ignore_write(struct file *file, const char __user
+*userbuf, size_t count, loff_t *ppos)
+{
+   u32 val, buf_size, fd;
+   int err = 0;
+   struct pmc_dev *pmcdev = 
+
+   buf_size = count < 64 ? count : 64;
+   mutex_lock(>lock);
+
+   if (kstrtou32_from_user(userbuf, buf_size, 10, )) {
+   err = -EFAULT;
+   goto out_unlock;
+   }
+
+   if (val > NUM_IP_IGN_ALLOWED) {
+   err = -EINVAL;
+   goto out_unlock;
+   }
+
+   fd = pmc_core_reg_read(pmcdev, SPT_PMC_LTR_IGNORE_OFFSET);
+   fd |= (1U << val);
+   pmc_core_reg_write(pmcdev, SPT_PMC_LTR_IGNORE_OFFSET, fd);
+
+out_unlock:
+   mutex_unlock(>lock);
+   return err == 0 ? count : err;
+}
+
+static int pmc_core_ltr_ignore_show(struct seq_file *s, void *unused)
+{
+   return 0;
+}
+
+static int pmc_core_ltr_ignore_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, pmc_core_ltr_ignore_show, inode->i_private);
+}
+
+static const struct file_operations pmc_core_ltr_ignore_ops = {
+   .open   = pmc_core_ltr_ignore_open,
+   .read   = seq_read,
+   .write  = pmc_core_ltr_ignore_write,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
 static void pmc_core_dbgfs_unregister(struct pmc_dev *pmcdev)
 {
debugfs_remove_recursive(pmcdev->dbgfs_dir);
@@ -410,6 +458,13 @@ static int pmc_core_dbgfs_register(struct pmc_dev *pmcdev)
if (!file)
goto err;
 
+   file = debugfs_create_file("ltr_ignore",
+  S_IFREG | S_IRUGO, dir, pmcdev,
+  _core_ltr_ignore_ops);
+
+   if (!file)
+   goto err;
+
return 0;
 err:
pmc_core_dbgfs_unregister(pmcdev);
diff --git a/drivers/platform/x86/intel_pmc_core.h 
b/drivers/platform/x86/intel_pmc_core.h
index 07161fb..5a48e77 100644
--- a/drivers/platform/x86/intel_pmc_core.h
+++ b/drivers/platform/x86/intel_pmc_core.h
@@ -30,6 +30,7 @@
 #define SPT_PMC_PM_STS_OFFSET  0x1c
 #define SPT_PMC_MTPMC_OFFSET   0x20
 #define SPT_PMC_MFPMC_OFFSET   0x38
+#define SPT_PMC_LTR_IGNORE_OFFSET  0x30C
 #define SPT_PMC_MPHY_CORE_STS_00x1143
 #define SPT_PMC_MPHY_CORE_STS_10x1142
 #define SPT_PMC_MPHY_COM_STS_0 0x1155
@@ -41,6 +42,7 @@
 #define SPT_PMC_READ_DISABLE_BIT   0x16
 #define SPT_PMC_MSG_FULL_STS_BIT   0x18
 #define NUM_RETRIES100
+#define NUM_IP_IGN_ALLOWED 17
 
 /* Sunrise Point: PGD PFET Enable Ack Status Registers */
 enum ppfear_regs {
-- 
1.9.1