[PATCH 3/6] ARM: DT: STi: STiH407: Update picophyreset for the usb3 controllers usb2 phy

[Peter Griffin]

Ths picophyreset is incorrectly defined, which stops the usb2 phy being
taken out of reset.

Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stih407-family.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index c06a546..186412d 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -280,7 +280,7 @@
#phy-cells = <0>;
st,syscfg = <_core 0x100 0xf4>;
resets = < STIH407_PICOPHY_SOFTRESET>,
-< STIH407_PICOPHY0_RESET>;
+< STIH407_PICOPHY2_RESET>;
reset-names = "global", "port";
};
 
-- 
1.9.1

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

[PATCH 1/6] phy: miphy365x: Use the generic phy type constants in dt-bindings/phy/phy.h

[Peter Griffin]

Now there are generic phy type constants declared in phy.h, migrate over to
using them rather than defining our own. This change has been done as one
atomic commit to be bisectable.

Signed-off-by: Peter Griffin 
---
 Documentation/devicetree/bindings/phy/phy-miphy365x.txt |  8 
 arch/arm/boot/dts/stih416.dtsi  |  4 ++--
 drivers/phy/phy-miphy365x.c | 14 +++---
 include/dt-bindings/phy/phy-miphy365x.h | 14 --
 4 files changed, 13 insertions(+), 27 deletions(-)
 delete mode 100644 include/dt-bindings/phy/phy-miphy365x.h

diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt 
b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
index 9802d5d..8772900 100644
--- a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -20,8 +20,8 @@ Required nodes:  A sub-node is required for each 
channel the controller
 Required properties (port (child) node):
 - #phy-cells   : Should be 1 (See second example)
  Cell after port phandle is device type from:
-   - MIPHY_TYPE_SATA
-   - MIPHY_TYPE_PCI
+   - PHY_TYPE_SATA
+   - PHY_TYPE_PCI
 - reg  : Address and length of register sets for each device in
  "reg-names"
 - reg-names : The names of the register addresses corresponding to the
@@ -68,10 +68,10 @@ property, containing a phandle to the phy port node and a 
device type.
 
 Example:
 
-#include 
+#include 
 
sata0: sata@fe38 {
...
-   phys  = <_port0 MIPHY_TYPE_SATA>;
+   phys  = <_port0 PHY_TYPE_SATA>;
...
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index ea28eba..eeb7afe 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -10,7 +10,7 @@
 #include "stih416-clock.dtsi"
 #include "stih416-pinctrl.dtsi"
 
-#include 
+#include 
 #include 
 #include 
 / {
@@ -306,7 +306,7 @@
reg = <0xfe38 0x1000>;
interrupts  = ;
interrupt-names = "hostc";
-   phys= <_port0 MIPHY_TYPE_SATA>;
+   phys= <_port0 PHY_TYPE_SATA>;
phy-names   = "sata-phy";
resets  = < STIH416_SATA0_POWERDOWN>,
  < STIH416_SATA0_SOFTRESET>;
diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
index 6c80154..98bffbc 100644
--- a/drivers/phy/phy-miphy365x.c
+++ b/drivers/phy/phy-miphy365x.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #define HFC_TIMEOUT100
 
@@ -176,7 +176,7 @@ static u8 rx_tx_spd[] = {
 static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
  struct miphy365x_dev *miphy_dev)
 {
-   bool sata = (miphy_phy->type == MIPHY_TYPE_SATA);
+   bool sata = (miphy_phy->type == PHY_TYPE_SATA);
 
return regmap_update_bits(miphy_dev->regmap,
  miphy_phy->ctrlreg,
@@ -430,7 +430,7 @@ static int miphy365x_init(struct phy *phy)
}
 
/* Initialise Miphy for PCIe or SATA */
-   if (miphy_phy->type == MIPHY_TYPE_PCIE)
+   if (miphy_phy->type == PHY_TYPE_PCIE)
ret = miphy365x_init_pcie_port(miphy_phy, miphy_dev);
else
ret = miphy365x_init_sata_port(miphy_phy, miphy_dev);
@@ -454,8 +454,8 @@ int miphy365x_get_addr(struct device *dev, struct 
miphy365x_phy *miphy_phy,
return ret;
}
 
-   if (!((!strncmp(name, "sata", 4) && type == MIPHY_TYPE_SATA) ||
- (!strncmp(name, "pcie", 4) && type == MIPHY_TYPE_PCIE)))
+   if (!((!strncmp(name, "sata", 4) && type == PHY_TYPE_SATA) ||
+ (!strncmp(name, "pcie", 4) && type == PHY_TYPE_PCIE)))
return 0;
 
miphy_phy->base = of_iomap(phynode, index);
@@ -498,8 +498,8 @@ static struct phy *miphy365x_xlate(struct device *dev,
 
miphy_phy->type = args->args[0];
 
-   if (!(miphy_phy->type == MIPHY_TYPE_SATA ||
- miphy_phy->type == MIPHY_TYPE_PCIE)) {
+   if (!(miphy_phy->type == PHY_TYPE_SATA ||
+ miphy_phy->type == PHY_TYPE_PCIE)) {
dev_err(dev, "Unsupported device type: %d\n", miphy_phy->type);
return ERR_PTR(-EINVAL);
}
diff --git a/include/dt-bindings/phy/phy-miphy365x.h 
b/include/dt-bindings/phy/phy-miphy365x.h
deleted file mode 100644
index 8ef8aba..000
--- a/include/dt-bindings/phy/phy-miphy365x.h
+++ /dev/null
@@ -1,14 +0,0 @@
-/*
- * This header provides constants for the phy framework
- * based on the STMicroelectronics MiPHY365x.
- *
- * Author: Lee Jones 
- */

[PATCH 5/6] usb: dwc3: dwc3-st: Update the DT example.

[Peter Griffin]

There is a subtle type phys-names should be phy-names. Using the
current example means you don't have working usb. Also update
the example to use the generic phy type constants which are now
used for miphy28.

Signed-off-by: Peter Griffin 
---
 Documentation/devicetree/bindings/usb/dwc3-st.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt 
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
index f9d7025..6634064 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-st.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -62,7 +62,7 @@ st_dwc3: dwc3@8f94000 {
reg = <0x0990 0x10>;
interrupts  = ;
dr_mode = "host";
-   phys-names  = "usb2-phy", "usb3-phy";
-   phys= <_picophy2>, <_port2 MIPHY_TYPE_USB>;
+   phy-names   = "usb2-phy", "usb3-phy";
+   phys= <_picophy2>, <_port2 PHY_TYPE_USB3>;
};
 };
-- 
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 6/6] MAINTAINERS: Add phy-miphy28lp.c to ARCH/STI architecture

[Peter Griffin]

This patch adds the phy-miphy28lp.c phy driver found on STMicroelectronics
stih407 family SoC's into the STI arch section of the maintainers file.

Signed-off-by: Peter Griffin 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..1a6180a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1457,6 +1457,7 @@ F:drivers/clocksource/arm_global_timer.c
 F: drivers/i2c/busses/i2c-st.c
 F: drivers/media/rc/st_rc.c
 F: drivers/mmc/host/sdhci-st.c
+F: drivers/phy/phy-miphy28lp.c
 F: drivers/phy/phy-stih407-usb.c
 F: drivers/phy/phy-stih41x-usb.c
 F: drivers/pinctrl/pinctrl-st.c
-- 
1.9.1

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

[PATCH 0/6] Add dwc3 usb3 DT node and various phy cleanup

[Peter Griffin]

Hi,

This series primarily adds the dwc3 DT node which activates the usb3 controller 
on
the stih407-b2120 and stih410-b2120 platforms.

As part of getting this working I noticed some various errors with the DT
documentation examples for how we reference the PHYs which I've also fixed.

Whilst doing this I also noticed the miphy365 (found on stih415/6 platforms) 
could
now use the generic PHY constants which are used by miphy28, so I've updated 
this
driver and the DT docs accoringly..

Also miphy28lp driver isn't included in STI section of MAINTAINERS, so rectify 
that.

regards,

Peter.

Peter Griffin (6):
  phy: miphy365x: Use the generic phy type constants in
dt-bindings/phy/phy.h
  ahci: st: Update the DT example for how to obtain the PHY.
  ARM: DT: STi: STiH407: Update picophyreset for the usb3 controllers
usb2 phy
  ARM: DT: STi: STiH407: Add dwc3 usb3 DT node.
  usb: dwc3: dwc3-st: Update the DT example.
  MAINTAINERS: Add phy-miphy28lp.c to ARCH/STI architecture

 Documentation/devicetree/bindings/ata/ahci-st.txt  |  4 ++--
 .../devicetree/bindings/phy/phy-miphy365x.txt  |  8 +++
 Documentation/devicetree/bindings/usb/dwc3-st.txt  |  4 ++--
 MAINTAINERS|  1 +
 arch/arm/boot/dts/stih407-family.dtsi  | 28 +-
 arch/arm/boot/dts/stih416.dtsi |  4 ++--
 drivers/phy/phy-miphy365x.c| 14 +--
 include/dt-bindings/phy/phy-miphy365x.h| 14 ---
 8 files changed, 45 insertions(+), 32 deletions(-)
 delete mode 100644 include/dt-bindings/phy/phy-miphy365x.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 4/6] ARM: DT: STi: STiH407: Add dwc3 usb3 DT node.

[Peter Griffin]

Now that both usb2 and usb3 phy drivers, and also the ST dwc3 glue code
are all present upstream, we can add the dwc3 DT node and have a working
usb3 controller on stih407-b2120 and stih410-b2020.

Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stih407-family.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index 186412d..18ff5a5 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -7,6 +7,7 @@
  * publishhed by the Free Software Foundation.
  */
 #include "stih407-pinctrl.dtsi"
+#include 
 #include 
 / {
#address-cells = <1>;
@@ -336,5 +337,30 @@
resets = < STIH407_MIPHY2_SOFTRESET>;
};
};
+
+   st_dwc3: dwc3@8f94000 {
+   compatible  = "st,stih407-dwc3";
+   reg = <0x08f94000 0x1000>, <0x110 0x4>;
+   reg-names   = "reg-glue", "syscfg-reg";
+   st,syscfg   = <_core>;
+   resets  = < STIH407_USB3_POWERDOWN>,
+ < STIH407_MIPHY2_SOFTRESET>;
+   reset-names = "powerdown",
+ "softreset";
+   #address-cells  = <1>;
+   #size-cells = <1>;
+   pinctrl-names   = "default";
+   pinctrl-0   = <_usb3>;
+   ranges;
+
+   dwc3: dwc3@990 {
+   compatible  = "snps,dwc3";
+   reg = <0x0990 0x10>;
+   interrupts  = ;
+   dr_mode = "host";
+   phy-names   = "usb2-phy", "usb3-phy";
+   phys= <_picophy0>, <_port2 
PHY_TYPE_USB3>;
+   };
+   };
};
 };
-- 
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 2/2] rocker: silence shift wrapping warning

[Dan Carpenter]

"val" is declared as a u64 so static checkers complain that this shift
can wrap.  I don't have the hardware but probably it's doesn't have over
31 ports.  Still we may as well silence the warning even if it's not a
real bug.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/ethernet/rocker/rocker.c 
b/drivers/net/ethernet/rocker/rocker.c
index 713a13c..9fb6948 100644
--- a/drivers/net/ethernet/rocker/rocker.c
+++ b/drivers/net/ethernet/rocker/rocker.c
@@ -1257,9 +1257,9 @@ static void rocker_port_set_enable(struct rocker_port 
*rocker_port, bool enable)
u64 val = rocker_read64(rocker_port->rocker, PORT_PHYS_ENABLE);
 
if (enable)
-   val |= 1 << rocker_port->lport;
+   val |= 1ULL << rocker_port->lport;
else
-   val &= ~(1 << rocker_port->lport);
+   val &= ~(1ULL << rocker_port->lport);
rocker_write64(rocker_port->rocker, PORT_PHYS_ENABLE, val);
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/8 v2] ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER

[Roger Quadros]

On 24/02/15 22:05, Robert ABEL wrote:
> The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
> even though the access is defined as asynchronous, and no GPMC_CLK clock
> is provided to the external device. Still, GPMCFCLKDIVIDER is used as a 
> divider
> for the GPMC clock, so it must be programmed to define the
> correct WAITMONITORINGTIME delay.
> 
> Signed-off-by: Robert ABEL 

Acked-by: Roger Quadros 

cheers,
-roger

> ---
>  drivers/memory/omap-gpmc.c | 15 +--
>  1 file changed, 5 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index ff1a1e7..a6abaf0 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -566,19 +566,14 @@ int gpmc_cs_set_timings(int cs, const struct 
> gpmc_timings *t)
>   if (gpmc_capability & GPMC_HAS_WR_ACCESS)
>   GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
>  
> - /* caller is expected to have initialized CONFIG1 to cover
> -  * at least sync vs async
> -  */
>   l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
> - if (l & (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
>  #ifdef DEBUG
> - printk(KERN_INFO "GPMC CS%d CLK period is %lu ns (div %d)\n",
> - cs, (div * gpmc_get_fclk_period()) / 1000, div);
> + printk(KERN_INFO "GPMC CS%d CLK period is %lu ns (div %d)\n",
> + cs, (div * gpmc_get_fclk_period()) / 1000, div);
>  #endif
> - l &= ~0x03;
> - l |= (div - 1);
> - gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
> - }
> + l &= ~0x03;
> + l |= (div - 1);
> + gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
>  
>   gpmc_cs_bool_timings(cs, >bool_timings);
>   gpmc_cs_show_timings(cs, "after gpmc_cs_set_timings");
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/8] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3

[Lukasz Majewski]

Hi Eduardo,

> On Wed, Feb 18, 2015 at 11:07:33AM +0100, Lukasz Majewski wrote:
> > With those bindings it is possible to use pwm-fan device available
> > in Odroid U3 as a cooling device.
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> > Changes for v2:
> > - Rename cooling-pwm-values property to cooling-levels
> > Changes for v3:
> > - Change patch's topic to "ARM dts"
> > - Reduce maximal cooling-level to 230 from 255
> > Changes for v4:
> > - None
> > ---
> >  arch/arm/boot/dts/exynos4412-odroidu3.dts | 33
> > ++- 1 file changed, 32 insertions(+), 1
> > deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> > b/arch/arm/boot/dts/exynos4412-odroidu3.dts index 60bd1e4..3e5df3e
> > 100644 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> > +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> > @@ -32,11 +32,42 @@
> > };
> > };
> >  
> > -   pwm-fan {
> > +   fan0: pwm-fan {
> > compatible = "pwm-fan";
> > pwms = < 0 1 0>;
> > +   cooling-min-state = <0>;
> > +   cooling-max-state = <3>;
> > +   #cooling-cells = <2>;
> > +   cooling-levels = <0 102 170 230>;
> > status = "okay";
> > };
> > +
> > +   thermal-zones {
> > +   cpu_thermal: cpu-thermal {
> 
> 
> This thermal zone misses the mandatory properties as per 
>  Documentation/devicetree/bindings/thermal/thermal.txt

Following mandatory properties:
thermal-sensors = < 0>;
polling-delay-passive = <0>;
polling-delay = <0>;
trips {

}

are defined in exynos4-cpu-thermal.dtsi included by this file.

In this patch only device dependent changes are stated.

> 
> > +   cooling-maps {
> > +   map0 {
> > +trip = <_alert1>;
> > +cooling-device = < 7 7>;
> > +   };
> > +   map1 {
> > +trip = <_alert2>;
> > +cooling-device = < 13
> > 13>;
> > +   };
> > +   map2 {
> > +trip = <_alert0>;
> > +cooling-device = < 0 1>;
> > +   };
> > +   map3 {
> > +trip = <_alert1>;
> > +cooling-device = < 1 2>;
> > +   };
> > +   map4 {
> > +trip = <_alert2>;
> > +cooling-device = < 2 3>;
> > +   };
> > +   };
> > +   };
> > +   };
> >  };
> >  
> >   {
> > -- 
> > 2.0.0.rc2
> > 



-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] phy: add phy-hi6220-usb

[zhangfei]

On 02/23/2015 11:36 PM, Felipe Balbi wrote:

Hi,

On Sun, Feb 22, 2015 at 11:10:36AM +0800, zhangfei wrote:

+static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
+{
+   struct usb_otg *otg = priv->phy.otg;
+
+   if (!otg->gadget)
+   return;
+
+   if (on)
+   usb_gadget_connect(otg->gadget);
+   else
+   usb_gadget_disconnect(otg->gadget);


why is the PHY fiddling with pullups ?


We use this to enable/disable otg gadget mode.


I got that, but the pullups don't belong to the PHY, they belong to the
gadget.


The gpio_id & gpio_vbus are used to distinguish otg gadget mode or
host mode.
When micro usb or otg device attached to otg, gpio_vbus falling down.
And gpio_id = 1 is micro usb, gpio_id = 0 is otg device.


all of that I understood clearly :-)


So when micro usb attached, we enable gadget mode; while micro usb
detached, we disable gadget mode, and dwc2 will automatically set to
host mode.


that's all fine, I'm concerned about letting the PHY fiddle with
something it doesn't own. If I am to change pullups rules in udc-core,
this is likely to break down miserably and I don't want to have to go
through that.


Thanks for the clarifying.


no problem.


How about using usb_gadget_vbus_connect/disconnect, which are used in many
files under drivers/usb/phy.
There is no vbus_session in dwc2/gadget.c, I thought it would be same as
pullup.

However, usb_gadget_vbus_connect still need para gadget, where should we put
this file, drivers/usb/phy or drivers/phy


drivers/phy, if the framework misses anything you need, it's a great
opportunity to give back to the community by extending the framework.


Sorry, I am a little confused.
I need some concrete suggestion for the next step of this patch, which is
required for the community board, hikey board.

Do you mean in the future we need use hsotg->phy instead of hsotg->uphy.
 struct phy *phy;
 struct usb_phy *uphy;


yes, we need to move everybody to use struct phy, instead of struct
usb_phy.


usb_phy has many members that struct phy does not have, including otg.
struct usb_otg  *otg;
Is that mean we need port such member from usb_phy to phy.


This means we have a little ground work to do before we can add your phy
driver to that framework, right ? As I said, if the framework is missing
anything, work with Kishon (generic phy maintainer) to add those missing
pieces generically.


OK, got it.



Besides, are you ok with using usb_gadget_vbus_connect/disconnect.



Scratching one's own itch kinda thing...


+static void hi6220_detect_work(struct work_struct *work)
+{
+   struct hi6220_priv *priv =
+   container_of(work, struct hi6220_priv, work.work);
+   int gpio_id, gpio_vbus;
+   enum usb_otg_state state;
+
+   if (!gpio_is_valid(priv->gpio_id) || !gpio_is_valid(priv->gpio_vbus))
+   return;
+
+   gpio_id = gpio_get_value_cansleep(priv->gpio_id);
+   gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);


looks like this should be using extcon

Not used extcon before.
However, we need gpio_vbus interrupt.
Checked phy-tahvo.c and phy-omap-otg.c, not find extcon related with
interrupt.
Will investigate tomorrow.


drivers/extcon/extcon-gpio.c

I think there is no need to use extcon, gpio is clear enough.
extcon-gpio.c even do not support dt.


well, add DT. The whole idea of free software is that we improve on
things we already have. EXTCON is *the* API to handle such things.


I think I am still not understanding extcon-gpio, not sure why need
use this API here.


because extcon is the API to use for external connectors. The same way
you use regulator framework to control that single GPIO tied to an
enable signal of a fixed regulator, you use extcon when you need to read
that gpio signal tied to id pin of the USB connector.


Here two gpio requires, one gpio as interrupt, in the interrupt
handler, we detect the gpio status judging the otg status.
extcon-gpio.c use the interrupt, then can we also use the gpio
interrupt.  Using extcon-gpio is used for saving gpio_request?


extcon is used to hide gpio_request from dwc2. dwc2 only knows about
extcon, not gpios. extcon will request the gpio and use it as interrupt
source. When an IRQ fires, it will read the gpio state and decide if it
should broadcast a message to tell dwc2 to become host or peripheral.


Thanks for the kind education, understand now.





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

Re: [PATCH 2/4] x86: get rid of KERNEL_STACK_OFFSET

[Denys Vlasenko]

On 02/25/2015 01:48 PM, Denys Vlasenko wrote:
> On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar  wrote:
>> But the fix should be to not touch RSP in SAVE_ARGS, to
>> keep percpu::kernel_stack as an optimized entry point -
>> with KERNEL_STACK_OFFSET pointing to.
>>
>> So NAK - this should be fixed for real.
> 
> IOW, the proposal is to set KERNEL_STACK_OFFSET
> to SIZEOF_PTREGS. I can do that.
> 
> However.
> 
> There is an ortogonal idea we were discussing: to save
> registers and construct iret frame using PUSH insns, not MOVs.
> IIRC Andy and Linus liked it. I am ambivalent: the code will be smaller,
> but might get slower (at least on some CPUs).
> If we go that way, we will require KERNEL_STACK_OFFSET = 0
> (IOW: the current patch).
> 
> The decision on how exactly we should fix KERNEL_STACK_OFFSET
> (set it to SIZEOF_PTREGS or to zero) depends on whether
> we switch to using PUSHes, or not. What do you think?

A data point. I implemented push-based creation of pt_regs
and benchmarked it. The patch is on top of all my latest
patches sent to ML.

On SandyBridge CPU, it does not get slower: seems to be 1 cycle
faster per syscall.

We lose a number of large insns there:

text   data bss dec hex filename
-   9863  0   098632687 entry_64.o
+   9671  0   0967125c7 entry_64.o


diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index f505cb6..d97bd92 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -128,8 +128,6 @@ ENDPROC(native_usergs_sysret64)
  * manipulation.
  */
.macro FIXUP_TOP_OF_STACK tmp offset=0
-   movq $__USER_DS,SS+\offset(%rsp)
-   movq $__USER_CS,CS+\offset(%rsp)
movq RIP+\offset(%rsp),\tmp  /* get rip */
movq \tmp,RCX+\offset(%rsp)  /* copy it to rcx as sysret would do */
movq EFLAGS+\offset(%rsp),\tmp /* ditto for rflags->r11 */
@@ -245,14 +243,22 @@ GLOBAL(system_call_after_swapgs)
 * and short:
 */
ENABLE_INTERRUPTS(CLBR_NONE)
-   ALLOC_PT_GPREGS_ON_STACK 6*8 /* 6*8: space for orig_ax and iret frame */
-   movq%rcx,RIP(%rsp)
-   movq%r11,EFLAGS(%rsp)
-   movqPER_CPU_VAR(old_rsp),%rcx
-   movq%rcx,RSP(%rsp)
-   movq_cfi rax,ORIG_RAX
-   SAVE_C_REGS_EXCEPT_RAX_RCX_R11
-   movq$-ENOSYS,RAX(%rsp)
+   /* Construct struct pt_regs on stack */
+   pushq   $__USER_DS  /* pt_regs->ss */
+   pushq   PER_CPU_VAR(old_rsp)/* pt_regs->sp */
+   pushq   %r11/* pt_regs->flags */
+   pushq   $__USER_CS  /* pt_regs->cs */
+   pushq   %rcx/* pt_regs->ip */
+   pushq   %rax/* pt_regs->orig_ax */
+   pushq   %rdi/* pt_regs->di */
+   pushq   %rsi/* pt_regs->si */
+   pushq   %rdx/* pt_regs->dx */
+   pushq   %rcx/* pt_regs->cx */
+   pushq   $-ENOSYS/* pt_regs->ax */
+   pushq   %r8 /* pt_regs->r8 */
+   pushq   %r9 /* pt_regs->r9 */
+   pushq   %r10/* pt_regs->r10 */
+   sub $(7*8),%rsp /* pt_regs->r11,bp,bx,r12-15 */
CFI_REL_OFFSET rip,RIP
testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
jnz tracesys


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

Re: [RFC PATCH] arm64: Implement cpu_relax as yield

[Will Deacon]

On Tue, Feb 24, 2015 at 11:07:37PM +, Peter Crosthwaite wrote:
> ARM64 has the yield nop hint which has the intended semantics of
> cpu_relax. Implement.
> 
> The immediate application is ARM CPU emulators. An emulator can take
> advantage of the yield hint to de-prioritise an emulated CPU in favor
> of other emulation tasks. QEMU A64 SMP emulation has yield awareness,
> and sees a significant boot time performance increase with this change.

Could you elaborate on the QEMU SMP boot case please? Usually SMP pens
for booting make use of wfe/sev to minimise the spinning overhead.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Trying to use 'perf probe' to debug perf itself

[Arnaldo Carvalho de Melo]

Em Wed, Feb 25, 2015 at 11:53:16AM +0900, Masami Hiramatsu escreveu:
> (2015/02/25 3:49), Arnaldo Carvalho de Melo wrote:
> > Available variables at thread__get
> > @
> > struct thread*  thread
> > [root@ssdandy ~]#

> > cool, so I thought it would be just a matter of asking to put the probes
> > and get the value of 'thread', then match things, but:

> > [root@ssdandy ~]# perf probe -v ~/bin/perf thread__put thread

> > Writing event: p:probe_perf/thread__put /root/bin/perf:0xd03d2 
> > thread=-32(%sp):u64
> > Failed to write event: Invalid argument
> >   Error: Failed to add events. Reason: Invalid argument (Code: -22)
> > [root@ssdandy ~]#

> > Not possible :-\ 
 
> Hmm, strange. Could you tell me the version of your kernel?

[root@ssdandy ~]# uname -r
3.10.0-210.el7.x86_64

> It seems that the kernel newer than 3.14 supports uprobes with
> memory dereference (e.g. -32(%sp) )feature.

Right, that must be the case, will test, but then, would it be possible
for the kernel, in such cases, return something line EOPNOTSUP?

I will try to figure out a better error message on the tooling side,
something like:

. Realize we're asking for memory dereference in uprobes
. If it fails with EINVAL, check the kernel version and say something
  like:

Please upgrade your kernel to at least x.y.z to have access to feature
FOO_BAR.

- Arnaldo

> (it was actually introduced by 5baaa59e, and git-describe told
>  it was v3.13-rc4-22-g5baaa59)
> 
> And also, could you try to write the result command to uprobe_event as
> below?
> 
> # echo "p:probe_perf/thread__put /root/bin/perf:0xd03d2 thread=-32(%sp):u64" 
> >> \
>  /sys/kernel/debug/tracing/uprobe_events

Well, I'll try that if it fails after I upgrade to 3.14.

> > please let me know if you need some file, here is the readelf -wi for
> > those two routines:
> 
> This should not be the problem of dwarf-analysis. It seems kernel-side
> (uprobe) problem.

Thanks a lot!

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8 v2] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS

[Roger Quadros]

