Re: [PATCH v4 1/2] pinctrl: Add driver for Alphascale asm9260 pinctrl

[Oleksij Rempel]

Hi, finally i'm able to continue to work on it.

Am 13.05.2015 um 13:00 schrieb Linus Walleij:
> On Tue, May 12, 2015 at 6:25 PM, Oleksij Rempel  
> wrote:
>> Am 05.05.2015 um 17:12 schrieb Linus Walleij:
> 
>>> Just reference the statically defined array by a pointer instead,
>>> this just takes up a lot o memory for no reason.
>>
>> This two arrays have different types this is why i convert it.
>> priv->pin_desc[i].name - here i copy pointer any ways, and
>> priv->pin_desc[i].number can be smaller then pointer.
> 
> I probably do not understand what you're trying to do, sorry :(
> 
> Why is it necessary for the driver to copy one description of
> the pin into another?

If i understand it correctly, pinctrl_pin_desc is essential part of
pinmux framework. Theoretically i should define just statical array of
this struct, but by this number of pins and functions it hard to keep it
readable and error free. So i decided to create asm9260_mux_table which
contains every thing i need. The side effect is higher memory usage
since i need to create pinctrl_pin_desc on fly.

May be i miss some thing?

>>> Mory copying. I don't see why this is necessary at all.
>>
>> I hadn't seen the point to define groups statically, especially because
>> they are used only  to make curious user happy. So, memory will be used
>> only if you request the list over sysfs. Or miss some thing?
> 
> pinctrl does not even use sysfs.

please read debugfs.

> The group names are usually there for matching with a function,
> it is part of the core functionality. The group name + function name
> matching is even more obvious in the dt case.
> 
> They also make things easier to read in debugfs yes, but
> the core of the crux is to make it easy to config function+groups
> states with e.g. DT or board files.
> 
 +static struct pinmux_ops asm9260_pinmux_ops = {
 +   .get_functions_count= asm9260_pinctrl_get_funcs_count,
 +   .get_function_name  = asm9260_pinctrl_get_func_name,
 +   .get_function_groups= asm9260_pinctrl_get_func_groups,
 +   .set_mux= asm9260_pinctrl_set_mux,
 +   /* TODO: should we care about gpios here? gpio_request_enable? */
>>>
>>> I think you should, if you also have a matching GPIO driver.
>>
>> I fear it would cause unpredictable bugs. GPIO mode is just one of mux
>> modes. If some one will request gpio some busy or dangerous line it
>> would do more harm then use. So, i assume limiting this only to device
>> tree would be better.
> 
> Device tree or not doesn't matter, .gpio_request_enable() is used
> as a shortcut to mux in GPIO pins.
> 
> If the simultaneous use of a pin for a device and GPIO bothers
> you there is nowadays (linux-next or my devel branch) a .strict
> option in pinmux_ops that you can set to disallow simultaneous
> use by devices and GPIO of the same pin.
> 
> Yours,
> Linus Walleij
> 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] net: tipc: fix stall during bclink wakeup procedure

[David Miller]

From: Kolmakov Dmitriy 
Date: Mon, 7 Sep 2015 09:05:48 +

> If an attempt to wake up users of broadcast link is made when there is
> no enough place in send queue than it may hang up inside the
> tipc_sk_rcv() function since the loop breaks only after the wake up
> queue becomes empty. This can lead to complete CPU stall with the
> following message generated by RCU:
 ...
> The issue occurs only when tipc_sk_rcv() is used to wake up postponed
> senders:
 ...
> After the sender thread is woke up it can gather control and perform
> an attempt to send a message. But if there is no enough place in send
> queue it will call link_schedule_user() function which puts a message
> of type SOCK_WAKEUP to the wakeup queue and put the sender to sleep.
> Thus the size of the queue actually is not changed and the while()
> loop never exits.
> 
> The approach I proposed is to wake up only senders for which there is
> enough place in send queue so the described issue can't occur.
> Moreover the same approach is already used to wake up senders on
> unicast links.
> 
> I have got into the issue on our product code but to reproduce the
> issue I changed a benchmark test application (from
> tipcutils/demos/benchmark) to perform the following scenario:
>   1. Run 64 instances of test application (nodes). It can be done
>  on the one physical machine.
>   2. Each application connects to all other using TIPC sockets in
>  RDM mode.
>   3. When setup is done all nodes start simultaneously send
>  broadcast messages.
>   4. Everything hangs up.
> 
> The issue is reproducible only when a congestion on broadcast link
> occurs. For example, when there are only 8 nodes it works fine since
> congestion doesn't occur. Send queue limit is 40 in my case (I use a
> critical importance level) and when 64 nodes send a message at the
> same moment a congestion occurs every time.
> 
> Signed-off-by: Dmitry S Kolmakov 
> Reviewed-by: Jon Maloy 
> Acked-by: Ying Xue 
> ---
> v2: Updated after comments from Jon and Ying.

Applied, 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] powerpc: Kconfig: remove BE-only platforms from LE kernel build

[Michael Ellerman]

On Wed, 2015-09-09 at 11:25 +0800, Boqun Feng wrote:
> Hi Michael,
> 
> On Wed, Sep 09, 2015 at 12:26:44PM +1000, Michael Ellerman wrote:
> > On Mon, 2015-09-07 at 07:58 +0800, Boqun Feng wrote:
> > > diff --git a/arch/powerpc/platforms/cell/Kconfig 
> > > b/arch/powerpc/platforms/cell/Kconfig
> > > index 2f23133..808a904 100644
> > > --- a/arch/powerpc/platforms/cell/Kconfig
> > > +++ b/arch/powerpc/platforms/cell/Kconfig
> > > @@ -25,7 +25,7 @@ config PPC_CELL_NATIVE
> > >  
> > >  config PPC_IBM_CELL_BLADE
> > >   bool "IBM Cell Blade"
> > > - depends on PPC64 && PPC_BOOK3S
> > > + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN
> > 
> > We end up saying this five times.
> > 
> > We already have PPC_BOOK3S_64 which captures the first two conditions, 
> > should
> > we add a PPC_BOOK3S_64_BE which expresses it all?
> 
> I'm not sure whether this is worth.. IMO, we add a config option only if
> 
> 1.we can use this config somewhere in the code, for example,
>   "#ifdef CONFIG_XXX"
> or
> 
> 2.we want to offer a option for users to choose.
>
> PPC_BOOK3S_64_BE satisfies neither condition. Further more,
> CONFIG_PPC64, CONFIG_PPC_BOOK3S and CONFIG_CPU_BIG_ENDIAN all are used
> in some #ifdefs in current code. As a newbie of kernel, I'm happy to get
> some knowledge like: "If I'm hacking PS3, then #ifndef CONFIG_PPC64 is
> guaranteed to be false, so I can just ignore the code guarded by them".
> But if we add a PPC_BOOK3S_64_BE, it will take a little more effort to
> see this.

Yeah those are good points, so I'll take it as is. Thanks for thinking about it 
:)

cheers



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

Re: [PATCH 1/3] doc: dt: add documentation for Mediatek spi-nor controller

[Sascha Hauer]

On Tue, Sep 08, 2015 at 05:49:54PM +0800, Bayi Cheng wrote:
> Add device tree binding documentation for serial flash with
> Mediatek serial flash controller
> 
> Signed-off-by: Bayi Cheng 
> ---
>  Documentation/devicetree/bindings/mtd/mtk_nor.txt | 25 
> +++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/mtk_nor.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/mtk_nor.txt 
> b/Documentation/devicetree/bindings/mtd/mtk_nor.txt
> new file mode 100644
> index 000..0eca0cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/mtk_nor.txt
> @@ -0,0 +1,25 @@
> +* MTD SPI nor driver for MTK MT81xx (and similar) serial flash controller
> +
> +MTK MT81xx serial flash controller is designed for serial Flash device.
> +It supports one Flash device with signal mode, dual mode and quad mode.
> +
> +Required properties:
> +- compatible: should be "mediatek,mt8173-nor";
> +- reg: physical base address and length of the controller's register
> +- clocks: spi nor source clock
> +- clock-names: "spi_clk", "axi_clk", "mux_clk", "sf_clk"

Drop the _clk suffix. It's the clock-names property which already makes
it clear that these are clock names.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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] ARM: Make FORCE_MAX_ZONEORDER configurable if ARM_SINGLE_ARMV7M

[Uwe Kleine-König]

On Tue, Sep 08, 2015 at 11:19:13PM +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 08, 2015 at 10:38:04PM +0200, Maxime Coquelin wrote:
> > This patch makes FORCE_MAX_ZONEORDER configurable in defconfig for ARMV7-M
> > when built for a single platform.
> 
> I'd prefer if we didn't do this, because this isn't supposed to be a user
> visible "option".  It's an option that was introduced to avoid having to
> throw masses of #ifdefs into the definition of MAX_ZONEORDER.
> 
> The problem with it is that it's a "well, what do I set this to?" option
> and that leads to "oh, I'll just choose the default because I don't know
> any better".
> 
> Do we know why EFM32 needs a value of 9 here?  It's not documented in
> the original commit, and it really _should_ have been.
IIRC it was done because of memory pressure. But not sure this makes any
sense. I will try with the default value later today and report back.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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 linux-next v9 2/3] mfd: devicetree: add bindings for Atmel Flexcom

[Rob Herring]

On 09/01/2015 09:46 AM, Cyrille Pitchen wrote:
> This patch documents the DT bindings for the Atmel Flexcom which will be
> introduced by sama5d2x SoCs. These bindings will be used by the actual
> Flexcom driver to be sent in another patch.
> 
> Signed-off-by: Cyrille Pitchen 
> Acked-by: Boris Brezillon 
> Acked-by: Alexandre Belloni 

A few comments, but in general looks fine.

> ---
>  .../devicetree/bindings/mfd/atmel-flexcom.txt  | 67 
> ++
>  1 file changed, 67 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt 
> b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> new file mode 100644
> index ..fc3511e41542
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> @@ -0,0 +1,67 @@
> +* Device tree bindings for Atmel Flexcom (Flexible Serial Communication Unit)
> +
> +The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
> +controller and an USART. Only one function can be used at a time and is 
> chosen
> +at boot time according to the device tree.

Doesn't the board design choose (unless pins go to a header)?

> +
> +Required properties:
> +- compatible:Should be "atmel,sama5d2-flexcom"
> +- reg:   Should be the offset/length value for Flexcom 
> dedicated
> + I/O registers (without USART, TWI or SPI registers).
> +- clocks:Should be the Flexcom peripheral clock from PMC.
> +- #address-cells:Should be <1>
> +- #size-cells:   Should be <1>
> +- ranges:Should be one range for the full I/O register region
> + (including USART, TWI and SPI registers).
> +- atmel,flexcom-mode:Should be one of the 3 following macros as 
> defined in
> + include/dt-bindings/mfd/atmel-flexcom.h:
> + - ATMEL_FLEXCOM_MODE_USART for USART
> + - ATMEL_FLEXCOM_MODE_SPI for SPI
> + - ATMEL_FLEXCOM_MODE_TWI for I2C
> +
> +Required child:
> +a single child device of type matching the "atmel,flexcom-mode" property.

Okay, but why not allow all children and use "status"?

> +
> +The reg property of this child should be:
> +- <0x200 0x200> for USART
> +- <0x400 0x200> for SPI
> +- <0x600 0x200> for I2C
> +
> +The phandle provided by the clocks property of the child is the same as one 
> for
> +the Flexcom parent.
> +
> +Other properties remain unchanged. See documentation of the respective 
> device:
> +- ../serial/atmel-usart.txt
> +- ../spi/spi_atmel.txt
> +- ../i2c/i2c-at91.txt
> +
> +Example:
> +
> +flexcom@f8034000 {
> + compatible = "atmel,sama5d2-flexcom";
> + reg = <0xf8034000 0x200>;
> + clocks = <_clk>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0xf8034000 0x800>;
> + atmel,flexcom-mode = ;
> +
> + spi@400 {
> + compatible = "atmel,at91rm9200-spi";
> + reg = <0x400 0x200>;
> + interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_flx0_default>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <_clk>;
> + clock-names = "spi_clk";
> + atmel,fifo-size = <32>;
> +
> + mtd_dataflash@0 {
> + compatible = "atmel,at25f512b";
> + reg = <0>;
> + spi-max-frequency = <2000>;
> + };
> + };
> +};
> 

--
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 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor

[Rob Herring]

On 09/07/2015 08:59 AM, Adriana Reus wrote:
> Thanks for your feedback, some comments inline.
> 
> On 31.08.2015 18:38, Rob Herring wrote:
>> On Thu, Aug 27, 2015 at 3:23 PM, Jonathan Cameron 
>> wrote:
>>> On 20/08/15 11:12, Adriana Reus wrote:
 Added entries in i2c/vendor-prefixes for the us5182d als and
 proximity sensor.
 Also added a documentation file for this sensor's properties.

 Signed-off-by: Adriana Reus 
>>> This isn't that trivial so I'd like some device tree maintainer
>>> input if possible.
>>
>> It seems fairly reasonable to me. Would other ALS or proximity sensors
>> need similar properties?
> The "glass-coef" is intended to compensate for the material (glass) that
> may be covering the sensor if it's integrated in a phone, tablet etc. I
> chose 1000 as resolution for this scaling factor (i'll add a more
> detailed description). So possibly similar properties could be used for
> other als sensors as well.

Seems like amstaos,cover-comp-gain would be doing the same thing. But it
is defined as an integer, so I'm not sure how that would work.

> 
> The last 3 tuning parameters are specific to this particular sensor.
>>
>>> For now I've backed out the driver from my tree (given timing we have
>>> loads of time to sort this out!)
>>>
>>> Anyhow, anyone device tree related able to take a look at this.
>>>
>>> Adriana, btw these should be cc'd to the device tree maintainers in
>>> the first place (now added).
>>>
>>> Jonathan
 ---
   .../devicetree/bindings/iio/light/us5182d.txt  | 23
 ++
   .../devicetree/bindings/vendor-prefixes.txt|  1 +
   2 files changed, 24 insertions(+)
   create mode 100644
 Documentation/devicetree/bindings/iio/light/us5182d.txt

 diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt
 b/Documentation/devicetree/bindings/iio/light/us5182d.txt
 new file mode 100644
 index 000..7785c56
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
 @@ -0,0 +1,23 @@
 +* UPISEMI us5182d I2C ALS and Proximity sensor
 +
 +Required properties:
 +- compatible: must be "upisemi,usd5182"
 +- reg: the I2C address of the device
 +
 +Optional properties:
>>
>> Do you expect certain defaults if not present? Some description of how
>> all these values are determined would be useful.
> Yes, if not present they will fall back to default values - the values
> in the example.
> - the glass-coef one is 1000 by default - so no glass compensation by
> default (lux = lux * 1000/1000)
> - the others were determined experimentally - by fine tuning starting
> from the default values in those registers).

So the default if the properties are not present is a default register
value or a default in the driver?

Rob
--
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 v7 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs

[Rob Herring]

On 09/08/2015 01:17 AM, Chunfeng Yun wrote:
> add a DT binding documentation of usb3.0 phy for MT65xx
> SoCs from Mediatek.
> 
> Signed-off-by: Chunfeng Yun 

One comment, otherwise:

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 69 
> ++
>  1 file changed, 69 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
> b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> new file mode 100644
> index 000..5812d20
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> @@ -0,0 +1,69 @@
> +mt65xx USB3.0 PHY binding
> +--
> +
> +This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
> +
> +Required properties (controller (parent) node):
> + - compatible: should be "mediatek,mt8173-u3phy"
> + - reg   : offset and length of register for phy, exclude port's
> +   register.
> + - clocks: a list of phandle + clock-specifier pairs, one for each
> +   entry in clock-names
> + - clock-names   : must contain
> +   "u3phya_ref": for reference clock of usb3.0 analog phy.
> +
> +Required nodes   : a sub-node is required for each port the controller
> +   provides. Address range information including the usual
> +   'reg' property is used inside these nodes to describe
> +   the controller's topology. These nodes are translated
> +   by the driver's .xlate() function.

The last sentence is Linux specific. Please remove.

