There is a bit of mess between cros-ec mfd includes and platform
includes. For example, we have a linux/mfd/cros_ec.h include that
exports the interface implemented in platform/chrome/cros_ec_proto.c. Or
we have a linux/mfd/cros_ec_commands.h file that is non related to the
multifunction device (in
Hi,
Now that rc1 is released is time to send another patchset rebased on
top. This is an attempt to clean up a bit more the cros-ec driver
to have a better separation on what is part of the MFD subsystem and
what is part of platform/chrome.
The major changes introduced by this patchset are:
1. Mo
Now, the ChromeOS EC core driver has nothing related to an MFD device, so
move that driver from the MFD subsystem to the platform/chrome subsystem.
Signed-off-by: Enric Balletbo i Serra
Acked-by: Andy Shevchenko
Acked-by: Thierry Reding
Acked-by: Mark Brown
Acked-by: Wolfram Sang
Acked-by: Ne
An MFD is a device that contains several sub-devices (cells). For instance,
the ChromeOS EC fits in this description as usually contains a charger and
can have other devices with different functions like a Real-Time Clock,
an Audio codec, a Real-Time Clock, ...
If you look at the driver, though, w
This patch corrects the SPDX License Identifier style
in the trace header file related to Microsoft Hyper-V
client drivers.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)
Changes made by using a script
From: Ondřej Jirman
Date: Jul/22/2019, 13:42:40 (UTC+00:00)
> Hello Jose,
>
> On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> > [ Hope this diff looks better (generated with --minimal) ]
> >
> > This converts stmmac to use phylink. Besides the code redution this will
> > allow to
On 22/07/2019 14:03, Russell King - ARM Linux admin wrote:
> On Mon, Jul 22, 2019 at 01:47:57PM +0100, Marc Zyngier wrote:
>> On 22/07/2019 12:25, Petr Mladek wrote:
>>> On Mon 2019-07-22 11:33:28, Marc Zyngier wrote:
printk currently relies on local_clock to time-stamp the kernel
message
Wire up the new clone3 syscall added in commit 7f192e3cd316 ("fork:
add clone3").
This requires a ppc_clone3 wrapper, in order to save the non-volatile
GPRs before calling into the generic syscall code. Otherwise we hit
the BUG_ON in CHECK_FULL_REGS in copy_thread().
Lightly tested using Christia
On 7/22/19 2:28 PM, Juri Lelli wrote:
> On 22/07/19 13:07, Dietmar Eggemann wrote:
>> On 7/19/19 3:59 PM, Juri Lelli wrote:
>>
>> [...]
>>
>>> @@ -557,6 +558,38 @@ static struct rq *dl_task_offline_migration(struct rq
>>> *rq, struct task_struct *p
>>> double_lock_balance(rq, later_rq)
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the dm365
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/dm365.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
From: Bartosz Golaszewski
Currently the timer code checks if the clock pointer passed to it is
good (!IS_ERR(clk)). The new clocksource driver expects the clock to
be functional and doesn't perform any checks so emit a warning if
clk_get() fails. Apply this to all davinci platforms.
Signed-off-b
From: Bartosz Golaszewski
Boards from the dm* family rely on register offset definitions from
arch/arm/mach-davinci/include/mach/time.h. We'll be removing this file
soon, so move the required defines to davinci.h where the rest of such
constants live.
Signed-off-by: Bartosz Golaszewski
Reviewed
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the dm644x
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/dm644x.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions
From: Bartosz Golaszewski
All platforms have now been switched to the new clocksource driver.
Remove the old code and various no longer needed bits and pieces.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/Makefile | 3 +-
arch/arm/mach
From: Bartosz Golaszewski
Sekhar,
the following patches switch DaVinci to using the new clocksource driver which
is now upstream. They are rebased on top of v5.3-rc1. Additionally the
following two patches were reverted locally due to a regression in v5.3-rc1
about which the relevant maintainers
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the da850
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/da850.c | 46 ++-
1 file changed, 13 insertions(+), 33
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the da830
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/da830.c | 41 ---
1 file changed, 14 insertions(+), 27
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the dm646x
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/dm646x.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions
From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the dm355
platform to using it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/mach-davinci/dm355.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-
On Mon, Jul 22, 2019 at 1:35 PM NitinGote wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by
From: Bartosz Golaszewski
Switch all davinci boards supporting device tree to using the new
clocksource driver: remove the previous OF_TIMER_DECLARE() from
mach-davinci and select davinci-timer for ARCH_DAVINCI.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: David Lechner
---
arch/arm/Kconfi
Hi,
Any feedback on this series? I think it was pretty much ready for merge
regarding the comments received so far.
I could craft a rebased v7, with or without additional changes, if needed.
What do you think?
Cheers,
Paul
On Fri 14 Jun 19, 16:38, Paul Kocialkowski wrote:
> This is early supp
On 7/22/19 7:56 AM, Takashi Iwai wrote:
On Mon, 22 Jul 2019 14:49:34 +0200,
Pierre-Louis Bossart wrote:
On 7/21/19 9:23 AM, Masahiro Yamada wrote:
When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
make sure they can be included from user-space.
Currently, header.h an
On Sun, Jul 21, 2019 at 04:53:27PM +0530, Hariprasad Kelam wrote:
> kmalloc + memcpy can be replaced with kmemdup.
>
> fix below issue reported by coccicheck
> ./fs/omfs/inode.c:366:9-16: WARNING opportunity for kmemdup
>
> Signed-off-by: Hariprasad Kelam
Thanks!
Acked-by: Bob Copeland
--
B
Sir/madam,I humbly seek your consent for an investment in your
country.I need to invest in the following areas by your candid advice
and supervision; industrial, petroleum energy , land farming..More
details of this will be sent following your INVESTMENT suggestion and
interest. I am deeply sorry f
There are a lot of compilation warnings due to tx_profile[] and
rx_profile[] are only used in lib/dim/net_dim.c but include/linux/dim.h
is included elsewhere.
In file included from ./include/rdma/ib_verbs.h:64,
from ./include/linux/mlx5/device.h:37,
from ./include
On Fri, Jul 19, 2019 at 04:16:02PM -0400, Jim Quinlan wrote:
> On Fri, Jul 19, 2019 at 7:03 AM Sudeep Holla wrote:
> >
> > On Thu, Jul 18, 2019 at 05:38:06PM -0400, Jim Quinlan wrote:
> > > Hi Sudeep,
> > >
> > > Just a comment in general. The asynchronous commands you are
> > > implementing are
pon., 22 lip 2019 o 14:12 Bartosz Golaszewski napisał(a):
>
> Hi,
>
> with v5.3-rc1 I'm hitting the following BUG() when trying to load the
> gpio-backlight module:
>
> kernel BUG at kernel/module.c:1919!
> Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: s
Hi,
[...]
> > +Buffer management while decoding
> > +
> > +Contrary to stateful decoders, a stateless decoder does not perform any
> > kind of
> > +buffer management: it only guarantees that dequeued ``CAPTURE`` buffers
> > can be
> > +used by the client for as l
Am Montag, den 22.07.2019, 15:48 +0300 schrieb Daniel Baluta:
> SAI module on imx7ulp/imx8m features 2 new registers (VERID and PARAM)
> at the beginning of register address space.
>
> On imx7ulp FIFOs can held up to 16 x 32 bit samples.
> On imx8mq FIFOs can held up to 128 x 32 bit samples.
>
>
On Mon, Jul 22, 2019 at 01:47:57PM +0100, Marc Zyngier wrote:
> On 22/07/2019 12:25, Petr Mladek wrote:
> > On Mon 2019-07-22 11:33:28, Marc Zyngier wrote:
> >> printk currently relies on local_clock to time-stamp the kernel
> >> messages. In order to allow the timestamping (and only that)
> >> to
Hello Kieran,
On 7/10/19 9:39 PM, Kieran Bingham wrote:
> I2C drivers match against an I2C ID table, an OF table, and an ACPI
> table. It is now also possible to match against an OF table entry
> without the vendor prefix to support backwards compatibility, and allow
> simplification of the i2c pr
Am Montag, den 22.07.2019, 15:48 +0300 schrieb Daniel Baluta:
> FIFO combining mode allows the separate FIFOs for multiple data
> channels
> to be used as a single FIFO for either software accesses or a single
> data
> channel or both.
>
> FIFO combined mode is described in chapter 13.10.3.5.4 fro
Hi,
* Johannes Berg [190625 08:03]:
> On Tue, 2019-06-25 at 01:00 -0700, Tony Lindgren wrote:
> > Hi,
> >
> > * Johannes Berg [190625 07:47]:
> > > On Tue, 2019-06-25 at 00:38 -0700, Tony Lindgren wrote:
> > > > Hi,
> > > >
> > > > Looks like at least drivers/net/wireless/ti wlcore driver has
Am Montag, den 22.07.2019, 15:48 +0300 schrieb Daniel Baluta:
> SAI supports up to 8 data lines. This property let the user
> configure how many data lines should be used per transfer
> direction (Tx/Rx).
>
> > Signed-off-by: Daniel Baluta
> ---
> Documentation/devicetree/bindings/sound/fsl-sai.
Am Montag, den 22.07.2019, 15:48 +0300 schrieb Daniel Baluta:
> SAI supports up to 8 Rx/Tx data lines which can be enabled
> using TCE/RCE bits of TCR3/RCR3 registers.
>
> Data lines to be enabled are read from DT fsl,dl_mask property.
> By default (if no DT entry is provided) only data line 0 is
On 7/22/19 3:50 PM, Arnd Bergmann wrote:
> objtool points out several conditions that it does not like, depending
> on the combination with other configuration options and compiler
> variants:
>
> stack protector:
> lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0xbf: call to
>
On Mon, 22 Jul 2019 14:49:34 +0200,
Pierre-Louis Bossart wrote:
>
>
>
> On 7/21/19 9:23 AM, Masahiro Yamada wrote:
> > When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
> > make sure they can be included from user-space.
> >
> > Currently, header.h and fw.h are excluded from
On Mon, Jul 22, 2019 at 2:25 PM Andrey Ryabinin wrote:
> On 7/22/19 12:10 PM, Arnd Bergmann wrote:
> >
> > Fixes: 42440c1f9911 ("lib/ubsan: add type mismatch handler for new
> > GCC/Clang")
>
> There was no uaccess validataion at that time, so the right fixes line is
> probably this:
>
> Fixes:
objtool points out several conditions that it does not like, depending
on the combination with other configuration options and compiler
variants:
stack protector:
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0xbf: call to
__stack_chk_fail() with UACCESS enabled
lib/ubsan.o: warni
On 7/21/19 9:23 AM, Masahiro Yamada wrote:
When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
make sure they can be included from user-space.
Currently, header.h and fw.h are excluded from the test coverage.
To make them join the compile-test, we need to fix the build erro
Tx channel enable (TCE) / Rx channel enable (RCE) bits
enable corresponding data channel for Tx/Rx operation.
Because SAI supports up the 8 channels TCE/RCE occupy
up the 8 bits inside TCR3/RCR3 registers we need to extend
the mask to reflect this.
Signed-off-by: Daniel Baluta
---
sound/soc/fsl
From: Lucas Stach
The DMA request schould be triggered as soon as the FIFO has space
for another burst. As different versions of the SAI block have
different FIFO sizes, the watrmark level needs to be derived from
version specific data.
Signed-off-by: Lucas Stach
---
sound/soc/fsl/fsl_sai.c |
SAI supports up to 8 data lines. This property let the user
configure how many data lines should be used per transfer
direction (Tx/Rx).
Signed-off-by: Daniel Baluta
---
Documentation/devicetree/bindings/sound/fsl-sai.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/dev
SAI supports up to 8 Rx/Tx data lines which can be enabled
using TCE/RCE bits of TCR3/RCR3 registers.
Data lines to be enabled are read from DT fsl,dl_mask property.
By default (if no DT entry is provided) only data line 0 is enabled.
Note:
We can only enable consecutive data lines starting with
New IP version introduces Version ID and Parameter registers
and optionally added Timestamp feature.
VERID and PARAM registers are placed at the top of registers
address space and some registers are shifted according to
the following table:
Tx/Rx data registers and Tx/Rx FIFO registers keep their
FIFO combining mode allows the separate FIFOs for multiple data channels
to be used as a single FIFO for either software accesses or a single data
channel or both.
FIFO combined mode is described in chapter 13.10.3.5.4 from i.MX8MQ
reference manual [1].
For each direction (RX/TX) fifo combine mod
This allows combining multiple-data-line FIFOs into a
single-data-line FIFO.
Signed-off-by: Daniel Baluta
---
Documentation/devicetree/bindings/sound/fsl-sai.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt
b/Documentation/devicetre
SAI IP supports up to 8 data lines. The configuration of
supported number of data lines is decided at SoC integration
time.
This patch adds definitions for all related data TX/RX registers:
* TDR0..7, Transmit data register
* TFR0..7, Transmit FIFO register
* RDR0..7, Recei
SAI module on imx7ulp/imx8m features 2 new registers (VERID and PARAM)
at the beginning of register address space.
On imx7ulp FIFOs can held up to 16 x 32 bit samples.
On imx8mq FIFOs can held up to 128 x 32 bit samples.
Signed-off-by: Daniel Baluta
---
sound/soc/fsl/fsl_sai.c | 14
From: Lucas Stach
New revisions of the SAI IP block have even more differences that need
be taken into account by the driver. To avoid sprinking compatible
checks all over the driver move the current differences into of_match_data.
Signed-off-by: Lucas Stach
---
sound/soc/fsl/fsl_sai.c | 22 ++
So far SAI IPs integrated with imx6 only supported one data line.
Starting with imx7 and imx8 SAI integration support up to 8 data
lines and multiple ways of combining the fifos for each data line.
New SAI IP version introduces two new registers (Version and Parmeter
registers) which are placed at
This changeset adds support for the ADIS16460.
Support for this chip, requires changes in both IIO & SPI, in order to
support configurable/longer CS change delays.
The default CS change delay is 10 uS, while the ADIS16460 requires a
minimum of 16 uS. In order to accomodate this, the SPI transfer
The ADIS16460 device is a complete inertial system that includes a triaxial
gyroscope and a triaxial accelerometer. It's more simplified design than
that of the ADIS16480, and does not offer the triaxial magnetometers &
pressure sensors. It does also have a temperature sensor (like the
ADIS16480).
This change adds device-tree bindings for the ADIS16460.
Reviewed-by: Rob Herring
Signed-off-by: Alexandru Ardelean
---
.../bindings/iio/imu/adi,adis16460.yaml | 53 +++
MAINTAINERS | 1 +
2 files changed, 54 insertions(+)
create mode 10
On 22/07/2019 12:25, Petr Mladek wrote:
> On Mon 2019-07-22 11:33:28, Marc Zyngier wrote:
>> printk currently relies on local_clock to time-stamp the kernel
>> messages. In order to allow the timestamping (and only that)
>> to be overridden by architecture-specific code, let's declare
>> a new time
The ADIS16460 requires a higher delay before the next transfer. Since the
SPI framework supports configuring the delay before the next transfer, this
driver will become the first user of it.
The support for this functionality in ADIS16460 requires an addition to the
ADIS lib to support the `cs_cha
Some devices like the ADIS16460 IMU require a longer period between
transfers, i.e. between when the CS is de-asserted and re-asserted. The
default value of 10us is not enough. This change makes the delay
configurable for when the next CS change goes active, allowing the default
to remain 10us is c
When building with 'make C=1', sparse reports an endianess bug:
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:60:30: warning: cast removes address
space of expression
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24: warning: incorrect type in
argument 1 (different address spaces)
drivers/dma/dw-edma/d
The new driver mixes up dma_addr_t and __iomem pointers, which results
in warnings on some 32-bit architectures, like:
drivers/dma/dw-edma/dw-edma-v0-core.c: In function '__dw_regs':
drivers/dma/dw-edma/dw-edma-v0-core.c:28:9: error: cast to pointer from integer
of different size [-Werror=int-to-
Putting large constant data on the stack causes unnecessary overhead
and stack usage:
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:285:6: error: stack frame size of 1376
bytes in function 'dw_edma_v0_debugfs_on' [-Werror,-Wframe-larger-than=]
Mark the variable 'static const' in order for the compile
Pershendetje e dashur,
A mund të trajtoni një projekt themeli?
ju lutemi të përgjigjeni për më shumë hollësi dhe informacion.
Zonja Karin
Hello Jose,
On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> [ Hope this diff looks better (generated with --minimal) ]
>
> This converts stmmac to use phylink. Besides the code redution this will
> allow to gain more flexibility.
I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-
Hi Steve,
On Tue, Jul 09, 2019 at 11:15:20AM -0400, Steven Rostedt wrote:
> On Wed, 3 Jul 2019 15:08:32 +0100
> Catalin Marinas wrote:
> > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > > index 5471efbeb937..0ca6f53c8505 100644
> > > --- a/kernel/kprobes.c
> > > +++ b/kernel/kprobes.c
> >
czw., 11 lip 2019 o 10:48 Geert Uytterhoeven napisał(a):
>
> On Thu, Jul 11, 2019 at 10:29 AM Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Instead of always dereferencing &pdev->dev, just assign a helper local
> > variable of type struct device * and use it where applicable.
Em Sun, Jul 21, 2019 at 01:24:10PM +0200, Jiri Olsa escreveu:
> Adding empty libperf.a under toos/perf/lib and
> linking it with perf.
So, I noticed you created a subdirectory under tools/perf/, while I
first thought you would have it in tools/lib/perf/, why not move it
there?
- Arnaldo
> It ca
On Fri, Jul 19, 2019 at 10:03:31PM +0200, Arnd Bergmann wrote:
> asan-stack mode still uses dangerously large kernel stacks of
> tens of kilobytes in some drivers, and it does not seem that anyone
> is working on the clang bug.
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
We get a warning about unnecessary properties of
arch/arm64/boot/dts/qcom/sdm845.dtsi:2211.22-2257.6: Warning
(avoid_unnecessary_addr_size): /soc/mdss@ae0/dsi@ae94000: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property
arch/arm64/boot/dts/qcom/sdm845.dtsi:2278.22
Unit name is supposed to be a number, using a macro with hex value is
not recommended, so add the value in unit name.
arch/arm64/boot/dts/qcom/pm8998.dtsi:81.18-84.6: Warning (unit_address_format):
/soc/spmi@c44/pmic@0/adc@3100/adc-chan@0x06: unit name should not have
leading "0x"
arch/arm64
Unit name is supposed to be a number, using a macro with hex value is
not recommended, so add the value in unit name.
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:966.16-969.4: Warning
(unit_address_format): /soc@0/spmi@c44/pmic@0/adc@3100/adc-chan@0x4d: unit
name should not have leading "0x"
So this is an attempt to fix some warns on sdm845 dts. We still have bunch
of warnings to fix after this series (dupplicate adress and node names
having underscores etc).
lets get long hanging ones fixed, we can see the warns with W=1 or W=2
Vinod Koul (5):
arm64: dts: qcom: sdm845: Add unit na
The thermal trip points have unit name but no reg property, so we can
remove them
arch/arm64/boot/dts/qcom/sdm845.dtsi:2824.31-2828.7: Warning
(unit_address_vs_reg): /thermal-zones/cpu0-thermal/trips/trip-point@0: node has
a unit name, but no reg property
arch/arm64/boot/dts/qcom/sdm845.dtsi:283
We get a warning about missing unit name for soc node, so add it.
arch/arm64/boot/dts/qcom/sdm845.dtsi:623.11-2814.4: Warning
(unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
1 file chang
On Tue, Jul 09, 2019 at 09:30:49PM +0900, Masami Hiramatsu wrote:
> On Wed, 3 Jul 2019 10:02:05 -0400 Steven Rostedt
> wrote:
> > On Tue, 2 Jul 2019 17:50:09 +0100 Mark Rutland
> > wrote:
> > > On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote:
> > > > Signed-off-by: Masami Hiramatsu
On Sun, Jul 21, 2019 at 11:20:08PM +0900, Masahiro Yamada wrote:
> When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
> make sure they can be included from user-space.
>
> Currently, zcrypt.h is excluded from the test coverage. To make it
> join the compile-test, we need to fix
On 22/07/19 13:07, Dietmar Eggemann wrote:
> On 7/19/19 3:59 PM, Juri Lelli wrote:
>
> [...]
>
> > @@ -557,6 +558,38 @@ static struct rq *dl_task_offline_migration(struct rq
> > *rq, struct task_struct *p
> > double_lock_balance(rq, later_rq);
> > }
> >
> > + if (p->dl.dl_non
On Mon, 22 Jul 2019 14:12:02 +0200,
Greg Kroah-Hartman wrote:
>
> On Mon, Jul 22, 2019 at 01:55:20PM +0200, Takashi Iwai wrote:
> > On Mon, 22 Jul 2019 07:55:36 +0200,
> > Takashi Iwai wrote:
> > >
> > > From: Mauro Rossi
> > >
> > > fw_{grow,map}_paged_buf() need to be defined as static inline
On 7/19/19 11:03 PM, Arnd Bergmann wrote:
> asan-stack mode still uses dangerously large kernel stacks of
> tens of kilobytes in some drivers, and it does not seem that anyone
> is working on the clang bug.
>
> Turn it off for all clang versions to prevent users from
> accidentally enabling it
On Mon 2019-07-22 14:08:51, Enrico Weigelt, metux IT consult wrote:
> From: Enrico Weigelt
>
> The current error message on failed probing tends to be a bit
> misleading. Fix it to tell exactly that an APU v1 was not found.
>
> Signed-off-by: Enrico Weigelt
Acked-by: Pavel Machek
--
(englis
On 7/22/19 2:55 PM, Arnd Bergmann wrote:
> ARM64 randdconfig builds regularly run into a build error, especially
> when NUMA_BALANCING and SPARSEMEM are enabled but not SPARSEMEM_VMEMMAP:
>
> #error "KASAN: not enough bits in page flags for tag"
>
> The last-cpuid bits are already contitional
On 7/22/19 12:10 PM, Arnd Bergmann wrote:
> objtool points out several conditions that it does not like, depending
> on the combination with other configuration options and compiler
> variants:
>
> stack protector:
> lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0xbf: call to
>
The patch
SoC: rockchip: rockchip_max98090: Enable MICBIAS for headset keypress
detection
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually
The patch
SoC: rockchip-max98090: Remove MICBIAS as supply of input pin IN34
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in th
The patch
regulator: lm363x: Fix off-by-one n_voltages for lm3632 ldo_vpos/ldo_vneg
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usuall
The patch
regulator: lm363x: Fix n_voltages setting for lm36274
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the ne
The patch
ASoC: wcd9335: Fix misuse of GENMASK macro
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sen
The patch
ASoC: codecs: ad193x: Use regmap_multi_reg_write() when initializing
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
ASoC: fsl_esai: Wrap some operations to be functions
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hour
The patch
sound: soc: codecs: wcd9335: add irqflag IRQF_ONESHOT flag
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 2
The patch
ASoC: SOF: use __u32 instead of uint32_t in uapi headers
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
ASoC: max98383: fix i2c probe failure
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
ASoC: dapm: Fix handling of custom_stop_condition on DAPM graph walks
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
sound: soc: codecs: mt6358: change return type of mt6358_codec_init_reg
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime
The patch
sound: soc: bcm: cygnus-pcm: Unneeded variable: "ret".
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 ho
The patch
regulator: rk808: Return REGULATOR_MODE_INVALID for invalid mode
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometim
The patch
ASoC: cs42xx8: Fix MFREQ selection issue for async mode
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 h
The patch
spi: pxa2xx: Balance runtime PM enable/disable on error
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hour
We get a warning when CONFIG_SCSI_LOWLEVEL is disabled here:
WARNING: unmet direct dependencies detected for SCSI_FDOMAIN
Depends on [n]: SCSI_LOWLEVEL [=n] && SCSI [=y]
Selected by [m]:
- PCMCIA_FDOMAIN [=m] && SCSI_LOWLEVEL_PCMCIA [=y] && SCSI [=y] && PCMCIA
[=y] && m && MODULES [=y]
Mov
We get a warning when CONFIG_SCSI_LOWLEVEL is disabled here:
WARNING: unmet direct dependencies detected for SCSI_FDOMAIN
Depends on [n]: SCSI_LOWLEVEL [=n] && SCSI [=y]
Selected by [m]:
- PCMCIA_FDOMAIN [=m] && SCSI_LOWLEVEL_PCMCIA [=y] && SCSI [=y] && PCMCIA
[=y] && m && MODULES [=y]
Mov
Hi,
with v5.3-rc1 I'm hitting the following BUG() when trying to load the
gpio-backlight module:
kernel BUG at kernel/module.c:1919!
Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: systemd Tainted: GW
5.2.0-rc2-5-g7dabaa5ce05a #19
Hardware name: D
801 - 900 of 1180 matches
Mail list logo