On 24/02/15 22:05, Robert ABEL wrote:
> DTS output was formatted to require additional work when copy-pasting into 
> DTS.
> Nano-second timings were removed, because they were not a confidence interval 
> nor
> an indication what timing values would result in the same #ticks

If they were not is it possible to dump min,max timings that will result in
the same ticks?

Otherwise patch is fine.

cheers,
-roger

> 
> Signed-off-by: Robert ABEL 
> ---
>  drivers/memory/omap-gpmc.c | 33 +++--
>  1 file changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index b5c8305..ff1a1e7 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -337,32 +337,45 @@ static void gpmc_cs_bool_timings(int cs, const struct 
> gpmc_bool_timings *p)
>  }
>  
>  #ifdef DEBUG
> +/**
> + * get_gpmc_timing_reg - read a timing parameter and print DTS settings for 
> it.
> + * @cs  Chip Select Region
> + * @reg GPMC_CS_CONFIGn register offset.
> + * @st_bit  Start Bit
> + * @end_bit End Bit. Must be >= @st_bit.
> + * @nameDTS node name, w/o "gpmc,"
> + * @raw Raw Format Option.
> + *  raw format:  gpmc,name = 
> + *  tick format: gpmc,name =  /* x ticks */
> + * @noval   Parameter values equal to 0 are not printed.
> + * @shift   Parameter value left shifts @shift, which is then printed 
> instead of value.
> + *
> + */
>  static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
>  bool raw, bool noval, int shift,
>  const char *name)
>  {
>   u32 l;
> - int nr_bits, max_value, mask;
> + int nr_bits;
> + int mask;
>  
>   l = gpmc_cs_read_reg(cs, reg);
>   nr_bits = end_bit - st_bit + 1;
> - max_value = (1 << nr_bits) - 1;
> - mask = max_value << st_bit;
> - l = (l & mask) >> st_bit;
> + mask = (1 << nr_bits) - 1;;
> + l = (l >> st_bit) & mask;
>   if (shift)
>   l = (shift << l);
>   if (noval && (l == 0))
>   return 0;
>   if (!raw) {
> - unsigned int time_ns_min, time_ns, time_ns_max;
> + /* DTS tick format for timings in ns */
> + unsigned int time_ns;
>  
> - time_ns_min = gpmc_ticks_to_ns(l ? l - 1 : 0);
>   time_ns = gpmc_ticks_to_ns(l);
> - time_ns_max = gpmc_ticks_to_ns(l + 1 > max_value ?
> -max_value : l + 1);
> - pr_info("gpmc,%s = <%u> (%u - %u ns, %i ticks)\n",
> - name, time_ns, time_ns_min, time_ns_max, l);
> + pr_info("gpmc,%s = <%u> /* %i ticks */\n",
> + name, time_ns, l);
>   } else {
> + /* raw format */
>   pr_info("gpmc,%s = <%u>\n", name, l);
>   }
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MODSIGN: Provide a utility to append a PKCS#7 signature to a module [ver #3]

[Michal Marek]

On 2015-02-06 15:59, David Howells wrote:
> + if (argc == 5) {
> + dest_name = argv[4];
> + replace_orig = false;
> + } else {
> + ERR(asprintf(_name, "%s.~signed~", module_name) < 0,
> + "asprintf");
> + replace_orig = true;
> + }
> +
> + ERR_load_crypto_strings();
> + ERR_clear_error();

The error queue initialization should be done before the first use of
the ERR() macro. Or the asprintf check should be open-coded, because it
has nothing to do with openssl.

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

[patch] memstick: mspro_block: add missing curly braces

[Dan Carpenter]

>From the indenting we can see the curly braces were obviously intended.
This is a static checker fix, but my guess is that we don't read enough
bytes, because we don't calculate "t_len" correctly.

Fixes: f1d82698029b ('memstick: use fully asynchronous request processing')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/memstick/core/mspro_block.c 
b/drivers/memstick/core/mspro_block.c
index fc145d2..922a750 100644
--- a/drivers/memstick/core/mspro_block.c
+++ b/drivers/memstick/core/mspro_block.c
@@ -758,7 +758,7 @@ static int mspro_block_complete_req(struct memstick_dev 
*card, int error)
 
if (error || (card->current_mrq.tpc == MSPRO_CMD_STOP)) {
if (msb->data_dir == READ) {
-   for (cnt = 0; cnt < msb->current_seg; cnt++)
+   for (cnt = 0; cnt < msb->current_seg; cnt++) {
t_len += msb->req_sg[cnt].length
 / msb->page_size;
 
@@ -766,6 +766,7 @@ static int mspro_block_complete_req(struct memstick_dev 
*card, int error)
t_len += msb->current_page - 1;
 
t_len *= msb->page_size;
+   }
}
} else
t_len = blk_rq_bytes(msb->block_req);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] MODSIGN: Use PKCS#7 for module signatures [ver #3]

[Michal Marek]

On 2015-02-06 15:58, David Howells wrote:
> Note that the revised sign-file program no longer supports the "-s 
> "
> option as I'm not sure what the best way to deal with this is.  Do we generate
> a PKCS#7 cert from the signature given, or do we get given a PKCS#7 cert?  I
> lean towards the latter.

It would be convenient to have it, since pesign also has
--import-raw-signature. But it can be added back later.

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

RE: [PATCH 0/7] New eFuse subsystem

[James Hartley]

Hi Maxime, 

> -Original Message-
> From: Ezequiel Garcia
> Sent: 25 February 2015 12:30
> To: Maxime Ripard
> Cc: Thierry Reding; Stephen Warren; Arnd Bergmann; Andrew Bresticker;
> James Hartley; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH 0/7] New eFuse subsystem
> 
> 
> 
> On 02/25/2015 09:02 AM, Maxime Ripard wrote:
> > Hi Ezequiel,
> >
> > On Wed, Feb 25, 2015 at 08:45:12AM -0300, Ezequiel Garcia wrote:
> >> This patchset introduces a new driver subsystem, meant to support
> >> eFuse (alias OTP, one-time-programmable) devices.
> >>
> >> The motivation behind this work is to have a common place for drivers
> >> that are currently more or less scattered: the tegra efuses are in
> >> drivers/soc/ and the sunxi efuses in drivers/misc/eeprom.
> >>
> >> For now, there's no proposal for a generic efuse API. Instead, we
> >> simply group the drivers together.
> >>
> >> This patchset is the result of the initial submission for IMG
> >> Pistachio eFuse support [1]. Our first proposal was to follow the
> >> Tegra efuse, and put the Pistachio efuse in drivers/soc. After some
> >> discussion we finally agreed [2] to first create an efuse directoy,
> >> and then put all efuse drivers in it.
> >>
> >> As always, all comments are welcome!
> >>
> >> [1] http://www.spinics.net/lists/devicetree/msg59246.html
> >> [2] http://www.spinics.net/lists/arm-kernel/msg389325.html
> >
> > Have you looked at the EEPROM framework currently in discussions? The
> > two seems to be covering pretty much the same use cases.
> >

Shouldn't this be a PROM framework if it is going to support both EEPROM and 
EFUSE/QFPROM, or am I missing something here (since an eFuse is not eraseable)? 
 

> 
> Nope, I was obviously unaware of that. Guess we'll wait until the discussion 
> is
> settled and use that framework.
> 
> Thanks!
> --
> Ezequiel

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

Re: [PATCH v1] clk: qcom: Add MSM8916 Global Clock Controller support

[Archit Taneja]

Hi Georgi,

On 02/24/2015 09:19 PM, Georgi Djakov wrote:

On 02/24/2015 06:49 AM, Archit Taneja wrote:

Hi,

[..]

+
+static struct freq_tbl ftbl_gcc_mdss_pclk[] = {
+{ .src = P_DSI0_PHYPLL_DSI },
+{ }
+};
+
+static struct clk_rcg2 pclk0_clk_src = {
+.cmd_rcgr = 0x4d084,


This should be 0x4d000. Same reason as above.


+.mnd_width = 8,
+.hid_width = 5,
+.parent_map = gcc_xo_gpll0_dsiphy_map,
+.freq_tbl = ftbl_gcc_mdss_pclk,
+.clkr.hw.init = &(struct clk_init_data){
+.name = "pclk0_clk_src",
+.parent_names = gcc_xo_gpll0_dsiphy,
+.num_parents = 1,
+.ops = _rcg2_ops,
+},
+};
+
+static const struct freq_tbl ftbl_gcc_mdss_vsync_clk[] = {
+F(1920, P_XO, 1, 0,0),
+{ }
+};
+
+static struct clk_rcg2 vsync_clk_src = {
+.cmd_rcgr = 0x4d02c,
+.hid_width = 5,
+.parent_map = gcc_xo_gpll0a_map,
+.freq_tbl = ftbl_gcc_mdss_vsync_clk,
+.clkr.hw.init = &(struct clk_init_data){
+.name = "vsync_clk_src",
+.parent_names = gcc_xo_gpll0a,
+.num_parents = 2,
+.ops = _rcg2_ops,
+},
+};
+




I think we can update the clk ops for pclk0_clk_src and byte0_clk_src to 
clk_pixel_ops and clk_byte_ops respectively too. The set_rate functions 
in these ops have been modified to make it run with DSI PLL.


An Ack by Stephen for this change would be nice, though.

Archit

--
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: [Linaro-acpi] [PATCH v3 4/9] ACPI: clean up checkpatch warnings for items with possible semantic value

[Hanjun Guo]

On 2015年02月25日 08:36, al.st...@linaro.org wrote:

From: Al Stone 

In preparation for later splitting out some of the arch-dependent code from
osl.c, clean up some warnings from checkpatch that fall into more semantic
issues; none of these should change functionality, but they do touch lines
of code with semantic significance:

-- replaced #include  with #include 
-- replaced extern that was only being used for sizeof() with a #define
-- removed use of else after breaks/returns when not useful
-- moved __initdata to the proper place in a definition
-- moved EXPORT_SYMBOL to a line immediately after the function
-- removed unnecessary return statements from void functions

Signed-off-by: Al Stone 
---
  drivers/acpi/osl.c | 31 ++-
  1 file changed, 10 insertions(+), 21 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 46317ff..af6dda7 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -40,9 +40,8 @@
  #include 
  #include 
  #include 
-
-#include 
-#include 
+#include 
+#include 

  #include "internal.h"

@@ -66,7 +65,7 @@ struct acpi_os_dpc {
  int acpi_in_debugger;
  EXPORT_SYMBOL(acpi_in_debugger);

-extern char line_buf[80];
+#define DEBUGGER_LINE_BUFLEN   80
  #endif/*ENABLE_DEBUGGER */

  static int (*__acpi_os_prepare_sleep)(u8 sleep_state, u32 pm1a_ctrl,
@@ -268,10 +267,8 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
return efi.acpi20;
else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
return efi.acpi;
-   else {
-   pr_err(PREFIX "System description tables not found\n");
-   return 0;
-   }
+   pr_err(PREFIX "System description tables not found\n");
+   return 0;
} else if (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
acpi_physical_address pa = 0;

@@ -594,7 +591,7 @@ static const char * const table_sigs[] = {
  #define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)

  #define ACPI_OVERRIDE_TABLES 64
-static struct cpio_data __initdata acpi_initrd_files[ACPI_OVERRIDE_TABLES];
+static struct cpio_data acpi_initrd_files[ACPI_OVERRIDE_TABLES] __initdata;

  #define MAP_CHUNK_SIZE   (NR_FIX_BTMAPS << PAGE_SHIFT)

@@ -806,10 +803,10 @@ static irqreturn_t acpi_irq(int irq, void *dev_id)
if (handled) {
acpi_irq_handled++;
return IRQ_HANDLED;
-   } else {
-   acpi_irq_not_handled++;
-   return IRQ_NONE;
}
+
+   acpi_irq_not_handled++;
+   return IRQ_NONE;
  }

  acpi_status
@@ -911,7 +908,6 @@ acpi_status acpi_os_read_port(acpi_io_address port, u32 
*value, u32 width)

return AE_OK;
  }
-
  EXPORT_SYMBOL(acpi_os_read_port);

  acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
@@ -927,7 +923,6 @@ acpi_status acpi_os_write_port(acpi_io_address port, u32 
value, u32 width)

return AE_OK;
  }
-
  EXPORT_SYMBOL(acpi_os_write_port);

  #ifdef readq
@@ -1362,7 +1357,7 @@ u32 acpi_os_get_line(char *buffer)
if (acpi_in_debugger) {
u32 chars;

-   kdb_read(buffer, sizeof(line_buf));
+   kdb_read(buffer, sizeof(DEBUGGER_LINE_BUFLEN));


I think kdb_read(buffer, DEBUGGER_LINE_BUFLEN); will be fine.

other than that,

Reviewd-by: Hanjun Guo 

Thanks
Hanjun



/* remove the CR kdb includes */
chars = strlen(buffer) - 1;
@@ -1490,8 +1485,6 @@ static void __init set_osi_linux(unsigned int enable)
acpi_osi_setup("Linux");
else
acpi_osi_setup("!Linux");
-
-   return;
  }

  static void __init acpi_cmdline_osi_linux(unsigned int enable)
@@ -1499,8 +1492,6 @@ static void __init acpi_cmdline_osi_linux(unsigned int 
enable)
osi_linux.cmdline = 1;  /* cmdline set the default and override DMI */
osi_linux.dmi = 0;
set_osi_linux(enable);
-
-   return;
  }

  void __init acpi_dmi_osi_linux(int enable, const struct dmi_system_id *d)
@@ -1512,8 +1503,6 @@ void __init acpi_dmi_osi_linux(int enable, const struct 
dmi_system_id *d)

osi_linux.dmi = 1;  /* DMI knows that this box asks OSI(Linux) */
set_osi_linux(enable);
-
-   return;
  }

  /*


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8 v2] ARM OMAP2+ GPMC: fix debug output alignment

[Roger Quadros]

On 24/02/15 22:05, Robert ABEL wrote:
> GPMC debug output is aligned to 10 characters for field names.
> However, some fields have bigger names, screwing up the alignment.
> Consequently, alignment was changed to longest field name (17 chars) for now.
> 
> Signed-off-by: Robert ABEL 

Acked-by: Roger Quadros 

cheers,
-roger

> ---
>  drivers/memory/omap-gpmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index 78b78a64..b5c8305 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -482,7 +482,7 @@ static int set_gpmc_timing_reg(int cs, int reg, int 
> st_bit, int end_bit,
>   l = gpmc_cs_read_reg(cs, reg);
>  #ifdef DEBUG
>   printk(KERN_INFO
> - "GPMC CS%d: %-10s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n",
> + "GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n",
>  cs, name, ticks, gpmc_get_fclk_period() * ticks / 1000,
>   (l >> st_bit) & mask, time);
>  #endif
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -next 01/13] serial: earlycon: Refactor parse_options into serial core

[Peter Hurley]

Hi Joe,

checkpatch warns on the line below:

On 02/24/2015 11:36 AM, Peter Hurley wrote:
> Prepare to support console-defined matching; refactor the command
> line parameter string processing from parse_options() into a
> new core function, uart_parse_earlycon(), which decodes command line
> parameters of the form:
>earlycon=,io|mmio|mmio32,,
>console=,io|mmio|mmio32,,
>earlycon=,0x,
>console=,0x,
> 
> Signed-off-by: Peter Hurley 
> ---
>  drivers/tty/serial/earlycon.c| 39 --
>  drivers/tty/serial/serial_core.c | 46 
> 
>  include/linux/serial_core.h  |  2 ++
>  3 files changed, 61 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> index 64fe25a..58d6bcd 100644
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -54,44 +54,31 @@ static void __iomem * __init earlycon_map(unsigned long 
> paddr, size_t size)
>   return base;
>  }
>  
> -static int __init parse_options(struct earlycon_device *device,
> - char *options)
> +static int __init parse_options(struct earlycon_device *device, char 
> *options)
>  {
>   struct uart_port *port = >port;
> - int mmio, mmio32, length;
> + int length;
>   unsigned long addr;
>  
> - if (!options)
> - return -ENODEV;
> + if (uart_parse_earlycon(options, >iotype, , ))
> + return -EINVAL;
>  
> - mmio = !strncmp(options, "mmio,", 5);
> - mmio32 = !strncmp(options, "mmio32,", 7);
> - if (mmio || mmio32) {
> - port->iotype = (mmio ? UPIO_MEM : UPIO_MEM32);
> - options += mmio ? 5 : 7;
> - addr = simple_strtoul(options, NULL, 0);
> + switch (port->iotype) {
> + case UPIO_MEM32:
> + port->regshift = 2; /* fall-through */
> + case UPIO_MEM:
>   port->mapbase = addr;
> - if (mmio32)
> - port->regshift = 2;
> - } else if (!strncmp(options, "io,", 3)) {
> - port->iotype = UPIO_PORT;
> - options += 3;
> - addr = simple_strtoul(options, NULL, 0);
> + break;
> + case UPIO_PORT:
>   port->iobase = addr;
> - mmio = 0;
> - } else if (!strncmp(options, "0x", 2)) {
> - port->iotype = UPIO_MEM;
> - addr = simple_strtoul(options, NULL, 0);
> - port->mapbase = addr;
> - } else {
> + break;
> + default:
>   return -EINVAL;
>   }
>  
>   port->uartclk = BASE_BAUD * 16;
>  
> - options = strchr(options, ',');
>   if (options) {
> - options++;
>   device->baud = simple_strtoul(options, NULL, 0);
>   length = min(strcspn(options, " ") + 1,
>(size_t)(sizeof(device->options)));
> @@ -100,7 +87,7 @@ static int __init parse_options(struct earlycon_device 
> *device,
>  
>   if (port->iotype == UPIO_MEM || port->iotype == UPIO_MEM32)
>   pr_info("Early serial console at MMIO%s 0x%llx (options 
> '%s')\n",
> - mmio32 ? "32" : "",
> + (port->iotype == UPIO_MEM32) ? "32" : "",
>   (unsigned long long)port->mapbase,
>   device->options);
>   else
> diff --git a/drivers/tty/serial/serial_core.c 
> b/drivers/tty/serial/serial_core.c
> index 6a1055a..3f823c26 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -1810,6 +1810,52 @@ uart_get_console(struct uart_port *ports, int nr, 
> struct console *co)
>  }
>  
>  /**
> + *   uart_parse_earlycon - Parse earlycon options
> + *   @p:   ptr to 2nd field (ie., just beyond ',')
> + *   @iotype:  ptr for decoded iotype (out)
> + *   @addr:ptr for decoded mapbase/iobase (out)
> + *   @options: ptr for  field; NULL if not present (out)
> + *
> + *   Decodes earlycon kernel command line parameters of the form
> + *  earlycon=,io|mmio|mmio32,,
> + *  console=,io|mmio|mmio32,,
> + *
> + *   The optional form
> + *  earlycon=,0x,
> + *  console=,0x,
> + *   is also accepted; the returned @iotype will be UPIO_MEM.
> + *
> + *   Returns 0 on success or -EINVAL on failure
> + */
> +int uart_parse_earlycon(char *p, unsigned char *iotype, unsigned long *addr,
> + char **options)
> +{
> + if (strncmp(p, "mmio,", 5) == 0) {
> + *iotype = UPIO_MEM;
> + p += 5;
> + } else if (strncmp(p, "mmio32,", 7) == 0) {
> + *iotype = UPIO_MEM32;
> + p += 7;
> + } else if (strncmp(p, "io,", 3) == 0) {
> + *iotype = UPIO_PORT;
> + p += 3;
> + } else if (strncmp(p, "0x", 2) == 0) {
> + *iotype = UPIO_MEM;
> + } else {
> + return -EINVAL;
> + }
> +
> + *addr = simple_strtoul(p, NULL, 

Re: [Linaro-acpi] [PATCH v3 3/9] ACPI: clean up checkpatch warnings for various bits of syntax

[Hanjun Guo]

On 2015年02月25日 08:36, al.st...@linaro.org wrote:

From: Al Stone

In preparation for later splitting out some of the arch-dependent code from
osl.c, clean up a bunch of warnings for odd bits of syntax:

-- remove CVS keyword markers
-- remove a space from between a function name and an opening parenthesis
-- clean up all but one line > 80 characters (one just looks silly if you
   make it less than 80)
-- add blank lines after declarations in functions
-- remove extraneous braces ({})

Signed-off-by: Al Stone


Reviewd-by: Hanjun Guo 

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86, boot: Allow 64bit EFI kernel to be loaded above 4G

[Matt Fleming]

On Tue, 24 Feb, at 04:31:27PM, Yinghai Lu wrote:
> On Tue, Feb 24, 2015 at 1:55 PM, Matt Fleming  
> wrote:
> > On Sun, 22 Feb, at 07:43:48PM, Yinghai Lu wrote:
> >> +Field name:  ext_code32_start
> >> +Type:modify (optional, reloc)
> >> +Offset/size: 0x268/4
> >> +Protocol:2.14+
> >> +
> >> +  This field is the upper 32bits of load address when EFI 64bit kernel
> >> +  is loaded above 4G. And it is used with code32_start to compare to
> >> +  pref_address to decide if kernel need to be relocated further.
> >
> > I think we can delete the second sentence.
> >
> > But these are minimal changes and I'm happy to fix them up when applying
> > this patch if that's OK?
> 
> Sure. Please go ahead.

Applied, thanks Yinghai.

-- 
Matt Fleming, 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] x86, boot: Allow 64bit EFI kernel to be loaded above 4G

[Matt Fleming]

On Wed, 25 Feb, at 11:31:32AM, Ingo Molnar wrote:
> 
> * Matt Fleming  wrote:
> 
> > On Sun, 22 Feb, at 07:43:48PM, Yinghai Lu wrote:
> > > Index: linux-2.6/arch/x86/boot/header.S
> > > ===
> > > --- linux-2.6.orig/arch/x86/boot/header.S
> > > +++ linux-2.6/arch/x86/boot/header.S
> > > @@ -301,7 +301,7 @@ _start:
> > >   # Part 2 of the header, from the old setup.S
> > >  
> > >   .ascii  "HdrS"  # header signature
> > > - .word   0x020d  # header version number (>= 0x0105)
> > > + .word   0x020e  # header version number (>= 0x0105)
> > >   # or else old loadlin-1.5 will fail)
> > >   .globl realmode_swtch
> > >  realmode_swtch:  .word   0, 0# default_switch, SETUPSEG
> > > @@ -449,6 +449,7 @@ pref_address: .quad LOAD_PHYSICAL_ADDR
> > >  #endif
> > >  init_size:   .long INIT_SIZE # kernel initialization 
> > > size
> > >  handover_offset: .long 0 # Filled in by build.c
> > > +ext_code32_start:.long 0 # werid one!
> >   
> > How about a comment like, "# Upper 32-bits of code32_start" ?
> 
> Also, in the Linux kernel we should not go about inventing 
> new English words like 'werid', right?

Yeah, my intention is to replace "werid one" with the comment I
suggested above.

-- 
Matt Fleming, 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] ARM: Don't use complete() during __cpu_die

[Russell King - ARM Linux]

On Thu, Feb 05, 2015 at 04:11:00PM +, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> > Works for me, assuming no hidden uses of RCU in the IPI code.  ;-)
> 
> Sigh... I kind'a new it wouldn't be this simple.  The gic code which
> actually raises the IPI takes a raw spinlock, so it's not going to be
> this simple - there's a small theoretical window where we have taken
> this lock, written the register to send the IPI, and then dropped the
> lock - the update to the lock to release it could get lost if the
> CPU power is quickly cut at that point.
> 
> Also, we _do_ need the second cache flush in place to ensure that the
> unlock is seen to other CPUs.

It's time to start discussing this problem again now that we're the
other side of the merge window.

I've been thinking about the lock in the GIC code.  Do we actually need
this lock in gic_raise_softirq(), or could we move this lock into the
higher level code?

Let's consider the bL switcher.

I think the bL switcher is racy wrt CPU hotplug at the moment.  What
happens if we're sleeping in wait_for_completion(_alive) and
CPU hotplug unplugs the CPU outgoing CPU?  What protects us against
this scenario?  I can't see anything in bL_switch_to() which ensures
that CPU hotplug can't run.

Let's assume that this rather glaring bug has been fixed, and that CPU
hotplug can't run in parallel with the bL switcher (and hence
gic_migrate_target() can't run concurrently with a CPU being taken
offline.)

If we have that guarantee, then we don't need to take a lock when sending
the completion IPI - we would know that while a CPU is being taken down,
the bL switcher could not run.  What we now need is a lock-less way to
raise an IPI.

Now, is the locking between the normal IPI paths and the bL switcher
something that is specific to the interrupt controller, or should generic
code care about it?  I think it's something generic code should care about
- and I believe that would make life a little easier.

The current bL switcher idea is to bring the new CPU up, disable IRQs
and FIQs on the outgoing CPU, change the IRQ/IPI targets, then read
any pending SGIs and raise them on the new CPU.  But what about any
pending SPIs?  These look like they could be lost.

How about this for an idea instead - the bL switcher code:

- brings the new CPU online.
- disables IRQs and FIQs.
- takes the IPI lock, which prevents new IPIs being raised.
- re-targets IRQs and IPIs onto the new CPU.
- releases the IPI lock.
- re-enables IRQs and FIQs.
- polls the IRQ controller to wait for any remaining IRQs and IPIs
  to be delivered.
