Re: [PATCH 07/22] openrisc: add atomic bitops
Hello, On Sun, Jan 15, 2017 at 01:42:56PM +0800, kbuild test robot wrote: > Hi Stefan, > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.10-rc3 next-20170113] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Stafford-Horne/Openrisc-patchees-from-backlog-for-4-11/20170115-121623 > config: openrisc-or1ksim_defconfig (attached as .config) > compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1 > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=openrisc > > All errors (new ones prefixed by >>): > >arch/openrisc/include/asm/bitops/atomic.h: Assembler messages: > >> arch/openrisc/include/asm/bitops/atomic.h:70: Error: unknown opcode2 > >> `l.lwa'. > >> arch/openrisc/include/asm/bitops/atomic.h:72: Error: unknown opcode2 > >> `l.swa'. > -- >arch/openrisc/include/asm/bitops/atomic.h: Assembler messages: > >> arch/openrisc/include/asm/bitops/atomic.h:70: Error: unknown opcode2 > >> `l.lwa'. > >> arch/openrisc/include/asm/bitops/atomic.h:72: Error: unknown opcode2 > >> `l.swa'. > >> arch/openrisc/include/asm/bitops/atomic.h:70: Error: unknown opcode2 > >> `l.lwa'. > >> arch/openrisc/include/asm/bitops/atomic.h:72: Error: unknown opcode2 > >> `l.swa'. > -- >arch/openrisc/include/asm/bitops/atomic.h: Assembler messages: >arch/openrisc/include/asm/bitops/atomic.h:90: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:92: Error: unknown opcode2 > `l.swa'. >arch/openrisc/include/asm/bitops/atomic.h:18: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:20: Error: unknown opcode2 > `l.swa'. >arch/openrisc/include/asm/bitops/atomic.h:90: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:92: Error: unknown opcode2 > `l.swa'. >arch/openrisc/include/asm/bitops/atomic.h:35: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:37: Error: unknown opcode2 > `l.swa'. >arch/openrisc/include/asm/bitops/atomic.h:35: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:37: Error: unknown opcode2 > `l.swa'. > >> arch/openrisc/include/asm/bitops/atomic.h:70: Error: unknown opcode2 > >> `l.lwa'. > >> arch/openrisc/include/asm/bitops/atomic.h:72: Error: unknown opcode2 > >> `l.swa'. > >> arch/openrisc/include/asm/bitops/atomic.h:70: Error: unknown opcode2 > >> `l.lwa'. > >> arch/openrisc/include/asm/bitops/atomic.h:72: Error: unknown opcode2 > >> `l.swa'. >arch/openrisc/include/asm/bitops/atomic.h:90: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:92: Error: unknown opcode2 > `l.swa'. >arch/openrisc/include/asm/bitops/atomic.h:90: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:92: Error: unknown opcode2 > `l.swa'. >arch/openrisc/include/asm/bitops/atomic.h:18: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:20: Error: unknown opcode2 > `l.swa'. >arch/openrisc/include/asm/bitops/atomic.h:18: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:20: Error: unknown opcode2 > `l.swa'. >arch/openrisc/include/asm/bitops/atomic.h:90: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:92: Error: unknown opcode2 > `l.swa'. > >> arch/openrisc/include/asm/bitops/atomic.h:70: Error: unknown opcode2 > >> `l.lwa'. > >> arch/openrisc/include/asm/bitops/atomic.h:72: Error: unknown opcode2 > >> `l.swa'. >arch/openrisc/include/asm/bitops/atomic.h:35: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:37: Error: unknown opcode2 > `l.swa'. >arch/openrisc/include/asm/bitops/atomic.h:18: Error: unknown opcode2 > `l.lwa'. >arch/openrisc/include/asm/bitops/atomic.h:20: Error: unknown opcode2 > `l.swa'. > >> arch/openrisc/include/asm/bitops/atomic.h:70: Error: unknown opcode2 > >> `l.lwa'. > >> arch/openrisc/include/asm/bitops/atomic.h:72: Error: unkn
Re: [PATCH 00/22] Openrisc patchees from backlog for 4.11
Hello Guenter, On Sat, Jan 14, 2017 at 09:17:01PM -0800, Guenter Roeck wrote: > On 01/14/2017 03:07 PM, Stafford Horne wrote: > > Hi All, > > > > This is another set of patches which I have been pulling out of the > > openrisc backlogs. Its a bit of a process since I need to cleanup commit > > messages, review and test the patches. > > > > The interesting things here are: > > - optimized memset and memcpy routines, ~20% boot time saving > > - support for cpu idling > > - adding support for l.swa and l.lwa atomic operations (in spec from 2014) > > - use atomics to implement: bitops, cmpxchg, futex, spinlocks > > - the atomics are in preparation for SMP support > > > > Testing: > > I have used the kselftests to validate the changes especially the futex > > operations with the futex test. Other atomic operations are common so no > > explicit testing. > > > > Note for testers: > > The l.swa and l.lwa emulation is broken in qemu openrisc port. I have sent > > patches [1] to qemu-devel to fix the qemu issues. > > > > Thanks a lot for the note. Cherry-picked and applied ... > > Are you going to add the series to -next ? That would give it some automatic > test exposure (including the various auto-builders). Yes, I was planning to push to my next branch, but I wanted to make sure I sent this note on qemu before pushing it because I was sure it would break. Also, as found by the build robots a late version toolchain would also be required to build/test these. Let me know if there is an issue or if you need any help with this. :: or1k-musl-linux- chain :: Get it here: https://github.com/openrisc/or1k-gcc/tree/musl-5.4.0/gcc - build using https://github.com/openrisc/musl-cross (would suggest my pull request - will merge soon https://github.com/openrisc/musl-cross/pull/1) OR :: or1k-elf- chain :: Get it here: https://github.com/openrisc/or1k-gcc/tree/or1k-5.4.0/gcc - build using baremetal/newlib https://github.com/openrisc/newlib - instructions http://openrisc.io/newlib/building.html > Anyway, today's -next gets a warning traceback as attached. That happens even > with the above mentioned patch applied to qemu. Oh, I didnt see this. I will look into it, thanks for highlighting. I havent started testing -next yet. -Stafford > OpenRISC Linux -- http://openrisc.io > [ cut here ] > WARNING: CPU: 0 PID: 0 at ./include/linux/jump_label.h:198 0xc02d758c > static_key_slow_inc used before call to jump_label_init > Modules linked in: > CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.0-rc3-next-20170113 #1 > Stack dump [0xc0385f3c]: > sp + 00: 0xc0385f3c > sp + 04: 0xc0385f60 > sp + 08: 0xc047a0b4 > sp + 12: 0xc0303662 > sp + 16: 0x > sp + 20: 0xc02d758c > sp + 24: 0x0009 > sp + 28: 0x00c6 > sp + 32: 0xc0167bc0 > sp + 36: 0xc0385f68 > sp + 40: 0xc000b5d8 > sp + 44: 0x > sp + 48: 0x > sp + 52: 0xc0303662 > sp + 56: 0x00c6 > sp + 60: 0xc02d758c > sp + 64: 0xc0385f9c > sp + 68: 0xc0385fb0 > sp + 72: 0xc0483954 > sp + 76: 0xc04839b0 > sp + 80: 0xc1fff1e0 > sp + 84: 0xc047a00c > sp + 88: 0x > sp + 92: 0xc000b620 > sp + 96: 0xc030367f > sp + 100: 0xc0385fb0 > sp + 104: 0xc0385fb0 > sp + 108: 0xc0483930 > sp + 112: 0xc02d758c > sp + 116: 0xc02e1cc4 > sp + 120: 0x > sp + 124: 0x > sp + 128: 0xc03a6798 > sp + 132: 0xc0385fd8 > sp + 136: 0xc047a014 > sp + 140: 0xc047a02c > sp + 144: 0xc03beb14 > sp + 148: 0xc1fff1e0 > sp + 152: 0xc03a68e0 > sp + 156: 0xc02e0070 > sp + 160: 0xc03b9e74 > sp + 164: 0xc03beb14 > sp + 168: 0xc0386000 > sp + 172: 0x > sp + 176: 0x > sp + 180: 0x > sp + 184: 0x > sp + 188: 0x > sp + 192: 0x > > [] > > [] > > [] > > [] > > [] > > [] > > [] > > [] > > [] > > === > ---[ end trace ]---
Re: taint/module: Fix problems when out-of-kernel driver defines true or false
http://lkml.iu.edu//hypermail/linux/kernel/1701.0/01592.html says Larry's patch was applied Jan. 3 2017. So far it hasn't showed in pull updates. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks
[PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"
So there's a new mpt3sas SCSI driver boot regression, introduced in this merge window, which made one of my servers unbootable. The kernel, starting at upstream commit a829a8445f09, would hang thusly: [6.230363] Linux agpgart interface v0.103 [6.245029] brd: module loaded [6.253233] loop: module loaded [6.256695] mpt3sas version 14.101.00.00 loaded [6.261890] mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (65950628 kB) [6.326222] mpt2sas_cm0: MSI-X vectors supported: 1, no of cores: 32, max_msix_vectors: -1 [6.334953] mpt2sas0-msix0: PCI-MSI-X enabled: IRQ 24 [6.340237] mpt2sas_cm0: iomem(0xdff3c000), mapped(0xc90007414000), size(16384) [6.349002] mpt2sas_cm0: ioport(0xe000), size(256) [6.410830] mpt2sas_cm0: sending message unit reset !! [6.417739] mpt2sas_cm0: message unit reset: SUCCESS [6.463486] mpt2sas_cm0: Allocated physical memory: size(8199 kB) [6.469820] mpt2sas_cm0: Current Controller Queue Depth(3640),Max Controller Queue Depth(3712) [6.478840] mpt2sas_cm0: Scatter Gather Elements per IO(128) [6.530653] mpt2sas_cm0: LSISAS2008: FWVersion(12.00.00.00), ChipRevision(0x03), BiosVersion(07.23.01.00) [6.540621] mpt2sas_cm0: Protocol=( [6.540622] Initiator [6.544346] ,Target [6.546844] ), [6.549168] Capabilities=( [6.551165] TLR [6.554098] ,EEDP [6.556095] ,Snapshot Buffer [6.558249] ,Diag Trace Buffer [6.561359] ,Task Set Full [6.564666] ,NCQ [6.567594] ) [6.571517] scsi host0: Fusion MPT SAS Host [6.576539] mpt2sas_cm0: sending port enable !! [6.576699] ahci :00:11.0: version 3.0 [6.577285] ahci :00:11.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode [6.577290] ahci :00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc [6.579218] scsi host1: ahci [6.579685] scsi host2: ahci [6.5800[ 39.972084] sd 0:0:0:0: attempting task abort! scmd(881014cb9500) [ 39.978809] sd 0:0:0:0: [sda] tag#0 CDB: ATA command pass through(12)/Blank a1 08 2e 00 01 00 00 00 00 ec 00 00 [ 39.989346] scsi target0:0:0: handle(0x0009), sas_address(0x44332211), phy(0) [ 39.997584] scsi target0:0:0: enclosure_logical_id(0x5003048003e10c00), slot(31) [ 40.005425] sd 0:0:0:0: task abort: SUCCESS scmd(881014cb9500) udevd[472]: timeout 'ata_id --export /dev/sda' udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] [ this would continue ad infinitum. ] The correct bootup sequence would be: [6.252918] loop: module loaded [6.256390] mpt3sas version 14.101.00.00 loaded [6.261554] mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (65950628 kB) [6.325894] mpt2sas_cm0: MSI-X vectors supported: 1, no of cores: 32, max_msix_vectors: -1 [6.334640] mpt2sas0-msix0: PCI-MSI-X enabled: IRQ 24 [6.339925] mpt2sas_cm0: iomem(0xdff3c000), mapped(0xc900073f4000), size(16384) [6.348672] mpt2sas_cm0: ioport(0xe000), size(256) [6.410508] mpt2sas_cm0: sending message unit reset !! [6.417437] mpt2sas_cm0: message unit reset: SUCCESS [6.463275] mpt2sas_cm0: Allocated physical memory: size(8199 kB) [6.469627] mpt2sas_cm0: Current Controller Queue Depth(3640),Max Controller Queue Depth(3712) [6.478635] mpt2sas_cm0: Scatter Gather Elements per IO(128) [6.530433] mpt2sas_cm0: LSISAS2008: FWVersion(12.00.00.00), ChipRevision(0x03), BiosVersion(07.23.01.00) [6.540424] mpt2sas_cm0: Protocol=( [6.540425] Initiator [6.544150] ,Target [6.546644] ), [6.548968] Capabilities=( [6.550943] TLR [6.553901] ,EEDP [6.555898] ,Snapshot Buffer [6.558050] ,Diag Trace Buffer [6.561159] ,Task Set Full [6.564462] ,NCQ [6.567395] ) [6.571316] scsi host0: Fusion MPT SAS Host [6.576344] mpt2sas_cm0: sending port enable !! [6.576495] ahci :00:11.0: version 3.0 [6.577100] ahci :00:11.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode [6.577105] ahci :00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc [6.579016] scsi host1: ahci [6.579387] scsi host2: ahci [6.[ [32m OK [0m] Started Journal Service. ... (BTW., note the various broken printk lines - which is an unrelated bug.) I bisected the regression back to this upstream merge commit done by Linus: commit a829a8445f09036404060f4d6489cb13433f4304 Merge: 84b607913442 f5b893c94715 Author: Linus Torvalds Date: Wed De
Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering
On Sun, Jan 15, 2017 at 08:57:11AM +0100, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > On Sun, Jan 15, 2017 at 08:11:23AM +0100, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney wrote:
> > >
> > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > > index 357b32aaea48..5fdfe874229e 100644
> > > > --- a/include/linux/rcupdate.h
> > > > +++ b/include/linux/rcupdate.h
> > > > @@ -1175,11 +1175,11 @@ do { \
> > > > * if the UNLOCK and LOCK are executed by the same CPU or if the
> > > > * UNLOCK and LOCK operate on the same lock variable.
> > > > */
> > > > -#ifdef CONFIG_PPC
> > > > +#ifdef CONFIG_ARCH_WEAK_RELACQ
> > > > #define smp_mb__after_unlock_lock()smp_mb() /* Full ordering for
> > > > lock. */
> > > > -#else /* #ifdef CONFIG_PPC */
> > > > +#else /* #ifdef CONFIG_ARCH_WEAK_RELACQ */
> > > > #define smp_mb__after_unlock_lock()do { } while (0)
> > > > -#endif /* #else #ifdef CONFIG_PPC */
> > > > +#endif /* #else #ifdef CONFIG_ARCH_WEAK_RELACQ */
> > > >
> > > >
> > >
> > > So at the risk of sounding totally pedantic, why not structure it like
> > > the
> > > existing smp_mb__before/after*() primitives in barrier.h?
> > >
> > > That allows asm-generic/barrier.h to pick up the definition - for example
> > > in the
> > > case of smp_acquire__after_ctrl_dep() we do:
> > >
> > > #ifndef smp_acquire__after_ctrl_dep
> > > #define smp_acquire__after_ctrl_dep() smp_rmb()
> > > #endif
> > >
> > > Which allows Tile to relax it:
> > >
> > > arch/tile/include/asm/barrier.h:#define smp_acquire__after_ctrl_dep()
> > > barrier()
> > >
> > > I.e. I'd move the API definition out of rcupdate.h and into barrier.h -
> > > even
> > > though tree-RCU is the only user of this barrier type.
> >
> > I wouldn't have any problem with that, however, some time back it was
> > moved into RCU because (you guessed it!) RCU is the only user. ;-)
>
> Indeed ...
>
> [sounds of rummaging around in the Git tree]
>
> I found this commit of yours from ancient history (more than a year ago!):
>
> commit 12d560f4ea87030667438a169912380be00cea4b
> Author: Paul E. McKenney
> Date: Tue Jul 14 18:35:23 2015 -0700
>
> rcu,locking: Privatize smp_mb__after_unlock_lock()
>
> RCU is the only thing that uses smp_mb__after_unlock_lock(), and is
> likely the only thing that ever will use it, so this commit makes this
> macro private to RCU.
>
> Signed-off-by: Paul E. McKenney
> Cc: Will Deacon
> Cc: Peter Zijlstra
> Cc: Benjamin Herrenschmidt
> Cc: "linux-a...@vger.kernel.org"
>
> So I concur and I'm fine with your patch - or with the status quo code as
> well.
I already have the patch queued, so how about I keep it if I get an ack
from the powerpc guys and drop it otherwise?
Thanx, Paul
Re: [PATCH v4 3/8] PCI: Don't block runtime PM for Thunderbolt host hotplug ports
On Thu, Jan 12, 2017 at 11:02:59AM +0200, Mika Westerberg wrote:
> On Thu, Jan 12, 2017 at 02:47:07AM +0100, Lukas Wunner wrote:
> > On Wed, Jan 11, 2017 at 12:02:10PM +0200, Mika Westerberg wrote:
> > > On Sun, Jan 08, 2017 at 09:41:45AM +0100, Lukas Wunner wrote:
> > > > Hotplug ports generally block their parents from suspending to D3hot as
> > > > otherwise their interrupts couldn't be delivered.
> > > >
> > > > An exception are Thunderbolt host controllers: They have a separate
> > > > GPIO pin to side-band signal plug events even if the controller is
> > > > powered down or its parent ports are suspended to D3. They can be told
> > > > apart from Thunderbolt controllers in attached devices by checking if
> > > > they're situated below a non-Thunderbolt device (typically a root port,
> > > > or the downstream port of a PCIe switch in the case of the MacPro6,1).
> > > >
> > > > To enable runtime PM for Thunderbolt on the Mac, the downstream bridges
> > > > of a host controller must not block runtime PM on the upstream bridge as
> > > > power to the chip is only cut once the upstream bridge has suspended.
> > > > Amend the condition in pci_dev_check_d3cold() accordingly.
> > > >
> > > > Cc: Mika Westerberg
> > > > Cc: Rafael J. Wysocki
> > > > Cc: Andreas Noever
> > > > Cc: Tomas Winkler
> > > > Cc: Amir Levy
> > > > Signed-off-by: Lukas Wunner
> > > > ---
> > > > drivers/pci/pci.c | 13 -
> > > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > > index 8ed098d..0b03fe7 100644
> > > > --- a/drivers/pci/pci.c
> > > > +++ b/drivers/pci/pci.c
> > > > @@ -2271,6 +2271,7 @@ bool pci_bridge_d3_possible(struct pci_dev
> > > > *bridge)
> > > >
> > > > static int pci_dev_check_d3cold(struct pci_dev *dev, void *data)
> > > > {
> > > > + struct pci_dev *parent, *grandparent;
> > > > bool *d3cold_ok = data;
> > > >
> > > > if (/* The device needs to be allowed to go D3cold ... */
> > > > @@ -2284,7 +2285,17 @@ static int pci_dev_check_d3cold(struct pci_dev
> > > > *dev, void *data)
> > > > !pci_power_manageable(dev) ||
> > > >
> > > > /* Hotplug interrupts cannot be delivered if the link is
> > > > down. */
> > > > - dev->is_hotplug_bridge)
> > > > + (dev->is_hotplug_bridge &&
> > > > +
> > > > + /*
> > > > +* Exception: Thunderbolt host controllers have a pin
> > > > to
> > > > +* side-band signal plug events. Their hotplug ports
> > > > are
> > > > +* recognizable by having a non-Thunderbolt device as
> > > > +* grandparent.
> > > > +*/
> > > > + !(dev->is_thunderbolt && (parent =
> > > > pci_upstream_bridge(dev)) &&
> > > > +(grandparent =
> > > > pci_upstream_bridge(parent)) &&
> > > > +
> > > > !grandparent->is_thunderbolt)))
> > >
> > > Can you move this to its own helper function?
> >
> > I can certainly do that.
> >
> > Could one of you guys confirm that the code above is safe on non-Macs?
> >
> > Specifically, the very first Thunderbolt chips (Light Ridge, Eagle Ridge)
> > had no POC, i.e. they were unable to power themselves off. Apple put an
> > ARM Cortex (NXP LPC1112) on the logic board which snoops on the connector
> > lines for hotplug detection while the Thunderbolt controller is powered
> > down. The power rails to the controller are brought up and down with
> > separate load switches. This functionality became integrated into the
> > controller starting with Cactus Ridge in 2012.
> >
> > So I know the above code is safe on Macs. However on non-Macs these
> > extra chips for power management may not exist, i.e. the controller
> > stays on all the time and then I shouldn't suspend the upstream bridge
> > to D3. I assume that such machines do not exist as Apple was pretty
> > much the only vendor with Thunderbolt gear in the 2010-2012 time frame.
> > The only other one I know of was the Sony Vaio Z21 which used the
> > optical version of Thunderbolt to attach a docking station, but these
> > are rare.
> >
> > If you know of non-Macs which might be broken by the above code snippet,
> > I could dmi-quirk this to Macs plus constrain to CONFIG_THUNDERBOLT being
> > enabled.
>
> The thunderbolt chips I have seen all include the side-band hotplug
> detection GPIO. In addition the whole PCIe hierarchy is powered down
> when there is nothing connected. So in that sense, I don't see how this
> could break them.
The pin to side-band signal a plug event is not present on Light Ridge
(and presumably Light Peak), only on Eagle Ridge and newer (2011+).
The pins for power control (Force Power, Go2Sx, Ok2Go2Sx) are not present
on Light Ridge and Eagle Ridge, only on Cactus Ridge and newer (2012+).
In other words, Thunderbolt controllers had
Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering
* Paul E. McKenney wrote: > > [sounds of rummaging around in the Git tree] > > > > I found this commit of yours from ancient history (more than a year ago!): > > > > commit 12d560f4ea87030667438a169912380be00cea4b > > Author: Paul E. McKenney > > Date: Tue Jul 14 18:35:23 2015 -0700 > > > > rcu,locking: Privatize smp_mb__after_unlock_lock() > > > > RCU is the only thing that uses smp_mb__after_unlock_lock(), and is > > likely the only thing that ever will use it, so this commit makes this > > macro private to RCU. > > > > Signed-off-by: Paul E. McKenney > > Cc: Will Deacon > > Cc: Peter Zijlstra > > Cc: Benjamin Herrenschmidt > > Cc: "linux-a...@vger.kernel.org" > > > > So I concur and I'm fine with your patch - or with the status quo code as > > well. > > I already have the patch queued, so how about I keep it if I get an ack > from the powerpc guys and drop it otherwise? Yeah, sounds good! Your patch made me look up 'RelAcq' so it has documentation value as well ;-) Thanks, Ingo
[GIT PULL] EFI fixes
Linus,
Please pull the latest efi-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
efi-urgent-for-linus
# HEAD: 0100a3e67a9cef64d72cd3a1da86f3ddbee50363 efi/x86: Prune invalid
memory map entries and fix boot regression
A number of regression fixes:
- Fix a boot hang on machines that have somewhat unusual memory map entries of
phys_addr=0x0 num_pages=0, which broke due to a recent commit. This commit
got
cherry-picked from the v4.11 queue because the bug is affecting real
machines.
- Fix a boot hang also reported by KASAN, caused by incorrect init ordering
introduced by a recent optimization.
- Fix a recent robustification fix to allocate_new_fdt_and_exit_boot() that
introduced an invalid assumption. Neither bugs were seen in the wild AFAIK.
Thanks,
Ingo
-->
Ard Biesheuvel (1):
efi/libstub/arm*: Pass latest memory map to the kernel
Nicolai Stange (1):
x86/efi: Don't allocate memmap through memblock after mm_init()
Peter Jones (1):
efi/x86: Prune invalid memory map entries and fix boot regression
arch/x86/platform/efi/efi.c| 66 ++
arch/x86/platform/efi/quirks.c | 4 +-
drivers/firmware/efi/fake_mem.c| 3 +-
drivers/firmware/efi/libstub/efistub.h | 8
drivers/firmware/efi/libstub/fdt.c | 87 ++
drivers/firmware/efi/memmap.c | 38 +++
include/linux/efi.h| 2 +
7 files changed, 165 insertions(+), 43 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 936a488d6cf6..274dfc481849 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -210,6 +210,70 @@ int __init efi_memblock_x86_reserve_range(void)
return 0;
}
+#define OVERFLOW_ADDR_SHIFT(64 - EFI_PAGE_SHIFT)
+#define OVERFLOW_ADDR_MASK (U64_MAX << OVERFLOW_ADDR_SHIFT)
+#define U64_HIGH_BIT (~(U64_MAX >> 1))
+
+static bool __init efi_memmap_entry_valid(const efi_memory_desc_t *md, int i)
+{
+ u64 end = (md->num_pages << EFI_PAGE_SHIFT) + md->phys_addr - 1;
+ u64 end_hi = 0;
+ char buf[64];
+
+ if (md->num_pages == 0) {
+ end = 0;
+ } else if (md->num_pages > EFI_PAGES_MAX ||
+ EFI_PAGES_MAX - md->num_pages <
+ (md->phys_addr >> EFI_PAGE_SHIFT)) {
+ end_hi = (md->num_pages & OVERFLOW_ADDR_MASK)
+ >> OVERFLOW_ADDR_SHIFT;
+
+ if ((md->phys_addr & U64_HIGH_BIT) && !(end & U64_HIGH_BIT))
+ end_hi += 1;
+ } else {
+ return true;
+ }
+
+ pr_warn_once(FW_BUG "Invalid EFI memory map entries:\n");
+
+ if (end_hi) {
+ pr_warn("mem%02u: %s range=[0x%016llx-0x%llx%016llx]
(invalid)\n",
+ i, efi_md_typeattr_format(buf, sizeof(buf), md),
+ md->phys_addr, end_hi, end);
+ } else {
+ pr_warn("mem%02u: %s range=[0x%016llx-0x%016llx] (invalid)\n",
+ i, efi_md_typeattr_format(buf, sizeof(buf), md),
+ md->phys_addr, end);
+ }
+ return false;
+}
+
+static void __init efi_clean_memmap(void)
+{
+ efi_memory_desc_t *out = efi.memmap.map;
+ const efi_memory_desc_t *in = out;
+ const efi_memory_desc_t *end = efi.memmap.map_end;
+ int i, n_removal;
+
+ for (i = n_removal = 0; in < end; i++) {
+ if (efi_memmap_entry_valid(in, i)) {
+ if (out != in)
+ memcpy(out, in, efi.memmap.desc_size);
+ out = (void *)out + efi.memmap.desc_size;
+ } else {
+ n_removal++;
+ }
+ in = (void *)in + efi.memmap.desc_size;
+ }
+
+ if (n_removal > 0) {
+ u64 size = efi.memmap.nr_map - n_removal;
+
+ pr_warn("Removing %d invalid memory map entries.\n", n_removal);
+ efi_memmap_install(efi.memmap.phys_map, size);
+ }
+}
+
void __init efi_print_memmap(void)
{
efi_memory_desc_t *md;
@@ -472,6 +536,8 @@ void __init efi_init(void)
}
}
+ efi_clean_memmap();
+
if (efi_enabled(EFI_DBG))
efi_print_memmap();
}
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 10aca63a50d7..30031d5293c4 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -214,7 +214,7 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
new_size = efi.memmap.desc_size * num_entries;
- new_phys = memblock_alloc(new_size, 0);
+ new_phys = efi_memmap_alloc(num_entries);
if (!new_phys) {
pr_err("Could not allocate boot services memmap\n");
return;
@@ -355,7
Re: 4.10-rc1: thinkpad x60: who ate my cpu?
On Sat 2017-01-14 12:30:54, Pavel Machek wrote: > Hi! > > On Thu 2017-01-12 20:19:31, Woody Suwalski wrote: > > Pavel Machek wrote: > > >Hi! > > > > > >>I used to have two cpus, and Thinkpad X60 should have two cores, but I > > >>only see one on 4.10-rc1. This machine went through many > > >>suspend/resume cycles. When backups finish, I'll try -rc2. > > >Whoever did it, he seems to have returned the cpu in -rc3. All seems > > >to be good now. > > > Actually since you have mentioned - I have checked my x60 - same problem - > > only one CPU. However I was running 4.8.13 with uptime 33 days, multiple > > sleep/wake-ups. > > Installed a current EOL 4.8.17 and rebooted - I see 2 CPUs. So the issue is > > older then 4.10 kernel, and I suspect it is the CPU hotplug / wakeup > > related... > > Hmm. So I seen two cores in -rc3 after boot. But it is quite well > possible that -rc1 was ok just after boot, too, and problem happened > sometime later (probably during suspend/resume cycles). Let me go back > to -rc1 to check. Indeed in -rc1 I see both CPUs after boot. So we have hard to reproduce case where 4.8 to 4.10 kernels lose one of the cpu cores... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[GIT PULL] perf fixes
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 18e7a45af91acdde99d3aa1372cc40e1f8142f7b perf/x86: Reject non
sampling events with precise_ip
Misc race fixes uncovered by fuzzing efforts, a Sparse fix, two PMU driver
fixes,
plus miscellanous tooling fixes.
Thanks,
Ingo
-->
Arnaldo Carvalho de Melo (4):
samples/bpf sock_example: Avoid getting ethhdr from two includes
samples/bpf trace_output_user: Remove duplicate sys/ioctl.h include
perf tools: Install tools/lib/traceevent plugins with install-bin
perf symbols: Robustify reading of build-id from sysfs
Colin King (1):
perf/x86/intel: Use ULL constant to prevent undefined shift behaviour
Daniel Bristot de Oliveira (1):
tools lib traceevent: Fix prev/next_prio for deadline tasks
David Carrillo-Cisneros (1):
perf/x86: Set pmu->module in Intel PMU modules
Jiri Olsa (5):
tools lib subcmd: Add OPT_STRING_OPTARG_SET option
perf record: Make __record_options static
perf record: Fix --switch-output documentation and comment
perf/x86/intel: Account interrupts for PEBS errors
perf/x86: Reject non sampling events with precise_ip
Masami Hiramatsu (3):
perf probe: Fix to get correct modname from elf header
perf probe: Fix --funcs to show correct symbols for offline module
perf probe: Fix to probe on gcc generated symbols for offline kernel
Namhyung Kim (1):
perf sched timehist: Show total scheduling time
Peter Zijlstra (2):
perf/core: Fix sys_perf_event_open() vs. hotplug
perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race
Prarit Bhargava (1):
perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell
init code
arch/x86/events/core.c | 4 +
arch/x86/events/intel/core.c | 2 +-
arch/x86/events/intel/cstate.c | 2 +
arch/x86/events/intel/ds.c | 6 +-
arch/x86/events/intel/rapl.c | 1 +
arch/x86/events/intel/uncore.c | 1 +
arch/x86/events/intel/uncore_snbep.c | 2 +-
include/linux/perf_event.h | 1 +
kernel/events/core.c | 175 ++---
samples/bpf/sock_example.h | 2 +-
samples/bpf/trace_output_user.c| 1 -
tools/lib/subcmd/parse-options.c | 3 +
tools/lib/subcmd/parse-options.h | 5 +
tools/lib/traceevent/plugin_sched_switch.c | 4 +-
tools/perf/Documentation/perf-record.txt | 4 +
tools/perf/Makefile.perf | 4 +-
tools/perf/builtin-record.c| 4 +-
tools/perf/builtin-sched.c | 17 ++-
tools/perf/util/probe-event.c | 105 +++--
tools/perf/util/symbol-elf.c | 6 +
20 files changed, 257 insertions(+), 92 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 019c5887b698..1635c0c8df23 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -505,6 +505,10 @@ int x86_pmu_hw_config(struct perf_event *event)
if (event->attr.precise_ip > precise)
return -EOPNOTSUPP;
+
+ /* There's no sense in having PEBS for non sampling events: */
+ if (!is_sampling_event(event))
+ return -EINVAL;
}
/*
* check that PEBS LBR correction does not conflict with
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 86138267b68a..d611cab214a6 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3987,7 +3987,7 @@ __init int intel_pmu_init(void)
x86_pmu.num_counters, INTEL_PMC_MAX_GENERIC);
x86_pmu.num_counters = INTEL_PMC_MAX_GENERIC;
}
- x86_pmu.intel_ctrl = (1 << x86_pmu.num_counters) - 1;
+ x86_pmu.intel_ctrl = (1ULL << x86_pmu.num_counters) - 1;
if (x86_pmu.num_counters_fixed > INTEL_PMC_MAX_FIXED) {
WARN(1, KERN_ERR "hw perf events fixed %d > max(%d), clipping!",
diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c
index fec8a461bdef..1076c9a77292 100644
--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -434,6 +434,7 @@ static struct pmu cstate_core_pmu = {
.stop = cstate_pmu_event_stop,
.read = cstate_pmu_event_update,
.capabilities = PERF_PMU_CAP_NO_INTERRUPT,
+ .module = THIS_MODULE,
};
static struct pmu cstate_pkg_pmu = {
@@ -447,6 +448,7 @@ static struct pmu cstate_pkg_pmu = {
.stop = cstate_pmu_event_stop,
.read = cstate_pmu_event_update,
.capabilities = PERF_PMU_CAP_NO_INTERRUPT,
+ .module = THIS_MODULE,
};
[PATCH] i2c: busses: constify dev_pm_ops structures
Declare dev_pm_ops structures as const as they are only stored in the pm
field of a device_driver structure. This field is of type const, so
dev_pm_ops structures having similar properties can be declared const
too.
File size before: drivers/i2c/busses/i2c-omap.o
textdata bss dec hex filename
6814 584 073981ce6 drivers/i2c/busses/i2c-omap.o
File size after: drivers/i2c/busses/i2c-omap.o
textdata bss dec hex filename
7006 392 073981ce6 drivers/i2c/busses/i2c-omap.o
Signed-off-by: Bhumika Goyal
---
drivers/i2c/busses/i2c-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index c7da0c4..1ebb5e9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1504,7 +1504,7 @@ static int omap_i2c_runtime_resume(struct device *dev)
return 0;
}
-static struct dev_pm_ops omap_i2c_pm_ops = {
+static const struct dev_pm_ops omap_i2c_pm_ops = {
SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
omap_i2c_runtime_resume, NULL)
};
--
1.9.1
[GIT PULL] nohz fix
Linus,
Please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
# HEAD: 24b91e360ef521a2808771633d76ebc68bd5604b nohz: Fix collision between
tick and other hrtimers
This fixes an old NOHZ race where we incorrectly calculate the next timer
interrupt in certain circumstances where hrtimers are pending, that can cause
hard to reproduce stalled-values artifacts in /proc/stat.
Thanks,
Ingo
-->
Frederic Weisbecker (1):
nohz: Fix collision between tick and other hrtimers
kernel/time/tick-sched.c | 9 +++--
kernel/time/tick-sched.h | 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 2c115fdab397..74e0388cc88d 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -767,7 +767,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched
*ts,
tick = expires;
/* Skip reprogram of event if its not changed */
- if (ts->tick_stopped && (expires == dev->next_event))
+ if (ts->tick_stopped && (expires == ts->next_tick))
goto out;
/*
@@ -787,6 +787,8 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched
*ts,
trace_tick_stop(1, TICK_DEP_MASK_NONE);
}
+ ts->next_tick = tick;
+
/*
* If the expiration time == KTIME_MAX, then we simply stop
* the tick timer.
@@ -802,7 +804,10 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched
*ts,
else
tick_program_event(tick, 1);
out:
- /* Update the estimated sleep length */
+ /*
+* Update the estimated sleep length until the next timer
+* (not only the tick).
+*/
ts->sleep_length = ktime_sub(dev->next_event, now);
return tick;
}
diff --git a/kernel/time/tick-sched.h b/kernel/time/tick-sched.h
index bf38226e5c17..075444e3d48e 100644
--- a/kernel/time/tick-sched.h
+++ b/kernel/time/tick-sched.h
@@ -27,6 +27,7 @@ enum tick_nohz_mode {
* timer is modified for nohz sleeps. This is necessary
* to resume the tick timer operation in the timeline
* when the CPU returns from nohz sleep.
+ * @next_tick: Next tick to be fired when in dynticks mode.
* @tick_stopped: Indicator that the idle tick has been stopped
* @idle_jiffies: jiffies at the entry to idle for idle time accounting
* @idle_calls:Total number of idle calls
@@ -44,6 +45,7 @@ struct tick_sched {
unsigned long check_clocks;
enum tick_nohz_mode nohz_mode;
ktime_t last_tick;
+ ktime_t next_tick;
int inidle;
int tick_stopped;
unsigned long idle_jiffies;
Re: Nokia N900: mixers changed between 4.9 and 4.10-rc3, no longer can use in-call speaker
Hi! > > Both are based on v4.7-rc1. v4.6 worked ok for me. > > > > Lets test mini-v4.7: in-call speaker works ok there, and no alsactl > > warnings. > > > > mini-v4.7+cb7e62256e99d285e415cf75db67558f0f8bb107+6d2de5ab4328718302 > > c54b20222c6b1a574c3fce > > > > : something seems to be broken there already. > > > > alsactl: set_control:1464: Cannot write control '2:0:0:TPA6130A2 > > Headphone Playback Volume:0' : Remote I/O error > > > > But in-call speakers and wired headset still seems to work. > > > > Lets test mini-v4.9... works ok. I don't even get the remote i/o > > error. Interesting. > > > > So regression seems to be between v4.9 and v4.10. Any ideas? > > Interesting... seems there are no sound relevant changes after v4.9. > > Looks like there are only three commits after v4.9 for sound/soc which > are built for Nokia N900: > > e411b0b5eb9b65257a050eac333d181d6e00e2c6 > e7aa450fe17890e59db7d3c2d8eff5b6b41fc531 > 63c3194b82530bd71fd49db84eb7ab656b8d404a > > Maybe something not related to sound/soc could broke it? Lets see. a9042defa29a01cc538b742eab047848e9b5ae14 -- works ok. ce38207f161513ee3d2bd3860489f07ebe65bc78 -- alsactl: set_control:1328: failed to obtain info for control #229 (No such file or directory) and broken in-call speaker. So this merge breaks stuff: commit ce38207f161513ee3d2bd3860489f07ebe65bc78 Merge: a9042de 995c6a7 Author: Linus Torvalds Date: Wed Dec 14 11:14:28 2016 -0800 Merge tag 'sound-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound ... Below are some highlights: ASoC: - support for stereo DAPM controls - some initial work on the of-graph sound card - regmap conversions of the remaining AC'97 drivers - a new version of the topology ABI; this should be backward compatible - updates / cleanups of rsnd, sunxi, sti, nau8825, samsung, arizona, Intel skylake, atom-sst - new drivers for Cirrus Logic CS42L42, Qualcomm MSM8916-WCD, and Realtek RT5665 ... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[GIT PULL] x86 fixes
Linus,
Please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
# HEAD: 453828625731d0ba7218242ef6ec88f59408f368 x86/mpx: Use compatible
types in comparison to fix sparse error
Misc fixes:
- unwinder fixes
- AMD CPU topology enumeration fixes
- microcode loader fixes
- x86 embedded platform fixes
- fix for a bootup crash that may trigger when clearcpuid= is used with
invalid values
Thanks,
Ingo
-->
Andy Shevchenko (2):
x86/cpu: Fix typo in the comment for Anniedale
x86/platform/intel-mid: Rename 'spidev' to 'mrfld_spidev'
Borislav Petkov (4):
x86/CPU/AMD: Fix Bulldozer topology
x86/CPU: Add native CPUID variants returning a single datum
x86/microcode: Use native CPUID to tickle out microcode revision
x86/microcode/intel: Add a helper which gives the microcode revision
Josh Poimboeuf (4):
x86/unwind: Silence warnings for non-current tasks
x86/unwind: Disable KASAN checks for non-current tasks
x86/unwind: Include __schedule() in stack traces
x86/entry: Fix the end of the stack for newly forked tasks
Junichi Nomura (2):
x86/microcode/intel: Fix allocation size of struct ucode_patch
x86/microcode/intel: Use correct buffer size for saving microcode data
Len Brown (1):
x86/tsc: Add the Intel Denverton Processor to native_calibrate_tsc()
Lukasz Odzioba (1):
x86/cpu: Fix bootup crashes by sanitizing the argument of the
'clearcpuid=' command-line option
Nicholas Mc Guire (1):
x86/boot: Add missing declaration of string functions
Tobias Klauser (1):
x86/mpx: Use compatible types in comparison to fix sparse error
arch/x86/boot/string.c | 1 +
arch/x86/boot/string.h | 9 +++
arch/x86/entry/entry_32.S | 30 --
arch/x86/entry/entry_64.S | 11 ++--
arch/x86/include/asm/intel-family.h| 2 +-
arch/x86/include/asm/microcode_intel.h | 15 +
arch/x86/include/asm/processor.h | 18 ++
arch/x86/include/asm/stacktrace.h | 2 +-
arch/x86/include/asm/switch_to.h | 10 +++-
arch/x86/kernel/cpu/amd.c | 9 +--
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/cpu/intel.c| 11 +---
arch/x86/kernel/cpu/microcode/intel.c | 70 ++
arch/x86/kernel/tsc.c | 1 +
arch/x86/kernel/unwind_frame.c | 30 +-
arch/x86/mm/mpx.c | 2 +-
arch/x86/platform/intel-mid/device_libs/Makefile | 2 +-
.../{platform_spidev.c => platform_mrfld_spidev.c} | 4 ++
18 files changed, 129 insertions(+), 100 deletions(-)
rename arch/x86/platform/intel-mid/device_libs/{platform_spidev.c =>
platform_mrfld_spidev.c} (91%)
diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
index cc3bd583dce1..9e240fcba784 100644
--- a/arch/x86/boot/string.c
+++ b/arch/x86/boot/string.c
@@ -14,6 +14,7 @@
#include
#include "ctype.h"
+#include "string.h"
int memcmp(const void *s1, const void *s2, size_t len)
{
diff --git a/arch/x86/boot/string.h b/arch/x86/boot/string.h
index 725e820602b1..113588ddb43f 100644
--- a/arch/x86/boot/string.h
+++ b/arch/x86/boot/string.h
@@ -18,4 +18,13 @@ int memcmp(const void *s1, const void *s2, size_t len);
#define memset(d,c,l) __builtin_memset(d,c,l)
#define memcmp __builtin_memcmp
+extern int strcmp(const char *str1, const char *str2);
+extern int strncmp(const char *cs, const char *ct, size_t count);
+extern size_t strlen(const char *s);
+extern char *strstr(const char *s1, const char *s2);
+extern size_t strnlen(const char *s, size_t maxlen);
+extern unsigned int atou(const char *s);
+extern unsigned long long simple_strtoull(const char *cp, char **endp,
+ unsigned int base);
+
#endif /* BOOT_STRING_H */
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 701d29f8e4d3..57f7ec35216e 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -255,23 +255,6 @@ ENTRY(__switch_to_asm)
END(__switch_to_asm)
/*
- * The unwinder expects the last frame on the stack to always be at the same
- * offset from the end of the page, which allows it to validate the stack.
- * Calling schedule_tail() directly would break that convention because its an
- * asmlinkage function so its argument has to be pushed on the stack. This
- * wrapper creates a proper "end of stack" frame header before the call.
- */
-ENTRY(schedule_tail_wrapper)
- FRAME_BEGIN
-
- pushl %eax
- callschedule_tail
- popl%eax
-
- FRAME_END
- ret
-ENDPROC(schedule_tail_wrapper)
-/*
* A newly forked process directly contex
Re: [PATCH] rcu: Narrow early boot window of illegal synchronous grace periods
On Sat, Jan 14, 2017 at 09:24:43PM -0800, Paul E. McKenney wrote:
> > Which means, you probably should tag your fix CC:stable and add
> >
> > Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
> >
> > to it too.
>
> Like this?
Very nice, ship it! :-)
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCHSET v6] blk-mq scheduling framework
> Il giorno 11 gen 2017, alle ore 22:39, Jens Axboe ha scritto: > > Another year, another posting of this patchset. The previous posting > was here: > > https://www.spinics.net/lists/kernel/msg2406106.html > > (yes, I've skipped v5, it was fixes on top of v4, not the rework). > > I've reworked bits of this to get rid of the shadow requests, thanks > to Bart for the inspiration. The missing piece, for me, was the fact > that we have the tags->rqs[] indirection array already. I've done this > somewhat differently, though, by having the internal scheduler tag > map be allocated/torn down when an IO scheduler is attached or > detached. This also means that when we run without a scheduler, we > don't have to do double tag allocations, it'll work like before. > > The patchset applies on top of 4.10-rc3, or can be pulled here: > > git://git.kernel.dk/linux-block blk-mq-sched.6 > > Hi Jens, I have checked this new version to find solutions to the apparent errors, mistakes or just unclear parts (to me) that I have pointed out before Christmas last year. But I have found no changes related to these problems. As I have already written, I'm willing to try to fix those errors myself, if they really are errors, but I would first need at least some minimal initial feedback and guidance. If needed, tell me how I can help you get in sync again with these issues (sending my reports again, sending a digest of them, ...). Thanks, Paolo > block/Kconfig.iosched| 50 > block/Makefile |3 > block/blk-core.c | 19 - > block/blk-exec.c |3 > block/blk-flush.c| 15 - > block/blk-ioc.c | 12 > block/blk-merge.c|4 > block/blk-mq-sched.c | 354 + > block/blk-mq-sched.h | 157 > block/blk-mq-sysfs.c | 13 + > block/blk-mq-tag.c | 58 ++-- > block/blk-mq-tag.h |4 > block/blk-mq.c | 413 +++--- > block/blk-mq.h | 40 +++ > block/blk-tag.c |1 > block/blk.h | 26 +- > block/cfq-iosched.c |2 > block/deadline-iosched.c |2 > block/elevator.c | 247 +++- > block/mq-deadline.c | 569 > +++ > block/noop-iosched.c |2 > drivers/nvme/host/pci.c |1 > include/linux/blk-mq.h |9 > include/linux/blkdev.h |6 > include/linux/elevator.h | 36 ++ > 25 files changed, 1732 insertions(+), 314 deletions(-) > > -- > Jens Axboe > > -- > To unsubscribe from this list: send the line "unsubscribe linux-block" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v3 04/10] net: dsa: Move ports assignment closer to error checking
Hello! On 1/15/2017 12:47 AM, Florian Fainelli wrote: Move the assignment of ports in _dsa_register_switch() closer to where it is checked, no functional change. Re-order declarations to be "Be" not needed. preserve the inverted christmas tree style. Signed-off-by: Florian Fainelli [...] MBR, Sergei
[thermal/intel_powerclamp] b4d590f251: WARNING:at_kernel/sched/idle.c:#play_idle
FYI, we noticed the following commit:
commit: b4d590f2511ecc219ca4a7a3cb81b366b10881ae ("thermal/intel_powerclamp:fix
sched_setscheduler fail")
url:
https://github.com/0day-ci/linux/commits/xinwu-liu-intel-com/thermal-intel_powerclamp-fix-sched_setscheduler-fail/20170113-231143
base: https://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
in testcase: idle-inject
with following parameters:
runtime: 60s
nr_threads: 200%
cur_state: 10cp
on test machine: 32 threads Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz with 32G
memory
caused below changes:
+---+++
| | cad8f6c4f6 | b4d590f251 |
+---+++
| boot_successes| 4 | 1 |
| boot_failures | 0 | 3 |
| WARNING:at_kernel/sched/idle.c:#play_idle | 0 | 3 |
+---+++
[ 31.795120]
[ 31.796570] [ cut here ]
[ 31.796573] [ cut here ]
[ 31.796585] WARNING: CPU: 6 PID: 9077 at kernel/sched/idle.c:298
play_idle+0x3f/0x191
[ 31.796594] WARNING: CPU: 15 PID: 9086 at kernel/sched/idle.c:298
play_idle+0x3f/0x191
[ 31.796617] Modules linked in:
[ 31.796620] Modules linked in:
[ 31.796621] sr_mod
[ 31.796623] sr_mod
[ 31.796625] cdrom
To reproduce:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.10.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONF
4.10 regression drm/i915: BUG/oops on lid open
Hi all, Since 4.10-rc1 I'm getting this on lid close/open on my trusty old ThinkPad X200s: pci :00:1e.0: PCI bridge to [bus 0d] BUG: unable to handle kernel NULL pointer dereference at (null) IP: intel_display_resume+0xaf/0x120 [i915] PGD 22b99b067 PUD 22b99a067 PMD 0 Oops: 0002 [#1] PREEMPT SMP Modules linked in: ccm rfcomm fuse xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables af_packet bnep msr xfs libcrc32c cdc_ether usbnet mii cdc_wdm cdc_acm dm_crypt algif_skcipher af_alg snd_hda_codec_conexant snd_hda_codec_generic arc4 snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm_oss snd_pcm mei_wdt iTCO_wdt iTCO_vendor_support iwldvm snd_seq mac80211 snd_seq_device snd_timer coretemp kvm_intel kvm irqbypass btusb btrtl btbcm btintel iwlwifi pcspkr snd_mixer_oss bluetooth thinkpad_acpi battery ac fjes i915 cfg80211 snd wmi rfkill drm_kms_helper video drm i2c_i801 fb_sys_fops syscopyarea e1000e sysfillrect sysimgblt i2c_algo_bit acpi_cpufreq ptp soundcore tpm_tis mei_me pps_core shpchp tpm_tis_core lpc_ich mei mfd_core button tpm serio_raw thermal ehci_pci uhci_hcd ehci_hcd usbcore sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua loop CPU: 0 PID: 12922 Comm: kworker/0:0 Not tainted 4.10.0-rc3-1.gf1c24bb-default #1 Hardware name: LENOVO 74665EG/74665EG, BIOS 6DET71WW (3.21 ) 12/13/2011 Workqueue: kacpi_notify acpi_os_execute_deferred task: 9e2c22854240 task.stack: becbcc85c000 RIP: 0010:intel_display_resume+0xaf/0x120 [i915] RSP: 0018:becbcc85fc70 EFLAGS: 00010282 RAX: c027a670 RBX: becbcc85fc78 RCX: RDX: 9e2c22854240 RSI: 000d RDI: 9e2c2d738210 RBP: becbcc85fcd0 R08: 0010 R09: R10: 9e2c2d738380 R11: c0451d00 R12: 9e2c2d738000 R13: R14: 9e2c2d738210 R15: FS: () GS:9e2c3bc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 00022b998000 CR4: 000406f0 Call Trace: intel_lid_notify+0xca/0xd0 [i915] notifier_call_chain+0x4a/0x70 __blocking_notifier_call_chain+0x47/0x60 blocking_notifier_call_chain+0x16/0x20 acpi_lid_notify_state+0xee/0x142 [button] acpi_lid_update_state+0x24/0x27 [button] acpi_button_notify+0x3d/0x130 [button] acpi_device_notify+0x19/0x1b acpi_ev_notify_dispatch+0x49/0x61 acpi_os_execute_deferred+0x14/0x20 process_one_work+0x193/0x470 worker_thread+0x4e/0x490 kthread+0x101/0x140 ? process_one_work+0x470/0x470 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x25/0x30 Code: e8 d7 aa 2c d6 8b 45 a4 89 c1 31 f6 48 c7 c2 c0 11 50 c0 48 c7 c7 e5 10 51 c0 e8 6d a3 de ff 48 c7 c0 70 a6 27 c0 48 85 c0 74 56 41 83 6d 00 01 75 08 4c 89 ef e8 01 b9 df ff 48 83 c4 40 5b RIP: intel_display_resume+0xaf/0x120 [i915] RSP: becbcc85fc70 CR2: ---[ end trace d496ba830778c097 ]--- The machine is running fine afterwards but never again receiving a lid close / open event. 4.9 is good. I tried to bisect it and landed at 0853695c3ba46f97dfc0b5885f7b7e640ca212dd Author: Chris Wilson Date: Fri Oct 14 13:18:18 2016 +0100 drm: Add reference counting to drm_atomic_state However, during bisecting the failure got worse (the machine locked up hard during lid close/open, with lots of recursive faults), so I doubt this is the commit to revert, but apparently it still needs some more fixes. Thanks, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Re: [PATCH] drivers: staging: rtl8188eu: include: wifi: Unnecessary do-while removed from macro
On Sun, Jan 15, 2017 at 01:08:15AM +0530, Kartikey Singh wrote:
> On Sat, Jan 14, 2017 at 07:38:01PM +0100, Greg KH wrote:
> > On Sat, Jan 14, 2017 at 11:53:36PM +0530, Kartikey Singh wrote:
> > > do while loop removed from single statement macro
> > >
> > > Signed-off-by: Kartikey Singh
> > > ---
> > > drivers/staging/rtl8188eu/include/wifi.h | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/staging/rtl8188eu/include/wifi.h
> > > b/drivers/staging/rtl8188eu/include/wifi.h
> > > index 9e08e68..57db709 100644
> > > --- a/drivers/staging/rtl8188eu/include/wifi.h
> > > +++ b/drivers/staging/rtl8188eu/include/wifi.h
> > > @@ -481,9 +481,7 @@ static inline int IsFrameTypeCtrl(unsigned char
> > > *pframe)
> > >
> > > --*/
> > >
> > > #define SetOrderBit(pbuf)\
> > > - do { \
> > > - *(unsigned short *)(pbuf) |= cpu_to_le16(_ORDER_); \
> > > - } while (0)
> > > + (*(unsigned short *)(pbuf) |= cpu_to_le16(_ORDER_))
> >
> > This macro is never used, so it could just be removed, right?
> >
> > > #define GetOrderBit(pbuf)\
> > > (((*(unsigned short *)(pbuf)) & le16_to_cpu(_ORDER_)) != 0)
> >
> > Same with that one. Care to do that type of fixup instead please?
> >
> > thanks,
> >
> > greg k-h
> I think that macro is needed.
I don't see it being used anywhere, do you?
Re: [PATCH] drivers: staging: rtl8188eu: include: wifi: Unnecessary do-while removed from macro
On Sat, Jan 14, 2017 at 10:53:04PM +0300, Ivan Safonov wrote: > On 01/14/2017 10:40 PM, Greg KH wrote: > > On Sun, Jan 15, 2017 at 12:44:41AM +0530, Kartikey singh wrote: > > Even better yet, remove it and rebuild the driver and see if it > > breaks :) > > Only if the code is not between #ifn?def / #endif... Heh, fair enough, but it usually is a good sign if you do a build, along with a search, that you are safe to remove something. thanks, greg k-h
Re: [PATCH] drivers: staging: rtl8188eu: include: Removed unnecssary defined macros
On Sun, Jan 15, 2017 at 01:09:23PM +0530, Kartikey Singh wrote:
> Removed macros not in use.
>
> Signed-off-by: Kartikey Singh
> ---
> drivers/staging/rtl8188eu/include/wifi.h | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/include/wifi.h
> b/drivers/staging/rtl8188eu/include/wifi.h
> index 9e08e68..9c9c334 100644
> --- a/drivers/staging/rtl8188eu/include/wifi.h
> +++ b/drivers/staging/rtl8188eu/include/wifi.h
> @@ -480,15 +480,6 @@ static inline int IsFrameTypeCtrl(unsigned char *pframe)
> Below is the definition for 802.11n
>
> --*/
>
> -#define SetOrderBit(pbuf)\
> - do { \
> - *(unsigned short *)(pbuf) |= cpu_to_le16(_ORDER_); \
> - } while (0)
> -
> -#define GetOrderBit(pbuf)\
> - (((*(unsigned short *)(pbuf)) & le16_to_cpu(_ORDER_)) != 0)
> -
> -
That's good, but:
> /**
> * struct rtw_ieee80211_bar - HT Block Ack Request
> *
> @@ -758,6 +749,8 @@ enum ht_cap_ampdu_factor {
> #define P2P_STATUS_FAIL_USER_REJECT 0x0B
>
> /* Value of Invitation Flags Attribute */
> +
> +/*
> #define P2P_INVITATION_FLAGS_PERSISTENT BIT(0)
>
> #define DMP_P2P_DEVCAP_SUPPORT (P2P_DEVCAP_SERVICE_DISCOVERY | \
> @@ -766,6 +759,7 @@ enum ht_cap_ampdu_factor {
> P2P_DEVCAP_INVITATION_PROC)
>
> #define DMP_P2P_GRPCAP_SUPPORT (P2P_GRPCAP_INTRABSS)
> +*/
Why did you comment these out and not just remove them?
No need keeping around useless stuff, right?
thanks,
greg k-h
Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer
On Sun, Jan 15, 2017 at 07:19:03AM +, Winkler, Tomas wrote: > > Subject: Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only > > for SPT > > and newer > > > > On Sat, Jan 14, 2017 at 08:27:31PM +0100, Paul Menzel wrote: > > > Dear Greg, > > > > > > > > > On 2017-01-13 14:00, Greg Kroah-Hartman wrote: > > > > On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel wrote: > > > > > > > > On 01/11/17 15:12, Winkler, Tomas wrote: > > > > > > > > > > > > > On 01/11/17 10:24, Winkler, Tomas wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler > > wrote: > > > > > > > > > > > On older platforms the command should be just ignored > > > > > > > > > > > by the firmware but some older platforms misbehave so > > > > > > > > > > > it's safer to send the command only if required. > > > > > > > > > > > > > > > > > > > > Thanks! This fixes suspend-to-ram for me (on a Thinkpad > > > > > > > > > > x201s). > > > > > > > > > > > > > > > > > > What about Dell XPS13? > > > > > > > > > > > > > > > > With Linus' master branch from today, and Greg's > > > > > > > > char-misc-linus merged > > > > > > > > (Merge: 807b93e995d1 546cf3ef9c92), the regression is still > > > > > > > > there. > > > > > > > > > > > > > > Hmm, this should work on KBL > > > > > > > > > > > > > > > I am now building a Linux kernel image with the two commits > > > > > > > > touching > > > > > > > > `bus- fixup.c` reverted. > > > > > > > > > > > > > > Thanks for the effort. > > > > > > > > > > > > > > > Do you want me to open a separate bug report for that, or > > > > > > > > continue debugging in the existing report [1], which is > > > > > > > > currently > > marked as resolved? > > > > > > > > > > > > > > Let's get some more data, shouldn't take long time. > > > > > > > > > > > > > > > > Do you have Kaby Lake devices sitting around for testing? > > > > > > > > > > > > > > We will of course try to reproduce the issue locally. > > > > > > > > > > > > Paul, currently we cannot reproduce this issue on Kaby Lake > > > > > > platforms on our side, > > > > > > > > > > It looks like it’s a different issue. Reverting the two commits > > > > > touching `bus-fixup.c`, did not help. > > > > > > > > > > > we would be great for more debug data from your side. > > > > > > You can get more info by enabling mode debug logs > > > > > > > > > > > > echo -n 'module mei +lfp' > > > > > > > /sys/kernel/debug/dynamic_debug/control > > > > > > echo -n 'module mei_me +lfp' > > > > > > > /sys/kernel/debug/dynamic_debug/control > > > > > > > > > > I am currently bisecting to find the culprit. 13 steps will take > > > > > some time though. > > > > > > > > I can duplicate this on my laptop here as well :( > > > > > > Which system do you have? > > > > A Dell XPS13, don't know what cpu type it is, here's the output of one cpu > > from > > /proc/cpuinfo > > > > processor : 3 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 78 > > model name : Intel(R) Core(TM) i7-6560U CPU @ 2.20GHz > > stepping: 3 > > microcode : 0x8a > > cpu MHz : 712.207 > > cache size : 4096 KB > > physical id : 0 > > siblings: 4 > > core id : 1 > > cpu cores : 2 > > apicid : 3 > > initial apicid : 3 > > fpu : yes > > fpu_exception : yes > > cpuid level : 22 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > > mca > > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx > > pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl > > xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor > > ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic > > movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm > > 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase > > tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt > > xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify > > hwp_act_window hwp_epp > > bugs: > > bogomips: 4419.34 > > clflush size: 64 > > cache_alignment : 64 > > address sizes : 39 bits physical, 48 bits virtual > > power management: > > > > > > Did you get anywhere with your bisection? > > > > > > Sorry, I replied to a different message with my status. > > > > > > Please see my status below. I’ll have access to the machine on Monday > > again. > > > > > > ``` > > > $ git bisect log > > > git bisect start > > > # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9 git > > > bisect good 69973b830859bc6529a7a0468ba0d80ee5117826 > > > # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9 git > > > bisect good 69973b830859bc6529a7a0468ba0d80ee5117826 > > > # bad: [a121103c922847ba5010819a3f250f1f7fc84ab8] Linux 4.10-rc3 git > > > bisect bad a121103c922847ba5010819a3f250f1f7fc84ab8 > > >
[PATCH] tty: serial: constify dev_pm_ops structures
Declare dev_pm_ops structures as const as they are only stored in the pm
field of a device_driver structure. This field is of type const, so
dev_pm_ops structures having similar properties can be declared const
too.
Size details after cross compiling the .o file for blackfin architecture.
File size before:
text data bss dec hex filename
3572 320 163908 f44 tty/serial/bfin_sport_uart.o
File size after:
textdata bss dec hex filename
3664 228 163908 f44 tty/serial/bfin_sport_uart.o
Signed-off-by: Bhumika Goyal
---
drivers/tty/serial/bfin_sport_uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/bfin_sport_uart.c
b/drivers/tty/serial/bfin_sport_uart.c
index 984e1c0..6b03fb1 100644
--- a/drivers/tty/serial/bfin_sport_uart.c
+++ b/drivers/tty/serial/bfin_sport_uart.c
@@ -740,7 +740,7 @@ static int sport_uart_resume(struct device *dev)
return 0;
}
-static struct dev_pm_ops bfin_sport_uart_dev_pm_ops = {
+static const struct dev_pm_ops bfin_sport_uart_dev_pm_ops = {
.suspend= sport_uart_suspend,
.resume = sport_uart_resume,
};
--
1.9.1
Bluetooth: always-true condition in dtl1_confcheck
Hello,
Since commit 00990e7ce0b0 ("pcmcia: use autoconfiguration feature for
ioports and iomem") function dtl1_confcheck() starts with the following
statements (in drivers/bluetooth/dtl1_cs.c):
static int dtl1_confcheck(struct pcmcia_device *p_dev, void *priv_data)
{
if ((p_dev->resource[1]->end) || (p_dev->resource[1]->end < 8))
return -ENODEV;
The condition in the if statement is always true and the compiler
reports an issue when building with -Wlogical-op. What was the condition
supposed to be?
Thanks,
Nicolas
Re: [PATCH net-next v3 05/10] drivers: base: Add device_find_class()
On Sat, Jan 14, 2017 at 01:47:08PM -0800, Florian Fainelli wrote:
> Add a helper function to lookup a device reference given a class name.
> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
> make it more generic.
>
> Signed-off-by: Florian Fainelli
> ---
> drivers/base/core.c| 19 +++
> include/linux/device.h | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 020ea7f05520..3dd6047c10d8 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2065,6 +2065,25 @@ struct device *device_find_child(struct device
> *parent, void *data,
> }
> EXPORT_SYMBOL_GPL(device_find_child);
>
> +static int dev_is_class(struct device *dev, void *class)
> +{
> + if (dev->class != NULL && !strcmp(dev->class->name, class))
> + return 1;
> +
> + return 0;
> +}
> +
> +struct device *device_find_class(struct device *parent, char *class)
Why are you using the char * for a class, and not just a pointer to
"struct class"? That seems to be the most logical one, no need to rely
on string comparisons here.
Also, what is this being used for? You aren't trying to walk up the
device heirachy to find a specific "type" of device, are you? If so,
ugh, I ranted about this in the past when the hyperv driver was trying
to do such a thing...
> +{
> + if (dev_is_class(parent, class)) {
> + get_device(parent);
> + return parent;
> + }
> +
> + return device_find_child(parent, class, dev_is_class);
You are trying to find a peer device with the same parent that belongs
to a specific class?
Again, what is this being used for?
And all exported driver core functions should have full kerneldoc
information for them so that people know how to use them, and what the
constraints are (see device_find_child() as an example.) Please do that
here as well because you are returning a pointer to a structure with the
reference count incremented, callers need to know that.
thanks,
greg k-h
Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
On Sat, Jan 14, 2017 at 01:47:09PM -0800, Florian Fainelli wrote:
> Now that the base device driver code provides an identical
> implementation of dev_find_class() utilize device_find_class() instead
> of our own version of it.
>
> Signed-off-by: Florian Fainelli
> ---
> net/dsa/dsa.c | 22 ++
> 1 file changed, 2 insertions(+), 20 deletions(-)
>
> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> index 2306d1b87c83..77fa4c4f5828 100644
> --- a/net/dsa/dsa.c
> +++ b/net/dsa/dsa.c
> @@ -455,29 +455,11 @@ EXPORT_SYMBOL_GPL(dsa_switch_resume);
> #endif
>
> /* platform driver init and cleanup
> */
> -static int dev_is_class(struct device *dev, void *class)
> -{
> - if (dev->class != NULL && !strcmp(dev->class->name, class))
> - return 1;
> -
> - return 0;
> -}
> -
> -static struct device *dev_find_class(struct device *parent, char *class)
> -{
> - if (dev_is_class(parent, class)) {
> - get_device(parent);
> - return parent;
> - }
> -
> - return device_find_child(parent, class, dev_is_class);
> -}
> -
> struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev)
> {
> struct device *d;
>
> - d = dev_find_class(dev, "mdio_bus");
> + d = device_find_class(dev, "mdio_bus");
> if (d != NULL) {
> struct mii_bus *bus;
You want a peer of your device on a specific class? What is this for?
> @@ -495,7 +477,7 @@ static struct net_device *dev_to_net_device(struct device
> *dev)
> {
> struct device *d;
>
> - d = dev_find_class(dev, "net");
> + d = device_find_class(dev, "net");
> if (d != NULL) {
> struct net_device *nd;
Again, huh? What is the device heirachy here that is so odd that this
type of function is needed?
totally confused,
greg k-h
Re: [PATCH net-next v3 07/10] net: Relocate dev_to_net_device() into core
On Sat, Jan 14, 2017 at 01:47:10PM -0800, Florian Fainelli wrote:
> dev_to_net_device() is moved from net/dsa/dsa.c to net/core/dev.c since
> it going to be used by net/dsa/dsa2.c and the namespace of the function
> justifies making it available to other users potentially.
>
> Signed-off-by: Florian Fainelli
> ---
> include/linux/netdevice.h | 2 ++
> net/core/dev.c| 19 +++
> net/dsa/dsa.c | 18 --
> 3 files changed, 21 insertions(+), 18 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 97ae0ac513ee..6d021c37b774 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -4390,4 +4390,6 @@ do {
> \
> #define PTYPE_HASH_SIZE (16)
> #define PTYPE_HASH_MASK (PTYPE_HASH_SIZE - 1)
>
> +struct net_device *dev_to_net_device(struct device *dev);
> +
> #endif /* _LINUX_NETDEVICE_H */
> diff --git a/net/core/dev.c b/net/core/dev.c
> index ad5959e56116..7547e2ccc06b 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -8128,6 +8128,25 @@ const char *netdev_drivername(const struct net_device
> *dev)
> return empty;
> }
>
> +struct net_device *dev_to_net_device(struct device *dev)
> +{
> + struct device *d;
> +
> + d = device_find_class(dev, "net");
> + if (d) {
> + struct net_device *nd;
> +
> + nd = to_net_dev(d);
> + dev_hold(nd);
> + put_device(d);
> +
> + return nd;
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(dev_to_net_device);
This really isn't just a "struct device to net device cast" type
function, (otherwise a simple container_of() would work). You are
walking the device tree and assuming it is in a specific order so that
this function works. You better document the hell out of this,
otherwise people are going to try to use this and get very confused,
very quickly...
thanks,
greg k-h
Re: [PATCH net-next v3 00/10] net: dsa: Support for pdata in dsa2
On Sat, Jan 14, 2017 at 01:47:03PM -0800, Florian Fainelli wrote: > Hi all, > > This is not exactly new, and was sent before, although back then, I did not > have an user of the pre-declared MDIO board information, but now we do. Note > that I have additional changes queued up to have b53 register platform data > for > MIPS bcm47xx and bcm63xx. > > Yes I know that we should have the Orion platforms eventually be converted to > Device Tree, but until that happens, I don't want any remaining users of the > old "dsa" platform device (hence the previous DTS submissions for ARM/mvebu) > and, there will be platforms out there that most likely won't never see DT > coming their way (BCM47xx is almost 100% sure, BCM63xx maybe not in a distant > future). > > We would probably want the whole series to be merged via David Miller's tree > to simplify things. > > Greg, can you Ack/Nack patch 5 since it touched the core LDD? I've NAKed them for now, you need to describe what you are trying to do here, as it doesn't make any sense to me at the moment. thanks, greg k-h
aacraid: kernel: AAC: Host adapter dead -1 (bisected)
Hi. There is a bug with handling of adaptec raid cards (in my case it is Adaptec 3405) where kernel logs hundreds of "AAC: Host adapter dead -1" messages. Bug was reported previously on lkml but there was no progres in solving it. There is also bugzilla entry: https://bugzilla.kernel.org/show_bug.cgi?id=151661 I've bisected that to commit bellow and indeed, reverting it from kernel 4.9.3 makes messages go away. Could anyone at microsemi look at this regression? Thanks commit 78cbccd3bd683c295a44af8050797dc4a41376ff Author: Raghava Aditya Renukunta Date: Mon Apr 25 23:32:37 2016 -0700 aacraid: Fix for KDUMP driver hang When KDUMP is triggered the driver first talks to the firmware in INTX mode, but the adapter firmware is still in MSIX mode. Therefore the first driver command hangs since the driver is waiting for an INTX response and firmware gives a MSIX response. If when the OS is installed on a RAID drive created by the adapter KDUMP will hang since the driver does not receive a response in sync mode. Fixed by: Change the firmware to INTX mode if it is in MSIX mode before sending the first sync command. Cc: sta...@vger.kernel.org Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen my hardware: 02:0e.0 RAID bus controller [0104]: Adaptec AAC-RAID [9005:0285] Subsystem: Adaptec 3405 [9005:02bb] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-
[PATCH] Input: cyapa_gen3: use msleep() for long delay
ulseep_range() uses hrtimers and provides no advantage over msleep() for larger delays. Fix up the 50ms delays here to use msleep() and reduce the load on the hrtimer subsystem. Signed-off-by: Nicholas Mc Guire --- Problem found by coccinelle script As the needed delay is specified in the comment as being "at least 50ms" the msleep(50) should be fine here. Note that cyapa_gen3_bl_exit() is returning -EAGAIN in cases where it was not yet ready to process the request, but the calling side cyapa_gen3_do_operational_check() does not check for -EAGAIN so in case of the noted increased delay "...can take up to an additional 2 seconds. If the device power is running low, this may take even longer", maybe cyapa_gen3_do_operational_check() may need a retry loop on -EAGAIN ? Patch was compile tested with: x86_64_defconfig + CONFIG_MOUSE_CYAPA=m Patch is against 4.10-rc3 (localversion-next is next-20170113) drivers/input/mouse/cyapa_gen3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c index f9600753..6e9ecb0 100644 --- a/drivers/input/mouse/cyapa_gen3.c +++ b/drivers/input/mouse/cyapa_gen3.c @@ -562,7 +562,7 @@ static int cyapa_gen3_bl_exit(struct cyapa *cyapa) * Wait for bootloader to exit, and operation mode to start. * Normally, this takes at least 50 ms. */ - usleep_range(5, 10); + msleep(50); /* * In addition, when a device boots for the first time after being * updated to new firmware, it must first calibrate its sensors, which -- 2.1.4
[PATCH RFC V2] Input: cyapa: use time based retry loop
Using counter based retry loops for peripherals results in the delay
being significantly overrun during high-load situations where delay
functions tend to be vary imprecise and overrun there timeouts. So
condition the termination on the actual condition of 2s for the
re-calibration to have been successful.
As this is a very long delay there is no advantage in using
high-resolution timers thus switching this to msleep().
Signed-off-by: Nicholas Mc Guire
---
V2: The maximum recalibration timeout should have been 2 * HZ as
Dmitry Torokhov noted - V2 sets
the timeout boundary to 2s now.
Problem detected with coccinelle script (usleep_range for long delay)
The basic model for the fix up here is to use
timeout = jiffies + (retry_time)
do {
check()
mleep()
} while (time_is_after_jiffies(timeout));
rather than using a counter and have very long retry loops under load
conditions. In the specific case it is sleep()/check() though to wait
on the previous write to complete. The initial intent was to move the
usleep_range() to msleep() as the delays are very long - if this
refactoring of the timeout loop is desirable or not is not clear (both
time and count based models seem to be common).
Patch was compile tested with: x86_64_defconfig + CONFIG_MOUSE_CYAPA=m
Patch is against 4.10-rc3 (localversion-next is next-20170113)
drivers/input/mouse/cyapa_gen3.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index f9600753..0c544de 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -789,7 +789,7 @@ static ssize_t cyapa_gen3_do_calibrate(struct device *dev,
const char *buf, size_t count)
{
struct cyapa *cyapa = dev_get_drvdata(dev);
- int tries;
+ unsigned long timeout;
int ret;
ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
@@ -812,31 +812,28 @@ static ssize_t cyapa_gen3_do_calibrate(struct device *dev,
goto out;
}
- tries = 20; /* max recalibration timeout 2s. */
+ /* max recalibration timeout 2s. */
+ timeout = jiffies + 2 * HZ;
do {
/*
* For this recalibration, the max time will not exceed 2s.
* The average time is approximately 500 - 700 ms, and we
* will check the status every 100 - 200ms.
*/
- usleep_range(10, 20);
-
+ msleep(100);
ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
if (ret < 0) {
- dev_err(dev, "Error reading dev status: %d\n",
- ret);
+ dev_err(dev, "Error reading dev status: %d\n", ret);
goto out;
}
- if ((ret & CYAPA_DEV_NORMAL) == CYAPA_DEV_NORMAL)
- break;
- } while (--tries);
+ if ((ret & CYAPA_DEV_NORMAL) == CYAPA_DEV_NORMAL) {
+ dev_dbg(dev, "Calibration successful.\n");
+ goto out;
+ }
+ } while (time_is_after_jiffies(timeout));
- if (tries == 0) {
- dev_err(dev, "Failed to calibrate. Timeout.\n");
- ret = -ETIMEDOUT;
- goto out;
- }
- dev_dbg(dev, "Calibration successful.\n");
+ dev_err(dev, "Failed to calibrate. Timeout.\n");
+ ret = -ETIMEDOUT;
out:
return ret < 0 ? ret : count;
--
2.1.4
Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM
Hi,
On Sat, Jan 07, 2017 at 10:43:39PM +0530, Afzal Mohammed wrote:
> On Tue, Dec 13, 2016 at 10:02:26AM +, Russell King - ARM Linux wrote:
> > Also, if the region setup for the vectors was moved as well, it would
> > then be possible to check the ID registers to determine whether this
> > is supported, and make the decision where to locate the vectors base
> > more dynamically.
>
> This would affect Cortex-R's, which is a bit concerning due to lack of
> those platforms with me, let me try to get it right.
QEMU too doesn't seem to provide a Cortex-R target
> Seems translating __setup_mpu() altogether to C
afaics, a kind of C translation is already present as
mpu_setup_region() in arch/arm/mm/nommu.c that takes care of
MPU_RAM_REGION only. And that seems to be a kind of redundant as it is
also done in asm at __setup_mpu(). Git blames asm & C to consecutive
commits, that makes me a little shaky about the conclusion on it being
redundant.
> & installing at a later, but suitable place might be better.
But looks like enabling MPU can't be moved to C & that would
necessitate keeping at least some portion of__setu_mpu() in asm.
Instead, moving region setup only for vectors to C as Russell
suggested at first would have to be done.
A kind of diff at the end is in my mind, with additional changes to
handle the similar during secondary cpu bringup too.
Thinking of invoking mpu_setup() from secondary_start_kernel() in
arch/arm/kernel/smp.c, with mpu_setup() being slightly modified to
avoid storing region details again when invoked by secondary cpu's.
Vladimir, once changes are done after a revisit, i would need your
help to test on Cortex-R.
As an aside, wasn't aware of the fact that Cortex-R supports SMP
Linux, had thought that, of !MMU one's, only Blackfin & J2 had it.
> Also !MMU Kernel could boot on 3 ARM v7-A platforms - AM335x Beagle
> Bone (A8), AM437x IDK (A9) & Vybrid VF610 (on A5 core, note that it
> has M4 core too)
Talking about Cortex-M, AMx3's too have it, to be specific M3, but
they are not Linux-able unlike the one in VF610.
Regards
afzal
--->8---
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index e0565d73e49e..f8ac79b6136d 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -249,20 +249,6 @@ ENTRY(__setup_mpu)
setup_region r0, r5, r6, MPU_INSTR_SIDE @ 0x0, BG region, enabled
2: isb
- /* Vectors region */
- set_region_nr r0, #MPU_VECTORS_REGION
- isb
- /* Shared, inaccessible to PL0, rw PL1 */
- mov r0, #CONFIG_VECTORS_BASE@ Cover from VECTORS_BASE
- ldr r5,=(MPU_AP_PL1RW_PL0NA | MPU_RGN_NORMAL)
- /* Writing N to bits 5:1 (RSR_SZ) --> region size 2^N+1 */
- mov r6, #(((2 * PAGE_SHIFT - 1) << MPU_RSR_SZ) | 1 << MPU_RSR_EN)
-
- setup_region r0, r5, r6, MPU_DATA_SIDE @ VECTORS_BASE, PL0 NA, enabled
- beq 3f @ Memory-map not unified
- setup_region r0, r5, r6, MPU_INSTR_SIDE @ VECTORS_BASE, PL0 NA, enabled
-3: isb
-
/* Enable the MPU */
mrc p15, 0, r0, c1, c0, 0 @ Read SCTLR
bic r0, r0, #CR_BR @ Disable the 'default mem-map'
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index e82056df0635..7fe8906322d5 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -269,12 +269,19 @@ void __init mpu_setup(void)
ilog2(memblock.memory.regions[0].size),
MPU_AP_PL1RW_PL0RW | MPU_RGN_NORMAL);
if (region_err) {
- panic("MPU region initialization failure! %d", region_err);
+ panic("MPU RAM region initialization failure! %d", region_err);
} else {
- pr_info("Using ARMv7 PMSA Compliant MPU. "
-"Region independence: %s, Max regions: %d\n",
- mpu_iside_independent() ? "Yes" : "No",
- mpu_max_regions());
+ region_err = mpu_setup_region(MPU_VECTORS_REGION, vectors_base,
+ ilog2(memblock.memory.regions[0].size),
+ MPU_AP_PL1RW_PL0NA | MPU_RGN_NORMAL);
+ if (region_err) {
+ panic("MPU VECTOR region initialization failure! %d",
+ region_err);
+ } else {
+ pr_info("Using ARMv7 PMSA Compliant MPU. "
+ "Region independence: %s, Max regions: %d\n",
+ mpu_iside_independent() ? "Yes" : "No",
+ mpu_max_regions());
}
}
#else
[PATCH] usb: host: constify dev_pm_ops structures
Declare dev_pm_ops structures as const as they are only stored in the pm
field of a device_driver structure. This field is of type const, so
dev_pm_ops structures having similar properties can be declared const
too.
Size details after cross compiling the .o file for powerpc
architecture.
File size before:
textdata bss dec hex filename
3183 372 03555 de3 drivers/usb/host/ehci-fsl.o
File size after:
textdata bss dec hex filename
3275 280 03555 de3 drivers/usb/host/ehci-fsl.o
Signed-off-by: Bhumika Goyal
---
drivers/usb/host/ehci-fsl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 91701cc..3733aab 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -600,7 +600,7 @@ static int ehci_fsl_drv_restore(struct device *dev)
return 0;
}
-static struct dev_pm_ops ehci_fsl_pm_ops = {
+static const struct dev_pm_ops ehci_fsl_pm_ops = {
.suspend = ehci_fsl_drv_suspend,
.resume = ehci_fsl_drv_resume,
.restore = ehci_fsl_drv_restore,
--
1.9.1
[PATCH] drivers: staging: rtl8188eu: include: wifi: Removed unnecessary defined macros
Removed macros not in use.
Signed-off-by: Kartikey Singh
---
drivers/staging/rtl8188eu/include/wifi.h | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/wifi.h
b/drivers/staging/rtl8188eu/include/wifi.h
index 9e08e68..e10de68 100644
--- a/drivers/staging/rtl8188eu/include/wifi.h
+++ b/drivers/staging/rtl8188eu/include/wifi.h
@@ -480,15 +480,6 @@ static inline int IsFrameTypeCtrl(unsigned char *pframe)
Below is the definition for 802.11n
--*/
-#define SetOrderBit(pbuf) \
- do { \
- *(unsigned short *)(pbuf) |= cpu_to_le16(_ORDER_); \
- } while (0)
-
-#define GetOrderBit(pbuf) \
- (((*(unsigned short *)(pbuf)) & le16_to_cpu(_ORDER_)) != 0)
-
-
/**
* struct rtw_ieee80211_bar - HT Block Ack Request
*
@@ -758,14 +749,6 @@ enum ht_cap_ampdu_factor {
#defineP2P_STATUS_FAIL_USER_REJECT 0x0B
/* Value of Invitation Flags Attribute */
-#defineP2P_INVITATION_FLAGS_PERSISTENT BIT(0)
-
-#defineDMP_P2P_DEVCAP_SUPPORT (P2P_DEVCAP_SERVICE_DISCOVERY | \
- P2P_DEVCAP_CLIENT_DISCOVERABILITY | \
- P2P_DEVCAP_CONCURRENT_OPERATION | \
- P2P_DEVCAP_INVITATION_PROC)
-
-#defineDMP_P2P_GRPCAP_SUPPORT (P2P_GRPCAP_INTRABSS)
/* Value of Device Capability Bitmap */
#defineP2P_DEVCAP_SERVICE_DISCOVERYBIT(0)
--
2.9.3
qla3xxx: u32 constant overflow in fm93c56a_select()
Hello, In drivers/net/ethernet/qlogic/qla3xxx.c, fm93c56a_select() currently calls: ql_write_nvram_reg(qdev, spir, ((ISP_NVRAM_MASK << 16) | qdev->eeprom_cmd_data)); and ISP_NVRAM_MASK is defined as (0x000F << 16). ql_write_nvram_reg() writes a 32-bit value but (ISP_NVRAM_MASK << 16) expands to ((0x000F << 16) << 16) = 0xF << 32, which overflows the u32 type. This means the above call is equivalent to: ql_write_nvram_reg(qdev, spir, qdev->eeprom_cmd_data); Is this something normal, in which case (ISP_NVRAM_MASK << 16) would be removed, or a bug? Thanks, Nicolas
[PULL REQUEST] i2c for 4.10
Linus, here is a pull request with bugfixes for I2C. Mostly core this time which is a bit unusual but nothing really scary in there. Also, this is the first public test run of my git-request-pull enhancement to give credits to people taking part in quality assurance (like reviewing and testing). I think we are lacking in this department and this is my take on fixing it. I'll post about it on LKML seperately later today. Please pull. Thanks, Wolfram The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux 4.10-rc3 (2017-01-08 14:18:17 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to 701dc207bf551d9fe6defa36e84a911e880398c3: i2c: piix4: Avoid race conditions with IMC (2017-01-12 20:52:12 +0100) Colin Ian King (1): i2c: fix spelling mistake: "insufficent" -> "insufficient" Dmitry Torokhov (1): i2c: do not enable fall back to Host Notify by default John Garry (1): i2c: print correct device invalid address Ricardo Ribalda Delgado (1): i2c: piix4: Avoid race conditions with IMC Vlad Tsyrklevich (1): i2c: fix kernel memory disclosure in dev interface with much appreciated quality assurance from Andy Shevchenko (1): (Rev.) i2c: piix4: Avoid race conditions with IMC Benjamin Tissoires (1): (Test) i2c: do not enable fall back to Host Notify by default Vladimir Zapolskiy (1): (Rev.) i2c: print correct device invalid address Documentation/devicetree/bindings/i2c/i2c.txt | 8 drivers/i2c/busses/i2c-piix4.c| 22 ++ drivers/i2c/i2c-core.c| 21 ++--- drivers/i2c/i2c-dev.c | 2 +- include/linux/i2c.h | 1 + 5 files changed, 42 insertions(+), 12 deletions(-)
Re: [PATCH v9 3/3] iio: adc: add support for Allwinner SoCs ADC
On 12/13/2016 03:33 PM, Quentin Schulz wrote: > + indio_dev->name = dev_name(&pdev->dev); The name is supposed to be the type of the device, e.g. part name, not the name of parent device instance. This could e.g. come from a name field in the gpadc_data struct.
Re: [PATCH v2 2/2] iio: distance: srf08: add IIO driver for us ranger
On 01/10/2017 07:48 PM, Andreas Klinger wrote: [...] > + indio_dev->name = dev_name(&client->dev); The name is supposed to be the type of the device, e.g. part name, not the name of parent device instance. E.g. "srf08" in this case.
[PATCH 1/1] crypto: img-hash - use dma_data_direction when calling dma_map_sg
The fourth argument of dma_map_sg() and dma_unmap_sg() is an item of
dma_data_direction enum. Function img_hash_xmit_dma() wrongly used
DMA_MEM_TO_DEV, which is an item of dma_transfer_direction enum.
Replace DMA_MEM_TO_DEV (which value is 1) with DMA_TO_DEVICE (which
value is fortunately also 1) when calling dma_map_sg() and
dma_unmap_sg().
Signed-off-by: Nicolas Iooss
---
drivers/crypto/img-hash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c
index a2e77b87485b..9b07f3d88feb 100644
--- a/drivers/crypto/img-hash.c
+++ b/drivers/crypto/img-hash.c
@@ -226,7 +226,7 @@ static int img_hash_xmit_dma(struct img_hash_dev *hdev,
struct scatterlist *sg)
struct dma_async_tx_descriptor *desc;
struct img_hash_request_ctx *ctx = ahash_request_ctx(hdev->req);
- ctx->dma_ct = dma_map_sg(hdev->dev, sg, 1, DMA_MEM_TO_DEV);
+ ctx->dma_ct = dma_map_sg(hdev->dev, sg, 1, DMA_TO_DEVICE);
if (ctx->dma_ct == 0) {
dev_err(hdev->dev, "Invalid DMA sg\n");
hdev->err = -EINVAL;
@@ -241,7 +241,7 @@ static int img_hash_xmit_dma(struct img_hash_dev *hdev,
struct scatterlist *sg)
if (!desc) {
dev_err(hdev->dev, "Null DMA descriptor\n");
hdev->err = -EINVAL;
- dma_unmap_sg(hdev->dev, sg, 1, DMA_MEM_TO_DEV);
+ dma_unmap_sg(hdev->dev, sg, 1, DMA_TO_DEVICE);
return -EINVAL;
}
desc->callback = img_hash_dma_callback;
--
2.11.0
[GIT PULL] TTY/Serial driver changes for 4.10-rc4
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux 4.10-rc3 (2017-01-08 14:18:17 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-4.10-rc4 for you to fetch changes up to 802c03881f29844af0252b6e22be5d2f65f93fd0: sysrq: attach sysrq handler correctly for 32-bit kernel (2017-01-11 09:22:54 +0100) TTY/serial fixes for 4.10-rc4 Here are some small tty/serial driver fixes for 4.10-rc4 to resolve a number of reported issues. Nothing major here at all, one revert of a problematic patch, and some other tiny bugfixes. Full details are in the shortlog below. All have been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Akinobu Mita (1): sysrq: attach sysrq handler correctly for 32-bit kernel Daniel Jedrychowski (1): Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break Gabriel Krisman Bertazi (1): 8250_pci: Fix potential use-after-free in error path Herbert Xu (1): Revert "tty: serial: 8250: add CON_CONSDEV to flags" Richard Genoud (2): tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx tty/serial: atmel: RS485 half duplex w/DMA: enable RX after TX is done drivers/tty/serial/8250/8250_core.c | 2 +- drivers/tty/serial/8250/8250_pci.c | 12 +--- drivers/tty/serial/8250/8250_port.c | 2 +- drivers/tty/serial/atmel_serial.c | 22 -- drivers/tty/sysrq.c | 4 ++-- 5 files changed, 25 insertions(+), 17 deletions(-)
[GIT PULL] USB driver fixes for 4.10-rc4
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux 4.10-rc3 (2017-01-08 14:18:17 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.10-rc4 for you to fetch changes up to 97f9c5f211d1f063b1745370e6b4fd64d6adaeff: Merge tag 'usb-serial-4.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus (2017-01-12 18:17:38 +0100) USB fixes for 4.10-rc4 Here are a few small USB driver fixes for 4.10-rc4 to resolve some reported issues. The "largest" here is a number of bugs being fixed in the ch341 usb-serial driver, to hopefully resolve the mess of different devices floating around that use this driver that have been having problems with the 4.10-rc1 release. There's also a tiny musb fix that I missed in the last pull request, as well as the traditional xhci fix rounding out the batch. All have been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Andy Lutomirski (1): wusbcore: Fix one more crypto-on-the-stack bug Bin Liu (1): usb: musb: fix runtime PM in debugfs Greg Kroah-Hartman (1): Merge tag 'usb-serial-4.10-rc4' of git://git.kernel.org/.../johan/usb-serial into usb-linus Johan Hovold (9): USB: serial: ch341: fix initial modem-control state USB: serial: ch341: fix open and resume after B0 USB: serial: ch341: fix modem-control and B0 handling USB: serial: ch341: fix open error handling USB: serial: ch341: fix resume after reset USB: serial: ch341: fix line settings after reset-resume USB: serial: ch341: fix baud rate and line-control handling USB: serial: kl5kusb105: fix line-state error handling USB: serial: ch341: fix control-message error handling Mathias Nyman (1): xhci: fix deadlock at host remove by running watchdog correctly drivers/usb/host/xhci-ring.c| 11 drivers/usb/host/xhci.c | 13 - drivers/usb/musb/musb_debugfs.c | 20 +++- drivers/usb/serial/ch341.c | 108 +++- drivers/usb/serial/kl5kusb105.c | 9 ++-- drivers/usb/wusbcore/crypto.c | 3 +- 6 files changed, 98 insertions(+), 66 deletions(-)
[GIT PULL] Driver core fixes for 4.10-rc4
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux 4.10-rc3 (2017-01-08 14:18:17 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ tags/driver-core-4.10-rc4 for you to fetch changes up to c7334ce814f7e5d8fc1f9b3126cda0640c2f81b3: Revert "driver core: Add deferred_probe attribute to devices in sysfs" (2017-01-14 14:09:03 +0100) Driver core fix for 4.10-rc4 Here is a single patch being reverted to remove a feature that was added in 4.10-rc1 that isn't quite ready for release. It will be redone as a debugfs file instead of a sysfs file in the future. Signed-off-by: Greg Kroah-Hartman Greg Kroah-Hartman (1): Revert "driver core: Add deferred_probe attribute to devices in sysfs" Documentation/ABI/testing/sysfs-devices-deferred_probe | 12 drivers/base/base.h| 2 -- drivers/base/core.c| 7 --- drivers/base/dd.c | 13 - 4 files changed, 34 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-devices-deferred_probe
[GIT PULL] Char/Misc driver fixes for 4.10-rc4
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux 4.10-rc3 (2017-01-08 14:18:17 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ tags/char-misc-4.10-rc4 for you to fetch changes up to c8a6a09c1c617402cc9254b2bc8da359a0347d75: vme: Fix wrong pointer utilization in ca91cx42_slave_get (2017-01-11 10:42:16 +0100) char/misc driver fixes for 4.10-rc4 Here are some small char/misc driver fixes for 4.10-rc4 that resolve some reported issues. The MEI driver issue resolves a lot of problems that people have been having, as does the mem driver fix. The other minor fixes resolve other reported issues. All of these have been in linux-next for a while. Signed-off-by: Greg Kroah-Hartman Alexander Usyskin (1): mei: bus: enable OS version only for SPT and newer Augusto Mecking Caringi (1): vme: Fix wrong pointer utilization in ca91cx42_slave_get Colin Ian King (1): ppdev: don't print a free'd string Pan Bian (1): extcon: return error code on failure Randy Dunlap (1): auxdisplay: fix new ht16k33 build errors Robin Murphy (1): drivers: char: mem: Fix thinkos in kmem address checks drivers/auxdisplay/Kconfig | 6 +++--- drivers/char/mem.c | 10 -- drivers/char/ppdev.c | 13 - drivers/extcon/extcon.c| 2 +- drivers/misc/mei/bus-fixup.c | 3 +++ drivers/misc/mei/debugfs.c | 2 ++ drivers/misc/mei/hbm.c | 4 drivers/misc/mei/hw.h | 6 ++ drivers/misc/mei/mei_dev.h | 2 ++ drivers/vme/bridges/vme_ca91cx42.c | 2 +- 10 files changed, 34 insertions(+), 16 deletions(-)
[PATCH 1/1] ASoC: fsl_asrc: use dma_transfer_direction enum when calling dmaengine_prep_dma_cyclic
When fsl_asrc_dma_prepare_and_submit() calls
dmaengine_prep_dma_cyclic(), it uses either DMA_TO_DEVICE or
DMA_FROM_DEVICE. These values are both items of dma_data_direction enum,
not of dma_data_direction enum, which is the type expected by
dmaengine_prep_dma_cyclic().
Replace DMA_TO_DEVICE with DMA_MEM_TO_DEV and DMA_FROM_DEVICE with
DMA_DEV_TO_MEM to fix this type mismatch issue.
Signed-off-by: Nicolas Iooss
---
sound/soc/fsl/fsl_asrc_dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c
index dc30d780f874..282d841840b1 100644
--- a/sound/soc/fsl/fsl_asrc_dma.c
+++ b/sound/soc/fsl/fsl_asrc_dma.c
@@ -76,7 +76,7 @@ static int fsl_asrc_dma_prepare_and_submit(struct
snd_pcm_substream *substream)
pair->dma_chan[!dir], runtime->dma_addr,
snd_pcm_lib_buffer_bytes(substream),
snd_pcm_lib_period_bytes(substream),
- dir == OUT ? DMA_TO_DEVICE : DMA_FROM_DEVICE, flags);
+ dir == OUT ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM, flags);
if (!pair->desc[!dir]) {
dev_err(dev, "failed to prepare slave DMA for Front-End\n");
return -ENOMEM;
--
2.11.0
[PATCH] staging: rtl8192e: rtl8192e: Remove NULL test before vfree
vfree frees the virtually continuous block of memory beginning at addr.
If addr is NULL, no operation is performed. So, NULL test is not needed
before vfree.
Signed-off-by: Shyam Saini
---
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 8a9172a..4bf7041 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -2695,10 +2695,8 @@ static void _rtl92e_pci_disconnect(struct pci_dev *pdev)
priv->polling_timer_on = 0;
_rtl92e_down(dev, true);
rtl92e_dm_deinit(dev);
- if (priv->pFirmware) {
- vfree(priv->pFirmware);
- priv->pFirmware = NULL;
- }
+ vfree(priv->pFirmware);
+ priv->pFirmware = NULL;
_rtl92e_free_rx_ring(dev);
for (i = 0; i < MAX_TX_QUEUE_COUNT; i++)
_rtl92e_free_tx_ring(dev, i);
--
2.7.4
Linux 4.4.43
I'm announcing the release of the 4.4.43 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/mach-omap2/omap-mpuss-lowpower.c |5 - arch/arm/mach-zynq/common.c |2 arch/powerpc/kernel/misc_32.S |2 drivers/hid/hid-cypress.c |3 drivers/isdn/gigaset/ser-gigaset.c|4 - drivers/net/ethernet/mellanox/mlx5/core/main.c| 10 ++ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 22 +++-- drivers/net/hyperv/netvsc_drv.c |3 drivers/net/usb/r8152.c | 80 - drivers/net/vrf.c |8 ++ drivers/spi/spi-orion.c | 83 ++ include/linux/netdevice.h |9 +- mm/page_alloc.c | 17 ++-- net/core/dev.c|4 - net/core/drop_monitor.c | 39 +++--- net/ipv4/fib_frontend.c |2 net/ipv4/fib_semantics.c |9 +- net/ipv4/igmp.c |7 + net/ipv6/ip6_offload.c|1 net/ipv6/raw.c|6 + net/sched/cls_api.c |4 - sound/firewire/tascam/tascam-stream.c |2 sound/usb/quirks.c|1 24 files changed, 236 insertions(+), 89 deletions(-) Alexander Duyck (1): ipv4: Do not allow MAIN to be alias for new LOCAL w/ custom rules Dan Carpenter (1): ser_gigaset: return -ENOMEM on error instead of success Daniel Borkmann (1): net, sched: fix soft lockup in tc_classify Dave Jones (1): ipv6: handle -EFAULT from skb_copy_bits David Ahern (3): net: vrf: Drop conntrack data after pass through VRF device on Tx net: ipv4: Fix multipath selection with vrf net: vrf: do not allow table id 0 Dennis Kadioglu (1): ALSA: usb-audio: Add a quirk for Plantronics BT600 Eli Cohen (1): net/mlx5: Avoid shadowing numa_node Eric Dumazet (1): gro: use min_t() in skb_gro_reset_offset() Florian Fainelli (1): net: stmmac: Fix race between stmmac_drv_probe and stmmac_open Greg Kroah-Hartman (2): HID: hid-cypress: validate length of report Linux 4.4.43 Herbert Xu (2): gro: Enter slow-path if there is no tailroom gro: Disable frag0 optimization on IPv6 ext headers Kyle Roeschley (1): ARM: zynq: Reserve correct amount of non-DMA RAM Larry Finger (1): powerpc: Fix build warning on 32-bit PPC Michal Tesar (1): igmp: Make igmp group member RFC 3376 compliant Noa Osherovich (1): net/mlx5: Check FW limitations on log_max_qp before setting it Oliver O'Halloran (1): mm/init: fix zone boundary creation Reiter Wolfgang (2): drop_monitor: add missing call to genlmsg_end drop_monitor: consider inserted data in genlmsg_end Takashi Sakamoto (1): ALSA: firewire-tascam: Fix to handle error from initialization of stream data Tony Lindgren (1): ARM: OMAP4+: Fix bad fallthrough for cpuidle Uwe Kleine-König (1): spi: mvebu: fix baudrate calculation for armada variant hayeswang (2): r8152: split rtl8152_suspend function r8152: fix rx issue for runtime suspend stephen hemminger (1): netvsc: reduce maximum GSO size signature.asc Description: PGP signature
Re: Linux 4.4.43
diff --git a/Makefile b/Makefile
index b8a90f9a463d..04a2186a4276 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 42
+SUBLEVEL = 43
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 65024af169d3..d3c14da7d216 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -243,10 +243,9 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
- if (IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE)) {
+ if (IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE))
save_state = 0;
- break;
- }
+ break;
default:
/*
* CPUx CSWR is invalid hardware state. Also CPUx OSWR
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 6f39d03cc27e..0a43143e9ceb 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -59,7 +59,7 @@ void __iomem *zynq_scu_base;
static void __init zynq_memory_init(void)
{
if (!__pa(PAGE_OFFSET))
- memblock_reserve(__pa(PAGE_OFFSET), __pa(swapper_pg_dir));
+ memblock_reserve(__pa(PAGE_OFFSET), 0x8);
}
static struct platform_device zynq_cpuidle_device = {
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index ed3ab509faca..df4efa304b2c 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -313,7 +313,7 @@ _GLOBAL(flush_instruction_cache)
lis r3, KERNELBASE@h
iccci 0,r3
#endif
-#elif CONFIG_FSL_BOOKE
+#elif defined(CONFIG_FSL_BOOKE)
BEGIN_FTR_SECTION
mfspr r3,SPRN_L1CSR0
ori r3,r3,L1CSR0_CFI|L1CSR0_CLFC
diff --git a/drivers/hid/hid-cypress.c b/drivers/hid/hid-cypress.c
index 1b764d1745f3..1689568b597d 100644
--- a/drivers/hid/hid-cypress.c
+++ b/drivers/hid/hid-cypress.c
@@ -39,6 +39,9 @@ static __u8 *cp_report_fixup(struct hid_device *hdev, __u8
*rdesc,
if (!(quirks & CP_RDESC_SWAPPED_MIN_MAX))
return rdesc;
+ if (*rsize < 4)
+ return rdesc;
+
for (i = 0; i < *rsize - 4; i++)
if (rdesc[i] == 0x29 && rdesc[i + 2] == 0x19) {
rdesc[i] = 0x19;
diff --git a/drivers/isdn/gigaset/ser-gigaset.c
b/drivers/isdn/gigaset/ser-gigaset.c
index 2a506fe0c8a4..74bf1a17ae7c 100644
--- a/drivers/isdn/gigaset/ser-gigaset.c
+++ b/drivers/isdn/gigaset/ser-gigaset.c
@@ -762,8 +762,10 @@ static int __init ser_gigaset_init(void)
driver = gigaset_initdriver(GIGASET_MINOR, GIGASET_MINORS,
GIGASET_MODULENAME, GIGASET_DEVNAME,
&ops, THIS_MODULE);
- if (!driver)
+ if (!driver) {
+ rc = -ENOMEM;
goto error;
+ }
rc = tty_register_ldisc(N_GIGASET_M101, &gigaset_ldisc);
if (rc != 0) {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 6cf6d93d8831..ba115ec7aa92 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -432,6 +432,13 @@ static int handle_hca_cap(struct mlx5_core_dev *dev)
MLX5_SET(cmd_hca_cap, set_hca_cap, pkey_table_size,
to_fw_pkey_sz(128));
+ /* Check log_max_qp from HCA caps to set in current profile */
+ if (MLX5_CAP_GEN_MAX(dev, log_max_qp) < profile[prof_sel].log_max_qp) {
+ mlx5_core_warn(dev, "log_max_qp value in current profile is %d,
changing it to HCA capability limit (%d)\n",
+ profile[prof_sel].log_max_qp,
+ MLX5_CAP_GEN_MAX(dev, log_max_qp));
+ profile[prof_sel].log_max_qp = MLX5_CAP_GEN_MAX(dev,
log_max_qp);
+ }
if (prof->mask & MLX5_PROF_MASK_QP_SIZE)
MLX5_SET(cmd_hca_cap, set_hca_cap, log_max_qp,
prof->log_max_qp);
@@ -505,7 +512,6 @@ static int mlx5_irq_set_affinity_hint(struct mlx5_core_dev
*mdev, int i)
struct mlx5_priv *priv = &mdev->priv;
struct msix_entry *msix = priv->msix_arr;
int irq = msix[i + MLX5_EQ_VEC_COMP_BASE].vector;
- int numa_node = priv->numa_node;
int err;
if (!zalloc_cpumask_var(&priv->irq_info[i].mask, GFP_KERNEL)) {
@@ -513,7 +519,7 @@ static int mlx5_irq_set_affinity_hint(struct mlx5_core_dev
*mdev, int i)
return -ENOMEM;
}
- cpumask_set_cpu(cpumask_local_spread(i, numa_node),
+ cpumask_set_cpu(cpumask_local_spread(i, priv->numa_node),
priv->irq_info[i].mask);
err = irq_set_affinity_hint(irq, pr
Linux 4.9.4
I'm announcing the release of the 4.9.4 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm/configs/qcom_defconfig |4 arch/arm/mach-omap2/Makefile|2 arch/arm/mach-omap2/board-generic.c |2 arch/arm/mach-omap2/common.h| 38 +-- arch/arm/mach-omap2/io.c|3 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 37 +-- arch/arm/mach-omap2/omap4-sar-layout.h |2 arch/arm/mach-omap2/timer.c |9 - arch/arm/mach-pxa/pxa25x.c |2 arch/arm/mach-zynq/common.c |2 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts|7 - arch/arm64/boot/dts/broadcom/bcm2837.dtsi |2 arch/arm64/boot/dts/mediatek/mt8173.dtsi|3 arch/powerpc/kernel/misc_32.S |2 arch/x86/net/bpf_jit_comp.c |2 drivers/bus/arm-ccn.c |5 drivers/clk/clkdev.c|8 + drivers/gpu/drm/i915/i915_drv.h |2 drivers/gpu/drm/i915/intel_display.c| 31 + drivers/gpu/drm/i915/intel_pm.c | 75 ++ drivers/hid/hid-cypress.c |3 drivers/net/dsa/bcm_sf2.c | 11 +- drivers/net/ethernet/mellanox/mlx5/core/en_fs_ethtool.c |1 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 27 +++-- drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c |7 - drivers/net/ethernet/mellanox/mlx5/core/eswitch.c |2 drivers/net/ethernet/mellanox/mlx5/core/main.c | 15 ++ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 23 ++-- drivers/net/usb/r8152.c | 80 --- drivers/net/vrf.c | 13 ++ drivers/net/wireless/realtek/rtlwifi/base.c |8 - drivers/net/wireless/realtek/rtlwifi/core.c |9 - drivers/net/wireless/realtek/rtlwifi/pci.c | 14 -- drivers/net/wireless/realtek/rtlwifi/ps.c | 36 +- drivers/net/wireless/realtek/rtlwifi/usb.c |1 drivers/spi/spi-orion.c | 83 ++-- include/linux/netdevice.h |9 + net/core/dev.c |4 net/core/drop_monitor.c | 39 +-- net/core/flow_dissector.c |5 net/core/rtnetlink.c|6 + net/core/sock.c |6 - net/dsa/dsa2.c | 11 +- net/ipv4/fib_frontend.c |2 net/ipv4/fib_semantics.c|9 + net/ipv4/igmp.c |7 + net/ipv4/ip_sockglue.c | 10 + net/ipv4/route.c|3 net/ipv6/datagram.c |2 net/ipv6/ip6_offload.c |1 net/ipv6/raw.c |6 - net/sched/cls_api.c |4 net/sched/cls_flower.c |4 net/sctp/socket.c |5 net/sunrpc/xprtrdma/svc_rdma_backchannel.c |1 sound/firewire/tascam/tascam-stream.c |2 sound/usb/quirks.c |1 tools/virtio/linux/compiler.h |2 59 files changed, 507 insertions(+), 205 deletions(-) Alexander Duyck (1): ipv4: Do not allow MAIN to be alias for new LOCAL w/ custom rules Andrea Merello (1): ARM64: dts: bcm2837-rpi-3-b: remove incorrect pwr LED Andreas Färber (1): ARM64: dts: bcm2835: Fix bcm2837 compatible string Anna, Suman (1): net: add the AF_QIPCRTR entries to family name tables Chuck Lever (1): svcrdma: Clear xpt_bc_xps in xprt_setup_rdma_bc() error exit arm Daniel Borkmann (2): net, sched: fix soft lockup in tc_classify bpf: change back to orig prog on too many passes Daniel Jurgens (1): net/mlx5: Can
Re: Linux 4.9.4
diff --git a/Makefile b/Makefile
index ae42a0aaab06..9175706bfe7f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 3
+SUBLEVEL = 4
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index c2dff4fd5fc4..9f6d2a69a6f7 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -162,8 +162,8 @@ CONFIG_APQ_MMCC_8084=y
CONFIG_IPQ_LCC_806X=y
CONFIG_MSM_GCC_8660=y
CONFIG_MSM_LCC_8960=y
-CONFIG_MSM_GCC_9615=y
-CONFIG_MSM_LCC_9615=y
+CONFIG_MDM_GCC_9615=y
+CONFIG_MDM_LCC_9615=y
CONFIG_MSM_MMCC_8960=y
CONFIG_MSM_MMCC_8974=y
CONFIG_HWSPINLOCK_QCOM=y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5b37ec29996e..e37ceb81a379 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -80,7 +80,7 @@ endif
# Power Management
omap-4-5-pm-common = omap-mpuss-lowpower.o
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-pm-common)
-obj-$(CONFIG_ARCH_OMAP5) += $(omap-4-5-pm-common)
+obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-pm-common)
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
ifeq ($(CONFIG_PM),y)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index bab814d2f37d..60f5e838a3bc 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -306,7 +306,7 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device
Tree)")
.init_late = am43xx_init_late,
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
- .init_time = omap4_local_timer_init,
+ .init_time = omap3_gptimer_timer_init,
.dt_compat = am43_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index deed42e1dd9c..6dcca2957e23 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -262,8 +262,6 @@ extern void __iomem *omap4_get_sar_ram_base(void);
extern void omap4_mpuss_early_init(void);
extern void omap_do_wfi(void);
-extern void omap4_secondary_startup(void);
-extern void omap4460_secondary_startup(void);
#ifdef CONFIG_SMP
/* Needed for secondary core boot */
@@ -275,16 +273,11 @@ extern void omap4_cpu_die(unsigned int cpu);
extern int omap4_cpu_kill(unsigned int cpu);
extern const struct smp_operations omap4_smp_ops;
-
-extern void omap5_secondary_startup(void);
-extern void omap5_secondary_hyp_startup(void);
#endif
#if defined(CONFIG_SMP) && defined(CONFIG_PM)
extern int omap4_mpuss_init(void);
extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
-extern int omap4_finish_suspend(unsigned long cpu_state);
-extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
@@ -305,14 +298,41 @@ static inline int omap4_mpuss_init(void)
return 0;
}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP4
+void omap4_secondary_startup(void);
+void omap4460_secondary_startup(void);
+int omap4_finish_suspend(unsigned long cpu_state);
+void omap4_cpu_resume(void);
+#else
+static inline void omap4_secondary_startup(void)
+{
+}
+
+static inline void omap4460_secondary_startup(void)
+{
+}
static inline int omap4_finish_suspend(unsigned long cpu_state)
{
return 0;
}
-
static inline void omap4_cpu_resume(void)
-{}
+{
+}
+#endif
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
+void omap5_secondary_startup(void);
+void omap5_secondary_hyp_startup(void);
+#else
+static inline void omap5_secondary_startup(void)
+{
+}
+
+static inline void omap5_secondary_hyp_startup(void)
+{
+}
#endif
void pdata_quirks_init(const struct of_device_id *);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 0e9acdd95d70..f0da5259762a 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -717,10 +717,11 @@ void __init omap5_init_early(void)
OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
omap2_control_base_init();
- omap4_pm_init_early();
omap2_prcm_base_init();
omap5xxx_check_revision();
omap4_sar_ram_init();
+ omap4_mpuss_early_init();
+ omap4_pm_init_early();
omap54xx_voltagedomains_init();
omap54xx_powerdomains_init();
omap54xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index ad982465efd0..7d62ad48c7c9 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#include "soc.h"
@@ -244,10
[PATCH] drm/i915: Avoid drm_atomic_state_put(NULL) in intel_display_resume
intel_display_resume() may be called without a atomic state to restore,
i.e. dev_priv->modeset_reset_restore state is NULL. One such case is
following a lid open/close event and the forced modeset in
intel_lid_notiy().
Reported-by: Stefan Seyfried
Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: # v4.10-rc1+
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3dc8724df400..260bbe8881e6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -17024,7 +17024,8 @@ void intel_display_resume(struct drm_device *dev)
if (ret)
DRM_ERROR("Restoring old state failed with %i\n", ret);
- drm_atomic_state_put(state);
+ if (state)
+ drm_atomic_state_put(state);
}
void intel_modeset_gem_init(struct drm_device *dev)
--
2.11.0
arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'
Hi Alex, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f4d3935e4f4884ba80561db5549394afb8eef8f7 commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation of a VDSO date: 1 year, 2 months ago config: mips-decstation_defconfig (attached as .config) compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout ebb5e78cc63417a35254a791de66e1cc84f963cc # save the attached .config to linux build tree make.cross ARCH=mips All errors (new ones prefixed by >>): >> arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32' /* -- >> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3000' requires '-mfp32' /* vim +1 arch/mips/vdso/elf.S > 1 /* 2 * Copyright (C) 2015 Imagination Technologies 3 * Author: Alex Smith 4 * --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v2 2/2] iio: distance: srf08: add IIO driver for us ranger
On 14/01/17 17:48, Andreas Klinger wrote:
> Hi Jonathan,
>
> see comments below.
>
> Andreas
>
>
> Jonathan Cameron schrieb am Sat, 14. Jan 12:17:
>> On 10/01/17 18:48, Andreas Klinger wrote:
>>> This is the IIO driver for devantech srf08 ultrasonic ranger which can be
>>> used to measure the distances to an object.
>>>
>>> The sensor supports I2C with some registers.
>>>
>>> Supported Features include:
>>> - read the distance in ranging mode in centimeters
>>> - output of the driver is directly the read value
>>> - together with the scale the driver delivers the distance in meters
>>> - only the first echo of the nearest object is delivered
>>> - set max gain register; userspace enters analogue value
>>> - set range registers; userspace enters range in millimeters in 43 mm steps
>>>
>>> Features not supported by this driver:
>>> - ranging mode in inches or in microseconds
>>> - ANN mode
>>> - change I2C address through this driver
>>> - light sensor
>>>
>>> The driver was added in the directory "proximity" of the iio subsystem
>>> in absence of another directory named "distance".
>>> There is also a new submenu "distance"
>> Hi Andreas,
>>
>> Sorry it took me a while to get to this!
>>
>> I'd not bother with the new submenu. Perhaps we should rename the
>> proximity menu to proximity/distance.
>>
>> We already the lightening detector in there which is definitely not
>> measuring proximity in the convetional sense!
>>
>> Anyhow, the actual code is fine, but we need to think about how the
>> userspace ABI fits within the wider IIO ABI. Naming and approaches
>> that make sense in a single class of drivers can end up meaining
>> very different things for other drivers. Various suggestions inline.
>>
>> Jonathan
>>>
>>> Signed-off-by: Andreas Klinger
>>> ---
>>> drivers/iio/proximity/Kconfig | 15 ++
>>> drivers/iio/proximity/Makefile | 1 +
>>> drivers/iio/proximity/srf08.c | 362
>>> +
>>> 3 files changed, 378 insertions(+)
>>> create mode 100644 drivers/iio/proximity/srf08.c
>>>
>>> diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
>>> index ef4c73db5b53..7b10a137702b 100644
>>> --- a/drivers/iio/proximity/Kconfig
>>> +++ b/drivers/iio/proximity/Kconfig
>>> @@ -46,3 +46,18 @@ config SX9500
>>> module will be called sx9500.
>>>
>>> endmenu
>>> +
>>> +menu "Distance sensors"
>>> +
>>> +config SRF08
>>> + tristate "Devantech SRF08 ultrasonic ranger sensor"
>>> + depends on I2C
>>> + help
>>> + Say Y here to build a driver for Devantech SRF08 ultrasonic
>>> + ranger sensor. This driver can be used to measure the distance
>>> + of objects.
>>> +
>>> + To compile this driver as a module, choose M here: the
>>> + module will be called srf08.
>>> +
>>> +endmenu
>>> diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
>>> index 9aadd9a8ee99..e914c2a5dd49 100644
>>> --- a/drivers/iio/proximity/Makefile
>>> +++ b/drivers/iio/proximity/Makefile
>>> @@ -5,4 +5,5 @@
>>> # When adding new entries keep the list in alphabetical order
>>> obj-$(CONFIG_AS3935) += as3935.o
>>> obj-$(CONFIG_LIDAR_LITE_V2)+= pulsedlight-lidar-lite-v2.o
>>> +obj-$(CONFIG_SRF08)+= srf08.o
>>> obj-$(CONFIG_SX9500) += sx9500.o
>>> diff --git a/drivers/iio/proximity/srf08.c b/drivers/iio/proximity/srf08.c
>>> new file mode 100644
>>> index ..f38c74ed0933
>>> --- /dev/null
>>> +++ b/drivers/iio/proximity/srf08.c
>>> @@ -0,0 +1,362 @@
>>> +/*
>>> + * srf08.c - Support for Devantech SRF08 ultrasonic ranger
>>> + *
>>> + * Copyright (c) 2016 Andreas Klinger
>>> + *
>>> + * This file is subject to the terms and conditions of version 2 of
>>> + * the GNU General Public License. See the file COPYING in the main
>>> + * directory of this archive for more details.
>>> + *
>>> + * For details about the device see:
>>> + * http://www.robot-electronics.co.uk/htm/srf08tech.html
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +/* registers of SRF08 device */
>>> +#define SRF08_WRITE_COMMAND0x00/* Command Register */
>>> +#define SRF08_WRITE_MAX_GAIN 0x01/* Max Gain Register: 0 .. 31 */
>>> +#define SRF08_WRITE_RANGE 0x02/* Range Register: 0 .. 255 */
>>> +#define SRF08_READ_SW_REVISION 0x00/* Software Revision */
>>> +#define SRF08_READ_LIGHT 0x01/* Light Sensor during last echo */
>>> +#define SRF08_READ_ECHO_1_HIGH 0x02/* Range of first echo received
>>> */
>>> +#define SRF08_READ_ECHO_1_LOW 0x03/* Range of first echo received
>>> */
>>> +
>>> +#define SRF08_CMD_RANGING_CM 0x51/* Ranging Mode - Result in cm
>>> */
>>> +
>>> +#define SRF08_DEFAULT_GAIN 1025/* max. analogue value of Gain */
>>> +#define SRF08_DEFAULT_RANGE11008 /* max. value of Range in mm */
>>> +
>>> +struct srf08_data {
>>>
[PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
Some devices (due to e.g. bad PCIe signal integrity) require to run
with forced GEN1 speed on PCIe bus.
This patch changes the speed explicitly on dra7 based devices when
proper device tree attribute is defined for the PCIe controller.
Signed-off-by: Lukasz Majewski
---
Patch applies on newest origin/master
SHA1: f4d3935e4f4884ba80561db5549394afb8eef8f7
Tested at AM5728
---
Documentation/devicetree/bindings/pci/ti-pci.txt | 1 +
drivers/pci/host/pci-dra7xx.c| 23 +++
drivers/pci/host/pcie-designware.h | 1 +
3 files changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 60e2516..9f97409 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -25,6 +25,7 @@ PCIe Designware Controller
Optional Property:
- gpios : Should be added if a gpio line is required to drive PERST# line
+ - to,pcie-is-gen1: Indicates that forced gen1 port operation is needed.
Example:
axi {
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 9595fad..eec5fae 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -63,6 +63,13 @@
#defineLINK_UP BIT(16)
#defineDRA7XX_CPU_TO_BUS_ADDR 0x0FFF
+#define PCIECTRL_EP_DBICS_LNK_CAP 0x007C
+#define MAX_LINK_SPEEDS_MASK GENMASK(3, 0)
+#define MAX_LINK_SPEEDS_GEN1BIT(0)
+
+#define PCIECTRL_PL_WIDTH_SPEED_CTL 0x080C
+#define CFG_DIRECTED_SPEED_CHANGE BIT(17)
+
struct dra7xx_pcie {
struct pcie_portpp;
void __iomem*base; /* DT ti_conf */
@@ -270,6 +277,7 @@ static int __init dra7xx_add_pcie_port(struct dra7xx_pcie
*dra7xx,
struct pcie_port *pp = &dra7xx->pp;
struct device *dev = pp->dev;
struct resource *res;
+ u32 val;
pp->irq = platform_get_irq(pdev, 1);
if (pp->irq < 0) {
@@ -296,6 +304,18 @@ static int __init dra7xx_add_pcie_port(struct dra7xx_pcie
*dra7xx,
if (!pp->dbi_base)
return -ENOMEM;
+ if (pp->is_gen1) {
+ dev_info(dev, "GEN1 forced\n");
+
+ val = readl(pp->dbi_base + PCIECTRL_EP_DBICS_LNK_CAP);
+ set_mask_bits(&val, MAX_LINK_SPEEDS_MASK, MAX_LINK_SPEEDS_GEN1);
+ writel(val, pp->dbi_base + PCIECTRL_EP_DBICS_LNK_CAP);
+
+ val = readl(pp->dbi_base + PCIECTRL_PL_WIDTH_SPEED_CTL);
+ val &= ~CFG_DIRECTED_SPEED_CHANGE;
+ writel(val, pp->dbi_base + PCIECTRL_PL_WIDTH_SPEED_CTL);
+ }
+
ret = dw_pcie_host_init(pp);
if (ret) {
dev_err(dev, "failed to initialize host\n");
@@ -404,6 +424,9 @@ static int __init dra7xx_pcie_probe(struct platform_device
*pdev)
goto err_gpio;
}
+ if (of_property_read_bool(np, "ti,pcie-is-gen1"))
+ pp->is_gen1 = true;
+
reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_DEVICE_CMD);
reg &= ~LTSSM_EN;
dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_DEVICE_CMD, reg);
diff --git a/drivers/pci/host/pcie-designware.h
b/drivers/pci/host/pcie-designware.h
index a567ea2..2fb0b18 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -50,6 +50,7 @@ struct pcie_port {
struct irq_domain *irq_domain;
unsigned long msi_data;
u8 iatu_unroll_enabled;
+ u8 is_gen1;
DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS);
};
--
2.1.4
arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'
Hi Guenter, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f4d3935e4f4884ba80561db5549394afb8eef8f7 commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error with binutils 2.24 and earlier date: 1 year, 1 month ago config: mips-decstation_defconfig (attached as .config) compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e # save the attached .config to linux build tree make.cross ARCH=mips All errors (new ones prefixed by >>): >> arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32' /* vim +1 arch/mips/vdso/gettimeofday.c a7f4df4e Alex Smith 2015-10-21 @1 /* a7f4df4e Alex Smith 2015-10-21 2 * Copyright (C) 2015 Imagination Technologies a7f4df4e Alex Smith 2015-10-21 3 * Author: Alex Smith a7f4df4e Alex Smith 2015-10-21 4 * a7f4df4e Alex Smith 2015-10-21 5 * This program is free software; you can redistribute it and/or modify it a7f4df4e Alex Smith 2015-10-21 6 * under the terms of the GNU General Public License as published by the a7f4df4e Alex Smith 2015-10-21 7 * Free Software Foundation; either version 2 of the License, or (at your a7f4df4e Alex Smith 2015-10-21 8 * option) any later version. a7f4df4e Alex Smith 2015-10-21 9 */ :: The code at line 1 was first introduced by commit :: a7f4df4e21dd8a8dab96e88acd2c9c5017b83fc6 MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime() :: TO: Alex Smith :: CC: Ralf Baechle --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [alsa-devel] [PATCH 1/1] ASoC: fsl_asrc: use dma_transfer_direction enum when calling dmaengine_prep_dma_cyclic
On Sun, Jan 15, 2017 at 10:43 AM, Nicolas Iooss wrote: > When fsl_asrc_dma_prepare_and_submit() calls > dmaengine_prep_dma_cyclic(), it uses either DMA_TO_DEVICE or > DMA_FROM_DEVICE. These values are both items of dma_data_direction enum, > not of dma_data_direction enum, which is the type expected by > dmaengine_prep_dma_cyclic(). > > Replace DMA_TO_DEVICE with DMA_MEM_TO_DEV and DMA_FROM_DEVICE with > DMA_DEV_TO_MEM to fix this type mismatch issue. > > Signed-off-by: Nicolas Iooss Reviewed-by: Fabio Estevam
Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack
Hi James, On Fri, Jan 13, 2017 at 10:49 AM, James Hogan wrote: > Its quite a significant change/feature, especially in terms of potential > for further breakage. I don't think its really stable material to be > honest. It sounds bad if the kernel stack requirement can be made > arbitrarily large by stacking too many drivers. Indeed I believe this is the case. If, say, a kthread is already using a bit of stack, and then a softirq chain of stacked virtual network drivers is called, the stack can be busted. > Is there a simpler fix/workaround for the issue that would satisfy > stable kernel users until they can upgrade to a kernel with irqstacks? The simplest solution is probably just not stacking tons of network drivers. For my own out-of-tree curve25519-donna code that's in OpenWRT and uses a fair amount of stack, I just kmalloc on MIPS but not on x86, so in terms of my own stuff there's already a workaround in place. But this still doesn't solve things for users who have some interesting networking requirements and stack a few drivers. Unfortunately, most folks are only testing stuff on ARM and x86, which already have the separate IRQ stacks, so they aren't hitting crashes. So, in the end, I'm not quite sure. On the one hand, this fixes an actual problem and it'd be nice to see stable kernels have the fix. On the other hand, this is a rather big change. I don't know how to assess it, but I've copied Greg on this email, who certainly has better judgement about this than me. Jason
arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register 'atomctl' for 'wsr' instruction
Hi Pete, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f4d3935e4f4884ba80561db5549394afb8eef8f7 commit: d0b73b488c55df905ea8faaad079f8535629ed26 xtensa: Add config files for Diamond 233L - Rev C processor variant date: 3 years, 11 months ago config: xtensa-generic_kc705_defconfig (attached as .config) compiler: xtensa-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout d0b73b488c55df905ea8faaad079f8535629ed26 # save the attached .config to linux build tree make.cross ARCH=xtensa All errors (new ones prefixed by >>): arch/xtensa/include/asm/initialize_mmu.h: Assembler messages: >> arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register >> 'atomctl' for 'wsr' instruction vim +41 arch/xtensa/include/asm/initialize_mmu.h c622b29d Max Filippov 2012-11-19 25 c622b29d Max Filippov 2012-11-19 26 #ifdef __ASSEMBLY__ c622b29d Max Filippov 2012-11-19 27 c622b29d Max Filippov 2012-11-19 28 #define XTENSA_HWVERSION_RC_2009_0 23 c622b29d Max Filippov 2012-11-19 29 c622b29d Max Filippov 2012-11-19 30.macro initialize_mmu c622b29d Max Filippov 2012-11-19 31 c622b29d Max Filippov 2012-11-19 32 #if XCHAL_HAVE_S32C1I && (XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0) c622b29d Max Filippov 2012-11-19 33 /* c622b29d Max Filippov 2012-11-19 34 * We Have Atomic Operation Control (ATOMCTL) Register; Initialize it. c622b29d Max Filippov 2012-11-19 35 * For details see Documentation/xtensa/atomctl.txt c622b29d Max Filippov 2012-11-19 36 */ c622b29d Max Filippov 2012-11-19 37 #if XCHAL_DCACHE_IS_COHERENT c622b29d Max Filippov 2012-11-19 38movia3, 0x25/* For SMP/MX -- internal for writeback, c622b29d Max Filippov 2012-11-19 39 * RCW otherwise c622b29d Max Filippov 2012-11-19 40 */ c622b29d Max Filippov 2012-11-19 @41 #else c622b29d Max Filippov 2012-11-19 42movia3, 0x29/* non-MX -- Most cores use Std Memory c622b29d Max Filippov 2012-11-19 43 * Controlers which usually can't use RCW c622b29d Max Filippov 2012-11-19 44 */ c622b29d Max Filippov 2012-11-19 45 #endif c622b29d Max Filippov 2012-11-19 46wsr a3, atomctl c622b29d Max Filippov 2012-11-19 47 #endif /* XCHAL_HAVE_S32C1I && c622b29d Max Filippov 2012-11-19 48 * (XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0) c622b29d Max Filippov 2012-11-19 49 */ :: The code at line 41 was first introduced by commit :: c622b29d1f38021411965b7e0170ab01b257 xtensa: initialize atomctl SR :: TO: Max Filippov :: CC: Chris Zankel --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack
On Sun, Jan 15, 2017 at 02:39:49PM +0100, Jason A. Donenfeld wrote: > Hi James, > > On Fri, Jan 13, 2017 at 10:49 AM, James Hogan wrote: > > Its quite a significant change/feature, especially in terms of potential > > for further breakage. I don't think its really stable material to be > > honest. It sounds bad if the kernel stack requirement can be made > > arbitrarily large by stacking too many drivers. > > Indeed I believe this is the case. If, say, a kthread is already using > a bit of stack, and then a softirq chain of stacked virtual network > drivers is called, the stack can be busted. > > > Is there a simpler fix/workaround for the issue that would satisfy > > stable kernel users until they can upgrade to a kernel with irqstacks? > > The simplest solution is probably just not stacking tons of network > drivers. For my own out-of-tree curve25519-donna code that's in > OpenWRT and uses a fair amount of stack, I just kmalloc on MIPS but > not on x86, so in terms of my own stuff there's already a workaround > in place. But this still doesn't solve things for users who have some > interesting networking requirements and stack a few drivers. > > Unfortunately, most folks are only testing stuff on ARM and x86, which > already have the separate IRQ stacks, so they aren't hitting crashes. > > So, in the end, I'm not quite sure. On the one hand, this fixes an > actual problem and it'd be nice to see stable kernels have the fix. On > the other hand, this is a rather big change. I don't know how to > assess it, but I've copied Greg on this email, who certainly has > better judgement about this than me. How many patches is the irqstacks "feature" for MIPS? What kernel was it released in? Have any git commit ids I can look at? thanks, greg k-h
Re: [PATCH 1/3] DT/bindings: Add bindings for TI ADS7950 A/DC chips
On 14/01/17 18:00, David Lechner wrote:
> On 01/14/2017 06:53 AM, Jonathan Cameron wrote:
>> On 11/01/17 17:52, David Lechner wrote:
>>> This adds device tree bindings for the TI ADS7950 family of A/DC chips.
>>>
>>> Signed-off-by: David Lechner
>> This is in of itself good, but we may need to have some deprecated
>> elements to continue supporting what was implicitly happening with
>> the missnaming so as to avoid accidentally breaking someone's device
>> tree.
>>
>
> As I mentioned in my cover letter, this driver, as far as I can tell,
> only exists in your testing branch, so I find it highly unlikely that
> we would be breaking anyone. It is not in mainline and it is not even
> in linux-next.
Oops, I not only have a memory like a goldfish, I clearly didn't read your
cover letter either.
Applied to the togreg branch of iio.git and pushed out as testing.
The driver will hit next before this does but will get into mainline
in the same ultimate pull request unless something weird happens so that's
all fine.
Jonathan
>> Jonathan
>>> ---
>>> .../devicetree/bindings/iio/adc/ti-ads7950.txt | 23
>>> ++
>>> 1 file changed, 23 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-ads7950.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/adc/ti-ads7950.txt
>>> b/Documentation/devicetree/bindings/iio/adc/ti-ads7950.txt
>>> new file mode 100644
>>> index 000..e77a6f7
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/adc/ti-ads7950.txt
>>> @@ -0,0 +1,23 @@
>>> +* Texas Instruments ADS7950 family of A/DC chips
>>> +
>>> +Required properties:
>>> + - compatible: Must be one of "ti,ads7950", "ti,ads7951", "ti,ads7952",
>>> + "ti,ads7953", "ti,ads7954", "ti,ads7955", "ti,ads7956", "ti,ads7957",
>>> + "ti,ads7958", "ti,ads7959", "ti,ads7960", or "ti,ads7961"
>>> + - reg: SPI chip select number for the device
>>> + - #io-channel-cells: Must be 1 as per ../iio-bindings.txt
>>> + - vref-supply: phandle to a regulator node that supplies the 2.5V or 5V
>>> + reference voltage
>>> +
>>> +Recommended properties:
>>> + - spi-max-frequency: Definition as per
>>> +Documentation/devicetree/bindings/spi/spi-bus.txt
>>> +
>>> +Example:
>>> +adc@0 {
>>> +compatible = "ti,ads7957";
>>> +reg = <0>;
>>> +#io-channel-cells = <1>;
>>> +vref-supply = <&refin_supply>;
>>> +spi-max-frequency = <1000>;
>>> +};
>>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/i915: Avoid drm_atomic_state_put(NULL) in intel_display_resume
Hi Chris,
this fixes the problem for me, thanks!
Tested-by: Stefan Seyfried
Am 15.01.2017 um 13:58 schrieb Chris Wilson:
> intel_display_resume() may be called without a atomic state to restore,
> i.e. dev_priv->modeset_reset_restore state is NULL. One such case is
> following a lid open/close event and the forced modeset in
> intel_lid_notiy().
>
> Reported-by: Stefan Seyfried
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: # v4.10-rc1+
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3dc8724df400..260bbe8881e6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -17024,7 +17024,8 @@ void intel_display_resume(struct drm_device *dev)
>
> if (ret)
> DRM_ERROR("Restoring old state failed with %i\n", ret);
> - drm_atomic_state_put(state);
> + if (state)
> + drm_atomic_state_put(state);
> }
>
> void intel_modeset_gem_init(struct drm_device *dev)
--
Stefan Seyfried
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman
Re: [PATCH 2/3] iio: adc: ti-ads7950: Drop "ti-" prefix from module name
On 14/01/17 18:07, David Lechner wrote:
> On 01/14/2017 06:49 AM, Jonathan Cameron wrote:
>> On 11/01/17 17:52, David Lechner wrote:
>>> This drops the "ti-" prefix from the module name. It makes the module name
>>> consistent with other iio ti-ads* drivers and it makes the driver work
>>> with device tree (the spi subsystem drops the "ti," prefix when matching
>>> compatible strings from device tree).
>>>
>>> Tested working on LEGO MINDSTORMS EV3 with the following device tree node:
>>>
>>> adc@3 {
>>> compatible = "ti,ads7957";
>>> reg = <3>;
>>> #io-channel-cells = <1>;
>>> spi-max-frequency = <1000>;
>>> vref-supply = <&adc_ref>;
>>> };
>>>
>>> Signed-off-by: David Lechner
>> What worries me here is that we might break existing setups. I agree
>> we should have gotten this 'right' in the first place, but can we fix
>> it now. Not so sure. We'd be better off perhaps adding an of_device_id
>> table with the write entries for device tree.
>
> As far as I can tell, this driver only exists in your testing branch.
> Does that really mean that it is too late to get it right?
Gah! I have a memory like a goldfish.
Excellent point - we can and should do this asap.
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
>>> ---
>>> drivers/iio/adc/ti-ads7950.c | 26 +-
>>> 1 file changed, 13 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c
>>> index 0330361..b587fa6 100644
>>> --- a/drivers/iio/adc/ti-ads7950.c
>>> +++ b/drivers/iio/adc/ti-ads7950.c
>>> @@ -459,25 +459,25 @@ static int ti_ads7950_remove(struct spi_device *spi)
>>> }
>>>
>>> static const struct spi_device_id ti_ads7950_id[] = {
>>> -{"ti-ads7950", TI_ADS7950},
>>> -{"ti-ads7951", TI_ADS7951},
>>> -{"ti-ads7952", TI_ADS7952},
>>> -{"ti-ads7953", TI_ADS7953},
>>> -{"ti-ads7954", TI_ADS7954},
>>> -{"ti-ads7955", TI_ADS7955},
>>> -{"ti-ads7956", TI_ADS7956},
>>> -{"ti-ads7957", TI_ADS7957},
>>> -{"ti-ads7958", TI_ADS7958},
>>> -{"ti-ads7959", TI_ADS7959},
>>> -{"ti-ads7960", TI_ADS7960},
>>> -{"ti-ads7961", TI_ADS7961},
>>> +{ "ads7950", TI_ADS7950 },
>>> +{ "ads7951", TI_ADS7951 },
>>> +{ "ads7952", TI_ADS7952 },
>>> +{ "ads7953", TI_ADS7953 },
>>> +{ "ads7954", TI_ADS7954 },
>>> +{ "ads7955", TI_ADS7955 },
>>> +{ "ads7956", TI_ADS7956 },
>>> +{ "ads7957", TI_ADS7957 },
>>> +{ "ads7958", TI_ADS7958 },
>>> +{ "ads7959", TI_ADS7959 },
>>> +{ "ads7960", TI_ADS7960 },
>>> +{ "ads7961", TI_ADS7961 },
>>> { }
>>> };
>>> MODULE_DEVICE_TABLE(spi, ti_ads7950_id);
>>>
>>> static struct spi_driver ti_ads7950_driver = {
>>> .driver = {
>>> -.name= "ti-ads7950",
>>> +.name= "ads7950",
>>> },
>>> .probe= ti_ads7950_probe,
>>> .remove= ti_ads7950_remove,
>>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] iio: adc: ti-ads7950: Change regulator matching string to "vref"
On 14/01/17 18:09, David Lechner wrote:
> On 01/14/2017 06:52 AM, Jonathan Cameron wrote:
>> On 11/01/17 17:52, David Lechner wrote:
>>> This changes the reference voltage regulator matching string from "refin"
>>> to "vref". This is to be consistent with other A/DC chips that also use
>>> "vref-supply" in their device tree bindings.
>>>
>>> Signed-off-by: David Lechner
>>> ---
>>> drivers/iio/adc/ti-ads7950.c | 6 +++---
>> Again, we missed this before and it would have been nice to have
>> had it as vref (which is matches the datasheet). The question
>> becomes how do we handle this going forward with no risk of breaking
>> existing device trees. We may have to do an optional get on one
>> name and then a non optional on the second. It's ugly, but
>> would fix this up in a 'safe' way.
>>
>
> Again, I don't think it is too late since this driver only exists in the
> iio/testing branch.
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
>
>> Jonathan
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c
>>> index b587fa6..16a0663 100644
>>> --- a/drivers/iio/adc/ti-ads7950.c
>>> +++ b/drivers/iio/adc/ti-ads7950.c
>>> @@ -411,15 +411,15 @@ static int ti_ads7950_probe(struct spi_device *spi)
>>> spi_message_init_with_transfers(&st->scan_single_msg,
>>> st->scan_single_xfer, 3);
>>>
>>> -st->reg = devm_regulator_get(&spi->dev, "refin");
>>> +st->reg = devm_regulator_get(&spi->dev, "vref");
>>> if (IS_ERR(st->reg)) {
>>> -dev_err(&spi->dev, "Failed get get regulator \"refin\"\n");
>>> +dev_err(&spi->dev, "Failed get get regulator \"vref\"\n");
>>> return PTR_ERR(st->reg);
>>> }
>>>
>>> ret = regulator_enable(st->reg);
>>> if (ret) {
>>> -dev_err(&spi->dev, "Failed to enable regulator \"refin\"\n");
>>> +dev_err(&spi->dev, "Failed to enable regulator \"vref\"\n");
>>> return ret;
>>> }
>>>
>>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ti,ads7950 device tree bindings
On 11/01/17 17:52, David Lechner wrote: > This series adds device tree bindings for the TI ADS7950 family of A/DC chips. > The series includes the bindings documentation and some fixes to the iio > driver > to make it work with the device tree bindings. > > FYI, the ads7950 driver has not made it into mainline yet, so no worries about > breaking anyone with these changes. > And here's the bit I failed to read! As an extra point, could you confirm what /sys/bus/iio/iio\:deviceX/name for this one reads? I have a feeling this is another case of what Lars has been pointing out in other drivers this morning. That name should be the device part number.. Thanks, Jonathan > David Lechner (3): > DT/bindings: Add bindings for TI ADS7950 A/DC chips > iio: adc: ti-ads7950: Drop "ti-" prefix from module name > iio: adc: ti-ads7950: Change regulator matching string to "vref" > > .../devicetree/bindings/iio/adc/ti-ads7950.txt | 23 > drivers/iio/adc/ti-ads7950.c | 32 > +++--- > 2 files changed, 39 insertions(+), 16 deletions(-) > create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-ads7950.txt >
cc1: error: '-march=r3000' requires '-mfp32'
Hi James, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f4d3935e4f4884ba80561db5549394afb8eef8f7 commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of vdso.lds date: 3 months ago config: mips-decstation_defconfig (attached as .config) compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 034827c727f7f3946a18355b63995b402c226c82 # save the attached .config to linux build tree make.cross ARCH=mips All errors (new ones prefixed by >>): >> cc1: error: '-march=r3000' requires '-mfp32' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack
Hi Greg, On Sun, Jan 15, 2017 at 2:48 PM, Greg Kroah-Hartman wrote: > How many patches is the irqstacks "feature" for MIPS? What kernel was > it released in? Have any git commit ids I can look at? According to Ralf, it's queued up for 4.11? Is that right? Part 1: https://lkml.org/lkml/2016/12/19/250 Part 2: https://lkml.org/lkml/2016/12/19/251 Part 3: https://lkml.org/lkml/2016/12/19/252 Part 4: https://lkml.org/lkml/2016/12/19/254 Part 5: https://lkml.org/lkml/2016/12/19/248 Jason
Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack
On Sun, Jan 15, 2017 at 3:11 PM, Jason A. Donenfeld wrote: > According to Ralf, it's queued up for 4.11? Is that right? It's in -next: Part 1: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=fe8bd18ffea5327344d4ec2bf11f47951212abd0 Part 2: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=d42d8d106b0275b027c1e8992c42aecf933436ea Part 3: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=510d86362a27577f5ee23f46cfb354ad49731e61 Part 4: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=dda45f701c9d7ad4ac0bb446e3a96f6df9a468d9 Part 5: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=3cc3434fd6307d06b53b98ce83e76bf9807689b9
Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack
On Sun, Jan 15, 2017 at 03:15:35PM +0100, Jason A. Donenfeld wrote: > On Sun, Jan 15, 2017 at 3:11 PM, Jason A. Donenfeld wrote: > > According to Ralf, it's queued up for 4.11? Is that right? > > It's in -next: > > Part 1: > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=fe8bd18ffea5327344d4ec2bf11f47951212abd0 > Part 2: > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=d42d8d106b0275b027c1e8992c42aecf933436ea > Part 3: > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=510d86362a27577f5ee23f46cfb354ad49731e61 > Part 4: > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=dda45f701c9d7ad4ac0bb446e3a96f6df9a468d9 > Part 5: > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=3cc3434fd6307d06b53b98ce83e76bf9807689b9 Sweet, that's it? Nice stuff, and all small and well-contained. If the MIPS maintainers have no issue with this, and it works out well in 4.11 for people (let's get it shaken out there first), I would have no objection to backporting this to the 4.4 and 4.9 stable trees if it will help out with issues that people are having with those tree. thanks, greg k-h
Re: [PATCH 02/19] staging: iio: isl29028: remove enable flag from isl29028_enable_proximity()
On 14/01/17 20:00, Brian Masney wrote: > On Sun, Dec 04, 2016 at 11:16:04AM +, Jonathan Cameron wrote: >> On 04/12/16 02:19, Brian Masney wrote: >>> isl29028_enable_proximity() has a boolean argument named enable. This >>> function is only called once and the enable flag is set to true in that >>> call. This patch removes the enable parameter from that function. >>> >>> Signed-off-by: Brian Masney >> >> The first thing that strikes me about this, is why do we have an enable >> only function? >> >> I think the intention was probably that we also disable the proximity >> sensing after the >> reading was done... Ideally we'd do this a little more cleverly, >> perhaps using runtime >> pm so that if someone is requesting a stream of proximity measurements, >> we won't end up >> powering up and down each time. >> >> It's a little 'interesting' as we would want to power this element down >> even if we do >> have a continuous stream of reads on the ALS. As such we may need to >> roll our own >> equivalent of runtime pm. >> >> In the first instance, I'd just put a disable after the reading is >> taken. This will >> make a bit of a mockery of the faster sampling frequencies but there we >> are! >> >> - >> >> On second thoughts (stupid email is hiding somewhere to be sent when I >> have wifi so can't reply to it) perhaps this is a coarse way of only >> turning proximity on if the LED is present? Not sure... > > Hi Jonathan, > > I chained your two replies together above. I am probably stating the > obvious here, but I've verified with an oscilloscope that the IRDR pin > that drives the external LED is off when the chip is first initialized > and ALS readings are taken. The IRDR pin fluctuates between high and low > every 100us (if memory serves me right) once the first proximity reading > is taken until the chip is suspended. > > What do you think about enabling runtime auto suspend after say 2 > seconds for the whole device? There is the situation that you describe > where if someone is continuously polling the ALS but asks for a single > proximity reading. The external LED will stay on in that case. Once the > chip is suspended, and later resumes, the IRDR pin that drives the > external LED will be off until the user asks for another proximity > reading. That would allow for the faster sampling frequency. > > If you still prefer, I'll go the route of shutting down the IRDR pin > after a proximity reading is taken. Perhaps runtime auto suspend for the whole thing is the simplest option. I don't mind that much either way. Jonathan > > Brian >
Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
Am 13.01.2017 um 21:03 schrieb Kevin Hilman: > Neil Armstrong writes: > >> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space, >> this patch adds this reserved zone and redefines the usable memory range. >> >> The memory node is also moved from the dtsi files into the proper dts files >> to handle variants memory sizes. >> >> This patch also fixes the memory sizes for the following platforms : >> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed >> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed >> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed >> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed >> >> Signed-off-by: Neil Armstrong > > Queued for v4.10-rc. What is the motivation for this change? I have a local U-Boot patch to detect the amount of memory available as done downstream, but U-Boot only updates the reg property that you seem to be abandoning here... So for devices that come in multiple RAM configurations - like R-Box Pro - this would require separate .dts files now! This looks very wrong to me, especially since I am not aware of other platforms doing the same. Instead, there's memory reservations for top and bottom done in U-Boot for reg, plus reserved-memory nodes for anything in the middle. Another thing to consider is that uEFI boot (bootefi) handles memory reservation differently yet again, on the bootloader level. I have had that working fine on Odroid-C2 and Vega S95. So if there's no bug this is fixing (none mentioned in commit message) I strongly object to this patch. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: Calling device_init_wakeup() on driver removal
On Saturday, January 14, 2017 08:46:05 PM Guenter Roeck wrote: > Hi folks, Hi, > while looking through driver initialization and removal functions, I noticed > that many drivers > call device_init_wakeup(dev, false) in the removal function. Given that the > driver is about > to be removed, that doesn't make much sense to me, especially since > device_wakeup_disable() > is called from device_pm_remove() anyway. > > Is it safe to assume that all those calls can be removed, or is there a > possible reason for > keeping them around ? Removing them automatically might break things, because device_init_wakeup(dev, false) also clears the power.can_wakeup flag and removes the "wakeup" attribute from sysfs. I guess they could be removed safely in the majority of cases, though. Thanks, Rafael
[PATCH 00/46] SELinux: Fine-tuning for several function implementations
From: Markus Elfring Date: Sun, 15 Jan 2017 15:15:14 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (46): Use kmalloc_array() in cond_init_bool_indexes() Delete an unnecessary return statement in cond_compute_av() Improve size determinations in four functions Use kmalloc_array() in hashtab_create() Adjust four checks for null pointers Use kcalloc() in policydb_index() Delete unnecessary variable assignments in policydb_index() Delete an unnecessary return statement in policydb_destroy() Delete an error message for a failed memory allocation in policydb_read() Move some assignments for the variable "rc" in policydb_read() Return directly after a failed next_entry() in genfs_read() Move assignments for two pointers in genfs_read() Move four assignments for the variable "rc" in genfs_read() One function call less in genfs_read() after null pointer detection One check and function call less in genfs_read() after error detection Move two assignments for the variable "rc" in filename_trans_read() Delete an unnecessary variable assignment in filename_trans_read() One function call less in filename_trans_read() after error detection Return directly after a failed next_entry() in range_read() Move four assignments for the variable "rc" in range_read() Two function calls less in range_read() after error detection Delete an unnecessary variable initialisation in range_read() Move an assignment for a pointer in range_read() Return directly after a failed kzalloc() in cat_read() Return directly after a failed kzalloc() in sens_read() Improve another size determination in sens_read() Move an assignment for the variable "rc" in sens_read() Return directly after a failed kzalloc() in user_read() Return directly after a failed kzalloc() in type_read() Return directly after a failed kzalloc() in role_read() Move an assignment for the variable "rc" in role_read() Return directly after a failed kzalloc() in class_read() Move an assignment for the variable "rc" in class_read() Return directly after a failed kzalloc() in common_read() Return directly after a failed kzalloc() in perm_read() Move an assignment for the variable "rc" in mls_read_range_helper() Move an assignment for the variable "rc" in policydb_load_isids() One function call less in five functions after null pointer detection Move two assignments for the variable "rc" in ocontext_read() Return directly after a failed kzalloc() in roles_init() Move two assignments for the variable "rc" in roles_init() One function call less in roles_init() after error detection Use kmalloc_array() in sidtab_init() Adjust two checks for null pointers Use common error handling code in sidtab_insert() Use seq_puts() in sel_avc_stats_seq_show() security/selinux/selinuxfs.c | 8 +- security/selinux/ss/conditional.c | 14 +-- security/selinux/ss/hashtab.c | 10 +- security/selinux/ss/policydb.c| 255 -- security/selinux/ss/sidtab.c | 22 ++-- 5 files changed, 157 insertions(+), 152 deletions(-) -- 2.11.0
[PATCH 01/46] selinux: Use kmalloc_array() in cond_init_bool_indexes()
From: Markus Elfring
Date: Sat, 14 Jan 2017 10:48:28 +0100
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
* Replace the specification of a data type by a pointer dereference
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Signed-off-by: Markus Elfring
---
security/selinux/ss/conditional.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/security/selinux/ss/conditional.c
b/security/selinux/ss/conditional.c
index 34afeadd9e73..fcfab2635c11 100644
--- a/security/selinux/ss/conditional.c
+++ b/security/selinux/ss/conditional.c
@@ -176,8 +176,9 @@ void cond_policydb_destroy(struct policydb *p)
int cond_init_bool_indexes(struct policydb *p)
{
kfree(p->bool_val_to_struct);
- p->bool_val_to_struct =
- kmalloc(p->p_bools.nprim * sizeof(struct cond_bool_datum *),
GFP_KERNEL);
+ p->bool_val_to_struct = kmalloc_array(p->p_bools.nprim,
+ sizeof(*p->bool_val_to_struct),
+ GFP_KERNEL);
if (!p->bool_val_to_struct)
return -ENOMEM;
return 0;
--
2.11.0
Re: [PATCH v9 1/3] gpio: exar: add gpio for exar cards
On Sun, Jan 15, 2017 at 12:50 AM, Sudip Mukherjee
wrote:
> From: Sudip Mukherjee
>
> Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
> can be controlled using gpio interface.
>
> Add the gpio specific code.
Thanks for an updated code.
Briefly looking into first two patches v10 would be needed.
Here one important line is missed, nevertheless I'll go to comment
some minor stuff as well.
Overall looks good!
> name[16] should be enough. Maximum of 12 char will be used.
Better to use enough space, otherwise there is a room for a bug.
So, you need to understand that kernel might crash in such cases,
though it's minor for now.
> +++ b/drivers/gpio/gpio-exar.c
> @@ -0,0 +1,199 @@
> +static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
> + unsigned int offset)
> +{
> + struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
> + int temp;
> +
> + mutex_lock(&exar_gpio->lock);
> + temp = readb(exar_gpio->regs + reg);
> + temp &= ~BIT(offset);
> + if (val)
> + temp |= BIT(offset);
You would do this in one line, but I dunno which style Linus prefers more
temp |= val ? BIT(...) : 0;
> +{
> + unsigned int addr;
> +
> + addr = offset / 8 ? EXAR_OFFSET_MPIOSEL_HI :
> + EXAR_OFFSET_MPIOSEL_LO;
Would it be one line?
Also you can consider
unsigned int bank = offset / 8;
unsigned int addr;
addr = bank ? _HI : _LO;
Same amount of lines, but a bit more readable. All other places as well.
> +static int gpio_exar_probe(struct platform_device *pdev)
> +{
> + struct pci_dev *pcidev = platform_get_drvdata(pdev);
> + struct exar_gpio_chip *exar_gpio;
> + void __iomem *p;
> + int index, ret;
> +
> + if (pcidev->vendor != PCI_VENDOR_ID_EXAR)
> + return -ENODEV;
> +
> + /*
> +* Map the pci device to get the register addresses
> +* We will need to read and write those registers to control
> +* the GPIO pins.
> +* Using managed functions will save us from unmaping on exit.
Yes, and "we may do that because UART driver enables managed functions".
> +*/
> +
Redundant empty line.
> + p = pcim_iomap(pcidev, 0, 0);
> + if (!p)
> + return -ENOMEM;
> +
> + exar_gpio = devm_kzalloc(&pcidev->dev, sizeof(*exar_gpio),
> GFP_KERNEL);
> + if (!exar_gpio)
> + return -ENOMEM;
> +
> + mutex_init(&exar_gpio->lock);
> +
> + index = ida_simple_get(&ida_index, 0, 0, GFP_KERNEL);
> +
> + sprintf(exar_gpio->name, "exar_gpio%d", index);
> + exar_gpio->gpio_chip.label = exar_gpio->name;
> + exar_gpio->gpio_chip.parent = &pcidev->dev;
> + exar_gpio->gpio_chip.direction_output = exar_direction_output;
> + exar_gpio->gpio_chip.direction_input = exar_direction_input;
> + exar_gpio->gpio_chip.get_direction = exar_get_direction;
> + exar_gpio->gpio_chip.get = exar_get_value;
> + exar_gpio->gpio_chip.set = exar_set_value;
> + exar_gpio->gpio_chip.base = -1;
> + exar_gpio->gpio_chip.ngpio = 16;
> + exar_gpio->regs = p;
> + exar_gpio->index = index;
> +
> + ret = devm_gpiochip_add_data(&pcidev->dev,
> +&exar_gpio->gpio_chip, exar_gpio);
> + if (ret)
> + goto err_destroy;
> +
> + platform_set_drvdata(pdev, exar_gpio);
> +
> + return 0;
> +
> +err_destroy:
> + mutex_destroy(&exar_gpio->lock);
Important!
You missed ida_simple_remove(); here
And as side effect you might overflow name and crash kernel due to this bug.
> + return ret;
> +}
--
With Best Regards,
Andy Shevchenko
[PATCH 02/46] selinux: Delete an unnecessary return statement in cond_compute_av()
From: Markus Elfring Date: Sat, 14 Jan 2017 11:00:23 +0100 The script "checkpatch.pl" pointed information out like the following. WARNING: void function return statements are not generally useful Thus remove such a statement in the affected function. Signed-off-by: Markus Elfring --- security/selinux/ss/conditional.c | 1 - 1 file changed, 1 deletion(-) diff --git a/security/selinux/ss/conditional.c b/security/selinux/ss/conditional.c index fcfab2635c11..4a3bf29f7565 100644 --- a/security/selinux/ss/conditional.c +++ b/security/selinux/ss/conditional.c @@ -664,5 +664,4 @@ void cond_compute_av(struct avtab *ctab, struct avtab_key *key, (node->key.specified & AVTAB_XPERMS)) services_compute_xperms_drivers(xperms, node); } - return; } -- 2.11.0
[PATCH 03/46] selinux: Improve size determinations in four functions
From: Markus Elfring
Date: Sat, 14 Jan 2017 11:22:12 +0100
Replace the specification of data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer.
Signed-off-by: Markus Elfring
---
security/selinux/ss/conditional.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/security/selinux/ss/conditional.c
b/security/selinux/ss/conditional.c
index 4a3bf29f7565..771c96afe1d5 100644
--- a/security/selinux/ss/conditional.c
+++ b/security/selinux/ss/conditional.c
@@ -227,7 +227,7 @@ int cond_read_bool(struct policydb *p, struct hashtab *h,
void *fp)
u32 len;
int rc;
- booldatum = kzalloc(sizeof(struct cond_bool_datum), GFP_KERNEL);
+ booldatum = kzalloc(sizeof(*booldatum), GFP_KERNEL);
if (!booldatum)
return -ENOMEM;
@@ -332,7 +332,7 @@ static int cond_insertf(struct avtab *a, struct avtab_key
*k, struct avtab_datum
goto err;
}
- list = kzalloc(sizeof(struct cond_av_list), GFP_KERNEL);
+ list = kzalloc(sizeof(*list), GFP_KERNEL);
if (!list) {
rc = -ENOMEM;
goto err;
@@ -421,7 +421,7 @@ static int cond_read_node(struct policydb *p, struct
cond_node *node, void *fp)
goto err;
rc = -ENOMEM;
- expr = kzalloc(sizeof(struct cond_expr), GFP_KERNEL);
+ expr = kzalloc(sizeof(*expr), GFP_KERNEL);
if (!expr)
goto err;
@@ -472,7 +472,7 @@ int cond_read_list(struct policydb *p, void *fp)
for (i = 0; i < len; i++) {
rc = -ENOMEM;
- node = kzalloc(sizeof(struct cond_node), GFP_KERNEL);
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
if (!node)
goto err;
--
2.11.0
[PATCH 04/46] selinux: Use kmalloc_array() in hashtab_create()
From: Markus Elfring
Date: Sat, 14 Jan 2017 12:06:13 +0100
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
security/selinux/ss/hashtab.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/selinux/ss/hashtab.c b/security/selinux/ss/hashtab.c
index 2cc496149842..dc99fff64ecb 100644
--- a/security/selinux/ss/hashtab.c
+++ b/security/selinux/ss/hashtab.c
@@ -24,7 +24,7 @@ struct hashtab *hashtab_create(u32 (*hash_value)(struct
hashtab *h, const void *
p->nel = 0;
p->hash_value = hash_value;
p->keycmp = keycmp;
- p->htable = kmalloc(sizeof(*(p->htable)) * size, GFP_KERNEL);
+ p->htable = kmalloc_array(size, sizeof(*p->htable), GFP_KERNEL);
if (p->htable == NULL) {
kfree(p);
return NULL;
--
2.11.0
[PATCH 05/46] selinux: Adjust four checks for null pointers
From: Markus Elfring
Date: Sat, 14 Jan 2017 12:36:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The script "checkpatch.pl" pointed information out like the following.
Comparison to NULL could be written !…
Thus fix affected source code places.
Signed-off-by: Markus Elfring
---
security/selinux/ss/hashtab.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/security/selinux/ss/hashtab.c b/security/selinux/ss/hashtab.c
index dc99fff64ecb..3858706a29fb 100644
--- a/security/selinux/ss/hashtab.c
+++ b/security/selinux/ss/hashtab.c
@@ -17,7 +17,7 @@ struct hashtab *hashtab_create(u32 (*hash_value)(struct
hashtab *h, const void *
u32 i;
p = kzalloc(sizeof(*p), GFP_KERNEL);
- if (p == NULL)
+ if (!p)
return p;
p->size = size;
@@ -25,7 +25,7 @@ struct hashtab *hashtab_create(u32 (*hash_value)(struct
hashtab *h, const void *
p->hash_value = hash_value;
p->keycmp = keycmp;
p->htable = kmalloc_array(size, sizeof(*p->htable), GFP_KERNEL);
- if (p->htable == NULL) {
+ if (!p->htable) {
kfree(p);
return NULL;
}
@@ -58,7 +58,7 @@ int hashtab_insert(struct hashtab *h, void *key, void *datum)
return -EEXIST;
newnode = kzalloc(sizeof(*newnode), GFP_KERNEL);
- if (newnode == NULL)
+ if (!newnode)
return -ENOMEM;
newnode->key = key;
newnode->datum = datum;
@@ -87,7 +87,7 @@ void *hashtab_search(struct hashtab *h, const void *key)
while (cur && h->keycmp(h, key, cur->key) > 0)
cur = cur->next;
- if (cur == NULL || (h->keycmp(h, key, cur->key) != 0))
+ if (!cur || (h->keycmp(h, key, cur->key) != 0))
return NULL;
return cur->datum;
--
2.11.0
[PATCH 06/46] selinux: Use kcalloc() in policydb_index()
From: Markus Elfring Date: Sat, 14 Jan 2017 13:08:59 +0100 Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kcalloc". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- security/selinux/ss/policydb.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c index d719db4219cd..21869b622c0c 100644 --- a/security/selinux/ss/policydb.c +++ b/security/selinux/ss/policydb.c @@ -540,23 +540,23 @@ static int policydb_index(struct policydb *p) #endif rc = -ENOMEM; - p->class_val_to_struct = - kzalloc(p->p_classes.nprim * sizeof(*(p->class_val_to_struct)), - GFP_KERNEL); + p->class_val_to_struct = kcalloc(p->p_classes.nprim, +sizeof(*p->class_val_to_struct), +GFP_KERNEL); if (!p->class_val_to_struct) goto out; rc = -ENOMEM; - p->role_val_to_struct = - kzalloc(p->p_roles.nprim * sizeof(*(p->role_val_to_struct)), - GFP_KERNEL); + p->role_val_to_struct = kcalloc(p->p_roles.nprim, + sizeof(*p->role_val_to_struct), + GFP_KERNEL); if (!p->role_val_to_struct) goto out; rc = -ENOMEM; - p->user_val_to_struct = - kzalloc(p->p_users.nprim * sizeof(*(p->user_val_to_struct)), - GFP_KERNEL); + p->user_val_to_struct = kcalloc(p->p_users.nprim, + sizeof(*p->user_val_to_struct), + GFP_KERNEL); if (!p->user_val_to_struct) goto out; -- 2.11.0
[PATCH 07/46] selinux: Delete unnecessary variable assignments in policydb_index()
From: Markus Elfring
Date: Sat, 14 Jan 2017 13:40:25 +0100
The local variable "rc" was reset with an error code up to five times
before a memory allocation failure was detected.
Add a jump target so that this assignment will only be performed after
a concrete software failure.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 21869b622c0c..4d4ba1ad910d 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -539,34 +539,30 @@ static int policydb_index(struct policydb *p)
symtab_hash_eval(p->symtab);
#endif
- rc = -ENOMEM;
p->class_val_to_struct = kcalloc(p->p_classes.nprim,
sizeof(*p->class_val_to_struct),
GFP_KERNEL);
if (!p->class_val_to_struct)
- goto out;
+ goto failure_indication;
- rc = -ENOMEM;
p->role_val_to_struct = kcalloc(p->p_roles.nprim,
sizeof(*p->role_val_to_struct),
GFP_KERNEL);
if (!p->role_val_to_struct)
- goto out;
+ goto failure_indication;
- rc = -ENOMEM;
p->user_val_to_struct = kcalloc(p->p_users.nprim,
sizeof(*p->user_val_to_struct),
GFP_KERNEL);
if (!p->user_val_to_struct)
- goto out;
+ goto failure_indication;
/* Yes, I want the sizeof the pointer, not the structure */
- rc = -ENOMEM;
p->type_val_to_struct_array = flex_array_alloc(sizeof(struct type_datum
*),
p->p_types.nprim,
GFP_KERNEL | __GFP_ZERO);
if (!p->type_val_to_struct_array)
- goto out;
+ goto failure_indication;
rc = flex_array_prealloc(p->type_val_to_struct_array, 0,
p->p_types.nprim, GFP_KERNEL | __GFP_ZERO);
@@ -578,12 +574,11 @@ static int policydb_index(struct policydb *p)
goto out;
for (i = 0; i < SYM_NUM; i++) {
- rc = -ENOMEM;
p->sym_val_to_name[i] = flex_array_alloc(sizeof(char *),
p->symtab[i].nprim,
GFP_KERNEL |
__GFP_ZERO);
if (!p->sym_val_to_name[i])
- goto out;
+ goto failure_indication;
rc = flex_array_prealloc(p->sym_val_to_name[i],
0, p->symtab[i].nprim,
@@ -598,6 +593,9 @@ static int policydb_index(struct policydb *p)
rc = 0;
out:
return rc;
+failure_indication:
+ rc = -ENOMEM;
+ goto out;
}
/*
--
2.11.0
[PATCH 08/46] selinux: Delete an unnecessary return statement in policydb_destroy()
From: Markus Elfring Date: Sat, 14 Jan 2017 14:00:02 +0100 The script "checkpatch.pl" pointed information out like the following. WARNING: void function return statements are not generally useful Thus remove such a statement in the affected function. Signed-off-by: Markus Elfring --- security/selinux/ss/policydb.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c index 4d4ba1ad910d..fe8992382a71 100644 --- a/security/selinux/ss/policydb.c +++ b/security/selinux/ss/policydb.c @@ -878,8 +878,6 @@ void policydb_destroy(struct policydb *p) ebitmap_destroy(&p->filename_trans_ttypes); ebitmap_destroy(&p->policycaps); ebitmap_destroy(&p->permissive_map); - - return; } /* -- 2.11.0
[PATCH 09/46] selinux: Delete an error message for a failed memory allocation in policydb_read()
From: Markus Elfring
Date: Sat, 14 Jan 2017 14:20:41 +0100
Omit an extra message for a memory allocation failure in this function.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index fe8992382a71..53e6d06e772a 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -2269,11 +2269,8 @@ int policydb_read(struct policydb *p, void *fp)
rc = -ENOMEM;
policydb_str = kmalloc(len + 1, GFP_KERNEL);
- if (!policydb_str) {
- printk(KERN_ERR "SELinux: unable to allocate memory for
policydb "
- "string of length %d\n", len);
+ if (!policydb_str)
goto bad;
- }
rc = next_entry(policydb_str, fp, len);
if (rc) {
--
2.11.0
[PATCH 10/46] selinux: Move some assignments for the variable "rc" in policydb_read()
From: Markus Elfring
Date: Sat, 14 Jan 2017 15:22:29 +0100
One local variable was set to an error code in some cases before
a concrete error situation was detected. Thus move the corresponding
assignments into if branches to indicate a software failure there.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 59 +-
1 file changed, 35 insertions(+), 24 deletions(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 53e6d06e772a..506b0228d1f1 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -2250,15 +2250,14 @@ int policydb_read(struct policydb *p, void *fp)
if (rc)
goto bad;
- rc = -EINVAL;
if (le32_to_cpu(buf[0]) != POLICYDB_MAGIC) {
printk(KERN_ERR "SELinux: policydb magic number 0x%x does "
"not match expected magic number 0x%x\n",
le32_to_cpu(buf[0]), POLICYDB_MAGIC);
+ rc = -EINVAL;
goto bad;
}
- rc = -EINVAL;
len = le32_to_cpu(buf[1]);
if (len != strlen(POLICYDB_STRING)) {
printk(KERN_ERR "SELinux: policydb string length %d does not "
@@ -2265,11 +2265,13 @@ int policydb_read(struct policydb *p, void *fp)
len, strlen(POLICYDB_STRING));
+ rc = -EINVAL;
goto bad;
}
- rc = -ENOMEM;
policydb_str = kmalloc(len + 1, GFP_KERNEL);
- if (!policydb_str)
+ if (!policydb_str) {
+ rc = -ENOMEM;
goto bad;
+ }
rc = next_entry(policydb_str, fp, len);
if (rc) {
@@ -2279,12 +2280,12 @@ int policydb_read(struct policydb *p, void *fp)
goto bad;
}
- rc = -EINVAL;
policydb_str[len] = '\0';
if (strcmp(policydb_str, POLICYDB_STRING)) {
printk(KERN_ERR "SELinux: policydb string %s does not match "
"my string %s\n", policydb_str, POLICYDB_STRING);
kfree(policydb_str);
+ rc = -EINVAL;
goto bad;
}
/* Done with policydb_str. */
@@ -2296,24 +2297,24 @@ int policydb_read(struct policydb *p, void *fp)
if (rc)
goto bad;
- rc = -EINVAL;
p->policyvers = le32_to_cpu(buf[0]);
if (p->policyvers < POLICYDB_VERSION_MIN ||
p->policyvers > POLICYDB_VERSION_MAX) {
printk(KERN_ERR "SELinux: policydb version %d does not match "
"my version range %d-%d\n",
le32_to_cpu(buf[0]), POLICYDB_VERSION_MIN,
POLICYDB_VERSION_MAX);
+ rc = -EINVAL;
goto bad;
}
if ((le32_to_cpu(buf[1]) & POLICYDB_CONFIG_MLS)) {
p->mls_enabled = 1;
- rc = -EINVAL;
if (p->policyvers < POLICYDB_VERSION_MLS) {
printk(KERN_ERR "SELinux: security policydb version %d "
"(MLS) not backwards compatible\n",
p->policyvers);
+ rc = -EINVAL;
goto bad;
}
}
@@ -2332,21 +2333,21 @@ int policydb_read(struct policydb *p, void *fp)
goto bad;
}
- rc = -EINVAL;
info = policydb_lookup_compat(p->policyvers);
if (!info) {
printk(KERN_ERR "SELinux: unable to find policy compat info "
"for version %d\n", p->policyvers);
+ rc = -EINVAL;
goto bad;
}
- rc = -EINVAL;
if (le32_to_cpu(buf[2]) != info->sym_num ||
le32_to_cpu(buf[3]) != info->ocon_num) {
printk(KERN_ERR "SELinux: policydb table sizes (%d,%d) do "
"not match mine (%d,%d)\n", le32_to_cpu(buf[2]),
le32_to_cpu(buf[3]),
info->sym_num, info->ocon_num);
+ rc = -EINVAL;
goto bad;
}
@@ -2365,10 +2366,11 @@ int policydb_read(struct policydb *p, void *fp)
p->symtab[i].nprim = nprim;
}
- rc = -EINVAL;
p->process_class = string_to_security_class(p, "process");
- if (!p->process_class)
+ if (!p->process_class) {
+ rc = -EINVAL;
goto bad;
+ }
rc = avtab_read(&p->te_avtab, fp, p);
if (rc)
@@ -2386,10 +2388,12 @@ int policydb_read(struct policydb *p, void *fp)
nel = le32_to_cpu(buf[0]);
ltr = NULL;
for (i = 0; i < nel; i++) {
- rc = -ENOMEM;
tr = kzalloc(sizeof(*tr), GFP_KERNEL);
- if (!tr)
+ if (!tr) {
+ rc = -ENOMEM;
goto bad;
+ }
+
if (ltr)
[PATCH 11/46] selinux: Return directly after a failed next_entry() in genfs_read()
From: Markus Elfring
Date: Sat, 14 Jan 2017 16:34:25 +0100
Return directly after a call of the function "next_entry" failed
at the beginning.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 506b0228d1f1..754f829d2027 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -2004,7 +2004,7 @@ static int genfs_read(struct policydb *p, void *fp)
rc = next_entry(buf, fp, sizeof(u32));
if (rc)
- goto out;
+ return rc;
nel = le32_to_cpu(buf[0]);
for (i = 0; i < nel; i++) {
--
2.11.0
[PATCH 12/46] selinux: Move assignments for two pointers in genfs_read()
From: Markus Elfring
Date: Sat, 14 Jan 2017 16:56:51 +0100
Move the assignment for the local variables "newc" and "newgenfs" behind
a call of the function "next_entry" at the beginning so that they will
only be set after a successful call.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 754f829d2027..7544e374dec9 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -1997,14 +1997,14 @@ static int genfs_read(struct policydb *p, void *fp)
int i, j, rc;
u32 nel, nel2, len, len2;
__le32 buf[1];
- struct ocontext *l, *c;
- struct ocontext *newc = NULL;
- struct genfs *genfs_p, *genfs;
- struct genfs *newgenfs = NULL;
+ struct ocontext *l, *c, *newc;
+ struct genfs *genfs_p, *genfs, *newgenfs;
rc = next_entry(buf, fp, sizeof(u32));
if (rc)
return rc;
+ newc = NULL;
+ newgenfs = NULL;
nel = le32_to_cpu(buf[0]);
for (i = 0; i < nel; i++) {
--
2.11.0
[PATCH 13/46] selinux: Move four assignments for the variable "rc" in genfs_read()
From: Markus Elfring
Date: Sat, 14 Jan 2017 17:21:59 +0100
One local variable was set to an error code in four cases before
a concrete error situation was detected. Thus move the corresponding
assignments into if branches to indicate a software failure there.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 7544e374dec9..a12d9166f0e4 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -2012,11 +2012,11 @@ static int genfs_read(struct policydb *p, void *fp)
if (rc)
goto out;
len = le32_to_cpu(buf[0]);
-
- rc = -ENOMEM;
newgenfs = kzalloc(sizeof(*newgenfs), GFP_KERNEL);
- if (!newgenfs)
+ if (!newgenfs) {
+ rc = -ENOMEM;
goto out;
+ }
rc = str_read(&newgenfs->fstype, GFP_KERNEL, fp, len);
if (rc)
@@ -2024,10 +2024,10 @@ static int genfs_read(struct policydb *p, void *fp)
for (genfs_p = NULL, genfs = p->genfs; genfs;
genfs_p = genfs, genfs = genfs->next) {
- rc = -EINVAL;
if (strcmp(newgenfs->fstype, genfs->fstype) == 0) {
printk(KERN_ERR "SELinux: dup genfs fstype
%s\n",
newgenfs->fstype);
+ rc = -EINVAL;
goto out;
}
if (strcmp(newgenfs->fstype, genfs->fstype) < 0)
@@ -2051,11 +2051,11 @@ static int genfs_read(struct policydb *p, void *fp)
if (rc)
goto out;
len = le32_to_cpu(buf[0]);
-
- rc = -ENOMEM;
newc = kzalloc(sizeof(*newc), GFP_KERNEL);
- if (!newc)
+ if (!newc) {
+ rc = -ENOMEM;
goto out;
+ }
rc = str_read(&newc->u.name, GFP_KERNEL, fp, len);
if (rc)
@@ -2072,12 +2072,12 @@ static int genfs_read(struct policydb *p, void *fp)
for (l = NULL, c = genfs->head; c;
l = c, c = c->next) {
- rc = -EINVAL;
if (!strcmp(newc->u.name, c->u.name) &&
(!c->v.sclass || !newc->v.sclass ||
newc->v.sclass == c->v.sclass)) {
printk(KERN_ERR "SELinux: dup genfs
entry (%s,%s)\n",
genfs->fstype, c->u.name);
+ rc = -EINVAL;
goto out;
}
len = strlen(newc->u.name);
--
2.11.0
[PATCH 14/46] selinux: One function call less in genfs_read() after null pointer detection
From: Markus Elfring
Date: Sat, 14 Jan 2017 17:43:47 +0100
Call the function "kfree" at the end only after it was determined
that the local variable "newgenfs" contained a non-null pointer.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index a12d9166f0e4..5dc31faa601f 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -2096,9 +2096,10 @@ static int genfs_read(struct policydb *p, void *fp)
}
rc = 0;
out:
- if (newgenfs)
+ if (newgenfs) {
kfree(newgenfs->fstype);
- kfree(newgenfs);
+ kfree(newgenfs);
+ }
ocontext_destroy(newc, OCON_FSUSE);
return rc;
--
2.11.0
[PATCH 15/46] selinux: One check and function call less in genfs_read() after error detection
From: Markus Elfring
Date: Sat, 14 Jan 2017 18:29:20 +0100
Adjust a jump target to avoid a check repetition at the end after a memory
allocation failed for the local variable "newgenfs".
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 5dc31faa601f..e7b882251da8 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -2015,7 +2015,7 @@ static int genfs_read(struct policydb *p, void *fp)
newgenfs = kzalloc(sizeof(*newgenfs), GFP_KERNEL);
if (!newgenfs) {
rc = -ENOMEM;
- goto out;
+ goto exit;
}
rc = str_read(&newgenfs->fstype, GFP_KERNEL, fp, len);
@@ -2101,7 +2101,7 @@ static int genfs_read(struct policydb *p, void *fp)
kfree(newgenfs);
}
ocontext_destroy(newc, OCON_FSUSE);
-
+exit:
return rc;
}
--
2.11.0
[PATCH 16/46] selinux: Move two assignments for the variable "rc" in filename_trans_read()
From: Markus Elfring
Date: Sat, 14 Jan 2017 18:50:52 +0100
One local variable was set to an error code in two cases before
a concrete error situation was detected. Thus move the corresponding
assignments into if branches to indicate a software failure there.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index e7b882251da8..106a1da1d68a 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -1930,16 +1930,17 @@ static int filename_trans_read(struct policydb *p, void
*fp)
ft = NULL;
otype = NULL;
name = NULL;
-
- rc = -ENOMEM;
ft = kzalloc(sizeof(*ft), GFP_KERNEL);
- if (!ft)
+ if (!ft) {
+ rc = -ENOMEM;
goto out;
+ }
- rc = -ENOMEM;
otype = kmalloc(sizeof(*otype), GFP_KERNEL);
- if (!otype)
+ if (!otype) {
+ rc = -ENOMEM;
goto out;
+ }
/* length of the path component string */
rc = next_entry(buf, fp, sizeof(u32));
--
2.11.0
[PATCH 17/46] selinux: Delete an unnecessary variable assignment in filename_trans_read()
From: Markus Elfring
Date: Sat, 14 Jan 2017 19:02:42 +0100
The local variable "ft" was set to a null pointer despite of an
immediate reassignment.
Thus remove this statement from the beginning of a loop.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 106a1da1d68a..2be5b18eb149 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -1927,7 +1927,6 @@ static int filename_trans_read(struct policydb *p, void
*fp)
nel = le32_to_cpu(buf[0]);
for (i = 0; i < nel; i++) {
- ft = NULL;
otype = NULL;
name = NULL;
ft = kzalloc(sizeof(*ft), GFP_KERNEL);
--
2.11.0
[PATCH 18/46] selinux: One function call less in filename_trans_read() after error detection
From: Markus Elfring
Date: Sat, 14 Jan 2017 19:19:42 +0100
Adjust a jump target to avoid a function call at the end after a memory
allocation failed for the local variable "ft".
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 2be5b18eb149..5f122e846332 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -1932,7 +1932,7 @@ static int filename_trans_read(struct policydb *p, void
*fp)
ft = kzalloc(sizeof(*ft), GFP_KERNEL);
if (!ft) {
rc = -ENOMEM;
- goto out;
+ goto free_name;
}
otype = kmalloc(sizeof(*otype), GFP_KERNEL);
@@ -1986,6 +1986,7 @@ static int filename_trans_read(struct policydb *p, void
*fp)
return 0;
out:
kfree(ft);
+free_name:
kfree(name);
kfree(otype);
--
2.11.0
[PATCH 19/46] selinux: Return directly after a failed next_entry() in range_read()
From: Markus Elfring
Date: Sat, 14 Jan 2017 19:35:59 +0100
Return directly after a call of the function "next_entry" failed
at the beginning.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 5f122e846332..a696876fc327 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -1850,7 +1850,7 @@ static int range_read(struct policydb *p, void *fp)
rc = next_entry(buf, fp, sizeof(u32));
if (rc)
- goto out;
+ return rc;
nel = le32_to_cpu(buf[0]);
for (i = 0; i < nel; i++) {
--
2.11.0
Re: [patch v2] mm, memcg: do not retry precharge charges
On Sat, Jan 14, 2017 at 09:42:48PM -0800, David Rientjes wrote: > On Sat, 14 Jan 2017, Johannes Weiner wrote: > > > The OOM killer livelock was the motivation for this patch. With that > > ruled out, what's the point of this patch? Try a bit less hard to move > > charges during task migration? > > > > Most important part is to fail ->can_attach() instead of oom killing > processes when attaching a process to a memcg hierarchy. Ah, that makes sense. Could you please update the changelog to reflect this? Thanks!
[PATCH 20/46] selinux: Move four assignments for the variable "rc" in range_read()
From: Markus Elfring
Date: Sat, 14 Jan 2017 19:55:00 +0100
One local variable was set to an error code in four cases before
a concrete error situation was detected. Thus move the corresponding
assignments into if branches to indicate a software failure there.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index a696876fc327..4cd96ce51322 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -1854,10 +1854,11 @@ static int range_read(struct policydb *p, void *fp)
nel = le32_to_cpu(buf[0]);
for (i = 0; i < nel; i++) {
- rc = -ENOMEM;
rt = kzalloc(sizeof(*rt), GFP_KERNEL);
- if (!rt)
+ if (!rt) {
+ rc = -ENOMEM;
goto out;
+ }
rc = next_entry(buf, fp, (sizeof(u32) * 2));
if (rc)
@@ -1873,24 +1874,26 @@ static int range_read(struct policydb *p, void *fp)
} else
rt->target_class = p->process_class;
- rc = -EINVAL;
if (!policydb_type_isvalid(p, rt->source_type) ||
!policydb_type_isvalid(p, rt->target_type) ||
- !policydb_class_isvalid(p, rt->target_class))
+ !policydb_class_isvalid(p, rt->target_class)) {
+ rc = -EINVAL;
goto out;
+ }
- rc = -ENOMEM;
r = kzalloc(sizeof(*r), GFP_KERNEL);
- if (!r)
+ if (!r) {
+ rc = -ENOMEM;
goto out;
+ }
rc = mls_read_range_helper(r, fp);
if (rc)
goto out;
- rc = -EINVAL;
if (!mls_range_isvalid(p, r)) {
printk(KERN_WARNING "SELinux: rangetrans: invalid
range\n");
+ rc = -EINVAL;
goto out;
}
--
2.11.0
[PATCH 21/46] selinux: Two function calls less in range_read() after error detection
From: Markus Elfring
Date: Sat, 14 Jan 2017 20:20:15 +0100
Adjust a jump target to avoid two calls of the function "kfree" at the end
after a memory allocation failed for the local variable "rt".
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 4cd96ce51322..0d2f64558c0a 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -1857,7 +1857,7 @@ static int range_read(struct policydb *p, void *fp)
rt = kzalloc(sizeof(*rt), GFP_KERNEL);
if (!rt) {
rc = -ENOMEM;
- goto out;
+ goto exit;
}
rc = next_entry(buf, fp, (sizeof(u32) * 2));
@@ -1909,6 +1909,7 @@ static int range_read(struct policydb *p, void *fp)
out:
kfree(rt);
kfree(r);
+exit:
return rc;
}
--
2.11.0
[PATCH 22/46] selinux: Delete an unnecessary variable initialisation in range_read()
From: Markus Elfring
Date: Sat, 14 Jan 2017 20:40:12 +0100
The local variable "rt" will be set to an appropriate pointer a bit later.
Thus omit the explicit initialisation at the beginning which became
unnecessary with a previous update step.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 0d2f64558c0a..6121a26ada64 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -1839,7 +1839,7 @@ u32 string_to_av_perm(struct policydb *p, u16 tclass,
const char *name)
static int range_read(struct policydb *p, void *fp)
{
- struct range_trans *rt = NULL;
+ struct range_trans *rt;
struct mls_range *r = NULL;
int i, rc;
__le32 buf[2];
--
2.11.0
[PATCH 23/46] selinux: Move an assignment for a pointer in range_read()
From: Markus Elfring
Date: Sat, 14 Jan 2017 21:00:45 +0100
Move the assignment for the local variable "r" behind a call of the
function "next_entry" at the beginning so that it will only be set
after a successful call.
Signed-off-by: Markus Elfring
---
security/selinux/ss/policydb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index 6121a26ada64..5101592ae172 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -1840,7 +1840,7 @@ u32 string_to_av_perm(struct policydb *p, u16 tclass,
const char *name)
static int range_read(struct policydb *p, void *fp)
{
struct range_trans *rt;
- struct mls_range *r = NULL;
+ struct mls_range *r;
int i, rc;
__le32 buf[2];
u32 nel;
@@ -1852,6 +1852,7 @@ static int range_read(struct policydb *p, void *fp)
if (rc)
return rc;
+ r = NULL;
nel = le32_to_cpu(buf[0]);
for (i = 0; i < nel; i++) {
rt = kzalloc(sizeof(*rt), GFP_KERNEL);
--
2.11.0
Re: Calling device_init_wakeup() on driver removal
On 01/15/2017 06:49 AM, Rafael J. Wysocki wrote: On Saturday, January 14, 2017 08:46:05 PM Guenter Roeck wrote: Hi folks, Hi, while looking through driver initialization and removal functions, I noticed that many drivers call device_init_wakeup(dev, false) in the removal function. Given that the driver is about to be removed, that doesn't make much sense to me, especially since device_wakeup_disable() is called from device_pm_remove() anyway. Is it safe to assume that all those calls can be removed, or is there a possible reason for keeping them around ? Removing them automatically might break things, because device_init_wakeup(dev, false) also clears the power.can_wakeup flag and removes the "wakeup" attribute from sysfs. I had the same concern, but I concluded that the wakeup attribute should be removed automatically, since it is added with sysfs_merge_group(), and the matching unmerge call is also made in dpm_sysfs_remove(). power.can_wakeup is part of the device structure, which is in the process of being removed, so I am not sure I understand how that can be problematic. I guess they could be removed safely in the majority of cases, though. How would one decide if it is needed ? I see some drivers call it on remove, but others don't. I don't see a clear pattern; unless I am missing something, it seems to be more or less random. Thanks, Guenter
[PATCH 24/46] selinux: Return directly after a failed kzalloc() in cat_read()
From: Markus Elfring Date: Sat, 14 Jan 2017 21:20:43 +0100 Return directly after a call of the function "kzalloc" failed at the beginning. Signed-off-by: Markus Elfring --- security/selinux/ss/policydb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c index 5101592ae172..eb898dcbe502 100644 --- a/security/selinux/ss/policydb.c +++ b/security/selinux/ss/policydb.c @@ -1635,10 +1635,9 @@ static int cat_read(struct policydb *p, struct hashtab *h, void *fp) __le32 buf[3]; u32 len; - rc = -ENOMEM; catdatum = kzalloc(sizeof(*catdatum), GFP_ATOMIC); if (!catdatum) - goto bad; + return -ENOMEM; rc = next_entry(buf, fp, sizeof buf); if (rc) -- 2.11.0
[PATCH 25/46] selinux: Return directly after a failed kzalloc() in sens_read()
From: Markus Elfring Date: Sat, 14 Jan 2017 21:42:02 +0100 Return directly after a call of the function "kzalloc" failed at the beginning. Signed-off-by: Markus Elfring --- security/selinux/ss/policydb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c index eb898dcbe502..5caa1fa5ea80 100644 --- a/security/selinux/ss/policydb.c +++ b/security/selinux/ss/policydb.c @@ -1593,10 +1593,9 @@ static int sens_read(struct policydb *p, struct hashtab *h, void *fp) __le32 buf[2]; u32 len; - rc = -ENOMEM; levdatum = kzalloc(sizeof(*levdatum), GFP_ATOMIC); if (!levdatum) - goto bad; + return -ENOMEM; rc = next_entry(buf, fp, sizeof buf); if (rc) -- 2.11.0
