Re: [PATCH 4.19 66/78] fbcon: remove soft scrollback code

Hi! > > > From: Linus Torvalds > > > > > > commit 50145474f6ef4a9c19205b173da6264a644c7489 upstream. > > > > > > This (and the VGA soft scrollback) turns out to have various nasty small > > > special cases that nobody really is willing to fight. The soft > > > scrollback code was really

Re: [PATCH 4.19 00/78] 4.19.146-rc1 review

Hi! > This is the start of the stable review cycle for the 4.19.146 release. > There are 78 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 Thu, 17 Sep 2020 14:06:12

Re: [PATCH 4.19 1/8] ALSA; firewire-tascam: exclude Tascam FE-8 from detection

Hi! > > Unfortunately it is too late to fix that now. > > > > This one was scheduled to be released at "Responses should be made by > > Sun, 13 Sep 2020 12:54:13 +.". But it was released day earlier: > > "Date: Sat, 12 Sep 2020 14:42:49 +0200". > > > > Could you actually follow published

Re: [PATCH 4.19 66/78] fbcon: remove soft scrollback code

Hi! > From: Linus Torvalds > > commit 50145474f6ef4a9c19205b173da6264a644c7489 upstream. > > This (and the VGA soft scrollback) turns out to have various nasty small > special cases that nobody really is willing to fight. The soft > scrollback code was really useful a few decades ago when you

Re: [PATCH 4.19 28/78] nvme: have nvme_wait_freeze_timeout return if it timed out

Hi! > [ Upstream commit 7cf0d7c0f3c3b0203aaf81c1bc884924d8fdb9bd ] > > Users can detect if the wait has completed or not and take appropriate > actions based on this information (e.g. weather to continue > initialization or rather fail and schedule another initialization > attempt). This does

Re: [PATCH 4.19 09/78] iio: adc: mcp3422: fix locking on error path

Hi! > [ Upstream commit a139ffa40f0c24b753838b8ef3dcf6ad10eb7854 ] > > Reading from the chip should be unlocked on error path else the lock > could never being released. > > Fixes: 07914c84ba30 ("iio: adc: Add driver for Microchip MCP3422/3/4 high > resolution ADC") > Fixes: 3f1093d83d71

[PATCH 1/3] droid 4: add special handling required for voice calls and SIM

Droid 4 modem is "special" (aka broken) so it seems to need a bit of error handling. --- drivers/atmodem/sim.c | 1 + drivers/atmodem/vendor.h| 1 + drivers/atmodem/voicecall.c | 4 3 files changed, 6 insertions(+) diff --git a/drivers/atmodem/sim.c b/drivers/atmodem/sim.c index

[PATCH 2/3] droid 4: special handling for SMSes

Droid 4 modem is "special" (aka broken) so and getting incoming SMSes to work is quite tricky. This should get it right. --- drivers/atmodem/sms.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/atmodem/sms.c b/drivers/atmodem/sms.c index

[PATCH 3/3] droid 4: Add probing.

. + * Copyright (C) 2009 Collabora Ltd. All rights reserved. + * Copyright (C) 2020 Pavel Machek. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software

Re: [PATCH v3] Support weird modem in Motorola Droid 4

Hi! > On 9/10/20 8:05 AM, Pavel Machek wrote: > > This is basic support for modem in Droid 4, accessed over > > ttyUSB4. That interface is unfortunately quite broken, so we need to > > force very specific SMS mode. > > > > Can you separate this into at least

Re: [PATCH v3] Support weird modem in Motorola Droid 4

Hi! > > This is basic support for modem in Droid 4, accessed over > > ttyUSB4. That interface is unfortunately quite broken, so we need to > > force very specific SMS mode. > > > > Can you separate this into at least a couple of patches per our patch > submission guidelines? See HACKING,

Re: Yet another ethernet PHY LED control proposal

Hi! > I have been thinking about another way to implement ABI for HW control > of ethernet PHY connected LEDs. > > This proposal is inspired by the fact that for some time there is a > movement in the kernel to do transparent HW offloading of things (DSA > is an example of that). And it is good

Re: [PATCH 4.19 1/8] ALSA; firewire-tascam: exclude Tascam FE-8 from detection

Hi! > From: Takashi Sakamoto > > Tascam FE-8 is known to support communication by asynchronous transaction > only. The support can be implemented in userspace application and > snd-firewire-ctl-services project has the support. However, ALSA > firewire-tascam driver is bound to the model. This

Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje

