[PATCH leds v1 05/10] leds: mt6323: use struct led_init_data when registering

By using struct led_init_data when registering we do not need to parse `label` DT property nor `linux,default-trigger` property. Signed-off-by: Marek Behún Cc: Sean Wang Cc: John Crispin Cc: Ryder Lee --- drivers/leds/leds-mt6323.c | 13 ++--- 1 file changed, 6 insertions(+), 7

[PATCH leds v1 09/10] leds: lm36274: use struct led_init_data when registering

By using struct led_init_data when registering we do not need to parse `label` DT property nor `linux,default-trigger` property. A small refactor was also done: - with using devm_led_classdev_register_ext the driver remove method is not needed - since only one child node is allowed for this

[PATCH leds v1 06/10] leds: pm8058: use struct led_init_data when registering

By using struct led_init_data when registering we do not need to parse `label` DT property nor `linux,default-trigger` property. Signed-off-by: Marek Behún Cc: Linus Walleij Cc: Bjorn Andersson --- drivers/leds/leds-pm8058.c | 38 +++--- 1 file changed, 19

[PATCH leds v1 02/10] leds: bcm6328, bcm6358: use struct led_init_data when registering

By using struct led_init_data when registering we do not need to parse `label` DT property nor `linux,default-trigger` property. Signed-off-by: Marek Behún Cc: Álvaro Fernández Rojas Cc: Kevin Cernekee Cc: Jaedon Shin --- drivers/leds/leds-bcm6328.c | 10 --

[PATCH leds v1 08/10] leds: is31fl319x: use struct led_init_data when registering

By using struct led_init_data when registering we do not need to parse `label` DT property nor `linux,default-trigger` property. This driver needed bigger refactor because it first parsed DT for all LEDs and only after that started registering them. Signed-off-by: Marek Behún Cc: H. Nikolaus

[PATCH leds v1 00/10] Start moving parsing of `linux,default-trigger` to LED core (a cleanup of LED drivers)

Hi, this series is also available at https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/log/?h=leds-cleanup-for-pavel this is a cleanup of some LED subsystem drivers. The main reason behind this is that I wanted to avoid code repetition by moving the parsing of

[PATCH leds v1 07/10] leds: is31fl32xx: use struct led_init_data when registering

By using struct led_init_data when registering we do not need to parse `label` DT property nor `linux,default-trigger` property. This driver needed small refactoring for this to work nicely. Signed-off-by: Marek Behún Cc: H. Nikolaus Schaller Cc: David Rivshin ---

[PATCH leds v1 03/10] leds: lm3697: use struct led_init_data when registering

By using struct led_init_data when registering we do not need to parse `label` DT property nor `linux,default-trigger` property. Previously if the `label` DT property was not present, the code composed name for the LED in the form "parent_name::" For backwards compatibility we therefore set

[PATCH leds v1 04/10] leds: max77650: use struct led_init_data when registering

By using struct led_init_data when registering we do not need to parse `label` DT property nor `linux,default-trigger` property. Previously if the `label` DT property was not present, the code composed name for the LED in the form "max77650::" For backwards compatibility we therefore set

[PATCH leds v1 01/10] leds: parse linux,default-trigger DT property in LED core

Do parsing of `linux,default-trigger` DT property to LED core. Currently it is done in many different drivers and the code is repeated. This commit removes the parsing only from drivers where the removal is simple, i.e. those which pass struct led_init_data with fwnode handle to the LED classdev

Re: [PATCH net-next 0/7] rcu: prevent RCU_LOCKDEP_WARN() from swallowing the condition

On Wed, Sep 16, 2020 at 11:45:21AM -0700, Jakub Kicinski wrote: > Hi! > > So I unfolded the RFC patch into smaller chunks and fixed an issue > in SRCU pointed out by build bot. Build bot has been quiet for > a day but I'm not 100% sure it's scanning my tree, so let's > give these patches some ML

[PATCH v4 00/10] Support qcom USB3+DP combo phy (or type-c phy)

This patch series is based on v12 of the msm DP driver submission[1] plus a compliance patch[2]. In the v5 patch series review I suggested that the DP PHY and PLL be split out of the drm driver and moved to the qmp phy driver. This patch series does that, but it is still marked as an RFC because

[PATCH v4 04/10] phy: qcom-qmp: Move 'serdes' and 'cfg' into 'struct qcom_phy'

The serdes I/O region is where the PLL for the phy is controlled. Sometimes the PLL is shared between multiple phys, for example in the PCIe case where there are three phys inside the same wrapper. Other times the PLL is for a single phy, i.e. some USB3 phys. To complete the trifecta we have the

[PATCH v4 09/10] clk: qcom: dispcc: Update DP clk ops for phy design

The clk_rcg2_dp_determine_rate() function is used for the DP pixel clk. This function should return the rate that can be achieved by the pixel clk in 'struct clk_rate_request::rate' and match the logic similar to what is seen in clk_rcg2_dp_set_rate(). But that isn't the case. Instead the code

