Re: [PATCH v2 29/30] dt-bindings: add vendor prefix for bananapi
On Fri, 2017-04-28 at 15:37 -0500, Rob Herring wrote: > On Wed, Apr 26, 2017 at 05:26:13PM +0800, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Banana Pi team in Sinovoip Co., Limited which are dedicated to > > design and manufacture open hardware product. > > > > Website: http://www.banana-pi.org/ > > > > Signed-off-by: Sean Wang > > --- > > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > > b/Documentation/devicetree/bindings/vendor-prefixes.txt > > index ec0bfb9..8ca0f3c 100644 > > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > > @@ -44,6 +44,7 @@ avia avia semiconductor > > avic Shanghai AVIC Optoelectronics Co., Ltd. > > axentiaAxentia Technologies AB > > axis Axis Communications AB > > +bananapi Banana Pi SINOVOP CO., LIMITED > > s/SINOVOP/SINOVOIP/ Hi Rob, thanks for your careful reviewing , i will correct it in the next version. BTW, Could those related dts changes go through your tree if everything looks good? Because I find Matthias have been inactive for a while and the latest branch in his tree seems still staying on 4.10. Sean > > > boeBOE Technology Group Co., Ltd. > > bosch Bosch Sensortec GmbH > > boundary Boundary Devices Inc. > > -- > > 1.9.1 > >
linux-next: Tree for May 1
Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170428: The spi tree gained a conflict against the pm tree. The rcu tree gained a conflict against the ftrace tree. The staging tree gained a conflict against the usb tree and a build failure due to an interaction with the mac80211-next tree for which I applied a merge fix patch. Non-merge commits (relative to Linus' tree): 12193 11126 files changed, 1247850 insertions(+), 227602 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 258 trees (counting Linus' and 37 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (97ce89f8a4eb Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (97da3854c526 Linux 4.11-rc3) Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading parentheses around a condition) Merging arc-current/for-curr (36b5a5152119 arc: axs10x: Fix ARC PGU default clock frequency) Merging arm-current/fixes (6d8059493691 ARM: 8670/1: V7M: Do not corrupt vector table around v7m_invalidate_l1 call) Merging m68k-current/for-linus (e3b1ebd67387 m68k: Wire up statx) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE with CONFIG_RELOCATABLE=y) Merging sparc/master (f83246089ca0 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (0060e79a1f52 Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux) Merging ipsec/master (cfcf99f987ba xfrm: fix GRO for !CONFIG_NETFILTER) Merging netfilter/master (1519fccb3437 netfilter: update MAINTAINERS file) Merging ipvs/master (1442f6f7c1b7 ipvs: explicitly forbid ipv6 service/dest creation if ipv6 mod is disabled) Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype avoiding use-after-free of virtual interface) Merging mac80211/master (f83246089ca0 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging sound-current/for-linus (d4a2fbcee0c8 Merge tag 'asoc-fix-v4.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (b9c1153f7a9c PCI: hisi: Fix DT binding (hisi-pcie-almost-ecam)) Merging driver-core.current/driver-core-linus (39da7c509acf Linux 4.11-rc6) Merging tty.current/tty-linus (4f7d029b9bf0 Linux 4.11-rc7) Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5) Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't access hidg->req without spinlock held) Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4) Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file) Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON) Merging staging.current/staging-linus (39da7c509acf Linux 4.11-rc6) Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4) Merging input-current/for-linus (7c5bb4ac2b76 Input: i8042 - add Clevo P650RS to the i8042 reset list) Merging crypto-current/master (e6534aebb26e crypto: algif_aead - Fix bogus request de
Re: [PATCH v2 02/30] pinctrl: mediatek: reuse pinctrl driver for mt7623
On Fri, 2017-04-28 at 10:01 +0200, Linus Walleij wrote: > On Wed, Apr 26, 2017 at 11:25 AM, wrote: > > > From: Sean Wang > > > > mt7623 pinctrl driver can be compatible with mt2701 one, > > so the patch reuses the driver and deletes those redundant > > ones. > > > > Cc: John Crispin > > Signed-off-by: Sean Wang > > Partly correct. > > > "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl. > > - "mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl. > > NO don't do this. > > "compatible" means exactly this: this hardware is compatible with > this driver. That is why we have it! > > So instead of mt7623 pretending to be mt2701, let the mt2701 driver > list that it is compatible with mt7623, simple. > > So patch pinctrl-mt2701.c mt2701_pctrl_match[] instead. > Hi Linus, really appreciate your clear guidance and reviewing on this I will fix it up in the next version Sean > Yours, > Linus Walleij
I'd like to donate a MacBook Pro
Dear kernel developers, I have a MacBookPro12,1 A1502 with a very annoying problem. Every time it boots, the screen stays black for about 90 seconds, and the keyboard is unresponsive for an additional 40 seconds. Both the internal keyboard and (if present) external USB keyboard are unresponsive. This is a big problem because I use LUKS full-disk encryption, and I can't put in the password without the keyboard working. On every boot, I get something like: starting version 232 A password is required to access the cryptroot volume: Enter passphrase for /dev/sda4: [ 13.697887] usb 2-3: device not accepting address 2, error -62 [ 24.790929] usb2-3: device not accepting address 3, error -62 [ 36.097301] usb2-3: device not accepting address 4, error -62 [ 47.403659] usb2-3: device not accepting address 5, error -62 [ 47.430395] usb2-port3: unable to enumerate USB device After the final error message, the keyboard starts working and I can input my password. The dmesg log contains an additional error, "xhci_hcd :00:14.0: Timeout while waiting for setup device command", interspersed with the "device not accepting address" errors. Resetting the SMC and the NVRAM did not help. I am confident that this is a common problem because I have found various other users complaining about it: https://bbs.archlinux.org/viewtopic.php?pid=1613363#p1613363 https://bbs.archlinux.org/viewtopic.php?pid=1451053#p1451053 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1668105 https://bugzilla.kernel.org/show_bug.cgi?id=115741 Mine is an older MacBook model that is not prohibitively expensive (about 400 USD). Do any of you think that you can fix this bug? If so, I would love to set up an identical model with an identical Arch Linux configuration to my own and send it to you to keep and debug. -Alex
Re: [PATCH 1/2] Add support for OneWire (W1) devices family 0x26 (MAX17211/MAX17215)
Hi! 30.04.17 23:53, Sebastian Reichel wrote:: Slave device provide software layer for access to internal registers MAX17211/MAX17215 chip. Please convert this to regmap.There is no generic w1 handler, but you can provide custom read/write functions. I think regmap be overkill for this driver. the perception. I did not ask for full usage of all regmap features. Just register the read/write handler as regmap handler and use regmap_read/write to get values. OK, I think about this. But max17211-battery use ONLY w1_max12711x_reg_get(). This is very simple function. Second function w1_max1721x_reg_set() writen for extend feature list (factory calibrating and init battery). I think, this code must _NOT_ be writen, and must _NOT_ be accessible for end user. Change calibration values potentially can damage battery or device. Theory, I can unexport this function and remove them from drivers code. So output registers of Maxim M5 Fuel Gauge algorithm very simple: one register - one value. In driver I have two points with bitfield. First - battery connected from power supply props. Second: very optional device type from probe. This value _NOT_ used from driver - just write device type, if manufacturer not fill this data in chip nvram. This moment driver use 14 registers. Ok, let's some time above will be 14*3=42 registers accessible with w1_max1721x_reg_get(). This value is greatly overestimated - so many properties are not in the class POWER_SUPPLY. But register range in MAX1721X is 0x1F0 (496 words or 992 bytes) of RAM for cache registers. As embedded system developer I dislike so ram management. As result I repeat: regmap will be overkill for this driver. But OK, I try to write this code. Just for fun.
Re: [PATCH 2/2] dmaengine: Add STM32 MDMA driver
On Wed, Apr 26, 2017 at 12:35:46PM +, Pierre Yves MORDRET wrote:
> On 04/06/2017 09:08 AM, Vinod Koul wrote:
> >> +static int stm32_mdma_get_width(struct stm32_mdma_chan *chan,
> >> + enum dma_slave_buswidth width)
> >> +{
> >> + switch (width) {
> >> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
> >> + return STM32_MDMA_BYTE;
> >> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> >> + return STM32_MDMA_HALF_WORD;
> >> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> >> + return STM32_MDMA_WORD;
> >> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> >> + return STM32_MDMA_DOUBLE_WORD;
> >
> > IIUC we can do this with ffs()
>
> I don't believe we can do that. This function translates DMA_SLAVE enum
> into internal register representation.
Yes and internal represenation seemed to be ffs() of dmanegine one.
> >> +subsys_initcall(stm32_mdma_init);
> >
> > why subsys?
> >
>
> subsys_initcall level is to ensure MDMA is going to be probed before its
> clients
Please use deffered probe approach for that
--
~Vinod
Re: [PATCH 2/5] dmaengine: Add STM32 DMAMUX driver
On Wed, Apr 26, 2017 at 09:17:37AM +, Pierre Yves MORDRET wrote:
> >> +
> >> + ret = of_property_read_u32(node, "dma-channels",
> >> + &dmamux->dmamux_channels);
> >
> > can we have property_xxx calls alone, that way driver is not strictly
> > dependent on of
>
> Can you please explain what you are asking for ? Not sure to understand
> correctly.
Use device_property_read_u32() which is a generic property API.
> >> +static int __init stm32_dmamux_init(void)
> >> +{
> >> + return platform_driver_register(&stm32_dmamux_driver);
> >> +}
> >> +arch_initcall(stm32_dmamux_init);
> >
> > why not module init, wouldnt defer probe solve the dependencies
> >
>
> The reason behind many devices (device_initcall level) rely on DMAs. If
> init is deferred DMAMUX driver will be probed twice if dependents rely
> on it. This sounds not a good call. This explains arch_initcall level.
Why not deferred probe was introduced to help with dependencies...
--
~Vinod
[GIT PULL] hwmon updates for v4.12
Hi Linus, Please pull hwmon updates for Linux v4.12 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus-v4.12 Thanks, Guenter -- The following changes since commit c02ed2e75ef4c74e41e421acb4ef1494671585e8: Linux 4.11-rc4 (2017-03-26 14:15:16 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git tags/hwmon-for-linus-v4.12 for you to fetch changes up to 09d9d82745801ca69c00f91f89c8f047b586e8cc: hwmon: (twl4030-madc) drop driver (2017-04-30 11:45:31 -0700) hwmon updates for v4.12 Removed twl4030-madc driver Various minor improvements and fixes in several drivers Chris Packham (2): docs: hwmon: Fix typo "Microship" should be "Microchip" hwmon: (adt7475) set start bit in probe Jaghathiswari Rankappagounder Natarajan (2): Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver drivers: hwmon: Support for ASPEED PWM/Fan tach Javier Martinez Canillas (21): hwmon: (ad7414) Add OF device ID table hwmon: (adc128d818) Add OF device ID table hwmon: (ads1015) Add OF device ID table hwmon: (ads7828) Add OF device ID table hwmon: (adt7475) Add OF device ID table hwmon: (ina209) Add OF device ID table hwmon: (ina2xx) Add OF device ID table hwmon: (lm63) Add OF device ID table hwmon: (lm75) Add OF device ID table hwmon: (lm85) Add OF device ID table hwmon: (lm90) Add OF device ID table hwmon: (lm95245) Add OF device ID table hwmon: (max6697) Add OF device ID table hwmon: (ucd9000) Add OF device ID table hwmon: (ucd9200) Add OF device ID table hwmon: (stts751) Add OF device ID table hwmon: (tmp102) Add OF device ID table hwmon: (tmp103) Add OF device ID table hwmon: (tmp421) Add OF device ID table hwmon: (lm87) Remove unused I2C devices driver_data hwmon: (lm87) Add OF device ID table Jean Delvare (1): hwmon: Constify str parameter of hwmon_ops->read_string Joe Schaack (1): hwmon: (ina209) Handled signed registers Katsumi Sato (1): hwmon: (w83627ehf) Use request_muxed_region Mahoda Ratnayaka (2): Documentation: dtb: lm87: Add hwmon binding documentation hwmon: (lm87) Allow channel data to be set from dts file Marco Franchi (1): dt: Add vendor prefix for Sensirion Pali Rohár (1): hwmon: (dell-smm) Add Dell XPS 15 9560 into DMI list Rahul Bedarkar (1): hwmon: (tmp103) Use SIMPLE_DEV_PM_OPS helper macro Sam Povilus (1): hwmon: (ads7828) Accept optional parameters from device tree Sebastian Reichel (1): hwmon: (twl4030-madc) drop driver Shikhar Dogra (1): driver: (adm1275) set the m,b and R coefficients correctly for power .../devicetree/bindings/hwmon/ads7828.txt | 25 + .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 68 ++ Documentation/devicetree/bindings/hwmon/lm87.txt | 30 + .../devicetree/bindings/vendor-prefixes.txt| 1 + Documentation/hwmon/aspeed-pwm-tacho | 22 + Documentation/hwmon/tc654 | 2 +- drivers/hwmon/Kconfig | 19 +- drivers/hwmon/Makefile | 2 +- drivers/hwmon/ad7414.c | 7 + drivers/hwmon/adc128d818.c | 7 + drivers/hwmon/ads1015.c| 22 +- drivers/hwmon/ads7828.c| 39 +- drivers/hwmon/adt7475.c| 44 +- drivers/hwmon/aspeed-pwm-tacho.c | 835 + drivers/hwmon/dell-smm-hwmon.c | 7 + drivers/hwmon/hwmon.c | 2 +- drivers/hwmon/ina209.c | 11 +- drivers/hwmon/ina2xx.c | 35 +- drivers/hwmon/lm63.c | 23 + drivers/hwmon/lm75.c | 98 ++- drivers/hwmon/lm85.c | 56 +- drivers/hwmon/lm87.c | 37 +- drivers/hwmon/lm90.c | 100 ++- drivers/hwmon/lm95245.c| 8 + drivers/hwmon/max6697.c| 52 +- drivers/hwmon/pmbus/adm1275.c | 4 +- drivers/hwmon/pmbus/ucd9000.c | 39 +- drivers/hwmon/pmbus/ucd9200.c | 48 +- drivers/hwmon/stts751.c| 7 + drivers/hwmon/tmp102.c | 7 + drivers/hwmon/tmp103.c | 24 +- drivers/hwmon/tmp421.c | 35 +- drivers/hwmon/twl4030-madc-hw
Re: [PATCH] Allow to use DMA_CTRL_REUSE flag for all channel types
On Fri, Apr 28, 2017 at 04:37:46PM +0300, Eugeniy Paltsev wrote:
> In the current implementation dma_get_slave_caps is used to check
> state of descriptor_reuse option. But dma_get_slave_caps includes
> check if the channel supports slave transactions.
> So DMA_CTRL_REUSE flag can be set (even for MEM-TO-MEM tranfers)
> only if channel supports slave transactions.
>
> Now we can use DMA_CTRL_REUSE flag for all channel types.
> Also it allows to test reusing mechanism with simply mem-to-mem dma
> test.
We do not want to allow that actually. Slave is always treated as a special
case, so resue was allowed.
With memcpy the assumptions are different and clients can do reuse.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> include/linux/dmaengine.h | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 5336808..92cf8b0 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -1376,11 +1376,7 @@ static inline int dma_get_slave_caps(struct dma_chan
> *chan,
>
> static inline int dmaengine_desc_set_reuse(struct dma_async_tx_descriptor
> *tx)
> {
> - struct dma_slave_caps caps;
> -
> - dma_get_slave_caps(tx->chan, &caps);
> -
> - if (caps.descriptor_reuse) {
> + if (tx->chan->device->descriptor_reuse) {
> tx->flags |= DMA_CTRL_REUSE;
> return 0;
> } else {
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
~Vinod
[PATCH man-pages 1/5] ioctl_userfaultfd.2: update description of shared memory areas
Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 889feb9..6edd396 100644 --- a/man2/ioctl_userfaultfd.2 +++ b/man2/ioctl_userfaultfd.2 @@ -181,8 +181,17 @@ virtual memory areas .TP .B UFFD_FEATURE_MISSING_SHMEM If this feature bit is set, -the kernel supports registering userfaultfd ranges on tmpfs -virtual memory areas +the kernel supports registering userfaultfd ranges on shared memory areas. +This includes all kernel shared memory APIs: +System V shared memory, +tmpfs, +/dev/zero, +.BR mmap(2) +with +.I MAP_SHARED +flag set, +.BR memfd_create (2), +etc. The returned .I ioctls -- 1.9.1
[PATCH man-pages 3/5] ioctl_userfaultfd.2: add BUGS section
The features handshake is not quite convenient. Elaborate about it in the BUGS section. Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 9 + 1 file changed, 9 insertions(+) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index e12b9de..50316de 100644 --- a/man2/ioctl_userfaultfd.2 +++ b/man2/ioctl_userfaultfd.2 @@ -650,6 +650,15 @@ operations are Linux-specific. .SH EXAMPLE See .BR userfaultfd (2). +.SH BUGS +In order to detect available userfault features and +enable certain subset of those features +the usefault file descriptor must be closed after the first +.BR UFFDIO_API +operation that queries features availability and re-opened before +the second +.BR UFFDIO_API +call that actually enables the desired features. .SH SEE ALSO .BR ioctl (2), .BR mmap (2), -- 1.9.1
[PATCH man-pages 5/5] userfaultfd.2: update VERSIONS section with 4.11 chanegs
Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index f177bba..07a69f1 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -404,6 +404,9 @@ Insufficient kernel memory was available. The .BR userfaultfd () system call first appeared in Linux 4.3. + +The support for hugetlbfs and shared memory areas and +non-page-fault events was added in Linux 4.11 .SH CONFORMING TO .BR userfaultfd () is Linux-specific and should not be used in programs intended to be -- 1.9.1
[PATCH man-pages 2/5] ioctl_userfaultfd.2: UFFDIO_COPY: add ENOENT and ENOSPC description
Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 13 + 1 file changed, 13 insertions(+) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 6edd396..e12b9de 100644 --- a/man2/ioctl_userfaultfd.2 +++ b/man2/ioctl_userfaultfd.2 @@ -481,6 +481,19 @@ was invalid. An invalid bit was specified in the .IR mode field. +.TP +.B ENOENT +(Since Linux 4.11) +The faulting process has changed +its virtual memory layout simultaneously with outstanding +.I UFFDIO_COPY +operation. +.TP +.B ENOSPC +(Since Linux 4.11) +The faulting process has exited at the time of +.I UFFDIO_COPY +operation. .\" .SS UFFDIO_ZEROPAGE (Since Linux 4.3.) -- 1.9.1
[PATCH man-pages 0/5] {ioctl_}userfaultfd.2: yet another update
Hi Michael, These updates pretty much complete the coverage of 4.11 additions, IMHO. Mike Rapoport (5): ioctl_userfaultfd.2: update description of shared memory areas ioctl_userfaultfd.2: UFFDIO_COPY: add ENOENT and ENOSPC description ioctl_userfaultfd.2: add BUGS section userfaultfd.2: add note about asynchronios events delivery userfaultfd.2: update VERSIONS section with 4.11 chanegs man2/ioctl_userfaultfd.2 | 35 +-- man2/userfaultfd.2 | 15 +++ 2 files changed, 48 insertions(+), 2 deletions(-) -- 1.9.1
[PATCH man-pages 4/5] userfaultfd.2: add note about asynchronios events delivery
Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 12 1 file changed, 12 insertions(+) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index 8b89162..f177bba 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -112,6 +112,18 @@ created for the child process, which allows userfaultfd monitor to perform user-space paging for the child process. +Unlike page faults which have to be synchronous and require +explicit or implicit wakeup, +all other events are delivered asynchronously and +the non-cooperative process resumes execution as +soon as manager executes +.BR read(2). +The userfaultfd manager should carefully synchronize calls +to UFFDIO_COPY with the events processing. + +The current asynchronous model of the event delivery is optimal for +single threaded non-cooperative userfaultfd manager implementations. + .\" FIXME elaborate about non-cooperating mode, describe its limitations .\" for kernels before 4.11, features added in 4.11 .\" and limitations remaining in 4.11 -- 1.9.1
Re: [PATCH 0/3] TI-SoC-thermal: Fine-tuning for two functions
On Thursday 27 April 2017 09:50 PM, Eduardo Valentin wrote: > On Wed, Apr 26, 2017 at 05:33:10PM +0200, SF Markus Elfring wrote: >> From: Markus Elfring >> Date: Wed, 26 Apr 2017 17:24:56 +0200 >> >> Three update suggestions were taken into account >> from static source code analysis. >> >> Markus Elfring (3): >> Use devm_kcalloc() in ti_bandgap_build() >> Delete error messages for failed memory allocations in ti_bandgap_build() >> Fix a typo in a comment line >> > > Keerthy, > > Can you please give it a shot of this series on all supported OMAP chip > boards? I do not see any major issue with the series at all, but would > like to get it tested by you. Sure Eduardo. I will test and review this series. > > BR, > >> drivers/thermal/ti-soc-thermal/ti-bandgap.c | 14 +- >> 1 file changed, 5 insertions(+), 9 deletions(-) >> >> -- >> 2.12.2 >>
Re: new ...at() flag: AT_NO_JUMPS
On Sun, Apr 30, 2017 at 09:52:37PM -0700, Andy Lutomirski wrote: > On Sun, Apr 30, 2017 at 9:10 AM, Al Viro wrote: > > On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > > > >> It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. > > > > I considered AT_ROACH_MOTEL at one point... Another interesting > > question is whether EXDEV would've been better than ELOOP. > > Opinions? > > In support of my homeland, I propose AT_HOTEL_CALIFORNIA. > > How about EXDEV for crossing a mountpoint and ELOOP for absolute > symlinks or invalid ..? (Is there a technical reason why the same AT_ > flag should trigger both cases?) You do realize that mount --bind can do everything absolute symlinks could, right? And absolute symlinks most likely do lead to (or at least through) a different fs...
Re: [PATCH 02/11] blk: make the bioset rescue_workqueue optional.
On Mon, Apr 24 2017, Christoph Hellwig wrote: > On Mon, Apr 24, 2017 at 11:51:01AM +1000, NeilBrown wrote: >> >> I was following the existing practice exemplified by >> bioset_create_nobvec(). > > Which is pretty ugly to start with.. That is a matter of personal taste. As such, it is up to the maintainer to change it if they want it changed. > >> By not changing the signature of the function, I can avoid touching >> quite a few places where it is called. > > There are 13 callers of bioset_create and one caller of > bioset_create_nobvec, and your series touches many of those. > > So just adding a flags argument to bioset_create and passing > BIOSET_NEED_BVECS and BIOSET_NEED_RESUER flags to it doesn't seem > to much of an effort, and it's going to create a much nicer and easier > to extend interface. If someone else submitted a patch to discard bioset_create_nobvec in favour of BIOSET_NEED_BVECS and got it accepted, then I would rebase my series on that. As it is, I'm basing my patches on the style currently present in the tree. Of course, if Jens says he'll only take my patches if I change to style to match your preference, I'll do that. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH v7] Input: psxpad-spi - Add PlayStation 1/2 joypads via SPI interface Driver
Mr.Torokhov I fixed source, and sent PATCH v7 to you. I'm sorry to occars warnings. * In function 'psxpad_spi_probe', removed uninitialized value 'err' in dev_err(). * 'psxpad_spi_resume' restored. Regards. -- Tomohiro
linux-next: build warning after merge of the cgroup tree
Hi Tejun,
After merging the cgroup tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
kernel/cgroup/cgroup.c:439:13: warning: 'cgroup_get' defined but not used
[-Wunused-function]
static void cgroup_get(struct cgroup *cgrp)
^
Introduced by commit
a590b90d472f ("cgroup: fix spurious warnings on cgroup_is_dead() from
cgroup_sk_alloc()")
CONFIG_SOCK_CGROUP_DATA is not set for this build.
--
Cheers,
Stephen Rothwell
Re: [PATCH 0/2] arm64: Workaround for Thunder KVM hang issues.
On 04/24/2017 02:42 PM, David Daney wrote: > We have discovered in rare circumstances, guest execution may result > in host not receiving one or more interrupts. This does not otherwise > affect guest or host execution and/or isolation. Thanks David. I have tested these and can confirm that a 4.11 machine previously experiencing an issue has stable VMs with these. Tested-by: Jon Masters
Re: new ...at() flag: AT_NO_JUMPS
On Sun, Apr 30, 2017 at 9:10 AM, Al Viro wrote: > On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > >> It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. > > I considered AT_ROACH_MOTEL at one point... Another interesting > question is whether EXDEV would've been better than ELOOP. > Opinions? In support of my homeland, I propose AT_HOTEL_CALIFORNIA. How about EXDEV for crossing a mountpoint and ELOOP for absolute symlinks or invalid ..? (Is there a technical reason why the same AT_ flag should trigger both cases?) --Andy
linux-next: build failure after merge of the staging tree
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function
'rtw_cfg80211_indicate_connect':
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:552:6: error: passing
argument 2 of 'cfg80211_roamed' from incompatible pointer type
[-Werror=incompatible-pointer-types]
, notify_channel
^
In file included from
drivers/staging/rtl8723bs/include/osdep_service_linux.h:50:0,
from drivers/staging/rtl8723bs/include/osdep_service.h:23,
from drivers/staging/rtl8723bs/include/drv_types.h:29,
from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:17:
include/net/cfg80211.h:5435:6: note: expected 'struct cfg80211_roam_info *' but
argument is of type 'struct ieee80211_channel *'
void cfg80211_roamed(struct net_device *dev, struct cfg80211_roam_info *info,
^
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:553:6: warning: passing
argument 3 of 'cfg80211_roamed' makes integer from pointer without a cast
[-Wint-conversion]
, cur_network->network.MacAddress
^
In file included from
drivers/staging/rtl8723bs/include/osdep_service_linux.h:50:0,
from drivers/staging/rtl8723bs/include/osdep_service.h:23,
from drivers/staging/rtl8723bs/include/drv_types.h:29,
from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:17:
include/net/cfg80211.h:5435:6: note: expected 'gfp_t {aka unsigned int}' but
argument is of type 'unsigned char *'
void cfg80211_roamed(struct net_device *dev, struct cfg80211_roam_info *info,
^
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:551:3: error: too many
arguments to function 'cfg80211_roamed'
cfg80211_roamed(padapter->pnetdev
^
In file included from
drivers/staging/rtl8723bs/include/osdep_service_linux.h:50:0,
from drivers/staging/rtl8723bs/include/osdep_service.h:23,
from drivers/staging/rtl8723bs/include/drv_types.h:29,
from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:17:
include/net/cfg80211.h:5435:6: note: declared here
void cfg80211_roamed(struct net_device *dev, struct cfg80211_roam_info *info,
^
Caused by commit
554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
interacting with commit
29ce6ecbb83c ("cfg80211: unify cfg80211_roamed() and cfg80211_roamed_bss()")
from the mac80211-next tree.
I applied the following merge fix patch.
From: Stephen Rothwell
Date: Mon, 1 May 2017 14:34:17 +1000
Subject: [PATCH] staging: rtl8723bs: fix up for cfg80211_roamed() API change
Signed-off-by: Stephen Rothwell
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f092a72bffda..5e7a61f24f8d 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -542,20 +542,24 @@ void rtw_cfg80211_indicate_connect(struct adapter
*padapter)
struct ieee80211_channel *notify_channel;
u32 freq;
u16 channel = cur_network->network.Configuration.DSConfig;
+ struct cfg80211_roam_info roam_info = {};
freq = rtw_ieee80211_channel_to_frequency(channel,
NL80211_BAND_2GHZ);
notify_channel = ieee80211_get_channel(wiphy, freq);
DBG_871X(FUNC_ADPT_FMT" call cfg80211_roamed\n",
FUNC_ADPT_ARG(padapter));
- cfg80211_roamed(padapter->pnetdev
- , notify_channel
- , cur_network->network.MacAddress
- , pmlmepriv->assoc_req+sizeof(struct
ieee80211_hdr_3addr)+2
- , pmlmepriv->assoc_req_len-sizeof(struct
ieee80211_hdr_3addr)-2
- , pmlmepriv->assoc_rsp+sizeof(struct
ieee80211_hdr_3addr)+6
- , pmlmepriv->assoc_rsp_len-sizeof(struct
ieee80211_hdr_3addr)-6
- , GFP_ATOMIC);
+ roam_info.channel = notify_channel;
+ roam_info.bssid = cur_network->network.MacAddress;
+ roam_info.req_ie =
+ pmlmepriv->assoc_req+sizeof(struct
ieee80211_hdr_3addr)+2;
+ roam_info.req_ie_len =
+ pmlmepriv->assoc_req_len-sizeof(struct
ieee80211_hdr_3addr)-2;
+ roam_info.resp_ie =
+ pmlmepriv->assoc_rsp+sizeof(struct
ieee80211_hdr_3addr)+6;
+ roam_info.resp_ie_len =
+ pmlmepriv->assoc_rsp_len-sizeof(struct
ieee80211_hdr_3addr)-6;
+ cfg80211_roamed(padapter->pnetdev, &roam_info, GFP_ATOMIC);
}
else
{
--
2.11.0
--
Cheers,
Stephen Rothwell
[GIT PULL] EDAC queue for 4.12
Hi Linus, here's the EDAC pile for 4.12. Please pull, thanks. -- The following changes since commit 819f60fb7db169d851186d04e571e9bca27321e8: EDAC, pnd2_edac: Fix reported DIMM number (2017-03-26 09:36:28 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_for_4.12 for you to fetch changes up to f8d5549df25e3961d6bd2ae36d3e0b08614660d9: EDAC, ghes: Do not enable it by default (2017-04-27 14:15:38 +0200) * An EDAC driver for Cavium ThunderX RAS IP (Sergey Temerkhanov) * Removal of DRAM error reporting through PCI SERR NMI (Borislav Petkov) * Misc small fixes (Jan Glauber, Thor Thayer) Borislav Petkov (12): EDAC, highbank: Align Makefile directives x86/nmi, EDAC: Get rid of DRAM error reporting thru PCI SERR NMI EDAC: Get rid of edac_handlers EDAC: Remove edac_err_assert EDAC: Move edac_op_state to edac_mc.c ACPI/extlog: Add EDAC dependency EDAC: Issue tracepoint only when it is defined EDAC: Remove EDAC_MM_EDAC EDAC: Update Kconfig help text EDAC: Delete edac_stub.c EDAC: Rename report status accessors EDAC, ghes: Do not enable it by default Jan Glauber (1): EDAC, thunderx: Fix L2C MCI interrupt disable Sergey Temerkhanov (3): EDAC, thunderx: Add Cavium ThunderX EDAC driver EDAC, thunderx: Change LMC index calculation EDAC, thunderx: Remove unused code Thor Thayer (1): EDAC, altera: Fix peripheral warnings for Cyclone5 MAINTAINERS |1 + arch/arm/configs/multi_v7_defconfig |1 - arch/arm/configs/pxa_defconfig |3 +- arch/powerpc/configs/85xx-hw.config |3 +- arch/powerpc/configs/85xx/ge_imp3a_defconfig|1 - arch/powerpc/configs/85xx/xes_mpc85xx_defconfig |1 - arch/powerpc/configs/cell_defconfig |1 - arch/powerpc/configs/pasemi_defconfig |1 - arch/powerpc/configs/ppc64_defconfig|1 - arch/powerpc/configs/ppc64e_defconfig |1 - arch/powerpc/configs/ppc6xx_defconfig |3 +- arch/tile/configs/tilegx_defconfig |1 - arch/tile/configs/tilepro_defconfig |1 - arch/x86/kernel/nmi.c | 11 - drivers/acpi/Kconfig|3 +- drivers/acpi/acpi_extlog.c |8 +- drivers/edac/Kconfig| 129 +- drivers/edac/Makefile |8 +- drivers/edac/altera_edac.c | 22 +- drivers/edac/edac_mc.c | 99 +- drivers/edac/edac_stub.c| 68 - drivers/edac/pnd2_edac.c|2 +- drivers/edac/sb_edac.c |4 +- drivers/edac/skx_edac.c |2 +- drivers/edac/thunderx_edac.c| 2174 +++ include/linux/edac.h| 30 +- 26 files changed, 2343 insertions(+), 236 deletions(-) delete mode 100644 drivers/edac/edac_stub.c create mode 100644 drivers/edac/thunderx_edac.c -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
linux-next: manual merge of the staging tree with the usb tree
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in:
drivers/staging/Makefile
between commit:
f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
from the usb tree and commit:
051420a997a5 ("staging: bcm2835-audio: Move driver under vc04_services")
abefd6741d54 ("staging: ccree: introduce CryptoCell HW driver")
from the staging tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/staging/Makefile
index 682127c20da5,422fae4ea0f3..
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@@ -41,4 -42,5 +43,4 @@@ obj-$(CONFIG_MOST)+= most
obj-$(CONFIG_KS7010) += ks7010/
obj-$(CONFIG_GREYBUS) += greybus/
obj-$(CONFIG_BCM2835_VCHIQ) += vc04_services/
- obj-$(CONFIG_SND_BCM2835) += bcm2835-audio/
+ obj-$(CONFIG_CRYPTO_DEV_CCREE)+= ccree/
-
Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference
On 30/04/17 05:14 PM, Jerome Glisse wrote: > HMM ZONE_DEVICE pages are use like other pages (anonymous or file back page) > in _any_ vma. So i need to know when a page is freed ie either as result of > unmap, exit or migration or anything that would free the memory. For zone > device a page is free once its refcount reach 1 so i need to catch refcount > transition from 2->1 > > This is the only way i can inform the device that the page is now free. See > > https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-v21&id=52da8fe1a088b87b5321319add79e43b8372ed7d > > There is _no_ way around that. I had a similar issue in a piece of my p2pmem RFC [1]. I hacked around it by tracking the pages separately and freeing them when the vma is closed. This is by no means a great solution, it certainly has it's own warts. However, maybe it will spark some ideas for some alternate choices which avoid the hot path. Another thing I briefly looked at was hooking the vma close process earlier so that it would callback in time that you can loop through the pages and do your free process. Of course this all depends on the vma not getting closed while the pages have other references. So it may not work at all. Again, just ideas. Logan [1] https://github.com/sbates130272/linux-p2pmem/commit/77c631d92cb5c451c9824b3a4cf9b6cddfde6bb7
[git pull] uaccess-related bits of vfs.git
uaccess unification pile. It's _not_ the end of uaccess work, but
the next batch of that will go into the next cycle. This one mostly takes
copy_from_user() and friends out of arch/* and gets the zero-padding behaviour
in sync for all architectures.
Dealing with the nocache/writethrough mess is for the next cycle;
fortunately, that's x86-only. Same for cleanups in iov_iter.c (I am sold on
access_ok() in there, BTW; just not in this pile), same for reducing __copy_...
callsites, strn*... stuff, etc. - there will be a pile about as large as this
one in the next merge window.
This one sat in -next for weeks. -3KLoC. One trivial conflict in
arch/sparc/Kconfig - this series takes HAVE_ARCH_HARDENED_USERCOPY out,
and mainline has renaming of PROVE_LOCKING_SMALL to LOCKDEP_SMALL done in
the next line.
Please, pull. There's other stuff in vfs.git, but this is the
most massive one this cycle, so other pull requests will be smaller.
I apologize for the topology of this one - it's a common stem +
per-architecture branches + merge joining those + short tail after that.
Ugly, but I wanted to make it less painful in terms of conflicts with
arch trees...
The following changes since commit b884a190afcecdbef34ca508ea5ee88bb7c77861:
metag/usercopy: Add missing fixups (2017-04-05 15:25:07 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.uaccess
for you to fetch changes up to 2fefc97b2180518bac923fba3f79fdca1f41dc15:
HAVE_ARCH_HARDENED_USERCOPY is unconditional now (2017-04-26 12:11:06 -0400)
Al Viro (99):
uaccess: move VERIFY_{READ,WRITE} definitions to linux/uaccess.h
uaccess: drop duplicate includes from asm/uaccess.h
uaccess: drop pointless ifdefs
add asm-generic/extable.h
new helper: uaccess_kernel()
asm-generic/uaccess.h: don't mess with __copy_{to,from}_user
asm-generic: zero in __get_user(), not __get_user_fn()
generic ...copy_..._user primitives
alpha: switch __copy_user() and __do_clean_user() to normal calling
conventions
alpha: add asm/extable.h
alpha: get rid of 'segment' argument of __{get,put}_user_check()
alpha: don't bother with __access_ok() in traps.c
alpha: kill the 'segment' argument of __access_ok()
alpha: add a helper for emitting exception table entries
alpha: switch to RAW_COPY_USER
arc: get rid of unused declaration
arm: switch to generic extable.h
arm: switch to RAW_COPY_USER
arm64: add extable.h
avr32: switch to generic extable.h
arm64: switch to RAW_COPY_USER
avr32: switch to RAW_COPY_USER
blackfin: switch to generic extable.h
bfin: switch to RAW_COPY_USER
c6x: remove duplicate definition of __access_ok
c6x: switch to RAW_COPY_USER
cris: switch to generic extable.h
cris: don't rely upon __copy_user_zeroing() zeroing the tail
cris: get rid of zeroing in __asm_copy_from_user_N for N > 4
cris: get rid of zeroing
cris: rename __copy_user_zeroing to __copy_user_in
cris: switch to RAW_COPY_USER
frv: switch to use of fixup_exception()
frv: switch to RAW_COPY_USER
8300: switch to RAW_COPY_USER
m32r: switch to generic extable.h
m32r: get rid of zeroing
m68k: switch to generic extable.h
m68k: get rid of zeroing
m68k: switch to RAW_COPY_USER
metag: switch to generic extable.h
metag: kill verify_area()
microblaze: switch to generic extable.h
mn10300: switch to generic extable.h
mn10300: get rid of zeroing
mn10300: switch to RAW_COPY_USER
nios2: switch to generic extable.h
nios2: switch to RAW_COPY_USER
openrisc: switch to generic extable.h
openrisc: switch to RAW_COPY_USER
powerpc: switch to extable.h
s390: switch to extable.h
score: switch to generic extable.h
score: it's "VERIFY_WRITE", not "VERFITY_WRITE"...
score: switch to RAW_COPY_USER
sh: switch to extable.h
sh: switch to RAW_COPY_USER
sparc32: kill __ret_efault()
tile: switch to generic extable.h
tile: get rid of zeroing, switch to RAW_COPY_USER
um: switch to RAW_COPY_USER
amd64: get rid of zeroing
unicore32: get rid of zeroing and switch to RAW_COPY_USER
kill __copy_from_user_nocache()
xtensa: switch to generic extable.h
xtensa: get rid of zeroing, use RAW_COPY_USER
arc: switch to RAW_COPY_USER
x86: don't wank with magical size in __copy_in_user()
x86: switch to RAW_COPY_USER
s390: get rid of zeroing, switch to RAW_COPY_USER
Merge branch 'parisc-4.11-3' of
git://git.kernel.org/.../deller/parisc-linux into uaccess.parisc
parisc: switch to RAW_COPY_USER
sparc: switch to RAW_COPY_USER
Merge branch 'fixes' of git://git.kernel.org/.../jhogan/
linux-next: manual merge of the rcu tree with the ftrace tree
Hi Paul,
Today's linux-next merge of the rcu tree got a conflict in:
kernel/rcu/tree.c
between commit:
a278d4718988 ("rcu: Fix dyntick-idle tracing")
from the ftrace tree and commit:
e83d58dc7de2 ("rcu: Add lockdep_assert_held() teeth to tree.c")
from the rcu tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/rcu/tree.c
index ea2da0b22a6f,e180eea5061e..
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@@ -792,9 -785,10 +799,10 @@@ static void rcu_eqs_enter_common(bool u
{
struct rcu_state *rsp;
struct rcu_data *rdp;
- RCU_TRACE(struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);)
+ struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+ RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_eqs_enter_common() invoked with
irqs enabled!!!");
- trace_rcu_dyntick(TPS("Start"), oldval, rdtp->dynticks_nesting);
+ trace_rcu_dyntick(TPS("Start"), rdtp->dynticks_nesting, 0);
if (IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
!user && !is_idle_task(current)) {
struct task_struct *idle __maybe_unused =
Linux 4.11
So after that extra week with an rc8, things were pretty calm, and I'm much happier releasing a final 4.11 now. We still had various smaller fixes the last week, but nothing that made me go "hmm..". Shortlog appended for people who want to peruse the details, but it's a mix all over, with about half being drivers (networking dominates, but some sound fixlets too), with the rest being soem arch updates, generic networking, and filesystem (nfs[d]) fixes. But it's all really small, which is what I like to see the last week of the release cycle. And with this, the merge window is obviously open. I already have two pull request for 4.12 in my inbox, I expect that overnight I'll get a lot more. Linus --- Al Viro (4): orangefs_bufmap_copy_from_iovec(): fix EFAULT handling p9_client_readdir() fix fix nfs O_DIRECT advancing iov_iter too much fix a braino in ITER_PIPE iov_iter_revert() Alexander Kochetkov (1): net: phy: fix auto-negotiation stall due to unavailable interrupt Alexander Potapenko (1): net/packet: check length in getsockopt() called with PACKET_HDRLEN Andreas Kemnade (2): net: hso: fix module unloading net: hso: register netdev later to avoid a race condition Ansis Atteka (1): udp: disable inner UDP checksum offloads in IPsec case Arnaud Pouliquen (1): ASoC: STI: Fix null ptr deference in IRQ handler Arnd Bergmann (2): clk: sunxi-ng: always select CCU_GATE cpsw/netcp: refine cpts dependency Bert Kenward (1): sfc: tx ring can only have 2048 entries for all EF10 NICs Dan Carpenter (2): net: tc35815: move free after the dereference ravb: Double free on error in ravb_start_xmit() David Ahern (2): net: ipv6: send unsolicited NA if enabled for all interfaces net: ipv6: regenerate host route if moved to gc list David Howells (1): statx: Kill fd-with-NULL-path support in favour of AT_EMPTY_PATH David S. Miller (3): sparc64: Fill in rest of HAVE_REGS_AND_STACK_ACCESS_API sparc: Update syscall tables. Revert "phy: micrel: Disable auto negotiation on startup" David Sterba (1): btrfs: qgroup: move noisy underflow warning to debugging build Dmitry Torokhov (1): Input: i8042 - add Clevo P650RS to the i8042 reset list Dmitry V. Levin (1): uapi: change the type of struct statx_timestamp.tv_nsec to unsigned Eric Dumazet (2): tcp: do not underestimate skb->truesize in tcp_trim_head() net: adjust skb->truesize in ___pskb_trim() Eugenia Emantayev (1): net/mlx5e: Fix small packet threshold Florian Fainelli (3): net: dsa: b53: Include IMP/CPU port in dumb forwarding mode net: dsa: b53: Implement software reset for 58xx devices net: dsa: b53: Fix CPU port for 58xx devices Frederic Weisbecker (1): sched/cputime: Fix ksoftirqd cputime accounting regression Herbert Xu (1): macvlan: Fix device ref leak when purging bc_queue Ilan Tayari (1): net/mlx5e: Fix ETHTOOL_GRXCLSRLALL handling J. Bruce Fields (3): nfsd: check for oversized NFSv2/v3 arguments nfsd4: minor NFSv2/v3 write decoding cleanup nfsd: stricter decoding of write-like NFSv2/v3 ops James Cowgill (2): MIPS: Fix modversioning of _mcount symbol MIPS: Avoid BUG warning in arch_check_elf James Hogan (2): MIPS: cevt-r4k: Fix out-of-bounds array access MIPS: KGDB: Use kernel context for sleeping threads Jamie Bainbridge (1): ipv6: check raw payload size correctly in ioctl Janakarajan Natarajan (1): Prevent timer value 0 for MWAITX Jason A. Donenfeld (2): macsec: avoid heap overflow in skb_to_sgvec macsec: dynamically allocate space for sglist Johannes Thumshirn (1): scsi: return correct blkprep status code in case scsi_init_io() fails. Josh Poimboeuf (2): ftrace/x86: Fix triple fault with graph tracing and suspend-to-ram x86/build: convert function graph '-Os' error to warning Linus Torvalds (1): Linux 4.11 Maksim Salau (1): net: can: usb: gs_usb: Fix buffer on stack Maor Gottlieb (1): net/mlx5: Fix UAR memory leak Marcin Nowakowski (1): MIPS: generic: fix out-of-tree defconfig target builds Martin KaFai Lau (1): net/mlx5e: Fix race in mlx5e_sw_stats and mlx5e_vport_stats Mathias Kresin (1): MIPS: PCI: add controllers before the specified head Matt Redfearn (3): MIPS: Malta: Fix i8259 irqchip setup MIPS: KASLR: Add missing header files MIPS: smp-cps: Fix potentially uninitialised value of core Michael Kerrisk (man-pages) (1): statx: correct error handling of NULL pathname Mohamad Haj Yahia (1): net/mlx5: Fix driver load bad flow when having fw initializing timeout Mousumi Jana (1): ASoC: topology: Fix to store enum text values Myungho Jung (1): net: core: Prevent from dereferencing null pointer when releasing SKB Noam Camus (1): ARC: [plat-eznps] Fix b
Re: [PATCH v2] powerpc/mm: Only read faulting instruction when necessary in do_page_fault()
On Fri, 28 Apr 2017 08:13:01 +0200 (CEST)
Christophe Leroy wrote:
> Commit a7a9dcd882a67 ("powerpc: Avoid taking a data miss on every
> userspace instruction miss") has shown that limiting the read of
> faulting instruction to likely cases improves performance.
>
> This patch goes further into this direction by limiting the read
> of the faulting instruction to the only cases where it is definitly
> needed.
>
> On an MPC885, with the same benchmark app as in the commit referred
> above, we see a reduction of 4000 dTLB misses (approx 3%):
>
> Before the patch:
> Performance counter stats for './fault 500' (10 runs):
>
> 720495838 cpu-cycles
> ( +- 0.04% )
> 141769 dTLB-load-misses
> ( +- 0.02% )
> 52722 iTLB-load-misses
> ( +- 0.01% )
> 19611 faults
> ( +- 0.02% )
>
>5.750535176 seconds time elapsed
>( +- 0.16% )
>
> With the patch:
> Performance counter stats for './fault 500' (10 runs):
>
> 717669123 cpu-cycles
> ( +- 0.02% )
> 137344 dTLB-load-misses
> ( +- 0.03% )
> 52731 iTLB-load-misses
> ( +- 0.01% )
> 19614 faults
> ( +- 0.03% )
>
>5.728423115 seconds time elapsed
>( +- 0.14% )
>
> Signed-off-by: Christophe Leroy
> ---
> v2: Changes 'if (cond1) if (cond2)' by 'if (cond1 && cond2)'
>
> In case the instruction we read has value 0, store_update_sp() will
> return false, so it will bail out.
>
> This patch applies after the serie "powerpc/mm: some cleanup of
> do_page_fault()"
>
> arch/powerpc/mm/fault.c | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 400f2d0d42f8..2ec82a279d28 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -280,14 +280,6 @@ int do_page_fault(struct pt_regs *regs, unsigned long
> address,
>
> perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
>
> - /*
> - * We want to do this outside mmap_sem, because reading code around nip
> - * can result in fault, which will cause a deadlock when called with
> - * mmap_sem held
> - */
> - if (is_write && is_user)
> - __get_user(inst, (unsigned int __user *)regs->nip);
> -
> if (is_user)
> flags |= FAULT_FLAG_USER;
>
> @@ -356,8 +348,18 @@ int do_page_fault(struct pt_regs *regs, unsigned long
> address,
>* between the last mapped region and the stack will
>* expand the stack rather than segfaulting.
>*/
> - if (address + 2048 < uregs->gpr[1] && !store_updates_sp(inst))
> - goto bad_area;
> + if (address + 2048 < uregs->gpr[1] && !inst) {
> + /*
> + * We want to do this outside mmap_sem, because reading
> + * code around nip can result in fault, which will cause
> + * a deadlock when called with mmap_sem held
> + */
> + up_read(&mm->mmap_sem);
> + __get_user(inst, (unsigned int __user *)regs->nip);
> + if (!store_updates_sp(inst))
> + goto bad_area_nosemaphore;
> + goto retry;
> + }
Yes, nice patch. I wonder if you can do __get_user first as non-faulting to
avoid retaking the mmap_sem and retrying? Along the lines of:
+ nip = (unsigned int __user *)regs->nip;
+ pagefault_disable();
+ if (unlikely(__get_user_inatomic(inst, nip))) {
+ pagefault_enable();
+ up_read(&mm->mmap_sem);
+ if (get_user(inst, nip)) {
...
goto retry;
The user instruction should practically always have a Linux pte, so a
fault there should be exceedingly rare, I think?
Thanks,
Nick
Re: [PATCH] net: phy: Allow BCM5481x PHYs to setup internal TX/RX clock delay
From: Abhishek Shah Date: Sun, 30 Apr 2017 11:04:21 +0530 > This patch allows users to enable/disable internal TX and/or RX > clock delay for BCM5481x series PHYs so as to satisfy RGMII timing > specifications. > > On a particular platform, whether TX and/or RX clock delay is required > depends on how PHY connected to the MAC IP. This requirement can be > specified through "phy-mode" property in the platform device tree. > > Signed-off-by: Abhishek Shah Applied.
Re: [PATCH] net: sunhme: fix spelling mistakes: "ParityErro" -> "ParityError"
From: Colin King Date: Sat, 29 Apr 2017 22:38:57 +0100 > From: Colin Ian King > > trivial fix to spelling mistakes in printk message. > > Signed-off-by: Colin Ian King Applied.
Re: [PATCH v2] iov_iter: don't revert iov buffer if csum error
From: Al Viro Date: Sat, 29 Apr 2017 21:48:23 +0100 > On Sat, Apr 29, 2017 at 05:37:38PM +0800, Ding Tianhong wrote: > >> Looks good, if so, we don't need the csum_error any more, > > Acked-by: Al Viro > > Dave, I could put that through my tree, but I think it would be better off > in net.git; either way, it needs to go into mainline before -final... Please just send it directly to Linus, thanks.
linux-next: manual merge of the spi tree with the pm tree
Hi Mark,
Today's linux-next merge of the spi tree got a conflict in:
drivers/acpi/acpi_apd.c
between commit:
6e14cf361a0c ("ACPI / APD: Add clock frequency for Hisilicon Hip07/08 I2C
controller")
from the pm tree and commit:
251831bd4f49 ("spi: xlp: update for ARCH_VULCAN2")
from the spi tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/acpi/acpi_apd.c
index 8f57648f318b,17a1eb14847a..
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@@ -179,8 -169,7 +179,9 @@@ static const struct acpi_device_id acpi
#ifdef CONFIG_ARM64
{ "APMC0D0F", APD_ADDR(xgene_i2c_desc) },
{ "BRCM900D", APD_ADDR(vulcan_spi_desc) },
+ { "CAV900D", APD_ADDR(vulcan_spi_desc) },
+ { "HISI0A21", APD_ADDR(hip07_i2c_desc) },
+ { "HISI0A22", APD_ADDR(hip08_i2c_desc) },
#endif
{ }
};
Re: [PATCH v3 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Eric Anholt Date: Fri, 28 Apr 2017 15:22:03 -0700 > Cygnus is a small family of SoCs, of which we currently have > devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the > same as 58xx, just requiring a tiny bit of setup that was previously > missing. > > v2: Reorder the entry in the docs (suggestion by Scott Branden), add > missing '"' > > Signed-off-by: Eric Anholt > Reviewed-by: Florian Fainelli > Acked-by: Rob Herring The second patch with the DTS file update doesn't apply cleanly at all to net-next. So I'm dropping this series.
Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference
On Sat, Apr 29, 2017 at 7:18 AM, Ingo Molnar wrote:
>
> * Dan Williams wrote:
>
>> Kirill points out that the calls to {get,put}_dev_pagemap() can be
>> removed from the mm fast path if we take a single get_dev_pagemap()
>> reference to signify that the page is alive and use the final put of the
>> page to drop that reference.
>>
>> This does require some care to make sure that any waits for the
>> percpu_ref to drop to zero occur *after* devm_memremap_page_release(),
>> since it now maintains its own elevated reference.
>>
>> Cc: Ingo Molnar
>> Cc: Jérôme Glisse
>> Cc: Andrew Morton
>> Reviewed-by: Logan Gunthorpe
>> Suggested-by: Kirill Shutemov
>> Tested-by: Kirill Shutemov
>> Signed-off-by: Dan Williams
>
> This changelog is lacking an explanation about how this solves the crashes you
> were seeing.
>
Kirill? It wasn't clear to me why the conversion to generic
get_user_pages_fast() caused the reference counts to be off.
Re: [PATCH 2/3] mm/slub: wrap cpu_slab->partial in CONFIG_SLUB_CPU_PARTIAL
On Sun, Apr 30, 2017 at 07:31:51PM +0800, Wei Yang wrote:
> @@ -2302,7 +2302,11 @@ static bool has_cpu_slab(int cpu, void *info)
> struct kmem_cache *s = info;
> struct kmem_cache_cpu *c = per_cpu_ptr(s->cpu_slab, cpu);
>
> - return c->page || c->partial;
> + return c->page
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> + || c->partial
> +#endif
> + ;
> }
No. No way. This is disgusting.
The right way to do this is to create an accessor like this:
#ifdef CONFIG_SLUB_CPU_PARTIAL
#define slub_cpu_partial(c) ((c)->partial)
#else
#define slub_cpu_partial(c) 0
#endif
And then the above becomes:
- return c->page || c->partial;
+ return c->page || slub_cpu_partial(c);
All the other ifdefs go away, apart from these two:
> @@ -4980,6 +4990,7 @@ static ssize_t objects_partial_show(struct kmem_cache
> *s, char *buf)
> }
> SLAB_ATTR_RO(objects_partial);
>
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> static ssize_t slabs_cpu_partial_show(struct kmem_cache *s, char *buf)
> {
> int objects = 0;
> @@ -5010,6 +5021,7 @@ static ssize_t slabs_cpu_partial_show(struct kmem_cache
> *s, char *buf)
> return len + sprintf(buf + len, "\n");
> }
> SLAB_ATTR_RO(slabs_cpu_partial);
> +#endif
>
> static ssize_t reclaim_account_show(struct kmem_cache *s, char *buf)
> {
> @@ -5364,7 +5376,9 @@ static struct attribute *slab_attrs[] = {
> &destroy_by_rcu_attr.attr,
> &shrink_attr.attr,
> &reserved_attr.attr,
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> &slabs_cpu_partial_attr.attr,
> +#endif
> #ifdef CONFIG_SLUB_DEBUG
> &total_objects_attr.attr,
> &slabs_attr.attr,
Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference
On Sun, Apr 30, 2017 at 6:54 PM, Jerome Glisse wrote:
> On Sun, Apr 30, 2017 at 06:42:02PM -0700, Dan Williams wrote:
>> On Sun, Apr 30, 2017 at 4:14 PM, Jerome Glisse wrote:
>> > On Sat, Apr 29, 2017 at 01:17:26PM +0300, Kirill A. Shutemov wrote:
>> >> On Fri, Apr 28, 2017 at 03:33:07PM -0400, Jerome Glisse wrote:
>> >> > On Fri, Apr 28, 2017 at 12:22:24PM -0700, Dan Williams wrote:
>> >> > > Are you sure about needing to hook the 2 -> 1 transition? Could we
>> >> > > change ZONE_DEVICE pages to not have an elevated reference count when
>> >> > > they are created so you can keep the HMM references out of the mm hot
>> >> > > path?
>> >> >
>> >> > 100% sure on that :) I need to callback into driver for 2->1 transition
>> >> > no way around that. If we change ZONE_DEVICE to not have an elevated
>> >> > reference count that you need to make a lot more change to mm so that
>> >> > ZONE_DEVICE is never use as fallback for memory allocation. Also need
>> >> > to make change to be sure that ZONE_DEVICE page never endup in one of
>> >> > the path that try to put them back on lru. There is a lot of place that
>> >> > would need to be updated and it would be highly intrusive and add a
>> >> > lot of special cases to other hot code path.
>> >>
>> >> Could you explain more on where the requirement comes from or point me to
>> >> where I can read about this.
>> >>
>> >
>> > HMM ZONE_DEVICE pages are use like other pages (anonymous or file back
>> > page)
>> > in _any_ vma. So i need to know when a page is freed ie either as result of
>> > unmap, exit or migration or anything that would free the memory. For zone
>> > device a page is free once its refcount reach 1 so i need to catch refcount
>> > transition from 2->1
>> >
>> > This is the only way i can inform the device that the page is now free. See
>> >
>> > https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-v21&id=52da8fe1a088b87b5321319add79e43b8372ed7d
>> >
>> > There is _no_ way around that.
>>
>> Ok, but I need to point out that this not a ZONE_DEVICE requirement.
>> This is an HMM-specific need. So, this extra reference counting should
>> be clearly delineated as part of the MEMORY_DEVICE_PRIVATE use case.
>
> And it already is delimited, i think you even gave your review by on
> the patch.
>
I gave my reviewed-by to the patch that leveraged
{get,put}_zone_device_page(), but now those are gone and HMM needs a
new patch. I'm just saying these reference counts should not come back
as {get,put}_zone_device_page() because now they're HMM specific.
>> Can we hide the extra reference counting behind a static branch so
>> that the common case fast path doesn't get slower until a HMM device
>> shows up?
>
> Like i already did With likely()/unlikely() ? Or something else ?
>
> https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-v21&id=e84778e9db0672e371eb6599dfcb812512118842
Something different:
http://lxr.free-electrons.com/source/Documentation/static-keys.txt
Re: [PATCH] drivers:net:ethernet:emulex:benet: Use time_before_eq for time comparison
From: Karim Eshapa Date: Fri, 28 Apr 2017 03:48:59 +0200 > Use time_before_eq for time comparison more safe and dealing > with timer wrapping to be future-proof. > > Signed-off-by: Karim Eshapa Subject line has way too many subsystem prefixes, simply "benet: " is sufficient. And in situations where multiple subsystem prefixes are appropriate, one must put a space after each one like "one: two: three: ". Thanks.
Re: [PATCH net-next] net: Initialise init_net.count to 1
From: David Howells Date: Thu, 27 Apr 2017 22:40:23 +0100 > Initialise init_net.count to 1 for its pointer from init_nsproxy lest > someone tries to do a get_net() and a put_net() in a process in which > current->ns_proxy->net_ns points to the initial network namespace. > > Signed-off-by: David Howells Applied.
Re: [PATCH] net: macb: fix phy interrupt parsing
From: Alexandre Belloni
Date: Wed, 26 Apr 2017 12:06:28 +0200
> Since 83a77e9ec415, the phydev irq is explicitly set to PHY_POLL when
> there is no pdata. It doesn't work on DT enabled platforms because the
> phydev irq is already set by libphy before.
>
> Fixes: 83a77e9ec415 ("net: macb: Added PCI wrapper for Platform Driver.")
> Signed-off-by: Alexandre Belloni
Applied and queued up for -stable, thanks.
Re: RFC: i2c designware gpio recovery
On 28/04/2017 23:43, Tim Sander wrote:
Hi
G'day Tim,
Given a couple of days I can test this on some flack i2c hardware I have with a
Cyclone-V SOC.
I'm interested in the functionality as well.
For i2c that are connected to the dedicated HPS pins it should be possible to
reconfigure
the pin mux controller (see system manager) in the HPS to avoid the need to go
thru the fpga
to get direct control. The docs say this is "unsupport" but I've done some test
and it does
seem to work. I'm guess the no support is in a similar vain to the emac ptp
FPGA interface
couldn't be used when the HPS pin where used. But that got changed when the
user's proved otherwise.
There's just no pin ctrl driver yet to manage it.
I have tried to add a gpio recovery gpio controller to the designware i2c
driver. The attempt is
attached below. I have a Intel(Altera) Cyclone V SOC Platform attached to a
buggy power
supply which gives a lockup on the i2c controller as a external device gives to
much noise
on the signal and destroys a clock signal on its way to a i2c device.
I don't care to much about this buggy power supply but as the cable to one
i2c-slave is
rather long i fear that power surge conformance tests might give also some
problems.
So i would like to be safe than sorry and recover from this problem.
I have created two gpio ports in fpga and have routed the designware pins
through the fpga.
I can now read SDA input status and control SCL via these gpios. The recovery
gets triggered
and after that i get lots of:
i2c_designware ffc05000.i2c: controller timed out
so i guess that my i2c_dw_unprepare_recovery does not enought to get the
controller back.
I have also noticed that there does not seem do be a reset controller in the
standard configuration.
so reset_control_(de)assert(i_dev->rst) seems to do nothing.
I have verified that the recovery of the bus works and if i do a warm reboot
the i2c-bus is working
again. Which it doesn't without recovery. So i am pretty sure that the recovery
works as far as the
i2c-slave is not pulling down SDA and that my gpio pins are in the correct
state that they would not
interfere with the i2c-operation of the controller.
Any ideas what i can do to get the controller back up running with some special
treatment in
i2c_dw_(un)prepare_recovery without having to resort to a warm reboot?
Best regards
Tim
---
drivers/i2c/busses/i2c-designware-core.c| 15 ++--
drivers/i2c/busses/i2c-designware-core.h| 1 +
drivers/i2c/busses/i2c-designware-platdrv.c | 60 -
drivers/i2c/i2c-core.c | 10 -
4 files changed, 78 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index 7a3faa551cf8..b98fab40ce9a 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -317,6 +317,7 @@ static void i2c_dw_release_lock(struct dw_i2c_dev *dev)
dev->release_lock(dev);
}
+
/**
* i2c_dw_init() - initialize the designware i2c master hardware
* @dev: device private data
@@ -463,7 +464,11 @@ static int i2c_dw_wait_bus_not_busy(struct dw_i2c_dev *dev)
while (dw_readl(dev, DW_IC_STATUS) & DW_IC_STATUS_ACTIVITY) {
if (timeout <= 0) {
dev_warn(dev->dev, "timeout waiting for bus ready\n");
- return -ETIMEDOUT;
+ i2c_recover_bus(&dev->adapter);
+
+ if (dw_readl(dev, DW_IC_STATUS) & DW_IC_STATUS_ACTIVITY)
+ return -EIO;
+ else return 0;
}
timeout--;
usleep_range(1000, 1100);
@@ -719,9 +724,10 @@ static int i2c_dw_handle_tx_abort(struct dw_i2c_dev *dev)
for_each_set_bit(i, &abort_source, ARRAY_SIZE(abort_sources))
dev_err(dev->dev, "%s: %s\n", __func__, abort_sources[i]);
- if (abort_source & DW_IC_TX_ARB_LOST)
+ if (abort_source & DW_IC_TX_ARB_LOST) {
+ i2c_recover_bus(&dev->adapter);
return -EAGAIN;
- else if (abort_source & DW_IC_TX_ABRT_GCALL_READ)
+ } else if (abort_source & DW_IC_TX_ABRT_GCALL_READ)
return -EINVAL; /* wrong msgs[] data */
else
return -EIO;
@@ -766,6 +772,7 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
if (!wait_for_completion_timeout(&dev->cmd_complete, adap->timeout)) {
dev_err(dev->dev, "controller timed out\n");
/* i2c_dw_init implicitly disables the adapter */
+ //i2c_recover_bus(&dev->adapter);
i2c_dw_init(dev);
ret = -ETIMEDOUT;
goto done;
@@ -825,7 +832,7 @@ static const struct i2c_algorithm i2c_dw_algo = {
.functionality = i2c_dw_func,
};
-static u32 i2c_dw_read_clear_in
Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers
Thanx for the reply. Andrea Arcangeli: > Yes I already reported this, my original fix was way more efficient > (and also safer considering the above) than what landed upstream. My > feedback was ignored though. > > https://lists.freedesktop.org/archives/intel-gfx/2017-April/125414.html I see. Actually on my test system for v4.11-rc8, kthreadd, kworker, kswapd and others all stopped working due to the synchronize_rcu_expedited call from i915_gem_shrinker_count. It is definitly a show stopper for me as an i915 user. It was a few weeks ago when you posted. It is a pity the fix was not merged before v4.11 comes out. I know v4.11 will appear soon. So I'd ask i915 developers, would you test Andrea Arcangeli's fix and release it as v4.11.1 as soon as possible? J. R. Okajima
Re: RFC: i2c designware gpio recovery
G'day Tim, On 29/04/2017 00:14, Tim Sander wrote: Hi After sending this mail i just found out how i could reset the i2c-1 controller manually with devmem 0xffd05014 32 0x2000 devmem 0xffd05014 32 0 So i took a look into the device tree file socfpga.dtsi and found that the reset lines where not defined (although available in the corresponding reset manager). Is there a reason for this? Other components are connected. There's a few thing like that where the bootloader has been expected to setup the resets etc. However with the patch below my previously sent patch works! If there is interest in would cleanup the patch and send it in for mainlining. I think the most unacceptable part would be this line: + ret = gpio_request_one(bri->scl_gpio, //GPIOF_OPEN_DRAIN | My gpio drivers refuse to work as output as they have no open drain mode. So i wonder how to get this solved in a clean manner. I thought the gpio system would emulate open drain by switching the pin between an input and output driven low in this case. How are you configuring the GPIO's in the FPGA? Best regards Tim --- arch/arm/boot/dts/socfpga.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi index 2c43c4d85dee..5f28632bc88c 100644 --- a/arch/arm/boot/dts/socfpga.dtsi +++ b/arch/arm/boot/dts/socfpga.dtsi @@ -643,6 +643,7 @@ #size-cells = <0>; compatible = "snps,designware-i2c"; reg = <0xffc04000 0x1000>; + resets = <&rst I2C0_RESET>; clocks = <&l4_sp_clk>; interrupts = <0 158 0x4>; status = "disabled"; @@ -653,6 +654,7 @@ #size-cells = <0>; compatible = "snps,designware-i2c"; reg = <0xffc05000 0x1000>; + resets = <&rst I2C1_RESET>; clocks = <&l4_sp_clk>; interrupts = <0 159 0x4>; status = "disabled"; @@ -663,6 +665,7 @@ #size-cells = <0>; compatible = "snps,designware-i2c"; reg = <0xffc06000 0x1000>; + resets = <&rst I2C2_RESET>; clocks = <&l4_sp_clk>; interrupts = <0 160 0x4>; status = "disabled"; @@ -673,6 +676,7 @@ #size-cells = <0>; compatible = "snps,designware-i2c"; reg = <0xffc07000 0x1000>; + resets = <&rst I2C3_RESET>; clocks = <&l4_sp_clk>; interrupts = <0 161 0x4>; status = "disabled"; -- Regards Phil Reid ElectroMagnetic Imaging Technology Pty Ltd Development of Geophysical Instrumentation & Software www.electromag.com.au 3 The Avenue, Midland WA 6056, AUSTRALIA Ph: +61 8 9250 8100 Fax: +61 8 9250 7100 Email: pr...@electromag.com.au
Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference
On Sun, Apr 30, 2017 at 06:42:02PM -0700, Dan Williams wrote: > On Sun, Apr 30, 2017 at 4:14 PM, Jerome Glisse wrote: > > On Sat, Apr 29, 2017 at 01:17:26PM +0300, Kirill A. Shutemov wrote: > >> On Fri, Apr 28, 2017 at 03:33:07PM -0400, Jerome Glisse wrote: > >> > On Fri, Apr 28, 2017 at 12:22:24PM -0700, Dan Williams wrote: > >> > > Are you sure about needing to hook the 2 -> 1 transition? Could we > >> > > change ZONE_DEVICE pages to not have an elevated reference count when > >> > > they are created so you can keep the HMM references out of the mm hot > >> > > path? > >> > > >> > 100% sure on that :) I need to callback into driver for 2->1 transition > >> > no way around that. If we change ZONE_DEVICE to not have an elevated > >> > reference count that you need to make a lot more change to mm so that > >> > ZONE_DEVICE is never use as fallback for memory allocation. Also need > >> > to make change to be sure that ZONE_DEVICE page never endup in one of > >> > the path that try to put them back on lru. There is a lot of place that > >> > would need to be updated and it would be highly intrusive and add a > >> > lot of special cases to other hot code path. > >> > >> Could you explain more on where the requirement comes from or point me to > >> where I can read about this. > >> > > > > HMM ZONE_DEVICE pages are use like other pages (anonymous or file back page) > > in _any_ vma. So i need to know when a page is freed ie either as result of > > unmap, exit or migration or anything that would free the memory. For zone > > device a page is free once its refcount reach 1 so i need to catch refcount > > transition from 2->1 > > > > This is the only way i can inform the device that the page is now free. See > > > > https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-v21&id=52da8fe1a088b87b5321319add79e43b8372ed7d > > > > There is _no_ way around that. > > Ok, but I need to point out that this not a ZONE_DEVICE requirement. > This is an HMM-specific need. So, this extra reference counting should > be clearly delineated as part of the MEMORY_DEVICE_PRIVATE use case. And it already is delimited, i think you even gave your review by on the patch. > Can we hide the extra reference counting behind a static branch so > that the common case fast path doesn't get slower until a HMM device > shows up? Like i already did With likely()/unlikely() ? Or something else ? https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-v21&id=e84778e9db0672e371eb6599dfcb812512118842 Cheers, Jérôme
Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference
On Sun, Apr 30, 2017 at 4:14 PM, Jerome Glisse wrote: > On Sat, Apr 29, 2017 at 01:17:26PM +0300, Kirill A. Shutemov wrote: >> On Fri, Apr 28, 2017 at 03:33:07PM -0400, Jerome Glisse wrote: >> > On Fri, Apr 28, 2017 at 12:22:24PM -0700, Dan Williams wrote: >> > > Are you sure about needing to hook the 2 -> 1 transition? Could we >> > > change ZONE_DEVICE pages to not have an elevated reference count when >> > > they are created so you can keep the HMM references out of the mm hot >> > > path? >> > >> > 100% sure on that :) I need to callback into driver for 2->1 transition >> > no way around that. If we change ZONE_DEVICE to not have an elevated >> > reference count that you need to make a lot more change to mm so that >> > ZONE_DEVICE is never use as fallback for memory allocation. Also need >> > to make change to be sure that ZONE_DEVICE page never endup in one of >> > the path that try to put them back on lru. There is a lot of place that >> > would need to be updated and it would be highly intrusive and add a >> > lot of special cases to other hot code path. >> >> Could you explain more on where the requirement comes from or point me to >> where I can read about this. >> > > HMM ZONE_DEVICE pages are use like other pages (anonymous or file back page) > in _any_ vma. So i need to know when a page is freed ie either as result of > unmap, exit or migration or anything that would free the memory. For zone > device a page is free once its refcount reach 1 so i need to catch refcount > transition from 2->1 > > This is the only way i can inform the device that the page is now free. See > > https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-v21&id=52da8fe1a088b87b5321319add79e43b8372ed7d > > There is _no_ way around that. Ok, but I need to point out that this not a ZONE_DEVICE requirement. This is an HMM-specific need. So, this extra reference counting should be clearly delineated as part of the MEMORY_DEVICE_PRIVATE use case. Can we hide the extra reference counting behind a static branch so that the common case fast path doesn't get slower until a HMM device shows up?
Re: [PATCH] net: phy: Allow BCM5481x PHYs to setup internal TX/RX clock delay
On 04/29/2017 10:34 PM, Abhishek Shah wrote:
> This patch allows users to enable/disable internal TX and/or RX
> clock delay for BCM5481x series PHYs so as to satisfy RGMII timing
> specifications.
>
> On a particular platform, whether TX and/or RX clock delay is required
> depends on how PHY connected to the MAC IP. This requirement can be
> specified through "phy-mode" property in the platform device tree.
>
> Signed-off-by: Abhishek Shah
Reviewed-by: Florian Fainelli
> ---
> drivers/net/phy/broadcom.c | 69
> ++
> 1 file changed, 33 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
> index 9cd8b27..a32dc5d 100644
> --- a/drivers/net/phy/broadcom.c
> +++ b/drivers/net/phy/broadcom.c
> @@ -74,27 +74,40 @@ static int bcm54612e_config_init(struct phy_device
> *phydev)
> return 0;
> }
>
> -static int bcm54810_config(struct phy_device *phydev)
> +static int bcm5481x_config(struct phy_device *phydev)
> {
> int rc, val;
>
> - val = bcm_phy_read_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL);
> - val &= ~BCM54810_EXP_BROADREACH_LRE_MISC_CTL_EN;
> - rc = bcm_phy_write_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL,
> -val);
> - if (rc < 0)
> - return rc;
> -
> + /* handling PHY's internal RX clock delay */
> val = bcm54xx_auxctl_read(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC);
> - val &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
> val |= MII_BCM54XX_AUXCTL_MISC_WREN;
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
> + /* Disable RGMII RXC-RXD skew */
> + val &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
> + }
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
> + /* Enable RGMII RXC-RXD skew */
> + val |= MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
> + }
> rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
> val);
> if (rc < 0)
> return rc;
>
> + /* handling PHY's internal TX clock delay */
> val = bcm_phy_read_shadow(phydev, BCM54810_SHD_CLK_CTL);
> - val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
> + /* Disable internal TX clock delay */
> + val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
> + }
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
> + /* Enable internal TX clock delay */
> + val |= BCM54810_SHD_CLK_CTL_GTXCLK_EN;
> + }
> rc = bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, val);
> if (rc < 0)
> return rc;
> @@ -244,7 +257,7 @@ static void bcm54xx_adjust_rxrefclk(struct phy_device
> *phydev)
>
> static int bcm54xx_config_init(struct phy_device *phydev)
> {
> - int reg, err;
> + int reg, err, val;
>
> reg = phy_read(phydev, MII_BCM54XX_ECR);
> if (reg < 0)
> @@ -283,8 +296,14 @@ static int bcm54xx_config_init(struct phy_device *phydev)
> if (err)
> return err;
> } else if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
> - err = bcm54810_config(phydev);
> - if (err)
> + /* For BCM54810, we need to disable BroadR-Reach function */
> + val = bcm_phy_read_exp(phydev,
> +BCM54810_EXP_BROADREACH_LRE_MISC_CTL);
> + val &= ~BCM54810_EXP_BROADREACH_LRE_MISC_CTL_EN;
> + err = bcm_phy_write_exp(phydev,
> + BCM54810_EXP_BROADREACH_LRE_MISC_CTL,
> + val);
> + if (err < 0)
> return err;
> }
>
> @@ -392,29 +411,7 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
> ret = genphy_config_aneg(phydev);
>
> /* Then we can set up the delay. */
> - if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
> - u16 reg;
> -
> - /*
> - * There is no BCM5481 specification available, so down
> - * here is everything we know about "register 0x18". This
> - * at least helps BCM5481 to successfully receive packets
> - * on MPC8360E-RDK board. Peter Barada
> - * says: "This sets delay between the RXD and RXC signals
> - * instead of using trace lengths to achieve timing".
> - */
> -
> - /* Set RDX clk delay. */
> - reg = 0x7 | (0x7 << 12);
> - phy_write(phydev, 0x18, reg);
> -
> -
Re: [PATCH v2 4/4] iio: accel: adxl345: Add support for triggered buffer
On 29/04/17 08:49, Eva Rachel Retuya wrote:
> Previously, the only way to capture data is to read the exposed sysfs
> files in_accel_[x/y/z]_raw and applying the scale from in_accel_scale.
> Provide a way for continuous data capture that allows multiple data
> channels to be read at once by setting up buffer support.
>
> Initialize scan_type fields that describe the buffer and make sure to
> claim and release direct mode in read_raw. The latter is done to ensure
> no raw reads are attempted when utilizing the buffer and vice versa.
>
> Lastly, add triggered buffer support that allows utilization of any
> given trigger such as DATA_READY, hrtimer, etc. to initiate capturing of
> data and placing said data in the buffer. The trigger handler performs
> an all-axes read with timestamp.
>
> Signed-off-by: Eva Rachel Retuya
Few minor bits inline... I'm a little bit in two minds about the
holding up waiting for new data when using another trigger...
Jonathan
> ---
> Changes in v2:
> * Provide a more detailed commit message
> * adxl345_trigger_handler()
> * if using external trigger, place a adxl345_data_ready() call before
> performing a bulk read
> * Since get_triple() is scrapped, place a direct bulk read here
> * Move mutex unlocking below goto label
> * Switch to devm_iio_triggered_buffer_setup()
> * Remove i2c_check_functionality() that could introduce regression
>
> drivers/iio/accel/Kconfig| 2 +
> drivers/iio/accel/adxl345_core.c | 101
> ++-
> 2 files changed, 102 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 15de262..45092da 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -7,6 +7,8 @@ menu "Accelerometers"
>
> config ADXL345
> tristate
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
>
> config ADXL345_I2C
> tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer I2C
> Driver"
> diff --git a/drivers/iio/accel/adxl345_core.c
> b/drivers/iio/accel/adxl345_core.c
> index b8be0d7..40dbdce 100644
> --- a/drivers/iio/accel/adxl345_core.c
> +++ b/drivers/iio/accel/adxl345_core.c
> @@ -14,8 +14,11 @@
> #include
> #include
>
> +#include
> #include
> #include
> +#include
> +#include
>
> #include "adxl345.h"
>
> @@ -55,12 +58,20 @@
> */
> static const int adxl345_uscale = 38300;
>
> +enum adxl345_scan_index {
> + ADXL345_IDX_X,
> + ADXL345_IDX_Y,
> + ADXL345_IDX_Z,
> + ADXL345_IDX_TSTAMP,
> +};
> +
> struct adxl345_data {
> struct iio_trigger *data_ready_trig;
> bool data_ready_trig_on;
> struct regmap *regmap;
> struct mutex lock; /* protect this data structure */
> u8 data_range;
> + s16 buffer[8]; /* 3 x 16-bit channels + padding + 64-bit timestamp */
> };
>
> static int adxl345_set_mode(struct adxl345_data *data, u8 mode)
> @@ -109,12 +120,25 @@ static int adxl345_data_ready(struct adxl345_data *data)
> .address = reg, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> + .scan_index = ADXL345_IDX_##axis, \
> + .scan_type = { \
> + .sign = 's',\
> + .realbits = 13, \
> + .storagebits = 16, \
> + .endianness = IIO_LE, \
> + }, \
> }
>
> static const struct iio_chan_spec adxl345_channels[] = {
> ADXL345_CHANNEL(ADXL345_REG_DATAX0, X),
> ADXL345_CHANNEL(ADXL345_REG_DATAY0, Y),
> ADXL345_CHANNEL(ADXL345_REG_DATAZ0, Z),
> + IIO_CHAN_SOFT_TIMESTAMP(ADXL345_IDX_TSTAMP),
> +};
> +
> +static const unsigned long adxl345_scan_masks[] = {
> + BIT(ADXL345_IDX_X) | BIT(ADXL345_IDX_Y) | BIT(ADXL345_IDX_Z),
> + 0
> };
>
> static int adxl345_read_raw(struct iio_dev *indio_dev,
> @@ -127,6 +151,10 @@ static int adxl345_read_raw(struct iio_dev *indio_dev,
>
> switch (mask) {
> case IIO_CHAN_INFO_RAW:
> + ret = iio_device_claim_direct_mode(indio_dev);
> + if (ret)
> + return ret;
> +
> mutex_lock(&data->lock);
> ret = adxl345_set_mode(data, ADXL345_POWER_CTL_MEASURE);
> if (ret < 0) {
> @@ -148,12 +176,14 @@ static int adxl345_read_raw(struct iio_dev *indio_dev,
> ret = regmap_bulk_read(data->regmap, chan->address, ®val,
> sizeof(regval));
> mutex_unlock(&data->lock);
> + iio_device_release_direct_mode(indio_dev);
> if (ret < 0) {
>
Re: [PATCH v2 3/4] iio: accel: adxl345: Setup DATA_READY trigger
On 29/04/17 08:49, Eva Rachel Retuya wrote:
> The ADXL345 provides a DATA_READY interrupt function to signal
> availability of new data. This interrupt function is latched and can be
> cleared by reading the data registers. The polarity is set to active
> high by default.
>
> Support this functionality by setting it up as an IIO trigger.
>
> In addition, two output pins INT1 and INT2 are available for driving
> interrupts. Allow mapping to either pins by specifying the
> interrupt-names property in device tree.
>
> Signed-off-by: Eva Rachel Retuya
Coming together nicely, but a few more bits and pieces inline...
One slight worry is that the irq names stuff is to restrictive
as we want to direct different interrupts to different pins if
both are supported!
Jonathan
> ---
> Changes in v2:
> * Provide a detailed commit message
> * Move the of_irq_get_byname() check in core file in order to avoid
> introducing another parameter in probe()
> * adxl345_irq():
> * return values directly
> * switch from iio_trigger_poll() to iio_trigger_poll_chained(), the former
> should only be called at the top-half not at the bottom-half.
> * adxl345_drdy_trigger_set_state():
> * move regmap_get_device() to definition block
> * regmap_update_bits(): line splitting - one parameter per line, remove
> extra
> parenthesis
> * probe()
> * use variable 'regval' to hold value to be written to the register and call
> regmap_write() unconditionally
> * fix line splitting in devm_request_threaded_irq() and
> devm_iio_trigger_alloc()
> * Switch to devm_iio_trigger_register()
>
> drivers/iio/accel/adxl345.h | 2 +-
> drivers/iio/accel/adxl345_core.c | 104
> ++-
> drivers/iio/accel/adxl345_i2c.c | 3 +-
> drivers/iio/accel/adxl345_spi.c | 2 +-
> 4 files changed, 107 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl345.h b/drivers/iio/accel/adxl345.h
> index c1ddf39..d2fa806 100644
> --- a/drivers/iio/accel/adxl345.h
> +++ b/drivers/iio/accel/adxl345.h
> @@ -11,7 +11,7 @@
> #ifndef _ADXL345_H_
> #define _ADXL345_H_
>
> -int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> +int adxl345_core_probe(struct device *dev, struct regmap *regmap, int irq,
> const char *name);
> int adxl345_core_remove(struct device *dev);
>
> diff --git a/drivers/iio/accel/adxl345_core.c
> b/drivers/iio/accel/adxl345_core.c
> index b8a212c..b8be0d7 100644
> --- a/drivers/iio/accel/adxl345_core.c
> +++ b/drivers/iio/accel/adxl345_core.c
> @@ -9,15 +9,20 @@
> */
>
> #include
> +#include
> #include
> +#include
> #include
>
> #include
> +#include
>
> #include "adxl345.h"
>
> #define ADXL345_REG_DEVID0x00
> #define ADXL345_REG_POWER_CTL0x2D
> +#define ADXL345_REG_INT_ENABLE 0x2E
> +#define ADXL345_REG_INT_MAP 0x2F
> #define ADXL345_REG_INT_SOURCE 0x30
> #define ADXL345_REG_DATA_FORMAT 0x31
> #define ADXL345_REG_DATAX0 0x32
> @@ -39,6 +44,8 @@
>
> #define ADXL345_DEVID0xE5
>
> +#define ADXL345_IRQ_NAME "adxl345_event"
I'd just put this inline. It doesn't really give any benefit to
have this defined at the top.
> +
> /*
> * In full-resolution mode, scale factor is maintained at ~4 mg/LSB
> * in all g ranges.
> @@ -49,6 +56,8 @@
> static const int adxl345_uscale = 38300;
>
> struct adxl345_data {
> + struct iio_trigger *data_ready_trig;
> + bool data_ready_trig_on;
> struct regmap *regmap;
> struct mutex lock; /* protect this data structure */
> u8 data_range;
> @@ -158,17 +167,62 @@ static int adxl345_read_raw(struct iio_dev *indio_dev,
> return -EINVAL;
> }
>
> +static irqreturn_t adxl345_irq(int irq, void *p)
> +{
> + struct iio_dev *indio_dev = p;
> + struct adxl345_data *data = iio_priv(indio_dev);
> + int ret;
> + u32 int_stat;
> +
> + ret = regmap_read(data->regmap, ADXL345_REG_INT_SOURCE, &int_stat);
> + if (ret < 0)
> + return IRQ_HANDLED;
> +
> + if (int_stat & ADXL345_INT_DATA_READY) {
> + iio_trigger_poll_chained(data->data_ready_trig);
> + return IRQ_HANDLED;
> + }
> +
> + return IRQ_NONE;
> +}
> +
> +static int adxl345_drdy_trigger_set_state(struct iio_trigger *trig, bool
> state)
> +{
> + struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
> + struct adxl345_data *data = iio_priv(indio_dev);
> + struct device *dev = regmap_get_device(data->regmap);
> + int ret;
> +
> + ret = regmap_update_bits(data->regmap,
> + ADXL345_REG_INT_ENABLE,
> + ADXL345_INT_DATA_READY,
> + state ? ADXL345_INT_DATA_READY : 0);
> + if (ret < 0) {
> + dev_err(dev, "Failed to update INT_ENABLE bits\n");
> + return ret;
> +
Re: [PATCH v2 2/4] iio: accel: adxl345_core: Introduce set_mode and data_ready functions
On 29/04/17 08:48, Eva Rachel Retuya wrote:
> Move code that enables measurement/standby mode into its own function
> and call that function when appropriate. Previously, we set the sensor
> to measurement in probe and back to standby during remove. Change it
> here to only enter measurement mode when request for data is initiated.
>
> The DATA_READY bit is always set if the corresponding event occurs.
> Introduce the data_ready function that monitors the INT_SOURCE register
> of this bit. This is done to ensure consistent readings.
>
> Signed-off-by: Eva Rachel Retuya
> ---
> Changes in v2:
> * Make function naming more clear: drdy -> data_ready
> * Switch from while to do..while
> * Rename regval to val
> * Switch to usleep_range() for shorter delay
> * Add comment to justify delay
> * Change error code -EIO to -EAGAIN
> * Endianness issue: scrap the get_triple function entirely, make no
> changes in terms of reading registers in read_raw
> * Introduce mutex here rather than in succeeding patch
> * Probe:
> * Fix random whitespace omission
> * Remove configuring to standby mode, the device powers on in standby
> mode so this is not needed
>
> drivers/iio/accel/adxl345_core.c | 84
> +---
> 1 file changed, 69 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl345_core.c
> b/drivers/iio/accel/adxl345_core.c
> index 9ccb582..b8a212c 100644
> --- a/drivers/iio/accel/adxl345_core.c
> +++ b/drivers/iio/accel/adxl345_core.c
> @@ -8,6 +8,7 @@
> * directory of this archive for more details.
> */
>
> +#include
> #include
> #include
>
> @@ -17,6 +18,7 @@
>
> #define ADXL345_REG_DEVID0x00
> #define ADXL345_REG_POWER_CTL0x2D
> +#define ADXL345_REG_INT_SOURCE 0x30
> #define ADXL345_REG_DATA_FORMAT 0x31
> #define ADXL345_REG_DATAX0 0x32
> #define ADXL345_REG_DATAY0 0x34
> @@ -25,6 +27,10 @@
> #define ADXL345_POWER_CTL_MEASUREBIT(3)
> #define ADXL345_POWER_CTL_STANDBY0x00
>
> +/* INT_ENABLE/INT_MAP/INT_SOURCE bits */
> +#define ADXL345_INT_DATA_READY BIT(7)
> +#define ADXL345_INT_OVERRUN 0
> +
> #define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits resolution */
> #define ADXL345_DATA_FORMAT_2G 0
> #define ADXL345_DATA_FORMAT_4G 1
> @@ -44,9 +50,49 @@ static const int adxl345_uscale = 38300;
>
> struct adxl345_data {
> struct regmap *regmap;
> + struct mutex lock; /* protect this data structure */
> u8 data_range;
> };
>
> +static int adxl345_set_mode(struct adxl345_data *data, u8 mode)
> +{
> + struct device *dev = regmap_get_device(data->regmap);
> + int ret;
> +
> + ret = regmap_write(data->regmap, ADXL345_REG_POWER_CTL, mode);
> + if (ret < 0) {
> + dev_err(dev, "Failed to set power mode, %d\n", ret);
> + return ret;
drop the return ret here and just return ret at the end of the function.
One of the static checkers will probably moan about this otherwise.
> + }
> +
> + return 0;
> +}
> +
> +static int adxl345_data_ready(struct adxl345_data *data)
> +{
So this is a polling the dataready bit. Will ensure we always
get fresh data when a read occurs. Please add a comment to
that effect as that's not always how devices work.
> + struct device *dev = regmap_get_device(data->regmap);
> + int tries = 5;
> + u32 val;
> + int ret;
> +
> + do {
> + /*
> + * 1/ODR + 1.1ms; 11.1ms at ODR of 0.10 Hz
> + * Sensor currently operates at default ODR of 100 Hz
> + */
> + usleep_range(1100, 11100);
That's a huge range to allow... I'm not following the argument for why.
Or do we have a stray 0?
> +
> + ret = regmap_read(data->regmap, ADXL345_REG_INT_SOURCE, &val);
> + if (ret < 0)
> + return ret;
> + if ((val & ADXL345_INT_DATA_READY) == ADXL345_INT_DATA_READY)
> + return 0;
> + } while (--tries);
> + dev_err(dev, "Data is not yet ready, try again.\n");
> +
This is almost certainly a hardware fault. I'd be more brutal with
the error and return -EIO. If you get here your hardware is very unlikely
to be working correctly if you try again.
> + return -EAGAIN;
> +}
> +
> #define ADXL345_CHANNEL(reg, axis) { \
> .type = IIO_ACCEL, \
> .modified = 1, \
> @@ -72,6 +118,19 @@ static int adxl345_read_raw(struct iio_dev *indio_dev,
>
> switch (mask) {
> case IIO_CHAN_INFO_RAW:
> + mutex_lock(&data->lock);
> + ret = adxl345_set_mode(data, ADXL345_POWER_CTL_MEASURE);
> + if (ret < 0) {
> + mutex_unlock(&data->lock);
> + return ret;
> +
[PATCH 5/6] Drivers: hv: vmbus: Fix rescind handling
From: K. Y. Srinivasan
Fix the rescind handling. This patch addresses the following rescind
scenario that is currently not handled correctly:
If a rescind were to be received while the offer is still being
peocessed, we will be blocked indefinitely since the rescind message
is handled on the same work element as the offer message. Fix this
issue.
I would like to thank Dexuan Cui and
Long Li for working with me on this patch.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel.c |8 -
drivers/hv/channel_mgmt.c | 69 ++--
drivers/hv/connection.c |7 +++-
drivers/hv/hyperv_vmbus.h |7
drivers/hv/vmbus_drv.c| 29 ++-
5 files changed, 99 insertions(+), 21 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 736ac76..e9bf0bb 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -630,9 +630,13 @@ void vmbus_close(struct vmbus_channel *channel)
*/
list_for_each_safe(cur, tmp, &channel->sc_list) {
cur_channel = list_entry(cur, struct vmbus_channel, sc_list);
- if (cur_channel->state != CHANNEL_OPENED_STATE)
- continue;
vmbus_close_internal(cur_channel);
+ if (cur_channel->rescind) {
+ mutex_lock(&vmbus_connection.channel_mutex);
+ hv_process_channel_removal(cur_channel,
+ cur_channel->offermsg.child_relid);
+ mutex_unlock(&vmbus_connection.channel_mutex);
+ }
}
/*
* Now close the primary.
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index eec616a..06529b3 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -428,7 +428,6 @@ void vmbus_free_channels(void)
{
struct vmbus_channel *channel, *tmp;
- mutex_lock(&vmbus_connection.channel_mutex);
list_for_each_entry_safe(channel, tmp, &vmbus_connection.chn_list,
listentry) {
/* hv_process_channel_removal() needs this */
@@ -436,7 +435,6 @@ void vmbus_free_channels(void)
vmbus_device_unregister(channel->device_obj);
}
- mutex_unlock(&vmbus_connection.channel_mutex);
}
/*
@@ -483,8 +481,10 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
list_add_tail(&newchannel->sc_list, &channel->sc_list);
channel->num_sc++;
spin_unlock_irqrestore(&channel->lock, flags);
- } else
+ } else {
+ atomic_dec(&vmbus_connection.offer_in_progress);
goto err_free_chan;
+ }
}
dev_type = hv_get_dev_type(newchannel);
@@ -511,6 +511,7 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
if (!fnew) {
if (channel->sc_creation_callback != NULL)
channel->sc_creation_callback(newchannel);
+ atomic_dec(&vmbus_connection.offer_in_progress);
return;
}
@@ -532,9 +533,7 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
* binding which eventually invokes the device driver's AddDevice()
* method.
*/
- mutex_lock(&vmbus_connection.channel_mutex);
ret = vmbus_device_register(newchannel->device_obj);
- mutex_unlock(&vmbus_connection.channel_mutex);
if (ret != 0) {
pr_err("unable to add child device object (relid %d)\n",
@@ -542,6 +541,8 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
kfree(newchannel->device_obj);
goto err_deq_chan;
}
+
+ atomic_dec(&vmbus_connection.offer_in_progress);
return;
err_deq_chan:
@@ -799,6 +800,7 @@ static void vmbus_onoffer(struct
vmbus_channel_message_header *hdr)
newchannel = alloc_channel();
if (!newchannel) {
vmbus_release_relid(offer->child_relid);
+ atomic_dec(&vmbus_connection.offer_in_progress);
pr_err("Unable to allocate channel object\n");
return;
}
@@ -845,16 +847,38 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
rescind = (struct vmbus_channel_rescind_offer *)hdr;
+ /*
+* The offer msg and the corresponding rescind msg
+* from the host are guranteed to be ordered -
+* offer comes in first and then the rescind.
+* Since we process these events in work elements,
+* and with preemption, we may end up processing
+* the events out of order. Given that we handle these
+* work elements on the same CPU, this is possible only
+* in the case of preemption. In any case wait here
+* until the offer proces
[PATCH 4/6] Drivers: hv: util: Make hv_poll_channel() a little more efficient
From: K. Y. Srinivasan
The current code unconditionally sends an IPI. If we are running on the
correct CPU and are in interrupt level, we don't need an IPI.
Make this adjustment.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hyperv_vmbus.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 6113e91..fa514be 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -411,6 +411,10 @@ static inline void hv_poll_channel(struct vmbus_channel
*channel,
if (!channel)
return;
+ if (in_interrupt() && (channel->target_cpu == smp_processor_id())) {
+ cb(channel);
+ return;
+ }
smp_call_function_single(channel->target_cpu, cb, channel, true);
}
--
1.7.1
[PATCH 3/6] Drivers: hv: vmbus: Fix error code returned by vmbus_post_msg()
From: K. Y. Srinivasan ENOBUFS is a more approrpiate error code to be returned when the hypervisor cannot post the message because of insufficient buffers. Make the adjustment. Signed-off-by: K. Y. Srinivasan --- drivers/hv/connection.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c index fce27fb..a938fcf 100644 --- a/drivers/hv/connection.c +++ b/drivers/hv/connection.c @@ -370,7 +370,7 @@ int vmbus_post_msg(void *buffer, size_t buflen, bool can_sleep) break; case HV_STATUS_INSUFFICIENT_MEMORY: case HV_STATUS_INSUFFICIENT_BUFFERS: - ret = -ENOMEM; + ret = -ENOBUFS; break; case HV_STATUS_SUCCESS: return ret; -- 1.7.1
Re: [PATCH v1] LSM: Enable multiple calls to security_add_hooks() for the same LSM
On Sat, 29 Apr 2017, Mickaël Salaün wrote:
> Check if the registering LSM already registered hooks just before. This
> enable to split hook declarations into multiple files without
> registering multiple time the same LSM name, starting from commit
> d69dece5f5b6 ("LSM: Add /sys/kernel/security/lsm").
Please include a detailed rationale for these patches. The above tells us
very little about why they are needed.
--
James Morris
[PATCH 6/6] HV: properly delay KVP packets when negotiation is in progress
From: Long Li
The host may send multiple negotiation packets
(due to timeout) before the KVP user-mode daemon
is connected. KVP user-mode daemon is connected.
We need to defer processing those packets
until the daemon is negotiated and connected.
It's okay for guest to respond
to all negotiation packets.
In addition, the host may send multiple staged
KVP requests as soon as negotiation is done.
We need to properly process those packets using one
tasklet for exclusive access to ring buffer.
This patch is based on the work of
Nick Meier .
Signed-off-by: Long Li
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_kvp.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index e99ff2d..9a90b91 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -112,7 +112,7 @@ static void kvp_poll_wrapper(void *channel)
{
/* Transaction is finished, reset the state here to avoid races. */
kvp_transaction.state = HVUTIL_READY;
- hv_kvp_onchannelcallback(channel);
+ tasklet_schedule(&((struct vmbus_channel *)channel)->callback_event);
}
static void kvp_register_done(void)
@@ -159,7 +159,7 @@ static void kvp_timeout_func(struct work_struct *dummy)
static void kvp_host_handshake_func(struct work_struct *dummy)
{
- hv_poll_channel(kvp_transaction.recv_channel, hv_kvp_onchannelcallback);
+ tasklet_schedule(&kvp_transaction.recv_channel->callback_event);
}
static int kvp_handle_handshake(struct hv_kvp_msg *msg)
@@ -625,16 +625,17 @@ void hv_kvp_onchannelcallback(void *context)
NEGO_IN_PROGRESS,
NEGO_FINISHED} host_negotiatied = NEGO_NOT_STARTED;
- if (host_negotiatied == NEGO_NOT_STARTED &&
- kvp_transaction.state < HVUTIL_READY) {
+ if (kvp_transaction.state < HVUTIL_READY) {
/*
* If userspace daemon is not connected and host is asking
* us to negotiate we need to delay to not lose messages.
* This is important for Failover IP setting.
*/
- host_negotiatied = NEGO_IN_PROGRESS;
- schedule_delayed_work(&kvp_host_handshake_work,
+ if (host_negotiatied == NEGO_NOT_STARTED) {
+ host_negotiatied = NEGO_IN_PROGRESS;
+ schedule_delayed_work(&kvp_host_handshake_work,
HV_UTIL_NEGO_TIMEOUT * HZ);
+ }
return;
}
if (kvp_transaction.state > HVUTIL_READY)
@@ -702,6 +703,7 @@ void hv_kvp_onchannelcallback(void *context)
VM_PKT_DATA_INBAND, 0);
host_negotiatied = NEGO_FINISHED;
+ hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
}
}
--
1.7.1
[PATCH 2/6] tools: hv: properly handle long paths
From: Vitaly Kuznetsov
Paths can be up to PATH_MAX long and PATH_MAX is usually greater than 256.
While on it, simplify path reconstruction to a simple snprintf(), define
and reuse KVP_NET_DIR.
Suggested-by: Tomas Hozza
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
tools/hv/hv_kvp_daemon.c | 44 ++--
1 files changed, 18 insertions(+), 26 deletions(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index f1758fc..88b20e0 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
/*
@@ -97,6 +98,8 @@ enum {
#define KVP_SCRIPTS_PATH "/usr/libexec/hypervkvpd/"
#endif
+#define KVP_NET_DIR "/sys/class/net/"
+
#define MAX_FILE_NAME 100
#define ENTRIES_PER_BLOCK 50
@@ -596,26 +599,21 @@ void kvp_get_os_info(void)
DIR *dir;
struct dirent *entry;
FILE*file;
- char*p, *q, *x;
+ char*p, *x;
char*if_name = NULL;
charbuf[256];
- char *kvp_net_dir = "/sys/class/net/";
- char dev_id[256];
+ char dev_id[PATH_MAX];
- dir = opendir(kvp_net_dir);
+ dir = opendir(KVP_NET_DIR);
if (dir == NULL)
return NULL;
- snprintf(dev_id, sizeof(dev_id), "%s", kvp_net_dir);
- q = dev_id + strlen(kvp_net_dir);
-
while ((entry = readdir(dir)) != NULL) {
/*
* Set the state for the next pass.
*/
- *q = '\0';
- strcat(dev_id, entry->d_name);
- strcat(dev_id, "/device/device_id");
+ snprintf(dev_id, sizeof(dev_id), "%s%s/device/device_id",
+KVP_NET_DIR, entry->d_name);
file = fopen(dev_id, "r");
if (file == NULL)
@@ -653,12 +651,12 @@ void kvp_get_os_info(void)
FILE*file;
char*p, *x;
charbuf[256];
- char addr_file[256];
+ char addr_file[PATH_MAX];
unsigned int i;
char *mac_addr = NULL;
- snprintf(addr_file, sizeof(addr_file), "%s%s%s", "/sys/class/net/",
- if_name, "/address");
+ snprintf(addr_file, sizeof(addr_file), "%s%s%s", KVP_NET_DIR,
+if_name, "/address");
file = fopen(addr_file, "r");
if (file == NULL)
@@ -688,28 +686,22 @@ void kvp_get_os_info(void)
DIR *dir;
struct dirent *entry;
FILE*file;
- char*p, *q, *x;
+ char*p, *x;
char*if_name = NULL;
charbuf[256];
- char *kvp_net_dir = "/sys/class/net/";
- char dev_id[256];
+ char dev_id[PATH_MAX];
unsigned int i;
- dir = opendir(kvp_net_dir);
+ dir = opendir(KVP_NET_DIR);
if (dir == NULL)
return NULL;
- snprintf(dev_id, sizeof(dev_id), "%s", kvp_net_dir);
- q = dev_id + strlen(kvp_net_dir);
-
while ((entry = readdir(dir)) != NULL) {
/*
* Set the state for the next pass.
*/
- *q = '\0';
-
- strcat(dev_id, entry->d_name);
- strcat(dev_id, "/address");
+ snprintf(dev_id, sizeof(dev_id), "%s%s/address", KVP_NET_DIR,
+entry->d_name);
file = fopen(dev_id, "r");
if (file == NULL)
@@ -1218,9 +1210,9 @@ static int process_ip_string(FILE *f, char *ip_string,
int type)
static int kvp_set_ip_info(char *if_name, struct hv_kvp_ipaddr_value *new_val)
{
int error = 0;
- char if_file[128];
+ char if_file[PATH_MAX];
FILE *file;
- char cmd[512];
+ char cmd[PATH_MAX];
char *mac_addr;
/*
--
1.7.1
[PATCH 1/6] Tools: hv: vss: Thaw the filesystem and continue if freeze call has timed out
From: Alex Ng
If a FREEZE operation takes too long, the driver may time out and move on
to another operation. The daemon is unaware of this and attempts to
notify the driver that the FREEZE succeeded. This results in an error from
the driver and the daemon leaves the filesystem in frozen state.
Fix this by thawing the filesystem and continuing.
Signed-off-by: Michael Gissing
Signed-off-by: Alex Ng
Signed-off-by: K. Y. Srinivasan
---
tools/hv/hv_vss_daemon.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index e082980..7ba5419 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -261,7 +261,9 @@ int main(int argc, char *argv[])
if (len != sizeof(struct hv_vss_msg)) {
syslog(LOG_ERR, "write failed; error: %d %s", errno,
strerror(errno));
- exit(EXIT_FAILURE);
+
+ if (op == VSS_OP_FREEZE)
+ vss_operate(VSS_OP_THAW);
}
}
--
1.7.1
[PATCH 0/6] Drivers: hv: Miscellaneous fixes
From: K. Y. Srinivasan Miscellaneous fixes to vmbus and util drivers. Alex Ng (1): Tools: hv: vss: Thaw the filesystem and continue if freeze call has timed out K. Y. Srinivasan (3): Drivers: hv: vmbus: Fix error code returned by vmbus_post_msg() Drivers: hv: util: Make hv_poll_channel() a little more efficient Drivers: hv: vmbus: Fix rescind handling Long Li (1): HV: properly delay KVP packets when negotiation is in progress Vitaly Kuznetsov (1): tools: hv: properly handle long paths drivers/hv/channel.c |8 - drivers/hv/channel_mgmt.c | 69 ++-- drivers/hv/connection.c |9 -- drivers/hv/hv_kvp.c | 14 + drivers/hv/hyperv_vmbus.h | 11 +++ drivers/hv/vmbus_drv.c| 29 ++- tools/hv/hv_kvp_daemon.c | 44 - tools/hv/hv_vss_daemon.c |4 ++- 8 files changed, 133 insertions(+), 55 deletions(-)
Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference
On Sat, Apr 29, 2017 at 01:17:26PM +0300, Kirill A. Shutemov wrote: > On Fri, Apr 28, 2017 at 03:33:07PM -0400, Jerome Glisse wrote: > > On Fri, Apr 28, 2017 at 12:22:24PM -0700, Dan Williams wrote: > > > Are you sure about needing to hook the 2 -> 1 transition? Could we > > > change ZONE_DEVICE pages to not have an elevated reference count when > > > they are created so you can keep the HMM references out of the mm hot > > > path? > > > > 100% sure on that :) I need to callback into driver for 2->1 transition > > no way around that. If we change ZONE_DEVICE to not have an elevated > > reference count that you need to make a lot more change to mm so that > > ZONE_DEVICE is never use as fallback for memory allocation. Also need > > to make change to be sure that ZONE_DEVICE page never endup in one of > > the path that try to put them back on lru. There is a lot of place that > > would need to be updated and it would be highly intrusive and add a > > lot of special cases to other hot code path. > > Could you explain more on where the requirement comes from or point me to > where I can read about this. > HMM ZONE_DEVICE pages are use like other pages (anonymous or file back page) in _any_ vma. So i need to know when a page is freed ie either as result of unmap, exit or migration or anything that would free the memory. For zone device a page is free once its refcount reach 1 so i need to catch refcount transition from 2->1 This is the only way i can inform the device that the page is now free. See https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-v21&id=52da8fe1a088b87b5321319add79e43b8372ed7d There is _no_ way around that. Cheers, Jérôme
Re: [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2)
On Wed 2017-04-26 15:23:37, Pavel Machek wrote:
> Hi!
>
> > > > I don't see why it would be hard to open files or have threads inside
> > > > a library. There are several libraries that do that already, specially
> > > > the ones designed to be used on multimidia apps.
> > >
> > > Well, This is what the libv4l2 says:
> > >
> > >This file implements libv4l2, which offers v4l2_ prefixed versions
> > >of
> > > open/close/etc. The API is 100% the same as directly opening
> > >/dev/videoX
> > > using regular open/close/etc, the big difference is that format
> > >conversion
> > >
> > > but if I open additional files in v4l2_open(), API is no longer the
> > > same, as unix open() is defined to open just one file descriptor.
> > >
> > > Now. There is autogain support in libv4lconvert, but it expects to use
> > > same fd for camera and for the gain... which does not work with
> > > subdevs.
> > >
> > > Of course, opening subdevs by name like this is not really
> > > acceptable. But can you suggest a method that is?
> >
> > There are two separate things here:
> >
> > 1) Autofoucs for a device that doesn't use subdev API
> > 2) libv4l2 support for devices that require MC and subdev API
>
> Actually there are three: 0) autogain. Unfortunately, I need autogain
> first before autofocus has a chance...
>
> And that means... bayer10 support for autogain.
>
> Plus, I changed avg_lum to long long. Quick calculation tells me int
> could overflow with few megapixel sensor.
>
> Oh, btw http://ytse.tricolour.net/docs/LowLightOptimization.html no
> longer works.
Can I get some comments here? Patch will need fixup (constants need
adjusting), but is style/design acceptable?
Thanks,
Pavel
> diff --git a/lib/libv4lconvert/processing/autogain.c
> b/lib/libv4lconvert/processing/autogain.c
> index c6866d6..0b52d0f 100644
> --- a/lib/libv4lconvert/processing/autogain.c
> +++ b/lib/libv4lconvert/processing/autogain.c
> @@ -68,6 +71,41 @@ static void autogain_adjust(struct v4l2_queryctrl *ctrl,
> int *value,
> }
> }
>
> +static int get_luminosity_bayer10(uint16_t *buf, const struct v4l2_format
> *fmt)
> +{
> + long long avg_lum = 0;
> + int x, y;
> +
> + buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 +
> + fmt->fmt.pix.width / 4;
> +
> + for (y = 0; y < fmt->fmt.pix.height / 2; y++) {
> + for (x = 0; x < fmt->fmt.pix.width / 2; x++)
> + avg_lum += *buf++;
> + buf += fmt->fmt.pix.bytesperline - fmt->fmt.pix.width / 2;
> + }
> + avg_lum /= fmt->fmt.pix.height * fmt->fmt.pix.width / 4;
> + avg_lum /= 4;
> + return avg_lum;
> +}
> +
> +static int get_luminosity_bayer8(unsigned char *buf, const struct
> v4l2_format *fmt)
> +{
> + long long avg_lum = 0;
> + int x, y;
> +
> + buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 +
> + fmt->fmt.pix.width / 4;
> +
> + for (y = 0; y < fmt->fmt.pix.height / 2; y++) {
> + for (x = 0; x < fmt->fmt.pix.width / 2; x++)
> + avg_lum += *buf++;
> + buf += fmt->fmt.pix.bytesperline - fmt->fmt.pix.width / 2;
> + }
> + avg_lum /= fmt->fmt.pix.height * fmt->fmt.pix.width / 4;
> + return avg_lum;
> +}
> +
> /* auto gain and exposure algorithm based on the knee algorithm described
> here:
> http://ytse.tricolour.net/docs/LowLightOptimization.html */
> static int autogain_calculate_lookup_tables(
> @@ -100,17 +142,16 @@ static int autogain_calculate_lookup_tables(
> switch (fmt->fmt.pix.pixelformat) {
> + case V4L2_PIX_FMT_SGBRG10:
> + case V4L2_PIX_FMT_SGRBG10:
> + case V4L2_PIX_FMT_SBGGR10:
> + case V4L2_PIX_FMT_SRGGB10:
> + avg_lum = get_luminosity_bayer10((void *) buf, fmt);
> + break;
> +
> case V4L2_PIX_FMT_SGBRG8:
> case V4L2_PIX_FMT_SGRBG8:
> case V4L2_PIX_FMT_SBGGR8:
> case V4L2_PIX_FMT_SRGGB8:
> - buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 +
> - fmt->fmt.pix.width / 4;
> -
> - for (y = 0; y < fmt->fmt.pix.height / 2; y++) {
> - for (x = 0; x < fmt->fmt.pix.width / 2; x++)
> - avg_lum += *buf++;
> - buf += fmt->fmt.pix.bytesperline - fmt->fmt.pix.width /
> 2;
> - }
> - avg_lum /= fmt->fmt.pix.height * fmt->fmt.pix.width / 4;
> + avg_lum = get_luminosity_bayer8(buf, fmt);
> break;
>
> case V4L2_PIX_FMT_RGB24:
> diff --git a/lib/libv4lconvert/processing/libv4lprocessing.c
> b/lib/libv4lconvert/processing/libv4lprocessing.c
> index b061f50..b98d024 100644
> --- a/lib/libv4lconvert/processing/libv4lprocessing.c
> +++ b/lib/libv4lconvert/processing/libv4lprocessing.c
> @@ -164,6 +165,10 @@ void v4lprocessing_processing(struct v4lproce
Re: [patch] timer: Fix timers_update_migration(), and call it in tmigr_init()
On Sat, Apr 29, 2017 at 09:36:37PM -0700, Paul E. McKenney wrote: > On Sun, Apr 30, 2017 at 06:20:15AM +0200, Mike Galbraith wrote: > > On Sat, 2017-04-29 at 20:43 -0700, Paul E. McKenney wrote: > > > On Sun, Apr 30, 2017 at 03:21:58AM +0200, Mike Galbraith wrote: > > > > On Sat, 2017-04-29 at 14:45 -0700, Paul E. McKenney wrote: > > > > > On Sat, Apr 29, 2017 at 08:20:33PM +0200, Mike Galbraith wrote: > > > > > > On Sat, 2017-04-29 at 11:06 -0700, Paul E. McKenney wrote: > > > > > > > > > > > > > If someone will either repost a fresh series or point me at > > > > > > > exactly > > > > > > > the set of patches to use, I will run it through rcutorture again. > > > > > > > > > > > > Patchlet is against x86-tip/master.today. > > > > > > > > > > So today's (as in Saturday April 29) x86-tip/master with the following > > > > > patch applied? > > > > > > > > Yeah. > > > > > > OK, will fire it up once the current set of overnight tests complete. > > > > I certainly don't want to discourage you from beating hell outta tip, > > just want to make sure you know that I'm seeing zero RCU woes, only > > late timer expiry (sharpening rocks/sticks to focus trace). > > I got timer_migration splats from an earlier rcutorture run. Please see > message-ID <20170421192853.gd3...@linux.vnet.ibm.com> on LKML on April > 21st in reply to Thomas's V2 00/10 cover letter. So I am curious to > learn if your patches fix them. And sadly, the splats are still there. Please see the following for the relevant console output and .config files: http://www2.rdrop.com/users/paulmck/submission/TREE04.2017.04.30a.config http://www2.rdrop.com/users/paulmck/submission/TREE04.2017.04.30a.console.log http://www2.rdrop.com/users/paulmck/submission/TREE04.3.2017.04.30a.console.log http://www2.rdrop.com/users/paulmck/submission/TREE07.2017.04.30a.config http://www2.rdrop.com/users/paulmck/submission/TREE07.2.2017.04.30a.bzImage http://www2.rdrop.com/users/paulmck/submission/TREE07.2017.04.30a.console.log http://www2.rdrop.com/users/paulmck/submission/TREE07.2.2017.04.30a.console.log Please let me know if you have any trouble accessing these. Here is the first splat from the first TREE04 run: [3.310642] WARNING: CPU: 1 PID: 0 at /home/paulmck/public_git/timer-tip/kernel/time/timer_migration.c:387 tmigr_set_cpu_active+0xc6/0xe0 [3.313210] Modules linked in: [3.313861] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.11.0-rc8+ #1 [3.315196] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 [3.317196] task: 8c1fde9f task.stack: 8e4fc0124000 [3.318433] RIP: 0010:tmigr_set_cpu_active+0xc6/0xe0 [3.319464] RSP: :8e4fc0127e90 EFLAGS: 00010046 [3.320598] RAX: 0004 RBX: 0001 RCX: 001f [3.322146] RDX: 0001 RSI: 8c1fdfc54cc8 RDI: 8c1fdeb26f80 [3.323652] RBP: 8e4fc0127ea8 R08: R09: 0008 [3.325237] R10: 8e4fc0127e80 R11: 0400 R12: 8c1fdeb26f80 [3.326699] R13: 8c1fdfc54cc8 R14: R15: [3.328149] FS: () GS:8c1fdfc4() knlGS: [3.329845] CS: 0010 DS: ES: CR0: 80050033 [3.331078] CR2: 8e4fc02f CR3: 15e0a000 CR4: 06e0 [3.332509] Call Trace: [3.333107] tmigr_cpu_activate+0x36/0x40 [3.333972] tick_nohz_idle_exit+0xd1/0xf0 [3.334845] do_idle+0x113/0x170 [3.335501] cpu_startup_entry+0x18/0x20 [3.336338] start_secondary+0xe8/0xf0 [3.337147] secondary_startup_64+0x9f/0x9f [3.337998] Code: d0 48 8b 03 48 85 c0 75 eb eb a0 49 8b 7c 24 50 41 89 5c 24 08 48 85 ff 74 8c 49 8d 74 24 20 89 da e8 3f ff ff ff e9 7b ff ff ff <0f> ff 41 c6 04 24 00 5b 41 5c 41 5d 5d c3 66 90 66 2e 0f 1f 8 This is the first WARN_ON() in tmigr_set_cpu_active(). I got four splats in 12 hours of running the rcutorture TREE04 test scenario, that is, three runs of four hours each. The TREE07 runs fared worse, with many more splats, starting with a page fault. The scripting claimed a hang, but that looks to have instead been so many splats that the test failed to terminate itself in time. I ran two TREE07 runs of four hours each. Thanx, Paul
Re: [RFC/PATCH] perf: Add sizeof operator support
Hi Jeremy, On 06/14/2016 12:38 PM, Jeremy Linton wrote: > There are a fair number of tracepoints in the kernel making > use of the sizeof operator. Allow perf to understand some of > those cases, and report a more informative error message for > the ones it cannot understand. What's the status of this patch series? Are you planning to update? Jon.
[PATCH] scsi: fas216: Add __printf validation, fix fallout
__printf makes the compiler check format and arguments.
Fix fallout.
Miscellanea:
o Convert formats to const char *
o Use vsprintf extension %pV instead of a static buffer.
o Add newline to logging and remove now unnecessary printk("\n")
o Use pr_cont where appropriate
Signed-off-by: Joe Perches
---
drivers/scsi/arm/fas216.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/arm/fas216.c b/drivers/scsi/arm/fas216.c
index 24388795ee9a..112bec886192 100644
--- a/drivers/scsi/arm/fas216.c
+++ b/drivers/scsi/arm/fas216.c
@@ -289,17 +289,20 @@ static char fas216_target(FAS216_Info *info)
return 'H';
}
-static void
-fas216_do_log(FAS216_Info *info, char target, char *fmt, va_list ap)
+__printf(3, 0) static void
+fas216_do_log(FAS216_Info *info, char target, const char *fmt, va_list ap)
{
- static char buf[1024];
+ struct va_format vaf;
+
+ vaf.fmt = fmt;
+ vaf.va = ≈
- vsnprintf(buf, sizeof(buf), fmt, ap);
- printk("scsi%d.%c: %s", info->host->host_no, target, buf);
+ printk("scsi%d.%c: %pV\n", info->host->host_no, target, &vaf);
}
+__printf(4, 5)
static void fas216_log_command(FAS216_Info *info, int level,
- struct scsi_cmnd *SCpnt, char *fmt, ...)
+ struct scsi_cmnd *SCpnt, const char *fmt, ...)
{
va_list args;
@@ -313,8 +316,9 @@ static void fas216_log_command(FAS216_Info *info, int level,
scsi_print_command(SCpnt);
}
-static void
-fas216_log_target(FAS216_Info *info, int level, int target, char *fmt, ...)
+__printf(4, 5) static void
+fas216_log_target(FAS216_Info *info, int level, int target,
+ const char *fmt, ...)
{
va_list args;
@@ -329,11 +333,10 @@ fas216_log_target(FAS216_Info *info, int level, int
target, char *fmt, ...)
va_start(args, fmt);
fas216_do_log(info, target, fmt, args);
va_end(args);
-
- printk("\n");
}
-static void fas216_log(FAS216_Info *info, int level, char *fmt, ...)
+__printf(3, 4)
+static void fas216_log(FAS216_Info *info, int level, const char *fmt, ...)
{
va_list args;
@@ -343,8 +346,6 @@ static void fas216_log(FAS216_Info *info, int level, char
*fmt, ...)
va_start(args, fmt);
fas216_do_log(info, fas216_target(info), fmt, args);
va_end(args);
-
- printk("\n");
}
#define PH_SIZE32
@@ -431,7 +432,7 @@ fas216_get_last_msg(FAS216_Info *info, int pos)
}
fas216_log(info, LOG_MESSAGES,
- "Message: %04x found at position %02x\n", packed_msg, pos);
+ "Message: %04x found at position %02x", packed_msg, pos);
return packed_msg;
}
@@ -725,7 +726,7 @@ static void fas216_cleanuptransfer(FAS216_Info *info)
fifo = fas216_readb(info, REG_CFIS) & CFIS_CF;
fas216_log(info, LOG_BUFFER, "cleaning up from previous "
- "transfer: length 0x%06x, residual 0x%x, fifo %d",
+ "transfer: length 0x%06lx, residual 0x%lx, fifo %ld",
total, residual, fifo);
/*
@@ -1144,8 +1145,8 @@ static void fas216_parse_message(FAS216_Info *info,
unsigned char *message, int
fas216_log(info, 0, "unrecognised message, rejecting");
printk("scsi%d.%c: message was", info->host->host_no,
fas216_target(info));
for (i = 0; i < msglen; i++)
- printk("%s%02X", i & 31 ? " " : "\n ", message[i]);
- printk("\n");
+ pr_cont("%s%02X", i & 31 ? " " : "\n ", message[i]);
+ pr_cont("\n");
/*
* Something strange seems to be happening here -
@@ -1582,7 +1583,7 @@ static void fas216_funcdone_intr(FAS216_Info *info,
unsigned int stat, unsigned
default:
fas216_log(info, 0, "internal phase %s for function done?"
" What do I do with this?",
- fas216_target(info), fas216_drv_phase(info));
+ fas216_drv_phase(info));
}
}
@@ -1642,7 +1643,7 @@ irqreturn_t fas216_intr(FAS216_Info *info)
fas216_bus_reset(info);
scsi_report_bus_reset(info->host, 0);
} else if (inst & INST_ILLEGALCMD) {
- fas216_log(info, LOG_ERROR, "illegal command given\n");
+ fas216_log(info, LOG_ERROR, "illegal command given");
fas216_dumpstate(info);
print_debug_list();
} else if (inst & INST_DISCONNECT)
--
2.10.0.rc2.1.g053435c
Re: [PATCH] SPCR: check bit width for the 16550 UART
On 12/13/2016 01:20 AM, Jon Masters wrote: > On 12/07/2016 10:23 AM, Mark Salter wrote: >> If you specify a baudrate with earlycon=, the driver tries to set that >> baudrate and if you have an 8250 with some non-standard baud clock, then >> it will fail. Perhaps SPCR shouldn't pass baud option to setup_earlycon(). > > Yet they seem to explicitly want to do this...in my conversations with some > others we agree that, in many cases, you really want to say "leave the baud > whatever the firmware set it", which would work in this case, but might > break some others. Then again, nobody on x86 Linux is really using the > SPCR today due to it not having been something they used until now and > due to the location of the COM ports being fairly well known ;) > > So who knows what folks will prefer, but we should at least get the spec > to cover both situations by explicitly calling out Applied as special. > So I've been discussing some changes to the SPCR and the current proposal > is that we have two new subtypes - one for 16550s that are non-standard > register width/stride but use the typical base clock, and a specific > additional type for SBSA level 0 compatible 16550 UARTs (Applied). I > will followup when the specification document has been revised. As an update. I've been speaking with friends at Microsoft on and off about this for quite some time. They've been very helpful (as usual) and we should get an SPCR update soon covering Applied's case. I have pinged the APM team to make sure that they're ready to post a patch. I would like this small fix squeezed in 4.12, but before 4.13. Jon.
[PATCH 3/3] led: ledtrig-transient: add support for hrtimer
This patch adds a hrtimer to ledtrig-transient so that when driver is
registered with LED_BRIGHTNESS_FAST, the hrtimer is used for the better
time accuracy in handling the duration.
Signed-off-by: David Lin
---
drivers/leds/trigger/ledtrig-transient.c | 59 +---
1 file changed, 54 insertions(+), 5 deletions(-)
diff --git a/drivers/leds/trigger/ledtrig-transient.c
b/drivers/leds/trigger/ledtrig-transient.c
index 7e6011bd3646..63be54772596 100644
--- a/drivers/leds/trigger/ledtrig-transient.c
+++ b/drivers/leds/trigger/ledtrig-transient.c
@@ -24,15 +24,18 @@
#include
#include
#include
+#include
#include
#include "../leds.h"
struct transient_trig_data {
+ struct led_classdev *led_cdev;
int activate;
int state;
int restore_state;
unsigned long duration;
struct timer_list timer;
+ struct hrtimer hrtimer;
};
static void transient_timer_function(unsigned long data)
@@ -44,6 +47,54 @@ static void transient_timer_function(unsigned long data)
led_set_brightness_nosleep(led_cdev, transient_data->restore_state);
}
+static enum hrtimer_restart transient_hrtimer_function(struct hrtimer *timer)
+{
+ struct transient_trig_data *transient_data =
+ container_of(timer, struct transient_trig_data, hrtimer);
+
+ transient_timer_function((unsigned long)transient_data->led_cdev);
+
+ return HRTIMER_NORESTART;
+}
+
+static inline void transient_timer_setup(struct led_classdev *led_cdev)
+{
+ struct transient_trig_data *tdata = led_cdev->trigger_data;
+
+ if (led_cdev->flags & LED_BRIGHTNESS_FAST) {
+ tdata->led_cdev = led_cdev;
+ hrtimer_init(&tdata->hrtimer, CLOCK_MONOTONIC,
+HRTIMER_MODE_REL);
+ tdata->hrtimer.function = transient_hrtimer_function;
+ } else {
+ setup_timer(&tdata->timer, transient_timer_function,
+ (unsigned long)led_cdev);
+ }
+}
+
+static inline void transient_timer_start(struct led_classdev *led_cdev)
+{
+ struct transient_trig_data *tdata = led_cdev->trigger_data;
+
+ if (led_cdev->flags & LED_BRIGHTNESS_FAST) {
+ hrtimer_start(&tdata->hrtimer, ms_to_ktime(tdata->duration),
+ HRTIMER_MODE_REL);
+ } else {
+ mod_timer(&tdata->timer,
+ jiffies + msecs_to_jiffies(tdata->duration));
+ }
+}
+
+static inline void transient_timer_cancel(struct led_classdev *led_cdev)
+{
+ struct transient_trig_data *tdata = led_cdev->trigger_data;
+
+ if (led_cdev->flags & LED_BRIGHTNESS_FAST)
+ hrtimer_cancel(&tdata->hrtimer);
+ else
+ del_timer_sync(&tdata->timer);
+}
+
static ssize_t transient_activate_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -70,7 +121,7 @@ static ssize_t transient_activate_store(struct device *dev,
/* cancel the running timer */
if (state == 0 && transient_data->activate == 1) {
- del_timer(&transient_data->timer);
+ transient_timer_cancel(led_cdev);
transient_data->activate = state;
led_set_brightness_nosleep(led_cdev,
transient_data->restore_state);
@@ -84,8 +135,7 @@ static ssize_t transient_activate_store(struct device *dev,
led_set_brightness_nosleep(led_cdev, transient_data->state);
transient_data->restore_state =
(transient_data->state == LED_FULL) ? LED_OFF : LED_FULL;
- mod_timer(&transient_data->timer,
- jiffies + msecs_to_jiffies(transient_data->duration));
+ transient_timer_start(led_cdev);
}
/* state == 0 && transient_data->activate == 0
@@ -182,8 +232,7 @@ static void transient_trig_activate(struct led_classdev
*led_cdev)
if (rc)
goto err_out_state;
- setup_timer(&tdata->timer, transient_timer_function,
- (unsigned long) led_cdev);
+ transient_timer_setup(led_cdev);
led_cdev->activated = true;
return;
--
2.13.0.rc0.306.g87b477812d-goog
[PATCH 2/3] leds: Add the LED_BRIGHTNESS_FAST flag
This patch adds the LED_BRIGHTNESS_FAST flag to allow the driver to
indicate that the brightness_set() callback is implemented on a fastpath
so that the LED core may choose to for example use a hrtimer to
implement the duration of a trigger for better timing accuracy.
Suggested-by: Jacek Anaszewski
Signed-off-by: David Lin
---
Documentation/leds/leds-class.txt | 5 +
include/linux/leds.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/Documentation/leds/leds-class.txt
b/Documentation/leds/leds-class.txt
index 836cb16d6f09..70d7a3dca621 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -80,6 +80,11 @@ flag must be set in flags before registering. Calling
led_classdev_notify_brightness_hw_changed on a classdev not registered with
the LED_BRIGHT_HW_CHANGED flag is a bug and will trigger a WARN_ON.
+Optionally, the driver may choose to register with the LED_BRIGHTNESS_FAST
flag.
+This flag indicates that the driver implements the brightness_set() callback
+function using a fastpath so the LED core can use hrtimer if the driver
requires
+high precision for the trigger timing.
+
Hardware accelerated blink of LEDs
==
diff --git a/include/linux/leds.h b/include/linux/leds.h
index f9d10a9efcbe..78d2880ccd39 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -49,6 +49,7 @@ struct led_classdev {
#define LED_HW_PLUGGABLE BIT(19)
#define LED_PANIC_INDICATORBIT(20)
#define LED_BRIGHT_HW_CHANGED BIT(21)
+#define LED_BRIGHTNESS_FASTBIT(22)
/* set_brightness_work / blink_timer flags, atomic, private. */
unsigned long work_flags;
--
2.13.0.rc0.306.g87b477812d-goog
[PATCH 1/3] leds: Replace flags bit shift with BIT() macros
This is for readability as well as to avoid checkpatch warnings when
adding new bit flag information in the future.
Signed-off-by: David Lin
---
include/linux/leds.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 64c56d454f7d..f9d10a9efcbe 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -43,12 +43,12 @@ struct led_classdev {
#define LED_SUSPENDED (1 << 0)
#define LED_UNREGISTERING (1 << 1)
/* Upper 16 bits reflect control information */
-#define LED_CORE_SUSPENDRESUME (1 << 16)
-#define LED_SYSFS_DISABLE (1 << 17)
-#define LED_DEV_CAP_FLASH (1 << 18)
-#define LED_HW_PLUGGABLE (1 << 19)
-#define LED_PANIC_INDICATOR(1 << 20)
-#define LED_BRIGHT_HW_CHANGED (1 << 21)
+#define LED_CORE_SUSPENDRESUME BIT(16)
+#define LED_SYSFS_DISABLE BIT(17)
+#define LED_DEV_CAP_FLASH BIT(18)
+#define LED_HW_PLUGGABLE BIT(19)
+#define LED_PANIC_INDICATORBIT(20)
+#define LED_BRIGHT_HW_CHANGED BIT(21)
/* set_brightness_work / blink_timer flags, atomic, private. */
unsigned long work_flags;
--
2.13.0.rc0.306.g87b477812d-goog
[PATCH 0/3] led: ledtrig-transient: add support for hrtimer
Hi, These patch series add the LED_BRIGHTNESS_FAST flag support for ledtrig-transient to use hrtimer so that platforms with high-resolution timer support can have better accuracy in the trigger duration timing. The need for this support is driven by the fact that Android has removed the timed_ouput [1] and is now using led-trigger for handling vibrator control which requires the timer to be accurate up to a millisecond. However, this flag support would also allow hrtimer to co-exist with the ktimer without causing warning to the existing drivers [2]. David [1] https://patchwork.kernel.org/patch/8664831/ [2] https://lkml.org/lkml/2015/4/28/260 David Lin (3): leds: Replace flags bit shift with BIT() macros leds: Add the LED_BRIGHTNESS_FAST flag led: ledtrig-transient: add support for hrtimer Documentation/leds/leds-class.txt| 5 +++ drivers/leds/trigger/ledtrig-transient.c | 59 +--- include/linux/leds.h | 13 +++ 3 files changed, 66 insertions(+), 11 deletions(-) -- 2.13.0.rc0.306.g87b477812d-goog
Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update
On Wed, 26 Apr 2017, Vlastimil Babka wrote: > > Such an application typically already has such logic and executes a > > binding after discovering its numa node configuration on startup. It would > > have to be modified to redo that action when it gets some sort of a signal > > from the script telling it that the node config would be changed. > > > > Having this logic in the application instead of the kernel avoids all the > > kernel messes that we keep on trying to deal with and IMHO is much > > cleaner. > > That would be much simpler for us indeed. But we still IMHO can't > abruptly start denying page fault allocations for existing applications > that don't have the necessary awareness. We certainly can do that. The failure of the page faults are due to the admin trying to move an application that is not aware of this and is using mempols. That could be an error. Trying to move an application that contains both absolute and relative node numbers is definitely something that is potentiall so screwed up that the kernel should not muck around with such an app. Also user space can determine if the application is using memory policies and can then take appropriate measures (message to the sysadmin to eval tge situation f.e.) or mess aroud with the processes memory policies on its own. So this is certainly a way out of this mess.
Re: [PATCH 0/3] try to save some memory for kmem_cache in some cases
On Sun, 30 Apr 2017, Wei Yang wrote: > kmem_cache is a frequently used data in kernel. During the code reading, I > found maybe we could save some space in some cases. > > 1. On 64bit arch, type int will occupy a word if it doesn't sit well. > 2. cpu_slab->partial is just used when CONFIG_SLUB_CPU_PARTIAL is set > 3. cpu_partial is just used when CONFIG_SLUB_CPU_PARTIAL is set, while just > save some space on 32bit arch. This looks fine. But do we really want to add that amount of ifdeffery? How much memory does this save?
Re: [PATCH 1/3] ARM: dts: rockchip: Move cros-ec-sbs to rk3288-veyron-chromebook-sbs
Le dimanche 30 avril 2017 à 22:37 +0200, Heiko Stuebner a écrit :
> Hi Paul,
>
> Am Sonntag, 30. April 2017, 20:30:52 CEST schrieb Paul Kocialkowski:
> > This moves the cros-ec-sbs dtsi to a new rk3288-veyron-chromebook-sbs
> > dtsi since it only concerns rk3288 veyron Chromebooks.
> >
> > Other Chromebooks (such as the tegra124 nyans) also have sbs batteries
> > and don't use this dtsi, that only makes sense when used with
> > rk3288-veyron-chromebook anyway.
>
> That isn't true. The gru series (rk3399-based) also uses the
> sbs-battery [0]. And while it is currently limited to Rockchip-based
> Chromebooks it is nevertheless used on more than one platform, so
> the probability is high that it will be used in future series as well.
That's good to know, but as pointed out, other cros devices are using a sbs
battery without this header, so such a generic name isn't really a good fit.
Note that &charger has to be defined (after my subsequent patches), which it is
for devices that also include rk3288-veyron-chromebook, but not necessarily
others.
Overall, I think having one -sbs dtsi file makes sense here because there is
already a rk3288-veyron-chromebook dtsi that veyron chromebooks use. That file
cannot contain the battery bindings because minnie has a different one and it
would be a bit silly to copy it over all devices. That definitely makes sense.
As for other devices, I don't see why we should have a separate include file for
the battery instead of having it in the device's dts. I think this should be the
case on gru/kevin.
Also maybe not *all* gru-based devices will turn out to use a SBS battery, so it
seems early to include this header in the gru dtsi. One last point, gru/kevin
currently don't define a charger, which will break my subsequent patch (that is
however needed for the veyrons that use this file).
To me, it seems that there's little advantage and major drawbacks in keeping
this file the way it is.
> Also, it might be nice to also include some Chromeos people (there should
> be some in the git logs, like Brian who submitted the Gru patches), as they
> might be able to provide more detailed input.
That's a good point, thanks for including them.
>
> Heiko
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/a
> rch/arm64/boot/dts/rockchip/rk3399-gru.dtsi#n886
>
> >
> > Signed-off-by: Paul Kocialkowski
> > ---
> > .../boot/dts/{cros-ec-sbs.dtsi => rk3288-veyron-chromebook-sbs.dtsi}| 0
> > arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2
> > +-
> > arch/arm/boot/dts/rk3288-veyron-jerry.dts | 2
> > +-
> > arch/arm/boot/dts/rk3288-veyron-pinky.dts | 2
> > +-
> > arch/arm/boot/dts/rk3288-veyron-speedy.dts | 2
> > +-
> > 5 files changed, 4 insertions(+), 4 deletions(-)
> > rename arch/arm/boot/dts/{cros-ec-sbs.dtsi => rk3288-veyron-chromebook-
> > sbs.dtsi} (100%)
> >
> > diff --git a/arch/arm/boot/dts/cros-ec-sbs.dtsi b/arch/arm/boot/dts/rk3288-
> > veyron-chromebook-sbs.dtsi
> > similarity index 100%
> > rename from arch/arm/boot/dts/cros-ec-sbs.dtsi
> > rename to arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > index d33f5763c39c..f217a978e47a 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > @@ -45,7 +45,7 @@
> > /dts-v1/;
> >
> > #include "rk3288-veyron-chromebook.dtsi"
> > -#include "cros-ec-sbs.dtsi"
> > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> >
> > / {
> > model = "Google Jaq";
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > index cdea751f2a8c..bec607574165 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > @@ -44,7 +44,7 @@
> >
> > /dts-v1/;
> > #include "rk3288-veyron-chromebook.dtsi"
> > -#include "cros-ec-sbs.dtsi"
> > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> >
> > / {
> > model = "Google Jerry";
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > index 995cff42fa43..c81ad5bf1121 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > @@ -44,7 +44,7 @@
> >
> > /dts-v1/;
> > #include "rk3288-veyron-chromebook.dtsi"
> > -#include "cros-ec-sbs.dtsi"
> > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> >
> > / {
> > model = "Google Pinky";
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > index cc0b78cefe34..8aea9c3ff6e2 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > @@ -44,7 +44,7 @@
> >
> > /dts-v1/;
> > #include "rk3288-veyron-chro
Re: [PATCH 1/2] Add support for OneWire (W1) devices family 0x26 (MAX17211/MAX17215)
Hi, On Sun, Apr 30, 2017 at 08:21:51AM +0300, Alex A. Mihaylov wrote: > > > Slave device provide software layer for access to internal registers > > > MAX17211/MAX17215 chip. > > Please convert this to regmap.There is no generic w1 handler, but you can > > provide custom > > read/write functions. > I think regmap be overkill for this driver. Here we need access to a small > number of registers. Registers are extremely simple on the internal device. > As a result, the software layer of regmap will only complicate the > readability and understanding of the code. And also increase the size and > time of code execution, and even complicate the perception. I did not ask for full usage of all regmap features. Just register the read/write handler as regmap handler and use regmap_read/write to get values. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH v3 1/4] of: remove *phandle properties from expanded device tree
On 04/29/17 17:22, kbuild test robot wrote:
> Hi Frank,
>
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on v4.11-rc8 next-20170428]
> [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/frowand-list-gmail-com/of-remove-phandle-properties-from-expanded-device-tree/20170426-000149
> base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
> for-next
> config: s390-allmodconfig (attached as .config)
> compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=s390
>
> All errors (new ones prefixed by >>):
>
>In file included from include/linux/kobject.h:21:0,
> from include/linux/device.h:17,
> from include/linux/node.h:17,
> from include/linux/cpu.h:16,
> from drivers/of/base.c:25:
>drivers/of/base.c: In function '__of_add_phandle_sysfs':
>>> drivers/of/base.c:198:23: error: 'pp' undeclared (first use in this
>>> function)
> sysfs_bin_attr_init(&pp->attr);
> ^
Thanks for the report!
A patch to fix this is now submitted to Rob.
-Frank
>include/linux/sysfs.h:54:3: note: in definition of macro 'sysfs_attr_init'
> (attr)->key = &__key;\
> ^~~~
>drivers/of/base.c:198:2: note: in expansion of macro 'sysfs_bin_attr_init'
> sysfs_bin_attr_init(&pp->attr);
> ^~~
>drivers/of/base.c:198:23: note: each undeclared identifier is reported
> only once for each function it appears in
> sysfs_bin_attr_init(&pp->attr);
> ^
>include/linux/sysfs.h:54:3: note: in definition of macro 'sysfs_attr_init'
> (attr)->key = &__key;\
> ^~~~
>drivers/of/base.c:198:2: note: in expansion of macro 'sysfs_bin_attr_init'
> sysfs_bin_attr_init(&pp->attr);
> ^~~
>
> vim +/pp +198 drivers/of/base.c
>
> 19 */
> 20
> 21#define pr_fmt(fmt) "OF: " fmt
> 22
> 23#include
> 24#include
> > 25#include
> 26#include
> 27#include
> 28#include
> 29#include
> 30#include
> 31#include
> 32#include
> 33#include
> 34
> 35#include "of_private.h"
> 36
> 37LIST_HEAD(aliases_lookup);
> 38
> 39struct device_node *of_root;
> 40EXPORT_SYMBOL(of_root);
> 41struct device_node *of_chosen;
> 42struct device_node *of_aliases;
> 43struct device_node *of_stdout;
> 44static const char *of_stdout_options;
> 45
> 46struct kset *of_kset;
> 47
> 48/*
> 49 * Used to protect the of_aliases, to hold off addition of
> nodes to sysfs.
> 50 * This mutex must be held whenever modifications are being
> made to the
> 51 * device tree. The of_{attach,detach}_node() and
> 52 * of_{add,remove,update}_property() helpers make sure this
> happens.
> 53 */
> 54DEFINE_MUTEX(of_mutex);
> 55
> 56/* use when traversing tree through the child, sibling,
> 57 * or parent members of struct device_node.
> 58 */
> 59DEFINE_RAW_SPINLOCK(devtree_lock);
> 60
> 61int of_n_addr_cells(struct device_node *np)
> 62{
> 63const __be32 *ip;
> 64
> 65do {
> 66if (np->parent)
> 67np = np->parent;
> 68ip = of_get_property(np, "#address-cells",
> NULL);
> 69if (ip)
> 70return be32_to_cpup(ip);
> 71} while (np->parent);
> 72/* No #address-cells property for the root node */
> 73return OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
> 74}
> 75EXPORT_SYMBOL(of_n_addr_cells);
> 76
> 77int of_n_size_cells(struct device_node *np)
> 78{
> 79const __be32 *ip;
> 80
> 81do {
> 82if (np->parent)
> 83np = np->parent;
> 84ip = of_get_property(np, "#size-cells", NULL);
> 85if (ip)
> 86return be32_to_cpup(ip);
> 87} while (np->p
[PATCH] of: undeclared variable when CONFIG_DEBUG_LOCK_ALLOC
From: Frank Rowand An undeclared variable was used in a macro that evaluates to nothing when CONFIG_DEBUG_LOCK_ALLOC is not defined. Change to use the correct variable that does exist. --- reported by kbuild test robot on on robh/for-next https://lkml.org/lkml/2017/4/29/134 drivers/of/base.c: In function '__of_add_phandle_sysfs': >> drivers/of/base.c:198:23: error: 'pp' undeclared (first use in this function) sysfs_bin_attr_init(&pp->attr); Signed-off-by: Frank Rowand --- drivers/of/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/of/base.c b/drivers/of/base.c index 9fe42346925b..8a7ca2a49ba8 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -195,7 +195,7 @@ int __of_add_phandle_sysfs(struct device_node *np) if (!np->phandle || np->phandle == 0x) return 0; - sysfs_bin_attr_init(&pp->attr); + sysfs_bin_attr_init(&np->attr_phandle); np->attr_phandle.attr.name = "phandle"; np->attr_phandle.attr.mode = 0444; np->attr_phandle.size = sizeof(np->phandle); -- Frank Rowand
Re: [PATCH 2/2] Add driver for MAX17211/MAX17215 fuel gauge
Hi,
On Sun, Apr 30, 2017 at 08:32:10PM +0300, Михайлов Алексей Анатольевич wrote:
> > IIRC we already had problems with small THERMAL_NAME_LENGTH before.
> > I suggest to add another patch, that increases THERMAL_NAME_LENGTH
> > (don't forget to Cc/To the thermal subsystem people).
> May be rename "max17211-battery" to "max17211" and remove no_thermal = true?
> This case thermal zone will work again. In current (mainline) kernel all
> drivers "xx-battery" (like ds2780-battery or ds2760-battery) compiled,
> but not working (not registered). They can start working again without
> thermal zone by adding no_thermal = true or by remove "-battery" from
> platform device name. Alternative limit on THERMAL_NAME_LENGTH may be
> extended.
I think increasing THERMAL_NAME_LENGTH is the right way.
> > > + info->bat = power_supply_register(&pdev->dev, &info->bat_desc,
> > > + &psy_cfg);
> > > + if (IS_ERR(info->bat)) {
> > > + dev_err(info->dev, "failed to register battery\n");
> > > + return PTR_ERR(info->bat);
> > > + }
> > Please use devm_power_supply_register() and drop the remove
> > function.
> Khm... probe/remove paired functions. I can use devm_power_supply_register
> in my code. But all other fuel gauge drivers use classic probe/remove pair.
> Which decision will be more correct?
Most drivers are older than devm_power_supply_register. We already
have a few fuel gauge drivers, which use it, though:
$ git grep devm_power_supply_register | grep "battery"
88pm860x_battery.c: info->battery = devm_power_supply_register(&pdev->dev,
da9150-fg.c:fg->battery = devm_power_supply_register(dev, &fg_desc, NULL);
max17042_battery.c: chip->battery =
devm_power_supply_register(&client->dev, max17042_desc,
max8997_charger.c: charger->battery =
devm_power_supply_register(&pdev->dev,
max8998_charger.c: max8998->battery =
devm_power_supply_register(max8998->dev,
sbs-battery.c: chip->power_supply = devm_power_supply_register(&client->dev,
sbs_desc,
-- Sebastian
signature.asc
Description: PGP signature
Re: [PATCH 1/3] ARM: dts: rockchip: Move cros-ec-sbs to rk3288-veyron-chromebook-sbs
Hi Paul,
Am Sonntag, 30. April 2017, 20:30:52 CEST schrieb Paul Kocialkowski:
> This moves the cros-ec-sbs dtsi to a new rk3288-veyron-chromebook-sbs
> dtsi since it only concerns rk3288 veyron Chromebooks.
>
> Other Chromebooks (such as the tegra124 nyans) also have sbs batteries
> and don't use this dtsi, that only makes sense when used with
> rk3288-veyron-chromebook anyway.
That isn't true. The gru series (rk3399-based) also uses the
sbs-battery [0]. And while it is currently limited to Rockchip-based
Chromebooks it is nevertheless used on more than one platform, so
the probability is high that it will be used in future series as well.
Also, it might be nice to also include some Chromeos people (there should
be some in the git logs, like Brian who submitted the Gru patches), as they
might be able to provide more detailed input.
Heiko
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi#n886
>
> Signed-off-by: Paul Kocialkowski
> ---
> .../boot/dts/{cros-ec-sbs.dtsi => rk3288-veyron-chromebook-sbs.dtsi}| 0
> arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2
> +-
> arch/arm/boot/dts/rk3288-veyron-jerry.dts | 2
> +-
> arch/arm/boot/dts/rk3288-veyron-pinky.dts | 2
> +-
> arch/arm/boot/dts/rk3288-veyron-speedy.dts | 2
> +-
> 5 files changed, 4 insertions(+), 4 deletions(-)
> rename arch/arm/boot/dts/{cros-ec-sbs.dtsi =>
> rk3288-veyron-chromebook-sbs.dtsi} (100%)
>
> diff --git a/arch/arm/boot/dts/cros-ec-sbs.dtsi
> b/arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
> similarity index 100%
> rename from arch/arm/boot/dts/cros-ec-sbs.dtsi
> rename to arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
> diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> index d33f5763c39c..f217a978e47a 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> @@ -45,7 +45,7 @@
> /dts-v1/;
>
> #include "rk3288-veyron-chromebook.dtsi"
> -#include "cros-ec-sbs.dtsi"
> +#include "rk3288-veyron-chromebook-sbs.dtsi"
>
> / {
> model = "Google Jaq";
> diff --git a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> index cdea751f2a8c..bec607574165 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> @@ -44,7 +44,7 @@
>
> /dts-v1/;
> #include "rk3288-veyron-chromebook.dtsi"
> -#include "cros-ec-sbs.dtsi"
> +#include "rk3288-veyron-chromebook-sbs.dtsi"
>
> / {
> model = "Google Jerry";
> diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> index 995cff42fa43..c81ad5bf1121 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> @@ -44,7 +44,7 @@
>
> /dts-v1/;
> #include "rk3288-veyron-chromebook.dtsi"
> -#include "cros-ec-sbs.dtsi"
> +#include "rk3288-veyron-chromebook-sbs.dtsi"
>
> / {
> model = "Google Pinky";
> diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> index cc0b78cefe34..8aea9c3ff6e2 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> @@ -44,7 +44,7 @@
>
> /dts-v1/;
> #include "rk3288-veyron-chromebook.dtsi"
> -#include "cros-ec-sbs.dtsi"
> +#include "rk3288-veyron-chromebook-sbs.dtsi"
>
> / {
> model = "Google Speedy";
>
[PATCH] README: Find more sane first words we have to say about Linux
Imagine you're completely new to Linux, just real quick, ok? What do you do? Wouldn't having a look at README be under first if no *the* first thing? Ah there it is: README. "Linux kernel". nice! So what's that? "This file was moved to .. Please notice that there are several". Wtf!? Why? Can't they just tell me what's going on like a normal person? I'm sorry for the exaggeration, but really honestly I think we could do better. I'm all for not really having content in README, but come on :) I only try to avoid the biggest damage here and find some nice first words at least. Signed-off-by: Martin Kepplinger --- please ignore if too irrelevant, but I personally would put this in 4.11, if still possible, and rewrite the REAME for 4.12 to be even more friendly. thanks martin README | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/README b/README index b2ba4aaa3a71..876a98a5d472 100644 --- a/README +++ b/README @@ -1,10 +1,11 @@ Linux kernel -This file was moved to Documentation/admin-guide/README.rst +Linux is a Unix-like operating system, originally written by Linus Torvalds. +Please read Documentation/admin-guide/README.rst for an introduction. -Please notice that there are several guides for kernel developers and users. -These guides can be rendered in a number of formats, like HTML and PDF. +There are several guides for kernel developers and users. These guides can be +rendered in a number of formats, like HTML and PDF. In order to build the documentation, use ``make htmldocs`` or ``make pdfdocs``. -- 2.11.0
Re: [PATCH] staging: iio: isl29028: add isl29030 support
Hi, On Sun, Apr 30, 2017 at 05:27:07PM +0100, Jonathan Cameron wrote: > On 28/04/17 17:17, Brian Masney wrote: > > On Fri, Apr 28, 2017 at 05:55:58PM +0200, Sebastian Reichel wrote: > >> isl29030 is basically the same chip. The only difference > >> is the chip's first pin. For isl29028 its named ADDR0 and > >> can be used to change the chip's i2c address. For isl29030 > >> on the other hand that pin is named Ials and is an analog > >> current output proportional to ALS/IR. This change is > >> irrelevant for the Linux driver. > >> > >> This has been tested on Motorola Droid 4. > >> > >> Signed-off-by: Sebastian Reichel > >> --- > >> Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 + > >> drivers/staging/iio/light/isl29028.c | 6 ++ > >> 2 files changed, 7 insertions(+) > > > > Hi Sebastian, > > > > I moved this driver out of the staging directory earlier this week. > > You'll need to base your patch off of IIO testing: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/log/?h=testing > > > > Your patch should apply cleanly once you update the file path. > I did it rather than having this bounce around for a trivial rebase. > > Applied to the togreg branch of iio.git and pushed out as testing of > the autobuilders to play with it. Thanks. -- Sebastian signature.asc Description: PGP signature
[PATCH 2/2 v2] input: touchscreen: ar1021_i2c: use BIT to check for a bit
The MSB for the first byte of touch data transmission is always 1. Make it a little more obvious we're testing this bit by using BIT(7). Signed-off-by: Martin Kepplinger --- I'd still use the definition :) but otherwise I'd write the following. It really doesn't matter though. thanks for the quick support Dmitry, martin drivers/input/touchscreen/ar1021_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c index eb1874fe52c2..8c76aa435903 100644 --- a/drivers/input/touchscreen/ar1021_i2c.c +++ b/drivers/input/touchscreen/ar1021_i2c.c @@ -44,7 +44,7 @@ static irqreturn_t ar1021_i2c_irq(int irq, void *dev_id) goto out; /* sync bit set ? */ - if ((data[0] & 0x80) == 0) + if (!(data[0] & BIT(7))) goto out; button = data[0] & BIT(0); -- 2.11.0
[PATCH v4] fpga manager: Add Altera CvP driver
Add FPGA manager driver for loading Arria-V/Cyclone-V/Stratix-V
and Arria-10 FPGAs via CvP.
Signed-off-by: Anatolij Gustschin
---
Changes in v4:
- Update description about supported FPGA models in Kconfig
and commit log
- use writel() for iomem accesses
- factor out dummy write code to altera_cvp_dummy_write()
- add data register accessor function (iomem and pci config
space variants) to reduce code
Changes in v3:
- removed V-series from description (since the driver works
also with Arria-10). Also renamed functions, config option
and driver file name. Changed module description in Kconfig
- dropped 'firmware=' module option (does not allow to bypass
the fpga framework any more)
- fixed build warning with newer gcc
- changed to use hex numbers for PCI bus/device in registered
fpga manager name. Use more generic fpga manager name (no
V-series in the name any more)
- moved steps 16 to 18 from teardown func to write_complete()
as suggested by Yi
- rebased on linux-next and tested with Arria-10/Stratix-V
devices
Changes in v2:
- rebase for v4.10, change subject ("Stratix V" to "V series")
and add GPL header
- use BIT() in register bit macro definitions
- change .state() to return status or FPGA_MGR_STATE_UNKNOWN
- use unique name for registered FPGA manager (append "@B:D.F")
- use PCI_ANY_ID for device ID, users can set custom ID using
new_id sysfs interface
- remove map_base/map_len init and use pci_iomap() instead
- simplify to use pci_read_config_word() instead of
pci_bus_read_config_word()
- run fpga_mgr_put() after usage, so the module can be removed
without unbinding the driver
- access CVP_STATUS as a 32-bit register, update CVP_STATUS
bits macros
- check CONFIG_READY bit in write_init and perform a teardown
if this bit is set. Move teardown code to separate function
as suggested
- change function names to altera_v_*() as we can use
the driver with other V-series FPGAs. Also change
the driver file and Kconfig option names accordingly
- pad written firmware data if the file size is not a multiple of 4
- when config error checking is enabled, run checks after a 4KiB
chunk is written
- remove single built-in firmware string, add module parameter
to allow setting default firmware for multiple cards as a
Bus:Device.Function specific strings (optional)
- remove polling of non-existing data bits DATA_ENC, DATA_COMP.
Instead, add module parameter for bitstream specific clock to
data ratio setting
drivers/fpga/Kconfig | 7 +
drivers/fpga/Makefile | 1 +
drivers/fpga/altera-cvp.c | 549 ++
3 files changed, 557 insertions(+)
create mode 100644 drivers/fpga/altera-cvp.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 161ba9d..895529e 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -26,6 +26,13 @@ config FPGA_MGR_ICE40_SPI
help
FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
+config FPGA_MGR_ALTERA_CVP
+ tristate "Altera Arria-V/Cyclone-V/Stratix-V CvP FPGA Manager"
+ depends on PCI
+ help
+ FPGA manager driver support for Arria-V, Cyclone-V, Stratix-V
+ and Arria 10 Altera FPGAs using the CvP interface over PCIe.
+
config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA || COMPILE_TEST
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 2a4f021..2e5c8b6 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_FPGA) += fpga-mgr.o
# FPGA Manager Drivers
+obj-$(CONFIG_FPGA_MGR_ALTERA_CVP) += altera-cvp.o
obj-$(CONFIG_FPGA_MGR_ICE40_SPI) += ice40-spi.o
obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c
new file mode 100644
index 000..4903231
--- /dev/null
+++ b/drivers/fpga/altera-cvp.c
@@ -0,0 +1,549 @@
+/*
+ * FPGA Manager Driver for Altera Arria/Cyclone/Stratix CvP
+ *
+ * Copyright (C) 2017 DENX Software Engineering
+ *
+ * Anatolij Gustschin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Manage Altera FPGA firmware using PCIe CvP.
+ * Firmware must be in binary "rbf" format.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define CVP_BAR0 /* BAR used for data transfer in memory
Re: [PATCH] staging: rtl8723bs: declare private function as static
Hi,
On 23-04-17 19:37, Kenneth Hsu wrote:
This fixes a sparse warning regarding an undeclared symbol. Since the
function is private to rtw_recv.c, it should be declared as static.
Signed-off-by: Kenneth Hsu
Looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/staging/rtl8723bs/core/rtw_recv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c
b/drivers/staging/rtl8723bs/core/rtw_recv.c
index 74e11948c015..695a5c958c80 100644
--- a/drivers/staging/rtl8723bs/core/rtw_recv.c
+++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
@@ -1717,7 +1717,8 @@ sint wlanhdr_to_ethhdr(union recv_frame *precvframe)
}
/* perform defrag */
-union recv_frame *recvframe_defrag(struct adapter *adapter, struct __queue
*defrag_q)
+static union recv_frame *recvframe_defrag(struct adapter *adapter,
+ struct __queue *defrag_q)
{
struct list_head *plist, *phead;
u8 *data, wlanhdr_offset;
Re: [PATCH 1/7] hwmon: twl4030-madc: drop driver
On 04/30/2017 09:41 AM, Jonathan Cameron wrote: On 27/04/17 17:51, Guenter Roeck wrote: On Thu, Apr 27, 2017 at 05:30:06PM +0200, Sebastian Reichel wrote: This driver is no longer needed: * It has no mainline users * It has no DT support and OMAP is DT only * iio-hwmon can be used for madc, which also works with DT Signed-off-by: Sebastian Reichel Acked-by: Guenter Roeck ... assuming this will be pushed through the same tree as the rest of the series. Let me know if I should queue it up in hwmon for v4.12. We are too late for the series to go through IIO for the 4.12 cycle, so I guess it makes sense to take this one through hwmon if you still have time. Ok, done. Guenter
[PATCH 2/3] ARM: dts: rockchip: List charger as power supply for sbs battery
This lists the GPIO charger node as power supply for the battery, which
in turns allows receiving external power notifications and synchronizing
the charging state as soon as possible.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi | 1 +
arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
b/arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
index 71f5c5ecce46..8e4d2b9a35e1 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
@@ -48,5 +48,6 @@
reg = <0xb>;
sbs,i2c-retry-count = <2>;
sbs,poll-retry-count = <1>;
+ power-supplies = <&charger>;
};
};
diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index d752a315f884..fd4a3886c94b 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -99,7 +99,7 @@
pwm-delay-us = <1>;
};
- gpio-charger {
+ charger: gpio-charger {
compatible = "gpio-charger";
charger-type = "mains";
gpios = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>;
--
2.12.2
[PATCH 3/3] ARM: dts: rockchip: List charger as power supply for minnie
This lists the GPIO charger node as power supply for the battery, which
in turns allows receiving external power notifications and synchronizing
the charging state as soon as possible.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/rk3288-veyron-minnie.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index 544de6027aaa..3f97f33bd783 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -151,6 +151,7 @@
battery: bq27500@55 {
compatible = "ti,bq27500";
reg = <0x55>;
+ power-supplies = <&charger>;
};
};
--
2.12.2
[PATCH 1/3] ARM: dts: rockchip: Move cros-ec-sbs to rk3288-veyron-chromebook-sbs
This moves the cros-ec-sbs dtsi to a new rk3288-veyron-chromebook-sbs
dtsi since it only concerns rk3288 veyron Chromebooks.
Other Chromebooks (such as the tegra124 nyans) also have sbs batteries
and don't use this dtsi, that only makes sense when used with
rk3288-veyron-chromebook anyway.
Signed-off-by: Paul Kocialkowski
---
.../boot/dts/{cros-ec-sbs.dtsi => rk3288-veyron-chromebook-sbs.dtsi}| 0
arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2 +-
arch/arm/boot/dts/rk3288-veyron-jerry.dts | 2 +-
arch/arm/boot/dts/rk3288-veyron-pinky.dts | 2 +-
arch/arm/boot/dts/rk3288-veyron-speedy.dts | 2 +-
5 files changed, 4 insertions(+), 4 deletions(-)
rename arch/arm/boot/dts/{cros-ec-sbs.dtsi =>
rk3288-veyron-chromebook-sbs.dtsi} (100%)
diff --git a/arch/arm/boot/dts/cros-ec-sbs.dtsi
b/arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
similarity index 100%
rename from arch/arm/boot/dts/cros-ec-sbs.dtsi
rename to arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
index d33f5763c39c..f217a978e47a 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
@@ -45,7 +45,7 @@
/dts-v1/;
#include "rk3288-veyron-chromebook.dtsi"
-#include "cros-ec-sbs.dtsi"
+#include "rk3288-veyron-chromebook-sbs.dtsi"
/ {
model = "Google Jaq";
diff --git a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
index cdea751f2a8c..bec607574165 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
@@ -44,7 +44,7 @@
/dts-v1/;
#include "rk3288-veyron-chromebook.dtsi"
-#include "cros-ec-sbs.dtsi"
+#include "rk3288-veyron-chromebook-sbs.dtsi"
/ {
model = "Google Jerry";
diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
index 995cff42fa43..c81ad5bf1121 100644
--- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
@@ -44,7 +44,7 @@
/dts-v1/;
#include "rk3288-veyron-chromebook.dtsi"
-#include "cros-ec-sbs.dtsi"
+#include "rk3288-veyron-chromebook-sbs.dtsi"
/ {
model = "Google Pinky";
diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
index cc0b78cefe34..8aea9c3ff6e2 100644
--- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
@@ -44,7 +44,7 @@
/dts-v1/;
#include "rk3288-veyron-chromebook.dtsi"
-#include "cros-ec-sbs.dtsi"
+#include "rk3288-veyron-chromebook-sbs.dtsi"
/ {
model = "Google Speedy";
--
2.12.2
[PATCH] staging: media: atomisp: use logical AND, not bitwise
Fixes sparse warning "dubious: x & !y" in logical expression.
Signed-off-by: Guru Das Srinagesh
---
.../media/atomisp/pci/atomisp2/css2400/runtime/binary/src/binary.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/binary/src/binary.c
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/binary/src/binary.c
index 34ca534..44b2aff 100644
---
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/binary/src/binary.c
+++
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/binary/src/binary.c
@@ -1658,7 +1658,7 @@ ia_css_binary_find(struct ia_css_binary_descr *descr,
candidate->internal.max_height);
continue;
}
- if (!candidate->enable.ds && need_ds &
!(xcandidate->num_output_pins > 1)) {
+ if (!candidate->enable.ds && need_ds &&
!(xcandidate->num_output_pins > 1)) {
ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE,
"ia_css_binary_find() [%d] continue: !%d &&
%d\n",
__LINE__, candidate->enable.ds, (int)need_ds);
--
2.7.4
[PATCH 3/5] power: supply: bq27xxx: Rename work structure member to poll_work
This renames the work structure member to poll_work, in anticipation
of the introduction of a status_work member used to detect status
changes.
Signed-off-by: Paul Kocialkowski
---
drivers/power/supply/bq27xxx_battery.c | 20 ++--
drivers/power/supply/bq27xxx_battery_i2c.c | 2 +-
include/linux/power/bq27xxx_battery.h | 2 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index be476e0bc85d..926bd58344d9 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -769,8 +769,8 @@ static int poll_interval_param_set(const char *val, const
struct kernel_param *k
mutex_lock(&bq27xxx_list_lock);
list_for_each_entry(di, &bq27xxx_battery_devices, list) {
- cancel_delayed_work_sync(&di->work);
- schedule_delayed_work(&di->work, 0);
+ cancel_delayed_work_sync(&di->poll_work);
+ schedule_delayed_work(&di->poll_work, 0);
}
mutex_unlock(&bq27xxx_list_lock);
@@ -1126,12 +1126,12 @@ static void bq27xxx_battery_poll(struct work_struct
*work)
{
struct bq27xxx_device_info *di =
container_of(work, struct bq27xxx_device_info,
-work.work);
+poll_work.work);
bq27xxx_battery_update(di);
if (poll_interval > 0)
- schedule_delayed_work(&di->work, poll_interval * HZ);
+ schedule_delayed_work(&di->poll_work, poll_interval * HZ);
}
/*
@@ -1265,8 +1265,8 @@ static int bq27xxx_battery_get_property(struct
power_supply *psy,
mutex_lock(&di->lock);
if (time_is_before_jiffies(di->last_update + 5 * HZ)) {
- cancel_delayed_work_sync(&di->work);
- bq27xxx_battery_poll(&di->work.work);
+ cancel_delayed_work_sync(&di->poll_work);
+ bq27xxx_battery_poll(&di->poll_work.work);
}
mutex_unlock(&di->lock);
@@ -1344,8 +1344,8 @@ static void bq27xxx_external_power_changed(struct
power_supply *psy)
{
struct bq27xxx_device_info *di = power_supply_get_drvdata(psy);
- cancel_delayed_work_sync(&di->work);
- schedule_delayed_work(&di->work, 0);
+ cancel_delayed_work_sync(&di->poll_work);
+ schedule_delayed_work(&di->poll_work, 0);
}
int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
@@ -1356,7 +1356,7 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
psy_cfg.drv_data = di;
psy_cfg.of_node = di->of_node;
- INIT_DELAYED_WORK(&di->work, bq27xxx_battery_poll);
+ INIT_DELAYED_WORK(&di->poll_work, bq27xxx_battery_poll);
mutex_init(&di->lock);
di->regs = bq27xxx_regs[di->chip];
@@ -1399,7 +1399,7 @@ void bq27xxx_battery_teardown(struct bq27xxx_device_info
*di)
*/
poll_interval = 0;
- cancel_delayed_work_sync(&di->work);
+ cancel_delayed_work_sync(&di->poll_work);
power_supply_unregister(di->bat);
diff --git a/drivers/power/supply/bq27xxx_battery_i2c.c
b/drivers/power/supply/bq27xxx_battery_i2c.c
index 38a0422a4192..1b2ad22190ae 100644
--- a/drivers/power/supply/bq27xxx_battery_i2c.c
+++ b/drivers/power/supply/bq27xxx_battery_i2c.c
@@ -103,7 +103,7 @@ static int bq27xxx_battery_i2c_probe(struct i2c_client
*client,
goto err_failed;
/* Schedule a polling after about 1 min */
- schedule_delayed_work(&di->work, 60 * HZ);
+ schedule_delayed_work(&di->poll_work, 60 * HZ);
i2c_set_clientdata(client, di);
diff --git a/include/linux/power/bq27xxx_battery.h
b/include/linux/power/bq27xxx_battery.h
index 94637b77ecbf..0a9af513165a 100644
--- a/include/linux/power/bq27xxx_battery.h
+++ b/include/linux/power/bq27xxx_battery.h
@@ -66,7 +66,7 @@ struct bq27xxx_device_info {
struct device_node *of_node;
int charge_design_full;
unsigned long last_update;
- struct delayed_work work;
+ struct delayed_work poll_work;
struct power_supply *bat;
struct list_head list;
struct mutex lock;
--
2.12.2
[PATCH 5/5] power: supply: bq27xxx: Correct supply status with current draw
The status reported directly by the battery controller is not always
reliable and should be corrected based on the current draw information.
This implements such a correction with a dedicated function, called
when retrieving the supply status.
Signed-off-by: Paul Kocialkowski
---
drivers/power/supply/bq27xxx_battery.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index cade00df6162..f7694e775e68 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -1171,8 +1171,22 @@ static int bq27xxx_battery_status(struct
bq27xxx_device_info *di,
union power_supply_propval *val)
{
int status;
+ int curr;
+ int flags;
+
+ curr = bq27xxx_read(di, BQ27XXX_REG_AI, false);
+ if (curr < 0) {
+ dev_err(di->dev, "error reading current\n");
+ return curr;
+ }
if (di->chip == BQ27000 || di->chip == BQ27010) {
+ flags = bq27xxx_read(di, BQ27XXX_REG_FLAGS, true);
+ if (flags & BQ27000_FLAG_CHGS) {
+ dev_dbg(di->dev, "negative current!\n");
+ curr = -curr;
+ }
+
if (di->cache.flags & BQ27000_FLAG_FC)
status = POWER_SUPPLY_STATUS_FULL;
else if (di->cache.flags & BQ27000_FLAG_CHGS)
@@ -1182,6 +1196,8 @@ static int bq27xxx_battery_status(struct
bq27xxx_device_info *di,
else
status = POWER_SUPPLY_STATUS_DISCHARGING;
} else {
+ curr = (int)((s16)curr) * 1000;
+
if (di->cache.flags & BQ27XXX_FLAG_FC)
status = POWER_SUPPLY_STATUS_FULL;
else if (di->cache.flags & BQ27XXX_FLAG_DSC)
@@ -1190,6 +1206,18 @@ static int bq27xxx_battery_status(struct
bq27xxx_device_info *di,
status = POWER_SUPPLY_STATUS_CHARGING;
}
+
+ if (curr == 0 && status != POWER_SUPPLY_STATUS_NOT_CHARGING)
+ status = POWER_SUPPLY_STATUS_FULL;
+
+ if (status == POWER_SUPPLY_STATUS_FULL) {
+ /* Drawing or providing current when full */
+ if (curr > 0)
+ status = POWER_SUPPLY_STATUS_CHARGING;
+ else if (curr < 0)
+ status = POWER_SUPPLY_STATUS_DISCHARGING;
+ }
+
if (di->status_retry == 0 && di->status_change_reference != status) {
di->status_change_reference = status;
power_supply_changed(di->bat);
--
2.12.2
[PATCH 4/5] power: supply: bq27xxx: Look for status change on external power change
This introduces a dedicated status change work to look for power
status change. It is triggered by external power change notifications
and periodically retries detecting a power status change for 5 seconds.
This is largely inspired by a similar mechanism from the sbs-battery
driver.
Signed-off-by: Paul Kocialkowski
---
drivers/power/supply/bq27xxx_battery.c | 38 --
include/linux/power/bq27xxx_battery.h | 3 +++
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index 926bd58344d9..cade00df6162 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -1190,6 +1190,11 @@ static int bq27xxx_battery_status(struct
bq27xxx_device_info *di,
status = POWER_SUPPLY_STATUS_CHARGING;
}
+ if (di->status_retry == 0 && di->status_change_reference != status) {
+ di->status_change_reference = status;
+ power_supply_changed(di->bat);
+ }
+
val->intval = status;
return 0;
@@ -1340,12 +1345,38 @@ static int bq27xxx_battery_get_property(struct
power_supply *psy,
return ret;
}
+static void bq27xxx_status_change(struct work_struct *work)
+{
+ struct bq27xxx_device_info *di =
+ container_of(work, struct bq27xxx_device_info,
+status_work.work);
+ union power_supply_propval val;
+ int ret;
+
+ bq27xxx_battery_update(di);
+
+ ret = bq27xxx_battery_status(di, &val);
+ if (ret < 0)
+ return;
+
+ if (di->status_change_reference != val.intval) {
+ di->status_change_reference = val.intval;
+ power_supply_changed(di->bat);
+ }
+
+ if (di->status_retry > 0) {
+ di->status_retry--;
+ schedule_delayed_work(&di->status_work, HZ);
+ }
+}
+
static void bq27xxx_external_power_changed(struct power_supply *psy)
{
struct bq27xxx_device_info *di = power_supply_get_drvdata(psy);
- cancel_delayed_work_sync(&di->poll_work);
- schedule_delayed_work(&di->poll_work, 0);
+ cancel_delayed_work_sync(&di->status_work);
+ schedule_delayed_work(&di->status_work, HZ);
+ di->status_retry = 5;
}
int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
@@ -1357,8 +1388,10 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
psy_cfg.of_node = di->of_node;
INIT_DELAYED_WORK(&di->poll_work, bq27xxx_battery_poll);
+ INIT_DELAYED_WORK(&di->status_work, bq27xxx_status_change);
mutex_init(&di->lock);
di->regs = bq27xxx_regs[di->chip];
+ di->status_change_reference = POWER_SUPPLY_STATUS_UNKNOWN;
psy_desc = devm_kzalloc(di->dev, sizeof(*psy_desc), GFP_KERNEL);
if (!psy_desc)
@@ -1400,6 +1433,7 @@ void bq27xxx_battery_teardown(struct bq27xxx_device_info
*di)
poll_interval = 0;
cancel_delayed_work_sync(&di->poll_work);
+ cancel_delayed_work_sync(&di->status_work);
power_supply_unregister(di->bat);
diff --git a/include/linux/power/bq27xxx_battery.h
b/include/linux/power/bq27xxx_battery.h
index 0a9af513165a..16d604681ace 100644
--- a/include/linux/power/bq27xxx_battery.h
+++ b/include/linux/power/bq27xxx_battery.h
@@ -67,6 +67,9 @@ struct bq27xxx_device_info {
int charge_design_full;
unsigned long last_update;
struct delayed_work poll_work;
+ struct delayed_work status_work;
+ int status_retry;
+ int status_change_reference;
struct power_supply *bat;
struct list_head list;
struct mutex lock;
--
2.12.2
[PATCH 2/5] power: supply: bq27xxx: Register power supply with devm
This uses the managed devices resources version of the
power_supply_register_no_ws function to register the power supply.
Signed-off-by: Paul Kocialkowski
---
drivers/power/supply/bq27xxx_battery.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index 6ef95442a918..be476e0bc85d 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -1371,7 +1371,7 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
psy_desc->get_property = bq27xxx_battery_get_property;
psy_desc->external_power_changed = bq27xxx_external_power_changed;
- di->bat = power_supply_register_no_ws(di->dev, psy_desc, &psy_cfg);
+ di->bat = devm_power_supply_register_no_ws(di->dev, psy_desc, &psy_cfg);
if (IS_ERR(di->bat)) {
dev_err(di->dev, "failed to register battery\n");
return PTR_ERR(di->bat);
--
2.12.2
[PATCH 1/5] power: supply: bq27xxx: Pass of_node along to allow device-tree supply
This passes the of_node from the bq27xxx i2c battery driver to the
common code, so that it can be registered and provide external supplies
linked with device-tree.
Signed-off-by: Paul Kocialkowski
---
drivers/power/supply/bq27xxx_battery.c | 5 -
drivers/power/supply/bq27xxx_battery_i2c.c | 1 +
include/linux/power/bq27xxx_battery.h | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index 398801a21b86..6ef95442a918 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -1351,7 +1351,10 @@ static void bq27xxx_external_power_changed(struct
power_supply *psy)
int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
{
struct power_supply_desc *psy_desc;
- struct power_supply_config psy_cfg = { .drv_data = di, };
+ struct power_supply_config psy_cfg = {};
+
+ psy_cfg.drv_data = di;
+ psy_cfg.of_node = di->of_node;
INIT_DELAYED_WORK(&di->work, bq27xxx_battery_poll);
mutex_init(&di->lock);
diff --git a/drivers/power/supply/bq27xxx_battery_i2c.c
b/drivers/power/supply/bq27xxx_battery_i2c.c
index c68fbc3fe50a..38a0422a4192 100644
--- a/drivers/power/supply/bq27xxx_battery_i2c.c
+++ b/drivers/power/supply/bq27xxx_battery_i2c.c
@@ -96,6 +96,7 @@ static int bq27xxx_battery_i2c_probe(struct i2c_client
*client,
di->chip = id->driver_data;
di->name = name;
di->bus.read = bq27xxx_battery_i2c_read;
+ di->of_node = client->dev.of_node;
ret = bq27xxx_battery_setup(di);
if (ret)
diff --git a/include/linux/power/bq27xxx_battery.h
b/include/linux/power/bq27xxx_battery.h
index b312bcef53da..94637b77ecbf 100644
--- a/include/linux/power/bq27xxx_battery.h
+++ b/include/linux/power/bq27xxx_battery.h
@@ -63,6 +63,7 @@ struct bq27xxx_device_info {
const char *name;
struct bq27xxx_access_methods bus;
struct bq27xxx_reg_cache cache;
+ struct device_node *of_node;
int charge_design_full;
unsigned long last_update;
struct delayed_work work;
--
2.12.2
Re: [PATCH v1] selftests: Make test_harness.h more generally available
On Sun, Apr 30, 2017 at 12:39 PM, Kees Cook wrote:
>
> On Sun, Apr 30, 2017 at 5:26 AM, Mickaël Salaün wrote:
> > The seccomp/test_harness.h file contains useful helpers to build tests.
> > Moving it to the selftest directory should benefit to other test
> > components.
>
> Unless Shuah thinks this should live in a new include/ directory, this
> looks fine to me.
>
> Acked-by: Kees Cook
Same here!
Acked-by: Will Drewry
>
> Thanks!
>
> -Kees
>
> >
> > Signed-off-by: Mickaël Salaün
> > Cc: Andy Lutomirski
> > Cc: Kees Cook
> > Cc: Shuah Khan
> > Cc: Will Drewry
> > Link:
> > https://lkml.kernel.org/r/CAGXu5j+8CVz8vL51DRYXqOY=xc3zuKFf=ptene88xyhzfyi...@mail.gmail.com
> > ---
> > tools/testing/selftests/seccomp/seccomp_bpf.c| 2 +-
> > tools/testing/selftests/{seccomp => }/test_harness.h | 0
> > 2 files changed, 1 insertion(+), 1 deletion(-)
> > rename tools/testing/selftests/{seccomp => }/test_harness.h (100%)
> >
> > diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
> > b/tools/testing/selftests/seccomp/seccomp_bpf.c
> > index 03f1fa495d74..d7095ff58e72 100644
> > --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> > +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> > @@ -37,7 +37,7 @@
> > #include
> > #include
> >
> > -#include "test_harness.h"
> > +#include "../test_harness.h"
> >
> > #ifndef PR_SET_PTRACER
> > # define PR_SET_PTRACER 0x59616d61
> > diff --git a/tools/testing/selftests/seccomp/test_harness.h
> > b/tools/testing/selftests/test_harness.h
> > similarity index 100%
> > rename from tools/testing/selftests/seccomp/test_harness.h
> > rename to tools/testing/selftests/test_harness.h
> > --
> > 2.11.0
> >
>
>
>
> --
> Kees Cook
> Pixel Security
Re: [PATCH v1] selftests: Make test_harness.h more generally available
On Sun, Apr 30, 2017 at 5:26 AM, Mickaël Salaün wrote:
> The seccomp/test_harness.h file contains useful helpers to build tests.
> Moving it to the selftest directory should benefit to other test
> components.
Unless Shuah thinks this should live in a new include/ directory, this
looks fine to me.
Acked-by: Kees Cook
Thanks!
-Kees
>
> Signed-off-by: Mickaël Salaün
> Cc: Andy Lutomirski
> Cc: Kees Cook
> Cc: Shuah Khan
> Cc: Will Drewry
> Link:
> https://lkml.kernel.org/r/CAGXu5j+8CVz8vL51DRYXqOY=xc3zuKFf=ptene88xyhzfyi...@mail.gmail.com
> ---
> tools/testing/selftests/seccomp/seccomp_bpf.c| 2 +-
> tools/testing/selftests/{seccomp => }/test_harness.h | 0
> 2 files changed, 1 insertion(+), 1 deletion(-)
> rename tools/testing/selftests/{seccomp => }/test_harness.h (100%)
>
> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
> b/tools/testing/selftests/seccomp/seccomp_bpf.c
> index 03f1fa495d74..d7095ff58e72 100644
> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> @@ -37,7 +37,7 @@
> #include
> #include
>
> -#include "test_harness.h"
> +#include "../test_harness.h"
>
> #ifndef PR_SET_PTRACER
> # define PR_SET_PTRACER 0x59616d61
> diff --git a/tools/testing/selftests/seccomp/test_harness.h
> b/tools/testing/selftests/test_harness.h
> similarity index 100%
> rename from tools/testing/selftests/seccomp/test_harness.h
> rename to tools/testing/selftests/test_harness.h
> --
> 2.11.0
>
--
Kees Cook
Pixel Security
Re: perf report warnings on tracepoint events hidden by ui
>> >> An appears to be correctly parsed by event_read_print in >> tools/lib/tracevent/event-parse.c . Has anyone seen this before? > > What kernel are you running? > > I just built and booted v4.11-rc8 with a v4.11-rc8 perf: I was running an internal version. I found the bug in an internal commit. It's true that upstream is all good. Thank you for checking, David
Re: perf report warnings on tracepoint events hidden by ui
> > But I don't see any warning when I run it with --stdio. Could you > show me the format file of sys_enter_mmap? I found the problem. The kernel version I was testing on fails to initialize some fields in the tracepoint structure, so my format looked like: # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_mmap/format name: sys_enter_mmap ID: 144 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; print fmt: "addr: 0x%08lx, len: 0x%08lx, prot: 0x%08lx, flags: 0x%08lx, fd: 0x%08lx, off: 0x%08lx", ((unsigned long)(REC->addr)), ((unsigned long)(REC->len)), ((unsigned long)(REC->prot)), ((unsigned long)(REC->flags)), ((unsigned long)(REC->fd)), ((unsigned long)(REC->off)) rather than: name: sys_enter_mmap ID: 111 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int nr; offset:8; size:4; signed:1; field:unsigned long addr; offset:16; size:8; signed:0; field:unsigned long len;offset:24; size:8; signed:0; field:unsigned long prot; offset:32; size:8; signed:0; field:unsigned long flags; offset:40; size:8; signed:0; field:unsigned long fd; offset:48; size:8; signed:0; field:unsigned long off;offset:56; size:8; signed:0; print fmt: "addr: 0x%08lx, len: 0x%08lx, prot: 0x%08lx, flags: 0x%08lx, fd: 0x%08lx, off: 0x%08lx", ((unsigned long)(REC->addr)), ((unsigned long)(REC->len)), ((unsigned long)(REC->prot)), ((unsigned long)(REC->flags)), ((unsigned long)(REC->fd)), ((unsigned long)(REC->off)) Upstream is all good. It was my oversight not testing there first. Thanks, David
Re: [PATCH 2/2] Add driver for MAX17211/MAX17215 fuel gauge
Hi!
[...]
+* FixMe:
+* Device without no_thermal = true not register (err -22)
+* Len of platform device name "max17211-battery.X.auto"
+* more than 20 chars limit in THERMAL_NAME_LENGTH from
+* include/uapi/linux/thermal.h
+*/
IIRC we already had problems with small THERMAL_NAME_LENGTH before.
I suggest to add another patch, that increases THERMAL_NAME_LENGTH
(don't forget to Cc/To the thermal subsystem people).
May be rename "max17211-battery" to "max17211" and remove no_thermal =
true? This case thermal zone will work again. In current (mainline)
kernel all drivers "xx-battery" (like ds2780-battery or
ds2760-battery) compiled, but not working (not registered). They can
start working again without thermal zone by adding no_thermal = true or
by remove "-battery" from platform device name. Alternative limit on
THERMAL_NAME_LENGTH may be extended.
+ info->bat = power_supply_register(&pdev->dev, &info->bat_desc,
+ &psy_cfg);
+ if (IS_ERR(info->bat)) {
+ dev_err(info->dev, "failed to register battery\n");
+ return PTR_ERR(info->bat);
+ }
Please use devm_power_supply_register() and drop the remove
function.
Khm... probe/remove paired functions. I can use
devm_power_supply_register in my code. But all other fuel gauge drivers
use classic probe/remove pair. Which decision will be more correct?
Re: [v6 PATCH 06/21] x86/insn-eval: Add utility functions to get segment selector
On Wed, Apr 26, 2017 at 01:44:43PM -0700, Ricardo Neri wrote: > I regard that the role of this function is to obtain the the segment > selector from either of the prefixes or inferred from the operands. It > is the role of caller to determine if the segment selector should be > ignored. No, this is wrong. The function is called resolve_seg_selector() and it gives you the segment selector. CS, DS, ES, and SS in 64-bit mode are treated as null segments and your function should return/signal exactly that, i.e, saying that those should be ignored in that case. > I double-checked the latest version of the Intel Software Development > manual [2], in the table 3-5 in section 3.7.4 mentions that DS is > default segment for all data references, except string destinations. I > tested this code with the UMIP-protected instructions and whenever I use > %edi the default segment is %ds. Yes, all correct. Except that we're adding a more-or-less generic x86 insn decoder so we should make it so... > Is this example valid? The documentation of MOVS specifies that it > always moves DS:(E)SI to ES:(E)DI. ... that the decoder should do exactly that: if (MOVS and rDI) return SEG_ES; And you're handing in struct insn * so you can easily check which insn you're looking at. Thanks. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: [PATCH] iio: stm32 trigger: Add support for TRGO2 triggers
On 28/04/17 15:52, Fabrice Gasnier wrote: > On 04/27/2017 07:49 AM, Jonathan Cameron wrote: >> On 26/04/17 09:55, Benjamin Gaignard wrote: >>> 2017-04-26 10:17 GMT+02:00 Fabrice Gasnier : Add support for TRGO2 trigger that can be found on STM32F7. Add additional master modes supported by TRGO2. >> These additional modes would benefit from more information in the >> ABI docs. Otherwise patch seems fine, though this may win >> the award for hardest hardware to come up with a generic >> interface for... Register additional "tim[1/8]_trgo2" triggers for timer1 & timer8. Detect TRGO2 timer capability (master mode selection 2). Signed-off-by: Fabrice Gasnier --- .../ABI/testing/sysfs-bus-iio-timer-stm32 | 15 +++ drivers/iio/trigger/stm32-timer-trigger.c | 113 ++--- include/linux/iio/timer/stm32-timer-trigger.h | 2 + include/linux/mfd/stm32-timers.h | 2 + 4 files changed, 118 insertions(+), 14 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 index 230020e..47647b4 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 @@ -16,6 +16,21 @@ Description: - "OC2REF": OC2REF signal is used as trigger output. - "OC3REF": OC3REF signal is used as trigger output. - "OC4REF": OC4REF signal is used as trigger output. + Additional modes (on TRGO2 only): + - "OC5REF": OC5REF signal is used as trigger output. + - "OC6REF": OC6REF signal is used as trigger output. + - "compare_pulse_OC4REF": + OC4REF rising or falling edges generate pulses. >> I'd like this to be fairly understandable without resorting to reading the >> datasheet. As I understand it you get a fixed term pulse on both edges >> of the waveform? Perhaps this calls for some ascii art :) > > Hi Jonathan, > > If you feel like it needs more documentation, I'd rather prefer to add > reference or link to the datasheet... That will be more accurate, > up-to-date (e.g. like RM0385 pdf). Does this sound ok ? Or... Datasheet is good, but give it 10 years and chances are it will disappear into a black hole, whereas the hardware might still be in use by someone. Some of the hardware I use is at least that old. Frankly this laptop is getting close ;) > > Just in case, I prepared some ascii art, hope it clarify things. > I'm wondering if this is best place to put it ? > Shouldn't this be added in source code, instead of ABI Doc ? Could be either, but arguably the ABI docs should be all that a userspace developer should need to see. This isn't an internal detail afterall. > Maybe I can skip 1st part of it, heading boxes? (only example is enough? > or not...) > > +---+ +-++-+ > | Prescaler +-> | Counter |+-> | Master | TRGO(2) > +---+ +--++-+|-> | Control +--> >|| || +-+ > +--v+-+ OCxREF || +-+ > | Chx compare +--> | Output | ChX > +---+-+ | | Control +--> > . | | +-+ > . | |. > +---v-+ OC6REF |. > | Ch6 compare +-+> > +-+ > > Example with: "compare_pulse_OC4REF_r_or_OC6REF_r": > > X > X X > X . . X > X . . X > X . . X > count X . . . . X > . . . . > . . . . > +---+ > OC4REF | . . | > +-+ . . +-+ > . +---+ . > OC6REF . | | . > +---+ +---+ > +-+ +-+ > TRGO2 | | | | > +-+ +---+ +-+ This is good stuff so I'd put it in the ABI docs. Jonathan > > > side note: this isn't my house ;-) :) > > Please advise, > Thanks, > Fabrice > > + - "compare_pulse_OC6REF": + OC6REF rising or falling edges generate pulses. + - "compare_pulse_OC4REF_r_or_OC6REF_r": + OC4REF or OC6REF rising edges generate pulses. + - "compare_pulse_OC4REF_r_or_OC6REF_f": + OC4REF rising or OC6REF falling edges generate pulses. + - "compare_pulse_OC5REF_r_or_OC6REF_r": + OC5REF or OC6REF rising edges generate pulses. + - "compare_pulse_OC5REF_r_or_OC6REF_f": + OC5REF rising or OC6REF falling edges gener
Re: [PATCH] iio: st_pressure: st_accel: Initialise sensor platform data properly
On 28/04/17 05:11, Shrirang Bagul wrote: > On Wed, 2017-04-26 at 06:37 +0100, Jonathan Cameron wrote: >> On 19/04/17 15:05, Shrirang Bagul wrote: >>> This patch fixes the sensor platform data initialisation for st_pressure >>> and st_accel device drivers. Without this patch, the driver fails to >>> register the sensors when the user removes and re-loads the driver. >>> >>> 1. Unload the kernel modules for st_pressure >>> $ sudo rmmod st_pressure_i2c >>> $ sudo rmmod st_pressure >>> >>> 2. Re-load the driver >>> $ sudo insmod st_pressure >>> $ sudo insmod st_pressure_i2c >>> --- OR --- >>> $ sudo modprobe st_pressure_i2c >>> >>> dmesg errors: >>> >>> [ 160.935707] iio iio:device2: DRDY on pdata not valid. >>> [ 160.941505] st-press-i2c: probe of i2c-SMO9210:00 failed with error -22 >>> >>> The driver fails to register the pressure sensor device. Devices >>> supported by st_accel driver also suffer from the same bug. >>> >>> Signed-off-by: Shrirang Bagul >> >> Unless I am missing something, the severity of this bug is fairly minor >> so whilst I'm pleased to have it fixed, I'm not intending to mark this >> for stable. >> >> If anyone has a cunning way of exploiting it then let me know! > Stress testing st_pressure_i2c, st_pressure module load/unload does cause the > kernel > to panic. That requires root access, and isn't something that is done under normal operation. I assumed it would crash - question was whether the crash could be exploited to do anything else. I'm thinking no, so it's low severity. Jonathan > > Apr 27 18:11:21 caracalla kernel: [ 8417.756968] BUG: unable to handle kernel > paging > request at c0377c48 > Apr 27 18:11:21 caracalla kernel: [ 8417.764869] IP: [] > st_sensors_init_sensor+0x26/0x1f0 [st_sensors] > Apr 27 18:11:21 caracalla kernel: [ 8417.773550] PGD 2e0d067 PUD 2e0f067 PMD > 3792b067 > PTE 0 > Apr 27 18:11:21 caracalla kernel: [ 8417.779382] Oops: [#1] SMP > Apr 27 18:11:21 caracalla kernel: [ 8417.783045] Modules linked in: > st_pressure_i2c(+) st_pressure hts221_i2c msr cmac algif_hash algif_skcipher > af_alg > hci_vhci rfcomm bnep arc4 iTCO_wdt iTCO_vendor_support > snd_soc_sst_bytcr_rt5660 > dell_wmi sparse_keymap ven_rsi_sdio ven_rsi_91x intel_soc_dts_iosf bluetooth > intel_powerclamp coretemp kvm_intel kvm dcdbas mac80211 irqbypass > punit_atom_debug > crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 > cfg80211 lrw > gf128mul glue_helper ablk_helper input_leds cryptd psmouse serio_raw cdc_mbim > cdc_wdm > cdc_ncm uas r8169 usbnet cdc_acm lpc_ich mii mei_txe mei snd_intel_sst_acpi > shpchp > snd_intel_sst_core snd_soc_rt5660 snd_soc_sst_mfld_platform snd_soc_rl6231 > snd_soc_core 8250_fintek fjes st_accel_i2c st_accel st_sensors_i2c hts221 > i2c_hid > st_sensors snd_compress ad5593r ac97_bus hid industrialio_triggered_buffer > kfifo_buf > ad5592r_base industrialio snd_pcm_dmaengine snd_pcm tpm_crb snd_timer dw_dmac > snd > dw_dmac_core soundcore rfkill_gpio mac_hid spi_pxa2xx_platform > i2c_designware_platform i2c_designware_core pwm_lpss_platform snd_soc_sst_acpi > 8250_dw pwm_lpss iptable_filter ip_tables ip6table_filter ip6_tables x_tables > autofs4 > sdhci_pci virtio_scsi ahci libahci mmc_block i915 i2c_algo_bit drm_kms_helper > syscopyarea sysfillrect sysimgblt fb_sys_fops usb_storage drm wmi video > sdhci_acpi > sdhci [last unloaded: st_pressure] > Apr 27 18:11:21 caracalla kernel: [ 8417.917926] CPU: 0 PID: 15523 Comm: > modprobe Not > tainted 4.4.0-77-generic #98-Ubuntu > Apr 27 18:11:21 caracalla kernel: [ 8417.926686] Hardware name: Dell Inc. Edge > Gateway 3003/ , BIOS 00.00.28 03/23/2017 > Apr 27 18:11:21 caracalla kernel: [ 8417.935739] task: 88007521a640 ti: > 88007639c000 task.ti: 88007639c000 > Apr 27 18:11:21 caracalla kernel: [ 8417.944202] RIP: > 0010:[] > [] st_sensors_init_sensor+0x26/0x1f0 [st_sensors] > Apr 27 18:11:21 caracalla kernel: [ 8417.955627] RSP: 0018:88007639fac8 > EFLAGS: > 00010206 > Apr 27 18:11:21 caracalla kernel: [ 8417.961632] RAX: c0328640 RBX: > 880076832800 RCX: 0003 > Apr 27 18:11:21 caracalla kernel: [ 8417.969702] RDX: 8800371c9820 RSI: > c0377c48 RDI: 880076832800 > Apr 27 18:11:21 caracalla kernel: [ 8417.92] RBP: 88007639fad0 R08: > 88007639c000 R09: > Apr 27 18:11:21 caracalla kernel: [ 8417.985841] R10: 00b6 R11: > R12: > Apr 27 18:11:21 caracalla kernel: [ 8417.993911] R13: 0003 R14: > 880076832cc0 R15: c03730a0 > Apr 27 18:11:21 caracalla kernel: [ 8418.001982] FS: 7f71faa83700() > GS:880070a0() knlGS: > Apr 27 18:11:21 caracalla kernel: [ 8418.011133] CS: 0010 DS: ES: > CR0: > 80050033 > Apr 27 18:11:21 caracalla kernel: [ 8418.017629] CR2: c0377c48 CR3: > 74d7d000 CR4: 001006f0 > Apr 27 18:11:21 caracalla kernel: [ 8418.025698] Sta
Re: uvcvideo logging kernel warnings on device disconnect
On Sun, Apr 30, 2017 at 06:19:59PM +0200, Greg KH wrote: > On Sun, Apr 16, 2017 at 02:11:31PM +0300, Laurent Pinchart wrote: > > Hi Greg, > > > > On Wednesday 21 Dec 2016 10:59:54 Greg KH wrote: > > > On Tue, Dec 20, 2016 at 11:19:23AM +, Dave Stevenson wrote: > > > > On 09/12/16 09:43, Greg KH wrote: > > > >> On Fri, Dec 09, 2016 at 11:14:41AM +0200, Laurent Pinchart wrote: > > > >>> On Friday 09 Dec 2016 10:11:13 Greg KH wrote: > > > On Fri, Dec 09, 2016 at 10:59:24AM +0200, Laurent Pinchart wrote: > > > > On Friday 09 Dec 2016 08:25:52 Greg KH wrote: > > > >> On Fri, Dec 09, 2016 at 01:09:21AM +0200, Laurent Pinchart wrote: > > > >>> On Thursday 08 Dec 2016 12:31:55 Dave Stevenson wrote: > > > Hi All. > > > > > > I'm working with a USB webcam which has been seen to > > > spontaneously disconnect when in use. That's a separate > > > issue, but when it does it throws a load of warnings into > > > the kernel log if there is a file handle on the device open > > > at the time, even if not streaming. > > > > > > I've reproduced this with a generic Logitech C270 webcam on: > > > - Ubuntu 16.04 (kernel 4.4.0-51) vanilla, and with the > > > latest media tree from linuxtv.org > > > - Ubuntu 14.04 (kernel 4.4.0-42) vanilla > > > - an old 3.10.x tree on an embedded device. > > > > > > To reproduce: > > > - connect USB webcam. > > > - run a simple app that opens /dev/videoX, sleeps for a > > > while, and then closes the handle. > > > - disconnect the webcam whilst the app is running. > > > - read kernel logs - observe warnings. We get the disconnect > > > logged as it occurs, but the warnings all occur when the > > > file descriptor is closed. (A copy of the logs from my > > > Ubuntu 14.04 machine are below). > > > > > > I can fully appreciate that the open file descriptor is > > > holding references to a now invalid device, but is there a > > > way to avoid them? Or do we really not care and have to put > > > up with the log noise when doing such silly things? > > > >>> > > > >>> This is a known problem, caused by the driver core trying to > > > >>> remove the same sysfs attributes group twice. > > > >> > > > >> Ick, not good. > > > >> > > > >>> The group is first removed when the USB device is > > > >>> disconnected. The input device and media device created by the > > > >>> uvcvideo driver are children of the USB interface device, > > > >>> which is deleted from the system when the camera is unplugged. > > > >>> Due to the parent-child relationship, all sysfs attribute > > > >>> groups of the children are removed. > > > >> > > > >> Wait, why is the USB device being removed from sysfs at this > > > >> point, didn't the input and media subsystems grab a reference to > > > >> it so that it does not disappear just yet? > > > > > > > > References are taken in uvc_prove(): > > > > dev->udev = usb_get_dev(udev); > > > > dev->intf = usb_get_intf(intf); > > > > > > s/uvc_prove/uvc_probe/ ? :) > > > >>> > > > >>> Oops :-) > > > >>> > > > > and released in uvc_delete(), called when the last video device > > > > node is closed. This prevents the device from being released > > > > (freed), but device_del() is synchronous to device unplug as far > > > > as I understand. > > > > > > Ok, good, that means the UVC driver is doing the right thing here. > > > > > > But the sysfs files should only be attempted to be removed by the > > > driver core once, when the device is removed from sysfs, not twice, > > > which is really odd. > > > > > > Is there a copy of the "simple app that grabs the device node" > > > anywhere so that I can test it out here with my USB camera device to > > > try to track down where the problem is? > > > >>> > > > >>> Sure. The easiest way is to grab http://git.ideasonboard.org/yavta.git > > > >>> and run > > > >>> > > > >>> yavta -c /dev/video0 > > > >>> > > > >>> (your mileage may vary if you have other video devices) > > > >> > > > >> I'll point it at the correct device, /dev/video0 is built into this > > > >> laptop and can't be physically removed :) > > > >> > > > >>> While the application is running, unplug the webcam, and then > > > >>> terminate the application with ctrl-C. > > > >> > > > >> Ok, will try this out this afternoon and let you know how it goes. > > > > > > > > I hate to pester, but wondered if you had found anything obvious. > > > > I really do appreciate you taking the time to look. > > > > > > Sorry, I haven't had the chance and now will not be able to until > > > January > > > > Did you mean January 2017 or 2018 ? :-) >