- re-disables IRQs and FIQs (which shouldn't be received anyway since
  they're now targetting the new CPU.)
- shuts down the tick device.
- completes the switch

What this means is that we're not needing to have complex code in the
interrupt controllers to re-raise interrupts on other CPUs, and we
don't need a lock in the interrupt controller code synchronising IPI
raising with the bL switcher.

I'd also suggest is that this IPI lock should _not_ be a spinlock - it
should be a read/write spin lock - it's perfectly acceptable to have
multiple CPUs raising IPIs to each other, but it is not acceptable to
have any CPU raising an IPI when the bL switcher is modifying the IRQ
targets.  That fits the rwlock semantics.

What this means is that gic_raise_softirq() should again become a lock-
less function, which opens the door to using an IPI to complete the
CPU hot-unplug operation cleanly.

Thoughts (especially from Nico)?

-- 
FTTC broadband for 0.8mile line: currently at 10.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: [PATCH v3 2/9] ACPI: clear up warnings on use of printk reported by checkpatch.pl

[Hanjun Guo]

On 2015年02月25日 08:36, al.st...@linaro.org wrote:

From: Al Stone 

In preparation for later splitting out some of the arch-dependent code from
osl.c, clear up all the warnings reported by checkpatch.pl where pr_* should
be used instead of printk(KERN_* ...).

Signed-off-by: Al Stone 
---
  drivers/acpi/osl.c | 46 +++---
  1 file changed, 19 insertions(+), 27 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 1dc3a3b..865317c 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -141,7 +141,7 @@ static u32 acpi_osi_handler(acpi_string interface, u32 
supported)
  {
if (!strcmp("Linux", interface)) {

-   printk_once(KERN_NOTICE FW_BUG PREFIX
+   pr_notice_once(FW_BUG PREFIX


I think you can use pr_fmt() and then remove all the PREFIX in
this patch, just

#define pr_fmt(fmt) "ACPI: " fmt

in top of this file before all #includes.

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: DMA-API backtrace from rtsx_usb_ms driver

[Roger Tseng]

On Thu, 2015-02-19 at 11:58 -0500, Josh Boyer wrote:
> Hi All,
> 
> We've had a few bug reports with the stack trace below.  It looks like
> the ms_read_bytes and ms_write_bytes functions in
> drivers/memstick/host/rtsx_usb_mc.c are using a stack variable when
> calling rtsx_usb_ep0_read_register.  That eventually gets to the
> DMA-API debugging checks, which throws the warning backtrace.
> 
> A typical fix is to replace:
> 
> u8 val;
> 
> rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, );
> dev_dbg(ms_dev(host), "MS_TRANS_CFG: 0x%02x\n", val);
> 
> with something like:
> 
> u8 val = kzalloc(sizeof(u8), GFP_KERNEL);
> if (!val) return -ENOMEM;
> 
> rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, );
> dev_dbg(ms_dev(host), "MS_TRANS_CFG: 0x%02x\n", val);
> 
> <>
> kfree(val);
> 
> However, I'm not familiar enough with this driver to know if this
> function is called frequently in an IRQ handler, etc.  If the above
> pseudo code looks sufficient, I can come up with a patch.
> 
Thanks for reporting this.

rtsx_usb_ep0_read_register() is not called in any interrupt context. It 
is a high-priority(control pipe) but less used alternative to
communicate with device. It is primarily for error handling.

I'll fix it inside rtsx_usb_ep0_read_register() itself by a DMA'able
double buffer because it could be called somewhere else(e.g. mmc side).

> WARNING: CPU: 1 PID: 25 at lib/dma-debug.c:1166 check_for_stack+0x96/0xe0()
> ehci-pci :00:1a.0: DMA-API: device driver maps memory from stack
> [addr=8801199e3cef]
> Modules linked in: rtsx_usb_ms arc4 memstick intel_rapl iosf_mbi
> rtl8192ce snd_hda_codec_hdmi snd_hda_codec_realtek
> snd_hda_codec_generic snd_hda_intel rtl_pci rtl8192c_common
> snd_hda_controller x86_pkg_temp_thermal snd_hda_codec rtlwifi mac80211
> coretemp kvm_intel kvm iTCO_wdt snd_hwdep snd_seq snd_seq_device
> crct10dif_pclmul iTCO_vendor_support sparse_keymap cfg80211
> crc32_pclmul snd_pcm crc32c_intel ghash_clmulni_intel rfkill i2c_i801
> snd_timer shpchp snd serio_raw mei_me lpc_ich soundcore mei tpm_tis
> tpm wmi nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915
> rtsx_usb_sdmmc mmc_core 8021q uas garp stp i2c_algo_bit llc mrp
> drm_kms_helper usb_storage drm rtsx_usb mfd_core r8169 mii video
> CPU: 1 PID: 25 Comm: kworker/1:2 Not tainted 3.20.0-0.rc0.git7.3.fc22.x86_64 
> #1
> Hardware name: WB WB-B06211/WB-B0621, BIOS EB062IWB V1.0 12/12/2013
> Workqueue: events rtsx_usb_ms_handle_req [rtsx_usb_ms]
>   3d188e66 8801199e3808 8187642b
>   8801199e3860 8801199e3848 810ab39a
>  8801199e3864 8801199e3cef 880119b57098 880119b37320
> Call Trace:
>  [] dump_stack+0x4c/0x65
>  [] warn_slowpath_common+0x8a/0xc0
>  [] warn_slowpath_fmt+0x55/0x70
>  [] ? _raw_spin_unlock_irqrestore+0x36/0x70
>  [] check_for_stack+0x96/0xe0
>  [] debug_dma_map_page+0x104/0x150
>  [] usb_hcd_map_urb_for_dma+0x646/0x790
>  [] usb_hcd_submit_urb+0x1d5/0xa90
>  [] ? mark_held_locks+0x7f/0xc0
>  [] ? mark_held_locks+0x7f/0xc0
>  [] ? lockdep_init_map+0x65/0x5d0
>  [] usb_submit_urb+0x42e/0x5f0
>  [] usb_start_wait_urb+0x77/0x190
>  [] ? __kmalloc+0x205/0x2d0
>  [] usb_control_msg+0xdc/0x130
>  [] rtsx_usb_ep0_read_register+0x59/0x70 [rtsx_usb]
>  [] ? rtsx_usb_get_rsp+0x41/0x50 [rtsx_usb]
>  [] rtsx_usb_ms_handle_req+0x7ce/0x9c5 [rtsx_usb_ms]
>  [] ? process_one_work+0x19b/0x860
>  [] process_one_work+0x232/0x860
>  [] ? process_one_work+0x19b/0x860
>  [] ? worker_thread+0xda/0x470
>  [] worker_thread+0x53/0x470
>  [] ? process_one_work+0x860/0x860
>  [] kthread+0x104/0x120
>  [] ? local_clock+0x25/0x30
>  [] ? kthread_create_on_node+0x250/0x250
>  [] ret_from_fork+0x7c/0xb0
>  [] ? kthread_create_on_node+0x250/0x250
> 
> josh
> 
> --Please consider the environment before printing this e-mail.

-- 
Best regards,
Roger Tseng

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Borislav Petkov]

On Wed, Feb 25, 2015 at 12:38:20PM +, Kweh, Hock Leong wrote:
> The reason we use this interface for efi capsule is that efi capsule
> support multi binaries to be uploaded and each binary file name
> can be different.

So you can write the file path to a second file and reload then, once
per file.

Alternatively, you can combine all the files into a cpio archive like
we do with the microcode loader too, and let the kernel parse the cpio
archive.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH 2/4] x86: get rid of KERNEL_STACK_OFFSET

[Denys Vlasenko]

On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar  wrote:
>
> * Denys Vlasenko  wrote:
>
>> PER_CPU_VAR(kernel_stack) was set up in a way where it
>> points five stack slots below the top of stack.
>>
>> Presumably, it was done to avoid one "sub $5*8,%rsp" in
>> syscall/sysenter code paths, where iret frame needs to be
>> created by hand.
>>
>> Ironically, none of them benefit from this optimization,
>> since all of them need to allocate additional data on
>> stack (struct pt_regs), so they still have to perform
>> subtraction.
>
> Well, the original idea of percpu::kernel_stack was that of
> an optimization of the 64-bit system_call() path: to set up
> RSP as it has to be before we call into system calls.
>
> This optimization has bitrotted away: because these days
> the first SAVE_ARGS in the 64-bit entry path modifies RSP
> as well, undoing the optimization.

Yes, I figured this is how it was supposed to work.

> But the fix should be to not touch RSP in SAVE_ARGS, to
> keep percpu::kernel_stack as an optimized entry point -
> with KERNEL_STACK_OFFSET pointing to.
>
> So NAK - this should be fixed for real.

IOW, the proposal is to set KERNEL_STACK_OFFSET
to SIZEOF_PTREGS. I can do that.

However.

There is an ortogonal idea we were discussing: to save
registers and construct iret frame using PUSH insns, not MOVs.
IIRC Andy and Linus liked it. I am ambivalent: the code will be smaller,
but might get slower (at least on some CPUs).
If we go that way, we will require KERNEL_STACK_OFFSET = 0
(IOW: the current patch).

The decision on how exactly we should fix KERNEL_STACK_OFFSET
(set it to SIZEOF_PTREGS or to zero) depends on whether
we switch to using PUSHes, or not. What do you think?

-- 
vda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/9] ACPI: fix all errors reported by cleanpatch.pl in osl.c

[Hanjun Guo]

On 2015年02月25日 08:36, al.st...@linaro.org wrote:

From: Al Stone 

In preparation for later splitting out some of the arch-dependent code from
osl.c, clean up the errors reported by checkpatch.pl.  They fell into these
classes:

-- remove the FSF address from the GPL notice
-- "foo * bar" should be "foo *bar" (and the ** variation of same)
-- a return is not a function, so parentheses are not required.

Signed-off-by: Al Stone 


Reviewd-by: Hanjun Guo 

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/6] the big khugepaged redesign

[Vlastimil Babka]

On 02/24/2015 12:24 PM, Andrea Arcangeli wrote:

Hi everyone,


Hi,


On Tue, Feb 24, 2015 at 11:32:30AM +0100, Vlastimil Babka wrote:

I would suspect mmap_sem being held during whole THP page fault
(including the needed reclaim and compaction), which I forgot to mention
in the first e-mail - it's not just the problem page fault latency, but
also potentially holding back other processes, why we should allow
shifting from THP page faults to deferred collapsing.
Although the attempts for opportunistic page faults without mmap_sem
would also help in this particular case.

Khugepaged also used to hold mmap_sem (for read) during the allocation
attempt, but that was fixed since then. It could be also zone lru_lock
pressure.


I'm traveling and I didn't have much time to read the code yet but if
I understood well the proposal, I've some doubt boosting khugepaged
CPU utilization is going to provide a better universal trade off. I
think the low overhead background scan is safer default.


Making the background scanning more efficient should be win in any case.


If we want to do more async background work and less "synchronous work
at fault time", what may be more interesting is to generate
transparent hugepages in the background and possibly not to invoke
compaction (or much compaction) in the page faults.


Steps in that direction are in fact part of the patchset :)


I'd rather move compaction to a background kernel thread, and to
invoke compaction synchronously only in khugepaged. I like it more if
nothing else because it is a kind of background load that can come to
a full stop, once enough THP have been created.


Yes, we agree here.


Unlike khugepaged that
can never stop to scan and it better be lightweight kind of background
load, as it'd be running all the time.


IMHO it doesn't hurt if the scanning can focus on mm's where it's more 
likely to succeed, and tune its activity according to how successful it 
is. Then you don't need to achieve the "lightweightness" by setting the 
existing tunables to very long sleeps and very short scans, which 
increases the delay until the good collapse candidates are actually 
found by khugepaged.



Creating THP through khugepaged is much more expensive than creating
them on page faults. khugepaged will need to halt the userland access
on the range once more and it'll have to copy the 2MB.


Well, Mel also suggested another thing that I didn't mention yet - 
in-place collapsing, where the base pages would be allocated on page 
faults with such layout to allow later collapse without the copying. I 
think that Kiryl's refcounting changes could potentially allow this by 
allocating a hugepage, but mapping it using pte's so it could still be 
tracked which pages are actually accessed, and from which nodes. If 
after some time it looks like a good candidate, just switch it to pmd, 
otherwise break the hugepage and free the unused base pages.



Overall I agree with Andi we need more data collected for various
workloads before embarking into big changes, at least so we can proof
the changes to be beneficial to those workloads.


OK. I mainly wanted to stir some discussion at this point.


I would advise not to make changes for app that are already the
biggest users ever of hugetlbfs (like Oracle). Those already are
optimized by other means. THP target are apps that have several
benefit in not ever using hugetlbfs, so apps that are more dynamic
workloads that don't fit well with NUMA hard pinning with numactl or
other static placements of memory and CPU.

There are also other corner cases to optimize, that have nothing to do
with khugepaged nor compaction: for example redis has issues in the
way it forks() and then uses the child memory as a snapshot while the
parent keeps running and writing to the memory. If THP is enabled, the
parent that writes to the memory will allocate and copy 2MB objects
instead of 4k objects. That means more memory utilization but
especially the problem are those copy_user of 2MB instead of 4k hurting
the parent runtime.

For redis we need a more finegrined thing than MADV_NOHUGEPAGE. It
needs a MADV_COW_NOHUGEPAGE (please think at a better name) that will
only prevent THP creation during COW faults but still maximize THP
utilization for every other case. Once such a madvise will become
available, redis will run faster with THP enabled (currently redis
recommends THP disabled because of the higher latencies in the 2MB COW
faults while the child process is snapshotting). When the snapshot is
finished and the child quits, khugepaged will recreate THP for those
fragmented cows.


Hm sounds like Kiryl's patchset could also help here? In parent, split 
only the pmd and do cow on 4k pages, while child keeps the whole THP.
Later khugepaged can recreate THP for the parent, as you say. That 
should be better default behavior than the current 2MB copies, not just 
for redis? And no new madvise needed. Or maybe with MADV_HUGEPAGE you 
can assume that the 

Re: [PATCH] iommu/io-pgtable-arm: fix self-test WARNs on i386

[Joerg Roedel]

On Mon, Feb 16, 2015 at 06:38:20PM +, Will Deacon wrote:
> Various build/boot bots have reported WARNs being triggered by the ARM
> iopgtable LPAE self-tests on i386 machines.
> 
> This boils down to two instances of right-shifting a 32-bit unsigned
> long (i.e. an iova) by more than the size of the type. On 32-bit ARM,
> this happens to give us zero, hence my testing didn't catch this
> earlier.
> 
> This patch fixes the issue by using DIV_ROUND_UP and explicit case to
> to avoid the erroneous shifts.
> 
> Reported-by: Fengguang Wu 
> Reported-by: Huang Ying 
> Signed-off-by: Will Deacon 
> ---
> 
> Joerg -- please can you apply this as a fix for 3.20?

Applied to my fixes branch, thanks Will.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Kweh, Hock Leong]

> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Wednesday, February 25, 2015 7:48 PM
> 
> On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote:
> 
> So this sounds pretty overengineered for no reason, or maybe I'm missing
> the reason.
> 
> If I had to give an example from the microcode loader, what we do there
> is put the microcode in /lib/firmware/... and do
> 
> echo 1 > /sys/devices/system/cpu/microcode/reload
> 
> which goes and calls reload_store() in
> arch/x86/kernel/cpu/microcode/core.c which grabs a mutex, disables CPU
> hotplug, etc, etc...
> 
> And this mechanism is as simple as it can get. Maybe capsules can be
> loaded like that too?
> 
> Error code can be propagated too, if needed, of course.
> 
> --
> Regards/Gruss,
> Boris.
> 
> ECO tip #101: Trim your mails when you reply.
> --

Hi Boris,

The reason we use this interface for efi capsule is that efi capsule
support multi binaries to be uploaded and each binary file name
can be different.


Regards,
Wilson

[PATCH 5/7 v3] x86: get rid of KERNEL_STACK_OFFSET

[Denys Vlasenko]

PER_CPU_VAR(kernel_stack) was set up in a way where it points
five stack slots below the top of stack.

Presumably, it was done to avoid one "sub $5*8,%rsp"
in syscall/sysenter code paths, where iret frame needs to be
created by hand.

Ironically, none of them benefit from this optimization,
since all of them need to allocate additional data on stack
(struct pt_regs), so they still have to perform subtraction.
And ia32_sysenter_target even needs to *undo* this optimization:
it constructs iret stack with pushes instead of movs,
so it needs to start right at the top.

This patch eliminates KERNEL_STACK_OFFSET.
PER_CPU_VAR(kernel_stack) now points directly to top of stack.
pt_regs allocations are adjusted to allocate iret frame as well.

Semi-mysterious expressions THREAD_INFO(%rsp,RIP) - "why RIP??"
are now replaced by more logical THREAD_INFO(%rsp,SIZEOF_PTREGS) -
"rsp is SIZEOF_PTREGS bytes below the top, calculate
thread_info's address using that information"

Net result in code is that one instruction is eliminated,
and constants in several others have changed.

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Steven Rostedt 
CC: Ingo Molnar 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Oleg Nesterov 
CC: Frederic Weisbecker 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---

Changes since v1: BUG_ON fix in traps.c
Changes since v2: removed "5 slots (iret frame) are preallocated" comment

 arch/x86/ia32/ia32entry.S  | 35 +--
 arch/x86/include/asm/thread_info.h |  8 +++-
 arch/x86/kernel/cpu/common.c   |  2 +-
 arch/x86/kernel/entry_64.S |  9 -
 arch/x86/kernel/process_32.c   |  3 +--
 arch/x86/kernel/process_64.c   |  3 +--
 arch/x86/kernel/smpboot.c  |  3 +--
 arch/x86/kernel/traps.c|  3 ++-
 arch/x86/xen/smp.c |  3 +--
 9 files changed, 31 insertions(+), 38 deletions(-)

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index ed97463..eb9d690 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -114,7 +114,6 @@ ENTRY(ia32_sysenter_target)
CFI_REGISTERrsp,rbp
SWAPGS_UNSAFE_STACK
movqPER_CPU_VAR(kernel_stack), %rsp
-   addq$(KERNEL_STACK_OFFSET),%rsp
/*
 * No need to follow this irqs on/off section: the syscall
 * disabled irqs, here we enable it straight after entry:
@@ -128,7 +127,7 @@ ENTRY(ia32_sysenter_target)
CFI_REL_OFFSET rsp,0
pushfq_cfi
/*CFI_REL_OFFSET rflags,0*/
-   movl
TI_sysenter_return+THREAD_INFO(%rsp,3*8-KERNEL_STACK_OFFSET),%r10d
+   movlTI_sysenter_return+THREAD_INFO(%rsp,3*8),%r10d
CFI_REGISTER rip,r10
pushq_cfi $__USER32_CS
/*CFI_REL_OFFSET cs,0*/
@@ -160,8 +159,8 @@ ENTRY(ia32_sysenter_target)
jnz sysenter_fix_flags
 sysenter_flags_fixed:
 
-   orl $TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP)
-   testl   $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP)
+   orl $TS_COMPAT,TI_status+THREAD_INFO(%rsp,SIZEOF_PTREGS)
+   testl   
$_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
CFI_REMEMBER_STATE
jnz  sysenter_tracesys
cmpq$(IA32_NR_syscalls-1),%rax
@@ -178,10 +177,10 @@ sysenter_dispatch:
movq%rax,RAX(%rsp)
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
-   testl   $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP)
+   testl   $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
jnz sysexit_audit
 sysexit_from_sys_call:
-   andl$~TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP)
+   andl$~TS_COMPAT,TI_status+THREAD_INFO(%rsp,SIZEOF_PTREGS)
/* clear IF, that popfq doesn't enable interrupts early */
andl$~0x200,EFLAGS(%rsp)
movlRIP(%rsp),%edx  /* User %eip */
@@ -226,7 +225,7 @@ sysexit_from_sys_call:
.endm
 
.macro auditsys_exit exit
-   testl $(_TIF_ALLWORK_MASK & 
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP)
+   testl $(_TIF_ALLWORK_MASK & 
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
jnz ia32_ret_from_sys_call
TRACE_IRQS_ON
ENABLE_INTERRUPTS(CLBR_NONE)
@@ -241,7 +240,7 @@ sysexit_from_sys_call:
movl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),%edi
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
-   testl %edi,TI_flags+THREAD_INFO(%rsp,RIP)
+   testl %edi,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
jz \exit
CLEAR_RREGS
jmp int_with_check
@@ -263,7 +262,7 @@ sysenter_fix_flags:
 
 sysenter_tracesys:
 #ifdef CONFIG_AUDITSYSCALL
