Re: [PATCH v3 01/10] tracing: Update cond flag when enabling or disabling a trigger

[Daniel Wagner]

On 06/13/2015 10:45 AM, Daniel Wagner wrote:
> On 06/12/2015 06:01 PM, Steven Rostedt wrote:
>>> Signed-off-by: Tom Zanussi 
>>> Signed-off-by: Daniel Wagner 
>>
>> Why is Daniel signed off by here?
> 
> I have reported the issue and send a fix for this patch
> 
> https://lkml.org/lkml/2015/4/21/161
> 
> I would have complained if I wasn't okay with it.

Finally, have access to this account again. Let's do it proper:

Signed-off-by: Daniel Wagner 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/3] IRQ/Gic-V3: Change arm-gic-its to support the Mbigen interrupt

[majun (F)]

在 2015/6/12 18:48, Thomas Gleixner 写道:
> On Fri, 12 Jun 2015, Ma Jun wrote:
> 
>> This patch is applied to support the mbigen interrupt.
>>
>> As a kind of MSI interrupt controller, the mbigen is used as a child 
>> domain of ITS domain just like PCI devices.
>> So the arm-gic-v3-its and related files are changed.
>>
>> The chip.c is also changed to check irq_ach before it called.
> 
> This patch wants to be split into several:
> 
> 1) Changes to the core code
> 
> 2) New functionality in the core code
> 
> 2) Changes to gic-v3-its
> 
> And all patches require proper changelogs which explain WHY these
> changes are necessary.
> 
> We can see which files are changed from the diffstat and the patch
> ourself. So no point to mention this in the changelog.
> 
> But we cannot figure out from looking at the code WHY you think that
> your approach to solve the problem is the right one.
> 
>>  void irq_chip_ack_parent(struct irq_data *data)
>>  {
>>  data = data->parent_data;
>> -data->chip->irq_ack(data);
>> +if (data->chip->irq_ack)
>> +data->chip->irq_ack(data);
> 
> Why is this required? Just because? Again, you fail to provide a
> rationale for the changes to the irq_chip*parent() functions.
> 
> Why would you call irq_chip_ack_parent() if that parent does not
> provide the required functionality in the first place?
> 

Yes, this is not a necessary callback. I will remove this callback
from mbigen driver.

>>  /*
>> @@ -363,6 +364,9 @@ struct irq_chip {
>>  int (*irq_request_resources)(struct irq_data *data);
>>  void(*irq_release_resources)(struct irq_data *data);
>>  
>> +void(*irq_compose_mbigen_msg)(struct irq_data *data, struct 
>> mbigen_msg *msg);
>> +void(*irq_write_mbigen_msg)(struct irq_data *data, struct 
>> mbigen_msg *msg);
>> +
> 
> What's so special about mbigen to justify extra callbacks which just
> bloat the data structure for everyone. Why are the msi callbacks not
> sufficient?
> 
> MBI is just another variant of MSI, right?
> 
yes,MBI is a kind of MSI which used for non-pci devices.

According to Marc's advice, the irq hierachy structure
in my patch likes below:
non-pci devices-->mbigen-->its-->gic
pci devices -->msi __/

Eventhough the function *irq_compose_mbigen_msg does
the same thing as *irq_chip_compose_msi_msg, I still
added this function. Because I don't want mix the code
used by msi(pci devices) with the code used by mbigen.

> struct mbigen_msg {
>u32 address_lo;
>u32 address_hi;
>u32 data;
> };
> 
> struct mbigen_msg is just a mindless copy of struct msi_msg:
> 
> struct msi_msg {
> u32 address_lo; /* low 32 bits of msi message address */
> u32 address_hi; /* high 32 bits of msi message address */
> u32 data;   /* 16 bits of msi message data */
> };
> 
> So what's the point of this?
>

Based on the same reason, I also added  structure mbigen_msg for
mbigen using.

>>  void(*irq_compose_msi_msg)(struct irq_data *data, struct 
>> msi_msg *msg);
>>  void(*irq_write_msi_msg)(struct irq_data *data, struct 
>> msi_msg *msg);
>>  
> 
>> +
>> +/**
>> + * irq_chip_compose_mbigen_msg - Componse mbigen message for a mbigen irq 
>> chip
>> + * @data:   Pointer to interrupt specific data
>> + * @msg:Pointer to the mbigen message
>> + *
>> + * For hierarchical domains we find the first chip in the hierarchy
>> + * which implements the irq_compose_mbigen_msg callback. For non
>> + * hierarchical we use the top level chip.
>> + */
>> +
>> +int irq_chip_compose_mbigen_msg(struct irq_data *data, struct mbigen_msg 
>> *msg)
>> +{
>> +struct irq_data *pos = NULL;
>> +
>> +#ifdef  CONFIG_IRQ_DOMAIN_HIERARCHY
>> +for (; data; data = data->parent_data)
>> +#endif
>> +if (data->chip && data->chip->irq_compose_mbigen_msg)
>> +pos = data;
>> +if (!pos)
>> +return -ENOSYS;
>> +
>> +pos->chip->irq_compose_mbigen_msg(pos, msg);
>> +
>> +return 0;
>> +}
> 
> Again, this is a completely useless copy of irq_chip_compose_msi_msg().
> Why can't you just use the existing callbacks and use struct msi_msg
> for your special chip?
> 
As mentioned before, to avoid using the code of msi, i added this
function.Because they are different domain.

If you don't mind, I can use the irq_chip_compose_msi_msg function in
mbigen driver instead of irq_chip_compose_mbigen_msg.

> And w/o looking at the mbigen code in detail, I bet it's nothing else
> than MSI for non PCI devices and contains tons of redundant and copied
> code, right?
>
> Can you please provide a proper description of this mbigen chip and
> explain WHY you think that it needs all this special hackery?
> 
> Thanks,
> 
>   tglx
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordom

Re: [PATCH] m68k: Use vsprintf %pM extension

[Geert Uytterhoeven]

CC greg

On Mon, Jun 15, 2015 at 4:01 AM, Joe Perches  wrote:
> Format mac addresses with the normal kernel extension.
>
> Signed-off-by: Joe Perches 
> ---
>  arch/m68k/68000/m68EZ328.c | 3 +--
>  arch/m68k/68000/m68VZ328.c | 3 +--
>  arch/m68k/68360/config.c   | 3 +--
>  3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/m68k/68000/m68EZ328.c b/arch/m68k/68000/m68EZ328.c
> index 2195290..e6ab321 100644
> --- a/arch/m68k/68000/m68EZ328.c
> +++ b/arch/m68k/68000/m68EZ328.c
> @@ -62,8 +62,7 @@ void __init config_BSP(char *command, int len)
>  #ifdef CONFIG_UCSIMM
>printk(KERN_INFO "uCsimm serial string [%s]\n",getserialnum());
>p = cs8900a_hwaddr = gethwaddr(0);
> -  printk(KERN_INFO "uCsimm hwaddr %.2x:%.2x:%.2x:%.2x:%.2x:%.2x\n",
> - p[0], p[1], p[2], p[3], p[4], p[5]);
> +  printk(KERN_INFO "uCsimm hwaddr %pM\n", p);
>
>p = getbenv("APPEND");
>if (p) strcpy(p,command);
> diff --git a/arch/m68k/68000/m68VZ328.c b/arch/m68k/68000/m68VZ328.c
> index 0e5e5a1..1154bdb 100644
> --- a/arch/m68k/68000/m68VZ328.c
> +++ b/arch/m68k/68000/m68VZ328.c
> @@ -152,8 +152,7 @@ static void __init init_hardware(char *command, int size)
>
> printk(KERN_INFO "uCdimm serial string [%s]\n", getserialnum());
> p = cs8900a_hwaddr = gethwaddr(0);
> -   printk(KERN_INFO "uCdimm hwaddr %.2x:%.2x:%.2x:%.2x:%.2x:%.2x\n",
> -   p[0], p[1], p[2], p[3], p[4], p[5]);
> +   printk(KERN_INFO "uCdimm hwaddr %pM\n", p);
> p = getbenv("APPEND");
> if (p)
> strcpy(p, command);
> diff --git a/arch/m68k/68360/config.c b/arch/m68k/68360/config.c
> index fd1f948c..b65fe4e 100644
> --- a/arch/m68k/68360/config.c
> +++ b/arch/m68k/68360/config.c
> @@ -154,8 +154,7 @@ void __init config_BSP(char *command, int len)
>  #if defined(CONFIG_UCQUICC) && 0
>printk(KERN_INFO "uCquicc serial string [%s]\n",getserialnum());
>p = scc1_hwaddr = gethwaddr(0);
> -  printk(KERN_INFO "uCquicc hwaddr %.2x:%.2x:%.2x:%.2x:%.2x:%.2x\n",
> - p[0], p[1], p[2], p[3], p[4], p[5]);
> +  printk(KERN_INFO "uCquicc hwaddr %pM\n", p);
>
>p = getbenv("APPEND");
>if (p)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] x86: Add basic support for the Congatec CGEB BIOS interface

[Christian Gmeiner]

Hi Paul

Thanks for looking over my patches!

2015-06-12 11:35 GMT+02:00 Paul Bolle :
> A few nits.
>
> On Thu, 2015-06-11 at 22:48 +0200, Christian Gmeiner wrote:
>> --- /dev/null
>> +++ b/drivers/mfd/congatec-cgeb.c
>
>> + * 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 of the License.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>
>> +/*
>> + * cgeb_invoke - invoke CGEB BIOS call.
>
> s/cgeb_invoke/cgeb_call/
>

ok

>> + *
>> + * @board: board context data
>> + * @p: CGEB parameters for this call
>> + * @fct:   CGEB function code
>> + * @return:0 on success or negative error code on failure.
>> + *
>> + * Call the CGEB BIOS code with the given parameters.
>> + */
>> +unsigned int cgeb_call(struct cgeb_board_data *board,
>> +  struct cgeb_function_parameters *p, cgeb_function_t fct)
>> +{
>> + [...]
>> +}
>
>> +static int __init cgeb_init(void)
>> +{
>> + [...]
>> +}
>> +
>> +static void cgeb_exit(void)
>> +{
>> + [...]
>> +}
>> +
>> +module_init(cgeb_init);
>> +module_exit(cgeb_exit);
>
> cgeb_exit is only used through module_exit(). So I guess it could be
> marked __exit, right?
>

That is correct - will be fixed in v2.

>> +MODULE_LICENSE("GPL");
>
> The comment at the top of this file states the license is GPL v2. The
> MODULE_LICENSE() macro states, according to include/linux/module.h, that
> the license is GPL v2 or later. So I think one of these two needs to
> change.
>
> I spotted the same license mismatch in 2/4, 3/4 and 4/4.
>

Will be fixed in v2.

Thanks
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cris: don't use module_init for non-modular core eeprom.c code

[Jesper Nilsson]

On Sun, Jun 14, 2015 at 05:05:21PM -0400, Paul Gortmaker wrote:
> The eeprom.c code is compiled based on the Kconfig setting
> ETRAX_I2C_EEPROM, which is bool.  So the code is either built in
> or absent.  It will never be modular, so using module_init as an
> alias for __initcall is rather misleading.
> 
> Fix this up now, so that we can relocate module_init from
> init.h into module.h in the future.  If we don't do this, we'd
> have to add module.h to obviously non-modular code, and that
> would be a worse thing.
> 
> Direct use of __initcall is discouraged, vs prioritized ones.
> Use of device_initcall is consistent with what __initcall
> maps onto, and hence does not change the init order, making the
> impact of this change zero.   Should someone with real hardware
> for boot testing want to change it later to arch_initcall or
> something different, they can do that at a later date.
> 
> Cc: Mikael Starvik 

Looks good, I'll take it in the CRIS-tree.

> Cc: linux-cris-ker...@axis.com
> Signed-off-by: Paul Gortmaker 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/2] arm64: dts: mt8173: Add I2C device node

[Eddie Huang]

Hi Dan,

On Fri, 2015-06-12 at 20:28 +0800, Daniel Kurtz wrote:
> On Fri, Jun 12, 2015 at 5:27 PM, Eddie Huang  wrote:
> >
> > Add MT8173 I2C device nodes, include I2C controllers and pins.
> > MT8173 has six I2C controllers, from i2c0 to i2c6, exclude i2c5.
> > The 6th I2C controller register base doesn't next to 5th I2C,
> > and there is a hardware between 5th and 6th I2C controller. So
> > SoC designer name 6th controller as "i2c6", not "i2c5".
> 
> 
> This is slightly misleading.  There are in fact 7 I2C controllers, but
> "i2c5" is dedicated for use by HDMI for ddc & hdcp.
> Is there a reason why the HDMI I2C port cannot be controlled by the
> generic i2c driver?
> 
We add some extra HW function to HDMI I2C port, we have special driver
to control this HW, not generic I2C driver. This is why I don't count
this hardware to generic I2C controllers. 

> Of course the hdmiddc / i2c5 node can always be added in a later
> patch, so this is no reason to hold up this patch.
> 
> > Signed-off-by: Eddie Huang 
> > ---
> >  arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 50 
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi| 72 
> > +
> >  2 files changed, 122 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
> > b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > index 43d5401..2e01988 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > @@ -33,6 +33,56 @@
> > chosen { };
> >  };
> >
> > +&pio {
> 
> I don't think we needed to move these i2c pinmux descriptions from
> mt8173.dtsi to the board .dts file.
> 
> AFAICT, the "i2cN_pins_a" nodes defined here are the pinctl
> configuration that the corresponding enabled i2c nodes would choose.
> Thus, they are generic to the MT8173 SoC, not specific to any board.
> By themselves, these nodes do not actually select a pin configuration.
> 
> It is the nodes that *enable* the individual i2c nodes, and hence
> activate those pin settings, which is board specific.
> 
> Hence, if your intent is to have the evb enable all i2c nodes, it
> would have a set of nodes like this:
> 
> 
> &i2c0 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&i2c0_pins_a>;
>   status = "okay";
> };
> 
> &i2c1 {
>  pinctrl-names = "default";
>  pinctrl-0 = <&i2c1_pins_a>;
>  status = "okay";
> };
> 
> ...
> 
I personally think put I2C pins in SoC dtsi is ok because it is basic
and fixed. Almost every platform need these pins, so not necessary to
care about dtb size. And these pins are fixed. We put pins that may
change by platforms to board dts, like mmc.

