Re: [PATCH] net: tulip: update MAINTAINER status to Orphan

[Helge Deller]

On 20.11.2015 03:41, Grant Grundler wrote:
> On Thu, Nov 19, 2015 at 6:29 PM, Florian Fainelli  
> wrote:
>> On 19/11/15 17:56, Grant Grundler wrote:
>>> From: Grant Grundler 
>>>
>>> I haven't had any PCI tulip HW for the past ~5 years. I have
>>> been reviewing tulip patches and can continue doing that.
>>>
>>> Signed-off-by: Grant Grundler 
>>> ---
>>> I'm also proposing to add linux-parisc to the list since AFAIK, all
>>> parisc systems but the C8000 workstations (PA8800/PA8900 CPU)
>>> use tulip for onboard LAN.
>>>
>>> Specific mips and alpha systems also care about tulip driver too.
>>> But I don't know either well enough to suggest respective mailing
>>> lists should see every tulip patch.
>>
>> For MIPS, is not Cobalt the primary (and sole) user?
> 
> Once upon a time a Mips based router was using tulip as well. I know
> they needed to "borrow" some tulip patches that were only in
> parisc-linux source tree (for reasons I don't see a need to repeat
> here).
> 
>> You could add linux-m...@linux-mips.org if that helps.
> 
> I wanted to let the mips folks decide if they should be listedand
> CC'd Helge (parisc maintainer) in case he objected to added
> linux-parisc mailing list.

Yes, adding the linux-parisc mailing list is OK.

Acked-by: Helge Deller 

>>>
>>>  MAINTAINERS | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index ea17512..ec07061 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -10888,9 +10888,9 @@ S:Maintained
>>>  F:   drivers/media/tuners/tua9001*
>>>
>>>  TULIP NETWORK DRIVERS
>>> -M:   Grant Grundler 
>>>  L:   net...@vger.kernel.org
>>> -S:   Maintained
>>> +L:   linux-par...@vger.kernel.org
>>> +S:   Orphan
>>>  F:   drivers/net/ethernet/dec/tulip/
>>>
>>>  TUN/TAP driver

--
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 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:13 PM, Laurent Pinchart
 wrote:
> On Thursday 19 November 2015 21:44:27 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 9:26 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote:
>> >> Amend the DT bindings to include the optional clock sources for the Baud
>> >> Rate Generator for External Clock (BRG), as found on some SCIF variants
>> >> and on HSCIF.
>> >>
>> >> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >>
>> >> @@ -46,6 +46,12 @@ Required properties:
>> >>  On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>> >>- "hsck" for the optional external clock input (on HSCIF),
>> >>- "sck" for the optional external clock input (on other variants).
>> >>
>> >> +On UARTs equipped with a Baud Rate Generator for External Clock
>> >> (BRG)
>> >> +(some SCIF and HSCIF), additional clocks may be specified:
>> >> +  - "int_clk" for the optional internal clock source for the
>> >> frequency
>> >> + divider (typically the (AXI or SHwy) bus clock),
>> >
>> > Isn't this always the same clock as the SCIF functional clock ?
>>
>> (On R-Car Gen2/3)
>>
>> No, SCIF uses different parents for fck (p) and int_clk (zs).
>
> Right, my bad.
>
> Should we rename "int_clk" to something that makes it explicit that the clock
> is used as the BRG-EC input ? Maybe brg_clk, int_brg, int_brg_clk ? We
> probably don't need to keep the _clk suffix as it's quite evident that a clock
> name refers to a clock.

The documentation always uses the SoC-specific explicit clock name (e.g. zs
s3d1, or clks), or just "internal clock", so I used "int_clk".

But I agree "int_brg" sounds better.

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/

[PATCH] regulator: of: simplifing the parsing code

[Saurabh Sengar]

in case of_property_read_u32 fails, it keeps the parameter unchanged
so no need to test if its success and then assign the value

Signed-off-by: Saurabh Sengar 
---
Hi Mark,

I also have concern related to how we are passing 'regulator-mode' and
'regulator-initial-mode'. Currently this require a extra function to be
set in 'of_map_mode', which can be avoided.
These two parameters can be set directly from the device tree as in below patch:
https://lkml.org/lkml/2014/1/16/263
All drivers can have only out of 4 predefined values for these parameters,
define in linux/iregulator/consumer.h, its not driver specific.
Please let me know your comments, if this suits you I will send a one more
patch on top of this it will further simplify this code.
Regards,
Saurabh


 drivers/regulator/of_regulator.c | 41 +---
 1 file changed, 17 insertions(+), 24 deletions(-)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 499e437..61b74a9 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -51,16 +51,14 @@ static void of_get_regulation_constraints(struct 
device_node *np,
if (min_uV && max_uV && constraints->min_uV == constraints->max_uV)
constraints->apply_uV = true;
 
-   if (!of_property_read_u32(np, "regulator-microvolt-offset", ))
-   constraints->uV_offset = pval;
-   if (!of_property_read_u32(np, "regulator-min-microamp", ))
-   constraints->min_uA = pval;
-   if (!of_property_read_u32(np, "regulator-max-microamp", ))
-   constraints->max_uA = pval;
-
-   if (!of_property_read_u32(np, "regulator-input-current-limit-microamp",
- ))
-   constraints->ilim_uA = pval;
+   of_property_read_u32(np, "regulator-microvolt-offset",
+   >uV_offset);
+   of_property_read_u32(np, "regulator-min-microamp",
+   >min_uA);
+   of_property_read_u32(np, "regulator-max-microamp",
+   >max_uA);
+   of_property_read_u32(np, "regulator-input-current-limit-microamp",
+   >ilim_uA);
 
/* Current change possible? */
if (constraints->min_uA != constraints->max_uA)
@@ -79,17 +77,13 @@ static void of_get_regulation_constraints(struct 
device_node *np,
if (of_property_read_bool(np, "regulator-allow-set-load"))
constraints->valid_ops_mask |= REGULATOR_CHANGE_DRMS;
 
-   ret = of_property_read_u32(np, "regulator-ramp-delay", );
-   if (!ret) {
-   if (pval)
-   constraints->ramp_delay = pval;
-   else
+   if (!of_property_read_u32(np, "regulator-ramp-delay",
+   >ramp_delay))
+   if (!constraints->ramp_delay)
constraints->ramp_disable = true;
-   }
 
-   ret = of_property_read_u32(np, "regulator-enable-ramp-delay", );
-   if (!ret)
-   constraints->enable_time = pval;
+   of_property_read_u32(np, "regulator-enable-ramp-delay",
+   >enable_time);
 
constraints->soft_start = of_property_read_bool(np,
"regulator-soft-start");
@@ -107,8 +101,8 @@ static void of_get_regulation_constraints(struct 
device_node *np,
}
}
 
-   if (!of_property_read_u32(np, "regulator-system-load", ))
-   constraints->system_load = pval;
+   of_property_read_u32(np, "regulator-system-load",
+   >system_load);
 
constraints->over_current_protection = of_property_read_bool(np,
"regulator-over-current-protection");
@@ -154,9 +148,8 @@ static void of_get_regulation_constraints(struct 
device_node *np,
"regulator-off-in-suspend"))
suspend_state->disabled = true;
 
-   if (!of_property_read_u32(suspend_np,
-   "regulator-suspend-microvolt", ))
-   suspend_state->uV = pval;
+   of_property_read_u32(suspend_np,
+   "regulator-suspend-microvolt", _state->uV);
 
of_node_put(suspend_np);
suspend_state = NULL;
-- 
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: [RFD] CAT user space interface revisited

[Thomas Gleixner]

On Thu, 19 Nov 2015, Marcelo Tosatti wrote:
> On Thu, Nov 19, 2015 at 10:09:03AM +0100, Thomas Gleixner wrote:
> > On Wed, 18 Nov 2015, Marcelo Tosatti wrote
> > > Actually, there is a point that is useful: you might want the important
> > > application to share the L3 portion with HW (that HW DMAs into), and
> > > have only the application and the HW use that region.
> > > 
> > > So its a good point that controlling the exact position of the 
> > > reservation 
> > > is important.
> > 
> > I'm glad you figured that out yourself. :)
> > 
> > Thanks,
> > 
> > tglx
> 
> The HW is a reclaimer of the L3 region shared with HW.
> 
> You might want to remove any threads from reclaiming from 
> that region.

I might for some threads, but certainly not for those which need to
access DMA buffers. Throwing away 10% of L3 just because you don't
want to deal with it at the interface level is hillarious.

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 majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:04 PM, Laurent Pinchart
 wrote:
> On Thursday 19 November 2015 19:38:57 Geert Uytterhoeven wrote:
>> Refactor the clock and baud rate parameter code to ease adding support
>> for multiple clocks and baud rate generators later.
>> sci_scbrr_calc() now returns the bit rate error, so it can be compared
>> to the bit rate error for other baud rate generators.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>>  drivers/tty/serial/sh-sci.c | 176 +++--
>>  1 file changed, 120 insertions(+), 56 deletions(-)
>>
>> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> index 726c96d5a511c222..12800e52f41953dc 100644
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c