> +
> +Required properties (port (child) node):
> +- reg: address and length of the register set for the port.
> +- #phy-cells : should be 1 (See second example)
> +   cell after port phandle is phy type from:
> + - PHY_TYPE_USB2
> + - PHY_TYPE_USB3
> +
> +Example:
> +
> +u3phy: usb-phy@1129 {
> + compatible = "mediatek,mt8173-u3phy";
> + reg = <0 0x1129 0 0x800>;
> + clocks = < CLK_APMIXED_REF2USB_TX>;
> + clock-names = "u3phya_ref";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + status = "okay";
> +
> + phy_port0: port@11290800 {
> + reg = <0 0x11290800 0 0x800>;
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +
> + phy_port1: port@11291000 {
> + reg = <0 0x11291000 0 0x800>;
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +};
> +
> +Specifying phy control of devices
> +-
> +
> +Device nodes should specify the configuration required in their "phys"
> +property, containing a phandle to the phy port node and a device type;
> +phy-names for each port are optional.
> +
> +Example:
> +
> +#include 
> +
> +usb30: usb@1127 {
> + ...
> + phys = <_port0 PHY_TYPE_USB3>;
> + phy-names = "usb3-0";
> + ...
> +};
> 

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

Re: [PATCH] net: stmmac: Use msleep rather then udelay for reset delay

[David Miller]

From: Sjoerd Simons 
Date: Sun,  6 Sep 2015 17:50:59 +0200

> @@ -161,11 +161,16 @@ int stmmac_mdio_reset(struct mii_bus *bus)
>  
>   if (!gpio_request(reset_gpio, "mdio-reset")) {
>   gpio_direction_output(reset_gpio, active_low ? 1 : 0);
> - udelay(data->delays[0]);
> + if (data->delays[0])
> + msleep((data->delays[0] + 999) / 1000);

Please use something like DIV_ROUND_UP(..., USEC_PER_MSEC) or similar.
--
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: [PATCHv2 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.

[Rob Herring]

On 09/08/2015 02:25 AM, Enric Balletbo i Serra wrote:
> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> designed for portable devices.
> 
> You can add support to your board with current binding.
> 
> Example:
> 
>   anx7814: anx7814@38 {
>   compatible = "analogix,anx7814";
>   reg = <0x38>;
>   pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
>   reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
>   };
> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  .../devicetree/bindings/video/anx7814.txt  | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/anx7814.txt
> 
> diff --git a/Documentation/devicetree/bindings/video/anx7814.txt 
> b/Documentation/devicetree/bindings/video/anx7814.txt
> new file mode 100644
> index 000..a8cc746
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/anx7814.txt
> @@ -0,0 +1,22 @@
> +Analogix ANX7814 SlimPort (Full-HD Transmitter)
> +---
> +
> +The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> +designed for portable devices.
> +
> +Required properties:
> +
> + - compatible: "analogix,anx7814"
> + - reg   : I2C address of the device
> + - pd-gpios  : Which GPIO to use for power down
> + - reset-gpios   : Which GPIO to use for reset
> +
> +Example:
> +
> + anx7814: anx7814@38 {
> + compatible = "analogix,anx7814";
> + reg = <0x38>;
> + pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 2 GPIO_ACTIVE_HIGH>;

No ports needed for describing data connections?

Rob

> + };
> +
> 

--
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 04/22] of: add function to allow probing a device from a OF node

[Rob Herring]

On 09/07/2015 07:23 AM, Tomeu Vizoso wrote:
> Walks the OF tree up and finds the closest ancestor that has a struct
> device associated with it, probing it if isn't bound to a driver yet.
> 
> The above should ensure that the dependency represented by the passed OF
> node is available, because probing a device should cause its descendants
> to be probed as well (when they get registered).
> 
> Subsystems can use this when looking up resources for drivers, to reduce
> the chances of deferred probes because of the probing order of devices.
> 
> Signed-off-by: Tomeu Vizoso 

Looks pretty good to me. One comment below.

[...]

> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index baf04d7249bd..f089d95ac961 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -269,6 +269,8 @@ static struct amba_device *of_amba_device_create(struct 
> device_node *node,
>   goto err_free;
>   }
>  
> + node->device = >dev;
> +

This seems oddly placed. Can you move to patch 3?

>   return dev;
>  
>  err_free:
> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
> index cc7dd687a89d..da8d489e73ad 100644
> --- a/include/linux/of_device.h
> +++ b/include/linux/of_device.h
> @@ -40,6 +40,7 @@ extern ssize_t of_device_get_modalias(struct device *dev,
>  
>  extern void of_device_uevent(struct device *dev, struct kobj_uevent_env 
> *env);
>  extern int of_device_uevent_modalias(struct device *dev, struct 
> kobj_uevent_env *env);
> +extern void of_device_probe(struct device_node *np);
>  
>  static inline void of_device_node_put(struct device *dev)
>  {
> @@ -84,6 +85,8 @@ static inline int of_device_uevent_modalias(struct device 
> *dev,
>   return -ENODEV;
>  }
>  
> +static inline void of_device_probe(struct device_node *np) { }
> +
>  static inline void of_device_node_put(struct device *dev) { }
>  
>  static inline const struct of_device_id *__of_match_device(
> 

--
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 0/22] On-demand device probing

[Rob Herring]

On 09/08/2015 02:30 AM, Tomeu Vizoso wrote:
> On 7 September 2015 at 22:50, Rob Herring  wrote:
>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso  
>> wrote:
>>> Hello,
>>>
>>> I have a problem with the panel on my Tegra Chromebook taking longer
>>> than expected to be ready during boot (Stéphane Marchesin reported what
>>> is basically the same issue in [0]), and have looked into ordered
>>> probing as a better way of solving this than moving nodes around in the
>>> DT or playing with initcall levels and linking order.
>>>
>>> While reading the thread [1] that Alexander Holler started with his
>>> series to make probing order deterministic, it occurred to me that it
>>> should be possible to achieve the same by probing devices as they are
>>> referenced by other devices.
>>>
>>> This basically reuses the information that is already implicit in the
>>> probe() implementations, saving us from refactoring existing drivers or
>>> adding information to DTBs.
>>>
>>> During review of v1 of this series Linus Walleij suggested that it
>>> should be the device driver core to make sure that dependencies are
>>> ready before probing a device. I gave this idea a try [2] but Mark Brown
>>> pointed out to the logic duplication between the resource acquisition
>>> and dependency discovery code paths (though I think it's fairly minor).
>>>
>>> To address that code duplication I experimented with Arnd's devm_probe
>>> [3] concept of having drivers declare their dependencies instead of
>>> acquiring them during probe, and while it worked [4], I don't think we
>>> end up winning anything when compared to just probing devices on-demand
>>> from resource getters.
>>>
>>> One remaining objection is to the "sprinkling" of calls to
>>> of_device_probe() in the resource getters of each subsystem, but I think
>>> it's the right thing to do given that the storage of resources is
>>> currently subsystem-specific.
>>>
>>> We could avoid the above by moving resource storage into the core, but I
>>> don't think there's a compelling case for that.
>>>
>>> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
>>> OMAP SoCs, and these patches were enough to eliminate all the deferred
>>> probes (except one in PandaBoard because omap_dma_system doesn't have a
>>> firmware node as of yet).
>>>
>>> Have submitted a branch [5] with only these patches on top of thursday's
>>> linux-next to kernelci.org and I don't see any issues that could be
>>> caused by them. For some reason it currently has more passes than the
>>> version of -next it's based on!
>>>
>>> With this series I get the kernel to output to the panel in 0.5s,
>>> instead of 2.8s.
>>>
>>> Regards,
>>>
>>> Tomeu
>>>
>>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>>>
>>> [1] https://lkml.org/lkml/2014/5/12/452
>>>
>>> [2] https://lkml.org/lkml/2015/6/17/305
>>>
>>> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689
>>>
>>> [4] https://lkml.org/lkml/2015/7/21/441a
>>>
>>> [5] 
>>> https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6
>>>
>>> [6] 
>>> http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/
>>>
>>> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/
>>>
>>> Changes in v4:
>>> - Added bus.pre_probe callback so the probes of Primecell devices can be
>>>   deferred if their device IDs cannot be yet read because of the clock
>>>   driver not having probed when they are registered. Maybe this goes
>>>   overboard and the matching information should be in the DT if there is
>>>   one.
>>
>> Seems overboard to me or at least a separate problem.
> 
> It's a separate problem but this was preventing the series from
> working on a few boards.

What is the failure? Not booting? Fixing not working would certainly not
be overboard.

> 
>> Most clocks have
>> to be setup before the driver model simply because timers depend on
>> clocks usually.
> 
> Yes, but in this case the apb clocks for the primecell devices are
> implemented in a normal platform driver (vexpress_osc_driver), instead
> of using CLK_OF_DECLARE.

Okay.

Rob

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

Re: [PATCH 1/3] ARM: uniphier: add outer cache support

[Rob Herring]

On 09/08/2015 08:09 AM, Linus Walleij wrote:
> On Fri, Aug 28, 2015 at 12:24 PM, Masahiro Yamada
>  wrote:
>> 2015-08-26 22:39 GMT+09:00 Linus Walleij :
> 
>>> cache-unified and cache-level are *not* optional and should be required.
>>
>> "cache-unified" is mentioned in "3.7.3 Internal (L1) Cache Properties"
>> (Table 3-8),
>> but it is not in "3.8 Multi-level and Shared Caches" (Table 3-9)
>>
>> Are the rules in Table 3-8 also applied for L2?
> 
> Your guess is as good as mine unless someone involved in
> actually writing that spec says something :/

Maybe you'd have to be crazy to have Harvard cache for 2nd+ level. I've
got no clue. Doesn't hurt to have it.

> 
>>> (I'm just assuming this cache is unified, anything else would be baffling.)
>>
>> In fact, unified/harvard is configurable thru a register of this cache
>> controller.
> 
> Jesus Christ.

Hardware designers either hate software folks or ensure our job security.

> 
>> It is usually used as a unified cached, though.
> 
> I would, too.
> 
>> So,I am planning to use the same compatible for L2 and L3, like this:
>>
>>
>>l2-cache@500c {
>>compatible = "socionext,uniphier-cache";
>>reg = <0x500c 0x2000>, <0x503c0100 0x8>,
>>  <0x506c 0x400>;
>>cache-unified;
>>cache-level = <2>;
>>next-level-cache = <>;

Next level of the L2 is the L2?

>>cache-size = <0x20>;
>>cache-sets = <256>;
>>cache-line-size = <128>;
>> };
>>
>>/* Not all of UniPhier SoCs have L3 cache */
>>l3-cache@500c8000 {
>>compatible = "socionext,uniphier-cache";
>>reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
>>  <0x506c8000 0x400>;
>>cache-unified;
>>cache-level = <3>;
>>cache-size = <0x40>;
>>cache-sets = <256>;
>>cache-line-size = <256>;
>>};
> 
> This LooksGoodToMe.
> 
>> The Table 3-9 in ePAPR v1.1 says
>> the compatible should be "cache", but I do not think it makes sense here.
> 
> Agree.

It could be useful for finding all cache nodes, but we've generally
failed to use it, so at this point it doesn't matter.

Rob

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

Re: [PATCH 3/3] arm64: dts: mt8173: Add nor flash node

[Rob Herring]

On 09/08/2015 10:18 AM, Ezequiel Garcia wrote:
> On 8 September 2015 at 08:53, Jagan Teki  wrote:
>> On 8 September 2015 at 15:19, Bayi Cheng  wrote:
>>> Add Mediatek nor flash node
>>>
>>> Signed-off-by: Bayi Cheng 
>>> ---
>>>  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 ++
>>>  1 file changed, 10 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
>>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>>> index d18ee42..a14f005 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>>> @@ -365,6 +365,16 @@
>>> status = "disabled";
>>> };
>>>
>>> +   nor_flash: nor@1100d000 {
>>
>> Based on the comments from 1/3 - this notation needs to be change something 
>> like
>> qspi0: quadspi@1100d000
>>
> 
> Actually, to follow ePAPR recomendations it should be named as flash@1100d000.
> (See ePAPR, 2.2.2 Generic Names Recommendation).

The flash device node should, but this is the controller which should be
"spi" IMO even if this is not a general purpose controller.

Rob

--
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 linux-next v5 4/5] Documentation: atmel-quadspi: add binding file for Atmel QSPI driver

[Rob Herring]

On 08/26/2015 07:30 AM, Cyrille Pitchen wrote:
> This patch documents the DT bindings for the driver of the Atmel QSPI
> controller embedded inside sama5d2x SoCs.
> 
> Signed-off-by: Cyrille Pitchen 
> Acked-by: Nicolas Ferre 
> Acked-by: Marek Vasut 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/mtd/atmel-quadspi.txt  | 29 
> ++
>  1 file changed, 29 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt 
> b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> new file mode 100644
> index ..0b8d545bb198
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> @@ -0,0 +1,29 @@
> +* Atmel Quad Serial Peripheral Interface (QSPI)
> +
> +Required properties:
> +- compatible: should be "atmel,sama5d2-qspi"
> +- reg:the first contains the register location and length,
> +  the second contains the memory mapping address and length
> +- interrupts: should contain the interrupt for the device
> +- clocks: the phandle of the clock needed by the QSPI controller
> +- #address-cells: should be <1>
> +- #size-cells:should be <0>
> +
> +Example:
> +
> +spi@f002 {
> + compatible = "atmel,sama5d2-qspi";
> + reg = <0xf002 0x100>,
> +   <0xd000 0x800>;
> + interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>;
> + clocks = <_clk>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_spi0_default>;
> + status = "okay";
> +
> + m25p80@0 {
> + ...
> + };
> +};
> 

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

Re: [PATCH v7 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller

[Rob Herring]

On 09/08/2015 01:18 AM, Chunfeng Yun wrote:
> add a DT binding documentation of xHCI host controller for the
> MT8173 SoC from Mediatek.
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  .../devicetree/bindings/usb/mt8173-xhci.txt| 52 
> ++
>  1 file changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
> b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> new file mode 100644
> index 000..d851bf1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> @@ -0,0 +1,52 @@
> +MT8173 xHCI
> +
> +The device node for Mediatek SOC USB3.0 host controller
> +
> +Required properties:
> + - compatible : should contain "mediatek,mt8173-xhci"
> + - reg : specifies physical base address and size of the registers,
> + the first one for MAC, the second for IPPC
> + - interrupts : interrupt used by the controller
> + - power-domains : a phandle to USB power domain node to control USB's
> + mtcmos
> + - vusb33-supply : regulator of USB avdd3.3v
> +
> + - clocks : a list of phandle + clock-specifier pairs, one for each
> + entry in clock-names
> + - clock-names : must contain
> + "sys_ck": for clock of xHCI MAC
> + "wakeup_deb_p0": for USB wakeup debounce clock of port0
> + "wakeup_deb_p0": for USB wakeup debounce clock of port1
> +
> + - phys : a list of phandle + phy specifier pairs
> + - usb3-lpm-capable : supports USB3.0 LPM
> + - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
> + control register

Wake-up should probably be done in some generic way. That said, I don't
have a specific suggestion other than make it optional.

> + - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
> + mode; Others means don't enable wakeup source of USB

This should be optional rather than any other value meaning disabled.

> +
> +Optional properties:
> + - vbus-supply : reference to the VBUS regulator;
> +
> +Example:
> +usb30: usb@1127 {
> + compatible = "mediatek,mt8173-xhci";
> + reg = <0 0x1127 0 0x1000>,
> +   <0 0x11280700 0 0x0100>;
> + interrupts = ;
> + power-domains = < MT8173_POWER_DOMAIN_USB>;
> + clocks = < CLK_TOP_USB30_SEL>,
> +  < CLK_PERI_USB0>,
> +  < CLK_PERI_USB1>;
> + clock-names = "sys_ck",
> +   "wakeup_deb_p0",
> +   "wakeup_deb_p1";
> + phys = <_port0 PHY_TYPE_USB3>,
> +<_port1 PHY_TYPE_USB2>;
> + vusb33-supply = <_vusb_reg>;
> + vbus-supply = <_p1_vbus>;
> + usb3-lpm-capable;
> + mediatek,syscon-wakeup = <>;
> + mediatek,wakeup-src = <1>;
> + status = "okay";
> +};
> 

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

Re: [PATCH-v2 2/7] mmc: sdhci-pxav3: binding: Add pxa1928 compatible support

[Rob Herring]

On 09/07/2015 06:18 AM, Vaibhav Hiremath wrote:
> With support for pxa1928 family of devices , this patch
> updates the binding document with compatible property
> of "marvell,pxav3-1928-sdhci".
> 
> Signed-off-by: Vaibhav Hiremath 
> ---
>  Documentation/devicetree/bindings/mmc/sdhci-pxa.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt 
> b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
> index 3d1b449..29edcf5 100644
> --- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
> @@ -5,7 +5,7 @@ and the properties used by the sdhci-pxav2 and sdhci-pxav3 
> drivers.
>  
>  Required properties:
>  - compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or
> -  "marvell,armada-380-sdhci".
> +  "marvell,armada-380-sdhci" or "marvell,pxav3-1928-sdhci".

v3 is implied by pxa1928. So I'd just do "marvell,pxa1928-sdhci" to
better match the chip name.

Rob

>  - reg:
>* for "mrvl,pxav2-mmc" and "mrvl,pxav3-mmc", one register area for
>  the SDHCI registers.
> 

--
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: [PATCHv2 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.

[Rob Herring]

On 09/08/2015 02:25 AM, Enric Balletbo i Serra wrote:
> Analogix Semiconductor develops analog and mixed-signal devices for digital
> media and communications interconnect applications.
> 
> Signed-off-by: Enric Balletbo i Serra 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index ac5f0c3..e914a02 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -22,6 +22,7 @@ ampire  Ampire Co., Ltd.
>  ams  AMS AG
>  amstaos  AMS-Taos Inc.
>  apm  Applied Micro Circuits Corporation (APM)
> +analogix Analogix Semiconductor, Inc.
>  aptina   Aptina Imaging
>  arasan   Arasan Chip Systems
>  arm  ARM Ltd.
> 

--
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 linux-next v9 1/3] mfd: atmel-flexcom: create include file with macros used by DT bindings

[Rob Herring]

On 09/01/2015 09:46 AM, Cyrille Pitchen wrote:
> This patch defines some macros to be used as value for the
> "atmel,flexcom-mode" DT property. This value is then written into
> the Operating Mode (OPMODE) bit field of the Flexcom Mode Register.
> 
> Signed-off-by: Cyrille Pitchen 

Acked-by: Rob Herring 

In the future, you can combine headers with the binding doc as they are
part of the binding.

Rob

> ---
>  include/dt-bindings/mfd/atmel-flexcom.h | 16 
>  1 file changed, 16 insertions(+)
>  create mode 100644 include/dt-bindings/mfd/atmel-flexcom.h
> 
> diff --git a/include/dt-bindings/mfd/atmel-flexcom.h 
> b/include/dt-bindings/mfd/atmel-flexcom.h
> new file mode 100644
> index ..6728f2851b4d
> --- /dev/null
> +++ b/include/dt-bindings/mfd/atmel-flexcom.h
> @@ -0,0 +1,16 @@
> +/*
> + * This header provides macros for Atmel Flexcom DT bindings.
> + *
> + * Copyright (C) 2015 Cyrille Pitchen 
> + *
> + * GPLv2 only
> + */
> +
> +#ifndef __DT_BINDINGS_ATMEL_FLEXCOM_H__
> +#define __DT_BINDINGS_ATMEL_FLEXCOM_H__
> +
> +#define ATMEL_FLEXCOM_MODE_USART 1
> +#define ATMEL_FLEXCOM_MODE_SPI   2
> +#define ATMEL_FLEXCOM_MODE_TWI   3
> +
> +#endif /* __DT_BINDINGS_ATMEL_FLEXCOM_H__ */
> 

--
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/2 v3] watchdog: bcm7038: add device tree binding documentation

[Rob Herring]

On 09/08/2015 12:45 PM, Justin Chen wrote:
> Add device tree binding documentation for the watchdog hardware block
> on bcm7038 and newer SoCs.
> 
> Signed-off-by: Justin Chen 
> Acked-by: Guenter Roeck 

Some minor comments, otherwise:

Acked-by: Rob Herring 


> ---
>  .../devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt | 19 
> +++
>  1 file changed, 19 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> new file mode 100644
> index 000..39e5cf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> @@ -0,0 +1,19 @@
> +BCM7038 Watchdog timer
> +
> +Required properties:
> +
> +- compatible : should be "brcm,bcm7038-wdt"
> +- reg : Specifies base physical address and size of the registers.
> +
> +Optional properties:
> +
> +- clocks: The clock running the watchdog. If no clock is found the
> +   driver will default to 2700 HZ.

s/HZ/Hz/

> +
> +Example:
> +
> +watchdog {

This should have a unit address (watchdog@f040a7e8).

> + compatible = "brcm,bcm7038-wdt";
> + clocks = <_fixed>;
> + reg = <0xf040a7e8 0x16>;
> +};
> 

--
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] fbdev: ssd1307fb: add ssd1309 support

[Rob Herring]

On 09/08/2015 02:19 PM, Olliver Schinagl wrote:
> The ssd1307fb driver supports a lot of chips from the ssd130xfb series.
> This patch adds the ssd1309 chip, a 128x64 OLED driver chip. It is very
> similar to the other chips and only has some definitions added to
> support it.
> 
> Signed-off-by: Olliver Schinagl 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/video/ssd1307fb.txt |  3 ++-
>  drivers/video/fbdev/ssd1307fb.c   | 11 +++
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt 
> b/Documentation/devicetree/bindings/video/ssd1307fb.txt
> index d1be78d..eb31ed4 100644
> --- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
> +++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
> @@ -2,7 +2,8 @@
>  
>  Required properties:
>- compatible: Should be "solomon,fb-". The only supported bus 
> for
> -now is i2c, and the supported chips are ssd1305, ssd1306 and ssd1307.
> +now is i2c, and the supported chips are ssd1305, ssd1306, ssd1307 and
> +ssd1309.
>- reg: Should contain address of the controller on the I2C bus. Most likely
>   0x3c or 0x3d
>- pwm: Should contain the pwm to use according to the OF device tree PWM
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 339615c..8fc7960 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -495,6 +495,12 @@ static struct ssd1307fb_deviceinfo 
> ssd1307fb_ssd1307_deviceinfo = {
>   .need_pwm = 1,
>  };
>  
> +static struct ssd1307fb_deviceinfo ssd1307fb_ssd1309_deviceinfo = {
> + .default_vcomh = 0x34,
> + .default_dclk_div = 1,
> + .default_dclk_frq = 10,
> +};
> +
>  static const struct of_device_id ssd1307fb_of_match[] = {
>   {
>   .compatible = "solomon,ssd1305fb-i2c",
> @@ -508,6 +514,10 @@ static const struct of_device_id ssd1307fb_of_match[] = {
>   .compatible = "solomon,ssd1307fb-i2c",
>   .data = (void *)_ssd1307_deviceinfo,
>   },
> + {
> + .compatible = "solomon,ssd1309fb-i2c",
> + .data = (void *)_ssd1309_deviceinfo,
> + },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
> @@ -708,6 +718,7 @@ static const struct i2c_device_id ssd1307fb_i2c_id[] = {
>   { "ssd1305fb", 0 },
>   { "ssd1306fb", 0 },
>   { "ssd1307fb", 0 },
> + { "ssd1309fb", 0 },
>   { }
>  };
>  MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
> 

--
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: bridge: remove unnecessary switchdev include

[David Miller]

From: Vivien Didelot 
Date: Sat,  5 Sep 2015 21:49:41 -0400

> Remove the unnecessary switchdev.h include from br_netlink.c.
> 
> Signed-off-by: Vivien Didelot 

Applied.
--
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] net: bridge: check __vlan_vid_del for error

[David Miller]

From: Vivien Didelot 
Date: Sat,  5 Sep 2015 21:27:57 -0400

> Since __vlan_del can return an error code, change its inner function
> __vlan_vid_del to return an eventual error from switchdev_port_obj_del.
> 
> Signed-off-by: Vivien Didelot 

Applied, 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 v5 3/5] thermal: Add devfreq cooling

[Eduardo Valentin]

Hi

On Thu, Aug 27, 2015 at 11:55:49AM +0100, Javi Merino wrote:
> From: Ørjan Eide 
> 
> Add a generic thermal cooling device for devfreq, that is similar to
> cpu_cooling.
> 
> The device must use devfreq.  In order to use the power extension of the
> cooling device, it must have registered its OPPs using the OPP library.
> 
> Cc: Zhang Rui 
> Cc: Eduardo Valentin 
> Signed-off-by: Javi Merino 
> Signed-off-by: Ørjan Eide 

Thanks for taking this to upstream kernel.

Just minor comments as follows.

> ---
> 
> I had a look at 02373d7c69b4 ("thermal: cpu_cooling: fix lockdep
> problems in cpu_cooling").  It doesn't affect devfreq cooling because
> we don't have notifiers, we only use locking for idr.
> 

Thanks once again for checking it.

>  drivers/thermal/Kconfig   |  11 +
>  drivers/thermal/Makefile  |   3 +
>  drivers/thermal/devfreq_cooling.c | 546 
> ++
>  include/linux/devfreq_cooling.h   |  72 +
>  4 files changed, 632 insertions(+)
>  create mode 100644 drivers/thermal/devfreq_cooling.c
>  create mode 100644 include/linux/devfreq_cooling.h
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 118938ee8552..a2c6a6497804 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -147,6 +147,17 @@ config CLOCK_THERMAL
> device that is configured to use this cooling mechanism will be
> controlled to reduce clock frequency whenever temperature is high.
>  
> +config DEVFREQ_THERMAL
> + bool "Generic device cooling support"
> + depends on PM_DEVFREQ
> + depends on PM_OPP
> + help
> +   This implements the generic devfreq cooling mechanism through
> +   frequency reduction for devices using devfreq.
> +
> +   This will throttle the device by limiting the maximum allowed DVFS
> +   frequency corresponding to the cooling level.
> +
> If you want this support, you should say Y here.
>  
>  config THERMAL_EMULATION
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 535dfee1496f..45f26978ff74 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -22,6 +22,9 @@ thermal_sys-$(CONFIG_CPU_THERMAL)   += cpu_cooling.o
>  # clock cooling
>  thermal_sys-$(CONFIG_CLOCK_THERMAL)  += clock_cooling.o
>  
> +# devfreq cooling
> +thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
> +
>  # platform thermal drivers
>  obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM)   += qcom-spmi-temp-alarm.o
>  obj-$(CONFIG_SPEAR_THERMAL)  += spear_thermal.o
> diff --git a/drivers/thermal/devfreq_cooling.c 
> b/drivers/thermal/devfreq_cooling.c
> new file mode 100644
> index ..3d4abc746099
> --- /dev/null
> +++ b/drivers/thermal/devfreq_cooling.c
> @@ -0,0 +1,546 @@
> +/*
> + * devfreq_cooling: Thermal cooling device implementation for devices using
> + *  devfreq
> + *
> + * Copyright (C) 2014-2015 ARM Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * TODO:
> + *- If OPPs are added or removed after devfreq cooling has
> + *  registered, the devfreq cooling won't react to it.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static DEFINE_MUTEX(devfreq_lock);
> +static DEFINE_IDR(devfreq_idr);
> +
> +/**
> + * struct devfreq_cooling_device - Devfreq cooling device
> + * @id:  unique integer value corresponding to each
> + *   devfreq_cooling_device registered.
> + * @cdev:Pointer to associated thermal cooling device.
> + * @devfreq: Pointer to associated devfreq device.
> + * @cooling_state:   Current cooling state.
> + * @power_table: Pointer to table with maximum power draw for each
> + *   cooling state. State is the index into the table, and
> + *   the power is in mW.
> + * @freq_table:  Pointer to a table with the frequencies sorted in 
> descending
> + *   order.  You can index the table by cooling device state
> + * @freq_table_size: size of the @freq_table and @power_table
> + * @power_ops:   Pointer to power operations, used to generate 
> @power_table.
> + */
> +struct devfreq_cooling_device {
> + int id;
> + struct thermal_cooling_device *cdev;
> + struct devfreq *devfreq;
> + unsigned long cooling_state;
> + u32 *power_table;
> + u32 *freq_table;
> + size_t freq_table_size;
> + struct devfreq_cooling_ops *power_ops;
> +};
> +
> +/**
> + * get_idr - function to get a unique id.
> + * @idr: struct idr * handle used 

Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger

[Krzysztof Kozlowski]

On 09.09.2015 11:26, Andreas Dannenberg wrote:
> On Mon, Sep 07, 2015 at 12:57:56PM +0900, Krzysztof Kozlowski wrote:
>> 2015-09-07 2:23 GMT+09:00 Ramakrishna Pallala 
>> :
>>>
>>> Add new charger driver support for BQ24261 charger IC.
>>>
>>> BQ24261 charger driver relies on extcon notifications to get the
>>> charger cable type and based on that it will set the charging parameters.
>>>
>>> Signed-off-by: Ramakrishna Pallala 
>>> Signed-off-by: Jennt TC 
>>> ---
>>>  .../devicetree/bindings/power/bq24261.txt  |   37 +
>>>  drivers/power/Kconfig  |6 +
>>>  drivers/power/Makefile |1 +
>>>  drivers/power/bq24261_charger.c| 1208 
>>> 
>>>  include/linux/power/bq24261_charger.h  |   27 +
>>>  5 files changed, 1279 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/power/bq24261.txt
>>>  create mode 100644 drivers/power/bq24261_charger.c
>>>  create mode 100644 include/linux/power/bq24261_charger.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/bq24261.txt 
>>> b/Documentation/devicetree/bindings/power/bq24261.txt
>>> new file mode 100644
>>> index 000..25fc5c4
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/power/bq24261.txt
>>> @@ -0,0 +1,37 @@
>>> +Binding for TI bq24261 Li-Ion Charger
>>
>> Please split the bindings into separate patch (the first patch in patchset).
>>
>>> +
>>> +Required properties:
>>> +- compatible: Should contain one of the following:
>>> +* "ti,bq24261"
>>> +- reg: integer, i2c address of the device.
>>> +- ti,charge-current: integer, default charging current (in mA);
>>> +- ti,charge-voltage: integer, default charging voltage (in mV);
>>> +- ti,termination-current: integer, charge will be terminated when current 
>>> in
>>> +constant-voltage phase drops below this value (in mA);
>>> +- ti,max-charge-current: integer, maximum charging current (in mA);
>>> +- ti,max-charge-voltage: integer, maximum charging voltage (in mV);
>>> +- ti,min-charge-temperature: integer, minimum charging temperature (in 
>>> DegC);
>>> +- ti,max-charge-temperature: integer, maximum charging temperature (in 
>>> DegC).
>>
>> Before accepting "[PATCH 13/13] dt: power: bq24257-charger: Cover
>> additional devices"
>> http://www.spinics.net/lists/devicetree/msg92134.html
>>
>> could you and Andreas figure out common bindings? Look at this:
>>
>> +- ti,charge-current: integer, maximum charging current in uA.
>> +- ti,charge-current: integer, default charging current (in mA);
>>
>> Different meaning and different units. This is madness! :)
>>
>> In the same time you are adding TI-common bindings (not device
>> specific, there is no prefix) so I would expect exactly the same
>> bindings if it is possible.
> 
> Krzysztof, good observation! In bq2425x_charger.c (formerly known as
> bq24257_charger.c :) that I worked on the unit used was uA. At that time
> I did a quick check and there didn't seem to be a clear standard whether
> to use the "micro" or "milli" units - different drivers use different
> units. However there seems to be a tendency for the TI drivers to prefer
> "milli" (bq2415x_charger.c, bq24735-charger.c)
> 
> Personally I think "milli" units are more appropriate for chargers since
> they provide sufficient granularity and the numbers don't become too big
> (try typing a voltage in the Volt-range in uV, it's very easy to get the
> number of 0s wrong). However since the driver was already there I left
> that aspect alone to preserve compatibility.

I am fine with both units but milli indeed seems easier to judge by fast
looking and less error-prone. Whatever you choose - choose the same one. :)


>>> +
>>> +Optional properties:
>>> +- ti,thermal-sensing: boolean, if present thermal regulation will be 
>>> enabled;
>>
>> What is the requirement for thermal-sensing? Can it be enabled always?
>> If yes, then this is not really a hardware property.
>>
>>> +- ti,enable-user-write: boolean, if present driver will allow the user 
>>> space
>>> +to control the charging current and voltage through sysfs;
>>
>> This is not DT property. It does not describe hardware.
> 
> I take responsibility for this one :) In an earlier thread we were
> discussing that it will be better to prevent sysfs write access to
> "dangerous" charger parameters (charge voltage, current, ...) but I
> argued that such access might still be desirable during development and
> debug, and that a DT property could be used to allow such write access
> (with the default being the charger properties being made read-only) -
> this way giving the best of both worlds. However then when I updated the
> bq24157_charger.c driver I ended up not really needing and implementing
> this feature.
> 
> Out of curiosity, if it against best-practice to expose non hardware
> properties, how would one best address the above use case? Compile time
> switch? A sysfs property that 

Re: [PATCH] x86: serialize LVTT and TSC_DEADLINE write

[Shaohua Li]

On Tue, Sep 08, 2015 at 08:39:37PM -0700, Andi Kleen wrote:
> > Hmm, I didn't mean mfence can't serialize the instructions. For a true
> > IO, a serialization can't guarantee device finishes the IO, we generally
> > read some safe IO registers to wait IO finish. I completely don't know
> > if this case fits here though.
> 
> Sorry for the late answer. We (Intel) analyzed this case in detail and
> can confirm that the following sequence
> 
> 1.   Memory-mapped write to LVT Timer Register, setting bits 18:17 to 10b.
> 23. MFENCE.
> 4.   WRMSR to the IA32_TSC_DEADLINE MSR the desired deadline.
> 
> has the same effect as the loop algorithm described in the SDM on all Intel
> CPUs. So it's fine to use MFENCE here.

Thank you very much, Andi!

Here is the updated patch.


>From b5cdd3c14b0589e5d5a72d607814d9e808d05765 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Shaohua Li 
Date: Thu, 30 Jul 2015 16:24:43 -0700
Subject: [PATCH] x86: serialize LVTT and TSC_DEADLINE write

We saw a strange issue with local APIC timer. Some random CPU doesn't
receive any local APIC timer interrupt, which causes different issues.
The cpu uses TSC-Deadline mode for local APIC timer and APIC is in xAPIC
mode. When this happens, manually writing TSC_DEADLINE MSR can trigger
interrupt again and the system goes normal.

Currently we only see this issue in E5-2660 v2 and E5-2680 v2 CPU.
Compiler version seems mattering too, it's quite easy to reproduce the
issue with v4.7 gcc.

Since the local APIC timer interrupt number is 0, we either lose the
first interrupt or TSC_DEADLINE MSR isn't set correctly. After some
debugging, we believe it's the serialize issue described in Intel SDM.
In xAPIC mode, write to APIC LVTT and write to TSC_DEADLINE isn't
serialized. Debug shows read TSC_DEADLINE MSR followed the very first
MSR write returns 0 in the buggy cpu.

Thanks Andi Kleen confirms a 'mfence' can do the serialization here.
'mfence' instruction should be supported by CPU with TSC_DEADLINE, so we
don't need to check the instruction availability.

Cc: Suresh Siddha 
Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Andi Kleen 
Cc: sta...@vger.kernel.org v3.7+
Signed-off-by: Shaohua Li 
---
 arch/x86/kernel/apic/apic.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 3ca3e46..e3fd4ab 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -336,6 +336,13 @@ static void __setup_APIC_LVTT(unsigned int clocks, int 
oneshot, int irqen)
apic_write(APIC_LVTT, lvtt_value);
 
if (lvtt_value & APIC_LVT_TIMER_TSCDEADLINE) {
+   /*
+* See Intel SDM: TSC-Deadline Mode chapter. In xAPIC mode,
+* writing APIC LVTT and TSC_DEADLINE MSR isn't serialized.
+* According to Intel, mfence can do the serialization here.
+* */
+   asm volatile("mfence" : : : "memory");
+
printk_once(KERN_DEBUG "TSC deadline timer enabled\n");
return;
}
-- 
1.8.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 1/3] sysfs: Fix is_visible() support for binary attributes

[Guenter Roeck]

On 09/08/2015 08:58 PM, Greg KH wrote:

On Tue, Sep 08, 2015 at 06:10:16PM -0700, Guenter Roeck wrote:

Hi Emilio,

On 09/08/2015 05:51 PM, Emilio López wrote:

Hi Greg & Guenter,


[ ... ]


Unless I am missing something, this is not explained anywhere, but it is
not entirely trivial to understand. I think it should be documented.


I agree. I couldn't find any mention of what this int was supposed to be by 
looking at Documentation/ (is_visible is not even mentioned :/) or 
include/linux/sysfs.h. Once we settle on something I'll document it before 
sending a v2.


In the include file ? No strong preference, though.


By the way, I wrote a quick coccinelle script to match is_visible() users which 
reference the index (included below), and it found references to drivers which 
do not seem to use any binary attributes, so I believe changing the index 
meaning shouldn't be an issue.


Good.


I agree, make i the number of the bin attribute and that should solve
this issue.


No, that would conflict with the "normal" use of is_visible for non-binary
attributes, and make the index all but useless, since the is_visible function
would have to search through all the attributes anyway to figure out which one
is being checked.


Yeah, using the same indexes would be somewhat pointless, although not many 
seem to be using it anyway (only 14 files matched). Others seem to be comparing 
the attr* instead. An alternative would be to use negative indexes for binary 
attributes and positive indexes for normal attributes.


... and I probably wrote or reviewed a significant percentage of those ;-).

Using negative numbers for binary attributes is an interesting idea.
Kind of unusual, though. Greg, any thoughts on that ?


Ick, no, that's a mess, maybe we just could drop the index alltogether?



No, please don't. Having to manually compare dozens of index pointers would be
even more of a mess.

Guenter


--
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] of: add vendor prefix for Socionext Inc.

[Masahiro Yamada]

Hi Lee, Rob,

2015-08-25 0:11 GMT+09:00 Rob Herring :
> On Mon, Aug 24, 2015 at 1:57 AM, Lee Jones  wrote:
>> On Wed, 29 Jul 2015, Masahiro Yamada wrote:
>>
>>> Signed-off-by: Masahiro Yamada 
>>> ---
>>>
>>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>>  1 file changed, 1 insertion(+)
>>
>> Patch has been around for nearly a month and is pretty trivial, so I'm
>> just going to go ahead an apply it.
>
> Okay. I just added it now going thru my backlog, but will drop it.
>
> Rob
>

So, where has this patch gone?

I've not seen it anywhere.


-- 
Best Regards
Masahiro Yamada
--
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] cgroup: fix seq_show_option merge with legacy_name

