[PATCH 5/5] arm: dts: mt2701: Add usb3 device nodes
From: Chunfeng Yun
Add xhci nodes and usb3 phy nodes for MT2701
Signed-off-by: Chunfeng Yun
Signed-off-by: Erin Lo
---
arch/arm/boot/dts/mt2701.dtsi | 79 +++
1 file changed, 79 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index efb5118..16242f5 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -13,6 +13,7 @@
*/
#include
+#include
#include
#include
#include
@@ -677,6 +678,84 @@
#clock-cells = <1>;
};
+ usb0: usb@1a1c {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1a1c 0 0x1000>,
+ <0 0x1a1c4700 0 0x0100>;
+ reg-names = "mac", "ippc";
+ interrupts = ;
+ clocks = <&hifsys CLK_HIFSYS_USB0PHY>,
+<&topckgen CLK_TOP_ETHIF_SEL>;
+ clock-names = "sys_ck", "ref_ck";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_HIF>;
+ phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
+ status = "disabled";
+ };
+
+ u3phy0: usb-phy@1a1c4000 {
+ compatible = "mediatek,mt2701-u3phy";
+ reg = <0 0x1a1c4000 0 0x0700>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ u2port0: usb-phy@1a1c4800 {
+ reg = <0 0x1a1c4800 0 0x0100>;
+ clocks = <&topckgen CLK_TOP_USB_PHY48M>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u3port0: usb-phy@1a1c4900 {
+ reg = <0 0x1a1c4900 0 0x0700>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
+
+ usb1: usb@1a24 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1a24 0 0x1000>,
+ <0 0x1a244700 0 0x0100>;
+ reg-names = "mac", "ippc";
+ interrupts = ;
+ clocks = <&hifsys CLK_HIFSYS_USB1PHY>,
+<&topckgen CLK_TOP_ETHIF_SEL>;
+ clock-names = "sys_ck", "ref_ck";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_HIF>;
+ phys = <&u2port1 PHY_TYPE_USB2>, <&u3port1 PHY_TYPE_USB3>;
+ status = "disabled";
+ };
+
+ u3phy1: usb-phy@1a244000 {
+ compatible = "mediatek,mt2701-u3phy";
+ reg = <0 0x1a244000 0 0x0700>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ u2port1: usb-phy@1a244800 {
+ reg = <0 0x1a244800 0 0x0100>;
+ clocks = <&topckgen CLK_TOP_USB_PHY48M>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u3port1: usb-phy@1a244900 {
+ reg = <0 0x1a244900 0 0x0700>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
+
ethsys: syscon@1b00 {
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b00 0 0x1000>;
--
1.9.1
[PATCH 0/5] Add some DT nodes for Mediatek MT2701
This patch series based on v4.13-rc1, include MT2701 ethernet/disp bls/display/usb3 function DT nodes. Chunfeng Yun (1): arm: dts: mt2701: Add usb3 device nodes Sean Wang (1): arm: dts: mt2701: Add ethernet device node Weiqing Kong (2): arm: dts: mt2701: Add display bls related nodes for MT2701 arm: dts: mt2701: Add display bls related nodes for MT2701 YT Shen (1): arm: dts: mt2701: Add display subsystem related nodes for MT2701 arch/arm/boot/dts/mt2701-evb.dts | 27 ++ arch/arm/boot/dts/mt2701.dtsi| 189 +++ 2 files changed, 216 insertions(+) -- 1.9.1
[PATCH 1/5] arm: dts: mt2701: Add ethernet device node
From: Sean Wang
Add ethernet device node for MT2701
Signed-off-by: Sean Wang
Signed-off-by: Erin Lo
---
arch/arm/boot/dts/mt2701.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index f1efdc6..0619b86 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -597,6 +597,30 @@
#clock-cells = <1>;
};
+ eth: ethernet@1b10 {
+ compatible = "mediatek,mt2701-eth", "syscon";
+ reg = <0 0x1b10 0 0x2>;
+ interrupts = ,
+,
+;
+ clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
+<ðsys CLK_ETHSYS_ESW>,
+<ðsys CLK_ETHSYS_GP1>,
+<ðsys CLK_ETHSYS_GP2>,
+<&apmixedsys CLK_APMIXED_TRGPLL>;
+ clock-names = "ethif", "esw", "gp1", "gp2", "trgpll";
+ resets = <ðsys MT2701_ETHSYS_FE_RST>,
+<ðsys MT2701_ETHSYS_GMAC_RST>,
+<ðsys MT2701_ETHSYS_PPE_RST>;
+ reset-names = "fe", "gmac", "ppe";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
+ mediatek,ethsys = <ðsys>;
+ mediatek,pctl = <&syscfg_pctl_a>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
bdpsys: syscon@1c00 {
compatible = "mediatek,mt2701-bdpsys", "syscon";
reg = <0 0x1c00 0 0x1000>;
--
1.9.1
[PATCH 2/5] arm: dts: mt2701: Add display bls related nodes for MT2701
From: Weiqing Kong
This patch adds the device node of display backlight for MT2701
Signed-off-by: Weiqing Kong
Signed-off-by: Erin Lo
---
arch/arm/boot/dts/mt2701.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 0619b86..2bcf739 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -529,6 +529,15 @@
#clock-cells = <1>;
};
+ bls: bls@1400a000 {
+ compatible = "mediatek,mt2701-disp-pwm";
+ reg = <0 0x1400a000 0 0x1000>;
+ #pwm-cells = <2>;
+ clocks = <&mmsys CLK_MM_MDP_BLS_26M>, <&mmsys CLK_MM_DISP_BLS>;
+ clock-names = "main", "mm";
+ status = "disabled";
+ };
+
larb0: larb@1401 {
compatible = "mediatek,mt2701-smi-larb";
reg = <0 0x1401 0 0x1000>;
--
1.9.1
linux-kernel@vger.kernel.org
This patch is created to solve the coding style issues reported
by the checkpatch script.
Signed-off-by: Janani Sankara Babu
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 647a922..66d4e6c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -119,7 +119,7 @@ static void update_BCNTIM(struct adapter *padapter)
}
*dst_ie++ = _TIM_IE_;
- if ((pstapriv->tim_bitmap&0xff00) && (pstapriv->tim_bitmap&0x00fc))
+ if ((pstapriv->tim_bitmap & 0xff00) && (pstapriv->tim_bitmap & 0x00fc))
tim_ielen = 5;
else
tim_ielen = 4;
@@ -129,7 +129,7 @@ static void update_BCNTIM(struct adapter *padapter)
*dst_ie++ = 0;/* DTIM count */
*dst_ie++ = 1;/* DTIM period */
- if (pstapriv->tim_bitmap&BIT(0))/* for bc/mc frames */
+ if (pstapriv->tim_bitmap & BIT(0))/* for bc/mc frames */
*dst_ie++ = BIT(0);/* bitmap ctrl */
else
*dst_ie++ = 0;
@@ -583,7 +583,7 @@ static void update_bmc_sta(struct adapter *padapter)
{
u8 arg = 0;
- arg = psta->mac_id&0x1f;
+ arg = psta->mac_id & 0x1f;
arg |= BIT(7);
tx_ra_bitmap |= ((raid << 28) & 0xf000);
DBG_88E("update_bmc_sta, mask = 0x%x, arg = 0x%x\n",
tx_ra_bitmap, arg);
@@ -1043,7 +1043,7 @@ int rtw_check_beacon_data(struct adapter *padapter, u8
*pbuf, int len)
(psecuritypriv->wpa2_pairwise_cipher & WPA_CIPHER_CCMP))
pht_cap->ampdu_params_info |=
(IEEE80211_HT_CAP_AMPDU_DENSITY & (0x07 << 2));
else
- pht_cap->ampdu_params_info |=
(IEEE80211_HT_CAP_AMPDU_DENSITY&0x00);
+ pht_cap->ampdu_params_info |=
(IEEE80211_HT_CAP_AMPDU_DENSITY & 0x00);
/* set Max Rx AMPDU size to 64K */
pht_cap->ampdu_params_info |= (IEEE80211_HT_CAP_AMPDU_FACTOR &
0x03);
@@ -1719,7 +1719,7 @@ int rtw_sta_flush(struct adapter *padapter)
DBG_88E(FUNC_NDEV_FMT"\n", FUNC_NDEV_ARG(padapter->pnetdev));
- if ((pmlmeinfo->state&0x03) != WIFI_FW_AP_STATE)
+ if ((pmlmeinfo->state & 0x03) != WIFI_FW_AP_STATE)
return 0;
spin_lock_bh(&pstapriv->asoc_list_lock);
@@ -1754,7 +1754,7 @@ void sta_info_update(struct adapter *padapter, struct
sta_info *psta)
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
/* update wmm cap. */
- if (WLAN_STA_WME&flags)
+ if (WLAN_STA_WME & flags)
psta->qos_option = 1;
else
psta->qos_option = 0;
@@ -1763,7 +1763,7 @@ void sta_info_update(struct adapter *padapter, struct
sta_info *psta)
psta->qos_option = 0;
/* update 802.11n ht cap. */
- if (WLAN_STA_HT&flags) {
+ if (WLAN_STA_HT & flags) {
psta->htpriv.ht_option = true;
psta->qos_option = 1;
} else {
--
1.9.1
[PATCH 3/5] arm: dts: mt2701: Add display bls related nodes for MT2701
From: Weiqing Kong
This patch adds board related config for backlight
Signed-off-by: Weiqing Kong
Signed-off-by: Erin Lo
---
arch/arm/boot/dts/mt2701-evb.dts | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index f484973..b96e34d 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -23,6 +23,19 @@
reg = <0 0x8000 0 0x4000>;
};
+ backlight_lcd: backlight_lcd {
+ compatible = "pwm-backlight";
+ pwms = <&bls 0 10>;
+ brightness-levels = <
+ 0 16 32 48 64 80 96 112
+ 128 144 160 176 192 208 224 240
+ 255
+ >;
+ default-brightness-level = <9>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_bls_gpio>;
+ };
+
sound:sound {
compatible = "mediatek,mt2701-cs42448-machine";
mediatek,platform = <&afe>;
@@ -62,6 +75,10 @@
status = "okay";
};
+&bls {
+ status = "okay";
+};
+
&i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins_a>;
@@ -86,6 +103,10 @@
};
};
+&mmsys {
+ status = "okay";
+};
+
&pio {
i2c0_pins_a: i2c0@0 {
pins1 {
@@ -111,6 +132,12 @@
};
};
+ pwm_bls_gpio: pwm_bls_gpio {
+ pins_cmd_dat {
+ pinmux = ;
+ };
+ };
+
spi_pins_a: spi0@0 {
pins_spi {
pinmux = ,
--
1.9.1
[PATCH 4/5] arm: dts: mt2701: Add display subsystem related nodes for MT2701
From: YT Shen
This patch adds the device nodes for the DISP function blocks for MT2701
Signed-off-by: YT Shen
Signed-off-by: Erin Lo
---
arch/arm/boot/dts/mt2701.dtsi | 77 +++
1 file changed, 77 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 2bcf739..efb5118 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -25,6 +25,11 @@
compatible = "mediatek,mt2701";
interrupt-parent = <&cirq>;
+ aliases {
+ rdma0 = &rdma0;
+ rdma1 = &rdma1;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -202,6 +207,16 @@
power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
};
+ mipi_tx0: mipi-dphy@1001 {
+ compatible = "mediatek,mt2701-mipi-tx";
+ reg = <0 0x1001 0 0x90>;
+ clocks = <&clk26m>;
+ clock-output-names = "mipi_tx0_pll";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
sysirq: interrupt-controller@10200100 {
compatible = "mediatek,mt2701-sysirq",
"mediatek,mt6577-sysirq";
@@ -529,6 +544,33 @@
#clock-cells = <1>;
};
+ ovl@14007000 {
+ compatible = "mediatek,mt2701-disp-ovl";
+ reg = <0 0x14007000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_OVL>;
+ iommus = <&iommu MT2701_M4U_PORT_DISP_OVL_0>;
+ mediatek,larb = <&larb0>;
+ };
+
+ rdma0: rdma@14008000 {
+ compatible = "mediatek,mt2701-disp-rdma";
+ reg = <0 0x14008000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_RDMA>;
+ iommus = <&iommu MT2701_M4U_PORT_DISP_RDMA>;
+ mediatek,larb = <&larb0>;
+ };
+
+ wdma@14009000 {
+ compatible = "mediatek,mt2701-disp-wdma";
+ reg = <0 0x14009000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_WDMA>;
+ iommus = <&iommu MT2701_M4U_PORT_DISP_WDMA>;
+ mediatek,larb = <&larb0>;
+ };
+
bls: bls@1400a000 {
compatible = "mediatek,mt2701-disp-pwm";
reg = <0 0x1400a000 0 0x1000>;
@@ -538,6 +580,32 @@
status = "disabled";
};
+ color@1400b000 {
+ compatible = "mediatek,mt2701-disp-color";
+ reg = <0 0x1400b000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_COLOR>;
+ };
+
+ dsi: dsi@1400c000 {
+ compatible = "mediatek,mt2701-dsi";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DSI_ENGINE>, <&mmsys CLK_MM_DSI_DIG>,
+<&mipi_tx0>;
+ clock-names = "engine", "digital", "hs";
+ phys = <&mipi_tx0>;
+ phy-names = "dphy";
+ status = "disabled";
+ };
+
+ mutex: mutex@1400e000 {
+ compatible = "mediatek,mt2701-disp-mutex";
+ reg = <0 0x1400e000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_MUTEX_32K>;
+ };
+
larb0: larb@1401 {
compatible = "mediatek,mt2701-smi-larb";
reg = <0 0x1401 0 0x1000>;
@@ -548,6 +616,15 @@
power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
};
+ rdma1: rdma@14012000 {
+ compatible = "mediatek,mt2701-disp-rdma";
+ reg = <0 0x14012000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_RDMA1>;
+ iommus = <&iommu MT2701_M4U_PORT_DISP_RDMA1>;
+ mediatek,larb = <&larb0>;
+ };
+
imgsys: syscon@1500 {
compatible = "mediatek,mt2701-imgsys", "syscon";
reg = <0 0x1500 0 0x1000>;
--
1.9.1
[PATCH] pciehp: Fix infinite interupt handler loop
We've encountered a particular platform that under some circumstances
always has the power fault detected status raised. The pciehp irq handler
would loop forever because it thinks it is handling new events when in
fact the power fault is not new. This patch fixes that by masking off
the power fault status from new events if the driver hasn't seen the
power fault clear from the previous handling attempt.
Fixes: fad214b0aa72 ("PCI: pciehp: Process all hotplug events before looking
for new ones")
Cc: # 4.9+
Cc: Mayurkumar Patel
Signed-off-by: Keith Busch
---
Resending due to send-email setup error; this patch may appear twice
for some.
drivers/pci/hotplug/pciehp_hpc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 026830a..8ecbc13 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -583,7 +583,9 @@ static irqreturn_t pciehp_isr(int irq, void *dev_id)
* Slot Status contains plain status bits as well as event
* notification bits; right now we only want the event bits.
*/
- events = status & (PCI_EXP_SLTSTA_ABP | PCI_EXP_SLTSTA_PFD |
+ events = status & (PCI_EXP_SLTSTA_ABP |
+ (ctrl->power_fault_detected ?
+ 0 : PCI_EXP_SLTSTA_PFD) |
PCI_EXP_SLTSTA_PDC | PCI_EXP_SLTSTA_CC |
PCI_EXP_SLTSTA_DLLSC);
if (!events)
--
2.5.5
[PATCH] timers: Fix overflow in get_next_timer_interrupt
For e.g. HZ=100, timer being 430 jiffies in the future, and 32 bit
unsigned int, there is an overflow on unsigned int right-hand side
of the expression which results with wrong values being returned.
Problem was observed on tickless core and with following applied:
sched/nohz: add debugfs control over sched_tick_max_deferment
https://lkml.org/lkml/2013/9/16/499
Signed-off-by: Matija Glavinic Pecotic
---
kernel/time/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 71ce3f4..8f5d1bf 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1495,7 +1495,7 @@ u64 get_next_timer_interrupt(unsigned long basej, u64
basem)
base->is_idle = false;
} else {
if (!is_max_delta)
- expires = basem + (nextevt - basej) * TICK_NSEC;
+ expires = basem + (u64)(nextevt - basej) * TICK_NSEC;
/*
* If we expect to sleep more than a tick, mark the base idle:
*/
--
2.1.4
Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings
> Hi Kurt, > > On 07/28/2017 09:41 PM, Kurt Van Dijck wrote: > > >>The transceiver is an analog device that needs to support faster > >>switching frequency (FETs) including minimizing delay to support CAN-FD > >>ie higher bitrate. From the transceiver perspective the bits for > >>"arbitration" and "data" look exactly the same. Since it can't > >>differentiate between the two (at the physical layer) then the actual > >>limit isn't specific to which part/type of the CAN message is being > >>sent. Rather its just a single overall max bitrate limit. > > > >I must disagree here. > >The transceiver is an analog device that performs 2 functions: > >propagate tx bits to CAN wire, and propagate CAN wire state > >(dominant/recesive) to rx bits. > > > >I'll rephrase the above explanation to fit your argument: > >During arbitration, both directions are required, and needs to propagate > >within 1 bit time. The transceiver doesn't know, it just performs to > >best effort. > >During data, the round-trip timing requirement of layer2 is relaxed. > >The transceiver still doesn't know, it still performs to best effort. > >Due to the relaxed round-trip timing requirement, the same transceiver > >can suddenly allow higher bitrates. The transceiver didn't change, the > >requirement did change. > >This is what I meant earlier with "layer2 has been adapted to circumvent > >layer1 limitations" > > > I talked to our CAN transceiver & CAN physical layer specialist who was > involved in the ISO activities too. > > We just need ONE value: max-bitrate > > The CAN transceiver is qualified to provide this bitrate. That's it. > There's nothing special with the arbitration bitrate - we don't even need to > outline any CAN FD capability. > > The other things like 'loop delay compensation' are done in the CAN > controller. The better the transceiver get's the bits 'in shape' the higher > it can be qualified. But from the SoC/Controller/Linux view we only need the > max-bitrate value to double check with the CAN controllers bitrate > configuration request (which was Franklins intention). I bet your physical layer specialist understands the details way better than I do :-) 1 value it is then. Kind regards, Kurt
Re: [PATCH] ASoC: codecs: fix wm8524 build error
On Lu, 2017-07-31 at 18:05 +0200, Arnd Bergmann wrote:
> When CONFIG_OF is disabled, we run into a build error:
>
> sound/soc/codecs/wm8524.c:257:21: error: 'wm8524_of_match' undeclared
> here (not in a function); did you mean 'wm8524_dai'?
>
> This removes the unnecessary #ifdef around the match table.
>
> Fixes: 007b6a54c305 ("ASoC: codecs: add wm8524 codec driver")
> Signed-off-by: Arnd Bergmann
Acked-by: Mihai Serban
Re: [PATCH] staging: comedi: comedi_fops: do not call blocking ops when !TASK_RUNNING
On Fri, Jul 28, 2017 at 04:22:31PM +0100, Ian Abbott wrote: > Comedi's read and write file operation handlers (`comedi_read()` and > `comedi_write()`) currently call `copy_to_user()` or `copy_from_user()` > whilst in the `TASK_INTERRUPTIBLE` state, which falls foul of the > `might_fault()` checks when enabled. Fix it by setting the current task > state back to `TASK_RUNNING` a bit earlier before calling these > functions. > > Reported-by: Piotr Gregor > Signed-off-by: Ian Abbott > Cc: # 4.5+ > --- > Note: stable kernel versions 4.4 and earlier will need a slightly more > extensive change in `comedi_write()` than provided by this patch due to > a call to `mutex_lock()` whilst in the `TASK_INTERRUPTIBLE` state. > --- > drivers/staging/comedi/comedi_fops.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/staging/comedi/comedi_fops.c > b/drivers/staging/comedi/comedi_fops.c > index ca11be21f64b..34ca7823255d 100644 > --- a/drivers/staging/comedi/comedi_fops.c > +++ b/drivers/staging/comedi/comedi_fops.c > @@ -2396,6 +2396,7 @@ static ssize_t comedi_write(struct file *file, const > char __user *buf, > continue; > } > > + set_current_state(TASK_RUNNING); > wp = async->buf_write_ptr; > n1 = min(n, async->prealloc_bufsz - wp); > n2 = n - n1; > @@ -2528,6 +2529,8 @@ static ssize_t comedi_read(struct file *file, char > __user *buf, size_t nbytes, > } > continue; > } > + > + set_current_state(TASK_RUNNING); > rp = async->buf_read_ptr; > n1 = min(n, async->prealloc_bufsz - rp); > n2 = n - n1; > -- > 2.13.2 > Hi Ian, I will be able to test this in a couple of days. cheers, Piotr
Re: [PATCH v2 22/22] fpga: intel: afu: add FPGA_PORT_DMA_MAP/UNMAP ioctls support
On Mon, Jul 31, 2017 at 04:41:26PM -0500, Alan Tull wrote:
> On Sun, Jun 25, 2017 at 8:52 PM, Wu Hao wrote:
Hi Alan
Thanks a lot for the code review. :)
>
> Hi Hao,
>
> Please run checkpatch.pl --strict on this.
Sure, thanks for the suggestion, will run this on all the patches and
fix the items reported.
>
> Could you add some kernel-doc function comments here to help the new
> user (or reviewer) get a better handle on what this code is doing?
Do make sense to me, sure, will add kernel-doc style function comments.
>
> A few mostly minor comments below.
>
> > DMA memory regions are required for Accelerated Function Unit (AFU) usage.
> > These two ioctls allow user space applications to map user memory regions
> > for dma, and unmap them after use. Iova is returned from driver to user
> > space application via FPGA_PORT_DMA_MAP ioctl. Application needs to unmap
> > it after use, otherwise, driver will unmap them in device file release
> > operation.
> >
> > All the mapped regions are managed via a rb tree.
>
> Please note that each afu has its own rb tree (this comment sounds
> like there's one rb tree for all) to keep track of its DMA regions.
Yes, each afu has its own rb tree to manage the DMA regions, as each afu
could be assigned to a separated virtual machine.
I will improve the description above to avoid confusing things.
>
> >
> > Ioctl interfaces:
> > * FPGA_PORT_DMA_MAP
> > Do the dma mapping per user_addr and length which provided by user.
> > Return iova in provided struct afu_port_dma_map.
> >
> > * FPGA_PORT_DMA_UNMAP
> > Unmap the dma region per iova provided by user.
> >
> > Signed-off-by: Tim Whisonant
> > Signed-off-by: Enno Luebbers
> > Signed-off-by: Shiva Rao
> > Signed-off-by: Christopher Rauer
> > Signed-off-by: Xiao Guangrong
> > Signed-off-by: Wu Hao
> > ---
> > v2: moved the code to drivers/fpga folder as suggested by Alan Tull.
> > switched to GPLv2 license.
> > fixed kbuild warnings.
> > ---
> > drivers/fpga/Makefile | 3 +-
> > drivers/fpga/intel-afu-dma-region.c | 372
> >
> > drivers/fpga/intel-afu-main.c | 61 +-
> > drivers/fpga/intel-afu.h| 18 ++
> > include/uapi/linux/intel-fpga.h | 37
> > 5 files changed, 489 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/fpga/intel-afu-dma-region.c
> >
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index 45c0538..339d1f3 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -38,4 +38,5 @@ obj-$(CONFIG_INTEL_FPGA_AFU) += intel-fpga-afu.o
> >
> > intel-fpga-pci-objs := intel-pcie.o intel-feature-dev.o
> > intel-fpga-fme-objs := intel-fme-main.o intel-fme-pr.o
> > -intel-fpga-afu-objs := intel-afu-main.o intel-afu-region.o
> > +intel-fpga-afu-objs := intel-afu-main.o intel-afu-region.o \
> > + intel-afu-dma-region.o
> > diff --git a/drivers/fpga/intel-afu-dma-region.c
> > b/drivers/fpga/intel-afu-dma-region.c
> > new file mode 100644
> > index 000..982a9b5
> > --- /dev/null
> > +++ b/drivers/fpga/intel-afu-dma-region.c
> > @@ -0,0 +1,372 @@
> > +/*
> > + * Driver for Intel FPGA Accelerated Function Unit (AFU) DMA Region
> > Management
> > + *
> > + * Copyright (C) 2017 Intel Corporation, Inc.
> > + *
> > + * Authors:
> > + * Wu Hao
> > + * Xiao Guangrong
> > + *
> > + * This work is licensed under the terms of the GNU GPL version 2. See
> > + * the COPYING file in the top-level directory.
> > + */
> > +
> > +#include
> > +#include
> > +
> > +#include "intel-afu.h"
> > +
> > +static void put_all_pages(struct page **pages, int npages)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < npages; i++)
> > + if (pages[i] != NULL)
> > + put_page(pages[i]);
> > +}
> > +
> > +void afu_dma_region_init(struct feature_platform_data *pdata)
> > +{
> > + struct fpga_afu *afu = fpga_pdata_get_private(pdata);
> > +
> > + afu->dma_regions = RB_ROOT;
> > +}
> > +
> > +static long afu_dma_adjust_locked_vm(struct device *dev, long npages, bool
> > incr)
> > +{
> > + unsigned long locked, lock_limit;
> > + int ret = 0;
> > +
> > + /* the task is exiting. */
> > + if (!current->mm)
> > + return 0;
> > +
> > + down_write(¤t->mm->mmap_sem);
> > +
> > + if (incr) {
> > + locked = current->mm->locked_vm + npages;
> > + lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> > +
> > + if (locked > lock_limit && !capable(CAP_IPC_LOCK))
> > + ret = -ENOMEM;
> > + else
> > + current->mm->locked_vm += npages;
> > + } else {
> > +
>
> Don't need to skip a line here.
Sorry, will fix this in next version.
>
> > + if (WARN_ON_ONCE(npages > current->mm->locked_vm))
> > + npages = current->mm->locked_vm;
Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
David Miller writes:
> From: Anatoly Pugachev
> Date: Tue, 1 Aug 2017 01:01:47 +0300
>
> > I don't know how to run on a running kernel , but as I understood:
> >
> > root@v215:strace# gzip -dc /boot/vmlinuz-4.12.0 > vmlinux
> > root@v215:strace# gdb -q vmlinux
> > Reading symbols from vmlinux...(no debugging symbols found)...done.
> > (gdb) x/20i 0x49b294 - 16
>
> Unfortunately you need to do this on the build kernel image before it
> has been stripped of all of it's symbols.
>
> Mikael, you built your kernels right?
>
> Go into one of your OOPS's and extract the "RPC: " hex value, and run
> the gdb command:
>
> bash$ cd src/linux
> bash$ gdb ./vmlinux
> (gdb) x/10i 0x${RPC_HEX_VALUE} - 16
>
> Thanks.
Ok, with 4.13-rc3 I got
[ 240.085153] Unable to handle kernel NULL pointer dereference
[ 240.142397] tsk->{mm,active_mm}->context = 044a
[ 240.198531] tsk->{mm,active_mm}->pgd = fff23c784000
[ 240.250112] \|/ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
[ 240.374879] poll(724): Oops [#1]
[ 240.400132] CPU: 0 PID: 724 Comm: poll Not tainted 4.13.0-rc3 #1
[ 240.462002] task: fff000123cc71e00 task.stack: fff000123c894000
[ 240.522717] TSTATE: 004411001605 TPC: 007570fc TNPC:
00757110 Y: Not tainted
[ 240.634921] TPC: <__bzero+0x20/0xc0>
[ 240.664747] g0: fff000123c897081 g1: g2:
g3: 008ca100
[ 240.762068] g4: fff000123cc71e00 g5: fff23ef44000 g6: fff000123c894000
g7: 0008
[ 240.859389] o0: 000c o1: fff000123c897a80 o2:
o3: 000c
[ 240.956718] o4: fff000123c897a7c o5: 00fb sp: fff000123c897181
ret_pc: 00516ee0
[ 241.058627] RPC:
[ 241.094166] l0: 0002 l1: 014000c0 l2: 03fe
l3: fff000123c897a7c
[ 241.191506] l4: l5: l6: 006d
l7: ffea
[ 241.288822] i0: f7d93ff8 i1: 0002 i2: fff000123c897e90
i3: fff000123c897a70
[ 241.386141] i4: 000fffedc3768590 i5: fff000123c897a70 i6: fff000123c8975e1
i7: 005177f8
[ 241.483468] I7:
[ 241.513292] Call Trace:
[ 241.528265] [005177f8] SyS_poll+0x74/0xd0
[ 241.574140] [004061b4] linux_sparc_syscall32+0x34/0x60
[ 241.634847] Disabling lock debugging due to kernel taint
[ 241.687555] Caller[005177f8]: SyS_poll+0x74/0xd0
[ 241.740276] Caller[004061b4]: linux_sparc_syscall32+0x34/0x60
[ 241.807855] Caller[00010a20]: 0x10a20
[ 241.847983] Instruction DUMP:
[ 241.847987] c56a2000
[ 241.869824] 808a2003
[ 241.883651] 02480006
[ 241.897475]
[ 241.911207] 90022001
[ 241.925032] 808a2003
[ 241.938755] 1247fffd
[ 241.952484] 92226001
[ 241.966310] 808a2007
so the RPC should be do_sys_poll+0x80 right? Then gdb on the original vmlinux
said:
(gdb) x/10i do_sys_poll+0x80-16
0x516ed0 : brz %o0, 0x5170fc
0x516ed4 : mov %o0, %o2
0x516ed8 : sub %i4, %o0, %i4
0x516edc : clr %o1
0x516ee0 : call 0x7570b8
0x516ee4 : add %l3, %i4, %o0
0x516ee8 : b %xcc, 0x5170b0
0x516eec : mov -14, %l7
0x516ef0 : mov %l2, %o0
0x516ef4 : movleu %xcc, %l0, %o0
(gdb)
/Mikael
Re: [PATCH] mm/zsmalloc: Change stat type parameter to int
On (07/31/17 10:50), Matthias Kaehlcke wrote: > zs_stat_inc/dec/get() uses enum zs_stat_type for the stat type, however > some callers pass an enum fullness_group value. Change the type to int > to reflect the actual use of the functions and get rid of > 'enum-conversion' warnings > > Signed-off-by: Matthias Kaehlcke Reviewed-by: Sergey Senozhatsky -ss
Re: [PATCH] x86/hpet: Cure interface abuse in the resume path
On 31/07/17 23:07, Thomas Gleixner wrote:
The HPET resume path abuses irq_domain_[de]activate_irq() to restore the
MSI message in the HPET chip for the boot CPU on resume and it relies on an
implementation detail of the interrupt core code, which magically makes the
HPET unmask call invoked via a irq_disable/enable pair. This worked as long
as the irq code did unconditionally invoke the unmask() callback. With the
recent changes which keep track of the masked state to avoid expensive
hardware access, this does not longer work. As a consequence the HPET timer
interrupts are not unmasked which breaks resume as the boot CPU waits
forever that a timer interrupt arrives.
Make the restore of the MSI message explicit and invoke the unmask()
function directly. While at it get rid of the pointless affinity setting as
nothing can change the affinity of the interrupt and the vector across
suspend/resume. The restore of the MSI message reestablishes the previous
affinity setting which is the correct one.
Fixes: bf22ff45bed6 ("genirq: Avoid unnecessary low level irq function calls")
Reported-by: Martin Peres
Reported-by: Tomi Sarvela
Signed-off-by: Thomas Gleixner
Cc: jeffy.c...@rock-chips.com
Cc: Marc Zyngier
Cc: Peter Ziljstra
Cc: "Rafael J. Wysocki"
Tested-by: Tomi Sarvela
Tested only on the regressed Eagle Lake testhost. This patch fixes the
suspend/resume issue.
Tomi
--
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
[PATCH v1 2/2] dt-bindings: ata: add DT bindings for MediaTek SATA controller
Add DT bindings for the onboard SATA controller present on the MediaTek
SoCs.
Signed-off-by: Ryder Lee
---
Documentation/devicetree/bindings/ata/ahci-mtk.txt | 50 ++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt
diff --git a/Documentation/devicetree/bindings/ata/ahci-mtk.txt
b/Documentation/devicetree/bindings/ata/ahci-mtk.txt
new file mode 100644
index 000..8f64f15
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-mtk.txt
@@ -0,0 +1,50 @@
+MediaTek Seria ATA controller
+
+Required properties:
+ - compatible : Must be "mediatek,ahci".
+ - reg: Physical base addresses and length of register sets.
+ - interrupts : Interrupt associated with the SATA device.
+ - interrupt-names : Associated name must be: "hostc".
+ - clocks : A list of phandle and clock specifier pairs, one for each
+entry in clock-names.
+ - clock-names: Associated names must be: "ahb", "axi", "asic", "rbc",
"pm".
+ - phys : A phandle and PHY specifier pair for the PHY port.
+ - phy-names : Associated name must be: "sata-phy".
+ - ports-implemented : Mask that indicates which ports that the HBA supports
+ are available for software to use. Useful if PORTS_IMPL
+ is not programmed by the BIOS, which is true with some
+ embedded SOC's.
+
+Optional properties:
+ - power-domains : A phandle and power domain specifier pair to the power
+domain which is responsible for collapsing and restoring
+power to the peripheral.
+ - resets : Must contain an entry for each entry in reset-names.
+See ../reset/reset.txt for details.
+ - reset-names: Associated names must be: "axi-rst", "sw-rst", "reg-rst".
+ - mediatek,phy-mode : A phandle to the system controller, used to enable
+ SATA function.
+
+Example:
+
+ sata: sata@1a20 {
+ compatible = "mediatek,ahci";
+ reg = <0 0x1a20 0 0x1100>;
+ interrupts = ;
+ interrupt-names = "hostc";
+ clocks = <&pciesys CLK_SATA_AHB_EN>,
+<&pciesys CLK_SATA_AXI_EN>,
+<&pciesys CLK_SATA_ASIC_EN>,
+<&pciesys CLK_SATA_RBC_EN>,
+<&pciesys CLK_SATA_PM_EN>;
+ clock-names = "ahb", "axi", "asic", "rbc", "pm";
+ phys = <&u3port1 PHY_TYPE_SATA>;
+ phy-names = "sata-phy";
+ ports-implemented = <0x1>;
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
+ resets = <&pciesys MT7622_SATA_AXI_BUS_RST>,
+<&pciesys MT7622_SATA_PHY_SW_RST>,
+<&pciesys MT7622_SATA_PHY_REG_RST>;
+ reset-names = "axi-rst", "sw-rst", "reg-rst";
+ mediatek,phy-mode = <&pciesys>;
+ };
--
1.9.1
[PATCH v1 0/2] Add support for MediaTek AHCI SATA
Hi, This patch series add support for AHCI compatible SATA controller, and it is compliant with the ahci 1.3 and sata 3.0 specification. This driver is slightly different than ahci_platform.c (e.g., reset control, subsystem setting). changes since v1: - update binding text: add missing "specifier pairs" descriptions. - fix kbuild test warning: fix the error handling. Ryder Lee (2): ata: mediatek: add support for MediaTek SATA controller dt-bindings: ata: add DT bindings for MediaTek SATA controller Documentation/devicetree/bindings/ata/ahci-mtk.txt | 50 ++ drivers/ata/Kconfig| 10 ++ drivers/ata/Makefile | 1 + drivers/ata/ahci_mtk.c | 196 + 4 files changed, 257 insertions(+) create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt create mode 100644 drivers/ata/ahci_mtk.c -- 1.9.1
[PATCH v1 1/2] ata: mediatek: add support for MediaTek SATA controller
This adds support the AHCI-compliant Serial ATA controller present
on MediaTek SoCs.
Signed-off-by: Ryder Lee
---
drivers/ata/Kconfig| 10 +++
drivers/ata/Makefile | 1 +
drivers/ata/ahci_mtk.c | 196 +
3 files changed, 207 insertions(+)
create mode 100644 drivers/ata/ahci_mtk.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 948fc86..7d3eb47 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -153,6 +153,16 @@ config AHCI_CEVA
If unsure, say N.
+config AHCI_MTK
+ tristate "MediaTek AHCI SATA support"
+ depends on ARCH_MEDIATEK
+ select MFD_SYSCON
+ help
+ This option enables support for the MediaTek SoC's
+ onboard AHCI SATA controller.
+
+ If unsure, say N.
+
config AHCI_MVEBU
tristate "Marvell EBU AHCI SATA support"
depends on ARCH_MVEBU
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index a26ef5a..ff9cd2e 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AHCI_CEVA) += ahci_ceva.o
libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_DA850) += ahci_da850.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_DM816) += ahci_dm816.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_IMX) += ahci_imx.o libahci.o libahci_platform.o
+obj-$(CONFIG_AHCI_MTK) += ahci_mtk.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_MVEBU) += ahci_mvebu.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_OCTEON) += ahci_octeon.o
obj-$(CONFIG_AHCI_SUNXI) += ahci_sunxi.o libahci.o libahci_platform.o
diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
new file mode 100644
index 000..6361316
--- /dev/null
+++ b/drivers/ata/ahci_mtk.c
@@ -0,0 +1,196 @@
+/*
+ * MeidaTek AHCI SATA driver
+ *
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Ryder Lee
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ahci.h"
+
+#define DRV_NAME "ahci"
+
+#define SYS_CFG0x14
+#define SYS_CFG_SATA_MSK GENMASK(31, 30)
+#define SYS_CFG_SATA_ENBIT(31)
+
+struct mtk_ahci_drv_data {
+ struct regmap *mode;
+ struct reset_control *axi_rst;
+ struct reset_control *sw_rst;
+ struct reset_control *reg_rst;
+};
+
+static const struct ata_port_info ahci_port_info = {
+ .flags = AHCI_FLAG_COMMON,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &ahci_platform_ops,
+};
+
+static struct scsi_host_template ahci_platform_sht = {
+ AHCI_SHT(DRV_NAME),
+};
+
+static int mtk_ahci_platform_resets(struct ahci_host_priv *hpriv,
+ struct device *dev)
+{
+ struct mtk_ahci_drv_data *drv_data = hpriv->plat_data;
+ int err;
+
+ /* reset AXI bus and phy part */
+ drv_data->axi_rst = devm_reset_control_get_optional(dev, "axi-rst");
+ if (PTR_ERR(drv_data->axi_rst) == -EPROBE_DEFER)
+ return PTR_ERR(drv_data->axi_rst);
+
+ drv_data->sw_rst = devm_reset_control_get_optional(dev, "sw-rst");
+ if (PTR_ERR(drv_data->sw_rst) == -EPROBE_DEFER)
+ return PTR_ERR(drv_data->sw_rst);
+
+ drv_data->reg_rst = devm_reset_control_get_optional(dev, "reg-rst");
+ if (PTR_ERR(drv_data->reg_rst) == -EPROBE_DEFER)
+ return PTR_ERR(drv_data->reg_rst);
+
+ err = reset_control_assert(drv_data->axi_rst);
+ if (err) {
+ dev_err(dev, "assert axi bus failed\n");
+ return err;
+ }
+
+ err = reset_control_assert(drv_data->sw_rst);
+ if (err) {
+ dev_err(dev, "assert phy digital part failed\n");
+ return err;
+ }
+
+ err = reset_control_assert(drv_data->reg_rst);
+ if (err) {
+ dev_err(dev, "assert phy register part failed\n");
+ return err;
+ }
+
+ err = reset_control_deassert(drv_data->reg_rst);
+ if (err) {
+ dev_err(dev, "deassert phy register part failed\n");
+ return err;
+ }
+
+ err = reset_control_deassert(drv_data->sw_rst);
+ if (err) {
+ dev_err(dev, "deassert phy digital part failed\n");
+ return err;
+ }
+
+ err = reset_control_deassert(drv_data->axi_rst);
+ if (err) {
+ dev_err(dev, "deassert
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync
On 2017年07月31日 19:20, qiaozhou wrote: On 2017年07月29日 03:09, Vikram Mulukutla wrote: On 2017-07-28 02:28, Will Deacon wrote: On Thu, Jul 27, 2017 at 06:10:34PM -0700, Vikram Mulukutla wrote: Does bodging cpu_relax to back-off to wfe after a while help? The event stream will wake it up if nothing else does. Nasty patch below, but I'd be interested to know whether or not it helps. Will The patch also helps a lot on my platform. (Though it does cause deadlock(related with udelay) in uart driver in early boot, and not sure it's uart driver issue. Just workaround it firstly) Platform: 4 a53(832MHz) + 4 a73(1.8GHz) Test condition #1: a. core2: a53, while loop (spinlock, spin_unlock) b. core7: a73, while loop (spinlock, spin_unlock, cpu_relax) Test result: recording the lock acquire times(a53, a73), max lock acquired time(a53), in 20 seconds Without cpu_relax bodging patch: === |a53 locked times | a73 locked times | a53 max locked time(us)| ==|==|| 182| 38371616| 1,951,954| 202| 38427652| 2,261,319| 210| 38477427| 15,309,597| 207| 38494479| 6,656,453| 220| 38422283| 2,064,155| === With cpu_relax bodging patch: === |a53 locked times | a73 locked times | a53 max locked time(us)| ==|==|| 1849898| 37799379| 131,255| 1574172| 38557653| 38,410| 1924777| 37831725| 42,999| 1477665| 38723741| 52,087| 1865793| 38007741| 783,965| === Also add some workload to the whole system to check the result. Test condition #2: based on #1 c. core6: a73, 1.8GHz, run "while(1);" loop With cpu_relax bodging patch: === |a53 locked times | a73 locked times | a53 max locked time(us)| ==|==|| 20| 42563981| 2,317,070| 10| 42652793| 4,210,944| 9| 42651075| 5,691,834| 28| 42652591| 4,539,555| 10| 42652801| 5,850,639| === Also hotplug out other cores. Test condition #3: based on #1 d. hotplug out core1/3/4/5/6, keep core0 for scheduling With cpu_relax bodging patch: === |a53 locked times | a73 locked times | a53 max locked time(us)| ==|==|| 447| 42652450| 309,549| 515| 42650382| 337,661| 415| 42646669| 628,525| 431| 42651137| 365,862| 464| 42648916| 379,934| === The last two tests are the actual cases where the hard-lockup is triggered on my platform. So I gathered some data, and it shows that a53 needs much longer time to acquire the lock. All tests are done in android, black screen with USB cable attached. The data is not so pretty as Vikram's. It might be related with cpu topology, core numbers, CCI frequency etc. (I'll do another test with both a53 and a73 running at 1.2GHz, to check whether it's the core frequency which leads to the major difference.) Test the contention with the same frequency between a53 and a73 cores. Platform: 4 a53(1248MHz) + 4 a73(1248MHz) Test condition #4: a. core2: a53, while loop (spinlock, spin_unlock) b. core7: a73, while loop (spinlock, spin_unlock) === |a53 locked times | a73 locked times | a53 max locked time(us)| ==|==|| 12945632| 13021576| 14| 12934181| 13059230| 16| 12987186| 13059016| 49| 12958583| 13038884| 24| 14637546| 14672522| 14| === The locked times are almost the same, and the max time of acquiri
Re: [PATCH] printk: Clean up do_syslog() error handling
On (07/29/17 20:36), Nikitas Angelinas wrote: > The error variable in do_syslog() is preemptively set to the error code > before the error condition is checked, and then set to 0 if the error > condition is not encountered. This is not necessary, as it is likely > simpler to return immediately upon encountering the error condition. A > redundant set of the error variable to 0 is also removed. > > This patch has been build-tested on x86_64, but not tested for > functionality. > > Signed-off-by: Nikitas Angelinas looks good to me, Reviewed-by: Sergey Senozhatsky // p.s. Petr is on vacation now -ss
linux-next: Tree for Aug 1
Hi all, Changes since 20170731: The rdma tree lost its build failure. I reverted a commit from the staging tree that was causing overnight build failures. The akpm-current tree gained a build failure for which I applied a patch and another for which I reverted a commit. The akpm tree gained a conflict against the wberr tree. There was a build error after the merging of the akpm trees which I have left broken for today. Non-merge commits (relative to Linus' tree): 3505 3681 files changed, 120460 insertions(+), 57536 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu. Below is a summary of the state of the merge. I am currently merging 267 trees (counting Linus' and 41 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (2e7ca2064cbb Merge branch 'for-4.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup) Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig entry) Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in nconfig) Merging arc-current/for-curr (37f1db0e85ff ARC: [plat-axs10x]: prepare dts files for enabling PAE40 on axs103) Merging arm-current/fixes (ce184a0dee92 ARM: 8687/1: signal: Fix unparseable iwmmxt_sigframe in uc_regspace[]) Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (253fd51e2f53 powerpc/powernv/pci: Return failure for some uses of dma_set_mask()) Merging sparc/master (8cd3ec51c0c3 sbus: Convert to using %pOF instead of full_name) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (9975a54b3c9e bpf: fix bpf_prog_get_info_by_fd to dump correct xlated_prog_len) Merging ipsec/master (e6194923237f esp: Fix memleaks on error paths.) Merging netfilter/master (9beceb54fa2c netfilter: x_tables: Fix use-after-free in ipt_do_table.) Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook mask only if set) Merging wireless-drivers/master (5f5d03143de5 brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twice) Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES) Merging sound-current/for-linus (ba92b1142879 ALSA: hda - Add mute led support for HP ProBook 440 G4) Merging pci-current/for-linus (16f73eb02d7e Linux 4.13-rc3) Merging driver-core.current/driver-core-linus (5771a8c08880 Linux v4.13-rc1) Merging tty.current/tty-linus (37ef38f3f838 tty: pl011: fix initialization order of QDF2400 E44) Merging usb.current/usb-linus (45d73860530a usb: musb: fix tx fifo flush handling again) Merging usb-gadget-fixes/fixes (520eccdfe187 Linux 4.13-rc2) Merging usb-serial-fixes/usb-linus (9585e340db9f USB: serial: cp210x: add support for Qivicon USB ZigBee dongle) Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: check before accessing ci_role in ci_role_show) Merging phy/fixes (5771a8c08880 Linux v4.13-rc1) Merging staging.current/staging-linus (cef988642cda staging: comedi: comedi_fops: do not call blocking ops when !TASK_RUNNING) Merging char-misc.current/char-misc-linus (520eccdfe187 Linux 4.13-rc2) Merging input-current/for-linus (293b915fd9be Input: trackpoint - assume 3 bu
Re: [PATCH] x86/hpet: Cure interface abuse in the resume path
On Tue, 1 Aug 2017, Tomi Sarvela wrote:
> On 31/07/17 23:07, Thomas Gleixner wrote:
> > The HPET resume path abuses irq_domain_[de]activate_irq() to restore the
> > MSI message in the HPET chip for the boot CPU on resume and it relies on an
> > implementation detail of the interrupt core code, which magically makes the
> > HPET unmask call invoked via a irq_disable/enable pair. This worked as long
> > as the irq code did unconditionally invoke the unmask() callback. With the
> > recent changes which keep track of the masked state to avoid expensive
> > hardware access, this does not longer work. As a consequence the HPET timer
> > interrupts are not unmasked which breaks resume as the boot CPU waits
> > forever that a timer interrupt arrives.
> >
> > Make the restore of the MSI message explicit and invoke the unmask()
> > function directly. While at it get rid of the pointless affinity setting as
> > nothing can change the affinity of the interrupt and the vector across
> > suspend/resume. The restore of the MSI message reestablishes the previous
> > affinity setting which is the correct one.
> >
> > Fixes: bf22ff45bed6 ("genirq: Avoid unnecessary low level irq function
> > calls")
> > Reported-by: Martin Peres
> > Reported-by: Tomi Sarvela
> > Signed-off-by: Thomas Gleixner
> > Cc: jeffy.c...@rock-chips.com
> > Cc: Marc Zyngier
> > Cc: Peter Ziljstra
> > Cc: "Rafael J. Wysocki"
>
> Tested-by: Tomi Sarvela
>
> Tested only on the regressed Eagle Lake testhost. This patch fixes the
> suspend/resume issue.
Tomi, can you please do me a favor?
Use plain 4.13-rc3 (without that patch) and add the following on the kernel
command line: 'nohpet'. Boot the machine and capture and provide the output
of
# dmesg
# cat /proc/interrupts
# cat /proc/timer_list
Then try the suspend cycle again.
Thanks,
tglx
Re: [RFC/RFT PATCH 3/3] gpiolib: make gpio irqchip compatible with sparse_irq
On Sun, Jul 9, 2017 at 12:44 AM, Grygorii Strashko wrote: > Now IRQ mappings are always created for all (allowed) GPIOs in gpio irqchip in > gpiochip_irqchip_add_key() which goes against the idea of SPARSE_IRQ and, > as result, leads to: > - increasing of memory consumption because of allocated IRQ descriptors most > of which will never ever be used (especially on platform with a > high number of GPIOs) > - imposibility to use GPIO irqchip APIs by gpio drivers when HW implements > GPIO IRQ functionality as IRQ crossbar/multiplexer which has only limited > number of IRQ outputs (example from [1], all GPIOs can be mapped on only 8 > IRQs). > > Hence, remove static IRQ mapping code from gpiochip_irqchip_add_key() and > instead replace irq_find_mapping() with irq_create_mapping() in > gpiochip_to_irq(). Also add additional gpiochip_irqchip_irq_valid() calls > in gpiochip_to_irq() and gpiochip_irq_map(). > > After this change gpio2irq mapping will happen the following way when GPIO > irqchip APIs are used by gpio driver: > - IRQ mappings will be created statically if driver passes first_irq>0 > vlaue in gpiochip_irqchip_add_key(). > - IRQ mappings will be created dynamically from gpio_to_irq() or > of_irq_get(). > > [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1435847.html > Signed-off-by: Grygorii Strashko This is obviously better and what I should have done from the beginning had I only been smart enough, so what better to do than to throw this in now for -next and see what happens :) Patch applied. Yours, Linus Walleij
Re: [PATCHv2 08/10] x86/mm: Replace compile-time checks for 5-level with runtime-time
On 26/07/17 18:43, Kirill A. Shutemov wrote:
> On Wed, Jul 26, 2017 at 09:28:16AM +0200, Juergen Gross wrote:
>> On 25/07/17 11:05, Kirill A. Shutemov wrote:
>>> On Tue, Jul 18, 2017 at 04:24:06PM +0200, Juergen Gross wrote:
Xen PV guests will never run with 5-level-paging enabled. So I guess you
can drop the complete if (IS_ENABLED(CONFIG_X86_5LEVEL)) {} block.
>>>
>>> There is more code to drop from mmu_pv.c.
>>>
>>> But while there, I thought if with boot-time 5-level paging switching we
>>> can allow kernel to compile with XEN_PV and XEN_PVH, so the kernel image
>>> can be used in these XEN modes with 4-level paging.
>>>
>>> Could you check if with the patch below we can boot in XEN_PV and XEN_PVH
>>> modes?
>>
>> We can't. I have used your branch:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git
>> la57/boot-switching/v2
>>
>> with this patch applied on top.
>>
>> Doesn't boot PV guest with X86_5LEVEL configured (very early crash).
>
> Hm. Okay.
>
> Have you tried PVH?
>
>> Doesn't build with X86_5LEVEL not configured:
>>
>> AS arch/x86/kernel/head_64.o
>
> I've fixed the patch and split the patch into two parts: cleanup and
> re-enabling XEN_PV and XEN_PVH for X86_5LEVEL.
>
> There's chance that I screw somthing up in clenaup part. Could you check
> that?
Build is working with and without X86_5LEVEL configured.
PV domU boots without X86_5LEVEL configured.
PV domU crashes with X86_5LEVEL configured:
xen_start_kernel()
x86_64_start_reservations()
start_kernel()
setup_arch()
early_ioremap_init()
early_ioremap_pmd()
In early_ioremap_pmd() there seems to be a call to p4d_val() which is an
uninitialized paravirt operation in the Xen pv case.
HTH, Juergen
Re: [RFC/RFT PATCH 2/3] gpio: pxa: remove gpio_to_irq() from hw irq handlers
On Sun, Jul 9, 2017 at 12:44 AM, Grygorii Strashko wrote: > gpio_to_irq() API expected to be used by GPIO consumers and > not drivers and there are no guarantee that its gpiolib implementation > is irq safe. > > Signed-off-by: Grygorii Strashko Patch applied. This is the right thing to do. PXA developers: please test. Yours, Linus Walleij
Re: [RFC/RFT PATCH 1/3] gpio: tegra: remove gpio_to_irq() from hw irq handlers
On Sun, Jul 9, 2017 at 12:44 AM, Grygorii Strashko wrote: > gpio_to_irq() API expected to be used by GPIO consumers and > not drivers and there are no guarantee that its gpiolib implementation > is irq safe. > > Signed-off-by: Grygorii Strashko Patch applied. This is obviously the right way to do it. Tegra people: please test. Yours, Linus Walleij
Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
On Fri, Jul 21, 2017 at 6:49 PM, Grygorii Strashko wrote: > Now IRQ mappings are always created for all (allowed) GPIOs in gpiochip in > gpiochip_irqchip_add_key() which goes against the idea of SPARSE_IRQ and, > as result, leads to: > - increasing of memory consumption for IRQ descriptors most of which will > never ever be used (espessially on platform with a high number of GPIOs). > (sizeof(struct irq_desc) == 256 on my tested platforms) > - imposibility to use GPIO irqchip APIs by gpio drivers when HW implements > GPIO IRQ functionality as IRQ crossbar/router which has only limited > number of IRQ outputs (example from [1], all GPIOs can be mapped on only 8 > IRQs). > > Hence, remove static IRQ mapping code from gpiochip_irqchip_add_key() and > instead replace irq_find_mapping() with irq_create_mapping() in > gpiochip_to_irq(). Also add additional gpiochip_irqchip_irq_valid() calls > in gpiochip_to_irq() and gpiochip_irq_map(). > > After this change gpio2irq mapping will happen the following way when GPIO > irqchip APIs are used by gpio driver: > - IRQ mappings will be created statically if driver passes first_irq>0 > vlaue in gpiochip_irqchip_add_key(). > - IRQ mappings will be created dynamically from gpio_to_irq() or > of_irq_get(). > > Tested on am335x-evm and dra72-evm-revc. > - dra72-evm-revc: number of created irq mappings decreased from 402 -> 135 > Mem savings 267*256 = 68352 (66kB) > - am335x-evm: number of created irq mappings decreased from 188 -> 63 > Mem savings 125*256 = 32000 (31kB) > > [1] https://lkml.org/lkml/2017/6/15/428 > Signed-off-by: Grygorii Strashko > --- > Changes in v2: > - restored struct gpio_chip->irq_base to fix buld of gpio-mockup.c Applied this rather than v1. But maybe we should get rid of ->irq_base from gpio-mockup.c and delete it, as the base is irqchip-internal. Bartosz what do you say? Do we need this in the mockup? Yours, Linus Walleij
[PATCH v3] staging: octeon: fix line over 80 characters
From: John Smith
ethernet-rx.c:
fix WARNING: line over 80 characters
The code was restructured a bit, a helper function
was added to cvm_oct_poll.
Signed-off-by: John Smith
---
Changes since version 2:
- silenced build warning
drivers/staging/octeon/ethernet-rx.c | 79 +++-
1 file changed, 41 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/octeon/ethernet-rx.c
b/drivers/staging/octeon/ethernet-rx.c
index 72baede..1a44291 100644
--- a/drivers/staging/octeon/ethernet-rx.c
+++ b/drivers/staging/octeon/ethernet-rx.c
@@ -149,6 +149,46 @@ static inline int cvm_oct_check_rcv_error(cvmx_wqe_t *work)
return 0;
}
+static void copy_segments_to_skb(cvmx_wqe_t *work, struct sk_buff *skb)
+{
+ int segments = work->word2.s.bufs;
+ union cvmx_buf_ptr segment_ptr = work->packet_ptr;
+ int len = work->word1.len;
+ int segment_size;
+
+ while (segments--) {
+ union cvmx_buf_ptr next_ptr;
+
+ next_ptr = *(union cvmx_buf_ptr *)
+ cvmx_phys_to_ptr(segment_ptr.s.addr - 8);
+
+ /*
+* Octeon Errata PKI-100: The segment size is wrong.
+*
+* Until it is fixed, calculate the segment size based on
+* the packet pool buffer size.
+* When it is fixed, the following line should be replaced
+* with this one:
+* int segment_size = segment_ptr.s.size;
+*/
+ segment_size =
+ CVMX_FPA_PACKET_POOL_SIZE -
+ (segment_ptr.s.addr -
+(((segment_ptr.s.addr >> 7) -
+ segment_ptr.s.back) << 7));
+
+ /* Don't copy more than what is left in the packet */
+ if (segment_size > len)
+ segment_size = len;
+
+ /* Copy the data into the packet */
+ skb_put_data(skb, cvmx_phys_to_ptr(segment_ptr.s.addr),
+segment_size);
+ len -= segment_size;
+ segment_ptr = next_ptr;
+ }
+}
+
static int cvm_oct_poll(struct oct_rx_group *rx_group, int budget)
{
const int coreid = cvmx_get_core_num();
@@ -290,44 +330,7 @@ static int cvm_oct_poll(struct oct_rx_group *rx_group, int
budget)
skb_put_data(skb, ptr, work->word1.len);
/* No packet buffers to free */
} else {
- int segments = work->word2.s.bufs;
- union cvmx_buf_ptr segment_ptr =
- work->packet_ptr;
- int len = work->word1.len;
-
- while (segments--) {
- union cvmx_buf_ptr next_ptr =
- *(union cvmx_buf_ptr *)
- cvmx_phys_to_ptr(
- segment_ptr.s.addr - 8);
-
- /*
-* Octeon Errata PKI-100: The segment size is
-* wrong. Until it is fixed, calculate the
-* segment size based on the packet pool
-* buffer size. When it is fixed, the
-* following line should be replaced with this
-* one: int segment_size =
-* segment_ptr.s.size;
-*/
- int segment_size =
- CVMX_FPA_PACKET_POOL_SIZE -
- (segment_ptr.s.addr -
-(((segment_ptr.s.addr >> 7) -
- segment_ptr.s.back) << 7));
- /*
-* Don't copy more than what
-* is left in the packet.
-*/
- if (segment_size > len)
- segment_size = len;
- /* Copy the data into the packet */
- skb_put_data(skb,
-
cvmx_phys_to_ptr(segment_ptr.s.addr),
-segment_size);
- len -= segment_size;
- segment_ptr = next_ptr;
- }
+ copy_segments_to_skb(work, skb);
}
packet_not_copied = 0;
}
--
2.7.4
Re: Kernel error messages: leds fujitsu::radio_led: Setting an LED's brightness failed
Hi Michał, > A photo would be useful (though please do not attach it to your message, > https://www.notebookcheck.net/fileadmin/_migrated/pics/Fujitsu-LB-E751-Tastatur_1j.jpg That is exactly my laptop (well, except for those ugly windows badges ;)) To be completely sure I have taken two photos and posted them here: http://picpaste.com/IMG_20170720_125716-RazF0yQa.jpg http://picpaste.com/IMG_20170720_125736-zdpEGoHR.jpg Beware, the photos will only stay online for seven days. > Are these the 11 LEDs you mentioned? > > - top, left: E, HDD, Num Lock, Caps Lock, Scroll Lock, > - top, right: I, Power Button, > - front (not pictured in the first photo above): Power Supply, Battery > Charging, Battery 1, Battery 2. Yes, these are the LEDs in question >> 1783:Jul 14 12:33:48 gruenix kernel: leds fujitsu::radio_led: Setting an >> LED's brightness failed (-2147483648) > > 4.11 included a patch which sets the default trigger for the radio LED > to rfkill-any, which would explain why you only started seeing these > errors after upgrading to that version. See also below. > >> Some of the LEDs are not working under linux, especially the bluetooth >> one > > Where is the Bluetooth LED located? I cannot see it. Can you show it > on a photo? How does it behave under other operating systems? Well, IIRC the one in the I(nformation) key was acting as a bluetooth LED. I have another Harddisk with a working Win7 Installation which I will mount and report back later when I have the time. >> and three others E, > > According to a manual I found [1], this is an "Energy saving functions > indicator", which is lit when "energy function are enabled". My guess > would be it can be repurposed under Linux. Correct. Would be nice to reuse it in one way or another under linux >> I(nformation) > > According to the same manual, this LED signals battery level when the > laptop is off (S5 state) and the "I" key is pressed. Not sure it can be > repurposed, but how does it behave under other operating systems? See above. Will report this later when I changed harddisks. Under linux it does nothing. When suspended the three LEDs (1)Power (beneath the power button) (2)Power beneath the wireless slider (both blue) and (3)Battery2 are blinking. >> and one that shows the sign of a >> lock with up and down arrows in it. > > That is Scroll Lock. I do not think fujitsu-laptop has anything to do > with it. If it does not work the way you expect it to, you might want > to search the web, because there are known inconsistencies in how > various distributions handle it. Scroll lock works as expected. KDE had taken scroll lock due to a configuration I had forgotten. >> The case is equipped with a slider >> for Wireless on/off, if that matters. > > It does, see also below. > >> Although the message seems to be harmless I am somewhat embarrassed what >> happens here and thought I might report it to someone with more knowledge ;) > > Again, thank you for the report, because implementing a feature like > this in a platform driver often requires at least some guesswork, which > may result in that feature working for some users and misbehaving for > others. This is an example of such a situation. > > As you may have inferred from the patchwork link you visited, I was not > sure whether my method of detecting radio LED presence was correct. > Your report clearly proves I was wrong. Could you please send me the > BTNI value reported on your laptop? You should be able to look it up by > running: > > $ dmesg | grep BTNI 682:[ 12.189363] fujitsu_laptop: BTNI: [0x10f0101] > In fact, posting your entire dmesg output somewhere would not hurt > either. http://pasted.co/ce997722 > Anyway, you were curious what causes these log messages to appear. I > believe it happens because fujitsu-laptop _thinks_ you have a radio LED > present on your machine, which causes it to register this LED with a > default trigger set to rfkill-any. This means the kernel tries to > enable this LED whenever any radio transmitter is active and disable it > when all radio transmissions are disabled. In order to set the state of > the LED, the kernel driver calls a function exposed by the firmware. > This function returns an error, which is logged. The specific error > number you are seeing (-2147483648) means "unsupported command", which > means fujitsu-laptop attempted to use a feature which is unsupported by > your laptop's firmware. If you want to get rid of these messages, > running the following after every reboot should be enough: > > # echo "none" > /sys/class/leds/fujitsu::radio_led/trigger > > However, I would appreciate it if you could help us with finding out the > correct way to detect the radio LED (it may as well turn out it is not > possible by just checking firmware contents). For starters, we will > need your laptop's DSDT table, which you can extract using: > > # cat /sys/firmware/acpi/tables/DSDT > dsdt.bi
Re: [PATCH] gpio: drop unnecessary includes from include/linux/gpio/driver.h
On Mon, Jul 31, 2017 at 4:04 PM, Andy Shevchenko wrote: > On Mon, 2017-07-31 at 15:48 +0200, Linus Walleij wrote: >> On Tue, Jul 4, 2017 at 12:06 PM, Andy Shevchenko >> wrote: >> > On Tue, 2017-07-04 at 12:53 +0900, Masahiro Yamada wrote: >> > > Some of include directives in include/linux/gpio/driver.h are >> > > unneeded because the header does not need to know the content of >> > > struct device, irq_chip, etc. Just declare they are structures. >> > > >> > > On the other hand, and >> > > >> > > turned out to be necessary for irq_flow_handler_t and spinlock_t, >> > > respectively. >> > > >> > > Each driver should include what it needs without relying on what >> > > is >> > > implicitly included from . This will cut >> > > down >> > > unnecessary header parsing. >> > >> > If Linus is okay with the following proposal I would rather go with >> > it, >> > i.e. logical split the series to >> > >> > 1. Fix IRQ related headers inclusion >> > 2. Fix pinconf-generic.h inclusion >> > 3. Fix OF headers inclusion (btw, of_gpio.h is not enough there?) >> >> That works fine with me, but also one big patch actually, I do not >> want to make it too much work to refactor obviously incorrect things. >> >> As soon as we have rough consensus on this and the build robot >> are happy I will apply it to GPIO and also pull it into the pinctrl >> subsystem. > > For me priorities like this: > 1) it works after the patch being applied (no regressions); > 2) it makes code cleaner at the end; > 3) it is presented in logically split parts. > > So, as long as 1) and 2) are satisfied I can neglect on 3). We are in violent agreement :D Yours, Linus Walleij
Re: [PATCH] gpio: replace __maybe_unused in gpiolib.h with static inline
On Tue, Jul 11, 2017 at 4:41 PM, Masahiro Yamada wrote: > In header files, static inline is more commonly used. > > Signed-off-by: Masahiro Yamada Good point. Patch applied. Yours, Linus Walleij
[PATCH] f2fs: update cur_valid_map_mir together with cur_valid_map
When cur_valid_map passes the f2fs_test_and_set(,clear)_bit test, cur_valid_map_mir update is skipped unlikely, so fix it. Signed-off-by: Yunlong Song --- fs/f2fs/segment.c | 8 1 file changed, 8 insertions(+) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index 151968e..6f7731a 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -1535,6 +1535,10 @@ static void update_sit_entry(struct f2fs_sb_info *sbi, block_t blkaddr, int del) f2fs_bug_on(sbi, 1); #endif } +#ifdef CONFIG_F2FS_CHECK_FS + else + f2fs_set_bit(offset, se->cur_valid_map_mir); +#endif if (f2fs_discard_en(sbi) && !f2fs_test_and_set_bit(offset, se->discard_map)) sbi->discard_blks--; @@ -1556,6 +1560,10 @@ static void update_sit_entry(struct f2fs_sb_info *sbi, block_t blkaddr, int del) f2fs_bug_on(sbi, 1); #endif } +#ifdef CONFIG_F2FS_CHECK_FS + else + f2fs_clear_bit(offset, se->cur_valid_map_mir); +#endif if (f2fs_discard_en(sbi) && f2fs_test_and_clear_bit(offset, se->discard_map)) sbi->discard_blks++; -- 1.8.5.2
Re: [PATCH 3/3] mm/sched: memdelay: memory health interface for systems and workloads
On Mon, Jul 31, 2017 at 02:41:42PM -0400, Johannes Weiner wrote: > On Mon, Jul 31, 2017 at 10:31:11AM +0200, Peter Zijlstra wrote: > > So could you start by describing what actual statistics we need? Because > > as is the scheduler already does a gazillion stats and why can't re > > repurpose some of those? > > If that's possible, that would be great of course. > > We want to be able to tell how many tasks in a domain (the system or a > memory cgroup) are inside a memdelay section as opposed to how many And you haven't even defined wth a memdelay section is yet.. > are in a "productive" state such as runnable or iowait. Then derive > from that whether the domain as a whole is unproductive (all non-idle > tasks memdelayed), or partially unproductive (some delayed, but CPUs > are productive or there are iowait tasks). Then derive the percentages > of walltime the domain spends partially or fully unproductive. > > For that we need per-domain counters for > > 1) nr of tasks in memdelay sections > 2) nr of iowait or runnable/queued tasks that are NOT inside > memdelay sections And I still have no clue..
Re: [PATCH] pinctrl: rza1: constify gpio_chip structure
On Tue, Jul 11, 2017 at 8:22 PM, Gustavo A. R. Silva
wrote:
> This structure is only used to copy into other structure, so declare
> it as const.
>
> This issue was detected using Coccinelle and the following semantic patch:
>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct gpio_chip i@p = { ... };
>
> @ok@
> identifier r.i;
> expression e;
> position p;
> @@
> e = i@p;
>
> @bad@
> position p != {r.p,ok.p};
> identifier r.i;
> struct gpio_chip e;
> @@
> e@i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
> struct gpio_chip i = { ... };
>
> In the following log you can see a significant difference in the code size
> and data segment, hence in the dec segment. This log is the output
> of the size command, before and after the code change:
>
> before:
>textdata bss dec hex filename
> 118663520 128 155143c9a drivers/pinctrl/pinctrl-rza1.o
>
> after:
>textdata bss dec hex filename
> 115393464 128 151313b1b drivers/pinctrl/pinctrl-rza1.o
>
> Signed-off-by: Gustavo A. R. Silva
Patch applied.
Yours,
Linus Walleij
Re: [PATCH] pinctrl: vt8500: wmt: constify gpio_chip structure
On Tue, Jul 11, 2017 at 8:28 PM, Gustavo A. R. Silva
wrote:
> This structure is only used to copy into other structure, so declare
> it as const.
>
> This issue was detected using Coccinelle and the following semantic patch:
>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct gpio_chip i@p = { ... };
>
> @ok@
> identifier r.i;
> expression e;
> position p;
> @@
> e = i@p;
>
> @bad@
> position p != {r.p,ok.p};
> identifier r.i;
> struct gpio_chip e;
> @@
> e@i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
> struct gpio_chip i = { ... };
>
> In the following log you can see a significant difference in the code size
> and data segment, hence in the dec segment. This log is the output
> of the size command, before and after the code change:
>
> before:
>textdata bss dec hex filename
>77542328 0 100822762 drivers/pinctrl/vt8500/pinctrl-wmt.o
>
> after:
>textdata bss dec hex filename
>74722272 097442610 drivers/pinctrl/vt8500/pinctrl-wmt.o
>
> Signed-off-by: Gustavo A. R. Silva
Patch applied.
Yours,
Linus Walleij
Re: [PATCH] dma-mapping: Reduce dma_mapping_error() inline bloat
Hi Robin,
On 2017-07-24 19:29, Robin Murphy wrote:
Thanks to the nested inlining, all drivers correctly calling
dma_mapping_error() after a mapping a page or single buffer generate two
calls to get_arch_dma_ops() per callsite, which all adds up to a fair
old chunk of useless code, e.g. ~3KB for an arm64 defconfig plus extras:
text data bss dec hex filename
130513911503898 327768 14883057 e318f1 vmlinux.o.old
130507511503898 327768 14882417 e31671 vmlinux.o.new
Give the compiler a hand by making it clear we want the same ops.
Reviewed-by: Marek Szyprowski
Similar pattern is used in drivers/xen/swiotlb-xen.c for mmap and
get_sgtable. This could be also fixed, although those are not used so
frequently as dma_mapping_error.
Signed-off-by: Robin Murphy
---
include/linux/dma-mapping.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 843ab866e0f4..239e53d12ee8 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -541,10 +541,11 @@ static inline void dma_free_noncoherent(struct device
*dev, size_t size,
static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
- debug_dma_mapping_error(dev, dma_addr);
+ const struct dma_map_ops *ops = get_dma_ops(dev);
- if (get_dma_ops(dev)->mapping_error)
- return get_dma_ops(dev)->mapping_error(dev, dma_addr);
+ debug_dma_mapping_error(dev, dma_addr);
+ if (ops->mapping_error)
+ return ops->mapping_error(dev, dma_addr);
return 0;
}
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH] pinctrl: nomadik: abx500: constify gpio_chip structure
On Tue, Jul 11, 2017 at 11:29 PM, Gustavo A. R. Silva
wrote:
> This structure is only used to copy into another structure, so declare
> it as const.
>
> This issue was detected using Coccinelle and the following semantic patch:
>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct gpio_chip i@p = { ... };
>
> @ok@
> identifier r.i;
> expression e;
> position p;
> @@
> e = i@p;
>
> @bad@
> position p != {r.p,ok.p};
> identifier r.i;
> struct gpio_chip e;
> @@
> e@i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
> struct gpio_chip i = { ... };
>
> In the following log you can see a significant difference in the code size
> and data segment, hence in the dec segment. This log is the output
> of the size command, before and after the code change:
>
> before:
>textdata bss dec hex filename
> 175455376 0 229215989
> drivers/pinctrl/nomadik/pinctrl-abx500.o
>
> after:
> bss dec hex filename
> 172735320 0 225935841
> drivers/pinctrl/nomadik/pinctrl-abx500.o
>
> Signed-off-by: Gustavo A. R. Silva
Patch applied.
Yours,
Linus Walleij
Re: [PATCH] pinctrl: coh901: constify gpio_chip structure
On Tue, Jul 11, 2017 at 11:35 PM, Gustavo A. R. Silva
wrote:
> This structure is only used to copy into another structure, so declare
> it as const.
>
> This issue was detected using Coccinelle and the following semantic patch:
>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct gpio_chip i@p = { ... };
>
> @ok@
> identifier r.i;
> expression e;
> position p;
> @@
> e = i@p;
>
> @bad@
> position p != {r.p,ok.p};
> identifier r.i;
> struct gpio_chip e;
> @@
> e@i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
> struct gpio_chip i = { ... };
>
> In the following log you can see a significant difference in the code size
> and data segment, hence in the dec segment. This log is the output
> of the size command, before and after the code change:
>
> before:
>textdata bss dec hex filename
> 127753696 64 165354097 drivers/pinctrl/pinctrl-coh901.o
>
> after:
> bss dec hex filename
> 124403640 64 161443f10 drivers/pinctrl/pinctrl-coh901.o
>
> Signed-off-by: Gustavo A. R. Silva
Patch applied.
Yours,
Linus Walleij
Re: [PATCH] pinctrl: qcom: ssbi-gpio: constify gpio_chip structure
On Tue, Jul 11, 2017 at 8:39 PM, Gustavo A. R. Silva
wrote:
> This structure is only used to copy into other structure, so declare
> it as const.
>
> This issue was detected using Coccinelle and the following semantic patch:
>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct gpio_chip i@p = { ... };
>
> @ok@
> identifier r.i;
> expression e;
> position p;
> @@
> e = i@p;
>
> @bad@
> position p != {r.p,ok.p};
> identifier r.i;
> struct gpio_chip e;
> @@
> e@i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
> struct gpio_chip i = { ... };
>
> In the following log you can see a significant difference in the code size
> and data segment, hence in the dec segment. This log is the output
> of the size command, before and after the code change:
>
> before:
>textdata bss dec hex filename
> 170616992 0 240535df5
> drivers/pinctrl/qcom/pinctrl-ssbi-gpio.o
>
> after:
>textdata bss dec hex filename
> 167776904 0 236815c81
> drivers/pinctrl/qcom/pinctrl-ssbi-gpio.o
>
> Signed-off-by: Gustavo A. R. Silva
Patch applied with Björn's ACK.
Yours,
Linus Walleij
[PATCH v2 4/4] clocksource/arm_arch_timer: Use static_branch_enable_cpuslocked()
Use the new static_branch_enable_cpuslocked function to switch the workaround static key on the CPU hotplug path. Signed-off-by: Marc Zyngier --- drivers/clocksource/arm_arch_timer.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index aae87c4c546e..c62e71614c75 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -455,7 +455,11 @@ void arch_timer_enable_workaround(const struct arch_timer_erratum_workaround *wa per_cpu(timer_unstable_counter_workaround, i) = wa; } - static_branch_enable(&arch_timer_read_ool_enabled); + /* +* Use the locked version, as we're called from the CPU +* hotplug framework. Otherwise, we end-up in deadlock-land. +*/ + static_branch_enable_cpuslocked(&arch_timer_read_ool_enabled); /* * Don't use the vdso fastpath if errata require using the -- 2.11.0
Re: [PATCH] pinctrl: qcom: msm: constify gpio_chip structure
On Tue, Jul 11, 2017 at 8:34 PM, Gustavo A. R. Silva
wrote:
> This structure is only used to copy into other structure, so declare
> it as const.
>
> This issue was detected using Coccinelle and the following semantic patch:
>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct gpio_chip i@p = { ... };
>
> @ok@
> identifier r.i;
> expression e;
> position p;
> @@
> e = i@p;
>
> @bad@
> position p != {r.p,ok.p};
> identifier r.i;
> struct gpio_chip e;
> @@
> e@i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
> struct gpio_chip i = { ... };
>
> In the following log you can see a significant difference in the code size
> and data segment, hence in the dec segment. This log is the output
> of the size command, before and after the code change:
>
> before:
>textdata bss dec hex filename
> 131292808 192 161293f01 drivers/pinctrl/qcom/pinctrl-msm.o
>
> after:
>textdata bss dec hex filename
> 128392720 192 157513d87 drivers/pinctrl/qcom/pinctrl-msm.o
>
> Signed-off-by: Gustavo A. R. Silva
Patch applied with Björn's ACK.
Yours,
Linus Walleij
[PATCH v2 0/4] Working around CPU hotplug and static keys locking
Since f2545b2d4ce1 ("jump_label: Reorder hotplug lock and
jump_label_lock"), it has become impossible to switch a static key
from a CPU hotplug notifier:
- On the primary CPU, cpu_hotplug_lock is taken by
__cpuhp_setup_state(), and then again by static_key_slow_inc(). The
lock being taken as a reader, so it is OK so far.
- On a secondary CPU, _cpu_up takes the lock *as a writer* on the boot
CPU, and the secondary tries to switch the static key, taking the
lock as well (as a reader). In that case, we're toasted.
I couldn't find an elegant solution to this, so this series works
around the issue in the most disgusting way, adding a _nolock version
of the static key API to be used in CPU hotplug situations.
The last patch uses this API to work around the issue that Leo
reported, where the static key flipped on a secondary CPU brings the
box down in flames.
Marc Zyngier (4):
jump_label: Move cpu hotplug locking
jump_label: Split out code under the hotplug lock
jump_label: Provide hotplug context variants
clocksource/arm_arch_timer: Use static_branch_enable_cpuslocked()
Documentation/static-keys.txt| 15
drivers/clocksource/arm_arch_timer.c | 6 -
include/linux/jump_label.h | 11 +++--
kernel/jump_label.c | 44 +++-
4 files changed, 67 insertions(+), 9 deletions(-)
--
2.11.0
Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
On Tue, 2017-08-01 at 09:52 +0200, Linus Walleij wrote: > On Fri, Jul 21, 2017 at 6:49 PM, Grygorii Strashko > wrote: > > > Now IRQ mappings are always created for all (allowed) GPIOs in gpiochip in > > gpiochip_irqchip_add_key() which goes against the idea of SPARSE_IRQ and, > > as result, leads to: > > - increasing of memory consumption for IRQ descriptors most of which will > > never ever be used (espessially on platform with a high number of GPIOs). > > (sizeof(struct irq_desc) == 256 on my tested platforms) > > - imposibility to use GPIO irqchip APIs by gpio drivers when HW implements > > GPIO IRQ functionality as IRQ crossbar/router which has only limited > > number of IRQ outputs (example from [1], all GPIOs can be mapped on only 8 > > IRQs). Sorry, I forgot to reply to this thread until now. This patch is generalization of create mapping in the gpio_to_irq, right ? So the issue of mapping left lying around until the gpio driver is unloaded is still there ? Having gpio_irq_prepare/gpio_irq_unprepare would solve that, I suppose (Again, sorry I could not send an RFC for this yet ...) > > > > Hence, remove static IRQ mapping code from gpiochip_irqchip_add_key() and > > instead replace irq_find_mapping() with irq_create_mapping() in > > gpiochip_to_irq(). Also add additional gpiochip_irqchip_irq_valid() calls > > in gpiochip_to_irq() and gpiochip_irq_map(). > > > > After this change gpio2irq mapping will happen the following way when GPIO > > irqchip APIs are used by gpio driver: > > - IRQ mappings will be created statically if driver passes first_irq>0 > > vlaue in gpiochip_irqchip_add_key(). > > - IRQ mappings will be created dynamically from gpio_to_irq() or > > of_irq_get(). > > > > Tested on am335x-evm and dra72-evm-revc. > > - dra72-evm-revc: number of created irq mappings decreased from 402 -> 135 > > Mem savings 267*256 = 68352 (66kB) > > - am335x-evm: number of created irq mappings decreased from 188 -> 63 > > Mem savings 125*256 = 32000 (31kB) > > > > [1] https://lkml.org/lkml/2017/6/15/428 > > Signed-off-by: Grygorii Strashko > > --- > > Changes in v2: > > - restored struct gpio_chip->irq_base to fix buld of gpio-mockup.c > > Applied this rather than v1. > > But maybe we should get rid of ->irq_base from gpio-mockup.c > and delete it, as the base is irqchip-internal. > > Bartosz what do you say? Do we need this in the mockup? > > Yours, > Linus Walleij
[PATCH v2 3/4] jump_label: Provide hotplug context variants
As using the normal static key API under the hotplug lock is
pretty much impossible, let's provide a variant of some of them
that require the hotplug lock to have already been taken.
These function are only meant to be used in CPU hotplug callbacks.
Signed-off-by: Marc Zyngier
---
Documentation/static-keys.txt | 15 +++
include/linux/jump_label.h| 11 +--
kernel/jump_label.c | 20
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt
index b83dfa1c0602..6d0a181e74d2 100644
--- a/Documentation/static-keys.txt
+++ b/Documentation/static-keys.txt
@@ -149,6 +149,21 @@ static_branch_inc(), will change the branch back to true.
Likewise, if the
key is initialized false, a 'static_branch_inc()', will change the branch to
true. And then a 'static_branch_dec()', will again make the branch false.
+Note that switching branches results in some locks being taken,
+particularly the CPU hotplug lock (in order to avoid races against
+CPUs being brought in the kernel whilst the kernel is getting
+patched). Calling the static key API from within a hotplug notifier is
+thus a sure deadlock recipe. In order to still allow use of the
+functionnality, the following functions are provided:
+
+ static_key_enable_cpuslocked()
+ static_key_disable_cpuslocked()
+ static_branch_enable_cpuslocked()
+ static_branch_disable_cpuslocked()
+
+These functions are *not* general purpose, and must only be used when
+you really know that you're in the above context, and no other.
+
Where an array of keys is required, it can be defined as::
DEFINE_STATIC_KEY_ARRAY_TRUE(keys, count);
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 2afd74b9d844..c5e5d2ffce58 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -163,6 +163,8 @@ extern void jump_label_apply_nops(struct module *mod);
extern int static_key_count(struct static_key *key);
extern void static_key_enable(struct static_key *key);
extern void static_key_disable(struct static_key *key);
+extern void static_key_enable_cpuslocked(struct static_key *key);
+extern void static_key_disable_cpuslocked(struct static_key *key);
/*
* We should be using ATOMIC_INIT() for initializing .enabled, but
@@ -252,6 +254,9 @@ static inline void static_key_disable(struct static_key
*key)
static_key_slow_dec(key);
}
+#define static_key_enable_cpuslocked(k)static_key_enable((k))
+#define static_key_disable_cpuslocked(k) static_key_disable((k))
+
#define STATIC_KEY_INIT_TRUE { .enabled = ATOMIC_INIT(1) }
#define STATIC_KEY_INIT_FALSE { .enabled = ATOMIC_INIT(0) }
@@ -413,8 +418,10 @@ extern bool wrong_branch_error(void);
* Normal usage; boolean enable/disable.
*/
-#define static_branch_enable(x)static_key_enable(&(x)->key)
-#define static_branch_disable(x) static_key_disable(&(x)->key)
+#define static_branch_enable(x)
static_key_enable(&(x)->key)
+#define static_branch_disable(x) static_key_disable(&(x)->key)
+#define static_branch_enable_cpuslocked(x)
static_key_enable_cpuslocked(&(x)->key)
+#define static_branch_disable_cpuslocked(x)
static_key_disable_cpuslocked(&(x)->key)
#endif /* __ASSEMBLY__ */
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 0ab8b35daa54..4e7fa067ca17 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -170,6 +170,26 @@ static void static_key_slow_dec_cpuslocked(struct
static_key *key,
jump_label_unlock();
}
+void static_key_enable_cpuslocked(struct static_key *key)
+{
+ int count = static_key_count(key);
+
+ WARN_ON_ONCE(count < 0 || count > 1);
+
+ if (!count)
+ static_key_slow_inc_cpuslocked(key);
+}
+
+void static_key_disable_cpuslocked(struct static_key *key)
+{
+ int count = static_key_count(key);
+
+ WARN_ON_ONCE(count < 0 || count > 1);
+
+ if (count)
+ static_key_slow_dec_cpuslocked(key, 0, NULL);
+}
+
static void __static_key_slow_dec(struct static_key *key,
unsigned long rate_limit,
struct delayed_work *work)
--
2.11.0
[PATCH v2 1/4] jump_label: Move cpu hotplug locking
As we're about to rework the locking, let's move the taking and
release of the CPU hotplug lock to locations that will make its
reworking completely obvious.
Signed-off-by: Marc Zyngier
---
kernel/jump_label.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index d11c506a6ac3..f11b10091100 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -105,6 +105,7 @@ void static_key_slow_inc(struct static_key *key)
{
int v, v1;
+ cpus_read_lock();
STATIC_KEY_CHECK_USE();
/*
@@ -121,11 +122,12 @@ void static_key_slow_inc(struct static_key *key)
*/
for (v = atomic_read(&key->enabled); v > 0; v = v1) {
v1 = atomic_cmpxchg(&key->enabled, v, v + 1);
- if (likely(v1 == v))
+ if (likely(v1 == v)) {
+ cpus_read_unlock();
return;
+ }
}
- cpus_read_lock();
jump_label_lock();
if (atomic_read(&key->enabled) == 0) {
atomic_set(&key->enabled, -1);
--
2.11.0
[PATCH v2 2/4] jump_label: Split out code under the hotplug lock
In order to later introduce an "already locked" version of some
of the static key funcions, let's split the code into the core stuff
(the *_cpuslocked functions) and the usual helpers, which now
take/release the hotplug lock and call into the _cpuslocked
versions.
Signed-off-by: Marc Zyngier
---
kernel/jump_label.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index f11b10091100..0ab8b35daa54 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -101,11 +101,10 @@ void static_key_disable(struct static_key *key)
}
EXPORT_SYMBOL_GPL(static_key_disable);
-void static_key_slow_inc(struct static_key *key)
+static void static_key_slow_inc_cpuslocked(struct static_key *key)
{
int v, v1;
- cpus_read_lock();
STATIC_KEY_CHECK_USE();
/*
@@ -122,10 +121,8 @@ void static_key_slow_inc(struct static_key *key)
*/
for (v = atomic_read(&key->enabled); v > 0; v = v1) {
v1 = atomic_cmpxchg(&key->enabled, v, v + 1);
- if (likely(v1 == v)) {
- cpus_read_unlock();
+ if (likely(v1 == v))
return;
- }
}
jump_label_lock();
@@ -137,14 +134,20 @@ void static_key_slow_inc(struct static_key *key)
atomic_inc(&key->enabled);
}
jump_label_unlock();
+}
+
+void static_key_slow_inc(struct static_key *key)
+{
+ cpus_read_lock();
+ static_key_slow_inc_cpuslocked(key);
cpus_read_unlock();
}
EXPORT_SYMBOL_GPL(static_key_slow_inc);
-static void __static_key_slow_dec(struct static_key *key,
- unsigned long rate_limit, struct delayed_work *work)
+static void static_key_slow_dec_cpuslocked(struct static_key *key,
+ unsigned long rate_limit,
+ struct delayed_work *work)
{
- cpus_read_lock();
/*
* The negative count check is valid even when a negative
* key->enabled is in use by static_key_slow_inc(); a
@@ -155,7 +158,6 @@ static void __static_key_slow_dec(struct static_key *key,
if (!atomic_dec_and_mutex_lock(&key->enabled, &jump_label_mutex)) {
WARN(atomic_read(&key->enabled) < 0,
"jump label: negative count!\n");
- cpus_read_unlock();
return;
}
@@ -166,6 +168,14 @@ static void __static_key_slow_dec(struct static_key *key,
jump_label_update(key);
}
jump_label_unlock();
+}
+
+static void __static_key_slow_dec(struct static_key *key,
+ unsigned long rate_limit,
+ struct delayed_work *work)
+{
+ cpus_read_lock();
+ static_key_slow_dec_cpuslocked(key, rate_limit, work);
cpus_read_unlock();
}
--
2.11.0
[PATCH v6 0/2] add UniPhier thermal support
This series adds support for CPU temperature monitor modules implemented on UniPhier LD20 and PXs2 SoCs. This driver supports temperature monitoring and alert function on the module. Changes since v5: - replace of_get_property() with of_property_get_u32_array() - get the cariblation value in DT after failure to get the value from register Changes since v4: - fix warnings from sparse by replacing u32 with __be32 Changes since v3: - remove TMOD_MASK and use TMOD_WIDTH representing the bit width of TMOD Changes since v2: - add nsleep after starting and stopping PVT - replace temperature calculation with sign_extend32() Changes since v1: - separate dts from this patchset as another patchset - remove 'reg' description on the dt-bindings document - fix the order of calling initialization functions - replace mask bits to use GENMASK - fix calculation of temperature because of not considering a negative value - use devm_request_threaded_irq() instead of devm_request_irq() and separate a thread function from the interrupt handler - add dependency to Kconfig - set 120C to CRITICAL_TEMP_LIMIT as maximum temperature - shrink each line of parameters to save the number of lines - improve some comments and copyright description Kunihiko Hayashi (2): dt-bindings: thermal: add binding documentation for UniPhier thermal monitor thermal: uniphier: add UniPhier thermal driver .../bindings/thermal/uniphier-thermal.txt | 64 drivers/thermal/Kconfig| 8 + drivers/thermal/Makefile | 1 + drivers/thermal/uniphier_thermal.c | 384 + 4 files changed, 457 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/uniphier-thermal.txt create mode 100644 drivers/thermal/uniphier_thermal.c -- 2.7.4
Re: [PATCH 1/2] pinctrl: stm32: select IRQ_DOMAIN_HIERARCHY instead of depends on
On Wed, Jul 12, 2017 at 1:11 AM, Masahiro Yamada wrote: > Drivers that need IRQ_DOMAIN_HIERARCHY should "select" it, but > drivers/pinctrl/stm32/Kconfig is the only exception that uses > "depends on" syntax. This prevents GPIO drivers from select'ing > IRQ_DOMAIN_HIERARCHY. > > For example, if I add "select IRQ_DOMAIN_HIERARCHY" to GPIO_XGENE_SB, > I get the following recursive dependency error. > > drivers/gpio/Kconfig:13:error: recursive dependency detected! > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpio/Kconfig:13:symbol GPIOLIB is selected by PINCTRL_STM32 > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/pinctrl/stm32/Kconfig:3:symbol PINCTRL_STM32 is selected by > PINCTRL_STM32F429 > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/pinctrl/stm32/Kconfig:11: symbol PINCTRL_STM32F429 depends on > IRQ_DOMAIN_HIERARCHY > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > kernel/irq/Kconfig:67: symbol IRQ_DOMAIN_HIERARCHY is selected by > GPIO_XGENE_SB > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpio/Kconfig:502: symbol GPIO_XGENE_SB depends on GPIOLIB > > Signed-off-by: Masahiro Yamada Patch applied for GPIO fixes with Alexandre's test tag. Yours, Linus Walleij
[PATCH v6 2/2] thermal: uniphier: add UniPhier thermal driver
Add a thermal driver for on-chip PVT (Process, Voltage and Temperature)
monitoring unit implemented on UniPhier SoCs. This driver supports
temperature monitoring and alert function.
Signed-off-by: Kunihiko Hayashi
---
drivers/thermal/Kconfig| 8 +
drivers/thermal/Makefile | 1 +
drivers/thermal/uniphier_thermal.c | 384 +
3 files changed, 393 insertions(+)
create mode 100644 drivers/thermal/uniphier_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b5b5fac..b9f2365 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -473,4 +473,12 @@ config ZX2967_THERMAL
the primitive temperature sensor embedded in zx2967 SoCs.
This sensor generates the real time die temperature.
+config UNIPHIER_THERMAL
+ tristate "Socionext UniPhier thermal driver"
+ depends on ARCH_UNIPHIER || COMPILE_TEST
+ depends on THERMAL_OF && MFD_SYSCON
+ help
+ Enable this to plug in UniPhier on-chip PVT thermal driver into the
+ thermal framework. The driver supports CPU thermal zone temperature
+ reporting and a couple of trip points.
endif
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 094d703..8b79bca 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -59,3 +59,4 @@ obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
+obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
diff --git a/drivers/thermal/uniphier_thermal.c
b/drivers/thermal/uniphier_thermal.c
new file mode 100644
index 000..9570473
--- /dev/null
+++ b/drivers/thermal/uniphier_thermal.c
@@ -0,0 +1,384 @@
+/**
+ * uniphier_thermal.c - Socionext UniPhier thermal driver
+ *
+ * Copyright 2014 Panasonic Corporation
+ * Copyright 2016-2017 Socionext Inc.
+ * All rights reserved.
+ *
+ * Author:
+ * Kunihiko Hayashi
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "thermal_core.h"
+
+/*
+ * block registers
+ * addresses are the offset from .block_base
+ */
+#define PVTCTLEN 0x
+#define PVTCTLEN_ENBIT(0)
+
+#define PVTCTLMODE 0x0004
+#define PVTCTLMODE_MASK0xf
+#define PVTCTLMODE_TEMPMON 0x5
+
+#define EMONREPEAT 0x0040
+#define EMONREPEAT_ENDLESS BIT(24)
+#define EMONREPEAT_PERIOD GENMASK(3, 0)
+#define EMONREPEAT_PERIOD_100 0x9
+
+/*
+ * common registers
+ * addresses are the offset from .map_base
+ */
+#define PVTCTLSEL 0x0900
+#define PVTCTLSEL_MASK GENMASK(2, 0)
+#define PVTCTLSEL_MONITOR 0
+
+#define SETALERT0 0x0910
+#define SETALERT1 0x0914
+#define SETALERT2 0x0918
+#define SETALERT_TEMP_OVF (GENMASK(7, 0) << 16)
+#define SETALERT_TEMP_OVF_VALUE(val) (((val) & GENMASK(7, 0)) << 16)
+#define SETALERT_ENBIT(0)
+
+#define PMALERTINTCTL 0x0920
+#define PMALERTINTCTL_CLR(ch) BIT(4 * (ch) + 2)
+#define PMALERTINTCTL_SET(ch) BIT(4 * (ch) + 1)
+#define PMALERTINTCTL_EN(ch) BIT(4 * (ch) + 0)
+#define PMALERTINTCTL_MASK (GENMASK(10, 8) | GENMASK(6, 4) | \
+GENMASK(2, 0))
+
+#define TMOD 0x0928
+#define TMOD_WIDTH 9
+
+#define TMODCOEF 0x0e5c
+
+#define TMODSETUP0_EN BIT(30)
+#define TMODSETUP0_VAL(val)(((val) & GENMASK(13, 0)) << 16)
+#define TMODSETUP1_EN BIT(15)
+#define TMODSETUP1_VAL(val)((val) & GENMASK(14, 0))
+
+/* SoC critical temperature */
+#define CRITICAL_TEMP_LIMIT(120 * 1000)
+
+/* Max # of alert channels */
+#define ALERT_CH_NUM 3
+
+/* SoC specific thermal sensor data */
+struct uniphier_tm_soc_data {
+ u32 map_base;
+ u32 block_base;
+ u32 tmod_setup_addr;
+};
+
+struct uniphier_tm_dev {
+ struct regmap *regmap;
+ struct device *dev;
+ bool alert_en[ALERT_CH_NUM];
+ struct thermal_zone_device *tz_dev;
+ const struct uniphier_tm_soc_data *data;
+};
+
+stati
[PATCH v6 1/2] dt-bindings: thermal: add binding documentation for UniPhier thermal monitor
Add devicetree binding documentation for thermal monitor implemented on
Socionext UniPhier SoCs.
Signed-off-by: Kunihiko Hayashi
Acked-by: Rob Herring
---
.../bindings/thermal/uniphier-thermal.txt | 64 ++
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/uniphier-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/uniphier-thermal.txt
b/Documentation/devicetree/bindings/thermal/uniphier-thermal.txt
new file mode 100644
index 000..686c0b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/uniphier-thermal.txt
@@ -0,0 +1,64 @@
+* UniPhier Thermal bindings
+
+This describes the devicetree bindings for thermal monitor supported by
+PVT(Process, Voltage and Temperature) monitoring unit implemented on Socionext
+UniPhier SoCs.
+
+Required properties:
+- compatible :
+ - "socionext,uniphier-pxs2-thermal" : For UniPhier PXs2 SoC
+ - "socionext,uniphier-ld20-thermal" : For UniPhier LD20 SoC
+- interrupts : IRQ for the temperature alarm
+- #thermal-sensor-cells : Should be 0. See ./thermal.txt for details.
+
+Optional properties:
+- socionext,tmod-calibration: A pair of calibrated values referred from PVT,
+ in case that the values aren't set on SoC,
+ like a reference board.
+
+Example:
+
+ sysctrl@6184 {
+ compatible = "socionext,uniphier-ld20-sysctrl",
+"simple-mfd", "syscon";
+ reg = <0x6184 0x1>;
+ ...
+ pvtctl: pvtctl {
+ compatible = "socionext,uniphier-ld20-thermal";
+ interrupts = <0 3 1>;
+ #thermal-sensor-cells = <0>;
+ };
+ ...
+ };
+
+ thermal-zones {
+ cpu_thermal {
+ polling-delay-passive = <250>; /* 250ms */
+ polling-delay = <1000>; /* 1000ms */
+ thermal-sensors = <&pvtctl>;
+
+ trips {
+ cpu_crit: cpu_crit {
+ temperature = <11>; /* 110C */
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ cpu_alert: cpu_alert {
+ temperature = <10>; /* 100C */
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert>;
+ cooling-device = <&cpu0 (-1) (-1)>;
+ };
+ map1 {
+ trip = <&cpu_alert>;
+ cooling-device = <&cpu2 (-1) (-1)>;
+ };
+ };
+ };
+ };
--
2.7.4
Re: [PATCH 2/2] gpio: xgene-sb: select IRQ_DOMAIN_HIERARCHY
On Wed, Jul 12, 2017 at 1:11 AM, Masahiro Yamada wrote: > This driver calls irq_domain_hierarchy() and irq_chip_*_parent(). > They are available only when CONFIG_IRQ_DOMAIN_HIERARCHY is enabled. > > Signed-off-by: Masahiro Yamada Patch applied for GPIO fixes on top of 1/2. Thanks for the thorough fix, very impressed with this good work. Yours, Linus Walleij
Re: [PATCH v2] [BUGFIX] gpio: reject invalid gpio before getting gpio_desc
On Mon, Jul 31, 2017 at 3:57 AM, Masami Hiramatsu wrote:
> Check user-given gpio number and reject it before
> calling gpio_to_desc() because gpio_to_desc() is
> for kernel driver and it expects given gpio number
> is valid (means 0 to 511).
> If given number is invalid, gpio_to_desc() calls
> WARN() and dump registers and stack for debug.
> This means user can easily kick WARN() just by
> writing invalid gpio number (e.g. 512) to
> /sys/class/gpio/export.
>
> Fixes: 0e9a5edf5d01 ("gpio: fix deferred probe detection for legacy API")
> Signed-off-by: Masami Hiramatsu
> ---
> Changes in v2:
>- Add gpio_to_valid_desc() according to Andy's comment (Thanks!).
>- Fix patch description.
I hate the old sysfs ABI sigh. Thanks for fixing it anyways!
Should this be tagged for stable?
Waiting for Andy's review before applying.
Yours,
Linus Walleij
Re: [PATCH 1/6] pinctrl: uniphier: remove unneeded EXPORT_SYMBOL_GPL()
On Mon, Jul 31, 2017 at 8:21 AM, Masahiro Yamada wrote: > All UniPhier pinctrl drivers are built-in. Exporting the symbol > is meaningless. > > Signed-off-by: Masahiro Yamada Patch applied. Yours, Linus Walleij
Re: [PATCH v1 01/15] perf, tools, stat: Fix buffer overflow while freeing events
On Mon, Jul 24, 2017 at 04:40:01PM -0700, Andi Kleen wrote:
SNIP
>
> The event is allocated with cpus == 1, but freed with cpus == real number
> When the evsel close function walks the file descriptors it exceeds the
> fd xyarray boundaries and reads random memory.
>
> Just make sure to always use the same dummy cpu map following
> the same logic as the open call.
>
> Signed-off-by: Andi Kleen
> ---
> tools/perf/builtin-stat.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index 48ac53b199fc..97d6b6c42014 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -715,6 +715,8 @@ static int __run_perf_stat(int argc, const char **argv)
>* group leaders.
>*/
> read_counters();
> + if (!target__has_cpu(&target))
> + evsel_list->cpus = cpu_map__dummy_new();
you're leaking evsel_list->cpus right here..
I can see there's the issue when we mix system_wide event
(with cpumask defined) and normal event:
- we open such group as per_thread events (not system_wide),
forcing both evsel->fd xyarray to be allocated from dummy
cpus (with ncpus == 1)
- but when we call perf_evlist__close we take ncpus from
int n = evsel->cpus ? evsel->cpus->nr : ncpus;
which is wrong for system_wide event and will
cause the xyarray out of bounds access
I can see the solution either in:
1) keeping the bounds for xyarray in it and use it for iterations
2) or forcing system_wide target if there's single system_wide event
specified (patch below)
but not sure there's any sense in meassuting system_wide
event in non system_wide mode (ad 1).. thoughts?
thanks,
jirka
---
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 866da7aa54bf..9ccb4d671568 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -2540,8 +2540,8 @@ static void setup_system_wide(int forks)
* conditions is met:
*
* - there's no workload specified
-* - there is workload specified but all requested
-* events are system wide events
+* - there is workload specified and one
+* of the events is system wide
*/
if (!target__none(&target))
return;
@@ -2552,12 +2552,11 @@ static void setup_system_wide(int forks)
struct perf_evsel *counter;
evlist__for_each_entry(evsel_list, counter) {
- if (!counter->system_wide)
+ if (counter->system_wide) {
+ target.system_wide = true;
return;
+ }
}
-
- if (evsel_list->nr_entries)
- target.system_wide = true;
}
}
Re: [linux-sunxi] [PATCH v3 03/12] ASoC: sun4i-i2s: Add regmap config to quirks
On Sat, Jul 29, 2017 at 10:17 PM, wrote: > From: Marcus Cooper > > The newer SoCs have a larger range than the original SoC that this > driver was developed for. By adding the regmap config to the quirks > then the driver can initialise the managed register map correctly. > > Signed-off-by: Marcus Cooper Reviewed-by: Chen-Yu Tsai
Re: [PATCH 2/6] pinctrl: uniphier: fix pin_config_get() for input-enable
On Mon, Jul 31, 2017 at 8:21 AM, Masahiro Yamada
wrote:
> For LD11/LD20 SoCs (capable of per-pin input enable), iectrl bits are
> located across multiple registers. So, the register offset must be
> taken into account. Otherwise, wrong input-enable status is displayed.
>
> While we here, rename the macro because it is a base address.
>
> Fixes: aa543888ca8c ("pinctrl: uniphier: support per-pin input enable for new
> SoCs")
> Signed-off-by: Masahiro Yamada
Patch applied.
Yours,
Linus Walleij
[PATCH v1.1] drm/rockchip: fix race with kms hotplug and fbdev
According to the kerneldoc[0], should do fbdev setup before calling drm_kms_helper_poll_init(), otherwise, Kms hotplug event may race into fbdev helper initial, and fb_helper->dev may be NULL pointer, that would cause the bug: [0.735411] [0200] *pgd=f6ffe003, *pud=f6ffe003, *pmd= [0.736156] Internal error: Oops: 9605 [#1] PREEMPT SMP [0.736648] Modules linked in: [0.736930] CPU: 2 PID: 20 Comm: kworker/2:0 Not tainted 4.4.41 #20 [0.737480] Hardware name: Rockchip RK3399 Board rev2 (BOX) (DT) [0.738020] Workqueue: events cdn_dp_pd_event_work [0.738447] task: ffc0f21f3100 ti: ffc0f2218000 task.ti: ffc0f2218000 [0.739109] PC is at mutex_lock+0x14/0x44 [0.739469] LR is at drm_fb_helper_hotplug_event+0x30/0x114 [0.756253] [] mutex_lock+0x14/0x44 [0.756260] [] drm_fb_helper_hotplug_event+0x30/0x114 [0.756271] [] rockchip_drm_output_poll_changed+0x18/0x20 [0.756280] [] drm_kms_helper_hotplug_event+0x28/0x34 [0.756286] [] cdn_dp_pd_event_work+0x394/0x3c4 [0.756295] [] process_one_work+0x218/0x3e0 [0.756302] [] worker_thread+0x2e8/0x404 [0.756308] [] kthread+0xe8/0xf0 [0.756316] [] ret_from_fork+0x10/0x40 [0]: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms-helpers.html Signed-off-by: Mark Yao --- Changes in v1.1: - According to the kerneldoc, fix the race bug in generic way. drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 848edcf..c41f48a 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -161,22 +161,21 @@ static int rockchip_drm_bind(struct device *dev) */ drm_dev->irq_enabled = true; - /* init kms poll for handling hpd */ - drm_kms_helper_poll_init(drm_dev); - ret = rockchip_drm_fbdev_init(drm_dev); if (ret) - goto err_kms_helper_poll_fini; + goto err_unbind_all; + + /* init kms poll for handling hpd */ + drm_kms_helper_poll_init(drm_dev); ret = drm_dev_register(drm_dev, 0); if (ret) - goto err_fbdev_fini; + goto err_kms_helper_poll_fini; return 0; -err_fbdev_fini: - rockchip_drm_fbdev_fini(drm_dev); err_kms_helper_poll_fini: drm_kms_helper_poll_fini(drm_dev); + rockchip_drm_fbdev_fini(drm_dev); err_unbind_all: component_unbind_all(dev, drm_dev); err_mode_config_cleanup: -- 1.9.1
[PATCH 1/3] phy: rockchip-inno-usb2: add companion grf quirk
The registers of usb-phy are distributed in grf and usbgrf on some
Rockchip SoCs (e.g RV1108), this patch add a quirk to support this
companion grf design.
Signed-off-by: Frank Wang
---
.../bindings/phy/phy-rockchip-inno-usb2.txt| 4 +
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 112 ++---
2 files changed, 78 insertions(+), 38 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
index 84d59b0..ddf868a 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -18,6 +18,10 @@ Optional properties:
usb-phy output 480m and xin24m.
Refer to clk/clock-bindings.txt for generic clock
consumer properties.
+ - rockchip,usbgrf : phandle to the syscon managing the "usb general
+register files".
+ - rockchip,companion_grf_quirk : when set driver will request
+"rockchip,usbgrf" phandle as one companion-grf.
Required nodes : a sub-node is required for each port the phy provides.
The sub-node name is used to identify host or otg port,
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 626883d..669e5f6 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -202,6 +202,7 @@ struct rockchip_usb2phy_port {
/**
* struct rockchip_usb2phy: usb2.0 phy driver data.
* @grf: General Register Files regmap.
+ * @usbgrf: USB General Register Files regmap.
* @clk: clock struct of phy input clk.
* @clk480m: clock struct of phy output clk.
* @clk_hw: clock struct of phy output clk management.
@@ -216,6 +217,7 @@ struct rockchip_usb2phy_port {
struct rockchip_usb2phy {
struct device *dev;
struct regmap *grf;
+ struct regmap *usbgrf;
struct clk *clk;
struct clk *clk480m;
struct clk_hw clk480m_hw;
@@ -225,9 +227,15 @@ struct rockchip_usb2phy {
struct extcon_dev *edev;
const struct rockchip_usb2phy_cfg *phy_cfg;
struct rockchip_usb2phy_portports[USB2PHY_NUM_PORTS];
+ unsigned intcompanion_grf_quirk:1;
};
-static inline int property_enable(struct rockchip_usb2phy *rphy,
+static inline struct regmap *get_reg_base(struct rockchip_usb2phy *rphy)
+{
+ return rphy->companion_grf_quirk ? rphy->usbgrf : rphy->grf;
+}
+
+static inline int property_enable(struct regmap *base,
const struct usb2phy_reg *reg, bool en)
{
unsigned int val, mask, tmp;
@@ -236,17 +244,17 @@ static inline int property_enable(struct rockchip_usb2phy
*rphy,
mask = GENMASK(reg->bitend, reg->bitstart);
val = (tmp << reg->bitstart) | (mask << BIT_WRITEABLE_SHIFT);
- return regmap_write(rphy->grf, reg->offset, val);
+ return regmap_write(base, reg->offset, val);
}
-static inline bool property_enabled(struct rockchip_usb2phy *rphy,
+static inline bool property_enabled(struct regmap *base,
const struct usb2phy_reg *reg)
{
int ret;
unsigned int tmp, orig;
unsigned int mask = GENMASK(reg->bitend, reg->bitstart);
- ret = regmap_read(rphy->grf, reg->offset, &orig);
+ ret = regmap_read(base, reg->offset, &orig);
if (ret)
return false;
@@ -258,11 +266,12 @@ static int rockchip_usb2phy_clk480m_prepare(struct clk_hw
*hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
+ struct regmap *base = get_reg_base(rphy);
int ret;
/* turn on 480m clk output if it is off */
- if (!property_enabled(rphy, &rphy->phy_cfg->clkout_ctl)) {
- ret = property_enable(rphy, &rphy->phy_cfg->clkout_ctl, true);
+ if (!property_enabled(base, &rphy->phy_cfg->clkout_ctl)) {
+ ret = property_enable(base, &rphy->phy_cfg->clkout_ctl, true);
if (ret)
return ret;
@@ -277,17 +286,19 @@ static void rockchip_usb2phy_clk480m_unprepare(struct
clk_hw *hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
+ struct regmap *base = get_reg_base(rphy);
/* turn off 480m clk output */
- property_enable(rphy, &rphy->phy_cfg->clkout_ctl, false);
+ property_enable(base, &rphy->phy_cfg->clkout_ctl, false);
}
static int rockchip_usb2phy_clk480m_prepared(struct clk_hw *hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
+ struct regmap *base = get_reg_base(rphy);
- return property_enabled(rphy, &rphy->phy_cfg->clkout_ctl);
+ return pr
[PATCH 0/3] add some quirks for Rockchip usb2-phy and add rv1108 SoCs' support
These series of patches add companion_grf_quirk and otg_mux_irq_quirk for rockchip usb2-phy. In addition, this change also add rv1108 usb2-phy support. Frank Wang (3): phy: rockchip-inno-usb2: add companion grf quirk phy: rockchip-inno-usb2: add otg mux irq quirk phy: rockchip-inno-usb2: add support of usb2-phy for rv1108 SoCs .../bindings/phy/phy-rockchip-inno-usb2.txt| 10 + drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 223 - 2 files changed, 182 insertions(+), 51 deletions(-) -- 2.0.0
[PATCH 3/3] phy: rockchip-inno-usb2: add support of usb2-phy for rv1108 SoCs
This adds support usb2-phy for rv1108 SoCs and amend phy Documentation.
Signed-off-by: Frank Wang
---
.../bindings/phy/phy-rockchip-inno-usb2.txt| 1 +
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 43 ++
2 files changed, 44 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
index d49572b..1479dda 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -6,6 +6,7 @@ Required properties (phy (parent) node):
* "rockchip,rk3328-usb2phy"
* "rockchip,rk3366-usb2phy"
* "rockchip,rk3399-usb2phy"
+ * "rockchip,rv1108-usb2phy"
- reg : the address offset of grf for usb-phy configuration.
- #clock-cells : should be 0.
- clock-output-names : specify the 480m output clock name.
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 925919c..85909c0 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -1405,11 +1405,54 @@ static const struct rockchip_usb2phy_cfg
rk3399_phy_cfgs[] = {
{ /* sentinel */ }
};
+static const struct rockchip_usb2phy_cfg rv1108_phy_cfgs[] = {
+ {
+ .reg = 0x100,
+ .num_ports = 2,
+ .clkout_ctl = { 0x108, 4, 4, 1, 0 },
+ .port_cfgs = {
+ [USB2PHY_PORT_OTG] = {
+ .phy_sus= { 0x0100, 15, 0, 0, 0x1d1 },
+ .bvalid_det_en = { 0x0680, 3, 3, 0, 1 },
+ .bvalid_det_st = { 0x0690, 3, 3, 0, 1 },
+ .bvalid_det_clr = { 0x06a0, 3, 3, 0, 1 },
+ .ls_det_en = { 0x0680, 2, 2, 0, 1 },
+ .ls_det_st = { 0x0690, 2, 2, 0, 1 },
+ .ls_det_clr = { 0x06a0, 2, 2, 0, 1 },
+ .utmi_bvalid= { 0x0804, 10, 10, 0, 1 },
+ .utmi_ls= { 0x0804, 13, 12, 0, 1 },
+ },
+ [USB2PHY_PORT_HOST] = {
+ .phy_sus= { 0x0104, 15, 0, 0, 0x1d1 },
+ .ls_det_en = { 0x0680, 4, 4, 0, 1 },
+ .ls_det_st = { 0x0690, 4, 4, 0, 1 },
+ .ls_det_clr = { 0x06a0, 4, 4, 0, 1 },
+ .utmi_ls= { 0x0804, 9, 8, 0, 1 },
+ .utmi_hstdet= { 0x0804, 7, 7, 0, 1 }
+ }
+ },
+ .chg_det = {
+ .opmode = { 0x0100, 3, 0, 5, 1 },
+ .cp_det = { 0x0804, 1, 1, 0, 1 },
+ .dcp_det= { 0x0804, 0, 0, 0, 1 },
+ .dp_det = { 0x0804, 2, 2, 0, 1 },
+ .idm_sink_en= { 0x0108, 8, 8, 0, 1 },
+ .idp_sink_en= { 0x0108, 7, 7, 0, 1 },
+ .idp_src_en = { 0x0108, 9, 9, 0, 1 },
+ .rdm_pdwn_en= { 0x0108, 10, 10, 0, 1 },
+ .vdm_src_en = { 0x0108, 12, 12, 0, 1 },
+ .vdp_src_en = { 0x0108, 11, 11, 0, 1 },
+ },
+ },
+ { /* sentinel */ }
+};
+
static const struct of_device_id rockchip_usb2phy_dt_match[] = {
{ .compatible = "rockchip,rk3228-usb2phy", .data = &rk3228_phy_cfgs },
{ .compatible = "rockchip,rk3328-usb2phy", .data = &rk3328_phy_cfgs },
{ .compatible = "rockchip,rk3366-usb2phy", .data = &rk3366_phy_cfgs },
{ .compatible = "rockchip,rk3399-usb2phy", .data = &rk3399_phy_cfgs },
+ { .compatible = "rockchip,rv1108-usb2phy", .data = &rv1108_phy_cfgs },
{}
};
MODULE_DEVICE_TABLE(of, rockchip_usb2phy_dt_match);
--
2.0.0
Re: [RFC PATCH v2] membarrier: expedited private command
On Tue, Aug 01, 2017 at 12:00:47PM +1000, Nicholas Piggin wrote: > Thanks for this, I'll take a look. This should be a good start as a stress > test, but I'd also be interested in some application. The reason being that > for example using runqueue locks may give reasonable maximum throughput > numbers, but could cause some latency or slowdown when it's used in more > realistic scenario. Given this is an unprivileged interface we have to consider DoS and other such lovely things. And since we cannot use mm_cpumask() we're stuck with for_each_online_cpu(). Combined that means that using rq->lock is completely out of the question, some numbnut doing 'for (;;) sys_membarrier();' can completely wreck the system. Yes, it might work for 'normal' workloads, but the interference potential is just too big. I have the same problem with Paul's synchronize_rcu_expedited() patch, that is a machine wide IPI spray and will interfere with unrelated work.
Re: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception
Hi Pratyush, On Mon, Jul 31, 2017 at 04:10:28PM +0530, Pratyush Anand wrote: > v2 -> v3 > - Moved step_needed from uapi structure to kernel only structure > - Re-enable interrupt if stepped instruction faults > - Modified register_wide_hw_breakpoint() to accept step_needed arg > v2 was here: http://marc.info/?l=linux-arm-kernel&m=149942910730496&w=2 > > v1 -> v2: > - patch 1 of v1 has been modified to patch 1-3 of v2. > - Introduced a new event attribute step_needed and implemented > hw_breakpoint_needs_single_step() (patch 1) > - Replaced usage of is_default_overflow_handler() with > hw_breakpoint_needs_single_step(). (patch 2) > - Modified sample test to set set step_needed bit field (patch 3) > v1 was here: http://marc.info/?l=linux-arm-kernel&m=149910958418708&w=2 > > samples/hw_breakpoint/data_breakpoint.c passes with x86_64 but fails with > ARM64. Even though it has been NAKed previously on upstream [1, 2], I have > tried to come up with patches which can resolve it for ARM64 as well. > > I noticed that even perf step exception can go into an infinite loop if CPU > receives an interrupt while executing breakpoint/watchpoint handler. So, > event though we are not concerned about above test, we will have to find a > solution for the perf issue. > > This patchset attempts to resolve both the issue. Please review. > Since, it also takes care of SW breakpoint, so I hope kgdb should also be > fine. However, I have not tested that. > @Takahiro: Will it be possible to test these patches for kgdb. I have not yet understood the details of your patch, but I gave it a try and didn't see any difference around the behavior of kgdb's single stepping. I also gave a try to James' patch, but again nothing different as long as kgdb is concerned. (I'm tackling some issue in single stepping at irq's kernel_exit, in particular, 'eret'.) -Takahiro AKASHI > [1] http://marc.info/?l=linux-arm-kernel&m=149580777524910&w=2 > [2] > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-April/425266.html
Re: [PATCH 3/6] pinctrl: uniphier: clean up GPIO port muxing
On Mon, Jul 31, 2017 at 8:21 AM, Masahiro Yamada wrote: > There are a bunch of GPIO muxing data, but most of them are actually > unneeded because GPIO-to-pin mapping can be specified by "gpio-ranges" > DT properties. > > Tables that contain a set of GPIO pins are still needed for the named > mapping by "gpio-ranges-group-names". This is a much cleaner way for > UniPhier SoC family where GPIO numbers are not straight mapped to pin > numbers. > > Signed-off-by: Masahiro Yamada Patch applied. Yours, Linus Walleij
[PATCH 2/3] phy: rockchip-inno-usb2: add otg mux irq quirk
The otg-id/otg-bvalid/linestate irqs are multiplexed to one irq in
otg-port on some Rockchip SoC (e.g RV1108), this patch add a quirk
to support this mux irq feature.
Signed-off-by: Frank Wang
---
.../bindings/phy/phy-rockchip-inno-usb2.txt| 5 ++
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 68 +-
2 files changed, 60 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
index ddf868a..d49572b 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -22,6 +22,8 @@ Optional properties:
register files".
- rockchip,companion_grf_quirk : when set driver will request
"rockchip,usbgrf" phandle as one companion-grf.
+ - rockchip,otg_mux_irq_quirk: set if otg-id/otg-bvalid/linestate irqs
+are multiplexed to one irq in otg-port on some SoCs.
Required nodes : a sub-node is required for each port the phy provides.
The sub-node name is used to identify host or otg port,
@@ -36,6 +38,9 @@ Required properties (port (child) node):
* "otg-id" : for the otg id interrupt.
* "otg-bvalid" : for the otg vbus interrupt.
* "linestate" : for the host/otg linestate interrupt.
+ * "otg-mux" : otg-port interrupt, which multiplex otg-id/otg-bvalid/
+ linestate irqs to one irq. Should specify if
+ rockchip,otg_mux_irq_quirk property is set.
Optional properties:
- phy-supply : phandle to a regulator that provides power to VBUS.
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 669e5f6..925919c 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -172,6 +172,8 @@ struct rockchip_usb2phy_cfg {
* @vbus_attached: otg device vbus status.
* @bvalid_irq: IRQ number assigned for vbus valid rise detection.
* @ls_irq: IRQ number assigned for linestate detection.
+ * @otg_mux_irq: IRQ number which multiplex otg-id/otg-bvalid/linestate
+ * irqs to one irq in otg-port.
* @mutex: for register updating in sm_work.
* @chg_work: charge detect work.
* @otg_sm_work: OTG state machine work.
@@ -189,6 +191,7 @@ struct rockchip_usb2phy_port {
boolvbus_attached;
int bvalid_irq;
int ls_irq;
+ int otg_mux_irq;
struct mutexmutex;
struct delayed_work chg_work;
struct delayed_work otg_sm_work;
@@ -228,6 +231,7 @@ struct rockchip_usb2phy {
const struct rockchip_usb2phy_cfg *phy_cfg;
struct rockchip_usb2phy_portports[USB2PHY_NUM_PORTS];
unsigned intcompanion_grf_quirk:1;
+ unsigned intotg_mux_irq_quirk:1;
};
static inline struct regmap *get_reg_base(struct rockchip_usb2phy *rphy)
@@ -935,6 +939,17 @@ static irqreturn_t rockchip_usb2phy_bvalid_irq(int irq,
void *data)
return IRQ_HANDLED;
}
+static irqreturn_t rockchip_usb2phy_otg_mux_irq(int irq, void *data)
+{
+ struct rockchip_usb2phy_port *rport = data;
+ struct rockchip_usb2phy *rphy = dev_get_drvdata(rport->phy->dev.parent);
+
+ if (property_enabled(rphy->grf, &rport->port_cfg->bvalid_det_st))
+ return rockchip_usb2phy_bvalid_irq(irq, data);
+ else
+ return IRQ_NONE;
+}
+
static int rockchip_usb2phy_host_port_init(struct rockchip_usb2phy *rphy,
struct rockchip_usb2phy_port *rport,
struct device_node *child_np)
@@ -1011,20 +1026,44 @@ static int rockchip_usb2phy_otg_port_init(struct
rockchip_usb2phy *rphy,
rport->utmi_avalid =
of_property_read_bool(child_np, "rockchip,utmi-avalid");
- rport->bvalid_irq = of_irq_get_byname(child_np, "otg-bvalid");
- if (rport->bvalid_irq < 0) {
- dev_err(rphy->dev, "no vbus valid irq provided\n");
- ret = rport->bvalid_irq;
- goto out;
- }
+ if (rphy->otg_mux_irq_quirk) {
+ rport->otg_mux_irq = of_irq_get_byname(child_np, "otg-mux");
+ if (rport->otg_mux_irq < 0) {
+ dev_err(rphy->dev, "no otg-mux irq provided\n");
+ ret = rport->otg_mux_irq;
+ goto out;
+ }
- ret = devm_request_threaded_irq(rphy->dev, rport->bvalid_irq, NULL,
- rockchip_usb2phy_bvalid_irq,
- IRQF_ONESHOT,
- "rockchip_usb2phy_bvalid", rport);
- if (ret) {
- dev_err(rphy->dev, "failed to request otg-bvalid irq handle\n");
-
Re: [PATCH 4/6] pinctrl: uniphier: omit redundant input enable bit information
On Mon, Jul 31, 2017 at 8:21 AM, Masahiro Yamada wrote: > For LD11/20 SoCs (capable of per-pin input enable), the iectrl bit > number matches its pin number. So, this is redundant information. > Instead, we just need a flag to know if the iectrl gating exists or not. > > With this refactoring, 5 bits in pin data will be saved. > > Signed-off-by: Masahiro Yamada Patch applied. Yours, Linus Walleij
Re: [PATCH 5/6] pinctrl: uniphier: add suspend / resume support
On Mon, Jul 31, 2017 at 8:21 AM, Masahiro Yamada wrote: > Save registers lost in the sleep when suspending, and restore them > when resuming. > > Signed-off-by: Masahiro Yamada Patch applied. Yours, Linus Walleij
Re: [PATCH] timers: Fix overflow in get_next_timer_interrupt
On 01/08/17 09:11, Matija Glavinic Pecotic wrote:
> For e.g. HZ=100, timer being 430 jiffies in the future, and 32 bit
> unsigned int, there is an overflow on unsigned int right-hand side
> of the expression which results with wrong values being returned.
>
> Problem was observed on tickless core and with following applied:
>
> sched/nohz: add debugfs control over sched_tick_max_deferment
> https://lkml.org/lkml/2013/9/16/499
>
> Signed-off-by: Matija Glavinic Pecotic
Reviewed-by: Alexander Sverdlin
> ---
> kernel/time/timer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
> index 71ce3f4..8f5d1bf 100644
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -1495,7 +1495,7 @@ u64 get_next_timer_interrupt(unsigned long basej, u64
> basem)
> base->is_idle = false;
> } else {
> if (!is_max_delta)
> - expires = basem + (nextevt - basej) * TICK_NSEC;
> + expires = basem + (u64)(nextevt - basej) * TICK_NSEC;
> /*
>* If we expect to sleep more than a tick, mark the base idle:
>*/
--
Best regards,
Alexander Sverdlin.
Re: [PATCH v3 1/5] hw_breakpoint: Add step_needed event attribute
On Mon, Jul 31, 2017 at 04:10:29PM +0530, Pratyush Anand wrote:
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 24a635887f28..7da951f94b47 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -233,6 +233,12 @@ struct hw_perf_event {
>*/
> u64 freq_time_stamp;
> u64 freq_count_stamp;
> + /*
> + * A HW breakpoint user can either have it's own step handling
> + * mechanism or it can use default step handling meachanism defined
> + * by arch code. Set step_needed to use default mechanism.
> + */
> + int step_needed;
You'll note that there is an anonymous structure inside the anonymous
union specifically dedicated to hardware breakpoint state. Why not put
it there?
> #endif
> };
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 6c4e523dc1e2..66ce5574e778 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -9444,9 +9444,11 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
> } else if (is_write_backward(event)){
> event->overflow_handler = perf_event_output_backward;
> event->overflow_handler_context = NULL;
> + event->hw.step_needed = 1;
> } else {
> event->overflow_handler = perf_event_output_forward;
> event->overflow_handler_context = NULL;
> + event->hw.step_needed = 1;
> }
These here need a comment, because even if I'd know now why the heck we
need that = 1 here, I'd sure as hell won't know tomorrow.
Re: [PATCH 6/6] pinctrl: uniphier: add UniPhier PXs3 pinctrl driver
On Mon, Jul 31, 2017 at 8:21 AM, Masahiro Yamada wrote: > Add pin configuration and pinmux support for UniPhier PXs3 SoC. > > Signed-off-by: Masahiro Yamada Patch applied. Yours, Linus Walleij
Re: [linux-sunxi] [PATCH v3 04/12] ASoC: sun4i-i2s: Add TX FIFO offset to quirks
On Sat, Jul 29, 2017 at 10:17 PM, wrote: > From: Marcus Cooper > > It has been seen that the newer SoCs have a different TX FIFO > address. Add this to the quirks structure. > > Signed-off-by: Marcus Cooper Reviewed-by: Chen-Yu Tsai
Re: [PATCH 1/2 v2] backlight: gpio: Convert to use GPIO descriptor
On Tue, May 30, 2017 at 1:48 PM, Linus Walleij wrote: > This driver is predominantly used by device tree systems, all > of which can deal with modern GPIO descriptors. The legacy > GPIO API is only used by one SH board so make the GPIO > descriptor the default way to deal with it. > > As an intended side effect we do not need to look around in > the device tree for the inversion flag since the GPIO > descriptors will intrinsically deal with this. > > Acked-by: Daniel Thompson > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Assign flags value using the ternary operator. This patch seems to have been inadvertedly dropped? Can it be applied, along with 2/2? Yours, Linus Walleij
Re: [PATCH 4.12 00/84] 4.12.3-stable review
On Sat, 2017-07-22 at 08:53 -0700, Kevin Hilman wrote: > > Boot Failures Detected: > > > > arm: > > > > multi_v7_defconfig > > imx6ul-pico-hobbit_rootfs:nfs: 1 failed lab > > > > tegra_defconfig > > tegra124-jetson-tk1_rootfs:nfs: 1 failed lab > > @Jan looks like a couple boards in your lab are having NFS issues > with stable kernels. Could you have a closer look? NFS was not configured correctly in our lab. We've fixed it and they now boot correctly via NFS. Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH] x86/hpet: Cure interface abuse in the resume path
On 01/08/17 10:43, Thomas Gleixner wrote:
On Tue, 1 Aug 2017, Tomi Sarvela wrote:
On 31/07/17 23:07, Thomas Gleixner wrote:
The HPET resume path abuses irq_domain_[de]activate_irq() to restore the
MSI message in the HPET chip for the boot CPU on resume and it relies on an
implementation detail of the interrupt core code, which magically makes the
HPET unmask call invoked via a irq_disable/enable pair. This worked as long
as the irq code did unconditionally invoke the unmask() callback. With the
recent changes which keep track of the masked state to avoid expensive
hardware access, this does not longer work. As a consequence the HPET timer
interrupts are not unmasked which breaks resume as the boot CPU waits
forever that a timer interrupt arrives.
Make the restore of the MSI message explicit and invoke the unmask()
function directly. While at it get rid of the pointless affinity setting as
nothing can change the affinity of the interrupt and the vector across
suspend/resume. The restore of the MSI message reestablishes the previous
affinity setting which is the correct one.
Fixes: bf22ff45bed6 ("genirq: Avoid unnecessary low level irq function
calls")
Reported-by: Martin Peres
Reported-by: Tomi Sarvela
Signed-off-by: Thomas Gleixner
Cc: jeffy.c...@rock-chips.com
Cc: Marc Zyngier
Cc: Peter Ziljstra
Cc: "Rafael J. Wysocki"
Tested-by: Tomi Sarvela
Tested only on the regressed Eagle Lake testhost. This patch fixes the
suspend/resume issue.
Tomi, can you please do me a favor?
Use plain 4.13-rc3 (without that patch) and add the following on the kernel
command line: 'nohpet'. Boot the machine and capture and provide the output
of
# dmesg
# cat /proc/interrupts
# cat /proc/timer_list
Then try the suspend cycle again.
Trying with Linus' tree, tag v4.13-rc3 with nohpet on cmdline.
Outputs below. The nohpet option works, as suspend-resumes complete.
Tomi
# cat /proc/interrupts
CPU0 CPU1
0: 2072 1799 IO-APIC 2-edge timer
1: 2 1 IO-APIC 1-edge i8042
4: 5 3 IO-APIC 4-edge ttyS0
8: 0 0 IO-APIC 8-edge rtc0
9: 0 0 IO-APIC 9-fasteoi acpi
12: 2 2 IO-APIC 12-edge i8042
16: 1 0 IO-APIC 16-fasteoi i915
17: 4 16 IO-APIC 17-fasteoi
20: 0 0 IO-APIC 20-fasteoi ehci_hcd:usb2,
uhci_hcd:usb3, uhci_hcd:usb6
21: 0 0 IO-APIC 21-fasteoi uhci_hcd:usb4,
uhci_hcd:usb7
22: 0 0 IO-APIC 22-fasteoi ehci_hcd:usb1,
uhci_hcd:usb5, uhci_hcd:usb8
24: 3952 4051 PCI-MSI 512000-edge ahci[:00:1f.2]
25: 7 7 PCI-MSI 49152-edge mei_me
26:683816 PCI-MSI 409600-edge enp0s25
27:220234 PCI-MSI 442368-edge snd_hda_intel:card0
NMI: 12 11 Non-maskable interrupts
LOC: 9738 9281 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 12 11 Performance monitoring interrupts
IWI: 1 0 IRQ work interrupts
RTR: 0 0 APIC ICR read retries
RES: 1186 1121 Rescheduling interrupts
CAL:496263 Function call interrupts
TLB: 52 22 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 1 1 Machine check polls
ERR: 0
MIS: 0
PIN: 0 0 Posted-interrupt notification event
NPI: 0 0 Nested posted-interrupt event
PIW: 0 0 Posted-interrupt wakeup event
# cat /proc/timer_list
Timer List Version: v0.8
HRTIMER_MAX_CLOCK_BASES: 4
now at 61527604423 nsecs
cpu: 0
clock 0:
.base: 88011bc134c0
.index: 0
.resolution: 1 nsecs
.get_time: ktime_get
.offset: 0 nsecs
active timers:
#0: , tick_sched_timer, S:01
# expires at 6153000-6153000 nsecs [in 2395577 to 2395577 nsecs]
#1: , hrtimer_wakeup, S:01
# expires at 61614083697-61614133697 nsecs [in 86479274 to 86529274 nsecs]
#2: , watchdog_timer_fn, S:01
# expires at 6410600-6410600 nsecs [in 2578395577 to
2578395577 nsecs]
#3: , hrtimer_wakeup, S:01
# expires at 65151373671-65151423671 nsecs [in 3623769248 to
3623819248 nsecs]
#4: , hrtimer_wakeup, S:01
# expires at 77091542299-77091592299 nsecs [in 15563937876 to
15563987876 nsecs]
#5: , hrtimer_wakeup, S:01
# expires at 77585999559-77586049559 nsecs [in 16058395136 to
16058445136 nsecs]
#6: , hrtimer_wakeup, S:01
# expires at 82453677713-82453727713 nsecs [in 20926073290 to
20926123290 nsecs]
#7: , hrtimer_wakeup, S:01
# expires at 82501069770-82501119770 nsecs [in 20973465347 to
20973515347 nsecs]
#8: , hrtimer_wakeup, S:01
#
[PATCH] usb: xhci: fix call_kern.cocci warnings
GFP_KERNEL used when a lock is held. Convert to GFP_ATOMIC to avoid
the possibility of deadlock.
Fixes: 725d53536473 ("usb: xhci: Add DbC support in xHCI driver")
Signed-off-by: Julia Lawall
Signed-off-by: Fengguang Wu
---
I don't have access to any more of the context than what is shown so I
don't know if this is a real bug.
You may want to see if it is instead possible to pull the call out of the
lock.
tree: baolu/usb/xhci/dbc/beta-v2
head: 671cb76fa0644a2f72a78fe6aac58c3c3347bc38
commit: 725d53536473cb05cdcf2b81a727ded8875a2a2f [3/4] usb: xhci: Add DbC
support in xHCI driver
xhci-dbgcap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-dbgcap.c
+++ b/drivers/usb/host/xhci-dbgcap.c
@@ -595,7 +595,7 @@ static int __xhci_dbc_start(struct xhci_
if (ret)
return ret;
- ret = xhci_dbc_mem_init(xhci, GFP_KERNEL);
+ ret = xhci_dbc_mem_init(xhci, GFP_ATOMIC);
if (ret)
return ret;
Re: linux-next: build failure in the staging tree (Was: kisskb: FAILED linux-next/s390-allmodconfig/s390x Mon Jul 31, 17:24)
On 07/31/2017 06:58 PM, Greg KH wrote: > On Mon, Jul 31, 2017 at 09:55:14AM +, Laurentiu Tudor wrote: >> Hi Stephen, >> >> That's because the fsl-mc driver selects GENERIC_MSI_IRQ_DOMAIN and not >> all arches implement the support for the option. I can submit a patch >> that adds explicit dependencies on arches that it was build-tested (x86, >> arm, powerpc, all both 32 and 64 bits) similar to how it's done here >> [1]. Let me know if you're ok with this fix and i'll submit the fix to >> staging. > > Ugh, you should not be selecting that option, but rather depending on > the option, right? All users in the kernel use "select", so i don't think so. An interesting use that adds explicit dependencies on architectures can be seen here [1], in the generic code. I've proposed a patch [2] that does a similar thing for mc-bus. I think it's a good approach as it keeps things under control by explicitly specifying the architectures on which the driver was compile-tested. --- Best Regards, Laurentiu [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/Kconfig#n28 [2] https://patchwork.kernel.org/patch/9871861/
Re: [RFC] KVM: optimize the kvm_vcpu_on_spin
On 01/08/2017 05:26, Longpeng (Mike) wrote: > > > On 2017/7/31 21:20, Paolo Bonzini wrote: > >> On 31/07/2017 14:27, David Hildenbrand wrote: I'm not sure whether the operation of get the vcpu's priority-level is expensive on all architectures, so I record it in kvm_sched_out() for minimal the extra cycles cost in kvm_vcpu_on_spin(). >>> as you only care for x86 right now either way, you can directly optimize >>> here for the good (here: x86) case (keeping changes and therefore >>> possible bugs minimal). >> >> I agree with Cornelia that this is inconsistent, so you shouldn't update >> me->in_kernmode in kvm_vcpu_on_spin. However, get_cpl requires >> vcpu_load on Intel x86, so Mike's patch is necessary (vmx_get_cpl -> >> vmx_read_guest_seg_ar -> vmcs_read32). >> > > Hi Paolo, > > It seems that other architectures(e.g. arm/s390) needn't to cache the result, > but x86 need, so I need to move 'in_kernmode' into kvm_vcpu_arch and only add > this field to x86, right? That's another way to do it, and I like it. >> This will cache the result until the next sched_in, so that > > 'until the next sched_in' --> Do we need to clear the result in sched in ? No, thanks. Paolo
Re: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception
Hi Takahiro, On Tuesday 01 August 2017 01:44 PM, AKASHI Takahiro wrote: Hi Pratyush, On Mon, Jul 31, 2017 at 04:10:28PM +0530, Pratyush Anand wrote: v2 -> v3 - Moved step_needed from uapi structure to kernel only structure - Re-enable interrupt if stepped instruction faults - Modified register_wide_hw_breakpoint() to accept step_needed arg v2 was here: http://marc.info/?l=linux-arm-kernel&m=149942910730496&w=2 v1 -> v2: - patch 1 of v1 has been modified to patch 1-3 of v2. - Introduced a new event attribute step_needed and implemented hw_breakpoint_needs_single_step() (patch 1) - Replaced usage of is_default_overflow_handler() with hw_breakpoint_needs_single_step(). (patch 2) - Modified sample test to set set step_needed bit field (patch 3) v1 was here: http://marc.info/?l=linux-arm-kernel&m=149910958418708&w=2 samples/hw_breakpoint/data_breakpoint.c passes with x86_64 but fails with ARM64. Even though it has been NAKed previously on upstream [1, 2], I have tried to come up with patches which can resolve it for ARM64 as well. I noticed that even perf step exception can go into an infinite loop if CPU receives an interrupt while executing breakpoint/watchpoint handler. So, event though we are not concerned about above test, we will have to find a solution for the perf issue. This patchset attempts to resolve both the issue. Please review. Since, it also takes care of SW breakpoint, so I hope kgdb should also be fine. However, I have not tested that. @Takahiro: Will it be possible to test these patches for kgdb. I have not yet understood the details of your patch, but I gave it a try and didn't see any difference around the behavior of kgdb's single stepping. I also gave a try to James' patch, but again nothing different as long as kgdb is concerned. (I'm tackling some issue in single stepping at irq's kernel_exit, in particular, 'eret'.) You mean that you were expecting an step exception after eret (and this eret was being called from kgdb breakpoint exception handler), but you got irq exception? This is what I understood from your previous patch [0]. If that was the case, then I was expecting that this patch series should help. See, patch 4/5: - kgdb breakpoint handler kgdb_brk_fn() will be called from arch/arm64/kernel/debug-monitors.c: brk_handler(). - If we are expecting a step exception after servicing this breakpoint handler, then kgdb code would have called kernel_enable_single_step(). So, we should see kernel_active_single_step() true in brk_handler(). - If above happens then do_debug_exception() will make sure that PSR I bit is set before eret is called and we should not see an IRQ exception after eret. Can you please help me with your reproducer test case? [0] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/508066.html -- Regards Pratyush
Re: [linux-sunxi] [PATCH v3 05/12] ASoC: sun4i-i2s: Add regmap fields for channels
On Sat, Jul 29, 2017 at 10:17 PM, wrote:
> From: Marcus Cooper
>
> On the original i2s block the channel mapping and selection were
> configured for stereo audio by default: This is not the case with
> the newer SoCs and they are also located at different offsets.
>
> To support the newer SoC then regmap fields have been added to the
> quirks and these are initialised to their correct settings during
> probing.
>
> Signed-off-by: Marcus Cooper
> ---
> sound/soc/sunxi/sun4i-i2s.c | 80
> -
> 1 file changed, 72 insertions(+), 8 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index 2a25df22c2f8..120f797a38e8 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -82,7 +82,7 @@
> #define SUN4I_I2S_TX_CNT_REG 0x2c
>
> #define SUN4I_I2S_TX_CHAN_SEL_REG 0x30
> -#define SUN4I_I2S_TX_CHAN_SEL(num_chan)(((num_chan) - 1) <<
> 0)
> +#define SUN4I_I2S_CHAN_SEL(num_chan) (((num_chan) - 1) << 0)
>
> #define SUN4I_I2S_TX_CHAN_MAP_REG 0x34
> #define SUN4I_I2S_TX_CHAN_MAP(chan, sample)((sample) << (chan << 2))
> @@ -98,6 +98,10 @@
> * @sun4i_i2s_regmap: regmap config to use.
> * @mclk_offset: Value by which mclkdiv needs to be adjusted.
> * @bclk_offset: Value by which bclkdiv needs to be adjusted.
> + * @field_txchanmap: location of the tx channel mapping register.
> + * @field_rxchanmap: location of the rx channel mapping register.
> + * @field_txchansel: location of the tx channel select bit fields.
> + * @field_rxchansel: location of the rx channel select bit fields.
> */
> struct sun4i_i2s_quirks {
> boolhas_reset;
> @@ -105,6 +109,12 @@ struct sun4i_i2s_quirks {
> const struct regmap_config *sun4i_i2s_regmap;
> unsigned intmclk_offset;
> unsigned intbclk_offset;
> +
> + /* Register fields for i2s */
> + struct reg_fieldfield_txchanmap;
> + struct reg_fieldfield_rxchanmap;
> + struct reg_fieldfield_txchansel;
> + struct reg_fieldfield_rxchansel;
> };
>
> struct sun4i_i2s {
> @@ -118,6 +128,12 @@ struct sun4i_i2s {
> struct snd_dmaengine_dai_dma_data capture_dma_data;
> struct snd_dmaengine_dai_dma_data playback_dma_data;
>
> + /* Register fields for i2s */
> + struct regmap_field *field_txchanmap;
> + struct regmap_field *field_rxchanmap;
> + struct regmap_field *field_txchansel;
> + struct regmap_field *field_rxchansel;
> +
> const struct sun4i_i2s_quirks *variant;
> };
>
> @@ -264,6 +280,18 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> *substream,
> if (params_channels(params) != 2)
> return -EINVAL;
>
> + /* Map the channels for playback and capture */
> + regmap_field_write(i2s->field_txchanmap, 0x76543210);
> + regmap_field_write(i2s->field_rxchanmap, 0x3210);
> +
> + /* Configure the channels */
> + regmap_field_write(i2s->field_txchansel,
> + SUN4I_I2S_CHAN_SEL(params_channels(params)));
> +
> + regmap_field_write(i2s->field_rxchansel,
> + SUN4I_I2S_CHAN_SEL(params_channels(params)));
> +
> +
Checkpatch says don't use multiple blank lines.
> switch (params_physical_width(params)) {
> case 16:
> width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> @@ -486,13 +514,6 @@ static int sun4i_i2s_startup(struct snd_pcm_substream
> *substream,
>SUN4I_I2S_CTRL_SDO_EN_MASK,
>SUN4I_I2S_CTRL_SDO_EN(0));
>
> - /* Enable the first two channels */
> - regmap_write(i2s->regmap, SUN4I_I2S_TX_CHAN_SEL_REG,
> -SUN4I_I2S_TX_CHAN_SEL(2));
> -
> - /* Map them to the two first samples coming in */
> - regmap_write(i2s->regmap, SUN4I_I2S_TX_CHAN_MAP_REG,
> -SUN4I_I2S_TX_CHAN_MAP(0, 0) | SUN4I_I2S_TX_CHAN_MAP(1,
> 1));
>
> return clk_prepare_enable(i2s->mod_clk);
> }
> @@ -677,14 +698,51 @@ static const struct sun4i_i2s_quirks
> sun4i_a10_i2s_quirks = {
> .has_reset = false,
> .reg_offset_txdata = SUN4I_I2S_FIFO_TX_REG,
> .sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
> + .field_txchanmap= REG_FIELD(SUN4I_I2S_TX_CHAN_MAP_REG, 0, 31),
> + .field_rxchanmap= REG_FIELD(SUN4I_I2S_RX_CHAN_MAP_REG, 0, 31),
> + .field_txchansel= REG_FIELD(SUN4I_I2S_TX_CHAN_SEL_REG, 0, 2),
> + .field_rxchansel= REG_FIELD(SUN4I_I2S_RX_CHAN_SEL_REG, 0, 2),
> };
>
> static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
> .has_reset = true,
> .reg_offset_txdata = SUN4I_I2S_FIFO_TX_REG,
Re: [PATCH v2] [BUGFIX] gpio: reject invalid gpio before getting gpio_desc
On Tue, 1 Aug 2017 10:09:09 +0200
Linus Walleij wrote:
> On Mon, Jul 31, 2017 at 3:57 AM, Masami Hiramatsu wrote:
>
> > Check user-given gpio number and reject it before
> > calling gpio_to_desc() because gpio_to_desc() is
> > for kernel driver and it expects given gpio number
> > is valid (means 0 to 511).
> > If given number is invalid, gpio_to_desc() calls
> > WARN() and dump registers and stack for debug.
> > This means user can easily kick WARN() just by
> > writing invalid gpio number (e.g. 512) to
> > /sys/class/gpio/export.
> >
> > Fixes: 0e9a5edf5d01 ("gpio: fix deferred probe detection for legacy API")
> > Signed-off-by: Masami Hiramatsu
> > ---
> > Changes in v2:
> >- Add gpio_to_valid_desc() according to Andy's comment (Thanks!).
> >- Fix patch description.
>
> I hate the old sysfs ABI sigh. Thanks for fixing it anyways!
>
> Should this be tagged for stable?
Yes, I think so. Since this has been introduced 3 years ago,
it would be nice to go to older stable trees too.
Thanks,
>
> Waiting for Andy's review before applying.
>
> Yours,
> Linus Walleij
--
Masami Hiramatsu
Re: [PATCH 1/2] gpio: gpio-mxc: Fix: higher 16 GPIOs usable as wake source
On Wed, Jul 12, 2017 at 10:36 AM, Philipp Rosenberger wrote: > In the function gpio_set_wake_irq(), port->irq_high is only checked for > zero. As platform_get_irq() returns a value less then zero if no interrupt > was found, any gpio >= 16 was handled like an irq_high interrupt was > available. On iMX27 for example no high interrupt is available. This lead > to the problem that only some gpios (the lower 16) were useable as wake > sources. > > Signed-off-by: Philipp Rosenberger That looks like a clear bug, patch applied for fixes. Yours, Linus Walleij
Re: [PATCH] sched: fix NULL pointer issue in pick_next_entity()
On Tue, Aug 01, 2017 at 06:01:56PM +0800, Yafang Shao wrote: > When we select CFQ as the scheduler, in function pick_next_task_fair CFS, CFQ is a block IO scheduler. > it will pass NULL as the 2nd argument to pick_next_entity: > pick_next_entity(cfs_rq, NULL); > > And once __pick_first_entity() is called, it could return NULL as well. > > So in function pick_next_entity(), the local variable 'left' and 'curr' > could both be NULL, then this will cause NULL pointer issue. > > In order to fix this issue, we just need return NULL under the condition > that both 'left' and 'curr' are NULL, meaning that no entity available. And how would that happen? We only call pick_next_entity(.curr=NULL) when we _know_ cfs_rq->nr_running. > Signed-off-by: Yafang Shao > --- > kernel/sched/fair.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index c95880e..e64c359 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -3903,6 +3903,8 @@ static void clear_buddies(struct cfs_rq *cfs_rq, struct > sched_entity *se) You diff is broken, this is very much not the clear_buddies() function. > struct sched_entity *left = __pick_first_entity(cfs_rq); > struct sched_entity *se; > > + if (!left && !curr) > + return NULL; > /* >* If curr is set we have to see if its left of the leftmost entity >* still in the tree, provided there was anything in the tree at all. > -- > 1.8.3.1 >
Re: [PATCH 2/2] gpio: gpio-mxc: gpio_set_wake_irq() use proper return values
On Wed, Jul 12, 2017 at 10:36 AM, Philipp Rosenberger wrote: > Errors from enable_irq_wake() in gpio_set_wake_irq() were silently ignored. > Thus led to the problem that gpio_set_wake_irq() always returned > successfully, even if enable_irq_wake() returned an error. > > Signed-off-by: Philipp Rosenberger Patch applied. Yours, Linus Walleij
[PATCH V5 0/2] timer: add imx tpm timer support
The Timer/PWM Module (TPM) supports input capture, output compare, and the generation of PWM signals to control electric motor and power management applications. The counter, compare and capture registers are clocked by an asynchronous clock that can remain enabled in low power modes. TPM can support global counter bus where one TPM drives the counter bus for the others, provided bit width is the same. This patch only adds the timer support. PWM would be added later. ChangeLog: v4->v5: * use request_irq instead of setup_irq * switch to TIMER_OF_DECLARE from CLOCKSOURCE_OF_DECLARE * add more error check * patch title change to clocksource/drivers/imx-tpm: add imx tpm timer support v3->v4: * also add ETIME explanation in function v2->v3: * address a few minor comments from Daniel Lezcano * add more explaination on ETIME check in commit message v1->v2: * change to readl/writel from __raw_readl/writel according to Arnd's suggestion to avoid endian issue * add help information in Kconfig * add more error checking Dong Aisheng (2): dt-bindings: timer: add nxp tpm timer binding doc clocksource/drivers/imx-tpm: add imx tpm timer support .../devicetree/bindings/timer/nxp,tpm-timer.txt| 28 +++ drivers/clocksource/Kconfig| 8 + drivers/clocksource/Makefile | 1 + drivers/clocksource/timer-imx-tpm.c| 239 + 4 files changed, 276 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt create mode 100644 drivers/clocksource/timer-imx-tpm.c -- 2.7.4
[PATCH V5 1/2] dt-bindings: timer: add nxp tpm timer binding doc
Adding NXP Low Power Timer/Pulse Width Modulation Module (TPM)
binding doc.
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Cc: Daniel Lezcano
Cc: Thomas Gleixner
Cc: Shawn Guo
Cc: Bai Ping
Acked-by: Rob Herring
Signed-off-by: Dong Aisheng
---
ChangeLog:
v1->v5:
* No changes
---
.../devicetree/bindings/timer/nxp,tpm-timer.txt| 28 ++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
new file mode 100644
index 000..b4aa7dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
@@ -0,0 +1,28 @@
+NXP Low Power Timer/Pulse Width Modulation Module (TPM)
+
+The Timer/PWM Module (TPM) supports input capture, output compare,
+and the generation of PWM signals to control electric motor and power
+management applications. The counter, compare and capture registers
+are clocked by an asynchronous clock that can remain enabled in low
+power modes. TPM can support global counter bus where one TPM drives
+the counter bus for the others, provided bit width is the same.
+
+Required properties:
+
+- compatible : should be "fsl,imx7ulp-tpm"
+- reg :Specifies base physical address and size of the
register sets
+ for the clock event device and clock source device.
+- interrupts : Should be the clock event device interrupt.
+- clocks : The clocks provided by the SoC to drive the timer, must contain
+ an entry for each entry in clock-names.
+- clock-names : Must include the following entries: "igp" and "per".
+
+Example:
+tpm5: tpm@4026 {
+ compatible = "fsl,imx7ulp-tpm";
+ reg = <0x4026 0x1000>;
+ interrupts = ;
+ clocks = <&clks IMX7ULP_CLK_NIC1_BUS_DIV>,
+<&clks IMX7ULP_CLK_LPTPM5>;
+ clock-names = "ipg", "per";
+};
--
2.7.4
[PATCH V5 2/2] clocksource/drivers/imx-tpm: add imx tpm timer support
IMX Timer/PWM Module (TPM) supports both timer and pwm function while
this patch only adds the timer support. PWM would be added later.
The TPM counter, compare and capture registers are clocked by an
asynchronous clock that can remain enabled in low power modes.
NOTE: We observed in a very small probability, the bus fabric
contention between GPU and A7 may results a few cycles delay
of writing CNT registers which may cause the min_delta event got
missed, so we need add a ETIME check here in case it happened.
Cc: Daniel Lezcano
Cc: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Shawn Guo
Cc: Anson Huang
Cc: Bai Ping
Signed-off-by: Dong Aisheng
---
ChangeLog:
v4->v5:
* use request_irq instead of setup_irq
* switch to TIMER_OF_DECLARE from CLOCKSOURCE_OF_DECLARE
* add more error check
* patch title change to clocksource/drivers/imx-tpm: add imx tpm timer support
v3->v4:
* also add ETIME explanation in function
v2->v3:
* address all comments from Daniel Lezcano
* add more explaination on ETIME check in commit message
v1->v2:
* change to readl/writel from __raw_readl/writel according to Arnd's
suggestion to avoid endian issue
* add help information in Kconfig
* add more error checking
---
drivers/clocksource/Kconfig | 8 ++
drivers/clocksource/Makefile| 1 +
drivers/clocksource/timer-imx-tpm.c | 239
3 files changed, 248 insertions(+)
create mode 100644 drivers/clocksource/timer-imx-tpm.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 88818a4..a4a1ff3 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -591,6 +591,14 @@ config CLKSRC_IMX_GPT
depends on ARM && CLKDEV_LOOKUP
select CLKSRC_MMIO
+config CLKSRC_IMX_TPM
+ bool "Clocksource using i.MX TPM" if COMPILE_TEST
+ depends on ARM && CLKDEV_LOOKUP && GENERIC_CLOCKEVENTS
+ select CLKSRC_MMIO
+ help
+ Enable this option to use IMX Timer/PWM Module (TPM) timer as
+ clocksource.
+
config CLKSRC_ST_LPC
bool "Low power clocksource found in the LPC" if COMPILE_TEST
select TIMER_OF if OF
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 72bfd00..1631a84 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_CLKSRC_VERSATILE)+= versatile.o
obj-$(CONFIG_CLKSRC_MIPS_GIC) += mips-gic-timer.o
obj-$(CONFIG_CLKSRC_TANGO_XTAL)+= tango_xtal.o
obj-$(CONFIG_CLKSRC_IMX_GPT) += timer-imx-gpt.o
+obj-$(CONFIG_CLKSRC_IMX_TPM) += timer-imx-tpm.o
obj-$(CONFIG_ASM9260_TIMER)+= asm9260_timer.o
obj-$(CONFIG_H8300_TMR8) += h8300_timer8.o
obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
diff --git a/drivers/clocksource/timer-imx-tpm.c
b/drivers/clocksource/timer-imx-tpm.c
new file mode 100644
index 000..21bffdc
--- /dev/null
+++ b/drivers/clocksource/timer-imx-tpm.c
@@ -0,0 +1,239 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TPM_SC 0x10
+#define TPM_SC_CMOD_INC_PER_CNT(0x1 << 3)
+#define TPM_SC_CMOD_DIV_DEFAULT0x3
+#define TPM_CNT0x14
+#define TPM_MOD0x18
+#define TPM_STATUS 0x1c
+#define TPM_STATUS_CH0FBIT(0)
+#define TPM_C0SC 0x20
+#define TPM_C0SC_CHIE BIT(6)
+#define TPM_C0SC_MODE_SHIFT2
+#define TPM_C0SC_MODE_MASK 0x3c
+#define TPM_C0SC_MODE_SW_COMPARE 0x4
+#define TPM_C0V0x24
+
+static void __iomem *timer_base;
+static struct clock_event_device clockevent_tpm;
+
+static inline void tpm_timer_disable(void)
+{
+ unsigned int val;
+
+ /* channel disable */
+ val = readl(timer_base + TPM_C0SC);
+ val &= ~(TPM_C0SC_MODE_MASK | TPM_C0SC_CHIE);
+ writel(val, timer_base + TPM_C0SC);
+}
+
+static inline void tpm_timer_enable(void)
+{
+ unsigned int val;
+
+ /* channel enabled in sw compare mode */
+ val = readl(timer_base + TPM_C0SC);
+ val |= (TPM_C0SC_MODE_SW_COMPARE << TPM_C0SC_MODE_SHIFT) |
+ TPM_C0SC_CHIE;
+ writel(val, timer_base + TPM_C0SC);
+}
+
+static inline void tpm_irq_acknowledge(void)
+{
+ writel(TPM_STATUS_CH0F, timer_base + TPM_STATUS);
+}
+
+static struct delay_timer tpm_delay_timer;
+
+static inline unsigned long tpm_read_counter(void)
+{
+ return read
Re: [alsa-devel] [PATCH v2 2/2] drm/bridge: adv7511: restrict audio sample sizes
Hello Srinivas,
On 08/01/2017 12:49 AM, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla
>
> ADV7533 only supports audio samples word width from 16-24 bits.
> This patch restricts the audio sample sizes to the supported ones,
> so that sound card does not report wrong list of supported hwparms.
>
> Without this patch aplay would fail when playing a 32 bit audio.
>
> Signed-off-by: Srinivas Kandagatla
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> index 67469c26bae8..d01d0aa0eef7 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> @@ -214,6 +214,8 @@ static struct hdmi_codec_pdata codec_data = {
> .ops = &adv7511_codec_ops,
> .max_i2s_channels = 2,
> .i2s = 1,
> + .formats = (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |
> + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE),
> };
I'm not sure that this limitation is needed.
I already used ADV7513 and i did not observe this limitation.
I had a look to ADV7533 data-sheet. it should support 32 and 64 bits I2S
format bus, with 16 or 24 bits precision sample. So it should support
SNDRV_PCM_FMTBIT_S32_LE and SNDRV_PCM_FMTBIT_S32_BE
As example, if you configure bus in Left justified format with 24 bits
sample length, 32 bits application samples should be truncated to 24
bits samples at ADV7533 I2S interface level (LSB dropped).
Perhaps i missed something... but look like more an I2S bus
configuration issue in your DT card description, that that a miss in the
drivers.
Regards
Arnaud
>
> int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511)
>
Re: [PATCH 0/3] PINCTRL: Mediatek pinctrl driver for mt2712
On Mon, 2017-07-31 at 16:22 +0800, Zhiyong Tao wrote: > This series includes three patches: > 1.Add mt2712 compatible node in binding document. > 2.Add mt2712 pinctrl device node. > 3.Add mt2712 pinctrl driver. > > Zhiyong Tao (3): > dt-bindings: pinctrl: mt2712: add binding document > arm64: dts: mt2712: add pintcrl device node. > pinctrl: add mt2712 pinctrl driver > > .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |1 + > arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1014 +++ > arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 18 + mt2712e.dtsi doesn't exists in v4.13-rc1. What's the base for this series? Joe.C
Re: [linux-sunxi] [PATCH v3 06/12] ASoC: sun4i-i2s: Add changes for wss and sr
On Sat, Jul 29, 2017 at 10:17 PM, wrote: > From: Marcus Cooper > > On newer SoCs the location of the slot width select and sample > resolution are different and also there is a bigger range of > support. There is enough space to not use acronyms in the commit subject line. ASoC: sun4i-i2s: Add regfields for word size select and sample resolution would be much clearer. > > For the current supported rates then an offset is required. > > Signed-off-by: Marcus Cooper Otherwise, Reviewed-by: Chen-Yu Tsai
Re: [PATCH v2 02/22] fpga: add FPGA device framework
On Mon, Jul 31, 2017 at 04:40:16PM -0500, Alan Tull wrote: > On Thu, Jul 27, 2017 at 2:10 PM, Rob Herring wrote: > > On Thu, Jul 27, 2017 at 11:35 AM, Alan Tull wrote: > >> On Sun, Jun 25, 2017 at 8:51 PM, Wu Hao wrote: > >> > >> Hi Rob, > >> > >> I was hoping to pick your brain a bit on a DT question. > >> > >>> During FPGA device (e.g PCI-based) discovery, platform devices are > >>> registered for different FPGA function units. But the device node path > >>> isn't quite friendly to applications. > >>> > >>> Consider this case, applications want to access child device's sysfs file > >>> for some information. > >>> > >>> 1) Access using bus-based path (e.g PCI) > >>> > >>> /sys/bus/pci/devices/x/fpga_func_a.0/sysfs_file > >>> > >>> From the path, it's clear which PCI device is the parent, but not > >>> perfect > >>> solution for applications. PCI device BDF is not fixed, application may > >>> need to search all PCI device to find the actual FPGA Device. > >>> > >>> 2) Or access using platform device path > >>> > >>> /sys/bus/platform/devices/fpga_func_a.0/sysfs_file > >>> > >>> Applications find the actual function by name easily, but no information > >>> about which fpga device it belongs to. It's quite confusing if multiple > >>> FPGA devices are in one system. > >> > >> There's a proposal for adding sysfs nodes that correspond to each FPGA > >> device., with the devices located on each FPGA under them. It makes > >> it easier to see which device is on which FPGA. > > > > Makes sense. > > > >>> 'FPGA Device' class is introduced to resolve this problem. Each node under > >>> this class represents a fpga device, which may have one or more child > >>> devices. Applications only need to search under this FPGA Device class > >>> folder to find the child device node it needs. > >>> > >>> For example, for the platform has 2 fpga devices, each fpga device has > >>> 3 child devices, the hierarchy looks like this. > >>> > >>> Two nodes are under /sys/class/fpga/: > >>> /sys/class/fpga/fpga.0 > >>> /sys/class/fpga/fpga.1 > >>> > >>> Each node has 1 function A device and 2 function B devices: > >>> /sys/class/fpga/fpga.0/func_a.0 > >>> /sys/class/fpga/fpga.0/func_b.0 > >>> /sys/class/fpga/fpga.0/func_b.1 > >>> > >>> /sys/class/fpga/fpga.1/func_a.1 > >>> /sys/class/fpga/fpga.1/func_b.2 > >>> /sys/class/fpga/fpga.1/func_b.3 > > > > A class is generally what is the function of the device, not how it is > > attached. Seems like what you want here is a new bus type if the > > existing PCI and platform bus types don't work. > > > >> > >> I can see the value of having sysfs nodes that correspond to fpga > >> devices and being able to find devices under them. I'm thinking what > >> that would mean for Device Tree when fpga-dev is used on DT enabled > >> systems. In Device Tree, what is a fpga-dev? > > > > Just properly setting the parent struct device on the functions should > > be enough to figure out which function is in which fpga. I don't see > > why a new class is needed. > > > >> Currently the DT would have a FPGA bridge corresponding to each FPGA's > >> hardware bridge and a heirarchy of bridges, regions and devices under > >> it. On systems that don't support partial reconfiguration under the > >> OS (so not main bridge that was controlled by the OS), there would be > >> a FPGA region, then its child regions, bridges, and devices. > > > > The FPGA bridges could instantiate fpga bus type devices instead of > > platform devices. > > Yes > > Some FPGA use cases already have a base bridge per FPGA that could > serve as this bus. But this use case has a static FPGA image + > reprogrammable child fpga regions. There's no base bridge under Linux > since the FPGA was programmed and the bridge enabled before Linux > boots. An added base bridge that doesn't touch hardware will be > required for this type of use. Hi Alan Does 'base bridge' mentioned above mean a hardware bridge just like PCIe or USB? I tried to use fpga bus type device instead of fpga-dev class today, it works for me, e.g Intel FPGA device PCIe driver could create a fpga bus type dev as a child of PCIe device and its sysfs path will be changed to /sys/bus/fpga/devices/fpga.x/ from /sys/class/fpga/fpga.x/. For now, this fpga bus type device is only used as container device, so no driver needed for it. Do you have any concern on this? I see fpga bus type works fine, but I didn't see other advantages for this case, as we only use it as a container device to represent a FPGA device in sysfs hierarchy. :) Thanks Hao > > > That's really up to Linux and outside the scope of > > the bindings. > > Thanks for the feedback. > > Alan Tull > > > > > Rob
Re: [PATCH v5 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile
On Fri, 2017-07-28 at 19:37 +0800, YT Shen wrote:
> diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> new file mode 100644
> index 000..1e135af
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
<...>
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupt-parent = <&gic>;
> + interrupts = + (GIC_CPU_MASK_RAW(0x13) | IRQ_TYPE_LEVEL_LOW)>,
> + + (GIC_CPU_MASK_RAW(0x13) | IRQ_TYPE_LEVEL_LOW)>,
> + + (GIC_CPU_MASK_RAW(0x13) | IRQ_TYPE_LEVEL_LOW)>,
> + + (GIC_CPU_MASK_RAW(0x13) | IRQ_TYPE_LEVEL_LOW)>;
> + };
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "simple-bus";
> + ranges;
Matthias,
I notice this have soc node.
Do we need to get rid of it?
Joe.C
Re: [PATCH 2/4] mailbox: pcc: Drop uninformative output during boot
"Rafael J. Wysocki" writes: > On 7/31/2017 7:47 PM, Alexey Klimov wrote: >> (keeping Rafael in c/c per Jassi suggestion) >> >> On Thu, Jul 20, 2017 at 12:04 PM, Punit Agrawal >> wrote: >>> When booting on an ACPI enabled system that does not provide the >>> Platform Communications Channel Table (PCCT), the pcc mailbox driver >>> prints - >>> >>> [0.484261] PCCT header not found. >> Ah. I thought this was already removed ages ago. Thanks for removing this. >> >>> during probe before returning -ENODEV. >>> >>> This message clutters the bootlog and doesn't provide any useful >>> information. Drop this message. >>> >>> Signed-off-by: Punit Agrawal >>> Cc: Jassi Brar >> Acked-by: Alexey Klimov >> > Please resend this, including all applicable tags, with a CC to > linux-a...@vger.kernel.org for easier processing. Thanks Jassi for adding the appropriate folks on this patch. get_maintainer.pl threw me off on this one. ;) I'll add the tags (Thanks, Alexey) and re-send. > > Thanks, > > Rafael
Re: [PATCH 1/3] mm:hugetlb: Define system call hugetlb size encodings in single file
On Mon 31-07-17 11:56:24, Mike Kravetz wrote: > If hugetlb pages are requested in mmap or shmget system calls, a huge > page size other than default can be requested. This is accomplished by > encoding the log2 of the huge page size in the upper bits of the flag > argument. asm-generic and arch specific headers all define the same > values for these encodings. > > Put common definitions in a single header file. The primary uapi > header files for mmap and shm will use these definitions as a basis > for definitions specific to those system calls. > > Signed-off-by: Mike Kravetz Acked-by: Michal Hocko > --- > include/uapi/asm-generic/hugetlb_encode.h | 34 > +++ > 1 file changed, 34 insertions(+) > create mode 100644 include/uapi/asm-generic/hugetlb_encode.h > > diff --git a/include/uapi/asm-generic/hugetlb_encode.h > b/include/uapi/asm-generic/hugetlb_encode.h > new file mode 100644 > index 000..e4732d3 > --- /dev/null > +++ b/include/uapi/asm-generic/hugetlb_encode.h > @@ -0,0 +1,34 @@ > +#ifndef _ASM_GENERIC_HUGETLB_ENCODE_H_ > +#define _ASM_GENERIC_HUGETLB_ENCODE_H_ > + > +/* > + * Several system calls take a flag to request "hugetlb" huge pages. > + * Without further specification, these system calls will use the > + * system's default huge page size. If a system supports multiple > + * huge page sizes, the desired huge page size can be specified in > + * bits [26:31] of the flag arguments. The value in these 6 bits > + * will encode the log2 of the huge page size. > + * > + * The following definitions are associated with this huge page size > + * encoding in flag arguments. System call specific header files > + * that use this encoding should include this file. They can then > + * provide definitions based on these with their own specific prefix. > + * for example: > + * #define MAP_HUGE_SHIFT HUGETLB_FLAG_ENCODE_SHIFT > + */ > + > +#define HUGETLB_FLAG_ENCODE_SHIFT26 > +#define HUGETLB_FLAG_ENCODE_MASK 0x3f > + > +#define HUGETLB_FLAG_ENCODE_64KB (16 << HUGETLB_FLAG_ENCODE_SHIFT) > +#define HUGETLB_FLAG_ENCODE_512KB(19 << HUGETLB_FLAG_ENCODE_SHIFT) > +#define HUGETLB_FLAG_ENCODE_1MB (20 << > HUGETLB_FLAG_ENCODE_SHIFT) > +#define HUGETLB_FLAG_ENCODE_2MB (21 << > HUGETLB_FLAG_ENCODE_SHIFT) > +#define HUGETLB_FLAG_ENCODE_8MB (23 << > HUGETLB_FLAG_ENCODE_SHIFT) > +#define HUGETLB_FLAG_ENCODE_16MB (24 << HUGETLB_FLAG_ENCODE_SHIFT) > +#define HUGETLB_FLAG_ENCODE_256MB(28 << HUGETLB_FLAG_ENCODE_SHIFT) > +#define HUGETLB_FLAG_ENCODE_1GB (30 << > HUGETLB_FLAG_ENCODE_SHIFT) > +#define HUGETLB_FLAG_ENCODE_2GB (31 << > HUGETLB_FLAG_ENCODE_SHIFT) > +#define HUGETLB_FLAG_ENCODE_16GB (34 << HUGETLB_FLAG_ENCODE_SHIFT) > + > +#endif /* _ASM_GENERIC_HUGETLB_ENCODE_H_ */ > -- > 2.7.5 -- Michal Hocko SUSE Labs
Re: [PATCH] sched: fix NULL pointer issue in pick_next_entity()
Hi Peter, Thanks for your response! > CFS, CFQ is a block IO scheduler. Sorry for the mistake. It should be CFS. > And how would that happen? We only call pick_next_entity(.curr=NULL) > when we _know_ cfs_rq->nr_running. It crashed my machine when I did hadoop test, and after I made this change it works now. On SMP system, cfs_rq->nr_running isn't protected well, although we _know_ cfs_rq->nr_running, but it is modified by other thread running on other CPU and the sched_entity is set NULL as well. Then this thread broken here as accessed the NULL pointer here. > You diff is broken, this is very much not the clear_buddies() function. You're right. it is in pick_next_entity(). 2017-08-01 16:38 GMT+08:00 Peter Zijlstra : > On Tue, Aug 01, 2017 at 06:01:56PM +0800, Yafang Shao wrote: >> When we select CFQ as the scheduler, in function pick_next_task_fair > > CFS, CFQ is a block IO scheduler. > >> it will pass NULL as the 2nd argument to pick_next_entity: >> pick_next_entity(cfs_rq, NULL); >> >> And once __pick_first_entity() is called, it could return NULL as well. >> >> So in function pick_next_entity(), the local variable 'left' and 'curr' >> could both be NULL, then this will cause NULL pointer issue. >> >> In order to fix this issue, we just need return NULL under the condition >> that both 'left' and 'curr' are NULL, meaning that no entity available. > > And how would that happen? We only call pick_next_entity(.curr=NULL) > when we _know_ cfs_rq->nr_running. > >> Signed-off-by: Yafang Shao >> --- >> kernel/sched/fair.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index c95880e..e64c359 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -3903,6 +3903,8 @@ static void clear_buddies(struct cfs_rq *cfs_rq, >> struct sched_entity *se) > > You diff is broken, this is very much not the clear_buddies() function. > >> struct sched_entity *left = __pick_first_entity(cfs_rq); >> struct sched_entity *se; >> >> + if (!left && !curr) >> + return NULL; >> /* >>* If curr is set we have to see if its left of the leftmost entity >>* still in the tree, provided there was anything in the tree at all. >> -- >> 1.8.3.1 >>
Re: [PATCH 2/3] mm: arch: Consolidate mmap hugetlb size encodings
On Mon 31-07-17 11:56:25, Mike Kravetz wrote: > A non-default huge page size can be encoded in the flags argument > of the mmap system call. The definitions for these encodings are > in arch specific header files. However, all architectures use the > same values. > > Consolidate all the definitions in the primary user header file > (uapi/linux/mman.h). Include definitions for all known huge page > sizes. Use the generic encoding definitions in hugetlb_encode.h > as the basis for these definitions. > > Signed-off-by: Mike Kravetz Acked-by: Michal Hocko > --- > arch/alpha/include/uapi/asm/mman.h | 11 --- > arch/mips/include/uapi/asm/mman.h | 11 --- > arch/parisc/include/uapi/asm/mman.h| 11 --- > arch/powerpc/include/uapi/asm/mman.h | 16 > arch/x86/include/uapi/asm/mman.h | 3 --- > arch/xtensa/include/uapi/asm/mman.h| 11 --- > include/uapi/asm-generic/mman-common.h | 11 --- > include/uapi/linux/mman.h | 22 ++ > 8 files changed, 22 insertions(+), 74 deletions(-) > > diff --git a/arch/alpha/include/uapi/asm/mman.h > b/arch/alpha/include/uapi/asm/mman.h > index 02760f6..13b52aa 100644 > --- a/arch/alpha/include/uapi/asm/mman.h > +++ b/arch/alpha/include/uapi/asm/mman.h > @@ -67,17 +67,6 @@ > /* compatibility flags */ > #define MAP_FILE 0 > > -/* > - * When MAP_HUGETLB is set bits [26:31] encode the log2 of the huge page > size. > - * This gives us 6 bits, which is enough until someone invents 128 bit > address > - * spaces. > - * > - * Assume these are all power of twos. > - * When 0 use the default page size. > - */ > -#define MAP_HUGE_SHIFT 26 > -#define MAP_HUGE_MASK0x3f > - > #define PKEY_DISABLE_ACCESS 0x1 > #define PKEY_DISABLE_WRITE 0x2 > #define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS |\ > diff --git a/arch/mips/include/uapi/asm/mman.h > b/arch/mips/include/uapi/asm/mman.h > index 655e2fb..398eebc 100644 > --- a/arch/mips/include/uapi/asm/mman.h > +++ b/arch/mips/include/uapi/asm/mman.h > @@ -94,17 +94,6 @@ > /* compatibility flags */ > #define MAP_FILE 0 > > -/* > - * When MAP_HUGETLB is set bits [26:31] encode the log2 of the huge page > size. > - * This gives us 6 bits, which is enough until someone invents 128 bit > address > - * spaces. > - * > - * Assume these are all power of twos. > - * When 0 use the default page size. > - */ > -#define MAP_HUGE_SHIFT 26 > -#define MAP_HUGE_MASK0x3f > - > #define PKEY_DISABLE_ACCESS 0x1 > #define PKEY_DISABLE_WRITE 0x2 > #define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS |\ > diff --git a/arch/parisc/include/uapi/asm/mman.h > b/arch/parisc/include/uapi/asm/mman.h > index 5979745..9cd0e8c 100644 > --- a/arch/parisc/include/uapi/asm/mman.h > +++ b/arch/parisc/include/uapi/asm/mman.h > @@ -64,17 +64,6 @@ > #define MAP_FILE 0 > #define MAP_VARIABLE 0 > > -/* > - * When MAP_HUGETLB is set bits [26:31] encode the log2 of the huge page > size. > - * This gives us 6 bits, which is enough until someone invents 128 bit > address > - * spaces. > - * > - * Assume these are all power of twos. > - * When 0 use the default page size. > - */ > -#define MAP_HUGE_SHIFT 26 > -#define MAP_HUGE_MASK0x3f > - > #define PKEY_DISABLE_ACCESS 0x1 > #define PKEY_DISABLE_WRITE 0x2 > #define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS |\ > diff --git a/arch/powerpc/include/uapi/asm/mman.h > b/arch/powerpc/include/uapi/asm/mman.h > index ab45cc2..03c06ba 100644 > --- a/arch/powerpc/include/uapi/asm/mman.h > +++ b/arch/powerpc/include/uapi/asm/mman.h > @@ -29,20 +29,4 @@ > #define MAP_STACK0x2 /* give out an address that is best > suited for process/thread stacks */ > #define MAP_HUGETLB 0x4 /* create a huge page mapping */ > > -/* > - * When MAP_HUGETLB is set, bits [26:31] of the flags argument to mmap(2), > - * encode the log2 of the huge page size. A value of zero indicates that the > - * default huge page size should be used. To use a non-default huge page > size, > - * one of these defines can be used, or the size can be encoded by hand. Note > - * that on most systems only a subset, or possibly none, of these sizes will > be > - * available. > - */ > -#define MAP_HUGE_512KB (19 << MAP_HUGE_SHIFT) /* 512KB HugeTLB Page */ > -#define MAP_HUGE_1MB (20 << MAP_HUGE_SHIFT) /* 1MB HugeTLB Page */ > -#define MAP_HUGE_2MB (21 << MAP_HUGE_SHIFT) /* 2MB HugeTLB Page */ > -#define MAP_HUGE_8MB (23 << MAP_HUGE_SHIFT) /* 8MB HugeTLB Page */ > -#define MAP_HUGE_16MB(24 << MAP_HUGE_SHIFT) /* 16MB HugeTLB Page */ > -#define MAP_HUGE_1GB (30 << MAP_HUGE_SHIFT) /* 1GB HugeTLB Page */ > -#define MAP_HUGE_16GB(34 << MAP_HUGE_SHIFT) /* 16GB HugeTLB Page */ > - > #endif /* _UAPI_ASM_POWERPC_MMAN_H */ > diff --git a/arch/x86/include/uapi/asm/mman.h > b/arch/x86/include/uapi/asm/mman.h > index 39bca7f..3be08f0
Re: [PATCH 3/3] mm:shm: Use new hugetlb size encoding definitions
On Mon 31-07-17 11:56:26, Mike Kravetz wrote:
> Use the common definitions from hugetlb_encode.h header file for
> encoding hugetlb size definitions in shmget system call flags.
>
> In addition, move these definitions from the internal (kernel) to
> user (uapi) header file.
>
> Suggested-by: Matthew Wilcox
> Signed-off-by: Mike Kravetz
Acked-by: Michal Hocko
> ---
> include/linux/shm.h | 17 -
> include/uapi/linux/shm.h | 31 +--
> 2 files changed, 29 insertions(+), 19 deletions(-)
>
> diff --git a/include/linux/shm.h b/include/linux/shm.h
> index 04e8818..d56285a 100644
> --- a/include/linux/shm.h
> +++ b/include/linux/shm.h
> @@ -27,23 +27,6 @@ struct shmid_kernel /* private to the kernel */
> /* shm_mode upper byte flags */
> #define SHM_DEST01000 /* segment will be destroyed on last
> detach */
> #define SHM_LOCKED 02000 /* segment will not be swapped */
> -#define SHM_HUGETLB 04000 /* segment will use huge TLB pages */
> -#define SHM_NORESERVE 01 /* don't check for reservations */
> -
> -/* Bits [26:31] are reserved */
> -
> -/*
> - * When SHM_HUGETLB is set bits [26:31] encode the log2 of the huge page
> size.
> - * This gives us 6 bits, which is enough until someone invents 128 bit
> address
> - * spaces.
> - *
> - * Assume these are all power of twos.
> - * When 0 use the default page size.
> - */
> -#define SHM_HUGE_SHIFT 26
> -#define SHM_HUGE_MASK 0x3f
> -#define SHM_HUGE_2MB(21 << SHM_HUGE_SHIFT)
> -#define SHM_HUGE_1GB(30 << SHM_HUGE_SHIFT)
>
> #ifdef CONFIG_SYSVIPC
> struct sysv_shm {
> diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
> index 1fbf24e..cf23c87 100644
> --- a/include/uapi/linux/shm.h
> +++ b/include/uapi/linux/shm.h
> @@ -3,6 +3,7 @@
>
> #include
> #include
> +#include
> #ifndef __KERNEL__
> #include
> #endif
> @@ -40,11 +41,37 @@ struct shmid_ds {
> /* Include the definition of shmid64_ds and shminfo64 */
> #include
>
> -/* permission flag for shmget */
> +/*
> + * shmget() shmflg values.
> + */
> +/* The bottom nine bits are the same as open(2) mode flags */
> #define SHM_R0400/* or S_IRUGO from */
> #define SHM_W0200/* or S_IWUGO from */
> +/* Bits 9 & 10 are IPC_CREAT and IPC_EXCL */
> +#define SHM_HUGETLB 04000 /* segment will use huge TLB pages */
> +#define SHM_NORESERVE01 /* don't check for reservations */
> +
> +/*
> + * Huge page size encoding when SHM_HUGETLB is specified, and a huge page
> + * size other than the default is desired. See hugetlb_encode.h
> + */
> +#define SHM_HUGE_SHIFT HUGETLB_FLAG_ENCODE_SHIFT
> +#define SHM_HUGE_MASKHUGETLB_FLAG_ENCODE_MASK
> +
> +#define SHM_HUGE_64KBHUGETLB_FLAG_ENCODE_64KB
> +#define SHM_HUGE_512KB HUGETLB_FLAG_ENCODE_512KB
> +#define SHM_HUGE_1MB HUGETLB_FLAG_ENCODE_1MB
> +#define SHM_HUGE_2MB HUGETLB_FLAG_ENCODE_2MB
> +#define SHM_HUGE_8MB HUGETLB_FLAG_ENCODE_8MB
> +#define SHM_HUGE_16MBHUGETLB_FLAG_ENCODE_16MB
> +#define SHM_HUGE_256MB HUGETLB_FLAG_ENCODE_256MB
> +#define SHM_HUGE_1GB HUGETLB_FLAG_ENCODE_1GB
> +#define SHM_HUGE_2GB HUGETLB_FLAG_ENCODE_2GB
> +#define SHM_HUGE_16GBHUGETLB_FLAG_ENCODE_16GB
>
> -/* mode for attach */
> +/*
> + * shmat() shmflg values
> + */
> #define SHM_RDONLY 01 /* read-only access */
> #define SHM_RND 02 /* round attach address to SHMLBA
> boundary */
> #define SHM_REMAP 04 /* take-over region on attach */
> --
> 2.7.5
--
Michal Hocko
SUSE Labs
Re: [RFC][PATCH v3]: documentation,atomic: Add new documents
On Mon, Jul 31, 2017 at 10:43:45AM -0700, Paul E. McKenney wrote: > Why wouldn't the following have ACQUIRE semantics? > > atomic_inc(&var); > smp_mb__after_atomic(); > > Is the issue that there is no actual value returned or some such? Yes, so that the inc is a load-store, and thus there is a load, we loose the value. But I see your point I think. Irrespective of still having the value, the ordering is preserved and nothing should pass across that. > So if I have something like this, the assertion really can trigger? > > WRITE_ONCE(x, 1); atomic_inc(&y); > r0 = xchg_release(&y, 5); smp_mb__after_atomic(); > r1 = READ_ONCE(x); > > > WARN_ON(r0 == 0 && r1 == 0); > > I must confess that I am not seeing why we would want to allow this > outcome. No you are indeed quite right. I just wasn't creative enough. Thanks for the inspiration.
[PATCH] sysfs: replace WARN() with pr_debug in sysfs_remove_group()
There is no enough error handling in block device adding/registration path, for example, device_add_disk() blk_register_queue() When kernel returns from device_add_disk(), no return value to tell us it was successful or not --- that suggests it would always succeed, and according to this assumption, then during block device removal/ unregistration steps, sd_remove() del_gendisk() blk_unregister_queue() dpm_sysfs_remove(), blk_trace_remove_sysfs() will be called blindly, though there is likely no 'trace' 'power' sysfs groups there because actually blk_register_queue()/device_add() failed somewhere. thus causes WARN flood emitted from sysfs_remove_group() as following triggered by unloading fnic driver: modprobe -rv fnic [ 122.081398] WARNING: CPU: 14 PID: 11709 at fs/sysfs/group.c:224 sysfs_remove_group+0x9c/0xa0() [ 122.081399] sysfs group 'trace' not found for kobject 'sdb' [ 122.081424] CPU: 14 PID: 11709 Comm: modprobe Tainted: GW 4.1.12.x86_64 #2 [ 122.081425] Hardware name: Cisco Systems Inc UCSBXXxx [ 122.081425] 0286 d03792ff 881037823ad8 8173605d [ 122.081427] 881037823b30 81a2b9bc 881037823b18 810862aa [ 122.081428] 88103974a000 81ba4080 882037d45080 [ 122.081430] Call Trace: [ 122.081432] [] dump_stack+0x63/0x81 [ 122.081434] [] warn_slowpath_common+0x8a/0xc0 [ 122.081435] [] warn_slowpath_fmt+0x55/0x70 [ 122.081437] [] ? kernfs_find_and_get_ns+0x4c/0x60 [ 122.081439] [] sysfs_remove_group+0x9c/0xa0 [ 122.081441] [] blk_trace_remove_sysfs+0x14/0x20 [ 122.081444] [] blk_unregister_queue+0x65/0x90 [ 122.081446] [] del_gendisk+0x126/0x290 [ 122.081449] [] sd_remove+0x61/0xc0 [sd_mod] [ 122.081452] [] __device_release_driver+0x87/0x120 [ 122.081454] [] device_release_driver+0x23/0x30 [ 122.081456] [] bus_remove_device+0x108/0x180 [ 122.081457] [] device_del+0x160/0x2a0 [ 122.081459] [] __scsi_remove_device+0xcb/0xd0 [ 122.081461] [] scsi_forget_host+0x64/0x70 [ 122.081462] [] scsi_remove_host+0x7b/0x130 [ 122.081466] [] fnic_remove+0x1b7/0x4a0 [fnic] [ 122.081469] [] pci_device_remove+0x3f/0xc0 [ 122.081472] [] __device_release_driver+0x87/0x120 [ 122.081474] [] driver_detach+0xc8/0xd0 [ 122.081478] [] bus_remove_driver+0x59/0xe0 [ 122.081479] [] driver_unregister+0x30/0x70 [ 122.081482] [] pci_unregister_driver+0x2a/0x80 [ 122.081486] [] fnic_cleanup_module+0x10/0x7a [fnic] [ 122.081488] [] SyS_delete_module+0x1ac/0x230 [ 122.081490] [] ? syscall_trace_leave+0xc6/0x150 [ 122.081491] [] system_call_fastpath+0x12/0x71 [ 122.081502] ---[ end trace 29ba5813719045a4 ]--- WARNING: CPU: 14 PID: 11709 at fs/sysfs/group.c:224 sysfs_remove_group+0x9c/0xa0() [ 122.095724] sysfs group 'power' not found for kobject 'target2:0:4' [ 122.095790] CPU: 14 PID: 11709 Comm: modprobe Tainted: GW 4.1.12.x86_64 #2 [ 122.095793] Hardware name: Cisco Systems Inc UCSBXXxx [ 122.095795] 0286 d03792ff 881037823af8 8173605d [ 122.095800] 881037823b50 81a2b9bc 881037823b38 810862aa [ 122.095803] 881037823b38 81c0cf20 881034701838 [ 122.095807] Call Trace: [ 122.095814] [] dump_stack+0x63/0x81 [ 122.095818] [] warn_slowpath_common+0x8a/0xc0 [ 122.095822] [] warn_slowpath_fmt+0x55/0x70 [ 122.095827] [] ? kernfs_find_and_get_ns+0x4c/0x60 [ 122.095831] [] sysfs_remove_group+0x9c/0xa0 [ 122.095839] [] dpm_sysfs_remove+0x57/0x60 [ 122.095843] [] device_del+0x86/0x2a0 [ 122.095847] [] ? device_remove_file+0x19/0x20 [ 122.095854] [] attribute_container_class_device_del +0x1e/0x30 [ 122.095858] [] transport_remove_classdev+0x52/0x60 [ 122.095862] [] ? transport_add_class_device+0x40/0x40 [ 122.095866] [] attribute_container_device_trigger +0xdc/0xf0 [ 122.095870] [] transport_remove_device+0x15/0x20 [ 122.095875] [] scsi_target_reap_ref_release+0x25/0x40 [ 122.095879] [] scsi_target_reap+0x2c/0x30 [ 122.095883] [] __scsi_remove_device+0x86/0xd0 [ 122.095887] [] scsi_forget_host+0x64/0x70 [ 122.095891] [] scsi_remove_host+0x7b/0x130 [ 122.095900] [] fnic_remove+0x1b7/0x4a0 [fnic] [ 122.095909] [] pci_device_remove+0x3f/0xc0 [ 122.095915] [] __device_release_driver+0x87/0x120 [ 122.095922] [] driver_detach+0xc8/0xd0 [ 122.095930] [] bus_remove_driver+0x59/0xe0 [ 122.095934] [] driver_unregister+0x30/0x70 [ 122.095941] [] pci_unregister_driver+0x2a/0x80 [ 122.095952] [] fnic_cleanup_module+0x10/0x7a [fnic] [ 122.095957] [] SyS_delete_module+0x1ac/0x230 [ 122.095961] [] ? syscall_trace_leave+0xc6/0x150 [ 122.095966] [] system_call_fastpath+0x12/0x71 [ 122.095968] ---[ end trace 29ba5813719045a6 ]--- While, refactoring block device code seems not valuable if just because of above noisy but not so danger
Re: [PATCH] mm: remove optimizations based on i_size in mapping writeback waits
On Mon 31-07-17 11:29:46, Jeff Layton wrote:
> From: Jeff Layton
>
> Marcelo added this i_size based optimization with a patch in 2004
> (commit 765dad09b4ac in the linux-history tree):
>
> commit 765dad09b4ac101a32d87af2bb793c3060497d3c
> Author: Marcelo Tosatti
> Date: Tue Sep 7 17:51:17 2004 -0700
>
> small wait_on_page_writeback_range() optimization
>
> filemap_fdatawait() calls wait_on_page_writeback_range() with -1
> as "end" parameter. This is not needed since we know the EOF
> from the inode. Use that instead.
>
> There may be races here, particularly with clustered or network
> filesystems. Block devices always have an i_size of 0 as well, which
> makes using this with a blockdev inode sort of pointless.
Well, you are not quite right here. You are correct that
file_inode(file)->i_size is 0, however file->f_mapping->host->i_size is the
device size and that's what will be used for filemap_fdatawait(). So that
function works fine for block devices.
> It also seems like a bit of a layering violation since we're operating
> on an address_space here, not an inode.
>
> Finally, it's also questionable whether this optimization really helps
> on workloads that we care about. Should we be optimizing for writeback
> vs. truncate races in a codepath where we expect to wait anyway? It
> doesn't seem worth the risk.
>
> Remove this optimization from the filemap_fdatawait codepaths. This
> means that filemap_fdatawait becomes a trivial wrapper around
> filemap_fdatawait_range.
Agreed for all the other reasons so feel free to add:
Reviewed-by: Jan Kara
Honza
>
> Signed-off-by: Jeff Layton
> ---
> include/linux/fs.h | 9 +++--
> mm/filemap.c | 30 +-
> 2 files changed, 8 insertions(+), 31 deletions(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index af592ca3d509..656e04c6983e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2538,10 +2538,15 @@ extern int invalidate_inode_pages2_range(struct
> address_space *mapping,
> extern int write_inode_now(struct inode *, int);
> extern int filemap_fdatawrite(struct address_space *);
> extern int filemap_flush(struct address_space *);
> -extern int filemap_fdatawait(struct address_space *);
> -extern int filemap_fdatawait_keep_errors(struct address_space *mapping);
> extern int filemap_fdatawait_range(struct address_space *, loff_t lstart,
> loff_t lend);
> +extern int filemap_fdatawait_keep_errors(struct address_space *mapping);
> +
> +static inline int filemap_fdatawait(struct address_space *mapping)
> +{
> + return filemap_fdatawait_range(mapping, 0, LLONG_MAX);
> +}
> +
> extern bool filemap_range_has_page(struct address_space *, loff_t lstart,
> loff_t lend);
> extern int __must_check file_fdatawait_range(struct file *file, loff_t
> lstart,
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 394bb5e96f87..85dfe3bee324 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -512,39 +512,11 @@ EXPORT_SYMBOL(file_fdatawait_range);
> */
> int filemap_fdatawait_keep_errors(struct address_space *mapping)
> {
> - loff_t i_size = i_size_read(mapping->host);
> -
> - if (i_size == 0)
> - return 0;
> -
> - __filemap_fdatawait_range(mapping, 0, i_size - 1);
> + __filemap_fdatawait_range(mapping, 0, LLONG_MAX);
> return filemap_check_and_keep_errors(mapping);
> }
> EXPORT_SYMBOL(filemap_fdatawait_keep_errors);
>
> -/**
> - * filemap_fdatawait - wait for all under-writeback pages to complete
> - * @mapping: address space structure to wait for
> - *
> - * Walk the list of under-writeback pages of the given address space
> - * and wait for all of them. Check error status of the address space
> - * and return it.
> - *
> - * Since the error status of the address space is cleared by this function,
> - * callers are responsible for checking the return value and handling and/or
> - * reporting the error.
> - */
> -int filemap_fdatawait(struct address_space *mapping)
> -{
> - loff_t i_size = i_size_read(mapping->host);
> -
> - if (i_size == 0)
> - return 0;
> -
> - return filemap_fdatawait_range(mapping, 0, i_size - 1);
> -}
> -EXPORT_SYMBOL(filemap_fdatawait);
> -
> static bool mapping_needs_writeback(struct address_space *mapping)
> {
> return (!dax_mapping(mapping) && mapping->nrpages) ||
> --
> 2.13.3
>
--
Jan Kara
SUSE Labs, CR
[PATCH 2/2] staging:rtl8188eu:core Fix Avoid CamelCase
This patch is created to solve CamelCase issue. The
members 'IEs' and 'IELength' of struct wlan_bssid_ex
are modified to 'ies' and 'ielength' to solve CamelCase.
And all the places where these variables are referenced
inside rtl8188eu driver are also changed.
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 75 +-
drivers/staging/rtl8188eu/core/rtw_cmd.c| 26 +++---
drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 20 ++---
drivers/staging/rtl8188eu/core/rtw_ioctl_set.c | 2 +-
drivers/staging/rtl8188eu/core/rtw_mlme.c | 66
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 100
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 34
drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c| 16 ++--
drivers/staging/rtl8188eu/include/wlan_bssdef.h | 10 +--
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 12 +--
10 files changed, 182 insertions(+), 179 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 66d4e6c..2cd20f1 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -69,19 +69,22 @@ static void update_BCNTIM(struct adapter *padapter)
struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
struct mlme_ext_info *pmlmeinfo = &pmlmeext->mlmext_info;
struct wlan_bssid_ex *pnetwork_mlmeext = &pmlmeinfo->network;
- unsigned char *pie = pnetwork_mlmeext->IEs;
+ //unsigned char *pie = pnetwork_mlmeext->ies;
+ unsigned char *pie = pnetwork_mlmeext->ies;
u8 *p, *dst_ie, *premainder_ie = NULL;
u8 *pbackup_remainder_ie = NULL;
uint offset, tmp_len, tim_ielen, tim_ie_offset, remainder_ielen;
/* update TIM IE */
+ //p = rtw_get_ie(pie + _FIXED_IE_LENGTH_, _TIM_IE_, &tim_ielen,
+ //pnetwork_mlmeext->ie_length - _FIXED_IE_LENGTH_);
p = rtw_get_ie(pie + _FIXED_IE_LENGTH_, _TIM_IE_, &tim_ielen,
- pnetwork_mlmeext->IELength - _FIXED_IE_LENGTH_);
+ pnetwork_mlmeext->ie_length - _FIXED_IE_LENGTH_);
if (p && tim_ielen > 0) {
tim_ielen += 2;
premainder_ie = p + tim_ielen;
tim_ie_offset = (int)(p - pie);
- remainder_ielen = pnetwork_mlmeext->IELength -
+ remainder_ielen = pnetwork_mlmeext->ie_length -
tim_ie_offset - tim_ielen;
/* append TIM IE from dst_ie offset */
dst_ie = p;
@@ -94,7 +97,7 @@ static void update_BCNTIM(struct adapter *padapter)
/* get supported rates len */
p = rtw_get_ie(pie + _BEACON_IE_OFFSET_, _SUPPORTEDRATES_IE_,
- &tmp_len, (pnetwork_mlmeext->IELength -
+ &tmp_len, (pnetwork_mlmeext->ie_length -
_BEACON_IE_OFFSET_));
if (p)
offset += tmp_len+2;
@@ -104,7 +107,7 @@ static void update_BCNTIM(struct adapter *padapter)
premainder_ie = pie + offset;
- remainder_ielen = pnetwork_mlmeext->IELength -
+ remainder_ielen = pnetwork_mlmeext->ie_length -
offset - tim_ielen;
/* append TIM IE from offset */
@@ -148,7 +151,7 @@ static void update_BCNTIM(struct adapter *padapter)
kfree(pbackup_remainder_ie);
}
offset = (uint)(dst_ie - pie);
- pnetwork_mlmeext->IELength = offset + remainder_ielen;
+ pnetwork_mlmeext->ie_length = offset + remainder_ielen;
set_tx_beacon_cmd(padapter);
}
@@ -158,13 +161,13 @@ void rtw_add_bcn_ie(struct adapter *padapter, struct
wlan_bssid_ex *pnetwork,
{
struct ndis_802_11_var_ie *pIE;
u8 bmatch = false;
- u8 *pie = pnetwork->IEs;
+ u8 *pie = pnetwork->ies;
u8 *p = NULL, *dst_ie = NULL, *premainder_ie = NULL;
u8 *pbackup_remainder_ie = NULL;
u32 i, offset, ielen = 0, ie_offset, remainder_ielen = 0;
- for (i = sizeof(struct ndis_802_11_fixed_ie); i < pnetwork->IELength;) {
- pIE = (struct ndis_802_11_var_ie *)(pnetwork->IEs + i);
+ for (i = sizeof(struct ndis_802_11_fixed_ie); i < pnetwork->ie_length;)
{
+ pIE = (struct ndis_802_11_var_ie *)(pnetwork->ies + i);
if (pIE->ElementID > index) {
break;
@@ -187,7 +190,7 @@ void rtw_add_bcn_ie(struct adapter *padapter, struct
wlan_bssid_ex *pnetwork,
ie_offset = (int)(p - pie);
- remainder_ielen = pnetwork->IELength - ie_offset - ielen;
+ remainder_ielen = pnetwork->ie_length - ie_offset - ielen;
if (bmatch)
dst_ie = p;
@@ -216,7 +219,7 @@ void rtw_add_bcn_ie(struct adapter *padapter, struct
w
