[patch] ib_srpt: fix a WARN_ON() message
The first argument of WARN_ON() is a condition, so it means the warning
message here will just be the name without the ->qp_num information.
Signed-off-by: Dan Carpenter
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c
b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 1d13090..0bd3cb2 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -839,7 +839,7 @@ static void srpt_zerolength_write_done(struct ib_cq *cq,
struct ib_wc *wc)
if (srpt_set_ch_state(ch, CH_DISCONNECTED))
schedule_work(>release_work);
else
- WARN_ONCE("%s-%d\n", ch->sess_name, ch->qp->qp_num);
+ WARN_ONCE(1, "%s-%d\n", ch->sess_name, ch->qp->qp_num);
}
}
Re: [PATCH v3 0/2] Livepatch module notifier cleanup
On Wed, 16 Mar 2016, Jessica Yu wrote:
> These are the remaining 2 patches that came from the original ftrace/livepatch
> module notifier patchset found here: https://lkml.org/lkml/2016/2/8/1180
>
> Basically, the patchset does a bit of module.c cleanup (patch 1) in
> preparation for the klp_module_{coming,going} calls (patch 2). We decided
> to stop relying on the module notifier callchain in favor of hard-coding
> the appropriate livepatch function calls that handle coming and going
> modules. Hard-coding these calls will guarantee that ftrace and livepatch
> exit/initialization routines are called in the correct order without
> relying on module notifiers.
>
> The patches should be nearly exactly the same as those from the previous
> discussion, except in patch 2 I've added back the #if
> IS_ENABLED(CONFIG_LIVEPATCH)
> guard in livepatch.h.
>
> Patches based on linux-next.
>
> v2 discussion found here:
> https://lkml.kernel.org/g/1457726628-9171-1-git-send-email-j...@redhat.com
>
> v3:
> - Remove confusing comment above klp_module_going()
> - Place prepare_coming_module() after complete_formation()
> - Fix small race in klp_module_coming() by setting mod->klp_alive
>to false in the error path
I've applied v3 to for-4.6/notifier-cleanup.
Thanks!
--
Jiri Kosina
SUSE Labs
Re: [PATCH 1/4] vfs: add file_dentry()
On Thu, Mar 17, 2016 at 11:15 AM, Sedat Dilek wrote:
> On Thu, Mar 17, 2016 at 10:33 AM, Miklos Szeredi wrote:
>> On Thu, Mar 17, 2016 at 10:09 AM, Sedat Dilek wrote:
>>> On Thu, Mar 17, 2016 at 10:02 AM, Miklos Szeredi wrote:
From: Miklos Szeredi
This series fixes bugs in nfs and ext4 due to 4bacc9c9234c ("overlayfs:
Make
f_path always point to the overlay and f_inode to the underlay").
>>>
>>> Can you put that series in your vfs.git tree?
>>> Easier for getting and testing.
>>
>> Ok, pushed to:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git file_dentry
>>
>
> Is that correct the ext4-related patches 3/4 and 4/4 are Linux-v4.5 material?
> Not applicable fpr v4.4.y-stable?
>
Sorry, for disturbing again - parallelly building some other software
which needs my attention.
Why didn't you split 1/4 into a vfs (generic) part and overlayfs (related) part?
Thinking of bisecting or backporting ovl fixes.
Just my €0,02.
- Sedat -
Re: [PATCH] net: mvneta: bm: clarify dependencies
From: Arnd Bergmann
Date: Tue, 15 Mar 2016 22:47:14 +0100
> MVNETA_BM has a dependency on MVNETA, so we can only select the former
> if the latter is enabled. However, the code dependency is the reverse:
> The mvneta module can call into the mvneta_bm module, so mvneta cannot
> be a built-in if mvneta_bm is a module, or we get a link error:
>
> drivers/net/built-in.o: In function `mvneta_remove':
> drivers/net/ethernet/marvell/mvneta.c:4211: undefined reference to
> `mvneta_bm_pool_destroy'
> drivers/net/built-in.o: In function `mvneta_bm_update_mtu':
> drivers/net/ethernet/marvell/mvneta.c:1034: undefined reference to
> `mvneta_bm_bufs_free'
>
> This avoids the problem by further clarifying the dependency so that
> MVNETA_BM is a silent Kconfig option that gets turned on by the
> new MVNETA_BM_ENABLE option. This way both the core HWBM module and
> the MVNETA_BM code are always built-in when needed.
>
> Signed-off-by: Arnd Bergmann
> Fixes: dc35a10f68d3 ("net: mvneta: bm: add support for hardware buffer
> management")
Applied.
Re: [GIT PULL] USB driver patches for 4.6-rc1
On Fri, Mar 18, 2016 at 2:43 PM, Linus Torvalds wrote: > > Something in this - or possibly the tty pull, but that doesn't sound > very likely - has killed my USB keyboard on my desktop. Yeah, the bisect is now solidly in the usb part. The machine has 00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31) 03:00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller and the keyboard and mouse are on /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M which seems to be that ASMedia 3.1 controller. In case that gives anybody a clue while I continue bisecting. Linus
Re: arch/x86/um/user-offsets.c:8:24: fatal error: asm/ptrace.h: No such file or directory
On Mon, Mar 14, 2016 at 09:53:06AM +0900, Krzysztof Kozlowski wrote:
> On Sun, Mar 13, 2016 at 7:45 AM, kbuild test robot
> wrote:
> > Hi Al,
> >
> > FYI, the error/warning still remains.
> >
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > head: 03c668a93187fe7fba9464f96fbe7c22eebd9897
> > commit: 5c48b108ecbf6505d929e64d50dace13ac2bdf34 um: take arch/um/sys-x86
> > to arch/x86/um
> > date: 4 years, 4 months ago
> > config: um-i386_defconfig (attached as .config)
> > reproduce:
> > git checkout 5c48b108ecbf6505d929e64d50dace13ac2bdf34
> > # save the attached .config to linux build tree
> > make ARCH=um SUBARCH=i386
> >
>
> Hi,
>
> The code is correct. The build machine lacks asm/ptrace.h for i386
> (e.g. /usr/include/i386-linux-gnu/asm/ptrace.h). For example on Ubuntu
> this is provided by linux-libc-dev:i386.
sorry for late response, we have installed linux-libc-dev:i386 on our build
environment to have this head file.
Thanks
>
> Best regards,
> Krzysztof
>
>
> > All errors (new ones prefixed by >>):
> >
> >>> arch/x86/um/user-offsets.c:8:24: fatal error: asm/ptrace.h: No such file
> >>> or directory
> >compilation terminated.
> >make[2]: *** [arch/x86/um/user-offsets.s] Error 1
> >make[1]: *** [arch/x86/um/user-offsets.s] Error 2
> >make[1]: Target 'prepare' not remade because of errors.
> >make: *** [sub-make] Error 2
> >
> > vim +8 arch/x86/um/user-offsets.c
> >
> > 8d0b9dc9be arch/um/sys-x86_64/user-offsets.c Al Viro 2005-05-05 1
> > #include
> > 8d0b9dc9be arch/um/sys-x86_64/user-offsets.c Al Viro 2005-05-05 2
> > #include
> > 8d0b9dc9be arch/um/sys-x86_64/user-offsets.c Al Viro 2005-05-05 3
> > #include
> > 63ae2a94d9 arch/um/sys-x86_64/user-offsets.c Jeff Dike 2006-03-27 4
> > #include
> > 16dd07bc64 arch/um/sys-x86_64/user-offsets.c Jeff Dike 2007-05-06 5
> > #include
> > 189872f968 arch/um/sys-x86_64/user-offsets.c Jeff Dike 2007-10-16 6
> > #include
> > 8d0b9dc9be arch/um/sys-x86_64/user-offsets.c Al Viro 2005-05-05 7
> > #define __FRAME_OFFSETS
> > 8d0b9dc9be arch/um/sys-x86_64/user-offsets.c Al Viro 2005-05-05 @8
> > #include
> > ba9950c820 arch/um/sys-x86_64/user-offsets.c Jeff Dike 2005-05-20 9
> > #include
> > 8d0b9dc9be arch/um/sys-x86_64/user-offsets.c Al Viro 2005-05-05 10
> > 8d0b9dc9be arch/um/sys-x86_64/user-offsets.c Al Viro 2005-05-05 11
> > #define DEFINE(sym, val) \
> > 8d0b9dc9be arch/um/sys-x86_64/user-offsets.c Al Viro 2005-05-05 12 asm
> > volatile("\n->" #sym " %0 " #val : : "i" (val))
> > 8d0b9dc9be arch/um/sys-x86_64/user-offsets.c Al Viro 2005-05-05 13
> > ecba97d4aa arch/um/sys-x86_64/user-offsets.c Al Viro 2005-09-28 14
> > #define DEFINE_LONGS(sym, val) \
> > ecba97d4aa arch/um/sys-x86_64/user-offsets.c Al Viro 2005-09-28 15 asm
> > volatile("\n->" #sym " %0 " #val : : "i" (val/sizeof(unsigned long)))
> > ecba97d4aa arch/um/sys-x86_64/user-offsets.c Al Viro 2005-09-28 16
> >
> > :: The code at line 8 was first introduced by commit
> > :: 8d0b9dc9be3919e9979eac59fd12e8f82b098325 [PATCH] uml: start
> > cross-build support : mk_user_constants
> >
> > :: TO: Al Viro
> > :: CC: Linus Torvalds
> >
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology
> > Center
> > https://lists.01.org/pipermail/kbuild-all Intel
> > Corporation
>
Re: [PATCH v5 6/7][Update] cpufreq: Support for fast frequency switching
Hi,
On 17/03/16 00:51, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
> Subject: [PATCH] cpufreq: Support for fast frequency switching
>
[...]
> +void cpufreq_enable_fast_switch(struct cpufreq_policy *policy)
> +{
> + lockdep_assert_held(>rwsem);
> +
> + mutex_lock(_fast_switch_lock);
> + if (policy->fast_switch_possible && cpufreq_fast_switch_count >= 0) {
> + cpufreq_fast_switch_count++;
> + policy->fast_switch_enabled = true;
> + } else {
> + pr_warn("cpufreq: CPU%u: Fast freqnency switching not
> enabled\n",
Ultra-minor nit: s/freqnency/frequency/
Also, is this really a warning or just a debug message? (everything
seems to work fine on Juno even if this is printed :-)).
Best,
- Juri
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks
On Thu, Mar 17, 2016 at 10:47 AM, Linus Torvalds wrote: > On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: >> >> So we've not asked for NO_HIDE_STALE on the mailing lists, but I think >> it was one of the problems Sage had using xfs in his BlueStore >> implementation and was a big part of why it moved to pure userspace. >> FileStore might use NO_HIDE_STALE in some places but it would be >> pretty limited. When it came up at Linux FAST we were discussing how >> it and similar things had been problems for us in the past and it >> would've been nice if they were upstream. > > Hmm. > > So to me it really sounds like somebody should cook up a patch, but we > shouldn't put it in the upstream kernel until we get numbers and > actual "yes, we'd use this" from outside of google. > > I say "outside of google", because inside of google not only do we not > get numbers, but google can maintain their own patch. > > But maybe Ted could at least post the patch google uses, and somebody > in the Ceph community might want to at least try it out... > >>What *is* a >> big deal for >> FileStore (and would be easy to take advantage of) is the thematically >> similar O_NOMTIME flag, which is also about reducing metadata updates >> and got blocked on similar stupid-user grounds (although not security >> ones): http://thread.gmane.org/gmane.linux.kernel.api/10727. > > Hmm. I don't hate that patch, because the NOATIME thing really does > wonders on many loads. NOMTIME makes sense. > > It's not like you can't do this with utimes() anyway. > > That said, I do wonder if people wouldn't just prefer to expand on and > improve on the lazytime. > > Is there some reason you guys didn't use that? I wasn't really involved in this stuff but I gather from looking at http://www.spinics.net/lists/xfs/msg36869.html that any durability command other than fdatasync is going to write out the mtime updates to the inodes on disk. Given our durability requirements and the guarantees offered about when things actually hit disk, that doesn't work for us. We run an fsync on the order of every 30 seconds, and we do various combinations of fsync, fdatasync, flush_file_range, (and, well, any command we're provided) to try and bound the amount of dirty data and prevent fs/disk throughput pauses when we do that full sync. Anybody trying to do anything similar would want a switch that prevents operations from updating the mtime on disk no matter what. -Greg
Re: [PATCH] UBIFS: Implement ->migratepage()
Am 17.03.2016 um 05:39 schrieb kbuild test robot: > Hi Kirill, > > [auto build test ERROR on v4.5-rc7] > [also build test ERROR on next-20160316] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: > https://github.com/0day-ci/linux/commits/Richard-Weinberger/UBIFS-Implement-migratepage/20160317-065742 > config: x86_64-allmodconfig (attached as .config) > reproduce: > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >>> ERROR: "migrate_page_move_mapping" [fs/ubifs/ubifs.ko] undefined! >>> ERROR: "migrate_page_copy" [fs/ubifs/ubifs.ko] undefined! Meh. Just noticted that these functions are not exported and therefore not usable in modules. So, this patch is not really the solution although it makes the problem go away. Thanks, //richard
Re: [RFT] iommu/amd: use subsys_initcall() on amdv2 iommu
On Wed, Mar 16, 2016 at 12:16:57PM +0200, Oded Gabbay wrote: > On Wed, Mar 16, 2016 at 12:14 PM, Joerg Roedel wrote: > > On Wed, Mar 16, 2016 at 09:02:43AM +0200, Oded Gabbay wrote: > >> fwiw, we currently have this covered by the ugly hack of putting iommu > >> subsystem in front of gpu subsystem in the main drivers makefile (See > >> 1bacc894c227fad8a727eb99728df708eba57654) > > > > Sure, but the above is a less ugly hack to solve the problem. So the > > question is, would that work too? > > > > > > Joerg > > > > In theory it should, but I would prefer that it would be tested on > actual hardware. Hence, RFT. Anyone have hardware to test ? And would the other hack mentioned need to be reverted first ? Luis
Re: [PATCH] mm/page_isolation: let caller take the zone lock for test_pages_isolated
Am Freitag, den 18.03.2016, 02:18 +0900 schrieb Joonsoo Kim: > 2016-03-17 1:49 GMT+09:00 Lucas Stach : > > This fixes an annoying race in the CMA code leading to lots of "PFNs busy" > > messages when CMA is used concurrently. This is harmless normally as CMA > > will just retry the allocation at a different place, but it might lead to > > increased fragmentation of the CMA area as well as failing allocations > > when CMA is under memory pressure. > > > > The issue is that test_pages_isolated checks if the range is free by > > checking that all pages in the range are buddy pages. For this to work > > the start pfn needs to be aligned to the higher order buddy page > > including the start pfn if there is any. > > > > This is not a problem for the memory hotplug code, as it always offlines > > whole pageblocks, but CMA may want to isolate a smaller range. So for > > the check to work correctly it down-aligns the start pfn to the higher > > order buddy page. As the zone is not yet locked at that point a > > concurrent page free might coalesce the pages to be checked into an > > even bigger buddy page, causing the check to fail, while all pages are > > in fact buddy pages. > > > > By moving the zone locking to the caller of the test function, it's > > possible to do it before CMA tries to find the proper start page and stop > > any concurrent page coalescing to happen until the check is finished. > > I think that this patch cannot prevent the same race on > isolate_freepages_range(). If buddy merging happens after we > passed test_pages_isolated(), isolate_freepages_range() cannot see > buddy page and will fail. > Your analysis seems correct. I'll fix this patch to hold the zone lock across isolate_freepages_range. Thanks, Lucas
Re: [PATCH] USB: serial: ftdi_sio: Add support for ICP DAS I-756xU devices
On Thu, Mar 10, 2016 at 9:48 AM, Josh Boyer wrote:
> A Fedora user reports that the ftdi_sio driver works properly for the
> ICP DAS I-7561U device. Further, the user manual for these devices
> instructs users to load the driver and add the ids using the sysfs
> interface.
>
> Add support for these in the driver directly so that the devices work
> out of the box instead of needing manual configuration.
>
> Reported-by:
> CC: stable
> Signed-off-by: Josh Boyer
> ---
Anything further I need to do on this patch?
josh
> drivers/usb/serial/ftdi_sio.c | 4
> drivers/usb/serial/ftdi_sio_ids.h | 8
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 8c660ae401d8..b61f12160d37 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1004,6 +1004,10 @@ static const struct usb_device_id id_table_combined[]
> = {
> { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_DISPLAY_PID) },
> { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_LITE_PID) },
> { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ANALOG_PID) },
> + /* ICP DAS I-756xU devices */
> + { USB_DEVICE(ICPDAS_VID, ICPDAS_I7560U_PID) },
> + { USB_DEVICE(ICPDAS_VID, ICPDAS_I7561U_PID) },
> + { USB_DEVICE(ICPDAS_VID, ICPDAS_I7563U_PID) },
> { } /* Terminating entry */
> };
>
> diff --git a/drivers/usb/serial/ftdi_sio_ids.h
> b/drivers/usb/serial/ftdi_sio_ids.h
> index a84df2513994..a4ec24ce6a11 100644
> --- a/drivers/usb/serial/ftdi_sio_ids.h
> +++ b/drivers/usb/serial/ftdi_sio_ids.h
> @@ -872,6 +872,14 @@
> #define NOVITUS_BONO_E_PID 0x6010
>
> /*
> + * ICPDAS I-756*U devices
> + */
> +#define ICPDAS_VID 0x1b5c
> +#define ICPDAS_I7560U_PID 0x0103
> +#define ICPDAS_I7561U_PID 0x0104
> +#define ICPDAS_I7563U_PID 0x0105
> +
> +/*
> * RT Systems programming cables for various ham radios
> */
> #define RTSYSTEMS_VID 0x2100 /* Vendor ID */
> --
> 2.5.0
>
Re: [PATCH v2] mmc: Add CONFIG_MMC_SIMULATE_MAX_SPEED
On 22 February 2016 at 18:18, Mark Salyzyn wrote: > When CONFIG_MMC_SIMULATE_MAX_SPEED is enabled, Expose max_read_speed, > max_write_speed and cache_size sysfs controls to simulate a slow > eMMC device. The boot default values, should one wish to set this > behavior right from kernel start: > > CONFIG_MMC_SIMULATE_MAX_READ_SPEED > CONFIG_MMC_SIMULATE_MAX_WRITE_SPEED > CONFIG_MMC_SIMULATE_CACHE_SIZE > > respectively; and if not defined are 0 (off), 0 (off) and 4 MB > also respectively. So this changelog doesn't really tell me *why* this feature is nice to have. Could you elaborate on this and thus also extend the information in the changelog please. Moreover, I have briefly reviewed the code, but I don't want to go into the details yet... Instead, what I am trying to understand if this is something that useful+specific for the MMC subsystem, or if it's something that belongs in the upper generic BLOCK layer. Perhaps you can comment on this as well? Kind regards Uffe > > Signed-off-by: Mark Salyzyn > --- > changes in v2: change from CONFIG_MMC_BLOCK_MAX_SPEED to > CONFIG_MMC_SIMULATE_MAX_SPEED. Add documentation. > > Documentation/block/00-INDEX | 6 + > Documentation/block/mmc-max-speed.txt | 39 + > drivers/mmc/card/Kconfig | 57 +++ > drivers/mmc/card/block.c | 294 > ++ > drivers/mmc/card/queue.h | 8 + > 5 files changed, 404 insertions(+) > create mode 100644 Documentation/block/mmc-max-speed.txt > > diff --git a/Documentation/block/00-INDEX b/Documentation/block/00-INDEX > index e840b47..bc51487 100644 > --- a/Documentation/block/00-INDEX > +++ b/Documentation/block/00-INDEX > @@ -26,3 +26,9 @@ switching-sched.txt > - Switching I/O schedulers at runtime > writeback_cache_control.txt > - Control of volatile write back caches > +mmc-max-speed.txt > + - eMMC layer speed simulation, related to /sys/block/mmcblk*/ > + attributes: > +max_read_speed > +max_write_speed > +cache_size > diff --git a/Documentation/block/mmc-max-speed.txt > b/Documentation/block/mmc-max-speed.txt > new file mode 100644 > index 000..3ad1260 > --- /dev/null > +++ b/Documentation/block/mmc-max-speed.txt > @@ -0,0 +1,39 @@ > +eMMC Block layer simulation speed controls in /sys/block/mmcblk*/ > +=== > + > +Turned on with CONFIG_MMC_SIMULATE_MAX_SPEED which enables MMC device speed > +limiting. Used to test and simulate the behavior of the system when > +confronted with a slow MMC. > + > +Enables max_read_speed, max_write_speed and cache_size attributes to control > +the write or read maximum KB/second speed behaviors. The defaults are set > +by CONFIG_MMC_SIMULATE_MAX_READ_SPEED, CONFIG_MMC_SIMULATE_MAX_WRITE_SPEED > and > +CONFIG_MMC_SIMULATE_CACHE_SIZE config parameters respectively. > + > +NB: There is room for improving the algorithm for aspects tied directly to > +eMMC specific behavior. For instance, wear leveling and stalls from an > +exhausted erase pool. We would expect that if there was a need to provide > +similar speed simulation controls to other types of block devices, aspects of > +their behavior are modelled separately (e.g. head seek times, heat assist, > +shingling and rotational latency). > + > +/sys/block/mmcblk0/max_read_speed: > + > +Number of KB/second reads allowed to the block device. Used to test and > +simulate the behavior of the system when confronted with a slow reading MMC. > +Set to 0 or "off" to place no speed limit. > + > +/sys/block/mmcblk0/max_write_speed: > + > +Number of KB/second writes allowed to the block device. Used to test and > +simulate the behavior of the system when confronted with a slow writing MMC. > +Set to 0 or "off" to place no speed limit. > + > +/sys/block/mmcblk0/cache_size: > + > +Number of MB of high speed memory or high speed SLC cache expected on the > +eMMC device being simulated. Used to help simulate the write-back behavior > +more accurately. The assumption is the cache has no delay, but draws down > +in the background to the MLC/TLC primary store at the max_write_speed rate. > +Any write speed delays will show up when the cache is full, or when an I/O > +request to flush is issued. > diff --git a/drivers/mmc/card/Kconfig b/drivers/mmc/card/Kconfig > index 5562308..1abef59 100644 > --- a/drivers/mmc/card/Kconfig > +++ b/drivers/mmc/card/Kconfig > @@ -68,3 +68,60 @@ config MMC_TEST > > This driver is only of interest to those developing or > testing a host driver. Most people should say N here. > + > +config MMC_SIMULATE_MAX_SPEED > + bool "Turn on maximum speed control per block device" > + depends on MMC_BLOCK > + help > + Say Y here to enable MMC device speed limiting. Used to test and > + simulate the behavior of the system when confronted with a slow MMC. > + > + Enables max_read_speed,
Re: [PATCH v4 7/8] Documentation: devicetree: rockchip: Document Landingship
Am 18.03.2016 um 22:30 schrieb Rob Herring: > On Wed, Mar 16, 2016 at 02:58:45PM +0100, Andreas Färber wrote: >> Use "geekbuying,geekbox-landingship" compatible string, plus those of >> the GeekBox module. >> >> Signed-off-by: Andreas Färber >> --- >> v3 -> v4: Unchanged >> >> v2 -> v3: >> * Changed compatible string to include geekbox- (Heiko) >>and clarify that this is for GeekBox module >> >> v2: New >> >> Documentation/devicetree/bindings/arm/rockchip.txt | 5 + >> 1 file changed, 5 insertions(+) > > Think I already acked v3, but: > > Acked-by: Rob Herring Yes, you did, but after I had already sent v4. Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks
On 03/17/2016 01:47 PM, Linus Torvalds wrote: On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: So we've not asked for NO_HIDE_STALE on the mailing lists, but I think it was one of the problems Sage had using xfs in his BlueStore implementation and was a big part of why it moved to pure userspace. FileStore might use NO_HIDE_STALE in some places but it would be pretty limited. When it came up at Linux FAST we were discussing how it and similar things had been problems for us in the past and it would've been nice if they were upstream. Hmm. So to me it really sounds like somebody should cook up a patch, but we shouldn't put it in the upstream kernel until we get numbers and actual "yes, we'd use this" from outside of google. I say "outside of google", because inside of google not only do we not get numbers, but google can maintain their own patch. But maybe Ted could at least post the patch google uses, and somebody in the Ceph community might want to at least try it out... What *is* a big deal for FileStore (and would be easy to take advantage of) is the thematically similar O_NOMTIME flag, which is also about reducing metadata updates and got blocked on similar stupid-user grounds (although not security ones): http://thread.gmane.org/gmane.linux.kernel.api/10727. Hmm. I don't hate that patch, because the NOATIME thing really does wonders on many loads. NOMTIME makes sense. It's not like you can't do this with utimes() anyway. That said, I do wonder if people wouldn't just prefer to expand on and improve on the lazytime. Is there some reason you guys didn't use that? As noted though, we've basically given up and are moving to a pure-userspace solution as quickly as we can. That argues against worrying about this all in the kernel unless there are other users. Linus Just a note, when Greg says "user space solution", Ceph is looking at writing directly to raw block devices which is kind of a through back to early enterprise database trends. Ric
Re: [PATCH] Revert "arm64: Increase the max granular size"
On Wed, Mar 16, 2016 at 10:26:08AM -0500, Timur Tabi wrote: > Catalin Marinas wrote: > >Why do you need your own defconfig? If it's just on the short term until > >all your code is upstream, that's fine, but this goes against the single > >Image aim. I would like defconfig to cover all supported SoCs (and yes, > >ACPI on by default once we deem it !EXPERT anymore), though at some > >point we may need a server/mobile split (if the generated image is too > >large, maybe more stuff being built as modules). > > Yes, that's exactly it. Ours is an ACPI system, and so we have to have our > own defconfig for now. We're holding off on pushing our own defconfig > changes (enabling drivers, etc) until ACPI is enabled in > arch/arm64/configs/defconfig. Is there anything that prevents you from providing a dtb/dts for this SoC? -- Catalin
Re: [PATCH v4 11/14] i2c-octeon: Rename driver to prepare for split
On 03/18/2016 01:46 AM, Jan Glauber wrote: This is just an intermediate commit in preparation of the driver split. The module rename in this commit will be reverted in the next patch, this is just done to make the series bisectible. Signed-off-by: Jan Glauber --- drivers/i2c/busses/Makefile |2 +- drivers/i2c/busses/i2c-octeon-core.c | 1264 ++ drivers/i2c/busses/i2c-octeon.c | 1264 -- 3 files changed, 1265 insertions(+), 1265 deletions(-) create mode 100644 drivers/i2c/busses/i2c-octeon-core.c delete mode 100644 drivers/i2c/busses/i2c-octeon.c Again, if we need another patch submission, use "git format-patch -M ..."
[PATCH v4 00/13] Add A83T clk, r_pio, mmc rsb support
Hello,
This is v4 of series which adds further support for A83T, mainly adds clock
support.Also adds R_PIO, PRCM related clocks, mmc, rsb support.
A83T difference in short:
R_PIO is slightly different from A23 r_pio. AHB1 has different parents as
compared to a31-ahb1, APB1 has different dividers.Bus gates are similar to H3,
apb0 gates are different.mmc and rsb are compatible with earlier sunxi socs.
These patches are based on Maxime's sunxi/for-next branch.
https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/
v3->v4 Changes:
1. Removed MODULE_DEVICE_TABLE, module.h and made A83T R_PIO as
builtin_platform_driver.
2. Corrected config to MACH_SUN8I in clk/sunxi/Kconfig.
3. Corrected style related errors.
v2->v3 Changes:
1. Corrected wrong configuration of uart0 and timer in dtsi.
2. corrected clock gate name of "spdif" in dtsi.
3. Added kconfig for sunxi clocks, added sun8i-apb0 and sun9i-cpus clocks to it.
v1->v2 Changes:
1. Patches for apb0 gates clock, bus gates, low speed oscillators are already
merged, so, not included again in this series.
1. sorted the R_PIO Kconfig options.
2. removed un-necessary a83t apb1 div table.
3. combined the three ahb reset registers into one reset node.
4. Changed the bus gates names to bus_spidf and bus_usb_otg.
5. removed un-necessary #address-cells and #size-cells from R_PIO node.
6. splited rsb pins and rsb controller nodes in different patches.
7. used PF6 as mmc0 CD reference design pin.
8. corrected the style related errors.
Patch 1: adds support for r_pio pin controller.
patch 2: adds ahb1 clock support, 0b1x is pll6 parent otherwise it's same as a31
ahb1.
patch 3: adds apb1 clock support, apb1 has different dividers compared to a10
apb0 clock.
patch 4: adds basics clocks nodes to dtsi, pll6, ahb1, ahb2, apb1, apb2,
bus gates, and resets.
patch 5-6: adds mmc and it's clock nodes.
patch 7: adds A83T PRCM related clocks, clock resets.
patch 8: adds r_pio pin controller nodes to dtsi
patch 9: adds RSB controller nodes to dtsi
patch 10: adds common MMC CD detect pin as reference design pin
patch 11: enables mmc0 support for h8homlet board, tested by LABBE Corentin.
patch 12: This patch adds support for Sinovoip BPI-M3 A83T based board, it has
2GB LPDDR3, u-boot support is added recently for this board.
patch 13: Adds kconfig for clocks(sun8i-apb0 and sun9i-cpus).
Vishnu Patekar (13):
pinctrl: sunxi: Add A83T R_PIO controller
clk: sunxi: add ahb1 clock for A83T
clk: sunxi: Add APB1 clock for A83T
ARM: dts: sun8i-a83t: Add basic clocks and resets
ARM: dts: sun8i-a83t: add mmc clock nodes
ARM: dts: sun8i-a83t: Add mmc controller nodes
ARM: dts: sun8i-a83t: Add PRCM related clocks and resets
ARM: dts: sun8i-a83t: Add R_PIO controller node to the dtsi
ARM: dts: sun8i-a83t: Add RSB controller device node to dtsi
ARM: dts: sun8i-a83t: add mmc0 CD pin
ARM: dts: sun8i: enable mmc for H8Homlet Board.
ARM: dts: sun8i: Add A83T based Sinovoip Bpi-M3 Board
ARM: sunxi: Add Kconfig for sunxi clocks
Documentation/devicetree/bindings/clock/sunxi.txt | 2 +
.../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
.../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 11 +
...omlet-v2.dts => sun8i-a83t-sinovoip-bpi-m3.dts} | 21 +-
arch/arm/boot/dts/sun8i-a83t.dtsi | 285 -
drivers/clk/Kconfig| 1 +
drivers/clk/sunxi/Kconfig | 5 +
drivers/clk/sunxi/Makefile | 4 +-
drivers/clk/sunxi/clk-sunxi.c | 89 +++
drivers/pinctrl/sunxi/Kconfig | 5 +
drivers/pinctrl/sunxi/Makefile | 1 +
drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c | 117 +
13 files changed, 536 insertions(+), 7 deletions(-)
copy arch/arm/boot/dts/{sun8i-a83t-allwinner-h8homlet-v2.dts =>
sun8i-a83t-sinovoip-bpi-m3.dts} (83%)
create mode 100644 drivers/clk/sunxi/Kconfig
create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c
--
1.9.1
Re: [PATCH 04/15] irqchip/gic: WARN if setting the interrupt type fails
On Thu, Mar 17, 2016 at 03:04:01PM +, Jon Hunter wrote: > > On 17/03/16 14:51, Thomas Gleixner wrote: > > On Thu, 17 Mar 2016, Jon Hunter wrote: > > > >> Setting the interrupt type for private peripheral interrupts (PPIs) may > >> not be supported by a given GIC because it is IMPLEMENTATION DEFINED > >> whether this is allowed. There is no way to know if setting the type is > >> supported for a given GIC and so the value written is read back to > >> verify it matches the desired configuration. If it does not match then > >> an error is return. > >> > >> There are cases where the interrupt configuration read from firmware > >> (such as a device-tree blob), has been incorrect and hence > >> gic_configure_irq() has returned an error. This error has gone > >> undetected because the error code returned was ignored but the interrupt > >> still worked fine because the configuration for the interrupt could not > >> be overwritten. > >> > >> Given that this has done undetected and we should only fail to set the > >> type for PPIs whose configuration cannot be changed anyway, don't return > >> an error and simply WARN if this fails. This will allows us to fix up any > >> places in the kernel where we should be checking the return status and > >> maintain back compatibility with firmware images that may have incorrect > >> interrupt configurations. > > > > Though silently returning 0 is really the wrong thing to do. You can add the > > warn, but why do you want to return success? > > Yes that would be the correct thing to do I agree. However, the problem > is that if we do this, then after the patch "irqdomain: Don't set type > when mapping an IRQ" is applied, we may break interrupts for some > existing device-tree binaries that have bad configuration (such as omap4 > and tegra20/30 ... see patches 1 and 2) that have gone unnoticed. So it > is a back compatibility issue. This sounds like a textbook case for adding a boolean dt property. If "can-set-ppi-type" is absent (old DT blobs and new blobs without the ability), warn and return zero. If it's present, the driver can set the type, returning errors as encountered. thx, Jason.
Re: [PATCH 2/8] sched/fair: add margin to utilization update
Quoting Steve Muckle (2016-03-15 19:52:59)
> On 03/13/2016 10:22 PM, Michael Turquette wrote:
> > +unsigned long cfs_capacity_margin = CAPACITY_MARGIN_DEFAULT;
> > +
> > #ifdef CONFIG_CFS_BANDWIDTH
> > /*
> > * Amount of runtime to allocate from global (tg) to local (per-cfs_rq)
> > pool
> > @@ -2840,6 +2853,8 @@ static inline void update_load_avg(struct
> > sched_entity *se, int update_tg)
> >
> > if (cpu == smp_processor_id() && >cfs == cfs_rq) {
> > unsigned long max = rq->cpu_capacity_orig;
> > + unsigned long cap = cfs_rq->avg.util_avg *
> > + cfs_capacity_margin / max;
>
> Doesn't rq->cpu_capacity_orig get scaled per the microarch invariance?
> This would mean that the margin we're applying here would differ based
> on that.
>
> I'd expect that the margin would be * (cfs_capacity_margin /
> SCHED_CAPACITY_SCALE) which would then reduce the division into a shift.
Will fix.
Thanks,
Mike
RE: [PATCH v3 3/3] cpuacct: split usage into user_usage and sys_usage
Hi, Peter Zijlstra
> -Original Message-
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> Sent: Thursday, March 17, 2016 4:40 PM
> To: Zhao Lei
> Cc: linux-kernel@vger.kernel.org; Tejun Heo ; Yang
> Dongsheng
> Subject: Re: [PATCH v3 3/3] cpuacct: split usage into user_usage and sys_usage
>
> On Thu, Mar 17, 2016 at 12:19:44PM +0800, Zhao Lei wrote:
> > +static u64 __cpuusage_read(struct cgroup_subsys_state *css,
> > + enum cpuacct_usage_index index)
> > {
> > struct cpuacct *ca = css_ca(css);
> > u64 totalcpuusage = 0;
> > int i;
> >
> > for_each_present_cpu(i)
> > + totalcpuusage += cpuacct_cpuusage_read(ca, i, index);
> >
> > return totalcpuusage;
> > }
>
> Ok, so while looking over this, it mostly uses for_each_present_cpu(),
> which is already dubious, but then cpuacct_stats_show() uses
> for_each_online_cpu().
>
> Why is this? Why not always for_each_possible_cpu()?
>
> Surely, if you offline a cpu, you still want its stat to be included in
> your totals, otherwise your numbers will go backwards when you take a
> cpu offline.
>
I agree with you that for_each_possible_cpu() is best choice for above
code.
In corrent code,
1: cpuacct.usage_percpu only include present_cpus
If a cpu is hotplug out, it is not exist in above file.
2: cpuacct.usage only calculate present_cpus
If a cpu is hotplug out, this value maybe decreased.
3: cpuacct.stat only calculate online cpus
Obviously wrong.
Above 3 is easy to fix, but better to fix above 1 and 2 together,
in one word, to make ALL statics counts possible_cpu.
The problem is file output, currently,
# cat cpuacct.usage_percpu
689076136 1131883300
If we turn to use possible_cpu, above line will have
256 valuse, as:
# cat cpuacct.usage_percpu
689076136 1131883300 0 0 0 0 0 0 0 0 ...
Or we can only show present_cpu and non_present_cpu with !0 value,
and we need also need output a cpuindex, as:
# cat cpuacct.usage_percpu
[0] 689076136
[1] 1131883300
[3]
[50]
#
It will tell user more accurate information,
but both solution will change current cgroup interface.
So I suggest keeping current using of for_each_present_cpu,
and only modify for_each_online_cpu.
What is your opinion?
Thanks
Zhaolei
Re: [PATCH 1/1] arm64/dma-mapping: remove an unnecessary conversion
On Thu, Mar 17, 2016 at 07:06:27PM +0800, Leizhen (ThunderTown) wrote:
> On 2016/3/16 9:56, Leizhen (ThunderTown) wrote:
> > On 2016/3/15 23:37, Catalin Marinas wrote:
> >> On Tue, Mar 15, 2016 at 10:12:11AM +0800, Zhen Lei wrote:
> >>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> >>> index a6e757c..b2f2834 100644
> >>> --- a/arch/arm64/mm/dma-mapping.c
> >>> +++ b/arch/arm64/mm/dma-mapping.c
> >>> @@ -187,8 +187,6 @@ static void __dma_free(struct device *dev, size_t
> >>> size,
> >>> void *vaddr, dma_addr_t dma_handle,
> >>> struct dma_attrs *attrs)
> >>> {
> >>> - void *swiotlb_addr = phys_to_virt(dma_to_phys(dev, dma_handle));
> >>> -
> >>> size = PAGE_ALIGN(size);
> >>>
> >>> if (!is_device_dma_coherent(dev)) {
> >>> @@ -196,7 +194,7 @@ static void __dma_free(struct device *dev, size_t
> >>> size,
> >>> return;
> >>> vunmap(vaddr);
> >>> }
> >>> - __dma_free_coherent(dev, size, swiotlb_addr, dma_handle, attrs);
> >>> + __dma_free_coherent(dev, size, vaddr, dma_handle, attrs);
> >>> }
> >>
> >> What happens when !is_device_dma_coherent(dev)? (hint: read two lines
> >> above __dma_free_coherent).
>
> Do you afraid "vaddr" maybe modified by these statement?
> First, it could not be __free_from_pool. Otherwise, the function
> vunmap(which after it) can not work well. Then, it count not be vunmap
> too, the parameter is defined as "const void *".
>
> In the call chain:
> __dma_free_coherent-->__dma_free_coherent-->swiotlb_free_coherent,
> only swiotlb_free_coherent finally use "vaddr".
Exactly. So you give swiotlb_free_coherent a vaddr which has been
unmapped. It doesn't even matter whether it's still mapped since this
address is passed further to free_pages() which performs a
virt_to_page(). The latter is *only* valid on linear map addresses (and
you would actually hit the VM_BUG_ON in free_pages; you can try running
this with CONFIG_DEBUG_VM enabled and non-coherent DMA).
For non-coherent DMA, the vaddr is not part of the linear mapping as it
has been remapped by __dma_alloc() via dma_common_contiguous_remap(),
hence for swiotlb freeing we need the actual linear map address (the
original "ptr" in __dma_alloc()). We can generate it by a
phys_to_virt(dma_to_phys(dma_handle)).
--
Catalin
RE: [PATCH] staging: lustre: really make lustre dependent on LNet
>A patch intended to add a dependency on LNET for lustre didn't
>actually do that and instead allowed configurations that contain
>lustre with lnet but without IPv4 support that subsequently
>fail to link:
>
>warning: (LUSTRE_FS) selects LNET which has unmet direct dependencies (STAGING
>&& INET && m && MODULES)
>ERROR: "kernel_sendmsg" [drivers/staging/lustre/lnet/lnet/lnet.ko] undefined!
>ERROR: "sock_create_lite" [drivers/staging/lustre/lnet/lnet/lnet.ko] undefined!
>ERROR: "sock_release" [drivers/staging/lustre/lnet/lnet/lnet.ko] undefined!
>ERROR: "release_sock" [drivers/staging/lustre/lnet/klnds/socklnd/ksocklnd.ko]
>undefined!
>ERROR: "kernel_sendmsg"
>[drivers/staging/lustre/lnet/klnds/socklnd/ksocklnd.ko] undefined!
>ERROR: "tcp_sendpage" [drivers/staging/lustre/lnet/klnds/socklnd/ksocklnd.ko]
>undefined!
>
>This adds the one-line change that was evidently missing from the
>commit, doing what was intended there to have a correct set of dependencies.
>
>Signed-off-by: Arnd Bergmann
>Fixes: b08bb6bb5af5 ("staging: lustre: make lustre dependent on LNet")
Thanks for fixing that. I was surprised that select didn't manage the
configuration automatically.
Acked-by: James Simmons
>---
> drivers/staging/lustre/lustre/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/staging/lustre/lustre/Kconfig
>b/drivers/staging/lustre/lustre/Kconfig
>index a09b51ce8265..8ac7cd4d6fdb 100644
>--- a/drivers/staging/lustre/lustre/Kconfig
>+++ b/drivers/staging/lustre/lustre/Kconfig
>@@ -1,7 +1,7 @@
> config LUSTRE_FS
> tristate "Lustre file system client support"
> depends on m && !MIPS && !XTENSA && !SUPERH
>- select LNET
>+ depends on LNET
> select CRYPTO
> select CRYPTO_CRC32
> select CRYPTO_CRC32_PCLMUL if X86
>--
>2.7.0
Re: [PATCH] ARM: Rockchip: Fix use of plain integer as NULL pointer
Nit: Subject line doesn't match the preferred format for the sub-arch. On Thu, 17 Mar 2016, Peter Griffin wrote: > This fixes the following sparse build warning > mach-rockchip/platsmp.c:68:43: Using plain integer as NULL pointer Nit: I would insert a '\n' between your wording and the quoted warning. For added clarity, I usually stick a tab before the quote. > Signed-off-by: Peter Griffin > --- > arch/arm/mach-rockchip/platsmp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch looks good though: Acked-by: Lee Jones > diff --git a/arch/arm/mach-rockchip/platsmp.c > b/arch/arm/mach-rockchip/platsmp.c > index d42a07e..4d827a0 100644 > --- a/arch/arm/mach-rockchip/platsmp.c > +++ b/arch/arm/mach-rockchip/platsmp.c > @@ -65,7 +65,7 @@ static struct reset_control *rockchip_get_core_reset(int > cpu) > if (dev) > np = dev->of_node; > else > - np = of_get_cpu_node(cpu, 0); > + np = of_get_cpu_node(cpu, NULL); > > return of_reset_control_get(np, NULL); > } -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] watchdog: don't run proc_watchdog_update if new value is same as old
On 03/16/2016 04:21 AM, Ulrich Obergfell wrote: Josh, I haven't tried to reproduce the soft lockups with kernel 4.1, but I believe I found an explanation in terms of how your test case breaks the watchdog mechanism in kernel 4.1: The soft lockup detector is implemented via two components (per-cpu). - The watchdog_timer_fn() function. This function runs periodically (sample_period) in the context of a high-resolution timer on CPU N. It wakes up the 'watchdog/N' thread and checks watchdog_touch_ts[N] to determine whether the thread has run within the soft lockup detection interval (watchdog_thresh * 2). - The watchdog() function. This function is executed in the context of the 'watchdog/N' thread. It updates the watchdog_touch_ts[N] time stamp to signal that it got a chance to run. The thread has a high realtime priority. If it does not get a chance to run, this is indicative that 'something else' is hogging CPU N. The while :; do echo 1 > /proc/sys/kernel/nmi_watchdog; sleep .1; done loop triggers the following flow of execution in the watchdog code at a frequency that is much higher than sample_period. proc_nmi_watchdog proc_watchdog_common proc_watchdog_update watchdog_enable_all_cpus update_watchdog_all_cpus for_each_online_cpu update_watchdog smp_call_function_single(restart_watchdog_hrtimer) Calling the restart_watchdog_hrtimer() function at such a high rate has the following effects. - The high-resolution timer gets canceled and restarted before it ever gets a chance to expire. Hence, the watchdog_timer_fn() function does not get a chance to wake up the 'watchdog/N' thread. So this prevents the thread from running within the soft lockup detection interval. - Since watchdog_timer_fn() does not wake up the 'watchdog/N' thread, the watchdog_touch_ts[N] time stamp is not being updated. The sleep 30 && kill %1 command terminates the above while loop after 30 seconds, so the high-resolution timer no longer gets canceled. When the timer expires, watchdog_timer_fn() detects that 'watchdog/N' has not run within the soft lockup detection interval. Your patch 'masks' the above issue because proc_watchdog_update() is not called if the parameter value is not changed. The mechanism that picks up changes of watchdog parameters 'on the fly' was rewritten in kernel 4.3 (see https://lkml.org/lkml/2015/8/1/64 and http://marc.info/?l=linux-kernel=143894132129981=2). $ git log --pretty=oneline v4.2..v4.3 -- kernel/watchdog.c | head -5 ec6a90661a0d6ce1461d05c7a58a0a151154e14a watchdog: rename watchdog_suspend() and watchdog_resume() 999bbe49ea0118b70ddf3f5d679f51dc7a97ae55 watchdog: use suspend/resume interface in fixup_ht_bug() d4bdd0b21c7652a8271f873cc755486b255c1bbd watchdog: use park/unpark functions in update_watchdog_all_cpus() 8c073d27d7ad293bf734cc8475689413afadab81 watchdog: introduce watchdog_suspend() and watchdog_resume() 81a4beef91ba4a9e8ad6054ca9933dff7e25ff28 watchdog: introduce watchdog_park_threads() and watchdog_unpark_threads() The new version of the update_watchdog_all_cpus() function now parks and unparks all 'watchdog/N' threads. If any watchdog parameter in /proc was changed, the new value gets picked up by the threads during unpark when watchdog_enable() is executed. The following is particularly relevant to your test case. - watchdog_disable() cancels the high-resolution timer during park - watchdog_enable() starts the high-resolution timer during unpark and updates watchdog_touch_ts[N] by calling __touch_watchdog() I believe this explains why you can only reproduce the soft lockup with kernel v4.1 but not with v4.5. Your patch "don't run proc_watchdog_update if new value is same as old" looks OK to me. I have no objections. Many Thanks, Uli Uli Thanks for the detailed explanation! As you mention my patch will mask this problem for 4.1 which is why I wanted to get it into stable. Do you think there is any way to mitigate this issue for the stable kernels (4.1 to 4.4) if the user changes the values doing something like: foo=1; while :; do echo $foo > /proc/sys/kernel/nmi_watchdog; foo=$(( ! $foo )); sleep .1; done & sleep 30 && kill %1 ? I realize this isn't a real-world use-case (I hope :)), but shows there is still a way to cause the box to soft lockup with this code path. I ask b/c these kernels are both longterm stable releases and so this issue will likely live for a while in the wild. Josh
Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async
On (03/18/16 14:49), Byungchul Park wrote:
[..]
> > http://marc.info/?l=linux-kernel=145750373530161
>
> I checked it now. Do you mean the wake_up_process() introduced in the new
> patch in console_unlock()? If so, I also think it does not make a deadlock,
> just can make a recursion in the worst case. I thought it was the
> wake_up_process() in up() which is eventually called from console_unlock().
> A deadlock can happen with the wake_up_proces() in up(). :-)
I'm not addressing already existing problems here. I'm trying to
minimise the impact of new code only.
[..]
> diff --git a/kernel/locking/spinlock_debug.c b/kernel/locking/spinlock_debug.c
> index fd24588..30559c6 100644
> --- a/kernel/locking/spinlock_debug.c
> +++ b/kernel/locking/spinlock_debug.c
> @@ -138,14 +138,25 @@ static void __spin_lock_debug(raw_spinlock_t *lock)
> {
> u64 i;
> u64 loops = loops_per_jiffy * HZ;
> + static raw_spinlock_t *suspected_lock = NULL;
this has no chances to survive on SMP systems that have spin_lockup-ed on at
least two different spin locks.
I'd really prefer not to mix-in spin_dump/printk recursion problems into this
patch set. it makes sense not to make printk recursion detection worse due to
newly added spin_locks to vprintk_emit(), but that's it. this patch set set is
fixing other things in the first place.
-ss
> for (i = 0; i < loops; i++) {
> if (arch_spin_trylock(>raw_lock))
> return;
> __delay(1);
> }
> - /* lockup suspected: */
> - spin_dump(lock, "lockup suspected");
> +
> + /*
> + * When we suspect a lockup, it's good enough to inform it once for
> + * the same lock. Otherwise it could cause an infinite recursion if
> + * it's within printk().
> + */
> + if (suspected_lock != lock) {
> + suspected_lock = lock;
> + /* lockup suspected: */
> + spin_dump(lock, "lockup suspected");
> + suspected_lock = NULL;
> + }
> #ifdef CONFIG_SMP
> trigger_all_cpu_backtrace();
> #endif
> --
> 1.9.1
>
[PATCH v6 3/4] i2c: i801: add support of Host Notify
The i801 chip can handle the Host Notify feature since ICH 3 as mentioned
in
http://www.intel.com/content/dam/doc/datasheet/82801ca-io-controller-hub-3-datasheet.pdf
Enable the functionality unconditionally and propagate the alert
on each notification.
With a T440s and a Synaptics touchpad that implements Host Notify, the
payload data is always 0x, so I am not sure if the device actually
sends the payload or if there is a problem regarding the implementation.
Signed-off-by: Benjamin Tissoires
---
changes in v2:
- removed the description of the Slave functionality support in the chip table
(the table shows what is supported, not what the hardware is capable of)
- use i2c-smbus to forward the notification
- remove the fifo, and directly retrieve the address and payload in the worker
- do not check for Host Notification is the feature is not enabled
- use inw_p() to read the payload instead of 2 inb_p() calls
- add /* fall-through */ comment
- unconditionally enable Host Notify if the hardware supports it (can be
disabled by the user)
no changes in v3
changes in v4:
- make use of the new API -> no more worker spawning here
- solved a race between the access of the Host Notify registers and the actual
I2C transfers.
changes in v5:
- added SKL Host Notify support
changes in v6:
- select I2C_SMBUS in Kconfig to prevent an undefined reference when I2C_I801
is set to 'Y' while I2C_SMBUS is set to 'M'
drivers/i2c/busses/Kconfig| 1 +
drivers/i2c/busses/i2c-i801.c | 85 +--
2 files changed, 83 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index faa8e68..8c8fa12 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -91,6 +91,7 @@ config I2C_I801
tristate "Intel 82801 (ICH/PCH)"
depends on PCI
select CHECK_SIGNATURE if X86 && DMI
+ select I2C_SMBUS
help
If you say yes to this option, support will be included for the Intel
801 family of mainboard I2C interfaces. Specifically, the following
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 585a3b7..b244aa40 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -72,6 +72,7 @@
* Block process call transaction no
* I2C block read transaction yes (doesn't use the block buffer)
* Slave mode no
+ * SMBus Host Notify yes
* Interrupt processingyes
*
* See the file Documentation/i2c/busses/i2c-i801 for details.
@@ -86,6 +87,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -112,6 +114,10 @@
#define SMBPEC(p) (8 + (p)->smba) /* ICH3 and later */
#define SMBAUXSTS(p) (12 + (p)->smba)/* ICH4 and later */
#define SMBAUXCTL(p) (13 + (p)->smba)/* ICH4 and later */
+#define SMBSLVSTS(p) (16 + (p)->smba)/* ICH3 and later */
+#define SMBSLVCMD(p) (17 + (p)->smba)/* ICH3 and later */
+#define SMBNTFDADD(p) (20 + (p)->smba)/* ICH3 and later */
+#define SMBNTFDDAT(p) (22 + (p)->smba)/* ICH3 and later */
/* PCI Address Constants */
#define SMBBAR 4
@@ -176,6 +182,12 @@
#define SMBHSTSTS_INTR 0x02
#define SMBHSTSTS_HOST_BUSY0x01
+/* Host Notify Status registers bits */
+#define SMBSLVSTS_HST_NTFY_STS 1
+
+/* Host Notify Command registers bits */
+#define SMBSLVCMD_HST_NTFY_INTREN 0x01
+
#define STATUS_ERROR_FLAGS (SMBHSTSTS_FAILED | SMBHSTSTS_BUS_ERR | \
SMBHSTSTS_DEV_ERR)
@@ -244,13 +256,18 @@ struct i801_priv {
struct platform_device *mux_pdev;
#endif
struct platform_device *tco_pdev;
+
+ struct smbus_host_notify *host_notify;
};
+#define SMBHSTNTFY_SIZE8
+
#define FEATURE_SMBUS_PEC (1 << 0)
#define FEATURE_BLOCK_BUFFER (1 << 1)
#define FEATURE_BLOCK_PROC (1 << 2)
#define FEATURE_I2C_BLOCK_READ (1 << 3)
#define FEATURE_IRQ(1 << 4)
+#define FEATURE_HOST_NOTIFY(1 << 5)
/* Not really a feature, but it's convenient to handle it as such */
#define FEATURE_IDF(1 << 15)
#define FEATURE_TCO(1 << 16)
@@ -261,6 +278,7 @@ static const char *i801_feature_names[] = {
"Block process call",
"I2C block read",
"Interrupt",
+ "SMBus Host Notify",
};
static unsigned int disable_features;
@@ -269,7 +287,8 @@ MODULE_PARM_DESC(disable_features, "Disable selected driver
features:\n"
"\t\t 0x01 disable SMBus PEC\n"
"\t\t 0x02 disable the block buffer\n"
"\t\t 0x08 disable the I2C block read functionality\n"
- "\t\t 0x10 don't use interrupts ");
+ "\t\t 0x10 don't use interrupts\n"
+ "\t\t 0x20 disable SMBus Host Notify ");
/* Make sure the SMBus host is ready to start transmitting.
Return 0
[PATCH v2 5/9] efi/arm64: libstub: make screen_info accessible to the UEFI stub
Unlike on 32-bit ARM, where we need to pass the stub's version of struct
screen_info to the kernel proper via a configuration table, on 64-bit ARM
it simply involves making the core kernel's copy of struct screen_info
visible to the stub by exposing an __efistub_ alias for it.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/efi.h | 3 +++
arch/arm64/kernel/efi.c | 3 +++
arch/arm64/kernel/image.h| 1 +
3 files changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index bb26f2205973..ed6c85d3a583 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -54,6 +54,9 @@ int efi_create_mapping(struct mm_struct *mm,
efi_memory_desc_t *md);
#define __efi_call_early(f, ...) f(__VA_ARGS__)
#define efi_is_64bit() (true)
+#define alloc_screen_info(x...)_info
+#define free_screen_info(x...)
+
#define EFI_ALLOC_ALIGNSZ_64K
/*
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index b6abc852f2a1..6f4b3ea359db 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -17,6 +17,9 @@
#include
+/* we will fill this structure from the stub, so don't put it in .bss */
+struct screen_info screen_info __section(.data);
+
int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md)
{
pteval_t prot_val;
diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index 5e360ce88f10..1428849aece8 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -112,6 +112,7 @@ __efistub___memset = KALLSYMS_HIDE(__pi_memset);
__efistub__text= KALLSYMS_HIDE(_text);
__efistub__end = KALLSYMS_HIDE(_end);
__efistub__edata = KALLSYMS_HIDE(_edata);
+__efistub_screen_info = KALLSYMS_HIDE(screen_info);
#endif
--
2.5.0
Re: [PATCH] arm64: dma-mapping: fix dma_to_phys API for IOMMU attached devices
On Thursday 17 March 2016 12:36:28 Sinan Kaya wrote:
>
> The first solution that comes to my mind is to implement a weak function in
> swiotlb.c with these contents
>
> dma_addr_t __weak swio_phys_to_dma(struct device *dev, phys_addr_t paddr)
> {
> return paddr;
> }
>
>
> phys_addr_t __weak swio_dma_to_phys(struct device *dev, dma_addr_t daddr)
> {
> return daddr;
> }
>
> then clean up all the duplicates in dma-mapping.h for all ARCHs that have
> identical code.
>
> For others move the implementation to some source file.
>
>
Sounds ok to me, but I'd prefer using a macro instead of a __weak symbol:
#ifndef swiotlb_phys_to_dma
static inline dma_addr_t swiotlb_phys_to_dma(struct device *dev, phys_addr_t
paddr)
{
return paddr;
}
#endif
and then let the architectures that override it provide a self-referencing
macro:
#define swiotlb_phys_to_dma swiotlb_phys_to_dma
Also note swiotlb instead of swio, to match the existing naming.
Arnd
Re: [PATCH] powercap: intel_rapl: PSys support
On Thu, 2016-03-17 at 23:51 +0100, Borislav Petkov wrote: > On Thu, Mar 17, 2016 at 03:23:29PM -0700, Srinivas Pandruvada wrote: > > > > Skylake processor supports a new set of RAPL registers for > > controlling > > entire platform instead of just CPU package. This is useful for > > thermal > > and power control when source of power/thermal is not just CPU/GPU. > > This change adds a new platform domain (AKA PSys) to the current > > power capping Intel RAPL driver. > > PSys also supports PL1 (long term) and PL2 (short term) control > > like > > package domain. This also follows same MSRs for energy and time > > units as package domain. > > Unlike package domain, PSys support requires more than just > > processor > > level implementation. The other parts in the system need additional > > implementation, which OEMs needs to support. So not all Skylake > > systems will support PSys. > > > > Signed-off-by: Srinivas Pandruvada > .com> > > --- > > arch/x86/include/asm/msr-index.h | 3 ++ > > drivers/powercap/intel_rapl.c| 63 > > > > 2 files changed, 66 insertions(+) > > > > diff --git a/arch/x86/include/asm/msr-index.h > > b/arch/x86/include/asm/msr-index.h > > index 2da46ac..bd383f5 100644 > > --- a/arch/x86/include/asm/msr-index.h > > +++ b/arch/x86/include/asm/msr-index.h > > @@ -190,6 +190,9 @@ > > #define MSR_PP1_ENERGY_STATUS 0x0641 > > #define MSR_PP1_POLICY 0x0642 > > > > +#define MSR_PLATFORM_ENERGY_STATUS 0x064d > > +#define MSR_PLATFORM_POWER_LIMIT 0x065c > Please add those defines to intel_rapl.c as they're being used only > there, apparently. OK. I will move them. Thanks, Srinivas > > -- > Regards/Gruss, > Boris. > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, > HRB 21284 (AG Nürnberg)
[PATCH 06/10] iommu/ipmmu-vmsa: Add optional root device feature
From: Magnus Damm
Add root device handling to the IPMMU driver by
allowing certain DT compat strings to enable
has_cache_leaf_nodes that in turn will support
both root devices with interrupts and leaf devices
that face the actual IPMMU consumer devices.
Signed-off-by: Magnus Damm
---
drivers/iommu/ipmmu-vmsa.c | 92 ++--
1 file changed, 73 insertions(+), 19 deletions(-)
--- 0019/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2016-03-18 00:30:22.270513000 +0900
@@ -35,6 +35,7 @@
struct ipmmu_features {
bool use_ns_alias_offset;
+ bool has_cache_leaf_nodes;
};
struct ipmmu_vmsa_device {
@@ -50,10 +51,12 @@ struct ipmmu_vmsa_device {
struct dma_iommu_mapping *mapping;
#endif
const struct ipmmu_features *features;
+ bool is_leaf;
};
struct ipmmu_vmsa_domain {
struct ipmmu_vmsa_device *mmu;
+ struct ipmmu_vmsa_device *root;
struct iommu_domain io_domain;
struct io_pgtable_cfg cfg;
@@ -198,6 +201,36 @@ static struct ipmmu_vmsa_domain *to_vmsa
#define IMUASID_ASID0_SHIFT0
/*
-
+ * Root device handling
+ */
+
+static bool ipmmu_is_root(struct ipmmu_vmsa_device *mmu)
+{
+ if (mmu->features->has_cache_leaf_nodes)
+ return mmu->is_leaf ? false : true;
+ else
+ return true; /* older IPMMU hardware treated as single root */
+}
+
+static struct ipmmu_vmsa_device *ipmmu_find_root(struct ipmmu_vmsa_device
*leaf)
+{
+ struct ipmmu_vmsa_device *mmu = NULL;
+
+ if (ipmmu_is_root(leaf))
+ return leaf;
+
+ spin_lock(_devices_lock);
+
+ list_for_each_entry(mmu, _devices, list) {
+ if (ipmmu_is_root(mmu))
+ break;
+ }
+
+ spin_unlock(_devices_lock);
+ return mmu;
+}
+
+/*
-
* Read/Write Access
*/
@@ -214,13 +247,13 @@ static void ipmmu_write(struct ipmmu_vms
static u32 ipmmu_ctx_read(struct ipmmu_vmsa_domain *domain, unsigned int reg)
{
- return ipmmu_read(domain->mmu, domain->context_id * IM_CTX_SIZE + reg);
+ return ipmmu_read(domain->root, domain->context_id * IM_CTX_SIZE + reg);
}
static void ipmmu_ctx_write(struct ipmmu_vmsa_domain *domain, unsigned int reg,
u32 data)
{
- ipmmu_write(domain->mmu, domain->context_id * IM_CTX_SIZE + reg, data);
+ ipmmu_write(domain->root, domain->context_id * IM_CTX_SIZE + reg, data);
}
/*
-
@@ -334,7 +367,7 @@ static int ipmmu_domain_init_context(str
* TODO: Add support for coherent walk through CCI with DVM and remove
* cache handling. For now, delegate it to the io-pgtable code.
*/
- domain->cfg.iommu_dev = domain->mmu->dev;
+ domain->cfg.iommu_dev = domain->root->dev;
domain->iop = alloc_io_pgtable_ops(ARM_32_LPAE_S1, >cfg,
domain);
@@ -344,15 +377,15 @@ static int ipmmu_domain_init_context(str
/*
* Find an unused context.
*/
- ret = find_first_zero_bit(domain->mmu->ctx, IPMMU_CTX_MAX);
+ ret = find_first_zero_bit(domain->root->ctx, IPMMU_CTX_MAX);
if (ret == IPMMU_CTX_MAX) {
free_io_pgtable_ops(domain->iop);
return -EBUSY;
}
domain->context_id = ret;
- domain->mmu->domains[ret] = domain;
- set_bit(ret, domain->mmu->ctx);
+ domain->root->domains[ret] = domain;
+ set_bit(ret, domain->root->ctx);
/* TTBR0 */
ttbr = domain->cfg.arm_lpae_s1_cfg.ttbr[0];
@@ -396,7 +429,7 @@ static int ipmmu_domain_init_context(str
static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain)
{
- clear_bit(domain->context_id, domain->mmu->ctx);
+ clear_bit(domain->context_id, domain->root->ctx);
/*
* Disable the context. Flush the TLB as required when modifying the
@@ -524,7 +557,7 @@ static int ipmmu_attach_device(struct io
struct device *dev)
{
struct ipmmu_vmsa_archdata *archdata = dev->archdata.iommu;
- struct ipmmu_vmsa_device *mmu = archdata->mmu;
+ struct ipmmu_vmsa_device *root, *mmu = archdata->mmu;
struct ipmmu_vmsa_domain *domain = to_vmsa_domain(io_domain);
unsigned long flags;
unsigned int i;
@@ -535,15 +568,23 @@ static int ipmmu_attach_device(struct io
return -ENXIO;
}
+ root = ipmmu_find_root(archdata->mmu);
+ if (!root) {
+ dev_err(dev, "Unable to locate root IPMMU\n");
+ return -EAGAIN;
+ }
+
spin_lock_irqsave(>lock, flags);
if (!domain->mmu) {
/* The
Re: [PATCH v9] mtd: spi-nor: add hisilicon spi-nor flash controller driver
On 18 March 2016 at 12:52, Jiancheng Xue wrote: > Add hisilicon spi-nor flash controller driver > > Signed-off-by: Binquan Peng > Signed-off-by: Jiancheng Xue > Acked-by: Rob Herring > Reviewed-by: Ezequiel Garcia > --- Reviewed-by: Jagan Teki -- Jagan.
Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64
On 3/16/16, Jeffrey Merkey wrote: > On 3/15/16, Theodore Ts'o wrote: >> On Tue, Mar 15, 2016 at 01:03:39PM +1100, Stephen Rothwell wrote: >>> We don't generally PGP (GPG) sign commits in the kernel tree (so "-S" >>> is not required), just tags. However we always require that anyone who >>> handles a patch adds a Signed-off-by line to the final commit. See >>> Documentation/SubmittingPatches Section 11. >> >> In general all commits should have a Signed-Off-By line added. Once >> the git branch gets merged, it's hard to tell what is the final commit >> and what isn't, and in general different commits will have different >> people needing to vouch for the origins for the contents of that commit. >> >> Cheers, >> >> - Ted >> >> > > Hi Ted, > > I will repost this pull request with a signed-off by line for Linus to > consider.I am not certain who all should be included in the review > and I have to be careful how many email recipients I copy. I will > post to the folks Joe Perches copied. > > Jeff > Well, Joe updated checkpatch.pl so now there are some more areas of cleanup I need to do on the code to remove unsigned casts and replace them with unsigned int. I will resubmit at the next merge window for 4.7. Have not heard a word from Linus about this, Hey Linus, please don't lion-us by throwing us to the lions. :-) Jeff
Re: [PATCH 03/10] iommu/ipmmu-vmsa: Teach xlate() to skip disabled iommus
On Thu, Mar 17, 2016 at 5:29 PM, Magnus Damm wrote:
> From: Magnus Damm
>
> Right now the ->xlate() call gets invoked even though
> the iommu device has status = "disabled" in DT, so
> make sure we skip over disabled devices.
>
> In my mind it would make sense to have this at some
> shared level, but I guess some users may want to
> configure the iommu regardless of DT state.
>
> Signed-off-by: Magnus Damm
> ---
>
> drivers/iommu/ipmmu-vmsa.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> --- 0017/drivers/iommu/ipmmu-vmsa.c
> +++ work/drivers/iommu/ipmmu-vmsa.c 2016-03-18 00:16:51.200513000 +0900
> @@ -890,7 +890,13 @@ static struct iommu_group *ipmmu_device_
> static int ipmmu_of_xlate_dma(struct device *dev,
> struct of_phandle_args *spec)
> {
> - /* dummy callback to satisfy of_iommu_configure() */
> + /* If the IPMMU device is disabled in DT then return error
> +* to make sure the of_iommu code does not install ops
> +* even though the iommu device is disabled
> +*/
> + if (!of_device_is_available(spec->np))
> + return -ENODEV;
> +
> return 0;
I think this should be handled in drivers/iommu/of_iommu.c:of_iommu_init()
instead, cfr. commit 3e5dd6f6e690048d ("clk: Ignore disabled DT clock
providers").
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: rcutorture: Consider FROZEN hotplug notifier transitions
On Thu, Mar 17, 2016 at 11:14:35AM +0100, Anna-Maria Gleixner wrote:
> The hotplug notifier rcutorture_cpu_notify() doesn't consider the
> corresponding CPU_XXX_FROZEN transitions. They occure on
> suspend/resume and are usually handled the same way as the
> corresponding non frozen transitions.
>
> Mask the switch case action argument with '~CPU_TASKS_FROZEN' to map
> CPU_XXX_FROZEN hotplug transitions on corresponding non frozen
> transitions.
>
> Cc: Josh Triplett
> Cc: "Paul E. McKenney"
> Signed-off-by: Anna-Maria Gleixner
Queued for review and testing, thank you! If all goes well, I will
push this into the 4.7 merge window (not the current one, but the
next one).
Thanx, Paul
> ---
> kernel/rcu/rcutorture.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -1598,7 +1598,7 @@ static int rcutorture_cpu_notify(struct
> {
> long cpu = (long)hcpu;
>
> - switch (action) {
> + switch (action & ~CPU_TASKS_FROZEN) {
> case CPU_ONLINE:
> case CPU_DOWN_FAILED:
> (void)rcutorture_booster_init(cpu);
>
[PATCH v2 2/2] mcb: export bus information via sysfs
Export information about the bus stored in the FPGA's header to userspace via
sysfs, instead of hiding it in pr_debug()s from everyone.
Signed-off-by: Johannes Thumshirn
---
Documentation/ABI/testing/sysfs-bus-mcb | 29
drivers/mcb/mcb-core.c | 60 +
drivers/mcb/mcb-internal.h | 1 -
drivers/mcb/mcb-parse.c | 15 +++--
include/linux/mcb.h | 9 +
5 files changed, 103 insertions(+), 11 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-mcb
diff --git a/Documentation/ABI/testing/sysfs-bus-mcb
b/Documentation/ABI/testing/sysfs-bus-mcb
new file mode 100644
index 000..77947c5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-mcb
@@ -0,0 +1,29 @@
+What: /sys/bus/mcb/devices/mcb:X
+Date: March 2016
+KernelVersion: 4.7
+Contact: Johannes Thumshirn
+Description: Hardware chip or device hosting the MEN chameleon bus
+
+What: /sys/bus/mcb/devices/mcb:X/revision
+Date: March 2016
+KernelVersion: 4.7
+Contact: Johannes Thumshirn
+Description: The FPGA's revision number
+
+What: /sys/bus/mcb/devices/mcb:X/minor
+Date: March 2016
+KernelVersion: 4.7
+Contact: Johannes Thumshirn
+Description: The FPGA's minor number
+
+What: /sys/bus/mcb/devices/mcb:X/model
+Date: March 2016
+KernelVersion: 4.7
+Contact: Johannes Thumshirn
+Description: The FPGA's model number
+
+What: /sys/bus/mcb/devices/mcb:X/name
+Date: March 2016
+KernelVersion: 4.7
+Contact: Johannes Thumshirn
+Description: The FPGA's name
diff --git a/drivers/mcb/mcb-core.c b/drivers/mcb/mcb-core.c
index 1e336cc..9ae4d15 100644
--- a/drivers/mcb/mcb-core.c
+++ b/drivers/mcb/mcb-core.c
@@ -90,6 +90,60 @@ static void mcb_shutdown(struct device *dev)
mdrv->shutdown(mdev);
}
+static ssize_t revision_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct mcb_bus *bus = to_mcb_bus(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", bus->revision);
+}
+static DEVICE_ATTR_RO(revision);
+
+static ssize_t model_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct mcb_bus *bus = to_mcb_bus(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%c\n", bus->model);
+}
+static DEVICE_ATTR_RO(model);
+
+static ssize_t minor_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct mcb_bus *bus = to_mcb_bus(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", bus->minor);
+}
+static DEVICE_ATTR_RO(minor);
+
+static ssize_t name_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct mcb_bus *bus = to_mcb_bus(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%s\n", bus->name);
+}
+static DEVICE_ATTR_RO(name);
+
+static struct attribute *mcb_bus_attrs[] = {
+ _attr_revision.attr,
+ _attr_model.attr,
+ _attr_minor.attr,
+ _attr_name.attr,
+ NULL,
+};
+
+static const struct attribute_group mcb_carrier_group = {
+ .attrs = mcb_bus_attrs,
+};
+
+static const struct attribute_group *mcb_carrier_groups[] = {
+ _carrier_group,
+ NULL,
+};
+
+
static struct bus_type mcb_bus_type = {
.name = "mcb",
.match = mcb_match,
@@ -99,6 +153,11 @@ static struct bus_type mcb_bus_type = {
.shutdown = mcb_shutdown,
};
+static struct device_type mcb_carrier_device_type = {
+ .name = "mcb-carrier",
+ .groups = mcb_carrier_groups,
+};
+
/**
* __mcb_register_driver() - Register a @mcb_driver at the system
* @drv: The @mcb_driver
@@ -205,6 +264,7 @@ struct mcb_bus *mcb_alloc_bus(struct device *carrier)
device_initialize(>dev);
bus->dev.parent = carrier;
bus->dev.bus = _bus_type;
+ bus->dev.type = _carrier_device_type;
dev_set_name(>dev, "mcb:%d", bus_nr);
rc = device_add(>dev);
diff --git a/drivers/mcb/mcb-internal.h b/drivers/mcb/mcb-internal.h
index fb7493d..5254e02 100644
--- a/drivers/mcb/mcb-internal.h
+++ b/drivers/mcb/mcb-internal.h
@@ -5,7 +5,6 @@
#define PCI_VENDOR_ID_MEN 0x1a88
#define PCI_DEVICE_ID_MEN_CHAMELEON0x4d45
-#define CHAMELEON_FILENAME_LEN 12
#define CHAMELEONV2_MAGIC 0xabce
#define CHAM_HEADER_SIZE 0x200
diff --git a/drivers/mcb/mcb-parse.c b/drivers/mcb/mcb-parse.c
index 0049269..35f385b 100644
--- a/drivers/mcb/mcb-parse.c
+++ b/drivers/mcb/mcb-parse.c
@@ -113,16 +113,11 @@ int chameleon_parse_cells(struct mcb_bus *bus,
phys_addr_t mapbase,
}
p += hsize;
- pr_debug("header->revision = %d\n", header->revision);
- pr_debug("header->model = 0x%x ('%c')\n", header->model,
- header->model);
- pr_debug("header->minor =
Re: linux-next: Tree for Feb 24
On Thu, Mar 17, 2016 at 11:27 AM, Stephen Rothwell wrote: > Hi Sedat, > > On Thu, 17 Mar 2016 11:21:56 +0100 Sedat Dilek wrote: >> >> not seeing this anymore. >> How was that solved? > > The code has been removed while it is further worked on and reviewed > and may reappear after -rc1 is released. > Thanks! - sed@ -
Re: [PATCH v14 11/17] drm: bridge: analogix/dp: add some rk3288 special registers setting
在 2016年02月15日 19:10, Yakir Yang 写道:
RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.
Signed-off-by: Yakir Yang
Tested-by: Caesar Wang
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 76 ++-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 12
2 files changed, 60 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 3858df5..1e24b37 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -15,6 +15,8 @@
#include
#include
+#include
+
#include "analogix_dp_core.h"
#include "analogix_dp_reg.h"
@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device *dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+ writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+ writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+ writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+ writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+ writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+ }
+
In general, I will say what's mean for the number.
Okay that's the rk3288 special registers setting.
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
bool enable)
{
u32 reg;
+ u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+ phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH0_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH1_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH2_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH2_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base +
Re: [PATCH] iio: add driver for Microchip MCP414X/416X/424X/426X
On 03/16/2016 05:25 PM, Slawomir Stepien wrote: > On Mar 16, 2016 13:30, Peter Meerwald-Stadler wrote: [...] >> plenty of the private API, some of which seems to be debug only? >> what is really needed to interact with a poti? > > I wanted to export both the non volatile and volatile memory addresses for > wiper > position access. That is bare minimum for the poti to operate. > > But I also wanted to export additional features of this chip. That is way > there > is increase and decrease API, and STATUS and TCON register access. > The important part about a framework and the associated device drivers is to expose the features of a device using a standardized interface so you can write generic applications/libraries and share infrastructure. If an application requires device specific knowledge to access the features of a device you may as well write a userspace driver using i2cdev. So when you are introducing new ABI it should at least follow the standard naming scheme. And also try to think whether this is a feature that is present in other similar devices and come up with a device independent way to expose this functionality. Let's start with the simple stuff, I don't really see the advantage of having separate inc/dec controls. This can be handled through the standard raw attribute. If the newly written value is one off from the previous one use inc/dec otherwise write it directly. And even then it might make sense to just ignore that and always write the raw value. > The memory_map API is a way to access all the not used by chip memory > addresses. > This API I think could be deleted. But I still think that some people might > find > it useful. This sounds more like it should maybe be exposed as a standard EEPROM device.
Re: [PATCH] ACPI / property: Export a couple of symbols.
On 03/17/2016 06:00 AM, Rafael J. Wysocki wrote: On Thu, Mar 17, 2016 at 9:09 AM, Mika Westerberg wrote: On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote: From: David Daney The acpi_dev_prop_read() and acpi_dev_prop_read_single() can be called by drivers. Add EXPORT_SYMBOL_GPL to them to allow use by modular drivers. This makes them consistent with acpi_dev_get_property() and acpi_node_get_property_reference() which are already exported. Signed-off-by: David Daney --- FWIW: We hope to submit soon Cavium Thunder networking patches that fail under modular builds without these exports. You should not be using these functions directly in drivers. That's exactly my point. OK, for the sake of argument I will concede that my particular use of acpi_dev_prop_read_single() is incorrect. Let me ask you this: What is the point of the code in drivers/acpi/property.c? acpi_dev_prop_read() and acpi_dev_prop_read_single() are not used anywhere that I can see in the kernel, would you accept a patch to remove them? But from a philosophical point of view, what is the underlying problem of having drivers extract property information from the ACPI tables corresponding to the devices they control. Specifically, I am trying to understand how to port drivers that currently successfully use OF device tree so that they are usable in systems with ACPI based firmware. Thanks in advance, David Daney
[GIT PULL] dlm updates for 4.6
Hi Linus, Please pull dlm updates from tag: git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm.git dlm-4.6 Previous changes introduced the use of socket error reporting for dlm sockets. This set includes two fixes in how the socket error callbacks are used. Thanks, Dave Bob Peterson (2): DLM: Replace nodeid_to_addr with kernel_getpeername DLM: Save and restore socket callbacks properly fs/dlm/lowcomms.c | 74 ++- 1 file changed, 62 insertions(+), 12 deletions(-)
[PATCH 2/4] efi: Capsule update support
The EFI capsule mechanism allows data blobs to be passed to the EFI
firmware. A common use case is performing firmware updates. This patch
just introduces the main infrastructure for interacting with the
firmware, and a driver that allows users to upload capsules will come
in a later patch.
Once a capsule has been passed to the firmware, the next reboot must
be performed using the ResetSystem() EFI runtime service, which may
involve overriding the reboot type specified by reboot=. This ensures
the reset value returned by QueryCapsuleCapabilities() is used to
reset the system, which is required for the capsule to be processed.
efi_capsule_pending() is provided for this purpose.
At the moment we only allow a single capsule blob to be sent to the
firmware despite the fact that UpdateCapsule() takes a 'CapsuleCount'
parameter. This simplifies the API and shouldn't result in any
downside since it is still possible to send multiple capsules by
repeatedly calling UpdateCapsule().
Cc: Kweh Hock Leong
Cc: Borislav Petkov
Cc: Ard Biesheuvel
Cc: Mark Salter
Cc: Peter Jones
Cc: joeyli
Cc: Bryan O'Donoghue
Signed-off-by: Matt Fleming
---
drivers/firmware/efi/Makefile | 2 +-
drivers/firmware/efi/capsule.c | 286 +
drivers/firmware/efi/reboot.c | 12 +-
include/linux/efi.h| 14 ++
4 files changed, 312 insertions(+), 2 deletions(-)
create mode 100644 drivers/firmware/efi/capsule.c
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 62e654f255f4..e4468c7c16b5 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -9,7 +9,7 @@
#
KASAN_SANITIZE_runtime-wrappers.o := n
-obj-$(CONFIG_EFI) += efi.o vars.o reboot.o
+obj-$(CONFIG_EFI) += efi.o vars.o reboot.o capsule.o
obj-$(CONFIG_EFI_VARS) += efivars.o
obj-$(CONFIG_EFI_ESRT) += esrt.o
obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o
diff --git a/drivers/firmware/efi/capsule.c b/drivers/firmware/efi/capsule.c
new file mode 100644
index ..dac25208ad5e
--- /dev/null
+++ b/drivers/firmware/efi/capsule.c
@@ -0,0 +1,286 @@
+/*
+ * EFI capsule support.
+ *
+ * Copyright 2013 Intel Corporation; author Matt Fleming
+ *
+ * This file is part of the Linux kernel, and is made available under
+ * the terms of the GNU General Public License version 2.
+ */
+
+#define pr_fmt(fmt) "efi: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+typedef struct {
+ u64 length;
+ u64 data;
+} efi_capsule_block_desc_t;
+
+static bool capsule_pending;
+static int efi_reset_type = -1;
+
+/*
+ * capsule_mutex serialises access to both capsule_pending and
+ * efi_reset_type.
+ */
+static DEFINE_MUTEX(capsule_mutex);
+
+/**
+ * efi_capsule_pending - has a capsule been passed to the firmware?
+ * @reset_type: store the type of EFI reset if capsule is pending
+ *
+ * To ensure that the registered capsule is processed correctly by the
+ * firmware we need to perform a specific type of reset. If a capsule is
+ * pending return the reset type in @reset_type.
+ *
+ * This function will race with callers of efi_capsule_update(), for
+ * example, calling this function while somebody else is in
+ * efi_capsule_update() but hasn't reached efi_capsue_update_locked()
+ * will miss the updates to capsule_pending and efi_reset_type after
+ * efi_capsule_update_locked() completes.
+ *
+ * A non-racy use is from platform reboot code because we use
+ * system_state to ensure no capsules can be sent to the firmware once
+ * we're at SYSTEM_RESTART. See efi_capsule_update_locked().
+ */
+bool efi_capsule_pending(int *reset_type)
+{
+ bool rv = false;
+
+ mutex_lock(_mutex);
+ if (!capsule_pending)
+ goto out;
+
+ if (reset_type)
+ *reset_type = efi_reset_type;
+ rv = true;
+out:
+ mutex_unlock(_mutex);
+ return rv;
+}
+
+/**
+ * efi_capsule_supported - does the firmware support the capsule?
+ * @guid: vendor guid of capsule
+ * @flags: capsule flags
+ * @size: size of capsule data
+ * @reset: the reset type required for this capsule
+ *
+ * Check whether a capsule with @flags is supported by the firmware
+ * and that @size doesn't exceed the maximum size for a capsule.
+ *
+ * No attempt is made to check @reset against the reset type required
+ * by any pending capsules because of the races involved.
+ */
+int efi_capsule_supported(efi_guid_t guid, u32 flags, size_t size, int *reset)
+{
+ efi_capsule_header_t *capsule;
+ efi_status_t status;
+ u64 max_size;
+ int rv = 0;
+
+ capsule = kmalloc(sizeof(*capsule), GFP_KERNEL);
+ if (!capsule)
+ return -ENOMEM;
+
+ capsule->headersize = capsule->imagesize = sizeof(*capsule);
+ memcpy(>guid, , sizeof(efi_guid_t));
+ capsule->flags = flags;
+
+ status = efi.query_capsule_caps(,
Re: [PATCH v5 7/7][Update] cpufreq: schedutil: New governor based on scheduler utilization data
On Thu, Mar 17, 2016 at 12:30 PM, Juri Lelli wrote:
> Hi Rafael,
>
> On 17/03/16 01:01, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki
>
> [...]
>
>> +static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
>> + unsigned int next_freq)
>> +{
>> + struct cpufreq_policy *policy = sg_policy->policy;
>> +
>> + sg_policy->last_freq_update_time = time;
>> +
>> + if (policy->fast_switch_enabled) {
>> + if (next_freq > policy->max)
>> + next_freq = policy->max;
>> + else if (next_freq < policy->min)
>> + next_freq = policy->min;
>> +
>> + if (sg_policy->next_freq == next_freq) {
>> + trace_cpu_frequency(policy->cur, smp_processor_id());
>> + return;
>> + }
>> + sg_policy->next_freq = next_freq;
>> + next_freq = cpufreq_driver_fast_switch(policy, next_freq);
>> + if (next_freq == CPUFREQ_ENTRY_INVALID)
>> + return;
>> +
>> + policy->cur = next_freq;
>> + trace_cpu_frequency(next_freq, smp_processor_id());
>> + } else if (sg_policy->next_freq != next_freq) {
>> + sg_policy->work_cpu = smp_processor_id();
>
> + sg_policy->next_freq = next_freq;
>
Doh.
>> + irq_work_queue(_policy->irq_work);
>> + }
>> +}
>
> Or we remain at max_f :-).
Sure, thanks!
Will fix.
[PATCH v4 1/7] cpufreq: sched: Helpers to add and remove update_util hooks
From: Rafael J. Wysocki
Replace the single helper for adding and removing cpufreq utilization
update hooks, cpufreq_set_update_util_data(), with a pair of helpers,
cpufreq_add_update_util_hook() and cpufreq_remove_update_util_hook(),
and modify the users of cpufreq_set_update_util_data() accordingly.
With the new helpers, the code using them doesn't need to worry
about the internals of struct update_util_data and in particular
it doesn't need to worry about populating the func field in it
properly upfront.
Signed-off-by: Rafael J. Wysocki
---
New patch.
---
drivers/cpufreq/cpufreq_governor.c | 76 ++---
drivers/cpufreq/intel_pstate.c |8 +--
include/linux/sched.h |5 +-
kernel/sched/cpufreq.c | 48 ++-
4 files changed, 83 insertions(+), 54 deletions(-)
Index: linux-pm/include/linux/sched.h
===
--- linux-pm.orig/include/linux/sched.h
+++ linux-pm/include/linux/sched.h
@@ -3213,7 +3213,10 @@ struct update_util_data {
u64 time, unsigned long util, unsigned long max);
};
-void cpufreq_set_update_util_data(int cpu, struct update_util_data *data);
+void cpufreq_add_update_util_hook(int cpu, struct update_util_data *data,
+ void (*func)(struct update_util_data *data, u64 time,
+unsigned long util, unsigned long max));
+void cpufreq_remove_update_util_hook(int cpu);
#endif /* CONFIG_CPU_FREQ */
#endif
Index: linux-pm/kernel/sched/cpufreq.c
===
--- linux-pm.orig/kernel/sched/cpufreq.c
+++ linux-pm/kernel/sched/cpufreq.c
@@ -14,24 +14,50 @@
DEFINE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
/**
- * cpufreq_set_update_util_data - Populate the CPU's update_util_data pointer.
+ * cpufreq_add_update_util_hook - Populate the CPU's update_util_data pointer.
* @cpu: The CPU to set the pointer for.
* @data: New pointer value.
+ * @func: Callback function to set for the CPU.
*
- * Set and publish the update_util_data pointer for the given CPU. That
pointer
- * points to a struct update_util_data object containing a callback function
- * to call from cpufreq_update_util(). That function will be called from an
RCU
- * read-side critical section, so it must not sleep.
+ * Set and publish the update_util_data pointer for the given CPU.
*
- * Callers must use RCU-sched callbacks to free any memory that might be
- * accessed via the old update_util_data pointer or invoke synchronize_sched()
- * right after this function to avoid use-after-free.
+ * The update_util_data pointer of @cpu is set to @data and the callback
+ * function pointer in the target struct update_util_data is set to @func.
+ * That function will be called by cpufreq_update_util() from RCU-sched
+ * read-side critical sections, so it must not sleep. @data will always be
+ * passed to it as the first argument which allows the function to get to the
+ * target update_util_data structure and its container.
+ *
+ * The update_util_data pointer of @cpu must be NULL when this function is
+ * called or it will WARN() and return with no effect.
*/
-void cpufreq_set_update_util_data(int cpu, struct update_util_data *data)
+void cpufreq_add_update_util_hook(int cpu, struct update_util_data *data,
+ void (*func)(struct update_util_data *data, u64 time,
+unsigned long util, unsigned long max))
{
- if (WARN_ON(data && !data->func))
+ if (WARN_ON(!data || !func))
return;
+ if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu)))
+ return;
+
+ data->func = func;
rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), data);
}
-EXPORT_SYMBOL_GPL(cpufreq_set_update_util_data);
+EXPORT_SYMBOL_GPL(cpufreq_add_update_util_hook);
+
+/**
+ * cpufreq_remove_update_util_hook - Clear the CPU's update_util_data pointer.
+ * @cpu: The CPU to clear the pointer for.
+ *
+ * Clear the update_util_data pointer for the given CPU.
+ *
+ * Callers must use RCU-sched callbacks to free any memory that might be
+ * accessed via the old update_util_data pointer or invoke synchronize_sched()
+ * right after this function to avoid use-after-free.
+ */
+void cpufreq_remove_update_util_hook(int cpu)
+{
+ rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), NULL);
+}
+EXPORT_SYMBOL_GPL(cpufreq_remove_update_util_hook);
Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -258,43 +258,6 @@ unsigned int dbs_update(struct cpufreq_p
}
EXPORT_SYMBOL_GPL(dbs_update);
-static void gov_set_update_util(struct policy_dbs_info *policy_dbs,
-
[PATCH v3 15/15] dmaengine: dw: set cdesc to NULL when free cyclic transfers
To be sure we have the cyclic transfers already gone we set cdesc to NULL. It will prevent the double free. Signed-off-by: Andy Shevchenko --- drivers/dma/dw/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c index 78be785..86e55ab 100644 --- a/drivers/dma/dw/core.c +++ b/drivers/dma/dw/core.c @@ -1493,6 +1493,8 @@ void dw_dma_cyclic_free(struct dma_chan *chan) kfree(cdesc->desc); kfree(cdesc); + dwc->cdesc = NULL; + clear_bit(DW_DMA_IS_CYCLIC, >flags); } EXPORT_SYMBOL(dw_dma_cyclic_free); -- 2.7.0
Re: [PATCH 07/15] irqdomain: Don't set type when mapping an IRQ
On 17/03/16 14:19, Jon Hunter wrote:
> Some IRQ chips, such as GPIO controllers or secondary level interrupt
> controllers, may require require additional runtime power management
> control to ensure they are accessible. For such IRQ chips, it makes sense
> to enable the IRQ chip when interrupts are requested and disabled them
> again once all interrupts have been freed.
>
> When mapping an IRQ, the IRQ type settings are read and then programmed.
> The mapping of the IRQ happens before the IRQ is requested and so the
> programming of the type settings occurs before the IRQ is requested. This
> is a problem for IRQ chips that require additional power management
> control because they may not be accessible yet. Therefore, when mapping
> the IRQ, don't program the type settings, just save them and then program
> these saved settings when the IRQ is requested (so long as if they are not
> overridden via the call to request the IRQ).
>
> Add a stub function for irq_domain_free_irqs() to avoid any compilation
> errors when CONFIG_IRQ_DOMAIN_HIERARCHY is not selected.
>
> Signed-off-by: Jon Hunter
> ---
> include/linux/irqdomain.h | 3 +++
> kernel/irq/irqdomain.c| 18 ++
> kernel/irq/manage.c | 7 +++
> 3 files changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index 2aed04396210..fc66876d1965 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -440,6 +440,9 @@ static inline int irq_domain_alloc_irqs(struct irq_domain
> *domain,
> return -1;
> }
>
> +static inline void irq_domain_free_irqs(unsigned int virq,
> + unsigned int nr_irqs) { }
> +
> static inline bool irq_domain_is_hierarchy(struct irq_domain *domain)
> {
> return false;
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 0ea285baa619..332bee2205e0 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -576,6 +576,7 @@ static void of_phandle_args_to_fwspec(struct
> of_phandle_args *irq_data,
> unsigned int irq_create_fwspec_mapping(struct irq_fwspec *fwspec)
> {
> struct irq_domain *domain;
> + struct irq_data *irq_data;
> irq_hw_number_t hwirq;
> unsigned int cur_type = IRQ_TYPE_NONE;
> unsigned int type = IRQ_TYPE_NONE;
> @@ -638,10 +639,19 @@ unsigned int irq_create_fwspec_mapping(struct
> irq_fwspec *fwspec)
> return 0;
> }
>
> - /* Set type if specified and different than the current one */
> - if (type != IRQ_TYPE_NONE &&
> - type != irq_get_trigger_type(virq))
> - irq_set_irq_type(virq, type);
> + irq_data = irq_get_irq_data(virq);
> + if (!irq_data) {
> + if (irq_domain_is_hierarchy(domain))
> + irq_domain_free_irqs(virq, 1);
> + else
> + irq_dispose_mapping(virq);
> +
> + return 0;
> + }
I should only free/dispose here if we actually created it! Will fix this
as well :-(
Jon
Re: [PATCH] trace: irqsoff: Fix function tracing in preempt and preemptirqsoff tracers
This should fix the issue for you. This probably should be added to stable as well (I'll add a tag). -- Steve >From e79b49b73079d4320a6ad08eb91d3c92cfef6e6a Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" Date: Fri, 18 Mar 2016 12:27:43 -0400 Subject: [PATCH] tracing: Have preempt(irqs)off trace preempt disabled functions Joel Fernandes reported that the function tracing of preempt disabled sections was not being reported when running either the preemptirqsoff or preemptoff tracers. This was due to the fact that the function tracer callback for those tracers checked if irqs were disabled before tracing. But this fails when we want to trace preempt off locations as well. Joel explained that he wanted to see funcitons where interrupts are enabled but preemption was disabled. The expected output he wanted: <...>-22651d.h1 3419us : preempt_count_sub <-irq_exit <...>-22651d..1 3419us : __do_softirq <-irq_exit <...>-22651d..1 3419us : msecs_to_jiffies <-__do_softirq <...>-22651d..1 3420us : irqtime_account_irq <-__do_softirq <...>-22651d..1 3420us : __local_bh_disable_ip <-__do_softirq <...>-22651..s1 3421us : run_timer_softirq <-__do_softirq <...>-22651..s1 3421us : hrtimer_run_pending <-run_timer_softirq <...>-22651..s1 3421us : _raw_spin_lock_irq <-run_timer_softirq <...>-22651d.s1 3422us : preempt_count_add <-_raw_spin_lock_irq <...>-22651d.s2 3422us : _raw_spin_unlock_irq <-run_timer_softirq <...>-22651..s2 3422us : preempt_count_sub <-_raw_spin_unlock_irq <...>-22651..s1 3423us : rcu_bh_qs <-__do_softirq <...>-22651d.s1 3423us : irqtime_account_irq <-__do_softirq <...>-22651d.s1 3423us : __local_bh_enable <-__do_softirq There's a comment saying that the irq disabled check is because there's a possible race that tracing_cpu may be set when the function is executed. But I don't remember that race. For now, I added a check for preemption being enabled too to not record the function, as there would be no race if that was the case. I need to re-investigate this, as I'm now thinking that the tracing_cpu will always be correct. But no harm in keeping the check for now, except for the slight performance hit. Link: http://lkml.kernel.org/r/1457770386-88717-1-git-send-email-agnel.j...@gmail.com Reported-by: Joel Fernandes Signed-off-by: Steven Rostedt --- kernel/trace/trace_irqsoff.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c index e4e56589ec1d..be3222b7d72e 100644 --- a/kernel/trace/trace_irqsoff.c +++ b/kernel/trace/trace_irqsoff.c @@ -109,8 +109,12 @@ static int func_prolog_dec(struct trace_array *tr, return 0; local_save_flags(*flags); - /* slight chance to get a false positive on tracing_cpu */ - if (!irqs_disabled_flags(*flags)) + /* +* Slight chance to get a false positive on tracing_cpu, +* although I'm starting to think there isn't a chance. +* Leave this for now just to be paranoid. +*/ + if (!irqs_disabled_flags(*flags) && !preempt_count()) return 0; *data = per_cpu_ptr(tr->trace_buffer.data, cpu); -- 1.8.3.1
Re: Suspicious error for CMA stress test
On 03/17/2016 04:52 PM, Joonsoo Kim wrote:
> 2016-03-18 0:43 GMT+09:00 Vlastimil Babka :
>>
>> Okay. I used following slightly optimized version and I need to
>> add 'max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1)'
>> to yours. Please consider it, too.
>
> Hmm, this one is not work, I still can see the bug is there after
> applying
> this patch, did I miss something?
I may find that there is a bug which was introduced by me some time
ago. Could you test following change in __free_one_page() on top of
Vlastimil's patch?
-page_idx = pfn & ((1 << max_order) - 1);
+page_idx = pfn & ((1 << MAX_ORDER) - 1);
>>>
>>>
>>> I tested Vlastimil's patch + your change with stress for more than half
>>> hour, the bug
>>> I reported is gone :)
>>
>>
>> Oh, ok, will try to send proper patch, once I figure out what to write in
>> the changelog :)
>
> Thanks in advance!
>
OK, here it is. Hanjun can you please retest this, as I'm not sure if you had
the same code due to the followup one-liner patches in the thread. Lucas, see if
it helps with your issue as well. Laura and Joonsoo, please also test and review
and check changelog if my perception of the problem is accurate :)
Thanks
8<
From: Vlastimil Babka
Date: Fri, 18 Mar 2016 14:22:31 +0100
Subject: [PATCH] mm/page_alloc: prevent merging between isolated and other
pageblocks
Hanjun Guo has reported that a CMA stress test causes broken accounting of
CMA and free pages:
> Before the test, I got:
> -bash-4.3# cat /proc/meminfo | grep Cma
> CmaTotal: 204800 kB
> CmaFree: 195044 kB
>
>
> After running the test:
> -bash-4.3# cat /proc/meminfo | grep Cma
> CmaTotal: 204800 kB
> CmaFree: 6602584 kB
>
> So the freed CMA memory is more than total..
>
> Also the the MemFree is more than mem total:
>
> -bash-4.3# cat /proc/meminfo
> MemTotal: 16342016 kB
> MemFree:22367268 kB
> MemAvailable: 22370528 kB
Laura Abbott has confirmed the issue and suspected the freepage accounting
rewrite around 3.18/4.0 by Joonsoo Kim. Joonsoo had a theory that this is
caused by unexpected merging between MIGRATE_ISOLATE and MIGRATE_CMA
pageblocks:
> CMA isolates MAX_ORDER aligned blocks, but, during the process,
> partialy isolated block exists. If MAX_ORDER is 11 and
> pageblock_order is 9, two pageblocks make up MAX_ORDER
> aligned block and I can think following scenario because pageblock
> (un)isolation would be done one by one.
>
> (each character means one pageblock. 'C', 'I' means MIGRATE_CMA,
> MIGRATE_ISOLATE, respectively.
>
> CC -> IC -> II (Isolation)
> II -> CI -> CC (Un-isolation)
>
> If some pages are freed at this intermediate state such as IC or CI,
> that page could be merged to the other page that is resident on
> different type of pageblock and it will cause wrong freepage count.
This was supposed to be prevented by CMA operating on MAX_ORDER blocks, but
since it doesn't hold the zone->lock between pageblocks, a race window does
exist.
It's also likely that unexpected merging can occur between MIGRATE_ISOLATE
and non-CMA pageblocks. This should be prevented in __free_one_page() since
commit 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated
pageblock"). However, we only check the migratetype of the pageblock where
buddy merging has been initiated, not the migratetype of the buddy pageblock
(or group of pageblocks) which can be MIGRATE_ISOLATE.
Joonsoo has suggested checking for buddy migratetype as part of
page_is_buddy(), but that would add extra checks in allocator hotpath and
bloat-o-meter has shown significant code bloat (the function is inline).
This patch reduces the bloat at some expense of more complicated code. The
buddy-merging while-loop in __free_one_page() is initially bounded to
pageblock_border and without any migratetype checks. The checks are placed
outside, bumping the max_order if merging is allowed, and returning to the
while-loop with a statement which can't be possibly considered harmful.
This fixes the accounting bug and also removes the arguably weird state in the
original commit 3c605096d315 where buddies could be left unmerged.
Fixes: 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated
pageblock")
Link: https://lkml.org/lkml/2016/3/2/280
Reported-by: Hanjun Guo
Debugged-by: Laura Abbott
Debugged-by: Joonsoo Kim
Signed-off-by: Vlastimil Babka
Cc: # 3.18+
---
mm/page_alloc.c | 46 +-
1 file changed, 33 insertions(+), 13 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c46b75d14b6f..112a5d5cec51 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -683,34 +683,28 @@ static inline void __free_one_page(struct page *page,
unsigned long combined_idx;
unsigned long uninitialized_var(buddy_idx);
struct page *buddy;
- unsigned int max_order = MAX_ORDER;
+ unsigned int
Re: [RFC] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data
On Wed, Mar 16, 2016 at 09:05:06PM -0700, Peter Hurley wrote: > > Here is a new ioctl code which simply copies data from read buffer > > into the userspace without any additional processing (just like > > terminal is sitting in a raw mode). > > Maybe I'm overlooking something obvious, but why not do just that; > ie., save the termios, reset termios to raw mode and read the entire > ldisc read buffer? > > Note that saving and resetting termios to raw mode is only necessary > for the slave side, as the master side is always in raw mode. Hi Peter! Yes we can do that, but there is one significant problem: when we read the buffer (draining it) and then during later stages of checkpoint something fails -- we need to bring the dumping program back to the former state so it won't notice that someone has been dumping it. Which means code flow like - read ldisk buffer - ... some other work for checkpoint sake ... - ... obtained some error ... - write ldisk buffer back to restore original content and if here write fails (for any reason), the program being dupmed will loose ldisk buffer content. we simply can't allow this to happen because otherwise checkpoint will work in destructive way. Moreover there is an option in criu where we allow to dump program and leave it in running state, say someone needs a snapshot of a state, thus we always must work in non- destructive manner. Sure, not modifying the kernel would be a preferred way for me too. > > Then, two options for restore are: > 1) set termios to raw mode, write to peer, restore the saved termios; or > 2) restore the saved termios and write to peer. > > option 1 will preserve the contents as read but not preserve the line > termination state; ie., it will be possible to read multiple lines > with a single canonical read. > > option 2 will preserve the line termination state (for the most part) > but not necessarily the contents which might be re-interpreted. > > These two options are not necessarily exclusive; it may be possible > to construct a mixed mode for restore based on the original saved > termios that reconstitutes both line termination state and read buffer > contents. > > One thing not accounted for is the column position.
Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity
On 15/03/16 20:46, Michael Turquette wrote: > Quoting Dietmar Eggemann (2016-03-15 12:13:58) >> On 14/03/16 05:22, Michael Turquette wrote: [...] >> For me this independence of the scheduler code towards the actual >> implementation of the Frequency Invariant Engine (FEI) was actually a >> feature. > > I do not agree that it is a strength; I think it is confusing. My > opinion is that cpufreq drivers should implement > arch_scale_freq_capacity. Having a sane fallback > (cpufreq_scale_freq_capacity) simply means that you can remove the > boilerplate from the arm32 and arm64 code, which is a win. > > Furthermore, if we have multiple competing implementations of > arch_scale_freq_invariance, wouldn't it be better for all of them to > live in cpufreq drivers? This means we would only need to implement a > single run-time "selector". > > On the other hand, if the implementation lives in arch code and we have > various implementations of arch_scale_freq_capacity within an > architecture, then each arch would need to implement this selector > function. Even worse then if we have a split where some implementations > live in drivers/cpufreq (e.g. intel_pstate) and others in arch/arm and > others in arch/arm64 ... now we have three selectors. OK, now I see your point. What I don't understand is the fact why you want different foo_scale_freq_capacity() implementations per cpufreq drivers. IMHO we want to do the cpufreq.c based implementation to abstract from that (at least for target_index() cpufreq drivers). intel_pstate (setpolicy()) is an exception but my humble guess is that systems with intel_pstate driver have X86_FEATURE_APERFMPERF support. > Note that this has nothing to do with cpu microarch invariance. I'm > happy for that to stay in arch code because we can have heterogeneous > cpus that do not scale frequency, and thus would not enable cpufreq. > But if your platform scales cpu frequency, then really cpufreq should be > in the loop. Agreed. > >> >> In EAS RFC5.2 (linux-arm.org/linux-power.git energy_model_rfc_v5.2 , >> which hasn't been posted to LKML) we establish the link in the ARCH code >> (arch/arm64/include/asm/topology.h). > > Right, sorry again about preemptively posting the patch. Total brainfart > on my part. > >> >> #ifdef CONFIG_CPU_FREQ >> #define arch_scale_freq_capacity cpufreq_scale_freq_capacity >> ... >> +#endif > > The above is no longer necessary with this patch. Same question as > above: why insist on the arch boilerplate? OK. [...]
Re: [GIT PULL] remoteproc updates for v4.6
On Thu, Mar 17, 2016 at 3:27 AM, Linus Torvalds wrote: > On Mon, Mar 14, 2016 at 10:54 PM, Bjorn Andersson > wrote: >> >> New driver for controlling ST's remote processors and a couple of minor >> fixes. Also includes the addition of myself as co-maintainer. > > So I don't have any issue with this, but I _do_ want to get acks from > the person I used to pull from before I switch to pulling from another > person. > > Ohad? Acked-by: Ohad Ben-Cohen Thanks, Ohad.
[PATCH 7/8] lib/mpi: mpi_read_buffer(): replace open coded endian conversion
Currently, the endian conversion from CPU order to BE is open coded in
mpi_read_buffer().
Replace this by the centrally provided cpu_to_be*() macros.
Copy from the temporary storage on stack to the destination buffer
by means of memcpy().
Signed-off-by: Nicolai Stange
---
lib/mpi/mpicoder.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index 2fd8d41..a999ee1 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "mpi-internal.h"
#define MAX_EXTERN_MPI_BITS 16384
@@ -164,7 +165,13 @@ int mpi_read_buffer(MPI a, uint8_t *buf, unsigned buf_len,
unsigned *nbytes,
int *sign)
{
uint8_t *p;
- mpi_limb_t alimb;
+#if BYTES_PER_MPI_LIMB == 4
+ __be32 alimb;
+#elif BYTES_PER_MPI_LIMB == 8
+ __be64 alimb;
+#else
+#error please implement for this limb size.
+#endif
unsigned int n = mpi_get_size(a);
int i, lzeros;
@@ -187,25 +194,15 @@ int mpi_read_buffer(MPI a, uint8_t *buf, unsigned
buf_len, unsigned *nbytes,
for (i = a->nlimbs - 1 - lzeros / BYTES_PER_MPI_LIMB,
lzeros %= BYTES_PER_MPI_LIMB;
i >= 0; i--) {
- alimb = a->d[i];
#if BYTES_PER_MPI_LIMB == 4
- *p++ = alimb >> 24;
- *p++ = alimb >> 16;
- *p++ = alimb >> 8;
- *p++ = alimb;
+ alimb = cpu_to_be32(a->d[i]);
#elif BYTES_PER_MPI_LIMB == 8
- *p++ = alimb >> 56;
- *p++ = alimb >> 48;
- *p++ = alimb >> 40;
- *p++ = alimb >> 32;
- *p++ = alimb >> 24;
- *p++ = alimb >> 16;
- *p++ = alimb >> 8;
- *p++ = alimb;
+ alimb = cpu_to_be64(a->d[i]);
#else
#error please implement for this limb size.
#endif
-
+ memcpy(p, , BYTES_PER_MPI_LIMB);
+ p += BYTES_PER_MPI_LIMB;
if (lzeros > 0) {
mpi_limb_t *limb1 = (void *)p - sizeof(alimb);
mpi_limb_t *limb2 = (void *)p - sizeof(alimb)
--
2.7.2
Re: [PATCH 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single
On Thu, Mar 17, 2016 at 07:17:24PM -0400, ok...@codeaurora.org wrote: > What is the correct way? I don't want to write engine->sram_dma = sram Well, what the driver _is_ wanting to do is to go from a CPU physical address to a device DMA address. phys_to_dma() looks like the correct thing there to me, but I guess that's just an offset and doesn't take account of any IOMMU that may be in the way. If you have an IOMMU, then the whole phys_to_dma() thing is a total failure as it only does a linear translation, and there are no interfaces in the kernel to take account of an IOMMU in the way. So, it needs something designed for the job, implemented and discussed by the normal methods of proposing a new cross-arch interface for drivers to use. What I'm certain of, though, is that the change proposed in this patch will break current users of this driver: virt_to_page() on an address returned by ioremap() is completely undefined, and will result in either a kernel oops, or if not poking at memory which isn't a struct page, ultimately resulting in something that isn't SRAM being pointed to by "engine->sram_dma". -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH V5 02/10] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header
Hi Boris, On 03/18/2016 04:04 PM, Borislav Petkov wrote: On Fri, Mar 18, 2016 at 02:07:25PM +0700, Suravee Suthikulpanit wrote: Actually the exposed APIs (in both files) are from the AMD IOMMU driver, which is not necessary x86-specific. They mostly use struct pci_dev, which is also arch-agnostic. It is correct that the current IOMMU IP is only available in x86 systems. However, if AMD plans to use the IOMMU IP in the ARM-based processors in the future, putting these into include/linux/amd-iommu.h would work better. Let's wait until AMD does that then. Moving the header is the easiest part. But the whole point is that since we are moving it to consolidate these duplicated declarations, I think we should just put it in the most common place. The include/linux/amd-iommu.h file is already there. It's not like we have to create a brand new file, and then having to move it later. Regards, Suravee
[PATCH v3 00/15] Fixes / cleanups in dw_dmac (affects on few subsystems)
This patch series (v2: http://www.spinics.net/lists/dmaengine/msg08274.html) contains a number of mostly minor fixes and cleanups for the DW DMA driver. A couple of them affect the DT binding so these may need to be updated to maintain compatibility. The rest should be relatively straight-forward. This version has been tested on the following bare metal platforms: - ATNGW100 (avr32 based platform) with MMC - Sam460ex (powerpc 44x based platform) with SATA - Intel Braswell with UART - Intel Galileo (Intel Quark based platform) with UART (SATA driver and Intel Galileo UART support are based on this series and not available in upstream yet) Vinod, there are few patch sets developed on top of this one, so, the idea is to keep this in an immuutable branch / tag. Changes since v2: - add patch 1 to fix master selection which was broken for long time - remove "use field-by-field initialization" patch since like Mans metioned in has mostly no value and even might increase error prone - rebase on top of recent linux-next - wide testing on several platforms Changes since v1: - zeroing struct dw_dma_slave before use - fall back to old data_width property if data-width is not found - append tags for few patches - correct title of cover letter - rebase on top of recent linux-next Andy Shevchenko (11): dmaengine: dw: fix master selection dmaengine: dw: rename masters to reflect actual topology dmaengine: dw: substitute dma_read_byaddr by dma_readl_native dmaengine: dw: revisit data_width property dmaengine: dw: define counter variables as unsigned int dmaengine: dw: keep entire platform data in struct dw_dma dmaengine: dw: pass platform data via struct dw_dma_chip dmaengine: dw: move dwc->paused to dwc->flags dmaengine: dw: move dwc->initialized to dwc->flags dmaengine: dw: move residue to a descriptor dmaengine: dw: set cdesc to NULL when free cyclic transfers Mans Rullgard (4): dmaengine: dw: set src and dst master select according to xfer direction dmaengine: dw: fix byte order of hw descriptor fields dmaengine: dw: set LMS field in descriptors dmaengine: dw: clear LLP_[SD]_EN bits in last descriptor of a chain Documentation/devicetree/bindings/dma/snps-dma.txt | 9 +- arch/arc/boot/dts/abilis_tb10x.dtsi| 2 +- arch/arm/boot/dts/spear13xx.dtsi | 4 +- arch/avr32/mach-at32ap/at32ap700x.c| 16 +- drivers/ata/sata_dwc_460ex.c | 6 +- drivers/dma/dw/core.c | 355 ++--- drivers/dma/dw/pci.c | 5 +- drivers/dma/dw/platform.c | 27 +- drivers/dma/dw/regs.h | 55 ++-- drivers/spi/spi-pxa2xx-pci.c | 8 +- drivers/tty/serial/8250/8250_pci.c | 8 +- include/linux/dma/dw.h | 5 +- include/linux/platform_data/dma-dw.h | 15 +- sound/soc/intel/common/sst-firmware.c | 2 +- 14 files changed, 268 insertions(+), 249 deletions(-) -- 2.7.0
[PATCH 3.19.y-ckt 69/70] mld, igmp: Fix reserved tailroom calculation
v3.19.8-ckt17 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Benjamin Poirier
commit 1837b2e2bcd23137766555a63867e649c0b637f0 upstream.
The current reserved_tailroom calculation fails to take hlen and tlen into
account.
skb:
[__hlen__|__data|__tlen___|__extra__]
^ ^
headskb_end_offset
In this representation, hlen + data + tlen is the size passed to alloc_skb.
"extra" is the extra space made available in __alloc_skb because of
rounding up by kmalloc. We can reorder the representation like so:
[__hlen__|__data|__extra__|__tlen___]
^ ^
headskb_end_offset
The maximum space available for ip headers and payload without
fragmentation is min(mtu, data + extra). Therefore,
reserved_tailroom
= data + extra + tlen - min(mtu, data + extra)
= skb_end_offset - hlen - min(mtu, skb_end_offset - hlen - tlen)
= skb_tailroom - min(mtu, skb_tailroom - tlen) ; after skb_reserve(hlen)
Compare the second line to the current expression:
reserved_tailroom = skb_end_offset - min(mtu, skb_end_offset)
and we can see that hlen and tlen are not taken into account.
The min() in the third line can be expanded into:
if mtu < skb_tailroom - tlen:
reserved_tailroom = skb_tailroom - mtu
else:
reserved_tailroom = tlen
Depending on hlen, tlen, mtu and the number of multicast address records,
the current code may output skbs that have less tailroom than
dev->needed_tailroom or it may output more skbs than needed because not all
space available is used.
Fixes: 4c672e4b ("ipv6: mld: fix add_grhead skb_over_panic for devs with large
MTUs")
Signed-off-by: Benjamin Poirier
Acked-by: Hannes Frederic Sowa
Acked-by: Daniel Borkmann
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
include/linux/skbuff.h | 24
net/ipv4/igmp.c| 3 +--
net/ipv6/mcast.c | 3 +--
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 31a9eab..0494347 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1767,6 +1767,30 @@ static inline void skb_reserve(struct sk_buff *skb, int
len)
skb->tail += len;
}
+/**
+ * skb_tailroom_reserve - adjust reserved_tailroom
+ * @skb: buffer to alter
+ * @mtu: maximum amount of headlen permitted
+ * @needed_tailroom: minimum amount of reserved_tailroom
+ *
+ * Set reserved_tailroom so that headlen can be as large as possible but
+ * not larger than mtu and tailroom cannot be smaller than
+ * needed_tailroom.
+ * The required headroom should already have been reserved before using
+ * this function.
+ */
+static inline void skb_tailroom_reserve(struct sk_buff *skb, unsigned int mtu,
+ unsigned int needed_tailroom)
+{
+ SKB_LINEAR_ASSERT(skb);
+ if (mtu < skb_tailroom(skb) - needed_tailroom)
+ /* use at most mtu */
+ skb->reserved_tailroom = skb_tailroom(skb) - mtu;
+ else
+ /* use up to all available space */
+ skb->reserved_tailroom = needed_tailroom;
+}
+
#define ENCAP_TYPE_ETHER 0
#define ENCAP_TYPE_IPPROTO 1
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 9ffa231..06f24d7 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -352,9 +352,8 @@ static struct sk_buff *igmpv3_newpack(struct net_device
*dev, unsigned int mtu)
skb_dst_set(skb, >dst);
skb->dev = dev;
- skb->reserved_tailroom = skb_end_offset(skb) -
-min(mtu, skb_end_offset(skb));
skb_reserve(skb, hlen);
+ skb_tailroom_reserve(skb, mtu, tlen);
skb_reset_network_header(skb);
pip = ip_hdr(skb);
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 5ce107c..beec177 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1576,9 +1576,8 @@ static struct sk_buff *mld_newpack(struct inet6_dev
*idev, unsigned int mtu)
return NULL;
skb->priority = TC_PRIO_CONTROL;
- skb->reserved_tailroom = skb_end_offset(skb) -
-min(mtu, skb_end_offset(skb));
skb_reserve(skb, hlen);
+ skb_tailroom_reserve(skb, mtu, tlen);
if (__ipv6_get_lladdr(idev, _buf, IFA_F_TENTATIVE)) {
/* :
--
2.7.0
Re: [PATCH 3.4 098/107] kernel/watchdog.c: touch_nmi_watchdog should only touch local cpu not every one
On Wed, Mar 16, 2016 at 04:06:32PM +0800, l...@kernel.org wrote: > From: Ben Zhang > > 3.4.111-rc1 review patch. If anyone has any objections, please let me know. Just an FYI below, this patch won't work the way it was integrated.. comments below > > -- > > > commit 62572e29bc530b38921ef6059088b4788a9832a5 upstream. > > I ran into a scenario where while one cpu was stuck and should have > panic'd because of the NMI watchdog, it didn't. The reason was another > cpu was spewing stack dumps on to the console. Upon investigation, I > noticed that when writing to the console and also when dumping the > stack, the watchdog is touched. > > This causes all the cpus to reset their NMI watchdog flags and the > 'stuck' cpu just spins forever. > > This change causes the semantics of touch_nmi_watchdog to be changed > slightly. Previously, I accidentally changed the semantics and we > noticed there was a codepath in which touch_nmi_watchdog could be > touched from a preemtible area. That caused a BUG() to happen when > CONFIG_DEBUG_PREEMPT was enabled. I believe it was the acpi code. > > My attempt here re-introduces the change to have the > touch_nmi_watchdog() code only touch the local cpu instead of all of the > cpus. But instead of using __get_cpu_var(), I use the > __raw_get_cpu_var() version. > > This avoids the preemption problem. However my reasoning wasn't because > I was trying to be lazy. Instead I rationalized it as, well if > preemption is enabled then interrupts should be enabled to and the NMI > watchdog will have no reason to trigger. So it won't matter if the > wrong cpu is touched because the percpu interrupt counters the NMI > watchdog uses should still be incrementing. > > Don said: > > : I'm ok with this patch, though it does alter the behaviour of how > : touch_nmi_watchdog works. For the most part I don't think most callers > : need to touch all of the watchdogs (on each cpu). Perhaps a corner case > : will pop up (the scheduler?? to mimic touch_all_softlockup_watchdogs() ). > : > : But this does address an issue where if a system is locked up and one cpu > : is spewing out useful debug messages (or error messages), the hard lockup > : will fail to go off. We have seen this on RHEL also. > > Signed-off-by: Don Zickus > Signed-off-by: Ben Zhang > Signed-off-by: Andrew Morton > Signed-off-by: Linus Torvalds > [lizf: Backported to 3.4: adjust context] > Signed-off-by: Zefan Li > --- > kernel/watchdog.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/kernel/watchdog.c b/kernel/watchdog.c > index 991aa93..7527c8c 100644 > --- a/kernel/watchdog.c > +++ b/kernel/watchdog.c > @@ -162,6 +162,14 @@ void touch_nmi_watchdog(void) > per_cpu(watchdog_nmi_touch, cpu) = true; > } > } The above for-loop was to be replaced by the non-for-loop below. The above for-loop is the problem this patch was solving, so keeping it around does not solve anything. :-) > + /* > + * Using __raw here because some code paths have > + * preemption enabled. If preemption is enabled > + * then interrupts should be enabled too, in which > + * case we shouldn't have to worry about the watchdog > + * going off. > + */ > + __raw_get_cpu_var(watchdog_nmi_touch) = true; > touch_softlockup_watchdog(); > } > EXPORT_SYMBOL(touch_nmi_watchdog); Cheers, Don
[PATCH 4/5] oprofile: nmi-timer: Handle the FROZEN hot plug notifier actions.
When performing a suspend operation, the kernel brings all of the
non-boot CPUs offline, calling the hot plug notifiers with the flag,
CPU_TASKS_FROZEN, set in the action code. Similarly, during resume,
the CPUs are brought back online, but again the notifiers have the
FROZEN flag set.
While some very few drivers really need to treat suspend/resume
specially, this driver unintentionally ignores the notifications.
This patch changes the driver to react to the FROZEN hot plug events.
As a result, the NMI timer is no longer left running during the
suspended state.
Cc: Robert Richter
Cc: oprofile-l...@lists.sf.net
Signed-off-by: Richard Cochran
---
drivers/oprofile/nmi_timer_int.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/oprofile/nmi_timer_int.c b/drivers/oprofile/nmi_timer_int.c
index 9559829..37ae173 100644
--- a/drivers/oprofile/nmi_timer_int.c
+++ b/drivers/oprofile/nmi_timer_int.c
@@ -63,7 +63,7 @@ static int nmi_timer_cpu_notifier(struct notifier_block *b,
unsigned long action
void *data)
{
int cpu = (unsigned long)data;
- switch (action) {
+ switch (action & ~CPU_TASKS_FROZEN) {
case CPU_DOWN_FAILED:
case CPU_ONLINE:
nmi_timer_start_cpu(cpu);
--
2.1.4
Re: [PATCH] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()
Hi Jisheng,
[auto build test WARNING on pci/next]
[also build test WARNING on next-20160316]
[cannot apply to v4.5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Jisheng-Zhang/PCI-designware-move-remaining-rc-setup-code-to-dw_pcie_setup_rc/20160316-184353
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-randconfig-i1-201611 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/pci/host/pcie-designware.c: In function 'dw_pcie_host_init':
>> drivers/pci/host/pcie-designware.c:437:6: warning: unused variable 'val'
>> [-Wunused-variable]
u32 val;
^
vim +/val +437 drivers/pci/host/pcie-designware.c
f342d940 Jingoo Han 2013-09-06 421
irq_set_chip_and_handler(irq, _msi_irq_chip, handle_simple_irq);
f342d940 Jingoo Han 2013-09-06 422 irq_set_chip_data(irq,
domain->host_data);
f342d940 Jingoo Han 2013-09-06 423
f342d940 Jingoo Han 2013-09-06 424 return 0;
f342d940 Jingoo Han 2013-09-06 425 }
f342d940 Jingoo Han 2013-09-06 426
f342d940 Jingoo Han 2013-09-06 427 static const struct
irq_domain_ops msi_domain_ops = {
f342d940 Jingoo Han 2013-09-06 428 .map = dw_pcie_msi_map,
f342d940 Jingoo Han 2013-09-06 429 };
f342d940 Jingoo Han 2013-09-06 430
a43f32d6 Matwey V. Kornilov 2015-02-19 431 int dw_pcie_host_init(struct
pcie_port *pp)
4b1ced84 Jingoo Han 2013-07-31 432 {
4b1ced84 Jingoo Han 2013-07-31 433 struct device_node *np
= pp->dev->of_node;
4dd964df Kishon Vijay Abraham I 2014-07-17 434 struct platform_device
*pdev = to_platform_device(pp->dev);
cbce7900 Zhou Wang 2015-10-29 435 struct pci_bus *bus,
*child;
4dd964df Kishon Vijay Abraham I 2014-07-17 436 struct resource
*cfg_res;
9cdce1cd Zhou Wang 2015-10-29 @437 u32 val;
9cdce1cd Zhou Wang 2015-10-29 438 int i, ret;
0021d22b Zhou Wang 2015-10-29 439 LIST_HEAD(res);
0021d22b Zhou Wang 2015-10-29 440 struct resource_entry
*win;
f342d940 Jingoo Han 2013-09-06 441
4dd964df Kishon Vijay Abraham I 2014-07-17 442 cfg_res =
platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
4dd964df Kishon Vijay Abraham I 2014-07-17 443 if (cfg_res) {
adf70fc0 Pratyush Anand 2014-09-05 444 pp->cfg0_size =
resource_size(cfg_res)/2;
adf70fc0 Pratyush Anand 2014-09-05 445 pp->cfg1_size =
resource_size(cfg_res)/2;
:: The code at line 437 was first introduced by commit
:: 9cdce1cdc0c40e6c2e85ed9ca13c32adaa5fe0c5 Revert "PCI: designware:
Program ATU with untranslated address"
:: TO: Zhou Wang
:: CC: Bjorn Helgaas
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [RFC][PATCH v4 2/2] printk: Skip messages on oops
Hello Jan,
On (03/14/16 23:13), Sergey Senozhatsky wrote:
>
> From: Jan Kara
>
> When there are too many messages in the kernel printk buffer it can take
> very long to print them to console (especially when using slow serial
> console). This is undesirable during oops so when we encounter oops and
> there are more than 100 messages to print, print just the newest 100
> messages and then the oops message.
I think this patch will introduce a regression, so I'd probably prefer
not to include it now in the series.
the pattern "print something important then panic()" is quite common.
given that other CPUs can printk() a lot before panic_cpu send out
stop_ipi, we can lose the "print something important" part.
...
arch/metag/kernel/cachepart.c: pr_emerg("Potential cache
aliasing detected in %s on Thread %d\n",
arch/metag/kernel/cachepart.c- cache_type ? "DCACHE"
: "ICACHE", thread_id);
arch/metag/kernel/cachepart.c- pr_warn("Total %s size: %u
bytes\n",
arch/metag/kernel/cachepart.c- cache_type ? "DCACHE" :
"ICACHE",
arch/metag/kernel/cachepart.c- cache_type ?
get_dcache_size()
arch/metag/kernel/cachepart.c- : get_icache_size());
arch/metag/kernel/cachepart.c- pr_warn("Thread %s size: %d
bytes\n",
arch/metag/kernel/cachepart.c- cache_type ? "CACHE" :
"ICACHE",
arch/metag/kernel/cachepart.c- thread_cache_size);
arch/metag/kernel/cachepart.c- pr_warn("Page Size: %lu
bytes\n", PAGE_SIZE);
arch/metag/kernel/cachepart.c- panic("Potential cache aliasing
detected");
...
arch/s390/kernel/jump_label.c: pr_emerg("Jump label code mismatch at %pS
[%p]\n", ipc, ipc);
arch/s390/kernel/jump_label.c: pr_emerg("Found:%6ph\n", ipc);
arch/s390/kernel/jump_label.c: pr_emerg("Expected: %6ph\n", ipe);
arch/s390/kernel/jump_label.c: pr_emerg("New: %6ph\n", ipn);
arch/s390/kernel/jump_label.c- panic("Corrupted kernel text");
...
another example is hardlockup detector with sysctl_hardlockup_all_cpu_backtrace.
static void watchdog_overflow_callback(...)
{
...
if (is_hardlockup()) {
...
if (sysctl_hardlockup_all_cpu_backtrace &&
!test_and_set_bit(0, _allcpu_dumped))
trigger_allbutself_cpu_backtrace();
nmi_panic(regs, msg);
...
}
...
}
trigger_allbutself_cpu_backtrace() can be much more than 100 lines.
trigger_allbutself_cpu_backtrace() may or may not be implemented via
NMI. for example arch/sparc/kernel/process_64.c
thus, we better avoid skipping any messages when in panic() I think.
-ss
Re: [PATCH v4 7/7] ARM: OMAP2+: Update GPMC and NAND DT binding documentation
On Thu, Mar 10, 2016 at 05:56:43PM -0600, Franklin S Cooper Jr wrote: > Add additional details to the GPMC NAND documentation to clarify > what is needed to enable NAND DMA prefetch. > > Signed-off-by: Franklin S Cooper Jr > --- > Documentation/devicetree/bindings/bus/ti-gpmc.txt | 7 ++- > Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 2 +- > 2 files changed, 7 insertions(+), 2 deletions(-) Acked-by: Rob Herring
Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
2016-03-18 13:33+0100, Vitaly Kuznetsov:
> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
> delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD
> from. vmbus_wait_for_unload() doesn't account for the fact that in case
> we're crashing on some other CPU and CPU0 is still alive and operational
> CHANNELMSG_UNLOAD_RESPONSE will be delivered there completing
> vmbus_connection.unload_event, our wait on the current CPU will never
> end.
(Any chance of learning about this behavior from the spec?)
> Do the following:
> 1) Check for completion_done() in the loop. In case interrupt handler is
>still alive we'll get the confirmation we need.
>
> 2) Always read CPU0's message page as CHANNELMSG_UNLOAD_RESPONSE will be
>delivered there. We can race with still-alive interrupt handler doing
>the same but we don't care as we're checking completion_done() now.
(Yeah, seems better than hv_setup_vmbus_irq(NULL) or other hacks.)
> 3) Cleanup message pages on all CPUs. This is required (at least for the
>current CPU as we're clearing CPU0 messages now but we may want to bring
>up additional CPUs on crash) as new messages won't be delivered till we
>consume what's pending. On boot we'll place message pages somewhere else
>and we won't be able to read stale messages.
What if HV already set the pending message bit on current message,
do we get any guarantees that clearing once after UNLOAD_RESPONSE is
enough?
> Signed-off-by: Vitaly Kuznetsov
> ---
I had a question about NULL below. (Parenthesised rants aren't related
to r-b tag. ;)
> drivers/hv/channel_mgmt.c | 30 +-
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index b10e8f74..5f37057 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -512,14 +512,26 @@ static void init_vp_index(struct vmbus_channel
> *channel, const uuid_le *type_gui
>
> static void vmbus_wait_for_unload(void)
> {
> - int cpu = smp_processor_id();
> - void *page_addr = hv_context.synic_message_page[cpu];
> + int cpu;
> + void *page_addr = hv_context.synic_message_page[0];
> struct hv_message *msg = (struct hv_message *)page_addr +
> VMBUS_MESSAGE_SINT;
> struct vmbus_channel_message_header *hdr;
> bool unloaded = false;
>
> - while (1) {
> + /*
> + * CHANNELMSG_UNLOAD_RESPONSE is always delivered to CPU0. When we're
> + * crashing on a different CPU let's hope that IRQ handler on CPU0 is
> + * still functional and vmbus_unload_response() will complete
> + * vmbus_connection.unload_event. If not, the last thing we can do is
> + * read message page for CPU0 regardless of what CPU we're on.
> + */
> + while (!unloaded) {
(I'd feel a bit safer if this was bounded by some timeout, but all
scenarios where this would make a difference are unplausible ...
queue_work() not working while the rest is fine is the best one.)
> + if (completion_done(_connection.unload_event)) {
> + unloaded = true;
(No need to set unloaded when you break.)
> + break;
> + }
> +
> if (READ_ONCE(msg->header.message_type) == HVMSG_NONE) {
> mdelay(10);
> continue;
> @@ -530,9 +542,17 @@ static void vmbus_wait_for_unload(void)
(I'm not a huge fan of the unloaded variable; what about remembering the
header/msgtype here ...
> unloaded = true;
>
> vmbus_signal_eom(msg);
and checking its value here?)
> + }
>
> - if (unloaded)
> - break;
> + /*
> + * We're crashing and already got the UNLOAD_RESPONSE, cleanup all
> + * maybe-pending messages on all CPUs to be able to receive new
> + * messages after we reconnect.
> + */
> + for_each_online_cpu(cpu) {
> + page_addr = hv_context.synic_message_page[cpu];
Can't this be NULL?
> + msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
> + msg->header.message_type = HVMSG_NONE;
> }
(And, this block belongs to a separate function. ;])
Re: [PATCH] net: consolidate lock/unlock into unlock_wait
On Fri, 2016-03-18 at 17:37 -0400, David Miller wrote: > From: Nicholas Mc Guire > > The spin_lock()/spin_unlock() is synchronizing on the adapter->work_lock > > as the comment also suggests, which is equivalent to spin_unlock_wait() > > but the later should be more efficient. [] > There really is no justification for this change. > This is an optimization in a slow-path of the driver. > The device is a rarely used older piece of hardware. It really might be nice to take some of the ancient hardware drivers in drivers/net and move them into some separate subdirectory like: drivers/net/ancient or drivers/net/antiques or drivers/net/archaic etc... so there's some clear designation that these crufty old drivers don't need to be touched anymore except for maybe when kernel wide changes occur.
Re: [GIT PULL] USB driver patches for 4.6-rc1
On Fri, Mar 18, 2016 at 04:09:50PM -0700, Linus Torvalds wrote: > On Fri, Mar 18, 2016 at 3:58 PM, Greg KH wrote: > > > > Yes, people did report issues with that yesterday, and I queued up a > > patch for it, it's attached below, but I didn't think it would cause any > > issues with non-OF systems either. I wanted to give it a few days > > testing in linux-next before sending it to you, but can do so now if you > > want. > > Ok, that fixes it for me. Yeah, I'll need this in order to continue > merging, I don't merge more stuff on top of known-bad kernels. > > I can apply the patch directly (I did it on that machine for testing), > or take a pull request. Just let me know. Here's the pull request, it also includes some security fixes that have been reported publicly, and a crash for the UAS driver that some people have hit already. The following changes since commit 48d10bda1f2c69980601a61194015bb0790fb7ab: Merge tag 'usb-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb (2016-03-17 14:24:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.6-rc1 for you to fetch changes up to 55ff8cfbc4e12a7d2187df523938cc671fbebdd1: USB: uas: Reduce can_queue to MAX_CMNDS (2016-03-18 09:19:02 -0700) USB fixes for 4.6-rc1 Here is a USB fix for the reported issue with 69bec7259853 "USB: core: let USB device know device node" as well as some other issues that have been reported so far with this merge. Signed-off-by: Greg Kroah-Hartman Hans de Goede (1): USB: uas: Reduce can_queue to MAX_CMNDS Josh Boyer (1): USB: iowarrior: fix oops with malicious USB descriptors Nicolai Stange (1): usb/core: usb_alloc_dev(): fix setting of ->portnum Oliver Neukum (2): USB: usb_driver_claim_interface: add sanity checking USB: cdc-acm: more sanity checking drivers/usb/class/cdc-acm.c | 3 +++ drivers/usb/core/driver.c| 6 +- drivers/usb/core/usb.c | 5 +++-- drivers/usb/misc/iowarrior.c | 6 ++ drivers/usb/storage/uas.c| 2 +- 5 files changed, 18 insertions(+), 4 deletions(-)
[PATCH 3/5] Drivers: hv: vmbus: Fix a bug in hv_need_to_signal_on_read()
We need to issue a full memory barrier prior making a signalling decision. Signed-off-by: K. Y. Srinivasan Cc: sta...@vger.kernel.org --- drivers/hv/ring_buffer.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c index 2919395..67dc245 100644 --- a/drivers/hv/ring_buffer.c +++ b/drivers/hv/ring_buffer.c @@ -104,6 +104,7 @@ static bool hv_need_to_signal_on_read(struct hv_ring_buffer_info *rbi) u32 cur_write_sz; u32 pending_sz; + mb(); pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz); /* If the other end is not blocked on write don't bother. */ if (pending_sz == 0) -- 1.7.4.1
Re: [PATCH v8 3/6] cpufreq: powernv: Remove cpu_to_chip_id() from hot-path
On Sat, 2016-03-19 at 09:37 +1100, Benjamin Herrenschmidt wrote: > On Fri, 2016-03-18 at 15:04 +1100, Michael Neuling wrote: > > > > static int nr_chips; > > +static DEFINE_PER_CPU(unsigned int, chip_id); > > > > /* > > * Note: The set of pstates consists of contiguous integers, the > > @@ -317,9 +318,7 @@ static void powernv_cpufreq_throttle_check(void > > *data) > > > > pmsr = get_pmspr(SPRN_PMSR); > > > > - for (i = 0; i < nr_chips; i++) > > - if (chips[i].id == cpu_to_chip_id(cpu)) > > - break; > > + i = this_cpu_read(chip_id); > > Except it's not a chip_id, so your patch confused me for a good 2mn > ... > Call it chip_idx maybe ? ie, index. Yeah, it was a badly named variable but I changed it even more and Shilpasri rebased it here: http://patchwork.ozlabs.org/patch/599523/ Mikey
Re: [GIT PULL] USB driver patches for 4.6-rc1
On Fri, Mar 18, 2016 at 2:58 PM, Linus Torvalds wrote: > > Yeah, the bisect is now solidly in the usb part. The commit that ends up being marked bad is odd, but there it is: 69bec7259853 "USB: core: let USB device know device node". Very odd, but I tested multiple times: I'm typing this on d883f52e1f6d, and everything is fine. On 69bec7259853, I can't type. Note that when I say "I can't type", it's the early boot disk encryption password. And maybe there's an oops there, but I can't see it, and I can't log it. I don't even have CONFIG_OF enabled, so I don't see what difference that patch would make. But it makes some difference. I'll double-check by reverting it on top of current git (it does seem to at least revert cleanly), I haven't done that yet. But adding the people involved in that commit to the discussion to see if anybody sees anything. Linus
[PATCH 2/2] ASoC: codecs: add support for TAS5720 digital amplifier
The Texas Instruments TAS5720L/M device is a high-efficiency mono
Class-D audio power amplifier optimized for high transient power
capability to use the dynamic power headroom of small loudspeakers.
Its digital time division multiplexed (TDM) interface enables up to
16 devices to share the same bus.
Signed-off-by: Andreas Dannenberg
---
sound/soc/codecs/Kconfig | 10 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/tas5720.c | 733 +
sound/soc/codecs/tas5720.h | 90 ++
4 files changed, 835 insertions(+)
create mode 100644 sound/soc/codecs/tas5720.c
create mode 100644 sound/soc/codecs/tas5720.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 7ef3a0c..a0bb8cb 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -124,6 +124,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TAS2552 if I2C
select SND_SOC_TAS5086 if I2C
select SND_SOC_TAS571X if I2C
+ select SND_SOC_TAS5720 if I2C
select SND_SOC_TFA9879 if I2C
select SND_SOC_TLV320AIC23_I2C if I2C
select SND_SOC_TLV320AIC23_SPI if SPI_MASTER
@@ -741,6 +742,15 @@ config SND_SOC_TAS571X
tristate "Texas Instruments TAS5711/TAS5717/TAS5719 power amplifiers"
depends on I2C
+config SND_SOC_TAS5720
+ tristate "Texas Instruments TAS5720 Mono Audio amplifier"
+ depends on I2C
+ help
+ Enable support for Texas Instruments TAS5720L/M high-efficiency mono
+ Class-D audio power amplifiers. The devices use an I2C interface for
+ setup/control and support an optional GPIO interrupt signal for fault
+ reporting.
+
config SND_SOC_TFA9879
tristate "NXP Semiconductors TFA9879 amplifier"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 185a712..83d352e 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -129,6 +129,7 @@ snd-soc-stac9766-objs := stac9766.o
snd-soc-sti-sas-objs := sti-sas.o
snd-soc-tas5086-objs := tas5086.o
snd-soc-tas571x-objs := tas571x.o
+snd-soc-tas5720-objs := tas5720.o
snd-soc-tfa9879-objs := tfa9879.o
snd-soc-tlv320aic23-objs := tlv320aic23.o
snd-soc-tlv320aic23-i2c-objs := tlv320aic23-i2c.o
@@ -335,6 +336,7 @@ obj-$(CONFIG_SND_SOC_STI_SAS) += snd-soc-sti-sas.o
obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
obj-$(CONFIG_SND_SOC_TAS5086) += snd-soc-tas5086.o
obj-$(CONFIG_SND_SOC_TAS571X) += snd-soc-tas571x.o
+obj-$(CONFIG_SND_SOC_TAS5720) += snd-soc-tas5720.o
obj-$(CONFIG_SND_SOC_TFA9879) += snd-soc-tfa9879.o
obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o
obj-$(CONFIG_SND_SOC_TLV320AIC23_I2C) += snd-soc-tlv320aic23-i2c.o
diff --git a/sound/soc/codecs/tas5720.c b/sound/soc/codecs/tas5720.c
new file mode 100644
index 000..ac22c22
--- /dev/null
+++ b/sound/soc/codecs/tas5720.c
@@ -0,0 +1,733 @@
+/*
+ * tas5720.c - ALSA SoC Texas Instruments TAS5720 Mono Audio Amplifier
+ *
+ * Copyright (C)2015-2016 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Andreas Dannenberg
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "tas5720.h"
+
+static const char * const tas5720_supply_names[] = {
+ "dvdd", /* Digital power supply. Connect to 3.3-V supply. */
+ "pvdd", /* Class-D amp and analog power supply (connected). */
+};
+#define TAS5720_NUM_SUPPLIES ARRAY_SIZE(tas5720_supply_names)
+
+struct tas5720_data {
+ struct snd_soc_codec *codec;
+ struct regmap *regmap;
+ struct i2c_client *tas5720_client;
+ struct regulator_bulk_data supplies[TAS5720_NUM_SUPPLIES];
+ struct gpio_desc *gpiod_faultz;
+ struct delayed_work irq_enable_work;
+};
+
+static int tas5720_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params,
+struct snd_soc_dai *dai)
+{
+ struct snd_soc_codec *codec = dai->codec;
+ int width = params_width(params);
+ unsigned int rate = params_rate(params);
+ bool ssz_ds;
+ int ret;
+
+ switch (width) {
+ case 16:
+ case 18:
+ case 20:
+ case 24:
+ /*
+* We only support the different left-justified serial audio
+* formats in which case there is nothing to configure in the
+*
[PATCH 0/2] ASoC: codecs: add support for TAS5720 digital amplifier
Driver for TI's TAS5720L/M digital audio amplifiers. The driver should be
pretty standard except the optional interrupt-based fault reporting.
Some background on the fault reporting since that might be a discussion of
interest. The code should have that documented rather well but I wanted to
bring it up right away. The TAS5720 devices can report conditions such as
over-current (short), over temp, and others that can be important to know in a
real-world system. However the device lacks a way to mask the generation of
fault interrupts except by shutting it down, which can lead to cases where the
device generates SAIF-fault host interrupts every 300us! This is clearly a lot
of overhead to be thrown at the SoC (and my bench testing has demonstrated
that) so after trying different things to tame this behavior I ended up
implementing method to disable/enable the interrupts in the driver itself in
combination with rate-limiting the processing of those events. The fact of
processing interrupts in a threaded fashion (IRQF_ONESHOT) alone was not enough
under certain conditions to prevent the SoC from not being able to get to all
interrupts even with an empty threaded handler, and it would freeze and
eventually the Kernel would disable the interrupt ("no one cared").
The scheme currently implemented seems to work reliably cycling different audio
files over hours also forcing error conditions. But if anybody has a "cleaner"
idea how to rate-limit IRQs on a very low level (currently done in the IRQ
handler function) I'm absolutely open to suggestions. This all may not be an
issue at all when using a faster/lower-latency SoC than what I'm using
(BeagleBone Black) but the fact that IRQF_ONESHOT alone was not enough to
prevent the system to be brought to its knees (again, even with an empty
threaded handler) was a bit of a surprise to me.
--
Andreas Dannenberg
Texas Instruments Inc
Andreas Dannenberg (2):
ASoC: codecs: add TA5720 digital amplifier DT bindings
ASoC: codecs: add support for TAS5720 digital amplifier
.../devicetree/bindings/sound/tas5720.txt | 37 ++
sound/soc/codecs/Kconfig | 10 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/tas5720.c | 733 +
sound/soc/codecs/tas5720.h | 90 +++
5 files changed, 872 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas5720.txt
create mode 100644 sound/soc/codecs/tas5720.c
create mode 100644 sound/soc/codecs/tas5720.h
--
2.6.4
[PATCH 3/5] drm: Add an encoder and connector type enum for DPI.
Right now exynos is exposing DPI as a TMDS encoder and VGA connector,
which seems rather misleading. This isn't just an internal detail,
since xrandr actually exposes "VGA" as the output name. Define some
new enums so that vc4's DPI can have a more informative name.
I considered other names for the connector as well. For VC4, the
Adafruit DPI kippah takes the 28 GPIO pins and routes them to a
standard-ish 40-pin FPC connector, but "40-pin FPC" doesn't uniquely
identify an ordering of pins (apparently some other orderings exist),
doesn't explain things as well for the user (who, if anything, knows
their product is a DPI kippah/panel combo), and actually doesn't have
to exist (one could connect the 28 GPIOs directly to something else).
Simply "DPI" seems like a good compromise name to distinguish from the
HDMI, DSI, and TV connectors .
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_crtc.c | 2 ++
include/uapi/drm/drm_mode.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f619121..64bd954 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -168,6 +168,7 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] = {
{ DRM_MODE_CONNECTOR_eDP, "eDP" },
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
+ { DRM_MODE_CONNECTOR_DPI, "DPI" },
};
static const struct drm_prop_enum_list drm_encoder_enum_list[] = {
@@ -179,6 +180,7 @@ static const struct drm_prop_enum_list
drm_encoder_enum_list[] = {
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
{ DRM_MODE_ENCODER_DSI, "DSI" },
{ DRM_MODE_ENCODER_DPMST, "DP MST" },
+ { DRM_MODE_ENCODER_DPI, "DPI" },
};
static const struct drm_prop_enum_list drm_subpixel_enum_list[] = {
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 50adb46..1eb85f7 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -202,6 +202,7 @@ struct drm_mode_get_plane_res {
#define DRM_MODE_ENCODER_VIRTUAL 5
#define DRM_MODE_ENCODER_DSI 6
#define DRM_MODE_ENCODER_DPMST 7
+#define DRM_MODE_ENCODER_DPI 8
struct drm_mode_get_encoder {
__u32 encoder_id;
@@ -241,6 +242,7 @@ struct drm_mode_get_encoder {
#define DRM_MODE_CONNECTOR_eDP 14
#define DRM_MODE_CONNECTOR_VIRTUAL 15
#define DRM_MODE_CONNECTOR_DSI 16
+#define DRM_MODE_CONNECTOR_DPI 17
struct drm_mode_get_connector {
--
2.7.0
Re: [GIT PULL] Block driver changes for 4.6-rc
On Fri, Mar 18, 2016 at 10:33 AM, Jens Axboe wrote: > > 1) Pull for-4.6/drivers and do the merges yourself. This is the original >branch. > > 2) Pull for-4.6/drivers-merged, which is the above branch, but with v4.5 >merged into it and the merges resolved cleanly. I don't think your merge is correct. I pushed out mine. So the differences are (apart from purely newline changes): - you kept the early "flush_work(>reset_work)", so your merge didn't take the changes from commit ff23a2a15a2117245b4599c1352343c8b8fb4c43 properly, and you flush the work twice. I don't know that it matters, but it looks odd. - Your merge dropped the nvme_dev_disable() from nvme_remove_dead_ctrl(), added by commit 69d9a99c258eb1d6478fd9608a2070890797eed7 - Your merge kept the redundant dev_set_drvdata() in nvme_init_ctrl(), removed by commit f4f0f63e6f01055dfbdb7bc5e83935e1bdfa1980. Anyway, since I got a different merge result than you did, you should double-check, but I think I did the merge correctly. But I don't know the code nor the hardware, so I'm just going by reading the commits. I also do have to ask: why the hell is nvme development done in that insane way? Why the f*ck can people not work together? Why are these two different groups messing with each others code? Tell them to stop. I'm not happy with how messy these block layer pulls are. Linus Linus
Re: [PATCH 0/3] KVM: VMX: fix handling inv{ept,vpid} and nested RHEL6 KVM
On 18/03/2016 18:42, David Matlack wrote: > On Fri, Mar 18, 2016 at 9:09 AM, Paolo Bonzini wrote: >> Patches 1 and 2 fix two cases where a guest could hang at 100% CPU >> due to mis-emulation of a failing invept or invvpid. > > Will you be sending out kvm-unit-test test cases for these? Yes, of course, especially for patches 1 and 2. However I first want to add a --enable-unsafe option for stuff that breaks particularly badly when the test fails. We don't do nested virt CVEs (yet), but all of these would be treated as vulnerabilities if we did---the tests would effectively DoS the host. The infamous #AC failure could also be under a flag like that, and I remember a similar topic popping up with a LAPIC fix from Google. Paolo >> >> Patch 3 works around a bug in RHEL6 KVM, which is exposed by nested >> VPID support; RHEL6 KVM uses single-context invvpid unconditionally, >> but until now KVM did not provide it. >> >> Paolo >> > > For the series, > > Reviewed-by: David Matlack > >> Paolo Bonzini (3): >> KVM: VMX: avoid guest hang on invalid invept instruction >> KVM: VMX: avoid guest hang on invalid invvpid instruction >> KVM: VMX: fix nested vpid for old KVM guests >> >> arch/x86/kvm/vmx.c | 16 +++- >> 1 file changed, 15 insertions(+), 1 deletion(-) >> >> -- >> 1.8.3.1 >>
Re: [PATCH v2] efi: Introduce EFI bootloader control driver
On Fri, 2016-03-18 at 16:15 +, Matt Fleming wrote: > On Fri, 18 Mar, at 12:11:50PM, Daniel Baluta wrote: > > > > From: Matt Gumbel > > > > This driver intercepts system reboot requests and populates the > > LoaderEntryOneShot EFI variable with the user-supplied reboot > > argument. EFI bootloaders such as Gummiboot will consume this > > variable and use it to control which OS is booted next. > > > > We use this with Android where reboot() tells the kernel that > > we want to boot into recovery or other non-default OS environment. > > > > It is the bootloader's job to guard against this variable being > > uninitialzed or containing invalid data, and just boot normally > > if that is the case. > > > > Signed-off-by: Matt Gumbel > > Signed-off-by: Mohamed Abbas > > Signed-off-by: Constantin Musca > > Signed-off-by: Daniel Baluta > > --- > > Changes since v1: > > * updated Makefile after changing source name from efibc.c -> > > efi-bc.c > > to comply with naming rules in drivers/firmware/efi/ > > > > drivers/firmware/efi/Kconfig | 11 ++ > > drivers/firmware/efi/Makefile | 1 + > > drivers/firmware/efi/efi-bc.c | 251 > > ++ > > 3 files changed, 263 insertions(+) > > create mode 100644 drivers/firmware/efi/efi-bc.c > Why does this require a driver? Why is it not possible to solve this > problem by creating the variable in userspace before invoking > reboot(2)? Hi Matt, It is possible, but that means modifying those userspace apps :) There are reboot implementations that do "reboot ", such as Android's reboot command [1] and Upstart's reboot replacement [2], which pass the reason as an argument to the reboot syscall. Probably your first question will be - "Why don't you modify those apps?" Well, I don't see platform-agnostic way how those could be modified to pass the reason to the bootloader, regardless of platform or bootloader. Other non-EFI platforms use a driver as well: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/dri vers/soc/tegra/pmc.c#n382 [1] https://android.googlesource.com/platform/system/core/+/master/libcu tils/android_reboot.c#228 [2] https://bazaar.launchpad.net/~upstart-devel/upstart/trunk/view/head: /util/reboot.c#L259 Cheers, Stefan
RE: [PATCH V2 1/2] x86/perf/intel/uncore: Make Intel uncore modular
>
> On Fri, 18 Mar 2016, kan.li...@intel.com wrote:
>
> > From: Kan Liang
> >
> > This patch makes Intel uncore pmu driver modular.
> > By default, the uncore driver will be built in the kernel. If it is
> > configured as module, the supported cpu model can be auto loaded.
> > This patch also cleans up the code of cpu_init and pci_init.
>
> Nice work!
>
> > +static struct intel_uncore_init_fun skl_uncore_init = {
> > + .pci_init = skl_uncore_pci_init,
> > +};
> > +
> > +static const struct x86_cpu_id intel_uncore_match[] = {
>
> Shouldn't all of these structs be const __initconst?
>
Thanks for the review. I will fix it in next version.
Thanks,
Kan
> Other than that:
>
> Reviewed-by: Thomas Gleixner
Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods
On Fri, Mar 18, 2016 at 09:40:25AM +, Daniel Thompson wrote: > On 18/03/16 00:33, Paul E. McKenney wrote: > >On Thu, Mar 17, 2016 at 08:17:59PM -0400, Chris Metcalf wrote: > >>On 3/17/2016 6:55 PM, Paul E. McKenney wrote: > >>>The RCU stall-warn stack traces can be ugly, agreed. > >>> > >>>That said, RCU used to use NMI-based stack traces, but switched to the > >>>current scheme due to the NMIs having the unfortunate habit of locking > >>>things up, which IIRC often meant no stack traces at all. If I recall > >>>correctly, one of the problems was self-deadlock in printk(). > >> > >>Steven Rostedt enabled the per_cpu printk func support in June 2014, and > >>the nmi_backtrace code uses it to just capture printk output to percpu > >>buffers, so I think it's going to be a lot more robust than earlier > >>attempts. > > > >That would be a very good thing, give or take the "I think" qualifier. > >And assuming that the target CPU is healthy enough to find its way back > >to some place that can dump the per-CPU printk buffer. I might well > >be overly paranoid, but I have to suspect that the probability of that > >buffer getting dumped is reduced greatly on a CPU that isn't healthy > >enough to respond to RCU, though. > > The target CPU doesn't dump the buffer. It "just" fields the NMI, > stores the backtrace and sets a flag. > > The buffer is dumped to console by the requesting CPU, either when > all backtraces have come back or when a timeout is reached. That does sound a bit more robust, good! > >But it seems like enabling the experiment might be useful. > > > >"Try enabling the NMI version. If that doesn't get you your RCU CPU > >stall warning stack trace, try the remote-print variant." > > > >Or I suppose we could just do both in succession, just in case their > >console was a serial port. ;-) > > I guess both might be needed but only when the target CPU is dead > enough to fail to respond to NMI. In principle, we could exploit the > timeout in the NMI backtrace logic and only issue the missing > backtraces. It would be really nice if I could call one function that used the best strategy for getting information (including stack trace) about a specified CPU. Ditto for getting information about a specified task, which might be running or might be preempted at the time. Thanx, Paul
Re: [PATCH] mac80211: fix order of flag descriptions
On 18/03/16 17:29, Joe Perches wrote: > On Fri, 2016-03-18 at 16:35 +, Luis de Bethencourt wrote: >> Fix order of mac80211_rx_flags description to match the enum. >> >> Signed-off-by: Luis de Bethencourt >> --- >> Hi, >> >> I want ahead and fixed the order of the descriptions. checkpatch.pl was >> giving >> a warning to my previous patch and I had a hunch it was because the wrong >> order >> breaks the parser. Indeed it does and with this patch below checkpatch.pl >> does >> not complain about this flag descriptions anymore. > > checkpatch complains? About what? > warning: Enum value 'RX_FLAG_DUP_VALIDATED' not described in enum 'mac80211_rx_flags' Is the warning checkpatch.pl gives against my first patch (add doc for RX_FLAG_DUP_VALIDATED flag). This is silenced by reordering the descriptions to match the order in the enum. Thanks, Luis
Re: [PATCH 1/2] watchdog: Fix output
On Sat, 19 Mar 2016, Jiri Kosina wrote:
> > It was Jiri who made this mess by replacing WARN(), which has a very
> > distinct format, with this custom stuff.
>
> Right, this was in 55537871e ("kernel/watchdog.c: perform all-CPU
> backtrace in case of hard lockup").
>
> To be really honest, I don't really have 100% reliable explanation why I
> did it this way; I *think* it was because otherwise, in case WARN is
> preserved, we'll either
>
> - have different output format for current (warning) CPU and all the
> others (trigger_allbutself_cpu_backtrace())
>
> or
>
> - have duplicated backtrace for current CPU, one coming from WARN and one
> coming from the all-cpu backtrace
>
> > I think we should go back to the WARN() thing.
>
> I don't really have strong opinion on this, but someone should pick the
> poison from the two options above; I tried in the mentioned commit, but
> apparently not to general satisfaction :)
Hmm, or we can actually make the whole thing behave the way that was
introduced by 55537871e only in case of
sysctl_hardlockup_all_cpu_backtrace being set, and use WARN() otherwise.
I'll send out a patch for this during / after the weekend if noone else
beats me to do it.
--
Jiri Kosina
SUSE Labs
Re: [PATCHv4 08/25] thp: support file pages in zap_huge_pmd()
On Fri, Mar 18, 2016 at 07:23:41PM +0530, Aneesh Kumar K.V wrote: > "Kirill A. Shutemov" writes: > > > [ text/plain ] > > split_huge_pmd() for file mappings (and DAX too) is implemented by just > > clearing pmd entry as we can re-fill this area from page cache on pte > > level later. > > > > This means we don't need deposit page tables when file THP is mapped. > > Therefore we shouldn't try to withdraw a page table on zap_huge_pmd() > > file THP PMD. > > Archs like ppc64 use deposited page table to track the hardware page > table slot information. We probably may want to add hooks which arch can > use to achieve the same even with file THP Could you describe more on what kind of information you're talking about? -- Kirill A. Shutemov
[PATCH] Drivers: hv: vmbus: handle various crash scenarios
Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD
from. vmbus_wait_for_unload() doesn't account for the fact that in case
we're crashing on some other CPU and CPU0 is still alive and operational
CHANNELMSG_UNLOAD_RESPONSE will be delivered there completing
vmbus_connection.unload_event, our wait on the current CPU will never
end.
Do the following:
1) Check for completion_done() in the loop. In case interrupt handler is
still alive we'll get the confirmation we need.
2) Always read CPU0's message page as CHANNELMSG_UNLOAD_RESPONSE will be
delivered there. We can race with still-alive interrupt handler doing
the same but we don't care as we're checking completion_done() now.
3) Cleanup message pages on all CPUs. This is required (at least for the
current CPU as we're clearing CPU0 messages now but we may want to bring
up additional CPUs on crash) as new messages won't be delivered till we
consume what's pending. On boot we'll place message pages somewhere else
and we won't be able to read stale messages.
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/channel_mgmt.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index b10e8f74..5f37057 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -512,14 +512,26 @@ static void init_vp_index(struct vmbus_channel *channel,
const uuid_le *type_gui
static void vmbus_wait_for_unload(void)
{
- int cpu = smp_processor_id();
- void *page_addr = hv_context.synic_message_page[cpu];
+ int cpu;
+ void *page_addr = hv_context.synic_message_page[0];
struct hv_message *msg = (struct hv_message *)page_addr +
VMBUS_MESSAGE_SINT;
struct vmbus_channel_message_header *hdr;
bool unloaded = false;
- while (1) {
+ /*
+* CHANNELMSG_UNLOAD_RESPONSE is always delivered to CPU0. When we're
+* crashing on a different CPU let's hope that IRQ handler on CPU0 is
+* still functional and vmbus_unload_response() will complete
+* vmbus_connection.unload_event. If not, the last thing we can do is
+* read message page for CPU0 regardless of what CPU we're on.
+*/
+ while (!unloaded) {
+ if (completion_done(_connection.unload_event)) {
+ unloaded = true;
+ break;
+ }
+
if (READ_ONCE(msg->header.message_type) == HVMSG_NONE) {
mdelay(10);
continue;
@@ -530,9 +542,17 @@ static void vmbus_wait_for_unload(void)
unloaded = true;
vmbus_signal_eom(msg);
+ }
- if (unloaded)
- break;
+ /*
+* We're crashing and already got the UNLOAD_RESPONSE, cleanup all
+* maybe-pending messages on all CPUs to be able to receive new
+* messages after we reconnect.
+*/
+ for_each_online_cpu(cpu) {
+ page_addr = hv_context.synic_message_page[cpu];
+ msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
+ msg->header.message_type = HVMSG_NONE;
}
}
--
2.5.0
[PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended
Some BIOSes unconditionally send an ACPI notification to RBTN when the
system is resuming from suspend. This makes dell-rbtn send an input
event to userspace as if a function key was pressed. Prevent this by
ignoring all the notifications received while the device is suspended.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=106031
Signed-off-by: Gabriele Mazzotta
---
Same as v2 with some comments
drivers/platform/x86/dell-rbtn.c | 50
1 file changed, 50 insertions(+)
diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index 5155278..b144b8c 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -28,6 +28,7 @@ struct rbtn_data {
enum rbtn_type type;
struct rfkill *rfkill;
struct input_dev *input_dev;
+ bool suspended;
};
@@ -220,9 +221,49 @@ static const struct acpi_device_id rbtn_ids[] = {
{ "", 0 },
};
+#ifdef CONFIG_PM_SLEEP
+static void ACPI_SYSTEM_XFACE rbtn_acpi_clear_flag(void *context)
+{
+ struct rbtn_data *rbtn_data = context;
+
+ rbtn_data->suspended = false;
+}
+
+static int rbtn_suspend(struct device *dev)
+{
+ struct acpi_device *device = to_acpi_device(dev);
+ struct rbtn_data *rbtn_data = acpi_driver_data(device);
+
+ rbtn_data->suspended = true;
+
+ return 0;
+}
+
+static int rbtn_resume(struct device *dev)
+{
+ struct acpi_device *device = to_acpi_device(dev);
+ struct rbtn_data *rbtn_data = acpi_driver_data(device);
+ acpi_status status;
+
+ /*
+* Clear the flag only after we received the extra
+* ACPI notification.
+*/
+ status = acpi_os_execute(OSL_NOTIFY_HANDLER,
+rbtn_acpi_clear_flag, rbtn_data);
+ if (ACPI_FAILURE(status))
+ rbtn_data->suspended = false;
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(rbtn_pm_ops, rbtn_suspend, rbtn_resume);
+
static struct acpi_driver rbtn_driver = {
.name = "dell-rbtn",
.ids = rbtn_ids,
+ .drv.pm = _pm_ops,
.ops = {
.add = rbtn_add,
.remove = rbtn_remove,
@@ -384,6 +425,15 @@ static void rbtn_notify(struct acpi_device *device, u32
event)
{
struct rbtn_data *rbtn_data = device->driver_data;
+ /*
+* Some BIOSes send autonomously a notification at resume.
+* Ignore it to prevent unwanted input events.
+*/
+ if (rbtn_data->suspended) {
+ dev_dbg(>dev, "ACPI notification ignored\n");
+ return;
+ }
+
if (event != 0x80) {
dev_info(>dev, "Received unknown event (0x%x)\n",
event);
--
2.8.0.rc3
Re: [LKP] [lkp] [futex] 65d8fc777f: +25.6% will-it-scale.per_process_ops
On Fri, 18 Mar 2016, Huang, Ying wrote: > Usually we will put most important change we think in the subject of the > mail, for this email, it is, > > +25.6% will-it-scale.per_process_ops That is confusing on it's own, because the reader does not know at all whether this is an improvement or a regression. So something like this might be useful: Subject: subsystem: 12digitsha1: 25% performance improvement or in some other case Subject: subsystem: 12digitsha1: 25% performance regression So in the latter case I will look into that mail immediately. The improvement one can wait until I have cared about urgent stuff. In the subject line it is pretty much irrelevant which foo-bla-ops test has produced that result. It really does not matter. If it's a regression, it's urgent. If it's an improvement it's informal and it can wait to be read. So in that case it would be: futex: 65d8fc777f6d: 25% performance improvement You can grab the subsystem prefix from the commit. > and, we try to put most important changes at the top of the comparison > result below. That is the will-it-scale.xxx below. > > We are thinking about how to improve this. You input is valuable for > us. We are thinking change the "below changes" line to something like > below. > > FYI, we noticed the +25.6% will-it-scale.per_process_ops improvement on > ... > > Does this looks better? A bit, but it still does not tell me much. It's completely non obvious what 'will-it-scale.per_process_ops' means. Let me give you an example how a useful and easy to understand summary of the change could look like: FYI, we noticed 25.6% performance improvement due to commit 65d8fc777f6d "futex: Remove requirement for lock_page() in get_futex_key()" in the will-it-scale.per_process_ops test. will-it-scale.per_process_ops tests the futex operations for process shared futexes (Or whatever that test really does). The commit has no significant impact on any other test in the test suite. So those few lines tell precisely what this is about. It's something I already expected, so I really can skip the rest of the mail unless I'm interested in reproducing the result. Now lets look at a performance regression. Subject: futex: 65d8fc777f6d: 25% performance regression FYI, we noticed a 25.2% performance regression due to commit 65d8fc777f6d "futex: Remove requirement for lock_page() in get_futex_key()" in the will-it-scale.per_process_ops test. will-it-scale.per_process_ops tests the futex operations for process shared futexes (Or whatever that test really does). The commit has no significant impact on any other test in the test suite. In that case I will certainly be interested how to reproduce that test. So I need the following information: Machine description: Intel IvyBridge 2 sockets, 32 cores, 64G RAM Config file: http://wherever.you.store/your/results/test-nr/config Test: http://wherever.you.store/your/tests/will-it-scale.per_process_ops.tar.bz2 That tarball should contain: README test_script.sh test_binary README should tell: will-it-scale.per_process_ops Short explanation of the test Preliminaries: - perf - whatever So that allows me to reproduce that test more or less with no effort. And that's the really important part. You can provide nice charts and full comparison tables for all tests on a web site for those who are interested in large stats and pretty charts. Full results: http://wherever.you.store/your/results/test-nr/results So now lets look at a scenario where that commit results in a performance improvement on will-it-scale.per_process_ops and a regression on will-it-scale.per_task. Subject: futex: 65d8fc777f6d: 25% performance regression FYI, we noticed a 25.2% performance regression due to commit 65d8fc777f6d "futex: Remove requirement for lock_page() in get_futex_key()" in the will-it-scale.per_task test. will-it-scale.per_tasks tests the futex operations for process private futexes (Or whatever that test really does). The commit has significant impact on the following tests in the test suite: will-it-scale.per_process_ops: 25% improvement The 25% improvement is really not interesting. What's interesting is the regression. That's what people need to look at. You still can provide the information about all the tests including the 25% improvement data on Full results: http://wherever.you.store/your/results/test-nr/results Now, if you have commits which have mixed impact on various tests, then it's important to point out the most relevant issue clearly in the summary. I.e. you need to filter the tests for the maximum regression/improvement and use that as the main information. You still can provide the information about the impact on other tests in a very condensed form. The commit has significant impact on the following tests in the test suite: test1: 0.5% Regression test2: 2.0% Improvement testN:
Re: [PATCH] x86: Avoid undefined behavior in macro expansion
On Wed, Mar 16, 2016 at 11:48:49PM -0300, Vinicius Tinti wrote: > C11 standard (at 6.10.3.3) says that ## operator (paste) has undefined > behavior when one of the result operands is not a valid preprocessing > token. > > Therefore the macro expansion may depend on compiler implementation > which may or no preserve the leading white space. > > Moreover other places in kernel use CONCAT(a,b) instead of CONCAT(a, b). > Changing favors concise usage. Huh? > -#define XMM(i) CONCAT(%xmm, i) > +#define XMM(i) CONCAT(%xmm,i) What are you talking about? Undefined behaviour is when the result of concatenation of adjacent tokens is not a valid preprocessor token. It says nothing about the either argument being a single token. In this case after the substitution of e.g. XMM(42) we get 3 tokens: Punctuator[%] Identifier[xmm] Pp-number[42] with ## instructing us to replace the last two with preprocessor token that would be represented as concatenation of their representations. Which is to say, concatenation of xmm and 42, i.e. xmm42. Which *is* a representation of a valid preprocessor token - namely, Identifier[xmm42]. No undefined behaviour at all. And yes, you get two preprocessor tokens in the expansion - % and xmm42. Preprocessor works in terms of tokens, not strings... If you know of any compiler where these two variants would produce different expansions of XMM(), please report it to maintainers of the compiler in question; it's a bug, plain and simple. And no, there's no undefined behaviour in that.
[PATCH] staging: delete STE RMI4 hackish driver
As of commit 62d5bdf972ebcfc99f72f734ae979713e4ca6450 "Merge branch 'synaptics-rmi4' into next" the input subsystem has a proper RMI4 infrastructure and touchscreen driver. The ST Ux500 platform has been converted to use the new driver and its devicetree bindings. Delete this ancient hack. Cc: Andrew Duggan Cc: Christopher Heiny Cc: Dmitry Torokhov Signed-off-by: Linus Walleij --- drivers/staging/ste_rmi4/Kconfig |9 - drivers/staging/ste_rmi4/Makefile |4 - drivers/staging/ste_rmi4/TODO |7 - drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c | 1137 - drivers/staging/ste_rmi4/synaptics_i2c_rmi4.h | 46 - 5 files changed, 1203 deletions(-) delete mode 100644 drivers/staging/ste_rmi4/Kconfig delete mode 100644 drivers/staging/ste_rmi4/Makefile delete mode 100644 drivers/staging/ste_rmi4/TODO delete mode 100644 drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c delete mode 100644 drivers/staging/ste_rmi4/synaptics_i2c_rmi4.h diff --git a/drivers/staging/ste_rmi4/Kconfig b/drivers/staging/ste_rmi4/Kconfig deleted file mode 100644 index e8679509e525.. --- a/drivers/staging/ste_rmi4/Kconfig +++ /dev/null @@ -1,9 +0,0 @@ -config TOUCHSCREEN_SYNAPTICS_I2C_RMI4 - tristate "Synaptics i2c rmi4 touchscreen" - depends on I2C && INPUT - help - Say Y here if you have a Synaptics RMI4 and - want to enable support for the built-in touchscreen. - - To compile this driver as a module, choose M here: the - module will be called synaptics_rmi4_ts. diff --git a/drivers/staging/ste_rmi4/Makefile b/drivers/staging/ste_rmi4/Makefile deleted file mode 100644 index 6cce2ed187ef.. --- a/drivers/staging/ste_rmi4/Makefile +++ /dev/null @@ -1,4 +0,0 @@ -# -# Makefile for the RMI4 touchscreen driver. -# -obj-$(CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4) += synaptics_i2c_rmi4.o diff --git a/drivers/staging/ste_rmi4/TODO b/drivers/staging/ste_rmi4/TODO deleted file mode 100644 index 9be2437da85f.. --- a/drivers/staging/ste_rmi4/TODO +++ /dev/null @@ -1,7 +0,0 @@ -TODO - - -Wait for the official upstream synaptics rmi4 clearpad drivers as promised over the past few months -Merge any device support needed from this driver into it -Delete this driver - diff --git a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c deleted file mode 100644 index 774958a8ce02.. --- a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c +++ /dev/null @@ -1,1137 +0,0 @@ -/** - * - * Synaptics Register Mapped Interface (RMI4) I2C Physical Layer Driver. - * Copyright (c) 2007-2010, Synaptics Incorporated - * - * Author: Js HA for ST-Ericsson - * Author: Naveen Kumar G for ST-Ericsson - * Copyright 2010 (c) ST-Ericsson AB - */ -/* - * This file is licensed under the GPL2 license. - * - *# - * GPL - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 as published - * by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY - * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * for more details. - * - *# - */ - -#include -#include -#include -#include -#include -#include -#include -#include "synaptics_i2c_rmi4.h" - -/* TODO: for multiple device support will need a per-device mutex */ -#define DRIVER_NAME "synaptics_rmi4_i2c" - -#define MAX_ERROR_REPORT 6 -#define MAX_TOUCH_MAJOR15 -#define MAX_RETRY_COUNT5 -#define STD_QUERY_LEN 21 -#define PAGE_LEN 2 -#define DATA_BUF_LEN 32 -#define BUF_LEN37 -#define QUERY_LEN 9 -#define DATA_LEN 12 -#define HAS_TAP0x01 -#define HAS_PALMDETECT 0x01 -#define HAS_ROTATE 0x02 -#define HAS_TAPANDHOLD 0x02 -#define HAS_DOUBLETAP 0x04 -#define HAS_EARLYTAP 0x08 -#define HAS_RELEASE0x08 -#define HAS_FLICK 0x10 -#define HAS_PRESS 0x20 -#define HAS_PINCH 0x40 - -#define MASK_16BIT 0x -#define MASK_8BIT 0xFF -#define MASK_7BIT 0x7F -#define MASK_5BIT 0x1F -#define MASK_4BIT 0x0F -#define MASK_3BIT 0x07 -#define MASK_2BIT 0x03 -#define TOUCHPAD_CTRL_INTR 0x8 -#define PDT_START_SCAN_LOCATION (0x00E9) -#define PDT_END_SCAN_LOCATION (0x000A) -#define PDT_ENTRY_SIZE (0x0006) -#define SYNAPTICS_RMI4_TOUCHPAD_FUNC_NUM (0x11) -#define SYNAPTICS_RMI4_DEVICE_CONTROL_FUNC_NUM (0x01) -
Re: [PATCH v15 1/6] efi: ARM/arm64: ignore DT memory nodes instead of removing them
On 18 March 2016 at 13:56, Matt Fleming wrote: > On Fri, 18 Mar, at 01:31:59PM, Ard Biesheuvel wrote: >> >> Typically, the UEFI memory map is more restrictive, since it does not >> only describe where the memory lives, but also which parts of it the >> firmware has claimed for its own use. So if both memory nodes and the >> UEFI memory map are available, we must use the latter anyway, and so >> it makes sense to ignore the former. Alternatively, we could sanity >> check the memory nodes against the memory map, but it is simpler just >> to ignore them. >> >> However, that caused some problems in the past, since discovering the >> memory nodes occurs before the EFI entry point is invoked, and so it >> was decided that we strip the memory nodes rather than ignore them. > > Thanks Ard. > > Once you've stripped the memory nodes as represented in memblock, > there's no way for the memory nodes to re-appear in one form or > another after that point, right? The EFI memory map is the sole memory > layout either via memblock or if it's queried directly? Well, the significance of this patch in this series is that the memory nodes contain additional properties that describe the NUMA topology, which the UEFI memory map does not allow us to do. At some point, we may decide to capture this information in a different way (i.e., a separate configuration table), but for now, I think this is fine, especially since stripping nodes is a bit of a blunt tool.
Re: [PATCH v8 3/6] cpufreq: powernv: Remove cpu_to_chip_id() from hot-path
On Fri, Mar 18, 2016 at 5:11 AM, Michael Neuling wrote:
> On Fri, 2016-03-18 at 15:04 +1100, Michael Neuling wrote:
>
>> On Wed, 2016-02-03 at 01:11 +0530, Shilpasri G Bhat wrote:
>>
>
>> > cpu_to_chip_id() does a DT walk through to find out the chip id by
>> > taking a contended device tree lock. This adds an unnecessary
>> > overhead
>> > in a hot path. So instead of calling cpu_to_chip_id() everytime
>> > cache
>> > the chip ids for all cores in the array 'core_to_chip_map' and use
>> > it
>> > in the hotpath.
>> >
>> > Reported-by: Anton Blanchard
>> > Signed-off-by: Shilpasri G Bhat
>> > Reviewed-by: Gautham R. Shenoy
>> > Acked-by: Viresh Kumar
>> > ---
>> > No changes from v7.
>>
>> How about this instead? It removes the linear lookup and seems a lot
>> less complex.
This has gone in already. Can you please send a patch on top of it?
> BTW we never init nr_chips before using it. We also need something
> like.
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c
> b/drivers/cpufreq/powernv-cpufreq.c
> index d63d2cb..c819ed4 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -556,6 +556,8 @@ static int init_chip_info(void)
> unsigned int cpu, i;
> unsigned int prev_chip_id = UINT_MAX;
>
> + nr_chips = 0;
> +
> for_each_possible_cpu(cpu) {
> unsigned int id = cpu_to_chip_id(cpu);
>
>
Including this part too maybe?
Thanks,
Rafael
Re: [PATCH] Remove v850 from linux/elf-em.h
On 03/18/2016 12:46 PM, David Daney wrote: > I am not going to comment on it any more, but [commenting more] Yes you are. (And did then too.) > On 03/17/2016 07:32 PM, Rob Landley wrote: > [...] >> >> As I explained last email, userspace uses the libc header, not the linux >> header, > > The fallacy in this argument is the assertion that we know what > userspace does. Userspace programs that did that already broke on earlier symbol removals. > Userspace could easily do: > > #include > . >case SYMBOL_YOU_WANT_TO_REMOVE: > > ¡BOOM! it is broken. So you're assuming I don't know how headers get used by userspace. That's nice. Clearly, I never would have thought of that. Once again, "As I explained last email", symbols have been removed from this particular header before. Therefore userspace programs that did that without an #ifdef would have been broken by the previous commits that removed symbols. There is a header they can use, provided by libc, which exports all the defined ELF symbols _including_ the symbols the Linux kernel does not suse. The Linux kernel header in question only exports the symbols that this particular kernel version supports. When architectures are added or removed, the corresponding symbols get added or removed. I didn't invent the concept, it's happened before to this header. (In a larger context, we've removed bigger things. Remember when there was a feature-removal-schedule.txt that listed things pending removal, before Linus decided it was unnecessary and to just use his own judgement? Yeah, take it up with him.) And now I'm going to take your advice above. Please refer to my earlier messages in this thread for answers to what you're about to say. Rob
Re: rcu_preempt self-detected stall on CPU from 4.5-rc3, since 3.17
On Fri, Mar 18, 2016 at 02:00:11PM -0700, Josh Triplett wrote:
> On Thu, Feb 25, 2016 at 04:56:38PM -0800, Paul E. McKenney wrote:
> > On Thu, Feb 25, 2016 at 04:13:11PM +1100, Ross Green wrote:
> > > On Wed, Feb 24, 2016 at 8:28 AM, Ross Green wrote:
> > > > On Wed, Feb 24, 2016 at 7:55 AM, Paul E. McKenney
> > > > wrote:
> >
> > [ . . . ]
> >
> > > >> Still working on getting decent traces...
> >
> > And I might have succeeded, see below.
> >
> > > >>
> > > >> Thanx, Paul
> > > >>
> > > >
> > > > G'day all,
> > > >
> > > > Here is another dmesg output for 4.5-rc5 showing another rcu_preempt
> > > > stall.
> > > > This one appeared after only a day of running. CONFIG_DEBUG_TIMING is
> > > > turned on, but can't see any output that shows from this.
> > > >
> > > > Again testing as before,
> > > >
> > > > Boot, run a series of small benchmarks, then just let the system be
> > > > and idle away.
> > > >
> > > > I notice in the stack trace there is mention of hrtimer_run_queues and
> > > > hrtimer_interrupt.
> > > >
> > > > Anyway, leave this for a few more eyes to look at.
> > > >
> > > > Open to any other suggestions of things to test.
> > > >
> > > > Regards,
> > > >
> > > > Ross Green
> > >
> > >
> > > G'day Paul,
> > >
> > > I left the pandaboard running and captured another stall.
> > >
> > > the attachment is the dmesg output.
> > >
> > > Again there is no apparent output from any CONFIG_DEBUG_TIMING so I
> > > assume there is nothing happening there.
> >
> > I agree, looks like this is not due to time skew.
> >
> > > I just saw the updates for 4.6 RCU code.
> > > Is the patch in [PATCH tip/core/rcu 04/13] valid here?
> >
> > I doubt that it will help, but you never know.
> >
> > > do you want me try the new patch set with this configuration?
> >
> > Even better would be to try Daniel Wagner's swait patchset. I have
> > attached them in UNIX mbox format, or you can get them from the
> > -tip tree.
> >
> > And I -finally- got some tracing that -might- be useful. The dmesg, all
> > 67MB of it, is here:
> >
> > http://www.rdrop.com/~paulmck/submission/console.2016.02.23a.log
> >
> > This failure mode is less likely to happen, and looks a bit different
> > than the ones that I was seeing before enabling tracing. Then, an
> > additional wakeup would actually wake the task up. In contrast, with
> > tracing enabled, the RCU grace-period kthread goes into "teenager mode",
> > refusing to wake up despite repeated attempts. However, this might
> > be a side-effect of the ftrace dump.
> >
> > On line 525,132, we see that the rcu_preempt grace-period kthread has
> > been starved for 1,188,154 jiffies, or about 20 minutes. This seems
> > unlikely... The kthread is waiting for no more than a three-jiffy
> > timeout ("RCU_GP_WAIT_FQS(3)") and is in TASK_INTERRUPTIBLE state
> > ("0x1").
>
> We're seeing a similar stall (~60 seconds) on an x86 development system
> here. Any luck tracking down the cause of this? If not, any
> suggestions for traces that might be helpful?
The dmesg containing the stall, the kernel version, and the .config would
be helpful! Working on a torture test specific to this bug...
Thanx, Paul
[PATCH 1/2] ASoC: codecs: add TA5720 digital amplifier DT bindings
The Texas Instruments TAS5720L/M device is a high-efficiency mono
Class-D audio power amplifier optimized for high transient power
capability to use the dynamic power headroom of small loudspeakers.
Its digital time division multiplexed (TDM) interface enables up to
16 devices to share the same bus.
Signed-off-by: Andreas Dannenberg
---
.../devicetree/bindings/sound/tas5720.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas5720.txt
diff --git a/Documentation/devicetree/bindings/sound/tas5720.txt
b/Documentation/devicetree/bindings/sound/tas5720.txt
new file mode 100644
index 000..3775a3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas5720.txt
@@ -0,0 +1,37 @@
+Texas Instruments TAS5720 Mono Audio amplifier
+
+The TAS5720 serial control bus communicates through the I2C protocol only.
+
+Required properties:
+
+- compatible : "ti,tas5720"
+- reg : I2C slave address
+
+Optional properties:
+
+- dvdd-supply : phandle to a 3.3-V supply for the digital circuitry
+- pvdd-supply : phandle to a supply used for the Class-D amp and the analog
+- interrupts-extended : reference to a GPIO pin connected to the TAS5720
+FAULTZ pin for error reporting purposes
+
+Note that in case of codec errors the driver relies on the TAS5720 datasheet-
+proposed "Auto Recovery Circuit" (connection between the FAULTZ and SDZ device
+pins) for continued operation. This connection should always be made
independent
+of whether the optional interrupt-based fault-reporting feature is used.
+
+For more product information please see the links below:
+
+http://www.ti.com/product/TAS5720L
+http://www.ti.com/product/TAS5720M
+
+Example:
+
+tas5720: tas5720@6c {
+ status = "okay";
+ compatible = "ti,tas5720";
+ reg = <0x6c>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_int_pin>;
+ interrupts-extended = < 28 IRQ_TYPE_EDGE_FALLING>;
+};
--
2.6.4
Re: [PATCH v2] cpufreq: Make cpufreq_quick_get() safe to call.
On Saturday, March 12, 2016 06:52:37 AM Viresh Kumar wrote: > On 11-03-16, 09:43, Richard Cochran wrote: > > The function, cpufreq_quick_get, accesses the global 'cpufreq_driver' and > > its fields without taking the associated lock, cpufreq_driver_lock. > > > > Without the locking, nothing guarantees that 'cpufreq_driver' remains > > consistent during the call. This patch fixes the issue by taking the lock > > before accessing the data structure. > > > > Cc: Dirk Brandewie > > Cc: Rafael J. Wysocki > > Cc: Viresh Kumar > > Cc: linux...@vger.kernel.org > > Signed-off-by: Richard Cochran > > --- > > drivers/cpufreq/cpufreq.c | 12 ++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > Acked-by: Viresh Kumar Applied, thanks!
Re: [REGRESSION] 774ac8b7eff6 ("Thermal: initialize thermal zone device correctly") causes performance drop
On Fri, 2016-03-18 at 15:28 -0700, Laura Abbott wrote:
> (bringing this back to the main thread)
>
> On 03/16/2016 05:20 PM, Pandruvada, Srinivas wrote:
> > On Wed, 2016-03-16 at 17:00 -0700, Laura Abbott wrote:
> > > On 03/16/2016 03:46 PM, Greg Kroah-Hartman wrote:
> > > > On Wed, Mar 16, 2016 at 03:27:57PM -0700, Laura Abbott wrote:
> > > > > Hi,
> > > > >
> > > > > Fedora received a bug report (https://bugzilla.redhat.com/sho
> > > > > w_bu
> > > > > g.cgi?id=1317190)
> > > > > of a major performance drop on various bench marks and
> > > > > general
> > > > > system
> > > > > sluggishness with the 4.4.4 kernel update. The benchmarks
> > > > > were
> > > > > showing
> > > > > a reduction to about 18% performance (not minor).
> > > > >
> > > > > Bisection showed the first bad commit was
> > > > >
> > > > > commit 774ac8b7eff69e0786970157de2157e68b22f456
> > > > > Author: Zhang Rui
> > > > > Date: Fri Oct 30 16:31:47 2015 +0800
> > > > >
> > > > > Thermal: initialize thermal zone device correctly
> > > > > commit bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461
> > > > > upstream.
> > > > > After thermal zone device registered, as we have not
> > > > > read
> > > > > any
> > > > > temperature before, thus tz->temperature should not be
> > > > > 0,
> > > > > which actually means 0C, and thermal trend is not
> > > > > available.
> > > > > In this case, we need specially handling for the first
> > > > > thermal_zone_device_update().
> > > > > Both thermal core framework and step_wise governor is
> > > > > enhanced to handle this. And since the step_wise
> > > > > governor
> > > > > is the only one that uses trends, so it's the only
> > > > > thermal
> > > > > governor that needs to be updated.
> > > > > Tested-by: Manuel Krause
> > > > > Tested-by: szegad
> > > > > Tested-by: prash
> > > > > Tested-by: amish
> > > > > Tested-by: Matthias
> > > > > Reviewed-by: Javi Merino
> > > > > Signed-off-by: Zhang Rui
> > > > > Signed-off-by: Chen Yu
> > > > > Signed-off-by: Greg Kroah-Hartman > > > > on.or
> > > > > g>
> > > > >
> > > > >
> > > > >
> > > > > Reverting this plus to other commits in the series
> > > > > (a67208e94d94
> > > > > "Thermal: handle thermal zone device properly during system
> > > > > sleep"
> > > > > and 27f356149d59 "Thermal: do thermal zone update after a
> > > > > cooling
> > > > > device registered") confirmed the performance was back to
> > > > > normal.
> > > > >
> > > > > Bugzilla has the full discussion but this comment from one of
> > > > > the
> > > > > reporters sums it up:
> > > > >
> > > > > "In 4.4.3 and prior, my 2.40 MHz processor would fluctuate
> > > > > between
> > > > > 1000 and 3400 MHz. In 4.4.4, the processor would fluctuate
> > > > > between
> > > > > 400 and 700 MHz, according to /proc/cpuinfo.
> > > > >
> > > > > Setting
> > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
> > > > > to
> > > > > performance, instead of the default "powersave" forces the
> > > > > CPU to
> > > > > 2400 MHz, and improves performance greatly, but still not to
> > > > > the
> > > > > same level as in 4.4.3."
> > > > >
> > > > > Any ideas?
> > > >
> > > > Is this same "slowdown" also seen in 4.5?
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > >
> > >
> > > Yes, the same issue is seen on 4.5 according to the reporter.
> > What does it show here when performance drops?
> > grep . /sys/devices/system/cpu/intel_pstate/*
> >
> > Is the problem still occurs if you set
> > /sys/class/thermal/thermal_zone*/mode to "disabled"
> >
> > Thanks,
> > Srinivas
> >
>
> A separate thread was started which gave this insight:
>
> "I think
> the problem is your device has a passive trip temp of 0
> /sys/class/thermal/thermal_zone0/trip_point_2_temp:0
> /sys/class/thermal/thermal_zone0/trip_point_2_type:passive
>
> Which triggers a false throttle = true. I think we should this trip
> as
> invalid in the case of
> if (tz->temperature >= trip_temp) {} check
> in thermal_zone_trip_update()."
>
> So would something like the following work?
>
> diff --git a/drivers/thermal/step_wise.c
> b/drivers/thermal/step_wise.c
> index ea9366a..1228797 100644
> --- a/drivers/thermal/step_wise.c
> +++ b/drivers/thermal/step_wise.c
> @@ -143,7 +143,7 @@ static void thermal_zone_trip_update(struct
> thermal_zone_device *tz, int trip)
>
> trend = get_tz_trend(tz, trip);
>
> - if (tz->temperature >= trip_temp) {
> + if (trip_type != THERMAL_TRIPS_NONE && tz->temperature >=
> trip_temp) {
if (trip_temp && tz->temperature >= trip_temp) {
throttle = true;
> trace_thermal_zone_trip(tz, trip, trip_type);
> }
>
I think Rui is working on some change.
Thanks,
Srinivas
> (completely untested, no idea if I'm even close)
>
> Thanks,
> Laura
Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
2016-03-18 16:53+0100, Vitaly Kuznetsov: > Radim Krcmar writes: >> 2016-03-18 13:33+0100, Vitaly Kuznetsov: >>> @@ -530,9 +542,17 @@ static void vmbus_wait_for_unload(void) >> >> (I'm not a huge fan of the unloaded variable; what about remembering the >> header/msgtype here ... >> >>> unloaded = true; >>> >>> vmbus_signal_eom(msg); >> >> and checking its value here?) >> > > Sure, but we'll have to use a variable for that ... why would it be > better than 'unloaded'? It's easier to understand IMO, x = mem | x = mem if *x == sth | z = *x u = true| eoi() | eoi() if u | if z == sth break | break And you can replace msg with the new variable, z = *mem eoi() if z == sth break >> Can't this be NULL? > > It can't, we allocate it from hv_synic_alloc() (and we don't support cpu > onlining/offlining on WS2012R2+). Reviewed-by: Radim Krčmář Thanks. >>> + msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT; >>> + msg->header.message_type = HVMSG_NONE; >>> } >> >> (And, this block belongs to a separate function. ;]) > > I thought about moving it to hv_crash_handler() but then I decided to > leave it here as the need for this fixup is rather an artifact of how we > recieve the message. But I'm flexible here) Ok, clearing all VCPUs made me think that it would be generally useful.
Re: bluetooth: use-after-free in vhci_send_frame
On 03/07/2016, 05:27 PM, Jiri Slaby wrote: > On 03/04/2016, 10:15 AM, Dmitry Vyukov wrote: >> Ping. >> Just got another one on 4.5-rc6 > > FWIW I've just hit that too right now. > > But I haven't hit it with 4.4 which I am fuzzing by the orders of > magnitude longer. Scratch that, it happened on 4.4.6 today. thanks, -- js suse labs
whats wrong with my code ? trying to lock and iterate through read tasks in cfs rq
here is the code of system call I implemented trying to iterate
through cfs tasks of cpu_num rq and retrieve their pids :
#include
#include
#include "/home/user/linux-3.14.1/kernel/sched/sched.h"
#include
#include
asmlinkage long sys_get_tasks_from_rq(int cpu_num,void* dst)
{
struct rq * my_rq;
my_rq=cpu_rq(cpu_num);
int* pids = (int*) kmalloc(sizeof(int)*my_rq->nr_running,GFP_KERNEL);
struct task_struct *p, *n;
int i=0;
raw_spin_lock_irq(_rq->lock);
list_for_each_entry_safe(p, n, _rq->cfs_tasks, se.group_node){
pids[i]=task_pid_vnr(p);
i++;
}
raw_spin_unlock_irq(_rq->lock);
copy_to_user(dst,pids,300);
return 0;
}
when I try to use it in user space I get segmenation fault :
int main(int argc,char** argv){
int cpuNum = atoi(argv[1]);
int pids[300];
syscall(319,cpuNum,pids);
int i;
for (i=0;i<10;i++){
printf("%d \t",pids[i]);
}
}
So I guess Im doing something wrong :/ Could some plz direct me for
where my problem is? Thanks !
Re: [PATCH 1/1] linux-firmware: Update AMD microcode patch firmware
On Thu, Mar 17, 2016 at 01:56:11AM -0500, Sherry Hurwitz wrote: > For AMD Family 15h Processors to fix bugs in prior microcode patch > file: amd-ucode/microcode_amd_fam15h.bin > md5sum: 2384ef1d8ec8ca3930b62d82ea5a3813 > > Version: 2016_03_16 > > Signed-off-by: Sherry Hurwitz applied, thanks sherry. regards, --kyle
Re: [PATCH] sched: Add preempt checks in preempt_schedule() code
Hi Steven, On Fri, Mar 18, 2016 at 01:06:02PM -0400, Steven Rostedt wrote: > While testing the tracer preemptoff, I hit this strange trace: > > # cmd pid | time | caller > # \ / | \| / ><...>-259 0...10us : schedule <-worker_thread ><...>-259 0d..10us : rcu_note_context_switch <-__schedule ><...>-259 0d..10us : rcu_sched_qs <-rcu_note_context_switch ><...>-259 0d..10us : rcu_preempt_qs <-rcu_note_context_switch ><...>-259 0d..10us : _raw_spin_lock <-__schedule ><...>-259 0d..10us : preempt_count_add <-_raw_spin_lock ><...>-259 0d..20us : do_raw_spin_lock <-_raw_spin_lock ><...>-259 0d..21us : deactivate_task <-__schedule ><...>-259 0d..21us : update_rq_clock.part.84 <-deactivate_task ><...>-259 0d..21us : dequeue_task_fair <-deactivate_task ><...>-259 0d..21us : dequeue_entity <-dequeue_task_fair ><...>-259 0d..21us : update_curr <-dequeue_entity ><...>-259 0d..21us : update_min_vruntime <-update_curr ><...>-259 0d..21us : cpuacct_charge <-update_curr ><...>-259 0d..21us : __rcu_read_lock <-cpuacct_charge ><...>-259 0d..21us : __rcu_read_unlock <-cpuacct_charge ><...>-259 0d..21us : clear_buddies <-dequeue_entity ><...>-259 0d..21us : account_entity_dequeue <-dequeue_entity ><...>-259 0d..22us : update_min_vruntime <-dequeue_entity ><...>-259 0d..22us : update_cfs_shares <-dequeue_entity ><...>-259 0d..22us : hrtick_update <-dequeue_task_fair ><...>-259 0d..22us : wq_worker_sleeping <-__schedule ><...>-259 0d..22us : kthread_data <-wq_worker_sleeping ><...>-259 0d..22us : pick_next_task_fair <-__schedule ><...>-259 0d..22us : check_cfs_rq_runtime <-pick_next_task_fair ><...>-259 0d..22us : pick_next_entity <-pick_next_task_fair ><...>-259 0d..22us : clear_buddies <-pick_next_entity ><...>-259 0d..22us : pick_next_entity <-pick_next_task_fair ><...>-259 0d..22us : clear_buddies <-pick_next_entity ><...>-259 0d..22us : set_next_entity <-pick_next_task_fair ><...>-259 0d..23us : put_prev_entity <-pick_next_task_fair ><...>-259 0d..23us : check_cfs_rq_runtime <-put_prev_entity ><...>-259 0d..23us : set_next_entity <-pick_next_task_fair > gnome-sh-10310d..23us : finish_task_switch <-__schedule > gnome-sh-10310d..23us : _raw_spin_unlock_irq <-finish_task_switch > gnome-sh-10310d..23us : do_raw_spin_unlock <-_raw_spin_unlock_irq > gnome-sh-10310...23us!: preempt_count_sub <-_raw_spin_unlock_irq > gnome-sh-10310...1 582us : do_raw_spin_lock <-_raw_spin_lock > gnome-sh-10310...1 583us : _raw_spin_unlock <-drm_gem_object_lookup > gnome-sh-10310...1 583us : do_raw_spin_unlock <-_raw_spin_unlock > gnome-sh-10310...1 583us : preempt_count_sub <-_raw_spin_unlock > gnome-sh-10310...1 584us : _raw_spin_unlock <-drm_gem_object_lookup > gnome-sh-10310...1 584us+: trace_preempt_on <-drm_gem_object_lookup > gnome-sh-10310...1 603us : > => preempt_count_sub > => _raw_spin_unlock > => drm_gem_object_lookup > => i915_gem_madvise_ioctl > => drm_ioctl > => do_vfs_ioctl > => SyS_ioctl > => entry_SYSCALL_64_fastpath > > As I'm tracing preemption disabled, it seemed incorrect that the trace > would go across a schedule and report not being in the scheduler. > Looking into this I discovered the problem. > > schedule() calls preempt_disable() but the preempt_schedule() calls > preempt_enable_notrace(). What happened above was that the gnome-shell > task was preempted on another CPU, migrated over to the idle cpu. The > tracer stared with idle calling schedule(), which called > preempt_disable(), but then gnome-shell finished, and it enabled > preemption with preempt_enable_notrace() that does stop the trace, even > though preemption was enabled. > > The purpose of the preempt_disable_notrace() in the preempt_schedule() > is to prevent function tracing from going into an infinite loop. > Because function tracing can trace the preempt_enable/disable() calls > that are traced. The problem with function tracing is: > > NEED_RESCHED set > preempt_schedule() > preempt_disable() > preempt_count_inc() Just out of curiosity, could this be solved by adding a barrier() here? > function trace (before incrementing preempt count) > preempt_disable_notrace() > preempt_enable_notrace() > sees NEED_RESCHED set >preempt_schedule() (repeat) > I'm asking this because it seems to me if PREEMPT_COUNT=y and PREEMPT_TRACER=y, then preempt_disable_notrace(); preempt_disable_check(1); is actually __preempt_count_inc(); barrier();
Re: [GIT PULL] USB driver patches for 4.6-rc1
On Fri, Mar 18, 2016 at 3:58 PM, Greg KH wrote: > > Yes, people did report issues with that yesterday, and I queued up a > patch for it, it's attached below, but I didn't think it would cause any > issues with non-OF systems either. I wanted to give it a few days > testing in linux-next before sending it to you, but can do so now if you > want. Ok, that fixes it for me. Yeah, I'll need this in order to continue merging, I don't merge more stuff on top of known-bad kernels. I can apply the patch directly (I did it on that machine for testing), or take a pull request. Just let me know. Linus
Re: intel_pstate oopses and lockdep report with Linux v4.5-1822-g63e30271b04c
On Fri, Mar 18, 2016 at 6:35 PM, Josh Boyer wrote: > On Fri, Mar 18, 2016 at 10:36 AM, Rafael J. Wysocki > wrote: >> On Friday, March 18, 2016 08:37:15 AM Josh Boyer wrote: >>> On Thu, Mar 17, 2016 at 8:20 PM, Rafael J. Wysocki >>> wrote: >>> > On Thursday, March 17, 2016 12:44:54 PM Josh Boyer wrote: >>> >> On Thu, Mar 17, 2016 at 10:07 AM, Rafael J. Wysocki >>> >> wrote: >>> >> > On Thursday, March 17, 2016 09:02:29 AM Josh Boyer wrote: >>> >> >> Hello, >>> >> > >>> >> > Hi, >>> >> > >>> >> >> I have an Intel Atom based NUC that is producing the following >>> >> >> backtraces on boot of Linus' tree as of last evening. This does not >>> >> >> happen with a tree with top level commit 271ecc5253e2, but does happen >>> >> >> when using the tree mentioned in the subject with top level commit >>> >> >> 63e30271b04c. >>> >> >> >>> >> >> The first backtrace appears to be a warning because the intel_pstate >>> >> >> driver is calling wrmsrl_on_cpu when interrupts are disabled? Not >>> >> >> sure on that one. >>> >> >> >>> >> >> The second backtrace is a lockdep report. Both are from the same >>> >> >> boot. >>> >> > >>> >> > OK, thanks for the report. >>> >> > >>> >> > Can you please try the patch below? >>> >> > >>> >> > I'm actually unsure if we can do that safely in general for Atom >>> >> > because >>> >> > of the initialization, but that's what Core does anyway. >>> >> > >>> >> > Srinivas, Philippe, why exactly do we need the wrmsrl_on_cpu() in >>> >> > atom_set_pstate()? core_set_pstate() uses wrmsrl() and seems to be >>> >> > doing fine. >>> >> > >>> >> > --- >>> >> > drivers/cpufreq/intel_pstate.c |2 +- >>> >> > 1 file changed, 1 insertion(+), 1 deletion(-) >>> >> > >>> >> > Index: linux-pm/drivers/cpufreq/intel_pstate.c >>> >> > === >>> >> > --- linux-pm.orig/drivers/cpufreq/intel_pstate.c >>> >> > +++ linux-pm/drivers/cpufreq/intel_pstate.c >>> >> > @@ -587,7 +587,7 @@ static void atom_set_pstate(struct cpuda >>> >> > >>> >> > val |= vid; >>> >> > >>> >> > - wrmsrl_on_cpu(cpudata->cpu, MSR_IA32_PERF_CTL, val); >>> >> > + wrmsrl(MSR_IA32_PERF_CTL, val); >>> >> > } >>> >> > >>> >> > static int silvermont_get_scaling(void) >>> >> > >>> >> >>> >> I applied this on top of commit 09fd671ccb24 and the backtrace and >>> >> lockdep report both go away. So yes, this seems to clear up the >>> >> issue. I tested it on a variety of different CPU types and didn't >>> >> notice anything wrong on them either. >>> > >>> > The problems may show up during initialization and cleanup where one CPU >>> > may be running code trying to configure a different one. In those cases >>> > wrmsrl_on_cpu() needs to be used. >>> > >>> > Let me cut a patch taking that into account. >>> >>> OK. Happy to test when you have it ready. >> >> Thanks! >> >> Please test the patch below. >> >> --- >> From: Rafael J. Wysocki >> Subject: [PATCH] intel_pstate: Do not call wrmsrl_on_cpu() with disabled >> interrupts >> >> After commit a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with >> utilization update callbacks) wrmsrl_on_cpu() cannot be called in the >> intel_pstate_adjust_busy_pstate() path as that is executed with >> disabled interrupts. However, atom_set_pstate() called from there >> via intel_pstate_set_pstate() uses wrmsrl_on_cpu() to update the >> IA32_PERF_CTL MSR which triggers the WARN_ON_ONCE() in >> smp_call_function_single(). >> >> The reason why wrmsrl_on_cpu() is used by atom_set_pstate() is >> because intel_pstate_set_pstate() calling it is also invoked during >> the initialization and cleanup of the driver and in those cases it is >> not guaranteed to be run on the CPU that is being updated. However, >> in the case when intel_pstate_set_pstate() is called by >> intel_pstate_adjust_busy_pstate(), wrmsrl() can be used to update >> the register safely. Moreover, intel_pstate_set_pstate() already >> contains code that only is executed if the function is called by >> intel_pstate_adjust_busy_pstate() and there is a special argument >> passed to it because of that. >> >> To fix the problem at hand, rearrange the code taking the above >> observations into account. >> >> First, replace the ->set() callback in struct pstate_funcs with a >> ->get_val() one that will return the value to be written to the >> IA32_PERF_CTL MSR without updating the register. >> >> Second, split intel_pstate_set_pstate() into two functions, >> intel_pstate_update_pstate() to be called by >> intel_pstate_adjust_busy_pstate() that will contain all of the >> intel_pstate_set_pstate() code which only needs to be executed in >> that case and will use wrmsrl() to update the MSR (after obtaining >> the value to write to it from the ->get_val() callback), and >> intel_pstate_set_min_pstate() to be invoked during the >> initialization and cleanup that will set the P-state to the >> minimum one and will update the MSR using wrmsrl_on_cpu(). >> >>
USB Sound oops in Linus's latest tree
Hi, I'm getting the following oops with my USB sound device using Linus's latest tree of the moment, which has the sound tree pull in it. Anyone seen this before? thanks, greg k-h [ +0.002298] input: Schiit Audio USB Modi Device as /devices/pci:00/:00:14.0/usb2/2-10/2-10.1/2-10.1:1.2/0003:0D8C:1319.0001/input/input17 [ +0.56] hid-generic 0003:0D8C:1319.0001: input,hidraw0: USB HID v1.00 Device [Schiit Audio USB Modi Device] on usb-:00:14.0-10.1/input2 [ +0.008749] BUG: unable to handle kernel NULL pointer dereference at 0014 [ +0.001151] IP: [] usb_audio_probe+0x1e1/0x8f0 [snd_usb_audio] [ +0.001142] PGD 0 [ +0.001114] Oops: [#1] PREEMPT SMP [ +0.001115] Modules linked in: snd_usb_audio(+) hid_generic snd_usbmidi_lib usbhid snd_rawmidi snd_seq_device hid media arc4 fuse btusb btrtl btbcm btintel bluetooth rt2800usb rt2x00usb rt2800lib rt2x00lib mac80211 crc_ccitt cfg80211 rfkill nls_cp437 vfat fat iTCO_wdt iTCO_vendor_support mxm_wmi x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd psmouse serio_raw pcspkr firewire_ohci firewire_core crc_itu_t xhci_pci ehci_pci xhci_hcd ehci_hcd mei_me usbcore mei lpc_ich mfd_core usb_common wmi evdev ip_tables x_tables [ +0.004079] CPU: 4 PID: 615 Comm: systemd-udevd Not tainted 4.6.0-rc1+ #103 [ +0.001382] Hardware name: /, BIOS KLZ8711D.86A.0457.2015.0713.1319 07/13/2015 [ +0.001387] task: 880098ec0e00 ti: 88025192 task.ti: 88025192 [ +0.001417] RIP: 0010:[] [] usb_audio_probe+0x1e1/0x8f0 [snd_usb_audio] [ +0.001414] RSP: 0018:880251923af0 EFLAGS: 00010246 [ +0.001409] RAX: RBX: 88024d602000 RCX: [ +0.001404] RDX: 880254e0b340 RSI: 8802559b99f8 RDI: 82181030 [ +0.001413] RBP: 880251923b50 R08: 00019d00 R09: 81385837 [ +0.001431] R10: ea0009461200 R11: 880253b3fe72 R12: [ +0.001411] R13: R14: 0001 R15: 88025338c212 [ +0.001436] FS: 7f7a8db567c0() GS:88025fb0() knlGS: [ +0.001431] CS: 0010 DS: ES: CR0: 80050033 [ +0.001445] CR2: 0014 CR3: 000251854000 CR4: 001406e0 [ +0.001451] Stack: [ +0.001433] 880253302e88 88024d602054 88009879d000 880253302e88 [ +0.001480] 880255f7e000 386430425355d030 ff00393133313a63 8800984f4098 [ +0.001466] 8800984f4000 c0e95728 88009879d030 c0e955a0 [ +0.001497] Call Trace: [ +0.001295] [] usb_probe_interface+0x1bd/0x300 [usbcore] [ +0.001427] [] driver_probe_device+0x249/0x450 [ +0.001400] [] __driver_attach+0x84/0x90 [ +0.001398] [] ? driver_probe_device+0x450/0x450 [ +0.001417] [] bus_for_each_dev+0x64/0xa0 [ +0.001369] [] driver_attach+0x1e/0x20 [ +0.001396] [] bus_add_driver+0x1eb/0x280 [ +0.001365] [] driver_register+0x60/0xe0 [ +0.001369] [] usb_register_driver+0x84/0x140 [usbcore] [ +0.001422] [] ? 0xc0e9d000 [ +0.001370] [] usb_audio_driver_init+0x1e/0x20 [snd_usb_audio] [ +0.001472] [] do_one_initcall+0xab/0x1d0 [ +0.001547] [] do_init_module+0x5f/0x1cd [ +0.001469] [] load_module+0x1368/0x1510 [ +0.001542] [] ? symbol_put_addr+0x50/0x50 [ +0.001468] [] SyS_finit_module+0xc8/0xf0 [ +0.001451] [] do_syscall_64+0x5e/0xc0 [ +0.001538] [] entry_SYSCALL64_slow_path+0x25/0x25 [ +0.001397] Code: f8 01 00 44 89 e6 48 89 df e8 dc 73 00 00 85 c0 89 c1 0f 88 99 00 00 00 48 8b 7b 10 e8 c9 0b 80 c0 85 c0 89 c1 0f 88 86 00 00 00 <41> 80 7d 14 00 0f 85 90 04 00 00 48 63 03 48 89 1c c5 40 90 e9 [ +0.001513] RIP [] usb_audio_probe+0x1e1/0x8f0 [snd_usb_audio] [ +0.001468] RSP [ +0.001576] CR2: 0014 [ +0.010610] ---[ end trace c9cdd61401b8f1d9 ]---
Re: [GIT PULL] USB driver patches for 4.6-rc1
On Fri, Mar 18, 2016 at 03:12:15PM -0700, Greg KH wrote: > On Fri, Mar 18, 2016 at 02:58:27PM -0700, Linus Torvalds wrote: > > On Fri, Mar 18, 2016 at 2:43 PM, Linus Torvalds > > wrote: > > > > > > Something in this - or possibly the tty pull, but that doesn't sound > > > very likely - has killed my USB keyboard on my desktop. > > > > Yeah, the bisect is now solidly in the usb part. > > > > The machine has > > > > 00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI > > Controller (rev 31) > > 03:00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host > > Controller > > > > and the keyboard and mouse are on > > > > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M > > > > which seems to be that ASMedia 3.1 controller. > > > > In case that gives anybody a clue while I continue bisecting. > > Hm, your tree as of this morning works just fine for me right now (am > typing this from a USB keyboard), but I have an older host controller: > 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset > Family USB xHCI (rev 04) > > > I do see an oops in the snd_usb_audio driver that I didn't notice > before: Ok, I pulled your latest tree and I get the same results, sound driver crashes, but keyboard works fine. I'll go poke the sound developers about it. thanks, greg k-h
[RFC PATCH 2/4] workqueue: introduce support for attaching to cgroups
Introduce cgroup aware unbounded worker pools. Whenever a new worker thread is
created, create_worker attaches itself to the cgroups of the task that called
alloc_workqueue(). New worker pools are created if there's no match in the
global
list of cgroup aware worker pools.
Signed-off-by: Bandan Das
---
include/linux/workqueue.h | 2 +
kernel/workqueue.c | 212 +---
kernel/workqueue_internal.h | 4 +
3 files changed, 204 insertions(+), 14 deletions(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index ca73c50..7afb72d 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -131,6 +131,7 @@ struct workqueue_attrs {
int nice; /* nice level */
cpumask_var_t cpumask;/* allowed CPUs */
boolno_numa;/* disable NUMA affinity */
+ boolcg_enabled; /* cgroups aware */
};
static inline struct delayed_work *to_delayed_work(struct work_struct *work)
@@ -308,6 +309,7 @@ enum {
* http://thread.gmane.org/gmane.linux.kernel/1480396
*/
WQ_POWER_EFFICIENT = 1 << 7,
+ WQ_CGROUPS = 1 << 8,
__WQ_DRAINING = 1 << 16, /* internal: workqueue is draining */
__WQ_ORDERED= 1 << 17, /* internal: workqueue is ordered */
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7ff5dc7..f052d85 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include "workqueue_internal.h"
@@ -139,8 +140,18 @@ enum {
* MD: wq_mayday_lock protected.
*/
+/*
+ * list of tasks that "own" the cgroups that
+ * this pool is attached to
+ */
+struct cgroup_owners {
+ struct task_struct *owner;
+ struct list_headlink;
+};
+
/* struct worker is defined in workqueue_internal.h */
+
struct worker_pool {
spinlock_t lock; /* the pool lock */
int cpu;/* I: the associated cpu */
@@ -169,6 +180,8 @@ struct worker_pool {
struct worker *manager; /* L: purely informational */
struct mutexattach_mutex; /* attach/detach exclusion */
struct list_headworkers;/* A: attached workers */
+ struct list_headcg_owners; /* tasks using this pool*/
+ struct list_headunbound_node; /* all cgroup aware pools */
struct completion *detach_completion; /* all workers detached */
struct ida worker_ida; /* worker IDs for task name */
@@ -219,6 +232,7 @@ struct pool_workqueue {
*/
struct work_struct unbound_release_work;
struct rcu_head rcu;
+ struct task_struct *owner; /*for cgroups */
} __aligned(1 << WORK_STRUCT_FLAG_BITS);
/*
@@ -299,6 +313,7 @@ static DEFINE_MUTEX(wq_pool_mutex); /* protects pools and
workqueues list */
static DEFINE_SPINLOCK(wq_mayday_lock);/* protects wq->maydays list */
static LIST_HEAD(workqueues); /* PR: list of all workqueues */
+static LIST_HEAD(unbound_cgpool); /* list of cgroup aware worker pools */
static bool workqueue_freezing;/* PL: have wqs started
freezing? */
/* PL: allowable cpus for unbound wqs and work items */
@@ -425,6 +440,12 @@ static void workqueue_sysfs_unregister(struct
workqueue_struct *wq);
if (({ assert_rcu_or_wq_mutex(wq); false; })) { } \
else
+#define for_each_unbound_cgpool(pool) \
+ list_for_each_entry_rcu((pool), &(unbound_cgpool), unbound_node)
+
+#define for_each_task_cgpool(cgtask, pool) \
+ list_for_each_entry_rcu((cgtask), &(pool)->cg_owners, link)
+
#ifdef CONFIG_DEBUG_OBJECTS_WORK
static struct debug_obj_descr work_debug_descr;
@@ -700,6 +721,7 @@ static struct pool_workqueue *get_work_pwq(struct
work_struct *work)
*
* Return: The worker_pool @work was last associated with. %NULL if none.
*/
+
static struct worker_pool *get_work_pool(struct work_struct *work)
{
unsigned long data = atomic_long_read(>data);
@@ -757,6 +779,7 @@ static bool work_is_canceling(struct work_struct *work)
* they're being called with pool->lock held.
*/
+
static bool __need_more_worker(struct worker_pool *pool)
{
return !atomic_read(>nr_running);
@@ -1072,6 +1095,7 @@ static void get_pwq(struct pool_workqueue *pwq)
static void put_pwq(struct pool_workqueue *pwq)
{
lockdep_assert_held(>pool->lock);
+
if (likely(--pwq->refcnt))
return;
if (WARN_ON_ONCE(!(pwq->wq->flags & WQ_UNBOUND)))
@@ -1387,6 +1411,9 @@ retry:
/* pwq which will be used unless @work is executing elsewhere */
if (!(wq->flags & WQ_UNBOUND))
