Re: [PATCH 4.19 83/92] mfd: dln2: Run event handler loop under spinlock

Hi! > From: Andy Shevchenko > > [ Upstream commit 3d858942250820b9adc35f963a257481d6d4c81d ] > > The event handler loop must be run with interrupts disabled. > Otherwise we will have a warning: ... > Recently xHCI driver switched to tasklets in the commit 36dc01657b49 > ("usb: host: xhci:

Re: [PATCH 4.9 196/212] gpu: ipu-v3: image-convert: Combine rotate/no-rotate irq handlers

Hi! > From: Steve Longerbeam > > [ Upstream commit 0f6245f42ce9b7e4d20f2cda8d5f12b55a44d7d1 ] > > Combine the rotate_irq() and norotate_irq() handlers into a single > eof_irq() handler. AFAICT this is preparation for next patch, not a backfix. And actual fix patch is not there for 4.19, so

Re: [PATCH 4.14 196/228] RDMA/ipoib: Return void from ipoib_ib_dev_stop()

Hi! > From: Kamal Heib > > [ Upstream commit 95a5631f6c9f3045f26245e6045244652204dfdb ] > > The return value from ipoib_ib_dev_stop() is always 0 - change it to be > void. AFAICT this is not a fixup, just a preparation for "RDMA/ipoib: Fix ABBA deadlock with ipoib_reap_ah(", but we are not

Re: [PATCH] leds: s3c24xx: Remove unused machine header include

On Thu 2020-08-20 18:08:16, Krzysztof Kozlowski wrote: > On Wed, Aug 05, 2020 at 11:57:30PM +0200, Pavel Machek wrote: > > On Mon 2020-08-03 11:19:36, Krzysztof Kozlowski wrote: > > > The driver includes machine header for GPIO registers but actually does > > > not us

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

Hi! > > I think there's been some discussion about reverting that change for > > other reasons, but it's quite likely the culprit. > > Hmm. It reverts cleanly, but the end result doesn't work, because of > other changes. > > Reverting all of > >763fedd6a216 ("drm/i915: Remove

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

Hi! > > I think there's been some discussion about reverting that change for > > other reasons, but it's quite likely the culprit. > > Hmm. It reverts cleanly, but the end result doesn't work, because of > other changes. > > Reverting all of > >763fedd6a216 ("drm/i915: Remove

Re: GPS fun on Droid 4 and leste

Hi! > > GPS on the droid 4 does not really work out of the box. > > > > gpsd is not in default installation, maybe it should be? > > > > What is worse, there's something broken with gpsd. Try: > > > > /usr/sbin/gpsd -N -D 5 /dev/gnss0 > > gpspipe -w > > # this seems to work, but do ^C and

Re: [RFC] Limiting charge current on Droid 4 (and N900)

Hi! > > > Droid 4 has same problem as N900: it is often neccessary to manually > > > tweak current draw from USB, for example when using thin charging cable. > > > > > > N900 creates unique attribute by hand, but I believe > > > POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT looks suitable. (Should N900

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

On Tue 2020-08-18 18:59:27, Linus Torvalds wrote: > On Tue, Aug 18, 2020 at 6:13 PM Dave Airlie wrote: > > > > I think there's been some discussion about reverting that change for > > other reasons, but it's quite likely the culprit. > > Hmm. It reverts cleanly, but the end result doesn't work,

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

On Tue 2020-08-18 18:59:27, Linus Torvalds wrote: > On Tue, Aug 18, 2020 at 6:13 PM Dave Airlie wrote: > > > > I think there's been some discussion about reverting that change for > > other reasons, but it's quite likely the culprit. > > Hmm. It reverts cleanly, but the end result doesn't work,

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Replace reloc chain with terminator on error unwind

Hi! > > Yep, my machines are low on memory. > > > > But ... test did not work that well. I have dead X and blinking > > screen. Machine still works reasonably well over ssh, so I guess > > that's an improvement. > > > [ 7744.718473] BUG: unable to handle page fault for address: f8c0 > > [

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Replace reloc chain with terminator on error unwind

Hi! > > > If we hit an error during construction of the reloc chain, we need to > > > replace the chain into the next batch with the terminator so that upon > > > flushing the relocations so far, we do not execute a hanging batch. > > > > Thanks for the patches. I assume this should fix problem

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Replace reloc chain with terminator on error unwind

Hi! > If we hit an error during construction of the reloc chain, we need to > replace the chain into the next batch with the terminator so that upon > flushing the relocations so far, we do not execute a hanging batch. Thanks for the patches. I assume this should fix problem from "5.9-rc1:

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

Hi! > > I think there's been some discussion about reverting that change for > > other reasons, but it's quite likely the culprit. > > Hmm. It reverts cleanly, but the end result doesn't work, because of > other changes. > > Reverting all of > >763fedd6a216 ("drm/i915: Remove

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

Hi! > > I think there's been some discussion about reverting that change for > > other reasons, but it's quite likely the culprit. > > Hmm. It reverts cleanly, but the end result doesn't work, because of > other changes. > > Reverting all of > >763fedd6a216 ("drm/i915: Remove

Re: [PATCH 4.19 073/168] media: firewire: Using uninitialized values in node_probe()

igned and -ENOENT is type promoted to a very high positive value. > Then the "strncmp(name, model_names[i], name_len)" uses uninitialized > data because "name" is uninitialized. This causes memory leak, AFAICT. Signed-off-by: Pavel Machek (CIP) Best regards,

Re: [PATCH 4.19 000/168] 4.19.140-rc1 review

Hi! > This is the start of the stable review cycle for the 4.19.140 release. > There are 168 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 19 Aug 2020 14:36:49

Re: [PATCH 4.19 051/168] dyndbg: fix a BUG_ON in ddebug_describe_flags

On Mon 2020-08-17 17:16:22, Greg Kroah-Hartman wrote: > From: Jim Cromie > > [ Upstream commit f678ce8cc3cb2ad29df75d8824c74f36398ba871 ] > > ddebug_describe_flags() currently fills a caller provided string buffer, > after testing its size (also passed) in a BUG_ON. Fix this by > replacing

Re: [PATCH 4.19 040/168] drm/radeon: disable AGP by default

On Mon 2020-08-17 17:16:11, Greg Kroah-Hartman wrote: > From: Christian König > > [ Upstream commit ba806f98f868ce107aa9c453fef751de9980e4af ] > > Always use the PCI GART instead. We just have to many cases > where AGP still causes problems. This means a performance > regression for some GPUs,

Re: [PATCH 4.19 027/168] Bluetooth: add a mutex lock to avoid UAF in do_enale_set

e to avoid > this bug. For this to be safe, bt_6lowpan_exit() needs same handling, no? Signed-off-by: Pavel Machek (CIP) diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c index 9a75f9b00b51..2402ef5ac072 100644 --- a/net/bluetooth/6lowpan.c +++ b/net/bluetooth/6lowpan.c @@ -1304,10 +1304,

Re: [PATCH 4.19 012/168] crypto: ccree - fix resource leak on error path

Hi! > Fix a small resource leak on the error path of cipher processing. I believe this one is wrong. > @@ -149,10 +148,19 @@ static int cc_cipher_init(struct crypto_tfm *tfm) > ctx_p->flow_mode = cc_alg->flow_mode; > ctx_p->drvdata = cc_alg->drvdata; > > + if

Re: [PATCH] Makefile: Yes. Finally remove '-Wdeclaration-after-statement'

On Mon 2020-08-17 14:29:37, Linus Torvalds wrote: > On Mon, Aug 17, 2020 at 2:15 PM Eric W. Biederman > wrote: > > > > Does anyone remember why we added this warning? I had always thought > > it's purpose was to ensure we stayed within our chosen dialect of C. > > As far as I'm concerned,

Re: [PATCH] Makefile: Yes. Finally remove '-Wdeclaration-after-statement'

Hi! > > This is not just a matter of style; this is a matter of semantics, > > especially with regard to: > > > > * const Correctness. > > A const-declared variable must be initialized when defined. > > > > * Conditional Compilation. > > When there is complex interaction between

Re: [PATCH] Makefile: Yes. Finally remove '-Wdeclaration-after-statement'

On Sun 2020-08-16 21:19:23, Joe Perches wrote: > On Mon, 2020-08-17 at 03:37 +, Michael Witten wrote: > > Matters of style should probably not be enforced by the build > > infrastructure; style is a matter for the maintainer to enforce: > > I rather doubt style advice should be taken from

Re: [PATCH v33 0/6] LP50xx addition and remainder Multicolor patches

Hi! > These are the final patches from the original multicolor framework patchset. > > Changes made were to the LP50xx to rework regmap_defaults to eliminate used > only once #defines. Also fixed putting the child node in the dt parsing and > changed regmap regcache type to flat. Thanks. I

Re: [PATCH] leds: LP55XX_COMMON needs to depend on LEDS_CLASS

er_leds': > leds-lp55xx-common.c:(.text+0xc5f): undefined reference to > `devm_led_classdev_register_ext' > > Fixes: 33b3a561f417 ("leds: support new LP8501 device - another LP55xx > common") > Signed-off-by: Randy Dunlap > Cc: Pavel Machek > Cc: Dan Murphy

Re: [PATCH v2 1/2] dt-bindings: leds: pca955x: Add IBM implementation compatible string

On Wed 2020-08-12 13:57:47, Rob Herring wrote: > On Mon, 03 Aug 2020 09:50:54 -0500, Eddie James wrote: > > IBM created an implementation of the PCA9552 on a PIC16F > > microcontroller. Document the new compatible string for this device. > > > > Signed-off-by: Eddie James > > --- > >

5.9-rc1: graphics regression moved from -next to mainline

Hi! After about half an hour of uptime, screen starts blinking on thinkpad x60 and machine becomes unusable. I already reported this in -next, and now it is in mainline. It is 32-bit x86 system. Pavel Aug 17 17:36:04 amd

[Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

Hi! After about half an hour of uptime, screen starts blinking on thinkpad x60 and machine becomes unusable. I already reported this in -next, and now it is in mainline. It is 32-bit x86 system. Pavel Aug 17 17:36:04 amd

Re: [PATCH 1/2] kexec: Add quick kexec support for kernel

Hi! > +config QUICK_KEXEC > + bool "Support for quick kexec" > + depends on KEXEC_CORE > + help > + Say y here to enable this feature. ? > + It use reserved memory to accelerate kexec, just like crash uses > + kexec, load new kernel and initrd to reserved memory,

Re: [PATCH 1/2] kexec: Add quick kexec support for kernel

Hi! > +config QUICK_KEXEC > + bool "Support for quick kexec" > + depends on KEXEC_CORE > + help > + Say y here to enable this feature. ? > + It use reserved memory to accelerate kexec, just like crash uses > + kexec, load new kernel and initrd to reserved memory,

Re: [PATCH RFC 1/2] mm: Extract SLAB_QUARANTINE from KASAN

On Sat 2020-08-15 19:54:55, Matthew Wilcox wrote: > On Thu, Aug 13, 2020 at 06:19:21PM +0300, Alexander Popov wrote: > > +config SLAB_QUARANTINE > > + bool "Enable slab freelist quarantine" > > + depends on !KASAN && (SLAB || SLUB) > > + help > > + Enable slab freelist quarantine to

Re: [talk-cz] Hromadná editace zákazu vjezdu na kolech v národních přírodních rezervacích

Ahoj! > Dávám ke zvážení, zda v národních přírodních rezervacích neudělat hromadnou > editaci, a nevyznačit tam zákaz vjezdu na kolech na všechny lesní cesty a > pěšiny, kde není vyznačená cyklotrasa. Zatím tam cyklonavigace spokojeně > navádí, viz vedlejší vlákna. > Dotaz na Overpass turbo,

Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver

Hi! > >>Well it depends on where we want to create the default cache values. > >> > >>Either we run through a for..loop during driver probe and delay device start > >>up or we keep the simple arrays and increase the driver total size. > >for loop will be better. > > > >Plus, REGCACHE_RBTREE is

Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)

Hi! > > > > (eg, a specification) will be critical for remote filesystems. > > > > > > > > If any of this is to be supported by a remote filesystem, then we > > > > need an unencumbered description of the new metadata format > > > > rather than code. GPL-encumbered formats cannot be contributed

Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver

Hi! > >Actually... This is quite impressive ammount of code to > >zero-initialize few registers. Could the regmap be told to set the > >range to zero, or use loops to reduce ammount of code? > > I am not aware of any regmap calls that will set a range of registers to a > certain value. > > Well

Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)

Hi! > > > > (eg, a specification) will be critical for remote filesystems. > > > > > > > > If any of this is to be supported by a remote filesystem, then we > > > > need an unencumbered description of the new metadata format > > > > rather than code. GPL-encumbered formats cannot be contributed

Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)

