Add the bindings and driver changes for DSP support on the
SM8650 platform in order to enable the aDSP, cDSP and MPSS
subsystems to boot.
Compared to SM8550, where SM8650 uses the same dual firmware files,
(dtb file and main firmware) the memory zones requirement has changed:
- cDSP: now requires
On 12/4/2023 3:54 PM, Luca Weiss wrote:
This patch adds UFS host controller and Phy nodes for Qualcomm sc7280
SoC and enable it on some sc7280-based boards.
Pick up the patchset from Nitin since the last revision (v4) has been
sent end of September and is blocking qcm6490-fairphone-fp5 UFS.
This patch adds UFS host controller and Phy nodes for Qualcomm sc7280
SoC and enable it on some sc7280-based boards.
Pick up the patchset from Nitin since the last revision (v4) has been
sent end of September and is blocking qcm6490-fairphone-fp5 UFS.
---
Changes in v5:
- Try to get patch tags
On Thu, 27 Jul 2023 19:33:20 +0200, Konrad Dybcio wrote:
> Resending as the previous revision was mostly ignored on the rproc side.
>
> Changes since v3:
> - Pick up krzk's rb on bindings
> - Drop patch 4 (applied)
> Link to v3:
>
On 4/16/21 1:30 PM, Aswath Govindraju wrote:
> The following series of patches add support for CAN transceivers.
>
> TCAN1042 has a standby signal that needs to be pulled high for
> sending/receiving messages[1]. TCAN1043 has a enable signal along with
> standby signal that needs to be pulled up
The following series of patches add support for CAN transceivers.
TCAN1042 has a standby signal that needs to be pulled high for
sending/receiving messages[1]. TCAN1043 has a enable signal along with
standby signal that needs to be pulled up for sending/receiving
messages[2], and other
Add support for Xilinx ZynqMP pinctrl driver and also update
the Xilinx firmware driver to support pinctrl functionality.
This driver queries the pin information from the firmware and
allow configuring the pins as per the request.
changes in v5:
- Used generic property 'power-source' instead of
On Tue, Apr 13, 2021 at 04:15:03PM +0530, Mitali Borkar wrote:
> On Tue, Apr 13, 2021 at 09:52:48AM +0200, Greg KH wrote:
> > On Tue, Apr 13, 2021 at 08:55:03AM +0530, Mitali Borkar wrote:
> > > Changes from v4:-
> > > [PATCH v4 1/3]:- No changes.
> > > [PATCH v4 2/3]:- No changes.
> > > [PATCH V4
On Tue, Apr 13, 2021 at 09:52:48AM +0200, Greg KH wrote:
> On Tue, Apr 13, 2021 at 08:55:03AM +0530, Mitali Borkar wrote:
> > Changes from v4:-
> > [PATCH v4 1/3]:- No changes.
> > [PATCH v4 2/3]:- No changes.
> > [PATCH V4 3/3]:- Removed casts and parentheses.
>
> This series does not apply
On Tue, Apr 13, 2021 at 08:55:03AM +0530, Mitali Borkar wrote:
> Changes from v4:-
> [PATCH v4 1/3]:- No changes.
> [PATCH v4 2/3]:- No changes.
> [PATCH V4 3/3]:- Removed casts and parentheses.
This series does not apply cleanly, please rebase and resend.
thanks,
greg k-h
Changes from v4:-
[PATCH v4 1/3]:- No changes.
[PATCH v4 2/3]:- No changes.
[PATCH V4 3/3]:- Removed casts and parentheses.
Changes from v3:- Changed subject line to match prefix on the patches.
[PATCH v3 1/3]:- No changes.
[PATCH v3 2/3]:- No changes.
[PATCH V3 3/3]:- No changes.
Changes from
I decided to split sv48 support in small series to ease the review.
This patchset pushes the kernel mapping (modules and BPF too) to the last
4GB of the 64bit address space, this allows to:
- implement relocatable kernel (that will come later in another
patchset) that requires to move the
This patchset adds Hycon vendor, HY46XX touchscreen controller driver
and its .yaml binding.
---
V1->V2:
* changed authorship and SoBs to @benettiengineering.com domain
* fixed vendor commit log according to Jonathan Neuschäfer's suggestion
* fixed hy46xx bindings according to Rob Herring's
This patch series is to fix a few issues found during patch review and
testing on Linux, also including a patch to explictly disable CET support
in nested guest over Hyper-V(s).
change in v5:
- Changed condition to snapshot CET state to vmcs01 per Sean's feedback.
- Remove mixed fix code for MPX.
Hi folks,
I split up the extra misfit patches from v3 as I'm still playing around with
those following Vincent's comments. In the meantime, I believe the first few
patches of the series can still be considered as standalone.
o Patch 1 prevents pcpu kworkers from causing group_imbalanced
o Patch
On Mon, 22 Mar 2021 00:51:37 +0100, Michael Walle wrote:
> This patchset implements the MTD OTP functions to allow access to the SPI
> OTP data. Specific support is added for Winbond flash chips.
>
> In the past there was already an attempt by Rahul Bedarkar to add this, but
> there was no
Hello everyone,
This is the fifth version of the series adding support for the Techwell
TW9900 multi standard decoder. It's a pretty simple decoder compared to
the TW9910, since it doesn't have a built-in scaler/crop engine.
this fifth version addresses reviews by Hans and Rob, with the notable
changes v5:
- remove type for the settling-time-us property
changes v4:
- spell fixes
- add more comments
- make code more readable
- move scan_buf to the priv
- use FIELD_GET to extract ADC data
- make some multi line code as one line
- do not use atomic API for trig_more_count
- fix build
This patchset implements the MTD OTP functions to allow access to the SPI
OTP data. Specific support is added for Winbond flash chips.
In the past there was already an attempt by Rahul Bedarkar to add this, but
there was no response. These patches are slightly based on his work.
Hi Miquel,
On Wed, Mar 17, 2021 at 03:51:21PM +0100, Miquel Raynal wrote:
> Hi Manivannan,
>
> Manivannan Sadhasivam wrote on Wed,
> 17 Mar 2021 17:55:10 +0530:
>
> > On a typical end product, a vendor may choose to secure some regions in
> > the NAND memory which are supposed to stay intact
Hi Manivannan,
Manivannan Sadhasivam wrote on Wed,
17 Mar 2021 17:55:10 +0530:
> On a typical end product, a vendor may choose to secure some regions in
> the NAND memory which are supposed to stay intact between FW upgrades.
> The access to those regions will be blocked by a secure element
On a typical end product, a vendor may choose to secure some regions in
the NAND memory which are supposed to stay intact between FW upgrades.
The access to those regions will be blocked by a secure element like
Trustzone. So the normal world software like Linux kernel should not
touch these
A bus lock [1] is acquired through either split locked access to
writeback (WB) memory or any locked access to non-WB memory. This is
typically >1000 cycles slower than an atomic operation within
a cache line. It also disrupts performance on other cores.
Although split lock can be detected by #AC
On Thu, 11 Mar 2021 15:33:40 +0100, Jan Kiszka wrote:
> Changes in v4:
> - dropped spidev node
> - rebased over ti-k3-dts-next
>
> Jan
>
> Jan Kiszka (3):
> dt-bindings: Add Siemens vendor prefix
> dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
> arm64: dts: ti: Add
Changes in v4:
- dropped spidev node
- rebased over ti-k3-dts-next
Jan
Jan Kiszka (3):
dt-bindings: Add Siemens vendor prefix
dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
arm64: dts: ti: Add support for Siemens IOT2050 boards
.../devicetree/bindings/arm/ti/k3.yaml
The following series of patches
- Add support for GPIO subsystem in main and wakeup domains.
- Add voltage regulator device tree nodes and their corresponding pinmux
to support power cycle and voltage switch required for UHS-I modes
- sets respective tags in sdhci0 node to support higher speeds
On Mon, 8 Mar 2021 16:26:58 +0100
Janosch Frank wrote:
> On 3/8/21 4:19 PM, Christian Borntraeger wrote:
> > On 02.03.21 18:44, Claudio Imbrenda wrote:
> >> The current handling of the MVPG instruction when executed in a
> >> nested guest is wrong, and can lead to the nested guest hanging.
>
On 3/8/21 4:19 PM, Christian Borntraeger wrote:
> On 02.03.21 18:44, Claudio Imbrenda wrote:
>> The current handling of the MVPG instruction when executed in a nested
>> guest is wrong, and can lead to the nested guest hanging.
>>
>> This patchset fixes the behaviour to be more architecturally
On 02.03.21 18:44, Claudio Imbrenda wrote:
The current handling of the MVPG instruction when executed in a nested
guest is wrong, and can lead to the nested guest hanging.
This patchset fixes the behaviour to be more architecturally correct,
and fixes the hangs observed.
v4->v5
* split
The current handling of the MVPG instruction when executed in a nested
guest is wrong, and can lead to the nested guest hanging.
This patchset fixes the behaviour to be more architecturally correct,
and fixes the hangs observed.
v4->v5
* split kvm_s390_logical_to_effective so it can be reused
Some Atmel maXTouch controllers, like mXT1386 and mXT3432S1 for example,
have a WAKE line that needs to be asserted in order to wake controller
from a deep sleep, otherwise it will be unusable. This series implements
support for the wakeup methods in accordance to the mXT1386 datasheet [1],
see
v5:
-Update commit text for "clear devices when moving execution environments" patch
-Added test platform details that were missed out in the cover letter
-Merged two if checks in to a single one for EE serialization patch
v4:
-Addressed review comments for additional info logging for EE
This is an optimization of a set of sgx-related codes, each of which
is independent of the patch. Because the second and third patches have
conflicting dependencies, these patches are put together.
---
v5 changes:
* Remove the two patches with no actual value
* Typo fix in commit message
v4
The existed pGp shows the names of page flags only, rather than the full
information including section, node, zone, last cpuipid and kasan tag.
While it is not easy to parse these information manually because there
are so many flavors. We'd better interpret them in printf.
To be compitable with
This series provides the Microchip Sparx5 Switch Reset Driver
The Sparx5 Switch SoC has a number of components that can be reset
individually, but at least the Switch Core needs to be in a well defined
state at power on, when any of the Sparx5 drivers starts to access the
Switch Core, this reset
Moving a bunch of folks + lists to BCC.
On Thu, Feb 4, 2021 at 3:54 PM Andrii Nakryiko
wrote:
>
> On Wed, Feb 3, 2021 at 7:13 PM Nick Desaulniers
> wrote:
> >
> > On Wed, Feb 3, 2021 at 6:58 PM Andrii Nakryiko
> > wrote:
> > >
> > > On Wed, Feb 3, 2021 at 5:31 PM Nick Desaulniers
> > >
On Wed, Feb 3, 2021 at 7:13 PM Nick Desaulniers wrote:
>
> On Wed, Feb 3, 2021 at 6:58 PM Andrii Nakryiko
> wrote:
> >
> > On Wed, Feb 3, 2021 at 5:31 PM Nick Desaulniers
> > wrote:
> > >
> > > On Sun, Jan 17, 2021 at 12:14 PM Arnaldo Carvalho de Melo
> > > wrote:
> > > >
> > > > Em Fri, Jan
Hi
This series, building on top of the recently introduced SCMI System Power
Protocol support, adds a new SCMI driver which, registering for SystemPower
notifications, acts accordingly to satisfy SCMI plaform system transitions
requests like shutdown/reboot both of graceful and forceful kind.
On Thu, Feb 4, 2021 at 9:42 AM Sedat Dilek wrote:
>
> On Thu, Feb 4, 2021 at 3:58 AM Andrii Nakryiko
> wrote:
> ...
> >
> > Is there another (easy) way to get your patch set without the b4 tool?
> > Is your patch set present in some patchworks instance, so that I can
> > download it in mbox
On Thu, Feb 4, 2021 at 3:58 AM Andrii Nakryiko
wrote:
...
>
> Is there another (easy) way to get your patch set without the b4 tool?
> Is your patch set present in some patchworks instance, so that I can
> download it in mbox format, for example?
>
Just to promote the b4 tool - we have some cool
Hi Viresh,
On 2/4/21 2:41 PM, Viresh Kumar wrote:
> On 03-02-21, 17:23, Hsin-Yi Wang wrote:
>> The devfreq passive governor scales the frequency of a "child" device based
>> on the current frequency of a "parent" device (not parent/child in the
>> sense of device hierarchy). As of today, the
On Thu, Feb 4, 2021 at 1:41 PM Viresh Kumar wrote:
>
> On 03-02-21, 17:23, Hsin-Yi Wang wrote:
> > The devfreq passive governor scales the frequency of a "child" device based
> > on the current frequency of a "parent" device (not parent/child in the
> > sense of device hierarchy). As of today,
On 03-02-21, 17:23, Hsin-Yi Wang wrote:
> The devfreq passive governor scales the frequency of a "child" device based
> on the current frequency of a "parent" device (not parent/child in the
> sense of device hierarchy). As of today, the passive governor requires one
> of the following to work
On Wed, Feb 3, 2021 at 6:58 PM Andrii Nakryiko
wrote:
>
> On Wed, Feb 3, 2021 at 5:31 PM Nick Desaulniers
> wrote:
> >
> > On Sun, Jan 17, 2021 at 12:14 PM Arnaldo Carvalho de Melo
> > wrote:
> > >
> > > Em Fri, Jan 15, 2021 at 03:43:06PM -0800, Yonghong Song escreveu:
> > > >
> > > >
> > > >
On Wed, Feb 3, 2021 at 5:31 PM Nick Desaulniers wrote:
>
> On Sun, Jan 17, 2021 at 12:14 PM Arnaldo Carvalho de Melo
> wrote:
> >
> > Em Fri, Jan 15, 2021 at 03:43:06PM -0800, Yonghong Song escreveu:
> > >
> > >
> > > On 1/15/21 3:34 PM, Nick Desaulniers wrote:
> > > > On Fri, Jan 15, 2021 at
On Sun, Jan 17, 2021 at 12:14 PM Arnaldo Carvalho de Melo
wrote:
>
> Em Fri, Jan 15, 2021 at 03:43:06PM -0800, Yonghong Song escreveu:
> >
> >
> > On 1/15/21 3:34 PM, Nick Desaulniers wrote:
> > > On Fri, Jan 15, 2021 at 3:24 PM Yonghong Song wrote:
> > > >
> > > >
> > > >
> > > > On 1/15/21
Hi Hsin-Yi,
Thanks for the patch. I already reviewed this patch.
But, I'll check these again and test it.
On 2/3/21 6:23 PM, Hsin-Yi Wang wrote:
> The devfreq passive governor scales the frequency of a "child" device based
> on the current frequency of a "parent" device (not parent/child in the
The devfreq passive governor scales the frequency of a "child" device based
on the current frequency of a "parent" device (not parent/child in the
sense of device hierarchy). As of today, the passive governor requires one
of the following to work correctly:
1. The parent and child device have the
Hello Shawn,
Could you please have a look at the new patch set made after your commentaries?
Thank a lot for your time,
Thanks,
Le lun. 18 janv. 2021 à 12:15, Adrien Grassein
a écrit :
>
> Hello,
>
> This patch set aims is to add the support of the Nitrogen8M Mini SBC
> from Boundary Devices.
On Thu, Jan 21, 2021 at 12:45 AM Dmitry Osipenko wrote:
>
> Hi,
>
> This series is a prerequisite for the power domain driver of NVIDIA Tegra
> SoCs [1]. It extends the GENPD core with a better support of performance
> states and eases linking of child/parent PDs for the PD drivers.
>
> [1]
**
** NOTE: To "view the full picture", please look at the following
** patch series:
** https://patchwork.kernel.org/project/linux-arm-msm/list/?series=413355
** This is a subset of that series.
**
Changes in v5:
- Fixed getting OPP table when not yet installed by the
Hi,
This series is a prerequisite for the power domain driver of NVIDIA Tegra
SoCs [1]. It extends the GENPD core with a better support of performance
states and eases linking of child/parent PDs for the PD drivers.
[1] https://patchwork.ozlabs.org/project/linux-tegra/list/?series=221130
Hello,
This patch set aims is to add the support of the Nitrogen8M Mini SBC
from Boundary Devices.
Thanks,
Update in v2:
- Rewrite the dts (Remove the unused wlan and audio);
- Remove useless definition;
- Take in account review.
Update in v3:
- Take in account review.
Update in v4:
Em Fri, Jan 15, 2021 at 03:43:06PM -0800, Yonghong Song escreveu:
>
>
> On 1/15/21 3:34 PM, Nick Desaulniers wrote:
> > On Fri, Jan 15, 2021 at 3:24 PM Yonghong Song wrote:
> > >
> > >
> > >
> > > On 1/15/21 1:53 PM, Sedat Dilek wrote:
> > > > En plus, I encountered breakage with GCC v10.2.1
On Thu, 14 Jan 2021 11:22:16 +0100, Bartosz Golaszewski wrote:
> This is a set of improvements for the rtc-s5m driver. The first patch
> is new in v4: I noticed the I2C regmap is not selected by this driver's
> Kconfig. Two subsequent patches were already submitted separately.
>
> v1 -> v2:
> -
On 1/15/21 3:34 PM, Nick Desaulniers wrote:
On Fri, Jan 15, 2021 at 3:24 PM Yonghong Song wrote:
On 1/15/21 1:53 PM, Sedat Dilek wrote:
En plus, I encountered breakage with GCC v10.2.1 and LLVM=1 and
CONFIG_DEBUG_INFO_DWARF4.
So might be good to add a "depends on !DEBUG_INFO_BTF" in
On Fri, Jan 15, 2021 at 3:34 PM Nick Desaulniers
wrote:
>
> On Fri, Jan 15, 2021 at 3:24 PM Yonghong Song wrote:
> >
> >
> >
> > On 1/15/21 1:53 PM, Sedat Dilek wrote:
> > > En plus, I encountered breakage with GCC v10.2.1 and LLVM=1 and
> > > CONFIG_DEBUG_INFO_DWARF4.
> > > So might be good to
On Fri, Jan 15, 2021 at 3:24 PM Yonghong Song wrote:
>
>
>
> On 1/15/21 1:53 PM, Sedat Dilek wrote:
> > En plus, I encountered breakage with GCC v10.2.1 and LLVM=1 and
> > CONFIG_DEBUG_INFO_DWARF4.
> > So might be good to add a "depends on !DEBUG_INFO_BTF" in this combination.
Can you privately
On 1/15/21 1:53 PM, Sedat Dilek wrote:
On Fri, Jan 15, 2021 at 10:06 PM Nick Desaulniers
wrote:
DWARF v5 is the latest standard of the DWARF debug info format.
DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).
Link:
On Fri, Jan 15, 2021 at 10:06 PM Nick Desaulniers
wrote:
>
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> DWARF5 wins significantly in terms of size when mixed with compression
> (CONFIG_DEBUG_INFO_COMPRESSED).
>
> Link: http://www.dwarfstd.org/doc/DWARF5.pdf
>
> Patch 1 is
DWARF v5 is the latest standard of the DWARF debug info format.
DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).
Link: http://www.dwarfstd.org/doc/DWARF5.pdf
Patch 1 is a cleanup from Masahiro and isn't DWARF v5 specific.
Patch 2 is a
From: Bartosz Golaszewski
This is a set of improvements for the rtc-s5m driver. The first patch
is new in v4: I noticed the I2C regmap is not selected by this driver's
Kconfig. Two subsequent patches were already submitted separately.
v1 -> v2:
- remove the remove() callback
v2 -> v3:
- fix an
On Tue, Jan 12, 2021 at 06:09:28AM -0800, Guenter Roeck wrote:
> On 1/12/21 3:59 AM, Heikki Krogerus wrote:
> > On Tue, Jan 12, 2021 at 12:53:56PM +0100, Greg KH wrote:
> >> On Wed, Jan 06, 2021 at 12:39:24AM +0800, Kyle Tso wrote:
> >>> This series include previous patch "[v4] AMS and Collision
On 01/12, Sumera Priyadarsini wrote:
> This patchset aims to lay down some prep work before configfs can be
> implemented for the vkms driver. The first patch in the series adds a
> new type vkms_config to track device configuration. The second and third
> patch add module testing support for
On 1/12/21 3:59 AM, Heikki Krogerus wrote:
> On Tue, Jan 12, 2021 at 12:53:56PM +0100, Greg KH wrote:
>> On Wed, Jan 06, 2021 at 12:39:24AM +0800, Kyle Tso wrote:
>>> This series include previous patch "[v4] AMS and Collision Avoidance"
>>>
On Wed, Jan 06, 2021 at 12:39:24AM +0800, Kyle Tso wrote:
> This series include previous patch "[v4] AMS and Collision Avoidance"
> https://lore.kernel.org/r/20201217030632.903718-1-kyle...@google.com
> and two more patches "Protocol Error handling" and "Respond Wait if...".
>
> The patch "AMS
On Tue, Jan 12, 2021 at 12:57:28PM +0100, Hans de Goede wrote:
> Hi,
>
> On 1/12/21 12:53 PM, Greg KH wrote:
> > On Wed, Jan 06, 2021 at 12:39:24AM +0800, Kyle Tso wrote:
> >> This series include previous patch "[v4] AMS and Collision Avoidance"
> >>
On Tue, Jan 12, 2021 at 12:53:56PM +0100, Greg KH wrote:
> On Wed, Jan 06, 2021 at 12:39:24AM +0800, Kyle Tso wrote:
> > This series include previous patch "[v4] AMS and Collision Avoidance"
> > https://lore.kernel.org/r/20201217030632.903718-1-kyle...@google.com
> > and two more patches "Protocol
Hi,
On 1/12/21 12:53 PM, Greg KH wrote:
> On Wed, Jan 06, 2021 at 12:39:24AM +0800, Kyle Tso wrote:
>> This series include previous patch "[v4] AMS and Collision Avoidance"
>> https://lore.kernel.org/r/20201217030632.903718-1-kyle...@google.com
>> and two more patches "Protocol Error handling"
On Wed, Jan 06, 2021 at 12:39:24AM +0800, Kyle Tso wrote:
> This series include previous patch "[v4] AMS and Collision Avoidance"
> https://lore.kernel.org/r/20201217030632.903718-1-kyle...@google.com
> and two more patches "Protocol Error handling" and "Respond Wait if...".
>
> The patch "AMS
This patchset aims to lay down some prep work before configfs can be
implemented for the vkms driver. The first patch in the series adds a
new type vkms_config to track device configuration. The second and third
patch add module testing support for writeback operations.
The first patch is
This series include previous patch "[v4] AMS and Collision Avoidance"
https://lore.kernel.org/r/20201217030632.903718-1-kyle...@google.com
and two more patches "Protocol Error handling" and "Respond Wait if...".
The patch "AMS and Collision Avoidance" in [v5] is the same as the one
in [v4] (only
Hi everyone,
This is the fifth iteration of the series introducing a driver for the
PX30 camera interface.
This was previously known as the "cif" driver in other iterations, but
was renamed to "vip" following Ezequiel's advices to match the datasheet
name.
This is based on a BSP driver, and I'm
On Tue, Dec 08, 2020 at 04:21:28PM +0530, Manivannan Sadhasivam wrote:
> On Sun, Nov 22, 2020 at 10:38:19PM +0530, Manivannan Sadhasivam wrote:
> > From: Manivannan Sadhasivam
> >
> > Hello,
> >
> > This series adds support for MaxLinear/Exar USB to serial converters.
> > This driver only
Changes in v2:
- rename DT node
Changes in v3:
- add regulator-poweroff driver
- use regulator-poweroff driver instead of gpio-poweroff
Changes in v4:
- hardcode poweroff timeout to 3000ms, not configurable any more
- remove support for multiple regulators
- fix Documentation issues
On 08-12-20, 15:50, Peter Zijlstra wrote:
> On Tue, Dec 08, 2020 at 09:46:54AM +0530, Viresh Kumar wrote:
> > Viresh Kumar (3):
> > sched/core: Move schedutil_cpu_util() to core.c
> > sched/core: Rename schedutil_cpu_util() and allow rest of the kernel
> > to use it
> > thermal:
On Tue, Dec 08, 2020 at 09:46:54AM +0530, Viresh Kumar wrote:
> Viresh Kumar (3):
> sched/core: Move schedutil_cpu_util() to core.c
> sched/core: Rename schedutil_cpu_util() and allow rest of the kernel
> to use it
> thermal: cpufreq_cooling: Reuse sched_cpu_util() for SMP platforms
How
On Sun, Nov 22, 2020 at 10:38:19PM +0530, Manivannan Sadhasivam wrote:
> From: Manivannan Sadhasivam
>
> Hello,
>
> This series adds support for MaxLinear/Exar USB to serial converters.
> This driver only supports XR21V141X series but it can easily be extended
> to other series in future.
>
>
Hi,
This patchset makes the cpufreq_cooling driver reuse the CPU utilization
metric provided by the scheduler instead of depending on idle and busy
times of a CPU, which aren't that accurate to measure the busyness of a
CPU for the next cycle. More details can be seen in the commit logs of
the
From: Manivannan Sadhasivam
Hello,
This series adds support for MaxLinear/Exar USB to serial converters.
This driver only supports XR21V141X series but it can easily be extended
to other series in future.
This driver is inspired from the initial one submitted by Patong Yang:
On Tue, 10 Nov 2020, Ezequiel Garcia
wrote:
On Wed, 2020-11-11 at 00:28 +0200, Adrian Ratiu wrote:
Hi Ezequiel,
On Tue, 10 Nov 2020, Ezequiel Garcia
wrote:
> On Mon, 2 Nov 2020 at 16:04, Adrian Ratiu
> wrote:
> > Dear all, This is v5 of the series adding VP9 profile 0
> > decoding
On Wed, 2020-11-11 at 00:28 +0200, Adrian Ratiu wrote:
> Hi Ezequiel,
>
> On Tue, 10 Nov 2020, Ezequiel Garcia
> wrote:
> > On Mon, 2 Nov 2020 at 16:04, Adrian Ratiu
> > wrote:
> > > Dear all,
> > >
> > > This is v5 of the series adding VP9 profile 0 decoding to
> > > rkvdec.
> > >
> >
Hi Ezequiel,
On Tue, 10 Nov 2020, Ezequiel Garcia
wrote:
On Mon, 2 Nov 2020 at 16:04, Adrian Ratiu
wrote:
Dear all,
This is v5 of the series adding VP9 profile 0 decoding to
rkvdec.
All feedback from v4 should be addressed, there's just one
thing I did not address:
On Mon, 2 Nov 2020 at 16:04, Adrian Ratiu wrote:
>
> Dear all,
>
> This is v5 of the series adding VP9 profile 0 decoding to rkvdec.
>
> All feedback from v4 should be addressed, there's just one thing I did
> not address: ref_frame_sign_biases in the uAPI. The userspace tool I'm
I believe that
On Mon, 9 Nov 2020 09:58:54 +0530, Anshuman Khandual wrote:
> This series brings three different changes to the only memory event notifier
> on
> arm64 platform. These changes improve it's robustness while also enhancing
> debug
> capabilities during potential memory offlining error conditions.
On 10/28/20 3:56 AM, Michael Walle wrote:
> Am 2020-10-03 17:32, schrieb Michael Walle:
>> I bundled this as a series, because otherwise there will be conflicts
>> because the "remove global protection flag" patches modify the same lines
>> as the main patch.
>>
>> See invdividual patches for
This series brings three different changes to the only memory event notifier on
arm64 platform. These changes improve it's robustness while also enhancing debug
capabilities during potential memory offlining error conditions.
This applies on 5.10-rc3
Changes in V5:
- Added some more
This series adds support for Qcom GSI dma controller found on Qualcomm SoCs.
This controller can program the peripheral configuration so we add
additional parameters in dma_slave_config for configuring the peripherals
like spi and i2c.
Changes in v5:
- Add acked by Rob
- Move qcom-gpi-dma.h
This patchset mainly adds SMI support for mt8192.
It comes from the patchset[1]. I seperate the smi part into this patchset.
And the two part(IOMMU/SMI) patchset don't depend on each other.
Rebase on v5.10-rc1.
changenote:
v5: Fix complain from yamllint.
v4:
On Thu, 29 Oct 2020 17:36:17 + Aleksandr Nogikh wrote:
> From: Aleksandr Nogikh
>
> This patch series enables remote KCOV coverage collection during
> 802.11 frames processing. These changes make it possible to perform
> coverage-guided fuzzing in search of remotely triggerable bugs.
>
>
Add support to enable VBUS detection in the pm8941 extcon driver.
Changes from v4:
- Drop addition of new compatible string in both bindings and driver.
Changes from v3:
- Split bindings into direct conversion of txt file, and addition of VBUS
detection support.
Changes from v2:
- Fix YAML
Dear all,
This is v5 of the series adding VP9 profile 0 decoding to rkvdec.
All feedback from v4 should be addressed, there's just one thing I did
not address: ref_frame_sign_biases in the uAPI. The userspace tool I'm
using [1] apparently doesn't need it or the default hwreg value for it
is
On Mon, 19 Oct 2020 11:23:20 -0700, Bjorn Andersson wrote:
> This is the revised fourth attempt of inheriting the stream mapping for
> the framebuffer on many Qualcomm platforms, in order to not hit
> catastrophic faults during arm-smmu initialization.
>
> The new approach does, based on Robin's
From: Aleksandr Nogikh
This patch series enables remote KCOV coverage collection during
802.11 frames processing. These changes make it possible to perform
coverage-guided fuzzing in search of remotely triggerable bugs.
Normally, KCOV collects coverage information for the code that is
executed
On Tue, Oct 27, 2020 at 09:42:55PM +0100, Michael Weiß wrote:
> Time namespaces make it possible to virtualize time inside of
> containers, e.g., it is feasible to reset the uptime of a container
> to zero by setting the time namespace offset for boottime to the
> negated current value of the
Updated patchset.
Pavana Sharma (3):
net: phy: Add 5GBASER interface mode
dt-bindings: net: Add 5GBASER phy interface mode
net: dsa: mv88e6xxx: Add support for mv88e6393x family of Marvell
.../bindings/net/ethernet-controller.yaml | 2 +
drivers/net/dsa/mv88e6xxx/chip.c
Am 2020-10-03 17:32, schrieb Michael Walle:
I bundled this as a series, because otherwise there will be conflicts
because the "remove global protection flag" patches modify the same
lines
as the main patch.
See invdividual patches for the version history.
any news here?
-michael
Time namespaces make it possible to virtualize time inside of
containers, e.g., it is feasible to reset the uptime of a container
to zero by setting the time namespace offset for boottime to the
negated current value of the CLOCK_BOOTTIME.
However, the boot time stamp provided by getboottime64()
On 10/19/20 1:23 PM, Bjorn Andersson wrote:
> This is the revised fourth attempt of inheriting the stream mapping for
> the framebuffer on many Qualcomm platforms, in order to not hit
> catastrophic faults during arm-smmu initialization.
>
> The new approach does, based on Robin's suggestion,
This is the revised fourth attempt of inheriting the stream mapping for
the framebuffer on many Qualcomm platforms, in order to not hit
catastrophic faults during arm-smmu initialization.
The new approach does, based on Robin's suggestion, take a much more
direct approach with the allocation of a
1 - 100 of 1343 matches
Mail list logo