> 
> > +   i2c0_pins_a: i2c0@0 {
> 
> Do these nodes need the "@0"?
> 
Will remove.

> >
> > +   pins1 {
> > +   pinmux = ,
> > +;
> > +   bias-disable;
> > +   };
> > +   };
> > +
> > +   i2c1_pins_a: i2c1@0 {
> > +   pins1 {
> > +   pinmux = ,
> > +;
> > +   bias-disable;
> > +   };
> > +   };
> > +
> > +   i2c2_pins_a: i2c2@0 {
> > +   pins1 {
> > +   pinmux = ,
> > +;
> > +   bias-disable;
> > +   };
> > +   };
> > +
> > +   i2c3_pins_a: i2c3@0 {
> > +   pins1 {
> > +   pinmux = ,
> > +;
> > +   bias-disable;
> > +   };
> > +   };
> > +
> > +   i2c4_pins_a: i2c4@0 {
> > +   pins1 {
> > +   pinmux = ,
> > +;
> > +   bias-disable;
> > +   };
> > +   };
> > +
> > +   i2c6_pins_a: i2c6@0 {
> > +   pins1 {
> > +   pinmux = ,
> > +;
> 
> These are the SDA/SCL pins for i2c port 6, so they should really be
> _SDA6 / _SCL6.
> However... I checked, and these settings are labeled "SDA5 & SCL5" in
> the datasheet.
> I recommend marking them correctly as 6 here and fixing the datasheet :-).
> 
We make mistake at the beginning not give these pins suitable name, if
we change now, it may affect already shipped products. So I tend to keep
it.

> >
> > +   bias-disable;
> > +   };
> > +   };
> > +};
> > +
> >  &uart0 {
> > status = "okay";
> >  };
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> > b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > index b52ec43..6d3dbbdd 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > @@ -229,6 +229,78 @@
> > clocks = <&uart_clk>;
> > status = "disabled";
> > };
> > +
> > +   i2c0: i2c@11007000 {
> > +  

Re: [PATCH v4 12/12] MIPS: Add basic support for the TL-WR1043ND version 1

[Antony Pavlov]

On Wed, 10 Jun 2015 23:58:11 +0200
Alban  wrote:

> On Mon, 8 Jun 2015 13:17:58 +0300
> Antony Pavlov  wrote:
> 
> > IMHO AR9132 SoC can't work without external oscilator.
> > 
> > Can we just move basic extosc declaration to SoC dt file
> > (ar9132.dtsi)? So board dt file ar9132_tl_wr1043nd_v1.dts will
> > contain only oscilator clock frequency value.
> 
> I would prefer to keep the split between the files in sync with the
> hardware. I understand that most simple board designs use a fixed
> oscillator, but that might not always be the case.
> 

The AR9132 SoC __always__ use one external oscilator. So it's reasonable
to have the first mention of extosc in ar9132.dtsi not in a board file.
This description style is always sync with hardware.
On the other hand pll-controller is always part of the SoC
not a part of a board. So pll-controller on extosc dependency
have to go to SoC dts file not to a board file. In your dts description
pll-controller is a part of a dts board file.

It looks like my previous device tree structure proposal contains a small error
(extra clock-frequency field in ar9132.dtsi). I have fixed it. Please comment 
it.

ar9132.dtsi:


extosc: oscillator {
compatible = "fixed-clock";
#clock-cells = <0>;
};
...
ahb {
apb {

...

pll-controller@1805 {
...
clocks = <&extosc>;
...



ar9132_tl_wr1043nd_v1.dts:
==

...
&extosc {
clock-frequency = <4000>;
};


-- 
-- 
Best regards,
  Antony Pavlov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] soc: Mediatek: Add SCPSYS power domain driver

[Sascha Hauer]

Hi Ulf,

On Wed, Jun 10, 2015 at 04:47:01PM +0200, Ulf Hansson wrote:
> On 9 June 2015 at 10:47, Sascha Hauer  wrote:
> > This adds a power domain driver for the Mediatek SCPSYS unit.
> >
> > The System Control Processor System (SCPSYS) has several power
> > management related tasks in the system. The tasks include thermal
> > measurement, dynamic voltage frequency scaling (DVFS), interrupt
> > filter and lowlevel sleep control. The System Power Manager (SPM)
> > inside the SCPSYS is for the MTCMOS power domain control.
> >
> > For now this driver only adds power domain support, the more
> > advanced features are not yet supported. The driver implements
> > the generic PM domain device tree bindings, the first user will
> > most likely be the Mediatek AFE audio driver.
> >
> > Signed-off-by: Sascha Hauer 
> > ---
> >  drivers/soc/mediatek/Kconfig |   9 +
> >  drivers/soc/mediatek/Makefile|   1 +
> >  drivers/soc/mediatek/mtk-scpsys.c| 490 
> > +++
> >  include/dt-bindings/power/mt8173-power.h |  15 +
> >  4 files changed, 515 insertions(+)
> >  create mode 100644 drivers/soc/mediatek/mtk-scpsys.c
> >  create mode 100644 include/dt-bindings/power/mt8173-power.h
> >
> > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> > index e4f37a3..9a61b54 100644
> > --- a/drivers/soc/mediatek/Kconfig
> > +++ b/drivers/soc/mediatek/Kconfig
> > @@ -18,3 +18,12 @@ config MTK_PMIC_WRAP
> >   Say yes here to add support for MediaTek PMIC Wrapper found
> >   on different MediaTek SoCs. The PMIC wrapper is a proprietary
> >   hardware to connect the PMIC.
> > +
> > +config MTK_SCPSYS
> > +   bool "MediaTek SCPSYS Support"
> > +   depends on ARCH_MEDIATEK || COMPILE_TEST
> 
> How about also depending on "PM" and selecting PM_GENERIC_DOMAINS,
> would that work?

That's what patch 4/5 does. So far all drivers have this in
arch/arm/mach-*/Kconfig and so did I. However, they probably have it
under arch/ to have it next to the driver. I'll move it here and drop
4/5.

> > +static int scpsys_power_on(struct generic_pm_domain *genpd)
> > +{
> > +   struct scp_domain *scpd = container_of(genpd, struct scp_domain, 
> > genpd);
> > +   struct scp *scp = scpd->scp;
> > +   unsigned long timeout;
> > +   bool expired;
> > +   void __iomem *ctl_addr = scpd->ctl_addr;
> > +   u32 sram_pdn_ack = scpd->sram_pdn_ack_bits;
> > +   u32 val;
> > +   int ret;
> > +
> > +   if (scpd->clk) {
> 
> Shouldn't you check for !IS_ERR(scpd->clk) instead?

No. scpd->clk is initialized like this:

if (data->clk_id != MT8173_CLK_NONE)
scpd->clk = scp->clk[data->clk_id];

So scpd->clk will never be an ERR_PTR but always NULL if unset.

> 
> > +   ret = clk_prepare_enable(scpd->clk);
> > +   if (ret)
> > +   return ret;
> > +   }
> > +
> > +   val = readl(ctl_addr);
> > +   val |= PWR_ON_BIT;
> > +   writel(val, ctl_addr);
> > +   val |= PWR_ON_2ND_BIT;
> > +   writel(val, ctl_addr);
> > +
> > +   /* wait until PWR_ACK = 1 */
> > +   timeout = jiffies + HZ;
> > +   expired = false;
> > +   while (1) {
> > +   ret = scpsys_domain_is_on(scpd);
> > +   if (ret > 0)
> > +   break;
> > +
> > +   if (expired) {
> > +   ret = -ETIMEDOUT;
> > +   goto out;
> > +   }
> > +
> > +   cpu_relax();
> > +
> > +   if (time_after(jiffies, timeout))
> > +   expired = true;
> > +   }
> > +
> > +   val &= ~PWR_CLK_DIS_BIT;
> > +   writel(val, ctl_addr);
> > +
> > +   val &= ~PWR_ISO_BIT;
> > +   writel(val, ctl_addr);
> > +
> > +   val |= PWR_RST_B_BIT;
> > +   writel(val, ctl_addr);
> > +
> > +   val &= ~scpd->sram_pdn_bits;
> > +   writel(val, ctl_addr);
> > +
> > +   /* wait until SRAM_PDN_ACK all 0 */
> > +   timeout = jiffies + HZ;
> > +   expired = false;
> > +   while (sram_pdn_ack && (readl(ctl_addr) & sram_pdn_ack)) {
> > +
> > +   if (expired) {
> > +   ret = -ETIMEDOUT;
> > +   goto out;
> > +   }
> > +
> > +   cpu_relax();
> > +
> > +   if (time_after(jiffies, timeout))
> > +   expired = true;
> > +   }
> > +
> > +   if (scpd->bus_prot_mask) {
> > +   ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
> > +   scpd->bus_prot_mask);
> > +   if (ret)
> > +   return ret;
> > +   }
> > +
> > +   return 0;
> > +out:
> 
> There are no error handling. Especially the clock should be gated.

I'll disable the clock in the error path for the next round. Apart from
that I think I cannot implement a proper error hand

Re: [PATCH v2 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

[Javier Martinez Canillas]

Hello Doug,

Thanks a lot for your comments.

On 06/12/2015 10:17 PM, Doug Anderson wrote:
> Hi,
> 
> On Fri, Jun 12, 2015 at 12:36 PM, Javier Martinez Canillas
>  wrote:
 registers are lost assuming the combiner was powered down, even the
 status register will be lost and you will not know exactly the wakeup
 reason right ?

>>>
>>> Good question, I didn't find in the documentation I've access to that
>>> this happen but just found through experimentation that the IRQ enable
>>> set register values are lost after a resume and that saving/restoring
>>> the values makes the interrupts to be triggered again.
>>>
>>
>> I'll share here too the findings I mentioned over IRC. As you suggested I
>> add some printouts and noticed that the ISTRn (Interrupt Status) registers
>> values are indeed preserved on resume so I can know for example if the
>> wakeup source was the power gpio-key or cros_ec keyboard. I've checked the
>> values of the registers against the Exynos manual and they corresponds to
>> the interrupt sources in each case so the values are correct.
>>
>> So as you said, it seems that is not that the IP block loses its state on
>> S2R but that something is blindly writing the IESRn (Interrupt Enable Set)
>> registers.
> 
> I'll postulate an alternate theory here.  You can tell me if you buy
> it or if you think I've been out in the sun too long.
> 
> Let's say that the interrupt combiner's status registers show the raw
> status as asserted by whatever is hooked up to the combiner.  This
> means that even if the combiner got reset we could still read the
> status register and get the status of the source.  Imagine that the
> combiner is like a GPIO bank.  If you reset the GPIO bank, you'll lose
> all kinds of config (input vs. output, edge interrupt status, maybe
> pulls, etc).  ...but you can still read the state asserted by an
> external source, right?
> 

That definitely makes a lot of sense to me.

> In this case the combiner's interrupt source is 'EINT 11'.  ...and I'm
> pretty sure that the controller managine 'EINT 11' _doesn't_ lose
> power across suspend/resume...
>

Yes, the External Interrupt sources come from the GPIO controller and the
driver has a similar logic than $subject to save the registers state.
 
> 
> I'll further bolster my theory by saying that _almost nothing_ in the
> exynos keeps power across suspend/resume.  The UART?  Nope.  The GPIO
> controllers?  Nuh-uh.  The GIC?  Sorry, but no.  The clock tree?  It
> might be nice, but you're out of luck.  ...so it would make me
> terribly surprised to see the combiner keep power.
>

It surprised me as well but I didn't think about what you said that the
combiner interrupt source was restored so the status register could just
be showing the combiner's input raw status even after the chip was reset.

> 
>> To reduce the possible s/w components that could be doing this, I booted a
>> signed FIT image directly using the RO U-Boot instead of chain loading a
>> mainline nv-uboot. In this configuration I've the same issue so it seems
>> that if something is zeroing those registers on S2R, this can't be changed
>> without void the warranty of these machines.
>>
>> I also looked at the downstream ChromiumOS v3.8 tree [0] and I see that
>> they have a very similar solution than my patch, the IESRn are also saved
>> but using a notifier for the CPU_PM_ENTER and CPU_PM_EXIT events instead
>> or registering a syscore ops but the idea is basically the same.
> 
> Yup, you can see where kliegs added it in
> .  As per the
> comments in that CL, this was probably broken in:
> 
> 063bd6f ARM: EXYNOS: Remove GIC save & restore function
> 
>

Nod, thanks for the pointer.

>> I have to take a look to the U-boot that is shipped on the device, I think
>> the correct branch is [1] but I'm not sure if that is the correct one.
> 
> It is the right one.  If U-Boot were touching this (which would
> greatly surprise me) it should be here:
> 
> arch/arm/include/asm/arch-exynos/cpu.h
> 
> ...and it's not.  Doing a grep for '1044' (the combiner base
> address) doesn't find anything in U-Boot either, which makes it less
> likely.  ...and it's even less likely since the amount of code that is
> in U-Boot that runs at resume time is a very small subset and I'm
> fairly familiar with it and I would have remembered it touching the
> combiner.
>

That explains why I was also not able to find were U-Boot was overwriting
those registers.

> It's POSSIBLE that the internal ROM in exynos is clobbering this, but
> as per above it seems crazy unlikely and I think it's just losing
> power.
>

Agreed.

> 
> -Doug
>

Sudeep, so we may need something like $subject after all from Doug's
explanations since the combiner chip state is lost during a S2R. I know
that it adds more duplicated code (others irqchip drivers do the same)
and it may not scale well if a chip has many registers but is the best
solution I coul

Re: [PATCH v3 2/2] arm64: dts: mt8173: Add I2C device node

[Eddie Huang]

Hi Sascha,

On Mon, 2015-06-15 at 08:12 +0200, Sascha Hauer wrote:
> On Fri, Jun 12, 2015 at 08:28:51PM +0800, Daniel Kurtz wrote:
> > On Fri, Jun 12, 2015 at 5:27 PM, Eddie Huang  
> > wrote:
> > >
> > > Add MT8173 I2C device nodes, include I2C controllers and pins.
> > > MT8173 has six I2C controllers, from i2c0 to i2c6, exclude i2c5.
> > > The 6th I2C controller register base doesn't next to 5th I2C,
> > > and there is a hardware between 5th and 6th I2C controller. So
> > > SoC designer name 6th controller as "i2c6", not "i2c5".
> > 
> > 
> > This is slightly misleading.  There are in fact 7 I2C controllers, but
> > "i2c5" is dedicated for use by HDMI for ddc & hdcp.
> > Is there a reason why the HDMI I2C port cannot be controlled by the
> > generic i2c driver?
> > 
> > Of course the hdmiddc / i2c5 node can always be added in a later
> > patch, so this is no reason to hold up this patch.
> > 
> > > Signed-off-by: Eddie Huang 
> > > ---
> > >  arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 50 
> > >  arch/arm64/boot/dts/mediatek/mt8173.dtsi| 72 
> > > +
> > >  2 files changed, 122 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
> > > b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > > index 43d5401..2e01988 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > > @@ -33,6 +33,56 @@
> > > chosen { };
> > >  };
> > >
> > > +&pio {
> > 
> > I don't think we needed to move these i2c pinmux descriptions from
> > mt8173.dtsi to the board .dts file.
> > 
> > AFAICT, the "i2cN_pins_a" nodes defined here are the pinctl
> > configuration that the corresponding enabled i2c nodes would choose.
> > Thus, they are generic to the MT8173 SoC, not specific to any board.
> > By themselves, these nodes do not actually select a pin configuration.
> 
> On i.MX we started with i2cN_pins_[abcde] groups in the SoC dtsi file
> aswell. At some point we realized that this does not scale anymore.
> The problems were:
> 
> - Whenever a new board came along which needed some pin setting which
>   didn't already exist a new group was created in the SoC dtsi file using
>   the next free letter from the alphabet. The ordering of the group names
>   was rather arbitrary and often enough there were merge conflicts to
>   resolve when during one merge window two new boards showed up which both
>   added i2cN_pin_x with different content.
> - When a new board needs the same pins but with different drive strength
>   settings a new group was required
> - With SD/MMC we had groups for 4bit data, groups adding the remaining
>   pins for 8bit data
> - With UARTs we had groups for RX/TX and additionally groups adding
>   RTS/CTS
> - For graphics we had groups for 16bit data and 24bit data
> - There is no way to remove the unused nodes from the binary dtb, so
>   every board contained all existing pingroups for every other board,
>   so the dtbs became quite big
> 
> So with only a few existing boards with very similar pinmux groups
> it may work fine to put the groups into the SoC dtsi, but this way
> may also explode quite fast with more and different boards.
> I don't know how much variation there will be with Mediatek boards, so
> I'm fine with either way. You may want to look at:
> 
> 5a2a7d5 ARM: dts: imx51: make pinctrl nodes board specific
> 7ac0f70 ARM: dts: imx53: make pinctrl nodes board specific
> 817c27a ARM: dts: imx6qdl: make pinctrl nodes board specific
> 

We tend to put basic and fixed pins in SoC dtsi, platform-variant pins
to board dts.Since these pins already move once, I hope we reach a
consensus that I put i2c pins back to SoC dtsi.

Eddie
Thanks


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lockup when C1E and high-resolution timers enabled

[Borislav Petkov]

On Mon, Jun 15, 2015 at 01:05:07AM +0200, Christoph Fritz wrote:
> > > already using latest microcode:
> > > 
> > > [0.514490] microcode: CPU0: patch_level=0x06000822
> > > [0.514497] microcode: CPU1: patch_level=0x06000822
> > > [0.514508] microcode: CPU2: patch_level=0x06000822
> > > [0.514519] microcode: CPU3: patch_level=0x06000822
> > > [0.514529] microcode: CPU4: patch_level=0x06000822
> > > [0.514540] microcode: CPU5: patch_level=0x06000822
> > > [0.514550] microcode: CPU6: patch_level=0x06000822
> > > [0.514561] microcode: CPU7: patch_level=0x06000822
> > 
> > This is not the latest microcode.
> 
> > so what changed?
> 
> nice catch, my bad -- forgot to post all microcode messages.
> 
> $ dmesg | grep microcode:
> [0.514422] microcode: CPU0: patch_level=0x06000822
> [0.514429] microcode: CPU1: patch_level=0x06000822
> [0.514440] microcode: CPU2: patch_level=0x06000822
> [0.514450] microcode: CPU3: patch_level=0x06000822
> [0.514460] microcode: CPU4: patch_level=0x06000822
> [0.514493] microcode: CPU5: patch_level=0x06000822
> [0.514502] microcode: CPU6: patch_level=0x06000822
> [0.514513] microcode: CPU7: patch_level=0x06000822
> [0.514557] microcode: Microcode Update Driver: v2.00 
> , Peter Oruba
> [3.909642] microcode: CPU0: new patch_level=0x06000832
> [3.940694] microcode: CPU2: new patch_level=0x06000832
> [3.955187] microcode: CPU4: new patch_level=0x06000832
> [3.963403] microcode: CPU6: new patch_level=0x06000832

Just to rule out the aspect that your issue might be fixed by microcode
but that microcode needs to be loaded early, can you enable the early
microcode loader, put the microcode in initrd as described here:

Documentation/x86/early-microcode.txt

and retry?

I'm working on having it built-in too, in the case where people don't
use initrd, but that's 64-bit only for now.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH kernel] powerpc/iommu/ioda2: Enable compile with IOV=on and IOMMU_API=off

[Alexey Kardashevskiy]

The pnv_pci_ioda2_unset_window() function is used to do the final
cleanup of a DMA window being released:
- via VFIO ioctl by the guest request;
- via unplugging a virtual PCI function.
However the function was under #ifdef CONFIG_IOMMU_API and was missing.

This moves the helper outside of IOMMU_API block and enables it
for either or both IOMMU_API and PCI_IOV.

Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 50 ---
 1 file changed, 26 insertions(+), 24 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index b9f0f43..8424f5c 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2116,6 +2116,32 @@ static long pnv_pci_ioda2_setup_default_config(struct 
pnv_ioda_pe *pe)
return 0;
 }
 
+#if defined(CONFIG_IOMMU_API) || defined(CONFIG_PCI_IOV)
+static long pnv_pci_ioda2_unset_window(struct iommu_table_group *table_group,
+   int num)
+{
+   struct pnv_ioda_pe *pe = container_of(table_group, struct pnv_ioda_pe,
+   table_group);
+   struct pnv_phb *phb = pe->phb;
+   long ret;
+
+   pe_info(pe, "Removing DMA window #%d\n", num);
+
+   ret = opal_pci_map_pe_dma_window(phb->opal_id, pe->pe_number,
+   (pe->pe_number << 1) + num,
+   0/* levels */, 0/* table address */,
+   0/* table size */, 0/* page size */);
+   if (ret)
+   pe_warn(pe, "Unmapping failed, ret = %ld\n", ret);
+   else
+   pnv_pci_ioda2_tce_invalidate_entire(pe);
+
+   pnv_pci_unlink_table_and_group(table_group->tables[num], table_group);
+
+   return ret;
+}
+#endif
+
 #ifdef CONFIG_IOMMU_API
 static unsigned long pnv_pci_ioda2_get_table_size(__u32 page_shift,
__u64 window_size, __u32 levels)
@@ -2149,30 +2175,6 @@ static unsigned long pnv_pci_ioda2_get_table_size(__u32 
page_shift,
return bytes;
 }
 
-static long pnv_pci_ioda2_unset_window(struct iommu_table_group *table_group,
-   int num)
-{
-   struct pnv_ioda_pe *pe = container_of(table_group, struct pnv_ioda_pe,
-   table_group);
-   struct pnv_phb *phb = pe->phb;
-   long ret;
-
-   pe_info(pe, "Removing DMA window #%d\n", num);
-
-   ret = opal_pci_map_pe_dma_window(phb->opal_id, pe->pe_number,
-   (pe->pe_number << 1) + num,
-   0/* levels */, 0/* table address */,
-   0/* table size */, 0/* page size */);
-   if (ret)
-   pe_warn(pe, "Unmapping failed, ret = %ld\n", ret);
-   else
-   pnv_pci_ioda2_tce_invalidate_entire(pe);
-
-   pnv_pci_unlink_table_and_group(table_group->tables[num], table_group);
-
-   return ret;
-}
-
 static void pnv_ioda2_take_ownership(struct iommu_table_group *table_group)
 {
struct pnv_ioda_pe *pe = container_of(table_group, struct pnv_ioda_pe,
-- 
2.4.0.rc3.8.gfb3e7d5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lockup when C1E and high-resolution timers enabled

[Christoph Fritz]

On Mon, 2015-06-15 at 09:54 +0200, Borislav Petkov wrote:
> Just to rule out the aspect that your issue might be fixed by microcode
> but that microcode needs to be loaded early, can you enable the early
> microcode loader, put the microcode in initrd as described here:
> 
> Documentation/x86/early-microcode.txt
> 
> and retry?

I should have mentioned that, I already tested that, it doesn't fix
the described lockup :-(


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 2/3] sb_edac: virtualize several hard-coded functions

[Anaczkowski, Lukasz]

> From: Aristeu Rozanski [mailto:a...@redhat.com] 

> the only reason these exist is for when there's a difference between memory 
> controllers:
> > pvt->info.get_memory_type = get_memory_type;
> > pvt->info.get_memory_type = get_memory_type;
> > pvt->info.get_memory_type = haswell_get_memory_type;
> 

Well, this is similar to what's gonna happen when KNL patches are submitted, 
but currently, I'm not allowed to disclose them, so, please ignore this change 
for now.

Cheers,
Lukasz




Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial 
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | 
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] Increase limit of macvtap queues

[Jason Wang]

On 06/14/2015 04:42 PM, Michael S. Tsirkin wrote:
> On Fri, Jun 12, 2015 at 07:00:28PM +0530, Pankaj Gupta wrote:
>> Macvtap should be compatible with tuntap for maximum number
>> of queues. '1059590254fa9dce9cafc4f07d1103dbec415e76' removes
>> the limitation and increases number of queues in tuntap.
>> Now, Its safe to increase number of queues in Macvtap as well.
>>
>> Signed-off-by: Pankaj Gupta 
> It's a good idea, but this might be a problem:
>
> static void macvtap_del_queues(struct net_device *dev)
> {
> struct macvlan_dev *vlan = netdev_priv(dev);
> struct macvtap_queue *q, *tmp, *qlist[MAX_MACVTAP_QUEUES];
>
> ...
> }
>
> by itself, this will use 2K on stack, which seems too much.
>
> You need to rework this function to use a linked list + list_move
> instead of an array + list_del_init.

Looks like even simpler, we can just do sock_put() inside
list_for_each_entry_safe() loop.

>> ---
>>  include/linux/if_macvlan.h |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
>> index 6f6929e..a4ccc31 100644
>> --- a/include/linux/if_macvlan.h
>> +++ b/include/linux/if_macvlan.h
>> @@ -29,7 +29,7 @@ struct macvtap_queue;
>>   * Maximum times a macvtap device can be opened. This can be used to
>>   * configure the number of receive queue, e.g. for multiqueue virtio.
>>   */
>> -#define MAX_MACVTAP_QUEUES 16
>> +#define MAX_MACVTAP_QUEUES 256
>>
>>  #define MACVLAN_MC_FILTER_BITS 8
>>  #define MACVLAN_MC_FILTER_SZ   (1 << MACVLAN_MC_FILTER_BITS)
>> --
>> 1.7.1
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] perf probe: Fix failure to probe events on arm

[He Kuang]

Fix failure to probe events on arm, problem is introduced by commit
5a51fcd1f30c ("perf probe: Skip kernel symbols which is out of
.text"). For some architectures, label '_etext' is not in the .text
section(in .notes section for arm/arm64). Label out of .text section is
not loaded as symbols and we got a zero value when look up its address,
which causes all events be wrongly skiped.

This patch uses kernel map->end when failed to get the address of
'_etext' and fixes the problem.

Problem can be reproduced on arm as following:

  # perf probe --add='generic_perform_write'
  generic_perform_write+0 is out of .text, skip it.
  Probe point 'generic_perform_write' not found.
Error: Failed to add events. Reason: No such file or directory (Code: -2)

After this patch:

  # perf probe --add='generic_perform_write'
  Added new event:
probe:generic_perform_write (on generic_perform_write)

  You can now use it in all perf tools, such as:

perf record -e probe:generic_perform_write -aR sleep 1

Signed-off-by: He Kuang 
---
 tools/perf/util/probe-event.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index daa24a2..ee26961 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -575,8 +575,22 @@ static int post_process_probe_trace_events(struct 
probe_trace_event *tevs,
pr_warning("Relocated base symbol is not found!\n");
return -EINVAL;
}
-   /* Get the address of _etext for checking non-probable text symbol */
+   /* Get the address of _etext for checking non-probable text symbol,
+  for some architectures (e.g. arm, arm64), _etext is out of .text
+  section and not loaded as symbols, use kernel map->end instead.
+*/
etext_addr = kernel_get_symbol_address_by_name("_etext", false);
+   if (etext_addr == 0) {
+   struct map *map;
+
+   map = kernel_get_module_map(NULL);
+   if (!map) {
+   pr_err("Failed to get a map for kernel\n");
+   return -EINVAL;
+   }
+
+   etext_addr = map->end;
+   }
 
for (i = 0; i < ntevs; i++) {
if (tevs[i].point.address && !tevs[i].point.retprobe) {
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lockup when C1E and high-resolution timers enabled

[Borislav Petkov]

On Mon, Jun 15, 2015 at 10:01:41AM +0200, Christoph Fritz wrote:
> I should have mentioned that, I already tested that, it doesn't fix
> the described lockup :-(

Hmm, can you boot with

 "log_buf_len=16M ignore_loglevel debug initcall_debug apic=debug"

and send me full dmesg from that box?

Privately's fine too.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: Add docbook for soft start

[Mark Brown]

On Fri, Jun 12, 2015 at 03:48:06PM -0700, Stephen Boyd wrote:
> The docbook for these members is missing. Add them.
> 
> Warning(include/linux/regulator/machine.h:147): No description
> found for parameter 'soft_start'
> Warning(include/linux/regulator/driver.h:197): No description
> found for parameter 'set_soft_start'

Applied, thanks.


signature.asc
Description: Digital signature

linux-next: manual merge of the rdma tree with the net-next tree

[Michael Ellerman]

Hi Doug,

Today's linux-next merge of the rdma tree got a conflict in
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c and
drivers/net/ethernet/chelsio/cxgb4/sge.c between commit b26127227677
"cxgb4/cxgb4vf: function and argument name cleanup" from the net-next tree and
commit 66cf188eba52 "cxgb4: Support for user mode bar2 mappings with T4" from
the rdma tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

cheers


diff --cc drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 0e27f2266e6b,a9355593e65e..
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@@ -2356,8 -2352,8 +2358,8 @@@ static void process_db_drop(struct work
unsigned int bar2_qid;
int ret;
  
 -  ret = cxgb4_t4_bar2_sge_qregs(adap, qid, T4_BAR2_QTYPE_EGRESS,
 -0, &bar2_qoffset, &bar2_qid);
 +  ret = t4_bar2_sge_qregs(adap, qid, T4_BAR2_QTYPE_EGRESS,
-   &bar2_qoffset, &bar2_qid);
++  0, &bar2_qoffset, &bar2_qid);
if (ret)
dev_err(adap->pdev_dev, "doorbell drop recovery: "
"qid=%d, pidx_inc=%d\n", qid, pidx_inc);
diff --cc drivers/net/ethernet/chelsio/cxgb4/sge.c
index 6b7c37fd0252,1b99aecde736..
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@@ -2401,8 -2429,8 +2401,8 @@@ static void __iomem *bar2_address(struc
u64 bar2_qoffset;
int ret;
  
-   ret = t4_bar2_sge_qregs(adapter, qid, qtype,
 -  ret = cxgb4_t4_bar2_sge_qregs(adapter, qid, qtype, 0,
 -&bar2_qoffset, pbar2_qid);
++  ret = t4_bar2_sge_qregs(adapter, qid, qtype, 0,
 +  &bar2_qoffset, pbar2_qid);
if (ret)
return NULL;
  



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the staging tree with the rdma tree

[Michael Ellerman]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c between commit 8e37210b38fb
"IB/core: Change ib_create_cq to use struct ib_cq_init_attr" from the rdma tree
and commit ec3d17c0ed2e "staging: lustre: lnet: o2iblnd: code cleanup - align
whitespace" from the staging tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

cheers


diff --cc drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index c41b5575df05,48454a576b7a..
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@@ -642,18 -643,17 +643,18 @@@ kib_conn_t *kiblnd_create_conn(kib_peer
 * she must dispose of 'cmid'.  (Actually I'd block forever if I tried
 * to destroy 'cmid' here since I'm called from the CM which still has
 * its ref on 'cmid'). */
-   rwlock_t*glock = &kiblnd_data.kib_global_lock;
-   kib_net_t *net = peer->ibp_ni->ni_data;
-   kib_dev_t *dev;
+   rwlock_t *glock = &kiblnd_data.kib_global_lock;
+   kib_net_t *net = peer->ibp_ni->ni_data;
+   kib_dev_t *dev;
struct ib_qp_init_attr *init_qp_attr;
-   struct kib_sched_info   *sched;
-   struct ib_cq_init_attr  cq_attr = {};
-   kib_conn_t  *conn;
-   struct ib_cq*cq;
-   unsigned long   flags;
-   int cpt;
-   int rc;
-   int i;
+   struct kib_sched_info *sched;
++  struct ib_cq_init_attr cq_attr = {};
+   kib_conn_t *conn;
+   struct ib_cq *cq;
+   unsigned long flags;
+   int cpt;
+   int rc;
+   int i;
  
LASSERT(net != NULL);
LASSERT(!in_interrupt());



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the rdma tree with the net-next tree

[Michael Ellerman]

Hi Doug,

Today's linux-next merge of the rdma tree got a conflict in
drivers/infiniband/hw/mlx5/main.c between commit 1b5daf11b015 "IB/mlx5: Avoid
using the MAD_IFC command under ISSI > 0 mode" from the net-next tree and
commit 2528e33e6809 "IB/core: Pass hardware specific data in query_device" from
the rdma tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

cheers


diff --cc drivers/infiniband/hw/mlx5/main.c
index 79dadd627e9c,c6cb26e0c866..
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@@ -63,168 -62,36 +63,172 @@@ static char mlx5_version[] 
DRIVER_NAME ": Mellanox Connect-IB Infiniband driver v"
DRIVER_VERSION " (" DRIVER_RELDATE ")\n";
  
 +static enum rdma_link_layer
 +mlx5_ib_port_link_layer(struct ib_device *device)
 +{
 +  struct mlx5_ib_dev *dev = to_mdev(device);
 +
 +  switch (MLX5_CAP_GEN(dev->mdev, port_type)) {
 +  case MLX5_CAP_PORT_TYPE_IB:
 +  return IB_LINK_LAYER_INFINIBAND;
 +  case MLX5_CAP_PORT_TYPE_ETH:
 +  return IB_LINK_LAYER_ETHERNET;
 +  default:
 +  return IB_LINK_LAYER_UNSPECIFIED;
 +  }
 +}
 +
 +static int mlx5_use_mad_ifc(struct mlx5_ib_dev *dev)
 +{
 +  return !dev->mdev->issi;
 +}
 +
 +enum {
 +  MLX5_VPORT_ACCESS_METHOD_MAD,
 +  MLX5_VPORT_ACCESS_METHOD_HCA,
 +  MLX5_VPORT_ACCESS_METHOD_NIC,
 +};
 +
 +static int mlx5_get_vport_access_method(struct ib_device *ibdev)
 +{
 +  if (mlx5_use_mad_ifc(to_mdev(ibdev)))
 +  return MLX5_VPORT_ACCESS_METHOD_MAD;
 +
 +  if (mlx5_ib_port_link_layer(ibdev) ==
 +  IB_LINK_LAYER_ETHERNET)
 +  return MLX5_VPORT_ACCESS_METHOD_NIC;
 +
 +  return MLX5_VPORT_ACCESS_METHOD_HCA;
 +}
 +
 +static int mlx5_query_system_image_guid(struct ib_device *ibdev,
 +  __be64 *sys_image_guid)
 +{
 +  struct mlx5_ib_dev *dev = to_mdev(ibdev);
 +  struct mlx5_core_dev *mdev = dev->mdev;
 +  u64 tmp;
 +  int err;
 +
 +  switch (mlx5_get_vport_access_method(ibdev)) {
 +  case MLX5_VPORT_ACCESS_METHOD_MAD:
 +  return mlx5_query_mad_ifc_system_image_guid(ibdev,
 +  sys_image_guid);
 +
 +  case MLX5_VPORT_ACCESS_METHOD_HCA:
 +  err = mlx5_query_hca_vport_system_image_guid(mdev, &tmp);
 +  if (!err)
 +  *sys_image_guid = cpu_to_be64(tmp);
 +  return err;
 +
 +  default:
 +  return -EINVAL;
 +  }
 +}
 +
 +static int mlx5_query_max_pkeys(struct ib_device *ibdev,
 +  u16 *max_pkeys)
 +{
 +  struct mlx5_ib_dev *dev = to_mdev(ibdev);
 +  struct mlx5_core_dev *mdev = dev->mdev;
 +
 +  switch (mlx5_get_vport_access_method(ibdev)) {
 +  case MLX5_VPORT_ACCESS_METHOD_MAD:
 +  return mlx5_query_mad_ifc_max_pkeys(ibdev, max_pkeys);
 +
 +  case MLX5_VPORT_ACCESS_METHOD_HCA:
 +  case MLX5_VPORT_ACCESS_METHOD_NIC:
 +  *max_pkeys = mlx5_to_sw_pkey_sz(MLX5_CAP_GEN(mdev,
 +  pkey_table_size));
 +  return 0;
 +
 +  default:
 +  return -EINVAL;
 +  }
 +}
 +
 +static int mlx5_query_vendor_id(struct ib_device *ibdev,
 +  u32 *vendor_id)
 +{
 +  struct mlx5_ib_dev *dev = to_mdev(ibdev);
 +
 +  switch (mlx5_get_vport_access_method(ibdev)) {
 +  case MLX5_VPORT_ACCESS_METHOD_MAD:
 +  return mlx5_query_mad_ifc_vendor_id(ibdev, vendor_id);
 +
 +  case MLX5_VPORT_ACCESS_METHOD_HCA:
 +  case MLX5_VPORT_ACCESS_METHOD_NIC:
 +  return mlx5_core_query_vendor_id(dev->mdev, vendor_id);
 +
 +  default:
 +  return -EINVAL;
 +  }
 +}
 +
 +static int mlx5_query_node_guid(struct mlx5_ib_dev *dev,
 +  __be64 *node_guid)
 +{
 +  u64 tmp;
 +  int err;
 +
 +  switch (mlx5_get_vport_access_method(&dev->ib_dev)) {
 +  case MLX5_VPORT_ACCESS_METHOD_MAD:
 +  return mlx5_query_mad_ifc_node_guid(dev, node_guid);
 +
 +  case MLX5_VPORT_ACCESS_METHOD_HCA:
 +  err = mlx5_query_hca_vport_node_guid(dev->mdev, &tmp);
 +  if (!err)
 +  *node_guid = cpu_to_be64(tmp);
 +  return err;
 +
 +  default:
 +  return -EINVAL;
 +  }
 +}
 +
 +struct mlx5_reg_node_desc {
 +  u8  desc[64];
 +};
 +
 +static int mlx5_query_node_desc(struct mlx5_ib_dev *dev, char *node_desc)
 +{
 +  struct mlx5_reg_node_desc in;
 +
 +  if (mlx5_use_mad_ifc(dev))
 +  return mlx5_query_mad_ifc_node_desc(dev, node_desc);
 +
 +  memset(&in, 0, sizeof(in));
 +
 +  return mlx5_core_access_reg(dev->mdev, &in, sizeof(in), node_desc,
 +  sizeof(struct mlx5_reg_node_desc),
 +   

Re: [PATCH 03/25] mm, vmscan: Move LRU lists to node

[Mel Gorman]

On Thu, Jun 11, 2015 at 03:12:12PM +0800, Hillf Danton wrote:
> > @@ -774,6 +764,21 @@ typedef struct pglist_data {
> > ZONE_PADDING(_pad1_)
> > spinlock_t  lru_lock;
> > 
> > +   /* Fields commonly accessed by the page reclaim scanner */
> > +   struct lruvec   lruvec;
> > +
> > +   /* Evictions & activations on the inactive file list */
> > +   atomic_long_t   inactive_age;
> > +
> > +   /*
> > +* The target ratio of ACTIVE_ANON to INACTIVE_ANON pages on
> > +* this zone's LRU.  Maintained by the pageout code.
> > +*/
> 
> The comment has to be updated.
> 

Yes it does. Fixed.

> > +   unsigned int inactive_ratio;
> > +
> > +   unsigned long   flags;
> > +
> > +   ZONE_PADDING(_pad2_)
> > struct per_cpu_nodestat __percpu *per_cpu_nodestats;
> > atomic_long_t   vm_stat[NR_VM_NODE_STAT_ITEMS];
> >  } pg_data_t;
> > @@ -1185,7 +1185,7 @@ struct lruvec *mem_cgroup_zone_lruvec(struct zone 
> > *zone,
> > struct lruvec *lruvec;
> > 
> > if (mem_cgroup_disabled()) {
> > -   lruvec = &zone->lruvec;
> > +   lruvec = zone_lruvec(zone);
> > goto out;
> > }
> > 
> > @@ -1197,8 +1197,8 @@ out:
> >  * we have to be prepared to initialize lruvec->zone here;
> >  * and if offlined then reonlined, we need to reinitialize it.
> >  */
> > -   if (unlikely(lruvec->zone != zone))
> > -   lruvec->zone = zone;
> > +   if (unlikely(lruvec->pgdat != zone->zone_pgdat))
> > +   lruvec->pgdat = zone->zone_pgdat;
> 
> See below please.
> 
> > return lruvec;
> >  }
> > 
> > @@ -1211,14 +1211,14 @@ out:
> >   * and putback protocol: the LRU lock must be held, and the page must
> >   * either be PageLRU() or the caller must have isolated/allocated it.
> >   */
> > -struct lruvec *mem_cgroup_page_lruvec(struct page *page, struct zone *zone)
> > +struct lruvec *mem_cgroup_page_lruvec(struct page *page, struct 
> > pglist_data *pgdat)
> >  {
> > struct mem_cgroup_per_zone *mz;
> > struct mem_cgroup *memcg;
> > struct lruvec *lruvec;
> > 
> > if (mem_cgroup_disabled()) {
> > -   lruvec = &zone->lruvec;
> > +   lruvec = &pgdat->lruvec;
> > goto out;
> > }
> > 
> > @@ -1238,8 +1238,8 @@ out:
> >  * we have to be prepared to initialize lruvec->zone here;
> >  * and if offlined then reonlined, we need to reinitialize it.
> >  */
> > -   if (unlikely(lruvec->zone != zone))
> > -   lruvec->zone = zone;
> > +   if (unlikely(lruvec->pgdat != pgdat))
> > +   lruvec->pgdat = pgdat;
> 
> Given &pgdat->lruvec, we no longer need(or are able) to set lruvec->pgdat.
> 

I do not understand your comment. This is setting a mapping between lruvec
and pgdat, not the other way around. It's a straight-forward conversion
of zone to pgdat.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/25] mm, vmscan: Begin reclaiming pages on a per-node basis

[Mel Gorman]

On Thu, Jun 11, 2015 at 03:58:14PM +0800, Hillf Danton wrote:
> > @@ -1319,6 +1322,7 @@ static unsigned long isolate_lru_pages(unsigned long 
> > nr_to_scan,
> > struct list_head *src = &lruvec->lists[lru];
> > unsigned long nr_taken = 0;
> > unsigned long scan;
> > +   LIST_HEAD(pages_skipped);
> > 
> > for (scan = 0; scan < nr_to_scan && !list_empty(src); scan++) {
> > struct page *page;
> > @@ -1329,6 +1333,9 @@ static unsigned long isolate_lru_pages(unsigned long 
> > nr_to_scan,
> > 
> > VM_BUG_ON_PAGE(!PageLRU(page), page);
> > 
> > +   if (page_zone_id(page) > sc->reclaim_idx)
> > +   list_move(&page->lru, &pages_skipped);
> > +
> > switch (__isolate_lru_page(page, mode)) {
> > case 0:
> > nr_pages = hpage_nr_pages(page);
> > @@ -1347,6 +1354,15 @@ static unsigned long isolate_lru_pages(unsigned long 
> > nr_to_scan,
> > }
> > }
> > 
> > +   /*
> > +* Splice any skipped pages to the start of the LRU list. Note that
> > +* this disrupts the LRU order when reclaiming for lower zones but
> > +* we cannot splice to the tail. If we did then the SWAP_CLUSTER_MAX
> > +* scanning would soon rescan the same pages to skip and put the
> > +* system at risk of premature OOM.
> > +*/
> > +   if (!list_empty(&pages_skipped))
> > +   list_splice(&pages_skipped, src);
> > *nr_scanned = scan;
> > trace_mm_vmscan_lru_isolate(sc->order, nr_to_scan, scan,
> > nr_taken, mode, is_file_lru(lru));
> 
> Can we avoid splicing pages by skipping pages with scan not incremented?
> 

The reclaimers would still have to do the work of examining those pages
and ignoring them even if the counters are not updated. It'll look like
high CPU usage for no obvious reason.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 23/24] m68k/mac: Fix PRAM accessors

[Geert Uytterhoeven]

Hi Finn,

On Sun, Jun 14, 2015 at 9:46 AM, Finn Thain  wrote:
> --- linux.orig/arch/m68k/mac/misc.c 2015-06-14 17:46:02.0 +1000
> +++ linux/arch/m68k/mac/misc.c  2015-06-14 17:46:03.0 +1000
> @@ -284,11 +287,31 @@ static void via_pram_command(int command
>
>  static unsigned char via_pram_read_byte(int offset)
>  {
> -   return 0;
> +   unsigned char temp;
> +   int addr = ((offset & 0xE0) << 3) | ((offset & 0x1F) << 2);

Can you please add #defines for the magic values?

> +
> +   /* Use RTC command 0x38 for XPRAM access, as per MESS source code */
> +   via_pram_command(addr | 0x3800 | 0x8001, &temp);

It seems 0x38 is already documented in  (see below), or not (it's
shifted left by 8 bits?)?

> +
> +   return temp;
>  }
>
>  static void via_pram_write_byte(unsigned char data, int offset)
>  {
> +   unsigned char temp;
> +   int addr = ((offset & 0xE0) << 3) | ((offset & 0x1F) << 2);
> +
> +   /* Clear the write protect bit */
> +   temp = 0x55;
> +   via_pram_command(0x34 | 0x01, &temp);
> +
> +   /* Write the byte to XPRAM */
> +   temp = data;
> +   via_pram_command(0x3800 | 0x0001 | addr, &temp);
> +
> +   /* Set the write protect bit */
> +   temp = 0xD5;
> +   via_pram_command(0x34 | 0x01, &temp);

More magic values...

>  }
>
>  /*
> Index: linux/include/uapi/linux/pmu.h
> ===
> --- linux.orig/include/uapi/linux/pmu.h 2015-06-14 17:45:34.0 +1000
> +++ linux/include/uapi/linux/pmu.h  2015-06-14 17:46:03.0 +1000
> @@ -18,7 +18,9 @@
>  #define PMU_POWER_CTRL 0x11/* control power of some devices */
>  #define PMU_ADB_CMD0x20/* send ADB packet */
>  #define PMU_ADB_POLL_OFF   0x21/* disable ADB auto-poll */
> +#define PMU_WRITE_XPRAM0x32/* write eXtended Parameter 
> RAM */
>  #define PMU_WRITE_NVRAM0x33/* write non-volatile RAM */
> +#define PMU_READ_XPRAM 0x3a/* read eXtended Parameter RAM */
>  #define PMU_READ_NVRAM 0x3b/* read non-volatile RAM */
>  #define PMU_SET_RTC0x30/* set real-time clock */
>  #define PMU_READ_RTC   0x38/* read real-time clock */

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [BUG, bisect] Re: drm/i915: WARN_ON(dev_priv->mm.busy)

[Jeremiah Mahler]

Daniel,

On Mon, Jun 15, 2015 at 08:57:47AM +0200, Daniel Vetter wrote:
> Can you please retest with
> 
> commit 0aedb1626566efd72b369c01992ee7413c82a0c5
> Author: Ville Syrjälä 
> Date:   Thu May 28 18:32:36 2015 +0300
> 
> drm/i915: Don't skip request retirement if the active list is empty
> 
> Thanks, Daniel
> 

The bug is still present with that patch applied.  And it is still
present up to linux-next 20150611.

-- 
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] dmaengine: pl330: Fix overflow when reporting residue in memcpy

[Krzysztof Kozlowski]

During memcpy operations the residue was always set to an u32 overflowed
value.

In pl330_tx_status() function number of currently transferred bytes was
subtracted from internal "bytes_requested" field. However this
"bytes_requested" was not initialized at start to length of memcpy
buffer so transferred bytes were subtracted from 0 causing overflow.

Signed-off-by: Krzysztof Kozlowski 
Cc: 
Fixes: aee4d1fac887 ("dmaengine: pl330: improve pl330_tx_status() function")
---
 drivers/dma/pl330.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index f513f77b1d85..c535cd059724 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2623,6 +2623,7 @@ pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t 
dst,
desc->rqcfg.brst_len = 1;
 
desc->rqcfg.brst_len = get_burst_len(desc, len);
+   desc->bytes_requested = len;
 
desc->txd.flags = flags;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/25] mm, vmscan: Make kswapd think of reclaim in terms of nodes

[Mel Gorman]

On Fri, Jun 12, 2015 at 03:05:00PM +0800, Hillf Danton wrote:
> > -   /* Reclaim above the high watermark. */
> > -   sc->nr_to_reclaim = max(SWAP_CLUSTER_MAX, high_wmark_pages(zone));
> > +   /* Aim to reclaim above all the zone high watermarks */
> > +   for (z = 0; z <= end_zone; z++) {
> > +   zone = pgdat->node_zones + end_zone;
> s/end_zone/z/ ?

Ouch, thanks!

With this bug, kswapd would reclaim based on a multiple of the highest
zone. Whether that was under or over reclaim would depend on the size of
that zone relative to lower zones.

> > +   nr_to_reclaim += high_wmark_pages(zone);
> > 
> [...]
> > @@ -3280,13 +3177,26 @@ static unsigned long balance_pgdat(pg_data_t 
> > *pgdat, int order,
> > compact_pgdat(pgdat, order);
> > 
> > /*
> > +* Stop reclaiming if any eligible zone is balanced and clear
> > +* node writeback or congested.
> > +*/
> > +   for (i = 0; i <= *classzone_idx; i++) {
> > +   zone = pgdat->node_zones + i;
> > +
> > +   if (zone_balanced(zone, sc.order, 0, *classzone_idx)) {
> > +   clear_bit(PGDAT_CONGESTED, &pgdat->flags);
> > +   clear_bit(PGDAT_DIRTY, &pgdat->flags);
> > +   break;
> s/break/goto out/ ?

Yes. It'd actually be ok because it'll detect the same condition and
exit in the next outer loop but goto out is better.


-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] tip-queue 2015-06-15

[Borislav Petkov]

From: Borislav Petkov 

Hi,

nothing much this time.

Luis' stuff is ontop of the pat_enabled() cleanup in tip/x86/mm and
apparently there's maintainer agreement for it to go through tip. It has
ACKs and all.

The amd.c change is exporting the number of logical nodes in a physical
socket which will be used in the injection code.

Thanks.

Aravind Gopalakrishnan (1):
  x86/cpu/amd: Give access to the number of nodes in a physical package

Luis R. Rodriguez (3):
  drivers/media/ivtv: Use arch_phys_wc_add() and require PAT disabled
  drivers/infiniband/ipath: Add counting for MTRR
  drivers/infiniband/ipath: Use arch_phys_wc_add() and require PAT
disabled

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] drivers/media/ivtv: Use arch_phys_wc_add() and require PAT disabled

[Borislav Petkov]

From: "Luis R. Rodriguez" 

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future, we
also want to make the default behavior of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code, port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy compromise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.

Signed-off-by: Luis R. Rodriguez 
Acked-by: Andy Walls 
Acked-by: Mauro Carvalho Chehab 
Cc: Andy Lutomirski 
Cc: Antonino Daplas 
Cc: Arnd Bergmann 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Dave Hansen 
Cc: Doug Ledford 
Cc: Ingo Molnar 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Juergen Gross 
Cc: "Michael S. Tsirkin" 
Cc: Roger Pau Monné 
Cc: Stefan Bader 
Cc: Suresh Siddha 
Cc: Thomas Gleixner 
Cc: Ville Syrjälä 
Cc: bhelg...@google.com
Cc: konrad.w...@oracle.com
Cc: linux-me...@vger.kernel.org
Cc: tomi.valkei...@ti.com
Cc: toshi.k...@hp.com
Link: 
http://lkml.kernel.org/r/1434053994-2196-2-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov 
---
 drivers/media/pci/ivtv/Kconfig  |  3 +++
 drivers/media/pci/ivtv/ivtvfb.c | 58 -
 2 files changed, 26 insertions(+), 35 deletions(-)

diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e3a4c..6e5867c57305 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
  This is used in the Hauppauge PVR-350 card. There is a driver
  homepage at .
 
+ In order to use this module, you will need to boot with PAT disabled
+ on x86 systems, using the nopat kernel parameter.
+
  To compile this driver as a module, choose M here: the
  module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230192e8..4cb365d4ffdc 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
 #include 
 #include 
 
-#ifdef CONFIG_MTRR
-#include 
+#ifdef CONFIG_X86_64
+#include 
 #endif
 
 #include "ivtv-driver.h"
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
 
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+   int wc_cookie;
 
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
 static int ivtvfb_init_io(struct ivtv *itv)
 {
struct osd_info *oi = itv->osd_info;
+   /* Find the largest power of two that maps the whole buffer */
+   int size_shift = 31;
 
mutex_lock(&itv->serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi->video_pbase, oi->video_vbase,
oi->video_buffer_size / 1024);
 
-#ifdef CONFIG_MTRR
-   {
-   /* Find the largest power of two that maps the whole buffer */
-   int size_shift = 31;
-
-   while (!(oi->video_buffer_size & (1 << size_shift))) {
-   size_shift--;
-   }
-   size_shift++;
-   oi->fb_start_aligned_physaddr = oi->video_pbase & ~((1 << 
size_shift) - 1);
-   oi->fb_end_aligned_physaddr = oi->video_pbase + 
oi->video_buffer_size;
-   oi->fb_end_aligned_physaddr += (1 << size_shift) - 1;
-   oi->fb_end_aligned_physaddr &= ~((1 << size_shift) - 1);
-   if (mtrr_add(oi->fb_start_aligned_physaddr,
-   oi->fb_end_aligned_physaddr - 
oi->fb_start_aligned_physaddr,
-MTRR_TYPE_WRCOMB, 1) < 0) {
-   IVTVFB_INFO("disabled mttr\n");
-   oi->fb_start_aligned_physaddr = 0;
-   oi->fb_end_aligned_physaddr = 0;
-   }
-   }
-#endif
-
+   while (!(oi->video_buffer_size & (1 << size_shift)))
+   size_shift--;
+   size_shift++;
+   oi->fb_start_aligned_physaddr = oi->video_pbase & ~((1 << size_shift) - 
1);
+   oi->fb_end_aligned_physaddr = oi->video_pbase + oi->video_buffer_size;
+   oi->fb_end_aligned_physaddr += (1 << size_shift) - 1;
+   oi->fb_end_aligned_physaddr &= ~((1 << size_shift) - 1);
+   oi->wc_cookie

[PATCH 3/4] drivers/infiniband/ipath: Add counting for MTRR

[Borislav Petkov]

From: "Luis R. Rodriguez" 

There is no good reason not to, we eventually delete it as well.

Signed-off-by: Luis R. Rodriguez 
Acked-by: Doug Ledford 
Cc: Andy Lutomirski 
Cc: Antonino Daplas 
Cc: bhelg...@google.com
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Hal Rosenstock 
Cc: infinip...@intel.com
Cc: Ingo Molnar 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Juergen Gross 
Cc: linux-r...@vger.kernel.org
Cc: "Luis R. Rodriguez" 
Cc: mche...@osg.samsung.com
Cc: Roland Dreier 
Cc: Sean Hefty 
Cc: Suresh Siddha 
Cc: Thomas Gleixner 
Cc: Tomi Valkeinen 
Cc: Toshi Kani 
Link: 
http://lkml.kernel.org/r/1434053994-2196-3-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov 
---
 drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c 
b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
index 4ad0b932df1f..70c1f3aeb03d 100644
--- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
+++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
@@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
   "(addr %llx, len=0x%llx)\n",
   (unsigned long long) pioaddr,
   (unsigned long long) piolen);
-   cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+   cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie < 0) {
{
dev_info(&dd->pcidev->dev,
-- 
2.3.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] x86/cpu/amd: Give access to the number of nodes in a physical package

[Borislav Petkov]

From: Aravind Gopalakrishnan 

Stash the number of nodes in a physical processor package locally and
add an accessor to be called by interested parties. The first user is
the MCE injection module which uses it to find the node base core in a
package for injecting a certain type of errors.

Signed-off-by: Aravind Gopalakrishnan 
Cc: "H. Peter Anvin" 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: Ingo Molnar 
Cc: Jacob Shin 
Cc: Paolo Bonzini 
Cc: Thomas Gleixner 
Cc: linux-edac 
Cc: mche...@osg.samsung.com
Cc: x86-ml 
Link: 
http://lkml.kernel.org/r/1433868317-18417-2-git-send-email-aravind.gopalakrish...@amd.com
[ Rewrite commit message, merge with the accessor patch and unify naming. ]
Signed-off-by: Borislav Petkov 
---
 arch/x86/include/asm/processor.h |  1 +
 arch/x86/kernel/cpu/amd.c| 23 ++-
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 23ba6765b718..9aa52fd13a78 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -946,6 +946,7 @@ static inline int mpx_disable_management(struct task_struct 
*tsk)
 #endif /* CONFIG_X86_INTEL_MPX */
 
 extern u16 amd_get_nb_id(int cpu);
+extern u32 amd_get_nodes_per_socket(void);
 
 static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
 {
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 94e7051fba1a..56cae1964a81 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -19,6 +19,13 @@
 
 #include "cpu.h"
 
+/*
+ * nodes_per_socket: Stores the number of nodes per socket.
+ * Refer to Fam15h Models 00-0fh BKDG - CPUID Fn8000_001E_ECX
+ * Node Identifiers[10:8]
+ */
+static u32 nodes_per_socket = 1;
+
 static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
 {
u32 gprs[8] = { 0 };
@@ -291,7 +298,7 @@ static int nearby_node(int apicid)
 #ifdef CONFIG_X86_HT
 static void amd_get_topology(struct cpuinfo_x86 *c)
 {
-   u32 nodes, cores_per_cu = 1;
+   u32 cores_per_cu = 1;
u8 node_id;
int cpu = smp_processor_id();
 
@@ -300,7 +307,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
u32 eax, ebx, ecx, edx;
 
cpuid(0x801e, &eax, &ebx, &ecx, &edx);
-   nodes = ((ecx >> 8) & 7) + 1;
+   nodes_per_socket = ((ecx >> 8) & 7) + 1;
node_id = ecx & 7;
 
/* get compute unit information */
@@ -311,18 +318,18 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
u64 value;
 
rdmsrl(MSR_FAM10H_NODE_ID, value);
-   nodes = ((value >> 3) & 7) + 1;
+   nodes_per_socket = ((value >> 3) & 7) + 1;
node_id = value & 7;
} else
return;
 
/* fixup multi-node processor information */
-   if (nodes > 1) {
+   if (nodes_per_socket > 1) {
u32 cores_per_node;
u32 cus_per_node;
 
set_cpu_cap(c, X86_FEATURE_AMD_DCM);
-   cores_per_node = c->x86_max_cores / nodes;
+   cores_per_node = c->x86_max_cores / nodes_per_socket;
cus_per_node = cores_per_node / cores_per_cu;
 
/* store NodeID, use llc_shared_map to store sibling info */
@@ -366,6 +373,12 @@ u16 amd_get_nb_id(int cpu)
 }
 EXPORT_SYMBOL_GPL(amd_get_nb_id);
 
+u32 amd_get_nodes_per_socket(void)
+{
+   return nodes_per_socket;
+}
+EXPORT_SYMBOL_GPL(amd_get_nodes_per_socket);
+
 static void srat_detect_node(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_NUMA
-- 
2.3.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] drivers/infiniband/ipath: Use arch_phys_wc_add() and require PAT disabled

[Borislav Petkov]

From: "Luis R. Rodriguez" 

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future, we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy compromise given that the ipath device
driver powers the old HTX bus cards that only work in
AMD systems, while the newer IB/qib device driver
powers all PCI-e cards. The ipath device driver is
obsolete, hardware hard to find and because of this
this its a reasonable compromise to make to require
users of ipath to boot with nopat.

Signed-off-by: Luis R. Rodriguez 
Acked-by: Doug Ledford 
Cc: Andy Lutomirski 
Cc: Andy Walls 
Cc: Antonino Daplas 
Cc: Arnd Bergmann 
Cc: Bjorn Helgaas 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Dave Hansen 
Cc: Hal Rosenstock 
Cc: infinip...@intel.com
Cc: Ingo Molnar 
Cc: jbeul...@suse.com
Cc: Jean-Christophe Plagniol-Villard 
Cc: Juergen Gross 
Cc: konrad.w...@oracle.com
Cc: Linus Torvalds 
Cc: linux-r...@vger.kernel.org
Cc: mche...@osg.samsung.com
Cc: "Michael S. Tsirkin" 
Cc: Mike Marciniszyn 
Cc: Rickard Strandqvist 
Cc: Roger Pau Monné 
Cc: Roland Dreier 
Cc: Sean Hefty 
Cc: Stefan Bader 
Cc: Suresh Siddha 
Cc: Thomas Gleixner 
Cc: Tomi Valkeinen 
Cc: toshi.k...@hp.com
Cc: Ville Syrjälä 
Link: 
http://lkml.kernel.org/r/1434053994-2196-4-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov 
---
 drivers/infiniband/hw/ipath/Kconfig   |  3 ++
 drivers/infiniband/hw/ipath/ipath_driver.c| 18 +++
 drivers/infiniband/hw/ipath/ipath_kernel.h|  4 +--
 drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 ++-
 4 files changed, 26 insertions(+), 42 deletions(-)

diff --git a/drivers/infiniband/hw/ipath/Kconfig 
b/drivers/infiniband/hw/ipath/Kconfig
index 1d9bb115cbf6..8fe54ff00580 100644
--- a/drivers/infiniband/hw/ipath/Kconfig
+++ b/drivers/infiniband/hw/ipath/Kconfig
@@ -9,3 +9,6 @@ config INFINIBAND_IPATH
as IP-over-InfiniBand as well as with userspace applications
(in conjunction with InfiniBand userspace access).
For QLogic PCIe QLE based cards, use the QIB driver instead.
+
+   If you have this hardware you will need to boot with PAT disabled
+   on your x86-64 systems, use the nopat kernel parameter.
diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c 
b/drivers/infiniband/hw/ipath/ipath_driver.c
index bd0caedafe99..2d7e503d13cb 100644
--- a/drivers/infiniband/hw/ipath/ipath_driver.c
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c
@@ -42,6 +42,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_X86_64
+#include 
+#endif
 
 #include "ipath_kernel.h"
 #include "ipath_verbs.h"
@@ -395,6 +398,14 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
unsigned long long addr;
u32 bar0 = 0, bar1 = 0;
 
+#ifdef CONFIG_X86_64
+   if (WARN(pat_enabled(),
+"ipath needs PAT disabled, boot with nopat kernel 
parameter\n")) {
+   ret = -ENODEV;
+   goto bail;
+   }
+#endif
+
dd = ipath_alloc_devdata(pdev);
if (IS_ERR(dd)) {
ret = PTR_ERR(dd);
@@ -542,6 +553,7 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
dd->ipath_kregbase = __ioremap(addr, len,
(_PAGE_NO_CACHE|_PAGE_WRITETHRU));
 #else
+   /* XXX: split this properly to enable on PAT */
dd->ipath_kregbase = ioremap_nocache(addr, len);
 #endif
 
@@ -587,12 +599,8 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 
ret = ipath_enable_wc(dd);
 
-   if (ret) {
-   ipath_dev_err(dd, "Write combining not enabled "
- "(err %d): performance may be poor\n",
- -ret);
+   if (ret)
ret = 0;
-   }
 
ipath_verify_pioperf(dd);
 
diff --git a/drivers/infiniband/hw/ipath/ipath_kernel.h 
b/drivers/infiniband/hw/ipath/ipath_kernel.h
index e08db7020cd4..f0f947122779 100644
--- a/drivers/infiniband/hw/ipath/ipath_kernel.h
+++ b/drivers/infiniband/hw/ipath/ipath_kernel.h
@@ -463,9 +463,7 @@ struct ipath_devdata {
/* offset in HT config space of slave/primary interface block */
u8 ipath_ht_slave_off;
/* for write combining settings */
-   unsigned long ipath_wc_cookie;
-   unsigned long ipath_wc_base;
-   unsigned long ipath_wc_len;
+   int wc_cookie;
/* ref count for each pkey */
atomic_t ipath_pkeyrefs[4];
/* shadow copy of struct page *'s for exp tid pages */
diff --git a/drivers/infiniband/hw

[Semaphore API] down_interruptible_timeout

[Mason]

Hello,

The semaphore API provides several flavors of the down primitive:

  down, down_interruptible, down_killable, down_trylock, down_timeout

As far as I can tell, they all call __down_common (except down_trylock,
which returns 1 where the others would sleep).

I was looking for a version
1) with a timeout
2) that could be interrupted
e.g. down_interruptible_timeout, but it doesn't exist.

It seems

  __down_common(sem, TASK_INTERRUPTIBLE, timeout);

would work as expected, no?

Do you know why it is not offered?
(Maybe there is a better way to achieve the same thing?)


[POST SCRIPTUM EDIT]
I found this 2007 discussion:
http://thread.gmane.org/gmane.linux.kernel/498034

At the time, Andrew said
"Nobody else has needed to invent new locking infrastructure
to do such things and I'd prefer not to do so now."
I suppose this is still true :-)
[/EDIT]


My use-case is pretty simple:

A) process-context kernel thread fills a FIFO and calls down(&fifo_empty);
B) ISR handles the FIFO-empty interrupt with up(&fifo_empty);

However, in case something goes wrong and the interrupt never fires,
I don't want the process to be stuck in an uninterruptible sleep.

Perhaps I can set a tiny timeout (e.g. 10 µs) and not worry about
the interruptible part for such a small duration? (Hmm, __down_common
calls schedule_timeout, which is jiffies-based. I don't think there
is a hrtimers flavor. So µs timeouts would be off the table?)

Or I could use the interruptible version, and let the user kill the
operation if necessary.

I'd like to hear your comments and suggestions.

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 10/12] mm: add the buddy system interface

[Kamezawa Hiroyuki]

On 2015/06/11 5:40, Luck, Tony wrote:

I guess, mirrored memory should be allocated if !__GFP_HIGHMEM or !__GFP_MOVABLE


HIGHMEM shouldn't matter - partial memory mirror only makes any sense on X86_64 
systems ... 32-bit kernels
don't even boot on systems with 64GB, and the minimum rational configuration 
for a machine that supports
mirror is 128GB (4 cpu sockets * 2 memory controller per socket * 4 channels 
per controller * 4GB DIMM ...
leaving any channels empty likely leaves you short of memory bandwidth for 
these high core count processors).

MOVABLE is mostly the opposite of MIRROR - we never want to fill a kernel 
allocation from a MOVABLE page. I
want all kernel allocations to be from MIRROR.



So, there are 3 ideas.

 (1) kernel only from MIRROR / user only from MOVABLE (Tony)
 (2) kernel only from MIRROR / user from MOVABLE + MIRROR(ASAP)  (AKPM 
suggested)
 This makes use of the fact MOVABLE memory is reclaimable but Tony pointed 
out
 the memory reclaim can be critical for GFP_ATOMIC.
 (3) kernel only from MIRROR / user from MOVABLE, special user from MIRROR 
(Xishi)

2 Implementation ideas.
  - creating ZONE
  - creating new alloation attribute

I don't convince whether we need some new structure in mm. Isn't it good to use
ZONE_MOVABLE for not-mirrored memory ?
Then, disable fallback from ZONE_MOVABLE -> ZONE_NORMAL for (1) and (3)

Thanks,
-Kame


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [BUG, bisect] Re: drm/i915: WARN_ON(dev_priv->mm.busy)

[Ville Syrjälä]

On Mon, Jun 15, 2015 at 01:25:38AM -0700, Jeremiah Mahler wrote:
> Daniel,
> 
> On Mon, Jun 15, 2015 at 08:57:47AM +0200, Daniel Vetter wrote:
> > Can you please retest with
> > 
> > commit 0aedb1626566efd72b369c01992ee7413c82a0c5
> > Author: Ville Syrjälä 
> > Date:   Thu May 28 18:32:36 2015 +0300
> > 
> > drm/i915: Don't skip request retirement if the active list is empty
> > 
> > Thanks, Daniel
> > 
> 
> The bug is still present with that patch applied.  And it is still
> present up to linux-next 20150611.

The patch was misapplied, so what's in the tree at the moment isn't what
I sent to the list.

-- 
Ville Syrjälä
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

[Sudeep Holla]

On 12/06/15 21:17, Doug Anderson wrote:

Hi,

On Fri, Jun 12, 2015 at 12:36 PM, Javier Martinez Canillas
 wrote:

registers are lost assuming the combiner was powered down, even the
status register will be lost and you will not know exactly the wakeup
reason right ?



Good question, I didn't find in the documentation I've access to that
this happen but just found through experimentation that the IRQ enable
set register values are lost after a resume and that saving/restoring
the values makes the interrupts to be triggered again.



I'll share here too the findings I mentioned over IRC. As you suggested I
add some printouts and noticed that the ISTRn (Interrupt Status) registers
values are indeed preserved on resume so I can know for example if the
wakeup source was the power gpio-key or cros_ec keyboard. I've checked the
values of the registers against the Exynos manual and they corresponds to
the interrupt sources in each case so the values are correct.

So as you said, it seems that is not that the IP block loses its state on
S2R but that something is blindly writing the IESRn (Interrupt Enable Set)
registers.


I'll postulate an alternate theory here.  You can tell me if you buy
it or if you think I've been out in the sun too long.

Let's say that the interrupt combiner's status registers show the raw
status as asserted by whatever is hooked up to the combiner.  This
means that even if the combiner got reset we could still read the
status register and get the status of the source.  Imagine that the
combiner is like a GPIO bank.  If you reset the GPIO bank, you'll lose
all kinds of config (input vs. output, edge interrupt status, maybe
pulls, etc).  ...but you can still read the state asserted by an
external source, right?



Right, this makes sense. I assumed status was latched output and might
be lost. But that's wrong assumption I believe.


In this case the combiner's interrupt source is 'EINT 11'.  ...and I'm
pretty sure that the controller managine 'EINT 11' _doesn't_ lose
power across suspend/resume...


I'll further bolster my theory by saying that _almost nothing_ in the
exynos keeps power across suspend/resume.  The UART?  Nope.  The GPIO
controllers?  Nuh-uh.  The GIC?  Sorry, but no.  The clock tree?  It
might be nice, but you're out of luck.  ...so it would make me
terribly surprised to see the combiner keep power.



Interesting even GIC loses power ? I would be interested in knowing more
details as who will wake up the system then. Is the wakeup source
offloaded to some external power controller ?




To reduce the possible s/w components that could be doing this, I booted a
signed FIT image directly using the RO U-Boot instead of chain loading a
mainline nv-uboot. In this configuration I've the same issue so it seems
that if something is zeroing those registers on S2R, this can't be changed
without void the warranty of these machines.

I also looked at the downstream ChromiumOS v3.8 tree [0] and I see that
they have a very similar solution than my patch, the IESRn are also saved
but using a notifier for the CPU_PM_ENTER and CPU_PM_EXIT events instead
or registering a syscore ops but the idea is basically the same.


Yup, you can see where kliegs added it in
.  As per the
comments in that CL, this was probably broken in:

063bd6f ARM: EXYNOS: Remove GIC save & restore function



I have to take a look to the U-boot that is shipped on the device, I think
the correct branch is [1] but I'm not sure if that is the correct one.


It is the right one.  If U-Boot were touching this (which would
greatly surprise me) it should be here:

arch/arm/include/asm/arch-exynos/cpu.h

...and it's not.  Doing a grep for '1044' (the combiner base
address) doesn't find anything in U-Boot either, which makes it less
likely.  ...and it's even less likely since the amount of code that is
in U-Boot that runs at resume time is a very small subset and I'm
fairly familiar with it and I would have remembered it touching the
combiner.



Yes, I did search and find nothing, so definitely not U-Boot if I am
looking at the right source.


It's POSSIBLE that the internal ROM in exynos is clobbering this, but
as per above it seems crazy unlikely and I think it's just losing
power.



Agreed, not because I believe ROM code are not crazy but because of the
theory you have provided above :)

Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv6 2/4] ARM: dts: exynos5422-odroidxu3: Enable TMU at Exynos5422 base

[Markus Reichl]

Hi Anand, Krzysztof

Am 15.06.2015 um 04:23 schrieb Anand Moon:
> hi Krzysztof
> 
> On 15 June 2015 at 05:41, Krzysztof Kozlowski  wrote:
>> On 14.06.2015 19:24, Anand Moon wrote:
>>> This changes enables TMU IP block on the Exynos5422 Odroid-XU3
>>> device.
>>>
>>> Signed-off-by: Anand Moon 
>>> Tested-by: Markus Reichl 
>>
>> This does not look right.
>> You put this "Tested-by" since beginning of this patchset (v1) but first
>> it was LDO10. Then you proposed LDO18 and now you use LDO7 from my
>> suggestion. Which of this was tested by Markus because I cannot find his
>> emails with it on LKML?
> 
> Markus Reichl tested the earlier version with LDO10.

This is right.

> Commit logs got carry forward by mistake.
> 
> -Anand Moon
> 
>>
>> Krzysztof
>>
>>> Acked-by: Lukasz Majewski 
>>> ---
>>> Changes rebase on 
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch 
>>> for-next
>>> Changes from v5: Use LDO7 regulator instead of LD010.
>>>
>>> The output of LDO18 goes to VDD_EMMC_1V8. This is not regulator for TMU.
>>>
>>> I think the schematics are missing some of details but it can be deducted 
>>> that:
>>> 1. TEMP SE is supplied by VDD18_TS power domain. It consists of 5
>>> pairs of pins (XTSTEST_OUT[0-4], XTSEXT_RES[0-4]).
>>> 2. The VDD18_TS01, VDD18_TS23 and VDD18_TS4 are wired to the LDO7 of
>>> S2MPS11 PMIC.
>>> 3. I confirmed with the Exynos5422 datasheet that these
>>> VDD18_TS{01,23,4} supply the XTSTEST pins (OUT and RES).
>>>
>>> So the LDO7 it is... but before using it there is a caveat. The LDO7
>>> is also connected to VDD of MIPI, HDMI and few more. So when you use
>>> this regulator in TMU it may be turned off by TMU driver (e.g. during
>>> unbind). In such case these other blocks also should be tested and
>>> checked whether they take this regulator and enable it.
>>> ---
>>>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 25 
>>> ++
>>>  1 file changed, 25 insertions(+)
>>
> 
> 


-- 
Markus Reichl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/21] On-demand device registration

[Linus Walleij]

On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler  wrote:

> And because you've said that "problem space is a bit convoluted" and I
> disagree, here's a summary from my point of view:
>
> 1. All the necessary information (dependencies between drivers) already
> exists at compile time. The set of dependencies between drivers might become
> smaller by configuration, but will not become larger. So there should be NO
> need to collect them at runtime, e.g. by instrumenting function calls.

I think you arrived at the core of the crux here.

When we look up a resource provided from another driver, e.g. from
regulator_get(), clk_get(), pinctrl_get(), gpiod_get() etc - the dependency
is resolved by looking in a cross-reference table for either a struct device*
pointer or a string, an index, or both or all three. Examples:

struct regulator *regulator_get(struct device *dev, const char *id);
struct clk *clk_get(struct device *dev, const char *id);
struct gpio_desc *__must_check __gpiod_get(struct device *dev,
 const char *con_id,
 enum gpiod_flags flags);
(...)

(*_index() variants exist on some of the resource retrieveal
functions.)

struct device * is the device requesting the resource, con_id
is the string name of the resource on the provider side. This is all
solved by looking in cross reference tables. ONE way of resolving
that cross reference is to look into the device tree or the ACPI table.
But for the board file case, this is resolved at runtime by the cross
reference table, registered with calls such as gpiod_add_lookup_table().

It is true that in the theoretical sense, all of this exist at compile time
especially if you can parse something like a device tree and
figure out what struct device * nodes will correspond to the struct
device_node:s in it. For ACPI I guess a similar procedure is viable.

Problem: this requires the kernel compile to know exactly *which* device tree
or ACPI table it is going to boot on. The expressed goal of device tree
and ACPI is to have *ONE* kernel booting several device trees.
Here your approach stops short: you are suggesting instrumenting
the kernel at compile time to one single device tree or ACPI table.
But we never know really what device tree or ACPI table will be used.
This just cannot be done at compile time for that reason alone.

Example: in boot case (A) the regulator may be provided by regulator
"foo" driver on an i2c bus. But in boot case (B) the very same regulator
may be provided by regulator "bar" on an SPI bus. These are very
real usecases, for example for drivers/net/ethernet/smsc/smsc911x.c,
will get regulators from the most diverse places depending on what
device tree is used.

For board files, it is neither possible in theory: you need to compile the
code to figure out the struct device * provider, and/or the string name
of the providing device (.name field in struct device for the provider)
to resolve dependencies at compile time.

For the board file case, resolving dependencies at compile time will
require a quite complex two-stage rocket: compile the code to
get resources out, then recompile with known resources.

I guess your suggested approach then need to introduce a special
build tool to order the initcalls accordingly.

Again this will fall short if you don't know at compile time exactly
*which* board file will be executed.

So the only practical way to solve this at compile time is to predict
an initcall ordering sequence for all possible boot paths, compile in
all of them, and choose the right one at boot. But the number of boot
paths is equal to the number of device trees / ACPI tables or
board files supported, and that space is uncontrolled and ordered
infinite.

Basically I think the root problem with your approach is that you
assume we know what hardware we will boot on at compile time. We
discarded that development path years ago. We have no clue, this
is resolved at runtime. Alas, people still create super-optimized
systems using exactly this knowledge, but it is not our main target
here, it is a special optimization case.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] x86, acpi: Eliminate saved_eip

[Borislav Petkov]

On Sun, Jun 14, 2015 at 03:23:08PM +0200, Denys Vlasenko wrote:
> It always contains the address of "ret_point" label

This commit message is very laconic - I had to go look at the code just
to see what you mean. I guess it should be something like:

"Get rid of the global variable saved_eip as it is only written to and
jump directly to ret_point instead. No functionality change."

Other than that, patch looks ok.

> Run-tested.
> 
> Signed-off-by: Denys Vlasenko 
> CC: Pavel Machek 
> CC: Linus Torvalds 
> CC: Steven Rostedt 
> CC: Ingo Molnar 
> CC: Borislav Petkov 
> CC: "H. Peter Anvin" 
> CC: Andy Lutomirski 
> CC: Oleg Nesterov 
> CC: Frederic Weisbecker 
> CC: Alexei Starovoitov 
> CC: Will Drewry 
> CC: Kees Cook 
> CC: x...@kernel.org
> CC: linux-kernel@vger.kernel.org
> ---
>  arch/x86/kernel/acpi/wakeup_32.S | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 07/15] KVM: MTRR: do not split 64 bits MSR content

[Xiao Guangrong]

Variable MTRR MSRs are 64 bits which are directly accessed with full length,
no reason to split them to two 32 bits

Signed-off-by: Xiao Guangrong 
---
 arch/x86/include/asm/kvm_host.h |  7 ++-
 arch/x86/kvm/mtrr.c | 32 ++--
 2 files changed, 16 insertions(+), 23 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 8d43006..f735548 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -342,8 +342,13 @@ enum {
KVM_DEBUGREG_RELOAD = 4,
 };
 
+struct kvm_mtrr_range {
+   u64 base;
+   u64 mask;
+};
+
 struct kvm_mtrr {
-   struct mtrr_var_range var_ranges[KVM_NR_VAR_MTRR];
+   struct kvm_mtrr_range var_ranges[KVM_NR_VAR_MTRR];
mtrr_type fixed_ranges[KVM_NR_FIXED_MTRR_REGION];
u64 deftype;
 };
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index 191de64..c4b80a4 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -161,10 +161,8 @@ static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
/* variable range MTRRs. */
is_fixed = false;
index = (msr - 0x200) / 2;
-   start = (((u64)mtrr_state->var_ranges[index].base_hi) << 32) +
-  (mtrr_state->var_ranges[index].base_lo & PAGE_MASK);
-   mask = (((u64)mtrr_state->var_ranges[index].mask_hi) << 32) +
-  (mtrr_state->var_ranges[index].mask_lo & PAGE_MASK);
+   start = mtrr_state->var_ranges[index].base & PAGE_MASK;
+   mask = mtrr_state->var_ranges[index].mask & PAGE_MASK;
mask |= ~0ULL << cpuid_maxphyaddr(vcpu);
 
end = ((start & mask) | ~mask) + 1;
@@ -195,17 +193,13 @@ int kvm_mtrr_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
data)
vcpu->arch.pat = data;
else {  /* Variable MTRRs */
int idx, is_mtrr_mask;
-   u64 *pt;
 
idx = (msr - 0x200) / 2;
is_mtrr_mask = msr - 0x200 - 2 * idx;
if (!is_mtrr_mask)
-   pt =
- (u64 *)&vcpu->arch.mtrr_state.var_ranges[idx].base_lo;
+   vcpu->arch.mtrr_state.var_ranges[idx].base = data;
else
-   pt =
- (u64 *)&vcpu->arch.mtrr_state.var_ranges[idx].mask_lo;
-   *pt = data;
+   vcpu->arch.mtrr_state.var_ranges[idx].mask = data;
}
 
update_mtrr(vcpu, msr);
@@ -243,17 +237,13 @@ int kvm_mtrr_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
*pdata)
*pdata = vcpu->arch.pat;
else {  /* Variable MTRRs */
int idx, is_mtrr_mask;
-   u64 *pt;
 
idx = (msr - 0x200) / 2;
is_mtrr_mask = msr - 0x200 - 2 * idx;
if (!is_mtrr_mask)
-   pt =
- (u64 *)&vcpu->arch.mtrr_state.var_ranges[idx].base_lo;
+   *pdata = vcpu->arch.mtrr_state.var_ranges[idx].base;
else
-   pt =
- (u64 *)&vcpu->arch.mtrr_state.var_ranges[idx].mask_lo;
-   *pdata = *pt;
+   *pdata = vcpu->arch.mtrr_state.var_ranges[idx].mask;
}
 
return 0;
@@ -305,13 +295,11 @@ static int get_mtrr_type(struct kvm_mtrr *mtrr_state,
for (i = 0; i < num_var_ranges; ++i) {
unsigned short start_state, end_state;
 
-   if (!(mtrr_state->var_ranges[i].mask_lo & (1 << 11)))
+   if (!(mtrr_state->var_ranges[i].mask & (1 << 11)))
continue;
 
-   base = (((u64)mtrr_state->var_ranges[i].base_hi) << 32) +
-  (mtrr_state->var_ranges[i].base_lo & PAGE_MASK);
-   mask = (((u64)mtrr_state->var_ranges[i].mask_hi) << 32) +
-  (mtrr_state->var_ranges[i].mask_lo & PAGE_MASK);
+   base = mtrr_state->var_ranges[i].base & PAGE_MASK;
+   mask = mtrr_state->var_ranges[i].mask & PAGE_MASK;
 
start_state = ((start & mask) == (base & mask));
end_state = ((end & mask) == (base & mask));
@@ -321,7 +309,7 @@ static int get_mtrr_type(struct kvm_mtrr *mtrr_state,
if ((start & mask) != (base & mask))
continue;
 
-   curr_match = mtrr_state->var_ranges[i].base_lo & 0xff;
+   curr_match = mtrr_state->var_ranges[i].base & 0xff;
if (prev_match == 0xFF) {
prev_match = curr_match;
continue;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 15/15] KVM: MTRR: do not map huage page for non-consistent range

[Xiao Guangrong]

Based on Intel's SDM, mapping huge page which do not have consistent
memory cache for each 4k page will cause undefined behavior

In order to avoiding this kind of undefined behavior, we force to use
4k pages under this case

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c  | 20 +++-
 arch/x86/kvm/mtrr.c | 29 +
 arch/x86/kvm/x86.h  |  2 ++
 3 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 532aad2..f807496 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3446,6 +3446,16 @@ static bool try_async_pf(struct kvm_vcpu *vcpu, bool 
prefault, gfn_t gfn,
return false;
 }
 
+static bool
+check_hugepage_cache_consistency(struct kvm_vcpu *vcpu, gfn_t gfn, int level)
+{
+   int page_num = KVM_PAGES_PER_HPAGE(level);
+
+   gfn &= ~(page_num - 1);
+
+   return kvm_mtrr_check_gfn_range_consistency(vcpu, gfn, page_num);
+}
+
 static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t gpa, u32 error_code,
  bool prefault)
 {
@@ -3471,9 +3481,17 @@ static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t 
gpa, u32 error_code,
if (r)
return r;
 
-   force_pt_level = mapping_level_dirty_bitmap(vcpu, gfn);
+   if (mapping_level_dirty_bitmap(vcpu, gfn) ||
+   !check_hugepage_cache_consistency(vcpu, gfn, PT_DIRECTORY_LEVEL))
+   force_pt_level = 1;
+   else
+   force_pt_level = 0;
+
if (likely(!force_pt_level)) {
level = mapping_level(vcpu, gfn);
+   if (level > PT_DIRECTORY_LEVEL &&
+   !check_hugepage_cache_consistency(vcpu, gfn, level))
+   level = PT_DIRECTORY_LEVEL;
gfn &= ~(KVM_PAGES_PER_HPAGE(level) - 1);
} else
level = PT_PAGE_TABLE_LEVEL;
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index 097d616..5b26048 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -677,3 +677,32 @@ u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, 
gfn_t gfn)
return type;
 }
 EXPORT_SYMBOL_GPL(kvm_mtrr_get_guest_memory_type);
+
+bool kvm_mtrr_check_gfn_range_consistency(struct kvm_vcpu *vcpu, gfn_t gfn,
+ int page_num)
+{
+   struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
+   struct mtrr_iter iter;
+   u64 start, end;
+   int type = -1;
+
+   start = gfn_to_gpa(gfn);
+   end = gfn_to_gpa(gfn + page_num);
+   mtrr_for_each_mem_type(&iter, mtrr_state, start, end) {
+   if (type == -1) {
+   type = iter.mem_type;
+   continue;
+   }
+
+   if (type != iter.mem_type)
+   return false;
+   }
+
+   if (!iter.partial_map)
+   return true;
+
+   if (type == -1)
+   return true;
+
+   return type == mtrr_default_type(mtrr_state);
+}
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index 0e4727c..edc8cdc 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -167,6 +167,8 @@ u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, 
gfn_t gfn);
 bool kvm_mtrr_valid(struct kvm_vcpu *vcpu, u32 msr, u64 data);
 int kvm_mtrr_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data);
 int kvm_mtrr_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata);
+bool kvm_mtrr_check_gfn_range_consistency(struct kvm_vcpu *vcpu, gfn_t gfn,
+ int page_num);
 
 #define KVM_SUPPORTED_XCR0 (XSTATE_FP | XSTATE_SSE | XSTATE_YMM \
| XSTATE_BNDREGS | XSTATE_BNDCSR \
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 06/15] KVM: MTRR: clean up mtrr default type

[Xiao Guangrong]

Drop kvm_mtrr->enable, omit the decode/code workload and get rid of
all the hard code

Signed-off-by: Xiao Guangrong 
---
 arch/x86/include/asm/kvm_host.h |  3 +--
 arch/x86/kvm/mtrr.c | 40 
 2 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index fe9cbe4..8d43006 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -345,8 +345,7 @@ enum {
 struct kvm_mtrr {
struct mtrr_var_range var_ranges[KVM_NR_VAR_MTRR];
mtrr_type fixed_ranges[KVM_NR_FIXED_MTRR_REGION];
-   unsigned char enabled;
-   mtrr_type def_type;
+   u64 deftype;
 };
 
 struct kvm_vcpu_arch {
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index ce061ff..191de64 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -22,6 +22,10 @@
 #include "cpuid.h"
 #include "mmu.h"
 
+#define IA32_MTRR_DEF_TYPE_E   (1ULL << 11)
+#define IA32_MTRR_DEF_TYPE_FE  (1ULL << 10)
+#define IA32_MTRR_DEF_TYPE_TYPE_MASK   (0xff)
+
 static bool msr_mtrr_valid(unsigned msr)
 {
switch (msr) {
@@ -101,10 +105,24 @@ bool kvm_mtrr_valid(struct kvm_vcpu *vcpu, u32 msr, u64 
data)
 }
 EXPORT_SYMBOL_GPL(kvm_mtrr_valid);
 
+static bool mtrr_is_enabled(struct kvm_mtrr *mtrr_state)
+{
+   return !!(mtrr_state->deftype & IA32_MTRR_DEF_TYPE_E);
+}
+
+static bool fixed_mtrr_is_enabled(struct kvm_mtrr *mtrr_state)
+{
+   return !!(mtrr_state->deftype & IA32_MTRR_DEF_TYPE_FE);
+}
+
+static u8 mtrr_default_type(struct kvm_mtrr *mtrr_state)
+{
+   return mtrr_state->deftype & IA32_MTRR_DEF_TYPE_TYPE_MASK;
+}
+
 static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
 {
struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
-   unsigned char mtrr_enabled = mtrr_state->enabled;
gfn_t start, end, mask;
int index;
bool is_fixed = true;
@@ -113,7 +131,7 @@ static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
  !kvm_arch_has_noncoherent_dma(vcpu->kvm))
return;
 
-   if (!(mtrr_enabled & 0x2) && msr != MSR_MTRRdefType)
+   if (!mtrr_is_enabled(mtrr_state) && msr != MSR_MTRRdefType)
return;
 
switch (msr) {
@@ -152,7 +170,7 @@ static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
end = ((start & mask) | ~mask) + 1;
}
 
-   if (is_fixed && !(mtrr_enabled & 0x1))
+   if (is_fixed && !fixed_mtrr_is_enabled(mtrr_state))
return;
 
kvm_zap_gfn_range(vcpu->kvm, gpa_to_gfn(start), gpa_to_gfn(end));
@@ -165,10 +183,9 @@ int kvm_mtrr_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
data)
if (!kvm_mtrr_valid(vcpu, msr, data))
return 1;
 
-   if (msr == MSR_MTRRdefType) {
-   vcpu->arch.mtrr_state.def_type = data;
-   vcpu->arch.mtrr_state.enabled = (data & 0xc00) >> 10;
-   } else if (msr == MSR_MTRRfix64K_0)
+   if (msr == MSR_MTRRdefType)
+   vcpu->arch.mtrr_state.deftype = data;
+   else if (msr == MSR_MTRRfix64K_0)
p[0] = data;
else if (msr == MSR_MTRRfix16K_8 || msr == MSR_MTRRfix16K_A)
p[1 + msr - MSR_MTRRfix16K_8] = data;
@@ -215,8 +232,7 @@ int kvm_mtrr_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
*pdata)
return 1;
 
if (msr == MSR_MTRRdefType)
-   *pdata = vcpu->arch.mtrr_state.def_type +
-(vcpu->arch.mtrr_state.enabled << 10);
+   *pdata = vcpu->arch.mtrr_state.deftype;
else if (msr == MSR_MTRRfix64K_0)
*pdata = p[0];
else if (msr == MSR_MTRRfix16K_8 || msr == MSR_MTRRfix16K_A)
@@ -255,14 +271,14 @@ static int get_mtrr_type(struct kvm_mtrr *mtrr_state,
int i, num_var_ranges = KVM_NR_VAR_MTRR;
 
/* MTRR is completely disabled, use UC for all of physical memory. */
-   if (!(mtrr_state->enabled & 0x2))
+   if (!mtrr_is_enabled(mtrr_state))
return MTRR_TYPE_UNCACHABLE;
 
/* Make end inclusive end, instead of exclusive */
end--;
 
/* Look in fixed ranges. Just return the type as per start */
-   if ((mtrr_state->enabled & 0x1) && (start < 0x10)) {
+   if (fixed_mtrr_is_enabled(mtrr_state) && (start < 0x10)) {
int idx;
 
if (start < 0x8) {
@@ -330,7 +346,7 @@ static int get_mtrr_type(struct kvm_mtrr *mtrr_state,
if (prev_match != 0xFF)
return prev_match;
 
-   return mtrr_state->def_type;
+   return mtrr_default_type(mtrr_state);
 }
 
 u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn)
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the

[PATCH v2 14/15] KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type

[Xiao Guangrong]

mtrr_for_each_mem_type() is ready now, use it to simplify
kvm_mtrr_get_guest_memory_type()

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mtrr.c | 64 ++---
 1 file changed, 16 insertions(+), 48 deletions(-)

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index 10f0148..097d616 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -609,61 +609,23 @@ static void mtrr_lookup_next(struct mtrr_iter *iter)
 u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn)
 {
struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
-   u64 base, mask, start;
-   int i, num_var_ranges, type;
+   struct mtrr_iter iter;
+   u64 start, end;
+   int type = -1;
const int wt_wb_mask = (1 << MTRR_TYPE_WRBACK)
   | (1 << MTRR_TYPE_WRTHROUGH);
 
start = gfn_to_gpa(gfn);
-   num_var_ranges = KVM_NR_VAR_MTRR;
-   type = -1;
-
-   /* MTRR is completely disabled, use UC for all of physical memory. */
-   if (!mtrr_is_enabled(mtrr_state))
-   return MTRR_TYPE_UNCACHABLE;
-
-   /* Look in fixed ranges. Just return the type as per start */
-   if (fixed_mtrr_is_enabled(mtrr_state) && (start < 0x10)) {
-   int idx;
-
-   if (start < 0x8) {
-   idx = 0;
-   idx += (start >> 16);
-   return mtrr_state->fixed_ranges[idx];
-   } else if (start < 0xC) {
-   idx = 1 * 8;
-   idx += ((start - 0x8) >> 14);
-   return mtrr_state->fixed_ranges[idx];
-   } else if (start < 0x100) {
-   idx = 3 * 8;
-   idx += ((start - 0xC) >> 12);
-   return mtrr_state->fixed_ranges[idx];
-   }
-   }
-
-   /*
-* Look in variable ranges
-* Look of multiple ranges matching this address and pick type
-* as per MTRR precedence
-*/
-   for (i = 0; i < num_var_ranges; ++i) {
-   int curr_type;
-
-   if (!(mtrr_state->var_ranges[i].mask & (1 << 11)))
-   continue;
-
-   base = mtrr_state->var_ranges[i].base & PAGE_MASK;
-   mask = mtrr_state->var_ranges[i].mask & PAGE_MASK;
+   end = start + PAGE_SIZE;
 
-   if ((start & mask) != (base & mask))
-   continue;
+   mtrr_for_each_mem_type(&iter, mtrr_state, start, end) {
+   int curr_type = iter.mem_type;
 
/*
 * Please refer to Intel SDM Volume 3: 11.11.4.1 MTRR
 * Precedences.
 */
 
-   curr_type = mtrr_state->var_ranges[i].base & 0xff;
if (type == -1) {
type = curr_type;
continue;
@@ -703,9 +665,15 @@ u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, 
gfn_t gfn)
return MTRR_TYPE_WRBACK;
}
 
-   if (type != -1)
-   return type;
-
-   return mtrr_default_type(mtrr_state);
+   /* It is not covered by MTRRs. */
+   if (iter.partial_map) {
+   /*
+* We just check one page, partially covered by MTRRs is
+* impossible.
+*/
+   WARN_ON(type != -1);
+   type = mtrr_default_type(mtrr_state);
+   }
+   return type;
 }
 EXPORT_SYMBOL_GPL(kvm_mtrr_get_guest_memory_type);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 13/15] KVM: MTRR: introduce mtrr_for_each_mem_type

[Xiao Guangrong]

It walks all MTRRs and gets all the memory cache type setting for the
specified range also it checks if the range is fully covered by MTRRs

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mtrr.c | 188 
 1 file changed, 188 insertions(+)

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index e5e16a1..10f0148 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -220,6 +220,15 @@ static int fixed_mtrr_seg_unit_range_index(int seg, int 
unit)
return mtrr_seg->range_start + 8 * unit;
 }
 
+static int fixed_mtrr_seg_end_range_index(int seg)
+{
+   struct fixed_mtrr_segment *mtrr_seg = &fixed_seg_table[seg];
+   int n;
+
+   n = (mtrr_seg->end - mtrr_seg->start) / mtrr_seg->range_size;
+   return mtrr_seg->range_start + n - 1;
+}
+
 static bool fixed_msr_to_range(u32 msr, u64 *start, u64 *end)
 {
int seg, unit;
@@ -266,6 +275,14 @@ static int fixed_mtrr_addr_seg_to_range_index(u64 addr, 
int seg)
return index;
 }
 
+static u64 fixed_mtrr_range_end_addr(int seg, int index)
+{
+   struct fixed_mtrr_segment *mtrr_seg = &fixed_seg_table[seg];
+   int pos = index - mtrr_seg->range_start;
+
+   return mtrr_seg->start + mtrr_seg->range_size * (pos + 1);
+}
+
 static void var_mtrr_range(struct kvm_mtrr_range *range, u64 *start, u64 *end)
 {
u64 mask;
@@ -418,6 +435,177 @@ void kvm_vcpu_mtrr_init(struct kvm_vcpu *vcpu)
INIT_LIST_HEAD(&vcpu->arch.mtrr_state.head);
 }
 
+struct mtrr_iter {
+   /* input fields. */
+   struct kvm_mtrr *mtrr_state;
+   u64 start;
+   u64 end;
+
+   /* output fields. */
+   int mem_type;
+   /* [start, end) is not fully covered in MTRRs? */
+   bool partial_map;
+
+   /* private fields. */
+   union {
+   /* used for fixed MTRRs. */
+   struct {
+   int index;
+   int seg;
+   };
+
+   /* used for var MTRRs. */
+   struct {
+   struct kvm_mtrr_range *range;
+   /* max address has been covered in var MTRRs. */
+   u64 start_max;
+   };
+   };
+
+   bool fixed;
+};
+
+static bool mtrr_lookup_fixed_start(struct mtrr_iter *iter)
+{
+   int seg, index;
+
+   if (!fixed_mtrr_is_enabled(iter->mtrr_state))
+   return false;
+
+   seg = fixed_mtrr_addr_to_seg(iter->start);
+   if (seg < 0)
+   return false;
+
+   iter->fixed = true;
+   index = fixed_mtrr_addr_seg_to_range_index(iter->start, seg);
+   iter->index = index;
+   iter->seg = seg;
+   return true;
+}
+
+static bool match_var_range(struct mtrr_iter *iter,
+   struct kvm_mtrr_range *range)
+{
+   u64 start, end;
+
+   var_mtrr_range(range, &start, &end);
+   if (!(start >= iter->end || end <= iter->start)) {
+   iter->range = range;
+
+   /*
+* the function is called when we do kvm_mtrr.head walking.
+* Range has the minimum base address which interleaves
+* [looker->start_max, looker->end).
+*/
+   iter->partial_map |= iter->start_max < start;
+
+   /* update the max address has been covered. */
+   iter->start_max = max(iter->start_max, end);
+   return true;
+   }
+
+   return false;
+}
+
+static void __mtrr_lookup_var_next(struct mtrr_iter *iter)
+{
+   struct kvm_mtrr *mtrr_state = iter->mtrr_state;
+
+   list_for_each_entry_continue(iter->range, &mtrr_state->head, node)
+   if (match_var_range(iter, iter->range))
+   return;
+
+   iter->range = NULL;
+   iter->partial_map |= iter->start_max < iter->end;
+}
+
+static void mtrr_lookup_var_start(struct mtrr_iter *iter)
+{
+   struct kvm_mtrr *mtrr_state = iter->mtrr_state;
+
+   iter->fixed = false;
+   iter->start_max = iter->start;
+   iter->range = list_prepare_entry(iter->range, &mtrr_state->head, node);
+
+   __mtrr_lookup_var_next(iter);
+}
+
+static void mtrr_lookup_fixed_next(struct mtrr_iter *iter)
+{
+   /* terminate the lookup. */
+   if (fixed_mtrr_range_end_addr(iter->seg, iter->index) >= iter->end) {
+   iter->fixed = false;
+   iter->range = NULL;
+   return;
+   }
+
+   iter->index++;
+
+   /* have looked up for all fixed MTRRs. */
+   if (iter->index >= ARRAY_SIZE(iter->mtrr_state->fixed_ranges))
+   return mtrr_lookup_var_start(iter);
+
+   /* switch to next segment. */
+   if (iter->index > fixed_mtrr_seg_end_range_index(iter->seg))
+   iter->seg++;
+}
+
+static void mtrr_lookup_var_next(struct mtrr_iter *iter)
+{
+   __mtrr_lookup_var_next(iter);
+}
+
+static void mtrr_lookup_start(struct mtrr_iter *iter)
+{
+   if (!mt

[PATCH v2 01/15] KVM: x86: fix CR0.CD virtualization

[Xiao Guangrong]

Currently, CR0.CD is not checked when we virtualize memory cache type for
noncoherent_dma guests, this patch fixes it by :

- setting UC for all memory if CR0.CD = 1
- zapping all the last sptes in MMU if CR0.CD is changed

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/vmx.c | 32 ++--
 arch/x86/kvm/x86.c |  4 
 2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 06a186b..2764381 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8628,7 +8628,8 @@ static int get_ept_level(void)
 
 static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
 {
-   u64 ret;
+   u8 cache;
+   u64 ipat = 0;
 
/* For VT-d and EPT combination
 * 1. MMIO: always map as UC
@@ -8641,16 +8642,27 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t 
gfn, bool is_mmio)
 * 3. EPT without VT-d: always map as WB and set IPAT=1 to keep
 *consistent with host MTRR
 */
-   if (is_mmio)
-   ret = MTRR_TYPE_UNCACHABLE << VMX_EPT_MT_EPTE_SHIFT;
-   else if (kvm_arch_has_noncoherent_dma(vcpu->kvm))
-   ret = kvm_get_guest_memory_type(vcpu, gfn) <<
- VMX_EPT_MT_EPTE_SHIFT;
-   else
-   ret = (MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT)
-   | VMX_EPT_IPAT_BIT;
+   if (is_mmio) {
+   cache = MTRR_TYPE_UNCACHABLE;
+   goto exit;
+   }
 
-   return ret;
+   if (!kvm_arch_has_noncoherent_dma(vcpu->kvm)) {
+   ipat = VMX_EPT_IPAT_BIT;
+   cache = MTRR_TYPE_WRBACK;
+   goto exit;
+   }
+
+   if (kvm_read_cr0(vcpu) & X86_CR0_CD) {
+   ipat = VMX_EPT_IPAT_BIT;
+   cache = MTRR_TYPE_UNCACHABLE;
+   goto exit;
+   }
+
+   cache = kvm_get_guest_memory_type(vcpu, gfn);
+
+exit:
+   return (cache << VMX_EPT_MT_EPTE_SHIFT) | ipat;
 }
 
 static int vmx_get_lpage_level(void)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 43f0df7..43fdb10 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -621,6 +621,10 @@ int kvm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
 
if ((cr0 ^ old_cr0) & update_bits)
kvm_mmu_reset_context(vcpu);
+
+   if ((cr0 ^ old_cr0) & X86_CR0_CD)
+   kvm_zap_gfn_range(vcpu->kvm, 0, ~0ULL);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(kvm_set_cr0);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 08/15] KVM: MTRR: improve kvm_mtrr_get_guest_memory_type

[Xiao Guangrong]

 - kvm_mtrr_get_guest_memory_type() only checks one page in MTRRs so
   that it's unnecessary to check to see if the range is partially
   covered in MTRR

 - optimize the check of overlap memory type and add some comments
   to explain the precedence

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mtrr.c | 94 -
 1 file changed, 49 insertions(+), 45 deletions(-)

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index c4b80a4..2ea1213 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -249,24 +249,22 @@ int kvm_mtrr_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
*pdata)
return 0;
 }
 
-/*
- * The function is based on mtrr_type_lookup() in
- * arch/x86/kernel/cpu/mtrr/generic.c
- */
-static int get_mtrr_type(struct kvm_mtrr *mtrr_state,
-u64 start, u64 end)
+u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn)
 {
-   u64 base, mask;
-   u8 prev_match, curr_match;
-   int i, num_var_ranges = KVM_NR_VAR_MTRR;
+   struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
+   u64 base, mask, start;
+   int i, num_var_ranges, type;
+   const int wt_wb_mask = (1 << MTRR_TYPE_WRBACK)
+  | (1 << MTRR_TYPE_WRTHROUGH);
+
+   start = gfn_to_gpa(gfn);
+   num_var_ranges = KVM_NR_VAR_MTRR;
+   type = -1;
 
/* MTRR is completely disabled, use UC for all of physical memory. */
if (!mtrr_is_enabled(mtrr_state))
return MTRR_TYPE_UNCACHABLE;
 
-   /* Make end inclusive end, instead of exclusive */
-   end--;
-
/* Look in fixed ranges. Just return the type as per start */
if (fixed_mtrr_is_enabled(mtrr_state) && (start < 0x10)) {
int idx;
@@ -291,9 +289,8 @@ static int get_mtrr_type(struct kvm_mtrr *mtrr_state,
 * Look of multiple ranges matching this address and pick type
 * as per MTRR precedence
 */
-   prev_match = 0xFF;
for (i = 0; i < num_var_ranges; ++i) {
-   unsigned short start_state, end_state;
+   int curr_type;
 
if (!(mtrr_state->var_ranges[i].mask & (1 << 11)))
continue;
@@ -301,50 +298,57 @@ static int get_mtrr_type(struct kvm_mtrr *mtrr_state,
base = mtrr_state->var_ranges[i].base & PAGE_MASK;
mask = mtrr_state->var_ranges[i].mask & PAGE_MASK;
 
-   start_state = ((start & mask) == (base & mask));
-   end_state = ((end & mask) == (base & mask));
-   if (start_state != end_state)
-   return 0xFE;
-
if ((start & mask) != (base & mask))
continue;
 
-   curr_match = mtrr_state->var_ranges[i].base & 0xff;
-   if (prev_match == 0xFF) {
-   prev_match = curr_match;
+   /*
+* Please refer to Intel SDM Volume 3: 11.11.4.1 MTRR
+* Precedences.
+*/
+
+   curr_type = mtrr_state->var_ranges[i].base & 0xff;
+   if (type == -1) {
+   type = curr_type;
continue;
}
 
-   if (prev_match == MTRR_TYPE_UNCACHABLE ||
-   curr_match == MTRR_TYPE_UNCACHABLE)
+   /*
+* If two or more variable memory ranges match and the
+* memory types are identical, then that memory type is
+* used.
+*/
+   if (type == curr_type)
+   continue;
+
+   /*
+* If two or more variable memory ranges match and one of
+* the memory types is UC, the UC memory type used.
+*/
+   if (curr_type == MTRR_TYPE_UNCACHABLE)
return MTRR_TYPE_UNCACHABLE;
 
-   if ((prev_match == MTRR_TYPE_WRBACK &&
-curr_match == MTRR_TYPE_WRTHROUGH) ||
-   (prev_match == MTRR_TYPE_WRTHROUGH &&
-curr_match == MTRR_TYPE_WRBACK)) {
-   prev_match = MTRR_TYPE_WRTHROUGH;
-   curr_match = MTRR_TYPE_WRTHROUGH;
+   /*
+* If two or more variable memory ranges match and the
+* memory types are WT and WB, the WT memory type is used.
+*/
+   if (((1 << type) & wt_wb_mask) &&
+ ((1 << curr_type) & wt_wb_mask)) {
+   type = MTRR_TYPE_WRTHROUGH;
+   continue;
}
 
-   if (prev_match != curr_match)
-   return MTRR_TYPE_UNCACHABLE;
+   /*
+* For overlaps not defined by the above rules, processor
+* behavior is undefined.
+*/
+
+   /* We use WB for this undefined b

[PATCH v2 10/15] KVM: MTRR: introduce var_mtrr_range

[Xiao Guangrong]

It gets the range for the specified variable MTRR

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mtrr.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index df73149..cb9702d 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -241,10 +241,21 @@ static int fixed_msr_to_range_index(u32 msr)
return fixed_mtrr_seg_unit_range_index(seg, unit);
 }
 
+static void var_mtrr_range(struct kvm_mtrr_range *range, u64 *start, u64 *end)
+{
+   u64 mask;
+
+   *start = range->base & PAGE_MASK;
+
+   mask = range->mask & PAGE_MASK;
+   mask |= ~0ULL << boot_cpu_data.x86_phys_bits;
+   *end = ((*start & mask) | ~mask) + 1;
+}
+
 static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
 {
struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
-   gfn_t start, end, mask;
+   gfn_t start, end;
int index;
 
if (msr == MSR_IA32_CR_PAT || !tdp_enabled ||
@@ -264,11 +275,7 @@ static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
} else {
/* variable range MTRRs. */
index = (msr - 0x200) / 2;
-   start = mtrr_state->var_ranges[index].base & PAGE_MASK;
-   mask = mtrr_state->var_ranges[index].mask & PAGE_MASK;
-   mask |= ~0ULL << cpuid_maxphyaddr(vcpu);
-
-   end = ((start & mask) | ~mask) + 1;
+   var_mtrr_range(&mtrr_state->var_ranges[index], &start, &end);
}
 
kvm_zap_gfn_range(vcpu->kvm, gpa_to_gfn(start), gpa_to_gfn(end));
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 11/15] KVM: MTRR: sort variable MTRRs

[Xiao Guangrong]

Sort all valid variable MTRRs based on its base address, it will help us to
check a range to see if it's fully contained in variable MTRRs

Signed-off-by: Xiao Guangrong 
---
 arch/x86/include/asm/kvm_host.h |  3 ++
 arch/x86/kvm/mtrr.c | 63 ++---
 arch/x86/kvm/x86.c  |  2 +-
 arch/x86/kvm/x86.h  |  1 +
 4 files changed, 58 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index f735548..f2d60cc 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -345,12 +345,15 @@ enum {
 struct kvm_mtrr_range {
u64 base;
u64 mask;
+   struct list_head node;
 };
 
 struct kvm_mtrr {
struct kvm_mtrr_range var_ranges[KVM_NR_VAR_MTRR];
mtrr_type fixed_ranges[KVM_NR_FIXED_MTRR_REGION];
u64 deftype;
+
+   struct list_head head;
 };
 
 struct kvm_vcpu_arch {
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index cb9702d..c06ec13 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -281,6 +281,52 @@ static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
kvm_zap_gfn_range(vcpu->kvm, gpa_to_gfn(start), gpa_to_gfn(end));
 }
 
+static bool var_mtrr_range_is_valid(struct kvm_mtrr_range *range)
+{
+   u64 start, end;
+
+   if (!(range->mask & (1 << 11)))
+   return false;
+
+   var_mtrr_range(range, &start, &end);
+   return end > start;
+}
+
+static void set_var_mtrr_start(struct kvm_mtrr *mtrr_state, int index)
+{
+   /* remove the entry if it's in the list. */
+   if (var_mtrr_range_is_valid(&mtrr_state->var_ranges[index]))
+   list_del(&mtrr_state->var_ranges[index].node);
+}
+
+static void set_var_mtrr_end(struct kvm_mtrr *mtrr_state, int index)
+{
+   struct kvm_mtrr_range *tmp, *cur = &mtrr_state->var_ranges[index];
+
+   /* add it to the list if it's valid. */
+   if (var_mtrr_range_is_valid(&mtrr_state->var_ranges[index])) {
+   list_for_each_entry(tmp, &mtrr_state->head, node)
+   if (cur->base < tmp->base)
+   list_add_tail(&cur->node, &tmp->node);
+
+   list_add_tail(&cur->node, &mtrr_state->head);
+   }
+}
+
+static void set_var_mtrr_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data)
+{
+   int index, is_mtrr_mask;
+
+   index = (msr - 0x200) / 2;
+   is_mtrr_mask = msr - 0x200 - 2 * index;
+   set_var_mtrr_start(&vcpu->arch.mtrr_state, index);
+   if (!is_mtrr_mask)
+   vcpu->arch.mtrr_state.var_ranges[index].base = data;
+   else
+   vcpu->arch.mtrr_state.var_ranges[index].mask = data;
+   set_var_mtrr_end(&vcpu->arch.mtrr_state, index);
+}
+
 int kvm_mtrr_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data)
 {
int index;
@@ -295,16 +341,8 @@ int kvm_mtrr_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
data)
vcpu->arch.mtrr_state.deftype = data;
else if (msr == MSR_IA32_CR_PAT)
vcpu->arch.pat = data;
-   else {  /* Variable MTRRs */
-   int is_mtrr_mask;
-
-   index = (msr - 0x200) / 2;
-   is_mtrr_mask = msr - 0x200 - 2 * index;
-   if (!is_mtrr_mask)
-   vcpu->arch.mtrr_state.var_ranges[index].base = data;
-   else
-   vcpu->arch.mtrr_state.var_ranges[index].mask = data;
-   }
+   else
+   set_var_mtrr_msr(vcpu, msr, data);
 
update_mtrr(vcpu, msr);
return 0;
@@ -350,6 +388,11 @@ int kvm_mtrr_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
*pdata)
return 0;
 }
 
+void kvm_vcpu_mtrr_init(struct kvm_vcpu *vcpu)
+{
+   INIT_LIST_HEAD(&vcpu->arch.mtrr_state.head);
+}
+
 u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn)
 {
struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2ffad7f..6574fa3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7379,13 +7379,13 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
 {
int r;
 
+   kvm_vcpu_mtrr_init(vcpu);
r = vcpu_load(vcpu);
if (r)
return r;
kvm_vcpu_reset(vcpu, false);
kvm_mmu_setup(vcpu);
vcpu_put(vcpu);
-
return r;
 }
 
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index aeb0bb2..0e4727c 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -162,6 +162,7 @@ int kvm_write_guest_virt_system(struct x86_emulate_ctxt 
*ctxt,
gva_t addr, void *val, unsigned int bytes,
struct x86_exception *exception);
 
+void kvm_vcpu_mtrr_init(struct kvm_vcpu *vcpu);
 u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn);
 bool kvm_mtrr_valid(struct kvm_vcpu *vcpu, u32 msr, u64 data);
 int kvm_mtrr_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data);
-- 
2.1.0

--
To unsubscribe from thi

Re: latency histogram with BPF

[Daniel Wagner]

On 06/12/2015 07:17 PM, Alexei Starovoitov wrote:
> On 6/12/15 7:33 AM, Daniel Wagner wrote:
>> On 06/12/2015 08:12 AM, Daniel Wagner wrote:
>> Attaching kprobes to trace_preempt_[on|off] works fine. Empty BPF
>> programs connected to the probes is no problem as well. So I changed the
>> BPF program to use only arrays instead of hash tables. No crash anymore.
> 
> yes. I've tried that too. arrays work fine indeed.
> 
>> I suspect the hash table code will call trace_preempt_[off|on]
>> eventually and that is not going to fly.
> 
> The recursive calls into bpf programs are detected and prevented.
> That's ok. I've tested attaching kprobes to kmalloc/kfree and
> from the program do hash_map->update_elem->kmalloc which triggers
> recursive call into the same program. All works fine.
> There is something else here.

If the first map is an array all is fine too. So it seems it need two
hash tables to trigger it.

@@ -11,7 +11,7 @@
 #include "bpf_helpers.h"

 struct bpf_map_def SEC("maps") my_map = {
-   .type = BPF_MAP_TYPE_HASH,
+   .type = BPF_MAP_TYPE_ARRAY,
.key_size = sizeof(unsigned int),
.value_size = sizeof(u64),
.max_entries = 1024,
@@ -45,9 +45,10 @@ SEC("kprobe/trace_preempt_off")
 int bpf_prog1(struct pt_regs *ctx)
 {
int cpu = bpf_get_smp_processor_id();
-   u64 ts = bpf_ktime_get_ns();
+   u64 *ts = bpf_map_lookup_elem(&my_map, &cpu);

-   bpf_map_update_elem(&my_map, &cpu, &ts, BPF_ANY);
+   if (ts)
+   *ts = bpf_ktime_get_ns();

return 0;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 09/15] KVM: MTRR: introduce fixed_mtrr_segment table

[Xiao Guangrong]

This table summarizes the information of fixed MTRRs and introduce some APIs
to abstract its operation which helps us to clean up the code and will be
used in later patches

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mtrr.c | 200 ++--
 1 file changed, 147 insertions(+), 53 deletions(-)

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index 2ea1213..df73149 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -120,12 +120,132 @@ static u8 mtrr_default_type(struct kvm_mtrr *mtrr_state)
return mtrr_state->deftype & IA32_MTRR_DEF_TYPE_TYPE_MASK;
 }
 
+/*
+* Three terms are used in the following code:
+* - segment, it indicates the address segments covered by fixed MTRRs.
+* - unit, it corresponds to the MSR entry in the segment.
+* - range, a range is covered in one memory cache type.
+*/
+struct fixed_mtrr_segment {
+   u64 start;
+   u64 end;
+
+   u64 range_size;
+
+   /* the start position in kvm_mtrr.fixed_ranges[]. */
+   int range_start;
+};
+
+static struct fixed_mtrr_segment fixed_seg_table[] = {
+   /* MSR_MTRRfix64K_0, 1 unit. 64K fixed mtrr. */
+   {
+   .start = 0x0,
+   .end = 0x8,
+   .range_size = 64 * 1024,
+   .range_start = 0,
+   },
+
+   /*
+* MSR_MTRRfix16K_8 ... MSR_MTRRfix16K_A, 2 units,
+* 16K fixed mtrr.
+*/
+   {
+   .start = 0x8,
+   .end = 0xc,
+   .range_size = 16 * 1024,
+   .range_start = 8,
+   },
+
+   /*
+* MSR_MTRRfix4K_C ... MSR_MTRRfix4K_F8000, 8 units,
+* 4K fixed mtrr.
+*/
+   {
+   .start = 0xc,
+   .end = 0x10,
+   .range_size = 4 * 1024,
+   .range_start = 24,
+   }
+};
+
+/*
+ * The size of unit is covered in one MSR, one MSR entry contains
+ * 8 ranges so that unit size is always range_size * 8.
+ */
+static u64 fixed_mtrr_seg_unit_size(int seg)
+{
+   return fixed_seg_table[seg].range_size * 8;
+}
+
+static bool fixed_msr_to_seg_unit(u32 msr, int *seg, int *unit)
+{
+   switch (msr) {
+   case MSR_MTRRfix64K_0:
+   *seg = 0;
+   *unit = 0;
+   break;
+   case MSR_MTRRfix16K_8 ... MSR_MTRRfix16K_A:
+   *seg = 1;
+   *unit = msr - MSR_MTRRfix16K_8;
+   break;
+   case MSR_MTRRfix4K_C ... MSR_MTRRfix4K_F8000:
+   *seg = 2;
+   *unit = msr - MSR_MTRRfix4K_C;
+   break;
+   default:
+   return false;
+   }
+
+   return true;
+}
+
+static void fixed_mtrr_seg_unit_range(int seg, int unit, u64 *start, u64 *end)
+{
+   struct fixed_mtrr_segment *mtrr_seg = &fixed_seg_table[seg];
+   u64 unit_size = fixed_mtrr_seg_unit_size(seg);
+
+   *start = mtrr_seg->start + unit * unit_size;
+   *end = *start + unit_size;
+   WARN_ON(*end > mtrr_seg->end);
+}
+
+static int fixed_mtrr_seg_unit_range_index(int seg, int unit)
+{
+   struct fixed_mtrr_segment *mtrr_seg = &fixed_seg_table[seg];
+
+   WARN_ON(mtrr_seg->start + unit * fixed_mtrr_seg_unit_size(seg)
+   > mtrr_seg->end);
+
+   /* each unit has 8 ranges. */
+   return mtrr_seg->range_start + 8 * unit;
+}
+
+static bool fixed_msr_to_range(u32 msr, u64 *start, u64 *end)
+{
+   int seg, unit;
+
+   if (!fixed_msr_to_seg_unit(msr, &seg, &unit))
+   return false;
+
+   fixed_mtrr_seg_unit_range(seg, unit, start, end);
+   return true;
+}
+
+static int fixed_msr_to_range_index(u32 msr)
+{
+   int seg, unit;
+
+   if (!fixed_msr_to_seg_unit(msr, &seg, &unit))
+   return -1;
+
+   return fixed_mtrr_seg_unit_range_index(seg, unit);
+}
+
 static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
 {
struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
gfn_t start, end, mask;
int index;
-   bool is_fixed = true;
 
if (msr == MSR_IA32_CR_PAT || !tdp_enabled ||
  !kvm_arch_has_noncoherent_dma(vcpu->kvm))
@@ -134,32 +254,15 @@ static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
if (!mtrr_is_enabled(mtrr_state) && msr != MSR_MTRRdefType)
return;
 
-   switch (msr) {
-   case MSR_MTRRfix64K_0:
-   start = 0x0;
-   end = 0x8;
-   break;
-   case MSR_MTRRfix16K_8:
-   start = 0x8;
-   end = 0xa;
-   break;
-   case MSR_MTRRfix16K_A:
-   start = 0xa;
-   end = 0xc;
-   break;
-   case MSR_MTRRfix4K_C ... MSR_MTRRfix4K_F8000:
-   index = msr - MSR_MTRRfix4K_C;
-   start = 0xc + index * (32 << 10);
-   end = start + (32 << 10);
-   brea

[PATCH v2 12/15] KVM: MTRR: introduce fixed_mtrr_addr_* functions

[Xiao Guangrong]

Two functions are introduced:
- fixed_mtrr_addr_to_seg() translates the address to the fixed
  MTRR segment

- fixed_mtrr_addr_seg_to_range_index() translates the address to
  the index of kvm_mtrr.fixed_ranges[]

They will be used in the later patch

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mtrr.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index c06ec13..e5e16a1 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -241,6 +241,31 @@ static int fixed_msr_to_range_index(u32 msr)
return fixed_mtrr_seg_unit_range_index(seg, unit);
 }
 
+static int fixed_mtrr_addr_to_seg(u64 addr)
+{
+   struct fixed_mtrr_segment *mtrr_seg;
+   int seg, seg_num = ARRAY_SIZE(fixed_seg_table);
+
+   for (seg = 0; seg < seg_num; seg++) {
+   mtrr_seg = &fixed_seg_table[seg];
+   if (mtrr_seg->start >= addr && addr < mtrr_seg->end)
+   return seg;
+   }
+
+   return -1;
+}
+
+static int fixed_mtrr_addr_seg_to_range_index(u64 addr, int seg)
+{
+   struct fixed_mtrr_segment *mtrr_seg;
+   int index;
+
+   mtrr_seg = &fixed_seg_table[seg];
+   index = mtrr_seg->range_start;
+   index += (addr - mtrr_seg->start) / mtrr_seg->range_size;
+   return index;
+}
+
 static void var_mtrr_range(struct kvm_mtrr_range *range, u64 *start, u64 *end)
 {
u64 mask;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

[Sudeep Holla]

On 15/06/15 08:46, Javier Martinez Canillas wrote:
[...]



Sudeep, so we may need something like $subject after all from Doug's
explanations since the combiner chip state is lost during a S2R. I know
that it adds more duplicated code (others irqchip drivers do the same)
and it may not scale well if a chip has many registers but is the best
solution I could came with.



OK


If you have a suggestion for a better alternative, I can give a try and
write the patch. But I think $subject could also land to fix this issue
since is a very non intrusive change and later can be changed once the
irqchip core supports this use case.



Agreed. But I would suggest also to add MASK_ON_SUSPEND and set_irq_wake
also and then you can restore iff it's non-zero as irq core will take
care of most of the non-wakeup sources. Because I am planning to push
MASK_ON_SUSPEND to GIC and it will break this combiner if it assumes the
combiner interrupts are always on in GIC. Implement set_irq_wake as
enable_irq_wake (comb_irq_to_GIC).

Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkp] [drm/i915] 7f072451f2d: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun

[Maarten Lankhorst]

Hey,

Op 15-06-15 om 08:58 schreef Huang Ying:
> FYI, we noticed the below changes on
>
> git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
> commit 7f072451f2d3d53e4f6939440e15ab36afed2051 ("drm/i915: Implement 
> intel_crtc_control using atomic state, v4")
>
> Test Environment check: Succeeded.
> [0/2]  Running Test(s): 0
> [   87.315159] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
> pipe B FIFO underrun
> [   87.323386] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH 
> transcoder B FIFO underrun
> [1/2] pass: 1 Running Test(s): 1
> [2/2] dmesg-warn: 1, pass: 1
> Thank you for running Piglit!
> Results have been written to /tmp/lkp/piglit-results-0/results.json
> igt/kms_flip/rcs-wf_vblank-vs-dpms.seconds: 129.532452335
> 2015-06-12 04:39:32 piglit summary console /tmp/lkp/piglit-results-0
> igt/kms_flip/rcs-wf_vblank-vs-dpms: pass
> igt/kms_flip/rcs-wf_vblank-vs-dpms-interruptible: dmesg-warn
> summary:
>pass: 1
>fail: 0
>   crash: 0
>skip: 0
> timeout: 0
>warn: 0
>  dmesg-warn: 1
>  dmesg-fail: 0
>   total: 2
> all tests finished
>
>
> To reproduce:
>
>   apt-get install ruby
>   git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>   cd lkp-tests
>   bin/setup-local job.yaml # the job file attached in this email
>   bin/run-local   job.yaml
>
Are there any tests that already have FIFO underruns, before this commit?

~Maarten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Jun 15

[Michael Ellerman]

Hi all,

Changes since 20150612:

The arm-soc tree lost its build failure.

The rdma tree gained two conflicts against the net-next tree.

The tip tree lost its build failure.

The staging tree gained a conflict against the rdma tree.

Non-merge commits (relative to Linus' tree): 10544
 9271 files changed, 997810 insertions(+), 222890 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 219 trees (counting Linus' and 31 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.


cheers


$ git checkout master
$ git reset --hard stable
Merging origin/master (c8d17b451aa1 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (0bbe6b5a73c0 ARM: 8388/1: tcm: Don't crash when TCM 
banks are protected by TrustZone)
Merging m68k-current/for-linus (b24f670b7f5b m68k/mac: Fix out-of-bounds array 
index in OSS IRQ source initialization)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge-mpe/fixes (c65b99f04684 Linux 4.1-rc6)
Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1)
Merging sparc/master (c46a024ea5eb Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (2d45a02d0166 sctp: fix ASCONF list handling)
Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at 
start of day.)
Merging sound-current/for-linus (535115b5ff51 ALSA: hda - Abort the probe 
without i915 binding for HSW/BDW)
Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during 
alignment reordering)
Merging wireless-drivers/master (38fe44e61a89 Merge tag 
'iwlwifi-for-kalle-2015-05-28' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging tty.current/tty-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging usb.current/usb-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging usb-gadget-fixes/fixes (c94e289f195e usb: gadget: remove incorrect 
__init/__exit annotations)
Merging usb-serial-fixes/usb-linus (df72d588c54d USB: cp210x: add ID for HubZ 
dual ZigBee and Z-Wave dongle)
Merging staging.current/staging-linus (d4a4f75cd8f2 Linux 4.1-rc7)
Merging char-misc.current/char-misc-linus (e26081808eda Linux 4.1-rc4)
Merging input-current/for-linus (7f2ca8b55aef Input: synaptics - add min/max 
quirk for Lenovo S540)
Merging crypto-current/master (f858c7bcca8c crypto: algif_aead - Disable AEAD 
user-space for now)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (f36963c9d3f6 cpumask_set_cpu_local_first => 
cpumask_local_spread, lament)
Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible 
timeout)
Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DEFER while requesting the PWM)
Merging drm-intel-fixes/for-linux-next-fixes (2a8b35837c51 drm/i915: Always 
reset vma->ggtt_view.pages cache on unbinding)
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic)
Merging arc/for-next (359

[PATCH v2 03/15] KVM: MTRR: handle MSR_MTRRcap in kvm_mtrr_get_msr

[Xiao Guangrong]

MSR_MTRRcap is a MTRR msr so move the handler to the common place, also
add some comments to make the hard code more readable

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mtrr.c | 12 
 arch/x86/kvm/x86.c  |  2 --
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index fb2f7e1..a05846a 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -199,6 +199,18 @@ int kvm_mtrr_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
*pdata)
 {
u64 *p = (u64 *)&vcpu->arch.mtrr_state.fixed_ranges;
 
+   /* MSR_MTRRcap is a readonly MSR. */
+   if (msr == MSR_MTRRcap) {
+   /*
+* SMRR = 0
+* WC = 1
+* FIX = 1
+* VCNT = KVM_NR_VAR_MTRR
+*/
+   *pdata = 0x500 | KVM_NR_VAR_MTRR;
+   return 0;
+   }
+
if (!msr_mtrr_valid(msr))
return 1;
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e2bc798..fb6c9a1 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2443,8 +2443,6 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
msr_info->data = 0x1ULL;
break;
case MSR_MTRRcap:
-   msr_info->data = 0x500 | KVM_NR_VAR_MTRR;
-   break;
case 0x200 ... 0x2ff:
return kvm_mtrr_get_msr(vcpu, msr_info->index, &msr_info->data);
case 0xcd: /* fsb frequency */
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 02/15] KVM: x86: move MTRR related code to a separate file

[Xiao Guangrong]

MTRR code locates in x86.c and mmu.c so that move them to a separate file to
make the organization more clearer and it will be the place where we fully
implement vMTRR

Signed-off-by: Xiao Guangrong 
---
 arch/x86/include/asm/kvm_host.h |   1 -
 arch/x86/kvm/Makefile   |   2 +-
 arch/x86/kvm/mmu.c  | 103 
 arch/x86/kvm/mtrr.c | 335 
 arch/x86/kvm/vmx.c  |   2 +-
 arch/x86/kvm/x86.c  | 214 +
 arch/x86/kvm/x86.h  |   3 +
 7 files changed, 342 insertions(+), 318 deletions(-)
 create mode 100644 arch/x86/kvm/mtrr.c

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 8ca32cf..cf8d320 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -894,7 +894,6 @@ int load_pdptrs(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, 
unsigned long cr3);
 
 int emulator_write_phys(struct kvm_vcpu *vcpu, gpa_t gpa,
  const void *val, int bytes);
-u8 kvm_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn);
 
 struct kvm_irq_mask_notifier {
void (*func)(struct kvm_irq_mask_notifier *kimn, bool masked);
diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index 16e8f96..470dc6c9 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86/kvm/Makefile
@@ -12,7 +12,7 @@ kvm-y += $(KVM)/kvm_main.o 
$(KVM)/coalesced_mmio.o \
 kvm-$(CONFIG_KVM_ASYNC_PF) += $(KVM)/async_pf.o
 
 kvm-y  += x86.o mmu.o emulate.o i8259.o irq.o lapic.o \
-  i8254.o ioapic.o irq_comm.o cpuid.o pmu.o
+  i8254.o ioapic.o irq_comm.o cpuid.o pmu.o mtrr.o
 kvm-$(CONFIG_KVM_DEVICE_ASSIGNMENT)+= assigned-dev.o iommu.o
 kvm-intel-y+= vmx.o
 kvm-amd-y  += svm.o
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c88f0e4..532aad2 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2437,109 +2437,6 @@ int kvm_mmu_unprotect_page(struct kvm *kvm, gfn_t gfn)
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_unprotect_page);
 
-/*
- * The function is based on mtrr_type_lookup() in
- * arch/x86/kernel/cpu/mtrr/generic.c
- */
-static int get_mtrr_type(struct mtrr_state_type *mtrr_state,
-u64 start, u64 end)
-{
-   u64 base, mask;
-   u8 prev_match, curr_match;
-   int i, num_var_ranges = KVM_NR_VAR_MTRR;
-
-   /* MTRR is completely disabled, use UC for all of physical memory. */
-   if (!(mtrr_state->enabled & 0x2))
-   return MTRR_TYPE_UNCACHABLE;
-
-   /* Make end inclusive end, instead of exclusive */
-   end--;
-
-   /* Look in fixed ranges. Just return the type as per start */
-   if (mtrr_state->have_fixed && (mtrr_state->enabled & 0x1) &&
- (start < 0x10)) {
-   int idx;
-
-   if (start < 0x8) {
-   idx = 0;
-   idx += (start >> 16);
-   return mtrr_state->fixed_ranges[idx];
-   } else if (start < 0xC) {
-   idx = 1 * 8;
-   idx += ((start - 0x8) >> 14);
-   return mtrr_state->fixed_ranges[idx];
-   } else if (start < 0x100) {
-   idx = 3 * 8;
-   idx += ((start - 0xC) >> 12);
-   return mtrr_state->fixed_ranges[idx];
-   }
-   }
-
-   /*
-* Look in variable ranges
-* Look of multiple ranges matching this address and pick type
-* as per MTRR precedence
-*/
-   prev_match = 0xFF;
-   for (i = 0; i < num_var_ranges; ++i) {
-   unsigned short start_state, end_state;
-
-   if (!(mtrr_state->var_ranges[i].mask_lo & (1 << 11)))
-   continue;
-
-   base = (((u64)mtrr_state->var_ranges[i].base_hi) << 32) +
-  (mtrr_state->var_ranges[i].base_lo & PAGE_MASK);
-   mask = (((u64)mtrr_state->var_ranges[i].mask_hi) << 32) +
-  (mtrr_state->var_ranges[i].mask_lo & PAGE_MASK);
-
-   start_state = ((start & mask) == (base & mask));
-   end_state = ((end & mask) == (base & mask));
-   if (start_state != end_state)
-   return 0xFE;
-
-   if ((start & mask) != (base & mask))
-   continue;
-
-   curr_match = mtrr_state->var_ranges[i].base_lo & 0xff;
-   if (prev_match == 0xFF) {
-   prev_match = curr_match;
-   continue;
-   }
-
-   if (prev_match == MTRR_TYPE_UNCACHABLE ||
-   curr_match == MTRR_TYPE_UNCACHABLE)
-   return MTRR_TYPE_UNCACHABLE;
-
-   if ((prev_match == MTRR_TYPE_WRBACK &&
-curr_match == MTRR_TYPE_WRTH

Re: [PATCH 07/12] x86/virt/guest/xen: Remove use of pgd_list from the Xen guest code

[Ian Campbell]

On Sat, 2015-06-13 at 11:49 +0200, Ingo Molnar wrote:
> xen_mm_pin_all()/unpin_all() are used to implement full guest instance
> suspend/restore. It's a stop-all method that needs to iterate through
> all allocated pgds in the system to fix them up for Xen's use.
> 
> This code uses pgd_list, probably because it was an easy interface.
> 
> But we want to remove the pgd_list, so convert the code over to walk
> all tasks in the system. This is an equivalent method.
> 
> (As I don't use Xen this is was only build tested.)

In which case it seems extra important to copy the appropriate
maintainers, which I've done here.

Ian.

> 
> Cc: Andrew Morton 
> Cc: Andy Lutomirski 
> Cc: Borislav Petkov 
> Cc: Brian Gerst 
> Cc: Denys Vlasenko 
> Cc: H. Peter Anvin 
> Cc: Linus Torvalds 
> Cc: Oleg Nesterov 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: Waiman Long 
> Cc: linux...@kvack.org
> Signed-off-by: Ingo Molnar 
> ---
>  arch/x86/xen/mmu.c | 51 ++-
>  1 file changed, 38 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index dd151b2045b0..70a3df5b0b54 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -853,15 +853,27 @@ static void xen_pgd_pin(struct mm_struct *mm)
>   */
>  void xen_mm_pin_all(void)
>  {
> - struct page *page;
> + struct task_struct *g, *p;
>  
> - spin_lock(&pgd_lock);
> + spin_lock(&pgd_lock); /* Implies rcu_read_lock() for the task list 
> iteration: */
>  
> - list_for_each_entry(page, &pgd_list, lru) {
> - if (!PagePinned(page)) {
> - __xen_pgd_pin(&init_mm, (pgd_t *)page_address(page));
> - SetPageSavePinned(page);
> + for_each_process_thread(g, p) {
> + struct mm_struct *mm;
> + struct page *page;
> + pgd_t *pgd;
> +
> + task_lock(p);
> + mm = p->mm;
> + if (mm) {
> + pgd = mm->pgd;
> + page = virt_to_page(pgd);
> +
> + if (!PagePinned(page)) {
> + __xen_pgd_pin(&init_mm, pgd);
> + SetPageSavePinned(page);
> + }
>   }
> + task_unlock(p);
>   }
>  
>   spin_unlock(&pgd_lock);
> @@ -967,19 +979,32 @@ static void xen_pgd_unpin(struct mm_struct *mm)
>   */
>  void xen_mm_unpin_all(void)
>  {
> - struct page *page;
> + struct task_struct *g, *p;
>  
> - spin_lock(&pgd_lock);
> + spin_lock(&pgd_lock); /* Implies rcu_read_lock() for the task list 
> iteration: */
>  
> - list_for_each_entry(page, &pgd_list, lru) {
> - if (PageSavePinned(page)) {
> - BUG_ON(!PagePinned(page));
> - __xen_pgd_unpin(&init_mm, (pgd_t *)page_address(page));
> - ClearPageSavePinned(page);
> + for_each_process_thread(g, p) {
> + struct mm_struct *mm;
> + struct page *page;
> + pgd_t *pgd;
> +
> + task_lock(p);
> + mm = p->mm;
> + if (mm) {
> + pgd = mm->pgd;
> + page = virt_to_page(pgd);
> +
> + if (PageSavePinned(page)) {
> + BUG_ON(!PagePinned(page));
> + __xen_pgd_unpin(&init_mm, pgd);
> + ClearPageSavePinned(page);
> + }
>   }
> + task_unlock(p);
>   }
>  
>   spin_unlock(&pgd_lock);
> + rcu_read_unlock();
>  }
>  
>  static void xen_activate_mm(struct mm_struct *prev, struct mm_struct *next)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 05/15] KVM: MTRR: exactly define the size of variable MTRRs

[Xiao Guangrong]

Only KVM_NR_VAR_MTRR variable MTRRs are available in KVM guest

Signed-off-by: Xiao Guangrong 
---
 arch/x86/include/asm/kvm_host.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index cbf9f07..fe9cbe4 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -343,7 +343,7 @@ enum {
 };
 
 struct kvm_mtrr {
-   struct mtrr_var_range var_ranges[MTRR_MAX_VAR_RANGES];
+   struct mtrr_var_range var_ranges[KVM_NR_VAR_MTRR];
mtrr_type fixed_ranges[KVM_NR_FIXED_MTRR_REGION];
unsigned char enabled;
mtrr_type def_type;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 04/15] KVM: MTRR: remove mtrr_state.have_fixed

[Xiao Guangrong]

vMTRR does not depend on any host MTRR feature and fixed MTRRs have always
been implemented, so drop this field

Signed-off-by: Xiao Guangrong 
---
 arch/x86/include/asm/kvm_host.h | 9 -
 arch/x86/kvm/mtrr.c | 7 +++
 arch/x86/kvm/x86.c  | 1 -
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index cf8d320..cbf9f07 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -342,6 +342,13 @@ enum {
KVM_DEBUGREG_RELOAD = 4,
 };
 
+struct kvm_mtrr {
+   struct mtrr_var_range var_ranges[MTRR_MAX_VAR_RANGES];
+   mtrr_type fixed_ranges[KVM_NR_FIXED_MTRR_REGION];
+   unsigned char enabled;
+   mtrr_type def_type;
+};
+
 struct kvm_vcpu_arch {
/*
 * rip and regs accesses must go through
@@ -472,7 +479,7 @@ struct kvm_vcpu_arch {
bool nmi_injected;/* Trying to inject an NMI this entry */
bool smi_pending;/* SMI queued after currently running handler */
 
-   struct mtrr_state_type mtrr_state;
+   struct kvm_mtrr mtrr_state;
u64 pat;
 
unsigned switch_db_regs;
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index a05846a..ce061ff 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -103,7 +103,7 @@ EXPORT_SYMBOL_GPL(kvm_mtrr_valid);
 
 static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
 {
-   struct mtrr_state_type *mtrr_state = &vcpu->arch.mtrr_state;
+   struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
unsigned char mtrr_enabled = mtrr_state->enabled;
gfn_t start, end, mask;
int index;
@@ -247,7 +247,7 @@ int kvm_mtrr_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 
*pdata)
  * The function is based on mtrr_type_lookup() in
  * arch/x86/kernel/cpu/mtrr/generic.c
  */
-static int get_mtrr_type(struct mtrr_state_type *mtrr_state,
+static int get_mtrr_type(struct kvm_mtrr *mtrr_state,
 u64 start, u64 end)
 {
u64 base, mask;
@@ -262,8 +262,7 @@ static int get_mtrr_type(struct mtrr_state_type *mtrr_state,
end--;
 
/* Look in fixed ranges. Just return the type as per start */
-   if (mtrr_state->have_fixed && (mtrr_state->enabled & 0x1) &&
- (start < 0x10)) {
+   if ((mtrr_state->enabled & 0x1) && (start < 0x10)) {
int idx;
 
if (start < 0x8) {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fb6c9a1..2ffad7f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7379,7 +7379,6 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
 {
int r;
 
-   vcpu->arch.mtrr_state.have_fixed = 1;
r = vcpu_load(vcpu);
if (r)
return r;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 00/15] vMTRR bugfix and optimization

[Xiao Guangrong]

Changlog:
- let's fix the bugs for noncoherent_dma guests first

- these changes are from Paolo's review
  1) use inline functions instead of union definition for 'struct kvm_mtrr'
  2) improve code style
  3) fix fixed_msr_to_range_index which does not return the actual value
  4) introduce kvm_set_var_mtrr() to make the code more clearer
  5) improve mtrr_for_each_mem_type() APIs and clean it up
  6) drop @unit_size in 'struct fixed_mtrr_segment'

- these changes are from David Matlack's review
  1) improve comment
  2) fix fixed_mtrr_range_end_addr that did not count entries correctly
  

There are some bugs in current code if noncoherent_dma is detected:
- KVM still uses hugepage even if the 4K pages in that ranges span between
  on different memory types and uses the cache type of first page to do memory
  mapping
  
- CR0.CD is not checked so that guest memory is not UC as it expected  

This patchset fixes these bugs and also do optimization and cleanups.

Xiao Guangrong (15):
  KVM: x86: fix CR0.CD virtualization
  KVM: x86: move MTRR related code to a separate file
  KVM: MTRR: handle MSR_MTRRcap in kvm_mtrr_get_msr
  KVM: MTRR: remove mtrr_state.have_fixed
  KVM: MTRR: exactly define the size of variable MTRRs
  KVM: MTRR: clean up mtrr default type
  KVM: MTRR: do not split 64 bits MSR content
  KVM: MTRR: improve kvm_mtrr_get_guest_memory_type
  KVM: MTRR: introduce fixed_mtrr_segment table
  KVM: MTRR: introduce var_mtrr_range
  KVM: MTRR: sort variable MTRRs
  KVM: MTRR: introduce fixed_mtrr_addr_* functions
  KVM: MTRR: introduce mtrr_for_each_mem_type
  KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type
  KVM: MTRR: do not map huage page for non-consistent range

 arch/x86/include/asm/kvm_host.h |  17 +-
 arch/x86/kvm/Makefile   |   2 +-
 arch/x86/kvm/mmu.c  | 123 ++-
 arch/x86/kvm/mtrr.c | 708 
 arch/x86/kvm/vmx.c  |  32 +-
 arch/x86/kvm/x86.c  | 223 +
 arch/x86/kvm/x86.h  |   6 +
 7 files changed, 778 insertions(+), 333 deletions(-)
 create mode 100644 arch/x86/kvm/mtrr.c

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [BUG, bisect] Re: drm/i915: WARN_ON(dev_priv->mm.busy)

[Jani Nikula]

On Mon, 15 Jun 2015, Ville Syrjälä  wrote:
> On Mon, Jun 15, 2015 at 01:25:38AM -0700, Jeremiah Mahler wrote:
>> Daniel,
>> 
>> On Mon, Jun 15, 2015 at 08:57:47AM +0200, Daniel Vetter wrote:
>> > Can you please retest with
>> > 
>> > commit 0aedb1626566efd72b369c01992ee7413c82a0c5
>> > Author: Ville Syrjälä 
>> > Date:   Thu May 28 18:32:36 2015 +0300
>> > 
>> > drm/i915: Don't skip request retirement if the active list is empty
>> > 
>> > Thanks, Daniel
>> > 
>> 
>> The bug is still present with that patch applied.  And it is still
>> present up to linux-next 20150611.
>
> The patch was misapplied, so what's in the tree at the moment isn't what
> I sent to the list.

Auch, my bad.

So we should

1) revert

commit 0aedb1626566efd72b369c01992ee7413c82a0c5
Author: Ville Syrjälä 
Date:   Thu May 28 18:32:36 2015 +0300

drm/i915: Don't skip request retirement if the active list is empty

in v4.1

and

2) reapply http://patchwork.freedesktop.org/patch/50659 to
drm-intel-next-fixes for v4.2.

Is that right?

BR,
Jani.


>
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 0/7] instruction of cyapa gen6 and proximity patches

[Dudley Du]

V1 patches mainly have following updates compared with V0 patches:
1) This patch series is generated base on code base linux-next 20150612,
   so fix the patch v0 6/7 failed to apply on linux-next 20150611 issue.
1) Fix spelling errors, space and black line format errors in patch v1 1/7.
2) Add detail description of the new interrupt and proximity interfaces in
   patch v1 5/7.


This patch series is mainly aimed to add new gen6 trackpad devices support,
and also new function to report proximity data/vent for Gen5 and Gen6 trackpad
devices.


Dudley Du (7):
  input: cyapa: change strings of gen5 to pip in the name when they are
shared
  input: cyapa: add gen6 device module support in driver
  input: cyapa: add proximity function support for gen5 and gen6 modules
  input: cyapa: fully support runtime suspend power management
  input: cyapa: add proximity and interrupt sysfs interfaces support
  input: cyapa: add of match device support and description document
  input: cyapa: add CYAP0002 Gen6 device for ACPI configuration

 .../devicetree/bindings/input/cypress,cyapa.txt|   44 +
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 drivers/input/mouse/Makefile   |2 +-
 drivers/input/mouse/cyapa.c|  266 -
 drivers/input/mouse/cyapa.h|  161 ++-
 drivers/input/mouse/cyapa_gen3.c   |   11 +-
 drivers/input/mouse/cyapa_gen5.c   | 1254 +++-
 drivers/input/mouse/cyapa_gen6.c   |  760 
 8 files changed, 1854 insertions(+), 645 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/cypress,cyapa.txt
 create mode 100644 drivers/input/mouse/cyapa_gen6.c


History patch series modifications list:
V0 patches mainly have following updates:
1) Add Gen6 trackpad device support;
2) Add report proximity data function support for Gen5 and Gen6 devices;
3) Fully support runtime suspend/resume power management;
4) Add of_match_table mechanism support.

-- 
1.9.1


---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 4/7] input: cyapa: fully support runtime suspend power management

[Dudley Du]

Fix the the runtime suspend power management not working issue when system
starts up and before user touches the trackpad device.
TEST=test on Chromebook.

Signed-off-by: Dudley Du 
---
 drivers/input/mouse/cyapa.c  | 79 +++-
 drivers/input/mouse/cyapa.h  |  2 +-
 drivers/input/mouse/cyapa_gen3.c |  4 +-
 drivers/input/mouse/cyapa_gen5.c | 21 +++
 drivers/input/mouse/cyapa_gen6.c |  4 +-
 5 files changed, 72 insertions(+), 38 deletions(-)

diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index d2a24fc..9288948 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -371,7 +371,7 @@ static int cyapa_detect(struct cyapa *cyapa)
 static int cyapa_open(struct input_dev *input)
 {
struct cyapa *cyapa = input_get_drvdata(input);
-   struct i2c_client *client = cyapa->client;
+   struct device *dev = &cyapa->client->dev;
int error;
 
error = mutex_lock_interruptible(&cyapa->state_sync_lock);
@@ -385,10 +385,9 @@ static int cyapa_open(struct input_dev *input)
 * when in operational mode.
 */
error = cyapa->ops->set_power_mode(cyapa,
-   PWR_MODE_FULL_ACTIVE, 0);
+   PWR_MODE_FULL_ACTIVE, 0, false);
if (error) {
-   dev_warn(&client->dev,
-   "set active power failed: %d\n", error);
+   dev_warn(dev, "set active power failed: %d\n", error);
goto out;
}
} else {
@@ -399,11 +398,15 @@ static int cyapa_open(struct input_dev *input)
}
}
 
