Re: [PATCH] MAINTAINERS: add myself as Samsung SPI maintainer
On Thu, Aug 18, 2016 at 8:44 AM, Andi Shyti wrote: > Create a new entry for the Samsung SPI driver supported by the > drivers/spi/spi-s3c* and remove it from its original place under > "ARM/SAMSUNG EXYNOS ARM ARCHITECTURES". > > The original maintainership inherited from the Samsung Exynos > ARM Architecture is kept as it was (i.e. Kukjin and Krzysztof), I > will help and co-maintain the driver. > > CC: Krzysztof Kozlowski > CC: Kukjin Kim > CC: Mark Brown > CC: linux-samsung-...@vger.kernel.org > CC: linux-...@vger.kernel.org > Signed-off-by: Andi Shyti > --- > Hi, > > this patch depends on Krzysztof's previous patch-set on the > MAINTAINER file: https://lkml.org/lkml/2016/8/16/571 Thanks for taking care of SPI. From my side: Acked-by: Krzysztof Kozlowski I think there is no strict dependency on my patch (patches do not overlap) so it can safely go through SPI tree if accepted. Best regards, Krzysztof
[PATCH 0/0] regmap: drop cache if the bus transfer error
regmap_write ->_regmap_raw_write -->regcache_write first and than use map->bus->write to wirte i2c or spi But if the i2c or spi transfer failed, But the cache is updated, So if I use regmap_read will get the cache data which is not the real register value. I think the regmap should handle that gracefully, and may be my modify is not the best way. But as I described is how to slove that problem. Elaine Zhang (1): regmap: drop cache if the bus transfer error drivers/base/regmap/regmap.c | 2 ++ 1 file changed, 2 insertions(+) -- 1.9.1
Re: [PATCH V8 5/8] irqchip/gicv3-its: Refactor ITS DT init code to prepare for ACPI
On 17.08.2016 17:58, Bjorn Helgaas wrote:
On Wed, Aug 17, 2016 at 04:33:02PM +0800, Hanjun Guo wrote:
On 2016/8/11 18:06, Tomasz Nowicki wrote:
In order to add ACPI support we need to isolate ACPI&DT common code and
move DT logic to corresponding functions. To achieve this we are using
firmware agnostic handle which can be unpacked to either DT or ACPI node.
No functional changes other than a very minor one:
1. Terminate its_init call with -ENODEV for non-DT case which allows
to remove hack from its-gic-v3.c.
2. Fix ITS base register address type (from 'unsigned long' to 'phys_addr_t'),
as a bonus we get nice string formatting.
3. Since there is only one of ITS parent domain convert it to static global
variable and drop the parameter from its_probe_one. Users can refer to it
in more convenient way then.
[...]
-static int __init its_probe(struct device_node *node,
- struct irq_domain *parent)
+static int __init its_probe_one(struct resource *res,
+ struct fwnode_handle *handle, int numa_node)
{
- struct resource res;
struct its_node *its;
void __iomem *its_base;
u32 val;
u64 baser, tmp;
int err;
- err = of_address_to_resource(node, 0, &res);
- if (err) {
- pr_warn("%s: no regs?\n", node->full_name);
- return -ENXIO;
- }
-
- its_base = ioremap(res.start, resource_size(&res));
+ its_base = ioremap(res->start, resource_size(res));
if (!its_base) {
- pr_warn("%s: unable to map registers\n", node->full_name);
+ pr_warn("ITS@%pa: Unable to map ITS registers\n", &res->start);
return -ENOMEM;
}
val = readl_relaxed(its_base + GITS_PIDR2) & GIC_PIDR2_ARCH_MASK;
if (val != 0x30 && val != 0x40) {
- pr_warn("%s: no ITS detected, giving up\n", node->full_name);
+ pr_warn("ITS@%pa: No ITS detected, giving up\n", &res->start);
err = -ENODEV;
goto out_unmap;
}
err = its_force_quiescent(its_base);
if (err) {
- pr_warn("%s: failed to quiesce, giving up\n",
- node->full_name);
+ pr_warn("ITS@%pa: Failed to quiesce, giving up\n", &res->start);
goto out_unmap;
}
- pr_info("ITS: %s\n", node->full_name);
+ pr_info("ITS@%pa\n", &res->start);
^^
When I was testing this patch set I found message printed as below:
[0.00] ITS@0xc600
I think it'd be nicer to print the resource with %pR so we see the
type and size in a way that matches other physical address usage.
The intention was to keep previous message layout but while we are here,
%pR usage for this one pr_info seems nice to me.
I don't know whether there is or should be a struct device associated
with the ITS. The its_probe_one() function looks similar to regular
driver probe functions, so maybe there should be.
If there were a struct device associated with the ITS, it'd be nicer
to use dev_info() as well, of course.
Indeed dev_info() would be nice but there is no struct device for ITS.
Tomasz
Re: [PATCH v8 1/2] Documentation: kdump: remind user of nr_cpus
On 08/17/16 at 07:36pm, Joe Perches wrote: > On Thu, 2016-08-18 at 10:31 +0800, Zhou Wenjian wrote: > > nr_cpus can help to save memory. So we should remind user of it. > > trivia: > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > [] > > @@ -390,9 +390,11 @@ Notes on loading the dump-capture kernel: > > * Boot parameter "1" boots the dump-capture kernel into single-user > > mode without networking. If you want networking, use "3". > > > > -* We generally don' have to bring up a SMP kernel just to capture the > > +* We generally don' have to bring up an SMP kernel just to capture the > > don't or do not > Use do not is better, also need replace 'We' with 'You' to be consistent with other part.
[PATCH 0/1] regmap: drop cache if the bus transfer error
regmap_write
->_regmap_raw_write
-->regcache_write first and than use map->bus->write to wirte i2c or spi
But if the i2c or spi transfer failed, But the cache is updated, So if I use
regmap_read will get the cache data which is not the real register value.
Signed-off-by: Elaine Zhang
---
drivers/base/regmap/regmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 1f011f9d6dcb..369a4c3c933e 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1497,6 +1497,8 @@ int _regmap_raw_write(struct regmap *map, unsigned int
reg,
ret = map->bus->write(map->bus_context, buf, len);
kfree(buf);
+ } else if (ret != 0 && !map->cache_bypass && map->format.parse_val) {
+ regcache_drop_region(map, reg, reg + 1);
}
trace_regmap_hw_write_done(map, reg, val_len / map->format.val_bytes);
--
1.9.1
[PATCH] MAINTAINERS: add myself as Samsung SPI maintainer
Create a new entry for the Samsung SPI driver supported by the drivers/spi/spi-s3c* and remove it from its original place under "ARM/SAMSUNG EXYNOS ARM ARCHITECTURES". The original maintainership inherited from the Samsung Exynos ARM Architecture is kept as it was (i.e. Kukjin and Krzysztof), I will help and co-maintain the driver. CC: Krzysztof Kozlowski CC: Kukjin Kim CC: Mark Brown CC: linux-samsung-...@vger.kernel.org CC: linux-...@vger.kernel.org Signed-off-by: Andi Shyti --- Hi, this patch depends on Krzysztof's previous patch-set on the MAINTAINER file: https://lkml.org/lkml/2016/8/16/571 Thanks, Andi MAINTAINERS | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index c9cd8d3..c305fa2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1633,7 +1633,6 @@ F:drivers/*/*s3c64xx* F: drivers/*/*s5pv210* F: drivers/memory/samsung/* F: drivers/soc/samsung/* -F: drivers/spi/spi-s3c* F: Documentation/arm/Samsung/ F: Documentation/devicetree/bindings/arm/samsung/ F: Documentation/devicetree/bindings/sram/samsung-sram.txt @@ -10240,6 +10239,15 @@ S: Supported L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) F: drivers/clk/samsung/ +SAMSUNG SPI DRIVERS +M: Kukjin Kim +M: Krzysztof Kozlowski +M: Andi Shyti +L: linux-...@vger.kernel.org +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) +S: Maintained +F: drivers/spi/spi-s3c* + SAMSUNG SXGBE DRIVERS M: Byungho An M: Girish K S -- 2.8.1
Re: [PATCH v2 2/2] fs: super.c: Add tracepoint to get name of superblock shrinker
On Thu 18-08-16 07:32:39, Al Viro wrote: > On Thu, Aug 18, 2016 at 02:09:31AM -0400, Janani Ravichandran wrote: > > > static LIST_HEAD(super_blocks); > > @@ -64,6 +65,7 @@ static unsigned long super_cache_scan(struct shrinker > > *shrink, > > longinodes; > > > > sb = container_of(shrink, struct super_block, s_shrink); > > + trace_mm_shrinker_callback(shrink, sb->s_type->name); > > IOW, we are (should that patch be accepted) obliged to keep the function in > question and the guts of struct shrinker indefinitely. I am not aware that trace points are considered a stable ABI. Is that documented anywhere? We have changed/removed some of them in the past. If there is a debugging tool parsing them the tool itself is responsible to keep track of any changes. -- Michal Hocko SUSE Labs
Re: musb: am3358: having problem with high-speed on usb1 at peripheral
Hi, ayaka writes: >> On 08/13/2016 01:44 AM, Greg KH wrote: >>> On Sat, Aug 13, 2016 at 12:38:46AM +0800, ayaka wrote: >>> On 08/12/2016 03:40 PM, Greg KH wrote: > On Fri, Aug 12, 2016 at 10:23:15AM +0800, ayaka wrote: > Hello all: > I recently add a support for customize am3358 board using the > branch > processor-sdk-linux-03.00.00 from Ti git. But I meet a problem with > musb > at the peripheral mode. Then you are going to have to get support from TI for this, nothing we can do here about random vendor kernel trees, sorry. If you can use the 4.7 tree, or better yet, the 4.8-rc tree, then we >>> I have tried the 4.8-rc1, I meet the same problem. >> What problem is that exactly? > Sorry, the USB1 can't work at high speed gadget mode and have DMA problem. > musb-hdrc musb-hdrc.0.auto: Failed to request rx1. > musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 -517 is EPROBE_DEFER. Most likely DMA hasn't probed and MUSB is deferring to try later. This does _NOT_ MUSB can't work with DMA. Perhaps you didn't enable support for MUSB's DMA engine. >>> I have set the status of cppi41dma to okay in dts. And >>> CONFIG_USB_TI_CPPI41_DMA, >>> CONFIG_TI_CPPI41 and CONFIG_TI_EDMA are enabled with build into kernel. >>> >>> Anything else I should do? >> no, that should do it. Since musb returned -EPROBE_DEFER, it will retry >> probing later. Check if musb probed fine. The easiest way is to check if >> you have anything in /sys/class/udc/ > Yes, it has musb-hdrc.0.auto. But it doesn't mean that it fallback PIO mode? no, it doesn't. MUSB knows it needs the DMA, that's why is defers its own probe routine. > Actually I don't care whether it use PIO or DMA, I just can't bear it > work in USB 2.0 Full Speed mode, too slow. So it always enumerates in Full-speed? That's odd. Bin, any ideas? -- balbi signature.asc Description: PGP signature
Re: [PATCH v5 2/2] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
Hi,
Peter Chen writes:
> On Wed, Aug 17, 2016 at 03:53:24PM +0300, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Heikki Krogerus writes:
>>
>> [...]
>>
>> > +static struct platform_driver wcove_typec_driver = {
>> > + .driver = {
>> > + .name = "bxt_wcove_usbc",
>> > + },
>> > + .probe = wcove_typec_probe,
>> > + .remove = wcove_typec_remove,
>> > +};
>> > +
>> > +module_platform_driver(wcove_typec_driver);
>> > +
>> > +MODULE_AUTHOR("Intel Corporation");
>> > +MODULE_LICENSE("GPL v2");
>> > +MODULE_DESCRIPTION("WhiskeyCove PMIC USB Type-C PHY driver");
>>
>> you need to add:
>>
>> MODULE_ALIAS("platform:bxt_wcove_usbc");
>>
>> otherwise this won't probe() automagically.
>>
>
> What do you mean, Felipe? If there is a platform device named
> "bxt_wcove_usbc", why it will not be probed?
IIRC default module alias is added based on file name, not
platform_driver name, so this would be
MODULE_ALIAS("platform:typec_wcove") by default... I could be wrong,
really don't remember the details of that now.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v2 2/2] fs: super.c: Add tracepoint to get name of superblock shrinker
On Thu, Aug 18, 2016 at 02:09:31AM -0400, Janani Ravichandran wrote: > static LIST_HEAD(super_blocks); > @@ -64,6 +65,7 @@ static unsigned long super_cache_scan(struct shrinker > *shrink, > longinodes; > > sb = container_of(shrink, struct super_block, s_shrink); > + trace_mm_shrinker_callback(shrink, sb->s_type->name); IOW, we are (should that patch be accepted) obliged to keep the function in question and the guts of struct shrinker indefinitely. NAK. Keep your debugging patches in your tree and maintain them yourself. And if a change in the kernel data structures breaks them (and your userland code relying on those), it's your problem. Tracepoints are very nice for local debugging/data collection/etc. patches. Accepting them into mainline shifts the responsibility for updating them to the rest of us, and unlike you we can't update the userland side. Adding a userland ABI means pledging to keep it alive pretty much indefinitely. It's not automatically unacceptable (hell, new syscalls get added from time to time), but it should come with a serious analysis of what's getting exposed and it shouldn't be accepted without such.
[GIT PULL] ARM: exynos: Fixes for v4.8
Hi, A fix and a maintainers update for current release cycle (v4.8). Best regards, Krzysztof The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-fixes-4.8 for you to fetch changes up to 326dce0734b63c3b82b6a88e5645eab8b54c6692: MAINTAINERS: Switch to kernel.org account for Krzysztof Kozlowski (2016-08-17 17:54:56 +0200) Fix for v4.8-rc1: 1. Select proper eMMC HighSpeed mode on Odroid XU. DTS was mixing "samsung,exynos5250-dw-mshc" compatible (with HS200 as fastest mode) with a property "mmc-hs400-1_8v" thus leading to failures during probe. 2. Update Krzysztof Kozlowski's email address in maintainers. Krzysztof Kozlowski (2): ARM: dts: exynos: Properly select eMMC HighSpeed mode on Odroid XU MAINTAINERS: Switch to kernel.org account for Krzysztof Kozlowski .mailmap | 1 + MAINTAINERS | 15 +-- arch/arm/boot/dts/exynos5410-odroidxu.dts | 3 --- 3 files changed, 10 insertions(+), 9 deletions(-)
Re: [PATCH V8 1/8] ACPI: I/O Remapping Table (IORT) initial support
On 12.08.2016 18:33, Lorenzo Pieralisi wrote:
Hi Tomasz,
On Thu, Aug 11, 2016 at 12:06:31PM +0200, Tomasz Nowicki wrote:
IORT shows representation of IO topology for ARM based systems.
It describes how various components are connected together on
parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
Initial support allows to detect IORT table presence and save its
root pointer obtained through acpi_get_table(). The pointer validity
depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap
is not set while using IORT nodes we would dereference unmapped pointers.
For the aforementioned reason call iort_table_detect() from acpi_init()
which guarantees acpi_gbl_permanent_mmap to be set at that point.
We still need to get Rafael ACK on this, keeping in mind that the
eg code parsing DMAR table relies on the same assumption.
Exactly.
Rafael, can you please have a look ?
[...]
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 445ce28..6cef2d1 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -521,4 +521,9 @@ config ACPI_CONFIGFS
userspace. The configurable ACPI groups will be visible under
/config/acpi, assuming configfs is mounted under /config.
+if ARM64
+source "drivers/acpi/arm64/Kconfig"
+
Just curious: Why do you need a space ?
No good reason, it will disappear for next version.
+endif
+
endif # ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 5ae9d85..e5ada78 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -105,3 +105,5 @@ obj-$(CONFIG_ACPI_CONFIGFS) += acpi_configfs.o
video-objs += acpi_video.o video_detect.o
obj-y += dptf/
+
+obj-$(CONFIG_ARM64)+= arm64/
diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
new file mode 100644
index 000..fc818dc
--- /dev/null
+++ b/drivers/acpi/arm64/Kconfig
@@ -0,0 +1,6 @@
+#
+# ACPI Configuration for ARM64
+#
+
+config IORT_TABLE
+ bool
diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
new file mode 100644
index 000..d01be6f
--- /dev/null
+++ b/drivers/acpi/arm64/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_IORT_TABLE) += iort.o
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
new file mode 100644
index 000..f89056e
--- /dev/null
+++ b/drivers/acpi/arm64/iort.c
@@ -0,0 +1,218 @@
+/*
+ * Copyright (C) 2016, Semihalf
+ * Author: Tomasz Nowicki
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * This file implements early detection/parsing of I/O mapping
+ * reported to OS through firmware via I/O Remapping Table (IORT)
+ * IORT document number: ARM DEN 0049A
+ */
+
+#define pr_fmt(fmt)"ACPI: IORT: " fmt
+
+#include
+#include
+#include
+
+typedef acpi_status (*iort_find_node_callback)
+ (struct acpi_iort_node *node, void *context);
+
+/* Root pointer to the mapped IORT table */
+static struct acpi_table_header *iort_table;
See above.
[...]
+void __init iort_table_detect(void)
+{
+ acpi_status status;
+
+ status = acpi_get_table(ACPI_SIG_IORT, 0, &iort_table);
+ if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
+ const char *msg = acpi_format_exception(status);
+ pr_err("Failed to get table, %s\n", msg);
+ }
+}
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 85b7d07..55a84da 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -36,6 +36,7 @@
#ifdef CONFIG_X86
#include
#endif
+#include
#include
#include
#include
@@ -1186,6 +1187,7 @@ static int __init acpi_init(void)
}
pci_mmcfg_late_init();
+ iort_table_detect();
That's another bit we have to make sure Rafael is ok with, given
that IORT is ARM64 specific (but we stub it out if it is not
configured).
Having said that:
Reviewed-by: Lorenzo Pieralisi
Thanks for your time.
Tomasz
Re: [LKP] [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75!
Sorry, it's a duplicated report, please ignore it.
Thanks,
Xiaolong
On 08/18, kernel test robot wrote:
>
>FYI, we noticed the following commit:
>
>https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>commit 5b710f34e194c6b7710f69fdb5d798fdf35b98c1 ("x86/uaccess: Enable hardened
>usercopy")
>
>in testcase: boot
>
>on test machine: 1 threads qemu-system-i386 -enable-kvm with 360M memory
>
>caused below changes:
>
>
>+--+++
>| | f5509cc18d | 5b710f34e1 |
>+--+++
>| boot_successes | 12 | 0 |
>| boot_failures| 0 | 19 |
>| kernel_BUG_at_mm/usercopy.c | 0 | 19 |
>| EIP_is_at__check_object_size | 0 | 19 |
>| Kernel_panic-not_syncing:Fatal_exception | 0 | 19 |
>+--+++
>
>
>
>[ 177.875629] usercopy: kernel memory overwrite attempt detected to 80028f40
>() (512 bytes)
>[ 177.965655] [ cut here ]
>[ 177.965655] [ cut here ]
>[ 177.976995] kernel BUG at mm/usercopy.c:75!
>[ 177.976995] kernel BUG at mm/usercopy.c:75!
>[ 177.991519] invalid opcode: [#1]
>[ 177.991519] invalid opcode: [#1]
>[ 178.000490] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-4-g5b710f3 #2
>[ 178.000490] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-4-g5b710f3 #2
>[ 178.016498] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>Debian-1.8.2-1 04/01/2014
>[ 178.016498] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>Debian-1.8.2-1 04/01/2014
>[ 178.037761] task: 80028000 ti: 8002a000 task.ti: 8002a000
>[ 178.037761] task: 80028000 ti: 8002a000 task.ti: 8002a000
>[ 178.050690] EIP: 0060:[<8110a056>] EFLAGS: 00010246 CPU: 0
>[ 178.050690] EIP: 0060:[<8110a056>] EFLAGS: 00010246 CPU: 0
>[ 178.064166] EIP is at __check_object_size+0x202/0x258
>[ 178.064166] EIP is at __check_object_size+0x202/0x258
>[ 178.076286] EAX: 0063 EBX: 80028f40 ECX: 810945ac EDX: 80028000
>[ 178.076286] EAX: 0063 EBX: 80028f40 ECX: 810945ac EDX: 80028000
>[ 178.091360] ESI: 817c7dfa EDI: 94b3a5a0 EBP: 8002beac ESP: 8002be7c
>[ 178.091360] ESI: 817c7dfa EDI: 94b3a5a0 EBP: 8002beac ESP: 8002be7c
>[ 178.116671] DS: 007b ES: 007b FS: GS: 0033 SS: 0068
>[ 178.116671] DS: 007b ES: 007b FS: GS: 0033 SS: 0068
>[ 178.129596] CR0: 80050033 CR2: 775e1460 CR3: 0dfbc000 CR4: 0690
>[ 178.129596] CR0: 80050033 CR2: 775e1460 CR3: 0dfbc000 CR4: 0690
>[ 178.154127] Stack:
>[ 178.154127] Stack:
>[ 178.170232] 817c7e39
>[ 178.170232] 817c7e39 817c7e03 817c7e03 8184213b 8184213b 80028f40 80028f40
>817c7dcc 817c7dcc 0200 0200 94b3a000 94b3a000 00028000 00028000
>
>[ 178.205104] 0200
>[ 178.205104] 0200 7ffcbc40 7ffcbc40 80028000 80028000 0200 0200
>8002bf44 8002bf44 81047847 81047847 80028f40 80028f40 80028f00 80028f00
>
>[ 178.246126]
>[ 178.246126] 7ffcbbd0 7ffcbbd0
>81045015 81045015 80028000 80028000 8002bef8 8002bef8 81081804 81081804
>
>[ 178.290075] Call Trace:
>[ 178.290075] Call Trace:
>[ 178.303259] [<81047847>] __fpu__restore_sig+0x14f/0x439
>[ 178.303259] [<81047847>] __fpu__restore_sig+0x14f/0x439
>[ 178.328374] [<81045015>] ? sched_clock+0x9/0xd
>[ 178.328374] [<81045015>] ? sched_clock+0x9/0xd
>[ 178.350312] [<81081804>] ? sched_clock_cpu+0x19/0xc8
>
>
>FYI, raw QEMU command line is:
>
> qemu-system-i386 -enable-kvm -kernel
> /pkg/linux/i386-randconfig-w0-08170631/gcc-6/5b710f34e194c6b7710f69fdb5d798fdf35b98c1/vmlinuz-4.7.0-4-g5b710f3
> -append 'ip=vm-lkp-wsx03-quantal-i386-6::dhcp root=/dev/ram0 user=lkp
> job=/lkp/scheduled/vm-lkp-wsx03-quantal-i386-6/boot-1-quantal-core-i386.cgz-5b710f34e194c6b7710f69fdb5d798fdf35b98c1-20160817-52554-1cf9h0a-0.yaml
> ARCH=i386 kconfig=i386-randconfig-w0-08170631 branch=linus/master
> commit=5b710f34e194c6b7710f69fdb5d798fdf35b98c1
> BOOT_IMAGE=/pkg/linux/i386-randconfig-w0-08170631/gcc-6/5b710f34e194c6b7710f69fdb5d798fdf35b98c1/vmlinuz-4.7.0-4-g5b710f3
> max_uptime=600
> RESULT_ROOT=/result/boot/1/vm-lkp-wsx03-quantal-i386/quantal-core-i386.cgz/i386-randconfig-w0-08170631/gcc-6/5b710f34e194c6b7710f69fdb5d798fdf35b98c1/0
> LKP_SERVER=inn debug apic=debug sysrq_always_enabled
> rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_pan
[PowerPC] today's main line failed to build on PowerPC
Hi, The main line stable 4.8.0-rc2 failed to build on PowerPC with following build errors. config : pseries_le_defconfig Machine Type : PowerPC Bare Metal 09:34:22 00:04:59 INFO | make -j 160 vmlinux 09:34:24 00:05:01 ERROR| [stderr] arch/powerpc/mm/hash_low_32.S: Assembler messages: 09:34:24 00:05:01 ERROR| [stderr] arch/powerpc/mm/hash_low_32.S:353: Error: missing operand 09:34:24 00:05:01 ERROR| [stderr] arch/powerpc/mm/hash_low_32.S:612: Error: missing operand 09:34:24 00:05:01 ERROR| [stderr] arch/powerpc/mm/hash_low_32.S:670: Error: missing operand 09:34:24 00:05:01 ERROR| [stderr] make[1]: *** [arch/powerpc/mm/hash_low_32.o] Error 1 09:34:24 00:05:01 ERROR| [stderr] make[1]: *** Waiting for unfinished jobs 09:34:25 00:05:02 ERROR| [stderr] arch/powerpc/kernel/head_32.S: Assembler messages: 09:34:25 00:05:02 ERROR| [stderr] arch/powerpc/kernel/head_32.S:1113: Error: missing operand 09:34:25 00:05:02 ERROR| [stderr] make[1]: *** [arch/powerpc/kernel/head_32.o] Error 1 09:34:25 00:05:02 ERROR| [stderr] make[1]: *** Waiting for unfinished jobs 09:34:27 00:05:04 ERROR| [stderr] make: *** [arch/powerpc/mm] Error 2 09:34:27 00:05:04 ERROR| [stderr] make: *** Waiting for unfinished jobs 09:34:42 00:05:19 ERROR| [stderr] make: *** [arch/powerpc/kernel] Error 2 Regard's Abdul
Re: [PATCH v2] xen: rename xen_pmu_init() in sys-hypervisor.c
On 02/08/16 08:53, Juergen Gross wrote: > There are two functions with name xen_pmu_init() in the kernel. Rename > the one in drivers/xen/sys-hypervisor.c to avoid shadowing the one in > arch/x86/xen/pmu.c > > To avoid the same problem in future rename some more functions. > > Signed-off-by: Juergen Gross David, could you take this patch, please? Juergen
Re: [PATCH] Map in physical addresses in efi_map_region_fixed
On 08/17/16 at 11:00am, Alex Thorlton wrote: > On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote: > > > > Why do you guys need the physical mapping all of a sudden? > > > > > > It's not that we need it all of the sudden, necessarily, it's just that > > > we've had to make other changes to make things work with the new, > > > (almost) completely isolated, EFI page tables. We ended up choosing the > > > lesser of two evils, and have decided to temporarily rely on the > > > physical address of our runtime code, instead of continuing to rely on > > > EFI_OLD_MEMMAP. > > > > In efi_map_region, there is already mapped md->phys_addr for broken > > firmware. SGI still need EFI_OLD_MEMMAP? I means in 1st kernel instead > > of kexec kernel. > > We're actually in the middle of trying to move *away* from > EFI_OLD_MEMMAP, which is why we're just starting to uncover some of > these things. efi_map_region covers us on the primary kernel, because > it maps in the physical address of each md (as you note here), but that > little piece is missing in the kexec'd kernel. So, our primary kernel > works without efi=old_map, but the second kernel won't, without this > change (supplying "noefi" on the kexec command line also works, but then > we don't have any of our runtime stuff available). > > As noted in a previous message, we're aware that our code needs a little > more work to be "perfect," but this small change buys us most of (all > of?) the stuff we'd get by implementing the other changes that we're > aware we need to make, i.e. update our runtime function pointer to its > efi_va during SetVirtualAddressMap, at least from a kexec perspective. Thanks for explanation, I still do not get why the original ioremap way works if SetVirtualAddressMapdo does not update runtime function pointer. But if it fixes the problem in primary kernel, it should be fine to do same in kexec kernel. Thanks Dave
[PATCH v2 2/2] fs: super.c: Add tracepoint to get name of superblock shrinker
This patch adds a new tracepoint to gather specific name information
of the superblock types.
This tracepoint can be used in conjunction with mm_shrink_slab_start and
mm_shrink_slab_end to get information like latency, number of
objects scanned by that particular shrinker, etc. The shrinker struct
address printed by mm_shrink_slab_start, mm_shrink_slab_end
and the new tracepoint can help tie information together.
However, the specific superblock type can only be identified if the
while condition in do_shrink_slab() of vmscan.c is true and the
callback for the superblock shrinker is invoked.
Here's a sample output of a postprocessing script to observe how long
the shrinkers took. In this case, the while condition was true each time
and the superblock callback was invoked. The names cgroup, ext4, proc,
etc were obtained from the new tracepoint in the callback.
name:ext4_es_scan 518582ns
name:super_cache_scan/cgroup 1319939ns
name:super_cache_scan/ext4 16954600ns
name:super_cache_scan/proc 27466703ns
name:super_cache_scan/sysfs 11412903ns
name:super_cache_scan/tmpfs 71323ns
However, in cases where the callback is not invoked, it is not possible
to obtain name information from the new tracepoint. In such cases, the
output would be something like:
name:deferred_split_scan 345972ns
name:ext4_es_scan 2719002ns
name:i915_gem_shrinker_scan 10915266ns
name:scan_shadow_nodes 3349303ns
name:super_cache_scan 18970732ns
name:super_cache_scan/ext4 1293938ns
name:super_cache_scan/tmpfs 21588ns
On line 5,we can see that there were times when the super_cache_scan
callback wasn't invoked and therefore no name information was obtained.
Signed-off-by: Janani Ravichandran
---
Changes since v1:
v1 did not have any mechanism to print names of specific superblock
types . This version introduces that.
fs/super.c| 2 ++
include/trace/events/vmscan.h | 21 +
2 files changed, 23 insertions(+)
diff --git a/fs/super.c b/fs/super.c
index c2ff475..be7b493 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -35,6 +35,7 @@
#include
#include
#include "internal.h"
+#include
static LIST_HEAD(super_blocks);
@@ -64,6 +65,7 @@ static unsigned long super_cache_scan(struct shrinker *shrink,
longinodes;
sb = container_of(shrink, struct super_block, s_shrink);
+ trace_mm_shrinker_callback(shrink, sb->s_type->name);
/*
* Deadlock avoidance. We may hold various FS locks, and we don't want
diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
index 7091c29..5c8703e 100644
--- a/include/trace/events/vmscan.h
+++ b/include/trace/events/vmscan.h
@@ -283,6 +283,27 @@ TRACE_EVENT(mm_shrink_slab_end,
__entry->retval)
);
+TRACE_EVENT(mm_shrinker_callback,
+ TP_PROTO(struct shrinker *shr, const char *shrinker_name),
+
+ TP_ARGS(shr, shrinker_name),
+
+ TP_STRUCT__entry(
+ __field(struct shrinker *, shr)
+ __array(char, shrinker_name, SHRINKER_NAME_LEN)
+ ),
+
+ TP_fast_assign(
+ __entry->shr = shr;
+ strlcpy(__entry->shrinker_name, shrinker_name,
+ SHRINKER_NAME_LEN);
+ ),
+
+ TP_printk("shrinker:%p shrinker_name:%s",
+ __entry->shr,
+ __entry->shrinker_name)
+);
+
DECLARE_EVENT_CLASS(mm_vmscan_lru_isolate_template,
TP_PROTO(int classzone_idx,
--
2.7.0
Re: [PATCH v3] xen: Make VPMU init message look less scary
On 02/08/16 09:22, Juergen Gross wrote: > The default for the Xen hypervisor is to not enable VPMU in order to > avoid security issues. In this case the Linux kernel will issue the > message "Could not initialize VPMU for cpu 0, error -95" which looks > more like an error than a normal state. > > Change the message to something less scary in case the hypervisor > returns EOPNOTSUPP or ENOSYS when trying to activate VPMU. > > Signed-off-by: Juergen Gross David, could you take this patch, please? Juergen
Observing Softlockup's while running heavy IOs
Hi, Problem statement: Observing softlockups while running heavy IOs on 8 SSD drives connected behind our LSI SAS 3004 HBA. System configuration: OS & kernel version: Fedora 23, v4.2.3-300.fc23.x86_64 NUMA : disabled, CPUs : 24 logical cpus, SCSI_MQ: enabled Driver : mpt3sas, MSIx vectors: we have enabled only 2 MSIx vectors using driver module parameter 'max_msix_vectors' set to 2, IRQbalance version: v1.0.9 IRQbalance policy : 'subset' rq_affinity : 2 mpt3sas IRQs info: irq number = 219, smp_affinity = 40 affinity_hint = 000fff irq number = 220, smp_affinity = 001000 affinity_hint = fff000 issued IOs using fio tool with below parameters, iodepth=128 direct=1 runtime=300 group_reporting ioengine=libaio cpus_allowed=6,7,8,9,10,11,18,19,20,21,22,23 time_based [Ran-Read-4k-IOPs] numjobs=24 rw=randread bs=4k My Analysis: Observing a loop in the IO path, i.e only one CPU is busy with processing the interrupts and other CPUs (in the affinity_hint mask) are busy with sending the IOs (these CPUs are not yet all receiving any interrupts). For example, only CPU6 is busy with processing the interrupts from IRQ 219 and remaining CPUs i.e CPU 7,8,9,10 & 11 are just busy with pumping the IOs and they never processed any IO interrupts from IRQ 219. So we are observing softlockups due to existence this loop in the IO Path. We may not observe these softlockups if irqbalancer might have balanced the interrupts among the CPUs enabled in the particular irq's affinity_hint mask. so that all the CPUs are equaly busy with send IOs and processing the interrupts. I am not sure how irqbalancer balance the load among the CPUs, but here I see only one CPU from irq's affinity_hint mask is busy with interrupts and remaining CPUs won't receive any interrupts from this IRQ. Please help me with any suggestions/recomendations to slove/limit these kind of softlockups. Also please let me known if I have missed any setting in the irqbalance. Here is my 'sar -u ALL -P ALL 1' command output when softlock occurred, 12:16:11 PM CPU %usr %nice %sys %iowait%steal %irq %soft%guest%gnice %idle 12:16:12 PM all 6.31 0.00 31.62 4.49 0.00 0.00 2.59 0.00 0.00 54.99 12:16:12 PM 0 4.08 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 95.92 12:16:12 PM 1 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 96.00 12:16:12 PM 2 2.97 0.00 1.98 0.00 0.00 0.00 0.00 0.00 0.00 95.05 12:16:12 PM 3 7.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 92.00 12:16:12 PM 4 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 96.00 12:16:12 PM 5 4.04 0.00 1.01 0.00 0.00 0.00 0.00 0.00 0.00 94.95 12:16:12 PM 6 0.00 0.00 0.00 0.00 0.00 0.00100.00 0.00 0.00 0.00 12:16:12 PM 7 17.02 0.00 58.51 0.00 0.00 0.00 0.00 0.00 0.00 24.47 12:16:12 PM 8 14.13 0.00 61.96 23.91 0.00 0.00 0.00 0.00 0.00 0.00 12:16:12 PM 9 5.21 0.00 14.58 80.21 0.00 0.00 0.00 0.00 0.00 0.00 12:16:12 PM 10 4.21 0.00 14.74 0.00 0.00 0.00 0.00 0.00 0.00 81.05 12:16:12 PM 11 13.04 0.00 61.96 0.00 0.00 0.00 0.00 0.00 0.00 25.00 12:16:12 PM 12 0.00 0.00 0.00 0.00 0.00 0.00100.00 0.00 0.00 0.00 12:16:12 PM 13 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 96.00 12:16:12 PM 14 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 96.00 12:16:12 PM 15 3.03 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 96.97 12:16:12 PM 16 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 96.00 12:16:12 PM 17 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 96.00 12:16:12 PM 18 0.00 0.00100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:12 PM 19 16.84 0.00 69.47 0.00 0.00 0.00 0.00 0.00 0.00 13.68 12:16:12 PM 20 16.13 0.00 69.89 0.00 0.00 0.00 0.00 0.00 0.00 13.98 12:16:12 PM 21 0.00 0.00100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:12 PM 22 0.00 0.00100.00 0.00 0.00 0.00 0.00 0.00 0.
[x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75!
FYI, we noticed the following commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 5b710f34e194c6b7710f69fdb5d798fdf35b98c1 ("x86/uaccess: Enable hardened
usercopy")
in testcase: boot
on test machine: 1 threads qemu-system-i386 -enable-kvm with 360M memory
caused below changes:
+--+++
| | f5509cc18d | 5b710f34e1 |
+--+++
| boot_successes | 12 | 0 |
| boot_failures| 0 | 19 |
| kernel_BUG_at_mm/usercopy.c | 0 | 19 |
| EIP_is_at__check_object_size | 0 | 19 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 19 |
+--+++
[ 177.875629] usercopy: kernel memory overwrite attempt detected to 80028f40
() (512 bytes)
[ 177.965655] [ cut here ]
[ 177.965655] [ cut here ]
[ 177.976995] kernel BUG at mm/usercopy.c:75!
[ 177.976995] kernel BUG at mm/usercopy.c:75!
[ 177.991519] invalid opcode: [#1]
[ 177.991519] invalid opcode: [#1]
[ 178.000490] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-4-g5b710f3 #2
[ 178.000490] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-4-g5b710f3 #2
[ 178.016498] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[ 178.016498] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[ 178.037761] task: 80028000 ti: 8002a000 task.ti: 8002a000
[ 178.037761] task: 80028000 ti: 8002a000 task.ti: 8002a000
[ 178.050690] EIP: 0060:[<8110a056>] EFLAGS: 00010246 CPU: 0
[ 178.050690] EIP: 0060:[<8110a056>] EFLAGS: 00010246 CPU: 0
[ 178.064166] EIP is at __check_object_size+0x202/0x258
[ 178.064166] EIP is at __check_object_size+0x202/0x258
[ 178.076286] EAX: 0063 EBX: 80028f40 ECX: 810945ac EDX: 80028000
[ 178.076286] EAX: 0063 EBX: 80028f40 ECX: 810945ac EDX: 80028000
[ 178.091360] ESI: 817c7dfa EDI: 94b3a5a0 EBP: 8002beac ESP: 8002be7c
[ 178.091360] ESI: 817c7dfa EDI: 94b3a5a0 EBP: 8002beac ESP: 8002be7c
[ 178.116671] DS: 007b ES: 007b FS: GS: 0033 SS: 0068
[ 178.116671] DS: 007b ES: 007b FS: GS: 0033 SS: 0068
[ 178.129596] CR0: 80050033 CR2: 775e1460 CR3: 0dfbc000 CR4: 0690
[ 178.129596] CR0: 80050033 CR2: 775e1460 CR3: 0dfbc000 CR4: 0690
[ 178.154127] Stack:
[ 178.154127] Stack:
[ 178.170232] 817c7e39
[ 178.170232] 817c7e39 817c7e03 817c7e03 8184213b 8184213b 80028f40 80028f40
817c7dcc 817c7dcc 0200 0200 94b3a000 94b3a000 00028000 00028000
[ 178.205104] 0200
[ 178.205104] 0200 7ffcbc40 7ffcbc40 80028000 80028000 0200 0200
8002bf44 8002bf44 81047847 81047847 80028f40 80028f40 80028f00 80028f00
[ 178.246126]
[ 178.246126] 7ffcbbd0 7ffcbbd0
81045015 81045015 80028000 80028000 8002bef8 8002bef8 81081804 81081804
[ 178.290075] Call Trace:
[ 178.290075] Call Trace:
[ 178.303259] [<81047847>] __fpu__restore_sig+0x14f/0x439
[ 178.303259] [<81047847>] __fpu__restore_sig+0x14f/0x439
[ 178.328374] [<81045015>] ? sched_clock+0x9/0xd
[ 178.328374] [<81045015>] ? sched_clock+0x9/0xd
[ 178.350312] [<81081804>] ? sched_clock_cpu+0x19/0xc8
FYI, raw QEMU command line is:
qemu-system-i386 -enable-kvm -kernel
/pkg/linux/i386-randconfig-w0-08170631/gcc-6/5b710f34e194c6b7710f69fdb5d798fdf35b98c1/vmlinuz-4.7.0-4-g5b710f3
-append 'ip=vm-lkp-wsx03-quantal-i386-6::dhcp root=/dev/ram0 user=lkp
job=/lkp/scheduled/vm-lkp-wsx03-quantal-i386-6/boot-1-quantal-core-i386.cgz-5b710f34e194c6b7710f69fdb5d798fdf35b98c1-20160817-52554-1cf9h0a-0.yaml
ARCH=i386 kconfig=i386-randconfig-w0-08170631 branch=linus/master
commit=5b710f34e194c6b7710f69fdb5d798fdf35b98c1
BOOT_IMAGE=/pkg/linux/i386-randconfig-w0-08170631/gcc-6/5b710f34e194c6b7710f69fdb5d798fdf35b98c1/vmlinuz-4.7.0-4-g5b710f3
max_uptime=600
RESULT_ROOT=/result/boot/1/vm-lkp-wsx03-quantal-i386/quantal-core-i386.cgz/i386-randconfig-w0-08170631/gcc-6/5b710f34e194c6b7710f69fdb5d798fdf35b98c1/0
LKP_SERVER=inn debug apic=debug sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_panic=1
nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0
systemd.log_level=err ignore_loglevel earlyprintk=ttyS0,115200
console=ttyS0,115200 console=tty0 vga=normal rw drbd.minor_count=8' -initrd
/fs/sdc1/initrd-vm-lkp-wsx03-quantal-i386-6 -m 360 -smp 1 -device
e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog
i6300esb -watchdog-action debug -rtc base=localtime -pidfile
/dev/shm/kboot/pid-vm-lkp-wsx03-quantal-i386-6 -serial
fil
Re: [PATCH 2/2] dt-binding: remoteproc: Introduce ADSP loader binding
On Wed 17 Aug 10:27 PDT 2016, Bjorn Andersson wrote:
> This document defines the binding for a component that loads firmware
> and control the life cycle of the Qualcomm ADSP core.
>
> Signed-off-by: Bjorn Andersson
> ---
> .../devicetree/bindings/remoteproc/qcom,adsp.txt | 69
> ++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> new file mode 100644
> index ..077d9b6b9cd0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> @@ -0,0 +1,69 @@
> +Qualcomm ADSP Peripheral Image Loader
> +
> +This document defines the binding for a component that loads and boots
> firmware
> +on the Qualcomm ADSP core.
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be one of:
> + "qcom,adsp-pil"
This won't fly, as I moved past 8974 and 8996 to 8064 I found a few new
details that makes this slightly off, and the 8660 ADSP resources are
way off.
So it's probably better to throw in a platform identifier in the
compatible.
Regards,
Bjorn
> +
> +- interrupts-extended:
> + Usage: required
> + Value type:
> + Definition: must list the watchdog, fatal IRQs ready, handover and
> + stop-ack IRQs
> +
> +- interrupt-names:
> + Usage: required
> + Value type:
> + Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
> +
> +- cx-supply:
> + Usage: required
> + Value type:
> + Definition: reference to the regulator to be held on behalf of the
> + booting of the Hexagon core
> +
> +- memory-region:
> + Usage: required
> + Value type:
> + Definition: reference to the reserved-memory for the ADSP
> +
> +- qcom,smem-states:
> + Usage: required
> + Value type:
> + Definition: reference to the smem state for requesting the ADSP to
> + shut down
> +
> +- qcom,smem-state-names:
> + Usage: required
> + Value type:
> + Definition: must be "stop"
> +
> += EXAMPLE
> +The following example describes the resources needed to boot control the
> +ADSP, as it is found on MSM8974 boards.
> +
> + adsp {
> + compatible = "qcom,adsp-pil";
> +
> + interrupts-extended = <&intc 0 162 1>,
> + <&adsp_smp2p_in 0 0>,
> + <&adsp_smp2p_in 1 0>,
> + <&adsp_smp2p_in 2 0>,
> + <&adsp_smp2p_in 3 0>;
> + interrupt-names = "wdog",
> + "fatal",
> + "ready",
> + "handover",
> + "stop-ack";
> +
> + cx-supply = <&pm8841_s2>;
> +
> + memory-region = <&adsp_region>;
> +
> + qcom,smem-states = <&adsp_smp2p_out 0>;
> + qcom,smem-state-names = "stop";
> + };
> --
> 2.5.0
>
[PATCH v2 1/2] include: trace: Display names of shrinker callbacks
This patch enables the names of callbacks in mm_shrink_slab_start and
mm_shrink_slab_end to be seen by userspace tools.
This should give some information regarding the identity of the
shrinkers being run.
Signed-off-by: Janani Ravichandran
---
include/trace/events/vmscan.h | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
index c88fd09..7091c29 100644
--- a/include/trace/events/vmscan.h
+++ b/include/trace/events/vmscan.h
@@ -16,6 +16,8 @@
#define RECLAIM_WB_SYNC0x0004u /* Unused, all reclaim async */
#define RECLAIM_WB_ASYNC 0x0008u
+#define SHRINKER_NAME_LEN (size_t)32
+
#define show_reclaim_flags(flags) \
(flags) ? __print_flags(flags, "|", \
{RECLAIM_WB_ANON, "RECLAIM_WB_ANON"}, \
@@ -196,6 +198,7 @@ TRACE_EVENT(mm_shrink_slab_start,
TP_STRUCT__entry(
__field(struct shrinker *, shr)
__field(void *, shrink)
+ __array(char, shrinker_name, SHRINKER_NAME_LEN)
__field(int, nid)
__field(long, nr_objects_to_shrink)
__field(gfp_t, gfp_flags)
@@ -207,8 +210,12 @@ TRACE_EVENT(mm_shrink_slab_start,
),
TP_fast_assign(
+ char sym[KSYM_SYMBOL_LEN];
+
__entry->shr = shr;
__entry->shrink = shr->scan_objects;
+ sprint_symbol(sym, (unsigned long)__entry->shrink);
+ strlcpy(__entry->shrinker_name, sym, SHRINKER_NAME_LEN);
__entry->nid = sc->nid;
__entry->nr_objects_to_shrink = nr_objects_to_shrink;
__entry->gfp_flags = sc->gfp_mask;
@@ -219,9 +226,10 @@ TRACE_EVENT(mm_shrink_slab_start,
__entry->total_scan = total_scan;
),
- TP_printk("%pF %p: nid: %d objects to shrink %ld gfp_flags %s
pgs_scanned %ld lru_pgs %ld cache items %ld delta %lld total_scan %ld",
+ TP_printk("%pF %p name:%s nid: %d objects to shrink %ld gfp_flags %s
pgs_scanned %ld lru_pgs %ld cache items %ld delta %lld total_scan %ld",
__entry->shrink,
__entry->shr,
+ __entry->shrinker_name,
__entry->nid,
__entry->nr_objects_to_shrink,
show_gfp_flags(__entry->gfp_flags),
@@ -242,6 +250,7 @@ TRACE_EVENT(mm_shrink_slab_end,
TP_STRUCT__entry(
__field(struct shrinker *, shr)
__field(int, nid)
+ __array(char, shrinker_name, SHRINKER_NAME_LEN)
__field(void *, shrink)
__field(long, unused_scan)
__field(long, new_scan)
@@ -250,18 +259,23 @@ TRACE_EVENT(mm_shrink_slab_end,
),
TP_fast_assign(
+ char sym[KSYM_SYMBOL_LEN];
+
__entry->shr = shr;
__entry->nid = nid;
__entry->shrink = shr->scan_objects;
+ sprint_symbol(sym, (unsigned long)__entry->shrink);
+ strlcpy(__entry->shrinker_name, sym, SHRINKER_NAME_LEN);
__entry->unused_scan = unused_scan_cnt;
__entry->new_scan = new_scan_cnt;
__entry->retval = shrinker_retval;
__entry->total_scan = total_scan;
),
- TP_printk("%pF %p: nid: %d unused scan count %ld new scan count %ld
total_scan %ld last shrinker return val %d",
+ TP_printk("%pF %p name:%s nid: %d unused scan count %ld new scan count
%ld total_scan %ld last shrinker return val %d",
__entry->shrink,
__entry->shr,
+ __entry->shrinker_name,
__entry->nid,
__entry->unused_scan,
__entry->new_scan,
--
2.7.0
[PATCH v2 0/2] Get callbacks/names of shrinkers from tracepoints
Currently, it is not possible to know which shrinkers are being run. Even though the callbacks are printed using %pF in tracepoints mm_shrink_slab_start and mm_shrink_slab_end, they are not visible to userspace tools like perf. To address this, this patchset 1. Enables the display of names of shrinker callbacks in tracepoints mm_shrink_slab_start and mm_shrink_slab_end. 2. Adds a new tracepoint in the callback of the superblock shrinker to get specific names of superblock types. Changes since v1 at https://lkml.org/lkml/2016/7/9/33: 1. This patchset does not introduce a new variable to hold names of shrinkers, unlike v1. It makes mm_shrink_slab_start and mm_shrink_slab_end print names of callbacks instead. 2. It also adds a new tracepoint for superblock shrinkers to display more specific name information, which v1 did not do. Thanks to Dave Chinner and Tony Jones for their suggestions. Janani Ravichandran (2): include: trace: Display names of shrinker callbacks fs: super.c: Add tracepoint to get name of superblock shrinker fs/super.c| 2 ++ include/trace/events/vmscan.h | 39 +-- 2 files changed, 39 insertions(+), 2 deletions(-) -- 2.7.0
Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver
> I have just some minor comments below
Appreciate your review.
>> diff --git a/drivers/char/hw_random/jz4780-rng.c
>> b/drivers/char/hw_random/jz4780-rng.c
>> new file mode 100644
>> index 000..c9d2cde
>> --- /dev/null
>> +++ b/drivers/char/hw_random/jz4780-rng.c
>> @@ -0,0 +1,105 @@
>> +/*
>> + * jz4780-rng.c - Random Number Generator driver for J4780
>> + *
>> + * Copyright 2016 (C) PrasannaKumar Muralidharan
>>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> You could sort them by alphabetical order
Sure, will do.
>> +
>> +#define REG_RNG_CTRL 0x0
>> +#define REG_RNG_DATA 0x4
>> +
>> +struct jz4780_rng {
>> + struct device *dev;
>> + struct hwrng rng;
>> + void __iomem *mem;
>> +};
>> +
>> +static u32 jz4780_rng_readl(struct jz4780_rng *rng, u32 offset)
>> +{
>> + return readl(rng->mem + offset);
>> +}
>> +
>> +static void jz4780_rng_writel(struct jz4780_rng *rng, u32 val, u32 offset)
>> +{
>> + writel(val, rng->mem + offset);
>> +}
>> +
>> +static int jz4780_rng_read(struct hwrng *rng, void *buf, size_t max, bool
>> wait)
>> +{
>> + struct jz4780_rng *jz4780_rng = container_of(rng, struct jz4780_rng,
>> + rng);
>> + u32 *data = buf;
>> + *data = jz4780_rng_readl(jz4780_rng, REG_RNG_DATA);
>> + return 4;
>> +}
>
> If max is less than 4, its bad
Data will be 4 bytes.
>> +
>> +static int jz4780_rng_probe(struct platform_device *pdev)
>> +{
>> + struct jz4780_rng *jz4780_rng;
>> + struct resource *res;
>> + resource_size_t size;
>> + int ret;
>> +
>> + jz4780_rng = devm_kzalloc(&pdev->dev, sizeof(struct jz4780_rng),
>> + GFP_KERNEL);
>
> You could write sizeof(*js480_rng)
Will do.
>> + if (!jz4780_rng)
>> + return -ENOMEM;
>> +
>> + jz4780_rng->dev = &pdev->dev;
>> + jz4780_rng->rng.name = "jz4780";
>> + jz4780_rng->rng.read = jz4780_rng_read;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + size = resource_size(res);
>> +
>> + jz4780_rng->mem = devm_ioremap(&pdev->dev, res->start, size);
> You could save code by using devm_ioremap_resource (don't need size)
Will do.
>> + if (IS_ERR(jz4780_rng->mem))
>> + return PTR_ERR(jz4780_rng->mem);
>> +
>> + platform_set_drvdata(pdev, jz4780_rng);
>> + jz4780_rng_writel(jz4780_rng, 1, REG_RNG_CTRL);
>> + ret = hwrng_register(&jz4780_rng->rng);
>> +
>> + return ret;
>> +}
> You could write directly return hwrng_register(..)
Will do.
Re: [PATCH v2 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller
On Thursday 18 August 2016 09:20 AM, Dawei Chien wrote: This adds the device tree binding documentation for the mediatek thermal controller found on Mediatek MT2701. Reviewed-by: Keerthy Signed-off-by: Dawei Chien --- .../bindings/thermal/mediatek-thermal.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt index 81f9a51..e2f494d 100644 --- a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt @@ -8,7 +8,9 @@ apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS is also needed. Required properties: -- compatible: "mediatek,mt8173-thermal" +- compatible: + - "mediatek,mt8173-thermal" : For MT8173 family of SoCs + - "mediatek,mt2701-thermal" : For MT2701 family of SoCs - reg: Address range of the thermal controller - interrupts: IRQ for the thermal controller - clocks, clock-names: Clocks needed for the thermal controller. required
linux-next: Tree for Aug 18
Hi all, Changes since 20160817: New tree: vfs-miklos Removed trees: powerpc-merge-mpe, powerpc-mpe (no longer used) The netfilter-next tree gained a build failure so I used the version from next-20160817. The kbuild tree still had its build warnings for PowerPC, for which I reverted a commit. Non-merge commits (relative to Linus' tree): 2513 2682 files changed, 111802 insertions(+), 41622 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 (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 240 trees (counting Linus' and 34 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 Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (5ff132c07aa1 Merge tag 'for-v4.8-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply) Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when not configured) Merging arc-current/for-curr (b854f5e83bb2 ARC: Support syscall ABI v4) Merging arm-current/fixes (87eed3c74d7c ARM: fix address limit restoration for undefined instructions) Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs for v4.7-rc2) Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init()) Merging powerpc-fixes/fixes (ca49e64f0cb1 selftests/powerpc: Specify we expect to build with std=gnu99) Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support is disabled) Merging net/master (b96c22c071eb Merge branch 'tc_action-fixes') Merging ipsec/master (1625f4529957 net/xfrm_input: fix possible NULL deref of tunnel.ip6->parms.i_key) Merging netfilter/master (dcbe35909c84 netfilter: tproxy: properly refcount tcp listeners) Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes') Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git) Merging mac80211/master (4d0bd46a4d55 Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel") Merging sound-current/for-linus (a52ff34e5ec6 ALSA: hda - Manage power well properly for resume) Merging pci-current/for-linus (a855d4d8e71f PCI: Call pci_intx() when using legacy interrupts in pci_alloc_irq_vectors()) Merging driver-core.current/driver-core-linus (694d0d0bb203 Linux 4.8-rc2) Merging tty.current/tty-linus (29b4817d4018 Linux 4.8-rc1) Merging usb.current/usb-linus (f1f6d9a8b540 xhci: don't dereference a xhci member after removing xhci) Merging usb-gadget-fixes/fixes (a0ad85ae866f usb: dwc3: gadget: stop processing on HWO set) Merging usb-serial-fixes/usb-linus (3b7c7e52efda USB: serial: mos7840: fix non-atomic allocation in write path) Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: otg-fsm: add license to usb-otg-fsm) Merging staging.current/staging-linus (99f1c013194e staging/lustre/llite: Close atomic_open race with several openers) Merging char-misc.current/char-misc-linus (83cf8df2d4fa drivers/iio/light/Kconfig: SENSORS_BH1780 cleanup) Merging input-current/for-linus (22fe874f3803 Input: silead - remove some dead code) Merging crypto-current/master (e67479b13ede crypto: sha512-mb - fix ctx pointer) Merging ide/master (797cee982eef Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit) Merging rr-fixes/fixes (82
Re: perf: fuzzer: spinlock hang
On Wed, 17 Aug 2016, Peter Zijlstra wrote: > On Tue, Aug 09, 2016 at 11:51:48AM -0400, Vince Weaver wrote: > > > > So still haswell/4.8-rc1, after 6 hours of fuzzing this is where the > > system finally locked up permanently. > > > > It looks like some sort of spinlock error. > > The logs continued being spammed with this stuff overnight until I > > finally put it out of its misery, but I think just the beginning here > > is the relevant part. > > That sadly looks vaguely familiar... I think its the point where I gave > up chasing bugs last year, because I was going soft in the head staring > at this stuff for several months non-stop. > > It taking several hours to reproduce didn't help. > > I suspect its something iffy with the Intel driver, because I could > never trigger it on AMD, but of course, no guarantees ... I'm working on getting an AMD and an ARM box fuzzing along (in addition to the Haswell and Core2 box), maybe that will help narrow down if it's an Intel issue or not. If you're lucky I'll run out of time once classes start up next week and you won't have any more fuzz reports until January (well, probably November, as I'll need some material for the fuzzing microconference at Linux Plumbers). Vince
[PATCH] fib_trie: Fix the description of pos and bits
1) Fix one typo: s/tn/tp/ 2) Fix the description about the "u" bits. Signed-off-by: Xunlei Pang --- net/ipv4/fib_trie.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c index d07fc07..eb7c5d1 100644 --- a/net/ipv4/fib_trie.c +++ b/net/ipv4/fib_trie.c @@ -249,7 +249,7 @@ static inline unsigned long get_index(t_key key, struct key_vector *kv) * index into the parent's child array. That is, they will be used to find * 'n' among tp's children. * - * The bits from (n->pos + n->bits) to (tn->pos - 1) - "S" - are skipped bits + * The bits from (n->pos + n->bits) to (tp->pos - 1) - "S" - are skipped bits * for the node n. * * All the bits we have seen so far are significant to the node n. The rest @@ -258,7 +258,7 @@ static inline unsigned long get_index(t_key key, struct key_vector *kv) * The bits from (n->pos) to (n->pos + n->bits - 1) - "C" - are the index into * n's child array, and will of course be different for each child. * - * The rest of the bits, from 0 to (n->pos + n->bits), are completely unknown + * The rest of the bits, from 0 to (n->pos -1) - "u" - are completely unknown * at this point. */ -- 1.8.3.1
Re: perf: rdpmc and PERF_EVENT_IOC_RESET
On Wed, 17 Aug 2016, Peter Zijlstra wrote: > Hurm.. I never considered using RESET with rdpmc(). The typical usage of > rdpmc() I considered is something like: I'm finally trying to hook up PAPI to properly use rdpmc and PAPI likes to use IOC_RESET in various places. I can just special case to not do so when in rdpmc mode, but I got curious if RESET was expected to work. > But the rdpmc user function should: > ... > > Which sign-extends the RDPMC result and adds it to userpg->offset, > resulting in a positive number again. I will have to check to see if PAPI is using the proper code. What happens is the procesed result has bit 49 set for some reason, so the results are 2^49 too big. I've been trying to track it down, but the PAPI code is a bit of a mess (to put it mildly). Vince
Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement
On Wed, Aug 17, 2016 at 08:54:11PM -0700, Huang, Ying wrote: > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx > est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic > popcnt tsc_deadline_timer aes xsave avx lahf_lm tpr_shadow vnmi flexpriority > ept vpid xsaveopt dtherm ida arat pln pts ^^ There it is. So if there's no bug, alternatives should replace all "call __sw_hweightXX" calls with POPCNT. So you shouldn't be even calling these functions and hitting that path. Can you boot the kernel with "debug-alternative" and put that dmesg somewhere along with vmlinux for me to stare at? Privately is fine too. I'd like to make sure the alternatives application actually happens. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement
On August 17, 2016 8:45:13 PM PDT, Borislav Petkov wrote: >On Wed, Aug 17, 2016 at 03:29:04PM -0700, Huang, Ying wrote: >> branch-miss-rate decreased from ~0.30% to ~0.043%. >> >> So I guess there are some code alignment change, which caused >decreased >> branch miss rate. > >Hrrm, I still can't imagine how that would happen if the machine >supports POPCNT and we never call the __sw_hweight* variants. Or does >it? > >Can you paste /proc/cpuinfo from that Sandy Bridge-EP box? > >Thanks. popcnt was introduced in Nehalem AFAIK, two generations before Sandy Bridge. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement
Borislav Petkov writes: > On Wed, Aug 17, 2016 at 03:29:04PM -0700, Huang, Ying wrote: >> branch-miss-rate decreased from ~0.30% to ~0.043%. >> >> So I guess there are some code alignment change, which caused decreased >> branch miss rate. > > Hrrm, I still can't imagine how that would happen if the machine > supports POPCNT and we never call the __sw_hweight* variants. Or does > it? > > Can you paste /proc/cpuinfo from that Sandy Bridge-EP box? Here it is. processor : 31 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz stepping: 6 microcode : 0x603 cpu MHz : 3158.129 cache size : 20480 KB physical id : 1 siblings: 16 core id : 7 cpu cores : 8 apicid : 47 initial apicid : 47 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts bugs: bogomips: 5392.85 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: Best Regards, Huang, Ying
[PATCH v2 0/3] Add Mediatek thermal driver for mt2701
This series support for mt2701 chip to mtk_thermal.c, and integrate both mt8173 and mt2701 on the same driver. MT8173 has four banks and five sensors, and MT2701 has only one bank and three sensors. Change since V1: 1. Restore macro name with MT8173 for nvmem calibration data since original macro name could be used for both MT2701/MT8173. 2. Add flexible array member to instead of normal array since thermal bank has different array size between MT2701 to MT8173. Dawei Chien (3): dt-bindings: thermal: Add binding document for Mediatek thermal controller thermal: Add Mediatek thermal driver for mt2701. arm: dts: thermal: add thermal/auxadc node. .../bindings/thermal/mediatek-thermal.txt |4 +- arch/arm/boot/dts/mt2701.dtsi | 44 drivers/thermal/mtk_thermal.c | 215 ++-- 3 files changed, 199 insertions(+), 64 deletions(-)
ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?
Consider below test case (not all of it is necessary for reproducing
the behavior in question, but I wanted to cover related cases as well
to make sure they behave as expected). In this test case, the last
group-stop (after PTRACE_INTERRUPT) is delivered with a
WSTOPSIG(status) of SIGTTIN, which was the signr of the previous group
stop. From reading the man-page, I would have expected SIGTRAP. Now, I
understand that if there is another stop pending, PTRACE_INTERRUPT
will simply piggy-backs off that one, but I don't believe that is
happening in this case. Further, the current behavior seems to make it
very hard (impossible?) to reliably tell a true group-stop from a
PTRACE_INTERRUPT generated one. Is this behavior intended? If so, I
would be happy to update the man page accordingly, but would like some
guidance on what the intended semantics are.
```
#include
#include
#include
#include
#include
#include
#include
#include
int main() {
pid_t child, ret;
int err;
int status;
if (0 == (child = fork())) {
kill(getpid(), SIGSTOP);
kill(getpid(), SIGSTOP);
kill(getpid(), SIGTTIN);
sleep(1000);
exit(0);
}
ret = waitpid(child, &status, WSTOPPED);
assert(ret == child);
err = ptrace(PTRACE_SEIZE, child, NULL, NULL);
assert(err == 0);
err = ptrace(PTRACE_CONT, child, NULL, NULL);
assert(err == 0);
// Should now hit SIGSTOP signal-stop
ret = waitpid(child, &status, 0);
assert(ret == child && WIFSTOPPED(status) && WSTOPSIG(status) == SIGSTOP);
err = ptrace(PTRACE_CONT, child, NULL, (void*)SIGSTOP);
assert(err == 0);
// Should now hit SIGSTOP group-stop
ret = waitpid(child, &status, 0);
assert(ret == child && (status>>16 == PTRACE_EVENT_STOP) &&
WSTOPSIG(status) == SIGSTOP);
err = ptrace(PTRACE_CONT, child, NULL, NULL);
assert(err == 0);
// Should now hit SIGTTIN signal-stop
ret = waitpid(child, &status, 0);
assert(ret == child && WIFSTOPPED(status) && WSTOPSIG(status) == SIGTTIN);
err = ptrace(PTRACE_CONT, child, NULL, (void*)SIGTTIN);
assert(err == 0);
// Should now hit SIGTTIN group-stop
ret = waitpid(child, &status, 0);
assert(ret == child && (status>>16 == PTRACE_EVENT_STOP) &&
WSTOPSIG(status) == SIGTTIN);
err = ptrace(PTRACE_CONT, child, NULL, NULL);
assert(err == 0);
// Now interrupt it
err = ptrace(PTRACE_INTERRUPT, child, NULL, NULL);
assert(err == 0);
// Should now hit interrupt group-stop
ret = waitpid(child, &status, 0);
printf("Interrupt group-stop delivered with signal %d\n", WSTOPSIG(status));
assert(ret == child && (status>>16 == PTRACE_EVENT_STOP) &&
WSTOPSIG(status) == SIGTRAP);
exit(0);
}
```
[PATCH v2 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller
This adds the device tree binding documentation for the mediatek thermal controller found on Mediatek MT2701. Signed-off-by: Dawei Chien --- .../bindings/thermal/mediatek-thermal.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt index 81f9a51..e2f494d 100644 --- a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt @@ -8,7 +8,9 @@ apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS is also needed. Required properties: -- compatible: "mediatek,mt8173-thermal" +- compatible: + - "mediatek,mt8173-thermal" : For MT8173 family of SoCs + - "mediatek,mt2701-thermal" : For MT2701 family of SoCs - reg: Address range of the thermal controller - interrupts: IRQ for the thermal controller - clocks, clock-names: Clocks needed for the thermal controller. required -- 1.7.9.5
[PATCH v2 3/3] arm: dts: thermal: add thermal/auxadc node.
This adds the thermal controller and auxadc nodes
to the Mediatek MT2701 dtsi file.
Signed-off-by: Dawei Chien
---
This patch depned on:
https://patchwork.kernel.org/patch/9249589/
---
arch/arm/boot/dts/mt2701.dtsi | 44 +
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index e9150a4..cee4724 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -87,6 +87,36 @@
clock-output-names = "rtc32k";
};
+ thermal-zones {
+ cpu_thermal: cpu_thermal {
+ polling-delay-passive = <1000>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+
+ thermal-sensors = <&thermal 0>;
+ sustainable-power = <1000>;
+
+ trips {
+ threshold: trip-point@0 {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ target: trip-point@1 {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_crit: cpu_crit@0 {
+ temperature = <115000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <&gic>;
@@ -222,4 +252,18 @@
clock-names = "baud", "bus";
status = "disabled";
};
+
+ thermal: thermal@1100b000 {
+ #thermal-sensor-cells = <0>;
+ compatible = "mediatek,mt2701-thermal";
+ reg = <0 0x1100b000 0 0x1000>;
+ interrupts = ;
+ clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
+ clock-names = "therm", "auxadc";
+ resets = <&pericfg 0x10>;
+ reset-names = "therm";
+ mediatek,auxadc = <&auxadc>;
+ mediatek,apmixedsys = <&apmixedsys>;
+ };
+
};
--
1.7.9.5
[PATCH v2 2/3] thermal: Add Mediatek thermal driver for mt2701.
This patch adds support for mt2701 chip to mtk_thermal,
and integrate both mt8173 and mt2701 on the same driver.
MT8173 has four banks and five sensors, and MT2701 has
only one bank and three sensors.
Signed-off-by: Dawei Chien
---
This patch dependents on "Add clock support for Mediatek MT2701"[1].
Please accept this patch together with [1].
[1]http://lists.infradead.org/pipermail/linux-mediatek/2016-August/006620.html
---
drivers/thermal/mtk_thermal.c | 215 +
1 file changed, 152 insertions(+), 63 deletions(-)
diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 262ab0a..7b233c7 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -2,6 +2,7 @@
* Copyright (c) 2015 MediaTek Inc.
* Author: Hanyi Wu
* Sascha Hauer
+ * Dawei Chien
*
* 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
@@ -21,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -88,6 +90,7 @@
#define TEMP_ADCVALIDMASK_VALID_HIGH BIT(5)
#define TEMP_ADCVALIDMASK_VALID_POS(bit) (bit)
+/* MT8173 thermal sensors */
#define MT8173_TS1 0
#define MT8173_TS2 1
#define MT8173_TS3 2
@@ -106,7 +109,12 @@
/* The number of sensing points per bank */
#define MT8173_NUM_SENSORS_PER_ZONE4
-/* Layout of the fuses providing the calibration data */
+/*
+ * Layout of the fuses providing the calibration data
+ * These macros could be used for both MT8173 and MT2701.
+ * MT8173 has five sensors and need five VTS calibration data,
+ * and MT2701 has three sensors and need three VTS calibration data.
+ */
#define MT8173_CALIB_BUF0_VALIDBIT(0)
#define MT8173_CALIB_BUF1_ADC_GE(x)(((x) >> 22) & 0x3ff)
#define MT8173_CALIB_BUF0_VTS_TS1(x) (((x) >> 17) & 0x1ff)
@@ -117,24 +125,50 @@
#define MT8173_CALIB_BUF0_DEGC_CALI(x) (((x) >> 1) & 0x3f)
#define MT8173_CALIB_BUF0_O_SLOPE(x) (((x) >> 26) & 0x3f)
+/* MT2701 thermal sensors */
+#define MT2701_TS1 0
+#define MT2701_TS2 1
+#define MT2701_TSABB 2
+
+/* AUXADC channel 11 is used for the temperature sensors */
+#define MT2701_TEMP_AUXADC_CHANNEL 11
+
+/* The total number of temperature sensors in the MT2701 */
+#define MT2701_NUM_SENSORS 3
+
#define THERMAL_NAME"mtk-thermal"
+/* The number of sensing points per bank */
+#define MT2701_NUM_SENSORS_PER_ZONE3
+
struct mtk_thermal;
+struct thermal_bank_cfg {
+ unsigned int num_sensors;
+ const int *sensors;
+};
+
struct mtk_thermal_bank {
struct mtk_thermal *mt;
int id;
};
+struct mtk_thermal_data {
+ s32 num_banks;
+ s32 num_sensors;
+ s32 auxadc_channel;
+ const int *sensor_mux_values;
+ const int *msr;
+ const int *adcpnp;
+ struct thermal_bank_cfg bank_data[];
+};
+
struct mtk_thermal {
struct device *dev;
void __iomem *thermal_base;
struct clk *clk_peri_therm;
struct clk *clk_auxadc;
-
- struct mtk_thermal_bank banks[MT8173_NUM_ZONES];
-
/* lock: for getting and putting banks */
struct mutex lock;
@@ -144,16 +178,44 @@ struct mtk_thermal {
s32 o_slope;
s32 vts[MT8173_NUM_SENSORS];
+ const struct mtk_thermal_data *conf;
+ struct mtk_thermal_bank banks[];
};
-struct mtk_thermal_bank_cfg {
- unsigned int num_sensors;
- unsigned int sensors[MT8173_NUM_SENSORS_PER_ZONE];
+/* MT8173 thermal sensor data */
+const int mt8173_bank_data[MT8173_NUM_ZONES][3] = {
+ { MT8173_TS2, MT8173_TS3 },
+ { MT8173_TS2, MT8173_TS4 },
+ { MT8173_TS1, MT8173_TS2, MT8173_TSABB },
+ { MT8173_TS2 },
};
-static const int sensor_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
+const int mt8173_msr[MT8173_NUM_SENSORS_PER_ZONE] = {
+ TEMP_MSR0, TEMP_MSR1, TEMP_MSR2, TEMP_MSR2
+};
-/*
+const int mt8173_adcpnp[MT8173_NUM_SENSORS_PER_ZONE] = {
+ TEMP_ADCPNP0, TEMP_ADCPNP1, TEMP_ADCPNP2, TEMP_ADCPNP3
+};
+
+const int mt8173_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
+
+/* MT2701 thermal sensor data */
+const int mt2701_bank_data[MT2701_NUM_SENSORS] = {
+ MT2701_TS1, MT2701_TS2, MT2701_TSABB
+};
+
+const int mt2701_msr[MT2701_NUM_SENSORS_PER_ZONE] = {
+ TEMP_MSR0, TEMP_MSR1, TEMP_MSR2
+};
+
+const int mt2701_adcpnp[MT2701_NUM_SENSORS_PER_ZONE] = {
+ TEMP_ADCPNP0, TEMP_ADCPNP1, TEMP_ADCPNP2
+};
+
+const int mt2701_mux_values[MT2701_NUM_SENSORS] = { 0, 1, 16 };
+
+/**
* The MT8173 thermal controller has four banks. Each bank can read up to
* four temperature sensors simultaneously. The MT8173 has a total of 5
* temperature sensors. We use each bank to measure a certain area of the
@@ -166,42 +228,53 @@ static const int sensor_mux_values[MT8173_NUM_SENSORS] =
{ 0, 1, 2, 3, 16 };
* data, and this indeed
Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement
On Wed, Aug 17, 2016 at 03:29:04PM -0700, Huang, Ying wrote: > branch-miss-rate decreased from ~0.30% to ~0.043%. > > So I guess there are some code alignment change, which caused decreased > branch miss rate. Hrrm, I still can't imagine how that would happen if the machine supports POPCNT and we never call the __sw_hweight* variants. Or does it? Can you paste /proc/cpuinfo from that Sandy Bridge-EP box? Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
RE: Support for configurable PCIe endpoint
> -Original Message- > From: Kishon Vijay Abraham I [mailto:kis...@ti.com] > Sent: Thursday, August 04, 2016 6:02 PM > To: Joao Pinto ; bhelg...@google.com; linux- > p...@vger.kernel.org; a...@arndb.de; Jingoo Han ; > Pratyush Anand > Cc: Ley Foon Tan ; Rob Herring ; > Tanmay Inamdar ; Roy Zang fei.z...@freescale.com>; Mingkai Hu ; > Minghuan Lian ; Richard Zhu > ; Lucas Stach ; > Murali Karicheri ; Thomas Petazzoni > ; Jason Cooper > ; Thierry Reding ; > Simon Horman ; Zhou Wang > ; Gabriele Paoloni > ; Stanimir Varbanov sol.com>; David Daney ; linux- > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > o...@vger.kernel.org; Carlos Palminha > > Subject: Re: Support for configurable PCIe endpoint > > Hi, > > On Wednesday 03 August 2016 07:09 PM, Joao Pinto wrote: > > Hi Kishon, > > > > On 8/3/2016 7:03 AM, Kishon Vijay Abraham I wrote: > >> Hi, > >> > >> The PCIe controller present in TI's DRA7 SoC is capable of operating > >> either in Root Complex mode or Endpoint mode. (It uses Synopsys > >> Designware Core). I'd assume most of the PCIe controllers on other > >> platforms that use Designware core should also be capable to operate > >> in endpoint mode. But linux kernel right now supports only RC mode. > >> > >> PCIe endpoint support discussion came up briefly before [1] but it > >> was felt the practical use case will find firmware more suitable and > >> endpoint support in kernel can be used only for validation or demo. > >> > >> *) Modify platform driver to support EP mode (in my case pci-dra7xx.c). > >> > >> *) dt binding specific to EP mode should be created. > >> > >> Once I complete the implementation and start posting RFC patches, a > >> lot of these will become clear. But I want to check if this sounds > >> okay to you guys before starting the implementation. > >> > >> Let me know if you have some other ideas too. > >> > >> Cheers > >> Kishon > >> > >> [1] -> http://www.spinics.net/lists/linux-pci/msg26026.html > >> > > > > You are rising a topic that we are also addressing in Synopsys. > > > > For the PCIe RC hardware validation we are currently using the > > standard pcie-designware and pcie-designware-plat drivers. > > > > For the Endpoint we have to use an internal software package. Its main > > purpose is to initialize the IP registers, eDMA channels and make data > > transfer to prove that the everything is working properly. This is > > done in 2 levels, a custom driver built and loaded and an application > > that makes some ioctl to the driver executing some interesting > > functions to check the Endpoint status and make some data exchange. > > hmm.. the platform I have doesn't have a DMA in PCIe IP > (http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf). So in your testing does > the EP access RC memory? i.e the driver in the RC allocates memory from it's > DDR and gives it's DDR address to the EP. The EP then transfers data to this > address. (This is a typical use case with ethernet PCIe cards). IIUC that's > not > simple with configurable EPs. I'd like to know more about your testing though. > Hi Kishon, This is a typical user case for EP to use DMA transfer data to/from RC memory. In our case, we implement ring (like BD ring) or register in EP to communicate The address allocated in RC memory, then EP can transfer data to/from RC memory. Thanks, Mingkai
Re: [PATCH] zram: clean up valid_io_request
Hi, On (08/18/16 11:08), Shawn Lin wrote: [..] > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > index 04365b1..1094e95 100644 > --- a/drivers/block/zram/zram_drv.c > +++ b/drivers/block/zram/zram_drv.c > @@ -120,15 +120,15 @@ static inline bool valid_io_request(struct zram *zram, > u64 end, bound; > > /* unaligned request */ > - if (unlikely(start & (ZRAM_SECTOR_PER_LOGICAL_BLOCK - 1))) > + if (unlikely(!IS_ALIGNED(start, ZRAM_SECTOR_PER_LOGICAL_BLOCK))) > return false; > - if (unlikely(size & (ZRAM_LOGICAL_BLOCK_SIZE - 1))) > + if (unlikely(!IS_ALIGNED(size, ZRAM_LOGICAL_BLOCK_SIZE))) > return false; ok. > end = start + (size >> SECTOR_SHIFT); > bound = zram->disksize >> SECTOR_SHIFT; > /* out of range range */ > - if (unlikely(start >= bound || end > bound || start > end)) > + if (unlikely(start >= bound || end > bound)) > return false; why did you drop `start > end'? what if `start + (size >> SECTOR_SHIFT)' overflows and `start' becomes greater than `end'? -ss
Re: Context switch latency in tickless isolated CPU
Hi Chris, Thanks for your reply. Is the increased time fixed in each context switch? Because this increased time will be the latency of the real time application, we hope to confirm it. Thanks. Regards, - Kang On Wed, Aug 17, 2016 at 8:18 PM, Chris Metcalf wrote: > On 8/17/2016 2:26 AM, GeHao Kang wrote: >> >> To investigate the cause, I use the kernel event tracer to find out >> the events, user_enter and user_exit, of context_tracking would happen >> on tickless isolated CPU. These two events means that this CPU enters >> and exits the RCU extended quiescent state. Besides, the execution >> time of these two events are 3us and 2us, >> which are measured by ktime. Is this the reason why the context switch >> has higher >> latency on the tickless isolated CPU? > > > The increased context switch time is likely from the increased > time to return from the kernel to userspace, due to ensuring > that various things in the kernel are quiesced. > > Of course I'm sure it goes without saying that context switch > time is probably near the absolute bottom of things that > we care about as a metric for task isolation, since when you > are using it as designed, you never actually context switch. > But that said, it's always good to quantify what the overheads > are, so thanks. > > -- > Chris Metcalf, Mellanox Technologies > http://www.mellanox.com >
Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression
On Thu, Aug 18, 2016 at 02:06:50AM +0800, Xin Long wrote:
> >
> > It doesn't seem memory is an issue.
> >
> > The whole dump is about the same.
> > The MemFree and MemAvailable doesn't change much.
> >
> Hi, Aaron
>
> 1)
> I talked with Marcelo about this one.
> He said it might be related with cacheline. the new field distroyed
> the prior cacheline. So on top of commit 826d253d57b1, pls only add
> + unsigned long prsctp_param;
>
> to the end of struct sctp_chunk, then try.
This doesn't work.
> 2)
> if 1) still doesn't work, I may think about to drop prsctp_param in
> sctp_chunk, and reuse msg->expire_at. as for sent_count, I will
> put it to the mem hole of sctp_chunk.
>
> So pls also try the attachment patch, on top of commit a6c2f792873a
Good news, this brings the performance back on my Sandybridge desktop :)
I have queued jobs to the Ivybridge test box but I guess the result is
the same, but will let you know if it isn't.
It looks like the size of the structure plays a role here, but not clear
to me what happened underneath. Do you know why?
Thanks,
Aaron
>
> Thanks.
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 6bcda71..008cb76 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -524,7 +524,11 @@ struct sctp_datamsg {
> struct list_head chunks;
> /* Reference counting. */
> atomic_t refcnt;
> - /* When is this message no longer interesting to the peer? */
> + /* Re-use this field to record param for prsctp policies,
> + * for TTL policy, it is the time_to_drop of this chunk,
> + * for RTX policy, it is the max_sent_count of this chunk,
> + * for PRIO policy, it is the priority of this chunk.
> + */
> unsigned long expires_at;
> /* Did the messenge fail to send? */
> int send_error;
> @@ -553,6 +557,9 @@ struct sctp_chunk {
>
> atomic_t refcnt;
>
> + /* How many times this chunk have been sent, for prsctp RTX policy */
> + int sent_count;
> +
> /* This is our link to the per-transport transmitted list. */
> struct list_head transmitted_list;
>
> @@ -602,16 +609,6 @@ struct sctp_chunk {
> /* This needs to be recoverable for SCTP_SEND_FAILED events. */
> struct sctp_sndrcvinfo sinfo;
>
> - /* We use this field to record param for prsctp policies,
> - * for TTL policy, it is the time_to_drop of this chunk,
> - * for RTX policy, it is the max_sent_count of this chunk,
> - * for PRIO policy, it is the priority of this chunk.
> - */
> - unsigned long prsctp_param;
> -
> - /* How many times this chunk have been sent, for prsctp RTX policy */
> - int sent_count;
> -
> /* Which association does this belong to? */
> struct sctp_association *asoc;
>
> diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
> index 2698d12..0c53d64 100644
> --- a/net/sctp/chunk.c
> +++ b/net/sctp/chunk.c
> @@ -349,7 +349,7 @@ int sctp_chunk_abandoned(struct sctp_chunk *chunk)
> }
>
> if (SCTP_PR_TTL_ENABLED(chunk->sinfo.sinfo_flags) &&
> - time_after(jiffies, chunk->prsctp_param)) {
> + time_after(jiffies, chunk->msg->expires_at)) {
> if (chunk->sent_count)
> chunk->asoc->abandoned_sent[SCTP_PR_INDEX(TTL)]++;
> else
> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index 2c431ee..c7110a9 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -718,7 +718,7 @@ static void sctp_set_prsctp_policy(struct sctp_chunk
> *chunk,
> return;
>
> if (SCTP_PR_TTL_ENABLED(sinfo->sinfo_flags))
> - chunk->prsctp_param =
> + chunk->msg->expires_at =
> jiffies + msecs_to_jiffies(sinfo->sinfo_timetolive);
> }
>
[PATCH v9 0/2] update the doc of kdump
v8->v9: rearrange the patch. it won't fix typo which original exists. those should be fixed in other patch, which I'll post later. v7->v8: fix "a SMP kernel" to "an SMP kernel" and replace "\" with "/" v6->v7: fix typo v5->v6: replace "we" with "you" v4->v5: move change log to cover letter v3->v4: update the description of bring up SMP dump-capture kernel v2->v3: add description of nr_cpus. v1->v2: change nr_cpus to maxcpus Zhou Wenjian (2): Documentation: kdump: remind user of nr_cpus Documentation: kdump: add description of enable multi-cpus support Documentation/kdump/kdump.txt | 9 + 1 file changed, 9 insertions(+) -- 1.8.3.1
[PATCH] zram: clean up valid_io_request
Use IS_ALIGNED instead of opencoding to check the unaligned case. And size is aligned to ZRAM_LOGICAL_BLOCK_SIZE which will not make end <= start, so we do not need to compare the start and end. Signed-off-by: Shawn Lin --- drivers/block/zram/zram_drv.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index 04365b1..1094e95 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -120,15 +120,15 @@ static inline bool valid_io_request(struct zram *zram, u64 end, bound; /* unaligned request */ - if (unlikely(start & (ZRAM_SECTOR_PER_LOGICAL_BLOCK - 1))) + if (unlikely(!IS_ALIGNED(start, ZRAM_SECTOR_PER_LOGICAL_BLOCK))) return false; - if (unlikely(size & (ZRAM_LOGICAL_BLOCK_SIZE - 1))) + if (unlikely(!IS_ALIGNED(size, ZRAM_LOGICAL_BLOCK_SIZE))) return false; end = start + (size >> SECTOR_SHIFT); bound = zram->disksize >> SECTOR_SHIFT; /* out of range range */ - if (unlikely(start >= bound || end > bound || start > end)) + if (unlikely(start >= bound || end > bound)) return false; /* I/O request is valid */ -- 2.3.7
[PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus
nr_cpus can help to save memory. So we should remind user of it. Signed-off-by: Zhou Wenjian Acked-by: Baoquan He Acked-by: Xunlei Pang --- Documentation/kdump/kdump.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 88ff63d..d900080 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -393,6 +393,8 @@ Notes on loading the dump-capture kernel: * We generally don' have to bring up a SMP kernel just to capture the dump. Hence generally it is useful either to build a UP dump-capture kernel or specify maxcpus=1 option while loading dump-capture kernel. + Note, though maxcpus always works, you should replace it by nr_cpus to + save memory if supported by the current ARCH, such as x86. * For s390x there are two kdump modes: If a ELF header is specified with the elfcorehdr= kernel parameter, it is used by the kdump kernel as it -- 1.8.3.1
[PATCH v9 2/2] Documentation: kdump: add description of enable multi-cpus support
multi-cpu support is useful to improve the performance of kdump in some cases. So add the description of enable multi-cpu support in dump-capture kernel. Signed-off-by: Zhou Wenjian Acked-by: Baoquan He Acked-by: Xunlei Pang --- Documentation/kdump/kdump.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index d900080..31e6b88 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel: Note, though maxcpus always works, you should replace it by nr_cpus to save memory if supported by the current ARCH, such as x86. +* You should enable multi-cpu support in dump-capture kernel if you intend + to use multi-thread programs with it, such as parallel dump feature of + makedumpfile. Otherwise, the multi-thread program may have a great + performance degradation. To enable multi-cpu support, you should bring up an + SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X] + options while loading it. + * For s390x there are two kdump modes: If a ELF header is specified with the elfcorehdr= kernel parameter, it is used by the kdump kernel as it is done on all other architectures. If no elfcorehdr= kernel parameter is -- 1.8.3.1
[git pull] drm fixes
Hi Linus, Pretty quiet so far, a few amdgpu/radeon fixup for pcie pm changes, and a couple of amdgpu fixes, along with some build fixes, and printk fix. Dave. The following changes since commit 4b9eaf33d83d91430b7ca45d0ebf8241da489c92: Merge branch 'akpm' (patches from Andrew) (2016-08-11 16:58:24 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-4.8-rc3 for you to fetch changes up to 91d62d9f30206be6f7749a0e6f7fa58c6d70c702: Merge branch 'drm-fixes-4.8' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2016-08-18 12:51:27 +1000) Alex Deucher (2): Revert "drm/amdgpu: work around lack of upstream ACPI support for D3cold" Revert "drm/radeon: work around lack of upstream ACPI support for D3cold" Arnd Bergmann (3): drm/mediatek: add COMMON_CLK dependency drm/mediatek: add CONFIG_OF dependency drm/mediatek: add ARM_SMCCC dependency Chunming Zhou (1): drm/amdgpu: fix vm init error path Colin Ian King (1): drm/amdkfd: print doorbell offset as a hex value Dave Airlie (4): Merge tag 'drm-amdkfd-fixes-2016-08-09' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes Merge branch 'drm-fixes-4.8' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'mediatek-drm-fixes-2016-08-12' of git://git.pengutronix.de/git/pza/linux into drm-fixes Merge branch 'drm-fixes-4.8' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Felix Kuehling (1): drm/amdgpu: Change GART offset to 64-bit Jay Cornwall (1): drm/amdgpu: Fix memory trashing if UVD ring test fails drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 9 - drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 - drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c| 2 +- drivers/gpu/drm/mediatek/Kconfig | 3 +++ drivers/gpu/drm/radeon/radeon_atpx_handler.c | 9 - 8 files changed, 14 insertions(+), 25 deletions(-)
Re: [PATCH v9 4/4] arm64: dts: rockchip: configure usb2-phy support for rk3399-evb
On 2016/8/17 18:02, Heiko Stübner wrote:
Am Freitag, 22. Juli 2016, 15:00:46 schrieb Frank Wang:
Add vcc5v0_host regulator for usb2-phy and enable host-port support.
Signed-off-by: Frank Wang
applied to ny dts64 branch [0] with some changes:
- the pin is named vcc5v0_host_en not host_vbus_drv in the schematics
please always try to use the names from the schematics
- separated the enablement of the subnodes
Thanks for your valuable comments, I will try to improve the quality of
my patches in future.
BR.
Frank
Heiko
[0]
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=1d3bc1d6c9c4658d554bcf89a71b35a6783a5b4e
---
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 44
+++ 1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts index 1a3eb14..56aeedb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -69,6 +69,25 @@
regulator-max-microvolt = <330>;
};
+ vcc5v0_sys: vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ vcc5v0_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_vbus_drv>;
+ regulator-name = "vcc5v0_host";
+ vin-supply = <&vcc5v0_sys>;
+ };
+
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_phy";
@@ -89,6 +108,24 @@
status = "okay";
};
+&u2phy0 {
+ status = "okay";
+
+ u2phy0_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
+&u2phy1 {
+ status = "okay";
+
+ u2phy1_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
&uart2 {
status = "okay";
};
@@ -121,4 +158,11 @@
<1 18 RK_FUNC_GPIO &pcfg_pull_down>;
};
};
+
+ usb2 {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins =
+ <4 25 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
};
Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression
On Wed, Aug 17, 2016 at 04:49:07PM +0100, Mel Gorman wrote: > On Tue, Aug 16, 2016 at 10:47:36AM -0700, Linus Torvalds wrote: > > I've always preferred to see direct reclaim as the primary model for > > reclaim, partly in order to throttle the actual "bad" process, but > > also because "kswapd uses lots of CPU time" is such a nasty thing to > > even begin guessing about. > > > > While I agree that bugs with high CPU usage from kswapd are a pain, > I'm reluctant to move towards direct reclaim being the primary mode. The > stalls can be severe and there is no guarantee that the process punished > is the process responsible. I'm basing this assumption on observations > of severe performance regressions when I accidentally broke kswapd during > the development of node-lru. > > > So I have to admit to liking that "make kswapd sleep a bit if it's > > just looping" logic that got removed in that commit. > > > > It's primarily the direct reclaimer that is affected by that patch. > > > And looking at DaveC's numbers, it really feels like it's not even > > what we do inside the locked region that is the problem. Sure, > > __delete_from_page_cache() (which is most of it) is at 1.86% of CPU > > time (when including all the things it calls), but that still isn't > > all that much. Especially when compared to just: > > > >0.78% [kernel] [k] _raw_spin_unlock_irqrestore > > > > The profile is shocking for such a basic workload. I automated what Dave > described with xfs_io except that the file size is 2*RAM. The filesystem > is sized to be roughly the same size as the file to minimise variances > due to block layout. A call-graph profile collected on bare metal UMA with > numa=fake=4 and paravirt spinlocks showed > > 1.40% 0.16% kswapd1 [kernel.vmlinux][k] > _raw_spin_lock_irqsave > 1.36% 0.16% kswapd2 [kernel.vmlinux][k] > _raw_spin_lock_irqsave > 1.21% 0.12% kswapd0 [kernel.vmlinux][k] > _raw_spin_lock_irqsave > 1.12% 0.13% kswapd3 [kernel.vmlinux][k] > _raw_spin_lock_irqsave > 0.81% 0.45% xfs_io [kernel.vmlinux][k] > _raw_spin_lock_irqsave > > Those contention figures are not great but they are not terrible either. The > vmstats told me there was no direct reclaim activity so either my theory > is wrong or this machine is not reproducing the same problem Dave is seeing. No, that's roughly the same un-normalised CPU percentage I am seeing in spinlock contention. i.e. take way the idle CPU in the profile (probably upwards of 80% if it's a 16p machine), and instead look at that figure as a percentage of total CPU used by the workload. Then you'll that it's 30-40% of the total CPU consumed by the workload. > I have partial results from a 2-socket and 4-socket machine. 2-socket spends > roughtly 1.8% in _raw_spin_lock_irqsave and 4-socket spends roughtly 3%, > both with no direct reclaim. Clearly the problem gets worse the more NUMA > nodes there are but not to the same extent Dave reports. > > I believe potential reasons why I do not see the same problem as Dave are; > > 1. Different memory sizes changing timing > 2. Dave has fast storage and I'm using a spinning disk This particular is using an abused 3 year old SATA SSD that still runs at 500MB/s on sequential writes. This is "cheap desktop" capability these days and is nowhere near what I'd call "fast". > 3. Lock contention problems are magnified inside KVM > > I think 3 is a good possibility if contended locks result in expensive > exiting and reentery of the guest. I have a vague recollection that a > spinning vcpu exits the guest but I did not confirm that. I don't think anything like that has been implemented in the pv spinlocks yet. They just spin right now - it's the same lock implementation as the host. Also, Context switch rates measured on the host are not significantly higher than what is measured in the guest, so there doesn't appear to be any extra scheduling on the host side occurring. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH v8 1/2] Documentation: kdump: remind user of nr_cpus
On Thu, 2016-08-18 at 10:31 +0800, Zhou Wenjian wrote: > nr_cpus can help to save memory. So we should remind user of it. trivia: > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt [] > @@ -390,9 +390,11 @@ Notes on loading the dump-capture kernel: > * Boot parameter "1" boots the dump-capture kernel into single-user > mode without networking. If you want networking, use "3". > > -* We generally don' have to bring up a SMP kernel just to capture the > +* We generally don' have to bring up an SMP kernel just to capture the don't or do not
Re: [PATCH 15/15] block: Add FIXME comment to handle device_add_disk error
On (08/17/16 15:15), Fam Zheng wrote: [..] > ( > rc = device_add_disk(e1, e2, e3); > | > + /* FIXME: handle error. */ > device_add_disk(e1, e2, e3); or use __must_check for device_add_disk() function? /* which is _attribute__((warn_unused_result)) */ -ss
[PATCH v8 2/2] Documentation: kdump: add description of enable multi-cpus support
multi-cpu support is useful to improve the performance of kdump in some cases. So add the description of enable multi-cpu support in dump-capture kernel. Signed-off-by: Zhou Wenjian Acked-by: Baoquan He Acked-by: Xunlei Pang --- Documentation/kdump/kdump.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index e8da1d5..c781d49 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel: Note, though maxcpus always works, you should replace it by nr_cpus to save memory if supported by the current ARCH, such as x86. +* You should enable multi-cpu support in dump-capture kernel if you intend + to use multi-thread programs with it, such as parallel dump feature of + makedumpfile. Otherwise, the multi-thread program may have a great + performance degradation. To enable multi-cpu support, you should bring up an + SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X] + options while loading it. + * For s390x there are two kdump modes: If a ELF header is specified with the elfcorehdr= kernel parameter, it is used by the kdump kernel as it is done on all other architectures. If no elfcorehdr= kernel parameter is -- 1.8.3.1
[PATCH v8 0/2] update the doc of kdump
v7->v8: fix "a SMP kernel" to "an SMP kernel" and replace "\" with "/" v6->v7: fix typo v5->v6: replace "we" with "you" v4->v5: move change log to cover letter v3->v4: update the description of bring up SMP dump-capture kernel v2->v3: add description of nr_cpus. v1->v2: change nr_cpus to maxcpus Zhou Wenjian (2): Documentation: kdump: remind user of nr_cpus Documentation: kdump: add description of enable multi-cpus support Documentation/kdump/kdump.txt | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) -- 1.8.3.1
[PATCH v8 1/2] Documentation: kdump: remind user of nr_cpus
nr_cpus can help to save memory. So we should remind user of it. Signed-off-by: Zhou Wenjian Acked-by: Baoquan He Acked-by: Xunlei Pang --- Documentation/kdump/kdump.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 88ff63d..e8da1d5 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -390,9 +390,11 @@ Notes on loading the dump-capture kernel: * Boot parameter "1" boots the dump-capture kernel into single-user mode without networking. If you want networking, use "3". -* We generally don' have to bring up a SMP kernel just to capture the +* We generally don' have to bring up an SMP kernel just to capture the dump. Hence generally it is useful either to build a UP dump-capture kernel or specify maxcpus=1 option while loading dump-capture kernel. + Note, though maxcpus always works, you should replace it by nr_cpus to + save memory if supported by the current ARCH, such as x86. * For s390x there are two kdump modes: If a ELF header is specified with the elfcorehdr= kernel parameter, it is used by the kdump kernel as it -- 1.8.3.1
Re: [PATCH v3 0/4] Amlogic: Meson: Add reset controller
On Wed, Aug 17, 2016 at 9:15 PM, Kevin Hilman wrote: > Hi Philipp, > > On Thu, Jun 2, 2016 at 2:42 AM, Philipp Zabel wrote: >> Hi Neil, >> >> Am Montag, den 30.05.2016, 15:27 +0200 schrieb Neil Armstrong: >>> Patchset to add and enable the reset controller driver on Meson SoCs >>> platforms. >>> >>> This reset controller has up to 256 reset lines with reset pulse generation >>> only, >>> so the assert and deassert calls are not available. >>> >>> Depends on the patch : >>> - "reset: add devm_reset_controller_register API" [1] >>> >>> Changes since v2 at >>> http://lkml.kernel.org/r/1464169758-26975-1-git-send-email-narmstr...@baylibre.com >>> : >>> - Get back __iomem in _reset() callback >>> - Get rid of MODULE_ALIAS >>> >>> Changes since v1 at >>> http://lkml.kernel.org/r/1463732875-23141-1-git-send-email-narmstr...@baylibre.com >>> : >>> - Remove _gxbb_ in names >>> - Depends build on ARCH_MESON only >>> - Add meson8b compatible and bindings >>> - Re-indent dt-bindings headers >>> - Switch to devm_ reset controller register >>> - Remove platform "remove" callback >>> - Update Dual BSD/GPL file headers >>> >>> Changes since the RFC at >>> http://lkml.kernel.org/r/1463148012-25988-1-git-send-email-narmstr...@baylibre.com >>> : >>> - Fix register mapping and bit defines in bindings header >>> - Remove assert and unassert calls >>> - Fix missing __iomem >>> >>> [1] https://patchwork.kernel.org/patch/8988471/ >>> >>> Neil Armstrong (4): >>> reset: Add support for the Amlogic Meson SoC Reset Controller >>> dt-bindings: reset: Add bindings for the Meson SoC Reset Controller >> >> I've applied these two patches to the reset/next branch. >> > > I'm just noticing now that these didn't make it into v4.8-rc1. Was > there reason for that? Doh, nevermind, I'm blind (and was looking at the wrong tree.) I see them now. Kevin
Re: [PATCH v10 1/2] printk: Make printk() completely async
Hello, really sorry for very long reply. On (08/12/16 11:44), Petr Mladek wrote: [..] > IMHO, this is fine. We force the synchronous mode in critical > situations anyway. yes, I think it makes sense to lower the priority (we also have briefly discussed this in private emails with Viresh). I'd still prefer to have forced sync-printk on suspend/hibernate/etc., though. > But I was curious if we could hit a printk from the wake_up_process(). > The change above causes using the fair scheduler and there is > the following call chain [*] > > vprintk_emit() > -> wake_up_process() >-> try_to_wake_up() > -> ttwu_queue() > -> ttwu_do_activate() > -> ttwu_activate() >-> activate_task() > -> enqueue_task() >-> enqueue_task_fair() via p->sched_class->enqueue_task > -> cfs_rq_of() > -> task_of() > -> WARN_ON_ONCE(!entity_is_task(se)) > > We should never trigger this because printk_kthread is a task. > But what if the date gets inconsistent? > > Then there is the following chain: > > vprintk_emit() > -> wake_up_process() >-> try_to_wake_up() > -> ttwu_queue() > -> ttwu_do_activate() > -> ttwu_activate() >-> activate_task() > -> enqueue_task() >-> enqueue_task_fair() via p->sched_class->enqueue_task > ->hrtick_update() > -> hrtick_start_fair() > -> WARN_ON(task_rq(p) != rq) > > This looks like another paranoid consistency check that might be > triggered when the scheduler gets messed. > > I see few possible solutions: > > 1. Replace the WARN_ONs by printk_deferred(). > >This is the usual solution but it would make debugging less convenient. what I did internally was a combination of #1 and #3: I introduced a dump_stack_deferred() function which is basically (almost) a copy-past of dump_stack() from lib/dump_stack.c with the difference that it calls printk_deferred(). and added a WARN_ON_DEFERRED() macro. > 2. Force synchronous printk inside WARN()/BUG() macros. will it help? semaphore up() calls wake_up_process() regardless the context. not to mention that we still may have spin_dump() enabled. > 3. Force printk_deferred() inside WARN()/BUG() macros via the per-CPU >printk_func. > >It might be elegant. But we do not want this outside the scheduler >code. Therefore we would need special variants of WARN_*_SCHED() >BUG_*_SCHED() macros. > > I personally prefer the 2nd solution. What do you think about it, > please? I personally think a combo of #1 and #3 is a bit better than plain #2. -ss
Fast Loans
Apply for a loan at 2% reply to this Email for more Info
Re: [PATCH] time: alarmtimer: Add the trcepoints for alarmtimer
Hi John, On 18 August 2016 at 04:00, John Stultz wrote: > On Fri, Aug 12, 2016 at 2:16 AM, Baolin Wang wrote: >> For system debugging, we usually want to know who sets one alarm timer, the >> time of the timer, when the timer started and fired and so on. >> >> Thus adding tracepoints can help us trace the alarmtimer information. >> >> Signed-off-by: Baolin Wang > > > Looks reasonable to me. Might be good to get a specific example of > something you've used this for (with example output) in the commit > log. OK. Will add one example with the trace log in next version. > > Please also fix up the kbuild test issues and resubmit. OK. Thanks. > > thanks > -john -- Baolin.wang Best Regards
Re: [PATCH v3 0/4] Amlogic: Meson: Add reset controller
Hi Philipp, On Thu, Jun 2, 2016 at 2:42 AM, Philipp Zabel wrote: > Hi Neil, > > Am Montag, den 30.05.2016, 15:27 +0200 schrieb Neil Armstrong: >> Patchset to add and enable the reset controller driver on Meson SoCs >> platforms. >> >> This reset controller has up to 256 reset lines with reset pulse generation >> only, >> so the assert and deassert calls are not available. >> >> Depends on the patch : >> - "reset: add devm_reset_controller_register API" [1] >> >> Changes since v2 at >> http://lkml.kernel.org/r/1464169758-26975-1-git-send-email-narmstr...@baylibre.com >> : >> - Get back __iomem in _reset() callback >> - Get rid of MODULE_ALIAS >> >> Changes since v1 at >> http://lkml.kernel.org/r/1463732875-23141-1-git-send-email-narmstr...@baylibre.com >> : >> - Remove _gxbb_ in names >> - Depends build on ARCH_MESON only >> - Add meson8b compatible and bindings >> - Re-indent dt-bindings headers >> - Switch to devm_ reset controller register >> - Remove platform "remove" callback >> - Update Dual BSD/GPL file headers >> >> Changes since the RFC at >> http://lkml.kernel.org/r/1463148012-25988-1-git-send-email-narmstr...@baylibre.com >> : >> - Fix register mapping and bit defines in bindings header >> - Remove assert and unassert calls >> - Fix missing __iomem >> >> [1] https://patchwork.kernel.org/patch/8988471/ >> >> Neil Armstrong (4): >> reset: Add support for the Amlogic Meson SoC Reset Controller >> dt-bindings: reset: Add bindings for the Meson SoC Reset Controller > > I've applied these two patches to the reset/next branch. > I'm just noticing now that these didn't make it into v4.8-rc1. Was there reason for that? Kevin
Re: [PATCH v7 2/2] Documentation: kdump: add description of enable multi-cpus support
On 2016/08/18 at 09:50, Zhou Wenjian wrote: > multi-cpu support is useful to improve the performance of kdump in > some cases. So add the description of enable multi-cpu support in > dump-capture kernel. > > Signed-off-by: Zhou Wenjian > Acked-by: Baoquan He > --- > Documentation/kdump/kdump.txt | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > index 96da2b7..c93a6e0 100644 > --- a/Documentation/kdump/kdump.txt > +++ b/Documentation/kdump/kdump.txt > @@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel: >Note, though maxcpus always works, you should replace it by nr_cpus to >save memory if supported by the current ARCH, such as x86. > > +* You should enable multi-cpu support in dump-capture kernel if you intend > + to use multi-thread programs with it, such as parallel dump feature of > + makedumpfile. Otherwise, the multi-thread program may have a great > + performance degradation. To enable multi-cpu support, you should bring up > + a SMP dump-capture kernel and specify maxcpus\nr_cpus, > disable_cpu_apicid=[X] s/a SMP/an SMP/ For "maxcpus\nr_cpus", I think to use slash instead of backslash in Linux is better. Otherwise, looks good to me. Regards, Xunlei > + options while loading it. > + > * For s390x there are two kdump modes: If a ELF header is specified with >the elfcorehdr= kernel parameter, it is used by the kdump kernel as it >is done on all other architectures. If no elfcorehdr= kernel parameter is
Re: [PATCH 11/15] zram: Pass attribute group to device_add_disk
On (08/18/16 10:59), Sergey Senozhatsky wrote:
[..]
> I like the previous "Error creating sysfs group for device" string better,
> than "Error creating disk", because the latter one is much less informative.
>
> do you want to do something like below?
>
> int device_add_disk(struct device *parent, struct gendisk *disk,
> ...
>if (attr_group) {
>retval = sysfs_create_group(&disk_to_dev(disk)->kobj,
>attr_group);
>
> + pr_err("Error creating sysfs group for device ...\n", ...);
d'oh... a typo. pr_err() is meant to be in `if (retval)' branch.
>if (retval)
>goto fail;
>}
-ss
Re: [PATCH 11/15] zram: Pass attribute group to device_add_disk
Hello,
On (08/17/16 15:15), Fam Zheng wrote:
[..]
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 20920a2..2331788 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -1298,13 +1298,10 @@ static int zram_add(void)
> zram->disk->queue->limits.discard_zeroes_data = 0;
> queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, zram->disk->queue);
>
> - device_add_disk(NULL, zram->disk, NULL);
> + ret = device_add_disk(NULL, zram->disk, &zram_disk_attr_group);
>
> - ret = sysfs_create_group(&disk_to_dev(zram->disk)->kobj,
> - &zram_disk_attr_group);
> if (ret < 0) {
> - pr_err("Error creating sysfs group for device %d\n",
> - device_id);
> + pr_err("Error creating disk %d\n", device_id);
> goto out_free_disk;
> }
> strlcpy(zram->compressor, default_compressor, sizeof(zram->compressor));
I like the previous "Error creating sysfs group for device" string better,
than "Error creating disk", because the latter one is much less informative.
do you want to do something like below?
int device_add_disk(struct device *parent, struct gendisk *disk,
...
if (attr_group) {
retval = sysfs_create_group(&disk_to_dev(disk)->kobj,
attr_group);
+ pr_err("Error creating sysfs group for device ...\n", ...);
if (retval)
goto fail;
}
-ss
linux-next: build failure after merge of the netfilter-next tree
Hi all,
After merging the netfilter-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
ERROR: "nf_conntrack_htable_size" [net/netfilter/nf_conntrack_netlink.ko]
undefined!
ERROR: "nf_conntrack_htable_size" [net/ipv4/netfilter/nf_conntrack_ipv4.ko]
undefined!
Caused by commit
adf0516845bc ("netfilter: remove ip_conntrack* sysctl compat code")
or maybe
92e47ba8839b ("netfilter: conntrack: simplify the code by using
nf_conntrack_get_ht")
I have used the netfilter-next tree from next-20160817 for today.
--
Cheers,
Stephen Rothwell
[PATCH v7 0/2] update the doc of kdump
v6->v7: fix typo v5->v6: replace "we" with "you" v4->v5: move change log to cover letter v3->v4: update the description of bring up SMP dump-capture kernel v2->v3: add description of nr_cpus. v1->v2: change nr_cpus to maxcpus Zhou Wenjian (2): Documentation: kdump: remind user of nr_cpus Documentation: kdump: add description of enable multi-cpus support Documentation/kdump/kdump.txt | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) -- 1.8.3.1
[PATCH v7 1/2] Documentation: kdump: remind user of nr_cpus
nr_cpus can help to save memory. So we should remind user of it. Signed-off-by: Zhou Wenjian Acked-by: Baoquan He --- Documentation/kdump/kdump.txt | 2 +++- 1 file changed, 2 insertions(+) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 88ff63d..96da2b7 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -393,6 +393,8 @@ Notes on loading the dump-capture kernel: * We generally don' have to bring up a SMP kernel just to capture the dump. Hence generally it is useful either to build a UP dump-capture kernel or specify maxcpus=1 option while loading dump-capture kernel. + Note, though maxcpus always works, you should replace it by nr_cpus to + save memory if supported by the current ARCH, such as x86. * For s390x there are two kdump modes: If a ELF header is specified with the elfcorehdr= kernel parameter, it is used by the kdump kernel as it -- 1.8.3.1
[PATCH v7 2/2] Documentation: kdump: add description of enable multi-cpus support
multi-cpu support is useful to improve the performance of kdump in some cases. So add the description of enable multi-cpu support in dump-capture kernel. Signed-off-by: Zhou Wenjian Acked-by: Baoquan He --- Documentation/kdump/kdump.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 96da2b7..c93a6e0 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel: Note, though maxcpus always works, you should replace it by nr_cpus to save memory if supported by the current ARCH, such as x86. +* You should enable multi-cpu support in dump-capture kernel if you intend + to use multi-thread programs with it, such as parallel dump feature of + makedumpfile. Otherwise, the multi-thread program may have a great + performance degradation. To enable multi-cpu support, you should bring up + a SMP dump-capture kernel and specify maxcpus\nr_cpus, disable_cpu_apicid=[X] + options while loading it. + * For s390x there are two kdump modes: If a ELF header is specified with the elfcorehdr= kernel parameter, it is used by the kdump kernel as it is done on all other architectures. If no elfcorehdr= kernel parameter is -- 1.8.3.1
RE: [PATCH v2 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
On August 06, 2016 10:27 PM, Jagan Teki wrote:
> On 22 April 2016 at 12:09, Yunhui Cui wrote:
> > From: Yunhui Cui
> >
> > With the physical sectors combination, S25FS-S family flash requires
> > some special operations for read/write functions.
> >
> > Signed-off-by: Yunhui Cui
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 59
> > +++
> > 1 file changed, 59 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > b/drivers/mtd/spi-nor/spi-nor.c index 157841d..91ee920 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -39,6 +39,10 @@
> >
> > #define SPI_NOR_MAX_ID_LEN 6
> > #define SPI_NOR_MAX_ADDR_WIDTH 4
> > +/* Added for S25FS-S family flash */
> > +#define SPINOR_CONFIG_REG3_OFFSET 0x84
> > +#define CR3V_4KB_ERASE_UNABLE 0x8
> > +#define SPINOR_S25FS_FAMILY_ID 0x81
> >
> > struct flash_info {
> > char*name;
> > @@ -78,6 +82,7 @@ struct flash_info {
> > };
> >
> > #define JEDEC_MFR(info)((info)->id[0])
> > +#define EXT_ID(info) ((info)->id[5])
>
> I don't think 5th only the ext and usually last 3 bytes are called as
> ext_jedec if the id length is 6 bytes.
[Yunhui] ok, I will update it in next version.
>
> >
> > static const struct flash_info *spi_nor_match_id(const char *name);
> >
> > @@ -881,6 +886,7 @@ static const struct flash_info spi_nor_ids[] = {
> > */
> > { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128,
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024, 512, 0)},
> > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> > { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256,
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1018,6 +1024,53 @@ static
> const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
> > return ERR_PTR(-ENODEV);
> > }
> >
> > +/*
> > + * The S25FS-S family physical sectors may be configured as a
> > + * hybrid combination of eight 4-kB parameter sectors
> > + * at the top or bottom of the address space with all
> > + * but one of the remaining sectors being uniform size.
> > + * The Parameter Sector Erase commands (20h or 21h) must
> > + * be used to erase the 4-kB parameter sectors individually.
> > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > + * must be used to erase any of the remaining
> > + * sectors, including the portion of highest or lowest address
> > + * sector that is not overlaid by the parameter sectors.
> > + * The uniform sector erase command has no effect on parameter sectors.
> > + */
> > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) {
> > + struct fsl_qspi *q;
> > + u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
> > + u8 cr3v = 0x0;
> > + int ret = 0x0;
> > +
> > + q = nor->priv;
>
> Why this q?
[Yunhui] ok, It seems that 'q' is useless in the function. I will update it in
next version , thanks.
>
> --
> Jagan.
Re: [PATCH 06/15] genhd: Add return code to device_add_disk
On 08/17/2016 05:14 AM, Fam Zheng wrote: ... Of course, the plan is to write patches on top. I'm not cleaning up anything here because I'm concerned callers may double free (and I didn't look hard into that). Aside from Huck's concerns, the changes looked OK from aoe's perspective. -- Ed
Re: [PATCH] extcon: Introduce EXTCON_PROP_USB_SUPERSPEED property
On 2016년 08월 18일 09:41, Guenter Roeck wrote: > On Wed, Aug 17, 2016 at 5:37 PM, Chanwoo Choi wrote: >> Hi Guenter, >> >> How about changing the property name for SuperSpeed as following? >> It is more simple and reduce the length of property name. >> - EXTCON_PROP_USB_SUPERSPEED -> EXTCON_PROP_USB_SS >> > Whatever you prefer is fine. OK. Thanks. I'll change the property name. Regards, Chanwoo Choi > > Thanks, > Guenter > >> Regards, >> Chanwoo Choi >> >> On 2016년 08월 16일 10:41, Guenter Roeck wrote: >>> On Mon, Aug 15, 2016 at 5:55 PM, Chanwoo Choi wrote: Hi Guenter, Looks good to me. I'll add the reference[1] information on patch description and applied it. [1] https://en.wikipedia.org/wiki/USB#Overview >>> >>> Thanks! >>> >>> Guenter >>> Thanks, Chanwoo Choi On 2016년 08월 15일 22:15, Guenter Roeck wrote: > From: Guenter Roeck > > EXTCON_PROP_USB_SUPERSPEED is necessary to distinguish between USB/USB2 > and USB3 connections on USB Type-C cables. > > Cc: Chris Zhong > Signed-off-by: Guenter Roeck > --- > Applies on top of extcon-next. > > include/linux/extcon.h | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/include/linux/extcon.h b/include/linux/extcon.h > index ad7a1606a7f3..38d2c0dec2c1 100644 > --- a/include/linux/extcon.h > +++ b/include/linux/extcon.h > @@ -107,12 +107,18 @@ > * @type:integer (intval) > * @value: 0 (normal) or 1 (flip) > * @default: 0 (normal) > + * - EXTCON_PROP_USB_SUPERSPEED > + * @type: integer (intval) > + * @value: 0 (USB/USB2) or 1 (USB3) > + * @default:0 (USB/USB2) > + * > */ > #define EXTCON_PROP_USB_VBUS 0 > #define EXTCON_PROP_USB_TYPEC_POLARITY 1 > +#define EXTCON_PROP_USB_SUPERSPEED 2 > > #define EXTCON_PROP_USB_MIN 0 > -#define EXTCON_PROP_USB_MAX 1 > +#define EXTCON_PROP_USB_MAX 2 > #define EXTCON_PROP_USB_CNT (EXTCON_PROP_USB_MAX - EXTCON_PROP_USB_MIN > + 1) > > /* Properties of EXTCON_TYPE_CHG. */ > >>> >>> >>> >> > > >
[RFC PATCH 2/3] tty: serial_core: make tty_struct optional
In order to allow serial drivers to work without a tty, make calls from
drivers and serial_core work when tty_struct is NULL.
Signed-off-by: Rob Herring
---
drivers/tty/serial/serial_core.c | 3 ++-
drivers/tty/tty_buffer.c | 2 ++
include/linux/serial_core.h | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9fc1533..9dd444f 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -111,7 +111,8 @@ void uart_write_wakeup(struct uart_port *port)
* closed. No cookie for you.
*/
BUG_ON(!state);
- tty_wakeup(state->port.tty);
+ if (state->port.tty)
+ tty_wakeup(state->port.tty);
}
static void uart_stop(struct tty_struct *tty)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index aa80dc9..ffab8ea 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -528,6 +528,8 @@ static void flush_to_ldisc(struct work_struct *work)
void tty_flip_buffer_push(struct tty_port *port)
{
+ if (!port->tty)
+ return;
tty_schedule_flip(port);
}
EXPORT_SYMBOL(tty_flip_buffer_push);
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 2f44e20..a27ca1f 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -412,7 +412,7 @@ int uart_resume_port(struct uart_driver *reg, struct
uart_port *port);
static inline int uart_tx_stopped(struct uart_port *port)
{
struct tty_struct *tty = port->state->port.tty;
- if (tty->stopped || port->hw_stopped)
+ if ((tty && tty->stopped) || port->hw_stopped)
return 1;
return 0;
}
--
2.9.2
[RFC PATCH 3/3] tty: serial_core: add uart controller registration
Register serial ports with the uart device core as a controller and add
a receive handler call.
Signed-off-by: Rob Herring
---
drivers/tty/serial/serial_core.c | 8
include/linux/serial_core.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9dd444f..1552fee 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2800,6 +2801,10 @@ int uart_add_one_port(struct uart_driver *drv, struct
uart_port *uport)
uart_configure_port(drv, state, uport);
+ uport->ctrlr = uart_controller_alloc(uport->dev, 0);
+ uport->ctrlr->port = uport;
+ uart_controller_add(uport->ctrlr);
+
num_groups = 2;
if (uport->attr_group)
num_groups++;
@@ -3027,6 +3032,9 @@ void uart_insert_char(struct uart_port *port, unsigned
int status,
{
struct tty_port *tport = &port->state->port;
+ if (uart_controller_rx(port->ctrlr, ch) >= 0)
+ return;
+
if ((status & port->ignore_status_mask & ~overrun) == 0)
if (tty_insert_flip_char(tport, ch, flag) == 0)
++port->icount.buf_overrun;
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index a27ca1f..7cde6a9 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -155,6 +155,7 @@ struct uart_port {
unsigned intread_status_mask; /* driver specific */
unsigned intignore_status_mask; /* driver specific */
+ struct uart_controller *ctrlr;
struct uart_state *state; /* pointer to parent
state */
struct uart_icount icount; /* statistics */
--
2.9.2
[RFC PATCH 0/3] UART slave device bus
Currently, devices attached via a UART are not well supported in the kernel. The problem is the device support is done in tty line disciplines, various platform drivers to handle some sideband, and in userspace with utilities such as hciattach. There have been several attempts to improve support, but they suffer from still being tied into the tty layer and/or abusing the platform bus. This is a prototype to show creating a proper UART bus for UART devices. It is tied into the serial core (really struct uart_port) below the tty layer in order to use existing serial drivers. This is functional with minimal testing using the loopback driver and pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave device). It still needs lots of work and polish. TODOs: - Figure out the port locking. mutex plus spinlock plus refcounting? I'm hoping all that complexity is from the tty layer and not needed here. - Split out the controller for uart_ports into separate driver. Do we see a need for controller drivers that are not standard serial drivers? - Implement/test the removal paths - Fix the receive callbacks for more than character at a time (i.e. DMA) - Need better receive buffering than just a simple circular buffer or perhaps a different receive interface (e.g. direct to client buffer)? - Test with other UART drivers - Convert a real driver/line discipline over to UART bus. Before I spend more time on this, I'm looking mainly for feedback on the general direction and structure (the interface with the existing serial drivers in particular). Rob Rob Herring (3): uart bus: Introduce new bus for UART slave devices tty: serial_core: make tty_struct optional tty: serial_core: add uart controller registration drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/tty/serial/serial_core.c | 11 +- drivers/tty/tty_buffer.c | 2 + drivers/uart/Kconfig | 17 ++ drivers/uart/Makefile| 3 + drivers/uart/core.c | 458 +++ drivers/uart/loopback.c | 72 ++ include/linux/serial_core.h | 3 +- include/linux/uart_device.h | 163 ++ 10 files changed, 730 insertions(+), 2 deletions(-) create mode 100644 drivers/uart/Kconfig create mode 100644 drivers/uart/Makefile create mode 100644 drivers/uart/core.c create mode 100644 drivers/uart/loopback.c create mode 100644 include/linux/uart_device.h -- 2.9.2
[RFC PATCH 1/3] uart bus: Introduce new bus for UART slave devices
The UART bus is designed for slave devices such as Bluetooth, WiFi, GPS
and NFC connected to UARTs on host processors. Tradionally these have
been handled with tty line disciplines, rfkill, and userspace glue such
as hci_attach. This approach has many drawbacks since it doesn't fit
into the Linux driver model. Handling of sideband signals, power control
and firmware loading are the main issues.
This creates a UART bus with controllers (i.e. host UARTs) and slave
devices. Typically, these are point to point connections, but some
devices have muxing protocols or a h/w mux is conceivable. Any muxing is
not yet supported.
Signed-off-by: Rob Herring
---
drivers/Kconfig | 2 +
drivers/Makefile| 1 +
drivers/uart/Kconfig| 17 ++
drivers/uart/Makefile | 3 +
drivers/uart/core.c | 458
drivers/uart/loopback.c | 72 +++
include/linux/uart_device.h | 163
7 files changed, 716 insertions(+)
create mode 100644 drivers/uart/Kconfig
create mode 100644 drivers/uart/Makefile
create mode 100644 drivers/uart/core.c
create mode 100644 drivers/uart/loopback.c
create mode 100644 include/linux/uart_device.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index e1e2066..9145494 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -202,4 +202,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
source "drivers/fpga/Kconfig"
+source "drivers/uart/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 53abb4a..c915417 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -173,3 +173,4 @@ obj-$(CONFIG_STM) += hwtracing/stm/
obj-$(CONFIG_ANDROID) += android/
obj-$(CONFIG_NVMEM)+= nvmem/
obj-$(CONFIG_FPGA) += fpga/
+obj-$(CONFIG_UART_DEV) += uart/
diff --git a/drivers/uart/Kconfig b/drivers/uart/Kconfig
new file mode 100644
index 000..b232ce3
--- /dev/null
+++ b/drivers/uart/Kconfig
@@ -0,0 +1,17 @@
+#
+# UART slave driver configuration
+#
+menuconfig UART_DEV
+ tristate "UART device support"
+ help
+ Support for devices connected via a UART
+
+if UART_DEV
+
+config UART_DEV_LOOPBACK
+ tristate "Loopback Test Driver"
+ help
+ This option enables a loopback test driver. Anything received from
+ the connected device will be echoed back.
+
+endif
diff --git a/drivers/uart/Makefile b/drivers/uart/Makefile
new file mode 100644
index 000..704eec0
--- /dev/null
+++ b/drivers/uart/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_UART_DEV) := core.o
+
+obj-$(CONFIG_UART_DEV_LOOPBACK) += loopback.o
diff --git a/drivers/uart/core.c b/drivers/uart/core.c
new file mode 100644
index 000..5b5d0e1
--- /dev/null
+++ b/drivers/uart/core.c
@@ -0,0 +1,458 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd.
+ * Author: Rob Herring
+ *
+ * Based on drivers/spmi/spmi.c:
+ * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#define DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static bool is_registered;
+static DEFINE_IDA(ctrl_ida);
+
+static void uart_dev_release(struct device *dev)
+{
+ struct uart_device *udev = to_uart_device(dev);
+ kfree(udev);
+}
+
+static const struct device_type uart_dev_type = {
+ .release= uart_dev_release,
+};
+
+static void uart_ctrl_release(struct device *dev)
+{
+ struct uart_controller *ctrl = to_uart_controller(dev);
+ ida_simple_remove(&ctrl_ida, ctrl->nr);
+ kfree(ctrl);
+}
+
+static const struct device_type uart_ctrl_type = {
+ .release= uart_ctrl_release,
+};
+
+static int uart_device_match(struct device *dev, struct device_driver *drv)
+{
+ if (of_driver_match_device(dev, drv))
+ return 1;
+
+ if (drv->name)
+ return strncmp(dev_name(dev), drv->name,
+ SPMI_NAME_SIZE) == 0;
+
+ return 0;
+}
+
+/**
+ * uart_device_add() - add a device previously constructed via
uart_device_alloc()
+ * @udev: uart_device to be added
+ */
+int uart_device_add(struct uart_device *udev)
+{
+ struct uart_controller *ctrl = udev->ctrl;
+ int err;
+
+ dev_set_name(&udev->dev, "uartdev-%d", ctrl->nr);
+
+ err = device_add(&udev->dev);
+ if (err < 0) {
+ dev_err(&udev->dev, "Can't add %s, status %d\n",
+ dev_name(&udev->dev), err);
+
Re: linux-next: build warnings after merge of the kbuild tree
On Wed, 17 Aug 2016 14:59:59 +0200
Michal Marek wrote:
> On 2016-08-17 03:44, Stephen Rothwell wrote:
> > Hi Michal,
> >
> > After merging the kbuild tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced these warnings:
> >
> > WARNING: 25 bad relocations
> > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16
> [...]
> > Introduced by commit
> >
> > 9445aa1a3062 ("ppc: move exports to definitions")
> >
> > I have reverted that commit for today.
> >
> > [cc-ing the ppc guys for clues - also involved is commit
> >
> > 22823ab419d8 ("EXPORT_SYMBOL() for asm")
> > ]
>
> FWIW, I see these warnings as well. Any help from ppc developers is
> appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm
> symbols (their CRCs actually)?
The dangling relocation is a side effect of linker unable to resolve the
reference to the undefined weak symbols. So the real question is, why has
genksyms not overridden these symbols with their CRC values?
This may not even be powerpc specific, but I'll poke at it a bit more
when I get a chance.
Thanks,
Nick
Re: [PATCH] ARM: cpuidle: Fix error return code
On Wednesday, August 17, 2016 04:16:09 PM Daniel Lezcano wrote:
> On 08/11/2016 03:02 PM, Christophe JAILLET wrote:
> > We know that 'ret = 0' because it has been tested a few lines above.
> > So, if 'kzalloc' fails, 0 will be returned instead of an error code.
> > Return -ENOMEM instead.
> >
> > Fixes: a0d46a3dfdc3 ("ARM: cpuidle: Register per cpuidle device")
> >
> > Signed-off-by: Christophe JAILLET
>
> Applied, thanks !
Daniel, I've applied it too and earlier.
Thanks,
Rafael
Re: [RESEND PATCH 1/1] bitops.h: move out get_count_order[_long]() from __KERNEL__ scope
On Thu, Aug 18, 2016 at 07:51:19AM +0800, zijun_hu wrote: > > What the hell is anything without __KERNEL__ doing with linux/bitops.h in > > the first place? IOW, why do we have those ifdefs at all? > > > > __KERNEL__ is used to indicate the relevant sections within kernel > headers can't be exported to or used by user space ITYM "used to be used". These days it's "everything outside of */uapi/*.h can't be exported"...
RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration
Hi Michael, Could you help to review this version when you have time? Thanks! Liang > -Original Message- > From: Li, Liang Z > Sent: Monday, August 08, 2016 2:35 PM > To: linux-kernel@vger.kernel.org > Cc: virtualizat...@lists.linux-foundation.org; linux...@kvack.org; virtio- > d...@lists.oasis-open.org; k...@vger.kernel.org; qemu-de...@nongnu.org; > quint...@redhat.com; dgilb...@redhat.com; Hansen, Dave; Li, Liang Z > Subject: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & > fast live migration > > This patch set contains two parts of changes to the virtio-balloon. > > One is the change for speeding up the inflating & deflating process, the main > idea of this optimization is to use bitmap to send the page information to > host instead of the PFNs, to reduce the overhead of virtio data transmission, > address translation and madvise(). This can help to improve the performance > by about 85%. > > Another change is for speeding up live migration. By skipping process guest's > free pages in the first round of data copy, to reduce needless data > processing, > this can help to save quite a lot of CPU cycles and network bandwidth. We > put guest's free page information in bitmap and send it to host with the virt > queue of virtio-balloon. For an idle 8GB guest, this can help to shorten the > total live migration time from 2Sec to about 500ms in the 10Gbps network > environment. > > Dave Hansen suggested a new scheme to encode the data structure, > because of additional complexity, it's not implemented in v3. > > Changes from v2 to v3: > * Change the name of 'free page' to 'unused page'. > * Use the scatter & gather bitmap instead of a 1MB page bitmap. > * Fix overwriting the page bitmap after kicking. > * Some of MST's comments for v2. > > Changes from v1 to v2: > * Abandon the patch for dropping page cache. > * Put some structures to uapi head file. > * Use a new way to determine the page bitmap size. > * Use a unified way to send the free page information with the bitmap > * Address the issues referred in MST's comments > > > Liang Li (7): > virtio-balloon: rework deflate to add page to a list > virtio-balloon: define new feature bit and page bitmap head > mm: add a function to get the max pfn > virtio-balloon: speed up inflate/deflate process > mm: add the related functions to get unused page > virtio-balloon: define feature bit and head for misc virt queue > virtio-balloon: tell host vm's unused page info > > drivers/virtio/virtio_balloon.c | 390 > > include/linux/mm.h | 3 + > include/uapi/linux/virtio_balloon.h | 41 > mm/page_alloc.c | 94 + > 4 files changed, 485 insertions(+), 43 deletions(-) > > -- > 1.8.3.1
Re: [PATCH] timekeeping: Cap array access in timekeeping_debug to protect against invalid sleep times
On Wednesday, August 17, 2016 12:18:50 PM John Stultz wrote:
> It was reported that hibernation could fail on the 2nd attempt,
> where the system hangs at hibernate() -> syscore_resume() ->
> i8237A_resume() -> claim_dma_lock(), because the lock has
> already been taken.
>
> However there is actually no other process would like to grab
> this lock on that problematic platform.
>
> Further investigation showed that the problem is triggered by
> setting /sys/power/pm_trace to 1 before the 1st hibernation.
>
> Since once pm_trace is enabled, the rtc becomes unmeaningful
> after suspend, and meanwhile some BIOSes would like to adjust
> the 'invalid' tsc(e.g, smaller than 1970) to the release date
> of that motherboard during POST stage, thus after resumed, it
> may seem that the system had a significant long sleep time might
> due to meaningless tsc or RTC delta.
>
> Then in timekeeping_resume -> tk_debug_account_sleep_time, if
> the bit31 of the sleep time happened to be set to 1, the fls
> returns 32 and then we add 1 to sleep_time_bin[32], which
> caused a memory overwritten.
>
> As depicted by System.map:
> 81c9d080 b sleep_time_bin
> 81c9d100 B dma_spin_lock
> the dma_spin_lock.val is set to 1, which caused this problem.
>
> This patch adds a sanity check in tk_debug_account_sleep_time()
> to ensure we don't index past the sleep_time_bin array.
>
> Cc: Thomas Gleixner
> Cc: Rafael J. Wysocki
> Cc: Janek Kozicki
> Cc: Chen Yu
> Cc: Xunlei Pang
> Cc: Zhang Rui
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Reported-by: Janek Kozicki
> Reported-by: Chen Yu
> [jstultz: Problem diagnosed and original patch by Chen Yu, I've
> solved the issue slightly differently, but borrowed his excelent
> explanation of of the issue here.]
> Signed-off-by: John Stultz
> ---
> kernel/time/timekeeping_debug.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/time/timekeeping_debug.c b/kernel/time/timekeeping_debug.c
> index f6bd652..107310a6 100644
> --- a/kernel/time/timekeeping_debug.c
> +++ b/kernel/time/timekeeping_debug.c
> @@ -23,7 +23,9 @@
>
> #include "timekeeping_internal.h"
>
> -static unsigned int sleep_time_bin[32] = {0};
> +#define NUM_BINS 32
> +
> +static unsigned int sleep_time_bin[NUM_BINS] = {0};
>
> static int tk_debug_show_sleep_time(struct seq_file *s, void *data)
> {
> @@ -69,6 +71,9 @@ late_initcall(tk_debug_sleep_time_init);
>
> void tk_debug_account_sleep_time(struct timespec64 *t)
> {
> - sleep_time_bin[fls(t->tv_sec)]++;
> + /* Cap bin index so we don't overflow the array */
> + int bin = min(fls(t->tv_sec), NUM_BINS-1);
> +
> + sleep_time_bin[bin]++;
> }
>
>
If pm_trace_enabled is set, we can (or maybe even should) just skip
timekeeping_inject_sleeptime() entirely in rtc_resume() at least, because
sleep_time is almost certainly bogus in that case, even if it doesn't
overflow.
Of course, the above is still needed then.
Thanks,
Rafael
[PATCH v3 3/3] Documentation: livepatch: add section about arch-specific code
Document usage of arch-specific elf sections in livepatch as well as implementation of arch-specific code. Signed-off-by: Jessica Yu --- Documentation/livepatch/module-elf-format.txt | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/Documentation/livepatch/module-elf-format.txt b/Documentation/livepatch/module-elf-format.txt index eedbdcf..02bfafa 100644 --- a/Documentation/livepatch/module-elf-format.txt +++ b/Documentation/livepatch/module-elf-format.txt @@ -25,7 +25,8 @@ Table of Contents 3.3.2 Required name format 3.3.3 Example livepatch symbol names 3.3.4 Example `readelf --symbols` output -4. Symbol table and Elf section access +4. Architecture-specific sections +5. Symbol table and Elf section access 0. Background and motivation @@ -46,7 +47,7 @@ architecture. Since apply_relocate_add() requires access to a module's section header table, symbol table, and relocation section indices, Elf information is -preserved for livepatch modules (see section 4). Livepatch manages its own +preserved for livepatch modules (see section 5). Livepatch manages its own relocation sections and symbols, which are described in this document. The Elf constants used to mark livepatch symbols and relocation sections were selected from OS-specific ranges according to the definitions from glibc. @@ -117,7 +118,7 @@ also possible for a livepatch module to have no livepatch relocation sections, as in the case of the sample livepatch module (see samples/livepatch). -Since Elf information is preserved for livepatch modules (see Section 4), a +Since Elf information is preserved for livepatch modules (see Section 5), a livepatch relocation section can be applied simply by passing in the appropriate section index to apply_relocate_add(), which then uses it to access the relocation section and apply the relocations. @@ -292,8 +293,19 @@ Symbol table '.symtab' contains 127 entries: [*] Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20). "OS" means OS-specific. +- +4. Architecture-specific sections +- +Architectures may override arch_klp_init_object_loaded() to perform +additional arch-specific tasks when a target module loads, such as applying +arch-specific sections. On x86 for example, we must apply per-object +.altinstructions and .parainstructions sections when a target module loads. +These sections can be prefixed with ".klp.arch.$objname." so that they can +be easily identified when iterating through a patch module's Elf sections +(See arch/x86/kernel/livepatch.c for a complete example). + -- -4. Symbol table and Elf section access +5. Symbol table and Elf section access -- A livepatch module's symbol table is accessible through module->symtab. -- 2.5.5
[PATCH v3 0/3] Fix issue with alternatives/paravirt patches
Hi,
A few months ago, Chris Arges reported a bug involving alternatives/paravirt
patching that was discussed here [1] and here [2]. To briefly summarize the
bug, patch modules that contained .altinstructions or .parainstructions
sections would break because these alternative/paravirt patches would be
applied first by the module loader (see x86 module_finalize()), then
livepatch would later clobber these patches when applying per-object
relocations. This lead to crashes and unpredictable behavior.
One conclusion we reached from our last discussion was that we will
need to introduce some arch-specific code to address this problem.
This patchset presents a possible fix for the bug by adding a new
arch-specific arch_klp_init_object_loaded() function that by default
does nothing but can be overridden by different arches.
To fix this issue for x86, since we can access a patch module's Elf
sections through mod->klp_info, we can simply delay the calls to
apply_paravirt() and apply_alternatives() to arch_klp_init_object_loaded(),
which is called after relocations have been written for an object.
In addition, for patch modules, .parainstructions and .altinstructions are
prefixed by ".klp.arch.${objname}" so that the module loader ignores them
and livepatch can apply them manually.
Currently for kpatch, we don't support including jump table sections in
the patch module, and supporting .smp_locks is currently broken, so we
don't consider those sections (for now).
I did some light testing with some patches to kvm and verified that the
original issue reported in [2] was fixed.
Based on linux-next.
v2 here:
http://lkml.kernel.org/g/1469078640-26798-1-git-send-email-j...@redhat.com
v3:
- Add documentation about arch-specific code
- Make sure to call module_enable_ro() when returning on error
v2:
- add BUILD_BUG_ON() check in arch_klp_init_object_loaded (x86)
[1] http://thread.gmane.org/gmane.linux.kernel/2185604/
[2] https://github.com/dynup/kpatch/issues/580
Jessica Yu (3):
livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks
livepatch/x86: apply alternatives and paravirt patches after relocations
Documentation: livepatch: add section about arch-specific code
Documentation/livepatch/module-elf-format.txt | 20 +++--
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/livepatch.c | 65 +++
include/linux/livepatch.h | 3 ++
kernel/livepatch/core.c | 16 +--
5 files changed, 98 insertions(+), 7 deletions(-)
create mode 100644 arch/x86/kernel/livepatch.c
--
2.5.5
[PATCH v3 2/3] livepatch/x86: apply alternatives and paravirt patches after relocations
Implement arch_klp_init_object_loaded() for x86, which applies
alternatives/paravirt patches. This fixes the order in which relocations
and alternatives/paravirt patches are applied.
Previously, if a patch module had alternatives or paravirt patches,
these were applied first by the module loader before livepatch can apply
per-object relocations. The (buggy) sequence of events was:
(1) Load patch module
(2) Apply alternatives and paravirt patches to patch module
* Note that these are applied to the new functions in the patch module
(3) Apply per-object relocations to patch module when target module loads.
* This clobbers what was written in step 2
This lead to crashes and corruption in general, since livepatch would
overwrite or step on previously applied alternative/paravirt patches.
The correct sequence of events should be:
(1) Load patch module
(2) Apply per-object relocations to patch module
(3) Apply alternatives and paravirt patches to patch module
This is fixed by delaying paravirt/alternatives patching until after
relocations are applied. Any .altinstructions or .parainstructions
sections are prefixed with ".klp.arch.${objname}" and applied in
arch_klp_init_object_loaded().
Signed-off-by: Jessica Yu
---
arch/x86/kernel/Makefile| 1 +
arch/x86/kernel/livepatch.c | 65 +
2 files changed, 66 insertions(+)
create mode 100644 arch/x86/kernel/livepatch.c
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index d3f49c3..92fd50c 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_X86_MPPARSE) += mpparse.o
obj-y += apic/
obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
+obj-$(CONFIG_LIVEPATCH)+= livepatch.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
obj-$(CONFIG_FTRACE_SYSCALLS) += ftrace.o
obj-$(CONFIG_X86_TSC) += trace_clock.o
diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c
new file mode 100644
index 000..e9d252d
--- /dev/null
+++ b/arch/x86/kernel/livepatch.c
@@ -0,0 +1,65 @@
+/*
+ * livepatch.c - x86-specific Kernel Live Patching Core
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see
[PATCH v3 1/3] livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks
Introduce arch_klp_init_object_loaded() to complete any additional
arch-specific tasks during patching. Architecture code may override this
function.
Signed-off-by: Jessica Yu
---
include/linux/livepatch.h | 3 +++
kernel/livepatch/core.c | 16 +---
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index a93a0b2..9072f04 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -116,6 +116,9 @@ int klp_unregister_patch(struct klp_patch *);
int klp_enable_patch(struct klp_patch *);
int klp_disable_patch(struct klp_patch *);
+void arch_klp_init_object_loaded(struct klp_patch *patch,
+struct klp_object *obj);
+
/* Called from the module loader during module coming/going states */
int klp_module_coming(struct module *mod);
void klp_module_going(struct module *mod);
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 8bbe507..5fbabe0 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -274,7 +274,6 @@ static int klp_write_object_relocations(struct module *pmod,
objname = klp_is_module(obj) ? obj->name : "vmlinux";
- module_disable_ro(pmod);
/* For each klp relocation section */
for (i = 1; i < pmod->klp_info->hdr.e_shnum; i++) {
sec = pmod->klp_info->sechdrs + i;
@@ -309,7 +308,6 @@ static int klp_write_object_relocations(struct module *pmod,
break;
}
- module_enable_ro(pmod, true);
return ret;
}
@@ -763,6 +761,12 @@ static int klp_init_func(struct klp_object *obj, struct
klp_func *func)
func->old_sympos ? func->old_sympos : 1);
}
+/* Arches may override this to finish any remaining arch-specific tasks */
+void __weak arch_klp_init_object_loaded(struct klp_patch *patch,
+ struct klp_object *obj)
+{
+}
+
/* parts of the initialization that is done only when the object is loaded */
static int klp_init_object_loaded(struct klp_patch *patch,
struct klp_object *obj)
@@ -770,9 +774,15 @@ static int klp_init_object_loaded(struct klp_patch *patch,
struct klp_func *func;
int ret;
+ module_disable_ro(patch->mod);
ret = klp_write_object_relocations(patch->mod, obj);
- if (ret)
+ if (ret) {
+ module_enable_ro(patch->mod, true);
return ret;
+ }
+
+ arch_klp_init_object_loaded(patch, obj);
+ module_enable_ro(patch->mod, true);
klp_for_each_func(obj, func) {
ret = klp_find_object_symbol(obj->name, func->old_name,
--
2.5.5
[PATCH v4 4/4] gpu: ipu-ic: allow multiple handles to ic
The image converter kernel API supports conversion contexts and
job queues, so we should allow more than one handle to the IC, so
that multiple users can add jobs to the queue.
Note however that users that control the IC manually (that do not
use the image converter APIs but setup the IC task by hand via calls
to ipu_ic_task_enable(), ipu_ic_enable(), etc.) must still be careful not
to share the IC handle with other threads. At this point, the only user
that still controls the IC manually is the i.mx capture driver. In that
case the capture driver only allows one open context to get a handle
to the IC at a time, so we should be ok there.
Signed-off-by: Steve Longerbeam
---
v4: no changes
v3: no changes
v2: no changes
---
drivers/gpu/ipu-v3/ipu-ic.c | 25 +
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 01b1b56..c44aeba 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -338,7 +338,6 @@ struct ipu_ic {
enum ipu_color_space out_cs;
bool graphics;
bool rotation;
- bool in_use;
struct image_converter cvt;
@@ -2370,38 +2369,16 @@ EXPORT_SYMBOL_GPL(ipu_ic_disable);
struct ipu_ic *ipu_ic_get(struct ipu_soc *ipu, enum ipu_ic_task task)
{
struct ipu_ic_priv *priv = ipu->ic_priv;
- unsigned long flags;
- struct ipu_ic *ic, *ret;
if (task >= IC_NUM_TASKS)
return ERR_PTR(-EINVAL);
- ic = &priv->task[task];
-
- spin_lock_irqsave(&priv->lock, flags);
-
- if (ic->in_use) {
- ret = ERR_PTR(-EBUSY);
- goto unlock;
- }
-
- ic->in_use = true;
- ret = ic;
-
-unlock:
- spin_unlock_irqrestore(&priv->lock, flags);
- return ret;
+ return &priv->task[task];
}
EXPORT_SYMBOL_GPL(ipu_ic_get);
void ipu_ic_put(struct ipu_ic *ic)
{
- struct ipu_ic_priv *priv = ic->priv;
- unsigned long flags;
-
- spin_lock_irqsave(&priv->lock, flags);
- ic->in_use = false;
- spin_unlock_irqrestore(&priv->lock, flags);
}
EXPORT_SYMBOL_GPL(ipu_ic_put);
--
1.9.1
[PATCH v4 3/4] gpu: ipu-ic: Add complete image conversion support with tiling
This patch implements complete image conversion support to ipu-ic,
with tiling to support scaling to and from images up to 4096x4096.
Image rotation is also supported.
The internal API is subsystem agnostic (no V4L2 dependency except
for the use of V4L2 fourcc pixel formats).
Callers prepare for image conversion by calling
ipu_image_convert_prepare(), which initializes the parameters of
the conversion. The caller passes in the ipu_ic task to use for
the conversion, the input and output image formats, a rotation mode,
and a completion callback and completion context pointer:
struct image_converter_ctx *
ipu_image_convert_prepare(struct ipu_ic *ic,
struct ipu_image *in, struct ipu_image *out,
enum ipu_rotate_mode rot_mode,
image_converter_cb_t complete,
void *complete_context);
The caller is given a new conversion context that must be passed to
the further APIs:
struct image_converter_run *
ipu_image_convert_run(struct image_converter_ctx *ctx,
dma_addr_t in_phys, dma_addr_t out_phys);
This queues a new image conversion request to a run queue, and
starts the conversion immediately if the run queue is empty. Only
the physaddr's of the input and output image buffers are needed,
since the conversion context was created previously with
ipu_image_convert_prepare(). Returns a new run object pointer. When
the conversion completes, the run pointer is returned to the
completion callback.
void image_convert_abort(struct image_converter_ctx *ctx);
This will abort any active or pending conversions for this context.
Any currently active or pending runs belonging to this context are
returned via the completion callback with an error status.
void ipu_image_convert_unprepare(struct image_converter_ctx *ctx);
Unprepares the conversion context. Any active or pending runs will
be aborted by calling image_convert_abort().
Signed-off-by: Steve Longerbeam
---
v4:
- do away with struct ipu_ic_tile_off, and move tile offsets into
struct ipu_ic_tile. This paves the way for possibly allowing for
each tile to have different dimensions in the future.
v3: no changes
v2: no changes
---
drivers/gpu/ipu-v3/ipu-ic.c | 1694 ++-
include/video/imx-ipu-v3.h | 57 +-
2 files changed, 1739 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 1a37afc..01b1b56 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include "ipu-prv.h"
/* IC Register Offsets */
@@ -82,6 +84,40 @@
#define IC_IDMAC_3_PP_WIDTH_MASK(0x3ff << 20)
#define IC_IDMAC_3_PP_WIDTH_OFFSET 20
+/*
+ * The IC Resizer has a restriction that the output frame from the
+ * resizer must be 1024 or less in both width (pixels) and height
+ * (lines).
+ *
+ * The image conversion support attempts to split up a conversion when
+ * the desired output (converted) frame resolution exceeds the IC resizer
+ * limit of 1024 in either dimension.
+ *
+ * If either dimension of the output frame exceeds the limit, the
+ * dimension is split into 1, 2, or 4 equal stripes, for a maximum
+ * of 4*4 or 16 tiles. A conversion is then carried out for each
+ * tile (but taking care to pass the full frame stride length to
+ * the DMA channel's parameter memory!). IDMA double-buffering is used
+ * to convert each tile back-to-back when possible (see note below
+ * when double_buffering boolean is set).
+ *
+ * Note that the input frame must be split up into the same number
+ * of tiles as the output frame.
+ */
+#define MAX_STRIPES_W4
+#define MAX_STRIPES_H4
+#define MAX_TILES (MAX_STRIPES_W * MAX_STRIPES_H)
+
+#define MIN_W 128
+#define MIN_H 128
+#define MAX_W 4096
+#define MAX_H 4096
+
+enum image_convert_type {
+ IMAGE_CONVERT_IN = 0,
+ IMAGE_CONVERT_OUT,
+};
+
struct ic_task_regoffs {
u32 rsc;
u32 tpmem_csc[2];
@@ -96,6 +132,16 @@ struct ic_task_bitfields {
u32 ic_cmb_galpha_bit;
};
+struct ic_task_channels {
+ int in;
+ int out;
+ int rot_in;
+ int rot_out;
+ int vdi_in_p;
+ int vdi_in;
+ int vdi_in_n;
+};
+
static const struct ic_task_regoffs ic_task_reg[IC_NUM_TASKS] = {
[IC_TASK_ENCODER] = {
.rsc = IC_PRP_ENC_RSC,
@@ -138,12 +184,155 @@ static const struct ic_task_bitfields
ic_task_bit[IC_NUM_TASKS] = {
},
};
+static const struct ic_task_channels ic_task_ch[IC_NUM_TASKS] = {
+ [IC_TASK_ENCODER] = {
+ .out = IPUV3_CHANNEL_IC_PRP_ENC_MEM,
+ .rot_in = IPUV3_CHANNEL_MEM_ROT_ENC,
+ .rot_out = IPUV3_CHANNEL_ROT_ENC_MEM,
+ },
+ [IC_TASK_VIEWFINDER] = {
+ .in = IPUV3_CHANNEL_MEM_IC_PRP_VF,
+ .out = IPUV3_CHANNEL_IC_PRP_VF_MEM,
+
Re: [RESEND PATCH 1/1] bitops.h: move out get_count_order[_long]() from __KERNEL__ scope
On 2016/8/18 8:28, Al Viro wrote: > On Thu, Aug 18, 2016 at 08:10:19AM +0800, zijun_hu wrote: > >> Documentation/kbuild/makefiles.txt： >> The kernel includes a set of headers that is exported to userspace. >> Many headers can be exported as-is but other headers require a >> minimal pre-processing before they are ready for user-space. >> The pre-processing does: >> - drop kernel-specific annotations >> - drop include of compiler.h >> - drop all sections that are kernel internal (guarded by ifdef __KERNEL__) >> >> scripts/Makefile.headersinst: >> # == >> # Installing headers >> # >> # header-y - list files to be installed. They are preprocessed >> # to remove __KERNEL__ section of the file >> # genhdr-y - Same as header-y but in a generated/ directory > > Quite. Now, could you show me where bitops.h is mentioned in any header-y > assignments? > you are right bitops.h isn't mentioned in any header-y my aim is making macro __KERNEL__ purpose or history purpose clear it isn't a bad thing to follow __KERNEL__ purpose it maybe look nicer to keep get_counter_order() original scope that don't matter since the current scope works well also > Stuff outside of */uapi/* is not exported at all. >
[PATCH v4 1/4] gpu: ipu-v3: Add Video Deinterlacer unit
Adds the Video Deinterlacer (VDIC) unit.
Signed-off-by: Steve Longerbeam
---
v4:
- pruned included headers.
v3:
- renamed and exported ipu_vdi_set_top_field_man() to
ipu_vdi_set_field_order(). Args include std and field to determine
correct field order.
- exported ipu_vdi_set_motion().
- ipu_vdi_setup() does not need to call ipu_vdi_set_top_field_man() or
ipu_vdi_set_motion(), since latter are exported. This simplifies args.
- removed ipu_vdi_toggle_top_field_man().
- removed ipu_vdi_set_src().
v2:
- removed include of module.h
- corrected V4L2 field type checks
- cleaned up use_count decrement in ipu_vdi_disable()
---
drivers/gpu/ipu-v3/Makefile | 2 +-
drivers/gpu/ipu-v3/ipu-common.c | 11 ++
drivers/gpu/ipu-v3/ipu-prv.h| 6 +
drivers/gpu/ipu-v3/ipu-vdi.c| 243
include/video/imx-ipu-v3.h | 23
5 files changed, 284 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/ipu-v3/ipu-vdi.c
diff --git a/drivers/gpu/ipu-v3/Makefile b/drivers/gpu/ipu-v3/Makefile
index 107ec23..aeba9dc 100644
--- a/drivers/gpu/ipu-v3/Makefile
+++ b/drivers/gpu/ipu-v3/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_IMX_IPUV3_CORE) += imx-ipu-v3.o
imx-ipu-v3-objs := ipu-common.o ipu-cpmem.o ipu-csi.o ipu-dc.o ipu-di.o \
- ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-smfc.o
+ ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-smfc.o ipu-vdi.o
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index d230988..9d3584b 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -839,6 +839,14 @@ static int ipu_submodules_init(struct ipu_soc *ipu,
goto err_ic;
}
+ ret = ipu_vdi_init(ipu, dev, ipu_base + devtype->vdi_ofs,
+ IPU_CONF_VDI_EN | IPU_CONF_ISP_EN |
+ IPU_CONF_IC_INPUT);
+ if (ret) {
+ unit = "vdi";
+ goto err_vdi;
+ }
+
ret = ipu_di_init(ipu, dev, 0, ipu_base + devtype->disp0_ofs,
IPU_CONF_DI0_EN, ipu_clk);
if (ret) {
@@ -893,6 +901,8 @@ err_dc:
err_di_1:
ipu_di_exit(ipu, 0);
err_di_0:
+ ipu_vdi_exit(ipu);
+err_vdi:
ipu_ic_exit(ipu);
err_ic:
ipu_csi_exit(ipu, 1);
@@ -977,6 +987,7 @@ static void ipu_submodules_exit(struct ipu_soc *ipu)
ipu_dc_exit(ipu);
ipu_di_exit(ipu, 1);
ipu_di_exit(ipu, 0);
+ ipu_vdi_exit(ipu);
ipu_ic_exit(ipu);
ipu_csi_exit(ipu, 1);
ipu_csi_exit(ipu, 0);
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index fd47f8f..02057d8 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -138,6 +138,7 @@ struct ipu_dc_priv;
struct ipu_dmfc_priv;
struct ipu_di;
struct ipu_ic_priv;
+struct ipu_vdi;
struct ipu_smfc_priv;
struct ipu_devtype;
@@ -170,6 +171,7 @@ struct ipu_soc {
struct ipu_di *di_priv[2];
struct ipu_csi *csi_priv[2];
struct ipu_ic_priv *ic_priv;
+ struct ipu_vdi *vdi_priv;
struct ipu_smfc_priv*smfc_priv;
};
@@ -200,6 +202,10 @@ int ipu_ic_init(struct ipu_soc *ipu, struct device *dev,
unsigned long base, unsigned long tpmem_base);
void ipu_ic_exit(struct ipu_soc *ipu);
+int ipu_vdi_init(struct ipu_soc *ipu, struct device *dev,
+unsigned long base, u32 module);
+void ipu_vdi_exit(struct ipu_soc *ipu);
+
int ipu_di_init(struct ipu_soc *ipu, struct device *dev, int id,
unsigned long base, u32 module, struct clk *ipu_clk);
void ipu_di_exit(struct ipu_soc *ipu, int id);
diff --git a/drivers/gpu/ipu-v3/ipu-vdi.c b/drivers/gpu/ipu-v3/ipu-vdi.c
new file mode 100644
index 000..f27bf5a
--- /dev/null
+++ b/drivers/gpu/ipu-v3/ipu-vdi.c
@@ -0,0 +1,243 @@
+/*
+ * Copyright (C) 2012-2016 Mentor Graphics Inc.
+ * Copyright (C) 2005-2009 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+#include
+#include "ipu-prv.h"
+
+struct ipu_vdi {
+ void __iomem *base;
+ u32 module;
+ spinlock_t lock;
+ int use_count;
+ struct ipu_soc *ipu;
+};
+
+
+/* VDI Register Offsets */
+#define VDI_FSIZE 0x
+#define VDI_C 0x0004
+
+/* VDI Register Fields */
+#define VDI_C_CH_420 (0 << 1)
+#define VDI_C_CH_422 (1 << 1)
+#define VDI_C_MOT_SEL_MASK (0x3 << 2)
+#define VDI_C_MOT_SEL_FULL (2 << 2)
+#define VDI_C_MOT_S
[PATCH v4 2/4] gpu: ipu-v3: Add FSU channel linking support
Adds functions to link and unlink source channels to sink
channels in the FSU:
int ipu_fsu_link(struct ipu_soc *ipu, int src_ch, int sink_ch);
int ipu_fsu_unlink(struct ipu_soc *ipu, int src_ch, int sink_ch);
The channels numbers are usually IDMAC channels, but they can also be
channels that do not transfer data to or from memory. The following
convenience functions can be used in place of ipu_fsu_link/unlink()
when both source and sink channels are IDMAC channels:
int ipu_idmac_link(struct ipuv3_channel *src, struct ipuv3_channel *sink);
int ipu_idmac_unlink(struct ipuv3_channel *src, struct ipuv3_channel *sink);
So far the following links are supported:
IPUV3_CHANNEL_IC_PRP_ENC_MEM -> IPUV3_CHANNEL_MEM_ROT_ENC
PUV3_CHANNEL_IC_PRP_VF_MEM -> IPUV3_CHANNEL_MEM_ROT_VF
IPUV3_CHANNEL_IC_PP_MEM -> IPUV3_CHANNEL_MEM_ROT_PP
IPUV3_CHANNEL_CSI_DIRECT -> IPUV3_CHANNEL_CSI_VDI_PREV
More links can be added to the fsu_link_info[] array.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-common.c | 131
drivers/gpu/ipu-v3/ipu-prv.h| 27 +
include/video/imx-ipu-v3.h | 13
3 files changed, 171 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 9d3584b..891cbef 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -730,6 +730,137 @@ void ipu_set_ic_src_mux(struct ipu_soc *ipu, int csi_id,
bool vdi)
}
EXPORT_SYMBOL_GPL(ipu_set_ic_src_mux);
+
+/* Frame Synchronization Unit Channel Linking */
+
+struct fsu_link_reg_info {
+ int chno;
+ u32 reg;
+ u32 mask;
+ u32 val;
+};
+
+struct fsu_link_info {
+ struct fsu_link_reg_info src;
+ struct fsu_link_reg_info sink;
+};
+
+static const struct fsu_link_info fsu_link_info[] = {
+ {
+ .src = { IPUV3_CHANNEL_IC_PRP_ENC_MEM, IPU_FS_PROC_FLOW2,
+ FS_PRP_ENC_DEST_SEL_MASK, FS_PRP_ENC_DEST_SEL_IRT_ENC
},
+ .sink = { IPUV3_CHANNEL_MEM_ROT_ENC, IPU_FS_PROC_FLOW1,
+ FS_PRPENC_ROT_SRC_SEL_MASK, FS_PRPENC_ROT_SRC_SEL_ENC
},
+ }, {
+ .src = { IPUV3_CHANNEL_IC_PRP_VF_MEM, IPU_FS_PROC_FLOW2,
+ FS_PRPVF_DEST_SEL_MASK, FS_PRPVF_DEST_SEL_IRT_VF },
+ .sink = { IPUV3_CHANNEL_MEM_ROT_VF, IPU_FS_PROC_FLOW1,
+ FS_PRPVF_ROT_SRC_SEL_MASK, FS_PRPVF_ROT_SRC_SEL_VF },
+ }, {
+ .src = { IPUV3_CHANNEL_IC_PP_MEM, IPU_FS_PROC_FLOW2,
+ FS_PP_DEST_SEL_MASK, FS_PP_DEST_SEL_IRT_PP },
+ .sink = { IPUV3_CHANNEL_MEM_ROT_PP, IPU_FS_PROC_FLOW1,
+ FS_PP_ROT_SRC_SEL_MASK, FS_PP_ROT_SRC_SEL_PP },
+ }, {
+ .src = { IPUV3_CHANNEL_CSI_DIRECT, 0 },
+ .sink = { IPUV3_CHANNEL_CSI_VDI_PREV, IPU_FS_PROC_FLOW1,
+ FS_VDI_SRC_SEL_MASK, FS_VDI_SRC_SEL_CSI_DIRECT },
+ },
+};
+
+static const struct fsu_link_info *find_fsu_link_info(int src, int sink)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(fsu_link_info); i++) {
+ if (src == fsu_link_info[i].src.chno &&
+ sink == fsu_link_info[i].sink.chno)
+ return &fsu_link_info[i];
+ }
+
+ return NULL;
+}
+
+/*
+ * Links a source channel to a sink channel in the FSU.
+ */
+int ipu_fsu_link(struct ipu_soc *ipu, int src_ch, int sink_ch)
+{
+ const struct fsu_link_info *link;
+ u32 src_reg, sink_reg;
+ unsigned long flags;
+
+ link = find_fsu_link_info(src_ch, sink_ch);
+ if (!link)
+ return -EINVAL;
+
+ spin_lock_irqsave(&ipu->lock, flags);
+
+ if (link->src.mask) {
+ src_reg = ipu_cm_read(ipu, link->src.reg);
+ src_reg &= ~link->src.mask;
+ src_reg |= link->src.val;
+ ipu_cm_write(ipu, src_reg, link->src.reg);
+ }
+
+ if (link->sink.mask) {
+ sink_reg = ipu_cm_read(ipu, link->sink.reg);
+ sink_reg &= ~link->sink.mask;
+ sink_reg |= link->sink.val;
+ ipu_cm_write(ipu, sink_reg, link->sink.reg);
+ }
+
+ spin_unlock_irqrestore(&ipu->lock, flags);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ipu_fsu_link);
+
+/*
+ * Unlinks source and sink channels in the FSU.
+ */
+int ipu_fsu_unlink(struct ipu_soc *ipu, int src_ch, int sink_ch)
+{
+ const struct fsu_link_info *link;
+ u32 src_reg, sink_reg;
+ unsigned long flags;
+
+ link = find_fsu_link_info(src_ch, sink_ch);
+ if (!link)
+ return -EINVAL;
+
+ spin_lock_irqsave(&ipu->lock, flags);
+
+ if (link->src.mask) {
+ src_reg = ipu_cm_read(ipu, link->src.reg);
+ src_reg &= ~link->src.mask;
+ ipu_cm_write(ipu, src_reg, link->src.reg);
+ }
+
+ if (link->sink.mask) {
+
[PATCH v4 0/4] IPUv3 prep for i.MX5/6 v4l2 staging drivers, v4
In this version: - rebased against latest drm-next. - cleaned up header includes in ipu-vdi.c. - do away with struct ipu_ic_tile_off in ipu-ic.c, and move tile offsets into struct ipu_ic_tile. This paves the way for possibly allowing for each tile to have different dimensions in the future. Steve Longerbeam (4): gpu: ipu-v3: Add Video Deinterlacer unit gpu: ipu-v3: Add FSU channel linking support gpu: ipu-ic: Add complete image conversion support with tiling gpu: ipu-ic: allow multiple handles to ic drivers/gpu/ipu-v3/Makefile |2 +- drivers/gpu/ipu-v3/ipu-common.c | 142 drivers/gpu/ipu-v3/ipu-ic.c | 1719 ++- drivers/gpu/ipu-v3/ipu-prv.h| 33 + drivers/gpu/ipu-v3/ipu-vdi.c| 243 ++ include/video/imx-ipu-v3.h | 93 ++- 6 files changed, 2195 insertions(+), 37 deletions(-) create mode 100644 drivers/gpu/ipu-v3/ipu-vdi.c -- 1.9.1
Re: [PATCH] extcon: Introduce EXTCON_PROP_USB_SUPERSPEED property
Hi Guenter, How about changing the property name for SuperSpeed as following? It is more simple and reduce the length of property name. - EXTCON_PROP_USB_SUPERSPEED -> EXTCON_PROP_USB_SS Regards, Chanwoo Choi On 2016년 08월 16일 10:41, Guenter Roeck wrote: > On Mon, Aug 15, 2016 at 5:55 PM, Chanwoo Choi wrote: >> Hi Guenter, >> >> Looks good to me. >> I'll add the reference[1] information on patch description and applied it. >> [1] https://en.wikipedia.org/wiki/USB#Overview >> > > Thanks! > > Guenter > >> Thanks, >> Chanwoo Choi >> >> On 2016년 08월 15일 22:15, Guenter Roeck wrote: >>> From: Guenter Roeck >>> >>> EXTCON_PROP_USB_SUPERSPEED is necessary to distinguish between USB/USB2 >>> and USB3 connections on USB Type-C cables. >>> >>> Cc: Chris Zhong >>> Signed-off-by: Guenter Roeck >>> --- >>> Applies on top of extcon-next. >>> >>> include/linux/extcon.h | 8 +++- >>> 1 file changed, 7 insertions(+), 1 deletion(-) >>> >>> diff --git a/include/linux/extcon.h b/include/linux/extcon.h >>> index ad7a1606a7f3..38d2c0dec2c1 100644 >>> --- a/include/linux/extcon.h >>> +++ b/include/linux/extcon.h >>> @@ -107,12 +107,18 @@ >>> * @type:integer (intval) >>> * @value: 0 (normal) or 1 (flip) >>> * @default: 0 (normal) >>> + * - EXTCON_PROP_USB_SUPERSPEED >>> + * @type: integer (intval) >>> + * @value: 0 (USB/USB2) or 1 (USB3) >>> + * @default:0 (USB/USB2) >>> + * >>> */ >>> #define EXTCON_PROP_USB_VBUS 0 >>> #define EXTCON_PROP_USB_TYPEC_POLARITY 1 >>> +#define EXTCON_PROP_USB_SUPERSPEED 2 >>> >>> #define EXTCON_PROP_USB_MIN 0 >>> -#define EXTCON_PROP_USB_MAX 1 >>> +#define EXTCON_PROP_USB_MAX 2 >>> #define EXTCON_PROP_USB_CNT (EXTCON_PROP_USB_MAX - EXTCON_PROP_USB_MIN + >>> 1) >>> >>> /* Properties of EXTCON_TYPE_CHG. */ >>> >> > > >
Re: [PATCH] extcon: axp288: fix spelling mistake: "connecetd" -> "connected"
On 2016년 08월 18일 03:02, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in dev_dbg messages > > Signed-off-by: Colin Ian King > --- > drivers/extcon/extcon-axp288.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c > index fd55c2f..04610f8 100644 > --- a/drivers/extcon/extcon-axp288.c > +++ b/drivers/extcon/extcon-axp288.c > @@ -189,19 +189,19 @@ static int axp288_handle_chrg_det_event(struct > axp288_extcon_info *info) Applied it. Thanks, Chanwoo Choi
Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression
On Wed, Aug 17, 2016 at 04:49:07PM +0100, Mel Gorman wrote:
> > Yes, we could try to batch the locking like DaveC already suggested
> > (ie we could move the locking to the caller, and then make
> > shrink_page_list() just try to keep the lock held for a few pages if
> > the mapping doesn't change), and that might result in fewer crazy
> > cacheline ping-pongs overall. But that feels like exactly the wrong
> > kind of workaround.
> >
>
> Even if such batching was implemented, it would be very specific to the
> case of a single large file filling LRUs on multiple nodes.
>
The latest Jason Bourne movie was sufficiently bad that I spent time
thinking how the tree_lock could be batched during reclaim. It's not
straight-forward but this prototype did not blow up on UMA and may be
worth considering if Dave can test either approach has a positive impact.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 374d95d04178..926110219cd9 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -621,19 +621,39 @@ static pageout_t pageout(struct page *page, struct
address_space *mapping,
return PAGE_CLEAN;
}
+static void finalise_remove_mapping(struct list_head *swapcache,
+ struct list_head *filecache,
+ void (*freepage)(struct page *))
+{
+ struct page *page;
+
+ while (!list_empty(swapcache)) {
+ swp_entry_t swap = { .val = page_private(page) };
+ page = lru_to_page(swapcache);
+ list_del(&page->lru);
+ swapcache_free(swap);
+ set_page_private(page, 0);
+ }
+
+ while (!list_empty(filecache)) {
+ page = lru_to_page(swapcache);
+ list_del(&page->lru);
+ freepage(page);
+ }
+}
+
/*
* Same as remove_mapping, but if the page is removed from the mapping, it
* gets returned with a refcount of 0.
*/
-static int __remove_mapping(struct address_space *mapping, struct page *page,
- bool reclaimed)
+static int __remove_mapping_page(struct address_space *mapping,
+struct page *page, bool reclaimed,
+struct list_head *swapcache,
+struct list_head *filecache)
{
- unsigned long flags;
-
BUG_ON(!PageLocked(page));
BUG_ON(mapping != page_mapping(page));
- spin_lock_irqsave(&mapping->tree_lock, flags);
/*
* The non racy check for a busy page.
*
@@ -668,16 +688,18 @@ static int __remove_mapping(struct address_space
*mapping, struct page *page,
}
if (PageSwapCache(page)) {
- swp_entry_t swap = { .val = page_private(page) };
+ unsigned long swapval = page_private(page);
+ swp_entry_t swap = { .val = swapval };
mem_cgroup_swapout(page, swap);
__delete_from_swap_cache(page);
- spin_unlock_irqrestore(&mapping->tree_lock, flags);
- swapcache_free(swap);
+ set_page_private(page, swapval);
+ list_add(&page->lru, swapcache);
} else {
- void (*freepage)(struct page *);
void *shadow = NULL;
+ void (*freepage)(struct page *);
freepage = mapping->a_ops->freepage;
+
/*
* Remember a shadow entry for reclaimed file cache in
* order to detect refaults, thus thrashing, later on.
@@ -698,16 +720,13 @@ static int __remove_mapping(struct address_space
*mapping, struct page *page,
!mapping_exiting(mapping) && !dax_mapping(mapping))
shadow = workingset_eviction(mapping, page);
__delete_from_page_cache(page, shadow);
- spin_unlock_irqrestore(&mapping->tree_lock, flags);
-
- if (freepage != NULL)
- freepage(page);
+ if (freepage)
+ list_add(&page->lru, filecache);
}
return 1;
cannot_free:
- spin_unlock_irqrestore(&mapping->tree_lock, flags);
return 0;
}
@@ -719,16 +738,68 @@ static int __remove_mapping(struct address_space
*mapping, struct page *page,
*/
int remove_mapping(struct address_space *mapping, struct page *page)
{
- if (__remove_mapping(mapping, page, false)) {
+ unsigned long flags;
+ LIST_HEAD(swapcache);
+ LIST_HEAD(filecache);
+ void (*freepage)(struct page *);
+ int ret = 0;
+
+ spin_lock_irqsave(&mapping->tree_lock, flags);
+ freepage = mapping->a_ops->freepage;
+
+ if (__remove_mapping_page(mapping, page, false, &swapcache,
&filecache)) {
/*
* Unfreezing the refcount with 1 rather than 2 effectively
* drops the pagecache ref for us without requiring another
* atomic operation.
Re: [PATCH] extcon: Introduce EXTCON_PROP_USB_SUPERSPEED property
On Wed, Aug 17, 2016 at 5:37 PM, Chanwoo Choi wrote: > Hi Guenter, > > How about changing the property name for SuperSpeed as following? > It is more simple and reduce the length of property name. > - EXTCON_PROP_USB_SUPERSPEED -> EXTCON_PROP_USB_SS > Whatever you prefer is fine. Thanks, Guenter > Regards, > Chanwoo Choi > > On 2016년 08월 16일 10:41, Guenter Roeck wrote: >> On Mon, Aug 15, 2016 at 5:55 PM, Chanwoo Choi wrote: >>> Hi Guenter, >>> >>> Looks good to me. >>> I'll add the reference[1] information on patch description and applied it. >>> [1] https://en.wikipedia.org/wiki/USB#Overview >>> >> >> Thanks! >> >> Guenter >> >>> Thanks, >>> Chanwoo Choi >>> >>> On 2016년 08월 15일 22:15, Guenter Roeck wrote: From: Guenter Roeck EXTCON_PROP_USB_SUPERSPEED is necessary to distinguish between USB/USB2 and USB3 connections on USB Type-C cables. Cc: Chris Zhong Signed-off-by: Guenter Roeck --- Applies on top of extcon-next. include/linux/extcon.h | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/linux/extcon.h b/include/linux/extcon.h index ad7a1606a7f3..38d2c0dec2c1 100644 --- a/include/linux/extcon.h +++ b/include/linux/extcon.h @@ -107,12 +107,18 @@ * @type:integer (intval) * @value: 0 (normal) or 1 (flip) * @default: 0 (normal) + * - EXTCON_PROP_USB_SUPERSPEED + * @type: integer (intval) + * @value: 0 (USB/USB2) or 1 (USB3) + * @default:0 (USB/USB2) + * */ #define EXTCON_PROP_USB_VBUS 0 #define EXTCON_PROP_USB_TYPEC_POLARITY 1 +#define EXTCON_PROP_USB_SUPERSPEED 2 #define EXTCON_PROP_USB_MIN 0 -#define EXTCON_PROP_USB_MAX 1 +#define EXTCON_PROP_USB_MAX 2 #define EXTCON_PROP_USB_CNT (EXTCON_PROP_USB_MAX - EXTCON_PROP_USB_MIN + 1) /* Properties of EXTCON_TYPE_CHG. */ >>> >> >> >> >
Re: [PATCH v2] locking/mutex: Prevent lock starvation when spinning is enabled
2016-08-18 2:30 GMT+08:00 Jason Low : > Hi Wanpeng, > > On Wed, 2016-08-17 at 09:41 +0800, Wanpeng Li wrote: >> 2016-08-11 2:44 GMT+08:00 Jason Low : >> > Imre reported an issue where threads are getting starved when trying >> > to acquire a mutex. Threads acquiring a mutex can get arbitrarily delayed >> > sleeping on a mutex because other threads can continually steal the lock >> > in the fastpath and/or through optimistic spinning. >> > >> > Waiman has developed patches that allow waiters to return to optimistic >> > spinning, thus reducing the probability that starvation occurs. However, >> > Imre still sees this starvation problem in the workloads when optimistic >> > spinning is disabled. >> > >> > This patch adds an additional boolean to the mutex that gets used in >> > the CONFIG_SMP && !CONFIG_MUTEX_SPIN_ON_OWNER cases. The flag signifies >> > whether or not other threads need to yield to a waiter and gets set >> > when a waiter spends too much time waiting for the mutex. The threshold >> > is currently set to 16 wakeups, and once the wakeup threshold is exceeded, >> > other threads must yield to the top waiter. The flag gets cleared >> > immediately after the top waiter acquires the mutex. >> >> There is a subtle difference between this patch and Waiman's. Waiman's >> patch will boost any waiter-spinner which is woken up, however, this >> patch will boost the top waiter once the number of any waiter-spinners >> woken up reaches the threshold. > > Correct, since when spinning is disabled, we still want to generally > allow other threads to steal the lock even if there are waiters in order > to keep performance good, and only yield the lock when a waiter is > getting 'starved'. > >> We can't get any benefit if the >> resource holder which top waiter is waiting for still not release the >> resource. > > If the resource holder does not release the resource, that sounds like > an issue with the lock holder. > > Unless you're referring to how this doesn't provide immediate benefit to > the top waiter, Yes. > in which case, I think that is okay since the goal of > the patch is to prevent starvation. We tried disabling 'lock stealing' > anytime there are waiters and that proved to reduce performance by quite > a bit in some workloads. Thanks for the clarification. :) Regards, Wanpeng Li
Re: [RESEND PATCH 1/1] bitops.h: move out get_count_order[_long]() from __KERNEL__ scope
On Thu, Aug 18, 2016 at 08:10:19AM +0800, zijun_hu wrote: > Documentation/kbuild/makefiles.txt： > The kernel includes a set of headers that is exported to userspace. > Many headers can be exported as-is but other headers require a > minimal pre-processing before they are ready for user-space. > The pre-processing does: > - drop kernel-specific annotations > - drop include of compiler.h > - drop all sections that are kernel internal (guarded by ifdef __KERNEL__) > > scripts/Makefile.headersinst: > # == > # Installing headers > # > # header-y - list files to be installed. They are preprocessed > # to remove __KERNEL__ section of the file > # genhdr-y - Same as header-y but in a generated/ directory Quite. Now, could you show me where bitops.h is mentioned in any header-y assignments? Stuff outside of */uapi/* is not exported at all.
[PATCH] sysctl: Handle error writing UINT_MAX to u32 fields
We have scripts which write to certain fields on 3.18 kernels but
this seems to be failing on 4.4 kernels. An entry which we write
to here is xfrm_aevent_rseqth which is u32.
echo 4294967295 > /proc/sys/net/core/xfrm_aevent_rseqth
Commit 230633d109e3 ("kernel/sysctl.c: detect overflows when
converting to int") prevented writing to sysctl entries when
integer overflow occurs. However, this does not apply to unsigned
integers.
Heinrich suggested that we introduce a new option to handle 64 bit
limits and set min as 0 and max as UINT_MAX. This might not work
as it leads to issues similar to __do_proc_doulongvec_minmax.
Alternatively, we would need to change the datatype of the entry
to 64 bit.
static int __do_proc_doulongvec_minmax(void *data, struct ctl_table
{
i = (unsigned long *) data; //This cast is causing to
read beyond the size of data (u32)
vleft = table->maxlen / sizeof(unsigned long); //vleft is 0
because maxlen is sizeof(u32) which is lesser than sizeof(unsigned
long) on x86_64.
Introduce a new proc handler proc_douintvec. Individual proc
entries will need to be updated to use the new handler.
Fixes: 230633d109e3 ("kernel/sysctl.c:detect overflows when converting to int")
Cc: Heinrich Schuchardt
Cc: Andrew Morton
Cc: Kees Cook
Cc: "David S. Miller"
Cc: Ingo Molnar
Signed-off-by: Subash Abhinov Kasiviswanathan
---
include/linux/sysctl.h | 2 ++
kernel/sysctl.c| 42 ++
2 files changed, 44 insertions(+)
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 697e160..a4f7203 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -42,6 +42,8 @@ extern int proc_dostring(struct ctl_table *, int,
void __user *, size_t *, loff_t *);
extern int proc_dointvec(struct ctl_table *, int,
void __user *, size_t *, loff_t *);
+extern int proc_douintvec(struct ctl_table *, int,
+void __user *, size_t *, loff_t *);
extern int proc_dointvec_minmax(struct ctl_table *, int,
void __user *, size_t *, loff_t *);
extern int proc_dointvec_jiffies(struct ctl_table *, int,
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index b43d0b2..96437af 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2140,6 +2140,21 @@ static int do_proc_dointvec_conv(bool *negp, unsigned
long *lvalp,
return 0;
}
+static int do_proc_douintvec_conv(bool *negp, unsigned long *lvalp,
+int *valp,
+int write, void *data)
+{
+ if (write) {
+ if (*negp)
+ return -EINVAL;
+ *valp = *lvalp;
+ } else {
+ unsigned int val = *valp;
+ *lvalp = (unsigned long)val;
+ }
+ return 0;
+}
+
static const char proc_wspace_sep[] = { ' ', '\t', '\n' };
static int __do_proc_dointvec(void *tbl_data, struct ctl_table *table,
@@ -2263,6 +2278,26 @@ int proc_dointvec(struct ctl_table *table, int write,
NULL,NULL);
}
+/**
+ * proc_douintvec - read a vector of unsigned integers
+ * @table: the sysctl table
+ * @write: %TRUE if this is a write to the sysctl file
+ * @buffer: the user buffer
+ * @lenp: the size of the user buffer
+ * @ppos: file position
+ *
+ * Reads/writes up to table->maxlen/sizeof(unsigned int) unsigned integer
+ * values from/to the user buffer, treated as an ASCII string.
+ *
+ * Returns 0 on success.
+ */
+int proc_douintvec(struct ctl_table *table, int write,
+void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+return do_proc_dointvec(table,write,buffer,lenp,ppos,
+ do_proc_douintvec_conv, NULL);
+}
+
/*
* Taint values can only be increased
* This means we can safely use a temporary.
@@ -2858,6 +2893,12 @@ int proc_dointvec(struct ctl_table *table, int write,
return -ENOSYS;
}
+int proc_douintvec(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+ return -ENOSYS;
+}
+
int proc_dointvec_minmax(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
@@ -2903,6 +2944,7 @@ int proc_doulongvec_ms_jiffies_minmax(struct ctl_table
*table, int write,
* exception granted :-)
*/
EXPORT_SYMBOL(proc_dointvec);
+EXPORT_SYMBOL(proc_douintvec);
EXPORT_SYMBOL(proc_dointvec_jiffies);
EXPORT_SYMBOL(proc_dointvec_minmax);
EXPORT_SYMBOL(proc_dointvec_userhz_jiffies);
--
1.9.1
Re: [PATCH v5 2/2] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
On Wed, Aug 17, 2016 at 03:53:24PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Heikki Krogerus writes:
>
> [...]
>
> > +static struct platform_driver wcove_typec_driver = {
> > + .driver = {
> > + .name = "bxt_wcove_usbc",
> > + },
> > + .probe = wcove_typec_probe,
> > + .remove = wcove_typec_remove,
> > +};
> > +
> > +module_platform_driver(wcove_typec_driver);
> > +
> > +MODULE_AUTHOR("Intel Corporation");
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_DESCRIPTION("WhiskeyCove PMIC USB Type-C PHY driver");
>
> you need to add:
>
> MODULE_ALIAS("platform:bxt_wcove_usbc");
>
> otherwise this won't probe() automagically.
>
What do you mean, Felipe? If there is a platform device named
"bxt_wcove_usbc", why it will not be probed?
--
Best Regards,
Peter Chen
Re: [RESEND PATCH 1/1] bitops.h: move out get_count_order[_long]() from __KERNEL__ scope
On 2016/8/18 7:59, Al Viro wrote: > On Thu, Aug 18, 2016 at 07:51:19AM +0800, zijun_hu wrote: >>> What the hell is anything without __KERNEL__ doing with linux/bitops.h in >>> the first place? IOW, why do we have those ifdefs at all? >>> >> >> __KERNEL__ is used to indicate the relevant sections within kernel >> headers can't be exported to or used by user space > > ITYM "used to be used". These days it's "everything outside of */uapi/*.h > can't be exported"... > i conclude one purpose of __KERNEL__ from the following kernel files scripts/headers_install.sh: echo "Usage: headers_install.sh OUTDIR SRCDIR [FILES...]" echo echo "Prepares kernel header files for use by user space, by removing" echo "all compiler.h definitions and #includes, removing any" echo "#ifdef __KERNEL__ sections, and putting __underscores__ around" echo "asm/inline/volatile keywords." echo .. scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ "$OUTDIR/$FILE.sed" Documentation/kbuild/makefiles.txt： The kernel includes a set of headers that is exported to userspace. Many headers can be exported as-is but other headers require a minimal pre-processing before they are ready for user-space. The pre-processing does: - drop kernel-specific annotations - drop include of compiler.h - drop all sections that are kernel internal (guarded by ifdef __KERNEL__) scripts/Makefile.headersinst: # == # Installing headers # # header-y - list files to be installed. They are preprocessed # to remove __KERNEL__ section of the file # genhdr-y - Same as header-y but in a generated/ directory # # ==
[GIT] Networking
1) Buffers powersave frame test is reversed in cfg80211, fix from Felix Fietkau. 2) Remove bogus WARN_ON in openvswitch, from Jarno Rajahalme. 3) Fix some tg3 ethtool logic bugs, and one that would cause no interrupts to be generated when rx-coalescing is set to 0. From Satish Baddipadige and Siva Reddy Kallam. 4) QLCNIC mailbox corruption and napi budget handling fix from Manish Chopra. 5) Fix fib_trie logic when walking the trie during /proc/net/route output than can access a stale node pointer. From David Forster. 6) Several sctp_diag fixes from Phil Sutter. 7) PAUSE frame handling fixes in mlxsw driver from Ido Schimmel. 8) Checksum fixup fixes in bpf from Daniel Borkmann. 9) Memork leaks in nfnetlink, from Liping Zhang. 10) Use after free in rxrpc, from David Howells. 11) Use after free in new skb_array code of macvtap driver, from Jason Wang. 12) Calipso resource leak, from Colin Ian King. 13) mediatek bug fixes (missing stats sync init, etc.) from Sean Wang. 14) Fix bpf non-linear packet write helpers, from Daniel Borkmann. 15) Fix lockdep splats in macsec, from Sabrina Dubroca. 16) hv_netvsc bug fixes from Vitaly Kuznetsov, mostly to do with VF handling. 17) Various tc-action bug fixes, from CONG Wang. Please pull, thanks a lot! The following changes since commit bf0f500bd0199aab613eb0ecb3412edd5472740d: Merge tag 'trace-v4.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2016-08-03 12:50:06 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git for you to fetch changes up to b96c22c071eb1126db4055de4bb75b02b05affd1: Merge branch 'tc_action-fixes' (2016-08-17 19:27:58 -0400) Alexander Duyck (2): ixgbe: Force VLNCTRL.VFE to be set in all VMDq paths ixgbe: Re-enable ability to toggle VLAN filtering Alexei Starovoitov (2): bpf: restore behavior of bpf_map_update_elem samples/bpf: add bpf_map_update_elem() tests Arnd Bergmann (3): net: xgene: fix maybe-uninitialized variable rxrpc: fix uninitialized pointer dereference in debug code dsa: mv88e6xxx: hide unused functions Christophe Leroy (1): netfilter: nf_conntrack_sip: CSeq 0 is a valid CSeq Colin Ian King (2): cfg80211: fix missing break in NL8211_CHAN_WIDTH_80P80 case calipso: fix resource leak on calipso_genopt failure Daniel Borkmann (5): bpf: also call skb_postpush_rcsum on xmit occasions bpf: fix checksum fixups on bpf_skb_store_bytes bpf: fix checksum for vlan push/pop helper bpf: fix bpf_skb_in_cgroup helper naming bpf: fix write helpers with regards to non-linear parts Dave Ertman (1): i40e: check for and deal with non-contiguous TCs David Forster (1): ipv4: panic in leaf_walk_rcu due to stale node pointer David Howells (6): rxrpc: Fix races between skb free, ACK generation and replying rxrpc: Need to flag call as being released on connect failure rxrpc: Don't access connection from call if pointer is NULL rxrpc: Once packet posted in data_ready, don't retry posting rxrpc: Fix a use-after-push in data_ready handler rxrpc: Free packets discarded in data_ready David S. Miller (14): Merge branch 'tg3-fixes' Merge branch 'qlcnic-fixes' Merge tag 'mac80211-for-davem-2016-08-05' of git://git.kernel.org/.../jberg/mac80211 Merge branch 'sctp_diag-fixes' Merge branch 'mlxsw-dcb-fixes' Merge branch 'bpf-csum-complete' Merge branch 'qed-fixes' Merge tag 'rxrpc-fixes-20160809' of git://git.kernel.org/.../dhowells/linux-fs Merge git://git.kernel.org/.../pablo/nf Merge branch 'hv_netvsc-VF-removal-fixes' Merge branch 'mediatek-fixes' Merge branch 'mlxsw-fixes' Merge branch '1GbE' of git://git.kernel.org/.../jkirsher/net-queue Merge branch 'tc_action-fixes' Elad Raz (1): mlxsw: spectrum: Add missing packet traps Fabian Frederick (1): net: hns: fix typo in g_gmac_stats_string[] Felix Fietkau (2): mac80211: fix check for buffered powersave frames with txq mac80211: fix purging multicast PS buffer queue Florian Westphal (1): rhashtable: avoid large lock-array allocations Geert Uytterhoeven (1): net: dsa: b53: Add missing ULL suffix for 64-bit constant Grygorii Strashko (1): drivers: net: cpsw: fix kmemleak false-positive reports for sk buffers Harini Katakam (1): net: macb: Correct CAPS mask Ian Wienand (1): OVS: Ignore negative headroom value Ido Schimmel (11): mlxsw: spectrum: Do not assume PAUSE frames are disabled mlxsw: spectrum: Do not override PAUSE settings mlxsw: spectrum: Add missing DCB rollback in error path mlxsw: spectrum: Don't return upon error in removal path mlxsw: spectrum: Remove redundant errors from the code mlxsw:
Re: [RESEND PATCH 1/1] bitops.h: move out get_count_order[_long]() from __KERNEL__ scope
On 2016/8/18 1:20, Al Viro wrote:
> On Tue, Aug 16, 2016 at 03:46:22PM +0800, zijun_hu wrote:
>> From: zijun_hu
>>
>> move out get_count_order[_long]() definitions from scope limited
>> by macro __KERNEL__
>>
>> it not only make both functions available in wider region regardless
>> of whether __KERNEL__ is defined but also keep original region for
>> get_count_order() before the recent commit c513b4cd2fe9
>> ("mm-vmalloc-fix-align-value-calculation-error-v2-fix-fix")
>
> What the hell is anything without __KERNEL__ doing with linux/bitops.h in
> the first place? IOW, why do we have those ifdefs at all?
>
__KERNEL__ is used to indicate the relevant sections within kernel
headers can't be exported to or used by user space
let me illuminate this patch background firstly
i and Andrew develop another patch to fix a mm issue recently, that
patch move get_count_order() into __KERNEL__ scope, so touch the
function's scope property we don't need to touch or care
the aim of this patch is undoing our unnecessary changes
Re: [PATCH] net: ipconfig: Fix more use after free
From: Thierry Reding
Date: Tue, 16 Aug 2016 16:45:38 +0200
> From: Thierry Reding
>
> While commit 9c706a49d660 ("net: ipconfig: fix use after free") avoids
> the use after free, the resulting code still ends up calling both the
> ic_setup_if() and ic_setup_routes() after calling ic_close_devs(), and
> access to the device is still required.
>
> Move the call to ic_close_devs() to the very end of the function.
>
> Signed-off-by: Thierry Reding
> ---
> This applies on top of next-20160816.
Applied, thanks.