[PATCH v4 08/10] phy: qcom-qmp: Add support for sc7180 DP phy

Add the necessary compatible strings and phy data for the sc7180 USB3+DP combo phy. Cc: Jeykumar Sankaran Cc: Chandan Uddaraju Cc: Vara Reddy Cc: Tanmay Shah Cc: Bjorn Andersson Cc: Manu Gautam Cc: Sandeep Maheswaram Cc: Douglas Anderson Cc: Sean Paul Cc: Jonathan Marek Cc: Dmitry

[PATCH v4 07/10] phy: qcom-qmp: Add support for DP in USB3+DP combo phy

Add support for the USB3 + DisplayPort (DP) "combo" phy to the qmp phy driver. We already have support for the USB3 part of the combo phy, so most additions are for the DP phy. Split up the qcom_qmp_phy{enable,disable}() functions into the phy init, power on, power off, and exit functions that

[PATCH v4 02/10] phy: qcom-qmp: Move phy mode into struct qmp_phy

The phy mode pertains to the phy itself, i.e. 'struct qmp_phy', not the wrapper, i.e. 'struct qcom_qmp'. Move the phy mode into the phy structure to more accurately reflect what is going on. This also cleans up 'struct qcom_qmp' so that it can eventually be the place where qmp wrapper wide data is

Re: [PATCH] gpio: aspeed: fix ast2600 bank properties

On Thu, 17 Sep 2020, at 06:12, rentao.b...@gmail.com wrote: > From: Tao Ren > > GPIO_U is mapped to the least significant byte of input/output mask, and > the byte in "output" mask should be 0 because GPIO_U is input only. All > the other bits need to be 1 because GPIO_V/W/X support both

[PATCH v4 05/10] phy: qcom-qmp: Get dp_com I/O resource by index

The dp_com resource is always at index 1 according to the dts files in the kernel. Get this resource by index so that we don't need to make future additions to the DT binding use 'reg-names'. Cc: Jeykumar Sankaran Cc: Chandan Uddaraju Cc: Vara Reddy Cc: Tanmay Shah Cc: Bjorn Andersson Cc:

[PATCH v4 06/10] phy: qcom-qmp: Use devm_platform_ioremap_resource() to simplify

We can use the wrapper API here to save some lines and remove the need for the 'base' and 'res' local variable. Suggested-by: Bjorn Andersson Cc: Jeykumar Sankaran Cc: Chandan Uddaraju Cc: Vara Reddy Cc: Tanmay Shah Cc: Bjorn Andersson Cc: Manu Gautam Cc: Sandeep Maheswaram Cc: Douglas

[PATCH v4 10/10] drm/msm/dp: Use qmp phy for DP PLL and PHY

Make the necessary changes to the DP driver to use the qmp phy from the common phy framework instead of rolling our own in the drm subsystem. This also removes the PLL code and adds proper includes so things build. Cc: Jeykumar Sankaran Cc: Chandan Uddaraju Cc: Vara Reddy Cc: Tanmay Shah Cc:

[PATCH v4 01/10] dt-bindings: phy: qcom,qmp-usb3-dp: Add DP phy information

This binding only describes the USB phy inside the USB3 + DP "combo" phy. Add information for the DP phy and describe the sub-nodes that represent the DP and USB3 phys that exist inside the combo wrapper. Remove reg-names from required properties because it isn't required nor used by the kernel

[PATCH v4 03/10] phy: qcom-qmp: Remove 'initialized' in favor of 'init_count'

We already track if any phy inside the qmp wrapper has been initialized by means of the struct qcom_qmp::init_count member. Let's drop the duplicate 'initialized' member to simplify the code a bit. Cc: Jeykumar Sankaran Cc: Chandan Uddaraju Cc: Vara Reddy Cc: Tanmay Shah Reviewed-by: Bjorn

Re: [PATCH v3 04/10] PCI/RCEC: Add pcie_walk_rcec() to walk associated RCiEPs

On Tue, Sep 15, 2020 at 09:09:20AM -0700, Sean V Kelley wrote: > Walking the bus with an RCEC as it is probed in the portdrv_pci.c can be > done with both its own bus (bitmap) and with supported associated bus > ranges. In that walk I’m able to find all the associated endpoints via both > bitmap

Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver

On Wed, 2020-09-16 at 10:22 +0200, Greg Kroah-Hartman wrote: > On Wed, Sep 16, 2020 at 11:02:39AM +0300, Oded Gabbay wrote: > > On Wed, Sep 16, 2020 at 10:41 AM Greg Kroah-Hartman > > wrote: > > > On Wed, Sep 16, 2020 at 09:36:23AM +0300, Oded Gabbay wrote: > > > > On Wed, Sep 16, 2020 at 9:25 AM

[PATCH net] ethtool: add and use message type for tunnel info reply

Tunnel offload info code uses ETHTOOL_MSG_TUNNEL_INFO_GET message type (cmd field in genetlink header) for replies to tunnel info netlink request, i.e. the same value as the request have. This is a problem because we are using two separate enums for userspace to kernel and kernel to userspace