-   enable_irq(client->irq);
-   if (!pm_runtime_enabled(&client->dev)) {
-   pm_runtime_set_active(&client->dev);
-   pm_runtime_enable(&client->dev);
+   enable_irq(cyapa->client->irq);
+   if (!pm_runtime_enabled(dev)) {
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
}
+
+   pm_runtime_get_sync(dev);
+   pm_runtime_mark_last_busy(dev);
+   pm_runtime_put_sync_autosuspend(dev);
 out:
mutex_unlock(&cyapa->state_sync_lock);
return error;
@@ -412,17 +415,17 @@ out:
 static void cyapa_close(struct input_dev *input)
 {
struct cyapa *cyapa = input_get_drvdata(input);
-   struct i2c_client *client = cyapa->client;
+   struct device *dev = &cyapa->client->dev;
 
mutex_lock(&cyapa->state_sync_lock);
 
-   disable_irq(client->irq);
-   if (pm_runtime_enabled(&client->dev))
-   pm_runtime_disable(&client->dev);
-   pm_runtime_set_suspended(&client->dev);
+   disable_irq(cyapa->client->irq);
+   if (pm_runtime_enabled(dev))
+   pm_runtime_disable(dev);
+   pm_runtime_set_suspended(dev);
 
if (cyapa->operational)
-   cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
+   cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0, false);
 
mutex_unlock(&cyapa->state_sync_lock);
 }