>> @@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
>>
>>  static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
>>  {
>> - /* Get the SCI functional clock. It's called "fck" on ARM. */
>> - sci_port->fclk = devm_clk_get(dev, "fck");
>> - if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
>> - return -EPROBE_DEFER;
>> - if (!IS_ERR(sci_port->fclk))
>> - return 0;
>> + const char *clk_names[] = {
>> + [SCI_FCK] = "fck",
>> + };
>> + struct clk *clk;
>> + unsigned int i;
>>
>> - /*
>> -  * But it used to be called "sci_ick", and we need to maintain DT
>> -  * backward compatibility.
>> -  */
>> - sci_port->fclk = devm_clk_get(dev, "sci_ick");
>> - if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
>> - return -EPROBE_DEFER;
>> - if (!IS_ERR(sci_port->fclk))
>> - return 0;
>> + for (i = 0; i < SCI_NUM_CLKS; i++) {
>> + clk = devm_clk_get(dev, clk_names[i]);
>> + if (PTR_ERR(clk) == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>>
>> - /*
>> -  * Not all SH platforms declare a clock lookup entry for SCI devices,
>> -  * in which case we need to get the global "peripheral_clk" clock.
>> -  */
>> - sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
>> - if (!IS_ERR(sci_port->fclk))
>> - return 0;
>> + if (IS_ERR(clk) && i == SCI_FCK) {
>> + /*
>> +  * "fck" used to be called "sci_ick", and we need to
>> +  * maintain DT backward compatibility.
>> +  */
>> + clk = devm_clk_get(dev, "sci_ick");
>> + if (PTR_ERR(clk) == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> +
>> + if (!IS_ERR(clk))
>> + goto found;
>> +
>> + /*
>> +  * Not all SH platforms declare a clock lookup entry
>> +  * for SCI devices, in which case we need to get the
>> +  * global "peripheral_clk" clock.
>> +  */
>> + clk = devm_clk_get(dev, "peripheral_clk");
>> + if (!IS_ERR(clk))
>> + goto found;
>> +
>> + dev_err(dev, "failed to get functional clock\n");
>> + return PTR_ERR(clk);
>> + }
>>
>> - dev_err(dev, "failed to get functional clock\n");
>> - return PTR_ERR(sci_port->fclk);
>> +found:
>> + if (!IS_ERR(clk))
>> + dev_dbg(dev, "clk %u is %pC rate %pCr\n", i, clk, clk);
>> + sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
>
> Isn't it an issue that we can't tell apart the case where there is no clock
> specified in DT and the case where we can't get the clock due to another error
> ?

All failures here are for optional clocks.
If the real failure is that the clock wasn't specified (or misspelled) in DT,
it should have been detected during the integration phase.

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: [PATCH v3 0/3] virtio DMA API core stuff

[Michael S. Tsirkin]

On Fri, Nov 20, 2015 at 08:56:46AM +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 19, 2015 at 01:59:05PM -0800, Andy Lutomirski wrote:
> > On Nov 19, 2015 5:45 AM, "Michael S. Tsirkin"  wrote:
> > >
> > > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote:
> > > > This switches virtio to use the DMA API unconditionally.  I'm sure
> > > > it breaks things, but it seems to work on x86 using virtio-pci, with
> > > > and without Xen, and using both the modern 1.0 variant and the
> > > > legacy variant.
> > >
> > > So thinking hard about it, I don't see any real drawbacks to making this
> > > conditional on a new feature bit, that Xen can then set..
> > 
> > Can you elaborate?  If I run QEMU, hosting Xen, hosting Linux, and the
> > virtio device is provided by QEMU, then how does Xen set the bit?
> 
> You would run QEMU with the appropriate flag. E.g.
> -global virtio-pci,use_platform_dma=on

Or Xen code within QEMU can tweak this global internally
so users don't need to care.

> > Similarly, how would Xen set the bit for a real physical device?
> > 
> > 
> > --Andy
> 
> There's no need to set bits for physical devices I think: from security
> point of view, using them from a VM isn't very different from using them
> from host.
> 
> 
> 
> -- 
> MST
--
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 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart
 wrote:
> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
>> The "renesas,scif" compatible value is currently used for the SCIF
>> variant in all Renesas SoCs of the R-Car family.  However, the variant
>> used in the R-Car family is not the common "SH-4(A)" variant, but a
>> derivative with added "Baud Rate Generator for External Clock" (BRG),
>> which is also present in sh7734.
>
> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
>
> As the only DT-enabled platform to have a different SCIF type is r7s72100 we
> could also consider just switching the regtype to SCIx_SH4_SCIF_BRG_REGTYPE
> for the generic "renesas,scif" entry as it's listed after the "renesas,scif-
> r7s72100" entry. That might cause an issue if we want to enable DT on arch/sh
> though, but even if that happens due to the J-Core processors I'd be surprised
> to see the old Renesas SH platforms being moved to DT.

I thought about that, but you never know in which out-of-tree BSP it ended up
being used, too. So better safe than sorry.

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/

[PATCH v2 0/2] fix a possible NULL dereference

[LABBE Corentin]

Hello

The main goal of this patch series is to fix a possible NULL dereference.
Even if the probability of this case is very low, fixing it made
static analyzers happy.
In the same time it permits to remove a "cast that drop const qualifiers.

Regards

Changes since v1
- Use of_device_get_match_data
- Add the missing patch for constify atmel_nand_caps structures

LABBE Corentin (2):
  mtd: nand: atmel_nand: constify atmel_nand_caps structures
  mtd: nand: atmel_nand: fix a possible NULL dereference

 drivers/mtd/nand/atmel_nand.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

-- 
2.4.10

--
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 1/2] mtd: nand: atmel_nand: constify atmel_nand_caps structures

[LABBE Corentin]

All atmel_nand_caps are never modified, consitify them.

Signed-off-by: LABBE Corentin 
---
 drivers/mtd/nand/atmel_nand.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 583cdd9..475c938 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -128,7 +128,7 @@ struct atmel_nand_host {
 
struct atmel_nfc*nfc;
 
-   struct atmel_nand_caps  *caps;
+   const struct atmel_nand_caps*caps;
boolhas_pmecc;
u8  pmecc_corr_cap;
u16 pmecc_sector_size;
@@ -2304,11 +2304,11 @@ static int atmel_nand_remove(struct platform_device 
*pdev)
return 0;
 }
 
-static struct atmel_nand_caps at91rm9200_caps = {
+static const struct atmel_nand_caps at91rm9200_caps = {
.pmecc_correct_erase_page = false,
 };
 
-static struct atmel_nand_caps sama5d4_caps = {
+static const struct atmel_nand_caps sama5d4_caps = {
.pmecc_correct_erase_page = true,
 };
 
-- 
2.4.10

--
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] KVM: x86: emulate: correct page fault error code for NoWrite instructions

[Nadav Amit]

Wanpeng Li  wrote:

> 2015-11-20 10:52 GMT+08:00 Wanpeng Li :
>> Hi Paolo,
>> 2015-02-09 17:03 GMT+08:00 Paolo Bonzini :
>>> NoWrite instructions (e.g. cmp or test) never set the "write access"
>>> bit in the error code, even if one of the operands is treated as a
>>> destination.
>> 
>> Sorry to reply to an old commit, btw, could you point out where in SDM
>> describe above?
> 
> I see.

I don’t understand whether you still need my help, so to clarify: on a
page-fault the error code should indicate whether the access was due to a
write access. Previously KVM marked it as “write access” for instructions
such as test and cmp that do not perform write.

Nadav--
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 2/2] mtd: nand: atmel_nand: fix a possible NULL dereference

[LABBE Corentin]

of_match_device could return NULL, and so cause a NULL pointer
dereference later.

Signed-off-by: LABBE Corentin 
---
 drivers/mtd/nand/atmel_nand.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 475c938..7902967 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -1496,8 +1496,9 @@ static int atmel_of_init_port(struct atmel_nand_host 
*host,
struct atmel_nand_data *board = >board;
enum of_gpio_flags flags = 0;
 
-   host->caps = (struct atmel_nand_caps *)
-   of_match_device(atmel_nand_dt_ids, host->dev)->data;
+   host->caps = of_device_get_match_data(host->dev);
+   if (!host->caps)
+   return 1;
 
if (of_property_read_u32(np, "atmel,nand-addr-offset", ) == 0) {
if (val >= 32) {
-- 
2.4.10

--
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] ASoC: fsl_esai: spba clock is needed by esai device

[Nicolin Chen]

On Fri, Nov 20, 2015 at 02:17:51PM +0800, Shengjiu Wang wrote:

> diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt 
> b/Documentation/devicetree/bindings/sound/fsl,esai.txt
> index d3b6b5f..f1d5351 100644
> --- a/Documentation/devicetree/bindings/sound/fsl,esai.txt
> +++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt
> @@ -27,6 +27,8 @@ Required properties:
> derive HCK, SCK and FS.
>   "fsys"The system clock derived from ahb clock used to
> derive HCK, SCK and FS.
> + "spba"The spba clock is needed when two spba master port
> +   is used.

I was expecting a little bit more detail like:

+   "spba"  The spba clock is required when ESAI is placed as
a bus slave of the Shared Peripheral Bus and when
two or more bus masters (CPU, DMA or DSP) try to
access it. This property is optional depending on
the SoC design.

> diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
> index 504e731..8749f53 100644
> --- a/sound/soc/fsl/fsl_esai.c
> +++ b/sound/soc/fsl/fsl_esai.c
> @@ -54,6 +54,7 @@ struct fsl_esai {
>   struct clk *coreclk;
>   struct clk *extalclk;
>   struct clk *fsysclk;
> + struct clk *spbaclk;

Please add one entry in the comment above for the new clock.

> @@ -819,6 +826,11 @@ static int fsl_esai_probe(struct platform_device *pdev)
>   dev_warn(>dev, "failed to get fsys clock: %ld\n",
>   PTR_ERR(esai_priv->fsysclk));
>  
> + esai_priv->spbaclk = devm_clk_get(>dev, "spba");
> + if (IS_ERR(esai_priv->spbaclk))
> + dev_warn(>dev, "Cannot get spba clock: %ld\n",

It'd be better to write the warning following the previous one:
+   dev_warn(>dev, "failed to get spba clock: %ld\n",
--
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/3] clk: let of_clk_get_parent_name() fail for invalid clock-indices

[Masahiro Yamada]

Currently, of_clk_get_parent_name() returns a wrong parent clock name
when "clock-indices" property exists and the given index is not found
in the property.  In this case, NULL should be returned.

For example,

oscillator {
compatible = "myclocktype";
#clock-cells = <1>;
clock-indices = <1>, <3>;
clock-output-names = "clka", "clkb";
};

Currently, of_clk_get_parent_name(np, 0) returns "clka", but should
return NULL because "clock-indices" does not contain <0>.

Signed-off-by: Masahiro Yamada 
---

 drivers/clk/clk.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 20d8e07..8698074 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3054,12 +3054,9 @@ EXPORT_SYMBOL_GPL(of_clk_get_parent_count);
 const char *of_clk_get_parent_name(struct device_node *np, int index)
 {
struct of_phandle_args clkspec;
-   struct property *prop;
const char *clk_name;
-   const __be32 *vp;
-   u32 pv;
-   int rc;
-   int count;
+   const __be32 *list;
+   int rc, len, i;
struct clk *clk;
 
rc = of_parse_phandle_with_args(np, "clocks", "#clock-cells", index,
@@ -3068,17 +3065,20 @@ const char *of_clk_get_parent_name(struct device_node 
*np, int index)
return NULL;
 
index = clkspec.args_count ? clkspec.args[0] : 0;
-   count = 0;
 
/* if there is an indices property, use it to transfer the index
 * specified into an array offset for the clock-output-names property.
 */
-   of_property_for_each_u32(clkspec.np, "clock-indices", prop, vp, pv) {
-   if (index == pv) {
-   index = count;
-   break;
-   }
-   count++;
+   list = of_get_property(clkspec.np, "clock-indices", );
+   if (list) {
+   len /= sizeof(*list);
+   for (i = 0; i < len; i++)
+   if (index == be32_to_cpup(list++)) {
+   index = i;
+   break;
+   }
+   if (i == len)
+   return NULL;
}
 
if (of_property_read_string_index(clkspec.np, "clock-output-names",
-- 
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 3/3] clk: split of_clk_get_parent_name() into two functions

[Masahiro Yamada]

Currently, there is no function to get the clock name of the given
node.  Create a new helper function, of_clk_get_name().  This is
useful to get the clock name where "clock-indices" property is used.

  of_clk_get_name(): get the clock name in the given node
  of_clk_get_parent_name(): get the name of the parent clock

Signed-off-by: Masahiro Yamada 
---

I want to use of_clk_get_name() for my clk drivers for my SoCs,
which I will submit later.

I found this helper function is useful.


 drivers/clk/clk.c| 45 +++-
 include/linux/clk-provider.h |  1 +
 2 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8698074..1788ec7 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3051,25 +3051,17 @@ int of_clk_get_parent_count(struct device_node *np)
 }
 EXPORT_SYMBOL_GPL(of_clk_get_parent_count);
 
-const char *of_clk_get_parent_name(struct device_node *np, int index)
+const char *of_clk_get_name(struct device_node *np, int index)
 {
-   struct of_phandle_args clkspec;
const char *clk_name;
const __be32 *list;
-   int rc, len, i;
-   struct clk *clk;
-
-   rc = of_parse_phandle_with_args(np, "clocks", "#clock-cells", index,
-   );
-   if (rc)
-   return NULL;
-
-   index = clkspec.args_count ? clkspec.args[0] : 0;
+   int len, i, rc;
 
-   /* if there is an indices property, use it to transfer the index
+   /*
+* if there is an indices property, use it to transfer the index
 * specified into an array offset for the clock-output-names property.
 */
-   list = of_get_property(clkspec.np, "clock-indices", );
+   list = of_get_property(np, "clock-indices", );
if (list) {
len /= sizeof(*list);
for (i = 0; i < len; i++)
@@ -3081,9 +3073,29 @@ const char *of_clk_get_parent_name(struct device_node 
*np, int index)
return NULL;
}
 
-   if (of_property_read_string_index(clkspec.np, "clock-output-names",
- index,
- _name) < 0) {
+   rc = of_property_read_string_index(np, "clock-output-names", index,
+  _name);
+
+   return rc ? NULL : clk_name;
+}
+EXPORT_SYMBOL_GPL(of_clk_get_name);
+
+const char *of_clk_get_parent_name(struct device_node *np, int index)
+{
+   struct of_phandle_args clkspec;
+   const char *clk_name;
+   struct clk *clk;
+   int rc;
+
+   rc = of_parse_phandle_with_args(np, "clocks", "#clock-cells", index,
+   );
+   if (rc)
+   return NULL;
+
+   index = clkspec.args_count ? clkspec.args[0] : 0;
+
+   clk_name = of_clk_get_name(clkspec.np, index);
+   if (!clk_name) {
/*
 * Best effort to get the name if the clock has been
 * registered with the framework. If the clock isn't
@@ -3102,7 +3114,6 @@ const char *of_clk_get_parent_name(struct device_node 
*np, int index)
}
}
 
-
of_node_put(clkspec.np);
return clk_name;
 }
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index e7bd710..c6ff498 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -702,6 +702,7 @@ struct clk *of_clk_src_onecell_get(struct of_phandle_args 
*clkspec, void *data);
 int of_clk_get_parent_count(struct device_node *np);
 int of_clk_parent_fill(struct device_node *np, const char **parents,
   unsigned int size);
+const char *of_clk_get_name(struct device_node *np, int index);
 const char *of_clk_get_parent_name(struct device_node *np, int index);
 
 void of_clk_init(const struct of_device_id *matches);
-- 
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 1/3] clk: remove redundant negative index check in of_clk_get_parent_name()

[Masahiro Yamada]

This if-block can be dropped because the of_parse_phandle_with_args()
in the following line returns -EINVAL for negative index.

Signed-off-by: Masahiro Yamada 
---

 drivers/clk/clk.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 764aca2..20d8e07 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3062,9 +3062,6 @@ const char *of_clk_get_parent_name(struct device_node 
*np, int index)
int count;
struct clk *clk;
 
-   if (index < 0)
-   return NULL;
-
rc = of_parse_phandle_with_args(np, "clocks", "#clock-cells", index,
);
if (rc)
-- 
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 00/71] More fixes, cleanup and modernization for NCR5380 drivers

[Ondrej Zary]

On Friday 20 November 2015, Finn Thain wrote:
> 
> On Thu, 19 Nov 2015, Ondrej Zary wrote:
> 
> > On Thursday 19 November 2015 03:24:56 Finn Thain wrote:
> >
> > > On Wed, 18 Nov 2015, Ondrej Zary wrote:
> > >
> > > >
> > > > I have some NCR5380 ISA cards and can test them.
> > >
> > > Thanks Ondrej. I've no idea which ISA drivers are presently working in 
> > > mainline. Finding regressions may be more difficult than usual ;-)
> > 
> > You're right... looks very broken:
> > 
> > [   62.577194] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, 
> > n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, 
> > sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, USLEEP_POLL 
> > 3, USLEEP_WAITLONG 1250, options { AUTOPROBE_IRQ PSEUDO_DMA 
> > NCR53C400 }
> > [   62.796635] scsi 2:0:0:0: Direct-Access IBM  0663 e  
> >   PQ: 0 ANSI: 2
> > [   63.878494] sd 2:0:0:0: Attached scsi generic sg1 type 0
> > [   95.848260] sd 2:0:0:0: aborting command
> > 
> > And the system hangs completely.
> > 
> 
> Yes. That was the usual failure mode. The old EH abort routine is fatal. 
> Up until I disabled PDMA by default for mac_scsi (in v3.19), that driver 
> would do the same thing.
> 
> > It's much better with your patches, but still not great :)
> > 
> 
> Pleased to hear it :)
> 
> > [   93.963264] pnp 01:01.00: [io  0x0240-0x025f]
> > [   93.963493] pnp 01:01.00: [irq 5]
> > [   93.965768] pnp 01:01.00: activated
> > [   93.977147] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x240, 
> > n_io_port 16, base 0x0, irq 0, can_queue 16, cmd_per_lun 2, 
> > sg_tablesize 128, this_id 7, flags { DTC3181E NO_PSEUDO_DMA }, options { 
> > AUTOPROBE_IRQ PSEUDO_DMA }
> > [   93.987527] scsi host2: rejecting message
> > [   93.987647] Synchronous Data Transfer Request period = 100 ns offset = 12
> > [   94.001219] scsi 2:0:0:0: Direct-Access IBM  0663 e  
> >   PQ: 0 ANSI: 2
> > [  113.000794] sd 2:0:0:0: Attached scsi generic sg1 type 0
> 
> I'd be interested to know what commands were in play in that 19 second 
> interval. Might need to use scsi_logging_level to figure that out.
> 
> My tests involved 3 different scsi targets (two disks and a CD-ROM) but 
> none of these send a SDTR. Your log says the driver correctly rejected the 
> SDTR message but that doesn't mean the target actually went to MSG IN 
> phase and got the message. Do you have any older targets you can test?

Yes, I have some older disks too and also CD-ROMs. This one was just handy in
an external enclosure (the card has only an external DB25 connector). It can
be opened easily so I'll test the other devices too.

> > [  144.852432] sd 2:0:0:0: [sdb] Unit Not Ready
> > [  144.852574] sd 2:0:0:0: [sdb] Sense Key : Aborted Command [current]
> > [  144.852713] sd 2:0:0:0: [sdb] Add. Sense: Select or reselect failure
> 
> AFAIK, the target should not have to abort any commands. Moreover, the 
> target should never experience a select/reselect failure, because you have 
> irq == 0 (see above) and that implies that the target is never permitted 
> the disconnect privilege.
> 
> > [  240.108292] INFO: task modprobe:1957 blocked for more than 120 seconds.
> > [  240.108418]   Not tainted 4.3.0-rc1+ #74
> 
> Why not use v4.3?

I had that already built so just quickly applied the patches and tested. I have
to update the git tree anyway as ACPI is broken.

> > [  240.108501] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> > this message.
> > [  240.108597] modprobeD 001a 0  1957   1950 0x
> > [  240.108790]  ce0fad00 0086 53881781 001a c1525f88 4edbe39c 
> > 001a 04ac33e5
> > [  240.109246]   ccd54000   d204b280 c139c504 
> >  c104416d
> > [  240.109699]   ce0fad00 c1054a45 c151fd8c c151fd8c d204b280 
> >  ccd6d100
> > [  240.110156] Call Trace:
> > [  240.110295]  [] ? schedule+0x5b/0x67
> > [  240.110430]  [] ? async_synchronize_cookie_domain+0x73/0x9f
> > [  240.110569]  [] ? abort_exclusive_wait+0x6e/0x6e
> > [  240.110699]  [] ? do_init_module+0xa4/0x1a3
> > [  240.110824]  [] ? load_module+0x14de/0x18ca
> > [  240.110948]  [] ? SyS_finit_module+0x47/0x56
> > [  240.111068]  [] ? sysenter_do_call+0x12/0x12
> 
> Not sure what module was being probed here. I presume it was g_NCR5380 or 
> g_NCR5380_mmio. Neither of these calls 'scsi_scan_host'. I'm not sure what 
> the implications are (?)

It was g_NCR5380 (DTCT-436P card).

> > [  240.852458] sd 2:0:0:0: [sdb] Read Capacity(10) failed: Result: 
> > hostbyte=DID_TIME_OUT driverbyte=DRIVER_SENSE
> > [  240.852620] sd 2:0:0:0: [sdb] Sense Key : Aborted Command [current]
> > [  240.852760] sd 2:0:0:0: [sdb] Add. Sense: Select or reselect failure
> > [  272.852471] sd 2:0:0:0: [sdb] Write Protect is off
> > [  272.852614] sd 2:0:0:0: [sdb] Mode Sense: 00 00 00 00
> > [  304.084452] sd 2:0:0:0: [sdb] Asking for cache data failed
> > [  304.084592] sd 

Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

[Christoph Hellwig]

On Fri, Nov 20, 2015 at 06:21:06PM +1100, Finn Thain wrote:
> > Not sure what module was being probed here. I presume it was g_NCR5380 
> > or g_NCR5380_mmio. Neither of these calls 'scsi_scan_host'. I'm not sure 
> > what the implications are (?)
> 
> Nevermind. The call is in scsi_module.c.

Which, btw really need to go away.  If you want to resurrect the
ISA drivers they need to be converted to proper probing.
--
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] fpga: zynq-fpga: Enable pm_runtime (suspend, resume)

[Mike Looijmans]

On 19-11-15 23:07, Moritz Fischer wrote:

Replaced constant clock_{enable,disable} calls with pm_runtime
hooks for suspend and resume to avoid constant clk_enable /
clk_disable.

Acked-by: Alan Tull 
Signed-off-by: Moritz Fischer 
---
Changes:

v1:
   - Removed superfluous #ifdef CONFIG_PM as suggested by Michal
   - Changed commit message to include suspend / resume
   - Added Alan's Acked-by

  drivers/fpga/zynq-fpga.c | 76 +---
  1 file changed, 59 insertions(+), 17 deletions(-)

diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
index c2fb412..3f5469d 100644
--- a/drivers/fpga/zynq-fpga.c
+++ b/drivers/fpga/zynq-fpga.c
@@ -28,6 +28,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

@@ -184,8 +185,8 @@ static int zynq_fpga_ops_write_init(struct fpga_manager 
*mgr, u32 flags,

priv = mgr->priv;

-   err = clk_enable(priv->clk);
-   if (err)
+   err = pm_runtime_get_sync(priv->dev);
+   if (err < 0)
return err;

/* don't globally reset PL if we're doing partial reconfig */
@@ -271,12 +272,12 @@ static int zynq_fpga_ops_write_init(struct fpga_manager 
*mgr, u32 flags,
ctrl = zynq_fpga_read(priv, MCTRL_OFFSET);
zynq_fpga_write(priv, MCTRL_OFFSET, (~MCTRL_PCAP_LPBK_MASK & ctrl));

-   clk_disable(priv->clk);
+   pm_runtime_put(priv->dev);

return 0;

  out_err:
-   clk_disable(priv->clk);
+   pm_runtime_put(priv->dev);

return err;
  }
@@ -301,9 +302,8 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,

memcpy(kbuf, buf, count);

-   /* enable clock */
-   err = clk_enable(priv->clk);
-   if (err)
+   err = pm_runtime_get_sync(priv->dev);
+   if (err < 0)
goto out_free;

zynq_fpga_write(priv, INT_STS_OFFSET, IXR_ALL_MASK);
@@ -335,7 +335,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
err = -EFAULT;
}

-   clk_disable(priv->clk);
+   pm_runtime_put(priv->dev);

  out_free:
dma_free_coherent(priv->dev, in_count, kbuf, dma_addr);
@@ -349,8 +349,8 @@ static int zynq_fpga_ops_write_complete(struct fpga_manager 
*mgr, u32 flags)
int err;
u32 intr_status;

-   err = clk_enable(priv->clk);
-   if (err)
+   err = pm_runtime_get_sync(priv->dev);
+   if (err < 0)
return err;

err = zynq_fpga_poll_timeout(priv, INT_STS_OFFSET, intr_status,
@@ -358,7 +358,7 @@ static int zynq_fpga_ops_write_complete(struct fpga_manager 
*mgr, u32 flags)
 INIT_POLL_DELAY,
 INIT_POLL_TIMEOUT);

-   clk_disable(priv->clk);
+   pm_runtime_put(priv->dev);

if (err)
return err;
@@ -385,12 +385,12 @@ static enum fpga_mgr_states zynq_fpga_ops_state(struct 
fpga_manager *mgr)

priv = mgr->priv;

-   err = clk_enable(priv->clk);
-   if (err)
+   err = pm_runtime_get_sync(priv->dev);
+   if (err < 0)
return FPGA_MGR_STATE_UNKNOWN;

intr_status = zynq_fpga_read(priv, INT_STS_OFFSET);
-   clk_disable(priv->clk);
+   pm_runtime_put(priv->dev);

if (intr_status & IXR_PCFG_DONE_MASK)
return FPGA_MGR_STATE_OPERATING;
@@ -457,19 +457,26 @@ static int zynq_fpga_probe(struct platform_device *pdev)
return err;
}

+   pm_runtime_get_noresume(>dev);
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
+
/* unlock the device */
zynq_fpga_write(priv, UNLOCK_OFFSET, UNLOCK_MASK);

-   clk_disable(priv->clk);

err = fpga_mgr_register(dev, "Xilinx Zynq FPGA Manager",
_fpga_ops, priv);
if (err) {
dev_err(dev, "unable to register FPGA manager");
-   clk_unprepare(priv->clk);
+   clk_disable_unprepare(priv->clk);
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_disable(>dev);
return err;
}

+   pm_runtime_put(>dev);
+
return 0;
  }

@@ -483,11 +490,45 @@ static int zynq_fpga_remove(struct platform_device *pdev)

fpga_mgr_unregister(>dev);

-   clk_unprepare(priv->clk);
+   pm_runtime_get_sync(>dev);
+   clk_disable_unprepare(priv->clk);
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_disable(>dev);

return 0;
  }

+static int __maybe_unused zynq_fpga_runtime_suspend(struct device *dev)
+{
+   struct zynq_fpga_priv *priv;
+   struct fpga_manager *mgr;
+
+   mgr = dev_get_drvdata(dev);
+   priv = mgr->priv;
+
+   clk_disable(priv->clk);


From what I understand, this call is done in a sleepable context, so you can 
use clk_disable_unprepare here (and its counterpart in resume). And remove the 
prepare at probe time and unprepare at removal.


Not all clocks can implement atomic 

Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

[Finn Thain]

On Fri, 20 Nov 2015, I wrote:

> On Thu, 19 Nov 2015, Ondrej Zary wrote:
> 
> > [  240.108501] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> > this message.
> > [  240.108597] modprobeD 001a 0  1957   1950 0x
> > [  240.108790]  ce0fad00 0086 53881781 001a c1525f88 4edbe39c 
> > 001a 04ac33e5
> > [  240.109246]   ccd54000   d204b280 c139c504 
> >  c104416d
> > [  240.109699]   ce0fad00 c1054a45 c151fd8c c151fd8c d204b280 
> >  ccd6d100
> > [  240.110156] Call Trace:
> > [  240.110295]  [] ? schedule+0x5b/0x67
> > [  240.110430]  [] ? async_synchronize_cookie_domain+0x73/0x9f
> > [  240.110569]  [] ? abort_exclusive_wait+0x6e/0x6e
> > [  240.110699]  [] ? do_init_module+0xa4/0x1a3
> > [  240.110824]  [] ? load_module+0x14de/0x18ca
> > [  240.110948]  [] ? SyS_finit_module+0x47/0x56
> > [  240.111068]  [] ? sysenter_do_call+0x12/0x12
> 
> Not sure what module was being probed here. I presume it was g_NCR5380 
> or g_NCR5380_mmio. Neither of these calls 'scsi_scan_host'. I'm not sure 
> what the implications are (?)

Nevermind. The call is in scsi_module.c.

-- 
--
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] mm: hugetlb: fix hugepage memory leak caused by wrong reserve count

[Naoya Horiguchi]

When dequeue_huge_page_vma() in alloc_huge_page() fails, we fall back to
alloc_buddy_huge_page() to directly create a hugepage from the buddy allocator.
In that case, however, if alloc_buddy_huge_page() succeeds we don't decrement
h->resv_huge_pages, which means that successful hugetlb_fault() returns without
releasing the reserve count. As a result, subsequent hugetlb_fault() might fail
despite that there are still free hugepages.

This patch simply adds decrementing code on that code path.

I reproduced this problem when testing v4.3 kernel in the following situation:
- the test machine/VM is a NUMA system,
- hugepage overcommiting is enabled,
- most of hugepages are allocated and there's only one free hugepage
  which is on node 0 (for example),
- another program, which calls set_mempolicy(MPOL_BIND) to bind itself to
  node 1, tries to allocate a hugepage,
- the allocation should fail but the reserve count is still hold.

Signed-off-by: Naoya Horiguchi 
Cc:  [3.16+]
---
- the reason why I set stable target to "3.16+" is that this patch can be
  applied easily/automatically on these versions. But this bug seems to be
  old one, so if you are interested in backporting to older kernels,
  please let me know.
---
 mm/hugetlb.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git v4.3/mm/hugetlb.c v4.3_patched/mm/hugetlb.c
index 9cc7734..77c518c 100644
--- v4.3/mm/hugetlb.c
+++ v4.3_patched/mm/hugetlb.c
@@ -1790,7 +1790,10 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
page = alloc_buddy_huge_page(h, NUMA_NO_NODE);
if (!page)
goto out_uncharge_cgroup;
-
+   if (!avoid_reserve && vma_has_reserves(vma, gbl_chg)) {
+   SetPagePrivate(page);
+   h->resv_huge_pages--;
+   }
spin_lock(_lock);
list_move(>lru, >hugepage_activelist);
/* Fall through */
-- 
1.7.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: x86/microcode update on systems without INITRD

[Markus Trippelsdorf]

On 2015.11.19 at 23:58 +0100, Borislav Petkov wrote:
> On Thu, Nov 19, 2015 at 10:55:43PM +0100, Borislav Petkov wrote:
> > On Thu, Nov 19, 2015 at 10:43:01PM +0100, Markus Trippelsdorf wrote:
> > > It looks like the ability to update x86/microcode without using an
> > > initrd was removed this merge window.
> > 
> > Whoops, that shouldnt've happened. Will debug it tomorrow and provide a
> > fix.
> 
> Anyway, the hunk below seems to work in my guest here, I'll run it
> on the rest of the boxes tomorrow. In case you want to give it a try
> before:

Your patch works fine. Thanks.
But of course it needs this additional patch, otherwise the microcode
loader wouldn't build at all:

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index db3622f22b61..52c6964e24bd 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1126,7 +1126,6 @@ config MICROCODE
bool "CPU microcode loading support"
default y
depends on CPU_SUP_AMD || CPU_SUP_INTEL
-   depends on BLK_DEV_INITRD
select FW_LOADER
---help---
 

-- 
Markus
--
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/04] pinctrl: sh-pfc: r8a7794: DU support

[Magnus Damm]

Hi Laurent,

On Fri, Nov 20, 2015 at 11:46 AM, Laurent Pinchart
 wrote:
> Hi Magnus,
>
> Thank you for the patch.
>
> On Tuesday 17 November 2015 12:18:32 Magnus Damm wrote:
>> pinctrl: sh-pfc: r8a7794: DU support
>>
>> [PATCH 01/04] pinctrl: sh-pfc: r8a7794: Add DU pin groups
>> [PATCH 02/04] pinctrl: sh-pfc: r8a7794: Separate DU CDE and DISP
>> [PATCH 03/04] pinctrl: sh-pfc: r8a7794: Add missing dot clock signals
>> [PATCH 04/04] pinctrl: sh-pfc: r8a7794: Break out ODDF from sync
>>
>> These patches take the r8a7794 PFC DU support code from the BSP
>> and reworks it to fit the r8a7794 ALT board. Tested with the ALT
>> VGA port - by default PFC is not used however enabling PFC using
>> an incremental (yet to be posted) patch works well.
>>
>> It is worth noting that patch 2-4 modifies the pin groups. This
>> means that the upstream DT ABI for PFC DU will differ compared
>> to the unreviewed BSP code.
>>
>> In general it is not considered good practice to change the pin
>> groups and break compatibility since they are part of the DT ABI.
>>
>> For this particular case upstream never have had PFC DU support
>> for r8a7794, so treating the BSP bindings as experimental and
>> migrate away seems reasonable.
>
> If we start considering DT bindings that never went upstream as stable we'll
> have a big problem. I mean even bigger than the upstream DT bindings stability
> problem :-)

I'm not saying that local DT hacks should be considered stable, more
that it as usual makes sense to follow upstream first with proper DT
review process early on.

>> Signed-off-by: Magnus Damm 
>
> Wouldn't it make sense to merge the 4 patches together ?

Yeah, I guess so. My feeling is also that it would be good to verify
HDMI on ALT before commiting to DT bindings. Right now only one DU
channel is tested.

Cheers,

/ magnus
--
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] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Tian, Kevin]

> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, November 20, 2015 4:03 AM
> 
> > >
> > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > userspace, and thus to QEMU, using the VFIO API.  For instance, vfio
> > > supports modular bus drivers and IOMMU drivers.  An intel-vfio-gvt-d
> > > module (or extension of i915) can register as a vfio bus driver, create
> > > a struct device per vGPU, create an IOMMU group for that device, and
> > > register that device with the vfio-core.  Since we don't rely on the
> > > system IOMMU for GVT-d vGPU assignment, another vGPU vendor driver (or
> > > extension of the same module) can register a "type1" compliant IOMMU
> > > driver into vfio-core.  From the perspective of QEMU then, all of the
> > > existing vfio-pci code is re-used, QEMU remains largely unaware of any
> > > specifics of the vGPU being assigned, and the only necessary change so
> > > far is how QEMU traverses sysfs to find the device and thus the IOMMU
> > > group leading to the vfio group.
> >
> > GVT-g requires to pin guest memory and query GPA->HPA information,
> > upon which shadow GTTs will be updated accordingly from (GMA->GPA)
> > to (GMA->HPA). So yes, here a dummy or simple "type1" compliant IOMMU
> > can be introduced just for this requirement.
> >
> > However there's one tricky point which I'm not sure whether overall
> > VFIO concept will be violated. GVT-g doesn't require system IOMMU
> > to function, however host system may enable system IOMMU just for
> > hardening purpose. This means two-level translations existing (GMA->
> > IOVA->HPA), so the dummy IOMMU driver has to request system IOMMU
> > driver to allocate IOVA for VMs and then setup IOVA->HPA mapping
> > in IOMMU page table. In this case, multiple VM's translations are
> > multiplexed in one IOMMU page table.
> >
> > We might need create some group/sub-group or parent/child concepts
> > among those IOMMUs for thorough permission control.
> 
> My thought here is that this is all abstracted through the vGPU IOMMU
> and device vfio backends.  It's the GPU driver itself, or some vfio
> extension of that driver, mediating access to the device and deciding
> when to configure GPU MMU mappings.  That driver has access to the GPA
> to HVA translations thanks to the type1 complaint IOMMU it implements
> and can pin pages as needed to create GPA to HPA mappings.  That should
> give it all the pieces it needs to fully setup mappings for the vGPU.
> Whether or not there's a system IOMMU is simply an exercise for that
> driver.  It needs to do a DMA mapping operation through the system IOMMU
> the same for a vGPU as if it was doing it for itself, because they are
> in fact one in the same.  The GMA to IOVA mapping seems like an internal
> detail.  I assume the IOVA is some sort of GPA, and the GMA is managed
> through mediation of the device.

Sorry I'm not familiar with VFIO internal. My original worry is that system 
IOMMU for GPU may be already claimed by another vfio driver (e.g. host kernel
wants to harden gfx driver from rest sub-systems, regardless of whether vGPU 
is created or not). In that case vGPU IOMMU driver shouldn't manage system
IOMMU directly.

btw, curious today how VFIO coordinates with system IOMMU driver regarding
to whether a IOMMU is used to control device assignment, or used for kernel 
hardening. Somehow two are conflicting since different address spaces are
concerned (GPA vs. IOVA)...

> 
> 
> > > There are a few areas where we know we'll need to extend the VFIO API to
> > > make this work, but it seems like they can all be done generically.  One
> > > is that PCI BARs are described through the VFIO API as regions and each
> > > region has a single flag describing whether mmap (ie. direct mapping) of
> > > that region is possible.  We expect that vGPUs likely need finer
> > > granularity, enabling some areas within a BAR to be trapped and fowarded
> > > as a read or write access for the vGPU-vfio-device module to emulate,
> > > while other regions, like framebuffers or texture regions, are directly
> > > mapped.  I have prototype code to enable this already.
> >
> > Yes in GVT-g one BAR resource might be partitioned among multiple vGPUs.
> > If VFIO can support such partial resource assignment, it'd be great. Similar
> > parent/child concept might also be required here, so any resource enumerated
> > on a vGPU shouldn't break limitations enforced on the physical device.
> 
> To be clear, I'm talking about partitioning of the BAR exposed to the
> guest.  Partitioning of the physical BAR would be managed by the vGPU
> vfio device driver.  For instance when the guest mmap's a section of the
> virtual BAR, the vGPU device driver would map that to a portion of the
> physical device BAR.
> 
> > One unique requirement for GVT-g here, though, is that vGPU device model
> > need to know guest BAR configuration for proper emulation (e.g. register
> > IO emulation handler to KVM). 

Re: [PATCH v3 00/12] Add mipi dsi support for rk3288

[Chris Zhong]

Hi Emil

On 11/19/2015 10:41 PM, Emil Velikov wrote:

On 19 November 2015 at 03:35, Chris Zhong  wrote:

The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
IP. This series adds support for a Synopsys DesignWare MIPI DSI host
controller DRM bridge driver and a rockchip MIPI DSI specific DRM
driver.

This series also includes a DRM panel driver for BOE TV080WUM-NL0 panel.
This panel only use the MIPI DSI video mode.

The MIPI DSI feature is tested on rk3288 evb board, backport them to
chrome os kernel v3.14, and it can display normally.

This patchset is base on the patchset from ying@freescale.com.



Changes in v3:
move the dw_mipi_dsi.txt to Documentation/devicetree/bindings/display/bridge
move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/
move boe,tv080wum-nl0.txt to bindings/display/panel/

Changes in v2:
add the mipi clk id in a single patch
As Thierry.Reding comment, add a documentation for this panel.

Chris Zhong (10):
   clk: rockchip: add id for mipidsi sclk on rk3288
   clk: rockchip: add mipidsi clocks on rk3288
   drm/rockchip: return a true clock rate to adjusted_mode
   drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver

Did you actually rewrite the patch from Liu Ying ?

I modify the dw_mipi_dsi.c based on the patch from Liu Ying.

Out of curiosity what was the obstacle of this work getting merged ?

There are different version dw controller, and it is too hard to merge them,
since most registers are different.



   drm: rockchip: Support Synopsys DesignWare MIPI DSI host controller
   Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
   ARM: dts: rockchip: add rk3288 mipi_dsi nodes
   drm/panel: simple: Add support for BOE TV080WUM-NL0
   drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree
 binding

As the DT people will tell you - there is no BOE vendor in
bindings/vendor-prefixes.txt.

Yes, I have post a verdor patch in v2 series,

Maybe I should add it back to series with

Acked-by: Rob Herring




   ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb

Liu Ying (2):
   drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
   Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM
 bridge driver


>From the above 12 patches only ~6 reached this mailing list is that
intentional ? Previously I've seen people CC dri-devel for their
panel/bridge DT patches.
I use the patman to post the series, forgot to add you and Thierry to 
the to-list.

I will fix in next version series. Thanks for your reply.



Regards,
Emil






--
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 0/3] virtio DMA API core stuff

[Michael S. Tsirkin]

On Thu, Nov 19, 2015 at 01:59:05PM -0800, Andy Lutomirski wrote:
> On Nov 19, 2015 5:45 AM, "Michael S. Tsirkin"  wrote:
> >
> > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote:
> > > This switches virtio to use the DMA API unconditionally.  I'm sure
> > > it breaks things, but it seems to work on x86 using virtio-pci, with
> > > and without Xen, and using both the modern 1.0 variant and the
> > > legacy variant.
> >
> > So thinking hard about it, I don't see any real drawbacks to making this
> > conditional on a new feature bit, that Xen can then set..
> 
> Can you elaborate?  If I run QEMU, hosting Xen, hosting Linux, and the
> virtio device is provided by QEMU, then how does Xen set the bit?

You would run QEMU with the appropriate flag. E.g.
-global virtio-pci,use_platform_dma=on

> Similarly, how would Xen set the bit for a real physical device?
> 
> 
> --Andy

There's no need to set bits for physical devices I think: from security
point of view, using them from a VM isn't very different from using them
from host.



-- 
MST
--
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 3/3] ASoC: fsl_asrc: spba clock is needed by asrc device

[Shengjiu Wang]

ASRC need to enable the spba clock, when sdma is using share peripheral
script. In this case, there is two spba master port is used, if don't
enable the clock, the spba bus will have arbitration issue, which may
cause read/write wrong data from/to ASRC registers

Signed-off-by: Shengjiu Wang 
---
 Documentation/devicetree/bindings/sound/fsl,asrc.txt |  2 ++
 sound/soc/fsl/fsl_asrc.c | 10 ++
 sound/soc/fsl/fsl_asrc.h |  1 +
 3 files changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt 
b/Documentation/devicetree/bindings/sound/fsl,asrc.txt
index b93362a..d83 100644
--- a/Documentation/devicetree/bindings/sound/fsl,asrc.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt
@@ -25,6 +25,8 @@ Required properties:
"mem" Peripheral access clock to access registers.
"ipg" Peripheral clock to driver module.
"asrck_<0-f>" Clock sources for input and output clock.
+   "spba"The spba clock is needed when two spba master port
+ is used.
 
- big-endian: If this property is absent, the little endian 
mode
  will be in use as default. Otherwise, the big endian
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 9f087d4..800828e 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -859,6 +859,10 @@ static int fsl_asrc_probe(struct platform_device *pdev)
return PTR_ERR(asrc_priv->ipg_clk);
}
 
+   asrc_priv->spba_clk = devm_clk_get(>dev, "spba");
+   if (IS_ERR(asrc_priv->spba_clk))
+   dev_warn(>dev, "failed to get spba clock\n");
+
for (i = 0; i < ASRC_CLK_MAX_NUM; i++) {
sprintf(tmp, "asrck_%x", i);
asrc_priv->asrck_clk[i] = devm_clk_get(>dev, tmp);
@@ -939,6 +943,9 @@ static int fsl_asrc_runtime_resume(struct device *dev)
ret = clk_prepare_enable(asrc_priv->ipg_clk);
if (ret)
goto disable_mem_clk;
+   ret = clk_prepare_enable(asrc_priv->spba_clk);
+   if (ret)
+   goto disable_ipg_clk;
for (i = 0; i < ASRC_CLK_MAX_NUM; i++) {
ret = clk_prepare_enable(asrc_priv->asrck_clk[i]);
if (ret)
@@ -950,6 +957,8 @@ static int fsl_asrc_runtime_resume(struct device *dev)
 disable_asrck_clk:
for (i--; i >= 0; i--)
clk_disable_unprepare(asrc_priv->asrck_clk[i]);
+   clk_disable_unprepare(asrc_priv->spba_clk);
+disable_ipg_clk:
clk_disable_unprepare(asrc_priv->ipg_clk);
 disable_mem_clk:
clk_disable_unprepare(asrc_priv->mem_clk);
@@ -963,6 +972,7 @@ static int fsl_asrc_runtime_suspend(struct device *dev)
 
for (i = 0; i < ASRC_CLK_MAX_NUM; i++)
clk_disable_unprepare(asrc_priv->asrck_clk[i]);
+   clk_disable_unprepare(asrc_priv->spba_clk);
clk_disable_unprepare(asrc_priv->ipg_clk);
clk_disable_unprepare(asrc_priv->mem_clk);
 
diff --git a/sound/soc/fsl/fsl_asrc.h b/sound/soc/fsl/fsl_asrc.h
index 4aed63c..889080e 100644
--- a/sound/soc/fsl/fsl_asrc.h
+++ b/sound/soc/fsl/fsl_asrc.h
@@ -442,6 +442,7 @@ struct fsl_asrc {
unsigned long paddr;
struct clk *mem_clk;
struct clk *ipg_clk;
+   struct clk *spba_clk;
struct clk *asrck_clk[ASRC_CLK_MAX_NUM];
spinlock_t lock;
 
-- 
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 V2 2/3] ASoC: fsl_spdif: spba clk is needed by spdif device

[Shengjiu Wang]

SPDIF need to enable the spba clock, when sdma is using share peripheral
script. In this case, there is two spba master port is used, if don't
enable the clock, the spba bus will have arbitration issue, which may
cause read/write wrong data from/to SPDIF registers.

Signed-off-by: Shengjiu Wang 
---
 Documentation/devicetree/bindings/sound/fsl,spdif.txt |  2 ++
 sound/soc/fsl/fsl_spdif.c | 14 ++
 2 files changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt 
b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
index b5ee32e..7bcd9d0 100644
--- a/Documentation/devicetree/bindings/sound/fsl,spdif.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -27,6 +27,8 @@ Required properties:
  Transceiver Clock Diagram" of SoC reference manual.
  It can also be referred to TxClk_Source bit of
  register SPDIF_STC.
+   "spba"The spba clock is needed when two spba master port
+ is used.
 
- big-endian: If this property is absent, the native endian 
mode
  will be in use as default, or the big endian mode
diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 28a8823..d4b0ba3 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -106,6 +106,7 @@ struct fsl_spdif_priv {
struct clk *rxclk;
struct clk *coreclk;
struct clk *sysclk;
+   struct clk *spbaclk;
struct snd_dmaengine_dai_dma_data dma_params_tx;
struct snd_dmaengine_dai_dma_data dma_params_rx;
/* regcache for SRPC */
@@ -474,6 +475,12 @@ static int fsl_spdif_startup(struct snd_pcm_substream 
*substream,
return ret;
}
 
+   ret = clk_prepare_enable(spdif_priv->spbaclk);
+   if (ret) {
+   dev_err(>dev, "failed to enable spba clock\n");
+   goto err_spbaclk;
+   }
+
ret = spdif_softreset(spdif_priv);
if (ret) {
dev_err(>dev, "failed to soft reset\n");
@@ -515,6 +522,8 @@ disable_txclk:
for (i--; i >= 0; i--)
clk_disable_unprepare(spdif_priv->txclk[i]);
 err:
+   clk_disable_unprepare(spdif_priv->spbaclk);
+err_spbaclk:
clk_disable_unprepare(spdif_priv->coreclk);
 
return ret;
@@ -548,6 +557,7 @@ static void fsl_spdif_shutdown(struct snd_pcm_substream 
*substream,
spdif_intr_status_clear(spdif_priv);
regmap_update_bits(regmap, REG_SPDIF_SCR,
SCR_LOW_POWER, SCR_LOW_POWER);
+   clk_disable_unprepare(spdif_priv->spbaclk);
clk_disable_unprepare(spdif_priv->coreclk);
}
 }
@@ -1261,6 +1271,10 @@ static int fsl_spdif_probe(struct platform_device *pdev)
return PTR_ERR(spdif_priv->coreclk);
}
 
+   spdif_priv->spbaclk = devm_clk_get(>dev, "spba");
+   if (IS_ERR(spdif_priv->spbaclk))
+   dev_warn(>dev, "no spba clock in devicetree\n");
+
/* Select clock source for rx/tx clock */
spdif_priv->rxclk = devm_clk_get(>dev, "rxtx1");
if (IS_ERR(spdif_priv->rxclk)) {
-- 
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 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

[Joonsoo Kim]

Ccing Steven.

Hello,

On Wed, Nov 18, 2015 at 04:34:30PM +0100, Vlastimil Babka wrote:
> On 11/09/2015 08:23 AM, Joonsoo Kim wrote:
> > CMA allocation should be guaranteed to succeed by definition, but,
> > unfortunately, it would be failed sometimes. It is hard to track down
> > the problem, because it is related to page reference manipulation and
> > we don't have any facility to analyze it.
> 
> Reminds me of the PeterZ's VM_PINNED patchset. What happened to it?
> https://lwn.net/Articles/600502/
> 
> > This patch adds tracepoints to track down page reference manipulation.
> > With it, we can find exact reason of failure and can fix the problem.
> > Following is an example of tracepoint output.
> > 
> > <...>-9018  [004]92.678375: page_ref_set: pfn=0x17ac9 flags=0x0 
> > count=1 mapcount=0 mapping=(nil) mt=4 val=1
> > <...>-9018  [004]92.678378: kernel_stack:
> >  => get_page_from_freelist (81176659)
> >  => __alloc_pages_nodemask (81176d22)
> >  => alloc_pages_vma (811bf675)
> >  => handle_mm_fault (8119e693)
> >  => __do_page_fault (810631ea)
> >  => trace_do_page_fault (81063543)
> >  => do_async_page_fault (8105c40a)
> >  => async_page_fault (817581d8)
> > [snip]
> > <...>-9018  [004]92.678379: page_ref_mod: pfn=0x17ac9 
> > flags=0x40048 count=2 mapcount=1 mapping=0x880015a78dc1 mt=4 val=1
> > [snip]
> > ...
> > ...
> > <...>-9131  [001]93.174468: test_pages_isolated:  start_pfn=0x17800 
> > end_pfn=0x17c00 fin_pfn=0x17ac9 ret=fail
> > [snip]
> > <...>-9018  [004]93.174843: page_ref_mod_and_test: pfn=0x17ac9 
> > flags=0x40068 count=0 mapcount=0 mapping=0x880015a78dc1 mt=4 val=-1 
> > ret=1
> >  => release_pages (8117c9e4)
> >  => free_pages_and_swap_cache (811b0697)
> >  => tlb_flush_mmu_free (81199616)
> >  => tlb_finish_mmu (8119a62c)
> >  => exit_mmap (811a53f7)
> >  => mmput (81073f47)
> >  => do_exit (810794e9)
> >  => do_group_exit (81079def)
> >  => SyS_exit_group (81079e74)
> >  => entry_SYSCALL_64_fastpath (817560b6)
> > 
> > This output shows that problem comes from exit path. In exit path,
> > to improve performance, pages are not freed immediately. They are gathered
> > and processed by batch. During this process, migration cannot be possible
> > and CMA allocation is failed. This problem is hard to find without this
> > page reference tracepoint facility.
> 
> Yeah but when you realized it was this problem, what was the fix? Probably not
> remove batching from exit path? Shouldn't CMA in this case just try waiting 
> for
> the pins to go away, which would eventually happen? And for long-term pins,
> VM_PINNED would make sure the pages are migrated away from CMA pageblocks 
> first?
> 
> So I'm worried that this is quite nontrivial change for a very specific 
> usecase.

Minchan already answered it. Thanks, Minchan.
This also can be used for memory-offlining and compaction.

> > Enabling this feature bloat kernel text 20 KB in my configuration.
> 
> It's not just that, see below.
> 
> [...]
> 
> 
> >  static inline int page_ref_freeze(struct page *page, int count)
> >  {
> > -   return likely(atomic_cmpxchg(>_count, count, 0) == count);
> > +   int ret = likely(atomic_cmpxchg(>_count, count, 0) == count);
> 
> The "likely" mean makes no sense anymore, doe it?

I don't know how compiler uses this hint exactly but it will have same
effect as before. Why do you think it makes no sense now?

> 
> > diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
> > index 957d3da..71d2399 100644
> > --- a/mm/Kconfig.debug
> > +++ b/mm/Kconfig.debug
> > @@ -28,3 +28,7 @@ config DEBUG_PAGEALLOC
> >  
> >  config PAGE_POISONING
> > bool
> > +
> > +config DEBUG_PAGE_REF
> > +   bool "Enable tracepoint to track down page reference manipulation"
> 
> So you should probably state the costs. Which is the extra memory, and also 
> that
> all the page ref manipulations are now turned to function calls, even if the
> tracepoints are disabled.

Yes, will do.

> Patch 1 didn't change that many callsites, so maybe it
> would be feasible to have the tracepoints inline, where being disabled has
> near-zero overhead?

Hmm...Although I changed just one get_page() in previous patch, it would
be used in many places. So, it's not feasible to inline tracepoints to
each callsites directly.

In fact, I tried to inline tracepoint into wrapper function directly,
but, it fails due to (maybe) header file dependency.

Steven, is it possible to add tracepoint to inlined fucntion such as
get_page() in include/linux/mm.h?

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/

[PATCH] nvme: lightnvm: use nvme admin queue

[Wenwei Tao]

According to Open-ChannelSSDInterfaceSpecification 0.1,
NVMe-NVM admin commands use vendor specific admin opcodes
of NVMe, so use the NVMe admin queue to dispatch these
commands

Signed-off-by: Wenwei Tao 
---
 drivers/nvme/host/lightnvm.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index e0b7b95..7d1981d 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -244,6 +244,7 @@ static int init_grps(struct nvm_id *nvm_id, struct 
nvme_nvm_id *nvme_nvm_id)
 static int nvme_nvm_identity(struct request_queue *q, struct nvm_id *nvm_id)
 {
struct nvme_ns *ns = q->queuedata;
+   struct nvme_dev *dev = ns->dev;
struct nvme_nvm_id *nvme_nvm_id;
struct nvme_nvm_command c = {};
int ret;
@@ -256,8 +257,8 @@ static int nvme_nvm_identity(struct request_queue *q, 
struct nvm_id *nvm_id)
if (!nvme_nvm_id)
return -ENOMEM;
 
-   ret = nvme_submit_sync_cmd(q, (struct nvme_command *), nvme_nvm_id,
-   sizeof(struct nvme_nvm_id));
+   ret = nvme_submit_sync_cmd(dev->admin_q, (struct nvme_command *),
+   nvme_nvm_id, sizeof(struct nvme_nvm_id));
if (ret) {
ret = -EIO;
goto out;
@@ -299,8 +300,8 @@ static int nvme_nvm_get_l2p_tbl(struct request_queue *q, 
u64 slba, u32 nlb,
c.l2p.slba = cpu_to_le64(cmd_slba);
c.l2p.nlb = cpu_to_le32(cmd_nlb);
 
-   ret = nvme_submit_sync_cmd(q, (struct nvme_command *),
-   entries, len);
+   ret = nvme_submit_sync_cmd(dev->admin_q,
+   (struct nvme_command *), entries, len);
if (ret) {
dev_err(dev->dev, "L2P table transfer failed (%d)\n",
ret);
@@ -343,8 +344,8 @@ static int nvme_nvm_get_bb_tbl(struct request_queue *q, int 
lunid,
 
bitmap_zero(bb_bitmap, nr_blocks);
 
-   ret = nvme_submit_sync_cmd(q, (struct nvme_command *), bb_bitmap,
-   bb_bitmap_size);
+   ret = nvme_submit_sync_cmd(dev->admin_q, (struct nvme_command *),
+   bb_bitmap, bb_bitmap_size);
if (ret) {
dev_err(dev->dev, "get bad block table failed (%d)\n", ret);
ret = -EIO;
-- 
1.8.3.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 v4 7/7] mtd: spi-nor: add read loop

[Heiner Kallweit]

Am 20.11.2015 um 00:39 schrieb Brian Norris:
> + Heiner
> 
> On Fri, Aug 14, 2015 at 09:23:09AM -, Michal Suchanek wrote:
>> mtdblock and ubi do not handle the situation when read returns less data
>> than requested. Loop in spi-nor until buffer is filled or an error is
>> returned.
> 
> I'm slightly torn on this patch. I believe this is inspired by issues in
> the SPI layer. But I believe there is some agreement from the SPI layer
> that protocol drivers (such as m25p80.c/spi-nor.c) should not have to
> worry about spi_messages getting truncated [1]. Heiner is looking at
> that.
> 
> But on the other hand, it's possible that some non-SPI driver would have
> similar limitations, and so spi-nor.c should be handling the issue.
> 
>> Signed-off-by: Michal Suchanek 
>> ---
>>  drivers/mtd/spi-nor/spi-nor.c | 20 ++--
>>  1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index e0ae9cf..246fac7 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -738,14 +738,22 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t 
>> from, size_t len,
>>  if (ret)
>>  return ret;
>>  
>> -ret = nor->read(nor, from, len, buf);
>> +while (len) {
>> +ret = nor->read(nor, from, len, buf);
>> +if (ret <= 0)
>> +goto read_err;
> 
> Do we really want to exit silently when ret==0, but len!=0?
> 
>> +
>> +BUG_ON(ret > len);
> 
> Maybe the condition here should be 'ret > len || len == 0', since this
> shouldn't happen.
> 
> Also, please don't use BUG_ON(). Even though this is really unexpected,
> we don't need to crash the system. Perhaps:
> 
>   if (WARN_ON(ret > len || ret == 0)) {
>   ret = -EIO;
>   goto read_err;
>   }
> 
>> +*retlen += ret;
>> +buf += ret;
>> +from += ret;
>> +len -= ret;
>> +}
>> +ret = 0;
>>  
>> +read_err:
>>  spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_READ);
>> -if (ret < 0)
>> -return ret;
>> -
>> -*retlen += ret;
>> -return 0;
>> +return ret;
>>  }
>>  
>>  static int sst_write(struct mtd_info *mtd, loff_t to, size_t len,
> 
> Brian
> 
> [1] http://www.spinics.net/lists/linux-spi/msg05877.html
> "RfC: Handle SPI controller limitations like maximum message length"
> 
> I'm honestly not really sure what the conclusion from that thread
> is, so far. It seems like the SPI master "should" be exposing its
> max length to the SPI core, but it's unclear whether that would get
> propagated as a short write/read (i.e., shorter-than-expected
> spi_message::actual_length), or whether the SPI core should be
> somehow splitting up the messages into manageable chunks for us. I'm
> not even sure if the latter is legal for things like
> read-from-flash; might this cause the chip select to get toggled,
> potentially disrupting the operation?

That's exactly my issue with Freescale ESPI.
You provide a message length (up to 64K) to the chip and it sets / resets
CS internally. Resuming a short read requires to set the (SPI NOR)
start address for the next read properly.
And this can be done by the protocol driver only.
Currently the fsl-espi controller driver includes some ugly
(protocol driver) logic to deal with this.
One consequence is that this controller driver can be used with
SPI NOR devices only.

At a first glance I see two options:

1. The controller driver returns an error like EMSGSIZE and the number
   of read bytes. Then the protocol driver can loop and assemble the chunks.

2. The SPI master exposes the SPI message length constraint and the
   protocol driver can proactively deal with this limitation.

I have a little headache with option 1 because I'm not sure that we can
in general rely on the number of read bytes if an error is returned.
Some controller driver might return whatever value assuming that the
caller ignores it anyway if an error is returned.

Options 2 I like better as it doesn't require the controller driver
to handle an error situation like a short read in a specific way.

And it seems like Mark could be fine with an additional member of
spi_master like size_t max_msg_size.
The idea of a struct encapsulating all constraints he didn't like too much.

> 
> Anyway, in the former case, we need something like your patch. But
> in the latter case, we actually don't need anything, other than
> maybe an assertion that ret == len.
> 

--
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 V3] iommu: arm-smmu: correct group reference count

[Peng Fan]

Hi Will,

On Tue, Nov 17, 2015 at 04:17:46PM +, Will Deacon wrote:
>On Tue, Nov 10, 2015 at 09:56:26AM +0800, Peng Fan wrote:
>> The basic flow for add a device:
>>  arm_smmu_add_device
>> |->iommu_group_get_for_dev
>> |->iommu_group_get
>>  return group;  (1)
>> |->ops->device_group : Init/increase reference count to/by 1.
>> |->iommu_group_add_device : Increase reference count by 1.
>>   return group   (2)
>> |->return 0;
>> 
>> Since we are adding one device, the flow is (2) and the group reference
>> count will be increased by 2. So, we need to add iommu_group_put at the
>> end of arm_smmu_add_device to decrease the count by 1.
>> 
>> Signed-off-by: Peng Fan 
>> Cc: Will Deacon 
>> ---
>>  drivers/iommu/arm-smmu-v3.c | 7 ++-
>>  drivers/iommu/arm-smmu.c| 2 ++
>>  2 files changed, 8 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 4e5118a..ac333ee 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -1825,8 +1825,10 @@ static int arm_smmu_add_device(struct device *dev)
>>  pci_for_each_dma_alias(pdev, __arm_smmu_get_pci_sid, );
>>  for (i = 0; i < smmu_group->num_sids; ++i) {
>>  /* If we already know about this SID, then we're done */
>> -if (smmu_group->sids[i] == sid)
>> +if (smmu_group->sids[i] == sid) {
>> +iommu_group_put(group);
>>  return 0;
>> +}
>>  }
>>  
>>  /* Check the SID is in range of the SMMU and our stream table */
>> @@ -1855,6 +1857,9 @@ static int arm_smmu_add_device(struct device *dev)
>>  /* Add the new SID */
>>  sids[smmu_group->num_sids - 1] = sid;
>>  smmu_group->sids = sids;
>> +
>> +iommu_group_put(group);
>> +
>>  return 0;
>
>I still think this is wrong for the failure path. If we fail during
>add_device, then we want to put things back like they were, which is
>what the out_put_group label is for. That means dropping the refcount
>for the group *and* the refcount for the device. The nasty part is that
>we don't know if we were responsible for adding the device to the group,
>but it looks like we already assume that in ->remove_device.

Thanks for your comments. I missed to handle the failure path.

>
>The best bet is probably something like the diff below.

Yeah.

I'll send a new version patch with your diff.

Thanks,
Peng.

>
>Thoughts?
>
>Will
>
>--->8
>
>diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>index 86480480895d..db03c2fb1319 100644
>--- a/drivers/iommu/arm-smmu-v3.c
>+++ b/drivers/iommu/arm-smmu-v3.c
>@@ -1804,13 +1804,13 @@ static int arm_smmu_add_device(struct device *dev)
>   smmu = arm_smmu_get_for_pci_dev(pdev);
>   if (!smmu) {
>   ret = -ENOENT;
>-  goto out_put_group;
>+  goto out_remove_dev;
>   }
> 
>   smmu_group = kzalloc(sizeof(*smmu_group), GFP_KERNEL);
>   if (!smmu_group) {
>   ret = -ENOMEM;
>-  goto out_put_group;
>+  goto out_remove_dev;
>   }
> 
>   smmu_group->ste.valid   = true;
>@@ -1826,20 +1826,20 @@ static int arm_smmu_add_device(struct device *dev)
>   for (i = 0; i < smmu_group->num_sids; ++i) {
>   /* If we already know about this SID, then we're done */
>   if (smmu_group->sids[i] == sid)
>-  return 0;
>+  goto out_put_group;
>   }
> 
>   /* Check the SID is in range of the SMMU and our stream table */
>   if (!arm_smmu_sid_in_range(smmu, sid)) {
>   ret = -ERANGE;
>-  goto out_put_group;
>+  goto out_remove_dev;
>   }
> 
>   /* Ensure l2 strtab is initialised */
>   if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
>   ret = arm_smmu_init_l2_strtab(smmu, sid);
>   if (ret)
>-  goto out_put_group;
>+  goto out_remove_dev;
>   }
> 
>   /* Resize the SID array for the group */
>@@ -1849,16 +1849,20 @@ static int arm_smmu_add_device(struct device *dev)
>   if (!sids) {
>   smmu_group->num_sids--;
>   ret = -ENOMEM;
>-  goto out_put_group;
>+  goto out_remove_dev;
>   }
> 
>   /* Add the new SID */
>   sids[smmu_group->num_sids - 1] = sid;
>   smmu_group->sids = sids;
>-  return 0;
> 
> out_put_group:
>   iommu_group_put(group);
>+  return 0;
>+
>+out_remove_dev:
>+  iommu_group_remove_device(dev);
>+  iommu_group_put(group);
>   return ret;
> }
> 
--
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  

Re: [PATCH 2/3] mm/page_isolation: add new tracepoint, test_pages_isolated

[Joonsoo Kim]

On Thu, Nov 19, 2015 at 03:34:11PM -0800, Andrew Morton wrote:
> On Fri, 13 Nov 2015 11:23:47 +0900 Joonsoo Kim  wrote:
> 
> > cma allocation should be guranteeded to succeed, but, sometimes,
> > it could be failed in current implementation. To track down
> > the problem, we need to know which page is problematic and
> > this new tracepoint will report it.
> 
> akpm3:/usr/src/25> size mm/page_isolation.o
>textdata bss dec hex filename
>2972 112109641801054 mm/page_isolation.o-before
>4608 570184070181b6a mm/page_isolation.o-after
> 
> This seems an excessive amount of bloat for one little tracepoint.  Is
> this expected and normal (and acceptable)?

Hello,

I checked bloat on other tracepoints and found that it's normal.
It takes 1KB more per tracepoint.

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/

[PATCH V2 1/3] ASoC: fsl_esai: spba clock is needed by esai device

[Shengjiu Wang]

ESAI need to enable the spba clock, when sdma is using share peripheral
script. In this case, there is two spba master port is used, if don't
enable the clock, the spba bus will have arbitration issue, which may
cause read/write wrong data from/to ESAI registers.

Signed-off-by: Shengjiu Wang 
---
 Documentation/devicetree/bindings/sound/fsl,esai.txt |  2 ++
 sound/soc/fsl/fsl_esai.c | 12 
 2 files changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt 
b/Documentation/devicetree/bindings/sound/fsl,esai.txt
index d3b6b5f..f1d5351 100644
--- a/Documentation/devicetree/bindings/sound/fsl,esai.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt
@@ -27,6 +27,8 @@ Required properties:
  derive HCK, SCK and FS.
"fsys"The system clock derived from ahb clock used to
  derive HCK, SCK and FS.
+   "spba"The spba clock is needed when two spba master port
+ is used.
 
   - fsl,fifo-depth : The number of elements in the transmit and receive
  FIFOs. This number is the maximum allowed value for
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 504e731..8749f53 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -54,6 +54,7 @@ struct fsl_esai {
struct clk *coreclk;
struct clk *extalclk;
struct clk *fsysclk;
+   struct clk *spbaclk;
u32 fifo_depth;
u32 slot_width;
u32 slots;
@@ -469,6 +470,9 @@ static int fsl_esai_startup(struct snd_pcm_substream 
*substream,
ret = clk_prepare_enable(esai_priv->coreclk);
if (ret)
return ret;
+   ret = clk_prepare_enable(esai_priv->spbaclk);
+   if (ret)
+   goto err_spbaclk;
if (!IS_ERR(esai_priv->extalclk)) {
ret = clk_prepare_enable(esai_priv->extalclk);
if (ret)
@@ -499,6 +503,8 @@ err_fsysclk:
if (!IS_ERR(esai_priv->extalclk))
clk_disable_unprepare(esai_priv->extalclk);
 err_extalck:
+   clk_disable_unprepare(esai_priv->spbaclk);
+err_spbaclk:
clk_disable_unprepare(esai_priv->coreclk);
 
return ret;
@@ -564,6 +570,7 @@ static void fsl_esai_shutdown(struct snd_pcm_substream 
*substream,
clk_disable_unprepare(esai_priv->fsysclk);
if (!IS_ERR(esai_priv->extalclk))
clk_disable_unprepare(esai_priv->extalclk);
+   clk_disable_unprepare(esai_priv->spbaclk);
clk_disable_unprepare(esai_priv->coreclk);
 }
 
@@ -819,6 +826,11 @@ static int fsl_esai_probe(struct platform_device *pdev)
dev_warn(>dev, "failed to get fsys clock: %ld\n",
PTR_ERR(esai_priv->fsysclk));
 
+   esai_priv->spbaclk = devm_clk_get(>dev, "spba");
+   if (IS_ERR(esai_priv->spbaclk))
+   dev_warn(>dev, "Cannot get spba clock: %ld\n",
+   PTR_ERR(esai_priv->spbaclk));
+
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(>dev, "no irq for node %s\n", pdev->name);
-- 
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 V2 0/3] add spba clock for fsl audio IP

[Shengjiu Wang]

add spba clock for fsl audio IP

Changes in v2
- spba is a optional clock, compatible with previous devicetree.
- change the name from "dma" to "spba"

Shengjiu Wang (3):
  ASoC: fsl_esai: spba clock is needed by esai device
  ASoC: fsl_spdif: spba clk is needed by spdif device
  ASoC: fsl_asrc: spba clock is needed by asrc device

 Documentation/devicetree/bindings/sound/fsl,asrc.txt  |  2 ++
 Documentation/devicetree/bindings/sound/fsl,esai.txt  |  2 ++
 Documentation/devicetree/bindings/sound/fsl,spdif.txt |  2 ++
 sound/soc/fsl/fsl_asrc.c  | 10 ++
 sound/soc/fsl/fsl_asrc.h  |  1 +
 sound/soc/fsl/fsl_esai.c  | 12 
 sound/soc/fsl/fsl_spdif.c | 14 ++
 7 files changed, 43 insertions(+)

-- 
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: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Tian, Kevin]

> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Thursday, November 19, 2015 4:41 PM
> 
>   Hi,
> 
> > > Another area of extension is how to expose a framebuffer to QEMU for
> > > seamless integration into a SPICE/VNC channel.  For this I believe we
> > > could use a new region, much like we've done to expose VGA access
> > > through a vfio device file descriptor.  An area within this new
> > > framebuffer region could be directly mappable in QEMU while a
> > > non-mappable page, at a standard location with standardized format,
> > > provides a description of framebuffer and potentially even a
> > > communication channel to synchronize framebuffer captures.  This would
> > > be new code for QEMU, but something we could share among all vGPU
> > > implementations.
> >
> > Now GVT-g already provides an interface to decode framebuffer information,
> > w/ an assumption that the framebuffer will be further composited into
> > OpenGL APIs.
> 
> Can I have a pointer to docs / code?
> 
> iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't
> explain how the guest framebuffer can be accessed then.

You can check "fb_decoder.h". One thing to clarify. Its format is
actually based on drm definition, instead of OpenGL. Sorry for
that.

> 
> > So the format is defined according to OpenGL definition.
> > Does that meet SPICE requirement?
> 
> Yes and no ;)
> 
> Some more background:  We basically have two rendering paths in qemu.
> The classic one, without opengl, and a new, still emerging one, using
> opengl and dma-bufs (gtk support merged for qemu 2.5, sdl2 support will
> land in 2.6, spice support still WIP, hopefully 2.6 too).  For best
> performance you probably want use the new opengl-based rendering
> whenever possible.  However I do *not* expect the classic rendering path
> disappear, we'll continue to need that in various cases, most prominent
> one being vnc support.
> 
> So, for non-opengl rendering qemu needs the guest framebuffer data so it
> can feed it into the vnc server.  The vfio framebuffer region is meant
> to support this use case.

what's the format requirement on that framebuffer? If you are familiar
with Intel Graphics, there's a so-called tiling feature applied on frame
buffer so it can't be used as a raw input to vnc server. w/o opengl you
need do some conversion on CPU first.

> 
> > Another thing to be added. Framebuffers are frequently switched in
> > reality. So either Qemu needs to poll or a notification mechanism is 
> > required.
> 
> The idea is to have qemu poll (and adapt poll rate, i.e. without vnc
> client connected qemu will poll alot less frequently).
> 
> > And since it's dynamic, having framebuffer page directly exposed in the
> > new region might be tricky.  We can just expose framebuffer information
> > (including base, format, etc.) and let Qemu to map separately out of VFIO
> > interface.
> 
> Allocate some memory, ask gpu to blit the guest framebuffer there, i.e.
> provide a snapshot of the current guest display instead of playing
> mapping tricks?

yes it works but better to be completed in user level.

> 
> > And... this works fine with vGPU model since software knows all the
> > detail about framebuffer. However in pass-through case, who do you expect
> > to provide that information? Is it OK to introduce vGPU specific APIs in
> > VFIO?
> 
> It will only be used in the vgpu case, not for pass-though.
> 
> We think it is better to extend the vfio interface to improve vgpu
> support rather than inventing something new while vfio can satisfy 90%
> of the vgpu needs already.  We want avoid vendor-specific extensions
> though, the vgpu extension should work across vendors.

it's fine, as long as vgpu specific interface is allowed. :-)

> 
> > Now there is no standard. We expose vGPU life-cycle mgmt. APIs through
> > sysfs (under i915 node), which is very Intel specific. In reality different
> > vendors have quite different capabilities for their own vGPUs, so not sure
> > how standard we can define such a mechanism.
> 
> Agree when it comes to create vGPU instances.
> 
> > But this code should be
> > minor to be maintained in libvirt.
> 
> As far I know libvirt only needs to discover those devices.  If they
> look like sr/iov devices in sysfs this might work without any changes to
> libvirt.
> 
> cheers,
>   Gerd
> 

[RFC/PATCH] perf tools: Introduce perf_thread for backtrace

[Namhyung Kim]

Backtrace is a crucial info for debugging.  And upcoming refcnt
tracking facility also wants to use it.

So instead of relying on glibc's backtrace_symbols[_fd] which misses
some (static) functions , use our own symbol searching mechanism.  To
do that, add perf_thread global variable to keep its maps and symbols.

The backtrace output from TUI is changed like below.  (I made a key
action to generate a segfault for testing):

Before:
  perf: Segmentation fault
   backtrace 
  perf[0x544a8b]
  /usr/lib/libc.so.6(+0x33680)[0x7fc46420b680]
  perf[0x54041b]
  perf(perf_evlist__tui_browse_hists+0x91)[0x5432e1]
  perf(cmd_report+0x1d20)[0x43cb10]
  perf[0x487073]
  perf(main+0x62f)[0x42cb1f]
  /usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7fc4641f8610]
  perf(_start+0x29)[0x42cc39]
  [0x0]

After:
  perf: Segmentation fault
   backtrace 
  perf_evsel__hists_browse(+0x43b) in perf [0x54066b]
  perf_evlist__tui_browse_hists(+0x91) in perf [0x543531]
  cmd_report(+0x1d20) in perf [0x43cb50]
  run_builtin(+0x53) in perf [0x4870b3]
  main(+0x634) in perf [0x42cb54]
  __libc_start_main(+0xf0) in libc-2.22.so [0x7fea3577c610]
  _start(+0x29) in perf [0x42cc79]
  [0x0]

Cc: Frederic Weisbecker 
Cc: Masami Hiramatsu 
Signed-off-by: Namhyung Kim 
---
 tools/perf/perf.c |  7 +-
 tools/perf/ui/tui/setup.c | 21 ++--
 tools/perf/util/util.c| 62 +++
 tools/perf/util/util.h|  5 
 4 files changed, 92 insertions(+), 3 deletions(-)

diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 4bee53c3f796..f77eb440b05c 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -604,6 +604,8 @@ int main(int argc, const char **argv)
 */
pthread__block_sigwinch();
 
+   create_perf_thread();
+
while (1) {
static int done_help;
int was_alias = run_argv(, );
@@ -615,7 +617,7 @@ int main(int argc, const char **argv)
fprintf(stderr, "Expansion of alias '%s' failed; "
"'%s' is not a perf-command\n",
cmd, argv[0]);
-   goto out;
+   goto out_destroy;
}
if (!done_help) {
cmd = argv[0] = help_unknown_cmd(cmd);
@@ -626,6 +628,9 @@ int main(int argc, const char **argv)
 
fprintf(stderr, "Failed to run command '%s': %s\n",
cmd, strerror_r(errno, sbuf, sizeof(sbuf)));
+
+out_destroy:
+   destroy_perf_thread();
 out:
return 1;
 }
diff --git a/tools/perf/ui/tui/setup.c b/tools/perf/ui/tui/setup.c
index 7dfeba0a91f3..bc2da884e65a 100644
--- a/tools/perf/ui/tui/setup.c
+++ b/tools/perf/ui/tui/setup.c
@@ -13,6 +13,8 @@
 #include "../libslang.h"
 #include "../keysyms.h"
 #include "tui.h"
+#include "../../util/symbol.h"
+#include "../../util/thread.h"
 
 static volatile int ui__need_resize;
 
@@ -96,14 +98,29 @@ int ui__getch(int delay_secs)
 static void ui__signal_backtrace(int sig)
 {
void *stackdump[32];
-   size_t size;
+   size_t size, i;
 
ui__exit(false);
psignal(sig, "perf");
 
printf(" backtrace \n");
size = backtrace(stackdump, ARRAY_SIZE(stackdump));
-   backtrace_symbols_fd(stackdump, size, STDOUT_FILENO);
+   /* skip first two stack frame (for this function and signal stack) */
+   for (i = 2; i < size; i++) {
+   struct addr_location al = {
+   .sym = NULL,
+   };
+
+   thread__find_addr_location(perf_thread, PERF_RECORD_MISC_USER,
+  MAP__FUNCTION, (long)stackdump[i], 
);
+
+   if (al.sym)
+   printf("%s(+0x%"PRIx64") in ", al.sym->name,
+  map__map_ip(al.map, (u64)stackdump[i]) - 
al.sym->start);
+   if (al.map)
+   printf("%s ", al.map->dso->short_name);
+   printf("[0x%lx]\n", (unsigned long)stackdump[i]);
+   }
 
exit(0);
 }
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 75759aebc7b8..f1a26ea14053 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -16,6 +16,9 @@
 #include 
 #include 
 #include "callchain.h"
+#include "machine.h"
+#include "thread.h"
+#include "thread_map.h"
 
 struct callchain_param callchain_param = {
.mode   = CHAIN_GRAPH_ABS,
@@ -696,3 +699,62 @@ fetch_kernel_version(unsigned int *puint, char *str,
*puint = (version << 16) + (patchlevel << 8) + sublevel;
return 0;
 }
+
+
+static int process_event(struct perf_tool *tool, union perf_event *event,
+struct perf_sample *sample, struct machine *machine)
+{
+   switch (event->header.type) {
+   case PERF_RECORD_COMM:
+   return tool->comm(tool, event, sample, machine);
+   case PERF_RECORD_MMAP:

Re: [PATCH 1/1] usb: phy: omap-otg: do not write to unallocated memory

[Chanwoo Choi]

Hi,

The same patch was already reviewed and applied on usb.git repository[1]
[1] 
https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/fixes=2c2025b41aeff57963f9ae2dd909fea704c625ab

Thanks,
Chanwoo Choi

On 2015년 11월 20일 08:43, Heinrich Schuchardt wrote:
> The current coding writes to memory before allocating it.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/usb/phy/phy-omap-otg.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
> index 1270906..8bbf121 100644
> --- a/drivers/usb/phy/phy-omap-otg.c
> +++ b/drivers/usb/phy/phy-omap-otg.c
> @@ -105,12 +105,13 @@ static int omap_otg_probe(struct platform_device *pdev)
>   extcon = extcon_get_extcon_dev(config->extcon);
>   if (!extcon)
>   return -EPROBE_DEFER;
> - otg_dev->extcon = extcon;
>  
>   otg_dev = devm_kzalloc(>dev, sizeof(*otg_dev), GFP_KERNEL);
>   if (!otg_dev)
>   return -ENOMEM;
>  
> + otg_dev->extcon = extcon;
> +
>   otg_dev->base = devm_ioremap_resource(>dev, >resource[0]);
>   if (IS_ERR(otg_dev->base))
>   return PTR_ERR(otg_dev->base);
> 

--
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] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Tian, Kevin]

> From: Song, Jike
> Sent: Friday, November 20, 2015 1:52 PM
> 
> On 11/20/2015 12:22 PM, Alex Williamson wrote:
> > On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> >> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> >>> On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
>  On Thu, 19 Nov 2015, Jike Song wrote:
> > Hi Alex, thanks for the discussion.
> >
> > In addition to Kevin's replies, I have a high-level question: can VFIO
> > be used by QEMU for both KVM and Xen?
> 
>  No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
>  is owned by Xen.
> >>>
> >>> Right, but in this case we're talking about device MMUs, which are owned
> >>> by the device driver which I think is running in dom0, right?  This
> >>> proposal doesn't require support of the system IOMMU, the dom0 driver
> >>> maps IOVA translations just as it would for itself.  We're largely
> >>> proposing use of the VFIO API to provide a common interface to expose a
> >>> PCI(e) device to QEMU, but what happens in the vGPU vendor device and
> >>> IOMMU backends is specific to the device and perhaps even specific to
> >>> the hypervisor.  Thanks,

As I commented in another thread, let's not including device MMU in this
discussion, which is purely device internal so not in the scope of VFIO (Qemu
doesn't need to know). Let's keep discussion about a dummy type-1
IOMMU driver for maintaining G2H mapping.

> >>
> >> Let me conclude this, and please correct me in case of any misread: the
> >> vGPU interface between kernel and QEMU will be through VFIO, with a new
> >> VFIO backend (instead of the existing type1), for both KVMGT and XenGT?
> >
> > My primary concern is KVM and QEMU upstream, the proposal is not
> > specifically directed at XenGT, but does not exclude it either.  Xen is
> > welcome to adopt this proposal as well, it simply defines the channel
> > through which vGPUs are exposed to QEMU as the VFIO API.  The core VFIO
> > code in the Linux kernel is just as available for use in Xen dom0 as it
> > is for a KVM host. VFIO in QEMU certainly knows about some
> > accelerations for KVM, but these are almost entirely around allowing
> > eventfd based interrupts to be injected through KVM, which is something
> > I'm sure Xen could provide as well.  These accelerations are also not
> > required, VFIO based device assignment in QEMU works with or without
> > KVM.  Likewise, the VFIO kernel interface knows nothing about KVM and
> > has no dependencies on it.
> >
> > There are two components to the VFIO API, one is the type1 compliant
> > IOMMU interface, which for this proposal is really doing nothing more
> > than tracking the HVA to GPA mappings for the VM.  This much seems
> > entirely common regardless of the hypervisor.  The other part is the
> > device interface.  The lifecycle of the virtual device seems like it
> > would be entirely shared, as does much of the emulation components of
> > the device.  When we get to pinning pages, providing direct access to
> > memory ranges for a VM, and accelerating interrupts, the vGPU drivers
> > will likely need some per hypervisor branches, but these are areas where
> > that's true no matter what the interface.  I'm probably over
> > simplifying, but hopefully not too much, correct me if I'm wrong.
> >
> 
> Thanks for confirmation. For QEMU/KVM, I totally agree your point; However,
> if we take XenGT to consider, it will be a bit more complex: with Xen
> hypervisor and Dom0 kernel running in different level, it's not a straight-
> forward way for QEMU to do something like mapping a portion of MMIO BAR
> via VFIO in Dom0 kernel, instead of calling hypercalls directly.
> 
> I don't know if there is a better way to handle this. But I do agree that
> channels between kernel and Qemu via VFIO is a good idea, even though we
> may have to split KVMGT/XenGT in Qemu a bit.  We are currently working on
> moving all of PCI CFG emulation from kernel to Qemu, hopefully we can
> release it by end of this year and work with you guys to adjust it for
> the agreed method.

Currently pass-through path is already different in Qemu between Xen and KVM.
For now let's keep it simple about how to extend VFIO to manage vGPU. In
the future if Xen decides to use VFIO, it should not be that difficult to add
some Xen specific vfio driver there.

> 
> 
> > The benefit of course is that aside from some extensions to the API, the
> > QEMU components are already in place and there's a lot more leverage for
> > getting both QEMU and libvirt support upstream in being able to support
> > multiple vendors, perhaps multiple hypervisors, with the same code.
> > Also, I'm not sure how useful it is, but VFIO is a userspace driver
> > interface, where here we're predominantly talking about that userspace
> > driver being QEMU.  It's not limited to that though.  A userspace
> > compute application could have direct access to a vGPU through this
> > model.  Thanks,
> 

One idea in 

[PATCH] staging: lustre: lustre: fld: Removed a blank line

[Anjali Menon]

Removed a blank line after the open brace to remove the
check detected by the checkpatch.pl.

CHECK: Blank lines aren't necessary after an open brace '{'

Signed-off-by: Anjali Menon 
---
 drivers/staging/lustre/lustre/fld/fld_cache.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/fld/fld_cache.c 
b/drivers/staging/lustre/lustre/fld/fld_cache.c
index 4469174..c7a0f0c 100644
--- a/drivers/staging/lustre/lustre/fld/fld_cache.c
+++ b/drivers/staging/lustre/lustre/fld/fld_cache.c
@@ -227,7 +227,6 @@ static int fld_cache_shrink(struct fld_cache *cache)
 
while (cache->fci_cache_count + cache->fci_threshold >
   cache->fci_cache_size && curr != >fci_lru) {
-
flde = list_entry(curr, struct fld_cache_entry, fce_lru);
curr = curr->prev;
fld_cache_entry_delete(cache, flde);
-- 
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 perf/core 03/13] perf: Introduce generic refcount APIs with debug feature

[Namhyung Kim]

On Fri, Nov 20, 2015 at 04:12:06AM +, 平松雅巳 / HIRAMATU，MASAMI wrote:
> From: Namhyung Kim [mailto:namhy...@kernel.org]
> >
> >On Wed, Nov 18, 2015 at 03:40:16PM +0900, Masami Hiramatsu wrote:
> >> This is a kind of debugging feature for atomic reference counter.
> >> The reference counters are widely used in perf tools but not well
> >> debugged. It sometimes causes memory leaks but no one has noticed
> >> the issue, since it is hard to debug such un-reclaimed objects.
> >>
> >> This refcnt interface provides fully backtrace debug feature to
> >> analyze such issue. User just replace atomic_t ops with refcnt
> >> APIs and add refcnt__exit() where the object is released.
> >>
> >> /* At object initializing */
> >> refcnt__init(obj, refcnt); /* <- atomic_set(>refcnt, 1); */
> >>
> >> /* At object get method */
> >> refcnt__get(obj, refcnt); /* <- atomic_inc(>refcnt); */
> >>
> >> /* At object put method */
> >> if (obj && refcnt__put(obj, refcnt)) /* 
> >> <-atmoic_dec_and_test(>refcnt)*/
> >>
> >> /* At object releasing */
> >> refcnt__exit(obj, refcnt); /* <- Newly added */
> >>
> >> The debugging feature is enabled when building perf with
> >> REFCNT_DEBUG=1. Otherwides it is just translated as normal
> >> atomic ops.
> >>
> >> Debugging binary warns you if it finds leaks when the perf exits.
> >> If you give -v (or --verbose) to the perf, it also shows backtrace
> >> logs on all refcnt operations of leaked objects.
> >>
> >> Signed-off-by: Masami Hiramatsu 
> >
> >Looks really useful!
> >
> >Acked-by: Namhyung Kim 
> >
> >Just a nitpick below..
> 
> Thanks!
> 
> >> ---
> >
> >[SNIP]
> >> +void refcnt_object__record(void *obj, const char *name, int count)
> >> +{
> >> +  struct refcnt_object *ref = refcnt__find_object(obj);
> >> +  struct refcnt_buffer *buf;
> >> +
> >> +  /* If no entry, allocate new one */
> >> +  if (!ref) {
> >> +  ref = malloc(sizeof(*ref));
> >> +  if (!ref) {
> >> +  pr_debug("REFCNT: Out of memory for %p (%s)\n",
> >> +   obj, name);
> >> +  return;
> >> +  }
> >> +  INIT_LIST_HEAD(>list);
> >> +  INIT_LIST_HEAD(>head);
> >> +  ref->name = name;
> >> +  ref->obj = obj;
> >> +  list_add_tail(>list, _root);
> >> +  }
> >> +
> >> +  buf = malloc(sizeof(*buf));
> >> +  if (!buf) {
> >> +  pr_debug("REFCNT: Out of memory for %p (%s)\n", obj, ref->name);
> >> +  return;
> >> +  }
> >> +
> >> +  INIT_LIST_HEAD(>list);
> >> +  buf->count = count;
> >> +  buf->nr = backtrace(buf->buf, BACKTRACE_SIZE);
> >> +  list_add_tail(>list, >head);
> >> +}
> >> +
> >> +static void pr_refcnt_buffer(struct refcnt_buffer *buf)
> >> +{
> >> +  char **symbuf;
> >> +  int i;
> >> +
> >> +  if (!buf)
> >> +  return;
> >> +  symbuf = backtrace_symbols(buf->buf, buf->nr);
> >
> >It seems you need to check the return value.  Maybe we can use
> >backtrace_symbols_fd() instead, or just in case of an error.
> 
> Yeah, it should be checked and in that case we can fall back to
> backtrace_symbols_fd(as the last resort), but I don’t like
> backtrace_symbols_fd replacing because it doesn't allow us to
> indent the backtrace result.

OK, I think we need to improve the backtrace code in general.  I'll
send a related patch soon.

Thanks,
Namhyung


> >
> >> +  /* Skip the first one because it is always btrace__record */
> >> +  for (i = 1; i < buf->nr; i++)
> >> +  pr_debug("  %s\n", symbuf[i]);
> >> +  free(symbuf);
> >> +}
> >> +
> >> +void refcnt__dump_unreclaimed(void) __attribute__((destructor));
> >> +void refcnt__dump_unreclaimed(void)
> >> +{
> >> +  struct refcnt_object *ref, *n;
> >> +  struct refcnt_buffer *buf;
> >> +  int i = 0;
> >> +
> >> +  if (list_empty(_root))
> >> +  return;
> >> +
> >> +  pr_warning("REFCNT: BUG: Unreclaimed objects found.\n");
> >> +  list_for_each_entry_safe(ref, n, _root, list) {
> >> +  pr_debug(" [%d] \nUnreclaimed %s: %p\n", i,
> >> +   ref->name ? ref->name : "(object)", ref->obj);
> >> +  list_for_each_entry(buf, >head, list) {
> >> +  pr_debug("Refcount %s => %d at\n",
> >> +   buf->count > 0 ? "+1" : "-1",
> >> +   buf->count > 0 ? buf->count : -buf->count - 1);
> >> +  pr_refcnt_buffer(buf);
> >> +  }
> >> +  __refcnt_object__delete(ref);
> >> +  i++;
> >> +  }
> >> +  pr_warning("REFCNT: Total %d objects are not reclaimed.\n", i);
> >> +  if (!verbose)
> >> +  pr_warning("   To see all backtraces, rerun with -v option\n");
> >> +}
--
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] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Jike Song]

On 11/20/2015 12:22 PM, Alex Williamson wrote:

On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:

On 11/19/2015 11:52 PM, Alex Williamson wrote:

On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:

On Thu, 19 Nov 2015, Jike Song wrote:

Hi Alex, thanks for the discussion.

In addition to Kevin's replies, I have a high-level question: can VFIO
be used by QEMU for both KVM and Xen?


No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
is owned by Xen.


Right, but in this case we're talking about device MMUs, which are owned
by the device driver which I think is running in dom0, right?  This
proposal doesn't require support of the system IOMMU, the dom0 driver
maps IOVA translations just as it would for itself.  We're largely
proposing use of the VFIO API to provide a common interface to expose a
PCI(e) device to QEMU, but what happens in the vGPU vendor device and
IOMMU backends is specific to the device and perhaps even specific to
the hypervisor.  Thanks,


Let me conclude this, and please correct me in case of any misread: the
vGPU interface between kernel and QEMU will be through VFIO, with a new
VFIO backend (instead of the existing type1), for both KVMGT and XenGT?


My primary concern is KVM and QEMU upstream, the proposal is not
specifically directed at XenGT, but does not exclude it either.  Xen is
welcome to adopt this proposal as well, it simply defines the channel
through which vGPUs are exposed to QEMU as the VFIO API.  The core VFIO
code in the Linux kernel is just as available for use in Xen dom0 as it
is for a KVM host. VFIO in QEMU certainly knows about some
accelerations for KVM, but these are almost entirely around allowing
eventfd based interrupts to be injected through KVM, which is something
I'm sure Xen could provide as well.  These accelerations are also not
required, VFIO based device assignment in QEMU works with or without
KVM.  Likewise, the VFIO kernel interface knows nothing about KVM and
has no dependencies on it.

There are two components to the VFIO API, one is the type1 compliant
IOMMU interface, which for this proposal is really doing nothing more
than tracking the HVA to GPA mappings for the VM.  This much seems
entirely common regardless of the hypervisor.  The other part is the
device interface.  The lifecycle of the virtual device seems like it
would be entirely shared, as does much of the emulation components of
the device.  When we get to pinning pages, providing direct access to
memory ranges for a VM, and accelerating interrupts, the vGPU drivers
will likely need some per hypervisor branches, but these are areas where
that's true no matter what the interface.  I'm probably over
simplifying, but hopefully not too much, correct me if I'm wrong.



Thanks for confirmation. For QEMU/KVM, I totally agree your point; However,
if we take XenGT to consider, it will be a bit more complex: with Xen
hypervisor and Dom0 kernel running in different level, it's not a straight-
forward way for QEMU to do something like mapping a portion of MMIO BAR
via VFIO in Dom0 kernel, instead of calling hypercalls directly.

I don't know if there is a better way to handle this. But I do agree that
channels between kernel and Qemu via VFIO is a good idea, even though we
may have to split KVMGT/XenGT in Qemu a bit.  We are currently working on
moving all of PCI CFG emulation from kernel to Qemu, hopefully we can
release it by end of this year and work with you guys to adjust it for
the agreed method.



The benefit of course is that aside from some extensions to the API, the
QEMU components are already in place and there's a lot more leverage for
getting both QEMU and libvirt support upstream in being able to support
multiple vendors, perhaps multiple hypervisors, with the same code.
Also, I'm not sure how useful it is, but VFIO is a userspace driver
interface, where here we're predominantly talking about that userspace
driver being QEMU.  It's not limited to that though.  A userspace
compute application could have direct access to a vGPU through this
model.  Thanks,





Alex


--
Thanks,
Jike
--
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] extcon: palmas: add support for using VBUSDET output

[Chanwoo Choi]

Hi Felipe,

On 2015년 11월 20일 14:33, Chanwoo Choi wrote:
> Hi Felipe,
> 
> Looks good to me. But I have one comment.
> 
> On 2015년 11월 13일 02:57, Felipe Balbi wrote:
>> TPS659038 can remux its GPIO_1 as VBUSDET output,
>> which can be tied to a SoC GPIO and used as a VBUS
>> interrupt.
>>
>> Beagle X15 uses that, in fact, and without it, I
>> could not get USB peripheral working with that
>> board.
>>
>> Signed-off-by: Felipe Balbi 
>> ---
>>  drivers/extcon/extcon-palmas.c | 22 --
>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
>> index 93c30a885740..7985d092c069 100644
>> --- a/drivers/extcon/extcon-palmas.c
>> +++ b/drivers/extcon/extcon-palmas.c
>> @@ -296,10 +296,28 @@ static int palmas_usb_probe(struct platform_device 
>> *pdev)
>>  }
>>  
>>  if (palmas_usb->enable_vbus_detection) {
>> +int irq = platform_get_irq(pdev, 0);
>> +
>> +if (irq > 0) {
>> +/* remux GPIO_1 as VBUSDET */
>> +status = palmas_update_bits(palmas, 
>> PALMAS_PU_PD_OD_BASE,
>> +PALMAS_PRIMARY_SECONDARY_PAD1,
>> +
>> PALMAS_PRIMARY_SECONDARY_PAD1_GPIO_1_MASK,
>> +(1 << 3));
> 
> PALMAS_PRIMARY_SECONDARY_PAD1_GPIO_1_SHIFT is appropriate instead of using 
> '3'.
> Also, I don't recommend the over line 80. The everything else is good
> 
> 
>> +if (status < 0) {
>> +dev_err(>dev, "can't remux GPIO1\n");
>> +return status;
>> +}
>> +
>> +palmas_usb->vbus_irq = irq;
>> +} else {
>> +irq = regmap_irq_get_virq(palmas->irq_data,
>> +PALMAS_VBUS_IRQ);
>> +palmas_usb->vbus_irq = irq;
>> +}
>> +
>>  palmas_usb->vbus_otg_irq = regmap_irq_get_virq(palmas->irq_data,
>> PALMAS_VBUS_OTG_IRQ);
>> -palmas_usb->vbus_irq = regmap_irq_get_virq(palmas->irq_data,
>> -   PALMAS_VBUS_IRQ);
>>  status = devm_request_threaded_irq(palmas_usb->dev,
>>  palmas_usb->vbus_irq, NULL,
>>  palmas_vbus_irq_handler,
>>
> 
> Thanks,
> Chanwoo Choi
> --
> 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/
> 

If you are OK about following patch, I'll apply it on extcon branch.

diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 93c30a885740..f601370c9466 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -296,10 +296,29 @@ static int palmas_usb_probe(struct platform_device *pdev)
}
 
if (palmas_usb->enable_vbus_detection) {
+   int irq = platform_get_irq(pdev, 0);
+
+   if (irq > 0) {
+   /* remux GPIO_1 as VBUSDET */
+   status = palmas_update_bits(palmas,
+   PALMAS_PU_PD_OD_BASE,
+   PALMAS_PRIMARY_SECONDARY_PAD1,
+   PALMAS_PRIMARY_SECONDARY_PAD1_GPIO_1_MASK,
+   (1 << 
PALMAS_PRIMARY_SECONDARY_PAD1_GPIO_1_SHIFT));
+   if (status < 0) {
+   dev_err(>dev, "can't remux GPIO1\n");
+   return status;
+   }
+
+   palmas_usb->vbus_irq = irq;
+   } else {
+   irq = regmap_irq_get_virq(palmas->irq_data,
+   PALMAS_VBUS_IRQ);
+   palmas_usb->vbus_irq = irq;
+   }
+
palmas_usb->vbus_otg_irq = regmap_irq_get_virq(palmas->irq_data,
   PALMAS_VBUS_OTG_IRQ);
-   palmas_usb->vbus_irq = regmap_irq_get_virq(palmas->irq_data,
-  PALMAS_VBUS_IRQ);
status = devm_request_threaded_irq(palmas_usb->dev,
palmas_usb->vbus_irq, NULL,
palmas_vbus_irq_handler,
-- 
1.9.1


Thanks,
Chanwoo Choi

--
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/2] arm: boot: beaglex15: pass correct interrupt

[Chanwoo Choi]

Hi,

On 2015년 11월 13일 02:53, Felipe Balbi wrote:
> According to latest schematics [1], GPIO_1/VBUSDET
> on TPS659038 is tied to AM57x GPIO4_21. We can use
> that as a VBUS interrupt, instead of relying on
> PMIC's VBUS interrupts which don't seem to be firing
> on x15 at all.
> 
> A follow up patch will add support for using this
> GPIO-based interrupt mechanism for notifying about
> VBUS.
> 
> [1] 
> https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2.pdf
> 
> Signed-off-by: Felipe Balbi 
> ---
>  arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 6f3a1a7ec5f9..5e47162f7883 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -560,6 +560,7 @@
>   extcon_usb2: tps659038_usb {
>   compatible = "ti,palmas-usb-vid";
>   ti,enable-vbus-detection;
> + interrupts-extended = < 21 IRQ_TYPE_EDGE_RISING>;
>   };
>  
>   };
> 

I check the schematic file. The GPIO4_21 pin is connected as following:
- GPIO_1/VBUSDET -> PMIC_VBUS_DET -> VBUS_DET -> AM5728 GPIO4_21 pin

Reviewed-by: Chanwoo Choi 

Thanks,
Chanwoo Choi
--
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] clk: use IS_ERR_OR_NULL(hw) instead of !hw || IS_ERR(hw)

[Masahiro Yamada]

This minor refactoring does not change the function behavior.

Signed-off-by: Masahiro Yamada 
---

 drivers/clk/clk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index f13c3f4..764aca2 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2482,7 +2482,7 @@ struct clk *__clk_create_clk(struct clk_hw *hw, const 
char *dev_id,
struct clk *clk;
 
/* This is to allow this function to be chained to others */
-   if (!hw || IS_ERR(hw))
+   if (IS_ERR_OR_NULL(hw))
return (struct clk *) hw;
 
clk = kzalloc(sizeof(*clk), GFP_KERNEL);
-- 
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] extcon: palmas: add support for using VBUSDET output

[Chanwoo Choi]

Hi Felipe,

Looks good to me. But I have one comment.

On 2015년 11월 13일 02:57, Felipe Balbi wrote:
> TPS659038 can remux its GPIO_1 as VBUSDET output,
> which can be tied to a SoC GPIO and used as a VBUS
> interrupt.
> 
> Beagle X15 uses that, in fact, and without it, I
> could not get USB peripheral working with that
> board.
> 
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/extcon/extcon-palmas.c | 22 --
>  1 file changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
> index 93c30a885740..7985d092c069 100644
> --- a/drivers/extcon/extcon-palmas.c
> +++ b/drivers/extcon/extcon-palmas.c
> @@ -296,10 +296,28 @@ static int palmas_usb_probe(struct platform_device 
> *pdev)
>   }
>  
>   if (palmas_usb->enable_vbus_detection) {
> + int irq = platform_get_irq(pdev, 0);
> +
> + if (irq > 0) {
> + /* remux GPIO_1 as VBUSDET */
> + status = palmas_update_bits(palmas, 
> PALMAS_PU_PD_OD_BASE,
> + PALMAS_PRIMARY_SECONDARY_PAD1,
> + 
> PALMAS_PRIMARY_SECONDARY_PAD1_GPIO_1_MASK,
> + (1 << 3));

PALMAS_PRIMARY_SECONDARY_PAD1_GPIO_1_SHIFT is appropriate instead of using '3'.
Also, I don't recommend the over line 80. The everything else is good


> + if (status < 0) {
> + dev_err(>dev, "can't remux GPIO1\n");
> + return status;
> + }
> +
> + palmas_usb->vbus_irq = irq;
> + } else {
> + irq = regmap_irq_get_virq(palmas->irq_data,
> + PALMAS_VBUS_IRQ);
> + palmas_usb->vbus_irq = irq;
> + }
> +
>   palmas_usb->vbus_otg_irq = regmap_irq_get_virq(palmas->irq_data,
>  PALMAS_VBUS_OTG_IRQ);
> - palmas_usb->vbus_irq = regmap_irq_get_virq(palmas->irq_data,
> -PALMAS_VBUS_IRQ);
>   status = devm_request_threaded_irq(palmas_usb->dev,
>   palmas_usb->vbus_irq, NULL,
>   palmas_vbus_irq_handler,
> 

Thanks,
Chanwoo Choi
--
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: Hibernate resume bug around 3,18-rc2 - Full PAT support

[Vassilis Virvilis]

On 11/19/2015 10:35 PM, Vassilis Virvilis wrote:


I compiled and I am running 4.3 right now.



It failed this morning. Last night I did 3 hibernate / resume cycles. In the 
last one I I also turned off the PSU (this seems to push it over the edge - but 
it may be random behavior) and it worked. This morning 7h later failed to 
resume - but it didn't hang on _lapic_resume. This time it rebooted - and I 
seem to recall this behavior for 4.2+ kernels. I forgot to mention it because 
my testing with 4.x kernels were one month before.

So 4.3 kernel - reboots on resume after a long hibernation time.

I am testing with 4.3 and nopat right now.

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

rhashtable: how to deal with that rhashtable_lookup_insert_key return -EBUSY

[Xin Long]

when I use rhashtable_lookup_insert_key, sometimes it will return -EBUSY.
im not sure if there is a good way to workabout it.
or I should just try again and again until it's inserted successfully ?

I have seen some use in kernel  by now, but it seems that no one consider
this issue for their cases. but it indeed exists in my case.

did I use it incorrectly or something else ?

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: [PATCH V3 2/5] PM / OPP: Add {opp-microvolt|opp-microamp}- binding

[Viresh Kumar]

On 12-11-15, 10:38, Viresh Kumar wrote:
> On 11-11-15, 14:31, Rob Herring wrote:
> > > + opp00 {
> > 
> > Thought we are doing frequency for unit address here.
> 
> That's done by the (Already reviewed) 4th patch..

Ping for the pending Ack :)

-- 
viresh
--
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 v6 8/9] ARM: EXYNOS: rearrange static and non-static functions of PMU driver

[Krzysztof Kozlowski]

On 20.11.2015 13:46, Manish Badarkhe wrote:
> On Tue, Nov 17, 2015 at 11:35 AM, Pankaj Dubey  
> wrote:
>> This patch moves exynos_sys_powerdown_conf function above all
>> static functions, to avoid confusion causing due to mixing of
>> static-nonstatic-static functions and to improve readability of this
>> driver.
>>
>> Signed-off-by: Pankaj Dubey 
>> Suggested-by: Krzysztof Kozlowski 
>> Reviewed-by: Krzysztof Kozlowski 
>> ---
>>  arch/arm/mach-exynos/pmu.c | 34 +-
>>  1 file changed, 17 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
>> index 01cb649..a7741d4 100644
>> --- a/arch/arm/mach-exynos/pmu.c
>> +++ b/arch/arm/mach-exynos/pmu.c
>> @@ -39,23 +39,6 @@ u32 pmu_raw_readl(u32 offset)
>> return readl_relaxed(pmu_base_addr + offset);
>>  }
>>
>> -static void exynos_power_off(void)
>> -{
>> -   unsigned int tmp;
>> -
>> -   pr_info("Power down.\n");
>> -   tmp = pmu_raw_readl(EXYNOS_PS_HOLD_CONTROL);
>> -   tmp ^= (1 << 8);
>> -   pmu_raw_writel(tmp, EXYNOS_PS_HOLD_CONTROL);
>> -
>> -   /* Wait a little so we don't give a false warning below */
>> -   mdelay(100);
>> -
>> -   pr_err("Power down failed, please power off system manually.\n");
>> -   while (1)
>> -   ;
>> -}
>> -
>>  void exynos_sys_powerdown_conf(enum sys_powerdown mode)
>>  {
>> unsigned int i;
>> @@ -85,6 +68,23 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
>> }
>>  }
>>
>> +static void exynos_power_off(void)
>> +{
>> +   unsigned int tmp;
>> +
>> +   pr_info("Power down.\n");
>> +   tmp = pmu_raw_readl(EXYNOS_PS_HOLD_CONTROL);
>> +   tmp ^= (1 << 8);
> Can we have some define over here? to operate this bit.
> 

1. This will be removed by syscon-reboot/poweroff patches [0].
2. This patch is only rename/move. Fixing stuff should go to separate
patches. But IMHO fixing is not needed because of 1.

[0] http://www.spinics.net/lists/devicetree/msg98858.html

Best regards,
Krzysztof

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

transakce?

[1mssg]

Ahoj,

napiste mi na e-mailovou adresu pro podrobnosti o vzájemne spoluprace.

chn.j...@gmail.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 v6 8/9] ARM: EXYNOS: rearrange static and non-static functions of PMU driver

[Manish Badarkhe]

On Tue, Nov 17, 2015 at 11:35 AM, Pankaj Dubey  wrote:
> This patch moves exynos_sys_powerdown_conf function above all
> static functions, to avoid confusion causing due to mixing of
> static-nonstatic-static functions and to improve readability of this
> driver.
>
> Signed-off-by: Pankaj Dubey 
> Suggested-by: Krzysztof Kozlowski 
> Reviewed-by: Krzysztof Kozlowski 
> ---
>  arch/arm/mach-exynos/pmu.c | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
> index 01cb649..a7741d4 100644
> --- a/arch/arm/mach-exynos/pmu.c
> +++ b/arch/arm/mach-exynos/pmu.c
> @@ -39,23 +39,6 @@ u32 pmu_raw_readl(u32 offset)
> return readl_relaxed(pmu_base_addr + offset);
>  }
>
> -static void exynos_power_off(void)
> -{
> -   unsigned int tmp;
> -
> -   pr_info("Power down.\n");
> -   tmp = pmu_raw_readl(EXYNOS_PS_HOLD_CONTROL);
> -   tmp ^= (1 << 8);
> -   pmu_raw_writel(tmp, EXYNOS_PS_HOLD_CONTROL);
> -
> -   /* Wait a little so we don't give a false warning below */
> -   mdelay(100);
> -
> -   pr_err("Power down failed, please power off system manually.\n");
> -   while (1)
> -   ;
> -}
> -
>  void exynos_sys_powerdown_conf(enum sys_powerdown mode)
>  {
> unsigned int i;
> @@ -85,6 +68,23 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
> }
>  }
>
> +static void exynos_power_off(void)
> +{
> +   unsigned int tmp;
> +
> +   pr_info("Power down.\n");
> +   tmp = pmu_raw_readl(EXYNOS_PS_HOLD_CONTROL);
> +   tmp ^= (1 << 8);
Can we have some define over here? to operate this bit.

> +   pmu_raw_writel(tmp, EXYNOS_PS_HOLD_CONTROL);
> +
> +   /* Wait a little so we don't give a false warning below */
> +   mdelay(100);
> +
> +   pr_err("Power down failed, please power off system manually.\n");
> +   while (1)
> +   ;
> +}
> +
>  static int pmu_restart_notify(struct notifier_block *this,
> unsigned long code, void *unused)
>  {
> --
> 2.4.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" 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] e1000e: fix division by zero on jumbo MTUs

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Leonid Bloch
> Sent: Tuesday, October 13, 2015 2:48 AM
> To: linux-kernel@vger.kernel.org
> Cc: Kirsher, Jeffrey T ; Brandeburg, Jesse
> ; Nelson, Shannon
> ; Wyborny, Carolyn
> ; Skidmore, Donald C
> ; Vick, Matthew ;
> Ronciak, John ; Williams, Mitch A
> ; intel-wired-...@lists.osuosl.org;
> net...@vger.kernel.org; Dmitry Fleytman 
> Subject: [PATCH] e1000e: fix division by zero on jumbo MTUs
> 
> From: Dmitry Fleytman 
> 
> This patch fixes possible division by zero in receive
> interrupt handler when working without adaptive interrupt
> moderation.
> 
> The adaptive interrupt moderation mechanism is typically
> disabled on jumbo MTUs.
> 
> Signed-off-by: Dmitry Fleytman 
> Signed-off-by: Leonid Bloch 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Tested-by: Aaron Brown 
--
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/7] kernfs: implement kernfs_walk_and_get()

[Greg Kroah-Hartman]

On Thu, Nov 19, 2015 at 01:52:46PM -0500, Tejun Heo wrote:
> Implement kernfs_walk_and_get() which is similar to
> kernfs_find_and_get() but can walk a path instead of just a name.
> 
> v2: Use strlcpy() instead of strlen() + memcpy() as suggested by
> David.
> 
> Signed-off-by: Tejun Heo 
> Cc: Greg Kroah-Hartman 
> Cc: David Miller 
> ---
>  fs/kernfs/dir.c| 46 ++
>  include/linux/kernfs.h | 12 
>  2 files changed, 58 insertions(+)

Acked-by: Greg Kroah-Hartman 
--
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-wired-lan] [PATCH v2] igb: improve handling of disconnected adapters

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Jarod Wilson
> Sent: Monday, October 19, 2015 8:52 AM
> To: linux-kernel@vger.kernel.org
> Cc: net...@vger.kernel.org; Jarod Wilson ; intel-wired-
> l...@lists.osuosl.org
> Subject: [Intel-wired-lan] [PATCH v2] igb: improve handling of disconnected
> adapters
> 
> Clean up array_rd32 so that it uses igb_rd32 the same as rd32, per the
> suggestion of Alexander Duyck, and use io_addr in more places, so that
> we don't have the need to call E1000_REMOVED (which simply looks for a
> null hw_addr) nearly as much.
> 
> CC: Mark Rustad 
> CC: Jeff Kirsher 
> CC: Alexander Duyck 
> CC: intel-wired-...@lists.osuosl.org
> CC: net...@vger.kernel.org
> Acked-by: Alexander Duyck 
> Signed-off-by: Jarod Wilson 
> ---
> Note: this patch is rebased on Jeff's next-queue/dev-queue branch, which
> already had an earlier revision of this applied, so I've essentially
> reverted a2675ab and applied the revised version of this, squashed them
> together, and here is the end result, which matches the version Alex acked.
> 
>  drivers/net/ethernet/intel/igb/e1000_regs.h |  3 +--
>  drivers/net/ethernet/intel/igb/igb_main.c   | 15 ++-
>  2 files changed, 3 insertions(+), 15 deletions(-)
> 

