Re: [PATCH RFC] kprobes: Remove MODULES dependency
On Fri, Jul 10, 2020 at 08:51:56AM -0700, Kees Cook wrote:
> On Fri, Jul 10, 2020 at 07:32:57PM +0900, Masami Hiramatsu wrote:
> > On Fri, 10 Jul 2020 02:45:19 +0300
> > Jarkko Sakkinen wrote:
> > > +#ifdef CONFIG_MODULES
> > > /* Lock modules while optimizing kprobes */
> > > mutex_lock(_mutex);
> > > +#endif
> >
> > Hmm, can you reduce these "#ifdef CONFIG_MODULE"s ?
> >
> > e.g.
> >
> > #ifdef CONFIG_MODULES
> > static void lock_modules(void)
> > {
> > mutex_lock(_mutex);
> > }
> > ...
> > #else
> > #define lock_modules() do { } while (0)
> > ...
> > #endif
>
> I prefer using "static inline" for no-op functions just because they
> will maintain argument type validation by the compiler regardless of the
> CONFIG state (though it doesn't really matter here since it's void).
>
> #else
> static inline lock_modules(void) { }
> #endif
>
> --
> Kees Cook
Thanks Kees, good remark.
/Jarkko
Re: [PATCH RFC] kprobes: Remove MODULES dependency
On Fri, Jul 10, 2020 at 09:22:43AM -0400, Steven Rostedt wrote:
> On Fri, 10 Jul 2020 22:18:02 +0900
> Masami Hiramatsu wrote:
>
> >
> > Agreed. As far as I know, ftrace and bpf also depends on module_alloc(),
> > so text_alloc() will help them too.
> >
>
> Yes please.
>
> arch/x86/kernel/ftrace.c:
>
> #ifdef CONFIG_MODULES
> #include
> /* Module allocation simplifies allocating memory for code */
> static inline void *alloc_tramp(unsigned long size)
> {
> return module_alloc(size);
> }
> static inline void tramp_free(void *tramp)
> {
> module_memfree(tramp);
> }
> #else
> /* Trampolines can only be created if modules are supported */
> static inline void *alloc_tramp(unsigned long size)
> {
> return NULL;
> }
> static inline void tramp_free(void *tramp) { }
> #endif
>
> -- Steve
Thanks, note taken. I'll take this into account in the next version.
/Jarkko
Re: [PATCH 5/9] phy: qcom-qmp: use correct values for ipq8074 gen2 pcie phy init
On 05-07-20, 14:47, Sivaprakash Murugesan wrote:
> There were some problem in ipq8074 gen2 pcie phy init sequence, fix
Can you please describe these problems, it would help review to
understand the issues and also for future reference to you
> these to make gen2 pcie port on ipq8074 to work.
>
> Fixes: eef243d04b2b6 ("phy: qcom-qmp: Add support for IPQ8074")
>
> Cc: sta...@vger.kernel.org
> Co-developed-by: Selvam Sathappan Periakaruppan
> Signed-off-by: Selvam Sathappan Periakaruppan
> Signed-off-by: Sivaprakash Murugesan
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 16 +---
> drivers/phy/qualcomm/phy-qcom-qmp.h | 2 ++
> 2 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index e91040af3394..ba277136f52b 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -504,8 +504,8 @@ static const struct qmp_phy_init_tbl
> ipq8074_pcie_serdes_tbl[] = {
> QMP_PHY_INIT_CFG(QSERDES_COM_BG_TRIM, 0xf),
> QMP_PHY_INIT_CFG(QSERDES_COM_LOCK_CMP_EN, 0x1),
> QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_MAP, 0x0),
> - QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER1, 0x1f),
> - QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER2, 0x3f),
> + QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER1, 0xff),
> + QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER2, 0x1f),
> QMP_PHY_INIT_CFG(QSERDES_COM_CMN_CONFIG, 0x6),
> QMP_PHY_INIT_CFG(QSERDES_COM_PLL_IVCO, 0xf),
> QMP_PHY_INIT_CFG(QSERDES_COM_HSCLK_SEL, 0x0),
> @@ -531,7 +531,6 @@ static const struct qmp_phy_init_tbl
> ipq8074_pcie_serdes_tbl[] = {
> QMP_PHY_INIT_CFG(QSERDES_COM_INTEGLOOP_GAIN1_MODE0, 0x0),
> QMP_PHY_INIT_CFG(QSERDES_COM_INTEGLOOP_GAIN0_MODE0, 0x80),
> QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CTRL_BY_PSM, 0x1),
> - QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_CTRL, 0xa),
> QMP_PHY_INIT_CFG(QSERDES_COM_SSC_EN_CENTER, 0x1),
> QMP_PHY_INIT_CFG(QSERDES_COM_SSC_PER1, 0x31),
> QMP_PHY_INIT_CFG(QSERDES_COM_SSC_PER2, 0x1),
> @@ -540,7 +539,6 @@ static const struct qmp_phy_init_tbl
> ipq8074_pcie_serdes_tbl[] = {
> QMP_PHY_INIT_CFG(QSERDES_COM_SSC_STEP_SIZE1, 0x2f),
> QMP_PHY_INIT_CFG(QSERDES_COM_SSC_STEP_SIZE2, 0x19),
> QMP_PHY_INIT_CFG(QSERDES_COM_CLK_EP_DIV, 0x19),
> - QMP_PHY_INIT_CFG(QSERDES_RX_SIGDET_CNTRL, 0x7),
> };
>
> static const struct qmp_phy_init_tbl ipq8074_pcie_tx_tbl[] = {
> @@ -548,6 +546,8 @@ static const struct qmp_phy_init_tbl
> ipq8074_pcie_tx_tbl[] = {
> QMP_PHY_INIT_CFG(QSERDES_TX_LANE_MODE, 0x6),
> QMP_PHY_INIT_CFG(QSERDES_TX_RES_CODE_LANE_OFFSET, 0x2),
> QMP_PHY_INIT_CFG(QSERDES_TX_RCV_DETECT_LVL_2, 0x12),
> + QMP_PHY_INIT_CFG(QSERDES_TX_EMP_POST1_LVL, 0x36),
> + QMP_PHY_INIT_CFG(QSERDES_TX_SLEW_CNTL, 0x0a),
> };
>
> static const struct qmp_phy_init_tbl ipq8074_pcie_rx_tbl[] = {
> @@ -558,7 +558,6 @@ static const struct qmp_phy_init_tbl
> ipq8074_pcie_rx_tbl[] = {
> QMP_PHY_INIT_CFG(QSERDES_RX_RX_EQU_ADAPTOR_CNTRL4, 0xdb),
> QMP_PHY_INIT_CFG(QSERDES_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x4b),
> QMP_PHY_INIT_CFG(QSERDES_RX_UCDR_SO_GAIN, 0x4),
> - QMP_PHY_INIT_CFG(QSERDES_RX_UCDR_SO_GAIN_HALF, 0x4),
> };
>
> static const struct qmp_phy_init_tbl ipq8074_pcie_pcs_tbl[] = {
> @@ -1673,6 +1672,9 @@ static const struct qmp_phy_cfg msm8996_usb3phy_cfg = {
> .pwrdn_ctrl = SW_PWRDN,
> };
>
> +static const char * const ipq8074_pciephy_clk_l[] = {
> + "aux", "cfg_ahb",
> +};
> /* list of resets */
> static const char * const ipq8074_pciephy_reset_l[] = {
> "phy", "common",
> @@ -1690,8 +1692,8 @@ static const struct qmp_phy_cfg ipq8074_pciephy_cfg = {
> .rx_tbl_num = ARRAY_SIZE(ipq8074_pcie_rx_tbl),
> .pcs_tbl= ipq8074_pcie_pcs_tbl,
> .pcs_tbl_num= ARRAY_SIZE(ipq8074_pcie_pcs_tbl),
> - .clk_list = NULL,
> - .num_clks = 0,
> + .clk_list = ipq8074_pciephy_clk_l,
> + .num_clks = ARRAY_SIZE(ipq8074_pciephy_clk_l),
I see patch is modifying some register values and then adding clks, in
the absence of proper patch description it is extremely hard to
understand what is going on..
> .reset_list = ipq8074_pciephy_reset_l,
> .num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l),
> .vreg_list = NULL,
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h
> b/drivers/phy/qualcomm/phy-qcom-qmp.h
> index 6d017a0c0c8d..832b3d098403 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.h
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.h
> @@ -77,6 +77,8 @@
> #define QSERDES_COM_CORECLK_DIV_MODE10x1bc
>
> /* Only for QMP V2 PHY - TX registers */
> +#define QSERDES_TX_EMP_POST1_LVL 0x018
> +#define QSERDES_TX_SLEW_CNTL
Re: [PATCH v2 1/3] powerpc/powernv/idle: Exclude mfspr on HID1, 4, 5 on P9 and above
Excerpts from Pratik Rajesh Sampat's message of July 10, 2020 3:22 pm:
> POWER9 onwards the support for the registers HID1, HID4, HID5 has been
> receded.
> Although mfspr on the above registers worked in Power9, In Power10
> simulator is unrecognized. Moving their assignment under the
> check for machines lower than Power9
Seems like a good fix.
Thanks,
Nick
>
> Signed-off-by: Pratik Rajesh Sampat
> Reviewed-by: Gautham R. Shenoy
> ---
> arch/powerpc/platforms/powernv/idle.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/idle.c
> b/arch/powerpc/platforms/powernv/idle.c
> index 2dd467383a88..19d94d021357 100644
> --- a/arch/powerpc/platforms/powernv/idle.c
> +++ b/arch/powerpc/platforms/powernv/idle.c
> @@ -73,9 +73,6 @@ static int pnv_save_sprs_for_deep_states(void)
>*/
> uint64_t lpcr_val = mfspr(SPRN_LPCR);
> uint64_t hid0_val = mfspr(SPRN_HID0);
> - uint64_t hid1_val = mfspr(SPRN_HID1);
> - uint64_t hid4_val = mfspr(SPRN_HID4);
> - uint64_t hid5_val = mfspr(SPRN_HID5);
> uint64_t hmeer_val = mfspr(SPRN_HMEER);
> uint64_t msr_val = MSR_IDLE;
> uint64_t psscr_val = pnv_deepest_stop_psscr_val;
> @@ -117,6 +114,9 @@ static int pnv_save_sprs_for_deep_states(void)
>
> /* Only p8 needs to set extra HID regiters */
> if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
> + uint64_t hid1_val = mfspr(SPRN_HID1);
> + uint64_t hid4_val = mfspr(SPRN_HID4);
> + uint64_t hid5_val = mfspr(SPRN_HID5);
>
> rc = opal_slw_set_reg(pir, SPRN_HID1, hid1_val);
> if (rc != 0)
> --
> 2.25.4
>
>
[PATCH] watchdog: pcwd_usb: remove needless check before usb_free_coherent()
usb_free_coherent() is safe with NULL usb_pcwd->intr_buffer and
this check is not required.
Signed-off-by: Xu Wang
---
drivers/watchdog/pcwd_usb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/watchdog/pcwd_usb.c b/drivers/watchdog/pcwd_usb.c
index 2f44af1831d0..6726301ac02e 100644
--- a/drivers/watchdog/pcwd_usb.c
+++ b/drivers/watchdog/pcwd_usb.c
@@ -585,9 +585,8 @@ static struct notifier_block usb_pcwd_notifier = {
static inline void usb_pcwd_delete(struct usb_pcwd_private *usb_pcwd)
{
usb_free_urb(usb_pcwd->intr_urb);
- if (usb_pcwd->intr_buffer != NULL)
- usb_free_coherent(usb_pcwd->udev, usb_pcwd->intr_size,
- usb_pcwd->intr_buffer, usb_pcwd->intr_dma);
+ usb_free_coherent(usb_pcwd->udev, usb_pcwd->intr_size,
+ usb_pcwd->intr_buffer, usb_pcwd->intr_dma);
kfree(usb_pcwd);
}
--
2.17.1
Re: [PATCH v2 2/3] powerpc/powernv/idle: save-restore DAWR0, DAWRX0 for P10
Excerpts from Pratik Rajesh Sampat's message of July 10, 2020 3:22 pm:
> Additional registers DAWR0, DAWRX0 may be lost on Power 10 for
> stop levels < 4.
> Therefore save the values of these SPRs before entering a "stop"
> state and restore their values on wakeup.
Hmm, where do you get this from? Documentation I see says DAWR is lost
on POWER9 but not P10.
Does idle thread even need to save DAWR, or does it get switched when
going to a thread that has a watchpoint set?
Thanks,
Nick
>
> Signed-off-by: Pratik Rajesh Sampat
> ---
> arch/powerpc/platforms/powernv/idle.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/idle.c
> b/arch/powerpc/platforms/powernv/idle.c
> index 19d94d021357..f2e2a6a4c274 100644
> --- a/arch/powerpc/platforms/powernv/idle.c
> +++ b/arch/powerpc/platforms/powernv/idle.c
> @@ -600,6 +600,8 @@ struct p9_sprs {
> u64 iamr;
> u64 amor;
> u64 uamor;
> + u64 dawr0;
> + u64 dawrx0;
> };
>
> static unsigned long power9_idle_stop(unsigned long psscr, bool mmu_on)
> @@ -687,6 +689,10 @@ static unsigned long power9_idle_stop(unsigned long
> psscr, bool mmu_on)
> sprs.iamr = mfspr(SPRN_IAMR);
> sprs.amor = mfspr(SPRN_AMOR);
> sprs.uamor = mfspr(SPRN_UAMOR);
> + if (cpu_has_feature(CPU_FTR_ARCH_31)) {
> + sprs.dawr0 = mfspr(SPRN_DAWR0);
> + sprs.dawrx0 = mfspr(SPRN_DAWRX0);
> + }
>
> srr1 = isa300_idle_stop_mayloss(psscr); /* go idle */
>
> @@ -710,6 +716,10 @@ static unsigned long power9_idle_stop(unsigned long
> psscr, bool mmu_on)
> mtspr(SPRN_IAMR,sprs.iamr);
> mtspr(SPRN_AMOR,sprs.amor);
> mtspr(SPRN_UAMOR, sprs.uamor);
> + if (cpu_has_feature(CPU_FTR_ARCH_31)) {
> + mtspr(SPRN_DAWR0, sprs.dawr0);
> + mtspr(SPRN_DAWRX0, sprs.dawrx0);
> + }
>
> /*
>* Workaround for POWER9 DD2.0, if we lost resources, the ERAT
> --
> 2.25.4
>
>
Re: [PATCH RFC] kprobes: Remove MODULES dependency
On Fri, Jul 10, 2020 at 03:04:29PM +0200, Christoph Hellwig wrote: > On Fri, Jul 10, 2020 at 01:32:38PM +0200, Peter Zijlstra wrote: > > On Fri, Jul 10, 2020 at 07:32:57PM +0900, Masami Hiramatsu wrote: > > > > - page = module_alloc(PAGE_SIZE); > > > > + page = vmalloc(PAGE_SIZE); > > > > > > No, you can not use vmalloc here. The reason why we use module_alloc() > > > is to allocate the executable memory for trampoline code. > > > So, you need to use vmalloc_exec() instead. > > > > vmalloc_exec() would be broken too, also hch recently got rid of that > > thing. > > > > module_alloc() really is the only sane choice here. > > > > We should make module_alloc() unconditionally available, and maybe even > > rename it to text_alloc(). > > I think unconitionally might be a bit too much, but for > MODULES || KRPOBES or a new symbol select by them makes sense. As does > the rename. Given that they are simple wrappers, would it be too much harmo to have inline functions for text_alloc() and text_memfree() and use them inside module_alloc() and alloc_memfree() in order not to initially turn things over too much? /Jarkko
Re: [PATCH v5 2/2] phy: bcm63xx-usbh: Add BCM63xx USBH driver
On 19-06-20, 12:00, Álvaro Fernández Rojas wrote:
> Add BCM63xx USBH PHY driver for BMIPS.
>
> Signed-off-by: Álvaro Fernández Rojas
> ---
> v5: use devm_reset_control_get_exclusive.
> v4: several improvements:
> - Use devm_platform_ioremap_resource.
> - Code cleanups.
> - Improve device mode config:
> - Move USBH_SWAP_CONTROL device mode value to variant variable.
> - Set USBH_UTMI_CONTROL1 register value (variant variable).
> v3: introduce changes suggested by Florian:
> - Add support for device mode.
> v2: introduce changes suggested by Florian:
> - Drop OF dependency (use device_get_match_data).
> - Drop __initconst from variant tables.
> - Use devm_clk_get_optional.
>
> drivers/phy/broadcom/Kconfig| 9 +
> drivers/phy/broadcom/Makefile | 1 +
> drivers/phy/broadcom/phy-bcm63xx-usbh.c | 457
> 3 files changed, 467 insertions(+)
> create mode 100644 drivers/phy/broadcom/phy-bcm63xx-usbh.c
>
> diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
> index b29f11c19155..a7889df8c541 100644
> --- a/drivers/phy/broadcom/Kconfig
> +++ b/drivers/phy/broadcom/Kconfig
> @@ -2,6 +2,15 @@
> #
> # Phy drivers for Broadcom platforms
> #
> +config PHY_BCM63XX_USBH
> + tristate "BCM63xx USBH PHY driver"
> + depends on BMIPS_GENERIC || COMPILE_TEST
> + select GENERIC_PHY
> + default BMIPS_GENERIC
you depend on BMIPS_GENERIC and also use as default?
> +static int __init bcm63xx_usbh_phy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct bcm63xx_usbh_phy *usbh;
> + const struct bcm63xx_usbh_phy_variant *variant;
> + struct phy *phy;
> + struct phy_provider *phy_provider;
> +
> + usbh = devm_kzalloc(dev, sizeof(*usbh), GFP_KERNEL);
> + if (!usbh)
> + return -ENOMEM;
> +
> + variant = device_get_match_data(dev);
> + if (!variant)
> + return -EINVAL;
> + usbh->variant = variant;
> +
> + usbh->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(usbh->base))
> + return PTR_ERR(usbh->base);
> +
> + usbh->reset = devm_reset_control_get_exclusive(dev, NULL);
> + if (IS_ERR(usbh->reset)) {
> + if (PTR_ERR(usbh->reset) != -EPROBE_DEFER)
> + dev_err(dev, "failed to get reset\n");
> + return PTR_ERR(usbh->reset);
> + }
> +
> + usbh->usbh_clk = devm_clk_get_optional(dev, "usbh");
> + if (IS_ERR(usbh->usbh_clk))
> + return PTR_ERR(usbh->usbh_clk);
> +
> + usbh->usb_ref_clk = devm_clk_get_optional(dev, "usb_ref");
> + if (IS_ERR(usbh->usb_ref_clk))
> + return PTR_ERR(usbh->usb_ref_clk);
> +
> + phy = devm_phy_create(dev, NULL, _usbh_phy_ops);
> + if (IS_ERR(phy)) {
> + dev_err(dev, "failed to create PHY\n");
> + return PTR_ERR(phy);
> + }
> +
> + platform_set_drvdata(pdev, usbh);
> + phy_set_drvdata(phy, usbh);
> +
> + phy_provider = devm_of_phy_provider_register(dev,
> + bcm63xx_usbh_phy_xlate);
> + if (IS_ERR(phy_provider)) {
> + dev_err(dev, "failed to register PHY provider\n");
> + return PTR_ERR(phy_provider);
> + }
> +
> + dev_info(dev, "Registered BCM63xx USB PHY driver\n");
debug level?
--
~Vinod
Re: [PATCH RFC] kprobes: Remove MODULES dependency
On Fri, Jul 10, 2020 at 01:32:38PM +0200, Peter Zijlstra wrote:
> On Fri, Jul 10, 2020 at 07:32:57PM +0900, Masami Hiramatsu wrote:
> > > - page = module_alloc(PAGE_SIZE);
> > > + page = vmalloc(PAGE_SIZE);
> >
> > No, you can not use vmalloc here. The reason why we use module_alloc()
> > is to allocate the executable memory for trampoline code.
> > So, you need to use vmalloc_exec() instead.
>
> vmalloc_exec() would be broken too, also hch recently got rid of that
> thing.
>
> module_alloc() really is the only sane choice here.
>
> We should make module_alloc() unconditionally available, and maybe even
> rename it to text_alloc().
Thanks for the remarks.
The current module_alloc looks like this:
void * __weak module_alloc(unsigned long size)
{
return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
NUMA_NO_NODE, __builtin_return_address(0));
}
What if I create inline functions for text_alloc() and text_memfree() and
convert this function as:
void * __weak module_alloc(unsigned long size)
{
return text_alloc(size);
}
/Jarkko
[PATCH v6 0/2] leds: pwm: add support for default-state device
v5 -> v6: tested the rebase to v5.8-rc2 based for-next .../devicetree/bindings/leds/leds-pwm.txt | 2 + drivers/leds/leds-pwm.c| 54 +++--- 2 files changed, 50 insertions(+), 6 deletions(-) Message-Id: <20200421130644.16059-1-denis.osterl...@diehl.com> base-commit: cf1a1a6a7d81d73bcb5568b23572d6fd593add87 Diehl Connectivity Solutions GmbH Geschäftsführung: Horst Leonberger Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht Nürnberg: HRB 32315 ___ Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten haben. Bitte loeschen Sie in diesem Fall die Nachricht. Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung und/oder Publikation dieser E-Mail ist strengstens untersagt. - Informationen zum Datenschutz, insbesondere zu Ihren Rechten, erhalten Sie unter https://www.diehl.com/group/de/transparenz-und-informationspflichten/ The contents of the above mentioned e-mail is not legally binding. This e-mail contains confidential and/or legally protected information. Please inform us if you have received this e-mail by mistake and delete it in such a case. Each unauthorized reproduction, disclosure, alteration, distribution and/or publication of this e-mail is strictly prohibited. - For general information on data protection and your respective rights please visit https://www.diehl.com/group/en/transparency-and-information-obligations/
[PATCH v3] ALSA: line6: add hw monitor volume control for POD HD500
Add hw monitor volume control for POD HD500. The same change may
work for HD500X but I don't have it to test.
Signed-off-by: Vasily Khoruzhick
---
v3: - use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL
- use GFP_KERNEL instead of GFP_ATOMIC for allocating a message
- use lower case for float lookup table
v2: clamp volume value to [0, ARRAY_SIZE() -1] in
podhd_set_monitor_level()
sound/usb/line6/driver.c | 3 +-
sound/usb/line6/driver.h | 4 ++
sound/usb/line6/podhd.c | 124 ++-
3 files changed, 129 insertions(+), 2 deletions(-)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 7629116f570e..3e07251b80e3 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -97,7 +97,7 @@ static void line6_stop_listen(struct usb_line6 *line6)
/*
Send raw message in pieces of wMaxPacketSize bytes.
*/
-static int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
+int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
int size)
{
int i, done = 0;
@@ -132,6 +132,7 @@ static int line6_send_raw_message(struct usb_line6 *line6,
const char *buffer,
return done;
}
+EXPORT_SYMBOL_GPL(line6_send_raw_message);
/*
Notification of completion of asynchronous request transmission.
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index 1a4e3700c80c..62c686bed0ca 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -108,6 +108,8 @@ enum {
LINE6_CAP_CONTROL_MIDI = 1 << 4,
/* device provides low-level information */
LINE6_CAP_CONTROL_INFO = 1 << 5,
+ /* device provides hardware monitoring volume control */
+ LINE6_CAP_HWMON_CTL = 1 << 6,
};
/*
@@ -185,6 +187,8 @@ extern int line6_read_data(struct usb_line6 *line6,
unsigned address,
void *data, unsigned datalen);
extern int line6_read_serial_number(struct usb_line6 *line6,
u32 *serial_number);
+extern int line6_send_raw_message(struct usb_line6 *line6,
+ const char *buffer, int size);
extern int line6_send_raw_message_async(struct usb_line6 *line6,
const char *buffer, int size);
extern int line6_send_sysex_message(struct usb_line6 *line6,
diff --git a/sound/usb/line6/podhd.c b/sound/usb/line6/podhd.c
index e39dc85c355a..0410d256aa50 100644
--- a/sound/usb/line6/podhd.c
+++ b/sound/usb/line6/podhd.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include "driver.h"
@@ -37,6 +38,9 @@ struct usb_line6_podhd {
/* Firmware version */
int firmware_version;
+
+ /* Monitor level */
+ int monitor_level;
};
#define line6_to_podhd(x) container_of(x, struct usb_line6_podhd, line6)
@@ -250,6 +254,115 @@ static void podhd_disconnect(struct usb_line6 *line6)
}
}
+static const unsigned int float_zero_to_one_lookup[] = {
+0x, 0x3c23d70a, 0x3ca3d70a, 0x3cf5c28f, 0x3d23d70a, 0x3d4d,
+0x3d75c28f, 0x3d8f5c29, 0x3da3d70a, 0x3db851ec, 0x3dcd, 0x3de147ae,
+0x3df5c28f, 0x3e051eb8, 0x3e0f5c29, 0x3e1a, 0x3e23d70a, 0x3e2e147b,
+0x3e3851ec, 0x3e428f5c, 0x3e4d, 0x3e570a3d, 0x3e6147ae, 0x3e6b851f,
+0x3e75c28f, 0x3e80, 0x3e851eb8, 0x3e8a3d71, 0x3e8f5c29, 0x3e947ae1,
+0x3e9a, 0x3e9eb852, 0x3ea3d70a, 0x3ea8f5c3, 0x3eae147b, 0x3eb3,
+0x3eb851ec, 0x3ebd70a4, 0x3ec28f5c, 0x3ec7ae14, 0x3ecd, 0x3ed1eb85,
+0x3ed70a3d, 0x3edc28f6, 0x3ee147ae, 0x3ee6, 0x3eeb851f, 0x3ef0a3d7,
+0x3ef5c28f, 0x3efae148, 0x3f00, 0x3f028f5c, 0x3f051eb8, 0x3f07ae14,
+0x3f0a3d71, 0x3f0d, 0x3f0f5c29, 0x3f11eb85, 0x3f147ae1, 0x3f170a3d,
+0x3f1a, 0x3f1c28f6, 0x3f1eb852, 0x3f2147ae, 0x3f23d70a, 0x3f26,
+0x3f28f5c3, 0x3f2b851f, 0x3f2e147b, 0x3f30a3d7, 0x3f33, 0x3f35c28f,
+0x3f3851ec, 0x3f3ae148, 0x3f3d70a4, 0x3f40, 0x3f428f5c, 0x3f451eb8,
+0x3f47ae14, 0x3f4a3d71, 0x3f4d, 0x3f4f5c29, 0x3f51eb85, 0x3f547ae1,
+0x3f570a3d, 0x3f5a, 0x3f5c28f6, 0x3f5eb852, 0x3f6147ae, 0x3f63d70a,
+0x3f66, 0x3f68f5c3, 0x3f6b851f, 0x3f6e147b, 0x3f70a3d7, 0x3f73,
+0x3f75c28f, 0x3f7851ec, 0x3f7ae148, 0x3f7d70a4, 0x3f80
+};
+
+static void podhd_set_monitor_level(struct usb_line6_podhd *podhd, int value)
+{
+ unsigned int fl;
+ static const unsigned char msg[16] = {
+ /* Chunk is 0xc bytes (without first word) */
+ 0x0c, 0x00,
+ /* First chunk in the message */
+ 0x01, 0x00,
+ /* Message size is 2 4-byte words */
+ 0x02, 0x00,
+ /* Unknown */
+ 0x04, 0x41,
+ /* Unknown */
+ 0x04, 0x00, 0x13, 0x00,
+ /* Volume, LE float32, 0.0 - 1.0 */
+ 0x00, 0x00, 0x00, 0x00
+ };
+ unsigned char *buf;
+
+ buf =
Re: Beginning 5.8rc1 kernel USB headsets (ASUS ROG Delta and HyperX Cloud Orbit S) play sound as if in slow-motion.
On Fri, 10 Jul 2020 at 17:15, Alexander Tsoy wrote: > > You've probably hit this bug: > https://bugzilla.kernel.org/show_bug.cgi?id=208353 > The issue already not reproduced at least on commit git 0bddd227f3dc -- Best Regards, Mike Gavrilov.
[PATCH v6 2/2] leds: pwm: add reference to common leds for default-state
The default-state is now supported for PWM leds. Signed-off-by: Denis Osterland-Heim Acked-by: Jacek Anaszewski Acked-by: Pavel Machek Acked-by: Rob Herring --- Documentation/devicetree/bindings/leds/leds-pwm.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt b/Documentation/devicetree/bindings/leds/leds-pwm.txt index 6c6583c35f2f..d0f489680594 100644 --- a/Documentation/devicetree/bindings/leds/leds-pwm.txt +++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt @@ -19,6 +19,8 @@ LED sub-node properties: see Documentation/devicetree/bindings/leds/common.txt - linux,default-trigger : (optional) see Documentation/devicetree/bindings/leds/common.txt +- default-state : (optional) + see Documentation/devicetree/bindings/leds/common.yaml Example: -- 2.27.0 Diehl Connectivity Solutions GmbH Geschäftsführung: Horst Leonberger Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht Nürnberg: HRB 32315 ___ Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten haben. Bitte loeschen Sie in diesem Fall die Nachricht. Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung und/oder Publikation dieser E-Mail ist strengstens untersagt. - Informationen zum Datenschutz, insbesondere zu Ihren Rechten, erhalten Sie unter https://www.diehl.com/group/de/transparenz-und-informationspflichten/ The contents of the above mentioned e-mail is not legally binding. This e-mail contains confidential and/or legally protected information. Please inform us if you have received this e-mail by mistake and delete it in such a case. Each unauthorized reproduction, disclosure, alteration, distribution and/or publication of this e-mail is strictly prohibited. - For general information on data protection and your respective rights please visit https://www.diehl.com/group/en/transparency-and-information-obligations/
[PATCH v6 1/2] leds: pwm: add support for default-state device property
This patch adds support for "default-state" devicetree property, which
allows to defer pwm init to first use of led.
This allows to configure the PWM early in bootloader to let the LED
blink until an application in Linux userspace sets something different.
Signed-off-by: Denis Osterland-Heim
Acked-by: Jacek Anaszewski
---
drivers/leds/leds-pwm.c | 54 -
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index ef7b91bd2064..7b199c151768 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -18,10 +18,15 @@
#include
#include
+#define LEDS_PWM_DEFSTATE_OFF 0
+#define LEDS_PWM_DEFSTATE_ON 1
+#define LEDS_PWM_DEFSTATE_KEEP 2
+
struct led_pwm {
const char *name;
const char *default_trigger;
u8 active_low;
+ u8 default_state;
unsigned intmax_brightness;
};
@@ -88,7 +93,30 @@ static int led_pwm_add(struct device *dev, struct
led_pwm_priv *priv,
led_data->cdev.brightness_set_blocking = led_pwm_set;
- pwm_init_state(led_data->pwm, _data->pwmstate);
+ /* init PWM state */
+ if (led->default_state == LEDS_PWM_DEFSTATE_KEEP) {
+ pwm_get_state(led_data->pwm, _data->pwmstate);
+ if (!led_data->pwmstate.period) {
+ led->default_state = LEDS_PWM_DEFSTATE_OFF;
+ dev_warn(dev,
+ "failed to read period for %s, default to off",
+ led->name);
+ }
+ }
+ if (led->default_state != LEDS_PWM_DEFSTATE_KEEP)
+ pwm_init_state(led_data->pwm, _data->pwmstate);
+
+ /* set brightness */
+ if (led->default_state == LEDS_PWM_DEFSTATE_ON)
+ led_data->cdev.brightness = led->max_brightness;
+ else if (led->default_state == LEDS_PWM_DEFSTATE_KEEP) {
+ uint64_t brightness;
+
+ brightness = led->max_brightness;
+ brightness *= led_data->pwmstate.duty_cycle;
+ do_div(brightness, led_data->pwmstate.period);
+ led_data->cdev.brightness = brightness;
+ }
ret = devm_led_classdev_register(dev, _data->cdev);
if (ret) {
@@ -97,11 +125,13 @@ static int led_pwm_add(struct device *dev, struct
led_pwm_priv *priv,
return ret;
}
- ret = led_pwm_set(_data->cdev, led_data->cdev.brightness);
- if (ret) {
- dev_err(dev, "failed to set led PWM value for %s: %d",
- led->name, ret);
- return ret;
+ if (led->default_state != LEDS_PWM_DEFSTATE_KEEP) {
+ ret = led_pwm_set(_data->cdev, led_data->cdev.brightness);
+ if (ret) {
+ dev_err(dev, "failed to set led PWM value for %s: %d",
+ led->name, ret);
+ return ret;
+ }
}
priv->num_leds++;
@@ -117,6 +147,8 @@ static int led_pwm_create_fwnode(struct device *dev, struct
led_pwm_priv *priv)
memset(, 0, sizeof(led));
device_for_each_child_node(dev, fwnode) {
+ const char *state = NULL;
+
ret = fwnode_property_read_string(fwnode, "label", );
if (ret && is_of_node(fwnode))
led.name = to_of_node(fwnode)->name;
@@ -134,6 +166,16 @@ static int led_pwm_create_fwnode(struct device *dev,
struct led_pwm_priv *priv)
fwnode_property_read_u32(fwnode, "max-brightness",
_brightness);
+ if (!fwnode_property_read_string(fwnode, "default-state",
+)) {
+ if (!strcmp(state, "keep"))
+ led.default_state = LEDS_PWM_DEFSTATE_KEEP;
+ else if (!strcmp(state, "on"))
+ led.default_state = LEDS_PWM_DEFSTATE_ON;
+ else
+ led.default_state = LEDS_PWM_DEFSTATE_OFF;
+ }
+
ret = led_pwm_add(dev, priv, , fwnode);
if (ret) {
fwnode_handle_put(fwnode);
--
2.27.0
Diehl Connectivity Solutions GmbH
Geschäftsführung: Horst Leonberger
Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht
Nürnberg: HRB 32315
___
Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail
enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten
haben. Bitte loeschen Sie in diesem Fall die Nachricht.
Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung
und/oder
Re: [PATCH] staging: qlge: Remove pci-dma-compat wrapper APIs.
On Mon, Jul 13, 2020 at 01:59:59PM +0900, Benjamin Poirier wrote: > On 2020-07-11 18:16 +0530, Suraj Upadhyay wrote: > > The legacy API wrappers in include/linux/pci-dma-compat.h > > should go away as it creates unnecessary midlayering > > for include/linux/dma-mapping.h APIs, instead use dma-mapping.h > > APIs directly. > > > > The patch has been generated with the coccinelle script below > > and compile-tested. > > > [...] > > > > @@ expression E1, E2, E3, E4; @@ > > - pci_dma_sync_single_for_device(E1, E2, E3, E4) > > + dma_sync_single_for_device(>dev, E2, E3, (enum dma_data_direction)E4) > > The qlge driver contains more usages of the deprecated pci_dma_* api > than what this diff addresses. In particular, there are some calls to > pci_dma_sync_single_for_cpu() which were not changed despite this > expression being in the semantic patch. Hii Ben, I couldn't find any instances of pci_dma_sync_single_for_cpu in the drivers/staging/qlge/ driver, I ran a simple `git grep pci_dma_sync_single_for_cpu/device` and got nothing. If I am wrong, please send the line number of the usages. > Dunno what happened but it should be reviewed. After converting away > from all of the old api, the TODO file should also be updated. Thanks for reminding me this, I would send a follow up patch to remove "pci_dma_*" from "avoid legacy/deprecated apis (ex. replace pci_dma_*, replace pci_enable_msi, use pci_iomap)". Thanks and Cheers, Suraj Upadhyay. > [...] > > > > > diff --git a/drivers/staging/qlge/qlge_mpi.c > > b/drivers/staging/qlge/qlge_mpi.c > > index fa178fc642a6..16a9bf818346 100644 > > --- a/drivers/staging/qlge/qlge_mpi.c > > +++ b/drivers/staging/qlge/qlge_mpi.c > > @@ -788,8 +788,9 @@ int ql_dump_risc_ram_area(struct ql_adapter *qdev, void > > *buf, > > char *my_buf; > > dma_addr_t buf_dma; > > > > - my_buf = pci_alloc_consistent(qdev->pdev, word_count * sizeof(u32), > > - _dma); > > + my_buf = dma_alloc_coherent(>pdev->dev, > > + word_count * sizeof(u32), _dma, > > + GFP_ATOMIC); > > if (!my_buf) > > return -EIO; > > > > @@ -797,8 +798,8 @@ int ql_dump_risc_ram_area(struct ql_adapter *qdev, void > > *buf, > > if (!status) > > memcpy(buf, my_buf, word_count * sizeof(u32)); > > > > - pci_free_consistent(qdev->pdev, word_count * sizeof(u32), my_buf, > > - buf_dma); > > + dma_free_coherent(>pdev->dev, word_count * sizeof(u32), my_buf, > > + buf_dma); > > return status; > > } > > > > -- > > 2.17.1 > > > > signature.asc Description: PGP signature
Re: [PATCH 01/21] dt-binding: memory: mediatek: Add a common larb-port header file
On Mon, Jul 13, 2020 at 2:06 AM Matthias Brugger wrote: > > > > On 11/07/2020 08:48, Yong Wu wrote: > > Put all the macros about smi larb/port togethers, this is a preparing > > patch for extending LARB_NR and adding new dom-id support. > > > > Signed-off-by: Yong Wu > > --- > > include/dt-bindings/memory/mt2712-larb-port.h | 2 +- > > include/dt-bindings/memory/mt6779-larb-port.h | 2 +- > > include/dt-bindings/memory/mt8173-larb-port.h | 2 +- > > include/dt-bindings/memory/mt8183-larb-port.h | 2 +- > > include/dt-bindings/memory/mtk-smi-larb-port.h | 15 +++ > > 5 files changed, 19 insertions(+), 4 deletions(-) > > create mode 100644 include/dt-bindings/memory/mtk-smi-larb-port.h > > > > ... > > diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h > > b/include/dt-bindings/memory/mtk-smi-larb-port.h > > new file mode 100644 > > index ..2ec7fe5ce4e9 > > --- /dev/null > > +++ b/include/dt-bindings/memory/mtk-smi-larb-port.h > > @@ -0,0 +1,15 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > +/* > > + * Copyright (c) 2020 MediaTek Inc. > > + * Author: Yong Wu > > + */ > > +#ifndef __DTS_MTK_IOMMU_PORT_H_ > > +#define __DTS_MTK_IOMMU_PORT_H_ > > + > > +#define MTK_LARB_NR_MAX 16 > > include/soc/mediatek/smi.h has the very same define. > Should smi.h include this file? > > Regards, > Matthias > Looks like this is being addressed in patch 5 in this series ([05/21] iommu/mediatek: Use the common mtk-smi-larb-port.h) That said, should that patch be merged into this one? > > + > > +#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) > > +#define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0xf) > > +#define MTK_M4U_TO_PORT(id) ((id) & 0x1f) > > + > > +#endif > >
Re: [PATCH RFC] kprobes: Remove MODULES dependency
On Fri, Jul 10, 2020 at 07:32:57PM +0900, Masami Hiramatsu wrote:
> Hi Jarkko,
>
> On Fri, 10 Jul 2020 02:45:19 +0300
> Jarkko Sakkinen wrote:
>
> > Remove MODULES dependency and migrate from module_alloc to vmalloc().
> > According to Andi, the history with this dependency is that kprobes
> > originally required custom LKM's, which does not hold today anymore.
> >
> > Right now one has to compile LKM support only to enable kprobes. With
> > this change applied, it is somewhat easier to create custom test
> > kernel's with a proper debugging capabilities, thus making Linux more
> > developer friendly.
>
> Agreed. Now we have several way to access kprobes via ftrace/perf/bpf
> without modules. So it's a good time to remove CONFIG_MODULE dependency.
>
> But I also would like to minimize the changes for code readability.
> I made some comments below.
Thanks, appreciate this.
> > Cc: Andi Kleen
> > Signed-off-by: Jarkko Sakkinen
> > ---
> > arch/Kconfig | 1 -
> > arch/x86/kernel/kprobes/core.c | 5 +++--
> > kernel/kprobes.c | 22 --
> > kernel/trace/trace_kprobe.c| 12
> > 4 files changed, 35 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 8cc35dc556c7..bb59cdf335ab 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -61,7 +61,6 @@ config OPROFILE_NMI_TIMER
> >
> > config KPROBES
> > bool "Kprobes"
> > - depends on MODULES
> > depends on HAVE_KPROBES
> > select KALLSYMS
> > help
> > diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> > index ada39ddbc922..dc7b8d6fd20d 100644
> > --- a/arch/x86/kernel/kprobes/core.c
> > +++ b/arch/x86/kernel/kprobes/core.c
> > @@ -42,6 +42,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -423,7 +424,7 @@ void *alloc_insn_page(void)
> > {
> > void *page;
> >
> > - page = module_alloc(PAGE_SIZE);
> > + page = vmalloc(PAGE_SIZE);
>
> No, you can not use vmalloc here. The reason why we use module_alloc()
> is to allocate the executable memory for trampoline code.
> So, you need to use vmalloc_exec() instead.
Right, I'm on the wagon with this after reading Peter's explanation.
>
> > if (!page)
> > return NULL;
> >
> > @@ -446,7 +447,7 @@ void *alloc_insn_page(void)
> > /* Recover page to RW mode before releasing it */
> > void free_insn_page(void *page)
> > {
> > - module_memfree(page);
> > + vfree(page);
> > }
> >
> > static int arch_copy_kprobe(struct kprobe *p)
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index 4a904cc56d68..02680642ea11 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -35,6 +35,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -111,12 +112,12 @@ enum kprobe_slot_state {
> >
> > void __weak *alloc_insn_page(void)
> > {
> > - return module_alloc(PAGE_SIZE);
> > + return vmalloc(PAGE_SIZE);
>
> Ditto.
>
> > }
> >
> > void __weak free_insn_page(void *page)
> > {
> > - module_memfree(page);
> > + vfree(page);
> > }
> >
> > struct kprobe_insn_cache kprobe_insn_slots = {
> > @@ -563,8 +564,11 @@ static void kprobe_optimizer(struct work_struct *work)
> > mutex_lock(_mutex);
> > cpus_read_lock();
> > mutex_lock(_mutex);
> > +
> > +#ifdef CONFIG_MODULES
> > /* Lock modules while optimizing kprobes */
> > mutex_lock(_mutex);
> > +#endif
>
> Hmm, can you reduce these "#ifdef CONFIG_MODULE"s ?
>
> e.g.
>
> #ifdef CONFIG_MODULES
> static void lock_modules(void)
> {
> mutex_lock(_mutex);
> }
> ...
> #else
> #define lock_modules() do { } while (0)
> ...
> #endif
Yes, I'll use this idea also to address to issues reported below.
>
> >
> > /*
> > * Step 1: Unoptimize kprobes and collect cleaned (unused and disarmed)
> > @@ -589,7 +593,9 @@ static void kprobe_optimizer(struct work_struct *work)
> > /* Step 4: Free cleaned kprobes after quiesence period */
> > do_free_cleaned_kprobes();
> >
> > +#ifdef CONFIG_MODULES
> > mutex_unlock(_mutex);
> > +#endif
> > mutex_unlock(_mutex);
> > cpus_read_unlock();
> >
> > @@ -739,6 +745,7 @@ static int reuse_unused_kprobe(struct kprobe *ap)
> > return 0;
> > }
> >
>
> > +#ifdef CONFIG_MODULE
> > /* Remove optimized instructions */
> > static void kill_optimized_kprobe(struct kprobe *p)
> > {
> > @@ -764,6 +771,7 @@ static void kill_optimized_kprobe(struct kprobe *p)
> > /* Don't touch the code, because it is already freed. */
> > arch_remove_optimized_kprobe(op);
> > }
> > +#endif
>
> This optprobe related one is OK to keep in this place.
>
> >
> > static inline
> > void __prepare_optimized_kprobe(struct optimized_kprobe *op, struct kprobe
> > *p)
> > @@ -1608,6 +1616,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
> > goto
Re: [PATCH v6 2/2] phy: intel: Add Keem Bay eMMC PHY support
On 02-07-20, 08:09, Wan Ahmad Zainie wrote: > Add support for eMMC PHY on Intel Keem Bay SoC. > > Signed-off-by: Wan Ahmad Zainie > --- > drivers/phy/intel/Kconfig| 12 + > drivers/phy/intel/Makefile | 1 + > drivers/phy/intel/phy-keembay-emmc.c | 314 +++ > 3 files changed, 327 insertions(+) > create mode 100644 drivers/phy/intel/phy-keembay-emmc.c > > diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig > index 7b47682a4e0e..8ddda4fb95d2 100644 > --- a/drivers/phy/intel/Kconfig > +++ b/drivers/phy/intel/Kconfig > @@ -22,3 +22,15 @@ config PHY_INTEL_EMMC > select GENERIC_PHY > help > Enable this to support the Intel EMMC PHY > + > +config PHY_KEEMBAY_EMMC Pls keep this in alphabetical sort > + tristate "Intel Keem Bay EMMC PHY driver" > + depends on ARM64 || COMPILE_TEST Intel and ARM64, aha, fun times! > + depends on OF && HAS_IOMEM > + select GENERIC_PHY > + select REGMAP_MMIO > + help > + Choose this option if you have an Intel Keem Bay SoC. > + > + To compile this driver as a module, choose M here: the module > + will be called phy-keembay-emmc. phy-keembay-emmc.ko ? > diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile > index 233d530dadde..6566334e7b77 100644 > --- a/drivers/phy/intel/Makefile > +++ b/drivers/phy/intel/Makefile > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > obj-$(CONFIG_PHY_INTEL_COMBO)+= phy-intel-combo.o > obj-$(CONFIG_PHY_INTEL_EMMC)+= phy-intel-emmc.o > +obj-$(CONFIG_PHY_KEEMBAY_EMMC) += phy-keembay-emmc.o here as well > +/* eMMC/SD/SDIO core/phy configuration registers */ > +#define PHY_CFG_00x24 > +#define SEL_DLY_TXCLK_MASK BIT(29) > +#define SEL_DLY_TXCLK(x)(((x) << 29) & SEL_DLY_TXCLK_MASK) > +#define OTAP_DLY_ENA_MASK BIT(27) > +#define OTAP_DLY_ENA(x) (((x) << 27) & OTAP_DLY_ENA_MASK) > +#define OTAP_DLY_SEL_MASK GENMASK(26, 23) > +#define OTAP_DLY_SEL(x) (((x) << 23) & OTAP_DLY_SEL_MASK) why not a generic helper to do (x) << ffs(reg - 1) & reg ? You can skip defining for each register that way! -- ~Vinod
Re: [PATCH 04/21] dt-binding: mediatek: Add binding for mt8192 IOMMU and SMI
On Sat, Jul 11, 2020 at 2:50 PM Yong Wu wrote: > > This patch adds decriptions for mt8192 IOMMU and SMI. > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation > table format. The M4U-SMI HW diagram is as below: > > EMI >| > M4U >| > >SMI Common > >| > +---+--+--+--+---+ > | | | | .. | | > | | | | | | > larb0 larb1 larb2 larb4 .. larb19 larb20 > disp0 disp1 mdpvdec IPE IPE > > All the connections are HW fixed, SW can NOT adjust it. > > mt8192 M4U support 0~16GB iova range. we preassign different engines > into different iova ranges: > > domain-id module iova-range larbs >0 disp0 ~ 4G larb0/1 >1 vcodec 4G ~ 8G larb4/5/7 >2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20 >3 CCU00x4000_ ~ 0x43ff_ larb13: port 9/10 >4 CCU10x4400_ ~ 0x47ff_ larb14: port 4/5 > > The iova range for CCU0/1(camera control unit) is HW requirement. > > Signed-off-by: Yong Wu > --- > .../bindings/iommu/mediatek,iommu.txt | 8 +- > .../mediatek,smi-common.txt | 5 +- > .../memory-controllers/mediatek,smi-larb.txt | 3 +- > include/dt-bindings/memory/mt8192-larb-port.h | 237 ++ > 4 files changed, 247 insertions(+), 6 deletions(-) > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h > ... > diff --git a/include/dt-bindings/memory/mt8192-larb-port.h > b/include/dt-bindings/memory/mt8192-larb-port.h > new file mode 100644 > index ..fbe0d5d50f1c > --- /dev/null > +++ b/include/dt-bindings/memory/mt8192-larb-port.h > ... > +/* larb7 */ > +#define M4U_PORT_L7_VENC_RCPU MTK_M4U_DOM_ID(1, 7, 0) > +#define M4U_PORT_L7_VENC_REC MTK_M4U_DOM_ID(1, 7, 1) > +#define M4U_PORT_L7_VENC_BSDMA MTK_M4U_DOM_ID(1, 7, 2) > +#define M4U_PORT_L7_VENC_SV_COMV MTK_M4U_DOM_ID(1, 7, 3) > +#define M4U_PORT_L7_VENC_RD_COMV MTK_M4U_DOM_ID(1, 7, 4) > +#define M4U_PORT_L7_VENC_CUR_LUMA MTK_M4U_DOM_ID(1, 7, 5) > +#define M4U_PORT_L7_VENC_CUR_CHROMAMTK_M4U_DOM_ID(1, 7, 6) > +#define M4U_PORT_L7_VENC_REF_LUMA MTK_M4U_DOM_ID(1, 7, 7) > +#define M4U_PORT_L7_VENC_REF_CHROMAMTK_M4U_DOM_ID(1, 7, 8) > +#define M4U_PORT_L7_JPGENC_Y_RDMA MTK_M4U_DOM_ID(1, 7, 9) > +#define M4U_PORT_L7_JPGENC_Q_RDMA MTK_M4U_DOM_ID(1, 7, 10) > +#define M4U_PORT_L7_JPGENC_C_TABLE MTK_M4U_DOM_ID(1, 7, 11) > +#define M4U_PORT_L7_JPGENC_BSDMA MTK_M4U_DOM_ID(1, 7, 12) > +#define M4U_PORT_L7_VENC_SUB_R_LUMAMTK_M4U_DOM_ID(1, 7, 13) > +#define M4U_PORT_L7_VENC_SUB_W_LUMAMTK_M4U_DOM_ID(1, 7, 14) > + Small nit, /* larb8: null */ is missing here. > +/* larb9 */ > +#define M4U_PORT_L9_IMG_IMGI_D1MTK_M4U_DOM_ID(2, 9, > 0) > +#define M4U_PORT_L9_IMG_IMGBI_D1 MTK_M4U_DOM_ID(2, 9, 1) > +#define M4U_PORT_L9_IMG_DMGI_D1MTK_M4U_DOM_ID(2, 9, > 2) > +#define M4U_PORT_L9_IMG_DEPI_D1MTK_M4U_DOM_ID(2, 9, > 3) > +#define M4U_PORT_L9_IMG_ICE_D1 MTK_M4U_DOM_ID(2, 9, 4) > +#define M4U_PORT_L9_IMG_SMTI_D1MTK_M4U_DOM_ID(2, 9, > 5) > +#define M4U_PORT_L9_IMG_SMTO_D2MTK_M4U_DOM_ID(2, 9, > 6) > +#define M4U_PORT_L9_IMG_SMTO_D1MTK_M4U_DOM_ID(2, 9, > 7) > +#define M4U_PORT_L9_IMG_CRZO_D1MTK_M4U_DOM_ID(2, 9, > 8) > +#define M4U_PORT_L9_IMG_IMG3O_D1 MTK_M4U_DOM_ID(2, 9, 9) > +#define M4U_PORT_L9_IMG_VIPI_D1MTK_M4U_DOM_ID(2, 9, > 10) > +#define M4U_PORT_L9_IMG_SMTI_D5MTK_M4U_DOM_ID(2, 9, > 11) > +#define M4U_PORT_L9_IMG_TIMGO_D1 MTK_M4U_DOM_ID(2, 9, 12) > +#define M4U_PORT_L9_IMG_UFBC_W0MTK_M4U_DOM_ID(2, 9, > 13) > +#define M4U_PORT_L9_IMG_UFBC_R0MTK_M4U_DOM_ID(2, 9, > 14) > + > ...
Re: [RESEND PATCH v7 1/2] phy: qualcomm: add qcom ipq806x dwc usb phy driver
On 15-06-20, 22:53, Ansuel Smith wrote:
> @@ -0,0 +1,593 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright (c) 2014-2015, Code Aurora Forum. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
You have SPDX tag, so we dont need the license text, please remove this.
Also we are in 2020 now so Copyright looks incorrect
> +static int qcom_ipq806x_usb_ss_phy_init(struct phy *phy)
> +{
> + struct usb_phy *phy_dwc3 = phy_get_drvdata(phy);
> + int ret;
> + u32 data = 0;
Superfluous init
> +static int qcom_ipq806x_usb_phy_probe(struct platform_device *pdev)
> +{
> + struct usb_phy *phy_dwc3;
> + struct phy_provider *phy_provider;
> + struct phy *generic_phy;
> + const struct of_device_id *match;
> + const struct phy_drvdata *data;
> + struct resource *res;
> + resource_size_t size;
Pls pick one, tabs or single spaces, not both. and reverse christmas
looks better :)
> + struct device_node *np;
> +
> + phy_dwc3 = devm_kzalloc(>dev, sizeof(*phy_dwc3), GFP_KERNEL);
> + if (!phy_dwc3)
> + return -ENOMEM;
> +
> + match = of_match_node(qcom_ipq806x_usb_phy_table, pdev->dev.of_node);
> + data = match->data;
How about using of_device_get_match_data() instead?
--
~Vinod
[PATCH v6] powerpc/fadump: fix race between pstore write and fadump crash trigger
When we enter into fadump crash path via system reset we fail to update
the pstore.
On the system reset path we first update the pstore then we go for fadump
crash. But the problem here is when all the CPUs try to get the pstore
lock to initiate the pstore write, only one CPUs will acquire the lock
and proceed with the pstore write. Since it in NMI context CPUs that fail
to get lock do not wait for their turn to write to the pstore and simply
proceed with the next operation which is fadump crash. One of the CPU who
proceeded with fadump crash path triggers the crash and does not wait for
the CPU who gets the pstore lock to complete the pstore update.
Timeline diagram to depicts the sequence of events that leads to an
unsuccessful pstore update when we hit fadump crash path via system reset.
12 3... n CPU Threads
|| | |
|| | |
Reached to -->|--->|>| --->|
system reset|| | |
path|| | |
|| | |
Try to -->|--->|>|>|
acquire the || | |
pstore lock || | |
|| | |
|| | |
Got the -->| +->| | |<-+
pstore lock | | | | | |--> Didn't get the
| --+ lock and moving
|| | |ahead on fadump
|| | |crash path
|| | |
Begins the -->|| | |
process to || | |<-- Got the chance to
update the || | |trigger the crash
pstore | -> | |... <- |
| | | | | |
| | | | | |<-- Triggers the
| | | | | |crash
| | | | | | ^
| | | | | | |
Writing to -->| | | | | | |
pstore | | | | | | |
| | |
^ |__| |
| CPU Relax |
| |
+-+
|
v
Race: crash triggered before pstore
update completes
To avoid this race condition a barrier is added on crash_fadump path, it
prevents the CPU to trigger the crash until all the online CPUs completes
their task.
A barrier is added to make sure all the secondary CPUs hit the
crash_fadump function before we initiates the crash. A timeout is kept to
ensure the primary CPU (one who initiates the crash) do not wait for
secondary CPUs indefinitely.
Signed-off-by: Sourabh Jain
---
arch/powerpc/kernel/fadump.c | 24
1 file changed, 24 insertions(+)
---
Chanagelog:
v1 -> v3:
- https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/208267.html
v3 -> v4:
- Now the primary CPU (one who triggers dump) waits for all secondary
CPUs to enter and then initiates the crash.
v4 -> v5:
- Fixed a build failure reported by kernel test robot
Now the cpus_in_crash variable is defined outside CONFIG_CMA
config option.
v5 -> v6
- Changed a variable name cpus_in_crash -> cpus_in_fadump.
---
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 78ab9a6ee6ac..1858896d6809 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -32,11 +32,20 @@
#include
#include
+/*
+ * The CPU who acquired the lock to trigger the fadump crash should
+ * wait for other CPUs to enter.
+ *
+ * The timeout is in milliseconds.
+ */
+#define CRASH_TIMEOUT 500
+
static struct fw_dump fw_dump;
static void __init fadump_reserve_crash_area(u64 base);
struct kobject *fadump_kobj;
+static atomic_t cpus_in_fadump;
#ifndef CONFIG_PRESERVE_FA_DUMP
static DEFINE_MUTEX(fadump_mutex);
@@ -668,8 +677,11 @@ early_param("fadump_reserve_mem",
early_fadump_reserve_mem);
void crash_fadump(struct pt_regs *regs, const char *str)
{
+ unsigned int msecs;
struct fadump_crash_info_header *fdh = NULL;
int old_cpu, this_cpu;
+ /* Do not include first CPU */
+ unsigned int ncpus = num_online_cpus() - 1;
if (!should_fadump_crash())
return;
@@ -685,6 +697,8 @@ void crash_fadump(struct pt_regs *regs, const char *str)
old_cpu = cmpxchg(_cpu, -1, this_cpu);
if (old_cpu != -1) {
+ atomic_inc(_in_fadump);
+
/*
* We can't loop here indefinitely. Wait
linux-next: manual merge of the tty tree with the drm-misc tree
Hi all,
Today's linux-next merge of the tty tree got a conflict in:
drivers/video/fbdev/core/fbcon.c
between commit:
fcf918b96662 ("fbcon: Use array3_size() helper in scr_memcpyw()")
from the drm-misc tree and commit:
28bc24fc46f9 ("vc: separate state")
from the tty 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 drivers/video/fbdev/core/fbcon.c
index af9f5ab96f74,86fe41b1deb8..
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@@ -676,8 -676,8 +676,8 @@@ static void fbcon_prepare_logo(struct v
q = (unsigned short *) (vc->vc_origin +
vc->vc_size_row *
rows);
- scr_memcpyw(q, save, logo_lines * new_cols * 2);
+ scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));
- vc->vc_y += logo_lines;
+ vc->state.y += logo_lines;
vc->vc_pos += logo_lines * vc->vc_size_row;
kfree(save);
}
pgpSTLwEhHDJH.pgp
Description: OpenPGP digital signature
Re: [PATCH 3/3] MAINTAINERS: Add Bruno Thomsen as reviewer of Kamstrup DTS
On Mon, 2020-07-13 at 10:56 +0800, Shawn Guo wrote:
> On Mon, Jun 29, 2020 at 01:49:27PM +0200, Bruno Thomsen wrote:
> > Add myself as reviewer of device trees for Kamstrup
> > Concentrators.
> >
> > Signed-off-by: Bruno Thomsen
> > ---
> > MAINTAINERS | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 496fd4eafb68..97fc112309af 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9282,6 +9282,11 @@ S: Maintained
> > F: Documentation/hwmon/k8temp.rst
> > F: drivers/hwmon/k8temp.c
> >
> > +KAMSTRUP CONCENTRATORS
> > +R: Bruno Thomsen
> > +S: Maintained
> > +F: arch/arm/boot/dts/imx7d-flex-concentrator*.dts
> > +
>
> I guess get_maintainer.pl should list you for patches touching the
> files, so it's not really required? I'm worried about that MAINTAINERS
> file will get bloated quickly if we patch it for every single DTS
> file.
Right now, a little less than half of the .dts* files
have an author or other email address in them.
$ git ls-files arch/arm/boot/dts/*.dts* | wc -l
2105
$ git grep -P --name-only '<\S+@\S+>' arch/arm/boot/dts/*.dts* | wc -l
997
Some have multiple email addresses:
$ git grep -P '<\S+@\S+>' arch/arm/boot/dts/*.dts* | wc -l
1240
(and there are a few false positives in that regex)
I suppose that get_maintainer could handle .dts* files
the same way .yaml files are handled so any email address
in the file is added to patches that touch the file.
This is the commit that added the .yaml file handling:
commit 0c78c013762142bfe8fce34e7e968f83f0a4b891
Author: Joe Perches
Date: Thu Jun 4 16:50:01 2020 -0700
get_maintainer: add email addresses from .yaml files
.yaml files can contain maintainer/author addresses and it seems unlikely
or unnecessary that individual MAINTAINER file section entries for each
.yaml file will be created.
So add the email addresses found in .yaml files to the default
get_maintainer output.
The email addresses are marked with "(in file)" when using the "--roles"
or "--rolestats" options.
So something like:
---
scripts/get_maintainer.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 484d2fbf5921..4c3c69d7bed0 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -436,7 +436,7 @@ sub maintainers_in_file {
return if ($file =~ m@\bMAINTAINERS$@);
-if (-f $file && ($email_file_emails || $file =~ /\.yaml$/)) {
+if (-f $file && ($email_file_emails || $file =~ /\.(?:yaml|dtsi?)$/)) {
open(my $f, '<', $file)
or die "$P: Can't open $file: $!\n";
my $text = do { local($/) ; <$f> };
Re: [PATCH v6 1/2] hwmon: shtc1: add support for device tree bindings
On 12/7/2020 12:44 pm, Chris Ruehl wrote:
Add support for DTS bindings for the sensirion shtc1,shtw1 and shtc3.
Signed-off-by: Chris Ruehl
Reviewed-by: Guenter Roeck
Received new PCBA from the factory today, with the chip installed.
Probe working, the measurement of temperature and humidity is correct.
root@pcba0:~# cat
/sys/devices/platform/ff11.i2c/i2c-1/1-0070/hwmon/hwmon1/temp1_input
42334
root@pcba0:~# cat
/sys/devices/platform/ff11.i2c/i2c-1/1-0070/hwmon/hwmon1/humidity1_input
38128
Tested-by: Chris Ruehl
---
drivers/hwmon/shtc1.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/shtc1.c b/drivers/hwmon/shtc1.c
index a0078ccede03..7993a5ff8768 100644
--- a/drivers/hwmon/shtc1.c
+++ b/drivers/hwmon/shtc1.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/* commands (high precision mode) */
static const unsigned char shtc1_cmd_measure_blocking_hpm[]= { 0x7C, 0xA2
};
@@ -196,6 +197,7 @@ static int shtc1_probe(struct i2c_client *client,
enum shtcx_chips chip = id->driver_data;
struct i2c_adapter *adap = client->adapter;
struct device *dev = >dev;
+ struct device_node *np = dev->of_node;
if (!i2c_check_functionality(adap, I2C_FUNC_I2C)) {
dev_err(dev, "plain i2c transactions not supported\n");
@@ -233,8 +235,14 @@ static int shtc1_probe(struct i2c_client *client,
data->client = client;
data->chip = chip;
- if (client->dev.platform_data)
- data->setup = *(struct shtc1_platform_data *)dev->platform_data;
+ if (np) {
+ data->setup.blocking_io = of_property_read_bool(np,
"sensirion,blocking-io");
+ data->setup.high_precision = !of_property_read_bool(np,
"sensicon,low-precision");
+ } else {
+ if (client->dev.platform_data)
+ data->setup = *(struct shtc1_platform_data
*)dev->platform_data;
+ }
+
shtc1_select_command(data);
mutex_init(>update_lock);
@@ -257,8 +265,19 @@ static const struct i2c_device_id shtc1_id[] = {
};
MODULE_DEVICE_TABLE(i2c, shtc1_id);
+static const struct of_device_id shtc1_of_match[] = {
+ { .compatible = "sensirion,shtc1" },
+ { .compatible = "sensirion,shtw1" },
+ { .compatible = "sensirion,shtc3" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, shtc1_of_match);
+
static struct i2c_driver shtc1_i2c_driver = {
- .driver.name = "shtc1",
+ .driver = {
+ .name = "shtc1",
+ .of_match_table = shtc1_of_match,
+ },
.probe= shtc1_probe,
.id_table = shtc1_id,
};
--
GTSYS Limited RFID Technology
9/F, Unit E, R07, Kwai Shing Industrial Building Phase 2,
42-46 Tai Lin Pai Road, Kwai Chung, N.T., Hong Kong
Tel (852) 9079 9521
Disclaimer: https://www.gtsys.com.hk/email/classified.html
Re: [PATCH v2 0/3] Power10 basic energy management
Excerpts from Pratik Rajesh Sampat's message of July 10, 2020 3:22 pm: > Changelog v1 --> v2: > 1. Save-restore DAWR and DAWRX unconditionally as they are lost in > shallow idle states too > 2. Rename pnv_first_spr_loss_level to pnv_first_fullstate_loss_level to > correct naming terminology > > Pratik Rajesh Sampat (3): > powerpc/powernv/idle: Exclude mfspr on HID1,4,5 on P9 and above > powerpc/powernv/idle: save-restore DAWR0,DAWRX0 for P10 > powerpc/powernv/idle: Rename pnv_first_spr_loss_level variable > > arch/powerpc/platforms/powernv/idle.c | 34 +-- > 1 file changed, 22 insertions(+), 12 deletions(-) These look okay to me, but the CPU_FTR_ARCH_300 test for pnv_power9_idle_init() is actually wrong, it should be a PVR test because idle is not completely architected (not even shallow stop states, unfortunately). It doesn't look like we support POWER10 idle correctly yet, and on older kernels it wouldn't work even if we fixed newer, so ideally the PVR check would be backported as a fix in the front of the series. Sadly, we have no OPAL idle driver yet. Hopefully we will before the next processor shows up :P Thanks, Nick
Re: [PATCH] phy: renesas: rcar-gen3-usb2: fix SError happen if DEBUG_SHIRQ is enabled
Hi Yoshihiro,
On 09-07-20, 19:36, Yoshihiro Shimoda wrote:
> If CONFIG_DEBUG_SHIRQ was enabled, r8a77951-salvator-xs could boot
> correctly. If we appended "earlycon keep_bootcon" to the kernel
> command like, we could get kernel log like below.
>
> SError Interrupt on CPU0, code 0xbf02 -- SError
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 5.8.0-rc3-salvator-x-00505-g6c843129e6faaf01 #785
> Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)
> pstate: 60400085 (nZCv daIf +PAN -UAO BTYPE=--)
> pc : rcar_gen3_phy_usb2_irq+0x14/0x54
> lr : free_irq+0xf4/0x27c
>
> This means free_irq() calls the interrupt handler while PM runtime
> is not getting if DEBUG_SHIRQ is enabled and rcar_gen3_phy_usb2_probe()
> failed. To fix the issue, add a condition into the interrupt
> handler to avoid register access if any phys are not initialized.
>
> Note that rcar_gen3_is_any_rphy_initialized() was introduced on v5.2.
> So, if we backports this patch to v5.1 or less, we need to make
> other way.
Should we really check phy is initialized? I think the issue here is
that you register irq first, so your handler can be invoked. Right fix
for this would be to move the irq registration to later in the probe
when we are ready to handle interrupts
>
> Reported-by: Wolfram Sang
> Reported-by: Geert Uytterhoeven
> Fixes: 9f391c574efc ("phy: rcar-gen3-usb2: add runtime ID/VBUS pin detection")
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/phy/renesas/phy-rcar-gen3-usb2.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> index bfb22f8..91c732d 100644
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -507,9 +507,13 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void
> *_ch)
> {
> struct rcar_gen3_chan *ch = _ch;
> void __iomem *usb2_base = ch->base;
> - u32 status = readl(usb2_base + USB2_OBINTSTA);
> + u32 status;
> irqreturn_t ret = IRQ_NONE;
>
> + if (!rcar_gen3_is_any_rphy_initialized(ch))
> + return ret;
> +
> + status = readl(usb2_base + USB2_OBINTSTA);
> if (status & USB2_OBINT_BITS) {
> dev_vdbg(ch->dev, "%s: %08x\n", __func__, status);
> writel(USB2_OBINT_BITS, usb2_base + USB2_OBINTSTA);
> --
> 2.7.4
--
~Vinod
Re: [PATCH 3/3] arm64: allwinner: a64: enable Bluetooth On Pinebook
On Mon, Jul 6, 2020 at 4:47 AM Maxime Ripard wrote:
>
> Hi,
>
> On Sun, Jul 05, 2020 at 12:51:10PM -0700, Vasily Khoruzhick wrote:
> > Pinebook has an RTL8723CS WiFi + BT chip, BT is connected to UART1
> > and uses PL5 as device wake GPIO, PL6 as host wake GPIO the I2C
> > controlling signals are connected to R_I2C bus.
> >
> > Enable it in the device tree.
> >
> > Signed-off-by: Vasily Khoruzhick
> > ---
> > .../arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > index 64b1c54f87c0..e63ff271be4e 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > @@ -408,6 +408,18 @@ {
> > status = "okay";
> > };
> >
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins>, <_rts_cts_pins>;
> > + status = "okay";
>
> You probably need uart-has-rtscts here
Will add in v2
> > +
> > + bluetooth {
> > + compatible = "realtek,rtl8723cs-bt";
> > + device-wake-gpios = <_pio 0 5 GPIO_ACTIVE_LOW>; /* PL5 */
> > + host-wake-gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
> > + };
>
> And max-speed I guess?
There's no max-speed in the schema for this bluetooth controller.
Moreover it reads uart settings from firmware config. See
btrtl_get_uart_settings() in drivers/bluetooth/btrtl.c
> Maxime
> >
Re: [PATCH RESEND] phy: exynos5-usbdrd: Calibrating makes sense only for USB2.0 PHY
On 08-07-20, 15:38, Marek Szyprowski wrote: > PHY calibration is needed only for USB2.0 (UTMI) PHY, so skip calling > calibration code when phy_calibrate() is called for USB3.0 (PIPE3) PHY. Applied, thanks -- ~Vinod
Re: [PATCH] dt-bindings: phy: uniphier: Fix incorrect clocks and clock-names for PXs3 usb3-hsphy
On 08-07-20, 17:57, Kunihiko Hayashi wrote:
> The usb3-hsphy for PXs3 SoC needs to accept 3 clocks like usb3-ssphy.
Applied, thanks
>
> Fixes: 134ab2845acb ("dt-bindings: phy: Convert UniPhier USB3-PHY conroller
> to json-schema")
> Signed-off-by: Kunihiko Hayashi
> ---
> .../devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml| 8
> ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
> b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
> index f88d362..c871d46 100644
> --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
> @@ -31,12 +31,16 @@ properties:
>
>clocks:
> minItems: 1
> -maxItems: 2
> +maxItems: 3
>
>clock-names:
> oneOf:
>- const: link # for PXs2
> - - items: # for PXs3
> + - items: # for PXs3 with phy-ext
> +- const: link
> +- const: phy
> +- const: phy-ext
> + - items: # for others
> - const: link
> - const: phy
>
> --
> 2.7.4
--
~Vinod
Re: [PATCH] phy: allwinner: Make PHY_SUN6I_MIPI_DPHY depend on COMMON_CLK
On 07-07-20, 17:22, Tiezhu Yang wrote: > When CONFIG_ARCH_SUNXI is not set but CONFIG_COMPILE_TEST=y, > CONFIG_HAVE_CLK=y, CONFIG_HAVE_LEGACY_CLK=y, there exists > the following build errors with CONFIG_PHY_SUN6I_MIPI_DPHY=y: > > drivers/phy/allwinner/phy-sun6i-mipi-dphy.o: In function `sun6i_dphy_init': > phy-sun6i-mipi-dphy.c:(.text+0x320): undefined reference to > `clk_set_rate_exclusive' > drivers/phy/allwinner/phy-sun6i-mipi-dphy.o: In function `sun6i_dphy_exit': > phy-sun6i-mipi-dphy.c:(.text+0x2c8): undefined reference to > `clk_rate_exclusive_put' > > clk_set_rate_exclusive() and clk_rate_exclusive_put() are defined > in drivers/clk/clk.c, this file is built under CONFIG_COMMON_CLK, > so in order to build drivers/phy/allwinner/phy-sun6i-mipi-dphy.c > successful used with various configs, CONFIG_PHY_SUN6I_MIPI_DPHY > should depend on CONFIG_COMMON_CLK. Applied, thanks -- ~Vinod
Re: [PATCH] x86/entry: Fix vectors to IDTENTRY_SYSVEC for CONFIG_HYPERV
On Mon, Jul 13, 2020 at 1:11 AM Sedat Dilek wrote: > > When using Clang's Integrated Assembler (LLVM_IAS=1) we fell over > ClangBuiltLinux (CBL) issue #1043 where Jian Cai provided a fix. > Just FYI: Patch submitted by Jian. - Sedat - [1] https://lore.kernel.org/patchwork/patch/1271455/ [2] https://lore.kernel.org/lkml/20200713012428.1039487-1-caij2...@gmail.com/
Re: [PATCH 1/3] Bluetooth: Add new quirk for broken local ext features max_page
On Tue, Jul 7, 2020 at 9:03 AM Marcel Holtmann wrote: > > Hi Vasily, > > > Some adapters (e.g. RTL8723CS) advertise that they have more than > > 2 pages for local ext features, but they don't support any features > > declared in these pages. RTL8723CS reports max_page = 2 and declares > > support for sync train and secure connection, but it responds with > > either garbage or with error in status on corresponding commands. > > please send the btmon for this so I can see what the controller is responding. Here is relevant part: < HCI Command: Read Local Extend.. (0x04|0x0004) plen 1 #228 [hci0] 6.889869 Page: 2 > HCI Event: Command Complete (0x0e) plen 14 #229 [hci0] 6.890487 Read Local Extended Features (0x04|0x0004) ncmd 2 Status: Success (0x00) Page: 2/2 Features: 0x5f 0x03 0x00 0x00 0x00 0x00 0x00 0x00 Connectionless Slave Broadcast - Master Connectionless Slave Broadcast - Slave Synchronization Train Synchronization Scan Inquiry Response Notification Event Coarse Clock Adjustment Secure Connections (Controller Support) Ping < HCI Command: Delete Stored Lin.. (0x03|0x0012) plen 7 #230 [hci0] 6.890559 Address: 00:00:00:00:00:00 (OUI 00-00-00) Delete all: 0x01 > HCI Event: Command Complete (0x0e) plen 6 #231 [hci0] 6.891170 Delete Stored Link Key (0x03|0x0012) ncmd 2 Status: Success (0x00) Num keys: 0 < HCI Command: Read Synchronizat.. (0x03|0x0077) plen 0 #232 [hci0] 6.891199 > HCI Event: Command Complete (0x0e) plen 9 #233 [hci0] 6.891788 Read Synchronization Train Parameters (0x03|0x0077) ncmd 2 invalid packet size 01 ac bd 11 80 80.. = Close Index: 00:E0:4C:23:99:87 [hci0] 6.891832 hci0 registration stops here and bluetoothctl doesn't even see the controller. > Regards > > Marcel >
Re: [PATCH v1 1/1] phy: tusb1210: use bitmasks to set VENDOR_SPECIFIC2
On 01-07-20, 21:06, Liam Beguin wrote:
> From: Liam Beguin
>
> Start by reading the content of the VENDOR_SPECIFIC2 register and update
> each bit field based on device properties when defined.
>
> The use of bit masks prevents fields from overriding each other and
> enables users to clear bits which are set by default, like datapolarity
> in this instance.
>
> Signed-off-by: Liam Beguin
> ---
> drivers/phy/ti/phy-tusb1210.c | 29 -
> 1 file changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/phy/ti/phy-tusb1210.c b/drivers/phy/ti/phy-tusb1210.c
> index d8d0cc11d187..a957655ebd36 100644
> --- a/drivers/phy/ti/phy-tusb1210.c
> +++ b/drivers/phy/ti/phy-tusb1210.c
> @@ -13,9 +13,9 @@
> #include
>
> #define TUSB1210_VENDOR_SPECIFIC20x80
> -#define TUSB1210_VENDOR_SPECIFIC2_IHSTX_SHIFT0
> -#define TUSB1210_VENDOR_SPECIFIC2_ZHSDRV_SHIFT 4
> -#define TUSB1210_VENDOR_SPECIFIC2_DP_SHIFT 6
> +#define TUSB1210_VENDOR_SPECIFIC2_IHSTX_MASK 0x0f
> +#define TUSB1210_VENDOR_SPECIFIC2_ZHSDRV_MASK0x30
Why not be better and use GENMASK(3, 0) and GENMASK(5, 4) for these
> +#define TUSB1210_VENDOR_SPECIFIC2_DP_MASKBIT(6)
>
> struct tusb1210 {
> struct ulpi *ulpi;
> @@ -118,22 +118,25 @@ static int tusb1210_probe(struct ulpi *ulpi)
>* diagram optimization and DP/DM swap.
>*/
>
> + reg = ulpi_read(ulpi, TUSB1210_VENDOR_SPECIFIC2);
> +
> /* High speed output drive strength configuration */
> - device_property_read_u8(>dev, "ihstx", );
> - reg = val << TUSB1210_VENDOR_SPECIFIC2_IHSTX_SHIFT;
> + if (!device_property_read_u8(>dev, "ihstx", ))
> + reg = (reg & ~TUSB1210_VENDOR_SPECIFIC2_IHSTX_MASK) |
> + (val & TUSB1210_VENDOR_SPECIFIC2_IHSTX_MASK);
It would be better to use a helper to do this
>
> /* High speed output impedance configuration */
> - device_property_read_u8(>dev, "zhsdrv", );
> - reg |= val << TUSB1210_VENDOR_SPECIFIC2_ZHSDRV_SHIFT;
> + if (!device_property_read_u8(>dev, "zhsdrv", ))
> + reg = (reg & ~TUSB1210_VENDOR_SPECIFIC2_ZHSDRV_MASK) |
> + (val & TUSB1210_VENDOR_SPECIFIC2_ZHSDRV_MASK);
>
> /* DP/DM swap control */
> - device_property_read_u8(>dev, "datapolarity", );
> - reg |= val << TUSB1210_VENDOR_SPECIFIC2_DP_SHIFT;
> + if (!device_property_read_u8(>dev, "datapolarity", ))
> + reg = (reg & ~TUSB1210_VENDOR_SPECIFIC2_DP_MASK) |
> + (val & TUSB1210_VENDOR_SPECIFIC2_DP_MASK);
>
> - if (reg) {
> - ulpi_write(ulpi, TUSB1210_VENDOR_SPECIFIC2, reg);
> - tusb->vendor_specific2 = reg;
> - }
> + ulpi_write(ulpi, TUSB1210_VENDOR_SPECIFIC2, reg);
> + tusb->vendor_specific2 = reg;
>
> tusb->phy = ulpi_phy_create(ulpi, _ops);
> if (IS_ERR(tusb->phy))
>
> base-commit: cd77006e01b3198c75fb7819b3d0ff89709539bb
fatal: bad object cd77006e01b3198c75fb7819b3d0ff89709539bb in
linux-phy.git
--
~Vinod
Re: [PATCH v8 2/6] IIO: Ingenic JZ47xx: Error check clk_enable calls.
On Sun, 2020-07-12 at 13:02 +0100, Jonathan Cameron wrote:
> On Thu, 9 Jul 2020 17:21:56 +0200
> Artur Rojek wrote:
>
> > Introduce error checks for the clk_enable calls used in this driver.
> > As part of the changes, move clk_enable/clk_disable calls out of
> > ingenic_adc_set_config and into respective logic of its callers.
> >
> > Signed-off-by: Artur Rojek
> > Tested-by: Paul Cercueil
> Applied.
>
> Thanks,
>
> Jonathan
>
> > ---
> >
> > Changes:
> >
> > v6: new patch
> >
> > v7: no change
> >
> > v8: move `clk_disable` outside the lock
> >
> > drivers/iio/adc/ingenic-adc.c | 25 +
> > 1 file changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/iio/adc/ingenic-adc.c b/drivers/iio/adc/ingenic-
> > adc.c
> > index 39c0a609fc94..c1946a9f1cca 100644
> > --- a/drivers/iio/adc/ingenic-adc.c
> > +++ b/drivers/iio/adc/ingenic-adc.c
> > @@ -73,7 +73,6 @@ static void ingenic_adc_set_config(struct ingenic_adc
> > *adc,
> > {
> > uint32_t cfg;
> >
> > - clk_enable(adc->clk);
> > mutex_lock(>lock);
> >
> > cfg = readl(adc->base + JZ_ADC_REG_CFG) & ~mask;
> > @@ -81,7 +80,6 @@ static void ingenic_adc_set_config(struct ingenic_adc
> > *adc,
> > writel(cfg, adc->base + JZ_ADC_REG_CFG);
> >
> > mutex_unlock(>lock);
> > - clk_disable(adc->clk);
> > }
> >
> > static void ingenic_adc_enable(struct ingenic_adc *adc,
> > @@ -124,6 +122,8 @@ static int ingenic_adc_write_raw(struct iio_dev
> > *iio_dev,
> > long m)
> > {
> > struct ingenic_adc *adc = iio_priv(iio_dev);
> > + struct device *dev = iio_dev->dev.parent;
> > + int ret;
> >
> > switch (m) {
> > case IIO_CHAN_INFO_SCALE:
> > @@ -131,6 +131,14 @@ static int ingenic_adc_write_raw(struct iio_dev
> > *iio_dev,
> > case INGENIC_ADC_BATTERY:
> > if (!adc->soc_data->battery_vref_mode)
> > return -EINVAL;
> > +
> > + ret = clk_enable(adc->clk);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable clock:
> > %d\n",
> > + ret);
> > + return ret;
> > + }
> > +
> > if (val > JZ_ADC_BATTERY_LOW_VREF) {
> > ingenic_adc_set_config(adc,
> >JZ_ADC_REG_CFG_BAT_M
> > D,
> > @@ -142,6 +150,9 @@ static int ingenic_adc_write_raw(struct iio_dev
> > *iio_dev,
> >JZ_ADC_REG_CFG_BAT_M
> > D);
> > adc->low_vref_mode = true;
> > }
> > +
> > + clk_disable(adc->clk);
> > +
> > return 0;
> > default:
> > return -EINVAL;
> > @@ -317,6 +328,13 @@ static int ingenic_adc_read_chan_info_raw(struct
> > ingenic_adc *adc,
> > int *val)
> > {
> > int bit, ret, engine = (chan->channel == INGENIC_ADC_BATTERY);
> > + struct device *dev = iio_priv_to_dev(adc)->dev.parent;
This uses iio_priv_to_dev(), which should be removed [if it hasn't been
already].
Also, with the iio_dev_opaque struct/type, using the iio_priv_to_dev()
helper shouldn't work, or should give undefined behavior, as the offset to
the private data should be matched against iio_dev_opaque (and not
iio_dev).
Looking at this code, it looks like ingenic_adc_read_chan_info_raw() can
take an 'indio_dev' reference and obtain the private information via
iio_priv()
Maybe [for some] there's a question as to why iio_priv_to_dev() is being
removed.
The answer is: because the iio_dev_opaque struct/type was introduced to
hide some iio_dev [INTERN] fields; the main reason for hiding them [aside
from good coding practice, and because they belong to the IIO framework] is
to not have to review new drivers being copied/adapted from old drivers.
Naturally, the iio_priv_to_dev() could have been kept around [in a reworked
form], but it didn't make much sense, since most users of iio_priv_to_dev()
could access a reference to indio_dev without much/any hassle.
> > +
> > + ret = clk_enable(adc->clk);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable clock: %d\n", ret);
> > + return ret;
> > + }
> >
> > /* We cannot sample AUX/AUX2 in parallel. */
> > mutex_lock(>aux_lock);
> > @@ -325,7 +343,6 @@ static int ingenic_adc_read_chan_info_raw(struct
> > ingenic_adc *adc,
> > ingenic_adc_set_config(adc, JZ_ADC_REG_CFG_AUX_MD, bit);
> > }
> >
> > - clk_enable(adc->clk);
> > ret = ingenic_adc_capture(adc, engine);
> > if (ret)
> > goto out;
> > @@ -342,8 +359,8 @@ static int ingenic_adc_read_chan_info_raw(struct
> > ingenic_adc *adc,
> >
> > ret = IIO_VAL_INT;
> > out:
> > - clk_disable(adc->clk);
> > mutex_unlock(>aux_lock);
> >
Re: [PATCH 2/3] Bluetooth: btrtl: add support for the RTL8723CS
On Tue, Jul 7, 2020 at 9:01 AM Marcel Holtmann wrote:
>
> Hi Vasily,
>
> > The Realtek RTL8723CS is SDIO WiFi chip. It also contains a Bluetooth
> > module which is connected via UART to the host.
> >
> > It shares lmp subversion with 8703B, so Realtek's userspace
> > initialization tool (rtk_hciattach) differentiates varieties of RTL8723CS
> > (CG, VF, XX) with RTL8703B using vendor's command to read chip type.
> >
> > Also this chip declares support for some features it doesn't support
> > so add a quirk to indicate that these features are broken.
> >
> > Signed-off-by: Vasily Khoruzhick
> > ---
> > drivers/bluetooth/btrtl.c | 128 -
> > drivers/bluetooth/btrtl.h | 12
> > drivers/bluetooth/hci_h5.c | 6 ++
> > 3 files changed, 143 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
> > index 3a9afc905f24..8c7b35abe492 100644
> > --- a/drivers/bluetooth/btrtl.c
> > +++ b/drivers/bluetooth/btrtl.c
> > @@ -17,8 +17,12 @@
> >
> > #define VERSION "0.1"
> >
> > +#define RTL_CHIP_8723CS_CG 3
> > +#define RTL_CHIP_8723CS_VF 4
> > +#define RTL_CHIP_8723CS_XX 5
> > #define RTL_EPATCH_SIGNATURE "Realtech"
> > #define RTL_ROM_LMP_3499 0x3499
> > +#define RTL_ROM_LMP_8703B0x8703
> > #define RTL_ROM_LMP_8723A 0x1200
> > #define RTL_ROM_LMP_8723B 0x8723
> > #define RTL_ROM_LMP_8723D 0x8873
> > @@ -31,6 +35,7 @@
> > #define IC_MATCH_FL_HCIREV(1 << 1)
> > #define IC_MATCH_FL_HCIVER(1 << 2)
> > #define IC_MATCH_FL_HCIBUS(1 << 3)
> > +#define IC_MATCH_FL_CHIP_TYPE(1 << 4)
> > #define IC_INFO(lmps, hcir) \
> > .match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_HCIREV, \
> > .lmp_subver = (lmps), \
> > @@ -42,6 +47,7 @@ struct id_table {
> > __u16 hci_rev;
> > __u8 hci_ver;
> > __u8 hci_bus;
> > + __u8 chip_type;
> > bool config_needed;
> > bool has_rom_version;
> > char *fw_name;
> > @@ -89,6 +95,39 @@ static const struct id_table ic_id_table[] = {
> > .fw_name = "rtl_bt/rtl8723b_fw.bin",
> > .cfg_name = "rtl_bt/rtl8723b_config" },
> >
> > + /* 8723CS-CG */
> > + { .match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_CHIP_TYPE |
> > + IC_MATCH_FL_HCIBUS,
> > + .lmp_subver = RTL_ROM_LMP_8703B,
> > + .chip_type = RTL_CHIP_8723CS_CG,
> > + .hci_bus = HCI_UART,
> > + .config_needed = true,
> > + .has_rom_version = true,
> > + .fw_name = "rtl_bt/rtl8723cs_cg_fw.bin",
> > + .cfg_name = "rtl_bt/rtl8723cs_cg_config" },
> > +
> > + /* 8723CS-VF */
> > + { .match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_CHIP_TYPE |
> > + IC_MATCH_FL_HCIBUS,
> > + .lmp_subver = RTL_ROM_LMP_8703B,
> > + .chip_type = RTL_CHIP_8723CS_VF,
> > + .hci_bus = HCI_UART,
> > + .config_needed = true,
> > + .has_rom_version = true,
> > + .fw_name = "rtl_bt/rtl8723cs_vf_fw.bin",
> > + .cfg_name = "rtl_bt/rtl8723cs_vf_config" },
> > +
> > + /* 8723CS-XX */
> > + { .match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_CHIP_TYPE |
> > + IC_MATCH_FL_HCIBUS,
> > + .lmp_subver = RTL_ROM_LMP_8703B,
> > + .chip_type = RTL_CHIP_8723CS_XX,
> > + .hci_bus = HCI_UART,
> > + .config_needed = true,
> > + .has_rom_version = true,
> > + .fw_name = "rtl_bt/rtl8723cs_xx_fw.bin",
> > + .cfg_name = "rtl_bt/rtl8723cs_xx_config" },
> > +
> > /* 8723D */
> > { IC_INFO(RTL_ROM_LMP_8723B, 0xd),
> > .config_needed = true,
> > @@ -171,7 +210,8 @@ static const struct id_table ic_id_table[] = {
> > };
> >
> > static const struct id_table *btrtl_match_ic(u16 lmp_subver, u16 hci_rev,
> > - u8 hci_ver, u8 hci_bus)
> > + u8 hci_ver, u8 hci_bus,
> > + u8 chip_type)
> > {
> > int i;
> >
> > @@ -188,6 +228,9 @@ static const struct id_table *btrtl_match_ic(u16
> > lmp_subver, u16 hci_rev,
> > if ((ic_id_table[i].match_flags & IC_MATCH_FL_HCIBUS) &&
> > (ic_id_table[i].hci_bus != hci_bus))
> > continue;
> > + if ((ic_id_table[i].match_flags & IC_MATCH_FL_CHIP_TYPE) &&
> > + (ic_id_table[i].chip_type != chip_type))
> > + continue;
> >
> > break;
> > }
> > @@ -270,6 +313,7 @@ static int rtlbt_parse_firmware(struct hci_dev *hdev,
> > { RTL_ROM_LMP_8723B, 1 },
> > { RTL_ROM_LMP_8821A, 2 },
> > { RTL_ROM_LMP_8761A, 3 },
> > + { RTL_ROM_LMP_8703B, 7 },
> > { RTL_ROM_LMP_8822B, 8 },
> > { RTL_ROM_LMP_8723B, 9 }, /* 8723D */
> > { RTL_ROM_LMP_8821A, 10 }, /* 8821C */
> > @@ -545,6 +589,48 @@ static int
Re: [PATCH v2 2/2] phy: socionext: Add UniPhier AHCI PHY driver support
On 30-06-20, 17:59, Kunihiko Hayashi wrote:
> +++ b/drivers/phy/socionext/phy-uniphier-ahci.c
> @@ -0,0 +1,335 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * phy-uniphier-ahci.c - PHY driver for UniPhier AHCI controller
> + * Copyright 2016-2018, Socionext Inc.
we are in 2020 now!
> +static int uniphier_ahciphy_pxs2_power_on(struct uniphier_ahciphy_priv *priv)
> +{
> + int ret;
> + u32 val;
> +
> + /* enable reference clock for PHY */
> + val = readl(priv->base + CKCTRL);
> + val |= CKCTRL_REF_SSP_EN;
> + writel(val, priv->base + CKCTRL);
> +
> + /* release port reset */
> + val = readl(priv->base + CKCTRL);
> + val &= ~CKCTRL_P0_RESET;
> + writel(val, priv->base + CKCTRL);
> +
> + /* wait until PLL is ready */
> + if (priv->data->is_ready_high)
> + ret = readl_poll_timeout(priv->base + CKCTRL, val,
> + (val & CKCTRL_P0_READY), 200, 400);
> + else
> + ret = readl_poll_timeout(priv->base + CKCTRL, val,
> + !(val & CKCTRL_P0_READY), 200, 400);
> + if (ret) {
> + dev_err(priv->dev, "Failed to check whether PHY PLL is
> ready\n");
> + goto out_disable_clock;
> + }
> +
> + return 0;
> +
> +out_disable_clock:
> + /* assert port reset */
> + val = readl(priv->base + CKCTRL);
> + val |= CKCTRL_P0_RESET;
> + writel(val, priv->base + CKCTRL);
> +
> + /* disable reference clock for PHY */
> + val = readl(priv->base + CKCTRL);
> + val &= ~CKCTRL_REF_SSP_EN;
> + writel(val, priv->base + CKCTRL);
this seems to be repeated patter, why not add a modifyl() helper here..
> +static int uniphier_ahciphy_pxs3_init(struct uniphier_ahciphy_priv *priv)
> +{
> + int i;
> + u32 val;
> +
> + /* setup port parameter */
> + val = readl(priv->base + TXCTRL0);
> + val &= ~TXCTRL0_AMP_G3_MASK;
> + val |= FIELD_PREP(TXCTRL0_AMP_G3_MASK, 0x73);
> + val &= ~TXCTRL0_AMP_G2_MASK;
> + val |= FIELD_PREP(TXCTRL0_AMP_G2_MASK, 0x46);
> + val &= ~TXCTRL0_AMP_G1_MASK;
> + val |= FIELD_PREP(TXCTRL0_AMP_G1_MASK, 0x42);
> + writel(val, priv->base + TXCTRL0);
> +
> + val = readl(priv->base + TXCTRL1);
> + val &= ~TXCTRL1_DEEMPH_G3_MASK;
> + val |= FIELD_PREP(TXCTRL1_DEEMPH_G3_MASK, 0x23);
> + val &= ~TXCTRL1_DEEMPH_G2_MASK;
> + val |= FIELD_PREP(TXCTRL1_DEEMPH_G2_MASK, 0x05);
> + val &= ~TXCTRL1_DEEMPH_G1_MASK;
> + val |= FIELD_PREP(TXCTRL1_DEEMPH_G1_MASK, 0x05);
> +
> + val = readl(priv->base + RXCTRL);
> + val &= ~RXCTRL_LOS_LVL_MASK;
> + val |= FIELD_PREP(RXCTRL_LOS_LVL_MASK, 0x9);
> + val &= ~RXCTRL_LOS_BIAS_MASK;
> + val |= FIELD_PREP(RXCTRL_LOS_BIAS_MASK, 0x2);
> + val &= ~RXCTRL_RX_EQ_MASK;
> + val |= FIELD_PREP(RXCTRL_RX_EQ_MASK, 0x1);
> +
> + /* dummy read 25 times */
why?
> +static int uniphier_ahciphy_init(struct phy *phy)
> +{
> + struct uniphier_ahciphy_priv *priv = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = clk_prepare_enable(priv->clk_parent);
> + if (ret)
> + return ret;
> +
> + ret = reset_control_deassert(priv->rst_parent);
> + if (ret)
> + goto out_clk_disable;
> +
> + if (priv->data->init) {
> + ret = priv->data->init(priv);
> + if (ret)
> + goto out_rst_assert;
> + }
> +
> + return ret;
return 0?
> +static const struct uniphier_ahciphy_soc_data uniphier_pxs2_data = {
> + .init = NULL,
Isn't this superfluous ?
--
~Vinod
Re: [PATCH RFC] kprobes: Remove MODULES dependency
On Fri, Jul 10, 2020 at 12:49:10PM +0200, Peter Zijlstra wrote: > On Fri, Jul 10, 2020 at 01:36:38PM +0300, Jarkko Sakkinen wrote: > > Just so that I know (and learn), what did exactly disable optprobes? > > So regular, old-skool style kprobe is: > > - copy original instruction out > - replace instruction with breakpoint (int3 on x86) > - have exception handler return to the copied instruction with > single-step on > - have single step exception handler return to the original > instruction stream > > which is 2 exceptions. Out of pure interest, how does it handle a jump (as the original opcode), given that it single steps a copy? > optprobes avoid the single-step by not only writing a single > instruction, but additionally placing a JMP instruction behind it such > that it will automagically continue in the original instruction stream. > > This brings the requirement that the copied instruction is placed > within the JMP displacement of the regular kernel text (s32 on x86). > > module_alloc() ensures the memory provided is within that range. Right, a relative jump is placed instead of 0xcc to the breakpoint? /Jarkko
[PATCH v1 4/4] scsi: ufs: Fix up and simplify error recovery mechanism
Error recovery can be invoked from multiple paths, including hibern8
enter/exit, some vendor vops, ufshcd_eh_host_reset_handler(), resume and
eh_work scheduled from IRQ context. Ultimately, these paths are trying to
invoke ufshcd_reset_and_restore(), in either sync or async manner.
Having both sync and async manners at the same time has some problems
- If link recovery happens during clock scaling work, acquring scaling_lock
in ufshcd_exec_dev_cmd() would cause dead lock, because scaling_lock is
already held by scaling work before link recovery happens.
- If link recovery happens during ungate work, ufshcd_hold() would be
called recursively. Although commit 53c12d0ef6fcb
("scsi: ufs: fix error recovery after the hibern8 exit failure") fixed
a deadlock due to recursive calls of ufshcd_hold() by adding a check
of eh_in_progress into ufshcd_hold(), this check added to ufshcd_hold()
allows eh_work to run in parallel when link recovery is running.
- Similar concurrency can also happen to error recovery invoked from
eh_host_reset_handler(), although it tries to protect it from happening
by flushing eh_work before start invoking reset and restore, after flush
work returns, eh_work can still be scheduled and running in parallel.
- Concurrency can even happen between eh_works. eh_work, currently queued
on system_wq, is allowed to have multiple instances running in parallel,
but we don't have proper protection for that.
To fix up and simplify error recovery mechanism, this change mainly does
below things
o Queue eh_work on a single threaded workqueue to avoid concurrency between
eh_works.
o According to the UFSHCI JEDEC spec, hibern8 enter/exit error occurs when
the link is broken. This actaully applies to any power mode change
operations. In this change, if a power mode change operation (including
AH8 enter/exit) fails, mark the link state as UIC_LINK_BROKEN_STATE and
schedule eh_work. eh_work needs to do full reset and restore to recover
the link stack to active. Before the link state is recovered back to
active by eh_work, any power mode change attempts just return -ENOLINK to
avoid consecutive HW error.
o To avoid concurrency between eh_work and link recovery, remove link
recovery from hibern8 enter/exit func. If hibern8 enter/exit func fails,
simply return error code and let eh_work run in parallel.
o Recover UFS hba runtime PM error in eh_work. If ufschd_suspend/resume
fails due to UFS error, e.g. hibern8 enter/exit error and SSU cmd error,
the runtime PM framework saves the error to dev.power.runtime_error.
After that, hba runtime suspend/resume would not be invoked anymore until
dev.power.runtime_error is cleared. The runtime PM error can be recovered
in eh_work by calling pm_runtime_set_active() after reset and restore
succeeds. Meanwhile, if pm_runtime_set_active() returns no error, which
means dev.power.runtime_error is cleared, we also need to explicitly
resume those scsi devices under hba in case any of them has failed to be
resumed due to hba runtime resume error.
o Fix a racing problem between eh_work and ufshcd_suspend/resume. In the
old code, it blocks scsi requests before schedules eh_work, but when
eh_work calls pm_runtime_get_sync(), if ufshcd_suspend/resume is sending
a scsi cmd, most likely the SSU cmd, pm_runtime_get_sync() will never
return because scsi requests were blocked. To fix this racing problem,
o Don't block scsi requests before schedule eh_work, but let eh_work
block scsi requests when eh_work is ready to start error recovery.
o Meanwhile, if eh_work is schueduled due to fatal error, don't requeue
the scsi cmds sent from ufshcd_suspend/resume path, but simply let the
scsi cmds fail. If the scsi cmds fail, hba runtime suspend/resume fails
too, but it does hurt since eh_work recovers hba runtime PM error.
o Move host/regs dump in ufshcd_check_errors() to eh_work because heavy
dump in IRQ context can lead to stability issues. In addition, some clean
up in ufshcd_print_host_regs() and ufshcd_print_host_state().
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufs-sysfs.c | 1 +
drivers/scsi/ufs/ufshcd.c| 441 ++-
drivers/scsi/ufs/ufshcd.h| 15 ++
3 files changed, 284 insertions(+), 173 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
index 2d71d23..02d379f00 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -16,6 +16,7 @@ static const char *ufschd_uic_link_state_to_string(
case UIC_LINK_OFF_STATE:return "OFF";
case UIC_LINK_ACTIVE_STATE: return "ACTIVE";
case UIC_LINK_HIBERN8_STATE:return "HIBERN8";
+ case UIC_LINK_BROKEN_STATE: return "BROKEN";
default:return "UNKNOWN";
}
}
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 33214bb..98bd28b 100644
---
[PATCH v1 3/4] ufs: ufs-qcom: Fix a few BUGs in func ufs_qcom_dump_dbg_regs()
Dumping testbus registers needs to sleep a bit intermittently as there are
too many of them. Skip them for those contexts where sleep is not allowed.
Meanwhile, if ufs_qcom_dump_dbg_regs() calls ufs_qcom_testbus_config() from
ufshcd_suspend/resume and/or clk gate/ungate context, pm_runtime_get_sync()
and ufshcd_hold() will cause racing problems. Fix it by removing the
unnecessary calls of pm_runtime_get_sync() and ufshcd_hold().
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufs-qcom.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2e6ddb5..3743c17 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1604,9 +1604,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host *host)
*/
}
mask <<= offset;
-
- pm_runtime_get_sync(host->hba->dev);
- ufshcd_hold(host->hba, false);
ufshcd_rmwl(host->hba, TEST_BUS_SEL,
(u32)host->testbus.select_major << 19,
REG_UFS_CFG1);
@@ -1619,8 +1616,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host *host)
* committed before returning.
*/
mb();
- ufshcd_release(host->hba);
- pm_runtime_put_sync(host->hba->dev);
return 0;
}
@@ -1658,11 +1653,13 @@ static void ufs_qcom_dump_dbg_regs(struct ufs_hba *hba)
/* sleep a bit intermittently as we are dumping too much data */
ufs_qcom_print_hw_debug_reg_all(hba, NULL, ufs_qcom_dump_regs_wrapper);
- udelay(1000);
- ufs_qcom_testbus_read(hba);
- udelay(1000);
- ufs_qcom_print_unipro_testbus(hba);
- udelay(1000);
+ if (in_task()) {
+ udelay(1000);
+ ufs_qcom_testbus_read(hba);
+ udelay(1000);
+ ufs_qcom_print_unipro_testbus(hba);
+ udelay(1000);
+ }
}
/**
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
[PATCH v1 1/4] scsi: ufs: Add checks before setting clk-gating states
Clock gating features can be turned on/off selectively which means its
state information is only important if it is enabled. This change makes
sure that we only look at state of clk-gating if it is enabled.
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index efc0a6c..ebf7a95 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1839,6 +1839,8 @@ static void ufshcd_init_clk_gating(struct ufs_hba *hba)
if (!ufshcd_is_clkgating_allowed(hba))
return;
+ hba->clk_gating.state = CLKS_ON;
+
hba->clk_gating.delay_ms = 150;
INIT_DELAYED_WORK(>clk_gating.gate_work, ufshcd_gate_work);
INIT_WORK(>clk_gating.ungate_work, ufshcd_ungate_work);
@@ -2538,7 +2540,8 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
err = SCSI_MLQUEUE_HOST_BUSY;
goto out;
}
- WARN_ON(hba->clk_gating.state != CLKS_ON);
+ if (ufshcd_is_clkgating_allowed(hba))
+ WARN_ON(hba->clk_gating.state != CLKS_ON);
lrbp = >lrb[tag];
@@ -8315,8 +8318,11 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum
ufs_pm_op pm_op)
/* If link is active, device ref_clk can't be switched off */
__ufshcd_setup_clocks(hba, false, true);
- hba->clk_gating.state = CLKS_OFF;
- trace_ufshcd_clk_gating(dev_name(hba->dev), hba->clk_gating.state);
+ if (ufshcd_is_clkgating_allowed(hba)) {
+ hba->clk_gating.state = CLKS_OFF;
+ trace_ufshcd_clk_gating(dev_name(hba->dev),
+ hba->clk_gating.state);
+ }
/* Put the host controller in low power mode if possible */
ufshcd_hba_vreg_set_lpm(hba);
@@ -8456,6 +8462,11 @@ static int ufshcd_resume(struct ufs_hba *hba, enum
ufs_pm_op pm_op)
if (hba->clk_scaling.is_allowed)
ufshcd_suspend_clkscaling(hba);
ufshcd_setup_clocks(hba, false);
+ if (ufshcd_is_clkgating_allowed(hba)) {
+ hba->clk_gating.state = CLKS_OFF;
+ trace_ufshcd_clk_gating(dev_name(hba->dev),
+ hba->clk_gating.state);
+ }
out:
hba->pm_op_in_progress = 0;
if (ret)
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
[PATCH v1 2/4] scsi: ufs: Fix imbalanced scsi_block_reqs_cnt caused by ufshcd_hold()
The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be decreased back in ufshcd_ungate_work() in a paired way. However, if specific ufshcd_hold/release sequences are met, it is possible that scsi_block_reqs_cnt is increased twice but only one ungate work is queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold() and ufshcd_ungate_work() in a paired way, increase it only if queue_work() returns true. Signed-off-by: Can Guo --- drivers/scsi/ufs/ufshcd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index ebf7a95..33214bb 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -1611,12 +1611,12 @@ int ufshcd_hold(struct ufs_hba *hba, bool async) */ /* fallthrough */ case CLKS_OFF: - ufshcd_scsi_block_requests(hba); hba->clk_gating.state = REQ_CLKS_ON; trace_ufshcd_clk_gating(dev_name(hba->dev), hba->clk_gating.state); - queue_work(hba->clk_gating.clk_gating_workq, - >clk_gating.ungate_work); + if (queue_work(hba->clk_gating.clk_gating_workq, + >clk_gating.ungate_work)) + ufshcd_scsi_block_requests(hba); /* * fall through to check if we should wait for this * work to be done or not. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH] staging: qlge: Remove pci-dma-compat wrapper APIs.
On 2020-07-11 18:16 +0530, Suraj Upadhyay wrote: > The legacy API wrappers in include/linux/pci-dma-compat.h > should go away as it creates unnecessary midlayering > for include/linux/dma-mapping.h APIs, instead use dma-mapping.h > APIs directly. > > The patch has been generated with the coccinelle script below > and compile-tested. > [...] > > @@ expression E1, E2, E3, E4; @@ > - pci_dma_sync_single_for_device(E1, E2, E3, E4) > + dma_sync_single_for_device(>dev, E2, E3, (enum dma_data_direction)E4) The qlge driver contains more usages of the deprecated pci_dma_* api than what this diff addresses. In particular, there are some calls to pci_dma_sync_single_for_cpu() which were not changed despite this expression being in the semantic patch. Dunno what happened but it should be reviewed. After converting away from all of the old api, the TODO file should also be updated. [...] > > diff --git a/drivers/staging/qlge/qlge_mpi.c b/drivers/staging/qlge/qlge_mpi.c > index fa178fc642a6..16a9bf818346 100644 > --- a/drivers/staging/qlge/qlge_mpi.c > +++ b/drivers/staging/qlge/qlge_mpi.c > @@ -788,8 +788,9 @@ int ql_dump_risc_ram_area(struct ql_adapter *qdev, void > *buf, > char *my_buf; > dma_addr_t buf_dma; > > - my_buf = pci_alloc_consistent(qdev->pdev, word_count * sizeof(u32), > - _dma); > + my_buf = dma_alloc_coherent(>pdev->dev, > + word_count * sizeof(u32), _dma, > + GFP_ATOMIC); > if (!my_buf) > return -EIO; > > @@ -797,8 +798,8 @@ int ql_dump_risc_ram_area(struct ql_adapter *qdev, void > *buf, > if (!status) > memcpy(buf, my_buf, word_count * sizeof(u32)); > > - pci_free_consistent(qdev->pdev, word_count * sizeof(u32), my_buf, > - buf_dma); > + dma_free_coherent(>pdev->dev, word_count * sizeof(u32), my_buf, > + buf_dma); > return status; > } > > -- > 2.17.1 > signature.asc Description: PGP signature
Re: [PATCH 4/5] dma-mapping: add a dma_ops_bypass flag to struct device
On 09/07/2020 01:24, Christoph Hellwig wrote:
> Several IOMMU drivers have a bypass mode where they can use a direct
> mapping if the devices DMA mask is large enough. Add generic support
> to the core dma-mapping code to do that to switch those drivers to
> a common solution.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/device.h | 8 +
> kernel/dma/Kconfig | 8 +
> kernel/dma/mapping.c | 74 +-
> 3 files changed, 68 insertions(+), 22 deletions(-)
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 4c4af98321ebd6..1f71acf37f78d7 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -523,6 +523,11 @@ struct dev_links_info {
> * sync_state() callback.
> * @dma_coherent: this particular device is dma coherent, even if the
> * architecture supports non-coherent devices.
> + * @dma_ops_bypass: If set to %true then the dma_ops are bypassed for the
> + * streaming DMA operations (->map_* / ->unmap_* / ->sync_*),
> + * and optionall (if the coherent mask is large enough) also
s/optionall/optional/g
Otherwise the series looks good and works well on powernv and pseries.
Thanks,
--
Alexey
Re: [PATCH v2 1/2] dt-bindings: phy: Add UniPhier AHCI PHY description
On 30-06-20, 17:59, Kunihiko Hayashi wrote:
> Add DT bindings for PHY interface built into ahci controller implemented
> in UniPhier SoCs.
Rob ?
>
> Signed-off-by: Kunihiko Hayashi
> ---
> .../bindings/phy/socionext,uniphier-ahci-phy.yaml | 76
> ++
> 1 file changed, 76 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
> b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
> new file mode 100644
> index 000..bab2ff4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/socionext,uniphier-ahci-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Socionext UniPhier AHCI PHY
> +
> +description: |
> + This describes the deivcetree bindings for PHY interfaces built into
> + AHCI controller implemented on Socionext UniPhier SoCs.
> +
> +maintainers:
> + - Kunihiko Hayashi
> +
> +properties:
> + compatible:
> +enum:
> + - socionext,uniphier-pxs2-ahci-phy
> + - socionext,uniphier-pxs3-ahci-phy
> +
> + reg:
> +description: PHY register region (offset and length)
> +
> + "#phy-cells":
> +const: 0
> +
> + clocks:
> +maxItems: 2
> +
> + clock-names:
> +oneOf:
> + - items: # for PXs2
> +- const: link
> + - items: # for others
> +- const: link
> +- const: phy
> +
> + resets:
> +maxItems: 2
> +
> + reset-names:
> +items:
> + - const: link
> + - const: phy
> +
> +required:
> + - compatible
> + - reg
> + - "#phy-cells"
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +ahci-glue@6570 {
> +compatible = "socionext,uniphier-pxs3-ahci-glue",
> + "simple-mfd";
> +#address-cells = <1>;
> +#size-cells = <1>;
> +ranges = <0 0x6570 0x100>;
> +
> +ahci_phy: phy@10 {
> +compatible = "socionext,uniphier-pxs3-ahci-phy";
> +reg = <0x10 0x10>;
> +#phy-cells = <0>;
> +clock-names = "link", "phy";
> +clocks = <_clk 28>, <_clk 30>;
> +reset-names = "link", "phy";
> +resets = <_rst 28>, <_rst 30>;
> +};
> +};
> --
> 2.7.4
--
~Vinod
Re: [RFC PATCH 7/7] lazy tlb: shoot lazies, a non-refcounting lazy tlb option
Excerpts from Peter Zijlstra's message of July 10, 2020 7:35 pm:
> On Fri, Jul 10, 2020 at 11:56:46AM +1000, Nicholas Piggin wrote:
>> On big systems, the mm refcount can become highly contented when doing
>> a lot of context switching with threaded applications (particularly
>> switching between the idle thread and an application thread).
>>
>> Abandoning lazy tlb slows switching down quite a bit in the important
>> user->idle->user cases, so so instead implement a non-refcounted scheme
>> that causes __mmdrop() to IPI all CPUs in the mm_cpumask and shoot down
>> any remaining lazy ones.
>>
>> On a 16-socket 192-core POWER8 system, a context switching benchmark
>> with as many software threads as CPUs (so each switch will go in and
>> out of idle), upstream can achieve a rate of about 1 million context
>> switches per second. After this patch it goes up to 118 million.
>
> That's mighty impressive, however:
Well, it's the usual case of "find a bouncing line and scale up the
machine size until you achieve your desired improvements" :) But we
are looking at some fundamental scalabilities and seeing if we can
improve a few things.
>
>> +static void shoot_lazy_tlbs(struct mm_struct *mm)
>> +{
>> +if (IS_ENABLED(CONFIG_MMU_LAZY_TLB_SHOOTDOWN)) {
>> +smp_call_function_many(mm_cpumask(mm), do_shoot_lazy_tlb, (void
>> *)mm, 1);
>> +do_shoot_lazy_tlb(mm);
>> +}
>> +}
>
> IIRC you (power) never clear a CPU from that mask, so for other
> workloads I can see this resulting in massive amounts of IPIs.
>
> For instance, take as many processes as you have CPUs. For each,
> manually walk the task across all CPUs and exit. Again.
>
> Clearly, that's an extreme, but still...
We do have some issues with that, it does tend to be very self-limiting
though, short lived tasks that can drive lots of exits won't get to run
on a lot of cores.
It's worth keeping an eye on, it may not be too hard to mitigate the IPIs
doing something dumb like collecting a queue of mms before killing a
batch of them.
Thanks,
Nick
RE: [PATCH] exfat: retain 'VolumeFlags' properly
Hi Tetsuhiro,
> Retain ActiveFat, MediaFailure and ClearToZero fields.
> And, never clear VolumeDirty, if it is dirty at mount.
>
> In '3.1.13.3 Media Failure Field' of exfat specification says ...
> If, upon mounting a volume, the value of this field is 1, implementations
> which scan the entire
> volume for media failures and record all failures as "bad" clusters in the
> FAT (or otherwise resolve
> media failures) may clear the value of this field to 0.
> Therefore, should not clear MediaFailure without scanning volume.
>
> In '8.1 Recommended Write Ordering' of exfat specification says ...
> Clear the value of the VolumeDirty field to 0, if its value prior to the
> first step was 0 Therefore,
> should not clear VolumeDirty when mounted.
>
> Also, rename ERR_MEDIUM to MED_FAILURE.
I think that MEDIA_FAILURE looks better.
>
> Signed-off-by: Tetsuhiro Kohada
> ---
> fs/exfat/exfat_fs.h | 5 +++--
> fs/exfat/exfat_raw.h | 2 +-
> fs/exfat/super.c | 22 ++
> 3 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h index
> cb51d6e83199..3f8dc4ca8109 100644
> --- a/fs/exfat/exfat_fs.h
> +++ b/fs/exfat/exfat_fs.h
> @@ -224,7 +224,8 @@ struct exfat_sb_info {
> unsigned int num_FAT_sectors; /* num of FAT sectors */
> unsigned int root_dir; /* root dir cluster */
> unsigned int dentries_per_clu; /* num of dentries per cluster */
> - unsigned int vol_flag; /* volume dirty flag */
> + unsigned int vol_flags; /* volume flags */
> + unsigned int vol_flags_noclear; /* volume flags to retain */
> struct buffer_head *boot_bh; /* buffer_head of BOOT sector */
>
> unsigned int map_clu; /* allocation bitmap start cluster */ @@ -380,7
> +381,7 @@ static inline
> int exfat_sector_to_cluster(struct exfat_sb_info *sbi, }
>
> /* super.c */
> -int exfat_set_vol_flags(struct super_block *sb, unsigned short new_flag);
> +int exfat_set_vol_flags(struct super_block *sb, unsigned short
> +new_flags);
>
> /* fatent.c */
> #define exfat_get_next_cluster(sb, pclu) exfat_ent_get(sb, *(pclu), pclu)
> diff --git
> a/fs/exfat/exfat_raw.h b/fs/exfat/exfat_raw.h index
> 350ce59cc324..d86a8a6b0601 100644
> --- a/fs/exfat/exfat_raw.h
> +++ b/fs/exfat/exfat_raw.h
> @@ -16,7 +16,7 @@
>
> #define VOL_CLEAN0x
> #define VOL_DIRTY0x0002
> -#define ERR_MEDIUM 0x0004
> +#define MED_FAILURE 0x0004
>
> #define EXFAT_EOF_CLUSTER0xu
> #define EXFAT_BAD_CLUSTER0xFFF7u
> diff --git a/fs/exfat/super.c b/fs/exfat/super.c index
> b5bf6dedbe11..c26b0f5a0875 100644
> --- a/fs/exfat/super.c
> +++ b/fs/exfat/super.c
> @@ -96,17 +96,22 @@ static int exfat_statfs(struct dentry *dentry, struct
> kstatfs *buf)
> return 0;
> }
>
> -int exfat_set_vol_flags(struct super_block *sb, unsigned short new_flag)
> +int exfat_set_vol_flags(struct super_block *sb, unsigned short
> +new_flags)
> {
> struct exfat_sb_info *sbi = EXFAT_SB(sb);
> struct boot_sector *p_boot = (struct boot_sector *)sbi->boot_bh->b_data;
> bool sync;
If dirty bit is set in on-disk volume flags, we can just return 0 at the
beginning
of this function ?
>
> + if (new_flags == VOL_CLEAN)
> + new_flags = (sbi->vol_flags & ~VOL_DIRTY) |
> sbi->vol_flags_noclear;
> + else
> + new_flags |= sbi->vol_flags;
> +
> /* flags are not changed */
> - if (sbi->vol_flag == new_flag)
> + if (sbi->vol_flags == new_flags)
> return 0;
>
> - sbi->vol_flag = new_flag;
> + sbi->vol_flags = new_flags;
>
> /* skip updating volume dirty flag,
>* if this volume has been mounted with read-only @@ -114,9 +119,9 @@
> int
> exfat_set_vol_flags(struct super_block *sb, unsigned short new_flag)
> if (sb_rdonly(sb))
> return 0;
>
> - p_boot->vol_flags = cpu_to_le16(new_flag);
> + p_boot->vol_flags = cpu_to_le16(new_flags);
How about set or clear only dirty bit to on-disk volume flags instead of using
sbi->vol_flags_noclear ?
if (set)
p_boot->vol_flags |= cpu_to_le16(VOL_DIRTY);
else
p_boot->vol_flags &= cpu_to_le16(~VOL_DIRTY);
>
> - if (new_flag == VOL_DIRTY && !buffer_dirty(sbi->boot_bh))
> + if ((new_flags & VOL_DIRTY) && !buffer_dirty(sbi->boot_bh))
> sync = true;
> else
> sync = false;
> @@ -457,7 +462,8 @@ static int exfat_read_boot_sector(struct super_block *sb)
> sbi->dentries_per_clu = 1 <<
> (sbi->cluster_size_bits - DENTRY_SIZE_BITS);
>
> - sbi->vol_flag = le16_to_cpu(p_boot->vol_flags);
> + sbi->vol_flags = le16_to_cpu(p_boot->vol_flags);
> + sbi->vol_flags_noclear = sbi->vol_flags & (VOL_DIRTY | MED_FAILURE);
> sbi->clu_srch_ptr = EXFAT_FIRST_CLUSTER;
> sbi->used_clusters = EXFAT_CLUSTERS_UNTRACKED;
>
> @@ -472,9 +478,9 @@ static int
linux-next: manual merge of the kvms390 tree with the kvm tree
Hi all,
Today's linux-next merge of the kvms390 tree got a conflict in:
include/uapi/linux/kvm.h
between commit:
1aa561b1a4c0 ("kvm: x86: Add "last CPU" to some KVM_EXIT information")
from the kvm tree and commit:
23a60f834406 ("s390/kvm: diagnose 0x318 sync and reset")
from the kvms390 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 include/uapi/linux/kvm.h
index ff9b335620d0,35cdb4307904..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -1032,7 -1031,7 +1032,8 @@@ struct kvm_ppc_resize_hpt
#define KVM_CAP_PPC_SECURE_GUEST 181
#define KVM_CAP_HALT_POLL 182
#define KVM_CAP_ASYNC_PF_INT 183
-#define KVM_CAP_S390_DIAG318 184
+#define KVM_CAP_LAST_CPU 184
++#define KVM_CAP_S390_DIAG318 185
#ifdef KVM_CAP_IRQ_ROUTING
pgp7mIim8HTCX.pgp
Description: OpenPGP digital signature
[PATCH v2] arm64: dts: qcom: sc7180: Add missing properties for Wifi node
The wlan firmware memory is statically mapped in
the Trusted Firmware, hence the wlan driver does
not need to map/unmap this region dynamically.
Hence add the property to indicate the wlan driver
to not map/unamp the firmware memory region
dynamically.
Also add the chain1 voltage supply for wlan.
Signed-off-by: Rakesh Pillai
---
Changes from v1:
- Add the wifi mac alias
This patch is created on top of the change by
Douglas Anderson.
https://lkml.org/lkml/2020/6/25/817
Also the dt-bindings for the chain1 voltage supply
is added by the below patch series:
https://patchwork.kernel.org/project/linux-wireless/list/?series=309137
---
arch/arm64/boot/dts/qcom/sc7180-idp.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
index 472f7f4..c042d61 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
@@ -19,6 +19,7 @@
aliases {
bluetooth0 =
+ wifi0 =
hsuart0 =
serial0 =
};
@@ -391,10 +392,12 @@
{
status = "okay";
+ qcom,msa-fixed-perm;
vdd-0.8-cx-mx-supply = <_l9a_0p6>;
vdd-1.8-xo-supply = <_l1c_1p8>;
vdd-1.3-rfa-supply = <_l2c_1p3>;
vdd-3.3-ch0-supply = <_l10c_3p3>;
+ vdd-3.3-ch1-supply = <_l11c_3p3>;
wifi-firmware {
iommus = <_smmu 0xc2 0x1>;
};
--
2.7.4
Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
Excerpts from Andy Lutomirski's message of July 11, 2020 3:04 am:
> On Thu, Jul 9, 2020 at 6:57 PM Nicholas Piggin wrote:
>>
>> And get rid of the generic sync_core_before_usermode facility.
>>
>> This helper is the wrong way around I think. The idea that membarrier
>> state requires a core sync before returning to user is the easy one
>> that does not need hiding behind membarrier calls. The gap in core
>> synchronization due to x86's sysret/sysexit and lazy tlb mode, is the
>> tricky detail that is better put in x86 lazy tlb code.
>>
>> Consider if an arch did not synchronize core in switch_mm either, then
>> membarrier_mm_sync_core_before_usermode would be in the wrong place
>> but arch specific mmu context functions would still be the right place.
>> There is also a exit_lazy_tlb case that is not covered by this call, which
>> could be a bugs (kthread use mm the membarrier process's mm then context
>> switch back to the process without switching mm or lazy mm switch).
>>
>> This makes lazy tlb code a bit more modular.
>
> The mm-switching and TLB-management has often had the regrettable
> property that it gets wired up in a way that seems to work at the time
> but doesn't have clear semantics, and I'm a bit concerned that this
> patch is in that category.
It's much more explicit in the core code about where hooks are called
after this patch. And then the x86 membarrier implementation details
are contained to the x86 code where they belong, and we don't have the
previous hook with unclear semantics missing from core code.
> If I'm understanding right, you're trying
> to enforce the property that exiting lazy TLB mode will promise to
> sync the core eventually. But this has all kinds of odd properties:
>
> - Why is exit_lazy_tlb() getting called at all in the relevant cases?
It's a property of how MEMBARRIER_SYNC_CORE is implemented by arch/x86,
see the membarrier comment in finish_task_switch (for analogous reason).
> When is it permissible to call it?
Comment for the asm-generic code says it's to be called when the lazy
active mm becomes non-lazy.
> I look at your new code and see:
>
>> +/*
>> + * Ensure that a core serializing instruction is issued before returning
>> + * to user-mode, if a SYNC_CORE was requested. x86 implements return to
>> + * user-space through sysexit, sysrel, and sysretq, which are not core
>> + * serializing.
>> + *
>> + * See the membarrier comment in finish_task_switch as to why this is done
>> + * in exit_lazy_tlb.
>> + */
>> +#define exit_lazy_tlb exit_lazy_tlb
>> +static inline void exit_lazy_tlb(struct mm_struct *mm, struct task_struct
>> *tsk)
>> +{
>> + /* Switching mm is serializing with write_cr3 */
>> +if (tsk->mm != mm)
>> +return;
>
> And my brain says WTF? Surely you meant something like if
> (WARN_ON_ONCE(tsk->mm != mm)) { /* egads, what even happened? how do
> we try to recover well enough to get a crashed logged at least? */ }
No, the active mm can be unlazied by switching to a different mm.
> So this needs actual documentation, preferably in comments near the
> function, of what the preconditions are and what this mm parameter is.
> Once that's done, then we could consider whether it's appropriate to
> have this function promise to sync the core under some conditions.
It's documented in generic code. I prefer not to duplicate comments
too much but I can add a "refer to asm-generic version for usage" or
something if you'd like?
> - This whole structure seems to rely on the idea that switching mm
> syncs something.
Which whole structure? The x86 implementation of sync core explicitly
does rely on that, yes. But I've pulled that out of core code with
this patch.
> I periodically ask chip vendor for non-serializing
> mm switches. Specifically, in my dream world, we have totally
> separate user and kernel page tables. Changing out the user tables
> doesn't serialize or even create a fence. Instead it creates the
> minimum required pipeline hazard such that user memory access and
> switches to usermode will make sure they access memory through the
> correct page tables. I haven't convinced a chip vendor yet, but there
> are quite a few hundreds of cycles to be saved here.
The fundmaental difficulty is that the kernel can still access user
mappings any time after the switch. We can probably handwave ways
around it by serializing lazily when encountering the next user
access and hoping that most of your mm switches result in a kernel
exit that serializes or some other unavoidable serialize so you can
avoid the mm switch one. In practice it sounds like a lot of trouble.
But anyway the sync core could presumably be adjusted or reasoned to
still be correct, depending on how it works.
> With this in
> mind, I see the fencing aspects of the TLB handling code as somewhat
> of an accident. I'm fine with documenting them and using them to
> optimize other paths, but I think it should be explicit. For example:
>
>
[PATCH 1/2] mfd: intel-m10-bmc: add Max10 BMC chip support for Intel FPGA PAC
This patch implements the basic functions of the BMC chip for some Intel
FPGA PCIe Acceleration Cards (PAC). The BMC is implemented using the
intel max10 CPLD.
This BMC chip is connected to FPGA by a SPI bus. To provide reliable
register access from FPGA, an Avalon Memory-Mapped (Avmm) transaction
protocol over the SPI bus is used between host and slave.
This driver implements the basic register access with the regmap framework.
The mfd cells array is empty now as a placeholder.
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Signed-off-by: Matthew Gerlach
Signed-off-by: Russ Weight
Signed-off-by: Tom Rix
---
.../ABI/testing/sysfs-driver-intel-m10-bmc | 15 +
drivers/mfd/Kconfig| 13 +
drivers/mfd/Makefile | 3 +
drivers/mfd/intel-m10-bmc-main.c | 176
drivers/mfd/intel-spi-avmm.c | 904 +
drivers/mfd/intel-spi-avmm.h | 35 +
include/linux/mfd/intel-m10-bmc.h | 57 ++
7 files changed, 1203 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
create mode 100644 drivers/mfd/intel-m10-bmc-main.c
create mode 100644 drivers/mfd/intel-spi-avmm.c
create mode 100644 drivers/mfd/intel-spi-avmm.h
create mode 100644 include/linux/mfd/intel-m10-bmc.h
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
new file mode 100644
index 000..54cf5bc
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
@@ -0,0 +1,15 @@
+What: /sys/bus/spi/devices/.../bmc_version
+Date: June 2020
+KernelVersion: 5.9
+Contact: Xu Yilun
+Description: Read only. Returns the hardware build version of Intel
+ MAX10 BMC chip.
+ Format: "0x%x".
+
+What: /sys/bus/spi/devices/.../bmcfw_version
+Date: June 2020
+KernelVersion: 5.9
+Contact: Xu Yilun
+Description: Read only. Returns the firmware version of Intel MAX10
+ BMC chip.
+ Format: "0x%x".
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d13bb0a..9c478d7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2130,5 +2130,18 @@ config SGI_MFD_IOC3
If you have an SGI Origin, Octane, or a PCI IOC3 card,
then say Y. Otherwise say N.
+config MFD_INTEL_M10_BMC
+ tristate "Intel MAX10 board management controller"
+ depends on SPI_MASTER
+ select REGMAP
+ select MFD_CORE
+ help
+ Support for the Intel MAX10 board management controller using the
+ SPI interface.
+
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 1c8d6be..fb15cde 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -265,3 +265,6 @@ obj-$(CONFIG_MFD_STMFX) += stmfx.o
obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o
obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
+
+intel-m10-bmc-objs:= intel-m10-bmc-main.o intel-spi-avmm.o
+obj-$(CONFIG_MFD_INTEL_M10_BMC) += intel-m10-bmc.o
diff --git a/drivers/mfd/intel-m10-bmc-main.c b/drivers/mfd/intel-m10-bmc-main.c
new file mode 100644
index 000..7fdf1f3
--- /dev/null
+++ b/drivers/mfd/intel-m10-bmc-main.c
@@ -0,0 +1,176 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Max10 Board Management Controller chip Driver
+ *
+ * Copyright (C) 2018-2020 Intel Corporation. All rights reserved.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "intel-spi-avmm.h"
+
+enum m10bmc_type {
+ M10_N3000,
+};
+
+static struct mfd_cell m10bmc_pacn3000_subdevs[] = {};
+
+static struct regmap_config intel_m10bmc_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = M10BMC_MEM_END,
+};
+
+static ssize_t bmc_version_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct intel_m10bmc *m10bmc = dev_get_drvdata(dev);
+ unsigned int val;
+ int ret;
+
+ ret = m10bmc_sys_read(m10bmc, M10BMC_BUILD_VER, );
+ if (ret)
+ return ret;
+
+ return sprintf(buf, "0x%x\n", val);
+}
+static DEVICE_ATTR_RO(bmc_version);
+
+static ssize_t bmcfw_version_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct intel_m10bmc *max10 = dev_get_drvdata(dev);
+ unsigned int val;
+ int ret;
+
+ ret = m10bmc_sys_read(max10, NIOS2_FW_VERSION, );
+ if (ret)
+ return ret;
+
+ return sprintf(buf, "0x%x\n", val);
+}
+static DEVICE_ATTR_RO(bmcfw_version);
+
+static struct attribute
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
arch/arm64/kvm/mmu.c
between commit:
c1a33aebe91d ("KVM: arm64: Use common KVM implementation of MMU memory
caches")
from the kvm tree and commit:
a0e50aa3f4a8 ("KVM: arm64: Factor out stage 2 page table data from struct
kvm")
from the kvm-arm 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/arm64/kvm/mmu.c
index 838aad520f1c,cd14c831d56f..
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@@ -124,11 -127,44 +127,12 @@@ static void stage2_dissolve_pud(struct
put_page(virt_to_page(pudp));
}
- static void clear_stage2_pgd_entry(struct kvm *kvm, pgd_t *pgd, phys_addr_t
addr)
-static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
-int min, int max)
-{
- void *page;
-
- BUG_ON(max > KVM_NR_MEM_OBJS);
- if (cache->nobjs >= min)
- return 0;
- while (cache->nobjs < max) {
- page = (void *)__get_free_page(GFP_PGTABLE_USER);
- if (!page)
- return -ENOMEM;
- cache->objects[cache->nobjs++] = page;
- }
- return 0;
-}
-
-static void mmu_free_memory_cache(struct kvm_mmu_memory_cache *mc)
-{
- while (mc->nobjs)
- free_page((unsigned long)mc->objects[--mc->nobjs]);
-}
-
-static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
-{
- void *p;
-
- BUG_ON(!mc || !mc->nobjs);
- p = mc->objects[--mc->nobjs];
- return p;
-}
-
+ static void clear_stage2_pgd_entry(struct kvm_s2_mmu *mmu, pgd_t *pgd,
phys_addr_t addr)
{
+ struct kvm *kvm = mmu->kvm;
p4d_t *p4d_table __maybe_unused = stage2_p4d_offset(kvm, pgd, 0UL);
stage2_pgd_clear(kvm, pgd);
- kvm_tlb_flush_vmid_ipa(kvm, addr);
+ kvm_tlb_flush_vmid_ipa(mmu, addr, S2_NO_LEVEL_HINT);
stage2_p4d_free(kvm, p4d_table);
put_page(virt_to_page(pgd));
}
pgpAbFCqgwYcD.pgp
Description: OpenPGP digital signature
[PATCH 2/2] mfd: intel-m10-bmc: start with the last SOP on phy rx buffer parsing
From: Matthew Gerlach
This patch works around a bug in the SPI Slave to Avalon Master bridge.
The SPI slave will send an unexpected extra SOP in the following case.
One in approximately one million read requests results in an apparant
stall on the avalon bus where the SPI slave inserts IDLE characters. When
the stall is over, the slave sends an extra SOP character instead of the
0x7c indicating channel. The other characters are correct.
To eliminate the impact of the bug, this patch changes to look for the
last SOP as the start point of the valid phy rx data.
Signed-off-by: Matthew Gerlach
Signed-off-by: Xu Yilun
Signed-off-by: Luis Claudio R. Goncalves
Signed-off-by: Tom Rix
---
drivers/mfd/intel-spi-avmm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/intel-spi-avmm.c b/drivers/mfd/intel-spi-avmm.c
index 2604657..e4443b7 100644
--- a/drivers/mfd/intel-spi-avmm.c
+++ b/drivers/mfd/intel-spi-avmm.c
@@ -431,14 +431,14 @@ static int pkt_phy_rx_parse(struct device *dev,
{
char *b, *p;
- b = phy_buf;
p = trans_buf;
- /* Find the SOP */
- while (b < phy_buf + phy_len && *b != PKT_SOP)
- b++;
+ /* Find the last SOP */
+ b = (phy_buf + phy_len) - 1;
+ while (b >= phy_buf && *b != PKT_SOP)
+ b--;
- if (b >= phy_buf + phy_len) {
+ if (b < phy_buf) {
dev_err(dev, "%s no SOP\n", __func__);
return -EINVAL;
}
--
2.7.4
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got conflicts in:
arch/arm64/include/asm/kvm_coproc.h
arch/arm64/kvm/handle_exit.c
between commit:
74cc7e0c35c1 ("KVM: arm64: clean up redundant 'kvm_run' parameters")
from the kvm tree and commits:
6b33e0d64f85 ("KVM: arm64: Drop the target_table[] indirection")
750ed5669380 ("KVM: arm64: Remove the target table")
3a949f4c9354 ("KVM: arm64: Rename HSR to ESR")
from the kvm-arm 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/arm64/include/asm/kvm_coproc.h
index 454373704b8a,147f3a77e6a5..
--- a/arch/arm64/include/asm/kvm_coproc.h
+++ b/arch/arm64/include/asm/kvm_coproc.h
@@@ -19,20 -19,12 +19,12 @@@ struct kvm_sys_reg_table
size_t num;
};
- struct kvm_sys_reg_target_table {
- struct kvm_sys_reg_table table64;
- struct kvm_sys_reg_table table32;
- };
-
- void kvm_register_target_sys_reg_table(unsigned int target,
- struct kvm_sys_reg_target_table *table);
-
-int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_cp14_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu);
+int kvm_handle_cp14_32(struct kvm_vcpu *vcpu);
+int kvm_handle_cp14_64(struct kvm_vcpu *vcpu);
+int kvm_handle_cp15_32(struct kvm_vcpu *vcpu);
+int kvm_handle_cp15_64(struct kvm_vcpu *vcpu);
+int kvm_handle_sys_reg(struct kvm_vcpu *vcpu);
#define kvm_coproc_table_init kvm_sys_reg_table_init
void kvm_sys_reg_table_init(void);
diff --cc arch/arm64/kvm/handle_exit.c
index 1df3beafd73f,98ab33139982..
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@@ -87,9 -87,9 +87,9 @@@ static int handle_no_fpsimd(struct kvm_
* world-switches and schedule other host processes until there is an
* incoming IRQ or FIQ to the VM.
*/
-static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static int kvm_handle_wfx(struct kvm_vcpu *vcpu)
{
- if (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
+ if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
vcpu->stat.wfe_exit_stat++;
kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
@@@ -114,12 -115,11 +114,12 @@@
* guest and host are using the same debug facilities it will be up to
* userspace to re-inject the correct exception for guest delivery.
*
- * @return: 0 (while setting run->exit_reason), -1 for error
+ * @return: 0 (while setting vcpu->run->exit_reason), -1 for error
*/
-static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu)
{
+ struct kvm_run *run = vcpu->run;
- u32 hsr = kvm_vcpu_get_hsr(vcpu);
+ u32 esr = kvm_vcpu_get_esr(vcpu);
int ret = 0;
run->exit_reason = KVM_EXIT_DEBUG;
@@@ -144,12 -144,12 +144,12 @@@
return ret;
}
-static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu)
{
- u32 hsr = kvm_vcpu_get_hsr(vcpu);
+ u32 esr = kvm_vcpu_get_esr(vcpu);
- kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
- hsr, esr_get_class_string(hsr));
+ kvm_pr_unimpl("Unknown exception class: esr: %#08x -- %s\n",
+ esr, esr_get_class_string(esr));
kvm_inject_undefined(vcpu);
return 1;
@@@ -237,12 -237,11 +237,12 @@@ static int handle_trap_exceptions(struc
* Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
* proper exit to userspace.
*/
-int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
- int exception_index)
+int handle_exit(struct kvm_vcpu *vcpu, int exception_index)
{
+ struct kvm_run *run = vcpu->run;
+
if (ARM_SERROR_PENDING(exception_index)) {
- u8 hsr_ec = ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
+ u8 esr_ec = ESR_ELx_EC(kvm_vcpu_get_esr(vcpu));
/*
* HVC/SMC already have an adjusted PC, which we need
pgpb4EpwgtROB.pgp
Description: OpenPGP digital signature
[PATCH 0/2] add Intel Max10 BMC chip support
This patchset add basic functions for Intel Max10 BMC chip. Patch #1 implements the main feature. Patch #2 is a fix for the HW issue lies in the "SPI Slave to Avalon Master bridge" IP block, which is used for communication between host and the BMC chip. Matthew Gerlach (1): mfd: intel-m10-bmc: start with the last SOP on phy rx buffer parsing Xu Yilun (1): mfd: intel-m10-bmc: add Max10 BMC chip support for Intel FPGA PAC .../ABI/testing/sysfs-driver-intel-m10-bmc | 15 + drivers/mfd/Kconfig| 13 + drivers/mfd/Makefile | 3 + drivers/mfd/intel-m10-bmc-main.c | 176 drivers/mfd/intel-spi-avmm.c | 904 + drivers/mfd/intel-spi-avmm.h | 35 + include/linux/mfd/intel-m10-bmc.h | 57 ++ 7 files changed, 1203 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-m10-bmc create mode 100644 drivers/mfd/intel-m10-bmc-main.c create mode 100644 drivers/mfd/intel-spi-avmm.c create mode 100644 drivers/mfd/intel-spi-avmm.h create mode 100644 include/linux/mfd/intel-m10-bmc.h -- 2.7.4
[PATCH] checkpatch: Fix the usage of capture group ( ... )
The usage of "capture group (...)" in the immediate condition after `&&`
results in `$1` being uninitialized. This issues a warning "Use of
uninitialized value $1 in regexp compilation at ./scripts/checkpatch.pl
line 2638".
I noticed this bug while running checkpatch on the set of commits from
v5.7 to v5.8-rc1 of the kernel on the commits with a diff content in
their commit message.
This bug was introduced in the script by commit e518e9a59ec3
("checkpatch: emit an error when there's a diff in a changelog"). It has
been in the script since then.
The author intended to store the match made by capture group in variable
`$1`. This should have contained the name of the file as `[\w/]+` matched.
However, this couldn't be accomplished due to usage of capture group and
`$1` in the same regular expression.
Fix this by placing the capture group in the condition before `&&`.
Thus, `$1` can be initialized to the text that capture group matches
thereby setting it to the desired and required value.
Signed-off-by: Mrinal Pandey
---
scripts/checkpatch.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4c820607540b..e73e998d582a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2636,8 +2636,8 @@ sub process {
# Check if the commit log has what seems like a diff which can confuse patch
if ($in_commit_log && !$commit_log_has_diff &&
- (($line =~ m@^\s+diff\b.*a/[\w/]+@ &&
- $line =~ m@^\s+diff\b.*a/([\w/]+)\s+b/$1\b@) ||
+ (($line =~ m@^\s+diff\b.*a/([\w/]+)@ &&
+ $line =~ m@^\s+diff\b.*a/[\w/]+\s+b/$1\b@) ||
$line =~ m@^\s*(?:\-\-\-\s+a/|\+\+\+\s+b/)@ ||
$line =~ m/^\s*\@\@ \-\d+,\d+ \+\d+,\d+ \@\@/)) {
ERROR("DIFF_IN_COMMIT_MSG",
--
2.25.1
signature.asc
Description: PGP signature
Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
Hi Mauro, On 09-07-20, 13:11, Mauro Carvalho Chehab wrote: > Em Mon, 06 Jul 2020 06:30:01 -0700 > Joe Perches escreveu: > > > > $ git grep -i -w -P '\w*slave\w*' drivers | \ > > cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n > > 1 5683 drivers/net > > 2 2118 drivers/gpu > > 3 1807 drivers/dma > > 4 1389 drivers/i2c > > 5 866 drivers/interconnect > > 6 835 drivers/soundwire > > 7 821 drivers/spi > > 8 698 drivers/w1 > > 9 508 drivers/media > > 10 481 drivers/infiniband > > 11 440 drivers/ata > > 12 317 drivers/scsi > > 13 267 drivers/fsi > > 14 240 drivers/tty > > 15 225 drivers/vme > > 16 223 drivers/staging > > 17 157 drivers/mmc > > 18 155 drivers/usb > > 19 141 drivers/video > > 20 140 drivers/char > > It sounds that, as soon after this patch gets merged, the mailing lists > will be flooded by lots of patches replacing such terms with something > else :-( > > Doing a quick look at the media subsystem, it sounds that most terms > come from I2C master/slave and DiSEqC terminology, as defined by their > specs (and the others seem to be derived from some hardware vendor > specific terminology). > > As they're all supported by the current specs, if one would want > to replace them, it should first ensure that the supporting specs > should be using a different terminology, as otherwise replacing > them would just make harder for anyone trying to understand the > code. I think waiting for specs may result in long delays, we all know how 'fast' spec bodies work! Putting my soundwire maintainer hat, I see more than 1K uses of 'slave' in the subsystem due to MIPI defined terms of SoundWire Master/Slave, so I am planning to replace that and not wait for MIPI to update the spec. A similar approach where we discuss with relevant stakeholder and arrive at replacement terms and swap them would be great Thanks -- ~Vinod
Re: [Ksummit-discuss] [PATCH v3] CodingStyle: Inclusive Terminology
Hi Dan,
On 08-07-20, 11:14, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
> http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.st...@dwillia2-desk3.amr.corp.intel.com
> Acked-by: Randy Dunlap
> Acked-by: Dave Airlie
> Acked-by: SeongJae Park
> Acked-by: Christian Brauner
> Acked-by: James Bottomley
> Reviewed-by: Mark Brown
> Signed-off-by: Theodore Ts'o
> Signed-off-by: Shuah Khan
> Signed-off-by: Dan Carpenter
> Signed-off-by: Kees Cook
> Signed-off-by: Olof Johansson
> Signed-off-by: Jonathan Corbet
> Signed-off-by: Chris Mason
> Signed-off-by: Greg Kroah-Hartman
> Signed-off-by: Dan Williams
Acked-By: Vinod Koul
Thanks for working on this
> ---
> Changes since v2 [1]:
> - Pick up missed sign-offs and acks from Jon, Shuah, and Christian
> (sorry about missing those earlier).
>
> - Reformat the replacement list to make it easier to read.
>
> - Add 'controller' as a suggested replacement (Kees and Mark)
>
> - Fix up the paired term for 'performer' to be 'director' (Kees)
>
> - Collect some new acks, reviewed-by's, and sign-offs for v2.
>
> - Fix up Chris's email
>
> [1]:
> http://lore.kernel.org/r/159419296487.2464622.863943877093636532.st...@dwillia2-desk3.amr.corp.intel.com
>
>
> Documentation/process/coding-style.rst | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/process/coding-style.rst
> b/Documentation/process/coding-style.rst
> index 2657a55c6f12..1bee6f8affdb 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -319,6 +319,26 @@ If you are afraid to mix up your local variable names,
> you have another
> problem, which is called the function-growth-hormone-imbalance syndrome.
> See chapter 6 (Functions).
>
> +For symbol names and documentation, avoid introducing new usage of
> +'master / slave' (or 'slave' independent of 'master') and 'blacklist /
> +whitelist'.
> +
> +Recommended replacements for 'master / slave' are:
> +'{primary,main} / {secondary,replica,subordinate}'
> +'{initiator,requester} / {target,responder}'
> +'{controller,host} / {device,worker,proxy}'
> +'leader / follower'
> +'director / performer'
> +
> +Recommended replacements for 'blacklist/whitelist' are:
> +'denylist / allowlist'
> +'blocklist / passlist'
> +
> +Exceptions for introducing new usage is to maintain a userspace ABI/API,
> +or when updating code for an existing (as of 2020) hardware or protocol
> +specification that mandates those terms. For new specifications
> +translate specification usage of the terminology to the kernel coding
> +standard where possible.
>
> 5) Typedefs
> ---
>
> ___
> Ksummit-discuss mailing list
> ksummit-disc...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
--
~Vinod
Re: mmotm 2020-07-09-21-00 uploaded (drivers/net/ethernet/mellanox/mlx5/core/en_main.c)
On 7/12/20 9:02 PM, Stephen Rothwell wrote:
> Hi Randy,
>
> On Fri, 10 Jul 2020 10:40:29 -0700 Randy Dunlap wrote:
>>
>> on i386:
>>
>> In file included from
>> ../drivers/net/ethernet/mellanox/mlx5/core/en_main.c:49:0:
>> ../drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h: In function
>> ‘mlx5e_accel_sk_get_rxq’:
>> ../drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h:153:12:
>> error: implicit declaration of function ‘sk_rx_queue_get’; did you mean
>> ‘sk_rx_queue_set’? [-Werror=implicit-function-declaration]
>> int rxq = sk_rx_queue_get(sk);
>> ^~~
>> sk_rx_queue_set
>
> Caused by commit
>
> 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support")
>
> from the net-next tree. Presumably CONFIG_XPS is not set.
Yes, that's correct.
--
~Randy
Re: [PATCH 2/2] locking/pvqspinlock: Optionally store lock holder cpu into lock
Excerpts from Waiman Long's message of July 13, 2020 9:05 am: > On 7/12/20 1:34 PM, Peter Zijlstra wrote: >> On Sat, Jul 11, 2020 at 02:21:28PM -0400, Waiman Long wrote: >>> The previous patch enables native qspinlock to store lock holder cpu >>> number into the lock word when the lock is acquired via the slowpath. >>> Since PV qspinlock uses atomic unlock, allowing the fastpath and >>> slowpath to put different values into the lock word will further slow >>> down the performance. This is certainly undesirable. >>> >>> The only way we can do that without too much performance impact is to >>> make fastpath and slowpath put in the same value. Still there is a slight >>> performance overhead in the additional access to a percpu variable in the >>> fastpath as well as the less optimized x86-64 PV qspinlock unlock path. >>> >>> A new config option QUEUED_SPINLOCKS_CPUINFO is now added to enable >>> distros to decide if they want to enable lock holder cpu information in >>> the lock itself for both native and PV qspinlocks across both fastpath >>> and slowpath. If this option is not configureed, only native qspinlocks >>> in the slowpath will put the lock holder cpu information in the lock >>> word. >> And this kills it,.. if it doesn't make unconditional sense, we're not >> going to do this. It's just too ugly. >> > You mean it has to be unconditional, no option config if we want to do > it. Right? > > It can certainly be made unconditional after I figure out how to make > the optimized PV unlock code work. Sorry I've not had a lot of time to get back to this thread and test things -- don't spend loads of effort or complexity on it until we get some more numbers. I did see some worse throughput results (with no attention to fairness) with the PV spin lock, but it was a really quick limited few tests, I need to get something a bit more substantial. I do very much appreciate your help with the powerpc patches, and interest in the PV issues though. I'll try to find more time to help out. Thanks, Nick
Re: [PATCH] arm64: defconfig: enable RTC and audio support on Kontron sl28 boards
On Sat, Jul 04, 2020 at 12:11:43AM +0200, Michael Walle wrote: > Although the Kontron SMARC-sAL28 board is now supported, there is still > missing driver support for the hardware clock, audio interface and audio > codec. Let's enable them as modules (where possible). > > Signed-off-by: Michael Walle Applied, thanks.
Re: [PATCH net-next v1 5/5] net: phy: micrel: ksz886x/ksz8081: add cabletest support
On Sat, Jul 11, 2020 at 08:29:12PM +0200, Andrew Lunn wrote: > On Fri, Jul 10, 2020 at 02:08:51PM +0200, Oleksij Rempel wrote: > > This patch support for cable test for the ksz886x switches and the > > ksz8081 PHY. > > > > The patch was tested on a KSZ8873RLL switch with following results: > > > > - port 1: > > - cannot detect any distance > > - provides inverted values > > (Errata: DS8830A: "LinkMD does not work on Port 1", > > > > http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8873-Errata-DS8830A.pdf) > > - Reports "short" on open or ok. > > - Reports "ok" on short. > > > > - port 2: > > - can detect distance > > - can detect open on each wire of pair A (wire 1 and 2) > > - can detect open only on one wire of pair B (only wire 3) > > - can detect short between wires of a pair (wires 1 + 2 or 3 + 6) > > - short between pairs is detected as open. > > For example short between wires 2 + 3 is detected as open. > > > > In order to work around the errata for port 1, the ksz8795 switch driver > > should be extended to provide proper device tree support for the related > > PHY nodes. So we can set a DT property to mark the port 1 as affected by > > the errata. Hi Andrew, > Hi Oleksij > > Do the PHY register read/writes pass through the DSA driver for the > 8873? I was wondering if the switch could intercept reads/writes on > port1 for KSZ8081_LMD and return EOPNOTSUPP? That would be a more > robust solution than DT properties, which are going to get forgotten. Yes, it was my first idea as well. But this switch allows direct MDIO access to the PHYs and this PHY driver could be used without DSA driver. Not sure if we should support both variants? Beside, the Port 1 need at least one more quirk. The pause souport is announced but is not working. Should we some how clear Puase bit in the PHY and tell PHY framework to not use it? What is the best way to do it? Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v2 4/4] arm64: configs: add pca9450 pmic driver
On Sat, Jul 04, 2020 at 12:19:38AM +0800, Robin Gong wrote: > Add pca9450 pmic driver. > > Signed-off-by: Robin Gong Updated subject prefix like 'arm64: defconfig: ...' and applied patch. Shawn
Re: [PATCH v2 3/4] arm64: dts: imx8mn-evk: add pca9450 for i.mx8mn-evk board
On Sat, Jul 04, 2020 at 12:19:37AM +0800, Robin Gong wrote: > Add pca9450 pmic driver for i.mx8mn-evk board. > > Signed-off-by: Robin Gong Applied, thanks.
Re: [PATCH] ARM: dts: imx6qp-sabreauto: enable sata
On Fri, Jul 10, 2020 at 04:30:47PM +0800, Richard Zhu wrote: > Enable SATA on iMX6QP SABREAUTO board. > > Signed-off-by: Richard Zhu > Reviewed-by: Fabio Estevam Applied both, thanks.
[PATCH v2 5/5] power: supply: core: supply battery soc with decimal form
From: Qiwu Huang
Broadcast battery soc with decimal form.
soc_decimal is the decimal part of battery soc.
soc_decimal_rate is update frequency of decimal
part of battery soc.
We want to report such as 0.01 to 99.99% to
user space to improve user experience
when do very quick charging.
Signed-off-by: Qiwu Huang
---
Documentation/ABI/testing/sysfs-class-power | 20
drivers/power/supply/power_supply_sysfs.c | 2 ++
include/linux/power_supply.h| 2 ++
3 files changed, 24 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power
b/Documentation/ABI/testing/sysfs-class-power
index f4234ba1684a..bcc8ccad8163 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -349,6 +349,26 @@ Description:
Access: Read
Valid values: Represented in microvolts
+What: /sys/class/power_supply//soc_decimal,
+Date: Jul 2020
+Contact: jiangf...@xiaomi.com
+Description:
+ Broadcast battery soc with decimal form.
+ soc_decimal is the start decimal part of battery soc.
+
+ Access: Read
+ Valid values: 0 - 100
+
+What: /sys/class/power_supply//soc_decimal_rate,
+Date: Jul 2020
+Contact: jiangf...@xiaomi.com
+Description:
+ Broadcast battery soc with decimal form.
+ soc_decimal_rate is the decimal part of battery soc update
freqency.
+
+ Access: Read
+ Valid values: 0 - 100
+
= USB Properties =
What: /sys/class/power_supply//current_avg
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index 81916b6b6ccf..a837addb4f21 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -210,6 +210,8 @@ static struct power_supply_attr power_supply_attrs[] = {
POWER_SUPPLY_ATTR(TX_ADAPTER),
POWER_SUPPLY_ATTR(SIGNAL_STRENGTH),
POWER_SUPPLY_ATTR(REVERSE_CHG_MODE),
+ POWER_SUPPLY_ATTR(SOC_DECIMAL),
+ POWER_SUPPLY_ATTR(SOC_DECIMAL_RATE),
};
static struct attribute *
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 319bf6456867..d1aa5497938e 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -171,6 +171,8 @@ enum power_supply_property {
POWER_SUPPLY_PROP_TX_ADAPTER,
POWER_SUPPLY_PROP_SIGNAL_STRENGTH,
POWER_SUPPLY_PROP_REVERSE_CHG_MODE,
+ POWER_SUPPLY_PROP_SOC_DECIMAL,
+ POWER_SUPPLY_PROP_SOC_DECIMAL_RATE,
};
enum power_supply_type {
--
2.27.0
[PATCH v2 3/5] power: supply: core: add wireless signal strength property
From: Qiwu Huang
reports wireless signal strength.
The value show degree of coupling between tx and rx.
Signed-off-by: Qiwu Huang
---
Documentation/ABI/testing/sysfs-class-power | 11 +++
drivers/power/supply/power_supply_sysfs.c | 1 +
include/linux/power_supply.h| 1 +
3 files changed, 13 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power
b/Documentation/ABI/testing/sysfs-class-power
index cd07d3f4e8b1..f10780be2732 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -729,3 +729,14 @@ Description:
Access: Read-Only
Valid values: Reported as integer
+
+What: /sys/class/power_supply//signal_strength
+Date: Jul 2020
+Contact: Fei Jiang
+Description:
+ Reports wireless signal strength.The value show degree of
coupling.
+ Unit is KHZ,the "value" means the working frequency of receiver
+ chip of wireless charging.
+
+ Access: Read-Only
+ Valid values: Reported as integer
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index f2458e21d02b..e420a453095e 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -208,6 +208,7 @@ static struct power_supply_attr power_supply_attrs[] = {
POWER_SUPPLY_ATTR(SERIAL_NUMBER),
POWER_SUPPLY_ATTR(QUICK_CHARGE_TYPE),
POWER_SUPPLY_ATTR(TX_ADAPTER),
+ POWER_SUPPLY_ATTR(SIGNAL_STRENGTH),
};
static struct attribute *
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 2de9a4c93723..397fb8e96b03 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -169,6 +169,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_SERIAL_NUMBER,
POWER_SUPPLY_PROP_QUICK_CHARGE_TYPE,
POWER_SUPPLY_PROP_TX_ADAPTER,
+ POWER_SUPPLY_PROP_SIGNAL_STRENGTH,
};
enum power_supply_type {
--
2.27.0
[PATCH v2 2/5] power: supply: core: add wireless charger adapter type property
From: Qiwu Huang
Reports what type of wireless adapter connection is
currently active forthe supply.
for example it can show if ADAPTER_PD capable source is attached.
Signed-off-by: Qiwu Huang
---
Documentation/ABI/testing/sysfs-class-power | 11 +++
drivers/power/supply/power_supply_sysfs.c | 1 +
include/linux/power_supply.h| 1 +
3 files changed, 13 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power
b/Documentation/ABI/testing/sysfs-class-power
index d3169d47e359..cd07d3f4e8b1 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -718,3 +718,14 @@ Contact: Fei Jiang
Access: Read-Only
Valid values: Reported as integer
+= Wireless Charger Properties =
+What: /sys/class/power_supply//tx_adapter
+Date: Jul 2020
+Contact: Fei Jiang
+Description:
+ Reports what type of wireless adapter connection is currently
active for
+ the supply, for example it can show if ADAPTER_PD capable source
+ is attached.
+
+ Access: Read-Only
+ Valid values: Reported as integer
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index 9554d7907373..f2458e21d02b 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -207,6 +207,7 @@ static struct power_supply_attr power_supply_attrs[] = {
POWER_SUPPLY_ATTR(MANUFACTURER),
POWER_SUPPLY_ATTR(SERIAL_NUMBER),
POWER_SUPPLY_ATTR(QUICK_CHARGE_TYPE),
+ POWER_SUPPLY_ATTR(TX_ADAPTER),
};
static struct attribute *
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 3fe7e9ef2f0f..2de9a4c93723 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -168,6 +168,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_MANUFACTURER,
POWER_SUPPLY_PROP_SERIAL_NUMBER,
POWER_SUPPLY_PROP_QUICK_CHARGE_TYPE,
+ POWER_SUPPLY_PROP_TX_ADAPTER,
};
enum power_supply_type {
--
2.27.0
Re: [PATCH v3 2/2] riscv: Enable per-task stack canaries
Hi Kees,
On Mon, Jul 13, 2020 at 10:40 AM Kees Cook wrote:
>
> On Fri, Jul 10, 2020 at 04:19:58PM +, guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > This enables the use of per-task stack canary values if GCC has
> > support for emitting the stack canary reference relative to the
> > value of tp, which holds the task struct pointer in the riscv
> > kernel.
> >
> > After compare arm64 and x86 implementations, seems arm64's is more
> > flexible and readable. The key point is how gcc get the offset of
> > stack_canary from gs/el0_sp.
> >
> > x86: Use a fix offset from gs, not flexible.
> >
> > struct fixed_percpu_data {
> > /*
> >* GCC hardcodes the stack canary as %gs:40. Since the
> >* irq_stack is the object at %gs:0, we reserve the bottom
> >* 48 bytes of the irq stack for the canary.
> >*/
> > chargs_base[40]; // :(
> > unsigned long stack_canary;
> > };
> >
> > arm64: Use -mstack-protector-guard-offset & guard-reg
> > gcc options:
> > -mstack-protector-guard=sysreg
> > -mstack-protector-guard-reg=sp_el0
> > -mstack-protector-guard-offset=xxx
> >
> > riscv: Use -mstack-protector-guard-offset & guard-reg
> > gcc options:
> > -mstack-protector-guard=tls
> > -mstack-protector-guard-reg=tp
> > -mstack-protector-guard-offset=xxx
> >
> > Here is riscv gcc's work [1].
> >
> > [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549583.html
> >
> > In the end, these codes are inserted by gcc before return:
> >
> > * 0xffe00020b396 <+120>: ld a5,1008(tp) # 0x3f0
> > * 0xffe00020b39a <+124>: xor a5,a5,a4
> > * 0xffe00020b39c <+126>: mv a0,s5
> > * 0xffe00020b39e <+128>: bneza5,0xffe00020b61c <_do_fork+766>
> >0xffe00020b3a2 <+132>: ld ra,136(sp)
> >0xffe00020b3a4 <+134>: ld s0,128(sp)
> >0xffe00020b3a6 <+136>: ld s1,120(sp)
> >0xffe00020b3a8 <+138>: ld s2,112(sp)
> >0xffe00020b3aa <+140>: ld s3,104(sp)
> >0xffe00020b3ac <+142>: ld s4,96(sp)
> >0xffe00020b3ae <+144>: ld s5,88(sp)
> >0xffe00020b3b0 <+146>: ld s6,80(sp)
> >0xffe00020b3b2 <+148>: ld s7,72(sp)
> >0xffe00020b3b4 <+150>: addisp,sp,144
> >0xffe00020b3b6 <+152>: ret
> >...
> > * 0xffe00020b61c <+766>: auipc ra,0x7f8
> > * 0xffe00020b620 <+770>: jalr-1764(ra) # 0xffe000a02f38
> > <__stack_chk_fail>
> >
> > Signed-off-by: Guo Ren
> > Signed-off-by: cooper
> > Cc: cooper
> > Cc: Kees Cook
> > ---
> > Change v2:
> > - Change to -mstack-protector-guard=tls for gcc final define
> > - Solve compile error by changing position of KBUILD_CFLAGS in
> >Makefile
> >
> > Signed-off-by: Guo Ren
> > ---
> > arch/riscv/Kconfig | 7 +++
> > arch/riscv/Makefile | 10 ++
> > arch/riscv/include/asm/stackprotector.h | 3 ++-
> > arch/riscv/kernel/asm-offsets.c | 3 +++
> > arch/riscv/kernel/process.c | 2 +-
> > 5 files changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 4b0e308..d98ce29 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -394,6 +394,13 @@ config CMDLINE_FORCE
> >
> > endchoice
> >
> > +config CC_HAVE_STACKPROTECTOR_TLS
> > + def_bool $(cc-option,-mstack-protector-guard=tls
> > -mstack-protector-guard-reg=tp -mstack-protector-guard-offset=0)
> > +
> > +config STACKPROTECTOR_PER_TASK
> > + def_bool y
> > + depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS
> > +
> > endmenu
> >
> > config BUILTIN_DTB
> > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > index fb6e37d..f5f8ee9 100644
> > --- a/arch/riscv/Makefile
> > +++ b/arch/riscv/Makefile
> > @@ -68,6 +68,16 @@ KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-relax)
> > # architectures. It's faster to have GCC emit only aligned accesses.
> > KBUILD_CFLAGS += $(call cc-option,-mstrict-align)
> >
> > +ifeq ($(CONFIG_STACKPROTECTOR_PER_TASK),y)
> > +prepare: stack_protector_prepare
> > +stack_protector_prepare: prepare0
> > + $(eval KBUILD_CFLAGS += -mstack-protector-guard=tls \
> > + -mstack-protector-guard-reg=tp\
> > + -mstack-protector-guard-offset=$(shell\
> > + awk '{if ($$2 == "TSK_STACK_CANARY") print $$3;}' \
> > + include/generated/asm-offsets.h))
> > +endif
> > +
> > # arch specific predefines for sparse
> > CHECKFLAGS += -D__riscv -D__riscv_xlen=$(BITS)
> >
> > diff --git a/arch/riscv/include/asm/stackprotector.h
> > b/arch/riscv/include/asm/stackprotector.h
> > index d95f7b2..a895e07 100644
> > --- a/arch/riscv/include/asm/stackprotector.h
> > +++ b/arch/riscv/include/asm/stackprotector.h
> > @@
[PATCH v2 1/5] power: supply: core: add quick charge type property
From: Qiwu Huang
Reports the kind of quick charge type based on
different adapter power. UI will show different
animation effect for different quick charge type.
Signed-off-by: Qiwu Huang
---
Documentation/ABI/testing/sysfs-class-power | 10 ++
drivers/power/supply/power_supply_sysfs.c | 1 +
include/linux/power_supply.h| 1 +
3 files changed, 12 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power
b/Documentation/ABI/testing/sysfs-class-power
index 216d61a22f1e..d3169d47e359 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -708,3 +708,13 @@ Description:
Access: Read
Valid values: 1-31
+
+What: /sys/class/power_supply//quick_charge_type
+Date: Jul 2020
+Contact: Fei Jiang
+ Description:
+ Reports the kind of quick charge type based on different
adapter power.
+
+ Access: Read-Only
+ Valid values: Reported as integer
+
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index bc79560229b5..9554d7907373 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -206,6 +206,7 @@ static struct power_supply_attr power_supply_attrs[] = {
POWER_SUPPLY_ATTR(MODEL_NAME),
POWER_SUPPLY_ATTR(MANUFACTURER),
POWER_SUPPLY_ATTR(SERIAL_NUMBER),
+ POWER_SUPPLY_ATTR(QUICK_CHARGE_TYPE),
};
static struct attribute *
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index ac1345a48ad0..3fe7e9ef2f0f 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -167,6 +167,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
POWER_SUPPLY_PROP_SERIAL_NUMBER,
+ POWER_SUPPLY_PROP_QUICK_CHARGE_TYPE,
};
enum power_supply_type {
--
2.27.0
[PATCH v2 4/5] power: supply: core: property to control reverse charge
From: Qiwu Huang
Interface to control wireless reverse charge.
Supply reverse charge function when enabled.
Signed-off-by: Qiwu Huang
---
Documentation/ABI/testing/sysfs-class-power | 12
drivers/power/supply/power_supply_sysfs.c | 1 +
include/linux/power_supply.h| 1 +
3 files changed, 14 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power
b/Documentation/ABI/testing/sysfs-class-power
index f10780be2732..f4234ba1684a 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -740,3 +740,15 @@ Description:
Access: Read-Only
Valid values: Reported as integer
+
+What: /sys/class/power_supply//reverse_chg_mode
+Date: Jul 2020
+Contact: Fei Jiang
+Description:
+ The property supply interface to control wireless
+ reverse charge mode.
+
+ Valid values:
+ - 1: enabled
+ - 0: disabled
+
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index e420a453095e..81916b6b6ccf 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -209,6 +209,7 @@ static struct power_supply_attr power_supply_attrs[] = {
POWER_SUPPLY_ATTR(QUICK_CHARGE_TYPE),
POWER_SUPPLY_ATTR(TX_ADAPTER),
POWER_SUPPLY_ATTR(SIGNAL_STRENGTH),
+ POWER_SUPPLY_ATTR(REVERSE_CHG_MODE),
};
static struct attribute *
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 397fb8e96b03..319bf6456867 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -170,6 +170,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_QUICK_CHARGE_TYPE,
POWER_SUPPLY_PROP_TX_ADAPTER,
POWER_SUPPLY_PROP_SIGNAL_STRENGTH,
+ POWER_SUPPLY_PROP_REVERSE_CHG_MODE,
};
enum power_supply_type {
--
2.27.0
[PATCH] arm64: Make TSK_STACK_CANARY more accurate defined
From: Guo Ren TSK_STACK_CANARY only used in arm64/Makefile with CONFIG_STACKPROTECTOR_PER_TASK wrap. So use the same policy in asm-offset.c. Signed-off-by: Guo Ren Co-developed-by: Kees Cook Cc: Catalin Marinas Cc: Will Deacon --- arch/arm64/kernel/asm-offsets.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index 0577e21..37d5d3d 100644 --- a/arch/arm64/kernel/asm-offsets.c +++ b/arch/arm64/kernel/asm-offsets.c @@ -39,7 +39,7 @@ int main(void) DEFINE(TSK_TI_SCS_SP,offsetof(struct task_struct, thread_info.scs_sp)); #endif DEFINE(TSK_STACK,offsetof(struct task_struct, stack)); -#ifdef CONFIG_STACKPROTECTOR +#ifdef CONFIG_STACKPROTECTOR_PER_TASK DEFINE(TSK_STACK_CANARY, offsetof(struct task_struct, stack_canary)); #endif BLANK(); -- 2.7.4
Re: mmotm 2020-07-09-21-00 uploaded (drivers/net/ethernet/mellanox/mlx5/core/en_main.c)
Hi Randy,
On Fri, 10 Jul 2020 10:40:29 -0700 Randy Dunlap wrote:
>
> on i386:
>
> In file included from
> ../drivers/net/ethernet/mellanox/mlx5/core/en_main.c:49:0:
> ../drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h: In function
> ‘mlx5e_accel_sk_get_rxq’:
> ../drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h:153:12: error:
> implicit declaration of function ‘sk_rx_queue_get’; did you mean
> ‘sk_rx_queue_set’? [-Werror=implicit-function-declaration]
> int rxq = sk_rx_queue_get(sk);
> ^~~
> sk_rx_queue_set
Caused by commit
1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support")
from the net-next tree. Presumably CONFIG_XPS is not set.
--
Cheers,
Stephen Rothwell
pgp6QeEakNSNs.pgp
Description: OpenPGP digital signature
Re: [PATCH] x86/entry: add compatibility with IAS
On Sun, Jul 12, 2020 at 10:54:29PM -0400, Arvind Sankar wrote: > On Sun, Jul 12, 2020 at 06:24:22PM -0700, Jian Cai wrote: > > Clang's integrated assembler does not allow symbols with non-absolute > > values to be reassigned. This patch allows the affected code to be > > compatible with IAS. > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1043 > > Reported-by: Nick Desaulniers > > Reported-by: Sedat Dilek > > Suggested-by: Nick Desaulniers > > Tested-by: Sedat Dilek > > Signed-off-by: Jian Cai > > --- > > arch/x86/include/asm/idtentry.h | 22 ++ > > 1 file changed, 10 insertions(+), 12 deletions(-) > > > > diff --git a/arch/x86/include/asm/idtentry.h > > b/arch/x86/include/asm/idtentry.h > > index f3d70830bf2a..77beed2cd6d9 100644 > > --- a/arch/x86/include/asm/idtentry.h > > +++ b/arch/x86/include/asm/idtentry.h > > @@ -468,34 +468,32 @@ __visible noinstr void func(struct pt_regs *regs, > > \ > > */ > > .align 8 > > SYM_CODE_START(irq_entries_start) > > -vector=FIRST_EXTERNAL_VECTOR > > -pos = . > > +i = 1 > > +pos1 = . > > .rept (FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR) > > UNWIND_HINT_IRET_REGS > > - .byte 0x6a, vector > > + .byte 0x6a, FIRST_EXTERNAL_VECTOR + i - 1 > > jmp asm_common_interrupt > > nop > > /* Ensure that the above is 8 bytes max */ > > - . = pos + 8 > > -pos=pos+8 > > -vector=vector+1 > > + . = pos1 + 8 * i > > + i = i + 1 > > .endr > > SYM_CODE_END(irq_entries_start) > > I think it would be a little cleaner to initialize i to 0, and drop pos. > i.e. couldn't we do > i = 0 > ... > .byte 0x6a, FIRST_EXTERNAL_VECTOR + i > ... > i = i + 1 > . = irq_entries_start + 8 * i > Or maybe just: diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h index eeac6dc2adaa..c774039d130b 100644 --- a/arch/x86/include/asm/idtentry.h +++ b/arch/x86/include/asm/idtentry.h @@ -469,15 +469,14 @@ __visible noinstr void func(struct pt_regs *regs, \ .align 8 SYM_CODE_START(irq_entries_start) vector=FIRST_EXTERNAL_VECTOR -pos = . .rept (FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR) +0: UNWIND_HINT_IRET_REGS .byte 0x6a, vector jmp asm_common_interrupt nop /* Ensure that the above is 8 bytes max */ - . = pos + 8 -pos=pos+8 + . = 0b + 8 vector=vector+1 .endr SYM_CODE_END(irq_entries_start) @@ -486,15 +485,14 @@ SYM_CODE_END(irq_entries_start) .align 8 SYM_CODE_START(spurious_entries_start) vector=FIRST_SYSTEM_VECTOR -pos = . .rept (NR_VECTORS - FIRST_SYSTEM_VECTOR) +0: UNWIND_HINT_IRET_REGS .byte 0x6a, vector jmp asm_spurious_interrupt nop /* Ensure that the above is 8 bytes max */ - . = pos + 8 -pos=pos+8 + . = 0b + 8 vector=vector+1 .endr SYM_CODE_END(spurious_entries_start)
Re: [PATCH v10 01/17] spi: spi-mem: allow specifying whether an op is DTR or not
On 6/23/20 9:30 PM, Pratyush Yadav wrote: > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c > index 9a86cc27fcc0..93e255287ab9 100644 > --- a/drivers/spi/spi-mem.c > +++ b/drivers/spi/spi-mem.c > @@ -156,6 +156,9 @@ bool spi_mem_default_supports_op(struct spi_mem *mem, >op->data.dir == SPI_MEM_DATA_OUT)) > return false; > > + if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr) > + return false; I would put this check the first thing in the function to exit sooner and avoid the rest of the checks, that would become superfluous. Anyway this is just a nit.
Re: [v2 PATCH] usb: gadget: bdc: use readl_poll_timeout() to simplify code
On 7/12/2020 8:30 PM, Chunfeng Yun wrote:
> Use readl_poll_timeout() to poll register status
>
> Cc: Florian Fainelli
> Signed-off-by: Chunfeng Yun
> ---
> v2 changes, suggested by Stephen:
> 1. use unsigned int instead of int for @usec parameter
> 2. add dev_log() back
> 3. drop "Err" in error log
> ---
> drivers/usb/gadget/udc/bdc/bdc_core.c | 26 +++---
> 1 file changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c
> b/drivers/usb/gadget/udc/bdc/bdc_core.c
> index 02a3a77..53dccb1 100644
> --- a/drivers/usb/gadget/udc/bdc/bdc_core.c
> +++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -29,24 +30,19 @@
> #include "bdc_dbg.h"
>
> /* Poll till controller status is not OIP */
> -static int poll_oip(struct bdc *bdc, int usec)
> +static int poll_oip(struct bdc *bdc, u32 usec)
> {
> u32 status;
> - /* Poll till STS!= OIP */
> - while (usec) {
> - status = bdc_readl(bdc->regs, BDC_BDCSC);
> - if (BDC_CSTS(status) != BDC_OIP) {
> - dev_dbg(bdc->dev,
> - "poll_oip complete status=%d",
> - BDC_CSTS(status));
> - return 0;
> - }
> - udelay(10);
> - usec -= 10;
> - }
> - dev_err(bdc->dev, "Err: operation timedout BDCSC: 0x%08x\n", status);
> + int ret;
>
> - return -ETIMEDOUT;
> + ret = readl_poll_timeout(bdc->regs + BDC_BDCSC, status,
> + (BDC_CSTS(status) != BDC_OIP), 10, usec);
You could probably indent this to the opening parenthesis, but with or
without it:
Reviewed-by: Florian Fainelli
and thanks for picking up the MAINTAINERS file update ;)
> + if (ret)
> + dev_err(bdc->dev, "operation timedout BDCSC: 0x%08x\n", status);
> + else
> + dev_dbg(bdc->dev, "%s complete status=%d", __func__,
> BDC_CSTS(status));
> +
> + return ret;
> }
>
> /* Stop the BDC controller */
>
--
Florian
Re: WARNING: at mm/mremap.c:211 move_page_tables in i386
On Sun, Jul 12, 2020 at 7:53 PM Joel Fernandes wrote: > > > But I do feel like you figured out why the bug happened, now we're > > just discussing whether the patch is the right thing to do. > > Yes. > > > Maybe saying "doing the pmd copies for the initial stack isn't > > important, so let's just note this as a special case and get rid of > > the WARN_ON()" might be an alternative solution. > > Personally, I feel it is better to keep the warning just so in the future we > can detect any bugs. I don't disagree, the warning didn't happen to find a bug now, but it did fine a case we might be able to do better. So now that I feel we understand the issue, and it's not a horrible problem, just a (very hard to trigger) warning, I don't think there's any huge hurry. I think think I will - for now - change the WARN_ON() to WARN_ON_ONCE() (so that it doesn't floow the logs if somebody triggers this odd special case this malisiously), and add a note about how this happens to the code for posterito. And if/when you figure out a better way to fix it, we can update the note. Ok? Linus
Re: [PATCH v4 1/2] dt-bindings: dma: Add bindings for intel LGM SOC
Hi Thomas, Thanks for the review. My comments inline. On 7/9/2020 3:54 PM, Langer, Thomas wrote: -Original Message- From: devicetree-ow...@vger.kernel.org On Behalf Of Amireddy Mallikarjuna reddy Sent: Donnerstag, 9. Juli 2020 08:01 To: dmaeng...@vger.kernel.org; vk...@kernel.org; devicet...@vger.kernel.org; robh...@kernel.org Cc: linux-kernel@vger.kernel.org; Shevchenko, Andriy ; chuanhua@linux.intel.com; Kim, Cheol Yong ; Wu, Qiming ; malliamireddy...@gmail.com; Amireddy Mallikarjuna reddy Subject: [PATCH v4 1/2] dt-bindings: dma: Add bindings for intel LGM SOC Add DT bindings YAML schema for DMA controller driver of Lightning Mountain(LGM) SoC. Signed-off-by: Amireddy Mallikarjuna reddy --- v1: - Initial version. v2: - Fix bot errors. v3: - No change. v4: - Address Thomas langer comments Please read my comments again and then respond about the topics you ignored. I added some hints below again. Thanks. --- .../devicetree/bindings/dma/intel,ldma.yaml| 416 + 1 file changed, 416 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/intel,ldma.yaml diff --git a/Documentation/devicetree/bindings/dma/intel,ldma.yaml b/Documentation/devicetree/bindings/dma/intel,ldma.yaml new file mode 100644 index ..7f666b9812e4 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/intel,ldma.yaml @@ -0,0 +1,416 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/intel,ldma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Lightning Mountain centralized low speed DMA and high speed DMA controllers. + +maintainers: + - chuanhua@intel.com + - mallikarjunax.re...@intel.com + +properties: + $nodename: + pattern: "^dma(@.*)?$" Please explain the difference to the common dma binding. No difference. we can use "^dma-controller(@.*)?$" as in the common binding. Its My bad. I missed the changes to include in this patch. Surely update in the upcoming patch. + + "#dma-cells": + const: 1 + + compatible: + anyOf: + - const: intel,lgm-cdma + - const: intel,lgm-dma2tx + - const: intel,lgm-dma1rx + - const: intel,lgm-dma1tx + - const: intel,lgm-dma0tx + - const: intel,lgm-dma3 + - const: intel,lgm-toe-dma30 + - const: intel,lgm-toe-dma31 Please explain why you need so many different compatible strings. This hw dma has 7 DMA instances. Some for datapath, some for memcpy and some for TOE. Some for TX only, some for RX only, and some for TX/RX(memcpy and ToE). dma TX/RX type we considered as driver specific data of each instance and used different compatible strings for each instance. And also idea is in future if any driver specific data of any particular instance we can handle. Here if dma name and type(tx or rx) will be accepted as devicetree attributes then we can move .name = "toe_dma31", & .type = DMA_TYPE_MCPY to devicetree. So that the compatible strings can be limited to two. intel,lgm-cdma & intel,lgm-hdma . please suggest us the better proposal. + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + interrupts: + maxItems: 1 + + intel,dma-poll-cnt: + $ref: /schemas/types.yaml#definitions/uint32 + description: + DMA descriptor polling counter. It may need fine tune according + to the system application scenario. + + intel,dma-byte-en: + type: boolean + description: + DMA byte enable is only valid for DMA write(RX). + Byte enable(1) means DMA write will be based on the number of dwords + instead of the whole burst. + + intel,dma-drb: +type: boolean +description: + DMA descriptor read back to make sure data and desc synchronization. + + intel,dma-burst: +$ref: /schemas/types.yaml#definitions/uint32 +description: + Specifiy the DMA burst size(in dwords), the valid value will be 8, 16, 32. + Default is 16 for data path dma, 32 is for memcopy DMA. + + intel,dma-polling-cnt: +$ref: /schemas/types.yaml#definitions/uint32 +description: + DMA descriptor polling counter. It may need fine tune according to + the system application scenario. + + intel,dma-desc-in-sram: +type: boolean +description: + DMA descritpors in SRAM or not. Some old controllers descriptors + can be in DRAM or SRAM. The new ones are all in SRAM. + + intel,dma-orrc: +$ref: /schemas/types.yaml#definitions/uint32 +description: + DMA outstanding read counter. The maximum value is 16, and it may + need fine tune according to the system application scenarios. + + intel,dma-dburst-wr: +type: boolean +description: + Enable RX dynamic burst write. It only applies to RX DMA and memcopy DMA. + + + dma-ports: +type: object +description: + This sub-node must contain a sub-node for each DMA port. +properties: + '#address-cells': +const: 1 + '#size-cells': +
Re: [PATCH] virtio_balloon: clear modern features under legacy
On 2020/7/10 下午7:31, Michael S. Tsirkin wrote:
Page reporting features were never supported by legacy hypervisors.
Supporting them poses a problem: should we use native endian-ness (like
current code assumes)? Or little endian-ness like the virtio spec says?
Rather than try to figure out, and since results of
incorrect endian-ness are dire, let's just block this configuration.
Cc: sta...@vger.kernel.org
Signed-off-by: Michael S. Tsirkin
---
drivers/virtio/virtio_balloon.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 5d4b891bf84f..b9bc03345157 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -1107,6 +1107,15 @@ static int virtballoon_restore(struct virtio_device
*vdev)
static int virtballoon_validate(struct virtio_device *vdev)
{
+ /*
+* Legacy devices never specified how modern features should behave.
+* E.g. which endian-ness to use? Better not to assume anything.
+*/
+ if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+ __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT);
+ __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
+ __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_REPORTING);
+ }
/*
* Inform the hypervisor that our pages are poisoned or
* initialized. If we cannot do that then we should disable
Acked-by: Jason Wang
Re: [PATCH] virtio_ring: sparse warning fixup
On 2020/7/10 下午6:49, Michael S. Tsirkin wrote:
virtio_store_mb was built with split ring in mind so it accepts
__virtio16 arguments. Packed ring uses __le16 values, so sparse
complains. It's just a store with some barriers so let's convert it to
a macro, we don't loose too much type safety by doing that.
Signed-off-by: Michael S. Tsirkin
---
include/linux/virtio_ring.h | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index 3dc70adfe5f5..b485b13fa50b 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -46,16 +46,15 @@ static inline void virtio_wmb(bool weak_barriers)
dma_wmb();
}
-static inline void virtio_store_mb(bool weak_barriers,
- __virtio16 *p, __virtio16 v)
-{
- if (weak_barriers) {
- virt_store_mb(*p, v);
- } else {
- WRITE_ONCE(*p, v);
- mb();
- }
-}
+#define virtio_store_mb(weak_barriers, p, v) \
+do { \
+ if (weak_barriers) { \
+ virt_store_mb(*p, v); \
+ } else { \
+ WRITE_ONCE(*p, v); \
+ mb(); \
+ } \
+} while (0) \
struct virtio_device;
struct virtqueue;
Acked-by: Jason Wang
[PATCH] fsi: fsi-occ: fix return value check in occ_probe()
In case of error, the function platform_device_register_full() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Xu Wang --- drivers/fsi/fsi-occ.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fsi/fsi-occ.c b/drivers/fsi/fsi-occ.c index 7da9c81759ac..9eeb856c8905 100644 --- a/drivers/fsi/fsi-occ.c +++ b/drivers/fsi/fsi-occ.c @@ -555,7 +555,7 @@ static int occ_probe(struct platform_device *pdev) hwmon_dev_info.id = occ->idx; hwmon_dev = platform_device_register_full(_dev_info); - if (!hwmon_dev) + if (IS_ERR(hwmon_dev)) dev_warn(dev, "failed to create hwmon device\n"); return 0; -- 2.17.1
[v2 PATCH] usb: gadget: bdc: use readl_poll_timeout() to simplify code
Use readl_poll_timeout() to poll register status
Cc: Florian Fainelli
Signed-off-by: Chunfeng Yun
---
v2 changes, suggested by Stephen:
1. use unsigned int instead of int for @usec parameter
2. add dev_log() back
3. drop "Err" in error log
---
drivers/usb/gadget/udc/bdc/bdc_core.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c
b/drivers/usb/gadget/udc/bdc/bdc_core.c
index 02a3a77..53dccb1 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_core.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,24 +30,19 @@
#include "bdc_dbg.h"
/* Poll till controller status is not OIP */
-static int poll_oip(struct bdc *bdc, int usec)
+static int poll_oip(struct bdc *bdc, u32 usec)
{
u32 status;
- /* Poll till STS!= OIP */
- while (usec) {
- status = bdc_readl(bdc->regs, BDC_BDCSC);
- if (BDC_CSTS(status) != BDC_OIP) {
- dev_dbg(bdc->dev,
- "poll_oip complete status=%d",
- BDC_CSTS(status));
- return 0;
- }
- udelay(10);
- usec -= 10;
- }
- dev_err(bdc->dev, "Err: operation timedout BDCSC: 0x%08x\n", status);
+ int ret;
- return -ETIMEDOUT;
+ ret = readl_poll_timeout(bdc->regs + BDC_BDCSC, status,
+ (BDC_CSTS(status) != BDC_OIP), 10, usec);
+ if (ret)
+ dev_err(bdc->dev, "operation timedout BDCSC: 0x%08x\n", status);
+ else
+ dev_dbg(bdc->dev, "%s complete status=%d", __func__,
BDC_CSTS(status));
+
+ return ret;
}
/* Stop the BDC controller */
--
1.9.1
Re: [PATCH] vhost/scsi: fix up req type endian-ness
On 2020/7/10 下午6:48, Michael S. Tsirkin wrote:
vhost/scsi doesn't handle type conversion correctly
for request type when using virtio 1.0 and up for BE,
or cross-endian platforms.
Fix it up using vhost_32_to_cpu.
Cc: sta...@vger.kernel.org
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 6fb4d7ecfa19..b22adf03f584 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1215,7 +1215,7 @@ vhost_scsi_ctl_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
continue;
}
- switch (v_req.type) {
+ switch (vhost32_to_cpu(vq, v_req.type)) {
case VIRTIO_SCSI_T_TMF:
vc.req = _req.tmf;
vc.req_size = sizeof(struct virtio_scsi_ctrl_tmf_req);
Acked-by: Jason Wang
Re: [PATCH] ubifs: Fix a potential space leak problem while linking tmpfile
在 2020/7/11 14:37, Zhihao Cheng 写道:
在 2020/7/7 20:47, Richard Weinberger 写道:
- Ursprüngliche Mail -
Perhaps I misunderstood what commit 32fe905c17f001 ("ubifs: Fix
O_TMPFILE corner case in ubifs_link()") wanted to fix.
I think orphan area is used to remind filesystem don't forget to
delete
inodes (whose nlink is 0) in next unclean rebooting. Generally,
the file
system is not corrupted caused by replaying orphan nodes.
Ralph reported a filesystem corruption in combination with overlayfs.
Can you tell me the details about that problem? Thanks.
On my test bed I didn't see a fs corruption, what I saw was a
failing orphan
self test while playing with O_TMPFILE and linkat().
Do we have a reproducer, or can I get the fail testcase? Is it a
xfstest
case?
I think xfstests triggered it, yes.
Later today I can check. :)
Thanks,
//richard
.
I think I have found the testcases, overlay/006 and overlay/041.
The 'mv' and 'rm' operations will put lowertestfile into orphan list
twice, so we must reseve the orphan deletion operation in
ubifs_link(), otherwise the testcase fails and we will see the
following msg:
Sorry, not lowertestfile, it's tempfile which is generated by ovl
copy-up (mv operation). The tempfile is linked after copy-up finished.
The tempfile is then unlinked by 'rm' operation.
overlay/006 2s ... - output mismatch (see
/root/git/xfstests-dev/results//overlay/006.out.bad)
--- tests/overlay/006.out 2020-07-07 21:42:57.73700 +0800
+++ /root/git/xfstests-dev/results//overlay/006.out.bad 2020-07-11
14:31:55.34000 +0800
@@ -1,2 +1,4 @@
QA output created by 006
Silence is golden
+rm: cannot remove
'/tmp/scratch/ovl-mnt/uppertestdir/lowertestfile': Invalid argument
+lowertestfile
...
[ 382.258210] UBIFS error (ubi0:1 pid 11896): orphan_add [ubifs]:
orphaned twice
[ 382.352535] UBIFS error (ubi0:1 pid 11930): free_orphans [ubifs]:
orphan list not empty at unmount
So, how about moving ubifs_delete_orphan() after ubifs_jnl_update() in
function ubifs_link(). Following modifications applied in linux-5.8
has been tested by overlay/041, overlay/006 and other tmpfile cases
(generic/531, generic/530, generic/509, generic/389, generic/004).
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index ef85ec167a84..fd4443a5e8c6 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -722,11 +722,6 @@ static int ubifs_link(struct dentry *old_dentry,
struct inode *dir,
goto out_fname;
lock_2_inodes(dir, inode);
-
- /* Handle O_TMPFILE corner case, it is allowed to link a
O_TMPFILE. */
- if (inode->i_nlink == 0)
- ubifs_delete_orphan(c, inode->i_ino);
-
inc_nlink(inode);
ihold(inode);
inode->i_ctime = current_time(inode);
@@ -736,6 +731,11 @@ static int ubifs_link(struct dentry *old_dentry,
struct inode *dir,
err = ubifs_jnl_update(c, dir, , inode, 0, 0);
if (err)
goto out_cancel;
+
+ /* Handle O_TMPFILE corner case, it is allowed to link a
O_TMPFILE. */
+ if (inode->i_nlink == 1)
+ ubifs_delete_orphan(c, inode->i_ino);
+
unlock_2_inodes(dir, inode);
ubifs_release_budget(c, );
@@ -747,8 +747,6 @@ static int ubifs_link(struct dentry *old_dentry,
struct inode *dir,
dir->i_size -= sz_change;
dir_ui->ui_size = dir->i_size;
drop_nlink(inode);
- if (inode->i_nlink == 0)
- ubifs_add_orphan(c, inode->i_ino);
unlock_2_inodes(dir, inode);
ubifs_release_budget(c, );
iput(inode);
--
__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Re: [PATCH] virtio_balloon: fix sparse warning
On 2020/7/10 下午6:48, Michael S. Tsirkin wrote: balloon uses virtio32_to_cpu instead of cpu_to_virtio32 to convert a native endian number to virtio. No practical difference but makes sparse warn. Fix it up. Signed-off-by: Michael S. Tsirkin --- drivers/virtio/virtio_balloon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index fc7301406540..5d4b891bf84f 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -596,7 +596,7 @@ static int send_cmd_id_start(struct virtio_balloon *vb) while (virtqueue_get_buf(vq, )) ; - vb->cmd_id_active = virtio32_to_cpu(vb->vdev, + vb->cmd_id_active = cpu_to_virtio32(vb->vdev, virtio_balloon_cmd_id_received(vb)); sg_init_one(, >cmd_id_active, sizeof(vb->cmd_id_active)); err = virtqueue_add_outbuf(vq, , 1, >cmd_id_active, GFP_KERNEL); Acked-by: Jason Wang
Re: [PATCH 1/2] ARM: imx: Remove imx_add_imx_dma() unused irq_err argument
On Wed, Jul 01, 2020 at 05:10:39PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> No callers of imx_add_imx_dma() need an error IRQ, so they supply 0 as
> "irq_err", which means we register a resource of IRQ 0, which is invalid
> and causes a warning if used.
>
> Remove the "irq_err" argument altogether so there's no chance of trying to
> use the invalid IRQ 0.
>
> Fixes: a85a6c86c25be ("driver core: platform: Clarify that IRQ 0 is invalid")
> Signed-off-by: Bjorn Helgaas
> Cc: Russell King
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: ker...@pengutronix.de
> Cc: Fabio Estevam
> Cc: linux-...@nxp.com
> Cc: linux-arm-ker...@lists.infradead.org
Applied, thanks.
Re: [PATCH 2/2] cpufreq: tegra186: Simplify probe return path
On 12-07-20, 11:06, Jon Hunter wrote: > We always put the reference to BPMP device on exit of the Tegra186 > CPUFREQ driver and so there is no need to have separate exit paths > for success and failure. Therefore, simplify the probe return path > in the Tegra186 CPUFREQ driver by combining the success and failure > paths. > > Signed-off-by: Jon Hunter > --- > drivers/cpufreq/tegra186-cpufreq.c | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/drivers/cpufreq/tegra186-cpufreq.c > b/drivers/cpufreq/tegra186-cpufreq.c > index c44190ce3f03..bf8cab357277 100644 > --- a/drivers/cpufreq/tegra186-cpufreq.c > +++ b/drivers/cpufreq/tegra186-cpufreq.c > @@ -231,15 +231,9 @@ static int tegra186_cpufreq_probe(struct platform_device > *pdev) > } > } > > - tegra_bpmp_put(bpmp); > - > tegra186_cpufreq_driver.driver_data = data; > > err = cpufreq_register_driver(_cpufreq_driver); > - if (err) > - return err; > - > - return 0; > > put_bpmp: > tegra_bpmp_put(bpmp); Applied. Thanks. -- viresh
Re: [PATCH 1/2] cpufreq: tegra186: Fix initial frequency
On 12-07-20, 11:06, Jon Hunter wrote:
> Commit 6cc3d0e9a097 ("cpufreq: tegra186: add
> CPUFREQ_NEED_INITIAL_FREQ_CHECK flag") fixed CPUFREQ support for
> Tegra186 but as a consequence the following warnings are now seen on
> boot ...
>
> cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 0 KHz
> cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to:
> 2035200 KHz
> cpufreq: cpufreq_online: CPU1: Running at unlisted freq: 0 KHz
> cpufreq: cpufreq_online: CPU1: Unlisted initial frequency changed to:
> 2035200 KHz
> cpufreq: cpufreq_online: CPU2: Running at unlisted freq: 0 KHz
> cpufreq: cpufreq_online: CPU2: Unlisted initial frequency changed to:
> 2035200 KHz
> cpufreq: cpufreq_online: CPU3: Running at unlisted freq: 0 KHz
> cpufreq: cpufreq_online: CPU3: Unlisted initial frequency changed to:
> 2035200 KHz
> cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 0 KHz
> cpufreq: cpufreq_online: CPU4: Unlisted initial frequency changed to:
> 2035200 KHz
> cpufreq: cpufreq_online: CPU5: Running at unlisted freq: 0 KHz
> cpufreq: cpufreq_online: CPU5: Unlisted initial frequency changed to:
> 2035200 KHz
>
> Although we could fix this by adding a 'get' operator for the Tegra186
> CPUFREQ driver, there is really little point because the CPUFREQ on
> Tegra186 is set by writing a value stored in the frequency table to a
> register and we just need to set the initial frequency.
The hardware still runs at the frequency requested by cpufreq core here, right ?
It is better to provide the get() callback as it is also used to show the
current frequency in userspace.
> So for Tegra186
> the simplest way to fix this is read the register that sets the
> frequency for each CPU and set the initial frequency when initialising
> the CPUFREQ driver.
>
> Signed-off-by: Jon Hunter
> ---
> drivers/cpufreq/tegra186-cpufreq.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/cpufreq/tegra186-cpufreq.c
> b/drivers/cpufreq/tegra186-cpufreq.c
> index 3d2f143748ef..c44190ce3f03 100644
> --- a/drivers/cpufreq/tegra186-cpufreq.c
> +++ b/drivers/cpufreq/tegra186-cpufreq.c
> @@ -59,6 +59,7 @@ static int tegra186_cpufreq_init(struct cpufreq_policy
> *policy)
> struct tegra186_cpufreq_cluster *cluster = >clusters[i];
> const struct tegra186_cpufreq_cluster_info *info =
> cluster->info;
> + u32 edvd_val;
> int core;
>
> for (core = 0; core < ARRAY_SIZE(info->cpus); core++) {
> @@ -71,6 +72,13 @@ static int tegra186_cpufreq_init(struct cpufreq_policy
> *policy)
> policy->driver_data =
> data->regs + info->offset + EDVD_CORE_VOLT_FREQ(core);
> policy->freq_table = cluster->table;
> +
> + edvd_val = readl(policy->driver_data);
> +
> + for (i = 0; cluster->table[i].frequency != CPUFREQ_TABLE_END;
> i++) {
> + if (cluster->table[i].driver_data == edvd_val)
> + policy->cur = cluster->table[i].frequency;
> + }
> break;
> }
>
> --
> 2.17.1
--
viresh
Re: [PATCH v9 0/5] mainline Protonic boards
On Wed, Jul 01, 2020 at 03:03:25PM +0200, Oleksij Rempel wrote: > Oleksij Rempel (5): > dt-bindings: arm: fsl: add different Protonic boards > ARM: dts: add Protonic PRTI6Q board > ARM: dts: add Protonic WD2 board > ARM: dts: add Protonic VT7 board > ARM: dts: add Protonic RVT board Applied all, thanks.
[PATCH V5 4/4] Documentation/mm: Add descriptions for arch page table helpers
This adds a specific description file for all arch page table helpers which is in sync with the semantics being tested via CONFIG_DEBUG_VM_PGTABLE. All future changes either to these descriptions here or the debug test should always remain in sync. Cc: Jonathan Corbet Cc: Andrew Morton Cc: Gerald Schaefer Cc: Christophe Leroy Cc: Mike Rapoport Cc: Vineet Gupta Cc: Catalin Marinas Cc: Will Deacon Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Kirill A. Shutemov Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: linux-snps-...@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-s...@vger.kernel.org Cc: linux-ri...@lists.infradead.org Cc: x...@kernel.org Cc: linux-a...@vger.kernel.org Cc: linux...@kvack.org Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Mike Rapoport Suggested-by: Mike Rapoport Signed-off-by: Anshuman Khandual --- Documentation/vm/arch_pgtable_helpers.rst | 258 ++ mm/debug_vm_pgtable.c | 6 + 2 files changed, 264 insertions(+) create mode 100644 Documentation/vm/arch_pgtable_helpers.rst diff --git a/Documentation/vm/arch_pgtable_helpers.rst b/Documentation/vm/arch_pgtable_helpers.rst new file mode 100644 index ..f3591ee3aaa8 --- /dev/null +++ b/Documentation/vm/arch_pgtable_helpers.rst @@ -0,0 +1,258 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _arch_page_table_helpers: + +=== +Architecture Page Table Helpers +=== + +Generic MM expects architectures (with MMU) to provide helpers to create, access +and modify page table entries at various level for different memory functions. +These page table helpers need to conform to a common semantics across platforms. +Following tables describe the expected semantics which can also be tested during +boot via CONFIG_DEBUG_VM_PGTABLE option. All future changes in here or the debug +test need to be in sync. + +== +PTE Page Table Helpers +== + ++---+--+ +| pte_same | Tests whether both PTE entries are the same | ++---+--+ +| pte_bad | Tests a non-table mapped PTE | ++---+--+ +| pte_present | Tests a valid mapped PTE | ++---+--+ +| pte_young | Tests a young PTE | ++---+--+ +| pte_dirty | Tests a dirty PTE | ++---+--+ +| pte_write | Tests a writable PTE | ++---+--+ +| pte_special | Tests a special PTE | ++---+--+ +| pte_protnone | Tests a PROT_NONE PTE | ++---+--+ +| pte_devmap| Tests a ZONE_DEVICE mapped PTE | ++---+--+ +| pte_soft_dirty| Tests a soft dirty PTE | ++---+--+ +| pte_swp_soft_dirty| Tests a soft dirty swapped PTE | ++---+--+ +| pte_mkyoung | Creates a young PTE | ++---+--+ +| pte_mkold | Creates an old PTE | ++---+--+ +| pte_mkdirty | Creates a dirty PTE | ++---+--+ +| pte_mkclean | Creates a clean PTE | ++---+--+ +| pte_mkwrite | Creates a writable PTE | ++---+--+ +| pte_mkwrprotect |
[PATCH V5 3/4] mm/debug_vm_pgtable: Add debug prints for individual tests
This adds debug print information that enlists all tests getting executed
on a given platform. With dynamic debug enabled, the following information
will be splashed during boot. For compactness purpose, dropped both time
stamp and prefix (i.e debug_vm_pgtable) from this sample output.
[debug_vm_pgtable ]: Validating architecture page table helpers
[pte_basic_tests ]: Validating PTE basic
[pmd_basic_tests ]: Validating PMD basic
[p4d_basic_tests ]: Validating P4D basic
[pgd_basic_tests ]: Validating PGD basic
[pte_clear_tests ]: Validating PTE clear
[pmd_clear_tests ]: Validating PMD clear
[pte_advanced_tests]: Validating PTE advanced
[pmd_advanced_tests]: Validating PMD advanced
[hugetlb_advanced_tests]: Validating HugeTLB advanced
[pmd_leaf_tests]: Validating PMD leaf
[pmd_huge_tests]: Validating PMD huge
[pte_savedwrite_tests ]: Validating PTE saved write
[pmd_savedwrite_tests ]: Validating PMD saved write
[pmd_populate_tests]: Validating PMD populate
[pte_special_tests ]: Validating PTE special
[pte_protnone_tests]: Validating PTE protnone
[pmd_protnone_tests]: Validating PMD protnone
[pte_devmap_tests ]: Validating PTE devmap
[pmd_devmap_tests ]: Validating PMD devmap
[pte_swap_tests]: Validating PTE swap
[swap_migration_tests ]: Validating swap migration
[hugetlb_basic_tests ]: Validating HugeTLB basic
[pmd_thp_tests ]: Validating PMD based THP
Cc: Andrew Morton
Cc: Gerald Schaefer
Cc: Christophe Leroy
Cc: Mike Rapoport
Cc: Vineet Gupta
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Kirill A. Shutemov
Cc: Paul Walmsley
Cc: Palmer Dabbelt
Cc: linux-snps-...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: x...@kernel.org
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Vineet Gupta#arc
Signed-off-by: Anshuman Khandual
---
mm/debug_vm_pgtable.c | 46 ++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index 9c7c11eecf17..0db4390435be 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -8,7 +8,7 @@
*
* Author: Anshuman Khandual
*/
-#define pr_fmt(fmt) "debug_vm_pgtable: %s: " fmt, __func__
+#define pr_fmt(fmt) "debug_vm_pgtable: [%-25s]: " fmt, __func__
#include
#include
@@ -48,6 +48,7 @@ static void __init pte_basic_tests(unsigned long pfn,
pgprot_t prot)
{
pte_t pte = pfn_pte(pfn, prot);
+ pr_debug("Validating PTE basic\n");
WARN_ON(!pte_same(pte, pte));
WARN_ON(!pte_young(pte_mkyoung(pte_mkold(pte;
WARN_ON(!pte_dirty(pte_mkdirty(pte_mkclean(pte;
@@ -64,6 +65,7 @@ static void __init pte_advanced_tests(struct mm_struct *mm,
{
pte_t pte = pfn_pte(pfn, prot);
+ pr_debug("Validating PTE advanced\n");
pte = pfn_pte(pfn, prot);
set_pte_at(mm, vaddr, ptep, pte);
ptep_set_wrprotect(mm, vaddr, ptep);
@@ -103,6 +105,7 @@ static void __init pte_savedwrite_tests(unsigned long pfn,
pgprot_t prot)
{
pte_t pte = pfn_pte(pfn, prot);
+ pr_debug("Validating PTE saved write\n");
WARN_ON(!pte_savedwrite(pte_mk_savedwrite(pte_clear_savedwrite(pte;
WARN_ON(pte_savedwrite(pte_clear_savedwrite(pte_mk_savedwrite(pte;
}
@@ -114,6 +117,7 @@ static void __init pmd_basic_tests(unsigned long pfn,
pgprot_t prot)
if (!has_transparent_hugepage())
return;
+ pr_debug("Validating PMD basic\n");
WARN_ON(!pmd_same(pmd, pmd));
WARN_ON(!pmd_young(pmd_mkyoung(pmd_mkold(pmd;
WARN_ON(!pmd_dirty(pmd_mkdirty(pmd_mkclean(pmd;
@@ -138,6 +142,7 @@ static void __init pmd_advanced_tests(struct mm_struct *mm,
if (!has_transparent_hugepage())
return;
+ pr_debug("Validating PMD advanced\n");
/* Align the address wrt HPAGE_PMD_SIZE */
vaddr = (vaddr & HPAGE_PMD_MASK) + HPAGE_PMD_SIZE;
@@ -180,6 +185,7 @@ static void __init pmd_leaf_tests(unsigned long pfn,
pgprot_t prot)
{
pmd_t pmd = pfn_pmd(pfn, prot);
+ pr_debug("Validating PMD leaf\n");
/*
* PMD based THP is a leaf entry.
*/
@@ -193,6 +199,8 @@ static void __init pmd_huge_tests(pmd_t *pmdp, unsigned
long pfn, pgprot_t prot)
if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP))
return;
+
+ pr_debug("Validating PMD huge\n");
/*
* X86 defined pmd_set_huge() verifies that the given
* PMD is not a populated non-leaf entry.
@@ -208,6 +216,7 @@
[PATCH V5 2/4] mm/debug_vm_pgtable: Add tests validating advanced arch page table helpers
This adds new tests validating for these following arch advanced page table
helpers. These tests create and test specific mapping types at various page
table levels.
1. pxxp_set_wrprotect()
2. pxxp_get_and_clear()
3. pxxp_set_access_flags()
4. pxxp_get_and_clear_full()
5. pxxp_test_and_clear_young()
6. pxx_leaf()
7. pxx_set_huge()
8. pxx_(clear|mk)_savedwrite()
9. huge_pxxp_xxx()
Cc: Andrew Morton
Cc: Gerald Schaefer
Cc: Christophe Leroy
Cc: Mike Rapoport
Cc: Vineet Gupta
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Kirill A. Shutemov
Cc: Paul Walmsley
Cc: Palmer Dabbelt
Cc: linux-snps-...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: x...@kernel.org
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Vineet Gupta#arc
Suggested-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
---
mm/debug_vm_pgtable.c | 312 ++
1 file changed, 312 insertions(+)
diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index 2fac47db3eb7..9c7c11eecf17 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -28,6 +29,7 @@
#include
#include
#include
+#include
#define VMFLAGS(VM_READ|VM_WRITE|VM_EXEC)
@@ -55,6 +57,55 @@ static void __init pte_basic_tests(unsigned long pfn,
pgprot_t prot)
WARN_ON(pte_write(pte_wrprotect(pte_mkwrite(pte;
}
+static void __init pte_advanced_tests(struct mm_struct *mm,
+ struct vm_area_struct *vma, pte_t *ptep,
+ unsigned long pfn, unsigned long vaddr,
+ pgprot_t prot)
+{
+ pte_t pte = pfn_pte(pfn, prot);
+
+ pte = pfn_pte(pfn, prot);
+ set_pte_at(mm, vaddr, ptep, pte);
+ ptep_set_wrprotect(mm, vaddr, ptep);
+ pte = ptep_get(ptep);
+ WARN_ON(pte_write(pte));
+
+ pte = pfn_pte(pfn, prot);
+ set_pte_at(mm, vaddr, ptep, pte);
+ ptep_get_and_clear(mm, vaddr, ptep);
+ pte = ptep_get(ptep);
+ WARN_ON(!pte_none(pte));
+
+ pte = pfn_pte(pfn, prot);
+ pte = pte_wrprotect(pte);
+ pte = pte_mkclean(pte);
+ set_pte_at(mm, vaddr, ptep, pte);
+ pte = pte_mkwrite(pte);
+ pte = pte_mkdirty(pte);
+ ptep_set_access_flags(vma, vaddr, ptep, pte, 1);
+ pte = ptep_get(ptep);
+ WARN_ON(!(pte_write(pte) && pte_dirty(pte)));
+
+ pte = pfn_pte(pfn, prot);
+ set_pte_at(mm, vaddr, ptep, pte);
+ ptep_get_and_clear_full(mm, vaddr, ptep, 1);
+ pte = ptep_get(ptep);
+ WARN_ON(!pte_none(pte));
+
+ pte = pte_mkyoung(pte);
+ set_pte_at(mm, vaddr, ptep, pte);
+ ptep_test_and_clear_young(vma, vaddr, ptep);
+ pte = ptep_get(ptep);
+ WARN_ON(pte_young(pte));
+}
+
+static void __init pte_savedwrite_tests(unsigned long pfn, pgprot_t prot)
+{
+ pte_t pte = pfn_pte(pfn, prot);
+
+ WARN_ON(!pte_savedwrite(pte_mk_savedwrite(pte_clear_savedwrite(pte;
+ WARN_ON(pte_savedwrite(pte_clear_savedwrite(pte_mk_savedwrite(pte;
+}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot)
{
@@ -77,6 +128,90 @@ static void __init pmd_basic_tests(unsigned long pfn,
pgprot_t prot)
WARN_ON(!pmd_bad(pmd_mkhuge(pmd)));
}
+static void __init pmd_advanced_tests(struct mm_struct *mm,
+ struct vm_area_struct *vma, pmd_t *pmdp,
+ unsigned long pfn, unsigned long vaddr,
+ pgprot_t prot)
+{
+ pmd_t pmd = pfn_pmd(pfn, prot);
+
+ if (!has_transparent_hugepage())
+ return;
+
+ /* Align the address wrt HPAGE_PMD_SIZE */
+ vaddr = (vaddr & HPAGE_PMD_MASK) + HPAGE_PMD_SIZE;
+
+ pmd = pfn_pmd(pfn, prot);
+ set_pmd_at(mm, vaddr, pmdp, pmd);
+ pmdp_set_wrprotect(mm, vaddr, pmdp);
+ pmd = READ_ONCE(*pmdp);
+ WARN_ON(pmd_write(pmd));
+
+ pmd = pfn_pmd(pfn, prot);
+ set_pmd_at(mm, vaddr, pmdp, pmd);
+ pmdp_huge_get_and_clear(mm, vaddr, pmdp);
+ pmd = READ_ONCE(*pmdp);
+ WARN_ON(!pmd_none(pmd));
+
+ pmd = pfn_pmd(pfn, prot);
+ pmd = pmd_wrprotect(pmd);
+ pmd = pmd_mkclean(pmd);
+ set_pmd_at(mm, vaddr, pmdp, pmd);
+ pmd = pmd_mkwrite(pmd);
+ pmd = pmd_mkdirty(pmd);
+ pmdp_set_access_flags(vma, vaddr, pmdp, pmd, 1);
+ pmd = READ_ONCE(*pmdp);
+ WARN_ON(!(pmd_write(pmd) &&
[PATCH V5 1/4] mm/debug_vm_pgtable: Add tests validating arch helpers for core MM features
This adds new tests validating arch page table helpers for these following
core memory features. These tests create and test specific mapping types at
various page table levels.
1. SPECIAL mapping
2. PROTNONE mapping
3. DEVMAP mapping
4. SOFTDIRTY mapping
5. SWAP mapping
6. MIGRATION mapping
7. HUGETLB mapping
8. THP mapping
Cc: Andrew Morton
Cc: Gerald Schaefer
Cc: Christophe Leroy
Cc: Mike Rapoport
Cc: Vineet Gupta
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Kirill A. Shutemov
Cc: Paul Walmsley
Cc: Palmer Dabbelt
Cc: linux-snps-...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: x...@kernel.org
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Vineet Gupta#arc
Reviewed-by: Zi Yan
Suggested-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
---
mm/debug_vm_pgtable.c | 302 +-
1 file changed, 301 insertions(+), 1 deletion(-)
diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index 61ab16fb2e36..2fac47db3eb7 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -282,6 +282,278 @@ static void __init pmd_populate_tests(struct mm_struct
*mm, pmd_t *pmdp,
WARN_ON(pmd_bad(pmd));
}
+static void __init pte_special_tests(unsigned long pfn, pgprot_t prot)
+{
+ pte_t pte = pfn_pte(pfn, prot);
+
+ if (!IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL))
+ return;
+
+ WARN_ON(!pte_special(pte_mkspecial(pte)));
+}
+
+static void __init pte_protnone_tests(unsigned long pfn, pgprot_t prot)
+{
+ pte_t pte = pfn_pte(pfn, prot);
+
+ if (!IS_ENABLED(CONFIG_NUMA_BALANCING))
+ return;
+
+ WARN_ON(!pte_protnone(pte));
+ WARN_ON(!pte_present(pte));
+}
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+static void __init pmd_protnone_tests(unsigned long pfn, pgprot_t prot)
+{
+ pmd_t pmd = pmd_mkhuge(pfn_pmd(pfn, prot));
+
+ if (!IS_ENABLED(CONFIG_NUMA_BALANCING))
+ return;
+
+ WARN_ON(!pmd_protnone(pmd));
+ WARN_ON(!pmd_present(pmd));
+}
+#else /* !CONFIG_TRANSPARENT_HUGEPAGE */
+static void __init pmd_protnone_tests(unsigned long pfn, pgprot_t prot) { }
+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+
+#ifdef CONFIG_ARCH_HAS_PTE_DEVMAP
+static void __init pte_devmap_tests(unsigned long pfn, pgprot_t prot)
+{
+ pte_t pte = pfn_pte(pfn, prot);
+
+ WARN_ON(!pte_devmap(pte_mkdevmap(pte)));
+}
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+static void __init pmd_devmap_tests(unsigned long pfn, pgprot_t prot)
+{
+ pmd_t pmd = pfn_pmd(pfn, prot);
+
+ WARN_ON(!pmd_devmap(pmd_mkdevmap(pmd)));
+}
+
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+static void __init pud_devmap_tests(unsigned long pfn, pgprot_t prot)
+{
+ pud_t pud = pfn_pud(pfn, prot);
+
+ WARN_ON(!pud_devmap(pud_mkdevmap(pud)));
+}
+#else /* !CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
+static void __init pud_devmap_tests(unsigned long pfn, pgprot_t prot) { }
+#endif /* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
+#else /* CONFIG_TRANSPARENT_HUGEPAGE */
+static void __init pmd_devmap_tests(unsigned long pfn, pgprot_t prot) { }
+static void __init pud_devmap_tests(unsigned long pfn, pgprot_t prot) { }
+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+#else
+static void __init pte_devmap_tests(unsigned long pfn, pgprot_t prot) { }
+static void __init pmd_devmap_tests(unsigned long pfn, pgprot_t prot) { }
+static void __init pud_devmap_tests(unsigned long pfn, pgprot_t prot) { }
+#endif /* CONFIG_ARCH_HAS_PTE_DEVMAP */
+
+static void __init pte_soft_dirty_tests(unsigned long pfn, pgprot_t prot)
+{
+ pte_t pte = pfn_pte(pfn, prot);
+
+ if (!IS_ENABLED(CONFIG_MEM_SOFT_DIRTY))
+ return;
+
+ WARN_ON(!pte_soft_dirty(pte_mksoft_dirty(pte)));
+ WARN_ON(pte_soft_dirty(pte_clear_soft_dirty(pte)));
+}
+
+static void __init pte_swap_soft_dirty_tests(unsigned long pfn, pgprot_t prot)
+{
+ pte_t pte = pfn_pte(pfn, prot);
+
+ if (!IS_ENABLED(CONFIG_MEM_SOFT_DIRTY))
+ return;
+
+ WARN_ON(!pte_swp_soft_dirty(pte_swp_mksoft_dirty(pte)));
+ WARN_ON(pte_swp_soft_dirty(pte_swp_clear_soft_dirty(pte)));
+}
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+static void __init pmd_soft_dirty_tests(unsigned long pfn, pgprot_t prot)
+{
+ pmd_t pmd = pfn_pmd(pfn, prot);
+
+ if (!IS_ENABLED(CONFIG_MEM_SOFT_DIRTY))
+ return;
+
+ WARN_ON(!pmd_soft_dirty(pmd_mksoft_dirty(pmd)));
+ WARN_ON(pmd_soft_dirty(pmd_clear_soft_dirty(pmd)));
+}
+
+static void __init pmd_swap_soft_dirty_tests(unsigned long pfn, pgprot_t prot)
+{
+ pmd_t
[PATCH V5 0/4] mm/debug_vm_pgtable: Add some more tests
This series adds some more arch page table helper validation tests which are related to core and advanced memory functions. This also creates a documentation, enlisting expected semantics for all page table helpers as suggested by Mike Rapoport previously (https://lkml.org/lkml/2020/1/30/40). There are many TRANSPARENT_HUGEPAGE and ARCH_HAS_TRANSPARENT_HUGEPAGE_PUD ifdefs scattered across the test. But consolidating all the fallback stubs is not very straight forward because ARCH_HAS_TRANSPARENT_HUGEPAGE_PUD is not explicitly dependent on ARCH_HAS_TRANSPARENT_HUGEPAGE. Tested on arm64, x86 platforms but only build tested on all other enabled platforms through ARCH_HAS_DEBUG_VM_PGTABLE i.e powerpc, arc, s390. The following failure on arm64 still exists which was mentioned previously. It will be fixed with the upcoming THP migration on arm64 enablement series. WARNING mm/debug_vm_pgtable.c:866 debug_vm_pgtable+0x940/0xa54 WARN_ON(!pmd_present(pmd_mkinvalid(pmd_mkhuge(pmd This series is based on v5.8-rc5. Changes in V5: - Dropped RANDOM_ORVALUE from hugetlb_advanced_tests() - Folded in Mike's patch for the rst document - Fixed typos in the rst document Changes in V4: (https://patchwork.kernel.org/project/linux-mm/list/?series=313173) - Replaced READ_ONCE() with ptep_get() while accessing PTE pointers per Christophe - Fixed function argument alignments per Christophe Changes in V3: (https://patchwork.kernel.org/project/linux-mm/list/?series=302483) - Replaced HAVE_ARCH_SOFT_DIRTY with MEM_SOFT_DIRTY - Added HAVE_ARCH_HUGE_VMAP checks in pxx_huge_tests() per Gerald - Updated documentation for pmd_thp_tests() per Zi Yan - Replaced READ_ONCE() with huge_ptep_get() per Gerald - Added pte_mkhuge() and masking with PMD_MASK per Gerald - Replaced pte_same() with holding pfn check in pxx_swap_tests() - Added documentation for all (#ifdef #else #endif) per Gerald - Updated pmd_protnone_tests() per Gerald - Updated HugeTLB PTE creation in hugetlb_advanced_tests() per Gerald - Replaced [pmd|pud]_mknotpresent() with [pmd|pud]_mkinvalid() - Added has_transparent_hugepage() check for PMD and PUD tests - Added a patch which debug prints all individual tests being executed - Updated documentation for renamed [pmd|pud]_mkinvalid() helpers Changes in V2: (https://patchwork.kernel.org/project/linux-mm/list/?series=260573) - Dropped CONFIG_ARCH_HAS_PTE_SPECIAL per Christophe - Dropped CONFIG_NUMA_BALANCING per Christophe - Dropped CONFIG_HAVE_ARCH_SOFT_DIRTY per Christophe - Dropped CONFIG_MIGRATION per Christophe - Replaced CONFIG_S390 with __HAVE_ARCH_PMDP_INVALIDATE - Moved page allocation & free inside swap_migration_tests() per Christophe - Added CONFIG_TRANSPARENT_HUGEPAGE to protect pfn_pmd() - Added CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD to protect pfn_pud() - Added a patch for other arch advanced page table helper tests - Added a patch creating a documentation for page table helper semantics Changes in V1: (https://patchwork.kernel.org/patch/11408253/) Cc: Jonathan Corbet Cc: Andrew Morton Cc: Mike Rapoport Cc: Vineet Gupta Cc: Catalin Marinas Cc: Will Deacon Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Kirill A. Shutemov Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Zi Yan Cc: Gerald Schaefer Cc: Christophe Leroy Cc: Christophe Leroy Cc: linux-snps-...@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-s...@vger.kernel.org Cc: linux-ri...@lists.infradead.org Cc: x...@kernel.org Cc: linux...@kvack.org Cc: linux-...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Anshuman Khandual (4): mm/debug_vm_pgtable: Add tests validating arch helpers for core MM features mm/debug_vm_pgtable: Add tests validating advanced arch page table helpers mm/debug_vm_pgtable: Add debug prints for individual tests Documentation/mm: Add descriptions for arch page table helpers Documentation/vm/arch_pgtable_helpers.rst | 258 + mm/debug_vm_pgtable.c | 666 +- 2 files changed, 922 insertions(+), 2 deletions(-) create mode 100644 Documentation/vm/arch_pgtable_helpers.rst -- 2.20.1
Re: [PATCH] ARM: dts: imx6ul: Add ASRC device node
On Wed, Jul 01, 2020 at 11:46:56AM +0800, Shengjiu Wang wrote: > Add ASRC device node. > > Signed-off-by: Shengjiu Wang Applied, thanks.
[PATCH] clk: clk-atlas6: fix return value check in atlas6_clk_init()
In case of error, the function clk_register() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: Xu Wang
---
drivers/clk/sirf/clk-atlas6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sirf/clk-atlas6.c b/drivers/clk/sirf/clk-atlas6.c
index c84d5bab7ac2..b95483bb6a5e 100644
--- a/drivers/clk/sirf/clk-atlas6.c
+++ b/drivers/clk/sirf/clk-atlas6.c
@@ -135,7 +135,7 @@ static void __init atlas6_clk_init(struct device_node *np)
for (i = pll1; i < maxclk; i++) {
atlas6_clks[i] = clk_register(NULL, atlas6_clk_hw_array[i]);
- BUG_ON(!atlas6_clks[i]);
+ BUG_ON(IS_ERR(atlas6_clks[i]));
}
clk_register_clkdev(atlas6_clks[cpu], NULL, "cpu");
clk_register_clkdev(atlas6_clks[io], NULL, "io");
--
2.17.1
Re: [PATCH v10 05/15] perf evlist: implement control command handling functions
On Wed, Jul 8, 2020 at 4:50 PM Alexey Budankov
wrote:
>
>
> Implement functions of initialization, finalization and processing
> of control command messages coming from control file descriptors.
> Allocate control file descriptor as descriptor at struct pollfd
> object of evsel_list for atomic poll() operation.
>
> Signed-off-by: Alexey Budankov
> ---
[SNIP]
> +static int evlist__ctlfd_recv(struct evlist *evlist, enum evlist_ctl_cmd
> *cmd,
> + char *cmd_data, size_t data_size)
> +{
> + int err;
> + char c;
> + size_t bytes_read = 0;
> +
> + memset(cmd_data, 0, data_size--);
I overlooked the '--' at the end and thought there might be
buffer overflow.. Care to add a comment?
> +
> + do {
> + err = read(evlist->ctl_fd.fd, , 1);
Maybe I missed earlier discussion, but do we really want
this 1 byte read in a loop?
Thanks
Namhyung
> + if (err > 0) {
> + if (c == '\n' || c == '\0')
> + break;
> + cmd_data[bytes_read++] = c;
> + if (bytes_read == data_size)
> + break;
> + } else {
> + if (err == -1)
> + pr_err("Failed to read from ctlfd %d: %m\n",
> evlist->ctl_fd.fd);
> + break;
> + }
> + } while (1);
> +
> + pr_debug("Message from ctl_fd: \"%s%s\"\n", cmd_data,
> +bytes_read == data_size ? "" : c == '\n' ? "\\n" : "\\0");
> +
> + if (err > 0) {
> + if (!strncmp(cmd_data, EVLIST_CTL_CMD_ENABLE_TAG,
> +(sizeof(EVLIST_CTL_CMD_ENABLE_TAG)-1))) {
> + *cmd = EVLIST_CTL_CMD_ENABLE;
> + } else if (!strncmp(cmd_data, EVLIST_CTL_CMD_DISABLE_TAG,
> + (sizeof(EVLIST_CTL_CMD_DISABLE_TAG)-1))) {
> + *cmd = EVLIST_CTL_CMD_DISABLE;
> + }
> + }
> +
> + return err;
> +}
RE: [PATCH 2/2] Input: elan_i2c - High resolution report for new pattern 2.
HI Dmitry:
1. Could you please explain relationship between IC types and "pattern"?
--> There is no direct connection between IC_type and "pattern".
2. Can there be controllers with same IC type but different patterns?
--> Yes, same IC type might have different pattern, ir depends on the TP
size.
3. Do SMbus controllers use the new report type?
--> Yes
Do controllers use only one type of report (old or the new 0x60), or can
they send mix?
--> The controllers use only one type of report, it depends on the value of
"pattern".
4. The SMBus code always returns '0' as pattern. How can we have SMBus with
pattern 2?
--> The SMBus protocol was only triggered in PS2+SMBus mode. The PS2
interface would read the "pattern" value and then transfer the value to
SMBus driver
The Change were in below patches.
Elan_i2c:
[PATCH 1/3] Input: elan_i2c - Do no operation for elan_smbus_set_mode
function.
[PATCH 2/3] Input: elan_i2c - Do no operation for elan_smbus_sleep_control
function.
[PATCH 3/3] Input: elan_i2c - Get the device information from PS/2 interface
Elantench:
[PATCH 1/6] Input: elantech - Add the pattern for firmware into
elantech_device_info structure.
[PATCH 2/6] Input: elantech - Add the function to get more bytes from
register.
[PATCH 3/6] Input: elantech - Increace and correct device information for
pattern 0,1,2.
[PATCH 4/6] Input: elantech - High resolution report for new pattern 2.
[PATCH 5/6] Input: elantech - Transfer the device information from PS/2 to
SMBus.
[PATCH 6/6] Input: elantech - Add the flag which will also use host notify.
5. I think it is OK if you declare buffer as:
u8 buffer[max(ETP_I2C_REPORT_LEN, ETP_I2C_REPORT_LEN_ID2)];
and do not worry about dynamic allocation. It should be OK if you do a
partial read here, we just want to make sure we consume all pending data
before re-enabling interrupts.
--> OK, we would initial the buffer as "u8 buffer[ETP_I2C_REPORT_LEN_ID2]".
6.
> - *max_x = le16_to_cpup((__le16 *)val) & 0x0fff;
> + *max_x = le16_to_cpup((__le16 *)val) & 0x;
There is no point in executing this max for 16 bit value, so if we can drop
this altogether, as long as we are certain that older firmware did not
return garbage in 4 upper bits of this data.
--> We have internal check. the older firmware can also execute 16 bit
value.
THANKS
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Monday, July 13, 2020 3:11 AM
To: Jingle Wu
Cc: linux-kernel@vger.kernel.org; linux-in...@vger.kernel.org;
phoe...@emc.com.tw; josh.c...@emc.com.tw; dave.w...@emc.com.tw
Subject: Re: [PATCH 2/2] Input: elan_i2c - High resolution report for new
pattern 2.
Hi Jingle,
On Fri, Jul 10, 2020 at 01:41:16AM -0400, Jingle Wu wrote:
> Due to the higer resolution touchpads would be produced, The mainly
> modifications were as below:
> 1. the former resolution bits were not enough. Extend the resolution
> bits from 12 to 16 bits.
> 2. Increase the report ID 0x60 for higher resoltion of touchpads.
> 3. Move the position of mk value in the report packet.
Could you please explain relationship between IC types and "pattern"?
Can there be controllers with same IC type but different patterns?
Do SMbus controllers use the new report type? Do controllers use only one
type of report (old or the new 0x60), or can they send mix?
>
> Signed-off-by: Jingle Wu
> ---
> drivers/input/mouse/elan_i2c.h | 7 +-
> drivers/input/mouse/elan_i2c_core.c | 134 +++
> drivers/input/mouse/elan_i2c_i2c.c | 48 +++---
> drivers/input/mouse/elan_i2c_smbus.c | 14 ++-
> 4 files changed, 170 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/input/mouse/elan_i2c.h
> b/drivers/input/mouse/elan_i2c.h index f28b747978f5..71fff2cef8b5
> 100644
> --- a/drivers/input/mouse/elan_i2c.h
> +++ b/drivers/input/mouse/elan_i2c.h
> @@ -78,9 +78,12 @@ struct elan_transport_ops {
> int (*write_fw_block)(struct i2c_client *client, u16 fw_page_size,
> const u8 *page, u16 checksum, int idx);
> int (*finish_fw_update)(struct i2c_client *client,
> - struct completion *reset_done);
> + struct completion *reset_done,
> + int report_len);
>
> - int (*get_report)(struct i2c_client *client, u8 *report);
> + int (*get_report_length)(struct i2c_client *client, int
*report_len);
> + int (*get_report)(struct i2c_client *client, u8 *report,
> + int report_len);
> int (*get_pressure_adjustment)(struct i2c_client *client,
> int *adjustment);
> int (*get_pattern)(struct i2c_client *client, u8 *pattern); diff
> --git a/drivers/input/mouse/elan_i2c_core.c
> b/drivers/input/mouse/elan_i2c_core.c
> index 0703f7d0d02d..a1bdb25c2450 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@
Re: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal zone support
On Thu, Jul 02, 2020 at 03:33:59AM +, Andy Tang wrote: > Hi Shawn, > > Do you think it is ok if the cooling devices are shared between thermal zones? Yeah, Amit has the authority on thermal support, so follow his suggestion, I would say :) Shawn
Re: [PATCH v10 04/15] perf evlist: introduce control file descriptors
Hello,
On Wed, Jul 8, 2020 at 4:47 PM Alexey Budankov
wrote:
>
>
> Define and initialize control file descriptors.
>
> Signed-off-by: Alexey Budankov
> ---
> tools/perf/util/evlist.c | 3 +++
> tools/perf/util/evlist.h | 5 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index bcbe0cb8482e..36eb50aba1f5 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -63,6 +63,9 @@ void evlist__init(struct evlist *evlist, struct
> perf_cpu_map *cpus,
> perf_evlist__set_maps(>core, cpus, threads);
> evlist->workload.pid = -1;
> evlist->bkw_mmap_state = BKW_MMAP_NOTREADY;
> + evlist->ctl_fd.fd = -1;
> + evlist->ctl_fd.ack = -1;
> + evlist->ctl_fd.pos = -1;
> }
>
> struct evlist *evlist__new(void)
> diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
> index 38901c0d1599..2caf19fb87a8 100644
> --- a/tools/perf/util/evlist.h
> +++ b/tools/perf/util/evlist.h
> @@ -74,6 +74,11 @@ struct evlist {
> pthread_t th;
> volatile intdone;
> } thread;
> + struct {
> + int fd;
> + int ack;
> + int pos;
> + } ctl_fd;
Could you please add brief descriptions for each field
in the comment? It's not obvious to me other than fd.
Thanks
Namhyung
> };
>
> struct evsel_str_handler {
> --
> 2.24.1
>
>
[PATCH v2] f2fs: change the way of handling range.len in F2FS_IOC_SEC_TRIM_FILE
From: Daeho Jeong
Changed the way of handling range.len of F2FS_IOC_SEC_TRIM_FILE.
1. Added -1 value support for range.len to secure trim the whole blocks
starting from range.start regardless of i_size.
2. If the end of the range passes over the end of file, it means until
the end of file (i_size).
3. ignored the case of that range.len is zero to prevent the function
from making end_addr zero and triggering different behaviour of
the function.
Signed-off-by: Daeho Jeong
---
Changes in v2:
- Changed -1 range.len option to mean the whole blocks starting from
range.start regardless of i_size
---
fs/f2fs/file.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 368c80f8e2a1..2485841e3b2d 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -3792,7 +3792,7 @@ static int f2fs_sec_trim_file(struct file *filp, unsigned
long arg)
pgoff_t index, pg_end;
block_t prev_block = 0, len = 0;
loff_t end_addr;
- bool to_end;
+ bool to_end = false;
int ret = 0;
if (!(filp->f_mode & FMODE_WRITE))
@@ -3813,23 +3813,23 @@ static int f2fs_sec_trim_file(struct file *filp,
unsigned long arg)
file_start_write(filp);
inode_lock(inode);
- if (f2fs_is_atomic_file(inode) || f2fs_compressed_file(inode)) {
+ if (f2fs_is_atomic_file(inode) || f2fs_compressed_file(inode) ||
+ range.start >= inode->i_size) {
ret = -EINVAL;
goto err;
}
- if (range.start >= inode->i_size) {
- ret = -EINVAL;
+ if (range.len == 0)
goto err;
- }
- if (inode->i_size - range.start < range.len) {
- ret = -E2BIG;
- goto err;
+ if (inode->i_size - range.start > range.len) {
+ end_addr = range.start + range.len;
+ } else {
+ end_addr = range.len == (u64)-1 ?
+ sbi->sb->s_maxbytes : inode->i_size;
+ to_end = true;
}
- end_addr = range.start + range.len;
- to_end = (end_addr == inode->i_size);
if (!IS_ALIGNED(range.start, F2FS_BLKSIZE) ||
(!to_end && !IS_ALIGNED(end_addr, F2FS_BLKSIZE))) {
ret = -EINVAL;
@@ -3846,7 +3846,8 @@ static int f2fs_sec_trim_file(struct file *filp, unsigned
long arg)
down_write(_I(inode)->i_gc_rwsem[WRITE]);
down_write(_I(inode)->i_mmap_sem);
- ret = filemap_write_and_wait_range(mapping, range.start, end_addr - 1);
+ ret = filemap_write_and_wait_range(mapping, range.start,
+ to_end ? LLONG_MAX : end_addr - 1);
if (ret)
goto out;
--
2.27.0.383.g050319c2ae-goog