@@ -533,7 +536,7 @@ static void cyapa_enable_irq_for_cmd(struct cyapa *cyapa)
 */
if (!input || cyapa->operational)
cyapa->ops->set_power_mode(cyapa,
-   PWR_MODE_FULL_ACTIVE, 0);
+   PWR_MODE_FULL_ACTIVE, 0, false);
/* Gen3 always using polling mode for command. */
if (cyapa->gen >= CYAPA_GEN5)
enable_irq(cyapa->client->irq);
@@ -548,7 +551,8 @@ static void cyapa_disable_irq_for_cmd(struct cyapa *cyapa)
if (cyapa->gen >= CYAPA_GEN5)
disable_irq(cyapa->client->irq);
if (!input || cyapa->operational)
-   cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
+   cyapa->ops->set_power_mode(cyapa,
+  PWR_MODE_OFF, 0, false);
}
 }
 
@@ -615,7 +619,7 @@ static int cyapa_initialize(struct cyapa *cyapa)
 
/* Power down the device until we need it. */
if (cyapa->operational)
-   cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
+   cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0, false);
 
return 0;
 }
@@ -631,7 +635,8 @@ static int cyapa_reinitialize(struct cyapa *cyapa)
 
/* Avoid command failures when TP was in OFF state. */
if (cyapa->operational)
-   cyapa->ops->set_power_mode(cyapa, PWR_MODE_FULL_ACTIVE, 0);
+   cyapa->ops->set_power_mode(cyapa,
+  PWR_MODE_FULL_ACTIVE, 0, false);
 
