Re: [PATCH v3] dcdbas: Add support for WSMT ACPI table
On Wed, Jun 13, 2018 at 4:24 AM, Stuart Hayes wrote:
>
> If the WSMT ACPI table is present and indicates that a fixed communication
> buffer should be used, use the firmware-specified buffer instead of
> allocating a buffer in memory for communications between the dcdbas driver
> and firmare.
Thanks for an update. My comments below.
> - if ((pos + count) > MAX_SMI_DATA_BUF_SIZE)
> + if ((pos + count) > max_smi_data_buf_size)
> return -EINVAL;
Parens are redundant, but okay, not purpose of the change.
> + /* Calling Interface SMI
I suppose the style of the comments like
/*
* Calling ...
...
> +*
> +* Provide physical address of command buffer field within
> +* the struct smi_cmd... can't use virt_to_phys on smi_cmd
> +* because address may be from memremap.
Wait, memremap() might return a virtual address. How we be sure that
we got still physical address here?
(Also note () when referring to functions)
> +*/
> + smi_cmd->ebx = smi_data_buf_phys_addr +
> + offsetof(struct smi_cmd, command_buffer);
Btw, can it be one line (~83 character are okay for my opinion).
> + acpi_get_table(ACPI_SIG_WSMT, 0, (struct acpi_table_header **));
> + if (!wsmt)
> + return 0;
> +
> + /* Check if WSMT ACPI table shows that protection is enabled */
> + if (!(wsmt->protection_flags & ACPI_WSMT_FIXED_COMM_BUFFERS)
> + || !(wsmt->protection_flags
> +& ACPI_WSMT_COMM_BUFFER_NESTED_PTR_PROTECTION))
Better to indent like
if (... ||
!(... & ...)
> + return 0;
> +
> + /* Scan for EPS (entry point structure) */
> + for (addr = (u8 *)__va(0xf);
> +addr < (u8 *)__va(0x10 - sizeof(struct smm_eps_table));
> +addr += 1) {
This wasn't commented IIRC and changed. So, why?
--
With Best Regards,
Andy Shevchenko
Re: [PATCH V6] powercap/drivers/idle_injection: Add an idle injection framework
On 12-06-18, 19:35, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 07:02:57PM +0200, Daniel Lezcano wrote:
> > Mmh, it is unclear for me if the park() vs wakeup() can happen at the
> > same time.
> >
> > If the park() function is called, that means the hotplug is allowed.
>
> No, it means we're inside hot-un-plug, but that doesn't stop the hrtimer
> from firing.
>
> > If the hotplug is allowed, we can modify the online mask.
> >
> > What happens with the online mask when we are processing it in an
> > interrupt context ?
>
> RCU-like, if you observe a CPU in the online mask, it will stay
> available, but the bit might get cleared.
>
> > > Maybe avoid the issue entire by having a
> > > {period,idle} tuple, where your old run := period - idle.
> >
> > Can you elaborate ? I don't get it.
>
> Have a period parameter that specifies the interval in which you have
> one injected idle, and specify for how long you want to inject idle;
> then obviously idle < period.
>
> > >>> Furthermore, should you not be using hrtimer_forward(,
> > >>> idle_duration + run_duration) instead? AFAICT the current scheme is
> > >>> prone to drifting.
> > >>
> > >> (I assume you meant setting the timer in the wakeup task function).
> > >>
> > >> Yes, drifting is not an issue if that happens. This scheme is simpler
> > >> and safer than setting the timer ahead before waking up the tasks with
> > >> the risk it expires before all the tasks ended their idle cycles.
> > >
> > > sloppy though..
> >
> > Ok, do you prefer to see the timer set in the wakeup function and thus
> > having a periodic tick for the idle injection ?
>
> I think having a HRTIMER_RESTART handler that does hrtimer_forward() is
> the most sensible. You will end up having to deal with threads not being
> ready, but I think that's not a real problem.
Honestly speaking I am not sure if we can fix all the races we have identified
until now, with the current design and the fear of using resources after getting
freed will always be there. Too many corner cases really.
The requirement we have is to make sure no kthread or hrtimer is still in use
when the ii_dev is freed from idle_injection_unregister().
May be the only sane way to make it work is to call
smpboot_register_percpu_thread() from idle_injection_register() and then
unregister those threads from idle_injection_unregister().
--
viresh
Re: [PATCH V6] powercap/drivers/idle_injection: Add an idle injection framework
On 13/06/2018 10:55, Viresh Kumar wrote:
> On 12-06-18, 19:35, Peter Zijlstra wrote:
>> On Tue, Jun 12, 2018 at 07:02:57PM +0200, Daniel Lezcano wrote:
>>> Mmh, it is unclear for me if the park() vs wakeup() can happen at the
>>> same time.
>>>
>>> If the park() function is called, that means the hotplug is allowed.
>>
>> No, it means we're inside hot-un-plug, but that doesn't stop the hrtimer
>> from firing.
>>
>>> If the hotplug is allowed, we can modify the online mask.
>>>
>>> What happens with the online mask when we are processing it in an
>>> interrupt context ?
>>
>> RCU-like, if you observe a CPU in the online mask, it will stay
>> available, but the bit might get cleared.
>>
Maybe avoid the issue entire by having a
{period,idle} tuple, where your old run := period - idle.
>>>
>>> Can you elaborate ? I don't get it.
>>
>> Have a period parameter that specifies the interval in which you have
>> one injected idle, and specify for how long you want to inject idle;
>> then obviously idle < period.
>>
>> Furthermore, should you not be using hrtimer_forward(,
>> idle_duration + run_duration) instead? AFAICT the current scheme is
>> prone to drifting.
>
> (I assume you meant setting the timer in the wakeup task function).
>
> Yes, drifting is not an issue if that happens. This scheme is simpler
> and safer than setting the timer ahead before waking up the tasks with
> the risk it expires before all the tasks ended their idle cycles.
sloppy though..
>>>
>>> Ok, do you prefer to see the timer set in the wakeup function and thus
>>> having a periodic tick for the idle injection ?
>>
>> I think having a HRTIMER_RESTART handler that does hrtimer_forward() is
>> the most sensible. You will end up having to deal with threads not being
>> ready, but I think that's not a real problem.
>
> Honestly speaking I am not sure if we can fix all the races we have identified
> until now, with the current design and the fear of using resources after
> getting
> freed will always be there. Too many corner cases really.
>
> The requirement we have is to make sure no kthread or hrtimer is still in use
> when the ii_dev is freed from idle_injection_unregister().
>
> May be the only sane way to make it work is to call
> smpboot_register_percpu_thread() from idle_injection_register() and then
> unregister those threads from idle_injection_unregister().
nr_threads(smpboot) <> nr_threads(idleinject)
If we are facing races issues, it is because we are trying to avoid
using locks in the code path. With lock and proper refcounting that
should be solved, AFAICT there are similar races with inodes.
Furthermore, hrtimer_forward approach is probably cleaner.
--
Facebook |
Twitter |
Re: [PATCH v2] IB/umem: ib_ucontext already have tgid, remove pid from ib_umem structure
On Wed, Jun 13, 2018 at 12:36 PM, Jason Gunthorpe wrote:
> On Tue, May 08, 2018 at 04:50:16PM +0800, Lidong Chen wrote:
>> The userspace may invoke ibv_reg_mr and ibv_dereg_mr by different threads.
>> If when ibv_dereg_mr invoke and the thread which invoked ibv_reg_mr has
>> exited, get_pid_task will return NULL, ib_umem_release does not decrease
>> mm->pinned_vm. This patch fixes it by use tgid in ib_ucontext struct.
>>
>> Signed-off-by: Lidong Chen
>> ---
>> [v2]
>> - use ib_ucontext tgid instread of tgid in ib_umem structure
>
> I'm looking at this again, and it doesn't seem quite right..
>
>> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
>> index 9a4e899..2b6c9b5 100644
>> --- a/drivers/infiniband/core/umem.c
>> +++ b/drivers/infiniband/core/umem.c
>> @@ -119,7 +119,6 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context,
>> unsigned long addr,
>> umem->length = size;
>> umem->address= addr;
>> umem->page_shift = PAGE_SHIFT;
>> - umem->pid= get_task_pid(current, PIDTYPE_PID);
>> /*
>>* We ask for writable memory if any of the following
>>* access flags are set. "Local write" and "remote write"
>> @@ -132,7 +131,6 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context,
>> unsigned long addr,
>>IB_ACCESS_REMOTE_ATOMIC | IB_ACCESS_MW_BIND));
>>
>> if (access & IB_ACCESS_ON_DEMAND) {
>> - put_pid(umem->pid);
>> ret = ib_umem_odp_get(context, umem, access);
>> if (ret) {
>> kfree(umem);
>> @@ -148,7 +146,6 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context,
>> unsigned long addr,
>>
>> page_list = (struct page **) __get_free_page(GFP_KERNEL);
>> if (!page_list) {
>> - put_pid(umem->pid);
>> kfree(umem);
>> return ERR_PTR(-ENOMEM);
>> }
>
> in ib_umem_get we are doing this:
>
> down_write(>mm->mmap_sem);
> locked = npages + current->mm->pinned_vm;
>
> And then in release we now do:
>
> task = get_pid_task(umem->context->tgid, PIDTYPE_PID);
> if (!task)
> goto out;
> mm = get_task_mm(task);
> mm->pinned_vm -= diff;
>
> But there is no guarantee that context->tgid and 'current' are the
> same thing during ib_umem_get..
context->tgid and current maybe different. but different threads in one
process should point to one mm structure. so it should works for multithread.
>
> So in the dysfunctional case where someone forks and keeps the context
> FD open on both sides of the fork they can cause the pinned_vm
> counter to become wrong in the processes. Sounds bad..
I am not sure about fork support, I will check this problem.
>
> Thus, I think we need to go back to storing the tgid in the ib_umem
> and just fix it to store the group leader not the thread PID?
>
> And then even more we need the ib_get_mr_mm() helper to make sense of
> this, because all the drivers are doing the wrong thing by using the
> context->tgid too.
>
> Is that all right?
>
> Jason
Re: [PATCH 3/3] rtc: ftrtc010: let the core handle range
On 13/06/2018 11:10:35+0200, Linus Walleij wrote: > On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni > wrote: > > The current range handling is highly suspicious. Anyway, let the core > > handle it. > > Hmmm. I have datasheets, do you need some input about the hardware? > Something I should patch? > Nothing to do as you seemed to confirm what I did was OK. I could find why it was set to 2148 in the first place. Maybe it correspond to the default days, hours minutes, second values on the SoC. > > The RTC has a 32 bit counter on top of days + hh:mm:ss registers. > > > > Signed-off-by: Alexandre Belloni > > Acked-by: Linus Walleij > > Yours, > Linus Walleij -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
Hi Liang, Thank you for the patch! Yet something to improve: [auto build test ERROR on mtd/nand/next] [also build test ERROR on v4.17 next-20180613] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Yixun-Lan/mtd-rawnand-meson-add-Amlogic-NAND-driver-support/20180613-161917 base: git://git.infradead.org/linux-mtd.git nand/next config: i386-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> drivers/mtd/nand/raw/meson_nand.c:21:10: fatal error: clk-regmap.h: No such >> file or directory #include "clk-regmap.h" ^~ compilation terminated. vim +21 drivers/mtd/nand/raw/meson_nand.c > 21 #include "clk-regmap.h" 22 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v3 4/6] dmaengine: imx-sdma: remove usless lock
On Mon, Jun 11, 2018 at 10:59:31PM +0800, Robin Gong wrote:
> No need anymore for 'lock' now since virtual dma will provide
> the common lock instead.
This can be merged into the last patch, maybe rephrasing the commit
message from "revert..." to what is being done. To me "revert" sounds
like the commit was wrong, but it wasn't at that time.
Sascha
>
> Signed-off-by: Robin Gong
> ---
> drivers/dma/imx-sdma.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index e0af8ee..f150b38 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -349,7 +349,6 @@ struct sdma_channel {
> unsigned long event_mask[2];
> unsigned long watermark_level;
> u32 shp_addr, per_addr;
> - spinlock_t lock;
> enum dma_status status;
> struct imx_dma_data data;
> };
> @@ -1907,7 +1906,6 @@ static int sdma_probe(struct platform_device *pdev)
> struct sdma_channel *sdmac = >channel[i];
>
> sdmac->sdma = sdma;
> - spin_lock_init(>lock);
>
> sdmac->channel = i;
> sdmac->vc.desc_free = sdma_desc_free;
> --
> 2.7.4
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [GIT PULL] KVM changes for 4.18 merge window
On Wed, 13 Jun 2018 at 12:53, Linus Torvalds wrote: > > On Tue, Jun 12, 2018 at 9:49 PM Greg Kroah-Hartman > wrote: > I'm going to be start traveling towards Japan and China tomorrow > morning, so I wanted to just get the problems I noticed out of my Great!, welcome to our country(China), and looking forward to see you at Linux Conf. :) Regards, Wanpeng Li
Re: [PATCH v4 2/6] dt-bindings: add binding for atmel-usart in SPI mode
On Fri, 25 May 2018, Radu Pirea wrote:
> This patch moves the bindings for serial from serial/atmel-usart.txt to
> mfd/atmel-usart.txt and adds bindings for USART in SPI mode.
>
> Signed-off-by: Radu Pirea
> ---
> .../bindings/{serial => mfd}/atmel-usart.txt | 25 +--
> 1 file changed, 23 insertions(+), 2 deletions(-)
> rename Documentation/devicetree/bindings/{serial => mfd}/atmel-usart.txt
> (76%)
For my own reference:
Acked-for-MFD-by: Lee Jones
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH] mtd: spi-nor: Support controllers with limited TX FIFO size
Some SPI controllers can't write nor->page_size bytes in a single
step because their TX FIFO is too small.
Allow nor->write() to return a size that is smaller than the requested
write size to gracefully handle this case.
Signed-off-by: Yogesh Gaur
---
drivers/mtd/spi-nor/spi-nor.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 5bfa36e..3e63543 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1431,13 +1431,6 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t
to, size_t len,
goto write_err;
*retlen += written;
i += written;
- if (written != page_remain) {
- dev_err(nor->dev,
- "While writing %zu bytes written %zd bytes\n",
- page_remain, written);
- ret = -EIO;
- goto write_err;
- }
}
write_err:
--
2.7.4
Patch is based on the spi-mem framework[1]
[1]https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/log/?h=for-4.18
[PATCH 2/2] iio: adc: Add Spreadtrum SC27XX PMICs ADC support
From: Freeman Liu
The Spreadtrum SC27XX PMICs ADC controller contains 32 channels,
which is used to sample voltages with 12 bits conversion.
Signed-off-by: Freeman Liu
Signed-off-by: Baolin Wang
---
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/sc27xx_adc.c | 558 ++
3 files changed, 569 insertions(+)
create mode 100644 drivers/iio/adc/sc27xx_adc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 9da7907..985b73e 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -621,6 +621,16 @@ config ROCKCHIP_SARADC
To compile this driver as a module, choose M here: the
module will be called rockchip_saradc.
+config SC27XX_ADC
+ tristate "Spreadtrum SC27xx series PMICs ADC"
+ depends on MFD_SC27XX_PMIC || COMPILE_TEST
+ help
+ Say yes here to build support for the integrated ADC inside the
+ Spreadtrum SC27xx series PMICs.
+
+ This driver can also be built as a module. If so, the module
+ will be called sc27xx_adc.
+
config SPEAR_ADC
tristate "ST SPEAr ADC"
depends on PLAT_SPEAR || COMPILE_TEST
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 28a9423..03db7b5 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
obj-$(CONFIG_QCOM_PM8XXX_XOADC) += qcom-pm8xxx-xoadc.o
obj-$(CONFIG_RCAR_GYRO_ADC) += rcar-gyroadc.o
obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
+obj-$(CONFIG_SC27XX_ADC) += sc27xx_adc.o
obj-$(CONFIG_SPEAR_ADC) += spear_adc.o
obj-$(CONFIG_STX104) += stx104.o
obj-$(CONFIG_SUN4I_GPADC) += sun4i-gpadc-iio.o
diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
new file mode 100644
index 000..d74310a
--- /dev/null
+++ b/drivers/iio/adc/sc27xx_adc.c
@@ -0,0 +1,558 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Spreadtrum Communications Inc.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PMIC global registers definition */
+#define SC27XX_MODULE_EN 0xc08
+#define SC27XX_MODULE_ADC_EN BIT(5)
+#define SC27XX_ARM_CLK_EN 0xc10
+#define SC27XX_CLK_ADC_EN BIT(5)
+#define SC27XX_CLK_ADC_CLK_EN BIT(6)
+
+/* ADC controller registers definition */
+#define SC27XX_ADC_CTL 0x0
+#define SC27XX_ADC_CH_CFG 0x4
+#define SC27XX_ADC_DATA0x4c
+#define SC27XX_ADC_INT_EN 0x50
+#define SC27XX_ADC_INT_CLR 0x54
+#define SC27XX_ADC_INT_STS 0x58
+#define SC27XX_ADC_INT_RAW 0x5c
+
+/* Bits and mask definition for SC27XX_ADC_CTL register */
+#define SC27XX_ADC_EN BIT(0)
+#define SC27XX_ADC_CHN_RUN BIT(1)
+#define SC27XX_ADC_12BIT_MODE BIT(2)
+#define SC27XX_ADC_RUN_NUM_MASKGENMASK(7, 4)
+#define SC27XX_ADC_RUN_NUM_SHIFT 4
+
+/* Bits and mask definition for SC27XX_ADC_CH_CFG register */
+#define SC27XX_ADC_CHN_ID_MASK GENMASK(4, 0)
+#define SC27XX_ADC_SCALE_MASK GENMASK(10, 8)
+#define SC27XX_ADC_SCALE_SHIFT 8
+
+/* Bits definitions for SC27XX_ADC_INT_EN registers */
+#define SC27XX_ADC_IRQ_EN BIT(0)
+
+/* Bits definitions for SC27XX_ADC_INT_CLR registers */
+#define SC27XX_ADC_IRQ_CLR BIT(0)
+
+/* Mask definition for SC27XX_ADC_DATA register */
+#define SC27XX_ADC_DATA_MASK GENMASK(11, 0)
+
+/* Timeout (ms) for the trylock of hardware spinlocks */
+#define SC27XX_ADC_HWLOCK_TIMEOUT 5000
+
+/* Maximum ADC channel number */
+#define SC27XX_ADC_CHANNEL_MAX 32
+
+/* ADC voltage ratio definition */
+#define SC27XX_VOLT_RATIO(n, d)\
+ (((n) << SC27XX_RATIO_NUMERATOR_OFFSET) | (d))
+#define SC27XX_RATIO_NUMERATOR_OFFSET 16
+#define SC27XX_RATIO_DENOMINATOR_MASK GENMASK(15, 0)
+
+/* Covert ADC values to voltage values */
+#define SC27XX_ADC_TO_VOLTAGE(volt0, volt1, adc0, adc1, value) \
+ ({ \
+ int tmp;\
+ tmp = (volt0) - (volt1);\
+ tmp = tmp * ((value) - (adc1)); \
+ tmp = tmp / ((adc0) - (adc1)); \
+ tmp = tmp + (volt1);\
+ if (tmp < 0)\
+ tmp = 0;\
+ \
+ tmp;\
+ })
+
+struct sc27xx_adc_data {
+ struct device *dev;
+ struct regmap *regmap;
+ /*
+* One hardware spinlock to synchronize between the multiple
+*
[PATCH 1/2] dt-bindings: iio: Add Spreadtrum SC27XX PMICs ADC controller documentation
This patch adds the binding documentation for Spreadtrum SC27XX series
PMICs ADC controller device.
Signed-off-by: Baolin Wang
---
.../bindings/iio/adc/sprd,sc27xx-adc.txt | 36
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
b/Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
new file mode 100644
index 000..8aad960
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
@@ -0,0 +1,36 @@
+Spreadtrum SC27XX series PMICs ADC binding
+
+Required properties:
+- compatible: Should be one of the following.
+ "sprd,sc2720-adc"
+ "sprd,sc2721-adc"
+ "sprd,sc2723-adc"
+ "sprd,sc2730-adc"
+ "sprd,sc2731-adc"
+- reg: The address offset of ADC controller.
+- interrupt-parent: The interrupt controller.
+- interrupts: The interrupt number for the ADC device.
+- #io-channel-cells: Number of cells in an IIO specifier.
+- hwlocks: Reference to a phandle of a hwlock provider node.
+
+Example:
+
+ sc2731_pmic: pmic@0 {
+ compatible = "sprd,sc2731";
+ reg = <0>;
+ spi-max-frequency = <2600>;
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic_adc: adc@480 {
+ compatible = "sprd,sc2731-adc";
+ reg = <0x480>;
+ interrupt-parent = <_pmic>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ #io-channel-cells = <1>;
+ hwlocks = < 4>;
+ };
+ };
--
1.7.9.5
Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen
On 13/06/18 08:13, Oleksandr Andrushchenko wrote:
> On 06/13/2018 09:11 AM, Dmitry Torokhov wrote:
>> On June 12, 2018 10:49:31 PM PDT, Oleksandr Andrushchenko
>> wrote:
>>> On 06/13/2018 02:40 AM, Dmitry Torokhov wrote:
On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
> On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> This is the sync up with the canonical definitions of the input,
>> sound and display protocols in Xen.
>>
>> Changes to kbdif:
>> 1. Add missing string constants for {feature|request}-raw-pointer
>> to align with the rest of the interface file.
>>
>> 2. Add new XenStore feature fields, so it is possible to
>>> individually
>> control set of exposed virtual devices for each guest OS:
>> - set feature-disable-keyboard to 1 if no keyboard device
>>> needs
>> to be created
>> - set feature-disable-pointer to 1 if no pointer device needs
>> to be created
>>
>> 3. Move multi-touch device parameters to backend nodes: these are
>> described as a part of frontend's XenBus configuration nodes
>> while they belong to backend's configuration. Fix this by
>>> moving
>> the parameters to the proper section.
>>
>> Unique-id field:
>> 1. Add unique-id XenBus entry for virtual input and display.
>>
>> 2. Change type of unique-id field to string for sndif to align with
>> display and input protocols.
>>
>> Signed-off-by: Oleksandr Andrushchenko
>>>
>> Cc: Konrad Rzeszutek Wilk
> Reviewed-by: Juergen Gross
>
> I'm fine with this patch being added via the input tree with the
>>> other
> patches. In case I should take it via the Xen tree, please send me a
> note.
Juergen,
I created an immutable branch off v4.17 with these 3 patches in case
>>> you
would want to merge them into your tree without waiting for them to
appear in mainline:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
>>> ib/4.17-xen-kbdfront-runtime-config
Thanks.
>>> Thank you,
>>> I would prefer the fastest path of course
>> It will be part of 4.19 pull request; the immutable branch is for
>> Juergen if he does not want to wait till 4.19 merge window to get the
>> changes.
> Ah, I see. Juergen, can we please merge this via Xen tree then which
> I assume will be faster?
As Dmitry has it already queued in the input tree I think this is fine.
I trust him to take the right decision for which kernel version those
patches are to be queued. They belong to the input tree after all.
Juergen
Re: [PATCH v5 04/13] s390: vfio-ap: base implementation of VFIO AP device driver
On 07/05/2018 17:11, Tony Krowiak wrote:
Introduces a new AP device driver. This device driver
is built on the VFIO mediated device framework. The framework
provides sysfs interfaces that facilitate passthrough
access by guests to devices installed on the linux host.
...snip...
+static int vfio_ap_matrix_dev_create(void)
+{
+ int ret;
+
+ vfio_ap_root_device = root_device_register(VFIO_AP_ROOT_NAME);
+
+ if (IS_ERR(vfio_ap_root_device)) {
+ ret = PTR_ERR(vfio_ap_root_device);
+ goto done;
+ }
+
+ ap_matrix = kzalloc(sizeof(*ap_matrix), GFP_KERNEL);
+ if (!ap_matrix) {
+ ret = -ENOMEM;
+ goto matrix_alloc_err;
+ }
+
+ ap_matrix->device.type = _ap_dev_type;
+ dev_set_name(_matrix->device, "%s", VFIO_AP_DEV_NAME);
+ ap_matrix->device.parent = vfio_ap_root_device;
+ ap_matrix->device.release = vfio_ap_matrix_dev_release;
+ ap_matrix->device.driver = _ap_drv.driver;
+
+ ret = device_register(_matrix->device);
+ if (ret)
+ goto matrix_reg_err;
+
+ goto done;
+
+matrix_reg_err:
+ put_device(_matrix->device);
Did not see this before but here you certainly want to
do a kfree and not a put_device.
+
+matrix_alloc_err:
+ root_device_unregister(vfio_ap_root_device);
+
+done:
+ return ret;
+}
+
+static void vfio_ap_matrix_dev_destroy(struct ap_matrix *ap_matrix)
+{
+ device_unregister(_matrix->device);
+ root_device_unregister(vfio_ap_root_device);
Also here you need a kfree(ap_matrix) too .
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
Re: [PATCH v5 04/13] s390: vfio-ap: base implementation of VFIO AP device driver
On Wed, 13 Jun 2018 09:41:16 +0200
Pierre Morel wrote:
> On 07/05/2018 17:11, Tony Krowiak wrote:
> > Introduces a new AP device driver. This device driver
> > is built on the VFIO mediated device framework. The framework
> > provides sysfs interfaces that facilitate passthrough
> > access by guests to devices installed on the linux host.
> ...snip...
>
> > +static int vfio_ap_matrix_dev_create(void)
> > +{
> > + int ret;
> > +
> > + vfio_ap_root_device = root_device_register(VFIO_AP_ROOT_NAME);
> > +
> > + if (IS_ERR(vfio_ap_root_device)) {
> > + ret = PTR_ERR(vfio_ap_root_device);
> > + goto done;
> > + }
> > +
> > + ap_matrix = kzalloc(sizeof(*ap_matrix), GFP_KERNEL);
> > + if (!ap_matrix) {
> > + ret = -ENOMEM;
> > + goto matrix_alloc_err;
> > + }
> > +
> > + ap_matrix->device.type = _ap_dev_type;
> > + dev_set_name(_matrix->device, "%s", VFIO_AP_DEV_NAME);
> > + ap_matrix->device.parent = vfio_ap_root_device;
> > + ap_matrix->device.release = vfio_ap_matrix_dev_release;
> > + ap_matrix->device.driver = _ap_drv.driver;
> > +
> > + ret = device_register(_matrix->device);
> > + if (ret)
> > + goto matrix_reg_err;
> > +
> > + goto done;
> > +
> > +matrix_reg_err:
> > + put_device(_matrix->device);
>
> Did not see this before but here you certainly want to
> do a kfree and not a put_device.
No, this must not be a kfree. Once you've tried to register something
embedding a struct device with the driver core, you need to use
put_device, as another path may have acquired a reference, even if
registering ultimately failed. See the comment for device_register().
IOW, the code is correct.
>
>
>
> > +
> > +matrix_alloc_err:
> > + root_device_unregister(vfio_ap_root_device);
> > +
> > +done:
> > + return ret;
> > +}
> > +
> > +static void vfio_ap_matrix_dev_destroy(struct ap_matrix *ap_matrix)
> > +{
> > + device_unregister(_matrix->device);
> > + root_device_unregister(vfio_ap_root_device);
>
> Also here you need a kfree(ap_matrix) too .
Same here.
[PATCH 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
The current Wound-Wait mutex algorithm is actually not Wound-Wait but Wait-Die. Implement also Wound-Wait as a per-ww-class choice. Wound-Wait is, contrary to Wait-Die a preemptive algorithm and is known to generate fewer backoffs. Testing reveals that this is true if the number of simultaneous contending transactions is small. As the number of simultaneous contending threads increases, Wait-Wound becomes inferior to Wait-Die in terms of elapsed time. Possibly due to the larger number of held locks of sleeping transactions. Update documentation and callers. Timings using git://people.freedesktop.org/~thomash/ww_mutex_test tag patch-18-06-04 Each thread runs 10 batches of lock / unlock 800 ww mutexes randomly chosen out of 10. Four core Intel x86_64: Algorithm#threads Rollbacks time Wound-Wait 4 ~100 ~17s. Wait-Die 4 ~15~19s. Wound-Wait 16 ~36~109s. Wait-Die 16 ~45~82s. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: David Airlie Cc: Davidlohr Bueso Cc: "Paul E. McKenney" Cc: Josh Triplett Cc: Thomas Gleixner Cc: Kate Stewart Cc: Philippe Ombredanne Cc: Greg Kroah-Hartman Cc: linux-...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Thomas Hellstrom --- Documentation/locking/ww-mutex-design.txt | 57 ++ drivers/dma-buf/reservation.c | 2 +- drivers/gpu/drm/drm_modeset_lock.c| 2 +- include/linux/ww_mutex.h | 19 -- kernel/locking/locktorture.c | 2 +- kernel/locking/mutex.c| 98 --- kernel/locking/test-ww_mutex.c| 2 +- lib/locking-selftest.c| 2 +- 8 files changed, 152 insertions(+), 32 deletions(-) diff --git a/Documentation/locking/ww-mutex-design.txt b/Documentation/locking/ww-mutex-design.txt index 34c3a1b50b9a..29c85623b551 100644 --- a/Documentation/locking/ww-mutex-design.txt +++ b/Documentation/locking/ww-mutex-design.txt @@ -1,4 +1,4 @@ -Wait/Wound Deadlock-Proof Mutex Design +Wound/Wait Deadlock-Proof Mutex Design == Please read mutex-design.txt first, as it applies to wait/wound mutexes too. @@ -32,10 +32,23 @@ the oldest task) wins, and the one with the higher reservation id (i.e. the younger task) unlocks all of the buffers that it has already locked, and then tries again. -In the RDBMS literature this deadlock handling approach is called wait/wound: -The older tasks waits until it can acquire the contended lock. The younger tasks -needs to back off and drop all the locks it is currently holding, i.e. the -younger task is wounded. +In the RDBMS literature, a reservation ticket is associated with a transaction. +and the deadlock handling approach is called Wait-Die. The name is based on +the actions of a locking thread when it encounters an already locked mutex. +If the transaction holding the lock is younger, the locking transaction waits. +If the transaction holding the lock is older, the locking transaction backs off +and dies. Hence Wait-Die. +There is also another algorithm called Wound-Wait: +If the transaction holding the lock is younger, the locking transaction +preempts the transaction holding the lock, requiring it to back off. It +Wounds the other transaction. +If the transaction holding the lock is older, it waits for the other +transaction. Hence Wound-Wait. +The two algorithms are both fair in that a transaction will eventually succeed. +However, the Wound-Wait algorithm is typically stated to generate fewer backoffs +compared to Wait-Die, but is, on the other hand, associated with more work than +Wait-Die when recovering from a backoff. Wound-Wait is also a preemptive +algorithm which requires a reliable way to preempt another transaction. Concepts @@ -47,10 +60,12 @@ Acquire context: To ensure eventual forward progress it is important the a task trying to acquire locks doesn't grab a new reservation id, but keeps the one it acquired when starting the lock acquisition. This ticket is stored in the acquire context. Furthermore the acquire context keeps track of debugging state -to catch w/w mutex interface abuse. +to catch w/w mutex interface abuse. An acquire context is representing a +transaction. W/w class: In contrast to normal mutexes the lock class needs to be explicit for -w/w mutexes, since it is required to initialize the acquire context. +w/w mutexes, since it is required to initialize the acquire context. The lock +class also specifies what algorithm to use, Wound-Wait or Wait-Die. Furthermore there are three different class of w/w lock acquire functions: @@ -90,10 +105,15 @@ provided. Usage - +The algorithm (Wait-Die vs Wound-Wait) is chosen using the _is_wait_die +argument to
[PATCH 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
From: Liang Yang Add initial support for the Amlogic NAND flash controller which found in the Meson-GXBB/GXL/AXG SoCs. Singed-off-by: Liang Yang Signed-off-by: Yixun Lan --- drivers/mtd/nand/raw/Kconfig |8 + drivers/mtd/nand/raw/Makefile |3 + drivers/mtd/nand/raw/meson_nand.c | 1422 + 3 files changed, 1433 insertions(+) create mode 100644 drivers/mtd/nand/raw/meson_nand.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index 19a2b283fbbe..b3c17a3ca8f4 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -534,4 +534,12 @@ config MTD_NAND_MTK Enables support for NAND controller on MTK SoCs. This controller is found on mt27xx, mt81xx, mt65xx SoCs. +config MTD_NAND_MESON + tristate "Support for NAND flash controller on Amlogic's Meson SoCs" + depends on ARCH_MESON || COMPILE_TEST + select COMMON_CLK_REGMAP_MESON + select MFD_SYSCON + help + Enables support for NAND controller on Amlogic's Meson SoCs. + endif # MTD_NAND diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 165b7ef9e9a1..cdf6162f38c3 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 +ccflags-$(CONFIG_MTD_NAND_MESON) += -I$(srctree)/drivers/clk/meson + obj-$(CONFIG_MTD_NAND) += nand.o obj-$(CONFIG_MTD_NAND_ECC) += nand_ecc.o obj-$(CONFIG_MTD_NAND_BCH) += nand_bch.o @@ -56,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_HISI504)+= hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o +obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o nand-objs := nand_base.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_amd.o diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c new file mode 100644 index ..28abc3684772 --- /dev/null +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -0,0 +1,1422 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Amlogic Meson Nand Flash Controller Driver + * + * Copyright (c) 2018 Amlogic, inc. + * Author: Liang Yang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "clk-regmap.h" + +#define NFC_REG_CMD0x00 +#define NFC_REG_CFG0x04 +#define NFC_REG_DADR 0x08 +#define NFC_REG_IADR 0x0c +#define NFC_REG_BUF0x10 +#define NFC_REG_INFO 0x14 +#define NFC_REG_DC 0x18 +#define NFC_REG_ADR0x1c +#define NFC_REG_DL 0x20 +#define NFC_REG_DH 0x24 +#define NFC_REG_CADR 0x28 +#define NFC_REG_SADR 0x2c +#define NFC_REG_PINS 0x30 +#define NFC_REG_VER0x38 + + +#define NFC_CMD_DRD(0x8 << 14) +#define NFC_CMD_IDLE (0xc << 14) +#define NFC_CMD_DWR(0x4 << 14) +#define NFC_CMD_CLE(0x5 << 14) +#define NFC_CMD_ALE(0x6 << 14) +#define NFC_CMD_ADL((0 << 16) | (3 << 20)) +#define NFC_CMD_ADH((1 << 16) | (3 << 20)) +#define NFC_CMD_AIL((2 << 16) | (3 << 20)) +#define NFC_CMD_AIH((3 << 16) | (3 << 20)) +#define NFC_CMD_SEED ((8 << 16) | (3 << 20)) +#define NFC_CMD_M2N((0 << 17) | (2 << 20)) +#define NFC_CMD_N2M((1 << 17) | (2 << 20)) +#define NFC_CMD_RB (1 << 20) +#define NFC_CMD_IO6((0xb << 10) | (1 << 18)) + +#define NFC_RB_USED(1 << 23) +#define NFC_LARGE_PAGE (1 << 22) +#define NFC_RW_OPS (2 << 20) + +#define NAND_TWB_TIME_CYCLE10 + +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages) \ + ( \ + (cmd_dir) | \ + ((ran) << 19) | \ + ((bch) << 14) | \ + ((short_mode) << 13)| \ + (((page_size) & 0x7f) << 6) | \ + ((pages) & 0x3f)\ + ) + +#define GENCMDDADDRL(adl, addr)((adl) | ((addr) & 0x)) +#define GENCMDDADDRH(adh, addr)((adh) | (((addr) >> 16) & 0x)) +#define GENCMDIADDRL(ail, addr)((ail) | ((addr) & 0x)) +#define GENCMDIADDRH(aih, addr)((aih) | (((addr) >> 16) & 0x)) + +#define RB_STA(x) (1 << (26 + x)) + +#define ECC_CHECK_RETURN_FF(-1) + +#define NAND_CE0 (0xe << 10) +#define NAND_CE1
Re: [PATCH v3 0/8] gnss: add new GNSS subsystem
On Tue, Jun 05, 2018 at 11:47:52PM +0200, Pavel Machek wrote: > Hi! > > > > udev solves device discovery pretty well; I don't think that's good > > > thing to optimize for. > > > > It's about grouping related devices together, devices which share some > > common functionality. In this case, providing location data from some > > satellite system. I really don't understand how you can find having a > > class type named "gnss" for this to be controversial in any way. > > We normally group devices by interface, not by functionality. And interfaces also tend to reflect functionality. > > > (And.. I'd really prefer /dev/nmeaX and /dev/sirfX in that situation; > > > and yes that makes it _even easier_ for location service to find right > > > devices). > > > > As I've already explained, you may not know which protocol is currently > > active when the device start and you typically switch from NMEA to a > > vendor protocol during runtime (e.g. for configuration or to access raw > > GNSS data). > > > > Trying to encode the GNSS protocol in the character-device node name is > > just a bad idea. > > I thought idea was to switch to the "best" protocol in kernel. I'm afraid it's not that simple; the vendor protocols are not always supersets of the data and commands provided by the NMEA modes. Apparently, some data is only available in NMEA mode for SiRF devices, for example, so we need to provide some flexibility here. > > > > As mentioned in the cover letter, we may eventually want to add support > > > > for some kinds of configuration from within the kernel (e.g. protocol > > > > and line speed changes). > > > > > > I believe we'll eventually want "real" GPS drivers, with common > > > interface. input was in this situation before... > > > > As we also already discussed, there's nothing preventing you from trying > > to move gpsd into the kernel later. I doubt this is something we want, > > and it may turn out not to be feasible for other reasons. > > Well -- I believe we want "gpsd in kernel". If you take /dev/gnss0 and > drivers/gnss now, where do I put them? The subsystem would still live under drivers/gnss. If there's ever going to be an in-kernel gpsd, then maybe /dev/gnss0 could have been used for it instead (if a character device is even the right interface). I started off with separating the gnss device itself from the raw interface (cf. hid) to allow for something like that, but the more I looked into this the more it seems I was just over-engineering for something that would never be realised. Take a look at some of the papers on the gpsd site about GNSS protocols and the problem of finding a common representation for all the various devices out there. gpsd itself has already gone through three revisions of its internal representation over the past decades. This does not seem like an exercise we want to repeat in the kernel with its rules about backwards compatibility etc. So at least for the time being, I'm convinced that a raw gnss interface is the right one. > > Ok, so I did read the damn thing along with the overview of the N900 GPS > > hardware and reverse-engineered protocol (why didn't you point me to > > those instead?) and I'm still not sure what the point you're trying to > > make is. > > Umm. Where did you find the hardware overview/protocol overview? It looks like Sebastian (and others) once put something together here: https://wiki.maemo.org/N900_Hardware_GPS https://wiki.maemo.org/N900_GPS_Reverse_Engineering > > The n900 service you link to above, parses phonet data, does some > > *floating point* calculations and generates NMEA sentences which it > > feeds to a pseudo terminal whose slave side is opened by gpsd. > > > > That NMEA data could just as easily be fed through a different kernel > > subsystem, namely gnss instead of tty, where it could be accessed > > through a common interface (for now, a raw gnss interface, with some > > associated meta data). [ And from what I can tell, ugnss would also > > allow you to get rid of some hacks related to finding out when the GNSS > > is opened and needs to be powered on. ] > > > > So the ugnss interface looks like it will work for N900 just as it will > > for other phones. > > Not NMEA please. First, NMEA has strange format of latitude/longitude > -- that's those calculations IIRC. NMEA has other problems, too -- > like not atomically providing speeds and accuracies. Plus it is crazy > text protoco with CRCs. Then of course you also have the issue that all of user space would need to be taught to understand this yet-to-be-conceived generic protocol. > > > NMEA would not be my first choice, really. I'd propose something very > > > similar to existing /dev/input/eventX, but with wider data types. > > > > Fine, you pursue that idea if you want then. I can see many problems > > with trying to so, but the point is, this series doesn't prevent you > > from doing so. > > > If you think you'll one day be able
Re: Restartable Sequences system call merged into Linux
On 06/12/2018 06:31 PM, Mathieu Desnoyers wrote:
- On Jun 12, 2018, at 9:11 AM, Florian Weimer fwei...@redhat.com wrote:
On 06/11/2018 10:04 PM, Mathieu Desnoyers wrote:
- On Jun 11, 2018, at 3:55 PM, Florian Weimer fwei...@redhat.com wrote:
On 06/11/2018 09:49 PM, Mathieu Desnoyers wrote:
It should be noted that there can be only one rseq TLS area registered per
thread,
which can then be used by many libraries and by the executable, so this is a
process-wide (per-thread) resource that we need to manage carefully.
Is it possible to resize the area after thread creation, perhaps even
from other threads?
I'm not sure why we would want to resize it. The per-thread area is fixed-size.
Its layout is here: include/uapi/linux/rseq.h: struct rseq
Looks I was mistaken and this is very similar to the robust mutex list.
Should we treat it the same way? Always allocate it for each new thread
and register it with the kernel?
That would be an efficient way to do it, indeed. There is very little
performance overhead to have rseq registered for all threads, whether or
not they intend to run rseq critical sections.
The ABI is designed so that all users (program and libraries) can interact
through this per-thread TLS area.
Then the user code needs just the address of the structure.
Yes.
So we'd add
struct rseq *rseq_location (void);
and be done with it? It would return the address of the thread-local
variable, similar to __errno_location.
Or we could add something like this:
extern __thread struct rseq pthread_rseq_area_np
__attribute__ ((__tls_model__ ("initial-exec")));
But of course only for recent-enough GNU compilers (and Clang, which
identifies itself as GNU).
The advantage of the function call is that it often results in more
compact code. Making the initial-exec nature part of the ABI has the
advantage that the applications could use the fact of the constant
offset to the thread pointer if they desire to do so.
Would we need to document which glibc functions use
pthread_rseq_area_np, so that applications do not call them when they
itself use the area?
Do we actually need to use RSEQ_FLAG_UNREGISTER prior to thread exit?
Why can't the kernel do it for us?
- requires all rseq users to upgrade to newer glibc. Early rseq users
(libs and applications) registering their own rseq TLS will conflict
with newer glibc.
We will need to do something about stack unwinding and longjmp anyway (I
assume the kernel already handles signals for us), so it may not be
possible to use restartable sequences in any substantial way with a
system upgrade anyway.
B) librseq.so exposes a strong __rseq_abi symbol:
- should ideally *not* be global-dynamic for performance reasons, but
testing shows that using initial-exec causes issues in situations where
librseq.so ends up being dlopen'd (e.g. java virtual machine dlopening
the lttng-ust tracer linked against librseq.so),
Just an aside:
You can work around that using preloading. On the glibc side, we could
also make the initial reserve configurable. On 64-bit, there really is
no reason not to use a different TCB allocation scheme which would allow
you to create a few threads before the initial-exec TLS area cannot be
extended.
The existing approach dates back to LinuxThreads and its TCB collocated
with the the stack. But changes in the next few months are not very likely.
C) __rseq_abi symbol declared weak within each user (application, librseq,
other libraries, glibc):
We can multiple two non-weak definitions for the symbol. It should work
as long as only the definition in glibc has a symbol version.
__rseq_abi as a name is problematic because it's in the internal namespace.
Thanks,
Florian
Re: [PATCH] irqchip/gic-v3: do not access GICR_WAKER if its secured register.
On 12/06/18 17:34, Marc Zyngier wrote: I suggest you find out how the GIC has been integrated on this platform. If you take a fault on accessing this register, this very much looks like an integration bug, and it should be quirked as such. Thanks for the suggestion, This is a bug in the firmware which is restricting access to this register. We have been working around this bug for more than 2 years due to this. Now this platform support is in mainline and We/I have no hope that this will be fixed in near future atleast for this platform. I will try to come up with a Quirk specific for this SoC. thanks, srini
Re: [PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
On Wed, Jun 13, 2018 at 05:41:08AM +, Naoya Horiguchi wrote:
> Hi everyone,
>
> I wrote a patch for this issue.
> There was a discussion about prechecking approach, but I finally found
> out it's hard to make change on memblock after numa_init, so I take
> another apporach (see patch description).
>
> I'm glad if you check that it works for you.
>
> Thanks,
> Naoya Horiguchi
> ---
> From: Naoya Horiguchi
> Date: Wed, 13 Jun 2018 12:43:27 +0900
> Subject: [PATCH] mm: zero remaining unavailable struct pages
>
> There is a kernel panic that is triggered when reading /proc/kpageflags
> on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
>
> BUG: unable to handle kernel paging request at fffe
> PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
> Oops: [#1] SMP PTI
> CPU: 2 PID: 1728 Comm: page-types Not tainted
> 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28
> 04/01/2014
> RIP: 0010:stable_page_flags+0x27/0x3c0
> Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89 fc
> 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6 c4 01
> 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
> RSP: 0018:bbd44111fde0 EFLAGS: 00010202
> RAX: fffe RBX: 7fffeff9 RCX:
> RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
> RBP: R08: 0001 R09: 0001
> R10: bbd44111fed8 R11: R12: ed1182fff5c0
> R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
> FS: 7efc4335a500() GS:93a5bfc0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: fffe CR3: b2a58000 CR4: 001406e0
> Call Trace:
>kpageflags_read+0xc7/0x120
>proc_reg_read+0x3c/0x60
>__vfs_read+0x36/0x170
>vfs_read+0x89/0x130
>ksys_pread64+0x71/0x90
>do_syscall_64+0x5b/0x160
>entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7efc42e75e23
> Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00 90
> 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0 ff ff
> 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
>
> According to kernel bisection, this problem became visible due to commit
> f7f99100d8d9 which changes how struct pages are initialized.
>
> Memblock layout affects the pfn ranges covered by node/zone. Consider
> that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
> the default (no memmap= given) memblock layout is like below:
>
> MEMBLOCK configuration:
>memory size = 0x0001fff75c00 reserved size = 0x0300c000
>memory.cnt = 0x4
>memory[0x0] [0x1000-0x0009efff],
> 0x0009e000 bytes on node 0 flags: 0x0
>memory[0x1] [0x0010-0xbffd6fff],
> 0xbfed7000 bytes on node 0 flags: 0x0
>memory[0x2] [0x0001-0x00013fff],
> 0x4000 bytes on node 0 flags: 0x0
>memory[0x3] [0x00014000-0x00023fff],
> 0x0001 bytes on node 1 flags: 0x0
>...
>
> If you give memmap=1G!4G (so it just covers memory[0x2]),
> the range [0x1-0x13fff] is gone:
>
> MEMBLOCK configuration:
>memory size = 0x0001bff75c00 reserved size = 0x0300c000
>memory.cnt = 0x3
>memory[0x0] [0x1000-0x0009efff],
> 0x0009e000 bytes on node 0 flags: 0x0
>memory[0x1] [0x0010-0xbffd6fff],
> 0xbfed7000 bytes on node 0 flags: 0x0
>memory[0x2] [0x00014000-0x00023fff],
> 0x0001 bytes on node 1 flags: 0x0
>...
>
> This causes shrinking node 0's pfn range because it is calculated by
> the address range of memblock.memory. So some of struct pages in the
> gap range are left uninitialized.
>
> We have a function zero_resv_unavail() which does zeroing the struct
> pages outside memblock.memory, but currently it covers only the reserved
> unavailable range (i.e. memblock.memory && !memblock.reserved).
> This patch extends it to cover all unavailable range, which fixes
> the reported issue.
>
> Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
> Signed-off-by: Naoya Horiguchi
> ---
> include/linux/memblock.h | 16
> mm/page_alloc.c | 33 -
> 2 files changed, 24 insertions(+), 25 deletions(-)
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index ca59883c8364..f191e51c5d2a 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -236,22 +236,6 @@ void __next_mem_pfn_range(int *idx, int nid, unsigned
> long *out_start_pfn,
> for_each_mem_range_rev(i, , , \
> nid,
Re: [PATCH 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
Hi Liang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mtd/nand/next]
[also build test ERROR on v4.17 next-20180613]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Yixun-Lan/mtd-rawnand-meson-add-Amlogic-NAND-driver-support/20180613-161917
base: git://git.infradead.org/linux-mtd.git nand/next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sparc64
All error/warnings (new ones prefixed by >>):
In file included from drivers/mtd/nand/raw/meson_nand.c:21:0:
>> drivers/clk/meson/clk-regmap.h:22:16: error: field 'hw' has incomplete type
struct clk_hw hw;
^~
>> drivers/mtd/nand/raw/meson_nand.c:951:2: error: field name not in record or
>> union initializer
.hw.init = &(struct clk_init_data) {
^
drivers/mtd/nand/raw/meson_nand.c:951:2: note: (near initialization for
'sd_emmc_c_ext_clk0_sel')
>> drivers/mtd/nand/raw/meson_nand.c:952:4: error: 'struct clk_init_data' has
>> no member named 'name'
.name = "sd_emmc_c_nand_clk_mux",
^~~~
>> drivers/mtd/nand/raw/meson_nand.c:952:11: warning: excess elements in struct
>> initializer
.name = "sd_emmc_c_nand_clk_mux",
^~~~
drivers/mtd/nand/raw/meson_nand.c:952:11: note: (near initialization for
'(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:953:4: error: 'struct clk_init_data' has
>> no member named 'ops'
.ops = _regmap_mux_ops,
^~~
drivers/mtd/nand/raw/meson_nand.c:953:10: warning: excess elements in struct
initializer
.ops = _regmap_mux_ops,
^
drivers/mtd/nand/raw/meson_nand.c:953:10: note: (near initialization for
'(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:954:4: error: 'struct clk_init_data' has
>> no member named 'parent_names'
.parent_names = sd_emmc_ext_clk0_parent_names,
^~~~
drivers/mtd/nand/raw/meson_nand.c:954:19: warning: excess elements in struct
initializer
.parent_names = sd_emmc_ext_clk0_parent_names,
^
drivers/mtd/nand/raw/meson_nand.c:954:19: note: (near initialization for
'(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:955:4: error: 'struct clk_init_data' has
>> no member named 'num_parents'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~
In file included from include/linux/list.h:9:0,
from include/linux/kobject.h:19,
from include/linux/device.h:16,
from include/linux/platform_device.h:14,
from drivers/mtd/nand/raw/meson_nand.c:9:
>> include/linux/kernel.h:71:25: warning: excess elements in struct initializer
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
^
>> drivers/mtd/nand/raw/meson_nand.c:955:18: note: in expansion of macro
>> 'ARRAY_SIZE'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~
include/linux/kernel.h:71:25: note: (near initialization for '(anonymous)')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
^
>> drivers/mtd/nand/raw/meson_nand.c:955:18: note: in expansion of macro
>> 'ARRAY_SIZE'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~
>> drivers/mtd/nand/raw/meson_nand.c:956:4: error: 'struct clk_init_data' has
>> no member named 'flags'
.flags = CLK_SET_RATE_PARENT,
^
>> drivers/mtd/nand/raw/meson_nand.c:956:12: error: 'CLK_SET_RATE_PARENT'
>> undeclared here (not in a function); did you mean 'DL_STATE_DORMANT'?
.flags = CLK_SET_RATE_PARENT,
^~~
DL_STATE_DORMANT
drivers/mtd/nand/raw/meson_nand.c:956:12: warning: excess elements in struct
initializer
drivers/mtd/nand/raw/meson_nand.c:956:12: note: (near initialization for
'(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:951:37: error: invalid use of undefined
>> type 'struct clk_init_data'
.hw.init = &(struct clk_init_data) {
^
>> drivers/mtd/nand/raw/meson_nand.c:965:12: error: 'CLK_DIVIDER_ROUND_CLOSEST'
>> undeclared here (not in a function); did you mean 'DIV_ROUND_CLOSEST'?
.flags = CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ONE_BASED
Re: [PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
On Wed 13-06-18 05:41:08, Naoya Horiguchi wrote: [...] > From: Naoya Horiguchi > Date: Wed, 13 Jun 2018 12:43:27 +0900 > Subject: [PATCH] mm: zero remaining unavailable struct pages > > There is a kernel panic that is triggered when reading /proc/kpageflags > on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]': > > BUG: unable to handle kernel paging request at fffe > PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0 > Oops: [#1] SMP PTI > CPU: 2 PID: 1728 Comm: page-types Not tainted > 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28 > 04/01/2014 > RIP: 0010:stable_page_flags+0x27/0x3c0 > Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89 fc > 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6 c4 01 > 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7 > RSP: 0018:bbd44111fde0 EFLAGS: 00010202 > RAX: fffe RBX: 7fffeff9 RCX: > RDX: 0001 RSI: 0202 RDI: ed1182fff5c0 > RBP: R08: 0001 R09: 0001 > R10: bbd44111fed8 R11: R12: ed1182fff5c0 > R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10 > FS: 7efc4335a500() GS:93a5bfc0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: fffe CR3: b2a58000 CR4: 001406e0 > Call Trace: >kpageflags_read+0xc7/0x120 >proc_reg_read+0x3c/0x60 >__vfs_read+0x36/0x170 >vfs_read+0x89/0x130 >ksys_pread64+0x71/0x90 >do_syscall_64+0x5b/0x160 >entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x7efc42e75e23 > Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00 90 > 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0 ff ff > 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24 > > According to kernel bisection, this problem became visible due to commit > f7f99100d8d9 which changes how struct pages are initialized. > > Memblock layout affects the pfn ranges covered by node/zone. Consider > that we have a VM with 2 NUMA nodes and each node has 4GB memory, and > the default (no memmap= given) memblock layout is like below: > > MEMBLOCK configuration: >memory size = 0x0001fff75c00 reserved size = 0x0300c000 >memory.cnt = 0x4 >memory[0x0] [0x1000-0x0009efff], > 0x0009e000 bytes on node 0 flags: 0x0 >memory[0x1] [0x0010-0xbffd6fff], > 0xbfed7000 bytes on node 0 flags: 0x0 >memory[0x2] [0x0001-0x00013fff], > 0x4000 bytes on node 0 flags: 0x0 >memory[0x3] [0x00014000-0x00023fff], > 0x0001 bytes on node 1 flags: 0x0 >... > > If you give memmap=1G!4G (so it just covers memory[0x2]), > the range [0x1-0x13fff] is gone: > > MEMBLOCK configuration: >memory size = 0x0001bff75c00 reserved size = 0x0300c000 >memory.cnt = 0x3 >memory[0x0] [0x1000-0x0009efff], > 0x0009e000 bytes on node 0 flags: 0x0 >memory[0x1] [0x0010-0xbffd6fff], > 0xbfed7000 bytes on node 0 flags: 0x0 >memory[0x2] [0x00014000-0x00023fff], > 0x0001 bytes on node 1 flags: 0x0 >... > > This causes shrinking node 0's pfn range because it is calculated by > the address range of memblock.memory. So some of struct pages in the > gap range are left uninitialized. > > We have a function zero_resv_unavail() which does zeroing the struct > pages outside memblock.memory, but currently it covers only the reserved > unavailable range (i.e. memblock.memory && !memblock.reserved). > This patch extends it to cover all unavailable range, which fixes > the reported issue. Thanks for pin pointing this down Naoya! I am wondering why we cannot simply mark the excluded ranges to be reserved instead. -- Michal Hocko SUSE Labs
Re: [PATCHv4 1/3] scripts: Preprocess module-common.lds
Laura Abbott writes: > On 06/11/2018 11:03 PM, Michael Ellerman wrote: >> kbuild test robot writes: ... >>> All errors (new ones prefixed by >>): >>> > ld: cannot open linker script file scripts/module-common.lds: No such > file or directory >> >> This seems to need the following. >> >> diff --git a/Makefile b/Makefile >> index 73f0bb2c7a98..55a5725b6606 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -425,7 +425,7 @@ KBUILD_AFLAGS_KERNEL := >> KBUILD_CFLAGS_KERNEL := >> KBUILD_AFLAGS_MODULE := -DMODULE >> KBUILD_CFLAGS_MODULE := -DMODULE >> -KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds >> +KBUILD_LDFLAGS_MODULE := -T $(objtree)/scripts/module-common.lds >> LDFLAGS := >> GCC_PLUGINS_CFLAGS := > > Thanks for pointing that out. I think I missed that when refactoring. > I'll fix that in the next version plus adding your powerpc patch. Thanks. cheers
Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT
On 06/12/2018 04:11 PM, Jason Baron wrote: > > > On 06/12/2018 03:46 AM, Michal Hocko wrote: >> On Mon 11-06-18 12:23:58, Jason Baron wrote: >>> On 06/11/2018 11:03 AM, Michal Hocko wrote: So can we start discussing whether we want to allow MADV_DONTNEED on mlocked areas and what downsides it might have? Sure it would turn the strong mlock guarantee to have the whole vma resident but is this acceptable for something that is an explicit request from the owner of the memory? >>> >>> If its being explicity requested by the owner it makes sense to me. I >>> guess there could be a concern about this breaking some userspace that >>> relied on MADV_DONTNEED not freeing locked memory? >> >> Yes, this is always the fear when changing user visible behavior. I can >> imagine that a userspace allocator calling MADV_DONTNEED on free could >> break. The same would apply to MLOCK_ONFAULT/MCL_ONFAULT though. We >> have the new flag much shorter so the probability is smaller but the >> problem is very same. So I _think_ we should treat both the same because >> semantically they are indistinguishable from the MADV_DONTNEED POV. Both >> remove faulted and mlocked pages. Mlock, once applied, should guarantee >> no later major fault and MADV_DONTNEED breaks that obviously. I think more concerning than guaranteeing no later major fault is possible data loss, e.g. replacing data with zero-filled pages. The madvise manpage is also quite specific about not allowing MADV_DONTNEED and MADV_FREE for locked pages. So I don't think we should risk changing that for all mlocked pages. Maybe we can risk MCL_ONFAULT, since it's relatively new and has few users? >> So the more I think about it the more I am worried about this but I am >> more and more convinced that making ONFAULT special is just a wrong way >> around this. >> > > Ok, I share the concern that there is a chance that userspace is relying > on MADV_DONTNEED not free'ing locked memory. In that case, what if we > introduce a MADV_DONTNEED_FORCE, which does everything that > MADV_DONTNEED currently does but in addition will also free mlock areas. > That way there is no concern about breaking something. A new niche case flag? Sad :( BTW I didn't get why we should allow this for MADV_DONTNEED but not MADV_FREE. Can you expand on that? > Thanks, > > -Jason > -- > To unsubscribe from this list: send the line "unsubscribe linux-api" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[lkp-robot] [rcutorture] 46e26223e3: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_stats_print
FYI, we noticed the following commit (built with gcc-4.9):
commit: 46e26223e39c64763e321f229e324be15179c505 ("rcutorture: Make boost test
more robust")
url:
https://github.com/0day-ci/linux/commits/Joel-Fernandes/rcutorture-Disable-RT-throttling-for-boost-tests/20180611-074731
base: https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git
rcu/next
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 320M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
++++
||
c71f2f97e9 | 46e26223e3 |
++++
| boot_successes | 0
| 0 |
| boot_failures | 16
| 12 |
| WARNING:suspicious_RCU_usage | 16
| 12 |
| lib/test_rhashtable.c:#suspicious_rcu_dereference_protected()usage | 16
| 12 |
| BUG:workqueue_lockup-pool | 5
||
| INFO:task_blocked_for_more_than#seconds| 5
| 3 |
| WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_stats_print| 0
| 12 |
| EIP:rcu_torture_stats_print| 0
| 12 |
++++
[ 74.158185] WARNING: CPU: 0 PID: 41 at kernel/rcu/rcutorture.c:1324
rcu_torture_stats_print+0x443/0x520
[ 74.160583] CPU: 0 PID: 41 Comm: rcu_torture_sta Not tainted
4.17.0-rc1-00151-g46e2622 #1
[ 74.161981] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 74.163331] EIP: rcu_torture_stats_print+0x443/0x520
[ 74.164187] EFLAGS: 00010202 CPU: 0
[ 74.164775] EAX: 7a8dcaa0 EBX: ECX: 0001 EDX:
[ 74.165755] ESI: 8979df34 EDI: 7a607f32 EBP: 8979df6c ESP: 8979dee0
[ 74.166780] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068
[ 74.167668] CR0: 80050033 CR2: 0806e270 CR3: 0ecc6000 CR4: 0690
[ 74.168721] Call Trace:
[ 74.169145] ? schedule_timeout+0x286/0x6d0
[ 74.169913] rcu_torture_stats+0x34/0x80
[ 74.170576] kthread+0xe0/0x110
[ 74.171105] ? rcu_torture_stats_print+0x520/0x520
[ 74.171900] ? __kthread_bind_mask+0x40/0x40
[ 74.172718] ret_from_fork+0x2e/0x38
[ 74.173313] Code: 04 c7 04 24 f9 1a 5f 7a e8 64 01 ff ff ff 05 28 bc 26 7b
31 c9 ba 01 00 00 00 b8 a0 ca 8d 7a c7 04 24 01 00 00 00 e8 fd 89 05 00 <0f> 0b
31 c9 ba 01 00 00 00 b8 88 ca 8d 7a c7 04 24 01 00 00 00
[ 74.176618] irq event stamp: 138
[ 74.177169] hardirqs last enabled at (137): [<790c173d>]
console_unlock+0x49d/0x6a0
[ 74.178459] hardirqs last disabled at (138): [<7a1a2a1c>]
common_exception+0x46/0x66
[ 74.179719] softirqs last enabled at (120): [<7a1a4b60>]
__do_softirq+0x4b0/0x57d
[ 74.181013] softirqs last disabled at (89): [<7901e76c>]
call_on_stack+0x4c/0x60
[ 74.182450] ---[ end trace 834273b866f313c1 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.17.0-rc1 Kernel Configuration
#
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
Re: ACPI support in common clock framework
+Cc: Rafael, ACPI ML On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam wrote: > Hi Michael, Stephen, > > We are adding ACPI support in our Linux based platform. > At present our clock hierarchy using common clock framework through DTS. > Now we required ACPI support in common clock framework to upgrade our > platform. > > For example, clk_get API called in many drivers to get clock device is > tightly coupled with DT framework. > > Please let us know, if anybody in Open Source community have plans to > add ACPI support for common clock framework. > If not please suggest us alternative method to use common clock > framework in ACPI use case. > > Thanks in advance. > > Regards, > Srinath. -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 2/5] dt: qcom: 8996: thermal: Move to DT initialisation
On Tue, Jun 12, 2018 at 10:35 PM, Bjorn Andersson
wrote:
> On Tue 12 Jun 03:54 PDT 2018, Amit Kucheria wrote:
>
>> We also split up the regmap address space into two, one for the TM
>> registers, the other for the SROT registers. This was required to deal with
>> different address offsets for the TM and SROT registers across different
>> SoC families.
>>
>> Since tsens-common.c/init_common() currently only registers one address
>> space, the order is important (TM before SROT).This is OK since the code
>> doesn't really use the SROT functionality yet.
>
> Please line wrap this.
>
>>
>> Signed-off-by: Amit Kucheria
>> ---
>> arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 +++-
>> drivers/thermal/qcom/tsens-8996.c | 1 -
>> 2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> index 410ae78..b4aab18 100644
>> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> @@ -451,7 +451,17 @@
>>
>> tsens0: thermal-sensor@4a8000 {
>> compatible = "qcom,msm8996-tsens";
>> - reg = <0x4a8000 0x2000>;
>> + reg = <0x4a9000 0x1000>, /* TM */
>> + <0x4a8000 0x1000>; /* SROT */
>> + #qcom,sensors = <13>;
>> + #thermal-sensor-cells = <1>;
>> + };
>> +
>> + tsens1: thermal-sensor@4ac000 {
>> + compatible = "qcom,msm8996-tsens";
>> + reg = <0x4ad000 0x1000>, /* TM */
>> + <0x4ac000 0x1000>; /* SROT */
>> + #qcom,sensors = <8>;
>> #thermal-sensor-cells = <1>;
>> };
>>
>> diff --git a/drivers/thermal/qcom/tsens-8996.c
>> b/drivers/thermal/qcom/tsens-8996.c
>> index e1f7781..6e59078 100644
>> --- a/drivers/thermal/qcom/tsens-8996.c
>> +++ b/drivers/thermal/qcom/tsens-8996.c
>> @@ -79,6 +79,5 @@ static const struct tsens_ops ops_8996 = {
>> };
>>
>> const struct tsens_data data_8996 = {
>> - .num_sensors= 13,
>
> This will cause the current 8996 dts to fail probing the tsens. I think
> you should just leave this as is, because specifying qcom,sensors in dts
> will overwrite this number regardless.
Ack, I didn't consider backword compatility of the code with the
current dts. Will fix.
> It also would make this change dts specific, which is convenient as it
> breaks the interdependency between the different subsystems.
>
>> .ops= _8996,
>
> Regards,
> Bjorn
Re: [PATCH V6] powercap/drivers/idle_injection: Add an idle injection framework
On 12-06-18, 14:59, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 02:00:11PM +0200, Daniel Lezcano wrote:
> > +struct idle_injection_device {
>
> remove this:
> > + cpumask_var_t cpumask;
>
> > + struct hrtimer timer;
> > + struct completion stop_complete;
> > + unsigned int idle_duration_ms;
> > + unsigned int run_duration_ms;
> > + atomic_t count;
>
> add:
> unsigned long cpumask[0];
> > +};
>
>
> > +static struct idle_injection_device *ii_dev_alloc(void)
> > +{
> > + struct idle_injection_device *ii_dev;
> > +
> > + ii_dev = kzalloc(sizeof(*ii_dev), GFP_KERNEL);
>
> use:
>
> sizeof(*ii_dev) + cpumask_size()
>
> > + if (!ii_dev)
> > + return NULL;
> > +
>
> delete:
>
> > + if (!alloc_cpumask_var(_dev->cpumask, GFP_KERNEL)) {
> > + kfree(ii_dev);
> > + return NULL;
> > + }
> > +
> > + return ii_dev;
> > +}
>
> And use:
>
> to_cpumask(ii_dev->cpumask)
What's the benefit of these changes? Is it just about not allocating memory
twice or more than that ?
And what could we do in situations where we need two cpumask variables (we have
a case in cpufreq core for that) ?
--
viresh
Re: [PATCH] PM / core: Fix supplier device runtime PM usage counter imbalance
On 13 June 2018 at 08:42, Marek Szyprowski wrote: > Hi Ulf, > > On 2018-06-12 21:43, Ulf Hansson wrote: >> On 12 June 2018 at 14:44, Marek Szyprowski wrote: >>> On 2018-06-12 13:00, Rafael J. Wysocki wrote: From: Rafael J. Wysocki If a device link is added via device_link_add() by the driver of the link's consumer device, the supplier's runtime PM usage counter is going to be dropped by the pm_runtime_put_suppliers() call in driver_probe_device(). However, in that case it is not incremented unless the supplier driver is already present and the link is not stateless. That leads to a runtime PM usage counter imbalance for the supplier device in a few cases. To prevent that from happening, bump up the supplier runtime PM usage counter in device_link_add() for all links with the DL_FLAG_PM_RUNTIME flag set that are added at the consumer probe time. Use pm_runtime_get_noresume() for that as the callers of device_link_add() who want the supplier to be resumed by it should pass DL_FLAG_RPM_ACTIVE in flags to it anyway. Fixes: 21d5c57b3726 (PM / runtime: Use device links) Reported-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki --- This is a replacement for commit 1e8378619841 (PM / runtime: Fixup reference counting of device link suppliers at probe) that is going to be reverted. >>> Thanks Rafael for the patch. I've applied it and now I'm a bit puzzled. >>> Let's get back to my IOMMU and codec case, mentioned here: >>> https://marc.info/?l=linux-pm=152878741527962=2 >>> >>> Now, after applying your patch, when IOMMU creates a link with >>> DL_FLAG_PM_RUNTIME to the jpeg device (this happens when jpeg device is >>> being probed), it is not IOMMU is not runtime resumed anymore (that's >>> because the patch changes pm_runtime_get_sync to pm_runtime_get_noresume). >> According to your earlier replies, I thought this is what you wanted. No? >> >>> This means that until jpeg driver enables runtime pm for its device and >>> finally performs runtime pm suspends/resume cycle, the supplier won't be >>> resumed. >> What's the problem with that? > > Wasted power. IOMMU device is left enabled until first use of JPEG device, > what means that respective power domain is also turned on unnecessarily. I understand the PM domain (genpd) gets powered on during probe, for the respective device. Now, that shouldn't be a problem, because, if the driver enables runtime PM and leaves its device in runtime suspend state when probe is complete, then when driver core invokes the dev->pm_domain->sync() callback (set to genpd_dev_pm_sync()), genpd should be able to power off the PM domain. > >> When does the IOMMU device needs to be >> runtime resumed? > > I would like to have IOMMU (supplier) runtime active all the time the JPEG > (consumer) device is runtime active AND all the time between probe() and > remove() if JPEG (consumer) doesn't support runtime PM (if it doesn't > enable runtime PM at all). Right, that explains why you need the existing behavior. Thanks for clarifying! I do see an opportunity for optimizations here, as clearly there are cases when you don't need the supplier, the IOMMU device, to be runtime resumed during link creation. However, currently this seems not feasible, as exynos_iommu_add_device() is called from a bus notifier, when the jpeg device is added. The point is, exynos_iommu_add_device() has no clue whether runtime PM is or will become enabled for the supplier device. Thus using DL_FLAG_RPM_ACTIVE is needed. To address this, I think the device link creation needs to be closer managed by the jpeg driver, somehow. > >>> On the other hand, when I add DL_FLAG_RPM_ACTIVE flag to link >>> creation, the supplier is properly resumed, but then, once the jpeg >>> device probe finishes, the supplier is still in runtime active state >>> until a next runtime suspend/resume cycle of jpeg device. >> Could you elaborate on the what happens in jpeg driver during probe, >> in regards to runtime PM. Perhaps you can also point me to what driver >> it is? > > s5p_jpeg_probe() doesn't touch hardware at all and only calls > pm_runtime_enable(), > see drivers/media/platform/s5p-jpeg/jpeg-core.c Thanks! > >>> If I understand >>> right, the DL_FLAG_RPM_ACTIVE flag should be there from the beginning, >>> but that time it runtime pm part of links worked in a bit different way >>> than now. >> Just to make sure, you also reverted 1e8378619841, before trying >> Rafael's change on top? > > Yes Great! > >>> Is there any way to keep old behavior? >> I think the old behavior is sub-optimal. I am sure there are users >> that really don't want the driver core to runtime resume the supplier >> unconditionally. >> >> I would rather go and fix the few users of device_link_add(), to use >> DL_FLAG_RPM_ACTIVE, in cases when they need it. Of course I am fine if >> we do these changes in a step by step basis
Re: [PATCH] PM / core: Fix supplier device runtime PM usage counter imbalance
[...]
> ---
> From: Rafael J. Wysocki
> Subject: [PATCH v2] PM / core: Fix supplier device runtime PM usage counter
> imbalance
>
> If a device link is added via device_link_add() by the driver of the
> link's consumer device, the supplier's runtime PM usage counter is
> going to be dropped by the pm_runtime_put_suppliers() call in
> driver_probe_device(). However, in that case it is not incremented
> unless the supplier driver is already present and the link is not
> stateless. That leads to a runtime PM usage counter imbalance for
> the supplier device in a few cases.
>
> To prevent that from happening, bump up the supplier runtime
> PM usage counter in device_link_add() for all links with the
> DL_FLAG_PM_RUNTIME flag set that are added at the consumer probe
> time. Use pm_runtime_get_noresume() for that as the callers of
> device_link_add() who want the supplier to be resumed by it are
> expected to pass DL_FLAG_RPM_ACTIVE in flags to it anyway, but
> additionally resume the supplier if the link is added during
> consumer driver probe to retain the existing behavior for the
> callers depending on it.
>
> Fixes: 21d5c57b3726 (PM / runtime: Use device links)
> Reported-by: Ulf Hansson
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/base/core.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> Index: linux-pm/drivers/base/core.c
> ===
> --- linux-pm.orig/drivers/base/core.c
> +++ linux-pm/drivers/base/core.c
> @@ -216,6 +216,13 @@ struct device_link *device_link_add(stru
> link->rpm_active = true;
> }
> pm_runtime_new_link(consumer);
> + /*
> +* If the link is being added by the consumer driver at probe
> +* time, balance the decrementation of the supplier's runtime
> PM
> +* usage counter after consumer probe in
> driver_probe_device().
> +*/
> + if (consumer->links.status == DL_DEV_PROBING)
> + pm_runtime_get_noresume(supplier);
> }
> get_device(supplier);
> link->supplier = supplier;
> @@ -235,12 +242,12 @@ struct device_link *device_link_add(stru
> switch (consumer->links.status) {
> case DL_DEV_PROBING:
> /*
> -* Balance the decrementation of the
> supplier's
> -* runtime PM usage counter after consumer
> probe
> -* in driver_probe_device().
> +* Some callers expect the link creation
> during
> +* consumer driver probe to resume the
> supplier
> +* even without DL_FLAG_RPM_ACTIVE.
> */
> if (flags & DL_FLAG_PM_RUNTIME)
> - pm_runtime_get_sync(supplier);
> + pm_runtime_resume(supplier);
>
> link->status = DL_STATE_CONSUMER_PROBE;
> break;
>
[PATCH] mm: cma: honor __GFP_ZERO flag in cma_alloc()
cma_alloc() function has gfp mask parameter, so users expect that it
honors typical memory allocation related flags. The most imporant from
the security point of view is handling of __GFP_ZERO flag, because memory
allocated by this function usually can be directly remapped to userspace
by device drivers as a part of multimedia processing and ignoring this
flag might lead to leaking some kernel structures to userspace.
Some callers of this function (for example arm64 dma-iommu glue code)
already assumed that the allocated buffers are cleared when this flag
is set. To avoid such issues, add simple code for clearing newly
allocated buffer when __GFP_ZERO flag is set. Callers will be then
updated to skip implicit clearing or adjust passed gfp flags.
Signed-off-by: Marek Szyprowski
---
mm/cma.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c
index 5809bbe360d7..1106d5aef2cc 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -464,6 +464,13 @@ struct page *cma_alloc(struct cma *cma, size_t count,
unsigned int align,
start = bitmap_no + mask + 1;
}
+ if (ret == 0 && gfp_mask & __GFP_ZERO) {
+ int i;
+
+ for (i = 0; i < count; i++)
+ clear_highpage(page + i);
+ }
+
trace_cma_alloc(pfn, page, count, align);
if (ret && !(gfp_mask & __GFP_NOWARN)) {
--
2.17.1
Re: [PATCH 1/3] rtc: ftrtc010: switch to devm_rtc_allocate_device
On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni wrote: > Switch to devm_rtc_allocate_device/rtc_register_device. This allow or > further improvement and simplifies ftrtc010_rtc_remove(). > > Signed-off-by: Alexandre Belloni Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 2/3] rtc: ftrtc010: handle dates after 2106
On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni wrote: > Use correct types for offset and time and use > rtc_time64_to_tm/rtc_tm_to_time64 to handle dates after 2106 properly. > > Signed-off-by: Alexandre Belloni Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT
On 06/13/2018 09:15 AM, Michal Hocko wrote: > On Wed 13-06-18 08:32:19, Vlastimil Babka wrote: >> On 06/12/2018 04:11 PM, Jason Baron wrote: >>> >>> >>> On 06/12/2018 03:46 AM, Michal Hocko wrote: On Mon 11-06-18 12:23:58, Jason Baron wrote: > On 06/11/2018 11:03 AM, Michal Hocko wrote: >> So can we start discussing whether we want to allow MADV_DONTNEED on >> mlocked areas and what downsides it might have? Sure it would turn the >> strong mlock guarantee to have the whole vma resident but is this >> acceptable for something that is an explicit request from the owner of >> the memory? >> > > If its being explicity requested by the owner it makes sense to me. I > guess there could be a concern about this breaking some userspace that > relied on MADV_DONTNEED not freeing locked memory? Yes, this is always the fear when changing user visible behavior. I can imagine that a userspace allocator calling MADV_DONTNEED on free could break. The same would apply to MLOCK_ONFAULT/MCL_ONFAULT though. We have the new flag much shorter so the probability is smaller but the problem is very same. So I _think_ we should treat both the same because semantically they are indistinguishable from the MADV_DONTNEED POV. Both remove faulted and mlocked pages. Mlock, once applied, should guarantee no later major fault and MADV_DONTNEED breaks that obviously. >> >> I think more concerning than guaranteeing no later major fault is >> possible data loss, e.g. replacing data with zero-filled pages. > > But MADV_DONTNEED is an explicit call for data loss. Or do I miss your > point? My point is that if somebody is relying on MADV_DONTNEED not affecting mlocked pages, the consequences will be unexpected data loss, not just extra page faults. >> The madvise manpage is also quite specific about not allowing >> MADV_DONTNEED and MADV_FREE for locked pages. > > Yeah, but that seems to describe the state of the art rather than > explain why. Right, but as it's explicitly described there, it makes it more likely that somebody is relying on it. >> So I don't think we should risk changing that for all mlocked pages. >> Maybe we can risk MCL_ONFAULT, since it's relatively new and has few users? > > That is what Jason wanted but I argued that the two are the same from > MADV_DONTNEED point of view. I do not see how treating them differently > would be less confusing or error prone. It's new so we can make it > behave differently is certainly not an argument. Right. Might be either this inconsistency, or a new flag.
Re: Possible regression caused by commit a192aa923b66a
On Wed, Jun 13, 2018 at 4:45 AM, Kai Heng Feng
wrote:
> Hi Rafael,
>
>> On Jun 12, 2018, at 5:17 PM, Rafael J. Wysocki wrote:
>>
>> On Monday, June 11, 2018 11:52:34 PM CEST Rafael J. Wysocki wrote:
>>>
>>> --703623056e64c488
>>> Content-Type: text/plain; charset="UTF-8"
>>>
>>> On Mon, Jun 11, 2018 at 10:09 AM, Rafael J. Wysocki
>>> wrote:
On Mon, Jun 11, 2018 at 8:26 AM, Kai-Heng Feng
wrote:
>
> Hi Rafael,
>
> There's a regression report [1] that says commit a192aa923b66a ("ACPI /
> LPSS: Consolidate runtime PM and system sleep handling") is the first
> bad
> commit.
>
> From the looks of it, it didn't introduce any behavioral change. So
> your
> help is appreciated.
>
> [1] https://bugs.launchpad.net/bugs/1774950
Well, the only difference is the iosf quirk AFAICS, but that should be
easy enough to check. I'll try to cut a patch for that later today.
>>>
>>>
>>> If the iosf quirk is the source of the problem, the attached patch should
>>> help.
>>
>>
>> The one below should be slightly better, please test this one.
>
>
> Affected users reported that this patch solves the issue for them.
OK, thanks for verifying. Let me add a changelog to it and resend it, then.
Thanks,
Rafael
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Fri, 8 Jun 2018 10:42:18 -0700
Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> Allocate agent IDs from a global IDR instead of an atomic variable.
> This eliminates the possibility of reusing an ID which is already in
> use after 4 billion registrations, and we can also limit the assigned
> ID to be less than 2^24, which fixes a bug in the mlx4 device.
>
> We look up the agent under protection of the RCU lock, which means we
> have to free the agent using kfree_rcu, and only increment the
> reference counter if it is not 0.
>
> Signed-off-by: Matthew Wilcox
> ---
> drivers/infiniband/core/mad.c | 78
> ++ drivers/infiniband/core/mad_priv.h |
> 7 +-- include/linux/idr.h| 9
> 3 files changed, 59 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/infiniband/core/mad.c
> b/drivers/infiniband/core/mad.c index 68f4dda916c8..62384a3dd3ec
> 100644 --- a/drivers/infiniband/core/mad.c
> +++ b/drivers/infiniband/core/mad.c
> @@ -38,6 +38,7 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include
> +#include
> #include
> #include
> #include
> @@ -58,8 +59,8 @@ MODULE_PARM_DESC(send_queue_size, "Size of send
> queue in number of work requests module_param_named(recv_queue_size,
> mad_recvq_size, int, 0444); MODULE_PARM_DESC(recv_queue_size, "Size
> of receive queue in number of work requests");
> +static DEFINE_IDR(ib_mad_clients);
> static struct list_head ib_mad_port_list;
> -static atomic_t ib_mad_client_id = ATOMIC_INIT(0);
>
> /* Port list lock */
> static DEFINE_SPINLOCK(ib_mad_port_list_lock);
> @@ -377,13 +378,24 @@ struct ib_mad_agent
> *ib_register_mad_agent(struct ib_device *device, goto error4;
> }
>
> - spin_lock_irq(_priv->reg_lock);
> - mad_agent_priv->agent.hi_tid =
> atomic_inc_return(_mad_client_id);
> + idr_preload(GFP_KERNEL);
> + idr_lock(_mad_clients);
> + ret2 = idr_alloc_cyclic(_mad_clients, mad_agent_priv, 0,
> + (1 << 24), GFP_ATOMIC);
> + idr_unlock(_mad_clients);
> + idr_preload_end();
> +
> + if (ret2 < 0) {
> + ret = ERR_PTR(ret2);
> + goto error5;
> + }
> + mad_agent_priv->agent.hi_tid = ret2;
>
> /*
>* Make sure MAD registration (if supplied)
>* is non overlapping with any existing ones
>*/
> + spin_lock_irq(_priv->reg_lock);
> if (mad_reg_req) {
> mgmt_class =
> convert_mgmt_class(mad_reg_req->mgmt_class); if
> (!is_vendor_class(mgmt_class)) { @@ -394,7 +406,7 @@ struct
> ib_mad_agent *ib_register_mad_agent(struct ib_device *device, if
> (method) { if (method_in_use(,
> mad_reg_req))
> - goto error5;
> + goto error6;
> }
> }
> ret2 = add_nonoui_reg_req(mad_reg_req,
> mad_agent_priv, @@ -410,24 +422,25 @@ struct ib_mad_agent
> *ib_register_mad_agent(struct ib_device *device, if
> (is_vendor_method_in_use( vendor_class,
> mad_reg_req))
> - goto error5;
> + goto error6;
> }
> }
> ret2 = add_oui_reg_req(mad_reg_req,
> mad_agent_priv); }
> if (ret2) {
> ret = ERR_PTR(ret2);
> - goto error5;
> + goto error6;
> }
> }
> -
> - /* Add mad agent into port's agent list */
> - list_add_tail(_agent_priv->agent_list,
> _priv->agent_list); spin_unlock_irq(_priv->reg_lock);
>
> return _agent_priv->agent;
> -error5:
> +error6:
> spin_unlock_irq(_priv->reg_lock);
> + idr_lock(_mad_clients);
> + idr_remove(_mad_clients, mad_agent_priv->agent.hi_tid);
> + idr_unlock(_mad_clients);
> +error5:
> ib_mad_agent_security_cleanup(_agent_priv->agent);
> error4:
> kfree(reg_req);
> @@ -589,8 +602,10 @@ static void unregister_mad_agent(struct
> ib_mad_agent_private *mad_agent_priv)
> spin_lock_irq(_priv->reg_lock);
> remove_mad_reg_req(mad_agent_priv);
> - list_del(_agent_priv->agent_list);
> spin_unlock_irq(_priv->reg_lock);
> + idr_lock(_mad_clients);
> + idr_remove(_mad_clients, mad_agent_priv->agent.hi_tid);
> + idr_unlock(_mad_clients);
>
> flush_workqueue(port_priv->wq);
> ib_cancel_rmpp_recvs(mad_agent_priv);
> @@ -601,7 +616,7 @@ static void unregister_mad_agent(struct
> ib_mad_agent_private *mad_agent_priv)
> ib_mad_agent_security_cleanup(_agent_priv->agent);
> kfree(mad_agent_priv->reg_req);
> - kfree(mad_agent_priv);
> + kfree_rcu(mad_agent_priv, rcu);
> }
>
> static void unregister_mad_snoop(struct ib_mad_snoop_private
>
Re: [PATCH] drivers/of: Add devm_of_iomap()
On Wed, Jun 13, 2018 at 3:18 AM, Benjamin Herrenschmidt wrote: > But there are many other uses of things like of_iomap() which could > benefit from switching to devm_of_iomap() and thus getting the > automated cleanup on exit and appropriate request of the memory > resource. Fine, fine. -- With Best Regards, Andy Shevchenko
Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT
On Wed 13-06-18 09:51:23, Vlastimil Babka wrote: > On 06/13/2018 09:15 AM, Michal Hocko wrote: > > On Wed 13-06-18 08:32:19, Vlastimil Babka wrote: [...] > >> I think more concerning than guaranteeing no later major fault is > >> possible data loss, e.g. replacing data with zero-filled pages. > > > > But MADV_DONTNEED is an explicit call for data loss. Or do I miss your > > point? > > My point is that if somebody is relying on MADV_DONTNEED not affecting > mlocked pages, the consequences will be unexpected data loss, not just > extra page faults. OK, I see your point now. I would consider this an application bug though. Calling MADV_DONTNEED and wondering that the content is gone is, ehm, questionable at best. Why would anybody do that in the first place? Anyway, I think that we cannot change the behavior because of mlockall semantic as mentioned earlier. -- Michal Hocko SUSE Labs
Re: [PATCH] irqchip/gic-v3: do not access GICR_WAKER if its secured register.
On Wed, Jun 13, 2018 at 9:21 AM, Srinivas Kandagatla wrote: > > > On 12/06/18 17:34, Marc Zyngier wrote: >> >> I suggest you find out how the GIC has been integrated on this >> platform. If you take a fault on accessing this register, this very >> much looks like an integration bug, and it should be quirked as such. > > Thanks for the suggestion, This is a bug in the firmware which is > restricting access to this register. We have been working around this bug > for more than 2 years due to this. Now this platform support is in mainline > and We/I have no hope that this will be fixed in near future atleast for > this platform. > >From what you are saying, you were aware of the firmware bug for 2 years as you had work-around from then. I wish the firmware had come up with the fix in those lost 2 years. I understand if it was discovered now, but that doesn't seem to be the case here. Firmware fixes are now becoming inevitable, so the attitude that firmware can't be fixed has to slowing change. I am not saying I am against the quirk, but in general I have seen the firmware support of QCOM parts are really bad. I waited for almost 2 years for PSCI firmware on previous dragonboard where developer are trying to upstream some feature. -- Regards, Sudeep
Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT
On Tue 12-06-18 10:11:33, Jason Baron wrote: [...] > Ok, I share the concern that there is a chance that userspace is relying > on MADV_DONTNEED not free'ing locked memory. In that case, what if we > introduce a MADV_DONTNEED_FORCE, which does everything that > MADV_DONTNEED currently does but in addition will also free mlock areas. What about other types of vmas that are not allowed to MADV_DONTNEED? _FORCE suggests that the user of the API know what he is doing so why shouldn't we allow unmapping hugetlb pages or special PFNMAPS? Or do we want to add MADV_DONTNEED_FORCE_FOR_REAL when somebody comes with another usecase? I agree with Vlastimil that adding new madvise mode for niche case sounds like a bad idea so we should better be sure that a new flag has a reasonable semantic. Just allow mlocked pages is more of a tweak than a proper semantic. So making it force for real requires to analyze what that would mean for other vmas which are excluded now. -- Michal Hocko SUSE Labs
Re: [PATCH 2/2] clk: qcom: Add display clock controller driver for SDM845
Hello Stephen,
Thanks for review.
On 6/12/2018 1:25 PM, Stephen Boyd wrote:
Quoting Taniya Das (2018-06-04 00:56:25)
diff --git a/drivers/clk/qcom/dispcc-sdm845.c b/drivers/clk/qcom/dispcc-sdm845.c
new file mode 100644
index 000..317ab33
--- /dev/null
+++ b/drivers/clk/qcom/dispcc-sdm845.c
@@ -0,0 +1,679 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
Used?
Unused ones I would clean up.
+#include "common.h"
+#include "gdsc.h"
+#include "reset.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
We really need to move this into the header file.
$ git grep '#define F(' -- drivers/clk/qcom/ | wc -l
13
Sure, will move this in a header and submit the patch.
+
[...]
+static const char * const disp_cc_parent_names_4[] = {
+ "bi_tcxo",
+ "dsi0_phy_pll_out_dsiclk",
+ "dsi1_phy_pll_out_dsiclk",
+ "core_bi_pll_test_se",
+};
+
+static const struct alpha_pll_config disp_cc_pll0_config = {
+ .l = 0x2c,
+ .alpha = 0xcaaa,
+};
Any reason this can't be put on the stack in the probe function?
I would move it.
+
+static struct clk_alpha_pll disp_cc_pll0 = {
+ .offset = 0x0,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
+ .clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_pll0",
+ .parent_names = (const char *[]){ "bi_tcxo" },
+ .num_parents = 1,
+ .ops = _alpha_pll_fabia_ops,
+ },
+ },
+};
[...]
+
+static struct clk_rcg2 disp_cc_mdss_pclk0_clk_src = {
+ .cmd_rcgr = 0x2058,
+ .mnd_width = 8,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_4,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_pclk0_clk_src",
+ .parent_names = disp_cc_parent_names_4,
+ .num_parents = 4,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
Why is the nocache flag needed? Applies to all clks in this file.
This flag is required for all RCGs whose PLLs are controlled outside the
clock controller. The display code would require the recalculated rate
always.
+ .ops = _pixel_ops,
+ },
+};
+
+static struct clk_rcg2 disp_cc_mdss_pclk1_clk_src = {
+ .cmd_rcgr = 0x2070,
+ .mnd_width = 8,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_4,
+ .clkr.hw.init = &(struct clk_init_data){
[...]
+
+static const struct regmap_config disp_cc_sdm845_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x1,
This seems arbitrarily large. List the actual end?
The actual end is larger than this :( , I have listed the range till the
register offset are used here.
+ .fast_io= true,
+};
+
+static const struct qcom_cc_desc disp_cc_sdm845_desc = {
+ .config = _cc_sdm845_regmap_config,
+ .clks = disp_cc_sdm845_clocks,
+ .num_clks = ARRAY_SIZE(disp_cc_sdm845_clocks),
+ .resets = disp_cc_sdm845_resets,
+ .num_resets = ARRAY_SIZE(disp_cc_sdm845_resets),
+ .gdscs = disp_cc_sdm845_gdscs,
+ .num_gdscs = ARRAY_SIZE(disp_cc_sdm845_gdscs),
+};
+
+static const struct of_device_id disp_cc_sdm845_match_table[] = {
+ { .compatible = "qcom,sdm845-dispcc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, disp_cc_sdm845_match_table);
+
+static int disp_cc_sdm845_probe(struct platform_device *pdev)
+{
+ struct regmap *regmap;
+
+ regmap = qcom_cc_map(pdev, _cc_sdm845_desc);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ clk_fabia_pll_configure(_cc_pll0, regmap, _cc_pll0_config);
+
+ /* Enable clock gating for DSI and MDP clocks */
Hardware clock gating? What does this mean.
These are used for deciding whether to enable HW based Clock gating or
not. Setting these bit will enable HW based Clock gating.
+ regmap_update_bits(regmap, 0x8000, 0x7f0, 0x7f0);
+
+ return qcom_cc_really_probe(pdev, _cc_sdm845_desc, regmap);
+}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
Re: [PATCH v3 5/6] dmaengine: imx-sdma: remove the maximum limation for bd numbers
In the subject: s/limation/limitation/
Sascha
On Mon, Jun 11, 2018 at 10:59:32PM +0800, Robin Gong wrote:
> No this limitation now after virtual dma used since bd is allocated
> dynamically instead of static.
>
> Signed-off-by: Robin Gong
> ---
> drivers/dma/imx-sdma.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index f150b38..0b0588d2 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -292,7 +292,6 @@ struct sdma_context_data {
> u32 scratch7;
> } __attribute__ ((packed));
>
> -#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
>
> struct sdma_engine;
>
> @@ -1296,13 +1295,6 @@ static struct dma_async_tx_descriptor
> *sdma_prep_slave_sg(
> if (ret)
> goto err_bd_out;
>
> - if (sg_len > NUM_BD) {
> - dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
> exceeded: %d > %d\n",
> - channel, sg_len, NUM_BD);
> - ret = -EINVAL;
> - goto err_bd_out;
> - }
> -
> desc->chn_count = 0;
> for_each_sg(sgl, sg, sg_len, i) {
> struct sdma_buffer_descriptor *bd = >bd[i];
> @@ -1412,12 +1404,6 @@ static struct dma_async_tx_descriptor
> *sdma_prep_dma_cyclic(
> if (ret)
> goto err_bd_out;
>
> - if (num_periods > NUM_BD) {
> - dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
> exceeded: %d > %d\n",
> - channel, num_periods, NUM_BD);
> - goto err_bd_out;
> - }
> -
> if (period_len > 0x) {
> dev_err(sdma->dev, "SDMA channel %d: maximum period size
> exceeded: %zu > %d\n",
> channel, period_len, 0x);
> --
> 2.7.4
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [GIT PULL] Please pull NFS client changes for 4.18
On Wed, Jun 13, 2018 at 11:42:51AM +1000, NeilBrown wrote: > On Tue, Jun 12 2018, Paul E. McKenney wrote: > > > On Tue, Jun 12, 2018 at 06:11:50PM -0700, Linus Torvalds wrote: > >> On Tue, Jun 12, 2018 at 6:02 PM Paul E. McKenney > >> wrote: > >> > > >> > We did review this one, and Neil did make requested changes to the > >> > comment > >> > header and documentation. > >> > >> Oh, I checked the commit for "acked-by" from you and didn't see any, > >> so I was assuming this was just Neil and Trond on their own.. > > > > Hmmm... I gave them a Reviewed-by, but perhaps it got lost. > > > > http://lkml.kernel.org/r/20180501141404.gd26...@linux.vnet.ibm.com > > Sorry about that. I think I planned to add it after I heard back from > Trond what he thought of the patch, but I didn't hear anything until it > landed. I'll try to be more proactive next time. Not a problem from my viewpoint. There may come a time when I need to care about contribution metrics, but I don't need to at the moment. ;-) Thanx, Paul
[PATCH] mtd: devices: m25p80: Make sure WRITE_EN is issued before each write
Some SPI controllers can't write nor->page_size bytes in a single step
because their TX FIFO is too small, but when that happens we should
make sure a WRITE_EN command before each write access and READ_SR command
after each write access is issued.
The core is already taking care of that, so all we have to do here is
return the actual number of bytes that were written during the
spi_mem_exec_op() operation.
Signed-off-by: Yogesh Gaur
---
drivers/mtd/devices/m25p80.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index e84563d..60224fe 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -72,7 +72,6 @@ static ssize_t m25p80_write(struct spi_nor *nor, loff_t to,
size_t len,
SPI_MEM_OP_ADDR(nor->addr_width, to, 1),
SPI_MEM_OP_DUMMY(0, 1),
SPI_MEM_OP_DATA_OUT(len, buf, 1));
- size_t remaining = len;
int ret;
/* get transfer protocols. */
@@ -84,22 +83,16 @@ static ssize_t m25p80_write(struct spi_nor *nor, loff_t to,
size_t len,
if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second)
op.addr.nbytes = 0;
- while (remaining) {
- op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
- ret = spi_mem_adjust_op_size(flash->spimem, );
- if (ret)
- return ret;
-
- ret = spi_mem_exec_op(flash->spimem, );
- if (ret)
- return ret;
+ ret = spi_mem_adjust_op_size(flash->spimem, );
+ if (ret)
+ return ret;
+ op.data.nbytes = len < op.data.nbytes ? len : op.data.nbytes;
- op.addr.val += op.data.nbytes;
- remaining -= op.data.nbytes;
- op.data.buf.out += op.data.nbytes;
- }
+ ret = spi_mem_exec_op(flash->spimem, );
+ if (ret)
+ return ret;
- return len;
+ return op.data.nbytes;
}
/*
--
2.7.4
Patch is based on the spi-mem framework[1]
[1]https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/log/?h=for-4.18
Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT
On Wed 13-06-18 08:32:19, Vlastimil Babka wrote: > On 06/12/2018 04:11 PM, Jason Baron wrote: > > > > > > On 06/12/2018 03:46 AM, Michal Hocko wrote: > >> On Mon 11-06-18 12:23:58, Jason Baron wrote: > >>> On 06/11/2018 11:03 AM, Michal Hocko wrote: > So can we start discussing whether we want to allow MADV_DONTNEED on > mlocked areas and what downsides it might have? Sure it would turn the > strong mlock guarantee to have the whole vma resident but is this > acceptable for something that is an explicit request from the owner of > the memory? > > >>> > >>> If its being explicity requested by the owner it makes sense to me. I > >>> guess there could be a concern about this breaking some userspace that > >>> relied on MADV_DONTNEED not freeing locked memory? > >> > >> Yes, this is always the fear when changing user visible behavior. I can > >> imagine that a userspace allocator calling MADV_DONTNEED on free could > >> break. The same would apply to MLOCK_ONFAULT/MCL_ONFAULT though. We > >> have the new flag much shorter so the probability is smaller but the > >> problem is very same. So I _think_ we should treat both the same because > >> semantically they are indistinguishable from the MADV_DONTNEED POV. Both > >> remove faulted and mlocked pages. Mlock, once applied, should guarantee > >> no later major fault and MADV_DONTNEED breaks that obviously. > > I think more concerning than guaranteeing no later major fault is > possible data loss, e.g. replacing data with zero-filled pages. But MADV_DONTNEED is an explicit call for data loss. Or do I miss your point? > The madvise manpage is also quite specific about not allowing > MADV_DONTNEED and MADV_FREE for locked pages. Yeah, but that seems to describe the state of the art rather than explain why. > So I don't think we should risk changing that for all mlocked pages. > Maybe we can risk MCL_ONFAULT, since it's relatively new and has few users? That is what Jason wanted but I argued that the two are the same from MADV_DONTNEED point of view. I do not see how treating them differently would be less confusing or error prone. It's new so we can make it behave differently is certainly not an argument. > >> So the more I think about it the more I am worried about this but I am > >> more and more convinced that making ONFAULT special is just a wrong way > >> around this. > >> > > > > Ok, I share the concern that there is a chance that userspace is relying > > on MADV_DONTNEED not free'ing locked memory. In that case, what if we > > introduce a MADV_DONTNEED_FORCE, which does everything that > > MADV_DONTNEED currently does but in addition will also free mlock areas. > > That way there is no concern about breaking something. > > A new niche case flag? Sad :( > > BTW I didn't get why we should allow this for MADV_DONTNEED but not > MADV_FREE. Can you expand on that? Well, I wanted to bring this up as well. I guess this would require some more hacks to handle the reclaim path correctly because we do rely on VM_LOCK at many places for the lazy mlock pages culling. -- Michal Hocko SUSE Labs
Re: [RFC 2/2] x86, tsc: Enable clock for ealry printk timestamp
On Wed, Jun 06, 2018 at 05:38:33PM +0800, Feng Tang wrote:
> On Sat, Jun 02, 2018 at 12:12:13AM +0800, Feng Tang wrote:
>
> Hi Peter and all,
>
>
> > Hi Peter and Petr,
> >
> > Thanks for your suggestions, will try to find a cleaner and less hacky way,
> > and it may take some time as dealing with all kinds of TSC is tricky :)
> >
> > - Feng
> >
> > On Thu, May 31, 2018 at 05:52:10PM +0200, Peter Zijlstra wrote:
> > > On Thu, May 31, 2018 at 03:55:42PM +0200, Petr Mladek wrote:
> > > > I wonder if we could get some cleaner integration into the timer and
> > > > printk code.
> > >
> > > Yes, these patches are particularly horrific..
> > >
> > > There were some earlier patches by Pavel Tatashin, which attempted do
> > > get things running earlier.
> > >
> > >
> > > http://lkml.kernel.org/r/20180209211143.16215-1-pasha.tatas...@oracle.com
> > >
> > > I'm not entirely happy with that, but I never did get around to
> > > reviewing that last version :-( In particuarly, now that you made me
> > > look, I dislike his patch 6 almost as much as these patches.
> > >
> > > The idea was to get regular sched_clock() running earlier, not to botch
> > > some early_sched_clock() into it.
> > >
> > > Basically run calibrate_tsc() earlier (like _waaay_ earlier, it doesn't
> > > rely on anything other than CPUID) and if you have a recent part (with
> > > exception of SKX) you'll get a usable tsc rate (and TSC_RELIABLE) and
> > > things will work.
>
>
> I just did a hacky experiment by moving the tsc_init()earlier into
> setup_arch() and remove the tsc_early_delay_calibrate(). The printk stamp
> does start working much earlier!
>
>
> But the __use_tsc and __sched_clock_stable are relying on jump_label,
> which can't be used so early (I tried to call the jump_label_init() before
> tsc_init(), but kernel crashs, and I worked around it for now).
Just figured out the kernel crash when taking jump_label_init() earlier
into setup_arch(), the tsc_init() will enable static_key __use_tsc
static_key_enable
__jump_label_update
arch_jump_label_transform
__jump_label_transform
text_poke_bp
text_poke
text_poke() will involve page , but paging is not initialized so
early yet, so it triggers a panic.
Beside this __use_tsc, the sched_clock also has one static key
__sched_clock_stable
Thanks,
Feng
>
> Please review the debug patch, thanks!
>
> ---
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 5c623df..b636888 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1201,7 +1201,8 @@ void __init setup_arch(char **cmdline_p)
> kvmclock_init();
> #endif
>
> - tsc_early_delay_calibrate();
> + tsc_init();
> +
> if (!early_xdbc_setup_hardware())
> early_xdbc_register_console();
>
> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> index 4008dd6..8288f39 100644
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -33,6 +33,7 @@ EXPORT_SYMBOL(cpu_khz);
> unsigned int __read_mostly tsc_khz;
> EXPORT_SYMBOL(tsc_khz);
>
> +int tsc_inited;
> /*
> * TSC can be unstable due to cpufreq or due to unsynced TSCs
> */
> @@ -192,7 +193,7 @@ static void set_cyc2ns_scale(unsigned long khz, int cpu,
> unsigned long long tsc_
> */
> u64 native_sched_clock(void)
> {
> - if (static_branch_likely(&__use_tsc)) {
> + if (static_branch_likely(&__use_tsc) || tsc_inited) {
> u64 tsc_now = rdtsc();
>
> /* return the value in ns */
> @@ -1387,30 +1391,16 @@ static int __init init_tsc_clocksource(void)
> */
> device_initcall(init_tsc_clocksource);
>
> -void __init tsc_early_delay_calibrate(void)
> -{
> - unsigned long lpj;
> -
> - if (!boot_cpu_has(X86_FEATURE_TSC))
> - return;
> -
> - cpu_khz = x86_platform.calibrate_cpu();
> - tsc_khz = x86_platform.calibrate_tsc();
> -
> - tsc_khz = tsc_khz ? : cpu_khz;
> - if (!tsc_khz)
> - return;
> -
> - lpj = tsc_khz * 1000;
> - do_div(lpj, HZ);
> - loops_per_jiffy = lpj;
> -}
> -
> void __init tsc_init(void)
> {
> u64 lpj, cyc;
> int cpu;
>
> + if (tsc_inited)
> + return;
> +
> + tsc_inited = 1;
> +
> if (!boot_cpu_has(X86_FEATURE_TSC)) {
> setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
> return;
> @@ -1474,11 +1464,15 @@ void __init tsc_init(void)
> lpj = ((u64)tsc_khz * 1000);
> do_div(lpj, HZ);
> lpj_fine = lpj;
> + loops_per_jiffy = lpj;
>
> use_tsc_delay();
>
> check_system_tsc_reliable();
>
> + extern void early_set_sched_clock_stable(u64 sched_clock_offset);
> + early_set_sched_clock_stable(div64_u64(rdtsc() * 1000, tsc_khz));
> +
> if (unsynchronized_tsc()) {
> mark_tsc_unstable("TSCs unsynchronized");
> return;
>
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Tue, Jun 12, 2018 at 05:07:39PM -0700, Matthew Wilcox wrote: > On Tue, Jun 12, 2018 at 02:33:22PM -0600, Jason Gunthorpe wrote: > > > @@ -377,13 +378,24 @@ struct ib_mad_agent *ib_register_mad_agent(struct > > > ib_device *device, > > > goto error4; > > > } > > > > > > - spin_lock_irq(_priv->reg_lock); > > > - mad_agent_priv->agent.hi_tid = atomic_inc_return(_mad_client_id); > > > + idr_preload(GFP_KERNEL); > > > + idr_lock(_mad_clients); > > > + ret2 = idr_alloc_cyclic(_mad_clients, mad_agent_priv, 0, > > > + (1 << 24), GFP_ATOMIC); > > > > I like this series, my only concern is this magic number here, at the > > very least it deserves a big comment explaining why it > > exists.. > > Yes, you're right. Maybe something like this ... > > /* > * The mlx4 driver uses the top byte to distinguish which virtual function > * generated the MAD, so we must avoid using it. > */ > #define AGENT_ID_LIMIT(1 << 24) > > ... > > ret2 = idr_alloc_cyclic(_mad_clients, mad_agent_priv, 0, > AGENT_ID_LIMIT, GFP_ATOMIC); > > > Let me see if I can get someone to give it some test time, I assume > > you haven't been able to test it it? > > I don't have any IB hardware. Frankly I'm scared of Infiniband ;-) I took it for regression, reliable results will be after -rc1 only. Thanks signature.asc Description: PGP signature
Re: [PATCH 3/3] rtc: ftrtc010: let the core handle range
On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni wrote: > The current range handling is highly suspicious. Anyway, let the core > handle it. Hmmm. I have datasheets, do you need some input about the hardware? Something I should patch? > The RTC has a 32 bit counter on top of days + hh:mm:ss registers. > > Signed-off-by: Alexandre Belloni Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH V6] powercap/drivers/idle_injection: Add an idle injection framework
On 13-06-18, 11:03, Daniel Lezcano wrote: > nr_threads(smpboot) <> nr_threads(idleinject) > > If we are facing races issues, it is because we are trying to avoid > using locks in the code path. With lock and proper refcounting that > should be solved, AFAICT there are similar races with inodes. I am not sure if locking can make things better here. We aren't using them as we don't really need them AFAIU :) -- viresh
Re: [PATCH] PM / core: Fix supplier device runtime PM usage counter imbalance
Hi Rafael, On 2018-06-12 16:24, Rafael J. Wysocki wrote: > On Tuesday, June 12, 2018 2:44:23 PM CEST Marek Szyprowski wrote: >> On 2018-06-12 13:00, Rafael J. Wysocki wrote: >>> From: Rafael J. Wysocki >>> >>> If a device link is added via device_link_add() by the driver of the >>> link's consumer device, the supplier's runtime PM usage counter is >>> going to be dropped by the pm_runtime_put_suppliers() call in >>> driver_probe_device(). However, in that case it is not incremented >>> unless the supplier driver is already present and the link is not >>> stateless. That leads to a runtime PM usage counter imbalance for >>> the supplier device in a few cases. >>> >>> To prevent that from happening, bump up the supplier runtime >>> PM usage counter in device_link_add() for all links with the >>> DL_FLAG_PM_RUNTIME flag set that are added at the consumer probe >>> time. Use pm_runtime_get_noresume() for that as the callers of >>> device_link_add() who want the supplier to be resumed by it should >>> pass DL_FLAG_RPM_ACTIVE in flags to it anyway. >>> >>> Fixes: 21d5c57b3726 (PM / runtime: Use device links) >>> Reported-by: Ulf Hansson >>> Signed-off-by: Rafael J. Wysocki >>> --- >>> >>> This is a replacement for commit 1e8378619841 (PM / runtime: Fixup >>> reference counting of device link suppliers at probe) that is going >>> to be reverted. >> Thanks Rafael for the patch. I've applied it and now I'm a bit puzzled. > Thanks for testing! :-) > >> Let's get back to my IOMMU and codec case, mentioned here: >> https://marc.info/?l=linux-pm=152878741527962=2 >> >> Now, after applying your patch, when IOMMU creates a link with >> DL_FLAG_PM_RUNTIME to the jpeg device (this happens when jpeg device is >> being probed), it is not IOMMU is not runtime resumed anymore (that's >> because the patch changes pm_runtime_get_sync to pm_runtime_get_noresume). >> This means that until jpeg driver enables runtime pm for its device and >> finally performs runtime pm suspends/resume cycle, the supplier won't be >> resumed. On the other hand, when I add DL_FLAG_RPM_ACTIVE flag to link >> creation, the supplier is properly resumed, but then, once the jpeg >> device probe finishes, the supplier is still in runtime active state >> until a next runtime suspend/resume cycle of jpeg device. > That additional suspend-resume cycle should not be necessary in theory > unless I'm missing something. > > The pm_request_idle() call in driver_probe_device() should trigger a > suspend of the jpeg device after probe (unless blocked by something) > and that should drop the RPM usage counter of the IOMMU. Next, the > pm_runtime_put_suppliers() in there should actually suspend it. I've also would expect such behavior of PM core, but checks on real hardware gives other results. > It looks like the pm_request_idle() doesn't work as expected. pm_request_idle() calls rpm_idle(), which returns early with -EAGAIN due to (dev->power.runtime_status != RPM_ACTIVE) check. The device runtime_status is RPM_SUSPENDED as initially set by pm_runtime_init() on device creation. Notice that JPEG driver only calls pm_runtime_enable() and nothing more. >> If I understand right, the DL_FLAG_RPM_ACTIVE flag should be there from the >> beginning, but that time it runtime pm part of links worked in a bit >> different way than now. > Right, and evidently there are callers depending on the existing behavior. > >> Is there any way to keep old behavior? > Yes, there is, please test the appended v2 of the $subject patch. > > That said, I'd like to remove the extra supplier resume from there going > forward as there may be callers who actually don't want that to happen and > DL_FLAG_RPM_ACTIVE is there for a purpose. Frankly, if the current behavior matches the designed behavior of DL_FLAG_RPM_ACTIVE flag, then maybe instead of adding workarounds now, we should simply fix all existing callers of device_link_add()? 'git grep' shows only 6 places where links are created with DL_FLAG_PM_RUNTIME flag, I see no problem to add DL_FLAG_RPM_ACTIVE there to keep current behavior after a fix in runtime PM core. The description of DL_FLAG_RPM_ACTIVE should also be a bit updated, because I initially thought that it means that the runtime pm counter on supplier is increased for the whole lifetime of the device link (it is not clear when core will call a corresponding pm_runtime_put()). The other question is what need to be fixed to get proper behavior without the additional suspend/resume cycle mentioned a few paragraphs above. > --- > From: Rafael J. Wysocki > Subject: [PATCH v2] PM / core: Fix supplier device runtime PM usage counter > imbalance > > If a device link is added via device_link_add() by the driver of the > link's consumer device, the supplier's runtime PM usage counter is > going to be dropped by the pm_runtime_put_suppliers() call in > driver_probe_device(). However, in that case it is not incremented > unless the supplier driver is already present
Re: [lkp-robot] [rcutorture] 46e26223e3: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_stats_print
(I'm actually not working this week, but still thought of replying :))
On Wed, Jun 13, 2018 at 02:57:11PM +0800, kernel test robot wrote:
>
> FYI, we noticed the following commit (built with gcc-4.9):
>
> commit: 46e26223e39c64763e321f229e324be15179c505 ("rcutorture: Make boost
> test more robust")
> url:
> https://github.com/0day-ci/linux/commits/Joel-Fernandes/rcutorture-Disable-RT-throttling-for-boost-tests/20180611-074731
> base: https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git
> rcu/next
>
> in testcase: trinity
> with following parameters:
>
> runtime: 300s
>
> test-description: Trinity is a linux system call fuzz tester.
> test-url: http://codemonkey.org.uk/projects/trinity/
I'll try to reproduce this, but it could be because after this patch, the
boost test is actually working.
The reason for the rcutorture test failure could be that the default
kthread_prio for the system's RCU threads is set to 1 (unless overridden by
rcutree.kthread_prio) which is also equal to the priority of the rcutorture's
boost threads. Due to this the rcutorture test could starve the RCU threads
as well and defeat the boosting mechanism. I was able to solve a similar
issue by just passing rcutree.kthread_prio of 50 on the kernel command line.
Paul, would it be ok if we changed the default kthread_prio to something > 1
so that rcutorture can test properly without needing to pass any extra
rcutree.* parameters?
so something like this in kernel/rcu/tree.c ?
static int kthread_prio = IS_ENABLED(CONFIG_RCU_BOOST) ? 2 : 0;
thanks!
- Joel
Re: [PATCH] PM / core: Fix supplier device runtime PM usage counter imbalance
On Tue, Jun 12, 2018 at 9:43 PM, Ulf Hansson wrote: > On 12 June 2018 at 14:44, Marek Szyprowski wrote: [cut] >> >> Is there any way to keep old behavior? > > I think the old behavior is sub-optimal. I am sure there are users > that really don't want the driver core to runtime resume the supplier > unconditionally. I agree. That said, the existing behavior has been there for quite a while and the callers of device_link_add() that have grown a dependency on it should be given a chance to change before it goes away. > I would rather go and fix the few users of device_link_add(), to use > DL_FLAG_RPM_ACTIVE, in cases when they need it. Which BTW was the original idea. :-) > Of course I am fine if we do these changes in a step by step basis as well. OK, because that's what I'd prefer to do.
Re: [PATCH] PM / core: Fix supplier device runtime PM usage counter imbalance
On Wed, Jun 13, 2018 at 8:23 AM, Marek Szyprowski wrote: > Hi Rafael, Hi Marek, > On 2018-06-12 16:24, Rafael J. Wysocki wrote: >> On Tuesday, June 12, 2018 2:44:23 PM CEST Marek Szyprowski wrote: >>> On 2018-06-12 13:00, Rafael J. Wysocki wrote: From: Rafael J. Wysocki If a device link is added via device_link_add() by the driver of the link's consumer device, the supplier's runtime PM usage counter is going to be dropped by the pm_runtime_put_suppliers() call in driver_probe_device(). However, in that case it is not incremented unless the supplier driver is already present and the link is not stateless. That leads to a runtime PM usage counter imbalance for the supplier device in a few cases. To prevent that from happening, bump up the supplier runtime PM usage counter in device_link_add() for all links with the DL_FLAG_PM_RUNTIME flag set that are added at the consumer probe time. Use pm_runtime_get_noresume() for that as the callers of device_link_add() who want the supplier to be resumed by it should pass DL_FLAG_RPM_ACTIVE in flags to it anyway. Fixes: 21d5c57b3726 (PM / runtime: Use device links) Reported-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki --- This is a replacement for commit 1e8378619841 (PM / runtime: Fixup reference counting of device link suppliers at probe) that is going to be reverted. >>> Thanks Rafael for the patch. I've applied it and now I'm a bit puzzled. >> Thanks for testing! :-) >> >>> Let's get back to my IOMMU and codec case, mentioned here: >>> https://marc.info/?l=linux-pm=152878741527962=2 >>> >>> Now, after applying your patch, when IOMMU creates a link with >>> DL_FLAG_PM_RUNTIME to the jpeg device (this happens when jpeg device is >>> being probed), it is not IOMMU is not runtime resumed anymore (that's >>> because the patch changes pm_runtime_get_sync to pm_runtime_get_noresume). >>> This means that until jpeg driver enables runtime pm for its device and >>> finally performs runtime pm suspends/resume cycle, the supplier won't be >>> resumed. On the other hand, when I add DL_FLAG_RPM_ACTIVE flag to link >>> creation, the supplier is properly resumed, but then, once the jpeg >>> device probe finishes, the supplier is still in runtime active state >>> until a next runtime suspend/resume cycle of jpeg device. >> That additional suspend-resume cycle should not be necessary in theory >> unless I'm missing something. >> >> The pm_request_idle() call in driver_probe_device() should trigger a >> suspend of the jpeg device after probe (unless blocked by something) >> and that should drop the RPM usage counter of the IOMMU. Next, the >> pm_runtime_put_suppliers() in there should actually suspend it. > > I've also would expect such behavior of PM core, but checks on real > hardware gives other results. > >> It looks like the pm_request_idle() doesn't work as expected. > > pm_request_idle() calls rpm_idle(), which returns early with -EAGAIN due to > (dev->power.runtime_status != RPM_ACTIVE) check. The device runtime_status > is RPM_SUSPENDED as initially set by pm_runtime_init() on device creation. > Notice that JPEG driver only calls pm_runtime_enable() and nothing more. But is the device really suspended during probe? Note that "suspend" means basically "not accessible to software", but I guess software needs to access it to set it up, right? If that is the case, maybe the driver should set the initial RPM status of the device to "active" before enabling runtime PM for it? That at least would be consistent with passing DL_FLAG_RPM_ACTIVE to device_link_add(). There are drivers that don't actually touch the hardware in ->probe(), but it follows from your description that this is not one of them. >>> If I understand right, the DL_FLAG_RPM_ACTIVE flag should be there from the >>> beginning, but that time it runtime pm part of links worked in a bit >>> different way than now. >> Right, and evidently there are callers depending on the existing behavior. >> >>> Is there any way to keep old behavior? >> Yes, there is, please test the appended v2 of the $subject patch. >> >> That said, I'd like to remove the extra supplier resume from there going >> forward as there may be callers who actually don't want that to happen and >> DL_FLAG_RPM_ACTIVE is there for a purpose. > > Frankly, if the current behavior matches the designed behavior of > DL_FLAG_RPM_ACTIVE flag, It doesn't match the DL_FLAG_RPM_ACTIVE exactly as you've already noticed. DL_FLAG_RPM_ACTIVE assumes that the initial RPM status of the device will be RPM_ACTIVE and therefore the suppliers need to be resumed at link creation time. Therefore device_link_add() causes the suppliers to remain in the RPM_ACTIVE state with the rpm_active status bit of the link set, whereas currently they are simply suspended again by the pm_runtime_put_suppliers() in driver_probe_device() and the
[PATCH 1/2] dt-bindings: nand: meson: add Amlogic NAND controller driver
From: Liang Yang
Add Amlogic NAND controller dt-bindings for Meson SoC,
Current this driver support GXBB/GXL/AXG platform.
Signed-off-by: Liang Yang
Signed-off-by: Yixun Lan
---
.../bindings/mtd/amlogic,meson-nand.txt | 118 ++
1 file changed, 118 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
new file mode 100644
index ..eac9f9433d5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
@@ -0,0 +1,118 @@
+Amlogic NAND Flash Controller (NFC) for GXBB/GXL/AXG family SoCs
+
+This file documents the properties in addition to those available in
+the MTD NAND bindings.
+
+Required properties:
+- compatible : contains one of:
+ - "amlogic,meson-gxl-nfc"
+ - "amlogic,meson-axg-nfc"
+- clocks :
+ A list of phandle + clock-specifier pairs for the clocks listed
+ in clock-names.
+
+- clock-names: Should contain the following:
+ "core" - NFC module gate clock
+ "clkin0" - Parent clock of internal mux
+ "clkin1" - Other parent clock of internal mux
+
+- pins : Select pins which NFC need.
+- nand_pins: Detail NAND pins information.
+ nand_pins: nand {
+ mux {
+ groups = "emmc_nand_d0",
+ "emmc_nand_d1",
+ "emmc_nand_d2",
+ "emmc_nand_d3",
+ "emmc_nand_d4",
+ "emmc_nand_d5",
+ "emmc_nand_d6",
+ "emmc_nand_d7",
+ "nand_ce0",
+ "nand_rb0",
+ "nand_ale",
+ "nand_cle",
+ "nand_wen_clk",
+ "nand_ren_wr";
+ function = "nand";
+ };
+ };
+
+- amlogic,mmc-syscon : Required for NAND clocks, it's shared with SD/eMMC
+ controller port C
+
+Optional children nodes:
+Children nodes represent the available nand chips.
+
+Optional properties:
+- meson-nand-user-mode :
+ only set 2 or 16 which mean the way of reading OOB bytes by NFC.
+- meson-nand-ran-mode :
+ setting 0 or 1, means disable/enable scrambler which keeps the balence
+ of 0 and 1
+
+Other properties:
+see Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
+
+Example demonstrate on AXG SoC:
+
+ sd_emmc_c: mmc@7000 {
+ compatible = "simple-bus", "syscon";
+ reg = <0x0 0x7000 0x0 0x800>;
+ status = "okay";
+ };
+
+ nand: nfc@7800 {
+ compatible = "amlogic,meson-axg-nfc";
+ reg = <0x0 0x7800 0x0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ status = "disabled";
+ clocks = < CLKID_SD_EMMC_C>,
+ < CLKID_SD_EMMC_C_CLK0>,
+ < CLKID_FCLK_DIV2>;
+ clock-names = "core", "clkin0", "clkin1";
+ amlogic,mmc-syscon = <_mmc_c>;
+
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ nand@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ nand-on-flash-bbt;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <1024>;
+
+ meson-nand-user-mode = <2>;
+ meson-nand-ran-mode = <1>;
+
+ partition@0 {
+ label = "boot";
+ reg = <0x 0x0020>;
+ read-only;
+ };
+ partition@20 {
+ label = "env";
+ reg = <0x0020 0x0040>;
+ };
+ partition@60 {
+ label = "system";
+ reg = <0x0060 0x00a0>;
+ };
+ partition@100 {
+ label = "rootfs";
+ reg = <0x0100 0x0300>;
+ };
+ partition@400 {
+ label = "media";
+
[PATCH 0/2] mtd: rawnand: meson: add Amlogic NAND driver support
These two patches try to add initial NAND driver support for Amlogic Meson SoCs, current it has been tested on GXL(p212) and AXG(s400) platform. Liang Yang (2): dt-bindings: nand: meson: add Amlogic NAND controller driver mtd: rawnand: meson: add support for Amlogic NAND flash controller .../bindings/mtd/amlogic,meson-nand.txt | 118 ++ drivers/mtd/nand/raw/Kconfig |8 + drivers/mtd/nand/raw/Makefile |3 + drivers/mtd/nand/raw/meson_nand.c | 1422 + 4 files changed, 1551 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt create mode 100644 drivers/mtd/nand/raw/meson_nand.c -- 2.17.1
Re: [lkp-robot] [watchdog/softlockup] 4808e7a5dc: BUG:KASAN:null-ptr-deref_in_h
On Wed, Jun 13, 2018 at 01:08:38PM +0800, kernel test robot wrote: > [0.037000] BUG: KASAN: null-ptr-deref in hrtimer_active+0x70/0xa0 > [0.037000] Read of size 4 at addr 0010 by task swapper/1 > [0.037000] > [0.037000] CPU: 0 PID: 1 Comm: swapper Tainted: GT > 4.17.0-11348-g4808e7a #1 > [0.037000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.10.2-1 04/01/2014 > [0.037000] Call Trace: > [0.037000] ? kasan_report+0xe3/0x360 > [0.037000] ? hrtimer_active+0x70/0xa0 > [0.037000] ? hrtimer_try_to_cancel+0x17/0x210 > [0.037000] ? hrtimer_cancel+0x15/0x20 > [0.037000] ? softlockup_stop_fn+0x11/0x20 > [0.037000] ? lockup_detector_reconfigure+0x25/0xa0 > [0.037000] ? lockup_detector_init+0x51/0x5d > [0.037000] ? kernel_init_freeable+0xa9/0x243 > [0.037000] ? rest_init+0xd0/0xd0 > [0.037000] ? kernel_init+0xf/0x120 > [0.037000] ? rest_init+0xd0/0xd0 > [0.037000] ? ret_from_fork+0x24/0x30 ARGH, I thought I fixed that one.. I think that'll cure things, but let me do a KASAN build myself. --- a/kernel/watchdog.c +++ b/kernel/watchdog.c @@ -587,8 +587,8 @@ static __init void lockup_detector_setup return; mutex_lock(_mutex); - softlockup_initialized = true; lockup_detector_reconfigure(); + softlockup_initialized = true; mutex_unlock(_mutex); }
Re: ACPI support in common clock framework
On Wed, Jun 13, 2018 at 10:13 AM, Andy Shevchenko wrote: > +Cc: Rafael, ACPI ML > > On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam > wrote: >> Hi Michael, Stephen, >> >> We are adding ACPI support in our Linux based platform. >> At present our clock hierarchy using common clock framework through DTS. >> Now we required ACPI support in common clock framework to upgrade our >> platform. >> >> For example, clk_get API called in many drivers to get clock device is >> tightly coupled with DT framework. >> >> Please let us know, if anybody in Open Source community have plans to >> add ACPI support for common clock framework. There are no plans for doing that AFAICS. Moreover, it generally would not be consistent with ACPI power management defined by the specification. >> If not please suggest us alternative method to use common clock >> framework in ACPI use case. The problem with using the clock framework on systems with ACPI is that, in general, the clock manipulation is expected to be carried out by ACPI power management and therefore it is "owned" by AML. Currently, there are no defined methods for synchronizing the AML's use of clocks for power management with what the OS may do with them directly. In theory, that can be worked around to some extent by representing clocks as power resources in ASL (even though the provider information would be missing then) and manipulating those power resources directly from the OS. I'm not aware of anyone doing that successfully, however. For simple power management it should be sufficient to let drivers rely on the ACPI PM domain which should happen automatically in the majority of cases anyway. Thanks, Rafael
Re: [PATCH 14/28] drm/mediatek: add connection from RDMA1 to DPI1
Hi, Stu:
On Wed, 2018-06-13 at 15:56 +0800, Stu Hsieh wrote:
> Hi, CK:
>
> On Wed, 2018-06-13 at 14:13 +0800, CK Hu wrote:
> > Hi, Stu:
> >
> > On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > > This patch add the connection from RDMA1 to DPI1
> > >
> > > Signed-off-by: Stu Hsieh
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > index fed1b5704355..4abd5dabeccf 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > @@ -85,7 +85,9 @@
> > > #define RDMA0_MOUT_DSI2 0x4
> > > #define RDMA0_MOUT_DSI3 0x5
> > > #define RDMA1_MOUT_DPI0 0x2
> > > +#define RDMA1_MOUT_DPI1 0x3
> >
> > Usually, each bit of a mout register represent a output enable. Is this
> > value 0x3 a correct value?
> >
> > Regards,
> > CK
> >
> In HW CONFIG SPEC show as following
>
> Bit(s)NameDescription
> 2:0 DISP_PATH1_SOUT_SEL_IN 0 : Output to DSI0
> 1: Ooutput to DSI1
> 2: Ooutput to DPI
> 3: Ooutput to DPI1
> 4: Ooutput to DSI2
> 5: Ooutput to DSI3
> 6 : reserved
> 7: Ooutput to DISP_UFOE
>
> So, 0x3 is correct value
It looks like that RDMA1 output is also SOUT, use the naming SOUT would
be better.
Regards,
CK
>
> Regard,
> Stu
>
>
> > > #define DPI0_SEL_IN_RDMA10x1
> > > +#define DPI1_SEL_IN_RDMA1(0x1 << 8)
> > > #define COLOR1_SEL_IN_OVL1 0x1
> > >
> > > #define OVL_MOUT_EN_RDMA 0x1
> > > @@ -171,6 +173,9 @@ static unsigned int mtk_ddp_mout_en(enum
> > > mtk_ddp_comp_id cur,
> > > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > > *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > > value = RDMA1_MOUT_DPI0;
> > > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> > > + *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > > + value = RDMA1_MOUT_DPI1;
> > > } else {
> > > value = 0;
> > > }
> > > @@ -190,6 +195,9 @@ static unsigned int mtk_ddp_sel_in(enum
> > > mtk_ddp_comp_id cur,
> > > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > > *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > value = DPI0_SEL_IN_RDMA1;
> > > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> > > + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > + value = DPI1_SEL_IN_RDMA1;
> > > } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> > > *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> > > value = COLOR1_SEL_IN_OVL1;
> >
> >
>
>
Re: [PATCH 2/2] iio: adc: Add Spreadtrum SC27XX PMICs ADC support
> From: Freeman Liu
some comments below
> The Spreadtrum SC27XX PMICs ADC controller contains 32 channels,
> which is used to sample voltages with 12 bits conversion.
>
> Signed-off-by: Freeman Liu
> Signed-off-by: Baolin Wang
> ---
> drivers/iio/adc/Kconfig | 10 +
> drivers/iio/adc/Makefile |1 +
> drivers/iio/adc/sc27xx_adc.c | 558
> ++
> 3 files changed, 569 insertions(+)
> create mode 100644 drivers/iio/adc/sc27xx_adc.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 9da7907..985b73e 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -621,6 +621,16 @@ config ROCKCHIP_SARADC
> To compile this driver as a module, choose M here: the
> module will be called rockchip_saradc.
>
> +config SC27XX_ADC
> + tristate "Spreadtrum SC27xx series PMICs ADC"
> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
> + help
> + Say yes here to build support for the integrated ADC inside the
> + Spreadtrum SC27xx series PMICs.
> +
> + This driver can also be built as a module. If so, the module
> + will be called sc27xx_adc.
> +
> config SPEAR_ADC
> tristate "ST SPEAr ADC"
> depends on PLAT_SPEAR || COMPILE_TEST
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 28a9423..03db7b5 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -59,6 +59,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
> obj-$(CONFIG_QCOM_PM8XXX_XOADC) += qcom-pm8xxx-xoadc.o
> obj-$(CONFIG_RCAR_GYRO_ADC) += rcar-gyroadc.o
> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> +obj-$(CONFIG_SC27XX_ADC) += sc27xx_adc.o
> obj-$(CONFIG_SPEAR_ADC) += spear_adc.o
> obj-$(CONFIG_STX104) += stx104.o
> obj-$(CONFIG_SUN4I_GPADC) += sun4i-gpadc-iio.o
> diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
> new file mode 100644
> index 000..d74310a
> --- /dev/null
> +++ b/drivers/iio/adc/sc27xx_adc.c
> @@ -0,0 +1,558 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2018 Spreadtrum Communications Inc.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* PMIC global registers definition */
> +#define SC27XX_MODULE_EN 0xc08
> +#define SC27XX_MODULE_ADC_EN BIT(5)
> +#define SC27XX_ARM_CLK_EN0xc10
> +#define SC27XX_CLK_ADC_ENBIT(5)
> +#define SC27XX_CLK_ADC_CLK_ENBIT(6)
> +
> +/* ADC controller registers definition */
> +#define SC27XX_ADC_CTL 0x0
> +#define SC27XX_ADC_CH_CFG0x4
> +#define SC27XX_ADC_DATA 0x4c
> +#define SC27XX_ADC_INT_EN0x50
> +#define SC27XX_ADC_INT_CLR 0x54
> +#define SC27XX_ADC_INT_STS 0x58
> +#define SC27XX_ADC_INT_RAW 0x5c
> +
> +/* Bits and mask definition for SC27XX_ADC_CTL register */
> +#define SC27XX_ADC_ENBIT(0)
> +#define SC27XX_ADC_CHN_RUN BIT(1)
> +#define SC27XX_ADC_12BIT_MODEBIT(2)
> +#define SC27XX_ADC_RUN_NUM_MASK GENMASK(7, 4)
> +#define SC27XX_ADC_RUN_NUM_SHIFT 4
> +
> +/* Bits and mask definition for SC27XX_ADC_CH_CFG register */
> +#define SC27XX_ADC_CHN_ID_MASK GENMASK(4, 0)
> +#define SC27XX_ADC_SCALE_MASKGENMASK(10, 8)
> +#define SC27XX_ADC_SCALE_SHIFT 8
> +
> +/* Bits definitions for SC27XX_ADC_INT_EN registers */
> +#define SC27XX_ADC_IRQ_ENBIT(0)
> +
> +/* Bits definitions for SC27XX_ADC_INT_CLR registers */
> +#define SC27XX_ADC_IRQ_CLR BIT(0)
> +
> +/* Mask definition for SC27XX_ADC_DATA register */
> +#define SC27XX_ADC_DATA_MASK GENMASK(11, 0)
> +
> +/* Timeout (ms) for the trylock of hardware spinlocks */
> +#define SC27XX_ADC_HWLOCK_TIMEOUT5000
> +
> +/* Maximum ADC channel number */
> +#define SC27XX_ADC_CHANNEL_MAX 32
> +
> +/* ADC voltage ratio definition */
> +#define SC27XX_VOLT_RATIO(n, d) \
> + (((n) << SC27XX_RATIO_NUMERATOR_OFFSET) | (d))
> +#define SC27XX_RATIO_NUMERATOR_OFFSET16
> +#define SC27XX_RATIO_DENOMINATOR_MASKGENMASK(15, 0)
> +
> +/* Covert ADC values to voltage values */
Convert
> +#define SC27XX_ADC_TO_VOLTAGE(volt0, volt1, adc0, adc1, value) \
I'd rather define a function than a macro for this
> + ({ \
> + int tmp;\
> + tmp = (volt0) - (volt1);\
> + tmp = tmp * ((value) - (adc1)); \
> + tmp = tmp / ((adc0) - (adc1)); \
> + tmp = tmp + (volt1);\
> + if (tmp < 0)\
> + tmp = 0;
[PULL REQUEST] i2c for 4.18
Linus, I2C has for 4.18: * mainly feature additions to drivers (stm32f7, qup, xlp9xx, mlxcpld, ...) * conversion to use the i2c_8bit_addr_from_msg macro consistently * move includes to platform_data * core updates to allow the (still in review) I3C subsystem to connect * and the regular share of smaller driver updates Please pull. Thanks, Wolfram The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f: Linux 4.17-rc5 (2018-05-13 16:15:17 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-4.18 for you to fetch changes up to 53e39628ac228fada53cc0106be62c6f65f67501: i2c: qup: fix building without CONFIG_ACPI (2018-05-31 23:21:00 +0200) Alexander Monakov (2): i2c: designware: fix poll-after-enable regression i2c: designware: refactor low-level enable/disable Anders Roxell (1): i2c: i801: fix unused-function warning Andrzej Hajda (1): i2c: exynos5: simplify transfer function Arnd Bergmann (1): i2c: qup: fix building without CONFIG_ACPI Austin Christ (4): i2c: qup: add probe path for Centriq ACPI devices i2c: qup: Add support for Fast Mode Plus i2c: qup: Correct duty cycle for FM and FM+ i2c: qup: Add command-line parameter to override SCL frequency Bartosz Golaszewski (5): eeprom: at24: fix retrieving the at24_chip_data structure eeprom: at24: fix retrieving the at24_chip_data structure eeprom: at24: use devm_nvmem_register() eeprom: at24: provide and use a helper for releasing dummy i2c clients eeprom: at24: provide a separate routine for creating dummy i2c clients Boris Brezillon (3): i2c: Get rid of i2c_board_info->archdata i2c: Retain info->of_node in i2c_new_device() i2c: Export of_i2c_get_board_info() Colin Ian King (1): i2c: xiic: fix spelling mistake: "unexpexted" -> "unexpected" David Engraf (1): i2c: at91: Read all available bytes at once Dmitry Osipenko (1): i2c: tegra: Remove suspend-resume Fabio Estevam (3): i2c: imx: Switch to SPDX identifier i2c: mxs: Switch to SPDX identifier i2c: imx-lpi2c: Switch to SPDX identifier George Cherian (3): i2c: xlp9xx: Add support for SMBAlert i2c: xlp9xx: Fix issue seen when updating receive length i2c: xlp9xx: Make sure the transfer size is not more than I2C_SMBUS_BLOCK_SIZE Hans de Goede (2): i2c: core: ACPI: Improve OpRegion read errors i2c: core: ACPI: Log device not acking errors at dbg loglevel Jean Delvare (1): i2c: i801: Don't restore config registers on runtime PM Julia Lawall (1): i2c: mux: pca954x: merge calls to of_match_device and of_device_get_match_data Krzysztof Kozlowski (1): i2c: s3c2410: Remove support for Exynos5440 Markus Elfring (1): i2c: mux: reg: failed memory allocation is logged elsewhere Michael Shych (5): i2c: mlxcpld: Add support for extended transaction length for i2c-mlxcpld i2c: mlxcpld: Add support for smbus block read transaction i2c: mlxcpld: Fix adapter functionality support callback i2c: mlxcpld: Allow configurable adapter id for mlxcpld i2c: mlxcpld: Add capability register description to documentation Mike Looijmans (1): i2c: mux: pca954x: force reset on probe if available Peter Rosin (10): i2c: pmcmsp: return message count on master_xfer success i2c: pmcmsp: fix error return from master_xfer i2c: viperboard: return message count on master_xfer success i2c: hix5hd2: remove some dead code i2c: synquacer: fix fence-post error in retry loop i2c: mux: ltc4306: switch to using .probe_new i2c: robotfuzz-osif: remove pointless local variable i2c: robotfuzz-osif: drop pointless test i2c: algos: make use of i2c_8bit_addr_from_msg i2c: busses: make use of i2c_8bit_addr_from_msg Pierre-Yves MORDRET (7): i2c: i2c-stm32f7: Add 10-bit address support i2c: i2c-stm32f7: Add slave support i2c: i2c-stm32f7: Add initial SMBus protocols support i2c: i2c-stm32: Add generic DMA API i2c: i2c-stm32f7: Add DMA support i2c: i2c-stm32f7: Implement I2C release mechanism i2c: stm32f7: fix documentation typo Ryder Lee (1): i2c: mediatek: use of_device_get_match_data() Sergei Shtylyov (1): i2c: rcar: document R8A77980 bindings Shawn Lin (1): i2c: rk3x: Don't print visible virtual mapping MMIO address Tobias Jordan (1): i2c: axxia: enable clock before calling clk_get_rate() Wenwen Wang (1): i2c: core: smbus: fix a potential missing-check bug Wolfram Sang (20): i2c: rcar: enhance comment to avoid regressions i2c: busses: remove superfluous ignoring of children for RPM Merge tag 'at24-4.17-rc5-fixes-for-wolfram' of git://git.kernel.org/.../brgl/linux into i2c/for-current Merge branch
[PATCH] clk: qcom: Move frequency table macro to common file
Frequency table macro is used by multiple clock drivers, move frequency
table macro to common header file.
Signed-off-by: Taniya Das
---
drivers/clk/qcom/clk-rcg.h | 2 ++
drivers/clk/qcom/gcc-apq8084.c | 2 --
drivers/clk/qcom/gcc-ipq4019.c | 2 --
drivers/clk/qcom/gcc-ipq8074.c | 2 --
drivers/clk/qcom/gcc-msm8916.c | 2 --
drivers/clk/qcom/gcc-msm8974.c | 2 --
drivers/clk/qcom/gcc-msm8994.c | 2 --
drivers/clk/qcom/gcc-msm8996.c | 2 --
drivers/clk/qcom/gcc-msm8998.c | 2 --
drivers/clk/qcom/gcc-sdm845.c | 2 --
drivers/clk/qcom/mmcc-apq8084.c | 2 --
drivers/clk/qcom/mmcc-msm8974.c | 2 --
drivers/clk/qcom/mmcc-msm8996.c | 2 --
13 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index b209a2f..dbd5a9e 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -7,6 +7,8 @@
#include
#include "clk-regmap.h"
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
struct freq_tbl {
unsigned long freq;
u8 src;
diff --git a/drivers/clk/qcom/gcc-apq8084.c b/drivers/clk/qcom/gcc-apq8084.c
index 486d961..9c99a71 100644
--- a/drivers/clk/qcom/gcc-apq8084.c
+++ b/drivers/clk/qcom/gcc-apq8084.c
@@ -106,8 +106,6 @@ enum {
"sleep_clk_src",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static struct clk_pll gpll0 = {
.l_reg = 0x0004,
.m_reg = 0x0008,
diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index 46cb256..8902ad4 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -179,8 +179,6 @@ struct clk_fepll {
"ddrpllapss",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static const struct freq_tbl ftbl_gcc_audio_pwm_clk[] = {
F(4800, P_XO, 1, 0, 0),
F(2, P_FEPLL200, 1, 0, 0),
diff --git a/drivers/clk/qcom/gcc-ipq8074.c b/drivers/clk/qcom/gcc-ipq8074.c
index 0462f4a..505c626 100644
--- a/drivers/clk/qcom/gcc-ipq8074.c
+++ b/drivers/clk/qcom/gcc-ipq8074.c
@@ -32,8 +32,6 @@
#include "clk-regmap-mux.h"
#include "reset.h"
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
enum {
P_XO,
P_GPLL0,
diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c
index d6c7f50..ac2b0aa 100644
--- a/drivers/clk/qcom/gcc-msm8916.c
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -264,8 +264,6 @@ enum {
"sleep_clk",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static struct clk_pll gpll0 = {
.l_reg = 0x21004,
.m_reg = 0x21008,
diff --git a/drivers/clk/qcom/gcc-msm8974.c b/drivers/clk/qcom/gcc-msm8974.c
index 348e30d..08e2900d 100644
--- a/drivers/clk/qcom/gcc-msm8974.c
+++ b/drivers/clk/qcom/gcc-msm8974.c
@@ -62,8 +62,6 @@ enum {
"gpll4_vote",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static struct clk_pll gpll0 = {
.l_reg = 0x0004,
.m_reg = 0x0008,
diff --git a/drivers/clk/qcom/gcc-msm8994.c b/drivers/clk/qcom/gcc-msm8994.c
index 1e38efc..53f0f36 100644
--- a/drivers/clk/qcom/gcc-msm8994.c
+++ b/drivers/clk/qcom/gcc-msm8994.c
@@ -57,8 +57,6 @@ enum {
"gpll4",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static struct clk_fixed_factor xo = {
.mult = 1,
.div = 1,
diff --git a/drivers/clk/qcom/gcc-msm8996.c b/drivers/clk/qcom/gcc-msm8996.c
index 9f35b3f..9d3756c 100644
--- a/drivers/clk/qcom/gcc-msm8996.c
+++ b/drivers/clk/qcom/gcc-msm8996.c
@@ -32,8 +32,6 @@
#include "reset.h"
#include "gdsc.h"
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
enum {
P_XO,
P_GPLL0,
diff --git a/drivers/clk/qcom/gcc-msm8998.c b/drivers/clk/qcom/gcc-msm8998.c
index 78d87f5..9f0ae40 100644
--- a/drivers/clk/qcom/gcc-msm8998.c
+++ b/drivers/clk/qcom/gcc-msm8998.c
@@ -25,8 +25,6 @@
#include "reset.h"
#include "gdsc.h"
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
enum {
P_AUD_REF_CLK,
P_CORE_BI_PLL_TEST_SE,
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index e78e6f5..19b470f 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -25,8 +25,6 @@
#include "gdsc.h"
#include "reset.h"
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
enum {
P_BI_TCXO,
P_AUD_REF_CLK,
diff --git a/drivers/clk/qcom/mmcc-apq8084.c b/drivers/clk/qcom/mmcc-apq8084.c
index 30777f9..4ce1d7c 100644
--- a/drivers/clk/qcom/mmcc-apq8084.c
+++ b/drivers/clk/qcom/mmcc-apq8084.c
@@ -219,8 +219,6 @@ enum {
"sleep_clk_src",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static struct clk_pll mmpll0 = {
.l_reg = 0x0004,
.m_reg = 0x0008,
diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c
index 715e7cd..9181851 100644
--- a/drivers/clk/qcom/mmcc-msm8974.c
+++
Re: [PATCH 14/39] ovl: stack file ops
On Tue, Jun 12, 2018 at 8:31 PM, Al Viro wrote: > On Tue, Jun 12, 2018 at 07:24:23PM +0100, Al Viro wrote: >> I hate it, but... consider path_open() objections withdrawn for now. Is that an ACK for the pull if I follow up with fixes for mmap botch, etc? >> Uses of ->vm_file (and rules for those) are too convoluted to untangle >> at the moment. I still would love to get that straightened out, but >> it's not this cycle fodder, more's the pity... Looked at some other options... What coda mmap does looks very dubious. It only sets f_mapping, not vm_file. That's going to get into all sorts of trouble when underlying fs tries to look at file_inode() or worse, ->private_data. Looks like that should be converted to what overlayfs does, to have a remote chance of actually not crashing on most filesystems. Does anybody actually use coda still? > PS: conversion of ->f_path.dentry is easy and that can probably go this > cycle - it's a fairly trivial change, with no functional changes unless > overlayfs is used with , fixing really bad shit if it ever > gets used thus. I'm not asking to put that into overlayfs pull *and* > it's independent from the "want to kill that fucking kludge" stuff. > The latter is too hard for this cycle, unfortunately. So this is about adding a file_dentry_check() (or whatever we want to call it) helper to be used by all filesystems when dereferecing f_path.dentry, right? Thanks, Miklos
[PATCH] clk: qcom: Move frequency table macro to common file
Frequency table macro is used by multiple clock drivers, move frequency
table macro to common header file.
Change-Id: I78d76f04b6c335c05dd9325025be7db1e99cbeac
Signed-off-by: Taniya Das
---
drivers/clk/qcom/clk-rcg.h| 2 ++
drivers/clk/qcom/gcc-apq8084.c| 2 --
drivers/clk/qcom/gcc-ipq4019.c| 2 --
drivers/clk/qcom/gcc-ipq8074.c| 2 --
drivers/clk/qcom/gcc-msm8916.c| 2 --
drivers/clk/qcom/gcc-msm8974.c| 2 --
drivers/clk/qcom/gcc-msm8994.c| 2 --
drivers/clk/qcom/gcc-msm8996.c| 2 --
drivers/clk/qcom/gcc-msm8998.c| 2 --
drivers/clk/qcom/gcc-sdm845.c | 2 --
drivers/clk/qcom/mmcc-apq8084.c | 2 --
drivers/clk/qcom/mmcc-msm8974.c | 2 --
drivers/clk/qcom/mmcc-msm8996.c | 2 --
drivers/clk/qcom/videocc-sdm845.c | 2 --
14 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index b209a2f..dbd5a9e 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -7,6 +7,8 @@
#include
#include "clk-regmap.h"
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
struct freq_tbl {
unsigned long freq;
u8 src;
diff --git a/drivers/clk/qcom/gcc-apq8084.c b/drivers/clk/qcom/gcc-apq8084.c
index 486d961..9c99a71 100644
--- a/drivers/clk/qcom/gcc-apq8084.c
+++ b/drivers/clk/qcom/gcc-apq8084.c
@@ -106,8 +106,6 @@ enum {
"sleep_clk_src",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static struct clk_pll gpll0 = {
.l_reg = 0x0004,
.m_reg = 0x0008,
diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index 46cb256..8902ad4 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -179,8 +179,6 @@ struct clk_fepll {
"ddrpllapss",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static const struct freq_tbl ftbl_gcc_audio_pwm_clk[] = {
F(4800, P_XO, 1, 0, 0),
F(2, P_FEPLL200, 1, 0, 0),
diff --git a/drivers/clk/qcom/gcc-ipq8074.c b/drivers/clk/qcom/gcc-ipq8074.c
index 0462f4a..505c626 100644
--- a/drivers/clk/qcom/gcc-ipq8074.c
+++ b/drivers/clk/qcom/gcc-ipq8074.c
@@ -32,8 +32,6 @@
#include "clk-regmap-mux.h"
#include "reset.h"
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
enum {
P_XO,
P_GPLL0,
diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c
index d6c7f50..ac2b0aa 100644
--- a/drivers/clk/qcom/gcc-msm8916.c
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -264,8 +264,6 @@ enum {
"sleep_clk",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static struct clk_pll gpll0 = {
.l_reg = 0x21004,
.m_reg = 0x21008,
diff --git a/drivers/clk/qcom/gcc-msm8974.c b/drivers/clk/qcom/gcc-msm8974.c
index 348e30d..08e2900d 100644
--- a/drivers/clk/qcom/gcc-msm8974.c
+++ b/drivers/clk/qcom/gcc-msm8974.c
@@ -62,8 +62,6 @@ enum {
"gpll4_vote",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static struct clk_pll gpll0 = {
.l_reg = 0x0004,
.m_reg = 0x0008,
diff --git a/drivers/clk/qcom/gcc-msm8994.c b/drivers/clk/qcom/gcc-msm8994.c
index 1e38efc..53f0f36 100644
--- a/drivers/clk/qcom/gcc-msm8994.c
+++ b/drivers/clk/qcom/gcc-msm8994.c
@@ -57,8 +57,6 @@ enum {
"gpll4",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static struct clk_fixed_factor xo = {
.mult = 1,
.div = 1,
diff --git a/drivers/clk/qcom/gcc-msm8996.c b/drivers/clk/qcom/gcc-msm8996.c
index 9f35b3f..9d3756c 100644
--- a/drivers/clk/qcom/gcc-msm8996.c
+++ b/drivers/clk/qcom/gcc-msm8996.c
@@ -32,8 +32,6 @@
#include "reset.h"
#include "gdsc.h"
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
enum {
P_XO,
P_GPLL0,
diff --git a/drivers/clk/qcom/gcc-msm8998.c b/drivers/clk/qcom/gcc-msm8998.c
index 78d87f5..9f0ae40 100644
--- a/drivers/clk/qcom/gcc-msm8998.c
+++ b/drivers/clk/qcom/gcc-msm8998.c
@@ -25,8 +25,6 @@
#include "reset.h"
#include "gdsc.h"
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
enum {
P_AUD_REF_CLK,
P_CORE_BI_PLL_TEST_SE,
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index e78e6f5..19b470f 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -25,8 +25,6 @@
#include "gdsc.h"
#include "reset.h"
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
enum {
P_BI_TCXO,
P_AUD_REF_CLK,
diff --git a/drivers/clk/qcom/mmcc-apq8084.c b/drivers/clk/qcom/mmcc-apq8084.c
index 30777f9..4ce1d7c 100644
--- a/drivers/clk/qcom/mmcc-apq8084.c
+++ b/drivers/clk/qcom/mmcc-apq8084.c
@@ -219,8 +219,6 @@ enum {
"sleep_clk_src",
};
-#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
-
static struct clk_pll mmpll0 = {
.l_reg = 0x0004,
.m_reg = 0x0008,
diff --git
RE: [PATCH] mtd: spi-nor: honour max_data_size for spi-nor writes
Hi Boris,
-Original Message-
From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
Sent: Monday, June 11, 2018 3:19 PM
To: Yogesh Narayan Gaur
Cc: linux-...@lists.infradead.org; boris.brezil...@free-electrons.com;
frieder.schre...@exceet.de; computersforpe...@gmail.com; David Wolfe
; Han Xu ; feste...@gmail.com;
marek.va...@gmail.com; Prabhakar Kushwaha ;
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; NeilBrown
Subject: Re: [PATCH] mtd: spi-nor: honour max_data_size for spi-nor writes
Hi Yogesh,
Unrelated note: no need to send your patches to both
boris.brezi...@free-electrons.com and boris.brezi...@bootlin.com, just use the
latter.
Ok, Sure.
On Mon, 11 Jun 2018 14:48:14 +0530
Yogesh Gaur wrote:
> Honour max_data_size for spi-nor writes
^ This is no longer relevant.
> In new spi-mem framework, data size to be written is being calculated
> using spi_mem_adjust_op_size().
> This can return value less than nor->page_size.
>
> Add check value of data size return from API spi_mem_adjust_op_size()
> with the actual requested data size and write, max, only supported
> data size.
This part is not clear.
Also, I'd prefer to have this patch split in 2:
1/ one patch removing the check in spi_nor_write() 2/ and the second patch
removing the while() loop in m25p80_write()
How about the following commit messages for those 2 patches:
1:
"
mtd: spi-nor: Support controllers with limited TX FIFO size
Some SPI controllers can't write nor->page_size bytes in a single step because
their TX FIFO is too small.
Allow nor->write() to return a size that is smaller than the requested write
size to gracefully handle this case.
"
2:
"
mtd: devices: m25p80: Make sure WRITE_EN is issued before each write
Some SPI controllers can't write nor->page_size bytes in a single step because
their TX FIFO is too small, but when that happens we should make sure a
WRITE_EN command is issued before each write access.
The core is already taking care of that, so all we have to do here is return
the actual number of bytes that were written during the
spi_mem_exec_op() operation.
"
Both patches send [1][2]
--
Regards
Yogesh Gaur.
>
> Signed-off-by: NeilBrown
> Signed-off-by: Yogesh Gaur
> ---
> drivers/mtd/devices/m25p80.c | 23 ---
> drivers/mtd/spi-nor/spi-nor.c | 7 ---
> 2 files changed, 8 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c
> b/drivers/mtd/devices/m25p80.c index e84563d..60224fe 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -72,7 +72,6 @@ static ssize_t m25p80_write(struct spi_nor *nor, loff_t to,
> size_t len,
> SPI_MEM_OP_ADDR(nor->addr_width, to, 1),
> SPI_MEM_OP_DUMMY(0, 1),
> SPI_MEM_OP_DATA_OUT(len, buf, 1));
> - size_t remaining = len;
> int ret;
>
> /* get transfer protocols. */
> @@ -84,22 +83,16 @@ static ssize_t m25p80_write(struct spi_nor *nor, loff_t
> to, size_t len,
> if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second)
> op.addr.nbytes = 0;
>
> - while (remaining) {
> - op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
> - ret = spi_mem_adjust_op_size(flash->spimem, );
> - if (ret)
> - return ret;
> -
> - ret = spi_mem_exec_op(flash->spimem, );
> - if (ret)
> - return ret;
> + ret = spi_mem_adjust_op_size(flash->spimem, );
> + if (ret)
> + return ret;
> + op.data.nbytes = len < op.data.nbytes ? len : op.data.nbytes;
>
> - op.addr.val += op.data.nbytes;
> - remaining -= op.data.nbytes;
> - op.data.buf.out += op.data.nbytes;
> - }
> + ret = spi_mem_exec_op(flash->spimem, );
> + if (ret)
> + return ret;
>
> - return len;
> + return op.data.nbytes;
> }
>
> /*
> diff --git a/drivers/mtd/spi-nor/spi-nor.c
> b/drivers/mtd/spi-nor/spi-nor.c index 5bfa36e..3e63543 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -1431,13 +1431,6 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t
> to, size_t len,
> goto write_err;
> *retlen += written;
> i += written;
> - if (written != page_remain) {
> - dev_err(nor->dev,
> - "While writing %zu bytes written %zd bytes\n",
> - page_remain, written);
> - ret = -EIO;
> - goto write_err;
> - }
> }
>
> write_err:
[1] https://patchwork.ozlabs.org/patch/928677/
[2] https://patchwork.ozlabs.org/patch/928678/
Re: [PATCH linux-next v5 07/13] dt-bindings: mfd: Add a document for PECI client mfd
All s/mfd/MFD/
> This commit adds a dt-bindings document for PECI client multi-function
> device.
Multi-Function Device
> Signed-off-by: Jae Hyun Yoo
> Cc: Andrew Jeffery
> Cc: James Feist
> Cc: Jason M Biils
> Cc: Joel Stanley
> Cc: Vernon Mauery
> ---
> .../devicetree/bindings/mfd/peci-client.txt | 23 +++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/peci-client.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/peci-client.txt
> b/Documentation/devicetree/bindings/mfd/peci-client.txt
> new file mode 100644
> index ..4eb8f6bb6ca4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/peci-client.txt
> @@ -0,0 +1,23 @@
> +* Intel PECI client bindings
Now it the time to expand on what a "PECI client" is.
> +Required properties:
> +- compatible : Should be "intel,peci-client", "simple-mfd".
> +- reg: Should contain address of a client CPU. Address range of CPU
> +clients is starting from 0x30 based on PECI specification.
s/is starting/start/
> +Example:
> + peci-bus@0 {
0?
> + #address-cells = <1>;
> + #size-cells = <0>;
No 'reg' property?
> + < more properties >
Remove this.
> + peci-client@30 {
> + compatible = "intel,peci-client", "simple-mfd";
> + reg = <0x30>;
> + };
> +
> + peci-client@31 {
> + compatible = "intel,peci-client", "simple-mfd";
> + reg = <0x31>;
> + };
> + };
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 18/24] serdev: ttydev: Serdev driver that creates an standard TTY port
Hi Rob, On Wed, Jun 13, 2018 at 3:20 AM Rob Herring wrote: > > On Mon, Jun 11, 2018 at 5:52 AM, Ricardo Ribalda Delgado > wrote: > > Standard TTY port that can be loaded/unloaded via serdev sysfs. This > > serdev driver can only be used by serdev controllers that are compatible > > with ttyport. > > I'm hesitant to expose a tty device on top of serdev to userspace that > we then have to support forever unless that's the only way tty devices > (for serial ports) are created. My concern is that, with the current implementation, serdev does have a tiny collection of usecases: -It cannot be used for board bring up -It cannot be used as a replacement of hciattach and friends It can only be used on embedded devices or platforms where the developer has control of the ACPI table. This hack, allows its use in almost any scenario and I have been happily using it for two weeks with no issue. It is also a very simple solution that does not have the issues of cdev/serdev coexistence that you mention. I am not very convinced about all the ttydev being serdevs. Adding 1K lines of code to people that do not plan to use serdev seems like a high expense. If in the future we can get rid of all the hciattach programs then we can redesign the port probing. > > I did a similar patch which just registered both serdev and a tty > allowing them to coexist. It suffered from warnings about open counts > though and felt hacky. > > Rob -- Ricardo Ribalda
[PATCH 1/4] net: emaclite: Fix position of lp->mii_bus assignment
To ensure MDIO bus is not double freed in remove() path
assign lp->mii_bus after MDIO bus registration.
Signed-off-by: Radhey Shyam Pandey
Signed-off-by: Michal Simek
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 69e31ce..37989ce 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -863,14 +863,14 @@ static int xemaclite_mdio_setup(struct net_local *lp,
struct device *dev)
bus->write = xemaclite_mdio_write;
bus->parent = dev;
- lp->mii_bus = bus;
-
rc = of_mdiobus_register(bus, np);
if (rc) {
dev_err(dev, "Failed to register mdio bus.\n");
goto err_register;
}
+ lp->mii_bus = bus;
+
return 0;
err_register:
--
1.7.1
[PATCH 4/4] net: emaclite: Remove xemaclite_mdio_setup return check
Errors are already reported in xemaclite_mdio_setup so avoid reporting it again. Signed-off-by: Radhey Shyam Pandey Signed-off-by: Michal Simek --- drivers/net/ethernet/xilinx/xilinx_emaclite.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c index ec4608e..2a0c06e 100644 --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c @@ -1143,9 +1143,7 @@ static int xemaclite_of_probe(struct platform_device *ofdev) xemaclite_update_address(lp, ndev->dev_addr); lp->phy_node = of_parse_phandle(ofdev->dev.of_node, "phy-handle", 0); - rc = xemaclite_mdio_setup(lp, >dev); - if (rc) - dev_warn(>dev, "error registering MDIO bus\n"); + xemaclite_mdio_setup(lp, >dev); dev_info(dev, "MAC address is now %pM\n", ndev->dev_addr); -- 1.7.1
[lkp-robot] [x86/vdso] ab1bcc4420: BUG:kernel_hang_in_boot_stage
FYI, we noticed the following commit (built with gcc-4.9):
commit: ab1bcc442070315bd0ce963331d5bb93d5c5476e ("x86/vdso: Move out the CPU
number store")
url:
https://github.com/0day-ci/linux/commits/Chang-S-Bae/x86-fsgsbase-64-Introduce-FS-GS-base-helper-functions/20180605-095329
in testcase: boot
on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+---+++
| | 053d1414b3 | ab1bcc4420 |
+---+++
| boot_successes| 8 | 0 |
| boot_failures | 0 | 8 |
| BUG:kernel_hang_in_boot_stage | 0 | 8 |
+---+++
[0.00] clocksource: refined-jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 1911260446275 ns
[0.00] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1
nr_node_ids:1
[0.00] percpu: Embedded 342 pages/cpu @(ptrval) s1371088 r0 d29744
u1400832
[0.00] pcpu-alloc: s1371088 r0 d29744 u1400832 alloc=342*4096
[0.00] pcpu-alloc: [0] 0
BUG: kernel hang in boot stage
Linux version 4.17.0-rc3-00290-gab1bcc4 #1
Command line: ip=vm-vp-quantal-i386-50::dhcp root=/dev/ram0 user=lkp
job=/lkp/scheduled/vm-vp-quantal-i386-50/boot-1-quantal-core-i386.cgz-ab1bcc442070315bd0ce963331d5bb93d5c5476e-20180610-7731-3wa87x-0.yaml
ARCH=i386 kconfig=i386-randconfig-h1-06101053
branch=linux-devel/devel-catchup-201806101444
commit=ab1bcc442070315bd0ce963331d5bb93d5c5476e
BOOT_IMAGE=/pkg/linux/i386-randconfig-h1-06101053/gcc-4.9/ab1bcc442070315bd0ce963331d5bb93d5c5476e/vmlinuz-4.17.0-rc3-00290-gab1bcc4
max_uptime=600
RESULT_ROOT=/result/boot/1/vm-vp-quantal-i386/quantal-core-i386.cgz/i386-randconfig-h1-06101053/gcc-4.9/ab1bcc442070315bd0ce963331d5bb93d5c5476e/0
LKP_SERVER=inn debug apic=debug sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2
prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_loglevel
console=tty0 earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
drbd.minor_count=8 rcuperf.shutdown=0
Elapsed time: 560
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.17.0-rc3 Kernel Configuration
#
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_FILTER_PGPROT=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
[lkp-robot] [kernfs, sysfs, cgroup, intel_rdt] 0dd4eca846: kernel_BUG_at_fs/super.c
FYI, we noticed the following commit (built with gcc-6):
commit: 0dd4eca846629b5dc7d11ca40ae2a1379334b9e4 ("kernfs, sysfs, cgroup,
intel_rdt: Support fs_context")
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-i386 -enable-kvm -m 256M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | 76224b97f0 | 0dd4eca846 |
+--+++
| boot_successes | 8 | 2 |
| boot_failures| 0 | 4 |
| kernel_BUG_at_fs/super.c | 0 | 4 |
| invalid_opcode:#[##] | 0 | 4 |
| EIP:vfs_get_tree | 0 | 4 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 4 |
+--+++
[7.295290] kernel BUG at fs/super.c:1775!
[7.297885] invalid opcode: [#1] PREEMPT SMP
[7.303028] CPU: 0 PID: 1 Comm: init Not tainted 4.17.0-rc5-00204-g0dd4eca
#54
[7.311821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[7.322843] EIP: vfs_get_tree+0x16d/0x170
[7.326346] EFLAGS: 00010246 CPU: 0
[7.327808] EAX: 0030 EBX: ce1a19c0 ECX: EDX: ce1a19c0
[7.330450] ESI: ce1a19c0 EDI: EBP: c7de1f04 ESP: c7de1eec
[7.336866] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[7.341293] CR0: 80050033 CR2: b7f3f588 CR3: 0bab1000 CR4: 0690
[7.346567] Call Trace:
[7.349189] ? vfs_set_fs_source+0x70/0x70
[7.350853] ? vfs_set_fs_source+0x70/0x70
[7.352936] do_mount+0x21a/0xaa0
[7.355547] ksys_mount+0xc4/0x140
[7.359244] sys_mount+0x19/0x20
[7.362170] do_int80_syscall_32+0x76/0x190
[7.367179] entry_INT80_32+0x36/0x36
[7.371221] EIP: 0xb7f36c3e
[7.375471] EFLAGS: 0296 CPU: 0
[7.378821] EAX: ffda EBX: 0804a3a9 ECX: 0804a3a1 EDX: 0804a3a9
[7.381308] ESI: 000e EDI: EBP: bfc00db8 ESP: bfc00d1c
[7.383960] DS: 007b ES: 007b FS: GS: 0033 SS: 007b
[7.388781] Code: c7 43 0c 00 00 00 00 e8 b2 e2 ff ff b8 f4 ff ff ff eb 8f
8d 76 00 b8 fe ff ff ff c3 8b 43 04 ff 30 68 e8 7d ec c1 e8 d4 b1 f0 ff <0f> 0b
90 55 89 c8 89 e5 5d c3 89 f6 8d bc 27 00 00 00 00 55 31
[7.408953] EIP: vfs_get_tree+0x16d/0x170 SS:ESP: 0068:c7de1eec
[7.420191] ---[ end trace 2ff80a4e86e2d2e8 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.17.0-rc5 Kernel Configuration
#
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_FILTER_PGPROT=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_KERNEL_LZ4=y
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_USELIB=y
# CONFIG_AUDIT
[PATCH 0/2] Enable VDMA S2MM vertical flip support
The AXI VDMA core supports Vertical Flip with S2MM as the path when Enable Vertical Flip (Advanced tab) is selected. This patch series add DT property for vertical flip and program its state in VDMA start_transfer. Radhey Shyam Pandey (2): dt-bindings: dmaengine: xilinx_dma: Add VDMA vertical flip property dmaengine: xilinx_dma: Enable VDMA S2MM vertical flip support .../devicetree/bindings/dma/xilinx/xilinx_dma.txt |2 + drivers/dma/xilinx/xilinx_dma.c| 22 include/linux/dma/xilinx_dma.h |2 + 3 files changed, 26 insertions(+), 0 deletions(-)
[PATCH 2/2] dmaengine: xilinx_dma: Enable VDMA S2MM vertical flip support
Vertical flip state is exported in xilinx_vdma_config and depending
on IP configuration(c_enable_vert_flip) vertical flip state is
programmed in hardware.
Signed-off-by: Radhey Shyam Pandey
Signed-off-by: Michal Simek
---
drivers/dma/xilinx/xilinx_dma.c | 22 ++
include/linux/dma/xilinx_dma.h |2 ++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 27b5235..c124423 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -115,6 +115,9 @@
#define XILINX_VDMA_REG_START_ADDRESS(n) (0x000c + 4 * (n))
#define XILINX_VDMA_REG_START_ADDRESS_64(n)(0x000c + 8 * (n))
+#define XILINX_VDMA_REG_ENABLE_VERTICAL_FLIP 0x00ec
+#define XILINX_VDMA_ENABLE_VERTICAL_FLIP BIT(0)
+
/* HW specific definitions */
#define XILINX_DMA_MAX_CHANS_PER_DEVICE0x20
@@ -340,6 +343,7 @@ struct xilinx_dma_tx_descriptor {
* @start_transfer: Differentiate b/w DMA IP's transfer
* @stop_transfer: Differentiate b/w DMA IP's quiesce
* @tdest: TDEST value for mcdma
+ * @has_vflip: S2MM vertical flip
*/
struct xilinx_dma_chan {
struct xilinx_dma_device *xdev;
@@ -376,6 +380,7 @@ struct xilinx_dma_chan {
void (*start_transfer)(struct xilinx_dma_chan *chan);
int (*stop_transfer)(struct xilinx_dma_chan *chan);
u16 tdest;
+ bool has_vflip;
};
/**
@@ -1092,6 +1097,14 @@ static void xilinx_vdma_start_transfer(struct
xilinx_dma_chan *chan)
desc->async_tx.phys);
/* Configure the hardware using info in the config structure */
+ if (chan->has_vflip) {
+ reg = dma_read(chan, XILINX_VDMA_REG_ENABLE_VERTICAL_FLIP);
+ reg &= ~XILINX_VDMA_ENABLE_VERTICAL_FLIP;
+ reg |= config->vflip_en;
+ dma_write(chan, XILINX_VDMA_REG_ENABLE_VERTICAL_FLIP,
+ reg);
+ }
+
reg = dma_ctrl_read(chan, XILINX_DMA_REG_DMACR);
if (config->frm_cnt_en)
@@ -2105,6 +2118,8 @@ int xilinx_vdma_channel_set_config(struct dma_chan *dchan,
}
chan->config.frm_cnt_en = cfg->frm_cnt_en;
+ chan->config.vflip_en = cfg->vflip_en;
+
if (cfg->park)
chan->config.park_frm = cfg->park_frm;
else
@@ -2428,6 +2443,13 @@ static int xilinx_dma_chan_probe(struct
xilinx_dma_device *xdev,
chan->direction = DMA_DEV_TO_MEM;
chan->id = chan_id;
chan->tdest = chan_id - xdev->nr_channels;
+ chan->has_vflip = of_property_read_bool(node,
+ "xlnx,enable-vert-flip");
+ if (chan->has_vflip) {
+ chan->config.vflip_en = dma_read(chan,
+ XILINX_VDMA_REG_ENABLE_VERTICAL_FLIP) &
+ XILINX_VDMA_ENABLE_VERTICAL_FLIP;
+ }
chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
diff --git a/include/linux/dma/xilinx_dma.h b/include/linux/dma/xilinx_dma.h
index 34b98f2..5b6e61e 100644
--- a/include/linux/dma/xilinx_dma.h
+++ b/include/linux/dma/xilinx_dma.h
@@ -27,6 +27,7 @@
* @delay: Delay counter
* @reset: Reset Channel
* @ext_fsync: External Frame Sync source
+ * @vflip_en: Vertical Flip enable
*/
struct xilinx_vdma_config {
int frm_dly;
@@ -39,6 +40,7 @@ struct xilinx_vdma_config {
int delay;
int reset;
int ext_fsync;
+ bool vflip_en;
};
int xilinx_vdma_channel_set_config(struct dma_chan *dchan,
--
1.7.1
[PATCH 1/2] dt-bindings: dmaengine: xilinx_dma: Add VDMA vertical flip property
The AXI VDMA core supports Vertical flip in S2MM path when Enable Vertical Flip (Advanced tab) is selected. To allow vertical flip programming define an optional 'xlnx,enable-vert-flip' channel child node property. Signed-off-by: Radhey Shyam Pandey Signed-off-by: Michal Simek --- .../devicetree/bindings/dma/xilinx/xilinx_dma.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt index a2b8bfa..174af2c 100644 --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt @@ -66,6 +66,8 @@ Optional child node properties: Optional child node properties for VDMA: - xlnx,genlock-mode: Tells Genlock synchronization is enabled/disabled in hardware. +- xlnx,enable-vert-flip: Tells vertical flip is + enabled/disabled in hardware(S2MM path). Optional child node properties for AXI DMA: -dma-channels: Number of dma channels in child node. -- 1.7.1
Re: [PATCH 2/2] iio: adc: Add Spreadtrum SC27XX PMICs ADC support
Hi Peter,
On 13 June 2018 at 16:53, Peter Meerwald-Stadler wrote:
>
>> From: Freeman Liu
>
> some comments below
>
>> The Spreadtrum SC27XX PMICs ADC controller contains 32 channels,
>> which is used to sample voltages with 12 bits conversion.
>>
>> Signed-off-by: Freeman Liu
>> Signed-off-by: Baolin Wang
>> ---
>> drivers/iio/adc/Kconfig | 10 +
>> drivers/iio/adc/Makefile |1 +
>> drivers/iio/adc/sc27xx_adc.c | 558
>> ++
>> 3 files changed, 569 insertions(+)
>> create mode 100644 drivers/iio/adc/sc27xx_adc.c
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 9da7907..985b73e 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -621,6 +621,16 @@ config ROCKCHIP_SARADC
>> To compile this driver as a module, choose M here: the
>> module will be called rockchip_saradc.
>>
>> +config SC27XX_ADC
>> + tristate "Spreadtrum SC27xx series PMICs ADC"
>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>> + help
>> + Say yes here to build support for the integrated ADC inside the
>> + Spreadtrum SC27xx series PMICs.
>> +
>> + This driver can also be built as a module. If so, the module
>> + will be called sc27xx_adc.
>> +
>> config SPEAR_ADC
>> tristate "ST SPEAr ADC"
>> depends on PLAT_SPEAR || COMPILE_TEST
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index 28a9423..03db7b5 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -59,6 +59,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>> obj-$(CONFIG_QCOM_PM8XXX_XOADC) += qcom-pm8xxx-xoadc.o
>> obj-$(CONFIG_RCAR_GYRO_ADC) += rcar-gyroadc.o
>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>> +obj-$(CONFIG_SC27XX_ADC) += sc27xx_adc.o
>> obj-$(CONFIG_SPEAR_ADC) += spear_adc.o
>> obj-$(CONFIG_STX104) += stx104.o
>> obj-$(CONFIG_SUN4I_GPADC) += sun4i-gpadc-iio.o
>> diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
>> new file mode 100644
>> index 000..d74310a
>> --- /dev/null
>> +++ b/drivers/iio/adc/sc27xx_adc.c
>> @@ -0,0 +1,558 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (C) 2018 Spreadtrum Communications Inc.
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/* PMIC global registers definition */
>> +#define SC27XX_MODULE_EN 0xc08
>> +#define SC27XX_MODULE_ADC_EN BIT(5)
>> +#define SC27XX_ARM_CLK_EN0xc10
>> +#define SC27XX_CLK_ADC_ENBIT(5)
>> +#define SC27XX_CLK_ADC_CLK_ENBIT(6)
>> +
>> +/* ADC controller registers definition */
>> +#define SC27XX_ADC_CTL 0x0
>> +#define SC27XX_ADC_CH_CFG0x4
>> +#define SC27XX_ADC_DATA 0x4c
>> +#define SC27XX_ADC_INT_EN0x50
>> +#define SC27XX_ADC_INT_CLR 0x54
>> +#define SC27XX_ADC_INT_STS 0x58
>> +#define SC27XX_ADC_INT_RAW 0x5c
>> +
>> +/* Bits and mask definition for SC27XX_ADC_CTL register */
>> +#define SC27XX_ADC_ENBIT(0)
>> +#define SC27XX_ADC_CHN_RUN BIT(1)
>> +#define SC27XX_ADC_12BIT_MODEBIT(2)
>> +#define SC27XX_ADC_RUN_NUM_MASK GENMASK(7, 4)
>> +#define SC27XX_ADC_RUN_NUM_SHIFT 4
>> +
>> +/* Bits and mask definition for SC27XX_ADC_CH_CFG register */
>> +#define SC27XX_ADC_CHN_ID_MASK GENMASK(4, 0)
>> +#define SC27XX_ADC_SCALE_MASKGENMASK(10, 8)
>> +#define SC27XX_ADC_SCALE_SHIFT 8
>> +
>> +/* Bits definitions for SC27XX_ADC_INT_EN registers */
>> +#define SC27XX_ADC_IRQ_ENBIT(0)
>> +
>> +/* Bits definitions for SC27XX_ADC_INT_CLR registers */
>> +#define SC27XX_ADC_IRQ_CLR BIT(0)
>> +
>> +/* Mask definition for SC27XX_ADC_DATA register */
>> +#define SC27XX_ADC_DATA_MASK GENMASK(11, 0)
>> +
>> +/* Timeout (ms) for the trylock of hardware spinlocks */
>> +#define SC27XX_ADC_HWLOCK_TIMEOUT5000
>> +
>> +/* Maximum ADC channel number */
>> +#define SC27XX_ADC_CHANNEL_MAX 32
>> +
>> +/* ADC voltage ratio definition */
>> +#define SC27XX_VOLT_RATIO(n, d) \
>> + (((n) << SC27XX_RATIO_NUMERATOR_OFFSET) | (d))
>> +#define SC27XX_RATIO_NUMERATOR_OFFSET16
>> +#define SC27XX_RATIO_DENOMINATOR_MASKGENMASK(15, 0)
>> +
>> +/* Covert ADC values to voltage values */
>
> Convert
Sorry for typo and will fix in next version.
>
>> +#define SC27XX_ADC_TO_VOLTAGE(volt0, volt1, adc0, adc1, value) \
>
> I'd rather define a function than a macro for this
Sure.
>
>> + ({ \
>> + int tmp;\
>> + tmp = (volt0) - (volt1);\
>> + tmp = tmp * ((value) - (adc1)); \
>> +
Re: [PATCH v3 3/3] arm64/mm: migrate swapper_pg_dir and tramp_pg_dir
Hi Jun,
On 06/06/18 05:39, Jun Yao wrote:
> Migrate swapper_pg_dir and tramp_pg_dir. And their virtual addresses
> do not correlate with kernel's address.
This is all to make 'KSMA' harder, where an single arbitrary write is used to
add a block mapping to the page-tables, giving the attacker full access to
physical memory.
This series is pretty complicated, and would still be overcome by arbitrary-read
of __pa_swapper_pg_dir. Any attacker already has to defeat KASLR, but I guess
that can be done without having read-access.
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 94056e064c6f..ba0b55158971 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -637,10 +647,29 @@ static void __init map_kernel(pgd_t *pgdp)
> */
> void __init paging_init(void)
> {
> - phys_addr_t pgd_phys = early_pgtable_alloc();
> - pgd_t *pgdp = pgd_set_fixmap(pgd_phys);
> + phys_addr_t pgd_phys;
> + pgd_t *pgdp;
> + phys_addr_t mem_size;
>
> - __pa_swapper_pg_dir = __pa_symbol(swapper_pg_dir);
> + mem_size = __pa_symbol(swapper_pg_dir) + PAGE_SIZE
> + - (__pa_symbol(idmap_pg_dir) + IDMAP_DIR_SIZE);
> +
> + if (mem_size == PAGE_SIZE) {
> + pgd_phys = early_pgtable_alloc();
This is where we migrated swapper_pg_dir to, its the first memblock_alloc()
call, and is guaranteed to be at the top of memory. Moving this allocation later
will still cause a predictable page to be allocated as this setup code is the
only thing running. I don't think we are in a better position after this series.
Ideally we would put these pgd entries in the read-only section. We only modify
swapper_pg_dir for vmalloc()/vmap() once its generated, which we could do
through a fixmap entry.
Like this, an attacker can find where swapper_pg_dir is, but can't write to it.
(the tricky bit will be breaking swapper_pg_dir up, as we free parts of it)
Thanks,
James
Re: [PATCH v4] staging: comedi: Improved readability of function comedi_nsamples_left.
So close... On Tue, Jun 12, 2018 at 11:09:44PM +0200, Chris Opperman wrote: > Changes since v3: > a) Reverted u64 to unsigned long long and u32 to unsigned int. > b) Added patch versioning. > c) Changed type of scans_left to unsigned long long to avoid cast. > d) Clarified and updated changelog. > > >8---8< This part here needs to go ... > > Improve readability of comedi_nsamples_left: > a) Reduce nesting by using more return statements. > b) Declare variables scans_left and samples_left at start of function. > c) Change type of scans_Left to unsigned long long to avoid cast. ^ > > Signed-off-by: Chris Opperman > --- ... down here, under the --- cut off line. > drivers/staging/comedi/drivers.c | 26 +- > 1 file changed, 13 insertions(+), 13 deletions(-) > > diff --git a/drivers/staging/comedi/drivers.c > b/drivers/staging/comedi/drivers.c regards, dan carpenter
Re: [PATCHv4 2/3] kbuild: Introduce build-salt linker section and config option
Hi.
2018-06-12 9:32 GMT+09:00 Laura Abbott :
>
> The build id generated from --build-id can be generated in several different
> ways, with the default being the sha1 on the output of the linked file. For
> distributions, it can be useful to make sure this ID is unique, even if the
> actual file contents don't change. The easiest way to do this is to insert
> a section with some data.
>
> Introduce a macro to insert a linker section which will be filled
> with a hex value. This will ensure the build id can be changed just via
> a config option. Users who don't care about this can leave the
> default value and strip the section.
>
> Suggested-by: Linus Torvalds
> Signed-off-by: Laura Abbott
> ---
> include/asm-generic/vmlinux.lds.h | 6 ++
> init/Kconfig | 9 +
> scripts/module-common.lds.S | 4
> 3 files changed, 19 insertions(+)
>
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h
> index e373e2e10f6a..4af7e683aad2 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -830,6 +830,12 @@
> #define PERCPU_DECRYPTED_SECTION
> #endif
>
> +#defineBUILD_SALT
> \
> + . = ALIGN(32); \
> + .salt : AT(ADDR(.salt) - LOAD_OFFSET) { \
> + LONG(0xffaa5500); \
> + . = ALIGN(32);\
> + } = CONFIG_BUILD_ID_SALT\
What is 0xffaa5500 ?
Is it another salt in addition to CONFIG_BUILD_ID_SALT ?
Or, does it have a special meaning?
> /*
> * Default discarded sections.
> diff --git a/init/Kconfig b/init/Kconfig
> index d2b8b2ea097e..eb92ccfe4ecb 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1967,3 +1967,12 @@ config ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
> # .
> config ARCH_HAS_SYSCALL_WRAPPER
> def_bool n
> +
> +config BUILD_ID_SALT
> + hex "Build ID Salt"
> + default 0x12345678
> + help
> + The build ID is used to link binaries and their debug info. Setting
> + this option will use the value in the calculation of the build id.
> + This is mostly useful for distributions which want to ensure the
> + build is unique between builds. It's safe to leave the default.
If you run "make menuconfig",
you will notice this looks so strange;
"Build ID Salt" is displayed in the top level menu.
> diff --git a/scripts/module-common.lds.S b/scripts/module-common.lds.S
> index d61b9e8678e8..3c8410270ac1 100644
> --- a/scripts/module-common.lds.S
> +++ b/scripts/module-common.lds.S
> @@ -3,6 +3,9 @@
> * Archs are free to supply their own linker scripts. ld will
> * combine them automatically.
> */
> +
> +#include
> +
You are pulling many macros in
into modules, VDSO, etc.
You also need to touch
arch/*/kernel/vmlinux.lds.S
of all architectures.
This is not so nice.
> SECTIONS {
> /DISCARD/ : {
> *(.discard)
> @@ -23,4 +26,5 @@ SECTIONS {
> .init_array 0 : ALIGN(8) { *(SORT(.init_array.*))
> *(.init_array) }
>
> __jump_table0 : ALIGN(8) { KEEP(*(__jump_table)) }
> + BUILD_SALT
> }
> --
> 2.18.0.rc1
I was playing with a different approach.
Instead of touching linker scripts around,
how about putting the salt into an elfnote?
The compiler puts the build ID
into the '.note.gnu.build-id' section.
So, I guess it is sensible to put
the salt into '.note.*' section as well.
I attached my trial below:
- I moved 'config BUILD_SALT' to a better location
so that it will be displayed in the "General setup" menu.
- I added 'range 0 0x' to avoid warnings.
- I renamed the config symbol to CONFIG_BUILD_SALT
and change the default to 0x0.
Of course, this is just bike-shed things, though..
- It looks like 'owner=Linux, type_id=0'
is already used in VDSO.
https://github.com/torvalds/linux/blob/v4.17/arch/arm64/kernel/vdso/note.S#L26
I chose 0x100 for the type id, but it could be a different value
diff --git a/arch/x86/entry/vdso/vdso-note.S b/arch/x86/entry/vdso/vdso-note.S
index 79a071e..7942317 100644
--- a/arch/x86/entry/vdso/vdso-note.S
+++ b/arch/x86/entry/vdso/vdso-note.S
@@ -3,6 +3,7 @@
* Here we can supply some information useful to userland.
*/
+#include
#include
#include
#include
@@ -10,3 +11,5 @@
ELFNOTE_START(Linux, 0, "a")
.long LINUX_VERSION_CODE
ELFNOTE_END
+
+BUILD_SALT
diff --git a/arch/x86/entry/vdso/vdso32/note.S
b/arch/x86/entry/vdso/vdso32/note.S
index 9fd51f2..e78047d 100644
--- a/arch/x86/entry/vdso/vdso32/note.S
+++ b/arch/x86/entry/vdso/vdso32/note.S
@@ -4,6 +4,7 @@
* Here we can supply some information useful to userland.
*/
+#include
#include
#include
@@ -14,6 +15,8 @@
Re: [PATCH] PM / core: Fix supplier device runtime PM usage counter imbalance
Hi Ulf, On 2018-06-12 21:43, Ulf Hansson wrote: > On 12 June 2018 at 14:44, Marek Szyprowski wrote: >> On 2018-06-12 13:00, Rafael J. Wysocki wrote: >>> From: Rafael J. Wysocki >>> >>> If a device link is added via device_link_add() by the driver of the >>> link's consumer device, the supplier's runtime PM usage counter is >>> going to be dropped by the pm_runtime_put_suppliers() call in >>> driver_probe_device(). However, in that case it is not incremented >>> unless the supplier driver is already present and the link is not >>> stateless. That leads to a runtime PM usage counter imbalance for >>> the supplier device in a few cases. >>> >>> To prevent that from happening, bump up the supplier runtime >>> PM usage counter in device_link_add() for all links with the >>> DL_FLAG_PM_RUNTIME flag set that are added at the consumer probe >>> time. Use pm_runtime_get_noresume() for that as the callers of >>> device_link_add() who want the supplier to be resumed by it should >>> pass DL_FLAG_RPM_ACTIVE in flags to it anyway. >>> >>> Fixes: 21d5c57b3726 (PM / runtime: Use device links) >>> Reported-by: Ulf Hansson >>> Signed-off-by: Rafael J. Wysocki >>> --- >>> >>> This is a replacement for commit 1e8378619841 (PM / runtime: Fixup >>> reference counting of device link suppliers at probe) that is going >>> to be reverted. >> Thanks Rafael for the patch. I've applied it and now I'm a bit puzzled. >> Let's get back to my IOMMU and codec case, mentioned here: >> https://marc.info/?l=linux-pm=152878741527962=2 >> >> Now, after applying your patch, when IOMMU creates a link with >> DL_FLAG_PM_RUNTIME to the jpeg device (this happens when jpeg device is >> being probed), it is not IOMMU is not runtime resumed anymore (that's >> because the patch changes pm_runtime_get_sync to pm_runtime_get_noresume). > According to your earlier replies, I thought this is what you wanted. No? > >> This means that until jpeg driver enables runtime pm for its device and >> finally performs runtime pm suspends/resume cycle, the supplier won't be >> resumed. > What's the problem with that? Wasted power. IOMMU device is left enabled until first use of JPEG device, what means that respective power domain is also turned on unnecessarily. > When does the IOMMU device needs to be > runtime resumed? I would like to have IOMMU (supplier) runtime active all the time the JPEG (consumer) device is runtime active AND all the time between probe() and remove() if JPEG (consumer) doesn't support runtime PM (if it doesn't enable runtime PM at all). >> On the other hand, when I add DL_FLAG_RPM_ACTIVE flag to link >> creation, the supplier is properly resumed, but then, once the jpeg >> device probe finishes, the supplier is still in runtime active state >> until a next runtime suspend/resume cycle of jpeg device. > Could you elaborate on the what happens in jpeg driver during probe, > in regards to runtime PM. Perhaps you can also point me to what driver > it is? s5p_jpeg_probe() doesn't touch hardware at all and only calls pm_runtime_enable(), see drivers/media/platform/s5p-jpeg/jpeg-core.c >> If I understand >> right, the DL_FLAG_RPM_ACTIVE flag should be there from the beginning, >> but that time it runtime pm part of links worked in a bit different way >> than now. > Just to make sure, you also reverted 1e8378619841, before trying > Rafael's change on top? Yes >> Is there any way to keep old behavior? > I think the old behavior is sub-optimal. I am sure there are users > that really don't want the driver core to runtime resume the supplier > unconditionally. > > I would rather go and fix the few users of device_link_add(), to use > DL_FLAG_RPM_ACTIVE, in cases when they need it. Of course I am fine if > we do these changes in a step by step basis as well. I also agree that the old behavior is sub-optimal and there are use cases for the new (corrected) approach. I see no problems to add DL_FLAG_RPM_ACTIVE to exynos-iommu driver (and probably the 5 other drivers, which create links with DL_FLAG_PM_RUNTIME flag set to avoid regressions). The question is what else should be changed/fixed to get old behavior now. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen
On 06/13/2018 09:40 AM, Juergen Gross wrote:
On 13/06/18 08:13, Oleksandr Andrushchenko wrote:
On 06/13/2018 09:11 AM, Dmitry Torokhov wrote:
On June 12, 2018 10:49:31 PM PDT, Oleksandr Andrushchenko
wrote:
On 06/13/2018 02:40 AM, Dmitry Torokhov wrote:
On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the sync up with the canonical definitions of the input,
sound and display protocols in Xen.
Changes to kbdif:
1. Add missing string constants for {feature|request}-raw-pointer
to align with the rest of the interface file.
2. Add new XenStore feature fields, so it is possible to
individually
control set of exposed virtual devices for each guest OS:
- set feature-disable-keyboard to 1 if no keyboard device
needs
to be created
- set feature-disable-pointer to 1 if no pointer device needs
to be created
3. Move multi-touch device parameters to backend nodes: these are
described as a part of frontend's XenBus configuration nodes
while they belong to backend's configuration. Fix this by
moving
the parameters to the proper section.
Unique-id field:
1. Add unique-id XenBus entry for virtual input and display.
2. Change type of unique-id field to string for sndif to align with
display and input protocols.
Signed-off-by: Oleksandr Andrushchenko
Cc: Konrad Rzeszutek Wilk
Reviewed-by: Juergen Gross
I'm fine with this patch being added via the input tree with the
other
patches. In case I should take it via the Xen tree, please send me a
note.
Juergen,
I created an immutable branch off v4.17 with these 3 patches in case
you
would want to merge them into your tree without waiting for them to
appear in mainline:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
ib/4.17-xen-kbdfront-runtime-config
Thanks.
Thank you,
I would prefer the fastest path of course
It will be part of 4.19 pull request; the immutable branch is for
Juergen if he does not want to wait till 4.19 merge window to get the
changes.
Ah, I see. Juergen, can we please merge this via Xen tree then which
I assume will be faster?
As Dmitry has it already queued in the input tree I think this is fine.
I trust him to take the right decision for which kernel version those
patches are to be queued. They belong to the input tree after all.
Of course, no doubt here
Juergen
Thank you,
Oleksandr
Re: [PATCH] arm64: dts: apq8096-db820c: disable uart0 by default
On Tue, Jun 12, 2018 at 03:48:06PM +0100, Srinivas Kandagatla wrote: > Access to UART0 is disabled by bootloaders. By leaving it enabled by > default would reboot the board. > Disable this for now, this would alteast give a board which boots. > > Signed-off-by: Srinivas Kandagatla Thanks for this patch. I'll queue it up for a fixes-for-rc1 Andy
Re: [PATCH 23/28] drm/mediatek: add DPI1 support for mutex
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the DPI1 support for mutex
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 5a8569fa6505..5916fc11693a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -76,6 +76,7 @@
> #define MUTEX_SOF_DSI0 1
> #define MUTEX_SOF_DSI1 2
> #define MUTEX_SOF_DPI0 3
> +#define MUTEX_SOF_DPI1 4
>
> #define OVL0_MOUT_EN_COLOR0 0x1
> #define OD_MOUT_EN_RDMA0 0x1
> @@ -385,6 +386,9 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
> case DDP_COMPONENT_DPI0:
> reg = MUTEX_SOF_DPI0;
> break;
> + case DDP_COMPONENT_DPI1:
> + reg = MUTEX_SOF_DPI1;
> + break;
> default:
> if (ddp->mutex_mod[id] < 32) {
> offset = DISP_REG_MUTEX_MOD(mutex->id);
> @@ -417,6 +421,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
> *mutex,
> case DDP_COMPONENT_DSI0:
> case DDP_COMPONENT_DSI1:
> case DDP_COMPONENT_DPI0:
> + case DDP_COMPONENT_DPI1:
> writel_relaxed(MUTEX_SOF_SINGLE_MODE,
> ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
> break;
Re: [PATCH 24/28] drm/mediatek: add DSI2 support for mutex
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the DSI2 support for mutex
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 5916fc11693a..1e7e3872eccc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -77,6 +77,7 @@
> #define MUTEX_SOF_DSI1 2
> #define MUTEX_SOF_DPI0 3
> #define MUTEX_SOF_DPI1 4
> +#define MUTEX_SOF_DSI2 5
>
> #define OVL0_MOUT_EN_COLOR0 0x1
> #define OD_MOUT_EN_RDMA0 0x1
> @@ -383,6 +384,9 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
> case DDP_COMPONENT_DSI1:
> reg = MUTEX_SOF_DSI0;
> break;
> + case DDP_COMPONENT_DSI2:
> + reg = MUTEX_SOF_DSI2;
> + break;
> case DDP_COMPONENT_DPI0:
> reg = MUTEX_SOF_DPI0;
> break;
> @@ -420,6 +424,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
> *mutex,
> switch (id) {
> case DDP_COMPONENT_DSI0:
> case DDP_COMPONENT_DSI1:
> + case DDP_COMPONENT_DSI2:
> case DDP_COMPONENT_DPI0:
> case DDP_COMPONENT_DPI1:
> writel_relaxed(MUTEX_SOF_SINGLE_MODE,
[PATCH] mtd: rawnand: fix return value check for bad block status
Positive return value from read_oob() is making false BAD
blocks. For some of the NAND controllers, OOB bytes will be
protected with ECC and read_oob() will return number of bitflips.
If there is any bitflip in ECC protected OOB bytes for BAD block
status page, then that block is getting treated as BAD.
Fixes: c120e75e0e7d ("mtd: nand: use read_oob() instead of cmdfunc() for bad
block check")
Cc:
Signed-off-by: Abhishek Sahu
---
drivers/mtd/nand/raw/nand_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index f28c3a5..4a73f73 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -440,7 +440,7 @@ static int nand_block_bad(struct mtd_info *mtd, loff_t ofs)
for (; page < page_end; page++) {
res = chip->ecc.read_oob(mtd, chip, page);
- if (res)
+ if (res < 0)
return res;
bad = chip->oob_poi[chip->badblockpos];
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc.
is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2] lib/test_printf.c: call wait_for_random_bytes() before plain %p tests
If the test_printf module is loaded before the crng is initialized, the
plain 'p' tests will fail because the printed address will not be hashed
and the buffer will contain "(ptrval)" instead.
Since we cannot wait for the crng to be initialized for an undefined
time, both plain 'p' tests now accept the string "(ptrval)" as a valid
result and print a warning message.
Signed-off-by: Thierry Escande
---
Change in v2:
- Remove wait_for_random_bytes() usage
- Removed Acked-by from Tobin as the proposed solution is not the same
anymore.
lib/test_printf.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/lib/test_printf.c b/lib/test_printf.c
index 71ebfa43ad05..a625e3749566 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -206,6 +206,7 @@ test_string(void)
#define PTR_WIDTH 16
#define PTR ((void *)0x0123456789ab)
#define PTR_STR "0123456789ab"
+#define PTR_VAL_NO_CRNG "(ptrval)"
#define ZEROS "" /* hex 32 zero bits */
static int __init
@@ -216,7 +217,16 @@ plain_format(void)
nchars = snprintf(buf, PLAIN_BUF_SIZE, "%p", PTR);
- if (nchars != PTR_WIDTH || strncmp(buf, ZEROS, strlen(ZEROS)) != 0)
+ if (nchars != PTR_WIDTH)
+ return -1;
+
+ if (strncmp(buf, PTR_VAL_NO_CRNG, PTR_WIDTH) == 0) {
+ pr_warn("crng possibly not yet initialized. plain 'p' buffer
contains \"%s\"",
+ PTR_VAL_NO_CRNG);
+ return 0;
+ }
+
+ if (strncmp(buf, ZEROS, strlen(ZEROS)) != 0)
return -1;
return 0;
@@ -227,6 +237,7 @@ plain_format(void)
#define PTR_WIDTH 8
#define PTR ((void *)0x456789ab)
#define PTR_STR "456789ab"
+#define PTR_VAL_NO_CRNG "(ptrval)"
static int __init
plain_format(void)
@@ -245,7 +256,16 @@ plain_hash(void)
nchars = snprintf(buf, PLAIN_BUF_SIZE, "%p", PTR);
- if (nchars != PTR_WIDTH || strncmp(buf, PTR_STR, PTR_WIDTH) == 0)
+ if (nchars != PTR_WIDTH)
+ return -1;
+
+ if (strncmp(buf, PTR_VAL_NO_CRNG, PTR_WIDTH) == 0) {
+ pr_warn("crng possibly not yet initialized. plain 'p' buffer
contains \"%s\"",
+ PTR_VAL_NO_CRNG);
+ return 0;
+ }
+
+ if (strncmp(buf, PTR_STR, PTR_WIDTH) == 0)
return -1;
return 0;
--
2.14.1
Re: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
Hi Rob,
On 12/06/18 21:48, Rob Herring wrote:
On Fri, Jun 01, 2018 at 02:16:05PM +0100, Suzuki K Poulose wrote:
The coresight drivers relied on default bindings for graph
in DT, while reusing the "reg" field of the "ports" to indicate
the actual hardware port number for the connections. However,
with the rules getting stricter w.r.t to the address mismatch
with the label, it is no longer possible to use the port address
field for the hardware port number. Hence, we add an explicit
property to denote the hardware port number, "coresight,hwid"
which must be specified for each "endpoint".
Cc: Mathieu Poirier
Cc: Sudeep Holla
Cc: Rob Herring
Signed-off-by: Suzuki K Poulose
---
.../devicetree/bindings/arm/coresight.txt | 26 +---
drivers/hwtracing/coresight/of_coresight.c | 46 --
2 files changed, 54 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
b/Documentation/devicetree/bindings/arm/coresight.txt
index bd36e40..385581a 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -104,7 +104,11 @@ properties to uniquely identify the connection details.
"slave-mode"
* Hardware Port number at the component:
- - The hardware port number is assumed to be the address of the "port"
component.
+ - (Obsolete) The hardware port number is assumed to be the address of the
"port" component.
+ - Each "endpoint" must define the hardware port of the local end of the
+ connection using the following property:
+ "coresight,hwid" - 32bit integer, hardware port number at the local end.
"coresight" is not a vendor and properties are in the form
[,].
OK. The issue here is that a coresight component could be an Arm IP or
a custom partner IP. So, the vendor could be either arm or the partner id.
However, this property is kind of a generic one for the Coresight family,
which is why we opted for "coresight". What is the guideline for such
cases ?
Or in other words I see the following possible options :
1) coresight,hwid - coresight generic
2) arm,coresight-hwid - arm vendor, however the device could be from any
vendor.
3) hwid - Generic
4) none of the above, something completely different.
What do you recommend from the above ?
+
Example:
@@ -120,6 +124,7 @@ Example:
etb_in_port: endpoint@0 {
There shouldn't be a unit address here because there is no reg property.
slave-mode;
remote-endpoint = <_out_port0>;
+ coresight,hwid = <0>;
It doesn't make sense for these to be in the endpoint. If you had
multiple endpoints, then you would have to duplicate it. "ports" are
a single data stream. "endpoints" are connections to that stream. So if
you have a muxed (input) or fanout/1-to-many (output) connection, then
you have multiple endpoints.
We do have many-to-1 input (e.g, funnels) and 1-to-many outputs
(e.g replicators). However, we have (so far) used only one endpoint per
port.
Also we could potentially have multiple data streams flowing through
the ports, which gets filtered to different ports in 1-to-many components
(read programmable-replicator).
So the point is we have a shared path which carries different data
streams with mux/demux components. I am open for suggestions based on
the above facts.
The same applied to the slave-mode property, but that ship has sailed.
No reason to continue that though.
};
};
};
@@ -134,6 +139,7 @@ Example:
tpiu_in_port: endpoint@0 {
slave-mode;
remote-endpoint = <_out_port1>;
+ coresight,hwid = <0>;
};
};
};
@@ -154,6 +160,7 @@ Example:
reg = <0>;
replicator_out_port0: endpoint {
remote-endpoint = <_in_port>;
+ coresight,hwid = <0>;
};
};
@@ -161,15 +168,17 @@ Example:
reg = <1>;
replicator_out_port1: endpoint {
remote-endpoint = <_in_port>;
+ coresight,hwid = <1>;
};
};
/* replicator input port */
port@2 {
- reg = <0>;
+ reg = <1>;
This will still get flagged as an error. reg must be 2 here.
Sorry, thats a mistake. I will fix it.
Cheers
Suzuki
Re: [PATCH] PM / core: Fix supplier device runtime PM usage counter imbalance
Hi Marek, On Wed, Jun 13, 2018 at 12:23 PM, Marek Szyprowski wrote: > Hi Rafael, > [cut] > Let's get back to my IOMMU and codec case, mentioned here: > https://marc.info/?l=linux-pm=152878741527962=2 > > Now, after applying your patch, when IOMMU creates a link with > DL_FLAG_PM_RUNTIME to the jpeg device (this happens when jpeg device is > being probed), it is not IOMMU is not runtime resumed anymore (that's > because the patch changes pm_runtime_get_sync to pm_runtime_get_noresume). > This means that until jpeg driver enables runtime pm for its device and > finally performs runtime pm suspends/resume cycle, the supplier won't be > resumed. On the other hand, when I add DL_FLAG_RPM_ACTIVE flag to link > creation, the supplier is properly resumed, but then, once the jpeg > device probe finishes, the supplier is still in runtime active state > until a next runtime suspend/resume cycle of jpeg device. That additional suspend-resume cycle should not be necessary in theory unless I'm missing something. The pm_request_idle() call in driver_probe_device() should trigger a suspend of the jpeg device after probe (unless blocked by something) and that should drop the RPM usage counter of the IOMMU. Next, the pm_runtime_put_suppliers() in there should actually suspend it. >>> I've also would expect such behavior of PM core, but checks on real >>> hardware gives other results. >>> It looks like the pm_request_idle() doesn't work as expected. >>> pm_request_idle() calls rpm_idle(), which returns early with -EAGAIN due to >>> (dev->power.runtime_status != RPM_ACTIVE) check. The device runtime_status >>> is RPM_SUSPENDED as initially set by pm_runtime_init() on device creation. >>> Notice that JPEG driver only calls pm_runtime_enable() and nothing more. >> >> But is the device really suspended during probe? > > This is a runtime pm state of the newly created platform device when driver > core calls ->probe() from its driver. At that time it is not yet known if > the driver supports runtime pm or not and typically drivers do some hardware > access there. Platform device is created from device tree. By the time the core calls pm_request_idle() in driver_probe_device(), really_probe() has run already and the driver's ->probe() should have run and that should damn well know if runtime PM can be supported. >> Note that "suspend" means basically "not accessible to software", but >> I guess software needs to access it to set it up, right? If that is >> the case, maybe the driver should set the initial RPM status of the >> device to "active" before enabling runtime PM for it? That at least >> would be consistent with passing DL_FLAG_RPM_ACTIVE to >> device_link_add(). >> >> There are drivers that don't actually touch the hardware in ->probe(), >> but it follows from your description that this is not one of them. > > The JPEG driver was just an example, and it actually doesn't touch hw in > probe. However I would like to have the typical cases working: > > 1. runtime pm enabled, no hw access > 2. runtime pm enabled, some hw access (guarded by either > pm_runtime_get_sync or pm_runtime_get_noresume+pm_runtime_set_active) > 3. runtime pm disabled (no runtime pm calls at all), some hw access. > > For the last type it is important to enable IOMMU during the probe(). I see. In that case whoever adds the link needs to do an extra pm_runtime_resume() on the supplier after the link has been added. Doing that in device_link_add() itself would adversely affect the case in which the creator of the link does not want the supplier to be resumed. > If I understand right, the DL_FLAG_RPM_ACTIVE flag should be there from > the > beginning, but that time it runtime pm part of links worked in a bit > different way than now. Right, and evidently there are callers depending on the existing behavior. > Is there any way to keep old behavior? Yes, there is, please test the appended v2 of the $subject patch. That said, I'd like to remove the extra supplier resume from there going forward as there may be callers who actually don't want that to happen and DL_FLAG_RPM_ACTIVE is there for a purpose. >>> Frankly, if the current behavior matches the designed behavior of >>> DL_FLAG_RPM_ACTIVE flag, >> It doesn't match the DL_FLAG_RPM_ACTIVE exactly as you've already noticed. >> >> DL_FLAG_RPM_ACTIVE assumes that the initial RPM status of the device >> will be RPM_ACTIVE and therefore the suppliers need to be resumed at >> link creation time. Therefore device_link_add() causes the suppliers >> to remain in the RPM_ACTIVE state with the rpm_active status bit of >> the link set, whereas currently they are simply suspended again by the >> pm_runtime_put_suppliers() in driver_probe_device() and the link is >> not marked as "rpm_active". >> >>> then maybe instead of adding workarounds now, we >>>
Re: [PATCH] clk: meson-gxbb: set fclk_div2 as CLK_IS_CRITICAL
On Wed, 2018-06-13 at 14:20 +0200, Neil Armstrong wrote:
> On Amlogic Meson GXBB & GXL platforms, the SCPI Cortex-M4 Co-Processor
> seems to be dependent on the FCLK_DIV2 to be operationnal.
>
> The issue occured since v4.17-rc1 by freezing the kernel boot when
> the 'schedutil' cpufreq governor was selected as default :
>
> [ 12.071837] scpi_protocol scpi: SCP Protocol 0.0 Firmware 0.0.0 version
> domain-0 init dvfs: 4
> [ 12.087757] hctosys: unable to open rtc device (rtc0)
> [ 12.087907] cfg80211: Loading compiled-in X.509 certificates for
> regulatory database
> [ 12.102241] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
>
> But when disabling the MMC driver, the boot finished but cpufreq failed to
> change the CPU frequency :
>
> [ 12.153045] cpufreq: __target_index: Failed to change cpu frequency: -5
>
> A bisect between v4.16 and v4.16-rc1 gave the 05f814402d61 commit to be
> the first bad commit.
> This commit added support for the missing clock gates before the fixed PLL
> fixed dividers (FCLK_DIVx) and the clock framework basically disabled
> all the unused fixed dividers, thus disabled a critical clock path for
> the SCPI Co-Processor.
>
> This patch simply sets the FCLK_DIV2 gate as critical to ensure
> nobody can disable it.
>
> Fixes: 05f814402d61 ("clk: meson: add fdiv clock gates")
> Signed-off-by: Neil Armstrong
Good catch !
We'll probably have to check the axg family as well
> ---
> drivers/clk/meson/gxbb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index b1e4d95..0e053c1 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -511,6 +511,7 @@ static struct clk_regmap gxbb_fclk_div2 = {
> .ops = _regmap_gate_ops,
> .parent_names = (const char *[]){ "fclk_div2_div" },
> .num_parents = 1,
> + .flags = CLK_IS_CRITICAL,
> },
> };
>
Re: [PATCH] fpga: altera-cvp: Fix an error handling path in 'altera_cvp_probe()'
Hi Christophe,
good catch!
On Mon, Jun 11, 2018 at 12:20 PM, Christophe JAILLET
wrote:
> If 'fpga_mgr_create()' fails, we should release some resources, as done
> in the other error handling path of the function.
>
> Fixes: 7085e2a94f7d ("fpga: manager: change api, don't use drvdata")
> Signed-off-by: Christophe JAILLET
Reviewed-by: Moritz Fischer
> ---
> drivers/fpga/altera-cvp.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c
> index dd4edd8f22ce..7fa793672a7a 100644
> --- a/drivers/fpga/altera-cvp.c
> +++ b/drivers/fpga/altera-cvp.c
> @@ -455,8 +455,10 @@ static int altera_cvp_probe(struct pci_dev *pdev,
>
> mgr = fpga_mgr_create(>dev, conf->mgr_name,
> _cvp_ops, conf);
> - if (!mgr)
> - return -ENOMEM;
> + if (!mgr) {
> + ret = -ENOMEM;
> + goto err_unmap;
> + }
>
> pci_set_drvdata(pdev, mgr);
>
> --
> 2.17.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
Moritz
Re: [PATCH] ACPI / LPSS: Avoid PM quirks on suspend and resume from S3
On Wed, 2018-06-13 at 13:17 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> It is reported that commit a192aa923b66a (ACPI / LPSS: Consolidate
> runtime PM and system sleep handling) introduced a system suspend
> regression on some machines, but the only functional change made by
> it was to cause the PM quirks in the LPSS to also be used during
> system suspend and resume. While that should always work for
> suspend-to-idle, it turns out to be problematic for S3
> (suspend-to-RAM).
>
> To address that issue restore the previous S3 suspend and resume
> behavior of the LPSS to avoid applying PM quirks then.
>
LGTM,
Reviewed-by: Andy Shevchenko
> Fixes: a192aa923b66a (ACPI / LPSS: Consolidate runtime PM and system
> sleep handling)
> Link: https://bugs.launchpad.net/bugs/1774950
> Reported-by: Kai-Heng Feng
> Tested-by: Kai-Heng Feng
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/acpi/acpi_lpss.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> Index: linux-pm/drivers/acpi/acpi_lpss.c
> ===
> --- linux-pm.orig/drivers/acpi/acpi_lpss.c
> +++ linux-pm/drivers/acpi/acpi_lpss.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "internal.h"
> @@ -940,9 +941,10 @@ static void lpss_iosf_exit_d3_state(void
> mutex_unlock(_iosf_mutex);
> }
>
> -static int acpi_lpss_suspend(struct device *dev, bool wakeup)
> +static int acpi_lpss_suspend(struct device *dev, bool runtime)
> {
> struct lpss_private_data *pdata =
> acpi_driver_data(ACPI_COMPANION(dev));
> + bool wakeup = runtime || device_may_wakeup(dev);
> int ret;
>
> if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
> @@ -955,13 +957,14 @@ static int acpi_lpss_suspend(struct devi
>* wrong status for devices being about to be powered off.
> See
>* lpss_iosf_enter_d3_state() for further information.
>*/
> - if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON &&
> iosf_mbi_available())
> + if ((runtime || !pm_suspend_via_firmware()) &&
> + lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON &&
> iosf_mbi_available())
> lpss_iosf_enter_d3_state();
>
> return ret;
> }
>
> -static int acpi_lpss_resume(struct device *dev)
> +static int acpi_lpss_resume(struct device *dev, bool runtime)
> {
> struct lpss_private_data *pdata =
> acpi_driver_data(ACPI_COMPANION(dev));
> int ret;
> @@ -970,7 +973,8 @@ static int acpi_lpss_resume(struct devic
>* This call is kept first to be in symmetry with
>* acpi_lpss_runtime_suspend() one.
>*/
> - if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON &&
> iosf_mbi_available())
> + if ((runtime || !pm_resume_via_firmware()) &&
> + lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON &&
> iosf_mbi_available())
> lpss_iosf_exit_d3_state();
>
> ret = acpi_dev_resume(dev);
> @@ -994,12 +998,12 @@ static int acpi_lpss_suspend_late(struct
> return 0;
>
> ret = pm_generic_suspend_late(dev);
> - return ret ? ret : acpi_lpss_suspend(dev,
> device_may_wakeup(dev));
> + return ret ? ret : acpi_lpss_suspend(dev, false);
> }
>
> static int acpi_lpss_resume_early(struct device *dev)
> {
> - int ret = acpi_lpss_resume(dev);
> + int ret = acpi_lpss_resume(dev, false);
>
> return ret ? ret : pm_generic_resume_early(dev);
> }
> @@ -1014,7 +1018,7 @@ static int acpi_lpss_runtime_suspend(str
>
> static int acpi_lpss_runtime_resume(struct device *dev)
> {
> - int ret = acpi_lpss_resume(dev);
> + int ret = acpi_lpss_resume(dev, true);
>
> return ret ? ret : pm_generic_runtime_resume(dev);
> }
>
--
Andy Shevchenko
Intel Finland Oy
Re: [PATCH] mm: cma: honor __GFP_ZERO flag in cma_alloc()
On Wed, Jun 13, 2018 at 10:58:37AM +0200, Marek Szyprowski wrote: > cma_alloc() function has gfp mask parameter, so users expect that it > honors typical memory allocation related flags. The most imporant from > the security point of view is handling of __GFP_ZERO flag, because memory > allocated by this function usually can be directly remapped to userspace > by device drivers as a part of multimedia processing and ignoring this > flag might lead to leaking some kernel structures to userspace. > Some callers of this function (for example arm64 dma-iommu glue code) > already assumed that the allocated buffers are cleared when this flag > is set. To avoid such issues, add simple code for clearing newly > allocated buffer when __GFP_ZERO flag is set. Callers will be then > updated to skip implicit clearing or adjust passed gfp flags. dma mapping implementations need to zero all memory returned anyway (even if a few implementation don't do that yet). I'd rather keep the zeroing in the common callers.
Re: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
Hi Matt,
Thanks for your comments, responses inline.
On 13/06/18 13:49, Matt Sealey wrote:
Suzuki,
Why not use “unit”?
I believe we had this discussion years ago about numbering serial ports and
sdhci (i.e. how do you know it’s UART0 or UART1 from just the address? Some
SoC’s don’t address sequentially *or* in a forward direction) - I believe it’s
not exactly codified in ePAPR, not am I sure where it may be otherwise, but it
exists.
We have different situation here. We need to know *the port number* as
understood by the
hardware, so that we can enable *the specific* port for a given path.
I agree with Rob on the slave-mode nonsense, this is an SPI controller concept
weirdly stuffed into a directed graph which implicitly tells you the data
direction - it’s a rooted tree (just like DT!).
Btw, the "slave-mode" is not a standard DT graph binding. It is not part of the
generic DT graph binding. In fact the generic bindings stay away from the
direction
aspect and explicitly mentions the same.
For the case of a funnel each device supplying trace should end up into an
input node - numbered with a unit - and all those nodes should point to the
output node as endpoints. Describing the hardware as a black box is probably
less of a good idea than showing that it’s a funnel, or replicator by showing
the internal paths. You wouldn’t need to “number” ports with a unit except
where the HW needs to differentiate between them, and you don’t need reg or a
node address to do it.
As I mentioned above, we need the hardware numbers to enable the "specific"
port.
E.g, :
static void funnel_enable_hw(struct funnel_drvdata *drvdata, int port)
{
u32 functl;
CS_UNLOCK(drvdata->base);
functl = readl_relaxed(drvdata->base + FUNNEL_FUNCTL);
functl &= ~FUNNEL_HOLDTIME_MASK;
functl |= FUNNEL_HOLDTIME;
functl |= (1 << port);
writel_relaxed(functl, drvdata->base + FUNNEL_FUNCTL);
writel_relaxed(drvdata->priority, drvdata->base + FUNNEL_PRICTL);
CS_LOCK(drvdata->base);
}
If you really need to parse full graphs in both directions (find root, find
leaf) then could we simply introduce properties which list the phandles of all
uplink sources, as linked lists point to the list head?
No we don't need to parse it in both ways, up and down. Btw, the trace paths
are not statically created. They are done at runtime, as configured by the
user. So all we need to do is have a list of the ports and the devices it
is connected to (of course with direction information). I would stay
away from duplicating the platform code when something already does
a good job.
This gives a way to validate that the graph starts and ends the way we expect,
and also allows every port to be associated with being a required path between
any two devices without parsing the *whole* graph (although you still need to
do that to find the route to sinks).
Coming back to your suggestion of "unit", what does it imply ?
Its too generic a term for something as concrete as a port number.
Cheers
Suzuki
Ta,
Matt
Sent from my iPhone
On Jun 13, 2018, at 04:45, Suzuki K Poulose wrote:
Hi Rob,
On 12/06/18 21:48, Rob Herring wrote:
On Fri, Jun 01, 2018 at 02:16:05PM +0100, Suzuki K Poulose wrote:
The coresight drivers relied on default bindings for graph
in DT, while reusing the "reg" field of the "ports" to indicate
the actual hardware port number for the connections. However,
with the rules getting stricter w.r.t to the address mismatch
with the label, it is no longer possible to use the port address
field for the hardware port number. Hence, we add an explicit
property to denote the hardware port number, "coresight,hwid"
which must be specified for each "endpoint".
Cc: Mathieu Poirier
Cc: Sudeep Holla
Cc: Rob Herring
Signed-off-by: Suzuki K Poulose
---
.../devicetree/bindings/arm/coresight.txt | 26 +---
drivers/hwtracing/coresight/of_coresight.c | 46 --
2 files changed, 54 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
b/Documentation/devicetree/bindings/arm/coresight.txt
index bd36e40..385581a 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -104,7 +104,11 @@ properties to uniquely identify the connection details.
"slave-mode"
* Hardware Port number at the component:
- - The hardware port number is assumed to be the address of the "port"
component.
+ - (Obsolete) The hardware port number is assumed to be the address of the
"port" component.
+ - Each "endpoint" must define the hardware port of the local end of the
+ connection using the following property:
+"coresight,hwid" - 32bit integer, hardware port number at the local end.
"coresight" is not a vendor and properties are in the form
[,].
OK. The issue here is that a coresight component
[PATCH v2 2/2] clk: qcom: Add display clock controller driver for SDM845
Add support for the display clock controller found on SDM845
based devices. This would allow display drivers to probe and
control their clocks.
Signed-off-by: Taniya Das
---
drivers/clk/qcom/Kconfig | 10 +
drivers/clk/qcom/Makefile| 1 +
drivers/clk/qcom/dispcc-sdm845.c | 674 +++
3 files changed, 685 insertions(+)
create mode 100644 drivers/clk/qcom/dispcc-sdm845.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 9c3480d..7300574 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -245,6 +245,16 @@ config SDM_VIDEOCC_845
Say Y if you want to support video devices and functionality such as
video encode and decode.
+config SDM_DISPCC_845
+ tristate "SDM845 Display Clock Controller"
+ select SDM_GCC_845
+ depends on COMMON_CLK_QCOM
+ help
+ Support for the display clock controller on Qualcomm Technologies, Inc
+ SDM845 devices.
+ Say Y if you want to support display devices and functionality such as
+ splash screen.
+
config SPMI_PMIC_CLKDIV
tristate "SPMI PMIC clkdiv Support"
depends on (COMMON_CLK_QCOM && SPMI) || COMPILE_TEST
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 762c011..2b041b2d 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o
obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
+obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o
obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
diff --git a/drivers/clk/qcom/dispcc-sdm845.c b/drivers/clk/qcom/dispcc-sdm845.c
new file mode 100644
index 000..af437e0
--- /dev/null
+++ b/drivers/clk/qcom/dispcc-sdm845.c
@@ -0,0 +1,674 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-rcg.h"
+#include "clk-regmap-divider.h"
+#include "common.h"
+#include "gdsc.h"
+#include "reset.h"
+
+enum {
+ P_BI_TCXO,
+ P_CORE_BI_PLL_TEST_SE,
+ P_DISP_CC_PLL0_OUT_MAIN,
+ P_DSI0_PHY_PLL_OUT_BYTECLK,
+ P_DSI0_PHY_PLL_OUT_DSICLK,
+ P_DSI1_PHY_PLL_OUT_BYTECLK,
+ P_DSI1_PHY_PLL_OUT_DSICLK,
+ P_GPLL0_OUT_MAIN,
+ P_GPLL0_OUT_MAIN_DIV,
+};
+
+static const struct parent_map disp_cc_parent_map_0[] = {
+ { P_BI_TCXO, 0 },
+ { P_DSI0_PHY_PLL_OUT_BYTECLK, 1 },
+ { P_DSI1_PHY_PLL_OUT_BYTECLK, 2 },
+ { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const disp_cc_parent_names_0[] = {
+ "bi_tcxo",
+ "dsi0_phy_pll_out_byteclk",
+ "dsi1_phy_pll_out_byteclk",
+ "core_bi_pll_test_se",
+};
+
+static const struct parent_map disp_cc_parent_map_2[] = {
+ { P_BI_TCXO, 0 },
+ { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const disp_cc_parent_names_2[] = {
+ "bi_tcxo",
+ "core_bi_pll_test_se",
+};
+
+static const struct parent_map disp_cc_parent_map_3[] = {
+ { P_BI_TCXO, 0 },
+ { P_DISP_CC_PLL0_OUT_MAIN, 1 },
+ { P_GPLL0_OUT_MAIN, 4 },
+ { P_GPLL0_OUT_MAIN_DIV, 5 },
+ { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const disp_cc_parent_names_3[] = {
+ "bi_tcxo",
+ "disp_cc_pll0",
+ "gcc_disp_gpll0_clk_src",
+ "gcc_disp_gpll0_div_clk_src",
+ "core_bi_pll_test_se",
+};
+
+static const struct parent_map disp_cc_parent_map_4[] = {
+ { P_BI_TCXO, 0 },
+ { P_DSI0_PHY_PLL_OUT_DSICLK, 1 },
+ { P_DSI1_PHY_PLL_OUT_DSICLK, 2 },
+ { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const disp_cc_parent_names_4[] = {
+ "bi_tcxo",
+ "dsi0_phy_pll_out_dsiclk",
+ "dsi1_phy_pll_out_dsiclk",
+ "core_bi_pll_test_se",
+};
+
+static struct clk_alpha_pll disp_cc_pll0 = {
+ .offset = 0x0,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
+ .clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_pll0",
+ .parent_names = (const char *[]){ "bi_tcxo" },
+ .num_parents = 1,
+ .ops = _alpha_pll_fabia_ops,
+ },
+ },
+};
+
+static struct clk_rcg2 disp_cc_mdss_byte0_clk_src = {
+ .cmd_rcgr = 0x20d0,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_0,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_byte0_clk_src",
+ .parent_names = disp_cc_parent_names_0,
+ .num_parents = 4,
+ .flags = CLK_SET_RATE_PARENT |
[GIT PULL] More ACPI updates for v4.18-rc1
Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.18-rc1-2 with top-most commit 674455326ee397bc8334920533f71090b61fa594 Merge branch 'acpica' on top of commit f4fe74cc909bf811cd9cc7fd84f5a7514e06a7e1 Merge tag 'acpi-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm to receive additional ACPI updates for 4.18-rc1. These update the ACPICA code in the kernel to upstream revision 20180531 including one important AML parser fix and updates related to the IORT table, make the kernel recognize the "Windows 2017.2" _OSI string and update the customized methods documentation. Specifics: - Update the ACPICA code in the kernel to upstream revision 20180531 including: * AML parser fix to continue loading tables after detecting an AML error (Erik Schmauss). * AML parser debug option to dump parse trees (Bob Moore). * Debugger updates (Bob Moore). * Initial bits of Unload () operator deprecation (Bob Moore). * Updates related to the IORT table (Robin Murphy). - Make Linux respond to the "Windows 2017.2" _OSI string which allows native Thunderbolt enumeration to be used on Dell systems and was unsafe before recent changes in the PCI subsystem (Mario Limonciello). - Update the ACPI method customization feature documentation (Erik Schmauss). Thanks! --- Bob Moore (5): ACPICA: Debugger: Add count of namespace nodes after namespace dump ACPICA: AML Parser: Add debug option to dump parse trees ACPICA: Debugger: Reduce verbosity for module-level code errors. ACPICA: Interpreter: Begin deprecation of Unload operator ACPICA: Update version to 20180531 Erik Schmauss (2): ACPI / Documentation: update ACPI customize method feature docs ACPICA: AML parser: attempt to continue loading table after error Mario Limonciello (1): ACPICA: Recognize the _OSI string "Windows 2017.2" Robin Murphy (2): ACPICA: IORT: Update for revision D ACPICA: IORT: Add PMCG node supprt --- Documentation/acpi/method-customizing.txt | 10 +++--- drivers/acpi/acpica/dbnames.c | 1 + drivers/acpi/acpica/dbobject.c| 23 +- drivers/acpi/acpica/dsdebug.c | 12 ++-- drivers/acpi/acpica/exconfig.c| 11 +++ drivers/acpi/acpica/nsdump.c | 3 ++ drivers/acpi/acpica/psloop.c | 51 ++- drivers/acpi/acpica/psobject.c| 30 ++ drivers/acpi/acpica/pswalk.c | 34 +++-- drivers/acpi/acpica/uterror.c | 10 +++--- drivers/acpi/acpica/utosi.c | 1 + include/acpi/acoutput.h | 4 ++- include/acpi/acpixf.h | 2 +- include/acpi/actbl2.h | 25 +++ include/acpi/actypes.h| 1 + 15 files changed, 192 insertions(+), 26 deletions(-)
[RFC PATCH] irqchip/gic-v3: Add quirk for msm8996 secured registers
Access to GICR_WAKER is restricted on msm8996 SoC. Its been more
than 2 years of wait for this to be fixed in firmware which is
not going anywhere. So add a quirk to not write to this register.
With this quirk MSM8996 can atleast boot out of mainline,
which can help community to work with boards based on MSM8996.
Without this patch Qualcomm DB820c board reboots when GICR_WAKER
is written to.
Signed-off-by: Srinivas Kandagatla
---
drivers/irqchip/irq-gic-v3.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 76ea56d779a1..d1bb2c0cce02 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -47,6 +47,8 @@ struct redist_region {
boolsingle_redist;
};
+#define GICV3_FLAGS_WORKAROUND_IW_GICR_WAKER (1ULL << 0)
+
struct gic_chip_data {
struct fwnode_handle*fwnode;
void __iomem*dist_base;
@@ -55,6 +57,7 @@ struct gic_chip_data {
struct irq_domain *domain;
u64 redist_stride;
u32 nr_redist_regions;
+ u64 flags;
boolhas_rss;
unsigned intirq_nr;
struct partition_desc *ppi_descs[16];
@@ -139,6 +142,9 @@ static void gic_enable_redist(bool enable)
u32 count = 100;/* 1s! */
u32 val;
+ if (gic_data.flags & GICV3_FLAGS_WORKAROUND_IW_GICR_WAKER)
+ return;
+
rbase = gic_data_rdist_rd_base();
val = readl_relaxed(rbase + GICR_WAKER);
@@ -1064,6 +1070,31 @@ static const struct irq_domain_ops partition_domain_ops
= {
.select = gic_irq_domain_select,
};
+static bool __maybe_unused gicv3_enable_quirk_msm8996(void *data)
+{
+ struct gic_chip_data *d = data;
+
+ d->flags |= GICV3_FLAGS_WORKAROUND_IW_GICR_WAKER;
+
+ return true;
+}
+
+static const struct gic_quirk gicv3_quirks[] = {
+ {
+ .desc = "GICV3: Qualcomm MSM8996 WAKER IW",
+ .iidr = 0x1070, /* MSM8996 */
+ .mask = 0x,
+ .init = gicv3_enable_quirk_msm8996,
+ },
+};
+
+static void gic_v3_enable_quirks(struct gic_chip_data *gic_data)
+{
+ u32 iidr = readl_relaxed(gic_data->dist_base + GICD_IIDR);
+
+ gic_enable_quirks(iidr, gicv3_quirks, gic_data);
+}
+
static int __init gic_init_bases(void __iomem *dist_base,
struct redist_region *rdist_regs,
u32 nr_redist_regions,
@@ -1126,6 +1157,7 @@ static int __init gic_init_bases(void __iomem *dist_base,
if (IS_ENABLED(CONFIG_ARM_GIC_V3_ITS) && gic_dist_supports_lpis())
its_init(handle, _data.rdists, gic_data.domain);
+ gic_v3_enable_quirks(_data);
gic_smp_init();
gic_dist_init();
gic_cpu_init();
--
2.16.2
[Fwd: avahi-daemon.service startup failure post kernel commit f396922d862a]
Well, the folks at "To:" below apparently don't want bug reports from non-subscribers (no mediation, simply rejected). Posting here simply because it may save some other busy person a bisection. Forwarded Message From: Mike Galbraith To: av...@lists.freedesktop.org Subject: avahi-daemon.service startup failure post kernel commit f396922d862a Date: Wed, 13 Jun 2018 13:32:25 +0200 Greetings, Service startup failure bisected to a kernel commit, but that commit points the finger at userspace, ergo an attempt to report it. Let's see if it bounces. homer:~ # systemctl status avahi-daemon ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2018-06-13 09:49:58 CEST; 1min 54s ago Process: 1930 ExecStart=/usr/sbin/avahi-daemon -s (code=exited, status=255) Main PID: 1930 (code=exited, status=255) Status: "avahi-daemon 0.6.32 exiting." Jun 13 09:49:58 homer systemd[1]: Started Avahi mDNS/DNS-SD Stack. Jun 13 09:49:58 homer avahi-daemon[1930]: Loading service file /etc/avahi/services/sftp-ssh.service. Jun 13 09:49:58 homer avahi-daemon[1930]: Loading service file /etc/avahi/services/ssh.service. Jun 13 09:49:58 homer avahi-daemon[1930]: SO_REUSEADDR failed: Structure needs cleaning Jun 13 09:49:58 homer avahi-daemon[1930]: SO_REUSEADDR failed: Structure needs cleaning Jun 13 09:49:58 homer avahi-daemon[1930]: Failed to create server: No suitable network protocol available Jun 13 09:49:58 homer avahi-daemon[1930]: avahi-daemon 0.6.32 exiting. Jun 13 09:49:58 homer systemd[1]: avahi-daemon.service: Main process exited, code=exited, status=255/n/a Jun 13 09:49:58 homer systemd[1]: avahi-daemon.service: Unit entered failed state. Jun 13 09:49:58 homer systemd[1]: avahi-daemon.service: Failed with result 'exit-code'. homer:~ # f396922d862aa05b53ad740596652691a723ee23 is the first bad commit commit f396922d862aa05b53ad740596652691a723ee23 Author: Maciej Żenczykowski Date: Sun Jun 3 10:47:05 2018 -0700 net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on bound sockets It is not safe to do so because such sockets are already in the hash tables and changing these options can result in invalidating the tb->fastreuse(port) caching. This can have later far reaching consequences wrt. bind conflict checks which rely on these caches (for optimization purposes). Not to mention that you can currently end up with two identical non-reuseport listening sockets bound to the same local ip:port by clearing reuseport on them after they've already both been bound. There is unfortunately no EISBOUND error or anything similar, and EISCONN seems to be misleading for a bound-but-not-connected socket, so use EUCLEAN 'Structure needs cleaning' which AFAICT is the closest you can get to meaning 'socket in bad state'. (although perhaps EINVAL wouldn't be a bad choice either?) This does unfortunately run the risk of breaking buggy userspace programs... Signed-off-by: Maciej Żenczykowski Cc: Eric Dumazet Change-Id: I77c2b3429b2fdf42671eee0fa7a8ba721c94963b Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller :04 04 39b702bc132c8aa812fbd452822a7047331553a1 e0ed7194986fd828073702d5346a4f91fbd6ea01 M net
Re: [PATCH 14/39] ovl: stack file ops
Al Viro: > I'd managed to push that particular nest of horrors out of mind ;-/ > Having dug out my notes from back then and grepped around... The real > mess is not even /proc/*/maps - it's /proc/*/map_files/* and yes, the > reasons for that kludge are still valid ;-/ ::: > Uses of ->vm_file (and rules for those) are too convoluted to untangle > at the moment. I still would love to get that straightened out, but > it's not this cycle fodder, more's the pity... I don't fully read this thread, but the discussion is related to the file path printed in /proc/$$/maps? If so, as just for your information, here is an approach that aufs took. In linux-v2.6 era, aufs tried implementing mmap by customzing address_space ops, but it was not good and failed completing the implementation. As wel as overlayfs, aufs has two struct file objects for a single a regular file. One is for a virtual aufs' entry, and the other is for a real layer's entry. When a user issues mmap(2) for the virtual file, aufs redirects the request to the real file on the layer internally. So the vm_file points to the real file. It means /proc/$$/maps prints the unexpected file path. Aufs added another struct file* vm_prfile in struct vma. It points to the virtual aufs file, and /proc/$$/maps prints vm_prfile instead of vm_file. Of cource, maintaining vm_prfile is important since vma may be merged or splitted. Still I don't like this approach, but I don't have another better idea, also it works for many years. You can get the patch in aufs4-standalone.git on sourceforge if you want. J. R. Okajima
Re: Quilt vs gmail (Was: [PATCH 0/3] sched/swait: Convert to full exclusive mode)
Hi Peter, Linus, Andreas,
On Tue, 12 Jun 2018 19:14:20 +0200, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 09:47:34AM -0700, Linus Torvalds wrote:
>
> > I do note how quilt emails are really hard to read, because that:
> >
> > Content-Disposition: inline
> >
> > makes gmail think it's flowed.
> >
> > Which works horribly badly for patches, surprise surprise.
> >
> > So I really wish quilt wouldn't do that. It does smell like a gmail
> > bug, but at the same time, why would you use "Content-Disposition:
> > inline" when you don't have an actual multi-part email? So I do blame
> > quilt too for sending nonsensical headers.
> >
> > (Yes, yes, I see the "It is permissible to use Content-Disposition on
> > the main body" in the RFC. But the RFC also makes it clear that it
> > actually matters for how things are presented, so saying "ok, I'll do
> > flowed" seems equally insane and equally technically RFC-compliant)
>
> Quilt people, anything that can be done about that?
The purpose of the Content-Disposition header is to let quilt store the
original patch file name, so that the recipient can save the email as a
patch file having the exact same name as the sender was using, to make
communication between developers easier. This is the reason why the
header is being added despite the email not being multi-part. As Linus
found out already, RFC 2183 allows that. The RFC also explicitly allows
the use of a filename parameter for inline parts (see section 2.3.)
Using "attachment" instead of "inline" would presumably force the user
to save the patch to a file before being able to read it, or, at least,
to take additional actions in the MUA to convince it to display the
contents inline regardless of what the Content-Disposition header
says. This is clearly not desirable.
We could try specifying the filename directly, without the "inline"
keyword, however that would no longer comply with the RFC
("disposition-parm" is optional, but "disposition-type" is mandatory)
and I am afraid that some MUA implementations would either default to
disposition-type "attachment" in this case, or ignore the header
altogether.
I'm not sure I understand what "flowed" means in this context. If you
mean that gmail breaks the formatting of the patch, I would say that
gmail is infringing the RFC, which clearly stipulates at the beginning
that the Content-Disposition header field is only about telling the MUA
which parts should be displayed immediately and which parts should not,
and not about presentation issues.
Considering that "inline" is the default for a non-multi-part message,
any MUA which changes its behavior in the presence of
"Content-Disposition: inline" is bugged in my opinion.
--
Jean Delvare
SUSE L3 Support
Re: [PATCH v2 2/2] clk: qcom: Add display clock controller driver for SDM845
Hi Taniya,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on clk/clk-next]
[also build test ERROR on next-20180613]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Taniya-Das/Add-display-clock-controller-driver-for-SDM845/20180613-183754
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh
All error/warnings (new ones prefixed by >>):
>> drivers/clk/qcom/dispcc-sdm845.c:130:2: error: implicit declaration of
>> function 'F' [-Werror=implicit-function-declaration]
F(1920, P_BI_TCXO, 1, 0, 0),
^
>> drivers/clk/qcom/dispcc-sdm845.c:130:2: error: initializer element is not
>> constant
drivers/clk/qcom/dispcc-sdm845.c:130:2: note: (near initialization for
'ftbl_disp_cc_mdss_esc0_clk_src[0].freq')
>> drivers/clk/qcom/dispcc-sdm845.c:131:2: warning: braces around scalar
>> initializer
{ }
^
drivers/clk/qcom/dispcc-sdm845.c:131:2: note: (near initialization for
'ftbl_disp_cc_mdss_esc0_clk_src[0].src')
drivers/clk/qcom/dispcc-sdm845.c:163:2: error: initializer element is not
constant
F(1920, P_BI_TCXO, 1, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:163:2: note: (near initialization for
'ftbl_disp_cc_mdss_mdp_clk_src[0].freq')
drivers/clk/qcom/dispcc-sdm845.c:164:2: error: initializer element is not
constant
F(85714286, P_GPLL0_OUT_MAIN, 7, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:164:2: note: (near initialization for
'ftbl_disp_cc_mdss_mdp_clk_src[0].src')
drivers/clk/qcom/dispcc-sdm845.c:165:2: error: initializer element is not
constant
F(1, P_GPLL0_OUT_MAIN, 6, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:165:2: note: (near initialization for
'ftbl_disp_cc_mdss_mdp_clk_src[0].pre_div')
drivers/clk/qcom/dispcc-sdm845.c:166:2: error: initializer element is not
constant
F(15000, P_GPLL0_OUT_MAIN, 4, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:166:2: note: (near initialization for
'ftbl_disp_cc_mdss_mdp_clk_src[0].m')
drivers/clk/qcom/dispcc-sdm845.c:167:2: error: initializer element is not
constant
F(171428571, P_GPLL0_OUT_MAIN, 3.5, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:167:2: note: (near initialization for
'ftbl_disp_cc_mdss_mdp_clk_src[0].n')
drivers/clk/qcom/dispcc-sdm845.c:168:2: error: initializer element is not
constant
F(2, P_GPLL0_OUT_MAIN, 3, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:168:2: note: (near initialization for
'ftbl_disp_cc_mdss_mdp_clk_src[1].freq')
drivers/clk/qcom/dispcc-sdm845.c:169:2: error: initializer element is not
constant
F(3, P_GPLL0_OUT_MAIN, 2, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:169:2: note: (near initialization for
'ftbl_disp_cc_mdss_mdp_clk_src[1].src')
drivers/clk/qcom/dispcc-sdm845.c:170:2: error: initializer element is not
constant
F(34400, P_DISP_CC_PLL0_OUT_MAIN, 2.5, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:170:2: note: (near initialization for
'ftbl_disp_cc_mdss_mdp_clk_src[1].pre_div')
drivers/clk/qcom/dispcc-sdm845.c:171:2: error: initializer element is not
constant
F(43000, P_DISP_CC_PLL0_OUT_MAIN, 2, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:171:2: note: (near initialization for
'ftbl_disp_cc_mdss_mdp_clk_src[1].m')
drivers/clk/qcom/dispcc-sdm845.c:172:2: warning: braces around scalar
initializer
{ }
^
drivers/clk/qcom/dispcc-sdm845.c:172:2: note: (near initialization for
'ftbl_disp_cc_mdss_mdp_clk_src[1].n')
drivers/clk/qcom/dispcc-sdm845.c:218:2: error: initializer element is not
constant
F(1920, P_BI_TCXO, 1, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:218:2: note: (near initialization for
'ftbl_disp_cc_mdss_rot_clk_src[0].freq')
drivers/clk/qcom/dispcc-sdm845.c:219:2: error: initializer element is not
constant
F(171428571, P_GPLL0_OUT_MAIN, 3.5, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:219:2: note: (near initialization for
'ftbl_disp_cc_mdss_rot_clk_src[0].src')
drivers/clk/qcom/dispcc-sdm845.c:220:2: error: initializer element is not
constant
F(3, P_GPLL0_OUT_MAIN, 2, 0, 0),
^
drivers/clk/qcom/dispcc-sdm845.c:220:2: note: (near initialization for
'ftbl_disp_cc_mdss_rot_clk_src[0].pre_div')
drivers/clk/qcom/dispcc-sdm845.c:221:2: error: initializer element is not
constant
F(34400, P_DISP_CC_PLL0_OUT_MAIN, 2.5, 0, 0),
^
drivers/clk/qcom/dispcc-
[PATCH 3/5] soc: qcom: smp2p: Add select IRQ_DOMAIN
Since we are using irq_domain_add_linear(), add a select on IRQ_DOMAIN. This is needed in order to be able to remove the depends on ARCH_QCOM. drivers/soc/qcom/smp2p.c: In function ‘qcom_smp2p_inbound_entry’: drivers/soc/qcom/smp2p.c:317:18: error: implicit declaration of function ‘irq_domain_add_linear’ entry->domain = irq_domain_add_linear(node, 32, _irq_ops, entry); ^ Signed-off-by: Niklas Cassel --- drivers/soc/qcom/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig index 9dc02f390ba3..2f59d0a835fd 100644 --- a/drivers/soc/qcom/Kconfig +++ b/drivers/soc/qcom/Kconfig @@ -106,6 +106,7 @@ config QCOM_SMP2P depends on MAILBOX depends on QCOM_SMEM select QCOM_SMEM_STATE + select IRQ_DOMAIN help Say yes here to support the Qualcomm Shared Memory Point to Point protocol. -- 2.17.1
