Re: [Gta04-owner] [PATCH] mfd: twl4030-power: Support compatible = "ti, twl4030-power" again.

[Dr. H. Nikolaus Schaller]

Am 08.11.2014 um 01:22 schrieb NeilBrown :

> 
> commit e7cd1d1eb16fcdf53001b926187a82f1f3e1a7e6
>mfd: twl4030-power: Add generic reset configuration
> 
> claims:
>Let's add device tree support and configure things for warm reset
>as the default when compatible = "ti,twl4030-power".
> and
>Documentation/devicetree/bindings/mfd/twl4030-power.txt
> claims that "ti,twl4030-power" is still a valid "compatible" setting.
> 
> However the current driver fails to probe with that 'compatible'
> setting.
> Restore the old default.

I think this is a duplicate to 

599a1ca80d1d8269d54fdc4abdec8e65141381fe

(in linux-next)

> 
> Signed-off-by: NeilBrown 
> 
> diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> index 4d3ff3771491..1a7794f6be15 100644
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -776,6 +776,10 @@ static struct twl4030_power_data osc_off_idle = {
> 
> static struct of_device_id twl4030_power_of_match[] = {
>   {
> + .compatible = "ti,twl4030-power",
> + .data = NULL,
> + },
> + {
>   .compatible = "ti,twl4030-power-reset",
>   .data = _reset,
>   },
> ___
> Gta04-owner mailing list
> gta04-ow...@goldelico.com
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

--
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] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Stephen Warren]

On 11/07/2014 10:12 AM, Gordon Hollingworth wrote:
> Resend: HTML less...
> On 7 November 2014 17:07, Gordon Hollingworth  wrote:
>> On 7 November 2014 16:20, Noralf Tronnes  wrote:
...
>>> From the HAT specification:
>>> GPIO pins ID_SC and ID_SD (GPIO0 and GPIO1) are reserved for use solely
>>> for board detection / identification. The only allowed connections to
>>> the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect
>>> anything else to these pins!
>>>
>>> Ref:
>>> https://github.com/raspberrypi/hats/blob/master/designguide.md#gpio-requirements
>>>
>>> I asked in the forum if I could use an app for writing to the eeprom to
>>> change things like display rotation in the DT fragment, but was told that 
>>> this
>>> was a no-no. i2c0 is also used together with the camera port, which is then
>>> controlled by the firmware.
>>
>> The idea with the HAT specification is to provide a mechanism for hardware
>> developers to add their drivers and configuration in such a way as to avoid
>> 'special' kernel builds for particular bits of hardware (this was a problem
>> with a number of DAC add on boards for the Pi)

Have you considered using the (recently merged upstream) DT overlay
mechanism instead? In this case, the board EEPROM would simply provide a
unique ID for the board. Linux would obtain this ID somehow (perhaps
directly reading the EEPROM on boot, or perhaps having some special DT
node indicating which device was present if only the VC firmware can
access the EEPROM). The ID then gets used to look up a DT overlay file
that the kernel loads and merges into its DT at run-time. The benefit
here is that the DT overlay is a file in the filesystem, and can be
easily modified or replaced to fix issues, especially when first
developing that DT for a new HAT. This is all based on the way the
BeagleBone Black handles its capes. Having RPi work in a standard way
that's also used on other boards leverages people's knowledge/experience
across different HW stacks. Standards are good!

If I want to use U-Boot as a bootloader on the Pi, is there a VC
firmware mailbox message that the firmware can use to read the content
of the EEPROM (or the VC firmware's cached copy of it?) Or, must U-Boot
be modified to accept a DT, extract information from it, and then modify
the DT it subsequently passes to the kernel based on the DT it was passed?
--
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] ipvs: Keep skb->sk when allocating headroom on tunnel xmit

[Julian Anastasov]

Hello,

On Fri, 7 Nov 2014, Calvin Owens wrote:

> On 11/05/2014 01:21 AM, Julian Anastasov wrote:
> >
> >  Hello,
> >
> > On Tue, 4 Nov 2014, Calvin Owens wrote:
> >
> > > ip_vs_prepare_tunneled_skb() ignores ->sk when allocating a new
> > > skb, either unconditionally setting ->sk to NULL or allowing
> > > the uninitialized ->sk from a newly allocated skb to leak through
> > > to the caller.
> > >
> > > This patch properly copies ->sk and increments its reference count.
> > >
> > > Signed-off-by: Calvin Owens 
> >
> > Good catch. Please, extend your patch to
> > fix also the second place that has such error,
> > ip_vs_tunnel_xmit_v6. This call is missing from long time,
> > it was not needed. But commits that allow skb->sk (local
> > clients) already need it, eg.
> 
> I'm not sure where exactly you mean: ip_vs_tunnel_xmit_v6() calls
> ip_vs_prepare_tunneled_skb() to do the allocation, so this patch covers that
> case.
> 
> In older versions of the kernel, ip_vs_tunnel_xmit_v6() does it directly,
> could that be what you're looking at?

Sorry, it seems I was checking old branch.

Simon, please apply.

Acked-by: Julian Anastasov 

> > - f2428ed5e7bc89c7 ("ipvs: load balance ipv6 connections from a local
> > process"), 2.6.28
> > - 4856c84c1358b798 ("ipvs: load balance IPv4 connections from a local
> > process"), 2.6.28
> >
> > > ---
> > >   net/netfilter/ipvs/ip_vs_xmit.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > >
> > > diff --git a/net/netfilter/ipvs/ip_vs_xmit.c
> > > b/net/netfilter/ipvs/ip_vs_xmit.c
> > > index 437a366..bd90bf8 100644
> > > --- a/net/netfilter/ipvs/ip_vs_xmit.c
> > > +++ b/net/netfilter/ipvs/ip_vs_xmit.c
> > > @@ -846,6 +846,8 @@ ip_vs_prepare_tunneled_skb(struct sk_buff *skb, int
> > > skb_af,
> > > new_skb = skb_realloc_headroom(skb, max_headroom);
> > > if (!new_skb)
> > >   goto error;
> > > + if (skb->sk)
> > > + skb_set_owner_w(new_skb, skb->sk);
> > > consume_skb(skb);
> > > skb = new_skb;
> > >}

Regards

--
Julian Anastasov 
--
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] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Stephen Warren]

On 11/07/2014 09:20 AM, Noralf Tronnes wrote:
> Den 07.11.2014 05:22, skrev Stephen Warren:
>> On 11/06/2014 12:36 PM, Noralf Tronnes wrote:
>>> Den 06.11.2014 00:45, skrev Matthias Klein:
 The model B and B+ differ in the GPIO lines for ACT and PWR leds,
 and the
 I2S interface.
...
 + {
 +status = "okay";
 +clock-frequency = <10>;
 +};
 +
 + {
 +status = "okay";
 +clock-frequency = <10>;
 +};
 +
>>>
>>> Should the I2C busses be enabled by default?
>>
>> Yes, I think so. Whichever I2C controllers are actually connected to
>> something (even bare pins on an IO connector) should be enabled by the
>> DT, so that they're available for use.
>
> What makes i2c so special that it should be enabled by default?

I2C itself as a bus requires no configuration. If all you represent in
DT is an enabled controller, it's quite possible for SW to then go and
use the I2C bus in SW. Thus bus can be scanned to detect devices. The
user can instruct SW what address to communicate with and how. Etc.

> SPI is not enabled

SPI devices require extra configuration; the chip-select must be
configured for each device. It doesn't make sense to enable the SPI bus
without actually defining which devices are attached to it.

> and not 1wire, i2s, lirc either, they must be explicitly
> enabled.

I don't think there is a 1-wire controller on the RPi? There's certainly
no pin on the expansion header (at least in A/B/B-rev2) that's labeled
in a way that indicates 1-wire is the "default" purpose.

I2S typically requires other things to be set up to be useful, e.g.
communication with a (typically I2C-based) CODEC to configure it before
it'll accept I2S data.

lirc is more of a SW concept.

> The problem I see, is that this is a newbie platform, and having
> pins driven increases the chance of shorting something.

In the case of I2C at least, the pins are always pulled high by the I2C
pull-ups. Admittedly that's a weak drive. Either way though, you simply
need to take care when hooking things up. There's simply no way for SW
to make it completely fool-proof.

> And it's quite easy to enable these devices with fdtput.

DT include files might be better, or DT overlays.

>>> On Raspian, i2c is disabled
>>> by blacklisting the module (/etc/modprobe.d/raspi-blacklist.conf).
>>> At least i2c0 should be left disabled due to the HAT EEPROM and camera.
>>> The bus number has also changed with revisions:
>>> http://www.raspberrypi.org/forums/viewtopic.php?p=603950#p603950
>>
>> It sounds like for I2C-0 on the B+ should use the i2c-mux-pinctrl.c to
>> switch the bus between the two destinations as required, although we'd
>> have to confirm with Broadcom or the RPi Foundation that that would work
>> with this SoC.
>>
>> There's certainly no reason to believe that the kernel wouldn't want to
>> read the HAT EEPROM. After all, it has to identify what's connected
>> there.
>
> This will happen solely in the firmware.

Oh, given your comments below, does the firmware completely own I2C-0
both when it's used for EEPROM ID *and* when driving the camera module?
I had assumed all control of the camera module would be performed via
drivers in the Linux kernel, and hence I2C-0 would be driven by the
Linux kernel I2C driver. If this isn't the case, we should indeed make
sure that the kernel DTs don't touch the pinmux for the camera I2C port
at all. It'd also be quite disappointing, since it would make it
essentially impossible for anyone outside the RPi Foundation to connect
a different camera module that required different programming over I2C.

> The firmware reads the eeprom,
> and if it contains a DT fragment, it is merged with the dtb before handing
> it over to the kernel. As far as I know, this hasn't been implemented yet.

Hmm. It sounds like it'd be much better if the EEPROM contained a board
ID, and the board ID was passed into the kernel, which then used the
(recently merged upstream) DT overlays feature to load the overlay DT
once that kernel boots. IIUC this would also allow unloading and
reloading the overlay DT during development of the DT overlay.

> I asked if we couldn't use u-boot as the boot loader, but I was turned
> down.

I assume you mean in the official SD card images? Nothing is stopping
anyone from using it; I use it without issue for example.

> Personally I'm not happy about putting a lot stuff in a closed firmware,
> especially on a platform dedicated to getting kids into programming.

Indeed.

> From the HAT specification:
> GPIO pins ID_SC and ID_SD (GPIO0 and GPIO1) are reserved for use solely
> for board detection / identification. The only allowed connections to
> the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect
> anything else to these pins!
> 
> Ref:
> https://github.com/raspberrypi/hats/blob/master/designguide.md#gpio-requirements
> 
> I asked in the forum if I could use an app for writing to the eeprom to
> change things like 

[PATCH V5 7/7] dt-bindings: add document for dw-hdmi

[Andy Yan]

Signed-off-by: Andy Yan 
---
 .../devicetree/bindings/drm/bridge/dw-hdmi.txt | 38 ++
 1 file changed, 38 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw-hdmi.txt

diff --git a/Documentation/devicetree/bindings/drm/bridge/dw-hdmi.txt 
b/Documentation/devicetree/bindings/drm/bridge/dw-hdmi.txt
new file mode 100644
index 000..aa7ed17
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/dw-hdmi.txt
@@ -0,0 +1,38 @@
+DesignWare HDMI bridge bindings
+
+Required properities:
+- compatibel: platform specific such as "fsl,imx6q-hdmi","fsl,imx6dl-hdmi"
+ "rockchip,rk3288-dw-hdmi"
+- reg: physical base address of the controller and length
+- ddc-i2c-bus: the ddc i2c bus
+- interrupts: The interrupt number to the cpu
+
+Optional properties
+- reg-io-width: the width of the reg:1,4, default set to 1 if not present
+
+Example:
+   hdmi: hdmi@012 {
+   compatible = "fsl,imx6q-hdmi";
+   reg = <0x0012 0x9000>;
+   interrupts = <0 115 0x04>;
+   gpr = <>;
+   clocks = < 123>, < 124>;
+   clock-names = "iahb", "isfr";
+   ddc-i2c-bus = <>;
+
+   port@0 {
+   reg = <0>;
+
+   hdmi_mux_0: endpoint {
+   remote-endpoint = <_di0_hdmi>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   hdmi_mux_1: endpoint {
+   remote-endpoint = <_di1_hdmi>;
+   };
+   };
+   };
-- 
1.9.1

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

[PATCH V5 6/7] dw-hdmi: convert dw-hdmi to drm_bridge mode

[Andy Yan]

From: Yakir Yang 

dw-hdmi is under drm/bridge, so it should be the bridge mode.
hange off the encoder to dw_hdmi-imx.c, keep the connector &
birdge in dw_hdmi.c

Signed-off-by: Andy Yan 
Signed-off-by: Yakir Yang 
---
 drivers/gpu/drm/bridge/dw_hdmi.c  | 217 ++
 drivers/staging/imx-drm/dw_hdmi-imx.c | 143 ++
 include/drm/bridge/dw_hdmi.h  |  13 +-
 3 files changed, 187 insertions(+), 186 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 52158ee..60e625b 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -11,7 +11,6 @@
  * Copyright (C) 2010, Guennadi Liakhovetski 
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -102,7 +101,8 @@ struct hdmi_data_info {
 
 struct dw_hdmi {
struct drm_connector connector;
-   struct drm_encoder encoder;
+   struct drm_encoder *encoder;
+   struct drm_bridge *bridge;
 
enum dw_hdmi_devtype dev_type;
struct device *dev;
@@ -1314,6 +1314,50 @@ static void dw_hdmi_poweroff(struct dw_hdmi *hdmi)
dw_hdmi_phy_disable(hdmi);
 }
 
+static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+
+   dw_hdmi_setup(hdmi, mode);
+
+   /* Store the display mode for plugin/DKMS poweron events */
+   memcpy(>previous_mode, mode, sizeof(hdmi->previous_mode));
+}
+
+static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void dw_hdmi_bridge_disable(struct drm_bridge *bridge)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+
+   dw_hdmi_poweroff(hdmi);
+}
+
+static void dw_hdmi_bridge_enable(struct drm_bridge *bridge)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+
+   dw_hdmi_poweron(hdmi);
+}
+
+static void dw_hdmi_bridge_destroy(struct drm_bridge *bridge)
+{
+   drm_bridge_cleanup(bridge);
+   kfree(bridge);
+}
+
+static void dw_hdmi_bridge_nope(struct drm_bridge *bridge)
+{
+   /* do nothing */
+}
+
 static enum drm_connector_status dw_hdmi_connector_detect(struct drm_connector
*connector, bool force)
 {
@@ -1355,60 +1399,7 @@ static struct drm_encoder 
*dw_hdmi_connector_best_encoder(struct drm_connector
struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
 connector);
 
-   return >encoder;
-}
-
-static void dw_hdmi_encoder_mode_set(struct drm_encoder *encoder,
-   struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
-{
-   struct dw_hdmi *hdmi = container_of(encoder, struct dw_hdmi, encoder);
-
-   dw_hdmi_setup(hdmi, mode);
-
-   /* Store the display mode for plugin/DKMS poweron events */
-   memcpy(>previous_mode, mode, sizeof(hdmi->previous_mode));
-}
-
-static bool dw_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
-{
-   return true;
-}
-
-static void dw_hdmi_encoder_disable(struct drm_encoder *encoder)
-{
-}
-
-static void dw_hdmi_encoder_dpms(struct drm_encoder *encoder, int mode)
-{
-   struct dw_hdmi *hdmi = container_of(encoder, struct dw_hdmi, encoder);
-
-   if (mode)
-   dw_hdmi_poweroff(hdmi);
-   else
-   dw_hdmi_poweron(hdmi);
-}
-
-static void dw_hdmi_encoder_prepare(struct drm_encoder *encoder)
-{
-   struct dw_hdmi *hdmi = container_of(encoder, struct dw_hdmi, encoder);
-
-   dw_hdmi_poweroff(hdmi);
-
-   if (hdmi->plat_data->encoder_prepare)
-   hdmi->plat_data->encoder_prepare(>connector, encoder);
-}
-
-static void dw_hdmi_encoder_commit(struct drm_encoder *encoder)
-{
-   struct dw_hdmi *hdmi = container_of(encoder, struct dw_hdmi, encoder);
-
-   if (hdmi->plat_data->encoder_commit)
-   hdmi->plat_data->encoder_commit(hdmi->priv, encoder);
-
-   dw_hdmi_poweron(hdmi);
+   return hdmi->encoder;
 }
 
 void dw_hdmi_connector_destroy(struct drm_connector *connector)
@@ -1417,19 +1408,6 @@ void dw_hdmi_connector_destroy(struct drm_connector 
*connector)
drm_connector_cleanup(connector);
 }
 
-static struct drm_encoder_funcs dw_hdmi_encoder_funcs = {
-   .destroy = drm_encoder_cleanup,
-};
-
-static struct drm_encoder_helper_funcs dw_hdmi_encoder_helper_funcs = {
-   .dpms = dw_hdmi_encoder_dpms,
-   .prepare = dw_hdmi_encoder_prepare,
-   .commit = dw_hdmi_encoder_commit,
-   

[PATCH V5 5/7] dw-hdmi: add support for multi byte register width access

[Andy Yan]

On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers.  Byte width accesses (writeb,
readb) generate an imprecise external abort.

Signed-off-by: Andy Yan 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 57 ++--
 1 file changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index e9e73a7..52158ee 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -126,16 +126,39 @@ struct dw_hdmi {
 
unsigned int sample_rate;
int ratio;
+   void (*write)(u8 val, void __iomem *addr);
+   u8 (*read)(void __iomem *addr);
+   int reg_shift;
 };
 
+static void dw_hdmi_writel(u8 val, void __iomem *addr)
+{
+   writel(val, addr);
+}
+
+static u8 dw_hdmi_readl(void __iomem *addr)
+{
+   return readl(addr);
+}
+
+static void dw_hdmi_writeb(u8 val, void __iomem *addr)
+{
+   writeb(val, addr);
+}
+
+static u8 dw_hdmi_readb(void __iomem *addr)
+{
+   return readb(addr);
+}
+
 static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
 {
-   writeb(val, hdmi->regs + offset);
+   hdmi->write(val, hdmi->regs + (offset << hdmi->reg_shift));
 }
 
 static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 {
-   return readb(hdmi->regs + offset);
+   return hdmi->read(hdmi->regs + (offset << hdmi->reg_shift));
 }
 
 static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
@@ -1499,6 +1522,36 @@ static int dw_hdmi_bind(struct device *dev, struct 
device *master, void *data)
struct device_node *ddc_node;
struct resource *iores;
int ret, irq;
+   u32 val = 1;
+
+   hdmi = devm_kzalloc(>dev, sizeof(*hdmi), GFP_KERNEL);
+   if (!hdmi)
+   return -ENOMEM;
+
+   hdmi->plat_data = plat_data;
+   hdmi->dev = >dev;
+   hdmi->dev_type = plat_data->dev_type;
+   hdmi->sample_rate = 48000;
+   hdmi->ratio = 100;
+   hdmi->encoder = encoder;
+
+   of_property_read_u32(np, "reg-io-width", );
+
+   switch (val) {
+   case 4:
+   hdmi->write = dw_hdmi_writel;
+   hdmi->read = dw_hdmi_readl;
+   hdmi->reg_shift = 2;
+   break;
+   case 1:
+   hdmi->write = dw_hdmi_writeb;
+   hdmi->read = dw_hdmi_readb;
+   hdmi->reg_shift = 0;
+   break;
+   default:
+   dev_err(dev, "reg-io-width must be 1 or 4\n");
+   return -EINVAL;
+   }
 
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
-- 
1.9.1

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

[PATCH V5 4/7] dw-hdmi: return defer if can't get ddc i2c adapter

[Andy Yan]

drm driver may probe before the i2c bus, so the driver should
defer probing untill it is avaliable

Signed-off-by: Andy Yan 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index df52921..e9e73a7 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1503,8 +1503,11 @@ static int dw_hdmi_bind(struct device *dev, struct 
device *master, void *data)
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
-   if (!hdmi->ddc)
+   if (!hdmi->ddc) {
dev_dbg(hdmi->dev, "failed to read ddc node\n");
+   of_node_put(ddc_node);
+   return -EPROBE_DEFER;
+   }
 
of_node_put(ddc_node);
} else {
-- 
1.9.1

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

[PATCH V5 3/7] dw-hdmi: make checkpatch happy

[Andy Yan]

CHECK: Alignment should match open parenthesis
+   if ((hdmi->vic == 10) || (hdmi->vic == 11) ||
+   (hdmi->vic == 12) || (hdmi->vic == 13) ||

CHECK: braces {} should be used on all arms of this statement
+   if (hdmi->hdmi_data.video_mode.mdvi)
[...]
+   else {
[...]

Signed-off-by: Andy Yan 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 97 
 1 file changed, 48 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 527014b..df52921 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -147,7 +147,7 @@ static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 
mask, unsigned reg)
 }
 
 static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int reg,
- u8 shift, u8 mask)
+u8 shift, u8 mask)
 {
hdmi_modb(hdmi, data << shift, mask, reg);
 }
@@ -311,7 +311,7 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
unsigned long pixel_clk,
 }
 
 static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
-   unsigned long pixel_clk)
+unsigned long pixel_clk)
 {
unsigned int clk_n, clk_cts;
 
@@ -322,7 +322,7 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
 
if (!clk_cts) {
dev_dbg(hdmi->dev, "%s: pixel clock not supported: %lu\n",
-__func__, pixel_clk);
+   __func__, pixel_clk);
return;
}
 
@@ -461,13 +461,11 @@ static void dw_hdmi_update_csc_coeffs(struct dw_hdmi 
*hdmi)
u16 coeff_b = (*csc_coeff)[1][i];
u16 coeff_c = (*csc_coeff)[2][i];
 
-   hdmi_writeb(hdmi, coeff_a & 0xff,
-   HDMI_CSC_COEF_A1_LSB + i * 2);
+   hdmi_writeb(hdmi, coeff_a & 0xff, HDMI_CSC_COEF_A1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_a >> 8, HDMI_CSC_COEF_A1_MSB + i * 2);
hdmi_writeb(hdmi, coeff_b & 0xff, HDMI_CSC_COEF_B1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_b >> 8, HDMI_CSC_COEF_B1_MSB + i * 2);
-   hdmi_writeb(hdmi, coeff_c & 0xff,
-   HDMI_CSC_COEF_C1_LSB + i * 2);
+   hdmi_writeb(hdmi, coeff_c & 0xff, HDMI_CSC_COEF_C1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_c >> 8, HDMI_CSC_COEF_C1_MSB + i * 2);
}
 
@@ -519,21 +517,22 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi)
struct hdmi_data_info *hdmi_data = >hdmi_data;
u8 val, vp_conf;
 
-   if (hdmi_data->enc_out_format == RGB
-   || hdmi_data->enc_out_format == YCBCR444) {
-   if (!hdmi_data->enc_color_depth)
+   if (hdmi_data->enc_out_format == RGB ||
+   hdmi_data->enc_out_format == YCBCR444) {
+   if (!hdmi_data->enc_color_depth) {
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS;
-   else if (hdmi_data->enc_color_depth == 8) {
+   } else if (hdmi_data->enc_color_depth == 8) {
color_depth = 4;
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS;
-   } else if (hdmi_data->enc_color_depth == 10)
+   } else if (hdmi_data->enc_color_depth == 10) {
color_depth = 5;
-   else if (hdmi_data->enc_color_depth == 12)
+   } else if (hdmi_data->enc_color_depth == 12) {
color_depth = 6;
-   else if (hdmi_data->enc_color_depth == 16)
+   } else if (hdmi_data->enc_color_depth == 16) {
color_depth = 7;
-   else
+   } else {
return;
+   }
} else if (hdmi_data->enc_out_format == YCBCR422_8BITS) {
if (!hdmi_data->enc_color_depth ||
hdmi_data->enc_color_depth == 8)
@@ -545,8 +544,9 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi)
else
return;
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_YCC422;
-   } else
+   } else {
return;
+   }
 
/* set the packetizer registers */
val = ((color_depth << HDMI_VP_PR_CD_COLOR_DEPTH_OFFSET) &
@@ -607,34 +607,34 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi)
 }
 
 static inline void hdmi_phy_test_clear(struct dw_hdmi *hdmi,
-   unsigned char bit)
+  unsigned char bit)
 {
hdmi_modb(hdmi, bit << HDMI_PHY_TST0_TSTCLR_OFFSET,
  HDMI_PHY_TST0_TSTCLR_MASK, HDMI_PHY_TST0);
 }
 
 static inline void hdmi_phy_test_enable(struct dw_hdmi *hdmi,
-   unsigned char bit)
+   unsigned char bit)
 {

[PATCH V5 2/7] dw-hdmi: move imx-hdmi to bridge/dw-hdmi

[Andy Yan]

the original imx hdmi driver is under staging/imx-drm,
which depends on imx-drm, so move the imx hdmi drvier out
to drm/bridge and rename imx-hdmi to dw-hdmi

Signed-off-by: Andy Yan 
---
 drivers/gpu/drm/bridge/Kconfig |   5 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c}| 281 +++--
 .../imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h}|  46 +---
 drivers/staging/imx-drm/Kconfig|   1 +
 drivers/staging/imx-drm/Makefile   |   2 +-
 drivers/staging/imx-drm/dw_hdmi-imx.c  |  70 ++---
 include/drm/bridge/dw_hdmi.h   |  57 +
 8 files changed, 243 insertions(+), 220 deletions(-)
 rename drivers/{staging/imx-drm/imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c} (83%)
 rename drivers/{staging/imx-drm/imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h} (97%)
 create mode 100644 include/drm/bridge/dw_hdmi.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..26162ef 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -3,3 +3,8 @@ config DRM_PTN3460
depends on DRM
select DRM_KMS_HELPER
---help---
+
+config DRM_DW_HDMI
+   bool "Synopsys DesignWare High-Definition Multimedia Interface"
+   depends on DRM
+   select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..d8a8cfd 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
 ccflags-y := -Iinclude/drm
 
 obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
diff --git a/drivers/staging/imx-drm/imx-hdmi.c 
b/drivers/gpu/drm/bridge/dw_hdmi.c
similarity index 83%
rename from drivers/staging/imx-drm/imx-hdmi.c
rename to drivers/gpu/drm/bridge/dw_hdmi.c
index cd9cf86..527014b 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -6,8 +6,7 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  *
- * SH-Mobile High-Definition Multimedia Interface (HDMI) driver
- * for SLISHDMI13T and SLIPHDMIT IP cores
+ * Designware High-Definition Multimedia Interface (HDMI) driver
  *
  * Copyright (C) 2010, Guennadi Liakhovetski 
  */
@@ -23,8 +22,9 @@
 #include 
 #include 
 #include 
+#include 
 
-#include "imx-hdmi.h"
+#include "dw_hdmi.h"
 
 #define HDMI_EDID_LEN  512
 
@@ -100,17 +100,17 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
 };
 
-struct imx_hdmi {
+struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder encoder;
 
-   enum imx_hdmi_devtype dev_type;
+   enum dw_hdmi_devtype dev_type;
struct device *dev;
struct clk *isfr_clk;
struct clk *iahb_clk;
 
struct hdmi_data_info hdmi_data;
-   const struct imx_hdmi_plat_data *plat_data;
+   const struct dw_hdmi_plat_data *plat_data;
void *priv;
int vic;
 
@@ -128,17 +128,17 @@ struct imx_hdmi {
int ratio;
 };
 
-static inline void hdmi_writeb(struct imx_hdmi *hdmi, u8 val, int offset)
+static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
 {
writeb(val, hdmi->regs + offset);
 }
 
-static inline u8 hdmi_readb(struct imx_hdmi *hdmi, int offset)
+static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 {
return readb(hdmi->regs + offset);
 }
 
-static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
+static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
 {
u8 val = hdmi_readb(hdmi, reg) & ~mask;
 
@@ -146,13 +146,13 @@ static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 
mask, unsigned reg)
hdmi_writeb(hdmi, val, reg);
 }
 
-static void hdmi_mask_writeb(struct imx_hdmi *hdmi, u8 data, unsigned int reg,
+static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int reg,
  u8 shift, u8 mask)
 {
hdmi_modb(hdmi, data << shift, mask, reg);
 }
 
