Just provide a weak default definition of dma_contiguous_early_fixup and
let arm override it.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-contiguous.h | 15 ---
arch/arm/mm/dma-mapping.c | 1 -
include/asm-generic/Kbuild| 1 -
include/asm-g
Most of the dma_direct symbols should only be used by direct.c and
mapping.c, so move them to kernel/dma. In fact more of dma-direct.h
should eventually move, but that will require more coordination with
other subsystems.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 106 ---
dma_declare_contiguous is a trivial wrapper around
dma_contiguous_reserve_area and just has a single caller.
Signed-off-by: Christoph Hellwig
---
arch/arm/mach-davinci/devices-da8xx.c | 16 +-
include/linux/dma-contiguous.h| 32 ---
2 files changed, 10
On 2020-09-30, Petr Mladek wrote:
>> Doubling the cost of every single printk by unconditionally doing
>> vsnprintf() twice is a bad idea.
>
> I would prefer to solve this when there are real life problems.
> printk() should not get called in performance sensitive paths in
> the first place.
>
> W
On 9/30/20 10:11 AM, Arnaud POULIQUEN wrote:
>
>
> On 9/29/20 12:17 AM, Rishabh Bhatnagar wrote:
>> Move recovery configuration from debugfs to sysfs.This will
>> allow usage of this configuration feature in production
>> devices where access to debugfs might be limited.
>>
>> Signed-off-by: R
@setup_text_buf only copies the original text messages (without any
prefix or extended text). It only needs to be LOG_LINE_MAX in size.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/print
Hello,
Marek Szyprowski reported [0] a problem with a particular printk
usage. This particular usage performs thousands of LOG_CONT calls.
The printk.c implementation was only limiting the growing record by
the maximum size available in the ringbuffer, thus creating a record
that was several kilob
On 30.09.20 10:52, Stefan Bader wrote:
On 29.09.20 16:05, Jürgen Groß wrote:
On 29.09.20 15:13, Stefan Bader wrote:
On 01.09.20 17:10, Greg Kroah-Hartman wrote:
From: Thomas Gleixner
commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream.
handler data is meant for interrupt handlers and n
If a reader provides a buffer that is smaller than the message text,
the @text_len field of @info will have a value larger than the buffer
size. If readers blindly read @text_len bytes of data without
checking the size, they will read beyond their buffer.
Add this check to record_print_text() to p
On Mon, Sep 28, 2020 at 03:31:28PM +0200, Paul Cercueil wrote:
> It's allocated with dma_alloc_wc, but then it's only accessed as
> non-coherent.
>
> Anyway, for the time being I guess you could revert 37054fc81443. But I
> have patches on top of it in drm-misc-next so it's going to be a mess.
>
Signed-off-by: Billy Tsai
---
arch/arm/boot/dts/aspeed-g6.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index 97ca743363d7..b9ec8b579f73 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot
"On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
>
> From: Dmitry Osipenko
>
> Multiple Tegra drivers need to retrieve Memory Controller and hence there
> is quite some duplication of the retrieval code among the drivers. Let's
> add a new common helper for the retrieval of the MC.
>
> Signed-o
Are you busy now?
I'm sorry, I'm so busy for my full time work :(
Anyway, I'm trying to review serious bug patches or bug reports first.
Other patches, such as clean-up or code refactoring, may take some time to
review.
I'll try to reduce your burden as much as possible.
I am waiting for you
On 2020/9/29 3:45, Nathan Chancellor wrote:
After commit 01feba590cd6 ("ACPI: Do not create new NUMA domains from
ACPI static tables that are not SRAT"):
$ scripts/config --file arch/x86/configs/x86_64_defconfig -d NUMA -e ACPI_NFIT
$ make -skj"$(nproc)" distclean defconfig drivers/acpi/nfit/
d
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Since this flash doesn't have a Profile 1.0 table, the Octal DTR
> capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D
> fast read sett
By using the dmaengine_get_dma_device() to get the device for
dma_api use, the dmatest can support per channel coherency if it is
supported by the DMA controller.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/dmatest.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --g
Hi,
The series have build dependency on ti_sci/soc series (v1):
https://lore.kernel.org/lkml/20200928083429.17390-1-peter.ujfal...@ti.com/
The unmapped event handling in INTA is also needed, but it is not a build
dependency (v2):
https://lore.kernel.org/lkml/20200930074559.18028-1-peter.ujfal...@
If the DMA device supports per channel coherency configuration (a channel
can be configured to have coherent or not coherent view) then a single
device (the DMA controller's device) can not be used for dma_api for all
channels as channels can have different coherency.
Introduce custom_dma_mapping
Client drivers should use the dmaengine_get_dma_device(chan) to get the
device pointer which should be used for DMA API for allocations and
mapping.
Signed-off-by: Peter Ujfalusi
---
Documentation/driver-api/dmaengine/client.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --gi
On 30/09/2020 11:46:06+0300, Alexandru Ardelean wrote:
> On Wed, Sep 30, 2020 at 10:48 AM Alexandre Belloni
> wrote:
> >
> > Hi,
> >
> > On 30/09/2020 09:00:08+0300, Alexandru Ardelean wrote:
> > > Since the driver should be allowed to build without OF support, the
> > > of_match_ptr() is redundan
Set the TDTYPE if it is supported on the platform (j721e) which will cause
UDMAP to wait for the remote peer to finish the teardown before returning
the teardown completed message.
Signed-off-by: Peter Ujfalusi
Tested-by: Keerthy
Reviewed-by: Grygorii Strashko
---
drivers/dma/ti/k3-udma.c | 12
Additional fields needed for K3 PKTDMA to be able to handle the mapped
channels (channels are locked to handle specific threads) and flow ranges
for these mapped threads.
PKTDMA also introduces tflow for tx channels which can not be found in
K3 UDMA architecture.
Signed-off-by: Peter Ujfalusi
---
Additional configuration for the DMA event router might be needed for a
channel which can not be done during device_alloc_chan_resources callback
since the router information is not yet present for the drivers.
If there is a need for additional configuration for the channel if DMA
router is in use
Rings in RING mode should be using the DMA device for DMA API as in this
mode the ringacc will not access the ring memory in any ways, but the DMA
is.
Fix up the ring configuration and set the dma_dev unconditionally and let
the ringacc driver to select the correct device to use for DMA API.
Sign
From: Grygorii Strashko
The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a
separate and generic ringacc is used.
The ring SW interface is similar to ringacc with some major architectural
differences, like
They are part of the DMA (BCDMA or PKTDMA).
They are dual mode ri
In k3 architecture a DMA channel (in TR momde) can be triggered by global
events, origination from different modules.
The events for triggers can be sent from any module which is connected to
PSI-L fabric, but the event number to be sent is DMA channel specific, it
is only known after the channel
New binding document for
Texas Instruments K3 Packet DMA (PKTDMA).
PKTDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-pktdma.yaml | 189 ++
1 file changed, 189 insertions(+)
create mode 100644 Documentation/devicetree/bindi
New binding document for
Texas Instruments K3 Block Copy DMA (BCDMA).
BCDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-bcdma.yaml | 183 ++
1 file changed, 183 insertions(+)
create mode 100644 Documentation/devicetree/bin
One of the DMAs introduced with AM64 is the Packet DMA (PKTDMA).
It serves similar purpose as K3 UDMAP channels in packet mode, but with
notable differences, like tflow support and channels being allocated to
service specific peripherals.
The rings for the PKTDMA is integrated within the DMA itself
Add initial PSI-L map file for AM64.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/Makefile | 3 +-
drivers/dma/ti/k3-psil-am64.c | 75 +++
drivers/dma/ti/k3-psil-priv.h | 1 +
drivers/dma/ti/k3-psil.c | 1 +
4 files changed, 79 insertions(+), 1 d
Unlike UDMAP the BCDMA defines the channel TPL levels per channel type.
In UDMAP the number of high and ultra-high channels applies to both tchan
and rchan.
BCDMA defines the TPL per channel types: bchan, tchan and rchan can have
different number of high and ultra-high channels.
In order to suppo
Glue layer users should use the device of the DMA for DMA mapping and
allocations as it is the DMA which accesses to descriptors and buffers,
not the clients
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 14 ++
drivers/dma/ti/k3-udma-private.c | 6 ++
driv
One of the DMAs introduced with AM64 is the Block Copy DMA (BCDMA).
It serves similar purpose as K3 UDMAP channels in TR mode.
The rings for the BCDMA is integrated within the DMA itself instead of
using rings from the general purpose ringacc.
A BCDMA have two different type of channels:
- Block
Resource allocation via sysfw can use up to two ranges per resource subtype
to support more complex resource assignment, mainly for DMA channels.
Take the second range also into consideration when setting up the maps for
available resources.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-u
From: Vignesh Raghavendra
This commit adds support for PKTDMA in k3-udma glue driver. Use new
psil_endpoint_config struct to get static data for a given channel or a
flow during setup. Make sure that the RX flows being mapped to a RX
channel is within the range of flows that is been allocated to
* Trent Piepho [200930 08:35]:
> The closest thing would be the generic pin config type bindings, which
> go in the pinctrl driver's nodes, and look like this:
> &am335x_pinmux {
> pinctrl_yoyo_reset: yoyogrp {
> pins = "foo";
> function = "gpio";
> bias-pull-up;
>
On Wed, Sep 30, 2020 at 07:08:23AM +0800, Boqun Feng wrote:
> I think there are two problems here:
>
> 1) the "(null)" means we don't have the "usage_str" for a usage bit,
> which I think is the LOCK_USED_READ bit introduced by Peter at
> 23870f122768 ('locking/lockdep: Fix "USED" <- "IN-NMI" inve
Since commit c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to
store a per interrupt XEN data pointer which contains XEN specific
information.")
Xen is using the chip_data pointer for storing IRQ specific data. When
running as a HVM domain this can result in problems for legacy IR
Peter Zijlstra 于2020年9月30日周三 下午4:20写道：
>
> On Wed, Sep 30, 2020 at 10:47:12AM +0800, qianjun.ker...@gmail.com wrote:
> > From: jun qian
> >
> > When the sched_schedstat changes from 0 to 1, some sched se maybe
> > already in the runqueue, the se->statistics.wait_start will be 0.
> > So it will le
On Tue, Sep 29, 2020 at 03:06:22PM +0100, Matthew Wilcox wrote:
> On Tue, Sep 29, 2020 at 10:26:22AM +0300, Mike Rapoport wrote:
> > This sentence presumes existing description/prior knowledge about
> > put_page().
> >
> > Maybe
> >
> > This function can free multi-page allocations that were no
On Wed, Sep 30, 2020 at 08:35:56AM +0200, Mauro Carvalho Chehab wrote:
> There are several :c:type: definitions there, in order to
> do cross-references with the driver's documentation.
>
> Those are broken when docs are built with Sphinx 3.x, as
> it would require :c:struct: instead.
>
> For Sph
On Wed, Sep 30, 2020 at 10:16:40AM +0200, Marcel Holtmann wrote:
> Hi Greg,
>
> I wrote a simple script "sco_features.pl" which show all supported
> codecs by local HCI bluetooth adapter. Script is available at:
>
> https://github.com/pali/hsphfpd-prototype/blo
On Wed, Sep 30, 2020 at 10:25:34AM +0200, Pali Rohár wrote:
> On Wednesday 30 September 2020 10:02:05 Greg Kroah-Hartman wrote:
> > On Tue, Sep 29, 2020 at 11:32:54PM +0200, Pali Rohár wrote:
> > > CCing other lists and maintainers, hopefully, somebody would have a time
> > > to look at it...
> >
Hi Uwe,
thank you for your review!
On Wed, Sep 30, 2020 at 08:57:26AM +0200, Uwe Kleine-König wrote:
> Hello Lars,
>
> On Tue, Sep 29, 2020 at 02:19:53PM +0200, poesc...@lemonage.de wrote:
> > From: Lars Poeschel
> >
> > This adds a class to exported pwm devices.
> > Exporting a pwm through sy
On Wed, Sep 30, 2020 at 04:14:59PM +0800, Pujin Shi wrote:
> 'ret' variable is now defined but not used in mvebu_uart_probe(),
> causing this warning:
>
> drivers/tty/serial/mvebu-uart.c: In function ‘mvebu_uart_probe’:
> drivers/tty/serial/mvebu-uart.c:806:6: warning: unused variable ‘ret’
>
On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
>
> Previously the driver relies on bus_set_iommu() in .probe() to call
> in .probe_device() function so each client can poll iommus property
> in DTB to configure fwspec via tegra_smmu_configure(). According to
> the comments in .probe(), this is
Hi Lars,
thanks for working on this!
On Sun, Sep 13, 2020 at 9:11 PM Lars Povlsen wrote:
> > What I do not understand is why this GPIO controller is placed in the
> > bindings of the pin controllers? Do you plan to add pin control
> > properties to the bindings in the future?
>
> I have made pr
The NXP PCAL9554B is a variant of the PCA953x GPIO expander,
with 8 GPIOs, latched interrupts and some advanced configuration
options. The "C" version only differs in I2C address.
This adds the entry to the devicetree bindings.
Signed-off-by: Mike Looijmans
---
v2: Split devicetree and code into
The NXP PCAL9554B is a variant of the PCA953x GPIO expander,
with 8 GPIOs, latched interrupts and some advanced configuration
options. The "C" version only differs in I2C address.
Signed-off-by: Mike Looijmans
---
v2: Split devicetree and code into separate patches
drivers/gpio/gpio-pca953x.c |
>
>
>On 20-09-28 14:27:39, Pawel Laszczak wrote:
>> Patch defines macros, registers and structures used by
>> Device side driver.
>>
>> Because the size of main patch is very big, I’ve decided to create
>> separate patch for gadget.h. It should simplify reviewing the code.
>>
>> Signed-off-by: Pawe
Hi, Alexander
在 2020年09月24日 20:46, Alexander Egorenkov 写道:
> The offset of the field 'init_uts_ns.name' has changed
> since
>
> commit 9a56493f6942c0e2df1579986128721da96e00d8
> Author: Kirill Tkhai
> Date: Mon Aug 3 13:16:21 2020 +0300
>
> uts: Use generic ns_common::count
>
> Link:
>
On Tue 29-09-20 18:25:14, Uladzislau Rezki wrote:
> > > I look at it in scope of GFP_ATOMIC/GFP_NOWAIT issues, i.e. inability
> > > to provide a memory service for contexts which are not allowed to
> > > sleep, RCU is part of them. Both flags used to provide such ability
> > > before but not anymor
On Tue, 29 Sep 2020 at 16:48, Alexei Starovoitov
wrote:
...
> There was a warning. I noticed it while applying and fixed it up.
> Lorenz, please upgrade your compiler. This is not the first time such
> warning has been missed.
I tried reproducing this on latest bpf-next (b0efc216f577997) with g
On Tue, Sep 29, 2020 at 3:14 PM Andy Shevchenko
wrote:
> Linus, are you referencing to [3]? It was fixed in GENMASK()
> implementation some time ago.
> [3]: https://lore.kernel.org/lkml/202006171559.jsbgjxnw%25...@intel.com/
Yup.
I tried to apply the patches again now to test it but now patch 2
On Wed, Sep 30, 2020 at 10:13:42AM +0300, Tali Perry wrote:
> Systems that can dinamically add and remove slave devices
dynamically
> often need to change the bus speed in runtime.
> This patch exposes the bus frequency to the user.
Expose the bus frequency to the user.
> This feature can also
On Tue, Sep 29, 2020 at 06:29:24PM +0200, Ansuel Smith wrote:
> Qcom L2 Krait CPUs use the generic cpufreq-dt driver and doesn't actually
> scale the Cache frequency when the CPU frequency is changed. This
> devfreq driver register with the cpu notifier and scale the Cache
> based on the max Freq a
Armv8.3 extends the SPE by adding:
- Alignment field in the Events packet, and filtering on this event
using PMSEVFR_EL1.
- Support for the Scalable Vector Extension (SVE).
The main additions for SVE are:
- Recording the vector length for SVE operations in the Operation Type
packet. It is not
Hi Miquel,
On 28/9/2020 10:25 pm, Miquel Raynal wrote:
Hello,
"Ramuthevar,Vadivel MuruganX"
wrote on Thu, 24 Sep 2020
16:48:40 +0800:
This patch adds the new IP of Nand Flash Controller(NFC) support
on Intel's Lightning Mountain(LGM) SoC.
DMA is used for burst data transfer operation, also
On Tue, Sep 29, 2020 at 4:02 PM Rob Herring wrote:
> On Tue, Sep 29, 2020 at 01:54:44PM +0200, Linus Walleij wrote:
> > On Sun, Sep 20, 2020 at 9:59 PM Krzysztof Kozlowski wrote:
> >
> > > The i.MX 7ULP DTSes use two compatibles so update the binding to fix
> > > dtbs_check warnings like:
> > >
>
On Wed, Sep 30, 2020 at 2:15 AM Tony Lindgren wrote:
>
> * Trent Piepho [200930 08:35]:
> > The closest thing would be the generic pin config type bindings, which
> > go in the pinctrl driver's nodes, and look like this:
> > &am335x_pinmux {
> > pinctrl_yoyo_reset: yoyogrp {
> > pins
On 9/21/20 4:54 PM, Ivan Mikhaylov wrote:
> Some chips like macronix don't have TB(Top/Bottom protection)
> bit in the status register. Do not write tb_mask inside status
> register, unless SPI_NOR_HAS_TB is present for the chip.
>
Not entirely accurate.. Macronix chips have TB bit in config r
>
>
>On 20-09-28 14:27:35, Pawel Laszczak wrote:
>> Patch splits file core.c into core.c containing the common reusable code
>> and cnd3-plat.c containing device platform specific code. These changes
>
>cdns3-plat.c
>
>Pawel, at 5.10-rc1, there are some cdns3 driver updates at Felipe's
>next tree,
On Tue, 29 Sep 2020 at 18:23, Martin KaFai Lau wrote:
...
> > Yeah, I think so. We'd need to do something similar to your
> > sock_common work for PTR_TO_RDONLY_BUF_OR_NULL. The fact that the
> > pointer is read only makes it a bit more difficult I think. After
> I thought the key arg should be
On 2020-03-17 10:21 p.m., Jason Ekstrand wrote:
Explicit synchronization is the future. At least, that seems to be what
most userspace APIs are agreeing on at this point. However, most of our
Linux APIs (both userspace and kernel UAPI) are currently built around
implicit synchronization with dm
Tested on Xiaomi Redmi Note 7 (lavender), SDM660
Tested-by: Alexey Minnekhanov
On 9/26/20 4:11 PM, khol...@gmail.com wrote:
> From: Konrad Dybcio
>
> QUSB on these SoCs actually uses *almost* the same
> configuration that msm8996 does, so we can reuse
> the phy_cfg from there with just a single
在 2020/9/30 16:53, Linus Walleij 写道:
On Mon, Sep 21, 2020 at 3:10 PM Qinglang Miao wrote:
Simplify the return expression.
Signed-off-by: Qinglang Miao
This patch does not apply to the pinctrl "devel" branch, please
rebase and resend, include Sean's ACK.
https://git.kernel.org/pub/scm/li
Hi,
On 9/21/20 4:54 PM, Ivan Mikhaylov wrote:
> Add locks for whole macronix chip series with BP0-2 and BP0-3 bits.
>
> Tested with mx25l51245g(BP0-3).
Since you have only tested on flash that have 4bit BP, please don't
modify flashes that have 3bit BP. Lets be conservative and enable only
thing
On Wed, Sep 30, 2020 at 11:21 AM Mike Looijmans wrote:
>
> The NXP PCAL9554B is a variant of the PCA953x GPIO expander,
> with 8 GPIOs, latched interrupts and some advanced configuration
> options. The "C" version only differs in I2C address.
>
> This adds the entry to the devicetree bindings.
>
>
On Wed, Sep 30, 2020 at 11:21 AM Mike Looijmans wrote:
>
> The NXP PCAL9554B is a variant of the PCA953x GPIO expander,
> with 8 GPIOs, latched interrupts and some advanced configuration
> options. The "C" version only differs in I2C address.
>
> Signed-off-by: Mike Looijmans
> ---
Reviewed-by:
On Sat, Sep 19, 2020 at 10:10 PM Drew Fustini wrote:
> Document the values in pinctrl-single,pins when #pinctrl-cells = <2>
>
> Fixes: 27c90e5e48d0 ("ARM: dts: am33xx-l4: change #pinctrl-cells from 1 to 2")
> Reported-by: Trent Piepho
> Link: https://lore.kernel.org/linux-omap/3139716.CMS8C0sQ7x
Hello,
I added Greg Kroah-Hartman who I discussed this with via irc a bit to
Cc:.
On Wed, Sep 30, 2020 at 11:20:56AM +0200, Lars Poeschel wrote:
> thank you for your review!
>
> On Wed, Sep 30, 2020 at 08:57:26AM +0200, Uwe Kleine-König wrote:
> > On Tue, Sep 29, 2020 at 02:19:53PM +0200, poesc.
RMI4 F3A supports the touchpad GPIO function, it's designed to support
more GPIOs and used on newer touchpads. The patches add support of
touchpad buttons and rename f30_data to avoid confusion.
Changes in v2:
- Combined patch 1 and 2 of v1 to fix bisectability.
Changes in v3:
- Fix indentations
RMI4 F3A supports the touchpad GPIO function, it's designed to
support more GPIOs and used on newer touchpads. This patch adds
support of the touchpad buttons.
Signed-off-by: Vincent Huang
Reviewed-by: Hans de Goede
Tested-by: Hans de Goede
---
drivers/input/rmi4/Kconfig | 8 ++
drivers
On Wed, Sep 30, 2020 at 10:23:49AM +0800, ChiYuan Huang wrote:
>Due to that already merged into your regulator for-next git, may I
> send the patch to fix Rob's comment?
Of course, yes please.
> And I also found one line need to be added into rtmv20 probe phase.
> Please check below.
>
f30_data in rmi_device_platform_data could be also referenced by RMI
function 3A, so rename it and the structure name to avoid confusion.
Signed-off-by: Vincent Huang
Reviewed-by: Hans de Goede
Tested-by: Hans de Goede
---
drivers/hid/hid-rmi.c | 2 +-
drivers/input/mouse/synaptics.
On (20/09/30 11:07), John Ogness wrote:
[..]
> @@ -1389,6 +1391,9 @@ bool prb_reserve_in_last(struct prb_reserved_entry *e,
> struct printk_ringbuffer
> if (!data_check_size(&rb->text_data_ring, r->text_buf_size))
> goto fail;
>
> + if (r->text_buf
On Wednesday 30 September 2020 11:20:43 Greg Kroah-Hartman wrote:
> On Wed, Sep 30, 2020 at 10:25:34AM +0200, Pali Rohár wrote:
> > On Wednesday 30 September 2020 10:02:05 Greg Kroah-Hartman wrote:
> > > On Tue, Sep 29, 2020 at 11:32:54PM +0200, Pali Rohár wrote:
> > > > CCing other lists and maint
On Wed, Sep 30, 2020 at 11:21:14AM +0200, Krzysztof Kozlowski wrote:
> On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
> >
> > Previously the driver relies on bus_set_iommu() in .probe() to call
> > in .probe_device() function so each client can poll iommus property
> > in DTB to configure fwspe
* Trent Piepho [200930 09:34]:
> On Wed, Sep 30, 2020 at 2:15 AM Tony Lindgren wrote:
> >
> > * Trent Piepho [200930 08:35]:
> > > The closest thing would be the generic pin config type bindings, which
> > > go in the pinctrl driver's nodes, and look like this:
> > > &am335x_pinmux {
> > > p
On Wed, Sep 30, 2020 at 11:07:32AM +0200, Krzysztof Kozlowski wrote:
> "On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
> >
> > From: Dmitry Osipenko
> >
> > Multiple Tegra drivers need to retrieve Memory Controller and hence there
> > is quite some duplication of the retrieval code among the d
On Wed, Sep 30, 2020 at 11:39 AM miaoqinglang wrote:
> I tried to rebase this patch to the pinctrl "devel" branch but there's
> no conflict. Could you please try again or show me some details?
If you used "git rebase" this might work for you because the git tree
can do a more intelligent rebase
Hi,
A GE phy supports pad isolation which can save power in WOL mode. But once the
isolation is enabled, the MAC can't send/receive pkts to/from the phy because
the phy is "isolated". To make the PHY work normally, I need to move the
enabling isolation to suspend hook, so far so good. But the isol
On Wednesday 30 September 2020 11:20:20 Greg Kroah-Hartman wrote:
> On Wed, Sep 30, 2020 at 10:16:40AM +0200, Marcel Holtmann wrote:
> > Hi Greg,
> >
> > I wrote a simple script "sco_features.pl" which show all supported
> > codecs by local HCI bluetooth adapter. Script is availa
On Wed, Sep 30, 2020 at 11:16:11AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 30, 2020 at 07:08:23AM +0800, Boqun Feng wrote:
> > I think there are two problems here:
> >
> > 1) the "(null)" means we don't have the "usage_str" for a usage bit,
> > which I think is the LOCK_USED_READ bit introduced
On Wed, Sep 30, 2020 at 11:21 AM Mike Looijmans wrote:
> The NXP PCAL9554B is a variant of the PCA953x GPIO expander,
> with 8 GPIOs, latched interrupts and some advanced configuration
> options. The "C" version only differs in I2C address.
>
> This adds the entry to the devicetree bindings.
>
>
On Wed, Sep 30, 2020 at 11:21 AM Mike Looijmans wrote:
> The NXP PCAL9554B is a variant of the PCA953x GPIO expander,
> with 8 GPIOs, latched interrupts and some advanced configuration
> options. The "C" version only differs in I2C address.
>
> Signed-off-by: Mike Looijmans
> ---
> v2: Split dev
On Wed, Sep 30, 2020 at 11:41:46AM +0200, Uwe Kleine-König wrote:
> Hello,
>
> I added Greg Kroah-Hartman who I discussed this with via irc a bit to
> Cc:.
>
> On Wed, Sep 30, 2020 at 11:20:56AM +0200, Lars Poeschel wrote:
> > thank you for your review!
> >
> > On Wed, Sep 30, 2020 at 08:57:26AM
On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
> On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
> > @@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct ib_device
> > *device,
> > goto umem_release;
> >
> > cur_base +
On Wed, Sep 30, 2020 at 03:11:51AM -0400, Peilin Ye wrote:
> On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 29, 2020 at 2:34 PM Peilin Ye wrote:
> > > It seems that users don't use `console_font` directly, they use
> > > `console_font_op`. Then, in TTY:
> >
> > Wow
On Wed, Sep 30, 2020 at 11:39:06AM +0200, Michel Dänzer wrote:
> On 2020-03-17 10:21 p.m., Jason Ekstrand wrote:
> > Explicit synchronization is the future. At least, that seems to be what
> > most userspace APIs are agreeing on at this point. However, most of our
> > Linux APIs (both userspace a
On Wed, Sep 30, 2020 at 11:01:27AM +0300, Kalle Valo wrote:
> Leon Romanovsky writes:
>
> >> diff --git a/drivers/net/wireless/purelifi/Kconfig
> > b/drivers/net/wireless/purelifi/Kconfig
> >> new file mode 100644
> >> index ..ff05eaf0a8d4
> >> --- /dev/null
> >> +++ b/drivers/net/wire
Since commit 79dfdaccd1d5 ("memcg: make oom_lock 0 and 1 based rather than
counter"), the mem_cgroup_unmark_under_oom() is added and the comment of
the mem_cgroup_oom_unlock() is moved here. But this comment make no sense
here because mem_cgroup_oom_lock() does not operate on under_oom field. So
w
Friendly ping :)
> When bio_add_hw_page() failed, we left page reference still held in pages
> from iov_iter_get_pages(). Release these references and also advance the
> iov_iter according to what we have done successfully yet.
>
> Fixes: 0512a75b98f8 ("block: Introduce REQ_OP_ZONE_APPEND")
> Re
On Wed, Sep 30, 2020 at 05:16:29PM +0800, jun qian wrote:
> Peter Zijlstra 于2020年9月30日周三 下午4:20写道：
> >
> > On Wed, Sep 30, 2020 at 10:47:12AM +0800, qianjun.ker...@gmail.com wrote:
> > > From: jun qian
> > >
> > > When the sched_schedstat changes from 0 to 1, some sched se maybe
> > > already in
Friendly ping :)
> Correct the wrong param name @addr to @p.
>
> Signed-off-by: Miaohe Lin
> ---
> include/asm-generic/bitops/lock.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/asm-generic/bitops/lock.h
> b/include/asm-generic/bitops/lock.h
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> Hi,
Hello,
>
> This series adds support for Octal DTR flashes in the SPI NOR framework,
> and then adds hooks for the Cypress Semper and Micron Xcella flashes to
> allow running them in Octal DTR mode. This series assumes that the flash
> is handed to
This is based on v5.9-rc7, before "other architectures support" patches
starting pouring in.
Currently objtool seems to be the only tool from build tools needed
which breaks x86 cross compilation on big endian systems.
But besides x86 cross compilation, endianness awareness is also needed
for big
From: Martin Schwidefsky
Make the x86 instruction decoder of the objtool usable on big endian
machines. This is useful for compile tests on non x86, big endian
hardware.
Co-developed-by: Vasily Gorbik
[ gor: more endianness problems findings fixes / rebasing ]
Signed-off-by: Martin Schwidefsky
Hi Sami,
On Tue, Sep 29, 2020 at 02:46:11PM -0700, Sami Tolvanen wrote:
> Select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY to disable
> recordmcount when DYNAMIC_FTRACE_WITH_REGS is selected.
Could you please add an explanation as to /why/ this is necessary in the
commit message? I couldn't figu
Correct objtool orc generation endianness problems to enable fully
functional x86 cross compiles on big endian hardware.
Signed-off-by: Vasily Gorbik
---
arch/x86/include/asm/orc_types.h | 24
tools/arch/x86/include/asm/orc_types.h | 24
to
1 - 100 of 1591 matches
Mail list logo
