Port driver to the new SCMI Voltage interface based on protocol handles
and common devm_get_ops().
Signed-off-by: Cristian Marussi
---
drivers/regulator/scmi-regulator.c | 39 --
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git
Drain the command queue and place all commands on a completion list.
Perform command completion on that list outside the host/queue locks.
Further, move purged command compeletions outside the host_lock as well.
Signed-off-by: Tyrel Datwyler
Reviewed-by: Brian King
---
The drivers queuecommand routine is still wrapped to hold the host lock
for the duration of the call. This will become problematic when moving
to multiple queues due to the lock contention preventing asynchronous
submissions to mulitple queues. There is no real legatimate reason to
hold the host
The ibmvfc driver in its current form relies heavily on the host_lock. This
patchset introduces a genric queue with its own queue lock and sent/free event
list locks. This generic queue allows the driver to decouple the primary queue
and future subordinate queues from the host lock reducing lock
On Wed, 6 Jan 2021, Andrea Arcangeli wrote:
>
> I'd be surprised if the kernel can boot with BUG_ON() defined as "do
> {}while(0)" so I guess it doesn't make any difference.
I had been afraid of that too, when CONFIG_BUG is not set:
but I think it's actually "if (cond) do {} while (0)".
Now that all the protocol private variable data have been moved out of
struct scmi_handle, mark all of its references as const.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/common.h | 4 ++--
drivers/firmware/arm_scmi/driver.c | 12 ++--
include/linux/scmi_protocol.h
Remove all the events registration code used to ease the transition to the
new interface based on protocol handles..
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/base.c| 4 ++--
drivers/firmware/arm_scmi/notify.h | 6 +++---
drivers/firmware/arm_scmi/perf.c| 9
Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/sensors.c | 82 -
include/linux/scmi_protocol.h | 19 ---
2
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->clk_ops still
around to ease transition.
Remove handle->clock_priv now unused.
Signed-off-by:
Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/perf.c | 120 ---
include/linux/scmi_protocol.h| 27 ---
2 files
Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/power.c | 47 ---
include/linux/scmi_protocol.h | 11
2 files
Now that all protocols and drivers have been ported to the new interface
based on protocol handles and get/put operations, remove all the legacy
transient initialization code.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/bus.c| 26 +-
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->voltage_ops still
around to ease transition.
Remove handle->voltage_priv now unused.
Port driver to the new SCMI Sensor interface based on protocol handles
and common devm_get_ops().
Signed-off-by: Cristian Marussi
---
drivers/hwmon/scmi-hwmon.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/hwmon/scmi-hwmon.c
Remove unused core scmi_xfer wrappers now that we have migrated all
protocols to the new interface based on protocol handles.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/common.h | 15 -
drivers/firmware/arm_scmi/driver.c | 91 --
2 files
Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/clock.c | 67 ---
include/linux/scmi_protocol.h | 15 ---
2 files
Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/reset.c | 68 ---
include/linux/scmi_protocol.h | 11 -
2 files
Port driver to the new SCMI Power interface based on protocol handles
and common devm_get_ops().
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/scmi_pm_domain.c | 26 +-
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git
Port driver to the new SCMI Clock interface based on protocol handles
and common devm_get_ops().
Signed-off-by: Cristian Marussi
---
drivers/clk/clk-scmi.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/clk-scmi.c
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->perf_ops still
around to ease transition.
Remove handle->perf_priv now unused.
Signed-off-by:
Port Base protocol to new protocol handles based interface.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/base.c | 117 +++--
drivers/firmware/arm_scmi/common.h | 3 +-
drivers/firmware/arm_scmi/driver.c | 14 +++-
3 files changed, 71 insertions(+),
Port driver to the new SCMI Perf interface based on protocol handles
and common devm_get_ops().
Signed-off-by: Cristian Marussi
---
drivers/cpufreq/scmi-cpufreq.c | 37 ++
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git
Add new core SCMI xfer operations based on protocol handles to enable
protocols to builds and send their own protocol specific messages.
Keep old original scmi_xfer_ operations interface as wrappers around the
new interface in order to let coexist old and new interfaces to ease
protocol by
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->power_ops still
around to ease transition.
Remove handle->power_priv now unused.
Convert refactored events registration routines to use protocol handles.
In order to maintain bisectability and to allow protocols and drivers
to be later ported to the new protocol handle interface one by one,
introduce here also some transient code and typing that will be removed
later in order
Add an helper to grab, from a protocol handle, the handle common memory
area allocated to store SCMI version data which is exposed on sysfs.
Such helper will be needed by SCMI Base protocol initialization once it
will be moved to new protocol handles scheme.
Signed-off-by: Cristian Marussi
---
Expose to the SCMI drivers a new alternative devres managed notifications
API based on protocol handles.
All drivers still keep using the old API, no functional change.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/notify.c | 123 +
Add basic protocol handles definitions and private data helpers support.
A protocol handle identifies a protocol instance initialized against a
specific handle; it embeds all the references to the core SCMI xfer methods
that will be needed by a protocol implementation to build and send its own
Expose to the SCMI drivers a non managed version of a common protocols API
based on generic get/put methods and protocol handles.
All drivers still keep using the old API, no functional change.
Signed-off-by: Cristian Marussi
---
These non devres methods are probably not needed, given the devm_
Expose to the SCMI drivers a new devres managed common protocols API based
on generic get/put methods and protocol handles.
All drivers still keep using the old API, no functional change.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/driver.c | 92 ++
Hi Gene,
I have a bunch of comments, please take a look at my inline
comments.
On Thu, Dec 24, 2020 at 03:48:04PM +0800, Gene Chen wrote:
> From: Gene Chen
>
> Add basic support for the battery charger for MT6360 PMIC
>
> Signed-off-by: Gene Chen
> ---
> drivers/power/supply/Kconfig
Extend common protocol registration routines and provide some new generic
protocols get/put helpers that can track protocols usage and automatically
perform the proper initialization and de-initialization on demand when
required.
Convert all standard protocols to use this new registration scheme
Hi all,
The current SCMI implementation does not provide an interface to easily
develop and include a custom vendor protocol implementation as prescribed
by the SCMI standard, also because, there is not currently any custom
protocol in the upstream to justify the development of a custom interface
From: Nathan Chancellor
Date: Mon, 4 Jan 2021 17:09:36 -0700
> On Mon, Jan 04, 2021 at 12:18:10PM +, Alexander Lobakin wrote:
>> This series hunts the problems discovered after manual enabling of
>> ARCH_WANT_LD_ORPHAN_WARN, notably the missing PAGE_ALIGNED_DATA()
>> section affecting VDSO
On Wednesday 06 Jan 2021 at 17:47:58 (+), Al Viro wrote:
> On Wed, Jan 06, 2021 at 03:07:24PM +, Ionela Voinescu wrote:
>
> > > > > 367 switch ((u64)reg->address) {
> > >
> > > That's not a dereference but I guess sparse complains of dropping the
> > > __iomem. We could change
Hello,
On Wed, Jan 06, 2021 at 11:46:20AM -0800, Andrew Morton wrote:
> On Tue, 5 Jan 2021 20:28:27 -0800 (PST) Hugh Dickins wrote:
>
> > Alex, please consider why the authors of these lines (whom you
> > did not Cc) chose to write them without BUG_ON(): it has always
> > been preferred
On Wed, 6 Jan 2021, Andrew Morton wrote:
> On Tue, 5 Jan 2021 20:28:27 -0800 (PST) Hugh Dickins wrote:
>
> > Alex, please consider why the authors of these lines (whom you
> > did not Cc) chose to write them without BUG_ON(): it has always
> > been preferred practice to use BUG_ON() on
On Sun, Jan 3, 2021 at 11:00 AM Samuel Holland wrote:
> As there is an RSB controller in the H6 SoC, there should be some pin
> configuration for it. While no such configuration is documented, the
> "s_i2c" pins are suspiciously on the "alternate" function 3, with no
> primary function 2 given.
> -Original Message-
> From: Vincent Guittot [mailto:vincent.guit...@linaro.org]
> Sent: Thursday, January 7, 2021 5:29 AM
> To: Song Bao Hua (Barry Song)
> Cc: Valentin Schneider ; Catalin Marinas
> ; Will Deacon ; Rafael J. Wysocki
> ; Cc: Len Brown ;
> gre...@linuxfoundation.org;
Now, after that all the sections are explicitly described and
declared in vmlinux.lds.S, we can enable ld orphan warnings to
prevent from missing any new sections in future.
Signed-off-by: Alexander Lobakin
---
arch/mips/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
Catch any symbols placed in .got, .got.plt, .plt, .rel.dyn
or .rela.dyn and check for these sections to be zero-sized
at link time.
At least two of them were noticed in real builds:
mips-alpine-linux-musl-ld: warning: orphan section `.rel.dyn'
from `init/main.o' being placed in section
Discard GNU attributes at link time as kernel doesn't use it at all.
Solves a dozen of the following ld warnings (one per every file):
mips-alpine-linux-musl-ld: warning: orphan section `.gnu.attributes'
from `arch/mips/kernel/head.o' being placed in section
`.gnu.attributes'
MIPS uses its own declaration of rwdata, and thus it should be kept
in sync with the asm-generic one. Currently PAGE_ALIGNED_DATA() is
missing from the linker script, which emits the following ld
warnings:
mips-alpine-linux-musl-ld: warning: orphan section
`.data..page_aligned' from
This series hunts the problems discovered after manual enabling of
ARCH_WANT_LD_ORPHAN_WARN, notably the missing PAGE_ALIGNED_DATA()
section affecting VDSO placement (marked for stable).
Compile and runtime tested on MIPS32R2 CPS board with no issues.
Since v1 [0]:
- catch .got entries too as
Hi Pawel,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
commit: 22447a99c97e353bde8f90c2353873f27681d57c drivers/soc/litex: add LiteX
SoC Controller driver
date: 8 weeks
On Wed, Jan 06, 2021 at 11:50:44AM -0800, Andrew Morton wrote:
> On Tue, 5 Jan 2021 20:22:39 -0800 Roman Gushchin wrote:
>
> > Imran Khan reported a regression in hackbench results caused by the
> > commit f2fe7b09a52b ("mm: memcg/slab: charge individual slab objects
> > instead of pages").
>
>
On Wed, Jan 6, 2021 at 3:23 AM David Hildenbrand wrote:
>
> On 06.01.21 11:42, Michal Hocko wrote:
> > On Wed 06-01-21 10:56:19, David Hildenbrand wrote:
> > [...]
> >> Note that this is not sufficient in the general case. I already
> >> mentioned that we effectively override an already
On Wed 06-01-21 11:30:25, Mike Kravetz wrote:
> On 1/6/21 8:35 AM, Michal Hocko wrote:
> > On Wed 06-01-21 16:47:35, Muchun Song wrote:
> >> Because we only can isolate a active page via isolate_huge_page()
> >> and hugetlbfs_fallocate() forget to mark it as active, we cannot
> >> isolate and
Add the bindings for the bq256xx series of battery charging ICs.
Datasheets:
- https://www.ti.com/lit/ds/symlink/bq25600.pdf
- https://www.ti.com/lit/ds/symlink/bq25601.pdf
- https://www.ti.com/lit/ds/symlink/bq25600d.pdf
- https://www.ti.com/lit/ds/symlink/bq25601d.pdf
-
The BQ256XX family of devices are highly integrated buck chargers
for single cell batteries.
Signed-off-by: Ricardo Rivera-Matos
---
v9 - resolves two warnings issued by kernel test robot
v10 - passes psy_cfg by reference
drivers/power/supply/Kconfig | 11 +
Hello,
This patchset introduces the bq256xx family of charging ICs. The bq256xx
ICs are highly integrated, buck, switching chargers intended for use in
smartphones, tablets, and portable electronics.
Ricardo Rivera-Matos (2):
dt-bindings: power: Add the bq256xx dt bindings
power: supply:
On Wed, Jan 6, 2021 at 2:42 PM Jim Quinlan wrote:
>
> -- Forwarded message -
> From: Bjorn Helgaas
> Date: Wed, Jan 6, 2021 at 2:19 PM
> Subject: Re: [PATCH v2 5/6] PCI: brcmstb: Add panic/die handler to RC driver
> To: Jim Quinlan
> Cc: , Nicolas Saenz Julienne
> , ,
> ,
On Wed, Jan 06, 2021 at 11:28:00AM -0500, Rik van Riel wrote:
> On Tue, 2021-01-05 at 16:41 -0800, paul...@kernel.org wrote:
> >
> > @@ -203,7 +204,6 @@ static void
> > clocksource_watchdog_inject_delay(void)
> > injectfail = inject_delay_run;
> > if (!(++injectfail /
On Tue, 5 Jan 2021 20:22:39 -0800 Roman Gushchin wrote:
> Imran Khan reported a regression in hackbench results caused by the
> commit f2fe7b09a52b ("mm: memcg/slab: charge individual slab objects
> instead of pages").
How large was the regression?
> --- a/mm/memcontrol.c
> +++
On Thu, Jan 07, 2021 at 01:08:01AM +0530, Jeffrin Jose T wrote:
> On Mon, 2021-01-04 at 07:21 +0100, Greg Kroah-Hartman wrote:
> > On Sun, Jan 03, 2021 at 06:37:51PM +0530, Jeffrin Jose T wrote:
> > > On Mon, 2020-12-28 at 12:41 -0800, Guenter Roeck wrote:
> > > > On 12/28/20 1:50 AM, Pavel Machek
On Tue, 5 Jan 2021 20:28:27 -0800 (PST) Hugh Dickins wrote:
> Alex, please consider why the authors of these lines (whom you
> did not Cc) chose to write them without BUG_ON(): it has always
> been preferred practice to use BUG_ON() on predicates, but not on
> functionally effective statements
Tom Rix wrote:
> These two loops iterate over the same data, i believe returning here is all
> that is needed.
But if the first loop is made to support a new type, but the second loop is
missed, it will then likely oops. Besides, the compiler should optimise both
paths together.
David
On Mon, 2021-01-04 at 07:21 +0100, Greg Kroah-Hartman wrote:
> On Sun, Jan 03, 2021 at 06:37:51PM +0530, Jeffrin Jose T wrote:
> > On Mon, 2020-12-28 at 12:41 -0800, Guenter Roeck wrote:
> > > On 12/28/20 1:50 AM, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > > > > > >
On Wed, Jan 06, 2021 at 10:25:26AM -0800, Joe Perches wrote:
> On Wed, 2021-01-06 at 18:52 +0100, Greg Kroah-Hartman wrote:
> > On Wed, Jan 06, 2021 at 07:43:42PM +0200, Filip Kolev wrote:
> > > On 06-Jan-21 09:51, Greg Kroah-Hartman wrote:
> > > > On Tue, Jan 05, 2021 at 10:29:18PM +0200, Filip
From: Jaegeuk Kim
This fixes a warning caused by wrong reserve tag usage in __ufshcd_issue_tm_cmd.
WARNING: CPU: 7 PID: 7 at block/blk-core.c:630 blk_get_request+0x68/0x70
WARNING: CPU: 4 PID: 157 at block/blk-mq-tag.c:82 blk_mq_get_tag+0x438/0x46c
And, in ufshcd_err_handler(), we can avoid to
When gate_work/ungate_work gets an error during hibern8_enter or exit,
ufshcd_err_handler()
ufshcd_scsi_block_requests()
ufshcd_reset_and_restore()
ufshcd_clear_ua_wluns() -> stuck
ufshcd_scsi_unblock_requests()
In order to avoid it, ufshcd_clear_ua_wluns() can be called per
During commit "88bc4178568b8e0331143cc0616640ab72f0cba1" DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This lead to DLCK inversion, so let's swap DCLK
phase to fix
First patch is a tested by me fix, while the second need testing to
understand if it works correctly with any sunxi SoC with DE peripheral.
Already tested SoCs are:
- A20
- A33
Need testing:
- A10
- A10s
- A13
Giulio Benetti (2):
drm/sun4i: tcon: fix inverted DCLK polarity
drm/sun4i: tcon:
It turned out(Maxime suggestion) that bit 26 of SUN4I_TCON0_IO_POL_REG is
dedicated to invert DCLK polarity and this makes thing really easier than
before. So let's handle DCLK polarity by adding
SUN4I_TCON0_IO_POL_DCLK_POSITIVE as bit 26 and activating according to
bus_flags the same way is done
On Wed, 6 Jan 2021 14:49:35 +0800 Baoquan He wrote:
> > Fixes: 9a1ac2288cf1 ("mm/memcontrol:rewrite mem_cgroup_page_lruvec()")
>
> ...
>
> Thanks for fixing this. We also encountered this issue in kdump kernel
> with the mainline 5.10 kernel since 'cgroup_disable=memory' is added.
Wait.
On 1/6/21 9:40 AM, David Howells wrote:
> David Howells wrote:
>
>> How about this?
>> ...
>> Fix the second loop so that it doesn't encode the size and type of an
>> unsupported token, but rather just ignore it as does the first loop.
> Actually, a better way is probably just to error
When gate_work/ungate_work gets an error during hibern8_enter or exit,
ufshcd_err_handler()
ufshcd_scsi_block_requests()
ufshcd_reset_and_restore()
ufshcd_clear_ua_wluns() -> stuck
ufshcd_scsi_unblock_requests()
In order to avoid it, ufshcd_clear_ua_wluns() can be called per
> Hi Arseny, thanks for your work on this!
> I did a small review in a hope it helps.
> Also it may be cool to have the driver feature
> for that (so that the host can see if its supported).
> But I guess this was already said by Michael. :)
Hello, thank You for your review, i'll prepare
v2 as
On Wed, 6 Jan 2021 14:49:35 +0800 Baoquan He wrote:
> > --- 5.11-rc2/include/linux/memcontrol.h 2020-12-27 20:39:36.751923135
> > -0800
> > +++ linux/include/linux/memcontrol.h2021-01-03 19:38:24.822978559
> > -0800
> > @@ -665,7 +665,7 @@ static inline struct lruvec *mem_cgroup_
>
On 1/6/21 8:35 AM, Michal Hocko wrote:
> On Wed 06-01-21 16:47:35, Muchun Song wrote:
>> Because we only can isolate a active page via isolate_huge_page()
>> and hugetlbfs_fallocate() forget to mark it as active, we cannot
>> isolate and migrate those pages.
>
> I've little bit hard time to
On Wed, Jan 06, 2021 at 11:45:50AM -0500, Alan Stern wrote:
> On Wed, Jan 06, 2021 at 01:10:05PM +0300, Dan Carpenter wrote:
> > Syzbot discovered that the probe error handling doesn't clean up the
> > resources allocated in zr364xx_board_init(). There are several
> > related bugs in this code so
> Is ENODEV the right error here?
> Just a quick look at a man page, and
> I am under impression something like
> EPROTONOSUPPORT or ESOCKNOSUPPORT
> may suit?
I used ENODEV because this code is returned some
lines below when !new_transport(e.g. valid transport
not found). But i think you codes
On 1/6/21 11:15 AM, Florian Fainelli wrote:
> All of the OF code that is used has stubbed and will compile and link
> just fine, keeping COMPILE_TEST is enough.
Yes, that matches my understanding.
I wish we had a list of which API families have full stub support...
Acked-by: Randy Dunlap
> IMHO you can avoid this special-casing
> by introducing yet another outer loop just
> for draining the extra data from buffer.
> Admittedly that may also require an extra
> transport op.
I'm not sure that extra tranport op is needed, may be i'll
try to put drain code inside copy loop, because
On Tue, Jan 05, 2021 at 02:39:28PM +0100, Jessica Yu wrote:
> Hi Frank,
>
> Sorry for the delay. I've just gotten back from vacation :-)
No problem - I figured you were :-)
Comments inline -
>
> +++ Frank van der Linden [21/12/20 23:49 +]:
> > 5fdc7db644 ("module: setup load info before
The pull request you sent on Wed, 6 Jan 2021 12:48:12 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.11-rc2-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/71c061d2443814de15e177489d5cc00a4a253ef3
Thank you!
--
Deet-doot-dot, I am
On Wed, 2021-01-06 at 20:16 +0100, Hans de Goede wrote:
> Hi Filipe,
>
> hid-logitech-dj already supports exposing devices behind a non-DJ / non-
> unifying
> receiver as separate HID child-devices of the receiver as we doe for DJ
> devices.
>
> ATM hid-logitech-dj does not yet support the c541
On Wed, 6 Jan 2021, Vlastimil Babka wrote:
> rather accept some wasted memory in scenarios that should be rare anyway (full
> memory hot remove), as we do the same in other contexts already. It's all RFC
> for now, as I might have missed some reason why it's not safe.
Looks good to me. My only
On Mon, Nov 30, 2020 at 04:11:37PM -0500, Jim Quinlan wrote:
> v2 -- Use regulator bulk API rather than multiple calls (MarkB).
>
> v1 -- Bindings are added for fixed regulators that may power the EP device.
>-- The brcmstb RC driver is modified to control these regulators
> during
On Mon, Nov 30, 2020 at 04:11:42PM -0500, Jim Quinlan wrote:
> Whereas most PCIe HW returns 0x on illegal accesses and the like,
> by default Broadcom's STB PCIe controller effects an abort. This simple
> handler determines if the PCIe controller was the cause of the abort and if
> so,
Hi Filipe,
On 1/6/21 8:07 PM, Filipe Laíns wrote:
> Hey,
>
> Some of the new Logitech receivers do not have the DJ interface, this creates
> an
> issue userspace applications like libratbag, as seen in [1], because we can't
> identify the device based on the hidraw PID.
>
> There are two
On Wed, 2021-01-06 at 18:48 +, Filipe Laíns wrote:
> On Wed, 2021-01-06 at 10:34 +0100, Bastien Nocera wrote:
> > On Mon, 2021-01-04 at 18:29 +, la...@archlinux.org wrote:
> > > From: Filipe Laíns
> > >
> > > This new feature present in new devices replaces the old Battery
> > > Level
>
On Wed, Jan 06, 2021 at 06:39:30PM +, Luck, Tony wrote:
> > The "Timeout: Not all CPUs entered broadcast exception handler" message
> > will appear from time to time given enough systems, but this message does
> > not identify which CPUs failed to enter the broadcast exception handler.
> >
All of the OF code that is used has stubbed and will compile and link
just fine, keeping COMPILE_TEST is enough.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/broadcom/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/Kconfig
On Wed, Jan 06, 2021 at 07:32:44PM +0100, Borislav Petkov wrote:
> On Wed, Jan 06, 2021 at 09:41:02AM -0800, Paul E. McKenney wrote:
> > The "Timeout: Not all CPUs entered broadcast exception handler" message
> > will appear from time to time given enough systems, but this message does
> > not
On Tue, 2021-01-05 at 15:02 +0100, Thomas Bogendoerfer wrote:
> Signed-off-by: Thomas Bogendoerfer
[]
> diff --git a/drivers/dma/txx9dmac.h b/drivers/dma/txx9dmac.h
[]
> @@ -26,11 +26,6 @@
> * DMA channel.
> */
>
>
> -#ifdef CONFIG_MACH_TX49XX
> -static inline bool
Hey,
Some of the new Logitech receivers do not have the DJ interface, this creates an
issue userspace applications like libratbag, as seen in [1], because we can't
identify the device based on the hidraw PID.
There are two solutions for this:
1) Implement device discovery via the internal
On Mon, Dec 28, 2020 at 09:50:38PM +0800, Zheng Yongjun wrote:
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
See this again:
https://lore.kernel.org/r/20171026223701.ga25...@bhelgaas-glaptop.roam.corp.google.com
>
On 01/05, Sumera Priyadarsini wrote:
> Currently, data for the device instance is held by vkms_device.
> Add a separate type, vkms_config to contain configuration details
> for the device and various modes to be later used by configfs.
> This config data stays constant once the device is created.
On Wed, Dec 16, 2020 at 09:19:44PM +0800, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
Looks like a good fix, but read this about the changelog title:
https://lore.kernel.org/r/20171026223701.ga25...@bhelgaas-glaptop.roam.corp.google.com
> Signed-off-by:
On Wed, Jan 6, 2021 at 10:59 AM Ben Gardon wrote:
>
> Many TDP MMU functions which need to perform some action on all TDP MMU
> roots hold a reference on that root so that they can safely drop the MMU
> lock in order to yield to other threads. However, when releasing the
> reference on the root,
On Tue, Jan 5, 2021 at 7:50 PM Liang Li wrote:
>
> Page reporting isolates free pages temporarily when reporting
> free pages information. It will reduce the actual free pages
> and may cause application failed for no enough available memory.
> This patch try to solve this issue, when there is no
Many TDP MMU functions which need to perform some action on all TDP MMU
roots hold a reference on that root so that they can safely drop the MMU
lock in order to yield to other threads. However, when releasing the
reference on the root, there is a bug: the root will not be freed even
if its
The tdp_mmu_roots and tdp_mmu_pages in struct kvm_arch should only contain
pages with tdp_mmu_page set to true. tdp_mmu_pages should not contain any
pages with a non-zero root_count and tdp_mmu_roots should only contain
pages with a positive root_count, unless a thread holds the MMU lock and
is in
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> Introduce the new compatible string, restricted-dma-pool, for restricted
> DMA. One can specify the address and length of the restricted DMA memory
> region by restricted-dma-pool in the device tree.
>
> Signed-off-by: Claire Chang
Hello!
In this file:
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index e4368159f88a..7fb2ac087d23 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
..
> +static const struct reserved_mem_ops rmem_swiotlb_ops = {
> + .device_init= rmem_swiotlb_device_init,
On Sat, Jan 2, 2021 at 3:37 AM Marc Zyngier wrote:
>
> On Thu, 31 Dec 2020 21:12:40 +,
> Rob Herring wrote:
> >
> > On Mon, Dec 21, 2020 at 09:30:45AM +, Marc Zyngier wrote:
> > > On 2020-12-18 21:07, Saravana Kannan wrote:
> > > > Add support for creating device links out of interrupts
On Wed, Jan 06, 2021 at 09:37:11AM +0100, Geert Uytterhoeven wrote:
> Hi Thomas,
>
> CC Nemoto-san (de-facto TX49XX maintainer)
>
> On Tue, Jan 5, 2021 at 3:03 PM Thomas Bogendoerfer
> wrote:
> > I couldn't find any buyable product other than reference boards using
> > TX49xx CPUs. And since
Hi,
First of all let me say that I am glad that someone is working on a
upstream solution for this issue, would appreciate if you could CC and
Jim Quinlan on subsequent submissions.
On 1/5/21 7:41 PM, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
>
On Wed, 2021-01-06 at 10:34 +0100, Bastien Nocera wrote:
> On Mon, 2021-01-04 at 18:29 +, la...@archlinux.org wrote:
> > From: Filipe Laíns
> >
> > This new feature present in new devices replaces the old Battery
> > Level
> > Status (0x1000) feature. It keeps essentially the same
401 - 500 of 1126 matches
Mail list logo
