linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/riscv/Kconfig
between commit:
d95f1a542c3d ("RISC-V: Implement sparsemem")
from the risc-v tree and commit:
f6a9089b8915 ("riscv: make mmap allocation top-down by default")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/riscv/Kconfig
index 572599cbf750,87dc5370becb..
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@@ -56,7 -54,18 +56,19 @@@ config RISC
select EDAC_SUPPORT
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
+ select SPARSEMEM_STATIC if 32BIT
+ select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
+ select HAVE_ARCH_MMAP_RND_BITS
+
+ config ARCH_MMAP_RND_BITS_MIN
+ default 18 if 64BIT
+ default 8
+
+ # max bits determined by the following formula:
+ # VA_BITS - PAGE_SHIFT - 3
+ config ARCH_MMAP_RND_BITS_MAX
+ default 24 if 64BIT # SV39 based
+ default 17
config MMU
def_bool y
pgpig4OM6djT0.pgp
Description: OpenPGP digital signature
Re: [PATCH v5 2/2] powerpc: Add support to initialize ima policy rules
Hi Nayna,
Some more comments below.
Nayna Jain writes:
> POWER secure boot relies on the kernel IMA security subsystem to
> perform the OS kernel image signature verification.
Again this is just a design choice we've made, it's not specified
anywhere or anything like that. And it only applies to bare metal secure
boot, at least so far. AIUI.
> Since each secure
> boot mode has different IMA policy requirements, dynamic definition of
> the policy rules based on the runtime secure boot mode of the system is
> required. On systems that support secure boot, but have it disabled,
> only measurement policy rules of the kernel image and modules are
> defined.
It's probably worth mentioning that we intend to use this in our
Linux-based boot loader, which uses kexec, and that's one of the reasons
why we're particularly interested in defining the rules for kexec?
> This patch defines the arch-specific implementation to retrieve the
> secure boot mode of the system and accordingly configures the IMA policy
> rules.
>
> This patch provides arch-specific IMA policies if PPC_SECURE_BOOT
> config is enabled.
>
> Signed-off-by: Nayna Jain
> ---
> arch/powerpc/Kconfig | 2 ++
> arch/powerpc/kernel/Makefile | 2 +-
> arch/powerpc/kernel/ima_arch.c | 50 ++
> include/linux/ima.h| 3 +-
> 4 files changed, 55 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/kernel/ima_arch.c
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index c902a39124dc..42109682b727 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -917,6 +917,8 @@ config PPC_SECURE_BOOT
> bool
> default n
> depends on PPC64
> + depends on IMA
> + depends on IMA_ARCH_POLICY
> help
> Linux on POWER with firmware secure boot enabled needs to define
> security policies to extend secure boot to the OS.This config
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index d310ebb4e526..520b1c814197 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -157,7 +157,7 @@ endif
> obj-$(CONFIG_EPAPR_PARAVIRT) += epapr_paravirt.o epapr_hcalls.o
> obj-$(CONFIG_KVM_GUEST) += kvm.o kvm_emul.o
>
> -obj-$(CONFIG_PPC_SECURE_BOOT)+= secboot.o
> +obj-$(CONFIG_PPC_SECURE_BOOT)+= secboot.o ima_arch.o
>
> # Disable GCOV, KCOV & sanitizers in odd or sensitive code
> GCOV_PROFILE_prom_init.o := n
> diff --git a/arch/powerpc/kernel/ima_arch.c b/arch/powerpc/kernel/ima_arch.c
> new file mode 100644
> index ..ac90fac83338
> --- /dev/null
> +++ b/arch/powerpc/kernel/ima_arch.c
> @@ -0,0 +1,50 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 IBM Corporation
> + * Author: Nayna Jain
> + *
> + * ima_arch.c
> + * - initialize ima policies for PowerPC Secure Boot
> + */
> +
> +#include
> +#include
> +
> +bool arch_ima_get_secureboot(void)
> +{
> + return get_powerpc_secureboot();
> +}
> +
> +/*
> + * File signature verification is not needed, include only measurements
> + */
> +static const char *const default_arch_rules[] = {
> + "measure func=KEXEC_KERNEL_CHECK",
> + "measure func=MODULE_CHECK",
> + NULL
> +};
The rules above seem fairly self explanatory.
> +
> +/* Both file signature verification and measurements are needed */
> +static const char *const sb_arch_rules[] = {
> + "measure func=KEXEC_KERNEL_CHECK template=ima-modsig",
> + "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig",
> +#if IS_ENABLED(CONFIG_MODULE_SIG)
> + "measure func=MODULE_CHECK",
> +#else
> + "measure func=MODULE_CHECK template=ima-modsig",
> + "appraise func=MODULE_CHECK appraise_type=imasig|modsig",
> +#endif
But these ones are not so obvious, at least to me who knows very little
about IMA.
Can you add a one line comment to each of the ones in here saying what
it does and why we want it?
> + NULL
> +};
> +
> +/*
> + * On PowerPC, file measurements are to be added to the IMA measurement list
> + * irrespective of the secure boot state of the system.
Why? Just because we think it's useful? Would be good to provide some
further justification.
* Signature verification
> + * is conditionally enabled based on the secure boot state.
> + */
> +const char *const *arch_get_ima_policy(void)
> +{
> + if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot())
> + return sb_arch_rules;
> + return default_arch_rules;
> +}
> diff --git a/include/linux/ima.h b/include/linux/ima.h
> index a20ad398d260..10af09b5b478 100644
> --- a/include/linux/ima.h
> +++ b/include/linux/ima.h
> @@ -29,7 +29,8 @@ extern void ima_kexec_cmdline(const void *buf, int size);
> extern void ima_add_kexec_buffer(struct kimage *image);
> #endif
>
> -#if (defined(CONFIG_X86) && defined(CONFIG_EFI)) || defined(CONFIG_S390)
> +#if (defined(CONFIG_X86) && defined(CONFIG_EFI))
[PATCH net-next] r8152: modify rtl8152_set_speed function
First, for AUTONEG_DISABLE, we only need to modify MII_BMCR.
Second, add advertising parameter for rtl8152_set_speed(). Add
RTL_ADVERTISED_xxx for advertising parameter of rtl8152_set_speed().
Then, the advertising settings from ethtool could be saved.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 196 +++-
1 file changed, 132 insertions(+), 64 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c6fa0c17c13d..5d49d8dd93e1 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -757,6 +757,7 @@ struct r8152 {
u32 msg_enable;
u32 tx_qlen;
u32 coalesce;
+ u32 advertising;
u32 rx_buf_sz;
u32 rx_copybreak;
u32 rx_pending;
@@ -790,6 +791,13 @@ enum tx_csum_stat {
TX_CSUM_NONE
};
+#define RTL_ADVERTISED_10_HALF BIT(0)
+#define RTL_ADVERTISED_10_FULL BIT(1)
+#define RTL_ADVERTISED_100_HALFBIT(2)
+#define RTL_ADVERTISED_100_FULLBIT(3)
+#define RTL_ADVERTISED_1000_HALF BIT(4)
+#define RTL_ADVERTISED_1000_FULL BIT(5)
+
/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
* The RTL chips use a 64 element hash table based on the Ethernet CRC.
*/
@@ -3801,90 +3809,117 @@ static void rtl8153b_disable(struct r8152 *tp)
r8153b_aldps_en(tp, true);
}
-static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u16 speed, u8
duplex)
+static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8
duplex,
+u32 advertising)
{
- u16 bmcr, anar, gbcr;
enum spd_duplex speed_duplex;
+ u16 bmcr;
int ret = 0;
- anar = r8152_mdio_read(tp, MII_ADVERTISE);
- anar &= ~(ADVERTISE_10HALF | ADVERTISE_10FULL |
- ADVERTISE_100HALF | ADVERTISE_100FULL);
- if (tp->mii.supports_gmii) {
- gbcr = r8152_mdio_read(tp, MII_CTRL1000);
- gbcr &= ~(ADVERTISE_1000FULL | ADVERTISE_1000HALF);
- } else {
- gbcr = 0;
- }
-
if (autoneg == AUTONEG_DISABLE) {
- if (speed == SPEED_10) {
- bmcr = 0;
- anar |= ADVERTISE_10HALF | ADVERTISE_10FULL;
- speed_duplex = FORCE_10M_HALF;
- } else if (speed == SPEED_100) {
- bmcr = BMCR_SPEED100;
- anar |= ADVERTISE_100HALF | ADVERTISE_100FULL;
- speed_duplex = FORCE_100M_HALF;
- } else if (speed == SPEED_1000 && tp->mii.supports_gmii) {
- bmcr = BMCR_SPEED1000;
- gbcr |= ADVERTISE_1000FULL | ADVERTISE_1000HALF;
- speed_duplex = NWAY_1000M_FULL;
- } else {
- ret = -EINVAL;
- goto out;
- }
+ if (duplex != DUPLEX_HALF && duplex != DUPLEX_FULL)
+ return -EINVAL;
- if (duplex == DUPLEX_FULL) {
- bmcr |= BMCR_FULLDPLX;
- if (speed != SPEED_1000)
- speed_duplex++;
- }
- } else {
- if (speed == SPEED_10) {
+ switch (speed) {
+ case SPEED_10:
+ bmcr = BMCR_SPEED10;
if (duplex == DUPLEX_FULL) {
- anar |= ADVERTISE_10HALF | ADVERTISE_10FULL;
- speed_duplex = NWAY_10M_FULL;
+ bmcr |= BMCR_FULLDPLX;
+ speed_duplex = FORCE_10M_FULL;
} else {
- anar |= ADVERTISE_10HALF;
- speed_duplex = NWAY_10M_HALF;
+ speed_duplex = FORCE_10M_HALF;
}
- } else if (speed == SPEED_100) {
+ break;
+ case SPEED_100:
+ bmcr = BMCR_SPEED100;
if (duplex == DUPLEX_FULL) {
- anar |= ADVERTISE_10HALF | ADVERTISE_10FULL;
- anar |= ADVERTISE_100HALF | ADVERTISE_100FULL;
- speed_duplex = NWAY_100M_FULL;
+ bmcr |= BMCR_FULLDPLX;
+ speed_duplex = FORCE_100M_FULL;
} else {
- anar |= ADVERTISE_10HALF;
- anar |= ADVERTISE_100HALF;
- speed_duplex = NWAY_100M_HALF;
+ speed_duplex = FORCE_100M_HALF;
}
- } else if (speed == SPEED_1000 && tp->mii.supports_gmii) {
- if (duplex ==
Re: [PATCH v5 1/2] powerpc: detect the secure boot mode of the system
Hi Nayna,
Sorry I've taken so long to get to this series, there's just too many
patches that need reviewing :/
Nayna Jain writes:
> Secure boot on POWER defines different IMA policies based on the secure
> boot state of the system.
The terminology throughout is a bit vague, we have POWER, PowerPC, Linux
on POWER etc.
What this patch is talking about is a particular implemention of secure
boot on some OpenPOWER machines running bare metal - am I right?
So saying "Secure boot on POWER defines different IMA policies" is a bit
broad I think. Really we've just decided that a way to implement secure
boot is to use IMA policies.
> This patch defines a function to detect the secure boot state of the
> system.
>
> The PPC_SECURE_BOOT config represents the base enablement of secureboot
> on POWER.
>
> Signed-off-by: Nayna Jain
> ---
> arch/powerpc/Kconfig | 11 +
> arch/powerpc/include/asm/secboot.h | 27
> arch/powerpc/kernel/Makefile | 2 +
> arch/powerpc/kernel/secboot.c | 71 ++
> 4 files changed, 111 insertions(+)
> create mode 100644 arch/powerpc/include/asm/secboot.h
> create mode 100644 arch/powerpc/kernel/secboot.c
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 77f6ebf97113..c902a39124dc 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -912,6 +912,17 @@ config PPC_MEM_KEYS
>
> If unsure, say y.
>
> +config PPC_SECURE_BOOT
> + prompt "Enable PowerPC Secure Boot"
How about "Enable secure boot support"
> + bool
> + default n
The default is 'n', so you don't need that default line.
> + depends on PPC64
Should it just depend on POWERNV for now? AFAIK there's nothing in here
that's necessarily going to be shared with the guest secure boot code is
there?
> + help
> + Linux on POWER with firmware secure boot enabled needs to define
> + security policies to extend secure boot to the OS.This config
> + allows user to enable OS Secure Boot on PowerPC systems that
> + have firmware secure boot support.
Again POWER vs PowerPC.
I think something like:
"Enable support for secure boot on some systems that have firmware
support for it. If in doubt say N."
> diff --git a/arch/powerpc/include/asm/secboot.h
> b/arch/powerpc/include/asm/secboot.h
secure_boot.h would be fine.
> new file mode 100644
> index ..e726261bb00b
> --- /dev/null
> +++ b/arch/powerpc/include/asm/secboot.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * PowerPC secure boot definitions
> + *
> + * Copyright (C) 2019 IBM Corporation
> + * Author: Nayna Jain
I prefer to not have email addresses in copyright headers, as they just
bit rot. Your email is in the git log.
> + *
> + */
> +#ifndef POWERPC_SECBOOT_H
> +#define POWERPC_SECBOOT_H
We usually do _ASM_POWERPC_SECBOOT_H (or _ASM_POWERPC_SECURE_BOOT_H).
> +#ifdef CONFIG_PPC_SECURE_BOOT
> +extern struct device_node *is_powerpc_secvar_supported(void);
> +extern bool get_powerpc_secureboot(void);
You don't need 'extern' for functions in headers.
> +#else
> +static inline struct device_node *is_powerpc_secvar_supported(void)
> +{
> + return NULL;
> +}
> +
> +static inline bool get_powerpc_secureboot(void)
> +{
> + return false;
> +}
> +
> +#endif
> +#endif
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index ea0c69236789..d310ebb4e526 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -157,6 +157,8 @@ endif
> obj-$(CONFIG_EPAPR_PARAVIRT) += epapr_paravirt.o epapr_hcalls.o
> obj-$(CONFIG_KVM_GUEST) += kvm.o kvm_emul.o
>
> +obj-$(CONFIG_PPC_SECURE_BOOT)+= secboot.o
> +
> # Disable GCOV, KCOV & sanitizers in odd or sensitive code
> GCOV_PROFILE_prom_init.o := n
> KCOV_INSTRUMENT_prom_init.o := n
> diff --git a/arch/powerpc/kernel/secboot.c b/arch/powerpc/kernel/secboot.c
> new file mode 100644
> index ..5ea0d52d64ef
> --- /dev/null
> +++ b/arch/powerpc/kernel/secboot.c
> @@ -0,0 +1,71 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 IBM Corporation
> + * Author: Nayna Jain
> + *
> + * secboot.c
> + * - util function to get powerpc secboot state
That's not really necessary.
> + */
> +#include
> +#include
> +#include
> +
> +struct device_node *is_powerpc_secvar_supported(void)
This is a pretty weird signature. The "is_" implies it will return a
bool, but then it actually returns a device node *.
> +{
> + struct device_node *np;
> + int status;
> +
> + np = of_find_node_by_name(NULL, "ibm,secureboot");
> + if (!np) {
> + pr_info("secureboot node is not found\n");
> + return NULL;
> + }
There's no good reason to search by name. You should just search by compatible.
eg. of_find_compatible_node()
> + status = of_device_is_compatible(np, "ibm,secureboot-v3");
> + if (!status) {
> +
Re: linux-next: build failure after merge of the powerpc tree
On Mon, Sep 02, 2019 at 09:40:11PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the powerpc tree, today's linux-next build (powerpc > ppc44x_defconfig) failed like this: Yes, this conflict is expected and we dicussed it before. I'll make sure Linus is in the loop when sending the pull request.
Re: [PATCH v3 4/7] usb: mtk-xhci: support ip-sleep wakeup for MT8183
Hi Chunfeng, I love your patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.3-rc6 next-20190830] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chunfeng-Yun/add-support-USB-for-MT8183/20190901-163637 config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=ia64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): In file included from include/linux/bitops.h:5:0, from include/linux/kernel.h:12, from include/linux/clk.h:13, from drivers/usb/host/xhci-mtk.c:10: drivers/usb/host/xhci-mtk.c: In function 'usb_wakeup_ip_sleep_set': include/linux/bits.h:8:19: warning: large integer implicitly truncated to unsigned type [-Woverflow] #define BIT(nr) (UL(1) << (nr)) ^ >> drivers/usb/host/xhci-mtk.c:64:19: note: in expansion of macro 'BIT' #define WC0_IS_EN BIT(6) ^~~ >> drivers/usb/host/xhci-mtk.c:294:9: note: in expansion of macro 'WC0_IS_EN' msk = WC0_IS_EN | WC0_IS_C(0xf) | WC0_IS_P; ^ vim +/BIT +64 drivers/usb/host/xhci-mtk.c > 10 #include 11 #include 12 #include 13 #include 14 #include 15 #include 16 #include 17 #include 18 #include 19 #include 20 #include 21 22 #include "xhci.h" 23 #include "xhci-mtk.h" 24 25 /* ip_pw_ctrl0 register */ 26 #define CTRL0_IP_SW_RST BIT(0) 27 28 /* ip_pw_ctrl1 register */ 29 #define CTRL1_IP_HOST_PDN BIT(0) 30 31 /* ip_pw_ctrl2 register */ 32 #define CTRL2_IP_DEV_PDNBIT(0) 33 34 /* ip_pw_sts1 register */ 35 #define STS1_IP_SLEEP_STS BIT(30) 36 #define STS1_U3_MAC_RST BIT(16) 37 #define STS1_XHCI_RST BIT(11) 38 #define STS1_SYS125_RST BIT(10) 39 #define STS1_REF_RSTBIT(8) 40 #define STS1_SYSPLL_STABLE BIT(0) 41 42 /* ip_xhci_cap register */ 43 #define CAP_U3_PORT_NUM(p) ((p) & 0xff) 44 #define CAP_U2_PORT_NUM(p) (((p) >> 8) & 0xff) 45 46 /* u3_ctrl_p register */ 47 #define CTRL_U3_PORT_HOST_SEL BIT(2) 48 #define CTRL_U3_PORT_PDNBIT(1) 49 #define CTRL_U3_PORT_DISBIT(0) 50 51 /* u2_ctrl_p register */ 52 #define CTRL_U2_PORT_HOST_SEL BIT(2) 53 #define CTRL_U2_PORT_PDNBIT(1) 54 #define CTRL_U2_PORT_DISBIT(0) 55 56 /* u2_phy_pll register */ 57 #define CTRL_U2_FORCE_PLL_STB BIT(28) 58 59 /* usb remote wakeup registers in syscon */ 60 /* mt8183 etc */ 61 #define PERI_WK_CTRL0 0x20 62 #define WC0_IS_C(x) (((x) & 0xf) << 28) /* cycle debounce */ 63 #define WC0_IS_PBIT(12) /* polarity */ > 64 #define WC0_IS_EN BIT(6) 65 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v3 08/11] PCI: layerscape: Modify the MSIX to the doorbell mode
On Mon, Sep 02, 2019 at 11:17:13AM +0800, Xiaowei Bao wrote: > dw_pcie_ep_raise_msix_irq was never called in the exisitng driver > before, because the ls1046a platform don't support the MSIX feature > and msix_capable was always set to false. > Now that add the ls1088a platform with MSIX support, but the existing > dw_pcie_ep_raise_msix_irq doesn't work, so use the doorbell method to > support the MSIX feature. > > Signed-off-by: Xiaowei Bao Reviewed-by: Andrew Murray > --- > v2: > - No change > v3: > - Modify the commit message make it clearly. > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c > b/drivers/pci/controller/dwc/pci-layerscape-ep.c > index 1e07287..5f0cb99 100644 > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c > @@ -79,7 +79,8 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 > func_no, > case PCI_EPC_IRQ_MSI: > return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num); > case PCI_EPC_IRQ_MSIX: > - return dw_pcie_ep_raise_msix_irq(ep, func_no, interrupt_num); > + return dw_pcie_ep_raise_msix_irq_doorbell(ep, func_no, > + interrupt_num); > default: > dev_err(pci->dev, "UNKNOWN IRQ type\n"); > return -EINVAL; > -- > 2.9.5 >
Re: [PATCH v2 1/3] ASoC: es8316: judge PCM rate at later timing
On Sun, Sep 01, 2019 at 01:26:48AM +0900, Katsuhiro Suzuki wrote: > This patch change the judge timing about playing/capturing PCM rate. > > Original code set constraints list of PCM rate limits at set_sysclk. > This strategy works well if system is using fixed rate clock. > > But some boards and SoC (such as RockPro64 and RockChip I2S) has > connected SoC MCLK out to ES8316 MCLK in. In this case, SoC side I2S > will choose suitable frequency of MCLK such as fs * mclk-fs when > user starts playing or capturing. The best way to handle this is to try to support both fixed and variable clock rates, some other drivers do this by setting constraints based on MCLK only if the MCLK has been set to a non-zero value. They have the machine drivers reset the clock rate to 0 when it goes idle so that no constraints are applied then. This means that if the machine has a fixed clock there will be constraints, and that constraints get applied if one direction has started and fixed the clock, but still allows the clock to be varied where possible. signature.asc Description: PGP signature
Re: [PATCH] media: vimc: fla: Add virtual flash subdevice
Hi Lucas, Eduardo, Thank you for the patch! Some comments below: On 9/1/19 11:11 PM, Lucas A. M. Magalhães wrote: > From: Lucas A. M. Magalhaes > > Add a virtual subdevice to simulate the flash control API. > Those are the supported controls: > v4l2-ctl -d /dev/v4l-subdev6 -L > Flash Controls > >led_mode 0x009c0901 (menu) : min=0 max=2 default=0 > value=0 > 0: Off > 1: Flash > 2: Torch > strobe_source 0x009c0902 (menu) : min=0 max=1 default=0 > value=0 > 0: Software > 1: External > strobe 0x009c0903 (button) : flags=write-only, > execute-on-write > stop_strobe 0x009c0904 (button) : flags=write-only, > execute-on-write > strobe_status 0x009c0905 (bool) : default=0 value=0 > flags=read-only > strobe_timeout 0x009c0906 (int): min=1 max=10 step=1 > default=10 value=10 >intensity_flash_mode 0x009c0907 (int): min=0 max=255 step=1 > default=255 value=255 >intensity_torch_mode 0x009c0908 (int): min=0 max=255 step=1 > default=255 value=255 > intensity_indicator 0x009c0909 (int): min=0 max=255 step=1 > default=255 value=255 > faults 0x009c090a (bitmask): max=0x0002 > default=0x value=0x > > Co-authored-by: Eduardo Barretto > Signed-off-by: Eduardo Barretto > Signed-off-by: Lucas A. M. Magalhães > > --- > Hi, > > This patch depends on the patch series > "Collapse vimc into single monolithic driver" version 3. > > I tested it using the v4l2-ctl and the v4l2-compliance. Apparently the > compliance > doesn't test any of the standard flash controls. However I got this error: > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > fail: v4l2-test-controls.cpp(830): subscribe event for control 'Flash > Controls' failed > > Is it really mandatory to implement the event mechanism? > > Here is the full output of the v4l2-compliance > > root@(none):/# /usr/local/bin/v4l2-compliance -d /dev/v4l-subdev6 > v4l2-compliance SHA: b393a5408383b7341883857dfda78537f2f85ef6, 64 bits > > Compliance test for vimc device /dev/v4l-subdev6: > > Media Driver Info: > Driver name : vimc > Model: VIMC MDEV > Serial : > Bus info : platform:vimc > Media version: 5.3.0 > Hardware revision: 0x (0) > Driver version : 5.3.0 > Interface Info: > ID : 0x0339 > Type : V4L Sub-Device > Entity Info: > ID : 0x001c (28) > Name : Flash Controller > Function : Flash Controller > > Required ioctls: > test MC information (see 'Media Driver Info' above): OK > > Allow for multiple opens: > test second /dev/v4l-subdev6 open: OK > test for unlimited opens: OK > > Debug ioctls: > [ 342.293254] Flash Controller: = START STATUS > > [ 342.293945] Flash Controller: == END STATUS > == > test VIDIOC_LOG_STATUS: OK (Not Supported) > > Input ioctls: > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 0 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Control ioctls: > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK > test VIDIOC_QUERYCTRL: OK > test VIDIOC_G/S_CTRL: OK > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > fail: v4l2-test-controls.cpp(830): subscribe event for > control 'Flash Controls' failed > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > > ontrols: 11 Private Controls: 0 > > Format ioctls: > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported) > test VIDIOC_G/S_PARM: OK (Not Supported) > test VIDIOC_G_FBUF: OK
Re: [PATCH 1/3] x86: fix typo in comment for poke_text_early
On Mon, Sep 02, 2019 at 12:24:34PM +0200, Marco Ammon wrote: > In the documentation for text_poke_early, "protected again" should > actually be "protected against". This patch fixes the spelling mistake. For the future: Avoid having "This patch" or "This commit" in the commit message. It is tautologically useless. Also, do $ git grep 'This patch' Documentation/process for more details. I've merged those patches into a single one and have applied it. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH 3/3] perf stat: Add --per-numa agregation support
Adding new --per-numa option to aggregate counts per NUMA
nodes for system-wide mode measurements.
You can specify --per-numa in live mode:
# perf stat -a -I 1000 -e cycles --per-numa
# time numa cpus counts unit events
1.000542550 N0 20 6,202,097 cycles
1.000542550 N1 20639,559 cycles
2.002040063 N0 20 7,412,495 cycles
2.002040063 N1 20 2,185,577 cycles
3.003451699 N0 20 6,508,917 cycles
3.003451699 N1 20765,607 cycles
...
Or in the record/report stat session:
# perf stat record -a -I 1000 -e cycles
# time counts unit events
1.000536937 10,008,468 cycles
2.002090152 9,578,539 cycles
3.003625233 7,647,869 cycles
4.005135036 7,032,086 cycles
^C 4.340902364 3,923,893 cycles
# perf stat report --per-numa
# time numa cpus counts unit events
1.000536937 N0 20 9,355,086 cycles
1.000536937 N1 20653,382 cycles
2.002090152 N0 20 7,712,838 cycles
2.002090152 N1 20 1,865,701 cycles
3.003625233 N0 20 6,604,441 cycles
3.003625233 N1 20 1,043,428 cycles
4.005135036 N0 20 6,350,522 cycles
4.005135036 N1 20681,564 cycles
4.340902364 N0 20 3,403,188 cycles
4.340902364 N1 20520,705 cycles
Link: http://lkml.kernel.org/n/tip-h57ftv8vmqrgzz3kdvlvh...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/Documentation/perf-stat.txt | 5 +++
tools/perf/builtin-stat.c | 52 ++
tools/perf/util/cpumap.c | 18 +
tools/perf/util/cpumap.h | 3 ++
tools/perf/util/stat-display.c | 15
tools/perf/util/stat.c | 1 +
tools/perf/util/stat.h | 1 +
7 files changed, 95 insertions(+)
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 930c51c01201..74299dc2ffd1 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -217,6 +217,11 @@ core number and the number of online logical processors on
that physical process
Aggregate counts per monitored threads, when monitoring threads (-t option)
or processes (-p option).
+--per-numa::
+Aggregate counts per NUMA nodes for system-wide mode measurements. This
+is a useful mode to detect imbalance between NUMA nodes. To enable this
+mode, use --per-numa in addition to -a. (system-wide).
+
-D msecs::
--delay msecs::
After starting the program, wait msecs before measuring. This is useful to
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 5bc0c570b7b6..5c30e9e3de19 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -790,6 +790,8 @@ static struct option stat_options[] = {
"aggregate counts per physical processor core", AGGR_CORE),
OPT_SET_UINT(0, "per-thread", _config.aggr_mode,
"aggregate counts per thread", AGGR_THREAD),
+ OPT_SET_UINT(0, "per-numa", _config.aggr_mode,
+"aggregate counts per numa node", AGGR_NUMA),
OPT_UINTEGER('D', "delay", _config.initial_delay,
"ms to wait before starting measurement after program
start"),
OPT_CALLBACK_NOOPT(0, "metric-only", _config.metric_only, NULL,
@@ -822,6 +824,12 @@ static int perf_stat__get_core(struct perf_stat_config
*config __maybe_unused,
return cpu_map__get_core(map, cpu, NULL);
}
+static int perf_stat__get_numa(struct perf_stat_config *config __maybe_unused,
+ struct perf_cpu_map *map, int cpu)
+{
+ return cpu_map__get_numa(map, cpu, NULL);
+}
+
static int perf_stat__get_aggr(struct perf_stat_config *config,
aggr_get_id_t get_id, struct perf_cpu_map *map,
int idx)
{
@@ -856,6 +864,12 @@ static int perf_stat__get_core_cached(struct
perf_stat_config *config,
return perf_stat__get_aggr(config, perf_stat__get_core, map, idx);
}
+static int perf_stat__get_numa_cached(struct perf_stat_config *config,
+ struct perf_cpu_map *map, int idx)
+{
+ return perf_stat__get_aggr(config, perf_stat__get_numa, map, idx);
+}
+
static bool term_percore_set(void)
{
struct evsel *counter;
@@ -894,6 +908,13 @@ static int perf_stat_init_aggr_mode(void)
}
stat_config.aggr_get_id = perf_stat__get_core_cached;
break;
+ case AGGR_NUMA:
+ if
[PATCH 0/3] perf stat: Add --per-numa option
hi, adding --per-numa option to aggregate stats per NUMA nodes, you can get now use stat command like: # perf stat -a -I 1000 -e cycles --per-numa # time numa cpus counts unit events 1.000542550 N0 20 6,202,097 cycles 1.000542550 N1 20639,559 cycles 2.002040063 N0 20 7,412,495 cycles 2.002040063 N1 20 2,185,577 cycles 3.003451699 N0 20 6,508,917 cycles 3.003451699 N1 20765,607 cycles ... thanks, jirka --- Jiri Olsa (3): libperf: Add perf_cpu_map__max function perf tools: Add perf_env__numa_node function perf stat: Add --per-numa agregation support tools/perf/Documentation/perf-stat.txt | 5 + tools/perf/builtin-stat.c | 60 ++-- tools/perf/lib/cpumap.c| 12 tools/perf/lib/include/perf/cpumap.h | 1 + tools/perf/lib/libperf.map | 1 + tools/perf/util/cpumap.c | 18 ++ tools/perf/util/cpumap.h | 3 +++ tools/perf/util/env.c | 35 +++ tools/perf/util/env.h | 6 ++ tools/perf/util/stat-display.c | 15 +++ tools/perf/util/stat.c | 1 + tools/perf/util/stat.h | 1 + 12 files changed, 148 insertions(+), 10 deletions(-)
[PATCH 1/3] libperf: Add perf_cpu_map__max function
So it can be used from multiple places.
Link: http://lkml.kernel.org/n/tip-yp3h5rl9e8piybufq41zq...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-stat.c| 14 +-
tools/perf/lib/cpumap.c | 12
tools/perf/lib/include/perf/cpumap.h | 1 +
tools/perf/lib/libperf.map | 1 +
4 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 7e17bf9f700a..5bc0c570b7b6 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -822,18 +822,6 @@ static int perf_stat__get_core(struct perf_stat_config
*config __maybe_unused,
return cpu_map__get_core(map, cpu, NULL);
}
-static int cpu_map__get_max(struct perf_cpu_map *map)
-{
- int i, max = -1;
-
- for (i = 0; i < map->nr; i++) {
- if (map->map[i] > max)
- max = map->map[i];
- }
-
- return max;
-}
-
static int perf_stat__get_aggr(struct perf_stat_config *config,
aggr_get_id_t get_id, struct perf_cpu_map *map,
int idx)
{
@@ -928,7 +916,7 @@ static int perf_stat_init_aggr_mode(void)
* taking the highest cpu number to be the size of
* the aggregation translate cpumap.
*/
- nr = cpu_map__get_max(evsel_list->core.cpus);
+ nr = perf_cpu_map__max(evsel_list->core.cpus);
stat_config.cpus_aggr_map = perf_cpu_map__empty_new(nr + 1);
return stat_config.cpus_aggr_map ? 0 : -ENOMEM;
}
diff --git a/tools/perf/lib/cpumap.c b/tools/perf/lib/cpumap.c
index 1f0e6f334237..2ca1fafa620d 100644
--- a/tools/perf/lib/cpumap.c
+++ b/tools/perf/lib/cpumap.c
@@ -260,3 +260,15 @@ int perf_cpu_map__idx(struct perf_cpu_map *cpus, int cpu)
return -1;
}
+
+int perf_cpu_map__max(struct perf_cpu_map *map)
+{
+ int i, max = -1;
+
+ for (i = 0; i < map->nr; i++) {
+ if (map->map[i] > max)
+ max = map->map[i];
+ }
+
+ return max;
+}
diff --git a/tools/perf/lib/include/perf/cpumap.h
b/tools/perf/lib/include/perf/cpumap.h
index 8aa995c59498..ac9aa497f84a 100644
--- a/tools/perf/lib/include/perf/cpumap.h
+++ b/tools/perf/lib/include/perf/cpumap.h
@@ -16,6 +16,7 @@ LIBPERF_API void perf_cpu_map__put(struct perf_cpu_map *map);
LIBPERF_API int perf_cpu_map__cpu(const struct perf_cpu_map *cpus, int idx);
LIBPERF_API int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
LIBPERF_API bool perf_cpu_map__empty(const struct perf_cpu_map *map);
+LIBPERF_API int perf_cpu_map__max(struct perf_cpu_map *map);
#define perf_cpu_map__for_each_cpu(cpu, idx, cpus) \
for ((idx) = 0, (cpu) = perf_cpu_map__cpu(cpus, idx); \
diff --git a/tools/perf/lib/libperf.map b/tools/perf/lib/libperf.map
index dc4d66363bc4..cd0d17b996c8 100644
--- a/tools/perf/lib/libperf.map
+++ b/tools/perf/lib/libperf.map
@@ -9,6 +9,7 @@ LIBPERF_0.0.1 {
perf_cpu_map__nr;
perf_cpu_map__cpu;
perf_cpu_map__empty;
+ perf_cpu_map__max;
perf_thread_map__new_dummy;
perf_thread_map__set_pid;
perf_thread_map__comm;
--
2.21.0
[PATCH 2/3] perf tools: Add perf_env__numa_node function
To speed up cpu to node lookup, adding perf_env__numa_node
function, that creates cpu array on the first lookup, that
holds numa nodes for each stored cpu.
Link: http://lkml.kernel.org/n/tip-qqwxklhissf3yjyuaszh6...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/env.c | 35 +++
tools/perf/util/env.h | 6 ++
2 files changed, 41 insertions(+)
diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c
index 3baca06786fb..6385961e45df 100644
--- a/tools/perf/util/env.c
+++ b/tools/perf/util/env.c
@@ -179,6 +179,7 @@ void perf_env__exit(struct perf_env *env)
zfree(>sibling_threads);
zfree(>pmu_mappings);
zfree(>cpu);
+ zfree(>numa_map);
for (i = 0; i < env->nr_numa_nodes; i++)
perf_cpu_map__put(env->numa_nodes[i].map);
@@ -338,3 +339,37 @@ const char *perf_env__arch(struct perf_env *env)
return normalize_arch(arch_name);
}
+
+
+int perf_env__numa_node(struct perf_env *env, int cpu)
+{
+ if (!env->nr_numa_map) {
+ struct numa_node *nn;
+ int i, nr = 0;
+
+ for (i = 0; i < env->nr_numa_nodes; i++) {
+ nn = >numa_nodes[i];
+ nr = max(nr, perf_cpu_map__max(nn->map));
+ }
+
+ nr++;
+ env->numa_map = zalloc(nr * sizeof(int));
+ if (!env->numa_map)
+ return -1;
+
+ for (i = 0; i < nr; i++)
+ env->numa_map[i] = -1;
+
+ env->nr_numa_map = nr;
+
+ for (i = 0; i < env->nr_numa_nodes; i++) {
+ int tmp, j;
+
+ nn = >numa_nodes[i];
+ perf_cpu_map__for_each_cpu(j, tmp, nn->map)
+ env->numa_map[j] = i;
+ }
+ }
+
+ return cpu >= 0 && cpu < env->nr_numa_map ? env->numa_map[cpu] : -1;
+}
diff --git a/tools/perf/util/env.h b/tools/perf/util/env.h
index d8e083d42610..777008f8007a 100644
--- a/tools/perf/util/env.h
+++ b/tools/perf/util/env.h
@@ -86,6 +86,10 @@ struct perf_env {
struct rb_root btfs;
u32 btfs_cnt;
} bpf_progs;
+
+ /* For fast cpu to numa node lookup via perf_env__numa_node */
+ int *numa_map;
+ int nr_numa_map;
};
enum perf_compress_type {
@@ -118,4 +122,6 @@ struct bpf_prog_info_node
*perf_env__find_bpf_prog_info(struct perf_env *env,
__u32 prog_id);
void perf_env__insert_btf(struct perf_env *env, struct btf_node *btf_node);
struct btf_node *perf_env__find_btf(struct perf_env *env, __u32 btf_id);
+
+int perf_env__numa_node(struct perf_env *env, int cpu);
#endif /* __PERF_ENV_H */
--
2.21.0
[tip: x86/cleanups] x86: Correct misc typos
The following commit has been merged into the x86/cleanups branch of tip: Commit-ID: 32b1cbe380417f2ed80f758791179de6b05795ab Gitweb: https://git.kernel.org/tip/32b1cbe380417f2ed80f758791179de6b05795ab Author:Marco Ammon AuthorDate:Mon, 02 Sep 2019 14:02:59 +02:00 Committer: Borislav Petkov CommitterDate: Mon, 02 Sep 2019 14:02:59 +02:00 x86: Correct misc typos Correct spelling typos in comments in different files under arch/x86/. [ bp: Merge into a single patch, massage. ] Signed-off-by: Marco Ammon Signed-off-by: Borislav Petkov Cc: Daniel Bristot de Oliveira Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Juergen Gross Cc: Masami Hiramatsu Cc: Nadav Amit Cc: Peter Zijlstra Cc: Pu Wen Cc: Rick Edgecombe Cc: "Steven Rostedt (VMware)" Cc: Thomas Gleixner Cc: triv...@kernel.org Cc: x86-ml Link: https://lkml.kernel.org/r/20190902102436.27396-1-marco.am...@fau.de --- arch/x86/include/asm/text-patching.h | 4 ++-- arch/x86/kernel/alternative.c| 6 +++--- arch/x86/kernel/kprobes/opt.c| 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/text-patching.h b/arch/x86/include/asm/text-patching.h index 70c0996..5e8319b 100644 --- a/arch/x86/include/asm/text-patching.h +++ b/arch/x86/include/asm/text-patching.h @@ -45,8 +45,8 @@ extern void text_poke_early(void *addr, const void *opcode, size_t len); * no thread can be preempted in the instructions being modified (no iret to an * invalid instruction possible) or if the instructions are changed from a * consistent state to another consistent state atomically. - * On the local CPU you need to be protected again NMI or MCE handlers seeing an - * inconsistent instruction while you patch. + * On the local CPU you need to be protected against NMI or MCE handlers seeing + * an inconsistent instruction while you patch. */ extern void *text_poke(void *addr, const void *opcode, size_t len); extern void *text_poke_kgdb(void *addr, const void *opcode, size_t len); diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c index ccd3201..9d3a971 100644 --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -713,7 +713,7 @@ void __init alternative_instructions(void) * Don't stop machine check exceptions while patching. * MCEs only happen when something got corrupted and in this * case we must do something about the corruption. -* Ignoring it is worse than a unlikely patching race. +* Ignoring it is worse than an unlikely patching race. * Also machine checks tend to be broadcast and if one CPU * goes into machine check the others follow quickly, so we don't * expect a machine check to cause undue problems during to code @@ -753,8 +753,8 @@ void __init alternative_instructions(void) * When you use this code to patch more than one byte of an instruction * you need to make sure that other CPUs cannot execute this code in parallel. * Also no thread must be currently preempted in the middle of these - * instructions. And on the local CPU you need to be protected again NMI or MCE - * handlers seeing an inconsistent instruction while you patch. + * instructions. And on the local CPU you need to be protected against NMI or + * MCE handlers seeing an inconsistent instruction while you patch. */ void __init_or_module text_poke_early(void *addr, const void *opcode, size_t len) diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c index 9d4aede..b348dd5 100644 --- a/arch/x86/kernel/kprobes/opt.c +++ b/arch/x86/kernel/kprobes/opt.c @@ -403,7 +403,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe *op, (u8 *)op->kp.addr + op->optinsn.size); len += RELATIVEJUMP_SIZE; - /* We have to use text_poke for instuction buffer because it is RO */ + /* We have to use text_poke() for instruction buffer because it is RO */ text_poke(slot, buf, len); ret = 0; out:
Re: [PATCH v4] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
Tony Chuang writes: >> From: Jian-Hong Pan >> Subject: [PATCH v4] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ >> >> There is a mass of jobs between spin lock and unlock in the hardware >> IRQ which will occupy much time originally. To make system work more >> efficiently, this patch moves the jobs to the soft IRQ (bottom half) to >> reduce the time in hardware IRQ. >> >> Signed-off-by: Jian-Hong Pan > > Now it works fine with MSI interrupt enabled. > > But this patch is conflicting with MSI interrupt patch. > Is there a better way we can make Kalle apply them more smoothly? > I can rebase them and submit both if you're OK. Yeah, submitting all the MSI patches in the same patchset is the easiest approach. That way they apply cleanly to wireless-drivers-next. -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] media: vimc: Implement debayer control for mean window size
On 9/1/19 9:40 PM, Arthur Moraes do Lago wrote:
> Add mean window size parameter for debayer filter as a control in
> vimc-debayer.
>
> vimc-debayer was patched to allow changing mean windows parameter
> of the filter without needing to reload the driver. The parameter
> can now be set using a v4l2-ctl control(mean_window_size).
>
> Co-developed-by: Laís Pessine do Carmo
> Signed-off-by: Laís Pessine do Carmo
> Signed-off-by: Arthur Moraes do Lago
>
> ---
> This patch was made on top of Shuah Khan's patch (162623).
> Thanks.
> ---
> drivers/media/platform/vimc/vimc-common.h | 1 +
> drivers/media/platform/vimc/vimc-debayer.c | 81 ++
> 2 files changed, 70 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/vimc/vimc-common.h
> b/drivers/media/platform/vimc/vimc-common.h
> index 5b2282de395c..547ff04a415e 100644
> --- a/drivers/media/platform/vimc/vimc-common.h
> +++ b/drivers/media/platform/vimc/vimc-common.h
> @@ -19,6 +19,7 @@
> #define VIMC_CID_VIMC_BASE (0x00f0 | 0xf000)
> #define VIMC_CID_VIMC_CLASS (0x00f0 | 1)
> #define VIMC_CID_TEST_PATTERN(VIMC_CID_VIMC_BASE + 0)
> +#define VIMC_CID_MEAN_WIN_SIZE (VIMC_CID_VIMC_BASE + 1)
>
> #define VIMC_FRAME_MAX_WIDTH 4096
> #define VIMC_FRAME_MAX_HEIGHT 2160
> diff --git a/drivers/media/platform/vimc/vimc-debayer.c
> b/drivers/media/platform/vimc/vimc-debayer.c
> index 6cee911bf149..aa3edeed96bc 100644
> --- a/drivers/media/platform/vimc/vimc-debayer.c
> +++ b/drivers/media/platform/vimc/vimc-debayer.c
> @@ -11,17 +11,11 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "vimc-common.h"
>
> -static unsigned int deb_mean_win_size = 3;
> -module_param(deb_mean_win_size, uint, );
> -MODULE_PARM_DESC(deb_mean_win_size, " the window size to calculate the
> mean.\n"
> - "NOTE: the window size needs to be an odd number, as the main pixel "
> - "stays in the center of the window, otherwise the next odd number "
> - "is considered");
> -
> #define IS_SINK(pad) (!pad)
> #define IS_SRC(pad) (pad)
>
> @@ -49,6 +43,8 @@ struct vimc_deb_device {
> u8 *src_frame;
> const struct vimc_deb_pix_map *sink_pix_map;
> unsigned int sink_bpp;
> + unsigned int mean_win_size;
> + struct v4l2_ctrl_handler hdl;
> };
>
> static const struct v4l2_mbus_framefmt sink_fmt_default = {
> @@ -387,7 +383,7 @@ static void vimc_deb_calc_rgb_sink(struct vimc_deb_device
> *vdeb,
>* the top left corner of the mean window (considering the current
>* pixel as the center)
>*/
> - seek = deb_mean_win_size / 2;
> + seek = vdeb->mean_win_size / 2;
>
> /* Sum the values of the colors in the mean window */
>
> @@ -477,6 +473,33 @@ static void *vimc_deb_process_frame(struct
> vimc_ent_device *ved,
>
> }
>
> +static inline void vimc_deb_s_mean_win_size(struct vimc_deb_device *vdeb,
> + unsigned int mean_win_size)
> +{
> + if (vdeb->mean_win_size == mean_win_size)
> + return;
> + vdeb->mean_win_size = mean_win_size;
> +}
> +
> +static int vimc_deb_s_ctrl(struct v4l2_ctrl *ctrl)
> +{
> + struct vimc_deb_device *vdeb =
> + container_of(ctrl->handler, struct vimc_deb_device, hdl);
> +
> + switch (ctrl->id) {
> + case VIMC_CID_MEAN_WIN_SIZE:
> + vimc_deb_s_mean_win_size(vdeb, ctrl->val);
> + break;
> + default:
> + return -EINVAL;
> + }
> + return 0;
> +}
> +
> +static const struct v4l2_ctrl_ops vimc_deb_ctrl_ops = {
> + .s_ctrl = vimc_deb_s_ctrl,
> +};
> +
> static void vimc_deb_release(struct v4l2_subdev *sd)
> {
> struct vimc_deb_device *vdeb =
> @@ -502,6 +525,24 @@ void vimc_deb_rm(struct vimc_device *vimc, struct
> vimc_ent_config *vcfg)
> vimc_ent_sd_unregister(ved, >sd);
> }
>
> +static const struct v4l2_ctrl_config vimc_deb_ctrl_class = {
> + .flags = V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY,
> + .id = VIMC_CID_VIMC_CLASS,
> + .name = "VIMC Controls",
> + .type = V4L2_CTRL_TYPE_CTRL_CLASS,
> +};
> +
> +static const struct v4l2_ctrl_config vimc_deb_ctrl_mean_win_size = {
> + .ops = _deb_ctrl_ops,
> + .id = VIMC_CID_MEAN_WIN_SIZE,
> + .name = "Mean window size",
Should be "Mean Window Size". We follow English capitalization rules for titles
for the control names.
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .min = 1,
> + .max = 99,
This seems unreasonably large. I'm not sure what is a typical maximum, but
I suspect it will be very much smaller than 99.
Make sure you do a streaming test with this control with both the min and max
values.
Does v4l2-compliance pass?
Regards,
Hans
> + .step = 2,
> + .def = 3,
> +};
> +
> int vimc_deb_add(struct vimc_device *vimc, struct vimc_ent_config *vcfg)
> {
> struct
Re: [PATCH v1 1/2] clk: intel: Add CGU clock driver for a new SoC
On Mon, Sep 02, 2019 at 03:43:13PM +0800, Tanwar, Rahul wrote:
> On 28/8/2019 11:09 PM, Andy Shevchenko wrote:
> > On Wed, Aug 28, 2019 at 03:00:17PM +0800, Rahul Tanwar wrote:
> > > drivers/clk/intel/Kconfig | 13 +
> > > drivers/clk/intel/Makefile | 4 +
> > Any plans what to do with existing x86 folder there?
> I checked the x86 folder. This driver's clock controller IP is totally
> different than other clock drivers inside x86. So having a common
> driver source is not a option. It is of course possible to move this
> driver inside x86 folder. Please let me know if you think moving
> this driver inside x86 folder makes more sense.
I'm talking about unambiguous folder where we keep Intel's drivers.
With your series it will be confusing x86 vs intel.
> > > +/*
> > > + * Calculate formula:
> > > + * rate = (prate * mult + (prate * frac) / frac_div) / div
> > > + */
> > > +static unsigned long
> > > +intel_pll_calc_rate(unsigned long prate, unsigned int mult,
> > > + unsigned int div, unsigned int frac, unsigned int frac_div)
> > > +{
> > > + u64 crate, frate, rate64;
> > > +
> > > + rate64 = prate;
> > > + crate = rate64 * mult;
> > > +
> > > + if (frac) {
> > This seems unnecessary.
> > I think you would like to check for frac_div instead?
> > Though I would rather to use frac = 0, frac_div = 1 and drop this
> > conditional
> > completely.
> frac_div value is fixed to BIT(24) i.e. always a non zero value. mult & div
> are directly read from registers and by design the register values for
> mult & div is also always a non zero value. However, frac can logically
> be zero. So, I still find if (frac) condition most suitable here.
Then it's simple not needed.
> > > + frate = rate64 * frac;
> > > + do_div(frate, frac_div);
> > > + crate += frate;
> > > + }
> > > + do_div(crate, div);
> > > +
> > > + return (unsigned long)crate;
> > > + hw = >hw;
> > Seems redundant temporary variable.
>
> Agree, will update in v2.
Though in another method you have similar pattern. So, perhaps you may leave it
for sake of consistency with patterns.
> > > + pr_debug("Add clk: %s, id: %u\n", clk_hw_get_name(hw), id);
> > Is this useful?
> Yes, IMO, this proves very useful for system wide clock issues
> debugging during bootup.
You may use function tracer for that.
> > Does val == 0 follows the table, i.e. makes div == 1?
>
> 0 val means output clock is ref clock i.e. div ==1. Agree that adding
> .val = 0, .div =1 entry will make it more clear & complete.
>
> > > + { .val = 0, .div = 1 },
> > > + { .val = 1, .div = 2 },
> > > + { .val = 2, .div = 3 },
1
> > > + { .val = 3, .div = 4 },
> > > + { .val = 4, .div = 5 },
> > > + { .val = 5, .div = 6 },
1
> > > + { .val = 6, .div = 8 },
> > > + { .val = 7, .div = 10 },
> > > + { .val = 8, .div = 12 },
2
> > > + { .val = 9, .div = 16 },
> > > + { .val = 10, .div = 20 },
> > > + { .val = 11, .div = 24 },
4
> > > + { .val = 12, .div = 32 },
> > > + { .val = 13, .div = 40 },
> > > + { .val = 14, .div = 48 },
8
> > > + { .val = 15, .div = 64 },
16
So, now we see the pattern:
div = val < 3 ? (val + 1) : (1 << ((val - 3) / 3));
So, can we eliminate table?
--
With Best Regards,
Andy Shevchenko
Applied "regulator: provide regulator_bulk_set_supply_names()" to the regulator tree
The patch
regulator: provide regulator_bulk_set_supply_names()
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d0087e72710ca7d1b309bf427286da58418ea89e Mon Sep 17 00:00:00 2001
From: Bartosz Golaszewski
Date: Fri, 30 Aug 2019 09:17:37 +0200
Subject: [PATCH] regulator: provide regulator_bulk_set_supply_names()
There are many regulator consumers who - before using the regulator
bulk functions - set the supply names in regulator_bulk_data using
a for loop.
Let's provide a simple helper in the consumer API that allows users
to do the same with a single function call.
Signed-off-by: Bartosz Golaszewski
Link: https://lore.kernel.org/r/20190830071740.4267-2-b...@bgdev.pl
Signed-off-by: Mark Brown
---
drivers/regulator/helpers.c| 21 +
include/linux/regulator/consumer.h | 12
2 files changed, 33 insertions(+)
diff --git a/drivers/regulator/helpers.c b/drivers/regulator/helpers.c
index 4986cc5064a1..ca3dc3f3bb29 100644
--- a/drivers/regulator/helpers.c
+++ b/drivers/regulator/helpers.c
@@ -860,3 +860,24 @@ int regulator_get_current_limit_regmap(struct
regulator_dev *rdev)
return -EINVAL;
}
EXPORT_SYMBOL_GPL(regulator_get_current_limit_regmap);
+
+/**
+ * regulator_bulk_set_supply_names - initialize the 'supply' fields in an array
+ * of regulator_bulk_data structs
+ *
+ * @consumers: array of regulator_bulk_data entries to initialize
+ * @supply_names: array of supply name strings
+ * @num_supplies: number of supply names to initialize
+ *
+ * Note: the 'consumers' array must be the size of 'num_supplies'.
+ */
+void regulator_bulk_set_supply_names(struct regulator_bulk_data *consumers,
+const char *const *supply_names,
+unsigned int num_supplies)
+{
+ unsigned int i;
+
+ for (i = 0; i < num_supplies; i++)
+ consumers[i].supply = supply_names[i];
+}
+EXPORT_SYMBOL_GPL(regulator_bulk_set_supply_names);
diff --git a/include/linux/regulator/consumer.h
b/include/linux/regulator/consumer.h
index 815983419375..6d2181a76987 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -281,6 +281,12 @@ void devm_regulator_unregister_notifier(struct regulator
*regulator,
void *regulator_get_drvdata(struct regulator *regulator);
void regulator_set_drvdata(struct regulator *regulator, void *data);
+/* misc helpers */
+
+void regulator_bulk_set_supply_names(struct regulator_bulk_data *consumers,
+const char *const *supply_names,
+unsigned int num_supplies);
+
#else
/*
@@ -580,6 +586,12 @@ static inline int regulator_list_voltage(struct regulator
*regulator, unsigned s
return -EINVAL;
}
+void regulator_bulk_set_supply_names(struct regulator_bulk_data *consumers,
+const char *const *supply_names,
+unsigned int num_supplies)
+{
+}
+
#endif
static inline int regulator_set_voltage_triplet(struct regulator *regulator,
--
2.20.1
Re: [PATCH v1 1/2] clk: intel: Add CGU clock driver for a new SoC
On Mon, Sep 02, 2019 at 03:20:30PM +0300, Andy Shevchenko wrote:
> On Mon, Sep 02, 2019 at 03:43:13PM +0800, Tanwar, Rahul wrote:
> > On 28/8/2019 11:09 PM, Andy Shevchenko wrote:
> > > On Wed, Aug 28, 2019 at 03:00:17PM +0800, Rahul Tanwar wrote:
> > > Does val == 0 follows the table, i.e. makes div == 1?
> >
> > 0 val means output clock is ref clock i.e. div ==1. Agree that adding
> > .val = 0, .div =1 entry will make it more clear & complete.
> >
> > > > + { .val = 0, .div = 1 },
> > > > + { .val = 1, .div = 2 },
> > > > + { .val = 2, .div = 3 },
>
> 1
>
> > > > + { .val = 3, .div = 4 },
> > > > + { .val = 4, .div = 5 },
> > > > + { .val = 5, .div = 6 },
>
> 1
>
> > > > + { .val = 6, .div = 8 },
> > > > + { .val = 7, .div = 10 },
> > > > + { .val = 8, .div = 12 },
>
> 2
>
> > > > + { .val = 9, .div = 16 },
> > > > + { .val = 10, .div = 20 },
> > > > + { .val = 11, .div = 24 },
>
> 4
>
> > > > + { .val = 12, .div = 32 },
> > > > + { .val = 13, .div = 40 },
> > > > + { .val = 14, .div = 48 },
>
> 8
>
> > > > + { .val = 15, .div = 64 },
>
> 16
>
>
> So, now we see the pattern:
>
> div = val < 3 ? (val + 1) : (1 << ((val - 3) / 3));
It's not complete, but I think you got the idea.
> So, can we eliminate table?
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v4 11/11] lib/test_printf: Add tests for %pfw printk modifier
On Mon, Sep 02, 2019 at 11:32:40AM +0300, Sakari Ailus wrote:
> Add a test for the %pfw printk modifier using software nodes.
> + const struct software_node softnodes[] = {
> + { .name = "first", },
> + { .name = "second", .parent = [0], },
> + { .name = "third", .parent = [1], },
> + { NULL /* Guardian */ },
> + };
> + test(full_name_second, "%pfw",
> + software_node_fwnode([ARRAY_SIZE(softnodes) - 3]));
> + test(full_name, "%pfw",
> + software_node_fwnode([ARRAY_SIZE(softnodes) - 2]));
> + test(full_name, "%pfwf",
> + software_node_fwnode([ARRAY_SIZE(softnodes) - 2]));
> + test(second_name, "%pfwP",
> + software_node_fwnode([ARRAY_SIZE(softnodes) - 3]));
> + test(third_name, "%pfwP",
> + software_node_fwnode([ARRAY_SIZE(softnodes) - 2]));
These can be shorted and easier to parse if you use absolute indexes.
--
With Best Regards,
Andy Shevchenko
Re: [RFC][PATCH 01/13] sched/deadline: Impose global limits on sched_attr::sched_period
On Mon, Sep 02, 2019 at 11:16:23AM +0200, Peter Zijlstra wrote: > On Sat, Aug 31, 2019 at 03:41:17PM +0100, Alessio Balsini wrote: > > Right! > > > > Verified that sysctl_sched_dl_period_max and sysctl_sched_dl_period_min > > values > > are now always consistent. > > > > I spent some time in trying to figure out if not having any mutex in > > __checkparam_dl() is safe. There can surely happen that "max < min", e.g.: > > Sharing my thoughts, a "BUG_ON(max < min)" in __checkparam_dl() is then a > > guaranteed source of explosions, but the good news is that "if (period < > > min || > > period > max" in __checkparam_dl() surely fails if "max < min". Also the > > fact > > that, when we are writing the new sysctl_sched_dl_* values, only one is > > actually changed at a time, that surely helps to preserve the consistency. > > > > But is that enough? > > Strictly speaking, no, I suppose it is not. We can have two changes in > between the two READ_ONCE()s and then we'd be able to observe a > violation. > > The easy way to fix that is do something like: > > + synchronize_rcu(); > mutex_unlock(); > > in sched_dl_period_handler(). And do: > > + preempt_disable(); > max = (u64)READ_ONCE(sysctl_sched_dl_period_max) * NSEC_PER_USEC; > min = (u64)READ_ONCE(sysctl_sched_dl_period_min) * NSEC_PER_USEC; > + preempt_enable(); > > in __checkparam_dl(). > > That would prohibit we see two changes, and seeing only the single > change is safe. I pushed out a new version; and added patch to sched_rt_handler() on top. Please have a look at: git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/wip-deadline I'll move these two patches to sched/core if everything looks good.
Re: [PATCH v3 05/11] dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a and ls2088a
On Mon, Sep 02, 2019 at 11:17:10AM +0800, Xiaowei Bao wrote: > Add compatible strings for ls1088a and ls2088a. > > Signed-off-by: Xiaowei Bao > --- > v2: > - No change. > v3: > - Use one valid combination of compatible strings. > > Documentation/devicetree/bindings/pci/layerscape-pci.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt > index e20ceaa..762ae41 100644 > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt > @@ -22,7 +22,9 @@ Required properties: > "fsl,ls1043a-pcie" > "fsl,ls1012a-pcie" >EP mode: > - "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep" > + "fsl,ls1046a-pcie-ep" "fsl,ls-pcie-ep" > + "fsl,ls1088a-pcie-ep" "fsl,ls-pcie-ep" > + "fsl,ls2088a-pcie-ep" "fsl,ls-pcie-ep" This isn't consistent with "[PATCH v3 09/11] PCI: layerscape: Add EP mode..." as that patch drops the fallback "fsl,ls-pcie-ep". Either the fallback must be preserved in the driver, or you need to drop it here. What if there are existing users that depend on the fallback? (I'm also not sure if that comma should have been dropped). Thanks, Andrew Murray > - reg: base addresses and lengths of the PCIe controller register blocks. > - interrupts: A list of interrupt outputs of the controller. Must contain an >entry for each entry in the interrupt-names property. > -- > 2.9.5 >
[PATCH 2/5] EDAC, mc_sysfs: Change dev_ch_attribute->channel to unsigned int
Struct member dev_ch_attribute->channel is always used as unsigned
int. Change type to unsigned int to avoid type casts.
Signed-off-by: Robert Richter
---
drivers/edac/edac_mc_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 640b9419623e..4eb8c5ceb973 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -131,7 +131,7 @@ static const char * const edac_caps[] = {
struct dev_ch_attribute {
struct device_attribute attr;
- int channel;
+ unsigned int channel;
};
#define DEVICE_CHANNEL(_name, _mode, _show, _store, _var) \
--
2.20.1
[PATCH 4/5] EDAC, mc_sysfs: Make debug messages consistent
Debug messages are inconsistently used in the error handlers. Some
lack an error message, some are called regardless the return status,
messages for the same error are at different locations in the code
depending on the error code. This happens esp. near put_device()
calls. Make those debug messages more consistent. Additionally, unify
the error messages to have the same terms for the same operations of
the device.
Signed-off-by: Robert Richter
---
drivers/edac/edac_mc_sysfs.c | 63 +---
1 file changed, 29 insertions(+), 34 deletions(-)
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 309fc24339b0..eaccde3fc1b8 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -278,7 +278,7 @@ static void csrow_attr_release(struct device *dev)
{
struct csrow_info *csrow = container_of(dev, struct csrow_info, dev);
- edac_dbg(1, "Releasing csrow device %s\n", dev_name(dev));
+ edac_dbg(1, "device %s released\n", dev_name(dev));
kfree(csrow);
}
@@ -414,14 +414,16 @@ static int edac_create_csrow_object(struct mem_ctl_info
*mci,
dev_set_name(>dev, "csrow%d", index);
dev_set_drvdata(>dev, csrow);
- edac_dbg(0, "creating (virtual) csrow node %s\n",
-dev_name(>dev));
-
err = device_add(>dev);
- if (err)
+ if (err) {
+ edac_dbg(1, "failure: create device %s\n",
dev_name(>dev));
put_device(>dev);
+ return err;
+ }
- return err;
+ edac_dbg(0, "device %s created\n", dev_name(>dev));
+
+ return 0;
}
/* Create a CSROW object under specifed edac_mc_device */
@@ -435,12 +437,8 @@ static int edac_create_csrow_objects(struct mem_ctl_info
*mci)
if (!nr_pages_per_csrow(csrow))
continue;
err = edac_create_csrow_object(mci, mci->csrows[i], i);
- if (err < 0) {
- edac_dbg(1,
-"failure: create csrow objects for csrow %d\n",
-i);
+ if (err < 0)
goto error;
- }
}
return 0;
@@ -624,7 +622,7 @@ static void dimm_attr_release(struct device *dev)
{
struct dimm_info *dimm = container_of(dev, struct dimm_info, dev);
- edac_dbg(1, "Releasing dimm device %s\n", dev_name(dev));
+ edac_dbg(1, "device %s released\n", dev_name(dev));
kfree(dimm);
}
@@ -653,12 +651,20 @@ static int edac_create_dimm_object(struct mem_ctl_info
*mci,
pm_runtime_forbid(>dev);
err = device_add(>dev);
- if (err)
+ if (err) {
+ edac_dbg(1, "failure: create device %s\n",
dev_name(>dev));
put_device(>dev);
+ return err;
+ }
- edac_dbg(0, "created rank/dimm device %s\n", dev_name(>dev));
+ if (IS_ENABLED(CONFIG_EDAC_DEBUG)) {
+ char location[80];
+ edac_dimm_info_location(dimm, location, sizeof(location));
+ edac_dbg(0, "device %s created at location %s\n",
+ dev_name(>dev), location);
+ }
- return err;
+ return 0;
}
/*
@@ -901,7 +907,7 @@ static void mci_attr_release(struct device *dev)
{
struct mem_ctl_info *mci = container_of(dev, struct mem_ctl_info, dev);
- edac_dbg(1, "Releasing csrow device %s\n", dev_name(dev));
+ edac_dbg(1, "device %s released\n", dev_name(dev));
kfree(mci);
}
@@ -933,7 +939,6 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci,
dev_set_drvdata(>dev, mci);
pm_runtime_forbid(>dev);
- edac_dbg(0, "creating device %s\n", dev_name(>dev));
err = device_add(>dev);
if (err < 0) {
edac_dbg(1, "failure: create device %s\n", dev_name(>dev));
@@ -941,6 +946,8 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci,
return err;
}
+ edac_dbg(0, "device %s created\n", dev_name(>dev));
+
/*
* Create the dimm/rank devices
*/
@@ -950,22 +957,9 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci,
if (!dimm->nr_pages)
continue;
-#ifdef CONFIG_EDAC_DEBUG
- edac_dbg(1, "creating dimm%d, located at ", i);
- if (edac_debug_level >= 1) {
- int lay;
- for (lay = 0; lay < mci->n_layers; lay++)
- printk(KERN_CONT "%s %d ",
- edac_layer_name[mci->layers[lay].type],
- dimm->location[lay]);
- printk(KERN_CONT "\n");
- }
-#endif
err = edac_create_dimm_object(mci, dimm, i);
- if (err) {
- edac_dbg(1, "failure: create dimm %d
[PATCH 0/5] EDAC: Small cleanups and fixes
A bunch of cleanups and fixes for issues found while working with the code. Changes are individual and independent from each other. They can be applied separately (only #4 depends on #3). Also updating the reviewer's entry as I will be able to do some reviews for edac code. Note that patch #3 is an updated version of a patch reviewed before: https://lore.kernel.org/patchwork/patch/1093466/ Some references to ml discussions that are related to this series: https://lore.kernel.org/patchwork/patch/1093480/#1312590 https://lore.kernel.org/patchwork/patch/1093466/#1310572 Robert Richter (5): EDAC: Prefer 'unsigned int' to bare use of 'unsigned' EDAC, mc_sysfs: Change dev_ch_attribute->channel to unsigned int EDAC, mc_sysfs: Remove pointless gotos EDAC, mc_sysfs: Make debug messages consistent MAINTAINERS: update EDAC's reviewer entry MAINTAINERS | 1 + drivers/edac/edac_mc.c | 20 drivers/edac/edac_mc.h | 6 +-- drivers/edac/edac_mc_sysfs.c | 91 drivers/edac/ghes_edac.c | 2 +- drivers/edac/i5100_edac.c| 16 --- include/linux/edac.h | 10 ++-- 7 files changed, 69 insertions(+), 77 deletions(-) -- 2.20.1
[PATCH 3/5] EDAC, mc_sysfs: Remove pointless gotos
Use direct returns instead of gotos. Error handling code becomes
smaller and better readable.
Signed-off-by: Robert Richter
---
drivers/edac/edac_mc_sysfs.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 4eb8c5ceb973..309fc24339b0 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -938,7 +938,7 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci,
if (err < 0) {
edac_dbg(1, "failure: create device %s\n", dev_name(>dev));
put_device(>dev);
- goto out;
+ return err;
}
/*
@@ -987,7 +987,6 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci,
}
device_unregister(>dev);
-out:
return err;
}
@@ -1044,10 +1043,8 @@ int __init edac_mc_sysfs_init(void)
int err;
mci_pdev = kzalloc(sizeof(*mci_pdev), GFP_KERNEL);
- if (!mci_pdev) {
- err = -ENOMEM;
- goto out;
- }
+ if (!mci_pdev)
+ return -ENOMEM;
mci_pdev->bus = edac_get_sysfs_subsys();
mci_pdev->type = _attr_type;
@@ -1055,17 +1052,14 @@ int __init edac_mc_sysfs_init(void)
dev_set_name(mci_pdev, "mc");
err = device_add(mci_pdev);
- if (err < 0)
- goto out_put_device;
+ if (err < 0) {
+ put_device(mci_pdev);
+ return err;
+ }
edac_dbg(0, "device %s created\n", dev_name(mci_pdev));
return 0;
-
- out_put_device:
- put_device(mci_pdev);
- out:
- return err;
}
void edac_mc_sysfs_exit(void)
--
2.20.1
[PATCH 5/5] MAINTAINERS: update EDAC's reviewer entry
I did some significant work with code in edac_mc.c and ghes_edac.c already, so I guess I can probably helping out a bit as code reviewer here. Signed-off-by: Robert Richter --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 97912d8333a9..79d2ae8519e3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5788,6 +5788,7 @@ M:Borislav Petkov M: Mauro Carvalho Chehab M: Tony Luck R: James Morse +R: Robert Richter L: linux-e...@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git edac-for-next S: Supported -- 2.20.1
[PATCH 1/5] EDAC: Prefer 'unsigned int' to bare use of 'unsigned'
Use of 'unsigned int' instead of bare use of 'unsigned'. Fix this for
edac_mc*, ghes and the i5100 driver.
Depending on the compiler's warning level it can throw messages like
this:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#235: FILE: drivers/edac/i5100_edac.c:854:
+ const unsigned chan = i5100_csrow_to_chan(mci, dimm->idx);
Signed-off-by: Robert Richter
---
drivers/edac/edac_mc.c | 20 ++--
drivers/edac/edac_mc.h | 6 +++---
drivers/edac/edac_mc_sysfs.c | 6 +++---
drivers/edac/ghes_edac.c | 2 +-
drivers/edac/i5100_edac.c| 16 +---
include/linux/edac.h | 10 +-
6 files changed, 31 insertions(+), 29 deletions(-)
diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index c68f62ab54b0..2f1e3ec8e1cc 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -114,8 +114,8 @@ static const struct kernel_param_ops edac_report_ops = {
module_param_cb(edac_report, _report_ops, _report, 0644);
-unsigned edac_dimm_info_location(struct dimm_info *dimm, char *buf,
-unsigned len)
+unsigned int edac_dimm_info_location(struct dimm_info *dimm, char *buf,
+ unsigned int len)
{
struct mem_ctl_info *mci = dimm->mci;
int i, n, count = 0;
@@ -236,9 +236,9 @@ EXPORT_SYMBOL_GPL(edac_mem_types);
* At return, the pointer 'p' will be incremented to be used on a next call
* to this function.
*/
-void *edac_align_ptr(void **p, unsigned size, int n_elems)
+void *edac_align_ptr(void **p, unsigned int size, int n_elems)
{
- unsigned align, r;
+ unsigned int align, r;
void *ptr = *p;
*p += size * n_elems;
@@ -302,10 +302,10 @@ static void _edac_mc_free(struct mem_ctl_info *mci)
kfree(mci);
}
-struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
- unsigned n_layers,
+struct mem_ctl_info *edac_mc_alloc(unsigned int mc_num,
+ unsigned int n_layers,
struct edac_mc_layer *layers,
- unsigned sz_pvt)
+ unsigned int sz_pvt)
{
struct mem_ctl_info *mci;
struct edac_mc_layer *layer;
@@ -313,9 +313,9 @@ struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
struct rank_info *chan;
struct dimm_info *dimm;
u32 *ce_per_layer[EDAC_MAX_LAYERS], *ue_per_layer[EDAC_MAX_LAYERS];
- unsigned pos[EDAC_MAX_LAYERS];
- unsigned size, tot_dimms = 1, count = 1;
- unsigned tot_csrows = 1, tot_channels = 1, tot_errcount = 0;
+ unsigned int pos[EDAC_MAX_LAYERS];
+ unsigned int size, tot_dimms = 1, count = 1;
+ unsigned int tot_csrows = 1, tot_channels = 1, tot_errcount = 0;
void *pvt, *p, *ptr = NULL;
int i, j, row, chn, n, len, off;
bool per_rank = false;
diff --git a/drivers/edac/edac_mc.h b/drivers/edac/edac_mc.h
index 4165e15995ad..02aac5c61d00 100644
--- a/drivers/edac/edac_mc.h
+++ b/drivers/edac/edac_mc.h
@@ -122,10 +122,10 @@ do {
\
* On success, return a pointer to struct mem_ctl_info pointer;
* %NULL otherwise
*/
-struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
- unsigned n_layers,
+struct mem_ctl_info *edac_mc_alloc(unsigned int mc_num,
+ unsigned int n_layers,
struct edac_mc_layer *layers,
- unsigned sz_pvt);
+ unsigned int sz_pvt);
/**
* edac_get_owner - Return the owner's mod_name of EDAC MC
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 4386ea4b9b5a..640b9419623e 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -200,7 +200,7 @@ static ssize_t channel_dimm_label_show(struct device *dev,
char *data)
{
struct csrow_info *csrow = to_csrow(dev);
- unsigned chan = to_channel(mattr);
+ unsigned int chan = to_channel(mattr);
struct rank_info *rank = csrow->channels[chan];
/* if field has not been initialized, there is nothing to send */
@@ -216,7 +216,7 @@ static ssize_t channel_dimm_label_store(struct device *dev,
const char *data, size_t count)
{
struct csrow_info *csrow = to_csrow(dev);
- unsigned chan = to_channel(mattr);
+ unsigned int chan = to_channel(mattr);
struct rank_info *rank = csrow->channels[chan];
size_t copy_count = count;
@@ -240,7 +240,7 @@ static ssize_t channel_ce_count_show(struct device *dev,
struct device_attribute *mattr, char *data)
{
struct csrow_info *csrow = to_csrow(dev);
- unsigned chan =
Re: [PATCH v4 04/11] device property: Add functions for accessing node's parents
Hi Andy,
On Mon, Sep 02, 2019 at 01:14:26PM +0300, Andy Shevchenko wrote:
> On Mon, Sep 02, 2019 at 11:32:33AM +0300, Sakari Ailus wrote:
> > Add two convenience functions for accessing node's parents:
> >
> > fwnode_count_parents() returns the number of parent nodes a given node
> > has. fwnode_get_nth_parent() returns node's parent at a given distance
> > from the node itself.
> >
>
> Much better now, thanks!
>
> Reviewed-by: Andy Shevchenko
>
> though one question below.
Thanks!
...
> > +/**
> > + * fwnode_get_nth_parent - Return an nth parent of a node
> > + * @fwnode: The node the parent of which is requested
> > + * @depth: Distance of the parent from the node
> > + *
> > + * Returns the nth parent of a node. If @depth is 0, the functionality is
> > + * equivalent to fwnode_handle_get(). For @depth == 1, it is
> > fwnode_get_parent()
> > + * and so on.
> > + *
> > + * The caller is responsible for calling fwnode_handle_put() for the
> > returned
> > + * node.
> > + */
> > +struct fwnode_handle *fwnode_get_nth_parent(struct fwnode_handle *fwnode,
> > + unsigned int depth)
> > +{
> > + unsigned int i;
> > +
> > + fwnode_handle_get(fwnode);
> > +
> > + for (i = 0; i < depth && fwnode; i++)
> > + fwnode = fwnode_get_next_parent(fwnode);
> > +
>
> If 'fnode == NULL' and 'i < depth', shan't we return some kind of error?
How about adding to the comment, after the first sentence of the
description:
If there is no parent at the requested depth, NULL is returned.
--
Sakari Ailus
sakari.ai...@linux.intel.com
[tip: x86/urgent] x86/uaccess: Don't leak the AC flags into __get_user() argument evaluation
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 9b8bd476e78e89c9ea26c3b435ad0201c3d7dbf5
Gitweb:
https://git.kernel.org/tip/9b8bd476e78e89c9ea26c3b435ad0201c3d7dbf5
Author:Peter Zijlstra
AuthorDate:Thu, 29 Aug 2019 10:24:45 +02:00
Committer: Peter Zijlstra
CommitterDate: Mon, 02 Sep 2019 14:22:38 +02:00
x86/uaccess: Don't leak the AC flags into __get_user() argument evaluation
Identical to __put_user(); the __get_user() argument evalution will too
leak UBSAN crud into the __uaccess_begin() / __uaccess_end() region.
While uncommon this was observed to happen for:
drivers/xen/gntdev.c: if (__get_user(old_status, batch->status[i]))
where UBSAN added array bound checking.
This complements commit:
6ae865615fc4 ("x86/uaccess: Dont leak the AC flag into __put_user() argument
evaluation")
Tested-by Sedat Dilek
Reported-by: Randy Dunlap
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Josh Poimboeuf
Reviewed-by: Thomas Gleixner
Cc: broo...@kernel.org
Cc: s...@canb.auug.org.au
Cc: a...@linux-foundation.org
Cc: Randy Dunlap
Cc: mho...@suse.cz
Cc: Josh Poimboeuf
Link:
https://lkml.kernel.org/r/20190829082445.gm2...@hirez.programming.kicks-ass.net
---
arch/x86/include/asm/uaccess.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 9c44353..35c225e 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -444,8 +444,10 @@ __pu_label:
\
({ \
int __gu_err; \
__inttype(*(ptr)) __gu_val; \
+ __typeof__(ptr) __gu_ptr = (ptr); \
+ __typeof__(size) __gu_size = (size);\
__uaccess_begin_nospec(); \
- __get_user_size(__gu_val, (ptr), (size), __gu_err, -EFAULT);\
+ __get_user_size(__gu_val, __gu_ptr, __gu_size, __gu_err, -EFAULT);
\
__uaccess_end();\
(x) = (__force __typeof__(*(ptr)))__gu_val; \
__builtin_expect(__gu_err, 0); \
[RESEND PATCH v3 6/7] backlight: gpio: remove def_value from struct gpio_backlight
From: Bartosz Golaszewski
This field is unused outside of probe(). There's no need to store it.
We can make it into a local variable.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
Reviewed-by: Linus Walleij
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/gpio_backlight.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index 70882556f047..cd6a75bca9cc 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -21,7 +21,6 @@
struct gpio_backlight {
struct device *fbdev;
struct gpio_desc *gpiod;
- int def_value;
};
static int gpio_backlight_update_status(struct backlight_device *bl)
@@ -61,7 +60,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
struct backlight_device *bl;
struct gpio_backlight *gbl;
enum gpiod_flags flags;
- int ret;
+ int ret, def_value;
gbl = devm_kzalloc(>dev, sizeof(*gbl), GFP_KERNEL);
if (gbl == NULL)
@@ -70,8 +69,8 @@ static int gpio_backlight_probe(struct platform_device *pdev)
if (pdata)
gbl->fbdev = pdata->fbdev;
- gbl->def_value = device_property_read_bool(>dev, "default-on");
- flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
+ def_value = device_property_read_bool(>dev, "default-on");
+ flags = def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
gbl->gpiod = devm_gpiod_get(>dev, NULL, flags);
if (IS_ERR(gbl->gpiod)) {
@@ -94,7 +93,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
return PTR_ERR(bl);
}
- bl->props.brightness = gbl->def_value;
+ bl->props.brightness = def_value;
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
--
2.21.0
[PATCH] keys: Fix missing null pointer check in request_key_auth_describe()
From: Hillf Danton
If a request_key authentication token key gets revoked, there's a window in
which request_key_auth_describe() can see it with a NULL payload - but it
makes no check for this and something like the following oops may occur:
BUG: Kernel NULL pointer dereference at 0x0038
Faulting instruction address: 0xc04ddf30
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [...] request_key_auth_describe+0x90/0xd0
LR [...] request_key_auth_describe+0x54/0xd0
Call Trace:
[...] request_key_auth_describe+0x54/0xd0 (unreliable)
[...] proc_keys_show+0x308/0x4c0
[...] seq_read+0x3d0/0x540
[...] proc_reg_read+0x90/0x110
[...] __vfs_read+0x3c/0x70
[...] vfs_read+0xb4/0x1b0
[...] ksys_read+0x7c/0x130
[...] system_call+0x5c/0x70
Fix this by checking for a NULL pointer when describing such a key.
Also make the read routine check for a NULL pointer to be on the safe side.
[DH: Modified to not take already-held rcu lock and modified to also check
in the read routine]
Fixes: 04c567d9313e ("[PATCH] Keys: Fix race between two instantiators of a
key")
Reported-by: Sachin Sant
Signed-off-by: Hillf Danton
Signed-off-by: David Howells
Tested-by: Sachin Sant
---
security/keys/request_key_auth.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/security/keys/request_key_auth.c b/security/keys/request_key_auth.c
index e73ec040e250..ecba39c93fd9 100644
--- a/security/keys/request_key_auth.c
+++ b/security/keys/request_key_auth.c
@@ -66,6 +66,9 @@ static void request_key_auth_describe(const struct key *key,
{
struct request_key_auth *rka = dereference_key_rcu(key);
+ if (!rka)
+ return;
+
seq_puts(m, "key:");
seq_puts(m, key->description);
if (key_is_positive(key))
@@ -83,6 +86,9 @@ static long request_key_auth_read(const struct key *key,
size_t datalen;
long ret;
+ if (!rka)
+ return -EKEYREVOKED;
+
datalen = rka->callout_len;
ret = datalen;
Re: [PATCH] arm64: use x22 to save boot exception level
On Fri, Aug 30, 2019 at 03:23:53PM -0400, Andrew F. Davis wrote: > On 8/29/19 5:47 AM, Mark Rutland wrote: > > On Wed, Aug 28, 2019 at 01:33:18PM -0400, Andrew F. Davis wrote: > We are seeing is a write-back from L3 cache. Our bootloader writes the > kernel image with caches on, then after turning off caching but before > handing off to Linux it clean/invalidates all cache lines by set/way. > This cleans out the L1/L2 but leaves dirty lines in L3. Our platform > doesn't really have a good way to clean L3 as it only provides cache > maintenance operations by VA, not by line, so we would need to clean > every VA address manually.. Ensuring that the Image is clean to the PoC is required by the arm64 boot protocol, which states that maintenance by VA may be necessary in the presence of a system cache. See: https://www.kernel.org/doc/html/latest/arm64/booting.html ... which states: | The MMU must be off. Instruction cache may be on or off. The address | range corresponding to the loaded kernel image must be cleaned to the | PoC. In the presence of a system cache or other coherent masters with | caches enabled, this will typically require cache maintenance by VA | rather than set/way operations. Please fix your bootloader to meet this requirement. The kernel is not in a position to fix this up, e.g. as while the MMU is off instruction fetches could fetch stale data from the PoC. You only need to clean the kernel Image to the PoC, rather than all of memory, so you should be able to do that with a loop of DC CVAC instructions covering the VA range of the kernel Image. > Also want to point out, although this isn't a problem for most platforms > what this code does here, with writing to a location as non-cacheable, > is not architecturally safe as the running cores that do the reads have > this section marked as cacheable when they read, therefor you have > mismatched attributes. When this happens like this according to the ARM > ARM we should do a cache invalidate after the write *and* before the > > I would like to work this fix from the U-Boot side also, but in parallel > I would like to reduce the mismatched attributes as much as possible on > the kernel side like done here. So yes, we still will have issue with > __early_cpu_boot_status, but that only seems to be needed in the failure > to boot case, I'd like to fix that up as well at some later point. If you haven't cleaned the Image to the PoC, there's no guarantee that any portion of it can be safely executed with the MMU off, so I don't think that makes sense -- please fix your bootloader first. I am aware that there are potential problems with mismatched attributes, the primary issue here being unexpected-data-cache-hit. However, were that to occur no amount of cache maintenance can save us in the presence of a live cacheable alias. Practically speaking that's mainly a problem for virtual environments. Thanks, Mark.
Re: [PATCH] ASoC: fsl_sai: Set SAI Channel Mode to Output Mode
On Sat, Aug 31, 2019 at 01:55:14AM +0300, Daniel Baluta wrote: > Fix this by setting CHMOD to Output Mode so that pins will output zero > when slots are masked or channels are disabled. This patch seems to do this unconditionally. This is fine for configurations where the SoC is the only thing driving the bus but will mean that for TDM configurations where something else also drives some of the slots we'll end up with both devices driving simultaneously. The safest thing would be to set this only if TDM isn't configured. signature.asc Description: PGP signature
linux-next: Tree for Sep 2
Hi all,
News: I will only be doing 2 more releases before I leave for Kernel
Summit (there may be some reports on Thursday, but I doubt I will have
time to finish the full release) and then no more until Sept 30.
Changes since 20190830:
The compiler-attributes tree lost its build failure.
The powerpc tree gained a conflict against the arm64 tree. Also a build
failure due to an interaction with the dma-mapping tree.
The afs tree gained conflicts against the net tree.
The pci tree lost its build failure.
The net-next tree lost its build failure.
The sound-asoc tree gained a conflict against the jc_docs tree.
The regulator tree lost its build failure.
The keys tree still has its build failure but I changed to applying a
fix patch.
The iommu tree gained a build failure for which I reverted a commit.
The tip tree gained conflicts against Linus' tree.
The hmm tree gained a build failure for which I reverted a commit.
The akpm-current tree gained a conflict against the risc-v tree.
Non-merge commits (relative to Linus' tree): 9928
9748 files changed, 583587 insertions(+), 269559 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 310 trees (counting Linus' and 77 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (9f159ae07f07 Merge branch 'x86-urgent-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (609488bc979f Linux 5.3-rc2)
Merging kbuild-current/fixes (d45331b00ddb Linux 5.3-rc4)
Merging arc-current/for-curr (2f029413cbfb arc: prefer __section from
compiler_attributes.h)
Merging arm-current/fixes (5b3efa4f1479 ARM: 8901/1: add a criteria for
pfn_valid of arm)
Merging arm-soc-fixes/arm/fixes (7a6c9dbb36a4 soc: ixp4xx: Protect IXP4xx SoC
drivers by ARCH_IXP4XX || COMPILE_TEST)
Merging arm64-fixes/for-next/fixes (82e40f558de5 KVM: arm/arm64: vgic-v2:
Handle SGI bits in GICD_I{S,C}PENDR0 as WI)
Merging m68k-current/for-linus (f28a1f16135c m68k: Don't select
ARCH_HAS_DMA_PREP_COHERENT for nommu or coldfire)
Merging powerpc-fixes/fixes (b9ee5e04fd77 powerpc/64e: Drop stale call to
smp_processor_id() which hangs SMP startup)
Merging s390-fixes/fixes (d45331b00ddb Linux 5.3-rc4)
Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (e1e54ec7fb55 net: seeq: Fix the function used to release
some memory in an error handling path)
Merging bpf/master (ede7c460b1da bpf: handle 32-bit zext during constant
blinding)
Merging ipsec/master (769a807d0b41 xfrm: policy: avoid warning splat when
merging nodes)
Merging netfilter/master (c3d7a089f945 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (58e8b37069ff Merge branch 'net-phy-dp83867-add-some-fixes')
Merging wireless-drivers/master (5a8c31aa6357 iwlwifi: pcie: fix recognition of
QuZ devices)
Merging mac80211/master (869326532956 Merge tag 'mac80211-for-davem-2019-08-29'
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging rdma-fixes/for-rc (531a64e4c35b RDMA/siw: Fix IPv6 addr_list locking)
Merging sound-current/for-linus (89781d0806c2 ALSA: hda/realtek - Fix
overridden device-specific initialization)
Merging sound-asoc-fixes/for-linus (2803b0e5da24 Merge
[PATCH V2] x86/Hyper-V: Fix overflow issue in the fill_gva_list()
From: Tianyu Lan
When the 'start' parameter is >= 0xFF00 on 32-bit
systems, or >= 0x'FF00 on 64-bit systems,
fill_gva_list gets into an infinite loop. With such inputs,
'cur' overflows after adding HV_TLB_FLUSH_UNIT and always
compares as less than end. Memory is filled with guest virtual
addresses until the system crashes
Fix this by never incrementing 'cur' to be larger than 'end'.
Reported-by: Jong Hyun Park
Signed-off-by: Tianyu Lan
Fixes: 2ffd9e33ce4a ("x86/hyper-v: Use hypercall for remote TLB flush")
---
Change since v1:
- Simply the commit message
arch/x86/hyperv/mmu.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index e65d7fe6489f..5208ba49c89a 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -37,12 +37,14 @@ static inline int fill_gva_list(u64 gva_list[], int offset,
* Lower 12 bits encode the number of additional
* pages to flush (in addition to the 'cur' page).
*/
- if (diff >= HV_TLB_FLUSH_UNIT)
+ if (diff >= HV_TLB_FLUSH_UNIT) {
gva_list[gva_n] |= ~PAGE_MASK;
- else if (diff)
+ cur += HV_TLB_FLUSH_UNIT;
+ } else if (diff) {
gva_list[gva_n] |= (diff - 1) >> PAGE_SHIFT;
+ cur = end;
+ }
- cur += HV_TLB_FLUSH_UNIT;
gva_n++;
} while (cur < end);
--
2.14.5
[PATCH 4/5] drm/qxl: use drm_gem_object_funcs callbacks
Switch qxl to use drm_gem_object_funcs callbacks
instead of drm_driver callbacks.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c| 8
drivers/gpu/drm/qxl/qxl_object.c | 12
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 2b726a51a302..996d428fa7e6 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -258,16 +258,8 @@ static struct drm_driver qxl_driver = {
#endif
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_pin = qxl_gem_prime_pin,
- .gem_prime_unpin = qxl_gem_prime_unpin,
- .gem_prime_get_sg_table = qxl_gem_prime_get_sg_table,
.gem_prime_import_sg_table = qxl_gem_prime_import_sg_table,
- .gem_prime_vmap = qxl_gem_prime_vmap,
- .gem_prime_vunmap = qxl_gem_prime_vunmap,
.gem_prime_mmap = qxl_gem_prime_mmap,
- .gem_free_object_unlocked = qxl_gem_object_free,
- .gem_open_object = qxl_gem_object_open,
- .gem_close_object = qxl_gem_object_close,
.fops = _fops,
.ioctls = qxl_ioctls,
.irq_handler = qxl_irq_handler,
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index 548dfe6f3b26..29aab7b14513 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -77,6 +77,17 @@ void qxl_ttm_placement_from_domain(struct qxl_bo *qbo, u32
domain, bool pinned)
}
}
+static const struct drm_gem_object_funcs qxl_object_funcs = {
+ .free = qxl_gem_object_free,
+ .open = qxl_gem_object_open,
+ .close = qxl_gem_object_close,
+ .pin = qxl_gem_prime_pin,
+ .unpin = qxl_gem_prime_unpin,
+ .get_sg_table = qxl_gem_prime_get_sg_table,
+ .vmap = qxl_gem_prime_vmap,
+ .vunmap = qxl_gem_prime_vunmap,
+};
+
int qxl_bo_create(struct qxl_device *qdev,
unsigned long size, bool kernel, bool pinned, u32 domain,
struct qxl_surface *surf,
@@ -100,6 +111,7 @@ int qxl_bo_create(struct qxl_device *qdev,
kfree(bo);
return r;
}
+ bo->tbo.base.funcs = _object_funcs;
bo->type = domain;
bo->pin_count = pinned ? 1 : 0;
bo->surface_id = 0;
--
2.18.1
[PATCH] video/fbdev/68328fb: Remove dead code
This is dead code since 3.15. If their is no plan to
use it further, these can be removed forever.
Signed-off-by: Souptick Joarder
---
drivers/video/fbdev/68328fb.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/video/fbdev/68328fb.c b/drivers/video/fbdev/68328fb.c
index d48e960..02d22b7 100644
--- a/drivers/video/fbdev/68328fb.c
+++ b/drivers/video/fbdev/68328fb.c
@@ -405,20 +405,8 @@ static int mc68x328fb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
int __init mc68x328fb_setup(char *options)
{
-#if 0
- char *this_opt;
-#endif
-
if (!options || !*options)
return 1;
-#if 0
- while ((this_opt = strsep(, ",")) != NULL) {
- if (!*this_opt)
- continue;
- if (!strncmp(this_opt, "disable", 7))
- mc68x328fb_enable = 0;
- }
-#endif
return 1;
}
--
1.9.1
[PATCH v3 1/2] gpio: acpi: add quirk to override GpioInt polarity
On GPD P2 Max, the firmware could not reset the touch panel correctly.
The kernel needs to take on the job instead, but the GpioInt definition
in DSDT specifies ActiveHigh while the GPIO pin should actually be
ActiveLow.
We need to override the polarity defined by DSDT. The GPIO driver
already allows defining polarity in acpi_gpio_params, but the option is
not applied to GpioInt.
This patch adds a new quirk that enables the polarity specified in
acpi_gpio_params to also be applied to GpioInt.
Signed-off-by: Peter Cai
Acked-by: Andy Shevchenko
---
v2: rebased to gpio/for-next, moved quirk out of the gpioint
conditional.
v3: no change, series update.
---
drivers/gpio/gpiolib-acpi.c | 9 +
include/linux/gpio/consumer.h | 6 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index fdee8afa5339..ab16ea61a8fa 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -603,6 +603,15 @@ static int acpi_populate_gpio_lookup(struct acpi_resource
*ares, void *data)
lookup->info.flags = acpi_gpio_to_gpiod_flags(agpio);
lookup->info.polarity = lookup->active_low;
}
+
+ /*
+* Override the polarity specified by GpioInt if
+* ACPI_GPIO_QUIRK_OVERRIDE_POLARITY is set.
+*/
+ if (lookup->info.quirks & ACPI_GPIO_QUIRK_OVERRIDE_POLARITY) {
+ dev_warn(>info.adev->dev, FW_BUG "Incorrect
polarity specified by GpioInt, overriding.\n");
+ lookup->info.polarity = lookup->active_low;
+ }
}
return 1;
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index b70af921c614..7e9f24ebb085 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -622,6 +622,12 @@ struct acpi_gpio_mapping {
* get GpioIo type explicitly, this quirk may be used.
*/
#define ACPI_GPIO_QUIRK_ONLY_GPIOIOBIT(1)
+/*
+ * Use the GPIO polarity (ActiveHigh / ActiveLow) from acpi_gpio_params
+ * for GpioInt as well. The default behavior is to use the one specified
+ * by GpioInt, which can be incorrect on some devices.
+ */
+#define ACPI_GPIO_QUIRK_OVERRIDE_POLARITY BIT(2)
unsigned int quirks;
};
--
2.23.0
Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
On Mon, Sep 02, 2019 at 11:17:14AM +0800, Xiaowei Bao wrote:
> Add PCIe EP mode support for ls1088a and ls2088a, there are some
> difference between LS1 and LS2 platform, so refactor the code of
> the EP driver.
>
> Signed-off-by: Xiaowei Bao
> ---
> v2:
> - This is a new patch for supporting the ls1088a and ls2088a platform.
> v3:
> - Adjust the some struct assignment order in probe function.
>
> drivers/pci/controller/dwc/pci-layerscape-ep.c | 72
> +++---
> 1 file changed, 53 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index 5f0cb99..723bbe5 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -20,27 +20,29 @@
>
> #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
>
> -struct ls_pcie_ep {
> - struct dw_pcie *pci;
> - struct pci_epc_features *ls_epc;
> +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> +
> +struct ls_pcie_ep_drvdata {
> + u32 func_offset;
> + const struct dw_pcie_ep_ops *ops;
> + const struct dw_pcie_ops*dw_pcie_ops;
> };
>
> -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> +struct ls_pcie_ep {
> + struct dw_pcie *pci;
> + struct pci_epc_features *ls_epc;
> + const struct ls_pcie_ep_drvdata *drvdata;
> +};
>
> static int ls_pcie_establish_link(struct dw_pcie *pci)
> {
> return 0;
> }
>
> -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> .start_link = ls_pcie_establish_link,
> };
>
> -static const struct of_device_id ls_pcie_ep_of_match[] = {
> - { .compatible = "fsl,ls-pcie-ep",},
> - { },
> -};
> -
> static const struct pci_epc_features*
> ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
> {
> @@ -87,10 +89,39 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8
> func_no,
> }
> }
>
> -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> + u8 func_no)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> +
> + WARN_ON(func_no && !pcie->drvdata->func_offset);
> + return pcie->drvdata->func_offset * func_no;
> +}
> +
> +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> .ep_init = ls_pcie_ep_init,
> .raise_irq = ls_pcie_ep_raise_irq,
> .get_features = ls_pcie_ep_get_features,
> + .func_conf_select = ls_pcie_ep_func_conf_select,
> +};
> +
> +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> + .ops = _pcie_ep_ops,
> + .dw_pcie_ops = _ls_pcie_ep_ops,
> +};
> +
> +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> + .func_offset = 0x2,
> + .ops = _pcie_ep_ops,
> + .dw_pcie_ops = _ls_pcie_ep_ops,
> +};
> +
> +static const struct of_device_id ls_pcie_ep_of_match[] = {
> + { .compatible = "fsl,ls1046a-pcie-ep", .data = _ep_drvdata },
> + { .compatible = "fsl,ls1088a-pcie-ep", .data = _ep_drvdata },
> + { .compatible = "fsl,ls2088a-pcie-ep", .data = _ep_drvdata },
> + { },
This removes support for "fsl,ls-pcie-ep" - was that intentional? If you do
plan to drop it please make sure you explain why in the commit message. See
also my comments in your dt-binding patch.
Thanks,
Andrew Murray
> };
>
> static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
> @@ -103,7 +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
> int ret;
>
> ep = >ep;
> - ep->ops = _ep_ops;
> + ep->ops = pcie->drvdata->ops;
>
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
> if (!res)
> @@ -142,20 +173,23 @@ static int __init ls_pcie_ep_probe(struct
> platform_device *pdev)
> if (!ls_epc)
> return -ENOMEM;
>
> - dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> - pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> - if (IS_ERR(pci->dbi_base))
> - return PTR_ERR(pci->dbi_base);
> + pcie->drvdata = of_device_get_match_data(dev);
>
> - pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> pci->dev = dev;
> - pci->ops = _pcie_ep_ops;
> - pcie->pci = pci;
> + pci->ops = pcie->drvdata->dw_pcie_ops;
>
> ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
>
> + pcie->pci = pci;
> pcie->ls_epc = ls_epc;
>
> + dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> + pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> + if (IS_ERR(pci->dbi_base))
> + return PTR_ERR(pci->dbi_base);
> +
> + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> +
>
[PATCH v3 2/2] touchscreen: goodix: define GPIO mapping for GPD P2 Max
The firmware of GPD P2 Max could not handle panel resets although code
is present in DSDT. The kernel needs to take on this job instead, but
the DSDT does not provide _DSD, rendering kernel helpless when trying to
find the respective GPIO pins.
Fortunately, this time GPD has proper DMI vendor / product strings that
we could match against. We simply apply an acpi_gpio_mapping table when
GPD P2 Max is matched.
Additionally, the DSDT definition of the irq pin specifies a wrong
polarity. The new quirk introduced in the previous patch
(ACPI_GPIO_QUIRK_OVERRIDE_POLARITY) is applied to correct this.
Signed-off-by: Peter Cai
Reviewed-by: Andy Shevchenko
---
v2: removed '#ifdef CONFIG_ACPI' as per suggestion. The #ifdef guards
for CONFIG_DMI is kept for consistency with the other dmi_system_id
definition in the same file.
v3: minor style adjustments. Added 'const' to dmi_match and moved it in
reverse xmas tree order as per suggestion.
---
drivers/input/touchscreen/goodix.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index 5178ea8b5f30..49ce478c1134 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -144,6 +144,31 @@ static const struct dmi_system_id rotated_screen[] = {
{}
};
+static const struct acpi_gpio_params irq_gpios_default = { 0, 0, false };
+static const struct acpi_gpio_params reset_gpios_default = { 1, 0, false };
+static const struct acpi_gpio_mapping gpio_mapping_force_irq_active_high[] = {
+ { "irq-gpios", _gpios_default, 1, ACPI_GPIO_QUIRK_OVERRIDE_POLARITY
},
+ { "reset-gpios", _gpios_default, 1 },
+ {}
+};
+
+/*
+ * Devices that need acpi_gpio_mapping to function correctly
+ */
+static const struct dmi_system_id need_gpio_mapping[] = {
+#if defined(CONFIG_DMI) && defined(CONFIG_X86)
+ {
+ .ident = "GPD P2 Max",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GPD"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P2 MAX")
+ },
+ .driver_data = _mapping_force_irq_active_high
+ },
+#endif
+ {}
+};
+
/**
* goodix_i2c_read - read data from a register of the i2c slave device.
*
@@ -793,9 +818,15 @@ static void goodix_disable_regulators(void *arg)
static int goodix_ts_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ const struct dmi_system_id *dmi_match;
struct goodix_ts_data *ts;
int error;
+ dmi_match = dmi_first_match(need_gpio_mapping);
+ if (dmi_match)
+ devm_acpi_dev_add_driver_gpios(>dev,
+ dmi_match->driver_data);
+
dev_dbg(>dev, "I2C Address: 0x%02x\n", client->addr);
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
--
2.23.0
Re: [PATCH v4 04/11] device property: Add functions for accessing node's parents
On Mon, Sep 02, 2019 at 03:34:31PM +0300, Sakari Ailus wrote:
> Hi Andy,
>
> On Mon, Sep 02, 2019 at 01:14:26PM +0300, Andy Shevchenko wrote:
> > On Mon, Sep 02, 2019 at 11:32:33AM +0300, Sakari Ailus wrote:
> > > Add two convenience functions for accessing node's parents:
> > >
> > > fwnode_count_parents() returns the number of parent nodes a given node
> > > has. fwnode_get_nth_parent() returns node's parent at a given distance
> > > from the node itself.
> > >
> >
> > Much better now, thanks!
> >
> > Reviewed-by: Andy Shevchenko
> >
> > though one question below.
> > > +/**
> > > + * fwnode_get_nth_parent - Return an nth parent of a node
> > > + * @fwnode: The node the parent of which is requested
> > > + * @depth: Distance of the parent from the node
> > > + *
> > > + * Returns the nth parent of a node. If @depth is 0, the functionality is
> > > + * equivalent to fwnode_handle_get(). For @depth == 1, it is
> > > fwnode_get_parent()
> > > + * and so on.
> > > + *
> > > + * The caller is responsible for calling fwnode_handle_put() for the
> > > returned
> > > + * node.
> > > + */
> > > +struct fwnode_handle *fwnode_get_nth_parent(struct fwnode_handle *fwnode,
> > > + unsigned int depth)
> > > +{
> > > + unsigned int i;
> > > +
> > > + fwnode_handle_get(fwnode);
> > > +
> > > + for (i = 0; i < depth && fwnode; i++)
> > > + fwnode = fwnode_get_next_parent(fwnode);
> > > +
> >
> > If 'fnode == NULL' and 'i < depth', shan't we return some kind of error?
>
> How about adding to the comment, after the first sentence of the
> description:
>
> If there is no parent at the requested depth, NULL is returned.
Works for me!
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] x86/Hyper-V: Fix overflow issue in the fill_gva_list()
On Sat, Aug 31, 2019 at 1:41 AM Michael Kelley wrote:
>
> From: lantianyu1...@gmail.com Sent: Thursday, August 29, 2019 11:16 PM
> >
> > From: Tianyu Lan
> >
> > fill_gva_list() populates gva list and adds offset
> > HV_TLB_FLUSH_UNIT(0x100) to variable "cur"
> > in the each loop. When diff between "end" and "cur" is
> > less than HV_TLB_FLUSH_UNIT, the gva entry should
> > be the last one and the loop should be end.
> >
> > If cur is equal or greater than 0xFF00 on 32-bit
> > mode, "cur" will be overflow after adding HV_TLB_FLUSH_UNIT.
> > Its value will be wrapped and less than "end". fill_gva_list()
> > falls into an infinite loop and fill gva list out of
> > border finally.
> >
> > Set "cur" to be "end" to make loop end when diff is
> > less than HV_TLB_FLUSH_UNIT and add HV_TLB_FLUSH_UNIT to
> > "cur" when diff is equal or greater than HV_TLB_FLUSH_UNIT.
> > Fix the overflow issue.
>
> Let me suggest simplifying the commit message a bit. It
> doesn't need to describe every line of the code change. I think
> it should also make clear that the same problem could occur on
> 64-bit systems with the right "start" address. My suggestion:
>
> When the 'start' parameter is >= 0xFF00 on 32-bit
> systems, or >= 0x'FF00 on 64-bit systems,
> fill_gva_list gets into an infinite loop. With such inputs,
> 'cur' overflows after adding HV_TLB_FLUSH_UNIT and always
> compares as less than end. Memory is filled with guest virtual
> addresses until the system crashes
>
> Fix this by never incrementing 'cur' to be larger than 'end'.
>
> >
> > Reported-by: Jong Hyun Park
> > Signed-off-by: Tianyu Lan
> > Fixes: 2ffd9e33ce4a ("x86/hyper-v: Use hypercall for remote
> > TLB flush")
>
> The "Fixes:" line needs to not wrap. It's exempt from the
> "wrap at 75 columns" rule in order to simplify parsing scripts.
>
> The code itself looks good.
Hi Michael:
Thanks for suggestion. Update commit log in V2.
--
Best regards
Tianyu Lan
Re: [RFC 7/9] dt-bindings: rtc: s3c: Convert S3C/Exynos RTC bindings to json-schema
On Mon, 26 Aug 2019 at 14:06, Rob Herring wrote: > > On Fri, Aug 23, 2019 at 9:54 AM Krzysztof Kozlowski wrote: > > > > Convert Samsung S3C/Exynos Real Time Clock bindings to DT schema format > > using json-schema. > > > > Signed-off-by: Krzysztof Kozlowski > > --- > > .../devicetree/bindings/rtc/s3c-rtc.txt | 31 -- > > .../devicetree/bindings/rtc/s3c-rtc.yaml | 95 +++ > > 2 files changed, 95 insertions(+), 31 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/rtc/s3c-rtc.txt > > create mode 100644 Documentation/devicetree/bindings/rtc/s3c-rtc.yaml > > > > diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml > > b/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml > > new file mode 100644 > > index ..44b021812a83 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml > > @@ -0,0 +1,95 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/rtc/s3c-rtc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Samsung S3C, S5P and Exynos Real Time Clock controller > > + > > +maintainers: > > + - Krzysztof Kozlowski > > + > > +# Select also deprecated compatibles (for finding deprecate usage) > > +select: > > + properties: > > +compatible: > > + items: > > +- enum: > > +- samsung,s3c2410-rtc > > +- samsung,s3c2416-rtc > > +- samsung,s3c2443-rtc > > +- samsung,s3c6410-rtc > > +# Deprecated, use samsung,s3c6410-rtc > > +- samsung,exynos3250-rtc > > We've come up with a better way of doing this that doesn't need a > custom 'select'. Add a 'oneOf' to compatible and add another entry: > > - const: samsung,exynos3250-rtc > deprecated: true > > It's not implemented yet in the tool, but we'll keep the compatible > for 'select' and otherwise drop schema marked deprecated. OK > > > + required: > > +- compatible > > + > > +properties: > > + compatible: > > +items: > > + - enum: > > You can drop 'items' when there's only 1 entry. Indeed. > > > + - samsung,s3c2410-rtc > > + - samsung,s3c2416-rtc > > + - samsung,s3c2443-rtc > > + - samsung,s3c6410-rtc > > + reg: > > +maxItems: 1 > > + > > + clocks: > > +description: > > + Must contain a list of phandle and clock specifier for the rtc > > + clock and in the case of a s3c6410 compatible controller, also > > + a source clock. > > +minItems: 1 > > +maxItems: 2 > > + > > + clock-names: > > +description: > > + Must contain "rtc" and for a s3c6410 compatible controller, > > + a "rtc_src" sorted in the same order as the clocks property. > > +oneOf: > > + - items: > > + - const: rtc > > + - items: > > + # TODO: This can be in any order matching clocks, how to express > > it? > > It shouldn't be in any order. Fix the dts files. I see, other schemas also require specific ordering. > > > + - const: rtc > > + - const: rtc_src > > You should drop all this and add an else clause below. Yes > > > + > > + interrupts: > > +description: > > + Two interrupt numbers to the cpu should be specified. First > > + interrupt number is the rtc alarm interrupt and second interrupt > > number > > + is the rtc tick interrupt. The number of cells representing a > > interrupt > > + depends on the parent interrupt controller. > > +minItems: 2 > > +maxItems: 2 > > + > > +allOf: > > + - if: > > + properties: > > +compatible: > > + contains: > > +enum: > > + - samsung,s3c6410-rtc > > + - samsung,exynos3250-rtc > > + > > +then: > > + properties: > > +clocks: > > + minItems: 2 > > + maxItems: 2 > > +clock-names: > > + items: > > + - const: rtc > > + - const: rtc_src > > Should be indented 2 more spaces. Thanks for feedback. Best regards, Krzysztof
Re: [PATCH v2] kunit: fix failure to build without printk
On Fri 2019-08-30 16:37:10, Brendan Higgins wrote:
> On Fri, Aug 30, 2019 at 11:22:43PM +, tim.b...@sony.com wrote:
> > > -Original Message-
> > > From: Brendan Higgins
> > >
> > > On Fri, Aug 30, 2019 at 3:46 PM Joe Perches wrote:
> > > >
> > > > On Fri, 2019-08-30 at 21:58 +, tim.b...@sony.com wrote:
> > > > > > From: Joe Perches
> > > > []
> > > > > IMHO %pV should be avoided if possible. Just because people are
> > > > > doing it doesn't mean it should be used when it is not necessary.
> > > >
> > > > Well, as the guy that created %pV, I of course
> > > > have a different opinion.
> > > >
> > > > > > then wouldn't it be easier to pass in the
> > > > > > > kernel level as a separate parameter and then strip off all printk
> > > > > > > headers like this:
> > > > > >
> > > > > > Depends on whether or not you care for overall
> > > > > > object size. Consolidated formats with the
> > > > > > embedded KERN_ like suggested are smaller
> > > > > > overall object size.
> > > > >
> > > > > This is an argument I can agree with. I'm generally in favor of
> > > > > things that lessen kernel size creep. :-)
> > > >
> > > > As am I.
> > >
> > > Sorry, to be clear, we are talking about the object size penalty due
> > > to adding a single parameter to a function. Is that right?
> >
> > Not exactly. The argument is that pre-pending the different KERN_LEVEL
> > strings onto format strings can result in several versions of nearly
> > identical strings
> > being compiled into the object file. By parameterizing this (that is,
> > adding
> > '%s' into the format string, and putting the level into the string as an
> > argument),
> > it prevents this duplication of format strings.
> >
> > I haven't seen the data on duplication of format strings, and how much this
> > affects it, but little things can add up. Whether it matters in this case
> > depends
> > on whether the format strings that kunit uses are also used elsewhere in
> > the kernel,
> > and whether these same format strings are used with multiple kernel message
> > levels.
> > -- Tim
>
> I thought this portion of the discussion was about whether Joe's version
> of kunit_printk was better or my critique of his version of kunit_printk:
>
> Joe's:
> > > > > -void kunit_printk(const char *level,
> > > > > - const struct kunit *test,
> > > > > - const char *fmt, ...)
> > > > > +void kunit_printk(const struct kunit *test, const char *fmt, ...)
> > > > > {
> > > > > + char lvl[PRINTK_MAX_SINGLE_HEADER_LEN + 1] = "\0";
> > > > > struct va_format vaf;
> > > > > va_list args;
> > > > > + int kern_level;
> > > > >
> > > > > va_start(args, fmt);
> > > > >
> > > > > + while ((kern_level = printk_get_level(fmt)) != 0) {
> > > > > + size_t size = printk_skip_level(fmt) - fmt;
> > > > > +
> > > > > + if (kern_level >= '0' && kern_level <= '7') {
> > > > > + memcpy(lvl, fmt, size);
> > > > > + lvl[size] = '\0';
> > > > > + }
> > > > > + fmt += size;
> > > > > + }
> > > > > +
> > > > > vaf.fmt = fmt;
> > > > > vaf.va =
> > > > >
> > > > > - kunit_vprintk(test, level, );
> > > > > + printk("%s\t# %s %pV\n", lvl, test->name, );
> > > > >
> > > > > va_end(args);
> > > > > }
>
> Mine:
> > void kunit_printk(const char *level,
> > const struct kunit *test,
> > const char *fmt, ...)
> > {
> > struct va_format vaf;
> > va_list args;
> >
> > va_start(args, fmt);
> >
> > + fmt = printk_skip_headers(fmt);
> > +
> > vaf.fmt = fmt;
> > vaf.va =
> >
> > - kunit_vprintk(test, level, );
> > + printk("%s\t# %s %pV\n", level, test->name, );
> >
> > va_end(args);
> > }
>
> I thought you and Joe were arguing that "Joe's" resulted in a smaller
> object size than "Mine" (not to be confused with the actual patch I
> presented here, which is what Sergey suggested I do on a different
> thread).
>
> I really don't feel strongly about what Sergey suggested I do (which is
> what this patch originally introduced), versus, what Joe suggested,
> versus what I suggested in response to Joe (or any of the things
> suggested on other threads). I just want to pick one, fix the breakage
> in linux-next, and move on with my life.
I am a bit lost in all the versions ;-) Though, I like most this
patch. I think that it is based on Sergey's suggestion.
I think that object size is not a huge concern for unit testing.
Also if I get it correctly, the object is bigger only when
the same string is used with different log levels. I am not
sure how often this happen.
Feel free to use for this patch:
Reviewed-by: Petr Mladek
Best Regards,
Petr
> Cheers
Re: [PATCH v6 05/24] erofs: add inode operations
On Sun, Sep 01, 2019 at 05:34:00PM +0800, Gao Xiang wrote: > > > + return iget5_locked(sb, hashval, erofs_ilookup_test_actor, > > > + erofs_iget_set_actor, ); > > > +#endif > > > > Just use the slightly more complicated 32-bit version everywhere so that > > you have a single actually tested code path. And then remove this > > helper. > > As I said before, 64-bit platforms is common currently, > I think iget_locked is enough. > https://lore.kernel.org/r/20190830184606.GA175612@architecture4/ The problem with that is that you now have two entirely different code paths. And the 32-bit one will probably get very little testing and eventually bitrot. We defintively had problems of that sort in XFS in the past, so my suggestion is to not go down the root of separate code for 32-bit vs 64-bit unless it makes a real difference for a real-life workload.
Re: [PATCH v4 01/10] KVM: arm64: Document PV-time interface
On Fri, Aug 30, 2019 at 04:25:08PM +0100, Steven Price wrote: > On 30/08/2019 15:47, Andrew Jones wrote: > > On Fri, Aug 30, 2019 at 09:42:46AM +0100, Steven Price wrote: > >> Introduce a paravirtualization interface for KVM/arm64 based on the > >> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A. > >> > >> This only adds the details about "Stolen Time" as the details of "Live > >> Physical Time" have not been fully agreed. > >> > >> User space can specify a reserved area of memory for the guest and > >> inform KVM to populate the memory with information on time that the host > >> kernel has stolen from the guest. > >> > >> A hypercall interface is provided for the guest to interrogate the > >> hypervisor's support for this interface and the location of the shared > >> memory structures. > >> > >> Signed-off-by: Steven Price > >> --- > >> Documentation/virt/kvm/arm/pvtime.txt | 64 + > >> Documentation/virt/kvm/devices/vcpu.txt | 14 ++ > >> 2 files changed, 78 insertions(+) > >> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt > >> > >> diff --git a/Documentation/virt/kvm/arm/pvtime.txt > >> b/Documentation/virt/kvm/arm/pvtime.txt > >> new file mode 100644 > >> index ..dda3f0f855b9 > >> --- /dev/null > >> +++ b/Documentation/virt/kvm/arm/pvtime.txt > >> @@ -0,0 +1,64 @@ > >> +Paravirtualized time support for arm64 > >> +== > >> + > >> +Arm specification DEN0057/A defined a standard for paravirtualised time > >> +support for AArch64 guests: > >> + > >> +https://developer.arm.com/docs/den0057/a > >> + > >> +KVM/arm64 implements the stolen time part of this specification by > >> providing > >> +some hypervisor service calls to support a paravirtualized guest > >> obtaining a > >> +view of the amount of time stolen from its execution. > >> + > >> +Two new SMCCC compatible hypercalls are defined: > >> + > >> +PV_FEATURES 0xC520 > >> +PV_TIME_ST 0xC522 > >> + > >> +These are only available in the SMC64/HVC64 calling convention as > >> +paravirtualized time is not available to 32 bit Arm guests. The existence > >> of > >> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 > >> ARCH_FEATURES > >> +mechanism before calling it. > >> + > >> +PV_FEATURES > >> +Function ID: (uint32) : 0xC520 > >> +PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST > > > > PV_TIME_LPT doesn't exist > > Thanks, will remove. > > >> +Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the > >> relevant > >> + PV-time feature is supported by the > >> hypervisor. > >> + > >> +PV_TIME_ST > >> +Function ID: (uint32) : 0xC522 > >> +Return value: (int64) : IPA of the stolen time data structure for > >> this > >> + VCPU. On failure: > >> + NOT_SUPPORTED (-1) > >> + > >> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal > >> memory > >> +with inner and outer write back caching attributes, in the inner shareable > >> +domain. A total of 16 bytes from the IPA returned are guaranteed to be > >> +meaningfully filled by the hypervisor (see structure below). > >> + > >> +PV_TIME_ST returns the structure for the calling VCPU. > >> + > >> +Stolen Time > >> +--- > >> + > >> +The structure pointed to by the PV_TIME_ST hypercall is as follows: > >> + > >> + Field | Byte Length | Byte Offset | Description > >> + --- | --- | --- | -- > >> + Revision| 4 | 0 | Must be 0 for version 0.1 > >> + Attributes | 4 | 4 | Must be 0 > > > > The above fields don't appear to be exposed to userspace in anyway. How > > will we handle migration from one KVM with one version of the structure > > to another? > > Interesting question. User space does have access to them now it is > providing the memory, but it's not exactly an easy method. In particular > user space has no (simple) way of probing the kernel's supported version. > > I guess one solution would be to add an extra attribute on the VCPU > which would provide the revision information. The current kernel would > then reject any revision other than 0, but this could then be extended > to support other revision numbers in the future. > > Although there's some logic in saying we could add the extra attribute > when(/if) there is a new version. Future kernels would then be expected > to use the current version unless user space explicitly set the new > attribute. > > Do you feel this is something that needs to be addressed now, or can it > be deferred until another version is proposed? Assuming we'll want userspace to have the option of choosing version=0, and that we're fine with version=0 being the implicit choice, when nothing is selected, then I guess it can be left as is for now. If, OTOH, we just
Re: [PATCH v3 11/11] misc: pci_endpoint_test: Add LS1088a in pci_device_id table
On Mon, Sep 02, 2019 at 11:17:16AM +0800, Xiaowei Bao wrote:
> Add LS1088a in pci_device_id table so that pci-epf-test can be used
> for testing PCIe EP in LS1088a.
>
> Signed-off-by: Xiaowei Bao
> ---
> v2:
> - No change.
> v3:
> - No change.
>
> drivers/misc/pci_endpoint_test.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/misc/pci_endpoint_test.c
> b/drivers/misc/pci_endpoint_test.c
> index 6e208a0..d531951 100644
> --- a/drivers/misc/pci_endpoint_test.c
> +++ b/drivers/misc/pci_endpoint_test.c
> @@ -793,6 +793,7 @@ static const struct pci_device_id pci_endpoint_test_tbl[]
> = {
> { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
> { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
> { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0) },
> + { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x80c0) },
The Freescale PCI devices are the only devices in this table that don't
have a define for their device ID. I think a define should be created
for both of the device IDs above.
Thanks,
Andrew Murray
> { PCI_DEVICE_DATA(SYNOPSYS, EDDA, NULL) },
> { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
> .driver_data = (kernel_ulong_t)_data
> --
> 2.9.5
>
[PATCH] tools/power/x86/turbostat: Fixing PKG_MIN_PWR_LVL{1|2} values
As per Intel's documentation, those 2 registers are starting from offset 47 and
not 48.
As a result, the reported values were incorrect.
Signed-off-by: Erwan Velu
---
tools/power/x86/turbostat/turbostat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index 75fc4fb9901c..76456de6b140 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -2370,7 +2370,7 @@ dump_config_tdp(void)
get_msr(base_cpu, MSR_CONFIG_TDP_LEVEL_1, );
fprintf(outf, "cpu%d: MSR_CONFIG_TDP_LEVEL_1: 0x%08llx (", base_cpu,
msr);
if (msr) {
- fprintf(outf, "PKG_MIN_PWR_LVL1=%d ", (unsigned int)(msr >> 48)
& 0x7FFF);
+ fprintf(outf, "PKG_MIN_PWR_LVL1=%d ", (unsigned int)(msr >> 47)
& 0x);
fprintf(outf, "PKG_MAX_PWR_LVL1=%d ", (unsigned int)(msr >> 32)
& 0x7FFF);
fprintf(outf, "LVL1_RATIO=%d ", (unsigned int)(msr >> 16) &
0xFF);
fprintf(outf, "PKG_TDP_LVL1=%d", (unsigned int)(msr) & 0x7FFF);
@@ -2380,7 +2380,7 @@ dump_config_tdp(void)
get_msr(base_cpu, MSR_CONFIG_TDP_LEVEL_2, );
fprintf(outf, "cpu%d: MSR_CONFIG_TDP_LEVEL_2: 0x%08llx (", base_cpu,
msr);
if (msr) {
- fprintf(outf, "PKG_MIN_PWR_LVL2=%d ", (unsigned int)(msr >> 48)
& 0x7FFF);
+ fprintf(outf, "PKG_MIN_PWR_LVL2=%d ", (unsigned int)(msr >> 47)
& 0x);
fprintf(outf, "PKG_MAX_PWR_LVL2=%d ", (unsigned int)(msr >> 32)
& 0x7FFF);
fprintf(outf, "LVL2_RATIO=%d ", (unsigned int)(msr >> 16) &
0xFF);
fprintf(outf, "PKG_TDP_LVL2=%d", (unsigned int)(msr) & 0x7FFF);
--
2.21.0
[PATCH] power: reset: gpio-restart: Fix typo when gpio reset is not found
Trivial patch which just corrects error message.
Fixes: 371bb20d6927 ("power: Add simple gpio-restart driver")
Signed-off-by: Michal Simek
---
drivers/power/reset/gpio-restart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/reset/gpio-restart.c
b/drivers/power/reset/gpio-restart.c
index 2880cd5ae0d2..308ca9d9d276 100644
--- a/drivers/power/reset/gpio-restart.c
+++ b/drivers/power/reset/gpio-restart.c
@@ -65,7 +65,7 @@ static int gpio_restart_probe(struct platform_device *pdev)
gpio_restart->reset_gpio = devm_gpiod_get(>dev, NULL,
open_source ? GPIOD_IN : GPIOD_OUT_LOW);
if (IS_ERR(gpio_restart->reset_gpio)) {
- dev_err(>dev, "Could net get reset GPIO\n");
+ dev_err(>dev, "Could not get reset GPIO\n");
return PTR_ERR(gpio_restart->reset_gpio);
}
--
2.17.1
Re: [PATCH v7 5/6] powerpc/64: Make COMPAT user-selectable disabled on littleendian by default.
On Mon, Sep 02, 2019 at 12:03:12PM +1000, Michael Ellerman wrote: > Michal Suchanek writes: > > On bigendian ppc64 it is common to have 32bit legacy binaries but much > > less so on littleendian. > > I think the toolchain people will tell you that there is no 32-bit > little endian ABI defined at all, if anything works it's by accident. There of course is a lot of powerpcle-* support. The ABI used for it on linux is the SYSV ABI, just like on BE 32-bit. There also is specific powerpcle-linux support in GCC, and in binutils, too. Also, config.guess/config.sub supports it. Half a year ago this all built fine (no, I don't test it often either). I don't think glibc supports it though, so I wonder if anyone builds an actual system with it? Maybe busybox or the like? > So I think we should not make this selectable, unless someone puts their > hand up to say they want it and are willing to test it and keep it > working. What about actual 32-bit LE systems? Does anyone still use those? Segher
Re: [PATCH RFC 00/12] media: hantro: H264 fixes and improvements
Hi Jonas, Thanks for the series, I'll be reviewing this shortly. On Sun, 2019-09-01 at 12:42 +, Jonas Karlman wrote: > This series contains fixes and improvements for the hantro H264 decoder. > > Patch 1-6 fixes issues and limitations observed when preparing support > for field encoded content. > > Patch 7 introduce new DPB entry flags that is used to signal how a reference > frame is referenced. This information is needed to correctly build a > reference list for field encoded content. > > Patch 8 adds bits to handle field encoded content, this is a rough patch > and should be reworked with proper code style and formatting. > Please get back with feedback on how to improve this. > > The following samples from [1] are now playable with patch 1-8 > - H264_1080i-25-interlace_Kaesescheibchen.mkv > - H264_10_1080i_50_AC3-Astra19.2_ProSieben_HD.ts > - big_buck_bunny_1080p_H264_AAC_25fps_7200K.mp4 > - h264_tivo_sample.ts > > The rest of the patches refactors G1 H264 code to more closely match > the code generated by my rockchip-vpu-regtool at [2] and then adds > support for H264 decoding on RK3399/RK3328 using the VPU2 block. > This code is early work and needs proper code style and formatting, > I just wanted to share the early work and get some initial feedback. > > This series has been tested using ffmpeg v4l2 request hwaccel at [3] [4] > What boards have you tested this on? Thanks, Ezequiel
Re: [PATCH 2/5] EDAC, mc_sysfs: Change dev_ch_attribute->channel to unsigned int
On Mon, Sep 02, 2019 at 12:33:43PM +, Robert Richter wrote:
> Struct member dev_ch_attribute->channel is always used as unsigned
> int. Change type to unsigned int to avoid type casts.
>
> Signed-off-by: Robert Richter
> ---
> drivers/edac/edac_mc_sysfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
> index 640b9419623e..4eb8c5ceb973 100644
> --- a/drivers/edac/edac_mc_sysfs.c
> +++ b/drivers/edac/edac_mc_sysfs.c
> @@ -131,7 +131,7 @@ static const char * const edac_caps[] = {
>
> struct dev_ch_attribute {
> struct device_attribute attr;
> - int channel;
> + unsigned int channel;
> };
>
> #define DEVICE_CHANNEL(_name, _mode, _show, _store, _var) \
> --
Merged this one into 1/5.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 1/2] dt-bindings: iio: accel: add binding documentation for ADIS16240
On Sun, 2019-09-01 at 21:59 -0300, Rodrigo Carvalho wrote:
> This patch add device tree binding documentation for ADIS16240.
>
> Signed-off-by: Rodrigo Ribeiro Carvalho
> ---
> I have doubt about what maintainer I may to put in that documentation. I
> put Alexandru as maintainer because he reviewed my last patch on this
> driver, so I think that he is a good candidate.
Fine to list me as maintainer for this.
Reviewed-by: Alexandru Ardelean
> .../bindings/iio/accel/adi,adis16240.yaml | 55 +++
> 1 file changed, 55 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> new file mode 100644
> index ..08019b51611c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/accel/adi,adis16240.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ADIS16240 Programmable Impact Sensor and Recorder driver
> +
> +maintainers:
> + - Alexandru Ardelean
> +
> +description: |
> + ADIS16240 Programmable Impact Sensor and Recorder driver that supports
> + SPI interface.
> +https://www.analog.com/en/products/adis16240.html
> +
> +properties:
> + compatible:
> +enum:
> + - adi,adis16240
> +
> + reg:
> +maxItems: 1
> +
> + spi-cpha: true
> +
> + spi-cpol: true
> +
> + interrupts:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +examples:
> + - |
> +#include
> +#include
> +spi0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +/* Example for a SPI device node */
> +accelerometer@0 {
> +compatible = "adi,adis16240";
> +reg = <0>;
> +spi-max-frequency = <250>;
> +spi-cpol;
> +spi-cpha;
> +interrupt-parent = <>;
> +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +};
Re: [PATCH v3 10/11] arm64: dts: layerscape: Add PCIe EP node for ls1088a
On Mon, Sep 02, 2019 at 11:17:15AM +0800, Xiaowei Bao wrote:
> Add PCIe EP node for ls1088a to support EP mode.
>
> Signed-off-by: Xiaowei Bao
> ---
> v2:
> - Remove the pf-offset proparty.
> v3:
> - No change.
>
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31
> ++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index c676d07..da246ab 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -483,6 +483,17 @@
> status = "disabled";
> };
>
> + pcie_ep@340 {
> + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
Here you specify a fallback "fsl,ls-pcie-ep" that is removed by this series.
Besides that, this looks OK.
Thanks,
Andrew Murray
> + reg = <0x00 0x0340 0x0 0x0010
> +0x20 0x 0x8 0x>;
> + reg-names = "regs", "addr_space";
> + num-ib-windows = <24>;
> + num-ob-windows = <128>;
> + max-functions = /bits/ 8 <2>;
> + status = "disabled";
> + };
> +
> pcie@350 {
> compatible = "fsl,ls1088a-pcie";
> reg = <0x00 0x0350 0x0 0x0010 /* controller
> registers */
> @@ -508,6 +519,16 @@
> status = "disabled";
> };
>
> + pcie_ep@350 {
> + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> + reg = <0x00 0x0350 0x0 0x0010
> +0x28 0x 0x8 0x>;
> + reg-names = "regs", "addr_space";
> + num-ib-windows = <6>;
> + num-ob-windows = <8>;
> + status = "disabled";
> + };
> +
> pcie@360 {
> compatible = "fsl,ls1088a-pcie";
> reg = <0x00 0x0360 0x0 0x0010 /* controller
> registers */
> @@ -533,6 +554,16 @@
> status = "disabled";
> };
>
> + pcie_ep@360 {
> + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> + reg = <0x00 0x0360 0x0 0x0010
> +0x30 0x 0x8 0x>;
> + reg-names = "regs", "addr_space";
> + num-ib-windows = <6>;
> + num-ob-windows = <8>;
> + status = "disabled";
> + };
> +
> smmu: iommu@500 {
> compatible = "arm,mmu-500";
> reg = <0 0x500 0 0x80>;
> --
> 2.9.5
>
Re: [PATCH v2 5/8] sched/fair: use rq->nr_running when balancing load
Hi Hillf,
Sorry for the late reply.
I have noticed that i didn't answer your question while preparing v3
On Fri, 9 Aug 2019 at 07:21, Hillf Danton wrote:
>
>
> On Thu, 1 Aug 2019 16:40:21 +0200 Vincent Guittot wrote:
> >
> > cfs load_balance only takes care of CFS tasks whereas CPUs can be used by
> > other scheduling class. Typically, a CFS task preempted by a RT or deadline
> > task will not get a chance to be pulled on another CPU because the
> > load_balance doesn't take into account tasks from classes.
>
> We can add something accordingly in RT to push cfs tasks to another cpu
> in this direction if the pulling above makes some sense missed long.
RT class doesn't and can't touch CFS tasks but the ilb will be kicked
to check if another CPU can pull the CFS task.
> I doubt we can as we can not do too much about RT tasks on any cpu.
> Nor is busiest cpu selected for load balancing based on a fifo cpuhog.
This patch takes into account all type tasks when checking the state
of a group and when trying to balance the number of tasks but of
course we can only detach and move the cfs tasks at the end.
So if we have 1 RT task and 1 CFS task competing for the same CPU but
there is an idle CPU, the CFS task will be pulled during the
load_balance of the idle CPU whereas it was not the case before.
>
> > Add sum of nr_running in the statistics and use it to detect such
> > situation.
> >
> > Signed-off-by: Vincent Guittot
> > ---
> > kernel/sched/fair.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index a8681c3..f05f1ad 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -7774,6 +7774,7 @@ struct sg_lb_stats {
> > unsigned long group_load; /* Total load over the CPUs of the group */
> > unsigned long group_capacity;
> > unsigned long group_util; /* Total utilization of the group */
> > + unsigned int sum_nr_running; /* Nr tasks running in the group */
> > unsigned int sum_h_nr_running; /* Nr tasks running in the group */
>
> A different comment is appreciated.
ok
>
> > unsigned int idle_cpus;
> > unsigned int group_weight;
> > @@ -8007,7 +8008,7 @@ static inline int sg_imbalanced(struct sched_group
> > *group)
> > static inline bool
> > group_has_capacity(struct lb_env *env, struct sg_lb_stats *sgs)
> > {
> > - if (sgs->sum_h_nr_running < sgs->group_weight)
> > + if (sgs->sum_nr_running < sgs->group_weight)
> > return true;
> >
> > if ((sgs->group_capacity * 100) >
> > @@ -8028,7 +8029,7 @@ group_has_capacity(struct lb_env *env, struct
> > sg_lb_stats *sgs)
> > static inline bool
> > group_is_overloaded(struct lb_env *env, struct sg_lb_stats *sgs)
> > {
> > - if (sgs->sum_h_nr_running <= sgs->group_weight)
> > + if (sgs->sum_nr_running <= sgs->group_weight)
> > return false;
> >
> > if ((sgs->group_capacity * 100) <
> > @@ -8132,6 +8133,8 @@ static inline void update_sg_lb_stats(struct lb_env
> > *env,
> > sgs->sum_h_nr_running += rq->cfs.h_nr_running;
> >
> > nr_running = rq->nr_running;
> > + sgs->sum_nr_running += nr_running;
> > +
> > if (nr_running > 1)
> > *sg_status |= SG_OVERLOAD;
> >
> > @@ -8480,7 +8483,7 @@ static inline void calculate_imbalance(struct lb_env
> > *env, struct sd_lb_stats *s
> >* groups.
> >*/
> > env->balance_type = migrate_task;
> > - env->imbalance = (busiest->sum_h_nr_running -
> > local->sum_h_nr_running) >> 1;
> > + env->imbalance = (busiest->sum_nr_running -
> > local->sum_nr_running) >> 1;
>
> Can we detach RR tasks?
>
> > return;
> > }
> >
> > @@ -8643,7 +8646,7 @@ static struct sched_group *find_busiest_group(struct
> > lb_env *env)
> >
> > /* Try to move all excess tasks to child's sibling domain */
> > if (sds.prefer_sibling && local->group_type == group_has_spare &&
> > - busiest->sum_h_nr_running > local->sum_h_nr_running + 1)
> > + busiest->sum_nr_running > local->sum_nr_running + 1)
> > goto force_balance;
> >
> > if (busiest->group_type != group_overloaded &&
> > --
> > 2.7.4
>
[PATCH 1/3] arm64: defconfig: Enable Qualcomm GENI based I2C controller
Tested on the Lenovo Yoga C630 where this patch enables the keyboard, touchpad and touchscreen. Signed-off-by: Lee Jones --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index facf19cc275d..0fe943ac53b5 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -366,6 +366,7 @@ CONFIG_I2C_IMX_LPI2C=y CONFIG_I2C_MESON=y CONFIG_I2C_MV64XXX=y CONFIG_I2C_PXA=y +CONFIG_I2C_QCOM_GENI=m CONFIG_I2C_QUP=y CONFIG_I2C_RK3X=y CONFIG_I2C_SH_MOBILE=y -- 2.17.1
[PATCH 3/3] arm64: defconfig: Enable Qualcomm QUSB2 PHY
Tested on the Lenovo Yoga C630 where this patch enables USB. Without it USB devices are not enumerated. Signed-off-by: Lee Jones --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index af7ca722b519..a94d002182ee 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -770,6 +770,7 @@ CONFIG_PHY_HISTB_COMBPHY=y CONFIG_PHY_HISI_INNO_USB2=y CONFIG_PHY_MVEBU_CP110_COMPHY=y CONFIG_PHY_QCOM_QMP=m +CONFIG_PHY_QCOM_QUSB2=m CONFIG_PHY_QCOM_USB_HS=y CONFIG_PHY_RCAR_GEN3_PCIE=y CONFIG_PHY_RCAR_GEN3_USB2=y -- 2.17.1
[PATCH 2/3] arm64: defconfig: Enable the EFI Framebuffer
Tested on the Lenovo Yoga C630 where this patch enables the framebuffer (screen/monitor). Without it the device appears not to boot. Signed-off-by: Lee Jones --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 0fe943ac53b5..af7ca722b519 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -540,6 +540,7 @@ CONFIG_DRM_LIMA=m CONFIG_DRM_PANFROST=m CONFIG_FB=y CONFIG_FB_MODE_HELPERS=y +CONFIG_FB_EFI=y CONFIG_BACKLIGHT_GENERIC=m CONFIG_BACKLIGHT_PWM=m CONFIG_BACKLIGHT_LP855X=m -- 2.17.1
[PATCH V4 3/4] staging: iio: adc: ad7192: Add system calibration support
This patch will add a system calibration attribute for each channel. Using
this option the user will have the ability to calibrate each channel for
zero scale and full scale. It uses the iio_chan_spec_ext_info and IIO_ENUM
to implement the functionality.
Signed-off-by: Mircea Caprioru
---
Changelog V2:
- no changes here
Changelog V3:
- no changes here
Changelog V4:
- add an attribute to start the system calibration
- the mode attribute does not trigger the calibration
- added ABI documentation
.../ABI/testing/sysfs-bus-iio-adc-ad7192 | 24 ++
drivers/staging/iio/adc/ad7192.c | 79 ++-
2 files changed, 102 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
index 74a2873045bf..7627d3be08f5 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
@@ -13,3 +13,27 @@ Description:
need to minimize the system current consumption.
Reading gives the state of the bridge switch.
Writing '1' enables the bridge switch.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration
+KernelVersion:
+Contact: linux-...@vger.kernel.org
+Description:
+ Initiates the system calibration procedure. This is done on a
+ single channel at a time. Write '1' to start the calibration.
+
+What:
/sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration_mode_available
+KernelVersion:
+Contact: linux-...@vger.kernel.org
+Description:
+ Reading returns a list with the possible calibration modes.
+ There are two available options:
+ "zero_scale" - calibrate to zero scale
+ "full_scale" - calibrate to full scale
+
+What:
/sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration_mode
+KernelVersion:
+Contact: linux-...@vger.kernel.org
+Description:
+ Sets up the calibration mode used in the system calibration
+ procedure. Reading returns the current calibration mode.
+ Writing sets the system calibration mode.
diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c
index d58ce08f3693..c5106d98c9b3 100644
--- a/drivers/staging/iio/adc/ad7192.c
+++ b/drivers/staging/iio/adc/ad7192.c
@@ -155,6 +155,11 @@
* The DOUT/RDY output must also be wired to an interrupt capable GPIO.
*/
+enum {
+ AD7192_SYSCALIB_ZERO_SCALE,
+ AD7192_SYSCALIB_FULL_SCALE,
+};
+
struct ad7192_state {
struct regulator*avdd;
struct regulator*dvdd;
@@ -169,10 +174,80 @@ struct ad7192_state {
u8 devid;
u8 clock_sel;
struct mutexlock; /* protect sensor state */
+ u8 syscalib_mode[8];
struct ad_sigma_delta sd;
};
+static const char * const ad7192_syscalib_modes[] = {
+ [AD7192_SYSCALIB_ZERO_SCALE] = "zero_scale",
+ [AD7192_SYSCALIB_FULL_SCALE] = "full_scale",
+};
+
+static int ad7192_set_syscalib_mode(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ unsigned int mode)
+{
+ struct ad7192_state *st = iio_priv(indio_dev);
+
+ st->syscalib_mode[chan->channel] = mode;
+
+ return 0;
+}
+
+static int ad7192_get_syscalib_mode(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan)
+{
+ struct ad7192_state *st = iio_priv(indio_dev);
+
+ return st->syscalib_mode[chan->channel];
+}
+
+static ssize_t ad7192_write_syscalib(struct iio_dev *indio_dev,
+uintptr_t private,
+const struct iio_chan_spec *chan,
+const char *buf, size_t len)
+{
+ struct ad7192_state *st = iio_priv(indio_dev);
+ bool sys_calib;
+ int ret, temp;
+
+ ret = strtobool(buf, _calib);
+ if (ret)
+ return ret;
+
+ temp = st->syscalib_mode[chan->channel];
+ if (sys_calib) {
+ if (temp == AD7192_SYSCALIB_ZERO_SCALE)
+ ret = ad_sd_calibrate(>sd, AD7192_MODE_CAL_SYS_ZERO,
+ chan->address);
+ else
+ ret = ad_sd_calibrate(>sd, AD7192_MODE_CAL_SYS_FULL,
+ chan->address);
+ }
+
+ return ret ? ret : len;
+}
+
+static const struct iio_enum ad7192_syscalib_mode_enum = {
+ .items = ad7192_syscalib_modes,
+ .num_items = ARRAY_SIZE(ad7192_syscalib_modes),
+ .set = ad7192_set_syscalib_mode,
+ .get = ad7192_get_syscalib_mode
+};
+
+static const struct
Re: [PATCH v4 11/11] lib/test_printf: Add tests for %pfw printk modifier
On Mon, Sep 02, 2019 at 03:26:27PM +0300, Andy Shevchenko wrote:
> On Mon, Sep 02, 2019 at 11:32:40AM +0300, Sakari Ailus wrote:
> > Add a test for the %pfw printk modifier using software nodes.
>
> > + const struct software_node softnodes[] = {
> > + { .name = "first", },
> > + { .name = "second", .parent = [0], },
> > + { .name = "third", .parent = [1], },
> > + { NULL /* Guardian */ },
> > + };
>
> > + test(full_name_second, "%pfw",
> > +software_node_fwnode([ARRAY_SIZE(softnodes) - 3]));
> > + test(full_name, "%pfw",
> > +software_node_fwnode([ARRAY_SIZE(softnodes) - 2]));
> > + test(full_name, "%pfwf",
> > +software_node_fwnode([ARRAY_SIZE(softnodes) - 2]));
> > + test(second_name, "%pfwP",
> > +software_node_fwnode([ARRAY_SIZE(softnodes) - 3]));
> > + test(third_name, "%pfwP",
> > +software_node_fwnode([ARRAY_SIZE(softnodes) - 2]));
>
>
> These can be shorted and easier to parse if you use absolute indexes.
The above doesn't end up accessing out-of-bounds memory without compiler
errors or warnings if the array is changed, therefore I'd prefer to keep it
as-is.
But I'll remove the comma from the guardian entry for v5. :-)
--
Sakari Ailus
sakari.ai...@linux.intel.com
[PATCH V4 1/4] iio: adc: ad7192: Add sysfs ABI documentation
Add initial ABI documentation for ad7192 adc sysfs interfaces. Signed-off-by: Mircea Caprioru --- Changelog V2: - no changes here Changelog V3: - no changes here Changelog V4: - added sysfs ABI documentation .../ABI/testing/sysfs-bus-iio-adc-ad7192 | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 new file mode 100644 index ..74a2873045bf --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 @@ -0,0 +1,15 @@ +What: /sys/bus/iio/devices/iio:deviceX/ac_excitation_en +KernelVersion: +Contact: linux-...@vger.kernel.org +Description: + Reading gives the state of AC excitation. + Writing '1' enables AC excitation. + +What: /sys/bus/iio/devices/iio:deviceX/bridge_switch_en +KernelVersion: +Contact: linux-...@vger.kernel.org +Description: + This bridge switch is used to disconnect it when there is a + need to minimize the system current consumption. + Reading gives the state of the bridge switch. + Writing '1' enables the bridge switch. -- 2.17.1
[PATCH V4 4/4] dt-bindings: iio: adc: ad7192: Add binding documentation for AD7192
This patch add device tree binding documentation for AD7192 adc in YAML
format.
Signed-off-by: Mircea Caprioru
---
Changelog V2:
- no changes here
Changelog V3:
- no changes here
Changelog V4:
- remove the const value from avdd and dvdd supply
.../bindings/iio/adc/adi,ad7192.yaml | 119 ++
1 file changed, 119 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
new file mode 100644
index ..040af0bcc92e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bindings/iio/adc/adi,ad7192.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD7192 ADC device driver
+
+maintainers:
+ - Michael Hennerich
+
+description: |
+ Bindings for the Analog Devices AD7192 ADC device. Datasheet can be
+ found here:
+
https://www.analog.com/media/en/technical-documentation/data-sheets/AD7192.pdf
+
+properties:
+ compatible:
+enum:
+ - adi,ad7190
+ - adi,ad7192
+ - adi,ad7193
+ - adi,ad7195
+
+ reg:
+maxItems: 1
+
+ spi-cpol: true
+
+ spi-cpha: true
+
+ clocks:
+maxItems: 1
+description: phandle to the master clock (mclk)
+
+ clock-names:
+items:
+ - const: mclk
+
+ interrupts:
+maxItems: 1
+
+ dvdd-supply:
+description: DVdd voltage supply
+maxItems: 1
+
+ avdd-supply:
+description: AVdd voltage supply
+maxItems: 1
+
+ adi,rejection-60-Hz-enable:
+description: |
+ This bit enables a notch at 60 Hz when the first notch of the sinc
+ filter is at 50 Hz. When REJ60 is set, a filter notch is placed at
+ 60 Hz when the sinc filter first notch is at 50 Hz. This allows
+ simultaneous 50 Hz/ 60 Hz rejection.
+type: boolean
+
+ adi,refin2-pins-enable:
+description: |
+ External reference applied between the P1/REFIN2(+) and P0/REFIN2(???)
pins.
+type: boolean
+
+ adi,buffer-enable:
+description: |
+ Enables the buffer on the analog inputs. If cleared, the analog inputs
+ are unbuffered, lowering the power consumption of the device. If this
+ bit is set, the analog inputs are buffered, allowing the user to place
+ source impedances on the front end without contributing gain errors to
+ the system.
+type: boolean
+
+ adi,burnout-currents-enable:
+description: |
+ When this bit is set to 1, the 500 nA current sources in the signal
+ path are enabled. When BURN = 0, the burnout currents are disabled.
+ The burnout currents can be enabled only when the buffer is active
+ and when chop is disabled.
+type: boolean
+
+ bipolar:
+description: see Documentation/devicetree/bindings/iio/adc/adc.txt
+type: boolean
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - dvdd-supply
+ - avdd-supply
+ - spi-cpol
+ - spi-cpha
+
+examples:
+ - |
+spi0 {
+ adc@0 {
+compatible = "adi,ad7192";
+reg = <0>;
+spi-max-frequency = <100>;
+spi-cpol;
+spi-cpha;
+clocks = <_mclk>;
+clock-names = "mclk";
+#interrupt-cells = <2>;
+interrupts = <25 0x2>;
+interrupt-parent = <>;
+dvdd-supply = <>;
+avdd-supply = <>;
+
+adi,refin2-pins-enable;
+adi,rejection-60-Hz-enable;
+adi,buffer-enable;
+adi,burnout-currents-enable;
+};
+};
--
2.17.1
[PATCH V4 2/4] iio: adc: ad_sigma_delta: Export ad_sd_calibrate
This patch exports the ad_sd_calibrate function in order to be able to
call it from outside ad_sigma_delta.
There are cases where the option to calibrate one channel at a time is
necessary (ex. system calibration for zero scale and full scale).
Signed-off-by: Mircea Caprioru
---
Changelog V2:
- no changes here
Changelog V3:
- no changes here
Changelog V4:
- no changes here
drivers/iio/adc/ad_sigma_delta.c | 3 ++-
include/linux/iio/adc/ad_sigma_delta.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/ad_sigma_delta.c b/drivers/iio/adc/ad_sigma_delta.c
index 2640b75fb774..8ba90486c787 100644
--- a/drivers/iio/adc/ad_sigma_delta.c
+++ b/drivers/iio/adc/ad_sigma_delta.c
@@ -205,7 +205,7 @@ int ad_sd_reset(struct ad_sigma_delta *sigma_delta,
}
EXPORT_SYMBOL_GPL(ad_sd_reset);
-static int ad_sd_calibrate(struct ad_sigma_delta *sigma_delta,
+int ad_sd_calibrate(struct ad_sigma_delta *sigma_delta,
unsigned int mode, unsigned int channel)
{
int ret;
@@ -242,6 +242,7 @@ static int ad_sd_calibrate(struct ad_sigma_delta
*sigma_delta,
return ret;
}
+EXPORT_SYMBOL_GPL(ad_sd_calibrate);
/**
* ad_sd_calibrate_all() - Performs channel calibration
diff --git a/include/linux/iio/adc/ad_sigma_delta.h
b/include/linux/iio/adc/ad_sigma_delta.h
index 7716fa0c9fce..8a4e25a7080c 100644
--- a/include/linux/iio/adc/ad_sigma_delta.h
+++ b/include/linux/iio/adc/ad_sigma_delta.h
@@ -119,6 +119,8 @@ int ad_sd_reset(struct ad_sigma_delta *sigma_delta,
int ad_sigma_delta_single_conversion(struct iio_dev *indio_dev,
const struct iio_chan_spec *chan, int *val);
+int ad_sd_calibrate(struct ad_sigma_delta *sigma_delta,
+ unsigned int mode, unsigned int channel);
int ad_sd_calibrate_all(struct ad_sigma_delta *sigma_delta,
const struct ad_sd_calib_data *cd, unsigned int n);
int ad_sd_init(struct ad_sigma_delta *sigma_delta, struct iio_dev *indio_dev,
--
2.17.1
Re: linux-next: Tree for Aug 30
On 9/2/19 12:55 AM, Christoph Hellwig wrote: On Sun, Sep 01, 2019 at 11:22:26AM -0700, Guenter Roeck wrote: On Sat, Aug 31, 2019 at 12:36:13AM +1000, Stephen Rothwell wrote: Hi all, Changes since 20190829: The compiler-attributes tree gained a build failure for which I reverted a commit. The arm-soc tree gained a conflict against the arm tree. The csky tree gained a conflict against the dma-mapping tree. The fuse tree gained a conflict against the fsverity tree. The vfs tree gained conflicts against the fuse tree. The pci tree gained a build failure for which I revereted a commit. The net-next tree still had its build failure for which I applied a patch. It also gained a conflict against the net tree. The regulator tree still has its build failure for which I reverted a commit. The keys tree still has its build failure so I used the version from next-20190828. The driver-core tree lost its build failure. The staging tree got conflicts against the net-next and usb trees. The akpm-current tree gained a build failure due to an interaction with the hmm tree for which I applied a patch. Something in the fixup patch seems to be wrong. I get the following error with sh4 boot tests when booting from usb. sm501-usb sm501-usb: OHCI Unrecoverable Error, disabled sm501-usb sm501-usb: HC died; cleaning up Unfortunately, bisect doesn't help much (see below). Reverting the fixup patch as well as the offending patch (plus a context patch) alone does not help either. Further analysis shows that the problem exists since at least next-20190823. Another round of bisect on next-20190827 suggests another culprit (see second bisect below). Reverting all the offending patches doesn't help either, though, only result in a different error. usb 1-1: new full-speed USB device number 2 using sm501-usb sm501-usb sm501-usb: DMA map on device without dma_mask With that, I am giving up. Copying Christoph as he appears to be heavily involved in the patch series causing the problems. What was the last tree you tested that works perfectly? next-20190822 Guenter
Re: [PATCH v4] mfd: Add support for Merrifield Basin Cove PMIC
On Mon, Sep 02, 2019 at 09:38:59AM +0100, Lee Jones wrote: > On Thu, 01 Aug 2019, Andy Shevchenko wrote: > > > Add an MFD driver for Intel Merrifield Basin Cove PMIC. > > > > Firmware on the platforms which are using Basin Cove PMIC is "smarter" > > than on the rest supported by vanilla kernel. It handles first level > > of interrupt itself, while others do it on OS level. > > > > The driver is done in the same way as the rest of Intel PMIC MFD drivers > > in the kernel to support the initial design. The design allows to use > > one driver among few PMICs without knowing implementation details of > > the each hardware version or generation. > > > > Signed-off-by: Andy Shevchenko > > --- > > v4: elaborate in the commit message the design choice > > drivers/mfd/Kconfig | 11 ++ > > drivers/mfd/Makefile | 1 + > > drivers/mfd/intel_soc_pmic_mrfld.c | 157 +++ > > include/linux/mfd/intel_soc_pmic_mrfld.h | 81 > > 4 files changed, 250 insertions(+) > > create mode 100644 drivers/mfd/intel_soc_pmic_mrfld.c > > create mode 100644 include/linux/mfd/intel_soc_pmic_mrfld.h > > Reluctantly applied, thanks. Thank you very much! If any better solution comes to your mind in the future, I would be glad to amend the driver. Btw, can you provide an immutable branch for IIO subsystem to take individual ADC driver? -- With Best Regards, Andy Shevchenko
Re: [PATCH v3] arch/microblaze: add support for get_user() of size 8 bytes
On 02. 09. 19 6:58, Linus Torvalds wrote: > On Sun, Sep 1, 2019 at 7:10 PM Randy Dunlap wrote: >> >> I guess we need a way to coerce that to call get_user_1(), >> such as a typecast. This _seems_ to work (i.e., call get_user_1()): > > No, I oversimplified. > > Try this slightly modified patch instead. This one looks good. I have also tested it on HW. I will run some LTP tests to see if there is any new error. If there is better testsuite to validate this please let me know. Randy/Linus: Are you going create regular patch from this? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs signature.asc Description: OpenPGP digital signature
Re: [PATCH v1] reset: Remove copy'n'paste redundancy in the comments
On Mon, Aug 19, 2019 at 01:52:52PM +0300, Andy Shevchenko wrote:
> It seems the commit bb475230b8e5
> ("reset: make optional functions really optional")
> brought couple of redundant lines in the comments.
>
> Drop them here.
Any comment on this?
>
> Cc: Ramiro Oliveira
> Signed-off-by: Andy Shevchenko
> ---
> drivers/reset/core.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> index 213ff40dda11..2badff33a0db 100644
> --- a/drivers/reset/core.c
> +++ b/drivers/reset/core.c
> @@ -334,7 +334,6 @@ EXPORT_SYMBOL_GPL(reset_control_reset);
> * internal state to be reset, but must be prepared for this to happen.
> * Consumers must not use reset_control_reset on shared reset lines when
> * reset_control_(de)assert has been used.
> - * return 0.
> *
> * If rstc is NULL it is an optional reset and the function will just
> * return 0.
> @@ -393,7 +392,6 @@ EXPORT_SYMBOL_GPL(reset_control_assert);
> * After calling this function, the reset is guaranteed to be deasserted.
> * Consumers must not use reset_control_reset on shared reset lines when
> * reset_control_(de)assert has been used.
> - * return 0.
> *
> * If rstc is NULL it is an optional reset and the function will just
> * return 0.
> --
> 2.23.0.rc1
>
--
With Best Regards,
Andy Shevchenko
From Michelle
Hallo, wie geht es dir? Hoffe, du hast meine Nachricht erhalten. Ich brauche jetzt deine dringende Antwort Vielen Dank Michelle
Re: [PATCH v6 1/5] kasan: support backing vmalloc space with real shadow memory
On Mon, Sep 02, 2019 at 09:20:24PM +1000, Daniel Axtens wrote:
> Hook into vmalloc and vmap, and dynamically allocate real shadow
> memory to back the mappings.
>
> Most mappings in vmalloc space are small, requiring less than a full
> page of shadow space. Allocating a full shadow page per mapping would
> therefore be wasteful. Furthermore, to ensure that different mappings
> use different shadow pages, mappings would have to be aligned to
> KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE.
>
> Instead, share backing space across multiple mappings. Allocate a
> backing page when a mapping in vmalloc space uses a particular page of
> the shadow region. This page can be shared by other vmalloc mappings
> later on.
>
> We hook in to the vmap infrastructure to lazily clean up unused shadow
> memory.
>
> To avoid the difficulties around swapping mappings around, this code
> expects that the part of the shadow region that covers the vmalloc
> space will not be covered by the early shadow page, but will be left
> unmapped. This will require changes in arch-specific code.
>
> This allows KASAN with VMAP_STACK, and may be helpful for architectures
> that do not have a separate module space (e.g. powerpc64, which I am
> currently working on). It also allows relaxing the module alignment
> back to PAGE_SIZE.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=202009
> Acked-by: Vasily Gorbik
> Signed-off-by: Daniel Axtens
> [Mark: rework shadow allocation]
> Signed-off-by: Mark Rutland
>
> --
>
> v2: let kasan_unpoison_shadow deal with ranges that do not use a
> full shadow byte.
>
> v3: relax module alignment
> rename to kasan_populate_vmalloc which is a much better name
> deal with concurrency correctly
>
> v4: Mark's rework
> Poision pages on vfree
> Handle allocation failures
>
> v5: Per Christophe Leroy, split out test and dynamically free pages.
>
> v6: Guard freeing page properly. Drop WARN_ON_ONCE(pte_none(*ptep)),
> on reflection it's unnecessary debugging cruft with too high a
> false positive rate.
> ---
[...]
> +static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
> + void *unused)
> +{
> + unsigned long page;
> +
> + page = (unsigned long)__va(pte_pfn(*ptep) << PAGE_SHIFT);
> +
> + spin_lock(_mm.page_table_lock);
> +
> + if (likely(!pte_none(*ptep))) {
> + pte_clear(_mm, addr, ptep);
> + free_page(page);
> + }
> + spin_unlock(_mm.page_table_lock);
> +
> + return 0;
> +}
There needs to be TLB maintenance after unmapping the page, but I don't
see that happening below.
We need that to ensure that errant accesses don't hit the page we're
freeing and that new mappings at the same VA don't cause a TLB conflict
or TLB amalgamation issue.
> +/*
> + * Release the backing for the vmalloc region [start, end), which
> + * lies within the free region [free_region_start, free_region_end).
> + *
> + * This can be run lazily, long after the region was freed. It runs
> + * under vmap_area_lock, so it's not safe to interact with the vmalloc/vmap
> + * infrastructure.
> + */
IIUC we aim to only free non-shared shadow by aligning the start
upwards, and aligning the end downwards. I think it would be worth
mentioning that explicitly in the comment since otherwise it's not
obvious how we handle races between alloc/free.
Thanks,
Mark.
> +void kasan_release_vmalloc(unsigned long start, unsigned long end,
> +unsigned long free_region_start,
> +unsigned long free_region_end)
> +{
> + void *shadow_start, *shadow_end;
> + unsigned long region_start, region_end;
> +
> + /* we start with shadow entirely covered by this region */
> + region_start = ALIGN(start, PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE);
> + region_end = ALIGN_DOWN(end, PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE);
> +
> + /*
> + * We don't want to extend the region we release to the entire free
> + * region, as the free region might cover huge chunks of vmalloc space
> + * where we never allocated anything. We just want to see if we can
> + * extend the [start, end) range: if start or end fall part way through
> + * a shadow page, we want to check if we can free that entire page.
> + */
> +
> + free_region_start = ALIGN(free_region_start,
> + PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE);
> +
> + if (start != region_start &&
> + free_region_start < region_start)
> + region_start -= PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE;
> +
> + free_region_end = ALIGN_DOWN(free_region_end,
> + PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE);
> +
> + if (end != region_end &&
> + free_region_end > region_end)
> + region_end += PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE;
> +
> + shadow_start = kasan_mem_to_shadow((void *)region_start);
> + shadow_end =
[PATCH 1/1] arm64: dts: qcom: Add Lenovo Yoga C630
From: Bjorn Andersson
The Lenovo Yoga C630 is built on the SDM850 from Qualcomm, but this seem
to be similar enough to the SDM845 that we can reuse the sdm845.dtsi.
Supported by this patch is: keyboard, battery monitoring, UFS storage,
USB host and Bluetooth.
Signed-off-by: Bjorn Andersson
Signed-off-by: Lee Jones
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 450 ++
2 files changed, 451 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 0a7e5dfce6f7..670c6c65f9e9 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -12,5 +12,6 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-1000.dtb
dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-4000.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
new file mode 100644
index ..3177b054035f
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
@@ -0,0 +1,450 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Lenovo Yoga C630
+ *
+ * Copyright (c) 2019, Linaro Ltd.
+ */
+
+/dts-v1/;
+
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+
+/ {
+ model = "Lenovo Yoga C630";
+ compatible = "lenovo,yoga-c630", "qcom,sdm845";
+
+ aliases {
+ hsuart0 =
+ };
+};
+
+_rsc {
+ pm8998-rpmh-regulators {
+ compatible = "qcom,pm8998-rpmh-regulators";
+ qcom,pmic-id = "a";
+
+ vdd-l2-l8-l17-supply = <_s3a_1p35>;
+ vdd-l7-l12-l14-l15-supply = <_s5a_2p04>;
+
+ vreg_s2a_1p125: smps2 {
+ };
+
+ vreg_s3a_1p35: smps3 {
+ regulator-min-microvolt = <1352000>;
+ regulator-max-microvolt = <1352000>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_s4a_1p8: smps4 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_s5a_2p04: smps5 {
+ regulator-min-microvolt = <204>;
+ regulator-max-microvolt = <204>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_s7a_1p025: smps7 {
+ };
+
+ vdd_qusb_hs0:
+ vdda_hp_pcie_core:
+ vdda_mipi_csi0_0p9:
+ vdda_mipi_csi1_0p9:
+ vdda_mipi_csi2_0p9:
+ vdda_mipi_dsi0_pll:
+ vdda_mipi_dsi1_pll:
+ vdda_qlink_lv:
+ vdda_qlink_lv_ck:
+ vdda_qrefs_0p875:
+ vdda_pcie_core:
+ vdda_pll_cc_ebi01:
+ vdda_pll_cc_ebi23:
+ vdda_sp_sensor:
+ vdda_ufs1_core:
+ vdda_ufs2_core:
+ vdda_usb1_ss_core:
+ vdda_usb2_ss_core:
+ vreg_l1a_0p875: ldo1 {
+ regulator-min-microvolt = <88>;
+ regulator-max-microvolt = <88>;
+ regulator-initial-mode = ;
+ };
+
+ vddpx_10:
+ vreg_l2a_1p2: ldo2 {
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-initial-mode = ;
+ regulator-always-on;
+ };
+
+ vreg_l3a_1p0: ldo3 {
+ };
+
+ vdd_wcss_cx:
+ vdd_wcss_mx:
+ vdda_wcss_pll:
+ vreg_l5a_0p8: ldo5 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <80>;
+ regulator-initial-mode = ;
+ };
+
+ vddpx_13:
+ vreg_l6a_1p8: ldo6 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l7a_1p8: ldo7 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l8a_1p2: ldo8 {
+ };
+
+ vreg_l9a_1p8: ldo9 {
+ };
+
+
Re: [PATCH 2/2] staging: iio: accel: adis16240: move out of staging
On Sun, 2019-09-01 at 21:59 -0300, Rodrigo Carvalho wrote: > Move ADIS16240 driver from staging to mainline. > > The ADIS16240 is a fully integrated digital shock detection > and recorder system. Hey, Comments inline. I'll probably take a look in the next days again. There seem to be some ABI/sysfs attributes that need to be resolved before moving this out of staging. > > Signed-off-by: Rodrigo Ribeiro Carvalho > --- > drivers/iio/accel/Kconfig | 12 + > drivers/iio/accel/Makefile| 1 + > drivers/iio/accel/adis16240.c | 454 ++ > drivers/staging/iio/accel/Kconfig | 12 - > drivers/staging/iio/accel/Makefile| 1 - > drivers/staging/iio/accel/adis16240.c | 454 -- > 6 files changed, 467 insertions(+), 467 deletions(-) > create mode 100644 drivers/iio/accel/adis16240.c > delete mode 100644 drivers/staging/iio/accel/adis16240.c Looks like MAINTAINERS file also needs to be updated, also with the DT bindings file. I think checkpatch usually complains about these. > > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig > index d4ef35aeb579..91fd8741c95f 100644 > --- a/drivers/iio/accel/Kconfig > +++ b/drivers/iio/accel/Kconfig > @@ -30,6 +30,18 @@ config ADIS16209 > To compile this driver as a module, say M here: the module will be > called adis16209. > > +config ADIS16240 > + tristate "Analog Devices ADIS16240 Programmable Impact Sensor and > Recorder" > + depends on SPI > + select IIO_ADIS_LIB > + select IIO_ADIS_LIB_BUFFER if IIO_BUFFER > + help > + Say Y here to build support for Analog Devices adis16240 programmable > + impact Sensor and recorder. > + > + To compile this driver as a module, say M here: the module will be > + called adis16240. > + > config ADXL345 > tristate > > diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile > index 56bd0215e0d4..f7e025a86dd9 100644 > --- a/drivers/iio/accel/Makefile > +++ b/drivers/iio/accel/Makefile > @@ -6,6 +6,7 @@ > # When adding new entries keep the list in alphabetical order > obj-$(CONFIG_ADIS16201) += adis16201.o > obj-$(CONFIG_ADIS16209) += adis16209.o > +obj-$(CONFIG_ADIS16240) += adis16240.o > obj-$(CONFIG_ADXL345) += adxl345_core.o > obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o > obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o > diff --git a/drivers/iio/accel/adis16240.c b/drivers/iio/accel/adis16240.c > new file mode 100644 > index ..82099db4bf0c > --- /dev/null > +++ b/drivers/iio/accel/adis16240.c > @@ -0,0 +1,454 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * ADIS16240 Programmable Impact Sensor and Recorder driver > + * > + * Copyright 2010 Analog Devices Inc. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +#define ADIS16240_STARTUP_DELAY 220 /* ms */ > + > +/* Flash memory write count */ > +#define ADIS16240_FLASH_CNT 0x00 > + > +/* Output, power supply */ > +#define ADIS16240_SUPPLY_OUT 0x02 > + > +/* Output, x-axis accelerometer */ > +#define ADIS16240_XACCL_OUT 0x04 > + > +/* Output, y-axis accelerometer */ > +#define ADIS16240_YACCL_OUT 0x06 > + > +/* Output, z-axis accelerometer */ > +#define ADIS16240_ZACCL_OUT 0x08 > + > +/* Output, auxiliary ADC input */ > +#define ADIS16240_AUX_ADC0x0A > + > +/* Output, temperature */ > +#define ADIS16240_TEMP_OUT 0x0C > + > +/* Output, x-axis acceleration peak */ > +#define ADIS16240_XPEAK_OUT 0x0E > + > +/* Output, y-axis acceleration peak */ > +#define ADIS16240_YPEAK_OUT 0x10 > + > +/* Output, z-axis acceleration peak */ > +#define ADIS16240_ZPEAK_OUT 0x12 > + > +/* Output, sum-of-squares acceleration peak */ > +#define ADIS16240_XYZPEAK_OUT0x14 > + > +/* Output, Capture Buffer 1, X and Y acceleration */ > +#define ADIS16240_CAPT_BUF1 0x16 > + > +/* Output, Capture Buffer 2, Z acceleration */ > +#define ADIS16240_CAPT_BUF2 0x18 > + > +/* Diagnostic, error flags */ > +#define ADIS16240_DIAG_STAT 0x1A > +This looks like it could be converted to IIO_CHAN_INFO_SAMP_FREQ attribute. > +/* Diagnostic, event counter */ > +#define ADIS16240_EVNT_CNTR 0x1C > + > +/* Diagnostic, check sum value from firmware test */ > +#define ADIS16240_CHK_SUM0x1E > + > +/* Calibration, x-axis acceleration offset adjustment */ > +#define ADIS16240_XACCL_OFF 0x20 > + > +/* Calibration, y-axis acceleration offset adjustment */ > +#define ADIS16240_YACCL_OFF 0x22 > + > +/* Calibration, z-axis acceleration offset adjustment */ > +#define ADIS16240_ZACCL_OFF 0x24 > +This looks like it could be converted to IIO_CHAN_INFO_SAMP_FREQ attribute. > +/* Clock, hour and minute */ > +#define ADIS16240_CLK_TIME 0x2E > + > +/* Clock,
[PATCH v2] tpm: Remove duplicate code from caps_show() in tpm-sysfs.c
Replace existing TPM 1.x version structs with new structs that consolidate
the common parts into a single struct so that code duplication is no longer
needed in caps_show().
Cc: Jerry Snitselaar
Signed-off-by: Jarkko Sakkinen
---
v2: Give back the TPM 1.1 version only if tpm1_getcap() returns 0.
drivers/char/tpm/tpm-sysfs.c | 45 ++--
drivers/char/tpm/tpm.h | 23 --
2 files changed, 33 insertions(+), 35 deletions(-)
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index edfa89160010..3b53b3e5ec3e 100644
--- a/drivers/char/tpm/tpm-sysfs.c
+++ b/drivers/char/tpm/tpm-sysfs.c
@@ -217,6 +217,7 @@ static ssize_t caps_show(struct device *dev, struct
device_attribute *attr,
char *buf)
{
struct tpm_chip *chip = to_tpm_chip(dev);
+ struct tpm1_version *version;
ssize_t rc = 0;
char *str = buf;
cap_t cap;
@@ -232,31 +233,31 @@ static ssize_t caps_show(struct device *dev, struct
device_attribute *attr,
str += sprintf(str, "Manufacturer: 0x%x\n",
be32_to_cpu(cap.manufacturer_id));
- /* Try to get a TPM version 1.2 TPM_CAP_VERSION_INFO */
- rc = tpm1_getcap(chip, TPM_CAP_VERSION_1_2, ,
+ /* TPM 1.2 */
+ if (!tpm1_getcap(chip, TPM_CAP_VERSION_1_2, ,
"attempting to determine the 1.2 version",
-sizeof(cap.tpm_version_1_2));
- if (!rc) {
- str += sprintf(str,
- "TCG version: %d.%d\nFirmware version: %d.%d\n",
- cap.tpm_version_1_2.Major,
- cap.tpm_version_1_2.Minor,
- cap.tpm_version_1_2.revMajor,
- cap.tpm_version_1_2.revMinor);
- } else {
- /* Otherwise just use TPM_STRUCT_VER */
- if (tpm1_getcap(chip, TPM_CAP_VERSION_1_1, ,
- "attempting to determine the 1.1 version",
- sizeof(cap.tpm_version)))
- goto out_ops;
- str += sprintf(str,
- "TCG version: %d.%d\nFirmware version: %d.%d\n",
- cap.tpm_version.Major,
- cap.tpm_version.Minor,
- cap.tpm_version.revMajor,
- cap.tpm_version.revMinor);
+sizeof(cap.version2))) {
+ version =
+ goto out_print;
}
+
+ /* TPM 1.1 */
+ if (tpm1_getcap(chip, TPM_CAP_VERSION_1_1, ,
+ "attempting to determine the 1.1 version",
+ sizeof(cap.version1))) {
+ goto out_ops;
+ }
+
+ version =
+
+out_print:
+ str += sprintf(str,
+ "TCG version: %d.%d\nFirmware version: %d.%d\n",
+ version->major, version->minor,
+ version->rev_major, version->rev_minor);
+
rc = str - buf;
+
out_ops:
tpm_put_ops(chip);
return rc;
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index a7fea3e0ca86..a4f74dd02a35 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -186,19 +186,16 @@ structstclear_flags_t {
u8 bGlobalLock;
} __packed;
-struct tpm_version_t {
- u8 Major;
- u8 Minor;
- u8 revMajor;
- u8 revMinor;
+struct tpm1_version {
+ u8 major;
+ u8 minor;
+ u8 rev_major;
+ u8 rev_minor;
} __packed;
-struct tpm_version_1_2_t {
- __be16 tag;
- u8 Major;
- u8 Minor;
- u8 revMajor;
- u8 revMinor;
+struct tpm1_version2 {
+ __be16 tag;
+ struct tpm1_version version;
} __packed;
struct timeout_t {
@@ -243,8 +240,8 @@ typedef union {
struct stclear_flags_t stclear_flags;
__u8owned;
__be32 num_pcrs;
- struct tpm_version_t tpm_version;
- struct tpm_version_1_2_t tpm_version_1_2;
+ struct tpm1_version version1;
+ struct tpm1_version2 version2;
__be32 manufacturer_id;
struct timeout_t timeout;
struct duration_t duration;
--
2.20.1
Re: [PATCH] tpm: Remove duplicate code from caps_show() in tpm-sysfs.c
On Fri, Aug 30, 2019 at 09:09:02AM -0700, Jerry Snitselaar wrote:
> On Thu Aug 29 19, Jarkko Sakkinen wrote:
> + /* TPM 1.1 */
> > + if (tpm1_getcap(chip, TPM_CAP_VERSION_1_1, ,
> > + "attempting to determine the 1.1 version",
> > + sizeof(cap.version1))) {
> > + version =
:>
> Actually looking at this again, this seems wrong. The version
> assignment here should be below this if, or in an else block, yes?
Absolutely is in a wrong place.
I sent an updated patch:
https://patchwork.kernel.org/patch/11126741/
/Jarkko
[PATCH] tools/power/x86/turbostat: Reporting EPB as per Intel's spec
The actual code is reporting the EPB mode by considering a single value,
while Intel's specfication defines ranges.
This patch is about to report the EPB by considering ranges of energy_policy
to actually report the state of the processor.
This avoids reporting a "custom" value while the specification describes
an explicit state of the processor for each value.
0-3 : Maximum performance
4-7 : Balanced Performance
8-11 : Balanced Efficiency
12-15: Powersave
This patch also introduce ENERGY_PERF_BIAS_MIN_POWERSAVE.
The first 3 performance profiles (ENERGY_PERF_BIAS_PERFORMANCE,
ENERGY_PERF_BIAS_BALANCE_PERFORMANCE, ENERGY_PERF_BIAS_BALANCE_POWERSAVE) where
defined
by the lowest value of the associate range while ENERGY_PERF_BIAS_POWERSAVE was
defined by the greatest value.
This was a little bit inconsistent and made more difficult to report EPB value
per range.
Signed-off-by: Erwan Velu
---
arch/x86/include/asm/msr-index.h | 1 +
tools/power/x86/turbostat/turbostat.c | 23 ++-
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 271d837d69a8..120073dfb195 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -596,6 +596,7 @@
#define ENERGY_PERF_BIAS_BALANCE_PERFORMANCE 4
#define ENERGY_PERF_BIAS_NORMAL6
#define ENERGY_PERF_BIAS_BALANCE_POWERSAVE 8
+#define ENERGY_PERF_BIAS_MIN_POWERSAVE 12
#define ENERGY_PERF_BIAS_POWERSAVE 15
#define MSR_IA32_PACKAGE_THERM_STATUS 0x01b1
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index 75fc4fb9901c..9fa73b468f7e 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -3552,6 +3552,7 @@ dump_sysfs_pstate_config(void)
int print_epb(struct thread_data *t, struct core_data *c, struct pkg_data *p)
{
unsigned long long msr;
+ unsigned int perf_bias_value;
char *epb_string;
int cpu;
@@ -3572,20 +3573,16 @@ int print_epb(struct thread_data *t, struct core_data
*c, struct pkg_data *p)
if (get_msr(cpu, MSR_IA32_ENERGY_PERF_BIAS, ))
return 0;
- switch (msr & 0xF) {
- case ENERGY_PERF_BIAS_PERFORMANCE:
+// Reporting perf_bias_performance as per intel specification
+ perf_bias_value = msr & 0xF;
+ epb_string = "powersave";
+ if (perf_bias_value < ENERGY_PERF_BIAS_BALANCE_PERFORMANCE)
epb_string = "performance";
- break;
- case ENERGY_PERF_BIAS_NORMAL:
- epb_string = "balanced";
- break;
- case ENERGY_PERF_BIAS_POWERSAVE:
- epb_string = "powersave";
- break;
- default:
- epb_string = "custom";
- break;
- }
+ else if (perf_bias_value < ENERGY_PERF_BIAS_BALANCE_POWERSAVE)
+ epb_string = "balanced performance";
+ else if (perf_bias_value < ENERGY_PERF_BIAS_MIN_POWERSAVE)
+ epb_string = "balanced efficiency";
+
fprintf(outf, "cpu%d: MSR_IA32_ENERGY_PERF_BIAS: 0x%08llx (%s)\n", cpu,
msr, epb_string);
return 0;
--
2.21.0
Re: [PATCH] ASoC: fsl_sai: Set SAI Channel Mode to Output Mode
On Mon, Sep 2, 2019 at 3:42 PM Mark Brown wrote: > > On Sat, Aug 31, 2019 at 01:55:14AM +0300, Daniel Baluta wrote: > > > Fix this by setting CHMOD to Output Mode so that pins will output zero > > when slots are masked or channels are disabled. > > This patch seems to do this unconditionally. This is fine for > configurations where the SoC is the only thing driving the bus but will > mean that for TDM configurations where something else also drives some > of the slots we'll end up with both devices driving simultaneously. The > safest thing would be to set this only if TDM isn't configured. I thought that the SAI IP is the single owner of the audio data lines, so even in TDM mode SAI IP (which is inside SoC) is the only one adding data on the bus. Now, you say that there could be two devices driving some of he masked slots right? I'm not sure how to really figure out that SAI is running in TDM mode. RM says: When enabled, the SAI continuously transmits and/or receives frames of data. Each frame consists of a fixed number of words and each word consists of a fixed number of bits. Within each frame, any given word can be masked causing the receiver to ignore that word and the transmitter to tri-state for the duration of that word. Will try to ask IP designer about this, thanks a lot for your comment! Daniel.
Re: [PATCH v2 06/10] PCI: layerscape: Modify the way of getting capability with different PEX
On Fri, Aug 23, 2019 at 04:13:30AM +, Xiaowei Bao wrote:
>
>
> > -Original Message-
> > From: Kishon Vijay Abraham I
> > Sent: 2019年8月23日 11:40
> > To: Xiaowei Bao ; bhelg...@google.com;
> > robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo Li
> > ; lorenzo.pieral...@arm.co
> > ; a...@arndb.de; gre...@linuxfoundation.org;
> > M.h. Lian ; Mingkai Hu ;
> > Roy Zang ; jingooh...@gmail.com;
> > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> > andrew.mur...@arm.com
> > Subject: Re: [PATCH v2 06/10] PCI: layerscape: Modify the way of getting
> > capability with different PEX
> >
> > Hi,
> >
> > (Fixed Lorenzo's email address. All the patches in the series have wrong
> > email
> > id)
> >
> > On 23/08/19 8:09 AM, Xiaowei Bao wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Kishon Vijay Abraham I
> > >> Sent: 2019年8月22日 19:44
> > >> To: Xiaowei Bao ; bhelg...@google.com;
> > >> robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> > Li
> > >> ; lorenzo.pieral...@arm.co; a...@arndb.de;
> > >> gre...@linuxfoundation.org; M.h. Lian ;
> > >> Mingkai Hu ; Roy Zang ;
> > >> jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> > >> linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> > >> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > >> linuxppc-...@lists.ozlabs.org; andrew.mur...@arm.com
> > >> Subject: Re: [PATCH v2 06/10] PCI: layerscape: Modify the way of
> > >> getting capability with different PEX
> > >>
> > >> Hi,
> > >>
> > >> On 22/08/19 4:52 PM, Xiaowei Bao wrote:
> > >>> The different PCIe controller in one board may be have different
> > >>> capability of MSI or MSIX, so change the way of getting the MSI
> > >>> capability, make it more flexible.
> > >>
> > >> please use different pci_epc_features table for different boards.
> > > Thanks, I think that it will be more flexible to dynamically get MSI
> > > or MSIX capability, Thus, we will not need to define the pci_epc_feature
> > > for
> > different boards.
> >
> > Is the restriction because you cannot have different compatible for
> > different
> > boards?
> Sorry, I am not very clear what your mean, I think even if I use the same
> compatible
> with different boards, each boards will enter the probe function, in there I
> will get
> the MSI or MSIX PCIe capability of the current controller in this board. Why
> do I need
> to define the pci_epc_feature for different boards?
At present you determine how to set the [msi,msix]_capable flags of
pci_epc_features based on reading the function capabilities at probe
time. Instead of doing this, is it possible that you can determine the flags
based on the compatible type alone? For example, is the MSI/MSIX capability
the same for all fsl,ls2088a-pcie-ep devices?
If it isn't *necessary* to probe for this information at probe time, then
you could instead create a static pci_epc_features structure and assign
it to something in your drvdata. This may provide some benefits.
The dw_pcie_ep_get_features function would then look like:
static const struct pci_epc_features*
ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
{
struct dw_pcie *pci = to_dw_pcie_from_pp(ep);
struct ls_pcie_ep *pcie = dev_get_drvdata(pci->dev);
return pcie->epc_features;
}
This also means you can revert "[v3,03/11] PCI: designware-ep: Move the".
Is this what you had in mind Kishon?
Thanks,
Andrew Murray
> >
> > Thanks
> > Kishon
> >
> > >>
> > >> Thanks
> > >> Kishon
> > >>>
> > >>> Signed-off-by: Xiaowei Bao
> > >>> ---
> > >>> v2:
> > >>> - Remove the repeated assignment code.
> > >>>
> > >>> drivers/pci/controller/dwc/pci-layerscape-ep.c | 26
> > >>> +++---
> > >>> 1 file changed, 19 insertions(+), 7 deletions(-)
> > >>>
> > >>> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > >>> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > >>> index 4e92a95..8461f62 100644
> > >>> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > >>> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > >>> @@ -22,6 +22,7 @@
> > >>>
> > >>> struct ls_pcie_ep {
> > >>> struct dw_pcie *pci;
> > >>> + struct pci_epc_features *ls_epc;
> > >>> };
> > >>>
> > >>> #define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > >>> @@ -40,25 +41,26 @@ static const struct of_device_id
> > >> ls_pcie_ep_of_match[] = {
> > >>> { },
> > >>> };
> > >>>
> > >>> -static const struct pci_epc_features ls_pcie_epc_features = {
> > >>> - .linkup_notifier = false,
> > >>> - .msi_capable = true,
> > >>> - .msix_capable = false,
> > >>> -};
> > >>> -
> > >>> static const struct pci_epc_features*
> > >>> ls_pcie_ep_get_features(struct dw_pcie_ep *ep) {
> > >>> - return _pcie_epc_features;
> > >>> +
Re: [PATCH v2 1/2] gpio: acpi: add quirk to override GpioInt polarity
On Mon, Sep 2, 2019 at 12:01 PM Andy Shevchenko wrote: > On Sat, Aug 31, 2019 at 11:09:14AM +0800, Peter Cai wrote: > > On GPD P2 Max, the firmware could not reset the touch panel correctly. > > The kernel needs to take on the job instead, but the GpioInt definition > > in DSDT specifies ActiveHigh while the GPIO pin should actually be > > ActiveLow. > > > > We need to override the polarity defined by DSDT. The GPIO driver > > already allows defining polarity in acpi_gpio_params, but the option is > > not applied to GpioInt. > > > > This patch adds a new quirk that enables the polarity specified in > > acpi_gpio_params to also be applied to GpioInt. > > Thank you for an update! > > Acked-by: Andy Shevchenko > > on the condition that Dmitry and other input / Goodix developers are okay with > the approach in general. Acked-by: Linus Walleij In case Dmitry needs to merge this. Or should I simply merge this patch to the GPIO tree? Yours, Linus Walleij
Re: [PATCH v3 07/11] PCI: layerscape: Modify the way of getting capability with different PEX
On Mon, Sep 02, 2019 at 11:17:12AM +0800, Xiaowei Bao wrote:
> The different PCIe controller in one board may be have different
> capability of MSI or MSIX, so change the way of getting the MSI
> capability, make it more flexible.
>
> Signed-off-by: Xiaowei Bao
Please see the comments I just made to Kishon's feedback in the thread for
this patch in series v2.
Thanks,
Andrew Murray
> ---
> v2:
> - Remove the repeated assignment code.
> v3:
> - Use ep_func msi_cap and msix_cap to decide the msi_capable and
>msix_capable of pci_epc_features struct.
>
> drivers/pci/controller/dwc/pci-layerscape-ep.c | 31
> +++---
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index a9c552e..1e07287 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -22,6 +22,7 @@
>
> struct ls_pcie_ep {
> struct dw_pcie *pci;
> + struct pci_epc_features *ls_epc;
> };
>
> #define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> @@ -40,26 +41,31 @@ static const struct of_device_id ls_pcie_ep_of_match[] = {
> { },
> };
>
> -static const struct pci_epc_features ls_pcie_epc_features = {
> - .linkup_notifier = false,
> - .msi_capable = true,
> - .msix_capable = false,
> - .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> -};
> -
> static const struct pci_epc_features*
> ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
> {
> - return _pcie_epc_features;
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> +
> + return pcie->ls_epc;
> }
>
> static void ls_pcie_ep_init(struct dw_pcie_ep *ep)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> + struct dw_pcie_ep_func *ep_func;
> enum pci_barno bar;
>
> + ep_func = dw_pcie_ep_get_func_from_ep(ep, 0);
> + if (!ep_func)
> + return;
> +
> for (bar = BAR_0; bar <= BAR_5; bar++)
> dw_pcie_ep_reset_bar(pci, bar);
> +
> + pcie->ls_epc->msi_capable = ep_func->msi_cap ? true : false;
> + pcie->ls_epc->msix_capable = ep_func->msix_cap ? true : false;
> }
>
> static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> @@ -119,6 +125,7 @@ static int __init ls_pcie_ep_probe(struct platform_device
> *pdev)
> struct device *dev = >dev;
> struct dw_pcie *pci;
> struct ls_pcie_ep *pcie;
> + struct pci_epc_features *ls_epc;
> struct resource *dbi_base;
> int ret;
>
> @@ -130,6 +137,10 @@ static int __init ls_pcie_ep_probe(struct
> platform_device *pdev)
> if (!pci)
> return -ENOMEM;
>
> + ls_epc = devm_kzalloc(dev, sizeof(*ls_epc), GFP_KERNEL);
> + if (!ls_epc)
> + return -ENOMEM;
> +
> dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> if (IS_ERR(pci->dbi_base))
> @@ -140,6 +151,10 @@ static int __init ls_pcie_ep_probe(struct
> platform_device *pdev)
> pci->ops = _pcie_ep_ops;
> pcie->pci = pci;
>
> + ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> +
> + pcie->ls_epc = ls_epc;
> +
> platform_set_drvdata(pdev, pcie);
>
> ret = ls_add_pcie_ep(pcie, pdev);
> --
> 2.9.5
>
Re: [PATCH v2 1/2] dt-bindings: clock: mediatek: add pericfg for MT8183
On Wed, 28 Aug 2019 16:22:12 +0800, Chunfeng Yun wrote: > This patch adds binding of pericfg for MT8183. > > Signed-off-by: Chunfeng Yun > --- > v2: no changes > --- > .../devicetree/bindings/arm/mediatek/mediatek,pericfg.txt| 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v1 13/18] dt-bindings: Document loongson vendor-prefix
On Fri, 30 Aug 2019 12:32:27 +0800, Jiaxun Yang wrote: > Loongson is a MIPS-compatible processor vendor. > > Signed-off-by: Jiaxun Yang > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v3 02/16] dt-bindings: arm: Convert Marvell MMP board/soc bindings to json-schema
On Sat, 31 Aug 2019 00:07:29 +0200, Lubomir Rintel wrote: > Convert Marvell MMP SoC bindings to DT schema format using json-schema. > > Signed-off-by: Lubomir Rintel > > --- > Changes since v2: > - Add mrvl,pxa910 > - s/MMP2 Brownstone Board/MMP2 based boards/ > > Changes since v1: > - Added this patch > > .../devicetree/bindings/arm/mrvl/mrvl.txt | 14 > .../devicetree/bindings/arm/mrvl/mrvl.yaml| 32 +++ > 2 files changed, 32 insertions(+), 14 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.txt > create mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml > Reviewed-by: Rob Herring
Re: [PATCH v5, 05/32] dt-bindings: mediatek: add mutex description for mt8183 display
On Thu, 29 Aug 2019 22:50:27 +0800, wrote: > From: Yongqiang Niu > > This patch add mutex description for mt8183 display > > Signed-off-by: Yongqiang Niu > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v2 1/3] dt-bindings: mtd: cadence-qspi:add support for Intel lgm-qspi
On Tue, 27 Aug 2019 11:58:25 +0800, "Ramuthevar,Vadivel MuruganX" wrote: > From: Ramuthevar Vadivel Murugan > > Add new vendor specific compatible string to check Intel's Lightning > Mountain(LGM) QSPI features enablement in cadence-quadspi driver. > > Signed-off-by: Ramuthevar Vadivel Murugan > > --- > Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v3 2/7] dt-bindings: usb: mtk-xhci: support USB wakeup for MT8183
On Fri, 30 Aug 2019 15:40:49 +0800, Chunfeng Yun wrote: > Support USB wakeup by ip-sleep mode for MT8183 > > Signed-off-by: Chunfeng Yun > --- > v2~v3: no changes > --- > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v2 1/2] dt-bindings: phy: intel-sdxc-phy: Add YAML schema for LGM SDXC PHY
On Wed, Aug 28, 2019 at 08:43:14PM +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan
>
> Add a YAML schema to use the host controller driver with the
> SDXC PHY on Intel's Lightning Mountain SoC.
>
> Signed-off-by: Ramuthevar Vadivel Murugan
>
> ---
> .../bindings/phy/intel,lgm-sdxc-phy.yaml | 52
> ++
> .../devicetree/bindings/phy/intel,syscon.yaml | 33 ++
> 2 files changed, 85 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml
> create mode 100644 Documentation/devicetree/bindings/phy/intel,syscon.yaml
>
> diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml
> b/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml
> new file mode 100644
> index ..99647207b414
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/intel,lgm-sdxc-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel Lightning Mountain(LGM) SDXC PHY Device Tree Bindings
> +
> +maintainers:
> + - Ramuthevar Vadivel Murugan
> +
> +allOf:
> + - $ref: "intel,syscon.yaml"
You don't need this. It should be selected and applied by the compatible
string matching.
> +
> +description: Binding for SDXC PHY
> +
> +properties:
> + compatible:
> +const: intel,lgm-sdxc-phy
> +
> + intel,syscon:
> +description: phandle to the sdxc through syscon
> +
> + clocks:
> +maxItems: 1
> +
> + clock-names:
> +maxItems: 1
> +
> + "#phy-cells":
> +const: 0
> +
> +required:
> + - "#phy-cells"
> + - compatible
> + - intel,syscon
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +sdxc_phy: sdxc_phy {
> +compatible = "intel,lgm-sdxc-phy";
> +intel,syscon = <>;
Make this a child of the below node and then you don't need this.
If there's a register address range associated with this, then add a reg
property.
> +clocks = <>;
> +clock-names = "sdxcclk";
> +#phy-cells = <0>;
> +};
> +
> +...
> diff --git a/Documentation/devicetree/bindings/phy/intel,syscon.yaml
> b/Documentation/devicetree/bindings/phy/intel,syscon.yaml
> new file mode 100644
> index ..d0b78805e49f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/intel,syscon.yaml
> @@ -0,0 +1,33 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/intel,syscon.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Syscon for eMMC/SDXC PHY Device Tree Bindings
Nothing else in this h/w block? If there are other functions, then this
should not be in bindings/phy/.
> +
> +maintainers:
> + - Ramuthevar Vadivel Murugan
> +
> +properties:
> + compatible:
> +const: intel,syscon
Needs to be more specific and reflect h/w blocks. 'syscon' is a Linux
thing to some extent.
> +
> + reg:
> +maxItems: 1
> +
> + "#reset-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - "#reset-cells"
> +
> +examples:
> + - |
> +sysconf: chiptop@e002 {
> + compatible = "intel,syscon", "syscon";
> + reg = <0xe002 0x100>;
> + #reset-cells = <1>;
> +};
> --
> 2.11.0
>
Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
On Wed, Aug 28, 2019 at 03:02:58AM +, Peng Fan wrote:
> From: Peng Fan
>
> The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
> actions in software layers running in the EL2 or EL3 exception levels.
> The term "ARM" here relates to the SMC instruction as part of the ARM
> instruction set, not as a standard endorsed by ARM Ltd.
>
> Signed-off-by: Peng Fan
> ---
> .../devicetree/bindings/mailbox/arm-smc.yaml | 125
> +
> 1 file changed, 125 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
>
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> new file mode 100644
> index ..f8eb28d5e307
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> @@ -0,0 +1,125 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM SMC Mailbox Interface
> +
> +maintainers:
> + - Peng Fan
> +
> +description: |
> + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
> + call) instruction to trigger a mailbox-connected activity in firmware,
> + executing on the very same core as the caller. By nature this operation
> + is synchronous and this mailbox provides no way for asynchronous messages
> + to be delivered the other way round, from firmware to the OS, but
> + asynchronous notification could also be supported. However the value of
> + r0/w0/x0 the firmware returns after the smc call is delivered as a received
> + message to the mailbox framework, so a synchronous communication can be
> + established, for a asynchronous notification, no value will be returned.
> + The exact meaning of both the action the mailbox triggers as well as the
> + return value is defined by their users and is not subject to this binding.
> +
> + One use case of this mailbox is the SCMI interface, which uses shared
> memory
> + to transfer commands and parameters, and a mailbox to trigger a function
> + call. This allows SoCs without a separate management processor (or when
> + such a processor is not available or used) to use this standardized
> + interface anyway.
> +
> + This binding describes no hardware, but establishes a firmware interface.
> + Upon receiving an SMC using one of the described SMC function identifiers,
> + the firmware is expected to trigger some mailbox connected functionality.
> + The communication follows the ARM SMC calling convention.
> + Firmware expects an SMC function identifier in r0 or w0. The supported
> + identifiers are passed from consumers, or listed in the the arm,func-ids
> + properties as described below. The firmware can return one value in
> + the first SMC result register, it is expected to be an error value,
> + which shall be propagated to the mailbox client.
> +
> + Any core which supports the SMC or HVC instruction can be used, as long as
> + a firmware component running in EL3 or EL2 is handling these calls.
> +
> +properties:
> + compatible:
> +const: arm,smc-mbox
> +
> + "#mbox-cells":
> +const: 1
> +
> + arm,num-chans:
> +description: The number of channels supported.
> +items:
> + minimum: 1
> + maximum: 4096 # Should be enough?
> +
> + method:
> +- enum:
Did you build this with 'make dt_binding_check' as this should be a
warning. This should not be a list entry (i.e. drop the '-').
> +- smc
> +- hvc
> +
> + transports:
arm,transports
> +- enum:
> +- mem
> +- reg
> +
> + arm,func-ids:
> +description: |
> + An array of 32-bit values specifying the function IDs used by each
> + mailbox channel. Those function IDs follow the ARM SMC calling
> + convention standard [1].
> +
> + There is one identifier per channel and the number of supported
> + channels is determined by the length of this array.
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +minItems: 0
> +maxItems: 4096 # Should be enough?
> +
> +required:
> + - compatible
> + - "#mbox-cells"
> + - arm,num-chans
> + - transports
> + - method
> +
> +examples:
> + - |
> +sram@91 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x93f000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x93f000 0x1000>;
> +
> + cpu_scp_lpri: scp-shmem@0 {
> +compatible = "arm,scmi-shmem";
> +reg = <0x0 0x200>;
> + };
> +
> + cpu_scp_hpri: scp-shmem@200 {
> +compatible = "arm,scmi-shmem";
> +reg = <0x200 0x200>;
> + };
> +};
> +
> +firmware {
> + smc_mbox: mailbox {
> +#mbox-cells = <1>;
> +compatible = "arm,smc-mbox";
> +method = "smc";
> +arm,num-chans = <0x2>;
> +
Re: [PATCH RFC 05/14] dt-bindings/interrupt-controller: pdc: add SPI config register
On Thu, Aug 29, 2019 at 12:11:54PM -0600, Lina Iyer wrote:
> In addition to configuring the PDC, additional registers that interface
> the GIC have to be configured to match the GPIO type. The registers on
> some QCOM SoCs are access restricted, while on other SoCs are not. They
> SoCs with access restriction to these SPI registers need to be written
Took me a minute to figure out this is GIC SPI interrupts, not SPI bus.
> from the firmware using the SCM interface. Add a flag to indicate if the
> register is to be written using SCM interface.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Lina Iyer
> ---
> .../bindings/interrupt-controller/qcom,pdc.txt | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
> b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
> index 8e0797cb1487..852fcba98ea6 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
> @@ -50,15 +50,22 @@ Properties:
> The second element is the GIC hwirq number for the PDC port.
> The third element is the number of interrupts in sequence.
>
> +- qcom,scm-spi-cfg:
> + Usage: optional
> + Value type:
> + Definition: Specifies if the SPI configuration registers have to be
> + written from the firmware.
> +
> Example:
>
> pdc: interrupt-controller@b22 {
> compatible = "qcom,sdm845-pdc";
> - reg = <0xb22 0x3>;
> + reg = <0xb22 0x3>, <0x179900f0 0x60>;
There needs to be a description for reg updated. These aren't GIC
registers are they? Because those go in the GIC node.
> qcom,pdc-ranges = <0 512 94>, <94 641 15>, <115 662 7>;
> #interrupt-cells = <2>;
> interrupt-parent = <>;
> interrupt-controller;
> + qcom,scm-spi-cfg;
> };
>
> DT binding of a device that wants to use the GIC SPI 514 as a wakeup
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: [PATCH V3 08/10] dt-bindings: interconnect: add MT8183 interconnect dt-bindings
On Wed, Aug 28, 2019 at 08:28:46PM +0800, Henry Chen wrote:
> Add interconnect provider dt-bindings for MT8183.
>
> Signed-off-by: Henry Chen
> ---
> .../devicetree/bindings/soc/mediatek/dvfsrc.txt| 9 +
> include/dt-bindings/interconnect/mtk,mt8183-emi.h | 18
> ++
> 2 files changed, 27 insertions(+)
> create mode 100644 include/dt-bindings/interconnect/mtk,mt8183-emi.h
>
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.txt
> b/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.txt
> index 7f43499..da98ec9 100644
> --- a/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.txt
> +++ b/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.txt
> @@ -12,6 +12,11 @@ Required Properties:
> - clock-names: Must include the following entries:
> "dvfsrc": DVFSRC module clock
> - clocks: Must contain an entry for each entry in clock-names.
> +- #interconnect-cells : should contain 1
> +- interconnect : interconnect providers support dram bandwidth requirements.
> + The provider is able to communicate with the DVFSRC and send the dram
> + bandwidth to it. shall contain only one of the following:
> + "mediatek,mt8183-emi"
>
> Example:
>
> @@ -20,4 +25,8 @@ Example:
> reg = <0 0x10012000 0 0x1000>;
> clocks = < CLK_INFRA_DVFSRC>;
> clock-names = "dvfsrc";
> + ddr_emi: interconnect {
The EMI is a sub-module in the DVFSRC? This is the DDR controller or
something else?
> + compatible = "mediatek,mt8183-emi";
> + #interconnect-cells = <1>;
> + };
> };
Re: [PATCH 1/5] dt-bindings: fsl: scu: add scu power key binding
On Fri, Aug 30, 2019 at 04:53:45PM -0400, Anson Huang wrote:
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> system controller, the system controller is in charge of system
> power, clock and power key event etc. management, Linux kernel
> has to communicate with system controller via MU (message unit)
> IPC to get power key event, add binding doc for i.MX system
> controller power key driver.
>
> Signed-off-by: Anson Huang
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 18
> ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> index c149fad..001d0b7 100644
> --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -157,6 +157,17 @@ Required properties:
> Optional properties:
> - timeout-sec: contains the watchdog timeout in seconds.
>
> +Power key bindings based on SCU Message Protocol
> +
> +
> +Required properties:
> +- compatible: should be:
> + "fsl,imx8qxp-sc-pwrkey"
> + followed by "fsl,imx-sc-pwrkey";
> +- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
> +Optional Properties:
> +- wakeup-source: See
> Documentation/devicetree/bindings/power/wakeup-source.txt
> +
> Example (imx8qxp):
> -
> aliases {
> @@ -220,6 +231,13 @@ firmware {
> compatible = "fsl,imx8qxp-sc-rtc";
> };
>
> + scu_pwrkey: scu-pwrkey {
> + compatible = "fsl,imx8qxp-sc-pwrkey",
> "fsl,imx-sc-pwrkey";
> + linux,keycode = ;
> + wakeup-source;
wakeup-source implies an interrupt property.
> + status = "disabled";
Don't should status in examples.
> + };
> +
> watchdog {
> compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
> timeout-sec = <60>;
> --
> 2.7.4
>
Re: [PATCH v4 2/3] scsi: ufs-qcom: Implement device_reset vops
On Wed, 28 Aug 2019 12:17:55 -0700, Bjorn Andersson wrote: > The UFS_RESET pin on Qualcomm SoCs are controlled by TLMM and exposed > through the GPIO framework. Acquire the device-reset GPIO and use this > to implement the device_reset vops, to allow resetting the attached > memory. > > Based on downstream support implemented by Subhash Jadavani > . > > Signed-off-by: Bjorn Andersson > --- > > Changes since v3: > - Renamed device-reset-gpios to just reset-gpios. > - Explicitly bail on !host->device_reset, to not rely on passing NULL to > gpiod_set_value_cansleep() > > .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 2 ++ > drivers/scsi/ufs/ufs-qcom.c | 36 +++ > drivers/scsi/ufs/ufs-qcom.h | 4 +++ > 3 files changed, 42 insertions(+) > Acked-by: Rob Herring
Re: [PATCH next v11 03/11] dt-bindings: usb: add binding for USB GPIO based connection detection driver
On Thu, 29 Aug 2019 17:22:30 +0800, Chunfeng Yun wrote: > It's used to support dual role switch via GPIO when use Type-B > receptacle, typically the USB ID pin is connected to an input > GPIO, and also used to enable/disable device when the USB Vbus > pin is connected to an input GPIO. > > Signed-off-by: Chunfeng Yun > Reviewed-by: Linus Walleij > --- > v11 changes: > 1. add Reviewed-by Linus > 2. change compatible as "gpio-usb-b-connector", and remove label > in example suggested by Rob > > v9~v10 no changes > > v8 changes: > 1. rename the title > 2. change the compatible as "linux,usb-conn-gpio" instead of > "linux,typeb-conn-gpio" > > v7 changes: > 1. add description for device only mode > > v6 changes: > 1. remove status and port nodes in example > 2. make vbus-supply as optional property > > v5 changes: > 1. treat type-B connector as child device of USB controller's, but not > as a separate virtual device, suggested by Rob > 2. put connector's port node under connector node, suggested by Rob > > v4 no changes > > v3 changes: > 1. treat type-B connector as a virtual device, but not child device of > USB controller's > > v2 changes: > 1. new patch to make binding clear suggested by Hans > --- > .../devicetree/bindings/usb/usb-conn-gpio.txt | 30 +++ > 1 file changed, 30 insertions(+) > create mode 100644 Documentation/devicetree/bindings/usb/usb-conn-gpio.txt > Reviewed-by: Rob Herring
Re: [PATCH] dt-bindings: serial: Convert riscv,sifive-serial to json-schema
On Sun, Sep 01, 2019 at 12:39:21PM +0530, Pragnesh Patel wrote:
> Convert the riscv,sifive-serial binding to DT schema using json-schema.
>
> Signed-off-by: Pragnesh Patel
> ---
> .../devicetree/bindings/serial/sifive-serial.txt | 33
> .../devicetree/bindings/serial/sifive-serial.yaml | 62
> ++
> 2 files changed, 62 insertions(+), 33 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/serial/sifive-serial.txt
> create mode 100644
> Documentation/devicetree/bindings/serial/sifive-serial.yaml
>
> diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.txt
> b/Documentation/devicetree/bindings/serial/sifive-serial.txt
> deleted file mode 100644
> index c86b1e5..000
> --- a/Documentation/devicetree/bindings/serial/sifive-serial.txt
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -SiFive asynchronous serial interface (UART)
> -
> -Required properties:
> -
> -- compatible: should be something similar to
> - "sifive,-uart" for the UART as integrated
> - on a particular chip, and "sifive,uart" for the
> - general UART IP block programming model. Supported
> - compatible strings as of the date of this writing are:
> - "sifive,fu540-c000-uart" for the SiFive UART v0 as
> - integrated onto the SiFive FU540 chip, or "sifive,uart0"
> - for the SiFive UART v0 IP block with no chip integration
> - tweaks (if any)
> -- reg: address and length of the register space
> -- interrupts: Should contain the UART interrupt identifier
> -- clocks: Should contain a clock identifier for the UART's parent clock
> -
> -
> -UART HDL that corresponds to the IP block version numbers can be found
> -here:
> -
> -https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/uart
> -
> -
> -Example:
> -
> -uart0: serial@1001 {
> - compatible = "sifive,fu540-c000-uart", "sifive,uart0";
> - interrupt-parent = <>;
> - interrupts = <80>;
> - reg = <0x0 0x1001 0x0 0x1000>;
> - clocks = < PRCI_CLK_TLCLK>;
> -};
> diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml
> b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
> new file mode 100644
> index 000..56fa935
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/serial/sifive-serial.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SiFive asynchronous serial interface (UART)
> +
> +maintainers:
> + - Pragnesh Patel
> + - Paul Walmsley
> + - Palmer Dabbelt
> +
> +allOf:
> + - $ref: /schemas/serial.yaml#
> +
> +properties:
> + compatible:
> +enum:
> + - sifive,fu540-c000-uart
> + - sifive,uart0
This is wrong and should have warned if you tested this on 5.3.
items:
- const: sifive,fu540-c000-uart
- const: sifive,uart0
> +
> +description:
> + Should be something similar to "sifive,-uart"
> + for the UART as integrated on a particular chip,
> + and "sifive,uart" for the general UART IP
> + block programming model.
> +
> + UART HDL that corresponds to the IP block version
> + numbers can be found here -
> +
> +
> https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/uart
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + clocks:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include
> + serial@1001 {
> +compatible = "sifive,fu540-c000-uart", "sifive,uart0";
> +interrupt-parent = <>;
> +interrupts = <80>;
> +reg = <0x0 0x1001 0x0 0x1000>;
> +clocks = < PRCI_CLK_TLCLK>;
> + };
> +
> +...
> --
> 2.7.4
>
Re: [PATCH v1 06/18] dt-bindings: interrupt-controller: Add Loongson-3 IOINTC
On Fri, Aug 30, 2019 at 12:32:20PM +0800, Jiaxun Yang wrote:
> Document Loongson-3 I/O Interrupt controller.
>
> Signed-off-by: Jiaxun Yang
> ---
> .../loongson,ls3-iointc.yaml | 75 +++
> 1 file changed, 75 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
>
> b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
> new file mode 100644
> index ..9aee10abd5cd
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
> @@ -0,0 +1,75 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> "http://devicetree.org/schemas/interrupt-controller/loongson,ls3-iointc.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Loongson-3 I/O Interrupt Controller
> +
> +maintainers:
> + - Jiaxun Yang
> +
> +description: |
> + This interrupt controller is found in the Loongson-3 family of chips as
> the primary
> + package interrupt source which can route interrupt to interrupt line of
> cores.
> +
> +properties:
> + compatible:
> +const: loongson,ls3-iointc
> +
> + reg:
> +maxItems: 1
> +
> +
Extra blank line.
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> +description: |
> + Specifies the number of cells needed to encode an interrupt source.
> + Must be 2 or 4.
> + If the system requires describing interrupt line & core mapping, than
> + it must be 4.
> +
> + The 1st cell is the hardware interrupt number.
> +
> + The 2nd cell is the flags, encoded as follows:
> +bits[3:0] trigger type and level flags.
> + 1 = low-to-high edge triggered
> + 2 = high-to-low edge triggered
> + 4 = active high level-sensitive
> + 8 = active low level-sensitive.
> +
> + The 3rd is the parent interrupt line that interrupt would map to.
> + As the CPU preserved 4 interrupt lines for I/O, in theory any of the
> iointc
> + interrupt can be chained to any interrupt lines on a core. But
> currently
> + we can only map all the interrupt to a single parent, so this cell
> must be
> + set uniformly for all the child interrupts corresponding to the parent
> + interrupt.
> +
> + The 4th is the parent core that interrupt would map to. The interrupt
> + contoller can map any of the interrupt to the specified core on a
> package.
> + This cell determined the core. It must be the bootcore.
> +
> + If the 3rd, 4th cell is not set, it will default to the 0# interrupt
> line
> + and bootcore.
> +
> +enum: [ 2, 4 ]
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
Missing from the property list and needs to define how many.
> + - interrupt-controller
> + - '#interrupt-cells'
> +
> +
> +examples:
> + - |
> +iointc: interrupt-controller@3ff01400 {
> +compatible = "loongson,ls3-io-intc";
> +reg = <0x3ff01400 0x60>;
> +interrupts = <2>;
> +interrupt-controller;
> +#interrupt-cells = <4>;
> +};
> +...
> --
> 2.22.0
>
Re: [BUG] Use of probe_kernel_address() in task_rcu_dereference() without checking return value
On 08/30, Eric W. Biederman wrote:
>
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -182,6 +182,24 @@ static void delayed_put_task_struct(struct rcu_head *rhp)
> put_task_struct(tsk);
> }
>
> +void put_dead_task_struct(struct task_struct *task)
> +{
> + bool delay = false;
> + unsigned long flags;
> +
> + /* Is the task both reaped and no longer being scheduled? */
> + raw_spin_lock_irqsave(>pi_lock, flags);
> + if ((task->state == TASK_DEAD) &&
> + (cmpxchg(>exit_state, EXIT_DEAD, EXIT_RCU) == EXIT_DEAD))
> + delay = true;
> + raw_spin_lock_irqrestore(>pi_lock, flags);
> +
> + /* If both are true use rcu delay the put_task_struct */
> + if (delay)
> + call_rcu(>rcu, delayed_put_task_struct);
> + else
> + put_task_struct(task);
> +}
>
> void release_task(struct task_struct *p)
> {
> @@ -222,76 +240,13 @@ void release_task(struct task_struct *p)
>
> write_unlock_irq(_lock);
> release_thread(p);
> - call_rcu(>rcu, delayed_put_task_struct);
> + put_dead_task_struct(p);
I had a similar change in mind, see below. This is subjective, but to me
it looks more simple and clean.
Oleg.
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8dc1811..1f9b021 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1134,7 +1134,10 @@ struct task_struct {
struct tlbflush_unmap_batch tlb_ubc;
- struct rcu_head rcu;
+ union {
+ boolxxx;
+ struct rcu_head rcu;
+ };
/* Cache last used pipe for splice(): */
struct pipe_inode_info *splice_pipe;
diff --git a/kernel/exit.c b/kernel/exit.c
index a75b6a7..baacfce 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -182,6 +182,11 @@ static void delayed_put_task_struct(struct rcu_head *rhp)
put_task_struct(tsk);
}
+void call_delayed_put_task_struct(struct task_struct *p)
+{
+ if (xchg(>xxx, 1))
+ call_rcu(>rcu, delayed_put_task_struct);
+}
void release_task(struct task_struct *p)
{
@@ -222,7 +227,7 @@ void release_task(struct task_struct *p)
write_unlock_irq(_lock);
release_thread(p);
- call_rcu(>rcu, delayed_put_task_struct);
+ call_delayed_put_task_struct(p);
p = leader;
if (unlikely(zap_leader))
diff --git a/kernel/fork.c b/kernel/fork.c
index d8ae0f1..e90f6de 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -900,11 +900,7 @@ static struct task_struct *dup_task_struct(struct
task_struct *orig, int node)
if (orig->cpus_ptr == >cpus_mask)
tsk->cpus_ptr = >cpus_mask;
- /*
-* One for us, one for whoever does the "release_task()" (usually
-* parent)
-*/
- refcount_set(>usage, 2);
+ refcount_set(>usage, 1);
#ifdef CONFIG_BLK_DEV_IO_TRACE
tsk->btrace_seq = 0;
#endif
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2b037f1..e77389c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3135,7 +3135,7 @@ static struct rq *finish_task_switch(struct task_struct
*prev)
/* Task is done with its stack. */
put_task_stack(prev);
- put_task_struct(prev);
+ call_delayed_put_task_struct(prev);
}
tick_nohz_task_switch();
Re: [PATCH 1/7] iommu/arm-smmu: add Nvidia SMMUv2 implementation
On 30/08/2019 19:16, Krishna Reddy wrote: +ARM_SMMU_MATCH_DATA(nvidia_smmuv2, ARM_SMMU_V2, NVIDIA_SMMUV2); From the previous discussions, I got the impression that other than the 'novel' way they're integrated, the actual SMMU implementations were unmodified Arm MMU-500s. Is that the case, or have I misread something? The ARM MMU-500 implementation is unmodified. It is the way the are integrated and used together(for interleaved accesses) is different from regular ARM MMU-500. I have added it to get the model number and to be able differentiate the SMMU implementation in arm-smmu-impl.c. In that case, I would rather keep smmu->model representing the MMU-500 microarchitecture - since you'll still want to pick up errata workarounds etc. for that - and detect the Tegra integration via an explicit of_device_is_compatible() check in arm_smmu_impl_init(). For comparison, under ACPI we'd probably have to detect integration details by looking at table headers, separately from the IORT "Model" field, so I'd prefer if the DT vs. ACPI handling didn't diverge more than necessary. Of course, that immediately opens the question of how best to combine arm_mmu500_impl with nsmmu_impl, but hey, one step at a time :) Robin.
Re: [PATCH 1/2] iommu: Implement of_iommu_get_resv_regions()
On Thu, 29 Aug 2019 13:14:06 +0200, Thierry Reding wrote: > From: Thierry Reding > > This is an implementation that IOMMU drivers can use to obtain reserved > memory regions from a device tree node. It uses the reserved-memory DT > bindings to find the regions associated with a given device. These > regions will be used to create 1:1 mappings in the IOMMU domain that > the devices will be attached to. > > Cc: Rob Herring > Cc: Frank Rowand > Cc: devicet...@vger.kernel.org > Signed-off-by: Thierry Reding > --- > drivers/iommu/of_iommu.c | 39 +++ > include/linux/of_iommu.h | 8 > 2 files changed, 47 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v1 08/18] dt-bindings: interrupt-controller: Add Loongson-3 HTINTC
On Fri, 30 Aug 2019 12:32:22 +0800, Jiaxun Yang wrote: > Document Loongson-3 HyperTransport Interrupt controller. > > Signed-off-by: Jiaxun Yang > --- > .../loongson,ls3-htintc.yaml | 55 +++ > 1 file changed, 55 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-htintc.yaml > Reviewed-by: Rob Herring
Re: [PATCH v3 1/7] dt-bindings: usb: mtu3: support USB wakeup for MT8183
On Fri, 30 Aug 2019 15:40:48 +0800, Chunfeng Yun wrote: > Support USB wakeup by ip-sleep mode for MT8183 > > Signed-off-by: Chunfeng Yun > --- > v2~v3: no changes > --- > Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