Re: [PATCH] cma: make number of CMA areas dynamic, remove CONFIG_CMA_AREAS

On 9/16/20 2:14 AM, Song Bao Hua (Barry Song) wrote: >>> -Original Message- >>> From: Mike Kravetz [mailto:mike.krav...@oracle.com] >>> Sent: Wednesday, September 16, 2020 8:57 AM >>> To: linux...@kvack.org; linux-kernel@vger.kernel.org; >>> linux-arm-ker...@lists.infradead.org;

Re: [PATCH 3/5] dt-bindings: pci: qcom: Document PCIe bindings for SM8250 SoC

On Wed 16 Sep 08:19 CDT 2020, Manivannan Sadhasivam wrote: > Document the PCIe DT bindings for SM8250 SoC. The PCIe IP is similar to > the one used on SDM845, hence just add the compatible. > > Signed-off-by: Manivannan Sadhasivam > --- > Documentation/devicetree/bindings/pci/qcom,pcie.txt | 5

Re: [PATCH 2/5] phy: qualcomm: phy-qcom-qmp: Add PCIe PHY support for SM8250 SoC

On Wed 16 Sep 08:19 CDT 2020, Manivannan Sadhasivam wrote: As with the controller patches, it's desirable for $subject to be succinct and have the prefix match other commits. So I suggest you go with "phy: qcom-qmp: Add SM8250 PCIe QMP PHYs" Apart from that I think this change looks good.

Re: [PATCH v3] ima: Fix NULL pointer dereference in ima_file_hash

On Wed, 2020-09-16 at 18:02 +, KP Singh wrote: > From: KP Singh > > ima_file_hash can be called when there is no iint->ima_hash available > even though the inode exists in the integrity cache. It is fairly > common for a file to not have a hash. (e.g. an mknodat, prior to the > file being

Re: [RFC PATCH 08/35] KVM: SVM: Prevent debugging under SEV-ES

On Wed, Sep 16, 2020 at 03:27:13PM -0500, Tom Lendacky wrote: > On 9/16/20 11:49 AM, Sean Christopherson wrote: > > On Wed, Sep 16, 2020 at 11:38:38AM -0500, Tom Lendacky wrote: > >> > >> > >> On 9/16/20 11:02 AM, Sean Christopherson wrote: > >>> On Wed, Sep 16, 2020 at 10:11:10AM -0500, Tom

Re: [PATCH v3 04/10] PCI/RCEC: Add pcie_walk_rcec() to walk associated RCiEPs

On Mon, Sep 14, 2020 at 09:55:53AM -0700, Sean V Kelley wrote: > On 11 Sep 2020, at 17:50, Bjorn Helgaas wrote: > > On Fri, Sep 11, 2020 at 04:16:03PM -0700, Sean V Kelley wrote: > > > I’ve done some experimenting with this approach, and I think > > > there may be a problem of just walking the

[GIT PULL] ARM: at91: DT for 5.10

Arnd, Olof, The bulk of the changes are fixes for issues found by dtbs_check. A new board is also introduced. The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at:

URGENT PAYMENT

Attn: Beneficiary, This to your notice that International Monetary Fund (IMF) have mobilized all compensate fund Scam and fraud victims awarded in past due to complains of Beneficiaries concern banks defraud beneficiaries through Western Union/MoneyGram/ATM Visa Card and etc, You are

Re: [PATCH 1/5] dt-bindings: phy: qcom,qmp: Document SM8250 PCIe PHY bindings

On Wed 16 Sep 08:19 CDT 2020, Manivannan Sadhasivam wrote: > Document the DT bindings of below PCIe PHY versions used on SM8250: > > QMP GEN3x1 PHY - 1 lane > QMP GEN3x2 PHY - 2 lanes > QMP Modem PHY - 2 lanes How about something like "Add the three PCIe PHYs found in SM8250 to the QMP

drivers/staging/media/atomisp//pci/ia_css_firmware.h:52:29: warning: 'struct device' declared inside parameter list will not be visible outside of this definition or declaration

: i386-randconfig-r011-20200916 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): git checkout 13c01139b17163c9b2aa543a9c39f8bbc875b625 # save the attached .config to linux build tree make W=1 ARCH=i386 If you fix the issue, kindly

Re: [PATCH] net: dsa: mt7530: Add some return-value checks

On Wed, Sep 16, 2020 at 08:50:17PM +0100, Alex Dewar wrote: > In mt7531_cpu_port_config(), if the variable port is neither 5 nor 5, This should read "neither 5 nor 6", obviously. I'll fix in v2.

[PATCH net] drivers/net/wan/hdlc: Set skb->protocol before transmitting

This patch sets skb->protocol before transmitting frames on the HDLC device, so that a user listening on the HDLC device with an AF_PACKET socket will see outgoing frames' sll_protocol field correctly set and consistent with that of incoming frames. 1. Control frames in hdlc_cisco and hdlc_ppp