Tested-by: Aaron Brown 
--
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 6/8] usb: dwc2: host: Assume all devices are on one single_tt hub

[John Youn]

On 11/19/2015 8:27 AM, Doug Anderson wrote:
> Felipe,
> 
> On Thu, Nov 19, 2015 at 7:34 AM, Felipe Balbi  wrote:
>>
>> Hi,
>>
>> Douglas Anderson  writes:
>>> Until we have logic to determine which devices share the same TT let's
>>> add logic to assume that all devices on a given dwc2 controller are on
>>> one single_tt hub.  This is better than the previous code that assumed
>>> that all devices were on one multi_tt hub, since single_tt hubs
>>> appear (in my experience) to be much more common and any schedule that
>>> would work on a single_tt hub will also work on a multi_tt hub.  This
>>> will prevent more than 8 total low/full speed devices to be on the bus
>>> at one time, but that's a reasonable restriction until we've made things
>>> smarter.
>>>
>>> Signed-off-by: Douglas Anderson 
>>> ---
>>> Changes in v3:
>>> - Assuming single_tt is new for v3; not terribly well tested (yet).
>>>
>>> Changes in v2: None
>>>
>>>  drivers/usb/dwc2/core.h  |  1 +
>>>  drivers/usb/dwc2/hcd_queue.c | 40 +++-
>>>  2 files changed, 40 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>>> index 567ee2c9e69f..09aa2b5ae29e 100644
>>> --- a/drivers/usb/dwc2/core.h
>>> +++ b/drivers/usb/dwc2/core.h
>>> @@ -782,6 +782,7 @@ struct dwc2_hsotg {
>>>   u16 periodic_usecs;
>>>   unsigned long periodic_bitmap[DIV_ROUND_UP(TOTAL_PERIODIC_USEC,
>>>  BITS_PER_LONG)];
>>> + bool has_split[8];
>>
>> why don't you use a u8 instead then just set each bit for each
>> "has_split" you need to take care of. This array is kinda ugly.
> 
> Let's actually drop this patch completely.  Julius and I sat down and
> he talked me through things, and with my current understanding the
> current microframe scheduler in dwc2 is broken enough that small
> little band-aids like this will do little more than just push the
> problems around.
> 
> I'm a good portion of the way through a better microframe scheduler.
> I have no doubt that it won't be perfect, but hopefully it will at
> least be based in reality...
> 
> My latest thinking on the patches in this series:
> 
> 1. usb: dwc2: rockchip: Make the max_transfer_size automatic
> 
> I'll probably separate this out into its own patch so I can stop
> sending it as part of this series.  ...or if someone wanted to land it
> then I won't bother.
> 
> 
> 2. usb: dwc2: host: Get aligned DMA in a more supported way
> 
> Still can land any time and has good benefits.  I believe that I can't
> separate this because it will cause conflicts with scheduler patches.
> 
> 
> 3. usb: dwc2: host: Add scheduler tracing
> 
> Would be nice to land.
> 
> 
> 4. usb: dwc2: host: Rewrite the microframe scheduler
> 5. usb: dwc2: host: Keep track of and use our scheduled microframe
> 6. usb: dwc2: host: Assume all devices are on one single_tt hub
> 
> Please drop patches 4-6 right now.
> 
> 
> 7. usb: dwc2: host: Add a delay before releasing periodic bandwidth
> 8. usb: dwc2: host: Giveback URB in tasklet context
> 
> I'll probably move these back up in the series (like in v2) and put
> microframe rewrite atop them.  With my current understanding the
> scheduling is so broken today that the concerns Alan brought up can
> wait until we have a proper scheduler to be addressed.  In the
> meantime getting the huge boost in interrupt speed will help with
> dwc2's correctness (and performance) because it means we're much less
> likely to miss SOF interrupts.
> 
> If anyone has any review time, giving a review to v2 of these patches
> would be helpful.  Otherwise I'll double check that v2 still looks
> good with my current understanding and eventually post them again.
> 
> -Doug
> 

Hi Doug,

Patches 1-3:
Acked-by: John Youn 

Patch 2:
Tested-by: John Youn 

Tested on core version 3.20 using internal TE for un-aligned
buffers.

I haven't had time to look into the scheduling patches yet. But I
agree with you that there are fundamental problems. I'll await
your rewrite.

Regards,
John

--
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] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Alex Williamson]