-   testl   $(_TIF_WORK_SYSCALL_ENTRY & 
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP)
+   testl   $(_TIF_WORK_SYSCALL_ENTRY & 
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
  

Re: [PATCH 0/7] New eFuse subsystem

[Ezequiel Garcia]

On 02/25/2015 09:02 AM, Maxime Ripard wrote:
> Hi Ezequiel,
> 
> On Wed, Feb 25, 2015 at 08:45:12AM -0300, Ezequiel Garcia wrote:
>> This patchset introduces a new driver subsystem, meant to support eFuse
>> (alias OTP, one-time-programmable) devices.
>>
>> The motivation behind this work is to have a common place for drivers
>> that are currently more or less scattered: the tegra efuses are in
>> drivers/soc/ and the sunxi efuses in drivers/misc/eeprom.
>>
>> For now, there's no proposal for a generic efuse API. Instead, we simply
>> group the drivers together.
>>
>> This patchset is the result of the initial submission for IMG Pistachio
>> eFuse support [1]. Our first proposal was to follow the Tegra efuse, and
>> put the Pistachio efuse in drivers/soc. After some discussion we finally
>> agreed [2] to first create an efuse directoy, and then put all efuse drivers
>> in it.
>>
>> As always, all comments are welcome!
>>
>> [1] http://www.spinics.net/lists/devicetree/msg59246.html
>> [2] http://www.spinics.net/lists/arm-kernel/msg389325.html
> 
> Have you looked at the EEPROM framework currently in discussions? The
> two seems to be covering pretty much the same use cases.
> 

Nope, I was obviously unaware of that. Guess we'll wait until the
discussion is settled and use that framework.

Thanks!
-- 
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vfs: avoid recopying filename in getname_flags

[Boqun Feng]

In the current implementation of getname_flags, filename in the
user-space will be recopied if it takes more space that
EMBEDDED_NAME_MAX, however, at this moment, EMBEDDED_NAME_MAX bytes of
the filename are already copied into kernel space, the only reason why
the recopy is needed is that "kname" needs to be relocated.

And the recopy can be avoided if we change the memory layout of the
"names_cache" allocation. By putting the struct "filename" at the tail
of the allocation instead of the head, relocation of kname is avoided.

Once putting the struct at the tail, each byte in the user space will be
copied only one time, so the recopy is avoided and code is more clear.

Of course, other functions aware of the layout of the names_cache
allocation, i.e., getname_kernel and putname also need to be modified to
adapt to the new layout.

This patch is based on v4.0-rc1.

Cc: Al Viro 
Cc: Paul Moore 
Signed-off-by: Boqun Feng 
---
 fs/namei.c | 50 +++---
 1 file changed, 31 insertions(+), 19 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index c83145a..3be372b 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -133,21 +133,20 @@ getname_flags(const char __user *filename, int flags, int 
*empty)
if (result)
return result;
 
-   result = __getname();
-   if (unlikely(!result))
+   kname = __getname();
+   if (unlikely(!kname))
return ERR_PTR(-ENOMEM);
-   result->refcnt = 1;
 
/*
 * First, try to embed the struct filename inside the names_cache
 * allocation
 */
-   kname = (char *)result + sizeof(*result);
+   result = (struct filename *)(kname + EMBEDDED_NAME_MAX);
result->name = kname;
result->separate = false;
+   result->refcnt = 1;
max = EMBEDDED_NAME_MAX;
 
-recopy:
len = strncpy_from_user(kname, filename, max);
if (unlikely(len < 0)) {
err = ERR_PTR(len);
@@ -157,23 +156,34 @@ recopy:
/*
 * Uh-oh. We have a name that's approaching PATH_MAX. Allocate a
 * separate struct filename so we can dedicate the entire
-* names_cache allocation for the pathname, and re-do the copy from
+* names_cache allocation for the pathname, and continue the copy from
 * userland.
 */
-   if (len == EMBEDDED_NAME_MAX && max == EMBEDDED_NAME_MAX) {
-   kname = (char *)result;
-
+   if (len == EMBEDDED_NAME_MAX) {
result = kzalloc(sizeof(*result), GFP_KERNEL);
if (!result) {
err = ERR_PTR(-ENOMEM);
-   result = (struct filename *)kname;
+   result = (struct filename *)(kname + EMBEDDED_NAME_MAX);
goto error;
}
result->name = kname;
result->separate = true;
result->refcnt = 1;
-   max = PATH_MAX;
-   goto recopy;
+   max = PATH_MAX - EMBEDDED_NAME_MAX;
+   /* we can't simply add the number of rest chars we copy to len,
+* since strncpy_from_user may return negative to indicate
+* something is wrong, so we do the addition later, after
+* strncpy_from_user succeeds, and we know we already copy
+* EMBEDDED_NAME_MAX chars.
+*/
+   len = strncpy_from_user(kname + EMBEDDED_NAME_MAX,
+   filename + EMBEDDED_NAME_MAX, max);
+
+   if (unlikely(len < 0)) {
+   err = ERR_PTR(len);
+   goto error;
+   }
+   len += EMBEDDED_NAME_MAX;
}
 
/* The empty path is special. */
@@ -209,28 +219,30 @@ struct filename *
 getname_kernel(const char * filename)
 {
struct filename *result;
+   char *kname;
int len = strlen(filename) + 1;
 
-   result = __getname();
-   if (unlikely(!result))
+   kname = __getname();
+   if (unlikely(!kname))
return ERR_PTR(-ENOMEM);
 
if (len <= EMBEDDED_NAME_MAX) {
-   result->name = (char *)(result) + sizeof(*result);
+   result = (struct filename *)(kname + EMBEDDED_NAME_MAX);
+   result->name = kname;
result->separate = false;
} else if (len <= PATH_MAX) {
struct filename *tmp;
 
tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
if (unlikely(!tmp)) {
-   __putname(result);
+   __putname(kname);
return ERR_PTR(-ENOMEM);
}
-   tmp->name = (char *)result;
+   tmp->name = kname;
tmp->separate = true;
result = tmp;
} else {
-   __putname(result);
+   __putname(kname);
return 

Re: doubt about sm7xxfb

[Sudip Mukherjee]

On Wed, Feb 11, 2015 at 02:33:51PM +0800, Greg Kroah-Hartman wrote:
> On Wed, Feb 11, 2015 at 11:58:18AM +0530, Sudip Mukherjee wrote:
> 
> Ok, that makes sense, I was thinking this was a "new" driver, instead of
> a vendor driver crud.
Hi Greg,
The SM750 driver is almost ready for staging, it now compiles without any error 
with today's linux-next and is working properly , ok,  there are lots of 
warning when compiling and checkpatch will give lots of complaints.
But in total it is creating 34 files and the size of the patch is 360K. So 
should i send it with mail, just the way we send other patches or should i send 
you a git pull request?

regards
sudip

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

Re: [PATCH 3/7] drivers: Introduce new eFuse subsystem stub

[Stefan Wahren]

Hi,

[adding devicetree list]

Am 25.02.2015 um 12:45 schrieb Ezequiel Garcia:
> This commit introduces a new eFuse subsystem stub to hold all the eFuse-like
> device drivers. This will be used to host the currently supported Tegra
> eFuse driver, and will allow to add support for other platforms as well.

as i mentioned in the old discussion it would be nice to keep drivers
and devicetree binding documentation consistent.

So how about renaming?

Documentation/devicetree/bindings/fuse/ ->
Documentation/devicetree/bindings/efuse/

Best regards
Stefan




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

Re: [PATCH 1/3] x86: Move msr accesses out of line

[Peter Zijlstra]

On Mon, Feb 23, 2015 at 09:43:40AM -0800, Andi Kleen wrote:
> On Mon, Feb 23, 2015 at 06:04:36PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 20, 2015 at 05:38:55PM -0800, Andi Kleen wrote:
> > 
> > > This patch moves the MSR functions out of line. A MSR access is typically
> > > 40-100 cycles or even slower, a call is a few cycles at best, so the
> > > additional function call is not really significant.
> > 
> > If I look at the below PDF a CALL+PUSH EBP+MOV RSP,RBP+ ... +POP+RET
> > ends up being 5+1.5+0.5+ .. + 1.5+8 = 16.5 + .. cycles.
> 
> You cannot just add up the latency cycles. The CPU runs all of this 
> in parallel. 
> 
> Latency cycles would only be interesting if these instructions were
> on the critical path for computing the result, which they are not. 
> 
> It should be a few cycles overhead.

I thought that since CALL touches RSP, PUSH touches RSP, MOV RSP,
(obviously) touches RSP, POP touches RSP and well, RET does too. There
were strong dependencies on the instructions and there would be little
room to parallelize things.

I'm glad you so patiently educated me on the wonders of modern
architectures and how it can indeed do all this in parallel.

Still, I wondered, so I ran me a little test. Note that I used a
serializing instruction (LOCK XCHG) because WRMSR is too.

I see a ~14 cycle difference between the inline and noinline version.

If I substitute the LOCK XCHG with XADD, I get to 1,5 cycles in
difference, so clearly there is some magic happening, but serializing
instructions wreck it.

Anybody can explain how such RSP deps get magiced away?

---

root@ivb-ep:~# cat call.c

#define __always_inline inline __attribute__((always_inline))
#define  noinline   __attribute__((noinline))

static int
#ifdef FOO
noinline
#else
__always_inline
#endif
xchg(int *ptr, int val)
{
asm volatile ("LOCK xchgl %0, %1\n"
: "+r" (val), "+m" (*(ptr))
: : "memory", "cc");
return val;
}

void main(void)
{
int val = 0, old;

for (int i = 0; i < 10; i++)
old = xchg(, i);
}

root@ivb-ep:~# gcc -std=gnu99 -O3 -fno-omit-frame-pointer -DFOO -o call call.c
root@ivb-ep:~# objdump -D call | awk '/<[^>]*>:/ {p=0} /:/ {p=1} 
/:/ {p=1} { if (p) print $0 }'
004003e0 :
  4003e0:   55  push   %rbp
  4003e1:   48 89 e5mov%rsp,%rbp
  4003e4:   53  push   %rbx
  4003e5:   31 db   xor%ebx,%ebx
  4003e7:   48 83 ec 18 sub$0x18,%rsp
  4003eb:   c7 45 e0 00 00 00 00movl   $0x0,-0x20(%rbp)
  4003f2:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
  4003f8:   48 8d 7d e0 lea-0x20(%rbp),%rdi
  4003fc:   89 de   mov%ebx,%esi
  4003fe:   83 c3 01add$0x1,%ebx
  400401:   e8 fa 00 00 00  callq  400500 
  400406:   81 fb 00 ca 9a 3b   cmp$0x3b9aca00,%ebx
  40040c:   75 ea   jne4003f8 
  40040e:   48 83 c4 18 add$0x18,%rsp
  400412:   5b  pop%rbx
  400413:   5d  pop%rbp
  400414:   c3  retq   

00400500 :
  400500:   55  push   %rbp
  400501:   89 f0   mov%esi,%eax
  400503:   48 89 e5mov%rsp,%rbp
  400506:   f0 87 07lock xchg %eax,(%rdi)
  400509:   5d  pop%rbp
  40050a:   c3  retq   
  40050b:   90  nop
  40050c:   90  nop
  40050d:   90  nop
  40050e:   90  nop
  40050f:   90  nop

root@ivb-ep:~# gcc -std=gnu99 -O3 -fno-omit-frame-pointer -o call-inline call.c
root@ivb-ep:~# objdump -D call-inline | awk '/<[^>]*>:/ {p=0} /:/ {p=1} 
/:/ {p=1} { if (p) print $0 }'
004003e0 :
  4003e0:   55  push   %rbp
  4003e1:   31 c0   xor%eax,%eax
  4003e3:   48 89 e5mov%rsp,%rbp
  4003e6:   c7 45 f0 00 00 00 00movl   $0x0,-0x10(%rbp)
  4003ed:   0f 1f 00nopl   (%rax)
  4003f0:   89 c2   mov%eax,%edx
  4003f2:   f0 87 55 f0 lock xchg %edx,-0x10(%rbp)
  4003f6:   83 c0 01add$0x1,%eax
  4003f9:   3d 00 ca 9a 3b  cmp$0x3b9aca00,%eax
  4003fe:   75 f0   jne4003f0 
  400400:   5d  pop%rbp
  400401:   c3  retq   

root@ivb-ep:~# perf stat -e "cycles:u" ./call

 Performance counter stats for './call':

36,309,274,162  cycles:u 

  10.561819310 seconds time elapsed

root@ivb-ep:~# perf stat -e "cycles:u" ./call-inline 

 

Re: [PATCH v4 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function

[Lukasz Majewski]

Hi Eduardo,

> On Wed, Feb 18, 2015 at 11:07:29AM +0100, Lukasz Majewski wrote:
> > Odroid U3 fan can work without being registered as OF cooling device
> > (with CONFIG_THERMAL_OF disabled).
> > In this situation it can be controlled via PWM entry at
> > /sys/class/hwmon/hwmon0/pwm1.
> > 
> > Therefore, the thermal_of_cooling_device_register() function needs
> > a stub to allow clean compilation.
> 
> 
> I've just applied a patch on this same matter from Nishanth Menon [1].
> Can you please check if his patch is enough for you?
> 
> [1] -
> https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=fixes=12ca7188468ee29c4e717f73db4bf43c90954fc7
> 

I will prepare new PWM-FAN patch set with above changes in mind.


> 
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> > Changes for v2:
> > - None
> > Changes for v3:
> > - Provide stub declaration when CONFIG_THERMAL is not set
> > Changes for v4:
> > - None
> > ---
> >  include/linux/thermal.h | 17 ++---
> >  1 file changed, 14 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> > index fc52e30..eacf2de 100644
> > --- a/include/linux/thermal.h
> > +++ b/include/linux/thermal.h
> > @@ -293,6 +293,20 @@ struct thermal_trip {
> >  };
> >  
> >  /* Function declarations */
> > +#ifdef CONFIG_THERMAL
> > +struct thermal_cooling_device *
> > +thermal_of_cooling_device_register(struct device_node *np,
> > +  char *type, void *devdata,
> > +  const struct
> > thermal_cooling_device_ops *); +#else
> > +static inline struct thermal_cooling_device *
> > +thermal_of_cooling_device_register(struct device_node *np,
> > +  char *type, void *devdata,
> > +  const struct
> > thermal_cooling_device_ops *ops) +{
> > +   return NULL;
> > +}
> > +#endif
> >  #ifdef CONFIG_THERMAL_OF
> >  struct thermal_zone_device *
> >  thermal_zone_of_sensor_register(struct device *dev, int id, void
> > *data, @@ -328,9 +342,6 @@ void thermal_zone_device_update(struct
> > thermal_zone_device *); 
> >  struct thermal_cooling_device
> > *thermal_cooling_device_register(char *, void *, const struct
> > thermal_cooling_device_ops *); -struct thermal_cooling_device *
> > -thermal_of_cooling_device_register(struct device_node *np, char *,
> > void *,
> > -  const struct
> > thermal_cooling_device_ops *); void
> > thermal_cooling_device_unregister(struct thermal_cooling_device *);
> > struct thermal_zone_device *thermal_zone_get_zone_by_name(const
> > char *name); int thermal_zone_get_temp(struct thermal_zone_device
> > *tz, unsigned long *temp); -- 2.0.0.rc2
> > 



-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thermal: exynos: Fix wrong control of power down detection mode for Exynos7

[Lukasz Majewski]

Hi Eduardo,

> Hi Lukasz,
> 
> On Wed, Feb 25, 2015 at 2:33 PM, Lukasz Majewski
>  wrote:
> > Hi Abhilash,
> >
> >> This patch fixes the wrong control of PD_DET_EN (power down
> >> detection mode) for Exynos7 because exynos7_tmu_control() always
> >> enables the power down detection mode regardless 'on' parameter.
> >>
> >> Cc: Zhang Rui 
> >> Cc: Eduardo Valentin 
> >> Signed-off-by: Chanwoo Choi 
> >> ---
> >>  drivers/thermal/samsung/exynos_tmu.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> >> b/drivers/thermal/samsung/exynos_tmu.c index 933cd80..a60f527
> >> 100644 --- a/drivers/thermal/samsung/exynos_tmu.c
> >> +++ b/drivers/thermal/samsung/exynos_tmu.c
> >> @@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct
> >> platform_device *pdev, bool on)
> >>   if (on) {
> >>   con |= (1 << EXYNOS_TMU_CORE_EN_SHIFT);
> >> + con |= (1 << EXYNOS7_PD_DET_EN_SHIFT);
> >>   interrupt_en =
> >>   (of_thermal_is_trip_valid(tz, 7)
> >>   << EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
> >> @@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct
> >> platform_device *pdev, bool on) interrupt_en <<
> >> EXYNOS_TMU_INTEN_FALL0_SHIFT; } else {
> >>   con &= ~(1 << EXYNOS_TMU_CORE_EN_SHIFT);
> >> + con &= ~(1 << EXYNOS7_PD_DET_EN_SHIFT);
> >>   interrupt_en = 0; /* Disable all interrupts */
> >>   }
> >> - con |= 1 << EXYNOS7_PD_DET_EN_SHIFT;
> >>
> >>   writel(interrupt_en, data->base + EXYNOS7_TMU_REG_INTEN);
> >>   writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
> >
> > Could you test this patch if it isn't introducing any regression on
> > your HW?
> 
> The patch does not cause any regression on exynos7 and seems
> logically correct.
> 
> Tested-by: Abhilash Kesavan 
> 

Eduardo, it is up to you if you prefer to take this fix directly or via
the new thermal-samsung tree ?

>From when shall I regard myself as a maintainer? :-)


> 
> Regards,
> Abhilash
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R Institute Poland (SRPOL) | Linux Platform Group


-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RT 1/2] rwsem-rt: Do not allow readers to nest

[Sebastian Andrzej Siewior]

On 02/18/2015 09:13 PM, Steven Rostedt wrote:

>> Here the same thing but without cmpxchg(). _If_ after an increment the
>> value is negative then we take slowpath. Otherwise we have the lock.
> 
> OK, so I need to make it so it can nest with trylock. I have to look at
> the patch again because it has been a while.

I have reverted the patch and can confirm that cpufreq works again.

I did some testing on vanilla and -RT:
- down_read(l) + down_read(l)
  this triggers a lockdep warning about a possible deadlock the lock is
  obtained.

- down_read(l) + down_read_trylock()
  this passes without a warning.

So I think we good now.

> An RW sem must not do two down_read()s on the same lock (it's fine for
> a trylock if it has a fail safe for it). The reason is, the second
> down_read() will block if there's a writer waiting. Thus you are
> guaranteed a deadlock if you have the lock for read, a write comes in
> and waits, and you grab the RW sem again, because it will block, and
> the writer is waiting for the reader to release. Thus you have a
> deadlock.

I fully understand. However nesting is allowed according to the code in
vanilla and now again in -RT. Lockdep complains properly so we should
catch people doing it wrong in both trees.

> I'll have to revisit this. I also need to revisit the multi readers
> (although Thomas hates it, but he even admitted there's a better way to
> do it. Now only if I could remember what that was ;-)

Okay. For now I keep the revert since it looks sane and simple.

> 
> Thanks,
> 
> -- Steve

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

Re: stand-alone kvmtool

[Will Deacon]

On Mon, Feb 23, 2015 at 05:23:58PM +, Pekka Enberg wrote:
> Hi,

Hi Pekka,

Sorry for the delay, I've been away from email for a few days.

> On 2/18/15 5:50 PM, Will Deacon wrote:
> > Thanks for doing this. Since it looks unlikely that kvmtool will ever be
> > merged back into the kernel tree, it makes sense to cut the dependency
> > in my opinion.
> 
> I am certainly OK with a standalone repository which preserves the 
> history. Will, would you like to take over the proposed new repository 
> and put it somewhere on git.kernel.org, perhaps?

Sure thing. I'll sync-up with Andre and reply back here when we've got
something sensible.

One extra point that I don't think has been mentioned in this thread so
far is that separating kvmtool from the kernel sources is likely a
prerequisite for distribution packaging. Once we've got something sorted
out, I'll poke some friendly local debian developers and see if they can't
package it up for us.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] media: em28xx replace printk in dprintk macros

[Mauro Carvalho Chehab]

Em Tue, 24 Feb 2015 19:45:50 -0800
Joe Perches  escreveu:

> On Tue, 2015-02-24 at 16:41 -0700, Shuah Khan wrote:
> > On 02/24/2015 03:03 PM, Mauro Carvalho Chehab wrote:
> > > Em Tue, 24 Feb 2015 11:53:47 -0700 Shuah Khan  
> > > escreveu:
> > >> Replace printk macro in dprintk macros in em28xx audio, dvb,
> > >> and input files with pr_* equivalent routines.
> []
> > >> diff --git a/drivers/media/usb/em28xx/em28xx-input.c 
> > >> b/drivers/media/usb/em28xx/em28xx-input.c
> []
> > >>  #define dprintk(fmt, arg...) \
> > >>  if (ir_debug) { \
> > >> -printk(KERN_DEBUG "%s/ir: " fmt, ir->name , ## arg); \
> > >> +pr_debug("%s/ir: " fmt, ir->name, ## arg); \
> > > 
> > > NACK.
> > > 
> > > This is the worse of two words, as it would require both to enable
> > > each debug line via dynamic printk setting and to enable ir_debug.
> > Ah. I missed that. Sorry for the noise.
> 
> It's
> At some point, I'm going to propose a standard mechanism
> similar to netif_ that does bitmap matching for
> dynamic_debug and generic debugging.

Such mechanism would make sense for media drivers.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thermal: exynos: Fix wrong control of power down detection mode for Exynos7

[Abhilash Kesavan]

Hi Lukasz,

On Wed, Feb 25, 2015 at 2:33 PM, Lukasz Majewski  wrote:
> Hi Abhilash,
>
>> This patch fixes the wrong control of PD_DET_EN (power down detection
>> mode) for Exynos7 because exynos7_tmu_control() always enables the
>> power down detection mode regardless 'on' parameter.
>>
>> Cc: Zhang Rui 
>> Cc: Eduardo Valentin 
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  drivers/thermal/samsung/exynos_tmu.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
>> b/drivers/thermal/samsung/exynos_tmu.c index 933cd80..a60f527 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct
>> platform_device *pdev, bool on)
>>   if (on) {
>>   con |= (1 << EXYNOS_TMU_CORE_EN_SHIFT);
>> + con |= (1 << EXYNOS7_PD_DET_EN_SHIFT);
>>   interrupt_en =
>>   (of_thermal_is_trip_valid(tz, 7)
>>   << EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
>> @@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct
>> platform_device *pdev, bool on) interrupt_en <<
>> EXYNOS_TMU_INTEN_FALL0_SHIFT; } else {
>>   con &= ~(1 << EXYNOS_TMU_CORE_EN_SHIFT);
>> + con &= ~(1 << EXYNOS7_PD_DET_EN_SHIFT);
>>   interrupt_en = 0; /* Disable all interrupts */
>>   }
>> - con |= 1 << EXYNOS7_PD_DET_EN_SHIFT;
>>
>>   writel(interrupt_en, data->base + EXYNOS7_TMU_REG_INTEN);
>>   writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
>
> Could you test this patch if it isn't introducing any regression on your
> HW?

The patch does not cause any regression on exynos7 and seems logically correct.

Tested-by: Abhilash Kesavan 


Regards,
Abhilash
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 14/18] ARM: Add STM32 family machine

[Maxime Coquelin]

2015-02-20 22:37 GMT+01:00 Paul Bolle :
> On Fri, 2015-02-20 at 21:00 +0100, Uwe Kleine-König wrote:
>> On Fri, Feb 20, 2015 at 07:01:13PM +0100, Maxime Coquelin wrote:
>> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> > index 97d07ed..cfd9532 100644
>> > --- a/arch/arm/Kconfig
>> > +++ b/arch/arm/Kconfig
>> > @@ -774,6 +774,28 @@ config ARCH_OMAP1
>> > help
>> >   Support for older TI OMAP1 (omap7xx, omap15xx or omap16xx)
>> >
>> > +config ARCH_STM32
>> > +   bool "STMicrolectronics STM32"
>> > +   depends on !MMU
>> > +   select ARCH_REQUIRE_GPIOLIB
>> > +   select ARM_NVIC
>> > +   select AUTO_ZRELADDR
>> > +   select ARCH_HAS_RESET_CONTROLLER
>> > +   select RESET_CONTROLLER
>> > +   select PINCTRL
>> > +   select PINCTRL_STM32
>> > +   select CLKSRC_OF
>> > +   select ARMV7M_SYSTICK
>> > +   select COMMON_CLK
>> > +   select CPU_V7M
>> > +   select GENERIC_CLOCKEVENTS
>> > +   select NO_DMA
>> > +   select NO_IOPORT_MAP
>> > +   select SPARSE_IRQ
>> > +   select USE_OF
>> Please sort this list alphabetically.
>
> And drop
> select NO_DMA
>
> You copied that from ARCH_EFM32, but it's pointless on arm (as arch/arm/
> doesn't provide a NO_DMA Kconfig symbol).

You are right, I will drop NO_DMA in v3.

Thanks,
Maxime

>
> I submitted a patch last year to drop it from ARCH_EFM32, which Uwe
> Acked, but then nothing happened. I'm to blame, as I should have sent a
> reminder.
>
>> > +   help
>> > + Support for STMicorelectronics STM32 processors.
>> > +
>> >  endchoice
>> >
>> >  menu "Multiple platform selection"
>
>
> Paul Bolle
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] New eFuse subsystem

[Maxime Ripard]

Hi Ezequiel,

On Wed, Feb 25, 2015 at 08:45:12AM -0300, Ezequiel Garcia wrote:
> This patchset introduces a new driver subsystem, meant to support eFuse
> (alias OTP, one-time-programmable) devices.
> 
> The motivation behind this work is to have a common place for drivers
> that are currently more or less scattered: the tegra efuses are in
> drivers/soc/ and the sunxi efuses in drivers/misc/eeprom.
> 
> For now, there's no proposal for a generic efuse API. Instead, we simply
> group the drivers together.
> 
> This patchset is the result of the initial submission for IMG Pistachio
> eFuse support [1]. Our first proposal was to follow the Tegra efuse, and
> put the Pistachio efuse in drivers/soc. After some discussion we finally
> agreed [2] to first create an efuse directoy, and then put all efuse drivers
> in it.
> 
> As always, all comments are welcome!
> 
> [1] http://www.spinics.net/lists/devicetree/msg59246.html
> [2] http://www.spinics.net/lists/arm-kernel/msg389325.html

Have you looked at the EEPROM framework currently in discussions? The
two seems to be covering pretty much the same use cases.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH v2 14/18] ARM: Add STM32 family machine

[Maxime Coquelin]

2015-02-20 21:00 GMT+01:00 Uwe Kleine-König :
> Hello,
>
> On Fri, Feb 20, 2015 at 07:01:13PM +0100, Maxime Coquelin wrote:
>> STMicrolectronics's STM32 series is a family of Cortex-M
>> microcontrollers. It is used in various applications, and
>> proposes a wide range of peripherals.
>>
>> Signed-off-by: Maxime Coquelin 
>> ---
>>  Documentation/arm/stm32/overview.txt   | 32 
>> ++
>>  Documentation/arm/stm32/stm32f429-overview.txt | 22 ++
>>  arch/arm/Kconfig   | 22 ++
>>  arch/arm/Makefile  |  1 +
>>  arch/arm/mach-stm32/Makefile   |  1 +
>>  arch/arm/mach-stm32/Makefile.boot  |  0
>>  arch/arm/mach-stm32/board-dt.c | 31 
>> +
>>  7 files changed, 109 insertions(+)
>>  create mode 100644 Documentation/arm/stm32/overview.txt
>>  create mode 100644 Documentation/arm/stm32/stm32f429-overview.txt
>>  create mode 100644 arch/arm/mach-stm32/Makefile
>>  create mode 100644 arch/arm/mach-stm32/Makefile.boot
>>  create mode 100644 arch/arm/mach-stm32/board-dt.c
>>



>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 97d07ed..cfd9532 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -774,6 +774,28 @@ config ARCH_OMAP1
>>   help
>> Support for older TI OMAP1 (omap7xx, omap15xx or omap16xx)
>>
>> +config ARCH_STM32
>> + bool "STMicrolectronics STM32"
>> + depends on !MMU
>> + select ARCH_REQUIRE_GPIOLIB
>> + select ARM_NVIC
>> + select AUTO_ZRELADDR
>> + select ARCH_HAS_RESET_CONTROLLER
>> + select RESET_CONTROLLER
>> + select PINCTRL
>> + select PINCTRL_STM32
>> + select CLKSRC_OF
>> + select ARMV7M_SYSTICK
>> + select COMMON_CLK
>> + select CPU_V7M
>> + select GENERIC_CLOCKEVENTS
>> + select NO_DMA
>> + select NO_IOPORT_MAP
>> + select SPARSE_IRQ
>> + select USE_OF
> Please sort this list alphabetically.

Ok, I will do for v3.

>
>> + help
>> +   Support for STMicorelectronics STM32 processors.
>> +
>>  endchoice
>>
>>  menu "Multiple platform selection"
>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
>> index c1785ee..7d00659 100644
>> --- a/arch/arm/Makefile
>> +++ b/arch/arm/Makefile
>> @@ -196,6 +196,7 @@ machine-$(CONFIG_ARCH_SHMOBILE)   += shmobile
>>  machine-$(CONFIG_ARCH_SIRF)  += prima2
>>  machine-$(CONFIG_ARCH_SOCFPGA)   += socfpga
>>  machine-$(CONFIG_ARCH_STI)   += sti
>> +machine-$(CONFIG_ARCH_STM32) += stm32
>>  machine-$(CONFIG_ARCH_SUNXI) += sunxi
>>  machine-$(CONFIG_ARCH_TEGRA) += tegra
>>  machine-$(CONFIG_ARCH_U300)  += u300
>> diff --git a/arch/arm/mach-stm32/Makefile b/arch/arm/mach-stm32/Makefile
>> new file mode 100644
>> index 000..bd0b7b5
>> --- /dev/null
>> +++ b/arch/arm/mach-stm32/Makefile
>> @@ -0,0 +1 @@
>> +obj-y += board-dt.o
>> diff --git a/arch/arm/mach-stm32/Makefile.boot 
>> b/arch/arm/mach-stm32/Makefile.boot
>> new file mode 100644
>> index 000..e69de29
> Maybe note there why this file exists and can be empty. Feel free to
> copy the content of efm32's Makefile.boot.

Ok, I will copy efm32's Makefile.boot content.
Do you know why your patch has not been applied yet?

>
>> diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-dt.c
>> new file mode 100644
>> index 000..1d681b3
>> --- /dev/null
>> +++ b/arch/arm/mach-stm32/board-dt.c
>> @@ -0,0 +1,31 @@
>> +/*
>> + * Copyright (C) Maxime Coquelin 2015
>> + * Author:  Maxime Coquelin 
>> + * License terms:  GNU General Public License (GPL), version 2
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static const char *const stm32_compat[] __initconst = {
>> + "st,stm32f429",
>> + NULL
>> +};
>> +
>> +static void __init stm32_timer_init(void)
>> +{
>> + of_clk_init(NULL);
>> + reset_controller_of_init();
>> + clocksource_of_init();
> Hmm, if reset_controller_of_init was called automatically you wouldn't
> need that, right? Maybe arange for that instead?

This is what I did in the v1:
http://marc.info/?l=linux-arm-kernel=142376341008550=2

But Rob advised to put it elsewhere.

Thanks,
Maxime

>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.   | Uwe Kleine-König|
> Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/8 v2] ARM OMAP2+ GPMC: add bus children

[Roger Quadros]

Robert,

On 24/02/15 22:05, Robert ABEL wrote:
> This patch adds support for spawning busses as children of the GPMC.
> 
> Signed-off-by: Robert ABEL 
> ---
>  drivers/memory/omap-gpmc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index 5cabac8..78b78a64 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1800,7 +1801,7 @@ static int gpmc_probe_generic_child(struct 
> platform_device *pdev,
>   gpmc_cs_enable_mem(cs);
>  
>  no_timings:
> - if (of_platform_device_create(child, NULL, >dev))
> + if (!of_platform_populate(child, of_default_bus_match_table, NULL, 
> >dev))
>   return 0;

This creates platform devices for the children of child, but what about platform
device for the child itself?

e.g. This fails to create the NOR device and instead starts creating children 
for
NOR partitions instead.

What bus device are you using. Shouldn't the bus driver for that bus be 
responsible
for spawning children of its bus?

>  
>   dev_err(>dev, "failed to create gpmc child %s\n", child->name);
> 

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Differences between builtins and modules

[Michal Marek]

On Tue, Feb 24, 2015 at 10:02:55PM -0300, Lucas De Marchi wrote:
> On Mon, Feb 23, 2015 at 12:51 PM, Michal Marek  wrote:
> > On 2015-02-23 15:30, Lucas De Marchi wrote:
> >> My questions are:
> >> 1) should we put *all* the "modules" in the builtin index?
> >
> > You mean all *.o files that do not end up in some *.ko? That won't work,
> > because unlike module names, the names of object files are not global.
> 
> I was actually meaning anything that can have a directory under
> /sys/module/. I figure we can't easily know this.

I see. Well, we could generate the .modinfo section also for builtin
object files and discard it from vmlinux later, like this:

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index ac78910..efe1798 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -683,6 +683,7 @@
EXIT_CALL   \
*(.discard) \
*(.discard.*)   \
+   *(.modinfo) \
}
 
 /**
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 1c9effa..f38abfa 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -16,23 +16,17 @@
 /* Chosen so that structs with an unsigned long line up. */
 #define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long))
 
-#ifdef MODULE
 #define __MODULE_INFO(tag, name, info)   \
 static const char __UNIQUE_ID(name)[]\
   __used __attribute__((section(".modinfo"), unused, aligned(1)))\
   = __stringify(tag) "=" info
-#else  /* !MODULE */
-/* This struct is here for syntactic coherency, it is not used */
-#define __MODULE_INFO(tag, name, info)   \
-  struct __UNIQUE_ID(name) {}
-#endif
 #define __MODULE_PARM_TYPE(name, _type)
  \
-  __MODULE_INFO(parmtype, name##type, #name ":" _type)
+  __MODULE_INFO(parmtype, name##type, MODULE_PARAM_PREFIX #name ":" _type)
 
 /* One for each parameter, describing how to use it.  Some files do
multiple of these per line, so can't just use MODULE_INFO. */
 #define MODULE_PARM_DESC(_parm, desc) \
-   __MODULE_INFO(parm, _parm, #_parm ":" desc)
+   __MODULE_INFO(parm, _parm, MODULE_PARAM_PREFIX #_parm ":" desc)
 
 struct kernel_param;
 
Then some script would look at the parmtype= fields in the built-in.o
files and complement the list of builtin modules. However, the question
is whether this is worth it. As far as I understand, the problem is just
the discrepancy between modules.builtin and /sys/module. In practice, no
sane tool is going to need to modprobe 'vt' or 'printk', because there
is no configuration in which these modules would exist.


> > Plus, there was IIRC an idea to teach lsmod to print builtin modules --
> > listing all *.o would make it rather useless.
> 
> This was one of my ideas... to traverse /sys/module and give more
> information than we actually output right now, including builtin
> modules. However, given the fact that builtin modules only have an
> entry in /sys/module if they have params and now that I'm aware of the
> race between the creation of the directory and the initstate file, I'm
> giving up on this idea for now.

You could still print the module names from modules.builtin(.idx). But
this is an unrelated topic, I only brought it up because I did not
understand what you were proposing.

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

Re: [PATCH v2 14/18] ARM: Add STM32 family machine

[Maxime Coquelin]

2015-02-20 19:33 GMT+01:00 Peter Meerwald :
>
>> STMicrolectronics's STM32 series is a family of Cortex-M
>> microcontrollers. It is used in various applications, and
>> proposes a wide range of peripherals.
>
> the text describing the STM32 could be a bit more specific :)
> some more nitpicking below
>

Thanks Peter,

I will reword the commit message to add more information, and also fix
the typos you have pointed out.

Best regards,
Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/18] Add support to STMicroelectronics STM32 family

[Maxime Coquelin]

Hello David,

2015-02-24 15:14 GMT+01:00 David Howells :
> Is support for this in upstream binutils and gcc?  What's the preferred target
> tuple?  I'll add support to Fedora's cross-binutils and cross-gcc sets if I
> can.

I just rebuilt using latest upstream binutils and gcc.
To compile Kernel and bootloader, I build a Bare Metal toolchain with
this configuration:

--target=arm-none-eabi --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16
--with-float=hard --with-mode=thumb

BR,
Maxime
>
> David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v8] sched/deadline: support dl task migration during cpu hotplug

[Wanpeng Li]

I observe that dl task can't be migrated to other cpus during cpu hotplug,
in addition, task may/may not be running again if cpu is added back. The
root cause which I found is that dl task will be throtted and removed from
dl rq after comsuming all budget, which leads to stop task can't pick it up
from dl rq and migrate to other cpus during hotplug.

The method to reproduce:
schedtool -E -t 5:10 -e ./test
Actually test is just a simple for loop. Then observe which cpu the test
task is on.
echo 0 > /sys/devices/system/cpu/cpuN/online

This patch adds the dl task migration during cpu hotplug by finding a most
suitable later deadline rq after dl timer fire if current rq is offline,
if fail to find a suitable later deadline rq then fallback to any eligible
online cpu in order that the deadline task will come back to us, and the
push/pull mechanism should then move it around properly.

Signed-off-by: Wanpeng Li 
---
v7 -> v8:
 * remove rd->span related modification since Pang's commit 16b269436b72 
   (sched/deadline: Modify cpudl::free_cpus to reflect rd->online) merged 
   upstream, which Juri pointed out can handle the exclusive cpusets.
 * rebase 
v6 -> v7:
 * rebase
v5 -> v6:
 * add double_lock_balance in the fallback path
v4 -> v5:
 * remove raw_spin_unlock(>lock)
 * cleanup codes, spotted by Peterz
 * cleanup patch description
v3 -> v4:
 * use tsk_cpus_allowed wrapper
 * fix compile error
v2 -> v3:
 * don't get_task_struct
 * if cannot preempt any rq, fallback to pick any online cpus
 * use cpu_active_mask as original later_mask if cpu is offline
v1 -> v2:
 * push the task to another cpu in dl_task_timer() if rq is offline.
 kernel/sched/deadline.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 3fa8fa6..49f92c8 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -492,6 +492,7 @@ static int start_dl_timer(struct sched_dl_entity *dl_se, 
bool boosted)
return hrtimer_active(_se->dl_timer);
 }
 
+static struct rq *find_lock_later_rq(struct task_struct *task, struct rq *rq);
 /*
  * This is the bandwidth enforcement timer callback. If here, we know
  * a task is not on its dl_rq, since the fact that the timer was running
@@ -537,6 +538,43 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
*timer)
update_rq_clock(rq);
 
/*
+* So if we find that the rq the task was on is no longer
+* available, we need to select a new rq.
+*/
+   if (unlikely(!rq->online)) {
+   struct rq *later_rq = NULL;
+
+   later_rq = find_lock_later_rq(p, rq);
+
+   if (!later_rq) {
+   int cpu;
+
+   /*
+* If cannot preempt any rq, fallback to pick any
+* online cpu.
+*/
+   cpu = cpumask_any_and(cpu_active_mask,
+   tsk_cpus_allowed(p));
+   if (cpu >= nr_cpu_ids) {
+   pr_warn("fail to find any online cpu and task 
will never come back\n");
+   goto unlock;
+   }
+   later_rq = cpu_rq(cpu);
+   double_lock_balance(rq, later_rq);
+   }
+
+   deactivate_task(rq, p, 0);
+   set_task_cpu(p, later_rq->cpu);
+   activate_task(later_rq, p, ENQUEUE_REPLENISH);
+
+   resched_curr(later_rq);
+
+   double_unlock_balance(rq, later_rq);
+
+   goto unlock;
+   }
+
+   /*
 * If the throttle happened during sched-out; like:
 *
 *   schedule()
-- 
1.9.1

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

Re: [PATCH] net: macb: Add big endian CPU support

[Michal Simek]

>> endian mode all the time. But the logic for detecting this on CPU is correct 
>> and this is what
>> you need to do on Zynq. You are writing big endian value to little endian 
>> register and read it back
>> to see if it was correctly written or not.
> 
> Just curious; will the same code work without change on a CPU with Big
> endian IP?
> (ie. If zynq hardware comes with only one change; IP configured in BE;
>  will the driver be needing further changes?)

Depends on HW setup and architecture which you want to use.
Let's say test could be to have Microblaze in PL in BE mode (not supported by 
tools)
and bridge to axi. Then depends on Linux kernel how IO functions are 
implemented.
That's why it is hard to say yes/no.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

[PATCH 7/7] ARM: sunxi: Rename EFUSE_SUNXI option in defconfigs

[Ezequiel Garcia]

After the Sunxi eFuse driver move, the config is renamed.
Update the defconfigs.

Cc: Maxime Ripard 
Signed-off-by: Ezequiel Garcia 
---
 arch/arm/configs/multi_v7_defconfig | 2 +-
 arch/arm/configs/sunxi_defconfig| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index e8a4c95..caa84d2 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -145,7 +145,6 @@ CONFIG_ICS932S401=y
 CONFIG_APDS9802ALS=y
 CONFIG_ISL29003=y
 CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_BLK_DEV_SR=y
 CONFIG_SCSI_MULTI_LUN=y
@@ -463,6 +462,7 @@ CONFIG_MSM_MMCC_8974=y
 CONFIG_TEGRA_IOMMU_GART=y
 CONFIG_TEGRA_IOMMU_SMMU=y
 CONFIG_MEMORY=y
+CONFIG_EFUSE_SUNXI_SID=y
 CONFIG_TI_AEMIF=y
 CONFIG_IIO=y
 CONFIG_XILINX_XADC=y
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 38840a8..484c06f 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -30,7 +30,6 @@ CONFIG_IP_PNP_BOOTP=y
 # CONFIG_WIRELESS is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_AHCI_SUNXI=y
@@ -105,6 +104,7 @@ CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_SUN6I=y
 CONFIG_RTC_DRV_SUNXI=y
 # CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EFUSE_SUNXI_SID=y
 CONFIG_PHY_SUN4I_USB=y
 CONFIG_EXT4_FS=y
 CONFIG_VFAT_FS=y
-- 
2.3.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 6/7] efuse: Move Sunxi fuse driver

[Ezequiel Garcia]

The Sunxi SoC eFuse support is currently located under drivers/eeprom,
although the driver is not an eeprom. This commit just moves the driver
to drivers/efuse. There's no functionality change.

Cc: Maxime Ripard 
Signed-off-by: Ezequiel Garcia 
---
 drivers/efuse/Kconfig  | 12 
 drivers/efuse/Makefile |  1 +
 drivers/{misc/eeprom => efuse}/sunxi_sid.c |  0
 drivers/misc/eeprom/Kconfig| 13 -
 drivers/misc/eeprom/Makefile   |  1 -
 5 files changed, 13 insertions(+), 14 deletions(-)
 rename drivers/{misc/eeprom => efuse}/sunxi_sid.c (100%)

diff --git a/drivers/efuse/Kconfig b/drivers/efuse/Kconfig
index b84e06b..a91a16e 100644
--- a/drivers/efuse/Kconfig
+++ b/drivers/efuse/Kconfig
@@ -6,5 +6,17 @@ config EFUSE_TEGRA
help
  Support for the eFuses available on Tegra SoCs
 
+config EFUSE_SUNXI_SID
+   tristate "Allwinner sunxi security ID support"
+   depends on ARCH_SUNXI && SYSFS
+   help
+ This is a driver for the 'security ID' available on various Allwinner
+ devices.
+
+ Due to the potential risks involved with changing e-fuses,
+ this driver is read-only.
+
+ This driver can also be built as a module. If so, the module
+ will be called sunxi_sid.
 
 endmenu
diff --git a/drivers/efuse/Makefile b/drivers/efuse/Makefile
index b69a0d6..30f8d5e 100644
--- a/drivers/efuse/Makefile
+++ b/drivers/efuse/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_EFUSE_TEGRA)  += tegra/
+obj-$(CONFIG_EFUSE_SUNXI_SID)  += sunxi_sid.o
diff --git a/drivers/misc/eeprom/sunxi_sid.c b/drivers/efuse/sunxi_sid.c
similarity index 100%
rename from drivers/misc/eeprom/sunxi_sid.c
rename to drivers/efuse/sunxi_sid.c
diff --git a/drivers/misc/eeprom/Kconfig b/drivers/misc/eeprom/Kconfig
index 9536852f..04f2e1f 100644
--- a/drivers/misc/eeprom/Kconfig
+++ b/drivers/misc/eeprom/Kconfig
@@ -96,17 +96,4 @@ config EEPROM_DIGSY_MTC_CFG
 
  If unsure, say N.
 
-config EEPROM_SUNXI_SID
-   tristate "Allwinner sunxi security ID support"
-   depends on ARCH_SUNXI && SYSFS
-   help
- This is a driver for the 'security ID' available on various Allwinner
- devices.
-
- Due to the potential risks involved with changing e-fuses,
- this driver is read-only.
-
- This driver can also be built as a module. If so, the module
- will be called sunxi_sid.
-
 endmenu
diff --git a/drivers/misc/eeprom/Makefile b/drivers/misc/eeprom/Makefile
index 9507aec..fc1e81d 100644
--- a/drivers/misc/eeprom/Makefile
+++ b/drivers/misc/eeprom/Makefile
@@ -4,5 +4,4 @@ obj-$(CONFIG_EEPROM_LEGACY) += eeprom.o
 obj-$(CONFIG_EEPROM_MAX6875)   += max6875.o
 obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
 obj-$(CONFIG_EEPROM_93XX46)+= eeprom_93xx46.o
-obj-$(CONFIG_EEPROM_SUNXI_SID) += sunxi_sid.o
 obj-$(CONFIG_EEPROM_DIGSY_MTC_CFG) += digsy_mtc_eeprom.o
-- 
2.3.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 5/7] ARM: tegra: Make sure efuse is always selected

[Ezequiel Garcia]

After the introduction of the efuse subsystem, platforms are now required
to select the efuse support explicitly.

Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Signed-off-by: Ezequiel Garcia 
---
 arch/arm/mach-tegra/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 5d1a318..114ea4e 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -11,6 +11,7 @@ menuconfig ARCH_TEGRA
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
select SOC_BUS
+   select EFUSE_TEGRA
select USB_ULPI if USB_PHY
select USB_ULPI_VIEWPORT if USB_PHY
help
-- 
2.3.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: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Borislav Petkov]

On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote:
> So the process steps basically look like this:
> 1.) cat capsule_ticket===> acquire a number and lock mutex then
>  expose 
> firmware_class user helper
>  
> interface as well as start timer for timeout
>  counting
> 2.) repeat step 1 if obtained a "0" number
> 3.) echo 1 > loading
> 4.) cat bin > data
> 5.) echo 0 > loading===> stop the timeout counting  then unlock
>   mutex 
> at the end of callback routine 
> 6.) cat capsule_report   ===> grep the number acquired from beginning
>   for 
> checking succeeded/failed

So this sounds pretty overengineered for no reason, or maybe I'm missing
the reason.

If I had to give an example from the microcode loader, what we do there
is put the microcode in /lib/firmware/... and do

echo 1 > /sys/devices/system/cpu/microcode/reload

which goes and calls reload_store() in
arch/x86/kernel/cpu/microcode/core.c which grabs a mutex, disables CPU
hotplug, etc, etc...

And this mechanism is as simple as it can get. Maybe capsules can be
loaded like that too?

Error code can be propagated too, if needed, of course.

-- 
Regards/Gruss,
Boris.

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

[PATCH 3/7] drivers: Introduce new eFuse subsystem stub

[Ezequiel Garcia]

This commit introduces a new eFuse subsystem stub to hold all the eFuse-like
device drivers. This will be used to host the currently supported Tegra
eFuse driver, and will allow to add support for other platforms as well.

Cc: Thierry Reding 
Cc: Stephen Warren 
Cc: Maxime Ripard 
Cc: Arnd Bergmann 
Cc: Stefan Wahren 
Signed-off-by: Ezequiel Garcia 
---
 drivers/Kconfig| 2 ++
 drivers/Makefile   | 1 +
 drivers/efuse/Kconfig  | 3 +++
 drivers/efuse/Makefile | 0
 4 files changed, 6 insertions(+)
 create mode 100644 drivers/efuse/Kconfig
 create mode 100644 drivers/efuse/Makefile

diff --git a/drivers/Kconfig b/drivers/Kconfig
index c0cc96b..9c0d93d 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -146,6 +146,8 @@ source "drivers/remoteproc/Kconfig"
 
 source "drivers/rpmsg/Kconfig"
 
+source "drivers/efuse/Kconfig"
+
 source "drivers/soc/Kconfig"
 
 source "drivers/devfreq/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 527a6da..5572728 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -34,6 +34,7 @@ obj-y += amba/
 obj-$(CONFIG_DMADEVICES)   += dma/
 
 # SOC specific infrastructure drivers.
+obj-y  += efuse/
 obj-y  += soc/
 
 obj-$(CONFIG_VIRTIO)   += virtio/
diff --git a/drivers/efuse/Kconfig b/drivers/efuse/Kconfig
new file mode 100644
index 000..617476f
--- /dev/null
+++ b/drivers/efuse/Kconfig
@@ -0,0 +1,3 @@
+menu "eFuse drivers"
+
+endmenu
diff --git a/drivers/efuse/Makefile b/drivers/efuse/Makefile
new file mode 100644
index 000..e69de29
-- 
2.3.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: [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage.

[Wang Nan]

On 2015/2/25 19:11, Wang Nan wrote:
> On 2015/2/20 11:59, Masami Hiramatsu wrote:
>> Hi,
>>
>> Sorry for replying late.
>>
>> (2015/02/13 14:39), Wang Nan wrote:
>>> I fell very sorry for people who reviewed my v2 patch series yesterday
>>> at https://lkml.org/lkml/2015/2/12/234 because I didn't provide enough
>>> information in commit log. This v3 patch series add those missing
>>> commit messages. There are also 2 small fix based on v2:
>>>
>>>  1. Fixes ftrace_sort_mcount_area. Original patch doesn't work for module.
>>>  2. Wraps setting of kprobes_initialized in stop_machine() context.
>>
>> From the viewpoint of the maintenance, it seems over-engineered and
>> not general implementation. Please reconsider just initializing breakpoint
>> handler in earlier stage. Since those exceptions may happen anywhere,
>> those trap handlers setup very early stage. E.g. on x86, setup_arch()
>> setup early_trap_init() at beginning. So we just need to initialize
>> kprobes earlier.
> 
> I tried as your suggestion. For x86, int3 handler doesn't work correctly until
> trap_init(). I don't have enough time to look into this problem today (and I 
> don't
> familiar with x86 architecture). Could you please have a look on it?
> 
> Thank you.
> 

Hi Masami,

Sorry for the noise. I have futher information may be useful.

I initialize kprobe and probed an instruction with int3 between setup_arch() and
trap_init(). It doesn't work at first. By dumping __log_buf[] I fount it 
reports NULL pointer panic.
With some random test I found following patch, which makes it works (looks 
like) correctly.

However I think there must be some reason to set dpl to '3' instead of '0' 
(set_mni_gate
use 0 as dpl). Do you have any suggestion on it?

Thank you.

- The patch ---
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 9d2073e..ac29277 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -925,9 +925,9 @@ dotraplinkage void do_iret_error(struct pt_regs *regs, long 
error_code)
 /* Set of traps needed for early debugging. */
 void __init early_trap_init(void)
 {
-   set_intr_gate_ist(X86_TRAP_DB, , DEBUG_STACK);
+   set_intr_gate_ist(X86_TRAP_DB, , 0);
/* int3 can be called from all */
-   set_system_intr_gate_ist(X86_TRAP_BP, , DEBUG_STACK);
+   set_intr_gate_ist(X86_TRAP_BP, , 0);
 #ifdef CONFIG_X86_32
set_intr_gate(X86_TRAP_PF, page_fault);
 #endif


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] New eFuse subsystem

[Ezequiel Garcia]

This patchset introduces a new driver subsystem, meant to support eFuse
(alias OTP, one-time-programmable) devices.

The motivation behind this work is to have a common place for drivers
that are currently more or less scattered: the tegra efuses are in
drivers/soc/ and the sunxi efuses in drivers/misc/eeprom.

For now, there's no proposal for a generic efuse API. Instead, we simply
group the drivers together.

This patchset is the result of the initial submission for IMG Pistachio
eFuse support [1]. Our first proposal was to follow the Tegra efuse, and
put the Pistachio efuse in drivers/soc. After some discussion we finally
agreed [2] to first create an efuse directoy, and then put all efuse drivers
in it.

As always, all comments are welcome!

[1] http://www.spinics.net/lists/devicetree/msg59246.html
[2] http://www.spinics.net/lists/arm-kernel/msg389325.html

Ezequiel Garcia (7):
  soc: tegra: Add missing include linux/types.h
  soc: tegra: Move the fuse header to a separate directory
  drivers: Introduce new eFuse subsystem stub
  efuse: Move Tegra efuse driver
  ARM: tegra: Make sure efuse is always selected
  efuse: Move Sunxi fuse driver
  ARM: sunxi: Rename EFUSE_SUNXI option in defconfigs

 arch/arm/configs/multi_v7_defconfig|  2 +-
 arch/arm/configs/sunxi_defconfig   |  2 +-
 arch/arm/mach-tegra/Kconfig|  1 +
 arch/arm/mach-tegra/cpuidle.c  |  3 +--
 arch/arm/mach-tegra/flowctrl.c |  3 +--
 arch/arm/mach-tegra/hotplug.c  |  2 +-
 arch/arm/mach-tegra/platsmp.c  |  2 +-
 arch/arm/mach-tegra/pm.c   |  2 +-
 arch/arm/mach-tegra/reset-handler.S|  3 +--
 arch/arm/mach-tegra/reset.c|  3 +--
 arch/arm/mach-tegra/sleep-tegra30.S|  3 +--
 arch/arm/mach-tegra/tegra.c|  2 +-
 drivers/Kconfig|  2 ++
 drivers/Makefile   |  1 +
 drivers/ata/ahci_tegra.c   |  2 +-
 drivers/clk/tegra/clk-periph-gate.c|  3 +--
 drivers/clk/tegra/clk.c|  3 +--
 drivers/efuse/Kconfig  | 22 ++
 drivers/efuse/Makefile |  2 ++
 drivers/{misc/eeprom => efuse}/sunxi_sid.c |  0
 drivers/{soc/tegra/fuse => efuse/tegra}/Makefile   |  0
 .../{soc/tegra/fuse => efuse/tegra}/fuse-tegra.c   |  2 +-
 .../{soc/tegra/fuse => efuse/tegra}/fuse-tegra20.c |  3 +--
 .../{soc/tegra/fuse => efuse/tegra}/fuse-tegra30.c |  3 +--
 drivers/{soc/tegra/fuse => efuse/tegra}/fuse.h |  0
 .../tegra/fuse => efuse/tegra}/speedo-tegra114.c   |  3 +--
 .../tegra/fuse => efuse/tegra}/speedo-tegra124.c   |  3 +--
 .../tegra/fuse => efuse/tegra}/speedo-tegra20.c|  3 +--
 .../tegra/fuse => efuse/tegra}/speedo-tegra30.c|  3 +--
 .../tegra/fuse => efuse/tegra}/tegra-apbmisc.c |  3 +--
 drivers/gpu/drm/nouveau/nouveau_platform.c |  2 +-
 drivers/misc/eeprom/Kconfig| 13 -
 drivers/misc/eeprom/Makefile   |  1 -
 drivers/soc/tegra/Makefile |  2 --
 drivers/soc/tegra/pmc.c|  2 +-
 drivers/thermal/tegra_soctherm.c   |  3 +--
 include/{soc/tegra/fuse.h => linux/efuse/tegra.h}  |  2 ++
 37 files changed, 55 insertions(+), 56 deletions(-)
 create mode 100644 drivers/efuse/Kconfig
 create mode 100644 drivers/efuse/Makefile
 rename drivers/{misc/eeprom => efuse}/sunxi_sid.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/Makefile (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra20.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra30.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse.h (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra114.c (98%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra124.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra20.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra30.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/tegra-apbmisc.c (98%)
 rename include/{soc/tegra/fuse.h => linux/efuse/tegra.h} (98%)

-- 
2.3.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 1/7] soc: tegra: Add missing include linux/types.h

[Ezequiel Garcia]

The soc/tegra/fuse.h header makes use of kernel-specific types (u32, u8) and
therefore it needs a linux/types.h include.

Cc: Thierry Reding 
Cc: Stephen Warren 
Cc: Alexandre Courbot 
Signed-off-by: Ezequiel Garcia 
---
 include/soc/tegra/fuse.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/soc/tegra/fuse.h b/include/soc/tegra/fuse.h
index b5f7b5f..8459008 100644
--- a/include/soc/tegra/fuse.h
+++ b/include/soc/tegra/fuse.h
@@ -28,6 +28,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include 
+
 u32 tegra_read_chipid(void);
 u8 tegra_get_chip_id(void);
 
-- 
2.3.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 2/7] soc: tegra: Move the fuse header to a separate directory

[Ezequiel Garcia]

As preparation work for the introduction of an eFuse subsystem,
this commit moves Tegra's fuse header and fixes the includes
where needed.

Cc: Thierry Reding 
Cc: Stephen Warren 
Cc: Alexandre Courbot 
Signed-off-by: Ezequiel Garcia 
---
 arch/arm/mach-tegra/cpuidle.c | 3 +--
 arch/arm/mach-tegra/flowctrl.c| 3 +--
 arch/arm/mach-tegra/hotplug.c | 2 +-
 arch/arm/mach-tegra/platsmp.c | 2 +-
 arch/arm/mach-tegra/pm.c  | 2 +-
 arch/arm/mach-tegra/reset-handler.S   | 3 +--
 arch/arm/mach-tegra/reset.c   | 3 +--
 arch/arm/mach-tegra/sleep-tegra30.S   | 3 +--
 arch/arm/mach-tegra/tegra.c   | 2 +-
 drivers/ata/ahci_tegra.c  | 2 +-
 drivers/clk/tegra/clk-periph-gate.c   | 3 +--
 drivers/clk/tegra/clk.c   | 3 +--
 drivers/gpu/drm/nouveau/nouveau_platform.c| 2 +-
 drivers/soc/tegra/fuse/fuse-tegra.c   | 2 +-
 drivers/soc/tegra/fuse/fuse-tegra20.c | 3 +--
 drivers/soc/tegra/fuse/fuse-tegra30.c | 3 +--
 drivers/soc/tegra/fuse/speedo-tegra114.c  | 3 +--
 drivers/soc/tegra/fuse/speedo-tegra124.c  | 3 +--
 drivers/soc/tegra/fuse/speedo-tegra20.c   | 3 +--
 drivers/soc/tegra/fuse/speedo-tegra30.c   | 3 +--
 drivers/soc/tegra/fuse/tegra-apbmisc.c| 3 +--
 drivers/soc/tegra/pmc.c   | 2 +-
 drivers/thermal/tegra_soctherm.c  | 3 +--
 include/{soc/tegra/fuse.h => linux/efuse/tegra.h} | 0
 24 files changed, 23 insertions(+), 38 deletions(-)
 rename include/{soc/tegra/fuse.h => linux/efuse/tegra.h} (100%)

diff --git a/arch/arm/mach-tegra/cpuidle.c b/arch/arm/mach-tegra/cpuidle.c
index 3165631..62b8086 100644
--- a/arch/arm/mach-tegra/cpuidle.c
+++ b/arch/arm/mach-tegra/cpuidle.c
@@ -21,11 +21,10 @@
  * more details.
  */
 
+#include 
 #include 
 #include 
 
-#include 
-
 #include "cpuidle.h"
 
 void __init tegra_cpuidle_init(void)
diff --git a/arch/arm/mach-tegra/flowctrl.c b/arch/arm/mach-tegra/flowctrl.c
index 475e783..623c820 100644
--- a/arch/arm/mach-tegra/flowctrl.c
+++ b/arch/arm/mach-tegra/flowctrl.c
@@ -19,14 +19,13 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-#include 
-
 #include "flowctrl.h"
 
 static u8 flowctrl_offset_halt_cpu[] = {
diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
index 6fc71f1..0d55820 100644
--- a/arch/arm/mach-tegra/hotplug.c
+++ b/arch/arm/mach-tegra/hotplug.c
@@ -9,11 +9,11 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
 #include 
-#include 
 
 #include 
 
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index b450866..2c65404 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -15,13 +15,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-#include 
 #include 
 
 #include 
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index b0f48a3..7089444 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,7 +28,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/arch/arm/mach-tegra/reset-handler.S 
b/arch/arm/mach-tegra/reset-handler.S
index 71be4af..318fbcc 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -14,11 +14,10 @@
  * along with this program.  If not, see .
  */
 
+#include 
 #include 
 #include 
 
-#include 
-
 #include 
 #include 
 
diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index 894c5c4..7fb3030 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -16,11 +16,10 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-tegra/sleep-tegra30.S 
b/arch/arm/mach-tegra/sleep-tegra30.S
index 5d8d13a..e8c8946 100644
--- a/arch/arm/mach-tegra/sleep-tegra30.S
+++ b/arch/arm/mach-tegra/sleep-tegra30.S
@@ -14,10 +14,9 @@
  * along with this program.  If not, see .
  */
 
+#include 
 #include 
 
-#include 
-
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 914341b..b216403 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -35,7 +36,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 #include 
diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
index 3a62eb2..cbd4b43 100644
--- a/drivers/ata/ahci_tegra.c
+++ b/drivers/ata/ahci_tegra.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 

[PATCH 4/7] efuse: Move Tegra efuse driver

[Ezequiel Garcia]

Now that the efuse subsystem has been introduced, move the Tegra efuse driver
from drivers/soc/tegra/fuse/ to drivers/efuse/tegra. For now, there's no
generic efuse API. However, by having the drivers in a unified location it is
expected that such API will arise easier once support for more devices is added.

Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Signed-off-by: Ezequiel Garcia 
---
 drivers/efuse/Kconfig | 7 +++
 drivers/efuse/Makefile| 1 +
 drivers/{soc/tegra/fuse => efuse/tegra}/Makefile  | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra.c  | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra20.c| 0
 drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra30.c| 0
 drivers/{soc/tegra/fuse => efuse/tegra}/fuse.h| 0
 drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra114.c | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra124.c | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra20.c  | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra30.c  | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/tegra-apbmisc.c   | 0
 drivers/soc/tegra/Makefile| 2 --
 13 files changed, 8 insertions(+), 2 deletions(-)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/Makefile (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra20.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra30.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse.h (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra114.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra124.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra20.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra30.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/tegra-apbmisc.c (100%)

diff --git a/drivers/efuse/Kconfig b/drivers/efuse/Kconfig
index 617476f..b84e06b 100644
--- a/drivers/efuse/Kconfig
+++ b/drivers/efuse/Kconfig
@@ -1,3 +1,10 @@
 menu "eFuse drivers"
 
+config EFUSE_TEGRA
+   bool
+   depends on ARCH_TEGRA
+   help
+ Support for the eFuses available on Tegra SoCs
+
+
 endmenu
diff --git a/drivers/efuse/Makefile b/drivers/efuse/Makefile
index e69de29..b69a0d6 100644
--- a/drivers/efuse/Makefile
+++ b/drivers/efuse/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_EFUSE_TEGRA)  += tegra/
diff --git a/drivers/soc/tegra/fuse/Makefile b/drivers/efuse/tegra/Makefile
similarity index 100%
rename from drivers/soc/tegra/fuse/Makefile
rename to drivers/efuse/tegra/Makefile
diff --git a/drivers/soc/tegra/fuse/fuse-tegra.c 
b/drivers/efuse/tegra/fuse-tegra.c
similarity index 100%
rename from drivers/soc/tegra/fuse/fuse-tegra.c
rename to drivers/efuse/tegra/fuse-tegra.c
diff --git a/drivers/soc/tegra/fuse/fuse-tegra20.c 
b/drivers/efuse/tegra/fuse-tegra20.c
similarity index 100%
rename from drivers/soc/tegra/fuse/fuse-tegra20.c
rename to drivers/efuse/tegra/fuse-tegra20.c
diff --git a/drivers/soc/tegra/fuse/fuse-tegra30.c 
b/drivers/efuse/tegra/fuse-tegra30.c
similarity index 100%
rename from drivers/soc/tegra/fuse/fuse-tegra30.c
rename to drivers/efuse/tegra/fuse-tegra30.c
diff --git a/drivers/soc/tegra/fuse/fuse.h b/drivers/efuse/tegra/fuse.h
similarity index 100%
rename from drivers/soc/tegra/fuse/fuse.h
rename to drivers/efuse/tegra/fuse.h
diff --git a/drivers/soc/tegra/fuse/speedo-tegra114.c 
b/drivers/efuse/tegra/speedo-tegra114.c
similarity index 100%
rename from drivers/soc/tegra/fuse/speedo-tegra114.c
rename to drivers/efuse/tegra/speedo-tegra114.c
diff --git a/drivers/soc/tegra/fuse/speedo-tegra124.c 
b/drivers/efuse/tegra/speedo-tegra124.c
similarity index 100%
rename from drivers/soc/tegra/fuse/speedo-tegra124.c
rename to drivers/efuse/tegra/speedo-tegra124.c
diff --git a/drivers/soc/tegra/fuse/speedo-tegra20.c 
b/drivers/efuse/tegra/speedo-tegra20.c
similarity index 100%
rename from drivers/soc/tegra/fuse/speedo-tegra20.c
rename to drivers/efuse/tegra/speedo-tegra20.c
diff --git a/drivers/soc/tegra/fuse/speedo-tegra30.c 
b/drivers/efuse/tegra/speedo-tegra30.c
similarity index 100%
rename from drivers/soc/tegra/fuse/speedo-tegra30.c
rename to drivers/efuse/tegra/speedo-tegra30.c
diff --git a/drivers/soc/tegra/fuse/tegra-apbmisc.c 
b/drivers/efuse/tegra/tegra-apbmisc.c
similarity index 100%
rename from drivers/soc/tegra/fuse/tegra-apbmisc.c
rename to drivers/efuse/tegra/tegra-apbmisc.c
diff --git a/drivers/soc/tegra/Makefile b/drivers/soc/tegra/Makefile
index cdaad9d..23a0f64 100644
--- a/drivers/soc/tegra/Makefile
+++ b/drivers/soc/tegra/Makefile
@@ -1,4 +1,2 @@
-obj-$(CONFIG_ARCH_TEGRA) += fuse/
-
 obj-$(CONFIG_ARCH_TEGRA) += common.o
 obj-$(CONFIG_ARCH_TEGRA) += pmc.o
-- 
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org

Re: [PATCH v3 3/3] tomoyo: reduce mmap_sem hold for mm->exe_file

[Tetsuo Handa]

Davidlohr Bueso wrote:
> The mm->exe_file is currently serialized with mmap_sem (shared) in order
> to both safely (1) read the file and (2) compute the realpath by calling
> tomoyo_realpath_from_path, making it an absolute overkill. Good users will,
> on the other hand, make use of the more standard get_mm_exe_file(), requiring
> only holding the mmap_sem to read the value, and relying on reference
> 
> Signed-off-by: Davidlohr Bueso 

Acked-by: Tetsuo Handa 

James, will you apply to linux-security.git#next ?
I'm not using publicly accessible git tree for sending pull requests.

> ---
> 
> Changes from v2: remove cleanups and cp initialization.
> 
>  security/tomoyo/util.c | 21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/security/tomoyo/util.c b/security/tomoyo/util.c
> index 2952ba5..29f3b65 100644
> --- a/security/tomoyo/util.c
> +++ b/security/tomoyo/util.c
> @@ -948,16 +948,19 @@ bool tomoyo_path_matches_pattern(const struct 
> tomoyo_path_info *filename,
>   */
>  const char *tomoyo_get_exe(void)
>  {
> - struct mm_struct *mm = current->mm;
> - const char *cp = NULL;
> +   struct file *exe_file;
> +   const char *cp;
> +   struct mm_struct *mm = current->mm;
>  
> - if (!mm)
> - return NULL;
> - down_read(>mmap_sem);
> - if (mm->exe_file)
> - cp = tomoyo_realpath_from_path(>exe_file->f_path);
> - up_read(>mmap_sem);
> - return cp;
> +   if (!mm)
> +return NULL;
> +   exe_file = get_mm_exe_file(mm);
> +   if (!exe_file)
> +return NULL;
> +
> +   cp = tomoyo_realpath_from_path(_file->f_path);
> +   fput(exe_file);
> +   return cp;
>  }
>  
>  /**
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] doc:input : Fix typo in Documentations/input

[Masanari Iida]

This patch fix spelling typos in Documentations/input.

Signed-off-by: Masanari Iida 
---
 Documentation/input/alps.txt| 4 ++--
 Documentation/input/event-codes.txt | 2 +-
 Documentation/input/gpio-tilt.txt   | 2 +-
 Documentation/input/iforce-protocol.txt | 2 +-
 Documentation/input/walkera0701.txt | 2 +-
 Documentation/input/yealink.txt | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt
index a63e5e0..b9ecf99 100644
--- a/Documentation/input/alps.txt
+++ b/Documentation/input/alps.txt
@@ -58,7 +58,7 @@ To exit command mode, PSMOUSE_CMD_SETSTREAM (EA) is sent to 
the touchpad.
 While in command mode, register addresses can be set by first sending a
 specific command, either EC for v3 devices or F5 for v4 devices. Then the
 address is sent one nibble at a time, where each nibble is encoded as a
-command with optional data. This enoding differs slightly between the v3 and
+command with optional data. This encoding differs slightly between the v3 and
 v4 protocols.
 
 Once an address has been set, the addressed register can be read by sending
@@ -131,7 +131,7 @@ ALPS Absolute Mode - Protocol Version 3
 ---
 
 ALPS protocol version 3 has three different packet formats. The first two are
-associated with touchpad events, and the third is associatd with trackstick
+associated with touchpad events, and the third is associated with trackstick
 events.
 
 The first type is the touchpad position packet.
diff --git a/Documentation/input/event-codes.txt 
b/Documentation/input/event-codes.txt
index c587a96..d92eae3 100644
--- a/Documentation/input/event-codes.txt
+++ b/Documentation/input/event-codes.txt
@@ -229,7 +229,7 @@ such device to feedback.
 EV_PWR:
 --
 EV_PWR events are a special type of event used specifically for power
-mangement. Its usage is not well defined. To be addressed later.
+management. Its usage is not well defined. To be addressed later.
 
 Device properties:
 =
diff --git a/Documentation/input/gpio-tilt.txt 
b/Documentation/input/gpio-tilt.txt
index 06d60c3..2cdfd9b 100644
--- a/Documentation/input/gpio-tilt.txt
+++ b/Documentation/input/gpio-tilt.txt
@@ -28,7 +28,7 @@ Example:
 
 
 Example configuration for a single TS1003 tilt switch that rotates around
-one axis in 4 steps and emitts the current tilt via two GPIOs.
+one axis in 4 steps and emits the current tilt via two GPIOs.
 
 static int sg060_tilt_enable(struct device *dev) {
/* code to enable the sensors */
diff --git a/Documentation/input/iforce-protocol.txt 
b/Documentation/input/iforce-protocol.txt
index 2d5fbfd..6628715 100644
--- a/Documentation/input/iforce-protocol.txt
+++ b/Documentation/input/iforce-protocol.txt
@@ -97,7 +97,7 @@ LEN= 0e
 *** Attack and fade ***
 OP=  02
 LEN= 08
-00-01 Address where to store the parameteres
+00-01 Address where to store the parameters
 02-03 Duration of attack (little endian encoding, in ms)
 04 Level at end of attack. Signed byte.
 05-06 Duration of fade.
diff --git a/Documentation/input/walkera0701.txt 
b/Documentation/input/walkera0701.txt
index 561385d..49e3ac6 100644
--- a/Documentation/input/walkera0701.txt
+++ b/Documentation/input/walkera0701.txt
@@ -91,7 +91,7 @@ absolute binary value. (10 bits per channel). Next nibble is 
checksum for
 first ten nibbles.
 
 Next nibbles 12 .. 21 represents four channels (not all channels can be
-directly controlled from TX). Binary representations ar the same as in first
+directly controlled from TX). Binary representations are the same as in first
 four channels. In nibbles 22 and 23 is a special magic number. Nibble 24 is
 checksum for nibbles 12..23.
 
diff --git a/Documentation/input/yealink.txt b/Documentation/input/yealink.txt
index 5360e43..8277b76 100644
--- a/Documentation/input/yealink.txt
+++ b/Documentation/input/yealink.txt
@@ -93,7 +93,7 @@ Format description:
   Format specifier
 '8' :  Generic 7 segment digit with individual addressable segments
 
-Reduced capability 7 segm digit, when segments are hard wired together.
+Reduced capability 7 segment digit, when segments are hard wired together.
 '1' : 2 segments digit only able to produce a 1.
 'e' : Most significant day of the month digit,
   able to produce at least 1 2 3.
-- 
2.3.0.149.gf3f4077

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: nios2: is the ptrace ABI correct?

[Ezequiel Garcia]

On 02/24/2015 04:25 PM, Arnd Bergmann wrote:
> On Tuesday 24 February 2015 12:28:41 Ezequiel Garcia wrote:
>>
>> Gah, no, you are right. I got confused.
>>
>> So it would be OK to avoid remove pt_regs from the uapi headers?
>> How does this affect the signal handling nios2 implementation?
>>
> 
> We have a number of architectures that don't provide this structure:
> 
> $ git grep -L pt_regs arch/*/include/uapi/asm/ptrace.h
> arch/frv/include/uapi/asm/ptrace.h
> arch/metag/include/uapi/asm/ptrace.h
> arch/openrisc/include/uapi/asm/ptrace.h
> arch/s390/include/uapi/asm/ptrace.h
> 
> so I'd assume it's ok in general not to have it. However, on
> nios2, struct pt_regs is embedded inside of struct sigcontext.
> If I read the code in arch/nios2/kernel/signal.c correctly,
> this is actually a bug and you should use a different structure
> there too, because pt_regs does not match the layout of the
> stack either. This means that the (rare) user programs that
> would know about the architecture to modify signal stacks
> are currently broken.
> 

/me is more confused now

In arch/nios2/include/asm/ucontext.h

struct ucontext {
unsigned long uc_flags;
struct ucontext  *uc_link;
stack_t   uc_stack;
struct mcontext   uc_mcontext;
sigset_t  uc_sigmask;
};

And in include/uapi/asm-generic/ucontext.h:

struct ucontext {
unsigned long uc_flags;
struct ucontext  *uc_link;
stack_t   uc_stack;
struct sigcontext uc_mcontext;
sigset_t  uc_sigmask;
};

Which one is the one that userspace sees? And why does the kernel has
two different structures?

Given this oddities, I'm wondering how troublesome would be to just
re-do this and break the ptrace and signal ABI. For instance, just
pushing pt_regs in PTRACE_GETREGSET would make things much clearer.

I guess Linus would burn me for even suggesting to breaking users... but
do we have any users at all? This arch has just been mainlined. Altera's
out-of-tree is already ABI-incompatible with mainline so that's not an
issue.

The only one using this ABI is gdb, which is easily fixed.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] compat: Fix endian issue in union sigval

[Catalin Marinas]

On Tue, Feb 24, 2015 at 04:54:17PM -0500, Chris Metcalf wrote:
> On 2/14/2015 6:22 AM, Catalin Marinas wrote:
> >1. user populates sival_int compat_sigevent and invokes
> >compat_sys_mq_notify()
> >2. kernel get_compat_sigevent() copies compat_sigevent into the native
> >sigevent. compat and native sival_int are the same, no problem so
> >far. The other half of 64-bit sival_ptr is zeroed by a memset in this
> >function (this other half can be top or bottom, depending on
> >endianness)
> >3. signal is about to be delivered to user via arch code. The
> >compat_ptr(from->si_ptr) conversion always takes the least
> >significant part of the native si_ptr. On big endian 64-bit, this is
> >zero because get_compat_sigevent() populated the top part of si_ptr
> >with si_int.
> >
> >So delivering such signals to compat user always sets si_int to 0.
> >Little endian is fine.
> 
> I looked at this again as I was getting ready to do a tile patch, and realized
> why tile and arm64 are different here: tile does a field-by-field copy in
> copy_siginfo_from_user32(), like parisc and s390.  As a result, we initialize
> the 64-bit kernel si_ptr value by cast from the 32-bit user si_ptr value, 
> rather
> than blindly writing into the lower-addressed half of the 64-bit sigval.

It's not about copy_siginfo_from_user32() but the generic
get_compat_sigevent() which always uses sival_int (called from e.g.
compat_sys_timer_create()).

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

Re: [PATCH 1/3] arm64: mediatek: Add config option for mt8173.

[Catalin Marinas]

On Wed, Feb 25, 2015 at 11:51:57AM +0100, Arnd Bergmann wrote:
> On Wednesday 25 February 2015 17:07:22 Yingjoe Chen wrote:
> > On Tue, 2015-01-27 at 15:13 +0800, Hongzhou Yang wrote:
> > > From: Hongzhou Yang 
> > > 
> > > The upcoming MTK pinctrl driver have a big pin table for each SoC,
> > > and we don't want to bloat the kernel binary if we don't need it.
> > > Add config options so we can build for one SoC only.
> > > 
> > > Signed-off-by: Hongzhou Yang 
> > > ---
> > >  arch/arm64/Kconfig | 6 ++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index e627ead..6213dac 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -151,9 +151,15 @@ menu "Platform selection"
> > >  config ARCH_MEDIATEK
> > >   bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
> > >   select ARM_GIC
> > > + select PINCTRL
> > >   help
> > > Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
> > >  
> > > +config MACH_MT8173
> > > + bool "Mediatek 8173 Soc Supprt"
> > > + depends on ARCH_MEDIATEK
> > > + default y
> > > +
> > >  config ARCH_SEATTLE
> > >   bool "AMD Seattle SoC Family"
> > >   help
> > 
> > Hi Arnd/Matthias,
> > 
> > Any comments on this patch?
> 
> Hi Joe,
> 
> Actually I just commented on a similar patch from Samsung the other
> day, and I think we should make a more general decision about these:
> 
> I would rather see only one Kconfig option per SoC family and use
> ARCH_MEDIATEK without any MACH_* options. We can have other options
> for e.g. networking chips from Mediatek that are not closely related
> but I would group all the phone and tablet chips under one option
> here. Same for the other vendors of course.

I agree.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] x86/intel_rdt: Intel Cache Allocation Technology detection

[Borislav Petkov]

On Tue, Feb 24, 2015 at 04:42:10PM -0800, Vikas Shivappa wrote:
> >>+
> >>+   pr_info("cbmlength:%u,Closs: %u\n", cbm_len, maxid);
> >
> >This text message needs to be much more user-friendly if it is going out
> >to the console unconditionally.
> >
> 
> bit mask lengh:  number of CLOSids: ? . it should print with the module name
> as well which should help understand what it is for.

Right, if I haven't read the SDM on RDT, I still don't understand what
those mean. What is the need for that message at all, what is it telling
me?

Can you show an example from a machine with RDT and explain what it is
good for?

> >>+config CGROUP_RDT
> >>+   bool "Resource Director Technology cgroup subsystem"
> >>+   depends on X86_64
> >
> >depends on X86_64 && CPU_SUP_INTEL
> >
> >Also, this should probably also depend on CGROUP-something or so
> >AFAICT...
> 
> This is with in the if CGROUPS

Right, but you still need the CPU_SUP_INTEL dependency as !Intel x86
doesn't need that code built.

Thanks.

-- 
Regards/Gruss,
Boris.

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

[PATCH 1/3] clockevents: asm9260: Fix compilation error with sparc/sparc64 allyesconfig

[Daniel Lezcano]

The Kconfig options for the asm9260 timer is wrong as it can be selected by
another platform with allyes config and thus leading to a compilation failure
as some non arch related code is pulled by the compilation.

Fix this by having the platform Kconfig to select the timer as it is done for
the others drivers.

Signed-off-by: Daniel Lezcano 
Acked-by: Guenter Roeck 
Acked-by: Oleksij Rempel 

Conflicts:
drivers/clocksource/Kconfig
---
 arch/arm/mach-asm9260/Kconfig |  2 ++
 drivers/clocksource/Kconfig   | 16 +---
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-asm9260/Kconfig b/arch/arm/mach-asm9260/Kconfig
index 8423be7..5224120 100644
--- a/arch/arm/mach-asm9260/Kconfig
+++ b/arch/arm/mach-asm9260/Kconfig
@@ -2,5 +2,7 @@ config MACH_ASM9260
bool "Alphascale ASM9260"
depends on ARCH_MULTI_V5
select CPU_ARM926T
+   select ASM9260_TIMER
+   select GENERIC_CLOCKEVENTS
help
  Support for Alphascale ASM9260 based platform.
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 1c2506f..68161f7 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -63,6 +63,11 @@ config VT8500_TIMER
 config CADENCE_TTC_TIMER
bool
 
+config ASM9260_TIMER
+   bool
+   select CLKSRC_MMIO
+   select CLKSRC_OF
+
 config CLKSRC_NOMADIK_MTU
bool
depends on (ARCH_NOMADIK || ARCH_U8500)
@@ -245,15 +250,4 @@ config CLKSRC_PXA
help
  This enables OST0 support available on PXA and SA-11x0
  platforms.
-
-config ASM9260_TIMER
-   bool "Alphascale ASM9260 timer driver"
-   depends on GENERIC_CLOCKEVENTS
-   select CLKSRC_MMIO
-   select CLKSRC_OF
-   default y if MACH_ASM9260
-   help
- This enables build of a clocksource and clockevent driver for
- the 32-bit System Timer hardware available on a Alphascale ASM9260.
-
 endmenu
-- 
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 2/3] clocksource: mtk: Fix race conditions in probe code

[Daniel Lezcano]

From: Matthias Brugger 

We have two race conditions in the probe code which could lead to a null
pointer dereference in the interrupt handler.

The interrupt handler accesses the clockevent device, which may not yet be
registered.

First race condition happens when the interrupt handler gets registered before
the interrupts get disabled. The second race condition happens when the
interrupts get enabled, but the clockevent device is not yet registered.

Fix that by disabling the interrupts before we register the interrupt and enable
the interrupts after the clockevent device got registered.

Reported-by: Gongbae Park 
Signed-off-by: Matthias Brugger 
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/mtk_timer.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
index 32a3d25..68ab423 100644
--- a/drivers/clocksource/mtk_timer.c
+++ b/drivers/clocksource/mtk_timer.c
@@ -224,6 +224,8 @@ static void __init mtk_timer_init(struct device_node *node)
}
rate = clk_get_rate(clk);
 
+   mtk_timer_global_reset(evt);
+
if (request_irq(evt->dev.irq, mtk_timer_interrupt,
IRQF_TIMER | IRQF_IRQPOLL, "mtk_timer", evt)) {
pr_warn("failed to setup irq %d\n", evt->dev.irq);
@@ -232,8 +234,6 @@ static void __init mtk_timer_init(struct device_node *node)
 
evt->ticks_per_jiffy = DIV_ROUND_UP(rate, HZ);
 
-   mtk_timer_global_reset(evt);
-
/* Configure clock source */
mtk_timer_setup(evt, GPT_CLK_SRC, TIMER_CTRL_OP_FREERUN);
clocksource_mmio_init(evt->gpt_base + TIMER_CNT_REG(GPT_CLK_SRC),
@@ -241,10 +241,11 @@ static void __init mtk_timer_init(struct device_node 
*node)
 
/* Configure clock event */
mtk_timer_setup(evt, GPT_CLK_EVT, TIMER_CTRL_OP_REPEAT);
-   mtk_timer_enable_irq(evt, GPT_CLK_EVT);
-
clockevents_config_and_register(>dev, rate, 0x3,
0x);
+
+   mtk_timer_enable_irq(evt, GPT_CLK_EVT);
+
return;
 
 err_clk_disable:
-- 
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: Kprobes: pre-handler with interrupts enabled - is it possible?

[Eugene Shatokhin]

> (2015/02/24 15:04), Eugene Shatokhin wrote:

24.02.2015 06:47, Masami Hiramatsu пишет:

No, that is not allowed. I mean, you can do anything you want to do
on your handler (enabling preemption/irq etc.) but the result may be
not safe (it can crash your kernel, but it's not a kprobes' bug).


Yes, that is why I am asking.


Actually, enable interrupts on kprobe handlers can cause reentering
kprobes (by kprobes on interrupt handlers), and currently kprobe skips
all those reentered kprobes.
Is it acceptable that some of your kprobe handlers are not fired when
hitting?


I think, yes. When a software breakpoint hits, my system decodes the
instruction, finds the address that is about to be accessed and tries to
place a hardware breakpoint on that memory area.

There are only 4 hardware breakpoints a CPU can use on x86, so if the
software breakpoint hits too often, the system will not be able to
process all hits anyway because all HW breakpoints may be already in use.


Would you mean sleep on your handler??


No, I use mdelay(). It is, in essence, a busy-wait loop as far as I
know. The delay intervals may vary, the default is 5 jiffies.


Hmm, here I couldn't understand. If mdelay() does busy-wait loop, why
would you like to enable irq??
Other code doesn't work on the core while waiting.


I'd like not to enable IRQ but rather to execute my handler with the
same (or similar) restrictions as the original instruction would. If the
insn executed with IRQ enabled, so would the handler, etc. So I am
looking for a way to avoid *additionally* disabling IRQ (and, perhaps,
preemption, although this might be harder).

The breakpoints and delays already incur a penalty on the system's
responsiveness.
However, if, say, I probe an insn executing in a process context with
IRQs enabled, the interrupts may be served on this CPU during the delay.
If, additionally, preemption is not disabled and the kernel is built
with CONFIG_PREEMPT=y then, I guess, mdelay() can be preempted allowing
some other task to run, which is good for overall responsiveness.

Usually, the longer delays I make, the more likely the races are
detected but the performance overhead increases too. I do not have the
exact numbers yet, but still.

So, while 5-10 jiffies are often enough, sometimes it could be
beneficial to wait longer. For example, when I used the system to
confirm a race between .probe() and .ndo_open() callbacks in e1000
driver a year ago, I used the delay of about one second or more (for
NetworkManager to start working with the device), which is too much if
the IRQs were disabled, I think. Both .probe() and .ndo_open() executed
in process context, by the way.

Well, I was actually thinking about something like the following (for
x86, at least).

If a Kprobe's pre_handler returns non-zero, single-step will not be
performed, right? As far as I can see in the code, Jprobes rely on that.
Preemption will still be disabled and Jprobe's handler enables it when
ready.

What if I place a Kprobe on an insn of interest and the pre_handler
changes regs->ip to the address of my function, say, "my_thunk_pre" (see
below) then returns non-zero. Handling of int3 then completes, the
context is restored, the interrupts are re-enabled (if they were enabled
before int3). Preemption remains off because the Kprobe's implementation
disabled it. Execution resumes in "my_thunk_pre" that is written in
assembly and may look like this on x86_64 (x86_32 is similar):

--
my_thunk_pre:
push %rax


call my_handler
// my_handler() is a C function, with the default
// calling convention/linkage.
// Returns the address of the copied insn in the
// Kprobe's insn slot in %rax.



// restore the orig value of %rax and push the address
// to jump to on the stack
xchg %rax, (%rsp)

// Jump to the copied insn (and fix %rsp at the same time):
ret
--

In this case, my_handler() seems to execute in the same context as the
original insn, except for disabled preemption.

It may use kprobe_running() to get the Kprobe, and, perhaps, some my
structure that contains that Kprobe. Then, I guess, it might call
preempt_enable_no_resched() like Jprobe's handler does (may be some
other actions are needed?). After that, my_handler can do the rest of
its job: arm the HW breakpoints, call mdelay(), etc.

my_handler will return the address of the copied insn in the Kprobe's
insn slot. The control will be passed there by my_thunk_pre().

For this to work, it is needed that the copied insn stored in the
Kprobe's insn slot was followed by a jump back to the original code, to
the next insn, I mean. Of course, this is not necessary for some
control-transfer insns. But my system mostly works with the insns that
access data rather than with these.

Looks like Kprobes already do something similar and place such jumps in
the insn 

Re: [STLinux Kernel] [PATCH v3 7/8] rtc: st: add new driver for ST's LPC RTC

[Russell King - ARM Linux]

On Mon, Feb 23, 2015 at 10:12:23AM +, Peter Griffin wrote:
> I think all the writel IO accessors in this driver can be replaced
> with the *_relaxed variant. This will avoid the overhead of taking a
> spinlock in the l2 outer cache part of writel.

You're really operating on old information.  With much improved L2 cache
support code which went in a year or so ago, for the popular L2 cache
controllers, we don't take a spinlock anymore - we just write to the
register directly.

The spinlock is only present for L2C-220 controllers, which are rare.

Moreover, taking the spinlock is only expensive if you have things like
lockdep enabled, otherwise it should be inline and will be fast.

However, using the _relaxed variants where we can get away with weaker
ordering of the writes to the device is a good thing nevertheless.  I'm
just pointing out that your reasoning above is wrong.

-- 
FTTC broadband for 0.8mile line: currently at 10.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/

[PATCH 3/3] clocksource: pxa: Fix section mismatch

[Daniel Lezcano]

From: Robert Jarzmik 

As pxa_timer_common_init() is only called in init context, mark it as
such, and quiesce the compiler warnings :
WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:sched_clock_register()

WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:clocksource_mmio_init()

Signed-off-by: Robert Jarzmik 
Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/pxa_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 941f3f3..d9438af 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
.dev_id = _pxa_osmr0,
 };
 
-static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
+static void __init pxa_timer_common_init(int irq, unsigned long 
clock_tick_rate)
 {
timer_writel(0, OIER);
timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);
-- 
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 PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage.

[Wang Nan]

On 2015/2/20 11:59, Masami Hiramatsu wrote:
> Hi,
> 
> Sorry for replying late.
> 
> (2015/02/13 14:39), Wang Nan wrote:
>> I fell very sorry for people who reviewed my v2 patch series yesterday
>> at https://lkml.org/lkml/2015/2/12/234 because I didn't provide enough
>> information in commit log. This v3 patch series add those missing
>> commit messages. There are also 2 small fix based on v2:
>>
>>  1. Fixes ftrace_sort_mcount_area. Original patch doesn't work for module.
>>  2. Wraps setting of kprobes_initialized in stop_machine() context.
> 
> From the viewpoint of the maintenance, it seems over-engineered and
> not general implementation. Please reconsider just initializing breakpoint
> handler in earlier stage. Since those exceptions may happen anywhere,
> those trap handlers setup very early stage. E.g. on x86, setup_arch()
> setup early_trap_init() at beginning. So we just need to initialize
> kprobes earlier.

I tried as your suggestion. For x86, int3 handler doesn't work correctly until
trap_init(). I don't have enough time to look into this problem today (and I 
don't
familiar with x86 architecture). Could you please have a look on it?

Thank you.

> I think this is almost enough for debugging, and very general because
> we don't need optprobe for porting to other arch.
> 
> And for ftrace-based kprobe, we can just put breakpoint on mcount call at
> beginning. ftrace will need to check and keep it when replacing mcount-call
> with nop. Afterward, we can cleanly update those kprobes with ftrace-based
> kprobe.
> 
> So, please start with smaller changes.
> 
> Thank you,
> 


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

[GIT PULL][resend] clockevents fixes for 4.0-rc1

[Daniel Lezcano]

Hi Thomas, Ingo,

this pull request provides the following fixes for 4.0-rc1:

- Fix the Kconfig to prevent the asm9260 timer to be compiled with 
allyesconfig with sparc/sparc64 (Daniel Lezcano)


 - Reorder the mtk driver init sequence in order to prevent a potential 
race when the clock is registered before the irq handler is set 
(Matthias Brugger)


 - Fix a section mismatch for the pxa driver (Robert Jarzmik)

Thanks !

  -- Daniel

The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:

  Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)

