Re: linux-next: build warnings after merge of the crypto tree
Am Dienstag, 26. August 2014, 14:38:12 schrieb Herbert Xu:
Hi Herbert,
>On Tue, Aug 26, 2014 at 04:14:56PM +1000, Stephen Rothwell wrote:
>> Hi Herbert,
>>
>> After merging the crypto tree, today's linux-next build (powerpc
>> ppc44x_defconfig, i386 defconfig and sparc defconfig) produced these
>> warnings:
>>
>> In file included from crypto/testmgr.c:30:0:
>> include/crypto/drbg.h: In function 'drbg_max_addtl':
>> include/crypto/drbg.h:157:2: warning: left shift count >= width of
>> type>
>> return (1UL<<35);
>> ^
>>
>> include/crypto/drbg.h: In function 'drbg_max_requests':
>> include/crypto/drbg.h:163:2: warning: left shift count >= width of
>> type>
>> return (1UL<<48);
>> ^
>>
>> Introduced by commit 05c81ccd9087 ("crypto: drbg - remove
>> configuration of fixed values"). These are all 32 bit builds.
>
>Stephan, could you take a look at this?
I am on it. Thanks.
>
>Thanks,
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation, v4
On Mon, Aug 25, 2014 at 02:08:43PM +0400, Cyrill Gorcunov wrote: > During development of c/r we've noticed that in case if we need to > support user namespaces we face a problem with capabilities in > prctl(PR_SET_MM, ...) call, in particular once new user namespace > is created capable(CAP_SYS_RESOURCE) no longer passes. Hi guys, here is a small nit in this patch (missing linux/types.h inclusion in prctl.h) as Stephen reported by linux-next build results. I've fixed it in local quilt queue but defer sending to not flood lkml until there will be no more concerns on the main code of the patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] spi: spi-imx: add DMA support
On Mon, Aug 25, 2014 at 10:07:22AM +0200, Marek Vasut wrote: > On Saturday, August 23, 2014 at 02:13:55 AM, Robin Gong wrote: > > After enable DMA > > Please also add a commit message which describes the change, not only some > test > results. > > [...] > Ok, I will enrich it in next version. > > @@ -911,6 +1194,13 @@ static int spi_imx_probe(struct platform_device > > *pdev) goto out_put_per; > > > > spi_imx->spi_clk = clk_get_rate(spi_imx->clk_per); > > + /* > > +* Only validated on i.mx6 now, can remove the constrain if validated on > > +* other chips. > > +*/ > > Given that the check below tests for imx51_ecspi_devtype_data ... does that > mean, that this code was never tested on MX51 and MX53, yet will be enabled > for those chips and might possibly break them ? > Yes, because there is no available mx51 mx53 boards in my hands. But I think it won't bring too much trouble, since they share the same IP. No, the patch won't break current MX51 and MX53, because they didn't enable dma in dts setting,and they will keep use pio mode. > > + if (spi_imx->devtype_data == &imx51_ecspi_devtype_data > > + && spi_imx_sdma_init(&pdev->dev, spi_imx, master, res)) > > + dev_err(&pdev->dev, "dma setup error,use pio instead\n"); > > > > spi_imx->devtype_data->reset(spi_imx); > > > > @@ -949,6 +1239,7 @@ static int spi_imx_remove(struct platform_device > > *pdev) writel(0, spi_imx->base + MXC_CSPICTRL); > > clk_unprepare(spi_imx->clk_ipg); > > clk_unprepare(spi_imx->clk_per); > > + spi_imx_sdma_exit(spi_imx); > > spi_master_put(master); > > > > return 0; > > Best regards, > Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: stmmac: fix warning from Sparse for socfpga
Warning:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:41:
sparse: cast removes address space of expression
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:38:
sparse: incorrect type in assignment (different address spaces)
Signed-off-by: Ley Foon Tan
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index cd613d7..c1addce 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -119,7 +119,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
*dwmac, struct device *
return -EINVAL;
}
- dwmac->splitter_base = (void *)devm_ioremap_resource(dev,
+ dwmac->splitter_base =
+ (void __iomem *)devm_ioremap_resource(dev,
&res_splitter);
if (!dwmac->splitter_base) {
dev_info(dev, "Failed to mapping emac splitter\n");
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/8] ARM: tegra: Add SATA controller to Tegra124 device tree
On 25/08/14 20:23, Stephen Warren wrote: On 07/16/2014 02:54 AM, Mikko Perttunen wrote: This adds the integrated AHCI-compliant Serial ATA controller present in Tegra124 systems-on-chip to the Tegra124 device tree. I have applied patches 2 and 3 to Tegra's for-3.18/dt branch. I fixed the DT node sort order when doing so. Thanks :) I can't apply patch 8 (the defconfig change) until 3.17-rc2 is out, or there will be a build failure, but I will do so ASAP. BTW, once 3.17-rc2 is out, can you please sent a patch to multi_v7_defconfig enabling Tegra SATA support there too. Thanks. Will do. Cheers, Mikko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 1/2] regulator: Add driver for max77802 PMIC PMIC regulators
On Mon, Aug 25, 2014 at 08:40:40AM -0700, Doug Anderson wrote: > On Mon, Aug 25, 2014 at 2:07 AM, Javier Martinez Canillas > > I see, so probably until we have a way to define the operating mode for > > each regulator using DT we should set the opmode to normal when enabling a > > regulator independently of the value the hardware register reported on > > probe. > > Can you please test the following change [0] so I can post as a proper > > patch? Doug, Mark do you think that forcing the regulator to opmode normal > > when enabling is the right solution here? > IMHO that makes sense. No, this doesn't make any obvious sense to me at all. Picking normal as a default if the hardware reads back off due to overlapping impelementation or something *might* make sense but not overwriting the hardware state without explicit permission from the machine integration is a key goal for the regulator API. signature.asc Description: Digital signature
About the reboot hang issue with EHCI driver on the Baytrail platform
Hi, I found that in the Baytrail-m platform if the "USB3.0 Configuration in Pre-OS" is set to Auto in the BIOS, the system will boot with EHCI-enabled. And test reboot 200 times. It sometimes hang in the shutdown process "ehci-pci :00:1d.0: shutdown." I also found that sometimes hang in the booting up process. But it still black screen, I can't see clearly where it hang. After doing some experiments, I found the following symptoms: 1) Set the "USB3.0 Configuration in Pre-OS" to enable, the 200 times reboot test can pass. Under the condition, lspci can't see the EHCI [8086:0f34] controller. 2) Build a new kernel without the EHCI driver can also pass the 200 times reboot test. 3) Put "echo -n ":00:1d.0" > /sys/bus/pci/drivers/ehci-pci/unbind" in the /etc/rc.local can avoid shutdown hang but sometimes it also hang in the booting up process during the 200 times reboot test. 4) I also found some messages in dmesg which show "ehci-pci :00:1d.0: port 1 reset error -110." If there is any possibility to disable the EHCI controller in the Baytrail platform because the XHCI covers all the ports connected to EHCI controller. And IIRC, there is only one host controller within EHCI and XHCI can be enabled in the Baytrail platform. I'm also trying to find out the kernel parameters to disable the EHCI driver, but currently there is no available one. Thanks, Gavin [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.17.0-999-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201408250205 SMP Mon Aug 25 06:06:48 UTC 2014 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.17.0-999-generic root=UUID=91e3866d-90aa-4bc1-a329-f13d85d58861 ro "dyndbg=module ehci_hcd +flmpt ; module ehci-pci +flmpt" [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x200f] reserved [0.00] BIOS-e820: [mem 0x2010-0x78ac5fff] usable [0.00] BIOS-e820: [mem 0x78ac6000-0x79245fff] reserved [0.00] BIOS-e820: [mem 0x79246000-0x79345fff] ACPI NVS [0.00] BIOS-e820: [mem 0x79346000-0x79385fff] ACPI data [0.00] BIOS-e820: [mem 0x79386000-0x79ff] usable [0.00] BIOS-e820: [mem 0x7a00-0x7a7f] reserved [0.00] BIOS-e820: [mem 0x7ae0-0x7fff] reserved [0.00] BIOS-e820: [mem 0xe000-0xe3ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved [0.00] BIOS-e820: [mem 0xfed03000-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved [0.00] BIOS-e820: [mem 0xfed0c000-0xfed0] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1cfff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xfef0-0xfeff] reserved [0.00] BIOS-e820: [mem 0xffb8-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00017fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: xxx-xxx xx xx Notebook PC/, BIOS B.41 07/23/2014 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x18 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0FFC0 mask FFFC0 write-protect [0.00] 1 base 0FFB8 mask 8 uncachable [0.00] 2 base 0 mask F8000 write-back [0.00] 3 base 07C00 mask FFC00 uncachable [0.00] 4 base 07B00 mask FFF00 uncachable [0.00] 5 base 07AE0 mask FFFE0 uncachable [0.00] 6 base 1 mask F8000 write-back [0.00] 7 di
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 08/25/2014 09:16 PM, Eliezer Tamir wrote: > On 22/08/2014 17:16, Eric Dumazet wrote: >> > On Fri, 2014-08-22 at 17:08 +0800, Jason Wang wrote: >> > >>> >> But this is just for current process. We want to determine whether or >>> >> not it was worth to loop busily in current process by checking if >>> >> there's any another runnable processes or callbacks. And what we need >>> >> here is just a simple and lockless hint which can't be wrong but may be >>> >> inaccurate to exit the busy loop. The net code does not depends on this >>> >> hint to do scheduling or yielding. >>> >> >>> >> How about just introducing a boolean helper like current_can_busy_loop() >>> >> and return true in one of the following conditions: >>> >> >>> >> - Current task is SCHED_FIFO >>> >> - Current task is neither SCHED_FIFO nor SCHED_IDLE and no other >>> >> runnable processes or pending RCU callbacks in current cpu >>> >> >>> >> And add warns to make sure it can only be called in process context. >> > >> > >> > 1) Any reasons Eliezer Tamir is not included in the CC list ? > Thanks for remembering me, Eric ;) > > Here are my 2 cents: > I think Ingo's suggestion of only yielding to tasks with same or higher > priority makes sense. I'm not sure I get your meaning. Do you mean calling yield_to() directly in sk_busy_loop? Schedule() which will be called later should handle all cases such as priority and rt process. And this patch just want the schedule() to do this decision earlier by exiting the busy loop earlier. This will improve the latency in both heavy load and light load. Checking number of nsecs this task is expected to run in the future sounds like the work that sk_busy_loop_end_time() should consider. It was not the issue that this patch want to address. > > IF you change the current behavior, please update the documentation. > You are going to make people scratch their head and ask "what changed?" > you owe them a clue. Thanks for the reminding. But for this patch itself, it does not change user noticeable behaviour. > I also would like to have some way to keep track of when/if/how much > this yield happens. > Ok, not very hard to add, maybe just another statistics counter. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the akpm tree
Hi Andrew,
After merging the akpm tree, today's linux-next build (sparc64
defconfig) failed like this:
kernel/built-in.o: In function `proc_dowatchdog':
(.text+0x6a620): undefined reference to
`watchdog_hardlockup_detector_is_enabled'
kernel/built-in.o: In function `proc_dowatchdog':
(.text+0x6a6a8): undefined reference to `watchdog_enable_hardlockup_detector'
kernel/built-in.o: In function `proc_dowatchdog':
(.text+0x6a79c): undefined reference to `watchdog_enable_hardlockup_detector'
Caused by commit 72355eed4bd7 ("kernel/watchdog.c: control hard lockup
detection default"). This build has CONFIG_HAVE_NMI_WATCHDOG=y,
CONFIG_HARDLOCKUP_DETECTOR not set.
I have reverted that commit (and commits
"watchdog-control-hard-lockup-detection-default-fix" and "kvm: ensure
hard lockup detection is disabled by default" that follow it) for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
linux-next: build warnings after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
defconfig) produced these warnings:
In file included from /scratch/sfr/next/include/asm-generic/bug.h:13:0,
from /scratch/sfr/next/arch/arm/include/asm/bug.h:61,
from /scratch/sfr/next/include/linux/bug.h:4,
from /scratch/sfr/next/include/linux/thread_info.h:11,
from /scratch/sfr/next/include/asm-generic/preempt.h:4,
from arch/arm/include/generated/asm/preempt.h:1,
from /scratch/sfr/next/include/linux/preempt.h:18,
from /scratch/sfr/next/include/linux/spinlock.h:50,
from /scratch/sfr/next/include/linux/mmzone.h:7,
from /scratch/sfr/next/include/linux/gfp.h:5,
from /scratch/sfr/next/include/linux/slab.h:14,
from /scratch/sfr/next/mm/nobootmem.c:13:
/scratch/sfr/next/mm/nobootmem.c: In function 'free_low_memory_core_early':
/scratch/sfr/next/include/linux/kernel.h:29:20: warning: large integer
implicitly truncated to unsigned type [-Woverflow]
#define ULLONG_MAX (~0ULL)
^
/scratch/sfr/next/mm/nobootmem.c:122:28: note: in expansion of macro
'ULLONG_MAX'
memblock_clear_hotplug(0, ULLONG_MAX);
^
Introduced by commit 6e162b4c49f7 ("mem-hotplug: let memblock skip the
hotpluggable memory regions in __next_mem_range()"). The second
argument to memblock_clear_hotplug() is a phys_addr_t, which varies in
size between architectures/platforms.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCHv4 0/4] pwm: imx: support output polarity inversion
Hi, Lothar Waßmann wrote: > This patch series adds support for polarity inversion to the pwm-imx > driver. The patches have been tested on i.MX6, i.MX53 and with the > ti-ehrpwm.c driver. > > Changes wrt. v2: > - make the use of '#pwm-cells = <3>' optional, so that the change does > not break existing DT blobs as suggested by Arnd Bergmann and Sascha > Hauer. > > Changes wrt. v3: > - implemented the approach suggested by Sascha Hauer > - don't modify struct pwm_ops in the imx_pwm probe function > > Any further comments? Anyone taking care of these patches? Lothar Waßmann -- ___ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | i...@karo-electronics.de ___ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: fix warning from Sparse for socfpga
On 8/26/2014 9:11 AM, Ley Foon Tan wrote:
Warning:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:41:
sparse: cast removes address space of expression
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:38:
sparse: incorrect type in assignment (different address spaces)
Signed-off-by: Ley Foon Tan
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index cd613d7..c1addce 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -119,7 +119,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
*dwmac, struct device *
return -EINVAL;
}
- dwmac->splitter_base = (void *)devm_ioremap_resource(dev,
+ dwmac->splitter_base =
+ (void __iomem *)devm_ioremap_resource(dev,
I think, no casting should be done:
dwmac->splitter_base = devm_ioremap_resource(dev,
patch should be for net-next
peppe
&res_splitter);
if (!dwmac->splitter_base) {
dev_info(dev, "Failed to mapping emac splitter\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: input: force generic axis to be mapped to their user space axis
On Mon, 25 Aug 2014, Benjamin Tissoires wrote: > Atmel 840B digitizer presents a stylus interface which reports twice > the X coordinate and then twice the Y coordinate. In its current > implementation, hid-input assign the first X to X, then the second to Y, > then the first Y to Z, then the second one to RX. > > This is wrong, and X should always be mapped to X, no matter what. > A solution consists in forcing X, Y, Z, RX, RY, RZ to be mapped to their > correct user space counter part. > > Reported-by: Éric Brunet > Signed-off-by: Benjamin Tissoires Applied, thanks. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On Mon, 25 Aug 2014, Bjorn Andersson wrote: > Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, > 8960 and 8064 based devices. The binding currently describes the rpm > itself and the regulator subnodes. > > Signed-off-by: Bjorn Andersson > --- > Documentation/devicetree/bindings/mfd/qcom,rpm.txt | 246 > > include/dt-bindings/mfd/qcom,rpm.h | 154 > 2 files changed, 400 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/qcom,rpm.txt > create mode 100644 include/dt-bindings/mfd/qcom,rpm.h Please use the same filename formatting as the existing files. [...] -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] ARM: debug: uncompress debug support for omap2plus
From: Sahara Since OMAP low-level debug code places data in the .data section, The symbol DEBUG_UNCOMPRESS was defined with !DEBUG_OMAP2PLUS_UART. This patch removes the part using data section in debug/omap2plus.S, so DEBUG_UNCOMPRESS is now available on OMAP system. Signed-off-by: Sahara Tested-by: Afzal Mohammed (on am335x beagle bone white) --- arch/arm/Kconfig.debug |3 +- arch/arm/include/debug/omap2plus.S | 96 ++-- 2 files changed, 27 insertions(+), 72 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index b11ad54..c0ad3e4 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -1220,8 +1220,7 @@ config DEBUG_UART_8250_FLOW_CONTROL config DEBUG_UNCOMPRESS bool depends on ARCH_MULTIPLATFORM || ARCH_MSM || PLAT_SAMSUNG - default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \ -(!DEBUG_TEGRA_UART || !ZBOOT_ROM) + default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT_ROM) help This option influences the normal decompressor output for multiplatform kernels. Normally, multiplatform kernels disable diff --git a/arch/arm/include/debug/omap2plus.S b/arch/arm/include/debug/omap2plus.S index 6d867ae..0b7ec89 100644 --- a/arch/arm/include/debug/omap2plus.S +++ b/arch/arm/include/debug/omap2plus.S @@ -58,115 +58,71 @@ #define UART_OFFSET(addr) ((addr) & 0x00ff) - .pushsection .data -omap_uart_phys:.word 0 -omap_uart_virt:.word 0 -omap_uart_lsr: .word 0 - .popsection - .macro addruart, rp, rv, tmp - /* Use omap_uart_phys/virt if already configured */ -10:adr \rp, 99f@ get effective addr of 99f - ldr \rv, [\rp] @ get absolute addr of 99f - sub \rv, \rv, \rp @ offset between the two - ldr \rp, [\rp, #4] @ abs addr of omap_uart_phys - sub \tmp, \rp, \rv @ make it effective - ldr \rp, [\tmp, #0] @ omap_uart_phys - ldr \rv, [\tmp, #4] @ omap_uart_virt - cmp \rp, #0 @ is port configured? - cmpne \rv, #0 - bne 100f@ already configured - /* Configure the UART offset from the phys/virt base */ -#ifdef CONFIG_DEBUG_OMAP2UART1 +#if defined(CONFIG_DEBUG_OMAP2UART1) mov \rp, #UART_OFFSET(OMAP2_UART1_BASE) @ omap2/3/4 b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP2UART2 +#elif defined(CONFIG_DEBUG_OMAP2UART2) mov \rp, #UART_OFFSET(OMAP2_UART2_BASE) @ omap2/3/4 b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP2UART3 +#elif defined(CONFIG_DEBUG_OMAP2UART3) mov \rp, #UART_OFFSET(OMAP2_UART3_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP3UART3 +#elif defined(CONFIG_DEBUG_OMAP3UART3) mov \rp, #UART_OFFSET(OMAP3_UART1_BASE) add \rp, \rp, #0x00fb add \rp, \rp, #0x6000 @ OMAP3_UART3_BASE b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP4UART3 +#elif defined(CONFIG_DEBUG_OMAP4UART3) mov \rp, #UART_OFFSET(OMAP4_UART3_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP3UART4 +#elif defined(CONFIG_DEBUG_OMAP3UART4) mov \rp, #UART_OFFSET(OMAP3_UART1_BASE) add \rp, \rp, #0x00fb add \rp, \rp, #0x00028000 @ OMAP3_UART4_BASE b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP4UART4 +#elif defined(CONFIG_DEBUG_OMAP4UART4) mov \rp, #UART_OFFSET(OMAP4_UART4_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_TI81XXUART1 +#elif defined(CONFIG_DEBUG_TI81XXUART1) mov \rp, #UART_OFFSET(TI81XX_UART1_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_TI81XXUART2 +#elif defined(CONFIG_DEBUG_TI81XXUART2) mov \rp, #UART_OFFSET(TI81XX_UART2_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_TI81XXUART3 +#elif defined(CONFIG_DEBUG_TI81XXUART3) mov \rp, #UART_OFFSET(TI81XX_UART3_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_AM33XXUART1 +#elif defined(CONFIG_DEBUG_AM33XXUART1) ldr \rp, =AM33XX_UART1_BASE and \rp, \rp, #0x00ff b 97f -#endif -#ifdef CONFIG_DEBUG_ZOOM_UART +#elif defined(CONFIG_DEBUG_ZOOM_UART) ldr \rp, =ZOOM_UART_BASE - str \rp, [\tmp, #0] @ omap_uart_phys - ldr \rp, =ZOOM_UART_VIRT - str \rp, [\tmp, #4] @ omap_uart_virt - mov \rp, #(UART_LSR << ZOOM_PORT_SHIFT) -
Re: [PATCH v2 4/9] pinctrl: tegra-xusb: Add USB PHY support
On 25/08/14 22:22, Stephen Warren wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
In addition to the PCIe and SATA PHYs, the XUSB pad controller also
supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single
PCIe or SATA lane and is mapped to one of the three UTMI ports.
The xHCI controller will also send messages intended for the PHY driver,
so request and listen for messages on the mailbox's PHY channel.
I'd like a review from Thierry here as the HW expert.
I need an ack from LinusW in order to take this pinctrl patch through
the Tegra tree.
diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c
b/drivers/pinctrl/pinctrl-tegra-xusb.c
+static int usb3_phy_power_on(struct phy *phy)
+{
+struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy);
+int port = usb3_phy_to_port(phy);
+int lane = padctl->usb3_ports[port].lane;
+u32 value, offset;
+
+if (!is_pcie_or_sata_lane(lane)) {
+dev_err(padctl->dev, "USB3 PHY %d mapped to invalid lane: %d\n",
+port, lane);
+return -EINVAL;
+}
An aside: This implies that the SATA driver should be talking to this
pinctrl driver and explicitly powering on the XUSB pins. However, the
SATA driver doesn't depend on this series. I'm a bit confused how that
works. Perhaps it's just by accident? Mikko, can you comment?
The SATA driver does depend on the pinctrl-tegra-xusb driver to power on
the SATA lane. It looks like what this patch does is it adds support for
using the SATA pad for USB3, in which case the SATA lane also needs to
be powered on. At least that's the understanding I got from a quick read.
Mikko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: rockchip: rk3288: Switch to use the proper PWM IP
On Mon, Aug 25, 2014 at 04:40:57PM -0700, Doug Anderson wrote: [...] > I was doing some thinking about what to do, then. I wondered whether > the right thing to do is not to make a "rk3288 syscon" driver that > configures these bits, but rather to make a "rk3288" driver has access > to the syscon. It could live in drivers/soc/rockchip/rk3288.c and we > could give it a handle to the syscon. It could do the one-time > initialization. It would also be a place to put special rk3288 APIs > in cases where other drivers need similar things. > > What do you think? Yes, that could work. There have been recent discussions about adding such machine drivers that match on the top-level compatible string in the DT. I still think that subclassing syscon would be the cleanest solution, though. Thierry pgpQ7y9nrcbMN.pgp Description: PGP signature
[RFC] mm: show deferred_compaction state in page alloc fail
Recently, I saw several reports that high order allocation failed
although there were many freeable pages but it's hard to reproduce
so asking them to reproduce the problem several time is really painful.
A culprit I doubt is compaction deferring logic which prevent
compaction for a while so high order allocation could be fail.
It would be more clear if we can see the stat which can show
current zone's compaction deferred state when allocatil fail.
It's a RFC and never test it. I just get an idea with
handling another strange high order allocation fail.
Any comments are welcome.
Cc: Vlastimil Babka
Cc: Mel Gorman
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Rik van Riel
Signed-off-by: Minchan Kim
---
arch/arm/mm/init.c | 4 ++--
arch/ia64/mm/init.c | 4 ++--
arch/metag/mm/init.c| 2 +-
arch/parisc/mm/init.c | 4 ++--
arch/powerpc/xmon/xmon.c| 2 +-
arch/sparc/kernel/setup_32.c| 2 +-
arch/sparc/mm/init_32.c | 4 ++--
arch/tile/mm/pgtable.c | 2 +-
arch/unicore32/mm/init.c| 4 ++--
drivers/net/ethernet/sgi/ioc3-eth.c | 2 +-
drivers/tty/serial/68328serial.c| 2 +-
drivers/tty/sysrq.c | 2 +-
drivers/tty/vt/keyboard.c | 2 +-
include/linux/compaction.h | 25 ++---
include/linux/mm.h | 4 ++--
lib/show_mem.c | 4 ++--
mm/nommu.c | 6 +++---
mm/oom_kill.c | 2 +-
mm/page_alloc.c | 10 ++
mm/vmscan.c | 2 +-
20 files changed, 55 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 659c75d808dc..2b5544072f2a 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -90,14 +90,14 @@ __tagtable(ATAG_INITRD2, parse_tag_initrd2);
* initialization functions, as well as show_mem() for the skipping
* of holes in the memory map. It is populated by arm_add_memory().
*/
-void show_mem(unsigned int filter)
+void show_mem(unsigned int filter, int order)
{
int free = 0, total = 0, reserved = 0;
int shared = 0, cached = 0, slab = 0;
struct memblock_region *reg;
printk("Mem-info:\n");
- show_free_areas(filter);
+ show_free_areas(filter, order);
for_each_memblock (memory, reg) {
unsigned int pfn1, pfn2;
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index 6b3345758d3e..c1e73e826032 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -723,14 +723,14 @@ __initcall(per_linux32_init);
* Shows a simple page count of reserved and used pages in the system.
* For discontig machines, it does this on a per-pgdat basis.
*/
-void show_mem(unsigned int filter)
+void show_mem(unsigned int filte, int order)
{
int total_reserved = 0;
unsigned long total_present = 0;
pg_data_t *pgdat;
printk(KERN_INFO "Mem-info:\n");
- show_free_areas(filter);
+ show_free_areas(filter, order);
printk(KERN_INFO "Node memory in pages:\n");
for_each_online_pgdat(pgdat) {
unsigned long present;
diff --git a/arch/metag/mm/init.c b/arch/metag/mm/init.c
index 11fa51c89617..7cab8983a1f5 100644
--- a/arch/metag/mm/init.c
+++ b/arch/metag/mm/init.c
@@ -390,7 +390,7 @@ void __init mem_init(void)
free_all_bootmem();
mem_init_print_info(NULL);
- show_mem(0);
+ show_mem(0, 0);
}
void free_initmem(void)
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 0bef864264c0..2ed6f37aeb20 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -643,13 +643,13 @@ void __init mem_init(void)
unsigned long *empty_zero_page __read_mostly;
EXPORT_SYMBOL(empty_zero_page);
-void show_mem(unsigned int filter)
+void show_mem(unsigned int filter, int order)
{
int total = 0,reserved = 0;
pg_data_t *pgdat;
printk(KERN_INFO "Mem-info:\n");
- show_free_areas(filter);
+ show_free_areas(filter, order);
for_each_online_pgdat(pgdat) {
unsigned long flags;
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index b988b5addf86..411dc0c8ab1f 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -843,7 +843,7 @@ cmds(struct pt_regs *excp)
memzcan();
break;
case 'i':
- show_mem(0);
+ show_mem(0, 0);
break;
default:
termch = cmd;
diff --git a/arch/sparc/kernel/setup_32.c b/arch/sparc/kernel/setup_32.c
index baef495c06bd..7fbcd331179f 100644
--- a/arch/sparc/kernel/setup_32.c
+++ b/arch/sparc/kernel/setup_32.c
@@ -84,7 +84,7 @@ static void prom_sync_me(void)
Re: [PATCH v5 4/5] Regulator: RK808: modify for struct rk808 change
On Mon, Aug 25, 2014 at 09:37:06PM +0800, Chris Zhong wrote: > The "dev" has been deleted from "struct rk808" in rk808 mfd driver > so rk808->dev should be replaced by &client->dev here. Applied, thanks. signature.asc Description: Digital signature
[PATCH] DRBG: fix bit shifting on 32 bit systems
Use ULL to mark a 64 bit value.
Reported-by: Stephen Rothwell
Reported-by: kbuild test robot
Signed-off-by: Stephan Mueller
---
include/crypto/drbg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index 3d8e73a..dd52aee 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -154,13 +154,13 @@ static inline size_t drbg_max_request_bytes(struct
drbg_state *drbg)
static inline size_t drbg_max_addtl(struct drbg_state *drbg)
{
/* SP800-90A requires 2**35 bytes additional info str / pers str */
- return (1UL<<35);
+ return (1ULL<<35);
}
static inline size_t drbg_max_requests(struct drbg_state *drbg)
{
/* SP800-90A requires 2**48 maximum requests before reseeding */
- return (1UL<<48);
+ return (1ULL<<48);
}
/*
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] DRBG: fix sparse warning for cpu_to_be[32|64]
The sparse tool complained that the cpu_to_be[32|64] functions return
__be[32|64] instead of __u32 or __u64. The patch replaces the __u32 and
__u64 with __be32 and __be64.
Reported-by: kbuild test robot
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 9fd239f..39ed918 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -277,7 +277,7 @@ static bool drbg_fips_continuous_test(struct drbg_state
*drbg,
static inline void drbg_cpu_to_be32(__u32 val, unsigned char *buf)
{
struct s {
- __u32 conv;
+ __be32 conv;
};
struct s *conversion = (struct s *) buf;
@@ -989,7 +989,7 @@ static int drbg_hash_generate(struct drbg_state *drbg,
int ret = 0;
union {
unsigned char req[8];
- __u64 req_int;
+ __be64 req_int;
} u;
unsigned char prefix = DRBG_PREFIX3;
struct drbg_string data1, data2;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DRBG: fix bit shifting on 32 bit systems
On Tue, Aug 26, 2014 at 09:31:02AM +0200, Stephan Mueller wrote: > Use ULL to mark a 64 bit value. > > Reported-by: Stephen Rothwell > Reported-by: kbuild test robot > Signed-off-by: Stephan Mueller I don't think this works as size_t is still 32-bit which means that you'll return zero. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DRBG: fix sparse warning for cpu_to_be[32|64]
On Tue, Aug 26, 2014 at 09:32:24AM +0200, Stephan Mueller wrote: > The sparse tool complained that the cpu_to_be[32|64] functions return > __be[32|64] instead of __u32 or __u64. The patch replaces the __u32 and > __u64 with __be32 and __be64. > > Reported-by: kbuild test robot > Signed-off-by: Stephan Mueller Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] drivers/base: Fix length checks in create_syslog_header()/dev_vprintk_emit()
snprintf() returns the number of bytes that could have been written (excluding the null), not the actual number of bytes written. Given a long enough subsystem or device name, these functions will advance beyond the end of the on-stack buffer in dev_vprintk_exit(), resulting in an information leak or stack corruption. I don't know whether such a long name is currently possible. In case snprintf() returns a value >= the buffer size, do not add structured logging information. Also WARN if this happens, so we can fix the driver or increase the buffer size. Signed-off-by: Ben Hutchings --- v2: use dev_WARN() not dev_WARN_ON() v3: the version that actually compiles drivers/base/core.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index 20da3ad..28b808c 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -2007,6 +2007,8 @@ create_syslog_header(const struct device *dev, char *hdr, size_t hdrlen) return 0; pos += snprintf(hdr + pos, hdrlen - pos, "SUBSYSTEM=%s", subsys); + if (pos >= hdrlen) + goto overflow; /* * Add device identifier DEVICE=: @@ -2038,7 +2040,14 @@ create_syslog_header(const struct device *dev, char *hdr, size_t hdrlen) "DEVICE=+%s:%s", subsys, dev_name(dev)); } + if (pos >= hdrlen) + goto overflow; + return pos; + +overflow: + dev_WARN(dev, "device/subsystem name too long"); + return 0; } int dev_vprintk_emit(int level, const struct device *dev, -- Ben Hutchings No political challenge can be met by shopping. - George Monbiot signature.asc Description: This is a digitally signed message part
linux-next: Tree for Aug 26
Hi all, Changes since 20140825: The net tree gained a build failure for which I reverted a commit. The mfd tree still had its build failure so I used the version from next-20140822. The trivial tree gained a conflict against Linus' tree. The staging tree still had its build failure for which I applied a fix patch. The rd-docs tree gained a conflict against the trivial tree. The akpm-current tree gained a build failure for which I reverted 2 commits. The akpm tree gained a build failure for which I reverted 3 commits. Non-merge commits (relative to Linus' tree): 1973 2042 files changed, 55360 insertions(+), 34839 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 220 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (52addcf9d666 Linux 3.17-rc2) Merging fixes/master (23cf8d3ca0fd powerpc: Fix "attempt to move .org backwards" error) Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1) Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4) Merging arm-current/fixes (e57e41931134 ARM: wire up memfd_create syscall) Merging m68k-current/for-linus (9117710a5997 m68k/sun3: Remove define statement no longer needed) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of flash_block_list in rtas_flash) Merging sparc/master (451fd72219dd Merge tag 'pwm/for-3.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm) Merging net/master (e24f8191cc35 xen-netback: move netif_napi_add before binding interrupt) [master d06679aa3754] Revert "mvneta: Fix TSO and checksum for non-acceleration vlan traffic" Merging ipsec/master (21009686662f net: phy: smsc: move smsc_phy_config_init reset part in a soft_reset function) Merging sound-current/for-linus (94a988a8ab91 ALSA: pcm: Fix the silence data for DSD formats) Merging pci-current/for-linus (8d7004a6904c PCI: spear: Remove module option) Merging wireless/master (c66517165610 rtlwifi: rtl8192cu: Add new ID) Merging driver-core.current/driver-core-linus (7d1311b93e58 Linux 3.17-rc1) Merging tty.current/tty-linus (7d1311b93e58 Linux 3.17-rc1) Merging usb.current/usb-linus (9b2667f1f30e usb: dwc2: gadget: Set the default EP max packet value as 8 bytes) Merging usb-gadget-fixes/fixes (5d19703822da usb: gadget: remove $(PWD) in ccflags-y) Merging usb-serial-fixes/usb-linus (646907f5bfb0 USB: ftdi_sio: Added PID for new ekey device) Merging staging.current/staging-linus (a2fa6721c723 staging: r8188eu: Add new USB ID) Merging char-misc.current/char-misc-linus (8e8248b1369c mei: nfc: fix memory leak in error path) Merging input-current/for-linus (fb92be7ba8ca Input: sparc - i8042-sparcio.h: fix unused kbd_res warning) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (ce5481d01f67 crypto: drbg - fix failure of generating multiple of 2**16 bytes) Merging ide/master (a53dae49b2fe ide: use module_platform_driver()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (5a12a597a862 arm: Add devicetree fixup machine function) Merging rr-fixes/fixes (ff7e0055bb5d module: Clean up ro/nx after early module load failures) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' o
Re: [PATCH] DRBG: fix bit shifting on 32 bit systems
Am Dienstag, 26. August 2014, 15:32:19 schrieb Herbert Xu: Hi Herbert, > On Tue, Aug 26, 2014 at 09:31:02AM +0200, Stephan Mueller wrote: > > Use ULL to mark a 64 bit value. > > > > Reported-by: Stephen Rothwell > > Reported-by: kbuild test robot > > Signed-off-by: Stephan Mueller > > I don't think this works as size_t is still 32-bit which means > that you'll return zero. Oops, yes. Thank you for catching this. I guess I need __u64 for this value. A patch will come shortly. > > Cheers, -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/4] zram: zram memory size limitation
On Mon, Aug 25, 2014 at 09:05:55AM +0900, Minchan Kim wrote:
> @@ -513,6 +540,14 @@ static int zram_bvec_write(struct zram *zram, struct
> bio_vec *bvec, u32 index,
> ret = -ENOMEM;
> goto out;
> }
> +
> + if (zram->limit_pages &&
> + zs_get_total_pages(meta->mem_pool) > zram->limit_pages) {
> + zs_free(meta->mem_pool, handle);
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO);
Hello,
I don't follow up previous discussion, so I could be wrong.
Why this enforcement should be here?
I think that this has two problems.
1) alloc/free happens unnecessarilly if we have used memory over the
limitation.
2) Even if this request doesn't do new allocation, it could be failed
due to other's allocation. There is time gap between allocation and
free, so legimate user who want to use preallocated zsmalloc memory
could also see this condition true and then he will be failed.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 4/4] pwm: imx: support output polarity inversion
On Wed, Aug 20, 2014 at 08:55:56AM +0200, Lothar Waßmann wrote: > The i.MX pwm unit on i.MX27 and newer SoCs provides a configurable > output polarity. This patch adds support to utilize this feature where > available. > > Signed-off-by: Lothar Waßmann Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] kexec: minor fixups and enhancements
On 08/25/14 at 12:59pm, Vivek Goyal wrote: > On Fri, Aug 22, 2014 at 06:39:47PM +, Geoff Levand wrote: > > Hi, > > > > Here are a few minor fixups and enhancements for kexec support. > > > > Patch 3 and 4 that add preprocessor macros for the kimage list flags are > > ones that I use in the arm64 kexec support I am working on, so it would > > be nice for those to go in. > > > > Please consider. > > Hi Geoff, > > Does arm64 has secureboot? If yes, then it might make sense to > enable the new syscall kexec_file_load() on arm64 instead of trying > to make old syscall work first. It will save efforts for efi support as well, for the in-kernel loader we do not necessary to save the efi physical addresses or runtime ranges to sysfs and passing them to 2nd kernel, we can just copy them in kernel. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] spi: spi-imx: add DMA support
On Tuesday, August 26, 2014 at 09:17:59 AM, Robin Gong wrote: > On Mon, Aug 25, 2014 at 10:07:22AM +0200, Marek Vasut wrote: > > On Saturday, August 23, 2014 at 02:13:55 AM, Robin Gong wrote: > > > After enable DMA > > > > Please also add a commit message which describes the change, not only > > some test results. > > > > [...] > > Ok, I will enrich it in next version. > > > > @@ -911,6 +1194,13 @@ static int spi_imx_probe(struct platform_device > > > *pdev) goto out_put_per; > > > > > > spi_imx->spi_clk = clk_get_rate(spi_imx->clk_per); > > > > > > + /* > > > + * Only validated on i.mx6 now, can remove the constrain if validated > > > on + * other chips. > > > + */ > > > > Given that the check below tests for imx51_ecspi_devtype_data ... does > > that mean, that this code was never tested on MX51 and MX53, yet will be > > enabled for those chips and might possibly break them ? > > Yes, because there is no available mx51 mx53 boards in my hands. But I > think it won't bring too much trouble, since they share the same IP. > No, the patch won't break current MX51 and MX53, because they didn't enable > dma in dts setting,and they will keep use pio mode. Thanks for clearing this up, this was the important piece of information for me. Please put it into the commit message. Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] Tegra124 EMC (external memory controller) support
On 25/08/14 20:40, Stephen Warren wrote: On 07/11/2014 08:18 AM, Mikko Perttunen wrote: Hi everyone, this series adds support for the EMC (external memory controller) clock in the Tegra124 system-on-chip. The series has been tested on Jetson TK1. The first two patches remove the old "emc_mux" and "emc" clocks from the clock tree and the device tree bindings. This is, of course, not backwards compatible, but as these clocks have never been useful for anything (apart from maybe reading the boot rate of the EMC clock). If this is still not acceptable, the second patch can be dropped. ... Mikko, this series had some comments, especially on the DT binding (patch 5/8) and how the MC/EMC drivers interact. Is there an updated version of the series? Or, is the series replaced by Tomeu Vizoso's work? Yes, I have a v2 with these comments addressed. One concern, though, is the part writing to CLK_SOURCE_EMC. If some other driver also wants to read this register (MC, likely), we might need to have an API for it in the CAR driver. On the other hand, maybe not, since it's only one register. Thierry? Another point is that v2 adds a new API to the MC driver, which also doesn't exist yet. The EMC driver can technically work without the MC driver (but with a header for MC added), but I'm not sure the result would be very useful. I believe the plan is that Tomeu's EMC code will be integrated into this EMC driver once both are ready. Mikko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/12] mmc: sdhi: Fixup system PM suspend lock-up
On Mon, Aug 25, 2014 at 2:26 PM, Ulf Hansson wrote:
> At system PM suspend, the tmio core accessed the internal registers of
> the controller without first moving the device into active state. This
> caused a lock-up in system PM suspend phase.
>
> The reason for the register access were masking of IRQs. Since that is
> managed via the runtime PM suspend path, let's just re-use that path
> for system PM suspend.
>
> In other words force the device into runtime PM suspend state at system
> PM suspend and restore it to active state at system PM resume.
>
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Ulf Hansson
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 net-next 4/6] bpf: enable bpf syscall on x64 and i386
* Alexei Starovoitov wrote: > On Mon, Aug 25, 2014 at 6:07 PM, David Miller wrote: > > From: Alexei Starovoitov > > Date: Mon, 25 Aug 2014 18:00:56 -0700 > > > >> - > >> +asmlinkage long sys_bpf(int cmd, unsigned long arg2, unsigned long arg3, > >> + unsigned long arg4, unsigned long arg5); > > > > Please do not add interfaces with opaque types as arguments. > > > > It is impossible for the compiler to type check the args at > > compile time when userspace tries to use this stuff. > > I share this concern. I went with single BPF syscall, because > alternative is 6 syscalls for every command and more > syscalls in the future when we'd need to add another command. We had a similar problem growing the perf syscall - and we were able to hold to a single syscall, which I think has served us well. Had we gone with a per functionality syscall we'd have something like a dozen syscalls today, scattered all around non-continuously in the syscall space on most platforms. But note that 'opaque or non-opaque' is a false dichotomy, as there are 3 options in reality: what we used instead of an opaque type was an extensible data type, and extensible C structure, with structure size expectations part of the structure. See 'struct perf_event_attr': SYSCALL_DEFINE5(perf_event_open, struct perf_event_attr __user *, attr_uptr, pid_t, pid, int, cpu, int, group_fd, unsigned long, flags) That way new versions of the data type are immediately obvious to the kernel, and compatibility can be handled well. Smaller, previous versions received from old user-space are padded out transparently to the kernel's value of the structure, with zeroes filled in. See perf_copy_attr() in kernel/events/core.c. Instead of versioning the structure, we use its size as a finegrained and robust version indicator in essence. That way it's both forwards and backwards compatible, as much as possible technically: old kernel can run new user-space, and new user-space will be able to take advantage of as much of an old kernel's capabilities as possible, and in the typical case of version match there's no extra overhead worth speaking of. This way we were able to gradually grow to the sophisticated ABI you can find in include/uapi/linux/perf_event.h, without having to touch the syscall interface. (It's not the only method: we also have a handful of ioctls, where that's the most natural interface for a perf event fd.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
On Tuesday 26 August 2014 08:57:31 Thierry Reding wrote: > On Mon, Aug 25, 2014 at 01:01:52PM -0600, Stephen Warren wrote: > > On 08/18/2014 11:08 AM, Andrew Bresticker wrote: > [...] > > >+static int tegra_xusb_mbox_probe(struct platform_device *pdev) > > > > >+res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > >+if (!res) > > >+return -ENODEV; > > > > Should devm_request_mem_region() be called here to claim the region? > > > > >+mbox->regs = devm_ioremap_nocache(&pdev->dev, res->start, > > >+ resource_size(res)); > > >+if (!mbox->regs) > > >+return -ENOMEM; > > > > Is _nocache required? I don't see other drivers using it. I assume there's > > nothing special about the mbox registers. > > Most drivers should be using devm_ioremap_resource() which will use the > _nocache variant of devm_ioremap() when appropriate. Usually the region > will not be marked cacheable (IORESOURCE_CACHEABLE) and therefore be > remapped uncached. > Note that ioremap() and ioremap_nocache() are the same. We really shouldn't ever call ioremap_nocache(). devm_ioremap_resource() and pci_iomap() checking for IORESOURCE_CACHEABLE is rather silly, since it doesn't call ioremap_cache() in that case. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] spi: spi-imx: add DMA support
On Tue, Aug 26, 2014 at 09:26:40AM +0200, Marek Vasut wrote: > On Tuesday, August 26, 2014 at 09:17:59 AM, Robin Gong wrote: > > On Mon, Aug 25, 2014 at 10:07:22AM +0200, Marek Vasut wrote: > > > On Saturday, August 23, 2014 at 02:13:55 AM, Robin Gong wrote: > > > > After enable DMA > > > > > > Please also add a commit message which describes the change, not only > > > some test results. > > > > > > [...] > > > > Ok, I will enrich it in next version. > > > > > > @@ -911,6 +1194,13 @@ static int spi_imx_probe(struct platform_device > > > > *pdev) goto out_put_per; > > > > > > > > spi_imx->spi_clk = clk_get_rate(spi_imx->clk_per); > > > > > > > > + /* > > > > +* Only validated on i.mx6 now, can remove the constrain if > > > > validated > > > > on + * other chips. > > > > +*/ > > > > > > Given that the check below tests for imx51_ecspi_devtype_data ... does > > > that mean, that this code was never tested on MX51 and MX53, yet will be > > > enabled for those chips and might possibly break them ? > > > > Yes, because there is no available mx51 mx53 boards in my hands. But I > > think it won't bring too much trouble, since they share the same IP. > > No, the patch won't break current MX51 and MX53, because they didn't enable > > dma in dts setting,and they will keep use pio mode. > > Thanks for clearing this up, this was the important piece of information for > me. > Please put it into the commit message. > Okay. Thanks for your reminding. > Best regards, > Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/12] mmc: tmio: Fixup PM support
Hi Ulf,
On Mon, Aug 25, 2014 at 2:25 PM, Ulf Hansson wrote:
> This patchset fixup the PM support for tmio and the tmio hosts.
> Some re-structuring of the code was also necessary to accomplish the above.
>
> A few of these patches has been posted earlier, but at that time I couldn't
> get
> help in testing them on hardware. Let's give this a second try now.
>
> http://www.spinics.net/lists/linux-mmc/msg23177.html
>
> Ulf Hansson (12):
> mmc: tmio: Keep host active while SDIO IRQ is enabled
> mmc: tmio: Keep host active while serving requests
> mmc: tmio: Extract bus_width modifications to a separate function
> mmc: tmio: Restructure ->set_ios() and adapt ->probe() to it
> mmc: tmio: Handle clock gating from runtime PM functions
> mmc: tmio: Mask all IRQs when inactive
> mmc: tmio: Make runtime PM callbacks available for CONFIG_PM
> mmc: sdhi: Make runtime PM callbacks available for CONFIG_PM
> mmc: tmio_mmc: Enable runtime PM support
> mmc: sdhi: Fixup system PM suspend lock-up
> mmc: tmio_mmc: Fixup system PM suspend lock-up
> mmc: tmio: Remove library functions for system PM
I gave this series a test run on r8a7791/Koelsch, everything seems to
work fine.
Even more important, s2ram was fixed by "mmc: sdhi: Fixup system PM
suspend lock-up".
For the whole series:
Acked-by: Geert Uytterhoeven
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] tools lib api: Adopt fdarray class from perf's evlist
Hi Arnaldo,
On Fri, 22 Aug 2014 17:59:50 -0300, Arnaldo Carvalho de Melo wrote:
> +int fdarray__add(struct fdarray *fda, int fd)
> +{
> + /*
> + * XXX: 64 is arbitrary, just not to call realloc at each fd.
> + * Find a better autogrowing heuristic
> + */
> + if (fda->nr == fda->nr_alloc &&
> + fdarray__grow(fda, 64) < 0)
> + return -ENOMEM;
> +
> + fcntl(fd, F_SETFL, O_NONBLOCK);
> + fda->entries[fda->nr].fd = fd;
> + fda->entries[fda->nr].events = POLLIN | POLLERR | POLLHUP;
> + fda->nr++;
> + return 0;
> +}
To be more generic api, I think it'd be better receiving events from
user rather than hard-coding. Also it might be useful to let user
sets a grow hint (during init?) as well.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: fix warning from Sparse for socfpga
On Tue, Aug 26, 2014 at 3:24 PM, Giuseppe CAVALLARO wrote: >> @@ -119,7 +119,8 @@ static int socfpga_dwmac_parse_data(struct >> socfpga_dwmac *dwmac, struct device * >> return -EINVAL; >> } >> >> - dwmac->splitter_base = (void *)devm_ioremap_resource(dev, >> + dwmac->splitter_base = >> + (void __iomem *)devm_ioremap_resource(dev, > > > I think, no casting should be done: > >dwmac->splitter_base = devm_ioremap_resource(dev, Oh ya, since both are same type. Will send new patch. > > patch should be for net-next Do you mean the patch need based on net-next git? I'm using linux-next git now. Thanks. Regards Ley Foon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Resend PATCH V2] X86/CPU: Avoid 100ms sleep for cpu offline during S3
With some bad kernel configures, cpu offline consumes more than 100ms
during S3. This because native_cpu_die() would fall into 100ms
sleep when cpu idle loop thread marked cpu state to DEAD slower. It's
timing related issue. What native_cpu_die() does is that poll cpu
state and wait for 100ms if cpu state hasn't been marked to DEAD.
The 100ms sleep doesn't make sense. To avoid such long sleep, this
patch is to add struct completion to each cpu, wait for the completion
in the native_cpu_die() and wakeup the completion when the cpu state is
marked to DEAD.
Tested on the Intel Xeon server with 48 cores, Ivbridge and Haswell laptops.
the times of cpu offline on these machines are reduced from more than 100ms
to less than 5ms. The system suspend time reduces 2.3s on the servers.
Borislav and Prarit also helped to test the patch on an AMD machine and
a few systems of various sizes and configurations (multi-socket,
single-socket, no hyper threading, etc.). No issues seen.
Acked-by: Borislav Petkov
Tested-by: Prarit Bhargava
Signed-off-by: Lan Tianyu
---
arch/x86/kernel/smpboot.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 5492798..25a8f17 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -102,6 +102,8 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t,
cpu_llc_shared_map);
DEFINE_PER_CPU_SHARED_ALIGNED(struct cpuinfo_x86, cpu_info);
EXPORT_PER_CPU_SYMBOL(cpu_info);
+DEFINE_PER_CPU(struct completion, die_complete);
+
atomic_t init_deasserted;
/*
@@ -1331,7 +1333,7 @@ int native_cpu_disable(void)
return ret;
clear_local_APIC();
-
+ init_completion(&per_cpu(die_complete, smp_processor_id()));
cpu_disable_common();
return 0;
}
@@ -1339,18 +1341,14 @@ int native_cpu_disable(void)
void native_cpu_die(unsigned int cpu)
{
/* We don't do anything here: idle task is faking death itself. */
- unsigned int i;
+ wait_for_completion_timeout(&per_cpu(die_complete, cpu), HZ);
- for (i = 0; i < 10; i++) {
- /* They ack this in play_dead by setting CPU_DEAD */
- if (per_cpu(cpu_state, cpu) == CPU_DEAD) {
- if (system_state == SYSTEM_RUNNING)
- pr_info("CPU %u is now offline\n", cpu);
- return;
- }
- msleep(100);
- }
- pr_err("CPU %u didn't die...\n", cpu);
+ /* They ack this in play_dead by setting CPU_DEAD */
+ if (per_cpu(cpu_state, cpu) == CPU_DEAD) {
+ if (system_state == SYSTEM_RUNNING)
+ pr_info("CPU %u is now offline\n", cpu);
+ } else
+ pr_err("CPU %u didn't die...\n", cpu);
}
void play_dead_common(void)
@@ -1362,6 +1360,7 @@ void play_dead_common(void)
mb();
/* Ack it */
__this_cpu_write(cpu_state, CPU_DEAD);
+ complete(&per_cpu(die_complete, smp_processor_id()));
/*
* With physical CPU hotplug, we should halt the cpu
--
1.8.4.rc0.1.g8f6a3e5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 net-next 4/6] bpf: enable bpf syscall on x64 and i386
* Alexei Starovoitov wrote: > On Mon, Aug 25, 2014 at 8:52 PM, Stephen Hemminger > wrote: > > Per discussion at Kernel Summit. Every new syscall requires > > a manual page and test programs. We have had too many new syscalls > > that are DOA. > > There is verifier testsuite that is testing eBPF verifier from userspace > via bpf syscall. Also there are multiple examples and libbpf. > I think test coverage for bpf syscall is quite substantial already. This is in tools/bpf/, right? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] Tegra124 EMC (external memory controller) support
On Tue, Aug 26, 2014 at 10:42:21AM +0300, Mikko Perttunen wrote: > On 25/08/14 20:40, Stephen Warren wrote: > >On 07/11/2014 08:18 AM, Mikko Perttunen wrote: > >>Hi everyone, > >> > >>this series adds support for the EMC (external memory controller) clock > >>in the Tegra124 system-on-chip. The series has been tested on Jetson TK1. > >> > >>The first two patches remove the old "emc_mux" and "emc" clocks from the > >>clock tree and the device tree bindings. This is, of course, not > >>backwards > >>compatible, but as these clocks have never been useful for anything > >>(apart from maybe reading the boot rate of the EMC clock). If this is > >>still > >>not acceptable, the second patch can be dropped. > >... > > > >Mikko, this series had some comments, especially on the DT binding > >(patch 5/8) and how the MC/EMC drivers interact. Is there an updated > >version of the series? Or, is the series replaced by Tomeu Vizoso's work? > > Yes, I have a v2 with these comments addressed. One concern, though, is the > part writing to CLK_SOURCE_EMC. If some other driver also wants to read this > register (MC, likely), we might need to have an API for it in the CAR > driver. On the other hand, maybe not, since it's only one register. Thierry? I don't think any of these drivers should directly access registers that aren't in the memory region that they've claimed. If they need to access functionality provided by some other driver then they should do so via a custom API. Thierry pgpqYQfpyLBeW.pgp Description: PGP signature
[GIT PULL] s390 patches for the 3.17-rc3
Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates:
Wire up the system calls seccomp, getrandom and memfd_create.
Use static system information as input to add_device_randomness.
And three bug fixes.
Heiko Carstens (2):
s390: wire up seccomp and getrandom syscalls
s390: wire up memfd_create syscall
Martin Schwidefsky (3):
s390: add system information as device randomness
s390/3215: fix tty output containing tabs
s390/sclp: remove unnecessary XTABS flag
Michael Holzheu (1):
s390/kdump: Clear subchannel ID to signal non-CCW/SCSI IPL
arch/s390/include/uapi/asm/unistd.h |5 -
arch/s390/kernel/compat_wrapper.c |3 +++
arch/s390/kernel/ipl.c |7 +++
arch/s390/kernel/setup.c| 19 +++
arch/s390/kernel/syscalls.S |3 +++
drivers/s390/char/con3215.c | 20 +---
drivers/s390/char/sclp_tty.c|2 +-
7 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/arch/s390/include/uapi/asm/unistd.h
b/arch/s390/include/uapi/asm/unistd.h
index 3802d2d..940ac49 100644
--- a/arch/s390/include/uapi/asm/unistd.h
+++ b/arch/s390/include/uapi/asm/unistd.h
@@ -283,7 +283,10 @@
#define __NR_sched_setattr 345
#define __NR_sched_getattr 346
#define __NR_renameat2 347
-#define NR_syscalls 348
+#define __NR_seccomp 348
+#define __NR_getrandom 349
+#define __NR_memfd_create 350
+#define NR_syscalls 351
/*
* There are some system calls that are not present on 64 bit, some
diff --git a/arch/s390/kernel/compat_wrapper.c
b/arch/s390/kernel/compat_wrapper.c
index 45cdb37..faf6caa 100644
--- a/arch/s390/kernel/compat_wrapper.c
+++ b/arch/s390/kernel/compat_wrapper.c
@@ -214,3 +214,6 @@ COMPAT_SYSCALL_WRAP3(finit_module, int, fd, const char
__user *, uargs, int, fla
COMPAT_SYSCALL_WRAP3(sched_setattr, pid_t, pid, struct sched_attr __user *,
attr, unsigned int, flags);
COMPAT_SYSCALL_WRAP4(sched_getattr, pid_t, pid, struct sched_attr __user *,
attr, unsigned int, size, unsigned int, flags);
COMPAT_SYSCALL_WRAP5(renameat2, int, olddfd, const char __user *, oldname,
int, newdfd, const char __user *, newname, unsigned int, flags);
+COMPAT_SYSCALL_WRAP3(seccomp, unsigned int, op, unsigned int, flags, const
char __user *, uargs)
+COMPAT_SYSCALL_WRAP3(getrandom, char __user *, buf, size_t, count, unsigned
int, flags)
+COMPAT_SYSCALL_WRAP2(memfd_create, const char __user *, uname, unsigned int,
flags)
diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c
index 633ca75..22aac58 100644
--- a/arch/s390/kernel/ipl.c
+++ b/arch/s390/kernel/ipl.c
@@ -2060,6 +2060,13 @@ void s390_reset_system(void (*func)(void *), void *data)
S390_lowcore.program_new_psw.addr =
PSW_ADDR_AMODE | (unsigned long) s390_base_pgm_handler;
+ /*
+* Clear subchannel ID and number to signal new kernel that no CCW or
+* SCSI IPL has been done (for kexec and kdump)
+*/
+ S390_lowcore.subchannel_id = 0;
+ S390_lowcore.subchannel_nr = 0;
+
/* Store status at absolute zero */
store_status();
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index ae1d5be..82bc113 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -61,6 +62,7 @@
#include
#include
#include
+#include
#include "entry.h"
/*
@@ -766,6 +768,7 @@ static void __init setup_hwcaps(void)
#endif
get_cpu_id(&cpu_id);
+ add_device_randomness(&cpu_id, sizeof(cpu_id));
switch (cpu_id.machine) {
case 0x9672:
#if !defined(CONFIG_64BIT)
@@ -804,6 +807,19 @@ static void __init setup_hwcaps(void)
}
/*
+ * Add system information as device randomness
+ */
+static void __init setup_randomness(void)
+{
+ struct sysinfo_3_2_2 *vmms;
+
+ vmms = (struct sysinfo_3_2_2 *) alloc_page(GFP_KERNEL);
+ if (vmms && stsi(vmms, 3, 2, 2) == 0 && vmms->count)
+ add_device_randomness(&vmms, vmms->count);
+ free_page((unsigned long) vmms);
+}
+
+/*
* Setup function called from init/main.c just after the banner
* was printed.
*/
@@ -901,6 +917,9 @@ void __init setup_arch(char **cmdline_p)
/* Setup zfcpdump support */
setup_zfcpdump();
+
+ /* Add system specific data to the random pool */
+ setup_randomness();
}
#ifdef CONFIG_32BIT
diff --git a/arch/s390/kernel/syscalls.S b/arch/s390/kernel/syscalls.S
index fe5cdf2..6fe886a 100644
--- a/arch/s390/kernel/syscalls.S
+++ b/arch/s390/kernel/syscalls.S
@@ -356,3 +356,6 @@
SYSCALL(sys_finit_module,sys_finit_module,compat_sys_finit_module)
SYSCALL(sys_sched_setattr,sys_sched_setattr,compat_sys_sched_setattr) /* 345 */
SYSCALL(sys_sched_getattr,sys_sc
Re: [PATCH v2 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
On Tue, Aug 26, 2014 at 09:43:50AM +0200, Arnd Bergmann wrote: > On Tuesday 26 August 2014 08:57:31 Thierry Reding wrote: > > On Mon, Aug 25, 2014 at 01:01:52PM -0600, Stephen Warren wrote: > > > On 08/18/2014 11:08 AM, Andrew Bresticker wrote: > > [...] > > > >+static int tegra_xusb_mbox_probe(struct platform_device *pdev) > > > > > > >+res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > > >+if (!res) > > > >+return -ENODEV; > > > > > > Should devm_request_mem_region() be called here to claim the region? > > > > > > >+mbox->regs = devm_ioremap_nocache(&pdev->dev, res->start, > > > >+ resource_size(res)); > > > >+if (!mbox->regs) > > > >+return -ENOMEM; > > > > > > Is _nocache required? I don't see other drivers using it. I assume there's > > > nothing special about the mbox registers. > > > > Most drivers should be using devm_ioremap_resource() which will use the > > _nocache variant of devm_ioremap() when appropriate. Usually the region > > will not be marked cacheable (IORESOURCE_CACHEABLE) and therefore be > > remapped uncached. > > > > Note that ioremap() and ioremap_nocache() are the same. We really shouldn't > ever call ioremap_nocache(). Perhaps we should remove ioremap_nocache() in that case. Or ioremap(), really, and keep only those variants that do what they claim to do. > devm_ioremap_resource() and pci_iomap() checking for IORESOURCE_CACHEABLE is > rather silly, since it doesn't call ioremap_cache() in that case. Then that should be fixed. Thierry pgpW8Jmi8j6J6.pgp Description: PGP signature
Re: [PATCH] sound: pci: ctxfi: ctatc.c: printk replacement
On Tue, Aug 26, 2014 at 08:27:09AM +0200, Takashi Iwai wrote:
> At Mon, 25 Aug 2014 23:26:52 +0530,
> Sudip Mukherjee wrote:
> >
> > printk replaced ith corresponding pr_err
> > fixed three broken user-visible strings
> > fixed a checkpatch warning of space before new line
>
> Fixes are good, but is this the final patch for ctxfi?
> If you're going to post another one, please fold them into a single
> patch. All patches do basically the same job, so splitting patches
> doesn't help much in such a case. Patches should be split logically.
>
> Also, if you fix broken strings, better to do it consistently to all
> targeted strings, instead of picking up random ones.
>
>
> thanks,
>
> Takashi
Hi,
I was posting them separately as i was thinking it will become a big patch.
For the broken string , it was actually not random . I did it only for those
string that were affected by my patch.
Anyways, I will send you a complete one for ctxfi.
thanks
sudip
>
> >
> >
> > Signed-off-by: Sudip Mukherjee
> > ---
> > sound/pci/ctxfi/ctatc.c | 23 ++-
> > 1 file changed, 10 insertions(+), 13 deletions(-)
> >
> > diff --git a/sound/pci/ctxfi/ctatc.c b/sound/pci/ctxfi/ctatc.c
> > index af632bd..41597a8 100644
> > --- a/sound/pci/ctxfi/ctatc.c
> > +++ b/sound/pci/ctxfi/ctatc.c
> > @@ -185,7 +185,7 @@ static unsigned int convert_format(snd_pcm_format_t
> > snd_format)
> > case SNDRV_PCM_FORMAT_FLOAT_LE:
> > return SRC_SF_F32;
> > default:
> > - printk(KERN_ERR "ctxfi: not recognized snd format is %d \n",
> > + pr_err("ctxfi: not recognized snd format is %d\n",
> > snd_format);
> > return SRC_SF_S16;
> > }
> > @@ -1282,7 +1282,7 @@ static int atc_identify_card(struct ct_atc *atc,
> > unsigned int ssid)
> > p = snd_pci_quirk_lookup_id(vendor_id, device_id, list);
> > if (p) {
> > if (p->value < 0) {
> > - printk(KERN_ERR "ctxfi: "
> > + pr_err("ctxfi: "
> >"Device %04x:%04x is black-listed\n",
> >vendor_id, device_id);
> > return -ENOENT;
> > @@ -1315,8 +1315,7 @@ int ct_atc_create_alsa_devs(struct ct_atc *atc)
> > err = alsa_dev_funcs[i].create(atc, i,
> > alsa_dev_funcs[i].public_name);
> > if (err) {
> > - printk(KERN_ERR "ctxfi: "
> > - "Creating alsa device %d failed!\n", i);
> > + pr_err("ctxfi: Creating alsa device %d failed!\n", i);
> > return err;
> > }
> > }
> > @@ -1332,7 +1331,7 @@ static int atc_create_hw_devs(struct ct_atc *atc)
> >
> > err = create_hw_obj(atc->pci, atc->chip_type, atc->model, &hw);
> > if (err) {
> > - printk(KERN_ERR "Failed to create hw obj!!!\n");
> > + pr_err("Failed to create hw obj!!!\n");
> > return err;
> > }
> > atc->hw = hw;
> > @@ -1351,8 +1350,7 @@ static int atc_create_hw_devs(struct ct_atc *atc)
> >
> > err = rsc_mgr_funcs[i].create(atc->hw, &atc->rsc_mgrs[i]);
> > if (err) {
> > - printk(KERN_ERR "ctxfi: "
> > - "Failed to create rsc_mgr %d!!!\n", i);
> > + pr_err("ctxfi: Failed to create rsc_mgr %d!!!\n", i);
> > return err;
> > }
> > }
> > @@ -1399,7 +1397,7 @@ static int atc_get_resources(struct ct_atc *atc)
> > err = daio_mgr->get_daio(daio_mgr, &da_desc,
> > (struct daio **)&atc->daios[i]);
> > if (err) {
> > - printk(KERN_ERR "ctxfi: Failed to get DAIO "
> > + pr_err("ctxfi: Failed to get DAIO "
> > "resource %d!!!\n", i);
> > return err;
> > }
> > @@ -1603,8 +1601,7 @@ static int atc_resume(struct ct_atc *atc)
> > /* Do hardware resume. */
> > err = atc_hw_resume(atc);
> > if (err < 0) {
> > - printk(KERN_ERR "ctxfi: pci_enable_device failed, "
> > - "disabling device\n");
> > + pr_err("ctxfi: pci_enable_device failed, disabling device\n");
> > snd_card_disconnect(atc->card);
> > return err;
> > }
> > @@ -1701,7 +1698,7 @@ int ct_atc_create(struct snd_card *card, struct
> > pci_dev *pci,
> > /* Find card model */
> > err = atc_identify_card(atc, ssid);
> > if (err < 0) {
> > - printk(KERN_ERR "ctatc: Card not recognised\n");
> > + pr_err("ctatc: Card not recognised\n");
> > goto error1;
> > }
> >
> > @@ -1717,7 +1714,7 @@ int ct_atc_create(struct snd_card *card, struct
> > pci_dev *pci,
> >
> > err = ct_mixer_create(atc, (struct ct_mixer **)&atc->mixer);
> > if (err) {
> > - printk(KERN_ERR "ctxfi: Failed to cre
Re: [PATCH] iio: core: Propagate error codes from OF layer to client drivers
Hi,
On Mon, 2014-08-25 at 09:54 -0700, Guenter Roeck wrote:
> On Mon, Aug 25, 2014 at 05:10:31PM +0100, Jonathan Cameron wrote:
> > On 25/08/14 13:57, Ivan T. Ivanov wrote:
> > > Do not overwrite error codes returned from of_iio_channel_get().
> > > Error codes are used to distinguish between "io-channel-names"
> > > not present in DT bindings, property is optional, and IIO channel
> > > provider driver still not being loaded, defer probe.
> > >
> > > Signed-off-by: Ivan T. Ivanov
> > Cc'd Guenter who often takes an interest in this code (and wrote it ;)
> >
> > Mostly seems logical to me, though I don't like the change of
> > priority in the last bit. I've also just taken a fix for this
> > code so there may be some fuzz from that once it's propogated
> > through to mainline and back to the togreg tree of iio.git
It is propagated, but exactly this patch [1] is causing the troubles :-)
> >
> > Thanks,
> >
> > Jonathan
> > > ---
> > > drivers/iio/inkern.c | 24
> > > 1 file changed, 12 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> > > index c749700..66a6cde 100644
> > > --- a/drivers/iio/inkern.c
> > > +++ b/drivers/iio/inkern.c
> > > @@ -162,7 +162,7 @@ err_free_channel:
> > > static struct iio_channel *of_iio_channel_get_by_name(struct device_node
> > > *np,
> > > const char *name)
> > > {
> > > - struct iio_channel *chan = NULL;
> > > + struct iio_channel *chan = ERR_PTR(-ENODEV);
> > >
> > > /* Walk up the tree of devices looking for a matching iio channel */
> > > while (np) {
> > > @@ -183,7 +183,7 @@ static struct iio_channel
> > > *of_iio_channel_get_by_name(struct device_node *np,
> > > else if (name && index >= 0) {
> > > pr_err("ERROR: could not get IIO channel %s:%s(%i)\n",
> > > np->full_name, name ? name : "", index);
> > > - return NULL;
> > > + break;
> > > }
> > >
> > > /*
> > > @@ -193,7 +193,7 @@ static struct iio_channel
> > > *of_iio_channel_get_by_name(struct device_node *np,
> > >*/
> > > np = np->parent;
> > > if (np && !of_get_property(np, "io-channel-ranges", NULL))
> > > - return NULL;
> > > + break;
> > > }
> > >
> > > return chan;
> > > @@ -243,12 +243,12 @@ error_free_chans:
> > > static inline struct iio_channel *
> > > of_iio_channel_get_by_name(struct device_node *np, const char *name)
> > > {
> > > - return NULL;
> > > + return ERR_PTR(-ENODEV);
> > > }
> > >
> > > static inline struct iio_channel *of_iio_channel_get_all(struct device
> > > *dev)
> > > {
> > > - return NULL;
> > > + return ERR_PTR(-ENODEV);
> > > }
> > >
> > > #endif /* CONFIG_OF */
> > > @@ -312,14 +312,14 @@ struct iio_channel *iio_channel_get(struct device
> > > *dev,
> > > const char *name = dev ? dev_name(dev) : NULL;
> > > struct iio_channel *channel;
> > >
> > > - if (dev) {
> > > - channel = of_iio_channel_get_by_name(dev->of_node,
> > > - channel_name);
> > > - if (channel != NULL)
> > > - return channel;
> > > - }
> > > + channel = iio_channel_get_sys(name, channel_name);
> > > + if (!IS_ERR(channel))
> > > + return channel;
> > > +
> > > + if (!dev)
> > > + return channel;
> > >
> > > - return iio_channel_get_sys(name, channel_name);
> > > + return of_iio_channel_get_by_name(dev->of_node, channel_name);
> > > }
> > Why reorder the logic? This makes this patch less obviously
> > correct for limited obvious gain?
I would like to avoid white listing EPROBE_DEFER error code on return of
of_get() function.
> >
> > Previously the priority was clearly given to device tree bindings
> > wherease now it is given to board file provided map elements. It
> > would be interesting to see boards with both provided, but it is
> > possible.
I see.
>
> I am not entirely sure I understand what problem this patch is supposed
> to fix on top of the patch you just applied,
Patch [1], Guenter please fix you date, introduce regression. It
breaks deferred probe mechanism.
> and I am also a bit concerned
> about reversing the logic. Also, iio_channel_get_sys can return -ENOMEM
> and -EINVAL besides -ENODEV, all of which is now being ignored
Yes, and thats why we continue with trying to find channel using OF.
> unless dev is set, and then it is returned unconditionally.
If dev is not valid there is no point to go and ask OF layer for
channel, so jut go out with error code from get_sys()
> So instead of ignoring error
> codes from of_iio_channel_get_by_name, the code now ignores error codes
> from iio_channel_get_sys under some circumstances (which, coincidentially,
> does not return -EPROBE_DEFER), and in other circumstances may return an error
> even if devicetree data
Re: [PATCH v5 3/4] zram: zram memory size limitation
Hey Joonsoo,
On Tue, Aug 26, 2014 at 04:37:30PM +0900, Joonsoo Kim wrote:
> On Mon, Aug 25, 2014 at 09:05:55AM +0900, Minchan Kim wrote:
> > @@ -513,6 +540,14 @@ static int zram_bvec_write(struct zram *zram, struct
> > bio_vec *bvec, u32 index,
> > ret = -ENOMEM;
> > goto out;
> > }
> > +
> > + if (zram->limit_pages &&
> > + zs_get_total_pages(meta->mem_pool) > zram->limit_pages) {
> > + zs_free(meta->mem_pool, handle);
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO);
>
> Hello,
>
> I don't follow up previous discussion, so I could be wrong.
> Why this enforcement should be here?
>
> I think that this has two problems.
> 1) alloc/free happens unnecessarilly if we have used memory over the
> limitation.
True but firstly, I implemented the logic in zsmalloc, not zram but
as I described in cover-letter, it's not a requirement of zsmalloc
but zram so it should be in there. If every user want it in future,
then we could move the function into zsmalloc. That's what we
concluded in previous discussion.
Another idea is we could call zs_get_total_pages right before zs_malloc
but the problem is we cannot know how many of pages are allocated
by zsmalloc in advance.
IOW, zram should be blind on zsmalloc's internal.
About alloc/free cost once if it is over the limit,
I don't think it's important to consider.
Do you have any scenario in your mind to consider alloc/free cost
when the limit is over?
> 2) Even if this request doesn't do new allocation, it could be failed
> due to other's allocation. There is time gap between allocation and
> free, so legimate user who want to use preallocated zsmalloc memory
> could also see this condition true and then he will be failed.
Yeb, we already discussed that. :)
Such false positive shouldn't be a severe problem if we can keep a
promise that zram user cannot exceed mem_limit.
>
> Thanks.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 25.08.2014 15:08, schrieb Jon Loeliger: Anyway, instead of going back and forth between "deferred probe is good" and "deferred probe is bad", how about we do something useful now and concentrate on how to make use of the information we have in DT with the goal to reduce the number of cases where deferred probing is required? Good idea. The proposal on the table is to allow the probe code to make a topological sort of the devices based on dependency information either implied, explicitly stated or both. That is likely a fundamentally correct approach. I believe some of the issues that need to be resolved are: 1) What constitutes a dependency? In my patches phandles are used. That works pretty good for almost all DTs. So almost all dependencies are already declared in a DT and almost no changes to the DT are necessary. The only binding I've seen where it doesn't work is remote-endpoint, because that binding isn't a directed dependency. So one of the two places where such a binding occurs needs a "no-dependencies = " to avoid circular dependencies which can be solved. 2) How is that dependency expressed? Already there in form of phandles. 3) How do we add missing dependencies? My patches offer the possibility to extend or reduce the list of (automatically generated) dependencies by using "[no-]dependencies = < list of phandles >;" 4) Backward compatability problems. None in my approach. The DT just includes an additional binding to circumvent the missing but needed type information for phandles. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] ARM: debug: uncompress debug support for omap2plus
On Tue, Aug 26, 2014 at 04:28:59PM +0900, kpark3...@gmail.com wrote: > From: Sahara > > Since OMAP low-level debug code places data in the .data section, > The symbol DEBUG_UNCOMPRESS was defined with !DEBUG_OMAP2PLUS_UART. > This patch removes the part using data section in debug/omap2plus.S, > so DEBUG_UNCOMPRESS is now available on OMAP system. > > Signed-off-by: Sahara > Tested-by: Afzal Mohammed (on am335x beagle > bone white) You need to consider whom you are sending this to. It would be well worth including the OMAP maintainer, Tony Lindgren. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 net-next 4/6] bpf: enable bpf syscall on x64 and i386
On 08/26/2014 09:46 AM, Ingo Molnar wrote: * Alexei Starovoitov wrote: On Mon, Aug 25, 2014 at 8:52 PM, Stephen Hemminger wrote: Per discussion at Kernel Summit. Every new syscall requires a manual page and test programs. We have had too many new syscalls that are DOA. There is verifier testsuite that is testing eBPF verifier from userspace via bpf syscall. Also there are multiple examples and libbpf. I think test coverage for bpf syscall is quite substantial already. This is in tools/bpf/, right? No, it contains a BPF JIT disasm, bpf assembler and a debugger, but the last two are for the 'classic' BPF interface only. There's a test suite for BPF/eBPF in general under lib/test_bpf.c, but so far it tests only the current code w/o eBPF verifier. That said, I think Alexei is referring to the examples et al from the bigger previous proposed patch set. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 net-next 4/6] bpf: enable bpf syscall on x64 and i386
* Daniel Borkmann wrote: > On 08/26/2014 09:46 AM, Ingo Molnar wrote: > >* Alexei Starovoitov wrote: > >>On Mon, Aug 25, 2014 at 8:52 PM, Stephen Hemminger > >> wrote: > >>>Per discussion at Kernel Summit. Every new syscall requires > >>>a manual page and test programs. We have had too many new syscalls > >>>that are DOA. > >> > >>There is verifier testsuite that is testing eBPF verifier from userspace > >>via bpf syscall. Also there are multiple examples and libbpf. > >>I think test coverage for bpf syscall is quite substantial already. > > > >This is in tools/bpf/, right? > > No, it contains a BPF JIT disasm, bpf assembler and a debugger, > but the last two are for the 'classic' BPF interface only. > There's a test suite for BPF/eBPF in general under > lib/test_bpf.c, but so far it tests only the current code w/o > eBPF verifier. > > That said, I think Alexei is referring to the examples et al > from the bigger previous proposed patch set. I mean, if all the testing already exists, it should be part of an initial submission and such. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] perf tools: Add +field argument support for --sort option
Hi Jiri, On Sat, 23 Aug 2014 14:59:48 +0200, Jiri Olsa wrote: > Adding support to add field(s) to default sort order > via using the '+' prefix, like for report: > > $ perf report > Samples: 2K of event 'cycles', Event count (approx.): 882172583 > Overhead Command Shared ObjectSymbol > 7.39% swapper [kernel.kallsyms][k] intel_idle > 1.97% firefox libpthread-2.17.so [.] > pthread_mutex_lock > 1.39% firefox [snd_hda_intel] [k] azx_get_position > 1.11% firefox libpthread-2.17.so [.] > pthread_mutex_unlock > > $ perf report -s +cpu > Samples: 2K of event 'cycles', Event count (approx.): 882172583 > Overhead Command Shared ObjectSymbol > CPU > 2.89% swapper [kernel.kallsyms][k] intel_idle > 000 > 2.61% swapper [kernel.kallsyms][k] intel_idle > 002 > 1.20% swapper [kernel.kallsyms][k] intel_idle > 001 > 0.82% firefox libpthread-2.17.so [.] > pthread_mutex_lock 002 > > Works in general for commands using --sort option. > > Cc: Arnaldo Carvalho de Melo > Cc: Corey Ashford > Cc: David Ahern > Cc: Frederic Weisbecker > Cc: Ingo Molnar > Cc: Jean Pihet > Cc: Paul Mackerras > Cc: Peter Zijlstra > Signed-off-by: Jiri Olsa Acked-by: Namhyung Kim Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][input-led] Defer input led work to workqueue
On Tue, 2014-08-26 at 03:54 +0200, Samuel Thibault wrote:
> + vt_led_wq = alloc_workqueue("input_leds", WQ_UNBOUND, 0);
> + if (!vt_led_wq)
> + return -ENOMEM;
Does this really need a separate workqueue rather than just using
schedule_work()? There doesn't seem to be much point in having its own
workqueue really, to me.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] Tegra124 EMC (external memory controller) support
On 26/08/14 10:47, Thierry Reding wrote: * PGP Signed by an unknown key On Tue, Aug 26, 2014 at 10:42:21AM +0300, Mikko Perttunen wrote: On 25/08/14 20:40, Stephen Warren wrote: On 07/11/2014 08:18 AM, Mikko Perttunen wrote: Hi everyone, this series adds support for the EMC (external memory controller) clock in the Tegra124 system-on-chip. The series has been tested on Jetson TK1. The first two patches remove the old "emc_mux" and "emc" clocks from the clock tree and the device tree bindings. This is, of course, not backwards compatible, but as these clocks have never been useful for anything (apart from maybe reading the boot rate of the EMC clock). If this is still not acceptable, the second patch can be dropped. ... Mikko, this series had some comments, especially on the DT binding (patch 5/8) and how the MC/EMC drivers interact. Is there an updated version of the series? Or, is the series replaced by Tomeu Vizoso's work? Yes, I have a v2 with these comments addressed. One concern, though, is the part writing to CLK_SOURCE_EMC. If some other driver also wants to read this register (MC, likely), we might need to have an API for it in the CAR driver. On the other hand, maybe not, since it's only one register. Thierry? I don't think any of these drivers should directly access registers that aren't in the memory region that they've claimed. If they need to access functionality provided by some other driver then they should do so via a custom API. I'll make a simple API and post patches. Thierry * Unknown Key * 0x7F3EB3A1 Mikko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: fix warning from Sparse for socfpga
On 8/26/2014 9:47 AM, Ley Foon Tan wrote: On Tue, Aug 26, 2014 at 3:24 PM, Giuseppe CAVALLARO wrote: @@ -119,7 +119,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device * return -EINVAL; } - dwmac->splitter_base = (void *)devm_ioremap_resource(dev, + dwmac->splitter_base = + (void __iomem *)devm_ioremap_resource(dev, I think, no casting should be done: dwmac->splitter_base = devm_ioremap_resource(dev, Oh ya, since both are same type. Will send new patch. thx a lot patch should be for net-next Do you mean the patch need based on net-next git? yes I do. I'm using linux-next git now. ok, can you signal it in the subject (e.g. [PATCH (net-next)] This can help on reviewing and IIRC required by Maintainer too Thanks. welcome BR peppe Regards Ley Foon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] DRBG: fix maximum value checks on 32 bit systems
The maximum values for additional input string or generated blocks is
larger than 1<<32. To ensure a sensible value on 32 bit systems, return
SIZE_MAX on 32 bit systems. This value is lower than the maximum allowed
values defined in SP800-90A. The standard allow lower maximum values,
but not larger values.
Reported-by: Stephen Rothwell
Reported-by: kbuild test robot
Signed-off-by: Stephan Mueller
---
include/crypto/drbg.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index 3d8e73a..5ac482a 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -154,13 +154,21 @@ static inline size_t drbg_max_request_bytes(struct
drbg_state *drbg)
static inline size_t drbg_max_addtl(struct drbg_state *drbg)
{
/* SP800-90A requires 2**35 bytes additional info str / pers str */
+#if (__BITS_PER_LONG == 32)
+ return SIZE_MAX;
+#else
return (1UL<<35);
+#endif
}
static inline size_t drbg_max_requests(struct drbg_state *drbg)
{
/* SP800-90A requires 2**48 maximum requests before reseeding */
+#if (__BITS_PER_LONG == 32)
+ return SIZE_MAX;
+#else
return (1UL<<48);
+#endif
}
/*
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 2/4] mm/page_alloc: add freepage on isolate pageblock to correct buddy list
In free_pcppages_bulk(), we use cached migratetype of freepage
to determine type of buddy list where freepage will be added.
This information is stored when freepage is added to pcp list, so
if isolation of pageblock of this freepage begins after storing,
this cached information could be stale. In other words, it has
original migratetype rather than MIGRATE_ISOLATE.
There are two problems caused by this stale information. One is that
we can't keep these freepages from being allocated. Although this
pageblock is isolated, freepage will be added to normal buddy list
so that it could be allocated without any restriction. And the other
problem is incorrect freepage accounting. Freepages on isolate pageblock
should not be counted for number of freepage.
Following is the code snippet in free_pcppages_bulk().
/* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */
__free_one_page(page, page_to_pfn(page), zone, 0, mt);
trace_mm_page_pcpu_drain(page, 0, mt);
if (likely(!is_migrate_isolate_page(page))) {
__mod_zone_page_state(zone, NR_FREE_PAGES, 1);
if (is_migrate_cma(mt))
__mod_zone_page_state(zone, NR_FREE_CMA_PAGES, 1);
}
As you can see above snippet, current code already handle second problem,
incorrect freepage accounting, by re-fetching pageblock migratetype
through is_migrate_isolate_page(page). But, because this re-fetched
information isn't used for __free_one_page(), first problem would not be
solved. This patch try to solve this situation to re-fetch pageblock
migratetype before __free_one_page() and to use it for __free_one_page().
In addition to move up position of this re-fetch, this patch use
optimization technique, re-fetching migratetype only if there is
isolate pageblock. Pageblock isolation is rare event, so we can
avoid re-fetching in common case with this optimization.
Signed-off-by: Joonsoo Kim
---
mm/page_alloc.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 51e0d13..6c952b6 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -716,14 +716,17 @@ static void free_pcppages_bulk(struct zone *zone, int
count,
/* must delete as __free_one_page list manipulates */
list_del(&page->lru);
mt = get_freepage_migratetype(page);
+ if (unlikely(has_isolate_pageblock(zone))) {
+ mt = get_pageblock_migratetype(page);
+ if (is_migrate_isolate(mt))
+ goto skip_counting;
+ }
+ __mod_zone_freepage_state(zone, 1, mt);
+
+skip_counting:
/* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */
__free_one_page(page, page_to_pfn(page), zone, 0, mt);
trace_mm_page_pcpu_drain(page, 0, mt);
- if (likely(!is_migrate_isolate_page(page))) {
- __mod_zone_page_state(zone, NR_FREE_PAGES, 1);
- if (is_migrate_cma(mt))
- __mod_zone_page_state(zone,
NR_FREE_CMA_PAGES, 1);
- }
} while (--to_free && --batch_free && !list_empty(list));
}
spin_unlock(&zone->lock);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 4/4] mm/page_alloc: restrict max order of merging on isolated pageblock
Current pageblock isolation logic could isolate each pageblock
individually. This causes freepage accounting problem if freepage with
pageblock order on isolate pageblock is merged with other freepage on
normal pageblock. We can prevent merging by restricting max order of
merging to pageblock order if freepage is on isolate pageblock.
Side-effect of this change is that there could be non-merged buddy
freepage even if finishing pageblock isolation, because undoing pageblock
isolation is just to move freepage from isolate buddy list to normal buddy
list rather than to consider merging. But, I think it doesn't matter
because 1) almost allocation request are for equal or below pageblock
order, 2) caller of pageblock isolation will use this freepage so
freepage will split in any case and 3) merge would happen soon after
some alloc/free on this and buddy pageblock.
Signed-off-by: Joonsoo Kim
---
mm/page_alloc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 809bfd3..8ba9fb0 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -570,6 +570,7 @@ static inline void __free_one_page(struct page *page,
unsigned long combined_idx;
unsigned long uninitialized_var(buddy_idx);
struct page *buddy;
+ int max_order = MAX_ORDER;
VM_BUG_ON(!zone_is_initialized(zone));
@@ -580,18 +581,26 @@ static inline void __free_one_page(struct page *page,
VM_BUG_ON(migratetype == -1);
if (unlikely(has_isolate_pageblock(zone))) {
migratetype = get_pfnblock_migratetype(page, pfn);
- if (is_migrate_isolate(migratetype))
+ if (is_migrate_isolate(migratetype)) {
+ /*
+* We restrict max order of merging to prevent merge
+* between freepages on isolate pageblock and normal
+* pageblock. Without this, pageblock isolation
+* could cause incorrect freepage accounting.
+*/
+ max_order = pageblock_order + 1;
goto skip_counting;
+ }
}
__mod_zone_freepage_state(zone, 1 << order, migratetype);
skip_counting:
- page_idx = pfn & ((1 << MAX_ORDER) - 1);
+ page_idx = pfn & ((1 << max_order) - 1);
VM_BUG_ON_PAGE(page_idx & ((1 << order) - 1), page);
VM_BUG_ON_PAGE(bad_range(zone, page), page);
- while (order < MAX_ORDER-1) {
+ while (order < max_order - 1) {
buddy_idx = __find_buddy_index(page_idx, order);
buddy = page + (buddy_idx - page_idx);
if (!page_is_buddy(page, buddy, order))
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DRBG: fix maximum value checks on 32 bit systems
On Tue, Aug 26, 2014 at 10:06:52AM +0200, Stephan Mueller wrote: > The maximum values for additional input string or generated blocks is > larger than 1<<32. To ensure a sensible value on 32 bit systems, return > SIZE_MAX on 32 bit systems. This value is lower than the maximum allowed > values defined in SP800-90A. The standard allow lower maximum values, > but not larger values. > > Reported-by: Stephen Rothwell > Reported-by: kbuild test robot > Signed-off-by: Stephan Mueller Unfortunately there's a place in drbg where you add one to drbg_max_addtl which will cause it to overflow back to zero. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 3/4] mm/page_alloc: move migratetype recheck logic to __free_one_page()
All the caller of __free_one_page() has same migratetype recheck logic,
so we can move it to __free_one_page(). This reduce line of code and help
future maintenance. This is also preparation step for "mm/page_alloc:
restrict max order of merging on isolated pageblock" which fix the
freepage accouting problem on freepage with more than pageblock order.
Signed-off-by: Joonsoo Kim
---
mm/page_alloc.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6c952b6..809bfd3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -578,7 +578,14 @@ static inline void __free_one_page(struct page *page,
return;
VM_BUG_ON(migratetype == -1);
+ if (unlikely(has_isolate_pageblock(zone))) {
+ migratetype = get_pfnblock_migratetype(page, pfn);
+ if (is_migrate_isolate(migratetype))
+ goto skip_counting;
+ }
+ __mod_zone_freepage_state(zone, 1 << order, migratetype);
+skip_counting:
page_idx = pfn & ((1 << MAX_ORDER) - 1);
VM_BUG_ON_PAGE(page_idx & ((1 << order) - 1), page);
@@ -716,14 +723,7 @@ static void free_pcppages_bulk(struct zone *zone, int
count,
/* must delete as __free_one_page list manipulates */
list_del(&page->lru);
mt = get_freepage_migratetype(page);
- if (unlikely(has_isolate_pageblock(zone))) {
- mt = get_pageblock_migratetype(page);
- if (is_migrate_isolate(mt))
- goto skip_counting;
- }
- __mod_zone_freepage_state(zone, 1, mt);
-skip_counting:
/* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */
__free_one_page(page, page_to_pfn(page), zone, 0, mt);
trace_mm_page_pcpu_drain(page, 0, mt);
@@ -743,14 +743,6 @@ static void free_one_page(struct zone *zone,
if (nr_scanned)
__mod_zone_page_state(zone, NR_PAGES_SCANNED, -nr_scanned);
- if (unlikely(has_isolate_pageblock(zone))) {
- migratetype = get_pfnblock_migratetype(page, pfn);
- if (is_migrate_isolate(migratetype))
- goto skip_counting;
- }
- __mod_zone_freepage_state(zone, 1 << order, migratetype);
-
-skip_counting:
__free_one_page(page, pfn, zone, order, migratetype);
spin_unlock(&zone->lock);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 1/4] mm/page_alloc: fix incorrect isolation behavior by rechecking migratetype
There are two paths to reach core free function of buddy allocator,
__free_one_page(), one is free_one_page()->__free_one_page() and the
other is free_hot_cold_page()->free_pcppages_bulk()->__free_one_page().
Each paths has race condition causing serious problems. At first, this
patch is focused on first type of freepath. And then, following patch
will solve the problem in second type of freepath.
In the first type of freepath, we got migratetype of freeing page without
holding the zone lock, so it could be racy. There are two cases of this
race.
1. pages are added to isolate buddy list after restoring orignal
migratetype
CPU1 CPU2
get migratetype => return MIGRATE_ISOLATE
call free_one_page() with MIGRATE_ISOLATE
grab the zone lock
unisolate pageblock
release the zone lock
grab the zone lock
call __free_one_page() with MIGRATE_ISOLATE
freepage go into isolate buddy list,
although pageblock is already unisolated
This may cause two problems. One is that we can't use this page anymore
until next isolation attempt of this pageblock, because freepage is on
isolate pageblock. The other is that freepage accouting could be wrong
due to merging between different buddy list. Freepages on isolate buddy
list aren't counted as freepage, but ones on normal buddy list are counted
as freepage. If merge happens, buddy freepage on normal buddy list is
inevitably moved to isolate buddy list without any consideration of
freepage accouting so it could be incorrect.
2. pages are added to normal buddy list while pageblock is isolated.
It is similar with above case.
This also may cause two problems. One is that we can't keep these
freepages from being allocated. Although this pageblock is isolated,
freepage would be added to normal buddy list so that it could be
allocated without any restriction. And the other problem is same as
case 1, that it, incorrect freepage accouting.
This race condition would be prevented by checking migratetype again
with holding the zone lock. Because it is somewhat heavy operation
and it isn't needed in common case, we want to avoid rechecking as much
as possible. So this patch introduce new variable, nr_isolate_pageblock
in struct zone to check if there is isolated pageblock.
With this, we can avoid to re-check migratetype in common case and do
it only if there is isolated pageblock. This solve above
mentioned problems.
Signed-off-by: Joonsoo Kim
---
include/linux/mmzone.h |4
include/linux/page-isolation.h |8
mm/page_alloc.c| 10 --
mm/page_isolation.c|2 ++
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 318df70..23e69f1 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -431,6 +431,10 @@ struct zone {
*/
int nr_migrate_reserve_block;
+#ifdef CONFIG_MEMORY_ISOLATION
+ unsigned long nr_isolate_pageblock;
+#endif
+
#ifdef CONFIG_MEMORY_HOTPLUG
/* see spanned/present_pages for more description */
seqlock_t span_seqlock;
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 3fff8e7..2dc1e16 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -2,6 +2,10 @@
#define __LINUX_PAGEISOLATION_H
#ifdef CONFIG_MEMORY_ISOLATION
+static inline bool has_isolate_pageblock(struct zone *zone)
+{
+ return zone->nr_isolate_pageblock;
+}
static inline bool is_migrate_isolate_page(struct page *page)
{
return get_pageblock_migratetype(page) == MIGRATE_ISOLATE;
@@ -11,6 +15,10 @@ static inline bool is_migrate_isolate(int migratetype)
return migratetype == MIGRATE_ISOLATE;
}
#else
+static inline bool has_isolate_pageblock(struct zone *zone)
+{
+ return false;
+}
static inline bool is_migrate_isolate_page(struct page *page)
{
return false;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f86023b..51e0d13 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -740,9 +740,15 @@ static void free_one_page(struct zone *zone,
if (nr_scanned)
__mod_zone_page_state(zone, NR_PAGES_SCANNED, -nr_scanned);
+ if (unlikely(has_isolate_pageblock(zone))) {
+ migratetype = get_pfnblock_migratetype(page, pfn);
+ if (is_migrate_isolate(migratetype))
+ goto skip_counting;
+ }
+ __mod_zone_freepage_state(zone, 1 << order, migratetype);
+
+skip_counting:
__free_one_page(page, pfn, zone, order, migratetype);
- if (unlikely(!is_migrate_isolate(migratetype)))
- __mod_zone_freepage_state(zone, 1 << order, migratetype);
spin_unlock(&zone->lock);
}
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index d1473b2..1fa4a4d 100644
-
[RFC PATCH v3 0/4] fix freepage count problems in memory isolation
This is version 3 patchset which is improved and minimized version of version 1 to fix freepage accounting problem during memory isolation. I tried different approach in version 2, but, it looks really complicated so I change my mind to improve version 1. You can see version 1, 2 in following links [1] [2], respectively. IMO, this v3 is better than v2, because this is simpler than v2 so better for maintainance and this doesn't change pageblock isolation logic so it is much easier to backport. This problems are found by testing my patchset [3]. There are some race conditions on pageblock isolation and these race cause incorrect freepage count. Before describing bugs itself, I first explain definition of freepage. 1. pages on buddy list are counted as freepage. 2. pages on isolate migratetype buddy list are *not* counted as freepage. 3. pages on cma buddy list are counted as CMA freepage, too. Now, I describe problems and related patch. Patch 1: There is race conditions on getting pageblock migratetype that it results in misplacement of freepages on buddy list, incorrect freepage count and un-availability of freepage. Patch 2: Freepages on pcp list could have stale cached information to determine migratetype of buddy list to go. This causes misplacement of freepages on buddy list and incorrect freepage count. Patch 4: Merging between freepages on different migratetype of pageblocks will cause freepages accouting problem. This patch fixes it. Without patchset [3], above problem doesn't happens on my CMA allocation test, because CMA reserved pages aren't used at all. So there is no chance for above race. With patchset [3], I did simple CMA allocation test and get below result. - Virtual machine, 4 cpus, 1024 MB memory, 256 MB CMA reservation - run kernel build (make -j16) on background - 30 times CMA allocation(8MB * 30 = 240MB) attempts in 5 sec interval - Result: more than 5000 freepage count are missed With patchset [3] and this patchset, I found that no freepage count are missed so that I conclude that problems are solved. These problems can be possible on memory hot remove users, although I didn't check it further. This patchset is based on linux-next-20140826. Please see individual patches for more information. Thanks. [1]: https://lkml.org/lkml/2014/7/4/79 [2]: lkml.org/lkml/2014/8/6/52 [3]: Aggressively allocate the pages on cma reserved memory https://lkml.org/lkml/2014/5/30/291 Joonsoo Kim (4): mm/page_alloc: fix incorrect isolation behavior by rechecking migratetype mm/page_alloc: add freepage on isolate pageblock to correct buddy list mm/page_alloc: move migratetype recheck logic to __free_one_page() mm/page_alloc: restrict max order of merging on isolated pageblock include/linux/mmzone.h |4 include/linux/page-isolation.h |8 mm/page_alloc.c| 28 +++- mm/page_isolation.c|2 ++ 4 files changed, 33 insertions(+), 9 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
On Tuesday 26 August 2014 09:50:25 Thierry Reding wrote: > On Tue, Aug 26, 2014 at 09:43:50AM +0200, Arnd Bergmann wrote: > > On Tuesday 26 August 2014 08:57:31 Thierry Reding wrote: > > > On Mon, Aug 25, 2014 at 01:01:52PM -0600, Stephen Warren wrote: > > > > On 08/18/2014 11:08 AM, Andrew Bresticker wrote: > > > [...] > > > > >+static int tegra_xusb_mbox_probe(struct platform_device *pdev) > > > > > > > > >+res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > > > >+if (!res) > > > > >+return -ENODEV; > > > > > > > > Should devm_request_mem_region() be called here to claim the region? > > > > > > > > >+mbox->regs = devm_ioremap_nocache(&pdev->dev, res->start, > > > > >+ resource_size(res)); > > > > >+if (!mbox->regs) > > > > >+return -ENOMEM; > > > > > > > > Is _nocache required? I don't see other drivers using it. I assume > > > > there's > > > > nothing special about the mbox registers. > > > > > > Most drivers should be using devm_ioremap_resource() which will use the > > > _nocache variant of devm_ioremap() when appropriate. Usually the region > > > will not be marked cacheable (IORESOURCE_CACHEABLE) and therefore be > > > remapped uncached. > > > > > > > Note that ioremap() and ioremap_nocache() are the same. We really shouldn't > > ever call ioremap_nocache(). > > Perhaps we should remove ioremap_nocache() in that case. Or ioremap(), > really, and keep only those variants that do what they claim to do. That would be good, but there are many instances of either one: arnd@wuerfel:/git/arm-soc$ git grep -w ioremap | wc 2156 13402 183732 arnd@wuerfel:/git/arm-soc$ git grep -w ioremap_nocache | wc 4852529 42955 FWIW, I just looked through all architectures and found three on which ioremap and ioremap_nocache are not the same, and ioremap defaults to cacheable: - OpenRISC so far only supports running in a simulator, so this is likely to be a bug that will get hit on actual hardware with MMIO. Jonas should probably look into this. - mn10300 has no MMU and doesn't really use ioremap, but it should still be fixed for PCI drivers using it on the one board that supports PCI. - cris seems to have been broken forever. > > devm_ioremap_resource() and pci_iomap() checking for IORESOURCE_CACHEABLE is > > rather silly, since it doesn't call ioremap_cache() in that case. > > Then that should be fixed. Yes. I'd suggest we just ignore that flag and always call ioremap here. When I checked this before, IORESOURCE_CACHEABLE only ever gets set for PCI ROM BARs, which we don't map into the kernel. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: fix warning from Sparse for socfpga
On Sel, 2014-08-26 at 10:04 +0200, Giuseppe CAVALLARO wrote: > > > > >> > >> patch should be for net-next > > Do you mean the patch need based on net-next git? > > yes I do. > > > I'm using linux-next git now. > > ok, can you signal it in the subject (e.g. [PATCH (net-next)] > This can help on reviewing and IIRC required by Maintainer too Sure, will do it in next revision. Thanks. Regards Ley Foon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regmap: Fix regcache debugfs initialization
On Sun, Aug 24, 2014 at 03:32:27PM +0200, Lars-Peter Clausen wrote:
> Commit 6cfec04bcc05 ("regmap: Separate regmap dev initialization") moved the
> regmap debugfs initialization after regcache initialization. This means
> that the regmap debugfs directory is not created yet when the cache
Applied, thanks.
signature.asc
Description: Digital signature
Re: [PATCH/RFC] hash: Let gcc decide how to multiply
David Miller writes: > From: Daniel Borkmann > Date: Mon, 25 Aug 2014 14:58:37 +0200 > >> On 08/25/2014 02:13 PM, Rasmus Villemoes wrote: >>> A 9+ years old comment in hash_64 says that gcc can't optimize >>> multiplication by GOLDEN_RATIO_PRIME_64. Well, compilers get smarter >>> and CPUs get faster all the time, so it is perhaps about time to >>> revisit that assumption. >> >> Seems fine by me, but Cc'ing a couple of others (as those you have >> Cc'ed haven't written that code :)). You might want to let your >> changes go via Andrew's tree, too, perhaps ... > > You need to test the code generation for a cpu where the multiply > instruction is more expensive than the shifts and adds. Yes, I should, but I'm afraid I can't. I only have x86 hardware, and even if I managed to set up some cross-compiler toolchain, I wouldn't know what CPUs to target. So I was hoping someone else could test this on appropriate platforms. Thanks, Rasmus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: ALPS - suppress message about 'Unknown touchpad'
Hi, On 08/25/2014 08:30 PM, Dmitry Torokhov wrote: > When we fail to match data returned by E7 and EC reports we state that we > found "Unknown ALPS touchpad" whereas it is most likely it is not ALPS > touchpad at all. Change wording a bit and reduce the message to debug so > that it does not litter users logs and confuse them. > > Reported-by: Paul Menzel > Signed-off-by: Dmitry Torokhov I noticed this too, and I agree that it is a confusing message: Acked-by: Hans de Goede Regards, Hans > --- > drivers/input/mouse/alps.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c > index a59a1a6..a956b98 100644 > --- a/drivers/input/mouse/alps.c > +++ b/drivers/input/mouse/alps.c > @@ -2234,8 +2234,8 @@ static int alps_identify(struct psmouse *psmouse, > struct alps_data *priv) > return 0; > } > > - psmouse_info(psmouse, > - "Unknown ALPS touchpad: E7=%3ph, EC=%3ph\n", e7, ec); > + psmouse_dbg(psmouse, > + "Likely not an ALPS touchpad: E7=%3ph, EC=%3ph\n", e7, ec); > > return -EINVAL; > } > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sound: pci: ctxfi: ctatc.c: printk replacement
At Tue, 26 Aug 2014 13:21:00 +0530,
Sudip Mukherjee wrote:
>
> On Tue, Aug 26, 2014 at 08:27:09AM +0200, Takashi Iwai wrote:
> > At Mon, 25 Aug 2014 23:26:52 +0530,
> > Sudip Mukherjee wrote:
> > >
> > > printk replaced ith corresponding pr_err
> > > fixed three broken user-visible strings
> > > fixed a checkpatch warning of space before new line
> >
> > Fixes are good, but is this the final patch for ctxfi?
> > If you're going to post another one, please fold them into a single
> > patch. All patches do basically the same job, so splitting patches
> > doesn't help much in such a case. Patches should be split logically.
> >
> > Also, if you fix broken strings, better to do it consistently to all
> > targeted strings, instead of picking up random ones.
> >
> >
> > thanks,
> >
> > Takashi
>
> Hi,
> I was posting them separately as i was thinking it will become a big patch.
> For the broken string , it was actually not random . I did it only for those
> string that were affected by my patch.
The worst thing by such a cleanup patch is unexpected regressions.
Usually it happens by a human error, typically wrong copy&paste or
wrong editing. So, a translation would be at best systematic, by
scripting. In that case, the size doesn't matter. It just does a
single task, and reviewers can concentrate on it.
After that, you can reformat the broken lines to single lines in
another patch for improving grep-ability. Again, this patch would do
only the single job, so the size doesn't matter much, too.
That being said, the most important point is to arrange your changes
logically.
thanks,
Takashi
> Anyways, I will send you a complete one for ctxfi.
>
> thanks
> sudip
>
> >
> > >
> > >
> > > Signed-off-by: Sudip Mukherjee
> > > ---
> > > sound/pci/ctxfi/ctatc.c | 23 ++-
> > > 1 file changed, 10 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/sound/pci/ctxfi/ctatc.c b/sound/pci/ctxfi/ctatc.c
> > > index af632bd..41597a8 100644
> > > --- a/sound/pci/ctxfi/ctatc.c
> > > +++ b/sound/pci/ctxfi/ctatc.c
> > > @@ -185,7 +185,7 @@ static unsigned int convert_format(snd_pcm_format_t
> > > snd_format)
> > > case SNDRV_PCM_FORMAT_FLOAT_LE:
> > > return SRC_SF_F32;
> > > default:
> > > - printk(KERN_ERR "ctxfi: not recognized snd format is %d \n",
> > > + pr_err("ctxfi: not recognized snd format is %d\n",
> > > snd_format);
> > > return SRC_SF_S16;
> > > }
> > > @@ -1282,7 +1282,7 @@ static int atc_identify_card(struct ct_atc *atc,
> > > unsigned int ssid)
> > > p = snd_pci_quirk_lookup_id(vendor_id, device_id, list);
> > > if (p) {
> > > if (p->value < 0) {
> > > - printk(KERN_ERR "ctxfi: "
> > > + pr_err("ctxfi: "
> > > "Device %04x:%04x is black-listed\n",
> > > vendor_id, device_id);
> > > return -ENOENT;
> > > @@ -1315,8 +1315,7 @@ int ct_atc_create_alsa_devs(struct ct_atc *atc)
> > > err = alsa_dev_funcs[i].create(atc, i,
> > > alsa_dev_funcs[i].public_name);
> > > if (err) {
> > > - printk(KERN_ERR "ctxfi: "
> > > -"Creating alsa device %d failed!\n", i);
> > > + pr_err("ctxfi: Creating alsa device %d failed!\n", i);
> > > return err;
> > > }
> > > }
> > > @@ -1332,7 +1331,7 @@ static int atc_create_hw_devs(struct ct_atc *atc)
> > >
> > > err = create_hw_obj(atc->pci, atc->chip_type, atc->model, &hw);
> > > if (err) {
> > > - printk(KERN_ERR "Failed to create hw obj!!!\n");
> > > + pr_err("Failed to create hw obj!!!\n");
> > > return err;
> > > }
> > > atc->hw = hw;
> > > @@ -1351,8 +1350,7 @@ static int atc_create_hw_devs(struct ct_atc *atc)
> > >
> > > err = rsc_mgr_funcs[i].create(atc->hw, &atc->rsc_mgrs[i]);
> > > if (err) {
> > > - printk(KERN_ERR "ctxfi: "
> > > -"Failed to create rsc_mgr %d!!!\n", i);
> > > + pr_err("ctxfi: Failed to create rsc_mgr %d!!!\n", i);
> > > return err;
> > > }
> > > }
> > > @@ -1399,7 +1397,7 @@ static int atc_get_resources(struct ct_atc *atc)
> > > err = daio_mgr->get_daio(daio_mgr, &da_desc,
> > > (struct daio **)&atc->daios[i]);
> > > if (err) {
> > > - printk(KERN_ERR "ctxfi: Failed to get DAIO "
> > > + pr_err("ctxfi: Failed to get DAIO "
> > > "resource %d!!!\n", i);
> > > return err;
> > > }
> > > @@ -1603,8 +1601,7 @@ static int atc_resume(struct ct_atc *atc)
> > > /* Do hardware resume. */
> > > err = atc_hw_resume(atc);
> > > if (err < 0) {
> > > - printk(KERN_ERR "ctxfi: pci_enable_device failed, "
> > > -"d
Re: [PATCH 1/3] Adding Skyworks SKY81452 MFD driver
On Mon, 25 Aug 2014, Gyungoh Yoo wrote:
> On Thu, Aug 21, 2014 at 10:45:02AM +0100, Lee Jones wrote:
> > When you send patch-sets, you should send them connected to one
> > another AKA threaded. That way, when we're reviewing we can look at
> > the other patches in the set for reference. See the man page for `git
> > send-email` for details.
> >
> >
> >
> > > Signed-off-by: Gyungoh Yoo
> > > ---
[...]
> > > +static int sky81452_register_devices(struct device *dev,
> > > + const struct sky81452_platform_data *pdata)
> > > +{
> > > + struct mfd_cell cells[] = {
> > > + {
> > > + .name = "sky81452-bl",
> > > + .platform_data = pdata->bl_pdata,
> > > + .pdata_size = sizeof(*pdata->bl_pdata),
> >
> > Have you tested this with DT?
> >
> > You're not passing the compatible string and not using
> > of_platform_populate() so I'm struggling to see how it would work
> > properly.
>
> sky81452-bl and regulator-sky81452 is parsing the information
> in regulator node of its parent node. So I thought these 2 drivers
> don't need compatible attribute. That is what it didn't have
> compatible string.
> Is is mandatory that all drivers should have compatible attribute?
How do they obtain their DT nodes?
[...]
> > > + return mfd_add_devices(dev, -1, cells, ARRAY_SIZE(cells),
> > > + NULL, 0, NULL);
> >
> > This doesn't really need to be in a function of its own. Please put
> > it in .probe(). Also check for the return value and present the user
> > with an error message if it fails.
>
> I think this need to be, in case of !CONFIG_OF.
> Can you please explain more in details?
Then how to you obtain the shared register map you created?
[...]
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/6] perf: add ability to sample machine state on interrupt
Hi Stephane,
On Mon, 18 Aug 2014 01:18:15 +0200, Stephane Eranian wrote:
> Enable capture of interrupted machine state for each
> sample.
>
> Registers to sample are passed per event in the
> sample_regs_intr bitmask.
>
> To sample interrupt machine state, the
> PERF_SAMPLE_INTR_REGS must be passed in
> sample_type.
>
> The list of available registers is arch
> dependent and provided by asm/perf_regs.h
>
> Registers are laid out as u64 in the order
> of the bit order of sample_intr_regs.
[SNIP]
> @@ -334,6 +335,15 @@ struct perf_event_attr {
>
> /* Align to u64. */
> __u32 __reserved_2;
> + /*
> + * Defines set of regs to dump for each sample
> + * state captured on:
> + * - precise = 0: PMU interrupt
> + * - precise > 0: sampled instruction
> + *
> + * See asm/perf_regs.h for details.
> + */
> + __u64 sample_regs_intr;
> };
Hmm.. this increases the size of perf_event_attr. It seems you need to
also define PERF_ATTR_SIZE_VER4 and update attr_file_abi_sizes.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 4/6] phy: remove the old lookup method
The users of the old method are now converted to the new one.
Signed-off-by: Heikki Krogerus
Tested-by: Vivek Gautam
---
drivers/phy/phy-bcm-kona-usb2.c | 2 +-
drivers/phy/phy-berlin-sata.c| 2 +-
drivers/phy/phy-core.c | 45 +++-
drivers/phy/phy-exynos-dp-video.c| 2 +-
drivers/phy/phy-exynos-mipi-video.c | 2 +-
drivers/phy/phy-exynos5-usbdrd.c | 3 +--
drivers/phy/phy-exynos5250-sata.c| 2 +-
drivers/phy/phy-hix5hd2-sata.c | 2 +-
drivers/phy/phy-miphy365x.c | 2 +-
drivers/phy/phy-mvebu-sata.c | 2 +-
drivers/phy/phy-omap-usb2.c | 2 +-
drivers/phy/phy-qcom-apq8064-sata.c | 3 +--
drivers/phy/phy-qcom-ipq806x-sata.c | 3 +--
drivers/phy/phy-samsung-usb2.c | 3 +--
drivers/phy/phy-spear1310-miphy.c| 2 +-
drivers/phy/phy-spear1340-miphy.c| 2 +-
drivers/phy/phy-sun4i-usb.c | 2 +-
drivers/phy/phy-ti-pipe3.c | 2 +-
drivers/phy/phy-twl4030-usb.c| 4 +---
drivers/phy/phy-xgene.c | 2 +-
drivers/pinctrl/pinctrl-tegra-xusb.c | 4 ++--
include/linux/phy/phy.h | 38 --
22 files changed, 28 insertions(+), 103 deletions(-)
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
index 894fe74..3463983 100644
--- a/drivers/phy/phy-bcm-kona-usb2.c
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -117,7 +117,7 @@ static int bcm_kona_usb2_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, phy);
- gphy = devm_phy_create(dev, NULL, &ops, NULL);
+ gphy = devm_phy_create(dev, NULL, &ops);
if (IS_ERR(gphy))
return PTR_ERR(gphy);
diff --git a/drivers/phy/phy-berlin-sata.c b/drivers/phy/phy-berlin-sata.c
index 5c3a042..010c463 100644
--- a/drivers/phy/phy-berlin-sata.c
+++ b/drivers/phy/phy-berlin-sata.c
@@ -239,7 +239,7 @@ static int phy_berlin_sata_probe(struct platform_device
*pdev)
if (!phy_desc)
return -ENOMEM;
- phy = devm_phy_create(dev, NULL, &phy_berlin_sata_ops, NULL);
+ phy = devm_phy_create(dev, NULL, &phy_berlin_sata_ops);
if (IS_ERR(phy)) {
dev_err(dev, "failed to create PHY %d\n", phy_id);
return PTR_ERR(phy);
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 67a8c726..834b337 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -55,36 +55,6 @@ static int devm_phy_match(struct device *dev, void *res,
void *match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *port)
-{
- unsigned int count;
- struct phy *phy;
- struct device *dev;
- struct phy_consumer *consumers;
- struct class_dev_iter iter;
-
- class_dev_iter_init(&iter, phy_class, NULL, NULL);
- while ((dev = class_dev_iter_next(&iter))) {
- phy = to_phy(dev);
-
- if (!phy->init_data)
- continue;
- count = phy->init_data->num_consumers;
- consumers = phy->init_data->consumers;
- while (count--) {
- if (!strcmp(consumers->dev_name, dev_name(device)) &&
- !strcmp(consumers->port, port)) {
- class_dev_iter_exit(&iter);
- return phy;
- }
- consumers++;
- }
- }
-
- class_dev_iter_exit(&iter);
- return ERR_PTR(-ENODEV);
-}
-
/**
* phy_register_lookup() - register PHY/device association
* @pl: association to register
@@ -210,10 +180,6 @@ static struct phy *phy_find(struct device *dev, const char
*con_id)
}
class_dev_iter_exit(&iter);
}
-
- /* fall-back to the old lookup method for now */
- if (IS_ERR(phy))
- phy = phy_lookup(dev, con_id);
return phy;
}
@@ -721,13 +687,11 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
* @dev: device that is creating the new phy
* @node: device node of the phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Called to create a phy using phy framework.
*/
struct phy *phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data)
+ const struct phy_ops *ops)
{
int ret;
int id;
@@ -765,7 +729,6 @@ struct phy *phy_create(struct device *dev, struct
device_node *node,
phy->dev.of_node = node ?: dev->of_node;
phy->id = id;
phy->ops = ops;
- phy->init_data = init_data;
ret = dev_set_name(&phy->dev, "phy-%s.%d", dev_name(dev), id);
if (ret)
@@ -800,7 +7
[PATCHv2] ARM: debug: uncompress debug support for omap2plus
From: Sahara Since OMAP low-level debug code places data in the .data section, The symbol DEBUG_UNCOMPRESS was defined with !DEBUG_OMAP2PLUS_UART. This patch removes the part using data section in debug/omap2plus.S, so DEBUG_UNCOMPRESS is now available on OMAP system. Signed-off-by: Sahara Tested-by: Afzal Mohammed (on am335x beagle bone white) --- arch/arm/Kconfig.debug |3 +- arch/arm/include/debug/omap2plus.S | 96 ++-- 2 files changed, 27 insertions(+), 72 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index b11ad54..c0ad3e4 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -1220,8 +1220,7 @@ config DEBUG_UART_8250_FLOW_CONTROL config DEBUG_UNCOMPRESS bool depends on ARCH_MULTIPLATFORM || ARCH_MSM || PLAT_SAMSUNG - default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \ -(!DEBUG_TEGRA_UART || !ZBOOT_ROM) + default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT_ROM) help This option influences the normal decompressor output for multiplatform kernels. Normally, multiplatform kernels disable diff --git a/arch/arm/include/debug/omap2plus.S b/arch/arm/include/debug/omap2plus.S index 6d867ae..0b7ec89 100644 --- a/arch/arm/include/debug/omap2plus.S +++ b/arch/arm/include/debug/omap2plus.S @@ -58,115 +58,71 @@ #define UART_OFFSET(addr) ((addr) & 0x00ff) - .pushsection .data -omap_uart_phys:.word 0 -omap_uart_virt:.word 0 -omap_uart_lsr: .word 0 - .popsection - .macro addruart, rp, rv, tmp - /* Use omap_uart_phys/virt if already configured */ -10:adr \rp, 99f@ get effective addr of 99f - ldr \rv, [\rp] @ get absolute addr of 99f - sub \rv, \rv, \rp @ offset between the two - ldr \rp, [\rp, #4] @ abs addr of omap_uart_phys - sub \tmp, \rp, \rv @ make it effective - ldr \rp, [\tmp, #0] @ omap_uart_phys - ldr \rv, [\tmp, #4] @ omap_uart_virt - cmp \rp, #0 @ is port configured? - cmpne \rv, #0 - bne 100f@ already configured - /* Configure the UART offset from the phys/virt base */ -#ifdef CONFIG_DEBUG_OMAP2UART1 +#if defined(CONFIG_DEBUG_OMAP2UART1) mov \rp, #UART_OFFSET(OMAP2_UART1_BASE) @ omap2/3/4 b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP2UART2 +#elif defined(CONFIG_DEBUG_OMAP2UART2) mov \rp, #UART_OFFSET(OMAP2_UART2_BASE) @ omap2/3/4 b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP2UART3 +#elif defined(CONFIG_DEBUG_OMAP2UART3) mov \rp, #UART_OFFSET(OMAP2_UART3_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP3UART3 +#elif defined(CONFIG_DEBUG_OMAP3UART3) mov \rp, #UART_OFFSET(OMAP3_UART1_BASE) add \rp, \rp, #0x00fb add \rp, \rp, #0x6000 @ OMAP3_UART3_BASE b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP4UART3 +#elif defined(CONFIG_DEBUG_OMAP4UART3) mov \rp, #UART_OFFSET(OMAP4_UART3_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP3UART4 +#elif defined(CONFIG_DEBUG_OMAP3UART4) mov \rp, #UART_OFFSET(OMAP3_UART1_BASE) add \rp, \rp, #0x00fb add \rp, \rp, #0x00028000 @ OMAP3_UART4_BASE b 98f -#endif -#ifdef CONFIG_DEBUG_OMAP4UART4 +#elif defined(CONFIG_DEBUG_OMAP4UART4) mov \rp, #UART_OFFSET(OMAP4_UART4_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_TI81XXUART1 +#elif defined(CONFIG_DEBUG_TI81XXUART1) mov \rp, #UART_OFFSET(TI81XX_UART1_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_TI81XXUART2 +#elif defined(CONFIG_DEBUG_TI81XXUART2) mov \rp, #UART_OFFSET(TI81XX_UART2_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_TI81XXUART3 +#elif defined(CONFIG_DEBUG_TI81XXUART3) mov \rp, #UART_OFFSET(TI81XX_UART3_BASE) b 98f -#endif -#ifdef CONFIG_DEBUG_AM33XXUART1 +#elif defined(CONFIG_DEBUG_AM33XXUART1) ldr \rp, =AM33XX_UART1_BASE and \rp, \rp, #0x00ff b 97f -#endif -#ifdef CONFIG_DEBUG_ZOOM_UART +#elif defined(CONFIG_DEBUG_ZOOM_UART) ldr \rp, =ZOOM_UART_BASE - str \rp, [\tmp, #0] @ omap_uart_phys - ldr \rp, =ZOOM_UART_VIRT - str \rp, [\tmp, #4] @ omap_uart_virt - mov \rp, #(UART_LSR << ZOOM_PORT_SHIFT) -
[PATCH v2] DRBG: fix maximum value checks on 32 bit systems
The maximum values for additional input string or generated blocks is
larger than 1<<32. To ensure a sensible value on 32 bit systems, return
SIZE_MAX on 32 bit systems. This value is lower than the maximum
allowed values defined in SP800-90A. The standard allow lower maximum
values, but not larger values.
SIZE_MAX - 1 is used for drbg_max_addtl to allow
drbg_healthcheck_sanity to check the enforcement of the variable
without wrapping.
Reported-by: Stephen Rothwell
Reported-by: kbuild test robot
Signed-off-by: Stephan Mueller
---
include/crypto/drbg.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index 3d8e73a..5186f75 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -154,13 +154,26 @@ static inline size_t drbg_max_request_bytes(struct
drbg_state *drbg)
static inline size_t drbg_max_addtl(struct drbg_state *drbg)
{
/* SP800-90A requires 2**35 bytes additional info str / pers str */
+#if (__BITS_PER_LONG == 32)
+ /*
+* SP800-90A allows smaller maximum numbers to be returned -- we
+* return SIZE_MAX - 1 to allow the verification of the enforcement
+* of this value in drbg_healthcheck_sanity.
+*/
+ return (SIZE_MAX - 1);
+#else
return (1UL<<35);
+#endif
}
static inline size_t drbg_max_requests(struct drbg_state *drbg)
{
/* SP800-90A requires 2**48 maximum requests before reseeding */
+#if (__BITS_PER_LONG == 32)
+ return SIZE_MAX;
+#else
return (1UL<<48);
+#endif
}
/*
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: compressed/head.S: use addruart properly
From: Sahara
This patch fixes compile error in compressed/head.S, when DEBUG
is defined. Since addruart macro accepts 3 params, rp, rv, and tmp,
loadsp macro also needs to be fixed. Or you will meet the following
error messages:
Error: ARM register expected -- `mov ,#(5<<1)'
Error: shift expression expected -- `add r3,r3,'
Signed-off-by: Sahara
---
arch/arm/boot/compressed/head.S | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 413fd94..9f1a6cd 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -24,19 +24,19 @@
#if defined(CONFIG_DEBUG_ICEDCC)
#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K) || defined(CONFIG_CPU_V7)
- .macro loadsp, rb, tmp
+ .macro loadsp, rp, rv, tmp
.endm
.macro writeb, ch, rb
mcr p14, 0, \ch, c0, c5, 0
.endm
#elif defined(CONFIG_CPU_XSCALE)
- .macro loadsp, rb, tmp
+ .macro loadsp, rp, rv, tmp
.endm
.macro writeb, ch, rb
mcr p14, 0, \ch, c8, c0, 0
.endm
#else
- .macro loadsp, rb, tmp
+ .macro loadsp, rp, rv, tmp
.endm
.macro writeb, ch, rb
mcr p14, 0, \ch, c1, c0, 0
@@ -52,17 +52,17 @@
.endm
#if defined(CONFIG_ARCH_SA1100)
- .macro loadsp, rb, tmp
- mov \rb, #0x8000@ physical base address
+ .macro loadsp, rp, rv, tmp
+ mov \rp, #0x8000@ physical base address
#ifdef CONFIG_DEBUG_LL_SER3
- add \rb, \rb, #0x0005 @ Ser3
+ add \rp, \rp, #0x0005 @ Ser3
#else
- add \rb, \rb, #0x0001 @ Ser1
+ add \rp, \rp, #0x0001 @ Ser1
#endif
.endm
#else
- .macro loadsp, rb, tmp
- addruart \rb, \tmp
+ .macro loadsp, rp, rv, tmp
+ addruart \rp, \rv, \tmp
.endm
#endif
#endif
@@ -1209,7 +1209,7 @@ phex: adr r3, phexbuf
b 1b
@ puts corrupts {r0, r1, r2, r3}
-puts: loadsp r3, r1
+puts: loadsp r3, r2, r1
1: ldrbr2, [r0], #1
teq r2, #0
moveq pc, lr
@@ -1225,9 +1225,9 @@ puts: loadsp r3, r1
mov pc, lr
@ putc corrupts {r0, r1, r2, r3}
putc:
+ loadsp r3, r2, r1
mov r2, r0
mov r0, #0
- loadsp r3, r1
b 2b
@ memdump corrupts {r0, r1, r2, r3, r10, r11, r12, lr}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] Documentation/scheduler/sched-deadline.txt: Rewrite section 4 intro
On 21/08/14 14:46, Ingo Molnar wrote: > * Juri Lelli wrote: > >> Section 4 intro was still describing the old interface. Rewrite it. >> >> Signed-off-by: Juri Lelli >> Signed-off-by: Luca Abeni >> Cc: Randy Dunlap >> Cc: Peter Zijlstra >> Cc: Ingo Molnar >> Cc: Henrik Austad >> Cc: Dario Faggioli >> Cc: Juri Lelli >> Cc: linux-...@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> --- >> Documentation/scheduler/sched-deadline.txt | 49 >> +++--- >> 1 file changed, 24 insertions(+), 25 deletions(-) >> >> diff --git a/Documentation/scheduler/sched-deadline.txt >> b/Documentation/scheduler/sched-deadline.txt >> index dce6d63..8372c3d 100644 >> --- a/Documentation/scheduler/sched-deadline.txt >> +++ b/Documentation/scheduler/sched-deadline.txt >> @@ -165,39 +165,38 @@ CONTENTS >> >> In order for the -deadline scheduling to be effective and useful, it is >> important to have some method to keep the allocation of the available CPU >> - bandwidth to the tasks under control. >> - This is usually called "admission control" and if it is not performed at >> all, >> - no guarantee can be given on the actual scheduling of the -deadline tasks. >> - >> - Since when RT-throttling has been introduced each task group has a >> bandwidth >> - associated, calculated as a certain amount of runtime over a period. >> - Moreover, to make it possible to manipulate such bandwidth, >> readable/writable >> - controls have been added to both procfs (for system wide settings) and >> cgroupfs >> - (for per-group settings). >> - Therefore, the same interface is being used for controlling the bandwidth >> - distrubution to -deadline tasks. >> - >> - However, more discussion is needed in order to figure out how we want to >> manage >> - SCHED_DEADLINE bandwidth at the task group level. Therefore, SCHED_DEADLINE >> - uses (for now) a less sophisticated, but actually very sensible, mechanism >> to >> - ensure that a certain utilization cap is not overcome per each root_domain. >> - >> - Another main difference between deadline bandwidth management and >> RT-throttling >> + bandwidth to the tasks under control. This is usually called "admission >> + control" and if it is not performed at all, no guarantee can be given on >> + the actual scheduling of the -deadline tasks. >> + >> + The interface used to control the fraction of CPU bandwidth that can be >> + allocated to -deadline tasks is similar to the one already used for -rt >> + tasks with real-time group scheduling (a.k.a. RT-throttling - see >> + Documentation/scheduler/sched-rt-group.txt), and is based on readable/ >> + writable control files located in procfs (for system wide settings). >> + Notice that per-group settings (controlled through cgroupfs) are still not >> + defined for -deadline tasks, because more discussion is needed in order to >> + figure out how we want to manage SCHED_DEADLINE bandwidth at the task group >> + level. >> + >> + A main difference between deadline bandwidth management and RT-throttling >> is that -deadline tasks have bandwidth on their own (while -rt ones >> don't!), >> and thus we don't need an higher level throttling mechanism to enforce the > > s/an higher/a higher > >> - desired bandwidth. >> + desired bandwidth. Therefore, using this simple interface, we can put a cap > > s/interface, we/interface we > >> + on total utilization of -deadline tasks (i.e., \Sum (runtime_i / period_i) >> < >> + some_desired_value). > Fixed. Thanks a lot, - Juri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/5] MFD: RK808: Add new mfd driver for RK808
On Mon, 25 Aug 2014, Doug Anderson wrote:
> On Mon, Aug 25, 2014 at 6:31 AM, Chris Zhong wrote:
> > The RK808 chip is a power management IC for multimedia and handheld
> > devices. It contains the following components:
> >
> > - Regulators
> > - RTC
> >
> > The RK808 core driver is registered as a platform driver and provides
> > communication through I2C with the host device for the different
> > components.
> >
> > Signed-off-by: Chris Zhong
>
> You need a Signed-off-by: Zhang Qing
>
> > ---
[...]
> > +static struct rk808 *g_rk808;
>
> I think Lee's "Grim" comment here was that prefixing globals with "g_"
> is not consistent with the Linux coding style. Just remove the "g_".
That and the seemingly unavoidable use of a global pointer.
[...]
> > +static const struct i2c_device_id rk808_ids[] = {
> > +{ "rk808", 0 },
>
> I think Lee wanted the above to be:
>
>{ "rk808", },
Right, but the ',' is now superfluous.
[...]
> I didn't do a thorough review, just compared to Lee's old feedback.
> Maybe a good idea to get in the habit to responding to others comments
> with "Done" so others know you have addressed each comment?
Please only do this locally or in your head. Reading replies to
reviews containing only a break-down of what has been fixed is a waste
of everyone's time. If/when replying to comments/observations that
you do _not_ agree with, please snip out all of the ones that you _do_
agree with.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/5] MFD: RK808: Add new mfd driver for RK808
On Tue, 26 Aug 2014, Chris Zhong wrote:
> On 08/26/2014 04:44 AM, Doug Anderson wrote:
> >On Mon, Aug 25, 2014 at 6:31 AM, Chris Zhong wrote:
[...]
> >You need a Signed-off-by: Zhang Qing
>
> Done
[...]
> >I think Lee's "Grim" comment here was that prefixing globals with "g_"
> >is not consistent with the Linux coding style. Just remove the "g_".
>
> Done
[...]
> >{ RK808_BUCK3_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_150MA },
> >
> >instead of:
> >
> >{RK808_BUCK3_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_150MA},
>
> Done
[...]
> >nit: add spacing so that VB_LO_SEL_3500MV lines up under VB_LO_ACT
>
> Done
[...]
> >I think Lee wanted the above to be:
> >
> >{ "rk808", },
>
> Done
[...]
> >I think Lee wanted you to remove ".owner = THIS_MODULE"
>
> Done
[...]
You've just spammed 10(00)'s of people with an email that contains
zero useful content.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c documentation: rename variable "register" to "reg"
The example code provided with the i2c device interface documentation
won't compile since it uses the reserved word "register" to name a
variable.
The compiler fails with this error message:
error: expected identifier or '(' before '=' token
__u8 register = 0x20; /* Device register to access */
^
Rename the variable "register" to simply "reg"
in the example code.
Signed-off-by: Jose Alarcon Roldan
---
Documentation/i2c/dev-interface | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index 3e742ba..f8b1e50 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -57,12 +57,12 @@ Well, you are all set up now. You can now use
SMBus commands or plain
I2C to communicate with your device. SMBus commands are preferred if
the device supports them. Both are illustrated below.
- __u8 register = 0x10; /* Device register to access */
+ __u8 reg = 0x10; /* Device register to access */
__s32 res;
char buf[10];
/* Using SMBus commands */
- res = i2c_smbus_read_word_data(file, register);
+ res = i2c_smbus_read_word_data(file, reg);
if (res < 0) {
/* ERROR HANDLING: i2c transaction failed */
} else {
@@ -70,8 +70,8 @@ the device supports them. Both are illustrated below.
}
/* Using I2C Write, equivalent of
- i2c_smbus_write_word_data(file, register, 0x6543) */
- buf[0] = register;
+ i2c_smbus_write_word_data(file, reg, 0x6543) */
+ buf[0] = reg;
buf[1] = 0x43;
buf[2] = 0x65;
if (write(file, buf, 3) ! =3) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding
wrote:
> On Mon, Aug 25, 2014 at 08:08:59AM -0500, Jon Loeliger wrote:
> > >
> >
> > > Anyway, instead of going back and forth between "deferred probe is good"
> > > and "deferred probe is bad", how about we do something useful now and
> > > concentrate on how to make use of the information we have in DT with the
> > > goal to reduce the number of cases where deferred probing is required?
> >
> > Good idea.
> >
> > The proposal on the table is to allow the probe code
> > to make a topological sort of the devices based on
> > dependency information either implied, explicitly stated
> > or both. That is likely a fundamentally correct approach.
> >
> > I believe some of the issues that need to be resolved are:
> >
> > 1) What constitutes a dependency?
> > 2) How is that dependency expressed?
> > 3) How do we add missing dependencies?
> > 4) Backward compatability problems.
> >
> > There are other questions, of course. Is it a topsort
> > per bus? Are there required "early devices"? Should
> > the inter-node dependencies be expressed at each node,
> > or in a separate hierarchy within the DTS? Others.
>
> I think Grant already objected to the idea of explicitly adding
> dependency information into the device tree sources. Rather, if I
> understand correctly, we should be using the information readily
> available (phandle references) as much as possible before resorting to
> additional properties.
My objection is primarily around the concern that the dependency data
will get stale if firmware modifies the tree or that the kernel will
break when by relying on incorrect dependency information.
If the kernel can handle incorrect dependencies gracefully (like falling
back to deferred probe) then we can consider additional properties.
> So far we've been operating under the assumption that a dependency is
> modeled as a phandle reference and that the dependent would contain the
> phandle reference to the dependency. That's for example how clocks and
> regulators (to name only a few) work. A simplified example would look
> like this:
>
> clock: clock@... {
> ...
> #clock-cells = <1>;
> ...
> };
>
> pmic: pmic@... {
> regulators {
> vdd_foo: ldo0 {
> ...
> };
>
> vdd_bar: ldo1 {
> ...
> };
> };
>
> device@... {
> vdd-supply = <&vdd_foo>;
> clocks = <&clock 0>;
> };
>
> device@... {
> vdd-supply = <&vdd_bar>;
> clocks = <&clock 1>;
> };
>
> There are somewhat standardized bindings for the above and especially
> for bindings of the type that clocks implement this is trivial. We can
> simply iterate over each (phandle, specifier) tuple and check that the
> corresponding clock provider can be resolved (which typically means that
> it's been registered with the common clock framework).
>
> For regulators (and regulator-like bindings) the problem is somewhat
> more difficult because they property names are not standardized. One way
> to solve this would be to look for property names with a -supply suffix,
> but that could obviously lead to false positives. One alternative that I
> think could eliminate this would be to explicitly list dependencies in
> drivers. This would allow core code to step through such a list and
> resolve the (phandle, specifier) tuples.
False positives and negatives may not actually be a problem. It is
suboptimal, certainly, but it shouldn't outright break the kernel.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] fuse: wait for end of IO on release (v2)
There are two types of I/O activity that can be "in progress" at the time
of fuse_release() execution: asynchronous read-ahead and write-back. The
patch ensures that they are completed before fuse_release_common sends
FUSE_RELEASE to userspace.
So far as fuse_release() waits for end of async I/O, its callbacks
(fuse_readpages_end and fuse_writepage_finish) calling fuse_file_put cannot
be the last holders of fuse file anymore. To emphasize the fact, the patch
replaces fuse_file_put with __fuse_file_put there.
Changed in v2 (thanks to Miklos):
- removed redundant locking around __fuse_file_put()
Signed-off-by: Maxim Patlasov
---
fs/fuse/file.c | 71
1 file changed, 66 insertions(+), 5 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 7723b3f..8713e62 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -149,6 +149,17 @@ static void fuse_file_put(struct fuse_file *ff, bool sync)
}
}
+/*
+ * Asynchronous callbacks may use it instead of fuse_file_put() because
+ * we guarantee that they are never last holders of ff. Hitting BUG() below
+ * will make clear any violation of the guarantee.
+ */
+static void __fuse_file_put(struct fuse_file *ff)
+{
+ if (atomic_dec_and_test(&ff->count))
+ BUG();
+}
+
int fuse_do_open(struct fuse_conn *fc, u64 nodeid, struct file *file,
bool isdir)
{
@@ -279,6 +290,11 @@ static void fuse_prepare_release(struct fuse_file *ff, int
flags, int opcode)
req->in.args[0].value = inarg;
}
+static bool must_release_synchronously(struct fuse_file *ff)
+{
+ return ff->open_flags & FOPEN_SYNC_RELEASE;
+}
+
void fuse_release_common(struct file *file, int opcode)
{
struct fuse_file *ff;
@@ -302,6 +318,13 @@ void fuse_release_common(struct file *file, int opcode)
req->misc.release.path = file->f_path;
/*
+* No more in-flight asynchronous READ or WRITE requests if
+* fuse file release is synchronous
+*/
+ if (must_release_synchronously(ff))
+ BUG_ON(atomic_read(&ff->count) != 1);
+
+ /*
* Normally this will send the RELEASE request, however if
* some asynchronous READ or WRITE requests are outstanding,
* the sending will be delayed.
@@ -321,11 +344,34 @@ static int fuse_open(struct inode *inode, struct file
*file)
static int fuse_release(struct inode *inode, struct file *file)
{
struct fuse_conn *fc = get_fuse_conn(inode);
+ struct fuse_file *ff = file->private_data;
/* see fuse_vma_close() for !writeback_cache case */
if (fc->writeback_cache)
write_inode_now(inode, 1);
+ if (must_release_synchronously(ff)) {
+ struct fuse_inode *fi = get_fuse_inode(inode);
+
+ /*
+* Must remove file from write list. Otherwise it is possible
+* this file will get more writeback from another files
+* rerouted via write_files.
+*/
+ spin_lock(&ff->fc->lock);
+ list_del_init(&ff->write_entry);
+ spin_unlock(&ff->fc->lock);
+
+ wait_event(fi->page_waitq, atomic_read(&ff->count) == 1);
+
+ /*
+* spin_unlock_wait(&ff->fc->lock) would be natural here to
+* wait for threads just released ff to leave their critical
+* sections. But taking spinlock is the first thing
+* fuse_release_common does, so that this is unnecessary.
+*/
+ }
+
fuse_release_common(file, FUSE_RELEASE);
/* return value is ignored by VFS */
@@ -823,8 +869,15 @@ static void fuse_readpages_end(struct fuse_conn *fc,
struct fuse_req *req)
unlock_page(page);
page_cache_release(page);
}
- if (req->ff)
- fuse_file_put(req->ff, false);
+ if (req->ff) {
+ if (must_release_synchronously(req->ff)) {
+ struct fuse_inode *fi = get_fuse_inode(req->inode);
+
+ __fuse_file_put(req->ff);
+ wake_up(&fi->page_waitq);
+ } else
+ fuse_file_put(req->ff, false);
+ }
}
struct fuse_fill_data {
@@ -851,6 +904,7 @@ static void fuse_send_readpages(struct fuse_fill_data *data)
if (fc->async_read) {
req->ff = fuse_file_get(ff);
req->end = fuse_readpages_end;
+ req->inode = data->inode;
fuse_request_send_background(fc, req);
} else {
fuse_request_send(fc, req);
@@ -1502,7 +1556,7 @@ static void fuse_writepage_free(struct fuse_conn *fc,
struct fuse_req *req)
for (i = 0; i < req->num_pages; i++)
__free_page(req->pages[i]);
- if (req->ff)
+ if (req->ff && !must_release_synchronously(req->ff))
[Bugfix] x86, irq: Fix bug in setting IOAPIC pin attributes
On startup, IOAPIC driver preallocates IRQ descriptors and programs IOAPIC pins with default level and polarity attributes for all legacy IRQs. Later legacy IRQ users may fail to set IOAPIC pin attributes if the requested attributes conflicts with the default IOAPIC pin attributes. So change mp_irqdomain_map() to allow the first legacy IRQ user to reprogram IOAPIC pin with different attributes. Signed-off-by: Jiang Liu --- arch/x86/kernel/apic/io_apic.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index 29290f554e79..66c2700c9f83 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -3896,7 +3896,15 @@ int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq, info->polarity = 1; } info->node = NUMA_NO_NODE; - info->set = 1; + + /* +* setup_IO_APIC_irqs() programs all legacy IRQs with default +* trigger and polarity attirbutes. Don't set the flag for that +* case so the first legacy IRQ user could reprogram the pin +* with real trigger and polarity attributes. +*/ + if (virq >= nr_legacy_irqs() || info->count) + info->set = 1; } set_io_apic_irq_attr(&attr, ioapic, hwirq, info->trigger, info->polarity); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems
On Tue, Aug 26, 2014 at 10:29:45AM +0200, Stephan Mueller wrote: > The maximum values for additional input string or generated blocks is > larger than 1<<32. To ensure a sensible value on 32 bit systems, return > SIZE_MAX on 32 bit systems. This value is lower than the maximum > allowed values defined in SP800-90A. The standard allow lower maximum > values, but not larger values. > > SIZE_MAX - 1 is used for drbg_max_addtl to allow > drbg_healthcheck_sanity to check the enforcement of the variable > without wrapping. This is really ugly but OK. However, I'm not sure how the sanity check ever worked. It would appear that the drbg_generate call in drbg_healthcheck_sanity should always fail because you explicitly set addtl->len to drbg_max_addtl + 1, which should trigger the "DRBG: additional information string too long" error, no? Obviously it's working for you but I'd like to understand why it's working and whether it'll continue to work. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix faulty logic in the case of recursive printk
On Sun 24-08-14 12:01:36, Patrick Palka wrote:
> We shouldn't set text_len in the code path that detects printk recursion
> because text_len corresponds to the length of the string inside textbuf.
> A few lines down from the line
>
> text_len = strlen(recursion_msg);
>
> is the line
>
> text_len += vscnprintf(text + text_len, ...);
>
> So if printk detects recursion, it sets text_len to 29 and logs an
> error. Then the message supplied by the caller of printk is stored
> inside textbuf but offset by 29 bytes. This means that the output of
> the recursive call to printk will contain 29 bytes of garbage in front
> of it.
>
> This defect is caused by commit 458df9fd ("printk: remove separate
> printk_sched buffers and use printk buf instead") which turned
>
> text_len = vscnprintf(text + text_len, ...);
>
> into
>
> text_len += vscnprintf(text + text_len, ...);
>
> To fix this, this patch avoids setting text_len when logging the printk
> recursion error. This patch also performs a couple of local
> micro-optimizations (use unlikely() and ARRAY_SIZE()).
Thanks for spotting this! Just one nit below:
> Signed-off-by: Patrick Palka
> ---
> kernel/printk/printk.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index e04c455..c101ec2 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1665,15 +1665,15 @@ asmlinkage int vprintk_emit(int facility, int level,
> raw_spin_lock(&logbuf_lock);
> logbuf_cpu = this_cpu;
>
> - if (recursion_bug) {
> + if (unlikely(recursion_bug)) {
> static const char recursion_msg[] =
> "BUG: recent printk recursion!";
>
> recursion_bug = 0;
> - text_len = strlen(recursion_msg);
> /* emit KERN_CRIT message */
> printed_len += log_store(0, 2, LOG_PREFIX|LOG_NEWLINE, 0,
> - NULL, 0, recursion_msg, text_len);
> + NULL, 0, recursion_msg,
> + ARRAY_SIZE(recursion_msg) - 1);
I'd prefer to keep using strlen(recursion_msg). It is more obvious what
it does and is more futureproof.
Honza
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote: > On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding > wrote: [...] > > There are somewhat standardized bindings for the above and especially > > for bindings of the type that clocks implement this is trivial. We can > > simply iterate over each (phandle, specifier) tuple and check that the > > corresponding clock provider can be resolved (which typically means that > > it's been registered with the common clock framework). > > > > For regulators (and regulator-like bindings) the problem is somewhat > > more difficult because they property names are not standardized. One way > > to solve this would be to look for property names with a -supply suffix, > > but that could obviously lead to false positives. One alternative that I > > think could eliminate this would be to explicitly list dependencies in > > drivers. This would allow core code to step through such a list and > > resolve the (phandle, specifier) tuples. > > False positives and negatives may not actually be a problem. It is > suboptimal, certainly, but it shouldn't outright break the kernel. There could be cases where some random integer in a cell could be interpreted as a phandle and resolve to a struct device_node. I suppose it might be unlikely, but not impossible, that the device_node could even match a device in the correct subsystem and you'd get a wrong dependency. Granted, a wrong dependency may not be catastrophic in that it won't lead to a crash, but it could lead to various kinds of weirdness and hard to diagnose problems. Thierry pgpRS_pcNlY8b.pgp Description: PGP signature
Re: [PATCH] ARM: errata: Workaround for Cortex-A12 erratum 818325
Hi Russell, I'd value your feedback on this if you have a moment. I think this will need by rk3288 soc. Thanks On 08/18/2014 05:58 PM, Kever Yang wrote: From: Huang Tao On Cortex-A12 (r0p0..r0p1-00lac0-rc11), when a CPU executes a sequence of two conditional store instructions with opposite condition code and updating the same register, the system might enter a deadlock if the second conditional instruction is an UNPREDICTABLE STR or STM instruction. This workaround setting bit[12] of the Feature Register prevents the erratum. This bit disables an optimisation applied to a sequence of 2 instructions that use opposing condition codes. Signed-off-by: Huang Tao Signed-off-by: Kever Yang --- arch/arm/Kconfig | 13 + arch/arm/mm/proc-v7.S | 15 ++- 2 files changed, 27 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 32cbbd5..4545835 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1245,6 +1245,19 @@ config ARM_ERRATA_773022 loop buffer may deliver incorrect instructions. This workaround disables the loop buffer to avoid the erratum. +config ARM_ERRATA_818325 + bool "ARM errata: Execution of an UNPREDICTABLE STR or STM instruction might deadlock" + depends on CPU_V7 + help + This option enables the workaround for the 818325 Cortex-A12 + (r0p0..r0p1-00lac0-rc11) erratum. When a CPU executes a sequence of + two conditional store instructions with opposite condition code and + updating the same register, the system might enter a deadlock if the + second conditional instruction is an UNPREDICTABLE STR or STM + instruction. This workaround setting bit[12] of the Feature Register + prevents the erratum. This bit disables an optimisation applied to a + sequence of 2 instructions that use opposing condition codes. + endmenu source "arch/arm/common/Kconfig" diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index b5d67db..5ffdf97 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -408,7 +408,20 @@ __v7_setup: mcrle p15, 0, r10, c1, c0, 1 @ write aux control register #endif -4: mov r10, #0 + /* Cortex-A12 Errata */ +4: ldr r10, =0x0c0d@ Cortex-A12 primary part number + teq r0, r10 + bne 5f +#ifdef CONFIG_ARM_ERRATA_818325 + teq r6, #0x00 @ present in r0p0 + teqne r6, #0x01 @ present in r0p1-00lac0-rc11 + mrceq p15, 0, r10, c15, c0, 1 @ read diagnostic register + orreq r10, r10, #1 << 12@ set bit #12 + mcreq p15, 0, r10, c15, c0, 1 @ write diagnostic register + isb +#endif + +5: mov r10, #0 mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate #ifdef CONFIG_MMU mcr p15, 0, r10, c8, c7, 0 @ invalidate I + D TLBs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Mon, 25 Aug 2014 08:08:59 -0500, Jon Loeliger wrote: > > > > > Anyway, instead of going back and forth between "deferred probe is good" > > and "deferred probe is bad", how about we do something useful now and > > concentrate on how to make use of the information we have in DT with the > > goal to reduce the number of cases where deferred probing is required? > > Good idea. > > The proposal on the table is to allow the probe code > to make a topological sort of the devices based on > dependency information either implied, explicitly stated > or both. That is likely a fundamentally correct approach. > > I believe some of the issues that need to be resolved are: > > 1) What constitutes a dependency? > 2) How is that dependency expressed? > 3) How do we add missing dependencies? > 4) Backward compatability problems. > > There are other questions, of course. Is it a topsort > per bus? Are there required "early devices"? Should > the inter-node dependencies be expressed at each node, > or in a separate hierarchy within the DTS? Others. Getting the dependency tree I think is only half the problem. The other have is how to get the driver model to actually order probing using that list. That problem is hard because the order drivers are probed is currently determined by the interaction of driver link order, driver initcall level, and device registration order. The first devices are registered at an early initcall, before their drivers, and therefore bind order is primarily determined by initcall level and driver link order. However, later devices (ie. i2c clients) are registered by the bus driver (ie. again, i2c) and probe order may be primarily link order (if the driver is not yet registered) or registration order (if the driver was registered before the parent bus). g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems
Am Dienstag, 26. August 2014, 16:43:43 schrieb Herbert Xu: Hi Herbert, > On Tue, Aug 26, 2014 at 10:29:45AM +0200, Stephan Mueller wrote: > > The maximum values for additional input string or generated blocks is > > larger than 1<<32. To ensure a sensible value on 32 bit systems, return > > SIZE_MAX on 32 bit systems. This value is lower than the maximum > > allowed values defined in SP800-90A. The standard allow lower maximum > > values, but not larger values. > > > > SIZE_MAX - 1 is used for drbg_max_addtl to allow > > drbg_healthcheck_sanity to check the enforcement of the variable > > without wrapping. > > This is really ugly but OK. However, I'm not sure how the sanity > check ever worked. It would appear that the drbg_generate call in > drbg_healthcheck_sanity should always fail because you explicitly > set addtl->len to drbg_max_addtl + 1, which should trigger the > "DRBG: additional information string too long" error, no? That is exactly what the test shall do: the test is intended to check whether the maximum values are enforced. And it does that by checking whether an error is returned. /* get the maximum value */ max_addtllen = drbg_max_addtl(drbg); /* add one to definitely overflow the maximum value */ drbg_string_fill(&addtl, buf, max_addtllen + 1); /* overflow addtllen with additonal info string */ len = drbg_generate(drbg, buf, OUTBUFLEN, &addtl); /* * check that the drbg_generate does not return a positive * value, i.e. check that drbg_generate does not generate anything */ BUG_ON(0 < len); > > Obviously it's working for you but I'd like to understand why > it's working and whether it'll continue to work. > > Thanks, -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace
On 08/22/2014 02:39 AM, Elliott, Robert (Server Storage) wrote:
-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Yoshihiro YUNOMAE
Sent: Friday, 08 August, 2014 6:50 AM
Subject: [RFC PATCH -logging 00/10] scsi/constants: Output continuous
error messages on trace
...
1) printk
Keeps current implemntation of upstream kernel.
The messages are divided and can be mixed, but all users can
check the error messages without any settings.
scsi_io_completion ignore the scsi_logging_level and always calls
printk if it detects ACTION_FAIL, resulting in messages like:
[10240.338600] sd 2:0:0:0: [sdr]
[10240.339722] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[10240.341662] sd 2:0:0:0: [sdr]
[10240.342792] Sense Key : Hardware Error [current]
[10240.344575] sd 2:0:0:0: [sdr]
[10240.345653] Add. Sense: Logical unit failure
[10240.347138] sd 2:0:0:0: [sdr] CDB:
[10240.348309] Read(10): 28 00 00 00 00 80 00 00 08 00
If you trigger hundreds of errors (e.g., hot remove a device
during heavy IO), then all the prints to the linux serial console
bog down the system, causing timeouts in commands to other
devices and soft lockups for applications.
Some changes that would help are:
1. Put them under SCSI logging level control
2. Use printk_ratelimited so an excessive number are trimmed
Would you like to include something like this in your
patch set?
This is an example patch that only prints them if the MLCOMPLETE
logging level is nonzero.
Off: scsi_logging_level --set --mlcomplete=0
On: scsi_logging_level --set --mlcomplete=1
Some other loglevel (e.g., ERROR_RECOVERY) could be used.
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index d6b4ea8..dbb601f 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1037,7 +1037,9 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned
int good_bytes)
switch (action) {
case ACTION_FAIL:
/* Give up and fail the remainder of the request */
- if (!(req->cmd_flags & REQ_QUIET)) {
+ if (!(req->cmd_flags & REQ_QUIET) &&
+ SCSI_LOG_LEVEL(SCSI_LOG_MLCOMPLETE_SHIFT,
+ SCSI_LOG_MLCOMPLETE_BITS)) {
scsi_print_result(cmd);
if (driver_byte(result) & DRIVER_SENSE)
scsi_print_sense("", cmd);
Converting to printk_ratelimited is harder since the prints
are spread out over three functions (and as your patch
series notes, many individual printk calls). The rates
for the printk calls might not match, which would lead to
even more confusing output.
Good point. Will be including it.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
From: Thierry Reding ... > > Is _nocache required? I don't see other drivers using it. I assume there's > > nothing special about the mbox registers. > > Most drivers should be using devm_ioremap_resource() which will use the > _nocache variant of devm_ioremap() when appropriate. Usually the region > will not be marked cacheable (IORESOURCE_CACHEABLE) and therefore be > remapped uncached. A related question: Is there any way for a driver to force that part of a PCIe BAR be mapped through the data cache even when the BAR isn't actually marked cacheable? Some hardware has address regions (which might not be an entire BAR) that are actually memory and mapping through the data cache will generate longer PCIe transfers [1]. Clearly the driver will have to be very careful about cache flushes and invalidates to make this work. [1] PCIe is high throughput and high latency, single word reads can be much slower that PCI, much nearer x86 ISA bus speeds. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems
On Tue, Aug 26, 2014 at 10:52:45AM +0200, Stephan Mueller wrote: > Am Dienstag, 26. August 2014, 16:43:43 schrieb Herbert Xu: > > Hi Herbert, > > > On Tue, Aug 26, 2014 at 10:29:45AM +0200, Stephan Mueller wrote: > > > The maximum values for additional input string or generated blocks is > > > larger than 1<<32. To ensure a sensible value on 32 bit systems, return > > > SIZE_MAX on 32 bit systems. This value is lower than the maximum > > > allowed values defined in SP800-90A. The standard allow lower maximum > > > values, but not larger values. > > > > > > SIZE_MAX - 1 is used for drbg_max_addtl to allow > > > drbg_healthcheck_sanity to check the enforcement of the variable > > > without wrapping. > > > > This is really ugly but OK. However, I'm not sure how the sanity > > check ever worked. It would appear that the drbg_generate call in > > drbg_healthcheck_sanity should always fail because you explicitly > > set addtl->len to drbg_max_addtl + 1, which should trigger the > > "DRBG: additional information string too long" error, no? > > That is exactly what the test shall do: the test is intended to check whether > the maximum values are enforced. And it does that by checking whether an > error > is returned. OK that makes sense. Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ata: ahci_tegra: Read calibration fuse
The original version of the driver did not read the SATA calibration
fuse to remove the dependency to the fuse driver. The fuse driver
is now merged, so add this functionality.
The calibration fuse contains a 2-bit value used to pick a set
of calibration values for the SATA pad.
Signed-off-by: Mikko Perttunen
---
v2: reordered and separated includes
drivers/ata/ahci_tegra.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
index f1fef74..0329044 100644
--- a/drivers/ata/ahci_tegra.c
+++ b/drivers/ata/ahci_tegra.c
@@ -18,14 +18,17 @@
*/
#include
-#include
#include
#include
#include
#include
#include
#include
+#include
+
+#include
#include
+
#include "ahci.h"
#define SATA_CONFIGURATION_0 0x180
@@ -180,9 +183,12 @@ static int tegra_ahci_controller_init(struct
ahci_host_priv *hpriv)
/* Pad calibration */
- /* FIXME Always use calibration 0. Change this to read the calibration
-* fuse once the fuse driver has landed. */
- val = 0;
+ ret = tegra_fuse_readl(FUSE_SATA_CALIB, &val);
+ if (ret) {
+ dev_err(&tegra->pdev->dev,
+ "failed to read calibration fuse: %d\n", ret);
+ return ret;
+ }
calib = tegra124_pad_calibration[val & FUSE_SATA_CALIB_MASK];
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] intel_idle: add idle values for Cherrytrail/Braswell
On Tue, Aug 26, 2014 at 10:38:32AM +0800, Li, Aubrey wrote: > On 2014/8/25 18:12, Mika Westerberg wrote: > > On Fri, Aug 22, 2014 at 10:06:21PM +0800, Li, Aubrey wrote: > >> On 2014/8/22 19:39, Mika Westerberg wrote: > >>> From: Mahesh Kumar P > >>> > >>> Cherrytrail/Braswell is a successor of Intel Baytrail but has slighly > >>> different CPU idle values and latencies. > >>> > >>> Signed-off-by: Kumar P Mahesh > >>> Signed-off-by: Alan Cox > >>> Signed-off-by: Mika Westerberg > >>> --- > >>> I learned from Mahesh that C1e, C4 and S0i2 states are deprecated so those > >>> are now removed. > >> > >> If the platform has ACPI supported, I believe Len wants to see what > >> C-states number exported by ACPI. > >> > >> Please boot the machine with "intel_idle.max_cstate=0" to disable > >> intel_idle, then post the output of the following commands > > > > OK, here goes: > > ACPI exposes 0x58 as C6 mwait hint while the patch proposes 0x52 for C6. > Can you please remove "intel_idle.max_cstate=0" and run "dmesg | grep > idle" again to see how many C6 supports in CPUID enumeration? [ 16.685769] intel_idle: MWAIT substates: 0x3320 [ 16.691236] intel_idle: v0.4 model 0x4C [ 16.695539] intel_idle: lapic_timer_reliable_states 0x -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/4] net: moxa: replace build_skb() with netdev_alloc_skb_ip_align() / memcpy()
On Monday 25 August 2014 16:22:22 Jonas Jensen wrote:
> @@ -226,13 +226,15 @@ static int moxart_rx_poll(struct napi_struct *napi, int
> budget)
> if (len > RX_BUF_SIZE)
> len = RX_BUF_SIZE;
>
> - skb = build_skb(priv->rx_buf[rx_head], priv->rx_buf_size);
> + skb = netdev_alloc_skb_ip_align(ndev, len);
> +
> if (unlikely(!skb)) {
> - net_dbg_ratelimited("build_skb failed\n");
> + net_dbg_ratelimited("netdev_alloc_skb_ip_align
> failed\n");
> priv->stats.rx_dropped++;
> priv->stats.rx_errors++;
> }
>
> + memcpy(skb->data, priv->rx_buf[rx_head], len);
> skb_put(skb, len);
> skb->protocol = eth_type_trans(skb, ndev);
> napi_gro_receive(&priv->napi, skb);
While this seems correct, I wonder why you don't do the normal approach of
dequeuing the skb from the chain and adding a newly allocated skb to it to
save the memcpy.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: fsl-sai: using 'lsb-first' property instead of 'big-endian-data'.
On Mon, Aug 25, 2014 at 08:16:01AM +0100, Xiubo Li wrote:
> This property used for configuring whether the LSB or the MSB is transmitted
> first for the fifo data.
I don't follow the rationale for this change.
This looks like a pointless renaming.
Why is this any better?
Thanks,
Mark.
> Signed-off-by: Xiubo Li
> Cc: Nicolin Chen
> ---
> Documentation/devicetree/bindings/sound/fsl-sai.txt | 8
> sound/soc/fsl/fsl_sai.c | 6 +++---
> sound/soc/fsl/fsl_sai.h | 2 +-
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt
> b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> index 06a405e..4956b14 100644
> --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt
> +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> @@ -20,9 +20,9 @@ Required properties:
>See ../pinctrl/pinctrl-bindings.txt for details of the property values.
> - big-endian: Boolean property, required if all the FTM_PWM registers
>are big-endian rather than little-endian.
> -- big-endian-data: If this property is absent, the little endian mode will
> - be in use as default, or the big endian mode will be in use for all the
> - fifo data.
> +- lsb-first: Configures whether the LSB or the MSB is transmitted first for
> + the fifo data. If this property is absent, the MSB is transmitted first as
> + default, or the LSB is transmitted first.
> - fsl,sai-synchronous-rx: This is a boolean property. If present, indicating
>that SAI will work in the synchronous mode (sync Tx with Rx) which means
>both the transimitter and receiver will send and receive data by following
> @@ -53,5 +53,5 @@ sai2: sai@40031000 {
> dmas = <&edma0 0 VF610_EDMA_MUXID0_SAI2_TX>,
> <&edma0 0 VF610_EDMA_MUXID0_SAI2_RX>;
> big-endian;
> - big-endian-data;
> + lsb-first;
> };
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index a6eb784..7eeb1dd 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -175,7 +175,7 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai
> *cpu_dai,
> bool tx = fsl_dir == FSL_FMT_TRANSMITTER;
> u32 val_cr2 = 0, val_cr4 = 0;
>
> - if (!sai->big_endian_data)
> + if (!sai->is_lsb_first)
> val_cr4 |= FSL_SAI_CR4_MF;
>
> /* DAI mode */
> @@ -304,7 +304,7 @@ static int fsl_sai_hw_params(struct snd_pcm_substream
> *substream,
> val_cr5 |= FSL_SAI_CR5_WNW(word_width);
> val_cr5 |= FSL_SAI_CR5_W0W(word_width);
>
> - if (sai->big_endian_data)
> + if (sai->is_lsb_first)
> val_cr5 |= FSL_SAI_CR5_FBT(0);
> else
> val_cr5 |= FSL_SAI_CR5_FBT(word_width - 1);
> @@ -573,7 +573,7 @@ static int fsl_sai_probe(struct platform_device *pdev)
> if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx6sx-sai"))
> sai->sai_on_imx = true;
>
> - sai->big_endian_data = of_property_read_bool(np, "big-endian-data");
> + sai->is_lsb_first = of_property_read_bool(np, "lsb-first");
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> base = devm_ioremap_resource(&pdev->dev, res);
> diff --git a/sound/soc/fsl/fsl_sai.h b/sound/soc/fsl/fsl_sai.h
> index 2cded44..3466720 100644
> --- a/sound/soc/fsl/fsl_sai.h
> +++ b/sound/soc/fsl/fsl_sai.h
> @@ -132,7 +132,7 @@ struct fsl_sai {
> struct clk *bus_clk;
> struct clk *mclk_clk[FSL_SAI_MCLK_MAX];
>
> - bool big_endian_data;
> + bool is_lsb_first;
> bool is_dsp_mode;
> bool sai_on_imx;
> bool synchronous[2];
> --
> 1.8.5
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC] x86 early_ioremap: increase FIX_BTMAPS_SLOTS to 8
3.16 kernel boot fail with earlyprintk=efi, it keeps scrolling at the bottom line of screen. Bisected, the first bad commit is below: commit 86dfc6f339886559d80ee0d4bd20fe5ee90450f0 Author: Lv Zheng Date: Fri Apr 4 12:38:57 2014 +0800 ACPICA: Tables: Fix table checksums verification before installation. I did some debugging by enabling both serial and efi earlyprintk, below is some debug dmesg, seems early_ioremap fails in scroll up function due to no free slot, see below dmesg output: [snip] [0.00] RAMDISK: [mem 0x3e1b-0x3e982fff] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0xDB752000 24 (v02 HPQOEM) [0.00] ACPI: XSDT 0xDB752088 8C (v01 HPQOEM SLIC-WKS 01072009 AMI 00010013) [0.00] ACPI: FACP 0xDB759590 00010C (v05 HPQOEM SLIC-WKS 01072009 AMI 00010013) [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:116 __early_ioremap+0x90/0x1c4() [0.00] __early_ioremap(ed00c800, 0c80) not found slot [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0-rc1+ #204 [0.00] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013 [0.00] 8173b970 814bb919 8173b9b8 [0.00] 8173b9a8 810638c9 8184ee81 ff538000 [0.00] 0c80 0003 0c80 8173ba08 [0.00] Call Trace: [0.00] [] dump_stack+0x4e/0x7a [0.00] [] warn_slowpath_common+0x75/0x8e [0.00] [] ? __early_ioremap+0x90/0x1c4 [0.00] [] warn_slowpath_fmt+0x47/0x49 [0.00] [] __early_ioremap+0x90/0x1c4 [0.00] [] ? sprintf+0x46/0x48 [0.00] [] early_ioremap+0x13/0x15 [0.00] [] early_efi_map+0x24/0x26 [0.00] [] early_efi_scroll_up+0x6d/0xc0 [0.00] [] early_efi_write+0x1b0/0x214 [0.00] [] call_console_drivers.constprop.21+0x73/0x7e [0.00] [] console_unlock+0x151/0x3b2 [0.00] [] ? vprintk_emit+0x49f/0x532 [0.00] [] vprintk_emit+0x521/0x532 [0.00] [] ? console_unlock+0x383/0x3b2 [0.00] [] printk+0x4f/0x51 [0.00] [] acpi_os_vprintf+0x2b/0x2d [0.00] [] acpi_os_printf+0x43/0x45 [0.00] [] acpi_info+0x5c/0x63 [0.00] [] ? __acpi_map_table+0x13/0x18 [0.00] [] ? acpi_os_map_iomem+0x21/0x147 [0.00] [] acpi_tb_print_table_header+0x177/0x186 [0.00] [] acpi_tb_install_table_with_override+0x4b/0x62 [0.00] [] acpi_tb_install_standard_table+0xd9/0x215 [0.00] [] ? early_ioremap+0x13/0x15 [0.00] [] ? __acpi_map_table+0x13/0x18 [0.00] [] acpi_tb_parse_root_table+0x16e/0x1b4 [0.00] [] acpi_initialize_tables+0x57/0x59 [0.00] [] acpi_table_init+0x50/0xce [0.00] [] acpi_boot_table_init+0x1e/0x85 [0.00] [] setup_arch+0x9b7/0xcc4 [0.00] [] start_kernel+0x94/0x42d [0.00] [] ? early_idt_handlers+0x120/0x120 [0.00] [] x86_64_start_reservations+0x2a/0x2c [0.00] [] x86_64_start_kernel+0xf3/0x100 [0.00] ---[ end trace 48732c7db414b8fe ]--- [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:116 __early_ioremap+0x90/0x1c4() [0.00] __early_ioremap(ed00c800, 0c80) not found slot [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Tainted: GW 3.17.0-rc1+ #204 [0.00] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013 [0.00] 8173b970 814bb919 8173b9b8 [0.00] 8173b9a8 810638c9 8184ee81 ff538000 [0.00] 0c80 0003 0c80 8173ba08 [0.00] Call Trace: [0.00] [] dump_stack+0x4e/0x7a [0.00] [] warn_slowpath_common+0x75/0x8e [0.00] [] ? __early_ioremap+0x90/0x1c4 [0.00] [] warn_slowpath_fmt+0x47/0x49 [0.00] [] __early_ioremap+0x90/0x1c4 [0.00] [] early_ioremap+0x13/0x15 [0.00] [] early_efi_map+0x24/0x26 [0.00] [] early_efi_scroll_up+0x6d/0xc0 [0.00] [] early_efi_write+0x1b0/0x214 [0.00] [] call_console_drivers.constprop.21+0x73/0x7e [0.00] [] console_unlock+0x1fa/0x3b2 [0.00] [] vprintk_emit+0x521/0x532 [0.00] [] ? console_unlock+0x383/0x3b2 [0.00] [] printk+0x4f/0x51 [0.00] [] acpi_os_vprintf+0x2b/0x2d [0.00] [] acpi_os_printf+0x43/0x45 [0.00] [] acpi_info+0x5c/0x63 [0.00] [] ? __acpi_map_table+0x13/0x18 [0.00] [] ? acpi_os_map_iomem+0x21/0x147 [0.00] [] acpi_tb_print_table_header+0x177/0x186 [0.00] [] acpi_tb_
Re: Linux UDF support
Hello, On Sun 24-08-14 14:46:46, Pali Rohár wrote: > I would like to know what is state of linux UDF driver. It is > experimental or is now suitable for storing data? The kernel driver is quite stable. I would happily use it for USB sticks etc. I would be reluctant to use it for say /home because we don't have any reasonable repair tool for the filesystem (there are format checkers out there but they mostly tell you there is a problem, however there's not a decent tool which would fix the filesystem AFAIK). > According to wikipedia [1] UDF has open specification format and > can be used also for HDDs (not only optical discs). Correct. > In OS support table is written that all major and other minor OSs > support UDF FS (without needs for additional programs). > > So it looks like UDF is good candidate for multi OS filesystem. > Are there any disadvantages for using UDF on e.g USB flash disk? > (when I want read/write support on Linux, Windows 7 and Mac OS X) Yes, it is a good candidate for exchange between different OSs. I know people who use it as such. > Because lot of manuals say that FAT32 (or NTFS) is only one > solution for using USB flash disk on more OS. > > On wikipedia there is one note about linux: Write support is only > up to UDF version 2.01. Is this restriction still valid? That is correct. > What will happen if I try to mount FS with UDF version 2.60 in > R/W mode on linux? It will fallback to R/O mode? Or newly written > files will be in previous (2.01) versions? The kernel refuses to mount the filesystem read-write if its revision is > 2.01. But frankly for interchange between OSs you don't want to use advanced features anyway (lower chance fs will be supported) and there's not much benefit since they are mostly aimed at optical media. Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 4/6] mfd: Add hi6421 PMIC core driver
On Mon, 25 Aug 2014, Guodong Xu wrote: > On 08/20/2014 04:09 PM, Lee Jones wrote: > > On Mon, 18 Aug 2014, Guodong Xu wrote: > >> This adds driver to support HiSilicon Hi6421 PMIC. Hi6421 includes multi- > >> functions, such as regulators, codec, ADCs, Coulomb counter, etc. > >> This driver includes core APIs _only_. > >> > >> Drivers for individul components, like voltage regulators, are > >> implemented in corresponding driver directories and files. > >> > >> Registers in Hi6421 are memory mapped, so using regmap-mmio API. > >> > >> Signed-off-by: Guodong Xu > >> --- > >> Documentation/devicetree/bindings/mfd/hi6421.txt | 37 +++ [...] > >> + * Author: Guodong Xu > >> + * > >> + * This program is free software; you can redistribute it and/or modify > >> + * it under the terms of the GNU General Public License version 2 as > >> + * published by the Free Software Foundation. > > > > This should also contain a link to the full licence. > > > > See: COPYING > > > > Thanks. I checked COPYING, but there is no 'link' to full license. I I was making reference to the fact that COPYING tells you to provide a link to the full notice: "To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found." > copied a link from other c source: http://www.gnu.org/licenses/ > is that OK? Yes, that's fine. > >> + platform_set_drvdata(pdev, pmic); > > > > It's not _that_ important, but I like to see this at the end after you > > know everything else has succeeded. > > When I move this after mfd_add_devices(), it fails to boot. In mfd > devices's probe, pmic->regmap is used. You can move it to just before mfd_add_devices(). -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
On Tue, Aug 26, 2014 at 10:09:25AM +0200, Arnd Bergmann wrote: > On Tuesday 26 August 2014 09:50:25 Thierry Reding wrote: > > On Tue, Aug 26, 2014 at 09:43:50AM +0200, Arnd Bergmann wrote: > > > On Tuesday 26 August 2014 08:57:31 Thierry Reding wrote: > > > > On Mon, Aug 25, 2014 at 01:01:52PM -0600, Stephen Warren wrote: > > > > > On 08/18/2014 11:08 AM, Andrew Bresticker wrote: > > > > [...] > > > > > >+static int tegra_xusb_mbox_probe(struct platform_device *pdev) > > > > > > > > > > >+res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > > > > >+if (!res) > > > > > >+return -ENODEV; > > > > > > > > > > Should devm_request_mem_region() be called here to claim the region? > > > > > > > > > > >+mbox->regs = devm_ioremap_nocache(&pdev->dev, res->start, > > > > > >+ resource_size(res)); > > > > > >+if (!mbox->regs) > > > > > >+return -ENOMEM; > > > > > > > > > > Is _nocache required? I don't see other drivers using it. I assume > > > > > there's > > > > > nothing special about the mbox registers. > > > > > > > > Most drivers should be using devm_ioremap_resource() which will use the > > > > _nocache variant of devm_ioremap() when appropriate. Usually the region > > > > will not be marked cacheable (IORESOURCE_CACHEABLE) and therefore be > > > > remapped uncached. > > > > > > > > > > Note that ioremap() and ioremap_nocache() are the same. We really > > > shouldn't > > > ever call ioremap_nocache(). > > > > Perhaps we should remove ioremap_nocache() in that case. Or ioremap(), > > really, and keep only those variants that do what they claim to do. > > That would be good, but there are many instances of either one: > > arnd@wuerfel:/git/arm-soc$ git grep -w ioremap | wc >2156 13402 183732 > arnd@wuerfel:/git/arm-soc$ git grep -w ioremap_nocache | wc > 4852529 42955 Ugh... nothing that I currently have time for. Perhaps this is a good one for the Janitors? I'm not sure if the kernelnewbies.org TODO list is still frequented since many pages seem to be very old. Is there some other place where I could add this? > > > devm_ioremap_resource() and pci_iomap() checking for IORESOURCE_CACHEABLE > > > is > > > rather silly, since it doesn't call ioremap_cache() in that case. > > > > Then that should be fixed. > > Yes. I'd suggest we just ignore that flag and always call ioremap here. > > When I checked this before, IORESOURCE_CACHEABLE only ever gets set for > PCI ROM BARs, which we don't map into the kernel. There's still a few users of ioremap_cache() around and they are potential candidates for a conversion to devm_ioremap_resource(), so I think it'd still make sense to keep the check. Thierry pgppdtOGdGcCz.pgp Description: PGP signature
Re: [PATCH v9 1/2] regulator: Add driver for max77802 PMIC PMIC regulators
Hello Mark, On 08/26/2014 09:17 AM, Mark Brown wrote: > On Mon, Aug 25, 2014 at 08:40:40AM -0700, Doug Anderson wrote: >> > Can you please test the following change [0] so I can post as a proper >> > patch? Doug, Mark do you think that forcing the regulator to opmode normal >> > when enabling is the right solution here? > >> IMHO that makes sense. > > No, this doesn't make any obvious sense to me at all. Picking normal as > a default if the hardware reads back off due to overlapping > impelementation or something *might* make sense but not overwriting the > hardware state without explicit permission from the machine integration > is a key goal for the regulator API. > Just to be sure I understood you correctly, what might makes sense to you then is to set the opmode to normal as default on probe only if off is read back from the hardware register but leaving the enable function as it is now using the opmode set on probe? That seems like a safer solution indeed since enable won't overwrite other values different from off read from the hardware register, I'll prepare a patch. Thanks a lot for your help and best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 2/4] net: moxa: replace build_skb() with netdev_alloc_skb_ip_align() / memcpy()
From: Arnd Bergmann
> On Monday 25 August 2014 16:22:22 Jonas Jensen wrote:
> > @@ -226,13 +226,15 @@ static int moxart_rx_poll(struct napi_struct *napi,
> > int budget)
> > if (len > RX_BUF_SIZE)
> > len = RX_BUF_SIZE;
> >
> > - skb = build_skb(priv->rx_buf[rx_head], priv->rx_buf_size);
> > + skb = netdev_alloc_skb_ip_align(ndev, len);
> > +
> > if (unlikely(!skb)) {
> > - net_dbg_ratelimited("build_skb failed\n");
> > + net_dbg_ratelimited("netdev_alloc_skb_ip_align
> > failed\n");
> > priv->stats.rx_dropped++;
> > priv->stats.rx_errors++;
> > }
> >
> > + memcpy(skb->data, priv->rx_buf[rx_head], len);
Is this memcpy() aligned?
If the hardware can receive to a 4n+2 offset it is probably better to
copy the two bytes before the frame data and to round the length of to
a whole number of words.
> > skb_put(skb, len);
> > skb->protocol = eth_type_trans(skb, ndev);
> > napi_gro_receive(&priv->napi, skb);
>
> While this seems correct, I wonder why you don't do the normal approach of
> dequeuing the skb from the chain and adding a newly allocated skb to it to
> save the memcpy.
Because the receive buffer area isn't made of skbs.
Post-allocating the skb also reduces the 'true size' of the skb.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 1/2] regulator: Add driver for max77802 PMIC PMIC regulators
On Tue, Aug 26, 2014 at 11:08:07AM +0200, Javier Martinez Canillas wrote: > On 08/26/2014 09:17 AM, Mark Brown wrote: > > No, this doesn't make any obvious sense to me at all. Picking normal as > > a default if the hardware reads back off due to overlapping > > impelementation or something *might* make sense but not overwriting the > > hardware state without explicit permission from the machine integration > > is a key goal for the regulator API. > Just to be sure I understood you correctly, what might makes sense to you > then is to set the opmode to normal as default on probe only if off is > read back from the hardware register but leaving the enable function as it > is now using the opmode set on probe? Yes. signature.asc Description: Digital signature