Hi! > > > > (eg, a specification) will be critical for remote filesystems. > > > > > > > > If any of this is to be supported by a remote filesystem, then we > > > > need an unencumbered description of the new metadata format > > > > rather than code. GPL-encumbered formats cannot be contributed

[PATCH] leds: we don't want people to use LED subsystem for vibrations

using input subsystem. Signed-off-by: Pavel Machek diff --git a/Documentation/leds/ledtrig-transient.rst b/Documentation/leds/ledtrig-transient.rst index eedfa1626e8a..63072f310660 100644 --- a/Documentation/leds/ledtrig-transient.rst +++ b/Documentation/leds/ledtrig-transient.rst

Re: [talk-cz] Brod na turistické a cyklotrase trase, za vyššího stavu neprůchozí - jak označit

On Mon 2020-08-10 17:34:24, Jan Macura wrote: > Ahoj > > On Mon, 10 Aug 2020 at 16:59, majkaz wrote: > > > Včera jsem byla docela nemile překvapená zmizelou lávkou > > přes > > Lužnici. Bohužel je tam zrovna vysoký stav vody,

Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor

Hi! > >> Thanks for the lively discussion. I have tried to answer some of the > >> comments below. > > > >>> There are options today, e.g. > >>> > >>> a) If the restriction is only per-alias, you can have distinct aliases > >>>where one is writable and another is executable, and you can make