are available in the git repository at:

  http://git.linaro.org/people/daniel.lezcano/linux.git clockevents/4.0-rc1

for you to fetch changes up to 6f2116ebe24f9f0f0d90ad17e405ea181f2499eb:

  clocksource: pxa: Fix section mismatch (2015-02-25 10:28:55 +0100)


Daniel Lezcano (1):
  clockevents: asm9260: Fix compilation error with sparc/sparc64 
allyesconfig


Matthias Brugger (1):
  clocksource: mtk: Fix race conditions in probe code

Robert Jarzmik (1):
  clocksource: pxa: Fix section mismatch

 arch/arm/mach-asm9260/Kconfig   |  2 ++
 drivers/clocksource/Kconfig | 16 +---
 drivers/clocksource/mtk_timer.c |  9 +
 drivers/clocksource/pxa_timer.c |  2 +-
 4 files changed, 13 insertions(+), 16 deletions(-)


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: mm: remove unused functions and variable protoypes

[Will Deacon]

On Wed, Feb 25, 2015 at 02:47:45AM +, Yingjoe Chen wrote:
> The functions __cpu_flush_user_tlb_range and __cpu_flush_kern_tlb_range
> were removed in commit fa48e6f780 'arm64: mm: Optimise tlb flush logic
> where we have >4K granule'. Global variable cpu_tlb was never used in
> arm64.
> 
> Remove them.
> 
> Signed-off-by: Yingjoe Chen 
> ---
>  arch/arm64/include/asm/tlbflush.h | 5 -
>  1 file changed, 5 deletions(-)

