[PATCH v1] tty: serial: 8250: 8250_gsc:- Handle return NULL error from ioremap_nocache
Here, If ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference.
This error check will avoid NULL pointer dereference.
Signed-off-by: Arvind Yadav
---
drivers/tty/serial/8250/8250_gsc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_gsc.c
b/drivers/tty/serial/8250/8250_gsc.c
index b1e6ae9..63306de 100644
--- a/drivers/tty/serial/8250/8250_gsc.c
+++ b/drivers/tty/serial/8250/8250_gsc.c
@@ -60,6 +60,10 @@ static int __init serial_init_chip(struct parisc_device *dev)
7272727 : 1843200;
uart.port.mapbase = address;
uart.port.membase = ioremap_nocache(address, 16);
+ if (!uart.port.membase) {
+ dev_warn(&dev->dev, "Failed to map memory\n");
+ return -ENOMEM;
+ }
uart.port.irq = dev->irq;
uart.port.flags = UPF_BOOT_AUTOCONF;
uart.port.dev = &dev->dev;
--
1.9.1
Re: [PATCH] drm/bochs: Implement nomodeset
On Mi, 2017-01-18 at 19:10 +0100, Max Staudt wrote: > Up until now, the bochsdrm driver didn't handle the nomodeset option > at boot, and didn't provide a "modeset" module option either. > > This patch implements both. > > The new parameter can be used by specifying bochs-drm.modeset=0 > at boot time. Added to drm-qemu queue. thanks, Gerd
Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.
Hi Fuwei,
One comments below.
On 2017/1/18 21:25, fu@linaro.org wrote:
From: Fu Wei
The counter frequency detection call(arch_timer_detect_rate) combines two
ways to get counter frequency: system coprocessor register and MMIO timer.
But in a specific timer init code, we only need one way to try:
getting frequency from MMIO timer register will be needed only when we
init MMIO timer; getting frequency from system coprocessor register will
be needed only when we init arch timer.
This patch separates paths to determine frequency:
Separate out the MMIO frequency and the sysreg frequency detection call,
and use the appropriate one for the counter.
Signed-off-by: Fu Wei
---
drivers/clocksource/arm_arch_timer.c | 40 ++--
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 6484f84..9482481 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -488,23 +488,33 @@ static int arch_timer_starting_cpu(unsigned int cpu)
return 0;
}
-static void arch_timer_detect_rate(void __iomem *cntbase)
+static void __arch_timer_determine_rate(u32 rate)
{
- /* Who has more than one independent system counter? */
- if (arch_timer_rate)
- return;
+ /* Check the timer frequency. */
+ if (!arch_timer_rate) {
+ if (rate)
+ arch_timer_rate = rate;
+ else
+ pr_warn("frequency not available\n");
+ } else if (rate && arch_timer_rate != rate) {
^
Typo? I think it's "&" here.
Thanks
Hanjun
Re: [PATCH v9 2/5] i2c: Add STM32F4 I2C driver
Hello Cedric, On Wed, Jan 18, 2017 at 09:55:39PM +0100, M'boumba Cedric Madianga wrote: > 2017-01-18 19:42 GMT+01:00 Uwe Kleine-König : > > Hello Cedric, > > > > On Wed, Jan 18, 2017 at 04:21:17PM +0100, M'boumba Cedric Madianga wrote: > >> >> + * In standard mode, the maximum allowed SCL rise time is 1000 ns. > >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is > >> >> equal to > >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be > >> >> + * programmed with 09h.(1000 ns / 125 ns = 8 + 1) > >> > > >> > * programmed with 0x9. > >> > (1000 ns / 125 ns = 8) > >> > > >> >> + * So, for I2C standard mode TRISE = FREQ[5:0] + 1 > >> >> + * > >> >> + * In fast mode, the maximum allowed SCL rise time is 300 ns. > >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is > >> >> equal to > >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be > >> >> + * programmed with 03h.(300 ns / 125 ns = 2 + 1) > >> > > >> > as above s/03h/0x3/; > >> > >> ok > >> > >> > s/.(/. (/; > >> ok > >> > >> > s/+ 1//; > >> This formula is use to understand how we find the result 0x3 > >> So, 0x3 => 300 ns / 125ns = 2 + 1 > > > > Yeah, I understood that, but writing 300 ns / 125ns = 2 + 1 is > > irritating at best. > > Ok. I will write 0x3 (300 ns / 125 ns + 1) and 0x9 (1000 ns / 125 ns + 1) > > >> > [...] > >> > If DUTY = 1: (to reach 400 kHz) > >> > > >> > Strange. > >> > > >> >> + val = DIV_ROUND_UP(i2c_dev->parent_rate, 40 * 3); > >> > > >> > the manual reads: > >> > > >> > The minimum allowed value is 0x04, except in FAST DUTY mode > >> > where the minimum allowed value is 0x01 > >> > > >> > You don't check for that, right? > >> > >> As the minimum freq value is 6 Mhz in fast mode the minimum CCR is 5 > >> as described in the comment. > >> So I don't need to check that again as it is already done by checking > >> parent frequency. > > > > That would then go into a comment. > > Is it really needed ? > Adding some comments to explain implementation choices or hardware > way of working is clearly useful. > But for this kind of thing, I am really surprised... TL;DR: It's not needed, but it probably helps. Consider someone sees a breakage in your driver in five years. By then you either have other interests or at least forgot 95 % of the thoughts you had when implementing the driver. So when I see: val = DIV_ROUND_UP(i2c_dev->parent_rate, 40 * 3); ccr |= STM32F4_I2C_CCR_CCR(val); writel_relaxed(ccr, i2c_dev->base + STM32F4_I2C_CCR); after seeing that the bus freq is wrong the obvious thoughts are: - Does this use the right algorithm? - Does this calculation result in values that are usable by the hardware? That you thought about this today doesn't mean it's still right in five years. During that time a new hardware variant is available with a higher parent freq. Or there is a new errata available for the SoC. So to help answer the questions above it helps if you add today the formulas from the manual and a quick reason for why val fits into the respective bits in the CCR register. That comment might be wrong until then, too, but that only means you should make it easy to verify. Something like: /* * Function bla_blub made sure that parent_rate is not higher * than 23 * pi MHz. As a result val is at most 13.2 bits wide * and so fits into the CCR bits. */ This gives you in five years time the opportunity to quickly check bla_blub if this is still true, add a printk for parent_rate to check this, or quickly identify the bug in the code or the mismatch to the manual. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [BISSECTED]: BUG: usb: dwc3: usb ports not working anymore on odroid-XU4
Hi,
Richard Genoud writes:
> Hi,
> Since commit c499ff71ff2a2 ("usb: dwc3: core: re-factor init and exit paths")
> (merged in 4.8), the usb ports on odroid-XU4 don't work anymore.
>
> [ Actually, it's commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all
> cores"), cf below ]
>
> Inserting an usb key (USB2.0) on the USB3.0 port result in:
> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2
> msec, port status = 0xc400fe3
> [ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop
> endpoint command.
> [ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
> [ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
> [ 74.606276] usb 3-1: USB disconnect, device number 2
> [ 74.613565] usb 4-1: USB disconnect, device number 2
> [ 74.621208] usb usb3-port1: couldn't allocate usb_device
> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0
> device (SATA to USB3 for instance).
> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek
> RTL8153 chip.
>
> I instrumented what was read/written in the registers before and after this
> patch, and I found that the culprit is:
> if (dwc->revision > DWC3_REVISION_194A)
> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
> Before commit c499ff71ff2a2 ("usb: dwc3: core: re-factor init and exit
> paths"), dwc3_phy_setup() was
> done early in dwc3_probe() and thus, dwc->revision wasn't set yet (==0)
> After this commit, dwc3_phy_setup() is done in dwc3_core_init(), after
> setting dwc->revision (it's done in dwc3_core_is_valid()).
>
> (The dwc3->revision on odroid-XU4 is 5533200a.)
>
> If I comment out the 2 lines:
> if (dwc->revision > DWC3_REVISION_194A)
> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
> The usb key is recognized right away:
> [ 38.008158] usb 3-1.2: new high-speed USB device number 3 using xhci-hcd
> [ 38.138924] usb 3-1.2: New USB device found, idVendor=abcd, idProduct=1234
> [ 38.144399] usb 3-1.2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
>
> I took a look at the history behind those 2 lines, and they've been
> introduced by:
> commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores") in 3.19.
> In 3.19, the dwc->revision dwc3_phy_setup() was set in dwc3_core_init().
> And, booting a 3.19 kernel on XU4 gives the same error (whereas booting a
> 3.18 kernel is ok)
>
> [ So, I should have started this email with:
> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
> the usb ports on odroid-XU4 don't work anymore. ]
>
> The funny thing is that commit 45bb7de213d8("usb: dwc3: setup phys earlier")
> (merged in 4.2)
> moved dwc3_phy_setup() in dwc3_probe(), way before dwc->revision was set,
> acting like a revert
> on commit 2164a476205c("usb: dwc3: set SUSPHY bit for all cores")
> That's why on 4.2, inserting an USB key on odroid-XU4 worked again,
>
> So, to make a resume:
> xxx-> 3.18: usb ok
> 3.19->4.1: usb error (due to commit 2164a476205ccc ("usb: dwc3: set SUSPHY
> bit for all cores"))
> 4.2->4.7: usb ok (due to commit 45bb7de213d8("usb: dwc3: setup phys earlier"))
> 4.8->now: usb error (due to commit c499ff71ff2a2 ("usb: dwc3: core: re-factor
> init and exit paths"))
>
>
> any idea on this ?
Thanks for bisecting. This could be caused by a similar case as
described at [1]. Can you check if adding quirk
"snps,dis_u3_susphy_quirk" helps ?
[1]
https://marc.info/?i=2b3535c5ece8b5419e3ecbe300772909021b3fd...@us01wembx2.internal.synopsys.com
--
balbi
[PATCH 0/1] add multiple clock handling for dwc2 driver
The Current default dwc2 just handle one clock named otg, however, it may have two or more clock need to manage for some new SoCs(such as RK3328), so this adds change clk to clk's array of dwc2_hsotg to handle more clocks operation. Frank Wang (1): usb: dwc2: add multiple clock handling drivers/usb/dwc2/core.h | 5 - drivers/usb/dwc2/platform.c | 39 ++- 2 files changed, 30 insertions(+), 14 deletions(-) -- 2.0.0
[PATCH 1/1] usb: dwc2: add multiple clock handling
Originally, dwc2 just handle one clock named otg, however, it may have
two or more clock need to manage for some new SoCs, so this adds
change clk to clk's array of dwc2_hsotg to handle more clocks operation.
Signed-off-by: Frank Wang
---
drivers/usb/dwc2/core.h | 5 -
drivers/usb/dwc2/platform.c | 39 ++-
2 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9548d3e..aa80837 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -121,6 +121,9 @@ static inline void dwc2_writel(u32 value, void __iomem
*addr)
/* Maximum number of Endpoints/HostChannels */
#define MAX_EPS_CHANNELS 16
+/* Maximum number of dwc2 clocks */
+#define DWC2_MAX_CLKS 3
+
/* dwc2-hsotg declarations */
static const char * const dwc2_hsotg_supply_names[] = {
"vusb_d", /* digital USB supply, 1.2V */
@@ -927,7 +930,7 @@ struct dwc2_hsotg {
spinlock_t lock;
void *priv;
int irq;
- struct clk *clk;
+ struct clk *clks[DWC2_MAX_CLKS];
struct reset_control *reset;
unsigned int queuing_high_bandwidth:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 4fc8c60..5065114 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -123,17 +123,20 @@ static int dwc2_get_dr_mode(struct dwc2_hsotg *hsotg)
static int __dwc2_lowlevel_hw_enable(struct dwc2_hsotg *hsotg)
{
struct platform_device *pdev = to_platform_device(hsotg->dev);
- int ret;
+ int clk, ret;
ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
hsotg->supplies);
if (ret)
return ret;
- if (hsotg->clk) {
- ret = clk_prepare_enable(hsotg->clk);
- if (ret)
+ for (clk = 0; clk < DWC2_MAX_CLKS && hsotg->clks[clk]; clk++) {
+ ret = clk_prepare_enable(hsotg->clks[clk]);
+ if (ret) {
+ while (--clk >= 0)
+ clk_disable_unprepare(hsotg->clks[clk]);
return ret;
+ }
}
if (hsotg->uphy)
@@ -168,7 +171,7 @@ int dwc2_lowlevel_hw_enable(struct dwc2_hsotg *hsotg)
static int __dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
{
struct platform_device *pdev = to_platform_device(hsotg->dev);
- int ret = 0;
+ int clk, ret = 0;
if (hsotg->uphy)
usb_phy_shutdown(hsotg->uphy);
@@ -182,8 +185,9 @@ static int __dwc2_lowlevel_hw_disable(struct dwc2_hsotg
*hsotg)
if (ret)
return ret;
- if (hsotg->clk)
- clk_disable_unprepare(hsotg->clk);
+ for (clk = DWC2_MAX_CLKS - 1; clk >= 0; clk--)
+ if (hsotg->clks[clk])
+ clk_disable_unprepare(hsotg->clks[clk]);
ret = regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies),
hsotg->supplies);
@@ -209,7 +213,7 @@ int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
{
- int i, ret;
+ int i, clk, ret;
hsotg->reset = devm_reset_control_get_optional(hsotg->dev, "dwc2");
if (IS_ERR(hsotg->reset)) {
@@ -282,11 +286,20 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
hsotg->phyif = GUSBCFG_PHYIF8;
}
- /* Clock */
- hsotg->clk = devm_clk_get(hsotg->dev, "otg");
- if (IS_ERR(hsotg->clk)) {
- hsotg->clk = NULL;
- dev_dbg(hsotg->dev, "cannot get otg clock\n");
+ /* Clocks */
+ for (clk = 0; clk < DWC2_MAX_CLKS; clk++) {
+ hsotg->clks[clk] = of_clk_get(hsotg->dev->of_node, clk);
+ if (IS_ERR(hsotg->clks[clk])) {
+ ret = PTR_ERR(hsotg->clks[clk]);
+ if (ret == -EPROBE_DEFER) {
+ while (--clk >= 0)
+ clk_put(hsotg->clks[clk]);
+ return ret;
+ }
+
+ hsotg->clks[clk] = NULL;
+ break;
+ }
}
/* Regulators */
--
2.0.0
Re: [PATCH 1/2] ARM64: dts: meson-gxm: Add R-Box Pro
Hi Andreas, Kevin, On 01/18/2017 11:27 PM, Kevin Hilman wrote: > Andreas Färber writes: > >> Am 17.01.2017 um 04:06 schrieb Andreas Färber: >>> diff --git a/arch/arm64/boot/dts/amlogic/Makefile >>> b/arch/arm64/boot/dts/amlogic/Makefile >>> index 0d7bfbf7d922..66bc809a5eae 100644 >>> --- a/arch/arm64/boot/dts/amlogic/Makefile >>> +++ b/arch/arm64/boot/dts/amlogic/Makefile >>> @@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb >>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb >>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb >>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb >> >> What is the logic behind meson-gxm-s912-q201 vs. meson-gxm-nexbox-a1? >> Should it be renamed to include -s912 for consistency? It followed the GXL logic... until I posted the nexbox-a1 without ! Since the q20x and p23x boards are the same, it was to enforce the fact that the S912 was on the q200 and q201 boards. > Oops, I think it should be renamed for consistency. > > I believe there's only one chip in the GXM family (S912) so it might be > that we could either drop the -s912 from the q20x boards or, add it to > the nexbox. I believe this aswell AFAIK. > > I lean towards dropping the -s912 since there's a single chip in GXM. > (FWIW, GXL has more than one chip in the family so we added the chip > there.) > >>> +dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb >> >> Should this new board use meson-gxm-s912-? > > No. Unless Neil or you thing otherwise, I think we should send a patch > to drop the -s912 from the q20x boards instead. (where "we" == Neil) ;) Ok, will do. > > Kevin Neil
Re: [PATCH 2/3] ARM64: dts: meson-gxbb: Add support for WeTek Hub and Play
On 01/18/2017 11:53 PM, Kevin Hilman wrote: > Neil Armstrong writes: > >> Adds support for the WeTek Hub and Play2 boards. >> The Hub is an extremely small IPTv Set-Top-Box and the Play2 is a more >> traditionnal Satellite or Terrestrial and IPTv Set-Top-Box. >> >> Both are based on the p200 Reference Design and out-of-tree support is >> based on OpenELEC kernel at [1]. >> >> [1] https://github.com/wetek-enigma/linux-amlogic >> >> Signed-off-by: Neil Armstrong > > Did you get the GPIO/button info from the LibreELEC tree or did you find > some schematics someplace? If you found any schematics, it would be > nice to have links in the DTS files. > > Kevin > It was in the dts of the LibreELEC tree, I found no schematics so far. I can respin a v2 with a link to the LibreELEC dts files. Neil
Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote: > Hi Peter, > > On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote: > > On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote: > > > On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote: > > >> On 04 January, 2017 21:39 CET, Rob Herring wrote: > > >>> On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote: > > On 03 January, 2017 23:51 CET, Rob Herring wrote: > > > On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote: > > >> Devicetree bindings documentation for the GE B850v3 LVDS/DP++ > > >> display bridge. > > >> > > >> Cc: Martyn Welch > > >> Cc: Martin Donnelly > > >> Cc: Javier Martinez Canillas > > >> Cc: Enric Balletbo i Serra > > >> Cc: Philipp Zabel > > >> Cc: Rob Herring > > >> Cc: Fabio Estevam > > >> Signed-off-by: Peter Senna Tschudin > > >> --- > > >> There was an Acked-by from Rob Herring for V6, > > >> but I changed the bindings to use i2c_new_secondary_device() so I > > >> removed it from the commit message. > > >> [...] > > >> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 +++ > > > > > > Isn't '-lvds-dp' redundant? The part# should be enough. > > > > b850v3 is the name of the product, this is why the proposed name. > > What about, b850v3-dp2 dp2 indicating the second DP output? > > >>> > > >>> Humm, b850v3 is the board name? This node should be the name of the > > >>> bridge chip. > > >> > > >> From the cover letter: > > >> > > >> -- // -- > > >> There are two physical bridges on the video signal pipeline: a > > >> STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and > > >> firmware made it complicated for this binding to comprise two device > > >> tree nodes, as the design goal is to configure both bridges based on > > >> the LVDS signal, which leave the driver powerless to control the video > > >> processing pipeline. The two bridges behaves as a single bridge, and > > >> the driver is only needed for telling the host about EDID / HPD, and > > >> for giving the host powers to ack interrupts. The video signal pipeline > > >> is as follows: > > >> Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video > > >> output > > >> -- // -- > > > > > > You forgot to prefix your patch series with [HACK] ;-) > > > > > > How about fixing the issues that make the two DT nodes solution difficult > > > ? What are they ? > > > > The Firmware and the hardware design. Both bridges, with stock firmware, > > are fully capable of providig EDID information and handling interrupts. > > But on this specific design, with this specific firmware, I need to read > > EDID from one bridge, and handle interrupts on the other. > > Which firmware are you talking about ? Firmware running on the bridges, or > somewhere else ? Each bridge has it's own external flash containing a binary firmware. The goal of the firmware is to configure the output end based on the input end. This is part of what makes handling EDID and HPD challenging. > > > Back when I was starting the development I could not come up with a proper > > way to split EDID and interrupts between two bridges in a way that would > > result in a fully functional connector. Did I miss something? > > You didn't, we did :-) I've been telling for quite some time now that we must > decouple bridges from connectors, and this is another example of why we have > such a need. Bridges should expose additional functions needed to implement > connector operations, and the connector should be instantiated by the display > driver with the help of bridge operations. You could then create a connector > that relies on one bridge to read the EDID and on the other bridge to handle > HPD. Ah thanks. So for now the single DT node approach is acceptable, right? The problem is that even if the driver is getting better on each iteration, the single DT node for two chips issue comes back often and I believe is _the_ issue preventing the driver from getting upstream. V1 was sent ~ 8 months ago... Can I have some blessing on the single DT node approach for now? I'm one of the 3 proposed maintainers for the driver, and I'm willing to maintain the driver on the long run, as is the same with the other two proposed maintainers. So when the time to split the node in two comes, we will be around, and willing to do it ourselves. Thank you! Peter > > -- > Regards, > > Laurent Pinchart >
Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
Hi Rob, On Wed, 18 Jan 2017 20:51:08 -0600 Rob Herring wrote: > On Wed, Jan 18, 2017 at 5:38 PM, Thomas Petazzoni > wrote: > > Hello, > > > > On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote: > > > >> > > Rob, Mark, any opinion? > >> > > >> > >> Sigh, is how to do compatibles really not yet understood? > > > > Well, it seems like not everyone necessarily understands what is the > > best strategy to adopt (me included). > > > >> > I agree that a clarification would be good. There are really two > >> > options: > >> > > >> > 1. Have two compatible strings in the DT, the one that matches the > >> > exact SoC where the IP is found (first compatible string) and the > >> > one that matches some other SoC where the same IP is found (second > >> > compatible string). Originally, Linux only supports the second > >> > compatible string in its device driver, but if it happens that a > >> > difference is found between two IPs that we thought were the same, > >> > we can add support for the first compatible string in the driver, > >> > with a slightly different behavior. > >> > >> This. And no wildcards in the compatible string. > > > > OK. So it means that today we do something like: > > > > compatible = "baz,foo-12", "baz,foo-00"; > > > > and support only baz,foo-00 in the driver. If tomorrow we discover > > that there is in fact a difference between the two IP blocks, we can > > add support for baz,foo-12 in the driver, and handle the differences. > > > > But then, the DT still contains: > > > > compatible = "baz,foo-12", "baz,foo-00"; > > > > and therefore pretends that the IP block is compatible with > > "baz,foo-00" which is in fact *not* the case. It was a mistake to > > consider it as compatible. So we keep living with a DT that has > > incorrect information. > > I wouldn't say it's a mistake necessarily. The old compatible would > probably work to some extent. I'd assume it was tested to some level. > Or it could be other changes exposing a difference. One last question and I'm done: is something like that acceptable? compatible = ",",","; This can happen when someone adds support for an unsupported feature on a brand new SoC, and then someone else use the same driver for an older SoC embedding the same IP but still wants to add a new compatible just in case these 2 IPs appear to be slightly different. Here the order of compat strings is no longer following a clear rule like 'most-specific compatible first' or 'newest IP/SoC version first', it's completely dependent on the order these IPs were supported in the OS (Linux). I'm perfectly fine with that BTW, just want to make sure this is authorized. Regards, Boris
Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
Hi Peter, On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote: > On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote: > > On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote: > >> On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote: > >>> On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote: > On 04 January, 2017 21:39 CET, Rob Herring wrote: > > On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote: > >> On 03 January, 2017 23:51 CET, Rob Herring wrote: > >>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote: > Devicetree bindings documentation for the GE B850v3 LVDS/DP++ > display bridge. > > Cc: Martyn Welch > Cc: Martin Donnelly > Cc: Javier Martinez Canillas > Cc: Enric Balletbo i Serra > Cc: Philipp Zabel > Cc: Rob Herring > Cc: Fabio Estevam > Signed-off-by: Peter Senna Tschudin > --- > There was an Acked-by from Rob Herring for V6, > but I changed the bindings to use i2c_new_secondary_device() so I > removed it from the commit message. > > [...] > > .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 + > >>> > >>> Isn't '-lvds-dp' redundant? The part# should be enough. > >> > >> b850v3 is the name of the product, this is why the proposed name. > >> What about, b850v3-dp2 dp2 indicating the second DP output? > > > > Humm, b850v3 is the board name? This node should be the name of the > > bridge chip. > > From the cover letter: > > -- // -- > There are two physical bridges on the video signal pipeline: a > STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and > firmware made it complicated for this binding to comprise two device > tree nodes, as the design goal is to configure both bridges based on > the LVDS signal, which leave the driver powerless to control the > video processing pipeline. The two bridges behaves as a single bridge, > and the driver is only needed for telling the host about EDID / HPD, > and for giving the host powers to ack interrupts. The video signal > pipeline > > is as follows: > Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video > output > > -- // -- > >>> > >>> You forgot to prefix your patch series with [HACK] ;-) > >>> > >>> How about fixing the issues that make the two DT nodes solution > >>> difficult ? What are they ? > >> > >> The Firmware and the hardware design. Both bridges, with stock firmware, > >> are fully capable of providig EDID information and handling interrupts. > >> But on this specific design, with this specific firmware, I need to read > >> EDID from one bridge, and handle interrupts on the other. > > > > Which firmware are you talking about ? Firmware running on the bridges, or > > somewhere else ? > > Each bridge has it's own external flash containing a binary firmware. > The goal of the firmware is to configure the output end based on the > input end. This is part of what makes handling EDID and HPD challenging. > > >> Back when I was starting the development I could not come up with a > >> proper way to split EDID and interrupts between two bridges in a way > >> that would result in a fully functional connector. Did I miss something? > > > > You didn't, we did :-) I've been telling for quite some time now that we > > must decouple bridges from connectors, and this is another example of why > > we have such a need. Bridges should expose additional functions needed to > > implement connector operations, and the connector should be instantiated > > by the display driver with the help of bridge operations. You could then > > create a connector that relies on one bridge to read the EDID and on the > > other bridge to handle HPD. > > Ah thanks. So for now the single DT node approach is acceptable, right? > The problem is that even if the driver is getting better on each > iteration, the single DT node for two chips issue comes back often and I > believe is _the_ issue preventing the driver from getting upstream. V1 > was sent ~ 8 months ago... > > Can I have some blessing on the single DT node approach for now? With the "DT as an ABI" approach, I'm afraid not. Temporary hacks are acceptable on the driver side, but you need two nodes in DT. > I'm one of the 3 proposed maintainers for the driver, and I'm willing to > maintain the driver on the long run, as is the same with the other two > proposed maintainers. So when the time to split the node in two comes, > we will be around, and willing to do it ourselves. How about putting that team of 3 maintainers to work on fixing the problem in the bridge API ? :-) -- Regards, Laurent Pinchart
Re: [PATCH v2 2/3] cpu: expose pm_qos_resume_latency for each cpu
On 01/17/2017 06:23 PM, Daniel Lezcano wrote: >> > >> > @@ -376,6 +377,7 @@ int register_cpu(struct cpu *cpu, int num) >> > >> >per_cpu(cpu_sys_devices, num) = &cpu->dev; >> >register_cpu_under_node(num, cpu_to_node(num)); >> > + dev_pm_qos_expose_latency_limit(&cpu->dev, 0); > This patch should be submitted as the last patch in the latencies constraint > changes patchset IMO. It is pointless to provide an interface before a > feature which is still under discussion. Thanks for comments! will fold it into next patch!
[PATCH] ARM64: dts: meson-gxm: Rename q200 and q201 DT files for consistency
In order to keep consistency naming with the Nexbox A1 DTS file, remove the
S912 SoC name in the GXM DT files.
Suggested-by: Andreas Färber
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/Makefile | 4 ++--
.../boot/dts/amlogic/{meson-gxm-s912-q200.dts => meson-gxm-q200.dts} | 0
.../boot/dts/amlogic/{meson-gxm-s912-q201.dts => meson-gxm-q201.dts} | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm64/boot/dts/amlogic/{meson-gxm-s912-q200.dts =>
meson-gxm-q200.dts} (100%)
rename arch/arm64/boot/dts/amlogic/{meson-gxm-s912-q201.dts =>
meson-gxm-q201.dts} (100%)
Kevin, is this patch format correct for you to apply ?
diff --git a/arch/arm64/boot/dts/amlogic/Makefile
b/arch/arm64/boot/dts/amlogic/Makefile
index 0d7bfbf..1aca8e5 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -9,8 +9,8 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-p212.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p230.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p231.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb
-dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb
-dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q200.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
b/arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
similarity index 100%
rename from arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
rename to arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
b/arch/arm64/boot/dts/amlogic/meson-gxm-q201.dts
similarity index 100%
rename from arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
rename to arch/arm64/boot/dts/amlogic/meson-gxm-q201.dts
--
1.9.1
Re: [PATCH 0/5] UM: Fine-tuning for some function implementations
Markus, Am 18.01.2017 um 22:55 schrieb SF Markus Elfring: > From: Markus Elfring > Date: Wed, 18 Jan 2017 22:48:02 +0100 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (5): > port: Move an assignment for the variable "fd" in port_wait() > port: Delete three error messages for a failed memory allocation > port: Improve size determinations in port_data() > ubd: Move two assignments for the variable "err" in ubd_remove() > ubd: Improve size determinations in do_ubd_request() please don't send drive-by patches. Please see: marc.info/?i=20170111225640.14e5d962@bbrezillon Nacked-by: Richard Weinberger Thanks, //richard
Re: [PATCH 13/33] Input: bfin_rotary - Use 'dev' instead of dereferencing it and other changes
On 01/18/2017 08:58 PM, Joe Perches wrote:
On Wed, 2017-01-18 at 12:35 -0800, Guenter Roeck wrote:
On Wed, Jan 18, 2017 at 11:39:52AM -0800, Dmitry Torokhov wrote:
On Wed, Jan 18, 2017 at 09:46:34AM -0800, Guenter Roeck wrote:
[]
diff --git a/drivers/input/misc/bfin_rotary.c b/drivers/input/misc/bfin_rotary.c
[]
@@ -141,25 +141,23 @@ static int bfin_rotary_probe(struct platform_device *pdev)
/* Basic validation */
if ((pdata->rotary_up_key && !pdata->rotary_down_key) ||
- (!pdata->rotary_up_key && pdata->rotary_down_key)) {
+ (!pdata->rotary_up_key && pdata->rotary_down_key))
maybe just use ^
if (!pdata->rotary_up_key ^ !pdata->rotary_down_key)
Interesting use case for a coccinelle rule.
To address the coccinelle related problem, I modified the rule to only apply
if the expression is in one line, and if the return statement is in the next
line. That works pretty well.
Guenter
Re: linux-next: build warning after merge of the net tree
Hi Stephen,
On 19/01/2017 12:56 AM, Stephen Rothwell wrote:
Hi all,
After merging the net tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c: In function
'mlx5e_set_channels':
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c:546:6: warning: unused
variable 'ncv' [-Wunused-variable]
int ncv = mlx5e_get_max_num_channels(priv->mdev);
^
Introduced by commit
639e9e94160e ("net/mlx5e: Remove unnecessary checks when setting num
channels")
which removed the last reference to 'ncv'.
We will send a fix shortly.
Thanks for your report!
Regards,
Tariq
Re: [PATCH v20 11/17] clocksource/drivers/arm_arch_timer: Introduce some new structs to prepare for GTDT
On 2017/1/18 21:25, fu@linaro.org wrote:
From: Fu Wei
The patch introduce two new structs: arch_timer_mem, arch_timer_mem_frame.
And also introduce a new define: ARCH_TIMER_MEM_MAX_FRAMES
These will be used for refactoring the memory-mapped timer init code to
prepare for GTDT
Signed-off-by: Fu Wei
---
include/clocksource/arm_arch_timer.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/clocksource/arm_arch_timer.h
b/include/clocksource/arm_arch_timer.h
index 4a98c06..b7dd185 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -57,6 +57,8 @@ enum arch_timer_spi_nr {
#define ARCH_TIMER_MEM_PHYS_ACCESS 2
#define ARCH_TIMER_MEM_VIRT_ACCESS 3
+#define ARCH_TIMER_MEM_MAX_FRAMES 8
+
#define ARCH_TIMER_USR_PCT_ACCESS_EN (1 << 0) /* physical counter */
#define ARCH_TIMER_USR_VCT_ACCESS_EN (1 << 1) /* virtual counter */
#define ARCH_TIMER_VIRT_EVT_EN (1 << 2)
@@ -72,6 +74,21 @@ struct arch_timer_kvm_info {
int virtual_irq;
};
+struct arch_timer_mem_frame {
+ int frame_nr;
+ phys_addr_t cntbase;
+ size_t size;
+ int phys_irq;
+ int virt_irq;
+};
+
+struct arch_timer_mem {
+ phys_addr_t cntctlbase;
+ size_t size;
+ int num_frames;
+ struct arch_timer_mem_frame frame[ARCH_TIMER_MEM_MAX_FRAMES];
+};
Since struct is introduced but not used in this patch, how about
squash it with patch 12/17?
Thanks
Hanjun
Re: [PATCH -next] init/main: Init jump_labels before they are used to build zonelists
On 01/17/2017 09:49 PM, Vlastimil Babka wrote:
> On 17.1.2017 21:34, Andrew Morton wrote:
Will you be able to look into that? Openrisc doesnt have jump_label
support, so its no issue at the moment.
Archs that do have it:
arch/arm64/Kconfig: select HAVE_ARCH_JUMP_LABEL
arch/mips/Kconfig: select HAVE_ARCH_JUMP_LABEL
arch/s390/Kconfig: select HAVE_ARCH_JUMP_LABEL
arch/sparc/Kconfig: select HAVE_ARCH_JUMP_LABEL if SPARC64
arch/tile/Kconfig: select HAVE_ARCH_JUMP_LABEL
arch/x86/Kconfig: select HAVE_ARCH_JUMP_LABEL
arch/arm/Kconfig: select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL &&
!CPU_ENDIAN_BE32 && MMU
arch/powerpc/Kconfig: select HAVE_ARCH_JUMP_LABEL
I looked at a few (arm, tile) and I dont see their
arch_jump_label_transform*
implementations depending on global state like ideal_nops from x86. They
should be ok.
>>>
>>> Thanks, I'll try.
>>>
If no time, Should you change your patch to not use static keys for
build_all_zonelists at least?
>>>
>>> Yes that would be uglier but possible if I find issues or I'm not
>>> confident enough with the auditing...
>>
>> We could just revert f5adbdff6a1c40e19 ("mm, page_alloc: convert
>> page_group_by_mobility_disable to static key")?
>
> That's a -next commit id, as the patch is in mmotm. I'll ask for removal if I
> don't have a fix soon, but if you or somebody else prefers to do that ASAP, it
> can be re-added later with a fix.
OK I think that we just drop the patch [1] from mmotm. Mel told me the
benefit was marginal, and also the last move of jump_label_init() caused
problems for several releases.
Thanks,
Vlastimil
[1] mm-page_alloc-convert-page_group_by_mobility_disable-to-static-key.patch
Re: [PATCH v9 2/5] i2c: Add STM32F4 I2C driver
ok fine 2017-01-19 9:02 GMT+01:00 Uwe Kleine-König : > Hello Cedric, > > On Wed, Jan 18, 2017 at 09:55:39PM +0100, M'boumba Cedric Madianga wrote: >> 2017-01-18 19:42 GMT+01:00 Uwe Kleine-König : >> > Hello Cedric, >> > >> > On Wed, Jan 18, 2017 at 04:21:17PM +0100, M'boumba Cedric Madianga wrote: >> >> >> + * In standard mode, the maximum allowed SCL rise time is 1000 >> >> >> ns. >> >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is >> >> >> equal to >> >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be >> >> >> + * programmed with 09h.(1000 ns / 125 ns = 8 + 1) >> >> > >> >> > * programmed with 0x9. >> >> > (1000 ns / 125 ns = 8) >> >> > >> >> >> + * So, for I2C standard mode TRISE = FREQ[5:0] + 1 >> >> >> + * >> >> >> + * In fast mode, the maximum allowed SCL rise time is 300 ns. >> >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is >> >> >> equal to >> >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be >> >> >> + * programmed with 03h.(300 ns / 125 ns = 2 + 1) >> >> > >> >> > as above s/03h/0x3/; >> >> >> >> ok >> >> >> >> > s/.(/. (/; >> >> ok >> >> >> >> > s/+ 1//; >> >> This formula is use to understand how we find the result 0x3 >> >> So, 0x3 => 300 ns / 125ns = 2 + 1 >> > >> > Yeah, I understood that, but writing 300 ns / 125ns = 2 + 1 is >> > irritating at best. >> >> Ok. I will write 0x3 (300 ns / 125 ns + 1) and 0x9 (1000 ns / 125 ns + 1) >> >> >> > [...] >> >> > If DUTY = 1: (to reach 400 kHz) >> >> > >> >> > Strange. >> >> > >> >> >> + val = DIV_ROUND_UP(i2c_dev->parent_rate, 40 * 3); >> >> > >> >> > the manual reads: >> >> > >> >> > The minimum allowed value is 0x04, except in FAST DUTY mode >> >> > where the minimum allowed value is 0x01 >> >> > >> >> > You don't check for that, right? >> >> >> >> As the minimum freq value is 6 Mhz in fast mode the minimum CCR is 5 >> >> as described in the comment. >> >> So I don't need to check that again as it is already done by checking >> >> parent frequency. >> > >> > That would then go into a comment. >> >> Is it really needed ? >> Adding some comments to explain implementation choices or hardware >> way of working is clearly useful. >> But for this kind of thing, I am really surprised... > > TL;DR: It's not needed, but it probably helps. > > Consider someone sees a breakage in your driver in five years. By then > you either have other interests or at least forgot 95 % of the thoughts > you had when implementing the driver. > > So when I see: > > val = DIV_ROUND_UP(i2c_dev->parent_rate, 40 * 3); > ccr |= STM32F4_I2C_CCR_CCR(val); > writel_relaxed(ccr, i2c_dev->base + STM32F4_I2C_CCR); > > after seeing that the bus freq is wrong the obvious thoughts are: > > - Does this use the right algorithm? > - Does this calculation result in values that are usable by the >hardware? > > That you thought about this today doesn't mean it's still right in five > years. During that time a new hardware variant is available with a > higher parent freq. Or there is a new errata available for the SoC. > > So to help answer the questions above it helps if you add today the > formulas from the manual and a quick reason for why val fits into the > respective bits in the CCR register. That comment might be wrong until > then, too, but that only means you should make it easy to verify. > Something like: > > /* > * Function bla_blub made sure that parent_rate is not higher > * than 23 * pi MHz. As a result val is at most 13.2 bits wide > * and so fits into the CCR bits. > */ > > This gives you in five years time the opportunity to quickly check > bla_blub if this is still true, add a printk for parent_rate to check > this, or quickly identify the bug in the code or the mismatch to the > manual. > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH] ipv6: addrconf: Avoid addrconf_disable_change() using RCU read-side lock
Just like commit 4acd4945cd1e ("ipv6: addrconf: Avoid calling
netdevice notifiers with RCU read-side lock"), it is unnecessary
to make addrconf_disable_change() use RCU iteration over the
netdev list, since it already holds the RTNL lock, or we may meet
Illegal context switch in RCU read-side critical section.
Signed-off-by: Kefeng Wang
---
net/ipv6/addrconf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index c1e124b..f60e88e 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -5540,8 +5540,7 @@ static void addrconf_disable_change(struct net *net,
__s32 newf)
struct net_device *dev;
struct inet6_dev *idev;
- rcu_read_lock();
- for_each_netdev_rcu(net, dev) {
+ for_each_netdev(net, dev) {
idev = __in6_dev_get(dev);
if (idev) {
int changed = (!idev->cnf.disable_ipv6) ^ (!newf);
@@ -5550,7 +5549,6 @@ static void addrconf_disable_change(struct net *net,
__s32 newf)
dev_disable_change(idev);
}
}
- rcu_read_unlock();
}
static int addrconf_disable_ipv6(struct ctl_table *table, int *p, int newf)
--
1.7.12.4
Re: [PATCH 1/6] mm: introduce kv[mz]alloc helpers
On 01/18/2017 12:21 AM, Michal Hocko wrote: On Tue 17-01-17 21:59:13, John Hubbard wrote: On 01/16/2017 11:51 PM, Michal Hocko wrote: On Mon 16-01-17 13:57:43, John Hubbard wrote: On 01/16/2017 01:48 PM, Michal Hocko wrote: On Mon 16-01-17 13:15:08, John Hubbard wrote: On 01/16/2017 11:40 AM, Michal Hocko wrote: On Mon 16-01-17 11:09:37, John Hubbard wrote: On 01/16/2017 12:47 AM, Michal Hocko wrote: On Sun 15-01-17 20:34:13, John Hubbard wrote: [...] Is that "Reclaim modifiers" line still true, or is it a leftover from an earlier approach? I am having trouble reconciling it with rest of the patchset, because: a) the flags argument below is effectively passed on to either kmalloc_node (possibly adding, but not removing flags), or to __vmalloc_node_flags. The above only says thos are _unsupported_ - in other words the behavior is not defined. Even if flags are passed down to kmalloc resp. vmalloc it doesn't mean they are used that way. Remember that vmalloc uses some hardcoded GFP_KERNEL allocations. So while I could be really strict about this and mask away these flags I doubt this is worth the additional code. I do wonder about passing those flags through to kmalloc. Maybe it is worth stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some insulation from any future changes to the implementation of kmalloc, and it also makes the documentation more believable. I am not really convinced that we should take an extra steps for these flags. There are no existing users for those flags and new users should follow the documentation. OK, let's just fortify the documentation ever so slightly, then, so that users are more likely to do the right thing. How's this sound: * Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. (Even * though the current implementation passes the flags on through to kmalloc and * vmalloc, that is done for efficiency and to avoid unnecessary code. The caller * should not pass in these flags.) * * __GFP_REPEAT is supported, but only for large (>64kB) allocations. ? Or is that documentation overkill? Dunno, it sounds like an overkill to me. It is telling more than necessary. If we want to be so vocal about gfp flags then we would have to say much more I suspect. E.g. what about __GFP_HIGHMEM? This flag is supported for vmalloc while unsupported for kmalloc. I am pretty sure there would be other gfp flags to consider and then this would grow borringly large and uninteresting to the point when people simply stop reading it. Let's just be as simple as possible. Agreed, on the simplicity point: simple and clear is ideal. But here, it's merely short, and not quite simple. :) People will look at that short bit of documentation, and then notice that the flags are, in fact, all passed right on through down to both kmalloc_node and __vmalloc_node_flags. If you don't want too much documentation, then I'd be inclined to say something higher-level, about the intent, rather than mentioning those two flags directly. Because as it stands, the documentation contradicts what the code does. Feel free to suggest a better wording. I am, of course, open to any changes. OK, here's the best I've got, I tried to keep it concise, but (as you suspected) I'm not sure it's actually any better than the original: * Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in. * Passing in __GFP_REPEAT is supported, but note that it is ignored for small * (<=64KB) allocations, during the kmalloc attempt. __GFP_REPEAT is fully * honored for all allocation sizes during the second part: the vmalloc attempt. this is not true to be really precise because vmalloc doesn't respect the given gfp mask all the way down (look at the pte initialization). I'm having some difficulty in locating that pte initialization part, am I on the wrong code path? Here's what I checked, before making the claim about __GFP_REPEAT being honored: kvmalloc_node __vmalloc_node_flags __vmalloc_node __vmalloc_node_range __vmalloc_area_node alloc_pages_node __alloc_pages_node __alloc_pages __alloc_pages_nodemask __alloc_pages_slowpath ...and __alloc_pages_slowpath does the __GFP_REPEAT handling: /* * Do not retry costly high order allocations unless they are * __GFP_REPEAT */ if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT)) goto nopage; thanks, john h
[GIT PULL] two bug fixes for 4.10-rc5
Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: Two changes, the first is a fix to add a missing memory clobber to the inline assembly to load control registers. This has not caused any issues so far, but who knows what code gcc will generate in future versions. The second change is an update for the default configurations. This includes CONFIG_BUG_ON_DATA_CORRUPTION=y, we want this to be enabled for s390. The usual approach to debug problems on production systems is to use crash on a system dump and for us avoiding data corruptions is priority one. Heiko Carstens (2): s390/ctl_reg: make __ctl_load a full memory barrier s390: update defconfigs arch/s390/configs/default_defconfig | 27 +- arch/s390/configs/gcov_defconfig| 50 - arch/s390/configs/performance_defconfig | 33 ++ arch/s390/defconfig | 5 ++-- arch/s390/include/asm/ctl_reg.h | 4 ++- 5 files changed, 70 insertions(+), 49 deletions(-) diff --git a/arch/s390/configs/default_defconfig b/arch/s390/configs/default_defconfig index e659daf..e0097536 100644 --- a/arch/s390/configs/default_defconfig +++ b/arch/s390/configs/default_defconfig @@ -69,7 +69,7 @@ CONFIG_CMA=y CONFIG_CMA_DEBUG=y CONFIG_CMA_DEBUGFS=y CONFIG_MEM_SOFT_DIRTY=y -CONFIG_ZPOOL=m +CONFIG_ZSWAP=y CONFIG_ZBUD=m CONFIG_ZSMALLOC=m CONFIG_ZSMALLOC_STAT=y @@ -141,8 +141,6 @@ CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CONNTRACK_TIMEOUT=y CONFIG_NF_CONNTRACK_TIMESTAMP=y -CONFIG_NF_CT_PROTO_DCCP=m -CONFIG_NF_CT_PROTO_UDPLITE=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m @@ -159,13 +157,12 @@ CONFIG_NF_TABLES=m CONFIG_NFT_EXTHDR=m CONFIG_NFT_META=m CONFIG_NFT_CT=m -CONFIG_NFT_RBTREE=m -CONFIG_NFT_HASH=m CONFIG_NFT_COUNTER=m CONFIG_NFT_LOG=m CONFIG_NFT_LIMIT=m CONFIG_NFT_NAT=m CONFIG_NFT_COMPAT=m +CONFIG_NFT_HASH=m CONFIG_NETFILTER_XT_SET=m CONFIG_NETFILTER_XT_TARGET_AUDIT=m CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m @@ -219,7 +216,6 @@ CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_RATEEST=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_RECENT=m -CONFIG_NETFILTER_XT_MATCH_SOCKET=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m @@ -258,7 +254,6 @@ CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m CONFIG_IP_VS_PE_SIP=m CONFIG_NF_CONNTRACK_IPV4=m -# CONFIG_NF_CONNTRACK_PROC_COMPAT is not set CONFIG_NF_TABLES_IPV4=m CONFIG_NFT_CHAIN_ROUTE_IPV4=m CONFIG_NF_TABLES_ARP=m @@ -436,7 +431,6 @@ CONFIG_EQUALIZER=m CONFIG_IFB=m CONFIG_MACVLAN=m CONFIG_MACVTAP=m -CONFIG_IPVLAN=m CONFIG_VXLAN=m CONFIG_TUN=m CONFIG_VETH=m @@ -480,6 +474,7 @@ CONFIG_VIRTIO_BALLOON=m CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y +CONFIG_EXT4_ENCRYPTION=y CONFIG_JBD2_DEBUG=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y @@ -592,14 +587,12 @@ CONFIG_LOCK_STAT=y CONFIG_DEBUG_LOCKDEP=y CONFIG_DEBUG_ATOMIC_SLEEP=y CONFIG_DEBUG_LOCKING_API_SELFTESTS=y -CONFIG_DEBUG_LIST=y CONFIG_DEBUG_SG=y CONFIG_DEBUG_NOTIFIERS=y CONFIG_DEBUG_CREDENTIALS=y CONFIG_RCU_TORTURE_TEST=m CONFIG_RCU_CPU_STALL_TIMEOUT=300 CONFIG_NOTIFIER_ERROR_INJECTION=m -CONFIG_CPU_NOTIFIER_ERROR_INJECT=m CONFIG_PM_NOTIFIER_ERROR_INJECT=m CONFIG_FAULT_INJECTION=y CONFIG_FAILSLAB=y @@ -618,6 +611,7 @@ CONFIG_STACK_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_UPROBE_EVENT=y CONFIG_FUNCTION_PROFILER=y +CONFIG_HIST_TRIGGERS=y CONFIG_TRACE_ENUM_MAP_FILE=y CONFIG_LKDTM=m CONFIG_TEST_LIST_SORT=y @@ -630,6 +624,7 @@ CONFIG_TEST_STRING_HELPERS=y CONFIG_TEST_KSTRTOX=y CONFIG_DMA_API_DEBUG=y CONFIG_TEST_BPF=m +CONFIG_BUG_ON_DATA_CORRUPTION=y CONFIG_S390_PTDUMP=y CONFIG_ENCRYPTED_KEYS=m CONFIG_SECURITY=y @@ -640,16 +635,18 @@ CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_IMA=y CONFIG_IMA_APPRAISE=y +CONFIG_CRYPTO_RSA=m +CONFIG_CRYPTO_DH=m +CONFIG_CRYPTO_ECDH=m CONFIG_CRYPTO_USER=m -# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m -CONFIG_CRYPTO_CTS=m +CONFIG_CRYPTO_CHACHA20POLY1305=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m -CONFIG_CRYPTO_XTS=m +CONFIG_CRYPTO_KEYWRAP=m CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_VMAC=m CONFIG_CRYPTO_CRC32=m @@ -673,11 +670,13 @@ CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH=m -CONFIG_CRYPTO_LZO=m +CONFIG_CRYPTO_842=m CONFIG_CRYPTO_LZ4=m CONFIG_CRYPTO_LZ4HC=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m +CONFIG_CRYPTO_USER_API_RNG=m +CONFIG_CRYPTO_USER_API_AEAD=m CONFIG_ZCRYPT=m CONFIG_CRYPTO_SHA1_S390=m CONFIG_CRYPTO_SHA256_S390=m diff --git a/arch/s390/configs/gcov_defconfig b/arch/s390/configs/gcov_
Re: [PATCH v8 0/8] Add PWM and IIO timer drivers for STM32
On Wed, 18 Jan 2017, Benjamin Gaignard wrote: > version 8: > - rebase on v4.10-rc4 > - fix comments done by Thierry on PWM > - reword "reg" parameter description > - change kernel kernel in IIO ABI documentation > > version 7: > - rebase on v4.10-rc2 > - remove iio_device code from driver and keep only the trigger part > > version 6: > - rename stm32-gptimer in stm32-timers. > - change "st,stm32-gptimer" compatible to "st,stm32-timers". > - modify "st,breakinput" parameter in pwm part. > - split DT patch in 2 > > version 5: > - fix comments done on version 4 > - rebased on kernel 4.9-rc8 > - change nodes names and re-order then by addresses > > version 4: > - fix comments done on version 3 > - don't use interrupts anymore in IIO timer > - detect hardware capabilities at probe time to simplify binding > > version 3: > - no change on mfd and pwm divers patches > - add cross reference between bindings > - change compatible to "st,stm32-timer-trigger" > - fix attributes access rights > - use string instead of int for master_mode and slave_mode > - document device attributes in sysfs-bus-iio-timer-stm32 > - update DT with the new compatible > > version 2: > - keep only one compatible per driver > - use DT parameters to describe hardware block configuration: > - pwm channels, complementary output, counter size, break input > - triggers accepted and create by IIO timers > - change DT to limite use of reference to the node > - interrupt is now in IIO timer driver > - rename stm32-mfd-timer to stm32-timers (for general purpose timer) > > The following patches enable PWM and IIO Timer features for STM32 platforms. > > Those two features are mixed into the registers of the same hardware block > (named general purpose timer) which lead to introduce a multifunctions driver > on the top of them to be able to share the registers. > > In STM32f4 14 instances of timer hardware block exist, even if they all have > the same register mapping they could have a different number of pwm channels > and/or different triggers capabilities. We use various parameters in DT to > describe the differences between hardware blocks > > The MFD (stm32-timers.c) takes care of clock and register mapping > by using regmap. stm32_timers structure is provided to its sub-node to > share those information. > > PWM driver is implemented into pwm-stm32.c. Depending of the instance we may > have up to 4 channels, sometime with complementary outputs or 32 bits counter > instead of 16 bits. Some hardware blocks may also have a break input function > which allows to stop pwm depending of a level, defined in devicetree, on an > external pin. > > IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a > list > of hardware triggers usable by hardware blocks like ADC, DAC or other timers. > > The matrix of possible connections between blocks is quite complex so we use > trigger names and is_stm32_iio_timer_trigger() function to be sure that > triggers are valid and configure the IPs. > > At run time IIO timer hardware blocks can configure (through "master_mode" > IIO device attribute) which internal signal (counter enable, reset, > comparison block, etc...) is used to generate the trigger. > > Benjamin Gaignard (8): > MFD: add bindings for STM32 Timers driver > MFD: add STM32 Timers driver > PWM: add pwm-stm32 DT bindings > PWM: add PWM driver for STM32 plaftorm > IIO: add bindings for STM32 timer trigger driver > IIO: add STM32 timer trigger driver > ARM: dts: stm32: add Timers driver for stm32f429 MCU > ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco > > .../ABI/testing/sysfs-bus-iio-timer-stm32 | 29 ++ > .../bindings/iio/timer/stm32-timer-trigger.txt | 23 ++ > .../devicetree/bindings/mfd/stm32-timers.txt | 46 +++ > .../devicetree/bindings/pwm/pwm-stm32.txt | 35 ++ > arch/arm/boot/dts/stm32f429.dtsi | 275 ++ > arch/arm/boot/dts/stm32f469-disco.dts | 28 ++ > drivers/iio/trigger/Kconfig| 9 + > drivers/iio/trigger/Makefile | 1 + > drivers/iio/trigger/stm32-timer-trigger.c | 342 ++ > drivers/mfd/Kconfig| 11 + > drivers/mfd/Makefile | 2 + > drivers/mfd/stm32-timers.c | 80 + > drivers/pwm/Kconfig| 9 + > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-stm32.c| 398 > + > include/linux/iio/timer/stm32-timer-trigger.h | 62 > include/linux/mfd/stm32-timers.h | 71 > 17 files changed, 1422 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 > create mode 100644 > Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt > create mode 100644 Docume
Re: [PATCH 8/8] Revert "ext4: fix wrong gfp type under transaction"
On Tue 17-01-17 18:29:25, Jan Kara wrote:
> On Tue 17-01-17 17:16:19, Michal Hocko wrote:
> > > > But before going to play with that I am really wondering whether we need
> > > > all this with no journal at all. AFAIU what Jack told me it is the
> > > > journal lock(s) which is the biggest problem from the reclaim recursion
> > > > point of view. What would cause a deadlock in no journal mode?
> > >
> > > We still have the original problem for why we need GFP_NOFS even in
> > > ext2. If we are in a writeback path, and we need to allocate memory,
> > > we don't want to recurse back into the file system's writeback path.
> >
> > But we do not enter the writeback path from the direct reclaim. Or do
> > you mean something other than pageout()'s mapping->a_ops->writepage?
> > There is only try_to_release_page where we get back to the filesystems
> > but I do not see any NOFS protection in ext4_releasepage.
>
> Maybe to expand a bit: These days, direct reclaim can call ->releasepage()
> callback, ->evict_inode() callback (and only for inodes with i_nlink > 0),
> shrinkers. That's it. So the recursion possibilities are rather more limited
> than they used to be several years ago and we likely do not need as much
> GFP_NOFS protection as we used to.
Thanks for making my remark more clear Jack! I would just want to add
that I was playing with the patch below (it is basically
GFP_NOFS->GFP_KERNEL for all allocations which trigger warning from the
debugging patch which means they are called from within transaction) and
it didn't hit the lockdep when running xfstests both with or without the
enabled journal.
So am I still missing something or the nojournal mode is safe and the
current series is OK wrt. ext*?
The following patch in its current form is WIP and needs a proper review
before I post it.
---
fs/ext4/inode.c | 4 ++--
fs/ext4/mballoc.c | 14 +++---
fs/ext4/xattr.c | 2 +-
fs/jbd2/journal.c | 4 ++--
fs/jbd2/revoke.c | 2 +-
fs/jbd2/transaction.c | 2 +-
6 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index b7d141c3b810..841cb8c4cb5e 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2085,7 +2085,7 @@ static int ext4_writepage(struct page *page,
return __ext4_journalled_writepage(page, len);
ext4_io_submit_init(&io_submit, wbc);
- io_submit.io_end = ext4_init_io_end(inode, GFP_NOFS);
+ io_submit.io_end = ext4_init_io_end(inode, GFP_KERNEL);
if (!io_submit.io_end) {
redirty_page_for_writepage(wbc, page);
unlock_page(page);
@@ -3794,7 +3794,7 @@ static int __ext4_block_zero_page_range(handle_t *handle,
int err = 0;
page = find_or_create_page(mapping, from >> PAGE_SHIFT,
- mapping_gfp_constraint(mapping, ~__GFP_FS));
+ mapping_gfp_mask(mapping));
if (!page)
return -ENOMEM;
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index d9fd184b049e..67b97cd6e3d6 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -1251,7 +1251,7 @@ ext4_mb_load_buddy_gfp(struct super_block *sb,
ext4_group_t group,
static int ext4_mb_load_buddy(struct super_block *sb, ext4_group_t group,
struct ext4_buddy *e4b)
{
- return ext4_mb_load_buddy_gfp(sb, group, e4b, GFP_NOFS);
+ return ext4_mb_load_buddy_gfp(sb, group, e4b, GFP_KERNEL);
}
static void ext4_mb_unload_buddy(struct ext4_buddy *e4b)
@@ -2054,7 +2054,7 @@ static int ext4_mb_good_group(struct
ext4_allocation_context *ac,
/* We only do this if the grp has never been initialized */
if (unlikely(EXT4_MB_GRP_NEED_INIT(grp))) {
- int ret = ext4_mb_init_group(ac->ac_sb, group, GFP_NOFS);
+ int ret = ext4_mb_init_group(ac->ac_sb, group, GFP_KERNEL);
if (ret)
return ret;
}
@@ -3600,7 +3600,7 @@ ext4_mb_new_inode_pa(struct ext4_allocation_context *ac)
BUG_ON(ac->ac_status != AC_STATUS_FOUND);
BUG_ON(!S_ISREG(ac->ac_inode->i_mode));
- pa = kmem_cache_alloc(ext4_pspace_cachep, GFP_NOFS);
+ pa = kmem_cache_alloc(ext4_pspace_cachep, GFP_KERNEL);
if (pa == NULL)
return -ENOMEM;
@@ -3694,7 +3694,7 @@ ext4_mb_new_group_pa(struct ext4_allocation_context *ac)
BUG_ON(!S_ISREG(ac->ac_inode->i_mode));
BUG_ON(ext4_pspace_cachep == NULL);
- pa = kmem_cache_alloc(ext4_pspace_cachep, GFP_NOFS);
+ pa = kmem_cache_alloc(ext4_pspace_cachep, GFP_KERNEL);
if (pa == NULL)
return -ENOMEM;
@@ -4479,7 +4479,7 @@ ext4_fsblk_t ext4_mb_new_blocks(handle_t *handle,
}
}
- ac = kmem_cache_zalloc(ext4_ac_cachep, GFP_NOFS);
+ ac = kmem_cache_zalloc(ext4_ac_cachep, GFP_KERNEL);
if (!ac) {
ar->len = 0;
*errp =
Re: [PATCH 1/7] scsi: hisi_sas: workaround v2 hw SATA IO timeout issue
On Thu, Jan 19, 2017 at 12:32:47AM +0800, John Garry wrote: > From: Xiang Chen > > The v2 SAS controller needs more time to detect channel idle > and send setup link request than SATA disk does, so it is > difficult for SAS controller to setup an STP link. Therefore it > may cause some IO timeouts. > > We need to periodically configure the SAS controller so it > doesn't receive STP setup requests from SATA disks for a while, > so IO can be sent during this period. > > Signed-off-by: Xiang Chen > Signed-off-by: John Garry > --- Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 2/7] scsi: hisi_sas: modify some values of ITCT table
On Thu, Jan 19, 2017 at 12:32:48AM +0800, John Garry wrote: > From: Xiang Chen > > Set SMP connection timeout and continue AWT timer; > Clear ITCT table when dev gone. > > Signed-off-by: Xiang Chen > Signed-off-by: John Garry > --- > drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c > b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c > index 6c787eb..452e329 100644 > --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c > +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c > @@ -334,6 +334,8 @@ > #define ITCT_HDR_MCR_MSK (0xf << ITCT_HDR_MCR_OFF) > #define ITCT_HDR_VLN_OFF 9 > #define ITCT_HDR_VLN_MSK (0xf << ITCT_HDR_VLN_OFF) > +#define ITCT_HDR_SMP_TIMEOUT_OFF 16 > +#define ITCT_HDR_AWT_CONTINUE_OFF25 > #define ITCT_HDR_PORT_ID_OFF 28 > #define ITCT_HDR_PORT_ID_MSK (0xf << ITCT_HDR_PORT_ID_OFF) > /* qw2 */ > @@ -696,6 +698,8 @@ static void setup_itct_v2_hw(struct hisi_hba *hisi_hba, > qw0 |= ((1 << ITCT_HDR_VALID_OFF) | > (device->linkrate << ITCT_HDR_MCR_OFF) | > (1 << ITCT_HDR_VLN_OFF) | > + (0xfa << ITCT_HDR_SMP_TIMEOUT_OFF) | ^~ You may want to give that magic value a name. Other than that, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 3/7] scsi: hisi_sas: downgrade refclk message
On Thu, Jan 19, 2017 at 12:32:49AM +0800, John Garry wrote: > The message to inform that the controller has no refclk > is currently at warning level, which is unnecessary, so > downgrade to debug. > > Signed-off-by: John Garry > Reviewed-by: Xiang Chen > --- Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 6/7] scsi: hisi_sas: fix probe ordering problem
On Thu, Jan 19, 2017 at 12:32:52AM +0800, John Garry wrote: > From: Xiang Chen > > There is a potential probe issue in how we trigger the hw initialisation. > Although we use 1s timer to delay hw initialisation, there is still a > potential that sas_register_ha() is not be finished before we start > the PHY init from hw->hw_init(). > To avoid this issue, initialise the hw after sas_register_ha() in the > same probe context. > Note: it is not necessary to use 1s timer now (modified v2 hw only). > > Signed-off-by: Xiang Chen > Signed-off-by: John Garry > --- Looks OK, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH v3] IOMMU: SMMUv2: Support for Extended Stream ID (16 bit)
Hi Aleksey,
On 17.01.2017 16:14, Aleksey Makarov wrote:
Enable the Extended Stream ID feature when available.
This patch on top of series "KVM PCIe/MSI passthrough on ARM/ARM64
and IOVA reserved regions" by Eric Auger [1] allows to passthrough
an external PCIe network card on a ThunderX server successfully.
Without this patch that card caused a warning like
pci 0006:90:00.0: stream ID 0x9000 out of range for SMMU (0x7fff)
during boot.
[1]
https://lkml.kernel.org/r/1484127714-3263-1-git-send-email-eric.au...@redhat.com
Signed-off-by: Aleksey Makarov
I do not thing this is related to PCIe network card. It is rather common
to all devices which bus number > 127
iommu/arm-smmu: Support for Extended Stream ID (16 bit)
It is the time we have the real 16-bit Stream ID user, which is the
ThunderX. Its IO topology uses 1:1 map for requester to stream ID
translation:
RC no. | Requester ID | Stream ID
| |
RC_0 | 0- ---> | 0-
which allows to get full 16-bit stream ID. Currently all devices with
bus number >= 128 (0x80) get non-zero 16th bit of BDF and stream ID (due
to 1:1 map). Eventually SMMU drops such device because the stream ID is
out of range. This is the case for all devices connected as external
endpoints on ThunderX.
To fix above issue enable the Extended Stream ID optional feature when
available.
Please add my:
Reviewed-by: Tomasz Nowicki
Tested-by: Tomasz Nowicki
Thanks,
Tomasz
---
v3:
- keep formatting of the comment
- fix printk message after the deleted chunk. "[Do] not print a mask
here, since it's not overly interesting in itself, and add_device will
still show the offending mask in full if it ever actually matters (as in
the commit message)." (Robin Murphy)
v2:
https://lkml.kernel.org/r/2017011614.29444-1-aleksey.maka...@linaro.org
- remove unnecessary parentheses (Robin Murphy)
- refactor testing SMR fields to after setting sCR0 as theirs width
depends on sCR0_EXIDENABLE (Robin Murphy)
v1 (rfc):
https://lkml.kernel.org/r/20170110115755.19102-1-aleksey.maka...@linaro.org
drivers/iommu/arm-smmu.c | 69 +---
1 file changed, 48 insertions(+), 21 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 13d26009b8e0..861cc135722f 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -24,6 +24,7 @@
* - v7/v8 long-descriptor format
* - Non-secure access to the SMMU
* - Context fault reporting
+ * - Extended Stream ID (16 bit)
*/
#define pr_fmt(fmt) "arm-smmu: " fmt
@@ -87,6 +88,7 @@
#define sCR0_CLIENTPD (1 << 0)
#define sCR0_GFRE (1 << 1)
#define sCR0_GFIE (1 << 2)
+#define sCR0_EXIDENABLE(1 << 3)
#define sCR0_GCFGFRE (1 << 4)
#define sCR0_GCFGFIE (1 << 5)
#define sCR0_USFCFG(1 << 10)
@@ -126,6 +128,7 @@
#define ID0_NUMIRPT_MASK 0xff
#define ID0_NUMSIDB_SHIFT 9
#define ID0_NUMSIDB_MASK 0xf
+#define ID0_EXIDS (1 << 8)
#define ID0_NUMSMRG_SHIFT 0
#define ID0_NUMSMRG_MASK 0xff
@@ -169,6 +172,7 @@
#define ARM_SMMU_GR0_S2CR(n) (0xc00 + ((n) << 2))
#define S2CR_CBNDX_SHIFT 0
#define S2CR_CBNDX_MASK0xff
+#define S2CR_EXIDVALID (1 << 10)
#define S2CR_TYPE_SHIFT16
#define S2CR_TYPE_MASK 0x3
enum arm_smmu_s2cr_type {
@@ -354,6 +358,7 @@ struct arm_smmu_device {
#define ARM_SMMU_FEAT_FMT_AARCH64_64K (1 << 9)
#define ARM_SMMU_FEAT_FMT_AARCH32_L(1 << 10)
#define ARM_SMMU_FEAT_FMT_AARCH32_S(1 << 11)
+#define ARM_SMMU_FEAT_EXIDS(1 << 12)
u32 features;
#define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
@@ -1051,7 +1056,7 @@ static void arm_smmu_write_smr(struct arm_smmu_device
*smmu, int idx)
struct arm_smmu_smr *smr = smmu->smrs + idx;
u32 reg = smr->id << SMR_ID_SHIFT | smr->mask << SMR_MASK_SHIFT;
- if (smr->valid)
+ if (!(smmu->features & ARM_SMMU_FEAT_EXIDS) && smr->valid)
reg |= SMR_VALID;
writel_relaxed(reg, ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_SMR(idx));
}
@@ -1063,6 +1068,9 @@ static void arm_smmu_write_s2cr(struct arm_smmu_device
*smmu, int idx)
(s2cr->cbndx & S2CR_CBNDX_MASK) << S2CR_CBNDX_SHIFT |
(s2cr->privcfg & S2CR_PRIVCFG_MASK) << S2CR_PRIVCFG_SHIFT;
+ if (smmu->features & ARM_SMMU_FEAT_EXIDS && smmu->smrs &&
+ smmu->smrs[idx].valid)
+ reg |= S2CR_EXIDVALID;
writel_relaxed(reg, ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_S2CR(idx));
}
@@ -1073,6 +1081,34 @@ static void arm_smmu_write_sme(struct arm_smmu_device
*smmu, int idx)
arm_smmu_write_smr(smmu, idx)
Re: [PATCH 2/7] scsi: hisi_sas: modify some values of ITCT table
On 19/01/2017 08:44, Johannes Thumshirn wrote: On Thu, Jan 19, 2017 at 12:32:48AM +0800, John Garry wrote: From: Xiang Chen Set SMP connection timeout and continue AWT timer; Clear ITCT table when dev gone. Signed-off-by: Xiang Chen Signed-off-by: John Garry --- drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c index 6c787eb..452e329 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c @@ -334,6 +334,8 @@ #define ITCT_HDR_MCR_MSK (0xf << ITCT_HDR_MCR_OFF) #define ITCT_HDR_VLN_OFF 9 #define ITCT_HDR_VLN_MSK (0xf << ITCT_HDR_VLN_OFF) +#define ITCT_HDR_SMP_TIMEOUT_OFF 16 +#define ITCT_HDR_AWT_CONTINUE_OFF 25 #define ITCT_HDR_PORT_ID_OFF 28 #define ITCT_HDR_PORT_ID_MSK (0xf << ITCT_HDR_PORT_ID_OFF) /* qw2 */ @@ -696,6 +698,8 @@ static void setup_itct_v2_hw(struct hisi_hba *hisi_hba, qw0 |= ((1 << ITCT_HDR_VALID_OFF) | (device->linkrate << ITCT_HDR_MCR_OFF) | (1 << ITCT_HDR_VLN_OFF) | + (0xfa << ITCT_HDR_SMP_TIMEOUT_OFF) | ^~ You may want to give that magic value a name. Thanks for having a look. We will create a new patch without the mysterious value. Regards, John Other than that, Reviewed-by: Johannes Thumshirn
Re: __mutex_lock_common() unlikely very likely
On Wed, Jan 18, 2017 at 03:58:24PM -0500, Steven Rostedt wrote:
> Chris,
>
> My branch tracer flagged the unlikely in __mutex_lock_common() as
> always hit. That's the:
>
> if (use_ww_ctx) {
> [...]
> if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
> return -EALREADY;
> }
>
> This is hit 100% of the time, and its coming from the drm logic:
By design this is an exceptional case. In practice, drm modesetting is a
little slapsidasical when it comes to locking. However, it is the
minority use case, just that on intel, the more prevalent users do not
hit this path - though they will with the ww_mutex refactoring work. ttm
drivers (amdgpu, nouveau etc) will be demonstrating that this is the
unlikely branch.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Re: [patch -mm] mm, page_alloc: warn_alloc nodemask is NULL when cpusets are disabled
On Thu 19-01-17 08:29:45, Vlastimil Babka wrote: > On 01/18/2017 10:51 PM, David Rientjes wrote: > > The patch "mm, page_alloc: warn_alloc print nodemask" implicitly sets the > > allocation nodemask to cpuset_current_mems_allowed when there is no > > effective mempolicy. cpuset_current_mems_allowed is only effective when > > cpusets are enabled, which is also printed by warn_alloc(), so setting > > the nodemask to cpuset_current_mems_allowed is redundant and prevents > > debugging issues where ac->nodemask is not set properly in the page > > allocator. > > > > This provides better debugging output since > > cpuset_print_current_mems_allowed() is already provided. > > > > Signed-off-by: David Rientjes > > Yes, with my current cpuset vs mempolicy debugging experience, this is > more useful (except how both nodemask and mems_allowed can change under > us, so what we print here is not necessarily the same that what > get_page_from_freelist() has seen, but that's another thing...). > > But I would suggest you change the oom killer's dump_header() the same > way than warn_alloc(). Yes please -- Michal Hocko SUSE Labs
Re: [PATCH 7/7] scsi: hisi_sas: decrease running_req in hisi_sas_slot_task_free()
On Thu, Jan 19, 2017 at 12:32:53AM +0800, John Garry wrote: > From: Xiang Chen > > There is an issue that hisi_sas_dev.running_req is not > decremented properly for internal abort and TMF. > > To resolve, only decrease running_req in hisi_sas_slot_task_free() > > Signed-off-by: Xiang Chen > Signed-off-by: John Garry > --- Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH v3] EDAC: expose per-dimm error counts in sysfs
On 11/4/16, 4:21 AM, "Borislav Petkov" wrote: LGTM. Acked-by: Borislav Petkov Mauro, I'm assuming you're picking up this. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. Did this ever get picked up?
Re: Potential issues (security and otherwise) with the current cgroup-bpf API
On Wed 18-01-17 14:18:50, Tejun Heo wrote: > Hello, Michal. > > On Tue, Jan 17, 2017 at 02:58:30PM +0100, Michal Hocko wrote: > > This would require using hierarchical cgroup iterators to iterate over > > It does behave hierarchically. > > > tasks. As per Andy's testing this doesn't seem to be the case. I haven't > > That's not what Andy's testing showed. What that showed was that > program in a child can override the one from its ancestor. My fault, I've misread Andy's test case. I thought that the child group simply disabled the bpf program and the one from the parent hasn't executed. -- Michal Hocko SUSE Labs
Re: [PATCH v2 3/3] gpio: Support gpio nexus dt bindings
On Wed, Jan 18, 2017 at 1:50 AM, Stephen Boyd wrote: > Platforms like 96boards have a standardized connector/expansion > slot that exposes signals like GPIOs to expansion boards in an > SoC agnostic way. We'd like the DT overlays for the expansion > boards to be written once without knowledge of the SoC on the > other side of the connector. This avoids the unscalable > combinatorial explosion of a different DT overlay for each > expansion board and SoC pair. > > Now that we have nexus support in the OF core let's change the > function call here that parses the phandle lists of gpios to use > the nexus variant. This allows us to remap phandles and their > arguments through any number of nexus nodes and end up with the > actual gpio provider being used. > > Cc: Pantelis Antoniou > Cc: Linus Walleij > Cc: Mark Brown > Signed-off-by: Stephen Boyd Acked-by: Linus Walleij Provided that patches 1 & 2 go in reviewed and merged by DT/device core people, they can merge this on top as well. Yours, Linus Walleij
Re: [PATCH 1/6] mm: introduce kv[mz]alloc helpers
On Thu 19-01-17 00:37:08, John Hubbard wrote: > > > On 01/18/2017 12:21 AM, Michal Hocko wrote: > > On Tue 17-01-17 21:59:13, John Hubbard wrote: [...] > > > * Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be > > > passed in. > > > * Passing in __GFP_REPEAT is supported, but note that it is ignored for > > > small > > > * (<=64KB) allocations, during the kmalloc attempt. > > > > > __GFP_REPEAT is fully > > > * honored for all allocation sizes during the second part: the vmalloc > > > attempt. > > > > this is not true to be really precise because vmalloc doesn't respect > > the given gfp mask all the way down (look at the pte initialization). > > > > I'm having some difficulty in locating that pte initialization part, am I on > the wrong code path? Here's what I checked, before making the claim about > __GFP_REPEAT being honored: > > kvmalloc_node > __vmalloc_node_flags > __vmalloc_node > __vmalloc_node_range > __vmalloc_area_node map_vm_area vmap_page_range vmap_page_range_noflush vmap_pud_range pud_alloc __pud_alloc pud_alloc_one pud will be allocated but the same pattern repeats on the pmd and pte levels. This is btw. one of the reasons why vmalloc with gfp flags is tricky! moreover > alloc_pages_node this is order-0 request so... > __alloc_pages_node > __alloc_pages > __alloc_pages_nodemask > __alloc_pages_slowpath > > > ...and __alloc_pages_slowpath does the __GFP_REPEAT handling: > > /* > * Do not retry costly high order allocations unless they are > * __GFP_REPEAT > */ > if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT)) > goto nopage; ... this doesn't apply -- Michal Hocko SUSE Labs
Re: [PATCH 5/7] scsi: hisi_sas: downgrade internal abort exit print
On Thu, Jan 19, 2017 at 12:32:51AM +0800, John Garry wrote: > Downgrade the exit print in hisi_sas_internal_task_abort() > to dbg level, as info is not required. > > Signed-off-by: John Garry > Reviewed-by: Xiang Chen > --- Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 4/7] scsi: hisi_sas: modify hard reset for directed-attached disk
On Thu, Jan 19, 2017 at 12:32:50AM +0800, John Garry wrote: > From: Xiang Chen > > Correctly set registers in v2 for root PHY hardreset for directly > attached disk. > > Signed-off-by: Xiang Chen > Signed-off-by: John Garry > --- Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 13/13] MIPS: jz4740: Remove custom GPIO code
On Wed, Jan 18, 2017 at 12:14 AM, Paul Cercueil wrote: > All the drivers for the various hardware elements of the jz4740 SoC have > been modified to use the pinctrl framework for their pin configuration > needs. > As such, this platform code is now unused and can be deleted. > > Signed-off-by: Paul Cercueil I feel I might have come across as a bit harsh in the previous review of the patches leading up to this one. In that case I'm sorry. I can clearly see that the intent of the series is to remove this hopelessly idiomatic code from the MIPS hurdle, and move these systems over to standard frameworks. In a way, if I look at the kernel as a whole, it would likely look better after these patches were merged, than before. Even with the shortcomings I painted out in the previous review comments. A very complicated piece of messy code is cut from MIPS. I think this is very valuable work and well worth persuing, so please go ahead and work with the series, your effort is very much appreciated! Yours, Linus Walleij
Re: [PATCH v3 00/18] FSI device driver introduction
On Tue, Jan 17, 2017 at 04:00:41PM -0600, Christopher Bostic wrote: > On Tue, Jan 17, 2017 at 1:42 AM, Greg KH wrote: > > On Mon, Jan 16, 2017 at 03:22:48PM -0600, christopher.lee.bos...@gmail.com > > wrote: > >> From: Chris Bostic > > > > > > > > Only this, and patch 02/18 came through, did something get stuck on your > > end? > > > > Hi Greg, > > Yes had an issue with the server blocking send, investigating why. It's still failing, I keep getting only the 00 email :(
Re: [PATCH v20 13/17] acpi/arm64: Add GTDT table parse driver
On 2017/1/18 21:25, fu@linaro.org wrote:
From: Fu Wei
This patch adds support for parsing arch timer info in GTDT,
provides some kernel APIs to parse all the PPIs and
always-on info in GTDT and export them.
By this driver, we can simplify arm_arch_timer drivers, and
separate the ACPI GTDT knowledge from it.
Signed-off-by: Fu Wei
Signed-off-by: Hanjun Guo
Acked-by: Rafael J. Wysocki
Tested-by: Xiongfeng Wang
---
arch/arm64/Kconfig | 1 +
drivers/acpi/arm64/Kconfig | 3 +
drivers/acpi/arm64/Makefile | 1 +
drivers/acpi/arm64/gtdt.c | 157
include/linux/acpi.h| 6 ++
5 files changed, 168 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1117421..ab1ee10 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2,6 +2,7 @@ config ARM64
def_bool y
select ACPI_CCA_REQUIRED if ACPI
select ACPI_GENERIC_GSI if ACPI
+ select ACPI_GTDT if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ACPI_MCFG if ACPI
select ACPI_SPCR_TABLE if ACPI
diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
index 4616da4..5a6f80f 100644
--- a/drivers/acpi/arm64/Kconfig
+++ b/drivers/acpi/arm64/Kconfig
@@ -4,3 +4,6 @@
config ACPI_IORT
bool
+
+config ACPI_GTDT
+ bool
diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
index 72331f2..1017def 100644
--- a/drivers/acpi/arm64/Makefile
+++ b/drivers/acpi/arm64/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_ACPI_IORT)+= iort.o
+obj-$(CONFIG_ACPI_GTDT)+= gtdt.o
diff --git a/drivers/acpi/arm64/gtdt.c b/drivers/acpi/arm64/gtdt.c
new file mode 100644
index 000..d93a790
--- /dev/null
+++ b/drivers/acpi/arm64/gtdt.c
@@ -0,0 +1,157 @@
[...]
+
+/**
+ * acpi_gtdt_init() - Get the info of GTDT table to prepare for further init.
+ * @table: The pointer to GTDT table.
+ * @platform_timer_count: The pointer of int variate for returning the
+ * number of platform timers. It can be NULL, if
+ * driver don't need this info.
+ *
+ * Return: 0 if success, -EINVAL if error.
+ */
+int __init acpi_gtdt_init(struct acpi_table_header *table,
+ int *platform_timer_count)
+{
+ int ret = 0;
+ int timer_count = 0;
+ void *platform_timer = NULL;
+ struct acpi_table_gtdt *gtdt;
+
+ gtdt = container_of(table, struct acpi_table_gtdt, header);
+ acpi_gtdt_desc.gtdt = gtdt;
+ acpi_gtdt_desc.gtdt_end = (void *)table + table->length;
+
+ if (table->revision < 2)
+ pr_debug("Revision:%d doesn't support Platform Timers.\n",
+table->revision);
GTDT table revision is updated to 2 in ACPI 5.1, we will
not support ACPI version under 5.1 and disable ACPI in FADT
parse before this code is called, so if we get revision
<2 here, I think we need to print warning (we need to keep
the firmware stick to the spec on ARM64).
+ else if (!gtdt->platform_timer_count)
+ pr_debug("No Platform Timer.\n");
+ else
+ timer_count = gtdt->platform_timer_count;
+
+ if (timer_count) {
+ platform_timer = (void *)gtdt + gtdt->platform_timer_offset;
+ if (platform_timer < (void *)table +
+sizeof(struct acpi_table_gtdt)) {
+ pr_err(FW_BUG "invalid timer data.\n");
It's ok but I didn't see other ACPI tables parsing did this check,
maybe we can just remove it :)
+ timer_count = 0;
+ platform_timer = NULL;
+ ret = -EINVAL;
+ }
+ }
+
+ acpi_gtdt_desc.platform_timer = platform_timer;
+ if (platform_timer_count)
+ *platform_timer_count = timer_count;
Then the code will much simple:
if (gtdt->platform_timer_count) {
acpi_gtdt_desc.platform_timer = (void *)gtdt +
gtdt->platform_timer_offset;
if (platform_timer_count)
*platform_timer_count = gtdt->platform_timer_count;
}
return 0;
and remove ret, timer_count and platform_timer.
Thanks
Hanjun
Re: [PATCH v5 0/4] usb: early: add support for early printk through USB3 debug port
* Greg Kroah-Hartman wrote: > On Wed, Jan 18, 2017 at 02:20:30PM +0800, Lu Baolu wrote: > > Hi Greg, > > > > This patch series has been there for 2 months without > > further comments. Will you consider it for usb-next? > > I needed acks from the x86 maintainers before I could take those > patches. Can you resend the series and hopefully get them? Thanks for the reminder - the patches look mostly good to me, I have a few very minor observations, I'll reply to the patches. Thanks, Ingo
Re: [PATCH v5 0/4] usb: early: add support for early printk through USB3 debug port
* Lu Baolu wrote: > xHCI debug capability (DbC) is an optional but standalone > functionality provided by an xHCI host controller. With DbC > hardware initialized, the system will present a debug device > through the USB3 debug port (normally the first USB3 port). > The debug device is fully compliant with the USB framework > and provides the equivalent of a very high performance (USB3) > full-duplex serial link between the debug host and target. > The DbC functionality is independent of xHCI host. There > isn't any precondition from xHCI host side for DbC to work. > > This patch set adds support for early printk functionality > through a USB3 debug port by 1) initializing and enabling > the DbC hardware during early boot; 2) registering a boot > console to the system so that early printk messages can go > through the USB3 debug port. It also includes some lines > of changes in usb_debug driver so that it can be bound when > a USB3 debug device is enumerated. > > This code is designed to be used only for kernel debugging > when machine crashes very early before the console code is > initialized. It makes the life of kernel debugging easier > when people work with a modern machine without any legacy > serial ports. BTW., just a side note, some kernel developers (like PeterZ - and I do it sometimes too) remap early_printk to printk permanently and use it as their main printk facility - because printk() reliability has suffered over the last couple of years. So it's more than just early boot debugging - it's a very simple state-less logging facility to an external computer. Thanks, ngo
[PATCH] ARM: Exynos4415: remove dead build rule
Commit 22dfab102cfa ("ARM: EXYNOS: Remove Exynos4415 arch code (SoC not
supported anymore)") removed the Kconfig option SOC_EXYNOS4415. Thus,
we are safe to remove the last reference in the Makefile.
Signed-off-by: Valentin Rothberg
---
Detected by using ./scripts/checkkconfigsymbols.py
drivers/clk/samsung/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 57f4dc6dc447..7afc21dc374e 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -5,7 +5,6 @@
obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
-obj-$(CONFIG_SOC_EXYNOS4415) += clk-exynos4415.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5260) += clk-exynos5260.o
obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o
--
2.11.0
Re: [PATCH v8 3/8] PWM: add pwm-stm32 DT bindings
On Wed, Jan 18, 2017 at 03:20:46PM +0100, Benjamin Gaignard wrote: > Define bindings for pwm-stm32 > > version 8: > - reword st,breakinput description. > > version 6: > - change st,breakinput parameter format to make it usuable on stm32f7 too. > > version 2: > - use parameters instead of compatible of handle the hardware configuration > > Signed-off-by: Benjamin Gaignard > Acked-by: Rob Herring > --- > .../devicetree/bindings/pwm/pwm-stm32.txt | 35 > ++ > 1 file changed, 35 insertions(+) > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt One last nit: please use "dt-bindings: pwm:" as prefix for the patch subject. So it would read something like this: dt-bindings: pwm: Add STM32 bindings or similar. That's the style that's been used for a while now. I'd have fixed that up myself, but since Lee plans to take this through the MFD tree I'd like to see that fixed up before it gets applied. With the above: Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH v5 0/4] usb: early: add support for early printk through USB3 debug port
On Wed, Jan 18, 2017 at 02:20:30PM +0800, Lu Baolu wrote: > Hi Greg, > > This patch series has been there for 2 months without > further comments. Will you consider it for usb-next? I needed acks from the x86 maintainers before I could take those patches. Can you resend the series and hopefully get them? thanks, greg k-h
Re: [PATCH v5 01/13] lockdep: Refactor lookup_chain_cache()
On Wed, Jan 18, 2017 at 10:17:27PM +0900, Byungchul Park wrote:
> Currently, lookup_chain_cache() provides both 'lookup' and 'add'
> functionalities in a function. However, each is useful. So this
> patch makes lookup_chain_cache() only do 'lookup' functionality and
> makes add_chain_cahce() only do 'add' functionality. And it's more
> readable than before.
>
> Signed-off-by: Byungchul Park
> ---
> kernel/locking/lockdep.c | 129
> +--
> 1 file changed, 81 insertions(+), 48 deletions(-)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 4d7ffc0..f37156f 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -2109,15 +2109,9 @@ static int check_no_collision(struct task_struct *curr,
> return 1;
> }
>
> -/*
> - * Look up a dependency chain. If the key is not present yet then
> - * add it and return 1 - in this case the new dependency chain is
> - * validated. If the key is already hashed, return 0.
> - * (On return with 1 graph_lock is held.)
> - */
I think you'd better put some comments here for the behavior of
add_chain_cache(), something like:
/*
* Add a dependency chain into chain hashtable.
*
* Must be called with graph_lock held.
* Return 0 if fail to add the chain, and graph_lock is released.
* Return 1 with graph_lock held if succeed.
*/
Regards,
Boqun
> -static inline int lookup_chain_cache(struct task_struct *curr,
> - struct held_lock *hlock,
> - u64 chain_key)
> +static inline int add_chain_cache(struct task_struct *curr,
> + struct held_lock *hlock,
> + u64 chain_key)
> {
> struct lock_class *class = hlock_class(hlock);
> struct hlist_head *hash_head = chainhashentry(chain_key);
> @@ -2125,49 +2119,18 @@ static inline int lookup_chain_cache(struct
> task_struct *curr,
> int i, j;
>
> /*
> + * Allocate a new chain entry from the static array, and add
> + * it to the hash:
> + */
> +
> + /*
>* We might need to take the graph lock, ensure we've got IRQs
>* disabled to make this an IRQ-safe lock.. for recursion reasons
>* lockdep won't complain about its own locking errors.
>*/
> if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
> return 0;
[...]
signature.asc
Description: PGP signature
Re: [PATCH 1/6] mm: introduce kv[mz]alloc helpers
On 01/19/2017 12:45 AM, Michal Hocko wrote: On Thu 19-01-17 00:37:08, John Hubbard wrote: On 01/18/2017 12:21 AM, Michal Hocko wrote: On Tue 17-01-17 21:59:13, John Hubbard wrote: [...] * Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in. * Passing in __GFP_REPEAT is supported, but note that it is ignored for small * (<=64KB) allocations, during the kmalloc attempt. __GFP_REPEAT is fully * honored for all allocation sizes during the second part: the vmalloc attempt. this is not true to be really precise because vmalloc doesn't respect the given gfp mask all the way down (look at the pte initialization). I'm having some difficulty in locating that pte initialization part, am I on the wrong code path? Here's what I checked, before making the claim about __GFP_REPEAT being honored: kvmalloc_node __vmalloc_node_flags __vmalloc_node __vmalloc_node_range __vmalloc_area_node map_vm_area vmap_page_range vmap_page_range_noflush vmap_pud_range pud_alloc __pud_alloc pud_alloc_one pud will be allocated but the same pattern repeats on the pmd and pte levels. This is btw. one of the reasons why vmalloc with gfp flags is tricky! Yes, I see that now, thank you for explaining, much appreciated. The flags are left way behind in the code path. So that leaves us with maybe this for documentation? * Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in. * Passing in __GFP_REPEAT is supported, and will cause the following behavior: * for larger (>64KB) allocations, the first part (kmalloc) will do some * retrying, before falling back to vmalloc. moreover alloc_pages_node this is order-0 request so... __alloc_pages_node __alloc_pages __alloc_pages_nodemask __alloc_pages_slowpath ...and __alloc_pages_slowpath does the __GFP_REPEAT handling: /* * Do not retry costly high order allocations unless they are * __GFP_REPEAT */ if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT)) goto nopage; ... this doesn't apply yes, true. thanks john h
[PATCH v5 1/2] tpm: implement TPM 2.0 capability to get active PCR banks
This patch implements the TPM 2.0 capability TPM_CAP_PCRS to
retrieve the active PCR banks from the TPM. This is needed
to enable extending all active banks as recommended by TPM 2.0
TCG Specification.
Signed-off-by: Nayna Jain
Reviewed-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm.h | 4
drivers/char/tpm/tpm2-cmd.c | 57 +
2 files changed, 61 insertions(+)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 1ae9768..573 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -127,6 +127,7 @@ enum tpm2_permanent_handles {
};
enum tpm2_capabilities {
+ TPM2_CAP_PCRS = 5,
TPM2_CAP_TPM_PROPERTIES = 6,
};
@@ -187,6 +188,8 @@ struct tpm_chip {
const struct attribute_group *groups[3];
unsigned int groups_cnt;
+
+ u16 active_banks[7];
#ifdef CONFIG_ACPI
acpi_handle acpi_dev_handle;
char ppi_version[TPM_PPI_VERSION_LEN + 1];
@@ -545,4 +548,5 @@ int tpm2_auto_startup(struct tpm_chip *chip);
void tpm2_shutdown(struct tpm_chip *chip, u16 shutdown_type);
unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
int tpm2_probe(struct tpm_chip *chip);
+ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip);
#endif
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 6eda239..75a7546 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -998,3 +998,60 @@ int tpm2_auto_startup(struct tpm_chip *chip)
rc = -ENODEV;
return rc;
}
+
+struct tpm2_pcr_selection {
+ __be16 hash_alg;
+ u8 size_of_select;
+ u8 pcr_select[3];
+} __packed;
+
+/**
+ * tpm2_get_pcr_allocation() - get TPM active PCR banks.
+ *
+ * @chip: TPM chip to use.
+ *
+ * Return: Same as with tpm_transmit_cmd.
+ */
+ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
+{
+ struct tpm2_pcr_selection pcr_selection;
+ struct tpm_buf buf;
+ void *marker;
+ unsigned int count = 0;
+ int rc;
+ int i;
+
+ rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_GET_CAPABILITY);
+ if (rc)
+ return rc;
+
+ tpm_buf_append_u32(&buf, TPM2_CAP_PCRS);
+ tpm_buf_append_u32(&buf, 0);
+ tpm_buf_append_u32(&buf, 1);
+
+ rc = tpm_transmit_cmd(chip, buf.data, PAGE_SIZE, 0,
+ "get tpm pcr allocation");
+ if (rc < 0)
+ goto out;
+
+ count = be32_to_cpup(
+ (__be32 *)&buf.data[TPM_HEADER_SIZE + 5]);
+
+ if (count > ARRAY_SIZE(chip->active_banks))
+ return -ENODEV;
+
+ marker = &buf.data[TPM_HEADER_SIZE + 9];
+ for (i = 0; i < count; i++) {
+ memcpy(&pcr_selection, marker, sizeof(pcr_selection));
+ chip->active_banks[i] = be16_to_cpu(pcr_selection.hash_alg);
+ marker = marker + sizeof(struct tpm2_pcr_selection);
+ }
+
+out:
+ if (count < ARRAY_SIZE(chip->active_banks))
+ chip->active_banks[count] = 0;
+
+ tpm_buf_destroy(&buf);
+
+ return rc;
+}
--
2.5.0
Re: [PATCH 00/33] Input: Automated coccinelle cleanup
On 01/18/2017 09:06 PM, Joe Perches wrote: On Wed, 2017-01-18 at 21:04 -0800, Guenter Roeck wrote: On 01/18/2017 05:42 PM, Joe Perches wrote: On Wed, 2017-01-18 at 09:46 -0800, Guenter Roeck wrote: The conversion was done automatically with coccinelle using several semantic patches. The semantic patches and the scripts used to generate this commit log are available at https://github.com/groeck/coccinelle-patches. It'd be better to include the script in this 0/n patch so that if github entry changes, the 0/n patch is useful. For this set it would have been possible, though even the rules used here add up to more than 1,000 lines. How many errors do you think are in the script? 1000+ lines, likely there 10+ errors/defects. Most of it is to limit the scope to ensure that there are none, so in this case the argument is a bit self-defeating. Guenter
[PATCH v5 2/2] tpm: enhance TPM 2.0 PCR extend to support multiple banks
The current TPM 2.0 device driver extends only the SHA1 PCR bank
but the TCG Specification[1] recommends extending all active PCR
banks, to prevent malicious users from setting unused PCR banks with
fake measurements and quoting them.
The existing in-kernel interface(tpm_pcr_extend()) expects only a
SHA1 digest. To extend all active PCR banks with differing
digest sizes, the SHA1 digest is padded with trailing 0's as needed.
This patch reuses the defined digest sizes from the crypto subsystem,
adding a dependency on CRYPTO_HASH_INFO module.
[1] TPM 2.0 Specification referred here is "TCG PC Client Specific
Platform Firmware Profile for TPM 2.0"
Signed-off-by: Nayna Jain
Reviewed-by: Jarkko Sakkinen
---
drivers/char/tpm/Kconfig | 1 +
drivers/char/tpm/tpm-interface.c | 15 ++-
drivers/char/tpm/tpm.h | 3 +-
drivers/char/tpm/tpm2-cmd.c | 91 +---
drivers/char/tpm/tpm_eventlog.h | 7
5 files changed, 73 insertions(+), 44 deletions(-)
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 277186d..af985cc 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -6,6 +6,7 @@ menuconfig TCG_TPM
tristate "TPM Hardware Support"
depends on HAS_IOMEM
select SECURITYFS
+ select CRYPTO_HASH_INFO
---help---
If you have a TPM security chip in your system, which
implements the Trusted Computing Group's specification,
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index a3461cb..b032ed5 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -772,13 +772,26 @@ int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8
*hash)
struct tpm_cmd_t cmd;
int rc;
struct tpm_chip *chip;
+ int max_active_banks = ARRAY_SIZE(chip->active_banks);
+ struct tpm2_digest digest_list[max_active_banks];
+ u32 count = 0;
+ int i;
chip = tpm_chip_find_get(chip_num);
if (chip == NULL)
return -ENODEV;
if (chip->flags & TPM_CHIP_FLAG_TPM2) {
- rc = tpm2_pcr_extend(chip, pcr_idx, hash);
+ memset(digest_list, 0, sizeof(digest_list));
+
+ for (i = 0; (chip->active_banks[i] != 0) &&
+(i < max_active_banks); i++) {
+ digest_list[i].alg_id = chip->active_banks[i];
+ memcpy(digest_list[i].digest, hash, TPM_DIGEST_SIZE);
+ count++;
+ }
+
+ rc = tpm2_pcr_extend(chip, pcr_idx, count, digest_list);
tpm_put_ops(chip);
return rc;
}
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 573..f578822 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -533,7 +533,8 @@ static inline void tpm_add_ppi(struct tpm_chip *chip)
#endif
int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf);
-int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash);
+int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, u32 count,
+ struct tpm2_digest *digests);
int tpm2_get_random(struct tpm_chip *chip, u8 *out, size_t max);
int tpm2_seal_trusted(struct tpm_chip *chip,
struct trusted_key_payload *payload,
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 75a7546..7ceebbd 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -53,22 +53,6 @@ struct tpm2_pcr_read_out {
u8 digest[TPM_DIGEST_SIZE];
} __packed;
-struct tpm2_null_auth_area {
- __be32 handle;
- __be16 nonce_size;
- u8 attributes;
- __be16 auth_size;
-} __packed;
-
-struct tpm2_pcr_extend_in {
- __be32 pcr_idx;
- __be32 auth_area_size;
- struct tpm2_null_auth_area auth_area;
- __be32 digest_cnt;
- __be16 hash_alg;
- u8 digest[TPM_DIGEST_SIZE];
-} __packed;
-
struct tpm2_get_tpm_pt_in {
__be32 cap_id;
__be32 property_id;
@@ -97,7 +81,6 @@ union tpm2_cmd_params {
struct tpm2_self_test_in selftest_in;
struct tpm2_pcr_read_inpcrread_in;
struct tpm2_pcr_read_out pcrread_out;
- struct tpm2_pcr_extend_in pcrextend_in;
struct tpm2_get_tpm_pt_in get_tpm_pt_in;
struct tpm2_get_tpm_pt_out get_tpm_pt_out;
struct tpm2_get_random_in getrandom_in;
@@ -290,46 +273,68 @@ int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8
*res_buf)
return rc;
}
-#define TPM2_GET_PCREXTEND_IN_SIZE \
- (sizeof(struct tpm_input_header) + \
-sizeof(struct tpm2_pcr_extend_in))
[PATCH v5 0/2] enhance TPM 2.0 extend function to support multiple PCR banks
IMA extends its hash measurements in the TPM PCRs, based on policy. The existing in-kernel TPM extend function extends only the SHA1 PCR bank. TPM 2.0 defines multiple PCR banks, to support different hash algorithms. The TCG TPM 2.0 Specification[1] recommends extending all active PCR banks to prevent malicious users from setting unused PCR banks with fake measurements and quoting them. This patch set adds support for extending all active PCR banks, as recommended. The first patch implements the TPM 2.0 capability to retrieve the list of active PCR banks. The second patch modifies the tpm_pcr_extend() and tpm2_pcr_extend() interface to support extending multiple PCR banks. The existing tpm_pcr_extend() interface expects only a SHA1 digest. Hence, to extend all active PCR banks with differing digest sizes for TPM 2.0, the SHA1 digest is padded with 0's as needed. [1] TPM 2.0 Specification referred here is "TCG PC Client Specific Platform Firmware Profile for TPM 2.0" Changelog v5: - Patch "tpm: implement TPM 2.0 capability to get active PCR banks" - Included Jarkko's feedbacks - Moved variable declaration to start of function in tpm_pcr_extend() Changelog v4: - Updated cover letter as per Mimi's feedback. - Rebased to Jarkko's latest master branch (4064b6b tpm_tis: use default timeout value if chip reports it as zero) - Patch "tpm: implement TPM 2.0 capability to get active PCR banks" - Included Jarkko's feedbacks - Moved call to tpm2_get_pcr_allocation to Patch 2 - Renamed struct tpm2_tpms_pcr_selection to struct tpm2_pcr_selection and moved the struct to before tpm2_get_pcr_allocation() - Fixed code formatting - Patch "tpm: enchance TPM 2.0 PCR extend to support multiple banks" - Included Jarkkos' feedbacks - Updated commit msg to mention dependency on CRYPTO_HASH_INFO - Renamed struct tpmt_hash to struct tpm2_digest - Removed struct tpml_digest_values, tpm2_pcr_extend() now accepts count and digests list as two separate arguments. Added check for count of hashes passed. - Cleaned up struct tpm2_pcr_extend_in as not required anymore with use of tpm_buf - Moved struct tpm2_null_auth_area just before tpm2_pcr_extend() as it is the only function using it for now. - Fixed code formatting Changelog v3: - Rebased to the Jarkko's latest master branch (8e25809 tpm: Do not print an error message when doing TPM auto startup) - Patch "tpm: implement TPM 2.0 capability to get active PCR banks" - Included Jarkko's feedbacks - Removed getcap_in, getcap_out and used tpm_buf for getting capability. - Used ARRAY_SIZE in place of TPM_MAX_PCR_BANKS and included other feedbacks. - Patch "tpm: enhance TPM 2.0 PCR extend to support multiple banks" - Fixed kbuild errors - Fixed buf.data uninitialized warning. - Added TCG_TPM dependency on CONFIG_CRYPTO_HASH_INFO in Kconfig. Changelog v2: - Patch "tpm: implement TPM 2.0 capability to get active PCR banks" - defined structs definition in tpm2-cmd.c. - no_of_active_banks field is removed. Instead, constant TPM2_MAX_PCR_BANKS is defined. - renamed tpm2_get_active_pcr_banks() to tpm2_get_pcr_allocation() - removed generic function tpm2_get_capability(). - Patch "tpm: enchance TPM 2.0 PCR extend to support multiple banks" - Removed tpm2.h, and defined structs common for extend and event log in tpm_eventlog.h - uses tpm_buf in tpm2_pcr_extend(). Nayna Jain (2): tpm: implement TPM 2.0 capability to get active PCR banks tpm: enhance TPM 2.0 PCR extend to support multiple banks drivers/char/tpm/Kconfig | 1 + drivers/char/tpm/tpm-interface.c | 15 +++- drivers/char/tpm/tpm.h | 7 +- drivers/char/tpm/tpm2-cmd.c | 148 --- drivers/char/tpm/tpm_eventlog.h | 7 ++ 5 files changed, 134 insertions(+), 44 deletions(-) -- 2.5.0
Re: [PATCH v20 16/17] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer
On 2017/1/18 21:25, fu@linaro.org wrote:
From: Fu Wei
The patch add memory-mapped timer register support by using the
information provided by the new GTDT driver of ACPI.
Signed-off-by: Fu Wei
---
drivers/clocksource/arm_arch_timer.c | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 79dc004..7ca2da7 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -1077,10 +1077,36 @@ CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem,
"arm,armv7-timer-mem",
arch_timer_mem_of_init);
#ifdef CONFIG_ACPI_GTDT
-/* Initialize per-processor generic timer */
+static int __init arch_timer_mem_acpi_init(int platform_timer_count)
+{
+ struct arch_timer_mem *timer_mem;
+ int timer_count, i, ret;
+
if (!platform_timer_count)
return 0;
Did I miss something?
Thanks
Hanjun
+ timer_mem = kcalloc(platform_timer_count, sizeof(*timer_mem),
+ GFP_KERNEL);
+ if (!timer_mem)
+ return -ENOMEM;
+
+ ret = acpi_arch_timer_mem_init(timer_mem, &timer_count);
+ if (ret || !timer_count)
+ goto error;
+
+ for (i = 0; i < timer_count; i++) {
+ ret = arch_timer_mem_init(timer_mem);
+ if (!ret)
+ break;
+ timer_mem++;
+ }
+
+error:
+ kfree(timer_mem);
+ return ret;
+}
+
+/* Initialize per-processor generic timer and memory-mapped timer(if present)
*/
static int __init arch_timer_acpi_init(struct acpi_table_header *table)
{
- int ret;
+ int ret, platform_timer_count;
if (arch_timers_present & ARCH_TIMER_TYPE_CP15) {
pr_warn("already initialized, skipping\n");
@@ -1089,7 +1115,7 @@ static int __init arch_timer_acpi_init(struct
acpi_table_header *table)
arch_timers_present |= ARCH_TIMER_TYPE_CP15;
- ret = acpi_gtdt_init(table, NULL);
+ ret = acpi_gtdt_init(table, &platform_timer_count);
if (ret) {
pr_err("Failed to init GTDT table.\n");
return ret;
@@ -1122,6 +1148,9 @@ static int __init arch_timer_acpi_init(struct
acpi_table_header *table)
if (ret)
return ret;
+ if (arch_timer_mem_acpi_init(platform_timer_count))
+ pr_err("Failed to initialize memory-mapped timer.\n");
+
return arch_timer_common_init();
}
CLOCKSOURCE_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
Re: [PATCH v8 4/8] PWM: add PWM driver for STM32 plaftorm
On Wed, Jan 18, 2017 at 03:20:47PM +0100, Benjamin Gaignard wrote:
> This driver adds support for PWM driver on STM32 platform.
> The SoC have multiple instances of the hardware IP and each
> of them could have small differences: number of channels,
> complementary output, auto reload register size...
>
> version 8:
> - fix comments done by Thierry on version 7
>
> version 6:
> - change st,breakinput parameter to make it usuable for stm32f7 too.
>
> version 4:
> - detect at probe time hardware capabilities
> - fix comments done on v2 and v3
> - use PWM atomic ops
>
> version 2:
> - only keep one comptatible
> - use DT parameters to discover hardware block configuration
>
> Signed-off-by: Benjamin Gaignard
> ---
> drivers/pwm/Kconfig | 9 ++
> drivers/pwm/Makefile| 1 +
> drivers/pwm/pwm-stm32.c | 398
>
> 3 files changed, 408 insertions(+)
> create mode 100644 drivers/pwm/pwm-stm32.c
Similar nit than for 3/8. The canonical prefix for PWM subsystem patches
is "pwm: ". One other thing that I had missed earlier...
> +MODULE_ALIAS("platform: stm32-pwm");
I don't think there should be a space after ':'.
With those two fixed:
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
Re: [PATCH v2 02/26] treewide: Move dma_ops from struct dev_archdata into struct device
On Thu, Jan 12, 2017 at 11:06:54AM -0800, Bart Van Assche wrote: > Some but not all architectures provide set_dma_ops(). Move dma_ops > from struct dev_archdata into struct device such that it becomes > possible on all architectures to configure dma_ops per device. > > Signed-off-by: Bart Van Assche > Cc: Benjamin Herrenschmidt > Cc: Boris Ostrovsky > Cc: David Woodhouse > Cc: Juergen Gross > Cc: H. Peter Anvin > Cc: Ingo Molnar > Cc: linux-a...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: Russell King > Cc: x...@kernel.org Acked-by: Greg Kroah-Hartman
Re: [PATCH v4 2/2] tpm: enhance TPM 2.0 PCR extend to support multiple banks
On 01/18/2017 07:28 PM, Jarkko Sakkinen wrote:
On Wed, Jan 18, 2017 at 03:44:50AM -0500, Nayna Jain wrote:
The current TPM 2.0 device driver extends only the SHA1 PCR bank
but the TCG Specification[1] recommends extending all active PCR
banks, to prevent malicious users from setting unused PCR banks with
fake measurements and quoting them.
The existing in-kernel interface(tpm_pcr_extend()) expects only a
SHA1 digest. To extend all active PCR banks with differing
digest sizes, the SHA1 digest is padded with trailing 0's as needed.
This patch reuses the defined digest sizes from the crypto subsystem,
adding a dependency on CRYPTO_HASH_INFO module.
[1] TPM 2.0 Specification referred here is "TCG PC Client Specific
Platform Firmware Profile for TPM 2.0"
Signed-off-by: Nayna Jain
---
drivers/char/tpm/Kconfig | 1 +
drivers/char/tpm/tpm-interface.c | 15 ++-
drivers/char/tpm/tpm.h | 3 +-
drivers/char/tpm/tpm2-cmd.c | 91 +---
drivers/char/tpm/tpm_eventlog.h | 7
5 files changed, 73 insertions(+), 44 deletions(-)
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 277186d..af985cc 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -6,6 +6,7 @@ menuconfig TCG_TPM
tristate "TPM Hardware Support"
depends on HAS_IOMEM
select SECURITYFS
+ select CRYPTO_HASH_INFO
---help---
If you have a TPM security chip in your system, which
implements the Trusted Computing Group's specification,
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index a3461cb..00612dd 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -770,6 +770,7 @@ static const struct tpm_input_header pcrextend_header = {
int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8 *hash)
{
struct tpm_cmd_t cmd;
+ int i;
int rc;
struct tpm_chip *chip;
@@ -778,7 +779,19 @@ int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8
*hash)
return -ENODEV;
if (chip->flags & TPM_CHIP_FLAG_TPM2) {
- rc = tpm2_pcr_extend(chip, pcr_idx, hash);
+ struct tpm2_digest digest_list[ARRAY_SIZE(chip->active_banks)];
+ u32 count = 0;
Declare variables in the beginning.
Done, posted new version with this change.
+
+ memset(digest_list, 0, sizeof(digest_list));
+
+ for (i = 0; (chip->active_banks[i] != 0) &&
+(i < ARRAY_SIZE(chip->active_banks)); i++) {
+ digest_list[i].alg_id = chip->active_banks[i];
+ memcpy(digest_list[i].digest, hash, TPM_DIGEST_SIZE);
+ count++;
+ }
+
+ rc = tpm2_pcr_extend(chip, pcr_idx, count, digest_list);
tpm_put_ops(chip);
return rc;
}
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 573..f578822 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -533,7 +533,8 @@ static inline void tpm_add_ppi(struct tpm_chip *chip)
#endif
int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf);
-int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash);
+int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, u32 count,
+ struct tpm2_digest *digests);
int tpm2_get_random(struct tpm_chip *chip, u8 *out, size_t max);
int tpm2_seal_trusted(struct tpm_chip *chip,
struct trusted_key_payload *payload,
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 75a7546..7ceebbd 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -53,22 +53,6 @@ struct tpm2_pcr_read_out {
u8 digest[TPM_DIGEST_SIZE];
} __packed;
-struct tpm2_null_auth_area {
- __be32 handle;
- __be16 nonce_size;
- u8 attributes;
- __be16 auth_size;
-} __packed;
-
-struct tpm2_pcr_extend_in {
- __be32 pcr_idx;
- __be32 auth_area_size;
- struct tpm2_null_auth_area auth_area;
- __be32 digest_cnt;
- __be16 hash_alg;
- u8 digest[TPM_DIGEST_SIZE];
-} __packed;
-
struct tpm2_get_tpm_pt_in {
__be32 cap_id;
__be32 property_id;
@@ -97,7 +81,6 @@ union tpm2_cmd_params {
struct tpm2_self_test_in selftest_in;
struct tpm2_pcr_read_inpcrread_in;
struct tpm2_pcr_read_out pcrread_out;
- struct tpm2_pcr_extend_in pcrextend_in;
struct tpm2_get_tpm_pt_in get_tpm_pt_in;
struct tpm2_get_tpm_pt_out get_tpm_pt_out;
struct tpm2_get_random_in getrandom_in;
@@ -2
Re: [PATCH] ARM: Exynos4415: remove dead build rule
On Thu, Jan 19, 2017 at 11:11 AM, Valentin Rothberg
wrote:
> Commit 22dfab102cfa ("ARM: EXYNOS: Remove Exynos4415 arch code (SoC not
> supported anymore)") removed the Kconfig option SOC_EXYNOS4415. Thus,
> we are safe to remove the last reference in the Makefile.
>
> Signed-off-by: Valentin Rothberg
> ---
> Detected by using ./scripts/checkkconfigsymbols.py
>
> drivers/clk/samsung/Makefile | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index 57f4dc6dc447..7afc21dc374e 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -5,7 +5,6 @@
> obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
> obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
> -obj-$(CONFIG_SOC_EXYNOS4415) += clk-exynos4415.o
It is already removed. Which tree are you using?
Best regards,
Krzysztof
Re: [PATCH] ARM: Exynos4415: remove dead build rule
On Thu, Jan 19, 2017 at 11:18 AM, Krzysztof Kozlowski wrote:
> On Thu, Jan 19, 2017 at 11:11 AM, Valentin Rothberg
> wrote:
>> Commit 22dfab102cfa ("ARM: EXYNOS: Remove Exynos4415 arch code (SoC not
>> supported anymore)") removed the Kconfig option SOC_EXYNOS4415. Thus,
>> we are safe to remove the last reference in the Makefile.
>>
>> Signed-off-by: Valentin Rothberg
>> ---
>> Detected by using ./scripts/checkkconfigsymbols.py
>>
>> drivers/clk/samsung/Makefile | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
>> index 57f4dc6dc447..7afc21dc374e 100644
>> --- a/drivers/clk/samsung/Makefile
>> +++ b/drivers/clk/samsung/Makefile
>> @@ -5,7 +5,6 @@
>> obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
>> obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
>> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
>> -obj-$(CONFIG_SOC_EXYNOS4415) += clk-exynos4415.o
>
> It is already removed. Which tree are you using?
BTW, please fix your own mail/name etc in from and Signed-off-by. One
of them is wrong and bounces.
Best regards,
Krzysztof
Re: [PATCH] ARM: Exynos4415: remove dead build rule
Hi,
On 2017년 01월 19일 18:11, Valentin Rothberg wrote:
> Commit 22dfab102cfa ("ARM: EXYNOS: Remove Exynos4415 arch code (SoC not
> supported anymore)") removed the Kconfig option SOC_EXYNOS4415. Thus,
> we are safe to remove the last reference in the Makefile.
>
> Signed-off-by: Valentin Rothberg
> ---
> Detected by using ./scripts/checkkconfigsymbols.py
>
> drivers/clk/samsung/Makefile | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index 57f4dc6dc447..7afc21dc374e 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -5,7 +5,6 @@
> obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
> obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
> -obj-$(CONFIG_SOC_EXYNOS4415) += clk-exynos4415.o
> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
> obj-$(CONFIG_SOC_EXYNOS5260) += clk-exynos5260.o
> obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
S/W Center, Samsung Electronics
Re: kvm: use-after-free in process_srcu
On 18/01/2017 23:15, Paul E. McKenney wrote: > On Wed, Jan 18, 2017 at 09:53:19AM +0100, Paolo Bonzini wrote: >> >> >> On 17/01/2017 21:34, Paul E. McKenney wrote: >>> Do any of your callback functions invoke call_srcu()? (Hey, I have to ask!) >> >> No, we only use synchronize_srcu and synchronize_srcu_expedited, so our >> only callback comes from there. > > OK, so the next question is whether your code makes sure that all of its > synchronize_srcu() and synchronize_srcu_expedited() calls return before > the call to cleanup_srcu_struct(). It certainly should! Or at least that would be our bug. > You should only need srcu_barrier() if there were calls to call_srcu(). > Given that you only have synchronize_srcu() and synchronize_srcu_expedited(), > you -don't- need srcu_barrier(). What you need instead is to make sure > that all synchronize_srcu() and synchronize_srcu_expedited() have > returned before the call to cleanup_srcu_struct(). Ok, good. >> If this is incorrect, then one flush_delayed_work is enough. If it is >> correct, the possible alternatives are: >> >> * srcu_barrier in the caller, flush_delayed_work+WARN_ON(sp->running) in >> cleanup_srcu_struct. I strongly dislike this one---because we don't use >> call_srcu at all, there should be no reason to use srcu_barrier in KVM >> code. Plus I think all other users have the same issue. >> >> * srcu_barrier+flush_delayed_work+WARN_ON(sp->running) in >> cleanup_srcu_struct >> >> * flush_delayed_work+flush_delayed_work+WARN_ON(sp->running) in >> cleanup_srcu_struct >> >> * while(flush_delayed_work) in cleanup_srcu_struct >> >> * "while(sp->running) flush_delayed_work" in cleanup_srcu_struct > > My current thought is flush_delayed_work() followed by a warning if > there are any callbacks still posted, and also as you say sp->running. Yes, that would work for KVM and anyone else who doesn't use call_srcu (and order synchronize_srcu correctly against destruction). On the other hand, users of call_srcu, such as rcutorture, _do_ need to place an srcu_barrier before cleanup_srcu_struct, or they need two flush_delayed_work() calls back to back in cleanup_srcu_struct. Do you agree? Thanks, Paolo
Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
On Thu, Jan 19, 2017 at 10:17:45AM +0200, Laurent Pinchart wrote: > Hi Peter, > > On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote: > > On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote: > > > On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote: > > >> On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote: > > >>> On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote: > > On 04 January, 2017 21:39 CET, Rob Herring wrote: > > > On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote: > > >> On 03 January, 2017 23:51 CET, Rob Herring wrote: > > >>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin > wrote: > > Devicetree bindings documentation for the GE B850v3 LVDS/DP++ > > display bridge. > > > > Cc: Martyn Welch > > Cc: Martin Donnelly > > Cc: Javier Martinez Canillas > > Cc: Enric Balletbo i Serra > > Cc: Philipp Zabel > > Cc: Rob Herring > > Cc: Fabio Estevam > > Signed-off-by: Peter Senna Tschudin > > --- > > There was an Acked-by from Rob Herring for V6, > > but I changed the bindings to use i2c_new_secondary_device() so I > > removed it from the commit message. > > > > [...] > > > > .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 + > > >>> > > >>> Isn't '-lvds-dp' redundant? The part# should be enough. > > >> > > >> b850v3 is the name of the product, this is why the proposed name. > > >> What about, b850v3-dp2 dp2 indicating the second DP output? > > > > > > Humm, b850v3 is the board name? This node should be the name of the > > > bridge chip. > > > > From the cover letter: > > > > -- // -- > > There are two physical bridges on the video signal pipeline: a > > STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and > > firmware made it complicated for this binding to comprise two device > > tree nodes, as the design goal is to configure both bridges based on > > the LVDS signal, which leave the driver powerless to control the > > video processing pipeline. The two bridges behaves as a single bridge, > > and the driver is only needed for telling the host about EDID / HPD, > > and for giving the host powers to ack interrupts. The video signal > > pipeline > > > > is as follows: > > Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video > > output > > > > -- // -- > > >>> > > >>> You forgot to prefix your patch series with [HACK] ;-) > > >>> > > >>> How about fixing the issues that make the two DT nodes solution > > >>> difficult ? What are they ? > > >> > > >> The Firmware and the hardware design. Both bridges, with stock firmware, > > >> are fully capable of providig EDID information and handling interrupts. > > >> But on this specific design, with this specific firmware, I need to read > > >> EDID from one bridge, and handle interrupts on the other. > > > > > > Which firmware are you talking about ? Firmware running on the bridges, or > > > somewhere else ? > > > > Each bridge has it's own external flash containing a binary firmware. > > The goal of the firmware is to configure the output end based on the > > input end. This is part of what makes handling EDID and HPD challenging. > > > > >> Back when I was starting the development I could not come up with a > > >> proper way to split EDID and interrupts between two bridges in a way > > >> that would result in a fully functional connector. Did I miss something? > > > > > > You didn't, we did :-) I've been telling for quite some time now that we > > > must decouple bridges from connectors, and this is another example of why > > > we have such a need. Bridges should expose additional functions needed to > > > implement connector operations, and the connector should be instantiated > > > by the display driver with the help of bridge operations. You could then > > > create a connector that relies on one bridge to read the EDID and on the > > > other bridge to handle HPD. > > > > Ah thanks. So for now the single DT node approach is acceptable, right? > > The problem is that even if the driver is getting better on each > > iteration, the single DT node for two chips issue comes back often and I > > believe is _the_ issue preventing the driver from getting upstream. V1 > > was sent ~ 8 months ago... > > > > Can I have some blessing on the single DT node approach for now? > > With the "DT as an ABI" approach, I'm afraid not. Temporary hacks are > acceptable on the driver side, but you need two nodes in DT. So can I make two node DT "in the right way" and work around current connectors vs. bridge limitations on the driver side? This seems to be doable. Then I could fix bridge API, with my own driver and update API clients affected by th
Re: [PATCH v20 00/17] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
Hi Fuwei, On 2017/1/18 21:25, fu@linaro.org wrote: From: Fu Wei This patchset: (1)Preparation for adding GTDT support in arm_arch_timer: 1. Clean up printk() usage 2. Rename the type macros 3. Rename the PPI enum & enum values 4. Move the type macro and PPI enum into the header file 5. Add new enum for SPIs 6. Rework PPI determination; 7. Rework counter frequency detection; 8. Refactor arch_timer_needs_probing, move it into DT init call 9. Introduce some new structs and refactor the MMIO timer init code for reusing some common code. (2)Introduce ACPI GTDT parser: drivers/acpi/arm64/acpi_gtdt.c Parse all kinds of timer in GTDT table of ACPI:arch timer, memory-mapped timer and SBSA Generic Watchdog timer. This driver can help to simplify all the relevant timer drivers, and separate all the ACPI GTDT knowledge from them. (3)Simplify ACPI code for arm_arch_timer (4)Add GTDT support for ARM memory-mapped timer. This patchset has been tested on the following platforms with ACPI enabled: (1)ARM Foundation v8 model Changelog: v20: https://lkml.org/lkml/2017/1/18/ Reorder the first 4 patches and split the 4th patches. Leave CNTHCTL_* as they originally were. Fix the bug in arch_timer_select_ppi. Split "Rework counter frequency detection" patch. Rework the arch_timer_detect_rate function. Improve the commit message of "Refactor MMIO timer probing". Rebase to 4.10.0-rc4 Other than some minor comments I raised, the patch set looks fine to me, and I tested this patch set on D03, the percpu arch timer works fine as before. With the comments fixed, Reviewed-by: Hanjun Guo Tested-by: Hanjun Guo Thanks Hanjun
Re: [PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration
On Wed, Jan 18, 2017 at 01:58:28PM +0200, Mathias Nyman wrote: > On 12.01.2017 10:38, Roger Quadros wrote: > > Mathias, > > > > On 11/01/17 17:08, Alan Stern wrote: > > > On Wed, 11 Jan 2017, Mathias Nyman wrote: > > > > > > > On 17.11.2016 13:43, Sriram Dash wrote: > > > > > From: Arnd Bergmann > > > > > > > > > > For xhci-hcd platform device, all the DMA parameters are not > > > > > configured properly, notably dma ops for dwc3 devices. So, set > > > > > the dma for xhci from sysdev. sysdev is pointing to device that > > > > > is known to the system firmware or hardware. > > > > > > > > > > Signed-off-by: Arnd Bergmann > > > > > Signed-off-by: Sriram Dash > > > > > Tested-by: Baolin Wang > > > > > --- > > > > > > > > ... > > > > > > > > > + /* > > > > > + * sysdev must point to a device that is known to the system > > > > > firmware > > > > > + * or PCI hardware. We handle these three cases here: > > > > > + * 1. xhci_plat comes from firmware > > > > > + * 2. xhci_plat is child of a device from firmware (dwc3-plat) > > > > > + * 3. xhci_plat is grandchild of a pci device (dwc3-pci) > > > > > + */ > > > > > + sysdev = &pdev->dev; > > > > > + if (sysdev->parent && !sysdev->of_node && > > > > > sysdev->parent->of_node) > > > > > + sysdev = sysdev->parent; > > > > > +#ifdef CONFIG_PCI > > > > > + else if (sysdev->parent && sysdev->parent->parent && > > > > > + sysdev->parent->parent->bus == &pci_bus_type) > > > > > + sysdev = sysdev->parent->parent; > > > > > +#endif > > > > > + > > > > > > > > Not maybe the the ideal situation here, and looks really tailored to > > > > make PCI dwc3 > > > > controllers with xhci support work. > > > > > > > > Was there some reason child devices can't automatically inherit the dma > > > > mask from the parents, > > > > forcing us to dig it from grandparents? > > > > > > > > Anyway, looks like the dwc3 part is already in 4.10-rc, > > > > If Greg and Alan want to take this series that's fine by me > > > > > > I have no objections. > > > > > > Alan Stern > > > > > > > I haven't tested that it won't break anything on PCI XHCI controllers > > > > though > > > > > > > > -Mathias > > > > Are you going to pick all the remaining patches from this series (i.e. 1 to > > 4)? > > > > That should fix the warning that people are seeing on v4.10-rc. > > > > Let's check with Greg > > Greg, 5/6 and 6/6 are in 4.10-rc already, causing additional warnings for > people using dwc3 xhci. > > First 3 patches change usb core, patch 4 xhci. > > Compiles and boots, doesn't break pci xhci (non-dwc3) functionality > > Would you like me to send first 4 patches for usb-linus to get a clean final > 4.10 > without warnings, or to send them for usb-next? > > Or will you just pick the patches from here directly. I don't have them "here" anymore, they are long-gone from my patch queue, sorry. Can you resend them, I don't know what these patches contained, but if they fix an 4.10 issue, that would be good to have there, right? thanks, greg k-h
Re: [PATCH] ARM: Exynos4415: remove dead build rule
On Thu, Jan 19, 2017 at 11:25 AM, Valentin Rothberg
wrote:
> Hi Krzysztof,
>
> On 19/01/2017 10:20, Krzysztof Kozlowski wrote:
>> On Thu, Jan 19, 2017 at 11:18 AM, Krzysztof Kozlowski
>> wrote:
>>> On Thu, Jan 19, 2017 at 11:11 AM, Valentin Rothberg
>>> wrote:
Commit 22dfab102cfa ("ARM: EXYNOS: Remove Exynos4415 arch code (SoC not
supported anymore)") removed the Kconfig option SOC_EXYNOS4415. Thus,
we are safe to remove the last reference in the Makefile.
Signed-off-by: Valentin Rothberg
---
Detected by using ./scripts/checkkconfigsymbols.py
drivers/clk/samsung/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 57f4dc6dc447..7afc21dc374e 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -5,7 +5,6 @@
obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
-obj-$(CONFIG_SOC_EXYNOS4415) += clk-exynos4415.o
>>>
>>> It is already removed. Which tree are you using?
>
> I'm on today's linux-next. Please excuse the noise, I did not see your
> other patch on lkml.
Sylwester,
Is your tree included in linux-next? I see my patch here:
https://git.linuxtv.org/snawrocki/samsung.git/log/?h=for-v4.11/clk/next
so maybe something in linux-next is missing?
Best regards,
Krzysztof
Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration
> That said, I have the feeling that is taking the wrong direction. Each time we
> are entering idle, we check the latencies. Entering idle can be done thousand
> of times per second. Wouldn't make sense to disable the states not fulfilling
> the constraints at the moment the latencies are changed ? As the idle states
> have increasing exit latencies, setting an idle state limit to disable all
> states after that limit may be more efficient than checking again and again in
> the idle path, no ?
You'r right. save some checking is good thing to do.
>From 9e1cc3e02b8d954e606dd5a0f6466a8d5b3efab7 Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Wed, 26 Oct 2016 15:26:22 +0800
Subject: [PATCH 2/2] cpuidle/menu: add per cpu pm_qos_resume_latency
consideration
Kernel or user may have special requirement on cpu response time, like
if a interrupt is pinned to a cpu, we don't want the cpu goes too deep
sleep. This patch can prevent this thing happen by consider per cpu
resume_latency setting in cpu sleep state selection in menu governor.
The pm_qos_resume_latency ask device to give reponse in this time. That's
similar with cpu cstates' entry_latency + exit_latency. But since
most of cpu cstate either has no entry_latency or add it into exit_latency
So, we just can restrict this time requirement as states exit_latency.
We can set a wanted latency value according to the value of
/sys/devices/system/cpu/cpuX/cpuidle/stateX/latency. to just a bit
less than related state's latency value. Then cpu can get to this state
or higher.
Signed-off-by: Alex Shi
Acked-by: Rik van Riel
To: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: Ulf Hansson
Cc: Daniel Lezcano
Cc: Rasmus Villemoes
Cc: Arjan van de Ven
Cc: Rik van Riel
Cc: "Rafael J. Wysocki"
---
drivers/base/cpu.c | 2 ++
drivers/cpuidle/governors/menu.c | 10 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 4c28e1a..2c3b359 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include "base.h"
@@ -376,6 +377,7 @@ int register_cpu(struct cpu *cpu, int num)
per_cpu(cpu_sys_devices, num) = &cpu->dev;
register_cpu_under_node(num, cpu_to_node(num));
+ dev_pm_qos_expose_latency_limit(&cpu->dev, 0);
return 0;
}
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 07e36bb..cc7d873 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/*
* Please note when changing the tuning values:
@@ -280,11 +281,13 @@ static unsigned int get_typical_interval(struct
menu_device *data)
static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
{
struct menu_device *data = this_cpu_ptr(&menu_devices);
+ struct device *device;
int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
int i;
unsigned int interactivity_req;
unsigned int expected_interval;
unsigned long nr_iowaiters, cpu_load;
+ int resume_latency;
if (data->needs_update) {
menu_update(drv, dev);
@@ -295,6 +298,13 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
if (unlikely(latency_req == 0))
return 0;
+ device = get_cpu_device(dev->cpu);
+
+ /* resume_latency is 0 means no restriction */
+ resume_latency = dev_pm_qos_read_value(device);
+ if (resume_latency)
+ latency_req = min(latency_req, resume_latency);
+
/* determine the expected residency time, round up */
data->next_timer_us = ktime_to_us(tick_nohz_get_sleep_length());
--
2.8.1.101.g72d917a
>
> For example, a zero PM_QOS_CPU_DMA_LATENCY latency should prevent to enter the
> select's idle routine.
That's a good idea. I will give a draft change to review! :)
Re: [PATCH] ARM: Exynos4415: remove dead build rule
Dear all,
On 2017년 01월 19일 18:14, Chanwoo Choi wrote:
> Hi,
>
> On 2017년 01월 19일 18:11, Valentin Rothberg wrote:
>> Commit 22dfab102cfa ("ARM: EXYNOS: Remove Exynos4415 arch code (SoC not
>> supported anymore)") removed the Kconfig option SOC_EXYNOS4415. Thus,
>> we are safe to remove the last reference in the Makefile.
>>
>> Signed-off-by: Valentin Rothberg
>> ---
>> Detected by using ./scripts/checkkconfigsymbols.py
>>
>> drivers/clk/samsung/Makefile | 1 -
>> 1 file changed, 1 deletion(-)
Please ignore this reply. Krzysztof's patch[1] already
removed the entry of clk-exynos4415.c.
[1] https://www.spinics.net/lists/arm-kernel/msg554369.html
--
Best Regards,
Chanwoo Choi
S/W R&D Center
Samsung Electronics
Re: [PATCH] procfs: change the owner of non-dumpable and writeable files
Cc Eric
On Wed 18-01-17 15:01:59, Aleksa Sarai wrote:
> In order to protect against ptrace(2) and similar attacks on container
> runtimes when they join namespaces, many runtimes set mm->dumpable to
> SUID_DUMP_DISABLE. However, doing this means that attempting to set up
> an unprivileged user namespace will fail because an unprivileged process
> can no longer access /proc/self/{setgroups,{uid,gid}_map} for the
> container process (which is the same uid as the runtime process).
>
> Fix this by changing pid_getattr to *also* change the owner of regular
> files that have a mode of 0644 (when the process is not dumpable). This
> ensures that the important /proc/[pid]/... files mentioned above are
> properly accessible by a container runtime in a rootless container
> context.
>
> The most blantant issue is that a non-dumpable process in a rootless
> container context is unable to open /proc/self/setgroups, because it
> doesn't own the file.
>
> int main(void)
> {
> prctl(PR_SET_DUMPABLE, 0, 0, 0, 0);
> unshare(CLONE_NEWUSER);
>
> /* This will fail. */
> int fd = open("/proc/self/setgroups", O_WRONLY);
> if (fd < 0)
> abort();
>
> return 0;
> }
I do agree that failing to open anything in /proc/self/ is more than
unexepcted! I cannot judge the patch but my gut feeling tells me that
the fix should be somewhere in the open handler.
One nit below
>
> Cc: d...@opencontainers.org
> Cc: contain...@lists.linux-foundation.org
> Signed-off-by: Aleksa Sarai
> ---
> fs/proc/base.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index ca651ac00660..ebabb12f4536 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1729,6 +1729,7 @@ int pid_getattr(struct vfsmount *mnt, struct dentry
> *dentry, struct kstat *stat)
> return -ENOENT;
> }
> if ((inode->i_mode == (S_IFDIR|S_IRUGO|S_IXUGO)) ||
> + (inode->i_mode == (S_IFREG|S_IRUGO|S_IWUSR)) ||
> task_dumpable(task)) {
> cred = __task_cred(task);
> stat->uid = cred->euid;
> @@ -1770,6 +1771,7 @@ int pid_revalidate(struct dentry *dentry, unsigned int
> flags)
>
> if (task) {
> if ((inode->i_mode == (S_IFDIR|S_IRUGO|S_IXUGO)) ||
> + (inode->i_mode == (S_IFREG|S_IRUGO|S_IWUSR)) ||
> task_dumpable(task)) {
> rcu_read_lock();
> cred = __task_cred(task);
> @@ -2394,7 +2396,7 @@ static int proc_pident_instantiate(struct inode *dir,
> return -ENOENT;
> }
>
> -static struct dentry *proc_pident_lookup(struct inode *dir,
> +static struct dentry *proc_pident_lookup(struct inode *dir,
>struct dentry *dentry,
>const struct pid_entry *ents,
>unsigned int nents)
> @@ -2536,7 +2538,7 @@ static const struct pid_entry attr_dir_stuff[] = {
>
> static int proc_attr_dir_readdir(struct file *file, struct dir_context *ctx)
> {
> - return proc_pident_readdir(file, ctx,
> + return proc_pident_readdir(file, ctx,
> attr_dir_stuff, ARRAY_SIZE(attr_dir_stuff));
> }
this two are just whitespace noise
--
Michal Hocko
SUSE Labs
[PATCH] VME: add again remove entry point
Commit 050c3d52cc7 dropped the remove
entry point. However, vme_bus_remove()
is called when a VME device is removed
from the bus and not when the bus is removed
and it calls the VME device driver's cleanup
function.
Without this function, the remove() in VME
device driver is never called and VME device
drivers cannot be reloaded again.
Signed-off-by: Stefano Babic
---
drivers/vme/vme.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/vme/vme.c b/drivers/vme/vme.c
index d078fad..ae35d7b 100644
--- a/drivers/vme/vme.c
+++ b/drivers/vme/vme.c
@@ -1737,10 +1737,25 @@ static int vme_bus_probe(struct device *dev)
return retval;
}
+static int vme_bus_remove(struct device *dev)
+{
+ int retval = -ENODEV;
+ struct vme_driver *driver;
+ struct vme_dev *vdev = dev_to_vme_dev(dev);
+
+ driver = dev->platform_data;
+
+ if (driver->remove != NULL)
+ retval = driver->remove(vdev);
+
+ return retval;
+}
+
struct bus_type vme_bus_type = {
.name = "vme",
.match = vme_bus_match,
.probe = vme_bus_probe,
+ .remove = vme_bus_remove,
};
EXPORT_SYMBOL(vme_bus_type);
--
2.7.4
Re: [PATCH v3] EDAC: expose per-dimm error counts in sysfs
On Thu, Jan 19, 2017 at 08:56:23AM +, Aaron Miller wrote: > Did this ever get picked up? It is now. Thanks for the reminder! -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v4 3/3] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs
On 19 January 2017 at 00:15, Linus Torvalds wrote: > On Wed, Jan 18, 2017 at 2:37 PM, Ard Biesheuvel > wrote: >> >> For a ballpark number of 10,000 CRCs in the core kernel, this would >> increase the size of the image by 40 KB for 32-bit architectures (and >> if saving 40 KB is essential, chances are you won't be using >> modversions in the first place). > > As you say, I don't think the space issue is much of a problem. > > I'm more worried about the replacement of one crazy model that has > problems due to linker subtlety with _another_ one. > > Your genksyms.c change is not exactly obvious. I looked at it, and my > brain just shut down. Why both the > > LONG(0x%08lx); > > _and_ the > > "%s__crc_%s = 0x%08lx;\n" > > in the linker script? I'm sure there's a good reason, but I'd like to > see a more explicit explanation fo what the generated linker script > does and what the rules are. > This is simply because modpost still uses the value of the symbol rather than the value it points to to generate the /other/ side of the comparison (i.e., Module.symvers etc) I will look into updating modpost to dereference the symbol as well, and update the RFC patch accordingly.
[PATCH] net/mlx5e: Remove unused variable
A cleanup removed the only user of this variable
mlx5/core/en_ethtool.c: In function 'mlx5e_set_channels':
mlx5/core/en_ethtool.c:546:6: error: unused variable 'ncv'
[-Werror=unused-variable]
Let's remove the declaration as well.
Fixes: 639e9e94160e ("net/mlx5e: Remove unnecessary checks when setting num
channels")
Signed-off-by: Arnd Bergmann
---
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index b1b9eb6ee135..5197817e4b2f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -543,7 +543,6 @@ static int mlx5e_set_channels(struct net_device *dev,
struct ethtool_channels *ch)
{
struct mlx5e_priv *priv = netdev_priv(dev);
- int ncv = mlx5e_get_max_num_channels(priv->mdev);
unsigned int count = ch->combined_count;
bool arfs_enabled;
bool was_opened;
--
2.9.0
Re: [PATCH] ARM: Exynos4415: remove dead build rule
Hi Krzysztof,
On 19/01/2017 10:20, Krzysztof Kozlowski wrote:
> On Thu, Jan 19, 2017 at 11:18 AM, Krzysztof Kozlowski wrote:
>> On Thu, Jan 19, 2017 at 11:11 AM, Valentin Rothberg
>> wrote:
>>> Commit 22dfab102cfa ("ARM: EXYNOS: Remove Exynos4415 arch code (SoC not
>>> supported anymore)") removed the Kconfig option SOC_EXYNOS4415. Thus,
>>> we are safe to remove the last reference in the Makefile.
>>>
>>> Signed-off-by: Valentin Rothberg
>>> ---
>>> Detected by using ./scripts/checkkconfigsymbols.py
>>>
>>> drivers/clk/samsung/Makefile | 1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
>>> index 57f4dc6dc447..7afc21dc374e 100644
>>> --- a/drivers/clk/samsung/Makefile
>>> +++ b/drivers/clk/samsung/Makefile
>>> @@ -5,7 +5,6 @@
>>> obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
>>> obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
>>> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
>>> -obj-$(CONFIG_SOC_EXYNOS4415) += clk-exynos4415.o
>>
>> It is already removed. Which tree are you using?
I'm on today's linux-next. Please excuse the noise, I did not see your
other patch on lkml.
> BTW, please fix your own mail/name etc in from and Signed-off-by. One
> of them is wrong and bounces.
Thanks for the hint.
Kind regards,
Valentin
Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC
On Wed, Jan 18, 2017 at 10:44 AM, Andre Przywara wrote: > Any future SoCs could then just use that compatible and would describe > the SoC details in the DT, like it's meant to be and like we do already, > but extended by putting the mux value in there as well. > So the only kernel contribution would then be the DT, really, (...) Your different positions have existed since the inception of the pinctrl subsystem: - One camp (myself included) wanted to describe the hardware mostly in the driver: functions, groups etc are tables in the driver file. - Another camp (OMAP included) think that the device tree should take store most things: groups functions, etc. What we know for sure should be described in DT is how different IP blocks are connected in an SoC (e.g. interrupts, clocks, DMA channels, regulators) and on the of course outside of the SoC, on the board. The question here is whether the way a hardware has instantiated a certain IP block when doing physical compilation in their Verilog, VHDL or SystemC files, is something that should be described in DT. Many companies have developed tools to extract this data from their hardware design files and provide it to developers as a blob och incomprehensible data, such was the situation for OMAP for example. So to them it made most sense to implement pinctrl-single, just parsing that data into DTS(I) files. Other companies (such as STMicroelectronics) instead put a team of people to write a datasheet with a special chapter on how pins etc are connected, and programmers are given this datasheet and need to again type in the data and define groups etc. Whether parametrization of a HW block should be done in the driver file from the compatible string or with custom attributes in the node is not a simple answer to the question. OF is vague on this kind of things: both solutions exist. Allwinner and Qualcomm authors faced a situation such as that they were given a code dump and no datasheet and no data tables either. That creates an especially complicated situation where none of the above scenarios apply. What we/you need to ask: what is most helpful for the Allwinner community? What makes the barrier low for new contributions, and makes it easiest to cooperate? I try to live by this motto from IETF: "rough consensus and running code" Please do the same. Yours, Linus Walleij
Re: [PATCH] tools: usb usbip - update README USB/IP driver location
On Fri, Jan 13, 2017 at 04:38:32PM -0700, Shuah Khan wrote: > Update USB/IP driver location in README. > > Signed-off-by: Shuah Khan > Reviewed-by: Krzysztof Opasiak > --- > tools/usb/usbip/README | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/usb/usbip/README b/tools/usb/usbip/README > index 831f49f..f349ef4 100644 > --- a/tools/usb/usbip/README > +++ b/tools/usb/usbip/README > @@ -7,7 +7,7 @@ > > [Requirements] > - USB/IP device drivers > - Found in the staging directory of the Linux kernel. > + Found in the drivers/usb/usbip directory of the Linux kernel. > > - libudev >= 2.0 > libudev library > -- > 2.7.4 Fails to apply to my usb-next branch :(
Business Proposal
-- Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Quatif Group of Companies
Re: [BISSECTED]: BUG: usb: dwc3: usb ports not working anymore on odroid-XU4
On 19/01/2017 09:03, Felipe Balbi wrote:
>
> Hi,
>
> Richard Genoud writes:
>> Hi,
>> Since commit c499ff71ff2a2 ("usb: dwc3: core: re-factor init and exit paths")
>> (merged in 4.8), the usb ports on odroid-XU4 don't work anymore.
>>
>> [ Actually, it's commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all
>> cores"), cf below ]
>>
>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2
>> msec, port status = 0xc400fe3
>> [ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop
>> endpoint command.
>> [ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>> host.
>> [ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>> [ 74.606276] usb 3-1: USB disconnect, device number 2
>> [ 74.613565] usb 4-1: USB disconnect, device number 2
>> [ 74.621208] usb usb3-port1: couldn't allocate usb_device
>> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0
>> device (SATA to USB3 for instance).
>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek
>> RTL8153 chip.
>>
>> I instrumented what was read/written in the registers before and after this
>> patch, and I found that the culprit is:
>> if (dwc->revision > DWC3_REVISION_194A)
>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>> Before commit c499ff71ff2a2 ("usb: dwc3: core: re-factor init and exit
>> paths"), dwc3_phy_setup() was
>> done early in dwc3_probe() and thus, dwc->revision wasn't set yet (==0)
>> After this commit, dwc3_phy_setup() is done in dwc3_core_init(), after
>> setting dwc->revision (it's done in dwc3_core_is_valid()).
>>
>> (The dwc3->revision on odroid-XU4 is 5533200a.)
>>
>> If I comment out the 2 lines:
>> if (dwc->revision > DWC3_REVISION_194A)
>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>> The usb key is recognized right away:
>> [ 38.008158] usb 3-1.2: new high-speed USB device number 3 using xhci-hcd
>> [ 38.138924] usb 3-1.2: New USB device found, idVendor=abcd, idProduct=1234
>> [ 38.144399] usb 3-1.2: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3
>>
>> I took a look at the history behind those 2 lines, and they've been
>> introduced by:
>> commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores") in 3.19.
>> In 3.19, the dwc->revision dwc3_phy_setup() was set in dwc3_core_init().
>> And, booting a 3.19 kernel on XU4 gives the same error (whereas booting a
>> 3.18 kernel is ok)
>>
>> [ So, I should have started this email with:
>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>> the usb ports on odroid-XU4 don't work anymore. ]
>>
>> The funny thing is that commit 45bb7de213d8("usb: dwc3: setup phys earlier")
>> (merged in 4.2)
>> moved dwc3_phy_setup() in dwc3_probe(), way before dwc->revision was set,
>> acting like a revert
>> on commit 2164a476205c("usb: dwc3: set SUSPHY bit for all cores")
>> That's why on 4.2, inserting an USB key on odroid-XU4 worked again,
>>
>> So, to make a resume:
>> xxx-> 3.18: usb ok
>> 3.19->4.1: usb error (due to commit 2164a476205ccc ("usb: dwc3: set SUSPHY
>> bit for all cores"))
>> 4.2->4.7: usb ok (due to commit 45bb7de213d8("usb: dwc3: setup phys
>> earlier"))
>> 4.8->now: usb error (due to commit c499ff71ff2a2 ("usb: dwc3: core:
>> re-factor init and exit paths"))
>>
>>
>> any idea on this ?
>
> Thanks for bisecting. This could be caused by a similar case as
> described at [1]. Can you check if adding quirk
> "snps,dis_u3_susphy_quirk" helps ?
>
> [1]
> https://marc.info/?i=2b3535c5ece8b5419e3ecbe300772909021b3fd...@us01wembx2.internal.synopsys.com
>
Thanks for your quick answer !
yes, adding this patch:
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
index 2faf88627a48..c76e76bc9ade 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
@@ -43,6 +43,9 @@
status = "okay";
};
+&usbdrd_dwc3_0 {
+ snps,dis_u3_susphy_quirk;
+};
&usbdrd_dwc3_1 {
dr_mode = "host";
};
removes the error "Port resume took longer than 2 msec, port status =
0xc400fe3"
and the USB devices are detected.
Richard.
Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability
* Lu Baolu wrote:
> xHCI debug capability (DbC) is an optional but standalone
> functionality provided by an xHCI host controller. Software
> learns this capability by walking through the extended
> capability list of the host. xHCI specification describes
> DbC in section 7.6.
>
> This patch introduces the code to probe and initialize the
> debug capability hardware during early boot. With hardware
> initialized, the debug target (system on which this code is
> running) will present a debug device through the debug port
> (normally the first USB3 port). The debug device is fully
> compliant with the USB framework and provides the equivalent
> of a very high performance (USB3) full-duplex serial link
> between the debug host and target. The DbC functionality is
> independent of xHCI host. There isn't any precondition from
> xHCI host side for DbC to work.
>
> This patch also includes bulk out and bulk in interfaces.
> These interfaces could be used to implement early printk
> bootconsole or hook to various system debuggers.
>
> This code is designed to be only used for kernel debugging
> when machine crashes very early before the console code is
> initialized. For normal operation it is not recommended.
>
> Cc: Mathias Nyman
> Signed-off-by: Lu Baolu
> ---
> arch/x86/Kconfig.debug| 14 +
> drivers/usb/Kconfig |3 +
> drivers/usb/Makefile |2 +-
> drivers/usb/early/Makefile|1 +
> drivers/usb/early/xhci-dbc.c | 1068
> +
> drivers/usb/early/xhci-dbc.h | 205
> include/linux/usb/xhci-dbgp.h | 22 +
> 7 files changed, 1314 insertions(+), 1 deletion(-)
> create mode 100644 drivers/usb/early/xhci-dbc.c
> create mode 100644 drivers/usb/early/xhci-dbc.h
> create mode 100644 include/linux/usb/xhci-dbgp.h
>
> diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> index 67eec55..13e85b7 100644
> --- a/arch/x86/Kconfig.debug
> +++ b/arch/x86/Kconfig.debug
> @@ -29,6 +29,7 @@ config EARLY_PRINTK
> config EARLY_PRINTK_DBGP
> bool "Early printk via EHCI debug port"
> depends on EARLY_PRINTK && PCI
> + select USB_EARLY_PRINTK
> ---help---
> Write kernel log output directly into the EHCI debug port.
>
> @@ -48,6 +49,19 @@ config EARLY_PRINTK_EFI
> This is useful for kernel debugging when your machine crashes very
> early before the console code is initialized.
>
> +config EARLY_PRINTK_XDBC
> + bool "Early printk via xHCI debug port"
> + depends on EARLY_PRINTK && PCI
> + select USB_EARLY_PRINTK
> + ---help---
> + Write kernel log output directly into the xHCI debug port.
> +
> + This is useful for kernel debugging when your machine crashes very
> + early before the console code is initialized. For normal operation
> + it is not recommended because it looks ugly and doesn't cooperate
> + with klogd/syslogd or the X server. You should normally N here,
> + unless you want to debug such a crash.
Could we please do this rename:
s/EARLY_PRINTK_XDBC
EARLY_PRINTK_USB_XDBC
?
As many people will not realize what 'xdbc' means, standalone - while "it's an
USB serial logging variant" is a lot more natural.
> +config USB_EARLY_PRINTK
> + bool
Also, could we standardize the nomencalture to not be a mixture of prefixes and
postfixes - i.e. standardize on postfixes (as commonly done in the Kconfig
space)
and rename this one to EARLY_PRINTK_USB or so?
You can see the prefix/postfix inconsistency here already:
> -obj-$(CONFIG_EARLY_PRINTK_DBGP) += early/
> +obj-$(CONFIG_USB_EARLY_PRINTK) += early/
> +obj-$(CONFIG_EARLY_PRINTK_XDBC) += xhci-dbc.o
> +static void __iomem * __init xdbc_map_pci_mmio(u32 bus, u32 dev, u32 func)
> +{
> + u32 val, sz;
> + u64 val64, sz64, mask64;
> + u8 byte;
> + void __iomem *base;
> +
> + val = read_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0);
> + write_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0, ~0);
> + sz = read_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0);
> + write_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0, val);
> + if (val == 0x || sz == 0x) {
> + pr_notice("invalid mmio bar\n");
> + return NULL;
> + }
> + if ((val & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> + PCI_BASE_ADDRESS_MEM_TYPE_64) {
Please don't break the line here.
> + val = read_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4);
> + write_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4, ~0);
> + sz = read_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4);
> + write_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4, val);
> +
> + val64 |= ((u64)val << 32);
> + sz64 |= ((u64)sz << 32);
> + mask64 |= ((u64)~0 << 32);
Unnecessary parentheses.
> + }
> +
> + sz64 &= mask64;
> +
> + if (sizeof(dma_a
Re: [PATCH v5 2/4] x86: add support for earlyprintk via USB3 debug port
* Lu Baolu wrote:
> index 8a12199..c4031b9 100644
> --- a/arch/x86/kernel/early_printk.c
> +++ b/arch/x86/kernel/early_printk.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -381,6 +382,10 @@ static int __init setup_early_printk(char *buf)
> if (!strncmp(buf, "efi", 3))
> early_console_register(&early_efi_console, keep);
> #endif
> +#ifdef CONFIG_EARLY_PRINTK_XDBC
> + if (!strncmp(buf, "xdbc", 4))
> + early_xdbc_parse_parameter(buf + 4);
> +#endif
>
> buf++;
> }
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 9c337b0..09d4a56 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -70,6 +70,8 @@
> #include
> #include
>
> +#include
> +
> #include
>
> #include
> @@ -1096,6 +1098,11 @@ void __init setup_arch(char **cmdline_p)
> memblock_set_current_limit(ISA_END_ADDRESS);
> memblock_x86_fill();
>
> +#ifdef CONFIG_EARLY_PRINTK_XDBC
> + if (!early_xdbc_setup_hardware())
> + early_xdbc_register_console();
> +#endif
> +
> reserve_bios_regions();
>
> if (efi_enabled(EFI_MEMMAP)) {
> --
> 2.1.4
Please create proper wrappers in xhci-dbgp.h to not litter generic code with
these
#ifdefs.
Thanks,
Ingo
Re: [PATCH] ARM: Exynos4415: remove dead build rule
On 01/19/2017 10:28 AM, Krzysztof Kozlowski wrote: > Is your tree included in linux-next? I see my patch here: > https://git.linuxtv.org/snawrocki/samsung.git/log/?h=for-v4.11/clk/next > so maybe something in linux-next is missing? No, it's not included. I will be sending a pull request to the clk maintainers this week so the patches should end up in linux-next soon. -- Thanks, Sylwester
[PATCH net-next] net/sched: cls_flower: reduce fl_change stack size
The new ARP support has pushed the stack size over the edge on ARM,
as there are two large objects on the stack in this function (mask
and tb) and both have now grown a bit more:
net/sched/cls_flower.c: In function 'fl_change':
net/sched/cls_flower.c:928:1: error: the frame size of 1072 bytes is larger
than 1024 bytes [-Werror=frame-larger-than=]
We can solve this by dynamically allocating one or both of them.
I first tried to do it just for the mask, but that only saved
152 bytes on ARM, while this version just does it for the 'tb'
array, bringing the stack size back down to 664 bytes.
Fixes: 99d31326cbe6 ("net/sched: cls_flower: Support matching on ARP")
Signed-off-by: Arnd Bergmann
---
net/sched/cls_flower.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 27934456d984..9e74b0fa4b89 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -832,23 +832,31 @@ static int fl_change(struct net *net, struct sk_buff
*in_skb,
struct cls_fl_head *head = rtnl_dereference(tp->root);
struct cls_fl_filter *fold = (struct cls_fl_filter *) *arg;
struct cls_fl_filter *fnew;
- struct nlattr *tb[TCA_FLOWER_MAX + 1];
+ struct nlattr **tb;
struct fl_flow_mask mask = {};
int err;
if (!tca[TCA_OPTIONS])
return -EINVAL;
+ tb = kcalloc(TCA_FLOWER_MAX + 1, sizeof(struct nlattr *), GFP_KERNEL);
+ if (!tb)
+ return -ENOBUFS;
+
err = nla_parse_nested(tb, TCA_FLOWER_MAX, tca[TCA_OPTIONS], fl_policy);
if (err < 0)
- return err;
+ goto errout_tb;
- if (fold && handle && fold->handle != handle)
- return -EINVAL;
+ if (fold && handle && fold->handle != handle) {
+ err = -EINVAL;
+ goto errout_tb;
+ }
fnew = kzalloc(sizeof(*fnew), GFP_KERNEL);
- if (!fnew)
- return -ENOBUFS;
+ if (!fnew) {
+ err = -ENOBUFS;
+ goto errout_tb;
+ }
err = tcf_exts_init(&fnew->exts, TCA_FLOWER_ACT, 0);
if (err < 0)
@@ -919,11 +927,14 @@ static int fl_change(struct net *net, struct sk_buff
*in_skb,
list_add_tail_rcu(&fnew->list, &head->filters);
}
+ kfree(tb);
return 0;
errout:
tcf_exts_destroy(&fnew->exts);
kfree(fnew);
+errout_tb:
+ kfree(tb);
return err;
}
--
2.9.0
Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.
Hi Hanjun,
On 19 January 2017 at 16:02, Hanjun Guo wrote:
> Hi Fuwei,
>
> One comments below.
>
>
> On 2017/1/18 21:25, fu@linaro.org wrote:
>>
>> From: Fu Wei
>>
>> The counter frequency detection call(arch_timer_detect_rate) combines two
>> ways to get counter frequency: system coprocessor register and MMIO timer.
>> But in a specific timer init code, we only need one way to try:
>> getting frequency from MMIO timer register will be needed only when we
>> init MMIO timer; getting frequency from system coprocessor register will
>> be needed only when we init arch timer.
>>
>> This patch separates paths to determine frequency:
>> Separate out the MMIO frequency and the sysreg frequency detection call,
>> and use the appropriate one for the counter.
>>
>> Signed-off-by: Fu Wei
>> ---
>> drivers/clocksource/arm_arch_timer.c | 40
>> ++--
>> 1 file changed, 25 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c
>> b/drivers/clocksource/arm_arch_timer.c
>> index 6484f84..9482481 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -488,23 +488,33 @@ static int arch_timer_starting_cpu(unsigned int cpu)
>> return 0;
>> }
>>
>> -static void arch_timer_detect_rate(void __iomem *cntbase)
>> +static void __arch_timer_determine_rate(u32 rate)
>> {
>> - /* Who has more than one independent system counter? */
>> - if (arch_timer_rate)
>> - return;
>> + /* Check the timer frequency. */
>> + if (!arch_timer_rate) {
>> + if (rate)
>> + arch_timer_rate = rate;
>> + else
>> + pr_warn("frequency not available\n");
>> + } else if (rate && arch_timer_rate != rate) {
>
> ^
> Typo? I think it's "&" here.
Not a typo, It's definitely a “&&” :-)
Here arch_timer_rate is not zero.
If rate is not zero(that means we got a valid rate), and
arch_timer_rate != rate ,
we will print warning message.
>
> Thanks
> Hanjun
--
Best regards,
Fu Wei
Software Engineer
Red Hat
Re: [PATCH 8/8] Revert "ext4: fix wrong gfp type under transaction"
On Thu 19-01-17 09:39:56, Michal Hocko wrote:
> On Tue 17-01-17 18:29:25, Jan Kara wrote:
> > On Tue 17-01-17 17:16:19, Michal Hocko wrote:
> > > > > But before going to play with that I am really wondering whether we
> > > > > need
> > > > > all this with no journal at all. AFAIU what Jack told me it is the
> > > > > journal lock(s) which is the biggest problem from the reclaim
> > > > > recursion
> > > > > point of view. What would cause a deadlock in no journal mode?
> > > >
> > > > We still have the original problem for why we need GFP_NOFS even in
> > > > ext2. If we are in a writeback path, and we need to allocate memory,
> > > > we don't want to recurse back into the file system's writeback path.
> > >
> > > But we do not enter the writeback path from the direct reclaim. Or do
> > > you mean something other than pageout()'s mapping->a_ops->writepage?
> > > There is only try_to_release_page where we get back to the filesystems
> > > but I do not see any NOFS protection in ext4_releasepage.
> >
> > Maybe to expand a bit: These days, direct reclaim can call ->releasepage()
> > callback, ->evict_inode() callback (and only for inodes with i_nlink > 0),
> > shrinkers. That's it. So the recursion possibilities are rather more limited
> > than they used to be several years ago and we likely do not need as much
> > GFP_NOFS protection as we used to.
>
> Thanks for making my remark more clear Jack! I would just want to add
> that I was playing with the patch below (it is basically
> GFP_NOFS->GFP_KERNEL for all allocations which trigger warning from the
> debugging patch which means they are called from within transaction) and
> it didn't hit the lockdep when running xfstests both with or without the
> enabled journal.
>
> So am I still missing something or the nojournal mode is safe and the
> current series is OK wrt. ext*?
I'm convinced the current series is OK, only real life will tell us whether
we missed something or not ;)
> The following patch in its current form is WIP and needs a proper review
> before I post it.
So jbd2 changes look confusing (although technically correct) to me - we
*always* should run in NOFS context in those place so having GFP_KERNEL
there looks like it is unnecessarily hiding what is going on. So in those
places I'd prefer to keep GFP_NOFS or somehow else make it very clear these
allocations are expected to be GFP_NOFS (and assert that). Otherwise the
changes look good to me.
Honza
> ---
> fs/ext4/inode.c | 4 ++--
> fs/ext4/mballoc.c | 14 +++---
> fs/ext4/xattr.c | 2 +-
> fs/jbd2/journal.c | 4 ++--
> fs/jbd2/revoke.c | 2 +-
> fs/jbd2/transaction.c | 2 +-
> 6 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index b7d141c3b810..841cb8c4cb5e 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -2085,7 +2085,7 @@ static int ext4_writepage(struct page *page,
> return __ext4_journalled_writepage(page, len);
>
> ext4_io_submit_init(&io_submit, wbc);
> - io_submit.io_end = ext4_init_io_end(inode, GFP_NOFS);
> + io_submit.io_end = ext4_init_io_end(inode, GFP_KERNEL);
> if (!io_submit.io_end) {
> redirty_page_for_writepage(wbc, page);
> unlock_page(page);
> @@ -3794,7 +3794,7 @@ static int __ext4_block_zero_page_range(handle_t
> *handle,
> int err = 0;
>
> page = find_or_create_page(mapping, from >> PAGE_SHIFT,
> -mapping_gfp_constraint(mapping, ~__GFP_FS));
> +mapping_gfp_mask(mapping));
> if (!page)
> return -ENOMEM;
>
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index d9fd184b049e..67b97cd6e3d6 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -1251,7 +1251,7 @@ ext4_mb_load_buddy_gfp(struct super_block *sb,
> ext4_group_t group,
> static int ext4_mb_load_buddy(struct super_block *sb, ext4_group_t group,
> struct ext4_buddy *e4b)
> {
> - return ext4_mb_load_buddy_gfp(sb, group, e4b, GFP_NOFS);
> + return ext4_mb_load_buddy_gfp(sb, group, e4b, GFP_KERNEL);
> }
>
> static void ext4_mb_unload_buddy(struct ext4_buddy *e4b)
> @@ -2054,7 +2054,7 @@ static int ext4_mb_good_group(struct
> ext4_allocation_context *ac,
>
> /* We only do this if the grp has never been initialized */
> if (unlikely(EXT4_MB_GRP_NEED_INIT(grp))) {
> - int ret = ext4_mb_init_group(ac->ac_sb, group, GFP_NOFS);
> + int ret = ext4_mb_init_group(ac->ac_sb, group, GFP_KERNEL);
> if (ret)
> return ret;
> }
> @@ -3600,7 +3600,7 @@ ext4_mb_new_inode_pa(struct ext4_allocation_context *ac)
> BUG_ON(ac->ac_status != AC_STATUS_FOUND);
> BUG_ON(!S_ISREG(ac->ac_inode->i_mode));
>
> - pa = kmem_cache_alloc(ext4_pspace_cachep,
Re: [PATCH] net/mlx5e: Remove unused variable
Hi Arnd,
On 19/01/2017 11:33 AM, Arnd Bergmann wrote:
A cleanup removed the only user of this variable
mlx5/core/en_ethtool.c: In function 'mlx5e_set_channels':
mlx5/core/en_ethtool.c:546:6: error: unused variable 'ncv'
[-Werror=unused-variable]
Let's remove the declaration as well.
Fixes: 639e9e94160e ("net/mlx5e: Remove unnecessary checks when setting num
channels")
Signed-off-by: Arnd Bergmann
---
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index b1b9eb6ee135..5197817e4b2f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -543,7 +543,6 @@ static int mlx5e_set_channels(struct net_device *dev,
struct ethtool_channels *ch)
{
struct mlx5e_priv *priv = netdev_priv(dev);
- int ncv = mlx5e_get_max_num_channels(priv->mdev);
unsigned int count = ch->combined_count;
bool arfs_enabled;
bool was_opened;
Reported-by: Stephen Rothwell
Reviewed-by: Tariq Toukan
Thanks for the fix!
Regards,
Tariq
Re: [PATCH v3 1/5] staging: fbtft: convert fbtft_reset() to be non-atomic
On Tue, Jan 03, 2017 at 08:29:45PM +0200, Andy Shevchenko wrote: > First of all, fbtft in current state doesn't allow to override GPIOs to be > optional, like "reset" one. It might be a bug somewhere, but rather out of > scope of this fix. > > Second, not all GPIOs available on the board would be SoC based, some of them > might sit on I2C GPIO expanders, for example, on Intel Edison/Arduino, and > thus > any communication with them might sleep. > > Besides that using udelay() and mdelay() is kinda resource wasteful. > > Summarize all of the above, convert fbtft_reset() function to non-atomic > variant by using gpio_set_value_cansleep(), usleep_range(), and msleep(). > > Reviewed-by: Noralf Trønnes > Signed-off-by: Andy Shevchenko Andy, this series came through with the charmap all corrupted and git didn't like them at all. Can you fix up and resend? thanks, greg k-h
[PATCH 2/3] pinctrl: Allow configuration of pins from gpiolib based drivers
When a GPIO driver is backed by a pinctrl driver the GPIO driver
sometimes needs to call the pinctrl driver to configure certain things,
like whether the pin is used as input or output. In addition to this
there are other configurations applicable to GPIOs such as setting
debounce time of the GPIO.
To support this we introduce a new function pinctrl_gpio_set_config()
that can be used by gpiolib based driver to pass configuration requests
to the backing pinctrl driver.
Signed-off-by: Mika Westerberg
---
drivers/pinctrl/core.c | 28
drivers/pinctrl/pinconf.c| 12
drivers/pinctrl/pinconf.h| 9 +
include/linux/pinctrl/consumer.h | 6 ++
4 files changed, 55 insertions(+)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index fb38e208f32d..8f6b2631c244 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -688,6 +688,34 @@ int pinctrl_gpio_direction_output(unsigned gpio)
}
EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_output);
+/**
+ * pinctrl_gpio_set_config() - Apply config to given GPIO pin
+ * @gpio: the GPIO pin number from the GPIO subsystem number space
+ *
+ * This function should *ONLY* be used from gpiolib-based GPIO drivers, if
+ * they need to call the underlying pin controller to change GPIO config
+ * (for example set debounce time).
+ */
+int pinctrl_gpio_set_config(unsigned gpio, unsigned long config)
+{
+ unsigned long configs[] = { config };
+ struct pinctrl_gpio_range *range;
+ struct pinctrl_dev *pctldev;
+ int ret, pin;
+
+ ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
+ if (ret)
+ return ret;
+
+ mutex_lock(&pctldev->mutex);
+ pin = gpio_to_pin(range, gpio);
+ ret = pinconf_set_config(pctldev, pin, configs, ARRAY_SIZE(configs));
+ mutex_unlock(&pctldev->mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pinctrl_gpio_set_config);
+
static struct pinctrl_state *find_state(struct pinctrl *p,
const char *name)
{
diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 799048f3c8d4..c1c1ccc58267 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -200,6 +200,18 @@ int pinconf_apply_setting(struct pinctrl_setting const
*setting)
return 0;
}
+int pinconf_set_config(struct pinctrl_dev *pctldev, unsigned pin,
+ unsigned long *configs, size_t nconfigs)
+{
+ const struct pinconf_ops *ops;
+
+ ops = pctldev->desc->confops;
+ if (!ops)
+ return -ENOTSUPP;
+
+ return ops->pin_config_set(pctldev, pin, configs, nconfigs);
+}
+
#ifdef CONFIG_DEBUG_FS
static void pinconf_show_config(struct seq_file *s, struct pinctrl_dev
*pctldev,
diff --git a/drivers/pinctrl/pinconf.h b/drivers/pinctrl/pinconf.h
index 55c75780b3b2..bf8aff9abf32 100644
--- a/drivers/pinctrl/pinconf.h
+++ b/drivers/pinctrl/pinconf.h
@@ -20,6 +20,9 @@ int pinconf_map_to_setting(struct pinctrl_map const *map,
void pinconf_free_setting(struct pinctrl_setting const *setting);
int pinconf_apply_setting(struct pinctrl_setting const *setting);
+int pinconf_set_config(struct pinctrl_dev *pctldev, unsigned pin,
+ unsigned long *configs, size_t nconfigs);
+
/*
* You will only be interested in these if you're using PINCONF
* so don't supply any stubs for these.
@@ -56,6 +59,12 @@ static inline int pinconf_apply_setting(struct
pinctrl_setting const *setting)
return 0;
}
+static inline int pinconf_set_config(struct pinctrl_dev *pctldev, unsigned pin,
+unsigned long *configs, size_t nconfigs)
+{
+ return -ENOTSUPP;
+}
+
#endif
#if defined(CONFIG_PINCONF) && defined(CONFIG_DEBUG_FS)
diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h
index d7e5d608faa7..a0f2aba72fa9 100644
--- a/include/linux/pinctrl/consumer.h
+++ b/include/linux/pinctrl/consumer.h
@@ -29,6 +29,7 @@ extern int pinctrl_request_gpio(unsigned gpio);
extern void pinctrl_free_gpio(unsigned gpio);
extern int pinctrl_gpio_direction_input(unsigned gpio);
extern int pinctrl_gpio_direction_output(unsigned gpio);
+extern int pinctrl_gpio_set_config(unsigned gpio, unsigned long config);
extern struct pinctrl * __must_check pinctrl_get(struct device *dev);
extern void pinctrl_put(struct pinctrl *p);
@@ -80,6 +81,11 @@ static inline int pinctrl_gpio_direction_output(unsigned
gpio)
return 0;
}
+static inline int pinctrl_gpio_set_config(unsigned gpio, unsigned long config)
+{
+ return 0;
+}
+
static inline struct pinctrl * __must_check pinctrl_get(struct device *dev)
{
return NULL;
--
2.11.0
Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)
On 2017-01-17 Michal Hocko wrote: > On Tue 17-01-17 14:21:14, Mel Gorman wrote: > > On Tue, Jan 17, 2017 at 02:52:28PM +0100, Michal Hocko wrote: > > > On Mon 16-01-17 11:09:34, Mel Gorman wrote: > > > [...] > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > > > index 532a2a750952..46aac487b89a 100644 > > > > --- a/mm/vmscan.c > > > > +++ b/mm/vmscan.c > > > > @@ -2684,6 +2684,7 @@ static void shrink_zones(struct zonelist > > > > *zonelist, struct scan_control *sc) continue; > > > > > > > > if (sc->priority != DEF_PRIORITY && > > > > + !buffer_heads_over_limit && > > > > !pgdat_reclaimable(zone->zone_pgdat)) > > > > continue; /* Let kswapd > > > > poll it */ > > > > > > I think we should rather remove pgdat_reclaimable here. This > > > sounds like a wrong layer to decide whether we want to reclaim > > > and how much. > > > > I had considered that but it'd also be important to add the other > > 32-bit patches you have posted to see the impact. Because of the > > ratio of LRU pages to slab pages, it may not have an impact but > > it'd need to be eliminated. > > OK, Trevor you can pull from > git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree > fixes/highmem-node-fixes branch. This contains the current mmotm tree > + the latest highmem fixes. I also do not expect this would help much > in your case but as Mel've said we should rule that out at least. Hi! The git tree above version oom'd after < 24 hours (3:02am) so it doesn't solve the bug. If you need a oom messages dump let me know. Let me know what to try next, guys, and I'll test it out. > > Before prototyping such a thing, I'd like to hear the outcome of > > this heavy hack and then add your 32-bit patches onto the list. If > > the problem is still there then I'd next look at taking slab pages > > into account in pgdat_reclaimable() instead of an outright removal > > that has a much wider impact. If that doesn't work then I'll > > prototype a heavy-handed forced slab reclaim when lower zones are > > almost all slab pages. I don't think I've tried the "heavy hack" patch yet? It's not in the mhocko tree I just tried? Should I try the heavy hack on top of mhocko git or on vanilla or what? I also want to mention that these PAE boxes suffer from another problem/bug that I've worked around for almost a year now. For some reason it keeps gnawing at me that it might be related. The disk I/O goes to pot on this/these PAE boxes after a certain amount of disk writes (like some unknown number of GB, around 10-ish maybe). Like writes go from 500MB/s to 10MB/s!! Reboot and it's magically 500MB/s again. I detail this here: https://muug.ca/pipermail/roundtable/2016-June/004669.html My fix was to mem=XG where X is <8 (like 4 or 6) to force the PAE kernel to be more sane about highmem choices. I never filed a bug because I read a ton of stuff saying Linus hates PAE, don't use over 4G, blah blah. But the other fix is to: set /proc/sys/vm/highmem_is_dirtyable to 1 I'm not bringing this up to get attention to a new bug, I bring this up because it smells like it might be related. If something slowly eats away at the box's vm to the point that I/O gets horribly slow, perhaps it's related to the slab and high/lomem issue we have here? And if related, it may help to solve the oom bug. If I'm way off base here, just ignore my tangent! The funny thing is I thought mem=XG where X<8 solved the problem, but it doesn't! It greatly mitigates it, but I still get subtle slowdown that gets worse over time (like weeks instead of days). I now use the highmem_is_dirtyable on most boxes and that seems to solve it for good in combo with mem=XG. Let me note, however, that I have NOT set highmem_is_dirtyable=1 on the test box I am using for all of this building/testing, as I wanted the config to stay static while I work through this oom bug. (I'm real curious to see if highmem_is_dirtyable=1 would have any impact on the oom though!) Thanks!
Re: [PATCH] drivers: staging: Fix "space required after that ','" errors
On Tue, Jan 17, 2017 at 10:56:31PM +0530, simran singhal wrote:
> Fix checkpatch.pl "space required after that ','" errors
>
> Signed-off-by: simran singhal
>
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
> b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
> index d7d85b3..6380b41 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
> @@ -3177,7 +3177,7 @@ int ieee80211_wpa_supplicant_ioctl(struct
> ieee80211_device *ieee, struct iw_poin
> break;
>
> default:
> - printk("Unknown WPA supplicant request: %d\n",param->cmd);
> + printk("Unknown WPA supplicant request: %d\n", param->cmd);
> ret = -EOPNOTSUPP;
> break;
> }
> ---
> drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
> b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
> index d7d85b3..6380b41 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
> @@ -3177,7 +3177,7 @@ int ieee80211_wpa_supplicant_ioctl(struct
> ieee80211_device *ieee, struct iw_poin
> break;
>
> default:
> - printk("Unknown WPA supplicant request: %d\n",param->cmd);
> + printk("Unknown WPA supplicant request: %d\n", param->cmd);
> ret = -EOPNOTSUPP;
> break;
> }
> --
> 2.7.4
You seem to have duplicated the patch twice here, please fix up and
resend.
thanks,
greg k-h
[PATCH 3/3] pinctrl / gpio: Introduce .set_config() callback for GPIO chips
Currently we already have two pin configuration related callbacks
available for GPIO chips .set_single_ended() and .set_debounce(). In
future we expect to have even more, which does not scale well if we need
to add yet another callback to the GPIO chip structure for each possible
configuration parameter.
Better solution is to reuse what we already have available in the
generic pinconf.
To support this, we introduce a new .set_config() callback for GPIO
chips. The callback takes a single packed pin configuration value as
parameter. This can then be extended easily beyond what is currently
supported by just adding new types to the generic pinconf enum.
We then convert the existing drivers over .set_config() and finally
remove the .set_single_ended() and .set_debounce() callbacks.
Suggested-by: Linus Walleij
Signed-off-by: Mika Westerberg
---
Documentation/gpio/driver.txt | 9 +++--
drivers/gpio/gpio-bcm-kona.c | 14 ++-
drivers/gpio/gpio-dln2.c | 12 --
drivers/gpio/gpio-dwapb.c | 14 ++-
drivers/gpio/gpio-ep93xx.c| 11 --
drivers/gpio/gpio-f7188x.c| 19 +
drivers/gpio/gpio-lp873x.c| 14 +++
drivers/gpio/gpio-max77620.c | 20 +-
drivers/gpio/gpio-menz127.c | 34 -
drivers/gpio/gpio-merrifield.c| 14 ++-
drivers/gpio/gpio-omap.c | 14 ++-
drivers/gpio/gpio-tc3589x.c | 15
drivers/gpio/gpio-tegra.c | 14 ++-
drivers/gpio/gpio-tps65218.c | 14 +++
drivers/gpio/gpio-vx855.c | 13 ---
drivers/gpio/gpio-wcove.c | 13 +++
drivers/gpio/gpio-wm831x.c| 21 +-
drivers/gpio/gpio-wm8994.c| 13 +++
drivers/gpio/gpiolib.c| 41 ++--
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 14 ++-
drivers/pinctrl/pinctrl-amd.c | 14 ++-
drivers/pinctrl/pinctrl-sx150x.c | 55 +--
drivers/staging/greybus/gpio.c| 15 +---
drivers/usb/serial/cp210x.c | 13 ---
include/linux/gpio/driver.h | 35 +++--
include/linux/pinctrl/pinconf-generic.h | 32 +++-
26 files changed, 282 insertions(+), 215 deletions(-)
diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt
index 747c721776ed..ad8f0c0cd13f 100644
--- a/Documentation/gpio/driver.txt
+++ b/Documentation/gpio/driver.txt
@@ -146,10 +146,11 @@ a pull-up resistor is needed on the outgoing rail to
complete the circuit, and
in the second case, a pull-down resistor is needed on the rail.
Hardware that supports open drain or open source or both, can implement a
-special callback in the gpio_chip: .set_single_ended() that takes an enum flag
-telling whether to configure the line as open drain, open source or push-pull.
-This will happen in response to the GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag
-set in the machine file, or coming from other hardware descriptions.
+special callback in the gpio_chip: .set_config() that takes a generic
+pinconf packed value telling whether to configure the line as open drain,
+open source or push-pull. This will happen in response to the
+GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag set in the machine file, or coming
+from other hardware descriptions.
If this state can not be configured in hardware, i.e. if the GPIO hardware does
not support open drain/open source in hardware, the GPIO library will instead
diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
index 3d1cf018e8e7..41d0ac142580 100644
--- a/drivers/gpio/gpio-bcm-kona.c
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -308,6 +308,18 @@ static int bcm_kona_gpio_set_debounce(struct gpio_chip
*chip, unsigned gpio,
return 0;
}
+static int bcm_kona_gpio_set_config(struct gpio_chip *chip, unsigned gpio,
+ unsigned long config)
+{
+ u32 debounce;
+
+ if (pinconf_to_config_param(config) != PIN_CONFIG_INPUT_DEBOUNCE)
+ return -ENOTSUPP;
+
+ debounce = pinconf_to_config_argument(config);
+ return bcm_kona_gpio_set_debounce(chip, gpio, debounce);
+}
+
static const struct gpio_chip template_chip = {
.label = "bcm-kona-gpio",
.owner = THIS_MODULE,
@@ -318,7 +330,7 @@ static const struct gpio_chip template_chip = {
.get = bcm_kona_gpio_get,
.direction_output = bcm_kona_gpio_direction_output,
.set = bcm_kona_gpio_set,
- .set_debounce = bcm_kona_gpio_set_debounce,
+ .set_config = bcm_kona_gpio_set_config,
.to_irq = bcm_kona_gpio_to_irq,
.base = 0,
};
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2
[PATCH 1/3] pinctrl: Widen the generic pinconf argument from 16 to 24 bits
The current pinconf packed format allows only 16-bit argument limiting
the maximum value 65535. For most types this is enough. However,
debounce time can be in range of hundreths of milliseconds in case of
mechanical switches so we cannot represent the worst case using the
current format.
In order to support larger values change the packed format so that the
lower 8 bits are used as type which leaves 24 bits for the argument.
This allows representing values up to 16777215 and debounce times up to
16 seconds.
We also convert the existing users to use 32-bit integer when extracting
argument from the packed configuration value.
Signed-off-by: Mika Westerberg
---
drivers/pinctrl/bcm/pinctrl-bcm281xx.c | 6 +++---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 2 +-
drivers/pinctrl/bcm/pinctrl-ns2-mux.c| 6 +++---
drivers/pinctrl/bcm/pinctrl-nsp-gpio.c | 6 +++---
drivers/pinctrl/intel/pinctrl-cherryview.c | 4 ++--
drivers/pinctrl/meson/pinctrl-meson.c| 2 --
drivers/pinctrl/pinctrl-da850-pupd.c | 2 --
drivers/pinctrl/pinctrl-lpc18xx.c| 10 +-
drivers/pinctrl/pinctrl-max77620.c | 2 +-
drivers/pinctrl/pinctrl-palmas.c | 2 +-
drivers/pinctrl/pinctrl-rockchip.c | 2 +-
drivers/pinctrl/pinctrl-single.c | 2 +-
drivers/pinctrl/sirf/pinctrl-atlas7.c| 3 ++-
drivers/pinctrl/sunxi/pinctrl-sunxi.c| 2 +-
drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 4 ++--
drivers/pinctrl/vt8500/pinctrl-wmt.c | 2 +-
drivers/rtc/rtc-omap.c | 2 +-
include/linux/pinctrl/pinconf-generic.h | 19 +++
18 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
index a5331fdfc795..810a81786f62 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
@@ -1106,7 +1106,7 @@ static int bcm281xx_std_pin_update(struct pinctrl_dev
*pctldev,
struct bcm281xx_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
int i;
enum pin_config_param param;
- u16 arg;
+ u32 arg;
for (i = 0; i < num_configs; i++) {
param = pinconf_to_config_param(configs[i]);
@@ -1222,7 +1222,7 @@ static int bcm281xx_i2c_pin_update(struct pinctrl_dev
*pctldev,
struct bcm281xx_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
int i, j;
enum pin_config_param param;
- u16 arg;
+ u32 arg;
for (i = 0; i < num_configs; i++) {
param = pinconf_to_config_param(configs[i]);
@@ -1292,7 +1292,7 @@ static int bcm281xx_hdmi_pin_update(struct pinctrl_dev
*pctldev,
struct bcm281xx_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
int i;
enum pin_config_param param;
- u16 arg;
+ u32 arg;
for (i = 0; i < num_configs; i++) {
param = pinconf_to_config_param(configs[i]);
diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index 5d1e505c3c63..3ca925dfefd1 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -619,7 +619,7 @@ static int iproc_pin_config_set(struct pinctrl_dev
*pctldev, unsigned pin,
{
struct iproc_gpio *chip = pinctrl_dev_get_drvdata(pctldev);
enum pin_config_param param;
- u16 arg;
+ u32 arg;
unsigned i, gpio = iproc_pin_to_gpio(pin);
int ret = -ENOTSUPP;
diff --git a/drivers/pinctrl/bcm/pinctrl-ns2-mux.c
b/drivers/pinctrl/bcm/pinctrl-ns2-mux.c
index 13a4c2774157..4b5cf0e0f16e 100644
--- a/drivers/pinctrl/bcm/pinctrl-ns2-mux.c
+++ b/drivers/pinctrl/bcm/pinctrl-ns2-mux.c
@@ -703,7 +703,7 @@ static int ns2_pin_get_enable(struct pinctrl_dev *pctrldev,
unsigned int pin)
}
static int ns2_pin_set_slew(struct pinctrl_dev *pctrldev, unsigned int pin,
- u16 slew)
+ u32 slew)
{
struct ns2_pinctrl *pinctrl = pinctrl_dev_get_drvdata(pctrldev);
struct ns2_pin *pin_data = pctrldev->desc->pins[pin].drv_data;
@@ -793,7 +793,7 @@ static void ns2_pin_get_pull(struct pinctrl_dev *pctrldev,
}
static int ns2_pin_set_strength(struct pinctrl_dev *pctrldev, unsigned int pin,
- u16 strength)
+ u32 strength)
{
struct ns2_pinctrl *pinctrl = pinctrl_dev_get_drvdata(pctrldev);
struct ns2_pin *pin_data = pctrldev->desc->pins[pin].drv_data;
@@ -904,7 +904,7 @@ static int ns2_pin_config_set(struct pinctrl_dev *pctrldev,
unsigned int pin,
struct ns2_pin *pin_data = pctrldev->desc->pins[pin].drv_data;
enum pin_config_param param;
unsigned int i;
- u16 arg;
+ u32 arg;
int ret = -ENOTSUPP;
Re: [PATCH v5 4/4] usb: doc: add document for USB3 debug port usage
* Lu Baolu wrote: > Add Documentation/usb/usb3-debug-port.rst. This document includes > the user guide for USB3 debug port. > > Cc: linux-...@vger.kernel.org > Signed-off-by: Lu Baolu > --- > Documentation/usb/usb3-debug-port.rst | 95 > +++ > 1 file changed, 95 insertions(+) > create mode 100644 Documentation/usb/usb3-debug-port.rst > > diff --git a/Documentation/usb/usb3-debug-port.rst > b/Documentation/usb/usb3-debug-port.rst > new file mode 100644 > index 000..70eabe4 > --- /dev/null > +++ b/Documentation/usb/usb3-debug-port.rst > @@ -0,0 +1,95 @@ > +=== > +USB3 debug port > +=== > + > +:Author: Lu Baolu > +:Date: October 2016 > + > +GENERAL > +=== > + > +This is a HOWTO for using USB3 debug port on x86 systems. > + > +Before using any kernel debugging functionalities based on USB3 s/debugging functionalities /debugging functionality > +debug port, you need to check 1) whether debug port is supported > +by the xHCI host, 2) which port is used for debugging purpose s/debugging purpose /debugging purposes > +On debug target system, you need to customize a debugging kernel s/On debug target system On the debug target system (There are more typos/grammar errors in the document, please re-read it.) Thanks, Ingo
Re: [PATCH] MIPS: KVM: Return directly after a failed copy_from_user() in kvm_arch_vcpu_ioctl()
On 18/01/2017 20:52, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 18 Jan 2017 20:43:41 +0100
>
> Return directly after a call of the function "copy_from_user" failed
> in a case block.
>
> Signed-off-by: Markus Elfring
The "out" label is now unused, so you should remove it.
Paolo
> ---
> arch/mips/kvm/mips.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index 06a60b19acfb..1dad78f74e8c 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -1152,10 +1152,8 @@ long kvm_arch_vcpu_ioctl(struct file *filp, unsigned
> int ioctl,
> {
> struct kvm_mips_interrupt irq;
>
> - r = -EFAULT;
> if (copy_from_user(&irq, argp, sizeof(irq)))
> - goto out;
> -
> + return -EFAULT;
> kvm_debug("[%d] %s: irq: %d\n", vcpu->vcpu_id, __func__,
> irq.irq);
>
> @@ -1165,9 +1163,8 @@ long kvm_arch_vcpu_ioctl(struct file *filp, unsigned
> int ioctl,
> case KVM_ENABLE_CAP: {
> struct kvm_enable_cap cap;
>
> - r = -EFAULT;
> if (copy_from_user(&cap, argp, sizeof(cap)))
> - goto out;
> + return -EFAULT;
> r = kvm_vcpu_ioctl_enable_cap(vcpu, &cap);
> break;
> }
>
Re: [PATCH 4/6] arm64: dts: mt8173: add reference clock for usb
On Wed, Jan 18, 2017 at 02:08:25PM +0800, Chunfeng Yun wrote: > add 26M reference clock for ssusb and xhci nodes > > Signed-off-by: Chunfeng Yun > --- > arch/arm64/boot/dts/mediatek/mt8173.dtsi |6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) This patch doesn't apply to my tree :(
[PATCH 0/3] pinctrl / gpio: Allow GPIO chips to use generic pinconfig
This series makes it possible to configure pins from GPIO chip drivers by implementing a new callback .set_config(). This callback replaces the existing .set_single_ended() and .set_debounce() simply because adding new callbacks for each possible configuration type does not scale. So instead we re-use the existing generic pinconf types and the packed format. This is a follow up of discussion on: https://patchwork.ozlabs.org/patch/713289/ While doing that, it was found out that the current packed format does not support all realistic debounce time values. The limit is ~64ms which does not cover mechanical switches connected to GPIOs that migh require values up to hundreths of milliseconds. To solve that we change the packed format so that the value takes 24 bits instead of 16, and change the callers to use 32-bit integer instead. We also make it possible for GPIO chip driver to call pinctrl directly by providing a new function pinctrl_gpio_set_config() following pinctrl_gpio_direction_output() and friends. I've tested this on Intel Gemini Lake SoC. Non-Intel drivers are compile tested only because I do not have the hardware. Mika Westerberg (3): pinctrl: Widen the generic pinconf argument from 16 to 24 bits pinctrl: Allow configuration of pins from gpiolib based drivers pinctrl / gpio: Introduce .set_config() callback for GPIO chips Documentation/gpio/driver.txt| 9 ++-- drivers/gpio/gpio-bcm-kona.c | 14 +- drivers/gpio/gpio-dln2.c | 12 -- drivers/gpio/gpio-dwapb.c| 14 +- drivers/gpio/gpio-ep93xx.c | 11 +++-- drivers/gpio/gpio-f7188x.c | 19 drivers/gpio/gpio-lp873x.c | 14 +++--- drivers/gpio/gpio-max77620.c | 20 - drivers/gpio/gpio-menz127.c | 34 +++ drivers/gpio/gpio-merrifield.c | 14 +- drivers/gpio/gpio-omap.c | 14 +- drivers/gpio/gpio-tc3589x.c | 15 +++ drivers/gpio/gpio-tegra.c| 14 +- drivers/gpio/gpio-tps65218.c | 14 +++--- drivers/gpio/gpio-vx855.c| 13 +++--- drivers/gpio/gpio-wcove.c| 13 +++--- drivers/gpio/gpio-wm831x.c | 21 + drivers/gpio/gpio-wm8994.c | 13 +++--- drivers/gpio/gpiolib.c | 41 +- drivers/pinctrl/bcm/pinctrl-bcm281xx.c | 6 +-- drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 2 +- drivers/pinctrl/bcm/pinctrl-ns2-mux.c| 6 +-- drivers/pinctrl/bcm/pinctrl-nsp-gpio.c | 6 +-- drivers/pinctrl/core.c | 28 drivers/pinctrl/intel/pinctrl-cherryview.c | 4 +- drivers/pinctrl/mediatek/pinctrl-mtk-common.c| 14 +- drivers/pinctrl/meson/pinctrl-meson.c| 2 - drivers/pinctrl/pinconf.c| 12 ++ drivers/pinctrl/pinconf.h| 9 drivers/pinctrl/pinctrl-amd.c| 14 +- drivers/pinctrl/pinctrl-da850-pupd.c | 2 - drivers/pinctrl/pinctrl-lpc18xx.c| 10 ++--- drivers/pinctrl/pinctrl-max77620.c | 2 +- drivers/pinctrl/pinctrl-palmas.c | 2 +- drivers/pinctrl/pinctrl-rockchip.c | 2 +- drivers/pinctrl/pinctrl-single.c | 2 +- drivers/pinctrl/pinctrl-sx150x.c | 55 drivers/pinctrl/sirf/pinctrl-atlas7.c| 3 +- drivers/pinctrl/sunxi/pinctrl-sunxi.c| 2 +- drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 4 +- drivers/pinctrl/vt8500/pinctrl-wmt.c | 2 +- drivers/rtc/rtc-omap.c | 2 +- drivers/staging/greybus/gpio.c | 15 --- drivers/usb/serial/cp210x.c | 13 +++--- include/linux/gpio/driver.h | 35 +++ include/linux/pinctrl/consumer.h | 6 +++ include/linux/pinctrl/pinconf-generic.h | 51 +++--- 47 files changed, 376 insertions(+), 254 deletions(-) -- 2.11.0
Re: [PATCH 1/2] perf symbols: use .gnu_debuglink as gdb does
On Thu, Jul 21, 2016 at 11:48:31AM +0200, Uwe Kleine-König wrote: > As documented in the comment gdb looks for debug files not only relative > to the binary's directory, but also in .debug and /usr/lib/debug/. > Let perf do the same thing. > > Signed-off-by: Uwe Kleine-König ping. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH] drivers: staging: rtl8188eu: include: statements using pointers enclosed in parantheses
On Wed, Jan 18, 2017 at 07:28:04AM +0530, Kartikey Singh wrote: > Macros with complex values enclosed in parentheses That does not make sense to me, does it to you? Please write changelogs that can be understood. thanks, greg k-h
Re: [PATCH net-next] net/sched: cls_flower: reduce fl_change stack size
Thu, Jan 19, 2017 at 10:45:31AM CET, a...@arndb.de wrote:
>The new ARP support has pushed the stack size over the edge on ARM,
>as there are two large objects on the stack in this function (mask
>and tb) and both have now grown a bit more:
>
>net/sched/cls_flower.c: In function 'fl_change':
>net/sched/cls_flower.c:928:1: error: the frame size of 1072 bytes is larger
>than 1024 bytes [-Werror=frame-larger-than=]
>
>We can solve this by dynamically allocating one or both of them.
>I first tried to do it just for the mask, but that only saved
>152 bytes on ARM, while this version just does it for the 'tb'
>array, bringing the stack size back down to 664 bytes.
>
>Fixes: 99d31326cbe6 ("net/sched: cls_flower: Support matching on ARP")
>Signed-off-by: Arnd Bergmann
Acked-by: Jiri Pirko
Re: [PATCH net-next v4] bridge: multicast to unicast
On 19/01/17 03:45, Linus Lüssing wrote: > From: Felix Fietkau > > Implements an optional, per bridge port flag and feature to deliver > multicast packets to any host on the according port via unicast > individually. This is done by copying the packet per host and > changing the multicast destination MAC to a unicast one accordingly. > > multicast-to-unicast works on top of the multicast snooping feature of > the bridge. Which means unicast copies are only delivered to hosts which > are interested in it and signalized this via IGMP/MLD reports > previously. > > This feature is intended for interface types which have a more reliable > and/or efficient way to deliver unicast packets than broadcast ones > (e.g. wifi). > > However, it should only be enabled on interfaces where no IGMPv2/MLDv1 > report suppression takes place. This feature is disabled by default. > > The initial patch and idea is from Felix Fietkau. > > Signed-off-by: Felix Fietkau > [linus.luess...@c0d3.blue: various bug + style fixes, commit message] > Signed-off-by: Linus Lüssing > > --- > > This feature is used and enabled by default in OpenWRT and LEDE for AP > interfaces for more than a year now to allow both a more robust multicast > delivery and multicast at higher rates (e.g. multicast streaming). > > In OpenWRT/LEDE the IGMP/MLD report suppression issue is overcome by > the network daemon enabling AP isolation and by that separating all STAs. > Delivery of STA-to-STA IP mulitcast is made possible again by > enabling and utilizing the bridge hairpin mode, which considers the > incoming port as a potential outgoing port, too. > > Hairpin-mode is performed after multicast snooping, therefore leading to > only deliver reports to STAs running a multicast router. > > Changes in v4: > * readd "From: Felix Fietkau [...]" (missed it again in v3) > > Changes in v3: > * fix an uninitialized variable bug introduced in br_multicast_flood() > in v2, found by kbuild test bot > > Changes in v2: > * netlink support (thanks Nik!) > * fixed switching between multicast_to_unicast on/off > -> even after toggling an already existing entry would > stale in its mode and would never be replaced > -> new extra check in br_port_group_equal) > * reduced checks in br_multicast_flood() from two to one > to address fast-path concerns (thanks Nik!) > * rev-christmas tree ordering (thanks Nik!) > * removed "net_bridge_port_group::unicast", using > ::flags instead (thanks Nik!) > * BR_MULTICAST_TO_UCAST -> BR_MULTICAST_TO_UNICAST > (BR_MULTICAST_FLAST_LEAVE has the same length anyway) > * simplified maybe_deliver_addr() > (no return, no "prev" paramater -> was a NOP anyway) > * added "From: Felix Fietkau [...]" > * added "Signed-off-by: Felix Fietkau [...]" > --- > include/linux/if_bridge.h| 1 + > include/uapi/linux/if_link.h | 1 + > net/bridge/br_forward.c | 37 - > net/bridge/br_mdb.c | 2 +- > net/bridge/br_multicast.c| 96 > > net/bridge/br_netlink.c | 5 +++ > net/bridge/br_private.h | 8 ++-- > net/bridge/br_sysfs_if.c | 2 + > 8 files changed, 121 insertions(+), 31 deletions(-) > Looks good to me, Reviewed-by: Nikolay Aleksandrov
[PATCH -improve] tools lib bpf: Fix map offsets in relocation
From: Joe Stringer
Commit 4708bbda5cb2 ("tools lib bpf: Fix maps resolution") attempted to
fix map resolution by identifying the number of symbols that point to
maps, and using this number to resolve each of the maps.
However, during relocation the original definition of the map size was
still in use. For up to two maps, the calculation was correct if there
was a small difference in size between the map definition in libbpf and
the one that the client library uses. However if the difference was
large, particularly if more than two maps were used in the BPF program,
the relocation would fail.
For example, when using a map definition with size 28, with three maps,
map relocation would count
(sym_offset / sizeof(struct bpf_map_def) => map_idx)
(0 / 16 => 0), ie map_idx = 0
(28 / 16 => 1), ie map_idx = 1
(56 / 16 => 3), ie map_idx = 3
So, libbpf reports:
libbpf: bpf relocation: map_idx 3 large than 2
Fix map relocation by checking the exact offset of maps when doing
relocation.
Fixes: 4708bbda5cb2 ("tools lib bpf: Fix maps resolution")
Signed-off-by: Joe Stringer
Signed-off-by: Wang Nan
[Allow different map size in an object]
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Arnaldo Carvalho de Melo
---
tools/lib/bpf/libbpf.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 84e6b35..671d5ad 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -779,7 +779,7 @@ static int
bpf_program__collect_reloc(struct bpf_program *prog,
size_t nr_maps, GElf_Shdr *shdr,
Elf_Data *data, Elf_Data *symbols,
- int maps_shndx)
+ int maps_shndx, struct bpf_map *maps)
{
int i, nrels;
@@ -829,7 +829,15 @@ bpf_program__collect_reloc(struct bpf_program *prog,
return -LIBBPF_ERRNO__RELOC;
}
- map_idx = sym.st_value / sizeof(struct bpf_map_def);
+ /* TODO: 'maps' is sorted. We can use bsearch to make it
faster. */
+ for (map_idx = 0; map_idx < nr_maps; map_idx++) {
+ if (maps[map_idx].offset == sym.st_value) {
+ pr_debug("relocation: find map %zd (%s) for
insn %u\n",
+map_idx, maps[map_idx].name, insn_idx);
+ break;
+ }
+ }
+
if (map_idx >= nr_maps) {
pr_warning("bpf relocation: map_idx %d large than %d\n",
(int)map_idx, (int)nr_maps - 1);
@@ -953,7 +961,8 @@ static int bpf_object__collect_reloc(struct bpf_object *obj)
err = bpf_program__collect_reloc(prog, nr_maps,
shdr, data,
obj->efile.symbols,
-obj->efile.maps_shndx);
+obj->efile.maps_shndx,
+obj->maps);
if (err)
return err;
}
--
2.10.1