[Zefan Li]

On 2015/9/9 2:30, Kees Cook wrote:

When seq_show_option (068acf2ee776) was merged, it did not correctly
collide with cgroup's addition of legacy_name (3e1d2eed39d8) changes. This
fixes the reported name.

Signed-off-by: Kees Cook 


Acked-by: Zefan 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: [PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator

[Guenter Roeck]

On Sun, Sep 06, 2015 at 04:41:10PM -0700, Guenter Roeck wrote:
> On Thu, Sep 03, 2015 at 03:25:11PM +0530, Kishon Vijay Abraham I wrote:
> > PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
> > OMAP5 and DRA7 SoCs. Enable it here.
> > 
> > Signed-off-by: Kishon Vijay Abraham I 
> 
> Tested-by: Guenter Roeck 
> 
This problem is now causing various runtime failures in mainline.
I see the following qemu test failures:

arm:beagle:multi_v7_defconfig:omap3-beagle
arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
arm:overo:multi_v7_defconfig:omap3-overo-tobi

I would expect all omap2/3/4/5 runtime tests with multi_v7_defconfig to fail.

Also, FWIW,

Fixes: 6a9b2ff07d04 ("mmc: host: omap_hsmmc: return on fatal errors from 
omap_hsmmc_reg_get")

Guenter

> > ---
> >  arch/arm/configs/multi_v7_defconfig |1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/configs/multi_v7_defconfig 
> > b/arch/arm/configs/multi_v7_defconfig
> > index 5fd8df6..f497c96 100644
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
> > @@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y
> >  CONFIG_REGULATOR_MAX77686=y
> >  CONFIG_REGULATOR_MAX77693=m
> >  CONFIG_REGULATOR_PALMAS=y
> > +CONFIG_REGULATOR_PBIAS=y
> >  CONFIG_REGULATOR_S2MPS11=y
> >  CONFIG_REGULATOR_S5M8767=y
> >  CONFIG_REGULATOR_TPS51632=y
> > -- 
> > 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/
> > 
> > 
--
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/2] lib: test_kasan: add some testcases

[Wang Long]

This patch add some out of bounds testcases to test_kasan
module.

Signed-off-by: Wang Long 
---
 lib/test_kasan.c | 69 
 1 file changed, 69 insertions(+)

diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index c1efb1b..c32f3b0 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -138,6 +138,71 @@ static noinline void __init kmalloc_oob_16(void)
kfree(ptr2);
 }
 
+static noinline void __init kmalloc_oob_memset_2(void)
+{
+   char *ptr;
+   size_t size = 8;
+
+   pr_info("out-of-bounds in memset2\n");
+   ptr = kmalloc(size, GFP_KERNEL);
+   if (!ptr) {
+   pr_err("Allocation failed\n");
+   return;
+   }
+
+   memset(ptr+7, 0, 2);
+   kfree(ptr);
+}
+
+static noinline void __init kmalloc_oob_memset_4(void)
+{
+   char *ptr;
+   size_t size = 8;
+
+   pr_info("out-of-bounds in memset4\n");
+   ptr = kmalloc(size, GFP_KERNEL);
+   if (!ptr) {
+   pr_err("Allocation failed\n");
+   return;
+   }
+
+   memset(ptr+5, 0, 4);
+   kfree(ptr);
+}
+
+
+static noinline void __init kmalloc_oob_memset_8(void)
+{
+   char *ptr;
+   size_t size = 8;
+
+   pr_info("out-of-bounds in memset8\n");
+   ptr = kmalloc(size, GFP_KERNEL);
+   if (!ptr) {
+   pr_err("Allocation failed\n");
+   return;
+   }
+
+   memset(ptr+1, 0, 8);
+   kfree(ptr);
+}
+
+static noinline void __init kmalloc_oob_memset_16(void)
+{
+   char *ptr;
+   size_t size = 16;
+
+   pr_info("out-of-bounds in memset16\n");
+   ptr = kmalloc(size, GFP_KERNEL);
+   if (!ptr) {
+   pr_err("Allocation failed\n");
+   return;
+   }
+
+   memset(ptr+1, 0, 16);
+   kfree(ptr);
+}
+
 static noinline void __init kmalloc_oob_in_memset(void)
 {
char *ptr;
@@ -264,6 +329,10 @@ static int __init kmalloc_tests_init(void)
kmalloc_oob_krealloc_less();
kmalloc_oob_16();
kmalloc_oob_in_memset();
+   kmalloc_oob_memset_2();
+   kmalloc_oob_memset_4();
+   kmalloc_oob_memset_8();
+   kmalloc_oob_memset_16();
kmalloc_uaf();
kmalloc_uaf_memset();
kmalloc_uaf2();
-- 
1.8.3.4

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

[PATCH 2/2] kasan: Fix a type conversion error

[Wang Long]

The current KASAN code can find the following out-of-bounds
bugs:
char *ptr;
ptr = kmalloc(8, GFP_KERNEL);
memset(ptr+7, 0, 2);

the cause of the problem is the type conversion error in
*memory_is_poisoned_n* function. So this patch fix that.

Signed-off-by: Wang Long 
---
 mm/kasan/kasan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 7b28e9c..5d65d06 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -204,7 +204,7 @@ static __always_inline bool memory_is_poisoned_n(unsigned 
long addr,
s8 *last_shadow = (s8 *)kasan_mem_to_shadow((void *)last_byte);
 
if (unlikely(ret != (unsigned long)last_shadow ||
-   ((last_byte & KASAN_SHADOW_MASK) >= *last_shadow)))
+   ((long)(last_byte & KASAN_SHADOW_MASK) >= 
*last_shadow)))
return true;
}
return false;
-- 
1.8.3.4

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

[PATCH 0/2] KASAN: fix a type conversion error and add test

[Wang Long]

Hi,

This patchset fix a type conversion error for KASAN.

patch 1: this patch add some out-of-bounds testcases, the current KASAN code
can not find these bugs.

patch 2: fix the type conversion error, with this patch, KASAN could find
these out-of-bounds bugs.

Wang Long (2):
  lib: test_kasan: add some testcases
  kasan: Fix a type conversion error

 lib/test_kasan.c | 69 
 mm/kasan/kasan.c |  2 +-
 2 files changed, 70 insertions(+), 1 deletion(-)

-- 
1.8.3.4

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

Re: [PATCH 1/3] sysfs: Fix is_visible() support for binary attributes

[Greg KH]

On Tue, Sep 08, 2015 at 06:10:16PM -0700, Guenter Roeck wrote:
> Hi Emilio,
> 
> On 09/08/2015 05:51 PM, Emilio López wrote:
> >Hi Greg & Guenter,
> >
> [ ... ]
> 
> Unless I am missing something, this is not explained anywhere, but it is
> not entirely trivial to understand. I think it should be documented.
> >
> >I agree. I couldn't find any mention of what this int was supposed to be by 
> >looking at Documentation/ (is_visible is not even mentioned :/) or 
> >include/linux/sysfs.h. Once we settle on something I'll document it before 
> >sending a v2.
> >
> In the include file ? No strong preference, though.
> 
> >By the way, I wrote a quick coccinelle script to match is_visible() users 
> >which reference the index (included below), and it found references to 
> >drivers which do not seem to use any binary attributes, so I believe 
> >changing the index meaning shouldn't be an issue.
> >
> Good.
> 
> >>>I agree, make i the number of the bin attribute and that should solve
> >>>this issue.
> >>>
> >>No, that would conflict with the "normal" use of is_visible for non-binary
> >>attributes, and make the index all but useless, since the is_visible 
> >>function
> >>would have to search through all the attributes anyway to figure out which 
> >>one
> >>is being checked.
> >
> >Yeah, using the same indexes would be somewhat pointless, although not many 
> >seem to be using it anyway (only 14 files matched). Others seem to be 
> >comparing the attr* instead. An alternative would be to use negative indexes 
> >for binary attributes and positive indexes for normal attributes.
> >
> ... and I probably wrote or reviewed a significant percentage of those ;-).
> 
> Using negative numbers for binary attributes is an interesting idea.
> Kind of unusual, though. Greg, any thoughts on that ?

Ick, no, that's a mess, maybe we just could drop the index alltogether?

thanks,

greg k-h
--
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 0/7] devcg: device cgroup extension for rdma resource

[Parav Pandit]

On Tue, Sep 8, 2015 at 8:53 PM, Tejun Heo  wrote:
> Hello, Parav.
>
> On Tue, Sep 08, 2015 at 02:08:16AM +0530, Parav Pandit wrote:
>> Currently user space applications can easily take away all the rdma
>> device specific resources such as AH, CQ, QP, MR etc. Due to which other
>> applications in other cgroup or kernel space ULPs may not even get chance
>> to allocate any rdma resources.
>
> Is there something simple I can read up on what each resource is?
> What's the usual access control mechanism?
>
Hi Tejun,
This is one old white paper, but most of the reasoning still holds true on RDMA.
http://h10032.www1.hp.com/ctg/Manual/c00257031.pdf

More notes on RDMA resources and summary:
RDMA allows data transport from one system to other system where RDMA
device implements OSI layers 4 to 1 typically in hardware, drivers.
RDMA device provides data path semantics to perform data transfer in
zero copy manner from one to other host, very similar to local dma
controller.
It also allows data transfer operation from user space application of
one to other system.
In order to do so, all the resources are created using trusted kernel
space which also provides isolation among applications.
These resources include are-  QP (queue pair) to transfer data, CQ
(Completion queue) to indicate completion of data transfer operation,
MR (memory region) to represent user application memory as source or
destination for data transfer.
Common resources are QP, SRQ (shared received queue), CQ, MR, AH
(Address handle), FLOW, PD (protection domain), user context etc.

>> This patch-set allows limiting rdma resources to set of processes.
>> It extend device cgroup controller for limiting rdma device limits.
>
> I don't think this belongs to devcg.  If these make sense as a set of
> resources to be controlled via cgroup, the right way prolly would be a
> separate controller.
>

In past there has been similar comment to have dedicated cgroup
controller for RDMA instead of merging with device cgroup.
I am ok with both the approach, however I prefer to utilize device
controller instead of spinning of new controller for new devices
category.
I anticipate more such need would arise and for new device category,
it might not be worth to have new cgroup controller.
RapidIO though very less popular and upcoming PCIe are on horizon to
offer similar benefits as that of RDMA and in future having one
controller for each of them again would not be right approach.

I certainly seek your and others inputs in this email thread here whether
(a) to continue to extend device cgroup (which support character,
block devices white list) and now RDMA devices
or
(b) to spin of new controller, if so what are the compelling reasons
that it can provide compare to extension.

Current scope of the patch is limited to RDMA resources as first
patch, but for fact I am sure that there are more functionality in
pipe to support via this cgroup by me and others.
So keeping atleast these two aspects in mind, I need input on
direction of dedicated controller or new one.

In future, I anticipate that we might have sub directory to device
cgroup for individual device class to control.
such as,
 Thanks.
>
> --
> tejun
--
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: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

[Sedat Dilek]

On Wed, Sep 9, 2015 at 5:25 AM, Baoquan He  wrote:
> Hi Sedat,
>
> On 09/09/15 at 04:51am, Sedat Dilek wrote:
>> On Wed, Sep 9, 2015 at 4:29 AM, Baoquan He  wrote:
>> commit 1a1d48a4a8fde49aedc045d894efe67173d59fe0
>> "linux/bitmap: Force inlining of bitmap weight functions"
>>
>> ...on top of Linux v4.2.
>>
>> This resulted in the same call-trace in QEMU.
>>
>> I hacked around to only re-build mm/percpu.c with GCC (rest with
>> CLANG) with some guidance from Linus (compiler warapper-script) etc.
>
> Sorry, from below log message and code flow I didn't get what's wrong
> with it. I am working on another issue which gives me much headache,
> don't hvae time to look into the the disassembling code now. But if GCC
> built code works, it should be related to compiler issues. You can try
> more tests, e.g build percpu.c bitmap.c with GCC. Maybe other people
> can give suggestions.
>
> Sorry again, Sedat.
>

Hi Baoquan,

OK, I understand your situation and kernel folks are within
merge-window or you have to concentrate on your daily work etc.

I have found some more playground

The article "Force a function to be inline in Clang/LLVM" from
 in [1] says...

"There is a good solution if compiling with C99 which is Clang's
default. Its simply using inline attribute.

inline void foo() {}

[...]

So in order to guarantee that the function is inlined:

1. Don’t use static inline.
2. Don’t add another implementation for the function that doesn't have
inline attribute.
3. You must use optimization. But even if there isn't optimization the
compilation will fail which is good.
4. Make sure not to compile with GNU89."

So I added to Linux main Makefile...

$ git diff
diff --git a/Makefile b/Makefile
index 0e333fd142a1..e1723367ece4 100644
--- a/Makefile
+++ b/Makefile
@@ -702,6 +702,14 @@ KBUILD_CFLAGS += $(call cc-disable-warning,
tautological-compare)
 # See modpost pattern 2
 KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)

+# Force a function to be inline in Clang/LLVM
+# 
http://stackoverflow.com/questions/25602813/force-a-function-to-be-inline-in-clang-llvm
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
+# http://marc.info/?t=14415615671=1=2
+ifdef CONFIG_OPTIMIZE_INLINING
+KBUILD_CFLAGS += $(call cc-option,-always-inline)
+endif
+
 else

 KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)

Some comments below...

Thanks in advance!

> setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1 nr_node_ids:1
>
> arch/x86/kernel/setup_percpu.c:setup_per_cpu_areas() ->
> mm/percpu.c : pcpu_embed_first_chunk() ->
> mm/percpu.c:pcpu_build_alloc_info() ->
> include/linux/cpumask.h:
> #define num_possible_cpus() cpumask_weight(cpu_possible_mask)
> static inline unsigned int cpumask_weight(const struct cpumask *srcp)
> {
> return bitmap_weight(cpumask_bits(srcp), nr_cpumask_bits);
> }
>

s/inline/__always_inline/ ???

> include/linux/bitmap.h:
> static inline int bitmap_weight(const unsigned long *src, unsigned int nbits)
> {
> if (small_const_nbits(nbits))
> return hweight_long(*src & BITMAP_LAST_WORD_MASK(nbits));
> return __bitmap_weight(src, nbits);
> }
>

s/inline/__always_inline/ ???

Already realized in "linux/bitmap: Force inlining of bitmap weight
functions" upstream (see [3], but not available for Linux v4.2).

> lib/bitmap.c:
> int __bitmap_weight(const unsigned long *bitmap, unsigned int bits)
> {
> unsigned int k, lim = bits/BITS_PER_LONG;
> int w = 0;
>
> for (k = 0; k < lim; k++)
> w += hweight_long(bitmap[k]);
>
> if (bits % BITS_PER_LONG)
> w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits));
>
> return w;
> }
> EXPORT_SYMBOL(__bitmap_weight);
>

Thanks again.

- Sedat -

[1] 
http://stackoverflow.com/questions/25602813/force-a-function-to-be-inline-in-clang-llvm
[2] 
http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob;f=arch/all/patches/compiler-gcc.patch
[3] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a1d48a4a8fde49aedc045d894efe67173d59fe0
--
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] x86: serialize LVTT and TSC_DEADLINE write

[Andi Kleen]

> Hmm, I didn't mean mfence can't serialize the instructions. For a true
> IO, a serialization can't guarantee device finishes the IO, we generally
> read some safe IO registers to wait IO finish. I completely don't know
> if this case fits here though.

Sorry for the late answer. We (Intel) analyzed this case in detail and
can confirm that the following sequence

1.   Memory-mapped write to LVT Timer Register, setting bits 18:17 to 10b.
23. MFENCE.
4.   WRMSR to the IA32_TSC_DEADLINE MSR the desired deadline.

has the same effect as the loop algorithm described in the SDM on all Intel
CPUs. So it's fine to use MFENCE here.

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

Re: [PATCH 3/3] staging: slimport: Add anx7814 driver support by analogix.

[Daniel Kurtz]

Hi Eric,

Thanks for starting to upstream this Analogix Slimport driver!
As Greg says, please move this driver to its intended directory, I presume:
/drivers/gpu/drm/bridge

And when you submit, use get_maintainer.pl to add the proper reviewers
and lists.
At present, you have no DRM folks, nor dri-devel, so you probably
won't receive any additional feedback on this version, since the
relevant folks have not seen your emails.

Some more very detailed feedback inline...

On Sep 7, 2015 05:15, "Enric Balletbo i Serra"  wrote:
>
> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> designed for portable devices.
>
> This driver adds initial support and supports HDMI to DP pass-through mode.
>
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  drivers/staging/Kconfig|2 +
>  drivers/staging/Makefile   |1 +
>  drivers/staging/slimport/Kconfig   |7 +
>  drivers/staging/slimport/Makefile  |4 +
>  drivers/staging/slimport/slimport.c|  301 +++
>  drivers/staging/slimport/slimport.h|   49 +
>  drivers/staging/slimport/slimport_tx_drv.c | 3293 
> 
>  drivers/staging/slimport/slimport_tx_drv.h |  254 +++
>  drivers/staging/slimport/slimport_tx_reg.h |  786 +++
>  9 files changed, 4697 insertions(+)
>  create mode 100644 drivers/staging/slimport/Kconfig
>  create mode 100644 drivers/staging/slimport/Makefile
>  create mode 100644 drivers/staging/slimport/slimport.c
>  create mode 100644 drivers/staging/slimport/slimport.h
>  create mode 100644 drivers/staging/slimport/slimport_tx_drv.c
>  create mode 100644 drivers/staging/slimport/slimport_tx_drv.h
>  create mode 100644 drivers/staging/slimport/slimport_tx_reg.h
>
> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
> index e29293c..24ccd7c 100644
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@ -110,4 +110,6 @@ source "drivers/staging/wilc1000/Kconfig"
>
>  source "drivers/staging/most/Kconfig"
>
> +source "drivers/staging/slimport/Kconfig"
> +
>  endif # STAGING
> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
> index 50824dd..942e886 100644
> --- a/drivers/staging/Makefile
> +++ b/drivers/staging/Makefile
> @@ -47,3 +47,4 @@ obj-$(CONFIG_FB_TFT)  += fbtft/
>  obj-$(CONFIG_FSL_MC_BUS)   += fsl-mc/
>  obj-$(CONFIG_WILC1000) += wilc1000/
>  obj-$(CONFIG_MOST) += most/
> +obj-$(CONFIG_SLIMPORT_ANX78XX) += slimport/
> diff --git a/drivers/staging/slimport/Kconfig 
> b/drivers/staging/slimport/Kconfig
> new file mode 100644
> index 000..f5233ef
> --- /dev/null
> +++ b/drivers/staging/slimport/Kconfig
> @@ -0,0 +1,7 @@
> +config SLIMPORT_ANX78XX

I think the "SLIMPORT_" here is a bit overkill, and just adds to
confusion over what name to use where.  I'd recommend just
CONFIG_ANX78XX.

Likewise, for consistency, the rename the files as "anx78xx*" instead
of "slimport*".

> +   tristate "Analogix Slimport transmitter ANX78XX support"
> +   help
> +   Slimport Transmitter is a HD video transmitter chip
> +   over micro-USB connector for smartphone device.
> +
> +
> diff --git a/drivers/staging/slimport/Makefile 
> b/drivers/staging/slimport/Makefile
> new file mode 100644
> index 000..9bb6ce2
> --- /dev/null
> +++ b/drivers/staging/slimport/Makefile
> @@ -0,0 +1,4 @@
> +obj-${CONFIG_SLIMPORT_ANX78XX} :=  anx78xx.o
> +
> +anx78xx-y := slimport.o
> +anx78xx-y += slimport_tx_drv.o
> diff --git a/drivers/staging/slimport/slimport.c 
> b/drivers/staging/slimport/slimport.c
> new file mode 100644
> index 000..95c5114
> --- /dev/null
> +++ b/drivers/staging/slimport/slimport.c
> @@ -0,0 +1,301 @@
> +/*
> + * Copyright(c) 2015, Analogix Semiconductor. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "slimport.h"
> +#include "slimport_tx_drv.h"
> +
> +/* HDCP switch for external block */
> +/* external_block_en = 1: enable, 0: disable */

This comment is a bit superfluous.

> +int external_block_en = 1;
> +
> +struct i2c_client *anx7814_client;

A single global client isn't going to work.  It is easy to imagine a
machine with more than one anx78xx, requiring multiple instances of
the driver and hence multiple i2c clients.

Also, you'll want to be a bit more consistent with naming; is the
driver for anx78xx?  Or 

Re: [PATCH v4 10/13] usb: hcd: Adapt to OTG core

[Peter Chen]

On Mon, Aug 24, 2015 at 04:21:21PM +0300, Roger Quadros wrote:
> The existing usb_add/remove_hcd() functionality
> remains unchanged for non-OTG devices. For OTG
> devices they only register the HCD with the OTG core.
> 
> Introduce usb_otg_add/remove_hcd() for use by OTG core.
> These functions actually add/remove the HCD.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/core/hcd.c | 55 
> +-
>  1 file changed, 50 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index c0fd1f6..4851682 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -46,6 +46,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "usb.h"
>  
> @@ -2625,8 +2626,8 @@ static void usb_put_invalidate_rhdev(struct usb_hcd 
> *hcd)
>   * buffers of consistent memory, register the bus, request the IRQ line,
>   * and call the driver's reset() and start() routines.
>   */
> -int usb_add_hcd(struct usb_hcd *hcd,
> - unsigned int irqnum, unsigned long irqflags)
> +static int usb_otg_add_hcd(struct usb_hcd *hcd,
> +unsigned int irqnum, unsigned long irqflags)

You may change the kernel doc to this name too.

>  {
>   int retval;
>   struct usb_device *rhdev;
> @@ -2839,17 +2840,16 @@ err_phy:
>   }
>   return retval;
>  }
> -EXPORT_SYMBOL_GPL(usb_add_hcd);
>  
>  /**
> - * usb_remove_hcd - shutdown processing for generic HCDs
> + * usb_otg_remove_hcd - shutdown processing for generic HCDs
>   * @hcd: the usb_hcd structure to remove
>   * Context: !in_interrupt()
>   *
>   * Disconnects the root hub, then reverses the effects of usb_add_hcd(),
>   * invoking the HCD's stop() method.
>   */
> -void usb_remove_hcd(struct usb_hcd *hcd)
> +static void usb_otg_remove_hcd(struct usb_hcd *hcd)
>  {
>   struct usb_device *rhdev = hcd->self.root_hub;
>  
> @@ -2923,6 +2923,51 @@ void usb_remove_hcd(struct usb_hcd *hcd)
>  
>   usb_put_invalidate_rhdev(hcd);
>  }
> +
> +static struct otg_hcd_ops otg_hcd_intf = {
> + .add = usb_otg_add_hcd,
> + .remove = usb_otg_remove_hcd,
> +};
> +
> +/**
> + * usb_add_hcd - finish generic HCD structure initialization and register
> + * @hcd: the usb_hcd structure to initialize
> + * @irqnum: Interrupt line to allocate
> + * @irqflags: Interrupt type flags
> + *
> + * Finish the remaining parts of generic HCD initialization: allocate the
> + * buffers of consistent memory, register the bus, request the IRQ line,
> + * and call the driver's reset() and start() routines.
> + * If it is an OTG device then it only registers the HCD with OTG core.
> + *
> + */
> +int usb_add_hcd(struct usb_hcd *hcd,
> + unsigned int irqnum, unsigned long irqflags)
> +{
> + /* If OTG device, OTG core takes care of adding HCD */
> + if (usb_otg_register_hcd(hcd, irqnum, irqflags, _hcd_intf))
> + return usb_otg_add_hcd(hcd, irqnum, irqflags);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(usb_add_hcd);
> +
> +/**
> + * usb_remove_hcd - shutdown processing for generic HCDs
> + * @hcd: the usb_hcd structure to remove
> + * Context: !in_interrupt()
> + *
> + * Disconnects the root hub, then reverses the effects of usb_add_hcd(),
> + * invoking the HCD's stop() method.
> + * If it is an OTG device then it unregisters the HCD from OTG core
> + * as well.
> + */
> +void usb_remove_hcd(struct usb_hcd *hcd)
> +{
> + /* If OTG device, OTG core takes care of stopping HCD */
> + if (usb_otg_unregister_hcd(hcd))
> + usb_otg_remove_hcd(hcd);
> +}
>  EXPORT_SYMBOL_GPL(usb_remove_hcd);
>  
>  void
> -- 
> 2.1.4
> 

-- 

Best Regards,
Peter Chen
--
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 07/13] usb: otg: add OTG core