Acked-by: Will Deacon 

Will

> diff --git a/arch/arm64/include/asm/tlbflush.h 
> b/arch/arm64/include/asm/tlbflush.h
> index 73f0ce5..4abe9b9 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -24,11 +24,6 @@
>  #include 
>  #include 
>  
> -extern void __cpu_flush_user_tlb_range(unsigned long, unsigned long, struct 
> vm_area_struct *);
> -extern void __cpu_flush_kern_tlb_range(unsigned long, unsigned long);
> -
> -extern struct cpu_tlb_fns cpu_tlb;
> -
>  /*
>   *   TLB Management
>   *   ==
> -- 
> 1.8.1.1.dirty
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [STLinux Kernel] [PATCH v3 7/8] rtc: st: add new driver for ST's LPC RTC

[Lee Jones]

On Mon, 23 Feb 2015, Peter Griffin wrote:
> On Wed, 18 Feb 2015, Lee Jones wrote:
> 
> > ST's Low Power Controller (LPC) controls two devices; watchdog and RTC.
> > Only one of the devices can be used at any one time.  This is enforced
> > by the correlating MFD driver.  This portion of the driver-set controls
> > the Real Time Clock.
> 
> 
> 
> > +{
> > +   unsigned long flags;
> > +
> > +   spin_lock_irqsave(>lock, flags);
> > +
> > +   writel(1, rtc->ioaddr + LPC_WDT_OFF);
> > +
> > +   writel(msb, rtc->ioaddr + LPC_LPA_MSB_OFF);
> > +   writel(lsb, rtc->ioaddr + LPC_LPA_LSB_OFF);
> > +   writel(1, rtc->ioaddr + LPC_LPA_START_OFF);
> > +
> > +   writel(0, rtc->ioaddr + LPC_WDT_OFF);
> 
> I think all the writel IO accessors in this driver can be replaced
> with the *_relaxed variant. This will avoid the overhead of taking a
> spinlock in the l2 outer cache part of writel.

Yes, there is no technical reason why we can't use the relaxed
variants.  Will fix.

> > +#ifdef CONFIG_PM_SLEEP
> > +static int st_rtc_suspend(struct device *dev)
> > +{
> > +   struct st_rtc *rtc = dev_get_drvdata(dev);
> > +
> > +   if (device_may_wakeup(dev))
> > +   return 0;
> > +
> > +   writel(1, rtc->ioaddr + LPC_WDT_OFF);
> > +   writel(0, rtc->ioaddr + LPC_LPA_START_OFF);
> > +   writel(0, rtc->ioaddr + LPC_WDT_OFF);
> 
> Is there a reason for not disabling the IP clock in suspend / resume 
> functions?

There is.  It will stop the alarm timer, which is undesirable.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] Add MIPS EJTAG Fast Debug Channel TTY driver

[James Hogan]

Hi,

On 29/01/15 11:14, James Hogan wrote:
> This patchset adds a TTY, console, and KGDB driver for the MIPS Fast
> Debug Channel (FDC) hardware, for communicating with a debugger via an
> EJTAG probe. 16 TTY ports are created per FDC device, corresponding to
> the 16 FDC channels. Each VPE usually has its own FDC instance.

It'd be great to get these patches upstream for v4.1 via the MIPS tree
along with my other two patchsets it depends on ([v2] Add MIPS CDMM bus
support, and MIPS: Allow shared IRQ for timer & perf counter), so
Acks/Reviews from TTY maintainers in particular would be really
appreciated.

Btw, more info about the FDC can be found here:
http://www.linux-mips.org/wiki/FDC

And a git branch containing the latest version of all 3 patchsets
(basically just rebased on v4.0-rc1 to resolve conflicts) can be found
here:
git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git fdc

Thanks
James

> 
> This patchset depends on my recent CDMM bus patchset (the FDC is in the
> per-CPU CDMM region), and my recent MIPS timer & perf counter IRQ
> sharing patchset (the FDC IRQ is a local CPU IRQ which may similarly
> share CPU IRQ lines with the other local IRQs).
> 
> Patches 1 to 6 add the necessary architecture bits for the FDC
> interrupt, and a workaround in the MIPS idle code to avoid the wait
> instruction on certain cores if FDC driver is enabled.
> 
> Finally patches 7-9 add the main TTY/console driver, wire up some early
> console code, and implement KGDB operations & magic sysrq.
> 
> Cc: Ralf Baechle 
> Cc: Andrew Bresticker 
> Cc: Thomas Gleixner 
> Cc: Jason Cooper 
> Cc: Greg Kroah-Hartman 
> Cc: Jiri Slaby 
> Cc: Jason Wessel 
> Cc: linux-m...@linux-mips.org
> Cc: kgdb-bugrep...@lists.sourceforge.net
> 
> James Hogan (9):
>   MIPS: Add architectural FDC IRQ fields
>   MIPS: Read CPU IRQ line that FDC to routed to
>   irqchip: mips-gic: Don't treat FDC IRQ as percpu devid
>   irqchip: mips-gic: Add function for retrieving FDC IRQ
>   MIPS: Malta: Implement get_c0_fdc_int()
>   MIPS: idle: Workaround wait + FDC problems
>   tty: Add MIPS EJTAG Fast Debug Channel TTY driver
>   MIPS, ttyFDC: Add early FDC console support
>   ttyFDC: Implement KGDB IO operations.
> 
>  arch/mips/include/asm/cdmm.h |   11 +
>  arch/mips/include/asm/irq.h  |3 +
>  arch/mips/include/asm/mipsregs.h |4 +
>  arch/mips/kernel/idle.c  |   13 +-
>  arch/mips/kernel/setup.c |2 +
>  arch/mips/kernel/traps.c |   11 +
>  arch/mips/mti-malta/malta-time.c |   16 +
>  drivers/irqchip/irq-mips-gic.c   |   38 +-
>  drivers/tty/Kconfig  |   47 ++
>  drivers/tty/Makefile |1 +
>  drivers/tty/mips_ejtag_fdc.c | 1303 
> ++
>  include/linux/irqchip/mips-gic.h |1 +
>  12 files changed, 1443 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/tty/mips_ejtag_fdc.c
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 0/3] Add MIPS CDMM bus support

[James Hogan]

Hi,

On 02/02/15 11:45, James Hogan wrote:
> This patchset adds basic support for the MIPS Common Device Memory Map
> Memory (CDMM) region in the form of a bus in the standard Linux device
> model.

It'd be great to get these patches upstream for v4.1 via the MIPS tree
along with my other two related patchsets (MIPS: Allow shared IRQ for
timer & perf counter, and Add MIPS EJTAG Fast Debug Channel TTY driver).

Greg: Since this is a new bus I suspect I need your Ack/Review first?

Btw, more info about CDMM can be found here:
http://www.linux-mips.org/wiki/CDMM

And a git branch containing the latest version of all 3 patchsets
(basically just rebased on v4.0-rc1 to resolve conflicts) can be found
here:
git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git fdc

Thanks
James

> 
> Since the CDMM region is a feature of the MIPS architecture (since
> around MIPSr2) the first patch adds the necessary definitions and
> probing to arch/mips.
> 
> The second patch adds the actual bus driver (see that patch for lots
> more info). 
> 
> The final patch just enables CDMM to work on Malta.
> 
> Futher patches will follow soon to add TTY/Console/KGDB support for the
> EJTAG Fast Debug Channel (FDC) device which is found in the CDMM region.
> 
> Changes in v2:
> - Fix typo in definition of MIPS_CPU_CDMM, s/0ll/ull (Maciej).
> - Fix some checkpatch errors.
> - Correct CDMM name in various places. It is "Common Device Memory Map",
>   rather than "Common Device Mapped Memory" (which for some reason had
>   got stuck in my head).
> 
> Cc: Ralf Baechle 
> Cc: Greg Kroah-Hartman 
> Cc: linux-m...@linux-mips.org
> 
> James Hogan (3):
>   MIPS: Add arch CDMM definitions and probing
>   MIPS: Add CDMM bus support
>   MIPS: Malta: Implement mips_cdmm_phys_base()
> 
>  arch/mips/include/asm/cdmm.h |  87 +
>  arch/mips/include/asm/cpu-features.h |   4 +
>  arch/mips/include/asm/cpu.h  |   1 +
>  arch/mips/include/asm/mipsregs.h |  11 +
>  arch/mips/kernel/cpu-probe.c |   2 +
>  arch/mips/mti-malta/malta-memory.c   |   7 +
>  drivers/bus/Kconfig  |  13 +
>  drivers/bus/Makefile |   1 +
>  drivers/bus/mips_cdmm.c  | 711 
> +++
>  include/linux/mod_devicetable.h  |   8 +
>  scripts/mod/devicetable-offsets.c|   3 +
>  scripts/mod/file2alias.c |  16 +
>  12 files changed, 864 insertions(+)
>  create mode 100644 arch/mips/include/asm/cdmm.h
>  create mode 100644 drivers/bus/mips_cdmm.c
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/8 v2] ARM OMAP2+ GPMC: don't undef DEBUG

[Roger Quadros]

On 24/02/15 22:05, Robert ABEL wrote:
> OMAP2+ GPMC driver undefines DEBUG, which makes it unnecessarily
> hard to turn DEBUG on. Remove the offending lines.
> 
> Signed-off-by: Robert ABEL 

Acked-by: Roger Quadros 

cheers,
-roger

> ---
>  drivers/memory/omap-gpmc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index 24696f5..5cabac8 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -12,8 +12,6 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>   */
> -#undef DEBUG
> -
>  #include 
>  #include 
>  #include 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [lm-sensors] [PATCH 1/4] kernel.h: add find_closest() macro