error = cyapa_detect(cyapa);
if (error)
@@ -650,7 +655,8 @@ out:
if (!input || !input->users) {
/* Reset to power OFF state to save power when no user open. */

[PATCH v1 3/7] input: cyapa: add proximity function support for gen5 and gen6 modules

[Dudley Du]

Gen5 and Gen6 trackpad devices are able to detect and report object
proximity data/events, add this function support in the cyapa driver
through the MTB protocol ABS_MT_DISTANCE event.
TEST=test on Chromebook.

Signed-off-by: Dudley Du 
---
 drivers/input/mouse/cyapa.c  | 19 -
 drivers/input/mouse/cyapa.h  |  4 +++
 drivers/input/mouse/cyapa_gen3.c |  2 ++
 drivers/input/mouse/cyapa_gen5.c | 61 +++-
 drivers/input/mouse/cyapa_gen6.c | 19 +
 5 files changed, 103 insertions(+), 2 deletions(-)

diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index dbb53eb..d2a24fc 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -39,6 +39,11 @@ const char product_id[] = "CYTRA";
 
 static int cyapa_reinitialize(struct cyapa *cyapa);
 
+int cyapa_set_not_supported(struct cyapa *cyapa, bool enable)
+{
+   return -EOPNOTSUPP;
+}
+
 bool cyapa_is_pip_bl_mode(struct cyapa *cyapa)
 {
if (cyapa->gen == CYAPA_GEN6 && cyapa->state == CYAPA_STATE_GEN6_BL)
@@ -477,6 +482,8 @@ static int cyapa_create_input_dev(struct cyapa *cyapa)
if (cyapa->gen >= CYAPA_GEN5) {
input_set_abs_params(input, ABS_MT_WIDTH_MAJOR, 0, 255, 0, 0);
input_set_abs_params(input, ABS_MT_WIDTH_MINOR, 0, 255, 0, 0);
+
+   input_set_abs_params(input, ABS_MT_DISTANCE, 0, 1, 0, 0);
}
 
input_abs_set_res(input, ABS_MT_POSITION_X,
@@ -1340,6 +1347,13 @@ static int __maybe_unused cyapa_suspend(struct device 
*dev)
error);
}
 
+   /*
+* Disable proximity interrupt when system idle, want true touch to
+* wake the system.
+*/
+   if (cyapa->dev_pwr_mode != PWR_MODE_OFF)
+   cyapa->ops->set_proximity(cyapa, false);
+
if (device_may_wakeup(dev))
cyapa->irq_wake = (enable_irq_wake(client->irq) == 0);
 
@@ -1360,7 +1374,10 @@ static int __maybe_unused cyapa_resume(struct device 
*dev)
cyapa->irq_wake = false;
}
 