[Peter Chen]

On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
> 
> 
> On 08/09/15 11:31, Peter Chen wrote:
> > On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
> >> On 07/09/15 04:23, Peter Chen wrote:
> >>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>  + * This is used by the USB Host stack to register the Host controller
>  + * to the OTG core. Host controller must not be started by the
>  + * caller as it is left upto the OTG state machine to do so.
>  + *
>  + * Returns: 0 on success, error value otherwise.
>  + */
>  +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>  + unsigned long irqflags, struct otg_hcd_ops 
>  *ops)
>  +{
>  +struct usb_otg *otgd;
>  +struct device *hcd_dev = hcd->self.controller;
>  +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>  +
> >>>
> >>> One big problem here is: there are two designs for current (IP) driver
> >>> code, one creates dedicated hcd device as roothub's parent, like dwc3.
> >>> Another one doesn't do this, roothub's parent is core device (or otg 
> >>> device
> >>> in your patch), like chipidea and dwc2.
> >>>
> >>> Then, otg_dev will be glue layer device for chipidea after that.
> >>
> >> OK. Let's add a way for the otg controller driver to provide the host and 
> >> gadget
> >> information to the otg core for such devices like chipidea and dwc2.
> >>
> > 
> > Roger, not only chipidea and dwc2, I think the musb uses the same
> > hierarchy. If the host, device, and otg share the same register
> > region, host part can't be a platform driver since we don't want
> > to remap the same register region again.
> > 
> > So, in the design, we may need to consider both situations, one
> > is otg/host/device has its own register region, and host is a
> > separate platform device (A), the other is three parts share the
> > same register region, there is only one platform driver (B).
> > 
> > A:
> > 
> > IP core device 
> > |
> > |
> >   |-|-|
> >   gadget   host platform device 
> > |
> > roothub
> > 
> > B:
> > 
> > IP core device
> > |
> > |
> >   |-|-|
> >   gadget roothub
> > 
> > 
> >> This API must be called before the hcd/gadget-driver is added so that the 
> >> otg
> >> core knows it's linked to an OTG controller.
> >>
> >> Any better idea?
> >>
> > 
> > A flag stands for this hcd controller is the same with otg controller
> > can be used, this flag can be stored at struct usb_otg_config.
> 
> What if there is another architecture like so?
> 
> C:
>   [Parent]
>  |
>  |
>   |--|--|
>   [OTG core]  [gadget][host]
> 
> We need a more flexible mechanism to link the gadget and
> host device to the otg core for non DT case.
> 
> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
> 
> e.g.
> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
> 
> If otg is NULL it will try DT otg-controller property or parent to
> get the otg controller.

How usb_otg_register_hcd get struct usb_otg, from where?

> 
> > 
> > Peter
> > 
> > P.S: I still read your code, I find not all APIs in this file are used
> > in your dwc3 example. 
> 
> Which ones? The ones for registering/unregistered host/gadget are used
> by hcd/udc core as part of usb_add/remove_hcd() and
> udc_bind_to_driver()/usb_gadget_remove_driver()
> 

Ok, now I understand your design, usb_create_hcd must be called before
the fsm kicks off. The call flow like below:

usb_otg_register->usb_create_hcd->usb_add_hcd->usb_otg_register_hcd->
usb_otg_start_host->usb_otg_add_hcd

We need to make some changes to let chipidea work since usb_create_hcd
is included at host->start.

-- 

Best Regards,
Peter Chen
--
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: similar files amd vs radeon

[Deucher, Alexander]

> -Original Message-
> From: Peter Senna Tschudin [mailto:peter.se...@gmail.com]
> Sent: Monday, September 07, 2015 11:09 AM
> To: David Airlie; Deucher, Alexander; Koenig, Christian; Zhou, Jammy; dri-
> de...@lists.freedesktop.org; linux-kernel@vger.kernel.org
> Subject: similar files amd vs radeon
> 
> I executed a clone detection tool* on drivers source code and I found
> that there are similar files between drivers/gpu/drm/amd/ and
> drivers/gpu/drm/radeon, but also inside each of theses folders.
> 
> Some examples:
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c,drivers/gpu/drm/amd/amdgpu
> /dce_v10_0.c
> drivers/gpu/drm/amd/amdgpu/ci_dpm.c,drivers/gpu/drm/radeon/ci_dpm.c
> drivers/gpu/drm/radeon/kv_dpm.c,drivers/gpu/drm/amd/amdgpu/kv_dpm
> .c
> 
> I use meld for seeing the differences and similarities. More results
> from the tool at: http://pastebin.com/iX3fhifG (The number on the
> first field is the number of probable cloned lines of code).
> 
> Should these files be consolidated? And if so how?

No, they shouldn't be.  Amdgpu was forked from radeon to restructure the driver 
and support new asics.  However, due to the nature of the restructuring and our 
past experience with radeon, there's not much more we'd like to consolidate.  
We did the initial prototyping and bring up for amdgpu on CI parts (ci and kv) 
which are already supported in radeon since we wanted to use an asic that was 
already well supported in radeon so we had a good working base to compare 
against as we brought up the new driver.  The CI support in amdgpu however can 
be conditionally compiled out to avoid duplication of support.  The dce files 
are for specific versions of the display hw block.  Each hardware version is 
similar, but there are enough version specific differences that I'd rather not 
further consolidate the code to avoid bug fixes in one version regressing 
features in another version.

Alex

> 
> Thank you,
> 
> Peter
> 
> * https://github.com/petersenna/ccfinderx-core
> 
> --
> Peter
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

linux-next: Tree for Sep 9

[Stephen Rothwell]

Hi all,

Please do not add material for v4.4 until after v4.3-rc1 is out.

Changes since 20150908:

I used the h8300 tree from next-20150828 since the current tree has been
rebased onto something very old :-(

The drm-misc tree lost its build failure.

The kvm tree gained a build failure for which I reverted a commit.

The akpm tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1751
 1436 files changed, 84738 insertions(+), 20817 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), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final
link) and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 226 trees (counting Linus' and 33 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 (12f03ee60691 Merge tag 'libnvdimm-for-4.3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (3939f3345050 ARM: 8418/1: add boot image 
dependencies to not generate invalid images)
Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather 
than duplicating its implementation)
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 (daebaabb5cfb powerpc/pseries: Release DRC when 
configure_connector fails)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (46cdc9be0841 cxgb4: fix usage of uninitialized variable)
Merging ipsec/master (93efac3f2e03 ipv6: Fix IPsec pre-encap fragmentation 
check)
Merging sound-current/for-linus (5ee20bc79246 ALSA: usb-audio: Change internal 
PCM order)
Merging pci-current/for-linus (45ea2a5fed6d PCI: Don't use 64-bit bus addresses 
on PA-RISC)
Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module 
parameter for MSI interrupts)
Merging driver-core.current/driver-core-linus (cbfe8fa6cd67 Linux 4.2-rc4)
Merging tty.current/tty-linus (0de6cfb9f314 Revert "uart: pl011: Rename regs 
with enumeration")
Merging usb.current/usb-linus (f7644cbfcdf0 Linux 4.2-rc6)
Merging usb-gadget-fixes/fixes (c93e64e91248 usb: udc: core: add device_del() 
call to error pathway)
Merging usb-serial-fixes/usb-linus (d071a3cdd2e1 USB: qcserial: add HP lt4111 
LTE/EV-DO/HSPA+ Gobi 4G Module)
Merging staging.current/staging-linus (7d9071a09502 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging char-misc.current/char-misc-linus (f7644cbfcdf0 Linux 4.2-rc6)
Merging input-current/for-linus (01b944fe1cd4 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (71c6da846be4 crypto: ghash-clmulni: specify 
context size for ghash async algorithm)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (fee50f3c8427 selftests/futex: Fix 
futex_cmp_requeue_pi() error handling)
Merging backlight-fixes/for

Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

[Baoquan He]

Hi Sedat,

On 09/09/15 at 04:51am, Sedat Dilek wrote:
> On Wed, Sep 9, 2015 at 4:29 AM, Baoquan He  wrote:
> commit 1a1d48a4a8fde49aedc045d894efe67173d59fe0
> "linux/bitmap: Force inlining of bitmap weight functions"
> 
> ...on top of Linux v4.2.
> 
> This resulted in the same call-trace in QEMU.
> 
> I hacked around to only re-build mm/percpu.c with GCC (rest with
> CLANG) with some guidance from Linus (compiler warapper-script) etc.

Sorry, from below log message and code flow I didn't get what's wrong
with it. I am working on another issue which gives me much headache,
don't hvae time to look into the the disassembling code now. But if GCC
built code works, it should be related to compiler issues. You can try
more tests, e.g build percpu.c bitmap.c with GCC. Maybe other people
can give suggestions.

Sorry again, Sedat.

setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1 nr_node_ids:1

arch/x86/kernel/setup_percpu.c:setup_per_cpu_areas() ->
mm/percpu.c : pcpu_embed_first_chunk() ->
mm/percpu.c:pcpu_build_alloc_info() ->
include/linux/cpumask.h:
#define num_possible_cpus() cpumask_weight(cpu_possible_mask)
static inline unsigned int cpumask_weight(const struct cpumask *srcp)   
 
{
return bitmap_weight(cpumask_bits(srcp), nr_cpumask_bits);
}

include/linux/bitmap.h:
static inline int bitmap_weight(const unsigned long *src, unsigned int nbits)   
 
{
if (small_const_nbits(nbits))
return hweight_long(*src & BITMAP_LAST_WORD_MASK(nbits));
return __bitmap_weight(src, nbits);
}

lib/bitmap.c:
int __bitmap_weight(const unsigned long *bitmap, unsigned int bits)
{
unsigned int k, lim = bits/BITS_PER_LONG;
int w = 0;

for (k = 0; k < lim; k++)   
 
w += hweight_long(bitmap[k]);

if (bits % BITS_PER_LONG)
w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits));

return w;
}
EXPORT_SYMBOL(__bitmap_weight);

--
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] powerpc: Kconfig: remove BE-only platforms from LE kernel build

[Boqun Feng]

Hi Michael,

On Wed, Sep 09, 2015 at 12:26:44PM +1000, Michael Ellerman wrote:
> On Mon, 2015-09-07 at 07:58 +0800, Boqun Feng wrote:
> > diff --git a/arch/powerpc/platforms/cell/Kconfig 
> > b/arch/powerpc/platforms/cell/Kconfig
> > index 2f23133..808a904 100644
> > --- a/arch/powerpc/platforms/cell/Kconfig
> > +++ b/arch/powerpc/platforms/cell/Kconfig
> > @@ -25,7 +25,7 @@ config PPC_CELL_NATIVE
> >  
> >  config PPC_IBM_CELL_BLADE
> > bool "IBM Cell Blade"
> > -   depends on PPC64 && PPC_BOOK3S
> > +   depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN
> 
> We end up saying this five times.
> 
> We already have PPC_BOOK3S_64 which captures the first two conditions, should
> we add a PPC_BOOK3S_64_BE which expresses it all?
> 

I'm not sure whether this is worth.. IMO, we add a config option only if

1.  we can use this config somewhere in the code, for example,
"#ifdef CONFIG_XXX"
or

2.  we want to offer a option for users to choose.

PPC_BOOK3S_64_BE satisfies neither condition. Further more,
CONFIG_PPC64, CONFIG_PPC_BOOK3S and CONFIG_CPU_BIG_ENDIAN all are used
in some #ifdefs in current code. As a newbie of kernel, I'm happy to get
some knowledge like: "If I'm hacking PS3, then #ifndef CONFIG_PPC64 is
guaranteed to be false, so I can just ignore the code guarded by them".
But if we add a PPC_BOOK3S_64_BE, it will take a little more effort to
see this.

Regards,
Boqun


signature.asc
Description: PGP signature

RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Li Leo]

> On Thu, Aug 20, 2015 at 12:08:00PM +0800, Vinod Koul wrote:
> > On Mon, Aug 17, 2015 at 02:10:46PM -0500, Li Yang wrote:
> > > >> Think of it from the end user perspective. Would you like your
> > > >> laptop (or
> > > >> whatever) to refuse to suspend because of this condition? The
> > > >> user may well expect that closing the lid on their laptop will
> > > >> reliably lead to it suspending to ram. Returning a failure here
> > > >> could result in a loss of data if the condition is not detected
> > > >> and the machine
> > subsequently runs out of power.
> > > >>
> > > >
> > > > Yes, the user may well expect that closing the lid on their laptop
> > > > will reliably
> > lead to it suspending to ram.
> > > > So the client(the user of the DMA) must  to PAUSE or terminate the
> > > > DMA
> > transmission.
> > > >
> > > > We need to rely on client doing the right thing here.
> > > > The DMA should not make a decision instead of client.
> > > > If the DMA is not idle in DMA suspend, it should be the client's issue.
> > > > We don't know what the client really want to do, so just return
> > > > the non-
> > success value.
> > >
> > > The problem here is that neither the client nor the DMA controller
> > > driver should easily decide to stop the suspend entrance and rollback.
> > > I don't think the non-idle situation is serious enough to cause a
> > > rollback.  You should do whatever can be done with the DMA
> > > controller(such as stop the controller and leave whatever to be done
> > > to the wake up) and continue with the suspend.
> >
> > Ideally yes client should suspend first and dmaengine driver then
> > being idle when suspend is invoked. But we know we are in idle world!
> > So, driver should ensure it suspends the active channels and then goes
> > to suspend and restores that on resume
> >
> 
> Hi Vinod,
> Hi Leo,
> 
> Is there any other discussions?
> 
> I think we can have the following solutions for DMA driver:
> 1, Force terminate the active channels in its suspend and then return.
> 2, DMA have to wait until the active channels idle.
> 3, Don't care about the active channels and direct return.
> 4, Return BUS BUSY error and stop PM progress.
> 
> 
> I prefer the last one, because I think client should make sure the channel is 
> idle.
> 
> But also the first one should be works.

I agree that client should be responsible for cleaning up the pending requests. 
 My concern is that we shouldn't be triggering rewind by returning error if any 
client failed to do so.  I would suggest to complain about it with a message 
and continue to do whatever we can do at the DMA driver level and continue with 
the suspend.  So I would prefer the solution one.

Regards,
Leo

--
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] ASoC: atmel-classd: DT binding for Class D audio amplifier driver

[Wu, Songjun]

On 9/8/2015 20:23, Mark Brown wrote:

On Tue, Sep 08, 2015 at 05:36:13PM +0800, Wu, Songjun wrote:

On 9/8/2015 00:25, Mark Brown wrote:



Sure, there's no problem at all having that structure in software but it
should be possible to do this without having to represent this structure
in DT.  It should be possible to register the card at the same time as
the rest of the components rather than needing the separate device in
the DT.



Do you mean using a single entry in the DT for the whole classD system and
instantiate ASoC components from it.
For now, there are two entry, they could be combined to one entry.


Yes, exactly.


Accept. the two entries will be combined to one entry.
--
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/2] ASoC: atmel-classd: add the Audio Class D Amplifier code

[Wu, Songjun]

On 9/8/2015 20:23, Mark Brown wrote:

On Tue, Sep 08, 2015 at 05:36:01PM +0800, Wu, Songjun wrote:

On 9/8/2015 00:23, Mark Brown wrote:



OK, so that's not actually what the code was doing - it had separate
enums for bass, mid and treble.  If you make this a single enum with all
the above options in it that seems like the best way of handling things.



A single enum seems not very friendly to user, there are tree EQs, bass,
medium and treble.
So I create tree enum controls to control three EQs.
The 'get' function is replaced by 'classd_get_eq_enum', if user operates one
of the tree EQ controls, the other two EQs will show 0 dB.


If you want to have three controls you need to write code so that the
user can only change one of them from 0dB at once, returning an error
otherwise.  That was why it looked like they were three separate
controls.

If user operates two or tree controls at the same time, for my 
understanding, these operations are serial actually in kernel, not 
parallel, and the last operation will be effective. I only write the 
function 'classd_get_eq_enum' to get the enumeration value, if user 
changes one of controls, the other controls will get 0dB. Is my 
understanding correct?

--
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: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

[Sedat Dilek]

On Wed, Sep 9, 2015 at 5:04 AM, Sedat Dilek  wrote:
> On Wed, Sep 9, 2015 at 4:51 AM, Sedat Dilek  wrote:
>> On Wed, Sep 9, 2015 at 4:29 AM, Baoquan He  wrote:
>>>
>>> Seems it happened when call num_possible_cpus() which is a inline
>>> function to call __bitmap_weight(). So did you check
>>> lib/bitmap.c:__bitmap_weight() by objdump?
>>>
>>> setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1 nr_node_ids:1
>>>
>>
>> [ CC->TO Denys ]
>>
>> Hi Boaquan,
>>
>> Thanks for your reply.
>>
>> I tried a lot in the meantime :-).
>>
>> For example I applied a patch from Denys Vlasenko ...
>>
>> commit 1a1d48a4a8fde49aedc045d894efe67173d59fe0
>> "linux/bitmap: Force inlining of bitmap weight functions"
>>
>> ...on top of Linux v4.2.
>>
>> This resulted in the same call-trace in QEMU.
>>
>> I hacked around to only re-build mm/percpu.c with GCC (rest with
>> CLANG) with some guidance from Linus (compiler warapper-script) etc.
>>
>> What do you need for outputs?
>> objdump of lib/bitmap.o?
>> From both builds - with GCC and CLANG?
>>
>> Please give me clear instructions, Thanks!
>>
>> Regards,
>> - Sedat -
>>
>> [1] 
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a1d48a4a8fde49aedc045d894efe67173d59fe0
>
> Below snippets against Linux v4.2 and Linux v4.2 plus llvmlinux-fixes
> (see file-attachment)...
> ( The patch "linux/bitmap: Force inlining of bitmap weight functions"
> from Denys was not applied. )
>
> [ lib-bitmap_o-objdump-drw_CLANG-3-7.txt ]
>
> 0670 <__bitmap_weight>:
>  670:   49 89 f8mov%rdi,%r8
>  673:   31 d2   xor%edx,%edx
>  675:   41 89 f1mov%esi,%r9d
>  678:   41 c1 e9 06 shr$0x6,%r9d
>  67c:   b8 00 00 00 00  mov$0x0,%eax
>  681:   74 26   je 6a9 <__bitmap_weight+0x39>
>  683:   31 d2   xor%edx,%edx
>  685:   45 89 camov%r9d,%r10d
>  688:   4c 89 c1mov%r8,%rcx
>  68b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
>  690:   48 8b 39mov(%rcx),%rdi
>  693:   e8 00 00 00 00  callq  698
> <__bitmap_weight+0x28>   694: R_X86_64_PC32
> __sw_hweight64-0x4
>  698:   89 d2   mov%edx,%edx
>  69a:   48 01 c2add%rax,%rdx
>  69d:   48 83 c1 08 add$0x8,%rcx
>  6a1:   41 ff cadec%r10d
>  6a4:   75 ea   jne690 <__bitmap_weight+0x20>
>  6a6:   44 89 c8mov%r9d,%eax
>  6a9:   40 f6 c6 3f test   $0x3f,%sil
>  6ad:   74 1c   je 6cb <__bitmap_weight+0x5b>
>  6af:   f7 de   neg%esi
>  6b1:   48 c7 c7 ff ff ff ffmov$0x,%rdi
>  6b8:   40 88 f1mov%sil,%cl
>  6bb:   48 d3 efshr%cl,%rdi
>  6be:   49 23 3c c0 and(%r8,%rax,8),%rdi
>  6c2:   e8 00 00 00 00  callq  6c7
> <__bitmap_weight+0x57>   6c3: R_X86_64_PC32
> __sw_hweight64-0x4
>  6c7:   01 d0   add%edx,%eax
>  6c9:   89 c2   mov%eax,%edx
>  6cb:   89 d0   mov%edx,%eax
>  6cd:   c3  retq
>  6ce:   66 90   xchg   %ax,%ax
>
> [ lib-bitmap_o-objdump-drw_GCC-4-9.txt ]
>
> 0d60 <__bitmap_weight>:
>  d60:   89 f1   mov%esi,%ecx
>  d62:   55  push   %rbp
>  d63:   49 89 famov%rdi,%r10
>  d66:   c1 e9 06shr$0x6,%ecx
>  d69:   85 c9   test   %ecx,%ecx
>  d6b:   48 89 e5mov%rsp,%rbp
>  d6e:   74 52   je dc2 <__bitmap_weight+0x62>
>  d70:   8d 41 fflea-0x1(%rcx),%eax
>  d73:   48 89 famov%rdi,%rdx
>  d76:   45 31 c0xor%r8d,%r8d
>  d79:   4c 8d 0c c5 08 00 00 00 lea0x8(,%rax,8),%r9
>  d81:   49 01 f9add%rdi,%r9
>  d84:   48 8b 3amov(%rdx),%rdi
>  d87:   48 83 c2 08 add$0x8,%rdx
>  d8b:   e8 00 00 00 00  callq  d90 <__bitmap_weight+0x30>
>  d8c: R_X86_64_PC32  __sw_hweight64-0x4
>  d90:   41 01 c0add%eax,%r8d
>  d93:   4c 39 cacmp%r9,%rdx
>  d96:   75 ec   jned84 <__bitmap_weight+0x24>
>  d98:   40 f6 c6 3f test   $0x3f,%sil
>  d9c:   44 89 c0mov%r8d,%eax
>  d9f:   74 1f   je dc0 <__bitmap_weight+0x60>
>  da1:   f7 de   neg%esi
>  da3:   89 ca   mov%ecx,%edx
>  da5:   48 c7 c0 ff ff ff ffmov

Re: [PATCH] ARM:mm: define arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case

[Nicolas Pitre]

On Tue, 8 Sep 2015, Sergey Dyasly wrote:

> On 08.09.2015 5:45, Zhang Zhen wrote:
> > The arch-specific IOREMAP_MAX_ORDER is introduced in
> > commit: ff0daca([ARM] Add section support to ioremap) and
> > commit: a069c89 ([ARM] 3705/1: add supersection support to ioremap()).
> > But supersections and sections mappings are only used in !SMP && !LPAE case.
> > Otherwise, mapping is created using the usual 4K pages.
> > 
> > In most cases without !SMP && !LPAE, the big alignment cause high
> > fragmentation
> > issue in vmalloc area.
> > Here we use arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case,
> > otherwise use generic IOREMAP_MAX_ORDER in include/linux/vmalloc.h.
> > 
> > Signed-off-by: Zhang Zhen 
> > ---
> >   arch/arm/include/asm/memory.h | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> > index b7f6fb4..3209012 100644
> > --- a/arch/arm/include/asm/memory.h
> > +++ b/arch/arm/include/asm/memory.h
> > @@ -76,10 +76,12 @@
> >*/
> >   #define XIP_VIRT_ADDR(physaddr)  (MODULES_VADDR + ((physaddr) &
> > 0x000f))
> > 
> > +#if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE)
> >   /*
> >* Allow 16MB-aligned ioremap pages
> >*/
> >   #define IOREMAP_MAX_ORDER 24
> > +#endif
> > 
> >   #else /* CONFIG_MMU */
> > 
> 
> Hmm... This looks exactly like my old patch -
> http://thread.gmane.org/gmane.linux.kernel.mm/127620
> (Thanks to Vladimir for pointing that out!)
> 
> Hasn't there been any progress about this issue?

IMHO the patch makes sense.

Did you send it to RMK's patch system?


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

Private Message

[J O'Neill & Co Solicitors]

I wish to inform you that my late client made his Inheritance in your favour, I 
advise you get in touch with me immediately 


J O'Neill
--
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] power: bq24261_charger: Add support for TI BQ24261 charger

[Fabio Estevam]

On Sun, Sep 6, 2015 at 2:23 PM, Ramakrishna Pallala
 wrote:

> +   chip->psy_usb = power_supply_register(>dev,
> +   _charger_desc, _cfg);
> +   if (IS_ERR(chip->psy_usb)) {
> +   dev_err(>dev,
> +   "power supply registration failed(%d)\n", ret);
> +   return ret;

You should not print and return ret here.

You should print and return IS_ERR(chip->psy_usb) 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/

[RFC] Generic PHY interface extention for dynamic configuration

[Shawn Lin]

Hi Kishon,

	Now, Generic PHY framework just provide four interfaces(AKA: 
init/exit/power_on/power_off). Also, these fours itfs take struct phy as
unique argument.Is it means that the generic PHY framework can't support 
to modify PHY configuration at run-time for diff cases?
	Actually I'm writing some code for supporting emmc controller's phy. 
And sometimes it indeed need to modify the phy's configuration. But I 
have no idea about how to deal with it in current framework. So I send 
this RFC to you and mailing.


Thanks.

--
Best Regards
Shawn Lin

--
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: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

[Sedat Dilek]

On Wed, Sep 9, 2015 at 4:29 AM, Baoquan He  wrote:
>
> Seems it happened when call num_possible_cpus() which is a inline
> function to call __bitmap_weight(). So did you check
> lib/bitmap.c:__bitmap_weight() by objdump?
>
> setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1 nr_node_ids:1
>

[ CC->TO Denys ]

Hi Boaquan,

Thanks for your reply.

I tried a lot in the meantime :-).

For example I applied a patch from Denys Vlasenko ...

commit 1a1d48a4a8fde49aedc045d894efe67173d59fe0
"linux/bitmap: Force inlining of bitmap weight functions"

...on top of Linux v4.2.

This resulted in the same call-trace in QEMU.

I hacked around to only re-build mm/percpu.c with GCC (rest with
CLANG) with some guidance from Linus (compiler warapper-script) etc.

What do you need for outputs?
objdump of lib/bitmap.o?
>From both builds - with GCC and CLANG?

Please give me clear instructions, Thanks!

Regards,
- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a1d48a4a8fde49aedc045d894efe67173d59fe0
--
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 V9 4/6] perf,tools: Dump per-sample freq/CPU%/CORE_BUSY% in report -D