[Bartosz Golaszewski]

2015-02-24 21:51 GMT+01:00 Guenter Roeck :
> I think the lm85 conversion actually introduces a bug with such an
> off-by-one mistake. And if it doesn't, there is still a unexplained
> and not easy to understand '-1' in one of the calls to find_closest().
>
> So the question is if the new code really improves the situation in that
> respect.

Yes, it's a mistake. I couldn't test this one and missed this '-1'.
Sorry for that.

As for the size comparisons - at first glance it seems as if it adds bloat:

ina2xx:
add/remove: 0/0 grow/shrink: 1/0 up/down: 24/0 (24)
function old new   delta
ina226_set_interval  296 320 +24

lm85:
add/remove: 0/0 grow/shrink: 3/0 up/down: 72/0 (72)
function old new   delta
set_temp_auto_temp_min   364 388 +24
set_temp_auto_temp_max   336 360 +24
set_pwm_freq 284 308 +24

w83795:
add/remove: 0/0 grow/shrink: 1/0 up/down: 16/0 (16)
function old new   delta
store_pwm496 512 +16

But this actually comes from DIV_ROUND_CLOSEST() since replacing it
with a simple '/ 2' gives different results:

ina2xx.ko:
add/remove: 0/0 grow/shrink: 1/0 up/down: 6/0 (6)
function old new   delta
__UNIQUE_ID_vermagic0 73  79  +6

lm85.ko:
add/remove: 0/0 grow/shrink: 1/0 up/down: 6/0 (6)
function old new   delta
__UNIQUE_ID_vermagic0 73  79  +6

w83795.ko:
add/remove: 0/0 grow/shrink: 2/0 up/down: 14/0 (14)
function old new   delta
store_pwm496 504  +8
__UNIQUE_ID_vermagic0 73  79  +6

The idea however was to remove duplicated operations from source files
and prevent off-by-one bugs (how ironic the lm85 patch...), not really
to reduce size.

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

Re: [PATCH 3/3] clocksource: pxa: Fix section mismatch

[Ingo Molnar]

* Daniel Lezcano  wrote:

> On 02/25/2015 11:48 AM, Ingo Molnar wrote:
> >
> >* Daniel Lezcano  wrote:
> >
> >>On 02/25/2015 11:35 AM, Ingo Molnar wrote:
> >>>
> >>>* Daniel Lezcano  wrote:
> >>>
> From: Robert Jarzmik 
> 
> As pxa_timer_common_init() is only called in init context, mark it as
> such, and quiesce the compiler warnings :
> WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
> from the function pxa_timer_common_init() to the function
> .init.text:sched_clock_register()
> 
> WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
> from the function pxa_timer_common_init() to the function
> .init.text:clocksource_mmio_init()
> 
> Signed-off-by: Robert Jarzmik 
> Signed-off-by: Daniel Lezcano 
> ---
>   drivers/clocksource/pxa_timer.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/pxa_timer.c 
> b/drivers/clocksource/pxa_timer.c
> index 941f3f3..d9438af 100644
> --- a/drivers/clocksource/pxa_timer.c
> +++ b/drivers/clocksource/pxa_timer.c
> @@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
>   .dev_id = _pxa_osmr0,
>   };
> 
> -static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
> +static void __init pxa_timer_common_init(int irq, unsigned long 
> clock_tick_rate)
>   {
>   timer_writel(0, OIER);
>   timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);
> >>>
> >>>So this is then used indirectly by:
> >>>
> >>>CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);
> >>>
> >>>which should probably be marked __initdata?
> >>
> >>
> >>Sorry, I miss the point. What should be marked __initdata ?
> >
> >so CLOCKSOURCE_OF_DECLARE() defines 'struct of_device_id'
> >entries, right? Those, if they are only used during
> >initialization, should be marked __initdata.
> >
> >Or are they mixed use?
> 
> Ah, ok. Thanks for the clarification. I thought there was 
> an issue with the patch and I was hanging the PR.

No, the patch is fine I think, I was just double checking 
it and noticed that nobody really marks 
CLOCKSOURCE_OF_DECLARE() as __initdata in practice.

> Let me look in details.

might not be worth doing, and it will quickly bitrot 
anyway, as new drivers might not pick it up.

Plus, should that structure ever get modularized, it will 
have to be removed again.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: macb: Add big endian CPU support

[Arun Chandran]

On Wed, Feb 25, 2015 at 3:32 PM, Michal Simek  wrote:
> On 02/24/2015 08:39 AM, Arun Chandran wrote:
>> This patch converts all __raw_readl and __raw_writel function calls
>> to their corresponding readl_relaxed and writel_relaxed variants.
>>
>> It also tells the driver to set ahb_endian_swp_mgmt_en bit in dma_cfg
>> when the cpu is configured in big endian mode.
>>
>> Signed-off-by: Arun Chandran 
>> ---
>>   This patch is tested on xilinx ZC702 evaluation board with
>>   CONFIG_CPU_BIG_ENDIAN=y and booting NFS rootfs
>>   Added on the fly IP endianness detection according to
>>   comments from Michal Simek.
>> ---
>> ---
>>  drivers/net/ethernet/cadence/macb.c | 33 +++--
>>  drivers/net/ethernet/cadence/macb.h | 15 ---
>>  2 files changed, 35 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb.c 
>> b/drivers/net/ethernet/cadence/macb.c
>> index ad76b8e..1642911 100644
>> --- a/drivers/net/ethernet/cadence/macb.c
>> +++ b/drivers/net/ethernet/cadence/macb.c
>> @@ -449,7 +449,7 @@ static void macb_update_stats(struct macb *bp)
>>   WARN_ON((unsigned long)(end - p - 1) != (MACB_TPF - MACB_PFR) / 4);
>>
>>   for(; p < end; p++, reg++)
>> - *p += __raw_readl(reg);
>> + *p += readl_relaxed(reg);
>>  }
>>
>>  static int macb_halt_tx(struct macb *bp)
>> @@ -1578,6 +1578,7 @@ static u32 macb_dbw(struct macb *bp)
>>  static void macb_configure_dma(struct macb *bp)
>>  {
>>   u32 dmacfg;
>> + u32 tmp, ncr;
>>
>>   if (macb_is_gem(bp)) {
>>   dmacfg = gem_readl(bp, DMACFG) & ~GEM_BF(RXBS, -1L);
>> @@ -1585,7 +1586,25 @@ static void macb_configure_dma(struct macb *bp)
>>   if (bp->dma_burst_length)
>>   dmacfg = GEM_BFINS(FBLDO, bp->dma_burst_length, 
>> dmacfg);
>>   dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
>> - dmacfg &= ~GEM_BIT(ENDIA);
>> + dmacfg &= ~GEM_BIT(ENDIA_PKT);
>> +
>> + /* Here we use the loopback bit of net_ctrl register to detect
>> +  * endianness on IP. save it first. Program swaped mode for
>> +  * management descriptor accesses if writing to loop back bit
>> +  * and reading it back brings no change in bit value.
>> +  */
>> + ncr = macb_readl(bp, NCR);
>> + __raw_writel(MACB_BIT(LLB), bp->regs + MACB_NCR);
>> + tmp =  __raw_readl(bp->regs + MACB_NCR);
>
>
> I have tested this patch on zc702 le and be and it is working.
> The comment is not fully accurate. Sorry I thought that you are using a 
> little bit different
> configuration than Zynq. The case I had in mind is that CPU and also IP can 
> have different endianness.
>
> The code above is not checking endianness on IP itself but CPU endianness 
> because IP is in little

Ok. I will change the comment.

> endian mode all the time. But the logic for detecting this on CPU is correct 
> and this is what
> you need to do on Zynq. You are writing big endian value to little endian 
> register and read it back
> to see if it was correctly written or not.

Just curious; will the same code work without change on a CPU with Big
endian IP?
(ie. If zynq hardware comes with only one change; IP configured in BE;
 will the driver be needing further changes?)

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

Re: [PATCH 3/3] clocksource: pxa: Fix section mismatch

[Daniel Lezcano]

On 02/25/2015 11:48 AM, Ingo Molnar wrote:


* Daniel Lezcano  wrote:


On 02/25/2015 11:35 AM, Ingo Molnar wrote:


* Daniel Lezcano  wrote:


From: Robert Jarzmik 

As pxa_timer_common_init() is only called in init context, mark it as
such, and quiesce the compiler warnings :
WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference

>from the function pxa_timer_common_init() to the function

.init.text:sched_clock_register()

WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference

>from the function pxa_timer_common_init() to the function

.init.text:clocksource_mmio_init()

Signed-off-by: Robert Jarzmik 
Signed-off-by: Daniel Lezcano 
---
  drivers/clocksource/pxa_timer.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 941f3f3..d9438af 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
.dev_id = _pxa_osmr0,
  };

-static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
+static void __init pxa_timer_common_init(int irq, unsigned long 
clock_tick_rate)
  {
timer_writel(0, OIER);
timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);


So this is then used indirectly by:

CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);

which should probably be marked __initdata?



Sorry, I miss the point. What should be marked __initdata ?


so CLOCKSOURCE_OF_DECLARE() defines 'struct of_device_id'
entries, right? Those, if they are only used during
initialization, should be marked __initdata.

Or are they mixed use?


Ah, ok. Thanks for the clarification. I thought there was an issue with 
the patch and I was hanging the PR.


Let me look in details.


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH 1/3] arm64: mediatek: Add config option for mt8173.

[Arnd Bergmann]

On Wednesday 25 February 2015 17:07:22 Yingjoe Chen wrote:
> On Tue, 2015-01-27 at 15:13 +0800, Hongzhou Yang wrote:
> > From: Hongzhou Yang 
> > 
> > The upcoming MTK pinctrl driver have a big pin table for each SoC,
> > and we don't want to bloat the kernel binary if we don't need it.
> > Add config options so we can build for one SoC only.
> > 
> > Signed-off-by: Hongzhou Yang 
> > ---
> >  arch/arm64/Kconfig | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index e627ead..6213dac 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -151,9 +151,15 @@ menu "Platform selection"
> >  config ARCH_MEDIATEK
> >   bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
> >   select ARM_GIC
> > + select PINCTRL
> >   help
> > Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
> >  
> > +config MACH_MT8173
> > + bool "Mediatek 8173 Soc Supprt"
> > + depends on ARCH_MEDIATEK
> > + default y
> > +
> >  config ARCH_SEATTLE
> >   bool "AMD Seattle SoC Family"
> >   help
> 
> Hi Arnd/Matthias,
> 
> Any comments on this patch?

Hi Joe,

Actually I just commented on a similar patch from Samsung the other
day, and I think we should make a more general decision about these:

I would rather see only one Kconfig option per SoC family and use
ARCH_MEDIATEK without any MACH_* options. We can have other options
for e.g. networking chips from Mediatek that are not closely related
but I would group all the phone and tablet chips under one option
here. Same for the other vendors of course.

Any other opinions?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/3] net: Linn Ethernet Packet Sniffer driver

[Stathis Voukelatos]

Hi Richard,

On 25/02/15 09:50, Richard Cochran wrote:


The Linux kernel already fully supports this kind of application via
the SIOCSHWTSTAMP, SO_TIMESTAMPING, and PHC mechanisms.  We certainly
don't need another another interface just for someone's warped
hardware design.