-   /* Update device states and runtime PM states. */
+   /*
+* Update device states and runtime PM states.
+* Re-Enable proximity interrupt after enter operational mode.
+*/
error = cyapa_reinitialize(cyapa);
if (error)
dev_warn(dev, "failed to reinitialize TP device: %d\n", error);
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index 3a211c0..203d7a2 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -274,6 +274,8 @@ struct cyapa_dev_ops {
u8 *, int *, cb_sort);
 
int (*set_power_mode)(struct cyapa *, u8, u16);
+
+   int (*set_proximity)(struct cyapa *, bool);
 };
 
 struct cyapa_pip_cmd_states {
@@ -415,9 +417,11 @@ int cyapa_pip_bl_deactivate(struct cyapa *cyapa);
 ssize_t cyapa_pip_do_calibrate(struct device *dev,
   struct device_attribute *attr,
   const char *buf, size_t count);
+int cyapa_pip_set_proximity(struct cyapa *cyapa, bool enable);
 
 bool cyapa_pip_irq_cmd_handler(struct cyapa *cyapa);
 int cyapa_pip_irq_handler(struct cyapa *cyapa);
+int cyapa_set_not_supported(struct cyapa *cyapa, bool enable);
 
 
 extern u8 pip_read_sys_info[];
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index 3884311..6460beb 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -1243,4 +1243,6 @@ const struct cyapa_dev_ops cyapa_gen3_ops = {
.irq_cmd_handler = cyapa_gen3_irq_cmd_handler,
.sort_empty_output_data = cyapa_gen3_empty_output_data,
.set_power_mode = cyapa_gen3_set_power_mode,
+
+   .set_proximity = cyapa_set_not_supported,
 };
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index 4e19dce..519d437 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -52,6 +52,11 @@
 #define PIP_WAKEUP_EVENT_REPORT_ID  0x04
 #define PIP_PUSH_BTN_REPORT_ID  0x06
 #define GEN5_OLD_PUSH_BTN_REPORT_ID 0x05  /* Special for old Gen5 TP. */
+#define PIP_PROXIMITY_REPORT_ID 0x07
+
+#define PIP_PROXIMITY_REPORT_SIZE  6
+#define PIP_PROXIMITY_DISTANCE_OFFSET  0x05
+#define PIP_PROXIMITY_DISTANCE_MASK0x01
 
 #define PIP_TOUCH_REPORT_HEAD_SIZE 7
 #define PIP_TOUCH_REPORT_MAX_SIZE  127
@@ -78,6 +83,8 @@
 #define PIP_SENSING_MODE_MUTUAL_CAP_FINE   0x00
 #define PIP_SENSING_MODE_SELF_CAP  0x02
 
+#define PIP_SET_PROXIMITY  0x49
+
 /* Macro of Gen5 */
 #define GEN5_BL_MAX_OUTPUT_LENGTH 0x0100
 #define GEN5_APP_MAX_OUTPUT_LENGTH0x00fe
@@ -1517,6 +1524,28 @@ static int cyapa_gen5_disable_pip_report(struct cyapa 
*cyapa)
return 0;
 }
 
+int cyapa_pip_set_proximity(struct cyapa *cyapa, bool enable)
+{
+   u8 cmd[] = { 0x04, 0x00, 0x06, 0x00, 0x2f, 0x00,

[PATCH v1 2/7] input: cyapa: add gen6 device module support in driver

[Dudley Du]

Based on the cyapa core, add the gen6 trackpad device's basic functions
supported, so gen6 trackpad device can work with kernel input system.
And also based on the state parse interface, the cyapa driver can
automatically determine the attached is gen3, gen5 or gen6 protocol
trackpad device, then set the correct protocol to work with the attached
trackpad device.
TEST=test on Chromebook.

Signed-off-by: Dudley Du 
---
 drivers/input/mouse/Makefile |   2 +-
 drivers/input/mouse/cyapa.c  |  22 ++
 drivers/input/mouse/cyapa.h  |  15 +
 drivers/input/mouse/cyapa_gen5.c |  69 +++-
 drivers/input/mouse/cyapa_gen6.c | 727 +++
 5 files changed, 831 insertions(+), 4 deletions(-)
 create mode 100644 drivers/input/mouse/cyapa_gen6.c

diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
index 793300b..ee6a6e9 100644
--- a/drivers/input/mouse/Makefile
+++ b/drivers/input/mouse/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_MOUSE_SYNAPTICS_I2C) += synaptics_i2c.o
 obj-$(CONFIG_MOUSE_SYNAPTICS_USB)  += synaptics_usb.o
 obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o
 
-cyapatp-objs := cyapa.o cyapa_gen3.o cyapa_gen5.o
+cyapatp-objs := cyapa.o cyapa_gen3.o cyapa_gen5.o cyapa_gen6.o
 psmouse-objs := psmouse-base.o synaptics.o focaltech.o
 
 psmouse-$(CONFIG_MOUSE_PS2_ALPS)   += alps.o
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 4f0d76e..dbb53eb 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -41,6 +41,9 @@ static int cyapa_reinitialize(struct cyapa *cyapa);
 
 bool cyapa_is_pip_bl_mode(struct cyapa *cyapa)
 {
+   if (cyapa->gen == CYAPA_GEN6 && cyapa->state == CYAPA_STATE_GEN6_BL)
+   return true;
+
if (cyapa->gen == CYAPA_GEN5 && cyapa->state == CYAPA_STATE_GEN5_BL)
return true;
 
@@ -49,6 +52,9 @@ bool cyapa_is_pip_bl_mode(struct cyapa *cyapa)
 
 bool cyapa_is_pip_app_mode(struct cyapa *cyapa)
 {
+   if (cyapa->gen == CYAPA_GEN6 && cyapa->state == CYAPA_STATE_GEN6_APP)
+   return true;
+
if (cyapa->gen == CYAPA_GEN5 && cyapa->state == CYAPA_STATE_GEN5_APP)
return true;
 
@@ -204,6 +210,15 @@ static int cyapa_get_state(struct cyapa *cyapa)
if (!error)
goto out_detected;
}
+   if (cyapa->gen == CYAPA_GEN_UNKNOWN ||
+   cyapa->gen == CYAPA_GEN6 ||
+   cyapa->gen == CYAPA_GEN5) {
+   error = cyapa_pip_state_parse(cyapa,
+   status, BL_STATUS_SIZE);
+   if (!error)
+   goto out_detected;
+   }
+   /* For old Gen5 trackpads detecting. */
if ((cyapa->gen == CYAPA_GEN_UNKNOWN ||
cyapa->gen == CYAPA_GEN5) &&
!smbus && even_addr) {
@@ -300,6 +315,9 @@ static int cyapa_check_is_operational(struct cyapa *cyapa)
return error;
 
switch (cyapa->gen) {
+   case CYAPA_GEN6:
+   cyapa->ops = &cyapa_gen6_ops;
+   break;
case CYAPA_GEN5:
cyapa->ops = &cyapa_gen5_ops;
break;
@@ -579,6 +597,8 @@ static int cyapa_initialize(struct cyapa *cyapa)
error = cyapa_gen3_ops.initialize(cyapa);
if (!error)
error = cyapa_gen5_ops.initialize(cyapa);
+   if (!error)
+   error = cyapa_gen6_ops.initialize(cyapa);
if (error)
return error;
 
@@ -1136,9 +1156,11 @@ static char *cyapa_state_to_string(struct cyapa *cyapa)
case CYAPA_STATE_BL_ACTIVE:
return "bootloader active";
case CYAPA_STATE_GEN5_BL:
+   case CYAPA_STATE_GEN6_BL:
return "bootloader";
case CYAPA_STATE_OP:
case CYAPA_STATE_GEN5_APP:
+   case CYAPA_STATE_GEN6_APP:
return "operational";  /* Normal valid state. */
default:
return "invalid mode";
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index d019d1d..3a211c0 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -19,6 +19,7 @@
 #define CYAPA_GEN_UNKNOWN   0x00   /* unknown protocol. */
 #define CYAPA_GEN3   0x03   /* support MT-protocol B with tracking ID. */
 #define CYAPA_GEN5   0x05   /* support TrueTouch GEN5 trackpad device. */
+#define CYAPA_GEN6   0x06   /* support TrueTouch GEN6 trackpad device. */
 
 #define CYAPA_NAME   "Cypress APA Trackpad (cyapa)"
 
@@ -198,6 +199,9 @@
 #define PIP_BL_APP_INFO_RESP_LENGTH30
 #define PIP_BL_GET_INFO_RESP_LENGTH19
 
+#define PIP_BL_PLATFORM_VER_SHIFT  4
+#define PIP_BL_PLATFORM_VER_MASK   0x0f
+
 #define PIP_PRODUCT_FAMILY_MASK0xf000
 #define PIP_PRODUCT_FAMILY_TRACKPAD0x1000
 
@@ -299,6 +303,14 @

[PATCH v1 5/7] input: cyapa: add proximity and interrupt sysfs interfaces support

[Dudley Du]

Add proximity and interrupt control interfaces in sysfs device node.
The proximity interface is used to disable/enable proximity function in
device. Through this interface, user can apply their own specific strategy
to use the proximity function compared to the default strategy.
For example, some products may need the proximity function, but some may
be not. And for a running system, the requirements for the proximity
function may be also different in the different usage state, so user/app
can fully own its specific strategy and change the proximity function
through this interface.
Currently, the default strategy of the proximity function is that the
proximity function will be always enabled when the trackpad device enters
into the active mode, ignore the previous setting of the proximity
function.
The interrupt interface is used to disable/enable interrupt from the
device. Through this interrupt interface, user can temporary
disable/enable the trackpad device to report data to host system, or
disable the event process that driven by the interrupt event from the
trackpad device, so it can help to avoid the unload/reload process of the
driver which will cause the additional processing to re-initialize the
trackpad device. It would be helpful in firmware debugging.
TEST=test on Chromebook.

Signed-off-by: Dudley Du 
---
 drivers/input/mouse/cyapa.c  | 101 +++
 drivers/input/mouse/cyapa.h  |   4 ++
 drivers/input/mouse/cyapa_gen3.c |   1 +
 drivers/input/mouse/cyapa_gen5.c |   2 +
 drivers/input/mouse/cyapa_gen6.c |  14 ++
 5 files changed, 122 insertions(+)

diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 9288948..4e69594 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -594,6 +594,7 @@ static int cyapa_initialize(struct cyapa *cyapa)
 
cyapa->state = CYAPA_STATE_NO_DEVICE;
cyapa->gen = CYAPA_GEN_UNKNOWN;
+   cyapa->interrupt = true;
mutex_init(&cyapa->state_sync_lock);
 
/*
@@ -1217,12 +1218,110 @@ static ssize_t cyapa_show_mode(struct device *dev,
return size;
 }
 
+static ssize_t cyapa_show_interrupt(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct cyapa *cyapa = dev_get_drvdata(dev);
+   int size;
+   int error;
+
+   error = mutex_lock_interruptible(&cyapa->state_sync_lock);
+   if (error)
+   return error;
+
+   size = scnprintf(buf, PAGE_SIZE, "%d\n", cyapa->interrupt ? 1 : 0);
+
+   mutex_unlock(&cyapa->state_sync_lock);
+   return size;
+}
+
+static ssize_t cyapa_interrupt_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct cyapa *cyapa = dev_get_drvdata(dev);
+   u16 value;
+   int error;
+
+   if (cyapa->gen < CYAPA_GEN6)
+   return -EOPNOTSUPP;
+
+   if (kstrtou16(buf, 10, &value)) {
+   dev_err(dev, "invalid interrupt set parameter\n");
+   return -EINVAL;
+   }
+
+   error = mutex_lock_interruptible(&cyapa->state_sync_lock);
+   if (error)
+   return error;
+
+   if (cyapa->operational)
+   error = cyapa->ops->set_interrupt(cyapa,
+ value ? true : false);
+   else
+   error = -EBUSY;  /* Still running in bootloader mode. */
+
+   mutex_unlock(&cyapa->state_sync_lock);
+   return error < 0 ? error : count;
+}
+
+static ssize_t cyapa_show_proximity(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct cyapa *cyapa = dev_get_drvdata(dev);
+   int size;
+   int error;
+
+   error = mutex_lock_interruptible(&cyapa->state_sync_lock);
+   if (error)
+   return error;
+
+   size = scnprintf(buf, PAGE_SIZE, "%d\n", cyapa->proximity ? 1 : 0);
+
+   mutex_unlock(&cyapa->state_sync_lock);
+   return size;
+}
+
+static ssize_t cyapa_proximity_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct cyapa *cyapa = dev_get_drvdata(dev);
+   u16 value;
+   int error;
+
+   if (cyapa->gen < CYAPA_GEN5)
+   return -EOPNOTSUPP;
+
+   if (kstrtou16(buf, 10, &value)) {
+   dev_err(dev, "invalid set value of proximity\n");
+   return -EINVAL;
+   }
+
+   error = mutex_lock_interruptible(&cyapa->state_sync_lock);
+   if (error)
+   return error;
+
+   if (cyapa->operational)
+   error = cyapa->ops->set_proximity(cyapa,
+ value ? true : false);
+   else
+   error = -EBUSY;  /* Still running in bootloader mod

[PATCH v1 7/7] input: cyapa: add CYAP0002 Gen6 device for ACPI configuration

[Dudley Du]

Add CYTP0002 name for Gen6 device for ACPI configuration
TEST=test on Chromebook.

Signed-off-by: Dudley Du 
---
 drivers/input/mouse/cyapa.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 7b6d6d4..7f674aa 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -1558,6 +1558,7 @@ MODULE_DEVICE_TABLE(i2c, cyapa_id_table);
 static const struct acpi_device_id cyapa_acpi_id[] = {
{ "CYAP", 0 },  /* Gen3 trackpad with 0x67 I2C address. */
{ "CYAP0001", 0 },  /* Gen5 trackpad with 0x24 I2C address. */
+   { "CYAP0002", 0 },  /* Gen6 trackpad with 0x24 I2C address. */
{ }
 };
 MODULE_DEVICE_TABLE(acpi, cyapa_acpi_id);
-- 
1.9.1


---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 6/7] input: cyapa: add of match device support and description document

[Dudley Du]

Add of_match_device mechanism support for Cypress trackpad device, and
add the sample description document of adding the trackpad device node in
device tree.
TEST=test on Chromebook.

Signed-off-by: Dudley Du 
---
 .../devicetree/bindings/input/cypress,cyapa.txt| 44 ++
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 drivers/input/mouse/cyapa.c| 10 +
 3 files changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/cypress,cyapa.txt

diff --git a/Documentation/devicetree/bindings/input/cypress,cyapa.txt 
b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
new file mode 100644
index 000..9be2b44
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
@@ -0,0 +1,44 @@
+Cypress I2C Touchpad
+
+Required properties:
+- compatible: must be "cypress,cyapa".
+- reg: I2C address of the chip.
+- interrupt-parent: a phandle for the interrupt controller (see interrupt
+  binding[0]).
+- interrupts: interrupt to which the chip is connected (see interrupt
+  binding[0]).
+
+Optional properties:
+- wakeup-source: touchpad can be used as a wakeup source.
+- pinctrl-names: should be "default" (see pinctrl binding [1]).
+- pinctrl-0: a phandle pointing to the pin settings for the device (see
+  pinctrl binding [1]).
+- vcc-supply: a phandle for the regulator supplying 3.3V power.
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+Example:
+   &i2c0 {
+   /* ... */
+
+   /* Cypress Gen3 touchpad */
+   touchpad@67 {
+   compatible = "cypress,cyapa";
+   reg = <0x24>;
+   interrupt-parent = <&gpio>;
+   interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
+   wakeup-source;
+   };
+
+   /* Cypress Gen5 and later touchpad */
+   touchpad@24 {
+   compatible = "cypress,cyapa";
+   reg = <0x24>;
+   interrupt-parent = <&gpio>;
+   interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
+   wakeup-source;
+   };
+
+   /* ... */
+   };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ee2ce7b..e43d532 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -54,6 +54,7 @@ cortina   Cortina Systems, Inc.
 cosmic Cosmic Circuits
 crystalfontz   Crystalfontz America, Inc.
 cubietech  Cubietech, Ltd.
+cypressCypress Semiconductor Corporation
 dallas Maxim Integrated Products (formerly Dallas Semiconductor)
 davicomDAVICOM Semiconductor, Inc.
 delta  Delta Electronics, Inc.
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 4e69594..7b6d6d4 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "cyapa.h"
 
 
@@ -1562,12 +1563,21 @@ static const struct acpi_device_id cyapa_acpi_id[] = {
 MODULE_DEVICE_TABLE(acpi, cyapa_acpi_id);
 #endif
 
+#ifdef CONFIG_OF
+static const struct of_device_id cyapa_of_match[] = {
+   { .compatible = "cypress,cyapa" },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, cyapa_of_match);
+#endif
+
 static struct i2c_driver cyapa_driver = {
.driver = {
.name = "cyapa",
.owner = THIS_MODULE,
.pm = &cyapa_pm_ops,
.acpi_match_table = ACPI_PTR(cyapa_acpi_id),
+   .of_match_table = of_match_ptr(cyapa_of_match),
},
 
.probe = cyapa_probe,
-- 
1.9.1


---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 0/4] VFIO platform reset

[Eric Auger]

In situations where the userspace driver is stopped abnormally and the
VFIO platform device is released, the assigned HW device currently is
left running. As a consequence the HW device might continue issuing IRQs
and performing DMA accesses.

On release, no physical IRQ handler is setup anymore. Also the DMA buffers
are unmapped leading to IOMMU aborts. So there is no serious consequence.

However when assigning that HW device again to another userspace driver,
this latter might face some unexpected IRQs and DMA accesses, which are
the result of the previous assignment.

In virtualization use-case, a VM newly granted with that HW device may be
impacted by the assignment of that device to a previous VM:
- IRQs may be injected very early when booting the new guest, even before
  the guest driver has initialized leading to possible driver state
  inconsistency.
- DMA accesses may hit the newly mapped VM address space at addresses that
  may jeopardize the integrity of the newly installed VM.

Obviously the criticity depends on the assigned HW device.

As opposed to PCI, there is no standard mechanism to reset the platform
device.

This series proposes to implement device specific reset functions in
separate in-kernel vfio reset modules. The vfio-platform driver holds
a whitelist of implemented triplets (compat string, module name,
reset function name). When the vfio-platform driver is probed it identifies
the fellow reset module/function matching the compat string of the
device, if any, and forces the load of this reset module.

A first reset module is provided: the vfio-platform-calxedaxgmac
module which implements a basic reset for the Calxeda xgmac.

The series can be found at
https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.1-rc8-reset-v4

History:
v3 -> v4:
- fix the commit message of "VFIO: platform: add reset struct and lookup table"

v2 -> v3:
- remove void module_init/exit functions in calxeda reset module
- remove enum vfio_platform_reset_type
- for reset lookup, use ARRAY_SIZE
- in reset put use symbol_put_addr

v1 -> v2:
- much simplified compared to v1 although principle of external modules is
  kept: removed mechanism of dynamic registration of reset functions
- list is replaced by whitelist lookup table
- name of the reset function also stored in the lookup table
- autoload of reset modules

RFC -> PATCH v1:
- solution now based on a lookup list instead of specialized driver


Eric Auger (4):
  VFIO: platform: add reset struct and lookup table
  VFIO: platform: add reset callback
  VFIO: platform: populate the reset function on probe
  VFIO: platform: Calxeda xgmac reset module

 drivers/vfio/platform/Kconfig  |  2 +
 drivers/vfio/platform/Makefile |  2 +
 drivers/vfio/platform/reset/Kconfig|  7 ++
 drivers/vfio/platform/reset/Makefile   |  5 ++
 .../platform/reset/vfio_platform_calxedaxgmac.c| 86 ++
 drivers/vfio/platform/vfio_platform_common.c   | 60 ++-
 drivers/vfio/platform/vfio_platform_private.h  |  7 ++
 7 files changed, 166 insertions(+), 3 deletions(-)
 create mode 100644 drivers/vfio/platform/reset/Kconfig
 create mode 100644 drivers/vfio/platform/reset/Makefile
 create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 3/4] VFIO: platform: populate the reset function on probe

[Eric Auger]

The reset function lookup happens on vfio-platform probe. The reset
module load is requested  and a reference to the function symbol is
hold. The reference is released on vfio-platform remove.

Signed-off-by: Eric Auger 

---

v2 -> v3:
- vfio_platform_get_reset becomes void
- use ARRAY_SIZE
- use symbol_put_addr

v1 -> v2:
- [get,put]_reset now is called once on probe/remove
- use request_module to automatically load the reset module that
  matches the compatibility string
- lookup table is used instead of list
- remove registration mechanism: reset function name is stored in the
  lookup table.
- use device_property_read_string instead of
  device_property_read_string_array
---
 drivers/vfio/platform/vfio_platform_common.c | 37 +++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 6393581..f3391a9 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -28,6 +28,36 @@ static DEFINE_MUTEX(driver_lock);
 static const struct vfio_platform_reset_combo reset_lookup_table[] = {
 };
 
+static void vfio_platform_get_reset(struct vfio_platform_device *vdev,
+   struct device *dev)
+{
+   const char *compat;
+   int (*reset)(struct vfio_platform_device *);
+   int ret, i;
+
+   ret = device_property_read_string(dev, "compatible", &compat);
+   if (ret)
+   return;
+
+   for (i = 0 ; i < ARRAY_SIZE(reset_lookup_table); i++) {
+   if (!strcmp(reset_lookup_table[i].compat, compat)) {
+   request_module(reset_lookup_table[i].module_name);
+   reset = __symbol_get(
+   reset_lookup_table[i].reset_function_name);
+   if (reset) {
+   vdev->reset = reset;
+   return;
+   }
+   }
+   }
+}
+
+static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
+{
+   if (vdev->reset)
+   symbol_put_addr(vdev->reset);
+}
+
 static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
 {
int cnt = 0, i;
@@ -516,6 +546,8 @@ int vfio_platform_probe_common(struct vfio_platform_device 
*vdev,
return ret;
}
 
+   vfio_platform_get_reset(vdev, dev);
+
mutex_init(&vdev->igate);
 
return 0;
@@ -527,8 +559,11 @@ struct vfio_platform_device 
*vfio_platform_remove_common(struct device *dev)
struct vfio_platform_device *vdev;
 
vdev = vfio_del_group_dev(dev);
-   if (vdev)
+
+   if (vdev) {
+   vfio_platform_put_reset(vdev);
iommu_group_put(dev->iommu_group);
+   }
 
return vdev;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 1/4] VFIO: platform: add reset struct and lookup table

[Eric Auger]

This patch introduces the vfio_platform_reset_combo struct that
stores all the information useful to handle the reset modality:
compat string, name of the reset function, name of the module that
implements the reset function. A lookup table of such structures
is added, currently void.

Signed-off-by: Eric Auger 

---

v3 -> v4:
- update the commit message

v2 -> v3:
- add const in struct vfio_platform_reset_combo
- remove enum vfio_platform_reset_type

v2: creation
---
 drivers/vfio/platform/vfio_platform_common.c  | 3 +++
 drivers/vfio/platform/vfio_platform_private.h | 6 ++
 2 files changed, 9 insertions(+)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index abcff7a..611597e 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -25,6 +25,9 @@
 
 static DEFINE_MUTEX(driver_lock);
 
+static const struct vfio_platform_reset_combo reset_lookup_table[] = {
+};
+
 static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
 {
int cnt = 0, i;
diff --git a/drivers/vfio/platform/vfio_platform_private.h 
b/drivers/vfio/platform/vfio_platform_private.h
index 5d31e04..9e37b9f 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -69,6 +69,12 @@ struct vfio_platform_device {
int (*get_irq)(struct vfio_platform_device *vdev, int i);
 };
 
+struct vfio_platform_reset_combo {
+   const char *compat;
+   const char *reset_function_name;
+   const char *module_name;
+};
+
 extern int vfio_platform_probe_common(struct vfio_platform_device *vdev,
  struct device *dev);
 extern struct vfio_platform_device *vfio_platform_remove_common
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 2/4] VFIO: platform: add reset callback

[Eric Auger]

A new reset callback is introduced. If this callback is populated,
the reset is invoked on device first open/last close or upon userspace
ioctl.  The modality is exposed on VFIO_DEVICE_GET_INFO.

Signed-off-by: Eric Auger 

---

v1 -> v2:
- reset now is also called on first open on top of last close
- remove IS_ERR_OR_NULL
---
 drivers/vfio/platform/vfio_platform_common.c  | 15 +--
 drivers/vfio/platform/vfio_platform_private.h |  1 +
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 611597e..6393581 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -103,6 +103,8 @@ static void vfio_platform_release(void *device_data)
mutex_lock(&driver_lock);
 
if (!(--vdev->refcnt)) {
+   if (vdev->reset)
+   vdev->reset(vdev);
vfio_platform_regions_cleanup(vdev);
vfio_platform_irq_cleanup(vdev);
}
@@ -130,6 +132,9 @@ static int vfio_platform_open(void *device_data)
ret = vfio_platform_irq_init(vdev);
if (ret)
goto err_irq;
+
+   if (vdev->reset)
+   vdev->reset(vdev);
}
 