On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> > On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> >> On Thu, 19 Nov 2015, Jike Song wrote:
> >>> Hi Alex, thanks for the discussion.
> >>>
> >>> In addition to Kevin's replies, I have a high-level question: can VFIO
> >>> be used by QEMU for both KVM and Xen?
> >>
> >> No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
> >> is owned by Xen.
> >
> > Right, but in this case we're talking about device MMUs, which are owned
> > by the device driver which I think is running in dom0, right?  This
> > proposal doesn't require support of the system IOMMU, the dom0 driver
> > maps IOVA translations just as it would for itself.  We're largely
> > proposing use of the VFIO API to provide a common interface to expose a
> > PCI(e) device to QEMU, but what happens in the vGPU vendor device and
> > IOMMU backends is specific to the device and perhaps even specific to
> > the hypervisor.  Thanks,
> 
> Let me conclude this, and please correct me in case of any misread: the
> vGPU interface between kernel and QEMU will be through VFIO, with a new
> VFIO backend (instead of the existing type1), for both KVMGT and XenGT?

My primary concern is KVM and QEMU upstream, the proposal is not
specifically directed at XenGT, but does not exclude it either.  Xen is
welcome to adopt this proposal as well, it simply defines the channel
through which vGPUs are exposed to QEMU as the VFIO API.  The core VFIO
code in the Linux kernel is just as available for use in Xen dom0 as it
is for a KVM host.  VFIO in QEMU certainly knows about some
accelerations for KVM, but these are almost entirely around allowing
eventfd based interrupts to be injected through KVM, which is something
I'm sure Xen could provide as well.  These accelerations are also not
required, VFIO based device assignment in QEMU works with or without
KVM.  Likewise, the VFIO kernel interface knows nothing about KVM and
has no dependencies on it.