Ahoj! > Na https://geoportal.kraj-jihocesky.gov.cz/gs/zastavky-verejne-dopravy/ >  je > už delší dobu pod licencí CC0 k dispozici seznam všech autobusových > a vlakových zastávek Jihočeského kraje, tj. licence zde by měla být >

Re: [PATCH v3 1/2] leds: mt6360: Add LED driver for MT6360

Hi! > >+{ > >+struct mt6360_led *led = container_of(lcdev, struct mt6360_led, > >flash.led_cdev); > >+struct mt6360_priv *priv = led->priv; > >+u32 enable_mask = MT6360_TORCHEN_MASK | MT6360_FLCSEN_MASK(led->led_no); > >+u32 val = (level) ? MT6360_FLCSEN_MASK(led->led_no) : 0; >

Re: [PATCH net-next + leds v2 6/7] net: phy: marvell: add support for LEDs controlled by Marvell PHYs

On Wed 2020-09-09 18:25:51, Marek Behún wrote: > This patch adds support for controlling the LEDs connected to several > families of Marvell PHYs via the PHY HW LED trigger API. These families > are: 88E1112, 88E1121R, 88E1240, 88E1340S, 88E1510 and 88E1545. More can > be added. > > This patch

Re: [PATCH net-next + leds v2 6/7] net: phy: marvell: add support for LEDs controlled by Marvell PHYs

Hi! > > We already have different support for blinking in LED subsystem. Lets use > > that. > > You are assuming we have full software control of the LED, we can turn > it on and off. That is not always the case. But there is sometimes a > mode which the hardware blinks the LED. Please see

Re: [PATCH v3 1/2] leds: mt6360: Add LED driver for MT6360

Hi! > > > 1. set FLED1 brightness > > > # echo 1 > /sys/class/leds/white:flash1/flash_brightness > > > 2. enable FLED1 strobe > > > # echo 1 > /sys/class/leds/white:flash1/flash_strobe > > > 3 . turn off FLED1 strobe (just used to gaurantee the strobe mode > > > flash leds must be turned off) > >

Re: [PATCH net-next + leds v2 6/7] net: phy: marvell: add support for LEDs controlled by Marvell PHYs

Hi! > Okay, so the netdev trigger offers modes `link`, `rx`, `tx`. > You can enable/disable either of these (via separate sysfs files). `rx` > and `tx` blink the LED, `link` turns the LED on if the interface is > linked. I wonder if people really need separate rx and tx, but... this sounds

Re: [PATCH net-next + leds v2 6/7] net: phy: marvell: add support for LEDs controlled by Marvell PHYs

On Thu 2020-09-10 15:15:41, Andrew Lunn wrote: > On Thu, Sep 10, 2020 at 02:23:41PM +0200, Pavel Machek wrote: > > On Wed 2020-09-09 18:25:51, Marek Behún wrote: > > > This patch adds support for controlling the LEDs connected to several > > > families of Marvell PHYs

Re: Supporting modem in Droid 4

Hi! > > Two months I sent patch for Droid 4 support in ofono: > > > > https://www.mail-archive.com/ofono@ofono.org/msg19590.html > > > > I got no replies. Could I get some comments? Should I try to resend? > > Please resend. Looks like they got buried in a thread and I must have missed >

[PATCH v3] Support weird modem in Motorola Droid 4

file mode 100644 index ..4e048dbb --- /dev/null +++ b/plugins/droid.c @@ -0,0 +1,226 @@ +/* + * + * oFono - Open Source Telephony + * + * Copyright (C) 2008-2011 Intel Corporation. All rights reserved. + * Copyright (C) 2009 Collabora Ltd. All rights reserved. + * Copyright (C) 2020 P

Re: [PATCH v3 1/2] leds: mt6360: Add LED driver for MT6360

Hi! > > > +{ > > > + struct mt6360_led *led = container_of(lcdev, struct mt6360_led, > > > flash.led_cdev); > > > + struct mt6360_priv *priv = led->priv; > > > + u32 enable_mask = MT6360_TORCHEN_MASK | > > > MT6360_FLCSEN_MASK(led->led_no); > > > + u32 val = (level) ?

Re: [PATCH v3 1/2] leds: mt6360: Add LED driver for MT6360

On Thu 2020-09-10 14:34:54, Andy Shevchenko wrote: > On Thu, Sep 10, 2020 at 11:18 AM Pavel Machek wrote: > > ... > > > > > > +enum { > > > > > + MT6360_LED_ISNK1 = 0, > > > > > + MT6360_LED_ISNK2, > > >

Re: [PATCH net-next + mvebu v2 7/7] arm64: dts: armada-3720-turris-mox: add nodes for ethernet PHY LEDs

Hi! > Add nodes for the green and yellow LEDs that are connected to the > ethernet PHY chip on Turris MOX A. > > Signed-off-by: Marek Behún > --- > .../dts/marvell/armada-3720-turris-mox.dts| 23 +++ > 1 file changed, 23 insertions(+) > > diff --git

Re: [PATCH net-next + leds v2 5/7] net: phy: add support for LEDs controlled by ethernet PHY chips

trolled_led_ops and set the member led_ops in struct > phy_driver to point to that structure. > > Signed-off-by: Marek Behún Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html s

Re: [PATCH net-next + leds v2 3/7] net: phy: add simple incrementing phyindex member to phy_device struct

gt; */ > int phy_device_register(struct phy_device *phydev) > { > + static atomic_t phyindex; > int err; > > err = mdiobus_register_device(>mdio); I'd put the static out of the function... for greater visibility. Otherwise: Reviewed-by: Pavel Machek -- (en

Re: [PATCH v3 1/2] leds: mt6360: Add LED driver for MT6360

Hi! > > > +enum { > > > + MT6360_LED_ISNK1 = 0, > > > + MT6360_LED_ISNK2, > > > + MT6360_LED_ISNK3, > > > + MT6360_LED_ISNK4, > > > + MT6360_LED_FLASH1, > > > + MT6360_LED_FLASH2, > > > > > + MT6360_MAX_LEDS, > > > > No comma for terminator entry. > > >

Re: [Tinkerphones] Mailing list about low levels of Linux on cellphones

> > I've created phone-de...@vger.kernel.org Thank you! Pavel ___ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community

Re: [PATCH net-next + leds v2 2/7] leds: add generic API for LEDs that can be controlled by hardware

On Thu 2020-09-10 00:15:26, Marek Behun wrote: > On Wed, 9 Sep 2020 23:40:09 +0200 > Pavel Machek wrote: > > > > > > > > > 80 columns :-) (and please fix that globally, at least at places where > > > > it is easy, like comments). > > > >

Re: Mailing list about low levels of Linux on cellphones

> > I've created phone-de...@vger.kernel.org Thank you! Pavel

Re: [PATCH net-next + leds v2 2/7] leds: add generic API for LEDs that can be controlled by hardware

Hi! > > > Many an ethernet PHY (and other chips) supports various HW control modes > > > for LEDs connected directly to them. > > > > I guess this should be > > > > "Many ethernet PHYs (and other chips) support various HW control modes > > for LEDs connected directly to them." > > > > I

Re: [PATCH v3 1/2] leds: pwm: Allow automatic labels for DT based devices

Hi! > >>> pwm_init_state(led_data->pwm, _data->pwmstate); > >>>- ret = devm_led_classdev_register(dev, _data->cdev); > >>>+ if (fwnode) { > >>>+ init_data.fwnode = fwnode; > >>>+ ret = devm_led_classdev_register_ext(dev, _data->cdev, > >>>+

Re: [PATCH net-next + leds v2 2/7] leds: add generic API for LEDs that can be controlled by hardware

Hi! > Many an ethernet PHY (and other chips) supports various HW control modes > for LEDs connected directly to them. I guess this should be "Many ethernet PHYs (and other chips) support various HW control modes for LEDs connected directly to them." > This API registers a new private LED

Supporting modem in Droid 4

Hi! Two months I sent patch for Droid 4 support in ofono: https://www.mail-archive.com/ofono@ofono.org/msg19590.html I got no replies. Could I get some comments? Should I try to resend? Best regards, Pavel -- (english)

Re: [PATCH 4/7] drivers: leds: Add the iEi WT61P803 PUZZLE LED driver

Hi! > > Add support for the iEi WT61P803 PUZZLE LED driver. > > Currently only the front panel power LED is supported. > > > > This driver depends on the iEi WT61P803 PUZZLE MFD driver. > > Can we make it OF independent? > See below how to achieve this. Is there reason to believe this will be

Re: [PATCH 1/1] USB: PHY: JZ4770: Fix uninitialized value written to HW register

Hi! > >>> -reg = USBPCR_IDPULLUP_OTG | USBPCR_VBUSVLDEXT > >>> | USBPCR_TXPREEMPHTUNE | > >>> +return USBPCR_IDPULLUP_OTG | USBPCR_VBUSVLDEXT | > >>> USBPCR_TXPREEMPHTUNE | > >>> USBPCR_COMMONONN | USBPCR_POR; > >>> -writel(reg, priv->base +

Re: [PATCH v2 0/2] leds: pwm: Make automatic labels work

Hi! > > > Besides: those suggestions are obviously valid for new bindings. What > > > about old bindings (.txt), which had no explicit SPDX tag or license note > > > before? What license would apply there? Is the .yaml file technically > > > new, when it was mostly just converted from .txt? > >

Re: [PATCH v9 11/13] arm64: dts: freescale: sl28: enable LED support

, thus while it is possible to enable both at the same > time it is hard to tell the difference between "yellow only" and "yellow > and green". > > Signed-off-by: Michael Walle Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky

Re: [PATCH 1/4] leds: lm3692x: Simplify with dev_err_probe()

On Wed 2020-08-26 16:50:10, Krzysztof Kozlowski wrote: > Common pattern of handling deferred probe can be simplified with > dev_err_probe(). Less code and also it prints the error value. > > Signed-off-by: Krzysztof Kozlowski Thanks, applied.

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

On Tue 2020-08-25 16:22:05, Grant Feng wrote: > generate a 5ms low pulse on shutdown pin when startup, then the chip > becomes more stable in the complex EM environment. Thanks, I applied the series. Best regards, Pavel

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

On Tue 2020-09-01 13:57:55, Harald Arnesen wrote: > Still (rc3) doesn't work without the three reverts. > > I'm not sure how to proceed, I cannot capture any oops, and see nothing > obvious in any logs. I believe this is the place when you ask Linus for reverts... Best regards,

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

On Tue 2020-09-01 13:57:55, Harald Arnesen wrote: > Still (rc3) doesn't work without the three reverts. > > I'm not sure how to proceed, I cannot capture any oops, and see nothing > obvious in any logs. I believe this is the place when you ask Linus for reverts... Best regards,

Re: [PATCH] dt: bindings: lp55xx: Updte yaml examples with new color ID

On Wed 2020-08-12 14:32:48, Dan Murphy wrote: > Update the binding examples for the color ID to LED_COLOR_ID_RGB > > Signed-off-by: Dan Murphy Thanks, applied. BR, Pavel -- (english)

Re: [PATCH v3 1/2] leds: pwm: Allow automatic labels for DT based devices

Hi! > pwm_init_state(led_data->pwm, _data->pwmstate); > > - ret = devm_led_classdev_register(dev, _data->cdev); > + if (fwnode) { > + init_data.fwnode = fwnode; > + ret = devm_led_classdev_register_ext(dev, _data->cdev, > +

Re: [PATCH v2 0/2] leds: pwm: Make automatic labels work

Hi! > > > for leds-gpio you can use the properties 'function' and 'color' in the > > > devicetree node and omit 'label', the label is constructed > > > automatically. This is a common feature supposed to be working for all > > > LED drivers. However it did not yet work for the 'leds-pwm'

Re: [PATCH] media: pci: ttpci: av7110: avoid compiler optimization of reading data[0] in debiirq()

: 6499a0db9b0f ("media: pci: ttpci: av7110: fix possible buffer > > overflow caused by bad DMA value in debiirq()") > > Reported-by: Pavel Machek > > Pavel reported that your patch was garbage, if you are trying to defend > against a malicious pci device. READ_ONCE(

Re: [PATCH 1/2] leds: mt6360: Add LED driver for MT6360

Hi! > > >@@ -271,6 +271,17 @@ config LEDS_MT6323 > > This option enables support for on-chip LED drivers found on > > Mediatek MT6323 PMIC. ...522 lines... > >+static int mt6360_init_isnk_properties(struct mt6360_led *led, struct > >led_init_data *init_data) > >+{ > >+struct

Mailing list about low levels of Linux on cellphones

Hi! It seems there is quite a lot of efforts porting kernel to various cellphones. Librem 5 and PinePhone have their own hardware, people around Maemo Leste work with Nokia N900 and Droid 4, there's group working with Sony cellphones, there are postmarketOS people and there are probably groups I

Re: [PATCH v3 1/2] leds: mt6360: Add LED driver for MT6360

Hi! > From: Gene Chen > > Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode, > and 4-channel RGB LED support Register/Flash/Breath Mode > > Signed-off-by: Gene Chen > --- > drivers/leds/Kconfig | 11 + > drivers/leds/Makefile | 1 + >

Re: [PATCH] x86: work around clang IAS bug referencing __force_order

On Sat 2020-08-22 11:51:56, Sedat Dilek wrote: > On Sat, Aug 22, 2020 at 11:23 AM Sedat Dilek wrote: > > > > On Sat, Aug 22, 2020 at 10:42 AM Segher Boessenkool > > wrote: > > > > > > Hi Arvind, > > > > > > On Fri, Aug 21, 2020 at 11:55:52PM -0400, Arvind Sankar wrote: > > > > Cc Segher. > > > >

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

I915_MAP_FORCE_WC); > + map = i915_gem_object_pin_map(pool->obj, I915_MAP_FORCE_WB); > > on top of the previous patch. Faultinjection didn't turn up anything in > eb_relocate_vma, so we need to dig deeper. With this on top of other patches, it works. Tested-by: Pavel Machek Bes

Re: [RFC PATCH v2 0/6] SCHED_DEADLINE server infrastructure

Hi! > This is RFC v2 of Peter's SCHED_DEADLINE server infrastructure > implementation [1]. > > SCHED_DEADLINE servers can help fixing starvation issues of low priority > tasks (e.g., > SCHED_OTHER) when higher priority tasks monopolize CPU cycles. Today we have > RT > Throttling; DEADLINE

Re: [PATCH v3 2/2] dt-bindings: leds: Add bindings for MT6360 LED

Hi! > From: Gene Chen > > Add bindings document for LED support on MT6360 PMIC > > Signed-off-by: Gene Chen Put this first in the series. Acked-by: Pavel Machek Pavel -- (english) http://www.

Re: [PATCH 4/7] drivers: leds: Add the iEi WT61P803 PUZZLE LED driver

Hi! > Add support for the iEi WT61P803 PUZZLE LED driver. > Currently only the front panel power LED is supported. > > This driver depends on the iEi WT61P803 PUZZLE MFD driver. > > Signed-off-by: Luka Kovacic > Cc: Luka Perkov > +#define CMD_CHAR(x) (char)(x) Come on... no need to hide

Re: [PATCH 4.19 00/88] 4.19.144-rc1 review

Hi! > This is the start of the stable review cycle for the 4.19.144 release. > There are 88 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 Thu, 10 Sep 2020 15:21:57

Re: [PATCH 4.19 41/88] net: ethernet: mlx4: Fix memory allocation in mlx4_buddy_init()

Hi! > On machines with much memory (> 2 TByte) and log_mtts_per_seg == 0, a > max_order of 31 will be passed to mlx_buddy_init(), which results in > s = BITS_TO_LONGS(1 << 31) becoming a negative value, leading to > kvmalloc_array() failure when it is converted to size_t. > > mlx4_core

Re: [PATCH 4.19 34/88] bnxt_en: fix HWRM error when querying VF temperature

Hi! > Firmware returns RESOURCE_ACCESS_DENIED for HWRM_TEMP_MONITORY_QUERY for > VFs. This produces unpleasing error messages in the log when temp1_input > is queried via the hwmon sysfs interface from a VF. > > The error is harmless and expected, so silence it and return unknown as > the value.

Re: [PATCH 4.19 40/88] perf tools: Correct SNOOPX field offset

Hi! > From: Al Grant > > [ Upstream commit 39c0a53b114d0317e5c4e76b631f41d133af5cb0 ] > > perf_event.h has macros that define the field offsets in the data_src > bitmask in perf records. The SNOOPX and REMOTE offsets were both 37. > > These are distinct fields, and the bitfield layout in

Re: [PATCHv3 0/3] Lost key-up interrupt handling for omap4-keypad

Hi! > This series updates omap4-keypad to disable unused long interrupts, and > implements the missing parts for the lost key-up interrupt quirk as > described in the silicon errata pdf. I do not see this in 5.9-rc4; problem is real, could we get this merged? Best regards,

Re: [PATCH 1/3] Input: atmel_mxt_ts - use runtime PM instead of custom functions

Hi! > Let's use standard runtime PM functions instead of custom start and stop > functions. This way we can implement runtime idle mode using runtime PM > autosuspend in the following patches. This is not in recent kernel. What needs to be done here? Best regards,

Re: [PATCH] /dev/zero: also implement ->read

On Sun 2020-09-06 20:35:38, Christophe Leroy wrote: > Hi, > > Le 06/09/2020 à 20:21, Pavel Machek a écrit : > >Hi! > > > >>>>Christophe reported a major speedup due to avoiding the iov_iter > >>>>overhead, so just add this trivial function.

Re: [PATCH] /dev/zero: also implement ->read

Hi! > > > Christophe reported a major speedup due to avoiding the iov_iter > > > overhead, so just add this trivial function. Note that /dev/zero > > > already implements both an iter and non-iter writes so this just > > > makes it more symmetric. > > > > > > Christophe Leroy > > >

Re: [PATCH 4.19 108/125] USB: yurex: Fix bad gfp argument

he driver in the process. > This patch changes the call to use GFP_ATOMIC instead of GFP_KERNEL. Fixing it properly should be as simple as moving prepare_to_wait down, no? Signed-off-by: Pavel Machek (CIP) diff --git a/drivers/usb/misc/yurex.c b/drivers/usb/misc/yurex.c index 785080f79073..

Re: [PATCH 4.19 053/125] media: gpio-ir-tx: improve precision of transmitted signal due to scheduling

Hi! > > [ Upstream commit ea8912b788f8144e7d32ee61e5ccba45424bef83 ] > > usleep_range() may take longer than the max argument due to scheduling, > especially under load. This is causing random errors in the transmitted > IR. Remove the usleep_range() in favour of busy-looping with udelay(). > >

Re: [PATCH 4.4 00/61] 4.4.235-rc2 review

Hi! > This is the start of the stable review cycle for the 4.4.235 release. > There are 61 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, 04 Sep 2020 07:47:57

Re: [PATCH 4.19 000/125] 4.19.143-rc1 review

Hi! > This is the start of the stable review cycle for the 4.19.143 release. > There are 125 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 Thu, 03 Sep 2020 15:09:01

Re: [PATCH 4.19 085/125] fbcon: prevent user font height or width change from causing potential out-of-bounds access

On Tue 2020-09-01 17:10:40, Greg Kroah-Hartman wrote: > From: George Kennedy > > commit 39b3cffb8cf3111738ea993e2757ab382253d86a upstream. > > Add a check to fbcon_resize() to ensure that a possible change to user font > height or user font width will not allow a font data out-of-bounds access.

Re: [PATCH 4.19 016/125] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()

On Tue 2020-09-01 18:35:23, Greg Kroah-Hartman wrote: > On Tue, Sep 01, 2020 at 05:25:12PM +0100, Sean Young wrote: > > Greg, > > > > On Tue, Sep 01, 2020 at 05:09:31PM +0200, Greg Kroah-Hartman wrote: > > > From: Jia-Ju Bai > > > > > > [ Upstream commit 6499a0db9b0f1e903d52f8244eacc1d4be00eea2

Re: [PATCH 4.19 124/125] HID: hiddev: Fix slab-out-of-bounds write in hiddev_ioctl_usage()

Hi! > commit 25a097f5204675550afb879ee18238ca917cba7a upstream. > > `uref->usage_index` is not always being properly checked, causing > hiddev_ioctl_usage() to go out of bounds under some cases. Fix it. Well, the code is quite confusig, but: a) does HIDIOCGCOLLECTIONINDEX need same checking?

Re: [PATCH 4.19 047/125] media: davinci: vpif_capture: fix potential double free

Hi! > [ Upstream commit 602649eadaa0c977e362e641f51ec306bc1d365d ] > > In case of errors vpif_probe_complete() releases memory for vpif_obj.sd > and unregisters the V4L2 device. But then this is done again by > vpif_probe() itself. The patch removes the cleaning from > vpif_probe_complete(). >

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

Hi! > > > The phydev name is not particularly nice: > > > > > > !mdio-mux!mdio@1!switch@0!mdio:00 ... > > > 400d.ethernet-1:00 > > > 400d.ethernet-1:01 > > > fixed-0:00 > > > > Not nice, I see. In particular, it contains ":"... which would be a > > problem. > > > > > The interface name

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

Hi! > > > And no, I don't want phydev name there. > > > > Ummm. Can we get little more explanation on that? I fear that LED > > device renaming will be tricky and phydev would work around that > > nicely. > > Hi Pavel > > The phydev name is not particularly nice: > >

Re: [PATCH AUTOSEL 4.19 34/38] btrfs: file: reserve qgroup space after the hole punch range is locked

Hi! > [ Upstream commit a7f8b1c2ac21bf081b41264c9cfd6260dffa6246 ] > > The incoming qgroup reserved space timing will move the data reservation > to ordered extent completely. > > However in btrfs_punch_hole_lock_range() will call > btrfs_invalidate_page(), which will clear QGROUP_RESERVED bit

Re: [PATCH AUTOSEL 4.19 08/38] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()

Hi! > The value av7110->debi_virt is stored in DMA memory, and it is assigned > to data, and thus data[0] can be modified at any time by malicious > hardware. In this case, "if (data[0] < 2)" can be passed, but then > data[0] can be changed into a large number, which may cause buffer > overflow

Re: [PATCH 1/2] Input: i8042 - Prevent intermixing i8042 commands

On Thu 2020-08-27 13:52:22, Raul E Rangel wrote: > The i8042_mutex must be held by writers of the AUX and KBD ports, as > well as users of i8042_command. There were a lot of users of > i8042_command that were not calling i8042_lock_chip/i8042_unlock_chip. > This resulted in i8042_commands being

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

Hi! > >> It's a Thinkpad T520. > > > > Oh, so this is a 64-bit machine? Yeah, that patch to flush vmalloc > > ranges won't make any difference on x86-64. > > > > Or are you for some reason running a 32-bit kernel on that thing? Have > > you tried building a 64-bit one (user-space can be 32-bit,

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

Hi! > >> It's a Thinkpad T520. > > > > Oh, so this is a 64-bit machine? Yeah, that patch to flush vmalloc > > ranges won't make any difference on x86-64. > > > > Or are you for some reason running a 32-bit kernel on that thing? Have > > you tried building a 64-bit one (user-space can be 32-bit,

Re: [PATCH 4.4 00/33] 4.4.234-rc1 review

Hi! > Responses should be made by Wed, 26 Aug 2020 08:23:34 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.234-rc1.gz > or in the git tree and

Re: [PATCH 4.19 00/71] 4.19.142-rc1 review

Hi! > This is the start of the stable review cycle for the 4.19.142 release. > There are 71 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, 26 Aug 2020 08:23:34

Re: [PATCH 4.19 65/71] powerpc/pseries: Do not initiate shutdown when system is running on UPS

Hi! > We have a user space tool (rtas_errd) on LPAR to monitor for > EPOW_SHUTDOWN_ON_UPS. Once it gets an event it initiates shutdown > after predefined time. It also starts monitoring for any new EPOW Yeah, so there's userspace tool, and currently systems _with_ that tool work poorly with UPS.

Re: [PATCH 4.19 22/71] scsi: target: tcmu: Fix crash in tcmu_flush_dcache_range on ARM

Hi! > From: Bodo Stroesser > > [ Upstream commit 3145550a7f8b08356c8ff29feaa6c56aca12901d ] > > This patch fixes the following crash (see > https://bugzilla.kernel.org/show_bug.cgi?id=208045) > > Process iscsi_trx (pid: 7496, stack limit = 0x10dd111a) > CPU: 0 PID: 7496 Comm:

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

Hi! > > > > If we ported the full driver, we would break the existing driver > > > > structure because we would introduce more Qualcomm code. I think > > > > that's an unreasonable change. > > > > > > That doesn't make much sense. You have a working driver for these apis, > > > just submit it

Re: [PATCH 4.19 09/71] btrfs: sysfs: use NOFS for device creation

Hi! > From: Josef Bacik > > Dave hit this splat during testing btrfs/078: ... > CC: sta...@vger.kernel.org # 4.14+ This commit is in mainline, as a47bd78d0c44621efb98b525d04d60dc4d1a79b0, but is not marked as such. Best regards,

Re: [PATCH v1 3/6] leds: Add driver for Acer Iconia Tab A500

On Sun 2020-08-23 17:08:43, Dmitry Osipenko wrote: > Acer Iconia Tab A500 is an Android tablet device which has two LEDs > embedded into the Power Button. Orange LED indicates "battery charging" > status and white LED indicates "wake-up/charge-done" status. The new LED > driver provides control

Re: [PATCH v1 3/6] leds: Add driver for Acer Iconia Tab A500

Hi! > Acer Iconia Tab A500 is an Android tablet device which has two LEDs > embedded into the Power Button. Orange LED indicates "battery charging" > status and white LED indicates "wake-up/charge-done" status. The new LED > driver provides control over both LEDs to userspace. > @@ -0,0 +1,121

Re: Camera LED on Librem 5 was Re: [PATCH] backlight: add led-backlight driver

Hi! > > > > This patch adds a led-backlight driver (led_bl), which is similar to > > > > pwm_bl except the driver uses a LED class driver to adjust the > > > > brightness in the HW. Multiple LEDs can be used for a single backlight. > > > > > > Tested-by: Guido Günther > > > > Thanks for

Re: [PATCH] thermal: ti-soc-thermal: Fix bogus thermal shutdowns for omap4430

Hi! > We can sometimes get bogus thermal shutdowns on omap4430 at least with > droid4 running idle with a battery charger connected: > > thermal thermal_zone0: critical temperature reached (143 C), shutting down > > Dumping out the register values shows we can occasionally get a 0x7f value >

Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()

> > Tested-by: Chris Wilson #x86-32 > Cc: # v5.8+ > Signed-off-by: Joerg Roedel This seems to solve screen blinking problems on Thinkpad X60. (It already survived few unison runs, which would usually kill it.). Tested-by: Pavel Machek

Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()

> > Tested-by: Chris Wilson #x86-32 > Cc: # v5.8+ > Signed-off-by: Joerg Roedel This seems to solve screen blinking problems on Thinkpad X60. (It already survived few unison runs, which would usually kill it.). Tested-by: Pavel Machek

Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()

Hi! > > > The __apply_to_page_range() function is also used to change and/or > > > allocate page-table pages in the vmalloc area of the address space. > > > Make sure these changes get synchronized to other page-tables in the > > > system by calling arch_sync_kernel_mappings() when necessary. > >

Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()

Hi! > > > The __apply_to_page_range() function is also used to change and/or > > > allocate page-table pages in the vmalloc area of the address space. > > > Make sure these changes get synchronized to other page-tables in the > > > system by calling arch_sync_kernel_mappings() when necessary. > >

Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()

Hi! > > > The __apply_to_page_range() function is also used to change and/or > > > allocate page-table pages in the vmalloc area of the address space. > > > Make sure these changes get synchronized to other page-tables in the > > > system by calling arch_sync_kernel_mappings() when necessary. > >

Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()

Hi! > > > The __apply_to_page_range() function is also used to change and/or > > > allocate page-table pages in the vmalloc area of the address space. > > > Make sure these changes get synchronized to other page-tables in the > > > system by calling arch_sync_kernel_mappings() when necessary. > >

Re: [PATCH 1/4] drivers: hv: dxgkrnl: core code

On Fri 2020-08-14 08:38:53, Sasha Levin wrote: > Add support for a Hyper-V based vGPU implementation that exposes the > DirectX API to Linux userspace. NAK. Kernel APIs should be documented. ... in tree and with suitable license. > +int dxgadapter_init(struct dxgadapter *adapter, struct

Re: [PATCH V2] ARM: dts: omap3: Add cpu trips and cooling map for omap34/36 families

On Mon 2020-08-17 08:39:31, Adam Ford wrote: > The OMAP3530, OMAP3630, and DM3730 all show thresholds of 90C and 105C > depending on commercial or industrial temperature ratings. > > This patch expands the thermal information to include the limits of 90 > and 105C for alert and critical. It sets

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

On Thu 2020-08-20 09:16:18, Linus Torvalds wrote: > On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek wrote: > > > > Yes, it seems they make things work. (Chris asked for new patch to be > > tested, so I am switching to his kernel, but it survived longer than > > it usually

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

On Thu 2020-08-20 09:16:18, Linus Torvalds wrote: > On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek wrote: > > > > Yes, it seems they make things work. (Chris asked for new patch to be > > tested, so I am switching to his kernel, but it survived longer than > > it usually

Re: [PATCH 4.19 00/92] 4.19.141-rc1 review

On Thu 2020-08-20 11:20:45, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.19.141 release. > There are 92 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 90/92] drm/radeon: fix fb_div check in ni_init_smc_spll_table()

Hi! > From: Denis Efremov > > commit f29aa08852e1953e461f2d47ab13c34e14bc08b3 upstream. > > clk_s is checked twice in a row in ni_init_smc_spll_table(). > fb_div should be checked instead. > > Fixes: 69e0b57a91ad ("drm/radeon/kms: add dpm support for cayman (v5)") > Cc: sta...@vger.kernel.org

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