Re: [PATCH v4 07/11] pwm: imx: Provide atomic PWM support for i.MX PWMv2
On Mon, 09 Jan 2017 19:14:43 -0800
Stefan Agner wrote:
> >>
> >> >
> >> > But, while reviewing your patch I realized this was actually unneeded
> >> > (see the explanation in my previous review).
> >> >
> >> > >
> >> > > Now it depends on cstate.enabled flag.
> >> > >
> >> > > So we end up with
> >> > >
> >> > > if (state.enabled && !cstate.enabled)
> >> > >clk_preapre_enable();
> >> >
> >> > Yep, and that's correct.
> >>
> >> And following patch:
> >> http://patchwork.ozlabs.org/patch/709510/
> >>
> >> address this issue.
> >
> > Yes, that was needed because the enable/disable path were not
> > separated, and we were unconditionally writing to the IP registers
> > even when the PWM was already disabled (which is probably the case
> > generating the fault reported by Stefan). This is not the case anymore,
> > but let's wait for Stefan to confirm this.
>
> With v4 as is, the kernel crashes/hangs on i.MX 7.
>
> The function imx_pwm_apply_v2 gets first called with state->enabled 0,
> cstate->enabled 0. This branches to else and leads to a register access
> with clocks disabled (and if that would succeed, also an unbalanced
> disable?...)
>
> With the proposed change plus the additional change in the else branch
> it works for me:
>
> @@ -192,19 +193,20 @@ static int imx_pwm_apply_v2(struct pwm_chip *chip,
> struct pwm_device *pwm,
> else
> period_cycles = 0;
>
> - ret = clk_prepare_enable(imx->clk_per);
> - if (ret)
> - return ret;
> -
> /*
> * Wait for a free FIFO slot if the PWM is already
> enabled, and
> * flush the FIFO if the PWM was disabled and is about
> to be
> * enabled.
> */
> - if (cstate.enabled)
> + if (cstate.enabled) {
> imx_pwm_wait_fifo_slot(chip, pwm);
> - else if (state->enabled)
> + } else if (state->enabled) {
> + ret = clk_prepare_enable(imx->clk_per);
> + if (ret)
> + return ret;
> +
> imx_pwm_sw_reset(chip);
> + }
>
> writel(duty_cycles, imx->mmio_base + MX3_PWMSAR);
> writel(period_cycles, imx->mmio_base + MX3_PWMPR);
> @@ -218,7 +220,7 @@ static int imx_pwm_apply_v2(struct pwm_chip *chip,
> struct pwm_device *pwm,
> cr |= MX3_PWMCR_POUTC;
>
> writel(cr, imx->mmio_base + MX3_PWMCR);
> - } else {
> + } else if (cstate.enabled) {
> writel(0, imx->mmio_base + MX3_PWMCR);
>
> clk_disable_unprepare(imx->clk_per);
>
>
> This would not disable a disabled PWM anymore, I guess at normal use not
> a problem. Only at bootup it could end up left on, but I guess if we
> care about boot time transition we should implement get_state, but
> something which we can do in a follow up patch.
Yep, that's a different problem which could be addressed by
implementing ->get_state(). Note that you don't necessary want to
disable the PWM at boot time, in some situation, when the PWM is
driving a critical device (like the VDDIODDR regulator), you want the
transition between the bootloader/firmware and Linux to be as smooth as
possible. Actually, 'initial state retrieval' and 'atomic changes'
were added to handle this case.
Stefan, one last thing, can you apply patch 2 alone and check if it
doesn't introduce a regression?
Thanks,
Boris
[V2 2/2] arm64: dts: Add dts files for Hisilicon Hi3660 SoC
Add initial dtsi file to support Hisilicon Hi3660 SoC with
support of Octal core CPUs in two clusters(4 * A53 & 4 * A73).
Also add dts file to support HiKey960 development board which
based on Hi3660 SoC.
The output console is earlycon "earlycon=pl011,0xfdf05000".
And the con_init uart5 with a fixed clock, which already
configured at bootloader.
When clock is available, the uart5 will be modified.
Tested on HiKey960 Board.
Signed-off-by: Chen Feng
---
arch/arm64/boot/dts/hisilicon/Makefile| 1 +
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 34 +
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 156 ++
3 files changed, 191 insertions(+)
create mode 100644 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
create mode 100644 arch/arm64/boot/dts/hisilicon/hi3660.dtsi
diff --git a/arch/arm64/boot/dts/hisilicon/Makefile
b/arch/arm64/boot/dts/hisilicon/Makefile
index c8b8f80..7aee1f3 100644
--- a/arch/arm64/boot/dts/hisilicon/Makefile
+++ b/arch/arm64/boot/dts/hisilicon/Makefile
@@ -1,4 +1,5 @@
dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
+dtb-$(CONFIG_ARCH_HISI) += hi3660-hikey960.dtb
dtb-$(CONFIG_ARCH_HISI) += hip05-d02.dtb
dtb-$(CONFIG_ARCH_HISI) += hip06-d03.dtb
dtb-$(CONFIG_ARCH_HISI) += hip07-d05.dtb
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
new file mode 100644
index 000..bc5399d
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -0,0 +1,34 @@
+/*
+ * dts file for Hisilicon HiKey960 Development Board
+ *
+ * Copyright (C) 2016, Hisilicon Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include "hi3660.dtsi"
+
+/ {
+ model = "HiKey960";
+ compatible = "hisilicon,hi3660";
+
+ aliases {
+ serial5 = &uart5; /* console UART */
+ };
+
+ chosen {
+ stdout-path = "serial5:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0040 0x0 0xbfe0>;
+ };
+
+ soc {
+ uart5: uart@fdf05000 {
+ status = "ok";
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
new file mode 100644
index 000..7f9805c
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -0,0 +1,156 @@
+/*
+ * dts file for Hisilicon Hi3660 SoC
+ *
+ * Copyright (C) 2016, Hisilicon Ltd.
+ */
+
+#include
+
+/ {
+ compatible = "hisilicon,hi3660";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ core2 {
+ cpu = <&cpu2>;
+ };
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+ cluster1 {
+ core0 {
+ cpu = <&cpu4>;
+ };
+ core1 {
+ cpu = <&cpu5>;
+ };
+ core2 {
+ cpu = <&cpu6>;
+ };
+ core3 {
+ cpu = <&cpu7>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ compatible = "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@2 {
+ compatible = "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@3 {
+ compatible = "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ };
+
+
Re: [RFC] coccicheck: add a test for repeat memory fetches
On Tue, 10 Jan 2017, Pengfei Wang wrote: > > > 在 2017年1月10日，下午2:06，Julia Lawall 写道： > > > > > > > > On Mon, 9 Jan 2017, Kees Cook wrote: > > > >> Okay, this adds a few tests, for people to examine. > >> > >> reusercopy-cook.cocci: > >> My original test, with recent updates from Julia. > >> > >> reusercopy-wang.cocci: > >> This is Pengfei's test, but with heavily modified reporting to fit in the > >> kernel coccicheck target, and with all the getuser checks removed so that > >> Julia's size test could be added (this lets us compare the results between > >> this and my original test). > > > > Thanks for the update. > > > > I'm not enthusiastic about all the python filtering. It would be better > > to try to put it into the pattern matching rules. > > I agree with that. I used the python filtering because I could not filter out > the false > positives with the rules since I was a beginner to Coccinelle. I encourage > you to use > the pattern matching rules if possible. > > > > I'm not sure what is the point of func in the various rules. Is there a > > need to ensure that the pattern appears only once in a function definition? > > It is unnecessary to use the “func” as long as it won’t cause an error when > running the script. > I used it because we found that this pattern usually takes place within a > function. The pattern > is not necessarily to appear only once, and our approach should be able to > match multiple > occurrences of this pattern within one function. > > However, our approach currently cannot match an inter-function pattern, > within which the two > copy operations reside in two functions respectively. The first function > copies the user data first, > and it calls the second function, then within the second function, the user > data is copied again > and used. This situation actually exists(CVE-2016-6516), and could cause bad > consequences. > > I also suggest adding more copy function APIs, such as strncpy_from_user(). I > didn’t do so for > two reasons. > 1. My script already looks redundant and I’m trying to use a better structure. > 2. The other copy functions are not so prevalent as the four I used. > But adding more copy functions could make it more accurate. > > Please feel free to contact me if you have any questions about my script. Thanks for the feedback! Indeed Coccinelle is not well adapted to interprocedural analysis, but it could be added to a limited extent, eg one level of function call if it seems useful, once the rest is in good shape. julia > > Regards > Pengfei > > > > > I'll look at this in more detail this evening, and try to remove more false > > positives. If you know of some specifically, please let me know what they > > are. > > > > thanks, > > julia > > > > > >> > >> regetuser-wang.cocci: > >> This is Pengfei's get_user() tests only (to compare against hits from just > >> the copy_from_user() tests). > >> > >> Comparing reusercopy-cook.cocci with reusercopy-wang.cocci: > >> -./arch/ia64/kernel/perfmon.c:4833 > >> +./arch/powerpc/kernel/signal_32.c:742 > >> +./arch/powerpc/kernel/signal_32.c:850 > >> ./arch/powerpc/platforms/powernv/opal-prd.c:248 > >> ./drivers/acpi/custom_method.c:54 > >> -./drivers/firmware/efi/test/efi_test.c:617 > >> -./drivers/hid/hid-picolcd_debugfs.c:283 > >> +./drivers/gpu/drm/radeon/radeon_cs.c:635 > >> ./drivers/hwtracing/stm/core.c:580 > >> ./drivers/isdn/i4l/isdn_ppp.c:875 > >> ./drivers/md/dm-ioctl.c:1741 > >> -./drivers/misc/mic/vop/vop_vringh.c:775 > >> +./drivers/md/md.c:7030 > >> +./drivers/misc/lkdtm_usercopy.c:106 > >> +./drivers/misc/lkdtm_usercopy.c:160 > >> +./drivers/misc/lkdtm_usercopy.c:232 > >> ./drivers/misc/mic/vop/vop_vringh.c:944 > >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2159 > >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2257 > >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2302 > >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2342 > >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2365 > >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2406 > >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2439 > >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2491 > >> +./drivers/net/hamradio/yam.c:981 > >> +./drivers/net/hamradio/yam.c:997 > >> +./drivers/net/tun.c:2021 > >> +./drivers/net/tun.c:2152 > >> +./drivers/net/tun.c:2168 > >> +./drivers/net/tun.c:2211 > >> ./drivers/platform/chrome/cros_ec_dev.c:185 > >> ./drivers/scsi/3w-9xxx.c:688 > >> ./drivers/scsi/3w-sas.c:761 > >> ./drivers/scsi/3w-.c:920 > >> ./drivers/scsi/aacraid/commctrl.c:117 > >> ./drivers/scsi/megaraid.c:3465 > >> +./drivers/scsi/mpt3sas/mpt3sas_ctl.c:2309 > >> +./drivers/scsi/sg.c:422 > >> ./drivers/staging/lustre/lustre/llite/llite_lib.c:2491 > >> -./kernel/kexec_core.c:775 > >> -./kernel/kexec_core.c:838 > >> +./lib/test_kasan.c:401 > >> +./net/wireless/wext-core.c:809 > >> > >> So, a couple false positives (kernel/kexec_core.c) are detected and ignored > >> with the larg
Re: [PATCH 0/3] per cpu resume latency
Hi All, Is there any comments for the testing or the patch? Thanks! Alex On 01/05/2017 11:48 PM, Alex Shi wrote: > On 01/05/2017 11:29 PM, Alex Shi wrote: >> > cpu_dma_latency is designed to keep all cpu awake from deep c-state. >> > That is good keep system with short response latency. But sometime we >> > don't need all cpu power especially in a more and more multi-core day. >> > So set all cpu restless that lead to a big power waste. >> > >> > A better way is to keep the short cpu response latency on needed cpu, >> > while let other unnecesscary cpus go to deep idle. That is this >> > patchset. We just use the pm_qos_resume_latency on cpu. Giving the >> > short cpu latency on appointed cpu via setting value on >> > /sys/devices/system/cpu/cpuX/power/pm_qos_resume_latency_us >> > We can set we wanted latency value according to the value of >> > /sys/devices/system/cpu/cpuX/cpuidle/stateX/latency. to just a bit >> > less related state's latency value. Then cpu can get to this state or >> > higher. >> > >> > Here is some testing data on my dragonboard 410c, the latency of state1 >> > is 280us. It has 4 cores. >> > >> > Benchmark: cyclictest -t 1 -n -i 1 -l 1000 -q --latency=1 >> > >> > without the patch: >> > Latency (us) Min: 87 Act: 209 Avg: 205 Max: 239 >> > With the patch and cpu0/power/pm_qos_resume_latency_us is lower than >> > 280us, like set to 279 >> > benchmark result on cpu0: >> > Latency (us) Min: 82 Act: 91 Avg: 95 Max: 110 >> > In repeat testing, the Avg latency always drop to half of vanilla kernel >> > value, as well as Max latency value, although sometime the Max latency >> > is similar with vanilla kernel.
Re: [PATCH] tmpfs: clear S_ISGID when setting posix ACLs
On Mon 09-01-17 09:34:48, Gu Zheng wrote:
> This change was missed the tmpfs modification in In CVE-2016-7097
> commit 073931017b49 ("posix_acl: Clear SGID bit when setting
> file permissions")
> It can test by xfstest generic/375, which failed to clear
> setgid bit in the following test case on tmpfs:
>
> touch $testfile
> chown 100:100 $testfile
> chmod 2755 $testfile
> _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile
>
> Signed-off-by: Gu Zheng
Thanks. The patch looks good. You can add:
Reviewed-by: Jan Kara
Al, will you please merge it? Thanks!
Honza
> ---
> fs/posix_acl.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/fs/posix_acl.c b/fs/posix_acl.c
> index 5955220..d014dff 100644
> --- a/fs/posix_acl.c
> +++ b/fs/posix_acl.c
> @@ -922,11 +922,10 @@ int simple_set_acl(struct inode *inode, struct
> posix_acl *acl, int type)
> int error;
>
> if (type == ACL_TYPE_ACCESS) {
> - error = posix_acl_equiv_mode(acl, &inode->i_mode);
> - if (error < 0)
> - return 0;
> - if (error == 0)
> - acl = NULL;
> + error = posix_acl_update_mode(inode,
> + &inode->i_mode, &acl);
> + if (error)
> + return error;
> }
>
> inode->i_ctime = current_time(inode);
> --
> 2.5.0
>
--
Jan Kara
SUSE Labs, CR
Re: [PATCH v8 2/3] serial: exar: split out the exar code from 8250_pci
On Monday 09 January 2017 11:13 PM, Andy Shevchenko wrote: On Tue, Jan 10, 2017 at 12:25 AM, Sudip Mukherjee wrote: On Monday 09 January 2017 12:14 AM, Andy Shevchenko wrote: + /* +* Setup Multipurpose Input/Output pins. +*/ + if (idx == 0) + setup_gpio(p); So, my question is can we do this in GPIO driver? No, I am using the pci card made by RTD, and they use the GPIO pins to configure the hardware. And its based on the default values that is set here. Can you elaborate a bit. I case you have GPIO: 1. map registers 2. do some GPIO configuration 3. do some other configuration 4. umap registers 5. register GPIO 6. register serial Correct? My question is, would it work if 1. register GPIO then the platform device is created and the gpio driver will start but the gpio register might not be written yet. 2. write GPIO related register (perhaps in GPIO driver) If we write the GPIO related registers in the GPIO driver and if the gpio driver is not enabled, then the gpio configuration registers will not be written and initialized and few boards will break. 3. map registers did you mean pci_ioremap_bar() ? write to GPIO related register involves writing to the address that we obtained using pci_ioremap_bar(). 4. write some other configuration 5. unmap registers 6. register serial ? + if (!pcim_iomap(pcidev, bar, 0) && !pcim_iomap_table(pcidev)) + return -ENOMEM; You ignored my comment, we may never finish the review in such case :-( Asking again: do you really need this part? I know why I did so and put it to 8250_pci, but let's focus on your code. I checked your review of v7 and you have not mentioned about this one. :( I'm sorry, but this is not true. Please, pay attention to all comments. Below is the cite from here: https://www.spinics.net/lists/kernel/msg2416487.html ---vvv + if (!pcim_iomap(dev, bar, 0) && !pcim_iomap_table(dev)) + return -ENOMEM; Do you need to check this per port? In probe you would know this. ---^^^ well, and I removed this to the probe so that it is checked only once and not per port (like you mentioned). I thought that is what you meant. :) regards sudip
Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding documentation
Hi Punnaiah, On Tue, 10 Jan 2017 06:03:25 + Punnaiah Choudary Kalluri wrote: > Hi Rob, > >Thanks for the review. > > > -Original Message- > > From: Rob Herring [mailto:r...@kernel.org] > > Sent: Tuesday, January 10, 2017 11:06 AM > > To: Punnaiah Choudary Kalluri > > Cc: dw...@infradead.org; computersforpe...@gmail.com; > > boris.brezil...@free-electrons.com; marek.va...@gmail.com; > > rich...@nod.at; cyrille.pitc...@atmel.com; mark.rutl...@arm.com; linux- > > ker...@vger.kernel.org; linux-...@lists.infradead.org; > > devicet...@vger.kernel.org; Michal Simek ; > > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah > > Choudary Kalluri > > Subject: Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding > > documentation > > > > On Mon, Jan 09, 2017 at 08:28:53AM +0530, Punnaiah Choudary Kalluri wrote: > > > This patch adds the dts binding document for arasan nand flash > > > controller. > > > > > > Signed-off-by: Punnaiah Choudary Kalluri > > > --- > > > Changes in v7: > > > - Corrected the acronyms those should be in caps > > > changes in v6: > > > - Removed num-cs property > > > - Separated nandchip from nand controller > > > changes in v5: > > > - None > > > Changes in v4: > > > - Added num-cs property > > > - Added clock support > > > Changes in v3: > > > - None > > > Changes in v2: > > > - None > > > --- > > > .../devicetree/bindings/mtd/arasan_nfc.txt | 38 > > ++ > > > 1 file changed, 38 insertions(+) > > > create mode 100644 > > Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > > > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > new file mode 100644 > > > index 000..f20adfc > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > @@ -0,0 +1,38 @@ > > > +Arasan NAND Flash Controller with ONFI 3.1 support > > > + > > > +Required properties: > > > +- compatible: Should be "arasan,nfc-v3p10" > > > > Needs a note that it must also have an SoC specific compatible string. > > > Sorry, I couldn't understand this comment. Could you elaborate it? Arasan is an IP vendor, and those IPs are usually embedded in specific SoCs. I guess Rob was suggesting to define something like: compatible = ",", "arasan,"; This way you can differentiate minor changes/tweaks between each SoC (each SoC vendor usually enable/disable specific features based on their needs). > > > > +- reg: Memory map for module access > > > +- interrupt-parent: Interrupt controller the interrupt is routed through > > > +- interrupts: Should contain the interrupt for the device > > > +- clock-name: List of input clocks - "clk_sys", "clk_flash" > > > > clk_ is redundant. > > > > I have defined these clock names as per the controller data sheet. > So, I feel it is fine to have them in sync with the datasheet. > Please let me know if you still want me to change this. We already know this is a clock, hence the unneeded clk_ prefix. Please drop it. Thanks, Boris
[PATCH v5 0/2] Support for Axentia TSE-850
Hi! changes v4 -> v5 - comment from Rob about the memory node made me look closer and the memory size is actually updated by the bootloader, and that hid the fact that the entry was always faulty. This version specifies the correct memory size from the start, which is 64MB. - ack from Rob changes v3 -> v4 - rename files arch/arm/boot/dts/axentia-* to .../at91-* - remove bootargs from at91-tse850-3.dts - depend on the atmel ssc to register as a sound dai by itself - bump copyright years changes v2 -> v3 - document the new compatible strings prefixed with "axentia,". changes v1 -> v2 - squash the fixup into the correct patch, sorry for the noise. After finally having all essintial drivers upstreamed I would like to have the dts and the defconfig also upstreamed. The atmel-ssc/sound-dai change depends on a change that has been sitting in the ASoC tree since mid-december, and I have been waiting for it to hit linux-next before sending this, but it seems to take longer than I anticipated. So, since I do not want this to in turn miss the next merge window because of that wait I therefore request that this is taken now even though it doesn't really work w/o the ASoC "topic/atmel" branch as of 2016-12-15 [1]. It of course builds cleanly even w/o those ASoC changes. That effectively means that noone besides me should notice the inconsistency (I currently have all affected devices under my control). Cheers, peda [1] http://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/atmel Peter Rosin (2): ARM: dts: at91: add devicetree for the Axentia TSE-850 ARM: sama5_defconfig: add support for the Axentia TSE-850 board Documentation/devicetree/bindings/arm/axentia.txt | 19 ++ MAINTAINERS | 8 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/at91-linea.dtsi | 53 + arch/arm/boot/dts/at91-tse850-3.dts | 274 ++ arch/arm/configs/sama5_defconfig | 7 +- 6 files changed, 361 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt create mode 100644 arch/arm/boot/dts/at91-linea.dtsi create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts -- 2.1.4
[PATCH] block: Don't register a registered bdi device
This issue is same as Sreekanth Reddy's report bug, link:https://patchwork.kernel.org/patch/9394471/ so I quoted the calltrace Sreekanth Reddy's report. Observing below kernel panic while creating second raid disk on LSI SAS3008 HBA card. [ +0.55] [ cut here ] [ +0.07] WARNING: CPU: 2 PID: 281 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 [ +0.02] sysfs: cannot create duplicate filename '/devices/virtual/bdi/8:32' [ +0.01] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables intel_rapl sb_edac edac_core x86_pkg_temp_pclmul joydev ghash_clmulni_intel iTCO_wdt ipmi_ssif mei_me pcspkr mei iTCO_vendor_support ipmi_si i2c_i801 lpc_ich mfd_corema acpi_pad wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc sunrpc xfs libcrc32c ast i2c_algo_bit drm_kore raid_class nvme_core scsi_transport_sas dca [ +0.67] CPU: 2 PID: 281 Comm: kworker/u49:5 Not tainted 4.9.0-rc2 #1 [ +0.02] Hardware name: Supermicro SYS-2028U-TNRT+/X10DRU-i+, BIOS 1.1 07/22/2015 [ +0.05] Workqueue: events_unbound async_run_entry_fn [ +0.04] Call Trace: [ +0.09] [] dump_stack+0x63/0x85 [ +0.05] [] __warn+0xcb/0xf0 [ +0.04] [] warn_slowpath_fmt+0x5f/0x80 [ +0.06] [] ? kernfs_path_from_node+0x4f/0x60 [ +0.02] [] sysfs_warn_dup+0x62/0x80 [ +0.02] [] sysfs_create_dir_ns+0x77/0x90 [ +0.04] [] kobject_add_internal+0x99/0x330 [ +0.03] [] ? vsnprintf+0x35b/0x4c0 [ +0.03] [] kobject_add+0x75/0xd0 [ +0.06] [] ? device_private_init+0x23/0x70 [ +0.07] [] ? mutex_lock+0x12/0x30 [ +0.03] [] device_add+0x119/0x670 [ +0.04] [] device_create_groups_vargs+0xe0/0xf0 [ +0.03] [] device_create_vargs+0x1c/0x20 [ +0.06] [] bdi_register+0x8c/0x180 [ +0.03] [] bdi_register_owner+0x36/0x60 [ +0.06] [] device_add_disk+0x168/0x480 [ +0.05] [] ? update_autosuspend+0x51/0x60 [ +0.05] [] sd_probe_async+0x110/0x1c0 [ +0.02] [] async_run_entry_fn+0x39/0x140 [ +0.03] [] process_one_work+0x15f/0x430 [ +0.02] [] worker_thread+0x4e/0x490 [ +0.02] [] ? process_one_work+0x430/0x430 [ +0.03] [] kthread+0xd9/0xf0 [ +0.03] [] ? kthread_park+0x60/0x60 [ +0.03] [] ret_from_fork+0x25/0x30 [ +0.02] [ cut here ] [ +0.04] WARNING: CPU: 2 PID: 281 at lib/kobject.c:240 kobject_add_internal+0x2bd/0x330 [ +0.01] kobject_add_internal failed for 8:32 with -EEXIST, don't try to register things with the same name in the same [ +0.01] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables intel_rapl sb_edac edac_core x86_pkg_temp_pclmul joydev ghash_clmulni_intel iTCO_wdt ipmi_ssif mei_me pcspkr mei iTCO_vendor_support ipmi_si i2c_i801 lpc_ich mfd_corema acpi_pad wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc sunrpc xfs libcrc32c ast i2c_algo_bit drm_kore raid_class nvme_core scsi_transport_sas dca [ +0.43] CPU: 2 PID: 281 Comm: kworker/u49:5 Tainted: GW 4.9.0-rc2 #1 [ +0.01] Hardware name: Supermicro SYS-2028U-TNRT+/X10DRU-i+, BIOS 1.1 07/22/2015 [ +0.02] Workqueue: events_unbound async_run_entry_fn [ +0.03] Call Trace: [ +0.03] [] dump_stack+0x63/0x85 [ +0.03] [] __warn+0xcb/0xf0 [ +0.04] [] warn_slowpath_fmt+0x5f/0x80 [ +0.02] [] ? sysfs_warn_dup+0x6a/0x80 [ +0.03] [] kobject_add_internal+0x2bd/0x330 [ +0.03] [] ? vsnprintf+0x35b/0x4c0 [ +0.03] [] kobject_add+0x75/0xd0 [ +0.03] [] ? device_private_init+0x23/0x70 [ +0.04] [] ? mutex_lock+0x12/0x30 [ +0.02] [] device_add+0x119/0x670 [ +0.04] [] device_create_groups_vargs+0xe0/0xf0 [ +0.03] [] device_create_vargs+0x1c/0x20 [ +0.03] [] bdi_register+0x8c/0x180 [ +0.03] [] bdi_register_owner+0x36/0x60 [ +0.04] [] device_add_disk+0x168/0x480 [ +0.03] [] ? update_autosuspend+0x51/0x60 [ +0.02] [] sd_probe_async+0x110/0x1c0 [ +0.02] [] async_run_entry_fn+0x39/0x140 [ +0.02] [] process_one_work+0x15f/0x430 [ +0.02] [] worker_thread+0x4e/0x490 [ +0.02] [] ? process_one_work+0x430/0x430 [ +0.03] [] kthread+0xd9/0xf0 [ +0.03] [] ? kthread_park+0x60/0x60 [ +0.03] [] ret_from_fork+0x25/0x30 [ +0.000949] BUG: unable to handle kernel [ +0.005263] NULL pointer dereference [ +0.002853] IP: [] sysfs_do_create_link_sd.isra.2+0x34/0xb0 [ +0.008584] PGD 0 [ +0.006115] Oops: [#1] SMP [ +0.004531] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables
[PATCH v5 2/2] ARM: sama5_defconfig: add support for the Axentia TSE-850 board
Signed-off-by: Peter Rosin --- arch/arm/configs/sama5_defconfig | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig index aca8625b6fc9..bf5b3a73e38c 100644 --- a/arch/arm/configs/sama5_defconfig +++ b/arch/arm/configs/sama5_defconfig @@ -131,7 +131,7 @@ CONFIG_GPIO_SYSFS=y CONFIG_POWER_SUPPLY=y CONFIG_BATTERY_ACT8945A=y CONFIG_POWER_RESET=y -# CONFIG_HWMON is not set +CONFIG_SENSORS_JC42=y CONFIG_WATCHDOG=y CONFIG_AT91SAM9X_WATCHDOG=y CONFIG_SAMA5D4_WATCHDOG=y @@ -142,6 +142,7 @@ CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_ACT8865=y CONFIG_REGULATOR_ACT8945A=y +CONFIG_REGULATOR_PWM=y CONFIG_MEDIA_SUPPORT=y CONFIG_MEDIA_CAMERA_SUPPORT=y CONFIG_V4L_PLATFORM_DRIVERS=y @@ -164,6 +165,7 @@ CONFIG_SND_ATMEL_SOC=y CONFIG_SND_ATMEL_SOC_WM8904=y # CONFIG_HID_GENERIC is not set CONFIG_SND_ATMEL_SOC_PDMIC=y +CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_EHCI_HCD=y @@ -199,6 +201,9 @@ CONFIG_AT_XDMAC=y CONFIG_IIO=y CONFIG_AT91_ADC=y CONFIG_AT91_SAMA5D2_ADC=y +CONFIG_ENVELOPE_DETECTOR=y +CONFIG_DPOT_DAC=y +CONFIG_MCP4531=y CONFIG_PWM=y CONFIG_PWM_ATMEL=y CONFIG_PWM_ATMEL_HLCDC_PWM=y -- 2.1.4
[PATCH v5 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
Acked-by: Rob Herring
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/at91-linea.dtsi | 53 +
arch/arm/boot/dts/at91-tse850-3.dts | 274 ++
5 files changed, 355 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
diff --git a/Documentation/devicetree/bindings/arm/axentia.txt
b/Documentation/devicetree/bindings/arm/axentia.txt
new file mode 100644
index ..ea3fb96ae465
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axentia.txt
@@ -0,0 +1,19 @@
+Device tree bindings for Axentia ARM devices
+
+
+Linea CPU module
+
+
+Required root node properties:
+compatible = "axentia,linea",
+"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from atmel-at91.txt for a sama5d31 SoC.
+
+
+TSE-850 v3 board
+
+
+Required root node properties:
+compatible = "axentia,tse850v3", "axentia,linea",
+"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from above for the axentia,linea CPU module.
diff --git a/MAINTAINERS b/MAINTAINERS
index 97b78cc5aa51..5c2ea6e9cd7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2346,6 +2346,14 @@ S: Maintained
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXENTIA ARM DEVICES
+M: Peter Rosin
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/arm/axentia.txt
+F: arch/arm/boot/dts/at91-linea.dtsi
+F: arch/arm/boot/dts/at91-tse850-3.dts
+
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab
M: Mauro Carvalho Chehab
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9a7375c388a8..7632849866de 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
+ at91-tse850-3.dtb \
sama5d31ek.dtb \
sama5d33ek.dtb \
sama5d34ek.dtb \
diff --git a/arch/arm/boot/dts/at91-linea.dtsi
b/arch/arm/boot/dts/at91-linea.dtsi
new file mode 100644
index ..646feb0daa81
--- /dev/null
+++ b/arch/arm/boot/dts/at91-linea.dtsi
@@ -0,0 +1,53 @@
+/*
+ * at91-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ compatible = "axentia,linea",
+"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ memory {
+ reg = <0x2000 0x400>;
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <1200>;
+};
+
+&main {
+ clock-frequency = <1200>;
+};
+
+&i2c0 {
+ status = "okay";
+
+ eeprom@51 {
+ compatible = "st,24c64";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+};
+
+&nand0 {
+ status = "okay";
+
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+};
diff --git a/arch/arm/boot/dts/at91-tse850-3.dts
b/arch/arm/boot/dts/at91-tse850-3.dts
new file mode 100644
index ..669a2c6bdefc
--- /dev/null
+++ b/arch/arm/boot/dts/at91-tse850-3.dts
@@ -0,0 +1,274 @@
+/*
+ * at91-tse850-3.dts - Device Tree file for the Axentia TSE-850 3.0 board
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include
+#include "at91-linea.dtsi"
+
+/ {
+ model = "Axentia TSE-850 3.0";
+ compatible = "axentia,tse850v3", "axentia,linea",
+"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ pinctrl@f200 {
+ tse850 {
+ pinctrl_usba_vbus: usba-vbus {
+ atmel,pins =
+ ;
+ };
+ };
+ };
+
+ watchdog@fe40 {
+ status = "okay";
+ };
+ };
+ };
+
+ sck: oscillator {
+ compatible = "fixed-clock";
+
+ #clock-c
Re: [PATCH] tmpfs: clear S_ISGID when setting posix ACLs
On Tue, Jan 10, 2017 at 09:03:01AM +0100, Jan Kara wrote:
> On Mon 09-01-17 09:34:48, Gu Zheng wrote:
> > This change was missed the tmpfs modification in In CVE-2016-7097
> > commit 073931017b49 ("posix_acl: Clear SGID bit when setting
> > file permissions")
> > It can test by xfstest generic/375, which failed to clear
> > setgid bit in the following test case on tmpfs:
> >
> > touch $testfile
> > chown 100:100 $testfile
> > chmod 2755 $testfile
> > _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile
> >
> > Signed-off-by: Gu Zheng
>
> Thanks. The patch looks good. You can add:
>
> Reviewed-by: Jan Kara
>
> Al, will you please merge it? Thanks!
Already applied, actually...
Re: [PATCH v2 0/2] phy: Replace the deprecated extcon API
Hi Kishon, Could you review these patches or pick up them if there is no any comment? On 2016년 12월 30일 13:11, Chanwoo Choi wrote: > This patches just replace the deprecated extcon API without any change > of extcon operation and use the resource-managed function for > extcon_register_notifier(). > > The new extcon API instead of deprecated API. > - extcon_set_cable_state_() -> extcon_set_state_sync(); > - extcon_get_cable_state_() -> extcon_get_state(); > > Changes from v1: > - Rebase these patches based on v4.10-rc1. > - Drop the usb/power-supply/chipidea patches. > > Chanwoo Choi (2): > phy: rcar-gen3-usb2: Replace the deprecated extcon API > phy: sun4i-usb: Replace the deprecated extcon API > > drivers/phy/phy-rcar-gen3-usb2.c | 8 > drivers/phy/phy-sun4i-usb.c | 4 ++-- > 2 files changed, 6 insertions(+), 6 deletions(-) > -- Best Regards, Chanwoo Choi S/W Center, Samsung Electronics
[PATCH] scsi: remove useless acpi functions in the head file
From: Hanjun Guo
commit f1bc1e4c44b1 ("ata: acpi: rework the ata acpi bind support")
removed scsi_register_acpi_bus_type() and scsi_unregister_acpi_bus_type(),
but forgot to remove them in the head file, do it now.
Signed-off-by: Hanjun Guo
---
include/scsi/scsi.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
index 8ec7c30..a1e1930 100644
--- a/include/scsi/scsi.h
+++ b/include/scsi/scsi.h
@@ -29,16 +29,6 @@ enum scsi_timeouts {
*/
#define SCAN_WILD_CARD ~0
-#ifdef CONFIG_ACPI
-struct acpi_bus_type;
-
-extern int
-scsi_register_acpi_bus_type(struct acpi_bus_type *bus);
-
-extern void
-scsi_unregister_acpi_bus_type(struct acpi_bus_type *bus);
-#endif
-
/** scsi_status_is_good - check the status return.
*
* @status: the status passed up from the driver (including host and
--
1.7.12.4
Re: [RFC] coccicheck: add a test for repeat memory fetches
On Tue, Jan 10, 2017 at 1:31 PM, Julia Lawall wrote: > > > On Tue, 10 Jan 2017, Pengfei Wang wrote: > >> >> > 在 2017年1月10日，下午2:06，Julia Lawall 写道： >> > >> > >> > >> > On Mon, 9 Jan 2017, Kees Cook wrote: >> > >> >> Okay, this adds a few tests, for people to examine. >> >> >> >> reusercopy-cook.cocci: >> >> My original test, with recent updates from Julia. >> >> >> >> reusercopy-wang.cocci: >> >> This is Pengfei's test, but with heavily modified reporting to fit in the >> >> kernel coccicheck target, and with all the getuser checks removed so that >> >> Julia's size test could be added (this lets us compare the results between >> >> this and my original test). >> > >> > Thanks for the update. >> > >> > I'm not enthusiastic about all the python filtering. It would be better >> > to try to put it into the pattern matching rules. >> >> I agree with that. I used the python filtering because I could not filter >> out the false >> positives with the rules since I was a beginner to Coccinelle. I encourage >> you to use >> the pattern matching rules if possible. >> > >> > I'm not sure what is the point of func in the various rules. Is there a >> > need to ensure that the pattern appears only once in a function definition? >> >> It is unnecessary to use the “func” as long as it won’t cause an error when >> running the script. >> I used it because we found that this pattern usually takes place within a >> function. The pattern >> is not necessarily to appear only once, and our approach should be able to >> match multiple >> occurrences of this pattern within one function. >> >> However, our approach currently cannot match an inter-function pattern, >> within which the two >> copy operations reside in two functions respectively. The first function >> copies the user data first, >> and it calls the second function, then within the second function, the user >> data is copied again >> and used. This situation actually exists(CVE-2016-6516), and could cause bad >> consequences. Thanks for the inputs on this issue. Indeed finding things under one function are obvious cases. /kernel/kexec_core.c was removed from the output because of that approach. This can be easily done in the reusercopy-cook.cocci as well. Also, reusercopy-wang.cocci finds few more cases. I have done few changes in reusercopy-cook.cocci to cover them in pattern matching rule only so that we don't need the whole python rule from reusercopy-wang.cocci. Was supposed to send it but now that you have mentioned the issue with the inter function pattern, let me try to see if we can do that with Coccinelle. As far as it is within a single file, I think coccinelle would be able to do that. I'll send my proposed changes after testing the inter function pattern. >> I also suggest adding more copy function APIs, such as strncpy_from_user(). >> I didn’t do so for >> two reasons. >> 1. My script already looks redundant and I’m trying to use a better >> structure. >> 2. The other copy functions are not so prevalent as the four I used. >> But adding more copy functions could make it more accurate. I'll check about strncpy_from_user once we will have a coccinelle script in a good shape for both of these cases. Thanks! >> Please feel free to contact me if you have any questions about my script. > > Thanks for the feedback! Indeed Coccinelle is not well adapted to > interprocedural analysis, but it could be added to a limited extent, eg > one level of function call if it seems useful, once the rest is in good > shape. > > julia > > >> >> Regards >> Pengfei >> >> > >> > I'll look at this in more detail this evening, and try to remove more false >> > positives. If you know of some specifically, please let me know what they >> > are. >> > >> > thanks, >> > julia >> > >> > >> >> >> >> regetuser-wang.cocci: >> >> This is Pengfei's get_user() tests only (to compare against hits from just >> >> the copy_from_user() tests). >> >> >> >> Comparing reusercopy-cook.cocci with reusercopy-wang.cocci: >> >> -./arch/ia64/kernel/perfmon.c:4833 >> >> +./arch/powerpc/kernel/signal_32.c:742 >> >> +./arch/powerpc/kernel/signal_32.c:850 >> >> ./arch/powerpc/platforms/powernv/opal-prd.c:248 >> >> ./drivers/acpi/custom_method.c:54 >> >> -./drivers/firmware/efi/test/efi_test.c:617 >> >> -./drivers/hid/hid-picolcd_debugfs.c:283 >> >> +./drivers/gpu/drm/radeon/radeon_cs.c:635 >> >> ./drivers/hwtracing/stm/core.c:580 >> >> ./drivers/isdn/i4l/isdn_ppp.c:875 >> >> ./drivers/md/dm-ioctl.c:1741 >> >> -./drivers/misc/mic/vop/vop_vringh.c:775 >> >> +./drivers/md/md.c:7030 >> >> +./drivers/misc/lkdtm_usercopy.c:106 >> >> +./drivers/misc/lkdtm_usercopy.c:160 >> >> +./drivers/misc/lkdtm_usercopy.c:232 >> >> ./drivers/misc/mic/vop/vop_vringh.c:944 >> >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2159 >> >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2257 >> >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:2302 >> >> +./drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
Re: [PATCH v2 0/6] usb: Replace the deprecated extcon API
Hi Felipe, These patches have already acked-by tag from you. Could you please apply them if there is additional comment? On 2016년 12월 30일 13:08, Chanwoo Choi wrote: > This patches just replace the deprecated extcon API without any change > of extcon operation and use the resource-managed function for > extcon_register_notifier(). > > The new extcon API instead of deprecated API. > - extcon_set_cable_state_() -> extcon_set_state_sync(); > - extcon_get_cable_state_() -> extcon_get_state(); > > Changes from v1: > - Rebase these patches based on v4.10-rc1. > - Add acked-by tag from usb maintainer and reviewer. > - Drop the phy/power-supply/chipidea patches. > > Chanwoo Choi (6): > usb: dwc3: omap: Replace the extcon API > usb: phy: msm: Replace the extcon API > usb: phy: omap-otg: Replace the extcon API > usb: phy: qcom-8x16-usb: Replace the extcon API > usb: phy: tahvo: Replace the deprecated extcon API > usb: renesas_usbhs: Replace the deprecated extcon API > > drivers/usb/dwc3/dwc3-omap.c| 20 +++- > drivers/usb/phy/phy-msm-usb.c | 33 +++-- > drivers/usb/phy/phy-omap-otg.c | 24 ++-- > drivers/usb/phy/phy-qcom-8x16-usb.c | 13 - > drivers/usb/phy/phy-tahvo.c | 10 +- > drivers/usb/renesas_usbhs/common.c | 2 +- > 6 files changed, 34 insertions(+), 68 deletions(-) > -- Best Regards, Chanwoo Choi S/W Center, Samsung Electronics
Re: [PATCH v2] usb: musb: sunxi: Uses the resource-managed extcon API when registering extcon notifier
Hi Felipe, This patch got the acked-by from Bin Liu and. Could you please apply this patch? On 2016년 12월 30일 13:19, Chanwoo Choi wrote: > This patch just uses the resource-managed extcon API when registering > the extcon notifier. > > Signed-off-by: Chanwoo Choi > Acked-by: Maxime Ripard > Acked-by: Bin Liu > --- > Changes from v1: > - Rebase this patch based on v4.10-rc1. > - Add acked-by tag from Maxime Ripard and Bin Lin. > - Drop the phy/power-supply/chipidea patches. > > drivers/usb/musb/sunxi.c | 12 +++- > 1 file changed, 3 insertions(+), 9 deletions(-) > > diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c > index d0be0eadd0d9..2332294dee0f 100644 > --- a/drivers/usb/musb/sunxi.c > +++ b/drivers/usb/musb/sunxi.c > @@ -251,14 +251,14 @@ static int sunxi_musb_init(struct musb *musb) > writeb(SUNXI_MUSB_VEND0_PIO_MODE, musb->mregs + SUNXI_MUSB_VEND0); > > /* Register notifier before calling phy_init() */ > - ret = extcon_register_notifier(glue->extcon, EXTCON_USB_HOST, > -&glue->host_nb); > + ret = devm_extcon_register_notifier(glue->dev, glue->extcon, > + EXTCON_USB_HOST, &glue->host_nb); > if (ret) > goto error_reset_assert; > > ret = phy_init(glue->phy); > if (ret) > - goto error_unregister_notifier; > + goto error_reset_assert; > > musb->isr = sunxi_musb_interrupt; > > @@ -267,9 +267,6 @@ static int sunxi_musb_init(struct musb *musb) > > return 0; > > -error_unregister_notifier: > - extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST, > -&glue->host_nb); > error_reset_assert: > if (test_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags)) > reset_control_assert(glue->rst); > @@ -293,9 +290,6 @@ static int sunxi_musb_exit(struct musb *musb) > > phy_exit(glue->phy); > > - extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST, > -&glue->host_nb); > - > if (test_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags)) > reset_control_assert(glue->rst); > > -- Best Regards, Chanwoo Choi S/W Center, Samsung Electronics
Re: kernel 4.9 iwlwifi startup error
In data martedì 10 gennaio 2017 00:21:51 CET, Luca Coelho ha scritto: > On Tue, 2017-01-03 at 13:42 +1100, Andrew Donnellan wrote: > > On 02/01/17 21:12, Fabio Coatti wrote: > > > Hi all, > > > I'm using kernel 4.9 and maybe half of the times I boot my laptop I get > > > the > > > error reported below, and the wifi does not work. I have to remove > > > iwlwifi (like modprobe -r iwldvm iwlwifi) and insert it again to get > > > things workig again. This seems a bit random, it does not happens all > > > the times so it could be a timing issue or even a flaky hardware > > > (unlikely, as I see only this issue with wifi, once it starts it works > > > just fine) > > > I'm pretty sure to have seen the same behaviour at some point in 4.8.X > > > release, but right now I lost the related notes. > > > Environment: > > > Distro: gentoo > > > gcc 5.4.0 > > > HW: Hewlett-Packard HP EliteBook Folio 9470m/18DF, BIOS 68IBD Ver. F.63 > > > 04/26/2016 > > > Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz > > > Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24) > > > > > > Of course if more info is needed, just drop me a note. > > > > > > I'm not subscribed to mailing lists, so please keep me in CC: for any > > > information request. > > > > > > Many thanks. > > > > I've so far seen this once on my laptop, a Samsung NP540U3C (don't have > > it with me right now, so I'm not sure what the wifi chipset is), running > > with a Debian 4.9 kernel. > > This bug has already been reported in bugzilla: > > https://bugzilla.kernel.org/show_bug.cgi?id=190281 > > Did you have any problems with older kernel versions? If so, would it be > possible for you to bisect? Well, it happens on a laptop that I use quite intensively, so it will take some time to bisect. However, in the meantime I checked the old logs and the first recorded occurrence happened with 4.8.10 release and firmware version 18.168.6.1 -- Fabio
Re: kernel 4.9 iwlwifi startup error
On Tue, 2017-01-10 at 09:21 +0100, Fabio Coatti wrote: > In data martedì 10 gennaio 2017 00:21:51 CET, Luca Coelho ha scritto: > > On Tue, 2017-01-03 at 13:42 +1100, Andrew Donnellan wrote: > > > On 02/01/17 21:12, Fabio Coatti wrote: > > > > Hi all, > > > > I'm using kernel 4.9 and maybe half of the times I boot my laptop I get > > > > the > > > > error reported below, and the wifi does not work. I have to remove > > > > iwlwifi (like modprobe -r iwldvm iwlwifi) and insert it again to get > > > > things workig again. This seems a bit random, it does not happens all > > > > the times so it could be a timing issue or even a flaky hardware > > > > (unlikely, as I see only this issue with wifi, once it starts it works > > > > just fine) > > > > I'm pretty sure to have seen the same behaviour at some point in 4.8.X > > > > release, but right now I lost the related notes. > > > > Environment: > > > > Distro: gentoo > > > > gcc 5.4.0 > > > > HW: Hewlett-Packard HP EliteBook Folio 9470m/18DF, BIOS 68IBD Ver. F.63 > > > > 04/26/2016 > > > > Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz > > > > Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24) > > > > > > > > Of course if more info is needed, just drop me a note. > > > > > > > > I'm not subscribed to mailing lists, so please keep me in CC: for any > > > > information request. > > > > > > > > Many thanks. > > > > > > I've so far seen this once on my laptop, a Samsung NP540U3C (don't have > > > it with me right now, so I'm not sure what the wifi chipset is), running > > > with a Debian 4.9 kernel. > > > > This bug has already been reported in bugzilla: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=190281 > > > > Did you have any problems with older kernel versions? If so, would it be > > possible for you to bisect? > > > Well, it happens on a laptop that I use quite intensively, so it will take > some time to bisect. However, in the meantime I checked the old logs and the > first recorded occurrence happened with 4.8.10 release and firmware version > 18.168.6.1 Thanks! Let's continue tracking this in bugzilla. -- Cheers, Luca.
Re: [PATCH 8/8] mmc-core: Use kmalloc_array() in mmc_alloc_sg()
On 2017/1/9 5:55, SF Markus Elfring wrote:
From: Markus Elfring
Date: Sun, 8 Jan 2017 22:10:40 +0100
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
* Replace the specification of a data structure by a pointer dereference
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Reviewed-by: Shawn Lin
Signed-off-by: Markus Elfring
---
drivers/mmc/core/queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index a6496d8027bc..b1986622c60e 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -152,7 +152,7 @@ static struct scatterlist *mmc_alloc_sg(int sg_len, int
*err)
{
struct scatterlist *sg;
- sg = kmalloc(sizeof(struct scatterlist)*sg_len, GFP_KERNEL);
+ sg = kmalloc_array(sg_len, sizeof(*sg), GFP_KERNEL);
if (!sg)
*err = -ENOMEM;
else {
--
Best Regards
Shawn Lin
Re: [PATCH 7/8] mmc-core: Use kcalloc() in mmc_test_alloc_mem()
On 2017/1/9 5:50, SF Markus Elfring wrote: From: Markus Elfring Date: Sun, 8 Jan 2017 21:43:12 +0100 * The script "checkpatch.pl" pointed information out like the following. WARNING: Prefer kcalloc over kzalloc with multiply Thus fix the affected source code place. Reviewed-by: Shawn Lin * Replace the specification of a data structure by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention. Signed-off-by: Markus Elfring --- drivers/mmc/core/mmc_test.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/mmc/core/mmc_test.c b/drivers/mmc/core/mmc_test.c index 294d3c675734..cb4750de2720 100644 --- a/drivers/mmc/core/mmc_test.c +++ b/drivers/mmc/core/mmc_test.c @@ -360,8 +360,7 @@ static struct mmc_test_mem *mmc_test_alloc_mem(unsigned long min_sz, if (!mem) return NULL; - mem->arr = kzalloc(sizeof(struct mmc_test_pages) * max_segs, - GFP_KERNEL); + mem->arr = kcalloc(max_segs, sizeof(*mem->arr), GFP_KERNEL); if (!mem->arr) goto out_free; -- Best Regards Shawn Lin
Re: [PATCH v3 05/15] livepatch/powerpc: add TIF_PATCH_PENDING thread flag
On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote: Add the TIF_PATCH_PENDING thread flag to enable the new livepatch per-task consistency model for powerpc. The bit getting set indicates the thread has a pending patch which needs to be applied when the thread exits the kernel. The bit is included in the _TIF_USER_WORK_MASK macro so that do_notify_resume() and klp_update_patch_state() get called when the bit is set. Signed-off-by: Josh Poimboeuf Reviewed-by: Kamalesh Babulal -- cheers, Kamalesh.
Re: [PATCH 6/8] mmc/core/mmc_test: Improve a size determination in five functions
On 2017/1/9 5:49, SF Markus Elfring wrote:
From: Markus Elfring
Date: Sun, 8 Jan 2017 21:25:44 +0100
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Reviewed-by: Shawn Lin
Signed-off-by: Markus Elfring
---
drivers/mmc/core/mmc_test.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/core/mmc_test.c b/drivers/mmc/core/mmc_test.c
index bb9f569a5dd5..294d3c675734 100644
--- a/drivers/mmc/core/mmc_test.c
+++ b/drivers/mmc/core/mmc_test.c
@@ -356,7 +356,7 @@ static struct mmc_test_mem *mmc_test_alloc_mem(unsigned
long min_sz,
if (max_segs > max_page_cnt)
max_segs = max_page_cnt;
- mem = kzalloc(sizeof(struct mmc_test_mem), GFP_KERNEL);
+ mem = kzalloc(sizeof(*mem), GFP_KERNEL);
if (!mem)
return NULL;
@@ -545,7 +545,7 @@ static void mmc_test_save_transfer_result(struct
mmc_test_card *test,
if (!test->gr)
return;
- tr = kmalloc(sizeof(struct mmc_test_transfer_result), GFP_KERNEL);
+ tr = kmalloc(sizeof(*tr), GFP_KERNEL);
if (!tr)
return;
@@ -2973,8 +2973,7 @@ static void mmc_test_run(struct mmc_test_card *test, int
testcase)
}
}
- gr = kzalloc(sizeof(struct mmc_test_general_result),
- GFP_KERNEL);
+ gr = kzalloc(sizeof(*gr), GFP_KERNEL);
if (gr) {
INIT_LIST_HEAD(&gr->tr_lst);
@@ -3108,7 +3107,7 @@ static ssize_t mtf_test_write(struct file *file, const
char __user *buf,
if (ret)
return ret;
- test = kzalloc(sizeof(struct mmc_test_card), GFP_KERNEL);
+ test = kzalloc(sizeof(*test), GFP_KERNEL);
if (!test)
return -ENOMEM;
@@ -3213,7 +3212,7 @@ static int __mmc_test_register_dbgfs_file(struct mmc_card
*card,
return -ENODEV;
}
- df = kmalloc(sizeof(struct mmc_test_dbgfs_file), GFP_KERNEL);
+ df = kmalloc(sizeof(*df), GFP_KERNEL);
if (!df) {
debugfs_remove(file);
dev_err(&card->dev,
--
Best Regards
Shawn Lin
RE: eMMC boot problem: switch to bus width 8 ddr failed
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Shawn Lin
> Sent: Monday, January 09, 2017 3:10 PM
> To: Clemens Gruber ; Shawn Lin
> ; linux-...@vger.kernel.org
> Cc: shawn@rock-chips.com; Ulf Hansson ; Linus
> Walleij ; Adrian Hunter ;
> A.S. Dong ; linux-kernel@vger.kernel.org
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
>
> On 2017/1/6 23:56, Clemens Gruber wrote:
> > On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> >> On 2017/1/6 8:41, Clemens Gruber wrote:
> >>> Hi,
> >>>
> >>> with the current mainline 4.10-rc2 kernel, I can no longer boot from
> >>> the eMMC on my i.MX6Q board.
> >>>
> >>> Details:
> >>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
> >>> supports eMMC 4.41 features and we did not implement voltage
> >>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
> >>> of the mmc-ddr or mmc-hs
> >>> options) to the device tree. The bus-width is 8.
> >>>
> >>> With 4.9 the board booted fine, now with the current mainline 4.10
> >>> tree, I get the following (repeating) errors at boot:
> >>>
> >>> [4.326834] Waiting for root device /dev/mmcblk0p2...
> >>> [ 14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> >>> [ 14.569619] sdhci: === REGISTER DUMP (mmc0)===
> >>> [ 14.575461] sdhci: Sys addr: 0x4e726000 | Version: 0x0002
> >>> [ 14.581300] sdhci: Blk size: 0x0200 | Blk cnt: 0x0001
> >>> [ 14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>> [ 14.592979] sdhci: Present: 0x01fd8009 | Host ctl: 0x0031
> >>> [ 14.598816] sdhci: Power:0x0002 | Blk gap: 0x0080
> >>> [ 14.604654] sdhci: Wake-up: 0x0008 | Clock:0x001f
> >>> [ 14.610493] sdhci: Timeout: 0x008f | Int stat: 0x
> >>> [ 14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>> [ 14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>> [ 14.628007] sdhci: Caps: 0x07eb | Caps_1: 0xa007
> >>> [ 14.633845] sdhci: Cmd: 0x0d1a | Max curr: 0x00ff
> >>
> >> it shows you always fail to get resp of sending status within the
> >> expected period of time.
> >>
> >>
> >>> [ 14.639682] sdhci: Host ctl2: 0x
> >>> [ 14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> >>> [ 14.649447] sdhci:
> ===
> >>>
> >>> This repeats a few times, then more information is shown at the bottom:
> >>>
> >>> [ 86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>> [ 86.899615] sdhci: === REGISTER DUMP (mmc0)===
> >>> [ 86.905453] sdhci: Sys addr: 0x | Version: 0x0002
> >>> [ 86.911291] sdhci: Blk size: 0x0200 | Blk cnt: 0x0001
> >>> [ 86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>> [ 86.922967] sdhci: Present: 0x01fd8009 | Host ctl: 0x0031
> >>> [ 86.928804] sdhci: Power:0x0002 | Blk gap: 0x0080
> >>> [ 86.934642] sdhci: Wake-up: 0x0008 | Clock:0x001f
> >>> [ 86.940479] sdhci: Timeout: 0x008f | Int stat: 0x
> >>> [ 86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>> [ 86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>> [ 86.957992] sdhci: Caps: 0x07eb | Caps_1: 0xa007
> >>> [ 86.963830] sdhci: Cmd: 0x0d1a | Max curr: 0x00ff
> >>> [ 86.969668] sdhci: Host ctl2: 0x
> >>> [ 86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> >>> [ 86.979433] sdhci:
> ===
> >>> [ 86.986356] mmc0: switch to bus width 8 ddr failed
> >>> [ 86.991163] mmc0: error -110 whilst initialising MMC card
> >>> [ 97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>
> >>> --
> >>>
> >>> After looking through the latest commits to mmc/core, I found the
> >>> culprit:
> >>> Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
> >>> CMD13 polling policy when switch to HS DDR mode")
> >>>
> >>> Reverting it fixes the problem. But I am unsure if that's the right
> >>> course of action?
> >>>
> >>> Feel free to send me patches for testing!
> >>
> >> By looking the changes itself, it should be good from the view of spec.
> >> Maybe you could try the patch below, but don't beat me if that
> >> doesn't help at all. :)
> >>
> >> --- a/drivers/mmc/core/mmc.c
> >> +++ b/drivers/mmc/core/mmc.c
> >> @@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card
> *card)
> >>EXT_CSD_BUS_WIDTH,
> >>ext_csd_bits,
> >>card->ext_csd.generic_cmd6_time,
> >> - MMC_TIMING_MMC_DDR52,
> >> + 0,
> >>true, true, true);
> >> if (err) {
> >> pr_err("%s: switch to
Re: [V9fs-developer] 9pfs hangs since 4.7
On Sun, 8 Jan 2017 05:46:39 + Al Viro wrote: > On Sat, Jan 07, 2017 at 06:15:23PM +, Al Viro wrote: > > On Sat, Jan 07, 2017 at 05:19:10PM +, Al Viro wrote: > > > > > released) simply trigger virtio_queue_notify_vq() again? It *is* a bug > > > (if we get a burst filling a previously empty queue all at once, there > > > won't > > > be any slots becoming freed > > > > Umm... Nope, even in that scenario we'll have all requests except the last > > one processed. I'm trying to put together a simpler reproducer, but... > > no luck so far. > > FWIW, here's another fun bug in qemu 9pfs: client may issue multiple > Tflush on the same pending request. Server must not reply to them > out of order and it must reply to at least the last one. If client has > sent more than one Tflush, it must treat an arrival of Rflush to one of > those as if it has received an Rflush to each of the earlier Tflush as > well (IOW, *their* tags are released). Client may not reuse the tag of > victim request until it has received Rflush for the last Tflush it has > sent. > > Linux kernel-side 9p client doesn't issue such multiple Tflush, but the > protocol allows that. > > qemu server does not guarantee in-order replies to multiple Tflush; worse, > while it is likely to reply only to one of those, it may very well be > the _first_ one. Subsequent ones will be lost; moreover, it'll leak > both coroutines and ring slots. > Yeah I'm aware about that, I had started to work on a fix but it's low priority on my TODO list since linux guests don't do that... and I got scheduled. > AFAICS, a clean way to deal with that would be to handle Tflush synchronously, > right in pdu_submit(): > if pdu->type == Tflush > look the victim request up. > if !victim || victim == pdu // [*] > send reply and free pdu immediately. > if victim->type == Tflush // [**] > pdu->victim = victim->victim > else > pdu->victim = victim > mark the victim cancelled > add pdu to the tail of pdu->victim->flushes > and let pdu_complete(pdu) send a reply to each request in pdu->flushes > as well (freeing them as we go) > I had kept the asynchronous way and it resulted in quite convoluted code. I'll give a try as per your suggestion. > Some locking might be needed to avoid the races between pdu_submit() and > pdu_complete(), but it's not going to be a wide critical area. I'm not > familiar with qemu locking primitives, sorry; what's providing an exclusion > between QLIST_INSERT_HEAD in pdu_alloc() (from handle_9p_output()) > and QLIST_REMOVE in pdu_free() (from pdu_complete())? Looks like the same > thing ought to suffice here... > This code runs in coroutines (stack switching, see include/qemu/coroutine.h for details): it is serialized. > [*] a cute way to hurt the current qemu server, BTW - coroutine that waits for > itself to complete... > Indeed :) > [**] Tflush to Tflush is another fun corner case - it does *not* do anything > to the earlier Tflush, but reply to it must follow that to original Tflush > to avoid tag reuse problems. Note that this is not the "multiple Tflush" > case mentioned above - those would all have oldtag pointing to the same > request; they are not chained and unlike this one can happen with legitimate > clients. Tflush to Tflush, OTOH, is not something a sane client would do. I agree I don't see when a client would want to do that but FWIW, it is mentioned in the last paragraph of http://man.cat-v.org/plan_9/5/flush :) Thanks for your valuable suggestions, Al! Cheers. -- Greg
Re: [PATCH 4/4] mm, page_alloc: Add a bulk page allocator
On Tue, Jan 10, 2017 at 12:00:27PM +0800, Hillf Danton wrote:
> > It shows a roughly 50-60% reduction in the cost of allocating pages.
> > The free paths are not improved as much but relatively little can be batched
> > there. It's not quite as fast as it could be but taking further shortcuts
> > would require making a lot of assumptions about the state of the page and
> > the context of the caller.
> >
> > Signed-off-by: Mel Gorman
> > ---
> Acked-by: Hillf Danton
>
Thanks.
> > @@ -2485,7 +2485,7 @@ void free_hot_cold_page(struct page *page, bool cold)
> > }
> >
> > /*
> > - * Free a list of 0-order pages
> > + * Free a list of 0-order pages whose reference count is already zero.
> > */
> > void free_hot_cold_page_list(struct list_head *list, bool cold)
> > {
> > @@ -2495,7 +2495,28 @@ void free_hot_cold_page_list(struct list_head *list,
> > bool cold)
> > trace_mm_page_free_batched(page, cold);
> > free_hot_cold_page(page, cold);
> > }
> > +
> > + INIT_LIST_HEAD(list);
>
> Nit: can we cut this overhead off?
Yes, but note that any caller of free_hot_cold_page_list() is then
required to reinit the list themselves or it'll cause corruption. It's
unlikely that a user of the bulk interface will handle the refcounts and
be able to use this interface properly but if they do, they need to
either reinit this or add the hunk back in.
It happens that all callers currently don't care.
> > /*
> > * split_page takes a non-compound higher-order page, and splits it into
> > @@ -3887,6 +3908,99 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int
> > order,
> > EXPORT_SYMBOL(__alloc_pages_nodemask);
> >
> > /*
> > + * This is a batched version of the page allocator that attempts to
> > + * allocate nr_pages quickly from the preferred zone and add them to list.
> > + * Note that there is no guarantee that nr_pages will be allocated although
> > + * every effort will be made to allocate at least one. Unlike the core
> > + * allocator, no special effort is made to recover from transient
> > + * failures caused by changes in cpusets. It should only be used from !IRQ
> > + * context. An attempt to allocate a batch of patches from an interrupt
> > + * will allocate a single page.
> > + */
> > +unsigned long
> > +__alloc_pages_bulk_nodemask(gfp_t gfp_mask, unsigned int order,
> > + struct zonelist *zonelist, nodemask_t *nodemask,
> > + unsigned long nr_pages, struct list_head *alloc_list)
> > +{
> > + struct page *page;
> > + unsigned long alloced = 0;
> > + unsigned int alloc_flags = ALLOC_WMARK_LOW;
> > + struct zone *zone;
> > + struct per_cpu_pages *pcp;
> > + struct list_head *pcp_list;
> > + int migratetype;
> > + gfp_t alloc_mask = gfp_mask; /* The gfp_t that was actually used for
> > allocation */
> > + struct alloc_context ac = { };
> > + bool cold = ((gfp_mask & __GFP_COLD) != 0);
> > +
> > + /* If there are already pages on the list, don't bother */
> > + if (!list_empty(alloc_list))
> > + return 0;
>
> Nit: can we move the check to the call site?
Yes, but it makes the API slightly more hazardous to use.
> > +
> > + /* Only handle bulk allocation of order-0 */
> > + if (order || in_interrupt())
> > + goto failed;
>
> Ditto
>
Same, if the caller is in interrupt context, there is a slight risk that
they'll corrupt the list in a manner that will be tricky to catch. The
checks are to minimise the risk of being surprising.
--
Mel Gorman
SUSE Labs
Re: [PATCH 5/8] mmc/core/mmc_test: Combine substrings for 5 messages
On 2017/1/9 5:47, SF Markus Elfring wrote:
From: Markus Elfring
Date: Sun, 8 Jan 2017 20:56:48 +0100
The script "checkpatch.pl" pointed information out like the following.
WARNING: quoted string split across lines
yup, the print shouldn't blindly split itself to shut up
"WARNING: line over 80 characters" . FWIW,
Reviewed-by: Shawn Lin
Thus fix affected source code places.
Signed-off-by: Markus Elfring
---
drivers/mmc/core/mmc_test.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/core/mmc_test.c b/drivers/mmc/core/mmc_test.c
index 42aefd3df09b..bb9f569a5dd5 100644
--- a/drivers/mmc/core/mmc_test.c
+++ b/drivers/mmc/core/mmc_test.c
@@ -277,8 +277,7 @@ static int mmc_test_wait_busy(struct mmc_test_card *test)
if (!busy && mmc_test_busy(&cmd)) {
busy = 1;
if (test->card->host->caps & MMC_CAP_WAIT_WHILE_BUSY)
- pr_info("%s: Warning: Host did not "
- "wait for busy state to end.\n",
+ pr_info("%s: Warning: Host did not wait for busy
state to end.\n",
mmc_hostname(test->card->host));
}
} while (mmc_test_busy(&cmd));
@@ -2967,8 +2966,7 @@ static void mmc_test_run(struct mmc_test_card *test, int
testcase)
if (mmc_test_cases[i].prepare) {
ret = mmc_test_cases[i].prepare(test);
if (ret) {
- pr_info("%s: Result: Prepare "
- "stage failed! (%d)\n",
+ pr_info("%s: Result: Prepare stage failed!
(%d)\n",
mmc_hostname(test->card->host),
ret);
continue;
@@ -3005,13 +3003,11 @@ static void mmc_test_run(struct mmc_test_card *test,
int testcase)
mmc_hostname(test->card->host));
break;
case RESULT_UNSUP_HOST:
- pr_info("%s: Result: UNSUPPORTED "
- "(by host)\n",
+ pr_info("%s: Result: UNSUPPORTED (by host)\n",
mmc_hostname(test->card->host));
break;
case RESULT_UNSUP_CARD:
- pr_info("%s: Result: UNSUPPORTED "
- "(by card)\n",
+ pr_info("%s: Result: UNSUPPORTED (by card)\n",
mmc_hostname(test->card->host));
break;
default:
@@ -3026,8 +3022,7 @@ static void mmc_test_run(struct mmc_test_card *test, int
testcase)
if (mmc_test_cases[i].cleanup) {
ret = mmc_test_cases[i].cleanup(test);
if (ret) {
- pr_info("%s: Warning: Cleanup "
- "stage failed! (%d)\n",
+ pr_info("%s: Warning: Cleanup stage failed!
(%d)\n",
mmc_hostname(test->card->host),
ret);
}
--
Best Regards
Shawn Lin
Re: [PATCH 4/8] mmc/core/mmc_test: Add some spaces for better code readability
On 2017/1/9 5:46, SF Markus Elfring wrote:
From: Markus Elfring
Date: Sun, 8 Jan 2017 20:25:39 +0100
Use space characters at some source code places according to
the Linux coding style convention.
Reviewed-by: Shawn Lin
Signed-off-by: Markus Elfring
---
drivers/mmc/core/mmc_test.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/core/mmc_test.c b/drivers/mmc/core/mmc_test.c
index 848f4f30e343..42aefd3df09b 100644
--- a/drivers/mmc/core/mmc_test.c
+++ b/drivers/mmc/core/mmc_test.c
@@ -641,11 +641,11 @@ static int __mmc_test_prepare(struct mmc_test_card *test,
int write)
if (write)
memset(test->buffer, 0xDF, 512);
else {
- for (i = 0;i < 512;i++)
+ for (i = 0; i < 512; i++)
test->buffer[i] = i;
}
- for (i = 0;i < BUFFER_SIZE / 512;i++) {
+ for (i = 0; i < BUFFER_SIZE / 512; i++) {
ret = mmc_test_buffer_transfer(test, test->buffer, i, 512, 1);
if (ret)
return ret;
@@ -674,7 +674,7 @@ static int mmc_test_cleanup(struct mmc_test_card *test)
memset(test->buffer, 0, 512);
- for (i = 0;i < BUFFER_SIZE / 512;i++) {
+ for (i = 0; i < BUFFER_SIZE / 512; i++) {
ret = mmc_test_buffer_transfer(test, test->buffer, i, 512, 1);
if (ret)
return ret;
@@ -946,7 +946,7 @@ static int mmc_test_transfer(struct mmc_test_card *test,
unsigned long flags;
if (write) {
- for (i = 0;i < blocks * blksz;i++)
+ for (i = 0; i < blocks * blksz; i++)
test->scratch[i] = i;
} else {
memset(test->scratch, 0, BUFFER_SIZE);
@@ -980,7 +980,7 @@ static int mmc_test_transfer(struct mmc_test_card *test,
memset(test->buffer, 0, sectors * 512);
- for (i = 0;i < sectors;i++) {
+ for (i = 0; i < sectors; i++) {
ret = mmc_test_buffer_transfer(test,
test->buffer + i * 512,
dev_addr + i, 512, 0);
@@ -988,12 +988,12 @@ static int mmc_test_transfer(struct mmc_test_card *test,
return ret;
}
- for (i = 0;i < blocks * blksz;i++) {
+ for (i = 0; i < blocks * blksz; i++) {
if (test->buffer[i] != (u8)i)
return RESULT_FAIL;
}
- for (;i < sectors * 512;i++) {
+ for (; i < sectors * 512; i++) {
if (test->buffer[i] != 0xDF)
return RESULT_FAIL;
}
@@ -1001,7 +1001,7 @@ static int mmc_test_transfer(struct mmc_test_card *test,
local_irq_save(flags);
sg_copy_to_buffer(sg, sg_len, test->scratch, BUFFER_SIZE);
local_irq_restore(flags);
- for (i = 0;i < blocks * blksz;i++) {
+ for (i = 0; i < blocks * blksz; i++) {
if (test->scratch[i] != (u8)i)
return RESULT_FAIL;
}
@@ -1086,7 +1086,7 @@ static int mmc_test_multi_write(struct mmc_test_card
*test)
sg_init_one(&sg, test->buffer, size);
- return mmc_test_transfer(test, &sg, 1, 0, size/512, 512, 1);
+ return mmc_test_transfer(test, &sg, 1, 0, size / 512, 512, 1);
}
static int mmc_test_multi_read(struct mmc_test_card *test)
@@ -1107,7 +1107,7 @@ static int mmc_test_multi_read(struct mmc_test_card *test)
sg_init_one(&sg, test->buffer, size);
- return mmc_test_transfer(test, &sg, 1, 0, size/512, 512, 0);
+ return mmc_test_transfer(test, &sg, 1, 0, size / 512, 512, 0);
}
static int mmc_test_pow2_write(struct mmc_test_card *test)
@@ -1118,7 +1118,7 @@ static int mmc_test_pow2_write(struct mmc_test_card *test)
if (!test->card->csd.write_partial)
return RESULT_UNSUP_CARD;
- for (i = 1; i < 512;i <<= 1) {
+ for (i = 1; i < 512; i <<= 1) {
sg_init_one(&sg, test->buffer, i);
ret = mmc_test_transfer(test, &sg, 1, 0, 1, i, 1);
if (ret)
@@ -1136,7 +1136,7 @@ static int mmc_test_pow2_read(struct mmc_test_card *test)
if (!test->card->csd.read_partial)
return RESULT_UNSUP_CARD;
- for (i = 1; i < 512;i <<= 1) {
+ for (i = 1; i < 512; i <<= 1) {
sg_init_one(&sg, test->buffer, i);
ret = mmc_test_transfer(test, &sg, 1, 0, 1, i, 0);
if (ret)
@@ -1154,7 +1154,7 @@ static int mmc_test_weird_write(struct mmc_test_card
*test)
if (!test->card->csd.write_partial)
return RESULT_UNSUP_CARD;
- for (i = 3; i < 512;i += 7) {
+ for (i = 3; i < 512; i += 7) {
Re: [PATCH 3/8] mmc-core: Use seq_puts() in mtf_testlist_show()
On 2017/1/9 5:45, SF Markus Elfring wrote: From: Markus Elfring Date: Sun, 8 Jan 2017 19:48:28 +0100 The script "checkpatch.pl" pointed information out like the following. WARNING: Prefer seq_puts to seq_printf it saves some lock time, Reviewed-by: Shawn Lin Thus fix the affected source code place. Signed-off-by: Markus Elfring --- drivers/mmc/core/mmc_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/core/mmc_test.c b/drivers/mmc/core/mmc_test.c index 2f838a13a904..848f4f30e343 100644 --- a/drivers/mmc/core/mmc_test.c +++ b/drivers/mmc/core/mmc_test.c @@ -3163,7 +3163,7 @@ static int mtf_testlist_show(struct seq_file *sf, void *data) mutex_lock(&mmc_test_lock); - seq_printf(sf, "0:\tRun all tests\n"); + seq_puts(sf, "0:\tRun all tests\n"); for (i = 0; i < ARRAY_SIZE(mmc_test_cases); i++) seq_printf(sf, "%d:\t%s\n", i+1, mmc_test_cases[i].name); -- Best Regards Shawn Lin
Re: [Cocci] [PATCH] coccicheck: add a test for repeat copy_from_user
On Tuesday 10 January 2017 01:51 PM, Pengfei Wang wrote:
在 2017年1月10日，上午1:05，Vaishali Thakkar 写道：
On Tuesday 27 December 2016 11:51 PM, Julia Lawall wrote:
I totally dropped the ball on this. Many thanks to Vaishali for
resurrecting it.
Some changes are suggested below.
On Tue, 26 Apr 2016, Kees Cook wrote:
This is usually a sign of a resized request. This adds a check for
potential races or confusions. The check isn't 100% accurate, so it
needs some manual review.
Signed-off-by: Kees Cook
---
scripts/coccinelle/tests/reusercopy.cocci | 36 +++
1 file changed, 36 insertions(+)
create mode 100644 scripts/coccinelle/tests/reusercopy.cocci
diff --git a/scripts/coccinelle/tests/reusercopy.cocci
b/scripts/coccinelle/tests/reusercopy.cocci
new file mode 100644
index ..53645de8ae95
--- /dev/null
+++ b/scripts/coccinelle/tests/reusercopy.cocci
@@ -0,0 +1,36 @@
+/// Recopying from the same user buffer frequently indicates a pattern of
+/// Reading a size header, allocating, and then re-reading an entire
+/// structure. If the structure's size is not re-validated, this can lead
+/// to structure or data size confusions.
+///
+// Confidence: Moderate
+// Copyright: (C) 2016 Kees Cook, Google. License: GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Comments:
+// Options: -no_includes -include_headers
The options could be: --no-include --include-headers
Actually, Coccinelle supports both, but it only officially supports the
-- versions.
+
+virtual report
+virtual org
Add, the following for the *s:
virtual context
Then add the following rule:
@ok@
position p;
expression src,dest;
@@
copy_from_user@p(&dest, src, sizeof(dest))
+
+@cfu_twice@
+position p;
Change this to:
position p != ok.p;
+identifier src;
+expression dest1, dest2, size1, size2, offset;
+@@
+
+*copy_from_user(dest1, src, size1)
+ ... when != src = offset
+ when != src += offset
Here, may be we should add few more lines from Pengfei's
script to avoid th potential FPs.
Add the following lines:
when != if (size2 > e1 || ...) { ... return ...; }
when != if (size2 > e1 || ...) { ... size2 = e2 ... }
These changes drop cases where the last argument to copy_from_usr is the
size of the first argument, which seems safe enough, and where there is a
test on the size value that can either update it or abort the function.
These changes only eliminate false positives, as far as I could tell.
If it would be more convenient, I could just send the complete revised
patch, or whatever seems convenient.
I was also thinking that probably we should also add other user space memory
API functions. May be get_user and strncpy_from_user. Although I'm not sure how
common it is to find such patterns for both of these functions.
I strongly recommend you adding get_user() API , which is used pervasively
within the kernel just like copy_from user().
Sure. I have changed regetuser-wang.cocci from Kees's RFC patches to
include everything in the pattern matching rule. I'll send that as well.
In many situations, there is a combination use, get_user() copies first then
followed by a copy_from_user() copy. According to our investigation, this
typical
situation works by get_user() firstly copying a field of a specific struct to
check,
then copy_from_user() copies in the whole struct to use. Of course, the struct
field is fetch twice.
Do you mean that there is a problem when we have get_user() followed by
copy_from_user()? Basically something like
this:
get_user(..., src.arg) //where src.arg = field of a structure
...
copy_from_user(..., src, ...) //where src is a whole structure
If that is the case then we would need to have one more new script
or rule for such kind of combinational patterns. Disjunction can
probably give FPs.
Thanks!
Regards
Pengfei
thanks,
julia
+*copy_from_user@p(dest2, src, size2)
+
+@script:python depends on org@
+p << cfu_twice.p;
+@@
+
+cocci.print_main("potentially dangerous second copy_from_user()",p)
+
+@script:python depends on report@
+p << cfu_twice.p;
+@@
+
+coccilib.report.print_report(p[0],"potentially dangerous second
copy_from_user()")
--
2.6.3
--
Kees Cook
Chrome OS & Brillo Security
___
Cocci mailing list
co...@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [PATCH net v2 5/5] net: qcom/emac: fix of_node and phydev leaks
On Mon, Jan 09, 2017 at 01:49:53PM -0600, Timur Tabi wrote:
> On 11/24/2016 12:21 PM, Johan Hovold wrote:
> > + if (!has_acpi_companion(&pdev->dev))
> > + put_device(&adpt->phydev->mdio.dev);
>
> I was wondering if, instead of calling put_device() only on non-ACPI systems,
> would it be better if on an ACPI system I called get_device() manually? That
> is, some thing like this:
>
> int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
> {
> ...
> if (has_acpi_companion(&pdev->dev)) {
> ...
> get_device(&mii_bus->dev);
> } else {
> ...
Yeah, that's better.
Thanks,
Johan
Re: [PATCH v2 1/3] dt-bindings: gpio: Add binding documentation for gpio-thunderx
On Mon, Jan 9, 2017 at 8:44 PM, David Daney wrote: > On 01/09/2017 11:36 AM, Linus Walleij wrote: >>> +Optional Properties: >>> +- compatible: "cavium,thunder-8890-gpio", unused as PCI driver binding >>> is used. >>> +- interrupt-controller: Marks the device node as an interrupt >>> controller. >>> +- #interrupt-cells: Must be present and have value of 2 if >>> +"interrupt-controller" is present. >>> + - First cell is the GPIO pin number relative to the controller. >>> + - Second cell is triggering flags as defined in interrupts.txt. >> >> >> AFAICT this device has an optional list of interrupts as well? >> One per pin even? > > I'm not sure I understand your question. > > The GPIO hardware supports an interrupt on each pin. The underlying > interrupt mechanism is via PCI MSI-X, which are fully discoverable by the > driver, so lack of device tree binding for the these underlying MSI-X is > fully appropriate. Sorry I guess I'm just ignorant about how PCI works, that has never been my strongest subject admittedly. So what you're saying is that PCI devices do not need specifying interrupts not interrupt parents in the device tree? That's fine then. Yours, Linus Walleij
Re: [patch] mm, thp: add new background defrag option
On 01/10/2017 04:38 AM, Hugh Dickins wrote: > On Mon, 9 Jan 2017, David Rientjes wrote: >> On Mon, 9 Jan 2017, Vlastimil Babka wrote: >> Any suggestions for a better name for "background" are more than welcome. >>> >>> Why not just "madvise+defer"? >>> >> >> Seeing no other activity regarding this issue (omg!), I'll wait a day or >> so to see if there are any objections to "madvise+defer" or suggestions >> that may be better and repost. > > I get very confused by the /sys/kernel/mm/transparent_hugepage/defrag > versus enabled flags, and this may be a terrible, even more confusing, > idea: but I've been surprised and sad to see defrag with a "defer" > option, but poor enabled without one; and it has crossed my mind that > perhaps the peculiar "madvise+defer" syntax in defrag might rather be > handled by "madvise" in defrag with "defer" in enabled? Or something > like that: 4 x 4 possibilities instead of 5 x 3. But would all the possibilities make sense? For example, if I saw "defer" in enabled, my first expectation would be that it would only use khugepaged, and no THP page faults at all - possibly including madvised regions. If we really wanted really to cover the whole configuration space, we would have files called "enable", "defrag", "enable-madvise", "defrag-madvise" and each with possible values "yes", "no", "defer", where "defer" for enable* files would mean to skip THP page fault completely and defer to khugepaged, and "defer" for defrag* files would mean wake up kswapd/kcompactd and skip direct reclaim/compaction. But, too late for that :) > > Please be gentle with me, > Hugh >
Re: [PATCH 2/8] mmc-core: Fix a typo in a comment line
On 2017/1/9 5:43, SF Markus Elfring wrote: From: Markus Elfring Date: Sun, 8 Jan 2017 19:05:37 +0100 Add a missing character in the function description. Good catch! Reviewed-by: Shawn Lin Signed-off-by: Markus Elfring --- drivers/mmc/core/mmc_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/core/mmc_test.c b/drivers/mmc/core/mmc_test.c index e85ef503d7ce..2f838a13a904 100644 --- a/drivers/mmc/core/mmc_test.c +++ b/drivers/mmc/core/mmc_test.c @@ -1533,7 +1533,7 @@ static int mmc_test_area_cleanup(struct mmc_test_card *test) /* * Initialize an area for testing large transfers. The test area is set to the - * middle of the card because cards may have different charateristics at the + * middle of the card because cards may have different characteristics at the * front (for FAT file system optimization). Optionally, the area is erased * (if the card supports it) which may improve write performance. Optionally, * the area is filled with data for subsequent read tests. -- Best Regards Shawn Lin
Re: [PATCH 1/8] mmc-core: Use kmalloc_array() in mmc_test_area_init()
On 2017/1/9 5:42, SF Markus Elfring wrote:
From: Markus Elfring
Date: Sun, 8 Jan 2017 18:44:26 +0100
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
Reviewed-by: Shawn Lin
* Replace the specification of a data structure by a pointer dereference
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/mmc/core/mmc_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/mmc_test.c b/drivers/mmc/core/mmc_test.c
index 3ab6e52d106c..e85ef503d7ce 100644
--- a/drivers/mmc/core/mmc_test.c
+++ b/drivers/mmc/core/mmc_test.c
@@ -1579,7 +1579,7 @@ static int mmc_test_area_init(struct mmc_test_card *test,
int erase, int fill)
if (!t->mem)
return -ENOMEM;
- t->sg = kmalloc(sizeof(struct scatterlist) * t->max_segs, GFP_KERNEL);
+ t->sg = kmalloc_array(t->max_segs, sizeof(*t->sg), GFP_KERNEL);
if (!t->sg) {
ret = -ENOMEM;
goto out_free;
--
Best Regards
Shawn Lin
Re: [PATCH] perf: protect group_leader from races that cause ctx
On Fri, Jan 06, 2017 at 12:39:17PM -0800, Kees Cook wrote: > > Reported-by: Kees Cook > > I was just relaying a fix. I noted the original reporter in the first > patch, how they asked to be credited: > > Reported-by: Di Shen (@returnsme) of KeenLab (@keen_lab), Tencent That's not a valid tag, complete lack of email address etc..
RE: [PATCH v7 1/2] mtd: arasan: Add device tree binding documentation
Hi Boris, Thanks. I will implement these changes and send the next series. Regards, Punnaiah > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com] > Sent: Tuesday, January 10, 2017 1:36 PM > To: Punnaiah Choudary Kalluri > Cc: Rob Herring ; dw...@infradead.org; > computersforpe...@gmail.com; marek.va...@gmail.com; rich...@nod.at; > cyrille.pitc...@atmel.com; mark.rutl...@arm.com; linux- > ker...@vger.kernel.org; linux-...@lists.infradead.org; > devicet...@vger.kernel.org; Michal Simek ; > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com > Subject: Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding > documentation > > Hi Punnaiah, > > On Tue, 10 Jan 2017 06:03:25 + > Punnaiah Choudary Kalluri wrote: > > > Hi Rob, > > > >Thanks for the review. > > > > > -Original Message- > > > From: Rob Herring [mailto:r...@kernel.org] > > > Sent: Tuesday, January 10, 2017 11:06 AM > > > To: Punnaiah Choudary Kalluri > > > Cc: dw...@infradead.org; computersforpe...@gmail.com; > > > boris.brezil...@free-electrons.com; marek.va...@gmail.com; > > > rich...@nod.at; cyrille.pitc...@atmel.com; mark.rutl...@arm.com; > linux- > > > ker...@vger.kernel.org; linux-...@lists.infradead.org; > > > devicet...@vger.kernel.org; Michal Simek ; > > > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah > > > Choudary Kalluri > > > Subject: Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding > > > documentation > > > > > > On Mon, Jan 09, 2017 at 08:28:53AM +0530, Punnaiah Choudary Kalluri > wrote: > > > > This patch adds the dts binding document for arasan nand flash > > > > controller. > > > > > > > > Signed-off-by: Punnaiah Choudary Kalluri > > > > --- > > > > Changes in v7: > > > > - Corrected the acronyms those should be in caps > > > > changes in v6: > > > > - Removed num-cs property > > > > - Separated nandchip from nand controller > > > > changes in v5: > > > > - None > > > > Changes in v4: > > > > - Added num-cs property > > > > - Added clock support > > > > Changes in v3: > > > > - None > > > > Changes in v2: > > > > - None > > > > --- > > > > .../devicetree/bindings/mtd/arasan_nfc.txt | 38 > > > ++ > > > > 1 file changed, 38 insertions(+) > > > > create mode 100644 > > > Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > > > > > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > new file mode 100644 > > > > index 000..f20adfc > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > @@ -0,0 +1,38 @@ > > > > +Arasan NAND Flash Controller with ONFI 3.1 support > > > > + > > > > +Required properties: > > > > +- compatible: Should be "arasan,nfc-v3p10" > > > > > > Needs a note that it must also have an SoC specific compatible string. > > > > > Sorry, I couldn't understand this comment. Could you elaborate it? > > Arasan is an IP vendor, and those IPs are usually embedded in specific > SoCs. I guess Rob was suggesting to define something like: > > compatible = ",", "arasan,"; > > This way you can differentiate minor changes/tweaks between each SoC > (each SoC vendor usually enable/disable specific features based on > their needs). > > > > > > > +- reg: Memory map for module access > > > > +- interrupt-parent: Interrupt controller the interrupt is routed > > > > through > > > > +- interrupts: Should contain the interrupt for the device > > > > +- clock-name: List of input clocks - "clk_sys", "clk_flash" > > > > > > clk_ is redundant. > > > > > > > I have defined these clock names as per the controller data sheet. > > So, I feel it is fine to have them in sync with the datasheet. > > Please let me know if you still want me to change this. > > We already know this is a clock, hence the unneeded clk_ prefix. Please > drop it. > > Thanks, > > Boris
Re: [PATCH v3 02/15] x86/entry: define _TIF_ALLWORK_MASK flags explicitly
On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote: The _TIF_ALLWORK_MASK macro automatically includes the least-significant 16 bits of the thread_info flags, which is less than obvious and tends to create confusion and surprises when reading or modifying the code. Define the flags explicitly. Signed-off-by: Josh Poimboeuf For the version with swapped _TIF_SINGLESTEP and _TIF_NEED_RESCHED flags. Reviewed-by: Kamalesh Babulal -- cheers, Kamalesh.
Re: [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote:
> When driver is handling AXI DMA SoftIP
> When user submits multiple descriptors back to back on the S2MM(recv)
> side with the current driver flow the last buffer descriptor next bd
> points to a invalid location resulting the invalid data or errors in the
> DMA engine.
Can you rephrase this, it a bit hard to understand.
>
> This patch fixes this issue by creating a BD Chain during
whats a BD?
> channel allocation itself and use those BD's.
>
> Signed-off-by: Kedareswara rao Appana
> ---
> Changes for v5:
> ---> None.
> Changes for v4:
> ---> None.
> Changes for v3:
> ---> None.
> Changes for v2:
> ---> None.
>
> drivers/dma/xilinx/xilinx_dma.c | 133
> +---
> 1 file changed, 83 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 0e9c02e..af2159d 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -163,6 +163,7 @@
> #define XILINX_DMA_BD_SOPBIT(27)
> #define XILINX_DMA_BD_EOPBIT(26)
> #define XILINX_DMA_COALESCE_MAX 255
> +#define XILINX_DMA_NUM_DESCS 255
why 255?
> #define XILINX_DMA_NUM_APP_WORDS 5
>
> /* Multi-Channel DMA Descriptor offsets*/
> @@ -310,6 +311,7 @@ struct xilinx_dma_tx_descriptor {
> * @pending_list: Descriptors waiting
> * @active_list: Descriptors ready to submit
> * @done_list: Complete descriptors
> + * @free_seg_list: Free descriptors
> * @common: DMA common channel
> * @desc_pool: Descriptors pool
> * @dev: The dma device
> @@ -331,7 +333,9 @@ struct xilinx_dma_tx_descriptor {
> * @desc_submitcount: Descriptor h/w submitted count
> * @residue: Residue for AXI DMA
> * @seg_v: Statically allocated segments base
> + * @seg_p: Physical allocated segments base
> * @cyclic_seg_v: Statically allocated segment base for cyclic transfers
> + * @cyclic_seg_p: Physical allocated segments base for cyclic dma
> * @start_transfer: Differentiate b/w DMA IP's transfer
> */
> struct xilinx_dma_chan {
> @@ -342,6 +346,7 @@ struct xilinx_dma_chan {
> struct list_head pending_list;
> struct list_head active_list;
> struct list_head done_list;
> + struct list_head free_seg_list;
> struct dma_chan common;
> struct dma_pool *desc_pool;
> struct device *dev;
> @@ -363,7 +368,9 @@ struct xilinx_dma_chan {
> u32 desc_submitcount;
> u32 residue;
> struct xilinx_axidma_tx_segment *seg_v;
> + dma_addr_t seg_p;
> struct xilinx_axidma_tx_segment *cyclic_seg_v;
> + dma_addr_t cyclic_seg_p;
> void (*start_transfer)(struct xilinx_dma_chan *chan);
> u16 tdest;
> };
> @@ -569,17 +576,31 @@ static struct xilinx_axidma_tx_segment *
> xilinx_axidma_alloc_tx_segment(struct xilinx_dma_chan *chan)
> {
> struct xilinx_axidma_tx_segment *segment;
> - dma_addr_t phys;
> -
> - segment = dma_pool_zalloc(chan->desc_pool, GFP_ATOMIC, &phys);
> - if (!segment)
> - return NULL;
> + unsigned long flags;
>
> - segment->phys = phys;
> + spin_lock_irqsave(&chan->lock, flags);
> + if (!list_empty(&chan->free_seg_list)) {
> + segment = list_first_entry(&chan->free_seg_list,
> +struct xilinx_axidma_tx_segment,
> +node);
> + list_del(&segment->node);
> + }
> + spin_unlock_irqrestore(&chan->lock, flags);
>
> return segment;
> }
>
> +static void xilinx_dma_clean_hw_desc(struct xilinx_axidma_desc_hw *hw)
> +{
> + u32 next_desc = hw->next_desc;
> + u32 next_desc_msb = hw->next_desc_msb;
> +
> + memset(hw, 0, sizeof(struct xilinx_axidma_desc_hw));
> +
> + hw->next_desc = next_desc;
> + hw->next_desc_msb = next_desc_msb;
> +}
> +
> /**
> * xilinx_dma_free_tx_segment - Free transaction segment
> * @chan: Driver specific DMA channel
> @@ -588,7 +609,9 @@ xilinx_axidma_alloc_tx_segment(struct xilinx_dma_chan
> *chan)
> static void xilinx_dma_free_tx_segment(struct xilinx_dma_chan *chan,
> struct xilinx_axidma_tx_segment *segment)
> {
> - dma_pool_free(chan->desc_pool, segment, segment->phys);
> + xilinx_dma_clean_hw_desc(&segment->hw);
> +
> + list_add_tail(&segment->node, &chan->free_seg_list);
> }
>
> /**
> @@ -713,16 +736,26 @@ static void xilinx_dma_free_descriptors(struct
> xilinx_dma_chan *chan)
> static void xilinx_dma_free_chan_resources(struct dma_chan *dchan)
> {
> struct xilinx_dma_chan *chan = to_xilinx_chan(dchan);
> + unsigned long flags;
>
> dev_dbg(chan->dev, "Free all channel resources.\n");
>
> xilinx_dma_free_descriptors(chan);
> +
> if (chan->xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
> - xilinx_dma_free_tx_segment(chan, chan->cyclic_seg_v);
>
Re: [PATCH 2/2] printk: always report lost messages on serial console
On (01/09/17 17:56), Petr Mladek wrote: > I have looked at this once again. Please, do you have a real-life > example when the "printk messages dropped" was not printed? . > By other words, the search for a visible message is finished when > we find one or when the entire log buffer is checked. > > As a consequence, the warning about "printk messages dropped" is > lost _only_ when there was no visible message in the entire buffer. > > Therefore, the warning might get lost only when the log buffer > was very small or when console_level filter was too restricting. with a slow serial console even a relatively large logbuf can easily become a "not quite large enough" logbuf. especially when the underlying uart_port ->lock is concurrently accessed by uart circ_buf flushing. > I wonder if this is a case for a real user or a real life. > In each case, such a scenario most likely comes from a very > curious setup. > > It is possible that your fix is fine. If we lose messages, > we are screwed anyway. But I still have problems to accept > that we would start printing less important messages (that would > normally be ignored) in situation when we have troubles > to print the more important ones. This logic rings warning > bells in my head and this is why I suggest more conservative > solution and ask the many questions. once the system is in "oh, let me drop some of the messages for you" mood, loglevel filtering is unreliable and in some cases unneeded. it's so unreliable that I'm even considering disabling it in *in-house* builds when console_unlock() detects that there was no room for all 'yet to be seen' messages. those are another messages, with 'visible' loglevel or with 'suppressed' loglevel or both 'visible' and 'suppressed' loglevels, that caused the logbuf overflow. now, if the loss of messages was caused by: a) flood of suppressed loglevel messages then printing at least some of those messages makes *a lot* of sense. it really does. because those messages will point at the root cause of the problem. and there is no other way of finding that out when all you have is a serial log of visible messages. those 'suppressed messages' part is the key. whatever loglevel it was, the fact that we overflowed the logbuf with those messages is already bad. b) flood of visible loglevel messages then may be those messages are not so important. there a whole logbuf of them. per my experience, it is quite hard to overflow the logbuf with really important, unique, sensible messages of 'visible' loglevel with active loglevel filtering. in most of the cases I've seen, those "important" messages are the same repeating messages. OOM is the most notable example: it can flood logbuf with pretty much same backtraces and Mem-Info printouts. for instance - CPU that stuck in GFP_REPEAT allocation under OOM. or memory allocation error in swap out path under OOM: ... [3282.5292] Node0, zone , type Isolate 0 0 0 0 0 0 0 0 0 0 0 [3282.5292] Node0, zone , typeUnmovable 0 0 0 0 0 0 0 0 0 0 0 ** 1389 printk messages dropped ** [3282.5430] Write-error on swap-device (254:0:1471944) ** 354 printk messages dropped ** [3282.5526] Write-error on swap-device (254:0:1473240) ** 254 printk messages dropped ** [3282.5598] Write-error on swap-device (254:0:1474472) [3282.5598] SLUB: Unable to allocate memory on xxx blah-blah-blah ... [3282.5606] Write-error on swap-device (254:0:1474480) [3282.5607] Write-error on swap-device (254:0:1474496) [3282.5607] Write-error on swap-device (254:0:1474504) [3282.5608] Write-error on swap-device (254:0:1474504) [3282.5610] Write-error on swap-device (254:0:1474528) [3282.5611] Write-error on swap-device (254:0:1474544) ** 519 printk messages dropped ** [3282.5611] Write-error on swap-device (254:0:1477152) ** 15 printk messages dropped ** [3282.5616] Write-error on swap-device (254:0:1477208) ... [3283.0532] zram: Error allocating memory for compressed page: 200385, size=2824 ... those messages preempt each other and preempt other *may be actually important* 'visible' loglevel messages. but there is no way to tell which one of the messages vprintk_emit() is about to overwrite is actually important. the outcome is -- the important repeating messages are _mostly_ as valuable as the suppressed ones. IOW, not every important message is really important under 'out of logbuf' condition. and vice versa. c) both a) and b) printing both suppressible and 'visible' loglevels makes sense here. considering a) and b): once the system is out of logbuf space it is impossible to clearly distinguish between 'important' and 'not so important' messages. all we know in console_unlock(), when we pick up next_idx message, is
Re: [PATCHv14 2/3] usb: USB Type-C connector class
Hi Guenter,
On Mon, Jan 09, 2017 at 08:59:32AM -0800, Guenter Roeck wrote:
> > +/**
> > + * typec_register_partner - Register a USB Type-C Partner
> > + * @port: The USB Type-C Port the partner is connected to
> > + * @desc: Description of the partner
> > + *
> > + * Registers a device for USB Type-C Partner described in @desc.
> > + *
> > + * Returns handle to the partner on success or NULL on failure.
> > + */
> > +struct typec_partner *typec_register_partner(struct typec_port *port,
> > +struct typec_partner_desc *desc)
> > +{
>
> With the changes to hide the actual partner structure, this looks at first
> glance like a minor API change, but it is substantial.
>
> Reason is that the vdo as required by typec_partner_desc is provided by a VDM
> command reply, which is completely orthogonal to the PD registration process.
> So far I was able to set the vdo later, after registering the connection,
> and after (and if) the vdo was received.
If the identity vdo value is updated after the creation of the device,
then the user space needs to be notified separately.
> Since the partner may not even respond to the DISCOVER_IDENT message, or not
> support PD at all, this means that I would have to disconnect partner
> registration from the PD protocol itself and tie it to the VDO message
> exchange, with appropriate timeouts to register anyway even if the identity
> was not received after some period of time or if the partner does not support
> PD.
>
> This in turn means that I'll have to re-implement and possibly re-architect
> a substantial amount of code.
We don't need to protect the structures like this, we can change this
back. But how about we introduce driver callback function for updating
the value instead, which would also notify the uses space?
Thanks,
--
heikki
Re: [PATCH v7 5/8] IIO: add bindings for STM32 timer trigger driver
2017-01-09 19:04 GMT+01:00 Rob Herring :
> On Thu, Jan 05, 2017 at 10:25:41AM +0100, Benjamin Gaignard wrote:
>> Define bindings for STM32 timer trigger
>>
>> version 4:
>> - remove triggers enumeration from DT
>> - add reg parameter
>>
>> version 3:
>> - change file name
>> - add cross reference with mfd bindings
>>
>> version 2:
>> - only keep one compatible
>> - add DT parameters to set lists of the triggers:
>> one list describe the triggers created by the device
>> another one give the triggers accepted by the device
>>
>> Signed-off-by: Benjamin Gaignard
>> ---
>> .../bindings/iio/timer/stm32-timer-trigger.txt | 23
>> ++
>> 1 file changed, 23 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
>> b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
>> new file mode 100644
>> index 000..36a6c4a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
>> @@ -0,0 +1,23 @@
>> +STMicroelectronics STM32 Timers IIO timer bindings
>> +
>> +Must be a sub-node of an STM32 Timers device tree node.
>> +See ../mfd/stm32-timers.txt for details about the parent node.
>> +
>> +Required parameters:
>> +- compatible:Must be "st,stm32-timer-trigger".
>> +- reg: Define triggers configuration of the hardware IP.
>
> Valid values? Not sure this makes sense for use of reg. reg should be
> how you address or id a device.
I use reg like an id to distinguish device and get the right
configuration inside
the driver.
>
>> +
>> +Example:
>> + timers@4001 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x4001 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> +
>> + timer {
>
> This would also need an unit address.
Ok I will fix that
>
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <0>;
>> + };
>> + };
>> --
>> 1.9.1
>>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v7 2/8] MFD: add STM32 Timers driver
2017-01-09 19:00 GMT+01:00 Rob Herring : > On Thu, Jan 05, 2017 at 10:25:38AM +0100, Benjamin Gaignard wrote: >> This hardware block could at used at same time for PWM generation >> and IIO timers. >> PWM and IIO timer configuration are mixed in the same registers >> so we need a multi fonction driver to be able to share those registers. >> >> version 7: >> - rebase on v4.10-rc2 >> >> version 6: >> - rename files to stm32-timers >> - rename functions to stm32_timers_xxx >> >> version 5: >> - fix Lee comments about detect function >> - add missing dependency on REGMAP_MMIO >> >> version 4: >> - add a function to detect Auto Reload Register (ARR) size >> - rename the structure shared with other drivers >> >> version 2: >> - rename driver "stm32-gptimer" to be align with SoC documentation >> - only keep one compatible >> - use of_platform_populate() instead of devm_mfd_add_devices() >> >> Signed-off-by: Benjamin Gaignard >> --- >> .../devicetree/bindings/mfd/stm32-timers.txt | 2 +- >> drivers/mfd/Kconfig| 11 +++ >> drivers/mfd/Makefile | 2 + >> drivers/mfd/stm32-timers.c | 80 >> ++ >> include/linux/mfd/stm32-timers.h | 71 +++ >> 5 files changed, 165 insertions(+), 1 deletion(-) >> create mode 100644 drivers/mfd/stm32-timers.c >> create mode 100644 include/linux/mfd/stm32-timers.h >> >> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt >> b/Documentation/devicetree/bindings/mfd/stm32-timers.txt >> index a73301d..897e7c2 100644 >> --- a/Documentation/devicetree/bindings/mfd/stm32-timers.txt >> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt >> @@ -12,7 +12,7 @@ Required parameters: >> >> - reg: Physical base address and length of the >> controller's >> registers. >> -- clock-names: Set to "int". >> +- clock-names: Set to "int". > > This hunk should be dropped or moved to previous patch. I will move it in the previous patch > >> - clocks:Phandle to the clock used by the timer module. >> For Clk properties, please refer to >> ../clock/clock-bindings.txt >> -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v4 01/10] power: supplies: bq27xxx: rename BQ27500 allow for deprecation in future.
On Tuesday 10 January 2017 16:25:29 Chris Lapa wrote: > From: Chris Lapa > > The BQ275XX definition exists only to satisfy backwards compatibility. > > tested: yes Instead "tested: yes" we use: "Tested-by: name " line. > Signed-off-by: Chris Lapa > Acked-by: Pali Rohár > Reviewed-by: Andrew F. Davis -- Pali Rohár pali.ro...@gmail.com
Re: [PATCH tip/master v4] kprobes: extable: Identify kprobes' insn-slots as kernel text area
On Mon, Jan 09, 2017 at 11:36:48AM -0600, Josh Poimboeuf wrote: > BTW, I think we'll have more problems with generated code if/when we > move to an x86 DWARF unwinder, because it won't have any idea how to > unwind past generated code. Long term I wonder if it would make sense > to create some kind of framework for creating or registering generated > code, so we can solve these types of problems in a single place. Yes, this seems like a good idea. Maybe we could pull the rbtree thing from modules and make that a more generic interface for code registration.
[PATCH net 2/2] r8152: fix rx issue for runtime suspend
Pause the rx and make sure the rx fifo is empty when the autosuspend
occurs.
If the rx data comes when the driver is canceling the rx urb, the host
controller would stop getting the data from the device and continue
it after next rx urb is submitted. That is, one continuing data is
split into two different urb buffers. That let the driver take the
data as a rx descriptor, and unexpected behavior happens.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c5e6d88..be41856 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3582,17 +3582,42 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
int ret = 0;
if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
+ u32 rcr = 0;
+
if (delay_autosuspend(tp)) {
ret = -EBUSY;
goto out1;
}
+ if (netif_carrier_ok(netdev)) {
+ u32 ocp_data;
+
+ rcr = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
+ ocp_data = rcr & ~RCR_ACPT_ALL;
+ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
+ rxdy_gated_en(tp, true);
+ ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA,
+PLA_OOB_CTRL);
+ if (!(ocp_data & RXFIFO_EMPTY)) {
+ rxdy_gated_en(tp, false);
+ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
+ ret = -EBUSY;
+ goto out1;
+ }
+ }
+
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
- napi_disable(&tp->napi);
- rtl_stop_rx(tp);
+
tp->rtl_ops.autosuspend_en(tp, true);
- napi_enable(&tp->napi);
+
+ if (netif_carrier_ok(netdev)) {
+ napi_disable(&tp->napi);
+ rtl_stop_rx(tp);
+ rxdy_gated_en(tp, false);
+ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
+ napi_enable(&tp->napi);
+ }
}
set_bit(SELECTIVE_SUSPEND, &tp->flags);
--
2.7.4
[PATCH net 0/2] r8152: fix autosuspend issue
Avoid rx is split into two parts when runtime suspend occurs. Hayes Wang (2): r8152: split rtl8152_suspend function r8152: fix rx issue for runtime suspend drivers/net/usb/r8152.c | 80 +++-- 1 file changed, 64 insertions(+), 16 deletions(-) -- 2.7.4
[PATCH net 1/2] r8152: split rtl8152_suspend function
Split rtl8152_suspend() into rtl8152_system_suspend() and
rtl8152_rumtime_suspend().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 57 ++---
1 file changed, 40 insertions(+), 17 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 7dc6122..c5e6d88 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3576,39 +3576,62 @@ static bool delay_autosuspend(struct r8152 *tp)
return false;
}
-static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
+static int rtl8152_rumtime_suspend(struct r8152 *tp)
{
- struct r8152 *tp = usb_get_intfdata(intf);
struct net_device *netdev = tp->netdev;
int ret = 0;
- mutex_lock(&tp->control);
-
- if (PMSG_IS_AUTO(message)) {
- if (netif_running(netdev) && delay_autosuspend(tp)) {
+ if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
+ if (delay_autosuspend(tp)) {
ret = -EBUSY;
goto out1;
}
- set_bit(SELECTIVE_SUSPEND, &tp->flags);
- } else {
- netif_device_detach(netdev);
+ clear_bit(WORK_ENABLE, &tp->flags);
+ usb_kill_urb(tp->intr_urb);
+ napi_disable(&tp->napi);
+ rtl_stop_rx(tp);
+ tp->rtl_ops.autosuspend_en(tp, true);
+ napi_enable(&tp->napi);
}
+ set_bit(SELECTIVE_SUSPEND, &tp->flags);
+
+out1:
+ return ret;
+}
+
+static int rtl8152_system_suspend(struct r8152 *tp)
+{
+ struct net_device *netdev = tp->netdev;
+ int ret = 0;
+
+ netif_device_detach(netdev);
+
if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
napi_disable(&tp->napi);
- if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
- rtl_stop_rx(tp);
- tp->rtl_ops.autosuspend_en(tp, true);
- } else {
- cancel_delayed_work_sync(&tp->schedule);
- tp->rtl_ops.down(tp);
- }
+ cancel_delayed_work_sync(&tp->schedule);
+ tp->rtl_ops.down(tp);
napi_enable(&tp->napi);
}
-out1:
+
+ return ret;
+}
+
+static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
+{
+ struct r8152 *tp = usb_get_intfdata(intf);
+ int ret;
+
+ mutex_lock(&tp->control);
+
+ if (PMSG_IS_AUTO(message))
+ ret = rtl8152_rumtime_suspend(tp);
+ else
+ ret = rtl8152_system_suspend(tp);
+
mutex_unlock(&tp->control);
return ret;
--
2.7.4
[PATCH v5 0/5] powernv:stop: Use psscr_val,mask provided by firmware
From: "Gautham R. Shenoy" This is the fifth iteration of the patchset to use the psscr_val and psscr_mask provided by the firmware for each of the stop states. The previous versions can be found here: [v4]: https://lkml.org/lkml/2016/12/9/288 [v3]: https://lkml.org/lkml/2016/11/10/37 [v2]: https://lkml.org/lkml/2016/10/27/143 [v1]: https://lkml.org/lkml/2016/9/29/45 This version addresses the feedback provided by Balbir and Vaidy to v4. The key changes are: - The current code had some functions/variables names containing arch300_* while others had power9*_. Uniformly rename this to arch300_*. - Add a comment for POWERNV_THRESHOLD_LATENCY_NS. - In case of a new firmware, validate that the PSSCR values provided by the firmware preserves the following invariants as required by the ISA: a) While running in Hypervisor mode (HV=1), EC bit must have the same value as ESL bit. b) For deep stop states that result in state-loss, ESL bit must be set. - Optimize the sequence of instructions before executing stop with ESL=EC=0. Reduce one instruction. - Fixed the typos in the Documentation for the device-tree bindings describing the stop-states exposed by the firmware. Synopsis == In the current implementation, the code for ISA v3.0 stop implementation has a couple of shortcomings. a) The code hand-codes the values for ESL,EC,TR,MTL bits of PSSCR and uses only the RL field from the firmware. While this is not incorrect, since the hand-coded values are legitimate, it is not a very flexible design since the firmware has the capability to communicate these values via the "ibm,cpu-idle-state-psscr" and "ibm,cpu-idle-state-psscr-mask" properties. In case where the firmware provides values for these fields that is different from the hand-coded values, the current code will not work as intended. b) Due to issue a), the current code assumes that ESL=EC=1 for all the stop states and hence the wakeup from the stop instruction will happen at 0x100, the system-reset vector. However, the ISA v3.0 allows the ESL=EC=0 behaviour where the corresponding stop-state loses no state and wakes up from the subsequent instruction. The current code doesn't handle this case. This patch series addresses these issues. The first patch in the series renames the existing IDLE_STATE_ENTER_SEQ macro to IDLE_STATE_ENTER_SEQ_NORET. It reuses the name IDLE_STATE_ENTER_SEQ for entering into stop-states which wake up at the subsequent instruction. The second patch in the series uniformly renames all occurences of "power9" to "arch300" thereby making the variable/function names consistent. The third patch adds a helper function in cpuidle-powernv.c for initializing entries of the powernv_states[] table that is passed to the cpu-idle core. This eliminates some of the code duplication in the function that discovers and initializes the stop states. The fourth patch in the series fixes issues a) and b) by ensuring that the psscr-value and the psscr-mask provided by the firmware are what will be used to set a particular stop state. It also adds support for handling wake-up from stop states which were entered with ESL=EC=0. It validates hat the psscr values exposed by the firmware maintains the invariants mentioned in the ISA. The fourth patch also handles the older firmware which sets only the Requested Level (RL) field in the psscr and psscr-mask exposed in the device tree. In the presence of such older firmware, this patch will set the default sane values for for remaining PSSCR fields (i.e PSLL, MTL, ESL, EC, and TR). The fifth patch provides the documentation for the device-tree bindings describing the idle state properties under the @power-mgt node in the device-tree. The skiboot patch populates all the relevant fields in the PSSCR values and the mask for all the stop states can be found here: https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html Gautham R. Shenoy (5): powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro powernv:stop: Uniformly rename power9 to arch300 cpuidle:powernv: Add helper function to populate powernv idle states. powernv: Pass PSSCR value and mask to power9_idle_stop Documentation:powerpc: Add device-tree bindings for power-mgt .../devicetree/bindings/powerpc/opal/power-mgt.txt | 125 ++ arch/powerpc/include/asm/cpuidle.h | 49 ++- arch/powerpc/include/asm/processor.h | 3 +- arch/powerpc/kernel/exceptions-64s.S | 6 +- arch/powerpc/kernel/idle_book3s.S | 53 arch/powerpc/platforms/powernv/idle.c | 142 ++--- arch/powerpc/platforms/powernv/powernv.h | 3 +- arch/powerpc/platforms/powernv/smp.c | 14 +- drivers/cpuidle/cpuidle-powernv.c | 129 +-- include/linux/cpuidle.h| 1 + 10 files changed, 435 insertions(+
Re: [PATCH v5 2/2] ARM: sama5_defconfig: add support for the Axentia TSE-850 board
Le 10/01/2017 à 09:08, Peter Rosin a écrit : > Signed-off-by: Peter Rosin I know that most of the entries in this configuration file are direct additions to the kernel but what about moving some of your additions to modules? Regards, > --- > arch/arm/configs/sama5_defconfig | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/configs/sama5_defconfig > b/arch/arm/configs/sama5_defconfig > index aca8625b6fc9..bf5b3a73e38c 100644 > --- a/arch/arm/configs/sama5_defconfig > +++ b/arch/arm/configs/sama5_defconfig > @@ -131,7 +131,7 @@ CONFIG_GPIO_SYSFS=y > CONFIG_POWER_SUPPLY=y > CONFIG_BATTERY_ACT8945A=y > CONFIG_POWER_RESET=y > -# CONFIG_HWMON is not set > +CONFIG_SENSORS_JC42=y > CONFIG_WATCHDOG=y > CONFIG_AT91SAM9X_WATCHDOG=y > CONFIG_SAMA5D4_WATCHDOG=y > @@ -142,6 +142,7 @@ CONFIG_REGULATOR=y > CONFIG_REGULATOR_FIXED_VOLTAGE=y > CONFIG_REGULATOR_ACT8865=y > CONFIG_REGULATOR_ACT8945A=y > +CONFIG_REGULATOR_PWM=y > CONFIG_MEDIA_SUPPORT=y > CONFIG_MEDIA_CAMERA_SUPPORT=y > CONFIG_V4L_PLATFORM_DRIVERS=y > @@ -164,6 +165,7 @@ CONFIG_SND_ATMEL_SOC=y > CONFIG_SND_ATMEL_SOC_WM8904=y > # CONFIG_HID_GENERIC is not set > CONFIG_SND_ATMEL_SOC_PDMIC=y > +CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=y > CONFIG_USB=y > CONFIG_USB_ANNOUNCE_NEW_DEVICES=y > CONFIG_USB_EHCI_HCD=y > @@ -199,6 +201,9 @@ CONFIG_AT_XDMAC=y > CONFIG_IIO=y > CONFIG_AT91_ADC=y > CONFIG_AT91_SAMA5D2_ADC=y > +CONFIG_ENVELOPE_DETECTOR=y > +CONFIG_DPOT_DAC=y > +CONFIG_MCP4531=y > CONFIG_PWM=y > CONFIG_PWM_ATMEL=y > CONFIG_PWM_ATMEL_HLCDC_PWM=y > -- Nicolas Ferre
[PATCH v5 1/5] powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro
From: "Gautham R. Shenoy" Currently all the low-power idle states are expected to wake up at reset vector 0x100. Which is why the macro IDLE_STATE_ENTER_SEQ that puts the CPU to an idle state and never returns. On ISA v3.0, when the ESL and EC bits in the PSSCR are zero, the CPU is expected to wake up at the next instruction of the idle instruction. This patch adds a new macro named IDLE_STATE_ENTER_SEQ_NORET for the no-return variant and reuses the name IDLE_STATE_ENTER_SEQ for a variant that allows resuming operation at the instruction next to the idle-instruction. Signed-off-by: Gautham R. Shenoy --- No changes from v4 arch/powerpc/include/asm/cpuidle.h | 5 - arch/powerpc/kernel/exceptions-64s.S | 6 +++--- arch/powerpc/kernel/idle_book3s.S| 10 +- 3 files changed, 12 insertions(+), 9 deletions(-) diff --git a/arch/powerpc/include/asm/cpuidle.h b/arch/powerpc/include/asm/cpuidle.h index 3919332..0a3255b 100644 --- a/arch/powerpc/include/asm/cpuidle.h +++ b/arch/powerpc/include/asm/cpuidle.h @@ -21,7 +21,7 @@ /* Idle state entry routines */ #ifdef CONFIG_PPC_P7_NAP -#defineIDLE_STATE_ENTER_SEQ(IDLE_INST) \ +#define IDLE_STATE_ENTER_SEQ(IDLE_INST) \ /* Magic NAP/SLEEP/WINKLE mode enter sequence */\ std r0,0(r1); \ ptesync;\ @@ -29,6 +29,9 @@ 1: cmpdcr0,r0,r0; \ bne 1b; \ IDLE_INST; \ + +#defineIDLE_STATE_ENTER_SEQ_NORET(IDLE_INST) \ + IDLE_STATE_ENTER_SEQ(IDLE_INST) \ b . #endif /* CONFIG_PPC_P7_NAP */ diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index 1ba82ea..7aa8afc 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -381,12 +381,12 @@ EXC_COMMON_BEGIN(machine_check_handle_early) lbz r3,PACA_THREAD_IDLE_STATE(r13) cmpwi r3,PNV_THREAD_NAP bgt 10f - IDLE_STATE_ENTER_SEQ(PPC_NAP) + IDLE_STATE_ENTER_SEQ_NORET(PPC_NAP) /* No return */ 10: cmpwi r3,PNV_THREAD_SLEEP bgt 2f - IDLE_STATE_ENTER_SEQ(PPC_SLEEP) + IDLE_STATE_ENTER_SEQ_NORET(PPC_SLEEP) /* No return */ 2: @@ -400,7 +400,7 @@ EXC_COMMON_BEGIN(machine_check_handle_early) */ ori r13,r13,1 SET_PACA(r13) - IDLE_STATE_ENTER_SEQ(PPC_WINKLE) + IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE) /* No return */ 4: #endif diff --git a/arch/powerpc/kernel/idle_book3s.S b/arch/powerpc/kernel/idle_book3s.S index 72dac0b..be90e2f 100644 --- a/arch/powerpc/kernel/idle_book3s.S +++ b/arch/powerpc/kernel/idle_book3s.S @@ -205,7 +205,7 @@ pnv_enter_arch207_idle_mode: stb r3,PACA_THREAD_IDLE_STATE(r13) cmpwi cr3,r3,PNV_THREAD_SLEEP bge cr3,2f - IDLE_STATE_ENTER_SEQ(PPC_NAP) + IDLE_STATE_ENTER_SEQ_NORET(PPC_NAP) /* No return */ 2: /* Sleep or winkle */ @@ -239,7 +239,7 @@ pnv_fastsleep_workaround_at_entry: common_enter: /* common code for all the threads entering sleep or winkle */ bgt cr3,enter_winkle - IDLE_STATE_ENTER_SEQ(PPC_SLEEP) + IDLE_STATE_ENTER_SEQ_NORET(PPC_SLEEP) fastsleep_workaround_at_entry: ori r15,r15,PNV_CORE_IDLE_LOCK_BIT @@ -261,7 +261,7 @@ fastsleep_workaround_at_entry: enter_winkle: bl save_sprs_to_stack - IDLE_STATE_ENTER_SEQ(PPC_WINKLE) + IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE) /* * r3 - requested stop state @@ -280,7 +280,7 @@ power_enter_stop: ld r4,ADDROFF(pnv_first_deep_stop_state)(r5) cmpdr3,r4 bge 2f - IDLE_STATE_ENTER_SEQ(PPC_STOP) + IDLE_STATE_ENTER_SEQ_NORET(PPC_STOP) 2: /* * Entering deep idle state. @@ -302,7 +302,7 @@ lwarx_loop_stop: bl save_sprs_to_stack - IDLE_STATE_ENTER_SEQ(PPC_STOP) + IDLE_STATE_ENTER_SEQ_NORET(PPC_STOP) _GLOBAL(power7_idle) /* Now check if user or arch enabled NAP mode */ -- 1.9.4
Re: [PATCH v3 08/15] livepatch: separate enabled and patched states
On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote: Once we have a consistency model, patches and their objects will be enabled and disabled at different times. For example, when a patch is disabled, its loaded objects' funcs can remain registered with ftrace indefinitely until the unpatching operation is complete and they're no longer in use. It's less confusing if we give them different names: patches can be enabled or disabled; objects (and their funcs) can be patched or unpatched: - Enabled means that a patch is logically enabled (but not necessarily fully applied). - Patched means that an object's funcs are registered with ftrace and added to the klp_ops func stack. Also, since these states are binary, represent them with booleans instead of ints. Signed-off-by: Josh Poimboeuf Reviewed-by: Kamalesh Babulal -- cheers, Kamalesh.
[PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300
From: "Gautham R. Shenoy"
Balbir pointed out that in idle_book3s.S and powernv/idle.c some
functions and variables had power9 in their names while some others
had arch300.
This patch uniformly renames all instances of "power9" in the
variables/function/comments occuring in these files to "arch300" in
order to make them consistent.
Signed-off-by: Gautham R. Shenoy
---
New patch in v5
arch/powerpc/include/asm/processor.h | 2 +-
arch/powerpc/kernel/idle_book3s.S | 13 +++--
arch/powerpc/platforms/powernv/idle.c | 6 +++---
arch/powerpc/platforms/powernv/smp.c | 2 +-
drivers/cpuidle/cpuidle-powernv.c | 2 +-
5 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index c07c31b..4b47308 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -458,7 +458,7 @@ static inline unsigned long get_clean_sp(unsigned long sp,
int is_32)
extern unsigned long power7_nap(int check_irq);
extern unsigned long power7_sleep(void);
extern unsigned long power7_winkle(void);
-extern unsigned long power9_idle_stop(unsigned long stop_level);
+extern unsigned long arch300_idle_stop(unsigned long stop_level);
extern void flush_instruction_cache(void);
extern void hard_reset_now(void);
diff --git a/arch/powerpc/kernel/idle_book3s.S
b/arch/powerpc/kernel/idle_book3s.S
index be90e2f..7f6657f 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -106,8 +106,9 @@ core_idle_lock_held:
/*
* Pass requested state in r3:
- * r3 - PNV_THREAD_NAP/SLEEP/WINKLE in POWER8
- *- Requested STOP state in POWER9
+ * r3 - PNV_THREAD_NAP/SLEEP/WINKLE on ISA 2.07 or less
+(POWER7,POWER8)
+ *- Requested STOP state on ISA 3.0 CPUs
*
* To check IRQ_HAPPENED in r4
* 0 - don't check
@@ -357,7 +358,7 @@ ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_ARCH_207S, 66);
\
/*
* r3 - requested stop state
*/
-_GLOBAL(power9_idle_stop)
+_GLOBAL(arch300_idle_stop)
LOAD_REG_IMMEDIATE(r4, PSSCR_HV_TEMPLATE)
or r4,r4,r3
mtspr SPRN_PSSCR, r4
@@ -377,7 +378,7 @@ _GLOBAL(pnv_restore_hyp_resource)
BEGIN_FTR_SECTION
ld r2,PACATOC(r13);
/*
-* POWER ISA 3. Use PSSCR to determine if we
+* POWER ISA 3.0. Use PSSCR to determine if we
* are waking up from deep idle state
*/
LOAD_REG_ADDRBASE(r5,pnv_first_deep_stop_state)
@@ -429,8 +430,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
/*
* Called if waking up from idle state which can cause either partial or
* complete hyp state loss.
- * In POWER8, called if waking up from fastsleep or winkle
- * In POWER9, called if waking up from stop state >= pnv_first_deep_stop_state
+ * In ISA 2.07 (POWER8),called if waking up from fastsleep or winkle
+ * In ISA 3.0, called if waking up from stop state >= pnv_first_deep_stop_state
*
* r13 - PACA
* cr3 - gt if waking up with partial/complete hypervisor state loss
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index 479c256..c3a2fac 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -241,10 +241,10 @@ static DEVICE_ATTR(fastsleep_workaround_applyonce, 0600,
/*
* Used for ppc_md.power_save which needs a function with no parameters
*/
-static void power9_idle(void)
+static void arch300_idle(void)
{
/* Requesting stop state 0 */
- power9_idle_stop(0);
+ arch300_idle_stop(0);
}
/*
* First deep stop state. Used to figure out when to save/restore
@@ -415,7 +415,7 @@ static int __init pnv_init_idle_states(void)
if (supported_cpuidle_states & OPAL_PM_NAP_ENABLED)
ppc_md.power_save = power7_idle;
else if (supported_cpuidle_states & OPAL_PM_STOP_INST_FAST)
- ppc_md.power_save = power9_idle;
+ ppc_md.power_save = arch300_idle;
out:
return 0;
diff --git a/arch/powerpc/platforms/powernv/smp.c
b/arch/powerpc/platforms/powernv/smp.c
index c789258..c931bb2 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -183,7 +183,7 @@ static void pnv_smp_cpu_kill_self(void)
ppc64_runlatch_off();
if (cpu_has_feature(CPU_FTR_ARCH_300))
- srr1 = power9_idle_stop(pnv_deepest_stop_state);
+ srr1 = arch300_idle_stop(pnv_deepest_stop_state);
else if (idle_states & OPAL_PM_WINKLE_ENABLED)
srr1 = power7_winkle();
else if ((idle_states & OPAL_PM_SLEEP_ENABLED) ||
diff --git a/drivers/cpuidle/cpuidle-powernv.c
b/drivers/cpuidle/cpuidle-powernv.c
index 7fe442c..a7f6528 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -102,7 +102,7 @@ static int stop_loop(struct cpuidle_devi
[PATCH v5 3/5] cpuidle:powernv: Add helper function to populate powernv idle states.
From: "Gautham R. Shenoy"
In the current code for powernv_add_idle_states, there is a lot of code
duplication while initializing an idle state in powernv_states table.
Add an inline helper function to populate the powernv_states[] table
for a given idle state. Invoke this for populating the "Nap",
"Fastsleep" and the stop states in powernv_add_idle_states.
Signed-off-by: Gautham R. Shenoy
---
[v4] --> [v5] : Added a comment above POWERNV_THRESHOLD_LATENCY_NS
drivers/cpuidle/cpuidle-powernv.c | 89 +++
include/linux/cpuidle.h | 1 +
2 files changed, 54 insertions(+), 36 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-powernv.c
b/drivers/cpuidle/cpuidle-powernv.c
index a7f6528..a21f1f0 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -20,6 +20,10 @@
#include
#include
+/*
+ * Expose only those Hardware idle states via the cpuidle framework
+ * that have latency value below POWERNV_THRESHOLD_LATENCY_NS.
+ */
#define POWERNV_THRESHOLD_LATENCY_NS 20
struct cpuidle_driver powernv_idle_driver = {
@@ -167,6 +171,24 @@ static int powernv_cpuidle_driver_init(void)
return 0;
}
+static inline void add_powernv_state(int index, const char *name,
+unsigned int flags,
+int (*idle_fn)(struct cpuidle_device *,
+ struct cpuidle_driver *,
+ int),
+unsigned int target_residency,
+unsigned int exit_latency,
+u64 psscr_val)
+{
+ strlcpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
+ strlcpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
+ powernv_states[index].flags = flags;
+ powernv_states[index].target_residency = target_residency;
+ powernv_states[index].exit_latency = exit_latency;
+ powernv_states[index].enter = idle_fn;
+ stop_psscr_table[index] = psscr_val;
+}
+
static int powernv_add_idle_states(void)
{
struct device_node *power_mgt;
@@ -236,6 +258,7 @@ static int powernv_add_idle_states(void)
"ibm,cpu-idle-state-residency-ns", residency_ns,
dt_idle_states);
for (i = 0; i < dt_idle_states; i++) {
+ unsigned int exit_latency, target_residency;
/*
* If an idle state has exit latency beyond
* POWERNV_THRESHOLD_LATENCY_NS then don't use it
@@ -243,28 +266,33 @@ static int powernv_add_idle_states(void)
*/
if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS)
continue;
+ /*
+* Firmware passes residency and latency values in ns.
+* cpuidle expects it in us.
+*/
+ exit_latency = latency_ns[i] / 1000;
+ if (!rc)
+ target_residency = residency_ns[i] / 1000;
+ else
+ target_residency = 0;
/*
-* Cpuidle accepts exit_latency and target_residency in us.
-* Use default target_residency values if f/w does not expose
it.
+* For nap and fastsleep, use default target_residency
+* values if f/w does not expose it.
*/
if (flags[i] & OPAL_PM_NAP_ENABLED) {
+ if (!rc)
+ target_residency = 100;
/* Add NAP state */
- strcpy(powernv_states[nr_idle_states].name, "Nap");
- strcpy(powernv_states[nr_idle_states].desc, "Nap");
- powernv_states[nr_idle_states].flags = 0;
- powernv_states[nr_idle_states].target_residency = 100;
- powernv_states[nr_idle_states].enter = nap_loop;
+ add_powernv_state(nr_idle_states, "Nap",
+ CPUIDLE_FLAG_NONE, nap_loop,
+ target_residency, exit_latency, 0);
} else if ((flags[i] & OPAL_PM_STOP_INST_FAST) &&
!(flags[i] & OPAL_PM_TIMEBASE_STOP)) {
- strncpy(powernv_states[nr_idle_states].name,
- names[i], CPUIDLE_NAME_LEN);
- strncpy(powernv_states[nr_idle_states].desc,
- names[i], CPUIDLE_NAME_LEN);
- powernv_states[nr_idle_states].flags = 0;
-
- powernv_states[nr_idle_states].enter = stop_loop;
- stop_psscr_table[nr_idle_states] = psscr_val[i];
+ add_powernv_state(nr_idle_states, names[i],
+ CPUIDLE_FLAG_N
[PATCH v5 4/5] powernv: Pass PSSCR value and mask to power9_idle_stop
From: "Gautham R. Shenoy"
The arch300_idle_stop method currently takes only the requested stop
level as a parameter and picks up the rest of the PSSCR bits from a
hand-coded macro. This is not a very flexible design, especially when
the firmware has the capability to communicate the psscr value and the
mask associated with a particular stop state via device tree.
This patch modifies the power9_idle_stop API to take as parameters the
PSSCR value and the PSSCR mask corresponding to the stop state that
needs to be set. These PSSCR value and mask are respectively obtained
by parsing the "ibm,cpu-idle-state-psscr" and
"ibm,cpu-idle-state-psscr-mask" fields from the device tree.
In addition to this, the patch adds support for handling stop states
for which ESL and EC bits in the PSSCR are zero. As per the
architecture, a wakeup from these stop states resumes execution from
the subsequent instruction as opposed to waking up at the System
Vector.
The older firmware sets only the Requested Level (RL) field in the
psscr and psscr-mask exposed in the device tree. For older firmware
where psscr-mask=0xf, this patch will set the default sane values that
the set for for remaining PSSCR fields (i.e PSLL, MTL, ESL, EC, and
TR). For the new firmware, the patch will validate that the invariants
required by the ISA for the psscr values are maintained by the
firmware.
This skiboot patch that exports fully populated PSSCR values and the
mask for all the stop states can be found here:
https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html
[Optimize the number of instructions before entering STOP with
ESL=EC=0, validate the PSSCR values provided by the firimware
maintains the invariants required as per the ISA suggested by Balbir
Singh]
Signed-off-by: Gautham R. Shenoy
---
[v4] -> [v5]: a) Validate the psscr values provided by firmware.
b) Optimize the number of instructions before entering
stop with ESL=EC=0.
arch/powerpc/include/asm/cpuidle.h | 44 ++
arch/powerpc/include/asm/processor.h | 3 +-
arch/powerpc/kernel/idle_book3s.S| 30 ---
arch/powerpc/platforms/powernv/idle.c| 138 ---
arch/powerpc/platforms/powernv/powernv.h | 3 +-
arch/powerpc/platforms/powernv/smp.c | 14 ++--
drivers/cpuidle/cpuidle-powernv.c| 52 +---
7 files changed, 241 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/include/asm/cpuidle.h
b/arch/powerpc/include/asm/cpuidle.h
index 0a3255b..ced47ee 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -10,11 +10,55 @@
#define PNV_CORE_IDLE_LOCK_BIT 0x100
#define PNV_CORE_IDLE_THREAD_BITS 0x0FF
+/*
+ * NOTE =
+ * The older firmware populates only the RL field in the psscr_val and
+ * sets the psscr_mask to 0xf. On such a firmware, the kernel sets the
+ * remaining PSSCR fields to default values as follows:
+ *
+ * - ESL and EC bits are to 1. So wakeup from any stop state will be
+ * at vector 0x100.
+ *
+ * - MTL and PSLL are set to the maximum allowed value as per the ISA,
+ *i.e. 15.
+ *
+ * - The Transition Rate, TR is set to the Maximum value 3.
+ */
+#define PSSCR_HV_DEFAULT_VAL(PSSCR_ESL | PSSCR_EC |\
+ PSSCR_PSLL_MASK | PSSCR_TR_MASK | \
+ PSSCR_MTL_MASK)
+
+#define PSSCR_HV_DEFAULT_MASK (PSSCR_ESL | PSSCR_EC |\
+ PSSCR_PSLL_MASK | PSSCR_TR_MASK | \
+ PSSCR_MTL_MASK | PSSCR_RL_MASK)
+#define PSSCR_EC_SHIFT20
+#define PSSCR_ESL_SHIFT 21
+#define GET_PSSCR_EC(x) (((x) & PSSCR_EC) >> PSSCR_EC_SHIFT)
+#define GET_PSSCR_ESL(x) (((x) & PSSCR_ESL) >> PSSCR_ESL_SHIFT)
+#define GET_PSSCR_RL(x) ((x) & PSSCR_RL_MASK)
+
+#define ERR_EC_ESL_MISMATCH-1
+#define ERR_DEEP_STATE_ESL_MISMATCH-2
+
#ifndef __ASSEMBLY__
extern u32 pnv_fastsleep_workaround_at_entry[];
extern u32 pnv_fastsleep_workaround_at_exit[];
extern u64 pnv_first_deep_stop_state;
+
+int validate_psscr_val_mask(u64 *psscr_val, u64 *psscr_mask, u32 flags);
+static inline void report_invalid_psscr_val(u64 psscr_val, int err)
+{
+ switch (err) {
+ case ERR_EC_ESL_MISMATCH:
+ pr_warn("Invalid psscr %llx : ESL,EC bits unequal",
+ psscr_val);
+ break;
+ case ERR_DEEP_STATE_ESL_MISMATCH:
+ pr_warn("Invalid psscr %llx : ESL cleared for deep stop-state",
+ psscr_val);
+ }
+}
#endif
#endif
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index 4b47308..da68890 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -458,7 +458,8 @@ static inline unsigned long get_clean_sp(unsigned long sp,
in
[PATCH v5 5/5] Documentation:powerpc: Add device-tree bindings for power-mgt
From: "Gautham R. Shenoy" Document the device-tree bindings defining the the properties under the @power-mgt node in the device tree that describe the idle states for Linux running on baremetal POWER servers. Signed-off-by: Gautham R. Shenoy --- [v4]-> [v5]: Fixed a couple of typos. .../devicetree/bindings/powerpc/opal/power-mgt.txt | 125 + 1 file changed, 125 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt diff --git a/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt b/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt new file mode 100644 index 000..4967831 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt @@ -0,0 +1,125 @@ +IBM Power-Management Bindings += + +Linux running on baremetal POWER machines has access to the processor +idle states. The description of these idle states is exposed via the +node @power-mgt in the device-tree by the firmware. + +Definitions: + +Typically each idle state has the following associated properties: + +- name: The name of the idle state as defined by the firmware. + +- flags: indicating some aspects of this idle states such as the + extent of state-loss, whether timebase is stopped on this + idle states and so on. The flag bits are as follows: + +- exit-latency: The latency involved in transitioning the state of the + CPU from idle to running. + +- target-residency: The minimum time that the CPU needs to reside in + this idle state in order to accrue power-savings + benefit. + +Properties + +The following properties provide details about the idle states. These +properties are optional unless mentioned otherwise below. + +- ibm,cpu-idle-state-names: + Array of strings containing the names of the idle states. + +- ibm,cpu-idle-state-flags: + Array of unsigned 32-bit values containing the values of the + flags associated with the the aforementioned idle-states. This + property is required on POWER9 whenever + ibm,cpu-idle-state-names is defined and the length of this + property array should be the same as + ibm,-cpu-idle-state-names.The flag bits are as follows: + 0x0001 /* Decrementer would stop */ + 0x0002 /* Needs timebase restore */ + 0x1000 /* Restore GPRs like nap */ + 0x2000 /* Restore hypervisor resource from PACA pointer */ + 0x4000 /* Program PORE to restore PACA pointer */ + 0x0001 /* This is a nap state */ + 0x0002 /* This is a fast-sleep state */ + 0x0004 /* This is a winkle state */ + 0x0008 /* This is a fast-sleep state which requires a */ + /* software workaround for restoring the timebase*/ + 0x0080 /* This state uses SPR PMICR instruction */ + 0x0010 /* This is a fast stop state */ + 0x0020 /* This is a deep-stop state */ + +- ibm,cpu-idle-state-latencies-ns: + Array of unsigned 32-bit values containing the values of the + exit-latencies (in ns) for the idle states in + ibm,cpu-idle-state-names. This property is required whenever + ibm,cpu-idle-state-names is defined and the length of this + property array should be the same as + ibm,-cpu-idle-state-names. + +- ibm,cpu-idle-state-residency-ns: + Array of unsigned 32-bit values containing the values of the + target-residency (in ns) for the idle states in + ibm,cpu-idle-state-names. On POWER8 this is an optional + property. If the property is absent, the target residency for + the "Nap", "FastSleep" are defined to 1 and 3 + respectively. On POWER9 this property must be defined if + ibm,cpu-idle-state-names is defined and the length should be + same as that of ibm,cpu-idle-state-names. + +- ibm,cpu-idle-state-psscr: + Array of unsigned 64-bit values containing the values for the + PSSCR for each of the idle states in ibm,cpu-idle-state-names. + This property is required on POWER9 whenever + ibm,cpu-idle-state-names is defined and the length of this + property array should be the same as + ibm,cpu-idle-state-names. + +- ibm,cpu-idle-state-psscr-mask: + Array of unsigned 64-bit values containing the masks + indicating which psscr fields are set in the corresponding + entries of ibm,cpu-idle-state-psscr. This property is + required on POWER9 whenever ibm,cpu-idle-state-names is + defined and the length of this property array should be the + same as ibm,cpu-idle-state-names. + + Whenever the firmware sets an entry in + ibm,cpu-idle-state-psscr-mask value to 0xf, it implies that + only the Request
Re: [PATCH v6 16/17] mtd: nand: hynix: Rework NAND ID decoding to extract more information
Hi Julia,
On Mon, 9 Jan 2017 21:21:27 +0100 (CET)
Julia Lawall wrote:
> It looks odd that lines 158 and 160 are the same.
Indeed, it should be 'chip->ecc_step_ds = 1024;' in the else branch.
I'll fix that.
Thanks,
Boris
>
> julia
>
> -- Forwarded message --
>
> In-Reply-To:
> <1483956264-3335-17-git-send-email-boris.brezil...@free-electrons.com>
>
> Hi Boris,
>
> [auto build test WARNING on mtd/master]
> [also build test WARNING on v4.10-rc3 next-20170106]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Boris-Brezillon/mtd-nand-allow-vendor-specific-detection-initialization/20170110-01
> base: git://git.infradead.org/linux-mtd.git master
> :: branch date: 2 hours ago
> :: commit date: 2 hours ago
>
> >> drivers/mtd/nand/nand_hynix.c:157:4-6: WARNING: possible condition with no
> >> effect (if == else)
>
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout ee58e9ecc231f4a40ff46fe95078d7796ebe430b
> vim +157 drivers/mtd/nand/nand_hynix.c
>
> ee58e9ec Boris Brezillon 2017-01-09 141 */
> ee58e9ec Boris Brezillon 2017-01-09 142 WARN(1,
> "Invalid ECC requirements");
> 1065fa22 Boris Brezillon 2017-01-09 143 }
> ee58e9ec Boris Brezillon 2017-01-09 144 } else {
> ee58e9ec Boris Brezillon 2017-01-09 145 /*
> ee58e9ec Boris Brezillon 2017-01-09 146 * The ECC requirements
> field meaning depends on the
> ee58e9ec Boris Brezillon 2017-01-09 147 * NAND technology.
> ee58e9ec Boris Brezillon 2017-01-09 148 */
> ee58e9ec Boris Brezillon 2017-01-09 149 u8 nand_tech =
> chip->id.data[5] & 0x3;
> 1065fa22 Boris Brezillon 2017-01-09 150
> ee58e9ec Boris Brezillon 2017-01-09 151 if (nand_tech < 3) {
> ee58e9ec Boris Brezillon 2017-01-09 152 /* > 26nm,
> reference: H27UBG8T2A datasheet */
> ee58e9ec Boris Brezillon 2017-01-09 153 if (ecc_level <
> 5) {
> ee58e9ec Boris Brezillon 2017-01-09 154
> chip->ecc_step_ds = 512;
> ee58e9ec Boris Brezillon 2017-01-09 155
> chip->ecc_strength_ds = 1 << ecc_level;
> ee58e9ec Boris Brezillon 2017-01-09 156 } else if
> (ecc_level < 7) {
> ee58e9ec Boris Brezillon 2017-01-09 @157 if
> (ecc_level == 5)
> ee58e9ec Boris Brezillon 2017-01-09 158
> chip->ecc_step_ds = 2048;
> 1065fa22 Boris Brezillon 2017-01-09 159 else
> ee58e9ec Boris Brezillon 2017-01-09 160
> chip->ecc_step_ds = 2048;
> ee58e9ec Boris Brezillon 2017-01-09 161
> chip->ecc_strength_ds = 24;
> ee58e9ec Boris Brezillon 2017-01-09 162 } else {
> ee58e9ec Boris Brezillon 2017-01-09 163 /*
> ee58e9ec Boris Brezillon 2017-01-09 164 * We
> should never reach this case, but if that
> ee58e9ec Boris Brezillon 2017-01-09 165 *
> happens, this probably means Hynix decided
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH v3 09/15] livepatch: remove unnecessary object loaded check
On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote: klp_patch_object()'s callers already ensure that the object is loaded, so its call to klp_is_object_loaded() is unnecessary. This will also make it possible to move the patching code into a separate file. Signed-off-by: Josh Poimboeuf Reviewed-by: Kamalesh Babulal -- cheers, Kamalesh.
Re: [PATCH v3 10/15] livepatch: move patching functions into patch.c
On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote: Move functions related to the actual patching of functions and objects into a new patch.c file. Signed-off-by: Josh Poimboeuf Reviewed-by: Kamalesh Babulal -- cheers, Kamalesh.
Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding documentation
On Tue, 10 Jan 2017 08:48:09 + Punnaiah Choudary Kalluri wrote: > Hi Boris, > > Thanks. I will implement these changes and send the next series. Please wait a bit. I still need to review the driver. > > Regards, > Punnaiah > > > -Original Message- > > From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com] > > Sent: Tuesday, January 10, 2017 1:36 PM > > To: Punnaiah Choudary Kalluri > > Cc: Rob Herring ; dw...@infradead.org; > > computersforpe...@gmail.com; marek.va...@gmail.com; rich...@nod.at; > > cyrille.pitc...@atmel.com; mark.rutl...@arm.com; linux- > > ker...@vger.kernel.org; linux-...@lists.infradead.org; > > devicet...@vger.kernel.org; Michal Simek ; > > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com > > Subject: Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding > > documentation > > > > Hi Punnaiah, > > > > On Tue, 10 Jan 2017 06:03:25 + > > Punnaiah Choudary Kalluri wrote: > > > > > Hi Rob, > > > > > >Thanks for the review. > > > > > > > -Original Message- > > > > From: Rob Herring [mailto:r...@kernel.org] > > > > Sent: Tuesday, January 10, 2017 11:06 AM > > > > To: Punnaiah Choudary Kalluri > > > > Cc: dw...@infradead.org; computersforpe...@gmail.com; > > > > boris.brezil...@free-electrons.com; marek.va...@gmail.com; > > > > rich...@nod.at; cyrille.pitc...@atmel.com; mark.rutl...@arm.com; > > linux- > > > > ker...@vger.kernel.org; linux-...@lists.infradead.org; > > > > devicet...@vger.kernel.org; Michal Simek ; > > > > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah > > > > Choudary Kalluri > > > > Subject: Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding > > > > documentation > > > > > > > > On Mon, Jan 09, 2017 at 08:28:53AM +0530, Punnaiah Choudary Kalluri > > wrote: > > > > > This patch adds the dts binding document for arasan nand flash > > > > > controller. > > > > > > > > > > Signed-off-by: Punnaiah Choudary Kalluri > > > > > --- > > > > > Changes in v7: > > > > > - Corrected the acronyms those should be in caps > > > > > changes in v6: > > > > > - Removed num-cs property > > > > > - Separated nandchip from nand controller > > > > > changes in v5: > > > > > - None > > > > > Changes in v4: > > > > > - Added num-cs property > > > > > - Added clock support > > > > > Changes in v3: > > > > > - None > > > > > Changes in v2: > > > > > - None > > > > > --- > > > > > .../devicetree/bindings/mtd/arasan_nfc.txt | 38 > > > > ++ > > > > > 1 file changed, 38 insertions(+) > > > > > create mode 100644 > > > > Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > > new file mode 100644 > > > > > index 000..f20adfc > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > > @@ -0,0 +1,38 @@ > > > > > +Arasan NAND Flash Controller with ONFI 3.1 support > > > > > + > > > > > +Required properties: > > > > > +- compatible: Should be "arasan,nfc-v3p10" > > > > > > > > Needs a note that it must also have an SoC specific compatible string. > > > > > > > Sorry, I couldn't understand this comment. Could you elaborate it? > > > > Arasan is an IP vendor, and those IPs are usually embedded in specific > > SoCs. I guess Rob was suggesting to define something like: > > > > compatible = ",", "arasan,"; > > > > This way you can differentiate minor changes/tweaks between each SoC > > (each SoC vendor usually enable/disable specific features based on > > their needs). > > > > > > > > > > +- reg: Memory map for module access > > > > > +- interrupt-parent: Interrupt controller the interrupt is routed > > > > > through > > > > > +- interrupts: Should contain the interrupt for the device > > > > > +- clock-name: List of input clocks - "clk_sys", "clk_flash" > > > > > > > > clk_ is redundant. > > > > > > > > > > I have defined these clock names as per the controller data sheet. > > > So, I feel it is fine to have them in sync with the datasheet. > > > Please let me know if you still want me to change this. > > > > We already know this is a clock, hence the unneeded clk_ prefix. Please > > drop it. > > > > Thanks, > > > > Boris
[PATCH v2 0/2] media: rc: add support for IR receiver on MT7623 SoC
From: Sean Wang This patchset introduces consumer IR (CIR) support on MT7623 SoC that also works on other similar SoCs and implements raw mode for more compatibility with different protocols. The driver simply reports the duration of pulses and spaces to rc-core logic to decode. Changes since v1: - change compatible string from "mediatek,mt7623-ir" into "mediatek,mt7623-cir" - use KBUILD_MODNAME to provide consistent device name used in driver. - remove unused fields in struct mtk_ir. - use synchronize_irq to give protection between IRQ handler and remove handler. - use devm_rc_allocate_device based on Andi Shyti's work. - simplify error handling patch with devm_rc_register_device and devm_rc_allocate_device. - remove unused spinlock. - add comments about hardware limitation and related workarounds. - enhance the caculation of sampling period for easiler assigned specific value. - refine git description. - fix IR message handling between IR hardware and rc-core. Sean Wang (2): Documentation: devicetree: Add document bindings for mtk-cir media: rc: add driver for IR remote receiver on MT7623 SoC .../devicetree/bindings/media/mtk-cir.txt | 24 ++ drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile | 1 + drivers/media/rc/mtk-cir.c | 326 + 4 files changed, 362 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt create mode 100644 drivers/media/rc/mtk-cir.c -- 2.7.4
Re: [RESEND RFC 1/3] mmc: sdhci: Add platform_dumpregs callback support to sdhci_ops.
On 2017/1/10 14:41, Ritesh Harjani wrote:
From: Sahitya Tummala
Add new host operation ->platform_dumpregs to provide a
mechanism through which host drivers can dump platform
specific registers in addition to SDHC registers
during error conditions.
Although we have been preventing from adding new callback
for sdhci core, this one makes sense as there are more and more
vendor registers outside the scope of SDHCI spec.
Signed-off-by: Sahitya Tummala
Signed-off-by: Ritesh Harjani
---
drivers/mmc/host/sdhci.c | 3 +++
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2390980..73a8918 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -101,6 +101,9 @@ static void sdhci_dumpregs(struct sdhci_host *host)
readl(host->ioaddr + SDHCI_ADMA_ADDRESS));
}
+ if (host->ops->platform_dumpregs)
+ host->ops->platform_dumpregs(host);
+
pr_err(DRIVER_NAME ": ===\n");
}
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 0b66f21..400f3a1 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -564,6 +564,7 @@ struct sdhci_ops {
struct mmc_card *card,
unsigned int max_dtr, int host_drv,
int card_drv, int *drv_type);
+ void(*platform_dumpregs)(struct sdhci_host *host);
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
--
Best Regards
Shawn Lin
[PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Wang
This patch adds driver for IR controller on MT7623 SoC.
and should also work on similar Mediatek SoC. Currently
testing successfully on NEC and SONY remote controller
only but it should work on others (lirc, rc-5 and rc-6).
Signed-off-by: Sean Wang
Reviewed-by: Sean Young
---
drivers/media/rc/Kconfig | 11 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/mtk-cir.c | 326 +
3 files changed, 338 insertions(+)
create mode 100644 drivers/media/rc/mtk-cir.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 629e8ca..9228479 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -235,6 +235,17 @@ config IR_MESON
To compile this driver as a module, choose M here: the
module will be called meson-ir.
+config IR_MTK
+ tristate "Mediatek IR remote receiver"
+ depends on RC_CORE
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ ---help---
+ Say Y if you want to use the IR remote receiver available
+ on Mediatek SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-cir.
+
config IR_NUVOTON
tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
depends on PNP
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 3a984ee..a78570b 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_RC_ST) += st_rc.o
obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
obj-$(CONFIG_IR_IMG) += img-ir/
obj-$(CONFIG_IR_SERIAL) += serial_ir.o
+obj-$(CONFIG_IR_MTK) += mtk-cir.o
diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
new file mode 100644
index 000..f752f63
--- /dev/null
+++ b/drivers/media/rc/mtk-cir.c
@@ -0,0 +1,326 @@
+/*
+ * Driver for Mediatek IR Receiver Controller
+ *
+ * Copyright (C) 2017 Sean Wang
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MTK_IR_DEV KBUILD_MODNAME
+
+/* Register to enable PWM and IR */
+#define MTK_CONFIG_HIGH_REG 0x0c
+/* Enable IR pulse width detection */
+#define MTK_PWM_EN BIT(13)
+/* Enable IR hardware function */
+#define MTK_IR_ENBIT(0)
+
+/* Register to setting sample period */
+#define MTK_CONFIG_LOW_REG0x10
+/* Field to set sample period */
+#define CHK_PERIOD DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, \
+ MTK_IR_CLK_PERIOD)
+#define MTK_CHK_PERIOD(((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
+#define MTK_CHK_PERIOD_MASK (GENMASK(20, 8))
+
+/* Register to clear state of state machine */
+#define MTK_IRCLR_REG 0x20
+/* Bit to restart IR receiving */
+#define MTK_IRCLRBIT(0)
+
+/* Register containing pulse width data */
+#define MTK_CHKDATA_REG(i)(0x88 + 4 * (i))
+#define MTK_WIDTH_MASK (GENMASK(7, 0))
+
+/* Register to enable IR interrupt */
+#define MTK_IRINT_EN_REG 0xcc
+/* Bit to enable interrupt */
+#define MTK_IRINT_EN BIT(0)
+
+/* Register to ack IR interrupt */
+#define MTK_IRINT_CLR_REG 0xd0
+/* Bit to clear interrupt status */
+#define MTK_IRINT_CLRBIT(0)
+
+/* Maximum count of samples */
+#define MTK_MAX_SAMPLES 0xff
+/* Indicate the end of IR message */
+#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
+/* Number of registers to record the pulse width */
+#define MTK_CHKDATA_SZ 17
+/* Source clock frequency */
+#define MTK_IR_BASE_CLK 27300
+/* Frequency after IR internal divider */
+#define MTK_IR_CLK_FREQ (MTK_IR_BASE_CLK / 4)
+/* Period for MTK_IR_CLK in ns*/
+#define MTK_IR_CLK_PERIODDIV_ROUND_CLOSEST(10ul, \
+ MTK_IR_CLK_FREQ)
+/* Sample period in ns */
+#define MTK_IR_SAMPLE(MTK_IR_CLK_PERIOD * 0xc00)
+
+/* struct mtk_ir - This is the main datasructure for holding the state
+ * of the driver
+ * @dev: The device pointer
+ * @rc:The rc instrance
+ * @irq: The IRQ that we are using
+ * @base: The mapped register i/o base
+ * @clk: The clock that we are using
+ */
+struct mtk_ir {
+ struct device *dev;
+ struct rc_dev *rc;
+ void __iome
Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum
On Mon, Jan 09, 2017 at 04:19:29PM -0800, h...@zytor.com wrote: > Any reason to not make these interfaces (leaf, subleaf) from the start? Two, actually: 1. I modelled them after the cpuid_(op) versions 2. I don't think we need the subleaf variant right now. But, when we do, we can do that when we cross that bridge and add native_cpuid_(leaf, subleaf) which gets called by the native_cpuid_(leaf) variants. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
[PATCH v2 1/2] Documentation: devicetree: Add document bindings for mtk-cir
From: Sean Wang
This patch adds documentation for devicetree bindings for
Mediatek consumer IR controller.
Signed-off-by: Sean Wang
---
.../devicetree/bindings/media/mtk-cir.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt
b/Documentation/devicetree/bindings/media/mtk-cir.txt
new file mode 100644
index 000..3850cbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
@@ -0,0 +1,24 @@
+Device-Tree bindings for Mediatek consumer IR controller found in
+Mediatek SoC family
+
+Required properties:
+- compatible : "mediatek,mt7623-cir"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "clk" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+
+Optional properties:
+- linux,rc-map-name : Remote control map name.
+
+Example:
+
+cir: cir@10013000 {
+ compatible = "mediatek,mt7623-cir";
+ reg = <0 0x10013000 0 0x1000>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_IRRX>;
+ clock-names = "clk";
+ linux,rc-map-name = "rc-rc6-mce";
+};
--
2.7.4
Re: [BUG] How to crash 4.9.2 x86_64: vmscan: shrink_slab
On Mon 09-01-17 23:02:10, Sami Farin wrote: > # sysctl vm.vfs_cache_pressure=-100 > > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-6640827866535449472 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-6640827866535450112 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-661702561611775889 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-6640827866535442432 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-6562613194205300197 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-6640827866535439872 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-659655090764208789 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-6564660665198832072 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-6562613194351275164 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-6562615996648922728 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-6564660665198832072 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-6562613194351264981 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-569296135781119076 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-565206492037048430 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-565212096665106188 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-569296135781119076 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-565206492037043196 > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > delete nr=-659660388715270673 > > > Alternatively, > # sysctl vm.vfs_cache_pressure=1000 Both values are insane and admins do not do insane things to their machines, do they? I am not sure how much we want to check the input value. -100 is clearly bogus and .procname = "vfs_cache_pressure", .data = &sysctl_vfs_cache_pressure, .maxlen = sizeof(sysctl_vfs_cache_pressure), .mode = 0644, .proc_handler = &proc_dointvec, .extra1 = &zero, tries to enforce min (extra1) check except proc_dointvec doesn't care about this... This is news to me. Only proc_dointvec_minmax does care about extra*, it seems. -- Michal Hocko SUSE Labs
Re: [PATCH v2 1/4] lib: Update LZ4 compressor module based on LZ4 v1.7.2.
On 01/08/2017 12:25 PM, Greg KH wrote: >On Sat, Jan 07, 2017 at 05:55:42PM +0100, Sven Schmidt wrote: >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet. >> The kernel module is inspired by the previous work by Chanho Min. >> The updated LZ4 module will not break existing code since there were alias >> methods added to ensure backwards compatibility. > > Meta-comment. Does this update include all of the security fixes that > we have made over the past few years to the lz4 code? I don't want to > be adding back insecure functions that will cause us problems. > > Specifically look at the changes I made in 2014 in this directory for an > example of what I am talking about here. > Hi Greg, it doesn't. I didn't have that in mind until now. But I had a look at the related commits after I received your E-Mail and will review what I have to change (and, obviously, do the changes :)). Thanks, Sven
Re: [PATCH 1/3] arm64: dts: Pine64: add MMC support
Hi Andre, [auto build test ERROR on mripard/sunxi/for-next] [also build test ERROR on next-20170110] [cannot apply to robh/for-next v4.10-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andre-Przywara/arm64-dts-A64-board-MMC-support/20170110-124554 base: https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git sunxi/for-next config: arm64-defconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm64 All errors (new ones prefixed by >>): >> Error: arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts:83.1-6 Label or >> path mmc0 not found >> FATAL ERROR: Syntax error parsing input tree --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v8 0/5] Add support for the STM32F4 I2C
On Thu, Jan 5, 2017 at 10:07 AM, M'boumba Cedric Madianga wrote: > This patchset adds support for the I2C controller embedded in STM32F4xx SoC. > It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus > speed. The whole series: Reviewed-by: Linus Walleij Looks perfect from my point of view now. Yours, Linus Walleij
Re: [RESEND 3/3] ARM: davinci_all_defconfig: enable iio and ADS7950
On Monday 09 January 2017 09:41 PM, David Lechner wrote: > This enables the iio subsystem and the TI ADS7950 driver. This is used by > LEGO MINDSTORMS EV3, which has an ADS7957 chip. > > Signed-off-by: David Lechner > --- > arch/arm/configs/davinci_all_defconfig | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm/configs/davinci_all_defconfig > b/arch/arm/configs/davinci_all_defconfig > index 2b1967a..a899876 100644 > --- a/arch/arm/configs/davinci_all_defconfig > +++ b/arch/arm/configs/davinci_all_defconfig > @@ -200,6 +200,13 @@ CONFIG_TI_EDMA=y > CONFIG_MEMORY=y > CONFIG_TI_AEMIF=m > CONFIG_DA8XX_DDRCTL=y > +CONFIG_IIO=m > +CONFIG_IIO_BUFFER_CB=m > +CONFIG_IIO_SW_DEVICE=m > +CONFIG_IIO_SW_TRIGGER=m > +CONFIG_TI_ADS7950=m > +CONFIG_IIO_HRTIMER_TRIGGER=m > +CONFIG_IIO_SYSFS_TRIGGER=m Hmm, there are some other comments I gave on the previous version I don't see addressed. Can you please fix those or respond to those comments? Thanks, Sekhar
Re: [PATCH] tools: gpio add .gitignore for generated files
On Thu, Jan 5, 2017 at 10:32 PM, Shuah Khan wrote: > Add .gitignore for generated files. > > Signed-off-by: Shuah Khan > --- > tools/gpio/.gitignore | 4 > 1 file changed, 4 insertions(+) > create mode 100644 tools/gpio/.gitignore > > diff --git a/tools/gpio/.gitignore b/tools/gpio/.gitignore > new file mode 100644 > index 000..767ad24 > --- /dev/null > +++ b/tools/gpio/.gitignore > @@ -0,0 +1,4 @@ > +gpio-event-mon > +gpio-hammer > +lsgpio > +include I understand the first three. But "include"? How did you produce that? Yours, Linus Walleij
Re: [PATCH v2] mm: Respect FOLL_FORCE/FOLL_COW for thp
On Fri 06-01-17 11:18:44, Kirill A. Shutemov wrote:
> On Thu, Jan 05, 2017 at 08:50:25PM -0500, Keno Fischer wrote:
> > In 19be0eaff ("mm: remove gup_flags FOLL_WRITE games from
> > __get_user_pages()"),
> > the mm code was changed from unsetting FOLL_WRITE after a COW was resolved
> > to
> > setting the (newly introduced) FOLL_COW instead. Simultaneously, the check
> > in
> > gup.c was updated to still allow writes with FOLL_FORCE set if FOLL_COW had
> > also been set. However, a similar check in huge_memory.c was forgotten. As a
> > result, remote memory writes to ro regions of memory backed by transparent
> > huge
> > pages cause an infinite loop in the kernel (handle_mm_fault sets FOLL_COW
> > and
> > returns 0 causing a retry, but follow_trans_huge_pmd bails out immidiately
> > because `(flags & FOLL_WRITE) && !pmd_write(*pmd)` is true. While in this
> > state the process is stil SIGKILLable, but little else works (e.g. no ptrace
> > attach, no other signals). This is easily reproduced with the following
> > code (assuming thp are set to always):
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > #define TEST_SIZE 5 * 1024 * 1024
> >
> > int main(void) {
> > int status;
> > pid_t child;
> > int fd = open("/proc/self/mem", O_RDWR);
> > void *addr = mmap(NULL, TEST_SIZE, PROT_READ,
> > MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
> > assert(addr != MAP_FAILED);
> > pid_t parent_pid = getpid();
> > if ((child = fork()) == 0) {
> > void *addr2 = mmap(NULL, TEST_SIZE, PROT_READ | PROT_WRITE,
> >MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
> > assert(addr2 != MAP_FAILED);
> > memset(addr2, 'a', TEST_SIZE);
> > pwrite(fd, addr2, TEST_SIZE, (uintptr_t)addr);
> > return 0;
> > }
> > assert(child == waitpid(child, &status, 0));
> > assert(WIFEXITED(status) && WEXITSTATUS(status) == 0);
> > return 0;
> > }
> >
> > Fix this by updating follow_trans_huge_pmd in huge_memory.c analogously to
> > the update in gup.c in the original commit. The same pattern exists in
> > follow_devmap_pmd. However, we should not be able to reach that check
> > with FOLL_COW set, so add WARN_ONCE to make sure we notice if we ever
> > do.
> >
> > Signed-off-by: Keno Fischer
>
> Cc: stable@ ?
Yes, please! I am just wondering how far do we have to go. I was under
impression that we split THP in the past in the gup path but I cannot
find the respective code now. Many things have changed after your
refcount rework. Could you clarify this part Kirill, please?
> Acke-by: Kirill A. Shutemov
The patch looks good to me.
Acked-by: Michal Hocko
Thanks!
--
Michal Hocko
SUSE Labs
Re: [PATCH v5 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
Hi,
This needs a commit message, please add one.
On 10/01/2017 at 09:08:51 +0100, Peter Rosin wrote :
> Acked-by: Rob Herring
> Signed-off-by: Peter Rosin
> ---
> Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
> MAINTAINERS | 8 +
> arch/arm/boot/dts/Makefile| 1 +
> arch/arm/boot/dts/at91-linea.dtsi | 53 +
> arch/arm/boot/dts/at91-tse850-3.dts | 274
> ++
> 5 files changed, 355 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
> create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
> create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/axentia.txt
> b/Documentation/devicetree/bindings/arm/axentia.txt
> new file mode 100644
> index ..ea3fb96ae465
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/axentia.txt
> @@ -0,0 +1,19 @@
> +Device tree bindings for Axentia ARM devices
> +
> +
> +Linea CPU module
> +
> +
> +Required root node properties:
> +compatible = "axentia,linea",
> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
> +and following the rules from atmel-at91.txt for a sama5d31 SoC.
> +
> +
> +TSE-850 v3 board
> +
> +
> +Required root node properties:
> +compatible = "axentia,tse850v3", "axentia,linea",
> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
> +and following the rules from above for the axentia,linea CPU module.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 97b78cc5aa51..5c2ea6e9cd7f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2346,6 +2346,14 @@ S: Maintained
> F: Documentation/devicetree/bindings/sound/axentia,*
> F: sound/soc/atmel/tse850-pcm5142.c
>
> +AXENTIA ARM DEVICES
> +M: Peter Rosin
> +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
> +S: Maintained
> +F: Documentation/devicetree/bindings/arm/axentia.txt
> +F: arch/arm/boot/dts/at91-linea.dtsi
> +F: arch/arm/boot/dts/at91-tse850-3.dts
> +
I don't think you need to add yourself to MAINTAINERS for two DTs if
that is just to keep checkpatch happy, don't bother.
> AZ6007 DVB DRIVERV
> M: Mauro Carvalho Chehab
> M: Mauro Carvalho Chehab
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9a7375c388a8..7632849866de 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
> at91-kizbox2.dtb \
> at91-sama5d2_xplained.dtb \
> at91-sama5d3_xplained.dtb \
> + at91-tse850-3.dtb \
> sama5d31ek.dtb \
> sama5d33ek.dtb \
> sama5d34ek.dtb \
> diff --git a/arch/arm/boot/dts/at91-linea.dtsi
> b/arch/arm/boot/dts/at91-linea.dtsi
> new file mode 100644
> index ..646feb0daa81
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91-linea.dtsi
> @@ -0,0 +1,53 @@
> +/*
> + * at91-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
> + *
> + * Copyright (C) 2017 Axentia Technologies AB
> + *
> + * Author: Peter Rosin
> + *
> + * Licensed under GPLv2 or later.
> + */
> +
> +#include "sama5d31.dtsi"
> +
> +/ {
> + compatible = "axentia,linea",
> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
> +
> + memory {
> + reg = <0x2000 0x400>;
> + };
> +};
> +
> +&slow_xtal {
> + clock-frequency = <32768>;
> +};
> +
> +&main_xtal {
> + clock-frequency = <1200>;
> +};
> +
> +&main {
> + clock-frequency = <1200>;
> +};
> +
I don't think this is needed
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Re: [RESEND 1/3] ARM: davinci_all_defconfig: enable DA8xx pinconf
On Monday 09 January 2017 09:41 PM, David Lechner wrote: > This enables the DA8xx pinconf driver by default. It is needed by LEGO > MINDSTORMS EV3. > > Signed-off-by: David Lechner Applied to v4.11/defconfig Thanks, Sekhar
Re: [RESEND 2/3] ARM: davinci_all_defconfig: Enable PWM modules
On Monday 09 January 2017 09:41 PM, David Lechner wrote: > This enables PWM and the TI ECAP and EHRWPM modules. These are used on LEGO > MINDSTORMS EV3. > > Signed-off-by: David Lechner Applied to v4.11/defconfig Thanks, Sekhar
Re: [PATCH] clk: qcom: gdsc: Fix handling of hw control enable/disable
Hi Rajendra,
Thanks for the patch!
On 01/10/2017 07:54 AM, Rajendra Nayak wrote:
> Once a gdsc is brought in and out of HW control, there is a
> power down and up cycle which can take upto 1us. Polling on
> the gdsc status immediately after the hw control enable/disable
> can mislead software/firmware to belive the gdsc is already either on
> or off, while its yet to complete the power cycle.
> To avoid this add a 1us delay post a enable/disable of HW control
> mode.
>
> Also after the HW control mode is disabled, poll on the status to
> check gdsc status reflects its 'on' before force disabling it
> in software.
>
> Reported-by: Stanimir Varbanov
> Signed-off-by: Rajendra Nayak
> ---
>
> Stan,
> If there was a specific issue you saw with venus because of the missing
> delay and poll, can you check if this fixes any of that.
>
> drivers/clk/qcom/gdsc.c | 58
> ++---
> 1 file changed, 45 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> index 288186c..6fbd6df 100644
> --- a/drivers/clk/qcom/gdsc.c
> +++ b/drivers/clk/qcom/gdsc.c
> @@ -63,11 +63,26 @@ static int gdsc_hwctrl(struct gdsc *sc, bool en)
> return regmap_update_bits(sc->regmap, sc->gdscr, HW_CONTROL_MASK, val);
> }
>
> +static int gdsc_poll_status(struct gdsc *sc, unsigned int reg, bool val)
Could you rename 'val' to 'en'.
> +{
> + ktime_t start;
> +
> + start = ktime_get();
> + do {
> + if (gdsc_is_enabled(sc, reg) == val)
> + return 0;
> + } while (ktime_us_delta(ktime_get(), start) < TIMEOUT_US);
> +
> + if (gdsc_is_enabled(sc, reg) == val)
> + return 0;
> +
> + return -ETIMEDOUT;
> +}
> +
> static int gdsc_toggle_logic(struct gdsc *sc, bool en)
> {
> int ret;
> u32 val = en ? 0 : SW_COLLAPSE_MASK;
> - ktime_t start;
> unsigned int status_reg = sc->gdscr;
>
> ret = regmap_update_bits(sc->regmap, sc->gdscr, SW_COLLAPSE_MASK, val);
> @@ -100,16 +115,7 @@ static int gdsc_toggle_logic(struct gdsc *sc, bool en)
> udelay(1);
> }
>
> - start = ktime_get();
> - do {
> - if (gdsc_is_enabled(sc, status_reg) == en)
> - return 0;
> - } while (ktime_us_delta(ktime_get(), start) < TIMEOUT_US);
> -
> - if (gdsc_is_enabled(sc, status_reg) == en)
> - return 0;
> -
> - return -ETIMEDOUT;
> + return gdsc_poll_status(sc, status_reg, en);
> }
>
> static inline int gdsc_deassert_reset(struct gdsc *sc)
> @@ -188,8 +194,19 @@ static int gdsc_enable(struct generic_pm_domain *domain)
> udelay(1);
>
> /* Turn on HW trigger mode if supported */
> - if (sc->flags & HW_CTRL)
> - return gdsc_hwctrl(sc, true);
> + if (sc->flags & HW_CTRL) {
> + ret = gdsc_hwctrl(sc, true);
> + /*
> + * Wait for the GDSC to go through a power down and
> + * up cycle. In case a firmware ends up polling status
> + * bits for the gdsc, it might read an 'on' status before
> + * the GDSC can finish the power cycle.
> + * We wait 1us before returning to ensure the firmware
> + * can't immediately poll the status bits.
> + */
> + mb();
Missing comment for this memory barrier, although I think it is
pointless because regmap-mmio using readl and writel.
> + udelay(1);
> + }
>
> return 0;
> }
> @@ -204,9 +221,24 @@ static int gdsc_disable(struct generic_pm_domain *domain)
>
> /* Turn off HW trigger mode if supported */
> if (sc->flags & HW_CTRL) {
> + unsigned int reg;
> +
> ret = gdsc_hwctrl(sc, false);
> if (ret < 0)
> return ret;
> + /*
> + * Wait for the GDSC to go through a power down and
> + * up cycle. In case we end up polling status
> + * bits for the gdsc before the power cycle is completed
> + * it might read an 'on' status wrongly.
> + */
> + mb();
Same comment as above one.
> + udelay(1);
> +
> + reg = sc->gds_hw_ctrl ? sc->gds_hw_ctrl : sc->gdscr;
> + ret = gdsc_poll_status(sc, reg, 0);
This should be gdsc_poll_status(sc, reg, true) because after disabling
hw_control we expect that the GDSC is in power_on state.
> + if (ret)
> + return ret;
> }
>
> if (sc->pwrsts & PWRSTS_OFF)
>
--
regards,
Stan
Re: [PATCH v2 1/4] lib: Update LZ4 compressor module based on LZ4 v1.7.2.
On 01/08/2017 12:23 PM, Greg KH wrote:
> On Sat, Jan 07, 2017 at 05:55:43PM +0100, Sven Schmidt wrote:
>> This patch updates the unlz4 wrapper to work with the new LZ4 kernel module
>> version.
>>
>> Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
>> ---
>> lib/decompress_unlz4.c | 13 -
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/lib/decompress_unlz4.c b/lib/decompress_unlz4.c
>> index 036fc88..1b0baf3 100644
>> --- a/lib/decompress_unlz4.c
>> +++ b/lib/decompress_unlz4.c
>> @@ -72,7 +72,7 @@ STATIC inline int INIT unlz4(u8 *input, long in_len,
>> error("NULL input pointer and missing fill function");
>> goto exit_1;
>> } else {
>> -inp = large_malloc(lz4_compressbound(uncomp_chunksize));
>> +inp = large_malloc(LZ4_compressBound(uncomp_chunksize));
>
> Having functions differ by different cases of the characters is ripe for
> abuse and confusion. Please never do that, especially as these "new"
> functions you created don't follow the correct kernel coding style rules
> :(
>
> thanks,
>
> greg k-h
Hi Greg,
you're right about that. I think I put a little too much effort in keeping old
function names here.
I will get rid of that.
I also want to quote your previous E-Mail here:
> And follow the proper kernel coding style rules, putting your patches
> through scripts/checkpatch.pl should help you out here.
Sorry, I didn't know about that particular script. I already put Patches 2, 3
and 4 through checkpatch.pl;
patch 1 is a little more to rework but I will, of course, do that.
Thanks,
Sven
Re: [PATCH] mm/hugetlb.c: fix reservation race when freeing surplus pages
On Mon 09-01-17 11:56:07, Mike Kravetz wrote:
> The routine return_unused_surplus_pages decrements the global
> reservation count, and frees any unused surplus pages that were
> backing the reservation. Commit 7848a4bf51b3 ("mm/hugetlb.c:
> add cond_resched_lock() in return_unused_surplus_pages()") added
> a call to cond_resched_lock in the loop freeing the pages. As
> a result, the hugetlb_lock could be dropped, and someone else
> could use the pages that will be freed in subsequent iterations
> of the loop. This could result in inconsistent global hugetlb
> page state, application api failures (such as mmap) failures or
> application crashes.
>
> When dropping the lock in return_unused_surplus_pages, make sure
> that the global reservation count (resv_huge_pages) remains
> sufficiently large to prevent someone else from claiming pages
> about to be freed.
>
> Fixes: 7848a4bf51b3 ("mm/hugetlb.c: add cond_resched_lock() in
> return_unused_surplus_pages()")
> Reported-and-analyzed-by: Paul Cassella
> Suggested-by: Michal Hocko
> Signed-off-by: Mike Kravetz
Looks good to me. I think we want also
Cc: stable # 3.15+
Paul, your Tested-by would be more than appreciated.
Thanks Mike!
> ---
> mm/hugetlb.c | 37 -
> 1 file changed, 28 insertions(+), 9 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 418bf01..a1760fa 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1773,23 +1773,32 @@ static int gather_surplus_pages(struct hstate *h, int
> delta)
> }
>
> /*
> - * When releasing a hugetlb pool reservation, any surplus pages that were
> - * allocated to satisfy the reservation must be explicitly freed if they were
> - * never used.
> - * Called with hugetlb_lock held.
> + * This routine has two main purposes:
> + * 1) Decrement the reservation count (resv_huge_pages) by the value passed
> + *in unused_resv_pages. This corresponds to the prior adjustments made
> + *to the associated reservation map.
> + * 2) Free any unused surplus pages that may have been allocated to satisfy
> + *the reservation. As many as unused_resv_pages may be freed.
> + *
> + * Called with hugetlb_lock held. However, the lock could be dropped (and
> + * reacquired) during calls to cond_resched_lock. Whenever dropping the
> lock,
> + * we must make sure nobody else can claim pages we are in the process of
> + * freeing. Do this by ensuring resv_huge_page always is greater than the
> + * number of huge pages we plan to free when dropping the lock.
> */
> static void return_unused_surplus_pages(struct hstate *h,
> unsigned long unused_resv_pages)
> {
> unsigned long nr_pages;
>
> - /* Uncommit the reservation */
> - h->resv_huge_pages -= unused_resv_pages;
> -
> /* Cannot return gigantic pages currently */
> if (hstate_is_gigantic(h))
> - return;
> + goto out;
>
> + /*
> + * Part (or even all) of the reservation could have been backed
> + * by pre-allocated pages. Only free surplus pages.
> + */
> nr_pages = min(unused_resv_pages, h->surplus_huge_pages);
>
> /*
> @@ -1799,12 +1808,22 @@ static void return_unused_surplus_pages(struct hstate
> *h,
>* when the nodes with surplus pages have no free pages.
>* free_pool_huge_page() will balance the the freed pages across the
>* on-line nodes with memory and will handle the hstate accounting.
> + *
> + * Note that we decrement resv_huge_pages as we free the pages. If
> + * we drop the lock, resv_huge_pages will still be sufficiently large
> + * to cover subsequent pages we may free.
>*/
> while (nr_pages--) {
> + h->resv_huge_pages--;
> + unused_resv_pages--;
> if (!free_pool_huge_page(h, &node_states[N_MEMORY], 1))
> - break;
> + goto out;
> cond_resched_lock(&hugetlb_lock);
> }
> +
> +out:
> + /* Fully uncommit the reservation */
> + h->resv_huge_pages -= unused_resv_pages;
> }
>
>
> --
> 2.7.4
--
Michal Hocko
SUSE Labs
Re: [PATCH v2 2/6] KVM: x86: decouple irqchip_in_kernel() and pic_irqchip()
On 10/01/2017 06:09, Peter Xu wrote:
>> Was wondering if FULL/SPLIT would be a better naming. However I also
>> find irqchip_kernel() vs irqchip_in_kernel() slightly confusing.
> Me too. Since we have kvm_irqchip_mode enum above, how about renaming
> irqchip_{kernel|split}() into irqchip_mode_{kernel|split}()?
>
> Sorry for such a late comment...
No problem, it can be done on top.
Another thing to do is to make irqchip_in_kernel check mode != NONE.
Paolo
Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
On Tue, Jan 10, 2017 at 02:27:16AM +0100, Rafael J. Wysocki wrote:
> Well, if the https://patchwork.kernel.org/patch/9504277/ patch from Lv
> worked, the attached one should work too (please test), but it can be
> justified in a slightly more convincing way.
No workie:
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 57fb5f4..acb6118 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -378,7 +378,11 @@ static void acpi_os_drop_map_ref(struct acpi_ioremap *map)
static void acpi_os_map_cleanup(struct acpi_ioremap *map)
{
if (!map->refcount) {
- synchronize_rcu_expedited();
+ if (acpi_os_initialized) {
+ pr_err("%s: acpi_os_initialized\n", __func__);
+ synchronize_rcu_expedited();
+ }
+
acpi_unmap(map->phys, map->virt);
kfree(map);
}
The pr_err() gets issued before the box hangs.
Lv's version which set the bool in acpi_os_map_generic_address() did
work though.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v2 5/6] KVM: x86: prevent setup of invalid routes
On 10/01/2017 06:26, Peter Xu wrote: > On Fri, Dec 16, 2016 at 04:10:05PM +0100, Radim Krčmář wrote: >> The check in kvm_set_pic_irq() and kvm_set_ioapic_irq() was just a >> temporary measure until the code improved enough for us to do this. >> >> This changes APIC in a case when KVM_SET_GSI_ROUTING is called to set up pic >> and ioapic routes before KVM_CREATE_IRQCHIP. Those rules would get >> overwritten >> by KVM_CREATE_IRQCHIP at best, so it is pointless to allow it. Userspaces >> hopefully noticed that things don't work if they do that and don't do that. >> >> Reviewed-by: Paolo Bonzini >> Signed-off-by: Radim Krčmář > > Since we are at here, do we need to protect KVM_SET_GSI_ROUTING in > general as well to make sure kernel APIC is there? Skipping the check is harmless. I agree that it should have been always done like you suggest, but right now it may break something. Paolo > > -8<- > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 482612b..31141a7 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -3057,6 +3057,10 @@ static long kvm_vm_ioctl(struct file *filp, > struct kvm_irq_routing_entry *entries = NULL; > > r = -EFAULT; > + > + if (!irqchip_in_kernel(kvm)) > + goto out; > + > if (copy_from_user(&routing, argp, sizeof(routing))) > goto out; > r = -EINVAL; > > ->8- > > Thanks, > > -- peterx >
Re: [PATCH] staging: most: hdm-usb: Fix sparse warning cast to restricted __le16
On Mon, 9 Jan 2017 21:25:56 -0600
Eric Salem wrote:
> Fixed the following sparse warning:
>
> drivers/staging/most/hdm-usb/hdm_usb.c:158:16: warning:
> cast to restricted __le16
>
> by correcting the variable's type (also updated sizeof).
>
> Signed-off-by: Eric Salem
Acked-by: Christian Gromm
> ---
> drivers/staging/most/hdm-usb/hdm_usb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/most/hdm-usb/hdm_usb.c
> b/drivers/staging/most/hdm-usb/hdm_usb.c
> index d6db0bd..01e3a31 100644
> --- a/drivers/staging/most/hdm-usb/hdm_usb.c
> +++ b/drivers/staging/most/hdm-usb/hdm_usb.c
> @@ -145,7 +145,7 @@ static void wq_netinfo(struct work_struct *wq_obj);
> static inline int drci_rd_reg(struct usb_device *dev, u16 reg, u16 *buf)
> {
> int retval;
> - u16 *dma_buf = kzalloc(sizeof(u16), GFP_KERNEL);
> + __le16 *dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
> u8 req_type = USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE;
>
> if (!dma_buf)
> @@ -154,7 +154,7 @@ static inline int drci_rd_reg(struct usb_device *dev, u16
> reg, u16 *buf)
> retval = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
>DRCI_READ_REQ, req_type,
>0x,
> - reg, dma_buf, sizeof(u16), 5 * HZ);
> + reg, dma_buf, sizeof(*dma_buf), 5 * HZ);
> *buf = le16_to_cpu(*dma_buf);
> kfree(dma_buf);
>
Re: [PATCH v2 4/4] fs/pstore: fs/squashfs: Change usage of LZ4 to comply with new LZ4 module version
Hi Kees,
On 01/07/2017 10:33 PM, Kees Cook wrote:
>On Sat, Jan 7, 2017 at 8:55 AM, Sven Schmidt
><4ssch...@informatik.uni-hamburg.de> wrote:
>> This patch updates fs/pstore and fs/squashfs to use the updated functions
>> from
>> the new LZ4 module.
>>
>> Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
>> ---
>> fs/pstore/platform.c | 14 --
>> fs/squashfs/lz4_wrapper.c | 12 ++--
>> 2 files changed, 14 insertions(+), 12 deletions(-)
>>
>> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
>> index 729677e..a0d8ca8 100644
>> --- a/fs/pstore/platform.c
>> +++ b/fs/pstore/platform.c
>> @@ -342,31 +342,33 @@ static int compress_lz4(const void *in, void *out,
>> size_t inlen, size_t outlen)
>> {
>> int ret;
>>
>> - ret = lz4_compress(in, inlen, out, &outlen, workspace);
>> + ret = LZ4_compress_default(in, out, inlen, outlen, workspace);
>> if (ret) {
>> + // ret is 0 means an error occured
>
>If that's true, then shouldn't the "if" logic be changed? Also, here
>and in all following comments are C++ style instead of kernel C-style.
>This should be "/* ret == 0 means an error occured */", though really,
>that should be obvious from the code and the comment isn't really
>needed.
indeed, it should. I fixed that one.
>> pr_err("lz4_compress error, ret = %d!\n", ret);
>If it's always going to be zero here, is there a better place to get
>details on why it failed?
It is always going to be zero. Honestly, after looking at the current LZ4 in
kernel again
I don't get why there actually was a need to print the return value since
lz4_compress
will (as far as I see) always return -1 in case of an error while the new
lz4_compress_fast/default
will return 0 in such case. Maybe I should just stick with the error?
Thanks,
Sven
Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
Hi, Am 10.01.2017 um 08:00 schrieb John Crispin: > On 08/01/2017 14:30, Andreas Färber wrote: >> >> Andreas Färber (4): >> Documentation: devicetree: Add vendor prefix for AsiaRF >> Documentation: devicetree: arm: mediatek: Add Geek Force board >> ARM: dts: mt7623: Add Geek Force config >> MAINTAINERS: Extend ARM/Mediatek SoC support section >> > > Hi, > > i need to NAK this series. the asiarf board is nothing more than the > official MTK EVB with AsiaRF written on it. this board is already > supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the > EVB dts file nstead of adding a duplicate and letting the original bitrot. Well, I disagree. First of all I'm not letting "the original" bitrot, because I have nothing to do with that .dts! If anyone is to blame for letting it bitrot since February 2016, pick your own nose: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/mt7623-evb.dts Second, I have no Mediatek documentation or even picture to identify any similarities between my board and that Mediatek EVB, so no, I can't hack on the -evb.dts file. I wrote my .dts from scratch, not even having access to /proc/device-tree on its 3.10 kernel for comparison. Third, by your argumentation we shouldn't be adding, e.g., Odroid .dts files either because they were based on a Samsung SMDK, or .dts files for Amlogic TV boxes because they're almost identical to reference designs, etc. Users need to know which .dts file to choose, so having a sane .dts filename is warranted. Depending on how similar they are, one could either #include the -evb.dts or factor out a shared .dtsi, but that takes us back to the previous point of hardly anyone having access to EVB information to identify such a subset. Therefore duplicating trivial nodes is the method of choice for all practical purposes - mt7623.dtsi is getting reused just fine. Comparing our two .dts files, mine has two more UART nodes enabled, the U-Boot bootloader's baudrate set to actually get serial output, a different board compatible string for identification, and I chose the new dual-licensing header that is being requested for new DT files. For lack of schematics I figured out UART1 by testing - continuity tests for GND, console=ttySx,115200n8 and trial-and-error for RX/TX. Obviously I can't do that for a board I don't have access to. UART2 and UART0 pins were clear, but only UART2 was obvious from ttyMT2. Do you actually have access to a Geek Force board yourself, or what are you basing your claims on? Mine looks different from the Indiegogo picture and thus has different identification from that on https://wikidevi.com/wiki/AsiaRF_WS2977 (WS3301, MT7623N RFB_V10). If you confirm the EVB's baudrate I can happily send that part your way. I've seen 921600 on the Helio X20 96board for instance. Also, none of what you've said justifies NAK'ing patch 4/4, which applies to any mt7* and arm64 .dts, including yours. While we're at it, I noticed that mainline has a "mediatek,mt7623-eth" network driver but no corresponding .dtsi node. Talk about bitrot... Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH v5 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
On 2017-01-10 10:29, Alexandre Belloni wrote:
> Hi,
>
> This needs a commit message, please add one.
There's not all that much to say, but ok, I'll add something.
> On 10/01/2017 at 09:08:51 +0100, Peter Rosin wrote :
>> Acked-by: Rob Herring
>> Signed-off-by: Peter Rosin
>> ---
>> Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
>> MAINTAINERS | 8 +
>> arch/arm/boot/dts/Makefile| 1 +
>> arch/arm/boot/dts/at91-linea.dtsi | 53 +
>> arch/arm/boot/dts/at91-tse850-3.dts | 274
>> ++
>> 5 files changed, 355 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
>> create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
>> create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
>>
>> diff --git a/Documentation/devicetree/bindings/arm/axentia.txt
>> b/Documentation/devicetree/bindings/arm/axentia.txt
>> new file mode 100644
>> index ..ea3fb96ae465
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/axentia.txt
>> @@ -0,0 +1,19 @@
>> +Device tree bindings for Axentia ARM devices
>> +
>> +
>> +Linea CPU module
>> +
>> +
>> +Required root node properties:
>> +compatible = "axentia,linea",
>> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
>> +and following the rules from atmel-at91.txt for a sama5d31 SoC.
>> +
>> +
>> +TSE-850 v3 board
>> +
>> +
>> +Required root node properties:
>> +compatible = "axentia,tse850v3", "axentia,linea",
>> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
>> +and following the rules from above for the axentia,linea CPU module.
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 97b78cc5aa51..5c2ea6e9cd7f 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2346,6 +2346,14 @@ S:Maintained
>> F: Documentation/devicetree/bindings/sound/axentia,*
>> F: sound/soc/atmel/tse850-pcm5142.c
>>
>> +AXENTIA ARM DEVICES
>> +M: Peter Rosin
>> +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>> +S: Maintained
>> +F: Documentation/devicetree/bindings/arm/axentia.txt
>> +F: arch/arm/boot/dts/at91-linea.dtsi
>> +F: arch/arm/boot/dts/at91-tse850-3.dts
>> +
>
> I don't think you need to add yourself to MAINTAINERS for two DTs if
> that is just to keep checkpatch happy, don't bother.
There's also the benefit of the increased chances of me getting
notified of changes. I don't mind...
>> AZ6007 DVB DRIVERV
>> M: Mauro Carvalho Chehab
>> M: Mauro Carvalho Chehab
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 9a7375c388a8..7632849866de 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
>> at91-kizbox2.dtb \
>> at91-sama5d2_xplained.dtb \
>> at91-sama5d3_xplained.dtb \
>> +at91-tse850-3.dtb \
>> sama5d31ek.dtb \
>> sama5d33ek.dtb \
>> sama5d34ek.dtb \
>> diff --git a/arch/arm/boot/dts/at91-linea.dtsi
>> b/arch/arm/boot/dts/at91-linea.dtsi
>> new file mode 100644
>> index ..646feb0daa81
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/at91-linea.dtsi
>> @@ -0,0 +1,53 @@
>> +/*
>> + * at91-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
>> + *
>> + * Copyright (C) 2017 Axentia Technologies AB
>> + *
>> + * Author: Peter Rosin
>> + *
>> + * Licensed under GPLv2 or later.
>> + */
>> +
>> +#include "sama5d31.dtsi"
>> +
>> +/ {
>> +compatible = "axentia,linea",
>> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
>> +
>> +memory {
>> +reg = <0x2000 0x400>;
>> +};
>> +};
>> +
>> +&slow_xtal {
>> +clock-frequency = <32768>;
>> +};
>> +
>> +&main_xtal {
>> +clock-frequency = <1200>;
>> +};
>> +
>> +&main {
>> +clock-frequency = <1200>;
>> +};
>> +
>
> I don't think this is needed
>
>
"this"? The &main frequency, or all of them?
Cheers,
peda
Re: [PATCH net-next v2] net: dsa: make "label" property optional for dsa2
Mon, Jan 09, 2017 at 07:06:39PM CET, f.faine...@gmail.com wrote:
>On 01/09/2017 09:58 AM, Jiri Pirko wrote:
>> Mon, Jan 09, 2017 at 06:42:07PM CET, f.faine...@gmail.com wrote:
>>> On 01/09/2017 08:06 AM, Jiri Pirko wrote:
Mon, Jan 09, 2017 at 04:45:33PM CET, vivien.dide...@savoirfairelinux.com
wrote:
> Hi Jiri,
>
> Jiri Pirko writes:
>
>>> Extra question: shouldn't phys_port_{id,name} be switchdev attributes in
>>
>> Again, phys_port_id has nothing to do with switches. Should be removed
>> from dsa because its use there is incorrect.
>
> Florian, since 3a543ef just got in, can it be reverted?
Yes, please revert it. It is only in net-next.
>>>
>>> Maybe the use case can be understood before reverting the change. How do
>>> we actually the physical port number of an Ethernet switch per-port
>>> network device? The name is not enough, because there are plenty of
>>> cases where we need to manipulate a physical port number (be it just for
>>> informational purposes).
>>
>> Like what?
>
>Specifying the physical port number (and derive a queue number
>eventually) for some ethtool (e.g: rxnfc)/tc (queue mapping) operations
>where there is an action/queue/port destination argument that gets
>programmed into the hardware.
Could you point me to a real example? User command?
>
>You already have the originating port number from the interface you call
>the method against, but you also need the destination port number since
>that is what the HW understands.
This is internal to kernel? I fail to understand what you mean exactly.
>
>Aside from that, it is useful for allowing interface naming in user
>space if you don't want to use labels.
>
>>
>> Why the name is not enough? This is something propagated to userspace
>> and never used internally in kernel.
>
>Because the name is not reflective of the port number in some switches.
>In my case for instance, we have 5 ports that are named after the
>entities they connect to (an integrated Gigabit PHY, two RGMII pads, one
>MoCA interface, and the CPU)
>
Again, I'm missing why you need a portnumber as a Integer to userspace.
>From driver, you can expose phys_port_name:
>0 -> gphy
"p0" or "gphy"
>1 -> rgmii_1
"p1" or "rgmii_1"
>2 -> rgmii_2
...
>7 -> moca
>8 -> cpu
>
>>
>> Btw, ndo_get_phys_port_id does not give you number, but arbitrary binary.
>
>It's not entirely arbitrary for DSA switches since the port number is
>stored in an u8 whose value is the port number in hexadecimal (as shown
>by sysfs at least).
In mlxsw, we also have port number stored in u8. It is used to
communicate with hw of course. But outside the driver, this is exposed
as phys_port_name "pX".
Re: [PATCH v2 1/4] lib: Update LZ4 compressor module based on LZ4 v1.7.2.
On Tue, Jan 10, 2017 at 10:32:17AM +0100, Sven Schmidt wrote: > On 01/08/2017 12:23 PM, Greg KH wrote: > > And follow the proper kernel coding style rules, putting your patches > > through scripts/checkpatch.pl should help you out here. > > Sorry, I didn't know about that particular script. I already put > Patches 2, 3 and 4 through checkpatch.pl; patch 1 is a little more to > rework but I will, of course, do that. You do know about Documentation/SubmittingPatches, right? If not, take a look at that as well :) thanks, greg k-h
Re: [PATCH v2 1/4] lib: Update LZ4 compressor module based on LZ4 v1.7.2.
On Tue, Jan 10, 2017 at 10:21:16AM +0100, Sven Schmidt wrote: > On 01/08/2017 12:25 PM, Greg KH wrote: > >On Sat, Jan 07, 2017 at 05:55:42PM +0100, Sven Schmidt wrote: > >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet. > >> The kernel module is inspired by the previous work by Chanho Min. > >> The updated LZ4 module will not break existing code since there were alias > >> methods added to ensure backwards compatibility. > > > > Meta-comment. Does this update include all of the security fixes that > > we have made over the past few years to the lz4 code? I don't want to > > be adding back insecure functions that will cause us problems. > > > > Specifically look at the changes I made in 2014 in this directory for an > > example of what I am talking about here. > > > > Hi Greg, > > it doesn't. I didn't have that in mind until now. Ick, those changes never got made "upstream"? Not good, but makes sense as we couldn't really find an "upstream" when we made them :( As you took this code from somewhere, you might want to also push your changes for these issues there as well, so that others don't run into them in the future. thanks, greg k-h
Re: linux-next: manual merge of the y2038 tree with the net-next tree
Hmm, I thought I had removed that commit when you asked me about it
last week. I've done it now, the conflict should be gone tomorrow.
On Tue, Jan 10, 2017 at 3:52 AM, Stephen Rothwell wrote:
> Hi Arnd,
>
> Today's linux-next merge of the y2038 tree got a conflict in:
>
> fs/afs/main.c
>
> between commit:
>
> 8e8d7f13b6d5 ("afs: Add some tracepoints")
>
> from the net-next tree and commit:
>
> 549eb7b22e24 ("AFS: Correctly use 64-bit time for UUID")
>
> from the y2038 tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc fs/afs/main.c
> index f8188feb03ad,129ff432391c..
> --- a/fs/afs/main.c
> +++ b/fs/afs/main.c
> @@@ -14,8 -14,7 +14,9 @@@
> #include
> #include
> #include
> +#include
> +#define CREATE_TRACE_POINTS
> + #include
> #include "internal.h"
>
> MODULE_DESCRIPTION("AFS Client File System");
Re: [PATCH] tpm_tis: Check return values from get_burstcount.
On Mon, Jan 09, 2017 at 11:46:58PM +0200, Jarkko Sakkinen wrote:
> From: Josh Zimmerman
>
> If the TPM we're connecting to uses a static burst count, it will report
> a burst count of zero throughout the response read. However, get_burstcount
> assumes that a response of zero indicates that the TPM is not ready to
> receive more data. In this case, it returns a negative error code, which
> is passed on to tpm_tis_{write,read}_bytes as a u16, causing
> them to read/write far too many bytes.
>
> This patch checks for negative return codes and bails out from recv_data
> and tpm_tis_send_data.
>
> Cc: sta...@vger.kernel.org
> Fixes: 1107d065fdf1 (tpm_tis: Introduce intermediate layer for TPM access)
> Signed-off-by: Josh Zimmerman
> Reviewed-by: Jarkko Sakkinen
> Signed-off-by: Jarkko Sakkinen
> ---
> Backport for 4.8 and 4.9
4.8 is now end-of-life, but I've queued this up for 4.9-stable, many
thanks!
greg k-h
Re: [PATCH v4 1/9] clk: stm32f4: Update DT bindings documentation
On 01/09/2017 08:33 PM, Stephen Boyd wrote: On 01/09, Alexandre Torgue wrote: Hi Stephen, On 12/22/2016 01:10 AM, Stephen Boyd wrote: On 12/13, gabriel.fernan...@st.com wrote: From: Gabriel Fernandez Creation of dt include file for specific stm32f4 clocks. These specific clocks are not derived from system clock (SYSCLOCK) We should use index 1 to use these clocks in DT. e.g. <&rcc 1 CLK_LSI> Signed-off-by: Gabriel Fernandez Acked-by: Rob Herring --- Applied to clk-stm32f4 and merged into clk-next. I'm preparing pull request branch for STM32 DT part. This patch is also requested to build correctly DT patches. Do you know how could we synchronize our pull request ? clk-stm32f4 is stable and not going to be rebased, so you're good to base patches on it and send it off to arm-soc if the arm-soc maintainers agree to it. You can also base off an earlier part of the branch if you only need this first patch for example. I will base my DT branch from 4.10-rc1 + this commit (seen with Arnd) Thanks
Re: [PATCH 3/4] x86/unwind: include __schedule() in stack traces
On Mon, 9 Jan 2017, Josh Poimboeuf wrote:
> In the following commit:
>
> 0100301bfdf5 ("sched/x86: Rewrite the switch_to() code")
>
> ... the layout of the 'inactive_task_frame' struct was designed to have
> a frame pointer header embedded in it, so that the unwinder could use
> the 'bp' and 'ret_addr' fields to report __schedule() on the stack (or
> ret_from_fork() for newly forked tasks which haven't actually run yet).
>
> Finish the job by changing get_frame_pointer() to return a pointer to
> inactive_task_frame's 'bp' field rather than 'bp' itself. This allows
> the unwinder to start one frame higher on the stack, so that it properly
> reports __schedule().
>
> Reported-by: Miroslav Benes
You can also add my
Tested-by: Miroslav Benes
One ignorant question below.
> Signed-off-by: Josh Poimboeuf
> ---
> arch/x86/include/asm/stacktrace.h | 5 +
> arch/x86/include/asm/switch_to.h | 10 +-
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/include/asm/stacktrace.h
> b/arch/x86/include/asm/stacktrace.h
> index 20ce3db..2e41c50 100644
> --- a/arch/x86/include/asm/stacktrace.h
> +++ b/arch/x86/include/asm/stacktrace.h
> @@ -52,16 +52,13 @@ static inline bool on_stack(struct stack_info *info, void
> *addr, size_t len)
> static inline unsigned long *
> get_frame_pointer(struct task_struct *task, struct pt_regs *regs)
> {
> - struct inactive_task_frame *frame;
> -
> if (regs)
> return (unsigned long *)regs->bp;
>
> if (task == current)
> return __builtin_frame_address(0);
>
> - frame = (struct inactive_task_frame *)task->thread.sp;
> - return (unsigned long *)READ_ONCE_NOCHECK(frame->bp);
> + return &((struct inactive_task_frame *)task->thread.sp)->bp;
You effectively remove one of the changes from the previous patch -
READ_ONCE_NOCHECK. Is it intentional?
Regards,
Miroslav
Re: [PATCH 3/4] ARM: dts: stm32: stm32f7: Enable clocks for STM32F746 boards
Hi Gabriel
On 01/06/2017 02:59 PM, gabriel.fernan...@st.com wrote:
From: Gabriel Fernandez
This patch enables clocks for STM32F746 boards.
Signed-off-by: Gabriel Fernandez
---
In commit header, "stm32f7" is not usefull.
arch/arm/boot/dts/stm32f746.dtsi | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index f321ffe..e05e131 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -43,6 +43,7 @@
#include "skeleton.dtsi"
#include "armv7-m.dtsi"
#include
+#include
This patch depends on another series not yet merged (maybe "[PATCH-next
... is a better header ?
/ {
clocks {
@@ -51,6 +52,24 @@
compatible = "fixed-clock";
clock-frequency = <0>;
};
+
+ clk-lse {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ };
+
+ clk-lsi {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32000>;
+ };
+
+ clk_i2s_ckin: clk-i2s-ckin {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <4800>;
+ };
};
soc {
@@ -178,6 +197,11 @@
interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>,
<42>, <62>, <76>;
};
+ pwrcfg: power-config@40007000 {
+ compatible = "syscon";
+ reg = <0x40007000 0x400>;
+ };
+
pin-controller {
#address-cells = <1>;
#size-cells = <1>;
@@ -291,9 +315,10 @@
rcc: rcc@40023800 {
#clock-cells = <2>;
- compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
+ compatible = "st,stm32f746-rcc", "st,stm32-rcc";
reg = <0x40023800 0x400>;
- clocks = <&clk_hse>;
+ clocks = <&clk_hse>, <&clk_i2s_ckin>;
+ st,syscfg = <&pwrcfg>;
};
};
};
Re: [PATCHv14 2/3] usb: USB Type-C connector class
On Fri, 2017-01-06 at 12:54 +0200, Heikki Krogerus wrote: > Hi guys, > > On Thu, Jan 05, 2017 at 05:54:02PM +0200, Mika Westerberg wrote: > > I wonder if "source sink" instead is better? Along the lines of > > /sys/power/state. > > > > Then you can print "[source] sink" when source is selected and so on. > > That is more or less how I originally proposed how we list the roles > in general. I introduced the separate "current_*_role" and > "supported_*_roles" attribute files because somebody wanted them. I > don't remember the reason why they were preferred to be in separate > attribute files. Neither do I. > > Oliver! Guenter! Do we really need to list the current and supported > roles in separate attribute files? Can't we just have the "power_role" > and "data_role" attribute files for the ports instead of the separate > "supported_*_roles" and "current_*_role", and show the current role > like Mika proposes? I definitely would prefer it that way because it > is similar style used in other places like Mike pointed out. Either way would serve. > And since we are talking about the ABI, can we also change the listing > of the accessory mode back to just "audio" and "debug" like I > originally had it? I don't remember who and why wanted it to be > changed to "Audio Adapter Accessory Mode" and "Debug Accessory Mode", > but it differs from the style we list the other details. Yes, but can we differentiate analog and digital audio? Regards Oliver
Re: [PATCH] perf: protect group_leader from races that cause ctx
* Kees Cook wrote: > > [...] > > Reported-by: Kees Cook > > I was just relaying a fix. I noted the original reporter in the first > patch, how they asked to be credited: > > Reported-by: Di Shen (@returnsme) of KeenLab (@keen_lab), Tencent So while it's OK to not give an email address (unlike Signed-off-by the Reported-by line is giving credit and has no code authorship legal effect), I agree with Peter that this line is pretty weird, bordering on the ugly. If the reporter doesn't want the email address exposed we can just skip the tag and credit the reporter in the changelog: Di Shen reported that ... Thanks, Ingo
Re: [PATCH 4.9 000/116] 4.9.2-stable review
On Mon, Jan 09, 2017 at 10:19:31AM -0800, Kevin Hilman wrote: > Greg Kroah-Hartman writes: > > > On Fri, Jan 06, 2017 at 09:42:24PM -0800, kernelci.org bot wrote: > >> stable-rc boot: 513 boots: 4 failed, 489 passed with 20 offline > >> (v4.9.1-117-ge3bc65e52a08) > >> > >> Full Boot Summary: > >> https://kernelci.org/boot/all/job/stable-rc/kernel/v4.9.1-117-ge3bc65e52a08/ > >> Full Build Summary: > >> https://kernelci.org/build/stable-rc/kernel/v4.9.1-117-ge3bc65e52a08/ > >> > >> Tree: stable-rc > >> Branch: local/linux-4.9.y > >> Git Describe: v4.9.1-117-ge3bc65e52a08 > >> Git Commit: e3bc65e52a086ea9bcc31605737bbf0476f9bcd3 > >> Git URL: > >> http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > >> Tested: 88 unique boards, 25 SoC families, 35 builds out of 206 > >> > >> Boot Regressions Detected: > >> > >> arm: > >> > >> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: > >> vexpress-v2p-ca15_a7: > >> lab-broonie: new failure (last pass: v4.9.1) > >> > >> Boot Failures Detected: > >> > >> arm: > >> > >> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y > >> vexpress-v2p-ca15_a7: 1 failed lab > >> > >> sunxi_defconfig > >> sun4i-a10-cubieboard: 1 failed lab > >> > >> exynos_defconfig > >> exynos5422-odroidxu3_rootfs:nfs: 1 failed lab > >> > >> arm64: > >> > >> defconfig+CONFIG_CPU_BIG_ENDIAN=y > >> juno-r2: 1 failed lab > > > > Are all of these really "failures"? Some of them seem like they really > > did boot, but the test system didn't detect it? > > > > I don't know what to do with these reports, should I trust them that I > > broke something, or just ignore them and let someone else dig into them > > to determine if it's a false-positive or something like that? > > Until we get these more reliable, you can assume that I'll flag > something that's really a blocker. Ok, thanks for that, it makes my life easier in trying to parse these reports :) greg k-h
Re: [PATCH] drm/exynos: constify exynos_drm_crtc_ops structures
On Mon, Jan 09, 2017 at 11:24:53PM +0530, Bhumika Goyal wrote:
> Declare exynos_drm_crtc_ops structures as const as they are only passed
> as an argument to the function exynos_drm_crtc_create. This argument is
> of type const struct exynos_drm_crtc_ops *, so exynos_drm_crtc_ops
> structures having this property can be declared const.
> Done using Coccinelle:
>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct exynos_drm_crtc_ops i@p={...};
>
> @ok@
> position p;
> identifier r.i;
> @@
> exynos_drm_crtc_create(...,&i@p,...)
>
> @bad@
> position p!={r.p,ok.p};
> identifier r.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> +const
> struct exynos_drm_crtc_ops i;
>
> File size before:
>text data bss dec hex filename
>5008 280 0528814a8 exynos/exynos5433_drm_decon.o
>
> File size after:
>text data bss dec hex filename
>5120 176 0529614b0 exynos/exynos5433_drm_decon.o
>
> Signed-off-by: Bhumika Goyal
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 6ca1f31..12b9bf0 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -470,7 +470,7 @@ static void decon_clear_channels(struct exynos_drm_crtc
> *crtc)
> clk_disable_unprepare(ctx->clks[i]);
> }
>
> -static struct exynos_drm_crtc_ops decon_crtc_ops = {
> +static const struct exynos_drm_crtc_ops decon_crtc_ops = {
> .enable = decon_enable,
> .disable= decon_disable,
> .enable_vblank = decon_enable_vblank,
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
(resend, hit the wrong reply button) On 10/01/2017 10:48, Andreas Färber wrote: > Hi, > > Am 10.01.2017 um 08:00 schrieb John Crispin: >> On 08/01/2017 14:30, Andreas Färber wrote: >>> >>> Andreas Färber (4): >>> Documentation: devicetree: Add vendor prefix for AsiaRF >>> Documentation: devicetree: arm: mediatek: Add Geek Force board >>> ARM: dts: mt7623: Add Geek Force config >>> MAINTAINERS: Extend ARM/Mediatek SoC support section >>> >> >> Hi, >> >> i need to NAK this series. the asiarf board is nothing more than the >> official MTK EVB with AsiaRF written on it. this board is already >> supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the >> EVB dts file nstead of adding a duplicate and letting the original bitrot. > > Well, I disagree. reading the rest of the email you seem to be quite agro about this. > > First of all I'm not letting "the original" bitrot, because I have > nothing to do with that .dts! If anyone is to blame for letting it > bitrot since February 2016, pick your own nose: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/mt7623-evb.dts what should i pick my nose about ? i made mt7623 work, then waited for 4.10-rc1 to be out for clk-mt2701 so that i can continue adding the missing support > Second, I have no Mediatek documentation or even picture to identify any > similarities between my board and that Mediatek EVB, so no, I can't hack > on the -evb.dts file. I wrote my .dts from scratch, not even having > access to /proc/device-tree on its 3.10 kernel for comparison. ok, that info is most likely under NDA > > Third, by your argumentation we shouldn't be adding, e.g., Odroid .dts > files either because they were based on a Samsung SMDK, or .dts files > for Amlogic TV boxes because they're almost identical to reference > designs, etc. > Users need to know which .dts file to choose, so having a sane .dts > filename is warranted. Depending on how similar they are, one could > either #include the -evb.dts or factor out a shared .dtsi, but that > takes us back to the previous point of hardly anyone having access to > EVB information to identify such a subset. Therefore duplicating trivial > nodes is the method of choice for all practical purposes - mt7623.dtsi > is getting reused just fine. > in that case add a dtsi file for the EVB and include it in your geek board.dts and only update the compat string. > Comparing our two .dts files, mine has two more UART nodes enabled, the > U-Boot bootloader's baudrate set to actually get serial output, a > different board compatible string for identification, and I chose the > new dual-licensing header that is being requested for new DT files. 1) at the time we adde this the uart support was not ready 2) the bootloader i am using is a custom built one hence the random baudrate 3) you can just updae the license if you want to, no problem > For lack of schematics I figured out UART1 by testing - continuity tests > for GND, console=ttySx,115200n8 and trial-and-error for RX/TX. Obviously > I can't do that for a board I don't have access to. > UART2 and UART0 pins were clear, but only UART2 was obvious from ttyMT2. you do have the EVB directly in front of you > Do you actually have access to a Geek Force board yourself, or what are > you basing your claims on? Mine looks different from the Indiegogo > picture and thus has different identification from that on > https://wikidevi.com/wiki/AsiaRF_WS2977 (WS3301, MT7623N RFB_V10). i dont need the geek board as i have the EVB and they are identical according to MTK > If you confirm the EVB's baudrate I can happily send that part your way. > I've seen 921600 on the Helio X20 96board for instance. see above > Also, none of what you've said justifies NAK'ing patch 4/4, which > applies to any mt7* and arm64 .dts, including yours. agreed, i never even mentioned 4/4 > While we're at it, I noticed that mainline has a "mediatek,mt7623-eth" > network driver but no corresponding .dtsi node. Talk about bitrot... the idea is that we work together to make thins optimal. this is not a you or is right. this is about the FOSS peer review process. please dont be so agro. to me it seems suboptimal to support 2 dts files for the same board. John > > Regards, > Andreas >
Re: [PATCH 4/4] dt-bindings: mfd: Add STM32F7 RCC numeric constants into DT include file
Hi Gabriel
On 01/06/2017 02:59 PM, gabriel.fernan...@st.com wrote:
From: Gabriel Fernandez
This patch lists STM32F7's RCC numeric constants.
It will be used by clock and reset drivers, and DT bindings.
Signed-off-by: Gabriel Fernandez
can you please split this commit ? (one part for binding and another for DT)
Thanks in advance
Alex
---
arch/arm/boot/dts/stm32f746.dtsi | 51
include/dt-bindings/mfd/stm32f7-rcc.h | 112 ++
2 files changed, 138 insertions(+), 25 deletions(-)
create mode 100644 include/dt-bindings/mfd/stm32f7-rcc.h
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index e05e131..09d6649 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -44,6 +44,7 @@
#include "armv7-m.dtsi"
#include
#include
+#include
/ {
clocks {
@@ -77,7 +78,7 @@
compatible = "st,stm32-timer";
reg = <0x4000 0x400>;
interrupts = <28>;
- clocks = <&rcc 0 128>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM2)>;
status = "disabled";
};
@@ -85,7 +86,7 @@
compatible = "st,stm32-timer";
reg = <0x4400 0x400>;
interrupts = <29>;
- clocks = <&rcc 0 129>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM3)>;
status = "disabled";
};
@@ -93,7 +94,7 @@
compatible = "st,stm32-timer";
reg = <0x4800 0x400>;
interrupts = <30>;
- clocks = <&rcc 0 130>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM4)>;
status = "disabled";
};
@@ -101,14 +102,14 @@
compatible = "st,stm32-timer";
reg = <0x4c00 0x400>;
interrupts = <50>;
- clocks = <&rcc 0 131>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM5)>;
};
timer6: timer@40001000 {
compatible = "st,stm32-timer";
reg = <0x40001000 0x400>;
interrupts = <54>;
- clocks = <&rcc 0 132>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM6)>;
status = "disabled";
};
@@ -116,7 +117,7 @@
compatible = "st,stm32-timer";
reg = <0x40001400 0x400>;
interrupts = <55>;
- clocks = <&rcc 0 133>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM7)>;
status = "disabled";
};
@@ -124,7 +125,7 @@
compatible = "st,stm32f7-usart", "st,stm32f7-uart";
reg = <0x40004400 0x400>;
interrupts = <38>;
- clocks = <&rcc 0 145>;
+ clocks = <&rcc 1 CLK_USART2>;
status = "disabled";
};
@@ -132,7 +133,7 @@
compatible = "st,stm32f7-usart", "st,stm32f7-uart";
reg = <0x40004800 0x400>;
interrupts = <39>;
- clocks = <&rcc 0 146>;
+ clocks = <&rcc 1 CLK_USART3>;
status = "disabled";
};
@@ -140,7 +141,7 @@
compatible = "st,stm32f7-uart";
reg = <0x40004c00 0x400>;
interrupts = <52>;
- clocks = <&rcc 0 147>;
+ clocks = <&rcc 1 CLK_UART4>;
status = "disabled";
};
@@ -148,7 +149,7 @@
compatible = "st,stm32f7-uart";
reg = <0x40005000 0x400>;
interrupts = <53>;
- clocks = <&rcc 0 148>;
+ clocks = <&rcc 1 CLK_UART5>;
status = "disabled";
};
@@ -156,7 +157,7 @@
compatible = "st,stm32f7-usart", "st,stm32f7-uart";
reg = <0x40007800 0x400>;
interrupts = <82>;
- clocks = <&rcc 0 158>;
+ clocks = <&rcc 1 CLK_UART7>;
status = "disabled";
};
@@ -164,7 +165,7 @@
compatible = "st,stm32f7-usart", "st,stm32f7-uart";
reg = <0x40007c00 0x400>;
interrupts = <83>;
- clocks = <&rcc 0 159>;
+ clocks = <&rcc 1 CLK_UART8>;
[PATCH 1/2] tools: perf: fix linker error when libelf config is disabled
When libelf is disabled in the configuration, we get the following
linker error:
LINK libperf-jvmti.so
ld: cannot find -lelf
Makefile.perf:515: recipe for target 'libperf-jvmti.so' failed
Jiri pointed out that both librt and libelf are not really required. So
this patch fixes the linker error by getting rid of unwanted libraries
in the linker stage.
Fixes: 209045adc2bb ("perf tools: add JVMTI agent library")
Acked-by: Jiri Olsa
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Stephane Eranian
Signed-off-by: Sudeep Holla
---
tools/perf/Makefile.perf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 8fc24824705e..9e4a7ea84637 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -512,7 +512,7 @@ $(LIBJVMTI_IN): FORCE
$(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=jvmti obj=jvmti
$(OUTPUT)$(LIBJVMTI): $(LIBJVMTI_IN)
- $(QUIET_LINK)$(CC) -shared -Wl,-soname -Wl,$(LIBJVMTI) -o $@ $< -lelf
-lrt
+ $(QUIET_LINK)$(CC) -shared -Wl,-soname -Wl,$(LIBJVMTI) -o $@ $<
endif
$(patsubst perf-%,%.o,$(PROGRAMS)): $(wildcard */*.h)
--
2.7.4