vdev->refcnt++;
@@ -162,6 +167,8 @@ static long vfio_platform_ioctl(void *device_data,
if (info.argsz < minsz)
return -EINVAL;
 
+   if (vdev->reset)
+   vdev->flags |= VFIO_DEVICE_FLAGS_RESET;
info.flags = vdev->flags;
info.num_regions = vdev->num_regions;
info.num_irqs = vdev->num_irqs;
@@ -255,8 +262,12 @@ static long vfio_platform_ioctl(void *device_data,
 
return ret;
 
-   } else if (cmd == VFIO_DEVICE_RESET)
-   return -EINVAL;
+   } else if (cmd == VFIO_DEVICE_RESET) {
+   if (vdev->reset)
+   return vdev->reset(vdev);
+   else
+   return -EINVAL;
+   }
 
return -ENOTTY;
 }
diff --git a/drivers/vfio/platform/vfio_platform_private.h 
b/drivers/vfio/platform/vfio_platform_private.h
index 9e37b9f..1c9b3d5 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -67,6 +67,7 @@ struct vfio_platform_device {
struct resource*
(*get_resource)(struct vfio_platform_device *vdev, int i);
int (*get_irq)(struct vfio_platform_device *vdev, int i);
+   int (*reset)(struct vfio_platform_device *vdev);
 };
 
 struct vfio_platform_reset_combo {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 4/4] VFIO: platform: Calxeda xgmac reset module

[Eric Auger]

This patch introduces a module that registers and implements a basic
reset function for the Calxeda xgmac device. This latter basically disables
interrupts and stops DMA transfers.

The reset function code is inherited from the native calxeda xgmac driver.

Signed-off-by: Eric Auger 

---

v2 -> v3:
- remove void vfio_platform_calxedaxgmac_init and
  vfio_platform_calxedaxgmac_exit
- no enum vfio_platform_reset_type type anymore

v1 -> v2:
- remove registration mechanism. The module mainly exports the reset
  function. module_init and module_exit now are void.
---
 drivers/vfio/platform/Kconfig  |  2 +
 drivers/vfio/platform/Makefile |  2 +
 drivers/vfio/platform/reset/Kconfig|  7 ++
 drivers/vfio/platform/reset/Makefile   |  5 ++
 .../platform/reset/vfio_platform_calxedaxgmac.c| 86 ++
 drivers/vfio/platform/vfio_platform_common.c   |  5 ++
 6 files changed, 107 insertions(+)
 create mode 100644 drivers/vfio/platform/reset/Kconfig
 create mode 100644 drivers/vfio/platform/reset/Makefile
 create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c

diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig
index 9a4403e..1df7477 100644
--- a/drivers/vfio/platform/Kconfig
+++ b/drivers/vfio/platform/Kconfig
@@ -18,3 +18,5 @@ config VFIO_AMBA
  framework.
 
  If you don't know what to do here, say N.
+
+source "drivers/vfio/platform/reset/Kconfig"
diff --git a/drivers/vfio/platform/Makefile b/drivers/vfio/platform/Makefile
index 81de144..9ce8afe 100644
--- a/drivers/vfio/platform/Makefile
+++ b/drivers/vfio/platform/Makefile
@@ -2,7 +2,9 @@
 vfio-platform-y := vfio_platform.o vfio_platform_common.o vfio_platform_irq.o
 
 obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform.o
+obj-$(CONFIG_VFIO_PLATFORM) += reset/
 
 vfio-amba-y := vfio_amba.o
 
 obj-$(CONFIG_VFIO_AMBA) += vfio-amba.o
+obj-$(CONFIG_VFIO_AMBA) += reset/
diff --git a/drivers/vfio/platform/reset/Kconfig 
b/drivers/vfio/platform/reset/Kconfig
new file mode 100644
index 000..746b96b
--- /dev/null
+++ b/drivers/vfio/platform/reset/Kconfig
@@ -0,0 +1,7 @@
+config VFIO_PLATFORM_CALXEDAXGMAC_RESET
+   tristate "VFIO support for calxeda xgmac reset"
+   depends on VFIO_PLATFORM
+   help
+ Enables the VFIO platform driver to handle reset for Calxeda xgmac
+
+ If you don't know what to do here, say N.
diff --git a/drivers/vfio/platform/reset/Makefile 
b/drivers/vfio/platform/reset/Makefile
new file mode 100644
index 000..2a486af
--- /dev/null
+++ b/drivers/vfio/platform/reset/Makefile
@@ -0,0 +1,5 @@
+vfio-platform-calxedaxgmac-y := vfio_platform_calxedaxgmac.o
+
+ccflags-y += -Idrivers/vfio/platform
+
+obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += vfio-platform-calxedaxgmac.o
diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c 
b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
new file mode 100644
index 000..619dc7d
--- /dev/null
+++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
@@ -0,0 +1,86 @@
+/*
+ * VFIO platform driver specialized for Calxeda xgmac reset
+ * reset code is inherited from calxeda xgmac native driver
+ *
+ * Copyright 2010-2011 Calxeda, Inc.
+ * Copyright (c) 2015 Linaro Ltd.
+ *  www.linaro.org
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "vfio_platform_private.h"
+
+#define DRIVER_VERSION  "0.1"
+#define DRIVER_AUTHOR   "Eric Auger "
+#define DRIVER_DESC "Reset support for Calxeda xgmac vfio platform device"
+
+#define CALXEDAXGMAC_COMPAT "calxeda,hb-xgmac"
+
+/* XGMAC Register definitions */
+#define XGMAC_CONTROL   0x  /* MAC Configuration */
+
+/* DMA Control and Status Registers */
+#define XGMAC_DMA_CONTROL   0x0f18  /* Ctrl (Operational Mode) */
+#define XGMAC_DMA_INTR_ENA  0x0f1c  /* Interrupt Enable */
+
+/* DMA Control registe defines */
+#define DMA_CONTROL_ST  0x2000  /* Start/Stop Transmission */
+#define DMA_CONTROL_SR  0x0002  /* Start/Stop Receive */
+
+/* Common MAC defines */
+#define MAC_ENABLE_TX   0x0008  /* Transmitter Enable */
+#define MAC_ENABLE_RX   0x0004  /* Receiver Enable */
+
+static inline void xgmac_mac_disable(void __iomem *ioaddr)
+{
+   u32 val

Re: [PATCH] gitignore: Add MIPS vmlinux.32 to the list

[Michal Marek]

On Sat, Jun 13, 2015 at 11:37:33AM -0700, Florian Fainelli wrote:
> 2015-04-24 10:27 GMT-07:00 Florian Fainelli :
> > MIPS64 kernels builds will produce a vmlinux.32 kernel image for
> > compatibility, ignore them.
> 
> Ralf, Michal, which one of you should take this patch?

I just applied it to kbuild.git#misc.

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 1/7] input: cyapa: change strings of gen5 to pip in the name when they are shared

[Dudley Du]

Change strings 'gen5' to 'pip' for all macros, variables and functions when
they are shared in gen5 and gen6 modules. The change of these strings is
aimed to keep name definition much more clear and readable.
Also the spelling errors are fix in this patch.
TEST=test on Chromebook.

Signed-off-by: Dudley Du 
---
 drivers/input/mouse/cyapa.c  |   34 +-
 drivers/input/mouse/cyapa.h  |  136 -
 drivers/input/mouse/cyapa_gen3.c |4 +-
 drivers/input/mouse/cyapa_gen5.c | 1103 ++
 4 files changed, 673 insertions(+), 604 deletions(-)

diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index efe1484..4f0d76e 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -6,7 +6,7 @@
  *   Daniel Kurtz 
  *   Benson Leung 
  *
- * Copyright (C) 2011-2014 Cypress Semiconductor, Inc.
+ * Copyright (C) 2011-2015 Cypress Semiconductor, Inc.
  * Copyright (C) 2011-2012 Google, Inc.
  *
  * This file is subject to the terms and conditions of the GNU General Public
@@ -39,11 +39,27 @@ const char product_id[] = "CYTRA";
 
 static int cyapa_reinitialize(struct cyapa *cyapa);
 
-static inline bool cyapa_is_bootloader_mode(struct cyapa *cyapa)
+bool cyapa_is_pip_bl_mode(struct cyapa *cyapa)
 {
if (cyapa->gen == CYAPA_GEN5 && cyapa->state == CYAPA_STATE_GEN5_BL)
return true;
 
+   return false;
+}
+
+bool cyapa_is_pip_app_mode(struct cyapa *cyapa)
+{
+   if (cyapa->gen == CYAPA_GEN5 && cyapa->state == CYAPA_STATE_GEN5_APP)
+   return true;
+
+   return false;
+}
+
+static inline bool cyapa_is_bootloader_mode(struct cyapa *cyapa)
+{
+   if (cyapa_is_pip_bl_mode(cyapa))
+   return true;
+
if (cyapa->gen == CYAPA_GEN3 &&
cyapa->state >= CYAPA_STATE_BL_BUSY &&
cyapa->state <= CYAPA_STATE_BL_ACTIVE)
@@ -54,7 +70,7 @@ static inline bool cyapa_is_bootloader_mode(struct cyapa 
*cyapa)
 
 static inline bool cyapa_is_operational_mode(struct cyapa *cyapa)
 {
-   if (cyapa->gen == CYAPA_GEN5 && cyapa->state == CYAPA_STATE_GEN5_APP)
+   if (cyapa_is_pip_app_mode(cyapa))
return true;
 
if (cyapa->gen == CYAPA_GEN3 && cyapa->state == CYAPA_STATE_OP)
@@ -306,7 +322,7 @@ static int cyapa_check_is_operational(struct cyapa *cyapa)
 
 /*
  * Returns 0 on device detected, negative errno on no device detected.
- * And when the device is detected and opertaional, it will be reset to
+ * And when the device is detected and operational, it will be reset to
  * full power active mode automatically.
  */
 static int cyapa_detect(struct cyapa *cyapa)
@@ -629,15 +645,15 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
if (device_may_wakeup(dev))
pm_wakeup_event(dev, 0);
 
-   /* Interrupt event maybe cuased by host command to trackpad device. */
+   /* Interrupt event maybe caused by host command to trackpad device. */
if (cyapa->ops->irq_cmd_handler(cyapa)) {
/*
 * Interrupt event maybe from trackpad device input reporting.
 */
if (!cyapa->input) {
/*
-* Still in probling or in firware image
-* udpating or reading.
+* Still in probing or in firmware image
+* updating or reading.
 */
cyapa->ops->sort_empty_output_data(cyapa,
NULL, NULL, NULL);
@@ -1051,12 +1067,12 @@ static ssize_t cyapa_update_fw_store(struct device *dev,
dev_dbg(dev, "firmware update successfully done.\n");
 
/*
-* Redetect trackpad device states because firmware update process
+* Re-detect trackpad device states because firmware update process
 * will reset trackpad device into bootloader mode.
 */
ret = cyapa_reinitialize(cyapa);
if (ret) {
-   dev_err(dev, "failed to redetect after updated: %d\n", ret);
+   dev_err(dev, "failed to re-detect after updated: %d\n", ret);
error = error ? error : ret;
}
 
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index adc9ed5..d019d1d 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -3,7 +3,7 @@
  *
  * Author: Dudley Du 
  *
- * Copyright (C) 2014 Cypress Semiconductor, Inc.
+ * Copyright (C) 2014-2015 Cypress Semiconductor, Inc.
  *
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file COPYING in the main directory of this archive for
@@ -25,7 +25,7 @@
 /*
  * Macros for SMBus communication
  */
-#define SMBUS_READ   0x01
+#define SMBUS_READ  0x01
 #define SMBUS_WRITE 0x00
 #define SMBUS_ENCODE_IDX(cmd, idx) ((cmd) | (((idx) & 0x03) << 1))
 #define SMBUS_ENCODE_RW(cmd, rw) ((cmd) | ((rw) & 0x01))
@@

[PATCH] VFIO: platform: enable ARM64 build

[Eric Auger]

This patch enables building VFIO platform and derivatives on ARM64.

Signed-off-by: Eric Auger 
---
 drivers/vfio/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig
index 1df7477..bb30128 100644
--- a/drivers/vfio/platform/Kconfig
+++ b/drivers/vfio/platform/Kconfig
@@ -1,6 +1,6 @@
 config VFIO_PLATFORM
tristate "VFIO support for platform devices"
-   depends on VFIO && EVENTFD && ARM
+   depends on VFIO && EVENTFD && (ARM || ARM64)
select VFIO_VIRQFD
help
  Support for platform devices with VFIO. This is required to make
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] net: fix search limit handling in skb_find_text()

[Roman I Khimov]

Suppose that we're trying to use an xt_string netfilter module to match a
string in a specially crafted packet that has "a nice string" starting at
offset 28.

It could be done in iptables like this:

-A some_chain -m string --string "a nice string" --algo bm --from 28 --to 38 -j 
DROP

And it would work as expected. Now changing that to

-A some_chain -m string --string "a nice string" --algo bm --from 29 --to 38 -j 
DROP

breaks the match, as expected. But, if we try to make

-A some_chain -m string --string "a nice string" --algo bm --from 20 --to 28 -j 
DROP

then it suddenly works again! So the 'to' parameter seems to be inclusive, not
working as an offset after which no search should be done. OK, now if we try:

-A some_chain -m string --string "a nice string" --algo bm --from 28 --to 28 -j 
DROP

it doesn't work. So, for the case of equal 'from' and 'to' it's treated in a
different way.

The first behaviour (matching at 'to' offset) comes from skb_find_text()
comparison. The second one (not matching if 'from' and 'to' are equal) comes
from skb_seq_read() check for (abs_offset >= st->upper_offset).

I think that the way skb_find_text() handles 'to' is wrong and should be fixed
so that we always have predictable behaviour -- only match before 'to' offset.

There are currently only five usages of skb_find_text() in the kernel and it
looks to me that none of them expect to match something at the 'to' offset,
so probably this change is safe.

Reported-by: Edward Makarov 
Tested-by: Edward Makarov 
Signed-off-by: Roman I Khimov 
Cc: Phil Oester 
---
 net/core/skbuff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 3cfff2a..0d32be7 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2901,7 +2901,7 @@ unsigned int skb_find_text(struct sk_buff *skb, unsigned 
int from,
skb_prepare_seq_read(skb, from, to, TS_SKB_CB(&state));
 
ret = textsearch_find(config, &state);
-   return (ret <= to - from ? ret : UINT_MAX);
+   return (ret < to - from ? ret : UINT_MAX);
 }
 EXPORT_SYMBOL(skb_find_text);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 07/18] kthread: Make iterant kthreads freezable by default

[Petr Mladek]

On Sat 2015-06-13 18:22:22, Tejun Heo wrote:
> > I try to better understand why freezer is considered to be a blunt
> > tool. Is it because it is a generic API, try_to_freeze() is put on
> > "random" locations, so that it does not define the safe point
> > precisely enough?
>
> Not that.  I don't know how to explain it better.  Hmmm... okay, let's
> say there's a shared queue Q and N users o fit.  If you wanna make Q
> empty and keep it that way for a while, the right thing to do is
> blocking new queueing and then wait till Q drains - you choke the
> entity that you wanna control.
>
> Instead of that, freezer is trying to block the "N" users part.  In
> majority of cases, it blocks enough but it's pretty difficult to be
> sure whether you actually got all N of them (as some of them may not
> involve kthreads at all or unfreezable kthreads might end up doing
> those operations too on corner cases) and it's also not that clear
> whether blocking the N users actually make Q empty.  Maybe there are
> things which can be in flight asynchronously on Q even all its N users
> are blocked.  This is inherently finicky.

I feel convinced that it does not make sense to make kthreads
freezable by default and that we should not use it when not
necessary.

Thanks a lot for patience and so detailed explanation.

Best Regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kexec: Remove the unnecessary conditional judgement to simplify the code logic

[Dave Young]

On 06/06/15 at 02:14pm, Minfei Huang wrote:
> From: Minfei Huang 
> 
> Transforming PFN(Page Frame Number) to struct page is never failure, so
> we can simplify the code logic to do the image->control_page assignment
> directly in the loop, and remove the unnecessary conditional judgement.
> 
> Signed-off-by: Minfei Huang 
> ---
>  kernel/kexec.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 7a36fdc..4589899 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -796,11 +796,10 @@ static struct page 
> *kimage_alloc_crash_control_pages(struct kimage *image,
>   /* If I don't overlap any segments I have found my hole! */
>   if (i == image->nr_segments) {
>   pages = pfn_to_page(hole_start >> PAGE_SHIFT);
> + image->control_page = hole_end;
>   break;
>   }
>   }
> - if (pages)
> - image->control_page = hole_end;
>  
>   return pages;
>  }

Acked-by: Dave Young 

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i2c: designware: use enable on resume instead initialization

[Mika Westerberg]

On Fri, Jun 12, 2015 at 07:45:00PM -0300, Lucas De Marchi wrote:
> Hi Mika,
> 
> On Wed, Jun 10, 2015 at 4:55 AM, Mika Westerberg
>  wrote:
> > On Mon, Jun 08, 2015 at 02:50:28PM -0300, lucas.de.mar...@gmail.com wrote:
> >> @@ -320,7 +320,7 @@ static int dw_i2c_resume(struct device *dev)
> >>   clk_prepare_enable(i_dev->clk);
> >>
> >>   if (!i_dev->pm_runtime_disabled)
> >> - i2c_dw_init(i_dev);
> >> + i2c_dw_enable(i_dev);
> >
> > This will not work if the device power gets removed (for example being
> > put to D3cold) as it looses context.
> 
> Do you mean we should keep the i2c_dw_init() here?

Yes, that's safer if the controller power gets removed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1 linux-next] ceph: use standard Opt_err

[Ilya Dryomov]

On Sun, Jun 14, 2015 at 12:05 PM, Fabian Frederick  wrote:
>
>
>> On 08 June 2015 at 09:49 Ilya Dryomov  wrote:
>>
>>
>> On Fri, Jun 5, 2015 at 10:12 PM, Fabian Frederick  wrote:
>> > ceph used -1 for the last match_table_t option.
>> > Use Opt_err enum like other FS
>> >
>> > match_token() is based on the pattern (NULL)
>> > so behavior should remain the same.
>> >
>> > Signed-off-by: Fabian Frederick 
>> > ---
>> > This is untested. If this one is ok, I can send the same update
>> > for rbd and net/ceph.
>> >
>> >  fs/ceph/super.c | 5 +++--
>> >  1 file changed, 3 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/fs/ceph/super.c b/fs/ceph/super.c
>> > index 4e99053..35ef692 100644
>> > --- a/fs/ceph/super.c
>> > +++ b/fs/ceph/super.c
>> > @@ -137,7 +137,8 @@ enum {
>> >  #ifdef CONFIG_CEPH_FS_POSIX_ACL
>> > Opt_acl,
>> >  #endif
>> > -   Opt_noacl
>> > +   Opt_noacl,
>> > +   Opt_err
>> >  };
>> >
>> >  static match_table_t fsopt_tokens = {
>> > @@ -169,7 +170,7 @@ static match_table_t fsopt_tokens = {
>> > {Opt_acl, "acl"},
>> >  #endif
>> > {Opt_noacl, "noacl"},
>> > -   {-1, NULL}
>> > +   {Opt_err, NULL}
>> >  };
>> >
>> >  static int parse_fsopt_token(char *c, void *private)
>>
>> This would result in a BUG on any unknown option - match_token->token
>> is what match_token() returns and parse_fsopt_token() clearly expects
>> that to be a negative value.
>>
>> Thanks,
>
> Maybe we could remove the following test ?
>
> token = match_token((char *)c, fsopt_tokens, argstr);
> if (token < 0)
> return -EINVAL;
>
> and return -EINVAL in switch default case ?

Sounds good.

Thanks,

Ilya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH v4 04/14] crypto: add a new driver for Marvell's CESA

[Herbert Xu]

On Fri, Jun 12, 2015 at 09:15:56AM +0200, Boris Brezillon wrote:
>
> +static inline int mv_cesa_sg_count(struct scatterlist *sg, int nbytes)
> +{
> + int nents = 0;
> +
> + while (nbytes > 0) {
> + nents++;
> + nbytes -= sg->length;
> + sg = sg_next(sg);
> + }
> +
> + return nents;
> +}

Please replace this with the newly added sg_nents_for_len.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/21] On-demand device registration

[Alexander Holler]

Am 15.06.2015 um 10:58 schrieb Linus Walleij:

On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler  wrote:


And because you've said that "problem space is a bit convoluted" and I
disagree, here's a summary from my point of view:

1. All the necessary information (dependencies between drivers) already
exists at compile time. The set of dependencies between drivers might become
smaller by configuration, but will not become larger. So there should be NO
need to collect them at runtime, e.g. by instrumenting function calls.


I think you arrived at the core of the crux here.


I've hoped so, that's why I've written it.


I guess your suggested approach then need to introduce a special
build tool to order the initcalls accordingly.

Again this will fall short if you don't know at compile time exactly
*which* board file will be executed.


I've just tried to describe the facts in order to make the problem space 
more clear, because, as said, I don't think it's convoluted.


Besides that, I didn't want to suggest anything else other than what 
I've already posted working patches for. What I've mentioned as possible 
other solutions above is stuff which might be possible too in order to 
give some starting points for people which are searching another 
solution. But I wouldn't have written my patches as they are, if I would 
think there is another more easier solution.


And of course, there is still a bit to resolve at runtime, even in the 
DT case (look at the "compatible" attribute). But there is already a 
runtime solution to find the right driver (in case of DT) and I haven't 
mentioned it in order to no confuse people again. Mentioning every 
little detail doesn't make sense if you want to describe something 
understandable (which is what I've tried).



So the only practical way to solve this at compile time is to predict
an initcall ordering sequence for all possible boot paths, compile in
all of them, and choose the right one at boot. But the number of boot
paths is equal to the number of device trees / ACPI tables or
board files supported, and that space is uncontrolled and ordered
infinite.


You just need one working ordered sequence which includes all options. 
This one will work for all others too.



Basically I think the root problem with your approach is that you
assume we know what hardware we will boot on at compile time. We


Totally wrong. If you assume that I assume this, than either I was 
totally unable to describe something clearly, or you were unable or 
unwilling to understand what I've written. And as the result is the 
same, we don't need to find out which was reason.


Anyway, have fun. I'm quitting the discussion here as I don't have any 
business with the kernel and already decided some time again to not post 
patches anymore as it seems to be a waste of my (and maybe others) time.


Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] seccomp: add ptrace options for suspend/resume

[Pavel Emelyanov]

On 06/13/2015 06:02 PM, Tycho Andersen wrote:
> This patch is the first step in enabling checkpoint/restore of processes
> with seccomp enabled.
> 
> One of the things CRIU does while dumping tasks is inject code into them
> via ptrace to collect information that is only available to the process
> itself. However, if we are in a seccomp mode where these processes are
> prohibited from making these syscalls, then what CRIU does kills the task.
> 
> This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
> a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
> filters to disable (and re-enable) seccomp filters for another task so that
> they can be successfully dumped (and restored). We restrict the set of
> processes that can disable seccomp through ptrace because although today
> ptrace can be used to bypass seccomp, there is some discussion of closing
> this loophole in the future and we would like this patch to not depend on
> that behavior and be future proofed for when it is removed.
> 
> Note that seccomp can be suspended before any filters are actually
> installed; this behavior is useful on criu restore, so that we can suspend
> seccomp, restore the filters, unmap our restore code from the restored
> process' address space, and then resume the task by detaching and have the
> filters resumed as well.
> 
> v2 changes:
> 
> * require that the tracer have no seccomp filters installed
> * drop TIF_NOTSC manipulation from the patch
> * change from ptrace command to a ptrace option and use this ptrace option
>   as the flag to check. This means that as soon as the tracer
>   detaches/dies, seccomp is re-enabled and as a corrollary that one can not
>   disable seccomp across PTRACE_ATTACHs.
> 
> v3 changes:
> 
> * get rid of various #ifdefs everywhere
> * report more sensible errors when PTRACE_O_SUSPEND_SECCOMP is incorrectly
>   used
> 
> v4 changes:
> 
> * get rid of may_suspend_seccomp() in favor of a capable() check in ptrace
>   directly
> 
> v5 changes:
> 
> * check that seccomp is not enabled (or suspended) on the tracer
> 
> Signed-off-by: Tycho Andersen 
> CC: Kees Cook 
> CC: Andy Lutomirski 
> CC: Will Drewry 
> CC: Roland McGrath 
> CC: Oleg Nesterov 
> CC: Pavel Emelyanov 
> CC: Serge E. Hallyn 

Acked-by: Pavel Emelyanov 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86/intel: Add comments about why we disabled HPET on Baytrail

[Feng Tang]

The question has been asked many times, and finally I found the
official document which explains the problem of HPET on Baytrail
that it will halt in deep idle states.

Signed-off-by: Feng Tang 
---
 arch/x86/kernel/early-quirks.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index fe9f0b7..9cdc6acb 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -628,7 +628,10 @@ static struct chipset early_qrk[] __initdata = {
  QFLAG_APPLY_ONCE, intel_graphics_stolen },
/*
 * HPET on current version of Baytrail platform has accuracy
-* problems, disable it for now:
+* problems, that it will halt in deep idle state, so disable it.
+*
+* Please refer section 18.10.1.3 of 
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-1.pdf
 
+* for more details.
 */
{ PCI_VENDOR_ID_INTEL, 0x0f00,
PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet},
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/20] [SCSI] mpt3sas: Add branding string support for OEM's HBA

[Johannes Thumshirn]

On Fri, Jun 12, 2015 at 03:12:22PM +0530, Sreekanth Reddy wrote:
> Added the following Dell branding to the mpt3sas driver.
> 
> "VendorID"   "DeviceID"  "SubsystemVendor ID"  "SubsystemDevice ID"  Dell 
> Branding String
> 0x10000x0097  0x1028 0x1F46DELL 
> 12Gbps HBA
> 
> Signed-off-by: Sreekanth Reddy 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.c | 36 
>  drivers/scsi/mpt3sas/mpt3sas_base.h | 11 +++
>  2 files changed, 47 insertions(+)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index 6739c0a..db362cb 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -2345,6 +2345,41 @@ _base_display_intel_branding(struct MPT3SAS_ADAPTER 
> *ioc)
>  
>  
>  /**
> + * _base_display_dell_branding - Display branding string
> + * @ioc: per adapter object
> + *
> + * Return nothing.
> + */
> +static void
> +_base_display_dell_branding(struct MPT3SAS_ADAPTER *ioc)
> +{
> + if (ioc->pdev->subsystem_vendor != PCI_VENDOR_ID_DELL)
> + return;
> +
> + switch (ioc->pdev->device) {
> + case MPI25_MFGPAGE_DEVID_SAS3008:
> + switch (ioc->pdev->subsystem_device) {
> + case MPT3SAS_DELL_12G_HBA_SSDID:
> + pr_info(MPT3SAS_FMT "%s\n", ioc->name,
> + MPT3SAS_DELL_12G_HBA_BRANDING);
> + break;
> + default:
> + pr_info(MPT3SAS_FMT
> +"Dell 12Gbps HBA: Subsystem ID: 0x%X\n", ioc->name,
> +ioc->pdev->subsystem_device);
> + break;
> + }
> + break;
> + default:
> + pr_info(MPT3SAS_FMT
> + "Dell 12Gbps HBA: Subsystem ID: 0x%X\n", ioc->name,
> + ioc->pdev->subsystem_device);
> + break;
> + }
> +}
> +
> +
> +/**
>   * _base_display_ioc_capabilities - Disply IOC's capabilities.
>   * @ioc: per adapter object
>   *
> @@ -2374,6 +2409,7 @@ _base_display_ioc_capabilities(struct MPT3SAS_ADAPTER 
> *ioc)
>   bios_version & 0x00FF);
>  
>   _base_display_intel_branding(ioc);
> + _base_display_dell_branding(ioc);
>  
>   pr_info(MPT3SAS_FMT "Protocol=(", ioc->name);
>  
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index 2318ef8..c4780c7 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -152,6 +152,17 @@
>  #define MPT3SAS_INTEL_RS3UC080_SSDID0x3524
>  
>  /*
> + * Dell HBA branding
> + */
> +#define MPT3SAS_DELL_12G_HBA_BRANDING   \
> + "Dell 12Gbps HBA"
> +
> +/*
> + * Dell HBA SSDIDs
> + */
> +#define MPT3SAS_DELL_12G_HBA_SSDID   0x1F46
> +
> +/*
>   * status bits for ioc->diag_buffer_status
>   */
>  #define MPT3_DIAG_BUFFER_IS_REGISTERED   (0x01)
> -- 
> 2.0.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

This might be something you might consider re-organizing for your code-base
merge as well, as it leads to a lot of code duplication the more OEMs you have.

-- 
Johannes Thumshirn   Storage
jthumsh...@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: EXYNOS: Remove duplicated define of SLEEP_MAGIC

[Krzysztof Kozlowski]

The magic cookie for entering sleep state was defined and used in two
different places: firmware.c and suspend.c. Move it to one common place
to reduce duplication.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/common.h   | 6 ++
 arch/arm/mach-exynos/firmware.c | 2 --
 arch/arm/mach-exynos/suspend.c  | 4 +---
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index e3a9256ed55f..153492513c40 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -128,6 +128,12 @@ void exynos_firmware_init(void);
 
 /* CPU BOOT mode flag for Exynos3250 SoC bootloader */
 #define C2_STATE   (1 << 3)
