[PATCH 3/9] ARM: zynq: DT: Add DDRC node
Add the DDR controller to the Zynq devicetree.
Signed-off-by: Soren Brinkmann
---
arch/arm/boot/dts/zynq-7000.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 6cc83d4c6c76..587cadcf7001 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -146,6 +146,11 @@
cache-level = <2>;
};
+ memory-controller@f8006000 {
+ compatible = "xlnx,zynq-ddrc-a05";
+ reg = <0xf8006000 0x1000>;
+ } ;
+
uart0: serial@e000 {
compatible = "xlnx,xuartps", "cdns,uart-r1p8";
status = "disabled";
--
2.0.1.1.gfbfc394
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/9] Zynq PM updates
Hi, I'm working on some PM-related updates and suspend for Zynq (for the interested, a branch with all patches is found here: https://github.com/sorenb-xlnx/linux-xlnx/commits/suspend). This series consists of the rather unproblematic parts that affect Zynq only and have no further dependencies. It's a little bit of clean up (thanks to Daniel too) and enabling a couple of the HW's power saving features. Thanks, Sören Daniel Lezcano (2): ARM: zynq: Remove invalidate cache for cpu die ARM: zynq: cpuidle: Remove pointless code Soren Brinkmann (7): ARM: zynq: PM: Enable A9 internal clock gating feature Documentation: devicetree: Add binding for Synopsys DDR controller ARM: zynq: DT: Add DDRC node ARM: zynq: PM: Enable DDR self-refresh and clock stop ARM: zynq: Synchronise zynq_cpu_die/kill ARM: zynq: Remove hotplug.c ARM: zynq: Rename 'zynq_platform_cpu_die' .../bindings/memory-controllers/synopsys.txt | 11 +++ arch/arm/boot/dts/zynq-7000.dtsi | 5 ++ arch/arm/mach-zynq/Makefile| 3 +- arch/arm/mach-zynq/common.c| 7 ++ arch/arm/mach-zynq/common.h| 18 - arch/arm/mach-zynq/hotplug.c | 47 +--- arch/arm/mach-zynq/platsmp.c | 35 - arch/arm/mach-zynq/pm.c| 84 ++ arch/arm/mach-zynq/slcr.c | 43 ++- drivers/cpuidle/cpuidle-zynq.c | 10 +-- 10 files changed, 202 insertions(+), 61 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/synopsys.txt create mode 100644 arch/arm/mach-zynq/pm.c -- 2.0.1.1.gfbfc394 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Automatically pull missing FW files
On Wed, 2014-08-20 at 12:21 -0700, Tadeusz Struk wrote: > Hi David, > On 08/20/2014 11:34 AM, David Woodhouse wrote: > > I'm not sure I understand. Precisely what fails? > > I clone a subsystem, configure it to use > CONFIG_EXTRA_FIRMWARE="qat_895xcc.bin", type make && make install and get: > > MK_FW firmware/qat_895xxc.bin.gen.S > make[1]: *** No rule to make target `firmware/qat_895xxc.bin', needed by > `firmware/qat_895xxc.bin.gen.o'. Stop. Can't you already just use CONFIG_EXTRA_FIRMWARE_DIR ? > Yes, if you use udev helper. When you want to compile in the blobs to > your kernel it is needed in build time, right? Yes. But seriously: don't do that. Let firmware get loaded from userspace the normal way. Don't build kernel images that you can't distribute because they include non-GPL parts. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: nohz fail (was: perf related boot hang.)
I've also just hit what seems to be the same panic in 3.17-rc1 (ignore the 1 local patch, it's an unrelated change in a comment) twice in less than 1 hour. Hitting this twice in a short amount of time seems to be proof that the 3.17 merge window made it trigger more often. Both times I was running a grep over a Firefox build tree which was taking a long time. The stacktraces are slightly different but both have the "cancel timer from a timer, followed by nmi" pattern. Pictures of the 2 stacktraces: https://drive.google.com/file/d/0B_fRjDygGZSNY0RIc2dyYTExTjg/edit?usp=sharing https://drive.google.com/file/d/0B_fRjDygGZSNS1pSWFkteURrOTQ/edit?usp=sharing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/3] pinctrl: qcom: Add APQ8084 pinctrl support
On Tue, Aug 19, 2014 at 08:22:14PM +0300, Georgi Djakov wrote:
> This patch adds support for the TLMM (Top-Level Mode Mux) block found
> in the APQ8084 platform.
Comment in-line
> + PINCTRL_PIN(134, "GPIO_134"),
> + PINCTRL_PIN(135, "GPIO_135"),
> + PINCTRL_PIN(136, "GPIO_136"),
> + PINCTRL_PIN(137, "GPIO_137"),
> + PINCTRL_PIN(138, "GPIO_138"),
> + PINCTRL_PIN(139, "GPIO_139"),
> + PINCTRL_PIN(140, "GPIO_140"),
> + PINCTRL_PIN(141, "GPIO_141"),
> + PINCTRL_PIN(142, "GPIO_142"),
Add in the missing pins
+ PINCTRL_PIN(142, "GPIO_143"),
+ PINCTRL_PIN(142, "GPIO_144"),
+ PINCTRL_PIN(142, "GPIO_145"),
+ PINCTRL_PIN(142, "GPIO_146"),
> +
> + PINCTRL_PIN(143, "SDC1_CLK"),
> + PINCTRL_PIN(144, "SDC1_CMD"),
> + PINCTRL_PIN(145, "SDC1_DATA"),
> + PINCTRL_PIN(146, "SDC2_CLK"),
> + PINCTRL_PIN(147, "SDC2_CMD"),
> + PINCTRL_PIN(148, "SDC2_DATA"),
Shift down to accomodate 4 pins
+ PINCTRL_PIN(147, "SDC1_CLK"),
+ PINCTRL_PIN(148, "SDC1_CMD"),
+ PINCTRL_PIN(149, "SDC1_DATA"),
+ PINCTRL_PIN(150, "SDC2_CLK"),
+ PINCTRL_PIN(151, "SDC2_CMD"),
+ PINCTRL_PIN(152, "SDC2_DATA"),
> +};
> +
> +#define DECLARE_APQ_GPIO_PINS(pin) static const unsigned int
> gpio##pin##_pins[] = { pin }
> +
> +DECLARE_APQ_GPIO_PINS(138);
> +DECLARE_APQ_GPIO_PINS(139);
> +DECLARE_APQ_GPIO_PINS(140);
> +DECLARE_APQ_GPIO_PINS(141);
> +DECLARE_APQ_GPIO_PINS(142);
+DECLARE_APQ_GPIO_PINS(143);
+DECLARE_APQ_GPIO_PINS(144);
+DECLARE_APQ_GPIO_PINS(145);
+DECLARE_APQ_GPIO_PINS(146);
> +
> +static const unsigned int sdc1_clk_pins[] = { 143 };
> +static const unsigned int sdc1_cmd_pins[] = { 144 };
> +static const unsigned int sdc1_data_pins[] = { 145 };
> +static const unsigned int sdc2_clk_pins[] = { 146 };
> +static const unsigned int sdc2_cmd_pins[] = { 147 };
> +static const unsigned int sdc2_data_pins[] = { 148 };
+static const unsigned int sdc1_clk_pins[] = { 147 };
+static const unsigned int sdc1_cmd_pins[] = { 148 };
+static const unsigned int sdc1_data_pins[] = { 149 };
+static const unsigned int sdc2_clk_pins[] = { 150 };
+static const unsigned int sdc2_cmd_pins[] = { 151 };
+static const unsigned int sdc2_data_pins[] = { 152 };
> +
> +#define FUNCTION(fname) \
> + [APQ_MUX_##fname] = { \
> + .name = #fname, \
> + "gpio64", "gpio65", "gpio66", "gpio67", "gpio68", "gpio69", "gpio70",
> + "gpio71", "gpio72", "gpio73", "gpio74", "gpio75", "gpio76", "gpio77",
> + "gpio78", "gpio79", "gpio80", "gpio81", "gpio82", "gpio83", "gpio84",
> + "gpio85", "gpio86", "gpio87", "gpio88", "gpio89", "gpio90", "gpio91",
> + "gpio92", "gpio93", "gpio94", "gpio95", "gpio96", "gpio97", "gpio98",
> + "gpio99", "gpio100", "gpio101", "gpio102", "gpio103", "gpio104",
> + "gpio105", "gpio106", "gpio107", "gpio108", "gpio109", "gpio110",
> + "gpio111", "gpio112", "gpio113", "gpio114", "gpio115", "gpio116",
> + "gpio117", "gpio118", "gpio119", "gpio120", "gpio121", "gpio122",
> + "gpio123", "gpio124", "gpio125", "gpio126", "gpio127", "gpio128",
> + "gpio129", "gpio130", "gpio131", "gpio132", "gpio133", "gpio134",
> + "gpio135", "gpio136", "gpio137", "gpio138", "gpio139", "gpio140",
> + "gpio141", "gpio142"
Add in extra pins
> + FUNCTION(cam_mclk3),
> + FUNCTION(cci_async),
> + FUNCTION(cci_async_in0),
> + FUNCTION(cci_i2c),
split into cci_i2c0 and cci_i2c1
> + FUNCTION(cci_timer0),
> + FUNCTION(cci_timer1),
> + FUNCTION(cci_timer2),
> + FUNCTION(cci_timer3),
> + FUNCTION(cci_timer4),
> + FUNCTION(dll_sdc10),
> + FUNCTION(dll_sdc11),
> + FUNCTION(dll_sdc20),
> + FUNCTION(dll_sdc21),
> + FUNCTION(edp_hot),
change this to edp_hpd
> + FUNCTION(edp_tpa),
> + FUNCTION(gcc_gp1),
> + FUNCTION(gcc_gp1_clk_b),
this isnt used
> + FUNCTION(gcc_gp2),
> + FUNCTION(gcc_gp2_clk_b),
this isnt used
> + FUNCTION(gcc_gp3),
> + FUNCTION(gcc_gp3_clk_b),
this isnt used
> + FUNCTION(gcc_obt),
> + FUNCTION(gcc_vtt),
> + FUNCTION(gp_mn),
> + FUNCTION(gp_pdm),
> + FUNCTION(gp_pdm_0a),
> + FUNCTION(gp_pdm_2a),
> + FUNCTION(gp_pdm_1b),
> + FUNCTION(gp_pdm_2b),
Drop a and b, there is no collision on the same pin, so unnecessary
> + FUNCTION(gp0_clk),
> + FUNCTION(gp1_clk),
> + FUNCTION(gpio),
> + FUNCTION(hdmi_cec),
> + FUNCTION(hdmi_ddc),
> + FUNCTION(hdmi_dtest),
> + FUNCTION(hdmi_hot),
change this to hdmi_hpd
> + FUNCTION(hdmi_rcv),
> + FUNCTION(hsic),
> + FUNCTION(ldo_en),
> + FUNCTION(ldo_update),
> + FUNCTION(mdp_vsync),
> + FUNCTION(pci_e0),
> + FUNCTION(pci_e0_rst),
> + FUNCTION(pci_e1),
> + FUNCTION(pci_e1_rst),
> + FUNCTION(pci_e1_rst_n),
> + FUNCTION(pci_e1_clkreq_n),
> + FUNCTION(pri_mi2s),
> +
Re: [PATCH v1 1/3] pinctrl: qcom: Add APQ8084 pinctrl support
On 20.08.14 18:42, Andy Gross wrote: > On Tue, Aug 19, 2014 at 09:39:30PM -0700, Bjorn Andersson wrote: >> On Tue 19 Aug 10:22 PDT 2014, Georgi Djakov wrote: >> >>> This patch adds support for the TLMM (Top-Level Mode Mux) block found >>> in the APQ8084 platform. >>> >> [...] >>> + >>> +#define NUM_GPIO_PINGROUPS 143 >>> + >> >> I think this looks good overall, but in my APQ8084 documentation >> (80-NG550-2X Rev. B) there are 147 (0..146) gpio pins in the TLMM block. >> >> Any suggestion to why there's a discrepancy? >> > > We have some discrepancies internally on the documentation. However, in this > case I'd expect the OEM documentation to be correct. So this needs to change > to > bjorn's version, as it appears to be the correct version. > > I have no idea why some pins are missing. > Thank you for reviewing, Bjorn and Andy. I'll update and submit v2. BR, Georgi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loading initrd above 4G causes freeze on boot
[ Pulling in EDK2 folks for help ]
On Wed, 20 Aug, at 08:53:45PM, Michael Brown wrote:
> On 20/08/14 20:05, Mantas Mikulėnas wrote:
> >
> >I experimented with some things (like setting chunk size to a few kB
> >to see if it hangs earlier or only at the very end; etc.), and finally
> >found out that it stops freezing if I pad the initrd file to a
> >multiple of 512 bytes :/ That is, 5684268 bytes will freeze, 5684736
> >bytes will not.
> >
> >...In other words, seems like it cannot read chunks that aren't
> >multiples of 512 into a location above 4 GB. Or something like that...
>
> I haven't been following this thread closely, but that immediately
> sounds like a problem within the EFI_DISK_IO_PROTOCOL implementation
> (which is responsible for handling smaller-than-block-sized reads).
> Looking at the EDK2 implementation in
> MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIo.c, the memory
> management does appear to be somewhat inventive. In particular,
> there's a frequent pattern in DiskIoCreateSubtaskList() equivalent
> to:
>
> if ( blocking_io ) {
> buffer = some_static_buffer;
> } else {
> buffer = malloc ( len );
> if ( ! buffer )
> goto single_shared_error_label;
> }
> ... do not record whether or not buffer was dynamically allocated ...
> ... use buffer as part of an asynchronous I/O operation ...
> ... eventually choose whether or not to free buffer, and hope the
> choice is correct ...
>
> It's not at all obvious that memory is freed correctly, especially
> under some of the error paths within that code.
>
> I can't immediately see anything that should fail with a pointer
> above 4G, but I wouldn't be surprised to find a path that causes a
> double free or similar error.
Guys, the original thread starts here,
http://article.gmane.org/gmane.linux.kernel.efi/4424
Basically, reading into a buffer above 0x using
EFI_FILE_PROTOCOL causes Mantas' machine to crash, irrespective of the
size of the read.
Is this a known issue? Perhaps here be dragons?
Halp?
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: remove outdated references to the linux-next wiki
The linux-next wiki at http://linux.f-seidel.de/linux-next/pmwiki has been gone for several months now. Signed-off-by: Jim Davis --- Documentation/HOWTO| 1 - Documentation/development-process/2.Process| 4 Documentation/development-process/8.Conclusion | 4 3 files changed, 9 deletions(-) diff --git a/Documentation/HOWTO b/Documentation/HOWTO index 57cf5efb044d..93aa8604630e 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO @@ -324,7 +324,6 @@ tree, they need to be integration-tested. For this purpose, a special testing repository exists into which virtually all subsystem trees are pulled on an almost daily basis: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git - http://linux.f-seidel.de/linux-next/pmwiki/ This way, the -next kernel gives a summary outlook onto what will be expected to go into the mainline kernel at the next merge period. diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process index 2e0617936e8f..c24e156a6118 100644 --- a/Documentation/development-process/2.Process +++ b/Documentation/development-process/2.Process @@ -289,10 +289,6 @@ lists when they are assembled; they can be downloaded from: http://www.kernel.org/pub/linux/kernel/next/ -Some information about linux-next has been gathered at: - - http://linux.f-seidel.de/linux-next/pmwiki/ - Linux-next has become an integral part of the kernel development process; all patches merged during a given merge window should really have found their way into linux-next some time before the merge window opens. diff --git a/Documentation/development-process/8.Conclusion b/Documentation/development-process/8.Conclusion index 1990ab4b4949..caef69022e9c 100644 --- a/Documentation/development-process/8.Conclusion +++ b/Documentation/development-process/8.Conclusion @@ -22,10 +22,6 @@ Beyond that, a valuable resource for kernel developers is: http://kernelnewbies.org/ -Information about the linux-next tree gathers at: - - http://linux.f-seidel.de/linux-next/pmwiki/ - And, of course, one should not forget http://kernel.org/, the definitive location for kernel release information. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Handling commit change logs
On 08/20/2014 02:02 PM, Andreas Färber wrote: Hi Javier, Am 20.08.2014 17:39, schrieb Javier Martinez Canillas: As you already know when you apply a patch with git am, everything that is between a line with 3 dashes line (---) and the actual diff is omitted since that is where the generated diffstat is placed by git format-patch. We usually rely on that behavior to put there the history of a patch or any information that we think that is useful for reviewers but is not suitable to end in the commit message. Now that means that you have to generate the patch and then manually edit it to add the history there. But since git am omits any text between the first "---" and the diff, it means that you can add a "---" on your actual commit message and anything that follows will be discarded by git am, that way you can maintain your history on your commit message which is way less tedious than manually editing patches. So the second "---" from Tuomas patch is actually the one generated by git format-patch but that gets discarded by git am just like any other text so it causes no harm when other apply the patches. If this not the correct workflow and you have a better way to manage this, I would love to know about it. One drawback of having --- in the commit message is that you can't cherry-pick but really need to use git-am for it to be stripped. You can, you just have to either: * Pass -e to git cherry-pick so you get to edit the patch description, * Run "git commit --amend" right afterwards, ... and then delete everything starting at ---. I do this reasonably often on my own patches; I send them to the list, get them reviewed, and then cherry-pick them into the Tegra maintainer tree rather than saving them from the email client and running git am. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] spi: Remove unused definitions
On Wed 2014-08-06 14:27:20, valdis.kletni...@vt.edu wrote: > On Wed, 06 Aug 2014 13:53:17 -0400, Nick Krause said: > > Remove unused definition which cause the following warnings > > > > drivers/spi/spi-omap-100k.c:73:0: warning: "WRITE" redefined [enabled by > > default] > > include/linux/fs.h:193:0: note: this is the location of the previous > > definition > > drivers/spi/spi-omap-100k.c:74:0: warning: "READ" redefined [enabled by > > default] > > include/linux/fs.h:192:0: note: this is the location of the previous > > definition > > > -#define WRITE 0 > > -#define READ 1 > > NAK. Full stop. These are potentially used in an inner macro someplace, and > by > removing these, the conflicting values from fs.h will be used instead. > > #define READ0 > #define WRITE RW_MASK > > So if there *is* a use in an inner macro, you just screwed the pooch > and introduced a bug in this "clean up" - somebody will be expecting to see > a 0 for a READ, and will receive a 1 instead. This can't end well. Actually.. having macros called READ and WRITE in fs.h is already something I'd say can't end well. Can we rename those? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: remove obsolete comment in uapi/e820.h
On Mon, 2014-05-19 at 11:50 -0600, Ross Zwisler wrote: > A comment introduced by this commit: > > 028b785888c5 x86 boot: extend some internal memory map arrays to handle > larger EFI input > > had to do with some nested preprocessor directives. The directives were > split into separate files by this commit: > > af170c5061dd UAPI: (Scripted) Disintegrate arch/x86/include/asm > > The comment explaining their interaction was retained and is now present > in arch/x86/include/uapi/asm/e820.h. This comment is no longer correct, > so delete it. > > Signed-off-by: Ross Zwisler > > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: x...@kernel.org > --- > arch/x86/include/uapi/asm/e820.h | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/arch/x86/include/uapi/asm/e820.h > b/arch/x86/include/uapi/asm/e820.h > index bbae024..d993e33 100644 > --- a/arch/x86/include/uapi/asm/e820.h > +++ b/arch/x86/include/uapi/asm/e820.h > @@ -21,11 +21,6 @@ > * this size. > */ > > -/* > - * Odd: 'make headers_check' complains about numa.h if I try > - * to collapse the next two #ifdef lines to a single line: > - * #if defined(__KERNEL__) && defined(CONFIG_EFI) > - */ > #ifndef __KERNEL__ > #define E820_X_MAX E820MAX > #endif Ping. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/5] ARM: tegra: Add thermal reset (thermtrip) support to PMC
On 08/13/2014 06:41 AM, Mikko Perttunen wrote: This adds a device tree controlled option to enable PMC-based thermal reset in overheating situations. Thermtrip is supported on Tegra30, Tegra114 and Tegra124. The thermal reset only works when the thermal sensors are calibrated, so a soctherm driver is also required. If calibration is required, presumably the soctherm must initialize before this thermtrip code can initialize, or this thermtrip logic might be triggered by uncalibrated sensors? If so, then there needs to be some explicit mechanism to force the two drivers into probing in the right order. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] of: Add descriptions of thermtrip properties to Tegra PMC bindings
On 08/13/2014 06:41 AM, Mikko Perttunen wrote: Hardware-triggered thermal reset requires configuring the I2C reset procedure. This configuration is read from the device tree, so document the relevant properties in the binding documentation. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt +Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'): +- nvidia,pinmux-id : Pinmux used by the hardware when issuing poweroff command. + Defaults to 0. We should either enumerate the legal values and what they mean, or include a reference to the TRM section which explains the legal values. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc: booke_wdt: Fix build error as a module
On Wed, Aug 20, 2014 at 4:10 PM, Guenter Roeck wrote:
> On Wed, Aug 20, 2014 at 03:26:46PM -0400, Pranith Kumar wrote:
>> Building booke_wdt fails when trying to build as a module as there is no
>> early_param() in module. Fix by using module_param() instead of
>> early_param().
>>
>> Signed-off-by: Pranith Kumar
>> CC: Guenter Roeck
>
> Looks good as far as I can see. One question though:
>
>> +MODULE_ALIAS("booke_wdt");
>
> Is this necessary ? If yes, shouldn't it be a separate patch to be applied
> to -stable ?
Suppose this was actually built as a module. How do you pass the
module parameters to this module? Only ways I know of are
./insmod booke_wdt booke_wdt_enabled=1 booke_wdt_period=3
or pass booke_wdt.booke_wdt_enabled=1 on the kernel boot params list.
So the alias is necessary to refer to this module to pass params.
About separate patch, I think it is only with conversion to
module_param() that we need this alias.
Am I missing something?
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] carl9170: Replace rcu_dereference() with rcu_access_pointer()
On Wednesday, August 20, 2014 08:32:11 PM Andreea Bernat wrote:
> On Mon, Aug 18, 2014 at 09:29:36PM +0200, Christian Lamparter wrote:
> > On Sunday, August 17, 2014 01:48:07 PM Andreea-Cristina Bernat wrote:
> > > The rcu_dereference() call is used directly in a condition.
> > > Since its return value is never dereferenced it is recommended to use
> > > "rcu_access_pointer()" instead of "rcu_dereference()".
> > > Therefore, this patch makes the replacement.
> > > [...]
> > > Signed-off-by: Andreea-Cristina Bernat
> > > ---
> > > drivers/net/wireless/ath/carl9170/main.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/wireless/ath/carl9170/main.c
> > > b/drivers/net/wireless/ath/carl9170/main.c
> > > index f8ded84..12018ff 100644
> > > --- a/drivers/net/wireless/ath/carl9170/main.c
> > > +++ b/drivers/net/wireless/ath/carl9170/main.c
> > > @@ -1431,7 +1431,7 @@ static int carl9170_op_ampdu_action(struct
> > > ieee80211_hw *hw,
> > > return -EOPNOTSUPP;
> > >
> > > rcu_read_lock();
> > > - if (rcu_dereference(sta_info->agg[tid])) {
> > > + if (rcu_access_pointer(sta_info->agg[tid])) {
> > > rcu_read_unlock();
> > > return -EBUSY;
> > > }
> >
> > There's more. The check does not do a whole lot. I think *it* [the check]
> > and the
> > rcu_read_[un]lock [and the return -EBUSY] can be removed completely from the
> > IEEE80211_AMPDU_TX_START code-path in carl9170_op_ampdu_action.
> >
> > It would be awesome, if you could you make a patch which removes this
> > unneeded cosmic-ray-protection check :-) .
>
> Could you tell me why you think that those lines have to be removed?
The carl9170_op_ampdu_action callback is used exclusively by the mac80211
framework to notify the driver about setup and tear down of TX and RX
aggregation sessions. Hence, mac80211 takes great care of performing
sanity checks and properly serializing calls to the driver's ampdu_action
callback.
Specifically mac80211 already prevents the START of an TX aggregation session,
if the aggregation session is already active [0]. Therefore the driver doesn't
need to perform a similar check as well. This is why:
- the expression (rcu_dereference(sta_info->agg[tid])) never evaluates to true
-> the -EBUSY exit path is "dead code"
And without the rcu_dereference(...) the rcu_read protection is not needed
either. So it can be removed for this case as well.
> I would like to fully understand this before I remove them.
Let me know if the explanation above answers sufficient :).
If not, I need some *pointers* to what needs further
explanation.
Regards
Christian
[0]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/5] of: Add nvidia,controller-id property to Tegra I2C bindings
On 08/13/2014 06:41 AM, Mikko Perttunen wrote: Sometimes, hardware blocks want to issue requests to devices connected to I2C buses by itself. In such case, the bus the target device resides on must be configured into a register. For this purpose, each I2C controller has a defined ID known by the hardware. Add a property for these IDs to the device tree bindings, so that drivers can know what ID to write to a hardware register when configuring a block that sends I2C messages autonomously. diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt +Optional properties: +- nvidia,controller-id: ID of controller when referred to in +hardware registers. I'd prefer to put this information into the thermal trip node, since this represents what ID the PMC uses to communicate with the I2C controller, and there's no absolute guarantee that multiple clients that communicate directly with an I2C controller would use the same numbering scheme. If that doesn't work, can be at least name this nvidia,pmc-controller-id or nvidia,id-in-pmc so that if there are different numbering schemes, there's a clear path to represent this in different properties without conflicting names? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Automatically pull missing FW files
On Wed, 20 Aug 2014 12:21:23 -0700, Tadeusz Struk said: > Hi David, > On 08/20/2014 11:34 AM, David Woodhouse wrote: > > I'm not sure I understand. Precisely what fails? > > I clone a subsystem, configure it to use > CONFIG_EXTRA_FIRMWARE="qat_895xcc.bin", type make && make install and get: > > MK_FW firmware/qat_895xxc.bin.gen.S > make[1]: *** No rule to make target `firmware/qat_895xxc.bin', needed by > `firmware/qat_895xxc.bin.gen.o'. Stop. Is this what you were looking for? config EXTRA_FIRMWARE_DIR string "Firmware blobs root directory" depends on EXTRA_FIRMWARE != "" default "firmware" help This option controls the directory in which the kernel build system looks for the firmware files listed in the EXTRA_FIRMWARE option. The default is firmware/ in the kernel source tree, but by changing this option you can point it elsewhere, such as /lib/firmware/ or some other directory containing the firmware files. pgp8mAFfTEg_V.pgp Description: PGP signature
Re: [PATCH 6/8] drm: use for_each_endpoint_of_node macro in drm_of_find_possible_crtcs
Hi Philipp,
Thank you for the patch.
On Tuesday 19 August 2014 15:02:44 Philipp Zabel wrote:
> Using the for_each_... macro should make the code a bit shorter and
> easier to read.
>
> Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_of.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 16150a0..024fa77 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -46,11 +46,7 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device
> *dev, struct device_node *remote_port, *ep = NULL;
> uint32_t possible_crtcs = 0;
>
> - do {
> - ep = of_graph_get_next_endpoint(port, ep);
> - if (!ep)
> - break;
> -
> + for_each_endpoint_of_node(port, ep) {
> remote_port = of_graph_get_remote_port(ep);
> if (!remote_port) {
> of_node_put(ep);
> @@ -60,7 +56,7 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device
> *dev, possible_crtcs |= drm_crtc_port_mask(dev, remote_port);
>
> of_node_put(remote_port);
> - } while (1);
> + }
>
> return possible_crtcs;
> }
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] of: Add descriptions of thermtrip properties to Tegra PMC bindings
On 08/13/2014 06:41 AM, Mikko Perttunen wrote: Hardware-triggered thermal reset requires configuring the I2C reset procedure. This configuration is read from the device tree, so document the relevant properties in the binding documentation. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt +Hardware-triggered thermal reset: +On Tegra30, Tegra114 and Tegra124, if the 'i2c-thermtrip' subnode exists, +hardware-triggered thermal reset will be enabled. "will be enabled" sounds like SW behaviour, whereas DT is suppose to describe HW, and leave SW to define its own behaviour. I would suggest: Optional sub-nodes: i2c-thermtrip: Describes how to power off the system in the event of a thermal emergency. +Required properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'): Simpler might be: Required properties for i2c-thermtrip node: +- nvidia,pmu : Phandle to power management unit / PMIC handling poweroff +- nvidia,reg-addr : I2C register address to write poweroff command to +- nvidia,reg-data : Poweroff command to write to PMU Why are both the PMU/PMIC phandle and the register address/data required? I thought the purpose of having the phandle was to allow the register address and data to be queried from the PMU/PMIC driver. To me, it seems much simpler to get rid of the phandle and just hard-code the I2C bus number, address, and data into this node, rather than having to go query it from the PMU/PMIC driver, then find the I2C controller, then query it for its ID (and hope that all HW modules that talk to I2C controllers directly use the same numbering scheme...) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] of: Add of_graph_get_port_by_id function
Hi Philipp,
Thank you for the patch.
On Tuesday 19 August 2014 15:02:43 Philipp Zabel wrote:
> This patch adds a function to get a port device tree node by port id,
> or reg property value.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/of/base.c| 30 ++
> include/linux/of_graph.h | 7 +++
> 2 files changed, 37 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index a49b5628..6044c15 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2053,6 +2053,36 @@ int of_graph_parse_endpoint(const struct device_node
> *node, EXPORT_SYMBOL(of_graph_parse_endpoint);
>
> /**
> + * of_graph_get_port_by_id() - get the port matching a given id
> + * @parent: pointer to the parent device node
> + * @id: id of the port
> + *
> + * Return: A 'port' node pointer with refcount incremented.The caller
Missing space before "The".
> + * has to use of_node_put() on it when done.
> + */
> +struct device_node *of_graph_get_port_by_id(struct device_node *node, int
> id)
How about making id and unsigned int, as it can't be negative ?
> +{
> + struct device_node *port = NULL;
> + int port_id;
> +
> + while (true) {
> + port = of_get_next_child(node, port);
> + if (!port)
> + return NULL;
> + if (of_node_cmp(port->name, "port") != 0)
> + continue;
> + if (of_property_read_u32(port, "reg", _id)) {
> + if (!id)
> + return port;
> + } else {
> + if (id == port_id)
> + return port;
> + }
Nitpicking here, I would have written this
int port_id = 0;
port = of_get_next_child(node, port);
if (!port)
return NULL;
if (of_node_cmp(port->name, "port") != 0)
continue;
of_property_read_u32(port, "reg", _id);
if (id == port_id)
return port;
That saves 8 bytes with my ARM cross-compiler (at the expense of using two
extra local registers).
Please free to ignore this is you find your code layout easier to read.
> + }
> +}
> +EXPORT_SYMBOL(of_graph_get_port_by_id);
> +
> +/**
> * of_graph_get_next_endpoint() - get next endpoint node
> * @parent: pointer to the parent device node
> * @prev: previous endpoint node, or NULL to get first
> diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
> index 2890a4c..24ceb4b 100644
> --- a/include/linux/of_graph.h
> +++ b/include/linux/of_graph.h
> @@ -33,6 +33,7 @@ struct of_endpoint {
> #ifdef CONFIG_OF
> int of_graph_parse_endpoint(const struct device_node *node,
> struct of_endpoint *endpoint);
> +struct device_node *of_graph_get_port_by_id(struct device_node *node, int
> id); struct device_node *of_graph_get_next_endpoint(const struct
> device_node *parent, struct device_node *previous);
> struct device_node *of_graph_get_remote_port_parent(
> @@ -46,6 +47,12 @@ static inline int of_graph_parse_endpoint(const struct
> device_node *node, return -ENOSYS;
> }
>
> +static inline struct device_node *of_graph_get_port_by_id(
> + struct device_node *node, int id)
> +{
> + return NULL;
> +}
> +
> static inline struct device_node *of_graph_get_next_endpoint(
> const struct device_node *parent,
> struct device_node *previous)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc: booke_wdt: Fix build error as a module
On Wed, Aug 20, 2014 at 03:26:46PM -0400, Pranith Kumar wrote:
> Building booke_wdt fails when trying to build as a module as there is no
> early_param() in module. Fix by using module_param() instead of early_param().
>
> Signed-off-by: Pranith Kumar
> CC: Guenter Roeck
Looks good as far as I can see. One question though:
> +MODULE_ALIAS("booke_wdt");
Is this necessary ? If yes, shouldn't it be a separate patch to be applied
to -stable ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Handling commit change logs (was: [PATCH v3 13/15] cpufreq: Add cpufreq driver for Tegra124)
Hi Javier, Am 20.08.2014 17:39, schrieb Javier Martinez Canillas: > As you already know when you apply a patch with git am, everything > that is between a line with 3 dashes line (---) and the actual diff is > omitted since that is where the generated diffstat is placed by git > format-patch. > > We usually rely on that behavior to put there the history of a patch > or any information that we think that is useful for reviewers but is > not suitable to end in the commit message. Now that means that you > have to generate the patch and then manually edit it to add the > history there. > > But since git am omits any text between the first "---" and the diff, > it means that you can add a "---" on your actual commit message and > anything that follows will be discarded by git am, that way you can > maintain your history on your commit message which is way less tedious > than manually editing patches. > > So the second "---" from Tuomas patch is actually the one generated by > git format-patch but that gets discarded by git am just like any other > text so it causes no harm when other apply the patches. > > If this not the correct workflow and you have a better way to manage > this, I would love to know about it. One drawback of having --- in the commit message is that you can't cherry-pick but really need to use git-am for it to be stripped. I resorted to a scripted way of handling change logs: Per patch series I maintain a shell script that after git-format-patch essentially runs sed -i "/---/ r /dev/stdin" $OUTDIR/0001-*.patch
[PATCH] params: fix potential memory leak in add_sysfs_param()
Do not leak memory when attrs is non NULL and
krealloc() fails. Without temporary variable,
reference to it is lost.
Signed-off-by: Arjun Sreedharan
---
kernel/params.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/kernel/params.c b/kernel/params.c
index 34f5270..b69d683 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -594,7 +594,7 @@ static __modinit int add_sysfs_param(struct module_kobject
*mk,
const char *name)
{
struct module_param_attrs *new;
- struct attribute **attrs;
+ struct attribute **attrs, **new_attrs;
int err, num;
/* We don't bother calling this with invisible parameters. */
@@ -613,15 +613,12 @@ static __modinit int add_sysfs_param(struct
module_kobject *mk,
sizeof(*mk->mp) + sizeof(mk->mp->attrs[0]) * (num+1),
GFP_KERNEL);
if (!new) {
- kfree(attrs);
err = -ENOMEM;
goto fail;
}
- /* Despite looking like the typical realloc() bug, this is safe.
-* We *want* the old 'attrs' to be freed either way, and we'll store
-* the new one in the success case. */
- attrs = krealloc(attrs, sizeof(new->grp.attrs[0])*(num+2), GFP_KERNEL);
- if (!attrs) {
+
+ new_attrs = krealloc(attrs, sizeof(new->grp.attrs[0])*(num+2),
GFP_KERNEL);
+ if (!new_attrs) {
err = -ENOMEM;
goto fail_free_new;
}
@@ -629,9 +626,9 @@ static __modinit int add_sysfs_param(struct module_kobject
*mk,
/* Sysfs wants everything zeroed. */
memset(new, 0, sizeof(*new));
memset(>attrs[num], 0, sizeof(new->attrs[num]));
- memset([num], 0, sizeof(attrs[num]));
+ memset(_attrs[num], 0, sizeof(new_attrs[num]));
new->grp.name = "parameters";
- new->grp.attrs = attrs;
+ new->grp.attrs = new_attrs;
/* Tack new one on the end. */
sysfs_attr_init(>attrs[num].mattr.attr);
@@ -653,6 +650,7 @@ static __modinit int add_sysfs_param(struct module_kobject
*mk,
fail_free_new:
kfree(new);
fail:
+ kfree(attrs);
mk->mp = NULL;
return err;
}
--
1.8.1.msysgit.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] of: Add for_each_endpoint_of_node helper macro
Hi Philipp,
Thank you for the patch.
On Tuesday 19 August 2014 15:02:42 Philipp Zabel wrote:
> Note that while of_graph_get_next_endpoint decrements the reference count
> of the child node passed to it, of_node_put(child) still has to be called
> manually when breaking out of the loop.
I think this is important enough to be mentioned in a comment in of_graph.h.
> Signed-off-by: Philipp Zabel
> ---
> include/linux/of_graph.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
> index befef42..2890a4c 100644
> --- a/include/linux/of_graph.h
> +++ b/include/linux/of_graph.h
> @@ -26,6 +26,10 @@ struct of_endpoint {
> const struct device_node *local_node;
> };
>
> +#define for_each_endpoint_of_node(parent, child) \
> + for (child = of_graph_get_next_endpoint(parent, NULL); child != NULL; \
> + child = of_graph_get_next_endpoint(parent, child))
> +
> #ifdef CONFIG_OF
> int of_graph_parse_endpoint(const struct device_node *node,
> struct of_endpoint *endpoint);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] arm/smp: Absorb boot_secondary()
Hi Arnd,
On Wed, Aug 20, 2014 at 9:30 PM, Arnd Bergmann wrote:
> On Wednesday 20 August 2014, Geert Uytterhoeven wrote:
>>
>> Ping?
>>
>> On Wed, Jul 9, 2014 at 5:01 PM, Geert Uytterhoeven
>> wrote:
>> > After becoming a mandatory function, boot_secondary() is no longer used
>> > outside arch/arm/kernel/smp.c. Hence remove its public prototype, and,
>> > as suggested by Arnd, let it be absorbed by its single caller.
>> >
>> > Signed-off-by: Geert Uytterhoeven
>> > Acked-by: Arnd Bergmann
>
> I think you should add the patch to Russell's patch tracking system
> at http://www.arm.linux.org.uk/developer/patches to get it applied.
Thanks for the info!
Has anyone already written a "git-send-email"-compatible script to
submit patches there?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/104] 3.12.27-stable review
On Wed, Aug 20, 2014 at 09:54:59AM -0700, Guenter Roeck wrote:
> On Wed, Aug 20, 2014 at 01:43:51PM +0200, Jiri Slaby wrote:
> > This is the start of the stable review cycle for the 3.12.27 release.
> > There are 104 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri Aug 22 13:43:20 CEST 2014.
> > Anything received after that time might be too late.
> >
> Build results look good:
> total: 135 pass: 135 fail: 0
>
> qemu tests passed except for sparc64 which hangs during boot, both for SMP and
> non-SMP builds. I'll try to bisect as soon as I have a somewhat stable
> internet
> connection.
>
Bisect result:
# bad: [c07d9e5da83f1470ccc58d37fe222dab36dbca67] drivers/rtc/interface.c: fix
infinite loop in initializing the alarm
# good: [d83a3234d2e1e2a55e7f2430fc9ca29a9bd315e7] Linux 3.12.26
git bisect start 'HEAD' 'v3.12.26'
# bad: [0d543dade2be5f0ddb268c6d6ea0e86938e3bf42] sparc64: Add membar to
Niagara2 memcpy code.
git bisect bad 0d543dade2be5f0ddb268c6d6ea0e86938e3bf42
# good: [6e1af05639abfc6f1841e6bf8b5c8492971ed1f2] staging: vt6655: Fix Warning
on boot handle_irq_event_percpu.
git bisect good 6e1af05639abfc6f1841e6bf8b5c8492971ed1f2
# good: [6a25e8f778995cabb0cfe2acb3247e3b42dec35f] macvlan: Initialize
vlan_features to turn on offload support.
git bisect good 6a25e8f778995cabb0cfe2acb3247e3b42dec35f
# good: [bf42f839476f1f447ca696fbbab7e741861d9d7d] sparc64: Fix executable bit
testing in set_pmd_at() paths.
git bisect good bf42f839476f1f447ca696fbbab7e741861d9d7d
# bad: [6acda98c75b536deaba1bf21f93411fcc484fbb5] sparc64: Add basic
validations to {pud,pmd}_bad().
git bisect bad 6acda98c75b536deaba1bf21f93411fcc484fbb5
# good: [a91ce41d405b3cc59dec91a5a3235f9cbcf6] sparc64: Fix top-level fault
handling bugs.
git bisect good a91ce41d405b3cc59dec91a5a3235f9cbcf6
# first bad commit: [6acda98c75b536deaba1bf21f93411fcc484fbb5] sparc64: Add
basic validations to {pud,pmd}_bad().
Reverting the offending patch ('Add basic validations ...') fixes the problem.
There is a twist: The final kernel hangs during boot. Some of the interim
builds crash. I did not try to track down where it stops crashing and starts
hanging.
Adding Dave for additional input. I suspect there may be some missing patch,
but no idea where to even start looking.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Loading initrd above 4G causes freeze on boot
On 20/08/14 20:05, Mantas Mikulėnas wrote:
On Wed, Aug 20, 2014 at 8:05 PM, Matt Fleming wrote:
On Wed, 13 Aug, at 07:44:49PM, Matt Fleming wrote:
At this point, I think modifying the max address is the best way to
debug this further, and figure out what address causes the hang.
Mantas, did you manage to get to the bottom of this issue?
I experimented with some things (like setting chunk size to a few kB
to see if it hangs earlier or only at the very end; etc.), and finally
found out that it stops freezing if I pad the initrd file to a
multiple of 512 bytes :/ That is, 5684268 bytes will freeze, 5684736
bytes will not.
...In other words, seems like it cannot read chunks that aren't
multiples of 512 into a location above 4 GB. Or something like that...
I haven't been following this thread closely, but that immediately
sounds like a problem within the EFI_DISK_IO_PROTOCOL implementation
(which is responsible for handling smaller-than-block-sized reads).
Looking at the EDK2 implementation in
MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIo.c, the memory management
does appear to be somewhat inventive. In particular, there's a frequent
pattern in DiskIoCreateSubtaskList() equivalent to:
if ( blocking_io ) {
buffer = some_static_buffer;
} else {
buffer = malloc ( len );
if ( ! buffer )
goto single_shared_error_label;
}
... do not record whether or not buffer was dynamically allocated ...
... use buffer as part of an asynchronous I/O operation ...
... eventually choose whether or not to free buffer, and hope the
choice is correct ...
It's not at all obvious that memory is freed correctly, especially under
some of the error paths within that code.
I can't immediately see anything that should fail with a pointer above
4G, but I wouldn't be surprised to find a path that causes a double free
or similar error.
Apologies if I've missed something critical earlier in the thread,
making my ramblings are totally irrelevant.
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] usb: add support for Diolan DLN-2 devices
On Wednesday 20 August 2014, Daniel Baluta wrote: > From: Octavian Purdila > > This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO > Master Adapter DLN-2. Details about the device can be found here: > > https://www.diolan.com/i2c/i2c_interface.html. > > Information about the USB protocol can be found in the Programmer's > Reference Manual [1], see section 1.7. > > Because the hardware has a single transmit endpoint and a single > receive endpoint the communication between the various DLN2 drivers > and the hardware will be muxed/demuxed by this driver. > > The functional DLN2 drivers (i2c, GPIO, etc.) will have to register > themselves as DLN2 modules in order to send or receive data. > > Each DLN2 module will be identified by the handle field within the DLN2 > message header. If a DLN2 module issues multiple commands in parallel > they will be identified by the echo counter field in the message header. > > The DLN2 modules can use the dln2_transfer() function to issue a > command and wait for its response. They can also use an asynchronous > mode of operation, in which case a receive callback function is going > to be notified when messages for a specific handle are received. > > Because the hardware reserves handle 0 for GPIO events, the driver > also reserves handle 0. It will be allocated to a DLN2 module only if > it is explicitly requested. > > [1] https://www.diolan.com/downloads/dln-api-manual.pdf > > Signed-off-by: Octavian Purdila After a very brief review of the driver, I think this would be better handled as an MFD driver in drivers/mfd that creates child devices and has the high-level drivers get registered as platform_driver. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] thermal: Add Tegra SOCTHERM thermal management driver
On 08/06/2014 04:25 AM, Mikko Perttunen wrote:
This adds support for the Tegra SOCTHERM thermal sensing and management
system found in the Tegra124 system-on-chip. This initial driver supports
temperature polling for four thermal zones.
Since both the Tegra DT patches and this driver all rely on a new header
added by patch 1/4, I guess this whole series needs to be applied in one
branch. I think it makes sense to apply it to the Tegra since it's
likely to have more conflicts there and fewer in the thermal
maintainer's tree. It can be applied in a topic branch that can be
merged into the thermal maintainer's tree if required to resolve
conflicts there.
Rui, Eduardo, do you agree?
diff --git a/drivers/thermal/tegra_soctherm.c b/drivers/thermal/tegra_soctherm.c
+static struct of_device_id tegra_soctherm_of_match[] = {
+ { .compatible = "nvidia,tegra124-soctherm" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tegra_soctherm_of_match);
+
+static int thermctl_temp_offsets[] = {
+ SENSOR_TEMP1, SENSOR_TEMP2, SENSOR_TEMP1, SENSOR_TEMP2
+};
+
+static int thermctl_temp_shifts[] = {
+ 16, 16, 0, 0
+};
Can any/all of those be const?
I don't pretend to know anything about the soctherm HW, but I see no
gross issues in the code structure, so,
Acked-by: Stephen Warren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] modsign: lookup lines ending in .ko in .mod files
Bertrand Jacquin writes: > This does the same as commit ef591a5 (scripts/Makefile.modpost: error > in finding modules from .mod files), but for scripts/Makefile.modsign > > Maybe we should also apply to Makefile.modsign and Makefile.modinst > the change applied to Makefile.modpost by commit ea4054a (modpost: > handle huge numbers of modules) ? Probably, yes. Applied! Rusty. > > Reviewed-by: Willy Tarreau > Signed-off-by: Bertrand Jacquin > --- > scripts/Makefile.modsign | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/Makefile.modsign b/scripts/Makefile.modsign > index abfda62..b6ac708 100644 > --- a/scripts/Makefile.modsign > +++ b/scripts/Makefile.modsign > @@ -7,7 +7,7 @@ __modsign: > > include scripts/Kbuild.include > > -__modules := $(sort $(shell grep -h '\.ko' /dev/null $(wildcard > $(MODVERDIR)/*.mod))) > +__modules := $(sort $(shell grep -h '\.ko$$' /dev/null $(wildcard > $(MODVERDIR)/*.mod))) > modules := $(patsubst %.o,%.ko,$(wildcard $(__modules:.ko=.o))) > > PHONY += $(modules) > -- > 2.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] module: add support for unsafe, tainting parameters
Daniel Vetter writes:
> On Wed, Aug 13, 2014 at 10:25 PM, Rusty Russell wrote:
>> Jani Nikula writes:
>>> This is a generic version of Daniel's patch [1] letting us have unsafe
>>> module parameters (experimental, debugging, testing, etc.) that taint
>>> the kernel when set. Quoting Daniel,
>>
>> OK, I think the idea is fine, but we'll probably only want this for
>> a few types (eg. int and bool). So for the moment I prefer a more
>> naive approach.
>>
>> Does this work for you?
>
> Can you please discuss this with yourself from a few months back?
> We've done the general version since you suggested that just doing it
> for int is a bit lame ;-) And I actually agreed so asked Jani to look
> into that.
Don't listen to me, I'm an idiot!
Applied.
I've applied this cleanup on top, however.
Cheers,
Rusty.
Subject: param: check for tainting before calling set op.
This means every set op doesn't need to call it, and it can move into
params.c.
Signed-off-by: Rusty Russell
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 9531f9f9729e..593501996574 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -374,22 +374,6 @@ static inline void destroy_params(const struct
kernel_param *params,
#define __param_check(name, p, type) \
static inline type __always_unused *__check_##name(void) { return(p); }
-/**
- * param_check_unsafe - Warn and taint the kernel if setting dangerous options.
- *
- * This gets called from all the standard param setters, but can be used from
- * custom setters as well.
- */
-static inline void
-param_check_unsafe(const struct kernel_param *kp)
-{
- if (kp->flags & KERNEL_PARAM_FL_UNSAFE) {
- pr_warn("Setting dangerous option %s - tainting kernel\n",
- kp->name);
- add_taint(TAINT_USER, LOCKDEP_STILL_OK);
- }
-}
-
extern struct kernel_param_ops param_ops_byte;
extern int param_set_byte(const char *val, const struct kernel_param *kp);
extern int param_get_byte(char *buffer, const struct kernel_param *kp);
diff --git a/kernel/params.c b/kernel/params.c
index ad8d04563c3a..f3cc977d6a66 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -83,6 +83,15 @@ bool parameq(const char *a, const char *b)
return parameqn(a, b, strlen(a)+1);
}
+static void param_check_unsafe(const struct kernel_param *kp)
+{
+ if (kp->flags & KERNEL_PARAM_FL_UNSAFE) {
+ pr_warn("Setting dangerous option %s - tainting kernel\n",
+ kp->name);
+ add_taint(TAINT_USER, LOCKDEP_STILL_OK);
+ }
+}
+
static int parse_one(char *param,
char *val,
const char *doing,
@@ -109,6 +119,7 @@ static int parse_one(char *param,
pr_debug("handling %s with %p\n", param,
params[i].ops->set);
mutex_lock(_lock);
+ param_check_unsafe([i]);
err = params[i].ops->set(val, [i]);
mutex_unlock(_lock);
return err;
@@ -233,7 +244,6 @@ char *parse_args(const char *doing,
#define STANDARD_PARAM_DEF(name, type, format, strtolfn) \
int param_set_##name(const char *val, const struct kernel_param *kp) \
{ \
- param_check_unsafe(kp); \
return strtolfn(val, 0, (type *)kp->arg); \
} \
int param_get_##name(char *buffer, const struct kernel_param *kp) \
@@ -266,8 +276,6 @@ int param_set_charp(const char *val, const struct
kernel_param *kp)
return -ENOSPC;
}
- param_check_unsafe(kp);
-
maybe_kfree_parameter(*(char **)kp->arg);
/* This is a hack. We can't kmalloc in early boot, and we
@@ -305,8 +313,6 @@ EXPORT_SYMBOL(param_ops_charp);
/* Actually could be a bool or an int, for historical reasons. */
int param_set_bool(const char *val, const struct kernel_param *kp)
{
- param_check_unsafe(kp);
-
/* No equals means "set"... */
if (!val) val = "1";
@@ -336,8 +342,6 @@ int param_set_invbool(const char *val, const struct
kernel_param *kp)
bool boolval;
struct kernel_param dummy;
- param_check_unsafe(kp);
-
dummy.arg =
ret = param_set_bool(val, );
if (ret == 0)
@@ -364,8 +368,6 @@ int param_set_bint(const char *val, const struct
kernel_param *kp)
bool v;
int ret;
- param_check_unsafe(kp);
-
/* Match bool exactly, by re-using it. */
boolkp = *kp;
boolkp.arg =
@@ -485,8 +487,6 @@ int param_set_copystring(const char *val, const struct
kernel_param *kp)
{
const struct kparam_string *kps = kp->str;
- param_check_unsafe(kp);
Re: [PATCH 01/24] perf tools: Add a test for tracking with sched_switch
Em Fri, Aug 15, 2014 at 10:08:36PM +0300, Adrian Hunter escreveu:
> Add a test that checks that sched_switch events and
> tracking events can be recorded for a workload using the
> evsel->system_wide and evsel->tracking flags (respectively)
> with other events sometimes enabled or disabled.
Really nice exercise! Gives lots of evlist/evsel routines a good test,
checking for expected behaviour, really good, thanks.
One thing I noticed was that it uses parse_events() for creating events,
a perhaps simpler equivalent would be:
switch_evsel = perf_evsel__newtp("sched", "sched_switch");
And then go on, like you did, configuring whatever attribute one wants
to have set, like what you get from ":u", and the other things you
touched, like:
switch_evsel->system_wide = true;
switch_evsel->no_aux_samples = true;
switch_evsel->immediate = true;
And when the evsel is all set up, if dealing with evlists, like in this
case, just do a:
perf_evlist__add(evlist, switch_evsel);
Looks more natural than using parse_events(evlist, "sched:sched_switch");
To then infer that it must be the last entry at this point to retrieve
it using:
switch_evsel = perf_evlist__last(evlist);
But, for the current architecture, that should be just a clarification,
not a requirement for this specific test.
Applying!
- Arnaldo
> Signed-off-by: Adrian Hunter
> ---
> tools/perf/Makefile.perf | 1 +
> tools/perf/tests/builtin-test.c| 4 +
> tools/perf/tests/switch-tracking.c | 572
> +
> tools/perf/tests/tests.h | 1 +
> 4 files changed, 578 insertions(+)
> create mode 100644 tools/perf/tests/switch-tracking.c
>
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 1ea31e2..95e832b 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -425,6 +425,7 @@ endif
> endif
> LIB_OBJS += $(OUTPUT)tests/mmap-thread-lookup.o
> LIB_OBJS += $(OUTPUT)tests/thread-mg-share.o
> +LIB_OBJS += $(OUTPUT)tests/switch-tracking.o
>
> BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o
> BUILTIN_OBJS += $(OUTPUT)builtin-bench.o
> diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
> index 9948136..6a4145e 100644
> --- a/tools/perf/tests/builtin-test.c
> +++ b/tools/perf/tests/builtin-test.c
> @@ -154,6 +154,10 @@ static struct test {
> .func = test__hists_cumulate,
> },
> {
> + .desc = "Test tracking with sched_switch",
> + .func = test__switch_tracking,
> + },
> + {
> .func = NULL,
> },
> };
> diff --git a/tools/perf/tests/switch-tracking.c
> b/tools/perf/tests/switch-tracking.c
> new file mode 100644
> index 000..50c82d5
> --- /dev/null
> +++ b/tools/perf/tests/switch-tracking.c
> @@ -0,0 +1,572 @@
> +#include
> +#include
> +#include
> +#include
> +
> +#include "parse-events.h"
> +#include "evlist.h"
> +#include "evsel.h"
> +#include "thread_map.h"
> +#include "cpumap.h"
> +#include "tests.h"
> +
> +static int spin_sleep(void)
> +{
> + struct timeval start, now, diff, maxtime;
> + struct timespec ts;
> + int err, i;
> +
> + maxtime.tv_sec = 0;
> + maxtime.tv_usec = 5;
> +
> + err = gettimeofday(, NULL);
> + if (err)
> + return err;
> +
> + /* Spin for 50ms */
> + while (1) {
> + for (i = 0; i < 1000; i++)
> + barrier();
> +
> + err = gettimeofday(, NULL);
> + if (err)
> + return err;
> +
> + timersub(, , );
> + if (timercmp(, , > /* For checkpatch */))
> + break;
> + }
> +
> + ts.tv_nsec = 50 * 1000 * 1000;
> + ts.tv_sec = 0;
> +
> + /* Sleep for 50ms */
> + err = nanosleep(, NULL);
> + if (err == EINTR)
> + err = 0;
> +
> + return err;
> +}
> +
> +struct switch_tracking {
> + struct perf_evsel *switch_evsel;
> + struct perf_evsel *cycles_evsel;
> + pid_t *tids;
> + int nr_tids;
> + int comm_seen[4];
> + int cycles_before_comm_1;
> + int cycles_between_comm_2_and_comm_3;
> + int cycles_after_comm_4;
> +};
> +
> +static int check_comm(struct switch_tracking *switch_tracking,
> + union perf_event *event, const char *comm, int nr)
> +{
> + if (event->header.type == PERF_RECORD_COMM &&
> + (pid_t)event->comm.pid == getpid() &&
> + (pid_t)event->comm.tid == getpid() &&
> + strcmp(event->comm.comm, comm) == 0) {
> + if (switch_tracking->comm_seen[nr]) {
> + pr_debug("Duplicate comm event\n");
> + return -1;
> + }
> + switch_tracking->comm_seen[nr] = 1;
> + pr_debug3("comm event: %s nr: %d\n", event->comm.comm, nr);
> + return 1;
> + }
> + return 0;
> +}
> +
> +static int check_cpu(struct
Re: [PATCH 2/3] kbuild: handle module compression while running 'make modules_install'.
Bertrand Jacquin writes: > Since module-init-tools (gzip) and kmod (gzip and xz) support compressed > modules, it could be useful to include a support for compressing modules > right after having them installed. Doing this in kbuild instead of per > distro can permit to make this kind of usage more generic. > > This patch add a Kconfig entry to "Enable loadable module support" menu > and let you choose to compress using gzip (default) or xz. > > Both gzip and xz does not used any extra -[1-9] option since Andi Kleen > and Rusty Russell prove no gain is made using them. gzip is called with -n > argument to avoid storing original filename inside compressed file, that > way we can save some more bytes. > > On a v3.16 kernel, 'make allmodconfig' generated 4680 modules for a > total of 378MB (no strip, no sign, no compress), the following table > shows observed disk space gain based on the allmodconfig .config : > >| time| >+-+-+ >| manual .ko | make | size | percent >| compression | modules_install | | gain >+-+-+--+ > -| | 18.61s | 378M | > GZIP | 3m16s | 3m37s | 102M | 73.41% > XZ | 5m22s | 5m39s | 77M | 79.83% > > The gain for restricted environnement seems to be interesting while > uncompress can be time consuming but happens only while loading a module, > that is generally done only once. > > This is fully compatible with signed modules while the signed module is > compressed. module-init-tools or kmod handles decompression > and provide to other layer the uncompressed but signed payload. > > Reviewed-by: Willy Tarreau > Signed-off-by: Bertrand Jacquin Thanks, applied these two as well. They'll go in *next* merge window (ie. 3.18). Cheers. Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] modinst: wrap long lines in order to enhance cmd_modules_install
Jim Davis writes: > On Tue, Aug 19, 2014 at 11:57 AM, Bertrand Jacquin wrote: >> Note: shouldn't we use 'install -D $(2)/$@ $@' instead of mkdir >> and cp ? > > Will an install with -D in that sense always be available? That's not > a flag in the original (BSD) program, and I did find one SPARC system > -- admittedly an ancient one -- where the install program had a -D > option but it did something else. install isn't listed as a required > program in Documentation/Changes, for that matter. Yes, we don't count on install. And ISTR that install -D would try to change perms on directories in the path, which can fail if you don't own them and aren't root... Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] ARM: tegra: Add thermal trip points for Jetson TK1
On 08/06/2014 04:25 AM, Mikko Perttunen wrote:
This adds critical trip points to the Jetson TK1 device tree.
The device will do a controlled shutdown when either the CPU, GPU
or MEM thermal zone reaches 101 degrees Celsius.
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+ thermal-zones {
+ cpu {
+ trips {
...
+ };
+ };
thermal.txt states that a cooling-maps sub-node is mandatory. However,
it seems to be missing here. Is the DT binding documentation overly
strict, or do we need to add such a node here?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree
On 08/06/2014 04:25 AM, Mikko Perttunen wrote:
This adds the soctherm thermal sensing and management unit to the
Tegra124 device tree along with the four thermal zones corresponding
to the four thermal sensors provided by soctherm.
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
+ thermal-zones {
+ soctherm: soctherm@0,700e2000 {
cpus {
The sort order of these nodes is wrong; nodes with reg should be sorted
according to the reg value. Nodes without reg should be sorted
alpha-numerically. That would place soctherm after sdhci@0,700b0600, and
thermal-zones before timer.
soctherm isn't a generic node name but sounds more like an identity;
thermal-sensor sounds like a better node name (but the node label can
still be soctherm if you want; label names don't show up in the DT ABI).
If these are the only issues, they can probably be fixed manually when
applying the patches, assuming a Tegra maintainer does it - I wouldn't
want to burden anyone else with that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: pci: convert generic host controller to DT host bridge creation API
On Wednesday 20 August 2014, Liviu Dudau wrote: > That has been the general approach of my patchset up to v9. But, as Bjorn has > mentioned in his v8 review and I have put in my cover letter, the regular > aproach means that architectures that use pci_scan_root_bus() will have to > drop their one liner and replace it with the more verbose > of_create_pci_host_bridge() > followed by pci_scan_child_bus() and pci_bus_add_devices() (basically, the > content > of pci_scan_root_bus()). For those architectures it will lead to a net > increase of > lines of code. I'll try to get hold of Bjorn here and discuss it with him in person. I'd rather see a few extra lines in each driver than the complexity of callback funtions. > The patch for pci-host-generic.c is the first to use the callback setup > function, but > not the only one. My PCI host bridge driver for Juno has the same need, and > I'm betting > all other host bridge controllers will use it as it will be the only > opportunity to > finish the controller setup before we start scanning the child busses. I'm > trying to > balance ease of read vs ease of use here and it is the best version I've come > up with > so far. My main objection to the new approach is that it's different from most other subsystems doing the same thing. For a person reading the pci host driver implementation, when they are familiar with other device drivers, I think it's much clearer what is going on when smaller functions are called in sequence than to see one function passed into some other interface that you now have to read as well in order to understand when it gets called. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] of: Add bindings for nvidia,tegra124-soctherm
On 08/06/2014 04:25 AM, Mikko Perttunen wrote: This adds binding documentation and headers for the Tegra124 SOCTHERM device tree node. Acked-by: Stephen Warren -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/3] x86: Make page cache mode a real type
On Tue, 2014-08-19 at 15:25 +0200, jgr...@suse.com wrote:
> From: Juergen Gross
>
> At the moment there are a lot of places that handle setting or getting
> the page cache mode by treating the pgprot bits equal to the cache mode.
> This is only true because there are a lot of assumptions about the setup
> of the PAT MSR. Otherwise the cache type needs to get translated into
> pgprot bits and vice versa.
>
> This patch tries to prepare for that by introducing a seperate type
> for the cache mode and adding functions to translate between those and pgprot
> values.
>
> To avoid too much performance penalty the translation between cache mode
> and pgprot values is done via tables which contain the relevant information.
> Write-back cache mode is hard-wired to be 0, all other modes are configurable
> via those tables. For large pages there are translation functions as the
> PAT bit is located at different positions in the ptes of 4k and large pages.
Hi Juergen,
Thanks for driving this. As we talked before, the changes look good to
me. I will post a patchset to enable WT on top of your patchset once
this is settled a bit.
I have couples of minor comments below.
> diff --git a/arch/x86/include/asm/pgtable_types.h
> b/arch/x86/include/asm/pgtable_types.h
> index f216963..7685b34 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
:
> /* xwr */
> #define __P000 PAGE_NONE
> @@ -328,6 +331,55 @@ static inline pteval_t pte_flags(pte_t pte)
> #define pgprot_val(x)((x).pgprot)
> #define __pgprot(x) ((pgprot_t) { (x) } )
>
> +extern uint16_t __cachemode2pte_tbl[_PAGE_CACHE_MODE_NUM];
> +extern uint8_t __pte2cachemode_tbl[8];
> +
> +#define __pte2cm_idx(cb) \
> + cb) >> (_PAGE_BIT_PAT - 2)) & 4) | \
> + (((cb) >> (_PAGE_BIT_PCD - 1)) & 2) | \
> + (((cb) >> _PAGE_BIT_PWT) & 1))
> +
> +static inline unsigned long protval_cachemode(enum page_cache_mode pct)
> +{
> + if (likely(pct == 0))
> + return 0;
> + return __cachemode2pte_tbl[pct];
> +}
I think this function name is not intuitive. pgprot_val() works as
pgprot-to-protval, but protval_cachemode() works the other way around as
cachemode-to-protval.
How about renaming to cachemode_protval()?
Also, "pct" should probably be changed to "pcm".
> +static inline pgprot_t pgprot_cachemode(enum page_cache_mode pct)
> +{
> + return __pgprot(protval_cachemode(pct));
> +}
Ditto.
> +static inline enum page_cache_mode cachemode_pgprot(pgprot_t pgprot)
> +{
> + unsigned long masked;
> +
> + masked = pgprot_val(pgprot) & _PAGE_CACHE_MASK;
> + if (likely(masked == 0))
> + return 0;
> + return __pte2cachemode_tbl[__pte2cm_idx(masked)];
> +}
Ditto.
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index 66dba36..0500124 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -27,6 +27,35 @@
>
> #include "mm_internal.h"
>
> +/*
> + * Tables translating between page_cache_type_t and pte encoding.
> + * Minimal supported modes are defined statically, modified if more supported
> + * cache modes are available.
> + * Index into __cachemode2pte_tbl is the cachemode.
> + * Index into __pte2cachemode_tbl are the caching attribute bits of the pte
> + * (_PAGE_PWT, _PAGE_PCD, _PAGE_PAT) at index bit positions 0, 1, 2.
> + */
> +uint16_t __cachemode2pte_tbl[_PAGE_CACHE_MODE_NUM] = {
> + [_PAGE_CACHE_MODE_WB] = 0,
> + [_PAGE_CACHE_MODE_WC] = _PAGE_PWT,
> + [_PAGE_CACHE_MODE_UC_MINUS] = _PAGE_PCD,
> + [_PAGE_CACHE_MODE_UC] = _PAGE_PCD | _PAGE_PWT,
> + [_PAGE_CACHE_MODE_WT] = _PAGE_PWT,
> + [_PAGE_CACHE_MODE_WP] = _PAGE_PWT,
> +};
I think WT and WP should be set to _PAGE_PCD (UC_MINUS) for safe.
> +EXPORT_SYMBOL_GPL(__cachemode2pte_tbl);
> +uint8_t __pte2cachemode_tbl[8] = {
> + [__pte2cm_idx(0)] = _PAGE_CACHE_MODE_WB,
> + [__pte2cm_idx(_PAGE_PWT)] = _PAGE_CACHE_MODE_WC,
> + [__pte2cm_idx(_PAGE_PCD)] = _PAGE_CACHE_MODE_UC_MINUS,
> + [__pte2cm_idx(_PAGE_PWT | _PAGE_PCD)] = _PAGE_CACHE_MODE_UC,
> + [__pte2cm_idx(_PAGE_PAT)] = _PAGE_CACHE_MODE_WB,
> + [__pte2cm_idx(_PAGE_PWT | _PAGE_PAT)] = _PAGE_CACHE_MODE_WC,
> + [__pte2cm_idx(_PAGE_PCD | _PAGE_PAT)] = _PAGE_CACHE_MODE_UC_MINUS,
> + [__pte2cm_idx(_PAGE_PWT | _PAGE_PCD | _PAGE_PAT)] = _PAGE_CACHE_MODE_UC,
> +};
:
> diff --git a/arch/x86/mm/iomap_32.c b/arch/x86/mm/iomap_32.c
> index 7b179b4..91a2d3b 100644
> --- a/arch/x86/mm/iomap_32.c
> +++ b/arch/x86/mm/iomap_32.c
> @@ -33,17 +33,17 @@ static int is_io_mapping_possible(resource_size_t base,
> unsigned long size)
>
> int iomap_create_wc(resource_size_t base, unsigned long size, pgprot_t *prot)
> {
> - unsigned long flag = _PAGE_CACHE_WC;
> + enum page_cache_mode pct = _PAGE_CACHE_MODE_WC;
> int ret;
>
> if (!is_io_mapping_possible(base,
Re: [PATCH v3 2/4] pwm: rockchip: Allow polarity invert on rk3288
Dmitry, On Wed, Aug 20, 2014 at 12:29 PM, Dmitry Torokhov wrote: > On August 20, 2014 1:54:11 PM CDT, Doug Anderson > wrote: >>On Wed, Aug 20, 2014 at 3:04 AM, Thierry Reding >> wrote: >>> On Tue, Aug 19, 2014 at 09:07:54AM -0700, Doug Anderson wrote: The rk3288 has the ability to invert + struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip); + + if (!pc->data->has_invert) + return -ENOSYS; + > > At the kernel summit hpa also mentioned that ENOSYS should only be used for > missing syscalls. Not sure what error code would suit better here though... Luckily this code is gone now. See v4 of the series. ;) -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] arm/smp: Absorb boot_secondary()
On Wednesday 20 August 2014, Geert Uytterhoeven wrote: > > Ping? > > On Wed, Jul 9, 2014 at 5:01 PM, Geert Uytterhoeven > wrote: > > After becoming a mandatory function, boot_secondary() is no longer used > > outside arch/arm/kernel/smp.c. Hence remove its public prototype, and, > > as suggested by Arnd, let it be absorbed by its single caller. > > > > Signed-off-by: Geert Uytterhoeven > > Acked-by: Arnd Bergmann I think you should add the patch to Russell's patch tracking system at http://www.arm.linux.org.uk/developer/patches to get it applied. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] pwm: rockchip: Allow polarity invert on rk3288
On August 20, 2014 1:54:11 PM CDT, Doug Anderson wrote: >On Wed, Aug 20, 2014 at 3:04 AM, Thierry Reding > wrote: >> On Tue, Aug 19, 2014 at 09:07:54AM -0700, Doug Anderson wrote: >>> The rk3288 has the ability to invert >>> + struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip); >>> + >>> + if (!pc->data->has_invert) >>> + return -ENOSYS; >>> + At the kernel summit hpa also mentioned that ENOSYS should only be used for missing syscalls. Not sure what error code would suit better here though... Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eventpoll: fix uninitialized variable in epoll_ctl
Nicolas Iooss wrote:
> When calling epoll_ctl with operation EPOLL_CTL_DEL, structure epds is
> not initialized but ep_take_care_of_epollwakeup reads its event field.
> When this unintialized field has EPOLLWAKEUP bit set, a capability check
> is done for CAP_BLOCK_SUSPEND in ep_take_care_of_epollwakeup. This
> produces unexpected messages in the audit log, such as (on a system
> running SELinux):
>
> type=AVC msg=audit(1408212798.866:410): avc: denied
> { block_suspend } for pid=7754 comm="dbus-daemon" capability=36
> scontext=unconfined_u:unconfined_r:unconfined_t
> tcontext=unconfined_u:unconfined_r:unconfined_t
> tclass=capability2 permissive=1
>
> type=SYSCALL msg=audit(1408212798.866:410): arch=c03e syscall=233
> success=yes exit=0 a0=3 a1=2 a2=9 a3=7fffd4d66ec0 items=0 ppid=1
> pid=7754 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=3 comm="dbus-daemon"
> exe="/usr/bin/dbus-daemon"
> subj=unconfined_u:unconfined_r:unconfined_t key=(null)
>
> ("arch=c03e syscall=233 a1=2" means "epoll_ctl(op=EPOLL_CTL_DEL)")
>
> Remove use of epds in epoll_ctl when op == EPOLL_CTL_DEL.
>
> Fixes: 4d7e30d98939 ("epoll: Add a flag, EPOLLWAKEUP, to prevent suspend
> while epoll events are ready")
> Signed-off-by: Nicolas Iooss
Looks good to me. Tested without regressions on several of my
(non-EPOLLWAKEUP) projects. Adding a few more folks to the Cc: list.
Acked-by: Eric Wong
> ---
> fs/eventpoll.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index b10b48c..7bcfff9 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -1852,7 +1852,8 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd,
> goto error_tgt_fput;
>
> /* Check if EPOLLWAKEUP is allowed */
> - ep_take_care_of_epollwakeup();
> + if (ep_op_has_event(op))
> + ep_take_care_of_epollwakeup();
>
> /*
>* We have to check that the file structure underneath the file
> descriptor
> --
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] mempolicy: change get_task_policy() to return default_policy rather than NULL
Every caller of get_task_policy() falls back to default_policy if it
returns NULL. Change get_task_policy() to do this.
Signed-off-by: Oleg Nesterov
---
mm/mempolicy.c | 31 +--
1 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index c0c5d38..656db97 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -126,22 +126,20 @@ static struct mempolicy
preferred_node_policy[MAX_NUMNODES];
static struct mempolicy *get_task_policy(struct task_struct *p)
{
struct mempolicy *pol = p->mempolicy;
+ int node;
- if (!pol) {
- int node = numa_node_id();
+ if (pol)
+ return pol;
- if (node != NUMA_NO_NODE) {
- pol = _node_policy[node];
- /*
-* preferred_node_policy is not initialised early in
-* boot
-*/
- if (!pol->mode)
- pol = NULL;
- }
+ node = numa_node_id();
+ if (node != NUMA_NO_NODE) {
+ pol = _node_policy[node];
+ /* preferred_node_policy is not initialised early in boot */
+ if (pol->mode)
+ return pol;
}
- return pol;
+ return _policy;
}
static const struct mempolicy_operations {
@@ -1644,14 +1642,14 @@ struct mempolicy *get_vma_policy(struct task_struct
*task,
mpol_get(pol);
}
}
- if (!pol)
- pol = _policy;
+
return pol;
}
bool vma_policy_mof(struct task_struct *task, struct vm_area_struct *vma)
{
struct mempolicy *pol = get_task_policy(task);
+
if (vma) {
if (vma->vm_ops && vma->vm_ops->get_policy) {
bool ret = false;
@@ -1667,9 +1665,6 @@ bool vma_policy_mof(struct task_struct *task, struct
vm_area_struct *vma)
}
}
- if (!pol)
- return default_policy.flags & MPOL_F_MOF;
-
return pol->flags & MPOL_F_MOF;
}
@@ -2077,7 +2072,7 @@ struct page *alloc_pages_current(gfp_t gfp, unsigned
order)
struct page *page;
unsigned int cpuset_mems_cookie;
- if (!pol || in_interrupt() || (gfp & __GFP_THISNODE))
+ if (in_interrupt() || (gfp & __GFP_THISNODE))
pol = _policy;
retry_cpuset:
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] powerpc: booke_wdt: Fix build error as a module
Building booke_wdt fails when trying to build as a module as there is no
early_param() in module. Fix by using module_param() instead of early_param().
Signed-off-by: Pranith Kumar
CC: Guenter Roeck
---
drivers/watchdog/booke_wdt.c | 28 +---
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 08a7853..e96b09b 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -30,8 +30,6 @@
* occur, and the final time the board will reset.
*/
-u32 booke_wdt_enabled;
-u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT;
#ifdef CONFIG_PPC_FSL_BOOK3E
#define WDTP(x)x)&0x3)<<30)|(((x)&0x3c)<<15))
@@ -41,27 +39,10 @@ u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT;
#define WDTP_MASK (TCR_WP_MASK)
#endif
-/* Checks wdt=x and wdt_period=xx command-line option */
-notrace int __init early_parse_wdt(char *p)
-{
- if (p && strncmp(p, "0", 1) != 0)
- booke_wdt_enabled = 1;
-
- return 0;
-}
-early_param("wdt", early_parse_wdt);
-
-int __init early_parse_wdt_period(char *p)
-{
- unsigned long ret;
- if (p) {
- if (!kstrtol(p, 0, ))
- booke_wdt_period = ret;
- }
-
- return 0;
-}
-early_param("wdt_period", early_parse_wdt_period);
+static bool booke_wdt_enabled;
+module_param(booke_wdt_enabled, bool, 0);
+static int booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT;
+module_param(booke_wdt_period, int, 0);
#ifdef CONFIG_PPC_FSL_BOOK3E
@@ -259,5 +240,6 @@ static int __init booke_wdt_init(void)
module_init(booke_wdt_init);
module_exit(booke_wdt_exit);
+MODULE_ALIAS("booke_wdt");
MODULE_DESCRIPTION("PowerPC Book-E watchdog driver");
MODULE_LICENSE("GPL");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] mempolicy: remove the "task" arg of vma_policy_mof() and simplify it
1. vma_policy_mof(task) is simply not safe unless task == current,
it can race with do_exit()->mpol_put(). Remove this arg and update
its single caller.
2. vma can not be NULL, remove this check and simplify the code.
Signed-off-by: Oleg Nesterov
---
include/linux/mempolicy.h |2 +-
kernel/sched/fair.c |2 +-
mm/mempolicy.c| 25 +++--
3 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
index f230a97..5e4bfce 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -136,7 +136,7 @@ struct mempolicy *mpol_shared_policy_lookup(struct
shared_policy *sp,
struct mempolicy *get_vma_policy(struct task_struct *tsk,
struct vm_area_struct *vma, unsigned long addr);
-bool vma_policy_mof(struct task_struct *task, struct vm_area_struct *vma);
+bool vma_policy_mof(struct vm_area_struct *vma);
extern void numa_default_policy(void);
extern void numa_policy_init(void);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bfa3c86..82088b2 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1946,7 +1946,7 @@ void task_numa_work(struct callback_head *work)
vma = mm->mmap;
}
for (; vma; vma = vma->vm_next) {
- if (!vma_migratable(vma) || !vma_policy_mof(p, vma))
+ if (!vma_migratable(vma) || !vma_policy_mof(vma))
continue;
/*
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index b86b08e..ad27bbc 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1646,27 +1646,24 @@ struct mempolicy *get_vma_policy(struct task_struct
*task,
return pol;
}
-bool vma_policy_mof(struct task_struct *task, struct vm_area_struct *vma)
+bool vma_policy_mof(struct vm_area_struct *vma)
{
- struct mempolicy *pol = NULL;
-
- if (vma) {
- if (vma->vm_ops && vma->vm_ops->get_policy) {
- bool ret = false;
+ struct mempolicy *pol;
- pol = vma->vm_ops->get_policy(vma, vma->vm_start);
- if (pol && (pol->flags & MPOL_F_MOF))
- ret = true;
- mpol_cond_put(pol);
+ if (vma->vm_ops && vma->vm_ops->get_policy) {
+ bool ret = false;
- return ret;
- }
+ pol = vma->vm_ops->get_policy(vma, vma->vm_start);
+ if (pol && (pol->flags & MPOL_F_MOF))
+ ret = true;
+ mpol_cond_put(pol);
- pol = vma->vm_policy;
+ return ret;
}
+ pol = vma->vm_policy;
if (!pol)
- pol = get_task_policy(task);
+ pol = get_task_policy(current);
return pol->flags & MPOL_F_MOF;
}
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] mempolicy: sanitize the usage of get_task_policy()
Cleanup + preparation. Every user of get_task_policy() calls it
unconditionally, even if it is not going to use the result.
get_task_policy() is cheap but still this does not look clean, plus
the code looks simpler if get_task_policy() is called only when this
is really needed.
Note: I hope this is correct, but it is not clear why vma_policy_mof()
doesn't fall back to get_task_policy() if ->get_policy() returns NULL.
Signed-off-by: Oleg Nesterov
---
mm/mempolicy.c | 25 ++---
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 656db97..b86b08e 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1621,14 +1621,11 @@ COMPAT_SYSCALL_DEFINE6(mbind, compat_ulong_t, start,
compat_ulong_t, len,
struct mempolicy *get_vma_policy(struct task_struct *task,
struct vm_area_struct *vma, unsigned long addr)
{
- struct mempolicy *pol = get_task_policy(task);
+ struct mempolicy *pol = NULL;
if (vma) {
if (vma->vm_ops && vma->vm_ops->get_policy) {
- struct mempolicy *vpol = vma->vm_ops->get_policy(vma,
- addr);
- if (vpol)
- pol = vpol;
+ pol = vma->vm_ops->get_policy(vma, addr);
} else if (vma->vm_policy) {
pol = vma->vm_policy;
@@ -1643,12 +1640,15 @@ struct mempolicy *get_vma_policy(struct task_struct
*task,
}
}
+ if (!pol)
+ pol = get_task_policy(task);
+
return pol;
}
bool vma_policy_mof(struct task_struct *task, struct vm_area_struct *vma)
{
- struct mempolicy *pol = get_task_policy(task);
+ struct mempolicy *pol = NULL;
if (vma) {
if (vma->vm_ops && vma->vm_ops->get_policy) {
@@ -1660,11 +1660,14 @@ bool vma_policy_mof(struct task_struct *task, struct
vm_area_struct *vma)
mpol_cond_put(pol);
return ret;
- } else if (vma->vm_policy) {
- pol = vma->vm_policy;
}
+
+ pol = vma->vm_policy;
}
+ if (!pol)
+ pol = get_task_policy(task);
+
return pol->flags & MPOL_F_MOF;
}
@@ -2068,12 +2071,12 @@ retry_cpuset:
*/
struct page *alloc_pages_current(gfp_t gfp, unsigned order)
{
- struct mempolicy *pol = get_task_policy(current);
+ struct mempolicy *pol = _policy;
struct page *page;
unsigned int cpuset_mems_cookie;
- if (in_interrupt() || (gfp & __GFP_THISNODE))
- pol = _policy;
+ if (!in_interrupt() && !(gfp & __GFP_THISNODE))
+ pol = get_task_policy(current);
retry_cpuset:
cpuset_mems_cookie = read_mems_allowed_begin();
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] mempolicy: change alloc_pages_vma() to use mpol_cond_put()
Trivial cleanup. alloc_pages_vma() can use mpol_cond_put(). Signed-off-by: Oleg Nesterov --- mm/mempolicy.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 8f5330d..c0c5d38 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -2046,8 +2046,7 @@ retry_cpuset: page = __alloc_pages_nodemask(gfp, order, policy_zonelist(gfp, pol, node), policy_nodemask(gfp, pol)); - if (unlikely(mpol_needs_cond_ref(pol))) - __mpol_put(pol); + mpol_cond_put(pol); if (unlikely(!page && read_mems_allowed_retry(cpuset_mems_cookie))) goto retry_cpuset; return page; -- 1.5.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Automatically pull missing FW files
Hi David, On 08/20/2014 11:34 AM, David Woodhouse wrote: > I'm not sure I understand. Precisely what fails? I clone a subsystem, configure it to use CONFIG_EXTRA_FIRMWARE="qat_895xcc.bin", type make && make install and get: MK_FW firmware/qat_895xxc.bin.gen.S make[1]: *** No rule to make target `firmware/qat_895xxc.bin', needed by `firmware/qat_895xxc.bin.gen.o'. Stop. I thought it might be useful if it would pull whatever FW it needs and not just give up. It also might be useful if one wants to "refresh" the FW binaries. In this case one can do rm firmware/*.[bin|ihex] && make && make install > > I don't like this patch very much. We should be removing the legacy > firmware/ directory entirely, not patching it up. > > Userspace is responsible for providing the firmware, and it should > generally come from an entirely separate checkout of the linux-firmware > repository. Yes, if you use udev helper. When you want to compile in the blobs to your kernel it is needed in build time, right? In both cases you need the binary anyway so you can copy it manually from linux-firmware or use this nice feature to do it for you. If you want to remove firmware/ directory entirely then this makefile will be gone as well so what's the problem? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] mempolicy: get_task_policy() cleanups/preparations
On 08/20, Oleg Nesterov wrote: > > With this change the only user of proc_maps_private->task is > hold_task_mempolicy/release_task_mempolicy. I believe this code is buggy > and should die, but this needs the changes in mm/mempolicy.c. I belive that 9e7814404b77c3e8 "hold task->mempolicy while numa_maps scans" was wrong and it doesn't fix the problem. I'll try to send the fix tomorrow, could you review the initial preparations? To me, these changes make sense as cleanups in any case, but I don't really understand this code and this was only compile tested. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/13] scsi: Use pci_enable_msix_range() instead of pci_enable_msix()
On Wed, Aug 20, 2014 at 08:14:17PM +0100, Alexander Gordeev wrote: > > I've applied patches 1 to 7 to the drivers-for-3.18 branch. > > Thanks, Christoph! > > Not sure how to handle the rest, though. Chelsio driver has no > maintainers and none of be2iscsi, pmcraid and csiostor has been > reviewed for several months. I've added Tomas to the Cc list who has been very helpful with reviewing drivers lately. Tomas, can you take a quick look at these patches? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler
Commit 1a6b69b6548c (ARM: gic: add CPU migration support, 2012-04-12) introduced an acquisition of the irq_controller_lock in gic_raise_softirq() which can lead to a spinlock recursion if the gic_arch_extn hooks call into the scheduler (via complete() or wake_up(), etc.). This happens because gic_arch_extn hooks are normally called with the irq_controller_lock held and calling into the scheduler may cause us to call smp_send_reschedule() which will grab the irq_controller_lock again. Here's an example from a vendor kernel (note that the gic_arch_extn hook code here isn't actually in mainline): BUG: spinlock recursion on CPU#0, swapper/0/1 lock: irq_controller_lock+0x0/0x18, .magic: dead4ead, .owner: sw er_cpu: 0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.10-00430-g3d433c4e Call trace: [] dump_backtrace+0x0/0x140 [] show_stack+0x10/0x1c [] dump_stack+0x74/0xc4 [] spin_dump+0x78/0x88 [] spin_bug+0x24/0x34 [] do_raw_spin_lock+0x58/0x148 [] _raw_spin_lock_irqsave+0x24/0x38 [] gic_raise_softirq+0x2c/0xbc [] smp_send_reschedule+0x34/0x40 [] try_to_wake_up+0x224/0x288 [] default_wake_function+0xc/0x18 [] __wake_up_common+0x50/0x8c [] __wake_up_locked+0x10/0x1c [] complete+0x3c/0x5c [] msm_mpm_enable_irq_exclusive+0x1b8/0x1c8 [] __msm_mpm_enable_irq+0x4c/0x7c [] msm_mpm_enable_irq+0xc/0x18 [] gic_unmask_irq+0x40/0x7c [] irq_enable+0x2c/0x48 [] irq_startup+0x4c/0x74 [] __setup_irq+0x264/0x3f0 [] request_threaded_irq+0xcc/0x11c [] devm_request_threaded_irq+0x68/0xb4 [] msm_iommu_ctx_probe+0x124/0x2d4 [] platform_drv_probe+0x20/0x54 [] driver_probe_device+0x158/0x340 [] __driver_attach+0x60/0x90 [] bus_for_each_dev+0x6c/0x8c [] driver_attach+0x1c/0x28 [] bus_add_driver+0x120/0x204 [] driver_register+0xbc/0x10c [] __platform_driver_register+0x5c/0x68 [] msm_iommu_driver_init+0x54/0x7c [] do_one_initcall+0xa4/0x130 [] kernel_init_freeable+0x138/0x1dc [] kernel_init+0xc/0xd4 We really just want to synchronize the sending of an SGI with the update of the gic_cpu_map[], so introduce a new SGI lock that we can use to synchronize the two code paths. To further optimize we don't take any locks at all if the BL switcher code isn't used. Cc: Nicolas Pitre Cc: Russell King - ARM Linux Signed-off-by: Stephen Boyd --- drivers/irqchip/irq-gic.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index 4b959e606fe8..052762638b1c 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -80,6 +80,16 @@ static DEFINE_RAW_SPINLOCK(irq_controller_lock); #define NR_GIC_CPU_IF 8 static u8 gic_cpu_map[NR_GIC_CPU_IF] __read_mostly; +#ifdef CONFIG_BL_SWITCHER +/* Synchronize switching CPU interface and sending SGIs */ +static DEFINE_RAW_SPINLOCK(gic_sgi_lock); +#define sgi_map_lock(flags) raw_spin_lock_irqsave(_sgi_lock, flags) +#define sgi_map_unlock(flags) raw_spin_unlock_irqrestore(_sgi_lock, flags) +#else +#define sgi_map_lock(flags) (void)(flags) +#define sgi_map_unlock(flags) (void)(flags) +#endif + /* * Supported arch specific GIC irq extension. * Default make them NULL. @@ -605,7 +615,7 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq) int cpu; unsigned long flags, map = 0; - raw_spin_lock_irqsave(_controller_lock, flags); + sgi_map_lock(flags); /* Convert our logical CPU mask into a physical one. */ for_each_cpu(cpu, mask) @@ -620,7 +630,7 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq) /* this always happens on GIC0 */ writel_relaxed(map << 16 | irq, gic_data_dist_base(_data[0]) + GIC_DIST_SOFTINT); - raw_spin_unlock_irqrestore(_controller_lock, flags); + sgi_map_unlock(flags); } #endif @@ -690,6 +700,7 @@ void gic_migrate_target(unsigned int new_cpu_id) ror_val = (cur_cpu_id - new_cpu_id) & 31; raw_spin_lock(_controller_lock); + raw_spin_lock(_sgi_lock); /* Update the target interface for this logical CPU */ gic_cpu_map[cpu] = 1 << new_cpu_id; @@ -709,6 +720,7 @@ void gic_migrate_target(unsigned int new_cpu_id) } } + raw_spin_unlock(_sgi_lock); raw_spin_unlock(_controller_lock); /* -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: booke_wdt: Fix build error as a module
On Wed, Aug 20, 2014 at 3:18 PM, Pranith Kumar wrote: > On Wed, Aug 20, 2014 at 2:59 PM, Guenter wrote: >> >> Any reason for changing the default from false to true ? >> Unless you have a reaslly good reason, I don't think that is a good idea. > > I don't see where it was being set to false. It is > uninitialized AFAICT. Does that mean that it is false? (I thought only > static variables got that default). Ohk, some googling tells me both global and static variables are initialized to 0. Makes sense, I will send in a v2 -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: booke_wdt: Fix build error as a module
On Wed, Aug 20, 2014 at 2:59 PM, Guenter wrote:
> On Wed, Aug 20, 2014 at 12:55:44PM -0400, Pranith Kumar wrote:
>> Building booke_wdt fails when trying to build as a module as there is no
>> early_param() in module. Fix by using module_param() instead of
>> early_param().
>>
>> Signed-off-by: Pranith Kumar
>> CC: Guenter Roeck
>> ---
>> drivers/watchdog/booke_wdt.c | 28 +---
>> 1 file changed, 5 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
>> index 08a7853..65f5e9f 100644
>> --- a/drivers/watchdog/booke_wdt.c
>> +++ b/drivers/watchdog/booke_wdt.c
>> @@ -30,8 +30,6 @@
>> * occur, and the final time the board will reset.
>> */
>>
>> -u32 booke_wdt_enabled;
>> -u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT;
>>
>> #ifdef CONFIG_PPC_FSL_BOOK3E
>> #define WDTP(x) x)&0x3)<<30)|(((x)&0x3c)<<15))
>> @@ -41,27 +39,10 @@ u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT;
>> #define WDTP_MASK(TCR_WP_MASK)
>> #endif
>>
>> -/* Checks wdt=x and wdt_period=xx command-line option */
>> -notrace int __init early_parse_wdt(char *p)
>> -{
>> - if (p && strncmp(p, "0", 1) != 0)
>> - booke_wdt_enabled = 1;
>> -
>> - return 0;
>> -}
>> -early_param("wdt", early_parse_wdt);
>> -
>> -int __init early_parse_wdt_period(char *p)
>> -{
>> - unsigned long ret;
>> - if (p) {
>> - if (!kstrtol(p, 0, ))
>> - booke_wdt_period = ret;
>> - }
>> -
>> - return 0;
>> -}
>> -early_param("wdt_period", early_parse_wdt_period);
>> +static bool booke_wdt_enabled = true;
>
> Any reason for changing the default from false to true ?
> Unless you have a reaslly good reason, I don't think that is a good idea.
I don't see where it was being set to false. It is
uninitialized AFAICT. Does that mean that it is false? (I thought only
static variables got that default).
>
>> +module_param(booke_wdt_enabled, bool, 0444);
>> +static int booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT;
>> +module_param(booke_wdt_period, int, 0444);
>>
> Also not sure if it adds value to have the module parameters visible
> from user space. Why not use 0 for the permission flags ?
>
I have no objection to your suggestion. But not sure if such paranoia
is warranted :)
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler
On 08/17/14 18:54, Jason Cooper wrote: > > Stephen, is the out of tree code that triggered this bound for mainline? > It's bound for mainline eventually. We're actively working on enabling more low power modes and when that happens we'll need this patch. We can always carry this patch for now if you don't want to accept it, but I figured getting it mainlined reduces our carrying burden and also makes a minor improvement in sending IPIs when the BL switcher is used. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: bluetooth 2014-08-20
Hi John, Here's a set of patches for the 3.17-rc series. It contains a connection reference counting fix for LE where a connection might stay up even though it should get disconnected. The other 802.15.4 6LoWPAN related patches were sent to the bluetooth tree by Alexander Aring and described as follows by him: " these patches contains patches for the bluetooth branch. This series includes memory leak fixes and an errno value fix. Also there are two patches for sending and receiving 1280 6LoWPAN packets, which makes the IEEE 802.15.4 6LoWPAN stack more RFC compliant. " Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 77b2f2865956b7573f9b040db7a9f808b434acd1: iwlwifi: mvm: disable scheduled scan to prevent firmware crash (2014-08-14 19:47:41 +0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git for-upstream for you to fetch changes up to f161dd4122ffa73e4e12000309dca65bec80d416: Bluetooth: Fix hci_conn reference counting for auto-connections (2014-08-20 21:57:39 +0300) Alexander Aring (2): ieee802154: 6lowpan_rtnl: fix correct errno value ieee802154: 6lowpan: ensure of sending 1280 packets Johan Hedberg (1): Bluetooth: Fix hci_conn reference counting for auto-connections Martin Townsend (3): mac802154: fixed potential skb leak with mac802154_parse_frame_start ieee802154: mac802154: handle the reserved dest mode by dropping the packet ieee802154: 6lowpan: ensure MTU of 1280 for 6lowpan include/net/bluetooth/hci_core.h | 2 ++ include/net/netns/ieee802154_6lowpan.h | 1 - net/bluetooth/hci_conn.c | 8 net/bluetooth/hci_core.c | 14 -- net/bluetooth/hci_event.c | 17 +++-- net/ieee802154/6lowpan_rtnl.c | 4 ++-- net/ieee802154/reassembly.c| 15 +++ net/mac802154/wpan.c | 6 +- 8 files changed, 47 insertions(+), 20 deletions(-) pgpowfTjtCGBh.pgp Description: PGP signature
Re: FW: [RFC 0/5] perf tools: Add perf data CTF conversion
On 08/20/2014 05:28 AM, Jiri Olsa wrote: ok, easy enough ;-) so I'm guessing this governs the expected CTF layout for event/stream headers/contexts, right? Correct, if the domain is "kernel" we then assume that the rest of the trace contains the expected elements of a kernel trace. Of course, one could craft a CTF trace to advertize itself as "kernel" or "ust", and not actually have the layout of that trace type, in which case it would fail parsing later on. Also judging from the trace display, you have hardcoded specific displays/actions for specific events? That's all connected/specific under trace type? Yes the trace type is the main "provider" of functionality. I could go into more details, but we use Eclipse extension points to define which columns to put in the event table, which views are available, etc. for each supported trace type. Once we have some views or analysis specific to perf CTF traces, we could definitely add a separate trace type for those too. I guess tracepoints and breakpoints should display something like the standard kernel trace. As for HW events it's usual to display profile infomation as the perf report does: https://perf.wiki.kernel.org/index.php/Tutorial#Sampling_with_perf_record Interesting, I haven't tried the perf CTF output yet, but I could see it using the Statistics view (which by default just prints the % of events, per event type) to print the results of the different "perf reports", calculated from the CTF events. Eventually with pie charts! I tried to record/display lttng event perf:cpu:cycles, but got nothing displayed in eclipse. Looks like this data provides only summary count of the event for the workload? Just to be sure I understand, you recorded an LTTng kernel trace, in which you enabled the "perf:cpu:cycles" context? Did this trace display anything in Babeltrace? It should display the same in the Eclipse viewer, the value of the context will be visible in the "Contents" column in the the table (and in the Properties view), although for now we don't make any use of it. From what I understand, yes, the value of the different perf:* contexts represents the value of the perf counter at the moment the tracepoint was hit. So you cannot get perf data "in between" trace events when using this method. Cheers, Alexandre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler
On 08/17/14 17:17, Nicolas Pitre wrote: > On Sun, 17 Aug 2014, Russell King - ARM Linux wrote: > >> I have no problem with changing gic_raise_softirq() to use a different >> lock, which gic_migrate_target(), and gic_set_affinity() can also use. >> There's no need for horrid locking here, because the only thing we're >> protecting is gic_map[] and the write to the register to trigger an >> IPI - and nothing using gic_arch_extn has any business knowing about >> SGIs. >> >> No need for these crappy sgi_map_lock() macros and all the ifdeffery. > Those macros are there only to conditionalize the locking in > gic_raise_softirq() because no locking what so ever is needed there when > gic_migrate_target() is configured out. I suggested the macros to cut > down on the #ifdefery in the code. Ok I can resend with the sgi lock around the gic_cpu_map updating code. Let's see how v5 goes. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/13] scsi: Use pci_enable_msix_range() instead of pci_enable_msix()
On Tue, Aug 19, 2014 at 10:00:47AM -0700, Christoph Hellwig wrote: > Thanks, > > I've applied patches 1 to 7 to the drivers-for-3.18 branch. Thanks, Christoph! Not sure how to handle the rest, though. Chelsio driver has no maintainers and none of be2iscsi, pmcraid and csiostor has been reviewed for several months. -- Regards, Alexander Gordeev agord...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: booke_wdt: Fix build error as a module
On Wed, Aug 20, 2014 at 12:55:44PM -0400, Pranith Kumar wrote:
> Building booke_wdt fails when trying to build as a module as there is no
> early_param() in module. Fix by using module_param() instead of early_param().
>
> Signed-off-by: Pranith Kumar
> CC: Guenter Roeck
> ---
> drivers/watchdog/booke_wdt.c | 28 +---
> 1 file changed, 5 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
> index 08a7853..65f5e9f 100644
> --- a/drivers/watchdog/booke_wdt.c
> +++ b/drivers/watchdog/booke_wdt.c
> @@ -30,8 +30,6 @@
> * occur, and the final time the board will reset.
> */
>
> -u32 booke_wdt_enabled;
> -u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT;
>
> #ifdef CONFIG_PPC_FSL_BOOK3E
> #define WDTP(x) x)&0x3)<<30)|(((x)&0x3c)<<15))
> @@ -41,27 +39,10 @@ u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT;
> #define WDTP_MASK(TCR_WP_MASK)
> #endif
>
> -/* Checks wdt=x and wdt_period=xx command-line option */
> -notrace int __init early_parse_wdt(char *p)
> -{
> - if (p && strncmp(p, "0", 1) != 0)
> - booke_wdt_enabled = 1;
> -
> - return 0;
> -}
> -early_param("wdt", early_parse_wdt);
> -
> -int __init early_parse_wdt_period(char *p)
> -{
> - unsigned long ret;
> - if (p) {
> - if (!kstrtol(p, 0, ))
> - booke_wdt_period = ret;
> - }
> -
> - return 0;
> -}
> -early_param("wdt_period", early_parse_wdt_period);
> +static bool booke_wdt_enabled = true;
Any reason for changing the default from false to true ?
Unless you have a reaslly good reason, I don't think that is a good idea.
> +module_param(booke_wdt_enabled, bool, 0444);
> +static int booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT;
> +module_param(booke_wdt_period, int, 0444);
>
Also not sure if it adds value to have the module parameters visible
from user space. Why not use 0 for the permission flags ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Loading initrd above 4G causes freeze on boot
On Wed, Aug 20, 2014 at 8:05 PM, Matt Fleming wrote: > On Wed, 13 Aug, at 07:44:49PM, Matt Fleming wrote: >> >> At this point, I think modifying the max address is the best way to >> debug this further, and figure out what address causes the hang. > > Mantas, did you manage to get to the bottom of this issue? I experimented with some things (like setting chunk size to a few kB to see if it hangs earlier or only at the very end; etc.), and finally found out that it stops freezing if I pad the initrd file to a multiple of 512 bytes :/ That is, 5684268 bytes will freeze, 5684736 bytes will not. ...In other words, seems like it cannot read chunks that aren't multiples of 512 into a location above 4 GB. Or something like that... -- Mantas Mikulėnas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/4] pwm: rockchip: Allow polarity invert on rk3288
The rk3288 has the ability to invert the polarity of the PWM. Let's
enable that ability. Note that this increases pwm_cells to 3 for
rk3288.
Signed-off-by: Doug Anderson
---
Changes in v4:
- Updated comment not to add caveats about pwm_cells 3.
- rockchip_pwm_set_polarity() is now static.
- Separate pwm_ops for v1 and v2; no set_polarity() in v1.
- Added a blank line.
Changes in v3:
- Don't store a private copy of polarity.
- Use true instead of 1.
- Cleanup init order with "has_invert".
Changes in v2: None
.../devicetree/bindings/pwm/pwm-rockchip.txt | 4 +-
drivers/pwm/pwm-rockchip.c | 57 ++
2 files changed, 50 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
index d47d15a..b8be3d0 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
@@ -7,8 +7,8 @@ Required properties:
"rockchip,vop-pwm": found integrated in VOP on RK3288 SoC
- reg: physical base address and length of the controller's registers
- clocks: phandle and clock specifier of the PWM reference clock
- - #pwm-cells: should be 2. See pwm.txt in this directory for a
- description of the cell format.
+ - #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.txt in this directory
+ for a description of the cell format.
Example:
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index bdd8644..9442df2 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -24,7 +24,9 @@
#define PWM_ENABLE (1 << 0)
#define PWM_CONTINUOUS (1 << 1)
#define PWM_DUTY_POSITIVE (1 << 3)
+#define PWM_DUTY_NEGATIVE (0 << 3)
#define PWM_INACTIVE_NEGATIVE (0 << 4)
+#define PWM_INACTIVE_POSITIVE (1 << 4)
#define PWM_OUTPUT_LEFT(0 << 5)
#define PWM_LP_DISABLE (0 << 8)
@@ -45,8 +47,10 @@ struct rockchip_pwm_regs {
struct rockchip_pwm_data {
struct rockchip_pwm_regs regs;
unsigned int prescaler;
+ const struct pwm_ops *ops;
- void (*set_enable)(struct pwm_chip *chip, bool enable);
+ void (*set_enable)(struct pwm_chip *chip,
+ struct pwm_device *pwm, bool enable);
};
static inline struct rockchip_pwm_chip *to_rockchip_pwm_chip(struct pwm_chip
*c)
@@ -54,7 +58,8 @@ static inline struct rockchip_pwm_chip
*to_rockchip_pwm_chip(struct pwm_chip *c)
return container_of(c, struct rockchip_pwm_chip, chip);
}
-static void rockchip_pwm_set_enable_v1(struct pwm_chip *chip, bool enable)
+static void rockchip_pwm_set_enable_v1(struct pwm_chip *chip,
+ struct pwm_device *pwm, bool enable)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
u32 enable_conf = PWM_CTRL_OUTPUT_EN | PWM_CTRL_TIMER_EN;
@@ -70,14 +75,19 @@ static void rockchip_pwm_set_enable_v1(struct pwm_chip
*chip, bool enable)
writel_relaxed(val, pc->base + pc->data->regs.ctrl);
}
-static void rockchip_pwm_set_enable_v2(struct pwm_chip *chip, bool enable)
+static void rockchip_pwm_set_enable_v2(struct pwm_chip *chip,
+ struct pwm_device *pwm, bool enable)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
u32 enable_conf = PWM_OUTPUT_LEFT | PWM_LP_DISABLE | PWM_ENABLE |
- PWM_CONTINUOUS | PWM_DUTY_POSITIVE |
- PWM_INACTIVE_NEGATIVE;
+ PWM_CONTINUOUS;
u32 val;
+ if (pwm->polarity == PWM_POLARITY_INVERSED)
+ enable_conf |= PWM_DUTY_NEGATIVE | PWM_INACTIVE_POSITIVE;
+ else
+ enable_conf |= PWM_DUTY_POSITIVE | PWM_INACTIVE_NEGATIVE;
+
val = readl_relaxed(pc->base + pc->data->regs.ctrl);
if (enable)
@@ -124,6 +134,19 @@ static int rockchip_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm,
return 0;
}
+static int rockchip_pwm_set_polarity(struct pwm_chip *chip,
+struct pwm_device *pwm,
+enum pwm_polarity polarity)
+{
+ /*
+* No action needed here because pwm->polarity will be set by the core
+* and the core will only change polarity when the PWM is not enabled.
+* We'll handle things in set_enable().
+*/
+
+ return 0;
+}
+
static int rockchip_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
@@ -133,7 +156,7 @@ static int rockchip_pwm_enable(struct pwm_chip *chip,
struct pwm_device *pwm)
if (ret)
return ret;
- pc->data->set_enable(chip, true);
+ pc->data->set_enable(chip, pwm, true);
return 0;
}
@@ -142,18 +165,26 @@ static void rockchip_pwm_disable(struct pwm_chip
Re: amd_mce.c redundant if check?
On Wed, Aug 20, 2014 at 11:18:21AM -0600, Adam Duskett wrote:
> I have recently come upon this section of code in
> arch/x86/kernel/cpu/mcheck/mce_amd.c that seems to be a redundant
> unnecessary if check.
>
>
> From line 170 - 176:
>
> if (tr->set_lvt_off) {
> if (lvt_off_valid(tr->b, tr->lvt_off, lo, hi)) {
> /* set new lvt offset */
> hi &= ~MASK_LVTOFF_HI;
> hi |= tr->lvt_off << 20;
> }
> }
>
>
> This seems like it's not actually doing anything because it's setting
> the same value that the bit-field already has to itself.
Are you sure?
Just try to find out what MASK_LVTOFF_HI is and then do the operations
with a pen and paper to check whether something else actually happens.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] toshiba_acpi.c - fix busted keyboard backlight logic
Both the original and the first attempted patch managed to get the logic wrong. So we fix it so we only continue if sscanf returns exactly one value, and it has to be either 1 or 2. Apparently, programmers are getting out and hacking code without remembering de Morgan's Laws... Patch is against the file that results from Ari's revert of the previous patch. Signed-Off-By: Valdis Kletnieks -- --- drivers/platform/x86/toshiba_acpi.c.orig2014-08-20 14:45:52.159898938 -0400 +++ drivers/platform/x86/toshiba_acpi.c 2014-08-20 14:47:55.102444985 -0400 @@ -1258,7 +1258,7 @@ static ssize_t toshiba_kbd_bl_mode_store int mode = -1; int time = -1; - if (sscanf(buf, "%i", ) != 1 && (mode != 2 || mode != 1)) + if (sscanf(buf, "%i", ) != 1 || !(mode == 2 || mode == 1)) return -EINVAL; /* Set the Keyboard Backlight Mode where: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/4] ARM: dts: Add main PWM info to rk3288
This adds the PWM info (other than the VOP PWM) to the main rk3288
dtsi file.
Signed-off-by: Caesar Wang
Signed-off-by: Doug Anderson
---
Changes in v4:
- Add rockchip,grf to pwm nodes.
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/rk3288.dtsi | 72 +++
1 file changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 36be7bb..9074205 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -261,6 +261,54 @@
status = "disabled";
};
+ pwm0: pwm@ff68 {
+ compatible = "rockchip,rk3288-pwm";
+ reg = <0xff68 0x10>;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin>;
+ clocks = < PCLK_PWM>;
+ clock-names = "pwm";
+ rockchip,grf = <>;
+ status = "disabled";
+ };
+
+ pwm1: pwm@ff680010 {
+ compatible = "rockchip,rk3288-pwm";
+ reg = <0xff680010 0x10>;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin>;
+ clocks = < PCLK_PWM>;
+ clock-names = "pwm";
+ rockchip,grf = <>;
+ status = "disabled";
+ };
+
+ pwm2: pwm@ff680020 {
+ compatible = "rockchip,rk3288-pwm";
+ reg = <0xff680020 0x10>;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin>;
+ clocks = < PCLK_PWM>;
+ clock-names = "pwm";
+ rockchip,grf = <>;
+ status = "disabled";
+ };
+
+ pwm3: pwm@ff680030 {
+ compatible = "rockchip,rk3288-pwm";
+ reg = <0xff680030 0x10>;
+ #pwm-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin>;
+ clocks = < PCLK_PWM>;
+ clock-names = "pwm";
+ rockchip,grf = <>;
+ status = "disabled";
+ };
+
pmu: power-management@ff73 {
compatible = "rockchip,rk3288-pmu", "syscon";
reg = <0xff73 0x100>;
@@ -611,5 +659,29 @@
rockchip,pins = <5 15 3 _pull_none>;
};
};
+
+ pwm0 {
+ pwm0_pin: pwm0-pin {
+ rockchip,pins = <7 0 RK_FUNC_1 _pull_none>;
+ };
+ };
+
+ pwm1 {
+ pwm1_pin: pwm1-pin {
+ rockchip,pins = <7 1 RK_FUNC_1 _pull_none>;
+ };
+ };
+
+ pwm2 {
+ pwm2_pin: pwm2-pin {
+ rockchip,pins = <7 22 RK_FUNC_3
_pull_none>;
+ };
+ };
+
+ pwm3 {
+ pwm3_pin: pwm3-pin {
+ rockchip,pins = <7 23 RK_FUNC_3
_pull_none>;
+ };
+ };
};
};
--
2.1.0.rc2.206.gedb03e5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/4] PWM changes for rk3288-evb
These patches enable the PWM backlight for the rk3288-evb board. There were tested by watching the backlight grow from off to max with the following instructions: cd /sys/class/backlight/backlight*/ for i in $(seq 255); do echo $i > brightness; sleep .01; done The first patch switches PWM cells from 2 to 3 on rk3288. I think it could land in Thierry's tree. This patch will break backward compatibility for rk3288 until changes land handling PWM cells more dynamically, but since there are no rk3288 boards shipping yet it seems OK. The second patch enables the proper IP. This will also break backward compatibility, but again should be OK since there are no users. If needed we could make the "grf" optional and assume any shipping boards enabled the bit in their bootloader. I think this could land in Thierry's tree with Heiko's ACK. The 3rd and 4th patches are DTS ones. They could land in Heiko's tree after the first two patches. They are based atop his current WIP 3.18 dts tree. Note that instantiating the PWM backlight will cause the system to hang unless Heiko's (clk: rockchip: protect critical clocks from getting disabled) is landed. There are no compile time or runtime dependencies between these patches except that patch #3 needs to come before patch #4. ...and of course the PWM won't work without all 4 patches. Changes in v4: - Updated comment not to add caveats about pwm_cells 3. - rockchip_pwm_set_polarity() is now static. - Separate pwm_ops for v1 and v2; no set_polarity() in v1. - Added a blank line. - Totally rewrote to go in the PWM driver. - Reordered IP switch to be atop invert patch. - Add rockchip,grf to pwm nodes. Changes in v3: - Don't store a private copy of polarity. - Use true instead of 1. - Cleanup init order with "has_invert". - Fix space to tab in 2 places in DTS. - Make sure PWM is upper case in prose. Changes in v2: - Check for failed ioremap() Doug Anderson (4): pwm: rockchip: Allow polarity invert on rk3288 ARM: rockchip: rk3288: Switch to use the proper PWM IP ARM: dts: Add main PWM info to rk3288 ARM: dts: Enable PWM backlight on rk3288-evb .../devicetree/bindings/pwm/pwm-rockchip.txt | 8 +- arch/arm/boot/dts/rk3288-evb.dtsi | 53 + arch/arm/boot/dts/rk3288.dtsi | 72 ++ drivers/pwm/pwm-rockchip.c | 86 +++--- 4 files changed, 208 insertions(+), 11 deletions(-) -- 2.1.0.rc2.206.gedb03e5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] pwm: rockchip: Allow polarity invert on rk3288
Thierry,
On Wed, Aug 20, 2014 at 3:04 AM, Thierry Reding
wrote:
> On Tue, Aug 19, 2014 at 09:07:54AM -0700, Doug Anderson wrote:
>> The rk3288 has the ability to invert the polarity of the PWM. Let's
>> enable that ability.
>>
>> To do this we increase the number of pwm_cells to 3 to allow using the
>> PWM_POLARITY_INVERTED flag. Since the PWM driver on rk3288 is very
>> new, I thought this was OK.
>
> I don't see any files in arch/arm/boot/dts using either of the
> rockchip,vop-pwm or rockchip,rk3288-pwm compatible strings, so there's
> no reason to consider this stable ABI yet. As far as I'm concerned the
> last sentence can just as well be dropped.
>
> Besides, patches have been posted to support #pwm-cells = <2> and
> #pwm-cells = <3> at the same time which should give you backwards-
> compatibility for free.
Done. I'm happy that the subsystem is being improved to handle
pwm-cells more dynamically, too! That's a nice improvement.
> A couple more comments inline.
>
>> diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
> [...]
>> +int rockchip_pwm_set_polarity(struct pwm_chip *chip, struct pwm_device *pwm,
>> + enum pwm_polarity polarity)
>
> This should be static.
Done.
>> +{
>> + struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
>> +
>> + if (!pc->data->has_invert)
>> + return -ENOSYS;
>> +
>> + /*
>> + * No action needed here because pwm->polarity will be set by the core
>> + * and the core will only change polarity when the PWM is not enabled.
>> + * We'll handle things in set_enable().
>> + */
>> +
>> + return 0;
>> +}
>
> An alternative here would be to provide a separate pwm_ops with
> .set_polarity = NULL for the versions of the IP block that don't support
> polarity inversion yet, but this works for me too.
Good point. I'll make the change since it paves the way for other
pwm_ops that are different.
>> @@ -173,6 +201,7 @@ static const struct rockchip_pwm_data pwm_data_v2 = {
>> .ctrl = 0x0c,
>> },
>> .prescaler = 1,
>> + .has_invert = true,
>> .set_enable = rockchip_pwm_set_enable_v2,
>> };
>>
>> @@ -184,6 +213,7 @@ static const struct rockchip_pwm_data pwm_data_vop = {
>> .ctrl = 0x00,
>> },
>> .prescaler = 1,
>> + .has_invert = true,
>> .set_enable = rockchip_pwm_set_enable_v2,
>> };
>
> Can you please add a '.has_invert = false,' line to pwm_data_v1? I know
> it's not strictly necessary but I like it when things are explicitly
> stated.
No longer relevant with different pwm_ops.
>> @@ -230,6 +260,10 @@ static int rockchip_pwm_probe(struct platform_device
>> *pdev)
>> pc->chip.ops = _pwm_ops;
>> pc->chip.base = -1;
>> pc->chip.npwm = 1;
>> + if (pc->data->has_invert) {
>
> There should be a blank line between the above two.
Done.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/4] ARM: rockchip: rk3288: Switch to use the proper PWM IP
The rk3288 SoC has an option to switch all of the PWMs in the system
between the old IP block and the new IP block. The rk3288 PWM driver
is written for the new block, so make sure that we enable the new
block in the GRF (general register file) when the PWM driver probes.
We emulate the solution to this problem used in i2c-rk3x.c. One
difference for the PWM is that there's a single "enable new IP" that's
used for all 4 PWMs. That means we set this bit 4 times if we've got
all 4 PWMs enabled. That shouldn't hurt.
Signed-off-by: Doug Anderson
---
Changes in v4:
- Totally rewrote to go in the PWM driver.
- Reordered IP switch to be atop invert patch.
Changes in v3: None
Changes in v2:
- Check for failed ioremap()
.../devicetree/bindings/pwm/pwm-rockchip.txt | 4 +++
drivers/pwm/pwm-rockchip.c | 29 ++
2 files changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
index b8be3d0..39190ec 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
@@ -10,6 +10,10 @@ Required properties:
- #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.txt in this directory
for a description of the cell format.
+Required for "rockchip,rk3288-pwm":
+ - rockchip,grf : the phandle of the syscon node for the general register
+ file (GRF)
+
Example:
pwm0: pwm@2003 {
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 9442df2..08cbde6 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -16,7 +16,12 @@
#include
#include
#include
+#include
#include
+#include
+
+#define RK3288_GRF_PWM_ENABLE_OFFSET 0x024c
+#define RK3288_GRF_PWM_ENABLE_BIT 0
#define PWM_CTRL_TIMER_EN (1 << 0)
#define PWM_CTRL_OUTPUT_EN (1 << 3)
@@ -231,6 +236,7 @@ MODULE_DEVICE_TABLE(of, rockchip_pwm_dt_ids);
static int rockchip_pwm_probe(struct platform_device *pdev)
{
+ struct device_node *np = pdev->dev.of_node;
const struct of_device_id *id;
struct rockchip_pwm_chip *pc;
struct resource *r;
@@ -240,6 +246,29 @@ static int rockchip_pwm_probe(struct platform_device *pdev)
if (!id)
return -EINVAL;
+ /*
+* Switch to new interface on rk3288.
+* The control bit is located in the GRF register space.
+*/
+ if (of_device_is_compatible(np, "rockchip,rk3288-pwm")) {
+ struct regmap *grf;
+
+ grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+ if (IS_ERR(grf)) {
+ dev_err(>dev, "Missing rockchip,grf property\n");
+ return PTR_ERR(grf);
+ }
+
+ /* Set bit 16 for write mask, 0 for switch to new IP */
+ ret = regmap_write(grf, RK3288_GRF_PWM_ENABLE_OFFSET,
+ BIT(RK3288_GRF_PWM_ENABLE_BIT + 16) |
+ BIT(RK3288_GRF_PWM_ENABLE_BIT));
+ if (ret != 0) {
+ dev_err(>dev, "Could not access GRF: %d\n", ret);
+ return ret;
+ }
+ }
+
pc = devm_kzalloc(>dev, sizeof(*pc), GFP_KERNEL);
if (!pc)
return -ENOMEM;
--
2.1.0.rc2.206.gedb03e5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/4] ARM: dts: Enable PWM backlight on rk3288-evb
PWM0 is the PWM associated with the LCD backlight. Enable it.
Signed-off-by: Doug Anderson
---
Changes in v4: None
Changes in v3:
- Fix space to tab in 2 places in DTS.
- Make sure PWM is upper case in prose.
Changes in v2: None
arch/arm/boot/dts/rk3288-evb.dtsi | 53 +++
1 file changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
b/arch/arm/boot/dts/rk3288-evb.dtsi
index 2964370..98b69d0 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -10,6 +10,7 @@
* GNU General Public License for more details.
*/
+#include
#include "rk3288.dtsi"
/ {
@@ -17,6 +18,48 @@
reg = <0x0 0x8000>;
};
+ backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <
+ 0 1 2 3 4 5 6 7
+ 8 9 10 11 12 13 14 15
+16 17 18 19 20 21 22 23
+24 25 26 27 28 29 30 31
+32 33 34 35 36 37 38 39
+40 41 42 43 44 45 46 47
+48 49 50 51 52 53 54 55
+56 57 58 59 60 61 62 63
+64 65 66 67 68 69 70 71
+72 73 74 75 76 77 78 79
+80 81 82 83 84 85 86 87
+88 89 90 91 92 93 94 95
+96 97 98 99 100 101 102 103
+ 104 105 106 107 108 109 110 111
+ 112 113 114 115 116 117 118 119
+ 120 121 122 123 124 125 126 127
+ 128 129 130 131 132 133 134 135
+ 136 137 138 139 140 141 142 143
+ 144 145 146 147 148 149 150 151
+ 152 153 154 155 156 157 158 159
+ 160 161 162 163 164 165 166 167
+ 168 169 170 171 172 173 174 175
+ 176 177 178 179 180 181 182 183
+ 184 185 186 187 188 189 190 191
+ 192 193 194 195 196 197 198 199
+ 200 201 202 203 204 205 206 207
+ 208 209 210 211 212 213 214 215
+ 216 217 218 219 220 221 222 223
+ 224 225 226 227 228 229 230 231
+ 232 233 234 235 236 237 238 239
+ 240 241 242 243 244 245 246 247
+ 248 249 250 251 252 253 254 255>;
+ default-brightness-level = <128>;
+ enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_en>;
+ pwms = < 0 100 PWM_POLARITY_INVERTED>;
+ };
+
gpio-keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -81,6 +124,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -102,6 +149,12 @@
};
{
+ backlight {
+ bl_en: bl-en {
+ rockchip,pins = <7 2 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
buttons {
pwrbtn: pwrbtn {
rockchip,pins = <0 5 RK_FUNC_GPIO _pull_up>;
--
2.1.0.rc2.206.gedb03e5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched: Add wrapper for checking task_struct:: on_rq
Commit-ID: da0c1e65b51a289540159663aa4b90ba2366bc21
Gitweb: http://git.kernel.org/tip/da0c1e65b51a289540159663aa4b90ba2366bc21
Author: Kirill Tkhai
AuthorDate: Wed, 20 Aug 2014 13:47:32 +0400
Committer: Ingo Molnar
CommitDate: Wed, 20 Aug 2014 14:52:59 +0200
sched: Add wrapper for checking task_struct::on_rq
Implement task_on_rq_queued() and use it everywhere instead of
on_rq check. No functional changes.
The only exception is we do not use the wrapper in
check_for_tasks(), because it requires to export
task_on_rq_queued() in global header files. Next patch in series
would return it back, so we do not twist it from here to there.
Signed-off-by: Kirill Tkhai
Cc: Peter Zijlstra
Cc: Paul Turner
Cc: Oleg Nesterov
Cc: Steven Rostedt
Cc: Mike Galbraith
Cc: Kirill Tkhai
Cc: Tim Chen
Cc: Nicolas Pitre
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/1408528052.23412.87.camel@tkhai
Signed-off-by: Ingo Molnar
---
kernel/sched/core.c | 82
kernel/sched/deadline.c | 15 -
kernel/sched/fair.c | 22 ++---
kernel/sched/rt.c| 16 +-
kernel/sched/sched.h | 7 +
kernel/sched/stop_task.c | 2 +-
6 files changed, 76 insertions(+), 68 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4f2826f..a02b624 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1043,7 +1043,7 @@ void check_preempt_curr(struct rq *rq, struct task_struct
*p, int flags)
* A queue event has occurred, and we're going to schedule. In
* this case, we can save a useless back to back clock update.
*/
- if (rq->curr->on_rq && test_tsk_need_resched(rq->curr))
+ if (task_on_rq_queued(rq->curr) && test_tsk_need_resched(rq->curr))
rq->skip_clock_update = 1;
}
@@ -1088,7 +1088,7 @@ void set_task_cpu(struct task_struct *p, unsigned int
new_cpu)
static void __migrate_swap_task(struct task_struct *p, int cpu)
{
- if (p->on_rq) {
+ if (task_on_rq_queued(p)) {
struct rq *src_rq, *dst_rq;
src_rq = task_rq(p);
@@ -1214,7 +1214,7 @@ static int migration_cpu_stop(void *data);
unsigned long wait_task_inactive(struct task_struct *p, long match_state)
{
unsigned long flags;
- int running, on_rq;
+ int running, queued;
unsigned long ncsw;
struct rq *rq;
@@ -1252,7 +1252,7 @@ unsigned long wait_task_inactive(struct task_struct *p,
long match_state)
rq = task_rq_lock(p, );
trace_sched_wait_task(p);
running = task_running(rq, p);
- on_rq = p->on_rq;
+ queued = task_on_rq_queued(p);
ncsw = 0;
if (!match_state || p->state == match_state)
ncsw = p->nvcsw | LONG_MIN; /* sets MSB */
@@ -1284,7 +1284,7 @@ unsigned long wait_task_inactive(struct task_struct *p,
long match_state)
* running right now), it's preempted, and we should
* yield - it could be a while.
*/
- if (unlikely(on_rq)) {
+ if (unlikely(queued)) {
ktime_t to = ktime_set(0, NSEC_PER_SEC/HZ);
set_current_state(TASK_UNINTERRUPTIBLE);
@@ -1478,7 +1478,7 @@ ttwu_stat(struct task_struct *p, int cpu, int wake_flags)
static void ttwu_activate(struct rq *rq, struct task_struct *p, int en_flags)
{
activate_task(rq, p, en_flags);
- p->on_rq = 1;
+ p->on_rq = TASK_ON_RQ_QUEUED;
/* if a worker is waking up, notify workqueue */
if (p->flags & PF_WQ_WORKER)
@@ -1537,7 +1537,7 @@ static int ttwu_remote(struct task_struct *p, int
wake_flags)
int ret = 0;
rq = __task_rq_lock(p);
- if (p->on_rq) {
+ if (task_on_rq_queued(p)) {
/* check_preempt_curr() may use rq clock */
update_rq_clock(rq);
ttwu_do_wakeup(rq, p, wake_flags);
@@ -1678,7 +1678,7 @@ try_to_wake_up(struct task_struct *p, unsigned int state,
int wake_flags)
success = 1; /* we're going to change ->state */
cpu = task_cpu(p);
- if (p->on_rq && ttwu_remote(p, wake_flags))
+ if (task_on_rq_queued(p) && ttwu_remote(p, wake_flags))
goto stat;
#ifdef CONFIG_SMP
@@ -1742,7 +1742,7 @@ static void try_to_wake_up_local(struct task_struct *p)
if (!(p->state & TASK_NORMAL))
goto out;
- if (!p->on_rq)
+ if (!task_on_rq_queued(p))
ttwu_activate(rq, p, ENQUEUE_WAKEUP);
ttwu_do_wakeup(rq, p, 0);
@@ -2095,7 +2095,7 @@ void wake_up_new_task(struct task_struct *p)
init_task_runnable_average(p);
rq = __task_rq_lock(p);
activate_task(rq, p, 0);
- p->on_rq = 1;
+ p->on_rq = TASK_ON_RQ_QUEUED;
trace_sched_wakeup_new(p, true);
check_preempt_curr(rq, p,
[tip:sched/core] sched: Remove double_rq_lock() from __migrate_task()
Commit-ID: a1e01829796aa7a993e28ffd7fee5c8d525be175
Gitweb: http://git.kernel.org/tip/a1e01829796aa7a993e28ffd7fee5c8d525be175
Author: Kirill Tkhai
AuthorDate: Wed, 20 Aug 2014 13:47:50 +0400
Committer: Ingo Molnar
CommitDate: Wed, 20 Aug 2014 14:53:02 +0200
sched: Remove double_rq_lock() from __migrate_task()
Avoid double_rq_lock() and use TASK_ON_RQ_MIGRATING for
__migrate_task(). The advantage is (obviously) not holding two
rq->lock's at the same time and thereby increasing parallelism.
The important point to note is that because we acquire dst->lock
immediately after releasing src->lock the potential wait time of
task_rq_lock() callers on TASK_ON_RQ_MIGRATING is not longer
than it would have been in the double rq lock scenario.
Signed-off-by: Kirill Tkhai
Cc: Peter Zijlstra
Cc: Paul Turner
Cc: Oleg Nesterov
Cc: Steven Rostedt
Cc: Mike Galbraith
Cc: Kirill Tkhai
Cc: Tim Chen
Cc: Nicolas Pitre
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/1408528070.23412.89.camel@tkhai
Signed-off-by: Ingo Molnar
---
kernel/sched/core.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 71b8360..a773c91 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4679,20 +4679,20 @@ EXPORT_SYMBOL_GPL(set_cpus_allowed_ptr);
*/
static int __migrate_task(struct task_struct *p, int src_cpu, int dest_cpu)
{
- struct rq *rq_dest, *rq_src;
+ struct rq *rq;
int ret = 0;
if (unlikely(!cpu_active(dest_cpu)))
return ret;
- rq_src = cpu_rq(src_cpu);
- rq_dest = cpu_rq(dest_cpu);
+ rq = cpu_rq(src_cpu);
raw_spin_lock(>pi_lock);
- double_rq_lock(rq_src, rq_dest);
+ raw_spin_lock(>lock);
/* Already moved. */
if (task_cpu(p) != src_cpu)
goto done;
+
/* Affinity changed (again). */
if (!cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
goto fail;
@@ -4702,15 +4702,22 @@ static int __migrate_task(struct task_struct *p, int
src_cpu, int dest_cpu)
* placed properly.
*/
if (task_on_rq_queued(p)) {
- dequeue_task(rq_src, p, 0);
+ dequeue_task(rq, p, 0);
+ p->on_rq = TASK_ON_RQ_MIGRATING;
set_task_cpu(p, dest_cpu);
- enqueue_task(rq_dest, p, 0);
- check_preempt_curr(rq_dest, p, 0);
+ raw_spin_unlock(>lock);
+
+ rq = cpu_rq(dest_cpu);
+ raw_spin_lock(>lock);
+ BUG_ON(task_rq(p) != rq);
+ p->on_rq = TASK_ON_RQ_QUEUED;
+ enqueue_task(rq, p, 0);
+ check_preempt_curr(rq, p, 0);
}
done:
ret = 1;
fail:
- double_rq_unlock(rq_src, rq_dest);
+ raw_spin_unlock(>lock);
raw_spin_unlock(>pi_lock);
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched/fair: Remove double_lock_balance() from active_load_balance_cpu_stop()
Commit-ID: e5673f280501298dbb56efa46e333cf64ee5080a
Gitweb: http://git.kernel.org/tip/e5673f280501298dbb56efa46e333cf64ee5080a
Author: Kirill Tkhai
AuthorDate: Wed, 20 Aug 2014 13:48:01 +0400
Committer: Ingo Molnar
CommitDate: Wed, 20 Aug 2014 14:53:03 +0200
sched/fair: Remove double_lock_balance() from active_load_balance_cpu_stop()
Avoid double_rq_lock() and use the TASK_ON_RQ_MIGRATING state for
active_load_balance_cpu_stop(). The advantage is (obviously) not
holding two 'rq->lock's at the same time and thereby increasing
parallelism.
Further note that if there was no task to migrate we will not
have acquired the second rq->lock at all.
The important point to note is that because we acquire dst->lock
immediately after releasing src->lock the potential wait time of
task_rq_lock() callers on TASK_ON_RQ_MIGRATING is not longer
than it would have been in the double rq lock scenario.
Signed-off-by: Kirill Tkhai
Cc: Peter Zijlstra
Cc: Paul Turner
Cc: Oleg Nesterov
Cc: Steven Rostedt
Cc: Mike Galbraith
Cc: Kirill Tkhai
Cc: Tim Chen
Cc: Nicolas Pitre
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/1408528081.23412.92.camel@tkhai
Signed-off-by: Ingo Molnar
---
kernel/sched/fair.c | 60 +++--
1 file changed, 44 insertions(+), 16 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9e6ca0d..7e5cf05 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5138,6 +5138,8 @@ static int task_hot(struct task_struct *p, struct lb_env
*env)
{
s64 delta;
+ lockdep_assert_held(>src_rq->lock);
+
if (p->sched_class != _sched_class)
return 0;
@@ -5257,6 +5259,9 @@ static
int can_migrate_task(struct task_struct *p, struct lb_env *env)
{
int tsk_cache_hot = 0;
+
+ lockdep_assert_held(>src_rq->lock);
+
/*
* We do not migrate tasks that are:
* 1) throttled_lb_pair, or
@@ -5341,30 +5346,49 @@ int can_migrate_task(struct task_struct *p, struct
lb_env *env)
}
/*
- * move_one_task tries to move exactly one task from busiest to this_rq, as
+ * detach_one_task() -- tries to dequeue exactly one task from env->src_rq, as
* part of active balancing operations within "domain".
- * Returns 1 if successful and 0 otherwise.
*
- * Called with both runqueues locked.
+ * Returns a task if successful and NULL otherwise.
*/
-static int move_one_task(struct lb_env *env)
+static struct task_struct *detach_one_task(struct lb_env *env)
{
struct task_struct *p, *n;
+ lockdep_assert_held(>src_rq->lock);
+
list_for_each_entry_safe(p, n, >src_rq->cfs_tasks, se.group_node) {
if (!can_migrate_task(p, env))
continue;
- move_task(p, env);
+ deactivate_task(env->src_rq, p, 0);
+ p->on_rq = TASK_ON_RQ_MIGRATING;
+ set_task_cpu(p, env->dst_cpu);
+
/*
-* Right now, this is only the second place move_task()
-* is called, so we can safely collect move_task()
-* stats here rather than inside move_task().
+* Right now, this is only the second place where
+* lb_gained[env->idle] is updated (other is move_tasks)
+* so we can safely collect stats here rather than
+* inside move_tasks().
*/
schedstat_inc(env->sd, lb_gained[env->idle]);
- return 1;
+ return p;
}
- return 0;
+ return NULL;
+}
+
+/*
+ * attach_one_task() -- attaches the task returned from detach_one_task() to
+ * its new rq.
+ */
+static void attach_one_task(struct rq *rq, struct task_struct *p)
+{
+ raw_spin_lock(>lock);
+ BUG_ON(task_rq(p) != rq);
+ p->on_rq = TASK_ON_RQ_QUEUED;
+ activate_task(rq, p, 0);
+ check_preempt_curr(rq, p, 0);
+ raw_spin_unlock(>lock);
}
static const unsigned int sched_nr_migrate_break = 32;
@@ -6943,6 +6967,7 @@ static int active_load_balance_cpu_stop(void *data)
int target_cpu = busiest_rq->push_cpu;
struct rq *target_rq = cpu_rq(target_cpu);
struct sched_domain *sd;
+ struct task_struct *p = NULL;
raw_spin_lock_irq(_rq->lock);
@@ -6962,9 +6987,6 @@ static int active_load_balance_cpu_stop(void *data)
*/
BUG_ON(busiest_rq == target_rq);
- /* move a task from busiest_rq to target_rq */
- double_lock_balance(busiest_rq, target_rq);
-
/* Search for an sd spanning us and the target CPU. */
rcu_read_lock();
for_each_domain(target_cpu, sd) {
@@ -6985,16 +7007,22 @@ static int active_load_balance_cpu_stop(void *data)
schedstat_inc(sd, alb_count);
- if (move_one_task())
+ p = detach_one_task();
+ if (p)
schedstat_inc(sd, alb_pushed);
[tip:sched/core] sched/fair: Remove double_lock_balance() from load_balance()
Commit-ID: 163122b7fcfa28c0e4a838fcc8043c616746802e
Gitweb: http://git.kernel.org/tip/163122b7fcfa28c0e4a838fcc8043c616746802e
Author: Kirill Tkhai
AuthorDate: Wed, 20 Aug 2014 13:48:29 +0400
Committer: Ingo Molnar
CommitDate: Wed, 20 Aug 2014 14:53:05 +0200
sched/fair: Remove double_lock_balance() from load_balance()
Avoid double_rq_lock() and use TASK_ON_RQ_MIGRATING for
load_balance(). The advantage is (obviously) not holding two
rq->lock's at the same time and thereby increasing parallelism.
Further note that if there was no task to migrate we will not
have acquired the second rq->lock at all.
The important point to note is that because we acquire dst->lock
immediately after releasing src->lock the potential wait time of
task_rq_lock() callers on TASK_ON_RQ_MIGRATING is not longer
than it would have been in the double rq lock scenario.
Signed-off-by: Kirill Tkhai
Cc: Peter Zijlstra
Cc: Paul Turner
Cc: Oleg Nesterov
Cc: Steven Rostedt
Cc: Mike Galbraith
Cc: Kirill Tkhai
Cc: Tim Chen
Cc: Nicolas Pitre
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/1408528109.23412.94.camel@tkhai
Signed-off-by: Ingo Molnar
---
kernel/sched/fair.c | 151 ++--
1 file changed, 99 insertions(+), 52 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7e5cf05..d3427a8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4709,7 +4709,7 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p, int wake_
return;
/*
-* This is possible from callers such as move_task(), in which we
+* This is possible from callers such as attach_tasks(), in which we
* unconditionally check_prempt_curr() after an enqueue (which may have
* lead to a throttle). This both saves work and prevents false
* next-buddy nomination below.
@@ -5117,21 +5117,10 @@ struct lb_env {
unsigned intloop_max;
enum fbq_type fbq_type;
+ struct list_headtasks;
};
/*
- * move_task - move a task from one runqueue to another runqueue.
- * Both runqueues must be locked.
- */
-static void move_task(struct task_struct *p, struct lb_env *env)
-{
- deactivate_task(env->src_rq, p, 0);
- set_task_cpu(p, env->dst_cpu);
- activate_task(env->dst_rq, p, 0);
- check_preempt_curr(env->dst_rq, p, 0);
-}
-
-/*
* Is this task likely cache-hot:
*/
static int task_hot(struct task_struct *p, struct lb_env *env)
@@ -5346,6 +5335,18 @@ int can_migrate_task(struct task_struct *p, struct
lb_env *env)
}
/*
+ * detach_task() -- detach the task for the migration specified in env
+ */
+static void detach_task(struct task_struct *p, struct lb_env *env)
+{
+ lockdep_assert_held(>src_rq->lock);
+
+ deactivate_task(env->src_rq, p, 0);
+ p->on_rq = TASK_ON_RQ_MIGRATING;
+ set_task_cpu(p, env->dst_cpu);
+}
+
+/*
* detach_one_task() -- tries to dequeue exactly one task from env->src_rq, as
* part of active balancing operations within "domain".
*
@@ -5361,15 +5362,13 @@ static struct task_struct *detach_one_task(struct
lb_env *env)
if (!can_migrate_task(p, env))
continue;
- deactivate_task(env->src_rq, p, 0);
- p->on_rq = TASK_ON_RQ_MIGRATING;
- set_task_cpu(p, env->dst_cpu);
+ detach_task(p, env);
/*
* Right now, this is only the second place where
-* lb_gained[env->idle] is updated (other is move_tasks)
+* lb_gained[env->idle] is updated (other is detach_tasks)
* so we can safely collect stats here rather than
-* inside move_tasks().
+* inside detach_tasks().
*/
schedstat_inc(env->sd, lb_gained[env->idle]);
return p;
@@ -5377,35 +5376,22 @@ static struct task_struct *detach_one_task(struct
lb_env *env)
return NULL;
}
-/*
- * attach_one_task() -- attaches the task returned from detach_one_task() to
- * its new rq.
- */
-static void attach_one_task(struct rq *rq, struct task_struct *p)
-{
- raw_spin_lock(>lock);
- BUG_ON(task_rq(p) != rq);
- p->on_rq = TASK_ON_RQ_QUEUED;
- activate_task(rq, p, 0);
- check_preempt_curr(rq, p, 0);
- raw_spin_unlock(>lock);
-}
-
static const unsigned int sched_nr_migrate_break = 32;
/*
- * move_tasks tries to move up to imbalance weighted load from busiest to
- * this_rq, as part of a balancing operation within domain "sd".
- * Returns 1 if successful and 0 otherwise.
+ * detach_tasks() -- tries to detach up to imbalance weighted load from
+ * busiest_rq, as part of a balancing operation within domain "sd".
*
- * Called with both runqueues locked.
+ * Returns number of detached tasks if successful and 0 otherwise.
*/
-static int move_tasks(struct
[tip:sched/core] sched: Teach scheduler to understand TASK_ON_RQ_MIGRATING state
Commit-ID: cca26e8009d1939a6a5bf0200d276fa26f03e536
Gitweb: http://git.kernel.org/tip/cca26e8009d1939a6a5bf0200d276fa26f03e536
Author: Kirill Tkhai
AuthorDate: Wed, 20 Aug 2014 13:47:42 +0400
Committer: Ingo Molnar
CommitDate: Wed, 20 Aug 2014 14:53:00 +0200
sched: Teach scheduler to understand TASK_ON_RQ_MIGRATING state
This is a new p->on_rq state which will be used to indicate that a task
is in a process of migrating between two RQs. It allows to get
rid of double_rq_lock(), which we used to use to change a rq of
a queued task before.
Let's consider an example. To move a task between src_rq and
dst_rq we will do the following:
raw_spin_lock(_rq->lock);
/* p is a task which is queued on src_rq */
p = ...;
dequeue_task(src_rq, p, 0);
p->on_rq = TASK_ON_RQ_MIGRATING;
set_task_cpu(p, dst_cpu);
raw_spin_unlock(_rq->lock);
/*
* Both RQs are unlocked here.
* Task p is dequeued from src_rq
* but its on_rq value is not zero.
*/
raw_spin_lock(_rq->lock);
p->on_rq = TASK_ON_RQ_QUEUED;
enqueue_task(dst_rq, p, 0);
raw_spin_unlock(_rq->lock);
While p->on_rq is TASK_ON_RQ_MIGRATING, task is considered as
"migrating", and other parallel scheduler actions with it are
not available to parallel callers. The parallel caller is
spining till migration is completed.
The unavailable actions are changing of cpu affinity, changing
of priority etc, in other words all the functionality which used
to require task_rq(p)->lock before (and related to the task).
To implement TASK_ON_RQ_MIGRATING support we primarily are using
the following fact. Most of scheduler users (from which we are
protecting a migrating task) use task_rq_lock() and
__task_rq_lock() to get the lock of task_rq(p). These primitives
know that task's cpu may change, and they are spining while the
lock of the right RQ is not held. We add one more condition into
them, so they will be also spinning until the migration is
finished.
Signed-off-by: Kirill Tkhai
Cc: Peter Zijlstra
Cc: Paul Turner
Cc: Oleg Nesterov
Cc: Steven Rostedt
Cc: Mike Galbraith
Cc: Kirill Tkhai
Cc: Tim Chen
Cc: Nicolas Pitre
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/1408528062.23412.88.camel@tkhai
Signed-off-by: Ingo Molnar
---
kernel/sched/core.c | 12 +---
kernel/sched/sched.h | 6 ++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a02b624..71b8360 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -333,9 +333,12 @@ static inline struct rq *__task_rq_lock(struct task_struct
*p)
for (;;) {
rq = task_rq(p);
raw_spin_lock(>lock);
- if (likely(rq == task_rq(p)))
+ if (likely(rq == task_rq(p) && !task_on_rq_migrating(p)))
return rq;
raw_spin_unlock(>lock);
+
+ while (unlikely(task_on_rq_migrating(p)))
+ cpu_relax();
}
}
@@ -352,10 +355,13 @@ static struct rq *task_rq_lock(struct task_struct *p,
unsigned long *flags)
raw_spin_lock_irqsave(>pi_lock, *flags);
rq = task_rq(p);
raw_spin_lock(>lock);
- if (likely(rq == task_rq(p)))
+ if (likely(rq == task_rq(p) && !task_on_rq_migrating(p)))
return rq;
raw_spin_unlock(>lock);
raw_spin_unlock_irqrestore(>pi_lock, *flags);
+
+ while (unlikely(task_on_rq_migrating(p)))
+ cpu_relax();
}
}
@@ -1678,7 +1684,7 @@ try_to_wake_up(struct task_struct *p, unsigned int state,
int wake_flags)
success = 1; /* we're going to change ->state */
cpu = task_cpu(p);
- if (task_on_rq_queued(p) && ttwu_remote(p, wake_flags))
+ if (p->on_rq && ttwu_remote(p, wake_flags))
goto stat;
#ifdef CONFIG_SMP
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 26566d0..aa0f73b 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -17,6 +17,7 @@ struct rq;
/* task_struct::on_rq states: */
#define TASK_ON_RQ_QUEUED 1
+#define TASK_ON_RQ_MIGRATING 2
extern __read_mostly int scheduler_running;
@@ -950,6 +951,11 @@ static inline int task_on_rq_queued(struct task_struct *p)
return p->on_rq == TASK_ON_RQ_QUEUED;
}
+static inline int task_on_rq_migrating(struct task_struct *p)
+{
+ return p->on_rq == TASK_ON_RQ_MIGRATING;
+}
+
#ifndef prepare_arch_switch
# define prepare_arch_switch(next) do { } while (0)
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/uv] x86/apic/uv: Remove unnecessary #ifdef
Commit-ID: 8091c1f8ea2374695c105591179b1269fb5f2fbb
Gitweb: http://git.kernel.org/tip/8091c1f8ea2374695c105591179b1269fb5f2fbb
Author: Andreas Ruprecht
AuthorDate: Wed, 20 Aug 2014 10:16:01 +0200
Committer: Ingo Molnar
CommitDate: Wed, 20 Aug 2014 15:05:30 +0200
x86/apic/uv: Remove unnecessary #ifdef
In the file x2apic_uv_x.c, some code is compiled conditionally
depending on CONFIG_SMP. However, the file is only built, if
CONFIG_X86_UV is enabled.
CONFIG_X86_UV depends on CONFIG_NUMA, which itself depends on
CONFIG_SMP, so the #ifdef will always evaluate to true, if the
file is compiled. Thus, it is unnecessary and can be removed.
Signed-off-by: Andreas Ruprecht
Cc: David Rientjes
Cc: Dimitri Sivanich
Cc: Hedi Berriche
Cc: Linus Torvalds
Cc: Mike Travis
Cc: Russ Anderson
Link:
http://lkml.kernel.org/r/1408522561-23389-1-git-send-email-rup...@einserver.de
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/apic/x2apic_uv_x.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 293b41d..2f1b5e0 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -204,7 +204,6 @@ EXPORT_SYMBOL(sn_rtc_cycles_per_second);
static int uv_wakeup_secondary(int phys_apicid, unsigned long start_rip)
{
-#ifdef CONFIG_SMP
unsigned long val;
int pnode;
@@ -223,7 +222,6 @@ static int uv_wakeup_secondary(int phys_apicid, unsigned
long start_rip)
uv_write_global_mmr64(pnode, UVH_IPI_INT, val);
atomic_set(_deasserted, 1);
-#endif
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Automatically pull missing FW files
On Wed, 2014-08-20 at 11:21 -0700, Tadeusz Struk wrote: > Hi, > When a binary FW file is not present in the firmware dir then the > build will fail. I'm not sure I understand. Precisely what fails? I don't like this patch very much. We should be removing the legacy firmware/ directory entirely, not patching it up. Userspace is responsible for providing the firmware, and it should generally come from an entirely separate checkout of the linux-firmware repository. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
[RFCv2 3/4] target: Add a user-passthrough backstore
Add a LIO storage engine that presents commands to userspace for execution.
This would allow more complex backstores to be implemented out-of-kernel,
and also make experimentation a-la FUSE (but at the SCSI level -- "SUSE"?)
possible.
It uses a mmap()able UIO device per LUN to share a command ring and data
area. The commands are raw SCSI CDBs and iovs for in/out data. The command
ring is also reused for scsi command status and sense data, if present.
This implementation is based on Shaohua Li's earlier version but heavily
modified. Differences include:
* Shared memory allocated by kernel, not locked-down user pages
* Single ring for command request and response
* Offsets instead of embedded pointers
* Generic SCSI CDB passthrough instead of per-cmd specialization in ring
format.
* Uses UIO device instead of anon_file passed in mailbox.
* Optional in-kernel handling of some commands.
The main reason for these differences is to permit greater resiliency
if the user process dies or hangs.
Things not yet implemented (on purpose):
* Zero copy. The data area is flexible enough to allow page flipping or
backend-allocated pages to be used by fabrics, but it's not clear these
are performance wins. Can come later.
* Out-of-order command completion by userspace. Possible to add by just
allowing userspace to change cmd_id in rsp cmd entries, but currently
not supported.
* No locks between kernel cmd submission and completion routines. Sounds
like it's possible, but this can come later.
* Sparse allocation of mmaped area. Current code vmallocs the whole thing.
If the mapped area was larger and not fully mapped then the driver would
have more freedom to change cmd and data area sizes based on demand.
Current code open issues:
* The use of idrs may be overkill -- we maybe can replace them with a
simple counter to generate cmd_ids, and a hash table to get a cmd_id's
associated pointer.
* Use of a free-running counter for cmd ring instead of explicit modulo
math. This would require power-of-2 cmd ring size.
* Random printks in code, still.
Signed-off-by: Andy Grover
---
drivers/target/Kconfig |5 +
drivers/target/Makefile|1 +
drivers/target/target_core_transport.c |4 +
drivers/target/target_core_user.c | 1158
include/uapi/linux/Kbuild |1 +
include/uapi/linux/target_core_user.h | 142
6 files changed, 1311 insertions(+)
create mode 100644 drivers/target/target_core_user.c
create mode 100644 include/uapi/linux/target_core_user.h
diff --git a/drivers/target/Kconfig b/drivers/target/Kconfig
index dc2d84a..b03a845 100644
--- a/drivers/target/Kconfig
+++ b/drivers/target/Kconfig
@@ -31,6 +31,11 @@ config TCM_PSCSI
Say Y here to enable the TCM/pSCSI subsystem plugin for non-buffered
passthrough access to Linux/SCSI device
+config TCM_USER
+ tristate "TCM/USER Subsystem Plugin for Linux"
+ help
+ Say Y here to enable the TCM/USER subsystem plugin
+
source "drivers/target/loopback/Kconfig"
source "drivers/target/tcm_fc/Kconfig"
source "drivers/target/iscsi/Kconfig"
diff --git a/drivers/target/Makefile b/drivers/target/Makefile
index 85b012d..bbb4a7d 100644
--- a/drivers/target/Makefile
+++ b/drivers/target/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_TARGET_CORE) += target_core_mod.o
obj-$(CONFIG_TCM_IBLOCK) += target_core_iblock.o
obj-$(CONFIG_TCM_FILEIO) += target_core_file.o
obj-$(CONFIG_TCM_PSCSI)+= target_core_pscsi.o
+obj-$(CONFIG_TCM_USER) += target_core_user.o
# Fabric modules
obj-$(CONFIG_LOOPBACK_TARGET) += loopback/
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index 7fa62fc..f018a8c 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -232,6 +232,10 @@ void transport_subsystem_check_init(void)
if (ret != 0)
pr_err("Unable to load target_core_pscsi\n");
+ ret = request_module("target_core_user");
+ if (ret != 0)
+ pr_err("Unable to load target_core_user\n");
+
sub_api_initialized = 1;
}
diff --git a/drivers/target/target_core_user.c
b/drivers/target/target_core_user.c
new file mode 100644
index 000..d959e04
--- /dev/null
+++ b/drivers/target/target_core_user.c
@@ -0,0 +1,1158 @@
+/*
+ * Copyright (C) 2013 Shaohua Li
+ * Copyright (C) 2014 Red Hat, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received
[RFCv2 4/4] target: Add documentation on the target userspace pass-through driver
Describes the driver and its interface to make it possible for user
programs to back a LIO-exported LUN.
Signed-off-by: Andy Grover
---
Documentation/target/tcmu-design.txt | 229 +++
1 file changed, 229 insertions(+)
create mode 100644 Documentation/target/tcmu-design.txt
diff --git a/Documentation/target/tcmu-design.txt
b/Documentation/target/tcmu-design.txt
new file mode 100644
index 000..1012fe4
--- /dev/null
+++ b/Documentation/target/tcmu-design.txt
@@ -0,0 +1,229 @@
+TCM Userspace Design
+
+
+
+Background:
+
+In addition to modularizing the transport protocol used for carrying
+SCSI commands ("fabrics"), the Linux kernel target, LIO, also modularizes
+the actual data storage as well. These are referred to as "backstores"
+or "storage engines". The target comes with backstores that allow a
+file, a block device, RAM, or another SCSI device to be used for the
+local storage needed for the exported SCSI LUN. Like the rest of LIO,
+these are implemented entirely as kernel code.
+
+These backstores cover the most common use cases, but not all. One new
+use case that other non-kernel target solutions, such as tgt, are able
+to support is using Gluster's GLFS or Ceph's RBD as a backstore. The
+target then serves as a translator, allowing initiators to store data
+in these non-traditional networked storage systems, while still only
+using standard protocols themselves.
+
+If the target is a userspace process, supporting these is easy. tgt,
+for example, needs only a small adapter module for each, because the
+modules just use the available userspace libraries for RBD and GLFS.
+
+Adding support for these backstores in LIO is considerably more
+difficult, because LIO is entirely kernel code. Instead of undertaking
+the significant work to port the GLFS or RBD APIs and protocols to the
+kernel, another approach is to create a userspace pass-through
+backstore for LIO, "TCMU".
+
+
+Benefits:
+
+In addition to allowing relatively easy support for RBD and GLFS, TCMU
+will also allow easier development of new backstores. TCMU combines
+with the LIO loopback fabric to become something similar to FUSE
+(Filesystem in Userspace), but at the SCSI layer instead of the
+filesystem layer. A SUSE, if you will.
+
+The disadvantage is there are more distinct components to configure, and
+potentially to malfunction. This is unavoidable, but hopefully not
+fatal if we're careful to keep things as simple as possible.
+
+Design constraints:
+
+- Good performance: high throughput, low latency
+- Cleanly handle if userspace:
+ 1) never attaches
+ 2) hangs
+ 3) dies
+ 4) misbehaves
+- Allow future flexibility in user & kernel implementations
+- Be reasonably memory-efficient
+- Simple to configure & run
+- Simple to write a userspace backend
+
+
+Implementation overview:
+
+The core of the TCMU interface is a memory region that is shared
+between kernel and userspace. Within this region is: a control area
+(mailbox); a lockless producer/consumer circular buffer for commands
+to be passed up, and status returned; and an in/out data buffer area.
+
+TCMU uses the pre-existing UIO subsystem. UIO allows device driver
+development in userspace, and this is conceptually very close to the
+TCMU use case, except instead of a physical device, TCMU implements a
+memory-mapped layout designed for SCSI commands. Using UIO also
+benefits TCMU by handling device introspection (e.g. a way for
+userspace to determine how large the shared region is) and signaling
+mechanisms in both directions.
+
+There are no embedded pointers in the memory region. Everything is
+expressed as an offset from the region's starting address. This allows
+the ring to still work if the user process dies and is restarted with
+the region mapped at a different virtual address.
+
+See target_core_user.h for the struct definitions.
+
+The Mailbox:
+
+The mailbox is always at the start of the shared memory region, and
+contains a version, details about the starting offset and size of the
+command ring, and head and tail pointers to be used by the kernel and
+userspace (respectively) to put commands on the ring, and indicate
+when the commands are completed.
+
+version - 1 (userspace should abort if otherwise)
+flags - none yet defined.
+cmdr_off - The offset of the start of the command ring from the start
+of the memory region, to account for the mailbox size.
+cmdr_size - The size of the command ring. This does *not* need to be a
+power of two.
+cmd_head - Modified by the kernel to indicate when a command has been
+placed on the ring.
+cmd_tail - Modified by userspace to indicate when it has completed
+processing of a command.
+
+The Command Ring:
+
+Commands are placed on the ring by the kernel incrementing
+mailbox.cmd_head by the size of the command, modulo cmdr_size, and
+then signaling userspace via uio_event_notify(). Once the command is
+completed, userspace updates mailbox.cmd_tail in the same
[RFCv2 0/4] Userspace pass-through storage engine (backend)
Hi all, Here is version two of the userspace passthrough backstore code I've been working on. You can find some documentation on the design in last patch. Please let me know what you think about the design and the code. Thanks -- Andy Changes since version 1: * Use netlink for reporting device add/removes to userspace * Remove pass_level in favor of automatic emulation of commands when userspace doesn't support them * Implemented 'tcmu-runner' daemon to handle the user side of the interface and make writing handlers easier (not in this patchset, see https://github.com/agrover/tcmu-runner). * Many bug fixes. Can now successfully partition, format, and use a TCMU-backed volume. * Two small patches added for other changes we need. Operation: * Using https://github.com/agrover/targetcli-fb/commits/userback and https://github.com/agrover/rtslib-fb/commits/userback, create a user storage object and give it a size, and 'file/foo.img' as config parameter * Start tcmu-runner (manually for now) * Create a loopback fabric and link the above storage object to it Andy Grover (4): target: Remove unneeded check in sbc_parse_cdb uio: Export definition of struct uio_device target: Add a user-passthrough backstore target: Add documentation on the target userspace pass-through driver Documentation/target/tcmu-design.txt | 229 +++ drivers/target/Kconfig |5 + drivers/target/Makefile|1 + drivers/target/target_core_sbc.c |2 +- drivers/target/target_core_transport.c |4 + drivers/target/target_core_user.c | 1158 drivers/uio/uio.c | 12 - include/linux/uio_driver.h | 12 +- include/uapi/linux/Kbuild |1 + include/uapi/linux/target_core_user.h | 142 10 files changed, 1552 insertions(+), 14 deletions(-) create mode 100644 Documentation/target/tcmu-design.txt create mode 100644 drivers/target/target_core_user.c create mode 100644 include/uapi/linux/target_core_user.h -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFCv2 1/4] target: Remove unneeded check in sbc_parse_cdb
The check of SCF_SCSI_DATA_CDB seems to be a remnant from before hch's
refactoring of this function. There are no places where that flag is set
that cmd->execute_cmd isn't also set.
Signed-off-by: Andy Grover
---
drivers/target/target_core_sbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index bd78d92..ebe62af 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -948,7 +948,7 @@ sbc_parse_cdb(struct se_cmd *cmd, struct sbc_ops *ops)
}
/* reject any command that we don't have a handler for */
- if (!(cmd->se_cmd_flags & SCF_SCSI_DATA_CDB) && !cmd->execute_cmd)
+ if (!cmd->execute_cmd)
return TCM_UNSUPPORTED_SCSI_OPCODE;
if (cmd->se_cmd_flags & SCF_SCSI_DATA_CDB) {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFCv2 2/4] uio: Export definition of struct uio_device
In order to prevent a O(n) search of the filesystem to link up its uio
node with its target configuration, TCMU needs to know the minor number
that UIO assigned. Expose the definition of this struct so TCMU can
access this field.
Signed-off-by: Andy Grover
---
drivers/uio/uio.c | 12
include/linux/uio_driver.h | 12 +++-
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index a673e5b..60fa627 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -28,18 +28,6 @@
#define UIO_MAX_DEVICES(1U << MINORBITS)
-struct uio_device {
- struct module *owner;
- struct device *dev;
- int minor;
- atomic_tevent;
- struct fasync_struct*async_queue;
- wait_queue_head_t wait;
- struct uio_info *info;
- struct kobject *map_dir;
- struct kobject *portio_dir;
-};
-
static int uio_major;
static struct cdev *uio_cdev;
static DEFINE_IDR(uio_idr);
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 1ad4724..baa8171 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -63,7 +63,17 @@ struct uio_port {
#define MAX_UIO_PORT_REGIONS 5
-struct uio_device;
+struct uio_device {
+struct module *owner;
+struct device *dev;
+int minor;
+atomic_tevent;
+struct fasync_struct*async_queue;
+wait_queue_head_t wait;
+struct uio_info *info;
+struct kobject *map_dir;
+struct kobject *portio_dir;
+};
/**
* struct uio_info - UIO device capabilities
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] firmware: Automatically pull missing FW files
Hi, When a binary FW file is not present in the firmware dir then the build will fail. This patch enables auto-download any missing FW file for both shipped and external targets. Generated against linux-next. Signed-off-by: Tadeusz Struk --- firmware/Makefile | 25 +++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/firmware/Makefile b/firmware/Makefile index 5747417..3ad12f6 100644 --- a/firmware/Makefile +++ b/firmware/Makefile @@ -178,10 +178,31 @@ wordsize_deps := $(wildcard include/config/64bit.h include/config/32bit.h \ include/config/superh32.h include/config/superh64.h \ include/config/x86_32.h include/config/x86_64.h) -$(patsubst %,$(obj)/%.gen.S, $(fw-shipped-y)): %: $(wordsize_deps) +FW_URL := git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/plain + +.NOTPARALLEL: get_missing_external $(patsubst %,$(obj)/%.gen.S, $(fw-external-y)) +.NOTPARALLEL: get_missing_shipped $(patsubst %,$(obj)/%.gen.S, $(fw-shipped-y)) + +get_missing_shipped: + @for file in $(fw-shipped-y) $(fw-shipped-m); do \ + if [ ! -f $(obj)/$$file ]; then \ + wget $(FW_URL)/$$file -o /dev/null -O $(obj)/$$file; \ + fi; \ + done; + +get_missing_external: + @for file in $(fw-external-y); do \ + if [ ! -f $(obj)/$$file ]; then \ + wget $(FW_URL)/$$file -o /dev/null -O $(obj)/$$file; \ + fi; \ + done; + +$(patsubst %,$(obj)/%.gen.S, $(fw-shipped-y)): %: $(wordsize_deps) \ + get_missing_shipped $(call cmd,fwbin,$(patsubst %.gen.S,%,$@)) + $(patsubst %,$(obj)/%.gen.S, $(fw-external-y)): %: $(wordsize_deps) \ - include/config/extra/firmware/dir.h + include/config/extra/firmware/dir.h get_missing_external $(call cmd,fwbin,$(fwabs)/$(patsubst $(obj)/%.gen.S,%,$@)) # The .o files depend on the binaries directly; the .S files don't. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Wed, Jul 23, 2014 at 03:33:23PM +0100, Peter Griffin wrote: > > > > > + reset_control_assert(dwc3_data->rstc_pwrdn); > > > > > + > > > > > + pinctrl_pm_select_sleep_state(dev); > > > > pinctrl will select sleep and default states automatically for you. > > I've left this in v3, as greping around I couldn't see how that could > happen automatically. > > Also I just double checked with linusw on irc who confirmed that the > only state which is ever auto-selected is "default". All other states, > as well as going back to default state need to be explicitly called. > > Hope thats ok. yeah, that's fine. Thanks :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] Revert "platform/x86/toshiba-apci.c possible bad if test?"
On Wed, 20 Aug 2014, Ari Sundholm wrote: > - if (sscanf(buf, "%i", ) != 1 || (mode != 2 || mode != 1)) > + if (sscanf(buf, "%i", ) != 1 && (mode != 2 || mode != 1)) > return -EINVAL; Note that the condition still looks wrong even after the revert, as (mode != 2 || mode != 1) is always true. Anybody guess what the actual intent was? Best regards, Ari Sundholm asund...@cs.hut.fi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel crypto API: cryptoperf performance measurement
On 08/20/2014 03:25 PM, Jussi Kivilinna wrote: >> One to four GB per second for XTS? 12 GB per second for AES CBC? Somehow >> that >> does not sound right. > > Agreed, those do not look correct... I wonder what happened there. On > new run, I got more sane results: Which cryptsetup version are you using? There was a bug in that test on fast machines (fixed in 1.6.3, I hope :) But anyway, it is not intended as rigorous speed test, it was intended for comparison of ciphers speed on particular machine. Test basically tries to encrypt 1MB block (or multiple of this if machine is too fast). All it runs through kernel userspace crypto API interface. (Real FDE is always slower because it runs over 512bytes blocks.) Milan > > # Algorithm | Key | Encryption | Decryption > aes-cbc 128b 139,1 MiB/s 1713,6 MiB/s > serpent-cbc 128b62,2 MiB/s 232,9 MiB/s > twofish-cbc 128b 116,3 MiB/s 243,7 MiB/s > aes-cbc 256b 375,1 MiB/s 1159,4 MiB/s > serpent-cbc 256b62,1 MiB/s 214,9 MiB/s > twofish-cbc 256b 139,3 MiB/s 217,5 MiB/s > aes-xts 256b 1296,4 MiB/s 1272,5 MiB/s > serpent-xts 256b 283,3 MiB/s 275,6 MiB/s > twofish-xts 256b 294,8 MiB/s 299,3 MiB/s > aes-xts 512b 984,3 MiB/s 991,1 MiB/s > serpent-xts 512b 227,7 MiB/s 220,6 MiB/s > twofish-xts 512b 220,6 MiB/s 220,2 MiB/s > > -Jussi > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] usb-phy: samsung: Cleanup the unused drivers
Hi, On Thu, Aug 14, 2014 at 07:53:53PM +0530, Vivek Gautam wrote: > - This series is based on 'usb-next' branch. > > Now that we have support for USB PHY controllers for Exynos SoC series, > we are free to remove the older usb-phy support. > In the process, we are removing the entire phy-samsung-usb3 driver, and > besides that all support for Exynos4x and Exynos5 from phy-samsung-usb2 > driver. > > We have also removed the older USB-PHY support from ehci-exynos and > ohci-exynos > since those drivers now can use newer GENERIC-PHYs, and don't need the older > USB-PHYs and related code anymore. These patches for ohci-exynos and > ehci-exynos > now replaces the older sent patch for phy sequence cleanup for them.[1] > > I have build-tested this series for exynos_defconfig and s3c64xx_defconfig, > and have tested the EHCI and OHCI operations on smdk5250 board, but > have not tested the actual working due to unavailability of S3C64XX > board. So can someone please help me testing this series. > > [1] https://lkml.org/lkml/2014/8/5/142 > > Vivek Gautam (7): > usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver > usb-phy: samsung-usb2: Remove support for Exynos5250 > usb-phy: samsung-usb2: Remove support for Exynos4X12 > usb-phy: samsung-usb2: Remove support for Exynos4210 > usb-phy: samsung-usb2: Clean up to leave only S3C64XX support > usb: host: ehci-exynos: Remove unnecessary usb-phy support > usb: host: ohci-exynos: Remove unnecessary usb-phy support some of these patches are still RFC, can you resend without RFC and all proper Acks in place ? Also rebased on top of v3.17-rc1. thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/5] usb: phy: samsung: remove old USB PHY code
Hi, On Thu, Aug 14, 2014 at 04:25:22PM +0200, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series removes the old Samsung USB PHY drivers that > got replaced by the new ones using the generic PHY layer. > > Depends on: > - next-20140813 branch of linux-next kernel this thread seems to have died, what do I need to do with these patches? Are we deleting the phy drivers or not ? Please rebase on v3.17-rc1 and resend with all Acks in place. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi,
On Wed, Jul 30, 2014 at 04:28:09PM +0100, Peter Griffin wrote:
> This patch adds the ST glue logic to manage the DWC3 HC
> on STiH407 SoC family. It manages the powerdown signal,
> and configures the internal glue logic and syscfg registers.
>
> Signed-off-by: Giuseppe Cavallaro
> Signed-off-by: Peter Griffin
> Acked-by: Lee Jones
> ---
> drivers/usb/dwc3/Kconfig | 9 ++
> drivers/usb/dwc3/Makefile | 1 +
> drivers/usb/dwc3/dwc3-st.c | 336
> +
> 3 files changed, 346 insertions(+)
> create mode 100644 drivers/usb/dwc3/dwc3-st.c
>
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index 8eb996e..6c85c43 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -79,6 +79,15 @@ config USB_DWC3_KEYSTONE
> Support of USB2/3 functionality in TI Keystone2 platforms.
> Say 'Y' or 'M' here if you have one such device
>
> +config USB_DWC3_ST
> + tristate "STMicroelectronics Platforms"
> + depends on ARCH_STI && OF
> + default USB_DWC3_HOST
this seems wrong as USB_DWC3_{HOST,GADGET,DUAL_ROLE} are booleans and
USB_DWC3_ST is a tristate. Better to stick with defaulting to USB_DWC3
instead like all the others.
> + help
> + STMicroelectronics SoCs with one DesignWare Core USB3 IP
> + inside (i.e. STiH407).
> + Say 'Y' or 'M' if you have one such device.
> +
> comment "Debugging features"
>
> config USB_DWC3_DEBUG
> diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> index 10ac3e7..11c9f54 100644
> --- a/drivers/usb/dwc3/Makefile
> +++ b/drivers/usb/dwc3/Makefile
> @@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
> obj-$(CONFIG_USB_DWC3_EXYNOS)+= dwc3-exynos.o
> obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
> obj-$(CONFIG_USB_DWC3_KEYSTONE) += dwc3-keystone.o
> +obj-$(CONFIG_USB_DWC3_ST)+= dwc3-st.o
> diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
> new file mode 100644
> index 000..227698f
> --- /dev/null
> +++ b/drivers/usb/dwc3/dwc3-st.c
> @@ -0,0 +1,336 @@
> +/**
> + * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics
> platforms
> + *
> + * This is a small driver for the dwc3 to provide the glue logic
> + * to configure the controller. Tested on STi platforms.
> + *
> + * Copyright (C) 2014 Stmicroelectronics
> + *
> + * Author: Giuseppe Cavallaro
> + * Contributors: Aymen Bouattay
> + * Peter Griffin
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Inspired by dwc3-omap.c and dwc3-exynos.c.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "core.h"
> +#include "io.h"
> +
> +/* glue registers */
> +#define CLKRST_CTRL 0x00
> +#define AUX_CLK_EN BIT(0)
> +#define SW_PIPEW_RESET_N BIT(4)
> +#define EXT_CFG_RESET_N BIT(8)
> +/*
> + * 1'b0 : The host controller complies with the xHCI revision 0.96
> + * 1'b1 : The host controller complies with the xHCI revision 1.0
> + */
> +#define XHCI_REVISIONBIT(12)
> +
> +#define USB2_VBUS_MNGMNT_SEL10x2C
> +/*
> + * For all fields in USB2_VBUS_MNGMNT_SEL1
> + * 2’b00 : Override value from Reg 0x30 is selected
> + * 2’b01 : utmiotg_ from usb3_top is selected
> + * 2’b10 : pipew_ from PIPEW instance is selected
> + * 2’b11 : value is 1'b0
> + */
> +#define USB2_VBUS_REG30 0x0
> +#define USB2_VBUS_UTMIOTG0x1
> +#define USB2_VBUS_PIPEW 0x2
> +#define USB2_VBUS_ZERO 0x3
> +
> +#define SEL_OVERRIDE_VBUSVALID(n)(n << 0)
> +#define SEL_OVERRIDE_POWERPRESENT(n) (n << 4)
> +#define SEL_OVERRIDE_BVALID(n) (n << 8)
> +
> +/* Static DRD configuration */
> +#define USB_HOST_DEFAULT_MASK0xffe
> +#define USB_SET_PORT_DEVICE 0x1
> +
> +/**
> + * struct st_dwc3 - dwc3-st driver private structure
> + * @dev: device pointer
> + * @glue_base: ioaddr for the glue registers
> + * @regmap: regmap pointer for getting syscfg
> + * @syscfg_reg_off: usb syscfg control offset
> + * @dr_mode: drd static host/device config
> + * @rstc_pwrdn: rest controller for powerdown signal
> + * @rstc_rst:reset controller for softreset signal
> + */
> +
> +struct st_dwc3 {
> + struct device *dev;
> + void __iomem *glue_base;
> + struct regmap *regmap;
> + int syscfg_reg_off;
> + enum usb_dr_mode dr_mode;
> + struct reset_control *rstc_pwrdn;
> + struct reset_control *rstc_rst;
> +};
> +
> +static inline u32
Re: [PATCH 1/4] ARM: rockchip: rk3288: Switch to use the proper PWM IP
Am Mittwoch, 20. August 2014, 09:27:02 schrieb Doug Anderson:
> Heiko,
>
> On Wed, Aug 20, 2014 at 9:20 AM, Heiko Stübner wrote:
> > Am Mittwoch, 20. August 2014, 08:55:09 schrieb Doug Anderson:
> >> Thierry,
> >>
> >> On Wed, Aug 20, 2014 at 8:38 AM, Thierry Reding
> >>
> >> wrote:
> >> > On Wed, Aug 20, 2014 at 08:20:53AM -0700, Doug Anderson wrote:
> >> >> Thierry,
> >> >>
> >> >> On Tue, Aug 19, 2014 at 11:08 PM, Thierry Reding
> >> >>
> >> >> wrote:
> >> >> > On Tue, Aug 19, 2014 at 08:18:54AM -0700, Doug Anderson wrote:
> >> >> >> Thierry,
> >> >> >>
> >> >> >> On Tue, Aug 19, 2014 at 12:10 AM, Thierry Reding
> >> >> >>
> >> >> >> wrote:
> >> >> >> > On Mon, Aug 18, 2014 at 10:09:06AM -0700, Doug Anderson wrote:
> >> >> >> >> The rk3288 SoC has an option to switch all of the PWMs in the
> >> >> >> >> system
> >> >> >> >> between the old IP block and the new IP block. The new IP block
> >> >> >> >> is
> >> >> >> >> working and tested and the suggested PWM to use, so setup the
> >> >> >> >> SoC
> >> >> >> >> to
> >> >> >> >> use it and then we can pretend that the other IP block doesn't
> >> >> >> >> exist.
> >> >> >
> >> >> > A few more questions as to how this actually works. Does it mean
> >> >> > there
> >> >> > are two physically separate blocks (with different physical
> >> >> > addresses)
> >> >> > to control the same PWM? And this register simply causes some of the
> >> >> > pins to be routed to one or another? As far as I recall there are a
> >> >> > number of instances of the PWM block, so the above would need to
> >> >> > count
> >> >> > for all of them. Or are there separate bits for each of them?
> >> >>
> >> >> All I have is the TRM (technical reference manual) which doesn't give
> >> >> me much more info than I've provided you. But I can answer some of
> >> >> your questoins:
> >> >>
> >> >> 1. If there are two physically separate blocks then the "old" block is
> >> >> not documented in my TRM.
> >> >>
> >> >> 1a) It's entirely possible it's located at some memory address that is
> >> >> marked "Reserved" in the TRM, but I have no idea.
> >> >>
> >> >> 1b) It's entirely possible that the old IP block and the new IP block
> >> >> are supposed to be "compatible" but that the old block is broken and
> >> >> thus isn't behaving properly.
> >> >>
> >> >> 1c) It's entirely possible that the old IP block and the new IP block
> >> >> are located at the same physical addresses but somehow work
> >> >> differently. If so, the old IP block isn't documented.
> >> >>
> >> >>
> >> >> 2. As per the patch description, there is a single bit that controls
> >> >> all of the PWMs. My guess is that there's actually a single IP block
> >> >> that implements all 4 PWMs.
> >> >
> >> > Looking at the register offsets in the device tree that seems likely.
> >> > At
> >> > least PWMs 0 and 1 as well as 2 and 3 seem like they could be in the
> >> >
> >> > same IP block. Their placement in the register map is somewhat strange:
> >> > pwm0: pwm@2003 {
> >> >
> >> > ...
> >> > reg = <0x2003 0x10>;
> >> > ...
> >> > clocks = < PCLK_PWM01>;
> >> > ...
> >> >
> >> > };
> >> >
> >> > pwm1: pwm@20030010 {
> >> >
> >> > ...
> >> > reg = <0x20030010 0x10>;
> >> > ...
> >> > clocks = < PCLK_PWM01>;
> >> > ...
> >> >
> >> > };
> >> >
> >> > ...
> >> >
> >> > pwm2: pwm@20050020 {
> >> >
> >> > ...
> >> > reg = <0x20050020 0x10>;
> >> > ...
> >> > clocks = < PCLK_PWM23>;
> >> > ...
> >> >
> >> > };
> >> >
> >> > pwm3: pwm@20050030 {
> >> >
> >> > ...
> >> > reg = <0x20050030 0x10>;
> >> > ...
> >> > clocks = < PCLK_PWM23>;
> >> > ...
> >> >
> >> > };
> >>
> >> Ah, you're looking at "rk3xxx.dtsi". That doesn't apply to rk3288
> >> (the downsides of trying to guess ahead of time what SoC vendors will
> >> name new models).
> >
> > It did sound like a nice idea at the time to hold the common stuff of
> > rk3066/rk3188 and all their derivatives and I assumed a SoC that changed
> > dramatically (including the core) would be called 4xxx or so :-) .
>
> Yes, I've fallen into the same trap. Now I jump on the bandwagon and
> name things arbitrarily by the first machine that had them. It's
> confusing, but sorta less confusing too.
the problem was in this case, that there also is rk3066-specific material which
made it all the more difficult.
I guess rk3066-common would have been a possibility but still sounds somewhat
strange, or something else entirely.
I'm not sure but don't think dtsi file-naming
Re: [PATCH] mtd: nand: stm_nand_bch: add new driver
On Tuesday 19 August 2014 07:42 AM, Brian Norris wrote:
On Wed, Aug 06, 2014 at 02:32:18AM +0530, pe...@pek-sem.com wrote:
On Tuesday 05 August 2014 07:53 PM, Lee Jones wrote:
On Thu, 03 Jul 2014, Gupta, Pekon wrote:
+ /* Load last page of block */
+ offs = (loff_t)block << chip->phys_erase_shift;
+ offs += mtd->erasesize - mtd->writesize;
+ if (bch_read_page(nandi, offs, buf) < 0) {
*Important*: You shouldn't call internal functions directly here..
Instead use chip->_read() OR mtd-read() that will:
I'm not sure exactly what you're saying in the above line (chip->_read()
is not a function, and and mtd-read() is syntactically incorrect),
but...
You most certainly do *not* want to call mtd->_read() directly (or any
of the callbacks prefixed with underscores). That is one of the main
purposes of:
commit 3c3c10bba1e4ccb75b41442e45c1a072f6cded19
Author: Artem Bityutskiy
Date: Mon Jan 30 14:58:32 2012 +0200
mtd: add leading underscore to all mtd functions
Makes sense. Thanks for pointing this.
[...]
I think somewhere in earlier comments, Brian also supported
to use high-level function like mtd_read(). Also, nand_bbt.c
itself uses 'mtd_read(), mtd_read_oob() and mtd_write_oob()
at many places. So I'll let Brain decide here.
But having low-level function will add redundant code for
re-checking and aligning the addresses boundaries to block
and page/sector sizes.
Not all checks are redundant. It's redundant to have the direct
descendant doing the same checks that the parent does, like:
mtd_read() (checks boundaries)
|_ mtd->_read() (e.g., nand_read())
So nand_read() and nand_do_read_ops() don't need the checking.
But for a BBT implementation, it can help to make sure that its
page/block/etc. arithmetic fits the right bounds when it ends up
deciding to scan a block.
Now, it still may be easy to prove that the checks are
redundant/unnecessary for correctly-written code, but if the layering
makes sense, then it still may be a better choice to simply use the
high-level, self-checking API than to try to dig deeper. For instance,
I'm pretty sure UBI does some checks to make sure it's not reading off
the end of an MTD, but it still calls mtd_read() because it's The Right
Thing (TM).
Brian
Agree.. re-using mtd_*() API for non-critical paths is justified.
with regards, pekon
Powered by BigRock.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
On Wed, Jul 30, 2014 at 04:28:10PM +0100, Peter Griffin wrote:
> This patch documents the device tree documentation required for
> the ST usb3 controller glue layer found in STiH407 devices.
>
> Signed-off-by: Giuseppe Cavallaro
> Signed-off-by: Peter Griffin
> Acked-by: Lee Jones
> ---
> Documentation/devicetree/bindings/usb/dwc3-st.txt | 69
> +++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
> b/Documentation/devicetree/bindings/usb/dwc3-st.txt
> new file mode 100644
> index 000..de3fea3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
> @@ -0,0 +1,69 @@
> +ST DWC3 glue logic
> +
> +This file documents the parameters for the dwc3-st driver.
> +This driver controls the glue logic used to configure the dwc3 core on
> +STiH407 based platforms.
> +
> +Required properties:
> + - compatible: must be "st,stih407-dwc3"
> + - reg : glue logic base address and USB syscfg ctrl register
> offset
> + - reg-names : should be "reg-glue" and "syscfg-reg"
> + - st,syscon : should be phandle to system configuration node which
> + encompasses the glue registers
> + - resets: list of phandle and reset specifier pairs. There should be
> two entries, one
> + for the powerdown and softreset lines of the usb3 IP
> + - reset-names : list of reset signal names. Names should be
> "powerdown" and "softreset"
> +See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
> +See: Documentation/devicetree/bindings/reset/reset.txt
> +
> + - #address-cells, #size-cells : should be '1' if the device has sub-nodes
> + with 'reg' property
> +
> + - pinctl-names : A pinctrl state named "default" must be defined
> +See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
> +
> + - pinctrl-0 : Pin control group
> +See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
> +
> + - ranges: allows valid 1:1 translation between child's address space and
> + parent's address space
> +
> +Sub-nodes:
> +The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
> +example below. The DT binding details of dwc3 can be found in:
> +Documentation/devicetree/bindings/usb/dwc3.txt
> +
> +NB: The dr_mode property described in [1] is NOT optional for this driver,
> as the default value
> +is "otg", which isn't supported by this SoC. Valid dr_mode values for
> dwc3-st are either "host"
> +or "device".
> +
> +[1] Documentation/devicetree/bindings/usb/generic.txt
> +
> +Example:
> +
> +st_dwc3: dwc3@8f94000 {
> + status = "disabled";
> + compatible = "st,stih407-dwc3";
> + reg = <0x08f94000 0x1000>, <0x110 0x4>;
> + reg-names = "reg-glue", "syscfg-reg";
> + st,syscfg = <_core>;
> + resets = < STIH407_USB3_POWERDOWN>;
> + < STIH407_MIPHY2_SOFTRESET>;
> + reset-names = "powerdown",
> + "softreset";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_usb3>;
> + ranges;
> +
> + dwc3: dwc3@990 {
> + compatible = "snps,dwc3";
> + reg = <0x0990 0x10>;
> + interrupts = ;
> + dr_mode = "host"
> + usb-phy = <_phy>;
> + phy-names = "usb2-phy";
> + phys= <_picophy2>;
why are you using different binding for usb2 and usb3 phys ? Why can't
you just:
phys-names = "usb2-phy", "usb3-phy";
phys= <_picophy2>, <_phy>;
??
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
On Wed, Jul 30, 2014 at 04:28:11PM +0100, Peter Griffin wrote: -ENOLOG > Signed-off-by: Peter Griffin > Acked-by: Lee Jones > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 702ca10..269ad3b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1325,6 +1325,7 @@ F: drivers/pinctrl/pinctrl-st.c > F: drivers/media/rc/st_rc.c > F: drivers/i2c/busses/i2c-st.c > F: drivers/tty/serial/st-asc.c > +F: drivers/usb/dwc3/dwc3-st.c also doesn't apply, please rebase on v3.17-rc1. As for the other two patches, I'm reviewing them right now and they apply cleanly, at least. -- balbi signature.asc Description: Digital signature
[PATCH] af_decnet: Use time_after_eq
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the Coccinelle semantic patch making this change
is as follows:
@change@
expression E1,E2,E3;
@@
- jiffies - E1 >= (E2*E3)
+ time_after_eq(jiffies, E1+E2*E3)
Signed-off-by: Himangi Saraogi
Acked-by: Julia Lawall
---
net/decnet/af_decnet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
index ae011b4..25733d5 100644
--- a/net/decnet/af_decnet.c
+++ b/net/decnet/af_decnet.c
@@ -127,6 +127,7 @@ Version 0.0.62.1.110 07-aug-98 Eduardo Marcelo
Serrat
#include
#include
#include
+#include
#include
#include
#include
@@ -598,7 +599,7 @@ int dn_destroy_timer(struct sock *sk)
if (sk->sk_socket)
return 0;
- if ((jiffies - scp->stamp) >= (HZ * decnet_time_wait)) {
+ if (time_after_eq(jiffies, scp->stamp + HZ * decnet_time_wait)) {
dn_unhash_sock(sk);
sock_put(sk);
return 1;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] decnet: Use time_after_eq
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the Coccinelle semantic patch making this change
is as follows:
@change@
expression E1,E2;
@@
- (jiffies - E1) >= E2
+ time_after_eq(jiffies, E1+E2)
Signed-off-by: Himangi Saraogi
Acked-by: Julia Lawall
---
net/decnet/dn_timer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/decnet/dn_timer.c b/net/decnet/dn_timer.c
index d9c150c..1d330fd 100644
--- a/net/decnet/dn_timer.c
+++ b/net/decnet/dn_timer.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -91,7 +92,7 @@ static void dn_slow_timer(unsigned long arg)
* since the last successful transmission.
*/
if (scp->keepalive && scp->keepalive_fxn && (scp->state == DN_RUN)) {
- if ((jiffies - scp->stamp) >= scp->keepalive)
+ if (time_after_eq(jiffies, scp->stamp + scp->keepalive))
scp->keepalive_fxn(sk);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ipconfig: Use time_before
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the Coccinelle semantic patch making this change
is as follows:
@change@
expression E1,E2;
@@
- jiffies - E1 < E2
+ time_before(jiffies, E1+E2)
Signed-off-by: Himangi Saraogi
Acked-by: Julia Lawall
---
net/ipv4/ipconfig.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 5bbef4f..648fa14 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -262,7 +262,8 @@ static int __init ic_open_devs(void)
/* wait for a carrier on at least one device */
start = jiffies;
next_msg = start + msecs_to_jiffies(CONF_CARRIER_TIMEOUT/12);
- while (jiffies - start < msecs_to_jiffies(CONF_CARRIER_TIMEOUT)) {
+ while (time_before(jiffies, start +
+ msecs_to_jiffies(CONF_CARRIER_TIMEOUT))) {
int wait, elapsed;
for_each_netdev(_net, dev)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 0/6] namespaces: log namespaces per task
Le 20/08/2014 18:25, Richard Guy Briggs a écrit : On 14/08/19, Eric W. Biederman wrote: Richard Guy Briggs writes: On 14/05/20, Richard Guy Briggs wrote: On 14/05/20, Eric Paris wrote: On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote: The purpose is to track namespaces in use by logged processes from the perspective of init_*_ns. (Including the Linux API list due to the additions to /proc//ns/. Please see http://www.kernelhub.org/?p=2=477668 and in particular http://www.kernelhub.org/?msg=477678=2 ) Sigh if you have to use something like this use the proc inode number. It is the same thing. I hate to claim it is unique absent of the proc superblock but it is and will be for the forseable future. It would be better to include the block device number that appears in proc of 3h of the primary mount of to qualify the number. But it is not particularly important. Coming up with an additional unique number that needs to be maintained seems stronlgy silly. I am reading a contradiction here: https://www.redhat.com/archives/linux-audit/2013-March/msg00032.html and this posting went completely ignored: https://www.redhat.com/archives/linux-audit/2014-January/msg00180.html And then there was this patchset and thread where there was some good discussion to clarify the use case: https://lkml.org/lkml/2014/4/22/662 Then V2: https://lkml.org/lkml/2014/5/9/637 Then V3 3 months ago: https://www.redhat.com/archives/linux-audit/2014-May/msg00071.html I'm about to post another version of the patchset addressing Eric Paris' concerns about record types, field naming... I also try to find a solution to identify netns in userland to solve some network problems (see http://thread.gmane.org/gmane.linux.network/315933/focus=321753). This serial number solution may be reused for this. We really need to find a way to solve this. Regards, Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dn_dev: Use time_before
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the Coccinelle semantic patch making this change
is as follows:
@change@
expression E1,E2;
@@
(
- (jiffies - E1) < E2
+ time_before(jiffies, E1+E2)
)
Signed-off-by: Himangi Saraogi
Acked-by: Julia Lawall
---
net/decnet/dn_dev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/decnet/dn_dev.c b/net/decnet/dn_dev.c
index 3b726f3..4400da7 100644
--- a/net/decnet/dn_dev.c
+++ b/net/decnet/dn_dev.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -875,7 +876,7 @@ static void dn_send_endnode_hello(struct net_device *dev,
struct dn_ifaddr *ifa)
static int dn_am_i_a_router(struct dn_neigh *dn, struct dn_dev *dn_db, struct
dn_ifaddr *ifa)
{
/* First check time since device went up */
- if ((jiffies - dn_db->uptime) < DRDELAY)
+ if (time_before(jiffies, dn_db->uptime + DRDELAY))
return 0;
/* If there is no router, then yes... */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] carl9170: Replace rcu_dereference() with rcu_access_pointer()
On Mon, Aug 18, 2014 at 09:29:36PM +0200, Christian Lamparter wrote:
> On Sunday, August 17, 2014 01:48:07 PM Andreea-Cristina Bernat wrote:
> > The rcu_dereference() call is used directly in a condition.
> > Since its return value is never dereferenced it is recommended to use
> > "rcu_access_pointer()" instead of "rcu_dereference()".
> > Therefore, this patch makes the replacement.
> > [...]
> > Signed-off-by: Andreea-Cristina Bernat
> > ---
> > drivers/net/wireless/ath/carl9170/main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/ath/carl9170/main.c
> > b/drivers/net/wireless/ath/carl9170/main.c
> > index f8ded84..12018ff 100644
> > --- a/drivers/net/wireless/ath/carl9170/main.c
> > +++ b/drivers/net/wireless/ath/carl9170/main.c
> > @@ -1431,7 +1431,7 @@ static int carl9170_op_ampdu_action(struct
> > ieee80211_hw *hw,
> > return -EOPNOTSUPP;
> >
> > rcu_read_lock();
> > - if (rcu_dereference(sta_info->agg[tid])) {
> > + if (rcu_access_pointer(sta_info->agg[tid])) {
> > rcu_read_unlock();
> > return -EBUSY;
> > }
>
> There's more. The check does not do a whole lot. I think *it* [the check] and
> the
> rcu_read_[un]lock [and the return -EBUSY] can be removed completely from the
> IEEE80211_AMPDU_TX_START code-path in carl9170_op_ampdu_action.
>
> It would be awesome, if you could you make a patch which removes this
> unneeded cosmic-ray-protection check :-) .
Could you tell me why you think that those lines have to be removed?
I would like to fully understand this before I remove them.
Thank you,
Andreea
>
> Thanks
> Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert "platform/x86/toshiba-apci.c possible bad if test?"
On Wed, 20 Aug 2014 20:03:26 +0300, Ari Sundholm said: > From: Ari Sundholm > > This reverts commit bdc3ae7221213963f438faeaa69c8b4a2195f491. > + if (sscanf(buf, "%i", ) != 1 && (mode != 2 || mode != 1)) > return -EINVAL; I'm not convinced that's right either. If we come in and mode == 1, then the mode != 2 is true, and yoinks... I think this wanted to be sscanf() != 1 || ! (mode == 2 || mode == 1) I'll spin a patch against the reverted version if desired. pgpriWS7snd4y.pgp Description: PGP signature
Re: [Xen-devel] [PATCH] xen-pciback: Add MODULE_ALIAS for pciback.
On Wed, 2014-08-20 at 13:20 -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 20, 2014 at 06:18:52PM +0100, Ian Campbell wrote:
> > On Wed, 2014-08-20 at 12:40 -0400, Konrad Rzeszutek Wilk wrote:
> > > The rest of the Xen device drivers use an module alias
> > > to load devices when they shop up in XenBus.
> >
> > "show".
> > >
> > > MODULE_LICENSE("Dual BSD/GPL");
> > > MODULE_ALIAS("xen-backend:pci");
> > > +MODULE_ALIAS("xen:pci");
> >
> > Isn't that xen-backend:pci already the right thing for a backend device?
> > xen: is for frontends, I thought.
>
> Oh, you are right. Cool! Thanks!
The patch turned out to be even more trivial than expected ;-)
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