There are two components to the VFIO API, one is the type1 compliant
IOMMU interface, which for this proposal is really doing nothing more
than tracking the HVA to GPA mappings for the VM.  This much seems
entirely common regardless of the hypervisor.  The other part is the
device interface.  The lifecycle of the virtual device seems like it
would be entirely shared, as does much of the emulation components of
the device.  When we get to pinning pages, providing direct access to
memory ranges for a VM, and accelerating interrupts, the vGPU drivers
will likely need some per hypervisor branches, but these are areas where
that's true no matter what the interface.  I'm probably over
simplifying, but hopefully not too much, correct me if I'm wrong.

The benefit of course is that aside from some extensions to the API, the
QEMU components are already in place and there's a lot more leverage for
getting both QEMU and libvirt support upstream in being able to support
multiple vendors, perhaps multiple hypervisors, with the same code.
Also, I'm not sure how useful it is, but VFIO is a userspace driver
interface, where here we're predominantly talking about that userspace
driver being QEMU.  It's not limited to that though.  A userspace
compute application could have direct access to a vGPU through this
model.  Thanks,

Alex

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

[GIT PULL] dmaengines fixes for 4.4-rc2

[Vinod Koul]

Hi Linus

Please pull to receive fixes for dmaengine for rc2. Fixes are spread thru the
drivers this time round

The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:

  Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

are available in the git repository at:

  git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-fix-4.4-rc2

for you to fetch changes up to 2c5d7407e012721f02741f1adae2b1bdf6ef6449:

  dmaengine: at_hdmac: use %pad format string for dma_addr_t (2015-11-16 
09:21:05 +0530)


dmaengine fixes for 4.4-rc2

  This has odd fixes spreadout drivers, not major here
   - usbdmac fixes for pm
   - edma build and logic fixes
   - build warn fixes for few drivers


Arnd Bergmann (3):
  dmaengine: edma: fix build without CONFIG_OF
  dmaengine: at_xdmac: use %pad format string for dma_addr_t
  dmaengine: at_hdmac: use %pad format string for dma_addr_t

Dan Carpenter (1):
  dmaengine: edma: predecence bug in GET_NUM_QDMACH()

Geert Uytterhoeven (2):
  dmaengine: sh: usb-dmac: Fix crash on runtime suspend
  dmaengine: sh: usb-dmac: Fix pm_runtime_{enable,disable}() imbalance

Jason Liu (1):
  dmaengine: imx-sdma: remove __init annotation on sdma_event_remap

Peter Ujfalusi (1):
  dmaengine: of_dma: Correct return code for of_dma_request_slave_channel 
in case !CONFIG_OF

 drivers/dma/at_hdmac.c  | 20 ++--
 drivers/dma/at_hdmac_regs.h |  6 +++---
 drivers/dma/at_xdmac.c  | 20 ++--
 drivers/dma/edma.c  |  4 ++--
 drivers/dma/imx-sdma.c  |  2 +-
 drivers/dma/sh/usb-dmac.c   | 11 ---
 include/linux/of_dma.h  |  2 +-
 7 files changed, 35 insertions(+), 30 deletions(-)

Thanks
-- 
~Vinod


signature.asc
Description: Digital signature

pids_free double free.

[Dave Jones]

One of my debian boxes got a systemd update. After rebooting,
I started seeing a use-after-free trace, followed by a lockup.

I have two slightly different traces from separate boots,
which may give some clue as to how it's getting free'd in two ways..

http://codemonkey.org.uk/junk/IMG_0474.jpg
http://codemonkey.org.uk/junk/IMG_0476.jpg

This isn't new, I booted back to 4.3, and hit slab debugging warnings
from the same code.  (At the least it was broken differently)

The WARN_ON referenced in the 2nd trace is this..

static void pids_cancel(struct pids_cgroup *pids, int num)
{
/*  
 * A negative count (or overflow for that matter) is invalid,
 * and indicates a bug in the `pids` controller proper.
 */
WARN_ON_ONCE(atomic64_add_negative(-num, >counter));
}


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: [for-next][PATCH 2/5] tracing: Add set_event_pid directory for future use

[Steven Rostedt]

On Thu, 19 Nov 2015 15:24:27 -0800
"Paul E. McKenney"  wrote:

> > +static void *p_start(struct seq_file *m, loff_t *pos)
> > +{
> > +   struct trace_pid_list *pid_list;
> > +   struct trace_array *tr = m->private;
> > +
> > +   /*
> > +* Grab the mutex, to keep calls to p_next() having the same
> > +* tr->filtered_pids as p_start() has.
> > +* If we just passed the tr->filtered_pids around, then RCU would
> > +* have been enough, but doing that makes things more complex.
> > +*/
> > +   mutex_lock(_mutex);
> > +   rcu_read_lock_sched();  
> 
> This looks interesting...  You hold the mutex, which I am guessing
> blocks changes.  Then why the need for rcu_read_lock_sched()?

Technically you are correct. It's not needed. But I added it more for
documentation :-)

Ideally, we wouldn't need the mutex here. But then we need to pass
around the pid_list which makes it a bit more complex in the seq_file
code than to pass around the tr (where we get pid_list from
tr->filtered_pids).

And we do multiple rcu_dereference_sched()s, and for this code to work
properly (give consistent output), the result should be the same.
Hence, we grab the mutex, to keep the tr->filtered_pids to be
consistent between the rcu_dereference_sched() calls, but since we are
not modifying tr->filtered_pids(), and if we changed this code to do a
single rcu_dereference_sched() and pass around the result, then we
wouldn't need to grab the mutex, and the rcu_read_lock_sched() would be
enough.

I could remove it and change the code to do rcu_dereferenced_lock() but
to me that makes it sound like this code is an update path, which it is
not.

Does this make sense in a crazy way?

-- Steve