Re: [PATCH next] gpiolib: check for parent device in devprop_gpiochip_set_names()

On Wed, 16 Sep 2020 at 16:47, Bartosz Golaszewski wrote: > > On Wed, Sep 16, 2020 at 4:29 PM Andy Shevchenko > wrote: > > > > On Wed, Sep 16, 2020 at 03:43:27PM +0200, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski > > > > > > It's possible for a GPIO chip to not have a parent

Re: [patch 00/13] preempt: Make preempt count unconditional

On Wed, Sep 16, 2020 at 11:43:02PM +0200, Daniel Vetter wrote: > On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney wrote: > > > > On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote: > > > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney > > > wrote: > > > > > > > > On Wed, Sep 16,

Re: [PATCH] net: dsa: mt7530: Add some return-value checks

[snip] > > > > /* Enable Mediatek header mode on the cpu port */ > > mt7530_write(priv, MT7530_PVC_P(port), > > @@ -2275,7 +2279,7 @@ mt7531_cpu_port_config(struct dsa_switch *ds, int > > port) > > { > > struct mt7530_priv *priv = ds->priv; > > phy_interface_t interface; > > -

[PATCH bpf-next v3 3/6] selftests/bpf: ksyms_btf to test typed ksyms

Selftests for typed ksyms. Tests two types of ksyms: one is a struct, the other is a plain int. This tests two paths in the kernel. Struct ksyms will be converted into PTR_TO_BTF_ID by the verifier while int typed ksyms will be converted into PTR_TO_MEM. Signed-off-by: Hao Luo ---

[PATCH bpf-next v3 5/6] bpf: Introduce bpf_this_cpu_ptr()

Add bpf_this_cpu_ptr() to help access percpu var on this cpu. This helper always returns a valid pointer, therefore no need to check returned value for NULL. Also note that all programs run with preemption disabled, which means that the returned pointer is stable during all the execution of the

[PATCH bpf-next v3 1/6] bpf: Introduce pseudo_btf_id

Pseudo_btf_id is a type of ld_imm insn that associates a btf_id to a ksym so that further dereferences on the ksym can use the BTF info to validate accesses. Internally, when seeing a pseudo_btf_id ld insn, the verifier reads the btf_id stored in the insn[0]'s imm field and marks the dst_reg as

[PATCH bpf-next v3 6/6] bpf/selftests: Test for bpf_per_cpu_ptr() and bpf_this_cpu_ptr()

Test bpf_per_cpu_ptr() and bpf_this_cpu_ptr(). Test two paths in the kernel. If the base pointer points to a struct, the returned reg is of type PTR_TO_BTF_ID. Direct pointer dereference can be applied on the returned variable. If the base pointer isn't a struct, the returned reg is of type

[PATCH bpf-next v3 4/6] bpf: Introduce bpf_per_cpu_ptr()

Add bpf_per_cpu_ptr() to help bpf programs access percpu vars. bpf_per_cpu_ptr() has the same semantic as per_cpu_ptr() in the kernel except that it may return NULL. This happens when the cpu parameter is out of range. So the caller must check the returned value. Acked-by: Andrii Nakryiko

[PATCH bpf-next v3 2/6] bpf/libbpf: BTF support for typed ksyms

If a ksym is defined with a type, libbpf will try to find the ksym's btf information from kernel btf. If a valid btf entry for the ksym is found, libbpf can pass in the found btf id to the verifier, which validates the ksym's type and value. Typeless ksyms (i.e. those defined as 'void') will not

[PATCH bpf-next v3 0/6] bpf: BTF support for ksyms

v2 -> v3: - Rename functions and variables in verifier for better readability. - Stick to logging message convention in libbpf. - Move bpf_per_cpu_ptr and bpf_this_cpu_ptr from trace-specific helper set to base helper set. - More specific test in ksyms_btf. - Fix return type cast in

RE: [PATCH v3] hv_netvsc: Add validation for untrusted Hyper-V values

> -Original Message- > From: Andrea Parri (Microsoft) > Sent: Wednesday, September 16, 2020 5:47 AM > To: linux-kernel@vger.kernel.org > Cc: KY Srinivasan ; Haiyang Zhang > ; Stephen Hemminger > ; Wei Liu ; linux- > hyp...@vger.kernel.org; Andres Beltran ; Michael > Kelley ; Saruhan

linux-next: Signed-off-by missing for commit in the net-next tree

Hi all, Commits 0d2ffdc8d400 ("net/mlx5: Don't call timecounter cyc2time directly from 1PPS flow") 87f3495cbe8d ("net/mlx5: Release clock lock before scheduling a PPS work") aac2df7f022e ("net/mlx5: Rename ptp clock info") fb609b5112bd ("net/mlx5: Always use container_of to find mdev

Re: [PATCH net-next] net: stmmac: Add support to Ethtool get/set ring parameters

From: Wong Vee Khee Date: Wed, 16 Sep 2020 15:40:20 +0800 > +int stmmac_reinit_ringparam(struct net_device *dev, u32 rx_size, u32 tx_size) > +{ > + struct stmmac_priv *priv = netdev_priv(dev); > + int ret = 0; > + > + if (netif_running(dev)) > + stmmac_release(dev); ...

Re: [PATCH leds + devicetree v2 2/2] leds: trigger: netdev: parse `trigger-sources` from device tree

On 9/16/20 2:15 AM, Marek Behun wrote: On Tue, 15 Sep 2020 23:35:25 +0200 Jacek Anaszewski wrote: Hi Marek, On 9/15/20 5:26 PM, Marek Behún wrote: Allow setting netdev LED trigger as default when given LED DT node has the `trigger-sources` property pointing to a node corresponding to a

Re: [PATCH RFC 1/4] mm/page_alloc: convert "report" flag of __free_one_page() to a proper flag

On Wed, Sep 16, 2020 at 11:34 AM David Hildenbrand wrote: > > Let's prepare for additional flags and avoid long parameter lists of bools. > Follow-up patches will also make use of the flags in __free_pages_ok(), > however, I wasn't able to come up with a better name for the type - should > be

Re: [patch 00/13] preempt: Make preempt count unconditional

On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney wrote: > > On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote: > > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote: > > > > > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote: > > > > On Tue, Sep 15, 2020 at 7:35

Re: [RFC PATCH v7 11/23] sched/fair: core wide cfs task priority comparison

On 9/16/20 8:57 AM, Li, Aubrey wrote: Here are the uperf results of the various patchsets. Note, that disabling smt is better for these tests and that that presumably reflects the overall overhead of core scheduling which went from bad to really bad. The primary focus in this email is to

linux-next: Signed-off-by missing for commit in the irqchip tree

Hi all, Commit 0502fd082b11 ("fixup! irqchip/gic: Handle non-standard SGI deactivation on Samsung's Franken-GIC") is missing a Signed-off-by from its author and committer. -- Cheers, Stephen Rothwell pgpjex9FUomkn.pgp Description: OpenPGP digital signature

linux-next: Signed-off-by missing for commit in the gfs2 tree

Hi all, Commit b15a7defc994 ("gfs2: convert to use DEFINE_SEQ_ATTRIBUTE macro") is missing a Signed-off-by from its committer. -- Cheers, Stephen Rothwell pgpGwlWDaxL8Y.pgp Description: OpenPGP digital signature

[PATCH] mm/page_alloc.c: fix early params garbage value accesses

From: Mateusz Nosek Previously in '__init early_init_on_alloc' and '__init early_init_on_free' the return values from 'kstrtobool' were not handled properly. That caused potential garbage value read from variable 'bool_result'. Introduced patch fixes error handling. Signed-off-by: Mateusz Nosek

Re: [PATCH v2 13/13] x86/platform/uv: Update Copyrights to conform to HPE standards

Acked-by: Steve Wahl On Wed, Sep 16, 2020 at 02:20:39PM -0500, Mike Travis wrote: > Add Copyrights to those files that have been updated for UV5 changes. > > Signed-off-by: Mike Travis > --- > arch/x86/include/asm/uv/bios.h | 1 + > arch/x86/include/asm/uv/uv_hub.h| 1 + >

Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40

On Mon, Feb 24, 2020 at 4:20 AM Thomas Backlund wrote: > > Den 09-01-2020 kl. 17:12, skrev Christian König: > > Hi Christoph, > > > > Am 09.01.20 um 15:14 schrieb Christoph Hellwig: > >> Hi Woody, > >> > >> sorry for the late reply, I've been off to a vacation over the holidays. > >> > >> On Sat,

Re: [PATCH net-next 2/3] net: dp83869: Add ability to advertise Fiber connection

On Wed, Sep 16, 2020 at 03:54:34PM -0500, Dan Murphy wrote: > Andrew > > On 9/15/20 3:17 PM, Andrew Lunn wrote: > > > + linkmode_set_bit(ETHTOOL_LINK_MODE_100baseFX_Full_BIT, > > > + phydev->supported); > > > +

Re: [RFC v7 11/19] lockdep: Fix recursive read lock related safe->unsafe detection

On Thu, 2020-09-17 at 00:14 +0800, Boqun Feng wrote: > Found a way to resolve this while still keeping the BFS. Every time when > we want to enqueue a lock_list, we basically enqueue a whole dep list of > entries from the previous lock_list, so we can use a trick here: instead > enqueue all the

RE: [EXTERNAL] Re: [PATCH RFC v1 08/18] x86/hyperv: handling hypercall page setup for root

> > On Tue, Sep 15, 2020 at 12:32:29PM +0200, Vitaly Kuznetsov wrote: > > Wei Liu writes: > > > > > When Linux is running as the root partition, the hypercall page will > > > have already been setup by Hyper-V. Copy the content over to the > > > allocated page. > > > > And we can't setup a new

[RFC PATCH] Add bridge driver to connect sensors to CIO2 device via software nodes on ACPI platforms

Currently on ACPI platforms, sensors that are intended to be connected to a CIO2 device for use with the ipu3-cio2 driver lack the necessary connection information in firmware. This patch adds a module to parse the connection properties from the SSDB buffer in DSDT and build the connection using

Re: [PATCH v5 1/3] PCI/IOV: Mark VFs as not implementing PCI_COMMAND_MEMORY

On Thu, Sep 10, 2020 at 10:59:55AM -0400, Matthew Rosato wrote: > For VFs, the Memory Space Enable bit in the Command Register is > hard-wired to 0. > > Add a new bit to signify devices where the Command Register Memory > Space Enable bit does not control the device's response to MMIO > accesses.

Re: [PATCH v2 0/3] PCI: iproc: Add fixes to pcie iproc

On Tue, Sep 15, 2020 at 07:15:38PM +0530, Srinath Mannam wrote: > This patch series contains fixes and improvements to pcie iproc driver. > > This patch set is based on Linux-5.9.0-rc2. > > Changes from v1: > - Addressed Bjorn's review comments > - pcie_print_link_status is used to print

Re: [PATCH RFC 2/4] mm/page_alloc: place pages to tail in __putback_isolated_page()

On Wed, Sep 16, 2020 at 11:34 AM David Hildenbrand wrote: > > __putback_isolated_page() already documents that pages will be placed to > the tail of the freelist - this is, however, not the case for > "order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be > the case for all

Re: [PATCH v6 4/4] bus: mhi: Add userspace client interface driver

On 9/16/20 12:56 PM, Hemant Kumar wrote: > diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig > index 6a217ff..8aebe8b 100644 > --- a/drivers/bus/mhi/Kconfig > +++ b/drivers/bus/mhi/Kconfig > @@ -20,3 +20,16 @@ config MHI_BUS_DEBUG >Enable debugfs support for use with the MHI

Re: [PATCH] cma: make number of CMA areas dynamic, remove CONFIG_CMA_AREAS

cma areas >> could be dynamic. It turns out it causes a kernel panic on arm64 during >> system boot as the >> returned address from memblock_alloc is invalid before paging_init() is done >> on arm64. >> > > Thank you! > > Based on your analysis, I am co

Re: [PATCH 5/5] pci: controller: dwc: qcom: Harcode PCIe config SID

s/Harcode/Hardcode/ (in subject) Also fix subject format as for 4/5. On Wed, Sep 16, 2020 at 06:50:00PM +0530, Manivannan Sadhasivam wrote: > Hardcode the PCIe config SID table value. This is needed to avoid random > MHI failure observed during reboot on SM8250. > > Signed-off-by: Jonathan

Re: [PATCH v5] PCI/ACS: Enable PCI_ACS_TB and disable only when needed for ATS

On Tue, Jul 14, 2020 at 01:15:40PM -0700, Rajat Jain wrote: > The ACS "Translation Blocking" bit blocks the translated addresses from > the devices. We don't expect such traffic from devices unless ATS is > enabled on them. A device sending such traffic without ATS enabled, > indicates malicious

Re: [PATCH v4 4/4] PCI/ACS: Enable PCI_ACS_TB for untrusted/external-facing devices

On Tue, Jul 07, 2020 at 03:46:04PM -0700, Rajat Jain wrote: > When enabling ACS, enable translation blocking for external facing ports > and untrusted devices. > > Signed-off-by: Rajat Jain Applied (slightly modified) to pci/acs for v5.10, thanks! I think the warning is superfluous because

Re: [PATCH v2 01/13] x86/platform/uv: Remove UV BAU TLB Shootdown Handler

Acked-by: Steve Wahl On Wed, Sep 16, 2020 at 02:20:27PM -0500, Mike Travis wrote: > The Broadcast Assist Unit (BAU) TLB shootdown handler is being rewritten > to become the UV BAU APIC driver. It is designed to speed up sending > IPI's to selective CPUs within the system. Remove the current

Re: [PATCH 4/5] pci: controller: dwc: qcom: Add PCIe support for SM8250 SoC

On Wed, Sep 16, 2020 at 06:49:59PM +0530, Manivannan Sadhasivam wrote: > The PCIe IP on SM8250 SoC is similar to the one used on SDM845. Hence > the support is added reusing the 2.7.0 ops. Only difference is the need > of ATU base, which will be fetched opionally if provided by DT/ACPI. > >

Re: [PATCH v2 02/13] x86/platform/uv: Remove SCIR MMR references for UVY systems.

Acked-by: Steve Wahl On Wed, Sep 16, 2020 at 02:20:28PM -0500, Mike Travis wrote: > UV class systems no longer use System Controller for monitoring of CPU > activity provided by this driver. Other methods have been developed > for BIOS and the management controller (BMC). This patch removes

[GIT PULL] ARM: at91: SoC for 5.10

Arnd, Olof, As usual, only PM related work in this pull request. A new mode is added, improving the wakeup latency on sam9x60. The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at:

Re: slab-out-of-bounds in iov_iter_revert()

On Sat, 2020-09-12 at 00:55 +0100, Al Viro wrote: > On Fri, Sep 11, 2020 at 05:59:04PM -0400, Qian Cai wrote: > > Super easy to reproduce on today's mainline by just fuzzing for a few > > minutes > > on virtiofs (if it ever matters). Any thoughts? > > Usually happens when ->direct_IO() fucks up

[PATCH v13 05/15] mtd: spi-nor: sfdp: get command opcode extension type from BFPT

Re: [PATCH v2 1/3] soundwire: qcom: clear BIT FIELDs before value set.

According to usage (bitfields.h) of REG_FIELDS, Modify is: reg &= ~REG_FIELD_C; reg |= FIELD_PREP(REG_FIELD_C, c); if this is indeed the case, all the code in cadence_master.c is also broken, e.g: dpn_config = cdns_readl(cdns, dpn_config_off); dpn_config |=

[PATCH v13 08/15] mtd: spi-nor: core: do 2 byte reads for SR and FSR in DTR mode

Re: [PATCH 5.8 000/177] 5.8.10-rc1 review

On 9/16/20 9:26 AM, Greg Kroah-Hartman wrote: On Wed, Sep 16, 2020 at 08:26:48AM -0600, Shuah Khan wrote: On 9/16/20 12:29 AM, Greg Kroah-Hartman wrote: On Tue, Sep 15, 2020 at 08:54:24PM -0600, Shuah Khan wrote: On 9/15/20 3:06 PM, Shuah Khan wrote: On 9/15/20 8:11 AM, Greg Kroah-Hartman

Re: Changing vma->vm_file in dma_buf_mmap()

On Wed, Sep 16, 2020 at 4:14 PM Christian König wrote: > > Am 16.09.20 um 16:07 schrieb Jason Gunthorpe: > > On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote: > > > >> But within the driver, we generally need thousands of these, and that > >> tends to bring fd exhaustion problems

Re: [PATCH] iommu/amd: fix interrupt remapping for avic

On 9/15/20 8:19 PM, Joao Martins wrote: On 9/15/20 1:30 PM, Suravee Suthikulpanit wrote: On 9/15/20 6:25 PM, Maxim Levitsky wrote: On Mon, 2020-09-14 at 21:48 +0700, Suravee Suthikulpanit wrote: Could you please try with the following patch instead? --- a/drivers/iommu/amd/iommu.c +++

[PATCH v2 0/1] PCI: pcie_bus_config can be set at build time

v2: Add more description text in the new Kconfig settings (Bjorn). v1: Original Jim Quinlan (1): PCI: pcie_bus_config can be set at build time drivers/pci/Kconfig | 56 + drivers/pci/pci.c | 12 ++ 2 files changed, 68 insertions(+) --

[PATCH v2 1/1] PCI: pcie_bus_config can be set at build time

The Kconfig is modified so that the pcie_bus_config setting can be done at build time in the same manner as the CONFIG_PCIEASPM_ choice. The pci_bus_config setting may still be overridden by the bootline param. Signed-off-by: Jim Quinlan --- drivers/pci/Kconfig | 56

Re: [PATCH v2 00/10] Independent per-CPU data section for nVHE

Hi Will, On Mon, Sep 14, 2020 at 06:40:09PM +0100, Will Deacon wrote: > Hi David, > > On Thu, Sep 03, 2020 at 11:17:02AM +0200, David Brazdil wrote: > > Introduce '.hyp.data..percpu' as part of ongoing effort to make nVHE > > hyp code self-contained and independent of the rest of the kernel. > >

Re: [RESEND PATCH v2] iio: adc: stm32-adc: fix runtime autosuspend delay when slow polling

On 7/1/20 4:55 PM, Fabrice Gasnier wrote: > When the ADC is runtime suspended and starting a conversion, the stm32-adc > driver calls pm_runtime_get_sync() that gets cascaded to the parent > (e.g. runtime resume of stm32-adc-core driver). This also kicks the > autosuspend delay (e.g. 2s) of the

Re: [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support

- Original Message - > On Wed, Sep 16, 2020 at 08:52:07AM -0400, Qian Cai wrote: > > On Tue, 2020-09-15 at 16:30 +0200, pet...@infradead.org wrote: > > > On Tue, Sep 15, 2020 at 08:48:17PM +0800, Boqun Feng wrote: > > > > I think this happened because seqcount_##lockname##_init() is

Re: [PATCH v5 3/5] mm: introduce memfd_secret system call to create "secret" memory areas

Hi Mike, On 9/16/20 12:35 AM, Mike Rapoport wrote: > From: Mike Rapoport > > > Signed-off-by: Mike Rapoport > --- > arch/Kconfig | 7 + > arch/x86/Kconfig | 1 + > include/uapi/linux/magic.h | 1 + > include/uapi/linux/secretmem.h | 8 + >

[tip: x86/irq] PCI: vmd: Dont abuse vector irqomain as parent

The following commit has been merged into the x86/irq branch of tip: Commit-ID: 585dfe8abc4460810c07114b64aca10a74fa2718 Gitweb: https://git.kernel.org/tip/585dfe8abc4460810c07114b64aca10a74fa2718 Author:Thomas Gleixner AuthorDate:Wed, 26 Aug 2020 13:16:31 +02:00

Re: [PATCH v37 02/24] x86/cpufeatures: x86/msr: Add Intel SGX Launch Control hardware bits

On Tue, Sep 15, 2020 at 09:02:50AM -0500, Josh Poimboeuf wrote: > On Tue, Sep 15, 2020 at 03:39:29PM +0200, Borislav Petkov wrote: > > On Tue, Sep 15, 2020 at 08:27:25AM -0500, Josh Poimboeuf wrote: > > > I see the v37 missing patches now, but they're not threaded with the > > > original thread. >

Re: [Intel-gfx] [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

On Wed, 2020-09-16 at 10:43 +0300, Jani Nikula wrote: > On Tue, 15 Sep 2020, Rodrigo Vivi wrote: > > On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote: > > > Since we're about to start adding support for Intel's magic HDR > > > backlight interface over DPCD, we need to ensure we're

[tip: x86/irq] x86/msi: Move compose message callback where it belongs

The following commit has been merged into the x86/irq branch of tip: Commit-ID: b0a19555efd098183db0ee3ad52a3cd3bfbd1ba2 Gitweb: https://git.kernel.org/tip/b0a19555efd098183db0ee3ad52a3cd3bfbd1ba2 Author:Thomas Gleixner AuthorDate:Wed, 26 Aug 2020 13:16:33 +02:00

Re: [RFC][PATCH 1/4] acpi: Use CPUIDLE_FLAG_TIMER_STOP

On Tue, Sep 15, 2020 at 06:26:52PM +0200, Rafael J. Wysocki wrote: > On Tue, Sep 15, 2020 at 12:44 PM Peter Zijlstra wrote: > > > > Make acpi_processor_idle use the common broadcast code, there's no > > reason not to. This also removes some RCU usage after > > rcu_idle_enter(). > > > >

[tip: x86/irq] iommu/vt-d: Consolidate irq domain getter

The following commit has been merged into the x86/irq branch of tip: Commit-ID: 60e5a9397c0c4b7cecf05fec1aef8fe2ae5c9f3c Gitweb: https://git.kernel.org/tip/60e5a9397c0c4b7cecf05fec1aef8fe2ae5c9f3c Author:Thomas Gleixner AuthorDate:Wed, 26 Aug 2020 13:16:37 +02:00

[tip: x86/irq] iommu/amd: Consolidate irq domain getter

The following commit has been merged into the x86/irq branch of tip: Commit-ID: 192a99f4bd9d1d546ca276e058761a79af575744 Gitweb: https://git.kernel.org/tip/192a99f4bd9d1d546ca276e058761a79af575744 Author:Thomas Gleixner AuthorDate:Wed, 26 Aug 2020 13:16:38 +02:00

Re: [PATCH v2] arm64: bpf: Fix branch offset in JIT

Hi Will, On Tue, Sep 15, 2020 at 02:11:03PM +0100, Will Deacon wrote: [...] > > continue; > > } > > - if (ctx->image == NULL) > > - ctx->offset[i] = ctx->idx; > > if (ret) > > return ret; > > } > > +

[tip: x86/irq] iommu/irq_remapping: Consolidate irq domain lookup

The following commit has been merged into the x86/irq branch of tip: Commit-ID: 6b6256e616f7e10c4434cfcd32371fc33ca94e48 Gitweb: https://git.kernel.org/tip/6b6256e616f7e10c4434cfcd32371fc33ca94e48 Author:Thomas Gleixner AuthorDate:Wed, 26 Aug 2020 13:16:39 +02:00

Re: [PATCH v2] software_node: Add support for fwnode_graph*() family of functions

On Wed, Sep 16, 2020 at 04:06:25PM +0100, Kieran Bingham wrote: > On 16/09/2020 14:22, Dan Scally wrote: > > On 16/09/2020 10:17, Sakari Ailus wrote: > >> On Wed, Sep 16, 2020 at 12:28:27AM +0100, Daniel Scally wrote: Thank you, Kieran, for detailed explanation, one small correction below though.

Re: [PATCH 0/3] PM operations for software nodes

+Sakari On Tue, Aug 25, 2020 at 04:59:48PM +0300, Heikki Krogerus wrote: > Hi guys, > > Unfortunately the last patch depends on this: > https://lore.kernel.org/linux-usb/20200821131101.81915-1-heikki.kroge...@linux.intel.com/ > > Would it be easiest that Felipe took care of these (assuming they

<    1   2   3   4   5   6   7   8   9   10   >