[PATCH v2 4/5] xhci: Platform: Set Synopsis device disconnection quirk based on platform data
If an xhci platform has Synopsis device disconnection errata then enable
XHCI_DISCONNECT_QUIRK quirk flag.
Signed-off-by: Sneeker Yeh
---
drivers/usb/host/xhci-plat.c |3 +++
include/linux/usb/xhci_pdriver.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b..40beb95 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,6 +147,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
(pdata && pdata->usb3_lpm_capable))
xhci->quirks |= XHCI_LPM_SUPPORT;
+
+ if (pdata && pdata->delay_portcsc_clear)
+ xhci->quirks |= XHCI_DISCONNECT_QUIRK;
/*
* Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
* is called by usb_add_hcd().
diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..a37a3a5 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,14 @@
*
* @usb3_lpm_capable: determines if this xhci platform supports USB3
* LPM capability
+ * @delay_portcsc_clear: determines if Synopsis USB3 core has errata in
+ * "DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1" hardware
+ * configuration.
*
*/
struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+ unsigneddelay_portcsc_clear:1;
};
#endif /* __USB_CORE_XHCI_PDRIVER_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
This issue is defined by a three-way race at disconnect, between
1) Class driver interrupt endpoint resheduling attempts if the ISR gave an ep
error event due to device detach (it would try 3 times)
2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
asynchronously
3) The hardware IP was configured in silicon with
- DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
- Synopsys IP version is < 3.00a
The IP will auto-suspend itself on device detach with some phy-specific interval
after CSC is cleared by 2)
If 2) and 3) complete before 1), the interrupts it expects will not be generated
by the autosuspended IP, leading to a deadlock. Even later disconnection
procedure would detect that corresponding urb is still in-progress and issue a
ep stop command, auto-suspended IP still won't respond to that command.
this defect would result in this when device detached:
---
[ 99.603544] usb 4-1: USB disconnect, device number 2
[ 104.615254] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop
endpoint command.
[ 104.623362] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting host.
[ 104.653261] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
microseconds.
[ 104.660584] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not
halting.
[ 104.667817] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
[ 104.674198] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
--
As a result, when device detached, we desired to postpone "PORTCSC clear" behind
"disable slot". it's found that all executed ep command related to disconnetion,
are executed before "disable slot".
Signed-off-by: Sneeker Yeh
---
drivers/usb/host/xhci-hub.c |4
drivers/usb/host/xhci.c | 29 +
drivers/usb/host/xhci.h | 24
3 files changed, 57 insertions(+)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a7865c4..3b8f7fc 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -368,6 +368,10 @@ static void xhci_clear_port_change_bit(struct xhci_hcd
*xhci, u16 wValue,
port_change_bit = "warm(BH) reset";
break;
case USB_PORT_FEAT_C_CONNECTION:
+ if ((xhci->quirks & XHCI_DISCONNECT_QUIRK) &&
+ !(readl(addr) & PORT_CONNECT))
+ return;
+
status = PORT_CSC;
port_change_bit = "connect";
break;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index c50d8d2..aa8e02a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3584,6 +3584,33 @@ command_cleanup:
return ret;
}
+static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num)
+{
+ int max_ports;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ __le32 __iomem **port_array;
+ u32 status;
+
+ /* print debug info */
+ if (hcd->speed == HCD_USB3) {
+ max_ports = xhci->num_usb3_ports;
+ port_array = xhci->usb3_ports;
+ } else {
+ max_ports = xhci->num_usb2_ports;
+ port_array = xhci->usb2_ports;
+ }
+
+ if (dev_port_num > max_ports) {
+ xhci_err(xhci, "%s() port number invalid", __func__);
+ return;
+ }
+ status = readl(port_array[dev_port_num - 1]);
+
+ /* write 1 to clear */
+ if (!(status & PORT_CONNECT) && (status & PORT_CSC))
+ writel(status & PORT_CSC, port_array[0]);
+}
+
/*
* At this point, the struct usb_device is about to go away, the device has
* disconnected, and all traffic has been stopped and the endpoints have been
@@ -3649,6 +3676,8 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device
*udev)
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(&xhci->lock, flags);
+ if (xhci->quirks & XHCI_DISCONNECT_QUIRK)
+ xhci_try_to_clear_csc(hcd, udev->portnum);
/*
* Event command completion handler will free any data structures
* associated with the slot. XXX Can free sleep?
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index cc7c5bb..65a65cc 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1560,6 +1560,30 @@ struct xhci_hcd {
#define XHCI_SPURIOUS_WAKEUP (1 << 18)
/* For controllers with a broken beyond repair streams implementation */
#define XHCI_BROKEN_STREAMS(1 << 19)
+/*
+ * This issue is defined by a three-way race at disconnect in Synopsis USB3 IP,
+ * between
+ * 1) Class driver interrupt endpoint resheduling attempts if the ISR gave an
ep
+ *error event due to device detach (it would try 3 times)
+ * 2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
+ *asynchronously
+ * 3) The hardware IP was configured in silicon with
+
[PATCH v2 2/5] usb: dwc3: add revision number DWC3_REVISION_300A
Add the contstant for v3.00a dwc3 IP detection
Signed-off-by: Sneeker Yeh
---
drivers/usb/dwc3/core.h |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4bb9aa6..8090249 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -776,6 +776,7 @@ struct dwc3 {
#define DWC3_REVISION_260A 0x5533260a
#define DWC3_REVISION_270A 0x5533270a
#define DWC3_REVISION_280A 0x5533280a
+#define DWC3_REVISION_300A 0x5533300a
enum dwc3_ep0_next ep0_next_event;
enum dwc3_ep0_state ep0state;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/5] usb: dwc3: Add quirk for Synopsis device disconnection errata
Synopsis Designware USB3 IP earlier than v3.00a which is configured in silicon
with DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, would need a specific quirk to prevent
xhci host controller from dying when device is disconnected.
Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP configuration whose state
cannot be checked from software in runtime, it has to be enabled via platform
data or device tree.
Signed-off-by: Sneeker Yeh
---
Documentation/devicetree/bindings/usb/dwc3.txt | 17 +
drivers/usb/dwc3/core.c|6 ++
drivers/usb/dwc3/core.h|1 +
drivers/usb/dwc3/host.c|4
drivers/usb/dwc3/platform_data.h |1 +
5 files changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index cd7f045..1b78b29 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -37,6 +37,23 @@ Optional properties:
- snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
- snps,hird-threshold: HIRD threshold
+ - snps,has_suspend_on_disconnect: true when IP is configured in silicon with
+ DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, it can inject a
+ specific quirk to prevent xhci host controller from
+ dying when usb device is disconnected from root hub.
+ Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP
+ configuration whose state cannot be checked from
+ software in runtime, it has to be enabled via platform
+ data or device tree.
+
+ xhci host dying symptom here is caused by that
+ DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
+ configuration makes IP auto-suspended after PORTCSC is
+ cleared when usb device detached, then an asynchronous
+ disconnection procedure might fail using endpoint
+ command that suspened IP won't have any response to.
+
+ this issue is fixed when IP version >= 3.00a.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 25ddc39..fbceab1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -838,6 +838,9 @@ static int dwc3_probe(struct platform_device *pdev)
"snps,tx_de_emphasis_quirk");
of_property_read_u8(node, "snps,tx_de_emphasis",
&tx_de_emphasis);
+
+ dwc->suspend_on_disconnect_quirk = of_property_read_bool(node,
+ "snps,has_suspend_on_disconnect");
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
dwc->has_lpm_erratum = pdata->has_lpm_erratum;
@@ -864,6 +867,9 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->tx_de_emphasis_quirk = pdata->tx_de_emphasis_quirk;
if (pdata->tx_de_emphasis)
tx_de_emphasis = pdata->tx_de_emphasis;
+
+ dwc->suspend_on_disconnect_quirk =
+ pdata->has_suspend_on_disconnect;
}
/* default to superspeed if no maximum_speed passed */
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 8090249..d7458ff 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -832,6 +832,7 @@ struct dwc3 {
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
+ unsignedsuspend_on_disconnect_quirk:1;
};
/* --
*/
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 12bfd3c..9c42074 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -53,6 +53,10 @@ int dwc3_host_init(struct dwc3 *dwc)
pdata.usb3_lpm_capable = 1;
#endif
+ if ((dwc->revision < DWC3_REVISION_300A) &&
+ dwc->suspend_on_disconnect_quirk)
+ pdata.delay_portcsc_clear = 1;
+
ret = platform_device_add_data(xhci, &pdata, sizeof(pdata));
if (ret) {
dev_err(dwc->dev, "couldn't add platform data to xHCI
device\n");
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index a3a3b6d..69562f1 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -44,4 +44,5 @@ struct dwc3_platform_data {
unsigned tx_de_emphasis_quirk:1;
unsigned tx_de_emphasis:2;
+ unsigned has_suspend_on_disconnect:1;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe
[PATCH v2 0/5] Add support for Fujitsu USB host controller
These patches add support for XHCI compliant Host controller found on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/ The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 driver and last four patch is about quirk implementation of errata in Synopsis DesignWare USB3 IP. Patch 1 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP driver. Patch 2 is to add a revison number 3.00a of Synopsis DesignWare USB3 IP core driver. Patch 3 introduces using a quirk based on a errata of Synopsis DesignWare USB3 IP which is versions < 3.00a and has hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As a result this quirk has to be enabled via platform data or device tree. Patch 4 is to set Synopsis quirk in xhci platform driver based on xhci platform data. Patch 5 introduces a quirk with device disconnection management necessary Synopsys Designware USB3 IP with versions < 3.00a and hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the quirk, that host controller will die after a usb device is disconnected from port of root hub. Successfully tested on Fujitsu mb86s7x board. Changes since v1 (RFC): [https://lkml.org/lkml/2014/12/15/929] - based on Arnd's comment, remove entire unnecessary Fujitsu EHCI/OHCI glue, - based on Felipe's comment, fix mis-using of runtime-pm API and setting dma mask, remove unnecessary comment, and refactor suspend/resume handler in Fujitsu Specific Glue layer in dwc3, - based on Felipe's comment, add more commit log and comments in Synopsis quirk implementation, and separate it into four patches. Sneeker Yeh (5): usb: dwc3: add Fujitsu Specific Glue layer usb: dwc3: add revision number DWC3_REVISION_300A usb: dwc3: Add quirk for Synopsis device disconnection errata xhci: Platform: Set Synopsis device disconnection quirk based on platform data xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core Documentation/devicetree/bindings/usb/dwc3.txt | 17 ++ .../devicetree/bindings/usb/fujitsu-dwc3.txt | 33 drivers/usb/dwc3/Kconfig | 11 ++ drivers/usb/dwc3/Makefile |1 + drivers/usb/dwc3/core.c|6 + drivers/usb/dwc3/core.h|2 + drivers/usb/dwc3/dwc3-mb86s70.c| 206 drivers/usb/dwc3/host.c|4 + drivers/usb/dwc3/platform_data.h |1 + drivers/usb/host/xhci-hub.c|4 + drivers/usb/host/xhci-plat.c |3 + drivers/usb/host/xhci.c| 29 +++ drivers/usb/host/xhci.h| 24 +++ include/linux/usb/xhci_pdriver.h |4 + 14 files changed, 345 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] mfd: rtsx: replace TAB by SPC after #define
On Mon, 19 Jan 2015, 敬锐 wrote: > > On 01/18/2015 08:39 PM, Lee Jones wrote: > > On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote: > > > >> From: Micky Ching > >> > >> Re-format coding-style, using uniform SPC after "#define" keyword > >> instead of mixing using TAB and SPC. > > Tabs and spaces in this context usually have different meanings > > i.e. space after #define usually denotes that the following define is > > a register address, whereas a tab commonly describes a bit field. > > > > Please ensure you're not messing with these conventions. By the looks > > of it you are not, but I need you to confirm that you know what you're > > doing. > if using TAB describe a bit field, and define TAB length = 8 SPC, > the editor will not show any difference(if not highlight TAB/SPC). > And the mix is not to show difference between address and field. > so all replaced by space, and show difference by next patch(02/10). Okay, so you have gone for a 1 space/2 space to differentiate. Sounds good. Acked-by: Lee Jones > >> Signed-off-by: Micky Ching > >> --- > >> include/linux/mfd/rtsx_pci.h | 254 > >> +-- > >> 1 file changed, 127 insertions(+), 127 deletions(-) > >> > >> diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h > >> index 0c12628..a9c2a14 100644 > >> --- a/include/linux/mfd/rtsx_pci.h > >> +++ b/include/linux/mfd/rtsx_pci.h > >> @@ -175,9 +175,9 @@ > >> /* CARD_SHARE_MODE */ > >> #define CARD_SHARE_MASK 0x0F > >> #define CARD_SHARE_MULTI_LUN 0x00 > >> -#define CARD_SHARE_NORMAL 0x00 > >> -#define CARD_SHARE_48_SD0x04 > >> -#define CARD_SHARE_48_MS0x08 > >> +#define CARD_SHARE_NORMAL 0x00 > >> +#define CARD_SHARE_48_SD 0x04 > >> +#define CARD_SHARE_48_MS 0x08 > >> /* CARD_SHARE_MODE for barossa */ > >> #define CARD_SHARE_BAROSSA_SD0x01 > >> #define CARD_SHARE_BAROSSA_MS0x02 > >> @@ -249,76 +249,76 @@ > >> #define CD_AUTO_DISABLE 0x40 > >> > >> /* SD_STAT1 */ > >> -#define SD_CRC7_ERR 0x80 > >> -#define SD_CRC16_ERR0x40 > >> -#define SD_CRC_WRITE_ERR0x20 > >> -#define SD_CRC_WRITE_ERR_MASK 0x1C > >> -#define GET_CRC_TIME_OUT0x02 > >> -#define SD_TUNING_COMPARE_ERR 0x01 > >> +#define SD_CRC7_ERR 0x80 > >> +#define SD_CRC16_ERR 0x40 > >> +#define SD_CRC_WRITE_ERR 0x20 > >> +#define SD_CRC_WRITE_ERR_MASK 0x1C > >> +#define GET_CRC_TIME_OUT 0x02 > >> +#define SD_TUNING_COMPARE_ERR 0x01 > >> > >> /* SD_STAT2 */ > >> -#define SD_RSP_80CLK_TIMEOUT0x01 > >> +#define SD_RSP_80CLK_TIMEOUT 0x01 > >> > >> /* SD_BUS_STAT */ > >> -#define SD_CLK_TOGGLE_EN0x80 > >> -#define SD_CLK_FORCE_STOP 0x40 > >> -#define SD_DAT3_STATUS 0x10 > >> -#define SD_DAT2_STATUS 0x08 > >> -#define SD_DAT1_STATUS 0x04 > >> -#define SD_DAT0_STATUS 0x02 > >> -#define SD_CMD_STATUS 0x01 > >> +#define SD_CLK_TOGGLE_EN 0x80 > >> +#define SD_CLK_FORCE_STOP 0x40 > >> +#define SD_DAT3_STATUS0x10 > >> +#define SD_DAT2_STATUS0x08 > >> +#define SD_DAT1_STATUS0x04 > >> +#define SD_DAT0_STATUS0x02 > >> +#define SD_CMD_STATUS 0x01 > >> > >> /* SD_PAD_CTL */ > >> -#define SD_IO_USING_1V8 0x80 > >> -#define SD_IO_USING_3V3 0x7F > >> -#define TYPE_A_DRIVING 0x00 > >> -#define TYPE_B_DRIVING 0x01 > >> -#define TYPE_C_DRIVING 0x02 > >> -#define TYPE_D_DRIVING 0x03 > >> +#define SD_IO_USING_1V8 0x80 > >> +#define SD_IO_USING_3V3 0x7F > >> +#define TYPE_A_DRIVING0x00 > >> +#define TYPE_B_DRIVING0x01 > >> +#define TYPE_C_DRIVING0x02 > >> +#define TYPE_D_DRIVING0x03 > >> > >> /* SD_SAMPLE_POINT_CTL */ > >> -#define DDR_FIX_RX_DAT 0x00 > >> -#define DDR_VAR_RX_DAT 0x80 > >> -#define DDR_FIX_RX_DAT_EDGE 0x00 > >> -#define DDR_FIX_RX_DAT_14_DELAY 0x40 > >> -#define DDR_FIX_RX_CMD 0x00 > >> -#define DDR_VAR_RX_CMD 0x20 > >> -#define DDR_FIX_RX_CMD_POS_EDGE 0x00 > >> -#define DDR_FIX_RX_CMD_14_DELAY 0x10 > >> -#define SD20_RX_POS_EDGE0x00 > >> -#define SD20_RX_14_DELAY0x08 > >> +#define DDR_FIX_RX_DAT0x00 > >> +#define DDR_VAR_RX_DAT0x80 >
Re: [PATCH 1/1] arch/x86/kvm/vmx.c: Fix external interrupts inject directly bug with guestos RFLAGS.IF=0
From: Radim Krčmář To: Li Kaihang , Cc: g...@kernel.org, pbonz...@redhat.com, t...@linutronix.de, mi...@redhat.com, h...@zytor.com, x...@kernel.org, k...@vger.kernel.org, linux-kernel@vger.kernel.org Date: 2015-01-17 上午 02:36 Subject:Re: [PATCH 1/1] arch/x86/kvm/vmx.c: Fix external interrupts inject directly bug with guestos RFLAGS.IF=0 2015-01-16 16:07+0800, Li Kaihang: > > GuestOS is running and handling some interrupt with RFLAGS.IF = 0 while a > > external interrupt coming, > > then can lead to a vm exit,in this case,we must avoid inject this external > > interrupt or it will generate > > a processor hardware exception causing virtual machine crash. > > What is the source of this exception? (Is there a reproducer?) > > Li Kaihang: exception is produced by intel processor hardware because > injecting a external interrupt vector is forbidden by intel processor when > GuestOS RFLAGS.IF = 0, > this need to be ensured by hypervisor software according to Intel > 64 and IA-32 Architectures Software Developer's Manual Volume 3. (Found it, happens on VMENTRY ... 26.3.1.4 Checks on Guest RIP and RFLAGS The IF flag (RFLAGS[bit 9]) must be 1 if the valid bit (bit 31) in the VM-entry interruption-information field is 1 and the interruption type (bits 10:8) is external interrupt.) > This bug has a certain probability, if code is designed to be > very short between cli and sti in a guestos's interrupt processing, > probability of occurrence > is very low, this event is like moving trap, bug is produced that > guestos is running between cli and sti instruction while a external interrupt > coming, it > may be verified by constructing a special guestos interrupt code. > General OS running on kvm vm has also probability to hit this bug. Is APICv enabled? (Does togging it avoid the bug?) Li kaihang: APICv doesn't completely solve the problem. Firstly, interrupts delivered by APICv must be recognized by virtual apic controller. Secondly, APIC sw is enabled. We know that some interrupts are not recognized by virtual apic controller(those may be what vm need or not),and some hardware interrupts emuluated by QEMU are needed by virtual bios before guestos starts, at this stage APIC sw is disabled. Thirdly, APICv is only supported by intel ivybridge or processors after it, it is not before that. > > Step 1: > > a ext intr gen a vm_exit --> vmx_complete_interrupts --> > > __vmx_complete_interrupts --> case INTR_TYPE_EXT_INR: > > kvm_queue_interrupt(vcpu, vector, type == INTR_TYPE_SOFT_INTR); > > > > Step 2: > > kvm_x86_ops->handle_external_intr(vcpu); > > for the above steps, step 4 and 5 will be a processor hardware exception if > > step1 happen while guestos RFLAGS.IF = 0, that is to say, guestos interrupt > > is disabled. > > So we should add a logic to judge in step 1 whether a external interrupt > > need to be pended then inject directly, in the process, we don't need to > > worry about > > this external interrupt lost because the next Step 2 will handle and choose > > a best chance to inject it by virtual interrupt controller. > > Can you explain the relation between vectored events (Step 1) and > external interrupts (Step 2)? > (The bug happens when external interrupt arrives during event delivery?) > > Li Kaihang: a external interrupt to running vm can trigger a vm_exit event > handled in step 1, then this interrupt vector can be processed in step2 > kvm_x86_ops->handle_external_intr(vcpu) and this function can > jump to HOSTOS IDT to complete external interrupt handling,external interrupt > handler in HOSTOS > IDT may inject the external interrupt into virtual interrupt > controller if it has been registered to be needed by virtual machine. Proposed non-accidental relation between first two steps confuses me ... 1) External interrupt in Step 1 should be from incomplete event delivery to the guest, 2) External interrupt in Step 2 from an interrupt for the host. 3) Interrupts should be unrelated, because if not, then we either deliver host's interrupts directly to the guest, or the other way around. (Both cases are buggy, regardless of CLI.) - What is stored in "VM-exit interruption information" (Step 2) and "IDT-vectoring information" (Step 1)? => Interrupts in first two steps are independent and we have interrupted external interrupt delivery to the guest. Can you provide a KVM trace of what is happening before the crash? (Or just point out where I made a mistake.) Li kaihang: There exist two cases: First, external interrupts registered by vm, such as timer,shared devices,pci passthrough devices interrupts, are handled by host idt to notify one virtual apic interrupt controller which manages all general interrupts owned by a vm, inject_pending_event will complete a interrupt vecto
Re: [PATCH 06/10] mfd: rtsx: update phy register
On Mon, 19 Jan 2015, 敬锐 wrote: > On 01/18/2015 08:29 PM, Lee Jones wrote: > > On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote: > > > >> From: Micky Ching > >> > >> update phy register value and using direct value instead of macros. > >> It is much easier to debug using constant value than a lot of macros. > >> We usually need compare the value directly to check the configure. > > NACK. This is the opposite of what I would like to see. > > > When we debug, we usually need to compare the value provided from hardware, > of course we can compare by print them to kernel log. but I think it more > convenient from source code. And we only set phy register when > initialize chip, > so the value will not scattered everywhere, we will not benefit from macros. > > if we want to know the meaning of setting, we can look at the register > define. This is not acceptable and is the complete opposite of what we're trying to achieve. I promote readability (by humans) as one of the highest priorities when writing code. 0xFE6C is far from readable. > >> Signed-off-by: Micky Ching > >> --- > >> drivers/mfd/rts5249.c | 46 ++ > >> 1 file changed, 14 insertions(+), 32 deletions(-) > >> > >> diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c > >> index 2fe2854..00208d1 100644 > >> --- a/drivers/mfd/rts5249.c > >> +++ b/drivers/mfd/rts5249.c > >> @@ -132,57 +132,39 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr) > >>if (err < 0) > >>return err; > >> > >> - err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV, > >> - PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED | > >> - PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN | > >> - PHY_REG_REV_RX_PWST | PHY_REG_REV_CLKREQ_DLY_TIMER_1_0 | > >> - PHY_REG_REV_STOP_CLKRD | PHY_REG_REV_STOP_CLKWR); > >> + err = rtsx_pci_write_phy_register(pcr, 0x19, 0xFE6C); > >>if (err < 0) > >>return err; > >> > >>msleep(1); > >> > >> - err = rtsx_pci_write_phy_register(pcr, PHY_BPCR, > >> - PHY_BPCR_IBRXSEL | PHY_BPCR_IBTXSEL | > >> - PHY_BPCR_IB_FILTER | PHY_BPCR_CMIRROR_EN); > >> + err = rtsx_pci_write_phy_register(pcr, 0x0A, 0x05C0); > >>if (err < 0) > >>return err; > >> - err = rtsx_pci_write_phy_register(pcr, PHY_PCR, > >> - PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 | > >> - PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 | > >> - PHY_PCR_RSSI_EN); > >> + > >> + err = rtsx_pci_write_phy_register(pcr, 0x00, 0xBA43); > >> + if (err < 0) > >> + return err; > >> + err = rtsx_pci_write_phy_register(pcr, 0x03, 0xC152); > >>if (err < 0) > >>return err; > >> - err = rtsx_pci_write_phy_register(pcr, PHY_RCR2, > >> - PHY_RCR2_EMPHASE_EN | PHY_RCR2_NADJR | > >> - PHY_RCR2_CDR_CP_10 | PHY_RCR2_CDR_SR_2 | > >> - PHY_RCR2_FREQSEL_12 | PHY_RCR2_CPADJEN | > >> - PHY_RCR2_CDR_SC_8 | PHY_RCR2_CALIB_LATE); > >> + err = rtsx_pci_write_phy_register(pcr, 0x1E, 0x78EB); > >>if (err < 0) > >>return err; > >> - err = rtsx_pci_write_phy_register(pcr, PHY_FLD4, > >> - PHY_FLD4_FLDEN_SEL | PHY_FLD4_REQ_REF | > >> - PHY_FLD4_RXAMP_OFF | PHY_FLD4_REQ_ADDA | > >> - PHY_FLD4_BER_COUNT | PHY_FLD4_BER_TIMER | > >> - PHY_FLD4_BER_CHK_EN); > >> + err = rtsx_pci_write_phy_register(pcr, 0x05, 0x4600); > >>if (err < 0) > >>return err; > >> - err = rtsx_pci_write_phy_register(pcr, PHY_RDR, PHY_RDR_RXDSEL_1_9); > >> + err = rtsx_pci_write_phy_register(pcr, 0x02, 0x041F); > >>if (err < 0) > >>return err; > >> - err = rtsx_pci_write_phy_register(pcr, PHY_RCR1, > >> - PHY_RCR1_ADP_TIME | PHY_RCR1_VCO_COARSE); > >> + err = rtsx_pci_write_phy_register(pcr, 0x1D, 0x0824); > >>if (err < 0) > >>return err; > >> - err = rtsx_pci_write_phy_register(pcr, PHY_FLD3, > >> - PHY_FLD3_TIMER_4 | PHY_FLD3_TIMER_6 | > >> - PHY_FLD3_RXDELINK); > >> + err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4FE4); > >>if (err < 0) > >>return err; > >> - return rtsx_pci_write_phy_register(pcr, PHY_TUNE, > >> - PHY_TUNE_TUNEREF_1_0 | PHY_TUNE_VBGSEL_1252 | > >> - PHY_TUNE_SDBUS_33 | PHY_TUNE_TUNED18 | > >> - PHY_TUNE_TUNED12); > >> + > >> + return 0; > >> } > >> > >> static int rts5249_turn_on_led(struct rtsx_pcr *pcr) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org
linux-next: build warning after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
fs/eventfd.c: In function 'eventfd_poll':
fs/eventfd.c:121:16: warning: unused variable 'flags' [-Wunused-variable]
unsigned long flags;
^
Introduced by commit a90de8a54127 ("eventfd: don't take the spinlock in
eventfd_poll").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpG9kOaxzE5x.pgp
Description: OpenPGP digital signature
Re: [PATCH] virtio_pci: add module param to force legacy mode
"Michael S. Tsirkin" writes: > If set, try legacy interface first, modern one if that fails. Useful to > work around device/driver bugs, and for compatibility testing. > > Signed-off-by: Michael S. Tsirkin Thanks, I've applied all these to virtio-next. Cheers! Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: module: fix module_refcount() return when running in a module exit routine
Masami Hiramatsu writes:
> (2015/01/19 1:55), James Bottomley wrote:
>> From: James Bottomley
>>
>> After e513cc1 module: Remove stop_machine from module unloading,
>> module_refcount() is returning (unsigned long)-1 when called from within
>> a routine that runs in module_exit. This is confusing the scsi device
>> put code which is coded to detect a module_refcount() of zero for
>> running within a module exit routine and not try to do another
>> module_put. The fix is to restore the original behaviour of
>> module_refcount() and return zero if we're running inside an exit
>> routine.
>>
>> Fixes: e513cc1c07e2ab93a4514eec9833e031df3e30bb
>> Reported-by: Bart Van Assche
>> Signed-off-by: James Bottomley
>>
>
> Yes, this should be fixed as you said, since it must return "unsigned long"
> value.
But there are only three non-module callers:
drivers/scsi/scsi.c:1012: if (module && module_refcount(module) != 0)
drivers/staging/lustre/lustre/obdclass/lu_object.c:1359:
LINVRNT(module_refcount(key->lct_owner) > 0);
include/linux/module.h:447:unsigned long module_refcount(struct module *mod);
kernel/debug/kdb/kdb_main.c:2026: kdb_printf("%4ld ",
module_refcount(mod));
kernel/module.c:775:unsigned long module_refcount(struct module *mod)
kernel/module.c:779:EXPORT_SYMBOL(module_refcount);
kernel/module.c:859:seq_printf(m, " %lu ", module_refcount(mod));
kernel/module.c:911:return sprintf(buffer, "%lu\n",
module_refcount(mk->mod));
The first one I think should be eliminated, and the second one is simply
an assertion before calling module_put() (which should probably be
eliminated). The others are just printing information.
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/10] mfd: rtsx: add support for rts525A
On Mon, 19 Jan 2015, 敬锐 wrote:
>
> On 01/18/2015 07:13 PM, Lee Jones wrote:
> >> @@ -97,7 +97,7 @@ static void rts5249_force_power_down(struct rtsx_pcr
> >> *pcr, u8 pm_state)
> >> > rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
> >> >
> >> > if (pm_state == HOST_ENTER_S3) {
> >> >- if (PCI_PID(pcr) == 0x524A)
> >> >+ if (PCI_PID(pcr) == 0x524A || PCI_PID(pcr) == 0x525A)
> > Shouldn't these be defined somewhere?
> >
> > I have a particular distaste for magic numbers.
> >
> This is the chip ID number, no need define, just using it.
> if we define, it will like RTS525A_PCI_ID, so bad.
Looks good. Please do that.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] mfd: rtsx: add support for rts524A
On Mon, 19 Jan 2015, 敬锐 wrote:
>
> On 01/18/2015 08:20 PM, Lee Jones wrote:
> >> +static int rts524a_optimize_phy(struct rtsx_pcr *pcr)
> >> >+{
> >> >+ int err;
> >> >+
> >> >+ err = rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3,
> >> >+ D3_DELINK_MODE_EN, 0x00);
> >> >+ if (err < 0)
> >> >+ return err;
> > if (err)
> >
> err value will never be positive, but I have to make it consistence
> with driver in other place, because all the check using if (err < 0) form.
Then all of them should be changed.
> And maybe, it make reserved for future the function may return positive
> value.
I'd prefer not to live in the world of 'what if'. I think only
checking for a less than zero error value insinuates that a greater
than zero return is acceptable, but in this case is it not.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] power: Add max77693 charger driver
On nie, 2015-01-18 at 18:00 +, Lee Jones wrote: > Tell us what you need? Hi Lee, All I need is... acks or applying of patchset by Sebastian. Sebastian acked main patch (3/4) but then I changed it [1]. You already acked the MFD change (patch 2/4: mfd: max77693: Add defines for MAX77693 charger driver). The patch with bindings (1/4: devicetree: power/mfd: max77693: Document new bindings for charger) actually adds bindings for charger so rather Sebastian's opinion is needed. Other patches are from power supply subsystem. Thanks for asking! Dear Sebastian, You already looked at the patchset [1], so maybe you could pick it up? [1] https://lkml.org/lkml/2014/10/27/774 Best regards, Krzysztof > > > Changes since v3 > > > > 1. Patch 3/4: Don't create platform data structure for charger settings > >because driver won't be used on non-DT SoCs (its for Exynos based > >Trats2). > > 2. Patch 3/4: Drop Sebastian's ack [1] because of change above. > > > > Changes since v2 > > > > 1. Add ack from Sebastian Reichel (charger driver). > > 2. Drop patch "mfd: max77693: Map charger device to its own of_node" > >(applied by Lee Jones). > > > > > > Changes since v1 > > > > 1. Add patch 2/5: mfd: max77693: Map charger device to its own of_node > >(forgot to send it in v1) > > 2. Remove patches for DTS and configs. I'll send them later. > > 3. Add ack from Lee Jones (patch 3/5). > > > > > > Description > > === > > The patchset adds max77693 charger driver present on Trats2 board > > (and Galaxy S III). The driver configures battery charger and exposes > > power supply interface. > > > > Driver is necessary to provide full charging stack on Trats2 device > > (extcon, charger-manager etc.). > > > > [1] https://lkml.org/lkml/2014/10/27/774 > > > > > > Best regards, > > Krzysztof > > > > > > > > Krzysztof Kozlowski (4): > > devicetree: power/mfd: max77693: Document new bindings for charger > > mfd: max77693: Add defines for MAX77693 charger driver > > power: max77693: Add charger driver for Maxim 77693 > > Documentation: power: max77693-charger: Document exported sysfs entry > > > > Documentation/ABI/testing/sysfs-class-power| 42 ++ > > Documentation/devicetree/bindings/mfd/max77693.txt | 45 ++ > > drivers/power/Kconfig | 6 + > > drivers/power/Makefile | 1 + > > drivers/power/max77693_charger.c | 758 > > + > > include/linux/mfd/max77693-private.h | 108 +++ > > 6 files changed, 960 insertions(+) > > create mode 100644 drivers/power/max77693_charger.c > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] mfd: rtsx: add support for rts524A
On Mon, 19 Jan 2015, 敬锐 wrote:
>
> On 01/18/2015 08:20 PM, Lee Jones wrote:
> >> +};
> >> >+
> >> >+void rts524a_init_params(struct rtsx_pcr *pcr)
> >> >+{
> >> >+ rts5249_init_params(pcr);
> >> >+
> >> >+ pcr->ops = &rts524a_pcr_ops;
> >> >+}
> > I see a couple of these now. Why don't you make 'ops' a parameter of
> > *_init_params().
> >
> *_init_params() is called from rtsx_pcr.c, and the ops parameter should
> be static, if we make ops as a parameter, the rts524a_pcr_ops defination
> should move to rtsx_pcr.c, not reasonable.
Fair enough.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CMA: treat free cma pages as non-free if not ALLOC_CMA on watermark checking
On Mon, Jan 19, 2015 at 2:55 PM, Minchan Kim wrote:
> Hello,
>
> On Sun, Jan 18, 2015 at 04:32:59PM +0800, Hui Zhu wrote:
>> From: Hui Zhu
>>
>> The original of this patch [1] is part of Joonsoo's CMA patch series.
>> I made a patch [2] to fix the issue of this patch. Joonsoo reminded me
>> that this issue affect current kernel too. So made a new one for upstream.
>
> Recently, we found many problems of CMA and Joonsoo tried to add more
> hooks into MM like agressive allocation but I suggested adding new zone
> would be more desirable than more hooks in mm fast path in various aspect.
> (ie, remove lots of hooks in hot path of MM, don't need reclaim hooks
> for special CMA pages, don't need custom fair allocation for CMA).
>
> Joonsoo is investigating the direction so please wait.
> If it turns out we have lots of hurdle to go that way,
> this direction(ie, putting more hooks) should be second plan.
OK. Thanks.
Best,
Hui
>
> Thanks.
>
>>
>> Current code treat free cma pages as non-free if not ALLOC_CMA in the first
>> check:
>> if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx])
>> return false;
>> But in the loop after that, it treat free cma pages as free memory even
>> if not ALLOC_CMA.
>> So this one substruct free_cma from free_pages before the loop if not
>> ALLOC_CMA to treat free cma pages as non-free in the loop.
>>
>> But there still have a issue is that CMA memory in each order is part
>> of z->free_area[o].nr_free, then the CMA page number of this order is
>> substructed twice. This bug will make __zone_watermark_ok return more false.
>> This patch add cma_nr_free to struct free_area that just record the number
>> of CMA pages. And add it back in the order loop to handle the substruct
>> twice issue.
>>
>> The last issue of this patch should handle is pointed by Joonsoo in [3].
>> If pageblock for CMA is isolated, cma_nr_free would be miscalculated.
>> This patch add two functions nr_free_inc and nr_free_dec to change the
>> values of nr_free and cma_nr_free. If the migratetype is MIGRATE_ISOLATE,
>> they will not change the value of nr_free.
>> Change __mod_zone_freepage_state to doesn't record isolated page to
>> NR_FREE_PAGES.
>> And add code to move_freepages to record the page number that isolated:
>> if (is_migrate_isolate(migratetype))
>> nr_free_dec(&zone->free_area[order],
>> get_freepage_migratetype(page));
>> else
>> nr_free_inc(&zone->free_area[order], migratetype);
>> Then the isolate issue is handled.
>>
>> This patchset is based on fc7f0dd381720ea5ee5818645f7d0e9dece41cb0.
>>
>> [1] https://lkml.org/lkml/2014/5/28/110
>> [2] https://lkml.org/lkml/2014/12/25/43
>> [3] https://lkml.org/lkml/2015/1/4/220
>>
>> Signed-off-by: Joonsoo Kim
>> Signed-off-by: Hui Zhu
>> Signed-off-by: Weixing Liu
>> ---
>> include/linux/mmzone.h | 3 +++
>> include/linux/vmstat.h | 4 +++-
>> mm/page_alloc.c| 59
>> +-
>> 3 files changed, 55 insertions(+), 11 deletions(-)
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index 2f0856d..094476b 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -92,6 +92,9 @@ static inline int get_pfnblock_migratetype(struct page
>> *page, unsigned long pfn)
>> struct free_area {
>> struct list_headfree_list[MIGRATE_TYPES];
>> unsigned long nr_free;
>> +#ifdef CONFIG_CMA
>> + unsigned long cma_nr_free;
>> +#endif
>> };
>>
>> struct pglist_data;
>> diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
>> index 82e7db7..f18ef00 100644
>> --- a/include/linux/vmstat.h
>> +++ b/include/linux/vmstat.h
>> @@ -6,6 +6,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> extern int sysctl_stat_interval;
>> @@ -280,7 +281,8 @@ static inline void drain_zonestat(struct zone *zone,
>> static inline void __mod_zone_freepage_state(struct zone *zone, int
>> nr_pages,
>>int migratetype)
>> {
>> - __mod_zone_page_state(zone, NR_FREE_PAGES, nr_pages);
>> + if (!is_migrate_isolate(migratetype))
>> + __mod_zone_page_state(zone, NR_FREE_PAGES, nr_pages);
>> if (is_migrate_cma(migratetype))
>> __mod_zone_page_state(zone, NR_FREE_CMA_PAGES, nr_pages);
>> }
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 7633c50..9a2b6da 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -576,6 +576,28 @@ static inline int page_is_buddy(struct page *page,
>> struct page *buddy,
>> return 0;
>> }
>>
>> +static inline void nr_free_inc(struct free_area *area, int migratetype)
>> +{
>> + if (!is_migrate_isolate(migratetype))
>> + area->nr_free++;
>> +
>> +#ifdef CONFIG_CMA
>> + if (is_migrate_cma(migratetype))
>> + area->cma_nr_free++;
>> +#e
Re: linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
On Mon, 19 Jan 2015 18:28:53 +1100 Stephen Rothwell
wrote:
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> mm/filemap_xip.c:304:2: error: unknown field 'remap_pages' specified in
> initializer
> .remap_pages = generic_file_remap_pages,
> ^
> mm/filemap_xip.c:304:17: error: 'generic_file_remap_pages' undeclared here
> (not in a function)
> .remap_pages = generic_file_remap_pages,
> ^
>
> Caused by commit 76f0255272b6 ("mm: drop vm_ops->remap_pages and
> generic_file_remap_pages() stub"). Looks like one was missed - grep is
> your friend.
>
> I have added this patch for today:
>
> From: Stephen Rothwell
> Date: Mon, 19 Jan 2015 18:16:15 +1100
> Subject: [PATCH] mm: drop vm_ops->remap_pages and generic_file_remap_pages()
> stub fix
>
> Signed-off-by: Stephen Rothwell
> ---
> mm/filemap_xip.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/mm/filemap_xip.c b/mm/filemap_xip.c
> index 0d105aeff82f..70c09da1a419 100644
> --- a/mm/filemap_xip.c
> +++ b/mm/filemap_xip.c
> @@ -301,7 +301,6 @@ out:
> static const struct vm_operations_struct xip_file_vm_ops = {
> .fault = xip_file_fault,
> .page_mkwrite = filemap_page_mkwrite,
> - .remap_pages = generic_file_remap_pages,
> };
>
> int xip_file_mmap(struct file * file, struct vm_area_struct * vma)
> --
> 2.1.4
I then had to fix up the later patch "dax,ext2: replace the XIP page
fault handler with the DAX page fault handler" because the above line
was already removed.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpRtqJGhQx6g.pgp
Description: OpenPGP digital signature
[PATCH] staging: rts5028: use msecs_to_jiffies for timeouts
This is only an API consolidation and should make things more readable
Signed-off-by: Nicholas Mc Guire
---
Converting milliseconds to jiffies by val * HZ / 1000 is technically
not wrong but msecs_to_jiffies(val) is the cleaner solution and handles
corner cases correctly.
This patch was only compile tested with x86_64_defconfig + CONFIG_STAGING=y,
CONFIG_RTS5208=m
Patch is against 3.19.0-rc4 -next-20150116
drivers/staging/rts5208/rtsx_transport.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_transport.c
b/drivers/staging/rts5208/rtsx_transport.c
index 756a968..dab1995 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -271,7 +271,7 @@ int rtsx_send_cmd(struct rtsx_chip *chip, u8 card, int
timeout)
/* Wait for TRANS_OK_INT */
timeleft = wait_for_completion_interruptible_timeout(
- &trans_done, timeout * HZ / 1000);
+ &trans_done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "chip->int_reg = 0x%x\n",
chip->int_reg);
@@ -431,7 +431,7 @@ static int rtsx_transfer_sglist_adma_partial(struct
rtsx_chip *chip, u8 card,
spin_unlock_irq(&rtsx->reg_lock);
timeleft = wait_for_completion_interruptible_timeout(
- &trans_done, timeout * HZ / 1000);
+ &trans_done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
@@ -455,7 +455,7 @@ static int rtsx_transfer_sglist_adma_partial(struct
rtsx_chip *chip, u8 card,
init_completion(&trans_done);
spin_unlock_irq(&rtsx->reg_lock);
timeleft = wait_for_completion_interruptible_timeout(
- &trans_done, timeout * HZ / 1000);
+ &trans_done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
@@ -575,7 +575,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip
*chip, u8 card,
spin_unlock_irq(&rtsx->reg_lock);
timeleft = wait_for_completion_interruptible_timeout(
- &trans_done, timeout * HZ / 1000);
+ &trans_done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
@@ -602,7 +602,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip
*chip, u8 card,
init_completion(&trans_done);
spin_unlock_irq(&rtsx->reg_lock);
timeleft = wait_for_completion_interruptible_timeout(
- &trans_done, timeout * HZ / 1000);
+ &trans_done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
@@ -688,7 +688,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8
card, void *buf,
/* Wait for TRANS_OK_INT */
timeleft = wait_for_completion_interruptible_timeout(
- &trans_done, timeout * HZ / 1000);
+ &trans_done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
mm/filemap_xip.c:304:2: error: unknown field 'remap_pages' specified in
initializer
.remap_pages = generic_file_remap_pages,
^
mm/filemap_xip.c:304:17: error: 'generic_file_remap_pages' undeclared here (not
in a function)
.remap_pages = generic_file_remap_pages,
^
Caused by commit 76f0255272b6 ("mm: drop vm_ops->remap_pages and
generic_file_remap_pages() stub"). Looks like one was missed - grep is
your friend.
I have added this patch for today:
From: Stephen Rothwell
Date: Mon, 19 Jan 2015 18:16:15 +1100
Subject: [PATCH] mm: drop vm_ops->remap_pages and generic_file_remap_pages()
stub fix
Signed-off-by: Stephen Rothwell
---
mm/filemap_xip.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/filemap_xip.c b/mm/filemap_xip.c
index 0d105aeff82f..70c09da1a419 100644
--- a/mm/filemap_xip.c
+++ b/mm/filemap_xip.c
@@ -301,7 +301,6 @@ out:
static const struct vm_operations_struct xip_file_vm_ops = {
.fault = xip_file_fault,
.page_mkwrite = filemap_page_mkwrite,
- .remap_pages = generic_file_remap_pages,
};
int xip_file_mmap(struct file * file, struct vm_area_struct * vma)
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp7dkeXNYHJ1.pgp
Description: OpenPGP digital signature
[PATCH net-next 0/7] r8152: adjust the code
Code adjustment. Hayes Wang (7): r8152: adjust rx_bottom r8152: adjust lpm timer r8152: check linking status with netif_carrier_ok r8152: check RTL8152_UNPLUG for rtl8152_close r8152: adjust the link feed for hw_features r8152: replace get_protocol with vlan_get_protocol r8152: use BIT macro drivers/net/usb/r8152.c | 99 +++-- 1 file changed, 46 insertions(+), 53 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 4/7] r8152: check RTL8152_UNPLUG for rtl8152_close
It is unnecessary to accress the hw register if the device is unplugged.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 21f853f..9be642e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3064,7 +3064,7 @@ static int rtl8152_close(struct net_device *netdev)
netif_stop_queue(netdev);
res = usb_autopm_get_interface(tp->intf);
- if (res < 0) {
+ if (res < 0 || test_bit(RTL8152_UNPLUG, &tp->flags)) {
rtl_drop_queued_tx(tp);
rtl_stop_rx(tp);
} else {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 2/7] r8152: adjust lpm timer
Set LPM timer to 500us, except for RTL_VER_04 which doesn't link at USB 3.0. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 78a8917..3ee9d06 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -3274,10 +3274,10 @@ static void r8153_init(struct r8152 *tp) ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_LPM_CTRL); ocp_data &= ~LPM_TIMER_MASK; - if (tp->udev->speed == USB_SPEED_SUPER) - ocp_data |= LPM_TIMER_500US; - else + if (tp->version == RTL_VER_04 && tp->udev->speed != USB_SPEED_SUPER) ocp_data |= LPM_TIMER_500MS; + else + ocp_data |= LPM_TIMER_500US; ocp_write_byte(tp, MCU_TYPE_USB, USB_LPM_CTRL, ocp_data); ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_AFE_CTRL2); -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 3/7] r8152: check linking status with netif_carrier_ok
Replace (tp->speed & LINK_STATUS) with netif_carrier_ok().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3ee9d06..21f853f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -581,7 +581,6 @@ struct r8152 {
u16 ocp_base;
u8 *intr_buff;
u8 version;
- u8 speed;
};
enum rtl_version {
@@ -1169,12 +1168,12 @@ static void intr_callback(struct urb *urb)
d = urb->transfer_buffer;
if (INTR_LINK & __le16_to_cpu(d[0])) {
- if (!(tp->speed & LINK_STATUS)) {
+ if (!netif_carrier_ok(tp->netdev)) {
set_bit(RTL8152_LINK_CHG, &tp->flags);
schedule_delayed_work(&tp->schedule, 0);
}
} else {
- if (tp->speed & LINK_STATUS) {
+ if (netif_carrier_ok(tp->netdev)) {
set_bit(RTL8152_LINK_CHG, &tp->flags);
schedule_delayed_work(&tp->schedule, 0);
}
@@ -1906,7 +1905,7 @@ static void rtl8152_set_rx_mode(struct net_device *netdev)
{
struct r8152 *tp = netdev_priv(netdev);
- if (tp->speed & LINK_STATUS) {
+ if (netif_carrier_ok(netdev)) {
set_bit(RTL8152_SET_RX_MODE, &tp->flags);
schedule_delayed_work(&tp->schedule, 0);
}
@@ -2936,21 +2935,20 @@ static void set_carrier(struct r8152 *tp)
speed = rtl8152_get_speed(tp);
if (speed & LINK_STATUS) {
- if (!(tp->speed & LINK_STATUS)) {
+ if (!netif_carrier_ok(netdev)) {
tp->rtl_ops.enable(tp);
set_bit(RTL8152_SET_RX_MODE, &tp->flags);
netif_carrier_on(netdev);
rtl_start_rx(tp);
}
} else {
- if (tp->speed & LINK_STATUS) {
+ if (netif_carrier_ok(netdev)) {
netif_carrier_off(netdev);
napi_disable(&tp->napi);
tp->rtl_ops.disable(tp);
napi_enable(&tp->napi);
}
}
- tp->speed = speed;
}
static void rtl_work_func_t(struct work_struct *work)
@@ -2982,7 +2980,7 @@ static void rtl_work_func_t(struct work_struct *work)
/* don't schedule napi before linking */
if (test_bit(SCHEDULE_NAPI, &tp->flags) &&
- (tp->speed & LINK_STATUS)) {
+ netif_carrier_ok(tp->netdev)) {
clear_bit(SCHEDULE_NAPI, &tp->flags);
napi_schedule(&tp->napi);
}
@@ -3005,8 +3003,7 @@ static int rtl8152_open(struct net_device *netdev)
if (res)
goto out;
- /* set speed to 0 to avoid autoresume try to submit rx */
- tp->speed = 0;
+ netif_carrier_off(netdev);
res = usb_autopm_get_interface(tp->intf);
if (res < 0) {
@@ -3023,7 +3020,7 @@ static int rtl8152_open(struct net_device *netdev)
cancel_delayed_work_sync(&tp->schedule);
/* disable the tx/rx, if the workqueue has enabled them. */
- if (tp->speed & LINK_STATUS)
+ if (netif_carrier_ok(netdev))
tp->rtl_ops.disable(tp);
}
@@ -3032,7 +3029,6 @@ static int rtl8152_open(struct net_device *netdev)
rtl8152_set_speed(tp, AUTONEG_ENABLE,
tp->mii.supports_gmii ? SPEED_1000 : SPEED_100,
DUPLEX_FULL);
- tp->speed = 0;
netif_carrier_off(netdev);
netif_start_queue(netdev);
set_bit(WORK_ENABLE, &tp->flags);
@@ -3358,7 +3354,7 @@ static int rtl8152_resume(struct usb_interface *intf)
rtl_runtime_suspend_enable(tp, false);
clear_bit(SELECTIVE_SUSPEND, &tp->flags);
set_bit(WORK_ENABLE, &tp->flags);
- if (tp->speed & LINK_STATUS)
+ if (netif_carrier_ok(tp->netdev))
rtl_start_rx(tp);
} else {
tp->rtl_ops.up(tp);
@@ -3366,7 +3362,6 @@ static int rtl8152_resume(struct usb_interface *intf)
tp->mii.supports_gmii ?
SPEED_1000 : SPEED_100,
DUPLEX_FULL);
- tp->speed = 0;
netif_carrier_off(tp->netdev);
set_bit(WORK_ENABLE, &tp->flags);
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 5/7] r8152: adjust the link feed for hw_features
Keep NETIF_F_HW_VLAN_CTAG_RX and NETIF_F_HW_VLAN_CTAG_TX at the same line. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 9be642e..f66ffbd 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -3926,8 +3926,7 @@ static int rtl8152_probe(struct usb_interface *intf, netdev->hw_features = NETIF_F_RXCSUM | NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO | NETIF_F_FRAGLIST | NETIF_F_IPV6_CSUM | NETIF_F_TSO6 | - NETIF_F_HW_VLAN_CTAG_RX | - NETIF_F_HW_VLAN_CTAG_TX; + NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_CTAG_TX; netdev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | NETIF_F_IPV6_CSUM | NETIF_F_TSO6; -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 1/7] r8152: adjust rx_bottom
If a error occurs when submitting rx, skip the remaining submissions
and try to submit them again next time.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2e22442..78a8917 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1655,7 +1655,7 @@ static int rx_bottom(struct r8152 *tp, int budget)
{
unsigned long flags;
struct list_head *cursor, *next, rx_queue;
- int work_done = 0;
+ int ret = 0, work_done = 0;
if (!skb_queue_empty(&tp->rx_queue)) {
while (work_done < budget) {
@@ -1746,7 +1746,18 @@ find_next_rx:
}
submit:
- r8152_submit_rx(tp, agg, GFP_ATOMIC);
+ if (!ret) {
+ ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
+ } else {
+ urb->actual_length = 0;
+ list_add_tail(&agg->list, next);
+ }
+ }
+
+ if (!list_empty(&rx_queue)) {
+ spin_lock_irqsave(&tp->rx_lock, flags);
+ list_splice_tail(&rx_queue, &tp->rx_done);
+ spin_unlock_irqrestore(&tp->rx_lock, flags);
}
out1:
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 6/7] r8152: replace get_protocol with vlan_get_protocol
vlan_get_protocol() has been defined and use it to replace
get_protocol().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f66ffbd..46440ed 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1342,18 +1342,6 @@ static struct tx_agg *r8152_get_tx_agg(struct r8152 *tp)
return agg;
}
-static inline __be16 get_protocol(struct sk_buff *skb)
-{
- __be16 protocol;
-
- if (skb->protocol == htons(ETH_P_8021Q))
- protocol = vlan_eth_hdr(skb)->h_vlan_encapsulated_proto;
- else
- protocol = skb->protocol;
-
- return protocol;
-}
-
/* r8152_csum_workaround()
* The hw limites the value the transport offset. When the offset is out of the
* range, calculate the checksum by sw.
@@ -1459,7 +1447,7 @@ static int r8152_tx_csum(struct r8152 *tp, struct tx_desc
*desc,
goto unavailable;
}
- switch (get_protocol(skb)) {
+ switch (vlan_get_protocol(skb)) {
case htons(ETH_P_IP):
opts1 |= GTSENDV4;
break;
@@ -1490,7 +1478,7 @@ static int r8152_tx_csum(struct r8152 *tp, struct tx_desc
*desc,
goto unavailable;
}
- switch (get_protocol(skb)) {
+ switch (vlan_get_protocol(skb)) {
case htons(ETH_P_IP):
opts2 |= IPV4_CS;
ip_protocol = ip_hdr(skb)->protocol;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 7/7] r8152: use BIT macro
Use BIT macro to replace (1 << bits).
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 46440ed..c3a0224 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -489,16 +489,16 @@ struct rx_desc {
#define RX_LEN_MASK0x7fff
__le32 opts2;
-#define RD_UDP_CS (1 << 23)
-#define RD_TCP_CS (1 << 22)
-#define RD_IPV6_CS (1 << 20)
-#define RD_IPV4_CS (1 << 19)
+#define RD_UDP_CS BIT(23)
+#define RD_TCP_CS BIT(22)
+#define RD_IPV6_CS BIT(20)
+#define RD_IPV4_CS BIT(19)
__le32 opts3;
-#define IPF(1 << 23) /* IP checksum fail */
-#define UDPF (1 << 22) /* UDP checksum fail */
-#define TCPF (1 << 21) /* TCP checksum fail */
-#define RX_VLAN_TAG(1 << 16)
+#define IPFBIT(23) /* IP checksum fail */
+#define UDPF BIT(22) /* UDP checksum fail */
+#define TCPF BIT(21) /* TCP checksum fail */
+#define RX_VLAN_TAGBIT(16)
__le32 opts4;
__le32 opts5;
@@ -507,24 +507,24 @@ struct rx_desc {
struct tx_desc {
__le32 opts1;
-#define TX_FS (1 << 31) /* First segment of a packet */
-#define TX_LS (1 << 30) /* Final segment of a packet */
-#define GTSENDV4 (1 << 28)
-#define GTSENDV6 (1 << 27)
+#define TX_FS BIT(31) /* First segment of a packet */
+#define TX_LS BIT(30) /* Final segment of a packet */
+#define GTSENDV4 BIT(28)
+#define GTSENDV6 BIT(27)
#define GTTCPHO_SHIFT 18
#define GTTCPHO_MAX0x7fU
#define TX_LEN_MAX 0x3U
__le32 opts2;
-#define UDP_CS (1 << 31) /* Calculate UDP/IP checksum */
-#define TCP_CS (1 << 30) /* Calculate TCP/IP checksum */
-#define IPV4_CS(1 << 29) /* Calculate IPv4 checksum */
-#define IPV6_CS(1 << 28) /* Calculate IPv6 checksum */
+#define UDP_CS BIT(31) /* Calculate UDP/IP checksum */
+#define TCP_CS BIT(30) /* Calculate TCP/IP checksum */
+#define IPV4_CSBIT(29) /* Calculate IPv4 checksum */
+#define IPV6_CSBIT(28) /* Calculate IPv6 checksum */
#define MSS_SHIFT 17
#define MSS_MAX0x7ffU
#define TCPHO_SHIFT17
#define TCPHO_MAX 0x7ffU
-#define TX_VLAN_TAG(1 << 16)
+#define TX_VLAN_TAGBIT(16)
};
struct r8152;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] HID: hid-lg4ff: fix sysfs attribute permission
There is no reason to set the range attribute executable to the user and
group, and writable to the group. Fix the permission to 0644.
Signed-off-by: Vivien Didelot
---
drivers/hid/hid-lg4ff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index 7835717..4b668bf 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -52,7 +52,8 @@ static void hid_lg4ff_set_range_g25(struct hid_device *hid,
u16 range);
static ssize_t lg4ff_range_show(struct device *dev, struct device_attribute
*attr, char *buf);
static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute
*attr, const char *buf, size_t count);
-static DEVICE_ATTR(range, S_IRWXU | S_IRWXG | S_IROTH, lg4ff_range_show,
lg4ff_range_store);
+static DEVICE_ATTR(range, S_IRUGO | S_IWUSR, lg4ff_range_show,
+ lg4ff_range_store);
struct lg4ff_device_entry {
__u32 product_id;
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] HID: hid-lg4ff: use DEVICE_ATTR_RW macro
Use the DEVICE_ATTR_RW macro to reduce boiler plate and move the
attribute declaration to get rid of function signatures.
Signed-off-by: Vivien Didelot
---
drivers/hid/hid-lg4ff.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index 4b668bf..db0dd9b 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -49,11 +49,6 @@
static void hid_lg4ff_set_range_dfp(struct hid_device *hid, u16 range);
static void hid_lg4ff_set_range_g25(struct hid_device *hid, u16 range);
-static ssize_t lg4ff_range_show(struct device *dev, struct device_attribute
*attr, char *buf);
-static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute
*attr, const char *buf, size_t count);
-
-static DEVICE_ATTR(range, S_IRUGO | S_IWUSR, lg4ff_range_show,
- lg4ff_range_store);
struct lg4ff_device_entry {
__u32 product_id;
@@ -417,7 +412,8 @@ static void hid_lg4ff_switch_native(struct hid_device *hid,
const struct lg4ff_n
}
/* Read current range and display it in terminal */
-static ssize_t lg4ff_range_show(struct device *dev, struct device_attribute
*attr, char *buf)
+static ssize_t range_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct hid_device *hid = to_hid_device(dev);
struct lg4ff_device_entry *entry;
@@ -442,7 +438,8 @@ static ssize_t lg4ff_range_show(struct device *dev, struct
device_attribute *att
/* Set range to user specified value, call appropriate function
* according to the type of the wheel */
-static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute
*attr, const char *buf, size_t count)
+static ssize_t range_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
{
struct hid_device *hid = to_hid_device(dev);
struct lg4ff_device_entry *entry;
@@ -473,6 +470,7 @@ static ssize_t lg4ff_range_store(struct device *dev, struct
device_attribute *at
return count;
}
+static DEVICE_ATTR_RW(range);
#ifdef CONFIG_LEDS_CLASS
static void lg4ff_set_leds(struct hid_device *hid, __u8 leds)
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CMA: treat free cma pages as non-free if not ALLOC_CMA on watermark checking
Hello,
On Sun, Jan 18, 2015 at 04:32:59PM +0800, Hui Zhu wrote:
> From: Hui Zhu
>
> The original of this patch [1] is part of Joonsoo's CMA patch series.
> I made a patch [2] to fix the issue of this patch. Joonsoo reminded me
> that this issue affect current kernel too. So made a new one for upstream.
Recently, we found many problems of CMA and Joonsoo tried to add more
hooks into MM like agressive allocation but I suggested adding new zone
would be more desirable than more hooks in mm fast path in various aspect.
(ie, remove lots of hooks in hot path of MM, don't need reclaim hooks
for special CMA pages, don't need custom fair allocation for CMA).
Joonsoo is investigating the direction so please wait.
If it turns out we have lots of hurdle to go that way,
this direction(ie, putting more hooks) should be second plan.
Thanks.
>
> Current code treat free cma pages as non-free if not ALLOC_CMA in the first
> check:
> if (free_pages - free_cma <= min + z->lowmem_reserve[classzone_idx])
> return false;
> But in the loop after that, it treat free cma pages as free memory even
> if not ALLOC_CMA.
> So this one substruct free_cma from free_pages before the loop if not
> ALLOC_CMA to treat free cma pages as non-free in the loop.
>
> But there still have a issue is that CMA memory in each order is part
> of z->free_area[o].nr_free, then the CMA page number of this order is
> substructed twice. This bug will make __zone_watermark_ok return more false.
> This patch add cma_nr_free to struct free_area that just record the number
> of CMA pages. And add it back in the order loop to handle the substruct
> twice issue.
>
> The last issue of this patch should handle is pointed by Joonsoo in [3].
> If pageblock for CMA is isolated, cma_nr_free would be miscalculated.
> This patch add two functions nr_free_inc and nr_free_dec to change the
> values of nr_free and cma_nr_free. If the migratetype is MIGRATE_ISOLATE,
> they will not change the value of nr_free.
> Change __mod_zone_freepage_state to doesn't record isolated page to
> NR_FREE_PAGES.
> And add code to move_freepages to record the page number that isolated:
> if (is_migrate_isolate(migratetype))
> nr_free_dec(&zone->free_area[order],
> get_freepage_migratetype(page));
> else
> nr_free_inc(&zone->free_area[order], migratetype);
> Then the isolate issue is handled.
>
> This patchset is based on fc7f0dd381720ea5ee5818645f7d0e9dece41cb0.
>
> [1] https://lkml.org/lkml/2014/5/28/110
> [2] https://lkml.org/lkml/2014/12/25/43
> [3] https://lkml.org/lkml/2015/1/4/220
>
> Signed-off-by: Joonsoo Kim
> Signed-off-by: Hui Zhu
> Signed-off-by: Weixing Liu
> ---
> include/linux/mmzone.h | 3 +++
> include/linux/vmstat.h | 4 +++-
> mm/page_alloc.c| 59
> +-
> 3 files changed, 55 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 2f0856d..094476b 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -92,6 +92,9 @@ static inline int get_pfnblock_migratetype(struct page
> *page, unsigned long pfn)
> struct free_area {
> struct list_headfree_list[MIGRATE_TYPES];
> unsigned long nr_free;
> +#ifdef CONFIG_CMA
> + unsigned long cma_nr_free;
> +#endif
> };
>
> struct pglist_data;
> diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
> index 82e7db7..f18ef00 100644
> --- a/include/linux/vmstat.h
> +++ b/include/linux/vmstat.h
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> extern int sysctl_stat_interval;
> @@ -280,7 +281,8 @@ static inline void drain_zonestat(struct zone *zone,
> static inline void __mod_zone_freepage_state(struct zone *zone, int nr_pages,
>int migratetype)
> {
> - __mod_zone_page_state(zone, NR_FREE_PAGES, nr_pages);
> + if (!is_migrate_isolate(migratetype))
> + __mod_zone_page_state(zone, NR_FREE_PAGES, nr_pages);
> if (is_migrate_cma(migratetype))
> __mod_zone_page_state(zone, NR_FREE_CMA_PAGES, nr_pages);
> }
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7633c50..9a2b6da 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -576,6 +576,28 @@ static inline int page_is_buddy(struct page *page,
> struct page *buddy,
> return 0;
> }
>
> +static inline void nr_free_inc(struct free_area *area, int migratetype)
> +{
> + if (!is_migrate_isolate(migratetype))
> + area->nr_free++;
> +
> +#ifdef CONFIG_CMA
> + if (is_migrate_cma(migratetype))
> + area->cma_nr_free++;
> +#endif
> +}
> +
> +static inline void nr_free_dec(struct free_area *area, int migratetype)
> +{
> + if (!is_migrate_isolate(migratetype))
> + area->nr_free--;
> +
> +#ifdef CONFIG_CMA
> +
[PATCH v5] tty: serial: men_z135_uart: Fix driver for changes in hardware
16z135 IP Core has changed so the driver needs to be updated to respect
these changes. The following changes have been made:
* Don't invert the 16z135 modem status register when reading.
* Add module parameter to configure the (baud rate dependent) RX timeout.
Character timeout in seconds = (timeout_reg * baud_reg * 4)/freq_reg.
* Enable the handling of UART core's automatic flow control feature.
When AFE is active disable generation of modem status IRQs.
* Rework the handling of IRQs to be conform with newer FPGA versions and
take precautions not to miss an interrupt because of the destructive read
of the IIR register.
* Correct men_z135_handle_modem_status(), MSR is stat_reg[15:8] not
stat_reg[7:0]
* Correct calling of uart_handle_{dcd,cts}_change()
* Reset CLOCAL when CRTSCTS is set
Signed-off-by: Johannes Thumshirn
---
Changes to v1:
Incorporated comments of Jiri Slaby:
* Timeout value is documented in module parameter description
* rx_timeout variable is uint
* Changed IRQ handled variable to bool
* Changed if statement for RDA or CTI IRQ
Changes to v2:
* Correct men_z135_handle_modem_status(), MSR is stat_reg[15:8] not
stat_reg[7:0]
Changes to v3:
* Correct calling of uart_handle_{dcd,cts}_change()
* Correct handling of hardware's automode
Changes to v4:
* Reset CLOCAL when CRTSCTS is set (suggested by Peter Hurley)
drivers/tty/serial/men_z135_uart.c | 155 ++---
1 file changed, 109 insertions(+), 46 deletions(-)
diff --git a/drivers/tty/serial/men_z135_uart.c
b/drivers/tty/serial/men_z135_uart.c
index 517cd07..35c5550 100644
--- a/drivers/tty/serial/men_z135_uart.c
+++ b/drivers/tty/serial/men_z135_uart.c
@@ -23,7 +23,6 @@
#define MEN_Z135_MAX_PORTS 12
#define MEN_Z135_BASECLK 29491200
#define MEN_Z135_FIFO_SIZE 1024
-#define MEN_Z135_NUM_MSI_VECTORS 2
#define MEN_Z135_FIFO_WATERMARK1020
#define MEN_Z135_STAT_REG 0x0
@@ -34,12 +33,11 @@
#define MEN_Z135_CONF_REG 0x808
#define MEN_Z135_UART_FREQ 0x80c
#define MEN_Z135_BAUD_REG 0x810
-#define MENZ135_TIMEOUT0x814
+#define MEN_Z135_TIMEOUT 0x814
#define MEN_Z135_MEM_SIZE 0x818
-#define IS_IRQ(x) ((x) & 1)
-#define IRQ_ID(x) (((x) >> 1) & 7)
+#define IRQ_ID(x) ((x) & 0x1f)
#define MEN_Z135_IER_RXCIEN BIT(0) /* RX Space IRQ */
#define MEN_Z135_IER_TXCIEN BIT(1) /* TX Space IRQ */
@@ -94,11 +92,11 @@
#define MEN_Z135_LSR_TEXP BIT(6)
#define MEN_Z135_LSR_RXFIFOERR BIT(7)
-#define MEN_Z135_IRQ_ID_MST 0
-#define MEN_Z135_IRQ_ID_TSA 1
-#define MEN_Z135_IRQ_ID_RDA 2
-#define MEN_Z135_IRQ_ID_RLS 3
-#define MEN_Z135_IRQ_ID_CTI 6
+#define MEN_Z135_IRQ_ID_RLS BIT(0)
+#define MEN_Z135_IRQ_ID_RDA BIT(1)
+#define MEN_Z135_IRQ_ID_CTI BIT(2)
+#define MEN_Z135_IRQ_ID_TSA BIT(3)
+#define MEN_Z135_IRQ_ID_MST BIT(4)
#define LCR(x) (((x) >> MEN_Z135_LCR_SHIFT) & 0xff)
@@ -118,12 +116,18 @@ static int align;
module_param(align, int, S_IRUGO);
MODULE_PARM_DESC(align, "Keep hardware FIFO write pointer aligned, default 0");
+static uint rx_timeout;
+module_param(rx_timeout, uint, S_IRUGO);
+MODULE_PARM_DESC(rx_timeout, "RX timeout. "
+ "Timeout in seconds = (timeout_reg * baud_reg * 4) / freq_reg");
+
struct men_z135_port {
struct uart_port port;
struct mcb_device *mdev;
unsigned char *rxbuf;
u32 stat_reg;
spinlock_t lock;
+ bool automode;
};
#define to_men_z135(port) container_of((port), struct men_z135_port, port)
@@ -180,12 +184,16 @@ static inline void men_z135_reg_clr(struct men_z135_port
*uart,
*/
static void men_z135_handle_modem_status(struct men_z135_port *uart)
{
- if (uart->stat_reg & MEN_Z135_MSR_DDCD)
+ u8 msr;
+
+ msr = (uart->stat_reg >> 8) & 0xff;
+
+ if (msr & MEN_Z135_MSR_DDCD)
uart_handle_dcd_change(&uart->port,
- uart->stat_reg & ~MEN_Z135_MSR_DCD);
- if (uart->stat_reg & MEN_Z135_MSR_DCTS)
+ msr & MEN_Z135_MSR_DCD);
+ if (msr & MEN_Z135_MSR_DCTS)
uart_handle_cts_change(&uart->port,
- uart->stat_reg & ~MEN_Z135_MSR_CTS);
+ msr & MEN_Z135_MSR_CTS);
}
static void men_z135_handle_lsr(struct men_z135_port *uart)
@@ -322,7 +330,8 @@ static void men_z135_handle_tx(struct men_z135_port *uart)
txfree = MEN_Z135_FIFO_WATERMARK - txc;
if (txfree <= 0) {
- pr_err("Not enough room in TX FIFO have %d, need %d\n",
+ dev_err(&uart->mdev->dev,
+ "Not enough room in TX FIFO have %d, need %d\n",
txfree, qlen);
goto irq_en;
}
@@ -373,43 +382,54 @@ out:
* @irq: The IRQ number
* @data: Pointer to UART port
*
- * Check IIR register to
does the semantics of MAP_LOCKED is equal to mlock() function?
Hi all: In the latest kernel, i set the memory limit (4096) in a test cgroup. and add the test task. the test code code is: testcase 1: mmap with MAP_LOCKED flag(memsize = 8192) 185 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ, 186 MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, 0, 0); 187 if (p == MAP_FAILED) 188 err(1, "mmap(lock) failed"); expect: invoke OOM killer. result: not invoke OOM killer. testcase 2: mmap without MAP_LOCKED flag and the call mlock (memsize = 8192) 185 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ, 186 MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); 187 if (p == MAP_FAILED) 188 err(1, "mmap(lock) failed"); 189 190 if (mlock(p, memsize) == -1) 191 err(1, "mlock failed") expect: invoke OOM killer. result: invoke OOM killer. in the Linux Programmer's Manual: MAP_LOCKED (since Linux 2.5.37) Lock the pages of the mapped region into memory in the manner of mlock(2). This flag is ignored in older kernels. and mlock() locks pages in the address range starting at addr and continuing for len bytes. All pages that contain a part of the specified address range are guaranteed to be resident in RAM when the call returns successfully; the pages are guaranteed to stay in RAM until later unlocked. According to the description in the manual, the two testcases are equivalent. why the first testcase does not invoke OOM killer? does the mmap with MAP_LOCKED flag will not immediately allocate physical memory? Best Regards Wang Long -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmotm 2015-01-16-15-50 uploaded
On Fri, Jan 16, 2015 at 10:40:23PM -0800, Guenter Roeck wrote: > On Fri, Jan 16, 2015 at 03:50:38PM -0800, a...@linux-foundation.org wrote: > > The mm-of-the-moment snapshot 2015-01-16-15-50 has been uploaded to > > > >http://www.ozlabs.org/~akpm/mmotm/ > > > > mmotm-readme.txt says > > > > README for mm-of-the-moment: > > > > http://www.ozlabs.org/~akpm/mmotm/ > > > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > > more than once a week. > > > > This version is a bit worse than usual. > > Build results: > total: 133 pass: 113 fail: 20 > Failed builds: > alpha:defconfig > alpha:allmodconfig > m32r:defconfig > m68k:defconfig > m68k:allmodconfig > m68k:sun3_defconfig > m68k:m5475evb_defconfig > microblaze:mmu_defconfig > mips:allmodconfig > parisc:defconfig > parisc:generic-32bit_defconfig > parisc:a500_defconfig > parisc:generic-64bit_defconfig > powerpc:cell_defconfig > powerpc:mpc85xx_defconfig > powerpc:mpc85xx_smp_defconfig > powerpc:cell_defconfig > powerpc:mpc85xx_defconfig > powerpc:mpc85xx_smp_defconfig > sparc32:defconfig > Qemu tests: > total: 30 pass: 18 fail: 12 > Failed tests: > alpha:alpha_defconfig > microblaze:microblaze_defconfig > microblaze:microblazeel_defconfig > mips:mips_malta_smp_defconfig > mips64:mips_malta64_smp_defconfig > powerpc:ppc_book3s_smp_defconfig > powerpc:ppc64_book3s_smp_defconfig > sh:sh_defconfig > sparc32:sparc_defconfig > sparc32:sparc_smp_defconfig > x86:x86_pc_defconfig > x86_64:x86_64_pc_defconfig > > Details are available at http://server.roeck-us.net:8010/builders; look for > the > 'mmotm' logs. > > Patches identified as bad by bisect (see below for bisect logs): > > 3ecd42e200dc mm/hugetlb: reduce arch dependent code around follow_huge_* > c824a9dc5e88 mm: account pmd page tables to the process > 825e778f321e mm/slub: optimize alloc/free fastpath by removing preemption > on/off Hello, I sent the fix for testing failure due to 825e778f321e. https://lkml.org/lkml/2015/1/19/17 It would fix this testing failure. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] mm: don't use compound_head() in virt_to_head_page()
On Thu, Jan 15, 2015 at 05:16:46PM -0800, Andrew Morton wrote:
> On Thu, 15 Jan 2015 16:40:33 +0900 Joonsoo Kim wrote:
>
> > compound_head() is implemented with assumption that there would be
> > race condition when checking tail flag. This assumption is only true
> > when we try to access arbitrary positioned struct page.
> >
> > The situation that virt_to_head_page() is called is different case.
> > We call virt_to_head_page() only in the range of allocated pages,
> > so there is no race condition on tail flag. In this case, we don't
> > need to handle race condition and we can reduce overhead slightly.
> > This patch implements compound_head_fast() which is similar with
> > compound_head() except tail flag race handling. And then,
> > virt_to_head_page() uses this optimized function to improve performance.
> >
> > I saw 1.8% win in a fast-path loop over kmem_cache_alloc/free,
> > (14.063 ns -> 13.810 ns) if target object is on tail page.
> >
> > ...
> >
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -453,6 +453,13 @@ static inline struct page *compound_head(struct page
> > *page)
> > return page;
> > }
> >
> > +static inline struct page *compound_head_fast(struct page *page)
> > +{
> > + if (unlikely(PageTail(page)))
> > + return page->first_page;
> > + return page;
> > +}
>
> Can we please have some code comments which let people know when they
> should and shouldn't use compound_head_fast()? I shouldn't have to say
> this :(
Okay.
>
> > /*
> > * The atomic page->_mapcount, starts from -1: so that transitions
> > * both from it and to it can be tracked, using atomic_inc_and_test
> > @@ -531,7 +538,8 @@ static inline void get_page(struct page *page)
> > static inline struct page *virt_to_head_page(const void *x)
> > {
> > struct page *page = virt_to_page(x);
> > - return compound_head(page);
> > +
> > + return compound_head_fast(page);
>
> And perhaps some explanation here as to why virt_to_head_page() can
> safely use compound_head_fast(). There's an assumption here that
> nobody will be dismantling the compound page while virt_to_head_page()
> is in progress, yes? And this assumption also holds for the calling
> code, because otherwise the virt_to_head_page() return value is kinda
> meaningless.
>
> This is tricky stuff - let's spell it out carefully.
Okay.
I already sent v3 and it would have proper code comments.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/5] mm/compaction: enhance tracepoint output for compaction begin/end
On Thu, Jan 15, 2015 at 05:16:27PM -0800, Andrew Morton wrote:
> On Thu, 15 Jan 2015 16:41:10 +0900 Joonsoo Kim wrote:
>
> > We now have tracepoint for begin event of compaction and it prints
> > start position of both scanners, but, tracepoint for end event of
> > compaction doesn't print finish position of both scanners. It'd be
> > also useful to know finish position of both scanners so this patch
> > add it. It will help to find odd behavior or problem on compaction
> > internal logic.
> >
> > And, mode is added to both begin/end tracepoint output, since
> > according to mode, compaction behavior is quite different.
> >
> > And, lastly, status format is changed to string rather than
> > status number for readability.
> >
> > ...
> >
> > + TP_printk("zone_start=0x%lx migrate_pfn=0x%lx free_pfn=0x%lx
> > zone_end=0x%lx, mode=%s status=%s",
> > + __entry->zone_start,
> > + __entry->migrate_pfn,
> > + __entry->free_pfn,
> > + __entry->zone_end,
> > + __entry->sync ? "sync" : "async",
> > + compaction_status_string[__entry->status])
> > );
> >
> > #endif /* _TRACE_COMPACTION_H */
> > diff --git a/mm/compaction.c b/mm/compaction.c
> > index 546e571..2d86a20 100644
> > --- a/mm/compaction.c
> > +++ b/mm/compaction.c
> > @@ -19,6 +19,14 @@
> > #include "internal.h"
> >
> > #ifdef CONFIG_COMPACTION
> > +char *compaction_status_string[] = {
> > + "deferred",
> > + "skipped",
> > + "continue",
> > + "partial",
> > + "complete",
> > +};
>
> compaction_status_string[] is unreferenced if tracing is disabled -
> more ifdeffery is needed?
Hello,
Yes, I sent fixed version patchset, v4, a while ago.
And, there is some build failure reports from kbuild test bot so please
take v4 rather than v3.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/5] mm/compaction: print current range where compaction work
It'd be useful to know current range where compaction work for detailed
analysis. With it, we can know pageblock where we actually scan and
isolate, and, how much pages we try in that pageblock and can guess why
it doesn't become freepage with pageblock order roughly.
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
---
include/trace/events/compaction.h | 30 +++---
mm/compaction.c |9 ++---
2 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/include/trace/events/compaction.h
b/include/trace/events/compaction.h
index 839f6fa..139020b 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -11,39 +11,55 @@
DECLARE_EVENT_CLASS(mm_compaction_isolate_template,
- TP_PROTO(unsigned long nr_scanned,
+ TP_PROTO(
+ unsigned long start_pfn,
+ unsigned long end_pfn,
+ unsigned long nr_scanned,
unsigned long nr_taken),
- TP_ARGS(nr_scanned, nr_taken),
+ TP_ARGS(start_pfn, end_pfn, nr_scanned, nr_taken),
TP_STRUCT__entry(
+ __field(unsigned long, start_pfn)
+ __field(unsigned long, end_pfn)
__field(unsigned long, nr_scanned)
__field(unsigned long, nr_taken)
),
TP_fast_assign(
+ __entry->start_pfn = start_pfn;
+ __entry->end_pfn = end_pfn;
__entry->nr_scanned = nr_scanned;
__entry->nr_taken = nr_taken;
),
- TP_printk("nr_scanned=%lu nr_taken=%lu",
+ TP_printk("range=(0x%lx ~ 0x%lx) nr_scanned=%lu nr_taken=%lu",
+ __entry->start_pfn,
+ __entry->end_pfn,
__entry->nr_scanned,
__entry->nr_taken)
);
DEFINE_EVENT(mm_compaction_isolate_template,
mm_compaction_isolate_migratepages,
- TP_PROTO(unsigned long nr_scanned,
+ TP_PROTO(
+ unsigned long start_pfn,
+ unsigned long end_pfn,
+ unsigned long nr_scanned,
unsigned long nr_taken),
- TP_ARGS(nr_scanned, nr_taken)
+ TP_ARGS(start_pfn, end_pfn, nr_scanned, nr_taken)
);
DEFINE_EVENT(mm_compaction_isolate_template, mm_compaction_isolate_freepages,
- TP_PROTO(unsigned long nr_scanned,
+
+ TP_PROTO(
+ unsigned long start_pfn,
+ unsigned long end_pfn,
+ unsigned long nr_scanned,
unsigned long nr_taken),
- TP_ARGS(nr_scanned, nr_taken)
+ TP_ARGS(start_pfn, end_pfn, nr_scanned, nr_taken)
);
TRACE_EVENT(mm_compaction_migratepages,
diff --git a/mm/compaction.c b/mm/compaction.c
index f32d456..70af2b1 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -430,11 +430,12 @@ isolate_fail:
}
+ trace_mm_compaction_isolate_freepages(*start_pfn, blockpfn,
+ nr_scanned, total_isolated);
+
/* Record how far we have got within the block */
*start_pfn = blockpfn;
- trace_mm_compaction_isolate_freepages(nr_scanned, total_isolated);
-
/*
* If strict isolation is requested by CMA then check that all the
* pages requested were isolated. If there were any failures, 0 is
@@ -590,6 +591,7 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
unsigned long flags = 0;
bool locked = false;
struct page *page = NULL, *valid_page = NULL;
+ unsigned long start_pfn = low_pfn;
/*
* Ensure that there are not too many pages isolated from the LRU
@@ -750,7 +752,8 @@ isolate_success:
if (low_pfn == end_pfn)
update_pageblock_skip(cc, valid_page, nr_isolated, true);
- trace_mm_compaction_isolate_migratepages(nr_scanned, nr_isolated);
+ trace_mm_compaction_isolate_migratepages(start_pfn, low_pfn,
+ nr_scanned, nr_isolated);
count_compact_events(COMPACTMIGRATE_SCANNED, nr_scanned);
if (nr_isolated)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/5] mm/compaction: more trace to understand when/why compaction start/finish
It is not well analyzed that when/why compaction start/finish or not. With
these new tracepoints, we can know much more about start/finish reason of
compaction. I can find following bug with these tracepoint.
http://www.spinics.net/lists/linux-mm/msg81582.html
Change from v2: omit alloc_flag, classzone_idx from tracepoint output
Signed-off-by: Joonsoo Kim
---
include/linux/compaction.h|3 ++
include/trace/events/compaction.h | 74 +
mm/compaction.c | 38 +--
3 files changed, 111 insertions(+), 4 deletions(-)
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index 9363c08..648d183 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -12,6 +12,9 @@
#define COMPACT_PARTIAL3
/* The full zone was compacted */
#define COMPACT_COMPLETE 4
+/* For more detailed tracepoint output */
+#define COMPACT_NO_SUITABLE_PAGE 5
+#define COMPACT_NOT_SUITABLE_ZONE 6
/* When adding new state, please change compaction_status_string, too */
/* Used to signal whether compaction detected need_sched() or lock contention
*/
diff --git a/include/trace/events/compaction.h
b/include/trace/events/compaction.h
index 139020b..d465358 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -164,6 +164,80 @@ TRACE_EVENT(mm_compaction_end,
compaction_status_string[__entry->status])
);
+TRACE_EVENT(mm_compaction_try_to_compact_pages,
+
+ TP_PROTO(
+ int order,
+ gfp_t gfp_mask,
+ enum migrate_mode mode),
+
+ TP_ARGS(order, gfp_mask, mode),
+
+ TP_STRUCT__entry(
+ __field(int, order)
+ __field(gfp_t, gfp_mask)
+ __field(enum migrate_mode, mode)
+ ),
+
+ TP_fast_assign(
+ __entry->order = order;
+ __entry->gfp_mask = gfp_mask;
+ __entry->mode = mode;
+ ),
+
+ TP_printk("order=%d gfp_mask=0x%x mode=%d",
+ __entry->order,
+ __entry->gfp_mask,
+ (int)__entry->mode)
+);
+
+DECLARE_EVENT_CLASS(mm_compaction_suitable_template,
+
+ TP_PROTO(struct zone *zone,
+ int order,
+ int ret),
+
+ TP_ARGS(zone, order, ret),
+
+ TP_STRUCT__entry(
+ __field(int, nid)
+ __field(char *, name)
+ __field(int, order)
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ __entry->nid = zone_to_nid(zone);
+ __entry->name = (char *)zone->name;
+ __entry->order = order;
+ __entry->ret = ret;
+ ),
+
+ TP_printk("node=%d zone=%-8s order=%d ret=%s",
+ __entry->nid,
+ __entry->name,
+ __entry->order,
+ compaction_status_string[__entry->ret])
+);
+
+DEFINE_EVENT(mm_compaction_suitable_template, mm_compaction_finished,
+
+ TP_PROTO(struct zone *zone,
+ int order,
+ int ret),
+
+ TP_ARGS(zone, order, ret)
+);
+
+DEFINE_EVENT(mm_compaction_suitable_template, mm_compaction_suitable,
+
+ TP_PROTO(struct zone *zone,
+ int order,
+ int ret),
+
+ TP_ARGS(zone, order, ret)
+);
+
#endif /* _TRACE_COMPACTION_H */
/* This part must be outside protection */
diff --git a/mm/compaction.c b/mm/compaction.c
index 70af2b1..8248a53 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -41,6 +41,8 @@ static const char const *compaction_status_string[] = {
"continue",
"partial",
"complete",
+ "no_suitable_page",
+ "not_suitable_zone",
};
#endif
@@ -1049,7 +1051,7 @@ static isolate_migrate_t isolate_migratepages(struct zone
*zone,
return cc->nr_migratepages ? ISOLATE_SUCCESS : ISOLATE_NONE;
}
-static int compact_finished(struct zone *zone, struct compact_control *cc,
+static int __compact_finished(struct zone *zone, struct compact_control *cc,
const int migratetype)
{
unsigned int order;
@@ -1104,7 +1106,20 @@ static int compact_finished(struct zone *zone, struct
compact_control *cc,
return COMPACT_PARTIAL;
}
- return COMPACT_CONTINUE;
+ return COMPACT_NO_SUITABLE_PAGE;
+}
+
+static int compact_finished(struct zone *zone, struct compact_control *cc,
+ const int migratetype)
+{
+ int ret;
+
+ ret = __compact_finished(zone, cc, migratetype);
+ trace_mm_compaction_finished(zone, cc->order, ret);
+ if (ret == COMPACT_NO_SUITABLE_PAGE)
+ ret = COMPACT_CONTINUE;
+
+ return ret;
}
/*
@@ -1114,7 +1129,7 @@ static int compact_finished(struct zone *zone, struct
compact_control *cc,
* COMPACT_PARTIAL - If the allocation would succeed without compaction
* C
Re: Query: ARM64: Behavior of el1_dbg exception while executing el0_dbg
On Friday 16 January 2015 09:52 PM, Will Deacon wrote: On Fri, Jan 16, 2015 at 12:00:09PM +, Pratyush Anand wrote: On Thursday 15 January 2015 10:17 PM, Pratyush Anand wrote: On Tuesday 13 January 2015 11:23 PM, Pratyush Anand wrote: I will still try to find some way to capture enable_dbg macro path.H I did instrumented debug tap points at all the location from where enable_debug macro is called(see attached debug patch). But, I do not see that, execution reaches to any of those tap points between el0_dbg and el1_dbg, and tap points debug log also confirms that el1_dbg is raised before el0_dbg is returned. Probably we all missed this, ARMv8 specs is very clear about it. In section "D2.1 About debug exceptions" it says: Software Breakpoint Instruction exceptions cannot be masked. The PE takes Software Breakpoint Instruction exceptions regardless of both of the following: • The current Exception level. • The current Security state. Ah, of course, I completely forgot you were using software breakpoints! So, reception of el1_dbg while executing el0_dbg seems perfectly normal to me. If you agree then I am back with the original query which I asked in the beginning of the thread,(http://permalink.gmane.org/gmane.linux.ports.arm.kernel/383672) ie how can instruction_pointer be wrong when second el1_dbg is called recursively(as follows). [1]-> el0_dbg (After executing BRK instruction by user) [2] -> el1_dbg (when uprobe break handler at [1] executes BRK instruction) (At the end of this ELR_EL1 is programmed with fdfffc04) [3] -> el1_dbg (when kprobe break handler at [2] enables single stepping) (Here ELR_EL1 was found fe092470).So When this el1_dbg was received, then regs->pc values are not same what was programmed in ELR_EL1 at the return of [2]. Perhaps you're not removing the BRK instruction properly, and so you try to single-step a trapping instruction and end up stepping into the exception? No, probably that is not the scenario. One thing I agree, that even if AARCH64 specs says that SW BRK exception can not be masked, current kernel code is not ready to handle re-entrant software debug exception. So, I will keep those part of uprobe code as non-kprobable, and then its not so important to get into it for code development perspective. However, it would be good to understand that what went wrong and caused to receive an el1_inval. I still fail to pin point the reason of current issue and its not single stepping a trapping instruction (BRK). Sorry, but please have a relook at the sequence of events: 1. 1st instruction of uprobe_breakpoint_handler is: ffc00059a628: a9bf7bfdstp x29, x30, [sp,#-16]! which is replaced by BRK64_OPCODE_KPROBES = 0xD4200080, when Kprobe is instrumented. 2. User instruction at address 0x4005d0 is replaced by BRK64_OPCODE_UPROBES = 0xD4200100, when uprobe is instrumented. 3. When application executes instruction at 0x4005d0,we receive el0_dbg. 4. In el0_dbg handler we execute kernel code at address ffc00059a628, so el1_dbg is raised. (I agree here that el0_dbg has not been closed properly, which current entry.S code expects, so we will need to fix it if we consensus to support re-entrant software debug exception, how ever the issue which I see seems unrelated, so...) 5. Now in el1_dbg, we handle kprobe_breakpoint_handler, where we write saved instruction (ie a9bf7bfdstp x29, x30, [sp,#-16]!) to the kmalloc allocated address fdfffc04. kprobe code does flush_icache_range on this location. regs->pc is set to fdfffc04, so elr_el1 is programmed with fdfffc04 during kernel_exit. I have cross checked elr_el1 value just before eret is executed in kernel_exit, and it is correct. So, here we are trying to single step a STP instruction and not BRK instruction. 6. Here I am expecting a single step exception, but I receive a el1_inv with ESR_EL1(0x8607) ie EC as "ESR_EL1_EC_IABT_EL1" and IFSC as "Translation fault, third level". WHY As soon as enable_dbg is called in el1_inv, we receive next single step exception, with ELR_EL1 value as next instruction address after enable_dbg of el1_inv. Had we received single step instead of el1_inv with correct elr_el1, kprobe_single_step_handler would have executed properly and we would have come back to address ffc00059a62C (2nd instruction of uprobe_breakpoint_handler) after returning from this kprobe single step handler. [off-course fix would be needed to correctly come back to this address and then also for returning to user space] ~Pratyush -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/5] mm/compaction: enhance tracepoint output for compaction begin/end
We now have tracepoint for begin event of compaction and it prints
start position of both scanners, but, tracepoint for end event of
compaction doesn't print finish position of both scanners. It'd be
also useful to know finish position of both scanners so this patch
add it. It will help to find odd behavior or problem on compaction
internal logic.
And, mode is added to both begin/end tracepoint output, since
according to mode, compaction behavior is quite different.
And, lastly, status format is changed to string rather than
status number for readability.
Changes from v3: Build fix for !CONFIG_COMPACTION, !CONFIG_TRACEPOINTS
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
---
include/linux/compaction.h|1 +
include/trace/events/compaction.h | 49 ++---
mm/compaction.c | 15 ++--
3 files changed, 49 insertions(+), 16 deletions(-)
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index 3238ffa..9363c08 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -12,6 +12,7 @@
#define COMPACT_PARTIAL3
/* The full zone was compacted */
#define COMPACT_COMPLETE 4
+/* When adding new state, please change compaction_status_string, too */
/* Used to signal whether compaction detected need_sched() or lock contention
*/
/* No contention detected */
diff --git a/include/trace/events/compaction.h
b/include/trace/events/compaction.h
index 1337d9e..839f6fa 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -85,46 +85,67 @@ TRACE_EVENT(mm_compaction_migratepages,
);
TRACE_EVENT(mm_compaction_begin,
- TP_PROTO(unsigned long zone_start, unsigned long migrate_start,
- unsigned long free_start, unsigned long zone_end),
+ TP_PROTO(unsigned long zone_start, unsigned long migrate_pfn,
+ unsigned long free_pfn, unsigned long zone_end, bool sync),
- TP_ARGS(zone_start, migrate_start, free_start, zone_end),
+ TP_ARGS(zone_start, migrate_pfn, free_pfn, zone_end, sync),
TP_STRUCT__entry(
__field(unsigned long, zone_start)
- __field(unsigned long, migrate_start)
- __field(unsigned long, free_start)
+ __field(unsigned long, migrate_pfn)
+ __field(unsigned long, free_pfn)
__field(unsigned long, zone_end)
+ __field(bool, sync)
),
TP_fast_assign(
__entry->zone_start = zone_start;
- __entry->migrate_start = migrate_start;
- __entry->free_start = free_start;
+ __entry->migrate_pfn = migrate_pfn;
+ __entry->free_pfn = free_pfn;
__entry->zone_end = zone_end;
+ __entry->sync = sync;
),
- TP_printk("zone_start=0x%lx migrate_start=0x%lx free_start=0x%lx
zone_end=0x%lx",
+ TP_printk("zone_start=0x%lx migrate_pfn=0x%lx free_pfn=0x%lx
zone_end=0x%lx, mode=%s",
__entry->zone_start,
- __entry->migrate_start,
- __entry->free_start,
- __entry->zone_end)
+ __entry->migrate_pfn,
+ __entry->free_pfn,
+ __entry->zone_end,
+ __entry->sync ? "sync" : "async")
);
TRACE_EVENT(mm_compaction_end,
- TP_PROTO(int status),
+ TP_PROTO(unsigned long zone_start, unsigned long migrate_pfn,
+ unsigned long free_pfn, unsigned long zone_end, bool sync,
+ int status),
- TP_ARGS(status),
+ TP_ARGS(zone_start, migrate_pfn, free_pfn, zone_end, sync, status),
TP_STRUCT__entry(
+ __field(unsigned long, zone_start)
+ __field(unsigned long, migrate_pfn)
+ __field(unsigned long, free_pfn)
+ __field(unsigned long, zone_end)
+ __field(bool, sync)
__field(int, status)
),
TP_fast_assign(
+ __entry->zone_start = zone_start;
+ __entry->migrate_pfn = migrate_pfn;
+ __entry->free_pfn = free_pfn;
+ __entry->zone_end = zone_end;
+ __entry->sync = sync;
__entry->status = status;
),
- TP_printk("status=%d", __entry->status)
+ TP_printk("zone_start=0x%lx migrate_pfn=0x%lx free_pfn=0x%lx
zone_end=0x%lx, mode=%s status=%s",
+ __entry->zone_start,
+ __entry->migrate_pfn,
+ __entry->free_pfn,
+ __entry->zone_end,
+ __entry->sync ? "sync" : "async",
+ compaction_status_string[__entry->status])
);
#endif /* _TRACE_COMPACTION_H */
diff --git a/mm/compaction.c b/mm/compaction.c
index 546e571..f32d456 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -34,6 +34,15 @@ static inline void count_compact_events(enum vm_event_item
it
[PATCH v4 1/5] mm/compaction: change tracepoint format from decimal to hexadecimal
To check the range that compaction is working, tracepoint print
start/end pfn of zone and start pfn of both scanner with decimal format.
Since we manage all pages in order of 2 and it is well represented by
hexadecimal, this patch change the tracepoint format from decimal to
hexadecimal. This would improve readability. For example, it makes us
easily notice whether current scanner try to compact previously
attempted pageblock or not.
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
---
include/trace/events/compaction.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/trace/events/compaction.h
b/include/trace/events/compaction.h
index c6814b9..1337d9e 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -104,7 +104,7 @@ TRACE_EVENT(mm_compaction_begin,
__entry->zone_end = zone_end;
),
- TP_printk("zone_start=%lu migrate_start=%lu free_start=%lu
zone_end=%lu",
+ TP_printk("zone_start=0x%lx migrate_start=0x%lx free_start=0x%lx
zone_end=0x%lx",
__entry->zone_start,
__entry->migrate_start,
__entry->free_start,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 5/5] mm/compaction: add tracepoint to observe behaviour of compaction defer
compaction deferring logic is heavy hammer that block the way to
the compaction. It doesn't consider overall system state, so it
could prevent user from doing compaction falsely. In other words,
even if system has enough range of memory to compact, compaction would be
skipped due to compaction deferring logic. This patch add new tracepoint
to understand work of deferring logic. This will also help to check
compaction success and fail.
Changes from v2: Remove reason part from tracepoint output
Changes from v3: Build fix for !CONFIG_COMPACTION
Signed-off-by: Joonsoo Kim
---
include/linux/compaction.h| 65 +++--
include/trace/events/compaction.h | 56 +
mm/compaction.c | 71 +
3 files changed, 132 insertions(+), 60 deletions(-)
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index 648d183..5024019 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -43,66 +43,11 @@ extern void reset_isolation_suitable(pg_data_t *pgdat);
extern unsigned long compaction_suitable(struct zone *zone, int order,
int alloc_flags, int classzone_idx);
-/* Do not skip compaction more than 64 times */
-#define COMPACT_MAX_DEFER_SHIFT 6
-
-/*
- * Compaction is deferred when compaction fails to result in a page
- * allocation success. 1 << compact_defer_limit compactions are skipped up
- * to a limit of 1 << COMPACT_MAX_DEFER_SHIFT
- */
-static inline void defer_compaction(struct zone *zone, int order)
-{
- zone->compact_considered = 0;
- zone->compact_defer_shift++;
-
- if (order < zone->compact_order_failed)
- zone->compact_order_failed = order;
-
- if (zone->compact_defer_shift > COMPACT_MAX_DEFER_SHIFT)
- zone->compact_defer_shift = COMPACT_MAX_DEFER_SHIFT;
-}
-
-/* Returns true if compaction should be skipped this time */
-static inline bool compaction_deferred(struct zone *zone, int order)
-{
- unsigned long defer_limit = 1UL << zone->compact_defer_shift;
-
- if (order < zone->compact_order_failed)
- return false;
-
- /* Avoid possible overflow */
- if (++zone->compact_considered > defer_limit)
- zone->compact_considered = defer_limit;
-
- return zone->compact_considered < defer_limit;
-}
-
-/*
- * Update defer tracking counters after successful compaction of given order,
- * which means an allocation either succeeded (alloc_success == true) or is
- * expected to succeed.
- */
-static inline void compaction_defer_reset(struct zone *zone, int order,
- bool alloc_success)
-{
- if (alloc_success) {
- zone->compact_considered = 0;
- zone->compact_defer_shift = 0;
- }
- if (order >= zone->compact_order_failed)
- zone->compact_order_failed = order + 1;
-}
-
-/* Returns true if restarting compaction after many failures */
-static inline bool compaction_restarting(struct zone *zone, int order)
-{
- if (order < zone->compact_order_failed)
- return false;
-
- return zone->compact_defer_shift == COMPACT_MAX_DEFER_SHIFT &&
- zone->compact_considered >= 1UL << zone->compact_defer_shift;
-}
+extern void defer_compaction(struct zone *zone, int order);
+extern bool compaction_deferred(struct zone *zone, int order);
+extern void compaction_defer_reset(struct zone *zone, int order,
+ bool alloc_success);
+extern bool compaction_restarting(struct zone *zone, int order);
#else
static inline unsigned long try_to_compact_pages(struct zonelist *zonelist,
diff --git a/include/trace/events/compaction.h
b/include/trace/events/compaction.h
index d465358..9a6a3fe 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -238,6 +238,62 @@ DEFINE_EVENT(mm_compaction_suitable_template,
mm_compaction_suitable,
TP_ARGS(zone, order, ret)
);
+#ifdef CONFIG_COMPACTION
+DECLARE_EVENT_CLASS(mm_compaction_defer_template,
+
+ TP_PROTO(struct zone *zone, int order),
+
+ TP_ARGS(zone, order),
+
+ TP_STRUCT__entry(
+ __field(int, nid)
+ __field(char *, name)
+ __field(int, order)
+ __field(unsigned int, considered)
+ __field(unsigned int, defer_shift)
+ __field(int, order_failed)
+ ),
+
+ TP_fast_assign(
+ __entry->nid = zone_to_nid(zone);
+ __entry->name = (char *)zone->name;
+ __entry->order = order;
+ __entry->considered = zone->compact_considered;
+ __entry->defer_shift = zone->compact_defer_shift;
+ __entry->order_failed = zone->compact_order_failed;
+ ),
+
+ TP_printk("node=%d zone=%-8s order=%d order_failed=%d consider=%u
limit=%lu",
+ _
linux-next: manual merge of the luto-misc tree with the tip tree
Hi Andy,
Today's linux-next merge of the luto-misc tree got a conflict in
arch/x86/kernel/cpu/mcheck/mce.c between commit 83737691e586 ("x86,
mce: Fix sparse errors") from the tip tree and commit d4812e169de4
("x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks") from
the luto-misc tree.
I fixed it up (the latter removed some of the code changed by the
former) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgppj8HXUCC1F.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 2/5] ARM:sunxi:drivers:input Add support for A10/A20 PS2
Hello Dmitry,
Thank you for review comments. Please see in-lined.
On Sun, Jan 18, 2015 at 3:55 AM, Dmitry Torokhov
wrote:
> Hi Vishnu,
>
> On Fri, Jan 16, 2015 at 07:33:38PM +0530, Vishnu Patekar wrote:
>> Signed-off-by: VishnuPatekar
>> ---
>> drivers/input/serio/Kconfig | 11 ++
>> drivers/input/serio/Makefile|1 +
>> drivers/input/serio/sun4i-ps2.c | 330
>> +++
>> 3 files changed, 342 insertions(+)
>> create mode 100644 drivers/input/serio/sun4i-ps2.c
>>
>> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
>> index bc2d474..964afc5 100644
>> --- a/drivers/input/serio/Kconfig
>> +++ b/drivers/input/serio/Kconfig
>> @@ -281,4 +281,15 @@ config HYPERV_KEYBOARD
>> To compile this driver as a module, choose M here: the module will
>> be called hyperv_keyboard.
>>
>> +config SERIO_SUN4I_PS2
>> + tristate "Allwinner A10 PS/2 controller support"
>> + default n
>> + depends on ARCH_SUNXI || COMPILE_TEST
>> + help
>> + This selects support for the PS/2 Host Controller on
>> + Allwinner A10.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called sun4i-ps2.
>> +
>> endif
>> diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
>> index 815d874..c600089 100644
>> --- a/drivers/input/serio/Makefile
>> +++ b/drivers/input/serio/Makefile
>> @@ -29,3 +29,4 @@ obj-$(CONFIG_SERIO_ARC_PS2) += arc_ps2.o
>> obj-$(CONFIG_SERIO_APBPS2) += apbps2.o
>> obj-$(CONFIG_SERIO_OLPC_APSP)+= olpc_apsp.o
>> obj-$(CONFIG_HYPERV_KEYBOARD)+= hyperv-keyboard.o
>> +obj-$(CONFIG_SERIO_SUN4I_PS2)+= sun4i-ps2.o
>> diff --git a/drivers/input/serio/sun4i-ps2.c
>> b/drivers/input/serio/sun4i-ps2.c
>> new file mode 100644
>> index 000..06b3fef
>> --- /dev/null
>> +++ b/drivers/input/serio/sun4i-ps2.c
>> @@ -0,0 +1,330 @@
>> +/*
>> + * Driver for Allwinner A10 PS2 host controller
>> + *
>> + * Author: Vishnu Patekar
>> + * Aaron.maoye
>> + *
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define DRIVER_NAME "sun4i-ps2"
>> +
>> +/* register offset definitions */
>> +#define PS2_REG_GCTL 0x00/* PS2 Module Global Control Reg */
>> +#define PS2_REG_DATA 0x04/* PS2 Module Data Reg */
>> +#define PS2_REG_LCTL 0x08/* PS2 Module Line Control Reg */
>> +#define PS2_REG_LSTS 0x0C/* PS2 Module Line Status Reg */
>> +#define PS2_REG_FCTL 0x10/* PS2 Module FIFO Control Reg */
>> +#define PS2_REG_FSTS 0x14/* PS2 Module FIFO Status Reg */
>> +#define PS2_REG_CLKDR0x18/* PS2 Module Clock Divider
>> Reg*/
>> +
>> +/* PS2 GLOBAL CONTROL REGISTER PS2_GCTL */
>> +#define PS2_GCTL_INTFLAG BIT(4)
>> +#define PS2_GCTL_INTEN BIT(3)
>> +#define PS2_GCTL_RESET BIT(2)
>> +#define PS2_GCTL_MASTER BIT(1)
>> +#define PS2_GCTL_BUSEN BIT(0)
>> +
>> +/* PS2 LINE CONTROL REGISTER */
>> +#define PS2_LCTL_NOACK BIT(18)
>> +#define PS2_LCTL_TXDTOEN BIT(8)
>> +#define PS2_LCTL_STOPERREN BIT(3)
>> +#define PS2_LCTL_ACKERRENBIT(2)
>> +#define PS2_LCTL_PARERRENBIT(1)
>> +#define PS2_LCTL_RXDTOEN BIT(0)
>> +
>> +/* PS2 LINE STATUS REGISTER */
>> +#define PS2_LSTS_TXTDO BIT(8)
>> +#define PS2_LSTS_STOPERR BIT(3)
>> +#define PS2_LSTS_ACKERR BIT(2)
>> +#define PS2_LSTS_PARERR BIT(1)
>> +#define PS2_LSTS_RXTDO BIT(0)
>> +
>> +#define PS2_LINE_ERROR_BIT \
>> + (PS2_LSTS_TXTDO | PS2_LSTS_STOPERR | PS2_LSTS_ACKERR | \
>> + PS2_LSTS_PARERR | PS2_LSTS_RXTDO)
>> +
>> +/* PS2 FIFO CONTROL REGISTER */
>> +#define PS2_FCTL_TXRST BIT(17)
>> +#define PS2_FCTL_RXRST BIT(16)
>> +#define PS2_FCTL_TXUFIEN BIT(10)
>> +#define PS2_FCTL_TXOFIEN BIT(9)
>> +#define PS2_FCTL_TXRDYIENBIT(8)
>> +#define PS2_FCTL_RXUFIEN BIT(2)
>> +#define PS2_FCTL_RXOFIEN BIT(1)
>> +#define PS2_FCTL_RXRDYIENBIT(0)
>> +
>> +/* PS2 FIFO STATUS REGISTER */
>> +#define PS2_FSTS_TXUFBIT(10)
>> +#define PS2_FSTS_TXOFBIT(9)
>> +#define PS2_FSTS_TXRDY BIT(8)
>> +#define PS2_FSTS_RXUFBIT(2)
>> +#define PS2_FSTS_RXOFBIT(1)
>> +#define PS2_FSTS_RXRDY BIT(0)
>> +
>> +#define PS2_FIFO_ERROR_BIT \
>> + (PS2_FSTS_TXUF | PS2_FSTS_TXOF | PS2_FSTS_RXUF | PS2_FSTS_RXOF)
>> +
>> +#define PS2_SAMPLE_CLK 100
>> +#define PS2_SCLK 125000
>> +
>> +struct sun4i_ps2data {
>> + struct serio *serio;
>> + struct device *dev;
>> +
>> + /* IO mapping base */
>> + void __iomem*reg_base;
>> +
>> + /
[PATCH v3 2/2] mm: don't use compound_head() in virt_to_head_page()
compound_head() is implemented with assumption that there would be
race condition when checking tail flag. This assumption is only true
when we try to access arbitrary positioned struct page.
The situation that virt_to_head_page() is called is different case.
We call virt_to_head_page() only in the range of allocated pages,
so there is no race condition on tail flag. In this case, we don't
need to handle race condition and we can reduce overhead slightly.
This patch implements compound_head_fast() which is similar with
compound_head() except tail flag race handling. And then,
virt_to_head_page() uses this optimized function to improve performance.
I saw 1.8% win in a fast-path loop over kmem_cache_alloc/free,
(14.063 ns -> 13.810 ns) if target object is on tail page.
Change from v2: Add some code comments
Acked-by: Christoph Lameter
Signed-off-by: Joonsoo Kim
---
include/linux/mm.h | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f80d019..1148fc6 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -446,6 +446,12 @@ static inline struct page *compound_head_by_tail(struct
page *tail)
return tail;
}
+/*
+ * Since either compound page could be dismantled asynchronously in THP
+ * or we access asynchronously arbitrary positioned struct page, there
+ * would be tail flag race. To handle this race, we should call
+ * smp_rmb() before checking tail flag. compound_head_by_tail() did it.
+ */
static inline struct page *compound_head(struct page *page)
{
if (unlikely(PageTail(page)))
@@ -454,6 +460,18 @@ static inline struct page *compound_head(struct page *page)
}
/*
+ * If we access compound page synchronously such as access to
+ * allocated page, there is no need to handle tail flag race, so we can
+ * check tail flag directly without any synchronization primitive.
+ */
+static inline struct page *compound_head_fast(struct page *page)
+{
+ if (unlikely(PageTail(page)))
+ return page->first_page;
+ return page;
+}
+
+/*
* The atomic page->_mapcount, starts from -1: so that transitions
* both from it and to it can be tracked, using atomic_inc_and_test
* and atomic_add_negative(-1).
@@ -531,7 +549,14 @@ static inline void get_page(struct page *page)
static inline struct page *virt_to_head_page(const void *x)
{
struct page *page = virt_to_page(x);
- return compound_head(page);
+
+ /*
+* We don't need to worry about synchronization of tail flag
+* when we call virt_to_head_page() since it is only called for
+* already allocated page and this page won't be freed until
+* this virt_to_head_page() is finished. So use _fast variant.
+*/
+ return compound_head_fast(page);
}
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] mm/slub: optimize alloc/free fastpath by removing preemption on/off
We had to insert a preempt enable/disable in the fastpath a while ago in order to guarantee that tid and kmem_cache_cpu are retrieved on the same cpu. It is the problem only for CONFIG_PREEMPT in which scheduler can move the process to other cpu during retrieving data. Now, I reach the solution to remove preempt enable/disable in the fastpath. If tid is matched with kmem_cache_cpu's tid after tid and kmem_cache_cpu are retrieved by separate this_cpu operation, it means that they are retrieved on the same cpu. If not matched, we just have to retry it. With this guarantee, preemption enable/disable isn't need at all even if CONFIG_PREEMPT, so this patch removes it. I saw roughly 5% win in a fast-path loop over kmem_cache_alloc/free in CONFIG_PREEMPT. (14.821 ns -> 14.049 ns) Below is the result of Christoph's slab_test reported by Jesper Dangaard Brouer. * Before Single thread testing = 1. Kmalloc: Repeatedly allocate then free test 1 times kmalloc(8) -> 49 cycles kfree -> 62 cycles 1 times kmalloc(16) -> 48 cycles kfree -> 64 cycles 1 times kmalloc(32) -> 53 cycles kfree -> 70 cycles 1 times kmalloc(64) -> 64 cycles kfree -> 77 cycles 1 times kmalloc(128) -> 74 cycles kfree -> 84 cycles 1 times kmalloc(256) -> 84 cycles kfree -> 114 cycles 1 times kmalloc(512) -> 83 cycles kfree -> 116 cycles 1 times kmalloc(1024) -> 81 cycles kfree -> 120 cycles 1 times kmalloc(2048) -> 104 cycles kfree -> 136 cycles 1 times kmalloc(4096) -> 142 cycles kfree -> 165 cycles 1 times kmalloc(8192) -> 238 cycles kfree -> 226 cycles 1 times kmalloc(16384) -> 403 cycles kfree -> 264 cycles 2. Kmalloc: alloc/free test 1 times kmalloc(8)/kfree -> 68 cycles 1 times kmalloc(16)/kfree -> 68 cycles 1 times kmalloc(32)/kfree -> 69 cycles 1 times kmalloc(64)/kfree -> 68 cycles 1 times kmalloc(128)/kfree -> 68 cycles 1 times kmalloc(256)/kfree -> 68 cycles 1 times kmalloc(512)/kfree -> 74 cycles 1 times kmalloc(1024)/kfree -> 75 cycles 1 times kmalloc(2048)/kfree -> 74 cycles 1 times kmalloc(4096)/kfree -> 74 cycles 1 times kmalloc(8192)/kfree -> 75 cycles 1 times kmalloc(16384)/kfree -> 510 cycles * After Single thread testing = 1. Kmalloc: Repeatedly allocate then free test 1 times kmalloc(8) -> 46 cycles kfree -> 61 cycles 1 times kmalloc(16) -> 46 cycles kfree -> 63 cycles 1 times kmalloc(32) -> 49 cycles kfree -> 69 cycles 1 times kmalloc(64) -> 57 cycles kfree -> 76 cycles 1 times kmalloc(128) -> 66 cycles kfree -> 83 cycles 1 times kmalloc(256) -> 84 cycles kfree -> 110 cycles 1 times kmalloc(512) -> 77 cycles kfree -> 114 cycles 1 times kmalloc(1024) -> 80 cycles kfree -> 116 cycles 1 times kmalloc(2048) -> 102 cycles kfree -> 131 cycles 1 times kmalloc(4096) -> 135 cycles kfree -> 163 cycles 1 times kmalloc(8192) -> 238 cycles kfree -> 218 cycles 1 times kmalloc(16384) -> 399 cycles kfree -> 262 cycles 2. Kmalloc: alloc/free test 1 times kmalloc(8)/kfree -> 65 cycles 1 times kmalloc(16)/kfree -> 66 cycles 1 times kmalloc(32)/kfree -> 65 cycles 1 times kmalloc(64)/kfree -> 66 cycles 1 times kmalloc(128)/kfree -> 66 cycles 1 times kmalloc(256)/kfree -> 71 cycles 1 times kmalloc(512)/kfree -> 72 cycles 1 times kmalloc(1024)/kfree -> 71 cycles 1 times kmalloc(2048)/kfree -> 71 cycles 1 times kmalloc(4096)/kfree -> 71 cycles 1 times kmalloc(8192)/kfree -> 65 cycles 1 times kmalloc(16384)/kfree -> 511 cycles Most of the results are better than before. Note that this change slightly worses performance in !CONFIG_PREEMPT, roughly 0.3%. Implementing each case separately would help performance, but, since it's so marginal, I didn't do that. This would help maintanance since we have same code for all cases. Change from v1: add comment about barrier() usage Change from v2: - use raw_cpu_ptr() rather than this_cpu_ptr() to avoid warning from preemption debug check since this is intended behaviour - fix typo alogorithm -> algorithm Acked-by: Christoph Lameter Acked-by: Jesper Dangaard Brouer Tested-by: Jesper Dangaard Brouer Signed-off-by: Joonsoo Kim --- mm/slub.c | 35 +++ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index fe376fe..e7ed6f8 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2398,13 +2398,24 @@ redo: * reading from one cpu area. That does not matter as long * as we end up on the original cpu again when doing the cmpxchg. * -* Preemption is disabled for the retrieval of the tid because that -* must occur from the current processor. We cannot allow rescheduling -* on a different processor between the determination of the pointer -* and the retrieval of the tid. +* We should guarantee that tid and
Re: query on DWC3
Hi Felipe, On Thu, Jan 8, 2015 at 10:27 PM, Felipe Balbi wrote: > Hi, > > On Tue, Jan 06, 2015 at 12:39:55PM +0530, sundeep subbaraya wrote: >> >> On Sun, Dec 14, 2014 at 08:39:18AM +0530, sundeep subbaraya wrote: >> >> > Hi Paul, >> >> > >> >> > As per my understanding, for BULK OUT we do queue a request with 512 >> >> > bytes length since we do not >> >> >> >> sometimes we _do_ know the size. In case of Mass Storage, we _know_ that >> >> the first bulk out transfer will be 31-bytes (CBW), if we were to start >> >> a 31-byte transfer, we would't receive anything. >> >> >> >> > know the length of the transfer Host is going to send. For Control OUT >> >> > we know the length in wLength of >> >> > Setup packet, hence I assumed there is no difference in programming >> >> > model of Control IN and OUT. >> >> >> >> there is _no_ difference. It's just that it was agreed that for anything >> >> other than control ep, the function drivers would take care of it. See >> >> the uses of quirk_ep_out_aligned_size. >> >> got it..:) >> >> > >> > btw, why are you reimplementing the driver when there's a perfectly good >> > driver to use in mainline kernel ? >> >> I am writing a bare metal driver and it didn't work without alignment >> check mentioned above. > > just make sure you don't copy GPL code into your bare metal driver, > otherwise your bare metal driver will be GPL by definition. Also, since I didn't copy linux code. I have gone through dwc3 driver while writing udc-xilinx.c and now it is helping me to understand dwc3 controller quickly.:) > you're not using Linux at all, you should be asking support from > Synopsys instead, not the Linux USB mailing list. Sure will ask support from Synopsis. Thanks, Sundeep > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] gpio: support for GPIO forwarding
On Wed, Jan 14, 2015 at 9:58 PM, Linus Walleij wrote: > On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus > wrote: > >> This makes it possible to assign GPIOs at runtime. The >> motivation for it is because of need to forward GPIOs from >> one device to an other. That feature may be useful for >> example with some mfd devices, but initially it is needed >> because on some Intel Braswell based ACPI platforms the GPIO >> resources controlling signals of the USB PHY are given to >> the controller device object for whatever reason, so the >> driver of that controller needs be able to pass them to the >> PHY device somehow. >> >> So basically this is meant to allow patching of bad (bad >> from Linux kernels point of view) hardware descriptions >> provided by system fw in the drivers. >> >> Signed-off-by: Heikki Krogerus >> --- >> >> Hi, >> >> I'm sending this first as a RFC in case you guys have some better >> idea how to solve our problem. I actually already have couple >> platforms where the GPIO resources are given to the "wrong" device >> objects now. >> >> Originally we were thinking about simply handling our problem with >> hacks to the PHY drivers, basically also checking if the parent has >> GPIOs. That would only work if the controller is always the parent, >> which it's not, but even if it was, it would be too risky. The PHY >> drivers don't know which controller they are attached to, so what is >> to say that the GPIOs aren't really attached to the controller. >> >> So the safest way to handle our problem is to deal with it in quirks >> in the controller drivers. Solving it by bouncing the GPIOs did not >> feel ideal there doesn't seem to be any other way. The API is copied >> from clkdev (clk_register_clkdev). In the end it's really only one >> function for adding the lookups and one for removing them. >> >> The way it's implemented is by modifying the current style of handling >> the lookups a little bit. The per device lookup table is basically >> reverted back to the single linked-list format since it seems that >> these lookups may have to be assigned from several sources. > > Oh ain't that great. > > So now we start patching around the kernel because the ACPI > tables are erroneous for GPIOs. I'd like some feedback from > Rafael &| Darren on this patch, i.e. if you two think this is a good > way of accounting for bad GPIO descriptions in ACPI tables then > ACK this patch. > > I guess the other option would be to fix up the ACPI DSDT > itself to put resources right, correct? Is this not possible? > > Alexandre also need to ACK it before I dare do anything with > it. I am not really fond of this idea since it adds complexity to the (already too complex) GPIO lookup, and only solves to a local level (GPIO) what is a more global problem (bad ACPI tables that can affect any subsystem). Also I don't think any new functions is actually needed: on an ACPI system we can safely assume that the platform lookup tables are not used at all. So, although it is a hack as well, you can just call gpiod_add_lookup_table() with a runtime-built table from the driver that needs to pass the GPIO so the receipient can receive it through the lookup table fallback gpiod_get() uses if no GPIO is defined via ACPI. So I think that even with the current state of the code you can achieve what you need. Should you do it, that's another question - it seems more to-the-point to find a way to fix/patch the ACPI tables at runtime, if that is possible at all, to provide a more general solution to this issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: entry-common: fix forgotten set of thread_info->syscall
On Sat, Jan 17, 2015 at 8:54 AM, Kees Cook wrote:
> On Fri, Jan 16, 2015 at 11:57 AM, Kees Cook wrote:
>> On Fri, Jan 16, 2015 at 8:17 AM, Russell King - ARM Linux
>> wrote:
>>> On Sat, Jan 17, 2015 at 01:08:11AM +0900, Roman Peniaev wrote:
On Sat, Jan 17, 2015 at 12:59 AM, Russell King - ARM Linux
wrote:
> On Sat, Jan 17, 2015 at 12:57:02AM +0900, Roman Peniaev wrote:
>> On Fri, Jan 16, 2015 at 7:54 AM, Kees Cook
>> wrote:
>> > One interesting thing I noticed (which is unchanged by this series),
>> > but pulling ARM_r7 during the seccomp ptrace event shows __NR_poll,
>> > not __NR_restart_syscall, even though it was a __NR_restart_syscall
>> > trap from seccomp. Is there a better place to see the actual syscall?
>>
>> As I understand we do not push new r7 to the stack, and ptrace uses the
>> old value.
>
> And why should we push r7 to the stack? ptrace should be using the
> recorded system call number, rather than poking about on the stack
> itself.
Probably we should not, but the behaviour comparing arm to x86 is
different.
>>>
>>> We definitely should not, because changing the stacked value changes the
>>> value in r7 after the syscall has returned. We have guaranteed that the
>>> value will be preserved across syscalls for years, so we really should
>>> not be changing that.
>>
>> Yeah, we can't mess with the registers. I was just asking for
>> clarification on how this is visible to userspace.
>>
>>>
Also there is no any way from userspace to figure out what syscall was
restarted, if you do not trace each syscall enter and exit from the
very beginning.
>>>
>>> Thinking about ptrace, that's been true for years.
>>>
>>> It really depends whether you consider the restart syscall a userspace
>>> thing or a kernelspace thing. When you consider that the vast majority
>>> of syscall restarts are done internally in the kernel, and we just
>>> re-issue the syscall, it immediately brings up the question "why is
>>> the restart block method different?" and "should the restart block
>>> method be visible to userspace?"
>>>
>>> IMHO, it is prudent not to expose kernel internals to userspace unless
>>> there is a real reason to, otherwise they become part of the userspace
>>> API.
>>
>> I couldn't agree more, but restart_syscall is already visible to
>> userspace: it can be called directly, for example. And it's visible to
>> tracers.
>>
>> Unfortunately, the difference here is the visibility during trace
>> trap. On x86, it's exposed but on ARM, there's no way (that I can
>> find) to query the "true" syscall, even though the true syscall is
>> what triggers the tracer. The syscall number isn't provided by any
>> element of the ptrace event system, nor through siginfo, and must be
>> examined on a per-arch basis from registers.
>>
>> Seccomp does, however, provide a mechanism to pass arbitrary event
>> data on a TRACE event, so poll vs restart_syscall can be distinguished
>> that way.
>>
>> It seems even strace doesn't know how to find this information. For example:
>>
>> x86:
>> poll([{fd=3, events=POLLIN}], 1, 4294967295
>> ) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
>> --- SIGSTOP {si_signo=SIGSTOP, si_code=SI_USER, si_pid=994, si_uid=1000} ---
>> --- stopped by SIGSTOP ---
>> --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=994, si_uid=1000} ---
>> restart_syscall(<... resuming interrupted call ...>
>>
>> ARM:
>> poll([{fd=3, events=POLLIN}], 1, -1
>> )= ? ERESTART_RESTARTBLOCK (Interrupted by signal)
>> --- SIGSTOP {si_signo=SIGSTOP, si_code=SI_USER, si_pid=20563, si_uid=0} ---
>> --- stopped by SIGSTOP ---
>> --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=20563, si_uid=0} ---
>> poll([{fd=3, events=POLLIN}], 1, -1
>>
>> Would it make sense to add REGSET_SYSTEM_CALL to ARM? (Though this
>> begs the question, "Is restart_syscall visible during a trace on
>> arm64?", which I'll have to go check...)
>
> So, some further testing:
> - native arm64 presents "poll" again even to seccomp when
> restart_syscall is triggered (both via regs[8] and
> NT_ARM_SYSTEM_CALL).
> - compat mode on arm64 _does_ show syscall_restart (via ARM_r7).
>
> Which of these behaviors is intentional? :)
>
Just want to summarize the difference.
(please, correct me if i am mistaken)
Userspace has two ways to see actual syscall number:
1. /proc/pid/syscall file
2. ptrace
So the following is the table showing what syscall number
userspace sees using proc file or doing ptrace in case of restarted poll:
x86 ARM ARM64 ARM64 compat
cat /proc/pid/syscall: NR_restartNot supported? ?
ptrace: NR_restartNR_poll NR_poll NR_restart
Not supported - should be fixed by these two patches, the behaviour should
be similar to x86, i.e. userspace will see NR_restart
- I do
PE,PS/how to take more profits
Hi Sir, Update price for PE If you have any interest or questions, please reply me please just connect me. HDPE,LDPE,PP,PVC,GPPS and so on. Free sample can be provided if you want. Waiting for your reply. Have a nice day! Ada - Export Department SHANDONG XINYUAN INDUSTRY CO.,LTD
[PATCH] idle/tick-broadcast: Exit cpu idle poll loop when cleared from tick_broadcast_force_mask
An idle cpu enters cpu_idle_poll() if it is set in the tick_broadcast_force_mask. This is so that it does not incur the overhead of entering idle states when it is expected to be woken up anytime then through a broadcast IPI. The condition that forces an exit out of the idle polling is the check on setting of the TIF_NEED_RESCHED flag for the idle thread. When the broadcast IPI does arrive, it is not guarenteed that the handler sets the TIF_NEED_RESCHED flag. Hence although the cpu is cleared in the tick_broadcast_force_mask, it continues to loop in cpu_idle_poll unnecessarily wasting power. Hence exit the idle poll loop if the tick_broadcast_force_mask gets cleared and enter idle states. Of course if the cpu has entered cpu_idle_poll() on being asked to poll explicitly, it continues to poll till it is asked to reschedule. Signed-off-by: Preeti U Murthy --- kernel/sched/idle.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c index c47fce7..aaf1c1d 100644 --- a/kernel/sched/idle.c +++ b/kernel/sched/idle.c @@ -47,7 +47,8 @@ static inline int cpu_idle_poll(void) rcu_idle_enter(); trace_cpu_idle_rcuidle(0, smp_processor_id()); local_irq_enable(); - while (!tif_need_resched()) + while (!tif_need_resched() && + (cpu_idle_force_poll || tick_check_broadcast_expired())) cpu_relax(); trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id()); rcu_idle_exit(); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] crypto: aesni: add setkey for driver-gcm-aes-aesni
The cipher registered as __driver-gcm-aes-aesni is never intended
to be used directly by any caller. Instead it is a service mechanism to
rfc4106-gcm-aesni.
The kernel crypto API unconditionally calls the registered setkey
function. In case a caller erroneously uses __driver-gcm-aes-aesni a
call to crypto_aead_setkey will cause a NULL pointer dereference without
this patch.
CC: Tadeusz Struk
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/aesni-intel_glue.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/crypto/aesni-intel_glue.c
b/arch/x86/crypto/aesni-intel_glue.c
index 947c6bf..a278ef9 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -1012,6 +1012,16 @@ static int rfc4106_decrypt(struct aead_request *req)
}
}
+static int __driver_rfc4106_set_key(struct crypto_aead *parent,
+ const u8 *key, unsigned int key_len)
+{
+ /*
+* __driver-gcm-aes-aesni is only a backend for rfc4106-gcm-aesni
+* and is never intended to be used as a regular cipher.
+*/
+ return -EOPNOTSUPP;
+}
+
static int __driver_rfc4106_encrypt(struct aead_request *req)
{
u8 one_entry_in_sg = 0;
@@ -1366,6 +1376,7 @@ static struct crypto_alg aesni_algs[] = { {
.cra_module = THIS_MODULE,
.cra_u = {
.aead = {
+ .setkey = __driver_rfc4106_set_key,
.encrypt= __driver_rfc4106_encrypt,
.decrypt= __driver_rfc4106_decrypt,
},
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] crypto: Documentation: remove colons in comments
As documented in Documentation/kernel-doc-nano-HOWTO.txt lines terminated with a colon are treated as headings. The current layout of the documentation when compiling the kernel crypto API DocBook documentation is messed up by by treating some lines as headings. The patch removes colons from comments that shall not be treated as headings. Signed-off-by: Stephan Mueller --- include/linux/crypto.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/crypto.h b/include/linux/crypto.h index 9099834..fb5ef16 100644 --- a/include/linux/crypto.h +++ b/include/linux/crypto.h @@ -1147,7 +1147,7 @@ static inline void ablkcipher_request_free(struct ablkcipher_request *req) * cipher operation completes. * * The callback function is registered with the ablkcipher_request handle and - * must comply with the following template: + * must comply with the following template * * void callback_function(struct crypto_async_request *req, int error) */ @@ -1174,7 +1174,7 @@ static inline void ablkcipher_request_set_callback( * * For encryption, the source is treated as the plaintext and the * destination is the ciphertext. For a decryption operation, the use is - * reversed: the source is the ciphertext and the destination is the plaintext. + * reversed - the source is the ciphertext and the destination is the plaintext. */ static inline void ablkcipher_request_set_crypt( struct ablkcipher_request *req, @@ -1509,7 +1509,7 @@ static inline void aead_request_free(struct aead_request *req) * completes * * The callback function is registered with the aead_request handle and - * must comply with the following template: + * must comply with the following template * * void callback_function(struct crypto_async_request *req, int error) */ @@ -1536,7 +1536,7 @@ static inline void aead_request_set_callback(struct aead_request *req, * * For encryption, the source is treated as the plaintext and the * destination is the ciphertext. For a decryption operation, the use is - * reversed: the source is the ciphertext and the destination is the plaintext. + * reversed - the source is the ciphertext and the destination is the plaintext. * * IMPORTANT NOTE AEAD requires an authentication tag (MAC). For decryption, * the caller must concatenate the ciphertext followed by the -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: aesni: add setkey for driver-gcm-aes-aesni
Am Sonntag, 18. Januar 2015, 23:56:03 schrieb Stephan Mueller:
Hi Tadeusz,
> The cipher registered as __driver-gcm-aes-aesni is never intended
> to be used directly by any caller. Instead it is a service mechanism to
> rfc4106-gcm-aesni.
>
> The kernel crypto API unconditionally calls the registered setkey
> function. In case a caller erroneously uses __driver-gcm-aes-aesni a
> call to crypto_aead_setkey will cause a NULL pointer dereference without
> this patch.
I tested that patch and can confirm that this patch fixes the kernel crash
triggered through the AF_ALG interface for AEAD ciphers that is currently
under development reported earlier.
>
> CC: Tadeusz Struk
> Signed-off-by: Stephan Mueller
> ---
> arch/x86/crypto/aesni-intel_glue.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/x86/crypto/aesni-intel_glue.c
> b/arch/x86/crypto/aesni-intel_glue.c index 947c6bf..a278ef9 100644
> --- a/arch/x86/crypto/aesni-intel_glue.c
> +++ b/arch/x86/crypto/aesni-intel_glue.c
> @@ -1012,6 +1012,16 @@ static int rfc4106_decrypt(struct aead_request *req)
> }
> }
>
> +static int __driver_rfc4106_set_key(struct crypto_aead *parent,
> + const u8 *key, unsigned int key_len)
> +{
> + /*
> + * __driver-gcm-aes-aesni is only a backend for rfc4106-gcm-aesni
> + * and is never intended to be used as a regular cipher.
> + */
> + return -EOPNOTSUPP;
> +}
> +
> static int __driver_rfc4106_encrypt(struct aead_request *req)
> {
> u8 one_entry_in_sg = 0;
> @@ -1366,6 +1376,7 @@ static struct crypto_alg aesni_algs[] = { {
> .cra_module = THIS_MODULE,
> .cra_u = {
> .aead = {
> + .setkey = __driver_rfc4106_set_key,
> .encrypt= __driver_rfc4106_encrypt,
> .decrypt= __driver_rfc4106_decrypt,
> },
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: module: fix module_refcount() return when running in a module exit routine
(2015/01/19 1:55), James Bottomley wrote:
> From: James Bottomley
>
> After e513cc1 module: Remove stop_machine from module unloading,
> module_refcount() is returning (unsigned long)-1 when called from within
> a routine that runs in module_exit. This is confusing the scsi device
> put code which is coded to detect a module_refcount() of zero for
> running within a module exit routine and not try to do another
> module_put. The fix is to restore the original behaviour of
> module_refcount() and return zero if we're running inside an exit
> routine.
>
> Fixes: e513cc1c07e2ab93a4514eec9833e031df3e30bb
> Reported-by: Bart Van Assche
> Signed-off-by: James Bottomley
>
Yes, this should be fixed as you said, since it must return "unsigned long"
value.
Reviewed-by: Masami Hiramatsu
Just one comment below;
> diff --git a/kernel/module.c b/kernel/module.c
> index 3965511..c33a113 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -774,7 +774,12 @@ static int try_stop_module(struct module *mod, int
> flags, int *forced)
>
> unsigned long module_refcount(struct module *mod)
> {
> - return (unsigned long)atomic_read(&mod->refcnt) - MODULE_REF_BASE;
> + unsigned long ret = atomic_read(&mod->refcnt);
> +
> + if (ret == 0)
This would better be "if (unlikely(ret == 0))".
Thank you,
> + /* ref is already zero (probably in module exit) */
> + return 0;
> + return ret - MODULE_REF_BASE;
> }
> EXPORT_SYMBOL(module_refcount);
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch RESEND] x86: don't rely on VMWare emulating PAT MSR correctly
Juergen, thanks for following up on this.
X86 maintainers - If it helps let me also confirm that without this
patch the latest kernels *always* crash on VMware guest running HWv10
and earlier.
Please include the fix at your earliest.
Thanks,
Alok
On Mon, 2015-01-19 at 06:05 +0100, Juergen Gross wrote:
> PING!
>
> The patch repairs a bug with VMWARE, which has been reported by several
> users. All of them have confirmed the patch is working. And VMWARE has
> acked the patch. What else do you need to take it? It is available for
> over a month now!
>
> Juergen
>
> On 01/12/2015 06:15 AM, Juergen Gross wrote:
> > VMWare seems not to emulate the PAT MSR correctly: reaeding
> > MSR_IA32_CR_PAT returns 0 even after writing another value to it.
> >
> > Detect this bug and don't use the read value if it is 0.
> >
> > Commit bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 ("x86: Enable PAT to
> > use cache mode translation tables") triggers this VMWare bug when the
> > kernel is booted as a VMWare guest.
> >
> > Reported-by: Jongman Heo
> > Signed-off-by: Juergen Gross
> > Tested-by: Jongman Heo
> > Acked-by: Alok N Kataria
> > ---
> > arch/x86/mm/pat.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> > index edf299c..7ac6869 100644
> > --- a/arch/x86/mm/pat.c
> > +++ b/arch/x86/mm/pat.c
> > @@ -234,8 +234,13 @@ void pat_init(void)
> > PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
> >
> > /* Boot CPU check */
> > - if (!boot_pat_state)
> > + if (!boot_pat_state) {
> > rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
> > + if (!boot_pat_state) {
> > + pat_disable("PAT read returns always zero, disabled.");
> > + return;
> > + }
> > + }
> >
> > wrmsrl(MSR_IA32_CR_PAT, pat);
> >
> >
>
Re: [PATCH 01/28] PCI: Rip out pci_bus_add_devices() from pci_scan_bus()
On 19/01/15 12:04, Yijing Wang wrote: > On 2015/1/17 7:16, Yinghai Lu wrote: >> On Fri, Jan 16, 2015 at 3:15 PM, Yinghai Lu wrote: >>> On Thu, Jan 15, 2015 at 5:43 PM, Yijing Wang wrote: Pci_bus_add_devices() should not be placed in pci_scan_bus(). Now pci device will be added to driver core once its creation. All things left in pci_bus_add_devices() are driver attachment and other trivial sysfs things. Pci_scan_bus() should be the function responsible for scanning PCI devices, not including driver attachment. Other, some callers(m68k,unicore32,alpha) of pci_scan_bus() will call pci_bus_size_bridges() and pci_bus_assign_resources() after pci_scan_bus(). E.g. In m68k mcf_pci_init() pci_scan_bus() ... pci_bus_add_devices() --- try to attach driver pci_fixup_irqs() pci_bus_size_bridges() pci_bus_assign_resources() It is not correct, resources should be assigned correctly before attaching driver. >>> >> No, for booting path, at that time pci drivers are *NOT* loaded yet. > > Hi Yinghai, I knew code flow here would not cause problems, sorry the log > confused you, I will refresh it. But I think > pci_scan_bus()/pci_scan_root_bus() > which could only be used during system boot up(before module_init) make > the pci scan logic obscure. Because most callers additionally call > pci_bus_size_bridges() and pci_bus_assign_resources() later, > so rip out pci_bus_add_devices() from pci_scan_bus()/pci_scan_root_bus() > make code have better readability. I agree that ordering seems odd. I recall there was a reason I had to put it in that order (at that time - which is a few years back now). I can't remember exactly now, but it was something like bridges didn't get resourced properly without a pci scan first. Regards Greg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch V2 0/4] xen: auto-generate symbols for xen hypercalls
Hi, anything missing to take these patches? Juergen On 12/17/2014 10:50 AM, Juergen Gross wrote: The Xen hypercalls are defined in include/xen/interface/xen.h. There are some places where for each hypercall a table element is created. Instead of manually add each hypercall element to these tables use an auto generated header built during the make process of the kernel. Changes in V2: - add "autogenerated" comment to generated header file as suggested by David Vrabel (patch 1) - some minor adjustments to patch 4 as suggested by David Vrabel Juergen Gross (4): xen: build infrastructure for generating hypercall depending symbols xen: synchronize include/xen/interface/xen.h with xen xen: use generated hypervisor symbols in arch/x86/xen/trace.c xen: use generated hypercall symbols in arch/x86/xen/xen-head.S arch/x86/syscalls/Makefile | 9 +++ arch/x86/xen/trace.c| 50 +++ arch/x86/xen/xen-head.S | 63 +++-- include/xen/interface/xen.h | 6 - scripts/xen-hypercalls.sh | 12 + 5 files changed, 40 insertions(+), 100 deletions(-) create mode 100644 scripts/xen-hypercalls.sh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch RESEND] x86: don't rely on VMWare emulating PAT MSR correctly
PING!
The patch repairs a bug with VMWARE, which has been reported by several
users. All of them have confirmed the patch is working. And VMWARE has
acked the patch. What else do you need to take it? It is available for
over a month now!
Juergen
On 01/12/2015 06:15 AM, Juergen Gross wrote:
VMWare seems not to emulate the PAT MSR correctly: reaeding
MSR_IA32_CR_PAT returns 0 even after writing another value to it.
Detect this bug and don't use the read value if it is 0.
Commit bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 ("x86: Enable PAT to
use cache mode translation tables") triggers this VMWare bug when the
kernel is booted as a VMWare guest.
Reported-by: Jongman Heo
Signed-off-by: Juergen Gross
Tested-by: Jongman Heo
Acked-by: Alok N Kataria
---
arch/x86/mm/pat.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index edf299c..7ac6869 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -234,8 +234,13 @@ void pat_init(void)
PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
/* Boot CPU check */
- if (!boot_pat_state)
+ if (!boot_pat_state) {
rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
+ if (!boot_pat_state) {
+ pat_disable("PAT read returns always zero, disabled.");
+ return;
+ }
+ }
wrmsrl(MSR_IA32_CR_PAT, pat);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mach-davinci: Remove driver CDCE949
Hi,
On Monday 19 January 2015 05:07 AM, Rickard Strandqvist wrote:
> Remove driver CDCE949 because it is not used anywhere.
>
> Signed-off-by: Rickard Strandqvist
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
> b/arch/arm/mach-davinci/board-dm646x-evm.c
> index ae129bc..8be5aef 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -45,7 +45,6 @@
> #include
> #include
> #include
> -#include
>
> #include "davinci.h"
> #include "clock.h"
> @@ -399,9 +398,6 @@ static struct i2c_board_info __initdata i2c_info[] = {
> {
> I2C_BOARD_INFO("cpld_video", 0x3b),
> },
> - {
> - I2C_BOARD_INFO("cdce949", 0x6c),
> - },
> };
There is cdce_clk_init() and associated data structures that also need
to be removed.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
lainan hitaammin
hyvää päivää Nämä ovat Skipton Financial Services, tänään tarjoamme lainoja korolla 3%, meidän tyyppinen laina ovat: - yritysten lainoja,sisäisiä lainoja yksityishenkilöille lainat ja perhe lainoja. Jos olet kiinnostunut meidän Laina tarjous Täytä alla oleva lomake. Lainanottajien täydellinen nimi: Määrä tarvitaan Laina: Lainan tarkoitus: Laina Kesto: Puhelin: sukupuoli: Odotamme nopeaa vastausta, jos tarvitset taloudellista tukea. E-mail: skipton_fin-ser...@hotmail.com Kiitos, Toteuta rahoitustarpeet on tavoitteemme! Rebecca allso -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] sched/rt: Consider deadline tasks in cpupri_find()
Currently, RT global scheduling doesn't factor deadline
tasks, this may cause some problems.
See a case below:
On a 3 CPU system, CPU0 has one running deadline task,
CPU1 has one running low priority RT task or idle, CPU3
has one running high priority RT task. When another mid
priority RT task is woken on CPU3, it will be pushed to
CPU0(this also disturbs the deadline task on CPU0), while
it is reasonable to put it on CPU1.
This patch eliminates this issue by filtering CPUs that
have runnable deadline tasks, using cpudl->free_cpus in
cpupri_find().
NOTE: We want to make the most use of percpu local_cpu_mask
to save an extra mask allocation, so always passing a non-NULL
lowest_mask to cpupri_find().
Signed-off-by: Xunlei Pang
---
kernel/sched/core.c | 2 ++
kernel/sched/cpupri.c | 22 +-
kernel/sched/cpupri.h | 1 +
kernel/sched/rt.c | 9 +
4 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ade2958..48c9576 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5652,6 +5652,8 @@ static int init_rootdomain(struct root_domain *rd)
if (cpupri_init(&rd->cpupri) != 0)
goto free_rto_mask;
+
+ rd->cpupri.cpudl = &rd->cpudl;
return 0;
free_rto_mask:
diff --git a/kernel/sched/cpupri.c b/kernel/sched/cpupri.c
index 981fcd7..40b8e81 100644
--- a/kernel/sched/cpupri.c
+++ b/kernel/sched/cpupri.c
@@ -32,6 +32,7 @@
#include
#include
#include "cpupri.h"
+#include "cpudeadline.h"
/* Convert between a 140 based task->prio, and our 102 based cpupri */
static int convert_prio(int prio)
@@ -54,7 +55,7 @@ static int convert_prio(int prio)
* cpupri_find - find the best (lowest-pri) CPU in the system
* @cp: The cpupri context
* @p: The task
- * @lowest_mask: A mask to fill in with selected CPUs (or NULL)
+ * @lowest_mask: A mask to fill in with selected CPUs (not NULL)
*
* Note: This function returns the recommended CPUs as calculated during the
* current invocation. By the time the call returns, the CPUs may have in
@@ -103,24 +104,11 @@ int cpupri_find(struct cpupri *cp, struct task_struct *p,
if (skip)
continue;
- if (cpumask_any_and(&p->cpus_allowed, vec->mask) >= nr_cpu_ids)
+ cpumask_and(lowest_mask, &p->cpus_allowed, vec->mask);
+ cpumask_and(lowest_mask, lowest_mask, cp->cpudl->free_cpus);
+ if (cpumask_any(lowest_mask) >= nr_cpu_ids)
continue;
- if (lowest_mask) {
- cpumask_and(lowest_mask, &p->cpus_allowed, vec->mask);
-
- /*
-* We have to ensure that we have at least one bit
-* still set in the array, since the map could have
-* been concurrently emptied between the first and
-* second reads of vec->mask. If we hit this
-* condition, simply act as though we never hit this
-* priority level and continue on.
-*/
- if (cpumask_any(lowest_mask) >= nr_cpu_ids)
- continue;
- }
-
return 1;
}
diff --git a/kernel/sched/cpupri.h b/kernel/sched/cpupri.h
index 63cbb9c..acd7ccf 100644
--- a/kernel/sched/cpupri.h
+++ b/kernel/sched/cpupri.h
@@ -18,6 +18,7 @@ struct cpupri_vec {
struct cpupri {
struct cpupri_vec pri_to_cpu[CPUPRI_NR_PRIORITIES];
int *cpu_to_pri;
+ struct cpudl *cpudl;
};
#ifdef CONFIG_SMP
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 6725e3c..d28cfa4 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1349,14 +1349,17 @@ out:
return cpu;
}
+static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask);
static void check_preempt_equal_prio(struct rq *rq, struct task_struct *p)
{
+ struct cpumask *lowest_mask = this_cpu_cpumask_var_ptr(local_cpu_mask);
+
/*
* Current can't be migrated, useless to reschedule,
* let's hope p can move out.
*/
if (rq->curr->nr_cpus_allowed == 1 ||
- !cpupri_find(&rq->rd->cpupri, rq->curr, NULL))
+ !cpupri_find(&rq->rd->cpupri, rq->curr, lowest_mask))
return;
/*
@@ -1364,7 +1367,7 @@ static void check_preempt_equal_prio(struct rq *rq,
struct task_struct *p)
* see if it is pushed or pulled somewhere else.
*/
if (p->nr_cpus_allowed != 1
- && cpupri_find(&rq->rd->cpupri, p, NULL))
+ && cpupri_find(&rq->rd->cpupri, p, lowest_mask))
return;
/*
@@ -1526,8 +1529,6 @@ static struct task_struct
*pick_highest_pushable_task(struct rq *rq, int cpu)
return NULL;
}
-static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask);
-
static int find_lowest_rq(struct task_struct *tas
[Bugfix 0/3] Fix regressions in Xen IRQ management
Hi all,
Sander reports an Xen pci-passthrough regression caused by
commit cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 ("x86, irq: Keep
balance of IOAPIC pin reference count"). This patch set tries to
fix it.
Patch 1 is a fix for another issue found during fixing the regression.
Patch 2 is a hotfix for the regression and should be targeted for v3.19.
Patch 3 is the foundamental fix for the regression and should be targeted
at v3.20.
Hi Sander,
Could you please help to test by:
1) only apply patch 1 and patch 2
2) and then apply patch 3 ontop of patch 1/2.
Thanks!
Gerry
Jiang Liu (3):
xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
cffe0a2b5a34
xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
x86/PCI: Refine the way to release PCI IRQ resources
arch/x86/include/asm/acpi.h|1 +
arch/x86/include/asm/pci_x86.h |2 --
arch/x86/pci/common.c | 30 --
arch/x86/pci/intel_mid_pci.c |4 ++--
arch/x86/pci/irq.c | 15 +--
arch/x86/pci/xen.c |2 ++
drivers/acpi/pci_irq.c | 10 +-
7 files changed, 35 insertions(+), 29 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] sched/deadline: Remove cpu_active_mask from cpudl_find()
cpu_active_mask is rarely changeable, so remove this operation
to gain a little performance.
If there is a change in cpu_active_mask, rq_online_dl() and
rq_offline_dl() should take care of it normally, so cpudl::
free_cpus carries enough information for us.
For the rare case(causing a task put onto a dying cpu) which
rq_offline_dl() can't handle timely, then it can be handled
through _cpu_down()->...->multi_cpu_stop()->migration_call()
->migrate_tasks(), preventing the task from hanging on the
dead cpu.
Signed-off-by: Xunlei Pang
---
kernel/sched/cpudeadline.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index fd9d3fb..c6acb07 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -108,8 +108,7 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
const struct sched_dl_entity *dl_se = &p->dl;
if (later_mask &&
- cpumask_and(later_mask, cp->free_cpus, &p->cpus_allowed) &&
- cpumask_and(later_mask, later_mask, cpu_active_mask)) {
+ cpumask_and(later_mask, cp->free_cpus, &p->cpus_allowed)) {
best_cpu = cpumask_any(later_mask);
goto out;
} else if (cpumask_test_cpu(cpudl_maximum(cp), &p->cpus_allowed) &&
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] sched/deadline: Fix wrong cpudl_find() in check_preempt_equal_dl()
In check_preempt_equal_dl(), cpudl_find() is called with a NULL
later_mask, thus cpudl_find() here doesn't check cpudl::free_cpus
at all.
This patch takles this issue by always passing a non-NULL later_mask
to cpudl_find(), thereby fixing this issue.
Signed-off-by: Xunlei Pang
---
kernel/sched/cpudeadline.c | 8 +++-
kernel/sched/deadline.c| 15 +++
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index c6acb07..f331fcf 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -97,7 +97,7 @@ static inline int cpudl_maximum(struct cpudl *cp)
* cpudl_find - find the best (later-dl) CPU in the system
* @cp: the cpudl max-heap context
* @p: the task
- * @later_mask: a mask to fill in with the selected CPUs (or NULL)
+ * @later_mask: a mask to fill in with the selected CPUs (not NULL)
*
* Returns: int - best CPU (heap maximum if suitable)
*/
@@ -107,15 +107,13 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
int best_cpu = -1;
const struct sched_dl_entity *dl_se = &p->dl;
- if (later_mask &&
- cpumask_and(later_mask, cp->free_cpus, &p->cpus_allowed)) {
+ if (cpumask_and(later_mask, cp->free_cpus, &p->cpus_allowed)) {
best_cpu = cpumask_any(later_mask);
goto out;
} else if (cpumask_test_cpu(cpudl_maximum(cp), &p->cpus_allowed) &&
dl_time_before(dl_se->deadline, cp->elements[0].dl)) {
best_cpu = cpudl_maximum(cp);
- if (later_mask)
- cpumask_set_cpu(best_cpu, later_mask);
+ cpumask_set_cpu(best_cpu, later_mask);
}
out:
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index e7b2722..82d900f 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -943,14 +943,23 @@ out:
return cpu;
}
+static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask_dl);
+
static void check_preempt_equal_dl(struct rq *rq, struct task_struct *p)
{
+ struct cpumask *later_mask =
+ this_cpu_cpumask_var_ptr(local_cpu_mask_dl);
+
+ /* Make sure the mask is initialized first */
+ if (unlikely(!later_mask))
+ return;
+
/*
* Current can't be migrated, useless to reschedule,
* let's hope p can move out.
*/
if (rq->curr->nr_cpus_allowed == 1 ||
- cpudl_find(&rq->rd->cpudl, rq->curr, NULL) == -1)
+ cpudl_find(&rq->rd->cpudl, rq->curr, later_mask) == -1)
return;
/*
@@ -958,7 +967,7 @@ static void check_preempt_equal_dl(struct rq *rq, struct
task_struct *p)
* see if it is pushed or pulled somewhere else.
*/
if (p->nr_cpus_allowed != 1 &&
- cpudl_find(&rq->rd->cpudl, p, NULL) != -1)
+ cpudl_find(&rq->rd->cpudl, p, later_mask) != -1)
return;
resched_curr(rq);
@@ -1145,8 +1154,6 @@ next_node:
return NULL;
}
-static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask_dl);
-
static int find_later_rq(struct task_struct *task)
{
struct sched_domain *sd;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] sched/rt: Optimize find_lowest_rq() to select a cache hot cpu
In find_lowest_rq(), if we can't find a wake_affine cpu from
sched_domain, then we can actually determine a cache hot cpu
instead of simply calling "cpumask_any(lowest_mask)" which
always returns the first cpu in the mask.
So, we can determine the cache hot cpu during the interation of
sched_domain() in passing.
Signed-off-by: Xunlei Pang
---
kernel/sched/rt.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index d28cfa4..e6a42e6 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1535,6 +1535,7 @@ static int find_lowest_rq(struct task_struct *task)
struct cpumask *lowest_mask = this_cpu_cpumask_var_ptr(local_cpu_mask);
int this_cpu = smp_processor_id();
int cpu = task_cpu(task);
+ int cachehot_cpu = nr_cpu_ids;
/* Make sure the mask is initialized first */
if (unlikely(!lowest_mask))
@@ -1566,8 +1567,12 @@ static int find_lowest_rq(struct task_struct *task)
rcu_read_lock();
for_each_domain(cpu, sd) {
+ if (cachehot_cpu >= nr_cpu_ids)
+ cachehot_cpu = cpumask_first_and(lowest_mask,
+ sched_domain_span(sd));
+
if (sd->flags & SD_WAKE_AFFINE) {
- int best_cpu;
+ int wakeaffine_cpu;
/*
* "this_cpu" is cheaper to preempt than a
@@ -1579,16 +1584,20 @@ static int find_lowest_rq(struct task_struct *task)
return this_cpu;
}
- best_cpu = cpumask_first_and(lowest_mask,
+ wakeaffine_cpu = cpumask_first_and(lowest_mask,
sched_domain_span(sd));
- if (best_cpu < nr_cpu_ids) {
+ if (wakeaffine_cpu < nr_cpu_ids) {
rcu_read_unlock();
- return best_cpu;
+ return wakeaffine_cpu;
}
}
}
rcu_read_unlock();
+ /* most likely cache-hot */
+ if (cachehot_cpu < nr_cpu_ids)
+ return cachehot_cpu;
+
/*
* And finally, if there were no matches within the domains
* just give the caller *something* to work with from the compatible
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] sched/deadline: Modify cpudl::free_cpus to reflect rd->online
Currently, cpudl::free_cpus contains all cpus during init, see
cpudl_init(). When calling cpudl_find(), we have to add rd->span
to avoid selecting the cpu outside current root domain, because
cpus_allowed is undependable when performing clustered scheduling
using the cpuset, see find_later_rq().
This patch adds cpudl_set_freecpu() and cpudl_clear_freecpu() for
changing cpudl::free_cpus when doing rq_online_dl()/rq_offline_dl(),
so we can avoid the rd->span operation when calling cpudl_find()
in find_later_rq().
Signed-off-by: Xunlei Pang
---
kernel/sched/cpudeadline.c | 28
kernel/sched/cpudeadline.h | 2 ++
kernel/sched/deadline.c| 5 ++---
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index 539ca3c..fd9d3fb 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -107,7 +107,9 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
int best_cpu = -1;
const struct sched_dl_entity *dl_se = &p->dl;
- if (later_mask && cpumask_and(later_mask, later_mask, cp->free_cpus)) {
+ if (later_mask &&
+ cpumask_and(later_mask, cp->free_cpus, &p->cpus_allowed) &&
+ cpumask_and(later_mask, later_mask, cpu_active_mask)) {
best_cpu = cpumask_any(later_mask);
goto out;
} else if (cpumask_test_cpu(cpudl_maximum(cp), &p->cpus_allowed) &&
@@ -186,6 +188,26 @@ out:
}
/*
+ * cpudl_set_freecpu - Set the cpudl.free_cpus
+ * @cp: the cpudl max-heap context
+ * @cpu: rd attached cpu
+ */
+void cpudl_set_freecpu(struct cpudl *cp, int cpu)
+{
+ cpumask_set_cpu(cpu, cp->free_cpus);
+}
+
+/*
+ * cpudl_clear_freecpu - Clear the cpudl.free_cpus
+ * @cp: the cpudl max-heap context
+ * @cpu: rd attached cpu
+ */
+void cpudl_clear_freecpu(struct cpudl *cp, int cpu)
+{
+ cpumask_clear_cpu(cpu, cp->free_cpus);
+}
+
+/*
* cpudl_init - initialize the cpudl structure
* @cp: the cpudl max-heap context
*/
@@ -203,7 +225,7 @@ int cpudl_init(struct cpudl *cp)
if (!cp->elements)
return -ENOMEM;
- if (!alloc_cpumask_var(&cp->free_cpus, GFP_KERNEL)) {
+ if (!zalloc_cpumask_var(&cp->free_cpus, GFP_KERNEL)) {
kfree(cp->elements);
return -ENOMEM;
}
@@ -211,8 +233,6 @@ int cpudl_init(struct cpudl *cp)
for_each_possible_cpu(i)
cp->elements[i].idx = IDX_INVALID;
- cpumask_setall(cp->free_cpus);
-
return 0;
}
diff --git a/kernel/sched/cpudeadline.h b/kernel/sched/cpudeadline.h
index 020039b..1a0a6ef 100644
--- a/kernel/sched/cpudeadline.h
+++ b/kernel/sched/cpudeadline.h
@@ -24,6 +24,8 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
struct cpumask *later_mask);
void cpudl_set(struct cpudl *cp, int cpu, u64 dl, int is_valid);
int cpudl_init(struct cpudl *cp);
+void cpudl_set_freecpu(struct cpudl *cp, int cpu);
+void cpudl_clear_freecpu(struct cpudl *cp, int cpu);
void cpudl_cleanup(struct cpudl *cp);
#endif /* CONFIG_SMP */
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index b52092f..e7b2722 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1165,9 +1165,6 @@ static int find_later_rq(struct task_struct *task)
* We have to consider system topology and task affinity
* first, then we can look for a suitable cpu.
*/
- cpumask_copy(later_mask, task_rq(task)->rd->span);
- cpumask_and(later_mask, later_mask, cpu_active_mask);
- cpumask_and(later_mask, later_mask, &task->cpus_allowed);
best_cpu = cpudl_find(&task_rq(task)->rd->cpudl,
task, later_mask);
if (best_cpu == -1)
@@ -1562,6 +1559,7 @@ static void rq_online_dl(struct rq *rq)
if (rq->dl.overloaded)
dl_set_overload(rq);
+ cpudl_set_freecpu(&rq->rd->cpudl, rq->cpu);
if (rq->dl.dl_nr_running > 0)
cpudl_set(&rq->rd->cpudl, rq->cpu, rq->dl.earliest_dl.curr, 1);
}
@@ -1573,6 +1571,7 @@ static void rq_offline_dl(struct rq *rq)
dl_clear_overload(rq);
cpudl_set(&rq->rd->cpudl, rq->cpu, 0, 0);
+ cpudl_clear_freecpu(&rq->rd->cpudl, rq->cpu);
}
void init_sched_dl_class(void)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Bugfix 2/3] xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
Xen overrides __acpi_register_gsi and leaves __acpi_unregister_gsi as is.
That means, an IRQ allocated by acpi_register_gsi_xen_hvm() or
acpi_register_gsi_xen() will be freed by acpi_unregister_gsi_ioapic(),
which may cause undesired effects. So override __acpi_unregister_gsi to
NULL for safety.
Signed-off-by: Jiang Liu
---
arch/x86/include/asm/acpi.h |1 +
arch/x86/pci/xen.c |2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 0ab4f9fd2687..3a45668f6dc3 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -50,6 +50,7 @@ void acpi_pic_sci_set_trigger(unsigned int, u16);
extern int (*__acpi_register_gsi)(struct device *dev, u32 gsi,
int trigger, int polarity);
+extern void (*__acpi_unregister_gsi)(u32 gsi);
static inline void disable_acpi(void)
{
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 6e5e89c3c644..9098d880c476 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -458,6 +458,7 @@ int __init pci_xen_hvm_init(void)
* just how GSIs get registered.
*/
__acpi_register_gsi = acpi_register_gsi_xen_hvm;
+ __acpi_unregister_gsi = NULL;
#endif
#ifdef CONFIG_PCI_MSI
@@ -482,6 +483,7 @@ int __init pci_xen_initial_domain(void)
pci_msi_ignore_mask = 1;
#endif
__acpi_register_gsi = acpi_register_gsi_xen;
+ __acpi_unregister_gsi = NULL;
/* Pre-allocate legacy irqs */
for (irq = 0; irq < nr_legacy_irqs(); irq++) {
int trigger, polarity;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Bugfix 3/3] x86/PCI: Refine the way to release PCI IRQ resources
Some PCI device drivers assume that pci_dev->irq won't change after
calling pci_disable_device() and pci_enable_device() during suspend and
resume.
Commit c03b3b0738a56cf283b0d05256988d5e3c8bd719 ("x86, irq, mpparse:
Release IOAPIC pin when PCI device is disabled") frees PCI IRQ
resources when pci_disable_device() is called and reallocate IRQ
resources when pci_enable_device() is called again. This breaks
above assumption. So commit 3eec595235c1 ("x86, irq, PCI: Keep IRQ
assignment for PCI devices during suspend/hibernation") and
9eabc99a635a ("x86, irq, PCI: Keep IRQ assignment for runtime power
management") fix the issue by avoiding freeing/reallocating IRQ
resources during PCI device suspend/resume. They achieve this by
checking dev.power.is_prepared and dev.power.runtime_status.
PM maintainer, Rafael, then pointed out that it's really an ugly fix
which leaking PM internal state information to IRQ subsystem.
Recently David Vrabel also reports an
regression in pciback driver caused by commit cffe0a2b5a34 ("x86, irq:
Keep balance of IOAPIC pin reference count"). Please refer to:
http://lkml.org/lkml/2015/1/14/546
So this patch refine the way to release PCI IRQ resources. Instead of
releasing PCI IRQ resources in pci_disable_device()/
pcibios_disable_device(), we now release it at driver unbinding
notification BUS_NOTIFY_UNBOUND_DRIVER. In other word, we only release
PCI IRQ resources when there's no driver bound to the PCI device, and
it keeps the assumption that pci_dev->irq won't through multiple
invocation of pci_enable_device()/pci_disable_device().
Signed-off-by: Jiang Liu
---
arch/x86/include/asm/pci_x86.h |2 --
arch/x86/pci/common.c | 30 --
arch/x86/pci/intel_mid_pci.c |4 ++--
arch/x86/pci/irq.c | 15 +--
drivers/acpi/pci_irq.c |9 +
5 files changed, 32 insertions(+), 28 deletions(-)
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 164e3f8d3c3d..fa1195dae425 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -93,8 +93,6 @@ extern raw_spinlock_t pci_config_lock;
extern int (*pcibios_enable_irq)(struct pci_dev *dev);
extern void (*pcibios_disable_irq)(struct pci_dev *dev);
-extern bool mp_should_keep_irq(struct device *dev);
-
struct pci_raw_ops {
int (*read)(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 *val);
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 7b20bccf3648..99f15ed19f38 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -497,6 +497,25 @@ void __init pcibios_set_cache_line_size(void)
}
}
+static int pci_irq_notifier(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ struct pci_dev *dev = to_pci_dev(data);
+
+ if (action != BUS_NOTIFY_UNBOUND_DRIVER)
+ return NOTIFY_DONE;
+
+ if (pcibios_disable_irq)
+ pcibios_disable_irq(dev);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block pci_irq_nb = {
+ .notifier_call = pci_irq_notifier,
+ .priority = INT_MIN,
+};
+
int __init pcibios_init(void)
{
if (!raw_pci_ops) {
@@ -509,6 +528,9 @@ int __init pcibios_init(void)
if (pci_bf_sort >= pci_force_bf)
pci_sort_breadthfirst();
+
+ bus_register_notifier(&pci_bus_type, &pci_irq_nb);
+
return 0;
}
@@ -669,8 +691,12 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
void pcibios_disable_device (struct pci_dev *dev)
{
- if (!pci_dev_msi_enabled(dev) && pcibios_disable_irq)
- pcibios_disable_irq(dev);
+ /*
+* Some device drivers assume dev->irq won't change after calling
+* pci_disable_device(). So delay releasing of IRQ resource to driver
+* unbinding time. Otherwise it will break PM subsystem and drivers
+* like xen-pciback etc.
+*/
}
int pci_ext_cfg_avail(void)
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 44b9271580b5..95c2471f6819 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -234,10 +234,10 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
static void intel_mid_pci_irq_disable(struct pci_dev *dev)
{
- if (!mp_should_keep_irq(&dev->dev) && dev->irq_managed &&
- dev->irq > 0) {
+ if (dev->irq_managed && dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
+ dev->irq = 0;
}
}
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 5dc6ca5e1741..e71b3dbd87b8 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1256,22 +1256,9 @@ static int pirq_enable_irq(struct pci_dev *dev)
return 0;
}
-bool mp_should_keep_irq(struct device *dev)
-{
- if (dev->power.is_prepar
Re: [PATCH] n_tty: Remove LINEMODE support
Line mode goes back to BSD 4.x days, and it's useful over high latency links --- i.e., the sort of thing that you get with stone age cellular data networks (i.e., the sort of thing that we still have the US), amateur packet radio links, etc. So it's certianly a nice to have, if someone is willing to support it and the maintenance burden on the rest of the tty stack isn't too onerous. OTOH, one could argue that with something like mosh, if you can get that working across a particular firewall, it solves the probably much more portably without requiring kernel hacks. Mosh couldn't be used on amateur packet links, since it uses encryption, which is verboten for ham radio. But for other high latency links, mosh does work fairly well, without requiring EXTPROC in the kernel. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Bugfix 1/3] xen/irq, ACPI: Fix regression in xen PCI passthrough caused by cffe0a2b5a34
Xen pciback driver assumes that pci_dev->irq won't change after calling
pci_disable_device(). But commit cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687
("x86, irq: Keep balance of IOAPIC pin reference count") frees irq
resources and resets pci_dev->irq to zero when pci_disable_device() is
called.
So this is a hotfix for 3.19 to avoid resetting pci_dev->irq, and
another proper fix will be prepared for next merging window.
Signed-off-by: Jiang Liu
---
drivers/acpi/pci_irq.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 5277a0ee5704..b1def411c0b8 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -512,7 +512,6 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
dev_dbg(&dev->dev, "PCI INT %c disabled\n", pin_name(pin));
if (gsi >= 0) {
acpi_unregister_gsi(gsi);
- dev->irq = 0;
dev->irq_managed = 0;
}
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugfix v4 1/2] xen/pci: Fix xen IRQ allocation failure caused by commit b81975eade8c
On 2015/1/17 2:13, Konrad Rzeszutek Wilk wrote: > On Thu, Jan 15, 2015 at 09:04:35PM +0800, Jiang Liu wrote: >> >> Note: we need to test this patch on those special AMD systems which >> override normal SCI GSI (9) with strange GSI (20). > > [0.00] DMI: Supermicro X8DTN/X8DTN, BIOS 2.1c 10/28/2011 > .. > 0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) > [0.00] ACPI: IRQ0 used by override. > .. > 6.358737] xen: registering gsi 20 triggering 0 polarity 1 > [6.358756] xen: --> pirq=20 -> irq=20 (gsi=20) > ... > -bash-4.1# cat /proc/interrupts |grep acpi > 20: 0 0 0 xen-pirq-ioapic-level acpi Hi Konrad, May I assume an Tested-by from you here? Thanks! Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugfix v4 1/2] xen/pci: Fix xen IRQ allocation failure caused by commit b81975eade8c
On 2015/1/17 2:13, Konrad Rzeszutek Wilk wrote: > On Thu, Jan 15, 2015 at 09:04:35PM +0800, Jiang Liu wrote: >> >> Note: we need to test this patch on those special AMD systems which >> override normal SCI GSI (9) with strange GSI (20). > > [0.00] DMI: Supermicro X8DTN/X8DTN, BIOS 2.1c 10/28/2011 > .. > 0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) > [0.00] ACPI: IRQ0 used by override. > .. > 6.358737] xen: registering gsi 20 triggering 0 polarity 1 > [6.358756] xen: --> pirq=20 -> irq=20 (gsi=20) > ... > -bash-4.1# cat /proc/interrupts |grep acpi > 20: 0 0 0 xen-pirq-ioapic-level acpi > Thanks Konrad, it works as expected. Previously IRQ9 was assigned to ACPI SCI GSI 20, now it assigns IRQ20. But that's OK, ACPI has no special requirement about the assigned IRQ number, we could assign any valid IRQ number for ACPI SCI GSI. Thanks! Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] Perf tool fixes for ARC + uClibc
Hi Arnaldo,
On Wednesday 14 January 2015 07:29 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jan 14, 2015 at 01:00:00PM +0100, Jiri Olsa escreveu:
>> > On Tue, Jan 13, 2015 at 07:13:19PM +0530, Vineet Gupta wrote:
>>> > > Hi,
>>> > >
>>> > > This series based off linux-next of 20150105 allows us to build/use perf
>>> > > for ARC with uClibc based userland.
>>> > >
>>> > > v3: Changes since v2 [2]
>>> > > * 1/5 : Ack from Jiri
>>> > > * 2/5 : no changes
>>> > > * 3/5 : sys/syscall.h included [Jiri]
>>> > > * 4/5 : no changes
>>> > > * 5/5 : -lpthread added to link target [Jiri]
>>> > > * {1,5} : Changelog updated so scissor lines don't start at column 1
>> >
>> > Acked-by: Jiri Olsa
> Most are already in my perf/urgent branch.
>
> - Arnaldo
Are you planning to add {4,5}/5 for next window or did u drop/miss them ?
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated
On 01/18/2015 01:18 AM, Christoph Lameter wrote: On Sat, 17 Jan 2015, Vinayak Menon wrote: which had not updated the vmstat_diff. This CPU was in idle for around 30 secs. When I looked at the tvec base for this CPU, the timer associated with vmstat_update had its expiry time less than current jiffies. This timer had its deferrable flag set, and was tied to the next non-deferrable timer in the We can remove the deferrrable flag now since the vmstat threads are only activated as necessary with the recent changes. Looks like this could fix your issue? Yes, this should fix my issue. But I think we may need the fix in too_many_isolated, since there can still be a delay of few seconds (HZ by default and even more because of reasons pointed out by Michal) which will result in reclaimers unnecessarily entering congestion_wait. No ? -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 06/17] ARM64 / ACPI: Make PCI optional for ACPI on ARM64
On 2015年01月18日 17:29, Graeme Gregory wrote: On Sun, Jan 18, 2015 at 02:46:35PM +0800, Hanjun Guo wrote: On 2015年01月18日 14:31, Jon Masters wrote: Hi Folks, Sorry for top posting from bed. The mainstream servers will all likely do PCIe but there are several that may not. They should not be excluded. That said, if we booted a previously built kernel on a system without an MCFG and got no ECAM/root then things would probably still work. I think it'll work out either way but for the record there is no requirement to do PCIe on ARM servers that conform to spec. OK, Catalin already said that was not the main point of the comments for this patch, I think the title and change log of the patch is inconsistent with the code makes Catalin confused, I will update them in next version. Well what we are talking about is the presence of CONFIG_PCI=y which even in Jons case will be true as he wants to run the same kernel on both sets of hardware. Now the architecture has PCI support I think its safe to remove the make PCI optional part of the patch as this should be handled runtime not compile time. I missed that part, must be something wrong work in Sunday :) I will update the patch with ACPI depends on PCI, which makes thing much simpler. Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] thermal: rockchip: make temperature reporting much more accurate
Hi Caesar,
Some drive-by review comments inline...
On Mon, Jan 19, 2015 at 7:55 AM, Caesar Wang wrote:
> In general, the kernel should report temperature readings exactly as
> reported by the hardware. The cpu / gpu thermal driver works in 5 degree
> increments,but we ought to do more accurate. The temperature will do
> linear interpolation between the entries in the table.
>
> Test= $md5sum /dev/zero &
> $while true; do grep "" /sys/class/thermal/thermal_zone[1-2]/temp;
> sleep .5; done
>
> e.g. We can get the result as follows:
> /sys/class/thermal/thermal_zone1/temp:39994
> /sys/class/thermal/thermal_zone2/temp:39086
> /sys/class/thermal/thermal_zone1/temp:39994
> /sys/class/thermal/thermal_zone2/temp:39540
> /sys/class/thermal/thermal_zone1/temp:39540
> /sys/class/thermal/thermal_zone2/temp:39540
> /sys/class/thermal/thermal_zone1/temp:39540
> /sys/class/thermal/thermal_zone2/temp:39994
>
> Signed-off-by: Caesar Wang
> Reviewed-by: Dmitry Torokhov
>
> ---
>
> Changes in v2:
> Reviewed-by: Dmitry Torokhov
>
> drivers/thermal/rockchip_thermal.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/thermal/rockchip_thermal.c
> b/drivers/thermal/rockchip_thermal.c
> index 1bcddfc..a7ae23a 100644
> --- a/drivers/thermal/rockchip_thermal.c
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -193,19 +193,18 @@ static u32 rk_tsadcv2_temp_to_code(long temp)
>
> static long rk_tsadcv2_code_to_temp(u32 code)
> {
> - int high, low, mid;
> -
> - low = 0;
> - high = ARRAY_SIZE(v2_code_table) - 1;
> - mid = (high + low) / 2;
> + unsigned int low = 0;
> + unsigned int high = ARRAY_SIZE(v2_code_table) - 1;
> + unsigned int mid = (low + high) / 2;
> + unsigned int scale;
>
> if (code > v2_code_table[low].code || code < v2_code_table[high].code)
> return 125000; /* No code available, return max temperature */
I think if the temp sensor reading was invalid we should return an
error code rather than just silently returning "max temp".
Returning an error here could then be propagated up by its only
caller, the ->get_temp() callback.
Note: 'code < v2_code_table[high].code' is always false, since code is
unsigned, and the last entry is 0.
Also, the check above doesn't reject "code == 0xfff".
Even worse, I believe in that case the below algorithm will eventually
set mid=0 and access v2_code_table[-1].code.
>
> while (low <= high) {
> - if (code >= v2_code_table[mid].code && code <
> - v2_code_table[mid - 1].code)
> - return v2_code_table[mid].temp;
> + if (code >= v2_code_table[mid].code &&
> + code < v2_code_table[mid - 1].code)
> + break;
> else if (code < v2_code_table[mid].code)
> low = mid + 1;
> else
> @@ -213,7 +212,16 @@ static long rk_tsadcv2_code_to_temp(u32 code)
> mid = (low + high) / 2;
> }
>
> - return 125000;
> + /*
> +* The 5C granularity provided by the table is too much. Let's
> +* assume that the relationship between sensor readings and
> +* temperature between 2 table entries is linear and extrapolate
I think this is "interpolate", not "extrapolate".
> +* to produce less granular result.
> +*/
> + scale = (v2_code_table[mid].temp - v2_code_table[mid - 1].temp) /
> + (v2_code_table[mid - 1].code - v2_code_table[mid].code);
> + return v2_code_table[mid - 1].temp +
> + (v2_code_table[mid - 1].code - code) * scale;
Assuming the product fits in an unsigned long (and it will, since code
is only 12-bits), it is more precise to multiply first and then
divide, something like this:
num = v2_code_table[mid].temp - v2_code_table[mid - 1].temp;
num *= v2_code_table[mid - 1].code - code;
denom = v2_code_table[mid - 1].code - v2_code_table[mid].code;
return v2_code_table[mid - 1].temp + (num / denom);
-Daniel
> }
>
> /**
> --
> 1.9.1
>
>
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] gpio: lib-sysfs: Add 'wakeup' attribute
On Sat, Jan 17, 2015 at 1:49 AM, Sören Brinkmann wrote: > On Fri, 2015-01-16 at 12:11PM +0100, Johan Hovold wrote: >> On Thu, Jan 15, 2015 at 11:49:49AM -0800, Soren Brinkmann wrote: >> > Add an attribute 'wakeup' to the GPIO sysfs interface which allows >> > marking/unmarking a GPIO as wake IRQ. >> > The file 'wakeup' is created in each exported GPIOs directory, if an IRQ >> > is associated with that GPIO and the irqchip implements set_wake(). >> > Writing 'enabled' to that file will enable wake for that GPIO, while >> > writing 'disabled' will disable wake. >> > Reading that file will return either 'disabled' or 'enabled' depening on >> > the currently set flag for the GPIO's IRQ. >> > >> > Signed-off-by: Soren Brinkmann >> > Reviewed-by: Alexandre Courbot >> > --- >> > Hi Linus, Johan, >> > >> > I rebased my patch. And things look good. >> >> I took at closer look at this patch now and I really don't think it >> should be merged at all. >> >> We have a mechanism for handling wake-up sources (documented in >> Documentation/power/devices.txt) as well as an ABI to enable/disable >> them using the power/wakeup device attribute from userspace. > > Doesn't work for GPIOs AFAIK. > >> >> Implementing proper wakeup support for unclaimed GPIOs would take some >> work (if at all desired), but that is not a reason to be adding custom >> implementations that violates the kernel's power policies and new ABIs >> that would need to be maintained forever. > > These are claimed, by the sysfs interface. > >> >> [ And we really shouldn't be adding anything to the broken gpio sysfs >> interface until it's been redesigned. ] >> >> Meanwhile you can (should) use gpio-keys if you need to wake your system >> on gpio events. > > We had that discussion and I don't think GPIO keys is the right solution > for every use-case. Sorry, it has been a while - can you remind us of why? >> >> > But the 'is_visible' things does not behave the way I expected it to. >> > It seems to be only triggered on an export but not when attributes >> > change. Hence, in my case, everything was visiible since the inital >> > state matches that, but even when changing the direction or things >> > like that, attributes don't disappear. Is that something still worked >> > on? Expected >> >> That's expected. We generally don't want attributes to appear or >> disappear after the device has been registered (although there is a >> mechanism for cases were it makes sense). This is no different from >> how your v3 patch worked either. > > Sure, but the is_visible thing is effectively broken for GPIO. I think a > GPIO is in a defined state when exported and the checks all work on that > state during export. But then this state can be changed through the > sysfs interface. So, if the initial state hides something it becomes > unavailable for all times and, vice versa, if the initial state makes > something visible, it will stay even when it is no longer a valid > property to change. Is there anything that prevents you from patching other GPIO sysfs hooks to remove/reenable the wakeup property as needed? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 4/4] leds: no longer use unnamed gpios
On Mon, Jan 19, 2015 at 12:43 PM, Alexandre Courbot wrote:
> On Wed, Jan 14, 2015 at 10:20 PM, Olliver Schinagl wrote:
>>
>> On 14-01-15 13:45, Linus Walleij wrote:
>>>
>>> On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhov
>>> wrote:
On Thu, Jan 08, 2015 at 08:40:20AM -0600, Rob Herring wrote:
>
> On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl
> wrote:
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -184,7 +184,7 @@ static struct gpio_leds_priv
*gpio_leds_create(struct
platform_device *pdev)
struct gpio_led led = {};
const char *state = NULL;
- led.gpiod = devm_get_gpiod_from_child(dev, NULL,
child);
+ led.gpiod = devm_get_gpiod_from_child(dev, "led",
child);
>>>
>>> Would not this break existing boards using old bindings? You need to
>>> handle both cases: if you can't located "led-gpios" then you will have
>>> to
>>> try just "gpios".
>>
>> Very true. I was rather even hoping we could update all bindings, I
>> don't
>> mind going through the available dts files to fix them ... But need to
>> know
>> that that's the proper way to go before doing the work ;)
>
> That will not work. You cannot make changes that require a new dtb
> with a new kernel. This would also break for the other way around
> (i.e. a new dtb and old kernel).
>
> You would have to search for both led-gpios and gpios. I'm not sure if
> we can do that generically for all GPIOs. If you had a node with both
> "blah-gpios" and "gpios", it would break. I would hope there are no
> such cases like that. We also now have to consider how ACPI identifies
> GPIOs and whether this makes sense.
I think only the driver itself can know about such "legacy" mappings and
make a decision.
>>>
>>> Yeah leds-gpio.c will need to be patched to check for "led-gpios" first
>>> and then fall back to "gpios" if not found.
>>
>> yeah I've done the work, just need to double check it and resend a v2.
>>
>> Linus, I assume you want the already applied patches omitted from v2?
>
> Yes, please base new revisions on Linus' devel branch, omitting any
> patches that he has already accepted.
Actually on top of breaking backward compatibility, I think the case
of LED GPIOs is one of thoses where it makes sense to not have a name
(the GPIO usage is obvious from the DT hierarchy, and there cannot be
another one). So I don't feel like this change is really needed (other
patches in this series are still useful though).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/4] gpio: add parameter to allow the use named gpios
On Wed, Jan 7, 2015 at 6:08 PM, Olliver Schinagl
wrote:
> From: Olliver Schinagl
>
> The gpio binding document says that new code should always use named
> gpios. Patch 40b73183 added support to parse a list of gpios from child
> nodes, but does not make it possible to use named gpios. This patch adds
> the con_id property and implements it is done in gpiolib.c, where the
> old-style of using unnamed gpios still works.
This is absolutely correct - thanks for spotting this.
>
> Signed-off-by: Olliver Schinagl
> ---
> drivers/gpio/devres.c | 16 +++-
> drivers/input/keyboard/gpio_keys_polled.c | 2 +-
> drivers/leds/leds-gpio.c | 2 +-
> include/linux/gpio/consumer.h | 1 +
> 4 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
> index 13dbd3d..b7fbe1c 100644
> --- a/drivers/gpio/devres.c
> +++ b/drivers/gpio/devres.c
> @@ -111,23 +111,37 @@ EXPORT_SYMBOL(__devm_gpiod_get_index);
> /**
> * devm_get_gpiod_from_child - get a GPIO descriptor from a device's child
> node
> * @dev: GPIO consumer
> + * @con_id:function within the GPIO consumer
> * @child: firmware node (child of @dev)
> *
> * GPIO descriptors returned from this function are automatically disposed on
> * driver detach.
> */
> struct gpio_desc *devm_get_gpiod_from_child(struct device *dev,
> + const char *con_id,
> struct fwnode_handle *child)
> {
> + static const char const *suffixes[] = { "gpios", "gpio" };
> + char prop_name[32]; /* 32 is max size of property name */
> struct gpio_desc **dr;
> struct gpio_desc *desc;
> + unsigned int i;
>
> dr = devres_alloc(devm_gpiod_release, sizeof(struct gpio_desc *),
> GFP_KERNEL);
> if (!dr)
> return ERR_PTR(-ENOMEM);
>
> - desc = fwnode_get_named_gpiod(child, "gpios");
> + for (i = 0; i < ARRAY_SIZE(suffixes); i++) {
> + if (con_id)
> + snprintf(prop_name, 32, "%s-%s", con_id, suffixes[i]);
> + else
> + snprintf(prop_name, 32, "%s", suffixes[i]);
Same remark as Dmitry about the hardcoded length of the string, but ...
> +
> + desc = fwnode_get_named_gpiod(child, prop_name);
> + if (!IS_ERR(desc) || (PTR_ERR(desc) == -EPROBE_DEFER))
> + break;
> + }
... since it looks like this part has been mostly copy/pasted from
of_find_gpio(), can you add another patch that fixes it there as well?
Also in the case of ACPI this will prove to be an incomplete lookup
since acpi_find_gpio() has an additional fallback if the named lookup
fails.
In that respect, I wonder if it would not be better for
devm_get_gpiod_from_child() to call of_find_gpio() and
acpi_find_gpio() (after making them non-static) followed by
gpiod_request() instead of calling fwnode_get_named_gpiod(). But in
that case it will have to do the OF/ACPI handling by itself.
I'm not really sure about which way is better. I'd appreciate if you
could give a thought to a possible refactoring that would improve the
situation ; otherwise feel free to ignore what I have written above
and to duplicate the property name building code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:core/types] bitops: Add sign_extend8(), 16 and 64 functions
On Mon, Jan 19, 2015 at 7:54 AM, Linus Torvalds wrote: > > The 8- and 16- bit versions are the same as the 32-bit one. Side note: the 64-bit one is actually different on 32-bit architectures, not because it would generate a different value, but because the 64-bit overhead likely kills you. It might be that the compiler is smart enough that we'd *only* need the 64-bit version, but for non-constant bit numbers, it's likely hard for gcc to generate sane single-register versions, and so the 64-bit version is likely fine. But I don't see the 8-bit and 16-bit versions generating better code on any sane architecture. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf fuzzer crash [PATCH] perf: Get group events reference before moving the group
On Fri, 16 Jan 2015, Vince Weaver wrote: > > I just wanted to report that I've tested both this patch and Jiri's > original one and they both keep my easy-to-trigger-testcase from crashing > my core2 machine (when applied against 3.18). I've continued fuzzing all weekend, with PeterZ's patch applied to 3.19-rc4. It has managed to stay up without crashing, impressive. Fuzzing still turns up a few issues but no crashes: [ 1753.904001] WARNING: CPU: 0 PID: 23800 at arch/x86/kernel/hw_breakpoint.c:119 arch_install_hw_breakpoint+0x6a/0xf6() [ 1753.904001] Can't find any breakpoint slot (I thought we had fixed that one). [80608.209702] Uhhuh. NMI received for unknown reason 3d on CPU 0. [80608.212041] Do you have a strange power saving mode enabled? [80608.212041] Dazed and confused, but trying to continue (these are common but don't seem to affect system stability). Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 4/4] leds: no longer use unnamed gpios
On Wed, Jan 14, 2015 at 10:20 PM, Olliver Schinagl wrote:
>
> On 14-01-15 13:45, Linus Walleij wrote:
>>
>> On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhov
>> wrote:
>>>
>>> On Thu, Jan 08, 2015 at 08:40:20AM -0600, Rob Herring wrote:
On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl
wrote:
>>>
>>> --- a/drivers/leds/leds-gpio.c
>>> +++ b/drivers/leds/leds-gpio.c
>>> @@ -184,7 +184,7 @@ static struct gpio_leds_priv
>>> *gpio_leds_create(struct
>>> platform_device *pdev)
>>> struct gpio_led led = {};
>>> const char *state = NULL;
>>>- led.gpiod = devm_get_gpiod_from_child(dev, NULL,
>>> child);
>>> + led.gpiod = devm_get_gpiod_from_child(dev, "led",
>>> child);
>>
>> Would not this break existing boards using old bindings? You need to
>> handle both cases: if you can't located "led-gpios" then you will have
>> to
>> try just "gpios".
>
> Very true. I was rather even hoping we could update all bindings, I
> don't
> mind going through the available dts files to fix them ... But need to
> know
> that that's the proper way to go before doing the work ;)
That will not work. You cannot make changes that require a new dtb
with a new kernel. This would also break for the other way around
(i.e. a new dtb and old kernel).
You would have to search for both led-gpios and gpios. I'm not sure if
we can do that generically for all GPIOs. If you had a node with both
"blah-gpios" and "gpios", it would break. I would hope there are no
such cases like that. We also now have to consider how ACPI identifies
GPIOs and whether this makes sense.
>>>
>>> I think only the driver itself can know about such "legacy" mappings and
>>> make a decision.
>>
>> Yeah leds-gpio.c will need to be patched to check for "led-gpios" first
>> and then fall back to "gpios" if not found.
>
> yeah I've done the work, just need to double check it and resend a v2.
>
> Linus, I assume you want the already applied patches omitted from v2?
Yes, please base new revisions on Linus' devel branch, omitting any
patches that he has already accepted.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the net-next tree
Hi Marcel,
On Sun, 18 Jan 2015 19:13:17 -0800 Marcel Holtmann wrote:
>
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from net/bridge/br.c:22:0:
> > include/net/switchdev.h:73:1: error: expected identifier or '(' before '{'
> > token
> > {
> > ^
> > include/net/switchdev.h:71:19: warning: 'call_netdev_switch_notifiers'
> > declared 'static' but never defined [-Wunused-function]
> > static inline int call_netdev_switch_notifiers(unsigned long val, struct
> > net_device *dev,
> > ^
> >
> > Caused by commit 03bf0c281234 ("switchdev: introduce switchdev notifier").
> >
> > I have used the net-next tree from next-20150116 for today. I also had
> > to use the bluetooth tree from next-20150116 as it was fast forwarded
> > to be the same as the net-next tree today.
>
> it seems Dave forgot to push out his net-next tree, but in theory it should
> contain a fix for it.
Or he did so after I fetched his tree this morning. Either way, I
assume it will be fixed tomorrow.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpcoFswUAoQK.pgp
Description: OpenPGP digital signature
Re: [PATCH 27/28] PCI: Remove platform specific pci_domain_nr()
On 2015/1/16 17:44, Arnd Bergmann wrote:
> On Friday 16 January 2015 09:44:25 Yijing Wang wrote:
>>
>> +int pci_domain_nr(struct pci_bus *bus)
>> +{
>> + struct pci_host_bridge *host = find_pci_host_bridge(bus);
>> +
>> + return host->domain;
>> +}
>> +EXPORT_SYMBOL_GPL(pci_domain_nr);
>> +
>
> Since most of the existing functions are exported as EXPORT_SYMBOL
> rather than EXPORT_SYMBOL_GPL, I think the new version should do
> the same.
Good catch. Thanks!
>
> Arnd
>
> .
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/28] PCI/sparc: Use pci_scan_root_bridge() for simplicity
On 2015/1/16 18:01, Arnd Bergmann wrote:
> On Friday 16 January 2015 09:44:16 Yijing Wang wrote:
>> +static void pci_host_bridge_probe_mode(
>> + struct pci_host_bridge *host)
>> +{
>> + host->of_scan = true;
>> +}
>>
>
> I probably missed something here, but where does host->of_scan
> get used?
>
It is used in __pci_scan_root_bus() to detect whether of scan bus is needed in
patch 11.
@@ -2051,10 +2053,17 @@ static struct pci_bus *__pci_scan_root_bus(
pci_bus_insert_busn_res(b, host->busnum, 255);
}
- max = pci_scan_child_bus(b);
+ if (host->ops && host->ops->phb_probe_mode)
+ host->ops->phb_probe_mode(host);
- if (!found)
- pci_bus_update_busn_res_end(b, max);
+ if (host->of_scan) {
+ if (host->ops &&host->ops->phb_of_scan_bus)
+ host->ops->phb_of_scan_bus(host);
+ } else {
+ max = pci_scan_child_bus(b);
+ if (!found)
+ pci_bus_update_busn_res_end(b, max);
+ }
return b;
Thanks!
Yijing.
> Arnd
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> .
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 23/28] PCI/designware: Use pci_scan_root_bus() for simplicity
On 2015/1/18 0:39, Sergei Shtylyov wrote: > Hello. > > On 1/16/2015 4:44 AM, Yijing Wang wrote: > >> Use pci_scan_root_bus() instead of pci_create_root_bus() + >> pci_scan_child_bus() for simplicity. > >> Signed-off-by: Yijing Wang >> --- >> drivers/pci/host/pcie-designware.c |4 +--- >> 1 files changed, 1 insertions(+), 3 deletions(-) > >> diff --git a/drivers/pci/host/pcie-designware.c >> b/drivers/pci/host/pcie-designware.c >> index eef3111..d37fe27 100644 >> --- a/drivers/pci/host/pcie-designware.c >> +++ b/drivers/pci/host/pcie-designware.c >> @@ -725,13 +725,11 @@ static struct pci_bus *dw_pcie_scan_bus(int nr, struct >> pci_sys_data *sys) >> struct pcie_port *pp = sys_to_pcie(sys); >> >> pp->root_bus_nr = sys->busnr; >> -bus = pci_create_root_bus(pp->dev, sys->busnr, >> +bus = pci_scan_root_bus(pp->dev, sys->busnr, >> &dw_pcie_ops, sys, &sys->resources); > >Please realign this line, so that it still starts under 'pp'. ok. > > WBR, Sergei > > > . > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the net-next tree
Hi Stephen,
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from net/bridge/br.c:22:0:
> include/net/switchdev.h:73:1: error: expected identifier or '(' before '{'
> token
> {
> ^
> include/net/switchdev.h:71:19: warning: 'call_netdev_switch_notifiers'
> declared 'static' but never defined [-Wunused-function]
> static inline int call_netdev_switch_notifiers(unsigned long val, struct
> net_device *dev,
> ^
>
> Caused by commit 03bf0c281234 ("switchdev: introduce switchdev notifier").
>
> I have used the net-next tree from next-20150116 for today. I also had
> to use the bluetooth tree from next-20150116 as it was fast forwarded
> to be the same as the net-next tree today.
it seems Dave forgot to push out his net-next tree, but in theory it should
contain a fix for it.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/28] PCI: Save sysdata in pci_host_bridge drvdata
On 2015/1/16 17:18, Arnd Bergmann wrote:
> On Friday 16 January 2015 09:44:08 Yijing Wang wrote:
>> @@ -2066,11 +2064,11 @@ struct pci_bus *pci_scan_root_bus(struct device
>> *parent, u32 db,
>> {
>> struct pci_host_bridge *host;
>>
>> - host = pci_create_host_bridge(parent, db, resources);
>> + host = pci_create_host_bridge(parent, db, resources, sysdata);
>> if (!host)
>> return NULL;
>>
>> - return __pci_scan_root_bus(host, ops, sysdata);
>> + return __pci_scan_root_bus(host, ops);
>> }
>> EXPORT_SYMBOL(pci_scan_root_bus);
>>
>
> How about keeping the sysdata out of the pci_create_host_bridge interface, and
> refactoring it so that the call sequence becomes
>
> host = pci_create_host_bridge(parent, db, resources);
> host->sysdata = sysdata;
> __pci_scan_root_bus(host, ops);
>
> This way, we can make sysdata completely option. I assume that more of the
> fields we have in sysdata today can get moved into pci_host_bridge
> over time, so a host bridge driver can just assign those members individually
> between pci_create_host_bridge and __pci_scan_root_bus.
I put the sysdata in pci_host_bridge, because some platforms x86/ia64
need to call pcibios_root_bridge_prepare() before pci_host_bridge registration
in pci_create_host_bridge(), and pcibios_root_bridge_prepare() need the
companion
acpi device pointer which is stored in sysdata.
I like you idea, but I haven't find a better way yet.
Thanks!
Yijing.
>
> Arnd
>
> .
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] mfd: rtsx: add support for rts524A
On 01/18/2015 08:20 PM, Lee Jones wrote:
>> +};
>> >+
>> >+void rts524a_init_params(struct rtsx_pcr *pcr)
>> >+{
>> >+ rts5249_init_params(pcr);
>> >+
>> >+ pcr->ops = &rts524a_pcr_ops;
>> >+}
> I see a couple of these now. Why don't you make 'ops' a parameter of
> *_init_params().
>
*_init_params() is called from rtsx_pcr.c, and the ops parameter should
be static, if we make ops as a parameter, the rts524a_pcr_ops defination
should move to rtsx_pcr.c, not
reasonable.N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from net/bridge/br.c:22:0:
include/net/switchdev.h:73:1: error: expected identifier or '(' before '{' token
{
^
include/net/switchdev.h:71:19: warning: 'call_netdev_switch_notifiers' declared
'static' but never defined [-Wunused-function]
static inline int call_netdev_switch_notifiers(unsigned long val, struct
net_device *dev,
^
Caused by commit 03bf0c281234 ("switchdev: introduce switchdev notifier").
I have used the net-next tree from next-20150116 for today. I also had
to use the bluetooth tree from next-20150116 as it was fast forwarded
to be the same as the net-next tree today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpTBOB80I8J8.pgp
Description: OpenPGP digital signature
Re: [PATCH] kprobes: bugfix: checks kprobes_all_disarmed in unoptimized_kprobe().
Hi Masami Hiramatsu,
I can't find this patch and '[PATCH] kprobes: bugfix: checks
kprobes_all_disarmed
in unoptimized_kprobe().' in current mainline. How do these patches get there?
Should they be merged into Russell King's tree first?
Thank you!
On 2015/1/12 20:52, Masami Hiramatsu wrote:
> (2015/01/12 21:09), Wang Nan wrote:
>> Original code failed to disarm the probed instruction after
>>
>> echo 0 > /sys/kernel/debug/kprobes/enabled
>>
>> if OPTPROBE is enabled.
>>
>> This patch checks kprobes_all_disarmed in unoptimized_kprobe().
>>
>
> Looks good :)
>
> Acked-by: Masami Hiramatsu
>
> Thank you!
>
>> Signed-off-by: Wang Nan
>> ---
>> kernel/kprobes.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
>> index 9471710..f16936b 100644
>> --- a/kernel/kprobes.c
>> +++ b/kernel/kprobes.c
>> @@ -630,6 +630,9 @@ static void unoptimize_kprobe(struct kprobe *p, bool
>> force)
>> {
>> struct optimized_kprobe *op;
>>
>> +if (kprobes_all_disarmed)
>> +return;
>> +
>> if (!kprobe_aggrprobe(p) || kprobe_disarmed(p))
>> return; /* This is not an optprobe nor optimized */
>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/10] mfd: rtsx: add support for rts525A
On 01/18/2015 07:13 PM, Lee Jones wrote:
>> @@ -97,7 +97,7 @@ static void rts5249_force_power_down(struct rtsx_pcr *pcr,
>> u8 pm_state)
>> >rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
>> >
>> >if (pm_state == HOST_ENTER_S3) {
>> >- if (PCI_PID(pcr) == 0x524A)
>> >+ if (PCI_PID(pcr) == 0x524A || PCI_PID(pcr) == 0x525A)
> Shouldn't these be defined somewhere?
>
> I have a particular distaste for magic numbers.
>
This is the chip ID number, no need define, just using it.
if we define, it will like RTS525A_PCI_ID, so bad.
Re: [PATCH 09/28] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
On 2015/1/16 17:34, Arnd Bergmann wrote: > On Friday 16 January 2015 09:44:07 Yijing Wang wrote: >> We want to make a generic pci_host_bridge, then we could >> place common PCI infos like domain number in it. Ripping >> out pci_host_bridge creation from pci_create_root_bus() >> make code more better readability. Further more, we could >> use the generic pci_host_bridge to hold host bridge specific >> operations like pcibios_root_bridge_prepare(). >> >> Signed-off-by: Yijing Wang >> > > I assume this patch is doing the right thing, but the description > above doesn't really tell me enough to be sure. > > This is supposed to be transparent to the callers, right? If > so, please mention it explicitly in the text. Sorry, I will refresh the patch log for better description. In this series I have no plan to export the pci_create_host_bridge() to callers, because I think pci_host_bridge_ops could make callers have the ability to setup the platform specific operations. But if this is needed, we could introduce another patches to export it. > > Also you don't explain what the list of host bridges is > used for. Maybe you can split this out into a separate patch > so you have one patch that just moves code from one file > to the other but no functional changes, and a second patch > that exports pci_create_host_bridge and introduces the list, > with an explanation of what it is used for. > pci_host_bridge_list is used to find out whether the pci_host_bridge in domain:bus is already existed, I will split the related code to another patch, thanks. > Arnd > > . > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] regulator: da9211: Add gpio control for enable/disable of buck
This is a patch for adding gpio control about enable/disable of buck.
Signed-off-by: James Ban
---
This patch is relative to linux-next repository tag next-20150115.
Changes in V2:
- gpio name from gpio to gpios.
- add ena_gpio_initialized.
.../devicetree/bindings/regulator/da9211.txt |7 ++-
drivers/regulator/da9211-regulator.c | 16
include/linux/regulator/da9211.h |1 +
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/regulator/da9211.txt
b/Documentation/devicetree/bindings/regulator/da9211.txt
index 240019a..a3b58e8 100644
--- a/Documentation/devicetree/bindings/regulator/da9211.txt
+++ b/Documentation/devicetree/bindings/regulator/da9211.txt
@@ -11,6 +11,7 @@ Required properties:
BUCKA and BUCKB.
Optional properties:
+- buck-enable-platform-gpios: platform gpio for control of BUCKA/BUCKB.
- Any optional property defined in regulator.txt
Example 1) DA9211
@@ -27,6 +28,7 @@ Example 1) DA9211
regulator-max-microvolt = <157>;
regulator-min-microamp = <200>;
regulator-max-microamp = <500>;
+ buck-enable-platform-gpios = <&gpio 27 0>;
};
BUCKB {
regulator-name = "VBUCKB";
@@ -34,11 +36,12 @@ Example 1) DA9211
regulator-max-microvolt = <157>;
regulator-min-microamp = <200>;
regulator-max-microamp = <500>;
+ buck-enable-platform-gpios = <&gpio 17 0>;
};
};
};
-Example 2) DA92113
+Example 2) DA9213
pmic: da9213@68 {
compatible = "dlg,da9213";
reg = <0x68>;
@@ -51,6 +54,7 @@ Example 2) DA92113
regulator-max-microvolt = <157>;
regulator-min-microamp = <300>;
regulator-max-microamp = <600>;
+ buck-enable-platform-gpios = <&gpio 27 0>;
};
BUCKB {
regulator-name = "VBUCKB";
@@ -58,6 +62,7 @@ Example 2) DA92113
regulator-max-microvolt = <157>;
regulator-min-microamp = <300>;
regulator-max-microamp = <600>;
+ buck-enable-platform-gpios = <&gpio 17 0>;
};
};
};
diff --git a/drivers/regulator/da9211-regulator.c
b/drivers/regulator/da9211-regulator.c
index c78d210..84ab88f 100644
--- a/drivers/regulator/da9211-regulator.c
+++ b/drivers/regulator/da9211-regulator.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include "da9211-regulator.h"
@@ -277,6 +278,10 @@ static struct da9211_pdata *da9211_parse_regulators_dt(
pdata->init_data[n] = da9211_matches[i].init_data;
+ pdata->gpio_ren[n] =
+ of_get_named_gpio(da9211_matches[i].of_node,
+ "buck-enable-platform-gpios", 0);
+
n++;
}
@@ -366,6 +371,17 @@ static int da9211_regulator_init(struct da9211 *chip)
config.regmap = chip->regmap;
config.of_node = chip->dev->of_node;
+ if (gpio_is_valid(chip->pdata->gpio_ren[i])) {
+ config.ena_gpio = chip->pdata->gpio_ren[i];
+ config.ena_gpio_initialized = true;
+ } else {
+ config.ena_gpio = -EINVAL;
+ config.ena_gpio_initialized = false;
+ dev_warn(chip->dev,
+ "gpio control : GPIO[%d] not valid, ignoring\n",
+ chip->pdata->gpio_ren[i]);
+ }
+
chip->rdev[i] = devm_regulator_register(chip->dev,
&da9211_regulators[i], &config);
if (IS_ERR(chip->rdev[i])) {
diff --git a/include/linux/regulator/da9211.h b/include/linux/regulator/da9211.h
index 5479394..530b5ea 100644
--- a/include/linux/regulator/da9211.h
+++ b/include/linux/regulator/da9211.h
@@ -32,6 +32,7 @@ struct da9211_pdata {
* 2 : 2 phase 2 buck
*/
int num_buck;
+ int gpio_ren[DA9211_MAX_REGULATORS];
struct regulator_init_data *init_data[DA9211_MAX_REGULATORS];
};
#endif
--
end-of-patch for regulator: da9211: Add gpio control for enable/disable of buck
V2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.k
Re: [PATCH 08/10] mfd: rtsx: add support for rts524A
On 01/18/2015 08:20 PM, Lee Jones wrote:
>> +static int rts524a_optimize_phy(struct rtsx_pcr *pcr)
>> >+{
>> >+ int err;
>> >+
>> >+ err = rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3,
>> >+ D3_DELINK_MODE_EN, 0x00);
>> >+ if (err < 0)
>> >+ return err;
> if (err)
>
err value will never be positive, but I have to make it consistence
with driver in other place, because all the check using if (err < 0) form.
And maybe, it make reserved for future the function may return positive
value.N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 08/10] mfd: rtsx: add support for rts524A
On 01/18/2015 08:20 PM, Lee Jones wrote:
>> @@ -72,8 +72,10 @@ static void rts5249_fetch_vendor_settings(struct rtsx_pcr
>> *pcr)
>> >rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, ®);
>> >dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
>> >
>> >- if (!rtsx_vendor_setting_valid(reg))
>> >+ if (!rtsx_vendor_setting_valid(reg)) {
>> >+ pcr_dbg(pcr, "skip fetch vendor setting\n");
>> >return;
>> >+ }
> This doesn't have anything to do with adding the new chip.
>
> And I'm not sure it's even required.
>
Yes, it can be removed, but it is useful for debug,
help us to know whether config is load from hardware.
Re: [PATCH 2/2] staging: android: ion: Add pss info for each ion_client
On Mon, Jan 19, 2015 at 10:00:25AM +0800, Feng Tang wrote: > In real ION buffer usage, many of the ion buffer are shared > by several clients(imported and exported), and current ion > debugfs only provides size of all buffers a client may use. > This patch will considers the sharing and adds a "pss" info > for each ion_client, which will help on profiling the ion > memory usage. > > Actually we can do more aggressively in android world, in > which the "surfaceflinger" is a main proxy to help other > apps to do the ion buffer allocation, and we can consider > this and extract "surfaceflinger" related size out. And > this could be the next step. > > Signed-off-by: Feng Tang > --- > drivers/staging/android/ion/ion.c | 25 + > 1 file changed, 17 insertions(+), 8 deletions(-) I really need others to review and test this with their systems before I can accept it. So I'll have to wait for an ack from John or Colin or someone else... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] PCI: Introduce pci_host_assign_domain_nr() to assign domain
>> I'm confused: the same code is already part of the PCI tree, but with
>> Lorenzo Pieralisi listed as the patch author. The code is good,
>> and I acked it in the past, but one of you is (probably by accident)
>> misattributing the patch.
>>
>> Assuming that the patch that is already merged in next is the right
>> one, I think you should rebase your series on top of
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
>>
>> to avoid conflicts like this one.
>>
>
> I think I just got confused because the code duplicates most of
> pci_bus_assign_domain_nr(). Maybe this can be done in a better way
> by splitting the existing function into
>
> static int pci_assign_domain_nr(struct device *)
> {
> ... /* most of pci_bus_assign_domain_nr */
>
> return domain;
> }
>
> void pci_host_assign_domain_nr(struct pci_host_bridge *host)
> {
> host->domain = pci_assign_domain_nr(host->dev.parent);
> }
>
> void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> {
> bus->domain_nr = pci_assign_domain_nr(parent);
> }
>
Hi Arnd,
I kept the almost duplicated pci_host_assign_domain_nr() and
pci_bus_assign_domain_nr() here for building happy, because now
platform specific pci_domain_nr() still exists which may get domain
number from pci_bus. pci_bus_assign_domain_nr() will be removed in
the last patch.
Thanks!
Yijing.
> .
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] toshiba_acpi: Add a check for TOS_NOT_SUPPORTED in the sci_open function
This was "toshiba_acpi: Change sci_open function return value"
Some Toshiba laptops have "poorly implemented" SCI calls on their
BIOSes and are not checking for sci_{open, close} calls, therefore,
the sci_open function is failing and making some of the supported
features unavailable (kbd backlight, touchpad, illumination, etc.).
This patch checks wheter we receive TOS_NOT_SUPPORTED and returns
1, making the supported features work on such laptops.
In the case that some laptops really do not support the SCI, all the
SCI dependent functions check for TOS_NOT_SUPPORTED, and thus, not
registering support for the queried feature.
Signed-off-by: Azael Avalos
---
Darren,
Hopefully this new patch eases some of the concerns of the previous
patch, and this time I added a comment block explaining a bit, but of
course, let me know if there is something else that needs change.
Cheers
Azael
drivers/platform/x86/toshiba_acpi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index fc34a71..899ead6b 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -389,6 +389,19 @@ static int sci_open(struct toshiba_acpi_dev *dev)
} else if (out[0] == TOS_ALREADY_OPEN) {
pr_info("Toshiba SCI already opened\n");
return 1;
+ } else if (out[0] == TOS_NOT_SUPPORTED) {
+ /* Some BIOSes do not have the SCI open/close functions
+* implemented and return 0x8000 (Not Supported), failing to
+* register some supported features.
+*
+* Simply return 1 if we hit those affected laptops to make the
+* supported features work.
+*
+* In the case that some laptops really do not support the SCI,
+* all the SCI dependent functions check for TOS_NOT_SUPPORTED,
+* and thus, not registering support for the queried feature.
+*/
+ return 1;
} else if (out[0] == TOS_NOT_PRESENT) {
pr_info("Toshiba SCI is not present\n");
}
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH workqueue wq/for-3.19-fixes] workqueue: fix subtle pool management issue which can stall whole worker_pool
On 01/17/2015 03:32 AM, Tejun Heo wrote:
>>From 29187a9eeaf362d8422e62e17a22a6e115277a49 Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Fri, 16 Jan 2015 14:21:16 -0500
>
> A worker_pool's forward progress is guaranteed by the fact that the
> last idle worker assumes the manager role to create more workers and
> summon the rescuers if creating workers doesn't succeed in timely
> manner before proceeding to execute work items.
>
> This manager role is implemented in manage_workers(), which indicates
> whether the worker may proceed to work item execution with its return
> value. This is necessary because multiple workers may contend for the
> manager role, and, if there already is a manager, others should
> proceed to work item execution.
>
> Unfortunately, the function also indicates that the worker may proceed
> to work item execution if need_to_create_worker() is false at the head
> of the function. need_to_create_worker() tests the following
> conditions.
>
> pending work items && !nr_running && !nr_idle
>
> The first and third conditions are protected by pool->lock and thus
> won't change while holding pool->lock; however, nr_running can change
> asynchronously as other workers block and resume and while it's likely
> to be zero, as someone woke this worker up in the first place, some
> other workers could have become runnable inbetween making it non-zero.
I had sent a patch similar:
https://lkml.org/lkml/2014/7/10/446
It was shame for me that I did not think deep enough that time.
>
> If this happens, manage_worker() could return false even with zero
> nr_idle making the worker, the last idle one, proceed to execute work
> items. If then all workers of the pool end up blocking on a resource
> which can only be released by a work item which is pending on that
> pool, the whole pool can deadlock as there's no one to create more
> workers or summon the rescuers.
How nr_running is decreased to zero in this case?
( The decreasing of nr_running is also protected by "X" )
( I just checked the cpu-hotplug code again ... find no suspect)
> -static bool maybe_create_worker(struct worker_pool *pool)
> +static void maybe_create_worker(struct worker_pool *pool)
> __releases(&pool->lock)
> __acquires(&pool->lock)
> {
> - if (!need_to_create_worker(pool))
> - return false;
It only returns false here, if there ware bug, the bug would be here.
But it still holds the pool->lock and no releasing form the beginning to here)
My doubt might be wrong, but at least it is a good cleanup
Acked-by: Lai Jiangshan
Thanks
Lai
> restart:
> spin_unlock_irq(&pool->lock);
>
> @@ -1877,7 +1871,6 @@ restart:
>*/
> if (need_to_create_worker(pool))
> goto restart;
> - return true;
> }
>
> /**
> @@ -1897,16 +1890,14 @@ restart:
> * multiple times. Does GFP_KERNEL allocations.
> *
> * Return:
> - * %false if the pool don't need management and the caller can safely start
> - * processing works, %true indicates that the function released pool->lock
> - * and reacquired it to perform some management function and that the
> - * conditions that the caller verified while holding the lock before
> - * calling the function might no longer be true.
> + * %false if the pool doesn't need management and the caller can safely
> + * start processing works, %true if management function was performed and
> + * the conditions that the caller verified before calling the function may
> + * no longer be true.
> */
> static bool manage_workers(struct worker *worker)
> {
> struct worker_pool *pool = worker->pool;
> - bool ret = false;
>
> /*
>* Anyone who successfully grabs manager_arb wins the arbitration
> @@ -1919,12 +1910,12 @@ static bool manage_workers(struct worker *worker)
>* actual management, the pool may stall indefinitely.
>*/
> if (!mutex_trylock(&pool->manager_arb))
> - return ret;
> + return false;
>
> - ret |= maybe_create_worker(pool);
> + maybe_create_worker(pool);
>
> mutex_unlock(&pool->manager_arb);
> - return ret;
> + return true;
> }
>
> /**
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