> 
>   Thanx, Paul
> 
> > +
> > +   pid_list = rcu_dereference_sched(tr->filtered_pids);
> > +
> > +   if (!pid_list || *pos >= pid_list->nr_pids)
> > +   return NULL;
> > +
> > +   return (void *)_list->pids[*pos];
> > +}
> > +
> > +static void p_stop(struct seq_file *m, void *p)
> > +{
> > +   rcu_read_unlock_sched();
> > +   mutex_unlock(_mutex);
> > +}
> > +
> > +static void *
> > +p_next(struct seq_file *m, void *v, loff_t *pos)
> > +{
> > +   struct trace_array *tr = m->private;
> > +   struct trace_pid_list *pid_list = 
> > rcu_dereference_sched(tr->filtered_pids);
> > +
> > +   (*pos)++;
> > +
> > +   if (*pos >= pid_list->nr_pids)
> > +   return NULL;
> > +
> > +   return (void *)_list->pids[*pos];
> > +}
> > +
> > +static int p_show(struct seq_file *m, void *v)
> > +{
> > +   pid_t *pid = v;
> > +
> > +   seq_printf(m, "%d\n", *pid);
> > +   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/

linux-next: Tree for Nov 20

[Stephen Rothwell]

Hi all,

Changes since 20151119:

The sound-soc tree still had its build failures so I used the version from
next-20151118.

The kvms390 tree gained conflicts against the kvm tree.

Non-merge commits (relative to Linus' tree): 2033
 2035 files changed, 74174 insertions(+), 31042 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, a
multi_v7_defconfig for arm and a native build of tools/perf. After the
final fixups (if any), I do an x86_64 modules_install followed by builds
for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc,
sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 231 trees (counting Linus' and 36 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,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (b4ba1f0f6533 Merge tag 'arm64-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging fixes/master (25cb62b76430 Linux 4.3-rc5)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (049e6dde7e57 Linux 4.3-rc4)
Merging arm-current/fixes (28fa99b7645a ARM: wire up mlock2 syscall)
Merging m68k-current/for-linus (bab84fa9cc09 m68k/sun3: Use %pM format 
specifier to print ethernet address)
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-fixes/fixes (1451ad03fac3 powerpc: Wire up sys_mlock2())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (2c302e7e4105 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging net/master (1b8e6a01e19f tcp: md5: fix lockdep annotation)
Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops)
Merging ipvs/master (086f332167d6 netfilter: nf_tables: add clone interface to 
expression operations)
Merging wireless-drivers/master (eeec5d0ef7ee rtlwifi: rtl8821ae: Fix lockups 
on boot)
Merging mac80211/master (c2e703a55245 mac80211: mesh: fix call_rcu() usage)
Merging sound-current/for-linus (ff9d8859e2d4 ALSA: hda - apply SKL display 
power request/release patch to BXT)
Merging pci-current/for-linus (8005c49d9aea Linux 4.4-rc1)
Merging driver-core.current/driver-core-linus (8005c49d9aea Linux 4.4-rc1)
Merging tty.current/tty-linus (8005c49d9aea Linux 4.4-rc1)
Merging usb.current/usb-linus (dad67d5f3d0e xhci: Fix a race in usb2 LPM 
resume, blocking U3 for usb2 devices)
Merging usb-gadget-fixes/fixes (d134c48d889d usb: gadget: atmel_usba_udc: 
Expose correct device speed)
Merging usb-serial-fixes/usb-linus (59536da34513 USB: qcserial: Fix support for 
HP lt4112 LTE/HSPA+ Gobi 4G Modem)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: 
fix a possible NULL dereference)
Merging staging.current/staging-linus (b57f9f34e27b Revert "Staging: wilc1000: 
coreconfigurator: Drop unneeded wrapper functions")
Merging char-misc.current/char-misc-linus (8005c49d9aea Linux 4.4-rc1)
Merging input-current/for-linus (0c6da0733bff Input: parkbd - clear unused 
function pointers)
Merging crypto-current/master (79960943fdc1 crypto: talitos - Fix timing leak 
in ESP ICV verification)
Merging ide/master (1b1050cdc5cd Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (2ce47b44b25d selftests/seccomp: Get page size 
from sysconf)
Merging backlight-fixes/for-backlight-fixe

RE: [PATCH perf/core 03/13] perf: Introduce generic refcount APIs with debug feature

[平松雅巳 / HIRAMATU，MASAMI]

From: Namhyung Kim [mailto:namhy...@kernel.org]
>
>On Wed, Nov 18, 2015 at 03:40:16PM +0900, Masami Hiramatsu wrote:
>> This is a kind of debugging feature for atomic reference counter.
>> The reference counters are widely used in perf tools but not well
>> debugged. It sometimes causes memory leaks but no one has noticed
>> the issue, since it is hard to debug such un-reclaimed objects.
>>
>> This refcnt interface provides fully backtrace debug feature to
>> analyze such issue. User just replace atomic_t ops with refcnt
>> APIs and add refcnt__exit() where the object is released.
>>
>> /* At object initializing */
>> refcnt__init(obj, refcnt); /* <- atomic_set(>refcnt, 1); */
>>
>> /* At object get method */
>> refcnt__get(obj, refcnt); /* <- atomic_inc(>refcnt); */
>>
>> /* At object put method */
>> if (obj && refcnt__put(obj, refcnt)) /* <-atmoic_dec_and_test(>refcnt)*/
>>
>> /* At object releasing */
>> refcnt__exit(obj, refcnt); /* <- Newly added */
>>
>> The debugging feature is enabled when building perf with
>> REFCNT_DEBUG=1. Otherwides it is just translated as normal
>> atomic ops.
>>
>> Debugging binary warns you if it finds leaks when the perf exits.
>> If you give -v (or --verbose) to the perf, it also shows backtrace
>> logs on all refcnt operations of leaked objects.
>>
>> Signed-off-by: Masami Hiramatsu 
>
>Looks really useful!
>
>Acked-by: Namhyung Kim 
>
>Just a nitpick below..

Thanks!

>> ---
>
>[SNIP]
>> +void refcnt_object__record(void *obj, const char *name, int count)
>> +{
>> +struct refcnt_object *ref = refcnt__find_object(obj);
>> +struct refcnt_buffer *buf;
>> +
>> +/* If no entry, allocate new one */
>> +if (!ref) {
>> +ref = malloc(sizeof(*ref));
>> +if (!ref) {
>> +pr_debug("REFCNT: Out of memory for %p (%s)\n",
>> + obj, name);
>> +return;
>> +}
>> +INIT_LIST_HEAD(>list);
>> +INIT_LIST_HEAD(>head);
>> +ref->name = name;
>> +ref->obj = obj;
>> +list_add_tail(>list, _root);
>> +}
>> +
>> +buf = malloc(sizeof(*buf));
>> +if (!buf) {
>> +pr_debug("REFCNT: Out of memory for %p (%s)\n", obj, ref->name);
>> +return;
>> +}
>> +
>> +INIT_LIST_HEAD(>list);
>> +buf->count = count;
>> +buf->nr = backtrace(buf->buf, BACKTRACE_SIZE);
>> +list_add_tail(>list, >head);
>> +}
>> +
>> +static void pr_refcnt_buffer(struct refcnt_buffer *buf)
>> +{
>> +char **symbuf;
>> +int i;
>> +
>> +if (!buf)
>> +return;
>> +symbuf = backtrace_symbols(buf->buf, buf->nr);
>
>It seems you need to check the return value.  Maybe we can use
>backtrace_symbols_fd() instead, or just in case of an error.

Yeah, it should be checked and in that case we can fall back to
backtrace_symbols_fd(as the last resort), but I don’t like
backtrace_symbols_fd replacing because it doesn't allow us to
indent the backtrace result.

Thank you,


>
>Thanks,
>Namhyung
>
>
>> +/* Skip the first one because it is always btrace__record */
>> +for (i = 1; i < buf->nr; i++)
>> +pr_debug("  %s\n", symbuf[i]);
>> +free(symbuf);
>> +}
>> +
>> +void refcnt__dump_unreclaimed(void) __attribute__((destructor));
>> +void refcnt__dump_unreclaimed(void)
>> +{
>> +struct refcnt_object *ref, *n;
>> +struct refcnt_buffer *buf;
>> +int i = 0;
>> +
>> +if (list_empty(_root))
>> +return;
>> +
>> +pr_warning("REFCNT: BUG: Unreclaimed objects found.\n");
>> +list_for_each_entry_safe(ref, n, _root, list) {
>> +pr_debug(" [%d] \nUnreclaimed %s: %p\n", i,
>> + ref->name ? ref->name : "(object)", ref->obj);
>> +list_for_each_entry(buf, >head, list) {
>> +pr_debug("Refcount %s => %d at\n",
>> + buf->count > 0 ? "+1" : "-1",
>> + buf->count > 0 ? buf->count : -buf->count - 1);
>> +pr_refcnt_buffer(buf);
>> +}
>> +__refcnt_object__delete(ref);
>> +i++;
>> +}
>> +pr_warning("REFCNT: Total %d objects are not reclaimed.\n", i);
>> +if (!verbose)
>> +pr_warning("   To see all backtraces, rerun with -v option\n");
>> +}

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

A varied bunch of fixes, the radeon pull is probably a bit larger than I'd 
like, but it contains 2 weeks of stuff, and the Fiji fixes are a bit 
large, but they are Fiji specific.

Otherwise:

mgag200: One cursor regression oops fix.
vc4: A few small fixes and cleanups.
core: Atomic fixes and Atomic helper fixes
i915: Revert for the backlight regression along with a bunch of fixes.

Dave.

The following changes since commit 34258a32d9a9fc9e38fb549efe1692301cc31f85:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux (2015-11-18 08:59:29 
-0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 2d591ab18a77e25def2c483b495e07b42a3ea79f:

  Merge tag 'drm-intel-fixes-2015-11-19' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-11-20 09:45:31 
+1000)


Alex Deucher (1):
  drm/radeon: unconditionally set sysfs_initialized

Arnd Bergmann (1):
  drm/amdgpu: fix seq_printf format string

Christian König (16):
  drm/amdgpu: remove fence trace points
  drm/amdgpu: use a timer for fence fallback
  drm/amdgpu: use fence_is_later() for vm_flush as well v2
  drm/amdgpu: use common fence for amdgpu_vm_fence
  drm/amdgpu: fix leaking the IBs on error
  drm/amdgpu: cleanup amdgpu_cs_parser handling
  drm/amdgpu: cleanup scheduler fence get/put dance
  drm/amdgpu: fix incorrect mutex usage v3
  drm/amdgpu: fix handling order in scheduler CS
  drm/amdgpu: wait interruptible when semaphores are disabled v2
  drm/amdgpu: fix typo in firmware name
  drm/amdgpu: cleanup scheduler command submission
  drm/amdgpu: remove unused VM manager field
  drm/amdgpu: cleanup VM coding style
  drm/amdgpu: move VM manager clean into the VM code again
  drm/amdgpu: keep the owner for VMIDs

Chunming Zhou (7):
  drm/amdgpu: add kmem cache for amdgpu fence
  drm/amd: add kmem cache for sched fence
  drm/amdgpu: add command submission workflow tracepoint
  drm/amdgpu: update pd while updating vm as well
  drm/amdgpu: add lock for interval tree in vm
  drm/amdgpu: move bo_reserve out of amdgpu_vm_clear_bo
  drm/amdgpu: reserve/unreserve objects out of map/unmap operations

Dan Carpenter (1):
  drm/vc4: checking for NULL instead of IS_ERR

Daniel Vetter (1):
  drm/atomic-helper: Check encoder/crtc constraints

Dave Airlie (4):
  Merge branch 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge branch 'drm-vc4-fixes' of git://github.com/anholt/linux into 
drm-fixes
  Merge tag 'topic/drm-fixes-2015-11-19' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge tag 'drm-intel-fixes-2015-11-19' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes

Eric Anholt (2):
  drm/vc4: Fix some failure to track __iomem decorations on pointers.
  drm/vc4: Make sure that planes aren't scaled.

Flora Cui (3):
  drm/amdgpu: update Fiji's mmPA_SC_RASTER_CONFIG value
  drm/amdgpu: update fiji_mgcg_cgcg_init table
  drm/amdgpu: update Fiji's tiling mode table

Imre Deak (1):
  drm/i915: get runtime PM reference around GEM set_caching IOCTL

Jani Nikula (2):
  drm/i915: quirk backlight present on Macbook 4, 1
  Revert "drm/i915: skip modeset if compatible for everyone."

Jay Cornwall (1):
  drm/amdgpu: Fix default page access routing

Julia Lawall (2):
  drm/vc4: fix platform_no_drv_owner.cocci warnings
  drm/vc4: fix itnull.cocci warnings

Junwei Zhang (1):
  drm/amdgpu: remove the unnecessary parameter adev for amdgpu_sa_bo_new()

Maarten Lankhorst (7):
  drm/core: Set legacy_cursor_update in drm_atomic_helper_disable_plane.
  drm/core: Fix old_fb handling in drm_mode_atomic_ioctl.
  drm/atomic: add a drm_atomic_clean_old_fb helper.
  drm/core: Fix old_fb handling in restore_fbdev_mode_atomic.
  drm/core: Fix old_fb handling in pan_display_atomic.
  drm/i915: Clear intel_crtc->atomic before updating it.
  drm/i915: Consider SPLL as another shared pll, v2.

Maxim Sheviakov (1):
  drm/radeon: fix quirk for MSI R7 370 Armor 2X

Michel Dänzer (3):
  drm/radeon: Disable uncacheable CPU mappings of GTT with RV6xx
  drm/radeon: Always disable RADEON_GEM_GTT_UC along with RADEON_GEM_GTT_WC
  drm/radeon: Only prompt for enabling PAT when we'd allow write-combining

Mika Kuoppala (2):
  drm/i915: Fix GT frequency rounding
  drm/i915: Fix gpu frequency change tracing

Rex Zhu (1):
  drm/amdgpu: fix bug that can't enter thermal interrupt for bonaire.

Ville Syrjälä (3):
  drm/i915: Fix crtc_y assignment in intel_find_initial_plane_obj()
  drm: Fix primary plane size for stereo doubled modes for legacy setcrtc
  drm/i915: Don't clobber the addfb2 ioctl params

Wang, Rui Y (1):
  

Re: [PATCH RESEND 1/8] arm: dts: berlin2q: add watchdog nodes

[Jisheng Zhang]

On Thu, 19 Nov 2015 21:47:05 +0100
Sebastian Hesselbarth wrote:

> On 16.11.2015 12:09, Jisheng Zhang wrote:
> > The Marvell Berlin BG2Q has 3 watchdogs which are compatible with the
> > snps,dw-wdt driver sit in the sysmgr domain. This patch adds the
> > corresponding device tree nodes.
> > 
> > Signed-off-by: Jisheng Zhang 
> > ---
> >  arch/arm/boot/dts/berlin2q.dtsi | 24 
> >  1 file changed, 24 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/berlin2q.dtsi 
> > b/arch/arm/boot/dts/berlin2q.dtsi
> > index a3ecde5..fac4315 100644
> > --- a/arch/arm/boot/dts/berlin2q.dtsi
> > +++ b/arch/arm/boot/dts/berlin2q.dtsi
> > @@ -483,6 +483,30 @@
> > ranges = <0 0xfc 0x1>;
> > interrupt-parent = <>;
> >  
> > +   wdt0: watchdog@1000 {
> > +   compatible = "snps,dw-wdt";
> > +   reg = <0x1000 0x100>;
> > +   clocks = <>;
> > +   interrupts = <0>;
> > +   status = "disabled";  
> 
> Jisheng,
> 
> as the watchdogs are internal and cannot be clock gated
> at all, how about we remove the status = "disabled" and
> make them always available?

there are two issues here:

1. the dw-wdt can't support multiple variants now. I have rewrite the driver
with watchdog core supplied framework, but the patch isn't sent out and
may be need time to clean up and review.

2. not all dw-wdt devices are available and functional. This depends on
board design and configuration.

So IMHO status=disabled and patch5-8 is necessary, what do you think?

Thanks a lot for review,
Jisheng

> 
> I have applied patches 1-4 with the status property removed.
> This also renders patches 5-8 useless.
> 
> So, for now tentatively
> 
> Appled to berlin/dt and berlin64/dt respectivly
> 
> with status property removed.
> 
> Sebastian
> 

--
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 RESEND] arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs

[Jisheng Zhang]

On Thu, 19 Nov 2015 20:54:23 +0100
Sebastian Hesselbarth wrote:

> On 19.11.2015 17:59, Jisheng Zhang wrote:
> > On Tue, 17 Nov 2015 13:41:54 +
> > Catalin Marinas wrote:
> >   
> >>>  this small patch is missed:
> >>>  
> >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/378638.html
> >>>  arch/arm64/Kconfig.platforms | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> >>> index 4043c35..905d308 100644
> >>> --- a/arch/arm64/Kconfig.platforms
> >>> +++ b/arch/arm64/Kconfig.platforms
> >>> @@ -9,6 +9,7 @@ config ARCH_BERLIN
> >>>   bool "Marvell Berlin SoC Family"
> >>>   select ARCH_REQUIRE_GPIOLIB
> >>>   select DW_APB_ICTL
> >>> + select PINCTRL
> >>>   help
> >>> This enables support for Marvell Berlin SoC Family
> >>
> >> Cc'ing arm-soc.
> >>  
> > 
> > when adding clk support for BG4CT, I found
> > 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/378634.html
> > and
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/378635.html
> > 
> > are also missed in v4.4-rc1.
> > 
> > I know you are very busy but I dunno what's wrong. Can you please check?  
> 
> Jisheng,
> 
> there is nothing wrong. I applied the patches in question but didn't
> make it to send another pull-request in time.
> 
> I have re-added both patches to berlin64/dt again that will be sent
> for v4.4.
> 

Dear Sebastian,

I'm glad our berlin maintainer is back ;)

In last two years, you helped Marvell Berlin SoC mainline progress a lot and
gave lots of wonderful review comments and suggestions, I hope you can
continue to help us even I know your are very busy :D

In next few days, I'll send out patches for BG4CT clk, dts for i2c, dw-apb timer
dw-spi and BG4CT cpuidle. And maybe usb 2.0 support.

Thanks for your time,
Jisheng
--
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] KVM: x86: emulate: correct page fault error code for NoWrite instructions

[Wanpeng Li]

2015-11-20 10:52 GMT+08:00 Wanpeng Li :
> Hi Paolo,
> 2015-02-09 17:03 GMT+08:00 Paolo Bonzini :
>> NoWrite instructions (e.g. cmp or test) never set the "write access"
>> bit in the error code, even if one of the operands is treated as a
>> destination.
>
> Sorry to reply to an old commit, btw, could you point out where in SDM
> describe above?

I see.
--
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] readlink()-related oddities

[Al Viro]

On Thu, Nov 19, 2015 at 07:16:32PM -0800, Linus Torvalds wrote:

> .. it's not necessarily just readlink() either. I still think it might
> be a perfectly fine idea to allow non-directories to act as
> directories in some case (by exposing "readdir" and "lookup").

As soon as we expose ->lookup(), we are in for serious PITA with locking.
Please, don't.  The situation is convoluted enough as it is; playing with
parallel lookups is going to be interesting in itself and I'd rather not
mix it with attempts to accomodate for hybrid objects (e.g. something
with children and more than one parent, etc.), especially since I'm not
sure the latter can be done without major pain.
--
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] readlink()-related oddities

[Linus Torvalds]

On Thu, Nov 19, 2015 at 7:09 PM, Linus Torvalds
 wrote:
>
> So there is *potential* for just making it generic, but that doesn't
> mean that it necessarily has to act that way.

.. it's not necessarily just readlink() either. I still think it might
be a perfectly fine idea to allow non-directories to act as
directories in some case (by exposing "readdir" and "lookup").

But readdir() really doesn't sound horrible either. how about unix
domain sockets (or named pipes) giving their link information when you
do readdir() on them?

Quite frankly, I think allowing those kinds of unified interfaces is
better than the current situation where you have to use a
"getpeername()" system call etc. If it's a filesystem object, why not
allow filesystem operations to work on it?

We expose some things in /proc as symlinks things that actually would
work better as non-symlinks, exactly *because* we want to expose not
just the end result of what they point to, but also a *description* of
what they point to. So we have those odd "pseudo-symlinks" in /proc
that don't actually really do a pathname walk on the symlink content
they expose, but still *look* like symlinks just because readdir() is
such a useful thing to have.

No wonder other users have wanted to use it.

Linus
--
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: Hit regression with TCP_TW REUSE/RECYCLE

[Ethan Zhao]

Eric,


On Tue, Nov 17, 2015 at 8:07 PM, Eric Dumazet  wrote:
> On Tue, 2015-11-17 at 14:35 +0800, Ethan Zhao wrote:
>> Tested the same case with 4.4-RC1, it was fixed in 4.4-RC1.
>> But don't know which commit fixed it.
>>
>>  # echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range
>>  # cat /proc/sys/net/ipv4/ip_local_port_range
>> 102465535
>>  # echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
>>  #  cat /proc/sys/net/ipv4/tcp_tw_reuse
>> 1
>>  # echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
>>  #  cat /proc/sys/net/ipv4/tcp_tw_reuse
>> 1
>>  # ./accept -n 5 -r &
>> [1] 11866
>>  # port: 7954
>> ninst: 5
>> reuseport: 1
>>
>>  # ./connect -i 127.0.0.1 -n 5 -d 10
>> 78578.50
>>  # uname -a
>> Linux localhost.localdomain 4.4.0-rc1 #49 SMP Tue Nov 17 15:04:18 KST
>> 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> Maybe run a reverse bisection ?

 Hmmm,  will do.
>
> tcp_tw_reuse and tcp_tw_recycle both set to one have never been
> supported in linux.
>
> tcp_tw_recycle - BOOLEAN
> Enable fast recycling TIME-WAIT sockets. Default value is 0.
> It should not be changed without advice/request of technical
> experts.
>
> tcp_tw_reuse - BOOLEAN
> Allow to reuse TIME-WAIT sockets for new connections when it is
> safe from protocol viewpoint. Default value is 0.
> It should not be changed without advice/request of technical
> experts.
>
> Thanks.
>
>

Thanks,
Ethan
--
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] loop: Enable correct physical blocksize

[Ming Lei]

On Tue, Nov 10, 2015 at 4:13 PM, Hannes Reinecke  wrote:
> When running on files the physical blocksize is actually 4k,
> so we should be announcing it as such. This is enabled with
> a new LO_FLAGS_BLOCKSIZE flag value to the existing
> loop_set_status ioctl.

LO_FLAGS_BLOCKSIZE is defined in patch 3/4, and you use
it too early in patch 1/4.

>
> Signed-off-by: Hannes Reinecke 
> ---
>  drivers/block/loop.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 423f4ca..e790487 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -233,6 +233,8 @@ figure_loop_size(struct loop_device *lo, loff_t offset, 
> loff_t sizelimit)
> lo->lo_offset = offset;
> if (lo->lo_sizelimit != sizelimit)
> lo->lo_sizelimit = sizelimit;
> +   if (lo->lo_flags & LO_FLAGS_BLOCKSIZE)
> +   blk_queue_physical_block_size(lo->lo_queue, lo->lo_blocksize);
> set_capacity(lo->lo_disk, x);
> bd_set_size(bdev, (loff_t)get_capacity(bdev->bd_disk) << 9);
> /* let user-space know about the new size */
> @@ -1092,6 +1094,7 @@ loop_set_status(struct loop_device *lo, const struct 
> loop_info64 *info)
> int err;
> struct loop_func_table *xfer;
> kuid_t uid = current_uid();
> +   int lo_flags = lo->lo_flags;
>
> if (lo->lo_encrypt_key_size &&
> !uid_eq(lo->lo_key_owner, uid) &&
> @@ -1121,8 +1124,12 @@ loop_set_status(struct loop_device *lo, const struct 
> loop_info64 *info)
> if (err)
> return err;
>
> +   if (info->lo_flags & LO_FLAGS_BLOCKSIZE)
> +   lo->lo_flags |= LO_FLAGS_BLOCKSIZE;
> +
> if (lo->lo_offset != info->lo_offset ||
> -   lo->lo_sizelimit != info->lo_sizelimit)
> +   lo->lo_sizelimit != info->lo_sizelimit ||
> +   lo->lo_flags != lo_flags)
> if (figure_loop_size(lo, info->lo_offset, info->lo_sizelimit))
> return -EFBIG;
>
> --
> 1.8.5.6
>



-- 
Ming Lei
--
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] readlink()-related oddities

[Linus Torvalds]

On Thu, Nov 19, 2015 at 6:57 PM, Al Viro  wrote:
>
> How would those tools know that this particular pathname _is_ a magical
> symlink?

Like maybe just the AFS management tools? By design you'd only run
them on the mountpoint in question.

Not everything has to be "generic". Sometimes its' good enough to just
have the ability to get the work done.

Now, if it turns out that others also want to do this, maybe somebody
decides "let's add flag -V to 'ls', which forces a 'readlink()' on all
the targets, whether links or not, and shows the information".

I could imagine other special files having "a single line of
information about the file" that they'd expose with readlink(). Who
knows?

So there is *potential* for just making it generic, but that doesn't
mean that it necessarily has to act that way.

Linus
--
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 13/11] mtd: assign mtd->dev.of_node when creating partition devices

[Brian Norris]

On Thu, Nov 12, 2015 at 02:22:20PM +0100, Boris Brezillon wrote:
> On Wed, 11 Nov 2015 16:15:50 -0800
> Brian Norris  wrote:
> > IOW, I think we can grab the reference in add_mtd_device() and drop it
> > in del_mtd_device(). This would handle both the partition and
> > non-partition case the same.
> 
> Hm, actually I think we need it. When you iterate over child nodes with
> for_each_child_of_node(), the node is released (of_node_put() is
> called) after each iteration. While this is not a problem for mtd
> device registration (because the controller usually retain the
> reference when add_mtd_device() is called), this is not true for the
> partitions. And if the partitions are ever defined using an overlay,
> this can be a problem.

Yep.

> To sum-up, I think we should retain the node reference until
> add_mtd_device() has retained it, so maybe we should have a ->cleanup()
> function in mtd part parsers.

OK. I'll drop my patch and send out my ->cleanup() stuff instead, so you
can patch on top of that.

Brian
--
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] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Jike Song]

On 11/19/2015 11:52 PM, Alex Williamson wrote:

On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:

On Thu, 19 Nov 2015, Jike Song wrote:

Hi Alex, thanks for the discussion.

In addition to Kevin's replies, I have a high-level question: can VFIO
be used by QEMU for both KVM and Xen?


No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
is owned by Xen.


Right, but in this case we're talking about device MMUs, which are owned
by the device driver which I think is running in dom0, right?  This
proposal doesn't require support of the system IOMMU, the dom0 driver
maps IOVA translations just as it would for itself.  We're largely
proposing use of the VFIO API to provide a common interface to expose a
PCI(e) device to QEMU, but what happens in the vGPU vendor device and
IOMMU backends is specific to the device and perhaps even specific to
the hypervisor.  Thanks,


Let me conclude this, and please correct me in case of any misread: the
vGPU interface between kernel and QEMU will be through VFIO, with a new
VFIO backend (instead of the existing type1), for both KVMGT and XenGT?




Alex



--
Thanks,
Jike
--
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] readlink()-related oddities

[Al Viro]

On Thu, Nov 19, 2015 at 06:13:53PM -0800, Linus Torvalds wrote:

> > 3) normally, readlink(2) fails for non-symlinks.  Moreover, according to
> > POSIX it should do so (with -EINVAL).
> 
> I don't think POSIX is necessarily relevant here.
> 
> We have had magic file behavior outside the scope of POSIX before, and
> we will have it in the future. It makes perfect sense to use
> readlink() for management tools for automounting, even if the normal
> oepration is to treat the thing as a directory.
> 
> Not everything is within the domain of POSIX.

How would those tools know that this particular pathname _is_ a magical
symlink?  Sure, if you see a symlink with body that starts with % or #,
you could figure out that it's not a regular one and go parse the body,
but for stat(2) it looks like a directory.  Do those tools call readlink()
on every directory they spot on AFS volume?  David?

And what's the story with magical ->open() for those?  How could one get
to ->open() on those sucker and avoid triggering the automount instead?
--
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 0/3] virtio DMA API core stuff

[Benjamin Herrenschmidt]

On Thu, 2015-11-19 at 23:38 +, David Woodhouse wrote:
> 
> I understand that POWER and other platforms don't currently have a
> clean way to indicate that certain device don't have translation. And I
> understand that we may end up with a *quirk* which ensures that the DMA
> API does the right thing (i.e. nothing) in certain cases.
> 
> But we should *NOT* be involving the virtio device drivers in that
> quirk, in any way. And putting a feature bit in the virtio device
> itself doesn't seem at all sane either.
> 
> Bear in mind that qemu-system-x86_64 currently has the *same* problem
> with assigned physical devices. It's claiming they're translated, and
> they're not.

It's not that clear but yeah ... as I mentioned, I can't find a
way to do that quirk that won't break when we want to actually use
the iommu... 

Ben.

--
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 perf/core 03/13] perf: Introduce generic refcount APIs with debug feature

[Namhyung Kim]

On Wed, Nov 18, 2015 at 03:40:16PM +0900, Masami Hiramatsu wrote:
> This is a kind of debugging feature for atomic reference counter.
> The reference counters are widely used in perf tools but not well
> debugged. It sometimes causes memory leaks but no one has noticed
> the issue, since it is hard to debug such un-reclaimed objects.
> 
> This refcnt interface provides fully backtrace debug feature to
> analyze such issue. User just replace atomic_t ops with refcnt
> APIs and add refcnt__exit() where the object is released.
> 
> /* At object initializing */
> refcnt__init(obj, refcnt); /* <- atomic_set(>refcnt, 1); */
> 
> /* At object get method */
> refcnt__get(obj, refcnt); /* <- atomic_inc(>refcnt); */
> 
> /* At object put method */
> if (obj && refcnt__put(obj, refcnt)) /* <-atmoic_dec_and_test(>refcnt)*/
> 
> /* At object releasing */
> refcnt__exit(obj, refcnt); /* <- Newly added */
> 
> The debugging feature is enabled when building perf with
> REFCNT_DEBUG=1. Otherwides it is just translated as normal
> atomic ops.
> 
> Debugging binary warns you if it finds leaks when the perf exits.
> If you give -v (or --verbose) to the perf, it also shows backtrace
> logs on all refcnt operations of leaked objects.
> 
> Signed-off-by: Masami Hiramatsu 

