Re: [PATCH] pstore: Add boot loader log messages support
On Fri, 15 Feb 2019 12:01:30 +0800
Yue Hu wrote:
> On Tue, 12 Feb 2019 12:43:36 -0800
> Kees Cook wrote:
>
> > On Fri, Feb 1, 2019 at 12:30 AM Yue Hu wrote:
> > >
> > > From bac8bbcd6081b967422dc82074a41098a0cf5180 Mon Sep 17 00:00:00 2001
> > > From: Yue Hu
> > > Date: Tue, 29 Jan 2019 11:42:27 +0800
> > > Subject: [PATCH] pstore: Add boot loader log messages support
> > >
> > > Sometimes we hope to check boot loader log messages (e.g. Android
> > > Verified Boot status) when kernel is coming up. Generally it does
> > > depend on serial device, but it will be removed for the hardware
> > > shipping to market by most of manufacturers. In that case better
> > > solder and proper serial cable for different interface (e.g. Type-C
> > > or microUSB) are needed. That is inconvenient and even wasting much
> > > time on it.
> > >
> > > Therefore, let's add a logging support: PSTORE_TYPE_XBL.
> > >
> > > Signed-off-by: Yue Hu
> > > ---
> > > fs/pstore/Kconfig | 10
> > > fs/pstore/platform.c | 16 +
> > > fs/pstore/ram.c| 64
> > > --
> > > include/linux/pstore.h | 21 +
> > > 4 files changed, 104 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
> > > index 0d19d19..ef4a2dc 100644
> > > --- a/fs/pstore/Kconfig
> > > +++ b/fs/pstore/Kconfig
> > > @@ -137,6 +137,16 @@ config PSTORE_FTRACE
> > >
> > > If unsure, say N.
> > >
> > > +config PSTORE_XBL
> > > + bool "Log bootloader messages"
> > > + depends on PSTORE
> > > + help
> > > + When the option is enabled, pstore will log boot loader
> > > + messages to /sys/fs/pstore/xbl-ramoops-[ID] after reboot.
> > > + Boot loader needs to support log buffer reserved.
> > > +
> > > + If unsure, say N.
> > > +
> > > config PSTORE_RAM
> > > tristate "Log panic/oops to a RAM buffer"
> > > depends on PSTORE
> > > diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> > > index 0ca7657..7486e48 100644
> > > --- a/fs/pstore/platform.c
> > > +++ b/fs/pstore/platform.c
> > > @@ -66,6 +66,7 @@
> > > "mce",
> > > "console",
> > > "ftrace",
> > > + "xbl",
> > > "rtas",
> > > "powerpc-ofw",
> > > "powerpc-common",
> > > @@ -532,6 +533,19 @@ static void pstore_register_console(void) {}
> > > static void pstore_unregister_console(void) {}
> > > #endif
> > >
> > > +#ifdef CONFIG_PSTORE_XBL
> > > +static void pstore_register_xbl(void)
> > > +{
> > > + struct pstore_record record;
> > > +
> > > + pstore_record_init(&record, psinfo);
> > > + record.type = PSTORE_TYPE_XBL;
> > > + psinfo->write(&record);
> > > +}
> >
> > This writes a zero-length record at registration time. Why?
>
> It's related to interact with boot loader. Write callback will get the
> real record size which is set by boot loader.
>
> >
> > > +#else
> > > +static void pstore_register_xbl(void) {}
> > > +#endif
> > > +
> > > static int pstore_write_user_compat(struct pstore_record *record,
> > > const char __user *buf)
> > > {
> > > @@ -618,6 +632,8 @@ int pstore_register(struct pstore_info *psi)
> > > pstore_register_ftrace();
> > > if (psi->flags & PSTORE_FLAGS_PMSG)
> > > pstore_register_pmsg();
> > > + if (psi->flags & PSTORE_FLAGS_XBL)
> > > + pstore_register_xbl();
> > >
> > > /* Start watching for new records, if desired. */
> > > if (pstore_update_ms >= 0) {
> > > diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> > > index ca01778..0bb086b 100644
> > > --- a/fs/pstore/ram.c
> > > +++ b/fs/pstore/ram.c
> > > @@ -56,6 +56,10 @@
> > > module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
> > > MODULE_PARM_DESC(pmsg_size, "size of user space message log");
> > >
> > > +static ulong ramoops_xbl_size = MIN_MEM_SIZE;
> > > +module_param_named(xbl_size, ramoops_xbl_size, ulong, 0400);
> > > +MODULE_PARM_DESC(xbl_size, "size of boot loader log");
> > > +
> > > static unsigned long long mem_address;
> > > module_param_hw(mem_address, ullong, other, 0400);
> > > MODULE_PARM_DESC(mem_address,
> > > @@ -88,6 +92,7 @@ struct ramoops_context {
> > > struct persistent_ram_zone *cprz; /* Console zone */
> > > struct persistent_ram_zone **fprzs; /* Ftrace zones */
> > > struct persistent_ram_zone *mprz; /* PMSG zone */
> > > + struct persistent_ram_zone *bprz; /* XBL zone */
> > > phys_addr_t phys_addr;
> > > unsigned long size;
> > > unsigned int memtype;
> > > @@ -95,6 +100,7 @@ struct ramoops_context {
> > > size_t console_size;
> > > size_t ftrace_size;
> > > size_t pmsg_size;
> > > + size_t xbl_size;
> > > int dump_oops;
> > > u32 flags;
> > > struct persi
Re: [Xen-devel] [PATCH v6 2/2] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront
Hi Konrad, On 1/17/19 11:29 PM, Konrad Rzeszutek Wilk wrote: > On Tue, Jan 15, 2019 at 09:20:36AM +0100, Roger Pau Monné wrote: >> On Tue, Jan 15, 2019 at 12:41:44AM +0800, Dongli Zhang wrote: >>> The xenstore 'ring-page-order' is used globally for each blkback queue and >>> therefore should be read from xenstore only once. However, it is obtained >>> in read_per_ring_refs() which might be called multiple times during the >>> initialization of each blkback queue. >>> >>> If the blkfront is malicious and the 'ring-page-order' is set in different >>> value by blkfront every time before blkback reads it, this may end up at >>> the "WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));" in >>> xen_blkif_disconnect() when frontend is destroyed. >>> >>> This patch reworks connect_ring() to read xenstore 'ring-page-order' only >>> once. >>> >>> Signed-off-by: Dongli Zhang >> >> LGTM: >> >> Reviewed-by: Roger Pau Monné > > Applied. > > Will push out to Jens in a couple of days. Thank you! >> >> Thanks! I only see the PATCH 1/2 (xen/blkback: add stack variable 'blkif' in connect_ring()) on the top of below branch for Jens, would you please apply this one (PATCH 2/2) as well? https://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git/log/?h=linux-next 1/2 is only a prerequisite for 2/2. Thank you very much! Dongli Zhang
Re: Crash in list_add_leaf_cfs_rq due to bad tmp_alone_branch
Hi Gabriel, On Sat, 16 Feb 2019 at 00:06, Gabriel Hartmann wrote: > > Hi Vincent, > > Apologies for the slow turn around on this. We have tried both approaches to > fixing the bug now. In both cases for a particularly long duration CPU > intensive workload we are seeing ~33% slowdown. This was somehow expected because the unused cfs_rq are not removed anymore but at least the list is correctly ordered with my patch. the official version of this patch is there: https://lkml.org/lkml/2019/2/4/121 Then, more patches have been queued that removed unused cfs_rq and keep a correct list ordering: https://lkml.org/lkml/2019/2/6/499 With these 3 patches, the slowdown should disappear and the list ordering will stay correct Regards, Vincent > > -- Gabriel > > On Fri, Jan 25, 2019 at 6:31 AM Vincent Guittot > wrote: >> >> Hi Sargun, >> >> On Mon, 21 Jan 2019 at 15:46, Vincent Guittot >> wrote: >> > >> > Hi Sargun, >> > >> > Le Friday 18 Jan 2019 à 15:06:28 (+0100), Vincent Guittot a écrit : >> > > On Fri, 18 Jan 2019 at 11:16, Vincent Guittot >> > > wrote: >> > > > >> > > > On Wed, 9 Jan 2019 at 23:43, Sargun Dhillon wrote: >> > > > > >> > > > > On Wed, Jan 9, 2019 at 2:14 PM Sargun Dhillon >> > > > > wrote: >> > > > > > >> > > > > > I picked up c40f7d74c741a907cfaeb73a7697081881c497d0 sched/fair: >> > > > > > Fix >> > > > > > infinite loop in update_blocked_averages() by reverting >> > > > > > a9e7f6544b9c >> > > > > > and put it on top of 4.19.13. In addition to this, I uninlined >> > > > > > list_add_leaf_cfs_rq for debugging. >> > > >> > > With the fix above applied, the code that manages the leaf_cfs_rq_list >> > > is the same since v4.9. >> > > Have you noticed similar problem on other older kernel version between >> > > v4.9 and v4.19 ? The problem might have been introduce while modifying >> > > other part of the scheduler like the sequence for adding/removing >> > > cgroup. >> > > >> > > Knowing the most recent kernel version without the problem could help >> > > to narrow the problem >> > > >> > > Thanks, >> > > Vincent >> > > >> > > > > > >> > > > > > This revealed a new bug that we didn't get to because we kept >> > > > > > getting >> > > > > > crashes from the previous issue. When we are running with cgroups >> > > > > > that >> > > > > > are rapidly changing, with CFS bandwidth control, and in addition >> > > > > > using the cpusets cgroup, we see this crash. Specifically, it >> > > > > > seems to >> > > > > > occur with cgroups that are throttled and we change the allowed >> > > > > > cpuset. >> > > > >> > > > Thanks for the context, I will try to reproduce the problem and >> > > > understand how we can stop in the middle of walking to the >> > > > sched_entity branch with a parent not already added >> > > > >> > > > How many cgroup level have you got in you setup ? >> > > > >> > > > > > >> > > > > >> > > > > This patch from Gabriel should fix the problem: >> > > > > >> > > > > >> > > > > [PATCH] sched/fair: Reset tmp_alone_branch on cfs_rq delete >> > > > > >> > > > > When a child cfs_rq is added to the leaf cfs_rq list before its >> > > > > parent >> > > > > tmp_alone_branch is set to point to the child in preparation for the >> > > > > parent being added. >> > > > > >> > > > > If the child is deleted before the parent is added then >> > > > > tmp_alone_branch >> > > > > points to a freed cfs_rq. Any future reference to tmp_alone_branch >> > > > > will >> > > > > result in a use after free. >> > > > >> > > > So, the patch below is a temporary fix that helps to recover from the >> > > > situation where tmp_alone_branch doesn't finished back to >> > > > rq->leaf_cfs_rq_list >> > > > But this situation should not happened at the beginning >> > >> > I have been able to reproduce the situation where tmp_alone_branch doesn't >> > point to rq->leaf_cfs_rq_list after enqueuing a task. >> > >> > Can you try the patch below which ensures all cfs_rq of a cgroup branch >> > will >> > be added in the list even if throttled ? >> >> Did you get a chance to test this patch ? >> >> Regards, >> Vincent >> >> > >> > The algorithm used to order cfs_rq in rq->leaf_cfs_rq_list assumes that >> > it will walk down to root the 1st time a cfs_rq is used and we will >> > finished >> > to add either a cfs_rq without parent or a cfs_rq with a parent that is >> > already >> > on the list. But this is not always true in presence of throttling. >> > Because a cfs_rq can be throttled even if it has never been used but other >> > CPUS >> > of the cgroup have already used all the bandwdith, we are not sure to go >> > down to >> > the root and add all cfs_rq in the list. >> > >> > Ensure that all cfs_rq will be added in the list even if they are >> > throttled. >> > >> > Signed-off-by: Vincent Guittot >> > --- >> > kernel/sched/fair.c | 17 + >> > 1 file changed, 17 insertions(+) >> > >> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> > index 6483834..ae468ab 100644 >> > ---
FW: [PATCH] drivers: mux: Generic register bitfield-based multiplexer driver
Cc: linux-kernel@vger.kernel.org
> -Original Message-
> From: Pankaj Bansal [mailto:pankaj.ban...@nxp.com]
> Sent: Monday, 18 February, 2019 11:10 AM
> To: Leo Li ; Peter Rosin
> Cc: Pankaj Bansal
> Subject: [PATCH] drivers: mux: Generic register bitfield-based multiplexer
> driver
>
> Generic register bitfield-based multiplexer driver that controls the
> multiplexer
> producer defined under a parent node.
> The driver corresponding to parent node provides register read/write
> capabilities.
>
> Signed-off-by: Pankaj Bansal
> ---
>
> Notes:
> Dependencies:
> - https://patchwork.ozlabs.org/patch/1043790/
>
> drivers/mux/Kconfig | 13
> drivers/mux/Makefile | 2 +
> drivers/mux/regmap.c | 139 +
> 3 files changed, 154 insertions(+)
>
> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig index
> 7659d6c5f718..a412d0955258 100644
> --- a/drivers/mux/Kconfig
> +++ b/drivers/mux/Kconfig
> @@ -58,4 +58,17 @@ config MUX_MMIO
> To compile the driver as a module, choose M here: the module will
> be called mux-mmio.
>
> +config MUX_REGMAP
> + tristate "Regmap register bitfield-controlled Multiplexer"
> + depends on (OF && REGMAP) || COMPILE_TEST
> + help
> + Regmap register bitfield-controlled Multiplexer controller.
> +
> + The driver builds multiplexer controllers for bitfields in a regmap
> + device register. For N bit wide bitfields, there will be 2^N possible
> + multiplexer states.
> +
> + To compile the driver as a module, choose M here: the module will
> + be called regmap-mmio.
> +
> endmenu
> diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile index
> 6e9fa47daf56..ae1bafac0cbd 100644
> --- a/drivers/mux/Makefile
> +++ b/drivers/mux/Makefile
> @@ -8,9 +8,11 @@ mux-adg792a-objs := adg792a.o
> mux-adgs1408-objs:= adgs1408.o
> mux-gpio-objs:= gpio.o
> mux-mmio-objs:= mmio.o
> +mux-regmap-objs := regmap.o
>
> obj-$(CONFIG_MULTIPLEXER)+= mux-core.o
> obj-$(CONFIG_MUX_ADG792A)+= mux-adg792a.o
> obj-$(CONFIG_MUX_ADGS1408) += mux-adgs1408.o
> obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
> obj-$(CONFIG_MUX_MMIO) += mux-mmio.o
> +obj-$(CONFIG_MUX_REGMAP) += mux-regmap.o
> diff --git a/drivers/mux/regmap.c b/drivers/mux/regmap.c new file mode
> 100644 index ..c2156302929a
> --- /dev/null
> +++ b/drivers/mux/regmap.c
> @@ -0,0 +1,139 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Regmap register bitfield-controlled multiplexer driver
> + *
> + * Based on drivers/mux/mmio.c
> + *
> + * Copyright 2019 NXP
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int mux_regmap_set(struct mux_control *mux, int state) {
> + struct regmap_field **fields = mux_chip_priv(mux->chip);
> +
> + return regmap_field_write(fields[mux_control_get_index(mux)], state);
> +}
> +
> +static const struct mux_control_ops mux_regmap_ops = {
> + .set = mux_regmap_set,
> +};
> +
> +static const struct of_device_id mux_regmap_dt_ids[] = {
> + { .compatible = "reg-mux", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mux_regmap_dt_ids);
> +
> +static int mux_regmap_probe(struct platform_device *pdev) {
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + struct regmap_field **fields;
> + struct mux_chip *mux_chip;
> + struct regmap *regmap;
> + int num_fields;
> + int ret;
> + int i;
> +
> + regmap = dev_get_regmap(dev->parent, NULL);
> + if (IS_ERR(regmap)) {
> + ret = PTR_ERR(regmap);
> + dev_err(dev, "failed to get regmap: %d\n", ret);
> + return ret;
> + }
> +
> + ret = of_property_count_u32_elems(np, "mux-reg-masks");
> + if (ret == 0 || ret % 2)
> + ret = -EINVAL;
> + if (ret < 0) {
> + dev_err(dev, "mux-reg-masks property missing or invalid: %d\n",
> + ret);
> + return ret;
> + }
> + num_fields = ret / 2;
> +
> + mux_chip = devm_mux_chip_alloc(dev, num_fields, num_fields *
> +sizeof(*fields));
> + if (IS_ERR(mux_chip))
> + return PTR_ERR(mux_chip);
> +
> + fields = mux_chip_priv(mux_chip);
> +
> + for (i = 0; i < num_fields; i++) {
> + struct mux_control *mux = &mux_chip->mux[i];
> + struct reg_field field;
> + s32 idle_state = MUX_IDLE_AS_IS;
> + u32 reg, mask;
> + int bits;
> +
> + ret = of_property_read_u32_index(np, "mux-reg-masks",
> + 2 * i, ®);
> + if (!ret)
> + ret = of_property_read_u32_index(np, "mux-reg-
> masks",
> +
Re: [PATCH v3 0/9] device connection: Add support for device graphs
On Fri, Feb 15, 2019 at 02:47:15PM +0200, Heikki Krogerus wrote:
> Hi Greg,
>
> On Thu, Feb 14, 2019 at 11:10:44AM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 13, 2019 at 10:45:48AM +0300, Heikki Krogerus wrote:
> > > Hi,
> > >
> > > This is the third version of my proposal to add device graph parsing
> > > to the device connection API. There was only one problem reported in
> > > v2 by Jun - kernel-doc entry was missing for the new fwnode member in
> > > struct usb_role_switch_desc - and it's now fixed.
> > >
> > > The second version of the series:
> > > https://lkml.org/lkml/2019/1/30/622
> > >
> > > The commit message from v1:
> > >
> > > This series adds support for OF and ACPI device graph parsing to the
> > > device connection API.
> > >
> > > Handling the graph is straightforward, but because I'm adding that
> > > fwnode member to struct device_connection, I had to make sure all the
> > > existing users consider it.
> > >
> > > The plan is to only support matching with fwnode in the future, so no
> > > more device name matching. The software fwnodes that we now have in
> > > kernel should make that possible, once we add support for references
> > > to them.
> > >
> > > The original RFC:
> > > https://lkml.org/lkml/2018/10/24/619
> >
> > All now merged, thanks.
>
> It looks like you have not followed the order of the patches in this
> series.
>
> You applied at least the patch 4/9 ("device connection: Add fwnode
> member to struct device_connection") as the last patch to your
> usb-next branch. The rest of the series, patches starting from 5/9,
> depend on that patch.
Ugh, did I just apply them out of order? I can't rewrite my tree now,
sorry about that, odd that my sorting didn't work.
I think all of the patches are now in the tree, so I didn't miss
anything, is there anything I can do now? Want me to revert them and
then add them back in the correct order?
thanks,
greg k-h
Re: [PATCH v3 3/6] mm: Add build time sanity check for struct page size
On 02/17/19 at 08:50am, Kees Cook wrote: > On Sat, Feb 16, 2019 at 6:02 AM Baoquan He wrote: > > > > Size of struct page might be larger than 64 bytes if debug options > > enabled, or fields added for debugging intentionally. Yet an upper > > limit need be added at build time to trigger an alert in case the > > size is too big to boot up system, warning people to check if it's > > be done on purpose in advance. > > > > Here 1/4 of PAGE_SIZE is chosen since system must have been insane > > with this value. For those systems with PAGE_SIZE larger than 4KB, > > 1KB is simply taken. > > > > Signed-off-by: Baoquan He > > --- > > mm/page_alloc.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 35fdde041f5c..eb6c8e22333b 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -67,6 +67,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -7084,6 +7085,7 @@ void __init free_area_init_nodes(unsigned long > > *max_zone_pfn) > > unsigned long start_pfn, end_pfn; > > int i, nid; > > > > + BUILD_BUG_ON(sizeof(struct page) > min_t(size_t, SZ_1K, PAGE_SIZE)); > > Are there systems with PAGE_SIZE < 1K? Maybe this should just be a > direct SZ_1K check? This check was suggested by Kirill, I forgot adding his "Suggested-by", sorry abou that. Originally he suggested to add code in generic place like this: BUILD_BUG_ON(sizeof(struct page) < min(SZ_1K, PAGE_SIZE/4)); In later post, the kbuild test robot reported an build error on i386 ARCH, http://lkml.kernel.org/r/20180911074733.GX1740@192.168.1.3 >From the report hint, I thought 'PAGE_SIZE/4' also related to the macro expansion, so change it as min_t(size_t, SZ_1K, PAGE_SIZE). Just now I tried the build again, changing it back to 'PAGE_SIZE/4' also works. BUILD_BUG_ON(sizeof(struct page) > min_t(size_t, SZ_1K, PAGE_SIZE/4)); I guess Kirill wants to make it as self explanatory for this check by suggesting it as min(SZ_1K, PAGE_SIZE/4), to stress the 'PAGE_SIZE/4'. As he said in mail thread, "If struct page is more than 1/4 of PAGE_SIZE something is horribly broken". lkml.kernel.org/r/20180903102642.rmzawwqsqjvh2mkb@kshutemo-mobl1 Just try to give more details about this adding, not defend. I am fine to take any of them. > (Also, perhaps this should use the new static_assert where struct page > is defined?) I searched with 'git grep', didn't find static_assert macro or function. And also no finding in include/linux/mm_types.h. Could you please be more specific? Thanks Baoquan > > > /* Record where the zone boundaries are */ > > memset(arch_zone_lowest_possible_pfn, 0, > > sizeof(arch_zone_lowest_possible_pfn)); > > -- > > 2.17.2 > > > > > -- > Kees Cook
Re: [PATCH 2/2] x86: disable CONFIG_GENERIC_HWEIGHT and remove __HAVE_ARCH_SW_HWEIGHT
On Mon, Feb 18, 2019 at 02:59:31PM +0900, Masahiro Yamada wrote:
> arch/x86/include/asm/arch_hweight.h uses __sw_hweight{32,64} as
> alternatives, but they are implemented in arch/x86/lib/hweight.S
>
> x86 does not rely on the generic C implementation lib/hweight.c
> at all, so CONFIG_GENERIC_HWEIGHT should be disabled.
>
> __HAVE_ARCH_SW_HWEIGHT was unneeded in the first place.
Well, it was needed because I didn't think of removing the selection of
GENERIC_HWEIGHT in arch/x86/ at the time:
ld: lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:27: multiple
definition of `__ksymtab___sw_hweight32';
arch/x86/built-in.o:/dev/shm/bpetkov/kernel/linux/arch/x86/kernel/x8664_ksyms_64.c:47:
first defined here
ld: lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:67: multiple
definition of `__ksymtab___sw_hweight64';
arch/x86/built-in.o:/dev/shm/bpetkov/kernel/linux/arch/x86/kernel/x8664_ksyms_64.c:48:
first defined here
ld: arch/x86/lib/built-in.o: in function `__sw_hweight32':
/dev/shm/bpetkov/kernel/linux/arch/x86/lib/hweight.S:12: multiple definition of
`__sw_hweight32';
lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:15: first defined
here
ld: arch/x86/lib/built-in.o: in function `__sw_hweight64':
/dev/shm/bpetkov/kernel/linux/arch/x86/lib/hweight.S:38: multiple definition of
`__sw_hweight64';
lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:53: first defined
here
make: *** [vmlinux] Error 1
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH] binder: reduce mmap_sem write-side lock
binder has used write-side mmap_sem semaphore to release memory mapped at address space of the process. However, right lock to release pages is down_read, not down_write because page table lock already protects the race for parallel freeing. Please do not use mmap_sem write-side lock which is well known contented lock. Cc: Todd Kjos Cc: Martijn Coenen Cc: Arve Hjønnevåg Cc: Greg Kroah-Hartman Signed-off-by: Minchan Kim --- drivers/android/binder_alloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c index 022cd80e80cc3..2a62553b20fcc 100644 --- a/drivers/android/binder_alloc.c +++ b/drivers/android/binder_alloc.c @@ -964,7 +964,7 @@ enum lru_status binder_alloc_free_page(struct list_head *item, if (!mmget_not_zero(alloc->vma_vm_mm)) goto err_mmget; mm = alloc->vma_vm_mm; - if (!down_write_trylock(&mm->mmap_sem)) + if (!down_read_trylock(&mm->mmap_sem)) goto err_down_write_mmap_sem_failed; } @@ -980,7 +980,7 @@ enum lru_status binder_alloc_free_page(struct list_head *item, trace_binder_unmap_user_end(alloc, index); - up_write(&mm->mmap_sem); + up_read(&mm->mmap_sem); mmput(mm); } -- 2.21.0.rc0.258.g878e2cd30e-goog
Re: [PATCH][V3] regulator: axp20x: remove a redundant null check on rdev
On Fri, Feb 15, 2019 at 09:45:54AM +, Colin King wrote:
> From: Colin Ian King
>
> Currently rdev is dereferenced when assigning desc before rdev is null
> checked, this is leading to static analysis warnings. However, rdev
> can never be null, so the null check is redundant and can be removed.
>
> Detected by CoverityScan, CID#1476031 ("Dereference before null check")
>
> Fixes: 77e3e3b165db ("regulator: axp20x: add software based soft_start for
> AXP209 LDO3")
> Signed-off-by: Colin Ian King
>
> --
We need a third '-' character on the cut off marker.
>
> V2: Fix 2nd occurrance of this thinko
> V3: Remove null check, Dan Carpenter noted that rdev can never be null.
> ---
regards,
dan carpenter
Re: [PATCH v4 33/37] ARM: davinci: cp-intc: use readl/writel_relaxed()
niedz., 17 lut 2019 o 11:01 David Lechner napisał(a):
>
> On 2/14/19 8:52 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Raplace all calls to __raw_readl() & __raw_writel() with readl_relaxed()
>
> s/Raplace/Replace/
>
> > and writel_relaxed() respectively. It's safe to do as there's no
> > endianness conversion being done in the code.
>
> Should this be combined with patch 14/37?
>
No, this is for cp-intc and the other one is for aintc. I'd keep them separate.
Bart
> >
> > Signed-off-by: Bartosz Golaszewski
> > ---
> > arch/arm/mach-davinci/cp_intc.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/cp_intc.c
> > b/arch/arm/mach-davinci/cp_intc.c
> > index 1bf11fa8be76..f88b7f0978aa 100644
> > --- a/arch/arm/mach-davinci/cp_intc.c
> > +++ b/arch/arm/mach-davinci/cp_intc.c
> > @@ -45,13 +45,13 @@ static struct irq_domain *davinci_cp_intc_irq_domain;
> >
> > static inline unsigned int davinci_cp_intc_read(unsigned int offset)
> > {
> > - return __raw_readl(davinci_cp_intc_base + offset);
> > + return readl_relaxed(davinci_cp_intc_base + offset);
> > }
> >
> > static inline void davinci_cp_intc_write(unsigned long value,
> >unsigned int offset)
> > {
> > - __raw_writel(value, davinci_cp_intc_base + offset);
> > + writel_relaxed(value, davinci_cp_intc_base + offset);
> > }
> >
> > static void davinci_cp_intc_ack_irq(struct irq_data *d)
> >
Re: [PATCH 2/2] RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to the whitelist of devices to activate MAC address pass through.
On Mo, 2019-02-18 at 11:48 +0800, David Chen wrote:
> From: David Chen
>
> Per confirming with Realtek all devices containing RTL8153-BD should
> activate MAC pass through and there won't use pass through bit on efuse
> like in RTL8153-AD.
>
> Signed-off-by: David Chen
> ---
> drivers/net/usb/r8152.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index ada6baf8847a..86c8c64fbb0f 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -1179,7 +1179,7 @@ static int vendor_mac_passthru_addr_read(struct r8152
> *tp, struct sockaddr *sa)
> } else {
> /* test for RTL8153-BND and RTL8153-BD */
> ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_1);
> - if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK)) {
> + if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK) == 0) {
You are inverting the second half of the test. How can this possibly be
right? Had you dropped it, I would understand. But this? Are you sure?
Regards
Oliver
Re: [PATCH -next] ASoC: samsung: i2s: Fix return value check in i2s_create_secondary_device()
On Sat, 16 Feb 2019 at 02:07, Wei Yongjun wrote:
>
> In case of error, the function platform_device_register_simple() returns
> ERR_PTR() and never returns NULL. The NULL test in the return value
> check should be replaced with IS_ERR().
>
> Fixes: 7196c64c7d0c ("ASoC: samsung: i2s: Restore support for the secondary
> PCM")
> Signed-off-by: Wei Yongjun
> ---
> sound/soc/samsung/i2s.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Re: [v6] coccinelle: semantic code search for missing put_device()
>>> Which data element should not get reassigned here (before a corresponding >>> null pointer check)? >>> >> >> Thank you for your comments. >> We did some experiments: >> +id = of_find_device_by_node@p1(x) >> +... when != e = id >> ... >> Or: >> ... >> + ... when != id = e >> >> The number of issuses found by these two methods is the same. This can be because these SmPL specifications share some source code search functionality. >> When != e = id achieves this behavior. > > They are the same because neither issue arises. You might not notice a difference from a specific source file selection so far. > I would have a hard time saying which one is more reasonable to test, I suggest to reconsider the interpretation of this software situation once more. > since both are extremely unlikely. I disagree to this view because two ellipses were intentionally specified in published SmPL scripts. So some software developers found these “special use cases” important enough. >> In addition, we feel that we should probably accept this patch first, I disagree to this imagination because I would prefer to integrate a source code variant without a bug (which was copied from a version on 2013-05-08 by Petr Strnad). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/free/pci_free_consistent.cocci?id=f7b167113753e95ae61383e234f8d10142782ace#n12 I hope that nicer run time behaviour can become also relevant here. >> use it to find more memory leaks, and solve the actual problems in the >> kernel code. Your are not hindered to achieve specific software improvements with evolving development approaches while the clarification and the final integration of useful scripts for the semantic patch language can take a bit longer. >> As for the patch itself, we can continue to pursue perfect in the process >> of using it to solve practical problems. I am curious on how your attention will evolve further for the corresponding software correctness. 1. How much will you care for the order of identifiers within the application of SmPL assignment exclusions? 2. Would you like to take additional data type restrictions into account? Regards, Markus
Re: [PATCH] mm: Fix the pgtable leak
On Thu, Feb 14, 2019 at 04:23:52PM +0900, Minchan Kim wrote:
> On Wed, Feb 13, 2019 at 02:36:24PM +0100, Greg KH wrote:
> > On Wed, Feb 13, 2019 at 08:29:00PM +0900, Minchan Kim wrote:
> > > [1] was backported to v4.9 stable tree but it introduces pgtable
> > > memory leak because with fault retrial, preallocated pagetable
> > > could be leaked in second iteration.
> > > To fix the problem, this patch backport [2].
> > >
> > > [1] 5cf3e5ff95876, mm, memcg: fix reclaim deadlock with writeback
> >
> > This is really commit 63f3655f9501 ("mm, memcg: fix reclaim deadlock
> > with writeback") which was in 4.9.152, 4.14.94, 4.19.16, and 4.20.3 as
> > well as 5.0-rc2.
>
> Since 4.10, we has [2] so it should be okay other (tree > 4.10)
>
> >
> > > [2] b0b9b3df27d10, mm: stop leaking PageTables
> >
> > This commit was in 4.10, so I am guessing that this really is just a
> > backport of that commit?
>
> Yub.
>
> >
> > If so, it's not the full backport, why not take the whole thing? Why
> > only cherry-pick one chunk of it? Why do we not need the other parts?
>
> Because [2] actually aims for fixing [3] which was introduced at 4.10.
> Since then, [1] relies on the chunk I sent. Thus we don't need other part
> for 4.9.
>
> [3] 953c66c2b22a ("mm: THP page cache support for ppc64")
Hi Greg,
Any chance to look into this patch?
Re: [PATCH v2 4/4] mm: Generalize putback scan functions
On 16.02.2019 01:13, Daniel Jordan wrote:
> On Fri, Feb 15, 2019 at 10:01:05PM +, Kirill Tkhai wrote:
>> On 15.02.2019 23:39, Daniel Jordan wrote:
>>> On Thu, Feb 14, 2019 at 01:35:37PM +0300, Kirill Tkhai wrote:
+static unsigned noinline_for_stack move_pages_to_lru(struct lruvec
*lruvec,
+ struct list_head *list)
{
struct pglist_data *pgdat = lruvec_pgdat(lruvec);
+ int nr_pages, nr_moved = 0;
LIST_HEAD(pages_to_free);
+ struct page *page;
+ enum lru_list lru;
- /*
- * Put back any unfreeable pages.
- */
- while (!list_empty(page_list)) {
- struct page *page = lru_to_page(page_list);
- int lru;
-
+ while (!list_empty(list)) {
+ page = lru_to_page(list);
VM_BUG_ON_PAGE(PageLRU(page), page);
- list_del(&page->lru);
if (unlikely(!page_evictable(page))) {
+ list_del_init(&page->lru);
>>>
>>> Why change to list_del_init? It's more special than list_del but doesn't
>>> seem
>>> needed since the page is list_add()ed later.
>>
>> Not something special is here, I'll remove this _init.
>>
>>> That postprocess script from patch 1 seems kinda broken before this series,
>>> and
>>> still is. Not that it should block this change. Out of curiosity did you
>>> get
>>> it to run?
>>
>> I fixed all new warnings, which come with my changes, so the patch does not
>> make
>> the script worse.
>>
>> If you change all already existing warnings by renaming variables in
>> appropriate
>> places, the script will work in some way. But I'm not sure this is enough to
>> get
>> results correct, and I have no a big wish to dive into perl to fix warnings
>> introduced by another people, so I don't plan to do with this script
>> something else.
>
> Ok, was asking in case I was doing something wrong.
>
> With the above change, for the series, you can add
>
> Reviewed-by: Daniel Jordan
Ok, thanks.
[PATCH v3 0/4] mm: Generalize putback functions
Functions putback_inactive_pages() and move_active_pages_to_lru() are almost similar, so this patchset merges them in only function. v3: Replace list_del_init() with list_del() v2.5: Update comment v2: Fix tracing. Return VM_BUG_ON() check on the old place. Improve spelling. --- Kirill Tkhai (4): mm: Move recent_rotated pages calculation to shrink_inactive_list() mm: Move nr_deactivate accounting to shrink_active_list() mm: Remove pages_to_free argument of move_active_pages_to_lru() mm: Generalize putback scan functions .../trace/postprocess/trace-vmscan-postprocess.pl |7 + include/linux/vmstat.h |2 include/trace/events/vmscan.h | 13 +- mm/vmscan.c| 148 +++- 4 files changed, 68 insertions(+), 102 deletions(-) -- Signed-off-by: Kirill Tkhai Reviewed-by: Daniel Jordan
[PATCH v3 2/4] mm: Move nr_deactivate accounting to shrink_active_list()
We know which LRU is not active.
Signed-off-by: Kirill Tkhai
Reviewed-by: Daniel Jordan
---
mm/vmscan.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 84542004a277..8d7d55e71511 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2040,12 +2040,6 @@ static unsigned move_active_pages_to_lru(struct lruvec
*lruvec,
}
}
- if (!is_active_lru(lru)) {
- __count_vm_events(PGDEACTIVATE, nr_moved);
- count_memcg_events(lruvec_memcg(lruvec), PGDEACTIVATE,
- nr_moved);
- }
-
return nr_moved;
}
@@ -2137,6 +2131,10 @@ static void shrink_active_list(unsigned long nr_to_scan,
nr_activate = move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru);
nr_deactivate = move_active_pages_to_lru(lruvec, &l_inactive, &l_hold,
lru - LRU_ACTIVE);
+
+ __count_vm_events(PGDEACTIVATE, nr_deactivate);
+ __count_memcg_events(lruvec_memcg(lruvec), PGDEACTIVATE, nr_deactivate);
+
__mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, -nr_taken);
spin_unlock_irq(&pgdat->lru_lock);
[PATCH v3 4/4] mm: Generalize putback scan functions
This combines two similar functions move_active_pages_to_lru()
and putback_inactive_pages() into single move_pages_to_lru().
This remove duplicate code and makes object file size smaller.
Before:
textdata bss dec hex filename
570824732 128 61942f1f6 mm/vmscan.o
After:
textdata bss dec hex filename
551124600 128 59840e9c0 mm/vmscan.o
Note, that now we are checking for !page_evictable() coming
from shrink_active_list(), which shouldn't change any behavior
since that path works with evictable pages only.
Signed-off-by: Kirill Tkhai
Reviewed-by: Daniel Jordan
v3: Replace list_del_init() with list_del()
v2: Move VM_BUG_ON() up.
---
mm/vmscan.c | 122 +++
1 file changed, 40 insertions(+), 82 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 656a9b5af2a4..5647727919bc 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1807,33 +1807,53 @@ static int too_many_isolated(struct pglist_data *pgdat,
int file,
return isolated > inactive;
}
-static noinline_for_stack void
-putback_inactive_pages(struct lruvec *lruvec, struct list_head *page_list)
+/*
+ * This moves pages from @list to corresponding LRU list.
+ *
+ * We move them the other way if the page is referenced by one or more
+ * processes, from rmap.
+ *
+ * If the pages are mostly unmapped, the processing is fast and it is
+ * appropriate to hold zone_lru_lock across the whole operation. But if
+ * the pages are mapped, the processing is slow (page_referenced()) so we
+ * should drop zone_lru_lock around each page. It's impossible to balance
+ * this, so instead we remove the pages from the LRU while processing them.
+ * It is safe to rely on PG_active against the non-LRU pages in here because
+ * nobody will play with that bit on a non-LRU page.
+ *
+ * The downside is that we have to touch page->_refcount against each page.
+ * But we had to alter page->flags anyway.
+ *
+ * Returns the number of pages moved to the given lruvec.
+ */
+
+static unsigned noinline_for_stack move_pages_to_lru(struct lruvec *lruvec,
+struct list_head *list)
{
struct pglist_data *pgdat = lruvec_pgdat(lruvec);
+ int nr_pages, nr_moved = 0;
LIST_HEAD(pages_to_free);
+ struct page *page;
+ enum lru_list lru;
- /*
-* Put back any unfreeable pages.
-*/
- while (!list_empty(page_list)) {
- struct page *page = lru_to_page(page_list);
- int lru;
-
+ while (!list_empty(list)) {
+ page = lru_to_page(list);
VM_BUG_ON_PAGE(PageLRU(page), page);
- list_del(&page->lru);
if (unlikely(!page_evictable(page))) {
+ list_del(&page->lru);
spin_unlock_irq(&pgdat->lru_lock);
putback_lru_page(page);
spin_lock_irq(&pgdat->lru_lock);
continue;
}
-
lruvec = mem_cgroup_page_lruvec(page, pgdat);
SetPageLRU(page);
lru = page_lru(page);
- add_page_to_lru_list(page, lruvec, lru);
+
+ nr_pages = hpage_nr_pages(page);
+ update_lru_size(lruvec, lru, page_zonenum(page), nr_pages);
+ list_move(&page->lru, &lruvec->lists[lru]);
if (put_page_testzero(page)) {
__ClearPageLRU(page);
@@ -1847,13 +1867,17 @@ putback_inactive_pages(struct lruvec *lruvec, struct
list_head *page_list)
spin_lock_irq(&pgdat->lru_lock);
} else
list_add(&page->lru, &pages_to_free);
+ } else {
+ nr_moved += nr_pages;
}
}
/*
* To save our caller's stack, now use input list for pages to free.
*/
- list_splice(&pages_to_free, page_list);
+ list_splice(&pages_to_free, list);
+
+ return nr_moved;
}
/*
@@ -1945,7 +1969,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct
lruvec *lruvec,
reclaim_stat->recent_rotated[0] = stat.nr_activate[0];
reclaim_stat->recent_rotated[1] = stat.nr_activate[1];
- putback_inactive_pages(lruvec, &page_list);
+ move_pages_to_lru(lruvec, &page_list);
__mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, -nr_taken);
@@ -1982,72 +2006,6 @@ shrink_inactive_list(unsigned long nr_to_scan, struct
lruvec *lruvec,
return nr_reclaimed;
}
-/*
- * This moves pages from the active list to the inactive list.
- *
- * We move them the other way if the page is referenced by one or more
- * processes, from rmap.
- *
- * If the pages are mostly unmapped, the processing is fast and it is
- * appropriate to hold zone_lru_lock across the whole operation. But
[PATCH v3 3/4] mm: Remove pages_to_free argument of move_active_pages_to_lru()
We may use input argument list as output argument too.
This makes the function more similar to putback_inactive_pages().
Signed-off-by: Kirill Tkhai
Reviewed-by: Daniel Jordan
v2: Fix comment spelling.
---
mm/vmscan.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 8d7d55e71511..656a9b5af2a4 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2004,10 +2004,10 @@ shrink_inactive_list(unsigned long nr_to_scan, struct
lruvec *lruvec,
static unsigned move_active_pages_to_lru(struct lruvec *lruvec,
struct list_head *list,
-struct list_head *pages_to_free,
enum lru_list lru)
{
struct pglist_data *pgdat = lruvec_pgdat(lruvec);
+ LIST_HEAD(pages_to_free);
struct page *page;
int nr_pages;
int nr_moved = 0;
@@ -2034,12 +2034,17 @@ static unsigned move_active_pages_to_lru(struct lruvec
*lruvec,
(*get_compound_page_dtor(page))(page);
spin_lock_irq(&pgdat->lru_lock);
} else
- list_add(&page->lru, pages_to_free);
+ list_add(&page->lru, &pages_to_free);
} else {
nr_moved += nr_pages;
}
}
+ /*
+* To save our caller's stack, now use input list for pages to free.
+*/
+ list_splice(&pages_to_free, list);
+
return nr_moved;
}
@@ -2129,8 +2134,10 @@ static void shrink_active_list(unsigned long nr_to_scan,
*/
reclaim_stat->recent_rotated[file] += nr_rotated;
- nr_activate = move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru);
- nr_deactivate = move_active_pages_to_lru(lruvec, &l_inactive, &l_hold,
lru - LRU_ACTIVE);
+ nr_activate = move_active_pages_to_lru(lruvec, &l_active, lru);
+ nr_deactivate = move_active_pages_to_lru(lruvec, &l_inactive, lru -
LRU_ACTIVE);
+ /* Keep all free pages in l_active list */
+ list_splice(&l_inactive, &l_active);
__count_vm_events(PGDEACTIVATE, nr_deactivate);
__count_memcg_events(lruvec_memcg(lruvec), PGDEACTIVATE, nr_deactivate);
@@ -2138,8 +2145,8 @@ static void shrink_active_list(unsigned long nr_to_scan,
__mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, -nr_taken);
spin_unlock_irq(&pgdat->lru_lock);
- mem_cgroup_uncharge_list(&l_hold);
- free_unref_page_list(&l_hold);
+ mem_cgroup_uncharge_list(&l_active);
+ free_unref_page_list(&l_active);
trace_mm_vmscan_lru_shrink_active(pgdat->node_id, nr_taken, nr_activate,
nr_deactivate, nr_rotated, sc->priority, file);
}
[PATCH v3 1/4] mm: Move recent_rotated pages calculation to shrink_inactive_list()
The patch moves the calculation from putback_inactive_pages()
to shrink_inactive_list(). This makes putback_inactive_pages()
looking more similar to move_active_pages_to_lru().
To do that, we account activated pages in reclaim_stat::nr_activate.
Since a page may change its LRU type from anon to file cache
inside shrink_page_list() (see ClearPageSwapBacked()), we have to
account pages for the both types. So, nr_activate becomes an array.
Previously we used nr_activate to account PGACTIVATE events, but now
we account them into pgactivate variable (since they are about
number of pages in general, not about sum of hpage_nr_pages).
Signed-off-by: Kirill Tkhai
Reviewed-by: Daniel Jordan
v2.5: Update comment.
v2: Update trace events.
---
.../trace/postprocess/trace-vmscan-postprocess.pl |7 ---
include/linux/vmstat.h |2 +-
include/trace/events/vmscan.h | 13 -
mm/vmscan.c| 15 +++
4 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
index 66bfd8396877..995da15b16ca 100644
--- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
+++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
@@ -113,7 +113,7 @@ my $regex_kswapd_wake_default = 'nid=([0-9]*)
order=([0-9]*)';
my $regex_kswapd_sleep_default = 'nid=([0-9]*)';
my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)
gfp_flags=([A-Z_|]*)';
my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) classzone_idx=([0-9]*)
order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_skipped=([0-9]*)
nr_taken=([0-9]*) lru=([a-z_]*)';
-my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) nr_scanned=([0-9]*)
nr_reclaimed=([0-9]*) nr_dirty=([0-9]*) nr_writeback=([0-9]*)
nr_congested=([0-9]*) nr_immediate=([0-9]*) nr_activate=([0-9]*)
nr_ref_keep=([0-9]*) nr_unmap_fail=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)';
+my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) nr_scanned=([0-9]*)
nr_reclaimed=([0-9]*) nr_dirty=([0-9]*) nr_writeback=([0-9]*)
nr_congested=([0-9]*) nr_immediate=([0-9]*) nr_activate_anon=([0-9]*)
nr_activate_file=([0-9]*) nr_ref_keep=([0-9]*) nr_unmap_fail=([0-9]*)
priority=([0-9]*) flags=([A-Z_|]*)';
my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*)
nr_rotated=([0-9]*) priority=([0-9]*)';
my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)';
@@ -212,7 +212,8 @@ $regex_lru_shrink_inactive = generate_traceevent_regex(
"vmscan/mm_vmscan_lru_shrink_inactive",
$regex_lru_shrink_inactive_default,
"nid", "nr_scanned", "nr_reclaimed", "nr_dirty",
"nr_writeback",
- "nr_congested", "nr_immediate", "nr_activate",
"nr_ref_keep",
+ "nr_congested", "nr_immediate", "nr_activate_anon",
+ "nr_activate_file", "nr_ref_keep",
"nr_unmap_fail", "priority", "flags");
$regex_lru_shrink_active = generate_traceevent_regex(
"vmscan/mm_vmscan_lru_shrink_active",
@@ -407,7 +408,7 @@ sub process_events {
}
my $nr_reclaimed = $3;
- my $flags = $12;
+ my $flags = $13;
my $file = 0;
if ($flags =~ /RECLAIM_WB_FILE/) {
$file = 1;
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 2db8d60981fe..bdeda4b079fe 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -26,7 +26,7 @@ struct reclaim_stat {
unsigned nr_congested;
unsigned nr_writeback;
unsigned nr_immediate;
- unsigned nr_activate;
+ unsigned nr_activate[2];
unsigned nr_ref_keep;
unsigned nr_unmap_fail;
};
diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
index a1cb91342231..4f0e45e90cfc 100644
--- a/include/trace/events/vmscan.h
+++ b/include/trace/events/vmscan.h
@@ -358,7 +358,8 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive,
__field(unsigned long, nr_writeback)
__field(unsigned long, nr_congested)
__field(unsigned long, nr_immediate)
- __field(unsigned long, nr_activate)
+ __field(unsigned int, nr_activate0)
+ __field(unsigned int, nr_activate1)
__field(unsigned long, nr_ref_keep)
__field(unsigned long, nr_unmap_fail)
__field(int, priority)
@@ -373,20 +374,22 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive,
__entry->nr_writeback = stat->nr_writeback;
__entry->nr_congested = stat->nr_congested;
__entry->nr_immediate
Re: [PATCH 2/2] RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to the whitelist of devices to activate MAC address pass through.
Hi Oliver,
Thanks for reviewing. I have made some mistake, will correct it and resend.
Thanks and Regards,
-David
> Oliver Neukum 於 2019年2月18日 下午4:04 寫道：
>
>> On Mo, 2019-02-18 at 11:48 +0800, David Chen wrote:
>> From: David Chen
>>
>> Per confirming with Realtek all devices containing RTL8153-BD should
>> activate MAC pass through and there won't use pass through bit on efuse
>> like in RTL8153-AD.
>>
>> Signed-off-by: David Chen
>> ---
>> drivers/net/usb/r8152.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
>> index ada6baf8847a..86c8c64fbb0f 100644
>> --- a/drivers/net/usb/r8152.c
>> +++ b/drivers/net/usb/r8152.c
>> @@ -1179,7 +1179,7 @@ static int vendor_mac_passthru_addr_read(struct r8152
>> *tp, struct sockaddr *sa)
>>} else {
>>/* test for RTL8153-BND and RTL8153-BD */
>>ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_1);
>> -if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK)) {
>> +if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK) == 0) {
>
> You are inverting the second half of the test. How can this possibly be
> right? Had you dropped it, I would understand. But this? Are you sure?
>
>Regards
>Oliver
>
Re: [PATCH] ASoC: samsung: i2s: Prevent potential NULL platform data dereference
On Thu, 14 Feb 2019 at 16:58, Sylwester Nawrocki wrote: > > When np is NULL i2s_pdata could also be NULL but i2s_pdata is now being > dereferenced without proper check. Fix this and shorten the error message > so we don't exceed 80 characters limit. > > Reported-by: Dan Carpenter > Signed-off-by: Sylwester Nawrocki > --- > sound/soc/samsung/i2s.c | 27 +++ > 1 file changed, 15 insertions(+), 12 deletions(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH] kbuild: Disable extra debugging info in .s output
On Sun, Feb 10, 2019 at 01:39:23PM +0100, Borislav Petkov wrote: > Please attach the diff or send it from another mail server. So you couldn't be bothered to send me an applicable version so I went and typed it in by hand. Thanks. ;-\ Anyway, this variant works too, pls queue it. Acked-by: Borislav Petkov Tested-by: Borislav Petkov Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] kvm: vmx: Fix entry nubmer check for add_atomic_switch_msr()
On Fri, 2019-02-15 at 11:46 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 14, 2019 at 12:08:58PM +0800, Xiaoyao Li wrote:
> > Commit ca83b4a7f2d068da79a0 ("x86/KVM/VMX: Add find_msr() helper function")
> > introduces the helper function find_msr(), which returns -ENOENT when
> > not find the msr in vmx->msr_autoload.guest/host. Correct checking contion
>
> s/not find/cannot find/
> s/contion/condition/ ?
>
Hi Paolo,
Could you correct these typos in KVM tree or when sending a PR?
> > of no more available entry in vmx->msr_autoload.
> >
> > Fixes: ca83b4a7f2d0 ("x86/KVM/VMX: Add find_msr() helper function")
> > Signed-off-by: Xiaoyao Li
> > ---
> > arch/x86/kvm/vmx/vmx.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index 95d618045001..1aaef2d536bd 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -863,7 +863,8 @@ static void add_atomic_switch_msr(struct vcpu_vmx *vmx,
> > unsigned msr,
> > if (!entry_only)
> > j = find_msr(&m->host, msr);
> >
> > - if (i == NR_AUTOLOAD_MSRS || j == NR_AUTOLOAD_MSRS) {
> > + if ((i < 0 && m->guest.nr == NR_AUTOLOAD_MSRS) ||
> > + (j < 0 && m->host.nr == NR_AUTOLOAD_MSRS)) {
> > printk_once(KERN_WARNING "Not enough msr switch entries. "
> > "Can't add msr %x\n", msr);
> > return;
> > --
> > 2.19.1
> >
Re: [PATCH v3 4/6] x86/mm/KASLR: Fix the wrong calculation of memory region initial size
On 02/17/19 at 08:53am, Kees Cook wrote:
> On Sat, Feb 16, 2019 at 6:03 AM Baoquan He wrote:
> >
> > In memory region KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate
> > the initial size of the direct mapping region. This is correct in
> > the old code where __PHYSICAL_MASK_SHIFT was equal to MAX_PHYSMEM_BITS,
> > 46 bits, and only 4-level mode was supported.
> >
> > Later, in commit b83ce5ee91471d ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT
> > always 52"), __PHYSICAL_MASK_SHIFT was changed to be always 52 bits, no
> > matter it's 5-level or 4-level. This is wrong for 4-level paging. Then
> > when we adapt physical memory region size based on available memory, it
> > will overflow if the amount of system RAM and the padding is bigger
> > than 64 TB.
> >
> > In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by
> > replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.
> >
> > Fixes: b83ce5ee9147 ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52")
> > Acked-by: Kirill A. Shutemov
> > Reviewed-by: Thomas Garnier
> > Signed-off-by: Baoquan He
>
> Nice catch! I wish I had a system with >64TB RAM. ;)
>
> Acked-by: Kees Cook
Thanks for reviewing and ack-ing. I don't have system with 64 TB RAM
either. This fix is from code reading. In patch 0006, the UV system
issue is a serious regression when I introduced KASLR into RHEL, now
even though a RHEL-only fix has been merged in our distros, the tracker
bug which tracks upstream fix will go to me during planning stage of
each RHEL version. After Kirill pushed 5-level code, SGI UV dev said the
old bug can't be reproduced any more in upstream kernel, I read code
and found that the code bug fixed in this patch will hide the SGI UV
issue :-).
>
> > ---
> > arch/x86/mm/kaslr.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> > index bf680929fe26..97768df923e3 100644
> > --- a/arch/x86/mm/kaslr.c
> > +++ b/arch/x86/mm/kaslr.c
> > @@ -137,7 +137,7 @@ void __init kernel_randomize_memory(void)
> > if (!kaslr_memory_enabled())
> > return;
> >
> > - kaslr_regions[0].size_tb = 1 << (__PHYSICAL_MASK_SHIFT - TB_SHIFT);
> > + kaslr_regions[0].size_tb = 1 << (MAX_PHYSMEM_BITS - TB_SHIFT);
> > kaslr_regions[1].size_tb = VMALLOC_SIZE_TB;
> >
> > /*
> > --
> > 2.17.2
> >
>
>
> --
> Kees Cook
[PATCH -next] drm/radeon: remove set but not used variable 'vbi_time_out'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/si_dpm.c: In function 'si_program_response_times':
drivers/gpu/drm/radeon/si_dpm.c:3640:29: warning:
variable 'backbias_response_time' set but not used [-Wunused-but-set-variable]
It never used since introduction.
Signed-off-by: YueHaibing
---
drivers/gpu/drm/radeon/si_dpm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 0a785ef0ab66..de8bd245497f 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3637,14 +3637,13 @@ static int si_notify_smc_display_change(struct
radeon_device *rdev,
static void si_program_response_times(struct radeon_device *rdev)
{
- u32 voltage_response_time, backbias_response_time, acpi_delay_time,
vbi_time_out;
+ u32 voltage_response_time, acpi_delay_time, vbi_time_out;
u32 vddc_dly, acpi_dly, vbi_dly;
u32 reference_clock;
si_write_smc_soft_register(rdev, SI_SMC_SOFT_REGISTER_mvdd_chg_time, 1);
voltage_response_time = (u32)rdev->pm.dpm.voltage_response_time;
- backbias_response_time = (u32)rdev->pm.dpm.backbias_response_time;
if (voltage_response_time == 0)
voltage_response_time = 1000;
Re: [PATCH] binder: reduce mmap_sem write-side lock
On Mon, Feb 18, 2019 at 05:11:45PM +0900, Minchan Kim wrote: > binder has used write-side mmap_sem semaphore to release memory > mapped at address space of the process. However, right lock to > release pages is down_read, not down_write because page table lock > already protects the race for parallel freeing. > > Please do not use mmap_sem write-side lock which is well known > contented lock. > > Cc: Todd Kjos > Cc: Martijn Coenen > Cc: Arve Hjønnevåg > Cc: Greg Kroah-Hartman > Signed-off-by: Minchan Kim > --- > drivers/android/binder_alloc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Is this just needed for the recent binder changes that are in linux-next, or for older kernels as well? thanks, greg k-h
Re: [PATCH 1/2] ASoC: samsung: i2s: Fix the secondary platform device registration
On Fri, 15 Feb 2019 at 15:48, Sylwester Nawrocki wrote:
>
> This fixes unregistration of the secondary platform device so all
> resources are properly released. The test for NULL priv->pdev_sec
> is not necessary and it is removed.
>
> Signed-off-by: Sylwester Nawrocki
> ---
> This patch is based off of ASoC for-next and patches:
> ASoC: samsung: odroid: Ensure proper sample rate on pri/sec PCM
> ASoC: samsung: i2s: Prevent potential NULL platform data dereference
> ASoC: samsung: odroid: Add missing DAPM routes
>
> sound/soc/samsung/i2s.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
> index 6bf0f55d1e51..e36c44e2f1bb 100644
> --- a/sound/soc/samsung/i2s.c
> +++ b/sound/soc/samsung/i2s.c
> @@ -1359,11 +1359,10 @@ static int i2s_create_secondary_device(struct
> samsung_i2s_priv *priv)
>
> static void i2s_delete_secondary_device(struct samsung_i2s_priv *priv)
> {
> - if (priv->pdev_sec) {
> - platform_device_del(priv->pdev_sec);
> - priv->pdev_sec = NULL;
> - }
> + platform_device_unregister(priv->pdev_sec);
> + priv->pdev_sec = NULL;
Reviewed-by: Krzysztof Kozlowski
Although I think that you might need to re-order calls in
samsung_i2s_remove(). In general they should be in exact reverse order
of probe(). In this case, clk_disable_unprepare(priv->clk) should be
after unregistering secondary device. If order has to be different
because of some reasons - could you document them in comment?
Best regards,
Krzysztof
Re: [PATCH v3] usb: chipidea: Grab the (legacy) USB PHY by phandle first
Hi,
On Mon, 2019-02-18 at 03:04 +, Peter Chen wrote:
> > According to the chipidea driver bindings, the USB PHY is specified via the
> > "phys"
> > phandle node. However, this only takes effect for USB PHYs that use the
> > common
> > PHY framework. For legacy USB PHYs, a simple lookup based on the USB PHY
> > type is done instead.
> >
> > This does not play out well when more than one USB PHY is registered, since
> > the
> > first registered PHY matching the type will always be returned regardless
> > of what
> > the driver was bound to.
> >
> > Fix this by looking up the PHY based on the "phys" phandle node.
> > Although generic PHYs are rather matched by their "phys-name" and not the
> > "phys"
> > phandle directly, there is no helper for similar lookup on legacy PHYs and
> > it's
> > probably not worth the effort to add it.
> >
> > When no legacy USB PHY is found by phandle, fallback to grabbing any
> > registered
> > USB2 PHY. This ensures backward compatibility if some users were actually
> > relying
> > on this mechanism.
> >
> > Signed-off-by: Paul Kocialkowski
> > ---
> > Changes since v2:
> > * Fixed typos in commit message.
> >
> > Changes since v1:
> > * Only consider legacy USB PHY error for fallback as suggested;
> > * Checked against EPROBE_DEFER before entering fallback.
> >
> > drivers/usb/chipidea/core.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index
> > 7bfcbb23c2a4..016e4004fe9d 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -954,8 +954,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> > } else if (ci->platdata->usb_phy) {
> > ci->usb_phy = ci->platdata->usb_phy;
> > } else {
> > + ci->usb_phy = devm_usb_get_phy_by_phandle(dev->parent, "phys",
> > + 0);
> > ci->phy = devm_phy_get(dev->parent, "usb-phy");
> > - ci->usb_phy = devm_usb_get_phy(dev->parent,
> > USB_PHY_TYPE_USB2);
> > +
> > + /* Fallback to grabbing any registered USB2 PHY */
> > + if (IS_ERR(ci->usb_phy) &&
> > + PTR_ERR(ci->usb_phy) != -EPROBE_DEFER)
> > + ci->usb_phy = devm_usb_get_phy(dev->parent,
> > + USB_PHY_TYPE_USB2);
> >
>
> I think you may need to do above if ci->phy is error, and not the error is
> -EPROBE_DEFER.
As Thomas pointed out during the review of v1, the initial flow is to
try and get both ci->usb_phy and ci->phy and let the code use ci->phy
in priority later.
This change attempts to keep this flow intact. The EPROBE_DEFER check
is in case the initial ci->usb_phy is valid but deferred: we don't want
to overwrite it by calling devm_usb_get_phy which might return an
actual error and result in losing the EPROBE_DEFER information.
Does that make sense to you?
Cheers,
Paul
> Peter
>
> > /* if both generic PHY and USB PHY layers aren't enabled */
> > if (PTR_ERR(ci->phy) == -ENOSYS &&
> > --
> > 2.20.1
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Re: [PATCH] mm: Fix the pgtable leak
On Mon, Feb 18, 2019 at 05:20:26PM +0900, Minchan Kim wrote:
> On Thu, Feb 14, 2019 at 04:23:52PM +0900, Minchan Kim wrote:
> > On Wed, Feb 13, 2019 at 02:36:24PM +0100, Greg KH wrote:
> > > On Wed, Feb 13, 2019 at 08:29:00PM +0900, Minchan Kim wrote:
> > > > [1] was backported to v4.9 stable tree but it introduces pgtable
> > > > memory leak because with fault retrial, preallocated pagetable
> > > > could be leaked in second iteration.
> > > > To fix the problem, this patch backport [2].
> > > >
> > > > [1] 5cf3e5ff95876, mm, memcg: fix reclaim deadlock with writeback
> > >
> > > This is really commit 63f3655f9501 ("mm, memcg: fix reclaim deadlock
> > > with writeback") which was in 4.9.152, 4.14.94, 4.19.16, and 4.20.3 as
> > > well as 5.0-rc2.
> >
> > Since 4.10, we has [2] so it should be okay other (tree > 4.10)
> >
> > >
> > > > [2] b0b9b3df27d10, mm: stop leaking PageTables
> > >
> > > This commit was in 4.10, so I am guessing that this really is just a
> > > backport of that commit?
> >
> > Yub.
> >
> > >
> > > If so, it's not the full backport, why not take the whole thing? Why
> > > only cherry-pick one chunk of it? Why do we not need the other parts?
> >
> > Because [2] actually aims for fixing [3] which was introduced at 4.10.
> > Since then, [1] relies on the chunk I sent. Thus we don't need other part
> > for 4.9.
> >
> > [3] 953c66c2b22a ("mm: THP page cache support for ppc64")
>
> Hi Greg,
>
> Any chance to look into this patch?
You sent it on Thursday, it is Monday, I tried to actually take the
weekend off :)
It's in my queue, relax, it has good company with a few other hundred
stable patches being requested...
greg k-h
mremap vs sysctl_max_map_count
Hi all, I would like to bring up a topic that comes from an issue a customer of ours is facing with the mremap syscall + hitting the max_map_count threshold: When passing the MREMAP_FIXED flag, mremap() calls mremap_to() which does the following: 1) it unmaps the region where we want to put the new map: (new_addr, new_addr + new_len] [1] 2) IFF old_len > new_len, it unmaps the region: (old_addr + new_len, (old_addr + new_len) + (old_len - new_len)] [2] Now, having gone through steps 1) and 2), we eventually call move_vma() to do the actual move. move_vma() checks if we are at least 4 maps below max_map_count, otherwise it bails out with -ENOMEM [3]. The problem is that we might have already unmapped the vma's in steps 1) and 2), so it is not possible for userspace to figure out the state of the vma's after it gets -ENOMEM. - Did new_addr got unmaped? - Did part of the old_addr got unmaped? Because of that, it gets tricky for userspace to clean up properly on error path. While it is true that we can return -ENOMEM for more reasons (e.g: see vma_to_resize()->may_expand_vm()), I think that we might be able to pre-compute the number of maps that we are going add/release during the first two do_munmaps(), and check whether we are 4 maps below the threshold (as move_vma() does). Should not be the case, we can bail out early before we unmap anything, so we make sure the vma's are left untouched in case we are going to be short of maps. I am not sure if that is realistically doable, or there are limitations I overlooked, or we simply do not want to do that. Before investing more time and giving it a shoot, I just wanted to bring this upstream to get feedback on this matter. Thanks [1] https://github.com/torvalds/linux/blob/master/mm/mremap.c#L519 [2] https://github.com/torvalds/linux/blob/master/mm/mremap.c#L523 [3] https://github.com/torvalds/linux/blob/master/mm/mremap.c#L338 -- Oscar Salvador SUSE L3
Re: 5.0.0-rc6+: Oops at boot: RIP: 0010:__memmove+0x81/0x1a0 / vt_do_kdgkb_ioctl+0x34d/0x440 (race at reenter?)
On Sun, Feb 17, 2019 at 11:39:57PM +, Sergei Trofimovich wrote: > [ Copying as is from https://bugzilla.kernel.org/show_bug.cgi?id=202605 > and sending to LKML. Greg, Jiri, can you clarify mailing > list im MAINTAINERS as well? > https://github.com/torvalds/linux/blob/master/MAINTAINERS#L15527 > mentions no list for tty/vt/. ] > > Kernel Oops > [ 38.739241] Oops: 0003 [#1] PREEMPT SMP > [ 38.739243] CPU: 6 PID: 388 Comm: loadkeys Tainted: G C > 5.0.0-rc6-00153-g5ded5871030e #91 > [ 38.739244] Hardware name: Gigabyte Technology Co., Ltd. To be filled by > O.E.M./H77M-D3H, BIOS F12 11/14/2013 > [ 38.739249] RIP: 0010:__memmove+0x81/0x1a0 > happes on a fresh vanilla master kernel roughly at boot > (before tty login prompt): > $ uname -r > 5.0.0-rc6-00153-g5ded5871030e > > The kernel page fault happens at 'loadkeys start'. > I suspect some kind of race at reenter of vt_do_kdgkb_ioctl(KDSKBSENT): > > https://github.com/torvalds/linux/blob/master/drivers/tty/vt/keyboard.c#L1986 > > The oops trace looks similar to the following reports (no details besides > Oops) > https://bugzilla.kernel.org/show_bug.cgi?id=194589 > https://bugzilla.kernel.org/show_bug.cgi?id=202111 > > [ 38.044921] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready > [ 38.533196] usb 1-1.2: r8712u: CustomerID = 0x > [ 38.533200] usb 1-1.2: r8712u: MAC Address from efuse = 00:0d:81:a9:09:90 > [ 38.533203] usb 1-1.2: r8712u: Loading firmware from "rtlwifi/rtl8712u.bin" > [ 38.51] usbcore: registered new interface driver r8712u > [ 38.736178] BUG: unable to handle kernel paging request at 9c8735448000 > [ 38.737215] #PF error: [PROT] [WRITE] > [ 38.737216] PGD 288a05067 P4D 288a05067 PUD 288a07067 PMD 7f60c2063 PTE > 8007f5448161 > [ 38.739241] Oops: 0003 [#1] PREEMPT SMP > [ 38.739243] CPU: 6 PID: 388 Comm: loadkeys Tainted: G C > 5.0.0-rc6-00153-g5ded5871030e #91 > [ 38.739244] Hardware name: Gigabyte Technology Co., Ltd. To be filled by > O.E.M./H77M-D3H, BIOS F12 11/14/2013 > [ 38.739249] RIP: 0010:__memmove+0x81/0x1a0 > [ 38.739251] Code: 4c 89 4f 10 4c 89 47 18 48 8d 7f 20 73 d4 48 83 c2 20 e9 > a2 00 00 00 66 90 48 89 d1 4c 8b 5c 16 f8 4c 8d 54 17 f8 48 c1 e9 03 48 > a5 4d 89 1a e9 0c 01 00 00 0f 1f 40 00 48 89 d1 4c 8b 1e 49 > [ 38.739252] RSP: 0018:a1b9002d7d08 EFLAGS: 00010203 > [ 38.745857] RAX: 9c873541af43 RBX: 9c873541af43 RCX: > 0c6f105cd6bf > [ 38.745858] RDX: 637882e986b6 RSI: 9c8735447ffb RDI: > 9c8735447ffb > [ 38.745859] RBP: 9c8739cd3800 R08: 9c873b802f00 R09: > f73b > [ 38.745860] R10: b82b35f1 R11: 00505b1b004d5b1b R12: > > [ 38.745861] R13: 9c873541af3d R14: 000b R15: > 000c > [ 38.745862] FS: 7f450c390580() GS:9c873f18() > knlGS: > [ 38.745863] CS: 0010 DS: ES: CR0: 80050033 > [ 38.745864] CR2: 9c8735448000 CR3: 0007e213c002 CR4: > 000606e0 > [ 38.745865] Call Trace: > [ 38.745871] vt_do_kdgkb_ioctl+0x34d/0x440 > [ 38.745875] vt_ioctl+0xba3/0x1190 > [ 38.745879] ? __bpf_prog_run32+0x39/0x60 > [ 38.745882] ? mem_cgroup_commit_charge+0x7b/0x4e0 > [ 38.762583] tty_ioctl+0x23f/0x920 > [ 38.762586] ? preempt_count_sub+0x98/0xe0 > [ 38.762590] ? __seccomp_filter+0x67/0x600 > [ 38.762594] do_vfs_ioctl+0xa2/0x6a0 > [ 38.762597] ? syscall_trace_enter+0x192/0x2d0 > [ 38.762599] ksys_ioctl+0x3a/0x70 > [ 38.762601] __x64_sys_ioctl+0x16/0x20 > [ 38.762604] do_syscall_64+0x54/0xe0 > [ 38.772513] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 38.772515] RIP: 0033:0x7f450c2bb427 > [ 38.772517] Code: 00 00 00 75 0c 48 c7 c0 ff ff ff ff 48 83 c4 18 c3 e8 8d > d2 01 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 10 00 00 00 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 8b 0d 39 da 0c 00 f7 d8 64 89 01 48 > [ 38.772518] RSP: 002b:7fffbcedd348 EFLAGS: 0246 ORIG_RAX: > 0010 > [ 38.772519] RAX: ffda RBX: 000b RCX: > 7f450c2bb427 > [ 38.772520] RDX: 7fffbcedd360 RSI: 4b49 RDI: > 0003 > [ 38.772521] RBP: 7fffbcedd361 R08: 7f450c389c40 R09: > 55cbef2494a0 > [ 38.772522] R10: R11: 0246 R12: > 55cbef2412b0 > [ 38.772522] R13: 7fffbcedd360 R14: 000b R15: > 0003 > [ 38.772525] Modules linked in: snd_hda_codec_hdmi bridge r8712u(C) stp llc > snd_hda_codec_via snd_hda_codec_generic snd_hda_intel snd_hda_codec > x86_pkg_temp_thermal dummy kvm_intel snd_hwdep snd_hda_core snd_pcm snd_timer > kvm snd atl1c soundcore irqbypass xfs tun nf_conntrack_ftp nf_conntrack > nf_defrag_ipv6 nf_defrag_ipv4 loop fuse binfmt_misc ipv6 > [ 38.779196] r8712u 1-1.2:1.0 wl0: renamed from wlan0 > [ 38.779240] CR2: 9c8735448000 > [
Re: Firmware files for QCA BT chip WCN3990.
hi Balakrishna, On Mon, Feb 18, 2019 at 7:13 AM Balakrishna Godavarthi wrote: > > > Hi, > > The following changes since commit > a9c22d3d8af87bd39a078ec6c846b0674dd2ca38: > >qca: Add firmware files for BT chip wcn3990. (2019-02-15 16:07:56 > +0530) > > are available in the Git repository at: > >https://github.com/bgodavar/qca_bt_wcn3990_fw.git > > for you to fetch changes up to a9c22d3d8af87bd39a078ec6c846b0674dd2ca38: > >qca: Add firmware files for BT chip wcn3990. (2019-02-15 16:07:56 > +0530) qca/NOTICE.txt | 334 ++ ^ This looks a rather unexpected change. You are missing updates in WHENCE file, as such: $ make check E: qca/crbtfw21.tlv not listed in WHENCE E: qca/crnv21.bin not listed in WHENCE > > > -- > Regards > Balakrishna.
Re: [PATCH] KVM: arm/arm64: fix spelling mistake: "auxilary" -> "auxiliary"
On Sun, 17 Feb 2019 22:36:26 +
Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a kvm_err error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> virt/kvm/arm/arm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 7fcc1c8c4020..99c37384ba7b 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -1563,7 +1563,7 @@ static int init_hyp_mode(void)
>
> err = hyp_map_aux_data();
> if (err)
> - kvm_err("Cannot map host auxilary data: %d\n", err);
> + kvm_err("Cannot map host auxiliary data: %d\n", err);
>
> return 0;
>
Applied, thanks.
M.
--
Without deviation from the norm, progress is not possible.
Re: [PATCH][V3] regulator: axp20x: remove a redundant null check on rdev
On Fri, Feb 15, 2019 at 5:46 PM Colin King wrote:
>
> From: Colin Ian King
>
> Currently rdev is dereferenced when assigning desc before rdev is null
> checked, this is leading to static analysis warnings. However, rdev
> can never be null, so the null check is redundant and can be removed.
>
> Detected by CoverityScan, CID#1476031 ("Dereference before null check")
>
> Fixes: 77e3e3b165db ("regulator: axp20x: add software based soft_start for
> AXP209 LDO3")
> Signed-off-by: Colin Ian King
Acked-by: Chen-Yu Tsai
[PATCH -next] drm/qxl: remove set but not used variable 'bo_old'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/qxl/qxl_display.c: In function 'qxl_primary_atomic_update':
drivers/gpu/drm/qxl/qxl_display.c:538:17: warning:
variable 'bo_old' set but not used [-Wunused-but-set-variable]
It's not used any more after 4979904c62b9 ("drm/qxl: use shadow bo directly")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/qxl/qxl_display.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 08c725544a2f..8b319ebbb0fb 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -535,7 +535,7 @@ static void qxl_primary_atomic_update(struct drm_plane
*plane,
{
struct qxl_device *qdev = plane->dev->dev_private;
struct qxl_bo *bo = gem_to_qxl_bo(plane->state->fb->obj[0]);
- struct qxl_bo *bo_old, *primary;
+ struct qxl_bo *primary;
struct drm_clip_rect norect = {
.x1 = 0,
.y1 = 0,
@@ -544,12 +544,6 @@ static void qxl_primary_atomic_update(struct drm_plane
*plane,
};
uint32_t dumb_shadow_offset = 0;
- if (old_state->fb) {
- bo_old = gem_to_qxl_bo(old_state->fb->obj[0]);
- } else {
- bo_old = NULL;
- }
-
primary = bo->shadow ? bo->shadow : bo;
if (!primary->is_primary) {
Re: [PATCH 1/2] PM / Domains: Mark "name" const in genpd_dev_pm_attach_by_name()
On Mon, Feb 18, 2019 at 09:45:14AM +0530, Viresh Kumar wrote:
> On 15-02-19, 07:47, Doug Anderson wrote:
> > Hi,
> > On Thu, Feb 14, 2019 at 7:02 PM Viresh Kumar
> > wrote:
> > >
> > > On 14-02-19, 10:12, Douglas Anderson wrote:
> > > > The genpd_dev_pm_attach_by_name() simply takes the name and passes it
> > > > to of_property_match_string() where the argument is "const char *".
> > > > Adding a const here allows a later patch to add a const to
> > > > dev_pm_domain_attach_by_name() which allows drivers to pass in a name
> > > > that was declared "const" in a driver.
> > > >
> > > > Fixes: 5d6be70add65 ("PM / Domains: Introduce option to attach a device
> > > > by name to genpd")
> > >
> > > Not sure if this should be counted as a fix.
> >
> > I'm OK if the "Fixes" is stripped when applying or if someone tells me
> > to re-post without the Fixes--just let me know. In general I do a lot
> > of cherry-picks from upstream and I appreciate the Fixes tag helping
> > to link patches together. In this case if I picked the original patch
> > I'd definitely want this one too. Certainly, though, CCing stable
> > would make no sense in this case. ;-)
>
> I am not sure if this is being done right now or not, but I read/heard
> somewhere that stable has started picking "Fixes" patches directly as
> well even if they aren't cc'd to stable.
It's random, not always happening, and nothing you can rely on.
If you know this is a patch for older kernels, then always add the cc:
stable line, as the documentation says you have to do!
thanks,
greg k-h
Re: [PATCH V1] i2c: tegra: fix tegra186 hw supported features
On Sat, Feb 16, 2019 at 08:33:07AM -0800, Sowjanya Komatineni wrote: > Tegra186 does not support multi-master mode and also there is no > master fifo control register. > > This patch fixes supported features of Tegra186 and prevents > crashing during boot as master fifo control register are not > present on Tegra186 and prior. > > Signed-off-by: Sowjanya Komatineni > --- > drivers/i2c/busses/i2c-tegra.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) We really should've caught this earlier. Jon, let's think about ways to make it easier to catch these things in the future on our test system. Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [patch v6 0/7] genirq/affinity: Overhaul the multiple interrupt sets support
On Sat, 16 Feb 2019 18:13:06 +0100 Thomas Gleixner wrote: > This is the final update to the series with a few corner cases fixes > vs. V5 which can be found here: > >https://lkml.kernel.org/r/20190214204755.819014...@linutronix.de > > The series applies against: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master > > and is also available from: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.irq > > Changes vs. V5: > > - Change the invocation for the driver callback so it is invoked even > when there are no interrupts left to spread out. That ensures that the > driver can adjust to the situation (in case of NVME a single interrupt) > > - Make sure the callback is invoked in the legacy irq fallback case so > the driver is not in a stale state from a failed MSI[X} allocation > attempt. > > - Fix the adjustment logic in the NVME driver as pointed out by Ming and > Marc, plus another corner case I found during testing. > > - Simplify the unmanaged set support > > Thanks, > > tglx > > 8<- > drivers/nvme/host/pci.c | 117 > +--- > drivers/pci/msi.c | 39 + > drivers/scsi/be2iscsi/be_main.c |2 > include/linux/interrupt.h | 35 --- > include/linux/pci.h |4 - > kernel/irq/affinity.c | 116 > --- > 6 files changed, 153 insertions(+), 160 deletions(-) > > For the series (with or without patch 7), feel free to add my Acked-by: Marc Zyngier Thanks, M. -- Without deviation from the norm, progress is not possible.
[PATCH] i2c: cadence: try reset when master receive arbitration lost
When the adapter receive arbitration lost error interrupts,
cdns_i2c_master_xfer return to the caller directly instead of resetting
the adapter which resulted in the adapter being out of control.
So when driver detect err_status such as arbitration lost,
then try to repair and fix it.
Signed-off-by: sxauwsk
Signed-off-by: Shubhrajyoti Datta
---
drivers/i2c/busses/i2c-cadence.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index b13605718291..595b0d56ff1a 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -548,10 +548,6 @@ static int cdns_i2c_process_msg(struct cdns_i2c *id,
struct i2c_msg *msg,
cdns_i2c_writereg(CDNS_I2C_IXR_ALL_INTR_MASK,
CDNS_I2C_IDR_OFFSET);
- /* If it is bus arbitration error, try again */
- if (id->err_status & CDNS_I2C_IXR_ARB_LOST)
- return -EAGAIN;
-
return 0;
}
@@ -624,6 +620,12 @@ static int cdns_i2c_master_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
if (id->err_status) {
cdns_i2c_master_reset(adap);
+ /* If it is bus arbitration error, try again */
+ if (id->err_status & CDNS_I2C_IXR_ARB_LOST) {
+ ret = -EAGAIN;
+ goto out;
+ }
+
if (id->err_status & CDNS_I2C_IXR_NACK) {
ret = -ENXIO;
goto out;
--
2.19.2
[PATCH -next] crypto: marvell - Remove set but not used variable 'ivsize'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/crypto/marvell/cipher.c: In function 'mv_cesa_skcipher_dma_req_init':
drivers/crypto/marvell/cipher.c:325:15: warning:
variable 'ivsize' set but not used [-Wunused-but-set-variable]
It's not used any more after 0c99620f0ac1 ("crypto: marvell - Use an unique
pool to copy results of requests")
Signed-off-by: YueHaibing
---
drivers/crypto/marvell/cipher.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index 066830dcc53e..fb279b3a1ca1 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -322,7 +322,6 @@ static int mv_cesa_skcipher_dma_req_init(struct
skcipher_request *req,
struct mv_cesa_skcipher_dma_iter iter;
bool skip_ctx = false;
int ret;
- unsigned int ivsize;
basereq->chain.first = NULL;
basereq->chain.last = NULL;
@@ -381,7 +380,6 @@ static int mv_cesa_skcipher_dma_req_init(struct
skcipher_request *req,
} while (mv_cesa_skcipher_req_iter_next_op(&iter));
/* Add output data for IV */
- ivsize = crypto_skcipher_ivsize(crypto_skcipher_reqtfm(req));
ret = mv_cesa_dma_add_result_op(&basereq->chain,
CESA_SA_CFG_SRAM_OFFSET,
CESA_SA_DATA_SRAM_OFFSET,
CESA_TDMA_SRC_IN_SRAM, flags);
Re: [PATVH v2 0/4] arm64: dts: allwinner: h6: Enable CPU
Hi, On Fri, Feb 15, 2019 at 11:35:20PM +0800, Frank Lee wrote: > On Fri, Feb 15, 2019 at 11:13 PM Maxime Ripard > wrote: > > > > On Fri, Feb 15, 2019 at 08:49:33AM -0500, Yangtao Li wrote: > > > Add the cpufreq support of h6, source of information is as follows. > > > > > > h6 cpu opp info: > > > https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/arch/arm64/boot/dts/sunxi/sun50iw6p1.dtsi > > > > > > axp805 spec: > > > http://linux-sunxi.org/images/b/bc/AXP805_Datasheet_V1.0_en.pdf > > > > Was that tested on the two H6 boards this time? > > I tested two boards for about two hours. How did you test it? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH 1/5] nvmem: sunxi-sid: fix wrong description in kernel doc
On Sun, Feb 17, 2019 at 11:23:12AM -0500, Yangtao Li wrote: > qfprom->sunxi-sid > > Signed-off-by: Yangtao Li Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH] crypto: ccree: add missing inline qualifier
On Mon, Feb 11, 2019 at 3:29 PM Gilad Ben-Yossef wrote:
> Commit 1358c13a48c4 ("crypto: ccree - fix resume race condition on init")
> was missing a "inline" qualifier for stub function used when CONFIG_PM
> is not set causing a build warning.
>
> Fixes: 1358c13a48c4 ("crypto: ccree - fix resume race condition on init")
> Cc: sta...@kernel.org # v4.20
# v5.0
However, I believe the version comment is not necessary, as the same
version is indicated by the Fixes tag.
> Signed-off-by: Gilad Ben-Yossef
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/5] nvmem: sunxi-sid: add binding for H6's SID controller
On Sun, Feb 17, 2019 at 11:23:14AM -0500, Yangtao Li wrote: > Add a binding for H6's SID controller. > > Signed-off-by: Yangtao Li Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
[PATCH net-next v2 1/3] net: stmmac: Fix NAPI poll in TX path when in multi-queue
Commit 8fce33317023 introduced the concept of NAPI per-channel and
independent cleaning of TX path.
This is currently breaking performance in some cases. The scenario
happens when all packets are being received in Queue 0 but the TX is
performed in Queue != 0.
Fix this by using different NAPI instances per each TX and RX queue, as
suggested by Florian.
Changes from v1:
- Pass entire ring size to TX clean path (Florian)
Signed-off-by: Jose Abreu
Cc: Florian Fainelli
Cc: Joao Pinto
Cc: David S. Miller
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 5 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 114 --
2 files changed, 66 insertions(+), 53 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 63e1064b27a2..e697ecd9b0a6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -78,11 +78,10 @@ struct stmmac_rx_queue {
};
struct stmmac_channel {
- struct napi_struct napi cacheline_aligned_in_smp;
+ struct napi_struct rx_napi cacheline_aligned_in_smp;
+ struct napi_struct tx_napi cacheline_aligned_in_smp;
struct stmmac_priv *priv_data;
u32 index;
- int has_rx;
- int has_tx;
};
struct stmmac_tc_entry {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 685d20472358..c193bb1a3322 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -155,7 +155,10 @@ static void stmmac_disable_all_queues(struct stmmac_priv
*priv)
for (queue = 0; queue < maxq; queue++) {
struct stmmac_channel *ch = &priv->channel[queue];
- napi_disable(&ch->napi);
+ if (queue < rx_queues_cnt)
+ napi_disable(&ch->rx_napi);
+ if (queue < tx_queues_cnt)
+ napi_disable(&ch->tx_napi);
}
}
@@ -173,7 +176,10 @@ static void stmmac_enable_all_queues(struct stmmac_priv
*priv)
for (queue = 0; queue < maxq; queue++) {
struct stmmac_channel *ch = &priv->channel[queue];
- napi_enable(&ch->napi);
+ if (queue < rx_queues_cnt)
+ napi_enable(&ch->rx_napi);
+ if (queue < tx_queues_cnt)
+ napi_enable(&ch->tx_napi);
}
}
@@ -1939,6 +1945,10 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int
budget, u32 queue)
mod_timer(&priv->eee_ctrl_timer, STMMAC_LPI_T(eee_timer));
}
+ /* We still have pending packets, let's call for a new scheduling */
+ if (tx_q->dirty_tx != tx_q->cur_tx)
+ mod_timer(&tx_q->txtimer, STMMAC_COAL_TIMER(10));
+
__netif_tx_unlock_bh(netdev_get_tx_queue(priv->dev, queue));
return count;
@@ -2029,23 +2039,15 @@ static int stmmac_napi_check(struct stmmac_priv *priv,
u32 chan)
int status = stmmac_dma_interrupt_status(priv, priv->ioaddr,
&priv->xstats, chan);
struct stmmac_channel *ch = &priv->channel[chan];
- bool needs_work = false;
- if ((status & handle_rx) && ch->has_rx) {
- needs_work = true;
- } else {
- status &= ~handle_rx;
- }
-
- if ((status & handle_tx) && ch->has_tx) {
- needs_work = true;
- } else {
- status &= ~handle_tx;
+ if ((status & handle_rx) && (chan < priv->plat->rx_queues_to_use)) {
+ stmmac_disable_dma_irq(priv, priv->ioaddr, chan);
+ napi_schedule_irqoff(&ch->rx_napi);
}
- if (needs_work && napi_schedule_prep(&ch->napi)) {
+ if ((status & handle_tx) && (chan < priv->plat->tx_queues_to_use)) {
stmmac_disable_dma_irq(priv, priv->ioaddr, chan);
- __napi_schedule(&ch->napi);
+ napi_schedule_irqoff(&ch->tx_napi);
}
return status;
@@ -2241,8 +2243,14 @@ static void stmmac_tx_timer(struct timer_list *t)
ch = &priv->channel[tx_q->queue_index];
- if (likely(napi_schedule_prep(&ch->napi)))
- __napi_schedule(&ch->napi);
+ /*
+* If NAPI is already running we can miss some events. Let's rearm
+* the timer and try again.
+*/
+ if (likely(napi_schedule_prep(&ch->tx_napi)))
+ __napi_schedule(&ch->tx_napi);
+ else
+ mod_timer(&tx_q->txtimer, STMMAC_COAL_TIMER(10));
}
/**
@@ -3498,7 +3506,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit,
u32 queue)
else
skb->ip_summed = CHECKSUM_UNNECESSARY;
- napi_gro_receive(&ch->napi, skb);
+
Re: [PATCH 2/5] nvmem: sunxi-sid: add support for H5's SID controller
On Sun, Feb 17, 2019 at 11:23:13AM -0500, Yangtao Li wrote:
> Add support for H5's SID controller.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/nvmem/sunxi_sid.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
> index 570a2e354f30..036029e90921 100644
> --- a/drivers/nvmem/sunxi_sid.c
> +++ b/drivers/nvmem/sunxi_sid.c
> @@ -219,11 +219,17 @@ static const struct sunxi_sid_cfg sun50i_a64_cfg = {
> .size = 0x100,
> };
>
> +static const struct sunxi_sid_cfg sun50i_h5_cfg = {
> + .value_offset = 0x200,
> + .size = 0x100,
> +};
IIRC, there was an endianness issue on the newer SoCs, with the driver
converting the data from big endian to little endian, while it's
actually stored little endian in the SID.
Have you checked the SID content?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
[PATCH net-next v2 3/3] net: stmmac: dwxgmac2: Also use TBU interrupt to clean TX path
TBU interrupt is a normal interrupt and can be used to trigger the
cleaning of TX path. Lets check if it's active in DMA interrupt handler.
While at it, refactor a little bit the function:
- Don't check if RI is enabled because at function exit we will
only clear the interrupts that are enabled so, no event will
be missed.
In my tests withe XGMAC2 this increased performance.
Signed-off-by: Jose Abreu
Cc: Joao Pinto
Cc: David S. Miller
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 4 +++-
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 8 +++-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index d6bb953685fa..37d5e6fe7473 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -193,9 +193,10 @@
#define XGMAC_AIE BIT(14)
#define XGMAC_RBUE BIT(7)
#define XGMAC_RIE BIT(6)
+#define XGMAC_TBUE BIT(2)
#define XGMAC_TIE BIT(0)
#define XGMAC_DMA_INT_DEFAULT_EN (XGMAC_NIE | XGMAC_AIE | XGMAC_RBUE | \
- XGMAC_RIE | XGMAC_TIE)
+ XGMAC_RIE | XGMAC_TBUE | XGMAC_TIE)
#define XGMAC_DMA_CH_Rx_WATCHDOG(x)(0x313c + (0x80 * (x)))
#define XGMAC_RWT GENMASK(7, 0)
#define XGMAC_DMA_CH_STATUS(x) (0x3160 + (0x80 * (x)))
@@ -204,6 +205,7 @@
#define XGMAC_FBE BIT(12)
#define XGMAC_RBU BIT(7)
#define XGMAC_RI BIT(6)
+#define XGMAC_TBU BIT(2)
#define XGMAC_TPS BIT(1)
#define XGMAC_TI BIT(0)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index c5e25580a43f..2ba712b48a89 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -283,12 +283,10 @@ static int dwxgmac2_dma_interrupt(void __iomem *ioaddr,
x->normal_irq_n++;
if (likely(intr_status & XGMAC_RI)) {
- if (likely(intr_en & XGMAC_RIE)) {
- x->rx_normal_irq_n++;
- ret |= handle_rx;
- }
+ x->rx_normal_irq_n++;
+ ret |= handle_rx;
}
- if (likely(intr_status & XGMAC_TI)) {
+ if (likely(intr_status & (XGMAC_TI | XGMAC_TBU))) {
x->tx_normal_irq_n++;
ret |= handle_tx;
}
--
2.7.4
[PATCH net-next v2 0/3] net: stmmac: Performance improvements in Multi-Queue
Tested in XGMAC2 and GMAC5. Cc: Florian Fainelli Cc: Joao Pinto Cc: David S. Miller Cc: Giuseppe Cavallaro Cc: Alexandre Torgue Jose Abreu (3): net: stmmac: Fix NAPI poll in TX path when in multi-queue net: stmmac: dwmac4: Also use TBU interrupt to clean TX path net: stmmac: dwxgmac2: Also use TBU interrupt to clean TX path drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c | 24 ++--- drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 4 +- drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 8 +- drivers/net/ethernet/stmicro/stmmac/stmmac.h | 5 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 114 - 5 files changed, 79 insertions(+), 76 deletions(-) -- 2.7.4
Re: [PATCH 5/5] nvmem: sunxi-sid: convert to SPDX license tags
On Sun, Feb 17, 2019 at 11:23:16AM -0500, Yangtao Li wrote: > Updates license to use SPDX-License-Identifier. > > Signed-off-by: Yangtao Li Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
[PATCH net-next v2 2/3] net: stmmac: dwmac4: Also use TBU interrupt to clean TX path
TBU interrupt is a normal interrupt and can be used to trigger the
cleaning of TX path. Lets check if it's active in DMA interrupt handler.
While at it, refactor a little bit the function:
- Don't check if RI is enabled because at function exit we will
only clear the interrupts that are enabled so, no event will be
missed.
In my tests with GMAC5 this increased performance.
Signed-off-by: Jose Abreu
Cc: Joao Pinto
Cc: David S. Miller
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
index 49f5687879df..545cb9c47433 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
@@ -124,9 +124,9 @@ void dwmac4_disable_dma_irq(void __iomem *ioaddr, u32 chan)
int dwmac4_dma_interrupt(void __iomem *ioaddr,
struct stmmac_extra_stats *x, u32 chan)
{
- int ret = 0;
-
u32 intr_status = readl(ioaddr + DMA_CHAN_STATUS(chan));
+ u32 intr_en = readl(ioaddr + DMA_CHAN_INTR_ENA(chan));
+ int ret = 0;
/* ABNORMAL interrupts */
if (unlikely(intr_status & DMA_CHAN_STATUS_AIS)) {
@@ -151,16 +151,11 @@ int dwmac4_dma_interrupt(void __iomem *ioaddr,
if (likely(intr_status & DMA_CHAN_STATUS_NIS)) {
x->normal_irq_n++;
if (likely(intr_status & DMA_CHAN_STATUS_RI)) {
- u32 value;
-
- value = readl(ioaddr + DMA_CHAN_INTR_ENA(chan));
- /* to schedule NAPI on real RIE event. */
- if (likely(value & DMA_CHAN_INTR_ENA_RIE)) {
- x->rx_normal_irq_n++;
- ret |= handle_rx;
- }
+ x->rx_normal_irq_n++;
+ ret |= handle_rx;
}
- if (likely(intr_status & DMA_CHAN_STATUS_TI)) {
+ if (likely(intr_status & (DMA_CHAN_STATUS_TI |
+ DMA_CHAN_STATUS_TBU))) {
x->tx_normal_irq_n++;
ret |= handle_tx;
}
@@ -168,12 +163,7 @@ int dwmac4_dma_interrupt(void __iomem *ioaddr,
x->rx_early_irq++;
}
- /* Clear the interrupt by writing a logic 1 to the chanX interrupt
-* status [21-0] expect reserved bits [5-3]
-*/
- writel((intr_status & 0x3fffc7),
- ioaddr + DMA_CHAN_STATUS(chan));
-
+ writel(intr_status & intr_en, ioaddr + DMA_CHAN_STATUS(chan));
return ret;
}
--
2.7.4
Re: [PATCH v3 0/9] device connection: Add support for device graphs
On Mon, Feb 18, 2019 at 09:07:27AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 15, 2019 at 02:47:15PM +0200, Heikki Krogerus wrote:
> > Hi Greg,
> >
> > On Thu, Feb 14, 2019 at 11:10:44AM +0100, Greg Kroah-Hartman wrote:
> > > On Wed, Feb 13, 2019 at 10:45:48AM +0300, Heikki Krogerus wrote:
> > > > Hi,
> > > >
> > > > This is the third version of my proposal to add device graph parsing
> > > > to the device connection API. There was only one problem reported in
> > > > v2 by Jun - kernel-doc entry was missing for the new fwnode member in
> > > > struct usb_role_switch_desc - and it's now fixed.
> > > >
> > > > The second version of the series:
> > > > https://lkml.org/lkml/2019/1/30/622
> > > >
> > > > The commit message from v1:
> > > >
> > > > This series adds support for OF and ACPI device graph parsing to the
> > > > device connection API.
> > > >
> > > > Handling the graph is straightforward, but because I'm adding that
> > > > fwnode member to struct device_connection, I had to make sure all the
> > > > existing users consider it.
> > > >
> > > > The plan is to only support matching with fwnode in the future, so no
> > > > more device name matching. The software fwnodes that we now have in
> > > > kernel should make that possible, once we add support for references
> > > > to them.
> > > >
> > > > The original RFC:
> > > > https://lkml.org/lkml/2018/10/24/619
> > >
> > > All now merged, thanks.
> >
> > It looks like you have not followed the order of the patches in this
> > series.
> >
> > You applied at least the patch 4/9 ("device connection: Add fwnode
> > member to struct device_connection") as the last patch to your
> > usb-next branch. The rest of the series, patches starting from 5/9,
> > depend on that patch.
>
> Ugh, did I just apply them out of order? I can't rewrite my tree now,
> sorry about that, odd that my sorting didn't work.
>
> I think all of the patches are now in the tree, so I didn't miss
> anything, is there anything I can do now? Want me to revert them and
> then add them back in the correct order?
The problem is with bisecting, so I'm not sure if reverting helps. I
don't think there's anything else that can be done about this now.
thanks,
--
heikki
Re: [PATCH v4 0/8] Support Trusted Foundations firmware on Tegra30
On Mon, Feb 18, 2019 at 03:17:18AM +0300, Dmitry Osipenko wrote: > Hello, > > This patchset adds support for the Trusted Foundations firmware on > NVIDIA Tegra30. Pretty much all of Tegra30 consumer devices have that > firmware and upstream kernel can't boot on those devices without the > firmware support. > > Changelog: > > v4: - Fixed Thumb2-kernel hanging on Tegra20, turned out it was not a > good idea to switch CPU into Thumb2 mode right after jumping into > the reset handler. > > - Moved LP2-mode-set firmware call invocation to a later stage to > better replicate what downstream kernel does. This change was > suggested by Robert Yang and fixes system hang on Ouya game > console. > > - Added references to the original work made by Michał Mirosław > into commit messages of the relevant patches. > > v3: - Implemented suspend-resume support. > > - Reworked arm/firmware/trusted_foundations.c a tad. Now cache > is getting properly initialized, cache enabling / disabling is > supported. > > v2: > - The "Don't apply CPU erratas in insecure mode" patch got some > cleanup, in particular resolved the messiness in > __tegra_cpu_reset_handler_data. > > - Added a comment to tf_cache_write_sec(), justifying the warning > message. > > Dmitry Osipenko (8): > ARM: trusted_foundations: Implement L2 cache initialization callback > ARM: trusted_foundations: Make prepare_idle call to take mode argument > ARM: trusted_foundations: Provide information about whether firmware > is registered > ARM: tegra: Set up L2 cache using Trusted Foundations firmware > ARM: tegra: Don't apply CPU erratas in insecure mode > ARM: tegra: Always boot CPU in ARM-mode > ARM: tegra: Support L2 cache maintenance done via firmware > ARM: tegra: Add firmware calls required for suspend-resume > > arch/arm/firmware/trusted_foundations.c| 80 +- > arch/arm/include/asm/firmware.h| 2 +- > arch/arm/include/asm/trusted_foundations.h | 13 > arch/arm/mach-tegra/cpuidle-tegra114.c | 3 +- > arch/arm/mach-tegra/pm.c | 50 ++ > arch/arm/mach-tegra/reset-handler.S| 52 ++ > arch/arm/mach-tegra/reset.c| 3 + > arch/arm/mach-tegra/reset.h| 9 ++- > arch/arm/mach-tegra/sleep-tegra20.S| 4 ++ > arch/arm/mach-tegra/sleep.S| 11 +-- > arch/arm/mach-tegra/tegra.c| 10 +++ > 11 files changed, 214 insertions(+), 23 deletions(-) Hi Russell, I'm not sure if this is something that you have a vested interest in. It looks like Tegra is the only platform that uses this, and usage is limited to two generations (Tegra30 and Tegra114). Do you mind if I pick this up into the Tegra tree and send this as part of the pull requests for v5.2? Actually, Trusted Foundations is the only firmware implementation left in arch/arm/firmware, so how about we move this file over to drivers/firmware (perhaps even the tegra subdirectory given that nobody else seems to be using it) and get rid of arch/arm/firmware? I can prepare a patch that does that on top of this series, just let me know how you want to handle this. Thanks, Thierry signature.asc Description: PGP signature
[PATCH] drivers/component: kerneldoc polish
Polish the kerneldoc a bit with suggestions from Randy. Cc: Randy Dunlap Signed-off-by: Daniel Vetter Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Daniel Vetter Cc: Ramalingam C -- Greg, I don't need this in any of the topic branches, best if you pick this one up into your -next tree directly. Cheers, Daniel --- drivers/base/component.c | 14 +++--- include/linux/component.h | 2 +- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/base/component.c b/drivers/base/component.c index 7dbc41cccd58..6954e448f46b 100644 --- a/drivers/base/component.c +++ b/drivers/base/component.c @@ -27,7 +27,7 @@ * helper fills the niche of aggregate drivers for specific hardware, where * further standardization into a subsystem would not be practical. The common * example is when a logical device (e.g. a DRM display driver) is spread around - * the SoC on various component (scanout engines, blending blocks, transcoders + * the SoC on various components (scanout engines, blending blocks, transcoders * for various outputs and so on). * * The component helper also doesn't solve runtime dependencies, e.g. for system @@ -378,7 +378,7 @@ static void __component_match_add(struct device *master, } /** - * component_match_add_release - add a component match with release callback + * component_match_add_release - add a component match entry with release callback * @master: device with the aggregate driver * @matchptr: pointer to the list of component matches * @release: release function for @compare_data @@ -408,7 +408,7 @@ void component_match_add_release(struct device *master, EXPORT_SYMBOL(component_match_add_release); /** - * component_match_add_typed - add a compent match for a typed component + * component_match_add_typed - add a compent match entry for a typed component * @master: device with the aggregate driver * @matchptr: pointer to the list of component matches * @compare_typed: compare function to match against all typed components @@ -537,11 +537,11 @@ static void component_unbind(struct component *component, } /** - * component_unbind_all - unbind all component to an aggregate driver + * component_unbind_all - unbind all components of an aggregate driver * @master_dev: device with the aggregate driver * @data: opaque pointer, passed to all components * - * Unbinds all components to the aggregate @dev by passing @data to their + * Unbinds all components of the aggregate @dev by passing @data to their * &component_ops.unbind functions. Should be called from * &component_master_ops.unbind. */ @@ -619,11 +619,11 @@ static int component_bind(struct component *component, struct master *master, } /** - * component_bind_all - bind all component to an aggregate driver + * component_bind_all - bind all components of an aggregate driver * @master_dev: device with the aggregate driver * @data: opaque pointer, passed to all components * - * Binds all components to the aggregate @dev by passing @data to their + * Binds all components of the aggregate @dev by passing @data to their * &component_ops.bind functions. Should be called from * &component_master_ops.bind. */ diff --git a/include/linux/component.h b/include/linux/component.h index 30bcc7e590eb..8628d4d0aff1 100644 --- a/include/linux/component.h +++ b/include/linux/component.h @@ -98,7 +98,7 @@ void component_match_add_typed(struct device *master, int (*compare_typed)(struct device *, int, void *), void *compare_data); /** - * component_match_add - add a compent match + * component_match_add - add a compent match entry * @master: device with the aggregate driver * @matchptr: pointer to the list of component matches * @compare: compare function to match against all components -- 2.20.1
RE: [PATCH] ARC: Explicitly set ARCH_SLAB_MINALIGN = 8
Hi Vineet,
> -Original Message-
> From: Vineet Gupta
> Sent: Friday, February 15, 2019 4:34 AM
> To: Alexey Brodkin ; Peter Zijlstra
>
> Cc: David Laight ;
> linux-snps-...@lists.infradead.org; Arnd Bergmann
> ; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org; Mark Rutland
>
> Subject: Re: [PATCH] ARC: Explicitly set ARCH_SLAB_MINALIGN = 8
>
> On 2/14/19 12:50 AM, Alexey Brodkin wrote:
>
> > I suspect the slab allocator should be returning 8 byte aligned
> > addresses
> > on all systems
>
> why ? As I understand it is still not fool proof against the expected
> alignment of
> inner members. There ought to be a better way to enforce all this.
> >>>
> >>> I agree that for ARC ARCH_SLAB_MINALIGN should be at least 8.
> >>
> >> This issue aside, are there other reasons ? Because making it 8 on ARC is
> >> just
> >> pending the eventuality for later.
> >
> > But that's pretty much the same for other 32-bit arches that have 64-bit
> > atomics
> > like ARM etc. From what I may see from ARM's documentation for
> > LDREXD/SRREXD they
> > require double-word alignment of data as well.
>
> Right LLOCKD/SCONDD (64-bit exclusive load/store) needs 64-bit aligned
> effective
> addresses for micro-arch reasons (1 vs 2 cache lines) etc.
>
> So lets try to unpack this for me. Say we had.
>
>struct foo {
> inta;
> atomic64_t b;
>};
>
> The atomic64_t (which for ARC and most others is u64
> __attribute__((aligned(8))
> *already ensures* that there a 4 b padding is generated by gcc (I just
> confirmed
> with a simple test case).
>
>#ifdef DOALIGN__
>#define my_u64 __u64 __attribute__((aligned(8)))
>#else
>#define my_u64 __u64
>#endif
>
> struct foo on_heap;
>
> printf(%d", &on_heap.b)
>
> $ arc-linux-gcc -O2 test.c -DDOALIGN__ -c --save-temps
>
>main:
> mov_s r1,@on_heap+8 <
> mov_s r0,@.LC0
> b @printf
>
> W/o the alignment attribute (say normal LDD/STD)
>
> $ arc-linux-gcc -O2 test.c -c --save-temps
>
>main:
> mov_s r1,@on_heap+4
> mov_s r0,@.LC0
> b @printf
>
> So indeed your patch aligns dynamic structs to 64-bit, ensuring any embedded
> aligned_u64 to be 64-bit aligned as well. Phew !
>
>
> > That said if for some reason atomic64_t variable is unaligned execution on
> > any (or at least most) 32-bit architectures will lead to run-time failure,
> > i.e. we'll know about it and this will be fixed.
> >
> > And what I'm doing by that change (ARCH_SLAB_MINALIGN=8 for ARC) I'm just
> > working-around peculiarity of ARC ABI.
>
> Right.
So are you OK with this patch or something should be done before applying?
> >
> > Out of curiosity I checked if there're any other occurrences of
> > "alingof(long long)"
> > and there seems to be a couple of more:
> > --->8-
> > # git grep alignof | grep "long long"
> >
> > ...
> >
> > kernel/workqueue.c:5693:WARN_ON(__alignof__(struct pool_workqueue)
> > < __alignof__(long
> long));
> > mm/slab.c:155:#define REDZONE_ALIGN max(BYTES_PER_WORD,
> > __alignof__(unsigned long long))
>
> For ARC, it will be max(4,4) so 4
> for others 32-bit,it will be max(4,8)
>
> So indeed it makes sense to change it.
I guess that's still a separate change for generic code, right?
I.e. I'll do it in a separate patch.
-Alexey
Re: [LKP] efad4e475c [ 40.308255] Oops: 0000 [#1] PREEMPT SMP PTI
[Sorry for an excessive quoting in the previous email]
[Cc Pavel - the full report is
http://lkml.kernel.org/r/20190218052823.GH29177@shao2-debian[]
On Mon 18-02-19 08:08:44, Michal Hocko wrote:
> On Mon 18-02-19 13:28:23, kernel test robot wrote:
[...]
> > [ 40.305212] PGD 0 P4D 0
> > [ 40.308255] Oops: [#1] PREEMPT SMP PTI
> > [ 40.313055] CPU: 1 PID: 239 Comm: udevd Not tainted
> > 5.0.0-rc4-00149-gefad4e4 #1
> > [ 40.321348] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > 1.10.2-1 04/01/2014
> > [ 40.330813] RIP: 0010:page_mapping+0x12/0x80
> > [ 40.335709] Code: 5d c3 48 89 df e8 0e ad 02 00 85 c0 75 da 89 e8 5b 5d
> > c3 0f 1f 44 00 00 53 48 89 fb 48 8b 43 08 48 8d 50 ff a8 01 48 0f 45 da
> > <48> 8b 53 08 48 8d 42 ff 83 e2 01 48 0f 44 c3 48 83 38 ff 74 2f 48
> > [ 40.356704] RSP: 0018:88801fa87cd8 EFLAGS: 00010202
> > [ 40.362714] RAX: RBX: fffe RCX:
> > 000a
> > [ 40.370798] RDX: fffe RSI: 820b9a20 RDI:
> > 88801e5c
> > [ 40.378830] RBP: 6db6db6db6db6db7 R08: 88801e8bb000 R09:
> > 01b64d13
> > [ 40.386902] R10: 88801fa87cf8 R11: 0001 R12:
> > 88801e64
> > [ 40.395033] R13: 820b9a20 R14: 88801f145258 R15:
> > 0001
> > [ 40.403138] FS: 7fb2079817c0() GS:88801dd0()
> > knlGS:
> > [ 40.412243] CS: 0010 DS: ES: CR0: 80050033
> > [ 40.418846] CR2: 0006 CR3: 1fa82000 CR4:
> > 06a0
> > [ 40.426951] Call Trace:
> > [ 40.429843] __dump_page+0x14/0x2c0
> > [ 40.433947] is_mem_section_removable+0x24c/0x2c0
>
> This looks like we are stumbling over an unitialized struct page again.
> Something this patch should prevent from. Could you try to apply [1]
> which will make __dump_page more robust so that we do not blow up there
> and give some more details in return.
>
> Btw. is this reproducible all the time?
And forgot to ask whether this is reproducible with pending mmotm
patches in linux-next.
> I will have a look at the memory layout later today.
[0.059335] No NUMA configuration found
[0.059345] Faking a node at [mem 0x-0x1ffd]
[0.059399] NODE_DATA(0) allocated [mem 0x1e8c3000-0x1e8c5fff]
[0.073143] Zone ranges:
[0.073175] DMA32[mem 0x1000-0x1ffd]
[0.073204] Normal empty
[0.073212] Movable zone start for each node
[0.073240] Early memory node ranges
[0.073247] node 0: [mem 0x1000-0x0009efff]
[0.073275] node 0: [mem 0x0010-0x1ffd]
[0.073309] Zeroed struct page in unavailable ranges: 98 pages
[0.073312] Initmem setup node 0 [mem 0x1000-0x1ffd]
[0.073343] On node 0 totalpages: 130942
[0.073373] DMA32 zone: 1792 pages used for memmap
[0.073400] DMA32 zone: 21 pages reserved
[0.073408] DMA32 zone: 130942 pages, LIFO batch:31
We have only a single NUMA node with a single ZONE_DMA32. But there is a
hole in the zone and the first range before the hole is not section
aligned. We do zero some unavailable ranges but from the number it is no
clear which range it is and 98. [0x60fff, 0xf) is 96 pages. The
patch below should tell us whether we are covering all we need. If yes
then the hole shouldn't make any difference and the problem must be
somewhere else.
---
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 35fdde041f5c..c60642505e04 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6706,10 +6706,13 @@ void __init zero_resv_unavail(void)
pgcnt = 0;
for_each_mem_range(i, &memblock.memory, NULL,
NUMA_NO_NODE, MEMBLOCK_NONE, &start, &end, NULL) {
- if (next < start)
+ if (next < start) {
+ pr_info("zeroying %llx-%llx\n", PFN_DOWN(next),
PFN_UP(start));
pgcnt += zero_pfn_range(PFN_DOWN(next), PFN_UP(start));
+ }
next = end;
}
+ pr_info("zeroying %llx-%lx\n", PFN_DOWN(next), max_pfn);
pgcnt += zero_pfn_range(PFN_DOWN(next), max_pfn);
/*
--
Michal Hocko
SUSE Labs
Re: [PATCH] drm/drm_vm: Mark expected switch fall-throughs
On Fri, Feb 15, 2019 at 11:05:46AM -0600, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch > cases where we are expecting to fall through. > > Warning level 3 was used: -Wimplicit-fallthrough=3 > > Notice that, in this particular case, the code comment is modified > in accordance with what GCC is expecting to find. > > This patch is part of the ongoing efforts to enable > -Wimplicit-fallthrough. > > Signed-off-by: Gustavo A. R. Silva Queued for 5.2, thanks for your patch. -Daniel > --- > drivers/gpu/drm/drm_vm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c > index c3301046dfaa..8987501f53b2 100644 > --- a/drivers/gpu/drm/drm_vm.c > +++ b/drivers/gpu/drm/drm_vm.c > @@ -584,8 +584,8 @@ static int drm_mmap_locked(struct file *filp, struct > vm_area_struct *vma) > vma->vm_ops = &drm_vm_ops; > break; > } > - /* fall through to _DRM_FRAME_BUFFER... */ > #endif > + /* fall through - to _DRM_FRAME_BUFFER... */ > case _DRM_FRAME_BUFFER: > case _DRM_REGISTERS: > offset = drm_core_get_reg_ofs(dev); > @@ -610,7 +610,7 @@ static int drm_mmap_locked(struct file *filp, struct > vm_area_struct *vma) > vma->vm_end - vma->vm_start, vma->vm_page_prot)) > return -EAGAIN; > vma->vm_page_prot = drm_dma_prot(map->type, vma); > - /* fall through to _DRM_SHM */ > + /* fall through - to _DRM_SHM */ > case _DRM_SHM: > vma->vm_ops = &drm_vm_shm_ops; > vma->vm_private_data = (void *)map; > -- > 2.20.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v3 0/3] admin-guide: extend perf-security with resource control, data categories and privileged users
On 18.02.2019 2:14, Jonathan Corbet wrote: > On Mon, 11 Feb 2019 16:32:33 +0300 > Alexey Budankov wrote: > >> The patch set extends the first version of perf-security.rst documentation >> file [1], [2], [3] with the following topics: >> >> 1) perf_events/Perf resource limits and control management that describes >>RLIMIT_NOFILE and perf_event_mlock_kb settings for processes conducting >>performance monitoring; >> >> 2) categories of system and performance data that can be captured by >>perf_events/Perf with explicit designation of process sensitive data; >> >> 3) possible steps to create perf_event/Perf privileged users groups for >>the current implementations of perf_events syscall API [4] and Perf tool; > > I've applied the set, thanks. Thanks a lot Jon! ~Alexey > > jon >
Re: [RFC 2/6] mfd: Support for Ettus Research E31x devices PMU
On Sun, 17 Feb 2019, Moritz Fischer wrote: > On Thu, Feb 14, 2019 at 1:34 AM Lee Jones wrote: > > On Mon, 11 Feb 2019, Virendra Kakade wrote: > > > > > Signed-off-by: Virendra Kakade > > > --- > > > drivers/mfd/Kconfig | 7 +++ > > > drivers/mfd/Makefile | 2 +- > > > drivers/mfd/e31x-pmu.c | 89 > > > include/linux/mfd/e31x-pmu.h | 20 > > > 4 files changed, 117 insertions(+), 1 deletion(-) > > > create mode 100644 drivers/mfd/e31x-pmu.c > > > create mode 100644 include/linux/mfd/e31x-pmu.h [...] Try not to quote too many unnecessary lines when replying please. > > So the whole purpose of this driver is to do a version check. > > > > Seems like over-kill! > > > > Probably better to do the version check in an inline function stored > > in a header file, then call it from each of the children's .probe() > > function. > > A bit of context here, this is based on an in-house driver that we had that > does > a bunch of other stuff (e.g. it controls a flag on whether the device > auto-boots > on power being plugged in etc.). These functions will use the regmap. > > I had advised Virendra to submit a base version and follow up with patches > that would add these functions one by one as he figures out how to expose them > in a proper way to the kernel. Probably best to wait until you have something a little more featureful before attempting to upstream then. I couldn't tell you how many times I've had contributors tell me that they plan to follow up with additional patches and (for their own perfectly decent reasons I'm sure) fail to do so. As it stands, this driver over-kill for what you're trying to achieve and therefore isn't overly suitable for upstreaming at the moment. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH V6 2/7] clocksource: tegra: add Tegra210 timer support
On 2/15/19 11:14 PM, Daniel Lezcano wrote:
On 01/02/2019 17:16, Joseph Lo wrote:
Add support for the Tegra210 timer that runs at oscillator clock
(TMR10-TMR13). We need these timers to work as clock event device and to
replace the ARMv8 architected timer due to it can't survive across the
power cycle of the CPU core or CPUPORESET signal. So it can't be a wake-up
source when CPU suspends in power down state.
Also convert the original driver to use timer-of API.
Cc: Daniel Lezcano
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Joseph Lo
Acked-by: Thierry Reding
Acked-by: Jon Hunter
---
v6:
* refine the timer defines
* add ack tag from Jon.
v5:
* add ack tag from Thierry
v4:
* merge timer-tegra210.c in previous version into timer-tegra20.c
v3:
* use timer-of API
v2:
* add error clean-up code
---
drivers/clocksource/Kconfig | 2 +-
drivers/clocksource/timer-tegra20.c | 371
include/linux/cpuhotplug.h | 1 +
3 files changed, 270 insertions(+), 104 deletions(-)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a9e26f6a81a1..6af78534a285 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -131,7 +131,7 @@ config SUN5I_HSTIMER
config TEGRA_TIMER
bool "Tegra timer driver" if COMPILE_TEST
select CLKSRC_MMIO
- depends on ARM
This will break because the delay functions are defined in
arch/arm/include/asm/delay.h and the 01.org will try to compile the
driver on x86.
You may want to add 'depends on ARM && ARM64'
OK, I think it's 'depends on ARM || ARM64'.
Will fix.
+ select TIMER_OF
help
Enables support for the Tegra driver.
[snip]
-
static struct timespec64 persistent_ts;
static u64 persistent_ms, last_persistent_ms;
Did you check the above changes are still relevant after commit
39232ed5a1793f67 and after doing a change similar to
commit 1569557549697207e523 ?
Yes, just check both commits. I think it's okay to use the same. But
need another patch to do that, this patch only adds new support for
Tegra210. Doesn't touch the original code.
static struct delay_timer tegra_delay_timer;
[snip]
+#ifdef CONFIG_ARM64
+static DEFINE_PER_CPU(struct timer_of, tegra_to) = {
+ .flags = TIMER_OF_CLOCK | TIMER_OF_BASE,
+
+ .clkevt = {
+ .name = "tegra_timer",
+ .rating = 460,
+ .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
CLOCK_EVT_FEAT_DYNIRQ ?
Yes, good catch.
+ .set_next_event = tegra_timer_set_next_event,
+ .set_state_shutdown = tegra_timer_shutdown,
+ .set_state_periodic = tegra_timer_set_periodic,
+ .set_state_oneshot = tegra_timer_shutdown,
+ .tick_resume = tegra_timer_shutdown,
+ },
+};
[snip]
-static unsigned long tegra_delay_timer_read_counter_long(void)
+static int tegra_timer_suspend(void)
{
- return readl(timer_reg_base + TIMERUS_CNTR_1US);
+#ifdef CONFIG_ARM64
Please do not add those #ifdef but function stubs.
+ int cpu;
+
+ for_each_possible_cpu(cpu) {
+ struct timer_of *to = per_cpu_ptr(&tegra_to, cpu);
+ void __iomem *reg_base = timer_of_base(to);
+
+ writel(TIMER_PCR_INTR_CLR, reg_base + TIMER_PCR);
+ }
+#else
+ void __iomem *reg_base = timer_of_base(&tegra_to);
+
+ writel(TIMER_PCR_INTR_CLR, reg_base + TIMER_PCR);
+#endif
+
+ return 0;
}
-static irqreturn_t tegra_timer_interrupt(int irq, void *dev_id)
+static void tegra_timer_resume(void)
{
- struct clock_event_device *evt = (struct clock_event_device *)dev_id;
- timer_writel(1<<30, TIMER3_BASE + TIMER_PCR);
- evt->event_handler(evt);
- return IRQ_HANDLED;
+ writel(usec_config, timer_reg_base + TIMERUS_USEC_CFG);
}
-static struct irqaction tegra_timer_irq = {
- .name = "timer0",
- .flags = IRQF_TIMER | IRQF_TRIGGER_HIGH,
- .handler= tegra_timer_interrupt,
- .dev_id = &tegra_clockevent,
+static struct syscore_ops tegra_timer_syscore_ops = {
+ .suspend = tegra_timer_suspend,
+ .resume = tegra_timer_resume,
};
It will be nicer to use the suspend/resume callbacks defined in the
clockevent structure, so you can use generic as there are multiple
clockevents defined for the tegra210, thus multiple timer-of
encapsulating them. When the suspend/resume callbacks are called, they
have the clock_event pointer and you can use it to retrieve the timer-of
and then the base address. At the end, the callbacks will end up the
same for tegra20 and tegra210.
Very good suggestion, will follow up.
-static int __init tegra20_init_timer(struct device_node *np)
+static int tegra_timer_init(struct device_node *np, struct timer_of *to)
[snip]
+ for_each_possible_cpu(cpu
Re: [LKP] efad4e475c [ 40.308255] Oops: 0000 [#1] PREEMPT SMP PTI
On Mon 18-02-19 16:47:26, Rong Chen wrote: > > On 2/18/19 3:08 PM, Michal Hocko wrote: > > On Mon 18-02-19 13:28:23, kernel test robot wrote: [...] > > > [ 40.305212] PGD 0 P4D 0 > > > [ 40.308255] Oops: [#1] PREEMPT SMP PTI > > > [ 40.313055] CPU: 1 PID: 239 Comm: udevd Not tainted > > > 5.0.0-rc4-00149-gefad4e4 #1 > > > [ 40.321348] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > > > BIOS 1.10.2-1 04/01/2014 > > > [ 40.330813] RIP: 0010:page_mapping+0x12/0x80 > > > [ 40.335709] Code: 5d c3 48 89 df e8 0e ad 02 00 85 c0 75 da 89 e8 5b > > > 5d c3 0f 1f 44 00 00 53 48 89 fb 48 8b 43 08 48 8d 50 ff a8 01 48 0f 45 > > > da <48> 8b 53 08 48 8d 42 ff 83 e2 01 48 0f 44 c3 48 83 38 ff 74 2f 48 > > > [ 40.356704] RSP: 0018:88801fa87cd8 EFLAGS: 00010202 > > > [ 40.362714] RAX: RBX: fffe RCX: > > > 000a > > > [ 40.370798] RDX: fffe RSI: 820b9a20 RDI: > > > 88801e5c > > > [ 40.378830] RBP: 6db6db6db6db6db7 R08: 88801e8bb000 R09: > > > 01b64d13 > > > [ 40.386902] R10: 88801fa87cf8 R11: 0001 R12: > > > 88801e64 > > > [ 40.395033] R13: 820b9a20 R14: 88801f145258 R15: > > > 0001 > > > [ 40.403138] FS: 7fb2079817c0() GS:88801dd0() > > > knlGS: > > > [ 40.412243] CS: 0010 DS: ES: CR0: 80050033 > > > [ 40.418846] CR2: 0006 CR3: 1fa82000 CR4: > > > 06a0 > > > [ 40.426951] Call Trace: > > > [ 40.429843] __dump_page+0x14/0x2c0 > > > [ 40.433947] is_mem_section_removable+0x24c/0x2c0 > > This looks like we are stumbling over an unitialized struct page again. > > Something this patch should prevent from. Could you try to apply [1] > > which will make __dump_page more robust so that we do not blow up there > > and give some more details in return. > > > Hi Hocko, > > I have applied [1] and attached the dmesg file. Thanks so the log confirms that this is really an unitialized struct page [ 12.228622] raw: [ 12.231474] page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) [ 12.232135] [ cut here ] [ 12.232649] kernel BUG at include/linux/mm.h:1020! So now, we have to find out what has been left behind. Please see my other email. Also could you give me faddr2line of the is_mem_section_removable offset please? I assume it is is_pageblock_removable_nolock: if (!node_online(page_to_nid(page))) return false; -- Michal Hocko SUSE Labs
[PATCH v2] sched/x86: Save [ER]FLAGS on context switch
Subject: sched/x86: Save [ER]FLAGS on context switch
From: Peter Zijlstra
Date: Thu Feb 14 10:30:52 CET 2019
Effectively reverts commit:
2c7577a75837 ("sched/x86_64: Don't save flags on context switch")
Specifically because SMAP uses FLAGS.AC which invalidates the claim
that the kernel has clean flags.
In particular; while preemption from interrupt return is fine (the
IRET frame on the exception stack contains FLAGS) it breaks any code
that does synchonous scheduling, including preempt_enable().
This has become a significant issue ever since commit:
5b24a7a2aa20 ("Add 'unsafe' user access functions for batched accesses")
provided for means of having 'normal' C code between STAC / CLAC,
exposing the FLAGS.AC state. So far this hasn't led to trouble,
however fix it before it comes apart.
Fixes: 5b24a7a2aa20 ("Add 'unsafe' user access functions for batched accesses")
Acked-by: Andy Lutomirski
Reported-by: Julien Thierry
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/entry/entry_32.S|2 ++
arch/x86/entry/entry_64.S|2 ++
arch/x86/include/asm/switch_to.h |1 +
arch/x86/kernel/process_32.c |7 +++
arch/x86/kernel/process_64.c |8
5 files changed, 20 insertions(+)
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -650,6 +650,7 @@ ENTRY(__switch_to_asm)
pushl %ebx
pushl %edi
pushl %esi
+ pushfl
/* switch stack */
movl%esp, TASK_threadsp(%eax)
@@ -672,6 +673,7 @@ ENTRY(__switch_to_asm)
#endif
/* restore callee-saved registers */
+ popfl
popl%esi
popl%edi
popl%ebx
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -291,6 +291,7 @@ ENTRY(__switch_to_asm)
pushq %r13
pushq %r14
pushq %r15
+ pushfq
/* switch stack */
movq%rsp, TASK_threadsp(%rdi)
@@ -313,6 +314,7 @@ ENTRY(__switch_to_asm)
#endif
/* restore callee-saved registers */
+ popfq
popq%r15
popq%r14
popq%r13
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -40,6 +40,7 @@ asmlinkage void ret_from_fork(void);
* order of the fields must match the code in __switch_to_asm().
*/
struct inactive_task_frame {
+ unsigned long flags;
#ifdef CONFIG_X86_64
unsigned long r15;
unsigned long r14;
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -127,6 +127,13 @@ int copy_thread_tls(unsigned long clone_
struct task_struct *tsk;
int err;
+ /*
+* For a new task use the RESET flags value since there is no before.
+* All the status flags are zero; DF and all the system flags must also
+* be 0, specifically IF must be 0 because we context switch to the new
+* task with interrupts disabled.
+*/
+ frame->flags = X86_EFLAGS_FIXED;
frame->bp = 0;
frame->ret_addr = (unsigned long) ret_from_fork;
p->thread.sp = (unsigned long) fork_frame;
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -392,6 +392,14 @@ int copy_thread_tls(unsigned long clone_
childregs = task_pt_regs(p);
fork_frame = container_of(childregs, struct fork_frame, regs);
frame = &fork_frame->frame;
+
+ /*
+* For a new task use the RESET flags value since there is no before.
+* All the status flags are zero; DF and all the system flags must also
+* be 0, specifically IF must be 0 because we context switch to the new
+* task with interrupts disabled.
+*/
+ frame->flags = X86_EFLAGS_FIXED;
frame->bp = 0;
frame->ret_addr = (unsigned long) ret_from_fork;
p->thread.sp = (unsigned long) fork_frame;
Re: [PATCH] perf: update perf.data file format documentation
On Mon, Feb 18, 2019 at 12:22:46AM +0100, Jiri Olsa wrote:
> On Fri, Feb 15, 2019 at 07:28:23PM +0100, Jonas Rabenstein wrote:
> > I found that the documentation of the flags section is some how
> > different from the actual format used and expected by the perf
> > tools. In this patch the according section of the file format
> > documentation is updated to conform to the expectations of the
> > perf tool suite.
> >
> > Signed-off-by: Jonas Rabenstein
> > ---
> > .../perf/Documentation/perf.data-file-format.txt | 15 ++-
> > 1 file changed, 6 insertions(+), 9 deletions(-)
> >
> > diff --git a/tools/perf/Documentation/perf.data-file-format.txt
> > b/tools/perf/Documentation/perf.data-file-format.txt
> > index dfb218feaad9..6ea199f28330 100644
> > --- a/tools/perf/Documentation/perf.data-file-format.txt
> > +++ b/tools/perf/Documentation/perf.data-file-format.txt
> > @@ -43,13 +43,10 @@ struct perf_file_section {
> >
> > Flags section:
> >
> > -The header is followed by different optional headers, described by the
> > bits set
> > -in flags. Only headers for which the bit is set are included. Each header
> > -consists of a perf_file_section located after the initial header.
> > -The respective perf_file_section points to the data of the additional
> > -header and defines its size.
> > -
> > -Some headers consist of strings, which are defined like this:
> > +The Flags section is placed directly after the data section and consists
> > of a
> > +variable amount of information described by the flags-bitset in the
> > perf_header.
> > +A lot of the headers in the Flags section are simple strings and are
> > represented
> > +like this:
>
> some how I find this more confusing.. please describe
> what's actualy wrong with the current wording
The difference is that the current wording states "The header is
followed by different optional headers" but the actual placement
of those headers of the flags section is after the data section
(see perf_file_header__read at util/header.c:3108 in v4.20). But
I admit that I shouldn't have removed the perf_file_section's...
> >
> > struct perf_header_string {
> > uint32_t len;
> > @@ -82,7 +79,7 @@ assigned by the linker to an executable.
> > struct build_id_event {
> > struct perf_event_header header;
> > pid_tpid;
> > - uint8_t build_id[24];
> > + uint8_t build_id[PERF_ALIGN(24, sizeof(u64))];
>
> isn't that always 24? I guess u meant:
>
> build_id[PERF_ALIGN(20, sizeof(u64))];
You are right that this should always be 24. I just went over the diff
of my codebase to generate the perf.data file and tried to extract the
relevant format changes. I think I just stumbled across the definition
of build_id_event in util/event.h:229 and added that (irrelevant) change
which finally - also useless - worked as soon as I adjusted the flags
section.
The other way round this is the actual definition in the code base so
I'm not sure whether it should be the same. But as it is useless perhaps
change the definition in the source?
>
>
> > char filename[header.size - offsetof(struct
> > build_id_event, filename)];
> > };
> >
> > @@ -131,7 +128,7 @@ An uint64_t with the total memory in bytes.
> >
> > HEADER_CMDLINE = 11,
> >
> > -A perf_header_string with the perf command line used to collect the data.
> > +A perf_header_string_list with the perf arg-vector used to collect the
> > data.
>
> nice catch
>
> thanks,
> jirka
>
> >
> > HEADER_EVENT_DESC = 12,
> >
> > --
> > 2.17.1
> >
Re: Firmware files for QCA BT chip WCN3990.
Hi Nicolas, On 2019-02-18 14:08, Nicolas Dechesne wrote: hi Balakrishna, On Mon, Feb 18, 2019 at 7:13 AM Balakrishna Godavarthi wrote: Hi, The following changes since commit a9c22d3d8af87bd39a078ec6c846b0674dd2ca38: qca: Add firmware files for BT chip wcn3990. (2019-02-15 16:07:56 +0530) are available in the Git repository at: https://github.com/bgodavar/qca_bt_wcn3990_fw.git for you to fetch changes up to a9c22d3d8af87bd39a078ec6c846b0674dd2ca38: qca: Add firmware files for BT chip wcn3990. (2019-02-15 16:07:56 +0530) qca/NOTICE.txt | 334 ++ ^ This looks a rather unexpected change. [Bala]: yes we want to update the notice file according to the latest legal rules here in QCA. You are missing updates in WHENCE file, as such: $ make check E: qca/crbtfw21.tlv not listed in WHENCE E: qca/crnv21.bin not listed in WHENCE [Bala]: will update them in WHENCE. -- Regards Balakrishna. -- Regards Balakrishna.
Re: [PATCH 2/2] Input: add Apple SPI keyboard and trackpad driver.
On Sat, Feb 16, 2019 at 02:44:26AM +0200, Andy Shevchenko wrote:
> On Sun, Feb 10, 2019 at 03:18:34AM -0800, Life is hard, and then you die
> wrote:
> > On Wed, Feb 06, 2019 at 10:22:56PM +0200, Andy Shevchenko wrote:
> > > On Mon, Feb 04, 2019 at 12:19:47AM -0800, Ronald Tschalär wrote:
>
> > > > +#definedebug_print(mask, fmt, ...) \
> > > > + do { \
> > > > + if (debug & mask) \
> > > > + printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__); \
> > > > + } while (0)
> > > > +
> > > > +#definedebug_print_header(mask) \
> > > > + debug_print(mask, "--- %s ---\n", \
> > > > + applespi_debug_facility(mask))
> > > > +
> > > > +#definedebug_print_buffer(mask, fmt, ...) \
> > > > + do { \
> > > > + if (debug & mask) \
> > > > + print_hex_dump(KERN_DEBUG, pr_fmt(fmt), \
> > > > + DUMP_PREFIX_NONE, 32, 1,
> > > > ##__VA_ARGS__, \
> > > > + false); \
> > > > + } while (0)
> > >
> > > I'm not sure we need all of these... But okay, the driver is
> > > reverse-engineered, perhaps we can drop it later on.
> >
> > These have been extremely useful for debugging; but yes, they are for
> > debugging only. They also explicitly do not use the dynamic-debug
> > facilities because
> > 1. those can't be enabled at a function or line level on the kernel
> > command line (the docs indicate this should work, but it doesn't,
> > or at the very least I've been unable to figure out how, at least
> > for those drivers built as modules)
>
> Hmm... Usually you put either module_name.dyndbg into kernel command line to
> enable Dynamic Debug on built-in modules, or modprobe module_name dyndbg if
> it's built as a module.
Right, but while that works with
applespi.dyndbg=+p
it does not appear to work with
applespi.dyndbg="func applespi_get_spi_settings +p"
(it is parsed correctly, but it just doesn't get applied when the
module is later loaded - I've not tried to chase this down any further
than that)
[snip]
> > > > +static int touchpad_dimensions[4];
> > > > +module_param_array(touchpad_dimensions, int, NULL, 0444);
> > > > +MODULE_PARM_DESC(touchpad_dimensions, "The pixel dimensions of the
> > > > touchpad, as x_min,x_max,y_min,y_max .");
> > >
> > > We have some parsers for similar data as in format
> > >
> > > %dx%d%+d%+d ?
> > >
> > > For example, 200x100+20+10.
> >
> > Maybe it's just my grep-foo that is lacking, but I couldn't find
> > anything useful. There is some stuff for framebuffer video modes, but
> > that is too different and not really amenable for use here. OTOH, a
> > simple sscanf(buf, "%dx%d+%d+%d", ...) would parse this just fine
> > without the need for any fancier parser.
> >
> > OTOH, I'm not sure this format is any better: internally we need
> > x/y min/max, not x/y/w/h (though obviously the two are trivially
> > convertable); and for the user it doesn't really matter since they would
> > basically be getting the dimensions from running with debug set to
> > 0x1 and using that output to set this param, i.e. I don't see any
> > inherent advantage of using x/y/w/h.
>
> I would stick with some more or less standard notation. The XxY+W+H is widely
> used in X11 world.
>
> If you have better examples for input devices, choose them. My point that it
> would be better to be a standard to some extent.
I couldn't find anything useful (looked in the kernel and libinput),
so going with XxY+W+H.
[snip]
> > > > + message->counter = applespi->cmd_msg_cntr++ & 0xff;
> > >
> > > Usual pattern for this kind of entries is
> > >
> > > x = ... % 256;
> > >
> > > Btw, isn't 256 is defined somewhere?
> >
> > Many things are defined as have a value of 256 :-) But I didn't find any
> > with the intended semantics; could use (U8_MAX+1), though.
>
> What I meant is that I saw in the same driver definition with value of 256.
> Isn't it about messages?
Ah, right: the packet length is 256 bytes. But the semantics are quite
different, so IMHO it wouldn't be good to use that here. I.e. I think
(U8_MAX+1) is still semantically the best.
[snip]
> > > > +/* lifted from the BCM5974 driver */
> > > > +/* convert 16-bit little endian to signed integer */
> > > > +static inline int raw2int(__le16 x)
> > > > +{
> > > > + return (signed short)le16_to_cpu(x);
> > > > +}
> > >
> > > Perhaps it's time to introduce it inside include/linux/input.h ?
> >
> > Perhaps as
> >
> > static inline int le16_to_signed_int(__le16 x)
> >
> > ? (raw2int seems to ambiguous for a global function)
>
> I'm fine. It would need a description though.
After looking at this in more detail I don't think that
include/linux/input.h is the proper place for this, because input.h
basically represents the interface to the input core, and as such it
is devoid of helpers li
Re: [f2fs-dev] [PATCH] f2fs: don't clear CP_QUOTA_NEED_FSCK_FLAG
On 2019/2/16 12:55, Jaegeuk Kim wrote: > On 02/13, Chao Yu wrote: >> On 2019/2/12 10:33, Jaegeuk Kim wrote: >>> If we met this once, let fsck.f2fs clear this only. >>> Note that, this addresses all the subtle fault injection test. >>> >>> Signed-off-by: Jaegeuk Kim >>> --- >>> fs/f2fs/checkpoint.c | 2 -- >>> 1 file changed, 2 deletions(-) >>> >>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c >>> index 03fea4efd64b..10a3ada28715 100644 >>> --- a/fs/f2fs/checkpoint.c >>> +++ b/fs/f2fs/checkpoint.c >>> @@ -1267,8 +1267,6 @@ static void update_ckpt_flags(struct f2fs_sb_info >>> *sbi, struct cp_control *cpc) >>> >>> if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) >>> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >>> - else >>> - __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >> >> I didn't get it, previously, if we didn't persist all quota file's data in >> checkpoint, then we will tag CP_QUOTA_NEED_FSCK_FLAG in CP area, but in >> current >> checkpoint, we have persisted all quota file's data, quota files are >> consistent >> with all other files in filesystem, why we can't remove this NEED_FSCK >> flag..? > > I said it's subtle. So, I guessed 1) set CP_QUOTA_NEED_FSCK_FLAG, 2) clear I know it's subtle... and I agreed we can fix it like this in upstream first, but in our product, it's not rare that we hit the QUOTA_SKIP_FLUSH(its value is 4) case, later we may encounter long latency caused by quota repairing of fsck. > SBI_QUOTA_SKIP_FLUSH by checkpoint, 3) clear CP_QUOTA_NEED_FSCK_FLAG by > another > checkpoint? But later if QUOTA_NEED_REPAIR is set, we will set QUOTA_NEED_FSCK_FLAG again, right? if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); So in order to figure out whether this is caused by out-of-order execution of below assignments: if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); else __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- clear flag later if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- set flag first Could you have a try: if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR) || is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); else __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); Thanks, > >> >> Thanks, >> >>> >>> if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) >>> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >>> > > . >
Re: [LKP] efad4e475c [ 40.308255] Oops: 0000 [#1] PREEMPT SMP PTI
On 2/18/19 5:03 PM, Michal Hocko wrote: On Mon 18-02-19 16:47:26, Rong Chen wrote: On 2/18/19 3:08 PM, Michal Hocko wrote: On Mon 18-02-19 13:28:23, kernel test robot wrote: [...] [ 40.305212] PGD 0 P4D 0 [ 40.308255] Oops: [#1] PREEMPT SMP PTI [ 40.313055] CPU: 1 PID: 239 Comm: udevd Not tainted 5.0.0-rc4-00149-gefad4e4 #1 [ 40.321348] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 40.330813] RIP: 0010:page_mapping+0x12/0x80 [ 40.335709] Code: 5d c3 48 89 df e8 0e ad 02 00 85 c0 75 da 89 e8 5b 5d c3 0f 1f 44 00 00 53 48 89 fb 48 8b 43 08 48 8d 50 ff a8 01 48 0f 45 da <48> 8b 53 08 48 8d 42 ff 83 e2 01 48 0f 44 c3 48 83 38 ff 74 2f 48 [ 40.356704] RSP: 0018:88801fa87cd8 EFLAGS: 00010202 [ 40.362714] RAX: RBX: fffe RCX: 000a [ 40.370798] RDX: fffe RSI: 820b9a20 RDI: 88801e5c [ 40.378830] RBP: 6db6db6db6db6db7 R08: 88801e8bb000 R09: 01b64d13 [ 40.386902] R10: 88801fa87cf8 R11: 0001 R12: 88801e64 [ 40.395033] R13: 820b9a20 R14: 88801f145258 R15: 0001 [ 40.403138] FS: 7fb2079817c0() GS:88801dd0() knlGS: [ 40.412243] CS: 0010 DS: ES: CR0: 80050033 [ 40.418846] CR2: 0006 CR3: 1fa82000 CR4: 06a0 [ 40.426951] Call Trace: [ 40.429843] __dump_page+0x14/0x2c0 [ 40.433947] is_mem_section_removable+0x24c/0x2c0 This looks like we are stumbling over an unitialized struct page again. Something this patch should prevent from. Could you try to apply [1] which will make __dump_page more robust so that we do not blow up there and give some more details in return. Hi Hocko, I have applied [1] and attached the dmesg file. Thanks so the log confirms that this is really an unitialized struct page [ 12.228622] raw: [ 12.231474] page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) [ 12.232135] [ cut here ] [ 12.232649] kernel BUG at include/linux/mm.h:1020! So now, we have to find out what has been left behind. Please see my other email. Also could you give me faddr2line of the is_mem_section_removable offset please? I assume it is is_pageblock_removable_nolock: if (!node_online(page_to_nid(page))) return false; faddr2line result: is_mem_section_removable+0x24c/0x2c0: page_to_nid at include/linux/mm.h:1020 (inlined by) is_pageblock_removable_nolock at mm/memory_hotplug.c:1221 (inlined by) is_mem_section_removable at mm/memory_hotplug.c:1241 Best Regards, Rong Chen
Re: [PATCH] kbuild: Disable extra debugging info in .s output
Borislav, On Mon, Feb 18, 2019 at 5:30 PM Borislav Petkov wrote: > > On Sun, Feb 10, 2019 at 01:39:23PM +0100, Borislav Petkov wrote: > > Please attach the diff or send it from another mail server. > > So you couldn't be bothered to send me an applicable version so I went > and typed it in by hand. Thanks. ;-\ I admit I must fix my unfriendly attitude. Sorry for annoying you. > Anyway, this variant works too, pls queue it. > > Acked-by: Borislav Petkov > Tested-by: Borislav Petkov Could you send v2 as I suggested? Your commit log describes your motivation perfectly. (I lost the applicable patch because I just modified the code locally and pasted it into the previous email.) > Thx. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply. -- Best Regards Masahiro Yamada
Re: [PATCH] f2fs: correct spelling mistake
On 2019/2/18 14:26, Zeng Guangyue wrote: > correct spelling mistake for "nunmber" > > Signed-off-by: Zeng Guangyue Reviewed-by: Chao Yu Thanks,
Re: [PATCH 2/5] nvmem: sunxi-sid: add support for H5's SID controller
On Mon, Feb 18, 2019 at 4:49 PM Maxime Ripard wrote:
>
> On Sun, Feb 17, 2019 at 11:23:13AM -0500, Yangtao Li wrote:
> > Add support for H5's SID controller.
> >
> > Signed-off-by: Yangtao Li
> > ---
> > drivers/nvmem/sunxi_sid.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
> > index 570a2e354f30..036029e90921 100644
> > --- a/drivers/nvmem/sunxi_sid.c
> > +++ b/drivers/nvmem/sunxi_sid.c
> > @@ -219,11 +219,17 @@ static const struct sunxi_sid_cfg sun50i_a64_cfg = {
> > .size = 0x100,
> > };
> >
> > +static const struct sunxi_sid_cfg sun50i_h5_cfg = {
> > + .value_offset = 0x200,
> > + .size = 0x100,
> > +};
>
> IIRC, there was an endianness issue on the newer SoCs, with the driver
> converting the data from big endian to little endian, while it's
> actually stored little endian in the SID.
About that, it seems the internals are either little endian or native (same
as the bus). Either way the nvmem the driver currently exposes is wrong.
My idea is to keep the current one with the current name, but have it not
associate itself with the DT node. We then register an extra one, called
"sunxi-sid-native" which uses the native endian. This one will be associated
with the DT node, so the THS driver can consume nvmem cells.
What do you think?
> Have you checked the SID content?
On the A64 and H5, directly dumping the SID registers (not using the H3
read method) shows the contents are little or native endian.
ChenYu
Re: [PATCH] x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32
On Mon 2019-02-18 13:29:11, chengjian (D) wrote: > Hi，Jiri > > > This patch should be merged into 4.4 stable, > > which still use klp_write_module_reloc. > > > https://elixir.bootlin.com/linux/v4.4.174/source/arch/x86/kernel/livepatch.c > > > ZeFeng may have sent a stable(4.4-y) patch to the wrong mail-list(mainline). ZeFeng or Chengjian, please, send the patch once again with sta...@vger.kernel.org in CC and explanation that it is needed only for 4.4 and why. This thread is already too long and messed to be proceed by stable people effectively. Best Regards, Petr
[RESEND] clk: imx: Refactor entire sccg pll clk
Make the entire combination of plls to be one single clock. The parents used
for bypasses are specified each as an index in the parents list.
The determine_rate does a lookup throughout all the possible combinations
for all the divs and returns the best possible 'setup' which in turn is used
by set_rate later to set up all the divs and bypasses.
Signed-off-by: Abel Vesa
Tested-by: Lucas Stach
Acked-by: Lucas Stach
---
This is basically just a resend of the following:
https://lkml.org/lkml/2019/1/29/874
There are no changes. Just added T-b and A-b tags from Lucas.
Waiting for review.
drivers/clk/imx/clk-imx8mq.c | 58 ++---
drivers/clk/imx/clk-sccg-pll.c | 514 -
drivers/clk/imx/clk.h | 9 +-
3 files changed, 423 insertions(+), 158 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index 398ab0b..7326dce 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -34,15 +34,10 @@ static const char * const audio_pll1_bypass_sels[] =
{"audio_pll1", "audio_pll1_
static const char * const audio_pll2_bypass_sels[] = {"audio_pll2",
"audio_pll2_ref_sel", };
static const char * const video_pll1_bypass_sels[] = {"video_pll1",
"video_pll1_ref_sel", };
-static const char * const sys1_pll1_out_sels[] = {"sys1_pll1",
"sys1_pll1_ref_sel", };
-static const char * const sys2_pll1_out_sels[] = {"sys2_pll1",
"sys1_pll1_ref_sel", };
-static const char * const sys3_pll1_out_sels[] = {"sys3_pll1",
"sys3_pll1_ref_sel", };
-static const char * const dram_pll1_out_sels[] = {"dram_pll1",
"dram_pll1_ref_sel", };
-
-static const char * const sys1_pll2_out_sels[] = {"sys1_pll2_div",
"sys1_pll1_ref_sel", };
-static const char * const sys2_pll2_out_sels[] = {"sys2_pll2_div",
"sys2_pll1_ref_sel", };
-static const char * const sys3_pll2_out_sels[] = {"sys3_pll2_div",
"sys2_pll1_ref_sel", };
-static const char * const dram_pll2_out_sels[] = {"dram_pll2_div",
"dram_pll1_ref_sel", };
+static const char * const sys1_pll_out_sels[] = {"sys1_pll1_ref_sel", };
+static const char * const sys2_pll_out_sels[] = {"sys1_pll1_ref_sel",
"sys2_pll1_ref_sel", };
+static const char * const sys3_pll_out_sels[] = {"sys3_pll1_ref_sel",
"sys2_pll1_ref_sel", };
+static const char * const dram_pll_out_sels[] = {"dram_pll1_ref_sel", };
/* CCM ROOT */
static const char * const imx8mq_a53_sels[] = {"osc_25m", "arm_pll_out",
"sys2_pll_500m", "sys2_pll_1000m",
@@ -308,10 +303,6 @@ static int imx8mq_clocks_probe(struct platform_device
*pdev)
clks[IMX8MQ_AUDIO_PLL1_REF_DIV] = imx_clk_divider("audio_pll1_ref_div",
"audio_pll1_ref_sel", base + 0x0, 5, 6);
clks[IMX8MQ_AUDIO_PLL2_REF_DIV] = imx_clk_divider("audio_pll2_ref_div",
"audio_pll2_ref_sel", base + 0x8, 5, 6);
clks[IMX8MQ_VIDEO_PLL1_REF_DIV] = imx_clk_divider("video_pll1_ref_div",
"video_pll1_ref_sel", base + 0x10, 5, 6);
- clks[IMX8MQ_SYS1_PLL1_REF_DIV] = imx_clk_divider("sys1_pll1_ref_div",
"sys1_pll1_ref_sel", base + 0x38, 25, 3);
- clks[IMX8MQ_SYS2_PLL1_REF_DIV] = imx_clk_divider("sys2_pll1_ref_div",
"sys2_pll1_ref_sel", base + 0x44, 25, 3);
- clks[IMX8MQ_SYS3_PLL1_REF_DIV] = imx_clk_divider("sys3_pll1_ref_div",
"sys3_pll1_ref_sel", base + 0x50, 25, 3);
- clks[IMX8MQ_DRAM_PLL1_REF_DIV] = imx_clk_divider("dram_pll1_ref_div",
"dram_pll1_ref_sel", base + 0x68, 25, 3);
clks[IMX8MQ_ARM_PLL] = imx_clk_frac_pll("arm_pll", "arm_pll_ref_div",
base + 0x28);
clks[IMX8MQ_GPU_PLL] = imx_clk_frac_pll("gpu_pll", "gpu_pll_ref_div",
base + 0x18);
@@ -319,25 +310,6 @@ static int imx8mq_clocks_probe(struct platform_device
*pdev)
clks[IMX8MQ_AUDIO_PLL1] = imx_clk_frac_pll("audio_pll1",
"audio_pll1_ref_div", base + 0x0);
clks[IMX8MQ_AUDIO_PLL2] = imx_clk_frac_pll("audio_pll2",
"audio_pll2_ref_div", base + 0x8);
clks[IMX8MQ_VIDEO_PLL1] = imx_clk_frac_pll("video_pll1",
"video_pll1_ref_div", base + 0x10);
- clks[IMX8MQ_SYS1_PLL1] = imx_clk_sccg_pll("sys1_pll1",
"sys1_pll1_ref_div", base + 0x30, SCCG_PLL1);
- clks[IMX8MQ_SYS2_PLL1] = imx_clk_sccg_pll("sys2_pll1",
"sys2_pll1_ref_div", base + 0x3c, SCCG_PLL1);
- clks[IMX8MQ_SYS3_PLL1] = imx_clk_sccg_pll("sys3_pll1",
"sys3_pll1_ref_div", base + 0x48, SCCG_PLL1);
- clks[IMX8MQ_DRAM_PLL1] = imx_clk_sccg_pll("dram_pll1",
"dram_pll1_ref_div", base + 0x60, SCCG_PLL1);
-
- clks[IMX8MQ_SYS1_PLL2] = imx_clk_sccg_pll("sys1_pll2",
"sys1_pll1_out_div", base + 0x30, SCCG_PLL2);
- clks[IMX8MQ_SYS2_PLL2] = imx_clk_sccg_pll("sys2_pll2",
"sys2_pll1_out_div", base + 0x3c, SCCG_PLL2);
- clks[IMX8MQ_SYS3_PLL2] = imx_clk_sccg_pll("sys3_pll2",
"sys3_pll1_out_div", base + 0x48, SCCG_PLL2);
- clks[IMX8MQ_DRAM_PLL2] = imx_clk_sccg_pll("dram_pll2",
"dram_pll1_out_div", base + 0x60, SCCG_PLL2);
-
- /* PLL divs */
- clks[IMX8MQ_SYS1_PLL1_OUT_DIV] = imx_clk_divider("sys1_pll1_out_div",
"sys1_pll1_out",
Re: [PATCH 2/2] extcon intel-cht-wc: Enable external charger
Hi, On 17-02-19 22:52, Yauhen Kharuzhy wrote: On Fri, Feb 15, 2019 at 09:32:50AM +0300, Yauhen Kharuzhy wrote: On Thu, Feb 14, 2019 at 05:31:48PM +0100, Hans de Goede wrote: Hi, On 10-02-19 21:36, Yauhen Kharuzhy wrote: In some configuration external charge "#charge enable" signal is connected to PMIC. Enable it at device probing to allow charging. Tested at Lenovo Yoga Book (YB1-X91L). Signed-off-by: Yauhen Kharuzhy --- drivers/extcon/extcon-intel-cht-wc.c | 33 1 file changed, 33 insertions(+) diff --git a/drivers/extcon/extcon-intel-cht-wc.c b/drivers/extcon/extcon-intel-cht-wc.c index 4f6ba249bc30..00cb3084955e 100644 --- a/drivers/extcon/extcon-intel-cht-wc.c +++ b/drivers/extcon/extcon-intel-cht-wc.c @@ -57,6 +57,11 @@ #define CHT_WC_USBSRC_TYPE_OTHER 8 #define CHT_WC_USBSRC_TYPE_DCP_EXTPHY9 +#define CHT_WC_CHGDISCTRL 0x5e2f +#define CHT_WC_CHGDISCTRL_CCSM_DIS 0x11 +#define CHT_WC_CHGDISCTRL_CCSM_EN 0x00 Hmm, the enable mask here does not match the enable mask from: https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/EM-Charger-Disable-battery-charging-in-S3-and-enable.patch Which has: #define CHGDISFN_EN_CCSM_VAL 0x50 #define CHGDISFN_DIS_CCSM_VAL 0x11 #define CHGDISFN_CCSM_MASK 0x51 Where as on my hardware, the PMIC comes up with 0x50 in the 0x5e2f register, exactly matching the values from that patch. Why did you change this value ? Good question... I found this values in Lenovo's sources and use them 'as is': https://github.com/jekhor/yogabook-linux-android-kernel/blob/b7aa015ab794b516da7b6cb76e5e2d427e3b8b0c/drivers/power/intel_pmic_ccsm.h#L255 I don't remember if charger worked with Intel's value, I need to re-check this. As we know now, value 0x50 meaning is: - HW mode - regular output type - low level at output 0x00 meaning is: - SW mode - open-drain output - low level at output I don't know what exactly "HW/SW mode" means but I suppose that this pin can be controlled by PMIC internal charge state algorithm (if it is enabled) or by software (extcon driver). So, if we set 0x50 value and disable HW-controlled charging entirely (as extcon driver does), we don't set 'charger enable' signal to low as expected. Its exactly state is unknown, but I checked – it is HIGH. Charger doesn't start charging with this value and starts with 0x00. 0x0b register of 0x6b device on bus 7 – it is the status register of BQ25892 charger, where bits 3,4 describe charging state, 10b means fast charging, 00b means not charging. root@yogabook:/home/jek# i2cset -y -f 6 0x5e 0x2f 0x00 root@yogabook:/home/jek# i2cget -y -f 7 0x6b 0x0b 0x16 root@yogabook:/home/jek# i2cset -y -f 6 0x5e 0x2f 0x01 root@yogabook:/home/jek# i2cget -y -f 7 0x6b 0x0b 0x06 root@yogabook:/home/jek# i2cset -y -f 6 0x5e 0x2f 0x10 root@yogabook:/home/jek# i2cget -y -f 7 0x6b 0x0b 0x16 root@yogabook:/home/jek# i2cset -y -f 6 0x5e 0x2f 0x11 root@yogabook:/home/jek# i2cget -y -f 7 0x6b 0x0b 0x06 root@yogabook:/home/jek# i2cset -y -f 6 0x5e 0x2f 0x50 root@yogabook:/home/jek# i2cget -y -f 7 0x6b 0x0b 0x06 root@yogabook:/home/jek# i2cset -y -f 6 0x5e 0x2f 0x51 root@yogabook:/home/jek# i2cget -y -f 7 0x6b 0x0b 0x06 After reading of Intel's and Lenovo's sources i understood that Intel's meaning of CHGDISFN_EN_CCSM_VAL is 'enable HW control of charging' and Lenovo's is 'enable charging'. Lenovo set this value immediately after probing and after resume, Intel – only after resume. HW-controlled charging is disabled entirely at probing, so I don't know how Intel's driver enables charging. So, I propose: 1) save initial value of CHGDIS register for restoring it at driver remove (because the extcon-intel-cht-wc driver restores HW control in cht_wc_extcon_remove()). 2) at driver start, enable SW control of CHGDIS and set its value to 0. 3) at driver removing, restore the saved state. This sounds good to me, note I believe the extcon code should not touch bit 4 (open-drain,vs regular), but since we disable the charger state-machine we should obviously then switch the pin to sw mode and drive the pin low so that the charger still works. I believe that on the GPD win / GPD pocket the chgdis pin of the PMIC is not connected to the charger, since writing different values to reg 5e2f has no effect there. I do wonder how this interacts with inserting an otg-host cable into the micro-usb, I mean a cable like this: https://alexnld.com/wp-content/uploads/2013/11/S-UDC-103.jpg A cable like this will short the id-pin to ground and at this point we should disable the charger and enable a 5V boost converter to supply 5V to the device connected to the USB-A connector. On the GPD win / GPD pocket this is controlled through the Type-C framework and the V5 boost converter is actually part of the charger-IC, so charging gets disabled automatically when we tell the charger-IC to do enable its 5V boost converter
Re: [PATCH] mm/hugetlb: Fix unsigned overflow in __nr_hugepages_store_common()
On Sat 16-02-19 21:31:12, Jingxiangfeng wrote:
> From: Jing Xiangfeng
>
> We can use the following command to dynamically allocate huge pages:
> echo NR_HUGEPAGES > /proc/sys/vm/nr_hugepages
> The count in __nr_hugepages_store_common() is parsed from
> /proc/sys/vm/nr_hugepages,
> The maximum number of count is ULONG_MAX,
> the operation 'count += h->nr_huge_pages - h->nr_huge_pages_node[nid]'
> overflow and count will be a wrong number.
Could you be more specific of what is the runtime effect on the
overflow? I haven't checked closer but I would assume that we will
simply shrink the pool size because count will become a small number.
Is there any reason to report an error in that case? We do not report
errors when we cannot allocate the requested number of huge pages so why
is this case any different?
> So check the overflow to fix this problem.
>
> Signed-off-by: Jing Xiangfeng
> ---
> mm/hugetlb.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index afef616..55173c3 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2423,7 +2423,12 @@ static ssize_t __nr_hugepages_store_common(bool
> obey_mempolicy,
>* per node hstate attribute: adjust count to global,
>* but restrict alloc/free to the specified node.
>*/
> + unsigned long old_count = count;
> count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
> + if (count < old_count) {
> + err = -EINVAL;
> + goto out;
> + }
> init_nodemask_of_node(nodes_allowed, nid);
> } else
> nodes_allowed = &node_states[N_MEMORY];
> --
> 2.7.4
--
Michal Hocko
SUSE Labs
Re: [PATCH v2] USB: serial: cp210x: Fix GPIO in autosuspend
On So, 2019-02-17 at 18:59 +0100, Karoly Pados wrote: > Current GPIO code in cp210x fails to take USB autosuspend into account, > making it practically impossible to use GPIOs with autosuspend enabled > without user configuration. Fix this like for ftdi_sio in a previous patch. > Tested on a CP2102N. Hi, your patch is looking good to me, but I am afraid there are issues. How do the GPIO lines on the device interact with USB reset and system suspend? Regards Oliver
Re: [PATCH v5 3/3] powerpc/32: Add KASAN support
Christophe Leroy writes:
> diff --git a/arch/powerpc/include/asm/ppc_asm.h
> b/arch/powerpc/include/asm/ppc_asm.h
> index e0637730a8e7..dba2c1038363 100644
> --- a/arch/powerpc/include/asm/ppc_asm.h
> +++ b/arch/powerpc/include/asm/ppc_asm.h
> @@ -251,6 +251,10 @@ GLUE(.,name):
>
> #define _GLOBAL_TOC(name) _GLOBAL(name)
>
> +#define KASAN_OVERRIDE(x, y) \
> + .weak x; \
> + .set x, y
> +
Can you add a comment describing what that does and why?
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 879b36602748..fc4c42262694 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -16,8 +16,9 @@ CFLAGS_prom_init.o += -fPIC
> CFLAGS_btext.o += -fPIC
> endif
>
> -CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
> -CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
> +CFLAGS_early_32.o += -DDISABLE_BRANCH_PROFILING
> +CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
> -DDISABLE_BRANCH_PROFILING
> +CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
> -DDISABLE_BRANCH_PROFILING
Why do we need to disable branch profiling now?
I'd probably be happier if all the CFLAGS changes were done in a leadup
patch to make them more obvious.
> diff --git a/arch/powerpc/kernel/prom_init_check.sh
> b/arch/powerpc/kernel/prom_init_check.sh
> index 667df97d2595..da6bb16e0876 100644
> --- a/arch/powerpc/kernel/prom_init_check.sh
> +++ b/arch/powerpc/kernel/prom_init_check.sh
> @@ -16,8 +16,16 @@
> # If you really need to reference something from prom_init.o add
> # it to the list below:
>
> +grep CONFIG_KASAN=y .config >/dev/null
Just to be safe "^CONFIG_KASAN=y$" ?
> +if [ $? -eq 0 ]
> +then
> + MEMFCT="__memcpy __memset"
> +else
> + MEMFCT="memcpy memset"
> +fi
MEM_FUNCS ?
> diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
> index 3bf9fc6fd36c..ce8d4a9f810a 100644
> --- a/arch/powerpc/lib/Makefile
> +++ b/arch/powerpc/lib/Makefile
> @@ -8,6 +8,14 @@ ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
> CFLAGS_REMOVE_code-patching.o = $(CC_FLAGS_FTRACE)
> CFLAGS_REMOVE_feature-fixups.o = $(CC_FLAGS_FTRACE)
>
> +KASAN_SANITIZE_code-patching.o := n
> +KASAN_SANITIZE_feature-fixups.o := n
> +
> +ifdef CONFIG_KASAN
> +CFLAGS_code-patching.o += -DDISABLE_BRANCH_PROFILING
> +CFLAGS_feature-fixups.o += -DDISABLE_BRANCH_PROFILING
> +endif
There's that branch profiling again, though here it's only if KASAN is enabled.
> diff --git a/arch/powerpc/mm/kasan_init.c b/arch/powerpc/mm/kasan_init.c
> new file mode 100644
> index ..bd8e0a263e12
> --- /dev/null
> +++ b/arch/powerpc/mm/kasan_init.c
> @@ -0,0 +1,114 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#define DISABLE_BRANCH_PROFILING
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +void __init kasan_early_init(void)
> +{
> + unsigned long addr = KASAN_SHADOW_START;
> + unsigned long end = KASAN_SHADOW_END;
> + unsigned long next;
> + pmd_t *pmd = pmd_offset(pud_offset(pgd_offset_k(addr), addr), addr);
Can none of those fail?
cheers
Re: [LKP] efad4e475c [ 40.308255] Oops: 0000 [#1] PREEMPT SMP PTI
On Mon 18-02-19 17:11:49, Rong Chen wrote: > > On 2/18/19 5:03 PM, Michal Hocko wrote: > > On Mon 18-02-19 16:47:26, Rong Chen wrote: > > > On 2/18/19 3:08 PM, Michal Hocko wrote: > > > > On Mon 18-02-19 13:28:23, kernel test robot wrote: > > [...] > > > > > [ 40.305212] PGD 0 P4D 0 > > > > > [ 40.308255] Oops: [#1] PREEMPT SMP PTI > > > > > [ 40.313055] CPU: 1 PID: 239 Comm: udevd Not tainted > > > > > 5.0.0-rc4-00149-gefad4e4 #1 > > > > > [ 40.321348] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > > > > > BIOS 1.10.2-1 04/01/2014 > > > > > [ 40.330813] RIP: 0010:page_mapping+0x12/0x80 > > > > > [ 40.335709] Code: 5d c3 48 89 df e8 0e ad 02 00 85 c0 75 da 89 e8 > > > > > 5b 5d c3 0f 1f 44 00 00 53 48 89 fb 48 8b 43 08 48 8d 50 ff a8 01 48 > > > > > 0f 45 da <48> 8b 53 08 48 8d 42 ff 83 e2 01 48 0f 44 c3 48 83 38 ff > > > > > 74 2f 48 > > > > > [ 40.356704] RSP: 0018:88801fa87cd8 EFLAGS: 00010202 > > > > > [ 40.362714] RAX: RBX: fffe RCX: > > > > > 000a > > > > > [ 40.370798] RDX: fffe RSI: 820b9a20 RDI: > > > > > 88801e5c > > > > > [ 40.378830] RBP: 6db6db6db6db6db7 R08: 88801e8bb000 R09: > > > > > 01b64d13 > > > > > [ 40.386902] R10: 88801fa87cf8 R11: 0001 R12: > > > > > 88801e64 > > > > > [ 40.395033] R13: 820b9a20 R14: 88801f145258 R15: > > > > > 0001 > > > > > [ 40.403138] FS: 7fb2079817c0() GS:88801dd0() > > > > > knlGS: > > > > > [ 40.412243] CS: 0010 DS: ES: CR0: 80050033 > > > > > [ 40.418846] CR2: 0006 CR3: 1fa82000 CR4: > > > > > 06a0 > > > > > [ 40.426951] Call Trace: > > > > > [ 40.429843] __dump_page+0x14/0x2c0 > > > > > [ 40.433947] is_mem_section_removable+0x24c/0x2c0 > > > > This looks like we are stumbling over an unitialized struct page again. > > > > Something this patch should prevent from. Could you try to apply [1] > > > > which will make __dump_page more robust so that we do not blow up there > > > > and give some more details in return. > > > > > > Hi Hocko, > > > > > > I have applied [1] and attached the dmesg file. > > Thanks so the log confirms that this is really an unitialized struct > > page > > [ 12.228622] raw: > > [ 12.231474] page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) > > [ 12.232135] [ cut here ] > > [ 12.232649] kernel BUG at include/linux/mm.h:1020! > > > > So now, we have to find out what has been left behind. Please see my > > other email. Also could you give me faddr2line of the > > is_mem_section_removable offset please? I assume it is > > is_pageblock_removable_nolock: > > if (!node_online(page_to_nid(page))) > > return false; > > > faddr2line result: > > is_mem_section_removable+0x24c/0x2c0: > page_to_nid at include/linux/mm.h:1020 > (inlined by) is_pageblock_removable_nolock at mm/memory_hotplug.c:1221 > (inlined by) is_mem_section_removable at mm/memory_hotplug.c:1241 Thanks so this indeed points to page_to_nid. Thanks! -- Michal Hocko SUSE Labs
ALMIGHTY GOD HAS DONE IT,
Dear Friend, I hope you are fine over there in your country. I know that this message will come as a surprise to you but let me start by introducing myself; I am Mr. Abderazack Zebdani, Manager of Bank of Africa BOA Burkina Faso. I am writing you this letter to fulfill the promise I have with Almighty, now listen to me let me explain to you, in my department in the bank I discovered the sum of ($18.600, 000. eighteen Million six hundred thousand United State Dollars) and I was searching for a foreigner partner who will assist me to claims the fund, first I send you an E-mail concerning this transaction but I waited to hear from you about the transaction business in which I proposed to you but did not hear anything from you again maybe you are too busy or you did not received my messaged. So I have to search for another person who will assist me luckily for me I founded a partner from South Korea and both of us did the business now when this transaction was going on I have agreement with Almighty, I promised Almighty if the transaction move successfully that I will give out 10 percent of the total fund out to the motherless babies and the widowers and luckily for us the business move successfully without any problem so as a good Christian I did not forget my promise to Almighty, I decided to give out the 10 percent to the needy ones , so I decided to hand over the money under your care for you to use and help the motherless babies and the widowers over there in your country, Now I am in South Korea with my new partner who helped me finalized everything about the transaction. So therefore I kept the total sum of $ 1.860,000, Million (One Million eight Hundred sixty Thousand United State Dollars), As the 10 percent of the total fund for the motherless babies and the widowers and I deposited the money with the Coris Bank International under my secretary care Mrs.Latifa koumbousi, email ( latifakoumbousi2...@gmail.com ) therefore contact Mrs.Latifa koumbousi, immediately via her email address so that she will direct you how to receive the funds. you can receive it into your bank account in your country, so feel free to contact my secretary Mrs.Latifa koumbousi, for I have gave them instruction to transfer the funds to you as soon as you contact her; please give some part of this funds to the motherless babies and widowers in your country that is my promise to Almighty. N: B Note that I will not be checking my email because I am too busy here now in South Korea, I have instructed my secretary to direct you how to receive the funds and I want you to keep this as secret do not let my secretary to know about this transaction I just explain to you now I only kept the fund under her care but she’s not aware of the transaction I told her that the money is for business , so contact her and introduce yourself to her because I have also told her about you so tell her to direct you on how you will receive the funds please make sure that the motherless babies and the widowers over there in your country will receive this money successfully as I promise to Almighty. Thanks Best Regards, Mr. Abderazack Zebdani
Re: [PATCH] i2c: cadence: try reset when master receive arbitration lost
Hi, On 18. 02. 19 9:35, sxauwsk wrote: > When the adapter receive arbitration lost error interrupts, > cdns_i2c_master_xfer return to the caller directly instead of resetting > the adapter which resulted in the adapter being out of control. > > So when driver detect err_status such as arbitration lost, > then try to repair and fix it. > > Signed-off-by: sxauwsk Can you please fix your name here? And also in subject. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs signature.asc Description: OpenPGP digital signature
Re: [PATCH 4/4] arm64: dts: allwinner: h6: Add CPU Operating Performance Points table
Hi, On Fri, Feb 15, 2019 at 10:09:51PM +0800, Frank Lee wrote: > On Fri, Feb 15, 2019 at 9:56 PM Maxime Ripard > wrote: > > > > Hi > > > > On Fri, Feb 15, 2019 at 12:56:03AM +0800, Frank Lee wrote: > > > How about to implement a thermal driver that is not integrated with > > > gpadc ？ > > > > > > GPADC on soc is rarely used now. > > > > You mean GPADC in general, or the gpadc driver in particular? > > Otherwise, yes, having a driver for the thermal sensor in the H6 > > sounds like a good plan for thermal throttling, but I don't see it as > > a dependency for that whole series. > > At present, sunxi's thermal driver is integrated with the gpadc driver. > I have a idea to implement the thermal driver alone. I haven't started yet, > and it may take a while to do it. > > How about the plan to implement a thermal drive alone and put i > under drivers/thermal? The Thermal Sensor is basically a stripped down GPADC, which is why it would make sense to have a single driver. There was a pending series doing this that could be a good idea to improve and merge: https://lkml.org/lkml/2018/8/30/729 Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v3 1/4] dt-bindings: input: touchscreen: goodix: Document AVDD28-supply property
Hi Dmitry, On Mon, Feb 18, 2019 at 12:42 PM Dmitry Torokhov wrote: > > On Sun, Feb 17, 2019 at 02:45:52PM +0530, Jagan Teki wrote: > > On Sun, Feb 17, 2019 at 1:21 PM Jagan Teki > > wrote: > > > > > > Hi Dmitry and Rob, > > > > > > On Thu, Feb 14, 2019 at 3:21 AM Rob Herring wrote: > > > > > > > > On Tue, Jan 22, 2019 at 7:39 AM Jagan Teki > > > > wrote: > > > > > > > > > > On Mon, Jan 21, 2019 at 9:46 PM Rob Herring wrote: > > > > > > > > > > > > On Fri, Jan 18, 2019 at 10:01 AM Jagan Teki > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Jan 9, 2019 at 7:08 PM Rob Herring > > > > > > > wrote: > > > > > > > > > > > > > > > > Please CC DT list if you want bindings reviewed. > > > > > > > > > > > > > > Sorry I forgot. > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 9, 2019 at 1:40 AM Dmitry Torokhov > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Sat, Dec 15, 2018 at 08:47:59PM +0530, Jagan Teki wrote: > > > > > > > > > > Most of the Goodix CTP controllers are supply with AVDD28 > > > > > > > > > > pin. > > > > > > > > > > which need to supply for controllers like GT5663 on some > > > > > > > > > > boards > > > > > > > > > > to trigger the power. > > > > > > > > > > > > > > > > > > > > So, document the supply property so-that the require boards > > > > > > > > > > that used on GT5663 can enable it via device tree. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Jagan Teki > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > > > > | 1 + > > > > > > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > > > > > > > > > > > > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > > > > index f7e95c52f3c7..c4622c983e08 100644 > > > > > > > > > > --- > > > > > > > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > > > > +++ > > > > > > > > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > > > > @@ -23,6 +23,7 @@ Optional properties: > > > > > > > > > > - touchscreen-inverted-y : Y axis is inverted (boolean) > > > > > > > > > > - touchscreen-swapped-x-y : X and Y axis are swapped > > > > > > > > > > (boolean) > > > > > > > > > > (swapping is done after > > > > > > > > > > inverting the axis) > > > > > > > > > > + - AVDD28-supply : Analog power supply regulator on > > > > > > > > > > AVDD28 pin > > > > > > > > > > > > > > > > > > I think we normally use lower case in DT bindings and rarely > > > > > > > > > encode > > > > > > > > > voltage in the supply name unless we are dealing with several > > > > > > > > > supplies > > > > > > > > > of the same kind, but I'll let Ron comment on this. > > > > > > > > > > > > > > > > Yes on lowercase though there are some exceptions. > > > > > > > > > > > > > > > > There's also a AVDD22 supply as well as DVDD12 and VDDIO. So we > > > > > > > > probably need to keep the voltage, but the binding is > > > > > > > > incomplete. > > > > > > > > > > > > > > What is incomplete here? can you please elaborate. > > > > > > > > > > > > You are missing the 3 other supplies the chip has: AVDD22, DVDD12 > > > > > > and VDDIO. > > > > > > > > > > Though it has other supplies, only AVDD28 is connected in the Host > > > > > interface design similar like 9. Reference Schematic on Page, 23 in > > > > > attached manual. > > > > > > > > That is for a particular board design. It still has other supplies. > > > > Just make the binding complete please. You can make them optional. I > > > > don't care if the driver supports controlling all the supplies or not > > > > (though Dmitry might). > > > > > > So, Can I make bulk get and enable in all 4 regulators global to > > > driver or specific to that chip, in either way the regulators which > > > are not used to process via dummy regulators (which we all know). > > > > > > or regulator which are not using are get via devm_regulator_get_optional. > > > > > > Any suggestions? > > > > Just realized to go with bulk calls, please have a look at on v5 [1] > > I do not believe you can use bulk regulator API here as you need to > implement the power up timing scheme mentioned on p. 12 of the spec you > referenced earlier. And, because of that timing diagram, I believe if > you want to control AVDD supply, you also have to control VDDIO supply > as it has to be on only after enabling AVDD. AVDD here is AVDD28 it' is an out name of pin (mentioned in p. 23). So the power scheme goes to enable AVDD28 and then VDDIO does that really mean bulk of two regulators? > > I also wonder if it is valid to have both AVDD28 and AVDD22 connected at > the same time. Yes, DVDD12 and AVDD22 not been part of power-up schema at-least from the datasheet. I'm thinking
Re: [PATCH V1] i2c: tegra: fix tegra186 hw supported features
On 18/02/2019 08:42, Thierry Reding wrote: > On Sat, Feb 16, 2019 at 08:33:07AM -0800, Sowjanya Komatineni wrote: >> Tegra186 does not support multi-master mode and also there is no >> master fifo control register. >> >> This patch fixes supported features of Tegra186 and prevents >> crashing during boot as master fifo control register are not >> present on Tegra186 and prior. >> >> Signed-off-by: Sowjanya Komatineni >> --- >> drivers/i2c/busses/i2c-tegra.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > > We really should've caught this earlier. Jon, let's think about ways to > make it easier to catch these things in the future on our test system. Indeed. This has fixed the boot regression I was seeing over the weekend on -next for Tegra186. However, I am bit confused here, because when I look at the Tegra186 TRM it states that the I2C supports multi-master mode which disagrees with this patch. Furthermore, it seems odd that Tegra210 and Tegra194 would support multi-master mode but Tegra186 does not. So is this really correct? Cheers Jon -- nvpublic
Re: [PATCH] scsi: mvumi: fix 32 bit shift of a 32 bit unsigned int
On Sat, Feb 16, 2019 at 05:27:16PM +0100, Walter Harms wrote:
> Am 16.02.2019 15:44, schrieb Colin King:
> > From: Colin Ian King
> >
> > Currently m_sg->baseaddr_h (a 32 bit unsigned int) is being shifted by a
> > total of 32 bits; this always produces a 0 result. Fix this by casting
> > it to a dma_addr_t (a 64 bit unsigned int) before performing the shift.
> >
> > Detected by CoverityScan, CID#147270 ("Operands don't affect result")
> >
> > Fixes: f0c568a478f0 ("[SCSI] mvumi: Add Marvell UMI driver")
> > Signed-off-by: Colin Ian King
> > ---
> > drivers/scsi/mvumi.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/scsi/mvumi.c b/drivers/scsi/mvumi.c
> > index 36f64205ecfa..d3582accfd09 100644
> > --- a/drivers/scsi/mvumi.c
> > +++ b/drivers/scsi/mvumi.c
> > @@ -313,7 +313,7 @@ static void mvumi_delete_internal_cmd(struct mvumi_hba
> > *mhba,
> > sgd_getsz(mhba, m_sg, size);
> >
> > phy_addr = (dma_addr_t) m_sg->baseaddr_l |
> > - (dma_addr_t) ((m_sg->baseaddr_h << 16) << 16);
> > + (((dma_addr_t) m_sg->baseaddr_h << 16) << 16);
> >
> > dma_free_coherent(&mhba->pdev->dev, size, cmd->data_buf,
> > phy_addr);
>
> i would suggest to try a version with less casts to make it more readable
> like this untested suggestion:
>
> phy_addr =(m_sg->baseaddr_h << 16)| m_sg->baseaddr_l;
> phy_addr <<= 16;
>
That would be a behavior change but it also might be a bugfix? Why
doesn't the code just do:
phy_addr = ((dma_addr_t)m_sg->baseaddr_h << 32) | m_sg->baseaddr_l;
(Probably they broke it up into two shifts to silence a GCC warning that
the shift was wrong because of the missing cast?)
regards,
dan carpenter
Re: [PATCH] net/mlx4_en: fix spelling mistake: "quiting" -> "quitting"
On 2/18/2019 1:03 AM, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a en_err error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 6b1b8e35..c1438ae52a11 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -3360,7 +3360,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int
> port,
> dev->addr_len = ETH_ALEN;
> mlx4_en_u64_to_mac(dev->dev_addr, mdev->dev->caps.def_mac[priv->port]);
> if (!is_valid_ether_addr(dev->dev_addr)) {
> - en_err(priv, "Port: %d, invalid mac burned: %pM, quiting\n",
> + en_err(priv, "Port: %d, invalid mac burned: %pM, quitting\n",
> priv->port, dev->dev_addr);
> err = -EINVAL;
> goto out;
>
Hi Colin, thanks for your patch.
Reviewed-by: Tariq Toukan
I would suggest adding a Fixes line, but looking into the history of the
typo, it went through many patches that modified this line but preserved
the typo.
Actually, it dates back to the very first commit that introduces mlx4
driver:
Patches history:
2b3ddf27f48c net/mlx4_core: Replace VF zero mac with random mac in mlx4_core
ef96f7d46ad8 net/mlx4_en: Handle unassigned VF MAC address correctly
6bbb6d99f3d2 net/mlx4_en: Optimize Rx fast path filter checks
453a60827735 mlx4_en: Giving interface name in debug messages
c27a02cd94d6 mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC
I'm not sure what the "Fixes:" policy is in these cases.
Thanks,
Tariq
Re: [PATCH V6 2/7] clocksource: tegra: add Tegra210 timer support
On 18/02/2019 10:01, Joseph Lo wrote:
> On 2/15/19 11:14 PM, Daniel Lezcano wrote:
>> On 01/02/2019 17:16, Joseph Lo wrote:
>>> Add support for the Tegra210 timer that runs at oscillator clock
>>> (TMR10-TMR13). We need these timers to work as clock event device and to
>>> replace the ARMv8 architected timer due to it can't survive across the
>>> power cycle of the CPU core or CPUPORESET signal. So it can't be a
>>> wake-up
>>> source when CPU suspends in power down state.
>>>
>>> Also convert the original driver to use timer-of API.
>>>
>>> Cc: Daniel Lezcano
>>> Cc: Thomas Gleixner
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Joseph Lo
>>> Acked-by: Thierry Reding
>>> Acked-by: Jon Hunter
>>> ---
>>> v6:
>>> * refine the timer defines
>>> * add ack tag from Jon.
>>> v5:
>>> * add ack tag from Thierry
>>> v4:
>>> * merge timer-tegra210.c in previous version into timer-tegra20.c
>>> v3:
>>> * use timer-of API
>>> v2:
>>> * add error clean-up code
>>> ---
>>> drivers/clocksource/Kconfig | 2 +-
>>> drivers/clocksource/timer-tegra20.c | 371
>>> include/linux/cpuhotplug.h | 1 +
>>> 3 files changed, 270 insertions(+), 104 deletions(-)
>>>
>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>> index a9e26f6a81a1..6af78534a285 100644
>>> --- a/drivers/clocksource/Kconfig
>>> +++ b/drivers/clocksource/Kconfig
>>> @@ -131,7 +131,7 @@ config SUN5I_HSTIMER
>>> config TEGRA_TIMER
>>> bool "Tegra timer driver" if COMPILE_TEST
>>> select CLKSRC_MMIO
>>> - depends on ARM
>>
>> This will break because the delay functions are defined in
>> arch/arm/include/asm/delay.h and the 01.org will try to compile the
>> driver on x86.
>>
>> You may want to add 'depends on ARM && ARM64'
>>
>
> OK, I think it's 'depends on ARM || ARM64'.
Ah, yes right.
> Will fix.
>
>>> + select TIMER_OF
>>> help
>>> Enables support for the Tegra driver.
>>>
> [snip]
>>> -
>>> static struct timespec64 persistent_ts;
>>> static u64 persistent_ms, last_persistent_ms;
>>
>> Did you check the above changes are still relevant after commit
>> 39232ed5a1793f67 and after doing a change similar to
>> commit 1569557549697207e523 ?
>>
>
> Yes, just check both commits. I think it's okay to use the same. But
> need another patch to do that, this patch only adds new support for
> Tegra210. Doesn't touch the original code.
Ok, let's do the change later.
>>> static struct delay_timer tegra_delay_timer;
> [snip]
>>> +#ifdef CONFIG_ARM64
>>> +static DEFINE_PER_CPU(struct timer_of, tegra_to) = {
>>> + .flags = TIMER_OF_CLOCK | TIMER_OF_BASE,
>>> +
>>> + .clkevt = {
>>> + .name = "tegra_timer",
>>> + .rating = 460,
>>> + .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
>>
>> CLOCK_EVT_FEAT_DYNIRQ ?
> Yes, good catch.
>>
>>> + .set_next_event = tegra_timer_set_next_event,
>>> + .set_state_shutdown = tegra_timer_shutdown,
>>> + .set_state_periodic = tegra_timer_set_periodic,
>>> + .set_state_oneshot = tegra_timer_shutdown,
>>> + .tick_resume = tegra_timer_shutdown,
>>> + },
>>> +};
> [snip]
>>> -static unsigned long tegra_delay_timer_read_counter_long(void)
>>> +static int tegra_timer_suspend(void)
>>> {
>>> - return readl(timer_reg_base + TIMERUS_CNTR_1US);
>>> +#ifdef CONFIG_ARM64
>>
>> Please do not add those #ifdef but function stubs.
>>
>>> + int cpu;
>>> +
>>> + for_each_possible_cpu(cpu) {
>>> + struct timer_of *to = per_cpu_ptr(&tegra_to, cpu);
>>> + void __iomem *reg_base = timer_of_base(to);
>>> +
>>> + writel(TIMER_PCR_INTR_CLR, reg_base + TIMER_PCR);
>>> + }
>>> +#else
>>> + void __iomem *reg_base = timer_of_base(&tegra_to);
>>> +
>>> + writel(TIMER_PCR_INTR_CLR, reg_base + TIMER_PCR);
>>> +#endif
>>> +
>>> + return 0;
>>> }
>>> -static irqreturn_t tegra_timer_interrupt(int irq, void *dev_id)
>>> +static void tegra_timer_resume(void)
>>> {
>>> - struct clock_event_device *evt = (struct clock_event_device
>>> *)dev_id;
>>> - timer_writel(1<<30, TIMER3_BASE + TIMER_PCR);
>>> - evt->event_handler(evt);
>>> - return IRQ_HANDLED;
>>> + writel(usec_config, timer_reg_base + TIMERUS_USEC_CFG);
>>> }
>>> -static struct irqaction tegra_timer_irq = {
>>> - .name = "timer0",
>>> - .flags = IRQF_TIMER | IRQF_TRIGGER_HIGH,
>>> - .handler = tegra_timer_interrupt,
>>> - .dev_id = &tegra_clockevent,
>>> +static struct syscore_ops tegra_timer_syscore_ops = {
>>> + .suspend = tegra_timer_suspend,
>>> + .resume = tegra_timer_resume,
>>> };
>>
>> It will be nicer to use the suspend/resume callbacks defined in the
>> clockevent structure, so you can use generic as there are multiple
>> clockevents defined for the tegra210, thus multiple timer-of
>> encapsulating them. When the suspend/resume callbacks are called, they
>> have t
Re: [PATCH] mm: Fix buddy list helpers
On Sat 16-02-19 09:07:02, Dan Williams wrote: > Tetsuo reports that free page statistics are not reporting correctly, > and Vlastimil noticed that "mm: Move buddy list manipulations into > helpers" botched one of its conversions of add_to_free_area(). Fix the > double-increment of ->nr_free. > > Reported-by: Tetsuo Handa > Reported-by: Vlastimil Babka > Cc: Michal Hocko > Tested-by: Tetsuo Handa > Signed-off-by: Dan Williams Thanks for catching that. I have really missed it during review. Sorry about that. Acked-by: Michal Hocko > --- > Hi Andrew, > > Please fold this into > mm-move-buddy-list-manipulations-into-helpers.patch. > > mm/page_alloc.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 2a0969e3b0eb..da537fc39c54 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1851,7 +1851,6 @@ static inline void expand(struct zone *zone, struct > page *page, > continue; > > add_to_free_area(&page[size], area, migratetype); > - area->nr_free++; > set_page_order(&page[size], high); > } > } > -- Michal Hocko SUSE Labs
Re: [PATCH v3] x86/ima: require signed kernel modules
+++ Mimi Zohar [15/02/19 11:50 -0500]:
Have the IMA architecture specific policy require signed kernel modules
on systems with secure boot mode enabled; and coordinate the different
signature verification methods, so only one signature is required.
Requiring appended kernel module signatures may be configured, enabled
on the boot command line, or with this patch enabled in secure boot
mode. This patch defines set_module_sig_enforced().
To coordinate between appended kernel module signatures and IMA
signatures, only define an IMA MODULE_CHECK policy rule if
CONFIG_MODULE_SIG is not enabled. A custom IMA policy may still define
and require an IMA signature.
Signed-off-by: Mimi Zohar
Acked-by: Jessica Yu
Thanks!
---
arch/x86/kernel/ima_arch.c | 9 -
include/linux/module.h | 5 +
kernel/module.c| 5 +
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/ima_arch.c b/arch/x86/kernel/ima_arch.c
index e47cd9390ab4..3fb9847f1cad 100644
--- a/arch/x86/kernel/ima_arch.c
+++ b/arch/x86/kernel/ima_arch.c
@@ -64,12 +64,19 @@ static const char * const sb_arch_rules[] = {
"appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig",
#endif /* CONFIG_KEXEC_VERIFY_SIG */
"measure func=KEXEC_KERNEL_CHECK",
+#if !IS_ENABLED(CONFIG_MODULE_SIG)
+ "appraise func=MODULE_CHECK appraise_type=imasig",
+#endif
+ "measure func=MODULE_CHECK",
NULL
};
const char * const *arch_get_ima_policy(void)
{
- if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot())
+ if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
+ if (IS_ENABLED(CONFIG_MODULE_SIG))
+ set_module_sig_enforced();
return sb_arch_rules;
+ }
return NULL;
}
diff --git a/include/linux/module.h b/include/linux/module.h
index 8fa38d3e7538..5aaa9359adc8 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -660,6 +660,7 @@ static inline bool is_livepatch_module(struct module *mod)
#endif /* CONFIG_LIVEPATCH */
bool is_module_sig_enforced(void);
+void set_module_sig_enforced(void);
#else /* !CONFIG_MODULES... */
@@ -780,6 +781,10 @@ static inline bool is_module_sig_enforced(void)
return false;
}
+static inline void set_module_sig_enforced(void)
+{
+}
+
/* Dereference module function descriptor */
static inline
void *dereference_module_function_descriptor(struct module *mod, void *ptr)
diff --git a/kernel/module.c b/kernel/module.c
index 2ad1b5239910..73cada04bd24 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -286,6 +286,11 @@ bool is_module_sig_enforced(void)
}
EXPORT_SYMBOL(is_module_sig_enforced);
+void set_module_sig_enforced(void)
+{
+ sig_enforce = true;
+}
+
/* Block module loading/unloading? */
int modules_disabled = 0;
core_param(nomodule, modules_disabled, bint, 0);
--
2.7.5
Re: [PATCH v7 3/6] dt-bindings: pinctrl: mt8183: add binding document
On Fri, 2019-02-15 at 10:35 +0100, Matthias Brugger wrote:
>
> On 15/02/2019 07:02, Erin Lo wrote:
> > From: Zhiyong Tao
> >
> > The commit adds mt8183 compatible node in binding document.
> >
> > Signed-off-by: Zhiyong Tao
> > Signed-off-by: Erin Lo
> > ---
> > .../devicetree/bindings/pinctrl/pinctrl-mt8183.txt | 115
> > +
> > 1 file changed, 115 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
> > b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
> > new file mode 100644
> > index 000..364e673
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
> > @@ -0,0 +1,115 @@
> > +* Mediatek MT8183 Pin Controller
> > +
> > +The Mediatek's Pin controller is used to control SoC pins.
> > +
> > +Required properties:
> > +- compatible: value should be one of the following.
> > + "mediatek,mt8183-pinctrl", compatible with mt8183 pinctrl.
> > +- gpio-controller : Marks the device node as a gpio controller.
> > +- #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
> > + binding is used, the amount of cells must be specified as 2. See the
> > below
> > + mentioned gpio binding representation for description of particular
> > cells.
> > +- gpio-ranges : gpio valid number range.
> > +- reg: physicall address base for gpio base registers. There are nine
>
> s/physicall/physical
==>we will modify it.
>
> > + physicall address base in mt8183. They are 0x10005000, 0x11F2,
> > + 0x11E8, 0x11E7, 0x11E9, 0x11D3, 0x11D2, 0x11C5,
> > + 0x11F3.
> > +
> > + Eg: <&pio 6 0>
> > + <[phandle of the gpio controller node]
> > + [line number within the gpio controller]
> > + [flags]>
> > +
> > + Values for gpio specifier:
> > + - Line number: is a value between 0 to 202.
> > + - Flags: bit field of flags, as defined in .
> > +Only the following flags are supported:
> > +0 - GPIO_ACTIVE_HIGH
> > +1 - GPIO_ACTIVE_LOW
> > +
> > +Optional properties:
> > +- reg-names: gpio base register names. There are nine gpio base register
> > + names in mt8183. They are "iocfg0", "iocfg1", "iocfg2", "iocfg3",
> > "iocfg4",
> > + "iocfg5", "iocfg6", "iocfg7", "iocfg8".
> > +- interrupt-controller: Marks the device node as an interrupt controller
> > +- #interrupt-cells: Should be two.
> > +- interrupts : The interrupt outputs from the controller.
>
> we are missing interrupt-parent here.
==> we will add it in next version. we will add like this:
- interrupts-parents : The interrupt connector. In mt8183, it is sysirq.
>
> > +
> > +Please refer to pinctrl-bindings.txt in this directory for details of the
> > +common pinctrl bindings used by client devices.
> > +
> > +Subnode format
> > +A pinctrl node should contain at least one subnodes representing the
> > +pinctrl groups available on the machine. Each subnode will list the
> > +pins it needs, and how they should be configured, with regard to muxer
> > +configuration, pullups, drive strength, input enable/disable and input
> > schmitt.
> > +
> > +node {
> > + pinmux = ;
> > + GENERIC_PINCONFIG;
> > +};
> > +
> > +Required properties:
> > +- pinmux: integer array, represents gpio pin number and mux setting.
> > +Supported pin number and mux varies for different SoCs, and are defined
> > +as macros in boot/dts/-pinfunc.h directly.
> > +
> > +Optional properties:
> > +- GENERIC_PINCONFIG: is the generic pinconfig options to use, bias-disable,
> > +bias-pull-down, bias-pull-up, input-enable, input-disable, output-low,
> > output-high,
> > +input-schmitt-enable, input-schmitt-disable and drive-strength are
> > valid.
> > +
> > +Some special pins have extra pull up strength, there are R0 and R1
> > pull-up
> > +resistors available, but for user, it's only need to set R1R0 as 00,
> > 01, 10 or 11.
> > +So when config mediatek,pull-up-adv or mediatek,pull-down-adv,
> > +it support arguments for those special pins.
>
> I wonder if we should mention which this special pins are. A look at the
> driver
> told me that it is not possible to know that by reading the source code
> neither.
> Linus, what do you think?
>
> What about mediatek,tdsel and mediatek,rdsel? They are not supported?
>
> Wouldn't it make sense to have one binding description for paris and then just
> create SoC specifics bindings?
==> It can support mediatek,tdsel and mediatek,rdsel in mt8183 design.
I will try to create one new binding description and separate it from
soc specifics bindings.
>
> > +
> > +When config drive-strength, it can support some arguments, such as
> > +MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See dt-bindings/pinctrl/mt65xx.h.
>
> It can support all drive strength defined in that header file, 2, 4, 6, 8, 10,
> 12, 14, 16, 20, 24, 28
Re: next/master boot bisection: next-20190215 on beaglebone-black
On Fri 15-02-19 10:20:10, kernelci.org bot wrote: > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * This automated bisection report was sent to you on the basis * > * that you may be involved with the breaking commit it has * > * found. No manual investigation has been done to verify it, * > * and the root cause of the problem may be somewhere else. * > * Hope this helps! * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > next/master boot bisection: next-20190215 on beaglebone-black > > Summary: > Start: 7a92eb7cc1dc Add linux-next specific files for 20190215 > Details:https://kernelci.org/boot/id/5c666ea959b514b017fe6017 > Plain log: > https://storage.kernelci.org//next/master/next-20190215/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-7/lab-collabora/boot-am335x-boneblack.txt > HTML log: > https://storage.kernelci.org//next/master/next-20190215/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-7/lab-collabora/boot-am335x-boneblack.html > Result: 8dd037cc97d9 mm/shuffle: default enable all shuffling Does http://lkml.kernel.org/r/155033679702.1773410.13041474192173212653.st...@dwillia2-desk3.amr.corp.intel.com make any difference? -- Michal Hocko SUSE Labs
Re: [PATCH -next] ASoC: wm8741: Make function 'wm8741_mute' static
On Sat, Feb 16, 2019 at 01:35:56AM +, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> sound/soc/codecs/wm8741.c:371:5: warning:
> symbol 'wm8741_mute' was not declared. Should it be static?
>
> Fixes: 36b1599340b5 ("ASoC: wm8741: Add digital mute callback")
> Signed-off-by: Wei Yongjun
> ---
Acked-by: Charles Keepax
Thanks,
Charles
Re: [PATCH v7 1/3] thermal: tegra: remove unnecessary warnings
On 03/01/2019 11:12, Wei Ni wrote:
> Convert warnings to info as not all platforms may
> have all the thresholds and sensors enabled.
>
> Signed-off-by: Wei Ni
> ---
Reviewed-by: Daniel Lezcano
> drivers/thermal/tegra/soctherm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/tegra/soctherm.c
> b/drivers/thermal/tegra/soctherm.c
> index ed28110a3535..f07de8258e93 100644
> --- a/drivers/thermal/tegra/soctherm.c
> +++ b/drivers/thermal/tegra/soctherm.c
> @@ -569,7 +569,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
> set_throttle:
> ret = get_hot_temp(tz, &trip, &temperature);
> if (ret) {
> - dev_warn(dev, "throttrip: %s: missing hot temperature\n",
> + dev_info(dev, "throttrip: %s: missing hot temperature\n",
>sg->name);
> return 0;
> }
> @@ -600,7 +600,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
> }
>
> if (i == THROTTLE_SIZE)
> - dev_warn(dev, "throttrip: %s: missing throttle cdev\n",
> + dev_info(dev, "throttrip: %s: missing throttle cdev\n",
>sg->name);
>
> return 0;
>
--
Facebook |
Twitter |
Re: [PATCH] drivers: mux: Generic register bitfield-based multiplexer driver
Hi!
On 2019-02-18 06:40, Pankaj Bansal wrote:
> Generic register bitfield-based multiplexer driver that controls the
> multiplexer producer defined under a parent node.
> The driver corresponding to parent node provides register read/write
> capabilities.
This driver is just a rename of drivers/mux/mmio.c with a one-liner on
top. And there's a license change too. That's obnoxious. Please keep
this as GPL v2. Not that I /think/ Philipp nor Pengutronix cares deeply,
but what do I know? Changing the license as you copy the code is simply
not all right.
Anyway, I would prefer if you could extend drivers/mux/mmio.c to support
both compatibles, and using the compatible to select if
regmap = syscon_node_to_regmap(np->parent);
or
regmap = dev_get_regmap(dev->parent, NULL);
is called to get to the desired regmap.
Philipp, you don't object to extending the mmio driver, right?
Or are there more differences that I failed to notice?
Cheers,
Peter
>
> Signed-off-by: Pankaj Bansal
> ---
>
> Notes:
> Dependencies:
> - https://patchwork.ozlabs.org/patch/1043790/
>
> drivers/mux/Kconfig | 13
> drivers/mux/Makefile | 2 +
> drivers/mux/regmap.c | 139 +
> 3 files changed, 154 insertions(+)
>
> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> index 7659d6c5f718..a412d0955258 100644
> --- a/drivers/mux/Kconfig
> +++ b/drivers/mux/Kconfig
> @@ -58,4 +58,17 @@ config MUX_MMIO
> To compile the driver as a module, choose M here: the module will
> be called mux-mmio.
>
> +config MUX_REGMAP
> + tristate "Regmap register bitfield-controlled Multiplexer"
> + depends on (OF && REGMAP) || COMPILE_TEST
> + help
> + Regmap register bitfield-controlled Multiplexer controller.
> +
> + The driver builds multiplexer controllers for bitfields in a regmap
> + device register. For N bit wide bitfields, there will be 2^N possible
> + multiplexer states.
> +
> + To compile the driver as a module, choose M here: the module will
> + be called regmap-mmio.
> +
> endmenu
> diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
> index 6e9fa47daf56..ae1bafac0cbd 100644
> --- a/drivers/mux/Makefile
> +++ b/drivers/mux/Makefile
> @@ -8,9 +8,11 @@ mux-adg792a-objs := adg792a.o
> mux-adgs1408-objs:= adgs1408.o
> mux-gpio-objs:= gpio.o
> mux-mmio-objs:= mmio.o
> +mux-regmap-objs := regmap.o
>
> obj-$(CONFIG_MULTIPLEXER)+= mux-core.o
> obj-$(CONFIG_MUX_ADG792A)+= mux-adg792a.o
> obj-$(CONFIG_MUX_ADGS1408) += mux-adgs1408.o
> obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
> obj-$(CONFIG_MUX_MMIO) += mux-mmio.o
> +obj-$(CONFIG_MUX_REGMAP) += mux-regmap.o
> diff --git a/drivers/mux/regmap.c b/drivers/mux/regmap.c
> new file mode 100644
> index ..c2156302929a
> --- /dev/null
> +++ b/drivers/mux/regmap.c
> @@ -0,0 +1,139 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Regmap register bitfield-controlled multiplexer driver
> + *
> + * Based on drivers/mux/mmio.c
> + *
> + * Copyright 2019 NXP
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int mux_regmap_set(struct mux_control *mux, int state)
> +{
> + struct regmap_field **fields = mux_chip_priv(mux->chip);
> +
> + return regmap_field_write(fields[mux_control_get_index(mux)], state);
> +}
> +
> +static const struct mux_control_ops mux_regmap_ops = {
> + .set = mux_regmap_set,
> +};
> +
> +static const struct of_device_id mux_regmap_dt_ids[] = {
> + { .compatible = "reg-mux", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mux_regmap_dt_ids);
> +
> +static int mux_regmap_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + struct regmap_field **fields;
> + struct mux_chip *mux_chip;
> + struct regmap *regmap;
> + int num_fields;
> + int ret;
> + int i;
> +
> + regmap = dev_get_regmap(dev->parent, NULL);
> + if (IS_ERR(regmap)) {
> + ret = PTR_ERR(regmap);
> + dev_err(dev, "failed to get regmap: %d\n", ret);
> + return ret;
> + }
> +
> + ret = of_property_count_u32_elems(np, "mux-reg-masks");
> + if (ret == 0 || ret % 2)
> + ret = -EINVAL;
> + if (ret < 0) {
> + dev_err(dev, "mux-reg-masks property missing or invalid: %d\n",
> + ret);
> + return ret;
> + }
> + num_fields = ret / 2;
> +
> + mux_chip = devm_mux_chip_alloc(dev, num_fields, num_fields *
> +sizeof(*fields));
> + if (IS_ERR(mux_chip))
> + return PTR_ERR(mux_chip);
> +
> + fields = mux_chip_priv(mux_chip);
> +
> + for (i = 0; i < num_f
[PATCH 5/6] gpio: mockup: change the signature of unlocked get/set helpers
From: Bartosz Golaszewski
The unlocked variants only get called from places where we already have
the pointer to the underlying gpio_mockup_chip structure, so take it
as parameter instead of struct gpio_chip.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-mockup.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index 433adb3b4617..c498b0fbbec8 100644
--- a/drivers/gpio/gpio-mockup.c
+++ b/drivers/gpio/gpio-mockup.c
@@ -83,10 +83,9 @@ static int gpio_mockup_range_ngpio(unsigned int index)
return gpio_mockup_ranges[index * 2 + 1];
}
-static int __gpio_mockup_get(struct gpio_chip *gc, unsigned int offset)
+static int __gpio_mockup_get(struct gpio_mockup_chip *chip,
+unsigned int offset)
{
- struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
-
return chip->lines[offset].value;
}
@@ -96,7 +95,7 @@ static int gpio_mockup_get(struct gpio_chip *gc, unsigned int
offset)
int val;
mutex_lock(&chip->lock);
- val = __gpio_mockup_get(gc, offset);
+ val = __gpio_mockup_get(chip, offset);
mutex_unlock(&chip->lock);
return val;
@@ -110,7 +109,7 @@ static int gpio_mockup_get_multiple(struct gpio_chip *gc,
mutex_lock(&chip->lock);
for_each_set_bit(bit, mask, gc->ngpio) {
- val = __gpio_mockup_get(gc, bit);
+ val = __gpio_mockup_get(chip, bit);
__assign_bit(bit, bits, val);
}
mutex_unlock(&chip->lock);
@@ -118,11 +117,9 @@ static int gpio_mockup_get_multiple(struct gpio_chip *gc,
return 0;
}
-static void __gpio_mockup_set(struct gpio_chip *gc,
+static void __gpio_mockup_set(struct gpio_mockup_chip *chip,
unsigned int offset, int value)
{
- struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
-
chip->lines[offset].value = !!value;
}
@@ -132,7 +129,7 @@ static void gpio_mockup_set(struct gpio_chip *gc,
struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
mutex_lock(&chip->lock);
- __gpio_mockup_set(gc, offset, value);
+ __gpio_mockup_set(chip, offset, value);
mutex_unlock(&chip->lock);
}
@@ -144,7 +141,7 @@ static void gpio_mockup_set_multiple(struct gpio_chip *gc,
mutex_lock(&chip->lock);
for_each_set_bit(bit, mask, gc->ngpio)
- __gpio_mockup_set(gc, bit, test_bit(bit, bits));
+ __gpio_mockup_set(chip, bit, test_bit(bit, bits));
mutex_unlock(&chip->lock);
}
@@ -155,7 +152,7 @@ static int gpio_mockup_dirout(struct gpio_chip *gc,
mutex_lock(&chip->lock);
chip->lines[offset].dir = GPIO_MOCKUP_DIR_OUT;
- __gpio_mockup_set(gc, offset, value);
+ __gpio_mockup_set(chip, offset, value);
mutex_unlock(&chip->lock);
return 0;
--
2.20.1
[PATCH 4/6] gpio: mockup: change the type of 'offset' to unsigned int
From: Bartosz Golaszewski
This field can never be negative.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-mockup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index 0317917a3678..433adb3b4617 100644
--- a/drivers/gpio/gpio-mockup.c
+++ b/drivers/gpio/gpio-mockup.c
@@ -60,7 +60,7 @@ struct gpio_mockup_chip {
struct gpio_mockup_dbgfs_private {
struct gpio_mockup_chip *chip;
struct gpio_desc *desc;
- int offset;
+ unsigned int offset;
};
static int gpio_mockup_ranges[GPIO_MOCKUP_MAX_RANGES];
--
2.20.1
[PATCH 2/6] gpio: mockup: implement get_multiple()
From: Bartosz Golaszewski
We already support set_multiple(). Implement get_multiple() as well.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-mockup.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index b4c1de6acf74..1c945c967f60 100644
--- a/drivers/gpio/gpio-mockup.c
+++ b/drivers/gpio/gpio-mockup.c
@@ -102,6 +102,22 @@ static int gpio_mockup_get(struct gpio_chip *gc, unsigned
int offset)
return val;
}
+static int gpio_mockup_get_multiple(struct gpio_chip *gc,
+ unsigned long *mask, unsigned long *bits)
+{
+ struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
+ unsigned int bit, val;
+
+ mutex_lock(&chip->lock);
+ for_each_set_bit(bit, mask, gc->ngpio) {
+ val = __gpio_mockup_get(gc, bit);
+ __assign_bit(bit, bits, val);
+ }
+ mutex_unlock(&chip->lock);
+
+ return 0;
+}
+
static void __gpio_mockup_set(struct gpio_chip *gc,
unsigned int offset, int value)
{
@@ -327,6 +343,7 @@ static int gpio_mockup_probe(struct platform_device *pdev)
gc->parent = dev;
gc->get = gpio_mockup_get;
gc->set = gpio_mockup_set;
+ gc->get_multiple = gpio_mockup_get_multiple;
gc->set_multiple = gpio_mockup_set_multiple;
gc->direction_output = gpio_mockup_dirout;
gc->direction_input = gpio_mockup_dirin;
--
2.20.1
[PATCH 0/6] gpio: mockup: rework the testing driver - alternative version
From: Bartosz Golaszewski It's very late in the release cycle and we cannot seem to get the irq subsystem maintainers' ack on the proposed change in the interrupt simulator. This series contains only the gpio-mockup patches from the previous submission in order to at least partially track the line's state and add a way to verify the results of uAPI calls. The interrupts are fired regardless of their type configuration. This will be fixed once irq_sim supports it. Bartosz Golaszewski (6): gpio: mockup: add locking gpio: mockup: implement get_multiple() gpio: mockup: don't create the debugfs link named after the label gpio: mockup: change the type of 'offset' to unsigned int gpio: mockup: change the signature of unlocked get/set helpers gpio: mockup: rework debugfs interface drivers/gpio/gpio-mockup.c | 188 +++-- 1 file changed, 161 insertions(+), 27 deletions(-) -- 2.20.1
[PATCH 3/6] gpio: mockup: don't create the debugfs link named after the label
From: Bartosz Golaszewski
User-space tests no longer use it and we're breaking the interface
anyway.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-mockup.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index 1c945c967f60..0317917a3678 100644
--- a/drivers/gpio/gpio-mockup.c
+++ b/drivers/gpio/gpio-mockup.c
@@ -234,7 +234,7 @@ static void gpio_mockup_debugfs_setup(struct device *dev,
struct gpio_mockup_chip *chip)
{
struct gpio_mockup_dbgfs_private *priv;
- struct dentry *evfile, *link;
+ struct dentry *evfile;
struct gpio_chip *gc;
const char *devname;
char *name;
@@ -247,10 +247,6 @@ static void gpio_mockup_debugfs_setup(struct device *dev,
if (IS_ERR_OR_NULL(chip->dbg_dir))
goto err;
- link = debugfs_create_symlink(gc->label, gpio_mockup_dbg_dir, devname);
- if (IS_ERR_OR_NULL(link))
- goto err;
-
for (i = 0; i < gc->ngpio; i++) {
name = devm_kasprintf(dev, GFP_KERNEL, "%d", i);
if (!name)
--
2.20.1
[PATCH 6/6] gpio: mockup: rework debugfs interface
From: Bartosz Golaszewski
Modify the way the debugfs interface works in gpio-mockup. Introduce
the concept of dummy pull config which will keep the mockup lines in
known state. The pull values can be modified by writing to the debugfs
files corresponding to lines. Lines in input mode always report the
current pull value, lines in output mode change the line value but
it will revert back to the one specified by current pull when released.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-mockup.c | 116 -
1 file changed, 102 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index c498b0fbbec8..72f5c07c4219 100644
--- a/drivers/gpio/gpio-mockup.c
+++ b/drivers/gpio/gpio-mockup.c
@@ -47,6 +47,7 @@ enum {
struct gpio_mockup_line_status {
int dir;
int value;
+ int pull;
};
struct gpio_mockup_chip {
@@ -188,15 +189,56 @@ static int gpio_mockup_to_irq(struct gpio_chip *gc,
unsigned int offset)
return irq_sim_irqnum(&chip->irqsim, offset);
}
-static ssize_t gpio_mockup_event_write(struct file *file,
- const char __user *usr_buf,
- size_t size, loff_t *ppos)
+static void gpio_mockup_free(struct gpio_chip *gc, unsigned int offset)
+{
+ struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
+
+ __gpio_mockup_set(chip, offset, chip->lines[offset].pull);
+}
+
+static ssize_t gpio_mockup_debugfs_read(struct file *file,
+ char __user *usr_buf,
+ size_t size, loff_t *ppos)
+{
+ struct gpio_mockup_dbgfs_private *priv;
+ struct gpio_mockup_chip *chip;
+ struct seq_file *sfile;
+ struct gpio_chip *gc;
+ char buf[3];
+ int val, rv;
+
+ if (*ppos != 0)
+ return 0;
+
+ sfile = file->private_data;
+ priv = sfile->private;
+ chip = priv->chip;
+ gc = &chip->gc;
+
+ val = gpio_mockup_get(gc, priv->offset);
+ snprintf(buf, sizeof(buf), "%d\n", val);
+
+ rv = copy_to_user(usr_buf, buf, sizeof(buf));
+ if (rv)
+ return rv;
+
+ return sizeof(buf) - 1;
+}
+
+static ssize_t gpio_mockup_debugfs_write(struct file *file,
+const char __user *usr_buf,
+size_t size, loff_t *ppos)
{
struct gpio_mockup_dbgfs_private *priv;
struct gpio_mockup_chip *chip;
struct seq_file *sfile;
struct gpio_desc *desc;
- int rv, val;
+ struct gpio_chip *gc;
+ struct irq_sim *sim;
+ int rv, val, curr;
+
+ if (*ppos != 0)
+ return -EINVAL;
rv = kstrtoint_from_user(usr_buf, size, 0, &val);
if (rv)
@@ -206,24 +248,69 @@ static ssize_t gpio_mockup_event_write(struct file *file,
sfile = file->private_data;
priv = sfile->private;
- desc = priv->desc;
chip = priv->chip;
+ gc = &chip->gc;
+ desc = &gc->gpiodev->descs[priv->offset];
+ sim = &chip->irqsim;
+
+ mutex_lock(&chip->lock);
+
+ if (test_bit(FLAG_REQUESTED, &desc->flags) &&
+ !test_bit(FLAG_IS_OUT, &desc->flags)) {
+ curr = __gpio_mockup_get(chip, priv->offset);
+ if (curr == val)
+ goto out;
+
+ /*
+* FIXME: fire edge interrupts according to the type
+* configuration once irq_sim supports this.
+*/
+ irq_sim_fire(&chip->irqsim, priv->offset);
+ }
- gpiod_set_value_cansleep(desc, val);
- irq_sim_fire(&chip->irqsim, priv->offset);
+ /* Change the value unless we're actively driving the line. */
+ if (!test_bit(FLAG_REQUESTED, &desc->flags) ||
+ !test_bit(FLAG_IS_OUT, &desc->flags))
+ __gpio_mockup_set(chip, priv->offset, val);
+
+out:
+ chip->lines[priv->offset].pull = val;
+ mutex_unlock(&chip->lock);
return size;
}
-static int gpio_mockup_event_open(struct inode *inode, struct file *file)
+static int gpio_mockup_debugfs_open(struct inode *inode, struct file *file)
{
return single_open(file, NULL, inode->i_private);
}
-static const struct file_operations gpio_mockup_event_ops = {
+/*
+ * Each mockup chip is represented by a directory named after the chip's device
+ * name under /sys/kernel/debug/gpio-mockup/. Each line is represented by
+ * a file using the line's offset as the name under the chip's directory.
+ *
+ * Reading from the line's file yields the current *value*, writing to the
+ * line's file changes the current *pull*. Default pull for mockup lines is
+ * down.
+ *
+ * Examples:
+ * - when a line pulled down is requested in output mode and driven high, its
+ * value will return to 0 once it's released
+ * - when the line is re
[PATCH 1/6] gpio: mockup: add locking
From: Bartosz Golaszewski
While no user reported any race condition problems with gpio-mockup,
let's be on the safe side and use a mutex when performing any changes
on the dummy chip structures.
Suggested-by: Uwe Kleine-König
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-mockup.c | 50 --
1 file changed, 43 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index 6a50f9f59c90..b4c1de6acf74 100644
--- a/drivers/gpio/gpio-mockup.c
+++ b/drivers/gpio/gpio-mockup.c
@@ -54,6 +54,7 @@ struct gpio_mockup_chip {
struct gpio_mockup_line_status *lines;
struct irq_sim irqsim;
struct dentry *dbg_dir;
+ struct mutex lock;
};
struct gpio_mockup_dbgfs_private {
@@ -82,29 +83,53 @@ static int gpio_mockup_range_ngpio(unsigned int index)
return gpio_mockup_ranges[index * 2 + 1];
}
-static int gpio_mockup_get(struct gpio_chip *gc, unsigned int offset)
+static int __gpio_mockup_get(struct gpio_chip *gc, unsigned int offset)
{
struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
return chip->lines[offset].value;
}
-static void gpio_mockup_set(struct gpio_chip *gc,
- unsigned int offset, int value)
+static int gpio_mockup_get(struct gpio_chip *gc, unsigned int offset)
+{
+ struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
+ int val;
+
+ mutex_lock(&chip->lock);
+ val = __gpio_mockup_get(gc, offset);
+ mutex_unlock(&chip->lock);
+
+ return val;
+}
+
+static void __gpio_mockup_set(struct gpio_chip *gc,
+ unsigned int offset, int value)
{
struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
chip->lines[offset].value = !!value;
}
+static void gpio_mockup_set(struct gpio_chip *gc,
+ unsigned int offset, int value)
+{
+ struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
+
+ mutex_lock(&chip->lock);
+ __gpio_mockup_set(gc, offset, value);
+ mutex_unlock(&chip->lock);
+}
+
static void gpio_mockup_set_multiple(struct gpio_chip *gc,
unsigned long *mask, unsigned long *bits)
{
+ struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
unsigned int bit;
+ mutex_lock(&chip->lock);
for_each_set_bit(bit, mask, gc->ngpio)
- gpio_mockup_set(gc, bit, test_bit(bit, bits));
-
+ __gpio_mockup_set(gc, bit, test_bit(bit, bits));
+ mutex_unlock(&chip->lock);
}
static int gpio_mockup_dirout(struct gpio_chip *gc,
@@ -112,8 +137,10 @@ static int gpio_mockup_dirout(struct gpio_chip *gc,
{
struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
- gpio_mockup_set(gc, offset, value);
+ mutex_lock(&chip->lock);
chip->lines[offset].dir = GPIO_MOCKUP_DIR_OUT;
+ __gpio_mockup_set(gc, offset, value);
+ mutex_unlock(&chip->lock);
return 0;
}
@@ -122,7 +149,9 @@ static int gpio_mockup_dirin(struct gpio_chip *gc, unsigned
int offset)
{
struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
+ mutex_lock(&chip->lock);
chip->lines[offset].dir = GPIO_MOCKUP_DIR_IN;
+ mutex_unlock(&chip->lock);
return 0;
}
@@ -130,8 +159,13 @@ static int gpio_mockup_dirin(struct gpio_chip *gc,
unsigned int offset)
static int gpio_mockup_get_direction(struct gpio_chip *gc, unsigned int offset)
{
struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
+ int direction;
- return !chip->lines[offset].dir;
+ mutex_lock(&chip->lock);
+ direction = !chip->lines[offset].dir;
+ mutex_unlock(&chip->lock);
+
+ return direction;
}
static int gpio_mockup_to_irq(struct gpio_chip *gc, unsigned int offset)
@@ -283,6 +317,8 @@ static int gpio_mockup_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ mutex_init(&chip->lock);
+
gc = &chip->gc;
gc->base = base;
gc->ngpio = ngpio;
--
2.20.1
Re: [PATCH 0/4] provide a generic free_initmem implementation
On Thu, Feb 14, 2019 at 08:38:55PM +0200, Mike Rapoport wrote: > On Thu, Feb 14, 2019 at 06:04:16PM +0100, Christoph Hellwig wrote: > > This look fine to me, but I'm a little worried that as-is this will > > just create conflicts with my series.. > > I'll rebase on top of your patches once they are in. Or I can send both > series as a single set. > Preferences? So far there wasn't really much a reason to rebase my series, hope this gets picked up either by Andrew or Al (not sure what the right place is). I think for now just rebase your series on top, we can then figure out how to proceed.
