On Mon, Jul 22, 2019 at 10:41:52AM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 22, 2019 at 04:51:49AM -0700, Paul E. McKenney wrote:
>
> > > > > Would it make sense to have call_rcu() check to see if there are many
> > > > > outstanding requests on this CPU and if so process them before
> > > >
Need to ensure that kref_put does not run concurrently with the loop
inside rxe_pool_get_key.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_pool.c | 18 ++
drivers/infiniband/sw/rxe/rxe_pool.h | 4 +---
2 files changed, 19 insertions(+), 3 deletions(-)
diff
Used in a later patch.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_pool.c | 3 ++-
drivers/infiniband/sw/rxe/rxe_pool.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/sw/rxe/rxe_pool.c
b/drivers/infiniband/sw/rxe/rxe_pool.c
index
Make rxe_run_task only schedule tasks and never run them directly.
This simplification will be used in further patches.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_comp.c | 16
drivers/infiniband/sw/rxe/rxe_loc.h | 2 +-
Pointer to PD is not used in rxe_ah anymore.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_verbs.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.h
b/drivers/infiniband/sw/rxe/rxe_verbs.h
index 5c4b2239129c..8dd65c2a7c72 100644
---
Used in a later patch.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_loc.h | 1 +
drivers/infiniband/sw/rxe/rxe_qp.c | 17 +
drivers/infiniband/sw/rxe/rxe_req.c | 1 +
drivers/infiniband/sw/rxe/rxe_resp.c | 25 ++---
4 files changed,
This patchset helps to get rid of following race condition situations:
1. Tasklet functions were incrementing reference counting after entering
running the tasklet.
2. Getting a pointer to reference counted object (kref)
After putting all tasks to schedule, this counter does not have a
meaning anymore.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_comp.c| 6 --
drivers/infiniband/sw/rxe/rxe_hw_counters.c | 1 -
drivers/infiniband/sw/rxe/rxe_hw_counters.h | 1 -
3 files changed, 8
Replace tasklets with workqueues in rxe driver.
Ensure that task is called only through a workqueue. This allows to
simplify task logic.
Add additional dependencies to make sure that cleanup tasks do not
happen after object's memory is already reclaimed.
Improve overal stability of the driver
Reference should be aquired *before* the tasklet is run. The best time
to increment the reference counter is at initialisation. Otherwise, the
object may not exists anymore by the time tasklet is run.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_comp.c | 4
Replace void* with rxe_pool_entry* for some functions.
Change macro to inline function.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_comp.c | 18
drivers/infiniband/sw/rxe/rxe_mcast.c | 20
drivers/infiniband/sw/rxe/rxe_mr.c| 8 ++--
Specific implementations must finish off the cleanup of pool elements
when it is the right moment. Reason for that is that a concreate cleanup
function may want postpone and schedule part of object destruction to
later time.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_cq.c
On Fri, Jul 19 2019 at 12:22 -0600, Stephen Boyd wrote:
Quoting Lina Iyer (2019-07-01 08:29:07)
When triggering a TCS to send its contents, reading back the trigger
value may return an incorrect value. That is because, writing the
trigger may raise an interrupt which could be handled
On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> [snip]
> > > Would it make sense to have call_rcu() check to see if there are many
> > > outstanding requests on this CPU and if so process them before returning?
> > > That would ensure that frequent callers usually ended up doing
This enables the Enhanced Quadrature Encoder Pulse (eQEP) module for
connectors E1, E2 and E3 on BeagleBone Blue.
Signed-off-by: David Lechner
---
arch/arm/boot/dts/am335x-boneblue.dts | 54 +++
1 file changed, 54 insertions(+)
diff --git
This documents device tree binding for the Texas Instruments Enhanced
Quadrature Encoder Pulse (eQEP) Module found in various TI SoCs.
Signed-off-by: David Lechner
---
.../devicetree/bindings/counter/ti-eqep.txt| 18 ++
1 file changed, 18 insertions(+)
create mode 100644
This adds a new counter driver for the Texas Instruments Enhanced
Quadrature Encoder Pulse (eQEP) module.
Only very basic functionality is currently implemented - only enough to
be able to read the position. The actual device has many more features
which can be added to the driver on an as-needed
This adds new nodes for the Texas Instruments Enhanced Quadrature
Encoder Pulse (eQEP) module in the PWM subsystem on AM33XX.
Signed-off-by: David Lechner
---
arch/arm/boot/dts/am33xx-l4.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git
This series adds device tree bindings and a new counter driver for the Texas
Instruments Enhanced Quadrature Encoder Pulse (eQEP).
As mentioned in one of the commit messages, to start with, the driver only
supports reading the current counter value and setting the min/max values.
Other features
Now walk_page_range() can walk kernel page tables, we can switch the
arm64 ptdump code over to using it, simplifying the code.
Signed-off-by: Steven Price
---
arch/arm64/Kconfig | 1 +
arch/arm64/Kconfig.debug | 19 +
arch/arm64/include/asm/ptdump.h| 8 +-
To enable x86 to use the generic walk_page_range() function, the
callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct.
This means that ptdump_walk_pgd_level_core() is now always passed a
valid pgd, so drop the support for pgd==NULL.
Signed-off-by: Steven Price
---
Add a generic version of page table dumping that architectures can
opt-in to
Signed-off-by: Steven Price
---
include/linux/ptdump.h | 19 +
mm/Kconfig.debug | 21 ++
mm/Makefile| 1 +
mm/ptdump.c| 161 +
4 files
To enable x86 to use the generic walk_page_range() function, the
callers of ptdump_walk_pgd_level() need to pass an mm_struct rather
than the raw pgd_t pointer. Luckily since commit 7e904a91bf60
("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct
for EFI on x86.
Signed-off-by:
An mm_struct is needed to enable x86 to use of the generic
walk_page_range() function.
In the case of walking the user page tables (when
CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a
fake_mm structure because there isn't an mm_struct with a pointer
to the pgd of the user
Make use of the new functionality in walk_page_range to remove the
arch page walking code and use the generic code to walk the page tables.
The effective permissions are passed down the chain using new fields
in struct pg_state.
The KASAN optimisation is implemented by including test_p?d
Since 48684a65b4e3: "mm: pagewalk: fix misbehavior of walk_page_range
for vma(VM_PFNMAP)", page_table_walk() will report any kernel area as
a hole, because it lacks a vma.
This means each arch has re-implemented page table walking when needed,
for example in the per-arch ptdump walker.
Remove
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For sparc 64 bit, pmd_large() and pud_large() are already
pgd_entry() and pud_entry() were removed by commit 0b1fbfe50006c410
("mm/pagewalk: remove pgd_entry() and pud_entry()") because there were
no users. We're about to add users so reintroduce them, along with
p4d_entry() as we now have 5 levels of tables.
Note that commit a00cc7d9dd93d66a ("mm, x86:
For the /sys/kernel/debug/page_tables/ files, rather than outputing a
mostly empty line when a block of memory isn't present just skip the
line. This keeps the output shorter and will help with a future change
switching to using the generic page walk code as we no longer care about
the 'level'
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For s390, pud_large() and pmd_large() are already
mm/dump_pagetables.c passes both struct seq_file and struct pg_state
down the chain of walk_*_level() functions to be passed to note_page().
Instead place the struct seq_file in struct pg_state and access it from
struct pg_state (which is private to this file) in note_page().
Signed-off-by:
It is useful to be able to skip parts of the page table tree even when
walking without VMAs. Add test_p?d callbacks similar to test_walk but
which are called just before a table at that level is walked. If the
callback returns non-zero then the entire table is skipped.
Signed-off-by: Steven Price
Exposing the pud/pgd levels of the page tables to walk_page_range() means
we may come across the exotic large mappings that come with large areas
of contiguous memory (such as the kernel's linear map).
For architectures that don't provide all p?d_leaf() macros, provide
generic do nothing default
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For x86 we already have p?d_large() functions, so simply
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For mips, we only support large pages on 64 bit.
For 64
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information will be provided by the
p?d_leaf() functions/macros.
For arc, we only have two levels, so only pmd_leaf()
This is a slight reworking and extension of my previous patch set
(Convert x86 & arm64 to use generic page walk), but I've continued the
version numbering as most of the changes are the same. In particular
this series ends with a generic PTDUMP implemention for arm64 and x86.
Many architectures
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For powerpc pmd_large() already exists and does what we
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For riscv a page is a leaf page when it has a read, write
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information will be provided by the
p?d_leaf() functions/macros.
For arm64, we already have p?d_sect() macros which we
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For arm pmd_large() already exists and does what we want.
is.
>
> - sed@ -
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool-many-fixes-v2
next-20190722 has them.
Parallely, I opened an CBL issue #617
"drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
.altinstr_replacement+0x86: redundant UAC
On Mon, 2019-07-22 at 08:54 +, Gustavo Pimentel wrote:
>
> >
> > > > +static inline void al_pcie_target_bus_set(struct al_pcie
> > > > *pcie,
> > > > + u8 target_bus,
> > > > + u8 mask_target_bus)
> > > > +{
> >
The generic ARM CPUidle driver includes by mistake.
Remove the topology header include.
Signed-off-by: Lorenzo Pieralisi
Cc: Ulf Hansson
Cc: Sudeep Holla
Cc: Daniel Lezcano
Cc: "Rafael J. Wysocki"
---
drivers/cpuidle/cpuidle-arm.c | 1 -
1 file changed, 1 deletion(-)
diff --git
The PSCI checker currently relies on the generic ARM CPUidle
infrastructure to enter an idle state, which in turn creates
a dependency that is not really needed.
The PSCI checker code to test PSCI CPU suspend is built on
top of the CPUidle framework and can easily reuse the
struct
CPUidle back-end operations are not implemented in some platforms
but this should not be considered an error serious enough to be
logged. Check the arm_cpuidle_init() return value to detect whether
the failure must be reported or not in the kernel log and do
not log it if the platform does not
Current PSCI code handles idle state entry through the
psci_cpu_suspend_enter() API, that takes an idle state index as a
parameter and convert the index into a previously initialized
power_state parameter before calling the PSCI.CPU_SUSPEND() with it.
This is unwieldly, since it forces the PSCI
Current PSCI CPUidle driver is built on top of the generic ARM
CPUidle infrastructure that relies on the architectural back-end
idle operations to initialize and enter idle states.
On ARM64 systems, PSCI is the only interface the kernel ever uses
to enter idle states, so, having to rely on a
Allow selection of the PSCI CPUidle in the kernel by adding
the required Kconfig options.
Remove PSCI callbacks from ARM/ARM64 generic CPU ops
to prevent the PSCI idle driver from clashing with the generic
ARM CPUidle driver initialization, that relies on CPU ops
to initialize and enter idle
PSCI firmware is the standard power management control for
all ARM64 based platforms and it is also deployed on some
ARM 32 bit platforms to date.
Idle state entry in PSCI is currently achieved by calling
arm_cpuidle_init() and arm_cpuidle_suspend() in a generic
idle driver, which in turn relies
John,
On Mon, 22 Jul 2019, John Garry wrote:
> On 22/07/2019 15:41, Marc Zyngier wrote:
> > On 22/07/2019 15:14, John Garry wrote:
> > > I have a question on commit cbf866a6 ("genirq: Let irq thread follow
> > > the effective hard irq affinity"), if you could kindly check:
> > >
> > > Here
On Mon, Jul 22, 2019 at 05:14:26PM +0200, Maksym Planeta wrote:
> Replace tasklets with workqueues in rxe driver.
>
> Ensure that task is called only through a workqueue. This allows to
> simplify task logic.
>
> Add additional dependencies to make sure that cleanup tasks do not
> happen after
In a later patch I need to know if the dependency to QP object still
exists or not.
On 22/07/2019 17:29, Jason Gunthorpe wrote:
On Mon, Jul 22, 2019 at 05:14:23PM +0200, Maksym Planeta wrote:
Used in a later patch.
Signed-off-by: Maksym Planeta
drivers/infiniband/sw/rxe/rxe_pool.c | 3 ++-
On Mon, Jul 22, 2019 at 05:14:23PM +0200, Maksym Planeta wrote:
> Used in a later patch.
>
> Signed-off-by: Maksym Planeta
> drivers/infiniband/sw/rxe/rxe_pool.c | 3 ++-
> drivers/infiniband/sw/rxe/rxe_pool.h | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git
On 7/22/19 8:39 AM, Arnd Bergmann wrote:
On Sun, Jul 21, 2019 at 4:25 PM Masahiro Yamada
wrote:
struct snd_sof_blk_hdr {
enum snd_sof_fw_blk_type type;
- uint32_t size; /* bytes minus this header */
- uint32_t offset;/* offset from base */
+
On 22/07/2019 17:25, Jason Gunthorpe wrote:
On Mon, Jul 22, 2019 at 05:14:20PM +0200, Maksym Planeta wrote:
Need to ensure that kref_put does not run concurrently with the loop
inside rxe_pool_get_key.
Signed-off-by: Maksym Planeta
drivers/infiniband/sw/rxe/rxe_pool.c | 18
On Mon, Jul 22, 2019 at 05:14:21PM +0200, Maksym Planeta wrote:
>
> int rxe_init_task(void *obj, struct rxe_task *task,
> - void *arg, int (*func)(void *), char *name)
> + struct rxe_qp *qp, int (*func)(void *), char *name)
> {
> task->obj = obj;
> -
On Mon, Jul 22, 2019 at 05:14:20PM +0200, Maksym Planeta wrote:
> Need to ensure that kref_put does not run concurrently with the loop
> inside rxe_pool_get_key.
>
> Signed-off-by: Maksym Planeta
> drivers/infiniband/sw/rxe/rxe_pool.c | 18 ++
>
On 22-07-19, 16:44, Arnd Bergmann wrote:
> On Mon, Jul 22, 2019 at 4:36 PM Vinod Koul wrote:
> > On 22-07-19, 16:22, Arnd Bergmann wrote:
> > > On Mon, Jul 22, 2019 at 4:13 PM Vinod Koul wrote:
> > > >
> > > > On 22-07-19, 10:16, Arnd Bergmann wrote:
> > > > > With the audio driver no longer
On Mon, Jul 22, 2019 at 4:26 PM Arnd Bergmann wrote:
>
> On Mon, Jul 22, 2019 at 3:43 PM Alexander Potapenko wrote:
> > On Mon, Jul 22, 2019 at 1:41 PM Arnd Bergmann wrote:
> > >
> > > KASAN_STACK is currently implied by KASAN on gcc, but could be made a
> > > user selectable option if we want
On 7/22/19 8:34 AM, Arnd Bergmann wrote:
On Mon, Jul 22, 2019 at 3:16 PM Pierre-Louis Bossart
wrote:
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,
On Mon, Jul 22, 2019 at 05:03:01PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> This field is unused outside of probe(). There's no need to store it.
> We can make it into a local variable.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Daniel Thompson
> ---
>
Hi all,
In commit
665e985c2f41 ("mmc: meson-mx-sdio: Fix misuse of GENMASK macro")
Fixes tag
Fixes: ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
On Mon, Jul 22, 2019 at 5:18 PM Pierre-Louis Bossart
wrote:
> On 7/22/19 8:34 AM, Arnd Bergmann wrote:
> > On Mon, Jul 22, 2019 at 3:16 PM Pierre-Louis Bossart
> > wrote:
> >> On 7/22/19 7:56 AM, Takashi Iwai wrote:
> >>> On Mon, 22 Jul 2019 14:49:34 +0200,
> >> Our goal is to minimize the
Hi all,
In commit
52db6685932e ("ASoC: simple_card_utils.h: care NULL dai at
asoc_simple_debug_dai()")
Fixes tag
Fixes: commit 0580dde59438 ("ASoC: simple-card-utils: add
asoc_simple_debug_info()")
has these problem(s):
- leading word 'commit' unexpected
In commit
6cd249cfad68
On Mon, Jul 22, 2019 at 08:15:14PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Sun, Jul 21, 2019 at 12:58:46AM -0700, Nathan Chancellor wrote:
> >> 017c clear_user_page:
> >> 17c: 94 21 ff f0 stwu 1, -16(1)
> >> 180: 38 80 00 80
Hello,
syzbot found the following crash on:
HEAD commit:6d21a41b Add linux-next specific files for 20190718
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1377958fa0
kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
On 22/07/2019 15:41, Marc Zyngier wrote:
Hi John,
Hi Marc,
On 22/07/2019 15:14, John Garry wrote:
Hi Thomas,
I have a question on commit cbf866a6 ("genirq: Let irq thread follow
the effective hard irq affinity"), if you could kindly check:
Here we set the thread affinity to be the
[snip]
> > Would it make sense to have call_rcu() check to see if there are many
> > outstanding requests on this CPU and if so process them before returning?
> > That would ensure that frequent callers usually ended up doing their
> > own processing.
Other than what Paul already mentioned about
On Mon, Jul 22, 2019 at 3:27 AM Stephan Gerhold wrote:
>
> Document the new samsung,a3u/a5u-eur and longcheer,l8150
> device tree bindings used in their device trees.
>
> Signed-off-by: Stephan Gerhold
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 8
> 1 file changed, 8
On Mon, Jul 22, 2019 at 3:24 AM Stephan Gerhold wrote:
>
> Add the "longcheer" vendor prefix for Longcheer Technology Co., Ltd.,
> an "industry-leading service provider of mobile phone design
> and product delivery". (http://www.longcheer.com)
>
> Signed-off-by: Stephan Gerhold
> ---
>
On Mon 22 Jul 02:30 PDT 2019, Christoph Hellwig wrote:
> On Mon, Jul 22, 2019 at 10:38:55AM +0200, Marc Gonzalez wrote:
> > > In file included from drivers/firmware/qcom_scm.c:12:0:
> > > ./include/linux/dma-mapping.h:636:21: note: expected ‘dma_addr_t * {aka
> > > long long unsigned int *}’ but
The mlx4_dev_cap and mlx4_init_hca_param are really too large
to be put on the kernel stack, as shown by this clang warning:
drivers/net/ethernet/mellanox/mlx4/main.c:3304:12: error: stack frame size of
1088 bytes in function 'mlx4_load_one' [-Werror,-Wframe-larger-than=]
With gcc, the problem
clang warns about an overly large stack frame in one function
when it decides to inline all __qed_get_vport_*() functions into
__qed_get_vport_stats():
drivers/net/ethernet/qlogic/qed/qed_l2.c:1889:13: error: stack frame size of
1128 bytes in function '_qed_get_vport_stats'
Some functions in the datapath code are factored out so that each
one has a stack frame smaller than 1024 bytes with gcc. However,
when compiling with clang, the functions are inlined more aggressively
and combined again so we get
net/openvswitch/datapath.c:1124:12: error: stack frame size of
clang triggers a warning about oversized stack frames that gcc does not
notice because of slightly different inlining decisions:
ath/wcn36xx/smd.c:1409:5: error: stack frame size of 1040 bytes in function
'wcn36xx_smd_config_bss' [-Werror,-Wframe-larger-than=]
ath/wcn36xx/smd.c:640:5: error:
On Mon, 22 Jul 2019 13:42:02 +0100
Catalin Marinas wrote:
> > I agree with Masami, that the selftest actually caught a bug here. I
> > think the arch code may need to change as the purpose of Masami's
> > changes was to enable kprobes earlier in boot. The selftest failing
> > means that an early
rxkad sometimes triggers a warning about oversized stack frames
when building with clang for a 32-bit architecture:
net/rxrpc/rxkad.c:243:12: error: stack frame size of 1088 bytes in function
'rxkad_secure_packet' [-Werror,-Wframe-larger-than=]
net/rxrpc/rxkad.c:501:12: error: stack frame size
The mdio-bus-mux has no #address-cells/#size-cells property,
which causes a few dtc warnings:
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:129.4-18: Warning (reg_format):
/mdio-bus-mux/mdio@200:reg: property has invalid length (4 bytes)
(#address-cells == 2, #size-cells == 1)
Hi Jonathan,
On 14/7/19 18:32, Jonathan Cameron wrote:
> On Fri, 28 Jun 2019 12:17:08 -0700
> Gwendal Grignou wrote:
>
>> To allow cros_ec iio core library to be used with legacy device, add a
>> vector to rotate sensor data if necessary: legacy devices are not
>> reporting data in
When building a multiplatform kernel that includes armv4 support,
the default target CPU does not support the blx instruction,
which leads to a build failure:
arch/arm/mach-davinci/sleep.S: Assembler messages:
arch/arm/mach-davinci/sleep.S:56: Error: selected processor does not support
`blx ip'
On Mon, Jul 22, 2019 at 4:36 PM Vinod Koul wrote:
> On 22-07-19, 16:22, Arnd Bergmann wrote:
> > On Mon, Jul 22, 2019 at 4:13 PM Vinod Koul wrote:
> > >
> > > On 22-07-19, 10:16, Arnd Bergmann wrote:
> > > > With the audio driver no longer referring to this function, it
> > > > can be made
On Sat, May 4, 2019 at 4:27 PM Greg Ungerer wrote:
> On 4/5/19 3:06 am, Guenter Roeck wrote:
> > On Fri, May 03, 2019 at 08:16:05AM +0100, Linus Walleij wrote:
> >> On Fri, May 3, 2019 at 8:02 AM Greg Ungerer wrote:
> >>> Ultimately though I am left wondering if the ks8695 support in the
> >>>
Hi John,
On 22/07/2019 15:14, John Garry wrote:
> Hi Thomas,
>
> I have a question on commit cbf866a6 ("genirq: Let irq thread follow
> the effective hard irq affinity"), if you could kindly check:
>
> Here we set the thread affinity to be the same as the hard interrupt
> affinity. For an
On 7/22/19 3:17 PM, Paul Kocialkowski wrote:
> 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.
Just gave feedback. A v7 is needed in any case
On 6/14/19 4:38 PM, Paul Kocialkowski wrote:
> This introduces the required definitions for HEVC decoding support with
> stateless VPUs. The controls associated to the HEVC slice format provide
> the required meta-data for decoding slices extracted from the bitstream.
>
> They are not exported to
On Mon, Jul 22, 2019 at 02:26:45PM +, Jose Abreu wrote:
> From: Andrew Lunn
> Date: Jul/22/2019, 15:19:43 (UTC+00:00)
>
> > On Mon, Jul 22, 2019 at 01:58:20PM +, Jose Abreu wrote:
> > > From: Andrew Lunn
> > > Date: Jul/22/2019, 14:40:23 (UTC+00:00)
> > >
> > > > Does this mean that
Hello,
I discussed with Frank and other kernel developers last week at OSSJ 2019.
Eventually, I decided to leave from devicetree, because it can unstabilize
current devicetree desgin and policy. Instead, aim to introduce a new
generic structured kernel cmdline, something like "configtree".
I
Hello,
syzbot found the following crash on:
HEAD commit:6d21a41b Add linux-next specific files for 20190718
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1520015860
kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
Hello,
syzbot found the following crash on:
HEAD commit:3bfe1fc4 Merge tag 'for-5.3/dm-changes-2' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=163c6e5860
kernel config: https://syzkaller.appspot.com/x/.config?x=f8841b9f4365c7de
On 22-07-19, 16:22, Arnd Bergmann wrote:
> On Mon, Jul 22, 2019 at 4:13 PM Vinod Koul wrote:
> >
> > On 22-07-19, 10:16, Arnd Bergmann wrote:
> > > With the audio driver no longer referring to this function, it
> > > can be made private to the dmaengine driver itself, and the
> > > header file
On Mon, Jul 22, 2019 at 10:40 PM Arnd Bergmann wrote:
>
> On Sun, Jul 21, 2019 at 4:25 PM Masahiro Yamada
> wrote:
> >
> > struct snd_sof_blk_hdr {
> > enum snd_sof_fw_blk_type type;
> > - uint32_t size; /* bytes minus this header */
> > - uint32_t offset;/*
On 7/22/19 3:35 PM, Juri Lelli wrote:
> On 22/07/19 15:21, Dietmar Eggemann wrote:
>> 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
On 16-07-19, 19:15, Stefan Wahren wrote:
> During enabling of the RPi 4, we found out that the driver doesn't provide
> a helpful error message in case setting DMA mask fails. So add one.
Applied, thanks
--
~Vinod
On Mon, Jul 22, 2019 at 3:43 PM Alexander Potapenko wrote:
> On Mon, Jul 22, 2019 at 1:41 PM Arnd Bergmann wrote:
> >
> > KASAN_STACK is currently implied by KASAN on gcc, but could be made a
> > user selectable option if we want to allow combining (non-stack) KASAN
> > with
From: Andrew Lunn
Date: Jul/22/2019, 15:19:43 (UTC+00:00)
> On Mon, Jul 22, 2019 at 01:58:20PM +, Jose Abreu wrote:
> > From: Andrew Lunn
> > Date: Jul/22/2019, 14:40:23 (UTC+00:00)
> >
> > > Does this mean that all stmmac variants support 1G? There are none
> > > which just support Fast
...@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux
tags/for-linus-20190722
for you to fetch changes up to b191d6491be67cef2b3fa83015561caca1394ab9:
pidfd: fix a poll race when setting exit_state (2019-07-22 16:02:03 +0200)
/* Summary */
The pidfd polling code suffered from a race condition
On 12-07-19, 11:13, Arnd Bergmann wrote:
> clang-9 points out that there are two variables that depending on the
> configuration may only be used in an ARRAY_SIZE() expression but not
> referenced:
>
> drivers/dma/ste_dma40.c:145:12: error: variable 'd40_backup_regs' is not
> needed and will not
On Mon, Jul 22, 2019 at 9:30 PM Heiko Carstens
wrote:
>
> 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
On 22-07-19, 14:44, Arnd Bergmann wrote:
> 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=]
>
>
601 - 700 of 1164 matches
Mail list logo