[kan . liang]

From: Kan Liang 

The group read results from cycles/ref-cycles/TSC/ASTATE/MSTATE event
can be used to calculate the frequency, CPU Utilization and percent
performance during each sampling period.
This patch shows them in report -D.

Here is an example:

$ perf record --freq-perf  ~/tchain_edit

Here is one sample from perf report -D

1972044565107 0x3498 [0x88]: PERF_RECORD_SAMPLE(IP, 0x2): 10608/10608:
0x4005fd period: 564686 addr: 0
... sample_read:
 group nr 5
. id 0012, value 02143901
. id 0052, value 02143896
. id 0094, value 021e443d
. id 00d4, value 021db984
. id 0114, value 021db964
. Freq 2301 MHz
. CPU% 98%
. CORE_BUSY% 99%

Signed-off-by: Kan Liang 
Acked-by: Jiri Olsa 
---
 tools/perf/util/session.c | 28 +---
 tools/perf/util/session.h | 54 +++
 2 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 23fed17..ba763f7 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -7,7 +7,6 @@
 #include 
 
 #include "evlist.h"
-#include "evsel.h"
 #include "session.h"
 #include "tool.h"
 #include "sort.h"
@@ -878,8 +877,15 @@ static void perf_evlist__print_tstamp(struct perf_evlist 
*evlist,
printf("%" PRIu64 " ", sample->time);
 }
 
-static void sample_read__printf(struct perf_sample *sample, u64 read_format)
+static void sample_read__printf(struct perf_sample *sample,
+   struct perf_evsel *evsel)
 {
+   u64 read_format = evsel->attr.read_format;
+   struct perf_evlist *evlist = evsel->evlist;
+   struct perf_sample_id *sid;
+   perf_freq_t data = { 0 };
+   u64 cpu_max_freq = evlist->env->cpuattr.max_freq;
+
printf("... sample_read:\n");
 
if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED)
@@ -902,10 +908,26 @@ static void sample_read__printf(struct perf_sample 
*sample, u64 read_format)
printf(". id %016" PRIx64
   ", value %016" PRIx64 "\n",
   value->id, value->value);