Looks really useful!

Acked-by: Namhyung Kim 

Just a nitpick below..


> ---

[SNIP]
> +void refcnt_object__record(void *obj, const char *name, int count)
> +{
> + struct refcnt_object *ref = refcnt__find_object(obj);
> + struct refcnt_buffer *buf;
> +
> + /* If no entry, allocate new one */
> + if (!ref) {
> + ref = malloc(sizeof(*ref));
> + if (!ref) {
> + pr_debug("REFCNT: Out of memory for %p (%s)\n",
> +  obj, name);
> + return;
> + }
> + INIT_LIST_HEAD(>list);
> + INIT_LIST_HEAD(>head);
> + ref->name = name;
> + ref->obj = obj;
> + list_add_tail(>list, _root);
> + }
> +
> + buf = malloc(sizeof(*buf));
> + if (!buf) {
> + pr_debug("REFCNT: Out of memory for %p (%s)\n", obj, ref->name);
> + return;
> + }
> +
> + INIT_LIST_HEAD(>list);
> + buf->count = count;
> + buf->nr = backtrace(buf->buf, BACKTRACE_SIZE);
> + list_add_tail(>list, >head);
> +}
> +
> +static void pr_refcnt_buffer(struct refcnt_buffer *buf)
> +{
> + char **symbuf;
> + int i;
> +
> + if (!buf)
> + return;
> + symbuf = backtrace_symbols(buf->buf, buf->nr);

It seems you need to check the return value.  Maybe we can use
backtrace_symbols_fd() instead, or just in case of an error.

Thanks,
Namhyung


> + /* Skip the first one because it is always btrace__record */
> + for (i = 1; i < buf->nr; i++)
> + pr_debug("  %s\n", symbuf[i]);
> + free(symbuf);
> +}
> +
> +void refcnt__dump_unreclaimed(void) __attribute__((destructor));
> +void refcnt__dump_unreclaimed(void)
> +{
> + struct refcnt_object *ref, *n;
> + struct refcnt_buffer *buf;
> + int i = 0;
> +
> + if (list_empty(_root))
> + return;
> +
> + pr_warning("REFCNT: BUG: Unreclaimed objects found.\n");
> + list_for_each_entry_safe(ref, n, _root, list) {
> + pr_debug(" [%d] \nUnreclaimed %s: %p\n", i,
> +  ref->name ? ref->name : "(object)", ref->obj);
> + list_for_each_entry(buf, >head, list) {
> + pr_debug("Refcount %s => %d at\n",
> +  buf->count > 0 ? "+1" : "-1",
> +  buf->count > 0 ? buf->count : -buf->count - 1);
> + pr_refcnt_buffer(buf);
> + }
> + __refcnt_object__delete(ref);
> + i++;
> + }
> + pr_warning("REFCNT: Total %d objects are not reclaimed.\n", i);
> + if (!verbose)
> + pr_warning("   To see all backtraces, rerun with -v option\n");
> +}
--
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] KVM: x86: emulate: correct page fault error code for NoWrite instructions

[Wanpeng Li]

Hi Paolo,
2015-02-09 17:03 GMT+08:00 Paolo Bonzini :
> NoWrite instructions (e.g. cmp or test) never set the "write access"
> bit in the error code, even if one of the operands is treated as a
> destination.

Sorry to reply to an old commit, btw, could you point out where in SDM
describe above?

Regards,
Wanpeng Li
--
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] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Jike Song]

On 11/19/2015 07:09 PM, Paolo Bonzini wrote:

On 19/11/2015 09:40, Gerd Hoffmann wrote:

But this code should be
minor to be maintained in libvirt.

As far I know libvirt only needs to discover those devices.  If they
look like sr/iov devices in sysfs this might work without any changes to
libvirt.


I don't think they will look like SR/IOV devices.

The interface may look a little like the sysfs interface that GVT-g is
already using.  However, it should at least be extended to support
multiple vGPUs in a single VM.  This might not be possible for Intel
integrated graphics, but it should definitely be possible for discrete
graphics cards.


Didn't hear about multiple vGPUs for a single VM before. Yes If we
expect same vGPU interfaces for different vendors, abstraction and
vendor specific stuff should be implemented.



Another nit is that the VM id should probably be replaced by a UUID
(because it's too easy to stumble on an existing VM id), assuming a VM
id is needed at all.


For the last assumption, yes, a VM id is not necessary for gvt-g, it's
only a temporary implementation.

As long as libvirt is used, UUID should be enough for gvt-g. However,
UUID is not mandatory? What should we do if user don't specify an UUID
in QEMU cmdline?



Paolo



--
Thanks,
Jike
--
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/04] pinctrl: sh-pfc: r8a7794: DU support

[Laurent Pinchart]

Hi Magnus,

Thank you for the patch.

On Tuesday 17 November 2015 12:18:32 Magnus Damm wrote:
> pinctrl: sh-pfc: r8a7794: DU support
> 
> [PATCH 01/04] pinctrl: sh-pfc: r8a7794: Add DU pin groups
> [PATCH 02/04] pinctrl: sh-pfc: r8a7794: Separate DU CDE and DISP
> [PATCH 03/04] pinctrl: sh-pfc: r8a7794: Add missing dot clock signals
> [PATCH 04/04] pinctrl: sh-pfc: r8a7794: Break out ODDF from sync
> 
> These patches take the r8a7794 PFC DU support code from the BSP
> and reworks it to fit the r8a7794 ALT board. Tested with the ALT
> VGA port - by default PFC is not used however enabling PFC using
> an incremental (yet to be posted) patch works well.
> 
> It is worth noting that patch 2-4 modifies the pin groups. This
> means that the upstream DT ABI for PFC DU will differ compared
> to the unreviewed BSP code.
> 
> In general it is not considered good practice to change the pin
> groups and break compatibility since they are part of the DT ABI.
> 
> For this particular case upstream never have had PFC DU support
> for r8a7794, so treating the BSP bindings as experimental and
> migrate away seems reasonable.

If we start considering DT bindings that never went upstream as stable we'll 
have a big problem. I mean even bigger than the upstream DT bindings stability 
problem :-)

> Signed-off-by: Magnus Damm 

Wouldn't it make sense to merge the 4 patches together ?

> ---
> 
>  Written against v4.4-rc1
> 
>  drivers/pinctrl/sh-pfc/pfc-r8a7794.c |  282 +++
>  1 file changed, 252 insertions(+), 30 deletions(-)

-- 
Regards,

Laurent Pinchart

--
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: tulip: update MAINTAINER status to Orphan

[Grant Grundler]

On Thu, Nov 19, 2015 at 6:29 PM, Florian Fainelli  wrote:
> On 19/11/15 17:56, Grant Grundler wrote:
>> From: Grant Grundler 
>>
>> I haven't had any PCI tulip HW for the past ~5 years. I have
>> been reviewing tulip patches and can continue doing that.
>>
>> Signed-off-by: Grant Grundler 
>> ---
>> I'm also proposing to add linux-parisc to the list since AFAIK, all
>> parisc systems but the C8000 workstations (PA8800/PA8900 CPU)
>> use tulip for onboard LAN.
>>
>> Specific mips and alpha systems also care about tulip driver too.
>> But I don't know either well enough to suggest respective mailing
>> lists should see every tulip patch.
>
> For MIPS, is not Cobalt the primary (and sole) user?

Once upon a time a Mips based router was using tulip as well. I know
they needed to "borrow" some tulip patches that were only in
parisc-linux source tree (for reasons I don't see a need to repeat
here).

> You could add linux-m...@linux-mips.org if that helps.

I wanted to let the mips folks decide if they should be listedand
CC'd Helga (parisc maintainer) in case he objected to added
linux-parisc mailing list.

cheers,
grant

> My Cobalt stayed behind me when
> I moved to the US, so outside of Yoichi, I am not sure who else cares
> these days...
>
>>
>>  MAINTAINERS | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index ea17512..ec07061 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -10888,9 +10888,9 @@ S:Maintained
>>  F:   drivers/media/tuners/tua9001*
>>
>>  TULIP NETWORK DRIVERS
>> -M:   Grant Grundler 
>>  L:   net...@vger.kernel.org
>> -S:   Maintained
>> +L:   linux-par...@vger.kernel.org
>> +S:   Orphan
>>  F:   drivers/net/ethernet/dec/tulip/
>>
>>  TUN/TAP driver
>>
>
>
> --
> Florian
--
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 v4] watchdog: add support for Sigma Designs SMP86xx/SMP87xx

[Måns Rullgård]

Guenter Roeck  writes:

> On 11/19/2015 02:09 PM, Mans Rullgard wrote:
>> This adds support for the Sigma Designs SMP86xx/SMP87xx family built-in
>> watchdog.
>>
>> Signed-off-by: Mans Rullgard 
>
> Reviewed-by: Guenter Roeck 
>
> Did you send the bindings document to some other mailing list (only) ?
> I see "PATCH 2/2" in some of your submissions, but I seem to be missing
> patch 1/2.

Blame scripts/get_maintaintainer.pl for that.  Anyway, here it is:
http://article.gmane.org/gmane.linux.drivers.devicetree/144423

-- 
Måns Rullgård
m...@mansr.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] sp5100_tco: Add AMD Mullins platform support

[Huang Rui]

Hi Denis,

On Thu, Nov 19, 2015 at 05:56:00PM +0800, Denis Turischev wrote:
> AMD Mullins watchdog is fully compatible to the previous Hudson chipset,
> reuse the existent sp5100_tco driver.
> 

Thank you to add this support!
Actually, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS is only the SMBus device id
on AMD mullins but also on many other AMD platforms. Could you please
share some test method to me, that I am glad to do some quick tests. :)

Thanks,
Rui

> Signed-off-by: Denis Turischev 
> 
> diff -Nru linux-4.3.orig/drivers/watchdog/sp5100_tco.c 
> linux-4.3/drivers/watchdog/sp5100_tco.c
> --- linux-4.3.orig/drivers/watchdog/sp5100_tco.c  2015-11-02 
> 02:05:25.0 +0200
> +++ linux-4.3/drivers/watchdog/sp5100_tco.c   2015-11-19 11:08:06.27218 
> +0200
> @@ -306,6 +306,8 @@
>  static const struct pci_device_id sp5100_tco_pci_tbl[] = {
>   { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, PCI_ANY_ID,
> PCI_ANY_ID, },
> + { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, PCI_ANY_ID,
> +   PCI_ANY_ID, },
>   { 0, }, /* End of list */
>  };
>  MODULE_DEVICE_TABLE(pci, sp5100_tco_pci_tbl);
> --
> 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/
--
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/2] keys, trusted: seal with a policy

[James Morris]

On Wed, 18 Nov 2015, Jarkko Sakkinen wrote:

> On Wed, Nov 18, 2015 at 11:21:01AM +1100, James Morris wrote:
> > On Tue, 17 Nov 2015, Jarkko Sakkinen wrote:
> > 
> > >   }
> > >   break;
> > > + case Opt_policydigest:
> > > + if (!tpm2 ||
> > > + strlen(args[0].from) != (2 * opt->digest_len))
> > > + return -EINVAL;
> > > + kfree(opt->policydigest);
> > > + opt->policydigest = kzalloc(opt->digest_len,
> > > + GFP_KERNEL);
> > 
> > Is it correct to kfree opt->policydigest here before allocating it?
> 
> I think so. The same option might be encountered multiple times.

This would surely signify an error?


-- 
James Morris


--
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 V5 RESEND 3/3] arm64: dts: Add dts node for hi6220 smmu driver

[Chen Feng]

Add iommu node for hi6220 SoC platform

Signed-off-by: Chen Feng 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 82d2488..589424a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -208,5 +208,18 @@
clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
+
+   iommu: iommu@f421 {
+   compatible = "hisilicon,hi6220-smmu";
+   reg = <0x0 0xf421 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_ctrl HI6220_MMU_CLK>,
+<_ctrl HI6220_MED_MMU>,
+<_ctrl HI6220_MEDIA_PLL_SRC>;
+   clock-names = "smmu",
+ "media-sc",
+ "smmu-peri";
+   #iommu-cells = <0>;
+   };
};
 };
-- 
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 V5 RESEND 0/3] Add iommu support for hi6220 HiKey board

[Chen Feng]

The patch sets add iommu support for Hi6220 SoC. Current testing and support
board is Hikey which is one of 96boards.
It is an arm64 open source board. For more information about this board,
please access https://www.96boards.org.

The Architecture of SMMU on Hi6220 SoC:

   +--+
   |  |
   | +-+  ++  +-+   +---+ |
   | |   ADE   |  |  ISP   |  |  V/J codec  |   |  G3D  | |
   | +|+  +---|+  +--|--+   +---|---| |
   |  |   |  |  | |
   | -v---v--v--v-|
   |   Media Bus  |
   | |---||
   | |   ||
   | +---v---v+   |
   | |SMMU|   |
   | +--|-|---+   |
   || |   |
   +|-|---+
| |
   +v-v---+
   |  DDRC|
   +--+
Note:
The media system share the same smmu IP to access DDR memory. And all
media IP use the same page table. The hi6220 iommu driver also uses the
iova api to manage an iova allocator to ensure that the caller get different
iova address.
The caller can use the follow sample code to map phy and iova address.

eg:
struct iommu_domain *domain = iommu_domain_alloc(bus);
iommu_attach_device(domain, dev);
struct iova_domain *iovad = (struct iova_domain *)m_dev->archdata.iommu;
struct iova * t_iova = alloc_iova(iovad, size, limit_pfn, align);
iommu_map(domain, t_iova->pfn_lo << 12, phy_addr, size, port);

The patch sets are based on 4.4-RC1

V2: Fix tlb flush when unmap
V3: Fix format issue and iova address range
V5: Add cover-letter and resend to dt maillist

Chen Feng (3):
  docs: iommu: Documentation for iommu in hi6220 SoC
  iommu/hisilicon: Add hi6220-SoC smmu driver
  arm64: dts: Add dts node for hi6220 smmu driver

 .../bindings/iommu/hisi,hi6220-iommu.txt   |  32 ++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  13 +
 drivers/iommu/Kconfig  |  11 +
 drivers/iommu/Makefile |   1 +
 drivers/iommu/hi6220_iommu.c   | 492 +
 5 files changed, 549 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
 create mode 100644 drivers/iommu/hi6220_iommu.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 V5 RESEND 2/3] iommu/hisilicon: Add hi6220-SoC smmu driver

[Chen Feng]

Add iommu driver for hi6220 SoC platform.The smmu on hi6220
SoC is for media system.And the media IP use the same page-table.
It supports only one-to-one mapping from iova to phys address.

Signed-off-by: Chen Feng 
---
 drivers/iommu/Kconfig|  11 +
 drivers/iommu/Makefile   |   1 +
 drivers/iommu/hi6220_iommu.c | 492 +++
 3 files changed, 504 insertions(+)
 create mode 100644 drivers/iommu/hi6220_iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index b9094e9..7c13521 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -84,6 +84,17 @@ config IOMMU_PGTABLES_L2
def_bool y
depends on MSM_IOMMU && MMU && SMP && CPU_DCACHE_DISABLE=n
 
+config HI6220_IOMMU
+   bool "Hi6220 IOMMU Support"
+   depends on ARM64
+   select IOMMU_API
+   select IOMMU_IOVA
+   help
+ Enable IOMMU Driver for hi6220 SoC. The IOMMU API and IOMMU IOVA
+ is also selected.
+
+ If unsure, say N.
+
 # AMD IOMMU support
 config AMD_IOMMU
bool "AMD IOMMU support"
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 68faca02..cdb2b83 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o
 obj-$(CONFIG_ARM_SMMU) += arm-smmu.o
 obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
 obj-$(CONFIG_DMAR_TABLE) += dmar.o
+obj-$(CONFIG_HI6220_IOMMU) += hi6220_iommu.o
 obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o
 obj-$(CONFIG_INTEL_IOMMU_SVM) += intel-svm.o
 obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
diff --git a/drivers/iommu/hi6220_iommu.c b/drivers/iommu/hi6220_iommu.c
new file mode 100644
index 000..fd74f29
--- /dev/null
+++ b/drivers/iommu/hi6220_iommu.c
@@ -0,0 +1,492 @@
+/*
+ * Hisilicon Hi6220 IOMMU driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Chen Feng 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) "IOMMU: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SMMU_CTRL_OFFSET (0x)
+#define SMMU_ENABLE_OFFSET   (0x0004)
+#define SMMU_PTBR_OFFSET (0x0008)
+#define SMMU_START_OFFSET(0x000C)
+#define SMMU_END_OFFSET  (0x0010)
+#define SMMU_INTMASK_OFFSET  (0x0014)
+#define SMMU_RINTSTS_OFFSET  (0x0018)
+#define SMMU_MINTSTS_OFFSET  (0x001C)
+#define SMMU_INTCLR_OFFSET   (0x0020)
+#define SMMU_STATUS_OFFSET   (0x0024)
+#define SMMU_AXIID_OFFSET(0x0028)
+#define SMMU_CNTCTRL_OFFSET  (0x002C)
+#define SMMU_TRANSCNT_OFFSET (0x0030)
+#define SMMU_L0TLBHITCNT_OFFSET  (0x0034)
+#define SMMU_L1TLBHITCNT_OFFSET  (0x0038)
+#define SMMU_WRAPCNT_OFFSET  (0x003C)
+#define SMMU_SEC_START_OFFSET(0x0040)
+#define SMMU_SEC_END_OFFSET  (0x0044)
+#define SMMU_VERSION_OFFSET  (0x0048)
+#define SMMU_IPTSRC_OFFSET   (0x004C)
+#define SMMU_IPTPA_OFFSET(0x0050)
+#define SMMU_TRBA_OFFSET (0x0054)
+#define SMMU_BYS_START_OFFSET(0x0058)
+#define SMMU_BYS_END_OFFSET  (0x005C)
+#define SMMU_RAM_OFFSET  (0x1000)
+
+#define SMMU_CTRL_INVALID(BIT(10))
+#define SMMU_SR_REGS_NUM (15)
+#define SMMU_REGS_SGMT_END   (0x60)
+#define PAGE_ENTRY_VALID (0x1)
+#define IOPAGE_SHIFT (12)
+#define IOVA_PFN(addr)   ((addr) >> IOPAGE_SHIFT)
+#define IOVA_PAGE_SZ (SZ_4K)
+
+/**
+ * The iova address from 0 ~ 2G
+ */
+#define IOVA_START   (0x0)
+#define IOVA_END (0x8000)
+
+struct hi6220_smmu {
+   unsigned int irq;
+   void __iomem *reg_base;
+   struct clk *smmu_peri_clk;
+   struct clk *smmu_clk;
+   struct clk *media_sc_clk;
+   spinlock_t spinlock; /*spinlock for tlb invalid*/
+   dma_addr_t pgtable_phy;
+   void *pgtable_virt;
+   u32  pgtable_size;
+   u32  *sr_data;
+};
+
+struct hi6220_domain {
+   struct hi6220_smmu *smmu_dev;
+   struct iommu_domain io_domain;
+};
+
+static struct hi6220_smmu *smmu_dev_handle;
+static struct iova_domain iova_allocator;
+
+static struct hi6220_domain *to_hi6220_domain(struct iommu_domain *dom)
+{
+   return container_of(dom, struct hi6220_domain, io_domain);
+}
+
+static inline void __smmu_writel(struct hi6220_smmu *smmu_dev, u32 value,
+unsigned long offset)
+{
+   writel(value, smmu_dev->reg_base + offset);
+}
+
+static inline u32 __smmu_readl(struct hi6220_smmu *smmu_dev,
+  unsigned long offset)
+{
+   return readl(smmu_dev->reg_base + offset);

Re: [PATCH] net: tulip: update MAINTAINER status to Orphan

[Florian Fainelli]

On 19/11/15 17:56, Grant Grundler wrote:
> From: Grant Grundler 
> 
> I haven't had any PCI tulip HW for the past ~5 years. I have
> been reviewing tulip patches and can continue doing that.
> 
> Signed-off-by: Grant Grundler 
> ---
> I'm also proposing to add linux-parisc to the list since AFAIK, all
> parisc systems but the C8000 workstations (PA8800/PA8900 CPU)
> use tulip for onboard LAN.
> 
> Specific mips and alpha systems also care about tulip driver too.
> But I don't know either well enough to suggest respective mailing
> lists should see every tulip patch.

For MIPS, is not Cobalt the primary (and sole) user? You could add
linux-m...@linux-mips.org if that helps. My Cobalt stayed behind me when
I moved to the US, so outside of Yoichi, I am not sure who else cares
these days...

> 
>  MAINTAINERS | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea17512..ec07061 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10888,9 +10888,9 @@ S:Maintained
>  F:   drivers/media/tuners/tua9001*
>  
>  TULIP NETWORK DRIVERS
> -M:   Grant Grundler 
>  L:   net...@vger.kernel.org
> -S:   Maintained
> +L:   linux-par...@vger.kernel.org
> +S:   Orphan
>  F:   drivers/net/ethernet/dec/tulip/
>  
>  TUN/TAP driver
> 


-- 
Florian
--
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 V5 RESEND 1/3] docs: iommu: Documentation for iommu in hi6220 SoC

[Chen Feng]

Documentation for hi6220 iommu driver.

Signed-off-by: Chen Feng 
---
 .../bindings/iommu/hisi,hi6220-iommu.txt   | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt 
b/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
new file mode 100644
index 000..44f9101
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
@@ -0,0 +1,32 @@
+Hi6220 SoC SMMU Device Driver devicetree document
+The media system shared the same smmu IP to access DDR memory. And all
+media IP used the same page table.
+
+Below binding describes the system mmu for media system in hi6220 platform
+
+Required properties:
+- compatible: should contain "hisilicon,hi6220-smmu".
+- reg: A tuple of base address and size of System MMU registers.
+- clocks: a list of phandle + clock-specifier pairs, one for each entry
+  in clock-names.
+- clock-names: should contain:
+  * "smmu"
+  * "media-sc"
+  * "smmu-peri"
+- interrupts: An interrupt specifier for interrupt signal of System MMU.
+- #iommu-cells: The iommu-cells should be 0. Because no additional information
+  needs to be encoded in the specifier.
+
+Examples:
+   iommu@f421 {
+   compatible = "hisilicon,hi6220-smmu";
+   reg = <0x0 0xf421 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_ctrl HI6220_MMU_CLK>,
+<_ctrl HI6220_MED_MMU>,
+<_ctrl HI6220_MEDIA_PLL_SRC>;
+   clock-names = "smmu",
+ "media-sc",
+ "smmu-peri";
+   #iommu-cells = <0>;
+   };
-- 
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 v4] watchdog: add support for Sigma Designs SMP86xx/SMP87xx

[Guenter Roeck]

On 11/19/2015 02:09 PM, Mans Rullgard wrote:

This adds support for the Sigma Designs SMP86xx/SMP87xx family built-in
watchdog.

Signed-off-by: Mans Rullgard 


Reviewed-by: Guenter Roeck 

Did you send the bindings document to some other mailing list (only) ?
I see "PATCH 2/2" in some of your submissions, but I seem to be missing
patch 1/2.

Thanks,
Guenter


---
Changes:
- #include bitops.h
- clk_disable_unprepare() on failure
---
  drivers/watchdog/Kconfig  |  10 ++
  drivers/watchdog/Makefile |   1 +
  drivers/watchdog/tangox_wdt.c | 225 ++
  3 files changed, 236 insertions(+)
  create mode 100644 drivers/watchdog/tangox_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 7a8a6c6..f43ff7a 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -135,6 +135,16 @@ config MENF21BMC_WATCHDOG
  This driver can also be built as a module. If so the module
  will be called menf21bmc_wdt.

+config TANGOX_WATCHDOG
+   tristate "Sigma Designs SMP86xx/SMP87xx watchdog"
+   select WATCHDOG_CORE
+   depends on ARCH_TANGOX || COMPILE_TEST
+   help
+ Support for the watchdog in Sigma Designs SMP86xx (tango3)
+ and SMP87xx (tango4) family chips.
+
+ This driver can be built as a module. The module name is tangox_wdt.
+
  config WM831X_WATCHDOG
tristate "WM831x watchdog"
depends on MFD_WM831X
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 53d4827..46cb387 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -187,6 +187,7 @@ obj-$(CONFIG_DA9055_WATCHDOG) += da9055_wdt.o
  obj-$(CONFIG_DA9062_WATCHDOG) += da9062_wdt.o
  obj-$(CONFIG_DA9063_WATCHDOG) += da9063_wdt.o
  obj-$(CONFIG_GPIO_WATCHDOG)   += gpio_wdt.o
+obj-$(CONFIG_TANGOX_WATCHDOG) += tangox_wdt.o
  obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
  obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
  obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
