On 3/4/21 2:12 PM, Rasmus Villemoes wrote:
> As Arnd and Guenther suggested, this adds support to the gpio_wdt
> driver for being a consumer of the clock driving the ripple
> counter. However, I don't think it should be merged as-is, see below.
>
> The first patch makes sense on its own, quick gre
On 3/4/21 2:12 PM, Rasmus Villemoes wrote:
> Add a managed wrapper for clk_prepare_enable().
>
> Signed-off-by: Rasmus Villemoes
That has been tried several times, including by yours truly,
and has always been rejected.
Just use devm_add_action_or_reset() like many other watchdog
drivers.
Guen
On 3/8/21 8:36 PM, Chris Packham wrote:
>
> On 9/03/21 11:10 am, Chris Packham wrote:
>>
>> On 8/03/21 5:59 pm, Guenter Roeck wrote:
>>> On 3/7/21 8:37 PM, Chris Packham wrote:
>>> [ ... ]
>>>>> That's from -ENXIO which is used in only one
On Mon, Mar 08, 2021 at 08:27:30PM +, Chris Packham wrote:
[ ... ]
> > Other than that, the only other real idea I have would be to monitor
> > the i2c bus.
> I am in the fortunate position of being able to go into the office and
> even happen to have the expensive scope at the moment. Now I j
any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 10 Mar 2021 12:27:05 +.
> Anything received after that time might be too late.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 435 pass: 435 fai
> let me know.
>
> Responses should be made by Wed, 10 Mar 2021 12:27:05 +.
> Anything received after that time might be too late.
>
Build results:
total: 156 pass: 156 fail: 0
Qemu test results:
total: 430 pass: 430 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Wed, 10 Mar 2021 12:27:05 +.
> Anything received after that time might be too late.
>
Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 429 pass: 429 fail: 0
Tested-by: Guenter Roeck
Guenter
On 3/8/21 3:21 AM, Flavio Suligoi wrote:
> This patch series add a new way to consider the module parameters for the
> watchdog module.
>
> Instead of adding this kind of module parameters independently to each
> driver, the best solution is declaring each feature only once,
> in the watchdog core
e: "ret".
> Return "0" on line 794
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
Reviewed-by: Guenter Roeck
> ---
>
> Change in v2:
> -remove the unnecessary return statement
>
> drivers/usb/typec/tcpm/tcpm.c | 6 +-
> 1 fi
a)
> 01b: SNK.Default (Above minimum vRd-Connect)
> 10b: SNK.Power1.5 (Above minimum vRd-Connect) Detects Rp 1.5A
> 11b: SNK.Power3.0 (Above minimum vRd-Connect) Detects Rp 3.0A
>
> Fixes: 74e656d6b0551 ("staging: typec: Type-C Port Controller
> Interface driver (tcpci)")
On 3/7/21 10:21 PM, Yang Li wrote:
> This function always return '0' and no callers use the return value.
> So make it a void function.
>
> This eliminates the following coccicheck warning:
> ./drivers/usb/typec/tcpm/tcpm.c:778:5-8: Unneeded variable: "ret".
> Return "0" on line 794
>
> Reported-
On Fri, Mar 05, 2021 at 05:54:10PM -0800, Linus Torvalds wrote:
> Ok, so this is a couple of days early, but rc1 had the nasty swapfile
> issue, so I'm just accelerating rc2 a bit.
>
> Outside of the swapfile IO offset fix, the only other thing that
> stands out is some io_uring thread handling re
On 3/7/21 8:37 PM, Chris Packham wrote:
[ ... ]
>> That's from -ENXIO which is used in only one place in i2c-mpc.c. I'll
>> enable some debug and see what we get.
>
> For the errant readings there was nothing abnormal reported by the driver.
>
> For the "No such device or address" I saw "mpc-i2c
On 3/7/21 2:52 PM, Chris Packham wrote:
> Hi,
>
> I've got a system using a PowerPC T2080 SoC and among other things has
> an LM81 hwmon chip.
>
> Under a high CPU load we see errant readings from the LM81 as well as
> actual failures. It's the errant readings that cause the most concern
> sin
On Fri, Mar 05, 2021 at 01:20:19PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.21 release.
> There are 102 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 kno
> let me know.
>
> Responses should be made by Sun, 07 Mar 2021 12:08:39 +.
> Anything received after that time might be too late.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 435 pass: 435 fail: 0
Tested-by: Guenter Roeck
Guenter
On Fri, Mar 05, 2021 at 01:21:02PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.103 release.
> There are 72 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
> let me know.
>
> Responses should be made by Sun, 07 Mar 2021 12:08:39 +.
> Anything received after that time might be too late.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 420 pass: 420 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Sun, 07 Mar 2021 12:08:39 +.
> Anything received after that time might be too late.
>
Forgot:
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Sun, 07 Mar 2021 12:08:39 +.
> Anything received after that time might be too late.
>
Forgot:
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Sun, 07 Mar 2021 12:08:39 +.
> Anything received after that time might be too late.
>
Build results:
total: 168 pass: 168 fail: 0
Qemu test results:
total: 406 pass: 406 fail: 0
Tested-by: Guenter Roeck
Guenter
On Fri, Mar 05, 2021 at 01:22:07PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.260 release.
> There are 41 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
On Fri, Mar 05, 2021 at 01:22:29PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.260 release.
> There are 30 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
On Fri, Mar 05, 2021 at 01:20:19PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.21 release.
> There are 102 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 kno
On Fri, Mar 05, 2021 at 01:21:02PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.103 release.
> There are 72 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
off-by: Rafael J. Wysocki
Acked-by: Guenter Roeck
> ---
> drivers/hwmon/acpi_power_meter.c | 29 +++--
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> Index: linux-pm/drivers/hwmon/acpi_power_meter.c
> =
inux/issues/115
> Acked-by: Guenter Roeck
> Signed-off-by: Gustavo A. R. Silva
> ---
I Acked those, thus assuming that they would be applied through some
other tree. If that is not the case, you'll need to let me know. The
resend only means to me that whatever tree was supposed to
On Thu, Mar 04, 2021 at 05:04:06PM -0600, Gustavo A. R. Silva wrote:
> Hi all,
>
> It's been more than 3 months; who can take this, please? :)
>
I am not in favor of cosmetic patches for old drivers,
and I am not going to provide tags for them anymore.
The driver should be converted to use the w
On Thu, Mar 04, 2021 at 12:23:15PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Mar 03, 2021 at 02:02:20PM +0530, Naresh Kamboju wrote:
> > On Wed, 3 Mar 2021 at 00:59, Greg Kroah-Hartman
> > wrote:
> > >
> > > This is the start of the stable review cycle for the 5.11.3 release.
> > > There are 773
On 3/3/21 8:12 AM, Naresh Kamboju wrote:
> On Wed, 3 Mar 2021 at 00:59, Greg Kroah-Hartman
> wrote:
>>
>> This is the start of the stable review cycle for the 5.10.20 release.
>> There are 657 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with t
> let me know.
>
> Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> Anything received after that time might be too late.
>
Build results:
total: 165 pass: 165 fail: 0
Qemu test results:
total: 329 pass: 329 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> Anything received after that time might be too late.
>
Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 429 pass: 429 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> Anything received after that time might be too late.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 420 pass: 420 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> Anything received after that time might be too late.
>
Build results:
total: 156 pass: 156 fail: 0
Qemu test results:
total: 430 pass: 430 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> Anything received after that time might be too late.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 435 pass: 435 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> Anything received after that time might be too late.
>
Build results:
total: 168 pass: 168 fail: 0
Qemu test results:
total: 406 pass: 406 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> Anything received after that time might be too late.
>
Build results:
total: 168 pass: 168 fail: 0
Qemu test results:
total: 383 pass: 383 fail: 0
Tested-by: Guenter Roeck
Guenter
On 3/3/21 6:05 AM, Greg Kroah-Hartman wrote:
[ ... ]
>> Anyway, that's the convention or consensus so far for entire SoC. If we
>> want to change it - sure, but let's make it for everyone, not for just
>> this one USB driver.
>
> Great, let's change it for everyone, I don't see a need for ARCH_*
>
unctionality of
> - *Nuvoton NCT6683D/NCT6687D eSIO
> + *Nuvoton NCT6683D/NCT6686D/NCT6687D eSIO
> *
> * Copyright (C) 2013 Guenter Roeck
> *
> @@ -12,6 +12,7 @@
> *
> * Chip#vin#fan#pwm#temp chip ID
> * nct6683d 21(1) 16
On 3/1/21 10:21 PM, Jiqi JQ9 Li wrote:
> Sorry, Please ignore this email as some typos.
>
No problem. I seem to be missing the typos, though.
Thanks,
Guenter
> -邮件原件-
> 发件人: Jiqi JQ9 Li
> 发送时间: 2021年3月2日 14:12
> 收件人: jdelv...@suse.com; li...@roeck-us.net; linux-hw...@vger.kernel.org;
On 3/2/21 4:38 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.20 release.
> There are 658 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 shoul
On 3/2/21 8:33 AM, Henning Schild wrote:
> From: Henning Schild
>
> This driver adds initial support for several devices from Siemens. It is
> based on a platform driver introduced in an earlier commit.
>
> Signed-off-by: Gerd Haeussler
> Signed-off-by: Henning Schild
> ---
> drivers/watchdog
On 3/1/21 8:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.259 release.
> There are 93 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
On Sun, Feb 28, 2021 at 04:29:34PM -0800, Linus Torvalds wrote:
> So two weeks have passed since the 5.11 release, and so - like
> clockwork - the merge window for 5.12 has closed, and 5.12-rc1 is out
> there for your perusal.
>
Basic test results look pretty good.
Build results:
total:
On 3/1/21 1:44 AM, Arnd Bergmann wrote:
> On Mon, Mar 1, 2021 at 9:34 AM Rasmus Villemoes
> wrote:
>> On 26/02/2021 20.53, Guenter Roeck wrote:
>>>
>>> Sorry, I am missing something. If the watchdog is controlled by the clock,
>>> it is a consumer of th
Hi Chris,
On 2/28/21 3:07 PM, Chris Packham wrote:
> The IR36021 is a dual‐loop digital multi‐phase buck controller.
>
> Signed-off-by: Chris Packham
> ---
> Documentation/hwmon/index.rst | 1 +
> Documentation/hwmon/ir36021.rst | 62 +
> drivers/hwmon/pmbus/Kconfig
On 2/26/21 8:35 AM, Rasmus Villemoes wrote:
> On 26/02/2021 15.35, Arnd Bergmann wrote:
>> On Fri, Feb 26, 2021 at 3:14 PM Rasmus Villemoes
>> wrote:
>>
>>>
>>> So I'm thinking that the proper way to handle this is to be able to
>>> represent that ripple counter as a clock consumer in DT and have
e change SRC_READY -> SNK_UNATTACHED [rev3 NONE_AMS]
> [ 2593.649962] Disable vbus discharge ret:0
> [ 2593.890322] Start toggling
> [ 2593.925663] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0,
>
> Fixes: f321a02caebd ("usb: typec: tcpm: Implement enab
> let me know.
>
> Responses should be made by Sat, 27 Feb 2021 09:25:06 +.
> Anything received after that time might be too late.
>
Build results:
total: 156 pass: 156 fail: 0
Qemu test results:
total: 430 pass: 430 fail: 0
Tested-by: Guenter Roeck
Guenter
let me know.
>
> Responses should be made by Sat, 27 Feb 2021 09:25:06 +.
> Anything received after that time might be too late.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 435 pass: 435 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Sat, 27 Feb 2021 09:25:06 +.
> Anything received after that time might be too late.
>
Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 429 pass: 429 fail: 0
Tested-by: Guenter Roeck
Guenter
On 2/25/21 2:18 AM, Quan Nguyen wrote:
> Adds device tree bindings for SMPro drivers found on the Mt.Jade hardware
> reference platform with Ampere's Altra Processor family.
>
> Signed-off-by: Quan Nguyen
> ---
> .../bindings/hwmon/ampere,ac01-hwmon.yaml | 27 ++
> .../bindings/mfd/amper
On 2/25/21 2:18 AM, Quan Nguyen wrote:
> Add documentation for the Ampere(R)'s Altra(R) SMpro hwmon driver.
>
> Signed-off-by: Thu Nguyen
> Signed-off-by: Quan Nguyen
> ---
> Documentation/hwmon/index.rst | 1 +
> Documentation/hwmon/smpro-hwmon.rst | 100
>
On 2/25/21 2:18 AM, Quan Nguyen wrote:
> This commit adds support for Ampere SMpro hwmon driver. This driver
> supports accessing various CPU sensors provided by the SMpro co-processor
> including temperature, power, voltages, and current.
>
> Signed-off-by: Quan Nguyen
> ---
> drivers/hwmon/Kco
On Wed, Feb 24, 2021 at 02:57:06PM -0800, Sami Tolvanen wrote:
> parisc uses -fpatchable-function-entry with dynamic ftrace, which means we
> don't need recordmcount. Select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
> to tell that to the build system.
>
> Reported-by: Gu
TRY
> > to tell that to the build system.
> >
> > Reported-by: Guenter Roeck
> > Fixes: 3b15cdc15956 ("tracing: move function tracer options to Kconfig")
> > Signed-off-by: Sami Tolvanen
>
> I've got parisc building now, and can confirm:
>
On Wed, Feb 24, 2021 at 12:54:15PM -0800, Sami Tolvanen wrote:
> On Wed, Feb 24, 2021 at 12:38 PM Kees Cook wrote:
> >
> > On Wed, Feb 24, 2021 at 12:17:23PM -0800, Guenter Roeck wrote:
> > > On Fri, Dec 11, 2020 at 10:46:18AM -0800, Sami Tolvanen wrote:
> > >
On Wed, Feb 24, 2021 at 12:38:54PM -0800, Kees Cook wrote:
> On Wed, Feb 24, 2021 at 12:17:23PM -0800, Guenter Roeck wrote:
> > On Fri, Dec 11, 2020 at 10:46:18AM -0800, Sami Tolvanen wrote:
> > > Move function tracer options to Kconfig to make it easier to add
> > >
On Fri, Dec 11, 2020 at 10:46:18AM -0800, Sami Tolvanen wrote:
> Move function tracer options to Kconfig to make it easier to add
> new methods for generating __mcount_loc, and to make the options
> available also when building kernel modules.
>
> Note that FTRACE_MCOUNT_USE_* options are updated
On 2/24/21 7:58 AM, Enrico Weigelt, metux IT consult wrote:
> On 24.02.21 15:08, Masahiro Yamada wrote:
>> I read the commit log of the following two:
>>
>> - bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on !UML")
>> - 334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390")
>>
>>
On Wed, Feb 24, 2021 at 04:00:14PM +0100, Alexandre Belloni wrote:
> Hi,
>
> On 24/02/2021 15:55:00+0100, Bruno Thomsen wrote:
> > You could be right about that, I don't think the watchdog feature should
> > be available for use if the alarm feature is enabled due to how CTRL2
> > register behaves
On Tue, Feb 23, 2021 at 07:03:47PM +0100, Heiko Carstens wrote:
> On Tue, Feb 23, 2021 at 09:41:40AM -0800, Guenter Roeck wrote:
> > > I tried to explain why we don't want to set COMPILE_TEST for s390
> > > anymore. It overrides architecture dependencies in Kconfig, an
On Tue, Feb 23, 2021 at 12:54:10PM +0100, Heiko Carstens wrote:
> On Mon, Feb 22, 2021 at 08:03:31AM -0800, Guenter Roeck wrote:
> > > Maybe, we can add something like CONFIG_SUPPRESS_NOISY_TESTS,
> > > which is set to y by all{yes,mod}config.
> > >
> > >
dency. While at it, rename the module to VIRTIO_PCI_LIB.
>
> Cc: Arnd Bergmann
> Cc: Anders Roxell
> Cc: Guenter Roeck
> Reported-by: Naresh Kamboju
> Fixes: 86b87c9d858b6 ("virtio-pci: introduce modern device module")
> Signed-off-by: Jason Wang
Acked-by: Guen
On 2/23/21 12:00 AM, Álvaro Fernández Rojas wrote:
> bcm7038_wdt can be used on bmips big endian (bcm63xx) devices too.
>
> Signed-off-by: Álvaro Fernández Rojas
With the assumption that the driver indeed does not need memory
barriers,
Reviewed-by: Guenter Roeck
Thanks,
Guenter
On Thu, Feb 18, 2021 at 01:35:36PM +0100, Bruno Thomsen wrote:
> Hi,
>
> After updating the kernel from 5.8.17 to 5.11 systemd (246.6) is
> unable to init watchdog in pcf2127 during boot. Kernel option
> CONFIG_WATCHDOG_OPEN_TIMEOUT=300 is working as expected.
> It's possible to get watchdog from
On Mon, Feb 22, 2021 at 10:48:09PM +0100, Álvaro Fernández Rojas wrote:
> Hi Guenter,
>
> > El 22 feb 2021, a las 22:24, Guenter Roeck escribió:
> >
> > On 2/22/21 12:03 PM, Álvaro Fernández Rojas wrote:
> >> bcm7038_wdt can be used on bmips (bcm63xx) devices t
On Mon, Feb 22, 2021 at 11:28:18AM +, Flavio Suligoi wrote:
[ ... ]
> > Having said that, I'd prefer to have a module parameter in the watchdog
> > core. We already have a number of similar module parameters in various
> > drivers, all named differently, and I'd rather not have more.
>
> Ok, I
let me know.
>
> Responses should be made by Wed, 24 Feb 2021 12:07:46 +.
> Anything received after that time might be too late.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 435 pass: 435 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Wed, 24 Feb 2021 12:07:46 +.
> Anything received after that time might be too late.
>
Build results:
total: 156 pass: 156 fail: 0
Qemu test results:
total: 430 pass: 430 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Wed, 24 Feb 2021 12:07:46 +.
> Anything received after that time might be too late.
>
Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 429 pass: 429 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Wed, 24 Feb 2021 12:07:46 +.
> Anything received after that time might be too late.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 420 pass: 420 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Wed, 24 Feb 2021 12:07:46 +.
> Anything received after that time might be too late.
>
Build results:
total: 168 pass: 168 fail: 0
Qemu test results:
total: 406 pass: 406 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Wed, 24 Feb 2021 12:07:46 +.
> Anything received after that time might be too late.
>
Build results:
total: 168 pass: 168 fail: 0
Qemu test results:
total: 383 pass: 383 fail: 0
Tested-by: Guenter Roeck
Guenter
> let me know.
>
> Responses should be made by Wed, 24 Feb 2021 12:07:46 +.
> Anything received after that time might be too late.
>
Build results:
total: 165 pass: 165 fail: 0
Qemu test results:
total: 329 pass: 329 fail: 0
Tested-by: Guenter Roeck
Guenter
On 2/22/21 12:03 PM, Álvaro Fernández Rojas wrote:
> bcm7038_wdt can be used on bmips (bcm63xx) devices too.
>
It might make sense to actually enable it for BCM63XX.
> Signed-off-by: Álvaro Fernández Rojas
> ---
> drivers/watchdog/bcm7038_wdt.c | 30 --
> 1 file chan
On Wed, Feb 03, 2021 at 09:26:43PM -0800, Atish Patra wrote:
> SBI v0.2 functions can return an error code from SBI implementation.
> We are already processing the SBI error code and coverts it to the Linux
> error code.
>
> Propagate to the error code to the caller as well. As of now, kvm is the
On 2/22/21 7:45 AM, Masahiro Yamada wrote:
> On Tue, Feb 23, 2021 at 12:18 AM Guenter Roeck wrote:
>>
>> On 2/22/21 4:05 AM, Heiko Carstens wrote:
>>> On Sun, Feb 21, 2021 at 02:56:50PM -0800, Guenter Roeck wrote:
>>>> Commit 334ef6ed06fa ("init/K
On 2/22/21 7:12 AM, Romain Perier wrote:
> The strlcpy() reads the entire source buffer first, it is dangerous if
> the source buffer lenght is unbounded or possibility non NULL-terminated.
length
> It can lead to linear read overflows, crashes, etc...
>
That won't happen here since both buffer
On 2/22/21 7:12 AM, Romain Perier wrote:
> The strlcpy() reads the entire source buffer first, it is dangerous if
> the source buffer lenght is unbounded or possibility non NULL-terminated.
length
> It can lead to linear read overflows, crashes, etc...
>
Not here. This description is misleading.
On 2/22/21 4:05 AM, Heiko Carstens wrote:
> On Sun, Feb 21, 2021 at 02:56:50PM -0800, Guenter Roeck wrote:
>> Commit 334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390")
>> disabled
>> COMPILE_TEST for s390. At the same time, "make allmodconfi
On Sat, Feb 13, 2021 at 08:10:41AM -0800, Lakshmi Ramasubramanian wrote:
> From: Rob Herring
>
> Both arm64 and powerpc do essentially the same FDT /chosen setup for
> kexec. The differences are either omissions that arm64 should have
> or additional properties that will be ignored. The setup c
eiko Carstens
Fixes: 334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390")
Signed-off-by: Guenter Roeck
---
scripts/gcc-plugins/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig
index ab9eb4cbe
On 2/19/21 1:04 AM, Badhri Jagan Sridharan wrote:
> When vbus auto discharge is enabled, TCPM can sometimes be faster than
> the TCPC i.e. TCPM can go ahead and move the port to unattached state
> (involves disabling vbus auto discharge) before TCPC could effectively
> discharge vbus to VSAFE0V. Th
the prompt and documenting ...
> dependency.
>
> Cc: Arnd Bergmann
> Cc: Anders Roxell
> Cc: Guenter Roeck
> Reported-by: Naresh Kamboju
> Fixes: 86b87c9d858b6 ("virtio-pci: introduce modern device module")
> Signed-off-by: Jason Wang
Reviewed-by: Gu
On 2/19/21 6:01 AM, Flavio Suligoi wrote:
> Hi Mika,
>
>>> const struct wdat_instruction *instr, u32 *value)
>>> {
>>> @@ -437,6 +443,8 @@ static int wdat_wdt_probe(struct platform_device
>> *pdev)
>>> }
>>>
>>> wdat_wdt_boot_status(wdat);
>>> + if (start_enabled)
>>> + w
On 2/17/21 7:28 AM, cristian.bir...@microchip.com wrote:
> Hi Heikki,
>
> On 2/16/21 11:12 AM, Heikki Krogerus wrote:
>>
>> Hi Cristian,
>>
>> On Mon, Feb 15, 2021 at 05:25:29PM +, cristian.bir...@microchip.com
>> wrote:
>>> My name is Cristian and I'm working on bringing up a USB Type-C Port
On Tue, Feb 16, 2021 at 06:39:55PM -0800, Saravana Kannan wrote:
> On Wed, Feb 10, 2021 at 1:21 PM Guenter Roeck wrote:
> >
> > On 2/10/21 12:52 PM, Saravana Kannan wrote:
> > > On Wed, Feb 10, 2021 at 7:10 AM Guenter Roeck wrote:
> > >>
> > >
> let me know.
>
> Responses should be made by Wed, 17 Feb 2021 15:27:00 +.
> Anything received after that time might be too late.
>
Build results:
total: 154 pass: 154 fail: 0
Qemu test results:
total: 428 pass: 428 fail: 0
Tested-by: Guenter Roeck
Guenter
let me know.
>
> Responses should be made by Wed, 17 Feb 2021 15:27:00 +.
> Anything received after that time might be too late.
>
Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 427 pass: 427 fail: 0
Tested-by: Guenter Roeck
Guenter
On 2/16/21 6:17 AM, Flavio Suligoi wrote:
> Fix the following typo:
>
> "recommeded" --> "recommended"
> "firmare"--> "firmware"
>
> Signed-off-by: Flavio Suligoi
Reviewed-by: Guenter Roeck
> ---
> drivers/watchd
-us.net/
> Fixes: 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts")
> Reported-by: Guenter Roeck
> Signed-off-by: Saravana Kannan
That does the trick, at least for my test cases.
Tested-by: Guenter Roeck
Guenter
> ---
> Greg/Rob,
>
> I bel
On Wed, Feb 10, 2021 at 12:40:54AM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> There is no reason to have this as a seperate function for a single caller.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Kees Cook
When building ARCH=um SUBARCH="x86_64" defconfig:
kernel/softir
On Fri, Feb 12, 2021 at 02:25:35PM -0800, Ben Widawsky wrote:
> From: Dan Williams
>
> Create the /sys/bus/cxl hierarchy to enumerate:
>
> * Memory Devices (per-endpoint control devices)
>
> * Memory Address Space Devices (platform address ranges with
> interleaving, performance, and persiste
On 2/15/21 7:23 AM, Michal Simek wrote:
[ ... ]
>
>> I think the problem is here:
>>
>> /* initialize device tree for usage in early_printk */
>> early_init_devtree(_fdt_start);
>>
>> That probably also explains why enabling earlycon doesn't help.
>
> Can you please elaborate more on it?
On Sun, Feb 14, 2021 at 02:45:13PM -0800, Linus Torvalds wrote:
> Nothing unexpected or particularly scary happened this week, so here
> we are - with 5.11 tagged and pushed out.
>
> In fact, it's a smaller-than-average set of commits from rc7 to final,
> which makes me happy. And I already have s
sktop CPUs support
Guenter Roeck (3):
hwmon: (abx500) Decomission abx500 driver
hwmon: (pmbus/max16601) Determine and use number of populated phases
hwmon: (pmbus/max16601) Add support for MAX16508
Jiapeng Zhong (2):
hwmon: (applesmc) Assign boolean values to a bool variable
On 2/14/21 1:12 PM, Saravana Kannan wrote:
[ ... ]
> Can you please give me the following details:
> * The DTS file for the board (not the SoC).
I don't have it, sorry. The devicetree file is generated by qemu.
Is there a way to extract it from a running system ?
> * A boot log with the logs enab
Hi,
On Thu, Jan 21, 2021 at 02:57:12PM -0800, Saravana Kannan wrote:
> This allows fw_devlink to create device links between consumers of an
> interrupt and the supplier of the interrupt.
>
> Cc: Marc Zyngier
> Cc: Kevin Hilman
> Cc: Greg Kroah-Hartman
> Reviewed-by: Rob Herring
> Reviewed-by
On 2/13/21 7:59 AM, Hans de Goede wrote:
> Hi,
>
> On 2/13/21 4:27 PM, Guenter Roeck wrote:
>> On 2/13/21 7:03 AM, Hans de Goede wrote:
>> [ ... ]
>>>
>>> I think something like this should work:
>>>
>>> static int devm_delayed_work_a
301 - 400 of 5857 matches
Mail list logo