Re: [PATCH 4.19 47/48] i40e: Memory leak in i40e_config_iwarp_qvlist

Hi! > From: Martyna Szapar > > [ Upstream commit 0b63644602cfcbac849f7ea49272a39e90fa95eb ] > > Added freeing the old allocation of vf->qvlist_info in function > i40e_config_iwarp_qvlist before overwriting it with > the new allocation. Ok, but this also other error paths: > ---

Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver

Hi! > +/* LP5009 and LP5012 registers */ > +#define LP5012_BNK_BRT 0x03 > +#define LP5012_BNKA_CLR 0x04 > +#define LP5012_BNKB_CLR 0x05 > +#define LP5012_BNKC_CLR 0x06 > +#define LP5012_LED0_BRT 0x07 > +#define LP5012_LED1_BRT

Re: [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers

On Fri 2020-08-07 08:42:32, Dan Murphy wrote: > Pavel > > On 8/4/20 2:55 PM, Dan Murphy wrote: > > Pavel > > > > On 7/28/20 8:39 AM, Dan Murphy wrote: > > > Pavel > > > > > > On 7/22/20 10:31 AM, Dan Murphy wrote: > > > > Introduce the bindings for the Texas Instruments LP5036, LP5030, > > > >

Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver

Hi! > Introduce the LP5036/30/24/18/12/9 RGB LED driver. > The difference in these parts are the number of > LED outputs where the: > > LP5036 can control 36 LEDs > LP5030 can control 30 LEDs > LP5024 can control 24 LEDs > LP5018 can control 18 LEDs > LP5012 can control 12 LEDs > LP5009 can

Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver

Hi! > Introduce the LP5036/30/24/18/12/9 RGB LED driver. > The difference in these parts are the number of > LED outputs where the: > > LP5036 can control 36 LEDs > LP5030 can control 30 LEDs > LP5024 can control 24 LEDs > LP5018 can control 18 LEDs > LP5012 can control 12 LEDs > LP5009 can

Re: [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers

.ti.com/lit/ds/symlink/lp5036.pdf > > Reviewed-by: Rob Herring > Acked-by: Jacek Anaszewski > Signed-off-by: Dan Murphy Acked-by: Pavel Machek > + multi-led@1 { > + #address-cells = <1>; > + #size-cells =

Re: [PATCH 4.19 00/48] 4.19.139-rc1 review

On Mon 2020-08-10 17:21:22, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.19.139 release. > There are 48 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > >

Re: [PATCH 4.19 25/48] firmware: Fix a reference count leak.

Hi! > From: Qiushi Wu > > [ Upstream commit fe3c60684377d5ad9b0569b87ed3e26e12c8173b ] > > kobject_init_and_add() takes reference even when it fails. > If this function returns an error, kobject_put() must be called to > properly clean up the memory associated with the object. > Callback

Re: [PATCH 4.19 14/48] mtd: properly check all write ioctls for permissions

Hi! > From: Greg Kroah-Hartman > > commit f7e6b19bc76471ba03725fe58e0c218a3d6266c3 upstream. > > When doing a "write" ioctl call, properly check that we have permissions > to do so before copying anything from userspace or anything else so we > can "fail fast". This includes also covering the

Re: [PATCH 4.19 06/48] ALSA: seq: oss: Serialize ioctls

Hi! > commit 80982c7e834e5d4e325b6ce33757012ecafdf0bb upstream. > > Some ioctls via OSS sequencer API may race and lead to UAF when the > port create and delete are performed concurrently, as spotted by a > couple of syzkaller cases. This patch is an attempt to address it by > serializing the

Re: [PATCH] iio: documentation: light: Add as73211 sysfs documentation

On Mon 2020-08-10 11:57:46, Christian Eggers wrote: > On Monday, 10 August 2020, 11:00:54 CEST, Pavel Machek wrote: > > Hi! > > > > > The driver for the as73211 light sensor provides the following not yet > > > documented sysfs entries: > > > - in_intensi

Re: [RFC PATCH 0/7] metricfs metric file system and examples

On Fri 2020-08-07 14:29:09, Jonathan Adams wrote: > [resending to widen the CC lists per rdun...@infradead.org's suggestion > original posting to lkml here: https://lkml.org/lkml/2020/8/5/1009] > > To try to restart the discussion of kernel statistics started by the > statsfs patchsets

Re: [PATCH] iio: documentation: light: Add as73211 sysfs documentation

Hi! > The driver for the as73211 light sensor provides the following not yet > documented sysfs entries: > - in_intensity_(x|y|z)_raw > - in_intensity_(x|y|z)_scale > - in_intensity_sampling_frequency(_available) > - in_intensity_hardwaregain(_available) Should that be hardware_gain ?

Re: [PATCH] leds: mt6323: move period calculation

Hi! > Setting the delay_on/off means period needs to be recalculated > anyway. So move the period statements after this check. > > Fixes: 216ec6cc4c19 ("leds: Add LED support for MT6323 PMIC") Makes sense, thanks, applied. Best regards,

Re: [PATCH v36 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals

Hi! > Good morning, I hope the week is progressing well for everyone. > > > > CPUs starting from Icelake use Total Memory Encryption (TME) in > > > the place of MEE. TME throws away the Merkle tree, which means > > > losing integrity and anti-replay protection but also enables > > > variable

Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor

Hi! > Thanks for the lively discussion. I have tried to answer some of the > comments below. > > There are options today, e.g. > > > > a) If the restriction is only per-alias, you can have distinct aliases > >where one is writable and another is executable, and you can make it > >hard to

-next on 32-bit thinkpad x60: blinking screen, intel DRM responsible?

Hi! Next has been unusable for a while, but today I got dmesg. Screen is blinking, machine is very unhappy, and ssh is slow/hangs, but I got this: This is recurring patern, usually machine dies like this within 30 minutes of boot. [ 455.019838] perf: interrupt took too long (2509 > 2500),

[Intel-gfx] -next on 32-bit thinkpad x60: blinking screen, intel DRM responsible?

Hi! Next has been unusable for a while, but today I got dmesg. Screen is blinking, machine is very unhappy, and ssh is slow/hangs, but I got this: This is recurring patern, usually machine dies like this within 30 minutes of boot. [ 455.019838] perf: interrupt took too long (2509 > 2500),

Re: [talk-cz] Značky highway_1 v datech

Ahoj! > Narazila jsem v datech na to, že máme některé silnice zmapované i pomocí > značek highway_1/2/... > Je jich pár v okolí Prahy, pak Vltavotýnsko a zbytek je na Moravě, především > mezi Brnem a Olomoucí. >   > Bylo by dobře to projít a naházet ty značky nějak smysluplně, nejlépe někdo, >

Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class

On Sat 2020-07-25 20:48:46, Andrew Lunn wrote: > > > > +#if 0 > > > > + /* LED_COLOR_ID_MULTI is not yet merged in Linus' tree */ > > > > + /* TODO: Support DUAL MODE */ > > > > + if (color == LED_COLOR_ID_MULTI) { > > > > + phydev_warn(phydev, "node %pOF: This

Re: [PATCH RFC leds + net-next v4 0/2] Add support for LEDs on Marvell PHYs

Hi! > this is v4 of my RFC adding support for LEDs connected to Marvell PHYs. > > Please note that if you want to test this, you still need to first apply > the patch adding the LED private triggers support from Pavel's tree. >

Re: [PATCH v7 1/3] leds: move default_state read from fwnode to core

Hi! > Signed-off-by: Denis Osterland-Heim This tells me you: 1) you are probably not copyright owner 2) you want your company to promise not to sue people, in a legally binding way. > The contents of the above mentioned e-mail is not legally > binding. This e-mail contains confidential

Re: [PATCH v2 2/2] leds: pca955x: Add an IBM software implementation of the PCA9552 chip

this device. > > Signed-off-by: Eddie James > Reviewed-by: Vishwanatha Subbanna Acked-by: Pavel Machek This can be applied when Rob ack's the device tree change. I'll ask you to do new patch version when that happens. Best regards,

Re: [PATCH 4.19 0/6] 4.19.138-rc1 review

Hi! > This is the start of the stable review cycle for the 4.19.138 release. > There are 6 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri, 07 Aug 2020 15:34:53

Re: [PATCH 1/2] leds: is31fl319x: Add sdb pin and generate a 5ms low pulse when startup

Hi! > On 8/6/20 1:21 AM, Grant Feng wrote: > > generate a 5ms low pulse on sdb pin when startup, then the chip > > becomes more stable in the complex EM environment. > > > > Signed-off-by: Grant Feng > > --- > > drivers/leds/leds-is31fl319x.c | 12 > > 1 file changed, 12

Re: [PATCH] leds: s3c24xx: Remove unused machine header include

On Mon 2020-08-03 11:19:36, Krzysztof Kozlowski wrote: > The driver includes machine header for GPIO registers but actually does > not use them. > > Signed-off-by: Krzysztof Kozlowski Thanks, applied. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures)

Re: [PATCH v1] leds: is31fl32xx: Add sdb pin and generate a 5ms low pulse when startup

On Mon 2020-08-03 18:29:35, Grant Feng wrote: > generate a 5ms low pulse on sdb pin when startup, then the chip > becomes more stable in the complex EM environment. Thanks, applied. Pavel

[GIT PULL] LEDs changes for v5.9-rc1

Omnia LEDs Documentation: ABI: leds-turris-omnia: document sysfs attribute Pavel Machek (3): leds: pattern trigger -- check pattern for validity leds: add RGB color option, as that is different from multicolor. leds: disallow /sys/class/leds/*:multi:* for now Randy Dunlap (1

Re: [GIT PULL 0/5] ARM: SoC: changes for v5.9

Hi! > Thanks for all the kind words, I really appreciate it. Thanks for good work :-). > >My impression is that the newly added phones are still fairly rudimentary, > >but some others that were added in the past releases have gotten > >further. I don't know any details, but I've added Konrad to

Re: [GIT PULL 0/5] ARM: SoC: changes for v5.9

On Wed 2020-08-05 21:06:45, Arnd Bergmann wrote: > On Wed, Aug 5, 2020 at 7:27 PM Pavel Machek wrote: > > > 2. In the past few merge windows we have seen an increase in (usually > > >older) Android phones and tablets gaining mainline kernel support. > > >Thi

Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence

On Wed 2020-08-05 20:50:43, Geert Uytterhoeven wrote: > Hi Pavel, > > On Wed, Aug 5, 2020 at 7:26 PM Pavel Machek wrote: > > > I have submitted the below as a topic for the linux/arch/* MC that Mike > > > and I run, but I suppose it also makes sense to discuss it o

Re: [PATCH] CREDITS: add myself

Hi! > Rationale: > 50 already merged patches of mine. I don't believe anyone really maintains (or uses) CREDITS these days. Maybe akpm would be willing to take it? Best regards, Pavel > diff --git a/CREDITS b/CREDITS >

Re: [PATCH] MAINTAINERS: Remove myself as LED subsystem maintainer

wski Acked-by: Pavel Machek (I'm not sure what the process is here, do I take it through the LED tree?) Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~p

Re: [GIT PULL 0/5] ARM: SoC: changes for v5.9

Hi! > 2. In the past few merge windows we have seen an increase in (usually >older) Android phones and tablets gaining mainline kernel support. >This time we get a total of eight Snapdragon phones and two Tegra >tablets. To me this indicates that we finally have sufficient driver >

Re: [TECH TOPIC] Planning code obsolescence

Hi! > I have submitted the below as a topic for the linux/arch/* MC that Mike > and I run, but I suppose it also makes sense to discuss it on the > ksummit-discuss mailing list (cross-posted to linux-arch and lkml) as well > even if we don't discuss it at the main ksummit track. > * Latest

Re: [PATCH v4 3/6] can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.

Hi! > More about CAN related projects used and developed at the Faculty > of the Electrical Engineering (http://www.fel.cvut.cz/en/) > of Czech Technical University (https://www.cvut.cz/en) > in at Prague http://canbus.pages.fel.cvut.cz/ . Should this go to Documentation, not a changelog? > +

Re: [PATCH v4 2/6] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.

On Tue 2020-08-04 11:18:17, Pavel Machek wrote: > Hi! > > > The commit text again to make checkpatch happy. > > ? > > > > +oneOf: > > + - items: > > + - const: ctu,ctucanfd > > + - const: ctu,canfd-2 > > + -

Re: [PATCH v4 2/6] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.

Hi! > The commit text again to make checkpatch happy. ? > +oneOf: > + - items: > + - const: ctu,ctucanfd > + - const: ctu,canfd-2 > + - const: ctu,ctucanfd For consistency, can we have ctu,canfd-1, ctu,canfd-2? Best regards,

Re: [PATCH] lz4: Fix kernel decompression speed

Hi! > >> I've measured the kernel decompression speed using QEMU before and after > >> this patch for the x86_64 and i386 architectures. The speed-up is about > >> 10x as shown below. > >> > >> Code ArchKernel Size TimeSpeed > >> v5.8 x86_64 11504832 B 148 ms 79

Re: [PATCH 4.19 00/56] 4.19.137-rc1 review

Hi! > This is the start of the stable review cycle for the 4.19.137 release. > There are 56 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 05 Aug 2020 12:18:33

Re: [PATCH 4.19 31/56] net/mlx5: Verify Hardware supports requested ptp function on a given pin

T_PPS_OUT); > + default: > + return -EOPNOTSUPP; > + } > + > + return -EOPNOTSUPP; > } The last return statement is unreachable code. I'm not sure if it will provoke any warnings, but it looks ugly. Signed-off-by: Pavel Machek (CIP) diff --git a/drivers/net/ethe

Re: [PATCH 4.19 09/56] btrfs: inode: Verify inode mode to avoid NULL pointer dereference

Hi! > @@ -6993,6 +7010,14 @@ struct extent_map *btrfs_get_extent(struct btrfs_inode > *inode, > extent_start = found_key.offset; > if (found_type == BTRFS_FILE_EXTENT_REG || > found_type == BTRFS_FILE_EXTENT_PREALLOC) { > + /* Only regular file could have

Re: [PATCH v2 2/2] leds: pca955x: Add an IBM software implementation of the PCA9552 chip

On Mon 2020-08-03 19:42:17, Andy Shevchenko wrote: > On Mon, Aug 3, 2020 at 5:51 PM Eddie James wrote: > > > > IBM created an implementation of the PCA9552 on a PIC16F > > microcontroller. The I2C device addresses are different from the > > hardware PCA9552, so add a new compatible string and

[PATCH] btrfs: fix error value in btrfs_get_extent

btrfs_get_extent() sets variable ret, but out: error path expect error to be in variable err. Fix that. Signed-off-by: Pavel Machek (CIP) --- Notice that patch introducing this problem is on its way to 4.19.137-stable. diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 7befb7c12bd3

Re: [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)

On Sun 2020-08-02 10:03:00, Sasha Levin wrote: > On Sun, Aug 02, 2020 at 01:55:45PM +0200, Pavel Machek wrote: > >Hi! > > > >>IPE is a Linux Security Module which allows for a configurable > >>policy to enforce integrity requirements on the whole system. It > &

Re: [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)

Hi! > IPE is a Linux Security Module which allows for a configurable > policy to enforce integrity requirements on the whole system. It > attempts to solve the issue of Code Integrity: that any code being > executed (or files being read), are identical to the version that > was built by a trusted

Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)

On Sun 2020-08-02 10:03:00, Sasha Levin wrote: > On Sun, Aug 02, 2020 at 01:55:45PM +0200, Pavel Machek wrote: > >Hi! > > > >>IPE is a Linux Security Module which allows for a configurable > >>policy to enforce integrity requirements on the whole system. It > &

Re: [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)

On Sun 2020-08-02 10:03:00, Sasha Levin wrote: > On Sun, Aug 02, 2020 at 01:55:45PM +0200, Pavel Machek wrote: > >Hi! > > > >>IPE is a Linux Security Module which allows for a configurable > >>policy to enforce integrity requirements on the whole system. It > &

Re: [PATCH v4 1/4] power: supply: core: add quick charge type property

On Sun 2020-08-02 14:37:42, Greg KH wrote: > On Sun, Aug 02, 2020 at 02:00:15PM +0200, Pavel Machek wrote: > > On Mon 2020-07-20 13:47:14, Qiwu Huang wrote: > > > From: Qiwu Huang > > > > > > Reports the kind of quick charge type based on > > > dif

Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)

Hi! > IPE is a Linux Security Module which allows for a configurable > policy to enforce integrity requirements on the whole system. It > attempts to solve the issue of Code Integrity: that any code being > executed (or files being read), are identical to the version that > was built by a trusted

Re: [PATCH v4 0/2] Syscall User Redirection

Hi! > This is v4 of Syscall User Redirection. The implementation itself is > not modified from v3, it only applies the latest round of reviews to the > selftests. > > __NR_syscalls is not really exported in header files other than > asm-generic for every architecture, so it felt safer to

Re: [PATCH] MAINTAINERS: mark usbvision as obsolete

On Sun 2020-07-19 23:16:08, B K Karthik wrote: > mark staging/media/usbvision as obsolete so > checkpatch tells people not to send patches. Umm... that's not right. If we do not want people to fix it, it should not be in stagging -- it should be dropped.

Re: [PATCH v4 1/4] power: supply: core: add quick charge type property

On Mon 2020-07-20 13:47:14, Qiwu Huang wrote: > From: Qiwu Huang > > Reports the kind of quick charge type based on > different adapter power. > > Signed-off-by: Qiwu Huang > --- > Documentation/ABI/testing/sysfs-class-power | 21 + >

Re: [PATCH 0/6] Add TI PRUSS platform driver

On Sun 2020-08-02 13:53:30, Pavel Machek wrote: > Hi! > > > A typical usage scenario would be to load the application firmware into one > > or > > more of the PRU cores, initialize one or more of the peripherals and > > perform I/O > > through shared RAM fro

Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor

Hi! > > This is quite clever, but now I???m wondering just how much kernel help > > is really needed. In your series, the trampoline is an non-executable > > page. I can think of at least two alternative approaches, and I'd > > like to know the pros and cons. > > > > 1. Entirely userspace: a

Re: [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)

Hi! > IPE is a Linux Security Module which allows for a configurable > policy to enforce integrity requirements on the whole system. It > attempts to solve the issue of Code Integrity: that any code being > executed (or files being read), are identical to the version that > was built by a trusted

Re: [PATCH v18 3/3] Input: new da7280 haptic driver

Hi! > > +static DEVICE_ATTR_RW(ps_seq_id); > > +static DEVICE_ATTR_RW(ps_seq_loop); > > +static DEVICE_ATTR_RW(gpi_seq_id0); > > +static DEVICE_ATTR_RW(gpi_seq_id1); > > +static DEVICE_ATTR_RW(gpi_seq_id2); > > +static DEVICE_ATTR_WO(patterns); > > Should this be a binary attribute instead of

Re: [PATCH 0/6] Add TI PRUSS platform driver

Hi! > A typical usage scenario would be to load the application firmware into one or > more of the PRU cores, initialize one or more of the peripherals and perform > I/O > through shared RAM from either a kernel driver or directly from userspace. > > This series contains the PRUSS platform

Re: Should perf version match kernel version?

Hi! > > >We strive to have it all compatible, older perf should work on newer > > >kernel and newer perf should work on older kernel. > > > > > >How well it's all tested is another. > > > > > >Personally I often use a very old perf. > > > > Yeah, never was a requirement, if you find some problem

<    5   6   7   8   9   10   11   12   13   14   >