+
+   sid = perf_evlist__id2sid(evlist, value->id);
+   evsel = sid->evsel;
+   if (evsel != NULL)
+   perf_freq__init(evlist->env->msr_pmu_type,
+   evsel, data, value->value);
}
} else
printf(". id %016" PRIx64 ", value %016" PRIx64 "\n",
sample->read.one.id, sample->read.one.value);
+
+   if (perf_freq__has_freq(data))
+   printf(". Freq %lu MHz\n",
+  perf_freq__get_freq(data, cpu_max_freq/1000));
+   if (perf_freq__has_cpu_util(data))
+   printf(". CPU%% %lu%%\n",
+  perf_freq__get_cpu_util(data));
+   if (perf_freq__has_core_busy(data))
+   printf(". CORE_BUSY%% %lu%%\n",
+  perf_freq__get_core_busy(data));
 }
 
 static void dump_event(struct perf_evlist *evlist, union perf_event *event,
@@ -965,7 +987,7 @@ static void dump_sample(struct perf_evsel *evsel, union 
perf_event *event,
printf("... transaction: %" PRIx64 "\n", sample->transaction);
 
if (sample_type & PERF_SAMPLE_READ)
-   sample_read__printf(sample, evsel->attr.read_format);
+   sample_read__printf(sample, evsel);
 }
 
 static struct machine *machines__find_for_cpumode(struct machines *machines,
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index 3915be7..83bf4a9 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -11,6 +11,7 @@
 #include "ordered-events.h"
 #include 
 #include 
+#include "evsel.h"
 
 struct ip_callchain;
 struct thread;
@@ -42,6 +43,10 @@ struct perf_session {
 #define PRINT_IP_OPT_ONELINE   (1<<4)
 #define PRINT_IP_OPT_SRCLINE   (1<<5)
 
+#define PERF_MSR_TSC   0
+#define PERF_MSR_APERF 1
+#define PERF_MSR_MPERF 2
+
 enum perf_freq_perf_index {
FREQ_PERF_TSC   = 0,
FREQ_PERF_APERF = 1,
@@ -52,6 +57,55 @@ enum perf_freq_perf_index {
FREQ_PERF_MAX
 };
 
+typedef u64 perf_freq_t[FREQ_PERF_MAX];
+
+static inline void perf_freq__init(unsigned int msr_pmu_type,
+   struct perf_evsel *evsel,
+   perf_freq_t array,
+   u64 value)
+{
+   if (evsel->attr.type == msr_pmu_type) {
+   if (evsel->attr.config == PERF_MSR_TSC)
+   array[FREQ_PERF_TSC] = value;
+   if (evsel->attr.config == PERF_MSR_APERF)
+   array[FREQ_PERF_APERF] = value;
+   if (evsel->attr.config == PERF_MSR_MPERF)
+  

[PATCH V9 6/6] perf,tools: Show freq/CPU%/CORE_BUSY% in perf report by --freq-perf

[kan . liang]

From: Kan Liang 

Show frequency, CPU Utilization and percent performance for each symbol
in perf report by --freq-perf

In sampling group, only group leader do sampling. So only need to print
group leader's freq in --group.

--freq-perf option also implies --group.

Here is an example.

$ perf report --stdio --freq-perf

 Overhead   FREQ MHz   CPU%  CORE_BUSY%
Command  Shared Object Symbol
   .  .  ..
...    ..

99.54%  99.54%  99.53%  99.53%  99.53%   2301 96 99
tchain_edit  tchain_edit   [.] f3
 0.20%   0.20%   0.20%   0.20%   0.20%   2301 98 99
tchain_edit  tchain_edit   [.] f2
 0.05%   0.05%   0.05%   0.05%   0.05%   2300 98 99
tchain_edit  [kernel.vmlinux]  [k] read_tsc

Signed-off-by: Kan Liang 
---
 tools/perf/Documentation/perf-report.txt | 12 ++
 tools/perf/builtin-report.c  | 25 ++-
 tools/perf/ui/hist.c | 71 +---
 tools/perf/util/hist.h   |  3 ++
 tools/perf/util/session.c| 33 ---
 tools/perf/util/sort.c   |  3 ++
 tools/perf/util/symbol.h | 12 +-
 7 files changed, 137 insertions(+), 22 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index b941d5e..9804e63 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -307,6 +307,18 @@ OPTIONS
special event -e cpu/mem-loads/ or -e cpu/mem-stores/. See
'perf mem' for simpler access.
 
+--freq-perf::
+   Show CPU frequency and performance result from sample read.
+   To generate the frequency and performance output, the perf.data file
+   must have been obtained by group read and using special events cycles,
+   ref-cycles, msr/tsc/, msr/aperf/ or msr/mperf/
+   Freq MHz: The frequency during the sample interval. Needs cycles and
+ ref-cycles event.
+   CPU%: CPU utilization during the sample interval. Needs ref-cycles and
+ msr/tsc/ events.
+   CORE_BUSY%: actual percent performance (APERF/MPERF%) during the
+   sample interval. Needs msr/aperf/ and msr/mperf/ events.
+
 --percent-limit::
Do not show entries which have an overhead under that percent.
(Default: 0).
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index d6e5203..bd466d8 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -134,7 +134,8 @@ static int hist_iter__report_callback(struct 
hist_entry_iter *iter,
struct branch_info *bi;
 
if ((iter->ops == _iter_normal) &&
-   perf_evsel__is_group_leader(evsel))
+   perf_evsel__is_group_leader(evsel) &&
+   symbol_conf.freq_perf)
set_he_freq_perf(rep->session, iter);
 
if (!ui__has_annotation())
@@ -785,6 +786,8 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_BOOLEAN(0, "demangle-kernel", _conf.demangle_kernel,
"Enable kernel symbol demangling"),
OPT_BOOLEAN(0, "mem-mode", _mode, "mem access profile"),
+   OPT_BOOLEAN(0, "freq-perf", _conf.freq_perf,
+   "show CPU freqency and performance info"),
OPT_CALLBACK(0, "percent-limit", , "percent",
 "Don't show entries under that percent", 
parse_percent_limit),
OPT_CALLBACK(0, "percentage", NULL, "relative|absolute",
@@ -803,7 +806,9 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
struct perf_data_file file = {
.mode  = PERF_DATA_MODE_READ,
};
+   struct perf_evsel *pos;
int ret = hists__init();
+   perf_freq_t freq_data_status = { 0 };
 
if (ret < 0)
return ret;
@@ -888,6 +893,24 @@ repeat:
symbol_conf.cumulate_callchain = false;
}
 
+
+   if (symbol_conf.freq_perf) {
+   symbol_conf.freq_perf_type = 0;
+   evlist__for_each(session->evlist, pos) {
+   perf_freq__init(session->header.env.msr_pmu_type,
+   pos, freq_data_status, 1);
+   }
+   if (perf_freq__has_freq(freq_data_status))
+   symbol_conf.freq_perf_type |= 1U << DISPLAY_FREQ;
+   if (perf_freq__has_cpu_util(freq_data_status))
+   symbol_conf.freq_perf_type |= 1U << DISPLAY_CPU_UTIL;
+   if (perf_freq__has_core_busy(freq_data_status))
+   symbol_conf.freq_perf_type |= 1U << DISPLAY_CORE_BUSY;
+
+   /* --freq-perf option imply --group */
+   symbol_conf.event_group = true;
+   }
+

[PATCH V9 1/6] perf,tools: introduce generic FEAT for CPU attributes

[kan . liang]

From: Kan Liang 

This patch introduces generic FEAT for CPU attributes. For the patch
set, we only need cpu max frequency. But it can be easily extented to
support more other CPU attributes.
The cpu max frequency is from the first online cpu.

Signed-off-by: Kan Liang 
Acked-by: Jiri Olsa 
---
 tools/perf/util/cpumap.c | 32 ++
 tools/perf/util/cpumap.h |  1 +
 tools/perf/util/header.c | 59 
 tools/perf/util/header.h | 12 ++
 4 files changed, 104 insertions(+)

diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
index a05d76a..671ee83 100644
--- a/tools/perf/util/cpumap.c
+++ b/tools/perf/util/cpumap.c
@@ -514,3 +514,35 @@ int cpu__setup_cpunode_map(void)
closedir(dir1);
return 0;
 }
+
+u64 get_cpu_max_freq(void)
+{
+   const char *mnt;
+   char path[PATH_MAX], tmp;
+   FILE *fp;
+   u64 freq;
+   int cpu = 0;
+   int ret;
+
+   mnt = sysfs__mountpoint();
+   if (!mnt)
+   return 0;
+
+   snprintf(path, PATH_MAX, "%s/devices/system/cpu/online", mnt);
+   fp = fopen(path, "r");
+   if (fp) {
+   ret = fscanf(fp, "%u%c", , );
+   fclose(fp);
+   if (ret < 1)
+   return 0;
+   }
+
+   snprintf(path, PATH_MAX, 
"%s/devices/system/cpu/cpu%d/cpufreq/cpuinfo_max_freq", mnt, cpu);
+   fp = fopen(path, "r");
+   if (!fp)
+   return 0;
+   ret = fscanf(fp, "%lu", );
+   fclose(fp);
+
+   return (ret == 1) ? freq : 0;
+}
diff --git a/tools/perf/util/cpumap.h b/tools/perf/util/cpumap.h
index 8982d53..06cd2c4 100644
--- a/tools/perf/util/cpumap.h
+++ b/tools/perf/util/cpumap.h
@@ -60,6 +60,7 @@ int max_node_num;
 int *cpunode_map;
 
 int cpu__setup_cpunode_map(void);
+u64 get_cpu_max_freq(void);
 
 static inline int cpu__max_node(void)
 {
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 8fd7b7d..3535dcb 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -885,6 +885,23 @@ write_it:
return do_write_string(fd, buffer);
 }
 
+static int write_cpu_attributes(int fd, struct perf_header *h __maybe_unused,
+   struct perf_evlist *evlist __maybe_unused)
+{
+   u32 tag_id;
+   u64 max_freq;
+   int ret;
+
+   tag_id = PERF_HEADER_CPU_MAX_FREQ;
+   ret = do_write(fd, _id, sizeof(tag_id));
+   if (ret < 0)
+   return ret;
+
+   max_freq = get_cpu_max_freq();
+
+   return do_write(fd, _freq, sizeof(max_freq));
+}
+
 static int write_branch_stack(int fd __maybe_unused,
  struct perf_header *h __maybe_unused,
   struct perf_evlist *evlist __maybe_unused)
@@ -1185,6 +1202,11 @@ static void print_cpuid(struct perf_header *ph, int fd 
__maybe_unused, FILE *fp)
fprintf(fp, "# cpuid : %s\n", ph->env.cpuid);
 }
 
+static void print_cpu_attributes(struct perf_header *ph, int fd 
__maybe_unused, FILE *fp)
+{
+   fprintf(fp, "# CPU attributes: max frequency = %lu KHz\n", 
ph->env.cpuattr.max_freq);
+}
+
 static void print_branch_stack(struct perf_header *ph __maybe_unused,
   int fd __maybe_unused, FILE *fp)
 {
@@ -1498,6 +1520,42 @@ static int process_cpuid(struct perf_file_section 
*section __maybe_unused,
return ph->env.cpuid ? 0 : -ENOMEM;
 }
 
+static int process_cpu_attributes(struct perf_file_section *section 
__maybe_unused,
+ struct perf_header *ph, int fd,
+ void *data __maybe_unused)
+{
+   ssize_t ret;
+   u32 i, tag_id;
+   u64 nr;
+
+   for (i = 0; i < PERF_HEADER_CPU_ATTR_MAX; i++) {
+
+   ret = readn(fd, _id, sizeof(tag_id));
+   if (ret != sizeof(tag_id))
+   return -1;
+
+   if (ph->needs_swap)
+   nr = bswap_32(tag_id);
+
+   if (tag_id >= PERF_HEADER_CPU_ATTR_MAX) {
+   pr_debug("The number of cpu attributes is not expected. 
"
+"You may need to upgrade the perf tool.\n");
+   return -1;
+   }
+
+   ret = readn(fd, , sizeof(nr));
+   if (ret != sizeof(nr))
+   return -1;
+
+   if (ph->needs_swap)
+   nr = bswap_64(nr);
+
+   ph->env.cpu_attr[tag_id] = nr;
+   }
+
+   return 0;
+}
+
 static int process_total_mem(struct perf_file_section *section __maybe_unused,
 struct perf_header *ph, int fd,
 void *data __maybe_unused)
@@ -1983,6 +2041,7 @@ static const struct feature_ops 
feat_ops[HEADER_LAST_FEATURE] = {
FEAT_OPP(HEADER_PMU_MAPPINGS,   pmu_mappings),
FEAT_OPP(HEADER_GROUP_DESC, group_desc),
FEAT_OPP(HEADER_AUXTRACE,   

[PATCH V9 5/6] perf,tools: caculate and save freq/CPU%/CORE_BUSY% in he_stat

[kan . liang]

From: Kan Liang 

Caculate freq/CPU%/CORE_BUSY% in add_entry_cb, and update the value in
he_stat.

Signed-off-by: Kan Liang 
Acked-by: Jiri Olsa 
---
 tools/perf/builtin-report.c | 36 
 tools/perf/util/sort.h  |  3 +++
 2 files changed, 39 insertions(+)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 4b43245..d6e5203 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -90,6 +90,38 @@ static int report__config(const char *var, const char 
*value, void *cb)
return perf_default_config(var, value, cb);
 }
 
+static void set_he_freq_perf(struct perf_session *session,
+struct hist_entry_iter *iter)
+{
+   struct hist_entry *he = iter->he;
+   struct perf_evsel *evsel = iter->evsel;
+   struct perf_evsel *leader = evsel;
+   struct perf_sample *sample = iter->sample;
+   struct perf_evlist *evlist = session->evlist;
+   u64 cpu_max_freq = session->header.env.cpuattr.max_freq;
+   perf_freq_t data = { 0 };
+   u64 nr = 0;
+
+   perf_freq__init(session->header.env.msr_pmu_type,
+   evsel, data,
+   sample->read.group.values[nr].value);
+   evlist__for_each_continue(evlist, evsel) {
+   if ((evsel->leader != leader) ||
+(++nr >= sample->read.group.nr))
+   break;
+   perf_freq__init(session->header.env.msr_pmu_type,
+   evsel, data,
+   sample->read.group.values[nr].value);
+   }
+
+   if (perf_freq__has_freq(data))
+   he->stat.freq = perf_freq__get_freq(data, cpu_max_freq/1000);
+   if (perf_freq__has_cpu_util(data))
+   he->stat.cpu_util = perf_freq__get_cpu_util(data);
+   if (perf_freq__has_core_busy(data))
+   he->stat.core_busy = perf_freq__get_core_busy(data);
+}
+
 static int hist_iter__report_callback(struct hist_entry_iter *iter,
  struct addr_location *al, bool single,
  void *arg)
@@ -101,6 +133,10 @@ static int hist_iter__report_callback(struct 
hist_entry_iter *iter,
struct mem_info *mi;
struct branch_info *bi;
 
+   if ((iter->ops == _iter_normal) &&
+   perf_evsel__is_group_leader(evsel))
+   set_he_freq_perf(rep->session, iter);
+
if (!ui__has_annotation())
return 0;
 
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 654ac8a..f39e287 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -54,6 +54,9 @@ struct he_stat {
u64 period_guest_us;
u64 weight;
u32 nr_events;
+   u64 freq;
+   u64 cpu_util;
+   u64 core_busy;
 };
 
 struct hist_entry_diff {
-- 
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/

[PATCH V9 2/6] perf,tools: read msr pmu type from header.

[kan . liang]

From: Kan Liang 

Get msr pmu type when processing pmu_mappings

Signed-off-by: Kan Liang 
Acked-by: Jiri Olsa 
---
 tools/perf/util/header.c | 3 +++
 tools/perf/util/header.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 3535dcb..04f415d 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1879,6 +1879,9 @@ static int process_pmu_mappings(struct perf_file_section 
*section __maybe_unused
/* include a NULL character at the end */
strbuf_add(, "", 1);
 
+   if (!strcmp(name, "msr"))
+   ph->env.msr_pmu_type = type;
+
free(name);
pmu_num--;
}
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index dd9f6b0..d9034e8 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -107,6 +107,7 @@ struct perf_env {
u64 max_freq;
} cpuattr;
};
+   unsigned intmsr_pmu_type;
 };
 
 struct perf_header {
-- 
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/

[PATCH V9 3/6] perf, record: introduce --freq-perf option

[kan . liang]

From: Kan Liang 

To generate the frequency and performance output, perf must sample read
special events like cycles, ref-cycles, msr/tsc/, msr/aperf/ or
msr/mperf/.
With the --freq-perf option, perf record can automatically check and add
those event into evlist for sampling read.

Signed-off-by: Kan Liang 
---
 tools/perf/Documentation/perf-record.txt |  4 
 tools/perf/builtin-record.c  | 39 +++-
 tools/perf/util/session.h| 10 
 3 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index 2e9ce77..3f40712 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -308,6 +308,10 @@ This option sets the time out limit. The default value is 
500 ms.
 Record context switch events i.e. events of type PERF_RECORD_SWITCH or
 PERF_RECORD_SWITCH_CPU_WIDE.
 
+--freq-perf::
+Add frequency and performance related events to do sample read.
+These events include cycles, ref-cycles, msr/tsc/, msr/aperf/ and msr/mperf/.
+
 SEE ALSO
 
 linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 142eeb3..e87dda3 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -13,7 +13,7 @@
 #include "util/util.h"
 #include "util/parse-options.h"
 #include "util/parse-events.h"
-
+#include "util/pmu.h"
 #include "util/callchain.h"
 #include "util/cgroup.h"
 #include "util/header.h"
@@ -50,6 +50,7 @@ struct record {
boolno_buildid;
boolno_buildid_cache;
longsamples;
+   boolfreq_perf;
 };
 
 static int record__write(struct record *rec, void *bf, size_t size)
@@ -948,6 +949,35 @@ out_free:
return ret;
 }
 
+const char *freq_perf_events[FREQ_PERF_MAX][3] = {
+   { "msr", "tsc", "msr/tsc/" },
+   { "msr", "aperf", "msr/aperf/" },
+   { "msr", "mperf", "msr/mperf/" },
+   { NULL, "cycles", "cycles" },
+   { NULL, "ref-cycles", "ref-cycles" },
+};
+
+static int
+record_add_freq_perf_events(struct perf_evlist *evlist)
+{
+   int i;
+   char freq_perf_attrs[100];
+
+   strcpy(freq_perf_attrs, "{cycles,ref-cycles");
+   for (i = 0; i < FREQ_PERF_MAX; i++) {
+   if ((i == FREQ_PERF_CYCLES) ||
+   (i == FREQ_PERF_REF_CYCLES))
+   continue;
+   if (pmu_have_event(freq_perf_events[i][0], 
freq_perf_events[i][1])) {
+   strcat(freq_perf_attrs, ",");
+   strcat(freq_perf_attrs, freq_perf_events[i][2]);
+   }
+   }
+   strcat(freq_perf_attrs, "}:S");
+
+   return parse_events(evlist, freq_perf_attrs, NULL);
+}
+
 static const char * const __record_usage[] = {
"perf record [] []",
"perf record [] --  []",
@@ -1096,6 +1126,8 @@ struct option __record_options[] = {
"per thread proc mmap processing timeout in ms"),
OPT_BOOLEAN(0, "switch-events", _switch_events,
"Record context switch events"),
+   OPT_BOOLEAN(0, "freq-perf", _perf,
+   "Add frequency and performance related events to do sample 
read."),
OPT_END()
 };
 
@@ -1157,6 +1189,11 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
if (rec->no_buildid_cache || rec->no_buildid)
disable_buildid_cache();
 
+   if (rec->freq_perf && record_add_freq_perf_events(rec->evlist)) {
+   pr_err("Cannot set up freq and performance events\n");
+   goto out_symbol_exit;
+   }
+
if (rec->evlist->nr_entries == 0 &&
perf_evlist__add_default(rec->evlist) < 0) {
pr_err("Not enough memory for event selector list\n");
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index b44afc7..3915be7 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -42,6 +42,16 @@ struct perf_session {
 #define PRINT_IP_OPT_ONELINE   (1<<4)
 #define PRINT_IP_OPT_SRCLINE   (1<<5)
 
+enum perf_freq_perf_index {
+   FREQ_PERF_TSC   = 0,
+   FREQ_PERF_APERF = 1,
+   FREQ_PERF_MPERF = 2,
+   FREQ_PERF_CYCLES= 3,
+   FREQ_PERF_REF_CYCLES= 4,
+
+   FREQ_PERF_MAX
+};
+
 struct perf_tool;
 
 struct perf_session *perf_session__new(struct perf_data_file *file,
-- 
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/

[PATCH V9 0/6] Freq/CPU%/CORE_BUSY% support

[kan . liang]

From: Kan Liang 

This patch set supports per-sample freq/CPU%/CORE_BUSY% print in perf
report.
For printing these information, the perf.data file must have been obtained
by group read and using special events cycles, ref-cycles, msr/tsc/,
msr/aperf/ or msr/mperf/.

 - Freq (MHz): The frequency during the sample interval. Needs cycles
   ref-cycles event.
 - CPU%: CPU utilization during the sample interval. Needs ref-cycles and
   msr/tsc/ events.
 - CORE_BUSY%: actual percent performance (APERF/MPERF%) during the
   sample interval. Needs msr/aperf/ and msr/mperf/ events.

Here is an example:

$ perf record --freq-perf ~/tchain_edit

$ perf report --stdio --freq-perf

 Overhead   FREQ MHz   CPU%  CORE_BUSY%
Command  Shared Object Symbol
   .  .  ..
...    ..

99.54%  99.54%  99.53%  99.53%  99.53%   2301 96 99
tchain_edit  tchain_edit   [.] f3
 0.20%   0.20%   0.20%   0.20%   0.20%   2301 98 99
tchain_edit  tchain_edit   [.] f2
 0.05%   0.05%   0.05%   0.05%   0.05%   2300 98 99
tchain_edit  [kernel.vmlinux]  [k] read_tsc

Changes since V1:
 - Save cpu max freq to header when recording
 - Read cpu max freq and msr type from header when reporting

Changes since V2:
 - Introduce generic FEAT for CPU related data stored
 - Make cpu max freq and msr type part of perf_session_env
 - rename cpu_u to cpu_util
 - Don't save sample value in perf_sample and discards new iterator.
   Calculating the freq_perf_info in add_entry_cb callback
 - Introduce symbol_conf.freq_perf_type for related hpp column visibility

Changes since V3:
 - add a identifier 'tag' for CPU attributes, max frequency.
 - add backpointers to evlist for env, and evsel for evlist.
 - Use bitmask for freq_perf_type
 - Replace macros by functions to caculate freq, cpu_util and core_busy
 - Move all caculation codes under symbol_conf.show_freq_perf condition.

Changes since V4:
 - Store cpu attributes id as tag and more readable cpu_attr

Changes since V5:
 - Rename freq to max_freq and use it
 - Add a loop in process_cpu_attributes to facility future extension

Changes since V6:
 - Split rename perf_session_env and add backpointer to evlist patches

Changes since V7:
 - Introduce --freq-perf option for perf record
 - Factor out fix for dump_sample

Changes since V8:
 - Rename --show-freq-perf to --freq-perf 
 - --freq-perf option imply --group

Kan Liang (6):
  perf,tools: introduce generic FEAT for CPU attributes
  perf,tools: read msr pmu type from header.
  perf, record: introduce --freq-perf option
  perf,tools: Dump per-sample freq/CPU%/CORE_BUSY% in report -D
  perf,tools: caculate and save freq/CPU%/CORE_BUSY% in he_stat
  perf,tools: Show freq/CPU%/CORE_BUSY% in perf report by --freq-perf

 tools/perf/Documentation/perf-record.txt |  4 ++
 tools/perf/Documentation/perf-report.txt | 12 ++
 tools/perf/builtin-record.c  | 39 +-
 tools/perf/builtin-report.c  | 59 ++
 tools/perf/ui/hist.c | 71 +---
 tools/perf/util/cpumap.c | 32 ++
 tools/perf/util/cpumap.h |  1 +
 tools/perf/util/header.c | 62 
 tools/perf/util/header.h | 13 ++
 tools/perf/util/hist.h   |  3 ++
 tools/perf/util/session.c| 31 --
 tools/perf/util/session.h| 64 
 tools/perf/util/sort.c   |  3 ++
 tools/perf/util/sort.h   |  3 ++
 tools/perf/util/symbol.h | 12 +-
 15 files changed, 399 insertions(+), 10 deletions(-)

-- 
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 V1 Resend 02/10] PM / OPP: Drop unlikely before IS_ERR(_OR_NULL)

[Viresh Kumar]

On 28-08-15, 15:52, Jiri Kosina wrote:
> With series like this, I usually wait a couple weeks and the pick the ones 
> which haven't been picked into maintainer trees (I check that by looking 
> for its presence in linux-next) through trivial.git afterwards.

Is it the right to get the remaining patches applied now?

-- 
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 v2 3/4] perf/x86/intel/pt: Add Intel PT logger

[Takao Indoh]

On 2015/09/08 18:48, Alexander Shishkin wrote:
> Takao Indoh  writes:
> 
>> +/* intel_pt */
>> +static struct perf_event_attr pt_attr_pt = {
>> +.config = 0x400, /* bit10: TSCEn */
> 
> Doesn't it make sense to make these things configurable via sysfs or
> whatnot?

That make sense, will do.

> 
>> +static int pt_log_buf_nr_pages = 128; /* number of pages for log buffer */
> 
> Same here.
> 
>> +static struct cpumask pt_log_cpu_mask;
>> +
>> +static DEFINE_PER_CPU(struct perf_event *, pt_perf_event_pt);
>> +static DEFINE_PER_CPU(struct perf_event *, pt_perf_event_sched);
>> +static DEFINE_PER_CPU(struct perf_event *, pt_perf_event_dummy);
>> +
>> +/* Saved registers on panic */
>> +static DEFINE_PER_CPU(u64, saved_msr_ctl);
>> +static DEFINE_PER_CPU(u64, saved_msr_status);
>> +static DEFINE_PER_CPU(u64, saved_msr_output_base);
>> +static DEFINE_PER_CPU(u64, saved_msr_output_mask);
>> +
>> +void save_intel_pt_registers(void)
>> +{
>> +int cpu = smp_processor_id();
>> +u64 ctl;
>> +
>> +if (!cpumask_test_cpu(cpu, _log_cpu_mask))
>> +return;
>> +
>> +/* Save RTIT_CTL register */
>> +rdmsrl(MSR_IA32_RTIT_CTL, ctl);
>> +per_cpu(saved_msr_ctl, cpu) = ctl;
>> +
>> +/* Stop tracing */
>> +ctl &= ~RTIT_CTL_TRACEEN;
>> +wrmsrl(MSR_IA32_RTIT_CTL, ctl);
>> +
>> +/* Save other registers */
>> +rdmsrl(MSR_IA32_RTIT_STATUS, per_cpu(saved_msr_status, cpu));
>> +rdmsrl(MSR_IA32_RTIT_OUTPUT_BASE, per_cpu(saved_msr_output_base, cpu));
>> +rdmsrl(MSR_IA32_RTIT_OUTPUT_MASK, per_cpu(saved_msr_output_mask, cpu));
> 
> I'd really like to keep the PT msr accesses confined to the intel_pt
> driver. Maybe have a similar function there? That way you could also use
> pt_config_start() instead of clearing TraceEn by hand.
> 
> Do you need these saved msr values for the crash tool? I'm guessing
> you'd need the write pointer to figure out where the most recent data
> is. But then again, if you go the perf_event_disable() path, it'll all
> happen automatically in the driver. Or rather __perf_event_disable()
> type of thing since this is strictly cpu-local. Or even
> event::pmu::stop() would do the trick. The buffer's write head would
> then be in this_cpu_ptr(_ctx)->handle.head.

Yes, what I need is the last position where Intel PT hardware wrote
data. Once kernel panic occurs, basically we should minimize the access
to kernel data or functions because they may be broken. That is why I
touch msr directly in this patch. But I agree to limit the access to msr
except intel_pt driver. Using pmu.stop() or pt_event_stop() looks good
to me.

Thanks,
Takao Indoh


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

Re: [PATCH V2 3/9] cpufreq: ondemand: only queue canceled works from update_sampling_rate()

[Viresh Kumar]

On 09-09-15, 03:06, Rafael J. Wysocki wrote:
> I've just realized that if you combined this patch with the [6/9],
> you wouldn't need to make any changes to gov_queue_work() at all,
> because that patch removes the case in point entirely.

Yeah, but then these are really two separate issues at hand and so I
solved them separately. Lemme know how you want to see that and I can
change :)

-- 
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: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

[Baoquan He]

Seems it happened when call num_possible_cpus() which is a inline
function to call __bitmap_weight(). So did you check
lib/bitmap.c:__bitmap_weight() by objdump?

setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1 nr_node_ids:1

Thanks
Baoquan
--
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] cpufreq: s5pv210: remove superfluous CONFIG_PM ifdefs

[Viresh Kumar]

On 08-09-15, 19:02, Bartlomiej Zolnierkiewicz wrote:
> CONFIG_PM ifdefs are superfluous and can be removed.
> 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  drivers/cpufreq/s5pv210-cpufreq.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/s5pv210-cpufreq.c 
> b/drivers/cpufreq/s5pv210-cpufreq.c
> index 9e231f5..ef5282b 100644
> --- a/drivers/cpufreq/s5pv210-cpufreq.c
> +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> @@ -576,10 +576,8 @@ static struct cpufreq_driver s5pv210_driver = {
>   .get= cpufreq_generic_get,
>   .init   = s5pv210_cpu_init,
>   .name   = "s5pv210",
> -#ifdef CONFIG_PM
>   .suspend= cpufreq_generic_suspend,
>   .resume = cpufreq_generic_suspend, /* We need to set SLEEP FREQ 
> again */
> -#endif
>  };
>  
>  static struct notifier_block s5pv210_cpufreq_reboot_notifier = {

Acked-by: Viresh Kumar 

-- 
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] cpufreq: tegra20: remove superfluous CONFIG_PM ifdefs

[Viresh Kumar]

On 08-09-15, 19:13, Bartlomiej Zolnierkiewicz wrote:
> CONFIG_PM ifdefs are superfluous and can be removed.
> 
> Cc: Stephen Warren 
> Cc: Thierry Reding 
> Cc: Alexandre Courbot 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  drivers/cpufreq/tegra20-cpufreq.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/tegra20-cpufreq.c 
> b/drivers/cpufreq/tegra20-cpufreq.c
> index 8084c7f..2bd6284 100644
> --- a/drivers/cpufreq/tegra20-cpufreq.c
> +++ b/drivers/cpufreq/tegra20-cpufreq.c
> @@ -175,9 +175,7 @@ static struct cpufreq_driver tegra_cpufreq_driver = {
>   .exit   = tegra_cpu_exit,
>   .name   = "tegra",
>   .attr   = cpufreq_generic_attr,
> -#ifdef CONFIG_PM
>   .suspend= cpufreq_generic_suspend,
> -#endif
>  };
>  
>  static int __init tegra_cpufreq_init(void)

Acked-by: Viresh Kumar 

-- 
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] powerpc: Kconfig: remove BE-only platforms from LE kernel build

[Michael Ellerman]

On Mon, 2015-09-07 at 07:58 +0800, Boqun Feng wrote:
> diff --git a/arch/powerpc/platforms/cell/Kconfig 
> b/arch/powerpc/platforms/cell/Kconfig
> index 2f23133..808a904 100644
> --- a/arch/powerpc/platforms/cell/Kconfig
> +++ b/arch/powerpc/platforms/cell/Kconfig
> @@ -25,7 +25,7 @@ config PPC_CELL_NATIVE
>  
>  config PPC_IBM_CELL_BLADE
>   bool "IBM Cell Blade"
> - depends on PPC64 && PPC_BOOK3S
> + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN

We end up saying this five times.

We already have PPC_BOOK3S_64 which captures the first two conditions, should
we add a PPC_BOOK3S_64_BE which expresses it all?

cheers


--
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] power: bq24261_charger: Add support for TI BQ24261 charger

[Andreas Dannenberg]

On Mon, Sep 07, 2015 at 12:57:56PM +0900, Krzysztof Kozlowski wrote:
> 2015-09-07 2:23 GMT+09:00 Ramakrishna Pallala :
> >
> > Add new charger driver support for BQ24261 charger IC.
> >
> > BQ24261 charger driver relies on extcon notifications to get the
> > charger cable type and based on that it will set the charging parameters.
> >
> > Signed-off-by: Ramakrishna Pallala 
> > Signed-off-by: Jennt TC 
> > ---
> >  .../devicetree/bindings/power/bq24261.txt  |   37 +
> >  drivers/power/Kconfig  |6 +
> >  drivers/power/Makefile |1 +
> >  drivers/power/bq24261_charger.c| 1208 
> > 
> >  include/linux/power/bq24261_charger.h  |   27 +
> >  5 files changed, 1279 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/power/bq24261.txt
> >  create mode 100644 drivers/power/bq24261_charger.c
> >  create mode 100644 include/linux/power/bq24261_charger.h
> >
> > diff --git a/Documentation/devicetree/bindings/power/bq24261.txt 
> > b/Documentation/devicetree/bindings/power/bq24261.txt
> > new file mode 100644
> > index 000..25fc5c4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/bq24261.txt
> > @@ -0,0 +1,37 @@
> > +Binding for TI bq24261 Li-Ion Charger
> 
> Please split the bindings into separate patch (the first patch in patchset).
> 
> > +
> > +Required properties:
> > +- compatible: Should contain one of the following:
> > +* "ti,bq24261"
> > +- reg: integer, i2c address of the device.
> > +- ti,charge-current: integer, default charging current (in mA);
> > +- ti,charge-voltage: integer, default charging voltage (in mV);
> > +- ti,termination-current: integer, charge will be terminated when current 
> > in
> > +constant-voltage phase drops below this value (in mA);
> > +- ti,max-charge-current: integer, maximum charging current (in mA);
> > +- ti,max-charge-voltage: integer, maximum charging voltage (in mV);
> > +- ti,min-charge-temperature: integer, minimum charging temperature (in 
> > DegC);
> > +- ti,max-charge-temperature: integer, maximum charging temperature (in 
> > DegC).
> 
> Before accepting "[PATCH 13/13] dt: power: bq24257-charger: Cover
> additional devices"
> http://www.spinics.net/lists/devicetree/msg92134.html
> 
> could you and Andreas figure out common bindings? Look at this:
> 
> +- ti,charge-current: integer, maximum charging current in uA.
> +- ti,charge-current: integer, default charging current (in mA);
> 
> Different meaning and different units. This is madness! :)
> 
> In the same time you are adding TI-common bindings (not device
> specific, there is no prefix) so I would expect exactly the same
> bindings if it is possible.

Krzysztof, good observation! In bq2425x_charger.c (formerly known as
bq24257_charger.c :) that I worked on the unit used was uA. At that time
I did a quick check and there didn't seem to be a clear standard whether
to use the "micro" or "milli" units - different drivers use different
units. However there seems to be a tendency for the TI drivers to prefer
"milli" (bq2415x_charger.c, bq24735-charger.c)

Personally I think "milli" units are more appropriate for chargers since
they provide sufficient granularity and the numbers don't become too big
(try typing a voltage in the Volt-range in uV, it's very easy to get the
number of 0s wrong). However since the driver was already there I left
that aspect alone to preserve compatibility.

> > +
> > +Optional properties:
> > +- ti,thermal-sensing: boolean, if present thermal regulation will be 
> > enabled;
> 
> What is the requirement for thermal-sensing? Can it be enabled always?
> If yes, then this is not really a hardware property.
> 
> > +- ti,enable-user-write: boolean, if present driver will allow the user 
> > space
> > +to control the charging current and voltage through sysfs;
> 
> This is not DT property. It does not describe hardware.

I take responsibility for this one :) In an earlier thread we were
discussing that it will be better to prevent sysfs write access to
"dangerous" charger parameters (charge voltage, current, ...) but I
argued that such access might still be desirable during development and
debug, and that a DT property could be used to allow such write access
(with the default being the charger properties being made read-only) -
this way giving the best of both worlds. However then when I updated the
bq24157_charger.c driver I ended up not really needing and implementing
this feature.

Out of curiosity, if it against best-practice to expose non hardware
properties, how would one best address the above use case? Compile time
switch? A sysfs property that allows write-enabling the other sysfs
properties (doesn't sound right). Or...?

--
Andreas Dannenberg
Texas Instruments Inc

> Best regards,
> Krzysztof
> 
> > +
> > +Example:
> > +
> > +bq25890 {
> > +compatible = "ti,bq24261
> > +reg = <0x6b>;
> > +
> > + 

[PATCH 1/3] lib/kobject_uevent.c: disable broadcast of uevents to other namespaces

[Michael J. Coss]

Restrict sending uevents to only those listeners operating in the same
network namespace as the system init process.  This is the first step
toward allowing policy control of the forwarding of events to other
namespaces in userspace.

Signed-off-by: Michael J. Coss 
---
 lib/kobject_uevent.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index f6c2c1e..d791e33 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -295,6 +295,10 @@ int kobject_uevent_env(struct kobject *kobj, enum 
kobject_action action,
if (!netlink_has_listeners(uevent_sock, 1))
continue;
 
+   /* forward event only to the host systems network namespaces */
+   if (!net_eq(sock_net(uevent_sock), _net))
+   continue;
+
/* allocate message with the maximum possible size */
len = strlen(action_string) + strlen(devpath) + 2;
skb = alloc_skb(len + env->buflen, GFP_KERNEL);
-- 
2.4.6

--
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] net/udevns: Netlink module to forward uevent to containers

[Michael J. Coss]

New generic netlink module to provide an interface with the new
forwarding interface for uevent.  The driver allows a user to
direct a uevent as read from the kernel to a specific network
namespace by providing the uevent message, and a target process id.
The uapi header file provides the message format.

Signed-off-by: Michael J. Coss 
---
 include/uapi/linux/Kbuild   |   1 +
 include/uapi/linux/udevns.h |  19 
 net/Kconfig |   1 +
 net/Makefile|   1 +
 net/udevns/Kconfig  |   9 
 net/udevns/Makefile |   5 ++
 net/udevns/udevns.c | 112 
 net/udevns/udevns.h |  19 
 8 files changed, 167 insertions(+)
 create mode 100644 include/uapi/linux/udevns.h
 create mode 100644 net/udevns/Kconfig
 create mode 100644 net/udevns/Makefile
 create mode 100644 net/udevns/udevns.c
 create mode 100644 net/udevns/udevns.h

diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index 1ff9942..9fb9c59 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -404,6 +404,7 @@ header-y += toshiba.h
 header-y += tty_flags.h
 header-y += tty.h
 header-y += types.h
+header-y += udevns.h
 header-y += udf_fs_i.h
 header-y += udp.h
 header-y += uhid.h
diff --git a/include/uapi/linux/udevns.h b/include/uapi/linux/udevns.h
new file mode 100644
index 000..f5702f5
--- /dev/null
+++ b/include/uapi/linux/udevns.h
@@ -0,0 +1,19 @@
+#ifndef _UDEVNS_H_
+#define _UDEVNS_H_
+
+enum udevns_msg_types {
+   UDEVNS_FORWARD_MSG = 0x1,
+   UDEVNS_CMD_MAX,
+};
+
+enum udevns_attr {
+   UDEVNS_UNSPEC,
+   UDEVNS_PID,
+   UDEVNS_MSG,
+   __UDEVNS_ATTR_MAX,
+};
+
+#define UDEVNS_ATTR_MAX (__UDEVNS_ATTR_MAX - 1)
+#define UDEVNS_VERSION 0x1
+
+#endif
diff --git a/net/Kconfig b/net/Kconfig
index 57a7c5a..465e288 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -54,6 +54,7 @@ source "net/packet/Kconfig"
 source "net/unix/Kconfig"
 source "net/xfrm/Kconfig"
 source "net/iucv/Kconfig"
+source "net/udevns/Kconfig"
 
 config INET
bool "TCP/IP networking"
diff --git a/net/Makefile b/net/Makefile
index 3995613..bde7775 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_HSR) += hsr/
 ifneq ($(CONFIG_NET_SWITCHDEV),)
 obj-y  += switchdev/
 endif
+obj-$(CONFIG_UDEVNS)   += udevns/
diff --git a/net/udevns/Kconfig b/net/udevns/Kconfig
new file mode 100644
index 000..367e650
--- /dev/null
+++ b/net/udevns/Kconfig
@@ -0,0 +1,9 @@
+config UDEVNS
+   tristate "UDEV namespace bridge"
+   depends on SYSFS
+   default n
+   help
+   This option enables support for explicit forwarding of UDEV 
events to
+   other network namespaces
+
+   If unsure, say N.
diff --git a/net/udevns/Makefile b/net/udevns/Makefile
new file mode 100644
index 000..44c6b12
--- /dev/null
+++ b/net/udevns/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the uevent namespace aware forwarder
+#
+#
+obj-$(CONFIG_UDEVNS) += udevns.o
diff --git a/net/udevns/udevns.c b/net/udevns/udevns.c
new file mode 100644
index 000..8b23751
--- /dev/null
+++ b/net/udevns/udevns.c
@@ -0,0 +1,112 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "udevns.h"
+
+#define DRIVER_AUTHOR "Michael J Coss "
+#define DRIVER_DESC   "new udev namespace bridge"
+#define DEVICE_NAME   "udevns"
+
+#ifdef MODULE
+#define UDEVNS_NAME (THIS_MODULE->name)
+#else
+#define UDEVNS_NAME "udevns"
+#endif
+
+#define UDEVNS_INFO(fmt, args...)   \
+   pr_info("[%s] " fmt, UDEVNS_NAME, ## args)
+
+#define UDEVNS_ERROR(fmt, args...)  \
+   pr_err("[ERROR:%s:%s] " fmt, UDEVNS_NAME, __func__, ## args)
+
+#define UDEVNS_WARNING(fmt, args...)\
+   pr_warn("[WARNING:%s:%s] " fmt, UDEVNS_NAME, __func__, ## args)
+
+static struct genl_family udevns_genl_family = {
+   .id  = GENL_ID_GENERATE,
+   .name= DEVICE_NAME,
+   .hdrsize = 0,
+   .version = UDEVNS_VERSION,
+   .maxattr = UDEVNS_ATTR_MAX,
+};
+
+static const struct nla_policy udevns_fmsgpolicy[UDEVNS_ATTR_MAX + 1] = {
+   [UDEVNS_PID] = { .type = NLA_U32 },
+   [UDEVNS_MSG] = { .type = NLA_STRING, .len =  UEVENT_BUFFER_SIZE},
+};
+
+static int udevns_forwardmsg(struct sk_buff *skb, struct genl_info *info)
+{
+   pid_t pid;
+   char *msg;
+   int msglen;
+   int err;
+
+   if (!info->attrs[UDEVNS_PID]) {
+   UDEVNS_WARNING("missing PID from UDEVNS_FORWARD_MSG.\n");
+   return -EINVAL;
+   }
+
+   if (!info->attrs[UDEVNS_MSG]) {
+   UDEVNS_WARNING("missing uevent from UDEVNS_FORWARD_MSG.\n");
+   return -EINVAL;
+   }
+
+   pid = nla_get_u32(info->attrs[UDEVNS_PID]);
+   

[PATCH 2/3] lib/kobject_uevent.c: add uevent forwarding function

[Michael J. Coss]

Adds capability to allow userspace programs to forward a given event to
a specific network namespace as determined by the provided pid.  In
addition, support for a per-namespace kobject_sequence counter was
added.  Sysfs was modified to return the correct event counter based on
the current network namespace.

Signed-off-by: Michael J. Coss 
---
 include/linux/kobject.h |  3 ++
 include/net/net_namespace.h |  3 ++
 kernel/ksysfs.c | 12 ++
 lib/kobject_uevent.c| 90 +
 4 files changed, 108 insertions(+)

diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index 637f670..d1bb509 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -215,6 +215,9 @@ extern struct kobject *firmware_kobj;
 int kobject_uevent(struct kobject *kobj, enum kobject_action action);
 int kobject_uevent_env(struct kobject *kobj, enum kobject_action action,
char *envp[]);
+#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
+int kobject_uevent_forward(char *buf, size_t len, pid_t pid);
+#endif
 
 __printf(2, 3)
 int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index e951453..a4013e5 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -134,6 +134,9 @@ struct net {
 #if IS_ENABLED(CONFIG_MPLS)
struct netns_mpls   mpls;
 #endif
+#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
+   u64 kevent_seqnum;
+#endif
struct sock *diag_nlsk;
atomic_tfnhe_genid;
 };
diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 6683cce..4bc15fd 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -21,6 +21,9 @@
 #include 
 
 #include /* rcu_expedited */
+#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
+#include 
+#endif
 
 #define KERNEL_ATTR_RO(_name) \
 static struct kobj_attribute _name##_attr = __ATTR_RO(_name)
@@ -33,6 +36,15 @@ static struct kobj_attribute _name##_attr = \
 static ssize_t uevent_seqnum_show(struct kobject *kobj,
  struct kobj_attribute *attr, char *buf)
 {
+#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
+   pid_t p = task_pid_vnr(current);
+   struct net *n = get_net_ns_by_pid(p);
+
+   if (n != ERR_PTR(-ESRCH)) {
+   if (!net_eq(n, _net))
+   return sprintf(buf, "%llu\n", n->kevent_seqnum);
+   }
+#endif
return sprintf(buf, "%llu\n", (unsigned long long)uevent_seqnum);
 }
 KERNEL_ATTR_RO(uevent_seqnum);
diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index d791e33..7589745 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -379,6 +379,96 @@ int kobject_uevent(struct kobject *kobj, enum 
kobject_action action)
 }
 EXPORT_SYMBOL_GPL(kobject_uevent);
 
+#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
+/**
+ * kobject_uevent_forward - forward event to specified network namespace
+ *
+ * @buf: event buffer
+ * @len: event length
+ * @pid: pid of network namespace
+ *
+ * Returns 0 if kobject_uevent_forward() is completed with success or the
+ * corresponding error when it fails.
+ */
+int kobject_uevent_forward(char *buf, size_t len, pid_t pid)
+{
+   int retval = 0;
+#if defined(CONFIG_NET)
+   struct uevent_sock *ue_sk;
+   struct net *pns;
+   char *p;
+   u64 num;
+
+   /* grab the network namespace of the provided pid */
+   pns = get_net_ns_by_pid(pid);
+   if (pns == ERR_PTR(-ESRCH))
+   return -ESRCH;
+
+   /* find sequence number in buffer */
+   p = buf;
+   num = 0;
+   while (p < (buf + len)) {
+   if (strncmp(p, "SEQNUM=", 7) == 0) {
+   int r;
+
+   p += 7;
+   r = kstrtoull(p, 10, );
+   if (r) {
+   put_net(pns);
+   return r;
+   }
+   break;
+   }
+   p += (strlen(p) + 1);
+   }
+
+   /* if we didn't see a valid seqnum, or none was present, return error */
+   if (num == 0) {
+   put_net(pns);
+   return -EINVAL;
+   }
+   /* update per namespace sequence number as needed */
+   if (pns->kevent_seqnum < num)
+   pns->kevent_seqnum = num;
+
+   list_for_each_entry(ue_sk, _sock_list, list) {
+   struct sock *uevent_sock = ue_sk->sk;
+   struct sk_buff *skb;
+
+   if (!netlink_has_listeners(uevent_sock, 1))
+   continue;
+   /*
+* only send to sockets share the same network namespace
+* as the passed pid
+*/
+   if (!net_eq(sock_net(uevent_sock), pns))
+   

[PATCH 0/3] kobject: support namespace aware udev

[Michael J. Coss]

Currently when a uevent occurs, the event is replicated and sent to every
listener on the kernel netlink socket, ignoring network namespaces boundaries,
forwarding events to every listener in every network namespace.

With the expanded use of containers, it would be useful to be able to
regulate this flow of events to specific containers.  By restricting
the events to only the host network namespace, it allows for a userspace
program to provide a system wide policy on which events are routed where.

A new kernel function (kobject_uevent_forward) was added which allows
forwarding a given message to any uevent listeners in the network namespace
of the specified pid and a generic netlink module was added to provide an
interface to that kernel function.  This allows a userspace program to be
able to read the uevents via the libudev, and apply a policy (drop, forward,
or modify), and sending those uevents to a specific network namespace, and
by association to a specific container.

By allowing a controlled flow of uevents to a container, it is possible
for the container to run udevd, processing the event as normal while
allowing the host to maintain control over what events are sent.

Michael J. Coss (3):
  lib/kobject_uevent.c: disable broadcast of uevents to other namespaces
  lib/kobject_uevent.c: add uevent forwarding function
  net/udevns: Netlink module to forward uevent to containers

 include/linux/kobject.h |   3 ++
 include/net/net_namespace.h |   3 ++
 include/uapi/linux/Kbuild   |   1 +
 include/uapi/linux/udevns.h |  19 
 kernel/ksysfs.c |  12 +
 lib/kobject_uevent.c|  94 +
 net/Kconfig |   1 +
 net/Makefile|   1 +
 net/udevns/Kconfig  |   9 
 net/udevns/Makefile |   5 ++
 net/udevns/udevns.c | 112 
 net/udevns/udevns.h |  19 
 12 files changed, 279 insertions(+)
 create mode 100644 include/uapi/linux/udevns.h
 create mode 100644 net/udevns/Kconfig
 create mode 100644 net/udevns/Makefile
 create mode 100644 net/udevns/udevns.c
 create mode 100644 net/udevns/udevns.h

-- 
2.4.6

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

Re: [PATCH v5 4/6] spi: bcm2835: new driver implementing auxiliar spi1/spi2 on the bcm2835 soc

[Eric Anholt]

ker...@martin.sperl.org writes:

> From: Martin Sperl 
>
> Implements spi master driver for the 2 auxiliar spi devices
> supported by the bcm2835 SOC.
>
> The driver does not implement native chip-selects but uses
> framework provided aribtrary GPIO-chip-selects.
>
> Requires soc-bcm2835-aux enable api to enable/disable HW blocks.
>
> Signed-off-by: Martin Sperl 
> ---
>  drivers/spi/Kconfig  |   12 +
>  drivers/spi/Makefile |1 +
>  drivers/spi/spi-bcm2835aux.c |  514 
> ++
>  3 files changed, 527 insertions(+)
>  create mode 100644 drivers/spi/spi-bcm2835aux.c
>
> Changelog:
>   v4->v5: added error-handling and deferred probing support
>   moved change to default-config to a separate patch
>   fixed Kconfig to add the correct dependency

Review comments as a diff, so you can git-am and squash them in if you
like.  If you take them all, you can add "Acked-by: Eric Anholt
".

I didn't know anything about SPI before tonight, but I've looked through
what you did and it looks solid when compared to the hardware docs I've
got.  The only functional comment I had that's not in my diff is that
you could probably reduce the transfer overhead by knowing that there
are 4 dwords in the transfer and receive FIFOs, so I think you could
write more before checking if you had to stop.

From e082c3b5ea32d3eb1a40b7f9b5a822ba307cf886 Mon Sep 17 00:00:00 2001
From: Eric Anholt 
Date: Tue, 8 Sep 2015 17:51:08 -0700
Subject: [PATCH] spi: Changes for Martin's aux spi driver.

The intention is for these to be review fixes squashed into his commit of the 
driver.

- Reset has to happen before the clock gate is disabled, since
  register writes wouldn't take effect.

- Typo fixes.

- Dropped unnecessary regs/defines.

- Dropped custom clock enable/disable, assuming we use the aux clock
  driver instead.

Signed-off-by: Eric Anholt 
---
 drivers/spi/Kconfig  |  5 ++---
 drivers/spi/spi-bcm2835aux.c | 45 ++--
 2 files changed, 8 insertions(+), 42 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index cdb3dba..20854d4 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -89,16 +89,15 @@ config SPI_BCM2835
  not supported.
 
 config SPI_BCM2835AUX
-   tristate "BCM2835 SPI auxiliar controller"
+   tristate "BCM2835 SPI auxiliary controller"
depends on ARCH_BCM2835 || COMPILE_TEST
depends on GPIOLIB
-   select SOC_BCM2835_AUX
help
  This selects a driver for the Broadcom BCM2835 SPI aux master.
 
  The BCM2835 contains two types of SPI master controller; the
  "universal SPI master", and the regular SPI controller.
- This driver is for the universal/auxiliar SPI controller.
+ This driver is for the universal/auxiliary SPI controller.
 
 config SPI_BFIN5XX
tristate "SPI controller driver for ADI Blackfin5xx"
diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index d968647..3451ecb 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -1,5 +1,5 @@
 /*
- * Driver for Broadcom BCM2835 SPI Controllers
+ * Driver for Broadcom BCM2835 auxiliary SPI Controllers
  *
  * the driver does not rely on the native chipselects at all
  * but only uses the gpio type chipselects
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -38,27 +37,10 @@
 #include 
 
 /*
- * shared aux registers between spi1/spi2 and uart1
- *
- * these defines could go to a separate module if needed
- * so that it can also get used with the uart1 implementation
- * when it materializes.
- */
-
-/* the AUX register offsets */
-#define BCM2835_AUX_IRQ0x00
-#define BCM2835_AUX_ENABLE 0x04
-
-/* the AUX Bitfield identical for both register */
-#define BCM2835_AUX_BIT_UART   0x0001
-#define BCM2835_AUX_BIT_SPI1   0x0002
-#define BCM2835_AUX_BIT_SPI2   0x0004
-
-/*
  * spi register defines
  *
  * note there is garbage in the "official" documentation,
- * so somedata taken from the file:
+ * so some data is taken from the file:
  *   brcm_usrlib/dag/vmcsx/vcinclude/bcm2708_chip/aux_io.h
  * inside of:
  *   
http://www.broadcom.com/docs/support/videocore/Brcm_Android_ICS_Graphics_Stack.tar.gz
@@ -113,9 +95,6 @@
 #define BCM2835_AUX_SPI_MODE_BITS (SPI_CPOL | SPI_CPHA | SPI_CS_HIGH \
  | SPI_NO_CS)
 
-#define DRV_NAME   "spi-bcm2835aux"
-#define ENABLE_PROPERTY "brcm,aux-enable"
-
 struct bcm2835aux_spi {
void __iomem *regs;
struct clk *clk;
@@ -450,26 +429,17 @@ static int bcm2835aux_spi_probe(struct platform_device 
*pdev)
goto out_clk_disable;
}
 
-   /* enable HW block */
-   err = bcm2835aux_enable(>dev, ENABLE_PROPERTY);
-   if (err) {
-   dev_err(>dev, "could not enable aux: %d\n", err);
-   

Re: [GIT] Networking

[Konrad Rzeszutek Wilk]

On Tue, Sep 8, 2015 at 10:14 PM, Konrad Rzeszutek Wilk
 wrote:
>
> (Removed Linus and Andrew from the To, added Corinna ..)

and resending again without HTML (sorry, thought I had HTML-emails
disabled by default)
>
> On Thu, Sep 3, 2015 at 1:35 AM, David Miller  wrote:
>>
>>
>> Another merge window, another set of networking changes.  I've heard
>> rumblings that the lightweight tunnels infrastructure has been voted
>> networking change of the year.  But what do I know?
>>
> .. snip..
>>
>> Corinna Vinschen (2):
>>   r8169: Add values missing in @get_stats64 from HW counters
>
>
> .. cases an regression when SWIOTLB is in use. (See full attached serial 
> log), but
> the relevant snippet is:
>
> [   12.010065] BUG: sleeping function called from invalid context at 
> /home/konrad/ssd/konrad/linux/mm/page_alloc.c:3186
> [   12.88021e49b938 8174ff50 8800c6637748
> [   12.051548] ttyS1: 4 input overrun(s)
> [   12.055485]  8800c6637140 88021e49b958 810cf22e 
> 0001^G^G^G^G^G^G^G^G
> [   12.064566]   88021e49b988^G^G^G^G^G^G^G^G 
> 810cf2cd 88021e49b9b4
> [   12.073639] Call Trace:
> [   12.076156]  [] dump_stack+0x4f/0x68
> [   12.081444]  [] ___might_sleep+0xde/0x130
> [   12.087176]  [] __might_sleep+0x4d/0x90
> [   12.092731]  [] __alloc_pages_nodemask+0x26f/0xa20
> [   12.099271]  [] ? create_object+0x21e/0x2c0
> [   12.105183]  [] ? kmemleak_alloc+0x23/0x40
> [   12.111006]  [] ? kmem_cache_alloc_trace+0x184/0x190
> [   12.117721]  [] ? kmemleak_alloc+0x23/0x40
> [   12.123546]  [] dma_generic_alloc_coherent+0x9d/0x140
> [   12.130354]  [] x86_swiotlb_alloc_coherent+0x30/0x60
> [   12.137072]  [] dma_alloc_attrs+0x4c/0xb0
> [   12.142808]  [] rtl8169_update_counters+0x7e/0x150 
> [r8169]
> [   12.150061]  [] rtl8169_get_stats64+0xcb/0x130 [r8169]
> [   12.156956]  [] dev_get_stats+0x38/0x90
> [   12.162511]  [] dev_seq_printf_stats+0x23/0x100
> [   12.168786]  [] ? create_object+0x21e/0x2c0
> [   12.174715]  [] dev_seq_show+0xf/0x30
> [   12.180098]  [] seq_read+0x26a/0x400
> [   12.185384]  [] proc_reg_read+0x3e/0x70
> [   12.190943]  [] __vfs_read+0x2f/0xe0
> [   12.196245]  [] ? security_file_permission+0xa2/0xb0
> [   12.202972]  [] ? rw_verify_area+0x58/0xe0
> [   12.208799]  [] vfs_read+0x92/0xd0
> [   12.213908]  [] ? __fdget+0xe/0x10
> [   12.219024]  [] SyS_read+0x51/0xb0
> [   12.224140]  [] entry_SYSCALL_64_fastpath+0x12/0x71
>  done.
>
>  If I revert 6e85d5ad36a26debc23a9a865c029cbe242b2dc8 "r8169: Add values 
> missing in @get_stats64 from HW counters"
> I don't get this message.
>
> Thank you!
>>
>>


tst038
Description: Binary data

RE: [PATCH][rfc] intel_pstate: Fix user input of min/max to legal policy region

[Chen, Yu C]

Hi ,Rafael

> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Tuesday, September 08, 2015 5:47 AM
> To: Chen, Yu C; kris...@linux.intel.com
> Cc: viresh.ku...@linaro.org; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Zhang, Rui; l...@kernel.org
> Subject: Re: [PATCH][rfc] intel_pstate: Fix user input of min/max to legal
> policy region
> 
> On Wednesday, August 12, 2015 11:49:19 AM Chen Yu wrote:
> > In current code, if system is using performance policy, user can
> > modify the max_perf_pct to any values lower than 100:
> >
> > $ grep . /sys/devices/system/cpu/intel_pstate/m*_perf_pct
> > /sys/devices/system/cpu/intel_pstate/max_perf_pct:100
> > /sys/devices/system/cpu/intel_pstate/min_perf_pct:100
> >
> > $ echo 80 > /sys/devices/system/cpu/intel_pstate/max_perf_pct
> >
> > $ grep . /sys/devices/system/cpu/intel_pstate/m*_perf_pct
> > /sys/devices/system/cpu/intel_pstate/max_perf_pct:80
> > /sys/devices/system/cpu/intel_pstate/min_perf_pct:100
> >
> > the max_perf_pct above is lower than min_perf_pct, which is not
> > reasonable.
> >
> > This patch solves this problem by clamping min_perf_pct and
> > max_perf_pct to be strictly inside [min_policy_pct,max_policy_pct].
> >
> > Signed-off-by: Chen Yu 
> 
> Looks reasonable to me.
> 
> Kristen, any objections?
> 
Thanks for your reply! 
According to suggestion from  Seiichi, will re-send a V2 version patch,
to make some update.

Best Regards,
Yu 

Re: [[PATCH v6 09/10] powerpc/perf/hv-24x7: Use PMU_TXN_READ interface

[Michael Ellerman]

On Tue, 2015-09-08 at 13:29 +0200, Peter Zijlstra wrote:
> On Tue, Sep 08, 2015 at 07:07:55PM +1000, Michael Ellerman wrote:
> > On Thu, 2015-09-03 at 20:07 -0700, Sukadev Bhattiprolu wrote:
> > > The 24x7 counters in Powerpc allow monitoring a large number of counters
> > > simultaneously. They also allow reading several counters in a single
> > > HCALL so we can get a more consistent snapshot of the system.
> > > 
> > > Use the PMU's transaction interface to monitor and read several event
> > > counters at once. The idea is that users can group several 24x7 events
> > > into a single group of events. We use the following logic to submit
> > > the group of events to the PMU and read the values:
> > > 
> > >   pmu->start_txn()// Initialize before first event
> > > 
> > >   for each event in group
> > >   pmu->read(event);   // Queue each event to be read
> > > 
> > >   pmu->commit_txn()   // Read/update all queuedcounters
> > > 
> > > The ->commit_txn() also updates the event counts in the respective
> > > perf_event objects.  The perf subsystem can then directly get the
> > > event counts from the perf_event and can avoid submitting a new
> > > ->read() request to the PMU.
> > > 
> > > Thanks to input from Peter Zijlstra.
> > > 
> > > Signed-off-by: Sukadev Bhattiprolu 
> > > ---
> > >  arch/powerpc/perf/hv-24x7.c |  166 
> > > ++-
> > 
> > This looks fine to me from an arch perspective. I assume the whole series 
> > can
> > go via tip-something?
> 
> Yeah, I've had it queued for a few days, there was one s390 compile
> fail reported by the build-bot, which I've just fixed. So if nothing
> weird happens, it should hit tip somewhere this week.

Great, thanks.

Now Sukadev can focus on getting the JSON events support merged, hopefully it
won't require another 16 versions.

cheers


--
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] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n

[Michael Ellerman]

On Tue, 2015-09-08 at 17:19 -0600, Tim Gardner wrote:
> On 09/08/2015 04:47 PM, Paul Mackerras wrote:
> > On Tue, Sep 08, 2015 at 12:13:11PM -0600, tim.gard...@canonical.com wrote:
> >> From: Tim Gardner 
> >>
> >> commit 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx()
> >> routine available") neglected to define an empty inline replacement for
> >> enable_kernel_vsx() when CONFIG_VSX=n.
> > 
> > If code that wants to call enable_kernel_vsx() is getting compiled in
> > when CONFIG_VSX=n, that's a worry.  Is this patch motivated by an
> > actual compile failure?  If so what was the failure?
> 
> I was having link failures after backporting 'crypto: nx' patches to a
> 4.2 based kernel. You may have a point in that the upstream Kconfig will
> not allow those files to be compiled if CONFIG_VSX=n. I will check in my
> morning if to see if I can reproduce the same link error in mainline.

I suspect the problem is the "vmx" crypto actually.

$ git grep enable_kernel_vsx drivers/
drivers/crypto/vmx/aes.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
drivers/crypto/vmx/ghash.c: enable_kernel_vsx();
drivers/crypto/vmx/ghash.c: enable_kernel_vsx();
drivers/crypto/vmx/ghash.c: enable_kernel_vsx();
drivers/crypto/vmx/ghash.c: enable_kernel_vsx();


That appears to all be controlled by CONFIG_CRYPTO_DEV_VMX_ENCRYPT, which
depends on CONFIG_CRYPTO_DEV_VMX, which depends on PPC64.

So that looks like it will break terribly if VSX is turned off.

We do have an automated test build with VSX turned off, but it doesn't have
CONFIG_CRYPTO_DEV_VMX enabled :/


Having said all that, why are you building a ppc64 kernel with VSX turned off?

cheers


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

Re: [PATCH v2 2/4] perf: Add function to enable perf events in kernel with ring buffer

[Takao Indoh]

On 2015/09/08 18:32, Alexander Shishkin wrote:
> Takao Indoh  writes:
> 
>> perf_event_create_kernel_counter is used to enable perf events in kernel
>> without buffer for logging its events. This patch add new fucntion which
>> enable perf events with ring buffer. Intel PT logger uses this to enable
>> Intel PT and some associated events with its log buffer.
> 
> Have you seen [1] and related patches? I haven't gotten around to
> updating them yet, but hopefully it's going to happen soon.
> 
> The problem is that for such api to work, this memory needs to be
> accounted, especially when you start handling event inheritance. For
> system crash dump it doesn't really matter, but I also need a similar
> api for per-task core dumps, for example.

I have not seen this, I'll check it. You or someone else are working on
api for process core dump?

Thanks,
Takao Indoh

> 
> [1] https://lkml.org/lkml/2014/10/13/290
> 
> 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/

Re: [PATCH V4] thermal: cpu_cooling: Add MAINTAINERS entry

[Viresh Kumar]

On 27-08-15, 07:32, Viresh Kumar wrote:
> None of the patches are reaching Viresh or Daniel directly as
> get_maintainers doesn't report us as maintainers. Looks like file header
> or history of commits isn't able to do that properly.
> 
> Add a separate entry for cpu_cooling driver in MAINTAINERS.
> 
> Acked-by: Eduardo Valentin 
> Acked-by: Amit Daniel Kachhap 
> Acked-by: Amit Daniel Kachhap 
> Signed-off-by: Viresh Kumar 
> ---
> V4: Adding Javi as well into maintainers.
> 
>  MAINTAINERS | 10 ++
>  1 file changed, 10 insertions(+)

Ping !!

-- 
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 v5 0/6] bcm2835: auxiliar device support for spi

[Eric Anholt]

ker...@martin.sperl.org writes:

> From: Martin Sperl 
>
> The BCM2835 contains 3 auxiliar devices:
> * spi1
> * spi2
> * uart1
>
> All of those 3 devices are enabled/disabled via a shared register,
> which is set by default to be disabled.
>
> Access to this register needs to get serialized.
>
> So after several iterations of discussions with the following ideas:
> * syscon - device tree should describe HW not drivers to use -
>'compatiblity = "brcm,bcm2835-aux-enable", "syscon";'
>is not acceptable
> * regulator - it is not necessarily a regulator or a power gate
>   that is implemented in HW, so it is not valid to use
>   this framework
>
> The recommendation was made to create a new minimal API in soc
> just for access to this shared enable/disable register.
>
> This patch-series implements:
> * the bcm2835-auxiliar device enable/disable api in soc.
> * the bcm2835-auxiliar spi device driver
>
> The uart1 device driver (ns16550 based) is not implemented so far
> but would be using the same API.
>
> Both spi and uart drivers can run with shared interrupts,
> so there is no need for an interrupt-controller to get implemented.

I finally had a chance to sit down and look at what the hardware's doing
with the enable bit (also, I've read a whole lot more of the hardware
now, so I'm a lot faster at answering questions like this).  The enable
bits are a clock gate off of the VPU clock.

I knocked together the enable bits as a clock gate driver, since I'd
just written very similar code for the audio domain clock driver (and I
assume you are grumpy about how much time you've spent on this one
stupid register).  It's up at
https://github.com/anholt/linux/tree/bcm2835-clock-aux and I can submit
it if you like the result.  I've compile tested it only, but I'm hoping
you could just drop your aux SPI driver on top of it and have things
work.


signature.asc
Description: PGP signature

Re: [PATCH] ARM:mm: define arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case

[Zhang Zhen]

On 2015/9/9 2:12, Sergey Dyasly wrote:
> On 08.09.2015 5:45, Zhang Zhen wrote:
>> The arch-specific IOREMAP_MAX_ORDER is introduced in
>> commit: ff0daca([ARM] Add section support to ioremap) and
>> commit: a069c89 ([ARM] 3705/1: add supersection support to ioremap()).
>> But supersections and sections mappings are only used in !SMP && !LPAE case.
>> Otherwise, mapping is created using the usual 4K pages.
>>
>> In most cases without !SMP && !LPAE, the big alignment cause high 
>> fragmentation
>> issue in vmalloc area.
>> Here we use arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case,
>> otherwise use generic IOREMAP_MAX_ORDER in include/linux/vmalloc.h.
>>
>> Signed-off-by: Zhang Zhen 
>> ---
>>   arch/arm/include/asm/memory.h | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
>> index b7f6fb4..3209012 100644
>> --- a/arch/arm/include/asm/memory.h
>> +++ b/arch/arm/include/asm/memory.h
>> @@ -76,10 +76,12 @@
>>*/
>>   #define XIP_VIRT_ADDR(physaddr)  (MODULES_VADDR + ((physaddr) & 
>> 0x000f))
>>
>> +#if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE)
>>   /*
>>* Allow 16MB-aligned ioremap pages
>>*/
>>   #define IOREMAP_MAX_ORDER24
>> +#endif
>>
>>   #else /* CONFIG_MMU */
>>
> 
> Hmm... This looks exactly like my old patch -
> http://thread.gmane.org/gmane.linux.kernel.mm/127620
> (Thanks to Vladimir for pointing that out!)
> 
> Hasn't there been any progress about this issue?
> 
Oh sorry i didn't notice your old patch.
I send this patch because we encountered high fragmentation issue in vmalloc 
area
and the link about this issue.
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313040.html
Let's drop my patch.

Besides, i just want to know why this patch is not included into the upstream 
kernel?

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] atomics,cmpxchg: Privatize the inclusion of asm/cmpxchg.h

[Boqun Feng]

After commit:

atomics: add acquire/release/relaxed variants of some atomic operations

Architectures may only provide {cmp,}xchg_relaxed definitions in
asm/cmpxchg.h. Other variants, such as {cmp,}xchg, may be built in
linux/atomic.h, which means simply including asm/cmpxchg.h may not get
the definitions of all the{cmp,}xchg variants. Therefore, we should
privatize the inclusions of asm/cmpxchg.h to keep it only included in
arch/* and replace the inclusions outside with linux/atomic.h

Acked-by: Will Deacon 
Signed-off-by: Boqun Feng 
---
v1 --> v2:
1. rebase on current master branch of tip tree
2. remove documentation modification

 drivers/net/ethernet/sfc/mcdi.c | 2 +-
 drivers/phy/phy-rcar-gen2.c | 3 +--
 drivers/staging/speakup/selection.c | 2 +-
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/sfc/mcdi.c b/drivers/net/ethernet/sfc/mcdi.c
index 81640f8..968383e 100644
--- a/drivers/net/ethernet/sfc/mcdi.c
+++ b/drivers/net/ethernet/sfc/mcdi.c
@@ -9,7 +9,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include "net_driver.h"
 #include "nic.h"
 #include "io.h"
diff --git a/drivers/phy/phy-rcar-gen2.c b/drivers/phy/phy-rcar-gen2.c
index 6e0d9fa..c7a0599 100644
--- a/drivers/phy/phy-rcar-gen2.c
+++ b/drivers/phy/phy-rcar-gen2.c
@@ -17,8 +17,7 @@
 #include 
 #include 
 #include 
-
-#include 
+#include 
 
 #define USBHS_LPSTS0x02
 #define USBHS_UGCTRL   0x80
diff --git a/drivers/staging/speakup/selection.c 
b/drivers/staging/speakup/selection.c
index 98af3b1..aa5ab6c 100644
--- a/drivers/staging/speakup/selection.c
+++ b/drivers/staging/speakup/selection.c
@@ -7,7 +7,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "speakup.h"
 
-- 
2.5.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/3] net: irda: pxaficp_ir: convert to readl and writel

[Petr Cvek]

Dne 8.9.2015 v 22:24 Petr Cvek napsal(a):
> 
> Did you defined resources somewhere? Actual resources are in 
> "pxa_ir_resources" variable at:
> 
>   http://lxr.free-electrons.com/source/arch/arm/mach-pxa/devices.c#L386
> 
> or this pdata should be moved into specific machine files?
> 

I tried to add following patch for new resources, but now it fails with:

[  141.534545] pxa2xx-ir pxa2xx-ir: can't request region for resource [mem 
0x4070-0x40700100]
[  141.534574] pxa2xx-ir pxa2xx-ir: resource stuart not defined
[  141.534656] pxa2xx-ir: probe of pxa2xx-ir failed with error -16

That's because STUART is allocated by normal UART driver at:

http://lxr.free-electrons.com/source/arch/arm/mach-pxa/devices.c#L244

So somehow there must be configuration for STUART used with FICP and STUART 
alone (probably can be used for normal UART).


diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index 3543466..316ffa3 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -394,6 +394,26 @@ static struct resource pxa_ir_resources[] = {
.end= IRQ_ICP,
.flags  = IORESOURCE_IRQ,
},
+   [2] = {
+   .start  = 0x4080,
+   .end= 0x4080 + 0x100,
+   .flags  = IORESOURCE_MEM,
+   },
+   [3] = {
+   .start  = 0x4070,
+   .end= 0x4070 + 0x100,
+   .flags  = IORESOURCE_MEM,
+   },
+   [4] = {
+   .start  = 17,
+   .end= 17,
+   .flags  = IORESOURCE_DMA,
+   },
+   [5] = {
+   .start  = 18,
+   .end= 18,
+   .flags  = IORESOURCE_DMA,
+   },
 };
 
 struct platform_device pxa_device_ficp = {
-- 
1.7.12.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 1/3] sysfs: Fix is_visible() support for binary attributes

[Guenter Roeck]

Hi Emilio,

On 09/08/2015 05:51 PM, Emilio López wrote:

Hi Greg & Guenter,


[ ... ]


Unless I am missing something, this is not explained anywhere, but it is
not entirely trivial to understand. I think it should be documented.


I agree. I couldn't find any mention of what this int was supposed to be by 
looking at Documentation/ (is_visible is not even mentioned :/) or 
include/linux/sysfs.h. Once we settle on something I'll document it before 
sending a v2.


In the include file ? No strong preference, though.


By the way, I wrote a quick coccinelle script to match is_visible() users which 
reference the index (included below), and it found references to drivers which 
do not seem to use any binary attributes, so I believe changing the index 
meaning shouldn't be an issue.


Good.


I agree, make i the number of the bin attribute and that should solve
this issue.


No, that would conflict with the "normal" use of is_visible for non-binary
attributes, and make the index all but useless, since the is_visible function
would have to search through all the attributes anyway to figure out which one
is being checked.


Yeah, using the same indexes would be somewhat pointless, although not many 
seem to be using it anyway (only 14 files matched). Others seem to be comparing 
the attr* instead. An alternative would be to use negative indexes for binary 
attributes and positive indexes for normal attributes.


... and I probably wrote or reviewed a significant percentage of those ;-).

Using negative numbers for binary attributes is an interesting idea.
Kind of unusual, though. Greg, any thoughts on that ?

Guenter

--
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: set rockchip-specific uboot bootmode flags on reboot

[Andy Yan]

Hi Heiko:

On 2015年09月09日 06:46, Heiko Stübner wrote:

Hi Andy,

Am Dienstag, 8. September 2015, 20:43:07 schrieb Andy Yan:

rockchip platform have a protocol to pass the the kernel
reboot mode to bootloader by some special registers when
system reboot.By this way the bootloader can take different
action according to the different kernel reboot mode, for
example, command "reboot loader" will reboot the board to
rockusb mode, this is a very convenient way to get the board
to download mode.

Signed-off-by: Andy Yan

[...]


@@ -0,0 +1,22 @@
+#ifndef __MACH_ROCKCHIP_LOADER_H
+#define __MACH_ROCKCHIP_LOADER_H
+
+/*high 24 bits is tag, low 8 bits is type*/
+#define SYS_LOADER_REBOOT_FLAG   0x5242C300
+
+enum {
+   BOOT_NORMAL = 0, /* normal boot */
+   BOOT_LOADER, /* enter loader rockusb mode */
+   BOOT_MASKROM,/* enter maskrom rockusb mode (not support now) */
+   BOOT_RECOVER,/* enter recover */
+   BOOT_NORECOVER,  /* do not enter recover */
+   BOOT_SECONDOS,   /* boot second OS (not support now)*/
+   BOOT_WIPEDATA,   /* enter recover and wipe data. */
+   BOOT_WIPEALL,/* enter recover and wipe all data. */
+   BOOT_CHECKIMG,   /* check firmware img with backup part*/
+   BOOT_FASTBOOT,   /* enter fast boot mode */
+   BOOT_SECUREBOOT_DISABLE,
+   BOOT_CHARGING,   /* enter charge mode */
+   BOOT_MAX /* MAX VALID BOOT TYPE.*/
+};
+#endif

These flags rely on code in the bootloader to actually handle the target
action. Nowadays this is uboot, but still a rockchip-specific fork. And we're
actively moving away from that, with the recent rk3288 addition to mainline
uboot.
   Sorry, I don't know about this action before, but this is really a 
very convenient way

   to get machine enter download mode, it seems that many Android devices
   have this function to support commands like "reboot recovery", 
"reboot fastboot".

   Why should we moving away from that?

So unless you convince uboot people that the _underlying special
functionality_ behind these flags should be part of uboot, I don't think this
is going to fly.


In a way this is similar to gpu kernel code talking to proprietary userspace
libs - these are also not eligible for the kernel. (meaning stuff like the
mali kernel driver not being allowed).

[...]


+static int rockchip_reboot_notify(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+   u32 flag;
+
+   rockchip_get_reboot_flag(cmd, );
+   regmap_write(regmap, flag_reg, flag);
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block rockchip_reboot_handler = {
+   .notifier_call = rockchip_reboot_notify,
+   .priority = 150,
+};

the restart handlers are meant to really only restart the system, not to
execute some actions before the restart happens.

Seehttps://lkml.org/lkml/2015/6/3/707  for a similar case.


   So maybe I can use reboot notifier here?
  Thank you.

Heiko






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

Re: [RFC PATCH v3] Fix: clocksource watchdog marks TSC unstable on guest VM

[Shaohua Li]

On Tue, Sep 08, 2015 at 05:08:03PM +0200, Thomas Gleixner wrote:
> On Tue, 8 Sep 2015, Mathieu Desnoyers wrote:
> > Introduce WATCHDOG_RETRY to bound the number of retry (in the
> > unlikely event of a bogus clock source for wdnow). If the
> > number of retry has been reached, disable the watchdog timer.
> 
> This does not make any sense at all. Why would the clocksource be
> bogus? I rather say, that the whole idea of trying to watchdog the TSC
> in a VM is bogus.
> 
> There is no guarantee, that the readout of the TSC and the watchdog is
> not disturbed by VM scheduling. Aside of that, the HPET emulation goes
> all the way back into qemu user land and the implementation itself
> does not make me more confident. Be happy that we don't support 64bit
> HPET in the kernel as that emulation code is completely broken.
> 
> I really have to ask the question WHY we actually do this. There is
> absolutely no point at all.
> 
> The TSC watchdog is there to catch a few issues with the TSC
> 
>1) Frequency changing behind the kernels back
> 
>2) SMM driven power safe state 'features' which cause the TSC to
>   stop
> 
>3) SMM fiddling with the TSC
> 
>4) TSC drifting apart on multi socket systems
> 
> #1Is completely irrelevant for KVM as all machines which have
>   hardware virtualization have a frequency constant TSC
> 
> #2Is irrelevant for KVM as well, because the machine does not go
>   into deep idle states while the guest is running.
> 
> #3/#4 That are the only relevant issues, but there is absolutely no
>   need to do this detection in the guest.
> 
> We already have a TSC sanity check on the host. So instead of adding
> horrible hackery and magic detection, shutoff, retry mechanisms, we
> can simply let the guest know, that the TSC has been buggered.
> 
> On paravirt kernels we can do that today and AFAICT the
> pvclock/kvmclock code has enough magic to deal with all the oddities
> already.
> 
> For non paravirt kernels which can read the TSC directly, we'd need a
> way to transport that information. A simple mechanism would be to
> query an emulated MSR from the watchdog which tells the guest the
> state of affairs on the host side. That would be a sensible and
> minimal invasive change on both host and guests.

This will require every hypervisor supports the MSR, so not a solution
we can expect immediately.

I'm wondering why we can't just make the watchdog better to detect this
watchdog wrap. It can happen in physical machine as I said before, but I
can't find a simple way to trigger it, so it's not very convincing. But
the watchdog doesn't work for specific environment (for exmaple, a bogus
hardware doesn't responsond for some time) for sure, we shouldn't assume
the world is perfect.

Thanks,
Shaohua
--
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: Regression: can't apply frequency offsets above 1000ppm.

[Nuno Gonçalves]

Yes please.

Tested-by: Nuno Goncalves 

Thanks,
Nuno

On Wed, Sep 9, 2015 at 1:52 AM, John Stultz  wrote:
> On Sat, Sep 5, 2015 at 6:41 AM, Nuno Gonçalves  wrote:
>> Considering your last message I just tried to use abs64 instead. Fixes
>> the problem for me.
>
> Yea, I've since simplified my patch in the same way.
>
> Still looking good? Can I get a Tested-by: from you?
>
> thanks
> -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: IPMI updates for 4.3

[Linus Torvalds]

Corey,

 just for your information: this pull request doesn't show up with my
normal merge-window search pattern of "git pull", because you never
actually say "pull" anywhere.

Please use a subject with "[GIT PULL]" prefix (preferred), or just
change the body of the email to have a "please pull" in it or
something.  I get too much email, and particularly during the merge
window it really helps if I can keep my pull emails separate from
other stuff by just having them match a simple pattern.

As it is, I almost missed it. I went "ahh, all pending pull requests
done, but let's double-check.."

 Linus

On Thu, Sep 3, 2015 at 1:28 PM, Corey Minyard  wrote:
> The following changes since commit dd5cdb48edfd34401799056a9acf61078d773f90:
>
>   Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> (2015-09-03 08:08:17 -0700)
>
> are available in the git repository at:
>
>   git://git.code.sf.net/p/openipmi/linux-ipmi tags/for-linus-4.3
> ...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] sysfs: Fix is_visible() support for binary attributes

[Emilio López]

Hi Greg & Guenter,

On 08/09/15 16:30, Guenter Roeck wrote:

On Tue, Sep 08, 2015 at 12:10:02PM -0700, Greg KH wrote:

On Tue, Sep 08, 2015 at 08:30:13AM -0700, Guenter Roeck wrote:

Emilio,

On Tue, Sep 08, 2015 at 09:07:44AM -0300, Emilio López wrote:

According to the sysfs header file:

 "The returned value will replace static permissions defined in
  struct attribute or struct bin_attribute."

but this isn't the case, as is_visible is only called on
struct attribute only. This patch adds the code paths required
to support is_visible() on binary attributes.

Signed-off-by: Emilio López 
---
  fs/sysfs/group.c | 22 ++
  1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 39a0199..eb6996a 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -37,10 +37,10 @@ static int create_files(struct kernfs_node *parent, struct 
kobject *kobj,
  {
struct attribute *const *attr;
struct bin_attribute *const *bin_attr;
-   int error = 0, i;
+   int error = 0, i = 0;

if (grp->attrs) {
-   for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
+   for (attr = grp->attrs; *attr && !error; i++, attr++) {
umode_t mode = (*attr)->mode;

/*
@@ -73,13 +73,27 @@ static int create_files(struct kernfs_node *parent, struct 
kobject *kobj,
}

if (grp->bin_attrs) {
-   for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
+   for (bin_attr = grp->bin_attrs; *bin_attr; i++, bin_attr++) {
+   umode_t mode = (*bin_attr)->attr.mode;
+
if (update)
kernfs_remove_by_name(parent,
(*bin_attr)->attr.name);
+   if (grp->is_visible) {
+   mode = grp->is_visible(kobj,
+  &(*bin_attr)->attr, i);


With this, if 'n' is the number of non-binary attributes,

for i < n:
The index passed to is_visible points to a non-binary attribute.
for i >= n:
The index passed to is_visible points to the (index - n)th binary
attribute.

Unless I am missing something, this is not explained anywhere, but it is
not entirely trivial to understand. I think it should be documented.


I agree. I couldn't find any mention of what this int was supposed to be 
by looking at Documentation/ (is_visible is not even mentioned :/) or 
include/linux/sysfs.h. Once we settle on something I'll document it 
before sending a v2.


By the way, I wrote a quick coccinelle script to match is_visible() 
users which reference the index (included below), and it found 
references to drivers which do not seem to use any binary attributes, so 
I believe changing the index meaning shouldn't be an issue.



I agree, make i the number of the bin attribute and that should solve
this issue.


No, that would conflict with the "normal" use of is_visible for non-binary
attributes, and make the index all but useless, since the is_visible function
would have to search through all the attributes anyway to figure out which one
is being checked.


Yeah, using the same indexes would be somewhat pointless, although not 
many seem to be using it anyway (only 14 files matched). Others seem to 
be comparing the attr* instead. An alternative would be to use negative 
indexes for binary attributes and positive indexes for normal attributes.


Cheers,
Emilio

>8


// Find out is_visible() users which reference the index
// somehow

virtual report

@ func @
identifier visiblefun, i, j, n;
@@

visiblefun(struct kobject *i, struct attribute *j, int n)
{
<+...n...+>
}

@ attrib depends on func @
identifier aops;
identifier func.visiblefun;
position p0;
@@

struct attribute_group aops@p0 = {
...,
.is_visible = visiblefun,
...,
};

@script:python b_report depends on report@
p0 << attrib.p0;
@@

msg = "Suspicious is_visible(), please check."
coccilib.report.print_report(p0[0], msg)
--
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: Regression: can't apply frequency offsets above 1000ppm.

[John Stultz]

On Sat, Sep 5, 2015 at 6:41 AM, Nuno Gonçalves  wrote:
> Considering your last message I just tried to use abs64 instead. Fixes
> the problem for me.

Yea, I've since simplified my patch in the same way.

Still looking good? Can I get a Tested-by: from you?

thanks
-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: [PATCH v5 0/4] cpufreq-dt: add suspend frequency support

[Rafael J. Wysocki]

On Tuesday, September 08, 2015 06:41:00 PM Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> This patch series adds suspend frequency support (using opp-v2
> bindings and suspend-opp functionality) to cpufreq-dt driver and
> then adds suspend opp for Exynos4412 based boards.
> 
> This patch series fixes suspend/resume support on Exynos4412
> based Trats2 board and reboot hang on Exynos4412 based Odroid
> U3 board.
> 
> Changes since v4:
> - removed superfluous CONFIG_PM ifdefs
> - added Acked-by tag from Krzysztof to patch #4
> - added Acked-by tag from Viresh to patches #1-3
> 
> Changes since v3:
> - fixed dev_pm_opp_get_suspend_opp() locking
> - shortened variable name in dev_pm_opp_get_suspend_opp()
> - adjusted cpufreq_generic_suspend() to work with cpufreq-dt
> - removed no longer needed cpufreq_dt_suspend()
> - added Acked-by tag from Viresh to patch #4
> 
> Changes since v2:
> - rewrote to use suspend-opp functionality
> 
> Changes since v1:
> - removed superfluous ";"
> 
> Depends on:
> - next-20150902 branch of linux-next kernel tree

I've queued up [1-3/4] for the next PM pull request.

The [4/4] has to go in separately through the platform tree.

Thanks,
Rafael

--
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] staging: board: Migrate away from __pm_genpd_name_add_device()

[Rafael J. Wysocki]

On Tuesday, September 08, 2015 12:06:53 PM Greg Kroah-Hartman wrote:
> On Tue, Sep 08, 2015 at 07:06:03PM +0200, Geert Uytterhoeven wrote:
> > The named genpd APIs are deprecated. Hence convert the board staging
> > code from using genpd names to DT node paths.
> > 
> > For now this supports PM domains with "#power-domain-cells = <0>" only.
> > 
> > Signed-off-by: Geert Uytterhoeven 
> > Reviewed-by: Ulf Hansson 
> > ---
> > Rafael, Greg: If Greg provides his Acked-by, Rafael can apply this patch
> > to the linux-pm tree as a prerequisite for Ulf's patches to remove the
> > named genpd APIs.
> > 
> 
> Acked-by: Greg Kroah-Hartman 

Queued up for the next PM pull request, thanks!

Rafael

--
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] cpufreq: tegra20: remove superfluous CONFIG_PM ifdefs

[Rafael J. Wysocki]

On Tuesday, September 08, 2015 07:13:23 PM Bartlomiej Zolnierkiewicz wrote:
> CONFIG_PM ifdefs are superfluous and can be removed.
> 
> Cc: Stephen Warren 
> Cc: Thierry Reding 
> Cc: Alexandre Courbot 
> Signed-off-by: Bartlomiej Zolnierkiewicz 

What tree does this apply to?

> ---
>  drivers/cpufreq/tegra20-cpufreq.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/tegra20-cpufreq.c 
> b/drivers/cpufreq/tegra20-cpufreq.c
> index 8084c7f..2bd6284 100644
> --- a/drivers/cpufreq/tegra20-cpufreq.c
> +++ b/drivers/cpufreq/tegra20-cpufreq.c
> @@ -175,9 +175,7 @@ static struct cpufreq_driver tegra_cpufreq_driver = {
>   .exit   = tegra_cpu_exit,
>   .name   = "tegra",
>   .attr   = cpufreq_generic_attr,
> -#ifdef CONFIG_PM
>   .suspend= cpufreq_generic_suspend,
> -#endif
>  };
>  
>  static int __init tegra_cpufreq_init(void)
> 

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

Re: [PATCH] cpufreq: s5pv210: remove superfluous CONFIG_PM ifdefs

[Rafael J. Wysocki]

On Tuesday, September 08, 2015 07:02:12 PM Bartlomiej Zolnierkiewicz wrote:
> CONFIG_PM ifdefs are superfluous and can be removed.

I guess Kukjin can apply this one?

> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  drivers/cpufreq/s5pv210-cpufreq.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/s5pv210-cpufreq.c 
> b/drivers/cpufreq/s5pv210-cpufreq.c
> index 9e231f5..ef5282b 100644
> --- a/drivers/cpufreq/s5pv210-cpufreq.c
> +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> @@ -576,10 +576,8 @@ static struct cpufreq_driver s5pv210_driver = {
>   .get= cpufreq_generic_get,
>   .init   = s5pv210_cpu_init,
>   .name   = "s5pv210",
> -#ifdef CONFIG_PM
>   .suspend= cpufreq_generic_suspend,
>   .resume = cpufreq_generic_suspend, /* We need to set SLEEP FREQ 
> again */
> -#endif
>  };
>  
>  static struct notifier_block s5pv210_cpufreq_reboot_notifier = {
> 

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

Re: [PATCH v2] zram: introduce comp algorithm fallback functionality

[Sergey Senozhatsky]

On (09/08/15 19:42), Luis Henriques wrote:
> 
> Note that previously this operation (i.e. setting an invalid algorithm)
> would result in no algorithm being selected, which means that this
> represents a small change in the default behaviour.
> 

previously it would result in guaranteed to fail
echo xxx > /sys/block/zram/disksize
and thus in no device, not just "in no algorithm being selected".

comp_algorithm historically wasn't returning anything back to user space
and it always copied in its input (what later would have been used as a
compression algorithm name). yes, "wasn't returning anything back" is not
entirely correct, there was (and still is) a chance to receive -EBUSY, but
that was (and still is) is absolutely equivalent to
/sys/block/zram/initstate != 0

(well, I never had a clear understanding of why comp_algorithm and other
attrs return -EBUSY instead of simply silently ignoring the input; is it
really an error? there is a initstate attr for that, but I never had enough
reasons to change it either). anyway, believe me or not, that's what my toy
scripts were doing for years (and hopefully it's not because of the fact that
I'm completely unaware of the trivial basics of software development, as we
found out yesterday, but because zram ABI was letting me to do so).

# head -17 create-zram
---
#!/bin/sh

rmmod zram
modprobe zram

if [ -e /sys/block/zram0/initstate ]; then
initdone=`cat /sys/block/zram0/initstate`
if [ $initdone = 1 ]; then
echo "init done"
exit 1
fi
fi

echo 8 > /sys/block/zram0/max_comp_streams

echo $1 > /sys/block/zram0/comp_algorithm
cat /sys/block/zram0/comp_algorithm

---

So, "./create-zram LLZZOO 2G" will have different result now.


Other than that

Acked-by: Sergey Senozhatsky 

-ss

> Cc: Sergey Senozhatsky 
> Signed-off-by: Luis Henriques 
> ---
> Changes since v1:
>  * Moved the algorithm check further up, before mutex lock
>  * Dropped error path refactoring
>  * Updated commit text to explicitly refer to the ABI change
>  (changes suggested by Sergey and Minchan)
> 
> drivers/block/zram/zram_drv.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 9c01f5bfa33f..1caa8f793e51 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -365,6 +365,9 @@ static ssize_t comp_algorithm_store(struct device *dev,
>   struct zram *zram = dev_to_zram(dev);
>   size_t sz;
>  
> + if (!zcomp_available_algorithm(buf))
> + return -EINVAL;
> +
>   down_write(>init_lock);
>   if (init_done(zram)) {
>   up_write(>init_lock);
> @@ -378,9 +381,6 @@ static ssize_t comp_algorithm_store(struct device *dev,
>   if (sz > 0 && zram->compressor[sz - 1] == '\n')
>   zram->compressor[sz - 1] = 0x00;
>  
> - if (!zcomp_available_algorithm(zram->compressor))
> - len = -EINVAL;
> -
>   up_write(>init_lock);
>   return 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: [PATCH] ARM: qcom: add memory node to IPQ806x/AP148

[Stephen Boyd]

On 08/18, Mathieu Olivari wrote:
> On recent bootloaders, the bootloader patches the DT blob with memory
> information. However, with old bootloader, this operation doesn't
> happen, which leads the board to freeze in the early init code.
> 
> This patch adds the memory node to the AP148 dts explicitly to cover all
> boot cases.
> 
> Signed-off-by: Mathieu Olivari 

Does the old bootloader pass atags? If so we can just enable
CONFIG_ARM_ATAG_DTB_COMPAT and then we don't need to add anything
to dts files.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 3/9] cpufreq: ondemand: only queue canceled works from update_sampling_rate()

[Rafael J. Wysocki]

On Tuesday, September 08, 2015 07:28:31 AM Viresh Kumar wrote:
> On 08-09-15, 03:11, Rafael J. Wysocki wrote:
> > There really are two cases, either you pass a CPU or gov_queue_work() has to
> > walk policy->cpus.
> 
> Right (At least for now, we are doing just that.)
> 
> > Doing it the way you did hides that IMO.
> 
> Maybe. But I see it otherwise. Adding special meaning to a variable
> (like int cpu == -1 being the special case to specify policy->cpus)
> hides things morei, as we need to look at how it is decoded finally in
> the routine gov_queue_work().

Oh well.

I've just realized that if you combined this patch with the [6/9],
you wouldn't need to make any changes to gov_queue_work() at all,
because that patch removes the case in point entirely.

Thanks,
Rafael

--
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 4/9] cpufreq: governor: Drop __gov_queue_work()

[Rafael J. Wysocki]

On Tuesday, September 08, 2015 07:30:44 AM Viresh Kumar wrote:
> On 08-09-15, 03:15, Rafael J. Wysocki wrote:
> > On Monday, July 27, 2015 05:58:09 PM Viresh Kumar wrote:
> > > __gov_queue_work() isn't required anymore and can be merged with
> > > gov_queue_work(). Do it.
> > > 
> > > Signed-off-by: Viresh Kumar 
> > 
> > Quite frankly I don't see the point.
> 
> But isn't that just an unnecessary wrapper ?

It isn't a wrapper, just a separation of code executed in each step of
the loop.  There's nothing wrong with having a separate function for that
in principle.

I wouldn't make a fuss about that if that was new code even, so I don't
see why we should change it.

> > I'd even remove the inline from its definition and let the compiler decide
> > what to do with it.
> 
> What if the compiler decides to link it? Why add a function call for
> (almost) no use?

If the compiler does that, let it do it. :-)

If you think that you can outsmart the compiler people by doing such
optimizations at this level manually, you're likely wrong.  Serious
man-hours go into making that stuff work as well as it can in compilers.

Thanks,
Rafael

--
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] x86/efi: Map EFI memmap entries in-order at runtime

[joeyli]

Hi Matt,

On Tue, Sep 08, 2015 at 09:41:47PM +0100, Matt Fleming wrote:
> On Mon, 07 Sep, at 12:07:52PM, joeyli wrote:
> > 
> > This patch works to me on Intel S1200V3RPS to fix issue:
> > DMI: Intel Corporation (uefidk.com) Intel Server Board S1200V3RPS UEFI 
> > Development Kit/ROMLEY, BIOS 2.0
> > 
> > Tested-by: Lee, Chun-Yi 
> 
> When you say "fix issue", do you mean that your machine has the
> EFI_PROPERTIES_TABLE feature enabled, and that it doesn't boot without
> this patch?
> 
> -- 
> Matt Fleming, Intel Open Source Technology Center

Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't
boot without your patch.

I captured similar kernel oops through serial port:

[0.037745] ACPI: All ACPI Tables successfully acquired
[0.044666] BUG: unable to handle kernel paging request at fffef0e5d450
[0.052451] IP: [] 0xfffef0e5d450
[0.058291] PGD 1c0d067 PUD 17fcfd063 PMD 17fd6f063 PTE 0
[0.064355] Oops: 0010 [#1] SMP 
[0.067972] Modules linked in:
[0.071388] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.2.0-rc8-2.gc02428d-default #1
[0.080121] Hardware name: Intel Corporation (uefidk.com) Intel Server Board 
S1200V3RPS UEFI Development Kit/ROMLEY, BIOS 2.0 
[0.092827] task: 81c114c0 ti: 81c0 task.ti: 
81c0
[0.101172] RIP: 0010:[]  [] 
0xfffef0e5d450
[0.109724] RSP: :81c03d38  EFLAGS: 00010082
[0.115647] RAX: fffef0c5d100 RBX: fffef1d66040 RCX: fffef0c5d100
[0.123604] RDX: be366018 RSI:  RDI: 81c38b00
[0.131560] RBP: 000c R08: 81c03d70 R09: 81c38b0b
[0.139517] R10: 0078 R11: 0002 R12: 0296
[0.147475] R13: 81c03eb8 R14: 0030 R15: 0007
[0.155432] FS:  () GS:88042e60() 
knlGS:
[0.164457] CS:  0010 DS:  ES:  CR0: 80050033
[0.170864] CR2: fffef0e5d450 CR3: 0009b000 CR4: 000406b0
[0.178819] Stack:
[0.181059]  fffef10574c9 0002  

[0.189351]  81c38b00  fffef1057a4b 
0058
[0.197645]  00078000203c 0009b000 8801ffd7 
0009b000
[0.205939] Call Trace:
[0.208669]  [] ? efi_call+0x7e/0x100
[0.214497]  [] ? virt_efi_set_variable+0x66/0x90
[0.221487]  [] ? efi_delete_dummy_variable+0x77/0x90
[0.228866]  [] ? efi_enter_virtual_mode+0x3ac/0x3bb
[0.236147]  [] ? start_kernel+0x3f4/0x484
[0.242459]  [] ? early_idt_handler_array+0x120/0x120
[0.249835]  [] ? x86_64_start_reservations+0x2a/0x2c
[0.257212]  [] ? x86_64_start_kernel+0x13b/0x14a
[0.264200] Code:  Bad RIP value.
[0.267916] RIP  [] 0xfffef0e5d450
[0.273851]  RSP 
[0.277739] CR2: fffef0e5d450
[0.281436] ---[ end trace 19be7a419bfa9401 ]---
[0.286575] Kernel panic - not syncing: Attempted to kill the idle task!
[0.294049] Rebooting in 90 seconds..
[0.299184] ACPI MEMORY or I/O RESET_REG.


Thanks a lot!
Joey Lee
--
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: fsyscall

[Eric W. Biederman]

Andy Lutomirski  writes:

> On Tue, Sep 8, 2015 at 4:07 PM, Eric W. Biederman  
> wrote:

>> Perhaps I had missed it but I don't recall capsicum being able to wrap
>> things like reboot(2).
>>
>
> Ah, so you want to be able to grant BPF-defined capabilities :)

Pretty much.

Where I am focusing is turning Posix capabilities into real
capabilities.  I would not mind if the functionality was a bit more
general.  Say to be able to handle things like security labels, or
anywhere else you might reasonably be asked can you do X?

But I would be happy if we just managed to wrap the Posix capabilities
and turned them into real capablilities.

> Off the top of my head, I think that doing this using a nice IPC
> mechanism (which barely exists in Linux, but which seL4 and binder (!)
> can do very cleanly) would be simpler and more general, if less
> self-contained.

Less self-contained becomes a problem when you want to pass them between
processes written at different times between different people.  If there
is something conceptually simple we can implement in the kernel it
becomes worth it because that becomes the standard which everyone knows
to code to.

> (Aside: how on earth does anyone think that replacing binder with
> kdbus makes any sense?  Binder can pass capabilities, and kdbus can't.
> OTOH, maybe Android doesn't use the capability-passing ability.)

kdbus has file descriptor passing.  Beyond that no comment.

>> Which really describes what I am trying to tackle.  How do we create an
>> object that we can pass between processes that limits what we can do in
>> the case of the oddball syscalls that require special privileges.
>>
>> At the same time I still want the caller to be able to pass in data to
>> the system calls being called such as REBOOT_CMD_POWER_OFF versus
>> REBOOT_CMD_HALT, while being able to filter it and say you may not pass
>> REBOOT_CMD_CAD_OFF.
>>
>
> We could have a conservative whitelist of syscalls for which we allow
> this usage.  I'm a bit worried that there will be very limited use
> cases, given that a lot of use cases will want to follow pointers,
> which has TOCTOU problems.

Time of check to time of use problems.  Interesting point.

TOCTOU seems to make filtering of system calls in general much less
viable then I had hoped or imagined, and seems to be one of the better
arguments I have heard against ioctls.

I think the cases I care about are much less likely to have TOCTOU
problems than system calls in general, so I still may be ok.

However it does seem like past a certain point for good filtering the
entire syscall ABI needs to be turned into well defined IPC.  Ick!

Sigh.  I guess it is about time I dig up the places we call capable.
Ugh 1696 places in the kernel..  Even filtering out CAP_SYS_ADMIN and
CAP_NET_ADMIN the list is longer than I can easily look at. 

Still reboot isn't a problem ;)

Thinking abou the TOCTOU problems with system call filtering the only
general solution I can see is to handle it like the compat syscalls
but instead of copying things into a temporary on buffer in userspace
we copy the data into a temporary in-kernel buffer (filter the system call)
fs = get_fs();
set_fs(get_ds());
/* Call the system call */
set_fs(fs);

I don't like the whole set_fs() thing (especially if there is any data
we did not manage to copy).  But it seems like a good conceptual start.

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