diff --git a/drivers/watchdog/tangox_wdt.c b/drivers/watchdog/tangox_wdt.c
new file mode 100644
index 000..b9ee624
--- /dev/null
+++ b/drivers/watchdog/tangox_wdt.c
@@ -0,0 +1,225 @@
+/*
+ *  Copyright (C) 2015 Mans Rullgard 
+ *  SMP86xx/SMP87xx Watchdog driver
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under  the terms of the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the License, or (at your
+ *  option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_TIMEOUT 30
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout,
+"Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static unsigned int timeout;
+module_param(timeout, int, 0);
+MODULE_PARM_DESC(timeout, "Watchdog timeout");
+
+/*
+ * Counter counts down from programmed value.  Reset asserts when
+ * the counter reaches 1.
+ */
+#define WD_COUNTER 0
+
+#define WD_CONFIG  4
+#define WD_CONFIG_XTAL_IN  BIT(0)
+#define WD_CONFIG_DISABLE  BIT(31)
+
+struct tangox_wdt_device {
+   struct watchdog_device wdt;
+   void __iomem *base;
+   unsigned long clk_rate;
+   struct clk *clk;
+   struct notifier_block restart;
+};
+
+static int tangox_wdt_set_timeout(struct watchdog_device *wdt,
+ unsigned int new_timeout)
+{
+   wdt->timeout = new_timeout;
+
+   return 0;
+}
+
+static int tangox_wdt_start(struct watchdog_device *wdt)
+{
+   struct tangox_wdt_device *dev = watchdog_get_drvdata(wdt);
+   u32 ticks;
+
+   ticks = 1 + wdt->timeout * dev->clk_rate;
+   writel(ticks, dev->base + WD_COUNTER);
+
+   return 0;
+}
+
+static int tangox_wdt_stop(struct watchdog_device *wdt)
+{
+   struct tangox_wdt_device *dev = watchdog_get_drvdata(wdt);
+
+   writel(0, dev->base + WD_COUNTER);
+
+   return 0;
+}
+
+static unsigned int tangox_wdt_get_timeleft(struct watchdog_device *wdt)
+{
+   struct tangox_wdt_device *dev = watchdog_get_drvdata(wdt);
+   u32 count;
+
+   count = readl(dev->base + WD_COUNTER);
+
+   if (!count)
+   return 0;
+
+   return (count - 1) / dev->clk_rate;
+}
+
+static const struct watchdog_info tangox_wdt_info = {
+   .options  = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
+   .identity = "tangox watchdog",
+};
+
+static const struct watchdog_ops tangox_wdt_ops = {
+   .start  = tangox_wdt_start,
+   .stop   = tangox_wdt_stop,
+   .set_timeout= tangox_wdt_set_timeout,
+   .get_timeleft   = tangox_wdt_get_timeleft,
+};
+
+static int tangox_wdt_restart(struct notifier_block *nb, unsigned long action,
+ 

Re: [PATCH] perf test: Add bpf-output event

[Wangnan (F)]

On 2015/11/20 7:29, Sukadev Bhattiprolu wrote:

Wangnan (F) [wangn...@huawei.com] wrote:
|
|
| On 2015/11/19 7:14, Alexei Starovoitov wrote:
| >On Wed, Nov 18, 2015 at 05:50:39PM -0300, Arnaldo Carvalho de Melo wrote:
| >>Em Wed, Nov 18, 2015 at 11:26:04AM -0800, Sukadev Bhattiprolu escreveu:
| From 8f71d55dd3e27e6ca2138e3ed6dfeceb1c00a426 Mon Sep 17 00:00:00 2001
| >>>From: Sukadev Bhattiprolu 
| >>>Date: Wed, 18 Nov 2015 19:06:08 -0500
| >>>Subject: [PATCH] perf test: Add bpf-output event
| >>>
| >>>The kernel has added support for 'PERF_COUNT_SW_BPF_OUTPUT' but that is
| >>>missing from the perf tool. Among other things, results in the 'roundtrip
| >>>evsel->name check' test case of 'perf test' failing on Powerpc.
| >>Next time can you please state if this is for this merge window or for
| >>the next?
| >>
| >>Will apply it for perf/core, for the next merge window.
| >wait a sec, I believe Wang has posted an RFC a month ago that adds support
| >for this properly instead of simply shutting up the error.
|
| Yes. Please have a look at
|
| 
http://lkml.kernel.org/g/1446029705-199659-3-git-send-email-wangn...@huawei.com
|
| and patch 23/31 - 31/31 in
|
| http://lkml.kernel.org/g/1444826502-49291-1-git-send-email-wangn...@huawei.com
|
| We are working on a solution which truly utilizes bpf-output, including
| filling event array and extracting BPF output through perf data to CTF
| format. Now they are separated in multiple patchset, and I'd like to
| resend them to Arnaldo in this week.

Ok. It looked like there was development going on around BPF so I put
in the stubs to avoid false positives in the perf test.  There is a BPF
filter test case that is also getting Skipped. Would this patchset address
that too?


Do you mean this?

$ ./perf test bpf
37: Test BPF filter  :
37.1: Test basic BPF filtering   : Skip

To make it pass you need to build BPF compiling environment first.

First of all you must be root:

$ ./perf test -v bpf
37: Test BPF filter  :
37.1: Test basic BPF filtering   :
--- start ---
test child forked, pid 19359
Only root can run BPF test
test child finished with -2
 end 
Test BPF filter subtest 0: Skip


Then it would tell you how to setup your LLVM environment:

$ sudo -s
# ./perf test -v bpf
37: Test BPF filter  :
37.1: Test basic BPF filtering   :
--- start ---
test child forked, pid 19463
ERROR:unable to find clang.
Hint:Try to install latest clang/llvm to support BPF. Check your $PATH
 and 'clang-path' option in [llvm] section of ~/.perfconfig.
 LLVM 3.7 or newer is required. Which can be found from 
http://llvm.org

 You may want to try git trunk:
 git clone http://llvm.org/git/llvm.git
  and
 git clone http://llvm.org/git/clang.git

 Or fetch the latest clang/llvm 3.7 from pre-built llvm 
packages for

 debian/ubuntu:
 http://llvm.org/apt

 If you are using old version of clang, change 
'clang-bpf-cmd-template'

 option in [llvm] section of ~/.perfconfig to:

   "$CLANG_EXEC $CLANG_OPTIONS $KERNEL_INC_OPTIONS \
  -working-directory $WORKING_DIR -c $CLANG_SOURCE \
  -emit-llvm -o - | /path/to/llc -march=bpf -filetype=obj -o -"
 (Replace /path/to/llc with path to your llc)

Failed to compile test case: 'Basic BPF llvm compiling test'
Unable to get BPF object, fix 'perf test LLVM' first
test child finished with -2
 end 
Test BPF filter subtest 0: Skip


Set your clang path to ~/.perfconfig

# cat ~/.perfconfig
[llvm]
clang-path = "/opt/llvm-3.7.0/x86_64-oe-linux-clang"

Then try 'perf test LLVM', fix all failure:

# ./perf test LLVM
35: Test LLVM searching and compiling:
35.1: Basic BPF llvm compiling test  : Ok
35.2: Test kbuild searching  : Ok
35.3: Compile source for BPF prologue generation test: Ok

After that you can try perf test BPF:

# ./perf test BPF
37: Test BPF filter  :
37.1: Test basic BPF filtering   : Ok
37.2: Test BPF prologue generation   : Ok

Thank you.


--
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] spi: mediatek: remove unrequired description

[Leilk Liu]

cs-gpios isn't required with patch "spi: mediatek: single
device does not require cs_gpios", so modify the description.

Signed-off-by: Leilk Liu 
---
 .../devicetree/bindings/spi/spi-mt65xx.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt 
b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
index fba8334..60a183c 100644
--- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
+++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
@@ -29,7 +29,7 @@ Required properties:
   muxes clock, and "spi-clk" for the clock gate.
 
 Optional properties:
--cs-gpios: see spi-bus.txt, only required for MT8173.
+-cs-gpios: see spi-bus.txt.
 
 - mediatek,pad-select: specify which pins group(ck/mi/mo/cs) spi
   controller used. This is an array, the element value should be 0~3,
-- 
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/

[PATCH 4/4] spi: mediatek: revise mtk_spi_probe() failure flow

[Leilk Liu]

This patch revises failure flow while pm_runtime_enable().

Signed-off-by: Leilk Liu 
---
 drivers/spi/spi-mt65xx.c |   15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 6c1a96e..00a36da 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -607,7 +607,8 @@ static int mtk_spi_probe(struct platform_device *pdev)
ret = clk_set_parent(mdata->sel_clk, mdata->parent_clk);
if (ret < 0) {
dev_err(>dev, "failed to clk_set_parent (%d)\n", ret);
-   goto err_disable_clk;
+   clk_disable_unprepare(mdata->spi_clk);
+   goto err_put_master;
}
 
clk_disable_unprepare(mdata->spi_clk);
@@ -617,7 +618,7 @@ static int mtk_spi_probe(struct platform_device *pdev)
ret = devm_spi_register_master(>dev, master);
if (ret) {
dev_err(>dev, "failed to register master (%d)\n", ret);
-   goto err_put_master;
+   goto err_disable_runtime_pm;
}
 
if (mdata->dev_comp->need_pad_sel) {
@@ -626,14 +627,14 @@ static int mtk_spi_probe(struct platform_device *pdev)
"pad_num does not match num_chipselect(%d != 
%d)\n",
mdata->pad_num, master->num_chipselect);
ret = -EINVAL;
-   goto err_put_master;
+   goto err_disable_runtime_pm;
}
 
if (!master->cs_gpios && master->num_chipselect > 1) {
dev_err(>dev,
"cs_gpios not specified and num_chipselect > 
1\n");
ret = -EINVAL;
-   goto err_put_master;
+   goto err_disable_runtime_pm;
}
 
if (master->cs_gpios) {
@@ -644,7 +645,7 @@ static int mtk_spi_probe(struct platform_device *pdev)
if (ret) {
dev_err(>dev,
"can't get CS GPIO %i\n", i);
-   goto err_put_master;
+   goto err_disable_runtime_pm;
}
}
}
@@ -652,8 +653,8 @@ static int mtk_spi_probe(struct platform_device *pdev)
 
return 0;
 
-err_disable_clk:
-   clk_disable_unprepare(mdata->spi_clk);
+err_disable_runtime_pm:
+   pm_runtime_disable(>dev);
 err_put_master:
spi_master_put(master);
 
-- 
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/

[PATCH 3/4] spi: mediatek: remove needless pair of writel()/readl()

[Leilk Liu]

It's not need to re-read and re-write SPI_CMD_REG, so remove it.

Signed-off-by: Leilk Liu 
---
 drivers/spi/spi-mt65xx.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 7840067..6c1a96e 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -154,9 +154,6 @@ static int mtk_spi_prepare_message(struct spi_master 
*master,
reg_val |= SPI_CMD_CPOL;
else
reg_val &= ~SPI_CMD_CPOL;
-   writel(reg_val, mdata->base + SPI_CMD_REG);
-
-   reg_val = readl(mdata->base + SPI_CMD_REG);
 
/* set the mlsbx and mlsbtx */
if (chip_config->tx_mlsb)
-- 
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/

[PATCH 1/4] spi: mediatek: update document devicetree bindings to fix syntax error

[Leilk Liu]

This patch updates document devicetree bindings
to fix syntax error.

Signed-off-by: Leilk Liu 
---
 .../devicetree/bindings/spi/spi-mt65xx.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt 
b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
index ce363c923f..fba8334 100644
--- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
+++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
@@ -32,7 +32,7 @@ Optional properties:
 -cs-gpios: see spi-bus.txt, only required for MT8173.
 
 - mediatek,pad-select: specify which pins group(ck/mi/mo/cs) spi
-  controller used. This is a array, the element value should be 0~3,
+  controller used. This is an array, the element value should be 0~3,
   only required for MT8173.
 0: specify GPIO69,70,71,72 for spi pins.
 1: specify GPIO102,103,104,105 for spi pins.
-- 
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/

[PATCH V2] regulator: pv88090: new regulator driver

[James Ban]

From: James Ban 

This is the driver for the Powerventure PV88090 BUCKs and LDOs regulator.
It communicates via an I2C bus to the device.

Signed-off-by: James Ban 

---
Changes since PATCH V1
- Removed owner field if calls are used which set it automatically.
- Removed unneeded semicolon.
- Removed parsing the DT manually.
- Removed setting the constraints in driver.
- Removed printing an error after parsing dt.
- Added operation for range of buck voltage.

This patch applies against linux-next and next-20151118 


 .../devicetree/bindings/regulator/pv88090.txt  |   65 +++
 drivers/regulator/Kconfig  |8 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/pv88090-regulator.c  |  458 
 drivers/regulator/pv88090-regulator.h  |   98 +
 5 files changed, 630 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/pv88090.txt
 create mode 100644 drivers/regulator/pv88090-regulator.c
 create mode 100644 drivers/regulator/pv88090-regulator.h

diff --git a/Documentation/devicetree/bindings/regulator/pv88090.txt 
b/Documentation/devicetree/bindings/regulator/pv88090.txt
new file mode 100644
index 000..e52b2a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/pv88090.txt
@@ -0,0 +1,65 @@
+* Powerventure Semiconductor PV88090 Voltage Regulator
+
+Required properties:
+- compatible: "pvs,pv88090".
+- reg: I2C slave address, usually 0x48.
+- interrupts: the interrupt outputs of the controller
+- regulators: A node that houses a sub-node for each regulator within the
+  device. Each sub-node is identified using the node's name, with valid
+  values listed below. The content of each sub-node is defined by the
+  standard binding for regulators; see regulator.txt.
+  BUCK1, BUCK2, BUCK3, LDO1, and LDO2.
+
+Optional properties:
+- Any optional property defined in regulator.txt
+
+Example
+
+   pmic: pv88090@48 {
+   compatible = "pvs,pv88090";
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <24 24>;
+
+   regulators {
+   BUCK1 {
+   regulator-name = "buck1";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <1393750>;
+   regulator-min-microamp  = < 22>;
+   regulator-max-microamp  = <704>;
+   regulator-boot-on;
+   };
+
+   BUCK2 {
+   regulator-name = "buck2";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <1393750>;
+   regulator-min-microamp  = <1496000>;
+   regulator-max-microamp  = <4189000>;
+   };
+
+   BUCK3 {
+   regulator-name = "buck3";
+   regulator-min-microvolt = <60>;
+   regulator-max-microvolt = <1393750>;
+   regulator-min-microamp  = <1496000>;
+   regulator-max-microamp  = <4189000>;
+   regulator-boot-on;
+   };
+
+   LDO1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <435>;
+   regulator-boot-on;
+   };
+
+   LDO2 {
+   regulator-name = "ldo2";
+   regulator-min-microvolt = < 65>;
+   regulator-max-microvolt = <2225000>;
+   regulator-boot-on;
+   };
+   };
+   };
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index dfdaefb..2973486 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -505,6 +505,14 @@ config REGULATOR_PFUZE100
  Say y here to support the regulators found on the Freescale
  PFUZE100/PFUZE200 PMIC.
 
+config REGULATOR_PV88090
+   tristate "Powerventure Semiconductor PV88090 regulator"
+   depends on I2C
+   select REGMAP_I2C
+   help
+ Say y here to support the voltage regulators and convertors
+ on PV88090
+
 config REGULATOR_PWM
tristate "PWM voltage regulator"
depends on PWM
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 945d8ec..17cabd5 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
 

Re: [RFC] readlink()-related oddities

[Linus Torvalds]

On Thu, Nov 19, 2015 at 3:26 PM, Al Viro  wrote:
>
> 1) atime updates, according to POSIX, should happen in case of success.
> For example, giving readlink(2) an unmapped buffer should _not_ touch
> atime.  Neither should calling readlink(2) in case if ->readlink() method
> returns e.g. -EIO or -ENOMEM.  We do atime update in those cases.  Looks
> like a bug and unless there's a good reason to keep that behaviour, I'd
> rather have it do what POSIX says.

I really don't think anybody cares, but I also don't think anybody
cares about the current behavior, so we can certainly fix it to match
POSIX wording, and just move it a bit lower after checking the return
value from ->realink().

> 3) normally, readlink(2) fails for non-symlinks.  Moreover, according to
> POSIX it should do so (with -EINVAL).

I don't think POSIX is necessarily relevant here.

We have had magic file behavior outside the scope of POSIX before, and
we will have it in the future. It makes perfect sense to use
readlink() for management tools for automounting, even if the normal
oepration is to treat the thing as a directory.

Not everything is within the domain of POSIX.

   Linus
--
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 V7 2/3] reset: hi6220: Reset driver for hisilicon hi6220 SoC

[Chen Feng]

Add reset driver for hi6220-hikey board,this driver supply deassert
of IP on hi6220 SoC.

Signed-off-by: Chen Feng 
---
 drivers/reset/Kconfig  |   1 +
 drivers/reset/Makefile |   1 +
 drivers/reset/hisilicon/Kconfig|   5 ++
 drivers/reset/hisilicon/Makefile   |   1 +
 drivers/reset/hisilicon/hi6220_reset.c | 108 +
 5 files changed, 116 insertions(+)
 create mode 100644 drivers/reset/hisilicon/Kconfig
 create mode 100644 drivers/reset/hisilicon/Makefile
 create mode 100644 drivers/reset/hisilicon/hi6220_reset.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..df37212 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -13,3 +13,4 @@ menuconfig RESET_CONTROLLER
  If unsure, say no.
 
 source "drivers/reset/sti/Kconfig"
+source "drivers/reset/hisilicon/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 85d5904..99e18c8 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -4,5 +4,6 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_ARCH_HISI) += hisilicon/
 obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_ATH79) += reset-ath79.o
diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig
new file mode 100644
index 000..26bf95a
--- /dev/null
+++ b/drivers/reset/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+config COMMON_RESET_HI6220
+   tristate "Hi6220 Reset Driver"
+   depends on (ARCH_HISI && RESET_CONTROLLER)
+   help
+ Build the Hisilicon Hi6220 reset driver.
diff --git a/drivers/reset/hisilicon/Makefile b/drivers/reset/hisilicon/Makefile
new file mode 100644
index 000..c932f86
--- /dev/null
+++ b/drivers/reset/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_COMMON_RESET_HI6220) += hi6220_reset.o
diff --git a/drivers/reset/hisilicon/hi6220_reset.c 
b/drivers/reset/hisilicon/hi6220_reset.c
new file mode 100644
index 000..d17c910
--- /dev/null
+++ b/drivers/reset/hisilicon/hi6220_reset.c
@@ -0,0 +1,108 @@
+/*
+ * Hisilicon Hi6220 reset controller driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Feng Chen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ASSERT_OFFSET0x300
+#define DEASSERT_OFFSET  0x304
+#define MAX_INDEX0x509
+
+#define to_reset_data(x) container_of(x, struct hi6220_reset_data, rc_dev)
+
+struct hi6220_reset_data {
+   void __iomem*assert_base;
+   void __iomem*deassert_base;
+   struct reset_controller_dev rc_dev;
+};
+
+static int hi6220_reset_assert(struct reset_controller_dev *rc_dev,
+  unsigned long idx)
+{
+   struct hi6220_reset_data *data = to_reset_data(rc_dev);
+
+   int bank = idx >> 8;
+   int offset = idx & 0xff;
+
+   writel(BIT(offset), data->assert_base + (bank * 0x10));
+
+   return 0;
+}
+
+static int hi6220_reset_deassert(struct reset_controller_dev *rc_dev,
+unsigned long idx)
+{
+   struct hi6220_reset_data *data = to_reset_data(rc_dev);
+
+   int bank = idx >> 8;
+   int offset = idx & 0xff;
+
+   writel(BIT(offset), data->deassert_base + (bank * 0x10));
+
+   return 0;
+}
+
+static struct reset_control_ops hi6220_reset_ops = {
+   .assert = hi6220_reset_assert,
+   .deassert = hi6220_reset_deassert,
+};
+
+static int hi6220_reset_probe(struct platform_device *pdev)
+{
+   struct hi6220_reset_data *data;
+   struct resource *res;
+   void __iomem *src_base;
+
+   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   src_base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(src_base))
+   return PTR_ERR(src_base);
+
+   data->assert_base = src_base + ASSERT_OFFSET;
+   data->deassert_base = src_base + DEASSERT_OFFSET;
+   data->rc_dev.nr_resets = MAX_INDEX;
+   data->rc_dev.ops = _reset_ops;
+   data->rc_dev.of_node = pdev->dev.of_node;
+
+   reset_controller_register(>rc_dev);
+
+   return 0;
+}
+
+static const struct of_device_id hi6220_reset_match[] = {
+   { .compatible = "hisilicon,hi6220-sysctrl" },
+   { },
+};
+
+static struct platform_driver hi6220_reset_driver = {
+   .probe = hi6220_reset_probe,
+   .driver = {
+   .name = "reset-hi6220",
+   .of_match_table = hi6220_reset_match,
+   },
+};
+
+static int __init hi6220_reset_init(void)
+{
+   

[PATCH V7 3/3] arm64: dts: Add reset dts config for Hisilicon Hi6220 SoC

[Chen Feng]

Add reset controller for hi6220 hikey-board.

Signed-off-by: Chen Feng 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 82d2488..ad1f1eb 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -147,6 +147,7 @@
compatible = "hisilicon,hi6220-sysctrl", "syscon";
reg = <0x0 0xf703 0x0 0x2000>;
#clock-cells = <1>;
+   #reset-cells = <1>;
};
 
media_ctrl: media_ctrl@f441 {
-- 
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 V7 1/3] reset: hisilicon: document hisi-hi6220 reset controllers bindings

[Chen Feng]

Add DT bindings documentation for hi6220 SoC reset controller.

Signed-off-by: Chen Feng 
---
 .../bindings/reset/hisilicon,hi6220-reset.txt  | 34 +++
 include/dt-bindings/reset/hisi,hi6220-resets.h | 67 ++
 2 files changed, 101 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
 create mode 100644 include/dt-bindings/reset/hisi,hi6220-resets.h

diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt 
b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
new file mode 100644
index 000..e0b185a
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
@@ -0,0 +1,34 @@
+Hisilicon System Reset Controller
+==
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller registers are part of the system-ctl block on
+hi6220 SoC.
+
+Required properties:
+- compatible: may be "hisilicon,hi6220-sysctrl"
+- reg: should be register base and length as documented in the
+  datasheet
+- #reset-cells: 1, see below
+
+Example:
+sys_ctrl: sys_ctrl@f703 {
+   compatible = "hisilicon,hi6220-sysctrl", "syscon";
+   reg = <0x0 0xf703 0x0 0x2000>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+};
+
+Specifying reset lines connected to IP modules
+==
+example:
+
+uart1: serial@. {
+...
+resets = <_ctrl PERIPH_RSTEN3_UART1>;
+...
+};
+
+The index could be found in .
diff --git a/include/dt-bindings/reset/hisi,hi6220-resets.h 
b/include/dt-bindings/reset/hisi,hi6220-resets.h
new file mode 100644
index 000..ca08a7e
--- /dev/null
+++ b/include/dt-bindings/reset/hisi,hi6220-resets.h
@@ -0,0 +1,67 @@
+/**
+ * This header provides index for the reset controller
+ * based on hi6220 SoC.
+ */
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_HI6220
+#define _DT_BINDINGS_RESET_CONTROLLER_HI6220
+
+#define PERIPH_RSTDIS0_MMC0 0x000
+#define PERIPH_RSTDIS0_MMC1 0x001
+#define PERIPH_RSTDIS0_MMC2 0x002
+#define PERIPH_RSTDIS0_NANDC0x003
+#define PERIPH_RSTDIS0_USBOTG_BUS   0x004
+#define PERIPH_RSTDIS0_POR_PICOPHY  0x005
+#define PERIPH_RSTDIS0_USBOTG   0x006
+#define PERIPH_RSTDIS0_USBOTG_32K   0x007
+#define PERIPH_RSTDIS1_HIFI 0x100
+#define PERIPH_RSTDIS1_DIGACODEC0x105
+#define PERIPH_RSTEN2_IPF   0x200
+#define PERIPH_RSTEN2_SOCP  0x201
+#define PERIPH_RSTEN2_DMAC  0x202
+#define PERIPH_RSTEN2_SECENG0x203
+#define PERIPH_RSTEN2_ABB   0x204
+#define PERIPH_RSTEN2_HPM0  0x205
+#define PERIPH_RSTEN2_HPM1  0x206
+#define PERIPH_RSTEN2_HPM2  0x207
+#define PERIPH_RSTEN2_HPM3  0x208
+#define PERIPH_RSTEN3_CSSYS 0x300
+#define PERIPH_RSTEN3_I2C0  0x301
+#define PERIPH_RSTEN3_I2C1  0x302
+#define PERIPH_RSTEN3_I2C2  0x303
+#define PERIPH_RSTEN3_I2C3  0x304
+#define PERIPH_RSTEN3_UART1 0x305
+#define PERIPH_RSTEN3_UART2 0x306
+#define PERIPH_RSTEN3_UART3 0x307
+#define PERIPH_RSTEN3_UART4 0x308
+#define PERIPH_RSTEN3_SSP   0x309
+#define PERIPH_RSTEN3_PWM   0x30a
+#define PERIPH_RSTEN3_BLPWM 0x30b
+#define PERIPH_RSTEN3_TSENSOR   0x30c
+#define PERIPH_RSTEN3_DAPB  0x312
+#define PERIPH_RSTEN3_HKADC 0x313
+#define PERIPH_RSTEN3_CODEC_SSI 0x314
+#define PERIPH_RSTEN3_PMUSSI1   0x316
+#define PERIPH_RSTEN8_RS0   0x400
+#define PERIPH_RSTEN8_RS2   0x401
+#define PERIPH_RSTEN8_RS3   0x402
+#define PERIPH_RSTEN8_MS0   0x403
+#define PERIPH_RSTEN8_MS2   0x405
+#define PERIPH_RSTEN8_XG2RAM0   0x406
+#define PERIPH_RSTEN8_X2SRAM_TZMA   0x407
+#define PERIPH_RSTEN8_SRAM  0x408
+#define PERIPH_RSTEN8_HARQ  0x40a
+#define PERIPH_RSTEN8_DDRC  0x40c
+#define PERIPH_RSTEN8_DDRC_APB  0x40d
+#define PERIPH_RSTEN8_DDRPACK_APB   0x40e
+#define PERIPH_RSTEN8_DDRT  0x411
+#define PERIPH_RSDIST9_CARM_DAP 0x500
+#define PERIPH_RSDIST9_CARM_ATB 0x501
+#define PERIPH_RSDIST9_CARM_LBUS0x502
+#define PERIPH_RSDIST9_CARM_POR 0x503
+#define PERIPH_RSDIST9_CARM_CORE0x504
+#define PERIPH_RSDIST9_CARM_DBG 0x505
+#define PERIPH_RSDIST9_CARM_L2  0x506
+#define PERIPH_RSDIST9_CARM_SOCDBG  0x507
+#define PERIPH_RSDIST9_CARM_ETM 0x508
+
+#endif /*_DT_BINDINGS_RESET_CONTROLLER_HI6220*/
-- 
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

Re: [PATCH v3 0/6] Arizona Extcon Update Device Bindings

[Chanwoo Choi]

Hi,

On 2015년 11월 20일 00:45, Charles Keepax wrote:
> This patch chain adds device bindings for the jack and
> microphone detection system specific settings.
> 
> Changes since v2:
>  - Now moved things over to the new extcon binding document
> 
> Thanks,
> Charles
> 
> Charles Keepax (6):
>   extcon: arizona: Add device binding to enable ADC mode micdet
>   extcon: arizona: Add device binding for the general purpose switch
>   extcon: arizona: Add device binding for jack detect polarity
> inversion
>   extcon: arizona: Add device binding for second jack detect pin on
> GPIO5
>   extcon: arizona: Update DT binding documentation for mic detection
>   extcon: arizona: Update DT binding documentation for jack detection
> 
>  .../devicetree/bindings/extcon/extcon-arizona.txt  |   26 
> 
>  drivers/extcon/extcon-arizona.c|   13 ++
>  2 files changed, 39 insertions(+), 0 deletions(-)
> 

Applied them.

Thanks,
Chanwoo Choi
--
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 6/6] extcon: arizona: Update DT binding documentation for jack detection

[Chanwoo Choi]

Hi Charles,

On 2015년 11월 20일 00:45, Charles Keepax wrote:
> Add additional bindings for both inverting the polarity of the jack
> detection pins and allowing the use of a second jack detection pin. Note
> that the second jack detection pin is hard wired in the chip so can only
> be enabled through the binding, rather than a pin being specified.
> 
> Signed-off-by: Charles Keepax 
> Reviewed-by: Chanwoo Choi 
> ---
>  .../devicetree/bindings/extcon/extcon-arizona.txt  |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> index d661811..7640a35 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> +++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> @@ -14,6 +14,12 @@ Optional properties:
>  If this node is not mentioned or if the value is unknown, then
>  headphone detection mode is set to HPDETL.
>  
> +  - wlf,use-jd-gpio : Use GPIO input along with JD1 for dual pin jack
> +detection.

This property naming might cause the confusion.
If some don't know the knowledge of extcon-arizona,
it seems like the specific GPIO pin.

But I'll apply the all patches of this patchset
because these patchest take the too long time for review.

I'd like you to modify the this property name on later patch.

Thanks,
Chanwoo Choi
--
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/