+/*
+ * Magic values for bootloader indicating chosen low power mode.
+ * See also Documentation/arm/Samsung/Bootloader-interface.txt
+ */
+#define EXYNOS_SLEEP_MAGIC 0x0bad
+#define EXYNOS_AFTR_MAGIC  0xfcba0d10
 
 void exynos_set_boot_flag(unsigned int cpu, unsigned int mode);
 void exynos_clear_boot_flag(unsigned int cpu, unsigned int mode);
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 245f6dec1ded..111cfbf66fdb 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -25,8 +25,6 @@
 #include "common.h"
 #include "smc.h"
 
-#define EXYNOS_SLEEP_MAGIC 0x0bad
-#define EXYNOS_AFTR_MAGIC  0xfcba0d10
 #define EXYNOS_BOOT_ADDR   0x8
 #define EXYNOS_BOOT_FLAG   0xc
 
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index f572219c7a40..c506f8e9c3e5 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -38,8 +38,6 @@
 #include "regs-pmu.h"
 #include "exynos-pmu.h"
 
-#define S5P_CHECK_SLEEP 0x0BAD
-
 #define REG_TABLE_END (-1U)
 
 #define EXYNOS5420_CPU_STATE   0x28
@@ -331,7 +329,7 @@ static void exynos_pm_enter_sleep_mode(void)
 {
/* Set value of power down register for sleep mode */
exynos_sys_powerdown_conf(SYS_SLEEP);
-   pmu_raw_writel(S5P_CHECK_SLEEP, S5P_INFORM1);
+   pmu_raw_writel(EXYNOS_SLEEP_MAGIC, S5P_INFORM1);
 }
 
 static void exynos_pm_prepare(void)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH v4 04/14] crypto: add a new driver for Marvell's CESA

[Herbert Xu]

On Fri, Jun 12, 2015 at 09:15:56AM +0200, Boris Brezillon wrote:
>
> +static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine)
> +{
> + struct crypto_async_request *req;
> + struct mv_cesa_ctx *ctx;
> +
> + spin_lock_bh(&cesa_dev->lock);
> + req = crypto_dequeue_request(&cesa_dev->queue);

Need to call crypto_get_backlog before this so you can do the
backlog notification afterwards.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG ?] regmap: debugfs: WARN_ON at regmap-debugfs.c:151

[Mark Brown]

On Sat, Jun 13, 2015 at 03:21:02PM +0200, Sergej Sawazki wrote:

> when I try to read the register values of a i2c ASoC codec through
> debugfs, (eg: cat /sys/kernel/debug/regmap/1-001a/registers)
> I am getting an WARN_ON at drivers/base/regmap/regmap-debugfs.c:151.

Please provide some plain text description of which line of code you're
referring to when reporting things - line numbers do change as things
move on (though I see this one).

> I did some debugging and found that regmap_readable(), at regmap-
> debugfs.c:109, returns "false" for all registers, hence the
> debugfs_off_cache list remains empty and we get an warning in line 151.

We need to change that code to special case write only register maps
like this and just skip having a cache for those devices.  They normally
have very small register maps anyway so it shouldn't have too big an
impact on performance.


signature.asc
Description: Digital signature

Re: [PATCH] ASoC: Intel: mrfld: simplify sst_fill_widget_module_info

[Mark Brown]

On Thu, Jun 04, 2015 at 10:13:53AM +0200, Rasmus Villemoes wrote:
> Some tiny improvements, cutting 180 bytes off the generated code.

Applied, thanks


signature.asc
Description: Digital signature

Re: [PATCH 07/20] [SCSI] mpt3sas: Bump mpt3sas Driver version to v5.100.00.00

[Johannes Thumshirn]

On Fri, Jun 12, 2015 at 03:12:19PM +0530, Sreekanth Reddy wrote:
> Bump mpt3sas Driver version to v5.100.00.00
> 
> Signed-off-by: Sreekanth Reddy 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index 293ad23..9396a76 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -71,8 +71,8 @@
>  #define MPT3SAS_DRIVER_NAME  "mpt3sas"
>  #define MPT3SAS_AUTHOR "Avago Technologies 
> "
>  #define MPT3SAS_DESCRIPTION  "LSI MPT Fusion SAS 3.0 Device Driver"
> -#define MPT3SAS_DRIVER_VERSION   "04.100.00.00"
> -#define MPT3SAS_MAJOR_VERSION4
> +#define MPT3SAS_DRIVER_VERSION   "05.100.00.00"
> +#define MPT3SAS_MAJOR_VERSION5
>  #define MPT3SAS_MINOR_VERSION100
>  #define MPT3SAS_BUILD_VERSION0
>  #define MPT3SAS_RELEASE_VERSION  00
> -- 
> 2.0.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn   Storage
jthumsh...@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/20] [SCSI] mpt3sas: MPI 2.5 Rev I (2.5.4) specifications.

[Johannes Thumshirn]

On Fri, Jun 12, 2015 at 03:12:17PM +0530, Sreekanth Reddy wrote:
> Update MPI 2.5 Release: MPI 2.5 Rev I (2.5.4) specification and 2.00.33 
> header files
> 
> Below is the change set from the MPI specification for I Rev
> 
> 1) Added Base Enclosure Level bit to the Flags field of Manufacturing Page 7.
> 2) Updated description of the MaxTargetPortConnectTime field of SAS IO Unit 
> Page 1.
> 3) Added EnclosureLevel and ConnectorName fields to SAS Device Page 0. Also, 
> added EnclosureLevel and ConnectorName Valid bit to the Flags field.
> 4) Added EnclosureLevel field to SAS Enclosure Page 0. Also, added 
> EnclosureLevel Valid bit to the Flags field.
> 5) Added value for BIOS image to HashImageType.
> 
> Signed-off-by: Sreekanth Reddy 
> ---
>  drivers/scsi/mpt3sas/mpi/mpi2.h  |  6 --
>  drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 27 +--
>  drivers/scsi/mpt3sas/mpi/mpi2_ioc.h  |  4 +++-
>  3 files changed, 28 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
> index c34c115..d730c5c 100644
> --- a/drivers/scsi/mpt3sas/mpi/mpi2.h
> +++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
> @@ -8,7 +8,7 @@
>   * scatter/gather formats.
>   * Creation Date:  June 21, 2006
>   *
> - * mpi2.h Version:  02.00.31
> + * mpi2.h Version:  02.00.33
>   *
>   * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
>   *   prefix are for use only on MPI v2.5 products, and must not be used
> @@ -88,6 +88,8 @@
>   * Added MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET.
>   * 04-09-13  02.00.30  Bumped MPI2_HEADER_VERSION_UNIT.
>   * 04-17-13  02.00.31  Bumped MPI2_HEADER_VERSION_UNIT.
> + * 08-19-13  02.00.32  Bumped MPI2_HEADER_VERSION_UNIT.
> + * 12-05-13  02.00.33  Bumped MPI2_HEADER_VERSION_UNIT.
>   * --
>   */
>  
> @@ -121,7 +123,7 @@
>  #define MPI2_VERSION_02_05  (0x0205)
>  
>  /*Unit and Dev versioning for this MPI header set */
> -#define MPI2_HEADER_VERSION_UNIT(0x1F)
> +#define MPI2_HEADER_VERSION_UNIT(0x21)
>  #define MPI2_HEADER_VERSION_DEV (0x00)
>  #define MPI2_HEADER_VERSION_UNIT_MASK   (0xFF00)
>  #define MPI2_HEADER_VERSION_UNIT_SHIFT  (8)
> diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h 
> b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> index e261a31..62dfbf6 100644
> --- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> +++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> @@ -6,7 +6,7 @@
>   * Title:  MPI Configuration messages and pages
>   * Creation Date:  November 10, 2006
>   *
> - *   mpi2_cnfg.h Version:  02.00.26
> + *   mpi2_cnfg.h Version:  02.00.27
>   *
>   * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
>   *   prefix are for use only on MPI v2.5 products, and must not be used
> @@ -165,6 +165,16 @@
>   * match the specification.
>   * 08-19-13  02.00.26  Added reserved words to MPI2_CONFIG_PAGE_IO_UNIT_7 for
>   *   future use.
> + * 12-05-13  02.00.27  Added MPI2_MANPAGE7_FLAG_BASE_ENCLOSURE_LEVEL for
> + *  MPI2_CONFIG_PAGE_MAN_7.
> + *  Added EnclosureLevel and ConnectorName fields to
> + *  MPI2_CONFIG_PAGE_SAS_DEV_0.
> + *  Added MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID for
> + *  MPI2_CONFIG_PAGE_SAS_DEV_0.
> + *  Added EnclosureLevel field to
> + *  MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
> + *  Added MPI2_SAS_ENCLS0_FLAGS_ENCL_LEVEL_VALID for
> + *  MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
>   * --
>   */
>  
> @@ -724,6 +734,7 @@ typedef struct _MPI2_CONFIG_PAGE_MAN_7 {
>  #define MPI2_MANUFACTURING7_PAGEVERSION (0x01)
>  
>  /*defines for the Flags field */
> +#define MPI2_MANPAGE7_FLAG_BASE_ENCLOSURE_LEVEL (0x0008)
>  #define MPI2_MANPAGE7_FLAG_EVENTREPLAY_SLOT_ORDER   (0x0002)
>  #define MPI2_MANPAGE7_FLAG_USE_SLOT_INFO(0x0001)
>  
> @@ -2633,9 +2644,9 @@ typedef struct _MPI2_CONFIG_PAGE_SAS_DEV_0 {
>   U8
>   ControlGroup;   /*0x2E */
>   U8
> - Reserved1;  /*0x2F */
> + EnclosureLevel; /*0x2F */
>   U32
> - Reserved2;  /*0x30 */
> + ConnectorName[4];   /*0x30 */
>   U32
>   Reserved3;  /*0x34 */
>  } MPI2_CONFIG_PAGE_SAS_DEV_0,
> @@ -2643,7 +2654,7 @@ typedef struct _MPI2_CONFIG_PAGE_SAS_DEV_0 {
>   Mpi2SasDevicePage0_t,
>   *pMpi2SasDevicePage0_t;
>  
> -#define MPI2_SASDEVICE0_PAGEVERSION (0x08)
> +#define MPI2_SASDEVICE0_PAGEVERSION (0x09)
>  
>  /*values for SAS Device Page 0 AccessStatus field */
>  #define MPI2_SAS_DEVICE0_ASTATUS_NO_ERRORS  

Re: [PATCH 09/20] [SCSI] mpt3sas: MPI 2.5 Rev J (2.5.5) specification and 2.00.34 header files

[Johannes Thumshirn]

On Fri, Jun 12, 2015 at 03:12:21PM +0530, Sreekanth Reddy wrote:
> Following is the change set,
> 
> 1. Added more defines for the BiosOptions field of MPI2_CONFIG_PAGE_BIOS_1.
> 2. Added MPI2_TOOLBOX_CLEAN_BIT26_PRODUCT_SPECIFIC definition.
> 
> Signed-off-by: Sreekanth Reddy 
> ---
>  drivers/scsi/mpt3sas/mpi/mpi2.h  |  5 +++--
>  drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 14 --
>  drivers/scsi/mpt3sas/mpi/mpi2_tool.h |  4 +++-
>  3 files changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
> index d730c5c..c2d127c 100644
> --- a/drivers/scsi/mpt3sas/mpi/mpi2.h
> +++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
> @@ -8,7 +8,7 @@
>   * scatter/gather formats.
>   * Creation Date:  June 21, 2006
>   *
> - * mpi2.h Version:  02.00.33
> + * mpi2.h Version:  02.00.34
>   *
>   * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
>   *   prefix are for use only on MPI v2.5 products, and must not be used
> @@ -90,6 +90,7 @@
>   * 04-17-13  02.00.31  Bumped MPI2_HEADER_VERSION_UNIT.
>   * 08-19-13  02.00.32  Bumped MPI2_HEADER_VERSION_UNIT.
>   * 12-05-13  02.00.33  Bumped MPI2_HEADER_VERSION_UNIT.
> + * 01-08-14  02.00.34  Bumped MPI2_HEADER_VERSION_UNIT
>   * --
>   */
>  
> @@ -123,7 +124,7 @@
>  #define MPI2_VERSION_02_05  (0x0205)
>  
>  /*Unit and Dev versioning for this MPI header set */
> -#define MPI2_HEADER_VERSION_UNIT(0x21)
> +#define MPI2_HEADER_VERSION_UNIT(0x22)
>  #define MPI2_HEADER_VERSION_DEV (0x00)
>  #define MPI2_HEADER_VERSION_UNIT_MASK   (0xFF00)
>  #define MPI2_HEADER_VERSION_UNIT_SHIFT  (8)
> diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h 
> b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> index 62dfbf6..66f2cc1 100644
> --- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> +++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> @@ -6,7 +6,7 @@
>   * Title:  MPI Configuration messages and pages
>   * Creation Date:  November 10, 2006
>   *
> - *   mpi2_cnfg.h Version:  02.00.27
> + *   mpi2_cnfg.h Version:  02.00.28
>   *
>   * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
>   *   prefix are for use only on MPI v2.5 products, and must not be used
> @@ -175,6 +175,8 @@
>   *  MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
>   *  Added MPI2_SAS_ENCLS0_FLAGS_ENCL_LEVEL_VALID for
>   *  MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
> + * 01-08-14  02.00.28  Added more defines for the BiosOptions field of
> + *  MPI2_CONFIG_PAGE_BIOS_1.
>   * --
>   */
>  
> @@ -1334,9 +1336,17 @@ typedef struct _MPI2_CONFIG_PAGE_BIOS_1 {
>   *PTR_MPI2_CONFIG_PAGE_BIOS_1,
>   Mpi2BiosPage1_t, *pMpi2BiosPage1_t;
>  
> -#define MPI2_BIOSPAGE1_PAGEVERSION  (0x05)
> +#define MPI2_BIOSPAGE1_PAGEVERSION  (0x06)
>  
>  /*values for BIOS Page 1 BiosOptions field */
> +#define MPI2_BIOSPAGE1_OPTIONS_X86_DISABLE_BIOS  (0x0400)
> +
> +#define MPI2_BIOSPAGE1_OPTIONS_MASK_REGISTRATION_UEFI_BSD(0x0300)
> +#define MPI2_BIOSPAGE1_OPTIONS_USE_BIT0_REGISTRATION_UEFI_BSD
> (0x)
> +#define MPI2_BIOSPAGE1_OPTIONS_FULL_REGISTRATION_UEFI_BSD(0x0100)
> +#define MPI2_BIOSPAGE1_OPTIONS_ADAPTER_REGISTRATION_UEFI_BSD (0x0200)
> +#define MPI2_BIOSPAGE1_OPTIONS_DISABLE_REGISTRATION_UEFI_BSD (0x0300)
> +
>  #define MPI2_BIOSPAGE1_OPTIONS_MASK_OEM_ID  (0x00F0)
>  #define MPI2_BIOSPAGE1_OPTIONS_LSI_OEM_ID   (0x)
>  
> diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_tool.h 
> b/drivers/scsi/mpt3sas/mpi/mpi2_tool.h
> index 904910d..1629e5b 100644
> --- a/drivers/scsi/mpt3sas/mpi/mpi2_tool.h
> +++ b/drivers/scsi/mpt3sas/mpi/mpi2_tool.h
> @@ -6,7 +6,7 @@
>   * Title:  MPI diagnostic tool structures and definitions
>   * Creation Date:  March 26, 2007
>   *
> - *   mpi2_tool.h Version:  02.00.11
> + *   mpi2_tool.h Version:  02.00.12
>   *
>   * Version History
>   * ---
> @@ -33,6 +33,7 @@
>   * 07-26-12  02.00.10  Modified MPI2_TOOLBOX_DIAGNOSTIC_CLI_REQUEST so that
>   * it uses MPI Chain SGE as well as MPI Simple SGE.
>   * 08-19-13  02.00.11  Added MPI2_TOOLBOX_TEXT_DISPLAY_TOOL and related info.
> + * 01-08-14  02.00.12  Added MPI2_TOOLBOX_CLEAN_BIT26_PRODUCT_SPECIFIC.
>   * --
>   */
>  
> @@ -100,6 +101,7 @@ typedef struct _MPI2_TOOLBOX_CLEAN_REQUEST {
>  #define MPI2_TOOLBOX_CLEAN_OTHER_PERSIST_PAGES  (0x2000)
>  #define MPI2_TOOLBOX_CLEAN_FW_CURRENT   (0x1000)
>  #define MPI2_TOOLBOX_CLEAN_FW_BACKUP(0x0800)
> +#define MPI2_TOOLBOX_CLEAN_BIT26_PRODUCT_SPECIFIC   (0x0400)
>  

Re: [PATCH 08/20] [SCSI] mpt3sas: Update MPI2 strings to MPI2.5

[Johannes Thumshirn]

On Fri, Jun 12, 2015 at 03:12:20PM +0530, Sreekanth Reddy wrote:
> Update MPI2 strings to MPI2.5.
> 
> Signed-off-by: Sreekanth Reddy 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.c | 3 +--
>  drivers/scsi/mpt3sas/mpt3sas_base.h | 1 -
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index 32b86bf..6739c0a 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -3901,7 +3901,7 @@ _base_send_ioc_init(struct MPT3SAS_ADAPTER *ioc, int 
> sleep_flag)
>   mpi_request.WhoInit = MPI2_WHOINIT_HOST_DRIVER;
>   mpi_request.VF_ID = 0; /* TODO */
>   mpi_request.VP_ID = 0;
> - mpi_request.MsgVersion = cpu_to_le16(MPI2_VERSION);
> + mpi_request.MsgVersion = cpu_to_le16(MPI25_VERSION);
>   mpi_request.HeaderVersion = cpu_to_le16(MPI2_HEADER_VERSION);
>  
>   if (_base_is_controller_msix_enabled(ioc))
> @@ -4769,7 +4769,6 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
>   ioc->build_sg_scmd = &_base_build_sg_scmd_ieee;
>   ioc->build_sg = &_base_build_sg_ieee;
>   ioc->build_zero_len_sge = &_base_build_zero_len_sge_ieee;
> - ioc->mpi25 = 1;
>   ioc->sge_size_ieee = sizeof(Mpi2IeeeSgeSimple64_t);
>  
>   /*
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index 9396a76..2318ef8 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -819,7 +819,6 @@ struct MPT3SAS_ADAPTER {
>   MPT_BUILD_SG_SCMD build_sg_scmd;
>   MPT_BUILD_SGbuild_sg;
>   MPT_BUILD_ZERO_LEN_SGE build_zero_len_sge;
> - u8  mpi25;
>   u16 sge_size_ieee;
>  
>   /* function ptr for MPI sg elements only */
> -- 
> 2.0.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn   Storage
jthumsh...@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 12/20] [SCSI] mpt3sas: Bump mpt3sas driver version to v6.100.00.00

[Johannes Thumshirn]

On Fri, Jun 12, 2015 at 03:12:24PM +0530, Sreekanth Reddy wrote:
> Bump mpt3sas driver version to v6.100.00.00.
> 
> Signed-off-by: Sreekanth Reddy 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index 7cdbc65..a89c752 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -71,8 +71,8 @@
>  #define MPT3SAS_DRIVER_NAME  "mpt3sas"
>  #define MPT3SAS_AUTHOR "Avago Technologies 
> "
>  #define MPT3SAS_DESCRIPTION  "LSI MPT Fusion SAS 3.0 Device Driver"
> -#define MPT3SAS_DRIVER_VERSION   "05.100.00.00"
> -#define MPT3SAS_MAJOR_VERSION5
> +#define MPT3SAS_DRIVER_VERSION   "06.100.00.00"
> +#define MPT3SAS_MAJOR_VERSION6
>  #define MPT3SAS_MINOR_VERSION100
>  #define MPT3SAS_BUILD_VERSION0
>  #define MPT3SAS_RELEASE_VERSION  00
> -- 
> 2.0.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn   Storage
jthumsh...@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 13/20] [SCSI] mpt3sas: MPI 2.5 Rev K (2.5.6) specifications

[Johannes Thumshirn]

On Fri, Jun 12, 2015 at 03:12:25PM +0530, Sreekanth Reddy wrote:
> Below are the new changes to MPI 2.5 Rev K(2.5.6) specification and 2.00.35 
> header files
> 1) Added a minimum size requirement for target mode command buffers.
> 2) Added MinMSIxIndex and MaxMSIxIndex fields to CommandBufferPostBase 
> Request.
> 3) For BIOS Page 1, added SSUTimeout field, and added Product Name String 
> Format bits to the BiosOptions field
> 
> Signed-off-by: Sreekanth Reddy 
> ---
>  drivers/scsi/mpt3sas/mpi/mpi2.h  |  5 +++--
>  drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 17 ++---
>  2 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
> index c2d127c..ec27ad2 100644
> --- a/drivers/scsi/mpt3sas/mpi/mpi2.h
> +++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
> @@ -8,7 +8,7 @@
>   * scatter/gather formats.
>   * Creation Date:  June 21, 2006
>   *
> - * mpi2.h Version:  02.00.34
> + * mpi2.h Version:  02.00.35
>   *
>   * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
>   *   prefix are for use only on MPI v2.5 products, and must not be used
> @@ -91,6 +91,7 @@
>   * 08-19-13  02.00.32  Bumped MPI2_HEADER_VERSION_UNIT.
>   * 12-05-13  02.00.33  Bumped MPI2_HEADER_VERSION_UNIT.
>   * 01-08-14  02.00.34  Bumped MPI2_HEADER_VERSION_UNIT
> + * 06-13-14  02.00.35  Bumped MPI2_HEADER_VERSION_UNIT.
>   * --
>   */
>  
> @@ -124,7 +125,7 @@
>  #define MPI2_VERSION_02_05  (0x0205)
>  
>  /*Unit and Dev versioning for this MPI header set */
> -#define MPI2_HEADER_VERSION_UNIT(0x22)
> +#define MPI2_HEADER_VERSION_UNIT(0x23)
>  #define MPI2_HEADER_VERSION_DEV (0x00)
>  #define MPI2_HEADER_VERSION_UNIT_MASK   (0xFF00)
>  #define MPI2_HEADER_VERSION_UNIT_SHIFT  (8)
> diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h 
> b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> index 66f2cc1..c337a85 100644
> --- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> +++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
> @@ -6,7 +6,7 @@
>   * Title:  MPI Configuration messages and pages
>   * Creation Date:  November 10, 2006
>   *
> - *   mpi2_cnfg.h Version:  02.00.28
> + *   mpi2_cnfg.h Version:  02.00.29
>   *
>   * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
>   *   prefix are for use only on MPI v2.5 products, and must not be used
> @@ -177,6 +177,8 @@
>   *  MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
>   * 01-08-14  02.00.28  Added more defines for the BiosOptions field of
>   *  MPI2_CONFIG_PAGE_BIOS_1.
> + * 06-13-14  02.00.29  Added SSUTimeout field to MPI2_CONFIG_PAGE_BIOS_1, and
> + *  more defines for the BiosOptions field..
>   * --
>   */
>  
> @@ -1324,7 +1326,9 @@ typedef struct _MPI2_CONFIG_PAGE_BIOS_1 {
>   MPI2_CONFIG_PAGE_HEADER Header; /*0x00 */
>   U32 BiosOptions;/*0x04 */
>   U32 IOCSettings;/*0x08 */
> - U32 Reserved1;  /*0x0C */
> + U8  SSUTimeout; /*0x0C */
> + U8  Reserved1;  /*0x0D */
> + U16 Reserved2;  /*0x0E */
>   U32 DeviceSettings; /*0x10 */
>   U16 NumberOfDevices;/*0x14 */
>   U16 UEFIVersion;/*0x16 */
> @@ -1336,9 +1340,16 @@ typedef struct _MPI2_CONFIG_PAGE_BIOS_1 {
>   *PTR_MPI2_CONFIG_PAGE_BIOS_1,
>   Mpi2BiosPage1_t, *pMpi2BiosPage1_t;
>  
> -#define MPI2_BIOSPAGE1_PAGEVERSION  (0x06)
> +#define MPI2_BIOSPAGE1_PAGEVERSION  (0x07)
>  
>  /*values for BIOS Page 1 BiosOptions field */
> +#define MPI2_BIOSPAGE1_OPTIONS_PNS_MASK (0x3800)
> +#define MPI2_BIOSPAGE1_OPTIONS_PNS_PBDHL(0x)
> +#define MPI2_BIOSPAGE1_OPTIONS_PNS_ENCSLOSURE   (0x0800)
> +#define MPI2_BIOSPAGE1_OPTIONS_PNS_LWWID(0x1000)
> +#define MPI2_BIOSPAGE1_OPTIONS_PNS_PSENS(0x1800)
> +#define MPI2_BIOSPAGE1_OPTIONS_PNS_ESPHY(0x2000)
> +
>  #define MPI2_BIOSPAGE1_OPTIONS_X86_DISABLE_BIOS  (0x0400)
>  
>  #define MPI2_BIOSPAGE1_OPTIONS_MASK_REGISTRATION_UEFI_BSD(0x0300)
> -- 
> 2.0.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn 

Re: [PATCH 15/20] [SCSI] mpt3sas: Return host busy error status to SML when DMA mapping of scatter gather list fails for a SCSI command

[Johannes Thumshirn]

On Fri, Jun 12, 2015 at 03:12:27PM +0530, Sreekanth Reddy wrote:
> scsi_dma_map API will return a negative value (i.e. -ENOMEM)
> if DMA mapping of sg lists fails and zero if the sg list in the
> SCSI cmd is NULL. But drivers doesn't handled sg list DMA mapping
> failure case properly.
> 
> So, Updated the code to return host busy error status to SCSI MID Layer(SML),
> when DMA mapping of scatter gather list fails for a SCSI command.
> So that SML will retry this SCSI cmd after some time.
> 
> Signed-off-by: Sreekanth Reddy 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index 267e489..0b26c8d 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -1345,7 +1345,7 @@ _base_build_sg_scmd_ieee(struct MPT3SAS_ADAPTER *ioc,
>  
>   sg_scmd = scsi_sglist(scmd);
>   sges_left = scsi_dma_map(scmd);
> - if (!sges_left) {
> + if (!sges_left < 0) {
>   sdev_printk(KERN_ERR, scmd->device,
>   "pci_map_sg failed: request for %d bytes!\n",
>   scsi_bufflen(scmd));
> @@ -1414,7 +1414,7 @@ _base_build_sg_scmd_ieee(struct MPT3SAS_ADAPTER *ioc,
>   fill_in_last_segment:
>  
>   /* fill the last segment */
> - while (sges_left) {
> + while (sges_left > 0) {
>   if (sges_left == 1)
>   _base_add_sg_single_ieee(sg_local,
>   simple_sgl_flags_last, 0, sg_dma_len(sg_scmd),
> -- 
> 2.0.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn   Storage
jthumsh...@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1 linux-next] mmc: queue: use swap() in mmc_queue_thread()

[Ulf Hansson]

On 10 June 2015 at 18:30, Fabian Frederick  wrote:
> Use kernel.h macro definition.
>
> Thanks to Julia Lawall for Coccinelle scripting support.
>
> Signed-off-by: Fabian Frederick 

Thanks, applied.

Kind regards
Uffe

> ---
>  drivers/mmc/card/queue.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
> index 8efa368..d34e09b 100644
> --- a/drivers/mmc/card/queue.c
> +++ b/drivers/mmc/card/queue.c
> @@ -56,7 +56,6 @@ static int mmc_queue_thread(void *d)
> down(&mq->thread_sem);
> do {
> struct request *req = NULL;
> -   struct mmc_queue_req *tmp;
> unsigned int cmd_flags = 0;
>
> spin_lock_irq(q->queue_lock);
> @@ -86,9 +85,7 @@ static int mmc_queue_thread(void *d)
>
> mq->mqrq_prev->brq.mrq.data = NULL;
> mq->mqrq_prev->req = NULL;
> -   tmp = mq->mqrq_prev;
> -   mq->mqrq_prev = mq->mqrq_cur;
> -   mq->mqrq_cur = tmp;
> +   swap(mq->mqrq_prev, mq->mqrq_cur);
> } else {
> if (kthread_should_stop()) {
> set_current_state(TASK_RUNNING);
> --
> 2.4.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 1/3] pci_ids: Add AMD KERNCZ device ID support

[Ulf Hansson]

On 12 June 2015 at 22:34, Bjorn Helgaas  wrote:
> On Thu, Jun 11, 2015 at 08:11:45PM +0800, Wan ZongShun wrote:
>> The KERNCZ is new AMD SB/FCH generation name, like HUDSON2.
>> We will adopt 0x790b as device ID since from this gereration.
>
> s/We will adopt 0x790b as device ID since from/0x790b is the device ID for/
> s/gereration/generation/
>
>> Signed-off-by: Wan ZongShun 
>
> Acked-by: Bjorn Helgaas 

Thanks, applied with Bjorn's ack and his suggested changes.

Kind regards
Uffe

>
>> ---
>>  include/linux/pci_ids.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
>> index 2f7b9a4..cb63a7b 100644
>> --- a/include/linux/pci_ids.h
>> +++ b/include/linux/pci_ids.h
>> @@ -579,6 +579,7 @@
>>  #define PCI_DEVICE_ID_AMD_HUDSON2_SATA_IDE   0x7800
>>  #define PCI_DEVICE_ID_AMD_HUDSON2_SMBUS  0x780b
>>  #define PCI_DEVICE_ID_AMD_HUDSON2_IDE0x780c
>> +#define PCI_DEVICE_ID_AMD_KERNCZ_SMBUS  0x790b
>>
>>  #define PCI_VENDOR_ID_TRIDENT0x1023
>>  #define PCI_DEVICE_ID_TRIDENT_4DWAVE_DX  0x2000
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] mmc: card: Fixup request missing in mmc_blk_issue_rw_rq

[Ulf Hansson]

On 12 June 2015 at 14:38, Justin Wang (王丁)  wrote:
> From 0e01e7546745f39843d54810f74c198e01cb8226 Mon Sep 17 00:00:00 2001
> From: justin.wang 
> Date: Mon, 18 May 2015 20:14:15 +0800
> Subject: [PATCH v2] mmc: card: Fixup request missing in mmc_blk_issue_rw_rq
>
> The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function
> may cause new coming request permanent missing when the ongoing
> request (previoulsy started) complete end.
>
> The problem scenario is as follows:
> (1) Request A is ongoing;
> (2) Request B arrived, and finally mmc_blk_issue_rw_rq() is called;
> (3) Request A encounters the MMC_BLK_CMD_ERR error;
> (4) In the error handling of MMC_BLK_CMD_ERR, suppose mmc_blk_cmd_err()
> end request A completed and return zero. Continue the error handling,
> suppose mmc_blk_reset() reset device success;
> (5) Continue the execution, while loop completed because variable ret
> is zero now;
> (6) Finally, mmc_blk_issue_rw_rq() return without processing request B.
>
> The process related to the missing request may wait that IO request
> complete forever, possibly crashing the application or hanging the system.
>
> Fix this issue by starting new request when reset success.
>
> Signed-off-by: Ding Wang 

Thanks, applied for next.

I have added a the following fixes tag:
Fixes 67716327eec7 ("mmc: block: add eMMC hardware reset support")
I am not sure, whether the bug were introduced even earlier than that,
but I think $subject patch should be trivial to apply on top that one.

Kind regards
Uffe

> ---
>  drivers/mmc/card/block.c |8 +---
>  1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 60f7141..f05cd1f 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -1910,9 +1910,11 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, 
> struct request *rqc)
> break;
> case MMC_BLK_CMD_ERR:
> ret = mmc_blk_cmd_err(md, card, brq, req, ret);
> -   if (!mmc_blk_reset(md, card->host, type))
> -   break;
> -   goto cmd_abort;
> +   if (mmc_blk_reset(md, card->host, type))
> +   goto cmd_abort;
> +   if (!ret)
> +   goto start_new_req;
> +   break;
> case MMC_BLK_RETRY:
> if (retry++ < 5)
> break;
> --
> 1.7.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/