Re: [PATCH v4 00/10] Support qcom USB3+DP combo phy (or type-c phy)
On 16-09-20, 16:11, Stephen Boyd wrote: > 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 there are a couple more things to do, mostly updating the > DT binding and getting agreement on how to structure the code. > > Eventually I believe the qmp phy driver will need to listen for type-c > notifiers or somehow know the type-c pinout being used so this driver > can program things slightly differently. Right now, I don't have any way > to test it though, so I've left it as future work. For some more > details, the DP phy and the USB3 phy share the same physical pins on the > SoC and those pins pretty much line up with a type-c pinout modulo some > CC pins for cable orientation detection logic that lives on the PMIC. So > the DP phy can use all four lanes or it can use two lanes and the USB3 > phy can use two lanes. In the hardware designs that I have access to it > is always two lanes for USB3 and two lanes for DP going through what > looks like a type-c pinout so this just hard codes that configuration in > the driver. Applied 1 thru 8, thanks -- ~Vinod
Re: [PATCH] tpm: of: avoid __va() translation for event log address
Le 28/09/2020 à 01:44, Jarkko Sakkinen a écrit : On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote: On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote: On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote: On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen wrote: On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote: The TPM event log is provided to the OS by the firmware, by loading it into an area in memory and passing the physical address via a node in the device tree. Currently, we use __va() to access the memory via the kernel's linear map: however, it is not guaranteed that the linear map covers this particular address, as we may be running under HIGHMEM on a 32-bit architecture, or running firmware that uses a memory type for the event log that is omitted from the linear map (such as EfiReserved). Makes perfect sense to the level that I wonder if this should have a fixes tag and/or needs to be backported to the stable kernels? AIUI, the code was written specifically for ppc64, which is a non-highmem, non-EFI architecture. However, when we start reusing this driver for ARM, this issue could pop up. The code itself has been refactored a couple of times, so I think it will require different versions of the patch for different generations of stable kernels. So perhaps just add Cc: , and wait and see how far back it applies cleanly? Yeah, I think I'll cc it with some note before the diffstat. I'm thinking to cap it to only 5.x kernels (at least first) unless it is dead easy to backport below that. I have this vauge recollection of pointing at this before and being told that it had to be __va for some PPC reason? Do check with the PPC people first, I see none on the CC list. Jason Thanks, added arch/powerpc maintainers. As far as I can see, memremap() won't work on PPC32 at least: IIUC, memremap() calls arch_memremap_wb() arch_memremap_wb() calls ioremap_cache() In case of failure, then ioremap_wt() and ioremap_wc() are tried. All ioremap calls end up in __ioremap_caller() which will return NULL in case you try to ioremap RAM. So the statement "So instead, use memremap(), which will reuse the linear mapping if it is valid, or create another mapping otherwise." seems to be wrong, at least for PPC32. Even for PPC64 which doesn't seem to have the RAM check, I can't see that it will "reuse the linear mapping". Christophe
[GIT PULL]: Generic PHY fixes for v5.9
Hi Greg, We have a leak fix for TI driver, please consider for v5.9 The following changes since commit ad7a7acaedcf45071c822b6c983f9c1e084041c9: phy: omap-usb2-phy: disable PHY charger detect (2020-08-31 14:30:59 +0530) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git tags/phy-fixes-2-5.9 for you to fetch changes up to 850280156f6421a404f2351bee07a0e7bedfd4c6: phy: ti: am654: Fix a leak in serdes_am654_probe() (2020-09-08 16:23:09 +0530) phy: Second round of fixes for 5.9 *) Fix of leak in TI phy driver Dan Carpenter (1): phy: ti: am654: Fix a leak in serdes_am654_probe() drivers/phy/ti/phy-am654-serdes.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- ~Vinod signature.asc Description: PGP signature
Re: [PATCH] KVM: SVM: Initialize ir_list and ir_list_lock regardless of AVIC enablement
Hi,
Are there any issues or concerns about this patch?
Thank you,
Suravee
On 9/22/20 3:44 PM, Suravee Suthikulpanit wrote:
The struct vcpu_svm.ir_list and ir_list_lock are being accessed even when
AVIC is not enabled, while current code only initialize the list and
the lock only when AVIC is enabled. This ended up trigger NULL pointer
dereference bug in the function vm_ir_list_del with the following
call trace:
svm_update_pi_irte+0x3c2/0x550 [kvm_amd]
? proc_create_single_data+0x41/0x50
kvm_arch_irq_bypass_add_producer+0x40/0x60 [kvm]
__connect+0x5f/0xb0 [irqbypass]
irq_bypass_register_producer+0xf8/0x120 [irqbypass]
vfio_msi_set_vector_signal+0x1de/0x2d0 [vfio_pci]
vfio_msi_set_block+0x77/0xe0 [vfio_pci]
vfio_pci_set_msi_trigger+0x25c/0x2f0 [vfio_pci]
vfio_pci_set_irqs_ioctl+0x88/0xb0 [vfio_pci]
vfio_pci_ioctl+0x2ea/0xed0 [vfio_pci]
? alloc_file_pseudo+0xa5/0x100
vfio_device_fops_unl_ioctl+0x26/0x30 [vfio]
? vfio_device_fops_unl_ioctl+0x26/0x30 [vfio]
__x64_sys_ioctl+0x96/0xd0
do_syscall_64+0x37/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Therefore, move the initialziation code before checking for AVIC enabled
so that it is always excuted.
Fixes: dfa20099e26e ("KVM: SVM: Refactor AVIC vcpu initialization into
avic_init_vcpu()")
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kvm/svm/avic.c | 2 --
arch/x86/kvm/svm/svm.c | 3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
index ac830cd50830..1ccf13783785 100644
--- a/arch/x86/kvm/svm/avic.c
+++ b/arch/x86/kvm/svm/avic.c
@@ -572,8 +572,6 @@ int avic_init_vcpu(struct vcpu_svm *svm)
if (ret)
return ret;
- INIT_LIST_HEAD(>ir_list);
- spin_lock_init(>ir_list_lock);
svm->dfr_reg = APIC_DFR_FLAT;
return ret;
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index c44f3e9140d5..714d791fe5a5 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -1225,6 +1225,9 @@ static int svm_create_vcpu(struct kvm_vcpu *vcpu)
svm_init_osvw(vcpu);
vcpu->arch.microcode_version = 0x0165;
+ INIT_LIST_HEAD(>ir_list);
+ spin_lock_init(>ir_list_lock);
+
return 0;
free_page4:
[PATCH net v3] net: phy: realtek: fix rtl8211e rx/tx delay config
There are two chip pins named TXDLY and RXDLY which actually adds the 2ns
delays to TXC and RXC for TXD/RXD latching. These two pins can config via
4.7k-ohm resistor to 3.3V hw setting, but also config via software setting
(extension page 0xa4 register 0x1c bit13 12 and 11).
The configuration register definitions from table 13 official PHY datasheet:
PHYAD[2:0] = PHY Address
AN[1:0] = Auto-Negotiation
Mode = Interface Mode Select
RX Delay = RX Delay
TX Delay = TX Delay
SELRGV = RGMII/GMII Selection
This table describes how to config these hw pins via external pull-high or pull-
low resistor.
It is a misunderstanding that mapping it as register bits below:
8:6 = PHY Address
5:4 = Auto-Negotiation
3 = Interface Mode Select
2 = RX Delay
1 = TX Delay
0 = SELRGV
So I removed these descriptions above and add related settings as below:
14 = reserved
13 = force Tx RX Delay controlled by bit12 bit11
12 = Tx Delay
11 = Rx Delay
10:0 = Test && debug settings reserved by realtek
Test && debug settings are not recommend to modify by default.
Fixes: f81dadbcf7fd ("net: phy: realtek: Add rtl8211e rx/tx delays config")
Signed-off-by: Willy Liu
---
drivers/net/phy/realtek.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
mode change 100644 => 100755 drivers/net/phy/realtek.c
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
old mode 100644
new mode 100755
index 95dbe5e..0f09609
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -1,6 +1,5 @@
// SPDX-License-Identifier: GPL-2.0+
-/*
- * drivers/net/phy/realtek.c
+/* drivers/net/phy/realtek.c
*
* Driver for Realtek PHYs
*
@@ -32,9 +31,9 @@
#define RTL8211F_TX_DELAY BIT(8)
#define RTL8211F_RX_DELAY BIT(3)
-#define RTL8211E_TX_DELAY BIT(1)
-#define RTL8211E_RX_DELAY BIT(2)
-#define RTL8211E_MODE_MII_GMII BIT(3)
+#define RTL8211E_CTRL_DELAYBIT(13)
+#define RTL8211E_TX_DELAY BIT(12)
+#define RTL8211E_RX_DELAY BIT(11)
#define RTL8201F_ISR 0x1e
#define RTL8201F_IER 0x13
@@ -246,16 +245,16 @@ static int rtl8211e_config_init(struct phy_device *phydev)
/* enable TX/RX delay for rgmii-* modes, and disable them for rgmii. */
switch (phydev->interface) {
case PHY_INTERFACE_MODE_RGMII:
- val = 0;
+ val = RTL8211E_CTRL_DELAY | 0;
break;
case PHY_INTERFACE_MODE_RGMII_ID:
- val = RTL8211E_TX_DELAY | RTL8211E_RX_DELAY;
+ val = RTL8211E_CTRL_DELAY | RTL8211E_TX_DELAY |
RTL8211E_RX_DELAY;
break;
case PHY_INTERFACE_MODE_RGMII_RXID:
- val = RTL8211E_RX_DELAY;
+ val = RTL8211E_CTRL_DELAY | RTL8211E_RX_DELAY;
break;
case PHY_INTERFACE_MODE_RGMII_TXID:
- val = RTL8211E_TX_DELAY;
+ val = RTL8211E_CTRL_DELAY | RTL8211E_TX_DELAY;
break;
default: /* the rest of the modes imply leaving delays as is. */
return 0;
@@ -263,11 +262,12 @@ static int rtl8211e_config_init(struct phy_device *phydev)
/* According to a sample driver there is a 0x1c config register on the
* 0xa4 extension page (0x7) layout. It can be used to disable/enable
-* the RX/TX delays otherwise controlled by RXDLY/TXDLY pins. It can
-* also be used to customize the whole configuration register:
-* 8:6 = PHY Address, 5:4 = Auto-Negotiation, 3 = Interface Mode Select,
-* 2 = RX Delay, 1 = TX Delay, 0 = SELRGV (see original PHY datasheet
-* for details).
+* the RX/TX delays otherwise controlled by RXDLY/TXDLY pins.
+* The configuration register definition:
+* 14 = reserved
+* 13 = Force Tx RX Delay controlled by bit12 bit11,
+* 12 = RX Delay, 11 = TX Delay
+* 10:0 = Test && debug settings reserved by realtek
*/
oldpage = phy_select_page(phydev, 0x7);
if (oldpage < 0)
@@ -277,7 +277,8 @@ static int rtl8211e_config_init(struct phy_device *phydev)
if (ret)
goto err_restore_page;
- ret = __phy_modify(phydev, 0x1c, RTL8211E_TX_DELAY | RTL8211E_RX_DELAY,
+ ret = __phy_modify(phydev, 0x1c, RTL8211E_CTRL_DELAY
+ | RTL8211E_TX_DELAY | RTL8211E_RX_DELAY,
val);
err_restore_page:
--
1.9.1
Re [PATCH] Bluetooth: Fix the vulnerable issue on enc key size
Hi Marcel,
> On September 27, 2020 20:05, Marcel Holtmann wrote:
>
> Hi Alex,
>
> > When someone attacks the service provider, it creates connection,
> > authenticates. Then it requests key size of one byte and it identifies
> > the key with brute force methods.
> >
> > After l2cap info req/resp exchange is complete. the attacker sends
> l2cap
> > connect with specific PSM.
> >
> > In above procedure, there is no chance for the service provider to
> check
> > the encryption key size before l2cap_connect(). Because the state of
> > l2cap chan in conn->chan_l is BT_LISTEN, there is no l2cap chan with
> the
> > state of BT_CONNECT or BT_CONNECT2.
> >
> > So service provider should check the encryption key size in
> > l2cap_connect()
> >
> > Signed-off-by: Alex Lu
> > ---
> > net/bluetooth/l2cap_core.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> > index ade83e224567..63df961d402d 100644
> > --- a/net/bluetooth/l2cap_core.c
> > +++ b/net/bluetooth/l2cap_core.c
> > @@ -4150,6 +4150,13 @@ static struct l2cap_chan
> *l2cap_connect(struct
> l2cap_conn *conn,
> >
> > if (conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE) {
> > if (l2cap_chan_check_security(chan, false)) {
> > + if (!l2cap_check_enc_key_size(conn->hcon))
> {
> > + l2cap_state_change(chan,
> BT_DISCONN);
> > + __set_chan_timer(chan,
> L2CAP_DISC_TIMEOUT);
> > + result = L2CAP_CR_SEC_BLOCK;
> > + status = L2CAP_CS_NO_INFO;
> > + goto response;
> > + }
> > if (test_bit(FLAG_DEFER_SETUP, >flags)) {
> > l2cap_state_change(chan, BT_CONNECT2);
> > result = L2CAP_CR_PEND;
>
> I am not following what you are trying to fix here. Can you show this
> with
> >> a
> btmon trace from an attacking device?
>
> Regards
>
> Marcel
>
>
> >>>
> >>> I'm sorry, I didn't have btmon trace from an attacking device.
> >>> I didn't have the real attacking device. I just simulate the attacking.
> >>> I have a device that can create one byte size encryption key.
> >>> It uses the link key that was produced by pairing with the service
> provider.
> >> Actually the KNOB (Key Negotiation of Bluetooth Attack) says, the link key
> is
> >> unnecessary for the reconnection.
> >>> I use this device to reconnect to service provider, and then initiate the
> Key
> >> Negotiation for one byte size encryption key. Actually the attacker
> identified
> >> the encryption key with some brute force methods.
> >>>
> >>> I want to provide the trace on service provider side.
> >>
> >> what kernel version are you running? I wonder if we should always return
> >> L2CAP_CR_PEND here. Do you have a reproducer code?
> >
> > I'm running kernel 5.8.0-rc6 on acceptor and kernel 5.8.5 on the initiator
> which acts as an attacker.
> > For the attack simulation, some code needs to be changed on each size.
> > On the acceptor, the master parameter for bt_io_listen() in bluetoothd
> should be changed to FALSE in profiles/audio/a2dp.c a2dp_server_listen()
> and profiles/audio/avctp.c avctp_server_socket().
> > The change makes the kernel not to change the role to master when it
> receives hci conn req event.
> > I did the change in order to make the controller to send
> LMP_ENCRYPTION_KEY_SIZE_REQ PDU for one byte key size.
> >
> > On the initiator, the below encryption key size check should be removed.
> > @@ -1622,10 +1624,13 @@ static void l2cap_conn_start(struct l2cap_conn
> *conn)
> >continue;
> >}
> >
> > - if (l2cap_check_enc_key_size(conn->hcon))
> > - l2cap_start_connection(chan);
> > - else
> > - l2cap_chan_close(chan, ECONNREFUSED);
> > + /* Just simulate KNOB */
> > + l2cap_start_connection(chan);
> > + /* if (l2cap_check_enc_key_size(conn->hcon))
> > +* l2cap_start_connection(chan);
> > +* else
> > +* l2cap_chan_close(chan, ECONNREFUSED);
> > +*/
> >
> > At last, I did the test as below:
> > 1. On the initiator, pair acceptor
> > 2. Run l2test -r -P 3 on the acceptor
> > 3. Run l2test -n -P 3 on the initiator
> >
> >>
> >> The problem really is that the MASK_REQ_DONE indication is not enough
> to
> >> make a decision for the key size. We have to ensure that also the key size
> is
> >>
Re: [PATCH] Register read and writes tracing
Hi Prasad, On 2020-09-28 06:04, Prasad Sodagudi wrote: Qualcomm team have tried to upstreaming the register trace buffer(RTB) use case earlier - [1] with pstore approach. In that discussion, there was suggestion to use the ftrace events for tracking the register reads and writes. In this patch, added register read/write operations tracing support and also add _no_log variants(for example - readl_relaxed_no_log to readl_relaxed) functions, which will help to avoid excessive logging for certain register operations (continuous writes from a loop). These tracepoints can be used by modules to register probes and log the data convenient for silicon vendor format. [1] - https://lore.kernel.org/lkml/cover.1535119710.git.saiprakash.ran...@codeaurora.org/ Thanks for picking this up again. This kind of looks like going back to downstream implementation of having log and nolog variants which was exactly the thing we wanted to avoid. I believe the reason for this nolog variants is not just to avoid excessive logging but also to provide filtering i.e, selectively trace the register reads/writes from required drivers or subsystems like for example we wouldn't want to trace register reads/writes from serial drivers, now if you use these nolog variants then it will need to be sprinkled all over the kernel in various drivers to provide this kind of filtering. That was the reason I did not want to introduce these nolog and log variants, instead introduced a way to use dynamic debug [2] to provide this kind of filtering. Dynamic debug provides an array of filtering capacity such as filter by files, folders and even is applicable for modules making it a prime candidate for these kind of scenarios. So why not use it instead of all these new variants? Then you don't have to export things like you do in this patch and just have to add tracepoints. Also the patch series[1][2] was almost OK'ed(they didn't give a formal review) by arm folks at the time and even acked by Steve[3] except for the pstore part. We have ways to extract trace events from ramdumps via crash utility or STM, so pstore support is not mandatory and can be done later(it is currently being worked on). Plus the link you mentioned was an RFC and there was a new version posted after that[4]. Please take at the series[4] look once and see if you can use that, only thing required I suppose is decouple the pstore patches and you should be good to go. [1] https://patchwork.kernel.org/patch/10593175/ [2] https://patchwork.kernel.org/patch/10593175/ [3] https://patchwork.kernel.org/patch/10593173/ [4] https://patchwork.kernel.org/cover/10593159/ Qualcomm teams uses these logs for debugging various issues in the product life cycle and hopping that this logging would help other silicon vendors as this is generic approach. Please provide your suggestion/comments to bring this patch upstream quality. Prasad Sodagudi (1): tracing: Add register read and write tracing support arch/arm64/include/asm/io.h| 117 ++--- include/linux/iorw.h | 20 +++ include/trace/events/rwio.h| 51 ++ kernel/trace/Kconfig | 11 kernel/trace/Makefile | 1 + kernel/trace/trace_readwrite.c | 30 +++ 6 files changed, 222 insertions(+), 8 deletions(-) create mode 100644 include/linux/iorw.h create mode 100644 include/trace/events/rwio.h create mode 100644 kernel/trace/trace_readwrite.c Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] ptp: add stub function for ptp_get_msgtype()
On Sun Sep 27 2020, Yangbo Lu wrote:
> Added the missing stub function for ptp_get_msgtype().
>
> Reported-by: Randy Dunlap
> Fixes: 036c508ba95e ("ptp: Add generic ptp message type function")
> Signed-off-by: Yangbo Lu
Oh, my bad. Thanks for fixing it.
Thanks,
Kurt
signature.asc
Description: PGP signature
Re: [linux-sunxi] [PATCH v5 09/20] arm64: dts: allwinner: h6: Add DAI node and soundcard for HDMI
On Mon, Sep 28, 2020 at 1:32 PM Chen-Yu Tsai wrote:
>
> On Mon, Sep 28, 2020 at 3:29 AM Clément Péron wrote:
> >
> > From: Jernej Skrabec
> >
> > Add the I2S node used by the HDMI and a simple-soundcard to
> > link audio between HDMI and I2S.
> >
> > Note that the HDMI codec requires an inverted frame clock and
> > a fixed I2S width. As there is no such option for I2S we use
> > TDM property of the simple-soundcard to do that.
> >
> > Signed-off-by: Jernej Skrabec
> > Signed-off-by: Marcus Cooper
> > Signed-off-by: Clément Péron
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 33
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > index 28c77d6872f6..a8853ee7885a 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > @@ -67,6 +67,25 @@ de: display-engine {
> > status = "disabled";
> > };
> >
> > + hdmi_sound: hdmi-sound {
> > + compatible = "simple-audio-card";
> > + simple-audio-card,format = "i2s";
> > + simple-audio-card,name = "sun50i-h6-hdmi";
> > + simple-audio-card,mclk-fs = <128>;
> > + simple-audio-card,frame-inversion;
> > + status = "disabled";
> > +
> > + simple-audio-card,codec {
> > + sound-dai = <>;
> > + };
> > +
> > + simple-audio-card,cpu {
> > + sound-dai = <>;
> > + dai-tdm-slot-num = <2>;
>
> Doesn't this end up limiting the number of audio channels HDMI can carry?
> AFAICT the TDM properties are all optional, so just leave it out.
>
> Same goes for the other two patches.
>
> > + dai-tdm-slot-width = <32>;
> > + };
> > + };
> > +
> > osc24M: osc24M_clk {
> > #clock-cells = <0>;
> > compatible = "fixed-clock";
> > @@ -609,6 +628,19 @@ mdio: mdio {
> > };
> > };
> >
> > + i2s1: i2s@5091000 {
> > + #sound-dai-cells = <0>;
> > + compatible = "allwinner,sun50i-h6-i2s";
> > + reg = <0x05091000 0x1000>;
> > + interrupts = ;
> > + clocks = < CLK_BUS_I2S1>, < CLK_I2S1>;
> > + clock-names = "apb", "mod";
> > + dmas = < 4>, < 4>;
> > + resets = < RST_BUS_I2S1>;
> > + dma-names = "rx", "tx";
Sorry, missed this one.
Given that usage for this interface is transmit only, and there is no
RX DRQ number assigned to it, you should drop the RX DMA number and name.
> > + status = "disabled";
> > + };
> > +
> > spdif: spdif@5093000 {
> > #sound-dai-cells = <0>;
> > compatible = "allwinner,sun50i-h6-spdif";
> > @@ -739,6 +771,7 @@ ohci3: usb@5311400 {
> > };
> >
> > hdmi: hdmi@600 {
> > + #sound-dai-cells = <0>;
> > compatible = "allwinner,sun50i-h6-dw-hdmi";
> > reg = <0x0600 0x1>;
> > reg-io-width = <1>;
>
> The rest of the patch looks OK.
Re: [linux-sunxi] [PATCH v5 10/20] arm64: dts: allwinner: h6: Enable HDMI sound for Beelink GS1
On Mon, Sep 28, 2020 at 3:29 AM Clément Péron wrote: > > Now that HDMI sound node is available in the SoC dtsi. > Enable it for this board. > > Signed-off-by: Clément Péron Acked-by: Chen-Yu Tsai
Re: [linux-sunxi] [PATCH v5 09/20] arm64: dts: allwinner: h6: Add DAI node and soundcard for HDMI
On Mon, Sep 28, 2020 at 3:29 AM Clément Péron wrote:
>
> From: Jernej Skrabec
>
> Add the I2S node used by the HDMI and a simple-soundcard to
> link audio between HDMI and I2S.
>
> Note that the HDMI codec requires an inverted frame clock and
> a fixed I2S width. As there is no such option for I2S we use
> TDM property of the simple-soundcard to do that.
>
> Signed-off-by: Jernej Skrabec
> Signed-off-by: Marcus Cooper
> Signed-off-by: Clément Péron
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 33
> 1 file changed, 33 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index 28c77d6872f6..a8853ee7885a 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -67,6 +67,25 @@ de: display-engine {
> status = "disabled";
> };
>
> + hdmi_sound: hdmi-sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,name = "sun50i-h6-hdmi";
> + simple-audio-card,mclk-fs = <128>;
> + simple-audio-card,frame-inversion;
> + status = "disabled";
> +
> + simple-audio-card,codec {
> + sound-dai = <>;
> + };
> +
> + simple-audio-card,cpu {
> + sound-dai = <>;
> + dai-tdm-slot-num = <2>;
Doesn't this end up limiting the number of audio channels HDMI can carry?
AFAICT the TDM properties are all optional, so just leave it out.
Same goes for the other two patches.
> + dai-tdm-slot-width = <32>;
> + };
> + };
> +
> osc24M: osc24M_clk {
> #clock-cells = <0>;
> compatible = "fixed-clock";
> @@ -609,6 +628,19 @@ mdio: mdio {
> };
> };
>
> + i2s1: i2s@5091000 {
> + #sound-dai-cells = <0>;
> + compatible = "allwinner,sun50i-h6-i2s";
> + reg = <0x05091000 0x1000>;
> + interrupts = ;
> + clocks = < CLK_BUS_I2S1>, < CLK_I2S1>;
> + clock-names = "apb", "mod";
> + dmas = < 4>, < 4>;
> + resets = < RST_BUS_I2S1>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };
> +
> spdif: spdif@5093000 {
> #sound-dai-cells = <0>;
> compatible = "allwinner,sun50i-h6-spdif";
> @@ -739,6 +771,7 @@ ohci3: usb@5311400 {
> };
>
> hdmi: hdmi@600 {
> + #sound-dai-cells = <0>;
> compatible = "allwinner,sun50i-h6-dw-hdmi";
> reg = <0x0600 0x1>;
> reg-io-width = <1>;
The rest of the patch looks OK.
URGENT PLEASE.
Dear friend, This transmission is to inform you that we have chosen you from our Website as a new Branch manager in your country, for more about the Position email US via this Email: info_custom...@consultant.com, once we receive your respond we shall proceed. The position cannot stop you doing anything you want to do. Thank's.
[PATCH 6/7] arm64: dts: Add ipq5018 SoC and MP03 board support
Add initial device tree support for the Qualcomm IPQ5018 SoC and
MP03.1-C2 board.
Signed-off-by: Varadarajan Narayanan
---
Documentation/devicetree/bindings/arm/qcom.yaml | 7 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/ipq5018-mp03.1-c2.dts | 30
arch/arm64/boot/dts/qcom/ipq5018.dtsi | 201
4 files changed, 239 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/ipq5018-mp03.1-c2.dts
create mode 100644 arch/arm64/boot/dts/qcom/ipq5018.dtsi
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
b/Documentation/devicetree/bindings/arm/qcom.yaml
index 6031aee..694063f 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -28,6 +28,7 @@ description: |
apq8074
apq8084
apq8096
+ipq5018
ipq6018
ipq8074
mdm9615
@@ -49,6 +50,7 @@ description: |
hk01
idp
liquid
+mp03
mtp
qrd
sbc
@@ -142,6 +144,11 @@ properties:
- items:
- enum:
+ - qcom,ipq5018-mp03
+ - const: qcom,ipq5018
+
+ - items:
+ - enum:
- qcom,ipq8064-ap148
- const: qcom,ipq8064
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index d8f1466..3873970 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8096-ifc6640.dtb
dtb-$(CONFIG_ARCH_QCOM)+= ipq6018-cp01-c1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= ipq8074-hk01.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= ipq5018-mp03.1-c2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8916-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8916-longcheer-l8150.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8916-samsung-a3u-eur.dtb
diff --git a/arch/arm64/boot/dts/qcom/ipq5018-mp03.1-c2.dts
b/arch/arm64/boot/dts/qcom/ipq5018-mp03.1-c2.dts
new file mode 100644
index ..41bb3b3
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/ipq5018-mp03.1-c2.dts
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * IPQ5018 CP01 board device tree source
+ *
+ * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "ipq5018.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. IPQ5018/AP-MP03-C2";
+ compatible = "qcom,ipq5018-mp03", "qcom,ipq5018";
+
+ aliases {
+ serial0 = _uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs-append = " swiotlb=1";
+ };
+};
+
+_uart1 {
+ pinctrl-0 = <_1_pins>;
+ pinctrl-names = "default";
+ status = "ok";
+};
diff --git a/arch/arm64/boot/dts/qcom/ipq5018.dtsi
b/arch/arm64/boot/dts/qcom/ipq5018.dtsi
new file mode 100644
index ..12492a4
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/ipq5018.dtsi
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * IPQ5018 SoC device tree source
+ *
+ * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <>;
+
+ clocks {
+ sleep_clk: sleep-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <32000>;
+ #clock-cells = <0>;
+ };
+
+ xo: xo {
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ #clock-cells = <0>;
+ };
+ };
+
+ cpus: cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0>;
+ enable-method = "psci";
+ next-level-cache = <_0>;
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ enable-method = "psci";
+ reg = <0x1>;
+ next-level-cache = <_0>;
+ };
+
+ L2_0: l2-cache {
+ compatible = "cache";
+ cache-level = <0x2>;
+ };
+ };
+
+ pmuv8: pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = ;
+ };
+
+ psci: psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ tz:
[PATCH 2/7] dt-bindings: arm64: ipq5018: Add binding descriptions for clock and reset
This patch adds support for the global clock controller found on the IPQ5018 based devices. Signed-off-by: Varadarajan Narayanan --- .../devicetree/bindings/clock/qcom,gcc.yaml| 3 + include/dt-bindings/clock/qcom,gcc-ipq5018.h | 183 + include/dt-bindings/reset/qcom,gcc-ipq5018.h | 119 ++ 3 files changed, 305 insertions(+) create mode 100644 include/dt-bindings/clock/qcom,gcc-ipq5018.h create mode 100644 include/dt-bindings/reset/qcom,gcc-ipq5018.h diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index ee0467f..74d67fc 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -18,6 +18,8 @@ description: | - dt-bindings/clock/qcom,gcc-apq8084.h - dt-bindings/reset/qcom,gcc-apq8084.h - dt-bindings/clock/qcom,gcc-ipq4019.h + - dt-bindings/clock/qcom,gcc-ipq5018.h + - dt-bindings/reset/qcom,gcc-ipq5018.h - dt-bindings/clock/qcom,gcc-ipq6018.h - dt-bindings/reset/qcom,gcc-ipq6018.h - dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) @@ -39,6 +41,7 @@ properties: enum: - qcom,gcc-apq8084 - qcom,gcc-ipq4019 + - qcom,gcc-ipq5018 - qcom,gcc-ipq6018 - qcom,gcc-ipq8064 - qcom,gcc-msm8660 diff --git a/include/dt-bindings/clock/qcom,gcc-ipq5018.h b/include/dt-bindings/clock/qcom,gcc-ipq5018.h new file mode 100644 index ..069165f --- /dev/null +++ b/include/dt-bindings/clock/qcom,gcc-ipq5018.h @@ -0,0 +1,183 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ + +#ifndef _DT_BINDINGS_CLOCK_IPQ_GCC_5018_H +#define _DT_BINDINGS_CLOCK_IPQ_GCC_5018_H + +#define GPLL0_MAIN 0 +#define GPLL0 1 +#define GPLL2_MAIN 2 +#define GPLL2 3 +#define GPLL4_MAIN 4 +#define GPLL4 5 +#define UBI32_PLL_MAIN 6 +#define UBI32_PLL 7 +#define APSS_AHB_CLK_SRC 9 +#define APSS_AHB_POSTDIV_CLK_SRC 10 +#define APSS_AXI_CLK_SRC 11 +#define BLSP1_QUP1_I2C_APPS_CLK_SRC12 +#define BLSP1_QUP1_SPI_APPS_CLK_SRC13 +#define BLSP1_QUP2_I2C_APPS_CLK_SRC14 +#define BLSP1_QUP2_SPI_APPS_CLK_SRC15 +#define BLSP1_QUP3_I2C_APPS_CLK_SRC16 +#define BLSP1_QUP3_SPI_APPS_CLK_SRC17 +#define BLSP1_UART1_APPS_CLK_SRC 18 +#define BLSP1_UART2_APPS_CLK_SRC 19 +#define CRYPTO_CLK_SRC 20 +#define GCC_APSS_AHB_CLK 23 +#define GCC_APSS_AXI_CLK 24 +#define GCC_BLSP1_AHB_CLK 25 +#define GCC_BLSP1_QUP1_I2C_APPS_CLK26 +#define GCC_BLSP1_QUP1_SPI_APPS_CLK27 +#define GCC_BLSP1_QUP2_I2C_APPS_CLK28 +#define GCC_BLSP1_QUP2_SPI_APPS_CLK29 +#define GCC_BLSP1_QUP3_I2C_APPS_CLK30 +#define GCC_BLSP1_QUP3_SPI_APPS_CLK31 +#define GCC_BLSP1_UART1_APPS_CLK 33 +#define GCC_BLSP1_UART2_APPS_CLK 34 +#define GCC_BTSS_LPO_CLK 36 +#define GCC_CMN_BLK_AHB_CLK40 +#define GCC_CMN_BLK_SYS_CLK41 +#define GCC_CRYPTO_AHB_CLK 44 +#define GCC_CRYPTO_AXI_CLK 45 +#define GCC_CRYPTO_CLK 46 +#define GCC_CRYPTO_PPE_CLK 47 +#define GCC_DCC_CLK48 +#define GCC_GEPHY_RX_CLK 53 +#define GCC_GEPHY_TX_CLK 54 +#define GCC_GMAC0_CFG_CLK 55 +#define GCC_GMAC0_PTP_CLK 56 +#define GCC_GMAC0_RX_CLK 57 +#define GCC_GMAC0_SYS_CLK 58 +#define GCC_GMAC0_TX_CLK 59 +#define GCC_GMAC1_CFG_CLK 60 +#define GCC_GMAC1_PTP_CLK 61 +#define GCC_GMAC1_RX_CLK 62 +#define GCC_GMAC1_SYS_CLK 63 +#define GCC_GMAC1_TX_CLK 64 +#define GCC_GP1_CLK65 +#define GCC_GP2_CLK66 +#define GCC_GP3_CLK67 +#define GCC_LPASS_CORE_AXIM_CLK69 +#define
Re: [PATCH v4 06/17] virt: acrn: Introduce VM management interfaces
On Mon, Sep 28, 2020 at 11:50:30AM +0800, Shuo A Liu wrote: > > > + write_lock_bh(_vm_list_lock); > > > + list_add(>list, _vm_list); > > > + write_unlock_bh(_vm_list_lock); > > > > Why are the _bh() variants being used here? > > > > You are only accessing this list from userspace context in this patch. > > > > Heck, you aren't even reading from the list, only writing to it... > > acrn_vm_list is read in a tasklet which dispatch I/O requests and is wrote > in VM creation ioctl. Use the rwlock mechanism to protect it. > The reading operation is introduced in the following patches of this > series. So i keep the lock type at the moment of introduction. Ok, but think about someone trying to review this code. Does this lock actually make sense here? No, it does not. How am I supposed to know to look at future patches to determine that it changes location and usage to require this? That's just not fair, would you want to review something like this? And a HUGE meta-comment, again, why am I the only one reviewing this stuff? Why do you have a ton of Intel people on the Cc: yet it is, once again, my job to do this? If you all are wanting to burn me out, you are doing a good job... greg k-h
Re: general protection fault in map_vdso_randomized
On Fri, Aug 21, 2020 at 8:10 AM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:4b6c093e Merge tag 'block-5.9-2020-08-14' of git://git.ker.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=179f99f690 > kernel config: https://syzkaller.appspot.com/x/.config?x=a98b778f5fca0653 > dashboard link: https://syzkaller.appspot.com/bug?extid=6719f65e8a293105edcc > compiler: gcc (GCC) 10.1.0-syz 20200507 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+6719f65e8a293105e...@syzkaller.appspotmail.com #syz dup: general protection fault in perf_misc_flags > general protection fault, probably for non-canonical address > 0xdc00: [#1] PREEMPT SMP KASAN > KASAN: null-ptr-deref in range [0x-0x0007] > CPU: 0 PID: 27621 Comm: modprobe Not tainted 5.8.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:map_vdso_randomized+0x64/0x160 arch/x86/entry/vdso/vma.c:364 > Code: 00 fc ff df 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 eb 00 00 00 65 48 8b > 1c 25 c0 fe 01 00 48 8d bb 28 04 00 00 41 2b 54 24 20 <00> 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > RSP: 0018:c9000ab57c10 EFLAGS: 00010207 > RAX: dc00 RBX: 88804e0963c0 RCX: 11080a60 > RDX: 6000 RSI: 0001 RDI: 88804e0967e8 > RBP: 88801459b000 R08: 0001 R09: 0001 > R10: R11: 0160 R12: 884052e0 > R13: 8880a69cf950 R14: 7faba47c2c20 R15: 8880a5cb4400 > FS: () GS:8880ae60() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7faba49e6fc0 CR3: 31b89000 CR4: 001506f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > load_elf_binary+0x22d4/0x47c0 fs/binfmt_elf.c:1221 > search_binary_handler fs/exec.c:1819 [inline] > exec_binprm fs/exec.c:1860 [inline] > bprm_execve+0x936/0x1b10 fs/exec.c:1931 > kernel_execve+0x370/0x460 fs/exec.c:2080 > call_usermodehelper_exec_async+0x27a/0x500 kernel/umh.c:101 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 > Modules linked in: > ---[ end trace f344c46c1e164ddf ]--- > RIP: 0010:map_vdso_randomized+0x64/0x160 arch/x86/entry/vdso/vma.c:364 > Code: 00 fc ff df 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 eb 00 00 00 65 48 8b > 1c 25 c0 fe 01 00 48 8d bb 28 04 00 00 41 2b 54 24 20 <00> 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > RSP: 0018:c9000ab57c10 EFLAGS: 00010207 > RAX: dc00 RBX: 88804e0963c0 RCX: 11080a60 > RDX: 6000 RSI: 0001 RDI: 88804e0967e8 > RBP: 88801459b000 R08: 0001 R09: 0001 > R10: R11: 0160 R12: 884052e0 > R13: 8880a69cf950 R14: 7faba47c2c20 R15: 8880a5cb4400 > FS: () GS:8880ae70() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7ffc99314e38 CR3: 31b89000 CR4: 001506e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/8a0f4f05ad5d1743%40google.com.
Re: [PATCH v4 17/17] virt: acrn: Introduce an interface for Service VM to control vCPU
On Mon, Sep 28, 2020 at 12:10:07PM +0800, Shuo A Liu wrote: > > You just raced with userspace and lost. If you want to add attribute > > files to a device, use the default attribute group list, and it will be > > managed properly for you by the driver core. > > > > Huge hint, if a driver every has to touch a kobject, or call sysfs_*, > > then it is probably doing something wrong. > > Do you mean use .groups of struct miscdevice directly ? > > If yes, let me follow drivers/char/hw_random/s390-trng.c to do this. > BTW, few driver use the .groups directly. :) Drivers should almost never be messing with individual sysfs files. And this ability to use .groups is a "new" one, conversions of existing code that do not use them is always welcome. thanks, greg k-h
[PATCH v2 1/2] Input: synaptics-rmi4 - rename f30_data to gpio_data
f30_data in rmi_device_platform_data could be also referenced by RMI
function 3A, so rename it and the structure name to avoid confusion.
Signed-off-by: Vincent Huang
Reviewed-by: Hans de Goede
Tested-by: Hans de Goede
---
drivers/hid/hid-rmi.c | 2 +-
drivers/input/mouse/synaptics.c | 2 +-
drivers/input/rmi4/rmi_f30.c| 14 +++---
include/linux/rmi.h | 11 ++-
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 9ce22acdfaca..62315e31d520 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -722,7 +722,7 @@ static int rmi_probe(struct hid_device *hdev, const struct
hid_device_id *id)
}
if (data->device_flags & RMI_DEVICE_HAS_PHYS_BUTTONS)
- rmi_hid_pdata.f30_data.disable = true;
+ rmi_hid_pdata.gpio_data.disable = true;
data->xport.dev = hdev->dev.parent;
data->xport.pdata = rmi_hid_pdata;
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 4b81b2d0fe06..8a54efd6eb95 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1752,7 +1752,7 @@ static int synaptics_create_intertouch(struct psmouse
*psmouse,
.kernel_tracking = false,
.topbuttonpad = topbuttonpad,
},
- .f30_data = {
+ .gpio_data = {
.buttonpad = SYN_CAP_CLICKPAD(info->ext_cap_0c),
.trackstick_buttons =
!!SYN_CAP_EXT_BUTTONS_STICK(info->ext_cap_10),
diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
index a90dad1d9ac7..35045f161dc2 100644
--- a/drivers/input/rmi4/rmi_f30.c
+++ b/drivers/input/rmi4/rmi_f30.c
@@ -168,17 +168,17 @@ static int rmi_f30_config(struct rmi_function *fn)
rmi_get_platform_data(fn->rmi_dev);
int error;
- /* can happen if f30_data.disable is set */
+ /* can happen if gpio_data.disable is set */
if (!f30)
return 0;
- if (pdata->f30_data.trackstick_buttons) {
+ if (pdata->gpio_data.trackstick_buttons) {
/* Try [re-]establish link to F03. */
f30->f03 = rmi_find_function(fn->rmi_dev, 0x03);
f30->trackstick_buttons = f30->f03 != NULL;
}
- if (pdata->f30_data.disable) {
+ if (pdata->gpio_data.disable) {
drv->clear_irq_bits(fn->rmi_dev, fn->irq_mask);
} else {
/* Write Control Register values back to device */
@@ -245,10 +245,10 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
if (!rmi_f30_is_valid_button(i, f30->ctrl))
continue;
- if (pdata->f30_data.trackstick_buttons &&
+ if (pdata->gpio_data.trackstick_buttons &&
i >= TRACKSTICK_RANGE_START && i < TRACKSTICK_RANGE_END) {
f30->gpioled_key_map[i] = trackstick_button++;
- } else if (!pdata->f30_data.buttonpad || !button_mapped) {
+ } else if (!pdata->gpio_data.buttonpad || !button_mapped) {
f30->gpioled_key_map[i] = button;
input_set_capability(input, EV_KEY, button++);
button_mapped = true;
@@ -264,7 +264,7 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
* but I am not sure, so use only the pdata info and the number of
* mapped buttons.
*/
- if (pdata->f30_data.buttonpad || (button - BTN_LEFT == 1))
+ if (pdata->gpio_data.buttonpad || (button - BTN_LEFT == 1))
__set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
return 0;
@@ -372,7 +372,7 @@ static int rmi_f30_probe(struct rmi_function *fn)
struct f30_data *f30;
int error;
- if (pdata->f30_data.disable)
+ if (pdata->gpio_data.disable)
return 0;
if (!drv_data->input) {
diff --git a/include/linux/rmi.h b/include/linux/rmi.h
index 7b22366d0065..00dda5381bf8 100644
--- a/include/linux/rmi.h
+++ b/include/linux/rmi.h
@@ -102,15 +102,16 @@ struct rmi_2d_sensor_platform_data {
};
/**
- * struct rmi_f30_data - overrides defaults for a single F30 GPIOs/LED chip.
+ * struct rmi_gpio_data - overrides defaults for a single F30/F3A GPIOs/LED
+ * chip.
* @buttonpad - the touchpad is a buttonpad, so enable only the first actual
* button that is found.
- * @trackstick_buttons - Set when the function 30 is handling the physical
+ * @trackstick_buttons - Set when the function 30 or 3a is handling the
physical
* buttons of the trackstick (as a PS/2 passthrough device).
- * @disable - the touchpad incorrectly reports F30 and it should be ignored.
+ * @disable - the touchpad incorrectly reports F30/F3A and it should be
ignored.
* This is a special case
[PATCH v2 2/2] Input: synaptics-rmi4 - add support for F3A
RMI4 F3A supports the touchpad GPIO function, it's designed to
support more GPIOs and used on newer touchpads. This patch adds
support of the touchpad buttons.
Signed-off-by: Vincent Huang
Reviewed-by: Hans de Goede
Tested-by: Hans de Goede
---
drivers/input/rmi4/Kconfig | 8 ++
drivers/input/rmi4/Makefile | 1 +
drivers/input/rmi4/rmi_bus.c| 3 +
drivers/input/rmi4/rmi_driver.h | 1 +
drivers/input/rmi4/rmi_f3a.c| 241
5 files changed, 254 insertions(+)
create mode 100644 drivers/input/rmi4/rmi_f3a.c
diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index a212ff706f74..16119f760d11 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -100,6 +100,14 @@ config RMI4_F34
device via the firmware loader interface. This is triggered using a
sysfs attribute.
+config RMI4_F3A
+ bool "RMI4 Function 3A (GPIO)"
+ help
+ Say Y here if you want to add support for RMI4 function 3A.
+
+ Function 3A provides GPIO support for RMI4 devices. This includes
+ support for buttons on TouchPads and ClickPads.
+
config RMI4_F54
bool "RMI4 Function 54 (Analog diagnostics)"
depends on VIDEO_V4L2=y || (RMI4_CORE=m && VIDEO_V4L2=m)
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index f17631656987..02f14c846861 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -10,6 +10,7 @@ rmi_core-$(CONFIG_RMI4_F11) += rmi_f11.o
rmi_core-$(CONFIG_RMI4_F12) += rmi_f12.o
rmi_core-$(CONFIG_RMI4_F30) += rmi_f30.o
rmi_core-$(CONFIG_RMI4_F34) += rmi_f34.o rmi_f34v7.o
+rmi_core-$(CONFIG_RMI4_F3A) += rmi_f3a.o
rmi_core-$(CONFIG_RMI4_F54) += rmi_f54.o
rmi_core-$(CONFIG_RMI4_F55) += rmi_f55.o
diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index af706a583656..47d1b97ed6cf 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -365,6 +365,9 @@ static struct rmi_function_handler *fn_handlers[] = {
#ifdef CONFIG_RMI4_F34
_f34_handler,
#endif
+#ifdef CONFIG_RMI4_F3A
+ _f3a_handler,
+#endif
#ifdef CONFIG_RMI4_F54
_f54_handler,
#endif
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index 65bfaa95e193..1c6c6086c0e5 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -135,6 +135,7 @@ extern struct rmi_function_handler rmi_f11_handler;
extern struct rmi_function_handler rmi_f12_handler;
extern struct rmi_function_handler rmi_f30_handler;
extern struct rmi_function_handler rmi_f34_handler;
+extern struct rmi_function_handler rmi_f3a_handler;
extern struct rmi_function_handler rmi_f54_handler;
extern struct rmi_function_handler rmi_f55_handler;
#endif
diff --git a/drivers/input/rmi4/rmi_f3a.c b/drivers/input/rmi4/rmi_f3a.c
new file mode 100644
index ..be3c1ecc1181
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f3a.c
@@ -0,0 +1,241 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2012-2020 Synaptics Incorporated
+ */
+
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+
+#define RMI_F3A_MAX_GPIO_COUNT 128
+#define RMI_F3A_MAX_REG_SIZE DIV_ROUND_UP(RMI_F3A_MAX_GPIO_COUNT, 8)
+
+/* Defs for Query 0 */
+#define RMI_F3A_GPIO_COUNT 0x7F
+
+#define RMI_F3A_DATA_REGS_MAX_SIZE RMI_F3A_MAX_REG_SIZE
+
+#define TRACKSTICK_RANGE_START 3
+#define TRACKSTICK_RANGE_END 6
+
+struct f3a_data {
+ /* Query Data */
+ u8 gpio_count;
+
+ u8 register_count;
+
+ u8 data_regs[RMI_F3A_DATA_REGS_MAX_SIZE];
+ u16 *gpio_key_map;
+
+ struct input_dev *input;
+
+ struct rmi_function *f03;
+ bool trackstick_buttons;
+};
+
+static void rmi_f3a_report_button(struct rmi_function *fn,
+ struct f3a_data *f3a, unsigned int button)
+{
+ u16 key_code = f3a->gpio_key_map[button];
+ bool key_down = !(f3a->data_regs[0] & BIT(button));
+
+ if (f3a->trackstick_buttons &&
+ button >= TRACKSTICK_RANGE_START &&
+ button <= TRACKSTICK_RANGE_END) {
+ rmi_f03_overwrite_button(f3a->f03, key_code, key_down);
+ } else {
+ rmi_dbg(RMI_DEBUG_FN, >dev,
+ "%s: call input report key (0x%04x) value (0x%02x)",
+ __func__, key_code, key_down);
+ input_report_key(f3a->input, key_code, key_down);
+ }
+}
+
+static irqreturn_t rmi_f3a_attention(int irq, void *ctx)
+{
+ struct rmi_function *fn = ctx;
+ struct f3a_data *f3a = dev_get_drvdata(>dev);
+ struct rmi_driver_data *drvdata = dev_get_drvdata(>rmi_dev->dev);
+ int error;
+ int i;
+
+ if (drvdata->attn_data.data) {
+ if (drvdata->attn_data.size < f3a->register_count) {
+ dev_warn(>dev,
+"F3A
[PATCH v2 0/2] Add support for F3A
RMI4 F3A supports the touchpad GPIO function, it's designed to support more GPIOs and used on newer touchpads. The patches add support of touchpad buttons and rename f30_data to avoid confusion. Changes in v2: - Combined patch 1 and 2 of v1 to fix bisectability. Vincent Huang (2): Input: synaptics-rmi4 - rename f30_data to gpio_data Input: synaptics-rmi4 - add support for F3A drivers/hid/hid-rmi.c | 2 +- drivers/input/mouse/synaptics.c | 2 +- drivers/input/rmi4/Kconfig | 8 ++ drivers/input/rmi4/Makefile | 1 + drivers/input/rmi4/rmi_bus.c| 3 + drivers/input/rmi4/rmi_driver.h | 1 + drivers/input/rmi4/rmi_f30.c| 14 +- drivers/input/rmi4/rmi_f3a.c| 241 include/linux/rmi.h | 11 +- 9 files changed, 269 insertions(+), 14 deletions(-) create mode 100644 drivers/input/rmi4/rmi_f3a.c -- 2.25.1
Re: [PATCH] tracing: Add register read and write tracing support
On Sun, Sep 27, 2020 at 05:34:50PM -0700, Prasad Sodagudi wrote: > +config TRACE_RW > + bool "Register read/write tracing" > + select TRACING > + default n n is always the default, no need to list it. And you only did this for one arch, yet you made a generic kernel config option, is that really wise? thanks, greg k-h
[PATCH 7/7] arm64: defconfig: Enable IPQ5018 SoC base configs
Enables clk & pinctrl related configs Signed-off-by: Varadarajan Narayanan --- arch/arm64/configs/defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 6d04b95..ca25f79 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -473,6 +473,7 @@ CONFIG_PINCTRL_IMX8MQ=y CONFIG_PINCTRL_IMX8QXP=y CONFIG_PINCTRL_IMX8DXL=y CONFIG_PINCTRL_IPQ8074=y +CONFIG_PINCTRL_IPQ5018=y CONFIG_PINCTRL_IPQ6018=y CONFIG_PINCTRL_MSM8916=y CONFIG_PINCTRL_MSM8994=y @@ -851,6 +852,8 @@ CONFIG_QCOM_CLK_APCS_MSM8916=y CONFIG_QCOM_CLK_SMD_RPM=y CONFIG_QCOM_CLK_RPMH=y CONFIG_IPQ_GCC_8074=y +CONFIG_IPQ_GCC_5018=y +CONFIG_IPQ_APSS_5018=y CONFIG_IPQ_GCC_6018=y CONFIG_MSM_GCC_8916=y CONFIG_MSM_GCC_8994=y -- 2.7.4
Re: [PATCH] tracing: Add register read and write tracing support
On Sun, Sep 27, 2020 at 05:34:50PM -0700, Prasad Sodagudi wrote:
> Add register read/write operations tracing support.
> ftrace events helps trace register read and write
> location details of memory mapped IO registers. Also
> add _no_log variants the writel_relaxed/readl_relaed
> APIs to avoid excessive logging for certain register
> operations.
>
> Signed-off-by: Prasad Sodagudi
> ---
> arch/arm64/include/asm/io.h| 117
> ++---
> include/linux/iorw.h | 20 +++
> include/trace/events/rwio.h| 51 ++
> kernel/trace/Kconfig | 11
> kernel/trace/Makefile | 1 +
> kernel/trace/trace_readwrite.c | 30 +++
> 6 files changed, 222 insertions(+), 8 deletions(-)
> create mode 100644 include/linux/iorw.h
> create mode 100644 include/trace/events/rwio.h
> create mode 100644 kernel/trace/trace_readwrite.c
>
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index ff50dd7..db5acff 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -9,6 +9,7 @@
> #define __ASM_IO_H
>
> #include
> +#include
> #include
>
> #include
> @@ -24,24 +25,28 @@
> #define __raw_writeb __raw_writeb
> static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
> {
> + log_write_io(addr);
> asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
You are just logging the address, what about the data written or read?
Why throw away half of the information here?
Oh, and sending patches that break the build is generally not a good
thing to do :)
thanks,
greg k-h
Re: general protection fault in perf_misc_flags
On Sun, Sep 27, 2020 at 4:57 PM Borislav Petkov wrote: > > On Sat, Sep 19, 2020 at 01:32:14AM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:92ab97ad Merge tag 'sh-for-5.9-part2' of git://git.libc.or.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=1069669b90 > > kernel config: https://syzkaller.appspot.com/x/.config?x=cd992d74d6c7e62 > > dashboard link: https://syzkaller.appspot.com/bug?extid=ce179bc99e64377c24bc > > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ > > c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > > All below is AFAICT: > > This compiler you're using is not some official release but some random > commit before the v10 release: > > $ git show c2443155a0fb245c8f17f2c1c72b6ea391e86e81 > Author: Hans Wennborg > Date: Sat Nov 30 14:20:11 2019 +0100 > > Revert 651f07908a1 "[AArch64] Don't combine callee-save and local stack > adjustment when optimizing for size" > ... > > $ git describe c2443155a0fb245c8f17f2c1c72b6ea391e86e81 > llvmorg-10-init-10900-gc2443155a0fb > > The v10 release is: > > $ git show llvmorg-10.0.0 > tag llvmorg-10.0.0 > Tagger: Hans Wennborg > Date: Tue Mar 24 12:58:58 2020 +0100 > > Tag 10.0.0 > > and v10 has reached v10.0.1 in the meantime: > > $ git log --oneline > c2443155a0fb245c8f17f2c1c72b6ea391e86e81~1..llvmorg-10.0.1 | wc -l > 7051 > > so can you please update your compiler and see if you can still > reproduce with 10.0.1 so that we don't waste time chasing a bug which > has been likely already fixed in one of those >7K commits. +Alex, Marco, There is suspicion that these may be caused by use of unreleased clang. Do we use the same clang as we use for the KMSAN instance? But this is not KMSAN machine, so I am not sure who/when/why updated it last to this revision. I even see we have some clang 11 version: https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce Is it possible to switch to some released version for both KMSAN and KASAN now?
[PATCH 1/7] clk: qcom: clk-alpha-pll: Add support for Stromer PLLs
Add programming sequence support for managing the Stromer
PLLs.
Signed-off-by: Varadarajan Narayanan
---
drivers/clk/qcom/clk-alpha-pll.c | 156 ++-
drivers/clk/qcom/clk-alpha-pll.h | 5 ++
2 files changed, 160 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 26139ef..ce3257f 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -116,6 +116,19 @@ const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
[PLL_OFF_OPMODE] = 0x38,
[PLL_OFF_ALPHA_VAL] = 0x40,
},
+
+ [CLK_ALPHA_PLL_TYPE_STROMER] = {
+ [PLL_OFF_L_VAL] = 0x08,
+ [PLL_OFF_ALPHA_VAL] = 0x10,
+ [PLL_OFF_ALPHA_VAL_U] = 0x14,
+ [PLL_OFF_USER_CTL] = 0x18,
+ [PLL_OFF_USER_CTL_U] = 0x1c,
+ [PLL_OFF_CONFIG_CTL] = 0x20,
+ [PLL_OFF_CONFIG_CTL_U] = 0xff,
+ [PLL_OFF_TEST_CTL] = 0x30,
+ [PLL_OFF_TEST_CTL_U] = 0x34,
+ [PLL_OFF_STATUS] = 0x28,
+ },
};
EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
@@ -127,6 +140,8 @@ EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
#define ALPHA_BITWIDTH 32U
#define ALPHA_SHIFT(w) min(w, ALPHA_BITWIDTH)
+#definePLL_STATUS_REG_SHIFT8
+
#define PLL_HUAYRA_M_WIDTH 8
#define PLL_HUAYRA_M_SHIFT 8
#define PLL_HUAYRA_M_MASK 0xff
@@ -210,7 +225,7 @@ static int wait_for_pll(struct clk_alpha_pll *pll, u32
mask, bool inverse,
void clk_alpha_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
const struct alpha_pll_config *config)
{
- u32 val, mask;
+ u32 val, val_u, mask, mask_u;
regmap_write(regmap, PLL_L_VAL(pll), config->l);
regmap_write(regmap, PLL_ALPHA_VAL(pll), config->alpha);
@@ -240,14 +255,143 @@ void clk_alpha_pll_configure(struct clk_alpha_pll *pll,
struct regmap *regmap,
mask |= config->pre_div_mask;
mask |= config->post_div_mask;
mask |= config->vco_mask;
+ mask |= config->alpha_en_mask;
+ mask |= config->alpha_mode_mask;
regmap_update_bits(regmap, PLL_USER_CTL(pll), mask, val);
+ /* Stromer APSS PLL does not enable LOCK_DET by default, so enable it */
+ val_u = config->status_reg_val << PLL_STATUS_REG_SHIFT;
+ val_u |= config->lock_det;
+
+ mask_u = config->status_reg_mask;
+ mask_u |= config->lock_det;
+
+ if (val_u != 0)
+ regmap_update_bits(regmap, PLL_USER_CTL_U(pll), mask_u, val_u);
+
+ if (config->test_ctl_val != 0)
+ regmap_write(regmap, PLL_TEST_CTL(pll), config->test_ctl_val);
+
+ if (config->test_ctl_hi_val != 0)
+ regmap_write(regmap, PLL_TEST_CTL_U(pll),
config->test_ctl_hi_val);
+
if (pll->flags & SUPPORTS_FSM_MODE)
qcom_pll_set_fsm_mode(regmap, PLL_MODE(pll), 6, 0);
}
EXPORT_SYMBOL_GPL(clk_alpha_pll_configure);
+static unsigned long
+alpha_pll_stromer_calc_rate(u64 prate, u32 l, u64 a)
+{
+ return (prate * l) + ((prate * a) >> ALPHA_REG_BITWIDTH);
+}
+
+static unsigned long
+alpha_pll_stromer_round_rate(unsigned long rate, unsigned long prate, u32 *l,
u64 *a)
+{
+ u64 remainder;
+ u64 quotient;
+
+ quotient = rate;
+ remainder = do_div(quotient, prate);
+ *l = quotient;
+
+ if (!remainder) {
+ *a = 0;
+ return rate;
+ }
+
+ quotient = remainder << ALPHA_REG_BITWIDTH;
+
+ remainder = do_div(quotient, prate);
+
+ if (remainder)
+ quotient++;
+
+ *a = quotient;
+ return alpha_pll_stromer_calc_rate(prate, *l, *a);
+}
+
+static unsigned long
+clk_alpha_pll_stromer_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+ u32 l, low, high, ctl;
+ u64 a = 0, prate = parent_rate;
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+
+ regmap_read(pll->clkr.regmap, PLL_L_VAL(pll), );
+
+ regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), );
+ if (ctl & PLL_ALPHA_EN) {
+ regmap_read(pll->clkr.regmap, PLL_ALPHA_VAL(pll), );
+ regmap_read(pll->clkr.regmap, PLL_ALPHA_VAL_U(pll),
+ );
+ a = (u64)high << ALPHA_BITWIDTH | low;
+ }
+
+ return alpha_pll_stromer_calc_rate(prate, l, a);
+}
+
+static int clk_alpha_pll_stromer_determine_rate(struct clk_hw *hw,
+struct clk_rate_request *req)
+{
+ unsigned long rate = req->rate;
+ u32 l;
+ u64 a;
+
+ rate = alpha_pll_stromer_round_rate(rate, req->best_parent_rate, ,
);
+
+ return 0;
+}
+
+static int clk_alpha_pll_stromer_set_rate(struct clk_hw *hw, unsigned long
rate,
+unsigned long prate)
+{
+ struct clk_alpha_pll
[PATCH 4/7] dt-bindings: pinctrl: qcom: Add ipq5018 pinctrl bindings
Add device tree binding Documentation details for ipq5018
pinctrl driver.
Signed-off-by: Varadarajan Narayanan
---
.../bindings/pinctrl/qcom,ipq5018-pinctrl.yaml | 143 +
1 file changed, 143 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-pinctrl.yaml
diff --git
a/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-pinctrl.yaml
b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-pinctrl.yaml
new file mode 100644
index ..7fff90d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-pinctrl.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,ipq5018-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. IPQ5018 TLMM block
+
+maintainers:
+ - Nitheesh Sekar
+
+description: |
+ This binding describes the Top Level Mode Multiplexer block found in the
+ IPQ5018 platform.
+
+properties:
+ compatible:
+const: qcom,ipq5018-pinctrl
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description: Specifies the TLMM summary IRQ
+maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+description:
+ Specifies the PIN numbers and Flags, as defined in defined in
+ include/dt-bindings/interrupt-controller/irq.h
+const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+description: Specifying the pin number and flags, as defined in
+ include/dt-bindings/gpio/gpio.h
+const: 2
+
+ gpio-ranges:
+maxItems: 1
+
+#PIN CONFIGURATION NODES
+patternProperties:
+ '-pinmux$':
+type: object
+description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+$ref: "/schemas/pinctrl/pincfg-node.yaml"
+
+properties:
+ pins:
+description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+items:
+ oneOf:
+- pattern: "^gpio([1-9]|[1-7][0-9]|80)$"
+minItems: 1
+maxItems: 4
+
+ function:
+description:
+ Specify the alternative function to be configured for the specified
+ pins.
+enum: [ atest_char, atest_char0, atest_char1, atest_char2, atest_char3,
+ audio_pdm0, audio_pdm1, audio_rxbclk, audio_rxd, audio_rxfsync,
+ audio_rxmclk, audio_txbclk, audio_txd, audio_txfsync, audio_txmclk,
+ blsp0_i2c, blsp0_spi, blsp0_uart0, blsp0_uart1, blsp1_i2c0,
+ blsp1_i2c1, blsp1_spi0, blsp1_spi1, blsp1_uart0, blsp1_uart1,
+ blsp1_uart2, blsp2_i2c0, blsp2_i2c1, blsp2_spi, blsp2_spi0,
+ blsp2_spi1, btss0, btss1, btss10, btss11, btss12, btss13, btss2,
+ btss3, btss4, btss5, btss6, btss7, btss8, btss9, burn0, burn1,
+ cri_trng, cri_trng0, cri_trng1, cxc_clk, cxc_data, dbg_out, eud_gpio,
+ gcc_plltest, gcc_tlmm, gpio, mac0, mac1, mdc, mdio, pcie0_clk,
+ pcie0_wake, pcie1_clk, pcie1_wake, pll_test, prng_rosc, pwm0, pwm1,
+ pwm2, pwm3, qdss_cti_trig_in_a0, qdss_cti_trig_in_a1,
+ qdss_cti_trig_in_b0, qdss_cti_trig_in_b1, qdss_cti_trig_out_a0,
+ qdss_cti_trig_out_a1, qdss_cti_trig_out_b0, qdss_cti_trig_out_b1,
+ qdss_traceclk_a, qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b,
+ qdss_tracedata_a, qdss_tracedata_b, qspi_clk, qspi_cs, qspi0, qspi1,
+ qspi2, qspi3, reset_out, sdc1_clk, sdc1_cmd, sdc10, sdc11, sdc12,
+ sdc13, wci0, wci1, wci2, wci3, wci4, wci5, wci6, wci7, wsa_swrm,
+ wsi_clk3, wsi_data3, wsis_reset, xfem0, xfem1, xfem2, xfem3, xfem4,
+ xfem5, xfem6, xfem7 ]
+
+ drive-strength:
+enum: [2, 4, 6, 8, 10, 12, 14, 16]
+default: 2
+description:
+ Selects the drive strength for the specified pins, in mA.
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+required:
+ - pins
+ - function
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+tlmm: pinctrl@100 {
+ compatible = "qcom,ipq5018-pinctrl";
+ reg = <0x0100 0x30>;
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = < 0 80>;
+
+ serial3-pinmux {
+ pins = "gpio44", "gpio45";
+ function = "blsp2_uart";
+ drive-strength = <8>;
+ bias-pull-down;
+
[PATCH 5/7] pinctrl: qcom: Add IPQ5018 pinctrl driver
This adds the pinctrl definitions for the TLMM of IPQ5018.
Signed-off-by: Varadarajan Narayanan
---
drivers/pinctrl/qcom/Kconfig | 10 +
drivers/pinctrl/qcom/Makefile | 1 +
drivers/pinctrl/qcom/pinctrl-ipq5018.c | 903 +
3 files changed, 914 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq5018.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index f8ff30c..549b630 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -34,6 +34,16 @@ config PINCTRL_IPQ4019
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm IPQ4019 platform.
+config PINCTRL_IPQ5018
+ tristate "Qualcomm Technologies, Inc. IPQ5018 pin controller driver"
+ depends on GPIOLIB && OF
+ select PINCTRL_MSM
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for
+ the Qualcomm Technologies Inc. TLMM block found on the
+ Qualcomm Technologies Inc. IPQ5018 platform. Select this for
+ IPQ5018.
+
config PINCTRL_IPQ8064
tristate "Qualcomm IPQ8064 pin controller driver"
depends on GPIOLIB && OF
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 061ec9f..0c6cbbd 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_PINCTRL_MSM) += pinctrl-msm.o
obj-$(CONFIG_PINCTRL_APQ8064) += pinctrl-apq8064.o
obj-$(CONFIG_PINCTRL_APQ8084) += pinctrl-apq8084.o
obj-$(CONFIG_PINCTRL_IPQ4019) += pinctrl-ipq4019.o
+obj-$(CONFIG_PINCTRL_IPQ5018) += pinctrl-ipq5018.o
obj-$(CONFIG_PINCTRL_IPQ8064) += pinctrl-ipq8064.o
obj-$(CONFIG_PINCTRL_IPQ8074) += pinctrl-ipq8074.o
obj-$(CONFIG_PINCTRL_IPQ6018) += pinctrl-ipq6018.o
diff --git a/drivers/pinctrl/qcom/pinctrl-ipq5018.c
b/drivers/pinctrl/qcom/pinctrl-ipq5018.c
new file mode 100644
index ..92b38c42
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-ipq5018.c
@@ -0,0 +1,903 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2019-2020, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "pinctrl-msm.h"
+
+#define FUNCTION(fname)\
+ [msm_mux_##fname] = { \
+ .name = #fname, \
+ .groups = fname##_groups, \
+ .ngroups = ARRAY_SIZE(fname##_groups), \
+ }
+
+#define REG_SIZE 0x1000
+#define PINGROUP(id, f1, f2, f3, f4, f5, f6, f7, f8, f9) \
+ { \
+ .name = "gpio" #id, \
+ .pins = gpio##id##_pins,\
+ .npins = (unsigned int)ARRAY_SIZE(gpio##id##_pins), \
+ .funcs = (int[]){ \
+ msm_mux_gpio, /* gpio mode */ \
+ msm_mux_##f1, \
+ msm_mux_##f2, \
+ msm_mux_##f3, \
+ msm_mux_##f4, \
+ msm_mux_##f5, \
+ msm_mux_##f6, \
+ msm_mux_##f7, \
+ msm_mux_##f8, \
+ msm_mux_##f9\
+ }, \
+ .nfuncs = 10, \
+ .ctl_reg = REG_SIZE * id, \
+ .io_reg = 0x4 + REG_SIZE * id, \
+ .intr_cfg_reg = 0x8 + REG_SIZE * id,\
+ .intr_status_reg = 0xc + REG_SIZE * id, \
+ .intr_target_reg = 0x8 + REG_SIZE * id, \
+ .mux_bit = 2, \
+ .pull_bit = 0, \
+ .drv_bit = 6, \
+ .oe_bit = 9,\
+ .in_bit = 0,\
+ .out_bit = 1, \
+ .intr_enable_bit = 0, \
+ .intr_status_bit = 0, \
+ .intr_target_bit = 5, \
+ .intr_target_kpss_val = 3, \
+ .intr_raw_status_bit = 4, \
+ .intr_polarity_bit = 1, \
+ .intr_detection_bit = 2,\
+ .intr_detection_width = 2, \
+ }
+
+static const struct pinctrl_pin_desc ipq5018_pins[] = {
+ PINCTRL_PIN(0, "GPIO_0"),
+ PINCTRL_PIN(1, "GPIO_1"),
+ PINCTRL_PIN(2, "GPIO_2"),
+ PINCTRL_PIN(3, "GPIO_3"),
+ PINCTRL_PIN(4, "GPIO_4"),
+ PINCTRL_PIN(5, "GPIO_5"),
+ PINCTRL_PIN(6, "GPIO_6"),
+
[PATCH 0/7] Add minimal boot support for IPQ5018
The IPQ5018 is Qualcomm's 802.11ax SoC for Routers, Gateways and Access Points. This series adds minimal board boot support for ipq5018-mp03.1-c2 board. Varadarajan Narayanan (7): clk: qcom: clk-alpha-pll: Add support for Stromer PLLs dt-bindings: arm64: ipq5018: Add binding descriptions for clock and reset clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018 dt-bindings: pinctrl: qcom: Add ipq5018 pinctrl bindings pinctrl: qcom: Add IPQ5018 pinctrl driver arm64: dts: Add ipq5018 SoC and MP03 board support arm64: defconfig: Enable IPQ5018 SoC base configs Documentation/devicetree/bindings/arm/qcom.yaml|7 + .../devicetree/bindings/clock/qcom,gcc.yaml|3 + .../bindings/pinctrl/qcom,ipq5018-pinctrl.yaml | 143 + arch/arm64/boot/dts/qcom/Makefile |1 + arch/arm64/boot/dts/qcom/ipq5018-mp03.1-c2.dts | 30 + arch/arm64/boot/dts/qcom/ipq5018.dtsi | 201 + arch/arm64/configs/defconfig |3 + drivers/clk/qcom/Kconfig |8 + drivers/clk/qcom/Makefile |1 + drivers/clk/qcom/clk-alpha-pll.c | 156 +- drivers/clk/qcom/clk-alpha-pll.h |5 + drivers/clk/qcom/gcc-ipq5018.c | 3833 drivers/pinctrl/qcom/Kconfig | 10 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-ipq5018.c | 903 + include/dt-bindings/clock/qcom,gcc-ipq5018.h | 183 + include/dt-bindings/reset/qcom,gcc-ipq5018.h | 119 + include/linux/clk-provider.h |4 +- 18 files changed, 5608 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-pinctrl.yaml create mode 100644 arch/arm64/boot/dts/qcom/ipq5018-mp03.1-c2.dts create mode 100644 arch/arm64/boot/dts/qcom/ipq5018.dtsi create mode 100644 drivers/clk/qcom/gcc-ipq5018.c create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq5018.c create mode 100644 include/dt-bindings/clock/qcom,gcc-ipq5018.h create mode 100644 include/dt-bindings/reset/qcom,gcc-ipq5018.h -- 2.7.4
[PATCH 3/7] clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018
Add support for the global clock controller found on IPQ5018
based devices.
Signed-off-by: Varadarajan Narayanan
---
drivers/clk/qcom/Kconfig |8 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/gcc-ipq5018.c | 3833
include/linux/clk-provider.h |4 +-
4 files changed, 3844 insertions(+), 2 deletions(-)
create mode 100644 drivers/clk/qcom/gcc-ipq5018.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 0583273..d1a2504 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -155,6 +155,14 @@ config IPQ_GCC_8074
i2c, USB, SD/eMMC, etc. Select this for the root clock
of ipq8074.
+config IPQ_GCC_5018
+ tristate "IPQ5018 Global Clock Controller"
+ help
+Support for global clock controller on ipq5018 devices.
+Say Y if you want to use peripheral devices such as UART, SPI,
+i2c, USB, SD/eMMC, etc. Select this for the root clock
+of ipq5018.
+
config MSM_GCC_8660
tristate "MSM8660 Global Clock Controller"
help
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 9677e76..1283f70 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_IPQ_GCC_4019) += gcc-ipq4019.o
obj-$(CONFIG_IPQ_GCC_6018) += gcc-ipq6018.o
obj-$(CONFIG_IPQ_GCC_806X) += gcc-ipq806x.o
obj-$(CONFIG_IPQ_GCC_8074) += gcc-ipq8074.o
+obj-$(CONFIG_IPQ_GCC_5018) += gcc-ipq5018.o
obj-$(CONFIG_IPQ_LCC_806X) += lcc-ipq806x.o
obj-$(CONFIG_MDM_GCC_9615) += gcc-mdm9615.o
obj-$(CONFIG_MDM_LCC_9615) += lcc-mdm9615.o
diff --git a/drivers/clk/qcom/gcc-ipq5018.c b/drivers/clk/qcom/gcc-ipq5018.c
new file mode 100644
index ..9056386
--- /dev/null
+++ b/drivers/clk/qcom/gcc-ipq5018.c
@@ -0,0 +1,3833 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "clk-alpha-pll.h"
+#include "clk-regmap-divider.h"
+#include "clk-regmap-mux.h"
+#include "reset.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+enum {
+ P_XO,
+ P_GPLL0,
+ P_GPLL0_DIV2,
+ P_GPLL2,
+ P_GPLL4,
+ P_UBI32_PLL,
+ P_GEPHY_RX,
+ P_GEPHY_TX,
+ P_UNIPHY_RX,
+ P_UNIPHY_TX,
+ P_CORE_PI_SLEEP_CLK,
+ P_PCIE20_PHY0_PIPE,
+ P_PCIE20_PHY1_PIPE,
+ P_USB3PHY_0_PIPE,
+};
+
+static const char * const gcc_xo_gpll0_gpll0_out_main_div2[] = {
+ "xo",
+ "gpll0",
+ "gpll0_out_main_div2",
+};
+
+static const struct parent_map gcc_xo_gpll0_gpll0_out_main_div2_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 1 },
+ { P_GPLL0_DIV2, 4 },
+};
+
+static const char * const gcc_xo_gpll0[] = {
+ "xo",
+ "gpll0",
+};
+
+static const struct parent_map gcc_xo_gpll0_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 1 },
+};
+
+static const char * const gcc_xo_gpll0_out_main_div2_gpll0[] = {
+ "xo",
+ "gpll0_out_main_div2",
+ "gpll0",
+};
+
+static const struct parent_map gcc_xo_gpll0_out_main_div2_gpll0_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0_DIV2, 2 },
+ { P_GPLL0, 1 },
+};
+
+static const char * const gcc_xo_ubi32_gpll0[] = {
+ "xo",
+ "ubi32_pll",
+ "gpll0",
+};
+
+static const struct parent_map gcc_xo_ubi32_gpll0_map[] = {
+ { P_XO, 0 },
+ { P_UBI32_PLL, 1 },
+ { P_GPLL0, 2 },
+};
+
+static const char * const gcc_xo_gpll0_gpll2[] = {
+ "xo",
+ "gpll0",
+ "gpll2",
+};
+
+static const struct parent_map gcc_xo_gpll0_gpll2_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 1 },
+ { P_GPLL2, 2 },
+};
+
+static const char * const gcc_xo_gpll0_gpll2_gpll4[] = {
+ "xo",
+ "gpll0",
+ "gpll2",
+ "gpll4",
+};
+
+static const struct parent_map gcc_xo_gpll0_gpll2_gpll4_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 1 },
+ { P_GPLL2, 2 },
+ { P_GPLL4, 3 },
+};
+
+static const char * const gcc_xo_gpll0_out_main_div2[] = {
+ "xo",
+ "gpll0_out_main_div2",
+};
+
+static const struct parent_map gcc_xo_gpll0_out_main_div2_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0_DIV2, 1 },
+};
+
+static const char * const gcc_xo_gpll0_gpll4[] = {
+ "xo",
+ "gpll0",
+ "gpll4",
+};
+
+static const struct parent_map gcc_xo_gpll0_gpll4_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 1 },
+ { P_GPLL4, 2 },
+};
+
+static const char * const gcc_xo_gpll0_core_pi_sleep_clk[] = {
+ "xo",
+ "gpll0",
+ "sleep_clk",
+};
+
+static const struct parent_map gcc_xo_gpll0_core_pi_sleep_clk_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 2 },
+ { P_CORE_PI_SLEEP_CLK, 6 },
+};
+
+static const char * const gcc_xo_gpll0_gpll0_out_main_div2_sleep_clk[]
Re: [PATCH v2] lockdep: Allow tuning tracing capacity constants.
On Mon, Sep 28, 2020 at 2:24 AM Tetsuo Handa wrote: > > On 2020/09/16 21:14, Dmitry Vyukov wrote: > > On Wed, Sep 16, 2020 at 1:51 PM wrote: > >> > >> On Wed, Sep 16, 2020 at 01:28:19PM +0200, Dmitry Vyukov wrote: > >>> On Fri, Sep 4, 2020 at 6:05 PM Tetsuo Handa > >>> wrote: > > Hello. Can we apply this patch? > > This patch addresses top crashers for syzbot, and applying this patch > will help utilizing syzbot's resource for finding other bugs. > >>> > >>> Acked-by: Dmitry Vyukov > >>> > >>> Peter, do you still have concerns with this? > >> > >> Yeah, I still hate it with a passion; it discourages thinking. A bad > >> annotation that blows up the lockdep storage, no worries, we'll just > >> increase this :/ > >> > >> IIRC the issue with syzbot is that the current sysfs annotation is > >> pretty terrible and generates a gazillion classes, and syzbot likes > >> poking at /sys a lot and thus floods the system. > >> > >> I don't know enough about sysfs to suggest an alternative, and haven't > >> exactly had spare time to look into it either :/ > >> > >> Examples of bad annotations is getting every CPU a separate class, that > >> leads to nr_cpus! chains if CPUs arbitrarily nest (nr_cpus^2 if there's > >> only a single nesting level). > > > > Maybe on "BUG: MAX_LOCKDEP_CHAINS too low!" we should then aggregate, > > sort and show existing chains so that it's possible to identify if > > there are any worst offenders and who they are. > > > > Currently we only have a hypothesis that there are some worst > > offenders vs lots of normal load. And we can't point fingers which > > means that, say, sysfs, or other maintainers won't be too inclined to > > fix anything. > > > > If we would know for sure that lock class X is guilty. That would make > > the situation much more actionable. > > > > Dmitry is thinking that we need to use CONFIG_LOCKDEP=n temporary until > lockdep > problems are resolved. ( https://github.com/google/syzkaller/issues/2140 ) > > But I think it is better to apply this patch (and revert this patch when it > became > possible to identify if there are any worst offenders and who they are) than > using > CONFIG_LOCKDEP=n. > > CONFIG_LOCKDEP=n causes "#syz test" request to cause false response regarding > locking > related issues, for we are not ready to enforce "retest without proposed patch > when test with proposed patch did not reproduce the crash". FWIW patch testing for previously reported bugs should still work because it uses the kernel config associated with the bug report. > I think that "not detecting lock related problems introduced by new patches" > costs > more than "postpone fixing lock related problems in existing code".
Re: [PATCH] xfrm: Use correct address family in xfrm_state_find
On Fri, Sep 25, 2020 at 02:42:56PM +1000, Herbert Xu wrote:
> Resend with proper subject.
>
> ---8<---
> The struct flowi must never be interpreted by itself as its size
> depends on the address family. Therefore it must always be grouped
> with its original family value.
>
> In this particular instance, the original family value is lost in
> the function xfrm_state_find. Therefore we get a bogus read when
> it's coupled with the wrong family which would occur with inter-
> family xfrm states.
>
> This patch fixes it by keeping the original family value.
>
> Note that the same bug could potentially occur in LSM through
> the xfrm_state_pol_flow_match hook. I checked the current code
> there and it seems to be safe for now as only secid is used which
> is part of struct flowi_common. But that API should be changed
> so that so that we don't get new bugs in the future. We could
> do that by replacing fl with just secid or adding a family field.
>
> Reported-by: syzbot+577fbac3145a6eb2e...@syzkaller.appspotmail.com
> Fixes: 48b8d78315bf ("[XFRM]: State selection update to use inner...")
> Signed-off-by: Herbert Xu
Applied, thanks a lot Herbert!
[PATCH] thermal: imx: Correct run_measurement check method
It is incorrect to use irq_enabled flag for run_measurement check, as
irq_enabled is NOT always equal to thermal mode, when temperature is
higher than passive point, an alarm irq will be pending, and irq_enabled
flag will be set to false while thermal mode is still enabled, then the
following temperature read will power down thermal sensor, and next time
irq_enabled flag will set to true when temperature drop to below than
passive point, next temperature read will fail due to thermal sensor is NOT
power up at all, the error log is as below:
root@imx6qdlsolo:~# cat /sys/class/thermal/thermal_zone0/temp
cat: /sys/class/thermal/thermal_zone0/temp: Resource temporarily unavailable
So, it should read the thermal sensor's power down bit to decide whether
to run measurement.
Fixes: d92ed2c9d3ff ("thermal: imx: Use driver's local data to decide whether
to run a measurement")
Signed-off-by: Anson Huang
---
drivers/thermal/imx_thermal.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 2c7473d..9f00182 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -255,7 +255,8 @@ static int imx_get_temp(struct thermal_zone_device *tz, int
*temp)
bool wait, run_measurement;
u32 val;
- run_measurement = !data->irq_enabled;
+ regmap_read(map, soc_data->sensor_ctrl, );
+ run_measurement = val & soc_data->power_down_mask;
if (!run_measurement) {
/* Check if a measurement is currently in progress */
regmap_read(map, soc_data->temp_data, );
--
2.7.4
Re: [linux-sunxi] [PATCH v5 04/20] dt-bindings: ASoC: sun4i-i2s: Add H6 compatible
On Mon, Sep 28, 2020 at 3:29 AM Clément Péron wrote: > > From: Jernej Skrabec > > H6 I2S is very similar to H3, except that it supports up to 16 channels > and thus few registers have fields on different position. > > Signed-off-by: Jernej Skrabec > Signed-off-by: Marcus Cooper > Signed-off-by: Clément Péron > Acked-by: Maxime Ripard > Acked-by: Rob Herring Acked-by: Chen-Yu Tsai
Re: [linux-sunxi] [PATCH v5 03/20] ASoC: sun4i-i2s: Change get_sr() and get_wss() to be more explicit
On Mon, Sep 28, 2020 at 12:37 PM Chen-Yu Tsai wrote:
>
> On Mon, Sep 28, 2020 at 3:29 AM Clément Péron wrote:
> >
> > We are actually using a complex formula to just return a bunch of
> > simple values. Also this formula is wrong for sun4i when calling
BTW, it is entirely possible that the compiler optimizes your switch-case
back into the original complex formula you replaced. :)
> > get_wss() the function return 4 instead of 3.
> >
> > Replace this with a simpler switch case.
> >
> > Also drop the i2s params which is unused and return a simple int as
> > returning an error code could be out of range for an s8 and there is
> > no optim to return a s8 here.
> >
> > Signed-off-by: Clément Péron
>
> Fixes: 619c15f7fac9 ("ASoC: sun4i-i2s: Change SR and WSS computation")
>
> Reviewed-by: Chen-Yu Tsai
Re: [linux-sunxi] [PATCH v5 02/20] ASoC: sun4i-i2s: Change set_chan_cfg() params
On Mon, Sep 28, 2020 at 3:29 AM Clément Péron wrote:
>
> As slots and slot_width can be overwritter in case set_tdm() is
> called. Avoid to have this logic in set_chan_cfg().
It doesn't seem that set_tdm_slot() would get called concurrently
with hw_params(), at least not for the simple-card family. If so
then we'd have more problems like mismatched slots/slot-width
due to no serialization when interacting with those values.
> Instead pass the required values as params to set_chan_cfg().
>
> This will also avoid a bug when we will enable 20/24bits support,
> i2s->slot_width is not actually used in the lrck_period computation.
>
> Suggested-by: Samuel Holland
> Signed-off-by: Clément Péron
> ---
> sound/soc/sunxi/sun4i-i2s.c | 36 ++--
> 1 file changed, 14 insertions(+), 22 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index 2baf6c276280..0633b9fba3d7 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -177,8 +177,9 @@ struct sun4i_i2s_quirks {
> unsigned long (*get_bclk_parent_rate)(const struct sun4i_i2s *);
> s8 (*get_sr)(const struct sun4i_i2s *, int);
> s8 (*get_wss)(const struct sun4i_i2s *, int);
> - int (*set_chan_cfg)(const struct sun4i_i2s *,
> - const struct snd_pcm_hw_params *);
> + int (*set_chan_cfg)(const struct sun4i_i2s *i2s,
> + unsigned int channels, unsigned int slots,
> + unsigned int slot_width);
> int (*set_fmt)(const struct sun4i_i2s *, unsigned int);
> };
>
> @@ -414,10 +415,9 @@ static s8 sun8i_i2s_get_sr_wss(const struct sun4i_i2s
> *i2s, int width)
> }
>
> static int sun4i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
> - const struct snd_pcm_hw_params *params)
> + unsigned int channels, unsigned int slots,
> + unsigned int slot_width)
> {
> - unsigned int channels = params_channels(params);
> -
> /* Map the channels for playback and capture */
> regmap_write(i2s->regmap, SUN4I_I2S_TX_CHAN_MAP_REG, 0x76543210);
> regmap_write(i2s->regmap, SUN4I_I2S_RX_CHAN_MAP_REG, 0x3210);
> @@ -434,15 +434,11 @@ static int sun4i_i2s_set_chan_cfg(const struct
> sun4i_i2s *i2s,
> }
>
> static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
> - const struct snd_pcm_hw_params *params)
> + unsigned int channels, unsigned int slots,
> + unsigned int slot_width)
> {
> - unsigned int channels = params_channels(params);
> - unsigned int slots = channels;
> unsigned int lrck_period;
>
> - if (i2s->slots)
> - slots = i2s->slots;
> -
Based on the bug you highlighted in your expanded commit log, the simpler fix
would be to look at i2s->slot_width in addition to i2s->slots, and replace
params_physical_width(params) accordingly.
Also, I would put fixes (even preparatory ones) before patches that introduce
support for new features and hardware. That makes them easier to backport if
needed.
ChenYu
> /* Map the channels for playback and capture */
> regmap_write(i2s->regmap, SUN8I_I2S_TX_CHAN_MAP_REG, 0x76543210);
> regmap_write(i2s->regmap, SUN8I_I2S_RX_CHAN_MAP_REG, 0x76543210);
> @@ -467,11 +463,11 @@ static int sun8i_i2s_set_chan_cfg(const struct
> sun4i_i2s *i2s,
> case SND_SOC_DAIFMT_DSP_B:
> case SND_SOC_DAIFMT_LEFT_J:
> case SND_SOC_DAIFMT_RIGHT_J:
> - lrck_period = params_physical_width(params) * slots;
> + lrck_period = slot_width * slots;
> break;
>
> case SND_SOC_DAIFMT_I2S:
> - lrck_period = params_physical_width(params);
> + lrck_period = slot_width;
> break;
>
> default:
RE: [PATCH 2/5 V4] PCI: pciehp: check and wait port status out of DPC before handling DLLSC and PDC
Sathyanarayanan， -Original Message- From: Kuppuswamy, Sathyanarayanan Sent: Monday, September 28, 2020 2:59 AM To: Zhao, Haifeng ; bhelg...@google.com; ooh...@gmail.com; rus...@russell.cc; lu...@wunner.de; andriy.shevche...@linux.intel.com; stuart.w.ha...@gmail.com; mr.nuke...@gmail.com; mika.westerb...@linux.intel.com Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jia, Pei P ; ashok@linux.intel.com; h...@infradead.org; j...@perches.com Subject: Re: [PATCH 2/5 V4] PCI: pciehp: check and wait port status out of DPC before handling DLLSC and PDC On 9/27/20 1:27 AM, Ethan Zhao wrote: > When root port has DPC capability and it is enabled, then triggered by > errors, DPC DLLSC and PDC interrupts will be sent to DPC driver, > pciehp driver at the same time. > That will cause following result: > > 1. Link and device are recovered by hardware DPC and software DPC driver, > device > isn't removed, but the pciehp might treat it as device was hot removed. > > 2. Race condition happens bettween pciehp_unconfigure_device() called by > pciehp_ist() in pciehp driver and pci_do_recovery() called by > dpc_handler in DPC driver. no luck, there is no lock to protect > pci_stop_and_remove_bus_device() > against pci_walk_bus(), they hold different samphore and mutex, > pci_stop_and_remove_bus_device holds pci_rescan_remove_lock, and > pci_walk_bus() holds pci_bus_sem. Why not address the locking issue? May be a common lock? > > This race condition is not purely code analysis, it could be triggered > by following command series: > ># setpci -s 64:02.0 0x196.w=000a // 64:02.0 rootport has DPC capability ># setpci -s 65:00.0 0x04.w=0544 // 65:00.0 NVMe SSD populated in port ># mount /dev/nvme0n1p1 nvme > > One shot will cause system panic and NULL pointer reference happened. > (tested on stable 5.8 & ICS(Ice Lake SP platform, see > https://en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(server > )) > > Buffer I/O error on dev nvme0n1p1, logical block 3328, async page read > BUG: kernel NULL pointer dereference, address: 0050 > #PF: supervisor read access in kernel mode > #PF: error_code(0x) - not-present page > PGD 0 > Oops: [#1] SMP NOPTI > CPU: 12 PID: 513 Comm: irq/124-pcie-dp Not tainted 5.8.0 el8.x86_64+ #1 > RIP: 0010:report_error_detected.cold.4+0x7d/0xe6 > Code: b6 d0 e8 e8 fe 11 00 e8 16 c5 fb ff be 06 00 00 00 48 89 df e8 d3 > 65 ff ff b8 06 00 00 00 e9 75 fc ff ff 48 8b 43 68 45 31 c9 <48> 8b 50 > 50 48 83 3a 00 41 0f 94 c1 45 31 c0 48 85 d2 41 0f 94 c0 > RSP: 0018:ff8e06cf8762fda8 EFLAGS: 00010246 > RAX: RBX: ff4e3eaacf42a000 RCX: ff4e3eb31f223c01 > RDX: ff4e3eaacf42a140 RSI: ff4e3eb31f223c00 RDI: ff4e3eaacf42a138 > RBP: ff8e06cf8762fdd0 R08: 00bf R09: > R10: 00eb8ebeab53 R11: 93453258 R12: 0002 > R13: ff4e3eaacf42a130 R14: ff8e06cf8762fe2c R15: ff4e3eab44733828 > FS: () GS:ff4e3eab1fd0() knl > GS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 0050 CR3: 000f8f80a004 CR4: 00761ee0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > PKRU: 5554 > Call Trace: > ? report_normal_detected+0x20/0x20 > report_frozen_detected+0x16/0x20 > pci_walk_bus+0x75/0x90 > ? dpc_irq+0x90/0x90 > pcie_do_recovery+0x157/0x201 > ? irq_finalize_oneshot.part.47+0xe0/0xe0 > dpc_handler+0x29/0x40 > irq_thread_fn+0x24/0x60 > irq_thread+0xea/0x170 > ? irq_forced_thread_fn+0x80/0x80 > ? irq_thread_check_affinity+0xf0/0xf0 > kthread+0x124/0x140 > ? kthread_park+0x90/0x90 > ret_from_fork+0x1f/0x30 > Modules linked in: nft_fib_inet. > CR2: 0050 > > With this patch, the handling flow of DPC containment and hotplug is > partly ordered and serialized, If its a partial fix, what scenario is not covered? :see the 1/5 patch. > let hardware DPC do the controller reset etc recovery action first, > then DPC driver handling the call-back from device drivers, clear the > DPC status, at the end, pciehp handle the DLLSC and PDC etc. > > Signed-off-by: Ethan Zhao > Tested-by: Wen Jin > Tested-by: Shanshan Zhang > Reviewed-by: Andy Shevchenko > --- > Changes: > V2: revise doc according to Andy's suggestion. > V3: no change. > V4: no change. > > drivers/pci/hotplug/pciehp_hpc.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/hotplug/pciehp_hpc.c > b/drivers/pci/hotplug/pciehp_hpc.c > index 53433b37e181..6f271160f18d 100644 > --- a/drivers/pci/hotplug/pciehp_hpc.c > +++ b/drivers/pci/hotplug/pciehp_hpc.c > @@ -710,8 +710,10 @@ static irqreturn_t pciehp_ist(int irq, void *dev_id)
nouveau in kernel v5.9-rc7
Hello. Just built kernel 5.9-rc7, and ran it for about 30 minutes. Moved the mouse and saw it was jumping (pointer not moving smoothly). Dmesg showed: 5409.255054] nouveau :02:00.0: DRM: base-0: timeout [ 5411.380728] nouveau :02:00.0: DRM: base-0: timeout [ 5413.430281] nouveau :02:00.0: DRM: base-0: timeout [ 5415.443402] nouveau :02:00.0: DRM: base-0: timeout [ 5417.452150] nouveau :02:00.0: DRM: base-0: timeout [ 5419.470247] nouveau :02:00.0: DRM: base-0: timeout [ 5421.492721] nouveau :02:00.0: DRM: base-0: timeout [ 5423.507895] nouveau :02:00.0: DRM: base-0: timeout [ 5425.518642] nouveau :02:00.0: DRM: base-0: timeout [ 5427.535112] nouveau :02:00.0: DRM: base-0: timeout [ 5429.552140] nouveau :02:00.0: DRM: base-0: timeout [ 5429.704813] nouveau :02:00.0: disp: ERROR 5 [INVALID_STATE] 0b [] chid 1 mthd 0080 data 0001 [ 5429.704835] nouveau :02:00.0: disp: Base 1: [ 5429.704841] nouveau :02:00.0: disp: 0084: [ 5429.704846] nouveau :02:00.0: disp: 0088: [ 5429.704851] nouveau :02:00.0: disp: 008c: [ 5429.704856] nouveau :02:00.0: disp: 0090: [ 5429.704863] nouveau :02:00.0: disp: 0094: [ 5429.704871] nouveau :02:00.0: disp: 00a0: 0060 [ 5429.704879] nouveau :02:00.0: disp: 00a4: f000 [ 5429.704886] nouveau :02:00.0: disp: 00c0: fbfe [ 5429.704894] nouveau :02:00.0: disp: 00c4: [ 5429.704902] nouveau :02:00.0: disp: 00c8: [ 5429.704909] nouveau :02:00.0: disp: 00cc: [ 5429.704917] nouveau :02:00.0: disp: 00e0: 4000 [ 5429.704924] nouveau :02:00.0: disp: 00e4: [ 5429.704933] nouveau :02:00.0: disp: 00e8: [ 5429.704940] nouveau :02:00.0: disp: 00ec: [ 5429.704948] nouveau :02:00.0: disp: 00fc: [ 5429.704955] nouveau :02:00.0: disp: 0100: fffe [ 5429.704963] nouveau :02:00.0: disp: 0104: [ 5429.704970] nouveau :02:00.0: disp: 0110: [ 5429.704978] nouveau :02:00.0: disp: 0114: [ 5429.704982] nouveau :02:00.0: disp: Base 1 - Image 0: [ 5429.704990] nouveau :02:00.0: disp: 0800: 00032c00 -> 0005ca00 [ 5429.704998] nouveau :02:00.0: disp: 0804: [ 5429.705005] nouveau :02:00.0: disp: 0808: 04380f00 [ 5429.705013] nouveau :02:00.0: disp: 080c: f004 [ 5429.705021] nouveau :02:00.0: disp: 0810: cf00 [ 5429.705024] nouveau :02:00.0: disp: Base 1 - Image 1: [ 5429.705032] nouveau :02:00.0: disp: 0c00: 00032c00 -> 0005ca00 [ 5429.705040] nouveau :02:00.0: disp: 0c04: [ 5429.705048] nouveau :02:00.0: disp: 0c08: 04380f00 [ 5429.705055] nouveau :02:00.0: disp: 0c0c: f004 [ 5429.705063] nouveau :02:00.0: disp: 0c10: cf00 When running kernel 5.8.0, my card information is: Direct Rendering direct rendering: Yes GL_AMD_gpu_shader_int64, GL_AMD_multi_draw_indirect, GL_ARB_depth_clamp, GL_ARB_derivative_control, GL_ARB_direct_state_access, GL_ARB_draw_elements_base_vertex, GL_ARB_draw_indirect, GL_ARB_indirect_parameters, GL_ARB_instanced_arrays, GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multi_draw_indirect, GL_AMD_multi_draw_indirect, GL_AMD_performance_monitor, GL_ARB_direct_state_access, GL_ARB_draw_buffers, GL_ARB_draw_indirect, GL_ARB_draw_instanced, GL_ARB_enhanced_layouts, GL_ARB_indirect_parameters, GL_ARB_instanced_arrays, GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multi_draw_indirect, GL_EXT_direct_state_access, GL_EXT_draw_buffers2, GL_EXT_draw_instanced, Clocks 03: core 50 MHz memory 135 MHz 07: core 405 MHz memory 324 MHz 0f: core 810 MHz memory 700 MHz AC: core 405 MHz memory 324 MHz loaded video module parameters and values name: video brightness_switch_enabled: (bool) allow_duplicates: (bool) disable_backlight_sysfs_if: (int) report_key_events:0: none, 1: output changes, 2: brightness changes, 3: all (int) hw_changes_brightness:Set this to 1 on buggy hw which changes the brightness itself when a hotkey is pressed: -1: auto, 0: normal 1: hw-changes-brightness (int) device_id_scheme: (bool) only_lcd: (int) OpenGL vendor string: nouveau OpenGL renderer string: NVC1 OpenGL core profile version string: 4.3 (Core Profile) Mesa 20.0.8 OpenGL core profile shading language version string: 4.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.3 (Compatibility Profile) Mesa 20.0.8 OpenGL shading language version string: 4.30 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.0.8 OpenGL ES profile shading language version string: OpenGL ES GLSL ES
[PATCH 3/3] e1000e: Add more Dell CML systems into s0ix heuristics
These comet lake systems are not yet released, but have been validated
on pre-release hardware.
This is being submitted separately from released hardware in case of
a regression between pre-release and release hardware so this commit
can be reverted alone.
Signed-off-by: Mario Limonciello
---
drivers/net/ethernet/intel/e1000e/param.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/param.c
b/drivers/net/ethernet/intel/e1000e/param.c
index 58e6718c4f75..fe3157c8aa4a 100644
--- a/drivers/net/ethernet/intel/e1000e/param.c
+++ b/drivers/net/ethernet/intel/e1000e/param.c
@@ -273,6 +273,27 @@ static const struct dmi_system_id s0ix_supported_systems[]
= {
DMI_MATCH(DMI_PRODUCT_SKU, "09C4"),
},
},
+ {
+ /* Dell Notebook 0x0A40 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "0A40"),
+ },
+ },
+ {
+ /* Dell Notebook 0x0A41 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "0A41"),
+ },
+ },
+ {
+ /* Dell Notebook 0x0A42 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "0A42"),
+ },
+ },
{ }
};
--
2.25.1
[PATCH 1/3] e1000e: allow turning s0ix flows on for systems with ME
S0ix for GBE flows are needed for allowing the system to get into deepest
power state, but these require coordination of components outside of
control of Linux kernel. For systems that have confirmed to coordinate
this properly, allow turning on the s0ix flows at load time or runtime.
Fixes: e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME systems")
Signed-off-by: Mario Limonciello
---
.../device_drivers/ethernet/intel/e1000e.rst | 23
drivers/net/ethernet/intel/e1000e/e1000.h | 7 ++
drivers/net/ethernet/intel/e1000e/netdev.c| 64 +-
drivers/net/ethernet/intel/e1000e/param.c | 110 ++
4 files changed, 166 insertions(+), 38 deletions(-)
diff --git a/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst
b/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst
index f49cd370e7bf..da029b703573 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst
@@ -249,6 +249,29 @@ Debug
This parameter adjusts the level of debug messages displayed in the system
logs.
+EnableS0ix
+--
+:Valid Range: 0, 1, 2
+:Default Value: 1 (Use Heuristics)
+
+ +---++
+ | Value |EnableS0ix |
+ +===++
+ | 0 |Disabled|
+ +---++
+ | 1 | Use Heuristics |
+ +---++
+ | 2 |Enabled |
+ +---++
+
+Controls whether the e1000e driver will attempt s0ix flows. S0ix flows require
+correct platform configuration. By default the e1000e driver will use some
heuristics
+to decide whether to enable s0ix. This parameter can be used to override
heuristics.
+
+Additionally a sysfs file "enable_s0ix" will be present that can change the
value at
+runtime.
+
+Note: This option is only effective on Cannon Point or later hardware.
Additional Features and Configurations
==
diff --git a/drivers/net/ethernet/intel/e1000e/e1000.h
b/drivers/net/ethernet/intel/e1000e/e1000.h
index ba7a0f8f6937..32262fa7e085 100644
--- a/drivers/net/ethernet/intel/e1000e/e1000.h
+++ b/drivers/net/ethernet/intel/e1000e/e1000.h
@@ -436,6 +436,7 @@ s32 e1000e_get_base_timinca(struct e1000_adapter *adapter,
u32 *timinca);
#define FLAG2_DFLT_CRC_STRIPPING BIT(12)
#define FLAG2_CHECK_RX_HWTSTAMP BIT(13)
#define FLAG2_CHECK_SYSTIM_OVERFLOW BIT(14)
+#define FLAG2_ENABLE_S0IX_FLOWS BIT(15)
#define E1000_RX_DESC_PS(R, i) \
(&(((union e1000_rx_desc_packet_split *)((R).desc))[i]))
@@ -462,6 +463,12 @@ enum latency_range {
extern char e1000e_driver_name[];
void e1000e_check_options(struct e1000_adapter *adapter);
+ssize_t enable_s0ix_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+ssize_t enable_s0ix_show(struct device *dev,
+struct device_attribute *attr,
+char *buf);
void e1000e_set_ethtool_ops(struct net_device *netdev);
int e1000e_open(struct net_device *netdev);
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 664e8ccc88d2..4359e809d684 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -103,44 +103,16 @@ static const struct e1000_reg_info e1000_reg_info_tbl[] =
{
{0, NULL}
};
-struct e1000e_me_supported {
- u16 device_id; /* supported device ID */
-};
+static DEVICE_ATTR_RW(enable_s0ix);
-static const struct e1000e_me_supported me_supported[] = {
- {E1000_DEV_ID_PCH_LPT_I217_LM},
- {E1000_DEV_ID_PCH_LPTLP_I218_LM},
- {E1000_DEV_ID_PCH_I218_LM2},
- {E1000_DEV_ID_PCH_I218_LM3},
- {E1000_DEV_ID_PCH_SPT_I219_LM},
- {E1000_DEV_ID_PCH_SPT_I219_LM2},
- {E1000_DEV_ID_PCH_LBG_I219_LM3},
- {E1000_DEV_ID_PCH_SPT_I219_LM4},
- {E1000_DEV_ID_PCH_SPT_I219_LM5},
- {E1000_DEV_ID_PCH_CNP_I219_LM6},
- {E1000_DEV_ID_PCH_CNP_I219_LM7},
- {E1000_DEV_ID_PCH_ICP_I219_LM8},
- {E1000_DEV_ID_PCH_ICP_I219_LM9},
- {E1000_DEV_ID_PCH_CMP_I219_LM10},
- {E1000_DEV_ID_PCH_CMP_I219_LM11},
- {E1000_DEV_ID_PCH_CMP_I219_LM12},
- {E1000_DEV_ID_PCH_TGP_I219_LM13},
- {E1000_DEV_ID_PCH_TGP_I219_LM14},
- {E1000_DEV_ID_PCH_TGP_I219_LM15},
- {0}
+static struct attribute *e1000e_attrs[] = {
+ _attr_enable_s0ix.attr,
+ NULL,
};
-static bool e1000e_check_me(u16 device_id)
-{
- struct e1000e_me_supported *id;
-
- for (id = (struct e1000e_me_supported *)me_supported;
-id->device_id; id++)
- if (device_id == id->device_id)
- return true;
-
- return false;
-}
+static struct attribute_group e1000e_group = {
+
[PATCH 0/3] Improve s0ix flows for systems i219LM
commit e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME systems")
disabled s0ix flows for systems that have various incarnations of the
i219-LM ethernet controller. This was done because of some regressions
caused by an earlier
commit 632fbd5eb5b0e ("e1000e: fix S0ix flows for cable connected case")
with i219-LM controller.
Performing suspend to idle with these ethernet controllers requires a properly
configured system. To make enabling such systems easier, this patch
series offers configuration options to enable/disable the flows.
The flows have also been confirmed to be configured correctly on Dell's Latitude
and Precision CML systems containing the i219-LM controller, when the kernel
also
contains the fix for s0i3.2 entry here:
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20200914/021361.html
Patches 2 and 3 will turn the behavior on by default for Dell's CML systems.
These patches should only be carried if that patch linked above is also applied.
Mario Limonciello (3):
e1000e: allow turning s0ix flows on for systems with ME
e1000e: Add Dell's Comet Lake systems into s0ix heuristics
e1000e: Add more Dell CML systems into s0ix heuristics
.../device_drivers/ethernet/intel/e1000e.rst | 23 ++
drivers/net/ethernet/intel/Kconfig| 1 +
drivers/net/ethernet/intel/e1000e/e1000.h | 7 +
drivers/net/ethernet/intel/e1000e/netdev.c| 64 +++---
drivers/net/ethernet/intel/e1000e/param.c | 209 ++
5 files changed, 266 insertions(+), 38 deletions(-)
--
2.25.1
Re: [linux-sunxi] [PATCH v5 01/20] ASoC: sun4i-i2s: Add support for H6 I2S
On Mon, Sep 28, 2020 at 3:29 AM Clément Péron wrote:
>
> From: Jernej Skrabec
>
> H6 I2S is very similar to that in H3, except it supports up to 16
> channels.
>
> Signed-off-by: Jernej Skrabec
> Signed-off-by: Marcus Cooper
> Signed-off-by: Clément Péron
> ---
> sound/soc/sunxi/sun4i-i2s.c | 224
> 1 file changed, 224 insertions(+)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index f23ff29e7c1d..2baf6c276280 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -124,6 +124,21 @@
> #define SUN8I_I2S_RX_CHAN_SEL_REG 0x54
> #define SUN8I_I2S_RX_CHAN_MAP_REG 0x58
>
> +/* Defines required for sun50i-h6 support */
> +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASK GENMASK(21, 20)
> +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(offset) ((offset) << 20)
> +#define SUN50I_H6_I2S_TX_CHAN_SEL_MASK GENMASK(19, 16)
> +#define SUN50I_H6_I2S_TX_CHAN_SEL(chan)((chan - 1) << 16)
> +#define SUN50I_H6_I2S_TX_CHAN_EN_MASK GENMASK(15, 0)
> +#define SUN50I_H6_I2S_TX_CHAN_EN(num_chan) (((1 << num_chan) - 1))
> +
> +#define SUN50I_H6_I2S_TX_CHAN_MAP0_REG 0x44
> +#define SUN50I_H6_I2S_TX_CHAN_MAP1_REG 0x48
> +
> +#define SUN50I_H6_I2S_RX_CHAN_SEL_REG 0x64
> +#define SUN50I_H6_I2S_RX_CHAN_MAP0_REG 0x68
> +#define SUN50I_H6_I2S_RX_CHAN_MAP1_REG 0x6C
> +
> struct sun4i_i2s;
>
> /**
> @@ -474,6 +489,62 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s
> *i2s,
> return 0;
> }
>
> +static int sun50i_h6_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
> + const struct snd_pcm_hw_params *params)
> +{
> + unsigned int channels = params_channels(params);
> + unsigned int slots = channels;
> + unsigned int lrck_period;
> +
> + if (i2s->slots)
> + slots = i2s->slots;
> +
> + /* Map the channels for playback and capture */
> + regmap_write(i2s->regmap, SUN50I_H6_I2S_TX_CHAN_MAP1_REG, 0x76543210);
> + regmap_write(i2s->regmap, SUN50I_H6_I2S_RX_CHAN_MAP1_REG, 0x76543210);
Nit, since it supports up to 16 channels, you might want to map all 16 of them
now, instead of having to come back and fix it later.
Code wise, this patch is
Reviewed-by: Chen-Yu Tsai
I don't have a scope nor logic analyzer, so I wasn't able to participate in the
LRCK discussion.
[PATCH 2/3] e1000e: Add Dell's Comet Lake systems into s0ix heuristics
Dell's Comet Lake Latitude and Precision systems containing i219LM are
properly configured and should use the s0ix flows.
Signed-off-by: Mario Limonciello
---
drivers/net/ethernet/intel/Kconfig| 1 +
drivers/net/ethernet/intel/e1000e/param.c | 80 ++-
2 files changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/Kconfig
b/drivers/net/ethernet/intel/Kconfig
index 5aa86318ed3e..280af47d74d2 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -58,6 +58,7 @@ config E1000
config E1000E
tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
depends on PCI && (!SPARC32 || BROKEN)
+ depends on DMI
select CRC32
imply PTP_1588_CLOCK
help
diff --git a/drivers/net/ethernet/intel/e1000e/param.c
b/drivers/net/ethernet/intel/e1000e/param.c
index e66b222c824b..58e6718c4f75 100644
--- a/drivers/net/ethernet/intel/e1000e/param.c
+++ b/drivers/net/ethernet/intel/e1000e/param.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright(c) 1999 - 2018 Intel Corporation. */
+#include
#include
#include
#include
@@ -201,6 +202,80 @@ static const struct e1000e_me_supported me_supported[] = {
{0}
};
+static const struct dmi_system_id s0ix_supported_systems[] = {
+ {
+ /* Dell Latitude 5310 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "099F"),
+ },
+ },
+ {
+ /* Dell Latitude 5410 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "09A0"),
+ },
+ },
+ {
+ /* Dell Latitude 5410 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "09C9"),
+ },
+ },
+ {
+ /* Dell Latitude 5510 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "09A1"),
+ },
+ },
+ {
+ /* Dell Precision 3550 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "09A2"),
+ },
+ },
+ {
+ /* Dell Latitude 5411 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "09C0"),
+ },
+ },
+ {
+ /* Dell Latitude 5511 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "09C1"),
+ },
+ },
+ {
+ /* Dell Precision 3551 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "09C2"),
+ },
+ },
+ {
+ /* Dell Precision 7550 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "09C3"),
+ },
+ },
+ {
+ /* Dell Precision 7750 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_SKU, "09C4"),
+ },
+ },
+ { }
+};
+
static bool e1000e_check_me(u16 device_id)
{
struct e1000e_me_supported *id;
@@ -599,8 +674,11 @@ void e1000e_check_options(struct e1000_adapter *adapter)
}
if (enabled == S0IX_HEURISTICS) {
+ /* check for allowlist of systems */
+ if (dmi_check_system(s0ix_supported_systems))
+ enabled = S0IX_FORCE_ON;
/* default to off for ME configurations */
- if (e1000e_check_me(hw->adapter->pdev->device))
+ else if (e1000e_check_me(hw->adapter->pdev->device))
enabled = S0IX_FORCE_OFF;
}
--
2.25.1
Re: [linux-sunxi] [PATCH v5 03/20] ASoC: sun4i-i2s: Change get_sr() and get_wss() to be more explicit
On Mon, Sep 28, 2020 at 3:29 AM Clément Péron wrote:
>
> We are actually using a complex formula to just return a bunch of
> simple values. Also this formula is wrong for sun4i when calling
> get_wss() the function return 4 instead of 3.
>
> Replace this with a simpler switch case.
>
> Also drop the i2s params which is unused and return a simple int as
> returning an error code could be out of range for an s8 and there is
> no optim to return a s8 here.
>
> Signed-off-by: Clément Péron
Fixes: 619c15f7fac9 ("ASoC: sun4i-i2s: Change SR and WSS computation")
Reviewed-by: Chen-Yu Tsai
[PATCH v6 3/6] genirq/PM: Introduce IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag
An interrupt that is disabled/masked but set for wakeup still needs to
be able to wake up the system from sleep states like "suspend to RAM".
This change introduces IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag. If irqchip
have this flag set then irq PM will enable/unmask irqs that are marked
for wakeup but are in disabled state.
On resume such irqs will be restored back to disabled state.
Suggested-by: Thomas Gleixner
Signed-off-by: Maulik Shah
---
include/linux/irq.h | 49 ++---
kernel/irq/debugfs.c | 3 +++
kernel/irq/pm.c | 34 ++
3 files changed, 63 insertions(+), 23 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 63b9d96..ccd39e2 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -217,6 +217,8 @@ struct irq_data {
* from actual interrupt context.
* IRQD_AFFINITY_ON_ACTIVATE - Affinity is set on activation. Don't call
* irq_chip::irq_set_affinity() when deactivated.
+ * IRQD_IRQ_ENABLED_ON_SUSPEND - Interrupt is enabled on suspend by irq pm if
+ * irqchip have flag
IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND set.
*/
enum {
IRQD_TRIGGER_MASK = 0xf,
@@ -242,6 +244,7 @@ enum {
IRQD_MSI_NOMASK_QUIRK = (1 << 27),
IRQD_HANDLE_ENFORCE_IRQCTX = (1 << 28),
IRQD_AFFINITY_ON_ACTIVATE = (1 << 29),
+ IRQD_IRQ_ENABLED_ON_SUSPEND = (1 << 30),
};
#define __irqd_to_state(d) ACCESS_PRIVATE((d)->common, state_use_accessors)
@@ -321,6 +324,11 @@ static inline bool irqd_is_handle_enforce_irqctx(struct
irq_data *d)
return __irqd_to_state(d) & IRQD_HANDLE_ENFORCE_IRQCTX;
}
+static inline bool irqd_is_enabled_on_suspend(struct irq_data *d)
+{
+ return __irqd_to_state(d) & IRQD_IRQ_ENABLED_ON_SUSPEND;
+}
+
static inline bool irqd_is_wakeup_set(struct irq_data *d)
{
return __irqd_to_state(d) & IRQD_WAKEUP_STATE;
@@ -547,27 +555,30 @@ struct irq_chip {
/*
* irq_chip specific flags
*
- * IRQCHIP_SET_TYPE_MASKED:Mask before calling chip.irq_set_type()
- * IRQCHIP_EOI_IF_HANDLED: Only issue irq_eoi() when irq was handled
- * IRQCHIP_MASK_ON_SUSPEND:Mask non wake irqs in the suspend path
- * IRQCHIP_ONOFFLINE_ENABLED: Only call irq_on/off_line callbacks
- * when irq enabled
- * IRQCHIP_SKIP_SET_WAKE: Skip chip.irq_set_wake(), for this irq chip
- * IRQCHIP_ONESHOT_SAFE: One shot does not require mask/unmask
- * IRQCHIP_EOI_THREADED: Chip requires eoi() on unmask in threaded mode
- * IRQCHIP_SUPPORTS_LEVEL_MSI Chip can provide two doorbells for Level MSIs
- * IRQCHIP_SUPPORTS_NMI: Chip can deliver NMIs, only for root irqchips
+ * IRQCHIP_SET_TYPE_MASKED: Mask before calling chip.irq_set_type()
+ * IRQCHIP_EOI_IF_HANDLED:Only issue irq_eoi() when irq was handled
+ * IRQCHIP_MASK_ON_SUSPEND: Mask non wake irqs in the suspend path
+ * IRQCHIP_ONOFFLINE_ENABLED: Only call irq_on/off_line callbacks
+ *when irq enabled
+ * IRQCHIP_SKIP_SET_WAKE: Skip chip.irq_set_wake(), for this irq
chip
+ * IRQCHIP_ONESHOT_SAFE: One shot does not require mask/unmask
+ * IRQCHIP_EOI_THREADED: Chip requires eoi() on unmask in
threaded mode
+ * IRQCHIP_SUPPORTS_LEVEL_MSI:Chip can provide two doorbells for Level
MSIs
+ * IRQCHIP_SUPPORTS_NMI: Chip can deliver NMIs, only for root
irqchips
+ * IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND: Invokes __enable_irq()/__disable_irq()
for wake irqs
+ *in the suspend path if they are in
disabled state
*/
enum {
- IRQCHIP_SET_TYPE_MASKED = (1 << 0),
- IRQCHIP_EOI_IF_HANDLED = (1 << 1),
- IRQCHIP_MASK_ON_SUSPEND = (1 << 2),
- IRQCHIP_ONOFFLINE_ENABLED = (1 << 3),
- IRQCHIP_SKIP_SET_WAKE = (1 << 4),
- IRQCHIP_ONESHOT_SAFE= (1 << 5),
- IRQCHIP_EOI_THREADED= (1 << 6),
- IRQCHIP_SUPPORTS_LEVEL_MSI = (1 << 7),
- IRQCHIP_SUPPORTS_NMI= (1 << 8),
+ IRQCHIP_SET_TYPE_MASKED = (1 << 0),
+ IRQCHIP_EOI_IF_HANDLED = (1 << 1),
+ IRQCHIP_MASK_ON_SUSPEND = (1 << 2),
+ IRQCHIP_ONOFFLINE_ENABLED = (1 << 3),
+ IRQCHIP_SKIP_SET_WAKE = (1 << 4),
+ IRQCHIP_ONESHOT_SAFE= (1 << 5),
+ IRQCHIP_EOI_THREADED= (1 << 6),
+ IRQCHIP_SUPPORTS_LEVEL_MSI = (1 << 7),
+ IRQCHIP_SUPPORTS_NMI= (1 << 8),
+ IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND= (1 << 9),
};
#include
diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c
index
[PATCH v6 5/6] irqchip: qcom-pdc: Set IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag
Set IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag to enable/unmask the
wakeirqs during suspend entry.
Acked-by: Linus Walleij
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
Signed-off-by: Maulik Shah
---
drivers/irqchip/qcom-pdc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index 6ae9e1f..acc0620 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -205,7 +205,8 @@ static struct irq_chip qcom_pdc_gic_chip = {
.irq_set_type = qcom_pdc_gic_set_type,
.flags = IRQCHIP_MASK_ON_SUSPEND |
IRQCHIP_SET_TYPE_MASKED |
- IRQCHIP_SKIP_SET_WAKE,
+ IRQCHIP_SKIP_SET_WAKE |
+ IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND,
.irq_set_vcpu_affinity = irq_chip_set_vcpu_affinity_parent,
.irq_set_affinity = irq_chip_set_affinity_parent,
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v6 1/6] pinctrl: qcom: Set IRQCHIP_SET_TYPE_MASKED and IRQCHIP_MASK_ON_SUSPEND flags
Both IRQCHIP_SET_TYPE_MASKED and IRQCHIP_MASK_ON_SUSPEND flags are already
set for msmgpio's parent PDC irqchip but GPIO interrupts do not get masked
during suspend or during setting irq type since genirq checks irqchip flag
of msmgpio irqchip which forwards these calls to its parent PDC irqchip.
Add irqchip specific flags for msmgpio irqchip to mask non wakeirqs during
suspend and mask before setting irq type. Masking before changing type make
sures any spurious interrupt is not detected during this operation.
Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
Acked-by: Bjorn Andersson
Acked-by: Linus Walleij
Reviewed-by: Douglas Anderson
Signed-off-by: Maulik Shah
---
drivers/pinctrl/qcom/pinctrl-msm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index a2567e7..1c23f5c 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -1243,6 +1243,8 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
pctrl->irq_chip.irq_release_resources = msm_gpio_irq_relres;
pctrl->irq_chip.irq_set_affinity = msm_gpio_irq_set_affinity;
pctrl->irq_chip.irq_set_vcpu_affinity = msm_gpio_irq_set_vcpu_affinity;
+ pctrl->irq_chip.flags = IRQCHIP_MASK_ON_SUSPEND |
+ IRQCHIP_SET_TYPE_MASKED;
np = of_parse_phandle(pctrl->dev->of_node, "wakeup-parent", 0);
if (np) {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v6 2/6] pinctrl: qcom: Use return value from irq_set_wake() call
msmgpio irqchip was not using return value of irq_set_irq_wake() callback
since previously GIC-v3 irqchip neither had IRQCHIP_SKIP_SET_WAKE flag nor
it implemented .irq_set_wake callback. This lead to irq_set_irq_wake()
return error -ENXIO.
However from 'commit 4110b5cbb014 ("irqchip/gic-v3: Allow interrupt to be
configured as wake-up sources")' GIC irqchip has IRQCHIP_SKIP_SET_WAKE
flag.
Use return value from irq_set_irq_wake() and irq_chip_set_wake_parent()
instead of always returning success.
Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
Acked-by: Bjorn Andersson
Acked-by: Linus Walleij
Reviewed-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Signed-off-by: Maulik Shah
---
drivers/pinctrl/qcom/pinctrl-msm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 1c23f5c..1df2322 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -1077,12 +1077,10 @@ static int msm_gpio_irq_set_wake(struct irq_data *d,
unsigned int on)
* when TLMM is powered on. To allow that, enable the GPIO
* summary line to be wakeup capable at GIC.
*/
- if (d->parent_data)
- irq_chip_set_wake_parent(d, on);
-
- irq_set_irq_wake(pctrl->irq, on);
+ if (d->parent_data && test_bit(d->hwirq, pctrl->skip_wake_irqs))
+ return irq_chip_set_wake_parent(d, on);
- return 0;
+ return irq_set_irq_wake(pctrl->irq, on);
}
static int msm_gpio_irq_reqres(struct irq_data *d)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v6 6/6] irqchip: qcom-pdc: Reset PDC interrupts during init
Kexec can directly boot into a new kernel without going to complete
reboot. This can leave the previous kernel's configuration for PDC
interrupts as is.
Clear previous kernel's configuration during init by setting interrupts
in enable bank to zero. The IRQs specified in qcom,pdc-ranges property
are the only ones that can be used by the new kernel so clear only those
IRQs. The remaining ones may be in use by a different kernel and should
not be set by new kernel.
Acked-by: Linus Walleij
Suggested-by: Stephen Boyd
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
Signed-off-by: Maulik Shah
---
drivers/irqchip/qcom-pdc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index acc0620..bd39e9d 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -341,7 +341,8 @@ static const struct irq_domain_ops qcom_pdc_gpio_ops = {
static int pdc_setup_pin_mapping(struct device_node *np)
{
- int ret, n;
+ int ret, n, i;
+ u32 irq_index, reg_index, val;
n = of_property_count_elems_of_size(np, "qcom,pdc-ranges", sizeof(u32));
if (n <= 0 || n % 3)
@@ -370,6 +371,14 @@ static int pdc_setup_pin_mapping(struct device_node *np)
_region[n].cnt);
if (ret)
return ret;
+
+ for (i = 0; i < pdc_region[n].cnt; i++) {
+ reg_index = (i + pdc_region[n].pin_base) >> 5;
+ irq_index = (i + pdc_region[n].pin_base) & 0x1f;
+ val = pdc_reg_read(IRQ_ENABLE_BANK, reg_index);
+ val &= ~BIT(irq_index);
+ pdc_reg_write(IRQ_ENABLE_BANK, reg_index, val);
+ }
}
return 0;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v6 0/6] irqchip: qcom: pdc: Introduce irq_set_wake call
Changes in v6: - Update commit message more descriptive in v5 patch 1 - Symmetrically enable/disable wakeirqs during suspend/resume in v5 patch 3 - Include Acked-by and Reviewed-by tags from v5 series Changes in v5: - Update commit subject in v4 patch 1 - Add more details to commit message in v4 patch 2 - Add change to enable wake irqs during suspend using new flag in irqchip - Use this in PDC and qcom pinctrl driver to enable wakeirqs on suspend - Make for loop more readable and add more details in commit in v4 patch 7 Changes in v4: - Drop "Remove irq_disable callback from msmgpio irqchip" patch from v3 - Introduce irq_suspend_one() and irq_resume_one() callbacks - Use the new callbacks to unmask wake interrupts during suspend - Reset only pdc interrupts that are mapped in DTSI Changes in v3: - Drop gpiolib change (v2 patch 1) since its already in linux-next - Add Acked-by Linus Walleij for v2 patch 2 and v2 patch 3. - Address Stephen's comment to on v2 patch 3 - Address Stephen's comment to change variable to static on v2 patch 4. - Add a new change to use return value from .irq_set_wake callback - Add a new change to reset PDC irq enable bank during init time Changes in v2: - Fix compiler error on gpiolib patch This series adds support to lazy disable pdc interrupt. Some drivers using gpio interrupts want to configure gpio for wakeup using enable_irq_wake() but during suspend entry disables irq and expects system to resume when interrupt occurs. In the driver resume call interrupt is re-enabled and removes wakeup capability using disable_irq_wake() one such example is cros ec driver. With [1] in documentation saying "An irq can be disabled with disable_irq() and still wake the system as long as the irq has wake enabled". The PDC IRQs are currently "unlazy disabled" (disable here means that it will be masked in PDC & GIC HW GICD_ISENABLER, the moment driver invokes disable_irq()) such IRQs can not wakeup from low power modes like suspend to RAM since the driver chosen to disable this. During suspend entry, no one re-enable/unmask in HW, even if its marked for wakeup. One solutions thought to address this problem was...During suspend entry at last point, irq chip driver re-enable/unmask IRQs in HW that are marked for wakeup. This was attemped in [2]. This series adds alternate solution to [2] by "lazy disable" IRQs in HW. The genirq takes care of lazy disable in case if irqchip did not implement irq_disable callback. Below is high level steps on how this works out.. a. During driver's disable_irq() call, IRQ will be marked disabled in SW b. IRQ will still be enabled(read unmasked in HW) c. The device then enters low power mode like suspend to RAM d. The HW detects unmasked IRQs and wakesup the CPU e. During resume after local_irq_enable() CPU goes to handle the wake IRQ f. Generic handler comes to know that IRQ is disabled in SW g. Generic handler marks IRQ as pending and now invokes mask callback h. IRQ gets disabled/masked in HW now i. When driver invokes enable_irq() the SW pending IRQ leads IRQ's handler j. enable_irq() will again enable/unmask in HW [1] https://www.spinics.net/lists/kernel/msg3398294.html [2] https://patchwork.kernel.org/patch/11466021/ Maulik Shah (6): pinctrl: qcom: Set IRQCHIP_SET_TYPE_MASKED and IRQCHIP_MASK_ON_SUSPEND flags pinctrl: qcom: Use return value from irq_set_wake() call genirq/PM: Introduce IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag pinctrl: qcom: Set IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag irqchip: qcom-pdc: Set IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag irqchip: qcom-pdc: Reset PDC interrupts during init drivers/irqchip/qcom-pdc.c | 14 +-- drivers/pinctrl/qcom/pinctrl-msm.c | 11 + include/linux/irq.h| 49 +++--- kernel/irq/debugfs.c | 3 +++ kernel/irq/pm.c| 34 ++ 5 files changed, 81 insertions(+), 30 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v6 4/6] pinctrl: qcom: Set IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag
Set IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag to enable/unmask the
wakeirqs during suspend entry.
Acked-by: Linus Walleij
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
Signed-off-by: Maulik Shah
---
drivers/pinctrl/qcom/pinctrl-msm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 1df2322..c4bcda9 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -1242,7 +1242,8 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
pctrl->irq_chip.irq_set_affinity = msm_gpio_irq_set_affinity;
pctrl->irq_chip.irq_set_vcpu_affinity = msm_gpio_irq_set_vcpu_affinity;
pctrl->irq_chip.flags = IRQCHIP_MASK_ON_SUSPEND |
- IRQCHIP_SET_TYPE_MASKED;
+ IRQCHIP_SET_TYPE_MASKED |
+ IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND;
np = of_parse_phandle(pctrl->dev->of_node, "wakeup-parent", 0);
if (np) {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2 21/21] net: qrtr: Start MHI channels during init
From: Loic Poulain Start MHI device channels so that transfers can be performed. The MHI stack does not auto-start channels anymore. Signed-off-by: Loic Poulain Reviewed-by: Manivannan Sadhasivam Acked-by: David S. Miller Signed-off-by: Manivannan Sadhasivam --- net/qrtr/mhi.c | 5 + 1 file changed, 5 insertions(+) diff --git a/net/qrtr/mhi.c b/net/qrtr/mhi.c index ff0c41467fc1..7100f0bac4c6 100644 --- a/net/qrtr/mhi.c +++ b/net/qrtr/mhi.c @@ -76,6 +76,11 @@ static int qcom_mhi_qrtr_probe(struct mhi_device *mhi_dev, struct qrtr_mhi_dev *qdev; int rc; + /* start channels */ + rc = mhi_prepare_for_transfer(mhi_dev); + if (rc) + return rc; + qdev = devm_kzalloc(_dev->dev, sizeof(*qdev), GFP_KERNEL); if (!qdev) return -ENOMEM; -- 2.17.1
[PATCH v2 20/21] bus: mhi: Remove auto-start option
From: Loic Poulain
There is really no point having an auto-start for channels.
This is confusing for the device drivers, some have to enable the
channels, others don't have... and waste resources (e.g. pre allocated
buffers) that may never be used.
This is really up to the MHI device(channel) driver to manage the state
of its channels.
Signed-off-by: Loic Poulain
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/init.c | 9 -
drivers/bus/mhi/core/internal.h | 1 -
include/linux/mhi.h | 2 --
3 files changed, 12 deletions(-)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 0ffdebde8265..381fdea2eb9f 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -758,7 +758,6 @@ static int parse_ch_cfg(struct mhi_controller *mhi_cntrl,
mhi_chan->offload_ch = ch_cfg->offload_channel;
mhi_chan->db_cfg.reset_req = ch_cfg->doorbell_mode_switch;
mhi_chan->pre_alloc = ch_cfg->auto_queue;
- mhi_chan->auto_start = ch_cfg->auto_start;
/*
* If MHI host allocates buffers, then the channel direction
@@ -1160,11 +1159,6 @@ static int mhi_driver_probe(struct device *dev)
goto exit_probe;
ul_chan->xfer_cb = mhi_drv->ul_xfer_cb;
- if (ul_chan->auto_start) {
- ret = mhi_prepare_channel(mhi_cntrl, ul_chan);
- if (ret)
- goto exit_probe;
- }
}
ret = -EINVAL;
@@ -1198,9 +1192,6 @@ static int mhi_driver_probe(struct device *dev)
if (ret)
goto exit_probe;
- if (dl_chan && dl_chan->auto_start)
- mhi_prepare_channel(mhi_cntrl, dl_chan);
-
mhi_device_put(mhi_dev);
return ret;
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 7989269ddd96..33c23203c531 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -563,7 +563,6 @@ struct mhi_chan {
bool configured;
bool offload_ch;
bool pre_alloc;
- bool auto_start;
bool wake_capable;
};
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index d4841e5a5f45..6522a4adc794 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -214,7 +214,6 @@ enum mhi_db_brst_mode {
* @offload_channel: The client manages the channel completely
* @doorbell_mode_switch: Channel switches to doorbell mode on M0 transition
* @auto_queue: Framework will automatically queue buffers for DL traffic
- * @auto_start: Automatically start (open) this channel
* @wake-capable: Channel capable of waking up the system
*/
struct mhi_channel_config {
@@ -232,7 +231,6 @@ struct mhi_channel_config {
bool offload_channel;
bool doorbell_mode_switch;
bool auto_queue;
- bool auto_start;
bool wake_capable;
};
--
2.17.1
[PATCH v2 17/21] bus: mhi: Remove unused nr_irqs_req variable
From: Loic Poulain
nr_irqs_req is unused in MHI stack.
Signed-off-by: Loic Poulain
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/init.c | 3 ---
include/linux/mhi.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 103d51f35e28..0ffdebde8265 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -680,9 +680,6 @@ static int parse_ev_cfg(struct mhi_controller *mhi_cntrl,
mhi_event++;
}
- /* We need IRQ for each event ring + additional one for BHI */
- mhi_cntrl->nr_irqs_req = mhi_cntrl->total_ev_rings + 1;
-
return 0;
error_ev_cfg:
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index fb45a0ff9aa3..d4841e5a5f45 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -312,7 +312,6 @@ struct mhi_controller_config {
* @total_ev_rings: Total # of event rings allocated
* @hw_ev_rings: Number of hardware event rings
* @sw_ev_rings: Number of software event rings
- * @nr_irqs_req: Number of IRQs required to operate (optional)
* @nr_irqs: Number of IRQ allocated by bus master (required)
* @family_number: MHI controller family number
* @device_number: MHI controller device number
@@ -393,7 +392,6 @@ struct mhi_controller {
u32 total_ev_rings;
u32 hw_ev_rings;
u32 sw_ev_rings;
- u32 nr_irqs_req;
u32 nr_irqs;
u32 family_number;
u32 device_number;
--
2.17.1
[PATCH v2 18/21] bus: mhi: core: Fix the building of MHI module
The Kbuild rule to build MHI should use the append operator. This fixes
the below warning reported by Kbuild test bot.
WARNING: modpost: missing MODULE_LICENSE() in
drivers/bus/mhi/core/main.o
WARNING: modpost: missing MODULE_LICENSE() in drivers/bus/mhi/core/pm.o
WARNING: modpost: missing MODULE_LICENSE() in
drivers/bus/mhi/core/boot.o
Fixes: 0cbf260820fa ("bus: mhi: core: Add support for registering MHI
controllers")
Reported-by: kernel test robot
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/mhi/core/Makefile b/drivers/bus/mhi/core/Makefile
index 12c57ab3724c..c3feb4130aa3 100644
--- a/drivers/bus/mhi/core/Makefile
+++ b/drivers/bus/mhi/core/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_MHI_BUS) := mhi.o
+obj-$(CONFIG_MHI_BUS) += mhi.o
mhi-y := init.o main.o pm.o boot.o
mhi-$(CONFIG_MHI_BUS_DEBUG) += debugfs.o
--
2.17.1
[PATCH v2 19/21] bus: mhi: debugfs: Print channel context read-pointer
From: Loic Poulain This value was missing in the channel debugfs output. Signed-off-by: Loic Poulain Reviewed-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam --- drivers/bus/mhi/core/debugfs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/bus/mhi/core/debugfs.c b/drivers/bus/mhi/core/debugfs.c index f50d73054db4..3a48801e01f4 100644 --- a/drivers/bus/mhi/core/debugfs.c +++ b/drivers/bus/mhi/core/debugfs.c @@ -115,8 +115,9 @@ static int mhi_debugfs_channels_show(struct seq_file *m, void *d) seq_printf(m, " type: 0x%x event ring: %u", chan_ctxt->chtype, chan_ctxt->erindex); - seq_printf(m, " base: 0x%llx len: 0x%llx wp: 0x%llx", - chan_ctxt->rbase, chan_ctxt->rlen, chan_ctxt->wp); + seq_printf(m, " base: 0x%llx len: 0x%llx rp: 0x%llx wp: 0x%llx", + chan_ctxt->rbase, chan_ctxt->rlen, chan_ctxt->rp, + chan_ctxt->wp); seq_printf(m, " local rp: 0x%pK local wp: 0x%pK db: 0x%pad\n", ring->rp, ring->wp, -- 2.17.1
[PATCH v2 11/21] bus: mhi: core: Add const qualifier to MHI config information
From: Hemant Kumar
MHI channel, event and controller config data needs to be
treated read only information. Add const qualifier to make
sure config information passed by MHI controller is not
modified by MHI core driver.
Suggested-by: Kalle Valo
Signed-off-by: Hemant Kumar
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/init.c | 12 ++--
include/linux/mhi.h | 6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index f69a2f3d039d..d23293876be8 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -562,10 +562,10 @@ int mhi_init_chan_ctxt(struct mhi_controller *mhi_cntrl,
}
static int parse_ev_cfg(struct mhi_controller *mhi_cntrl,
- struct mhi_controller_config *config)
+ const struct mhi_controller_config *config)
{
struct mhi_event *mhi_event;
- struct mhi_event_config *event_cfg;
+ const struct mhi_event_config *event_cfg;
struct device *dev = _cntrl->mhi_dev->dev;
int i, num;
@@ -648,9 +648,9 @@ static int parse_ev_cfg(struct mhi_controller *mhi_cntrl,
}
static int parse_ch_cfg(struct mhi_controller *mhi_cntrl,
- struct mhi_controller_config *config)
+ const struct mhi_controller_config *config)
{
- struct mhi_channel_config *ch_cfg;
+ const struct mhi_channel_config *ch_cfg;
struct device *dev = _cntrl->mhi_dev->dev;
int i;
u32 chan;
@@ -766,7 +766,7 @@ static int parse_ch_cfg(struct mhi_controller *mhi_cntrl,
}
static int parse_config(struct mhi_controller *mhi_cntrl,
- struct mhi_controller_config *config)
+ const struct mhi_controller_config *config)
{
int ret;
@@ -803,7 +803,7 @@ static int parse_config(struct mhi_controller *mhi_cntrl,
}
int mhi_register_controller(struct mhi_controller *mhi_cntrl,
- struct mhi_controller_config *config)
+ const struct mhi_controller_config *config)
{
struct mhi_event *mhi_event;
struct mhi_chan *mhi_chan;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index 6b987e8cc438..b2c0214bfbd6 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -280,9 +280,9 @@ struct mhi_controller_config {
u32 timeout_ms;
u32 buf_len;
u32 num_channels;
- struct mhi_channel_config *ch_cfg;
+ const struct mhi_channel_config *ch_cfg;
u32 num_events;
- struct mhi_event_config *event_cfg;
+ const struct mhi_event_config *event_cfg;
bool use_bounce_buf;
bool m2_no_db;
};
@@ -545,7 +545,7 @@ void mhi_free_controller(struct mhi_controller *mhi_cntrl);
* @config: Configuration to use for the controller
*/
int mhi_register_controller(struct mhi_controller *mhi_cntrl,
- struct mhi_controller_config *config);
+ const struct mhi_controller_config *config);
/**
* mhi_unregister_controller - Unregister MHI controller
--
2.17.1
[PATCH v2 15/21] bus: mhi: core: Introduce sysfs entries for MHI
From: Bhaumik Bhatt
Introduce sysfs entries to enable userspace clients the ability to read
the serial number and the OEM PK Hash values obtained from BHI. OEMs
need to read these device-specific hardware information values through
userspace for factory testing purposes and cannot be exposed via degbufs
as it may remain disabled for performance reasons. Also, update the
documentation for ABI to include these entries.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Manivannan Sadhasivam
[mani: used dev_groups to manage sysfs attributes]
Signed-off-by: Manivannan Sadhasivam
---
Documentation/ABI/stable/sysfs-bus-mhi | 21 +++
MAINTAINERS| 1 +
drivers/bus/mhi/core/init.c| 37 ++
3 files changed, 59 insertions(+)
create mode 100644 Documentation/ABI/stable/sysfs-bus-mhi
diff --git a/Documentation/ABI/stable/sysfs-bus-mhi
b/Documentation/ABI/stable/sysfs-bus-mhi
new file mode 100644
index ..ecfe7662f8d0
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-bus-mhi
@@ -0,0 +1,21 @@
+What: /sys/bus/mhi/devices/.../serialnumber
+Date: Sept 2020
+KernelVersion: 5.10
+Contact: Bhaumik Bhatt
+Description: The file holds the serial number of the client device obtained
+ using a BHI (Boot Host Interface) register read after at least
+ one attempt to power up the device has been done. If read
+ without having the device power on at least once, the file will
+ read all 0's.
+Users: Any userspace application or clients interested in device info.
+
+What: /sys/bus/mhi/devices/.../oem_pk_hash
+Date: Sept 2020
+KernelVersion: 5.10
+Contact: Bhaumik Bhatt
+Description: The file holds the OEM PK Hash value of the endpoint device
+ obtained using a BHI (Boot Host Interface) register read after
+ at least one attempt to power up the device has been done. If
+ read without having the device power on at least once, the file
+ will read all 0's.
+Users: Any userspace application or clients interested in device info.
diff --git a/MAINTAINERS b/MAINTAINERS
index deaafb617361..11e7be9b9163 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11323,6 +11323,7 @@ M: Hemant Kumar
L: linux-arm-...@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi.git
+F: Documentation/ABI/stable/sysfs-bus-mhi
F: Documentation/mhi/
F: drivers/bus/mhi/
F: include/linux/mhi.h
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 61e5885a331a..a33665b7ee54 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -76,6 +76,42 @@ const char *to_mhi_pm_state_str(enum mhi_pm_state state)
return mhi_pm_state_str[index];
}
+static ssize_t serial_number_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct mhi_device *mhi_dev = to_mhi_device(dev);
+ struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
+
+ return snprintf(buf, PAGE_SIZE, "Serial Number: %u\n",
+ mhi_cntrl->serial_number);
+}
+static DEVICE_ATTR_RO(serial_number);
+
+static ssize_t oem_pk_hash_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct mhi_device *mhi_dev = to_mhi_device(dev);
+ struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
+ int i, cnt = 0;
+
+ for (i = 0; i < ARRAY_SIZE(mhi_cntrl->oem_pk_hash); i++)
+ cnt += snprintf(buf + cnt, PAGE_SIZE - cnt,
+ "OEMPKHASH[%d]: 0x%x\n", i,
+ mhi_cntrl->oem_pk_hash[i]);
+
+ return cnt;
+}
+static DEVICE_ATTR_RO(oem_pk_hash);
+
+static struct attribute *mhi_dev_attrs[] = {
+ _attr_serial_number.attr,
+ _attr_oem_pk_hash.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(mhi_dev);
+
/* MHI protocol requires the transfer ring to be aligned with ring length */
static int mhi_alloc_aligned_ring(struct mhi_controller *mhi_cntrl,
struct mhi_ring *ring,
@@ -1301,6 +1337,7 @@ struct bus_type mhi_bus_type = {
.dev_name = "mhi",
.match = mhi_match,
.uevent = mhi_uevent,
+ .dev_groups = mhi_dev_groups,
};
static int __init mhi_init(void)
--
2.17.1
[PATCH v2 16/21] bus: mhi: core: Allow shared IRQ for event rings
From: Loic Poulain
There is no requirement for using a dedicated IRQ per event ring.
Some systems does not support multiple MSI vectors (e.g. intel
without CONFIG_IRQ_REMAP), In that case the MHI controller can
configure all the event rings to use the same interrupt (as fallback).
Allow this by removing the nr_irqs = ev_ring test and add extra check
in the irq_setup function.
Signed-off-by: Loic Poulain
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/init.c | 7 +++
drivers/bus/mhi/core/pm.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index a33665b7ee54..103d51f35e28 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -162,6 +162,13 @@ int mhi_init_irq_setup(struct mhi_controller *mhi_cntrl)
if (mhi_event->offload_ev)
continue;
+ if (mhi_event->irq >= mhi_cntrl->nr_irqs) {
+ dev_err(dev, "irq %d not available for event ring\n",
+ mhi_event->irq);
+ ret = -EINVAL;
+ goto error_request;
+ }
+
ret = request_irq(mhi_cntrl->irq[mhi_event->irq],
mhi_irq_handler,
IRQF_SHARED | IRQF_NO_SUSPEND,
diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
index ce4d969818b4..3de7b1639ec6 100644
--- a/drivers/bus/mhi/core/pm.c
+++ b/drivers/bus/mhi/core/pm.c
@@ -918,7 +918,7 @@ int mhi_async_power_up(struct mhi_controller *mhi_cntrl)
dev_info(dev, "Requested to power ON\n");
- if (mhi_cntrl->nr_irqs < mhi_cntrl->total_ev_rings)
+ if (mhi_cntrl->nr_irqs < 1)
return -EINVAL;
/* Supply default wake routines if not provided by controller driver */
--
2.17.1
[PATCH v2 07/21] bus: mhi: core: Introduce helper function to check device state
From: Bhaumik Bhatt
Introduce a helper function to determine whether the device is in a
powered ON state and resides in one of the active MHI states. This will
allow for some use cases where access can be pre-determined.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/internal.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 1bbd6e99d38d..5a81a428c4aa 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -598,6 +598,11 @@ int mhi_pm_m3_transition(struct mhi_controller *mhi_cntrl);
int __mhi_device_get_sync(struct mhi_controller *mhi_cntrl);
int mhi_send_cmd(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan,
enum mhi_cmd_type cmd);
+static inline bool mhi_is_active(struct mhi_controller *mhi_cntrl)
+{
+ return (mhi_cntrl->dev_state >= MHI_STATE_M0 &&
+ mhi_cntrl->dev_state <= MHI_STATE_M3_FAST);
+}
static inline void mhi_trigger_resume(struct mhi_controller *mhi_cntrl)
{
--
2.17.1
[PATCH v2 14/21] bus: mhi: core: Introduce debugfs entries for MHI
From: Bhaumik Bhatt
Introduce debugfs entries to show state, register, channel, device,
and event rings information. Allow the host to dump registers,
issue device wake, and change the MHI timeout to help in debug.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/Kconfig | 8 +
drivers/bus/mhi/core/Makefile | 1 +
drivers/bus/mhi/core/debugfs.c | 410
drivers/bus/mhi/core/init.c | 7 +
drivers/bus/mhi/core/internal.h | 24 ++
include/linux/mhi.h | 2 +
6 files changed, 452 insertions(+)
create mode 100644 drivers/bus/mhi/core/debugfs.c
diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index 6677cccd61f3..e841c1097fb4 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -12,3 +12,11 @@ config MHI_BUS
communication protocol used by the host processors to control
and communicate with modem devices over a high speed peripheral
bus or shared memory.
+
+config MHI_BUS_DEBUG
+ bool "Debugfs support for the MHI bus"
+ depends on MHI_BUS && DEBUG_FS
+ help
+ Enable debugfs support for use with the MHI transport. Allows
+ reading and/or modifying some values within the MHI controller
+ for debug and test purposes.
diff --git a/drivers/bus/mhi/core/Makefile b/drivers/bus/mhi/core/Makefile
index 66e2700c9032..12c57ab3724c 100644
--- a/drivers/bus/mhi/core/Makefile
+++ b/drivers/bus/mhi/core/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_MHI_BUS) := mhi.o
mhi-y := init.o main.o pm.o boot.o
+mhi-$(CONFIG_MHI_BUS_DEBUG) += debugfs.o
diff --git a/drivers/bus/mhi/core/debugfs.c b/drivers/bus/mhi/core/debugfs.c
new file mode 100644
index ..f50d73054db4
--- /dev/null
+++ b/drivers/bus/mhi/core/debugfs.c
@@ -0,0 +1,410 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "internal.h"
+
+static int mhi_debugfs_states_show(struct seq_file *m, void *d)
+{
+ struct mhi_controller *mhi_cntrl = m->private;
+
+ /* states */
+ seq_printf(m, "PM state: %s Device: %s MHI state: %s EE: %s wake: %s\n",
+ to_mhi_pm_state_str(mhi_cntrl->pm_state),
+ mhi_is_active(mhi_cntrl) ? "Active" : "Inactive",
+ TO_MHI_STATE_STR(mhi_cntrl->dev_state),
+ TO_MHI_EXEC_STR(mhi_cntrl->ee),
+ mhi_cntrl->wake_set ? "true" : "false");
+
+ /* counters */
+ seq_printf(m, "M0: %u M2: %u M3: %u", mhi_cntrl->M0, mhi_cntrl->M2,
+ mhi_cntrl->M3);
+
+ seq_printf(m, " device wake: %u pending packets: %u\n",
+ atomic_read(_cntrl->dev_wake),
+ atomic_read(_cntrl->pending_pkts));
+
+ return 0;
+}
+
+static int mhi_debugfs_events_show(struct seq_file *m, void *d)
+{
+ struct mhi_controller *mhi_cntrl = m->private;
+ struct mhi_event *mhi_event;
+ struct mhi_event_ctxt *er_ctxt;
+ int i;
+
+ if (!mhi_is_active(mhi_cntrl)) {
+ seq_puts(m, "Device not ready\n");
+ return -ENODEV;
+ }
+
+ er_ctxt = mhi_cntrl->mhi_ctxt->er_ctxt;
+ mhi_event = mhi_cntrl->mhi_event;
+ for (i = 0; i < mhi_cntrl->total_ev_rings;
+ i++, er_ctxt++, mhi_event++) {
+ struct mhi_ring *ring = _event->ring;
+
+ if (mhi_event->offload_ev) {
+ seq_printf(m, "Index: %d is an offload event ring\n",
+ i);
+ continue;
+ }
+
+ seq_printf(m, "Index: %d intmod count: %lu time: %lu",
+ i, (er_ctxt->intmod & EV_CTX_INTMODC_MASK) >>
+ EV_CTX_INTMODC_SHIFT,
+ (er_ctxt->intmod & EV_CTX_INTMODT_MASK) >>
+ EV_CTX_INTMODT_SHIFT);
+
+ seq_printf(m, " base: 0x%0llx len: 0x%llx", er_ctxt->rbase,
+ er_ctxt->rlen);
+
+ seq_printf(m, " rp: 0x%llx wp: 0x%llx", er_ctxt->rp,
+ er_ctxt->wp);
+
+ seq_printf(m, " local rp: 0x%pK db: 0x%pad\n", ring->rp,
+ _event->db_cfg.db_val);
+ }
+
+ return 0;
+}
+
+static int mhi_debugfs_channels_show(struct seq_file *m, void *d)
+{
+ struct mhi_controller *mhi_cntrl = m->private;
+ struct mhi_chan *mhi_chan;
+ struct mhi_chan_ctxt *chan_ctxt;
+ int i;
+
+ if (!mhi_is_active(mhi_cntrl)) {
+ seq_puts(m, "Device not ready\n");
+ return -ENODEV;
+ }
+
+ mhi_chan = mhi_cntrl->mhi_chan;
+ chan_ctxt = mhi_cntrl->mhi_ctxt->chan_ctxt;
+ for (i = 0; i <
[PATCH v2 12/21] bus: mhi: Remove include of rwlock_types.h
From: Clark Williams
rwlock.h should not be included directly. Instead linux/splinlock.h
should be included. Including it directly will break the RT build.
Also there is no point in including _types.h headers directly. There is
no benefit in including the type without the accessor.
Fixes: 0cbf260820fa7 ("bus: mhi: core: Add support for registering MHI
controllers")
Signed-off-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
include/linux/mhi.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index b2c0214bfbd6..008b8f6fa9ff 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -9,10 +9,9 @@
#include
#include
#include
-#include
#include
#include
-#include
+#include
#include
#include
--
2.17.1
[PATCH v2 13/21] bus: mhi: Fix entries based on Kconfig coding style
From: Bhaumik Bhatt Kconfig coding style mandates use of tabs for the configuration definition and an additional two spaces for the help text. Make the required changes to the MHI Kconfig adhering to those guidelines. Signed-off-by: Bhaumik Bhatt Reviewed-by: Manivannan Sadhasivam Acked-by: Randy Dunlap Signed-off-by: Manivannan Sadhasivam --- drivers/bus/mhi/Kconfig | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig index a8bd9bd7db7c..6677cccd61f3 100644 --- a/drivers/bus/mhi/Kconfig +++ b/drivers/bus/mhi/Kconfig @@ -6,9 +6,9 @@ # config MHI_BUS - tristate "Modem Host Interface (MHI) bus" - help -Bus driver for MHI protocol. Modem Host Interface (MHI) is a -communication protocol used by the host processors to control -and communicate with modem devices over a high speed peripheral -bus or shared memory. + tristate "Modem Host Interface (MHI) bus" + help + Bus driver for MHI protocol. Modem Host Interface (MHI) is a + communication protocol used by the host processors to control + and communicate with modem devices over a high speed peripheral + bus or shared memory. -- 2.17.1
[PATCH v2 09/21] bus: mhi: core: Read and save device hardware information from BHI
From: Bhaumik Bhatt
Device hardware specific information such as serial number and the OEM
PK hash can be read using BHI and saved on host to identify the
endpoint.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/boot.c | 17 -
include/linux/mhi.h | 6 ++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
index 0b38014d040e..24422f5c3d80 100644
--- a/drivers/bus/mhi/core/boot.c
+++ b/drivers/bus/mhi/core/boot.c
@@ -392,13 +392,28 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
void *buf;
dma_addr_t dma_addr;
size_t size;
- int ret;
+ int i, ret;
if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
dev_err(dev, "Device MHI is not in valid state\n");
return;
}
+ /* save hardware info from BHI */
+ ret = mhi_read_reg(mhi_cntrl, mhi_cntrl->bhi, BHI_SERIALNU,
+ _cntrl->serial_number);
+ if (ret)
+ dev_err(dev, "Could not capture serial number via BHI\n");
+
+ for (i = 0; i < ARRAY_SIZE(mhi_cntrl->oem_pk_hash); i++) {
+ ret = mhi_read_reg(mhi_cntrl, mhi_cntrl->bhi, BHI_OEMPKHASH(i),
+ _cntrl->oem_pk_hash[i]);
+ if (ret) {
+ dev_err(dev, "Could not capture OEM PK HASH via BHI\n");
+ break;
+ }
+ }
+
/* If device is in pass through, do reset to ready state transition */
if (mhi_cntrl->ee == MHI_EE_PTHRU)
goto fw_load_ee_pthru;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index c56b4447a4e9..0c97f4bc5fae 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -16,6 +16,8 @@
#include
#include
+#define MHI_MAX_OEM_PK_HASH_SEGMENTS 16
+
struct mhi_chan;
struct mhi_event;
struct mhi_ctxt;
@@ -316,6 +318,8 @@ struct mhi_controller_config {
* @device_number: MHI controller device number
* @major_version: MHI controller major revision number
* @minor_version: MHI controller minor revision number
+ * @serial_number: MHI controller serial number obtained from BHI
+ * @oem_pk_hash: MHI controller OEM PK Hash obtained from BHI
* @mhi_event: MHI event ring configurations table
* @mhi_cmd: MHI command ring configurations table
* @mhi_ctxt: MHI device context, shared memory between host and device
@@ -394,6 +398,8 @@ struct mhi_controller {
u32 device_number;
u32 major_version;
u32 minor_version;
+ u32 serial_number;
+ u32 oem_pk_hash[MHI_MAX_OEM_PK_HASH_SEGMENTS];
struct mhi_event *mhi_event;
struct mhi_cmd *mhi_cmd;
--
2.17.1
[PATCH v2 08/21] bus: mhi: core: Introduce counters to track MHI device state transitions
From: Bhaumik Bhatt
Use counters to track MHI device state transitions such as those
to M0, M2, or M3 states. This can help in better debug, allowing
the user to see the number of transitions to a certain MHI state
when queried using debugfs entries or via other mechanisms.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/pm.c | 4
include/linux/mhi.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
index 27bb471c8f4e..ce4d969818b4 100644
--- a/drivers/bus/mhi/core/pm.c
+++ b/drivers/bus/mhi/core/pm.c
@@ -256,6 +256,7 @@ int mhi_pm_m0_transition(struct mhi_controller *mhi_cntrl)
dev_err(dev, "Unable to transition to M0 state\n");
return -EIO;
}
+ mhi_cntrl->M0++;
/* Wake up the device */
read_lock_bh(_cntrl->pm_lock);
@@ -326,6 +327,8 @@ void mhi_pm_m1_transition(struct mhi_controller *mhi_cntrl)
mhi_cntrl->dev_state = MHI_STATE_M2;
write_unlock_irq(_cntrl->pm_lock);
+
+ mhi_cntrl->M2++;
wake_up_all(_cntrl->state_event);
/* If there are any pending resources, exit M2 immediately */
@@ -362,6 +365,7 @@ int mhi_pm_m3_transition(struct mhi_controller *mhi_cntrl)
return -EIO;
}
+ mhi_cntrl->M3++;
wake_up_all(_cntrl->state_event);
return 0;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index bb337d163dda..c56b4447a4e9 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -328,6 +328,7 @@ struct mhi_controller_config {
* @dev_state: MHI device state
* @dev_wake: Device wakeup count
* @pending_pkts: Pending packets for the controller
+ * @M0, M2, M3: Counters to track number of device MHI state changes
* @transition_list: List of MHI state transitions
* @transition_lock: Lock for protecting MHI state transition list
* @wlock: Lock for protecting device wakeup
@@ -407,6 +408,7 @@ struct mhi_controller {
enum mhi_state dev_state;
atomic_t dev_wake;
atomic_t pending_pkts;
+ u32 M0, M2, M3;
struct list_head transition_list;
spinlock_t transition_lock;
spinlock_t wlock;
--
2.17.1
[PATCH v2 05/21] bus: mhi: core: Trigger host resume if suspended during mhi_device_get()
From: Bhaumik Bhatt It is possible that the host may be suspending or suspended and may not allow an outgoing device wake assert immediately if a client has requested for it. Ensure that the host wakes up and allows for it so the client does not have to wait for an external trigger or an outgoing packet to be queued for the host resume to occur. Signed-off-by: Bhaumik Bhatt Reviewed-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam --- drivers/bus/mhi/core/pm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c index b227d415e937..27bb471c8f4e 100644 --- a/drivers/bus/mhi/core/pm.c +++ b/drivers/bus/mhi/core/pm.c @@ -1112,6 +1112,9 @@ void mhi_device_get(struct mhi_device *mhi_dev) mhi_dev->dev_wake++; read_lock_bh(_cntrl->pm_lock); + if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state)) + mhi_trigger_resume(mhi_cntrl); + mhi_cntrl->wake_get(mhi_cntrl, true); read_unlock_bh(_cntrl->pm_lock); } -- 2.17.1
[PATCH v2 10/21] bus: mhi: core: Introduce APIs to allocate and free the MHI controller
From: Bhaumik Bhatt
Client devices should use the APIs provided to allocate and free
the MHI controller structure. This will help ensure that the
structure is zero-initialized and there are no false positives
with respect to reading any values such as the serial number or
the OEM PK hash.
Suggested-by: Manivannan Sadhasivam
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/init.c | 16
include/linux/mhi.h | 12
2 files changed, 28 insertions(+)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index e2011ec46b92..f69a2f3d039d 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -954,6 +954,22 @@ void mhi_unregister_controller(struct mhi_controller
*mhi_cntrl)
}
EXPORT_SYMBOL_GPL(mhi_unregister_controller);
+struct mhi_controller *mhi_alloc_controller(void)
+{
+ struct mhi_controller *mhi_cntrl;
+
+ mhi_cntrl = kzalloc(sizeof(*mhi_cntrl), GFP_KERNEL);
+
+ return mhi_cntrl;
+}
+EXPORT_SYMBOL_GPL(mhi_alloc_controller);
+
+void mhi_free_controller(struct mhi_controller *mhi_cntrl)
+{
+ kfree(mhi_cntrl);
+}
+EXPORT_SYMBOL_GPL(mhi_free_controller);
+
int mhi_prepare_for_power_up(struct mhi_controller *mhi_cntrl)
{
struct device *dev = _cntrl->mhi_dev->dev;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index 0c97f4bc5fae..6b987e8cc438 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -527,6 +527,18 @@ struct mhi_driver {
#define to_mhi_driver(drv) container_of(drv, struct mhi_driver, driver)
#define to_mhi_device(dev) container_of(dev, struct mhi_device, dev)
+/**
+ * mhi_alloc_controller - Allocate the MHI Controller structure
+ * Allocate the mhi_controller structure using zero initialized memory
+ */
+struct mhi_controller *mhi_alloc_controller(void);
+
+/**
+ * mhi_free_controller - Free the MHI Controller structure
+ * Free the mhi_controller structure which was previously allocated
+ */
+void mhi_free_controller(struct mhi_controller *mhi_cntrl);
+
/**
* mhi_register_controller - Register MHI controller
* @mhi_cntrl: MHI controller to register
--
2.17.1
[PATCH v2 06/21] bus: mhi: core: Use generic name field for an MHI device
From: Bhaumik Bhatt
An MHI device is not necessarily associated with only channels as we can
have one associated with the controller itself. Hence, the chan_name
field within the mhi_device structure should instead be replaced with a
generic name to accurately reflect any type of MHI device.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/init.c | 5 +++--
drivers/bus/mhi/core/main.c | 6 +++---
include/linux/mhi.h | 8
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index e43a190a7a36..e2011ec46b92 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -904,6 +904,7 @@ int mhi_register_controller(struct mhi_controller
*mhi_cntrl,
mhi_dev->dev_type = MHI_DEVICE_CONTROLLER;
mhi_dev->mhi_cntrl = mhi_cntrl;
dev_set_name(_dev->dev, "%s", dev_name(mhi_cntrl->cntrl_dev));
+ mhi_dev->name = dev_name(mhi_cntrl->cntrl_dev);
/* Init wakeup source */
device_init_wakeup(_dev->dev, true);
@@ -1249,7 +1250,7 @@ static int mhi_uevent(struct device *dev, struct
kobj_uevent_env *env)
struct mhi_device *mhi_dev = to_mhi_device(dev);
return add_uevent_var(env, "MODALIAS=" MHI_DEVICE_MODALIAS_FMT,
- mhi_dev->chan_name);
+ mhi_dev->name);
}
static int mhi_match(struct device *dev, struct device_driver *drv)
@@ -1266,7 +1267,7 @@ static int mhi_match(struct device *dev, struct
device_driver *drv)
return 0;
for (id = mhi_drv->id_table; id->chan[0]; id++)
- if (!strcmp(mhi_dev->chan_name, id->chan)) {
+ if (!strcmp(mhi_dev->name, id->chan)) {
mhi_dev->id = id;
return 1;
}
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 79be18ec2ebf..2cff5ddff225 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -249,7 +249,7 @@ int mhi_destroy_device(struct device *dev, void *data)
put_device(_dev->dl_chan->mhi_dev->dev);
dev_dbg(_cntrl->mhi_dev->dev, "destroy device for chan:%s\n",
-mhi_dev->chan_name);
+mhi_dev->name);
/* Notify the client and remove the device from MHI bus */
device_del(dev);
@@ -327,10 +327,10 @@ void mhi_create_devices(struct mhi_controller *mhi_cntrl)
}
/* Channel name is same for both UL and DL */
- mhi_dev->chan_name = mhi_chan->name;
+ mhi_dev->name = mhi_chan->name;
dev_set_name(_dev->dev, "%s_%s",
dev_name(mhi_cntrl->cntrl_dev),
-mhi_dev->chan_name);
+mhi_dev->name);
/* Init wakeup source if available */
if (mhi_dev->dl_chan && mhi_dev->dl_chan->wake_capable)
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index 0779bc689b3e..bb337d163dda 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -438,10 +438,10 @@ struct mhi_controller {
};
/**
- * struct mhi_device - Structure representing a MHI device which binds
- * to channels
+ * struct mhi_device - Structure representing an MHI device which binds
+ * to channels or is associated with controllers
* @id: Pointer to MHI device ID struct
- * @chan_name: Name of the channel to which the device binds
+ * @name: Name of the associated MHI device
* @mhi_cntrl: Controller the device belongs to
* @ul_chan: UL channel for the device
* @dl_chan: DL channel for the device
@@ -453,7 +453,7 @@ struct mhi_controller {
*/
struct mhi_device {
const struct mhi_device_id *id;
- const char *chan_name;
+ const char *name;
struct mhi_controller *mhi_cntrl;
struct mhi_chan *ul_chan;
struct mhi_chan *dl_chan;
--
2.17.1
[PATCH v2 03/21] bus: mhi: core: Abort suspends due to outgoing pending packets
From: Bhaumik Bhatt
Add the missing check to abort suspends if a client driver has pending
outgoing packets to send to the device. This allows better utilization
of the MHI bus wherein clients on the host are not left waiting for
longer suspend or resume cycles to finish for data transfers.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/pm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
index 796098078083..661d704c8093 100644
--- a/drivers/bus/mhi/core/pm.c
+++ b/drivers/bus/mhi/core/pm.c
@@ -686,7 +686,8 @@ int mhi_pm_suspend(struct mhi_controller *mhi_cntrl)
return -EIO;
/* Return busy if there are any pending resources */
- if (atomic_read(_cntrl->dev_wake))
+ if (atomic_read(_cntrl->dev_wake) ||
+ atomic_read(_cntrl->pending_pkts))
return -EBUSY;
/* Take MHI out of M2 state */
@@ -712,7 +713,8 @@ int mhi_pm_suspend(struct mhi_controller *mhi_cntrl)
write_lock_irq(_cntrl->pm_lock);
- if (atomic_read(_cntrl->dev_wake)) {
+ if (atomic_read(_cntrl->dev_wake) ||
+ atomic_read(_cntrl->pending_pkts)) {
write_unlock_irq(_cntrl->pm_lock);
return -EBUSY;
}
--
2.17.1
[PATCH v2 02/21] bus: mhi: core: Remove double occurrence for mhi_ctrl_ev_task() declaration
From: Bhaumik Bhatt mhi_ctrl_ev_task() in the internal header file occurred twice. Remove one of the occurrences for clean-up. Signed-off-by: Bhaumik Bhatt Reviewed-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam --- drivers/bus/mhi/core/internal.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h index b1f640b75a94..bcfa7b6558ef 100644 --- a/drivers/bus/mhi/core/internal.h +++ b/drivers/bus/mhi/core/internal.h @@ -592,7 +592,6 @@ void mhi_pm_st_worker(struct work_struct *work); void mhi_pm_sys_err_handler(struct mhi_controller *mhi_cntrl); void mhi_fw_load_worker(struct work_struct *work); int mhi_ready_state_transition(struct mhi_controller *mhi_cntrl); -void mhi_ctrl_ev_task(unsigned long data); int mhi_pm_m0_transition(struct mhi_controller *mhi_cntrl); void mhi_pm_m1_transition(struct mhi_controller *mhi_cntrl); int mhi_pm_m3_transition(struct mhi_controller *mhi_cntrl); -- 2.17.1
[PATCH v2 04/21] bus: mhi: core: Use helper API to trigger a non-blocking host resume
From: Bhaumik Bhatt
Autonomous low power mode support requires the MHI host to resume from
multiple places and post a wakeup source to exit system suspend. This
needs to be done in a non-blocking manner. Introduce a helper API to
trigger the host resume for data transfers and other non-blocking use
cases while supporting implementation of autonomous low power modes.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/internal.h | 7 +++
drivers/bus/mhi/core/main.c | 21 +++--
drivers/bus/mhi/core/pm.c | 13 -
3 files changed, 18 insertions(+), 23 deletions(-)
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index bcfa7b6558ef..1bbd6e99d38d 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -599,6 +599,13 @@ int __mhi_device_get_sync(struct mhi_controller
*mhi_cntrl);
int mhi_send_cmd(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan,
enum mhi_cmd_type cmd);
+static inline void mhi_trigger_resume(struct mhi_controller *mhi_cntrl)
+{
+ pm_wakeup_event(_cntrl->mhi_dev->dev, 0);
+ mhi_cntrl->runtime_get(mhi_cntrl);
+ mhi_cntrl->runtime_put(mhi_cntrl);
+}
+
/* Register access methods */
void mhi_db_brstmode(struct mhi_controller *mhi_cntrl, struct db_cfg *db_cfg,
void __iomem *db_addr, dma_addr_t db_val);
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 1f622ce6be8b..79be18ec2ebf 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -909,8 +909,7 @@ void mhi_ctrl_ev_task(unsigned long data)
* process it since we are probably in a suspended state,
* so trigger a resume.
*/
- mhi_cntrl->runtime_get(mhi_cntrl);
- mhi_cntrl->runtime_put(mhi_cntrl);
+ mhi_trigger_resume(mhi_cntrl);
return;
}
@@ -971,10 +970,8 @@ int mhi_queue_skb(struct mhi_device *mhi_dev, enum
dma_data_direction dir,
}
/* we're in M3 or transitioning to M3 */
- if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state)) {
- mhi_cntrl->runtime_get(mhi_cntrl);
- mhi_cntrl->runtime_put(mhi_cntrl);
- }
+ if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state))
+ mhi_trigger_resume(mhi_cntrl);
/* Toggle wake to exit out of M2 */
mhi_cntrl->wake_toggle(mhi_cntrl);
@@ -1032,10 +1029,8 @@ int mhi_queue_dma(struct mhi_device *mhi_dev, enum
dma_data_direction dir,
}
/* we're in M3 or transitioning to M3 */
- if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state)) {
- mhi_cntrl->runtime_get(mhi_cntrl);
- mhi_cntrl->runtime_put(mhi_cntrl);
- }
+ if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state))
+ mhi_trigger_resume(mhi_cntrl);
/* Toggle wake to exit out of M2 */
mhi_cntrl->wake_toggle(mhi_cntrl);
@@ -1147,10 +1142,8 @@ int mhi_queue_buf(struct mhi_device *mhi_dev, enum
dma_data_direction dir,
read_lock_irqsave(_cntrl->pm_lock, flags);
/* we're in M3 or transitioning to M3 */
- if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state)) {
- mhi_cntrl->runtime_get(mhi_cntrl);
- mhi_cntrl->runtime_put(mhi_cntrl);
- }
+ if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state))
+ mhi_trigger_resume(mhi_cntrl);
/* Toggle wake to exit out of M2 */
mhi_cntrl->wake_toggle(mhi_cntrl);
diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
index 661d704c8093..b227d415e937 100644
--- a/drivers/bus/mhi/core/pm.c
+++ b/drivers/bus/mhi/core/pm.c
@@ -824,11 +824,8 @@ int __mhi_device_get_sync(struct mhi_controller *mhi_cntrl)
/* Wake up the device */
read_lock_bh(_cntrl->pm_lock);
mhi_cntrl->wake_get(mhi_cntrl, true);
- if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state)) {
- pm_wakeup_event(_cntrl->mhi_dev->dev, 0);
- mhi_cntrl->runtime_get(mhi_cntrl);
- mhi_cntrl->runtime_put(mhi_cntrl);
- }
+ if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state))
+ mhi_trigger_resume(mhi_cntrl);
read_unlock_bh(_cntrl->pm_lock);
ret = wait_event_timeout(mhi_cntrl->state_event,
@@ -1139,10 +1136,8 @@ void mhi_device_put(struct mhi_device *mhi_dev)
mhi_dev->dev_wake--;
read_lock_bh(_cntrl->pm_lock);
- if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state)) {
- mhi_cntrl->runtime_get(mhi_cntrl);
- mhi_cntrl->runtime_put(mhi_cntrl);
- }
+ if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state))
+ mhi_trigger_resume(mhi_cntrl);
mhi_cntrl->wake_put(mhi_cntrl, false);
read_unlock_bh(_cntrl->pm_lock);
--
2.17.1
[PATCH v2 01/21] bus: mhi: fix doubled words and struct image_info kernel-doc
From: Randy Dunlap
Drop doubled word "table" in kernel-doc.
Fix syntax for the kernel-doc notation for struct image_info.
Note that the bhi_vec field is private and not part of the kernel-doc.
Drop doubled word "device" in a comment.
Signed-off-by: Randy Dunlap
Cc: Manivannan Sadhasivam
Cc: Hemant Kumar
Cc: linux-arm-...@vger.kernel.org
Reviewed-by: Manivannan Sadhasivam
[mani: Added bus: prefix to the commit subject]
Signed-off-by: Manivannan Sadhasivam
---
include/linux/mhi.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index c4a940d98912..0779bc689b3e 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -85,13 +85,15 @@ enum mhi_ch_type {
};
/**
- * struct image_info - Firmware and RDDM table table
- * @mhi_buf - Buffer for firmware and RDDM table
- * @entries - # of entries in table
+ * struct image_info - Firmware and RDDM table
+ * @mhi_buf: Buffer for firmware and RDDM table
+ * @entries: # of entries in table
*/
struct image_info {
struct mhi_buf *mhi_buf;
+ /* private: from internal.h */
struct bhi_vec_entry *bhi_vec;
+ /* public: */
u32 entries;
};
@@ -593,7 +595,7 @@ int mhi_async_power_up(struct mhi_controller *mhi_cntrl);
/**
* mhi_sync_power_up - Start MHI power up sequence and wait till the device
- * device enters valid EE state
+ * enters valid EE state
* @mhi_cntrl: MHI controller
*/
int mhi_sync_power_up(struct mhi_controller *mhi_cntrl);
--
2.17.1
[PATCH v2 00/21] MHI changes for v5.10
Hi Greg, Here is the MHI series for v5.10 cycle. Most of the patches are cleanups in the MHI stack. Notable changes are below: * Saving the client device hardware information obtained through the BHI protocol. This information will be exposed through sysfs to make use in the userland applications. * Introduce sysfs entries to read the serial number and OEM PK hash values of the client device obtained from BHI protocol. Relevant API documentation is also added. * Introduce debugfs entries to show MHI states, events, channels, register state etc... to aid debug. * Remove the channel name from MHI device name as the device is not specific to channels. Used generic names instead! * Fix the warning reported by Kbuild bot by using append (+=) Kbuild rule to the mhi/core Makefile. * Introduce APIs to allocate and free MHI controllers. This is done to make sure that the allocated structs are initialized to NULL before passing to the MHI core. * Remove the requirement to have a dedicated IRQ for each event ring. The MHI controllers can now use a single IRQ for all event rings. * Remove the auto-start option for MHI channels. This is done to avoid receiving spurious uplink from MHI client device when the client driver is not up. The corresponding qrtr change is also included with Dave's ACK. Please consider merging! Thanks, Mani Changes in v2: * Clubbed both series (take one and two) onto a single one * Used dev_groups to manage sysfs attributes * Merged the debugfs fix patch with the debugfs patch * Dropped MAX_MTU patch for now Bhaumik Bhatt (12): bus: mhi: core: Remove double occurrence for mhi_ctrl_ev_task() declaration bus: mhi: core: Abort suspends due to outgoing pending packets bus: mhi: core: Use helper API to trigger a non-blocking host resume bus: mhi: core: Trigger host resume if suspended during mhi_device_get() bus: mhi: core: Use generic name field for an MHI device bus: mhi: core: Introduce helper function to check device state bus: mhi: core: Introduce counters to track MHI device state transitions bus: mhi: core: Read and save device hardware information from BHI bus: mhi: core: Introduce APIs to allocate and free the MHI controller bus: mhi: Fix entries based on Kconfig coding style bus: mhi: core: Introduce debugfs entries for MHI bus: mhi: core: Introduce sysfs entries for MHI Clark Williams (1): bus: mhi: Remove include of rwlock_types.h Hemant Kumar (1): bus: mhi: core: Add const qualifier to MHI config information Loic Poulain (5): bus: mhi: core: Allow shared IRQ for event rings bus: mhi: Remove unused nr_irqs_req variable bus: mhi: debugfs: Print channel context read-pointer bus: mhi: Remove auto-start option net: qrtr: Start MHI channels during init Manivannan Sadhasivam (1): bus: mhi: core: Fix the building of MHI module Randy Dunlap (1): bus: mhi: fix doubled words and struct image_info kernel-doc Documentation/ABI/stable/sysfs-bus-mhi | 21 ++ MAINTAINERS| 1 + drivers/bus/mhi/Kconfig| 20 +- drivers/bus/mhi/core/Makefile | 3 +- drivers/bus/mhi/core/boot.c| 17 +- drivers/bus/mhi/core/debugfs.c | 411 + drivers/bus/mhi/core/init.c| 96 -- drivers/bus/mhi/core/internal.h| 38 ++- drivers/bus/mhi/core/main.c| 27 +- drivers/bus/mhi/core/pm.c | 28 +- include/linux/mhi.h| 53 +++- net/qrtr/mhi.c | 5 + 12 files changed, 644 insertions(+), 76 deletions(-) create mode 100644 Documentation/ABI/stable/sysfs-bus-mhi create mode 100644 drivers/bus/mhi/core/debugfs.c -- 2.17.1
Re: [PATCH v4 17/17] virt: acrn: Introduce an interface for Service VM to control vCPU
Hi Greg,
On Sun 27.Sep'20 at 12:44:14 +0200, Greg Kroah-Hartman wrote:
On Tue, Sep 22, 2020 at 07:43:11PM +0800, shuo.a@intel.com wrote:
From: Shuo Liu
ACRN supports partition mode to achieve real-time requirements. In
partition mode, a CPU core can be dedicated to a vCPU of User VM. The
local APIC of the dedicated CPU core can be passthrough to the User VM.
The Service VM controls the assignment of the CPU cores.
Introduce an interface for the Service VM to remove the control of CPU
core from hypervisor perspective so that the CPU core can be a dedicated
CPU core of User VM.
Signed-off-by: Shuo Liu
Reviewed-by: Zhi Wang
Reviewed-by: Reinette Chatre
Cc: Zhi Wang
Cc: Zhenyu Wang
Cc: Yu Wang
Cc: Reinette Chatre
Cc: Greg Kroah-Hartman
---
drivers/virt/acrn/hsm.c | 50 +++
drivers/virt/acrn/hypercall.h | 14 ++
2 files changed, 64 insertions(+)
diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index aaf4e76d27b4..ef5f77a38d1f 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -9,6 +9,7 @@
* Yakui Zhao
*/
+#include
#include
#include
#include
@@ -354,6 +355,47 @@ struct miscdevice acrn_dev = {
.fops = _fops,
};
+static ssize_t remove_cpu_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ u64 cpu, lapicid;
+ int ret;
+
+ if (kstrtoull(buf, 0, ) < 0)
+ return -EINVAL;
+
+ if (cpu >= num_possible_cpus() || cpu == 0 || !cpu_is_hotpluggable(cpu))
+ return -EINVAL;
+
+ if (cpu_online(cpu))
+ remove_cpu(cpu);
+
+ lapicid = cpu_data(cpu).apicid;
+ dev_dbg(dev, "Try to remove cpu %lld with lapicid %lld\n", cpu,
lapicid);
+ ret = hcall_sos_remove_cpu(lapicid);
+ if (ret < 0) {
+ dev_err(dev, "Failed to remove cpu %lld!\n", cpu);
+ goto fail_remove;
+ }
+
+ return count;
+
+fail_remove:
+ add_cpu(cpu);
+ return ret;
+}
+static DEVICE_ATTR_WO(remove_cpu);
+
+static struct attribute *acrn_attrs[] = {
+ _attr_remove_cpu.attr,
+ NULL
+};
+
+static struct attribute_group acrn_attr_group = {
+ .attrs = acrn_attrs,
+};
You create a sysfs attribute without any Documentation/ABI/ update as
well? That's not good.
Sorry, i will add it in the ABI/testing.
And why are you trying to emulate CPU hotplug here and not using the
existing CPU hotplug mechanism?
The interface introduced here includes:
1) The Service VM virtual CPU hotplug
2) hypercall to the hypervisor to remove one virtual CPU from the
Service VM
The 1) just do the CPU hotplug with kernel API remove_cpu(), and can be
resume back (by CPU online interface) if only 1) is done.
If 2) is done, then the physical CPU will be removed from the Service
VM's CPU pool. The ACRN hypervisor supports passthrough a physical CPU
to a VM. The precondition is that the physical CPU cannot be occupied by
any other VM. This interface intends to do that.
+
static int __init hsm_init(void)
{
int ret;
@@ -370,13 +412,21 @@ static int __init hsm_init(void)
return ret;
}
+ ret = sysfs_create_group(_dev.this_device->kobj, _attr_group);
+ if (ret) {
+ dev_warn(acrn_dev.this_device, "sysfs create failed\n");
+ misc_deregister(_dev);
+ return ret;
+ }
You just raced with userspace and lost. If you want to add attribute
files to a device, use the default attribute group list, and it will be
managed properly for you by the driver core.
Huge hint, if a driver every has to touch a kobject, or call sysfs_*,
then it is probably doing something wrong.
Do you mean use .groups of struct miscdevice directly ?
If yes, let me follow drivers/char/hw_random/s390-trng.c to do this.
BTW, few driver use the .groups directly. :)
Thanks
shuo
[PATCH 5/5 V5] PCI/ERR: don't mix io state not changed and no driver together
When we see 'can't recover (no error_detected callback)' on console,
Maybe the reason is io state is not changed by calling
pci_dev_set_io_state(), that is confused. fix it.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Chagnes:
V2: no change.
V3: no change.
V4: no change.
V5: no change.
drivers/pci/pcie/err.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index e35c4480c86b..d85f27c90c26 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -55,8 +55,10 @@ static int report_error_detected(struct pci_dev *dev,
if (!pci_dev_get(dev))
return 0;
device_lock(>dev);
- if (!pci_dev_set_io_state(dev, state) ||
- !dev->driver ||
+ if (!pci_dev_set_io_state(dev, state)) {
+ pci_dbg(dev, "Device might already being in error handling
...\n");
+ vote = PCI_ERS_RESULT_NONE;
+ } else if (!dev->driver ||
!dev->driver->err_handler ||
!dev->driver->err_handler->error_detected) {
/*
--
2.18.4
[PATCH 2/5 V5] PCI: pciehp: check and wait port status out of DPC before handling DLLSC and PDC
When root port has DPC capability and it is enabled, then triggered by
errors, DPC DLLSC and PDC interrupts will be sent to DPC driver, pciehp
driver at the same time.
That will cause following result:
1. Link and device are recovered by hardware DPC and software DPC driver,
device
isn't removed, but the pciehp might treat it as device was hot removed.
2. Race condition happens bettween pciehp_unconfigure_device() called by
pciehp_ist() in pciehp driver and pci_do_recovery() called by
dpc_handler in DPC driver. no luck, there is no lock to protect
pci_stop_and_remove_bus_device()
against pci_walk_bus(), they hold different samphore and mutex,
pci_stop_and_remove_bus_device holds pci_rescan_remove_lock, and
pci_walk_bus() holds pci_bus_sem.
This race condition is not purely code analysis, it could be triggered by
following command series:
# setpci -s 64:02.0 0x196.w=000a // 64:02.0 rootport has DPC capability
# setpci -s 65:00.0 0x04.w=0544 // 65:00.0 NVMe SSD populated in port
# mount /dev/nvme0n1p1 nvme
One shot will cause system panic and NULL pointer reference happened.
(tested on stable 5.8 & ICS(Ice Lake SP platform, see
https://en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(server))
Buffer I/O error on dev nvme0n1p1, logical block 3328, async page read
BUG: kernel NULL pointer dereference, address: 0050
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 0
Oops: [#1] SMP NOPTI
CPU: 12 PID: 513 Comm: irq/124-pcie-dp Not tainted 5.8.0 el8.x86_64+ #1
RIP: 0010:report_error_detected.cold.4+0x7d/0xe6
Code: b6 d0 e8 e8 fe 11 00 e8 16 c5 fb ff be 06 00 00 00 48 89 df e8 d3
65 ff ff b8 06 00 00 00 e9 75 fc ff ff 48 8b 43 68 45 31 c9 <48> 8b 50
50 48 83 3a 00 41 0f 94 c1 45 31 c0 48 85 d2 41 0f 94 c0
RSP: 0018:ff8e06cf8762fda8 EFLAGS: 00010246
RAX: RBX: ff4e3eaacf42a000 RCX: ff4e3eb31f223c01
RDX: ff4e3eaacf42a140 RSI: ff4e3eb31f223c00 RDI: ff4e3eaacf42a138
RBP: ff8e06cf8762fdd0 R08: 00bf R09:
R10: 00eb8ebeab53 R11: 93453258 R12: 0002
R13: ff4e3eaacf42a130 R14: ff8e06cf8762fe2c R15: ff4e3eab44733828
FS: () GS:ff4e3eab1fd0() knl
GS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0050 CR3: 000f8f80a004 CR4: 00761ee0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
PKRU: 5554
Call Trace:
? report_normal_detected+0x20/0x20
report_frozen_detected+0x16/0x20
pci_walk_bus+0x75/0x90
? dpc_irq+0x90/0x90
pcie_do_recovery+0x157/0x201
? irq_finalize_oneshot.part.47+0xe0/0xe0
dpc_handler+0x29/0x40
irq_thread_fn+0x24/0x60
irq_thread+0xea/0x170
? irq_forced_thread_fn+0x80/0x80
? irq_thread_check_affinity+0xf0/0xf0
kthread+0x124/0x140
? kthread_park+0x90/0x90
ret_from_fork+0x1f/0x30
Modules linked in: nft_fib_inet.
CR2: 0050
With this patch, the handling flow of DPC containment and hotplug is
partly ordered and serialized, let hardware DPC do the controller reset
etc recovery action first, then DPC driver handling the call-back from
device drivers, clear the DPC status, at the end, pciehp handle the DLLSC
and PDC etc.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Changes:
V2: revise doc according to Andy's suggestion.
V3: no change.
V4: no change.
V5: no change.
drivers/pci/hotplug/pciehp_hpc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 53433b37e181..6f271160f18d 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -710,8 +710,10 @@ static irqreturn_t pciehp_ist(int irq, void *dev_id)
down_read(>reset_lock);
if (events & DISABLE_SLOT)
pciehp_handle_disable_request(ctrl);
- else if (events & (PCI_EXP_SLTSTA_PDC | PCI_EXP_SLTSTA_DLLSC))
+ else if (events & (PCI_EXP_SLTSTA_PDC | PCI_EXP_SLTSTA_DLLSC)) {
+ pci_wait_port_outdpc(pdev);
pciehp_handle_presence_or_link_change(ctrl, events);
+ }
up_read(>reset_lock);
ret = IRQ_HANDLED;
--
2.18.4
[PATCH 1/5 V5] PCI: define a function to check and wait till port finish DPC handling
Once root port DPC capability is enabled and triggered, at the beginning
of DPC is triggered, the DPC status bits are set by hardware and then
sends DPC/DLLSC/PDC interrupts to OS DPC and pciehp drivers, it will
take the port and software DPC interrupt handler 10ms to 50ms (test data
on ICS(Ice Lake SP platform, see
https://en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(server)
& stable 5.9-rc6) to complete the DPC containment procedure
till the DPC status is cleared at the end of the DPC interrupt handler.
We use this function to check if the root port is in DPC handling status
and wait till the hardware and software completed the procedure.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
changes:
V2：align ICS code name to public doc.
V3: no change.
V4: response to Christoph's (Christoph Hellwig )
tip, move pci_wait_port_outdpc() to DPC driver and its declaration
to pci.h.
V5: fix building issue reported by l...@intel.com with some config.
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/dpc.c | 27 +++
2 files changed, 29 insertions(+)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index fa12f7cbc1a0..8fdb0d823d5a 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -455,10 +455,12 @@ void pci_restore_dpc_state(struct pci_dev *dev);
void pci_dpc_init(struct pci_dev *pdev);
void dpc_process_error(struct pci_dev *pdev);
pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
+bool pci_wait_port_outdpc(struct pci_dev *pdev);
#else
static inline void pci_save_dpc_state(struct pci_dev *dev) {}
static inline void pci_restore_dpc_state(struct pci_dev *dev) {}
static inline void pci_dpc_init(struct pci_dev *pdev) {}
+static inline bool pci_wait_port_outdpc(struct pci_dev *pdev) { return false; }
#endif
#ifdef CONFIG_PCI_ATS
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index daa9a4153776..2e0e091ce923 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -71,6 +71,33 @@ void pci_restore_dpc_state(struct pci_dev *dev)
pci_write_config_word(dev, dev->dpc_cap + PCI_EXP_DPC_CTL, *cap);
}
+bool pci_wait_port_outdpc(struct pci_dev *pdev)
+{
+ u16 cap = pdev->dpc_cap, status;
+ u16 loop = 0;
+
+ if (!cap) {
+ pci_WARN_ONCE(pdev, !cap, "No DPC capability initiated\n");
+ return false;
+ }
+ pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, );
+ pci_dbg(pdev, "DPC status %x, cap %x\n", status, cap);
+
+ while (status & PCI_EXP_DPC_STATUS_TRIGGER && loop < 100) {
+ msleep(10);
+ loop++;
+ pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, );
+ }
+
+ if (!(status & PCI_EXP_DPC_STATUS_TRIGGER)) {
+ pci_dbg(pdev, "Out of DPC %x, cost %d ms\n", status, loop*10);
+ return true;
+ }
+
+ pci_dbg(pdev, "Timeout to wait port out of DPC status\n");
+ return false;
+}
+
static int dpc_wait_rp_inactive(struct pci_dev *pdev)
{
unsigned long timeout = jiffies + HZ;
--
2.18.4
[PATCH 0/5 V5] Fix DPC hotplug race and enhance error handling
This simple patch set fixed some serious security issues found when DPC
error injection and NVMe SSD hotplug brute force test were doing -- race
condition between DPC handler and pciehp, AER interrupt handlers, caused
system hang and system with DPC feature couldn't recover to normal
working state as expected (NVMe instance lost, mount operation hang,
race PCIe access caused uncorrectable errors reported alternatively etc).
With this patch set applied, stable 5.9-rc6 on ICS (Ice Lake SP platform,
see
https://en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(server))
could pass the PCIe Gen4 NVMe SSD brute force hotplug test with any time
interval between hot-remove and plug-in operation tens of times without
any errors occur and system works normal.
With this patch set applied, system with DPC feature could recover from
NON-FATAL and FATAL errors injection test and works as expected.
System works smoothly when errors happen while hotplug is doing, no
uncorrectable errors found.
Brute DPC error injection script:
for i in {0..100}
do
setpci -s 64:02.0 0x196.w=000a
setpci -s 65:00.0 0x04.w=0544
mount /dev/nvme0n1p1 /root/nvme
sleep 1
done
Other details see every commits description part.
This patch set could be applied to stable 5.9-rc6 directly.
Help to review and test.
V2: changed according to review by Andy Shevchenko.
V3: changed patch 4/5 to simpler coding.
V4: move function pci_wait_port_outdpc() to DPC driver and its
declaration to pci.h. (tip from Christoph Hellwig ).
V5: fix building issue reported by l...@intel.com with some config.
Thanks,
Ethan
Ethan Zhao (5):
PCI: define a function to check and wait till port finish DPC handling
PCI: pciehp: check and wait port status out of DPC before handling
DLLSC and PDC
PCI/ERR: get device before call device driver to avoid NULL pointer
reference
PCI: only return true when dev io state is really changed
PCI/ERR: don't mix io state not changed and no driver together
drivers/pci/hotplug/pciehp_hpc.c | 4 +++-
drivers/pci/pci.h| 34 +---
drivers/pci/pcie/err.c | 18 +++--
include/linux/pci.h | 31 +
4 files changed, 55 insertions(+), 32 deletions(-)
--
2.18.4
[PATCH 4/5 V4] PCI: only return true when dev io state is really changed
When uncorrectable error happens, AER driver and DPC driver interrupt
handlers likely call
pcie_do_recovery()
->pci_walk_bus()
->report_frozen_detected()
with pci_channel_io_frozen the same time.
If pci_dev_set_io_state() return true even if the original state is
pci_channel_io_frozen, that will cause AER or DPC handler re-enter
the error detecting and recovery procedure one after another.
The result is the recovery flow mixed between AER and DPC.
So simplify the pci_dev_set_io_state() function to only return true
when dev->error_state is changed.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
Reviewed-by: Alexandru Gagniuc
---
Changnes:
V2: revise description and code according to suggestion from Andy.
V3: change code to simpler.
V4: no change.
V5: no change.
drivers/pci/pci.h | 37 +
1 file changed, 5 insertions(+), 32 deletions(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index fa12f7cbc1a0..a2c1c7d5f494 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -359,39 +359,12 @@ struct pci_sriov {
static inline bool pci_dev_set_io_state(struct pci_dev *dev,
pci_channel_state_t new)
{
- bool changed = false;
-
device_lock_assert(>dev);
- switch (new) {
- case pci_channel_io_perm_failure:
- switch (dev->error_state) {
- case pci_channel_io_frozen:
- case pci_channel_io_normal:
- case pci_channel_io_perm_failure:
- changed = true;
- break;
- }
- break;
- case pci_channel_io_frozen:
- switch (dev->error_state) {
- case pci_channel_io_frozen:
- case pci_channel_io_normal:
- changed = true;
- break;
- }
- break;
- case pci_channel_io_normal:
- switch (dev->error_state) {
- case pci_channel_io_frozen:
- case pci_channel_io_normal:
- changed = true;
- break;
- }
- break;
- }
- if (changed)
- dev->error_state = new;
- return changed;
+ if (dev->error_state == new)
+ return false;
+
+ dev->error_state = new;
+ return true;
}
static inline int pci_dev_set_disconnected(struct pci_dev *dev, void *unused)
--
2.18.4
[PATCH 3/5 V55555] PCI/ERR: get device before call device driver to avoid NULL pointer reference
During DPC error injection test we found there is race condition between
pciehp and DPC driver, NULL pointer reference caused panic as following
# setpci -s 64:02.0 0x196.w=000a
// 64:02.0 is rootport has DPC capability
# setpci -s 65:00.0 0x04.w=0544
// 65:00.0 is NVMe SSD populated in above port
# mount /dev/nvme0n1p1 nvme
(tested on stable 5.8 & ICS(Ice Lake SP platform, see
https://en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(server))
Buffer I/O error on dev nvme0n1p1, logical block 468843328,
async page read
BUG: kernel NULL pointer dereference, address: 0050
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 0
Oops: [#1] SMP NOPTI
CPU: 12 PID: 513 Comm: irq/124-pcie-dp Not tainted 5.8.0-0.0.7.el8.x86_64+ #1
RIP: 0010:report_error_detected.cold.4+0x7d/0xe6
Code: b6 d0 e8 e8 fe 11 00 e8 16 c5 fb ff be 06 00 00 00 48 89 df e8 d3 65 ff
ff b8 06 00 00 00 e9 75 fc ff ff 48 8b 43 68 45 31 c9 <48> 8b 50 50 48 83 3a 00
41 0f 94 c1 45 31 c0 48 85 d2 41 0f 94 c0
RSP: 0018:ff8e06cf8762fda8 EFLAGS: 00010246
RAX: RBX: ff4e3eaacf42a000 RCX: ff4e3eb31f223c01
RDX: ff4e3eaacf42a140 RSI: ff4e3eb31f223c00 RDI: ff4e3eaacf42a138
RBP: ff8e06cf8762fdd0 R08: 00bf R09:
R10: 00eb8ebeab53 R11: 93453258 R12: 0002
R13: ff4e3eaacf42a130 R14: ff8e06cf8762fe2c R15: ff4e3eab44733828
FS: () GS:ff4e3eab1fd0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0050 CR3: 000f8f80a004 CR4: 00761ee0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
PKRU: 5554
Call Trace:
? report_normal_detected+0x20/0x20
report_frozen_detected+0x16/0x20
pci_walk_bus+0x75/0x90
? dpc_irq+0x90/0x90
pcie_do_recovery+0x157/0x201
? irq_finalize_oneshot.part.47+0xe0/0xe0
dpc_handler+0x29/0x40
irq_thread_fn+0x24/0x60
irq_thread+0xea/0x170
? irq_forced_thread_fn+0x80/0x80
? irq_thread_check_affinity+0xf0/0xf0
kthread+0x124/0x140
? kthread_park+0x90/0x90
ret_from_fork+0x1f/0x30
Modules linked in: nft_fib_inet.
CR2: 0050
Though we partly close the race condition with patch 'PCI: pciehp: check
and wait port status out of DPC before handling DLLSC and PDC', but there
is no hardware spec or software sequence to guarantee the pcie_ist() run
into pci_wait_port_outdpc() first or DPC triggered status bits being set
first when errors triggered DPC containment procedure, so device still
could be removed by function pci_stop_and_removed_bus_device() then freed
by pci_dev_put() in pciehp driver first during pcie_do_recover()/
pci_walk_bus() is called by dpc_handler() in DPC driver.
Maybe unify pci_bus_sem and pci_rescan_remove_lock to serialize the
removal and walking operation is the right way, but here we use
pci_dev_get() to increase the reference count of device before using the
device to avoid it is freed in use.
With this patch and patch 'PCI: pciehp: check and wait port status out of
DPC before handling DLLSC and PDC', stable 5.9-rc6 could pass the error
injection test and no panic happened.
Brute DPC error injection script:
for i in {0..100}
do
setpci -s 64:02.0 0x196.w=000a
setpci -s 65:00.0 0x04.w=0544
mount /dev/nvme0n1p1 /root/nvme
sleep 1
done
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Changes:
V2: revise doc according to Andy's suggestion.
V3: no change.
V4: no change.
V5: no change.
drivers/pci/pcie/err.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index c543f419d8f9..e35c4480c86b 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -52,6 +52,8 @@ static int report_error_detected(struct pci_dev *dev,
pci_ers_result_t vote;
const struct pci_error_handlers *err_handler;
+ if (!pci_dev_get(dev))
+ return 0;
device_lock(>dev);
if (!pci_dev_set_io_state(dev, state) ||
!dev->driver ||
@@ -76,6 +78,7 @@ static int report_error_detected(struct pci_dev *dev,
pci_uevent_ers(dev, vote);
*result = merge_result(*result, vote);
device_unlock(>dev);
+ pci_dev_put(dev);
return 0;
}
@@ -94,6 +97,8 @@ static int report_mmio_enabled(struct pci_dev *dev, void
*data)
pci_ers_result_t vote, *result = data;
const struct pci_error_handlers *err_handler;
+ if (!pci_dev_get(dev))
+ return 0;
device_lock(>dev);
if (!dev->driver ||
!dev->driver->err_handler ||
@@ -105,6 +110,7 @@ static int report_mmio_enabled(struct pci_dev *dev, void
*data)
*result = merge_result(*result, vote);
out:
device_unlock(>dev);
+ pci_dev_put(dev);
return 0;
}
@@
Re: [RFC 12/14] dt-bindings: vendor-prefixes: add Aristainetos
Hello Krzysztof, Am 26.09.2020 um 18:28 schrieb Krzysztof Kozlowski: Document binding for an unknown entity Aristainetos with few boards mainlined. Cc: Heiko Schocher Signed-off-by: Krzysztof Kozlowski --- I tried to Google but except the patches from Heiko Schocher, I could not find any meaningful data. Heiko, you posted this. Do you know what is it? aristainetos is the name of the board, so it is not the vendor name. I just asked the customer if we can add a valid vendor name... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH 2/2] tpm: Revert "tpm_tis_core: Turn on the TPM before probing IRQ's"
On Sun, Sep 27, 2020 at 01:06:03PM -0700, James Bottomley wrote:
> On Tue, 2019-11-26 at 08:17 -0500, Stefan Berger wrote:
> > From: Stefan Berger
> >
> > Revert the patch that was turning the TPM on before probing for IRQs.
> >
> > Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing
> > IRQ's")
> > Signed-off-by: Stefan Berger
> > Reported-by: Jerry Snitselaar
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/char/tpm/tpm_tis_core.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_tis_core.c
> > b/drivers/char/tpm/tpm_tis_core.c
> > index 5dc52c4e2292..27c6ca031e23 100644
> > --- a/drivers/char/tpm/tpm_tis_core.c
> > +++ b/drivers/char/tpm/tpm_tis_core.c
> > @@ -1059,7 +1059,6 @@ int tpm_tis_core_init(struct device *dev,
> > struct tpm_tis_data *priv, int irq,
> > goto out_err;
> > }
> >
> > - tpm_chip_start(chip);
> > if (irq) {
> > tpm_tis_probe_irq_single(chip, intmask,
> > IRQF_SHARED,
> > irq);
> > @@ -1069,7 +1068,6 @@ int tpm_tis_core_init(struct device *dev,
> > struct tpm_tis_data *priv, int irq,
> > } else {
> > tpm_tis_probe_irq(chip, intmask);
> > }
> > - tpm_chip_stop(chip);
> > }
> >
> > rc = tpm_chip_register(chip);
>
> This patch is completely bogus: it's not a full revert of what it
> claims to be. With this patch applied all my TIS TPMs are returning
> 0xff to the status reads because the locality hasn't been properly
> requested. The chip has to be started somewhere for the interrupt
> probe to work on these TPMs ... what the original patch did was
> eliminate a bunch of start/stops for a global one. However, if the
> global one isn't working we should have gone back to the bunch of
> smaller ones i.e. a full revert.
>
> The only real manifestation of the problems this patch causes is that
> interrupts never get enabled on TIS TPMs that have this issue, but they
> still work via polling.
>
> The below is what fixes this for me with the minimum possible extend of
> additional chip start/stop in the code. This should be checked against
> the previous failing laptops.
>
> James
>
> ---
>
> From: James Bottomley
> Subject: [PATCH] tpm_tis: fix interrupt probing
>
> When we send a command into the TPM core, the TPM must be started
> otherwise the register reads can be bogus. There have been several
> bug reports about doing this inside the TIS core, so fix the issue by
> adding an external version of the tpm2_get_tpm_pt() call which adds a
> tpm ops get/put to set up the TPM correctly before the command is
> sent.
>
> Fixes: aa4a63dd9816 (tpm: Revert "tpm_tis_core: Turn on the TPM before
> probing IRQ's")
> Signed-off-by: James Bottomley
> ---
> drivers/char/tpm/tpm.h | 2 ++
> drivers/char/tpm/tpm2-cmd.c | 30 ++
> drivers/char/tpm/tpm_tis_core.c | 2 +-
> 3 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 947d1db0a5cc..041b0b5bd2a5 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -223,6 +223,8 @@ int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
> int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max);
> ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id,
> u32 *value, const char *desc);
> +ssize_t tpm2_get_tpm_pt_cmd(struct tpm_chip *chip, u32 property_id,
> + u32 *value, const char *desc);
>
> ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip);
> int tpm2_auto_startup(struct tpm_chip *chip);
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index eff1f12d981a..9b84158c5a9e 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -407,6 +407,36 @@ ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32
> property_id, u32 *value,
> }
> EXPORT_SYMBOL_GPL(tpm2_get_tpm_pt);
>
> +/**
> + * tpm2_get_tpm_pt_cmd() - get value of a TPM_CAP_TPM_PROPERTIES type
> property
> + * @chip:a _chip instance
> + * @property_id: property ID.
> + * @value: output variable.
> + * @desc:passed to tpm_transmit_cmd()
> + *
> + * This calls the necessary tpm_try_get_ops()/tpm_put_ops() around
> + * tpm2_get_tpm_pt() and must be called where it is used stand alone
> + * outside the core code.
> + *
> + * Return:
> + * 0 on success,
> + * -errno or a TPM return code otherwise
> + */
> +ssize_t tpm2_get_tpm_pt_cmd(struct tpm_chip *chip, u32 property_id, u32
> *value,
> + const char *desc)
> +{
> + ssize_t rc;
> +
> + rc = tpm_try_get_ops(chip);
> + if (rc)
> + return rc;
> + rc = tpm2_get_tpm_pt(chip, property_id, value, desc);
> + tpm_put_ops(chip);
> +
> + return rc;
> +}
>
linux-next: build failure after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function 'ingenic_drm_sync_data':
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:478:4: error: implicit declaration of
function 'dma_cache_sync'; did you mean 'regcache_sync'?
[-Werror=implicit-function-declaration]
478 |dma_cache_sync(priv->dev, addr + offset,
|^~
|regcache_sync
drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function 'ingenic_drm_gem_mmap':
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:671:11: error:
'DMA_ATTR_NON_CONSISTENT' undeclared (first use in this function)
671 | attrs = DMA_ATTR_NON_CONSISTENT;
| ^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:671:11: note: each undeclared
identifier is reported only once for each function it appears in
Caused by commit
37054fc81443 ("gpu/drm: ingenic: Add option to mmap GEM buffers cached")
interacting with commits
5a8429227140 ("dma-mapping: remove dma_cache_sync")
efa70f2fdc84 ("dma-mapping: add a new dma_alloc_pages API")
from the dma-mapping tree.
Its not immediately obvious how to fix this up, so I have just marked
CONFIG_DRM_INGENIC as BROKEN until a fix up is provided.
--
Cheers,
Stephen Rothwell
pgp511Qfv8YXT.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/5] bus: mhi: core: debugfs: Use correct format specifiers for addresses
On Sun, Sep 27, 2020 at 12:23:10PM +0200, Greg KH wrote:
> On Sun, Sep 27, 2020 at 09:06:48AM +0530, Manivannan Sadhasivam wrote:
> > For exposing the addresses of read/write pointers and doorbell register,
> > let's use the correct format specifiers. This fixes the following issues
> > generated using W=1 build in ARM32 and reported by Kbuild bot:
> >
> > All warnings (new ones prefixed by >>):
> >
> > >> drivers/bus/mhi/core/debugfs.c:75:7: warning: format specifies type
> > >> 'unsigned long long' but the argument has type 'dma_addr_t' (aka
> > >> 'unsigned int') [-Wformat]
> > mhi_event->db_cfg.db_val);
> > ^~~~
> >drivers/bus/mhi/core/debugfs.c:123:7: warning: format specifies type
> > 'unsigned long long' but the argument has type 'dma_addr_t' (aka 'unsigned
> > int') [-Wformat]
> > mhi_chan->db_cfg.db_val);
> > ^~~
> >2 warnings generated.
> >
> > drivers/bus/mhi/core/debugfs.c: In function ‘mhi_debugfs_events_show’:
> > drivers/bus/mhi/core/debugfs.c:74:51: warning: cast from pointer to integer
> > of different size [-Wpointer-to-int-cast]
> >seq_printf(m, " local rp: 0x%llx db: 0x%pad\n", (u64)ring->rp,
> >^
> > drivers/bus/mhi/core/debugfs.c: In function ‘mhi_debugfs_channels_show’:
> > drivers/bus/mhi/core/debugfs.c:122:7: warning: cast from pointer to integer
> > of different size [-Wpointer-to-int-cast]
> >(u64)ring->rp, (u64)ring->wp,
> >^
> > drivers/bus/mhi/core/debugfs.c:122:22: warning: cast from pointer to
> > integer of different size [-Wpointer-to-int-cast]
> >(u64)ring->rp, (u64)ring->wp,
> > ^
> > drivers/bus/mhi/core/debugfs.c:121:62: warning: format ‘%llx’ expects
> > argument of type ‘long long unsigned int’, but argument 5 has type
> > ‘dma_addr_t {aka unsigned int}’ [-Wformat=]
> >seq_printf(m, " local rp: 0x%llx local wp: 0x%llx db: 0x%llx\n",
> >~~~^
> >%x
> > drivers/bus/mhi/core/debugfs.c:123:7:
> >mhi_chan->db_cfg.db_val);
> >
> > Reported-by: kernel test robot
> > Signed-off-by: Manivannan Sadhasivam
> > ---
> > drivers/bus/mhi/core/debugfs.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
>
> Ah, this is against your first set of patches, that's the confusion on
> my part.
>
> Please just fix them all up and resend 1 series of patches, that isn't
> broken, and I will be glad to review and take that.
>
Sure, will merge this patch with debugfs one. I submitted this patch as I got
error report from Kbuild bot and I thought you applied the series to
char-misc-testing branch.
Thanks,
Mani
> thanks,
>
> greg k-h
Re: [PATCH 5/5] bus: mhi: core: Move MHI_MAX_MTU to external header file
On Sun, Sep 27, 2020 at 12:17:34PM +0200, Greg KH wrote: > On Sun, Sep 27, 2020 at 09:06:52AM +0530, Manivannan Sadhasivam wrote: > > From: Hemant Kumar > > > > Currently this macro is defined in internal MHI header as > > a TRE length mask. Moving it to external header allows MHI > > client drivers to set this upper bound for the transmit > > buffer size. > > > > Signed-off-by: Hemant Kumar > > Reviewed-by: Manivannan Sadhasivam > > Signed-off-by: Manivannan Sadhasivam > > --- > > drivers/bus/mhi/core/internal.h | 1 - > > include/linux/mhi.h | 3 +++ > > 2 files changed, 3 insertions(+), 1 deletion(-) > > If no one is using this change, then please don't make it until someone > needs it. > > So submit it when you have a user please. > Okay, will drop it. Thanks, Mani > thanks, > > greg k-h
Re: [PATCH 18/18] bus: mhi: core: Fix the building of MHI module
On Sun, Sep 27, 2020 at 12:22:33PM +0200, Greg KH wrote: > On Mon, Sep 21, 2020 at 09:38:15PM +0530, Manivannan Sadhasivam wrote: > > The Kbuild rule to build MHI should use the append operator. This fixes > > the below warning reported by Kbuild test bot. > > > > WARNING: modpost: missing MODULE_LICENSE() in > > drivers/bus/mhi/core/main.o > > WARNING: modpost: missing MODULE_LICENSE() in drivers/bus/mhi/core/pm.o > > WARNING: modpost: missing MODULE_LICENSE() in > > drivers/bus/mhi/core/boot.o > > > > Reported-by: kernel test robot > > Signed-off-by: Manivannan Sadhasivam > > What commit caused this problem? Can you add a Fixes: line for it? > Sure, will add the fixes tag! Thanks, Mani > thanks, > > greg k-h
Re: [PATCH 15/18] bus: mhi: core: Introduce sysfs entries for MHI
On Sun, Sep 27, 2020 at 12:26:59PM +0200, Greg KH wrote:
> On Mon, Sep 21, 2020 at 09:38:12PM +0530, Manivannan Sadhasivam wrote:
> > From: Bhaumik Bhatt
> >
> > Introduce sysfs entries to enable userspace clients the ability to read
> > the serial number and the OEM PK Hash values obtained from BHI. OEMs
> > need to read these device-specific hardware information values through
> > userspace for factory testing purposes and cannot be exposed via degbufs
> > as it may remain disabled for performance reasons. Also, update the
> > documentation for ABI to include these entries.
> >
> > Signed-off-by: Bhaumik Bhatt
> > Reviewed-by: Manivannan Sadhasivam
> > Signed-off-by: Manivannan Sadhasivam
> > ---
> > Documentation/ABI/stable/sysfs-bus-mhi | 21 ++
> > MAINTAINERS| 1 +
> > drivers/bus/mhi/core/init.c| 53 ++
> > 3 files changed, 75 insertions(+)
> > create mode 100644 Documentation/ABI/stable/sysfs-bus-mhi
> >
> > diff --git a/Documentation/ABI/stable/sysfs-bus-mhi
> > b/Documentation/ABI/stable/sysfs-bus-mhi
> > new file mode 100644
> > index ..ecfe7662f8d0
> > --- /dev/null
> > +++ b/Documentation/ABI/stable/sysfs-bus-mhi
> > @@ -0,0 +1,21 @@
> > +What: /sys/bus/mhi/devices/.../serialnumber
> > +Date: Sept 2020
> > +KernelVersion: 5.10
> > +Contact: Bhaumik Bhatt
> > +Description: The file holds the serial number of the client device
> > obtained
> > + using a BHI (Boot Host Interface) register read after at least
> > + one attempt to power up the device has been done. If read
> > + without having the device power on at least once, the file will
> > + read all 0's.
> > +Users: Any userspace application or clients interested in
> > device info.
> > +
> > +What: /sys/bus/mhi/devices/.../oem_pk_hash
> > +Date: Sept 2020
> > +KernelVersion: 5.10
> > +Contact: Bhaumik Bhatt
> > +Description: The file holds the OEM PK Hash value of the endpoint
> > device
> > + obtained using a BHI (Boot Host Interface) register read after
> > + at least one attempt to power up the device has been done. If
> > + read without having the device power on at least once, the file
> > + will read all 0's.
> > +Users: Any userspace application or clients interested in
> > device info.
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index deaafb617361..11e7be9b9163 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -11323,6 +11323,7 @@ M: Hemant Kumar
> > L: linux-arm-...@vger.kernel.org
> > S: Maintained
> > T: git git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi.git
> > +F: Documentation/ABI/stable/sysfs-bus-mhi
> > F: Documentation/mhi/
> > F: drivers/bus/mhi/
> > F: include/linux/mhi.h
> > diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> > index 61e5885a331a..1b4161eaf0d8 100644
> > --- a/drivers/bus/mhi/core/init.c
> > +++ b/drivers/bus/mhi/core/init.c
> > @@ -76,6 +76,56 @@ const char *to_mhi_pm_state_str(enum mhi_pm_state state)
> > return mhi_pm_state_str[index];
> > }
> >
[...]
> > +static int mhi_create_sysfs(struct mhi_controller *mhi_cntrl)
> > +{
> > + return sysfs_create_group(_cntrl->mhi_dev->dev.kobj,
> > + _sysfs_group);
>
> You should never have to call a sysfs_* function from a driver or bus
> code, that implies something is wrong :)
>
Hmm. I think the inspiration is drawn from an old bus driver :(
Will submit a patch later to fix it!
> Just set the sysfs attributes to be the default groups for your
> bus/device/whatever-you-have-here and then the driver core will properly
> manage the creation and removal of these files, in a race-free manner.
>
> As it is, I think this is racy and will cause userspace confusion, but I
> haven't looked for sure, as you should use the api that guarantees it is
> safe...
>
Okay. Will use the dev_groups callback to manage the sysfs attributes.
Thanks,
Mani
> thanks,
>
> greg k-h
Re: [PATCH] rcu: Clarify nocb kthreads naming in RCU_NOCB_CPU config
On Sun, Sep 27, 2020 at 08:13:42PM -0400, Joel Fernandes wrote:
> On Thu, Sep 24, 2020 at 12:04:10PM +0530, Neeraj Upadhyay wrote:
> > Clarify the "x" in rcuox/N naming in RCU_NOCB_CPU config
> > description.
> >
>
> Reviewed-by: Joel Fernandes (Google)
Thank you, I will apply your Reviewed-by on the next rebase.
Thanx, Paul
> thanks,
>
> - Joel
>
> > Signed-off-by: Neeraj Upadhyay
> > ---
> > kernel/rcu/Kconfig | 11 ++-
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig
> > index b71e21f..5b22747 100644
> > --- a/kernel/rcu/Kconfig
> > +++ b/kernel/rcu/Kconfig
> > @@ -227,11 +227,12 @@ config RCU_NOCB_CPU
> > specified at boot time by the rcu_nocbs parameter. For each
> > such CPU, a kthread ("rcuox/N") will be created to invoke
> > callbacks, where the "N" is the CPU being offloaded, and where
> > - the "p" for RCU-preempt (PREEMPTION kernels) and "s" for RCU-sched
> > - (!PREEMPTION kernels). Nothing prevents this kthread from running
> > - on the specified CPUs, but (1) the kthreads may be preempted
> > - between each callback, and (2) affinity or cgroups can be used
> > - to force the kthreads to run on whatever set of CPUs is desired.
> > + the "x" is "p" for RCU-preempt (PREEMPTION kernels) and "s" for
> > + RCU-sched (!PREEMPTION kernels). Nothing prevents this kthread
> > + from running on the specified CPUs, but (1) the kthreads may be
> > + preempted between each callback, and (2) affinity or cgroups can
> > + be used to force the kthreads to run on whatever set of CPUs is
> > + desired.
> >
> > Say Y here if you want to help to debug reduced OS jitter.
> > Say N here if you are unsure.
> > --
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
Re: [PATCH v4 04/17] x86/acrn: Introduce hypercall interfaces
On Sun 27.Sep'20 at 12:53:14 +0200, Greg Kroah-Hartman wrote:
On Sun, Sep 27, 2020 at 12:51:52PM +0200, Greg Kroah-Hartman wrote:
On Tue, Sep 22, 2020 at 07:42:58PM +0800, shuo.a@intel.com wrote:
> From: Shuo Liu
>
> The Service VM communicates with the hypervisor via conventional
> hypercalls. VMCALL instruction is used to make the hypercalls.
>
> ACRN hypercall ABI:
> * Hypercall number is in R8 register.
> * Up to 2 parameters are in RDI and RSI registers.
> * Return value is in RAX register.
>
> Introduce the ACRN hypercall interfaces. Because GCC doesn't support R8
> register as direct register constraints, here are two ways to use R8 in
> extended asm:
> 1) use explicit register variable as input
> 2) use supported constraint as input with a explicit MOV to R8 in
> beginning of asm
>
> The number of instructions of above two ways are same.
> Asm code from 1)
> 38: 41 b8 00 00 00 80 mov$0x8000,%r8d
> 3e: 48 89 c7mov%rax,%rdi
> 41: 0f 01 c1vmcall
> Here, writes to the lower dword (%r8d) clear the upper dword of %r8 when
> the CPU is in 64-bit mode.
>
> Asm code from 2)
> 38: 48 89 c7mov%rax,%rdi
> 3b: 49 b8 00 00 00 80 00movabs $0x8000,%r8
> 42: 00 00 00
> 45: 0f 01 c1vmcall
>
> Choose 1) for code simplicity and a little bit of code size
> optimization.
>
> Originally-by: Yakui Zhao
> Signed-off-by: Shuo Liu
> Reviewed-by: Reinette Chatre
> Cc: Dave Hansen
> Cc: Sean Christopherson
> Cc: Dan Williams
> Cc: Fengwei Yin
> Cc: Zhi Wang
> Cc: Zhenyu Wang
> Cc: Yu Wang
> Cc: Reinette Chatre
> Cc: Greg Kroah-Hartman
> ---
> arch/x86/include/asm/acrn.h | 57 +
> 1 file changed, 57 insertions(+)
>
> diff --git a/arch/x86/include/asm/acrn.h b/arch/x86/include/asm/acrn.h
> index a2d4aea3a80d..23a93b87edeb 100644
> --- a/arch/x86/include/asm/acrn.h
> +++ b/arch/x86/include/asm/acrn.h
> @@ -14,4 +14,61 @@ void acrn_setup_intr_handler(void (*handler)(void));
> void acrn_remove_intr_handler(void);
> bool acrn_is_privileged_vm(void);
>
> +/*
> + * Hypercalls for ACRN
> + *
> + * - VMCALL instruction is used to implement ACRN hypercalls.
> + * - ACRN hypercall ABI:
> + * - Hypercall number is passed in R8 register.
> + * - Up to 2 arguments are passed in RDI, RSI.
> + * - Return value will be placed in RAX.
> + */
> +static inline long acrn_hypercall0(unsigned long hcall_id)
> +{
> + register long r8 asm("r8");
> + long result;
> +
> + /* Nothing can come between the r8 assignment and the asm: */
> + r8 = hcall_id;
> + asm volatile("vmcall\n\t"
> + : "=a" (result)
> + : "r" (r8)
> + : );
What keeps an interrupt from happening between the r8 assignment and the
asm: ?
Dave gave a good explanation in another email. I will apply his better
comment that "No other C code can come between this r8 assignment and the
inline asm".
Is this something that most hypercalls need to handle? I don't see
other ones needing this type of thing, is it just because of how these
are defined?
Ah, the changelog above explains this. You should put that in the code
itself, as a comment, otherwise we will not know this at all in 5
years, when gcc is changed to allow r8 access :)
OK. I will copy that into code as well.
Thanks
shuo
Re: [RFC] mm/vmstat: Add events for HugeTLB migration
On 09/25/2020 03:19 PM, Oscar Salvador wrote:
> On Fri, Sep 25, 2020 at 02:42:29PM +0530, Anshuman Khandual wrote:
>> Add following new vmstat events which will track HugeTLB page migration.
>>
>> 1. HUGETLB_MIGRATION_SUCCESS
>> 2. HUGETLB_MIGRATION_FAILURE
>>
>> It follows the existing semantics to accommodate HugeTLB subpages in total
>> page migration statistics. While here, this updates current trace event
>> "mm_migrate_pages" to accommodate now available HugeTLB based statistics.
>>
>> Cc: Daniel Jordan
>> Cc: Zi Yan
>> Cc: John Hubbard
>> Cc: Mike Kravetz
>> Cc: Andrew Morton
>> Cc: linux...@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual
>
> Was this inspired by some usecase/debugging or just to follow THP's example?
Currently HugeTLB migration events get accommodated in PGMIGRATE_SUCCESS and
PGMIGRATE_FAIL event stats as normal single page instances. Previously this
might have just seemed okay as HugeTLB page could be viewed as a single page
entity, even though it was not fully accurate as PGMIGRATE_[SUCCESS|FAILURE]
tracked statistics in terms of normal base pages.
But tracking HugeTLB pages as single pages does not make sense any more, now
that THP pages are accounted for properly. This would complete the revamped
page migration accounting where PGMIGRATE_[SUCCESS|FAILURE] will track entire
page migration events in terms of normal base pages and THP_*/HUGETLB_* will
track specialized events when applicable.
>
>> int retry = 1;
>> int thp_retry = 1;
>> +int hugetlb_retry = 1;
>> int nr_failed = 0;
>> int nr_succeeded = 0;
>> int nr_thp_succeeded = 0;
>> int nr_thp_failed = 0;
>> int nr_thp_split = 0;
>> +int nr_hugetlb_succeeded = 0;
>> +int nr_hugetlb_failed = 0;
>> int pass = 0;
>> bool is_thp = false;
>> +bool is_hugetlb = false;
>> struct page *page;
>> struct page *page2;
>> int swapwrite = current->flags & PF_SWAPWRITE;
>> @@ -1433,6 +1437,7 @@ int migrate_pages(struct list_head *from, new_page_t
>> get_new_page,
>> for (pass = 0; pass < 10 && (retry || thp_retry); pass++) {
>
> Should you not have put hugetlb_retry within the loop as well?
> Otherwise we might not rety for hugetlb pages now?
>
Right, will fix it.
[PATCH v2] soc: mediatek: Check if power domains can be powered on at boot time
In the error case, where a power domain cannot be powered on
successfully at boot time (in mtk_register_power_domains),
pm_genpd_init would still be called with is_off=false, and the
system would later try to disable the power domain again, triggering
warnings as disabled clocks are disabled again (and other potential
issues).
Also print a warning splat in that case, as this should never
happen.
Fixes: c84e358718a66f7 ("soc: Mediatek: Add SCPSYS power domain driver")
Signed-off-by: Nicolas Boichat
---
Changes in v2:
- Add WARN_ON if the domain can't be powered on, to make it more
obvious that this should not happen (there is already an error
message).
drivers/soc/mediatek/mtk-scpsys.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index f669d3754627..ca75b14931ec 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -524,6 +524,7 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
for (i = 0; i < num; i++) {
struct scp_domain *scpd = >domains[i];
struct generic_pm_domain *genpd = >genpd;
+ bool on;
/*
* Initially turn on all domains to make the domains usable
@@ -531,9 +532,9 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
* software. The unused domains will be switched off during
* late_init time.
*/
- genpd->power_on(genpd);
+ on = !WARN_ON(genpd->power_on(genpd) < 0);
- pm_genpd_init(genpd, NULL, false);
+ pm_genpd_init(genpd, NULL, !on);
}
/*
--
2.28.0.681.g6f77f65b4e-goog
Re: [PATCH v4 02/17] x86/acrn: Introduce acrn_{setup, remove}_intr_handler()
On Sun 27.Sep'20 at 12:49:43 +0200, Greg Kroah-Hartman wrote: On Tue, Sep 22, 2020 at 07:42:56PM +0800, shuo.a@intel.com wrote: From: Shuo Liu The ACRN Hypervisor builds an I/O request when a trapped I/O access happens in User VM. Then, ACRN Hypervisor issues an upcall by sending a notification interrupt to the Service VM. HSM in the Service VM needs to hook the notification interrupt to handle I/O requests. Notification interrupts from ACRN Hypervisor are already supported and a, currently uninitialized, callback called. Export two APIs for HSM to setup/remove its callback. Originally-by: Yakui Zhao Signed-off-by: Shuo Liu Reviewed-by: Zhi Wang Reviewed-by: Reinette Chatre Cc: Dave Hansen Cc: Sean Christopherson Cc: Dan Williams Cc: Fengwei Yin Cc: Zhi Wang Cc: Zhenyu Wang Cc: Yu Wang Cc: Reinette Chatre Cc: Greg Kroah-Hartman --- arch/x86/include/asm/acrn.h | 8 arch/x86/kernel/cpu/acrn.c | 16 2 files changed, 24 insertions(+) create mode 100644 arch/x86/include/asm/acrn.h diff --git a/arch/x86/include/asm/acrn.h b/arch/x86/include/asm/acrn.h new file mode 100644 index ..ff259b69cde7 --- /dev/null +++ b/arch/x86/include/asm/acrn.h @@ -0,0 +1,8 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_X86_ACRN_H +#define _ASM_X86_ACRN_H + +void acrn_setup_intr_handler(void (*handler)(void)); +void acrn_remove_intr_handler(void); + +#endif /* _ASM_X86_ACRN_H */ diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c index 0b2c03943ac6..42e88d01ccf9 100644 --- a/arch/x86/kernel/cpu/acrn.c +++ b/arch/x86/kernel/cpu/acrn.c @@ -9,7 +9,11 @@ * */ +#define pr_fmt(fmt) "acrn: " fmt Why is this needed, if you are not adding pr_* calls in this patch? True. I will remove it. Thanks.
Re: ..and it built and boots without a fuss! Linux 5.9-rc7
On 14:56 Sun 27 Sep 2020, Linus Torvalds wrote:
So we finally have all the issues I know about sorted out - the fix
for the VM issue I mentioned in the rc6 announcement is here, as is
the fix for the slab corruption issue that was separately discussed,
along with another silly page locking bug one-liner fix.
But while I do now know of any remaining gating issues any more, the
fixes came in fairly late. So unless I feel insanely optimistic and/or
a burning bush tells me that everything is bug-free, my plan right now
is that I'll do another rc next Sunday rather than the final 5.9
release. And btw, please no more burning bushes. We're kind of
sensitive about those on the West coast right now.
Anyway, while the MM side is what kept me on my toes last week, most
of the changes here are actually drivers and networking. And
networking drivers. With a small smattering of documentation and
filesystem fixes and other noise thrown in.
Shortlog appended, but what I really hope you all will do is to give
it a nice good testing. One extra week or rc kernels will help, but
only if people actually try this out.
Well, something trivial for your eyes!
5.191189] sd 0:0:0:0: [sda] Write Protect is off
[5.195216] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[5.216432] sr 1:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[5.217571] cdrom: Uniform CD-ROM driver Revision: 3.20
[5.259708] tsc: Refined TSC clocksource calibration: 2194.917 MHz
[5.260783] clocksource: tsc: mask: 0x max_cycles:
0x1fa37107ca2, max_idle_ns: 440795258165 ns
[5.262035] clocksource: Switched to clocksource tsc
[5.275091] Key type encrypted registered
[5.285337] sd 0:0:0:0: [sda] Attached SCSI disk
[5.306124] md: Waiting for all devices to be available before autodetect
[5.307345] md: If you don't use raid, use raid=noautodetect
[5.309091] md: Autodetecting RAID arrays.
[5.309996] md: autorun ...
[5.310354] md: ... autorun DONE.
[5.495612] EXT4-fs (sda): recovery complete
[5.511867] EXT4-fs (sda): mounted filesystem with ordered data mode. Opts:
(null)
[5.514269] ext4 filesystem being mounted at /root supports timestamps until
2038 (0x7fff)
[5.516852] VFS: Mounted root (ext4 filesystem) on device 8:0.
[5.531445] devtmpfs: mounted
[5.600919] Freeing unused decrypted memory: 2040K
[5.809762] Freeing unused kernel image (initmem) memory: 1600K
[5.812846] Write protecting the kernel read-only data: 26624k
[5.822103] Freeing unused kernel image (text/rodata gap) memory: 2040K
[5.830467] Freeing unused kernel image (rodata/data gap) memory: 876K
[5.832276] rodata_test: all tests were successful
[5.833948] Run /sbin/init as init process
[6.264201] EXT4-fs (sda): re-mounted. Opts: (null)
[6.266284] ext4 filesystem being remounted at / supports timestamps until
2038 (0x7fff)
Starting syslogd: OK
Starting klogd: OK
Running sysctl: [7.674742] random: crng init done
OK
Initializing random number generator: OK
Saving random seed: OK
Starting network: OK
Welcome to Buildroot_Linux
Bhaskar_Thinkpad_x250 login: root
# uname -a
Linux Bhaskar_Thinkpad_x250 5.9.0-rc7-Gentoo #1 SMP Mon Sep 28 06:16:34 IST
2020 x86_64 GNU/Linux
~Bhaskar
So.. Please?
Linus
---
Adrian Hunter (1):
ftrace: Fix missing synchronize_rcu() removing trampoline from kallsyms
Al Viro (1):
fuse: fix the ->direct_IO() treatment of iov_iter
Alaa Hleihel (1):
net/mlx5e: Fix using wrong stats_grps in mlx5e_update_ndo_stats()
Alexey Dobriyan (1):
fs: fix cast in fsparam_u32hex() macro
Aloka Dixit (1):
mac80211: Fix radiotap header channel flag for 6GHz band
Anand Jain (1):
btrfs: fix put of uninitialized kobject after seed device delete
Andres Beltran (1):
hv_netvsc: Add validation for untrusted Hyper-V values
Andrii Nakryiko (2):
docs/bpf: Fix ringbuf documentation
docs/bpf: Remove source code links
Björn Töpel (1):
xsk: Fix number of pinned pages/umem size discrepancy
Borislav Petkov (1):
rcu/tree: Export rcu_idle_{enter,exit} to modules
Brian Vazquez (1):
fib: fix fib_rule_ops indirect call wrappers when CONFIG_IPV6=m
Chaitanya Kulkarni (2):
nvme-core: get/put ctrl and transport module in nvme_dev_open/release()
nvme-core: don't use NVME_NSID_ALL for command effects and supported log
Chanwoo Choi (1):
PM / devfreq: Add timer type to devfreq_summary debugfs
Charan Teja Reddy (1):
dmabuf: fix NULL pointer dereference in dma_buf_release()
Charles Keepax (2):
regmap: debugfs: Fix handling of name string for debugfs init delays
regmap: debugfs: Add back in erroneously removed initialisation of ret
Chris Packham (1):
spi: fsl-espi: Only process interrupts for expected events
Chris Wilson (1):
drm/i915/selftests: Push the fake iommu device from the stack to data
Christian
[RESEND v3 3/4] venus: core: vote with average bandwidth and peak bandwidth as zero
As per bandwidth table video driver is voting with average bandwidth
for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero
in bandwidth table.
Fixes: 7482a983d ("media: venus: redesign clocks and pm domains control")
Signed-off-by: Mansur Alisha Shaik
Reviewed-by: Stephen Boyd
---
drivers/media/platform/qcom/venus/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index fa363b8..d5bfd6f 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -385,11 +385,11 @@ static __maybe_unused int venus_runtime_resume(struct
device *dev)
const struct venus_pm_ops *pm_ops = core->pm_ops;
int ret;
- ret = icc_set_bw(core->video_path, 0, kbps_to_icc(1000));
+ ret = icc_set_bw(core->video_path, kbps_to_icc(2), 0);
if (ret)
return ret;
- ret = icc_set_bw(core->cpucfg_path, 0, kbps_to_icc(1000));
+ ret = icc_set_bw(core->cpucfg_path, kbps_to_icc(1000), 0);
if (ret)
return ret;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[RESEND v3 0/4] Venus - change clk enable, disable order and change bw values
The intention of this patchset is to correct clock enable and disable order and vote for venus-ebi and cpucfg paths with average bandwidth instad of peak bandwidth since with current implementation we are seeing clock related warning during XO-SD and suspend device while video playback --- Resending v3 patches by correcting fixes tag Mansur Alisha Shaik (4): venus: core: change clk enable and disable order in resume and suspend venus: core: vote for video-mem path venus: core: vote with average bandwidth and peak bandwidth as zero venus: put dummy vote on video-mem path after last session release drivers/media/platform/qcom/venus/core.c | 32 -- drivers/media/platform/qcom/venus/pm_helpers.c | 10 2 files changed, 35 insertions(+), 7 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[RESEND v3 4/4] venus: put dummy vote on video-mem path after last session release
As per current implementation, video driver is unvoting "videom-mem" path
for last video session during vdec_session_release().
While video playback when we try to suspend device, we see video clock
warnings since votes are already removed during vdec_session_release().
corrected this by putting dummy vote on "video-mem" after last video
session release and unvoting it during suspend.
Fixes: 7482a983d ("media: venus: redesign clocks and pm domains control")
Signed-off-by: Mansur Alisha Shaik
Reviewed-by: Stephen Boyd
---
drivers/media/platform/qcom/venus/pm_helpers.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c
b/drivers/media/platform/qcom/venus/pm_helpers.c
index 57877ea..0ebba8e 100644
--- a/drivers/media/platform/qcom/venus/pm_helpers.c
+++ b/drivers/media/platform/qcom/venus/pm_helpers.c
@@ -212,6 +212,16 @@ static int load_scale_bw(struct venus_core *core)
}
mutex_unlock(>lock);
+ /*
+* keep minimum bandwidth vote for "video-mem" path,
+* so that clks can be disabled during vdec_session_release().
+* Actual bandwidth drop will be done during device supend
+* so that device can power down without any warnings.
+*/
+
+ if (!total_avg && !total_peak)
+ total_avg = kbps_to_icc(1000);
+
dev_dbg(core->dev, VDBGL "total: avg_bw: %u, peak_bw: %u\n",
total_avg, total_peak);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[RESEND v3 1/4] venus: core: change clk enable and disable order in resume and suspend
Currently video driver is voting after clk enable and un voting
before clk disable. This is incorrect, video driver should vote
before clk enable and unvote after clk disable.
Corrected this by changing the order of clk enable and clk disable.
Fixes: 07f8f22a33a9e ("media: venus: core: remove CNOC voting while device
suspend")
Signed-off-by: Mansur Alisha Shaik
Reviewed-by: Stephen Boyd
---
- Resending by corecting fixes tag
drivers/media/platform/qcom/venus/core.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 6103aaf..52a3886 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -355,13 +355,16 @@ static __maybe_unused int venus_runtime_suspend(struct
device *dev)
if (ret)
return ret;
+ if (pm_ops->core_power) {
+ ret = pm_ops->core_power(dev, POWER_OFF);
+ if (ret)
+ return ret;
+ }
+
ret = icc_set_bw(core->cpucfg_path, 0, 0);
if (ret)
return ret;
- if (pm_ops->core_power)
- ret = pm_ops->core_power(dev, POWER_OFF);
-
return ret;
}
@@ -371,16 +374,16 @@ static __maybe_unused int venus_runtime_resume(struct
device *dev)
const struct venus_pm_ops *pm_ops = core->pm_ops;
int ret;
+ ret = icc_set_bw(core->cpucfg_path, 0, kbps_to_icc(1000));
+ if (ret)
+ return ret;
+
if (pm_ops->core_power) {
ret = pm_ops->core_power(dev, POWER_ON);
if (ret)
return ret;
}
- ret = icc_set_bw(core->cpucfg_path, 0, kbps_to_icc(1000));
- if (ret)
- return ret;
-
return hfi_core_resume(core, false);
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[RESEND v3 2/4] venus: core: vote for video-mem path
Currently video driver is voting for venus0-ebi path during buffer
processing with an average bandwidth of all the instances and
unvoting during session release.
While video streaming when we try to do XO-SD using the command
"echo mem > /sys/power/state command" , device is not entering
to suspend state and from interconnect summary seeing votes for venus0-ebi
Corrected this by voting for venus0-ebi path in venus_runtime_resume()
and unvote during venus_runtime_suspend().
Fixes: 7482a983d ("media: venus: redesign clocks and pm domains control")
Signed-off-by: Mansur Alisha Shaik
Reviewed-by: Stephen Boyd
---
drivers/media/platform/qcom/venus/core.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 52a3886..fa363b8 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -363,7 +363,18 @@ static __maybe_unused int venus_runtime_suspend(struct
device *dev)
ret = icc_set_bw(core->cpucfg_path, 0, 0);
if (ret)
- return ret;
+ goto err_cpucfg_path;
+
+ ret = icc_set_bw(core->video_path, 0, 0);
+ if (ret)
+ goto err_video_path;
+
+ return ret;
+
+err_video_path:
+ icc_set_bw(core->cpucfg_path, kbps_to_icc(1000), 0);
+err_cpucfg_path:
+ pm_ops->core_power(dev, POWER_ON);
return ret;
}
@@ -374,6 +385,10 @@ static __maybe_unused int venus_runtime_resume(struct
device *dev)
const struct venus_pm_ops *pm_ops = core->pm_ops;
int ret;
+ ret = icc_set_bw(core->video_path, 0, kbps_to_icc(1000));
+ if (ret)
+ return ret;
+
ret = icc_set_bw(core->cpucfg_path, 0, kbps_to_icc(1000));
if (ret)
return ret;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v1] PM / devfreq: tegra30: Improve initial hardware resetting
On 9/28/20 5:51 AM, Dmitry Osipenko wrote:
> It's safe to enable the ACTMON clock at any time during driver probing,
> even if we don't know the state of hardware, because it's used only for
> collecting and processing stats, and interrupt is kept disabled. This
> allows us to slightly improve code which performs initial hardware
> resetting by making use of a single reset_control_reset() instead of
> assert/deassert pair. Secondly, a potential error of the reset-control
> API is handled nicely now.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index dedd39de7367..f5e74c2ede85 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -822,8 +822,6 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return err;
> }
>
> - reset_control_assert(tegra->reset);
> -
> err = clk_prepare_enable(tegra->clock);
> if (err) {
> dev_err(>dev,
> @@ -831,7 +829,11 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return err;
> }
>
> - reset_control_deassert(tegra->reset);
> + err = reset_control_reset(tegra->reset);
> + if (err) {
> + dev_err(>dev, "Failed to reset hardware: %d\n", err);
> + goto disable_clk;
> + }
>
> rate = clk_round_rate(tegra->emc_clock, ULONG_MAX);
> if (rate < 0) {
>
Applied it. Thanks.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH V4] doc: zh_CN: add translatation for btrfs
在 2020/9/28 上午10:24, 王擎 写道: > 在 2020/9/25 下午3:22, Wang Qing 写道: >> Translate Documentation/filesystems/btrfs.rst into Chinese. >> >> Signed-off-by: Wang Qing >> --- >> .../translations/zh_CN/filesystems/btrfs.rst | 37 >> ++ >> .../translations/zh_CN/filesystems/index.rst | 1 + >> 2 files changed, 38 insertions(+) >> create mode 100644 Documentation/translations/zh_CN/filesystems/btrfs.rst >> >> diff --git a/Documentation/translations/zh_CN/filesystems/btrfs.rst >> b/Documentation/translations/zh_CN/filesystems/btrfs.rst >> new file mode 100644 >> index 000..8b8cca2 >> --- /dev/null >> +++ b/Documentation/translations/zh_CN/filesystems/btrfs.rst >> @@ -0,0 +1,37 @@ >> +.. SPDX-License-Identifier: GPL-2.0 >> + >> +.. include:: ../disclaimer-zh_CN.rst >> + >> +:Original: :ref:`Documentation/filesystems/ext3.rst ` Uh, the encoding is right. but is the btrfs.rst's original file ext3.rst?
[PATCH v5] ipvs: adjust the debug info in function set_tcp_state
Outputting client,virtual,dst addresses info when tcp state changes,
which makes the connection debug more clear
Signed-off-by: longguang.yue
---
net/netfilter/ipvs/ip_vs_proto_tcp.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c
b/net/netfilter/ipvs/ip_vs_proto_tcp.c
index dc2e7da2742a..7da51390cea6 100644
--- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
@@ -539,8 +539,8 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct
ip_vs_conn *cp,
if (new_state != cp->state) {
struct ip_vs_dest *dest = cp->dest;
- IP_VS_DBG_BUF(8, "%s %s [%c%c%c%c] %s:%d->"
- "%s:%d state: %s->%s conn->refcnt:%d\n",
+ IP_VS_DBG_BUF(8, "%s %s [%c%c%c%c] c:%s:%d v:%s:%d "
+ "d:%s:%d state: %s->%s conn->refcnt:%d\n",
pd->pp->name,
((state_off == TCP_DIR_OUTPUT) ?
"output " : "input "),
@@ -548,10 +548,12 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct
ip_vs_conn *cp,
th->fin ? 'F' : '.',
th->ack ? 'A' : '.',
th->rst ? 'R' : '.',
- IP_VS_DBG_ADDR(cp->daf, >daddr),
- ntohs(cp->dport),
IP_VS_DBG_ADDR(cp->af, >caddr),
ntohs(cp->cport),
+ IP_VS_DBG_ADDR(cp->af, >vaddr),
+ ntohs(cp->vport),
+ IP_VS_DBG_ADDR(cp->daf, >daddr),
+ ntohs(cp->dport),
tcp_state_name(cp->state),
tcp_state_name(new_state),
refcount_read(>refcnt));
--
2.20.1 (Apple Git-117)
