From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/bus_sdio.c | 258 +
1 file changed, 258 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/bus_sdio.c
diff --git a/drivers/net/wireless/silabs/wfx/bus_sdio.c
b/drivers/n
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/hif_api_cmd.h | 553 ++
.../net/wireless/silabs/wfx/hif_api_general.h | 267 +
drivers/net/wireless/silabs/wfx/hif_api_mib.h | 343 +++
3 files changed, 1163 insertions(+)
c
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/fwio.c | 405 +
drivers/net/wireless/silabs/wfx/fwio.h | 15 +
2 files changed, 420 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/fwio.c
create mode 100644 driv
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/data_rx.c | 93 +++
drivers/net/wireless/silabs/wfx/data_rx.h | 18 +
2 files changed, 111 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/data_rx.c
create mode 10
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/data_tx.c | 585 ++
drivers/net/wireless/silabs/wfx/data_tx.h | 67 +++
2 files changed, 652 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/data_tx.c
create mode 100
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/hif_rx.c | 415 +++
drivers/net/wireless/silabs/wfx/hif_rx.h | 18 +
2 files changed, 433 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/hif_rx.c
create mode 100644
On Mon, 19 Oct 2020 13:50:17 -0700
Sean V Kelley wrote:
> On 19 Oct 2020, at 11:59, Kuppuswamy, Sathyanarayanan wrote:
>
> > On 10/19/20 11:31 AM, Sean V Kelley wrote:
> >> On 19 Oct 2020, at 3:49, Ethan Zhao wrote:
> >>
> >>> On Sat, Oct 17, 2020 at 6:29 AM Bjorn Helgaas
> >>> wrote:
>
On Tue, Oct 20, 2020 at 2:36 AM Vincent Whitchurch
wrote:
>
> The reserved-memory overlap detection code fails to detect overlaps if
> either of the regions starts at address 0x0. For some reason the code
> explicitly checks for and ignores such regions, but this check looks
> invalid. Remove th
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/debug.c | 359
drivers/net/wireless/silabs/wfx/debug.h | 19 ++
2 files changed, 378 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/debug.c
create mode 100644 d
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/queue.c | 304
drivers/net/wireless/silabs/wfx/queue.h | 45
2 files changed, 349 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/queue.c
create mode 100644
On 10/20/20 3:30 AM, Peter Zijlstra wrote:
> On Mon, Oct 19, 2020 at 11:00:05AM -0300, Marcelo Tosatti wrote:
>>> So I think it is important to figure out what that driver really wants
>>> in the nohz_full case. If it wants to retain N interrupts per CPU, and
>>> only reduce the number of CPUs, th
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/traces.h | 501 +++
1 file changed, 501 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/traces.h
diff --git a/drivers/net/wireless/silabs/wfx/traces.h
b/drivers/net/w
From: Jérôme Pouiller
The wfx driver is now mature enough to leave the staging area.
Signed-off-by: Jérôme Pouiller
---
MAINTAINERS | 3 ++-
drivers/net/wireless/Kconfig | 1 +
drivers/net/wireless/Makefile| 1 +
drivers/net/wireless/silabs/Kconfig
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/bh.c | 333 +++
drivers/net/wireless/silabs/wfx/bh.h | 33 +++
2 files changed, 366 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/bh.c
create mode 100644 driver
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/hif_tx.c | 523 +++
drivers/net/wireless/silabs/wfx/hif_tx.h | 60 +++
drivers/net/wireless/silabs/wfx/hif_tx_mib.c | 324
drivers/net/wireless/silabs/wfx/hif_tx_mib.h
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/key.c | 241 ++
drivers/net/wireless/silabs/wfx/key.h | 20 +++
2 files changed, 261 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/key.c
create mode 100644 driv
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/scan.c | 132 +
drivers/net/wireless/silabs/wfx/scan.h | 22 +
2 files changed, 154 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/scan.c
create mode 100644
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/bus.h | 38 +++
1 file changed, 38 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/bus.h
diff --git a/drivers/net/wireless/silabs/wfx/bus.h
b/drivers/net/wireless
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/hwio.c | 352 +
drivers/net/wireless/silabs/wfx/hwio.h | 75 ++
2 files changed, 427 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/hwio.c
create mode 100644
From: Tom Rix
A break is not needed if it is preceded by a return
Signed-off-by: Tom Rix
---
v2: remove intersil/p54/eeprom.c
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 1 -
drivers/net/wireless/ath/ath6kl/testmode.c | 1 -
drivers/net/wireless/ath/ath9k/hw.c
From: Jérôme Pouiller
Add Silabs SDIO ID to sdio_ids.h.
Note that the values used by Silabs are uncommon. A driver cannot fully
rely on the SDIO PnP. It should also check if the device is declared in
the DT.
Signed-off-by: Jérôme Pouiller
---
include/linux/mmc/sdio_ids.h | 5 +
1 file cha
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
drivers/net/wireless/silabs/wfx/Kconfig | 8
drivers/net/wireless/silabs/wfx/Makefile | 25
2 files changed, 33 insertions(+)
create mode 100644 drivers/net/wireless/silabs/wfx/Kconfig
create mode 100
From: Jérôme Pouiller
Signed-off-by: Jérôme Pouiller
---
.../bindings/net/wireless/silabs,wfx.yaml | 133 ++
1 file changed, 133 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
diff --git a/Documentation/devicetree/bindings/
From: Jérôme Pouiller
I think the wfx driver is now mature enough to be accepted in the
drivers/net/wireless directory.
As requested by Kalle[1], I send one file per patch. At the end, all the
patches (or at least the patches 3 to 24) will be squashed (therefore, I
didn't bother to write real co
On Tue, Oct 20, 2020 at 09:17:01AM +0200, Peter Zijlstra wrote:
> On Tue, Oct 20, 2020 at 09:18:54AM +0300, Kirill A. Shutemov wrote:
> > +int __kvm_protect_memory(unsigned long start, unsigned long end, bool
> > protect)
> > +{
> > + struct mm_struct *mm = current->mm;
> > + struct vm_area_st
Add support for AISTARVISION MIPI Adapter V2.1 board connected to HiHope
RZ/G2N board.
Signed-off-by: Lad Prabhakar
Reviewed-by: Biju Das
---
v1->v2 - No change
---
arch/arm64/boot/dts/renesas/Makefile | 1 +
.../r8a774b1-hihope-rzg2n-ex-mipi-2.1.dts| 16
2
For HiHope RZ/G2H the OV5645 sensor is populated on i2c2 whereas the imx219
sensor is populated on i2c3 so add support for handling such cases by
adding a parent macro for each sensor.
Also update r8a774c0-ek874-mipi-2.1.dts to incorporate the changes.
Signed-off-by: Lad Prabhakar
Reviewed-by: B
Add support for AISTARVISION MIPI Adapter V2.1 board connected to HiHope
RZ/G2H board.
Common file hihope-rzg2-ex-aistarvision-mipi-adapter-2.1.dtsi is created
which will be used by RZ/G2{HMN}, by default the CSI20 node is tied to
ov5645 camera endpoint and the imx219 camera endpoint is tied to CS
Hi All,
This patch series adds support for MIPI Adapter V2.1 connected to
HiHope RZ/G2{HMN}.
Patches apply on top of [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/
renesas-devel.git/log/?h=renesas-arm-dt-for-v5.11
Cheers,
Prabhakar
Changes for v2:
* patches {1,2,4}/4 uncha
Add support for AISTARVISION MIPI Adapter V2.1 board connected to HiHope
RZ/G2M board.
Signed-off-by: Lad Prabhakar
Reviewed-by: Biju Das
---
v1->v2
* Disabled CSI40 amd imx219 nodes
* Added a comment wrt CSI40 as it supports only 4 lane mode
---
arch/arm64/boot/dts/renesas/Makefile |
On Tue, Oct 20, 2020 at 01:25:59AM -0700, John Hubbard wrote:
> On 10/19/20 11:18 PM, Kirill A. Shutemov wrote:
> > New helpers copy_from_guest()/copy_to_guest() to be used if KVM memory
> > protection feature is enabled.
> >
> > Signed-off-by: Kirill A. Shutemov
> > ---
> > include/linux/kvm_h
On Tue, Oct 20, 2020 at 02:59:57PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "sn
On Tue, Oct 20, 2020 at 09:06:58AM +0100, Christoph Hellwig wrote:
> NAK. Any virtio implementation that needs special DMA OPS treatment
> needs to set the VIRTIO_F_ACCESS_PLATFORM bit. The only reason the
> Xen hack existst is because it slipped in a long time ago and we can't
> fix that any mor
On Tue, Oct 20, 2020 at 02:26:21PM +0200, Krzysztof Kozlowski wrote:
> On Tue, Oct 20, 2020 at 03:00:58PM +0300, Sakari Ailus wrote:
> > Hi Krzysztof,
> >
> > On Tue, Oct 20, 2020 at 12:54:09PM +0200, Krzysztof Kozlowski wrote:
> > > On Tue, 20 Oct 2020 at 12:38, Sakari Ailus
> > > wrote:
> > >
On Tue, Oct 20, 2020 at 03:44:04PM +0300, Serge Semin wrote:
> On Tue, Oct 20, 2020 at 02:34:04PM +0200, Krzysztof Kozlowski wrote:
> > On Tue, Oct 20, 2020 at 02:59:35PM +0300, Serge Semin wrote:
> > > In accordance with the DWC USB3 bindings the property is supposed to have
> > > uint32 type. It'
On Tue, Oct 20, 2020 at 02:59:51PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "sn
On Tue, Oct 20, 2020 at 02:34:04PM +0200, Krzysztof Kozlowski wrote:
> On Tue, Oct 20, 2020 at 02:59:35PM +0300, Serge Semin wrote:
> > In accordance with the DWC USB3 bindings the property is supposed to have
> > uint32 type. It's erroneous from the DT schema and driver points of view
> > to decla
On Tue, Oct 20, 2020 at 02:59:59PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "sn
On Tue, Oct 20, 2020 at 12:59 AM Daniel Scally wrote:
>
> The software_node_get_next_child() function currently does not hold a kref
> to the child software_node; fix that.
>
> Fixes: 59abd83672f7 ("drivers: base: Introducing software nodes to the
> firmware node framework")
> Signed-off-by: Dani
On Tue, Oct 20, 2020 at 02:59:58PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "sn
On Tue, Oct 20, 2020 at 02:59:48PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "sn
On Tue, Oct 20, 2020 at 02:59:56PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "sn
On Tue, Oct 20, 2020 at 02:59:54PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "sn
On Tue, Oct 20, 2020 at 02:59:55PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "sn
On Tue, Oct 20, 2020 at 02:59:50PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "sn
On Tue, Oct 20, 2020 at 02:59:52PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "sn
On Tue, Oct 20, 2020 at 02:59:53PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "sn
On Tue, Oct 20, 2020 at 02:59:47PM +0300, Serge Semin wrote:
> In accordance with the Generic xHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the
On Tue, Oct 20, 2020 at 02:59:42PM +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sur
On Tue, Oct 20, 2020 at 8:23 AM Hillf Danton wrote:
>
> On Wed, 14 Oct 2020 22:44:35 +0200
> >
> > #ifdef CONFIG_KASAN_HW_TAGS
> > +#define arch_system_supports_tags() system_supports_mte()
>
> s/system_supports/support/ in order to look more like the brother of
>
> > #define arch_init_
On Tue, Oct 20, 2020 at 02:59:44PM +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sur
On Tue, Oct 20, 2020 at 02:59:46PM +0300, Serge Semin wrote:
> In accordance with the Generic xHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the
On Tuesday, 20 October 2020, 13:30:09 CEST, Peter Zijlstra wrote:
> On Mon, Oct 19, 2020 at 05:09:35PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2020-10-19 12:21:06 [+0200], Christian Eggers wrote:
> > > I have problems with the latest 5.9-rt releases on i.MX6ULL (!
CONFIG_SMP):
> > …
> >
> >
On Tue, Oct 20, 2020 at 02:59:45PM +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sur
On Tue, Oct 20, 2020 at 02:59:40PM +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sur
On Tue, Oct 20, 2020 at 02:59:41PM +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sur
On Tue, Oct 20, 2020 at 02:59:43PM +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sur
On Tue, Oct 20, 2020 at 02:59:39PM +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sur
On Tue, Oct 20, 2020 at 02:59:38PM +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sur
Hi!
> Usage is as follows:
>
> myled=ledname
> tty=ttyS0
>
> echo tty > /sys/class/leds/$myled/trigger
> echo $tty > /sys/class/leds/$myled/ttyname
>
> . When this new trigger is active it periodically checks the tty's
> statistics and when it changed since the last chec
Hi Ahmed,
On Tue, Oct 20, 2020 at 3:04 PM Ahmed Abdelsalam wrote:
>
> We are submitting the patch for End.DT4. End.DX4 is already there.
>
> So the optional parameter and OIF applies directly to End.X/End.DX6/End.DX4.
>
The only catch is OIF cannot be an optional parameter for linklocal address.
Hi Daniel, Heikki,
Thanks for the patch.
On Mon, Oct 19, 2020 at 11:58:58PM +0100, Daniel Scally wrote:
> From: Heikki Krogerus
>
> This implements the remaining .graph_* callbacks in the
> fwnode operations vector for the software nodes. That makes
> the fwnode_graph*() functions available in
On Tue, Oct 20, 2020 at 02:59:36PM +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sur
On Mon, Oct 19, 2020 at 8:43 PM Hans de Goede wrote:
>
> Hi,
>
> On 10/18/20 2:31 PM, Rafael J. Wysocki wrote:
> > On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 10/16/20 4:51 PM, Rafael J. Wysocki wrote:
> >>> On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote
On Tue, Oct 20, 2020 at 02:59:37PM +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sur
On Tue, Oct 20, 2020 at 02:59:35PM +0300, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the property is supposed to have
> uint32 type. It's erroneous from the DT schema and driver points of view
> to declare it as boolean.
I think the driver uses it as u32, so what do you mean by
On Tue, Oct 20, 2020 at 02:28:01PM +0200, Krzysztof Kozlowski wrote:
> On Tue, Oct 20, 2020 at 03:15:06PM +0300, Andy Shevchenko wrote:
> > On Tue, Oct 20, 2020 at 3:02 PM Serge Semin
> > wrote:
> > >
> > > Syonpsys IP cores are supposed to be defined with "snps" vendor-prefix.
> > > Discard a DW
On 2020-10-20 19:57, Can Guo wrote:
On 2020-10-20 19:02, Can Guo wrote:
On 2020-10-20 18:51, Avri Altman wrote:
On 2020-10-06 06:36, Jaegeuk Kim wrote:
> From: Jaegeuk Kim
>
> This adds user-friendly tracepoints with group id.
You have the entire cdb as part of the upiu trace,
Can't you pars
On 2020-10-20 13:25, Daniel Thompson wrote:
On Tue, Oct 20, 2020 at 04:52:43PM +0530, Sumit Garg wrote:
[...]
So in general, IPI as a normal IRQ is still useful for debugging but
it can't debug a core which is stuck in deadlock with interrupts
disabled.
And since we choose override default i
On Tue, Oct 20, 2020 at 02:59:33PM +0300, Serge Semin wrote:
> Syonpsys IP cores are supposed to be defined with "snps" vendor-prefix.
> Use it instead of the deprecated "synopsys" one.
>
> Signed-off-by: Serge Semin
> ---
> arch/arm/boot/dts/am437x-l4.dtsi | 4 ++--
> 1 file changed, 2 insertio
On Tue, Oct 20, 2020 at 02:59:32PM +0300, Serge Semin wrote:
> Syonpsys IP cores are supposed to be defined with "snps" vendor-prefix.
> Use it instead of the deprecated "synopsys" one.
>
> Signed-off-by: Serge Semin
> ---
> arch/arm/boot/dts/keystone-k2e.dtsi | 2 +-
> arch/arm/boot/dts/keyston
On Tue, Oct 20, 2020 at 03:15:06PM +0300, Andy Shevchenko wrote:
> On Tue, Oct 20, 2020 at 3:02 PM Serge Semin
> wrote:
> >
> > Syonpsys IP cores are supposed to be defined with "snps" vendor-prefix.
> > Discard a DW USB3 compatible string with the deprecated prefix seeing
> > one isn't used by an
Hi,
Serge Semin writes:
> Syonpsys IP cores are supposed to be defined with "snps" vendor-prefix.
> Discard a DW USB3 compatible string with the deprecated prefix seeing
> one isn't used by any dts file anymore.
>
> Signed-off-by: Serge Semin
> ---
> drivers/usb/dwc3/core.c | 3 ---
> 1 file c
On Sun 2020-10-18 22:40:21, Uwe Kleine-König wrote:
> For a given struct tty_struct this yields the corresponding statistics
> about sent and received characters (and some more) which is needed to
> implement an LED trigger for tty devices.
>
> The new function is then used to simplify tty_tiocgic
On Tue, Oct 20, 2020 at 03:00:58PM +0300, Sakari Ailus wrote:
> Hi Krzysztof,
>
> On Tue, Oct 20, 2020 at 12:54:09PM +0200, Krzysztof Kozlowski wrote:
> > On Tue, 20 Oct 2020 at 12:38, Sakari Ailus
> > wrote:
> > >
> > > Hi Krzysztof,
> > >
> > > On Mon, Oct 19, 2020 at 07:02:44PM +0200, Krzyszt
On Mon, Oct 19, 2020 at 9:47 PM Jakub Kicinski wrote:
>
> If we can save the device lookup and still be semantically correct,
> that's probably better.
I am afraid we need to do a device lookup if I am looking up the
neighbor. neigh_lookup
apis expect dev to be passed. If I go through the current
Hi1
> Introduce a new function tty_kopen_shared() that yields a struct
> tty_struct. The semantic difference to tty_kopen() is that the tty is
> expected to be used already. So rename tty_kopen() to
> tty_kopen_exclusive() for clearness, adapt the single user and put the
> common code in a new sta
On Tue, Oct 20, 2020 at 04:52:43PM +0530, Sumit Garg wrote:
> On Tue, 20 Oct 2020 at 15:38, Marc Zyngier wrote:
> >
> > On 2020-10-20 07:43, Sumit Garg wrote:
> > > On Mon, 19 Oct 2020 at 17:07, Marc Zyngier wrote:
> >
> > [...]
> >
> > >> > +{
> > >> > + if (!ipi_desc)
> > >> > +
On Mon, 19 Oct 2020 09:57:14 +0530, Srikar Dronamraju wrote:
> These patches fixes problems introduced by the coregroup patches.
> The first patch we remove a redundant variable.
> Second patch allows to boot with CONFIG_CPUMASK_OFFSTACK enabled.
>
> Changelog v1->v2:
> https://lore.kernel.org/lin
Hi!
On Tue, Oct 20, 2020 at 07:40:09AM +, Christophe Leroy wrote:
> In several places, inline assembly uses the "%Un" modifier
> to enable the use of instruction with update form addressing,
> but the associated "<>" constraint is missing.
>
> As mentioned in previous patch, this fails with g
Em Tue, Oct 20, 2020 at 11:01:39AM +0200, Jiri Slaby escreveu:
> Hi,
>
> On 19. 10. 20, 1:18, Érico Rolim wrote:
> > I'm trying to build kernel 5.9.1 for arm64, and my dotconfig has
> > `CONFIG_DEBUG_INFO_BTF=y`, which requires pahole for building. However,
> > pahole
> > version 1.18 segfaults d
From: Joerg Roedel
The early #VC handler which doesn't have a GHCB can only handle CPUID
exit codes. It is needed by the early boot code to handle #VC
exceptions raised in verify_cpu() and to get the position of the C
bit.
But the CPUID information comes from the hypervisor, which is untrusted
a
From: Joerg Roedel
Check whether the hypervisor reported the correct C-bit when running as
an SEV guest. Using a wrong C-bit position could be used to leak
sensitive data from the guest to the hypervisor.
The check function is in arch/x86/kernel/sev_verify_cbit.S so that it
can be re-used in the
From: Joerg Roedel
MMIO memory is usually not mapped encrypted, so there is no reason to
support emulated MMIO when it is mapped encrypted.
This prevents a possible hypervisor attack where it maps a RAM page as
an MMIO page in the nested page-table, so that any guest access to it
will trigger a
From: Joerg Roedel
Hi,
here are some enhancements to the SEV(-ES) code in the Linux kernel to
self-protect it against some newly detected hypervisor attacks. There
are 3 attacks addressed here:
1) Hypervisor does not present the SEV-enabled bit via CPUID
2) The Hypervisor prese
On Tue, Oct 20, 2020 at 11:04:57AM +0200, Olivier Moysan wrote:
> +static int mclk_event(struct snd_soc_dapm_widget *w,
> + struct snd_kcontrol *kcontrol, int event)
> +{
> + struct snd_soc_component *comp = snd_soc_dapm_to_component(w->dapm);
> + struct cs42l51_private *
From: Joerg Roedel
Introduce sev_status and initialize it together with sme_me_mask to have
an indicator which SEV features are enabled.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/mem_encrypt.S | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86
From: Joerg Roedel
When SEV is enabled the kernel requests the C-Bit position again from
the hypervisor to built its own page-table. Since the hypervisor is an
untrusted source the C-bit position needs to be verified before the
kernel page-table is used.
Call the sev_verify_cbit() function befor
On 20.10.20 08:18, Kirill A. Shutemov wrote:
> If the protected memory feature enabled, unmap guest memory from
> kernel's direct mappings.
Gah, ugly. I guess this also defeats compaction, swapping, ... oh gosh.
As if all of the encrypted VM implementations didn't bring us enough
ugliness already
Em Tue, Oct 20, 2020 at 03:07:15PM +0900, Namhyung Kim escreveu:
> Hello,
> On Fri, Oct 16, 2020 at 10:17 PM Tommi Rantala
> wrote:
> >
> > Currently reason for skipping the read only watchpoint test is only seen
> > when running in verbose mode:
> >
> > $ perf test watchpoint
> > 23: Watchpoi
On Tue, Oct 20, 2020 at 3:02 PM Serge Semin
wrote:
>
> Syonpsys IP cores are supposed to be defined with "snps" vendor-prefix.
> Discard a DW USB3 compatible string with the deprecated prefix seeing
> one isn't used by any dts file anymore.
I'm afraid it's no go.
It's an ABI from the moment when
On Tue, Oct 20, 2020 at 7:34 AM Dmitry Vyukov wrote:
>
> On Tue, Oct 20, 2020 at 12:51 AM Kostya Serebryany wrote:
> >
> > Hi,
> > I would like to hear opinions from others in CC on these choices:
> > * Production use of In-kernel MTE should be based on stripped-down
> > KASAN, or implemented ind
Em Mon, Oct 19, 2020 at 10:53:43PM +0200, Jiri Olsa escreveu:
> On Fri, Oct 16, 2020 at 02:47:18PM +0300, Tommi Rantala wrote:
> > The addr in PERF_RECORD_KSYMBOL events for non-jited bpf progs points to
> > the bpf interpreter, ie. within kernel text section. When processing the
> > unregister eve
On 9/25/20 11:12 PM, Steven Rostedt wrote:
From: "Steven Rostedt (VMware)"
As more use cases of checking if a tracepoint is enabled in a header are
coming to fruition, a helper macro, tracepoint_enabled(), has been added to
check if a tracepoint is enabled or not, and can be used with minimal h
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.10b-rc1b-tag
xen: branch for v5.10-rc1b
It contains the following:
- A single patch for fixing the Xen security issue XSA-331 (malicious
guests can DoS dom0 by triggering NULL-po
Em Tue, Oct 20, 2020 at 08:11:59AM +0200, Jiri Olsa escreveu:
> On Mon, Oct 19, 2020 at 06:02:34PM +0800, Leo Yan wrote:
> > This patch set is to move tsc testing from x86 specific to common
> > testing case. Since Arnaldo found the building failure for patch set
> > v4 [1], the first four patches
Em Tue, Oct 20, 2020 at 08:06:27AM +0200, Jiri Olsa escreveu:
> On Mon, Oct 19, 2020 at 08:36:13AM +0800, Leo Yan wrote:
> > Some archs (e.g. x86 and Arm64) don't enable the configuration
> > CONFIG_MEMORY_HOTPLUG by default, if this configuration is not enabled
> > when build the kernel image, the
Hi Andy,
On Tue, Oct 20, 2020 at 12:19:58PM +0300, Andy Shevchenko wrote:
> On Mon, Oct 19, 2020 at 11:59:01PM +0100, Daniel Scally wrote:
> > fwnode_graph_get_endpoint_by_id() will optionally parse enabled devices
> > only; that status being determined through the .device_is_available() op
> > of
Em Mon, Oct 19, 2020 at 04:25:45PM -0700, Ian Rogers escreveu:
> If perf is built with libpfm4 (LIBPFM4=1) then advertise it in perf -vv.
Thanks, applied.
- Arnaldo
> Signed-off-by: Ian Rogers
> ---
> tools/perf/builtin-version.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tool
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctl
601 - 700 of 1056 matches
Mail list logo