I suggest that you find a way to make your HW work within the existing
frame work.


The driver already uses that framework for returning timestamps to user 
space. It does not introduce any new interface.





The interface needs to be public so that a user-space application
can program a command string that will match packets that belong to
the audio stream of interest, for this example.


Let the user program simply use a BPF for that.


In addition returning just a timestamp would not be enough in many
cases. In the audio streaming use case mentioned above some
additional
bytes from the packet payload need to be returned (with Copy
commands) in order to associate the timestamp with a certain point
in the audio stream.


The time stamp is *already* associated with a particular frame.

Just tell your driver to program the hardware to:

1. time stamp every frame
2. deliver every frame

Thats all you need.



The H/W could not support that:
We have a "Match/Stamp" command, so the packet byte needs to match the 
value following the command, in order for a timestamp to be generated, 
otherwise the packet is dropped.
In addition, due to FIFO size limitations up to 128 bytes (including the 
timestamp) can be returned (through Copy commands) from each packet.


The module was designed to be able to configure it to sniff packets 
belonging to a certain application level stream and from each matching 
packet return a timestamp and some bytes (from eg. the application layer 
protocol header) that would be useful to the application.


BPF could accomplish that too, but timestamps will not be as accurate
without H/W support.

I understand that the device needs to be configured with a proprietary
command stream, but all interfacing with user-space is done using 
existing frameworks (AF_PACKET, SIOCSHWTSTAMP, cmsg)



Actually, that is how the H/W works. Each Match command is followed by
a data value which must match the packet data byte at the corresponding
location. If there is no match processing of the packet stops.


And just what is the "corresponding location"?


The command string is made up of a sequence of  pairs. Take 
this for example: {0x00, 0x00, 0x01, 0x55, 0x02, 0x00, 0x04, 0x00}.
First command is Don't Care (0x00), ie 1st byte of Ethernet frame is 
just skipped.
Second command is Match (0x01), ie if the 2nd byte of the Ethernet frame 
is 0x55 processing continues otherwise packet is dropped.
Third command is Copy (0x02), ie 3rd byte of the packet is copied to the 
H/W FIFO to be returned to the user
Fourth command is Copy/Done (0x04), ie 4th packet byte is also copied to 
the FIFO and processing stops.

Then an IRQ is generated, data (2 bytes) are read from the FIFO and
delivered through an AF_PACKET socket.

In v4 of the patch I tried to improve the documentation of some of these 
points.


Thanks,
Richard



Thanks,
Stathis

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/24] mm: use __SetPageSwapBacked and don't ClearPageSwapBacked

[Mel Gorman]

On Fri, Feb 20, 2015 at 07:56:15PM -0800, Hugh Dickins wrote:
> Commit 07a427884348 ("mm: shmem: avoid atomic operation during
> shmem_getpage_gfp") rightly replaced one instance of SetPageSwapBacked
> by __SetPageSwapBacked, pointing out that the newly allocated page is
> not yet visible to other users (except speculative get_page_unless_zero-
> ers, who may not update page flags before their further checks).
> 
> That was part of a series in which Mel was focused on tmpfs profiles:
> but almost all SetPageSwapBacked uses can be so optimized, with the
> same justification.  And remove the ClearPageSwapBacked from
> read_swap_cache_async()'s and zswap_get_swap_cache_page()'s error
> paths: it's not an error to free a page with PG_swapbacked set.
> 
> (There's probably scope for further __SetPageFlags in other places,
> but SwapBacked is the one I'm interested in at the moment.)
> 
> Signed-off-by: Hugh Dickins 
> ---
>  mm/migrate.c|6 +++---
>  mm/rmap.c   |2 +-
>  mm/shmem.c  |4 ++--
>  mm/swap_state.c |3 +--
>  mm/zswap.c  |3 +--
>  5 files changed, 8 insertions(+), 10 deletions(-)
> 
> 
> --- thpfs.orig/mm/shmem.c 2015-02-08 18:54:22.0 -0800
> +++ thpfs/mm/shmem.c  2015-02-20 19:33:35.676074594 -0800
> @@ -987,8 +987,8 @@ static int shmem_replace_page(struct pag
>   flush_dcache_page(newpage);
>  
>   __set_page_locked(newpage);
> + __SetPageSwapBacked(newpage);
>   SetPageUptodate(newpage);
> - SetPageSwapBacked(newpage);
>   set_page_private(newpage, swap_index);
>   SetPageSwapCache(newpage);
>  

It's clear why you did this but ...

> @@ -1177,8 +1177,8 @@ repeat:
>   goto decused;
>   }
>  
> - __SetPageSwapBacked(page);
>   __set_page_locked(page);
> + __SetPageSwapBacked(page);
>   if (sgp == SGP_WRITE)
>   __SetPageReferenced(page);
>  

It's less clear why this was necessary. I don't think it causes any
problems though so

Reviewed-by: Mel Gorman 

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

Re: [patch v2 for-4.0] mm, thp: really limit transparent hugepage allocation to local node

[Vlastimil Babka]

On 02/25/2015 12:24 AM, David Rientjes wrote:

From: Greg Thelen 

Commit 077fcf116c8c ("mm/thp: allocate transparent hugepages on local
node") restructured alloc_hugepage_vma() with the intent of only
allocating transparent hugepages locally when there was not an effective
interleave mempolicy.

alloc_pages_exact_node() does not limit the allocation to the single
node, however, but rather prefers it.  This is because __GFP_THISNODE is
not set which would cause the node-local nodemask to be passed.  Without
it, only a nodemask that prefers the local node is passed.


Oops, good catch.
But I believe we have the same problem with khugepaged_alloc_page(), 
rendering the recent node determination and zone_reclaim strictness 
patches partially useless.


Then I start to wonder about other alloc_pages_exact_node() users. Some 
do pass __GFP_THISNODE, others not - are they also mistaken? I guess the 
function is a misnomer - when I see "exact_node", I expect the 
__GFP_THISNODE behavior.


I think to avoid such hidden catches, we should create 
alloc_pages_preferred_node() variant, change the exact_node() variant to 
pass __GFP_THISNODE, and audit and adjust all callers accordingly.


Also, you pass __GFP_NOWARN but that should be covered by GFP_TRANSHUGE 
already. Of course, nothing guarantees that hugepage == true implies 
that gfp == GFP_TRANSHUGE... but current in-tree callers conform to that.



Fix this by passing __GFP_THISNODE and falling back to small pages when
the allocation fails.

Fixes: 077fcf116c8c ("mm/thp: allocate transparent hugepages on local node")
Signed-off-by: Greg Thelen 
Signed-off-by: David Rientjes 
---
  v2: GFP_THISNODE actually defers compaction and reclaim entirely based on
  the combination of gfp flags.  We want to try compaction and reclaim,
  so only set __GFP_THISNODE.  We still set __GFP_NOWARN to suppress
  oom warnings in the kernel log when we can simply fallback to small
  pages.

  mm/mempolicy.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1985,7 +1985,10 @@ retry_cpuset:
nmask = policy_nodemask(gfp, pol);
if (!nmask || node_isset(node, *nmask)) {
mpol_cond_put(pol);
-   page = alloc_pages_exact_node(node, gfp, order);
+   page = alloc_pages_exact_node(node, gfp |
+   __GFP_THISNODE |
+   __GFP_NOWARN,
+ order);
goto out;
}
}



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

Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs

[Ingo Molnar]

* Borislav Petkov  wrote:

> On Tue, Feb 24, 2015 at 04:07:07PM -0800, Andy Lutomirski wrote:
>
> > I'd prefer a different partial solution: encourage 
> > everyone to clear the xstate before making syscalls 
> > (using e.g. vzeroall).  In fact, maybe user code should 
> > aggressively clear newly-unused xstate.
> 
> We don't trust userspace.

We certainly don't, but in this case it's a performance 
optimization detail: if user-space clears unused xstate in 
a way that the CPU recognizes it (for example VZEROALL) 
then it might get faster context switches.

Thanks,

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

Re: [PATCH 3/3] clocksource: pxa: Fix section mismatch

[Ingo Molnar]

* Daniel Lezcano  wrote:

> On 02/25/2015 11:35 AM, Ingo Molnar wrote:
> >
> >* Daniel Lezcano  wrote:
> >
> >>From: Robert Jarzmik 
> >>
> >>As pxa_timer_common_init() is only called in init context, mark it as
> >>such, and quiesce the compiler warnings :
> >>WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
> >>from the function pxa_timer_common_init() to the function
> >>.init.text:sched_clock_register()
> >>
> >>WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
> >>from the function pxa_timer_common_init() to the function
> >>.init.text:clocksource_mmio_init()
> >>
> >>Signed-off-by: Robert Jarzmik 
> >>Signed-off-by: Daniel Lezcano 
> >>---
> >>  drivers/clocksource/pxa_timer.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/clocksource/pxa_timer.c 
> >>b/drivers/clocksource/pxa_timer.c
> >>index 941f3f3..d9438af 100644
> >>--- a/drivers/clocksource/pxa_timer.c
> >>+++ b/drivers/clocksource/pxa_timer.c
> >>@@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
> >>.dev_id = _pxa_osmr0,
> >>  };
> >>
> >>-static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
> >>+static void __init pxa_timer_common_init(int irq, unsigned long 
> >>clock_tick_rate)
> >>  {
> >>timer_writel(0, OIER);
> >>timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);
> >
> >So this is then used indirectly by:
> >
> >CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);
> >
> >which should probably be marked __initdata?
> 
> 
> Sorry, I miss the point. What should be marked __initdata ?

so CLOCKSOURCE_OF_DECLARE() defines 'struct of_device_id' 
entries, right? Those, if they are only used during 
initialization, should be marked __initdata.

Or are they mixed use?

Thnks,

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

Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs

[Ingo Molnar]

* Andy Lutomirski  wrote:

> > I'm a big fan of simplifying things, but.
> >
> > SIMD registers were growing in x86, and they are going 
> > to grow again, this time four-fold in Intel MIC: from 
> > sixteen 256-bit registers to thirty two 512-bit 
> > registers.
> >
> > That's 2 kbytes of data. Just moving this data out 
> > to/from memory will take some time.
> >
> > And some people talk about 1024-bit registers 
> > already...
> >
> > Let's not completely remove lazy FPU saving code just 
> > yet. Maybe we'll be forced to reinstate it.
> 
> I'd prefer a different partial solution: encourage 
> everyone to clear the xstate before making syscalls 
> (using e.g. vzeroall).  In fact, maybe user code should 
> aggressively clear newly-unused xstate.

Also, xstate has various compaction features and could grow 
new ones in the future as well, should the xsave area 
become overly sparse: see xstate_comp_*[] et al in 
arch/x86/kernel/xsave.c.

This is the better, hardware driven, synchronous 
alternative to lazy, async register state save/restore, as 
it gets us similar benefits of not saving/restoring unused 
space, but avoids any async trap overhead.

Also ... with more and wider vector CPU registers context 
switches between different sets of registers are going to 
be inevitably more expensive, no matter what.

Thanks,

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

Re: [PATCH 3/3] clocksource: pxa: Fix section mismatch

[Daniel Lezcano]

On 02/25/2015 11:35 AM, Ingo Molnar wrote:


* Daniel Lezcano  wrote:


From: Robert Jarzmik 

As pxa_timer_common_init() is only called in init context, mark it as
such, and quiesce the compiler warnings :
WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:sched_clock_register()

WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:clocksource_mmio_init()

Signed-off-by: Robert Jarzmik 
Signed-off-by: Daniel Lezcano 
---
  drivers/clocksource/pxa_timer.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 941f3f3..d9438af 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
.dev_id = _pxa_osmr0,
  };

-static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
+static void __init pxa_timer_common_init(int irq, unsigned long 
clock_tick_rate)
  {
timer_writel(0, OIER);
timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);


So this is then used indirectly by:

CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);

which should probably be marked __initdata?



Sorry, I miss the point. What should be marked __initdata ?


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/8 v2] ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters

[Roger Quadros]

Robert,

On 24/02/15 22:05, Robert ABEL wrote:
> GPMC_CONFIG1_i parameters CLKACTIVATIONTIME and WAITMONITORINGTIME
> have reserved values.
> Raise an error if calculated timings try to program reserved values.
> 
> GPMC_CONFIG1_i ATTCHEDDEVICEPAGELENGTH and DEVICESIZE were already checked

typo ATTCHEDDEVICEPAGELENGTH->ATTACHEDDEVICEPAGELENGTH

> when parsing the DT.
> 
> Explicitly comment invalid values on gpmc_cs_show_timings for
> -CLKACTIVATIONTIME
> -WAITMONITORINGTIME
> -DEVICESIZE
> -ATTACHEDDEVICEPAGELENGTH
> 
> Signed-off-by: Robert ABEL 
> ---
>  drivers/memory/omap-gpmc.c | 69 
> ++
>  1 file changed, 46 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index 6591991..cc2e6d0 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -135,6 +135,8 @@
>  #define GPMC_CONFIG1_WRITETYPE_ASYNC(0 << 27)
>  #define GPMC_CONFIG1_WRITETYPE_SYNC (1 << 27)
>  #define GPMC_CONFIG1_CLKACTIVATIONTIME(val) ((val & 3) << 25)
> +/** CLKACTIVATIONTIME Max Ticks */
> +#define GPMC_CONFIG1_CLKACTIVATIONTIME_MAX 2
>  #define GPMC_CONFIG1_PAGE_LEN(val)  ((val & 3) << 23)
>  #define GPMC_CONFIG1_WAIT_READ_MON  (1 << 22)
>  #define GPMC_CONFIG1_WAIT_WRITE_MON (1 << 21)
> @@ -144,6 +146,8 @@
>  #define GPMC_CONFIG1_WAIT_PIN_SEL(val)  ((val & 3) << 16)
>  #define GPMC_CONFIG1_DEVICESIZE(val)((val & 3) << 12)
>  #define GPMC_CONFIG1_DEVICESIZE_16  GPMC_CONFIG1_DEVICESIZE(1)
> +/** DEVICESIZE Max Value */
> +#define GPMC_CONFIG1_DEVICESIZE_MAX GPMC_CONFIG1_DEVICESIZE_16

Shouldn't this be 1 instead? I'm hoping max value is without the shift
based on GPMC_CONFIG1_CLKACTIVATIONTIME_MAX.

>  #define GPMC_CONFIG1_DEVICETYPE(val)((val & 3) << 10)
>  #define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
>  #define GPMC_CONFIG1_MUXTYPE(val)   ((val & 3) << 8)
> @@ -394,18 +398,21 @@ static void gpmc_cs_bool_timings(int cs, const struct 
> gpmc_bool_timings *p)
>   * @reg GPMC_CS_CONFIGn register offset.
>   * @st_bit  Start Bit
>   * @end_bit End Bit. Must be >= @st_bit.
> + * @max Maximum parameter value (after optional @shift).

max should be absolute value, without the shift.

> + *  If 0, maximum is as high as @st_bit and @end_bit allow.
>   * @nameDTS node name, w/o "gpmc,"
>   * @cd  Clock Domain of timing parameter.
>   * @shift   Parameter value left shifts @shift, which is then printed 
> instead of value.
>   * @raw Raw Format Option.
>   *  raw format:  gpmc,name = 
>   *  tick format: gpmc,name =  /* x ticks */
> + *  When @max is exceeded, "invalid" is printed inside comment.
>   * @noval   Parameter values equal to 0 are not printed.
>   *
>   */
>  static int get_gpmc_timing_reg(
>   /* timing specifiers */
> - int cs, int reg, int st_bit, int end_bit,
> + int cs, int reg, int st_bit, int end_bit, int max,
>   const char *name, const enum gpmc_clk_domain cd,
>   /* value transform */
>   int shift,
> @@ -415,11 +422,15 @@ static int get_gpmc_timing_reg(
>   u32 l;
>   int nr_bits;
>   int mask;
> + bool invalid;
>  
>   l = gpmc_cs_read_reg(cs, reg);
>   nr_bits = end_bit - st_bit + 1;
>   mask = (1 << nr_bits) - 1;;
>   l = (l >> st_bit) & mask;
> + if (!max)
> + max = mask;
> + invalid = l > max;
>   if (shift)
>   l = (shift << l);
>   if (noval && (l == 0))
> @@ -429,11 +440,11 @@ static int get_gpmc_timing_reg(
>   unsigned int time_ns;
>  
>   time_ns = gpmc_clk_ticks_to_ns(l, cs, cd);
> - pr_info("gpmc,%s = <%u> /* %i ticks */\n",
> - name, time_ns, l);
> + pr_info("gpmc,%s = <%u> /* %i ticks %s*/\n",
> + name, time_ns, l, invalid ? "; invalid " : "");
>   } else {
>   /* raw format */
> - pr_info("gpmc,%s = <%u>\n", name, l);
> + pr_info("gpmc,%s = <%u>%s\n", name, l, invalid ? " /* invalid 
> */" : "");
>   }
>  
>   return l;
> @@ -443,15 +454,19 @@ static int get_gpmc_timing_reg(
>   pr_info("cs%i %s: 0x%08x\n", cs, #config, \
>   gpmc_cs_read_reg(cs, config))
>  #define GPMC_GET_RAW(reg, st, end, field) \
> - get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK, 0, 1, 
> 0)
> + get_gpmc_timing_reg(cs, (reg), (st), (end), 0, field, GPMC_CD_FCLK, 0, 
> 1, 0)
> +#define GPMC_GET_RAW_MAX(reg, st, end, max, field) \
> + get_gpmc_timing_reg(cs, (reg), (st), (end), (max), field, GPMC_CD_FCLK, 
> 0, 1, 0)
>  #define GPMC_GET_RAW_BOOL(reg, st, end, field) \
> - get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK, 0, 1, 
> 1)
> -#define GPMC_GET_RAW_SHIFT(reg, st, end, shift, field) \
> - get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK, 
> (shift), 1, 1)
> + 

Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs

[Borislav Petkov]

On Tue, Feb 24, 2015 at 04:07:07PM -0800, Andy Lutomirski wrote:
> I'd prefer a different partial solution: encourage everyone to clear
> the xstate before making syscalls (using e.g. vzeroall).  In fact,
> maybe user code should aggressively clear newly-unused xstate.

We don't trust userspace.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH v2] mmc: dw_mmc: rockchip: add support MMC_CAP_RUNTIME_RESUME capability

[Jaehoon Chung]

Hi, Addy.

Acked-by: Jaehoon Chung 

Thanks!

Best Regards,
Jaehoon Chung

On 02/20/2015 11:37 AM, Addy Ke wrote:
> To support HS200 and UHS mode, mmc core will call init_card() to
> execute tuning:
> - sdio: init_card can be executed at runtime resume.
> - sd and mmc: init_card can be executed at resume or runtime resume,
>   which depends on MMC_CAP_RUNTIME_RESUME capability.
> 
> On rk3288 SoC, host will get DRTO interrupt when host send command
> to read tuning data. This will spend more than 111ms:
> drto_ms = drto_clks * 1000 / bus_hz = 111ms.
> 
> And the total tuning time will be more than 400ms.
> 
> So we should add MMC_CAP_RUNTIME_RESUME capability to execute tuning
> at runtime resume. Only if we do so, can we pass resume test.
> 
> Reviewed-by: Doug Anderson 
> Signed-off-by: Addy Ke 
> ---
> Changes in v2:
> - add this capability for all 4 slots, suggested by Doug Anderson.
> 
>  drivers/mmc/host/dw_mmc-rockchip.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/mmc/host/dw_mmc-rockchip.c 
> b/drivers/mmc/host/dw_mmc-rockchip.c
> index e2a726a..dbf166f 100644
> --- a/drivers/mmc/host/dw_mmc-rockchip.c
> +++ b/drivers/mmc/host/dw_mmc-rockchip.c
> @@ -76,12 +76,20 @@ static int dw_mci_rockchip_init(struct dw_mci *host)
>   return 0;
>  }
>  
> +/* Common capabilities of RK3288 SoC */
> +static unsigned long dw_mci_rk3288_dwmmc_caps[4] = {
> + MMC_CAP_RUNTIME_RESUME, /* emmc */
> + MMC_CAP_RUNTIME_RESUME, /* sdmmc */
> + MMC_CAP_RUNTIME_RESUME, /* sdio0 */
> + MMC_CAP_RUNTIME_RESUME, /* sdio1 */
> +};
>  static const struct dw_mci_drv_data rk2928_drv_data = {
>   .prepare_command= dw_mci_rockchip_prepare_command,
>   .init   = dw_mci_rockchip_init,
>  };
>  
>  static const struct dw_mci_drv_data rk3288_drv_data = {
> + .caps   = dw_mci_rk3288_dwmmc_caps,
>   .prepare_command= dw_mci_rockchip_prepare_command,
>   .set_ios= dw_mci_rk3288_set_ios,
>   .setup_clock= dw_mci_rk3288_setup_clock,
> 

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

Re: [PATCH 3/3] clocksource: pxa: Fix section mismatch

[Ingo Molnar]

* Daniel Lezcano  wrote:

> From: Robert Jarzmik 
> 
> As pxa_timer_common_init() is only called in init context, mark it as
> such, and quiesce the compiler warnings :
> WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
> from the function pxa_timer_common_init() to the function
> .init.text:sched_clock_register()
> 
> WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
> from the function pxa_timer_common_init() to the function
> .init.text:clocksource_mmio_init()
> 
> Signed-off-by: Robert Jarzmik 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/clocksource/pxa_timer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
> index 941f3f3..d9438af 100644
> --- a/drivers/clocksource/pxa_timer.c
> +++ b/drivers/clocksource/pxa_timer.c
> @@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
>   .dev_id = _pxa_osmr0,
>  };
>  
> -static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
> +static void __init pxa_timer_common_init(int irq, unsigned long 
> clock_tick_rate)
>  {
>   timer_writel(0, OIER);
>   timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);

So this is then used indirectly by:

CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);

which should probably be marked __initdata?

Thanks,

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

Re: [RFC][PATCH v2] sched/rt: Use IPI to trigger RT task push migration instead of pulling

[Peter Zijlstra]

On Tue, Feb 24, 2015 at 01:39:46PM -0500, Steven Rostedt wrote:
> Index: linux-rt.git/kernel/sched/rt.c
> ===
> --- linux-rt.git.orig/kernel/sched/rt.c   2015-02-24 10:44:08.798785452 
> -0500
> +++ linux-rt.git/kernel/sched/rt.c2015-02-24 13:07:20.154735448 -0500

> @@ -1760,11 +1771,171 @@ static void push_rt_tasks(struct rq *rq)
>   ;
>  }
>  
> +static void tell_cpu_to_push(int cpu, struct rq *rq, int prio)
> +{
> + /* We should never be here if the IPI is already out. */
> + BUG_ON(rq->rt.push_csd_pending);
> +
> + rq->rt.push_csd_pending = 1;
> + rq->rt.push_csd_cpu = cpu;
> + /* Save the prio that we used to find this CPU */
> + rq->rt.push_csd_prio = prio;
> +
> + /* Make sure csd_cpu is visible before we send the ipi */
> + smp_mb();

We've architecturally defined the raising of interrupts vs the execution
of the handler to be a serializing event, therefore this full barrier is
not required.

I think we documented it in places, but I never can find it.

> +
> + smp_call_function_single_async(cpu, >rt.push_csd);

I'm confused why are you mixing smp_call_function_single_async() and
irq_work_queue_on() in the same logic?

Pick one and stick to it.

Also: 
lkml.kernel.org/r/ca+55afz492bzlfhdbkn-hygjcreup7cjmeyk3ntsfrwjppz...@mail.gmail.com

Now I would suggest you use irq_wok_queue_on() for this, consistently,
because irq_works are ran after the smp function calls complete and
therefore minimize the latency for people waiting on the (sync) smp
function calls.

> +}
> +
> +static void try_to_push_tasks(void *arg)
> +{
> + struct rt_rq *rt_rq = arg;
> + struct rq *rq, *next_rq;
> + int next_cpu = -1;
> + int next_prio = MAX_PRIO + 1;
> + int this_prio;
> + int src_prio;
> + int prio;
> + int this_cpu;
> + int success;
> + int cpu;
> +
> + /* Make sure we can see csd_cpu */
> + smp_rmb();

As per the above, interrupt are serializing, this is not needed.

> +
> + this_cpu = rt_rq->push_csd_cpu;
> +
> + /* Paranoid check */
> + BUG_ON(this_cpu != smp_processor_id());
> +
> + rq = cpu_rq(this_cpu);
> +
> + /*
> +  * If there's nothing to push here, then see if another queue
> +  * can push instead.
> +  */
> + if (!has_pushable_tasks(rq))
> + goto pass_the_ipi;
> +
> + raw_spin_lock(>lock);
> + success = push_rt_task(rq);
> + raw_spin_unlock(>lock);
> +
> + if (success)
> + goto done;
> +
> + /* Nothing was pushed, try another queue */
> +pass_the_ipi:
> +
> + /*
> +  * We use the priority that determined to send to this CPU
> +  * even if the priority for this CPU changed. This is used
> +  * to determine what other CPUs to send to, to keep from
> +  * doing a ping pong from each CPU.
> +  */
> + this_prio = rt_rq->push_csd_prio;
> + src_prio = rt_rq->highest_prio.curr;

Should we, at this point, not check if the condition that triggered the
pull request is still valid on our src cpu? No point in continuing our
IPI chain if the CPU we're looking for work for is no longer interested
in it.

> + for_each_cpu(cpu, rq->rd->rto_mask) {
> + if (this_cpu == cpu)
> + continue;
> +
> + /*
> +  * This function was called because some rq lowered its
> +  * priority. It then searched for the highest priority
> +  * rq that had overloaded tasks and sent an smp function
> +  * call to that cpu to call this function to push its
> +  * tasks. But when it got here, the task was either
> +  * already pushed, or due to affinity, could not move
> +  * the overloaded task.
> +  *
> +  * Now we need to see if there's another overloaded rq that
> +  * has an RT task that can migrate to that CPU.
> +  *
> +  * We need to be careful, we do not want to cause a ping
> +  * pong between this CPU and another CPU that has an RT task
> +  * that can migrate, but not to the CPU that lowered its
> +  * priority. Since the lowering priority CPU finds the highest
> +  * priority rq to send to, we will ignore any rq that is of 
> higher
> +  * priority than this current one. 

Maybe start a new paragraph here?

   That is, if a rq scheduled a
> +  * task of higher priority, the schedule itself would do the
> +  * push or pull then. We can safely ignore higher priority rqs.
> +  * And if there's one that is the same priority, since the CPUS
> +  * are searched in order we will ignore CPUS of the same 
> priority
> +  * unless the CPU number is greater than this CPU's number.
> +  */

I would s/CPUS/CPUs/ the plural is not part of the