-static void hdmi_set_clock_regenerator_n(struct imx_hdmi *hdmi,
+static void hdmi_set_clock_regenerator_n(struct dw_hdmi *hdmi,
 unsigned int value)
 {
hdmi_writeb(hdmi, value & 0xff, HDMI_AUD_N1);
@@ -163,7 +163,7 @@ static void hdmi_set_clock_regenerator_n(struct imx_hdmi 
*hdmi,
hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
 }
 
-static void hdmi_regenerate_cts(struct imx_hdmi *hdmi, unsigned int cts)
+static void hdmi_regenerate_cts(struct dw_hdmi *hdmi, unsigned int cts)
 {
/* Must be set/cleared first */
hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
@@ -310,7 +310,7 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
unsigned long pixel_clk,
return (cts * ratio) / 100;
 }
 
-static void hdmi_set_clk_regenerator(struct imx_hdmi 

[PATCH V5 1/7] imx-drm: imx-hdmi: split imx soc specific code from imx-hdmi

[Andy Yan]

imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly difference, such as phy pll configuration,
register width, 4K support, clk useage, and the crtc mux configuration
is also platform specific.

To reuse the imx hdmi driver, split the platform specific code out
to dw_hdmi-imx.c.

Signed-off-by: Andy Yan 
---
 drivers/staging/imx-drm/Makefile  |   2 +-
 drivers/staging/imx-drm/dw_hdmi-imx.c | 214 
 drivers/staging/imx-drm/imx-hdmi.c| 257 --
 drivers/staging/imx-drm/imx-hdmi.h|  43 ++
 4 files changed, 320 insertions(+), 196 deletions(-)
 create mode 100644 drivers/staging/imx-drm/dw_hdmi-imx.c

diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index 582c438..809027d 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -9,4 +9,4 @@ obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
 
 imx-ipuv3-crtc-objs  := ipuv3-crtc.o ipuv3-plane.o
 obj-$(CONFIG_DRM_IMX_IPUV3)+= imx-ipuv3-crtc.o
-obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o
+obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o dw_hdmi-imx.o
diff --git a/drivers/staging/imx-drm/dw_hdmi-imx.c 
b/drivers/staging/imx-drm/dw_hdmi-imx.c
new file mode 100644
index 000..5422679
--- /dev/null
+++ b/drivers/staging/imx-drm/dw_hdmi-imx.c
@@ -0,0 +1,214 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-drm.h"
+#include "imx-hdmi.h"
+
+struct imx_hdmi_priv {
+   struct device *dev;
+   struct clk *isfr_clk;
+   struct clk *iahb_clk;
+   struct regmap *regmap;
+};
+
+static const struct mpll_config imx_mpll_cfg[] = {
+   {
+   4525, {
+   { 0x01e0, 0x },
+   { 0x21e1, 0x },
+   { 0x41e2, 0x }
+   },
+   }, {
+   9250, {
+   { 0x0140, 0x0005 },
+   { 0x2141, 0x0005 },
+   { 0x4142, 0x0005 },
+   },
+   }, {
+   14850, {
+   { 0x00a0, 0x000a },
+   { 0x20a1, 0x000a },
+   { 0x40a2, 0x000a },
+   },
+   }, {
+   ~0UL, {
+   { 0x00a0, 0x000a },
+   { 0x2001, 0x000f },
+   { 0x4002, 0x000f },
+   },
+   }
+};
+
+static const struct curr_ctrl imx_cur_ctr[] = {
+   /*  pixelclk bpp8bpp10   bpp12 */
+   {
+   5400, { 0x091c, 0x091c, 0x06dc },
+   }, {
+   5840, { 0x091c, 0x06dc, 0x06dc },
+   }, {
+   7200, { 0x06dc, 0x06dc, 0x091c },
+   }, {
+   7425, { 0x06dc, 0x0b5c, 0x091c },
+   }, {
+   11880, { 0x091c, 0x091c, 0x06dc },
+   }, {
+   21600, { 0x06dc, 0x0b5c, 0x091c },
+   }
+};
+
+static int imx_hdmi_parse_dt(struct imx_hdmi_priv *hdmi)
+{
+   struct device_node *np = hdmi->dev->of_node;
+
+   hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "gpr");
+   if (IS_ERR(hdmi->regmap)) {
+   dev_err(hdmi->dev, "Unable to get gpr\n");
+   return PTR_ERR(hdmi->regmap);
+   }
+
+   hdmi->isfr_clk = devm_clk_get(hdmi->dev, "isfr");
+   if (IS_ERR(hdmi->isfr_clk)) {
+   dev_err(hdmi->dev, "Unable to get HDMI isfr clk\n");
+   return PTR_ERR(hdmi->isfr_clk);
+   }
+
+   hdmi->iahb_clk = devm_clk_get(hdmi->dev, "iahb");
+   if (IS_ERR(hdmi->iahb_clk)) {
+   dev_err(hdmi->dev, "Unable to get HDMI iahb clk\n");
+   return PTR_ERR(hdmi->iahb_clk);
+   }
+
+   return 0;
+}
+
+static void *imx_hdmi_imx_setup(struct platform_device *pdev)
+{
+   struct imx_hdmi_priv *hdmi;
+   int ret;
+
+   hdmi = devm_kzalloc(>dev, sizeof(*hdmi), GFP_KERNEL);
+   if (!hdmi)
+   return ERR_PTR(-ENOMEM);
+   hdmi->dev = >dev;
+
+   ret = imx_hdmi_parse_dt(hdmi);
+   if (ret < 0)
+   return ERR_PTR(ret);
+   ret = clk_prepare_enable(hdmi->isfr_clk);
+   if (ret) {
+   dev_err(hdmi->dev,
+   "Cannot enable HDMI isfr clock: %d\n", ret);
+   return ERR_PTR(ret);
+   }
+
+   ret = clk_prepare_enable(hdmi->iahb_clk);
+   if (ret) {
+   dev_err(hdmi->dev,
+   "Cannot enable HDMI iahb clock: %d\n", ret);
+   return ERR_PTR(ret);
+   }
+
+   return hdmi;
+}
+
+static void imx_hdmi_imx_exit(void *priv)
+{
+   struct imx_hdmi_priv *hdmi = (struct imx_hdmi_priv *)priv;

[PATCH V5 0/7]dw-hdmi: convert imx hdmi to bridge/dw-hdmi

[Andy Yan]

We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they also have some
lightly difference, such as phy pll configuration, register width(imx hdmi
register is one byte, but rk3288 is 4 bytes width and can only access by word),
4K support(imx6 doesn't support 4k, but rk3288 does).

To reuse the imx-hdmi driver, we do this patch set:
patch (1): split out imx-soc code from imx-hdmi to dw_hdmi-imx.c
patch (2): move imx-hdmi to bridge/, and rename to dw-hdmi to
make this driver indepent of drm-imx .
And we will add rockchip platform specific code dw_hdmi-rockchip.c later,
this is depend on drm-rockchip.

Changes in V5:
- refactor reg-io-width process
- add dt-bindings
Changes in V4:
- return defer if can't get ddc i2c adapter
- fix checkpatch warns

Changes in V3:
- refactor multi byte register access, and split it
  to one indepent patch
- convert it to a drm_bridge driver

Changes in V2:
- use git format-patch -M to generate these patch
- remove change-id
- remove from 


Andy Yan (6):
  imx-drm: imx-hdmi: split imx soc specific code from imx-hdmi
  dw-hdmi: move imx-hdmi to bridge/dw-hdmi
  dw-hdmi: make checkpatch happy
  dw-hdmi: return defer if can't get ddc i2c adapter
  dw-hdmi: add support for multi byte register width access
  dt-bindings: add document for dw-hdmi

Yakir Yang (1):
  dw-hdmi: convert dw-hdmi to drm_bridge mode

 .../devicetree/bindings/drm/bridge/dw-hdmi.txt |  38 ++
 drivers/gpu/drm/bridge/Kconfig |   5 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c}| 714 +
 .../imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h}|   5 +-
 drivers/staging/imx-drm/Kconfig|   1 +
 drivers/staging/imx-drm/Makefile   |   2 +-
 drivers/staging/imx-drm/dw_hdmi-imx.c  | 263 
 include/drm/bridge/dw_hdmi.h   |  52 ++
 9 files changed, 661 insertions(+), 420 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw-hdmi.txt
 rename drivers/{staging/imx-drm/imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c} (71%)
 rename drivers/{staging/imx-drm/imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h} (99%)
 create mode 100644 drivers/staging/imx-drm/dw_hdmi-imx.c
 create mode 100644 include/drm/bridge/dw_hdmi.h

-- 
1.9.1

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

[PATCH] USB: serial: cp210x: Adding IDs for CEL MeshConnect USB Stick

[Preston Fick]

Signed-off-by: Preston Fick 
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index cfd009d..6c4eb3c 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -120,6 +120,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */
{ USB_DEVICE(0x10C4, 0x8664) }, /* AC-Services CAN-IF */
{ USB_DEVICE(0x10C4, 0x8665) }, /* AC-Services OBD-IF */
+   { USB_DEVICE(0x10C4, 0x8875) }, /* CEL MeshConnect USB Stick */
{ USB_DEVICE(0x10C4, 0x88A4) }, /* MMB Networks ZigBee USB Device */
{ USB_DEVICE(0x10C4, 0x88A5) }, /* Planet Innovation Ingeni ZigBee USB 
Device */
{ USB_DEVICE(0x10C4, 0x8946) }, /* Ketra N1 Wireless Interface */
-- 
1.9.1

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

Re: [RFC] perf-cache command interface design

[Masami Hiramatsu]

(2014/11/07 23:43), Namhyung Kim wrote:
> Hi Masami,
> 
> 2014-11-07 (금), 17:21 +0900, Masami Hiramatsu:
>> Hello,
>>
>> Here, I've tried to describe my idea of perf-cache subcommand interface.
>> It is just a design review, not implemented yet :)
>> Please give me your comments/ideas!
>>
>> Command-line Synopsis
>> =
>>
>> Current "perf buildid-cache [options]" are directly mapped to
>> "perf cache --buildid [options]".
>>
>> And adding --sdt for managing SDT caches as below.
>>
>>   Add or update SDT events in 
>> perf cache --sdt --add|--update 
>>
>>   Remove all SDT events for 
>> perf cache --sdt --remove 
>>
>>   List all SDT events
>> perf cache --sdt --list
>>
>> And --probes for managing probe-caches as below.
>>
>>   Add new probe-cache entries for kernel,  or .
>> perf cache --probe [--exec |--module ] --add 
>>
>>   Delete existing probe-cache entries for kernel,  or/and .
>> perf cache --probe --del [:][@][#]
>>
>>   Or remove all entires for given FILES
>> perf cache --probe --remove 
>>
>>   List the probe caches(including SDT) for kernel, , or/and .
>> perf cache --probe --list [@][#]
>>
>>   Query the probe definitions.
>> perf cache --probe --query [:][@][#]
>>
>> Note that --probes also can be used for managing SDT events, which has % 
>> prefix
>> e.g.
>>   Add all SDT events for 
>> perf cache --probe --exec  --add '%*:*'
>>
>>   Remove some SDT events for 
>> perf cache --probe --del '%some:events@'
>>
>>   Or remove all SDT events for 
>> perf cache --probe --del '%*:*#'
> 
> I'd prefer sub-command to option for this mandatory (and exclusive)
> behavior.  What about like this?

I consider this will also confusing users because it's different from
other subcommands. And Arnaldo gives us a better solution :)

> 
>   perf cache kprobe add [-m ]  [...]
>   perf cache kprobe del [:] [...]
>   perf cache kprobe list [-m ]
> 
>   perf cache uprobe add -x   [...]
>   perf cache uprobe del [:] [...]
>   perf cache uprobe list [-x ]

Since perf has only "probe" subcommand, we shouldn't separate
uprobe and kprobe.

> 
>   perf cache sdt [add|del|update]  [...]
>   perf cache sdt list [-b ] [...]
> 
> 
>>
>>
>> File Format
>> ===
>> All the cache files are placed under ~/.debug/ by default.
>> The paths of buildid cache of binary/symbols are not changed.
>>
>> The SDT/probe caches are placed under the 
>> ~/.debug/.probes/path/to/bin/bu/ildid
>> and that is linked to ~/.debug/.probes/.buildid/bu/ildid
>> # To avoid conflict with files under /probes/*, I picked up .probes/.
> 
> However, to be used with perf record, we need a way to find a matching
> probe cache file from a event name (or group/provider name, preferably).
> What about having something like below:
> 
>   $ cat ~/.debug/.probes/event.map
>   PROVIDER1 /path/to/some/where
>   PROVIDER2 /path/to/other/place

Hmm, agreed. We'd better have this kind of provider index file to
accelerate searching.

> When perf record see a cached event used, it first searches its
> provider/group name from the event.map file.  And then read bulid-id
> from the matching file on the path and finally find a cached event
> definition from ~/.debug/.probes/.buildid/bu/ildid file.
> 
> 
>>
>> This SDT/probe caches contain probe-definitions as following format.
>> 
>> #buildid:BUILDID
>> #path:PATH
>> p:%PROVIDER/EVENT PATH:OFFSET [ARGS]
> 
> It seems PATH is redundant and we don't need to repeat it everyline
> IMHO.  Since it need post-processing anyway, maybe it's better to just
> make it simpler, like:
> 
>   %:PROVIDER/EVENT OFFSET [ARGS]

Hmm, this is not good because this line will not be able to pass to
tracing/uprobe_events...
And also, I think we can compress this cache with gzip, then such
redundancy will not be a problem.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: [RFC] perf-cache command interface design

[Masami Hiramatsu]

(2014/11/07 23:38), Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 07, 2014 at 05:21:08PM +0900, Masami Hiramatsu escreveu:
>> Hello,
>>
>> Here, I've tried to describe my idea of perf-cache subcommand interface.
>> It is just a design review, not implemented yet :)
>> Please give me your comments/ideas!
>>
>> Command-line Synopsis
>> =
>>
>> Current "perf buildid-cache [options]" are directly mapped to
>> "perf cache --buildid [options]".
>>
>> And adding --sdt for managing SDT caches as below.
> 
> Can't we avoid having to specify the content? I.e. the tool can surely
> be smart enough to figure that out, no?
> 
> We should, as much as possible, to make things more compact yet
> unambiguous, IMHO.

Agreed.

>  
>>   Add or update SDT events in 
>> perf cache --sdt --add|--update 
> 
> Can automagically figure this out, so, it would become just:
> 
>   Add or update events in 
> 
> perf cache --add/--update 

Ah, nice idea :-)

>  
>>   Remove all SDT events for 
>> perf cache --sdt --remove 
> 
> Ditto.
>  
>>   List all SDT events
>> perf cache --sdt --list
> 
> That is ok, since the cache can hold different types of contents, but:
> 
>   perf cache --list
> 
> should show everything, with some marking showing the content type.

Yeah, as I replied to Hemant, --sdt/--probe can be unified.

>  
>> And --probes for managing probe-caches as below.
>>
>>   Add new probe-cache entries for kernel,  or .
>> perf cache --probe [--exec |--module ] --add 
> 
> No need to specify --probe
>  
>>   Delete existing probe-cache entries for kernel,  or/and .
>> perf cache --probe --del [:][@][#]
> 
> Ditto
>  
>>   Or remove all entires for given FILES
>> perf cache --probe --remove 
> 
> Ok
>  
>>   List the probe caches(including SDT) for kernel, , or/and .
>> perf cache --probe --list [@][#]
> 
> Can figure out the kind by the initial character, so no need to specify
> --probe

OK.

>>   Query the probe definitions.
>> perf cache --probe --query [:][@][#]
> 
> Ditto
>  
>> Note that --probes also can be used for managing SDT events, which has % 
>> prefix
>> e.g.
>>   Add all SDT events for 
>> perf cache --probe --exec  --add '%*:*'
> 
> See? --probe is smart enough to deal with SDT and probe caches, it can
> disambiguate by looking at the first char.

OK, but --add already have FILES arguments (according to buildid-cache)
So I'd like to move that pattern argument to --probe as I've described
in previous reply to Hemant.

>  
>>   Remove some SDT events for 
>> perf cache --probe --del '%some:events@'
> 
> No need for --probe
>  
>>   Or remove all SDT events for 
>> perf cache --probe --del '%*:*#'
> 
> Ditto
>  
>>
>> File Format
>> ===
>> All the cache files are placed under ~/.debug/ by default.
>> The paths of buildid cache of binary/symbols are not changed.
>>
>> The SDT/probe caches are placed under the 
>> ~/.debug/.probes/path/to/bin/bu/ildid
> 
> Here I think we could group everything related to a /path/to/bin into:
> 
> ~/.debug/path/to/bin/bu/ild/
> 
> With one file per content type:
> 
> ~/.debug/path/to/bin/bu/ild/elf
> ~/.debug/path/to/bin/bu/ild/probe

Ah, OK, this is good for me too. :)

> 
> That leaves room for us to add more file formats (CTF anyone? The Dtrace
> one, Compact C Type Information, I mean).

Perhaps.

> So that if we wanted to pick everything related to a pathname we could
> do:
> 
> tar cf gcc.debug.tar ~/.debug/usr/bin/gcc/
> 
> If we instead wanted to pick all files to a specific gcc build id, we
> would do:
> 
> tar cf gcc.debug.tar ~/.debug/usr/bin/gcc/bu/ild/

OK.

>> and that is linked to ~/.debug/.probes/.buildid/bu/ildid
> 
> Since this would break compatibility with the existing cache format, we
> could as well allow collecting everything related to a build id, by
> making the link be also in this fashion:
> 
> tar cf bu.ildid.tar ~/.debug/.build-id/bu/ildid/
> 
> Because we would have:
> 
> ~/.debug/.build-id/bu/ildid/elf -> ~/.debug/usr/bin/gcc/bu/ild/elf
> ~/.debug/.build-id/bu/ildid/probe -> ~/.debug/usr/bin/gcc/bu/ild/probe
> 
> And also links to the files that have no pathnames:
> 
> ~/.debug/.build-id/bu/ildid/vdso -> ~/.debug/[vdso]/bu/ild
> ~/.debug/.build-id/bu/ildid/kallsyms -> ~/.debug/[kernel.kallsyms]/bu/ild
> ~/.debug/.build-id/bu/ildid/kcore -> ~/.debug/[kcore]/bu/ild

OK, so let's make bu/ildid to a directory :)

Thank you!
-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: [PATCH v5 20/48] mfd: rn5t618: Register power-off handler with kernel power-off handler

[Guenter Roeck]

On 11/07/2014 01:00 PM, Beniamino Galvani wrote:

On Thu, Nov 06, 2014 at 08:43:04AM -0800, Guenter Roeck wrote:

Register with kernel power-off handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.

Cc: Beniamino Galvani 
Acked-by: Lee Jones 
Signed-off-by: Guenter Roeck 
---
v5:
- Rebase to v3.18-rc3
v4:
- Do not use notifiers but internal functions and data structures to manage
   the list of power-off handlers. Drop unused parameters from callbacks, and
   make the power-off function type void
v3:
- Replace poweroff in all newly introduced variables and in text
   with power_off or power-off as appropriate
- Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
v2:
- New patch

  drivers/mfd/rn5t618.c   | 28 
  include/linux/mfd/rn5t618.h |  2 ++
  2 files changed, 14 insertions(+), 16 deletions(-)


Tested-by: Beniamino Galvani 


Thanks!

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: [RFC] perf-cache command interface design

[Masami Hiramatsu]

(2014/11/07 19:51), Hemant Kumar wrote:
>>
>> File Format
>> ===
>> All the cache files are placed under ~/.debug/ by default.
>> The paths of buildid cache of binary/symbols are not changed.
>>
>> The SDT/probe caches are placed under the 
>> ~/.debug/.probes/path/to/bin/bu/ildid
>> and that is linked to ~/.debug/.probes/.buildid/bu/ildid
>> # To avoid conflict with files under /probes/*, I picked up .probes/.
>>
>> This SDT/probe caches contain probe-definitions as following format.
>> 
>> #buildid:BUILDID
>> #path:PATH
>> p:%PROVIDER/EVENT PATH:OFFSET [ARGS]
> 
> I think this format isn't accepted by the uprobe_events file (because of
> the '%') if we want to cat and grep into uprobe_events file directly.
> Although, in case of perf record, we can process it to remove '%' and
> then write into uprobe_events file. And, '%' is required as a flag for
> the SDT entries.

Ah, right...

> So, either we can modify the uprobe_events file to ignore '%' in the
> event group name (with an additional patch in the SDT series) or we can
> leave it to the user to write a script which can do some processing to
> remove '%' and then echo it to uprobe_events file.
> What would you think?

Hmm, ok. I think we can unify SDT and probe cache as just an cached
event. So replacing % with probe_ prefix is OK I think.

What I mean is if you add a file to cache, perf adds SDTs in the file,
and if you add a file with some expressions, like '* $params', perf
also adds probe caches. And you can use both events for not only
tracing but also profiling.

e.g.
 perf cache --add /bin/foo  # add foo's SDTs
 perf cache --add /bin/foo --probe 'foofunc $params' # add a probe cache for 
foofunc
 perf record -e %foo:sdtevent -e %foo:foofunc ... # we can record both SDT and 
cache

So, % prefix means "recall cached probe/sdt events to record if needed".
If you already set up the probe-events on those, you don't need % as below.

 perf probe --add "%foo:sdtevent" # add new probe_foo:sdtevent for %foo:sdtevent
 perf record -e probe_foo:sdtevent ...

Note that to avoid crash with existing event groups, we'll add "probe_" prefix
for cached events.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

[Sasha Levin]

On 10/22/2014 03:17 AM, Kirill Tkhai wrote:
> Unlocked access to dst_rq->curr in task_numa_compare() is racy.
> If curr task is exiting this may be a reason of use-after-free:
[...]

I've complained about an unrelated issue in that part of the code
a while back (https://lkml.org/lkml/2014/5/12/508) which PeterZ
ended up fixing (https://lkml.org/lkml/2014/5/21/428) but it seems
that both of us forgot to follow up on that and the fix never got
upstream.

Ever since this patch made it upstream, Peter's patch which I was
carrying in my tree stopped applying and I've started seeing:

[  829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
[  829.539203]  lock: 0x880631dd6b80, .magic: dead4ead, .owner: 
trinity-c594/11067, .owner_cpu: 13
[  829.539212] CPU: 10 PID: 11067 Comm: trinity-c594 Not tainted 
3.18.0-rc3-next-20141106-sasha-00054-g09b7ccf-dirty #1448
[  829.539226]    880053acb000 
88032b71f828
[  829.539235]  a009fb5a 0057 880631dd6b80 
88032b71f868
[  829.539243]  963f0c57 880053acbd80 880053acbdb0 
88032b71f858
[  829.539246] Call Trace:
[  829.539265] dump_stack (lib/dump_stack.c:52)
[  829.539277] spin_dump (kernel/locking/spinlock_debug.c:68 (discriminator 8))
[  829.539282] spin_bug (kernel/locking/spinlock_debug.c:76)
[  829.539288] do_raw_spin_lock (kernel/locking/spinlock_debug.c:84 
kernel/locking/spinlock_debug.c:135)
[  829.539304] ? __schedule (kernel/sched/core.c:2803)
[  829.539313] _raw_spin_lock_irq (include/linux/spinlock_api_smp.h:129 
kernel/locking/spinlock.c:167)
[  829.539321] ? task_numa_find_cpu (kernel/sched/fair.c:1258 
kernel/sched/fair.c:1385)
[  829.539330] ? rcu_is_watching (./arch/x86/include/asm/preempt.h:95 
kernel/rcu/tree.c:827)
[  829.539336] task_numa_find_cpu (kernel/sched/fair.c:1258 
kernel/sched/fair.c:1385)
[  829.539342] ? task_numa_find_cpu (kernel/sched/fair.c:1253 
kernel/sched/fair.c:1385)
[  829.539352] ? preempt_count_sub (kernel/sched/core.c:2644)
[  829.539358] task_numa_migrate (kernel/sched/fair.c:1452)
[  829.539364] ? task_numa_migrate (kernel/sched/fair.c:1391)
[  829.539376] ? kvm_clock_read (./arch/x86/include/asm/preempt.h:87 
arch/x86/kernel/kvmclock.c:85)
[  829.539386] ? sched_clock (./arch/x86/include/asm/paravirt.h:192 
arch/x86/kernel/tsc.c:304)
[  829.539392] ? sched_clock_local (kernel/sched/clock.c:202)
[  829.539399] numa_migrate_preferred (kernel/sched/fair.c:1539)
[  829.539404] ? sched_clock_local (kernel/sched/clock.c:202)
[  829.539411] task_numa_fault (kernel/sched/fair.c:2073)
[  829.539417] ? sched_clock_cpu (kernel/sched/clock.c:311)
[  829.539429] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[  829.539438] ? get_lock_stats (kernel/locking/lockdep.c:249)
[  829.539446] ? get_parent_ip (kernel/sched/core.c:2588)
[  829.539461] handle_mm_fault (mm/memory.c:3187 mm/memory.c:3233 
mm/memory.c:3346 mm/memory.c:3375)
[  829.539466] ? find_vma (mm/mmap.c:2048)
[  829.539477] __do_page_fault (arch/x86/mm/fault.c:1246)
[  829.539485] ? context_tracking_user_exit (kernel/context_tracking.c:144)
[  829.539491] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[  829.539498] ? trace_hardirqs_off_caller (kernel/locking/lockdep.c:2640 
(discriminator 8))
[  829.539505] trace_do_page_fault (arch/x86/mm/fault.c:1329 
include/linux/jump_label.h:114 include/linux/context_tracking_state.h:27 
include/linux/context_tracking.h:45 arch/x86/mm/fault.c:1330)
[  829.539510] do_async_page_fault (arch/x86/kernel/kvm.c:280)
[  829.539516] async_page_fault (arch/x86/kernel/entry_64.S:1301)



Thanks,
Sasha
--
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/2] Kernel Live Patching

[Josh Poimboeuf]

On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
> On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
> 
> > >   LEAVE_FUNCTION
> > >   LEAVE_PATCHED_SET
> > >   LEAVE_KERNEL
> > > 
> > >   SWITCH_FUNCTION
> > >   SWITCH_THREAD
> > >   SWITCH_KERNEL
> > > 
> > > Now with those definitions:
> > > 
> > >   livepatch (null model), as is, is LEAVE_FUNCTION and SWITCH_FUNCTION
> > > 
> > >   kpatch, masami-refcounting and Ksplice are LEAVE_PATCHED_SET and 
> > > SWITCH_KERNEL
> > > 
> > >   kGraft is LEAVE_KERNEL and SWITCH_THREAD
> > > 
> > >   CRIU/kexec is LEAVE_KERNEL and SWITCH_KERNEL
> > 
> > Thanks, nice analysis!
> > 
> > > By blending kGraft and masami-refcounting, we could create a consistency
> > > engine capable of almost any combination of these properties and thus
> > > all the consistency models.
> > 
> > Can you elaborate on what this would look like?
> 
> There would be the refcounting engine, counting entries/exits of the
> area of interest (nothing for LEAVE_FUNCTION, patched functions for
> LEAVE_PATCHED_SET - same as Masami's work now, or syscall entry/exit for
> LEAVE_KERNEL), and it'd do the counting either per thread, flagging a
> thread as 'new universe' when the count goes to zero, or flipping a
> 'new universe' switch for the whole kernel when the count goes down to zero.
> 
> A patch would have flags which specify a combination of the above
> properties that are needed for successful patching of that specific
> patch.

Would it really be necessary to support all possible permutations?  I
think that would add a lot of complexity to the code.  Especially if we
have to support LEAVE_KERNEL, which adds a lot of interdependencies with
the rest of the kernel (kthreads, syscall, irq, etc).

It seems to me that the two most interesting options are:
- LEAVE_PATCHED_SET + SWITCH_THREAD (Masami-kGraft)
- LEAVE_PATCHED_SET + SWITCH_KERNEL (kpatch and/or Masami-kpatch)

I do see some appeal for the choose-your-own-consistency-model idea.
But it wouldn't be practical for cumulative patch upgrades, which I
think we both agreed at LPC seems to be safer than incremental patching.
If you only ever have one patch module loaded at any given time, you
only get one consistency model anyway.

In order for multiple consistency models to be practical, I think we'd
need to figure out how to make incremental patching safe.

> > The big problem with SWITCH_THREAD is that it adds the possibility that
> > old functions can run simultaneously with new ones.  When you change
> > data or data semantics, which is roughly 10% of security patches, it
> > creates some serious headaches:
> > 
> > - It makes patch safety analysis much harder by doubling the number of
> >   permutations of scenarios you have to consider.  In addition to
> >   considering newfunc/olddata and newfunc/newdata, you also have to
> >   consider oldfunc/olddata and oldfunc/newdata.
> > 
> > - It requires two patches instead of one.  The first patch is needed to
> >   modify the old functions to be able to deal with new data.  After the
> >   first patch has been fully applied, then you apply the second patch
> >   which can start creating new versions of data.
> 
> For data layout an semantic changes, there are two approaches:
> 
>   1) TRANSFORM_WORLD
> 
>   Stop the world, transform everything, resume. This is what Ksplice does
>   and what could work for kpatch, would be rather interesting (but
>   possible) for masami-refcounting and doesn't work at all for the
>   per-thread kGraft.
> 
>   It allows to deallocate structures, allocate new ones, basically
>   rebuild the data structures of the kernel. No shadowing or using
>   of padding is needed.
> 
>   The nice part is that the patch can stay pretty much the original patch
>   that fixes the bug when applied to normal kernel sources.
> 
>   The most tricky part with this approach is writing the
>   additional transformation code. Finding all instances of a
>   changed data structure. It fails if only semantics are changed,
>   but that is easily fixed by making sure there is always a layout
>   change for any semantic change. All instances of a specific data
>   structure can be found, worst case with some compiler help: No
>   function can have pointers or instances of the structure on the
>   stack, or registers, as that would include it in the patched
>   set. So all have to be either global, or referenced by a
>   globally-rooted tree, linked list or any other structure.
> 
>   This one is also possible to revert, if a reverse-transforming function
>   is provided.
> 
>   masami-refcounting can be made to work with this by spinning in every
>   function entry ftrace/kprobe callback after a universe flip and calling
>   stop_kernel from the function exit callback that flipped the switch.

I'm kind of surprised to hear that Ksplice does this.  I had considered

Re: [PATCH V4 5/6] dw-hdmi: add support for multi byte register width access

[Andy Yan]

On 2014年11月07日 19:45, Lucas Stach wrote:

Am Freitag, den 07.11.2014, 19:35 +0800 schrieb Andy Yan:

On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers.  Byte width access (writeb,
readb) generates an imprecise external abort.

Signed-off-by: Andy Yan 
---
  drivers/gpu/drm/bridge/dw_hdmi.c | 49 +---
  1 file changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index df76a8c..9867642 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -126,19 +126,42 @@ struct dw_hdmi {

[...]

+   u32 val;
+
+   if (!of_property_read_u32(np, "reg-io-width", )) {
+   switch (val) {
+   case 4:
+   hdmi->write = dw_hdmi_writel;
+   hdmi->read = dw_hdmi_readl;
+   hdmi->reg_shift = 2;
+   break;
+   default:
+   hdmi->write = dw_hdmi_writeb;
+   hdmi->read = dw_hdmi_readb;
+   hdmi->reg_shift = 0;
+   break;
+   }
+   } else {
+   hdmi->write = dw_hdmi_writeb;
+   hdmi->read = dw_hdmi_readb;
+   hdmi->reg_shift = 0;
+   }
  
  	ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);

if (ddc_node) {

This should throw an error if the property value in devicetree is not
recognized. This could be simplified like this:

u32 val = 1;

// this won't touch val if it can't find the property
of_property_read_u32(np, "reg-io-width", )


switch (val) {
case 4:
hdmi->write = dw_hdmi_writel;
hdmi->read = dw_hdmi_readl;
hdmi->reg_shift = 2;
break;
case 1:
hdmi->write = dw_hdmi_writeb;
hdmi->read = dw_hdmi_readb;
hdmi->reg_shift = 0;
break;
default:
dev_err(dev, "unrecognized value for reg-io-width");
// error handling
}

Also the DT binding doc for this property is missing.

Regards,
Lucas

thanks for your suggestion, I will take it.
this properity is optional, I will add it to DT binding doc

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

Via Nano fails and completely crashes on kvm

[Timothy McDaniel]

Via Nano fails and completely crashes on kvm

here is my /proc/cpuinfo

processor   : 0
vendor_id   : CentaurHauls
cpu family  : 6
model   : 15
model name  : VIA Nano processor U2250 (1.6GHz Capable)
stepping: 3
cpu MHz : 800.000
cache size  : 1024 KB
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat clflush acpi mmx fxsr sse sse2 ss tm pbe syscall nx lm
constant_tsc up rep_good nopl pni monitor vmx est tm2 ssse3 cx16 xtpr
rng rng_en ace ace_en ace2 phe phe_en lahf_lm
bogomips: 3191.62
clflush size: 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

also here is my uname -mrs
Linux 3.2.0-4-amd64 x86_64

here is uname -a
Linux sd-24793 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux

please tell me if you need anymore info on helping me get kvm to work.
--
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/

typo of the comment

[john_gong]

hi Paolo,
i find a typo of the comment.


From 09d5df31f0930e8e3eb10ad60a3debc53d6ce992 Mon Sep 17 00:00:00 2001
From: john_gong 
Date: Fri, 7 Nov 2014 07:32:17 +0800
Subject: [PATCH] modify a typo of the comment

Signed-off-by: john_gong 
---
 arch/x86/kvm/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ef432f8..42bb2c8 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -214,7 +214,7 @@ void kvm_define_shared_msr(unsigned slot, u32 msr)
 if (slot >= shared_msrs_global.nr)
 shared_msrs_global.nr = slot + 1;
 shared_msrs_global.msrs[slot] = msr;
-/* we need ensured the shared_msr_global have been updated */
+/* we need ensured the shared_msrs_global have been updated */
 smp_wmb();
 }
 EXPORT_SYMBOL_GPL(kvm_define_shared_msr);
--
2.1.0


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

[PATCH] x86, kvm, vmx: Always use LOAD_IA32_EFER if available

[Andy Lutomirski]

At least on Sandy Bridge, letting the CPU switch IA32_EFER is much
faster than switching it manually.

I benchmarked this using the vmexit kvm-unit-test (single run, but
GOAL multiplied by 5 to do more iterations):

Test  Before  AfterChange
cpuid   2000   1932-3.40%
vmcall  1914   1817-5.07%
mov_from_cr8  13 13 0.00%
mov_to_cr819 19 0.00%
inl_from_pmtimer   19164  10619   -44.59%
inl_from_qemu  15662  10302   -34.22%
inl_from_kernel 3916   3802-2.91%
outl_to_kernel  2230   2194-1.61%
mov_dr   172176 2.33%
ipi(skipped)  (skipped)
ipi+halt   (skipped)  (skipped)
ple-round-robin   13 13 0.00%
wr_tsc_adjust_msr   1920   1845-3.91%
rd_tsc_adjust_msr   1892   1814-4.12%
mmio-no-eventfd:pci-mem16394  11165   -31.90%
mmio-wildcard-eventfd:pci-mem   4607   4645 0.82%
mmio-datamatch-eventfd:pci-mem  4601   4610 0.20%
portio-no-eventfd:pci-io   11507   7942   -30.98%
portio-wildcard-eventfd:pci-io  2239   2225-0.63%
portio-datamatch-eventfd:pci-io 2250   2234-0.71%

I haven't explicitly computed the significance of these numbers,
but this isn't subtle.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kvm/vmx.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 3e556c68351b..e72b9660e51c 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1659,8 +1659,14 @@ static bool update_transition_efer(struct vcpu_vmx *vmx, 
int efer_offset)
vmx->guest_msrs[efer_offset].mask = ~ignore_bits;
 
clear_atomic_switch_msr(vmx, MSR_EFER);
-   /* On ept, can't emulate nx, and must switch nx atomically */
-   if (enable_ept && ((vmx->vcpu.arch.efer ^ host_efer) & EFER_NX)) {
+
+   /*
+* On EPT, we can't emulate NX, so we must switch EFER atomically.
+* On CPUs that support "load IA32_EFER", always switch EFER
+* atomically, since it's faster than switching it manually.
+*/
+   if (cpu_has_load_ia32_efer ||
+   (enable_ept && ((vmx->vcpu.arch.efer ^ host_efer) & EFER_NX))) {
guest_efer = vmx->vcpu.arch.efer;
if (!(guest_efer & EFER_LMA))
guest_efer &= ~EFER_LME;
-- 
1.9.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/4] inet: Add skb_copy_datagram_iter

[Herbert Xu]

On Fri, Nov 07, 2014 at 11:42:53PM +, Al Viro wrote:
> I'll finish RTFS drivers/vhost and if it turns out to be OK I'll post the
> series moving those checks to the moment of copying iovec from userland,
> so that kernel-side we could always rely on ->msg_iov elements having been
> verified.

Great thanks!

Dave, please hold off on my skb_copy_datagram_iter series until
this verify_iovec change is added.

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

Re: [PATCH v2] PM / Sleep: Timer quiesce in freeze state

[Rafael J. Wysocki]

On Thursday, October 30, 2014 10:58:23 AM Li, Aubrey wrote:
> The patch is based on v3.17, merged with Rafael's pm+acpi-3.18-rc1 tag from
> linux-pm.git tree.
> 
> The patch is based on the patch PeterZ initially wrote.
> ---
> Freeze is a general power saving state that processes are frozen, devices
> are suspended and CPUs are in idle state. However, when the system enters
> freeze state, there are a few timers keep ticking and hence consumes more
> power unnecessarily. The observed timer events in freeze state are:
> - tick_sched_timer
> - watchdog lockup detector
> - realtime scheduler period timer
> 
> The system power consumption in freeze state will be reduced significantly
> if we quiesce these timers.
> 
> On Baytrail-T(ASUS_T100) platform, when the system is freezed to low power
> idle state(S0ix), quiescing these timers saves 29.8% power(94.48mw -> 
> 66.32mw).
> 
> The patch is also tested on:
> - Sandybrdige-EP system, both RTC alarm and power button are able to wake
>   the system up from freeze state.
> - HP laptop EliteBook 8460p, both RTC alarm and power button are able to
>   wake the system up from freeze state.
> 
> Signed-off-by: Aubrey Li 
> Signed-off-by: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Len Brown 
> Cc: Alan Cox 

Peter, Thomas, any comments here?

> ---
>  arch/x86/kernel/apic/apic.c|   8 ++
>  drivers/cpuidle/cpuidle.c  |  12 +++
>  kernel/power/suspend.c | 185 
> +++--
>  kernel/time/timekeeping.c  |   4 +-
>  kernel/time/timekeeping_internal.h |   3 +
>  5 files changed, 204 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 6776027..f2bb645 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -917,6 +917,14 @@ static void local_apic_timer_interrupt(void)
>*/
>   inc_irq_stat(apic_timer_irqs);
>  
> + /*
> +  * if timekeeping is suspended, the clock event device will be
> +  * suspended as well, so we are not supposed to invoke the event
> +  * handler of clock event device.
> +  */
> + if (unlikely(timekeeping_suspended))
> + return;
> +
>   evt->event_handler(evt);
>  }
>  
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index ee9df5e..8f84f40 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -119,6 +119,18 @@ int cpuidle_enter_state(struct cpuidle_device *dev, 
> struct cpuidle_driver *drv,
>   ktime_t time_start, time_end;
>   s64 diff;
>  
> + /*
> +  * under the scenario of use deepest idle state, the timekeeping
> +  * could be suspended as well as the clock source device, so we
> +  * bypass the idle counter update for this case
> +  */
> + if (unlikely(use_deepest_state)) {
> + entered_state = target_state->enter(dev, drv, index);
> + if (!cpuidle_state_is_coupled(dev, drv, entered_state))
> + local_irq_enable();
> + return entered_state;
> + }
> +
>   trace_cpu_idle_rcuidle(index, dev->cpu);
>   time_start = ktime_get();
>  
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 4ca9a33..660fd15 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -28,16 +28,20 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include "power.h"
> +#include "../time/tick-internal.h"
> +#include "../time/timekeeping_internal.h"
>  
>  const char *pm_labels[] = { "mem", "standby", "freeze", NULL };
>  const char *pm_states[PM_SUSPEND_MAX];
>  
>  static const struct platform_suspend_ops *suspend_ops;
>  static const struct platform_freeze_ops *freeze_ops;
> -static DECLARE_WAIT_QUEUE_HEAD(suspend_freeze_wait_head);
> -static bool suspend_freeze_wake;
> +static int suspend_freeze_wake;
>  
>  void freeze_set_ops(const struct platform_freeze_ops *ops)
>  {
> @@ -48,22 +52,191 @@ void freeze_set_ops(const struct platform_freeze_ops 
> *ops)
>  
>  static void freeze_begin(void)
>  {
> - suspend_freeze_wake = false;
> + suspend_freeze_wake = -1;
> +}
> +
> +enum freezer_state {
> + FREEZER_NONE,
> + FREEZER_PICK_TK,
> + FREEZER_SUSPEND_CLKEVT,
> + FREEZER_SUSPEND_TK,
> + FREEZER_IDLE,
> + FREEZER_RESUME_TK,
> + FREEZER_RESUME_CLKEVT,
> + FREEZER_EXIT,
> +};
> +
> +struct freezer_data {
> + int thread_num;
> + atomic_tthread_ack;
> + enum freezer_state  state;
> +};
> +
> +static void set_state(struct freezer_data *fd, enum freezer_state state)
> +{
> + /* set ack counter */
> + atomic_set(>thread_ack, fd->thread_num);
> + /* guarantee the write ordering between ack counter and state */
> + smp_wmb();
> + fd->state = state;
> +}
> +
> +static void ack_state(struct freezer_data *fd)
> +{
> + if (atomic_dec_and_test(>thread_ack))
> 

[PATCH v3 2/2] x86, mce: support memory error recovery for both UCNA and Deferred error in machine_check_poll

[Chen Yucong]

Uncorrected no action required (UCNA) - is a uncorrected recoverable
machine check error that is not signaled via a machine check exception
and, instead, is reported to system software as a corrected machine
check error. UCNA errors indicate that some data in the system is
corrupted, but the data has not been consumed and the processor state
is valid and you may continue execution on this processor. UCNA errors
require no action from system software to continue execution. Note that
UCNA errors are supported by the processor only when IA32_MCG_CAP[24]
(MCG_SER_P) is set.
   -- Intel SDM Volume 3B

Deferred errors are errors that cannot be corrected by hardware, but
do not cause an immediate interruption in program flow, loss of data
integrity, or corruption of processor state. These errors indicate
that data has been corrupted but not consumed. Hardware writes information
to the status and address registers in the corresponding bank that
identifies the source of the error if deferred errors are enabled for
logging. Deferred errors are not reported via machine check exceptions;
they can be seen by polling the MCi_STATUS registers.
-- AMD64 APM Volume 2

Above two items, both UCNA and Deferred errors belong to detected
errors, but they can't be corrected by hardware, and this is very
similar to Software Recoverable Action Optional (SRAO) errors.
Therefore, we can take some actions that have been used for handling
SRAO errors to handle UCNA and Deferred errors.

Signed-off-by: Chen Yucong 
---
 arch/x86/kernel/cpu/mcheck/mce.c |   50 ++
 1 file changed, 50 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 453e9bf..4b6e4cdf 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -575,6 +575,41 @@ static void mce_read_aux(struct mce *m, int i)
}
 }
 
+static bool memory_error(struct mce *m)
+{
+   struct cpuinfo_x86 *c = _cpu_data;
+
+   if (c->x86_vendor == X86_VENDOR_AMD) {
+   /*
+* AMD BKDGs - Machine Check Error Codes
+*
+* Bit 8 of ErrCode[15:0] of MCi_STATUS is used for indicating
+* a memory-specific error. Note that this field encodes info-
+* rmation about memory-hierarchy level involved in the error.
+*/
+   return (m->status & 0xff00) == BIT(8);
+   } else if (c->x86_vendor == X86_VENDOR_INTEL) {
+   /*
+* Intel SDM Volume 3B - 15.9.2 Compound Error Codes
+*
+* Bit 7 of the MCACOD field of IA32_MCi_STATUS is used for
+* indicating a memory error. Bit 8 is used for indicating a
+* cache hierarchy error. The combination of bit 2 and bit 3
+* is used for indicating a `generic' cache hierarchy error
+* But we can't just blindly check the above bits, because if
+* bit 11 is set, then it is a bus/interconnect error - and
+* either way the above bits just gives more detail on what
+* bus/interconnect error happened. Note that bit 12 can be
+* ignored, as it's the "filter" bit.
+*/
+   return (m->status & 0xef80) == BIT(7) ||
+  (m->status & 0xef00) == BIT(8) ||
+  (m->status & 0xeffc) == 0xc;
+   }
+
+   return false;
+}
+
 DEFINE_PER_CPU(unsigned, mce_poll_count);
 
 /*
@@ -595,6 +630,7 @@ DEFINE_PER_CPU(unsigned, mce_poll_count);
 void machine_check_poll(enum mcp_flags flags, mce_banks_t *b)
 {
struct mce m;
+   int severity;
int i;
 
this_cpu_inc(mce_poll_count);
@@ -630,6 +666,20 @@ void machine_check_poll(enum mcp_flags flags, mce_banks_t 
*b)
 
if (!(flags & MCP_TIMESTAMP))
m.tsc = 0;
+
+   severity = mce_severity(, mca_cfg.tolerant, NULL, false);
+
+   /*
+* In the cases where we don't have a valid address after all,
+* do not add it into the ring buffer.
+*/
+   if (severity == MCE_DEFERRED_SEVERITY && memory_error()) {
+   if (m.status & MCI_STATUS_ADDRV) {
+   mce_ring_add(m.addr >> PAGE_SHIFT);
+   mce_schedule_work();
+   }
+   }
+
/*
 * Don't get the IP here because it's unlikely to
 * have anything to do with the actual error location.
-- 
1.7.10.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  

[PATCH v3 1/2] x86, mce, severity: extend the the mce_severity mechanism to handle UCNA/DEFERRED error

[Chen Yucong]

Until now, the mce_severity mechanism can only identify the severity
of UCNA error as MCE_KEEP_SEVERITY. Meanwhile, it is not able to filter
out DEFERRED error for ADM platform.

This patch aims to extend the mce_severity mechanism for handling
UCNA/DEFERRED error. In order to do this, the patch introduces a new
severity level - MCE_UCNA/DEFERRED_SEVERITY.

In addition, mce_severity is specific to machine check exception,
and it will check MCIP/EIPV/RIPV bits. In order to use mce_severity
mechanism in non-exception context, the patch also introduces a new
argument (is_excp) for mce_severity. `is_excp' is used to explicitly
specify the calling context of mce_severity.

Signed-off-by: Chen Yucong 
---
 arch/x86/include/asm/mce.h|4 
 arch/x86/kernel/cpu/mcheck/mce-internal.h |4 +++-
 arch/x86/kernel/cpu/mcheck/mce-severity.c |   21 -
 arch/x86/kernel/cpu/mcheck/mce.c  |   14 --
 drivers/edac/mce_amd.h|3 ---
 5 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 276392f..51b26e89 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -34,6 +34,10 @@
 #define MCI_STATUS_S(1ULL<<56)  /* Signaled machine check */
 #define MCI_STATUS_AR   (1ULL<<55)  /* Action required */
 
+/* AMD-specific bits */
+#define MCI_STATUS_DEFERRED(1ULL<<44)  /* declare an uncorrected error */
+#define MCI_STATUS_POISON  (1ULL<<43)  /* access poisonous data */
+
 /*
  * Note that the full MCACOD field of IA32_MCi_STATUS MSR is
  * bits 15:0.  But bit 12 is the 'F' bit, defined for corrected
diff --git a/arch/x86/kernel/cpu/mcheck/mce-internal.h 
b/arch/x86/kernel/cpu/mcheck/mce-internal.h
index 09edd0b..10b4690 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-internal.h
+++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h
@@ -3,6 +3,8 @@
 
 enum severity_level {
MCE_NO_SEVERITY,
+   MCE_DEFERRED_SEVERITY,
+   MCE_UCNA_SEVERITY = MCE_DEFERRED_SEVERITY,
MCE_KEEP_SEVERITY,
MCE_SOME_SEVERITY,
MCE_AO_SEVERITY,
@@ -21,7 +23,7 @@ struct mce_bank {
charattrname[ATTR_LEN]; /* attribute name */
 };
 
-int mce_severity(struct mce *a, int tolerant, char **msg);
+int mce_severity(struct mce *a, int tolerant, char **msg, bool is_excp);
 struct dentry *mce_get_debugfs_dir(void);
 
 extern struct mce_bank *mce_banks;
diff --git a/arch/x86/kernel/cpu/mcheck/mce-severity.c 
b/arch/x86/kernel/cpu/mcheck/mce-severity.c
index c370e1c..c61feb3 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c
@@ -31,6 +31,7 @@
 
 enum context { IN_KERNEL = 1, IN_USER = 2 };
 enum ser { SER_REQUIRED = 1, NO_SER = 2 };
+enum exception { EXCP_CONTEXT = 1, NO_EXCP = 2 };
 
 static struct severity {
u64 mask;
@@ -40,6 +41,7 @@ static struct severity {
unsigned char mcgres;
unsigned char ser;
unsigned char context;
+   unsigned char excp;
unsigned char covered;
char *msg;
 } severities[] = {
@@ -48,6 +50,8 @@ static struct severity {
 #define  USER  .context = IN_USER
 #define  SER   .ser = SER_REQUIRED
 #define  NOSER .ser = NO_SER
+#define  EXCP  .excp = EXCP_CONTEXT
+#define  NOEXCP.excp = NO_EXCP
 #define  BITCLR(x) .mask = x, .result = 0
 #define  BITSET(x) .mask = x, .result = x
 #define  MCGMASK(x, y) .mcgmask = x, .mcgres = y
@@ -71,16 +75,20 @@ static struct severity {
/* When MCIP is not set something is very confused */
MCESEV(
PANIC, "MCIP not set in MCA handler",
-   MCGMASK(MCG_STATUS_MCIP, 0)
+   EXCP, MCGMASK(MCG_STATUS_MCIP, 0)
),
/* Neither return not error IP -- no chance to recover -> PANIC */
MCESEV(
PANIC, "Neither restart nor error IP",
-   MCGMASK(MCG_STATUS_RIPV|MCG_STATUS_EIPV, 0)
+   EXCP, MCGMASK(MCG_STATUS_RIPV|MCG_STATUS_EIPV, 0)
),
MCESEV(
PANIC, "In kernel and no restart IP",
-   KERNEL, MCGMASK(MCG_STATUS_RIPV, 0)
+   EXCP, KERNEL, MCGMASK(MCG_STATUS_RIPV, 0)
+   ),
+   MCESEV(
+   DEFERRED, "Deferred error",
+   NOSER, 
MASK(MCI_STATUS_UC|MCI_STATUS_DEFERRED|MCI_STATUS_POISON, MCI_STATUS_DEFERRED)
),
MCESEV(
KEEP, "Corrected error",
@@ -89,7 +97,7 @@ static struct severity {
 
/* ignore OVER for UCNA */
MCESEV(
-   KEEP, "Uncorrected no action required",
+   UCNA, "Uncorrected no action required",
SER, MASK(MCI_UC_SAR, MCI_STATUS_UC)
),
MCESEV(
@@ -178,8 +186,9 @@ static int error_context(struct mce *m)
return ((m->cs & 3) == 3) ? IN_USER : IN_KERNEL;
 }
 
-int 

[PATCH v3 0/2]RAS: add the support for handling UCNA/DEFERRED error

[Chen Yucong]

Hi all,

At the suggestion of Boris, the first patch extends the mce_severity
mechanism for handling UCNA/DEFERRED error.
  Link: https://lkml.org/lkml/2014/10/23/190

v2:
The first patch have also eliminated a big hack to make mce_severity() 
work when called from non-exception context on the advice of Tony and 
Boris.
  Link: https://lkml.org/lkml/2014/10/27/1017

And on the basis of the first patch, the second patch adds the support
for identifying and handling UCNA/DEFERRED error in machine_check_poll.

V3:
According to Boris, the second patch have also split `memory_error' 
from mem_deferred_error so that the memory_error() function can be used
in other code paths separately. 
  Link: https://lkml.org/lkml/2014/11/6/452

Boris also reported the warning about "MCI_STATUS_POISON" and  
"MCI_STATUS_POISON"
redefined.

thx!
cyc

[PATCH v3 1/2] x86, mce, severity: extend the the mce_severity
[PATCH v3 2/2] x86, mce: support memory error recovery for both UCNA
--
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 5/5] cpufreq, add BUG() messages in critical paths to aid debugging failures

[Rafael J. Wysocki]

On Wednesday, November 05, 2014 09:53:59 AM Prarit Bhargava wrote:
> Add some additional debug to capture failures in the locking scheme for
> cpufreq.  Instead of just a NULL pointer, these warnings will capture failure
> points if the locking scheme for cpufreq is broken.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Prarit Bhargava 
> ---
>  drivers/cpufreq/cpufreq_governor.c |   32 +++-
>  1 file changed, 27 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq_governor.c 
> b/drivers/cpufreq/cpufreq_governor.c
> index b1ee597..f158882 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -161,9 +161,18 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
>  EXPORT_SYMBOL_GPL(dbs_check_cpu);
>  
>  static inline void __gov_queue_work(int cpu, struct dbs_data *dbs_data,
> - unsigned int delay)
> + unsigned int delay,
> + struct cpufreq_policy *policy)
>  {
> - struct cpu_dbs_common_info *cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
> + struct cpu_dbs_common_info *cdbs;
> +
> + if (!dbs_data->cdata) {
> + pr_emerg("common_dbs_data is NULL for %s but initialized = %d",
> +  policy->governor->name,
> +  atomic_read(>governor->initialized));
> + BUG();

Is it necessary to crash the kernel here?

> + }
> + cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
>  
>   mod_delayed_work_on(cpu, system_wq, >work, delay);
>  }
> @@ -185,10 +194,11 @@ void gov_queue_work(struct dbs_data *dbs_data, struct 
> cpufreq_policy *policy,
>* those works are canceled during CPU_DOWN_PREPARE so they
>* can't possibly run on any other CPU.
>*/
> - __gov_queue_work(raw_smp_processor_id(), dbs_data, delay);
> + __gov_queue_work(raw_smp_processor_id(), dbs_data, delay,
> +  policy);
>   } else {
>   for_each_cpu(i, policy->cpus)
> - __gov_queue_work(i, dbs_data, delay);
> + __gov_queue_work(i, dbs_data, delay, policy);
>   }
>  
>  out_unlock:
> @@ -258,7 +268,13 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>   else
>   dbs_data = cdata->gdbs_data;
>  
> - WARN_ON(!dbs_data && (event != CPUFREQ_GOV_POLICY_INIT));
> + if (!dbs_data && (event != CPUFREQ_GOV_POLICY_INIT)) {
> + pr_emerg("governor_data is NULL but governor %s is initialized 
> = %d [governor_enabled = %d event = %u]\n",
> +  policy->governor->name,
> +  atomic_read(>governor->initialized),
> +  policy->governor_enabled, event);
> + BUG();

And here?

> + }
>  
>   switch (event) {
>   case CPUFREQ_GOV_POLICY_INIT:
> @@ -329,6 +345,12 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>   case CPUFREQ_GOV_POLICY_EXIT:
>   mutex_lock(_data->usage_count_mutex);
>   if (atomic_dec_and_test(_data->usage_count)) {
> + if (atomic_read(>governor->initialized) > 1) {
> + pr_emerg("Removing governor %s but initialized 
> = %d, dbs_data->usage_count = 0\n",
> +  policy->governor->name,
> +atomic_read(>governor->initialized));
> + BUG();
> + }
>   sysfs_remove_group(get_governor_parent_kobj(policy),
>   get_sysfs_attr(dbs_data));
>  
> 

-- 
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 4/5] cpufreq, policy->initialized count must be atomic

[Rafael J. Wysocki]

On Wednesday, November 05, 2014 09:53:58 AM Prarit Bhargava wrote:
> The policy->initialized value can be modified from several cpus concurrently 
> if
> !CPUFREQ_HAVE_GOVERNOR_PER_POLICY.  This leads to a situation where a
> governor maybe switched out even though the governor->initialized is greater
> than one.  It must be switched to atomic_t and protected with a mutex to
> make sure that future read/writes obtain the correct data.

Same comments as for [3/5].  If you add a new mutex, you can avoid using
atomic_t.

> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Prarit Bhargava 
> ---
>  drivers/cpufreq/cpufreq.c  |   12 +---
>  drivers/cpufreq/cpufreq_governor.c |4 ++--
>  include/linux/cpufreq.h|3 ++-
>  3 files changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index e33cb15..cf11de6 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2059,10 +2059,12 @@ static int __cpufreq_governor(struct cpufreq_policy 
> *policy,
>   ret = policy->governor->governor(policy, event);
>  
>   if (!ret) {
> + mutex_lock(>governor->initialized_mutex);
>   if (event == CPUFREQ_GOV_POLICY_INIT)
> - policy->governor->initialized++;
> + atomic_inc(>governor->initialized);
>   else if (event == CPUFREQ_GOV_POLICY_EXIT)
> - policy->governor->initialized--;
> + atomic_dec(>governor->initialized);
> + mutex_unlock(>governor->initialized_mutex);
>   } else {
>   /* Restore original values */
>   mutex_lock(_governor_lock);
> @@ -2092,7 +2094,11 @@ int cpufreq_register_governor(struct cpufreq_governor 
> *governor)
>  
>   mutex_lock(_governor_mutex);
>  
> - governor->initialized = 0;
> + mutex_init(>initialized_mutex);
> + mutex_lock(>initialized_mutex);
> + atomic_set(>initialized, 0);
> + mutex_unlock(>initialized_mutex);
> +
>   err = -EBUSY;
>   if (__find_governor(governor->name) == NULL) {
>   err = 0;
> diff --git a/drivers/cpufreq/cpufreq_governor.c 
> b/drivers/cpufreq/cpufreq_governor.c
> index 32ad9db..b1ee597 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -315,7 +315,7 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>   latency * LATENCY_MULTIPLIER));
>  
>   if ((cdata->governor == GOV_CONSERVATIVE) &&
> - (!policy->governor->initialized)) {
> + (!atomic_read(>governor->initialized))) {
>   struct cs_ops *cs_ops = dbs_data->cdata->gov_ops;
>  
>   cpufreq_register_notifier(cs_ops->notifier_block,
> @@ -336,7 +336,7 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>   cpufreq_put_global_kobject();
>  
>   if ((dbs_data->cdata->governor == GOV_CONSERVATIVE) &&
> - (policy->governor->initialized == 1)) {
> + atomic_read(>governor->initialized) == 1) {
>   struct cs_ops *cs_ops = 
> dbs_data->cdata->gov_ops;
>  
>   
> cpufreq_unregister_notifier(cs_ops->notifier_block,
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 43909ad..73cec45 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -431,7 +431,8 @@ static inline unsigned long cpufreq_scale(unsigned long 
> old, u_int div,
>  
>  struct cpufreq_governor {
>   charname[CPUFREQ_NAME_LEN];
> - int initialized;
> + struct mutex initialized_mutex;
> + atomic_t initialized;
>   int (*governor) (struct cpufreq_policy *policy,
>unsigned int event);
>   ssize_t (*show_setspeed)(struct cpufreq_policy *policy,
> 

-- 
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 3/5] cpufreq, dbs_data->usage count must be atomic

[Rafael J. Wysocki]

On Wednesday, November 05, 2014 09:53:57 AM Prarit Bhargava wrote:
> The usage_count value can be modified from several cpus concurrently if
> !CPUFREQ_HAVE_GOVERNOR_PER_POLICY.  This leads to a variety of panics in
> which the usage_count is negative or exceeds the number of cpus in the
> system.  It must be switched to atomic_t and protected with a mutex to make 
> sure
> that future read/writes obtain the correct data.

Why do you need to use a new mutex and atomic_t at the same time?  Most likely
one of them is redundant.

> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Prarit Bhargava 
> ---
>  drivers/cpufreq/cpufreq_governor.c |   16 
>  drivers/cpufreq/cpufreq_governor.h |3 ++-
>  2 files changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq_governor.c 
> b/drivers/cpufreq/cpufreq_governor.c
> index 1b44496..32ad9db 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -265,7 +265,9 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>   if (have_governor_per_policy()) {
>   WARN_ON(dbs_data);
>   } else if (dbs_data) {
> - dbs_data->usage_count++;
> + mutex_lock(_data->usage_count_mutex);
> + atomic_inc(_data->usage_count);
> + mutex_unlock(_data->usage_count_mutex);
>   policy->governor_data = dbs_data;
>   return 0;
>   }
> @@ -277,7 +279,10 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>   }
>  
>   dbs_data->cdata = cdata;
> - dbs_data->usage_count = 1;
> + mutex_init(_data->usage_count_mutex);
> + mutex_lock(_data->usage_count_mutex);
> + atomic_set(_data->usage_count, 1);
> + mutex_unlock(_data->usage_count_mutex);

The locking here isn't necessary (if it was, someone could be using an
uninitialized mutex).

>   rc = cdata->init(dbs_data);
>   if (rc) {
>   pr_err("%s: POLICY_INIT: init() failed\n", __func__);
> @@ -322,7 +327,8 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>  
>   return 0;
>   case CPUFREQ_GOV_POLICY_EXIT:
> - if (!--dbs_data->usage_count) {
> + mutex_lock(_data->usage_count_mutex);
> + if (atomic_dec_and_test(_data->usage_count)) {
>   sysfs_remove_group(get_governor_parent_kobj(policy),
>   get_sysfs_attr(dbs_data));
>  
> @@ -338,9 +344,11 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>   }
>  
>   cdata->exit(dbs_data);
> + mutex_unlock(_data->usage_count_mutex);
>   kfree(dbs_data);
>   cdata->gdbs_data = NULL;
> - }
> + } else
> + mutex_unlock(_data->usage_count_mutex);
>  
>   policy->governor_data = NULL;
>   return 0;
> diff --git a/drivers/cpufreq/cpufreq_governor.h 
> b/drivers/cpufreq/cpufreq_governor.h
> index cc401d1..53ca449 100644
> --- a/drivers/cpufreq/cpufreq_governor.h
> +++ b/drivers/cpufreq/cpufreq_governor.h
> @@ -219,7 +219,8 @@ struct common_dbs_data {
>  struct dbs_data {
>   struct common_dbs_data *cdata;
>   unsigned int min_sampling_rate;
> - int usage_count;
> + struct mutex usage_count_mutex;
> + atomic_t usage_count;
>   void *tuners;
>  
>   /* dbs_mutex protects dbs_enable in governor start/stop */
> 

-- 
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] scripts/package: binrpm-pkg do not build source tar file

[Jerome Glisse]

On Fri, Oct 31, 2014 at 03:05:31PM -0400, j.gli...@gmail.com wrote:
> From: Jérôme Glisse 
> 
> When doing make binrpm-pkg we do not want to build the source tar
> file. This patch avoid doing the gigantic tar file.
> 
> Signed-off-by: Jérôme Glisse 
> Cc: linux-kbu...@vger.kernel.org
> Cc: Michal Marek 
> Cc: Linus Torvalds 

Anyone ? Bueller ?

> ---
>  scripts/package/mkspec | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/scripts/package/mkspec b/scripts/package/mkspec
> index 1395760..b6f5e31 100755
> --- a/scripts/package/mkspec
> +++ b/scripts/package/mkspec
> @@ -119,8 +119,10 @@ echo "%endif"
>  
>  echo 'rm -f $RPM_BUILD_ROOT'"/lib/modules/$KERNELRELEASE/{build,source}"
>  echo "mkdir -p "'$RPM_BUILD_ROOT'"/usr/src/kernels/$KERNELRELEASE"
> +if ! $PREBUILT; then
>  echo "EXCLUDES=\"$RCS_TAR_IGNORE --exclude .tmp_versions --exclude=*vmlinux* 
> --exclude=*.o --exclude=*.ko --exclude=*.cmd --exclude=Documentation 
> --exclude=firmware --exclude .config.old --exclude .missing-syscalls.d\""
>  echo "tar "'$EXCLUDES'" -cf- . | (cd 
> "'$RPM_BUILD_ROOT'"/usr/src/kernels/$KERNELRELEASE;tar xvf -)"
> +fi
>  echo 'cd $RPM_BUILD_ROOT'"/lib/modules/$KERNELRELEASE"
>  echo "ln -sf /usr/src/kernels/$KERNELRELEASE build"
>  echo "ln -sf /usr/src/kernels/$KERNELRELEASE source"
> -- 
> 1.9.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] PM / Hibernate: Migrate to ktime_t

[Rafael J. Wysocki]

On Thursday, October 30, 2014 08:08:17 PM Arnd Bergmann wrote:
> On Thursday 30 October 2014 11:04:53 Tina Ruchandani wrote:
> > This patch migrates swsusp_show_speed and its callers to using ktime_t 
> > instead
> > of 'struct timeval' which suffers from the y2038 problem.
> > 
> > Changes to swsusp_show_speed:
> > - use ktime_t for start and stop times
> > - pass start and stop times by value
> > Calling functions affected:
> > - load_image
> > - load_image_lzo
> > - save_image
> > - save_image_lzo
> > - hibernate_preallocate_memory
> > Design decisions:
> > - use ktime_t to preserve same granularity of reporting as before
> > - use centisecs logic as before to avoid 'div by zero' issues 
> > caused by
> >   using seconds and nanoseconds directly
> > - use monotonic time (ktime_get()) since we only care about elapsed 
> > time.
> > 
> > Signed-off-by: Tina Ruchandani 
> > Suggested-by: Arnd Bergmann 
> 
> Reviewed-by: Arnd Bergmann 

Patch queued up for 3.19-rc1, thanks!


-- 
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 0/3] Tools: hv: vssdaemon: freeze/thaw logic improvement for the failure case

[Dexuan Cui]

> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Saturday, November 8, 2014 1:09 AM
> To: KY Srinivasan; Haiyang Zhang; Greg Kroah-Hartman
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; Dexuan Cui
> Subject: [PATCH 0/3] Tools: hv: vssdaemon: freeze/thaw logic improvement
> for the failure case
> 
> This patch series addresses the following issues:
> - Wrong error reporting for multiple filesystems case.
> - Skip all readonly-mounted filesystems instead of skipping iso9660.
> - Thaw all filesystems after an unsuccessful freeze attempt.
> 
> Vitaly Kuznetsov (3):
>   Tools: hv: vssdaemon: consult with errno in case of failure only
>   Tools: hv: vssdaemon: skip all filesystems mounted readonly
>   Tools: hv: vssdaemon: thaw everything in case of freeze failure
> 
>  tools/hv/hv_vss_daemon.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)

Hi Vitaly,
Thanks for your patchset!

FYI: Greg checked in a patch of mine several hours ago -- my patch
implemented "thaw all filesytems on a failure of freeze" too. :-)

Please see my patch in Greg's char-misc-next tree:
https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next=4f689190bb55d171d2f6614f8a6cbd4b868e48bd

Can you please rebase  your patch(es) on Greg's tree?

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

Re: [PATCH V3 6/6] cpufreq: Loongson1: Add cpufreq driver for Loongson1B

[Rafael J. Wysocki]

On Friday, October 17, 2014 04:07:50 PM Viresh Kumar wrote:
> On 17 October 2014 15:53, Kelvin Cheung  wrote:
> > This patch adds cpufreq driver for Loongson1B which
> > is capable of changing the CPU frequency dynamically.
> >
> > Signed-off-by: Kelvin Cheung 
> >
> > ---
> > V3:
> >Remove superfluous devm_clk_put().
> 
> Sorry for being bad to you :)
> 
> > +static int ls1x_cpufreq_probe(struct platform_device *pdev)
> > +{
> > +   struct plat_ls1x_cpufreq *pdata = pdev->dev.platform_data;
> > +   struct clk *clk;
> > +   int ret;
> > +
> > +   if (!pdata || !pdata->clk_name || !pdata->osc_clk_name)
> > +   return -EINVAL;
> > +
> > +   ls1x_cpufreq.dev = >dev;
> > +
> > +   clk = devm_clk_get(>dev, pdata->clk_name);
> > +   if (IS_ERR(clk)) {
> > +   dev_err(ls1x_cpufreq.dev, "unable to get %s clock\n",
> > +   pdata->clk_name);
> > +   ret = PTR_ERR(clk);
> > +   goto out;
> > +   }
> > +   ls1x_cpufreq.clk = clk;
> > +
> > +   clk = clk_get_parent(clk);
> > +   if (IS_ERR(clk)) {
> > +   dev_err(ls1x_cpufreq.dev, "unable to get parent of %s 
> > clock\n",
> > +   __clk_get_name(ls1x_cpufreq.clk));
> > +   ret = PTR_ERR(clk);
> > +   goto out;
> > +   }
> > +   ls1x_cpufreq.mux_clk = clk;
> > +
> > +   clk = clk_get_parent(clk);
> > +   if (IS_ERR(clk)) {
> > +   dev_err(ls1x_cpufreq.dev, "unable to get parent of %s 
> > clock\n",
> > +   __clk_get_name(ls1x_cpufreq.mux_clk));
> > +   ret = PTR_ERR(clk);
> > +   goto out;
> > +   }
> > +   ls1x_cpufreq.pll_clk = clk;
> > +
> > +   clk = devm_clk_get(>dev, pdata->osc_clk_name);
> > +   if (IS_ERR(clk)) {
> > +   dev_err(ls1x_cpufreq.dev, "unable to get %s clock\n",
> > +   pdata->osc_clk_name);
> > +   ret = PTR_ERR(clk);
> > +   goto out;
> > +   }
> > +   ls1x_cpufreq.osc_clk = clk;
> > +
> > +   ls1x_cpufreq.max_freq = pdata->max_freq;
> > +   ls1x_cpufreq.min_freq = pdata->min_freq;
> > +
> > +   ret = cpufreq_register_driver(_cpufreq_driver);
> > +   if (ret) {
> > +   dev_err(ls1x_cpufreq.dev,
> > +   "failed to register cpufreq driver: %d\n", ret);
> > +   goto out;
> > +   }
> > +
> > +   ret = cpufreq_register_notifier(_cpufreq_notifier_block,
> > +   CPUFREQ_TRANSITION_NOTIFIER);
> > +
> > +   if (!ret)
> > +   goto out;
> > +
> > +   dev_err(ls1x_cpufreq.dev, "failed to register cpufreq notifier: 
> > %d\n",
> > +   ret);
> > +
> > +   cpufreq_unregister_driver(_cpufreq_driver);
> > +out:
> 
> But all these goto out; doesn't make sense anymore. Just issue returns
> from all places and add
> 
> Acked-by: Viresh Kumar 

Patch queued up for 3.19-rc1, thanks!


-- 
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] cpufreq: allow powersave governor as the default without expert mode

[Rafael J. Wysocki]

On Thursday, October 30, 2014 11:15:09 PM Dirk Brandewie wrote:
> On 10/30/2014 02:18 PM, Rafael J. Wysocki wrote:
> > On Thursday, October 16, 2014 07:37:11 AM James Geboski wrote:
> >> The intel_pstate driver only supports the performance and the powersave
> >> governors. With the performance governor ensuring the highest possible
> >> performance settings, userspace tools fail to make any lasting changes.
> >> In order to allow userspace tools to make modifications to the settings,
> >> the powersave governor must be in use. This makes having the powersave
> >> governor as the default convenient for systems where the intel_pstate
> >> driver is being employed. Having to enable expert mode in the kernel
> >> configuration is just a headache for such a trivial task.
> >>
> >> This patch applies to all kernel versions 2.6.38 or greater after the
> >> migration from CONFIG_EMBEDDED to CONFIG_EXPERT (6a108a14fa35). Most
> >> importantly, this applies to kernel versions 3.9 or greater when the
> >> intel_pstate driver was introduced.
> >>
> >> Signed-off-by: James Geboski 
> >> Acked-by: Viresh Kumar 
> >
> > Dirk, any objections?
> 
> No objection.

OK, patch queued up for 3.19-rc1, thanks!


-- 
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] PM / Runtime: Rework RPM get callback routines

[Rafael J. Wysocki]

On Wednesday, October 29, 2014 10:58:18 AM Kevin Hilman wrote:
> Andrzej Hajda  writes:
> 
> > PM uses three separate functions to fetch RPM callbacks.
> > These functions uses quite complicated macro in their body.
> > The patch replaces these routines with one small macro and
> > one helper function.
> >
> > Signed-off-by: Andrzej Hajda 
> 
> Acked-by: Kevin Hilman 

Patch queued up for 3.19-rc1, thanks everyone!


-- 
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 v7 4/4] thermal: Add Tegra SOCTHERM thermal management driver

[Mikko Perttunen]

On 11/07/2014 05:54 PM, Eduardo Valentin wrote:

Terve Mikko,

On Wed, Oct 15, 2014 at 01:05:19PM +0300, Mikko Perttunen wrote:

Eduardo: ping




I had no objections with the driver at this point. Neither with the DT
part. I decided to include it in my -linus queue, which means, it will
hopefully be queued in the next major merge windown (v3.19).

I also merged it to my -next branch, for linux-next testing.


Great! Thanks.





Cheers,
Mikko

On 09/29/2014 05:17 PM, Mikko Perttunen wrote:

From: Mikko Perttunen 


BTW, this nvidia address is bouncing. I noticed because my automated
'I applied it on queue xyz' notification message has returned.


Yeah, I'm working at NVIDIA only during summer. Looks like this time 
they decided to deactivate my email there.






This adds support for the Tegra SOCTHERM thermal sensing and management
system found in the Tegra124 system-on-chip. This initial driver supports
temperature polling for four thermal zones.

Signed-off-by: Mikko Perttunen 
---
v7: bunch of style fixes

   drivers/thermal/Kconfig  |  10 +
   drivers/thermal/Makefile |   1 +
   drivers/thermal/tegra_soctherm.c | 473 
+++
   3 files changed, 484 insertions(+)
   create mode 100644 drivers/thermal/tegra_soctherm.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 693208e..fd9d049 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -175,6 +175,16 @@ config ARMADA_THERMAL
  Enable this option if you want to have support for thermal management
  controller present in Armada 370 and Armada XP SoC.

+config TEGRA_SOCTHERM
+   tristate "Tegra SOCTHERM thermal management"
+   depends on ARCH_TEGRA
+   help
+ Enable this option for integrated thermal management support on NVIDIA
+ Tegra124 systems-on-chip. The driver supports four thermal zones
+ (CPU, GPU, MEM, PLLX). Cooling devices can be bound to the thermal
+ zones to manage temperatures. This option is also required for the
+ emergency thermal reset (thermtrip) feature to function.
+
   config DB8500_CPUFREQ_COOLING
tristate "DB8500 cpufreq cooling"
depends on ARCH_U8500
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 31e232f..f0b94d5 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_INTEL_SOC_DTS_THERMAL)   += 
intel_soc_dts_thermal.o
   obj-$(CONFIG_TI_SOC_THERMAL) += ti-soc-thermal/
   obj-$(CONFIG_ACPI_INT3403_THERMAL)   += int3403_thermal.o
   obj-$(CONFIG_ST_THERMAL) += st/
+obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra_soctherm.o
diff --git a/drivers/thermal/tegra_soctherm.c b/drivers/thermal/tegra_soctherm.c
new file mode 100644
index 000..70f7e9e
--- /dev/null
+++ b/drivers/thermal/tegra_soctherm.c
@@ -0,0 +1,473 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Author:
+ * Mikko Perttunen 
+ *


Might be time to send a patch on top of my -linus queue to update the
above with a valid email address.

Thanks,


+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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 
+
+#include 
+
+#define SENSOR_CONFIG0 0
+#define SENSOR_CONFIG0_STOPBIT(0)
+#define SENSOR_CONFIG0_TALL_SHIFT  8
+#define SENSOR_CONFIG0_TCALC_OVER  BIT(4)
+#define SENSOR_CONFIG0_OVERBIT(3)
+#define SENSOR_CONFIG0_CPTR_OVER   BIT(2)
+
+#define SENSOR_CONFIG1 4
+#define SENSOR_CONFIG1_TSAMPLE_SHIFT   0
+#define SENSOR_CONFIG1_TIDDQ_EN_SHIFT  15
+#define SENSOR_CONFIG1_TEN_COUNT_SHIFT 24
+#define SENSOR_CONFIG1_TEMP_ENABLE BIT(31)
+
+#define SENSOR_CONFIG2 8
+#define SENSOR_CONFIG2_THERMA_SHIFT16
+#define SENSOR_CONFIG2_THERMB_SHIFT0
+
+#define SENSOR_PDIV0x1c0
+#define SENSOR_PDIV_T124   0x
+#define SENSOR_HOTSPOT_OFF 0x1c4
+#define SENSOR_HOTSPOT_OFF_T1240x00060600
+#define SENSOR_TEMP1   0x1c8
+#define SENSOR_TEMP2   0x1cc
+
+#define SENSOR_TEMP_MASK   0x
+#define READBACK_VALUE_MASK0xff00
+#define READBACK_VALUE_SHIFT   8
+#define READBACK_ADD_HALF

[PATCH v2] clk: Propagate prepare and enable when reparenting orphans

[Doug Anderson]

With the existing code, if you find a parent for an orhpan that has
already been prepared / enabled, you won't enable the parent.  That
can cause later problems since the clock tree isn't in a consistent
state.  Fix by propagating the prepare and enable.

NOTE: this does bring up the question about whether the enable of the
orphan actually made sense.  If the orphan's parent wasn't enabled by
default (by the bootloader or the default state of the hardware) then
the original enable of the orphan probably didn't do what the caller
though it would.  Some users of the orphan might have preferred an
EPROBE_DEFER be returned until we had a full path to a root clock.
This patch doesn't address those concerns and really just syncs up the
state.

Tested on rk3288-evb-rk808 by temporarily considering "sclk_tsadc" as
a critical clock (to simulate a driver enabling it at bootup).

Before:

   clock enable_cnt  prepare_cntrate   accuracy 
  phase

 xin32k   00   32768  0 0
sclk_hdmi_cec 00   32768  0 0
sclk_otg_adp  00   32768  0 0
sclk_tsadc11 993  0 0

After:

   clock enable_cnt  prepare_cntrate   accuracy 
  phase

 xin32k   11   32768  0 0
sclk_hdmi_cec 00   32768  0 0
sclk_otg_adp  00   32768  0 0
sclk_tsadc11 993  0 0

Note that xin32k on rk808 is a clock that cannot be disabled in
hardware (it's an always on clock), so really all we needed to do was
to sync up the state.

Signed-off-by: Doug Anderson 
---
Changes in v2:
- Only do the work for orphans, not for other users of __clk_reparent().

 drivers/clk/clk.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 4896ae9..0f04b7c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1652,6 +1652,22 @@ void __clk_reparent(struct clk *clk, struct clk 
*new_parent)
__clk_recalc_rates(clk, POST_RATE_CHANGE);
 }
 
+static void __clk_reparent_orphan(struct clk *clk, struct clk *new_parent)
+{
+   __clk_reparent(clk, new_parent);
+
+   if (clk->prepare_count) {
+   unsigned long flags;
+
+   __clk_prepare(new_parent);
+
+   flags = clk_enable_lock();
+   if (clk->enable_count)
+   __clk_enable(new_parent);
+   clk_enable_unlock(flags);
+   }
+}
+
 /**
  * clk_set_parent - switch the parent of a mux clk
  * @clk: the mux clk whose input we are switching
@@ -1953,13 +1969,13 @@ int __clk_init(struct device *dev, struct clk *clk)
if (orphan->num_parents && orphan->ops->get_parent) {
i = orphan->ops->get_parent(orphan->hw);
if (!strcmp(clk->name, orphan->parent_names[i]))
-   __clk_reparent(orphan, clk);
+   __clk_reparent_orphan(orphan, clk);
continue;
}
 
for (i = 0; i < orphan->num_parents; i++)
if (!strcmp(clk->name, orphan->parent_names[i])) {
-   __clk_reparent(orphan, clk);
+   __clk_reparent_orphan(orphan, clk);
break;
}
 }
-- 
2.1.0.rc2.206.gedb03e5

--
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] [RFC] cpufreq: Avoid crash in resume on SMP without OPP

[Rafael J. Wysocki]

On Tuesday, November 04, 2014 05:05:25 PM Geert Uytterhoeven wrote:
> When resuming from s2ram on an SMP system without cpufreq operating
> points (e.g. there's no "operating-points" property for the CPU node in
> DT, or the platform doesn't use DT yet), the kernel crashes when
> bringing CPU 1 online:
> 
> Enabling non-boot CPUs ...
> CPU1: Booted secondary processor
> Unable to handle kernel NULL pointer dereference at virtual address 
> 003c
> pgd = ee5e6b00
> [003c] *pgd=6e579003, *pmd=6e588003, *pte=
> Internal error: Oops: a07 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1246 Comm: s2ram Tainted: GW  
> 3.18.0-rc3-koelsch-01614-g0377af242bb175c8-dirty #589
> task: eeec5240 ti: ee704000 task.ti: ee704000
> PC is at __cpufreq_add_dev.isra.24+0x24c/0x77c
> LR is at __cpufreq_add_dev.isra.24+0x244/0x77c
> pc : []lr : []psr: 6153
> sp : ee705d48  ip : ee705d48  fp : ee705d84
> r10: c04e0450  r9 :   r8 : 0001
> r7 : c05426a8  r6 : 0001  r5 : 0001  r4 : 
> r3 :   r2 :   r1 : 2153  r0 : c0542734
> 
> Verify that policy is not NULL before dereferencing it to fix this.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> Notes:
>   - Is this the right fix?

The fix looks correct to me.

To my eyes what happens is that cpufreq_driver->init() in __cpufreq_add_dev()
fails and then cpufreq_cpu_data_fallback is cleared.  cpufreq_cpu_data is not
set for the CPU, so cpufreq_cpu_data_fallback is NULL all the time.  Then,
during resume, __cpufreq_add_dev() is called again and it calls
cpufreq_policy_restore(), because cpufreq_suspended is set.  You know the rest. 
:-)

I'm queuing this up for the next PM pull request (most likely next week
for -rc5).

>   - Interestingly, the crash is the same as the one reported in
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c81407fe573d8ac3c7150f5373475598c59197de
> ("cpufreq: cpufreq-dt: Restore default cpumask_setall(policy->cpus)"),
> but the cause is different.
> 
>   - The crash was initially observed on sh73a0/kzm9g-legacy, but it can
> easily be reproduced on e.g. r8a7791/koelsch, by removing the
> "operating-points" property from the cpu0 node in
> arch/arm/boot/dts/r8a7791.dtsi, or by any other means to make the
> call to dev_pm_opp_init_cpufreq_table() in
> drivers/cpufreq/cpufreq-dt.c:cpufreq_init() fail.
> 
>   - I did not add
> 
>   Fixes: 6e2c89d16d987e6e ("cpufreq: move call to __find_governor() to 
> cpufreq_init_policy()")

To me, that should be:

Fixes: 8414809c6a1e (cpufreq: Preserve policy structure across 
suspend/resume)

and therefore should go into 3.12+.

I'll add the appropriate tags.

> 
> as I couldn't verify that the issue is also present in that (old)
> version (there have been too many s2ram-related platform and driver
> fixes since v3.15).
> ---
>  drivers/cpufreq/cpufreq.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 644b54e1e7d13e8e..4473eba1d6b0b608 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1022,7 +1022,8 @@ static struct cpufreq_policy 
> *cpufreq_policy_restore(unsigned int cpu)
>  
>   read_unlock_irqrestore(_driver_lock, flags);
>  
> - policy->governor = NULL;
> + if (policy)
> + policy->governor = NULL;
>  
>   return policy;
>  }
> 

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

[RFC PATCH] KSM: Auto add flag new VMA as VM_MERGEABLE

[Timofey Titovets]

Hi list.

This is a small patch what allow ksm dedupe "whole" system memory.
I think what people with tiny pc and android developers will be happy 
after this patch.

I just like clear memory =].

I have tested it and it working very good. For testing apply it and 
enable ksm:

echo 1 | sudo tee /sys/kernel/mm/ksm/run
This show how much memory saved:
echo $[$(cat /sys/kernel/mm/ksm/pages_shared)*$(getconf PAGE_SIZE)/1024 ]KB

(i use linux-next-git 20141031)

It add very small overhead to mmap call's.

Please check my code, may be i should move new functions to other file?
I think about sysfs switcher like:
/sys/kernel/mm/ksm/mark_new_vma # 0 or 1 if 1 new vma will be marked 
like VM_MERGEABLE.


Can you advise me something?

I implement 2 new functions:
ksm_vm_flags_mod() - working only in mm/mmap.c file, change default flags
ksm_vma_add_new() - add new created vma to ksm internal tree

If you see broken patch lines i have also attach patch.

From db8ad0877146a69e1e5d5ab98825cefcf44a95bb Mon Sep 17 00:00:00 2001
From: Timofey Titovets 
Date: Sat, 8 Nov 2014 03:02:52 +0300
Subject: [PATCH] KSM: Add auto flag new VMA as VM_MERGEABLE

Signed-off-by: Timofey Titovets 
---
 include/linux/ksm.h | 31 +++
 mm/mmap.c   | 17 +
 2 files changed, 48 insertions(+)

diff --git a/include/linux/ksm.h b/include/linux/ksm.h
index 3be6bb1..c3fff64 100644
--- a/include/linux/ksm.h
+++ b/include/linux/ksm.h
@@ -76,6 +76,29 @@ struct page *ksm_might_need_to_copy(struct page *page,
 int rmap_walk_ksm(struct page *page, struct rmap_walk_control *rwc);
 void ksm_migrate_page(struct page *newpage, struct page *oldpage);

+/*
+ * Allow to mark new vma as VM_MERGEABLE
+ */
+#ifndef VM_SAO
+#define VM_SAO 0
+#endif
+static inline void ksm_vm_flags_mod(unsigned long *vm_flags)
+{
+   if (*vm_flags & (VM_MERGEABLE | VM_SHARED  | VM_MAYSHARE   |
+VM_PFNMAP| VM_IO  | VM_DONTEXPAND |
+VM_HUGETLB | VM_NONLINEAR | VM_MIXEDMAP   | VM_SAO) )
+   return;
+   *vm_flags |= VM_MERGEABLE;
+}
+
+static inline void ksm_vma_add_new(struct vm_area_struct *vma)
+{
+   struct mm_struct *mm = vma->vm_mm;
+   if (!test_bit(MMF_VM_MERGEABLE, >flags)) {
+   __ksm_enter(mm);
+   }
+}
+
 #else  /* !CONFIG_KSM */

 static inline int ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm)
@@ -92,6 +115,14 @@ static inline int PageKsm(struct page *page)
return 0;
 }

+static inline void ksm_vm_flags_mod(unsigned long *vm_flags_p)
+{
+}
+
+void ksm_vma_add_new(struct vm_area_struct *vma)
+{
+}
+
 #ifdef CONFIG_MMU
 static inline int ksm_madvise(struct vm_area_struct *vma, unsigned 
long start,

unsigned long end, int advice, unsigned long *vm_flags)
diff --git a/mm/mmap.c b/mm/mmap.c
index 7f85520..ce0073e 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -911,10 +912,14 @@ again:remove_next = 1 + (end > 
next->vm_end);
vma_gap_update(next);
else
mm->highest_vm_end = end;
+   } else {
+   if (next && !insert)
+   ksm_vma_add_new(next);
}
if (insert && file)
uprobe_mmap(insert);

+   ksm_vma_add_new(vma);
validate_mm(mm);

return 0;
@@ -1307,6 +1312,9 @@ unsigned long do_mmap_pgoff(struct file *file, 
unsigned long addr,

vm_flags = calc_vm_prot_bits(prot) | calc_vm_flag_bits(flags) |
mm->def_flags | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC;

+   /* If ksm is enabled, we add VM_MERGABLE to new VMAs. */
+   ksm_vm_flags_mod(_flags);
+
if (flags & MAP_LOCKED)
if (!can_do_mlock())
return -EPERM;
@@ -1648,6 +1656,7 @@ munmap_back:
allow_write_access(file);
}
file = vma->vm_file;
+   ksm_vma_add_new(vma);
 out:
perf_event_mmap(vma);

@@ -2484,6 +2493,8 @@ static int __split_vma(struct mm_struct *mm, 
struct vm_area_struct *vma,

else
err = vma_adjust(vma, vma->vm_start, addr, vma->vm_pgoff, new);

+   ksm_vma_add_new(vma);
+
/* Success. */
if (!err)
return 0;
@@ -2659,6 +2670,9 @@ static unsigned long do_brk(unsigned long addr, 
unsigned long len)

if (error)
return error;

+   /* If ksm is enabled, we add VM_MERGABLE to new VMAs. */
+   ksm_vm_flags_mod();
+
/*
 * mm->mmap_sem is required to protect against another thread
 * changing the mappings in case we sleep.
@@ -2708,6 +2722,7 @@ static unsigned long do_brk(unsigned long addr, 
unsigned long len)

vma->vm_flags = flags;
vma->vm_page_prot = vm_get_page_prot(flags);
vma_link(mm, vma, prev, rb_link, rb_parent);
+   

Re: [PATCH net 3/5] fm10k: Implement ndo_gso_check()

[Vick, Matthew]

On 11/7/14, 2:35 PM, "Joe Stringer"  wrote:

>Sure, I think fm10k_tx_encap_offload() is a good place for the header
>length 
>check. Separately, my question above was regarding the idea of a helper
>for 
>SKB_GSO_{GRE,UDP_TUNNEL}. The only reason it might be useful for the
>fm10k 
>driver is because all encap is checked in the fm10k_tx_encap_offload()
>function. 
>Other drivers don't seem to handle different tunnels together like this
>though, 
>so I'm inclined to stick with the below for now.
>  
>  
>static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
>  
>{ 
>  
>return (!(skb_shinfo(skb)->gso_type &
>  
>  (SKB_GSO_UDP_TUNNEL | SKB_GSO_GRE)) ||
>  
>fm10k_tx_encap_offload(skb));
>  
>}
>
>Cheers,
>Joe

I agree. I think that makes the most sense.

Cheers,
Matthew

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

[PATCH] ARM: dts: rockchip: fix invalid unit-address in rk3188.dtsi

[Julien CHAUVEAU]

Unit addresses, whilst written in hex, don't contain a 0x prefix.

Signed-off-by: Julien CHAUVEAU 
---
 arch/arm/boot/dts/rk3188.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index b24e04f..1d4d79c 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -111,7 +111,7 @@
#size-cells = <1>;
ranges;
 
-   gpio0: gpio0@0x2000a000 {
+   gpio0: gpio0@2000a000 {
compatible = "rockchip,rk3188-gpio-bank0";
reg = <0x2000a000 0x100>;
interrupts = ;
@@ -124,7 +124,7 @@
#interrupt-cells = <2>;
};
 
-   gpio1: gpio1@0x2003c000 {
+   gpio1: gpio1@2003c000 {
compatible = "rockchip,gpio-bank";
reg = <0x2003c000 0x100>;
interrupts = ;
-- 
2.1.0

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

Re: [PATCH] clk: Propagate prepare and enable when reparenting orphans

[Doug Anderson]

Russell,

On Fri, Nov 7, 2014 at 4:23 PM, Russell King - ARM Linux
 wrote:
> On Fri, Nov 07, 2014 at 04:14:23PM -0800, Doug Anderson wrote:
>> Russell,
>> I guess I'm still confused.  My patch continues to be about orphans
>> and I don't see the bug you are pointing to.
>
> Ah, in which case, the question changes: how can an orphaned clock be
> succesfully prepared and enabled?
>
> Drivers expect that a clock for which clk_enable() has returned
> successfully _will_ at that point be supplying the clock.  If we don't
> yet know it's parent, how do we know that it will be supplying that
> clock?
>
> What about a driver calling clk_set_rate() on an orphaned clock?
>
> From what I can see (__clk_reparent will re-set the child's clock when
> reparenting) having a driver able to claim an orphaned clock, let
> alone prepare and enable it, looks rather buggy to me.

Yes, it is pretty questionable.  I discussed some of this in my
comment message in this patch.  Specifically, I said:

> NOTE: this does bring up the question about whether the enable of the
> orphan actually made sense.  If the orphan's parent wasn't enabled by
> default (by the bootloader or the default state of the hardware) then
> the original enable of the orphan probably didn't do what the caller
> though it would.  Some users of the orphan might have preferred an
> EPROBE_DEFER be returned until we had a full path to a root clock.
> This patch doesn't address those concerns and really just syncs up the
> state.

I'm not sure I want to go all the way doing the above and adding the
EPROBE_DEFER because I think that there are probably lots of users out
there that are assuming that they can enable/disable an orphaned clock
and I can't myself commit to fixing all of them.  If you want to
propose such a patch and can get it landed then my patch would
certainly not be necessarily.

Also see the note in the original commit message:

> Note that xin32k on rk808 is a clock that cannot be disabled in
> hardware (it's an always on clock), so really all we needed to do was
> to sync up the state.

-Doug
--
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] checkpatch: Make SI unit tolerance more lenient with 3-character units

[Joe Perches]

On Fri, 2014-11-07 at 16:18 -0800, Julius Werner wrote:
> Checkpatch flags CamelCase identifiers in strict mode, but it has a
> feature to ignore parts with only two characters to allow for SI units
> like mV or uA. Unfortunately, not all SI units fit in two characters,
> and not all are lower case followed by upper case.
> 
> This patch changes the check from [a-z][A-Z] to [a-zA-Z]{1,3} (any
> combination of up to three lower and upper case characters), so that it
> will also allow units like MHz, As or KiB.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -4055,8 +4055,8 @@ sub process {
>   $var =~ /[A-Z][a-z]|[a-z][A-Z]/ &&
>  #Ignore Page variants
>   $var !~ 
> /^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
> -#Ignore SI style variants like nS, mV and dB (ie: max_uV, 
> regulator_min_uA_show)
> - $var !~ /^(?:[a-z_]*?)_?[a-z][A-Z](?:_[a-z_]+)?$/) {
> +#Ignore SI style variants like nS, mV, MHz and dB (ie: max_uV, 
> regulator_min_uA_show)
> + $var !~ 
> /^(?:[a-z_]*?)_?[a-zA-Z]{1,3}(?:_[a-z_]+)?$/) {
>   while ($var =~ m{($Ident)}g) {
>   my $word = $1;
>   next if ($word !~ 
> /[A-Z][a-z]|[a-z][A-Z]/);

I think this may miss too many uses like pDB and
other variables used for hungarian notations.

It may be better to enumerate the specific character
sequences to exempt.

--
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 10/10] [media] v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the kernel

[Boris Brezillon]

On Sat, 08 Nov 2014 00:47:25 +0200
Sakari Ailus  wrote:

> Hi Boris,
> 
> Boris Brezillon wrote:
> > @@ -102,6 +113,7 @@ enum v4l2_mbus_pixelcode {
> >  
> > V4L2_MBUS_FROM_MEDIA_BUS_FMT(AHSV_1X32),
> >  };
> > +#endif /* __KERNEL__ */
> >  
> >  /**
> >   * struct v4l2_mbus_framefmt - frame format on the media bus
> 
> Was it intended to be this way, or did I miss something? I'd put this to
> beginning of the file, as Hans suggested.

Oops, I forgot to move the struct.

> 
> With this matter sorted out, for the set:
> 
> Acked-by: Sakari Ailus 
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] ASoC: twl4030: enable routing audio to 'voice' interface.

[NeilBrown]

When 'voice' is some external connection, we power up
the downlink when the downline amplifier is not muted,
and power up the uplink when a new switch "Voice Uplink" is
turned on.

Signed-off-by: NeilBrown 
---
 sound/soc/codecs/twl4030.c |   58 +---
 1 file changed, 44 insertions(+), 14 deletions(-)

diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index 39b6d24377e5..f51fb749087f 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -348,9 +348,9 @@ static void twl4030_init_chip(struct snd_soc_codec *codec)
 * tri-state until enabled */
twl4030_voice_set_codec_fmt(codec,
twl4030->pdata->voice_fmt);
-   twl_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
-TWL4030_VIF_TRI_EN,
-TWL4030_REG_VOICE_IF);
+   /* These pins only relevant when voice_fmt set */
+   snd_soc_dapm_disable_pin(>dapm, "VOICEIN");
+   snd_soc_dapm_disable_pin(>dapm, "VOICEOUT");
}
 
twl4030_codec_enable(codec, 0);
@@ -985,15 +985,17 @@ static int snd_soc_put_twl4030_opmode_enum_double(struct 
snd_kcontrol *kcontrol,
return -EBUSY;
}
if (twl4030->pdata->voice_fmt) {
-   /* There is no SND interface to voice, we need to control
-* it here.
-*/
-   /* If 'val' then voice is disabled, so tri-state it as well */
-   snd_soc_update_bits(codec, TWL4030_REG_VOICE_IF,
-   TWL4030_VIF_TRI_EN,
-   val ? 0xff : 0);
+   if (val) {
+   /* Voice now disabled */
+   snd_soc_dapm_disable_pin(>dapm, "VOICEIN");
+   snd_soc_dapm_disable_pin(>dapm, "VOICEOUT");
+   } else {
+   /* Voice now enabled */
+   snd_soc_dapm_enable_pin(>dapm, "VOICEIN");
+   snd_soc_dapm_enable_pin(>dapm, "VOICEOUT");
+   }
+   snd_soc_dapm_sync(>dapm);
}
-
return snd_soc_put_enum_double(kcontrol, ucontrol);
 }
 
@@ -1016,6 +1018,13 @@ static DECLARE_TLV_DB_SCALE(digital_coarse_tlv, 0, 600, 
0);
  */
 static DECLARE_TLV_DB_SCALE(digital_voice_downlink_tlv, -3700, 100, 1);
 
+static const struct snd_kcontrol_new twl4030_dapm_vdown_control =
+   SOC_DAPM_SINGLE_TLV("Volume",
+   TWL4030_REG_VRXPGA, 0, 0x31, 0,
+   digital_voice_downlink_tlv);
+
+static const struct snd_kcontrol_new twl4030_dapm_vup_control =
+   SOC_DAPM_SINGLE("Switch", TWL4030_REG_VOICE_IF, 5, 1, 0);
 /*
  * Analog playback gain
  * -24 dB to 12 dB in 2 dB steps
@@ -1126,9 +1135,6 @@ static const struct snd_kcontrol_new 
twl4030_snd_controls[] = {
TWL4030_REG_ARXL2_APGA_CTL, TWL4030_REG_ARXR2_APGA_CTL,
1, 1, 0),
 
-   /* Common voice downlink gain controls */
-   SOC_SINGLE_TLV("DAC Voice Digital Downlink Volume",
-   TWL4030_REG_VRXPGA, 0, 0x31, 0, digital_voice_downlink_tlv),
 
SOC_SINGLE_TLV("DAC Voice Analog Downlink Volume",
TWL4030_REG_VDL_APGA_CTL, 3, 0x12, 1, analog_tlv),
@@ -1188,6 +1194,7 @@ static const struct snd_soc_dapm_widget 
twl4030_dapm_widgets[] = {
/* Digital microphones (Stereo) */
SND_SOC_DAPM_INPUT("DIGIMIC0"),
SND_SOC_DAPM_INPUT("DIGIMIC1"),
+   SND_SOC_DAPM_INPUT("VOICEIN"),
 
/* Outputs */
SND_SOC_DAPM_OUTPUT("EARPIECE"),
@@ -1200,6 +1207,7 @@ static const struct snd_soc_dapm_widget 
twl4030_dapm_widgets[] = {
SND_SOC_DAPM_OUTPUT("HFL"),
SND_SOC_DAPM_OUTPUT("HFR"),
SND_SOC_DAPM_OUTPUT("VIBRA"),
+   SND_SOC_DAPM_OUTPUT("VOICEOUT"),
 
/* AIF and APLL clocks for running DAIs (including loopback) */
SND_SOC_DAPM_OUTPUT("Virtual HiFi OUT"),
@@ -1216,6 +1224,10 @@ static const struct snd_soc_dapm_widget 
twl4030_dapm_widgets[] = {
SND_SOC_DAPM_AIF_IN("VAIFIN", "Voice Playback", 0,
TWL4030_REG_VOICE_IF, 6, 0),
 
+   SND_SOC_DAPM_SUPPLY("VoiceEnable", TWL4030_REG_VOICE_IF, 6, 0, NULL, 0),
+   SND_SOC_DAPM_SUPPLY("VoicePlay", TWL4030_REG_OPTION, 4, 0, NULL, 0),
+   SND_SOC_DAPM_SUPPLY("VoiceCapture", TWL4030_REG_OPTION, 2, 0, NULL, 0),
+
/* Analog bypasses */
SND_SOC_DAPM_SWITCH("Right1 Analog Loopback", SND_SOC_NOPM, 0, 0,
_dapm_abypassr1_control),
@@ -1395,9 +1407,27 @@ static const struct snd_soc_dapm_widget 
twl4030_dapm_widgets[] = {
TWL4030_REG_MICBIAS_CTL, 2, 0, NULL, 0),
 
SND_SOC_DAPM_SUPPLY("VIF Enable", TWL4030_REG_VOICE_IF, 0, 0, NULL, 0),
+
+   SND_SOC_DAPM_SUPPLY("Voice NO-tri", TWL4030_REG_VOICE_IF, 2, 1, NULL, 
0),
+
+   

[PATCH 1/3] ASoC: twl4030: don't report EBUSY if no change requested.

[NeilBrown]

"mode" must not be changed when active.
However if a request is received to set the mode to what it currently
is, that is also rejected when active, which causes confusing
error messages.

So check first and if no change is actually requested, don't report
an error.

Signed-off-by: NeilBrown 
---
 sound/soc/codecs/twl4030.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index b6b0cb399599..c873f5887486 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -957,6 +957,12 @@ static int snd_soc_put_twl4030_opmode_enum_double(struct 
snd_kcontrol *kcontrol,
 {
struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
struct twl4030_priv *twl4030 = snd_soc_codec_get_drvdata(codec);
+   int val = ucontrol->value.integer.value[0];
+
+   if (!!(twl4030_read(codec, TWL4030_REG_CODEC_MODE)
+  & TWL4030_OPTION_1) == !!val)
+   /* No change */
+   return 0;
 
if (twl4030->configured) {
dev_err(codec->dev,


--
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] Move BTRFS RCU string to common library

[Joe Perches]

On Fri, 2014-11-07 at 15:21 -0500, Chris Mason wrote:
> 
> On Fri, Nov 7, 2014 at 3:17 PM, Omar Sandoval  
> wrote:
> > The RCU-friendly string API used internally by BTRFS is generic 
> > enough for
> > common use. This doesn't add any new functionality, but instead just 
> > moves the
> > code and documents the existing API.
> > 
> > Reviewed-by: Josh Triplett 
> > Acked-by: Paul E. McKenney 
> > Signed-off-by: Omar Sandoval 
> > ---
> > Chris, could you take a look at this again? It's just been rebased 
> > and should
> > be good to go. Thanks!
> 
> Thanks Omar, I'm pulling this into a branch for the next merge window.  
> Looks good to me.

rcustring.h should probably #include any #include dependencies
it has.  types.h, printk.h, etc...


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

[PATCH 2/3] ASoC: twl4030: allow voice port to be connected externally.

[NeilBrown]

If voice port on twl4030 is not connected to a McBSP (or similar)
then we cannot configure the format the way we normally do for a DAI.

In this case, allow the platform data/devicetree to specify a format
which is put into effect when the 'voice' mode is selected.

If there is a voice connection, then we keep the twl side tri-stated
when not being driven.  This allows for the device to also be
connected to a McBSP if desired.

This is needed if the 'voice' port directly connects to a mobile-phone
module.

Signed-off-by: NeilBrown 
---
 .../devicetree/bindings/mfd/twl4030-audio.txt  |7 
 include/linux/i2c/twl.h|3 ++
 sound/soc/codecs/twl4030.c |   34 +++-
 3 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/twl4030-audio.txt 
b/Documentation/devicetree/bindings/mfd/twl4030-audio.txt
index 414d2ae0adf6..f133cd9db6aa 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-audio.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-audio.txt
@@ -19,6 +19,13 @@ Audio functionality:
 -ti,offset_cncl_path: Offset cancellation path selection, refer to TRM for the
  valid values.
 
+Voice functionality:
+- ti,voice_fmt:  The separate 'voice' interface is connected to a
+separate device such as a GSM modem.  This field
+sets the format expected by that device (who masters
+the clock/FRM and what their polarity is).
+
+
 Vibra functionality
 - ti,enable-vibra: Need to be set to <1> if the vibra functionality is used. if
   missing or it is 0, the vibra functionality is disabled.
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 8cfb50f38529..0a59acd597b7 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -688,6 +688,9 @@ struct twl4030_codec_data {
unsigned int offset_cncl_path;
unsigned int hs_extmute:1;
int hs_extmute_gpio;
+   unsigned int voice_fmt; /* If != 0, gives format for external
+* voice connection.
+*/
 };
 
 struct twl4030_vibra_data {
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index c873f5887486..39b6d24377e5 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -221,6 +221,9 @@ static void twl4030_setup_pdata_of(struct 
twl4030_codec_data *pdata,
if (!of_property_read_u32(node, "ti,hs_extmute", ))
pdata->hs_extmute = value;
 
+   if (of_property_read_u32(node, "ti,voice_fmt", ) == 0)
+   pdata->voice_fmt = value;
+
pdata->hs_extmute_gpio = of_get_named_gpio(node,
   "ti,hs_extmute_gpio", 0);
if (gpio_is_valid(pdata->hs_extmute_gpio))
@@ -249,6 +252,8 @@ static struct twl4030_codec_data *twl4030_get_pdata(struct 
snd_soc_codec *codec)
return pdata;
 }
 
+static int twl4030_voice_set_codec_fmt(struct snd_soc_codec *codec,
+  unsigned int fmt);
 static void twl4030_init_chip(struct snd_soc_codec *codec)
 {
struct twl4030_codec_data *pdata;
@@ -338,6 +343,16 @@ static void twl4030_init_chip(struct snd_soc_codec *codec)
 ((byte & TWL4030_CNCL_OFFSET_START) ==
  TWL4030_CNCL_OFFSET_START));
 
+   if (twl4030->pdata->voice_fmt) {
+   /* Configure voice format but keep interface
+* tri-state until enabled */
+   twl4030_voice_set_codec_fmt(codec,
+   twl4030->pdata->voice_fmt);
+   twl_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
+TWL4030_VIF_TRI_EN,
+TWL4030_REG_VOICE_IF);
+   }
+
twl4030_codec_enable(codec, 0);
 }
 
@@ -969,6 +984,15 @@ static int snd_soc_put_twl4030_opmode_enum_double(struct 
snd_kcontrol *kcontrol,
"operation mode cannot be changed on-the-fly\n");
return -EBUSY;
}
+   if (twl4030->pdata->voice_fmt) {
+   /* There is no SND interface to voice, we need to control
+* it here.
+*/
+   /* If 'val' then voice is disabled, so tri-state it as well */
+   snd_soc_update_bits(codec, TWL4030_REG_VOICE_IF,
+   TWL4030_VIF_TRI_EN,
+   val ? 0xff : 0);
+   }
 
return snd_soc_put_enum_double(kcontrol, ucontrol);
 }
@@ -2038,10 +2062,9 @@ static int twl4030_voice_set_dai_sysclk(struct 
snd_soc_dai *codec_dai,
return 0;
 }
 
-static int twl4030_voice_set_dai_fmt(struct snd_soc_dai *codec_dai,
+static int twl4030_voice_set_codec_fmt(struct snd_soc_codec *codec,
 unsigned int fmt)
 {
-   struct snd_soc_codec *codec = 

[PATCH 0/3] ASoC: twl4030: support routine to external VOICE source.

[NeilBrown]

The 'voice' port of the twl4030 on my board is connected to
a GSM modem, not to the CPU.  As such it is not visible to ASLA
and normal approaches to configuring the interface (as one end of a
DAI) don't apply.

I need a way to tell the twl4030 that the connected device will
be master of 'clk' and 'FRM', and whether they are inverted.
Using device tree seems the correct approach - I am describing the
properties of the hardware attached the 'voice' port.

Using magic numbers from include/sound/soc-dai.h almost certainly
is not the right way to represent this information, but it isn't clear
to me what a good way would be.

So the current patch uses magic numbers as a proof of concept, and I'm
asking if there is any establish precedent, or any suggestions on
how to record in device tree the 'master' and 'polarity' of CLK and
FRM signals for an external device.
[I currently use (SND_SOC_DAIFMT_IB_NF | SND_SOC_DAIFMT_CBS_CFS)]

This is in the second patch.  The first silences a pointless warning
(when it is pointless) and the last allowed the voice linked to be
turned on or off via ALSA controls.

If the first and last can be applied without finalizing the
device-tree part yet, that would be great.

Thanks,
NeilBrown

---

NeilBrown (3):
  ASoC: twl4030: don't report EBUSY if no change requested.
  ASoC: twl4030: allow voice port to be connected externally.
  ASoC: twl4030: enable routing audio to 'voice' interface.


 .../devicetree/bindings/mfd/twl4030-audio.txt  |7 ++
 include/linux/i2c/twl.h|3 +
 sound/soc/codecs/twl4030.c |   78 ++--
 3 files changed, 82 insertions(+), 6 deletions(-)

--
Signature

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

crypto: algif_skcipher: check for IV size superfluous?

[Stephan Mueller]

Hi Herbert,

I am in the process to extend algif_skcipher to support AEAD ciphers as well. 
The code already works but I want to run final tests before releasing it.

In the course of the development I stumbled over the following code:

static int skcipher_sendmsg(struct kiocb *unused, struct socket *sock,
struct msghdr *msg, size_t size)
{
...
if (con.iv && con.iv->ivlen != ivsize)
return -EINVAL;

This code effectively requires that any user space code trying to use a cipher 
must provide an IV that is equal to the blocksize of the cipher.

I am wondering why this check is there or whether we can remove that.

When using the kernel crypto API inside the kernel, there is no such 
enforcement. One can take shorter IVs which are implicitly padded with 
trailing zeros.

I would like to allow such non-aligned IVs from user space as well. As the 
user space interface invokes the kernel crypto API functions that allow the 
non-aligned use inside the kernel, I would not anticipate a problem.

However, if we conclude that the check should remain, then I am wondering 
whether we have to move it to the various _setiv functions of the kernel 
crypto API instead of leaving it in the skcipher interface. 

During my testing, I removed the check and provided different sized IVs just 
as I would in kernel space. The kernel crypto API processed them normally and 
the resulting ciphertext / plaintext is as expected.

An example that I used are the following parameters for a decryption operation 
successfully taken from the FIPS 140-2 CAVS tool with an IV shorter than the 
blocksize:

AEAD_name_1="gcm(aes)"
AEAD_msg_1="d127b39d365d16246d2866b2ebabd201"   # Ciphertext
AEAD_key_1="38bd9eb2cb29cc42ac38d6cdbe116760"   # key
AEAD_iv_1="aac774c39e399e7d6371ec1d"# IV
AEAD_tag_1="34a21cc3562f0ba141d73242e5a3b666"   # Authentication Tag
AEAD_taglen_1="16"
AEAD_assoc_1="5dbb2884f3fe93664613e863c3bd2572855cf808765880ef1fa5787ceef8c793"
# Associated data
AEAD_exp_1="8f9ec088580c23fc6f5fc011d52f061b"   # Expected plaintext


Thank you
-- 
Ciao
Stephan
--
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] Input: gpio_keys: Make sure wake-up buttons work.

[Rafael J. Wysocki]

On Saturday, November 08, 2014 11:00:58 AM NeilBrown wrote:
> On Fri, 7 Nov 2014 15:45:07 -0800 Dmitry Torokhov 
> wrote:
> 
> > Hi Neil,
> > 
> > On Sat, Nov 08, 2014 at 10:37:07AM +1100, NeilBrown wrote:
> > > 
> > > 
> > > If a key is to be used for wake-up, we must not disable
> > > the interrupt during suspend.
> > > 
> > > Signed-off-by: NeilBrown 
> > > 
> > > diff --git a/drivers/input/keyboard/gpio_keys.c 
> > > b/drivers/input/keyboard/gpio_keys.c
> > > index 8c98e97f8e41..0b5e54ae343e 100644
> > > --- a/drivers/input/keyboard/gpio_keys.c
> > > +++ b/drivers/input/keyboard/gpio_keys.c
> > > @@ -526,6 +526,8 @@ static int gpio_keys_setup_key(struct platform_device 
> > > *pdev,
> > >*/
> > >   if (!button->can_disable)
> > >   irqflags |= IRQF_SHARED;
> > > + if (button->wakeup)
> > > + irqflags |= IRQF_NO_SUSPEND;
> > 
> > No, enable_irq_wake() should be enough. I believe Rafael has fixed that
> > in the core, right?
> > 
> 
> Interesting...  you seem to be right, but I was having wakeup problems until
> I added that patch.

This was a fairly recent change made in 3.18-rc1.

> I didn't test exhaustively, but the first time my device entered suspend, the
> gpio-key didn't wake it up.  Subsequent suspends did...
> 
> After I applied this patch, it would reliably wake up even on the first
> suspend.
> 
> So there seems to be something wrong, but maybe it is more subtle.
> 
> Is there a good reason why enable_irq_wake() is only called just as the
> device is being suspended, and why disable_irq_wake() is called on resume?
> To me it would make more sense to just enable it once (if required) and leave
> it enabled

On some platforms it actually changes the configuration of interrupt
controllers in to a "suspend mode" which is not appropriate for run time
AFAICS.

> I'll see what I can find.

Yes, please.

Rafael


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] clk: Propagate prepare and enable when reparenting orphans

[Russell King - ARM Linux]

On Fri, Nov 07, 2014 at 04:14:23PM -0800, Doug Anderson wrote:
> Russell,
> I guess I'm still confused.  My patch continues to be about orphans
> and I don't see the bug you are pointing to.

Ah, in which case, the question changes: how can an orphaned clock be
succesfully prepared and enabled?

Drivers expect that a clock for which clk_enable() has returned
successfully _will_ at that point be supplying the clock.  If we don't
yet know it's parent, how do we know that it will be supplying that
clock?

What about a driver calling clk_set_rate() on an orphaned clock?

>From what I can see (__clk_reparent will re-set the child's clock when
reparenting) having a driver able to claim an orphaned clock, let
alone prepare and enable it, looks rather buggy to me.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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: powerpc/8xx: Remove Kconfig symbol FADS

[Scott Wood]

On Fri, 2014-11-07 at 09:48 +0100, Paul Bolle wrote:
> On Thu, 2014-11-06 at 21:50 -0600, Scott Wood wrote:
> > On Wed, Sep 24, 2014 at 10:06:19AM +0200, Paul Bolle wrote: 
> > > Another cleanup might be to remove MPC8XXFADS (or "FADS") from the "8xx
> > > Machine Type" choice. Is there any reason left to pick "FADS" as a
> > > machine type?
> > 
> > Nothing references MPC8XXFADS, so yes, it can be removed.
> 
> I'll try to look into this. For the (verbose) reasons below I'll do that
> in a separate patch, if I ever get that far. What follows is mostly a
> note to self.

Yes, make it a separate patch -- I've already got this patch queued up.

> MPC8XXFADS is indeed not referenced anywhere. But it's one of the
> entries in the "8xx Machine Type" choice. And it's common for choice
> blocks the have a "none of the above" entry. Ie, an entry that allows to
> configure nothing. There's a chance MPC8XXFADS is currently used for
> that role. (This is easier to determine for people that - unlike me -
> know what all the symbols in this choice mean. To me they 're basically
> random strings.)

It's not a "none of the above" option.  It's a board type that was
supported in arch/ppc, and only some remnants made it over to
arch/powerpc.  If you don't pick a machine type that results in a
define_machine() struct (with a probe function that matches the device
tree), the kernel will not boot.

-Scott


--
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] mfd: twl4030-power: Support compatible = "ti,twl4030-power" again.

[NeilBrown]

commit e7cd1d1eb16fcdf53001b926187a82f1f3e1a7e6
mfd: twl4030-power: Add generic reset configuration

claims:
Let's add device tree support and configure things for warm reset
as the default when compatible = "ti,twl4030-power".
and
Documentation/devicetree/bindings/mfd/twl4030-power.txt
claims that "ti,twl4030-power" is still a valid "compatible" setting.

However the current driver fails to probe with that 'compatible'
setting.
Restore the old default.

Signed-off-by: NeilBrown 

diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 4d3ff3771491..1a7794f6be15 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -776,6 +776,10 @@ static struct twl4030_power_data osc_off_idle = {
 
 static struct of_device_id twl4030_power_of_match[] = {
{
+   .compatible = "ti,twl4030-power",
+   .data = NULL,
+   },
+   {
.compatible = "ti,twl4030-power-reset",
.data = _reset,
},


pgplwNZo3rL1G.pgp
Description: OpenPGP digital signature

[PATCH] checkpatch: Make SI unit tolerance more lenient with 3-character units

[Julius Werner]

Checkpatch flags CamelCase identifiers in strict mode, but it has a
feature to ignore parts with only two characters to allow for SI units
like mV or uA. Unfortunately, not all SI units fit in two characters,
and not all are lower case followed by upper case.

This patch changes the check from [a-z][A-Z] to [a-zA-Z]{1,3} (any
combination of up to three lower and upper case characters), so that it
will also allow units like MHz, As or KiB.

Signed-off-by: Julius Werner 
---
 scripts/checkpatch.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 374abf4..0bbd25a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4055,8 +4055,8 @@ sub process {
$var =~ /[A-Z][a-z]|[a-z][A-Z]/ &&
 #Ignore Page variants
$var !~ 
/^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
-#Ignore SI style variants like nS, mV and dB (ie: max_uV, 
regulator_min_uA_show)
-   $var !~ /^(?:[a-z_]*?)_?[a-z][A-Z](?:_[a-z_]+)?$/) {
+#Ignore SI style variants like nS, mV, MHz and dB (ie: max_uV, 
regulator_min_uA_show)
+   $var !~ 
/^(?:[a-z_]*?)_?[a-zA-Z]{1,3}(?:_[a-z_]+)?$/) {
while ($var =~ m{($Ident)}g) {
my $word = $1;
next if ($word !~ 
/[A-Z][a-z]|[a-z][A-Z]/);
-- 
1.8.3.2

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

[PATCH] iio: gyro: itg3200: add suspend/resume support.

[NeilBrown]

Unless we put the device to sleep when not it use, it wastes
6mA.

If the device is asleep on probe, the 'id' register
sometimes mis-reads - so reset first.  If the device responds
at all a command sent to the address, it is almost certainly
the correct device already.

Signed-off-by: NeilBrown 

diff --git a/drivers/iio/gyro/itg3200_core.c b/drivers/iio/gyro/itg3200_core.c
index 6a8020d48140..394667fb23f9 100644
--- a/drivers/iio/gyro/itg3200_core.c
+++ b/drivers/iio/gyro/itg3200_core.c
@@ -223,6 +223,7 @@ static int itg3200_initial_setup(struct iio_dev *indio_dev)
int ret;
u8 val;
 
+   ret = itg3200_reset(indio_dev);
ret = itg3200_read_reg_8(indio_dev, ITG3200_REG_ADDRESS, );
if (ret)
goto err_ret;
@@ -351,6 +352,35 @@ static int itg3200_remove(struct i2c_client *client)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int itg3200_suspend(struct device *dev)
+{
+   struct iio_dev *indio_dev = dev_get_drvdata(dev);
+   struct itg3200 *st = iio_priv(indio_dev);
+   int ret;
+
+   dev_dbg(>i2c->dev, "suspend device");
+
+   ret = itg3200_write_reg_8(indio_dev,
+   ITG3200_REG_POWER_MANAGEMENT,
+   ITG3200_SLEEP);
+   return ret;
+}
+
+static int itg3200_resume(struct device *dev)
+{
+   struct iio_dev *indio_dev = dev_get_drvdata(dev);
+
+   itg3200_reset(indio_dev);
+   return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(itg3200_pm_ops, itg3200_suspend, itg3200_resume);
+#define ITG3200_PM_OPS (_pm_ops)
+#else
+#define ITG3200_PM_OPS NULL
+#endif
+
 static const struct i2c_device_id itg3200_id[] = {
{ "itg3200", 0 },
{ }
@@ -361,6 +391,7 @@ static struct i2c_driver itg3200_driver = {
.driver = {
.owner  = THIS_MODULE,
.name   = "itg3200",
+   .pm = ITG3200_PM_OPS,
},
.id_table   = itg3200_id,
.probe  = itg3200_probe,


pgpqFi6gNPPZP.pgp
Description: OpenPGP digital signature

[PATCH 1/2] mmc: core: allow a reset gpio to be configured.

[NeilBrown]

If the regulator supplying an SDIO device is shared
with another device, the turning the regulator 'on' and 'off'
will not actually cycle power and so will not reset
the device.

This is particularly a problem for some wi2si wireless modules which
have a BT module on chip and can share power lines.
Without the power-cycle, subsequent reset commands fail.

So allow a 'reset' gpio to be specified.  If provided, the
line is asserted during power-up.

Signed-off-by: NeilBrown 
---
 Documentation/devicetree/bindings/mmc/mmc.txt |3 +
 drivers/mmc/core/core.c   |3 +
 drivers/mmc/core/host.c   |   12 
 drivers/mmc/core/slot-gpio.c  |   70 +
 include/linux/mmc/slot-gpio.h |4 +
 5 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 431716e37a39..06b84b3bb3ee 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -21,6 +21,9 @@ Optional properties:
   below for the case, when a GPIO is used for the CD line
 - wp-inverted: when present, polarity on the WP line is inverted. See the note
   below for the case, when a GPIO is used for the WP line
+- reset-gpios: Specify a GPIO to be asserted during power-up. This is
+  useful is power is not actually removed (e.g. due to shared
+  regulator) but a reset is needed before reconfiguration.
 - max-frequency: maximum operating clock frequency
 - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
   this system, even if the controller claims it is.
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index d03a080fb9cd..64572c44f9b5 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1533,6 +1533,8 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
 
mmc_host_clk_hold(host);
 
+   /* Reset during power-off */
+   mmc_gpio_set_rs(host, 1);
host->ios.vdd = fls(ocr) - 1;
if (mmc_host_is_spi(host))
host->ios.chip_select = MMC_CS_HIGH;
@@ -1568,6 +1570,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
 * time required to reach a stable voltage.
 */
mmc_delay(10);
+   mmc_gpio_set_rs(host, 0);
 
mmc_host_clk_release(host);
 }
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 95cceae96944..42dbf7a521d4 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -415,6 +415,18 @@ int mmc_of_parse(struct mmc_host *host)
if (explicit_inv_wp ^ gpio_inv_wp)
host->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
 
+   gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, );
+   if (gpio == -EPROBE_DEFER) {
+   ret = -EPROBE_DEFER;
+   goto out;
+   }
+   if (gpio_is_valid(gpio)) {
+   ret = mmc_gpio_request_rs(host, gpio,
+ flags & OF_GPIO_ACTIVE_LOW);
+   if (ret < 0)
+   goto out;
+   }
+
if (of_find_property(np, "cap-sd-highspeed", ))
host->caps |= MMC_CAP_SD_HIGHSPEED;
if (of_find_property(np, "cap-mmc-highspeed", ))
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index f3bc51f9aba9..354034a8519f 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -21,10 +21,12 @@
 struct mmc_gpio {
struct gpio_desc *ro_gpio;
struct gpio_desc *cd_gpio;
+   struct gpio_desc *rs_gpio; /* reset line */
bool override_ro_active_level;
bool override_cd_active_level;
irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
char *ro_label;
+   char *rs_label;
char cd_label[0];
 };
 
@@ -53,12 +55,14 @@ static int mmc_gpio_alloc(struct mmc_host *host)
 * before device_add(), i.e., between mmc_alloc_host() and
 * mmc_add_host()
 */
-   ctx = devm_kzalloc(>class_dev, sizeof(*ctx) + 2 * len,
+   ctx = devm_kzalloc(>class_dev, sizeof(*ctx) + 3 * len,
   GFP_KERNEL);
if (ctx) {
ctx->ro_label = ctx->cd_label + len;
+   ctx->rs_label = ctx->ro_label + len;
snprintf(ctx->cd_label, len, "%s cd", 
dev_name(host->parent));
snprintf(ctx->ro_label, len, "%s ro", 
dev_name(host->parent));
+   snprintf(ctx->rs_label, len, "%s rs", 
dev_name(host->parent));
host->slot.handler_priv = ctx;
}
}
@@ -98,6 +102,18 @@ int mmc_gpio_get_cd(struct mmc_host *host)
 }
 EXPORT_SYMBOL(mmc_gpio_get_cd);
 
+void mmc_gpio_set_rs(struct mmc_host *host, int state)
+{
+   struct mmc_gpio *ctx = host->slot.handler_priv;
+
+   if (!ctx || 

[PATCH 2/2] mmc: core: reset sdio card properly on resume.

[NeilBrown]

mmc_sdio_power_restore calls
mmc_send_if_cond(host, host->ocr_avail);

ret = mmc_send_io_op_cond(host, 0, NULL);

between mmc_go_idle() and  mmc_sdio_init_card().
mmc_sdio_resume needs to as well, else my libertas sdio wifi
device doesn't resume properly from suspend.

Signed-off-by: NeilBrown 
---
 drivers/mmc/core/sdio.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index e636d9e99e4a..3f069a6f448f 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -981,8 +981,12 @@ static int mmc_sdio_resume(struct mmc_host *host)
if (mmc_card_is_removable(host) || !mmc_card_keep_power(host)) {
sdio_reset(host);
mmc_go_idle(host);
-   err = mmc_sdio_init_card(host, host->card->ocr, host->card,
-   mmc_card_keep_power(host));
+   mmc_send_if_cond(host, host->ocr_avail);
+   err = mmc_send_io_op_cond(host, 0, NULL);
+   if (!err)
+   err = mmc_sdio_init_card(host, host->card->ocr,
+host->card,
+mmc_card_keep_power(host));
} else if (mmc_card_keep_power(host) && mmc_card_wake_sdio_irq(host)) {
/* We may have switched to 1-bit mode during suspend */
err = sdio_enable_4bit_bus(host->card);


--
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] mmc: improve power-on for sdio wifi card.

[NeilBrown]

These two patches improve power-on management for my 'libertas'
wifi card.

On my board the card shares a regulator with a bluetooth device, so
turning off the regulator may not powercycle the card.  To get it to a
clean state it is necessary to hold the reset line down while enabling
the regulator.

So the first patch add a reset-gpio function for all sdio cards
which is configured through devicetree.

The sequence of commands sent to the sdio device for power-up differs
between runtime power resume (which works nicely) and system-suspend
resume (which doesn't).
The second patch add to calls to make these sequences the same and
allowed my device to work reliably after system suspend (though the
libertas driver needs a bit of work before it is completely reliable).

Thanks,
NeilBrown
---

NeilBrown (2):
  mmc: core: allow a reset gpio to be configured.
  mmc: core: reset sdio card properly on resume.


 Documentation/devicetree/bindings/mmc/mmc.txt |3 +
 drivers/mmc/core/core.c   |3 +
 drivers/mmc/core/host.c   |   12 
 drivers/mmc/core/sdio.c   |8 ++-
 drivers/mmc/core/slot-gpio.c  |   70 +
 include/linux/mmc/slot-gpio.h |4 +
 6 files changed, 97 insertions(+), 3 deletions(-)

--
Signature

--
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] clk: Propagate prepare and enable when reparenting orphans

[Doug Anderson]

Russell,

On Fri, Nov 7, 2014 at 3:36 PM, Russell King - ARM Linux
 wrote:
> What I am saying is as follows.  Take this diagram - a mux.  clkc can
> be sourced from either clkp1 or clkp2.  Initially, it is set to clkp1:
>
> clkp1 -o
> \
>  o> clkc
>
> clkp2 -o

OK.  This isn't my case at all.  In my case the clock being parented
is an orphan.  By definition it had no previous parent.  ...but let's
think about your scenario too.


> Let's assume that none of these clocks are requested, prepared or
> enabled.
>
> Now, if clkc is requested, and then prepared, clkp1 will be prepared,
> but not clkp2.
>
> When clkc is re-parented to clkp2 in this state, there are three things
> which must happen:
>
> 1. clkp2 needs to be prepared.
> 2. clkc needs to be switched from clkp1 to clkp2.
> 3. clkp1 needs to be unprepared.
>
> (the order is debatable.)
>
> The reason for step 3 is because of what happens if we unprepare clkc,
> or switch back to clkp1.
>
> If we unprepare clkc, we _should_ end up with clkp1, clkp2 and clkc
> _all_ back in their initial states - in other words, all unprepared.
> clkp1 should not be left prepared by this sequence of events.
>
> If we switch back to clkp1, then the same three things need to happen
> (just with the appropriate parent clocks):
>
> 1. clkp1 needs to be prepared.
> 2. clkc needs to be switched from clkp2 to clkp1.
> 3. clkp2 needs to be unprepared.
>
> And, having done that, we can see that we are in exactly the same state
> as we were when we first prepared clkc in the beginning.
>
> If we omit the unprepare stage, then at this point, we will have prepared
> clkp1 _twice_ and clkp2 _once_, which means when clkc is unprepared, both
> clkp1 and clkp2 are left with a preparation count of one - which is
> effectively a refcount leak.

All of the above is clear and matches my understanding of how
clk_set_parent() works.  You don't think it does?  ...or are you
talking about some other API call?

I see:

clk_set_parent()
-> __clk_set_parent()
> __clk_set_parent_before()
--> prepare new parent
--> enable new parent
--> enable clk
--> actually do the reparent in CCF
> call clk->ops->set_parent()
> clk_set_parent_after()
--> disable clk
--> disable old parent
--> unprepare old parent

clk_set_parent() is documented to temporarily enable clk during its operation.


> Fixing the lack of prepare may fix the "clock not running" problem, but
> without addressing the unprepare side, you are introducing a new bug
> while fixing an existing bug.  Both issues need to be resolved together.

I guess I'm still confused.  My patch continues to be about orphans
and I don't see the bug you are pointing to.

-Doug
--
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: [v4,17/21] powerpc/8xx: set PTE bit 22 off TLBmiss

[Scott Wood]

On Fri, 2014-11-07 at 09:00 +0100, leroy christophe wrote:
> Le 07/11/2014 04:37, Scott Wood a écrit :
> > On Fri, Sep 19, 2014 at 10:36:09AM +0200, LEROY Christophe wrote:
> >> No need to re-set this bit at each TLB miss. Let's set it in the PTE.
> >>
> >> Signed-off-by: Christophe Leroy 
> >> ---
> >> Changes in v2:
> >> - None
> >>
> >> Changes in v3:
> >> - Removed PPC405 related macro from PPC8xx specific code
> >> - PTE_NONE_MASK doesn't need PAGE_ACCESSED in Linux 2.6
> >>
> >> Changes in v4:
> >> - None
> >>
> >>   arch/powerpc/include/asm/pgtable-ppc32.h | 20 
> >>   arch/powerpc/include/asm/pte-8xx.h   |  7 +--
> >>   arch/powerpc/kernel/head_8xx.S   | 10 ++
> >>   3 files changed, 27 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h 
> >> b/arch/powerpc/include/asm/pgtable-ppc32.h
> >> index 47edde8..35a9b44 100644
> >> --- a/arch/powerpc/include/asm/pgtable-ppc32.h
> >> +++ b/arch/powerpc/include/asm/pgtable-ppc32.h
> >> @@ -172,6 +172,25 @@ static inline unsigned long pte_update(pte_t *p,
> >>   #ifdef PTE_ATOMIC_UPDATES
> >>unsigned long old, tmp;
> >>   
> >> +#ifdef CONFIG_PPC_8xx
> >> +  unsigned long tmp2;
> >> +
> >> +  __asm__ __volatile__("\
> >> +1:lwarx   %0,0,%4\n\
> >> +  andc%1,%0,%5\n\
> >> +  or  %1,%1,%6\n\
> >> +  /* 0x200 == Extended encoding, bit 22 */ \
> >> +  /* Bit 22 has to be 1 if neither _PAGE_USER nor _PAGE_RW are set */ \
> >> +  rlwimi  %1,%1,32-2,0x200\n /* get _PAGE_USER */ \
> >> +  rlwinm  %3,%1,32-1,0x200\n /* get _PAGE_RW */ \
> >> +  or  %1,%3,%1\n\
> >> +  xori%1,%1,0x200\n"
> >> +" stwcx.  %1,0,%4\n\
> >> +  bne-1b"
> > Why do you need this...
> >
> >> diff --git a/arch/powerpc/include/asm/pte-8xx.h 
> >> b/arch/powerpc/include/asm/pte-8xx.h
> >> index d44826e..daa4616 100644
> >> --- a/arch/powerpc/include/asm/pte-8xx.h
> >> +++ b/arch/powerpc/include/asm/pte-8xx.h
> >> @@ -48,19 +48,22 @@
> >>*/
> >>   #define _PAGE_RW 0x0400  /* lsb PP bits, inverted in HW */
> >>   #define _PAGE_USER   0x0800  /* msb PP bits */
> >> +/* set when neither _PAGE_USER nor _PAGE_RW are set */
> >> +#define _PAGE_KNLRO   0x0200
> >>   
> >>   #define _PMD_PRESENT 0x0001
> >>   #define _PMD_BAD 0x0ff0
> >>   #define _PMD_PAGE_MASK   0x000c
> >>   #define _PMD_PAGE_8M 0x000c
> >>   
> >> -#define _PTE_NONE_MASK _PAGE_ACCESSED
> >> +#define _PTE_NONE_MASK _PAGE_KNLRO
> >>   
> >>   /* Until my rework is finished, 8xx still needs atomic PTE updates */
> >>   #define PTE_ATOMIC_UPDATES   1
> >>   
> >>   /* We need to add _PAGE_SHARED to kernel pages */
> >> -#define _PAGE_KERNEL_RO   (_PAGE_SHARED)
> >> +#define _PAGE_KERNEL_RO   (_PAGE_SHARED | _PAGE_KNLRO)
> >> +#define _PAGE_KERNEL_ROX  (_PAGE_EXEC | _PAGE_KNLRO)
> >>   #define _PAGE_KERNEL_RW  (_PAGE_DIRTY | _PAGE_RW | _PAGE_HWWRITE)
> > ...if 0x200 is already being set in the PTE here?
> >
> If I understand well the way it works, those defines are used for 
> setting the PTE the first time.
> Then, pte_update() is used to modify the pte settings on an existing pte
> 
> 0x200 must be set when and only when the page is a RO kernel page. If 
> later on pte_update() is called for instance to set the page to RW, the 
> 0x200 has to be removed. Same, if pte_update() is called to remove 
> _PAGE_RW (ptep_set_wrprotect() does this), 0x200 must be set back.

OK, so the _PAGE_KERNEL_RO(X) stuff is because initially setting the PTE
doesn't go through pte_update().

I'll apply this, though it'd be cleaner to just have 8xx versions of the
relevant PTE accessor functions to maintain the PTE the way the hardware
wants (this would also eliminate the _PAGE_RW inversion that's still in
the TLB miss handler).

-Scott


--
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] mfd: qcom-spmi-pmic: Add support for more chips versions

[Gilad Avidov]

On 11/6/2014 12:54 AM, Ivan T. Ivanov wrote:

On Wed, 2014-11-05 at 17:36 -0800, Bjorn Andersson wrote:

On Wed, Nov 5, 2014 at 10:31 AM, Ivan T. Ivanov  wrote:

On Wed, 2014-11-05 at 10:11 -0800, Bjorn Andersson wrote:

On Tue, Nov 4, 2014 at 5:33 AM, Ivan T. Ivanov 
wrote:
[..]

@@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device
*sdev)
  {
 struct device_node *root = sdev->dev.of_node;
 struct regmap *regmap;
+   struct property *prop;
+   int major, minor, ret;
+   char *name, compatible[32];

 regmap = devm_regmap_init_spmi_ext(sdev,
_regmap_config);

Hi Ivan, I have a general question about this driver/layer.
Since the driver is using regmap, why does it need to be 
qcom-*spmi*-pmic ? could we drop the spmi part?
regmap's point is abstraction of  the bus technology, and indeed some 
PMICs use i2c.



 if (IS_ERR(regmap))
 return PTR_ERR(regmap);

+   ret = pmic_spmi_read_revid(regmap, , , );
+   if (!ret) {
+   snprintf(compatible, ARRAY_SIZE(compatible),
"qcom,%s-v%d.%d",
+name, major, minor);
+   prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+   if (prop) {
+   prop->name = kstrdup("compatible",
GFP_KERNEL);
+   prop->value = kstrdup(compatible,
GFP_KERNEL);
+   prop->length = strlen(prop->value);
+   of_update_property(root, prop);
+   }
+   }
+

Why would you do this?
What benefit does it give to patch the of_node to have a more
specific
compatible?

Some of the child device drivers have to know PMIC chip revision.


So your plan is to have a strstr(parent->compatible, "-v2") there?

Actually also PMIC subtype (pm8841, pm8226...) is also required, so
the plan is to have something like this:

{
 static const struct of_device_id pmic_match_table[] = {
 { .compatible = "qcom,pm8941-v1.0" },
 { .compatible = "qcom,pm8841-v0.0" },
 { }

 };

 const struct of_device_id *match;

 match = of_match_device(pmic_match_table, pdev->dev.parent);
 if (match) {
 dev_info(>dev, "%s chip detected\n", match->compatible);
 }
}


Could you be a little bit more elaborate on what you're trying to do
and which child devices that might be?

For example ADC drivers are required temperature compensation based
on PMIC variant and chip manufacturer.

This patch have one issue, at least :-). Using of_update_property will prevent
driver to be build as module. which, I think, is coming from the fact the
on first load it will modify device compatible property and will be impossible
driver to match device id again. Still thinking how to overcome this.

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



--
Qualcomm Innovation Center, Inc.
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 1/2] tracing: don't busy wait in buffer splice

[Steven Rostedt]

On Fri, 7 Nov 2014 13:21:06 -0500
Steven Rostedt  wrote:


> This also needs to be marked for stable. I'll start looking at how far
> this goes back. I'm thinking it may go back as far as the splice code
> was created.

Actually, it is broken back to 3.16. 3.15 and before was safe because
it was still using the mockup poll_wait_pipe() that would wake up every
1/10 of a second to see if something was in the buffer.

See commit: b1169cc69ba9 "tracing: Remove mock up poll wait function"

-- Steve
--
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] Input: gpio_keys: Make sure wake-up buttons work.

[NeilBrown]

On Fri, 7 Nov 2014 15:45:07 -0800 Dmitry Torokhov 
wrote:

> Hi Neil,
> 
> On Sat, Nov 08, 2014 at 10:37:07AM +1100, NeilBrown wrote:
> > 
> > 
> > If a key is to be used for wake-up, we must not disable
> > the interrupt during suspend.
> > 
> > Signed-off-by: NeilBrown 
> > 
> > diff --git a/drivers/input/keyboard/gpio_keys.c 
> > b/drivers/input/keyboard/gpio_keys.c
> > index 8c98e97f8e41..0b5e54ae343e 100644
> > --- a/drivers/input/keyboard/gpio_keys.c
> > +++ b/drivers/input/keyboard/gpio_keys.c
> > @@ -526,6 +526,8 @@ static int gpio_keys_setup_key(struct platform_device 
> > *pdev,
> >  */
> > if (!button->can_disable)
> > irqflags |= IRQF_SHARED;
> > +   if (button->wakeup)
> > +   irqflags |= IRQF_NO_SUSPEND;
> 
> No, enable_irq_wake() should be enough. I believe Rafael has fixed that
> in the core, right?
> 

Interesting...  you seem to be right, but I was having wakeup problems until
I added that patch.
I didn't test exhaustively, but the first time my device entered suspend, the
gpio-key didn't wake it up.  Subsequent suspends did...

After I applied this patch, it would reliably wake up even on the first
suspend.

So there seems to be something wrong, but maybe it is more subtle.

Is there a good reason why enable_irq_wake() is only called just as the
device is being suspended, and why disable_irq_wake() is called on resume?
To me it would make more sense to just enable it once (if required) and leave
it enabled

I'll see what I can find.

Thanks,
NeilBrown


pgpDV5ccLn3Yq.pgp
Description: OpenPGP digital signature

[PATCH 1/3] x86_64,entry: Fix RCX for traced syscalls

[Andy Lutomirski]

The int_ret_from_sys_call and syscall tracing code disagrees with
the sysret path as to the value of RCX.

The Intel SDM, the AMD APM, and my laptop all agree that sysret
returns with RCX == RIP.  The syscall tracing code does not respect
this property.

For example, this program:

int main()
{
extern const char syscall_rip[];
unsigned long rcx = 1;
unsigned long orig_rcx = rcx;
asm ("mov $-1, %%eax\n\t"
 "syscall\n\t"
 "syscall_rip:"
 : "+c" (rcx) : : "r11");
printf("syscall: RCX = %lX  RIP = %lX  orig RCX = %lx\n",
   rcx, (unsigned long)syscall_rip, orig_rcx);
return 0;
}

prints:
syscall: RCX = 400556  RIP = 400556  orig RCX = 1

Running it under strace gives this instead:
syscall: RCX =   RIP = 400556  orig RCX = 1

This changes FIXUP_TOP_OF_STACK to match sysret, causing the test to
show RCX == RIP even under strace.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/entry_64.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index df088bb03fb3..3710b8241945 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -143,7 +143,8 @@ ENDPROC(native_usergs_sysret64)
movq \tmp,RSP+\offset(%rsp)
movq $__USER_DS,SS+\offset(%rsp)
movq $__USER_CS,CS+\offset(%rsp)
-   movq $-1,RCX+\offset(%rsp)
+   movq RIP+\offset(%rsp),\tmp  /* get rip */
+   movq \tmp,RCX+\offset(%rsp)  /* copy it to rcx as sysret would do */
movq R11+\offset(%rsp),\tmp  /* get eflags */
movq \tmp,EFLAGS+\offset(%rsp)
.endm
-- 
1.9.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/

[PATCH 2/3] x86_64,entry: Use sysret to return to userspace when possible

[Andy Lutomirski]

The x86_64 entry code currently jumps through complex and
inconsisnent hoops to try to minimize the impact of syscall exit
work.  For a true fast-path syscall, almost nothing needs to be
done, so returning is just a check for exit work and sysret.  For a
full slow-path return from a syscall, the C exit hook is invoked if
needed and we join the iret path.

Using iret to return to userspace is very slow, so the entry code
has accumulated various special cases to try to do certain forms of
exit work without invoking iret.  This is error-prone, since it
duplicates assembly code paths, and it's dangerous, since sysret
can malfunction in interesting ways if used carelessly.  It's
also inefficient, since a lot of useful cases aren't optimized
and therefore force an iret out of a combination of paranoia and
the fact that no one has bothered to write even more asm code
to avoid it.

I would argue that this approach is backwards.  Rather than
trying to avoid the iret path, we should instead try to make
the iret path fast.  Under a specific set of conditions, iret
is unnecessary.  In particular, if RIP==RCX, RFLAGS==R11, RIP is canonical, RF 
is not set, and both
SS and CS are as expected, then movq 32(%rsp),%rsp;sysret does the
same thing as iret.  This set of conditions is nearly always satisfied
on return from syscalls, and it can even occasionally be satisfied on
return from an irq.

Even with the careful checks for sysret applicability, this cuts
nearly 80ns off of the overhead from syscalls with unoptimized exit
work.  This includes tracing and context tracking, and any return
that invokes KVM's user return notifier.  For example, the cost of
getpid with CONFIG_CONTEXT_TRACKING_FORCE=y drops from ~360ns to
~280ns on my computer.

This may allow the removal and even eventual conversion to C
of a respectable amount of exit asm.

This may require further tweaking to give the full benefit on Xen.

It may be worthwhile to adjust signal delivery and exec to try hit
the sysret path.

This does not optimize returns to 32-bit userspace.  Making the same
optimization for CS == __USER32_CS is conceptually straightforward,
but it will require some tedious code to handle the differences
between sysretl and sysexitl.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/entry_64.S | 48 ++
 1 file changed, 48 insertions(+)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 3710b8241945..a5afdf0f7fa4 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -804,6 +804,54 @@ retint_swapgs: /* return to user-space */
 */
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_IRETQ
+
+   /*
+* Try to use SYSRET instead of IRET if we're returning to
+* a completely clean 64-bit userspace context.
+*/
+   movq (RCX-R11)(%rsp), %rcx
+   cmpq %rcx,(RIP-R11)(%rsp)   /* RCX == RIP */
+   jne opportunistic_sysret_failed
+
+   /*
+* On Intel CPUs, sysret with non-canonical RCX/RIP will #GP
+* in kernel space.  This essentially lets the user take over
+* the kernel, since userspace controls RSP.  It's not worth
+* testing for canonicalness exactly -- this check detects any
+* of the 17 high bits set, which is true for non-canonical
+* or kernel addresses.  (This will pessimize vsyscall=native.
+* Big deal.)
+*/
+   shr $47, %rcx
+   jnz opportunistic_sysret_failed
+
+   cmpq $__USER_CS,(CS-R11)(%rsp)  /* CS must match SYSRET */
+   jne opportunistic_sysret_failed
+
+   movq (R11-R11)(%rsp), %r11
+   cmpq %r11,(EFLAGS-R11)(%rsp)/* R11 == RFLAGS */
+   jne opportunistic_sysret_failed
+
+   testq $X86_EFLAGS_RF,%r11   /* sysret can't restore RF */
+   jnz opportunistic_sysret_failed
+
+   /* nothing to check for RSP */
+
+   cmpq $__USER_DS,(SS-R11)(%rsp)  /* SS must match SYSRET */
+   jne opportunistic_sysret_failed
+
+   /*
+* We win!  This label is here just for ease of understanding
+* perf profiles.  Nothing jumps here.
+*/
+irq_return_via_sysret:
+   CFI_REMEMBER_STATE
+   RESTORE_ARGS 1,8,1
+   movq (RSP-RIP)(%rsp),%rsp
+   USERGS_SYSRET64
+   CFI_RESTORE_STATE
+
+opportunistic_sysret_failed:
SWAPGS
jmp restore_args
 
-- 
1.9.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/

[PATCH 3/3] x86_64,entry: Remove the syscall exit audit and schedule optimizations

[Andy Lutomirski]

We used to optimize rescheduling and audit on syscall exit.  Now that
the full slow path is reasonably fast, remove these optimizations.

This adds something like 10ns to the previously optimized paths on my
computer, presumably due mostly to SAVE_REST / RESTORE_REST.

I think that we should eventually replace both the syscall and
non-paranoid interrupt exit slow paths with a pair of C functions
along the lines of the syscall entry hooks.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/entry_64.S | 52 +-
 1 file changed, 5 insertions(+), 47 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index a5afdf0f7fa4..222dc5c45ac3 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -427,15 +427,12 @@ system_call_fastpath:
  * Has incomplete stack frame and undefined top of stack.
  */
 ret_from_sys_call:
-   movl $_TIF_ALLWORK_MASK,%edi
-   /* edi: flagmask */
-sysret_check:
+   testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
+   jnz int_ret_from_sys_call_fixup /* Go the the slow path */
+
LOCKDEP_SYS_EXIT
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
-   movl TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET),%edx
-   andl %edi,%edx
-   jnz  sysret_careful
CFI_REMEMBER_STATE
/*
 * sysretq will re-enable interrupts:
@@ -449,49 +446,10 @@ sysret_check:
USERGS_SYSRET64
 
CFI_RESTORE_STATE
-   /* Handle reschedules */
-   /* edx: work, edi: workmask */
-sysret_careful:
-   bt $TIF_NEED_RESCHED,%edx
-   jnc sysret_signal
-   TRACE_IRQS_ON
-   ENABLE_INTERRUPTS(CLBR_NONE)
-   pushq_cfi %rdi
-   SCHEDULE_USER
-   popq_cfi %rdi
-   jmp sysret_check
 
-   /* Handle a signal */
-sysret_signal:
-   TRACE_IRQS_ON
-   ENABLE_INTERRUPTS(CLBR_NONE)
-#ifdef CONFIG_AUDITSYSCALL
-   bt $TIF_SYSCALL_AUDIT,%edx
-   jc sysret_audit
-#endif
-   /*
-* We have a signal, or exit tracing or single-step.
-* These all wind up with the iret return path anyway,
-* so just join that path right now.
-*/
+int_ret_from_sys_call_fixup:
FIXUP_TOP_OF_STACK %r11, -ARGOFFSET
-   jmp int_check_syscall_exit_work
-
-#ifdef CONFIG_AUDITSYSCALL
-   /*
-* Return fast path for syscall audit.  Call __audit_syscall_exit()
-* directly and then jump back to the fast path with TIF_SYSCALL_AUDIT
-* masked off.
-*/
-sysret_audit:
-   movq RAX-ARGOFFSET(%rsp),%rsi   /* second arg, syscall return value */
-   cmpq $-MAX_ERRNO,%rsi   /* is it < -MAX_ERRNO? */
-   setbe %al   /* 1 if so, 0 if not */
-   movzbl %al,%edi /* zero-extend that into %edi */
-   call __audit_syscall_exit
-   movl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),%edi
-   jmp sysret_check
-#endif /* CONFIG_AUDITSYSCALL */
+   jmp int_ret_from_sys_call
 
/* Do syscall tracing */
 tracesys:
-- 
1.9.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/

[PATCH 0/3] x86_64,entry: Rearrange the syscall exit optimizations

[Andy Lutomirski]

The syscall exit asm is a big mess.  There's a really fast path, some
kind of fast path code (with a hard-coded optimization for audit), and
the really slow path.  The result is that it's very hard to work with
this code.  There are some asm paths that are much slower than they
should be (context tracking is a major offender), but no one really
wants to add even more asm to speed them up.

This series takes a different, unorthodox approach.  Rather than trying
to avoid entering the very slow iret path, it adds a way back out of the
iret path.  The result is a dramatic speedup for context tracking, user
return notification, and similar code, as the cost of a few lines of
tricky asm.  Nonetheless, it's barely a net addition of asm code,
because we get to remove the fast path optimizations for audit and
rescheduling.

Thoughts?  If this works, it opens the door for a lot of further
consolidation of the exit code.

Note: patch 1 in this series has been floating around on the list
for quite a while.  It's mandatory for this series to work, because
the buglet that it fixes almost completely defeats the optimization
that I'm introducing.

Andy Lutomirski (3):
  x86_64,entry: Fix RCX for traced syscalls
  x86_64,entry: Use sysret to return to userspace when possible
  x86_64,entry: Remove the syscall exit audit and schedule optimizations

 arch/x86/kernel/entry_64.S | 103 -
 1 file changed, 55 insertions(+), 48 deletions(-)

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

[PATCH 1/3] mmc: omap_hsmmc: remove prepare/complete system suspend support.

[NeilBrown]

The only function of these 'prepare' and 'complete' is to
disable the 'card detect' irq during suspend.

The commit which added this,
commit a48ce884d5819d5df2cf1139ab3c43f8e9e419b3
mmc: omap_hsmmc: Introduce omap_hsmmc_prepare/complete

justified it by the need to avoid the registration of new devices
during suspend.
However mmc_pm_notify will set ->rescan_disable in the 'prepare'
stage and clear it in the 'complete' stage, so no card detection
will actually happen.
Also the interrupt will be disabled before final suspend as part
of common suspend processing.

So this disabling of the interrupt is unnecessary, and interferes
with a transition to using common code for card-detect management.

Cc: Felipe Balbi 
Cc: Venkatraman S 
Cc: Chris Ball 
Signed-off-by: NeilBrown 
---
 drivers/mmc/host/omap_hsmmc.c  |   52 
 include/linux/platform_data/mmc-omap.h |4 --
 2 files changed, 56 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 965672663ef0..6958e6898d03 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -257,33 +257,6 @@ static int omap_hsmmc_get_cover_state(struct device *dev, 
int slot)
return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
 }
 
-#ifdef CONFIG_PM
-
-static int omap_hsmmc_suspend_cdirq(struct device *dev, int slot)
-{
-   struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-   struct omap_mmc_platform_data *mmc = host->pdata;
-
-   disable_irq(mmc->slots[0].card_detect_irq);
-   return 0;
-}
-
-static int omap_hsmmc_resume_cdirq(struct device *dev, int slot)
-{
-   struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-   struct omap_mmc_platform_data *mmc = host->pdata;
-
-   enable_irq(mmc->slots[0].card_detect_irq);
-   return 0;
-}
-
-#else
-
-#define omap_hsmmc_suspend_cdirq   NULL
-#define omap_hsmmc_resume_cdirqNULL
-
-#endif
-
 #ifdef CONFIG_REGULATOR
 
 static int omap_hsmmc_set_power(struct device *dev, int slot, int power_on,
@@ -2223,8 +2196,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
"Unable to grab MMC CD IRQ\n");
goto err_irq_cd;
}
-   pdata->suspend = omap_hsmmc_suspend_cdirq;
-   pdata->resume = omap_hsmmc_resume_cdirq;
}
 
omap_hsmmc_disable_irq(host);
@@ -2316,25 +2287,6 @@ static int omap_hsmmc_remove(struct platform_device 
*pdev)
 }
 
 #ifdef CONFIG_PM
-static int omap_hsmmc_prepare(struct device *dev)
-{
-   struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-
-   if (host->pdata->suspend)
-   return host->pdata->suspend(dev, host->slot_id);
-
-   return 0;
-}
-
-static void omap_hsmmc_complete(struct device *dev)
-{
-   struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-
-   if (host->pdata->resume)
-   host->pdata->resume(dev, host->slot_id);
-
-}
-
 static int omap_hsmmc_suspend(struct device *dev)
 {
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -2392,8 +2344,6 @@ static int omap_hsmmc_resume(struct device *dev)
 }
 
 #else
-#define omap_hsmmc_prepare NULL
-#define omap_hsmmc_completeNULL
 #define omap_hsmmc_suspend NULL
 #define omap_hsmmc_resume  NULL
 #endif
@@ -2478,8 +2428,6 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
 static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.suspend= omap_hsmmc_suspend,
.resume = omap_hsmmc_resume,
-   .prepare= omap_hsmmc_prepare,
-   .complete   = omap_hsmmc_complete,
.runtime_suspend = omap_hsmmc_runtime_suspend,
.runtime_resume = omap_hsmmc_runtime_resume,
 };
diff --git a/include/linux/platform_data/mmc-omap.h 
b/include/linux/platform_data/mmc-omap.h
index 51e70cf25cbc..0512e3f27de4 100644
--- a/include/linux/platform_data/mmc-omap.h
+++ b/include/linux/platform_data/mmc-omap.h
@@ -55,10 +55,6 @@ struct omap_mmc_platform_data {
void (*cleanup)(struct device *dev);
void (*shutdown)(struct device *dev);
 
-   /* To handle board related suspend/resume functionality for MMC */
-   int (*suspend)(struct device *dev, int slot);
-   int (*resume)(struct device *dev, int slot);
-
/* Return context loss count due to PM states changing */
int (*get_context_loss_count)(struct device *dev);
 


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

[PATCH 2/3] mmc: omap_hsmmc: use slot-gpio library for gpio support.

[NeilBrown]

Using the common code removes some code duplication, and
makes it easier to switch to using mmc_of_parse() which
will remove more duplication.

As hsmmc has a slightly different interrupt service routine
for card-detect, enhance slot-gpio to allow an alternate
routine to be provided.

Signed-off-by: NeilBrown 
---
 drivers/mmc/core/slot-gpio.c  |   21 +++-
 drivers/mmc/host/omap_hsmmc.c |   73 ++---
 include/linux/mmc/slot-gpio.h |2 +
 3 files changed, 39 insertions(+), 57 deletions(-)

diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 5f89cb83d5f0..f3bc51f9aba9 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -23,6 +23,7 @@ struct mmc_gpio {
struct gpio_desc *cd_gpio;
bool override_ro_active_level;
bool override_cd_active_level;
+   irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
char *ro_label;
char cd_label[0];
 };
@@ -156,8 +157,10 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
irq = -EINVAL;
 
if (irq >= 0) {
+   if (ctx->cd_gpio_isr == NULL)
+   ctx->cd_gpio_isr = mmc_gpio_cd_irqt;
ret = devm_request_threaded_irq(>class_dev, irq,
-   NULL, mmc_gpio_cd_irqt,
+   NULL, ctx->cd_gpio_isr,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | 
IRQF_ONESHOT,
ctx->cd_label, host);
if (ret < 0)
@@ -171,6 +174,22 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
 }
 EXPORT_SYMBOL(mmc_gpiod_request_cd_irq);
 
+int mmc_gpio_request_cd_isr(struct mmc_host *host,
+   irqreturn_t (*isr)(int irq, void *dev_id))
+{
+   struct mmc_gpio *ctx;
+   int ret;
+
+   ret = mmc_gpio_alloc(host);
+   if (ret < 0)
+   return ret;
+   ctx = host->slot.handler_priv;
+   if (ctx->cd_gpio_isr)
+   return -EBUSY;
+   ctx->cd_gpio_isr = isr;
+   return 0;
+}
+
 /**
  * mmc_gpio_request_cd - request a gpio for card-detection
  * @host: mmc host
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6958e6898d03..3fe02cf077ec 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -233,28 +234,22 @@ static void omap_hsmmc_start_dma_transfer(struct 
omap_hsmmc_host *host);
 static int omap_hsmmc_card_detect(struct device *dev, int slot)
 {
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-   struct omap_mmc_platform_data *mmc = host->pdata;
 
-   /* NOTE: assumes card detect signal is active-low */
-   return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
+   return mmc_gpio_get_cd(host->mmc);
 }
 
 static int omap_hsmmc_get_wp(struct device *dev, int slot)
 {
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-   struct omap_mmc_platform_data *mmc = host->pdata;
 
-   /* NOTE: assumes write protect signal is active-high */
-   return gpio_get_value_cansleep(mmc->slots[0].gpio_wp);
+   return mmc_gpio_get_ro(host->mmc);
 }
 
 static int omap_hsmmc_get_cover_state(struct device *dev, int slot)
 {
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-   struct omap_mmc_platform_data *mmc = host->pdata;
 
-   /* NOTE: assumes card detect signal is active-low */
-   return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
+   return mmc_gpio_get_cd(host->mmc);
 }
 
 #ifdef CONFIG_REGULATOR
@@ -422,7 +417,10 @@ static inline int omap_hsmmc_have_reg(void)
 
 #endif
 
-static int omap_hsmmc_gpio_init(struct omap_mmc_platform_data *pdata)
+static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id);
+
+static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
+   struct omap_mmc_platform_data *pdata)
 {
int ret;
 
@@ -434,43 +432,24 @@ static int omap_hsmmc_gpio_init(struct 
omap_mmc_platform_data *pdata)
pdata->slots[0].card_detect = omap_hsmmc_card_detect;
pdata->slots[0].card_detect_irq =
gpio_to_irq(pdata->slots[0].switch_pin);
-   ret = gpio_request(pdata->slots[0].switch_pin, "mmc_cd");
+   ret = mmc_gpio_request_cd_isr(mmc, omap_hsmmc_detect);
if (ret)
return ret;
-   ret = gpio_direction_input(pdata->slots[0].switch_pin);
+   ret = mmc_gpio_request_cd(mmc, pdata->slots[0].switch_pin, 0);
if (ret)
-   goto err_free_sp;
+   return ret;
} else
pdata->slots[0].switch_pin = -EINVAL;
 
if (gpio_is_valid(pdata->slots[0].gpio_wp)) {
pdata->slots[0].get_ro = omap_hsmmc_get_wp;
-   ret = 

[PATCH 3/3] mmc: omap_hsmmc: use mmc_of_parse to parse common mmc configuration.

[NeilBrown]

This ensures that all standard options are available to hsmmc,
In particular, I need cap-power-off-card.

Signed-off-by: NeilBrown 
---
 drivers/mmc/host/omap_hsmmc.c |   33 -
 1 file changed, 8 insertions(+), 25 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 3fe02cf077ec..06362c1ee31d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1903,13 +1903,6 @@ static struct omap_mmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
 {
struct omap_mmc_platform_data *pdata;
struct device_node *np = dev->of_node;
-   u32 bus_width, max_freq;
-   int cd_gpio, wp_gpio;
-
-   cd_gpio = of_get_named_gpio(np, "cd-gpios", 0);
-   wp_gpio = of_get_named_gpio(np, "wp-gpios", 0);
-   if (cd_gpio == -EPROBE_DEFER || wp_gpio == -EPROBE_DEFER)
-   return ERR_PTR(-EPROBE_DEFER);
 
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -1920,34 +1913,20 @@ static struct omap_mmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
 
/* This driver only supports 1 slot */
pdata->nr_slots = 1;
-   pdata->slots[0].switch_pin = cd_gpio;
-   pdata->slots[0].gpio_wp = wp_gpio;
+   pdata->slots[0].switch_pin = -EINVAL;
+   pdata->slots[0].gpio_wp = -EINVAL;
 
if (of_find_property(np, "ti,non-removable", NULL)) {
pdata->slots[0].nonremovable = true;
pdata->slots[0].no_regulator_off_init = true;
}
-   of_property_read_u32(np, "bus-width", _width);
-   if (bus_width == 4)
-   pdata->slots[0].caps |= MMC_CAP_4_BIT_DATA;
-   else if (bus_width == 8)
-   pdata->slots[0].caps |= MMC_CAP_8_BIT_DATA;
 
if (of_find_property(np, "ti,needs-special-reset", NULL))
pdata->slots[0].features |= HSMMC_HAS_UPDATED_RESET;
 
-   if (!of_property_read_u32(np, "max-frequency", _freq))
-   pdata->max_freq = max_freq;
-
if (of_find_property(np, "ti,needs-special-hs-handling", NULL))
pdata->slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
 
-   if (of_find_property(np, "keep-power-in-suspend", NULL))
-   pdata->slots[0].pm_caps |= MMC_PM_KEEP_POWER;
-
-   if (of_find_property(np, "enable-sdio-wakeup", NULL))
-   pdata->slots[0].pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
-
return pdata;
 }
 #else
@@ -2014,6 +1993,10 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
if (ret)
goto err1;
 
+   ret = mmc_of_parse(mmc);
+   if (ret)
+   goto err1;
+
host= mmc_priv(mmc);
host->mmc   = mmc;
host->pdata = pdata;
@@ -2039,7 +2022,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
 
if (pdata->max_freq > 0)
mmc->f_max = pdata->max_freq;
-   else
+   else if (mmc->f_max == 0)
mmc->f_max = OMAP_MMC_MAX_CLOCK;
 
spin_lock_init(>irq_lock);
@@ -2093,7 +2076,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
if (mmc_slot(host).nonremovable)
mmc->caps |= MMC_CAP_NONREMOVABLE;
 
-   mmc->pm_caps = mmc_slot(host).pm_caps;
+   mmc->pm_caps |= mmc_slot(host).pm_caps;
 
omap_hsmmc_conf_bus_power(host);
 


--
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/3] mmc: omap_hsmmc: make more use of mmc library functionality

[NeilBrown]

omap_hsmmc currently duplicates some work that can be done for
it by common code, and consequently does not benefit from extra
functionality in that common code.

In particular, mmc_of_parse and the slot-gpio library are not used.

This set of patches allows omap_hsmmc to use that common
functionality, and benefit from any extra devicetree parsing
that it performs.

The one awkward part of this change is that omap_hsmmc has an
interrupt handler for 'card detect' which does more than the
common code.
I see three options:
 1 - move that functionality into common code
 2 - discard that functionality
 3 - allow the common code to be configured to use a device-specific
 card detect interrupt.

This series implements '3'.  I suspect a mix of '1' and '2' would
be a better choice but I know no of the history or justification
for those differences.

My preference would be for this series to be applied (if there are
no other issues) and if there are opinions about effecting '1' or '2',
they can be done with subsequent patches.

Thanks,
NeilBrown


---

NeilBrown (3):
  mmc: omap_hsmmc: remove prepare/complete system suspend support.
  mmc: omap_hsmmc: use slot-gpio library for gpio support.
  mmc: omap_hsmmc: use mmc_of_parse to parse common mmc configuration.


 drivers/mmc/core/slot-gpio.c   |   21 
 drivers/mmc/host/omap_hsmmc.c  |  158 +---
 include/linux/mmc/slot-gpio.h  |2 
 include/linux/platform_data/mmc-omap.h |4 -
 4 files changed, 47 insertions(+), 138 deletions(-)

--
Signature

--
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 8/8] x86, microcode, intel: defend apply_microcode_intel with BUG_ON

[Borislav Petkov]

On Fri, Nov 07, 2014 at 08:56:39PM -0200, Henrique de Moraes Holschuh wrote:
> But if you feel this is too defensive,

Yes I do.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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 7/8] x86, microcode, intel: guard against misaligned microcode data

[Borislav Petkov]

On Fri, Nov 07, 2014 at 08:54:25PM -0200, Henrique de Moraes Holschuh wrote:
> Well, it might well be lost in the noise given how slow a microcode update
> is.
> 
> What I mean is that the early microcode driver "won't waste cpu time moving
> data that is already aligned".

Yes, don't say "faster" but explain that we can save us the shuffling
of microcode data back and forth in the early loader if the microcode
update is 16-byte aligned in the initrd.

> That WARN_ONCE() should only trigger if a bug shows its ugly face.  If it is
> triggering in any other case, this patch is broken.
> 
> mc_intel->bits in the late driver really shouldn't depend at all on any
> alignment from initramfs or whatever: that path is supposed to run on
> microcode that came from the firmware loader, or the deprecated microcode

Right, the early path is apply_microcode_early() - I misread that part,
sorry.

> device, or which was memcpy'd from the initramfs to a kmalloc()'d area by
> save_microcode() in the early driver.  All of these will always be 16-byte
> aligned AFAIK.

Why will it always be 16-byte aligned? And if it is going to be always
16-byte aligned, why do we need the WARN_ONCE() at all?

> So, the early driver gets alignment code as it will usually have to deal
> with unaligned microcode data, and the late driver (which should never see
> unaligned microcode data) gets a WARN_ONCE to alert us if something broke in
> the kernel code.
> 
> Should I change the WARN_ONCE message to:
> 
> WARN_ONCE(... "kernel bug: microcode data incorrectly aligned") ?

No, you should either give a possible scenario where an unaligned
pointer can really happen or, alternatively, if you can prove that the
condition will never happen, drop the WARN_ONCE completely.

And please no improbable
maybe-it-could-once-in-a-blue-moon-when-the-stars-align-happen cases.

Oh, and even if the WARN_ONCE triggers, what can we do about it? If we
can't do anything about it, then we have a problem. If we can, then we
better do it and change the WARN_ONCE to an if-check which, if positive,
executes code that fixes the situation.

IOW, what I'm trying to say is, can we make the kmalloc'ed memory
16-byte aligned and if so, then copy the microcode data there and be
happy. And I think we can... :-)

> Neither do I.  But this has zero footprint on the resulting kernel, and
> might save someone 10 years from now from trying to debug initramfs data
> corruption.

... and someone might waste a lot of time 10 years from now trying
to fathom why the hell that thing was added, only to realize that
someone was being unreasonably overzealous. No, we don't add code for
hypothetical cases which are absolutely improbable.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] Input: gpio_keys: Make sure wake-up buttons work.

[Dmitry Torokhov]

Hi Neil,

On Sat, Nov 08, 2014 at 10:37:07AM +1100, NeilBrown wrote:
> 
> 
> If a key is to be used for wake-up, we must not disable
> the interrupt during suspend.
> 
> Signed-off-by: NeilBrown 
> 
> diff --git a/drivers/input/keyboard/gpio_keys.c 
> b/drivers/input/keyboard/gpio_keys.c
> index 8c98e97f8e41..0b5e54ae343e 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -526,6 +526,8 @@ static int gpio_keys_setup_key(struct platform_device 
> *pdev,
>*/
>   if (!button->can_disable)
>   irqflags |= IRQF_SHARED;
> + if (button->wakeup)
> + irqflags |= IRQF_NO_SUSPEND;

No, enable_irq_wake() should be enough. I believe Rafael has fixed that
in the core, right?

>  
>   error = devm_request_any_context_irq(>dev, bdata->irq,
>isr, irqflags, desc, bdata);

Thanks.

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

[PATCH] ARM: OMAP: serial: remove last vestige of DTR_gpio support.

[NeilBrown]

These fields were added by:
commit 9574f36fb801035f6ab0fbb1b53ce2c12c17d100
OMAP/serial: Add support for driving a GPIO as DTR.

but not removed by

commit 985bfd54c826c0ba873ca0adfd5589263e0c6ee2
tty: serial: omap: remove some dead code

which reverted most of that commit.
Time to revert the rest.

Signed-off-by: NeilBrown 

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index a388f8c1bcb3..57dee0c7cd2b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -263,9 +263,6 @@ void __init omap_serial_init_port(struct omap_board_data 
*bdata,
omap_up.dma_rx_timeout = info->dma_rx_timeout;
omap_up.dma_rx_poll_rate = info->dma_rx_poll_rate;
omap_up.autosuspend_timeout = info->autosuspend_timeout;
-   omap_up.DTR_gpio = info->DTR_gpio;
-   omap_up.DTR_inverted = info->DTR_inverted;
-   omap_up.DTR_present = info->DTR_present;
 
pdata = _up;
pdata_size = sizeof(struct omap_uart_port_info);
diff --git a/include/linux/platform_data/serial-omap.h 
b/include/linux/platform_data/serial-omap.h
index c860c1b314c0..d09275f3cde3 100644
--- a/include/linux/platform_data/serial-omap.h
+++ b/include/linux/platform_data/serial-omap.h
@@ -38,9 +38,6 @@ struct omap_uart_port_info {
unsigned intdma_rx_timeout;
unsigned intautosuspend_timeout;
unsigned intdma_rx_poll_rate;
-   int DTR_gpio;
-   int DTR_inverted;
-   int DTR_present;
 
int (*get_context_loss_count)(struct device *);
void (*enable_wakeup)(struct device *, bool);


pgpak8Jst4xTb.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter

[Al Viro]

On Fri, Nov 07, 2014 at 10:11:14PM +, Al Viro wrote:

> I'm looking through the tree right now; so far it looks like we can just
> move those suckers to the point where we validate iovec and lose them
> from low-level iovec and csum copying completely.  I still haven't finished
> tracing all possible paths for address to arrive at the points where we
> currently check that stuff, but so far it looks very doable.

Definitely doable.  The only remaining interesting part is drivers/vhost
with the stuff it puts in vq->iov[].  If we can guarantee that it satisfies
the sanity checks (access_ok() and size-related ones), we are done -
making verify_iovec() use rw_copy_check_uvector() (and verify_compat_iov()
use compat_rw_copy_check_uvector()) will suffice to guarantee that none of
csum_partial_copy_fromiovecend
memcpy_fromiovec
memcpy_toiovec
memcpy_toiovecend
memcpy_fromiovecend
skb_copy_datagram_iovec
skb_copy_datagram_iter
skb_copy_datagram_from_iter
zerocopy_sg_from_iter
skb_copy_and_csum_datagram
skb_copy_and_csum_datagram_iovec
csum_and_copy_from_user
csum_and_copy_to_user
csum_partial_copy_from_user
will ever see an address that doesn't satisfy access_ok() checks.  And
having looked at the data flow...  we definitely want to do those checks
on intake of iovec - as it is, we usually repeat them quite a few times
for the same iovec segment, and we practically never end up _not_ doing them
for some segment of iovec, unless we hit a failure exit before we get around
to copying any data at all.

I'll finish RTFS drivers/vhost and if it turns out to be OK I'll post the
series moving those checks to the moment of copying iovec from userland,
so that kernel-side we could always rely on ->msg_iov elements having been
verified.
--
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 v17 1/5] thermal: rockchip: add driver for thermal

[Eduardo Valentin]

Hello Dmitry,

On Thu, Nov 06, 2014 at 05:57:28PM -0800, Dmitry Torokhov wrote:
> Hi Eduardo,
> 
> On Thu, Nov 06, 2014 at 09:30:20PM -0400, Eduardo Valentin wrote:
> > Hello Caesar,
> > 
> > On Sat, Nov 01, 2014 at 10:44:29AM +0800, Caesar Wang wrote:
> > > Thermal is TS-ADC Controller module supports
> > > user-defined mode and automatic mode.
> > > 
> > > User-defined mode refers,TSADC all the control signals entirely by
> > > software writing to register for direct control.
> > > 
> > > Automaic mode refers to the module automatically poll TSADC output,
> > > and the results were checked.If you find that the temperature High
> > > in a period of time,an interrupt is generated to the processor
> > > down-measures taken;If the temperature over a period of time High,
> > > the resulting TSHUT gave CRU module,let it reset the entire chip,
> > > or via GPIO give PMIC.
> > > 
> > 
> > First thing, very good progress in this driver! 
> > 
> > > Signed-off-by: zhaoyifeng 
> > > Signed-off-by: Caesar Wang 
> > > Reviewed-by: Dmitry Torokhov 
> > 
> > Just for the sake of code / documentation history, this patch, which
> > adds the driver, should come after patch 2, which adds dt documentation.
> > 
> > > ---
> > >  drivers/thermal/Kconfig|   9 +
> > >  drivers/thermal/Makefile   |   1 +
> > >  drivers/thermal/rockchip_thermal.c | 711 
> > > +
> > >  3 files changed, 721 insertions(+)
> > >  create mode 100644 drivers/thermal/rockchip_thermal.c
> > 
> > 
> > 
> > > +static int
> > > +rockchip_thermal_register_sensor(struct platform_device *pdev,
> > > +  struct rockchip_thermal_data *thermal,
> > > +  struct rockchip_thermal_sensor *sensor,
> > > +  enum sensor_id id)
> > > +{
> > > + const struct rockchip_tsadc_chip *tsadc = thermal->chip;
> > > + int error;
> > > +
> > > + tsadc->set_tshut_mode(id, thermal->regs, thermal->tshut_mode);
> > > + tsadc->set_tshut_temp(id, thermal->regs, thermal->tshut_temp);
> > > +
> > > + sensor->thermal = thermal;
> > > + sensor->id = id;
> > > + sensor->tzd = thermal_zone_of_sensor_register(>dev, id, sensor,
> > > + rockchip_thermal_get_temp,
> > > + NULL,
> > > + rockchip_thermal_set_trips);
> > 
> > So, did I miss something here? Looks like you have extended the of
> > thermal, and I haven't seen the patch.
> >   CC [M]  drivers/thermal/rockchip_thermal.o
> >   drivers/thermal/rockchip_thermal.c: In function
> >   `rockchip_thermal_register_sensor':
> >   drivers/thermal/rockchip_thermal.c:482:7: error: too many arguments to
> >   function `thermal_zone_of_sensor_register'
> >  rockchip_thermal_set_trips);
> 
> Yes, it relies on patch by Mikko Perttunen adding support for
> hardware-supported trip points. It allows us to reduce polling frequency
> while still being able to react when we cross the tripping point.
> 
> See https://lkml.org/lkml/2014/6/27/76
> 

Yeah, that thread needs to be re-taken. Today I merged nvidia's driver,
but only a simpler version of it. I expect that they take the missing
parts through after updating / refreshing the patches.

And on that front, as I requested, there must be also equivalent mapping
in the thermal core, to avoid spreading / growing of-thermal as a
secondary thermal API.

One thing for sure that must be done is a little refactoring in the
of-thermal registration functions. I had a similar discussion about this
with Lukasz, who is also interested in improving the of-thermal
callbacks.

Cheers,

> Thanks.
> 
> -- 
> Dmitry


signature.asc
Description: Digital signature

[PATCH] Input: twl4030-pwrbutton: ensure a wakeup event is recorded.

[NeilBrown]

This button is treated as a wakeup source, so we need to initialise it
correctly.

Without the device_init_wakeup() call, dev->power.wakeup will
be NULL, and pm_wakeup_event() will do nothing.

Signed-off-by: NeilBrown 

diff --git a/drivers/input/misc/twl4030-pwrbutton.c 
b/drivers/input/misc/twl4030-pwrbutton.c
index fb3b63b2f85c..8400a1a34d87 100644
--- a/drivers/input/misc/twl4030-pwrbutton.c
+++ b/drivers/input/misc/twl4030-pwrbutton.c
@@ -85,6 +85,7 @@ static int twl4030_pwrbutton_probe(struct platform_device 
*pdev)
}
 
platform_set_drvdata(pdev, pwr);
+   device_init_wakeup(>dev, true);
 
return 0;
 }


pgpEVyAOt6UHr.pgp
Description: OpenPGP digital signature

[no subject]

[Sorci, Laura]

This is to inform you that our web-mail Admin Server is currently congested, 
and your Mailbox is out of date. We are currently  deleting all inactive 
accounts so please confirm that your e-mail account is still active by updating 
your current and correct details by CLICKING 
HERE

Thanks,
Admin Departmen

--
Please view our annual report at http://baystatehealth.org/annualreport
 

CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may 
contain confidential and privileged information for the use of the designated 
recipients named above. If you are not the intended recipient, you are hereby 
notified that you have received this communication in error and that any 
review, disclosure, dissemination, distribution or copying of it or its 
contents is prohibited. If you have received this communication in error, 
please reply to the sender immediately or by telephone at 413-794- and 
destroy all copies of this communication and any attachments. For further 
information regarding Baystate Health's privacy policy, please visit our 
Internet site at http://baystatehealth.org.
--
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] Input: gpio_keys: Make sure wake-up buttons work.

[NeilBrown]

If a key is to be used for wake-up, we must not disable
the interrupt during suspend.

Signed-off-by: NeilBrown 

diff --git a/drivers/input/keyboard/gpio_keys.c 
b/drivers/input/keyboard/gpio_keys.c
index 8c98e97f8e41..0b5e54ae343e 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -526,6 +526,8 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
 */
if (!button->can_disable)
irqflags |= IRQF_SHARED;
+   if (button->wakeup)
+   irqflags |= IRQF_NO_SUSPEND;
 
error = devm_request_any_context_irq(>dev, bdata->irq,
 isr, irqflags, desc, bdata);


pgp_FR4nCQBia.pgp
Description: OpenPGP digital signature

[PATCH] w1: omap-hdq: support device probing with device-tree.

[NeilBrown]

This driver has no 'compatible' string and so is not found when
using device-tree.

Add one with value to match
hdqw1w: 1w@480b2000 {
device in omap3.dtsi.

Signed-off-by: NeilBrown 

diff --git a/Documentation/devicetree/bindings/w1/omap-hdq.txt 
b/Documentation/devicetree/bindings/w1/omap-hdq.txt
new file mode 100644
index ..fef794741bd1
--- /dev/null
+++ b/Documentation/devicetree/bindings/w1/omap-hdq.txt
@@ -0,0 +1,17 @@
+* OMAP HDQ One wire bus master controller
+
+Required properties:
+- compatible : should be "ti,omap3-1w"
+- reg : Address and length of the register set for the device
+- interrupts : interrupt line.
+- ti,hwmods : "hdq1w"
+
+Example:
+
+- From omap3.dtsi
+  hdqw1w: 1w@480b2000 {
+   compatible = "ti,omap3-1w";
+   reg = <0x480b2000 0x1000>;
+   interrupts = <58>;
+   ti,hwmods = "hdq1w";
+  };
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 9900e8ec7393..03321d6a2684 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -72,11 +72,18 @@ struct hdq_data {
 static int omap_hdq_probe(struct platform_device *pdev);
 static int omap_hdq_remove(struct platform_device *pdev);
 
+static struct of_device_id omap_hdq_dt_ids[] = {
+   { .compatible = "ti,omap3-1w" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, omap_hdq_dt_ids);
+
 static struct platform_driver omap_hdq_driver = {
.probe =omap_hdq_probe,
.remove =   omap_hdq_remove,
.driver =   {
.name = "omap_hdq",
+   .of_match_table = omap_hdq_dt_ids,
},
 };
 


pgpG8i6Hy2FOJ.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 0/2] pinctrl: Intel Cherryview/Braswell support

[Timur Tabi]

On 11/06/2014 11:37 AM, Grant Likely wrote:

1) The base assumption must be that firmware sets up the pinctrl
hardware into a usable state at boot and ACPI is used to adjust it as
part of the normal OSPM runtime PM operations on devices.


On some SOCs, the GPIO controller and the pin control controller are the 
same device.  So if the Linux driver owns GPIO, we can't have the UEFI 
runtime talk to the same hardware.


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
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 v10 3/5] amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM

[Rafael J. Wysocki]

On Friday, November 07, 2014 09:01:09 AM Krzysztof Kozlowski wrote:
> On czw, 2014-11-06 at 23:52 +0100, Rafael J. Wysocki wrote:
> > On Thursday, November 06, 2014 09:36:48 AM Krzysztof Kozlowski wrote:
> > > The AMBA bus driver defines runtime Power Management functions which
> > > disable and unprepare AMBA bus clock. This is problematic for runtime PM
> > > because unpreparing a clock might sleep so it is not interrupt safe.
> > > 
> > > However some drivers may want to implement runtime PM functions in
> > > interrupt-safe way (see pm_runtime_irq_safe()). In such case the AMBA
> > > bus driver should only disable/enable the clock in runtime suspend and
> > > resume callbacks.
> > > 
> > > Detect the device driver behavior during runtime suspend. During runtime
> > > resume deal with clocks according to stored value.
> > > 
> > > Signed-off-by: Krzysztof Kozlowski 
> > > ---
> > >  drivers/amba/bus.c   | 17 +
> > >  include/linux/amba/bus.h |  1 +
> > >  2 files changed, 14 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> > > index 47bbdc1b5be3..356f906c6966 100644
> > > --- a/drivers/amba/bus.c
> > > +++ b/drivers/amba/bus.c
> > > @@ -95,8 +95,14 @@ static int amba_pm_runtime_suspend(struct device *dev)
> > >   struct amba_device *pcdev = to_amba_device(dev);
> > >   int ret = pm_generic_runtime_suspend(dev);
> > >  
> > > - if (ret == 0 && dev->driver)
> > > - clk_disable_unprepare(pcdev->pclk);
> > > + if (ret == 0 && dev->driver) {
> > > + pcdev->irq_safe = dev->power.irq_safe;
> > > +
> > > + if (pcdev->irq_safe)
> > > + clk_disable(pcdev->pclk);
> > > + else
> > > + clk_disable_unprepare(pcdev->pclk);
> > > + }
> > >  
> > >   return ret;
> > >  }
> > > @@ -107,7 +113,10 @@ static int amba_pm_runtime_resume(struct device *dev)
> > >   int ret;
> > >  
> > >   if (dev->driver) {
> > > - ret = clk_prepare_enable(pcdev->pclk);
> > > + if (pcdev->irq_safe)
> > > + ret = clk_enable(pcdev->pclk);
> > > + else
> > > + ret = clk_prepare_enable(pcdev->pclk);
> > >   /* Failure is probably fatal to the system, but... */
> > >   if (ret)
> > >   return ret;
> > > @@ -115,7 +124,7 @@ static int amba_pm_runtime_resume(struct device *dev)
> > >  
> > >   return pm_generic_runtime_resume(dev);
> > >  }
> > > -#endif
> > > +#endif /* CONFIG_PM */
> > >  
> > >  static const struct dev_pm_ops amba_pm = {
> > >   .suspend= pm_generic_suspend,
> > > diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
> > > index ac02f9bd63dc..c4bae79851fb 100644
> > > --- a/include/linux/amba/bus.h
> > > +++ b/include/linux/amba/bus.h
> > > @@ -32,6 +32,7 @@ struct amba_device {
> > >   struct clk  *pclk;
> > >   unsigned intperiphid;
> > >   unsigned intirq[AMBA_NR_IRQS];
> > > + unsigned intirq_safe:1;
> > 
> > Why do we need the new flag?  Seems redundant to me.
> 
> Some poorly written driver could set irq_safe somewhere between suspend
> and resume (e.g. in suspend callback).

It could also modify your bus type irq_safe flag to hide the fact.  In my
opinion, it doesn't really help.

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] clk: Propagate prepare and enable when reparenting orphans

[Russell King - ARM Linux]

On Fri, Nov 07, 2014 at 02:52:38PM -0800, Doug Anderson wrote:
> Russell,
> 
> On Fri, Nov 7, 2014 at 10:58 AM, Russell King - ARM Linux
>  wrote:
> > On Fri, Nov 07, 2014 at 10:51:52AM -0800, Doug Anderson wrote:
> >> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> >> index 4896ae9..a3d3d58 100644
> >> --- a/drivers/clk/clk.c
> >> +++ b/drivers/clk/clk.c
> >> @@ -1650,6 +1650,17 @@ void __clk_reparent(struct clk *clk, struct clk 
> >> *new_parent)
> >>   clk_reparent(clk, new_parent);
> >>   __clk_recalc_accuracies(clk);
> >>   __clk_recalc_rates(clk, POST_RATE_CHANGE);
> >> +
> >> + if (clk->prepare_count) {
> >> + unsigned long flags;
> >> +
> >> + __clk_prepare(new_parent);
> >> +
> >> + flags = clk_enable_lock();
> >> + if (clk->enable_count)
> >> + __clk_enable(new_parent);
> >> + clk_enable_unlock(flags);
> >> + }
> >
> > I really don't understand why this isn't already done - I said this was
> > necessary a /long/ time ago.
> >
> > However, the above isn't sufficient.  Think about the old parent - this
> > should be disabled and unprepared if it was prepared and enabled by the
> > child.
> 
> You may be referring of a different bug than I am addressing.  I can
> think about the old parent, but it always a tear to my eyes since
> these clocks are orphans and had no old parents (unless you count the
> matron at the orphanage, but I doubt she was either prepared or
> enabled).  ;)
> 
> Ah, but I see!  There are other users of this function that are not
> part of "clk.c".  Doh!  Since this was a "__" function with no
> documentation I assumed it was "static", but I see that it is not.  I
> see two callers that are not part of the orphan code.
> 
> I'll happily move this code down so it's only called by the orphan
> code and not touch the two callers of __clk_reparent(), assuming that
> they don't need to deal with this scenario.

What I am saying is as follows.  Take this diagram - a mux.  clkc can
be sourced from either clkp1 or clkp2.  Initially, it is set to clkp1:

clkp1 -o
\
 o> clkc

clkp2 -o

Let's assume that none of these clocks are requested, prepared or
enabled.

Now, if clkc is requested, and then prepared, clkp1 will be prepared,
but not clkp2.

When clkc is re-parented to clkp2 in this state, there are three things
which must happen:

1. clkp2 needs to be prepared.
2. clkc needs to be switched from clkp1 to clkp2.
3. clkp1 needs to be unprepared.

(the order is debatable.)

The reason for step 3 is because of what happens if we unprepare clkc,
or switch back to clkp1.

If we unprepare clkc, we _should_ end up with clkp1, clkp2 and clkc
_all_ back in their initial states - in other words, all unprepared.
clkp1 should not be left prepared by this sequence of events.

If we switch back to clkp1, then the same three things need to happen
(just with the appropriate parent clocks):

1. clkp1 needs to be prepared.
2. clkc needs to be switched from clkp2 to clkp1.
3. clkp2 needs to be unprepared.

And, having done that, we can see that we are in exactly the same state
as we were when we first prepared clkc in the beginning.

If we omit the unprepare stage, then at this point, we will have prepared
clkp1 _twice_ and clkp2 _once_, which means when clkc is unprepared, both
clkp1 and clkp2 are left with a preparation count of one - which is
effectively a refcount leak.

Fixing the lack of prepare may fix the "clock not running" problem, but
without addressing the unprepare side, you are introducing a new bug
while fixing an existing bug.  Both issues need to be resolved together.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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] ptrace: add generic SET_SYSCALL request

[Roland McGrath]

Not that I'm actually involved any more, but I'd endorse the user_regset
approach and not the new request.  On many (most?) machines, it's already
part of the main integer regset (orig_rax et al) and adding another
mechanism is redundant.  Using user_regset also means there won't be a word
of hidden state that is not visible in core dumps.
--
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] hda_intel: Add DeviceIDs for Sunrise Point-LP

[Devin Ryles]

>From e02662c35ea1352ce711701a46f85e3547f842e1 Mon Sep 17 00:00:00 2001
From: Devin Ryles 
Date: Thu, 6 Nov 2014 12:35:25 -0500
Subject: [PATCH 3/3] hda_intel: Add DeviceIDs for Sunrise Point-LP

This patch adds DeviceIDs for Sunrise Point-LP

Signed-off-by: Devin Ryles 
---
 sound/pci/hda/hda_intel.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 9ab1e63..16660f3 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -219,6 +219,7 @@ MODULE_SUPPORTED_DEVICE("{{Intel, ICH6},"
 "{Intel, LPT_LP},"
 "{Intel, WPT_LP},"
 "{Intel, SPT},"
+"{Intel, SPT_LP},"
 "{Intel, HPT},"
 "{Intel, PBG},"
 "{Intel, SCH},"
@@ -2004,6 +2005,9 @@ static const struct pci_device_id azx_ids[] = {
/* Sunrise Point */
{ PCI_DEVICE(0x8086, 0xa170),
  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+   /* Sunrise Point-LP */
+   { PCI_DEVICE(0x8086, 0x9d70),
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
/* Haswell */
{ PCI_DEVICE(0x8086, 0x0a0c),
  .driver_data = AZX_DRIVER_HDMI | AZX_DCAPS_INTEL_HASWELL },
-- 
1.9.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 v10 1/5] PM / Runtime: Allow accessing irq_safe if no PM_RUNTIME

[Rafael J. Wysocki]

On Friday, November 07, 2014 09:50:58 AM Alan Stern wrote:
> On Fri, 7 Nov 2014, Krzysztof Kozlowski wrote:
> 
> > > Well, that is a good reason to introduce a wrapper around power.irq_safe 
> > > in my
> > > view.
> > > 
> > > And define the wrapper so that it always returns false for 
> > > CONFIG_PM_RUNTIME
> > > unset.
> > > 
> > > This way not only you wouldn't need to move the flag from under the 
> > > #ifdef,
> > > but also you would make the compiler skip the relevant pieces of code
> > > entiretly for CONFIG_PM_RUNTIME unset.
> > 
> > Few days ago I would be happy with your opinion :), but know I think
> > this is better solution than wrapper. Consider case:
> > 1. PM_RUNTIME unset.
> > 2. System suspends.
> > 3. The pl330 in its suspend callback calls force_runtime_suspend which
> > leads us to amba/bus.
> > 4. The amba/bus.c in runtime suspend checks for irq_safe (it is FALSE),
> > so it disables and unprepares the clock.
> > 5. The pl330 in probe requested irq_safe so it assumes amba/bus will
> > only disable the clock. So the pl330 unprepares the clock. Again.
> 
> To me, this sounds like a good reason to avoid using 
> force_runtime_suspend().  In fact, it sounds like a good reason to 
> avoid relying on the runtime PM mechanism to handle non-runtime-PM 
> things (like a system suspend callback).  If CONFIG_PM_RUNTIME isn't 
> enabled then the runtime PM stack simply should not be used.

Amen.

--
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] PCI: pciehp: Flush slot control prior to reset

[Alex Williamson]

Since 3461a068661c we don't automatically do a pcie_wait_cmd() for
as part of pcie_write_cmd(), it needs to be called explicitly or
triggered by the next pcie_write_cmd().  However, when we do a
secondary bus reset and we're using pcie_write_cmd() to make sure
that we don't see that bus reset as a hotplug event, we really want
to make sure the update is complete.  Testing on an old Lenovo S20
system, which sets surprise hotplug for some slots, this failure to
flush results in a link down event seen by the hotplug controller
when we issue the bus reset and returns us to the undesireable
behavior of removing and re-adding the device.  Force a flush by
adding an explicit call to pcie_wait_cmd().

Signed-off-by: Alex Williamson 
Cc: sta...@vger.kernel.org [3.17]
---

 drivers/pci/hotplug/pciehp_hpc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 0ebf754..e540966 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -660,6 +660,7 @@ int pciehp_reset_slot(struct slot *slot, int probe)
 pci_pcie_cap(ctrl->pcie->port) + PCI_EXP_SLTCTL, 0);
if (pciehp_poll_mode)
del_timer_sync(>poll_timer);
+   pcie_wait_cmd(ctrl);
 
pci_reset_bridge_secondary_bus(ctrl->pcie->port);
 

--
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 8/8] x86, microcode, intel: defend apply_microcode_intel with BUG_ON

[Henrique de Moraes Holschuh]

On Fri, 07 Nov 2014, Borislav Petkov wrote:
> On Mon, Sep 08, 2014 at 02:37:54PM -0300, Henrique de Moraes Holschuh wrote:
> > Microcode updates that requires an unknown loader should never reach the
> > apply_* functions (the code should have rejected it earlier).  Likewise
> > for an unknown microcode header layout.
> > 
> > Signed-off-by: Henrique de Moraes Holschuh 
> > ---
> >  arch/x86/kernel/cpu/microcode/intel.c   |2 ++
> >  arch/x86/kernel/cpu/microcode/intel_early.c |2 ++
> >  2 files changed, 4 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/cpu/microcode/intel.c 
> > b/arch/x86/kernel/cpu/microcode/intel.c
> > index 40caef1..439681f 100644
> > --- a/arch/x86/kernel/cpu/microcode/intel.c
> > +++ b/arch/x86/kernel/cpu/microcode/intel.c
> > @@ -157,6 +157,8 @@ static int apply_microcode_intel(int cpu)
> > if (mc_intel == NULL)
> > return 0;
> >  
> > +   BUG_ON(mc_intel->hdr.hdrver != 1 || mc_intel->hdr.ldrver != 1);
> > +
> > /* Intel SDM vol 3A section 9.11.6, page 9-34 */
> > if (WARN_ONCE((unsigned long)(mc_intel->bits) % 16,
> > "microcode data incorrectly aligned"))
> > diff --git a/arch/x86/kernel/cpu/microcode/intel_early.c 
> > b/arch/x86/kernel/cpu/microcode/intel_early.c
> > index 994c59b..095db11 100644
> > --- a/arch/x86/kernel/cpu/microcode/intel_early.c
> > +++ b/arch/x86/kernel/cpu/microcode/intel_early.c
> > @@ -671,6 +671,8 @@ static int apply_microcode_early(struct mc_saved_data 
> > *mc_saved_data,
> > if (mc_intel == NULL)
> > return 0;
> >  
> > +   BUG_ON(mc_intel->hdr.hdrver != 1 || mc_intel->hdr.ldrver != 1);
> > +
> > mcu_data = mc_intel->bits;
> > aligned_mcu_data = mc_intel->bits;
> 
> Both not needed, because we're running all microcode through
> microcode_sanity_check() first which already does that check.

Yeah, that's why it is BUG_ON().

But if you feel this is too defensive, I will just drop this patch.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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] clk: Propagate prepare and enable when reparenting orphans

[Doug Anderson]

Russell,

On Fri, Nov 7, 2014 at 10:58 AM, Russell King - ARM Linux
 wrote:
> On Fri, Nov 07, 2014 at 10:51:52AM -0800, Doug Anderson wrote:
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 4896ae9..a3d3d58 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -1650,6 +1650,17 @@ void __clk_reparent(struct clk *clk, struct clk 
>> *new_parent)
>>   clk_reparent(clk, new_parent);
>>   __clk_recalc_accuracies(clk);
>>   __clk_recalc_rates(clk, POST_RATE_CHANGE);
>> +
>> + if (clk->prepare_count) {
>> + unsigned long flags;
>> +
>> + __clk_prepare(new_parent);
>> +
>> + flags = clk_enable_lock();
>> + if (clk->enable_count)
>> + __clk_enable(new_parent);
>> + clk_enable_unlock(flags);
>> + }
>
> I really don't understand why this isn't already done - I said this was
> necessary a /long/ time ago.
>
> However, the above isn't sufficient.  Think about the old parent - this
> should be disabled and unprepared if it was prepared and enabled by the
> child.

You may be referring of a different bug than I am addressing.  I can
think about the old parent, but it always a tear to my eyes since
these clocks are orphans and had no old parents (unless you count the
matron at the orphanage, but I doubt she was either prepared or
enabled).  ;)

Ah, but I see!  There are other users of this function that are not
part of "clk.c".  Doh!  Since this was a "__" function with no
documentation I assumed it was "static", but I see that it is not.  I
see two callers that are not part of the orphan code.

I'll happily move this code down so it's only called by the orphan
code and not touch the two callers of __clk_reparent(), assuming that
they don't need to deal with this scenario.


NOTE: As far as I can tell, the standard exposed API call is
clk_set_parent().  From reading comments that does move the prepared /
enabled state, but I haven't confirmed that functionality.

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

[PATCH 1/3] SMBUS: Add DeviceIDs for SunrisePoint LP

[Devin Ryles]

>From 8386c61977dce52fcdfe7fb279692606f47650bc Mon Sep 17 00:00:00 2001
From: Devin Ryles 
Date: Wed, 5 Nov 2014 16:30:03 -0500
Subject: [PATCH 1/3] SMBUS: Add DeviceIDs for SunrisePoint LP

This patch adds the DeviceIDs for SunrisePoint LP

Signed-off-by: Devin Ryles 
---
 Documentation/i2c/busses/i2c-i801 | 1 +
 drivers/i2c/busses/Kconfig| 1 +
 drivers/i2c/busses/i2c-i801.c | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/Documentation/i2c/busses/i2c-i801
b/Documentation/i2c/busses/i2c-i801
index 793c83d..82f48f7 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -29,6 +29,7 @@ Supported adapters:
   * Intel Wildcat Point-LP (PCH)
   * Intel BayTrail (SOC)
   * Intel Sunrise Point-H (PCH)
+  * Intel Sunrise Point-LP (PCH)
Datasheets: Publicly available at the Intel website
 
 On Intel Patsburg and later chipsets, both the normal host SMBus
controller
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 917c358..06e99eb 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -123,6 +123,7 @@ config I2C_I801
Wildcat Point-LP (PCH)
BayTrail (SOC)
Sunrise Point-H (PCH)
+   Sunrise Point-LP (PCH)
 
  This driver can also be built as a module.  If so, the module
  will be called i2c-i801.
diff --git a/drivers/i2c/busses/i2c-i801.c
b/drivers/i2c/busses/i2c-i801.c
index 7cfc183..e158e18 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -63,6 +63,7 @@
  * Wildcat Point-LP (PCH)  0x9ca2  32  hardyes yes yes
  * BayTrail (SOC)  0x0f12  32  hardyes yes yes
  * Sunrise Point-H (PCH)   0xa123  32  hardyes yes yes
+ * Sunrise Point-LP (PCH)  0x9d23  32  hardyes yes yes
  *
  * Features supported by this driver:
  * Software PECno
@@ -186,6 +187,7 @@
 #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS 0x9c22
 #define PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_SMBUS  0x9ca2
 #define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_SMBUS   0xa123
+#define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_SMBUS  0x9d23
 
 struct i801_mux_config {
char *gpio_chip;
@@ -833,6 +835,7 @@ static const struct pci_device_id i801_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_BAYTRAIL_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_BRASWELL_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_SMBUS) },
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_SMBUS) },
{ 0, }
 };
 
-- 
1.9.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 7/8] x86, microcode, intel: guard against misaligned microcode data

[Henrique de Moraes Holschuh]

On Fri, 07 Nov 2014, Borislav Petkov wrote:
> > --- a/Documentation/x86/early-microcode.txt
> > +++ b/Documentation/x86/early-microcode.txt
> > @@ -14,6 +14,16 @@ during boot time. The microcode file in cpio name space 
> > is:
> >  on Intel: kernel/x86/microcode/GenuineIntel.bin
> >  on AMD  : kernel/x86/microcode/AuthenticAMD.bin
> >  
> > +For Intel processors, the microcode load process will be faster when 
> > special
> 
> faster??

Well, it might well be lost in the noise given how slow a microcode update
is.

What I mean is that the early microcode driver "won't waste cpu time moving
data that is already aligned".

However, if the data is _not_ aligned (and it will *not* be aligned if you
use standard cpio without any tricks), the early driver will have to move it
around so that it respects the architectural requirement of 16-byte
alignment for the microcode update WRMSR.

> > index 2182cec..40caef1 100644
> > --- a/arch/x86/kernel/cpu/microcode/intel.c
> > +++ b/arch/x86/kernel/cpu/microcode/intel.c
> > @@ -157,6 +157,11 @@ static int apply_microcode_intel(int cpu)
> > if (mc_intel == NULL)
> > return 0;
> >  
> > +   /* Intel SDM vol 3A section 9.11.6, page 9-34 */
> > +   if (WARN_ONCE((unsigned long)(mc_intel->bits) % 16,
> > +   "microcode data incorrectly aligned"))
> 
> I wonder how many people would start complaining when this goes out the
> door? Have you checked actually how the majority of the tools do layout
> the microcode in the initrd?

That WARN_ONCE() should only trigger if a bug shows its ugly face.  If it is
triggering in any other case, this patch is broken.

mc_intel->bits in the late driver really shouldn't depend at all on any
alignment from initramfs or whatever: that path is supposed to run on
microcode that came from the firmware loader, or the deprecated microcode
device, or which was memcpy'd from the initramfs to a kmalloc()'d area by
save_microcode() in the early driver.  All of these will always be 16-byte
aligned AFAIK.

So, the early driver gets alignment code as it will usually have to deal
with unaligned microcode data, and the late driver (which should never see
unaligned microcode data) gets a WARN_ONCE to alert us if something broke in
the kernel code.

Should I change the WARN_ONCE message to:

WARN_ONCE(... "kernel bug: microcode data incorrectly aligned") ?

> > +   return -1;
> > +
> > /*
> >  * Microcode on this CPU might be already up-to-date.  Only apply
> >  * the microcode patch in mc_intel when it is newer than the one
> > diff --git a/arch/x86/kernel/cpu/microcode/intel_early.c 
> > b/arch/x86/kernel/cpu/microcode/intel_early.c
> > index 92629a8..994c59b 100644
> > --- a/arch/x86/kernel/cpu/microcode/intel_early.c
> > +++ b/arch/x86/kernel/cpu/microcode/intel_early.c
> > @@ -662,14 +662,40 @@ static int apply_microcode_early(struct mc_saved_data 
> > *mc_saved_data,
> > struct microcode_intel *mc_intel;
> > unsigned int val[2];
> >  
> > +   char savedbuf[16];
> > +   void *mcu_data;
> > +   void *aligned_mcu_data;
> > +   unsigned int mcu_size = 0;
> > +
> > mc_intel = uci->mc;
> > if (mc_intel == NULL)
> > return 0;
> >  
> > +   mcu_data = mc_intel->bits;
> > +   aligned_mcu_data = mc_intel->bits;
> > +
> > +   /* Intel SDM vol 3A section 9.11.6, page 9-34: */
> > +   /* WRMSR MSR_IA32_UCODE_WRITE requires 16-byte alignment */
> 
> Kernel comment style:
> 
>   /*
>* Blabla.
>* More bla.
>*/

Will fix.

> > +   if ((unsigned long)(mcu_data) % 16) {
> > +   /* We have more than 16 bytes worth of microcode header
> > +* just before mc_intel->bits on a version 1 header */
> > +   BUILD_BUG_ON(offsetof(struct microcode_intel, bits) < 16);
> 
> That's not really needed - I don't see struct microcode_header_intel
> changing anytime soon.

Neither do I.  But this has zero footprint on the resulting kernel, and
might save someone 10 years from now from trying to debug initramfs data
corruption.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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] w1: support auto-load of w1_bq27000 module.

[NeilBrown]

1/ change request_module call to zero-pad single digit
   family numbers.  This appears to be the intention of
   the code, but not what it actually does.

   This means that the alias created for W1_FAMILY_SMEM_01
   might actually be useful.

2/ Define a family name for the BQ27000 battery charge monitor.
   Unfortunately this is the same number as W1_FAMILY_SMEM_01
   so if both a compiled on a system, one module might need to
   be blacklisted.

3/ Add a MODULE_ALIAS for the bq27000.

Signed-off-by: NeilBrown 

diff --git a/drivers/w1/slaves/w1_bq27000.c b/drivers/w1/slaves/w1_bq27000.c
index afbefed5f2c9..caafb1722783 100644
--- a/drivers/w1/slaves/w1_bq27000.c
+++ b/drivers/w1/slaves/w1_bq27000.c
@@ -88,7 +88,7 @@ static struct w1_family_ops w1_bq27000_fops = {
 };
 
 static struct w1_family w1_bq27000_family = {
-   .fid = 1,
+   .fid = W1_FAMILY_BQ27000,
.fops = _bq27000_fops,
 };
 
@@ -111,7 +111,7 @@ module_exit(w1_bq27000_exit);
 
 module_param(F_ID, int, S_IRUSR);
 MODULE_PARM_DESC(F_ID, "1-wire slave FID for BQ device");
-
+MODULE_ALIAS("w1-family-" __stringify(W1_FAMILY_BQ27000));
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Texas Instruments Ltd");
 MODULE_DESCRIPTION("HDQ/1-wire slave driver bq27000 battery monitor chip");
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 592f7edc671e..181f41cb960b 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -727,7 +727,7 @@ int w1_attach_slave_device(struct w1_master *dev, struct 
w1_reg_num *rn)
 
/* slave modules need to be loaded in a context with unlocked mutex */
mutex_unlock(>mutex);
-   request_module("w1-family-0x%0x", rn->family);
+   request_module("w1-family-0x%02x", rn->family);
mutex_lock(>mutex);
 
spin_lock(_flock);
diff --git a/drivers/w1/w1_family.h b/drivers/w1/w1_family.h
index 0d18365b61ad..ed5dcb80a1f7 100644
--- a/drivers/w1/w1_family.h
+++ b/drivers/w1/w1_family.h
@@ -27,6 +27,7 @@
 #include 
 
 #define W1_FAMILY_DEFAULT  0
+#define W1_FAMILY_BQ27000  0x01
 #define W1_FAMILY_SMEM_01  0x01
 #define W1_FAMILY_SMEM_81  0x81
 #define W1_THERM_DS18S20   0x10


pgpFH4KuONIo9.pgp
Description: OpenPGP digital signature

A recommendation from Support

[support2341]

Hello,

Hey Friend,

As you know, I’m always on the lookout for 
real ways to make decent money.   
 
Not just a measly $20 or $30 a day; I mean real money. 

$20,000 or $30,000 A DAY?!?! Now THAT is…

DAMN GOOD REAL MONEY!

His 6 figure bank accounts now are a pretty good 
indicator that Trevor Haynes has figured it out.

Check this out -  http://tinyurl.com/ko7bljk

The Millionaire Money Machine has nothing to do with 
eBooks, websites, T-shirts, MLM, gambling, writing, 
flipping sites or any of that.

THIS isn’t about making ten buck here or there. 

It’s about making TENS OF THOUSANDS DAILY.

You’ll meet one Millionaire Money Machine user who 
banked over $30K overnight… 

While he was asleep!

Take a look -  http://tinyurl.com/ko7bljk  

For a VERY LIMITED number, Haynes is giving away his 
Millionaire Money Machine. No strings, No BS.

But DO NOT WAIT on this!

Check it out here:

-  http://tinyurl.com/ko7bljk









NOTE: If your email account doesn't automatically turn the URL above into a 
link, 
  you can copy and paste it into your browser.   

If the link is broken please use this: 
http://nikkanares.mmmachine.cpa.clicksure.com   



Click below to view the webpage that your friend has recommended:


Support has used the Tell-a-Friend form to send you this link.

We look forward to your visit!


--
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 3/5] fm10k: Implement ndo_gso_check()

[Joe Stringer]

On Friday, November 07, 2014 11:49:38 Vick, Matthew wrote:
> On 11/6/14, 9:05 PM, "Joe Stringer"  wrote:
> >Let's merge both discussions into one thread (pick here or there). We
> >have
> >this suggestion or the one which simply checks for tunnels and
> >inner+outer
> >header lengths. Do you have a preference between them?
> 
> Agreed with merging the thread--consider it merged!
> 
> Reflecting on this some more, I prefer the latter option (checking tunnels
> and header lengths). I'm leaning towards pushing the header length check
> into fm10k_tx_encap_offload and then making fm10k_gso_check call that with
> the gso_type. So, it's really the most recent version of the patch you
> proposed:
> 
> static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
> {
>   if ((skb_shinfo(skb)->gso_type & (SKB_GSO_UDP_TUNNEL | SKB_GSO_GRE)) &&
>   !fm10k_tx_encap_offload(skb))
>   return false;
> 
>   return true;
> }
> 
> 
> plus the header length being checked in fm10k_tx_encap_offload. The only
> nit would be that I'd just return the conditional instead of having
> "return true" or "return false" lines.

OK, that sounds reasonable.

> The tunnel length check really should be there in fm10k_tx_encap_offload
> anyway, so I'll get a patch together for that one.

Thanks.

> >We could introduce an "skb_is_gso_encap()" or similar for this purpose.
> >Checking for SKB_GSO_UDP_TUNNEL or SKB_GSO_GRE is pretty closely tied to
> >what
> >fm10k_tx_encap_offload() checks for though; it might not even make sense
> >to call
> >it if some of the other SKB_GSO_* flags are raised.
> 
> A fair point. On the other hand, we have to check the header length both
> in the GSO and non-GSO cases anyway, so only having the check in
> fm10k_tx_encap_offload and calling it from fm10k_gso_check wouldn't be as
> duplicative. What do you think about that approach?

Sure, I think fm10k_tx_encap_offload() is a good place for the header length 
check. Separately, my question above was regarding the idea of a helper for 
SKB_GSO_{GRE,UDP_TUNNEL}. The only reason it might be useful for the fm10k 
driver is because all encap is checked in the fm10k_tx_encap_offload() 
function. 
Other drivers don't seem to handle different tunnels together like this though, 
so I'm inclined to stick with the below for now.

static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
{   
return (!(skb_shinfo(skb)->gso_type &   
  (SKB_GSO_UDP_TUNNEL | SKB_GSO_GRE)) ||
fm10k_tx_encap_offload(skb));   
}

Cheers,
Joe
--
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] netfilter: fix compile of nft_reject_bridge

[Thomas Meyer]

Von: Stephen Hemminger 
> An: Thomas Meyer 
> Betreff: Re: [PATCH] netfilter: fix compile of nft_reject_bridge
> Datum: Mon, 3 Nov 2014 12:44:06 -0800
> 
> On Sat, 01 Nov 2014 16:21:39 +0100
> Thomas Meyer  wrote:
> 
> > Module uses csum_ipv6_magic(), so include the correct header file.
> > 
> > Signed-off-by: Thomas Meyer 
> > ---
> > 
> > diff --git a/net/bridge/netfilter/nft_reject_bridge.c
b/net/bridge/netfilter/nft_reject_bridge.c
> > index 654c901..1123f2b 100644
> > --- a/net/bridge/netfilter/nft_reject_bridge.c
> > +++ b/net/bridge/netfilter/nft_reject_bridge.c
> > @@ -16,6 +16,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > 
> > 
> 
> Acked-by: Stephen Hemminger 


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

[PATCH 2/3] AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller

[Devin Ryles]

>From f01919cca1259bb2eec1c6db00cf31055a5c481d Mon Sep 17 00:00:00 2001
From: Devin Ryles 
Date: Wed, 5 Nov 2014 17:41:22 -0500
Subject: [PATCH 2/3] AHCI: Add DeviceIDs for Sunrise Point-LP SATA
controller

This patch adds DeviceIDs for Sunrise Point-LP

Signed-off-by: Devin Ryles 
---
 drivers/ata/ahci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5f039f1..50d9de5 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -313,6 +313,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x8c87), board_ahci }, /* 9 Series RAID */
{ PCI_VDEVICE(INTEL, 0x8c8e), board_ahci }, /* 9 Series RAID */
{ PCI_VDEVICE(INTEL, 0x8c8f), board_ahci }, /* 9 Series RAID */
+   { PCI_VDEVICE(INTEL, 0x9d03), board_ahci }, /* Sunrise Point-LP AHCI*/
+   { PCI_VDEVICE(INTEL, 0x9d05), board_ahci }, /* Sunrise Point-LP RAID*/
+   { PCI_VDEVICE(INTEL, 0x9d07), board_ahci }, /* Sunrise Point-LP RAID*/
 
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
-- 
1.9.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/