[PATCH V9 1/3] dt-bindings: mmc: tegra: Add supports-cqe property
Add supports-cqe optional property for Tegra SDMMC. Tegra186 and Tegra194 supports HW Command queue only on SDMMC4 controller. This property is used to identify command queue support controller in the tegra sdhci driver. Signed-off-by: Sowjanya Komatineni --- Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt index 32b4b4e41923..fb14c2c8d7ee 100644 --- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt @@ -72,6 +72,10 @@ Optional properties for Tegra210 and Tegra186: - nvidia,default-trim : Specify the default outbound clock trimmer value. - nvidia,dqs-trim : Specify DQS trim value for HS400 timing +- supports-cqe : The presence of this property indicates that the + corresponding controller supports HW command queue feature. + Tegra186 and Tegra194 has 4 SDMMC Controllers and only SDMMC4 + controller supports HW Command Queue with eMMC device. Notes on the pad calibration pull up and pulldown offset values: - The property values are drive codes which are programmed into the -- 2.7.4
[PATCH V9 3/3] mmc: tegra: HW Command Queue Support for Tegra SDMMC
This patch adds HW Command Queue for supported Tegra SDMMC
controllers.
Signed-off-by: Sowjanya Komatineni
---
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-tegra.c | 117 +++--
drivers/mmc/host/sdhci.c | 9 +++-
drivers/mmc/host/sdhci.h | 2 +
4 files changed, 124 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index e26b8145efb3..0739d26c001b 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -250,6 +250,7 @@ config MMC_SDHCI_TEGRA
depends on ARCH_TEGRA
depends on MMC_SDHCI_PLTFM
select MMC_SDHCI_IO_ACCESSORS
+ select MMC_CQHCI
help
This selects the Tegra SD/MMC controller. If you have a Tegra
platform with SD or MMC devices, say Y or M here.
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index e6ace31e2a41..d400f158bee4 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -33,6 +33,7 @@
#include
#include "sdhci-pltfm.h"
+#include "cqhci.h"
/* Tegra SDHOST controller vendor register definitions */
#define SDHCI_TEGRA_VENDOR_CLOCK_CTRL 0x100
@@ -89,6 +90,9 @@
#define NVQUIRK_NEEDS_PAD_CONTROL BIT(7)
#define NVQUIRK_DIS_CARD_CLK_CONFIG_TAPBIT(8)
+/* SDMMC CQE Base Address for Tegra Host Ver 4.1 and Higher */
+#define SDHCI_TEGRA_CQE_BASE_ADDR 0xF000
+
struct sdhci_tegra_soc_data {
const struct sdhci_pltfm_data *pdata;
u32 nvquirks;
@@ -128,6 +132,7 @@ struct sdhci_tegra {
u32 default_tap;
u32 default_trim;
u32 dqs_trim;
+ bool enable_hwcq;
};
static u16 tegra_sdhci_readw(struct sdhci_host *host, int reg)
@@ -595,6 +600,20 @@ static void tegra_sdhci_parse_tap_and_trim(struct
sdhci_host *host)
tegra_host->dqs_trim = 0x11;
}
+static void tegra_sdhci_parse_dt(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
+
+ if (device_property_read_bool(host->mmc->parent, "supports-cqe"))
+ tegra_host->enable_hwcq = true;
+ else
+ tegra_host->enable_hwcq = false;
+
+ tegra_sdhci_parse_pad_autocal_dt(host);
+ tegra_sdhci_parse_tap_and_trim(host);
+}
+
static void tegra_sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -836,6 +855,49 @@ static void tegra_sdhci_voltage_switch(struct sdhci_host
*host)
tegra_host->pad_calib_required = true;
}
+static void sdhci_tegra_cqe_enable(struct mmc_host *mmc)
+{
+ struct cqhci_host *cq_host = mmc->cqe_private;
+ u32 cqcfg = 0;
+
+ /*
+* Tegra SDMMC Controller design prevents write access to BLOCK_COUNT
+* registers when CQE is enabled.
+*/
+ cqcfg = cqhci_readl(cq_host, CQHCI_CFG);
+ if (cqcfg & CQHCI_ENABLE)
+ cqhci_writel(cq_host, (cqcfg & ~CQHCI_ENABLE), CQHCI_CFG);
+
+ sdhci_cqe_enable(mmc);
+
+ if (cqcfg & CQHCI_ENABLE)
+ cqhci_writel(cq_host, cqcfg, CQHCI_CFG);
+}
+
+static void sdhci_tegra_dumpregs(struct mmc_host *mmc)
+{
+ sdhci_dumpregs(mmc_priv(mmc));
+}
+
+static u32 sdhci_tegra_cqhci_irq(struct sdhci_host *host, u32 intmask)
+{
+ int cmd_error = 0;
+ int data_error = 0;
+
+ if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
+ return intmask;
+
+ cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+
+ return 0;
+}
+
+static const struct cqhci_host_ops sdhci_tegra_cqhci_ops = {
+ .enable = sdhci_tegra_cqe_enable,
+ .disable = sdhci_cqe_disable,
+ .dumpregs = sdhci_tegra_dumpregs,
+};
+
static const struct sdhci_ops tegra_sdhci_ops = {
.get_ro = tegra_sdhci_get_ro,
.read_w = tegra_sdhci_readw,
@@ -989,6 +1051,7 @@ static const struct sdhci_ops tegra186_sdhci_ops = {
.set_uhs_signaling = tegra_sdhci_set_uhs_signaling,
.voltage_switch = tegra_sdhci_voltage_switch,
.get_max_clock = tegra_sdhci_get_max_clock,
+ .irq = sdhci_tegra_cqhci_irq,
};
static const struct sdhci_pltfm_data sdhci_tegra186_pdata = {
@@ -1030,6 +1093,54 @@ static const struct of_device_id sdhci_tegra_dt_match[]
= {
};
MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match);
+static int sdhci_tegra_add_host(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
+ struct cqhci_host *cq_host;
+ bool dma64;
+ int ret;
+
+ if (!tegra_host->enable_hwcq)
+ return sdhci_add_host(host);
+
+ sdhci_enable_v4_mode(host);
+
+ ret = sdhci_setup_host(host);
+ i
[PATCH V9 2/3] arm64: dts: tegra: Add CQE Support for SDMMC4
Add CQE Support for Tegra186 and Tegra194 SDMMC4 controller Signed-off-by: Sowjanya Komatineni --- arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 + arch/arm64/boot/dts/nvidia/tegra194.dtsi | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi index 22815db4a3ed..3dfdc4701934 100644 --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi @@ -319,6 +319,7 @@ nvidia,default-trim = <0x9>; nvidia,dqs-trim = <63>; mmc-hs400-1_8v; + supports-cqe; status = "disabled"; }; diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi index 6dfa1ca0b851..9ce1c91d4596 100644 --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi @@ -325,6 +325,7 @@ clock-names = "sdhci"; resets = <&bpmp TEGRA194_RESET_SDMMC4>; reset-names = "sdhci"; + supports-cqe; status = "disabled"; }; -- 2.7.4
Re: [PATCH v1 03/10] cpufreq: Replace open-coded << with BIT()
Quoting Amit Kucheria (2019-01-14 08:34:55) > Minor clean-up to use BIT() and keep checkpatch happy. Clean up the > comment formatting while we're at it to make it easier to read. > > Signed-off-by: Amit Kucheria > --- Reviewed-by: Stephen Boyd
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/15/19 10:38 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
On 1/14/19 11:13 AM, Liam Mark wrote:
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses from the CPU to a cached heap should be bracketed with
{begin,end}_cpu_access calls so maintenance should not be needed anyway.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 14e48f6eb734..09cb5a8e2b09 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
dma_buf_attachment *attachment,
table = a->table;
- if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
- direction))
+ if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
+ direction, DMA_ATTR_SKIP_CPU_SYNC))
Unfortunately I don't think you can do this for a couple reasons.
You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
If the calls to {begin,end}_cpu_access were made before the call to
dma_buf_attach then there won't have been a device attached so the calls
to {begin,end}_cpu_access won't have done any cache maintenance.
That should be okay though, if you have no attachments (or all
attachments are IO-coherent) then there is no need for cache
maintenance. Unless you mean a sequence where a non-io-coherent device
is attached later after data has already been written. Does that
sequence need supporting?
Yes, but also I think there are cases where CPU access can happen before
in Android, but I will focus on later for now.
DMA-BUF doesn't have to allocate the backing
memory until map_dma_buf() time, and that should only happen after all
the devices have attached so it can know where to put the buffer. So we
shouldn't expect any CPU access to buffers before all the devices are
attached and mapped, right?
Here is an example where CPU access can happen later in Android.
Camera device records video -> software post processing -> video device
(who does compression of raw data) and writes to a file
In this example assume the buffer is cached and the devices are not
IO-coherent (quite common).
This is the start of the problem, having cached mappings of memory that
is also being accessed non-coherently is going to cause issues one way
or another. On top of the speculative cache fills that have to be
constantly fought back against with CMOs like below; some coherent
interconnects behave badly when you mix coherent and non-coherent access
(snoop filters get messed up).
The solution is to either always have the addresses marked non-coherent
(like device memory, no-map carveouts), or if you really want to use
regular system memory allocated at runtime, then all cached mappings of
it need to be dropped, even the kernel logical address (area as painful
as that would be).
I agree it's broken, hence my desire to remove it :)
The other problem is that uncached buffers are being used for
performance reason so anything that would involve getting
rid of the logical address would probably negate any performance
benefit.
ION buffer is allocated.
//Camera device records video
dma_buf_attach
dma_map_attachment (buffer needs to be cleaned)
Why does the buffer need to be cleaned here? I just got through reading
the thread linked by Laura in the other reply. I do like +Brian's
suggestion of tracking if the buffer has had CPU access since the last
time and only flushing the cache if it has. As unmapped heaps never get
CPU mapped this would never be the case for unmapped heaps, it solves my
problem.
[camera device writes to buffer]
dma_buf_unmap_attachment (buffer needs to be invalidated)
It doesn't know there will be any further CPU access, it could get freed
after this for all we know, the invalidate can be saved until the CPU
requests access again.
dma_buf_detach (device cannot stay attached because it is being sent down
the pipeline and Camera doesn't know the end of the use case)
This seems like a broken use-case, I understand the desire to keep
everything as modular as possible and separate the steps, but at this
point no one owns this buffers backing memory, not the CPU or any
device. I would go as far as to say DMA-BUF should be free now to
de-allocate the backing storage if it wants, that way it could get ready
for the next attachment, which may change the required backing memory
completely.
All devices should attach before the first mapping, and only let go
after the task is complete, otherwise this buffers data needs copied off
to a different location or the CPU needs to take ownership in-between.
Maybe it's broken but it's the status quo and we spent a good
am
Re: [PATCH v2] acpi: fix a potential inconsistency caused by double-fetch
On Tue, Jan 15, 2019 at 7:05 AM Kangjie Lu wrote:
>
>
>
> On Mon, Jan 14, 2019 at 5:15 AM Rafael J. Wysocki wrote:
>>
>> On Wed, Jan 9, 2019 at 9:14 AM Kangjie Lu wrote:
>> >
>> > "user_buf->length" is in user space, and copied in twice. The second
>> > copy is after it passes the security check. If a user program races to
>> > change user_buf->length in user space, the data fetched in the second
>> > copy may invalidate the security check. The fix avoids the double-fetch
>> > issue by using the value passing the security check.
>>
>> AFAICS the patch really does two things: it avoids the issue described
>> above and avoids using the (redundant) 'table' local variable on the
>> stack. Arguably, you could fix the issue without getting rid of the
>> redundant variable.
>>
>> >
>> > Signed-off-by: Kangjie Lu
>> > ---
>> > drivers/acpi/custom_method.c | 10 ++
>> > 1 file changed, 6 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
>> > index 4451877f83b6..f10ee0519033 100644
>> > --- a/drivers/acpi/custom_method.c
>> > +++ b/drivers/acpi/custom_method.c
>> > @@ -26,17 +26,16 @@ static ssize_t cm_write(struct file *file, const char
>> > __user * user_buf,
>> > static u32 max_size;
>> > static u32 uncopied_bytes;
>> >
>> > - struct acpi_table_header table;
>> > acpi_status status;
>> >
>> > if (!(*ppos)) {
>> > /* parse the table header to get the table length */
>> > if (count <= sizeof(struct acpi_table_header))
>> > return -EINVAL;
>> > - if (copy_from_user(&table, user_buf,
>> > - sizeof(struct acpi_table_header)))
>> > + if (get_user(max_size,
>> > + &((struct acpi_table_header
>> > *)user_buf)->length))
>> > return -EFAULT;
>> > - uncopied_bytes = max_size = table.length;
>> > + uncopied_bytes = max_size;
>> > buf = kzalloc(max_size, GFP_KERNEL);
>> > if (!buf)
>> > return -ENOMEM;
>> > @@ -57,6 +56,9 @@ static ssize_t cm_write(struct file *file, const char
>> > __user * user_buf,
>> > return -EFAULT;
>> > }
>> >
>> > + /* Ensure table length is not changed in the second copy */
>> > + ((struct acpi_table_header *)(buf + (*ppos)))->length = max_size;
>>
>> Why don't you return -EFAULT if max_size is different from ->length?
>> Surely, the table should not be used at all in that case.
>
>
> We could do either, but I didn't see one is clearly better than the other.
As I said, why would you use any inconsistent data instead of
returning an error?
>>
>> Moreover, wouldn't it be even better to compare the entire header with
>> the one read previously and return -EFAULT if they don't match?
>
>
> If other fields are not critical and thus not checked, we don't have to
> compare
> the entire header for better performance reasons.
If you really care about consistency, performance doesn't matter that much.
Thanks,
Rafael
Re: [PATCH] kvm: add proper frame pointer logic for vmx
+cc Josh Josh, The issue we're encountering is that vmx_vcpu_run() is marked with STACK_FRAME_NON_STANDARD because %rbp is saved/modified/restored when transitioning to/from the guest. But vmx_vcpu_run() also happens to be a giant blob of code that gcc will sometime split into separate .part.* functions, which means that objtool's symbol lookup to whitelist the function doesn't work. On Tue, Jan 15, 2019 at 11:43:20AM -0500, Qian Cai wrote: > > > On 1/15/19 2:13 AM, Paolo Bonzini wrote: > > Hmm, maybe like this: > > > > diff --git a/arch/x86/kvm/vmx/vmenter.S b/arch/x86/kvm/vmx/vmenter.S > > index bcef2c7e9bc4..33122fa9d4bd 100644 > > --- a/arch/x86/kvm/vmx/vmenter.S > > +++ b/arch/x86/kvm/vmx/vmenter.S > > @@ -26,19 +26,17 @@ ENTRY(vmx_vmenter) > > ret > > > > 2: vmlaunch > > +3: > > ret > > > > -3: cmpb $0, kvm_rebooting > > - jne 4f > > - call kvm_spurious_fault > > -4: ret > > - > > .pushsection .fixup, "ax" > > -5: jmp 3b > > +4: cmpb $0, kvm_rebooting > > + jne 3b > > + jmp kvm_spurious_fault > > .popsection > > > > - _ASM_EXTABLE(1b, 5b) > > - _ASM_EXTABLE(2b, 5b) > > + _ASM_EXTABLE(1b, 4b) > > + _ASM_EXTABLE(2b, 4b) > > > > ENDPROC(vmx_vmenter) > > No, that will not work. The problem is in vmx.o where I just sent another > patch > for it. > > I can see there are five options to solve it. > > 1) always inline vmx_vcpu_run() > 2) always noinline vmx_vcpu_run() > 3) add -fdiable-ipa-fnsplit option to Makefile for vmx.o > 4) let STACK_FRAME_NON_STANDARD support part.* syntax. > 5) trim-down vmx_vcpu_run() even more to not causing splitting by GCC. > > Option 1) and 2) seems give away the decision for user with > CONFIG_CC_OPTIMIZE_FOR_(PERFORMANCE/SIZE). > > Option 3) prevents other functions there for splitting for optimization. > > Option 4) and 5) seems tricky to implement. > > I am not more leaning to 3) as only other fuction will miss splitting is > vmx_segment_access_rights(). Option 4) is the most correct, but "tricky" is an understatement. Unless Josh is willing to pick up the task it'll likely have to wait. There's actually a few more options: 6) Replace "pop %rbp" in the vmx_vmenter() asm blob with an open-coded equivalent, e.g. "mov [%rsp], %rbp; add $8, %rsp". This runs an end- around on objtool since objtool explicitly keys off "pop %rbp" and NOT "mov ..., %rbp" (which is probably an objtool checking flaw?"). 7) Move the vmx_vmenter() asm blob and a few other lines of code into a separate helper, e.g. __vmx_vcpu_run(), and mark that as having a non-standard stack frame. Option 6) is an ugly (but amusing) hack. Arguably we should do option 7) regardless of whether or not objtool gets updated to support fnsplit behavior, as it it allows objtool to do proper stack checking on the bulk of vmx_vcpu_run(). And it's a pretty trivial change. I'll send a patch for option 7), which in theory should fix the warning for all .configs.
Applied "ASoC: imx-audmux: change snprintf to scnprintf for possible overflow" to the asoc tree
The patch
ASoC: imx-audmux: change snprintf to scnprintf for possible overflow
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From c407cd008fd039320d147088b52d0fa34ed3ddcb Mon Sep 17 00:00:00 2001
From: Silvio Cesare
Date: Tue, 15 Jan 2019 04:27:27 +0100
Subject: [PATCH] ASoC: imx-audmux: change snprintf to scnprintf for possible
overflow
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up larger than SIZE. In later
uses of snprintf, SIZE - size will result in a negative number, leading
to problems. Note that size might already be too large by using
size = snprintf before the code reaches a case of size += snprintf.
2) If size is ultimately used as a length parameter for a copy back to user
space, then it will potentially allow for a buffer overflow and information
disclosure when size is greater than SIZE. When the size is used to index
the buffer directly, we can have memory corruption. This also means when
size = snprintf... is used, it may also cause problems since size may become
large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
configuration.
The solution to these issues is to use scnprintf which returns the number of
characters actually written to the buffer, so the size variable will never
exceed SIZE.
Signed-off-by: Silvio Cesare
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Mark Brown
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Dan Carpenter
Cc: Kees Cook
Cc: Will Deacon
Cc: Greg KH
Signed-off-by: Willy Tarreau
Acked-by: Nicolin Chen
Reviewed-by: Kees Cook
Signed-off-by: Mark Brown
---
sound/soc/fsl/imx-audmux.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/sound/soc/fsl/imx-audmux.c b/sound/soc/fsl/imx-audmux.c
index 392d5eef356d..99e07b01a2ce 100644
--- a/sound/soc/fsl/imx-audmux.c
+++ b/sound/soc/fsl/imx-audmux.c
@@ -86,49 +86,49 @@ static ssize_t audmux_read_file(struct file *file, char
__user *user_buf,
if (!buf)
return -ENOMEM;
- ret = snprintf(buf, PAGE_SIZE, "PDCR: %08x\nPTCR: %08x\n",
+ ret = scnprintf(buf, PAGE_SIZE, "PDCR: %08x\nPTCR: %08x\n",
pdcr, ptcr);
if (ptcr & IMX_AUDMUX_V2_PTCR_TFSDIR)
- ret += snprintf(buf + ret, PAGE_SIZE - ret,
+ ret += scnprintf(buf + ret, PAGE_SIZE - ret,
"TxFS output from %s, ",
audmux_port_string((ptcr >> 27) & 0x7));
else
- ret += snprintf(buf + ret, PAGE_SIZE - ret,
+ ret += scnprintf(buf + ret, PAGE_SIZE - ret,
"TxFS input, ");
if (ptcr & IMX_AUDMUX_V2_PTCR_TCLKDIR)
- ret += snprintf(buf + ret, PAGE_SIZE - ret,
+ ret += scnprintf(buf + ret, PAGE_SIZE - ret,
"TxClk output from %s",
audmux_port_string((ptcr >> 22) & 0x7));
else
- ret += snprintf(buf + ret, PAGE_SIZE - ret,
+ ret += scnprintf(buf + ret, PAGE_SIZE - ret,
"TxClk input");
- ret += snprintf(buf + ret, PAGE_SIZE - ret, "\n");
+ ret += scnprintf(buf + ret, PAGE_SIZE - ret, "\n");
if (ptcr & IMX_AUDMUX_V2_PTCR_SYN) {
- ret += snprintf(buf + ret, PAGE_SIZE - ret,
+ ret += scnprintf(buf + ret, PAGE_SIZE - ret,
"Port is symmetric");
} else {
if (ptcr & IMX_AUDMUX_V2_PTCR_RFSDIR)
- ret += snprintf(buf + ret, PAGE_SIZE - ret,
+ ret += scnprintf(buf + ret, PAGE_SIZE - ret,
"RxFS output from %s, ",
audmux_port_string((ptcr >> 17) & 0x7));
else
- ret += snprintf(buf + ret, PAGE_SIZE - ret,
+ ret += scnprintf(buf
Re: [PATCH] kvm: add proper frame pointer logic for vmx
+cc Josh, for real this time. On Tue, Jan 15, 2019 at 11:06:17AM -0800, Sean Christopherson wrote: > +cc Josh > > Josh, > > The issue we're encountering is that vmx_vcpu_run() is marked with > STACK_FRAME_NON_STANDARD because %rbp is saved/modified/restored when > transitioning to/from the guest. But vmx_vcpu_run() also happens to > be a giant blob of code that gcc will sometime split into separate > .part.* functions, which means that objtool's symbol lookup to whitelist > the function doesn't work. > > On Tue, Jan 15, 2019 at 11:43:20AM -0500, Qian Cai wrote: > > > > > > On 1/15/19 2:13 AM, Paolo Bonzini wrote: > > > Hmm, maybe like this: > > > > > > diff --git a/arch/x86/kvm/vmx/vmenter.S b/arch/x86/kvm/vmx/vmenter.S > > > index bcef2c7e9bc4..33122fa9d4bd 100644 > > > --- a/arch/x86/kvm/vmx/vmenter.S > > > +++ b/arch/x86/kvm/vmx/vmenter.S > > > @@ -26,19 +26,17 @@ ENTRY(vmx_vmenter) > > > ret > > > > > > 2: vmlaunch > > > +3: > > > ret > > > > > > -3: cmpb $0, kvm_rebooting > > > - jne 4f > > > - call kvm_spurious_fault > > > -4: ret > > > - > > > .pushsection .fixup, "ax" > > > -5: jmp 3b > > > +4: cmpb $0, kvm_rebooting > > > + jne 3b > > > + jmp kvm_spurious_fault > > > .popsection > > > > > > - _ASM_EXTABLE(1b, 5b) > > > - _ASM_EXTABLE(2b, 5b) > > > + _ASM_EXTABLE(1b, 4b) > > > + _ASM_EXTABLE(2b, 4b) > > > > > > ENDPROC(vmx_vmenter) > > > > No, that will not work. The problem is in vmx.o where I just sent another > > patch > > for it. > > > > I can see there are five options to solve it. > > > > 1) always inline vmx_vcpu_run() > > 2) always noinline vmx_vcpu_run() > > 3) add -fdiable-ipa-fnsplit option to Makefile for vmx.o > > 4) let STACK_FRAME_NON_STANDARD support part.* syntax. > > 5) trim-down vmx_vcpu_run() even more to not causing splitting by GCC. > > > > Option 1) and 2) seems give away the decision for user with > > CONFIG_CC_OPTIMIZE_FOR_(PERFORMANCE/SIZE). > > > > Option 3) prevents other functions there for splitting for optimization. > > > > Option 4) and 5) seems tricky to implement. > > > > I am not more leaning to 3) as only other fuction will miss splitting is > > vmx_segment_access_rights(). > > Option 4) is the most correct, but "tricky" is an understatement. Unless > Josh is willing to pick up the task it'll likely have to wait. > > There's actually a few more options: > > 6) Replace "pop %rbp" in the vmx_vmenter() asm blob with an open-coded > equivalent, e.g. "mov [%rsp], %rbp; add $8, %rsp". This runs an end- > around on objtool since objtool explicitly keys off "pop %rbp" and NOT > "mov ..., %rbp" (which is probably an objtool checking flaw?"). > > 7) Move the vmx_vmenter() asm blob and a few other lines of code into a > separate helper, e.g. __vmx_vcpu_run(), and mark that as having a > non-standard stack frame. > > Option 6) is an ugly (but amusing) hack. > > Arguably we should do option 7) regardless of whether or not objtool gets > updated to support fnsplit behavior, as it it allows objtool to do proper > stack checking on the bulk of vmx_vcpu_run(). And it's a pretty trivial > change. > > I'll send a patch for option 7), which in theory should fix the warning > for all .configs.
Applied "spi: omap2-mcspi: Fix DMA and FIFO event trigger size mismatch" to the spi tree
The patch
spi: omap2-mcspi: Fix DMA and FIFO event trigger size mismatch
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From baf8b9f8d260c55a86405f70a384c29cda888476 Mon Sep 17 00:00:00 2001
From: Vignesh R
Date: Tue, 15 Jan 2019 12:28:32 +0530
Subject: [PATCH] spi: omap2-mcspi: Fix DMA and FIFO event trigger size
mismatch
Commit b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word
length")
broke SPI transfers where bits_per_word != 8. This is because of
mimsatch between McSPI FIFO level event trigger size (SPI word length) and
DMA request size(word length * maxburst). This leads to data
corruption, lockup and errors like:
spi1.0: EOW timed out
Fix this by setting DMA maxburst size to 1 so that
McSPI FIFO level event trigger size matches DMA request size.
Fixes: b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word
length")
Cc: sta...@vger.kernel.org
Reported-by: David Lechner
Tested-by: David Lechner
Signed-off-by: Vignesh R
Signed-off-by: Mark Brown
---
drivers/spi/spi-omap2-mcspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 2fd8881fcd65..8be304379628 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -623,8 +623,8 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
cfg.dst_addr = cs->phys + OMAP2_MCSPI_TX0;
cfg.src_addr_width = width;
cfg.dst_addr_width = width;
- cfg.src_maxburst = es;
- cfg.dst_maxburst = es;
+ cfg.src_maxburst = 1;
+ cfg.dst_maxburst = 1;
rx = xfer->rx_buf;
tx = xfer->tx_buf;
--
2.20.1
Applied "spi: sprd: Fix the error data length in SPI read-only mode" to the spi tree
The patch
spi: sprd: Fix the error data length in SPI read-only mode
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 63f5ffc46d4f53b309a93b83420b2e4bd0da5aba Mon Sep 17 00:00:00 2001
From: Lanqing Liu
Date: Tue, 15 Jan 2019 21:46:50 +0800
Subject: [PATCH] spi: sprd: Fix the error data length in SPI read-only mode
In SPI read-only mode, we will always return the writing length,
which is always the power of "bits_per_word", but the length unit
using by users is byte.
Thus this patch fixes the returning length by getting from
read_bufs() function to get the correct length.
Signed-off-by: Lanqing Liu
Signed-off-by: Baolin Wang
Signed-off-by: Mark Brown
---
drivers/spi/spi-sprd.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-sprd.c b/drivers/spi/spi-sprd.c
index 8daa24eec624..fa324ce194b2 100644
--- a/drivers/spi/spi-sprd.c
+++ b/drivers/spi/spi-sprd.c
@@ -380,7 +380,7 @@ static int sprd_spi_txrx_bufs(struct spi_device *sdev,
struct spi_transfer *t)
{
struct sprd_spi *ss = spi_controller_get_devdata(sdev->controller);
u32 trans_len = ss->trans_len, len;
- int ret, write_size = 0;
+ int ret, write_size = 0, read_size = 0;
while (trans_len) {
len = trans_len > SPRD_SPI_FIFO_SIZE ? SPRD_SPI_FIFO_SIZE :
@@ -416,13 +416,15 @@ static int sprd_spi_txrx_bufs(struct spi_device *sdev,
struct spi_transfer *t)
goto complete;
if (ss->trans_mode & SPRD_SPI_RX_MODE)
- ss->read_bufs(ss, len);
+ read_size += ss->read_bufs(ss, len);
trans_len -= len;
}
- ret = write_size;
-
+ if (ss->trans_mode & SPRD_SPI_TX_MODE)
+ ret = write_size;
+ else
+ ret = read_size;
complete:
sprd_spi_enter_idle(ss);
--
2.20.1
Re: [PATCH] genirq/affinity: Assign default affinity to pre/post vectors
On Mon, 31 Dec 2018, Huacai Chen wrote: > Generally, irq_create_affinity_masks() assign default affinity to pre/ > post vectors correctly. However, it ignore the case that there are only > pre/post vectors (when nvecs == affd->pre_vectors + affd->post_vectors) > and return NULL. This case usually happens when nvecs = 1 (e.g. in nvme > driver when MSI-X is unavailable and fallback to MSI) and will trigger > the warning in pci_irq_get_affinity(). This patch fix the corner case. Errm. This is just wrong. When this function returns NULL, then it has failed and the caller or any subsequent code is not supposed to use the result. The function can return NULL for other reasons, e.g. when the memory allocation failed. How are you going to duct tape that one? Thanks, tglx
Re: [PATCH 14/14] staging: android: ion: Add UNMAPPED heap type and helper
On 1/15/19 10:43 AM, Laura Abbott wrote:
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firewalls. This memory can still be
allocated from and used by devices that do have access to the
backing memory.
Based originally on the secure/unmapped heap from Linaro for
the OP-TEE SDP implementation, this was re-written to match
the carveout heap helper code.
Suggested-by: Etienne Carriere
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/Kconfig | 10 ++
drivers/staging/android/ion/Makefile | 1 +
drivers/staging/android/ion/ion.h | 16 +++
.../staging/android/ion/ion_unmapped_heap.c | 123 ++
drivers/staging/android/uapi/ion.h | 3 +
5 files changed, 153 insertions(+)
create mode 100644 drivers/staging/android/ion/ion_unmapped_heap.c
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 0fdda6f62953..a117b8b91b14 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -42,3 +42,13 @@ config ION_CMA_HEAP
Choose this option to enable CMA heaps with Ion. This heap is
backed
by the Contiguous Memory Allocator (CMA). If your system has
these
regions, you should say Y here.
+
+config ION_UNMAPPED_HEAP
+ bool "ION unmapped heap support"
+ depends on ION
+ help
+ Choose this option to enable UNMAPPED heaps with Ion. This heap is
+ backed in specific memory pools, carveout from the Linux memory.
+ Unlike carveout heaps these are assumed to be not mappable by
+ kernel or user-space.
+ Unless you know your system has these regions, you should say N
here.
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index 17f3a7569e3d..c71a1f3de581 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o
ion_page_pool.o
obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
+obj-$(CONFIG_ION_UNMAPPED_HEAP) += ion_unmapped_heap.o
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 97b2876b165a..ce74332018ba 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -341,4 +341,20 @@ static inline struct ion_heap
*ion_chunk_heap_create(phys_addr_t base, size_t si
}
#endif
+#ifdef CONFIG_ION_UNMAPPED_HEAP
+/**
+ * ion_unmapped_heap_create
+ * @base: base address of carveout memory
+ * @size: size of carveout memory region
+ *
+ * Creates an unmapped ion_heap using the passed in data
+ */
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t
size);
+#else
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t size)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
#endif /* _ION_H */
diff --git a/drivers/staging/android/ion/ion_unmapped_heap.c
b/drivers/staging/android/ion/ion_unmapped_heap.c
new file mode 100644
index ..7602b659c2ec
--- /dev/null
+++ b/drivers/staging/android/ion/ion_unmapped_heap.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ION Memory Allocator unmapped heap helper
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated -
http://www.ti.com/
+ * Andrew F. Davis
+ *
+ * ION "unmapped" heaps are physical memory heaps not by default
mapped into
+ * a virtual address space. The buffer owner can explicitly request
kernel
+ * space mappings but the underlying memory may still not be
accessible for
+ * various reasons, such as firewalls.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "ion.h"
+
+#define ION_UNMAPPED_ALLOCATE_FAIL -1
+
+struct ion_unmapped_heap {
+ struct ion_heap heap;
+ struct gen_pool *pool;
+};
+
+static phys_addr_t ion_unmapped_allocate(struct ion_heap *heap,
+ unsigned long size)
+{
+ struct ion_unmapped_heap *unmapped_heap =
+ container_of(heap, struct ion_unmapped_heap, heap);
+ unsigned long offset;
+
+ offset = gen_pool_alloc(unmapped_heap->pool, size);
+ if (!offset)
+ return ION_UNMAPPED_ALLOCATE_FAIL;
+
+ return offset;
+}
+
+static void ion_unmapped_free(struct ion_heap *heap, phys_addr_t addr,
+ unsigned long size)
+{
+ struct ion_unmapped_heap *unmapped_heap =
+ container_of(heap, struct ion_unmapped_heap, heap);
+
+ gen_pool_free(unmapped_heap->pool, addr, size);
+}
+
+static int ion_unmapped_heap_allocate(struct ion_heap *heap,
+ struct ion_buffer *buffer,
+ unsigned long size,
+
Re: [PATCH v7 perf, bpf-next 6/8] perf util: handle PERF_RECORD_KSYMBOL
Em Thu, Jan 10, 2019 at 04:19:31PM -0800, Song Liu escreveu:
> This patch handles PERF_RECORD_KSYMBOL in perf record/report.
> Specifically, map and symbol are created for ksymbol register, and
> removed for ksymbol unregister.
>
> This patch also set perf_event_attr.ksymbol properly. The flag is
> ON by default.
>
> Signed-off-by: Song Liu
> ---
> tools/perf/util/event.c | 21 +++
> tools/perf/util/event.h | 20 ++
> tools/perf/util/evsel.c | 9 +++
> tools/perf/util/evsel.h | 1 +
> tools/perf/util/machine.c | 57 +++
> tools/perf/util/machine.h | 3 +++
> tools/perf/util/session.c | 4 +++
> tools/perf/util/tool.h| 4 ++-
> 8 files changed, 118 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> index 937a5a4f71cc..3c8a6a8dd260 100644
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c
> @@ -24,6 +24,7 @@
> #include "symbol/kallsyms.h"
> #include "asm/bug.h"
> #include "stat.h"
> +#include "session.h"
>
> #define DEFAULT_PROC_MAP_PARSE_TIMEOUT 500
>
> @@ -45,6 +46,7 @@ static const char *perf_event__names[] = {
> [PERF_RECORD_SWITCH]= "SWITCH",
> [PERF_RECORD_SWITCH_CPU_WIDE] = "SWITCH_CPU_WIDE",
> [PERF_RECORD_NAMESPACES]= "NAMESPACES",
> + [PERF_RECORD_KSYMBOL] = "KSYMBOL",
> [PERF_RECORD_HEADER_ATTR] = "ATTR",
> [PERF_RECORD_HEADER_EVENT_TYPE] = "EVENT_TYPE",
> [PERF_RECORD_HEADER_TRACING_DATA] = "TRACING_DATA",
> @@ -1329,6 +1331,14 @@ int perf_event__process_switch(struct perf_tool *tool
> __maybe_unused,
> return machine__process_switch_event(machine, event);
> }
>
> +int perf_event__process_ksymbol(struct perf_tool *tool __maybe_unused,
> + union perf_event *event,
> + struct perf_sample *sample __maybe_unused,
> + struct machine *machine)
> +{
> + return machine__process_ksymbol(machine, event, sample);
> +}
> +
> size_t perf_event__fprintf_mmap(union perf_event *event, FILE *fp)
> {
> return fprintf(fp, " %d/%d: [%#" PRIx64 "(%#" PRIx64 ") @ %#" PRIx64
> "]: %c %s\n",
> @@ -1461,6 +1471,14 @@ static size_t perf_event__fprintf_lost(union
> perf_event *event, FILE *fp)
> return fprintf(fp, " lost %" PRIu64 "\n", event->lost.lost);
> }
>
> +size_t perf_event__fprintf_ksymbol(union perf_event *event, FILE *fp)
> +{
> + return fprintf(fp, " ksymbol event with addr %lx len %u type %u flags
> 0x%x name %s\n",
> +event->ksymbol_event.addr, event->ksymbol_event.len,
> +event->ksymbol_event.ksym_type,
> +event->ksymbol_event.flags, event->ksymbol_event.name);
> +}
> +
> size_t perf_event__fprintf(union perf_event *event, FILE *fp)
> {
> size_t ret = fprintf(fp, "PERF_RECORD_%s",
> @@ -1496,6 +1514,9 @@ size_t perf_event__fprintf(union perf_event *event,
> FILE *fp)
> case PERF_RECORD_LOST:
> ret += perf_event__fprintf_lost(event, fp);
> break;
> + case PERF_RECORD_KSYMBOL:
> + ret += perf_event__fprintf_ksymbol(event, fp);
> + break;
> default:
> ret += fprintf(fp, "\n");
> }
> diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
> index eb95f3384958..018322f2a13e 100644
> --- a/tools/perf/util/event.h
> +++ b/tools/perf/util/event.h
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
>
> #include "../perf.h"
> #include "build-id.h"
> @@ -84,6 +85,19 @@ struct throttle_event {
> u64 stream_id;
> };
>
> +#ifndef KSYM_NAME_LEN
> +#define KSYM_NAME_LEN 256
> +#endif
> +
> +struct ksymbol_event {
> + struct perf_event_header header;
> + u64 addr;
> + u32 len;
> + u16 ksym_type;
> + u16 flags;
> + char name[KSYM_NAME_LEN];
> +};
> +
> #define PERF_SAMPLE_MASK \
> (PERF_SAMPLE_IP | PERF_SAMPLE_TID | \
>PERF_SAMPLE_TIME | PERF_SAMPLE_ADDR | \
> @@ -651,6 +665,7 @@ union perf_event {
> struct stat_round_event stat_round;
> struct time_conv_event time_conv;
> struct feature_eventfeat;
> + struct ksymbol_eventksymbol_event;
> };
>
> void perf_event__print_totals(void);
> @@ -748,6 +763,10 @@ int perf_event__process_exit(struct perf_tool *tool,
>union perf_event *event,
>struct perf_sample *sample,
>struct machine *machine);
> +int perf_event__process_ksymbol(struct perf_tool *tool,
> + union perf_event *event,
> + struct perf_sample *sample,
> + struct machine *machine);
> int perf_tool__process_synth_ev
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
Am 15.01.19 um 19:31 schrieb h...@lst.de: > On Tue, Jan 15, 2019 at 06:03:39PM +, Thomas Hellstrom wrote: >> In the graphics case, it's probably because it doesn't fit the graphics >> use-cases: >> >> 1) Memory typically needs to be mappable by another device. (the "dma- >> buf" interface) > And there is nothing preventing dma-buf sharing of these buffers. > Unlike the get_sgtable mess it can actually work reliably on > architectures that have virtually tagged caches and/or don't > guarantee cache coherency with mixed attribute mappings. > >> 2) DMA buffers are exported to user-space and is sub-allocated by it. >> Mostly there are no GPU user-space kernel interfaces to sync / flush >> subregions and these syncs may happen on a smaller-than-cache-line >> granularity. > I know of no architectures that can do cache maintainance on a less > than cache line basis. Either the instructions require you to > specifcy cache lines, or they do sometimes more, sometimes less > intelligent rounding up. > > Note that as long dma non-coherent buffers are devices owned it > is up to the device and the user space driver to take care of > coherency, the kernel very much is out of the picture. Thomas is correct that the interface you propose here doesn't work at all for GPUs. The kernel driver is not informed of flush/sync, but rather just setups coherent mappings between system memory and devices. In other words you have an array of struct pages and need to map that to a specific device and so create dma_addresses for the mappings. Regards, Christian.
[PATCH] mmc: cqhci: data size depending on queue depth
CQE_DCMD is not necessary to be enabled when CQE is enabled.
(Software could halt CQE to send command, or via DCMD)
In the case that CQE_DCMD is not enabled, it still needs to allocate
space for data transfer. For instance:
CQE_DCMD is enabled: 32 slots space
CQE_DCMD is disabled: 31 slots space (is good enough)
Signed-off-by: Alamy Liu
---
drivers/mmc/host/cqhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c
index 4cc7863c13..974997b6cb 100644
--- a/drivers/mmc/host/cqhci.c
+++ b/drivers/mmc/host/cqhci.c
@@ -202,7 +202,7 @@ static int cqhci_host_alloc_tdl(struct cqhci_host *cq_host)
cq_host->desc_size = cq_host->slot_sz * cq_host->num_slots;
cq_host->data_size = cq_host->trans_desc_len * cq_host->mmc->max_segs *
- (cq_host->num_slots - 1);
+ cq_host->mmc->cqe_qdepth;
pr_debug("%s: cqhci: desc_size: %zu data_sz: %zu slot-sz: %d\n",
mmc_hostname(cq_host->mmc), cq_host->desc_size,
cq_host->data_size,
--
2.17.1
[PATCH v2] media: imx: queue subdev events to reachable video devices
In order to receive events generated by subdevices on the video capture
nodes, those events need to be forwarded to the subdevice's list of
reachable video capture devices.
Note this will queue the event to a video device even if there is
no actual _enabled_ media path from the sub-device to the video device.
So a future improvement is to skip the video device if there is no enabled
path to it from the sub-device. The entity->pipe pointer can't be
used for this check because in imx-media a sub-device can be a
member to more than one streaming pipeline at a time.
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- split out the implementation of (un)subscribe_event on the video
capture device to a separate patch.
---
drivers/staging/media/imx/imx-media-dev.c | 24 +++
1 file changed, 24 insertions(+)
diff --git a/drivers/staging/media/imx/imx-media-dev.c
b/drivers/staging/media/imx/imx-media-dev.c
index 4b344a4a3706..25e916562c66 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -442,6 +442,29 @@ static const struct media_device_ops imx_media_md_ops = {
.link_notify = imx_media_link_notify,
};
+static void imx_media_notify(struct v4l2_subdev *sd,
+unsigned int notification,
+void *arg)
+{
+ struct media_entity *entity = &sd->entity;
+ int i;
+
+ if (notification != V4L2_DEVICE_NOTIFY_EVENT)
+ return;
+
+ for (i = 0; i < entity->num_pads; i++) {
+ struct media_pad *pad = &entity->pads[i];
+ struct imx_media_pad_vdev *pad_vdev;
+ struct list_head *pad_vdev_list;
+
+ pad_vdev_list = to_pad_vdev_list(sd, pad->index);
+ if (!pad_vdev_list)
+ continue;
+ list_for_each_entry(pad_vdev, pad_vdev_list, list)
+ v4l2_event_queue(pad_vdev->vdev->vfd, arg);
+ }
+}
+
static int imx_media_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -462,6 +485,7 @@ static int imx_media_probe(struct platform_device *pdev)
mutex_init(&imxmd->mutex);
imxmd->v4l2_dev.mdev = &imxmd->md;
+ imxmd->v4l2_dev.notify = imx_media_notify;
strscpy(imxmd->v4l2_dev.name, "imx-media",
sizeof(imxmd->v4l2_dev.name));
--
2.17.1
[PATCH] media: imx: capture: Allow event subscribe/unsubscribe
Implement the vidioc_(un)subscribe_event operations. Imx will allow
subscribing to the imx-specific frame interval error events, events
from subdevices (V4L2_EVENT_SOURCE_CHANGE), and control events.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-media-capture.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/staging/media/imx/imx-media-capture.c
b/drivers/staging/media/imx/imx-media-capture.c
index b37e1186eb2f..4dfbe05d203e 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -335,6 +335,21 @@ static int capture_s_parm(struct file *file, void *fh,
return 0;
}
+static int capture_subscribe_event(struct v4l2_fh *fh,
+ const struct v4l2_event_subscription *sub)
+{
+ switch (sub->type) {
+ case V4L2_EVENT_IMX_FRAME_INTERVAL_ERROR:
+ return v4l2_event_subscribe(fh, sub, 0, NULL);
+ case V4L2_EVENT_SOURCE_CHANGE:
+ return v4l2_src_change_event_subscribe(fh, sub);
+ case V4L2_EVENT_CTRL:
+ return v4l2_ctrl_subscribe_event(fh, sub);
+ default:
+ return -EINVAL;
+ }
+}
+
static const struct v4l2_ioctl_ops capture_ioctl_ops = {
.vidioc_querycap= vidioc_querycap,
@@ -362,6 +377,9 @@ static const struct v4l2_ioctl_ops capture_ioctl_ops = {
.vidioc_expbuf = vb2_ioctl_expbuf,
.vidioc_streamon= vb2_ioctl_streamon,
.vidioc_streamoff = vb2_ioctl_streamoff,
+
+ .vidioc_subscribe_event = capture_subscribe_event,
+ .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
/*
--
2.17.1
[PATCH] arm64: Kconfig.platforms: fix warning unmet direct dependencies
When ARCH_MXC get enabled, ARM64_ERRATUM_845719 will be selected and this warning will happen when COMPAT isn't set. WARNING: unmet direct dependencies detected for ARM64_ERRATUM_845719 Depends on [n]: COMPAT [=n] Selected by [y]: - ARCH_MXC [=y] Rework to add 'if COMPAT' before ARM64_ERRATUM_845719 gets selected, since ARM64_ERRATUM_845719 depends on COMPAT. Signed-off-by: Anders Roxell --- arch/arm64/Kconfig.platforms | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 251ecf34cb02..d4faca775d9c 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -145,7 +145,7 @@ config ARCH_MVEBU config ARCH_MXC bool "ARMv8 based NXP i.MX SoC family" select ARM64_ERRATUM_843419 - select ARM64_ERRATUM_845719 + select ARM64_ERRATUM_845719 if COMPAT help This enables support for the ARMv8 based SoCs in the NXP i.MX family. -- 2.19.2
Re: [PATCH] KEYS: user: Align the payload buffer
Hi,
On Mon, Jan 14, 2019 at 07:37:16PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> Align the payload of "user" and "logon" keys so that users of the
> keyrings service can access it as a struct that requires more than
> 2-byte alignment. fscrypt currently does this which results in the read
> of fscrypt_key::size being misaligned as it needs 4-byte alignment.
>
> Align to __alignof__(u64) rather than __alignof__(long) since in the
> future it's conceivable that people would use structs beginning with
> u64, which on some platforms would require more than 'long' alignment.
>
> Reported-by: Aaro Koskinen
> Fixes: 2aa349f6e37c ("[PATCH] Keys: Export user-defined keyring operations")
> Fixes: 88bd6ccdcdd6 ("ext4 crypto: add encryption key management facilities")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eric Biggers
Tested-by: Aaro Koskinen
This fixes the "unaligned access" dmesg spam on SPARC when using ext4
encryption.
Thanks,
A.
> ---
> include/keys/user-type.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/keys/user-type.h b/include/keys/user-type.h
> index e098cbe27db54..12babe9915944 100644
> --- a/include/keys/user-type.h
> +++ b/include/keys/user-type.h
> @@ -31,7 +31,7 @@
> struct user_key_payload {
> struct rcu_head rcu;/* RCU destructor */
> unsigned short datalen;/* length of this data */
> - chardata[0];/* actual data */
> + chardata[0] __aligned(__alignof__(u64)); /* actual data */
> };
>
> extern struct key_type key_type_user;
> --
> 2.20.1
>
RE: [PATCH 4.20 14/57] CIFS: Do not hide EINTR after sending network packets
Hi Greg, I am wondering if it is possible to include exact stable kernel version (e.g. 4.20.3 in this case) in the email. This would help to quickly understand which kernel version should be installed in order to get the fix. Best regards, Pavel Shilovsky -Original Message- From: Greg Kroah-Hartman Sent: Tuesday, January 15, 2019 8:36 AM To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman ; sta...@vger.kernel.org; Pavel Shilovskiy ; Jeff Layton ; Steven French Subject: [PATCH 4.20 14/57] CIFS: Do not hide EINTR after sending network packets 4.20-stable review patch. If anyone has any objections, please let me know. -- From: Pavel Shilovsky commit ee13919c2e8d1f904e035ad4b4239029a8994131 upstream. Currently we hide EINTR code returned from sock_sendmsg() and return 0 instead. This makes a caller think that we successfully completed the network operation which is not true. Fix this by properly returning EINTR to callers. Cc: Signed-off-by: Pavel Shilovsky Reviewed-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman --- fs/cifs/transport.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/cifs/transport.c +++ b/fs/cifs/transport.c @@ -385,7 +385,7 @@ smbd_done: if (rc < 0 && rc != -EINTR) cifs_dbg(VFS, "Error %d sending data on socket to server\n", rc); - else + else if (rc > 0) rc = 0; return rc;
Re: [PATCH v2 4/4] gcov: clang: pick GCC vs Clang format depending on compiler
+ Masahiro On Tue, Jan 15, 2019 at 10:37 AM Tri Vo wrote: > > From: Tri Vo > > Clang gcov format is only supported by Clang compiler, and Clang > compiler only supports Clang format. > > We set gcov format to depend on which compiler (GCC or Clang) is used. > > Automatic format detection behavior is preserved because: > If GCC is used, one of the GCC gcov formats is selected. > If Clang is used, Clang gcov format is selected. > > Signed-off-by: Tri Vo > --- > kernel/gcov/Kconfig | 8 ++-- > kernel/gcov/Makefile | 2 +- > 2 files changed, 3 insertions(+), 7 deletions(-) > > diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig > index eb428e570923..f71c1adcff31 100644 > --- a/kernel/gcov/Kconfig > +++ b/kernel/gcov/Kconfig > @@ -53,6 +53,7 @@ config GCOV_PROFILE_ALL > choice > prompt "Specify GCOV format" > depends on GCOV_KERNEL > + depends on CC_IS_GCC > ---help--- > The gcov format is usually determined by the GCC version, and the > default is chosen according to your GCC version. However, there are > @@ -62,7 +63,7 @@ choice > > config GCOV_FORMAT_3_4 > bool "GCC 3.4 format" > - depends on CC_IS_GCC && GCC_VERSION < 40700 > + depends on GCC_VERSION < 40700 > ---help--- > Select this option to use the format defined by GCC 3.4. > > @@ -71,11 +72,6 @@ config GCOV_FORMAT_4_7 > ---help--- > Select this option to use the format defined by GCC 4.7. > > -config GCOV_FORMAT_CLANG > - bool "Clang format" > - ---help--- > - Select this option to use the format defined by Clang. > - > endchoice > > endmenu > diff --git a/kernel/gcov/Makefile b/kernel/gcov/Makefile > index 83da4765c18d..d66a74b0f100 100644 > --- a/kernel/gcov/Makefile > +++ b/kernel/gcov/Makefile > @@ -4,4 +4,4 @@ ccflags-y := -DSRCTREE='"$(srctree)"' -DOBJTREE='"$(objtree)"' > obj-y := base.o fs.o > obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_base.o gcc_3_4.o > obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_base.o gcc_4_7.o > -obj-$(CONFIG_GCOV_FORMAT_CLANG) += clang.o > +obj-$(CONFIG_CC_IS_CLANG) += clang.o I think this was the suggestion from Masahiro from v1? -- Thanks, ~Nick Desaulniers
Re: Regression: spi: core: avoid waking pump thread from spi_sync instead run teardown delayed
On Tue, Jan 15, 2019 at 06:39:27PM +0100, ker...@martin.sperl.org wrote: > Is it possible that the specific flash is not using the “normal” > spi_pump_message, but spi_controller_mem_ops operations? Right, that's my best guess at the minute as well. > Maybe we are missing the teardown in that driver or something is > changing flags there. > grepping a bit: > I see spi_mem_access_start calling spi_flush_queue, which is calling > pump_message, which - if there is no transfer - will trigger a delayed > tear-down, while it maybe should not be doing that. If nothing else it's inefficient. > Maybe spi_mem_access_end needs a call to spi_flush_queue as well? Hrm, or needs to schedule the queue at any rate (though this will only have an impact in the fairly unusual case where there's something sharing the bus with a flash). > Unfortunately this is theoretical work and quite a lot of guesswork > without an actual device available for testing... Indeed. signature.asc Description: PGP signature
Re: Regression: spi: core: avoid waking pump thread from spi_sync instead run teardown delayed
On Tue, Jan 15, 2019 at 04:09:14PM +, Jon Hunter wrote: > On 15/01/2019 15:10, Mark Brown wrote: > > On Tue, Jan 15, 2019 at 02:26:02PM +, Jon Hunter wrote: > > Right, I think with the current code we just shouldn't be checking for > > busy in teardown, since there's now a fairly big delay between idle and > > actually turning the hardware off the name is just super misleading and > > the logic confused. I don't have time to test right now but does > > something like the below which changes it to a flag for the hardware > > being powered up work: > I tried your change but the same problem still persists. OK, I feared as much with the stats not showing any activity. I do think it needs a cleanup still but probably won't help here. signature.asc Description: PGP signature
Regression in v5.0-rc with regmap-irq level-irq changes
Hi,
Looks like commit 1c2928e3e321 ("regmap: regmap-irq/gpio-max77620: add
level-irq support") caused a regression at least with palmas PMIC where
child interrupt no longer work and we get something like this on
omap5-uevm for example:
genirq: Setting trigger mode 3 for irq 157 failed
(regmap_irq_set_type+0x0/0x15c)
genirq: Setting trigger mode 12 for irq 154 failed
(regmap_irq_set_type+0x0/0x15c)
genirq: Setting trigger mode 8 for irq 149 failed
(regmap_irq_set_type+0x0/0x15c)
These are for child devices like power button, USB and RTC interrupts.
I'd also assume GPIOs might be broken now.
Any ideas what's needed? Some triggering mapping data to palmas.c
driver?
To me it seems the child device interrupt triggering can be whatever
the hardware supports including IRQ_TYPE_NONE for non-configurable
interrupts. Additionally palmas.c supports inverting the SoC
interrupt also.
Not sure if other things are broken now too, it might be worth
grepping the logs at kernelci.org for similar genirq errors above?
Regards,
Tony
Re: [PATCH v2 3/9] platform/chrome: Add sysfs attributes
Hi Nick,
Some few comments more ...
Missatge de Nick Crews del dia dl., 14 de gen.
2019 a les 23:07:
>
> From: Duncan Laurie
>
> Add some sample sysfs attributes for the Wilco EC that show how
> the mailbox interface works. "Legacy" attributes are those that
> existed in the EC before it was adapted to ChromeOS.
>
> > cat /sys/bus/platform/devices/GOOG000C\:00/version
> Label: 99.99.99
> SVN Revision : 738ed.99
> Model Number : 08;8
> Build Date : 08/30/18
>
> Signed-off-by: Duncan Laurie
> Signed-off-by: Nick Crews
> ---
>
> Changes in v2:
> - Remove license boiler plate
> - Remove "wilco_ec_sysfs -" docstring prefix
> - Fix accidental Makefile deletion
> - Add documentation for sysfs entries
> - Change "enable ? 0 : 1" to "!enable"
> - No longer override error code from sysfs_init()
> - Put attributes in the legacy file to begin with, don't move later
> - Remove duplicate error messages in sysfs_init() and its caller
>
> .../ABI/testing/sysfs-platform-wilcoec| 26 ++
> drivers/platform/chrome/wilco_ec/Makefile | 2 +-
> drivers/platform/chrome/wilco_ec/core.c | 15 +++
> drivers/platform/chrome/wilco_ec/legacy.c | 91 +++
> drivers/platform/chrome/wilco_ec/legacy.h | 47 ++
> drivers/platform/chrome/wilco_ec/sysfs.c | 66 ++
> include/linux/platform_data/wilco-ec.h| 14 +++
> 7 files changed, 260 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/ABI/testing/sysfs-platform-wilcoec
I'd like to rename this to sysfs-platform-wilco-ec (like cros-ec)
> create mode 100644 drivers/platform/chrome/wilco_ec/legacy.c
> create mode 100644 drivers/platform/chrome/wilco_ec/legacy.h
> create mode 100644 drivers/platform/chrome/wilco_ec/sysfs.c
>
> diff --git a/Documentation/ABI/testing/sysfs-platform-wilcoec
> b/Documentation/ABI/testing/sysfs-platform-wilcoec
> new file mode 100644
> index ..09552338c160
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform-wilcoec
> @@ -0,0 +1,26 @@
> +What: /sys/bus/platform/devices/GOOG000C\:00/version
> +Date: January 2019
> +KernelVersion: 4.19
That will be probably 5.1
> +Description:
> + Display Wilco Embedded Controller version info
> +
> + Output will be similar to the example below:
> + Label: 95.00.06
> + SVN Revision : 5960a.06
> + Model Number : 08;8
> + Build Date : 11/29/18
> +
> + Although this contains multiple pieces of data in a single
> sysfs
> + attribute (inconsistent with normal sysfs conventions),
> + this format was chosen to be consistent with the version
> + attribute in /sys/class/chomeos//version
> +
I don't buy the reason to be inconsistent. I don't think you need to
be consistent with something that is wrong and not following the
conventions. Past errors should be fixed :)
I'd like to see here single values in single attributes, this will
also be easier to parse from userspace point of view.
> +What: /sys/bus/platform/devices/GOOG000C\:00/stealth_mode
> +Date: January 2019
> +KernelVersion: 4.19
> +Description:
> + Turn stealth_mode on or off on EC. Stealth mode means that the
> + various LEDs, the LCD backlight, and onboard speakers are
> turned
> + off and remain off even if activated from the off state.
> + External monitors connected to the system are not affected.
> + In addition Wireless devices are turned off.
Would be good to specify the valid values to write.
> diff --git a/drivers/platform/chrome/wilco_ec/Makefile
> b/drivers/platform/chrome/wilco_ec/Makefile
> index 03b32301dc61..7965a39e2e7a 100644
> --- a/drivers/platform/chrome/wilco_ec/Makefile
> +++ b/drivers/platform/chrome/wilco_ec/Makefile
> @@ -1,4 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -wilco_ec-objs := core.o mailbox.o
> +wilco_ec-objs := core.o mailbox.o sysfs.o legacy.o
> obj-$(CONFIG_WILCO_EC) += wilco_ec.o
> diff --git a/drivers/platform/chrome/wilco_ec/core.c
> b/drivers/platform/chrome/wilco_ec/core.c
> index 2d1d8d3f9a94..3193e8b2ec91 100644
> --- a/drivers/platform/chrome/wilco_ec/core.c
> +++ b/drivers/platform/chrome/wilco_ec/core.c
> @@ -64,11 +64,26 @@ static int wilco_ec_probe(struct platform_device *pdev)
> cros_ec_lpc_mec_init(ec->io_packet->start,
> ec->io_packet->start + EC_MAILBOX_DATA_SIZE);
>
> + /* Create sysfs attributes for userspace interaction */
> + ret = wilco_ec_sysfs_init(ec);
> + if (ret < 0) {
> + dev_err(dev, "Failed to create sysfs attributes\n");
> + goto destroy_lpc_mec;
> + }
> return 0;
> +
> +destroy_lpc_mec:
> + cros_ec_lpc_mec_destroy();
> + return ret;
> }
>
Re: [PATCH v1] iommu/s390: Declare s390 iommu reserved regions
On Tue, 15 Jan 2019 18:37:30 +0100
Pierre Morel wrote:
> The s390 iommu can only allow DMA transactions between the zPCI device
> entries start_dma and end_dma.
>
> Let's declare the regions before start_dma and after end_dma as
> reserved regions using the appropriate callback in iommu_ops.
>
> Signed-off-by: Pierre Morel
> ---
> drivers/iommu/s390-iommu.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c
> index 22d4db3..5ca91a1 100644
> --- a/drivers/iommu/s390-iommu.c
> +++ b/drivers/iommu/s390-iommu.c
> @@ -363,6 +363,33 @@ void zpci_destroy_iommu(struct zpci_dev *zdev)
> iommu_device_sysfs_remove(&zdev->iommu_dev);
> }
>
> +static void s390_get_resv_regions(struct device *dev, struct list_head *head)
> +{
> + struct iommu_resv_region *region;
> + struct zpci_dev *zdev = to_pci_dev(dev)->sysdata;
> +
> + region = iommu_alloc_resv_region(0, zdev->start_dma,
> + 0, IOMMU_RESV_RESERVED);
> + if (!region)
> + return;
> + list_add_tail(®ion->list, head);
> +
> + region = iommu_alloc_resv_region(zdev->end_dma + 1,
> + ~0UL - zdev->end_dma,
> + 0, IOMMU_RESV_RESERVED);
Can you guarantee that start_dma will never be 0 and end_dma never ~0UL,
even with future HW?
In any of these cases, your code would reserve strange ranges, and sysfs
would report broken reserved ranges.
Maybe add a check for start_dma > 0 and end_dma < ULONG_MAX?
> + if (!region)
> + return;
> + list_add_tail(®ion->list, head);
> +}
> +
> +static void s390_put_resv_regions(struct device *dev, struct list_head *head)
> +{
> + struct iommu_resv_region *entry, *next;
> +
> + list_for_each_entry_safe(entry, next, head, list)
> + kfree(entry);
> +}
It looks very wrong that there is no matching list_del() for the previous
list_add_tail(). However, it seems to be done like this everywhere else,
and the calling functions (currently) only use temporary list_heads as
far as I can see, so I guess it should be OK (for now).
Still, a list_del() would be nice :-)
> +
> static const struct iommu_ops s390_iommu_ops = {
> .capable = s390_iommu_capable,
> .domain_alloc = s390_domain_alloc,
> @@ -376,6 +403,8 @@ static const struct iommu_ops s390_iommu_ops = {
> .remove_device = s390_iommu_remove_device,
> .device_group = generic_device_group,
> .pgsize_bitmap = S390_IOMMU_PGSIZES,
> + .get_resv_regions = s390_get_resv_regions,
> + .put_resv_regions = s390_put_resv_regions,
> };
>
> static int __init s390_iommu_init(void)
With the start/end_dma issue addressed (if necessary):
Acked-by: Gerald Schaefer
Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component
On 1/14/19 6:06 PM, Mark Brown wrote:
On Fri, Jan 11, 2019 at 03:49:08PM -0600, Pierre-Louis Bossart wrote:
Adding some traces I can see that the the platform name we use doesn't seem
compatible with your logic. All the Intel boards used a constant platform
name matching the PCI ID, see e.g. [1], which IIRC is used to bind
components. Liam, do you recall in more details if this is really required?
That's telling me that either snd_soc_find_components() isn't finding
components in the same way that we do when we bind things which isn't
good or we're binding links without having fully matched everything on
the link which also isn't good.
Without a system that shows the issue I can't 100% confirm but I think
it's the former - I'm fairly sure that those machines are relying on the
component name being initialized to fmt_single_name() in
snd_soc_component_initialize(). That is supposed to wind up using
dev_name() (which would be the PCI address for a PCI device) as the
basis of the name. What I can't currently see is how exactly that gets
bound (or how any of the other links avoid trouble for that matter). We
could revert and push this into cards but I would rather be confident
that we understand what's going on, I'm not comfortable that we aren't
just pushing the breakage around rather than fixing it. Can someone
with an x86 system take a look and confirm exactly what's going on with
binding these cards please?
Beyond the fact that the platform_name seems to be totally useless,
additional tests show that the patch ('ASoC: soc-core: defer card probe
until all component is added to list') adds a new restriction which
contradicts existing error checks.
None of the Intel machine drivers set the dailink "cpu_name" field but
use the "cpu_dai_name" field instead. This was perfectly legit as
documented by the code at the end of soc_init_dai_link()
/*
* At least one of CPU DAI name or CPU device name/node must be
* specified
*/
if (!link->cpu_dai_name &&
!(link->cpu_name || link->cpu_of_node)) {
dev_err(card->dev,
"ASoC: Neither cpu_dai_name nor cpu_name/of_node are set
for %s\n",
link->name);
return -EINVAL;
}
The code contributed by Qualcomm only checks for cpu_name, which
prevents the init from completing.
So if we want to be consistent, the new code should be something like:
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index b680c673c553..2791da9417f8 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1154,7 +1154,7 @@ static int soc_init_dai_link(struct snd_soc_card
*card,
* Defer card registartion if cpu dai component is not added to
* component list.
*/
- if (!soc_find_component(link->cpu_of_node, link->cpu_name))
+ if (!link->cpu_dai_name &&
!soc_find_component(link->cpu_of_node, link->cpu_name))
return -EPROBE_DEFER;
/*
or try to call soc_find_component with both cpu_name or cpu_dai_name, if
this makes sense?
Re: [PATCH 1/3] efi/x86: turn EFI runtime semaphore into a global lock
On Tue, Jan 15, 2019 at 18:55 Thomas Gleixner wrote: On Wed, 9 Jan 2019, Hedi Berriche wrote: Make efi_runtime_lock semaphore global so that it can be used by EFI runtime callers that may be defined outside efi/runtime-wrappers.c. The changelog should mention why the lock is renamed. OK; will add to V2 that it was renamed so that it doesn't clash with the efi_runtime_lock spinlock defined by CONFIG_EFI_MIXED. I have no strong opinion, but to apply that I need an Ack from Ard. OK; thanks for the feedback. Cheers, Hedi. -- Be careful of reading health books, you might die of a misprint. -- Mark Twain
Re: Regression in 32-bit-compat TIOCGPTPEER ioctl due to 311fc65c9fb9c966bca8e6f3ff8132ce57344ab9
On Tue, Jan 15, 2019 at 8:25 PM Eric W. Biederman wrote: > Can you confirm this fixes it for you? Sorry --- I made a mistake. It looks like this is already fixed on master, by commit e21120383f2dce32312f63ffca145ff8a87d41f5 (though I don't think Al Viro knew he was fixing this bug). So, nothing to do here. Thanks, Rob -- Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew hcihw, gninnigeb eht morf saw hcihw taht.
Re: [PATCH v2 4/9] platform/chrome: Add support for raw commands in sysfs
Hi Nick,
Missatge de Nick Crews del dia dl., 14 de gen.
2019 a les 23:07:
>
> From: Duncan Laurie
>
> Add a sysfs attribute that allows sending raw commands to the EC.
> This is useful for development and debug but should not be enabled
> in a production environment.
>
Shouldn't you use debugfs for all this stuff instead?
> > echo 00 f0 38 00 03 00 > /sys/bus/platform/devices/GOOG000C\:00/raw
> > cat /sys/bus/platform/devices/GOOG000C\:00/raw
> 00 37 33 38 65 64 00...
>
> Signed-off-by: Duncan Laurie
> Signed-off-by: Nick Crews
> ---
>
> Changes in v2:
> - Add sysfs documentation
> - rm duplicate EC_MAILBOX_DATA_SIZE defs
> - Make docstrings follow kernel style
> - Fix tags in commit msg
> - Reading raw now includes ASCII translation
>
> .../ABI/testing/sysfs-platform-wilcoec| 21
> drivers/platform/chrome/wilco_ec/Kconfig | 9 ++
> drivers/platform/chrome/wilco_ec/legacy.c | 99 +++
> drivers/platform/chrome/wilco_ec/legacy.h | 46 +
> drivers/platform/chrome/wilco_ec/sysfs.c | 6 ++
> 5 files changed, 181 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-platform-wilcoec
> b/Documentation/ABI/testing/sysfs-platform-wilcoec
> index 09552338c160..cac2cf11835f 100644
> --- a/Documentation/ABI/testing/sysfs-platform-wilcoec
> +++ b/Documentation/ABI/testing/sysfs-platform-wilcoec
> @@ -24,3 +24,24 @@ Description:
> off and remain off even if activated from the off state.
> External monitors connected to the system are not affected.
> In addition Wireless devices are turned off.
> +
> +What: /sys/bus/platform/devices/GOOG000C\:00/raw
> +Date: January 2019
> +KernelVersion: 4.19
> +Description:
> + Write and read raw mailbox commands to the EC.
> +
> + For writing:
> + Bytes 0-1 indicate the message type:
> + 00 F0 = Execute Legacy Command
> + 00 F2 = Read/Write NVRAM Property
> + Byte 2 provides the command code
> + Bytes 3+ consist of the data passed in the request
> +
> + Example:
> + // Request EC info type 3 (EC firmware build date)
> + $ echo 00 f0 38 00 03 00 > raw
> + // View the result. The decoded ASCII result "12/21/18" is
> + // included after the raw hex.
> + $ cat raw
> + 00 31 32 2f 32 31 2f 31 38 00 38 00 01 00 2f 00
> .12/21/18.8...
> diff --git a/drivers/platform/chrome/wilco_ec/Kconfig
> b/drivers/platform/chrome/wilco_ec/Kconfig
> index f8e6c9e8c5cd..0bd84c98b79b 100644
> --- a/drivers/platform/chrome/wilco_ec/Kconfig
> +++ b/drivers/platform/chrome/wilco_ec/Kconfig
> @@ -21,4 +21,13 @@ config WILCO_EC
> To compile this driver as a module, choose M here: the
> module will be called wilco_ec.
>
> +config WILCO_EC_SYSFS_RAW
> + bool "Enable raw access to EC via sysfs"
> + depends on WILCO_EC
> + help
> + If you say Y here, you get support for sending raw commands to
> + the Wilco EC via sysfs. These commands do not do any byte
> + manipulation and allow for testing arbitrary commands. This
> + interface is intended for debug only and is disabled by default.
> +
> endif # WILCO_EC_PLATFORM
> diff --git a/drivers/platform/chrome/wilco_ec/legacy.c
> b/drivers/platform/chrome/wilco_ec/legacy.c
> index 1fdf94d22f57..79bac5dccb39 100644
> --- a/drivers/platform/chrome/wilco_ec/legacy.c
> +++ b/drivers/platform/chrome/wilco_ec/legacy.c
> @@ -11,6 +11,105 @@
>
> #include "legacy.h"
>
> +#ifdef CONFIG_WILCO_EC_SYSFS_RAW
> +
> +/* Raw data buffer, large enough to hold extended responses */
> +static size_t raw_response_size;
> +static u8 raw_response_data[EC_MAILBOX_DATA_SIZE_EXTENDED];
> +
> +ssize_t wilco_ec_raw_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct wilco_ec_device *ec = dev_get_drvdata(dev);
> + struct wilco_ec_message msg;
> + u8 raw_request_data[EC_MAILBOX_DATA_SIZE];
> + int in_offset = 0;
> + int out_offset = 0;
> + int ret;
> +
> + while (in_offset < count) {
> + char word_buf[EC_MAILBOX_DATA_SIZE];
> + u8 byte;
> + int start_offset = in_offset;
> + int end_offset;
> +
> + /* Find the start of the byte */
> + while (buf[start_offset] && isspace(buf[start_offset]))
> + start_offset++;
> + if (!buf[start_offset])
> + break;
> +
> + /* Find the start of the next byte, if any */
> + end_offset = start_offset;
> + while (buf[end_offset] && !isspace(buf[end_offset]))
> + end_offset++;
> + if (start_offset > count || end_of
Re: [PATCH v3] memcg: schedule high reclaim for remote memcgs on high_work
On Mon, Jan 14, 2019 at 11:25 PM Michal Hocko wrote: > > On Mon 14-01-19 12:18:07, Shakeel Butt wrote: > > On Sun, Jan 13, 2019 at 10:34 AM Michal Hocko wrote: > > > > > > On Fri 11-01-19 14:54:32, Shakeel Butt wrote: > > > > Hi Johannes, > > > > > > > > On Fri, Jan 11, 2019 at 12:59 PM Johannes Weiner > > > > wrote: > > > > > > > > > > Hi Shakeel, > > > > > > > > > > On Thu, Jan 10, 2019 at 09:44:32AM -0800, Shakeel Butt wrote: > > > > > > If a memcg is over high limit, memory reclaim is scheduled to run on > > > > > > return-to-userland. However it is assumed that the memcg is the > > > > > > current > > > > > > process's memcg. With remote memcg charging for kmem or swapping > > > > > > in a > > > > > > page charged to remote memcg, current process can trigger reclaim on > > > > > > remote memcg. So, schduling reclaim on return-to-userland for > > > > > > remote > > > > > > memcgs will ignore the high reclaim altogether. So, record the memcg > > > > > > needing high reclaim and trigger high reclaim for that memcg on > > > > > > return-to-userland. However if the memcg is already recorded for > > > > > > high > > > > > > reclaim and the recorded memcg is not the descendant of the the > > > > > > memcg > > > > > > needing high reclaim, punt the high reclaim to the work queue. > > > > > > > > > > The idea behind remote charging is that the thread allocating the > > > > > memory is not responsible for that memory, but a different cgroup > > > > > is. Why would the same thread then have to work off any high excess > > > > > this could produce in that unrelated group? > > > > > > > > > > Say you have a inotify/dnotify listener that is restricted in its > > > > > memory use - now everybody sending notification events from outside > > > > > that listener's group would get throttled on a cgroup over which it > > > > > has no control. That sounds like a recipe for priority inversions. > > > > > > > > > > It seems to me we should only do reclaim-on-return when current is in > > > > > the ill-behaved cgroup, and punt everything else - interrupts and > > > > > remote charges - to the workqueue. > > > > > > > > This is what v1 of this patch was doing but Michal suggested to do > > > > what this version is doing. Michal's argument was that the current is > > > > already charging and maybe reclaiming a remote memcg then why not do > > > > the high excess reclaim as well. > > > > > > Johannes has a good point about the priority inversion problems which I > > > haven't thought about. > > > > > > > Personally I don't have any strong opinion either way. What I actually > > > > wanted was to punt this high reclaim to some process in that remote > > > > memcg. However I didn't explore much on that direction thinking if > > > > that complexity is worth it. Maybe I should at least explore it, so, > > > > we can compare the solutions. What do you think? > > > > > > My question would be whether we really care all that much. Do we know of > > > workloads which would generate a large high limit excess? > > > > > > > The current semantics of memory.high is that it can be breached under > > extreme conditions. However any workload where memory.high is used and > > a lot of remote memcg charging happens (inotify/dnotify example given > > by Johannes or swapping in tmpfs file or shared memory region) the > > memory.high breach will become common. > > This is exactly what I am asking about. Is this something that can > happen easily? Remote charges on themselves should be rare, no? > At the moment, for kmem we can do remote charging for fanotify, inotify and buffer_head and for anon pages we can do remote charging on swap in. Now based on the workload's cgroup setup the remote charging can be very frequent or rare. At Google, remote charging is very frequent but since we are still on cgroup-v1 and do not use memory.high, the issue this patch is fixing is not observed. However for the adoption of cgroup-v2, this fix is needed. Shakeel
RE: [PATCH] Documentation/process: hardcoded core.abbrev considered harmful!
> -Original Message- > From: Joe Perches [mailto:g...@perches.com] > Sent: Tuesday, January 15, 2019 11:41 AM > To: Ævar Arnfjörð Bjarmason ; Linus Torvalds > foundation.org> > Cc: linux-kernel@vger.kernel.org; Keller, Jacob E ; > Andrew > Morton ; Kirsher, Jeffrey T > > Subject: Re: [PATCH] Documentation/process: hardcoded core.abbrev considered > harmful! > > On Thu, 2018-12-20 at 01:01 +0100, Ævar Arnfjörð Bjarmason wrote: > > Stop recommending that core.abbrev=12 be hardcoded when referring to > > kernel commits, and instead rely on the git's default abbreviation. > > Nothing happened to this patch and there was no reply to > it as far as I can tell. > > This may be sensible for future git versions, but perhaps > there should be a different abbrev control added and the > kernel should enable that. > > > As an aside I have upcoming git.git patches so you'll be able to set > > core.abbbrev to e.g. +1 to get "13" now, "14" when it rolls over at > > ~16 million etc. Maybe that'll be a good fit for projects like > > linux.git that want more future-proof abbreviated SHAs than most. > > Will '$ git config --get core.abbrev' return a specific > number in that case? > > (not +1 and not blank as current if unspecified) > I wouldn't think so. There might need to be some sort of plumbing command added to obtain this information. Might be worth pointing that out on the git-devel mailing list. Thanks, Jake
Re: [PATCH v6] x86: load FPU registers on return to userland
On 1/15/19 4:44 AM, David Laight wrote: > Once this is done it might be worth while adding a parameter to > kernel_fpu_begin() to request the registers only when they don't > need saving. > This would benefit code paths where the gains are reasonable but not massive. > > The return value from kernel_fpu_begin() ought to indicate which > registers are available - none, SSE, SSE2, AVX, AVX512 etc. > So code can use an appropriate implementation. > (I've not looked to see if this is already the case!) Yeah, it would be sane to have both a mask passed, and returned, say: got = kernel_fpu_begin(XFEATURE_MASK_AVX512, NO_XSAVE_ALLOWED); if (got == XFEATURE_MASK_AVX512) do_avx_512_goo(); else do_integer_goo(); kernel_fpu_end(got) Then, kernel_fpu_begin() can actually work without even *doing* an XSAVE: /* Do we have to save state for anything in 'ask_mask'? */ if (all_states_are_init(ask_mask)) return ask_mask; Then kernel_fpu_end() just needs to zero out (re-init) the state, which it can do with XRSTORS and a careful combination of XSTATE_BV and the requested feature bitmap (RFBM). This is all just optimization, though.
Re: [PATCH] Documentation/process: hardcoded core.abbrev considered harmful!
On Thu, 2018-12-20 at 01:01 +0100, Ævar Arnfjörð Bjarmason wrote: > Stop recommending that core.abbrev=12 be hardcoded when referring to > kernel commits, and instead rely on the git's default abbreviation. Nothing happened to this patch and there was no reply to it as far as I can tell. This may be sensible for future git versions, but perhaps there should be a different abbrev control added and the kernel should enable that. > As an aside I have upcoming git.git patches so you'll be able to set > core.abbbrev to e.g. +1 to get "13" now, "14" when it rolls over at > ~16 million etc. Maybe that'll be a good fit for projects like > linux.git that want more future-proof abbreviated SHAs than most. Will '$ git config --get core.abbrev' return a specific number in that case? (not +1 and not blank as current if unspecified)
[PATCH net-next] net, decnet: use struct_size() in kzalloc()
One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
net/decnet/dn_fib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/decnet/dn_fib.c b/net/decnet/dn_fib.c
index f78fe58eafc8..6cd3737593a6 100644
--- a/net/decnet/dn_fib.c
+++ b/net/decnet/dn_fib.c
@@ -282,7 +282,7 @@ struct dn_fib_info *dn_fib_create_info(const struct rtmsg
*r, struct nlattr *att
(nhs = dn_fib_count_nhs(attrs[RTA_MULTIPATH])) == 0)
goto err_inval;
- fi = kzalloc(sizeof(*fi)+nhs*sizeof(struct dn_fib_nh), GFP_KERNEL);
+ fi = kzalloc(struct_size(fi, fib_nh, nhs), GFP_KERNEL);
err = -ENOBUFS;
if (fi == NULL)
goto failure;
--
2.20.1
Re: [PATCH v3 0/7] arm64: add system vulnerability sysfs entries
Hi Jeremy, > Jeremy Linton hat am 10. Januar 2019 um 00:55 > geschrieben: > > > Arm64 machines should be displaying a human readable > vulnerability status to speculative execution attacks in > /sys/devices/system/cpu/vulnerabilities > > This series enables that behavior by providing the expected > functions. Those functions expose the cpu errata and feature > states, as well as whether firmware is responding appropriately > to display the overall machine status. This means that in a > heterogeneous machine we will only claim the machine is mitigated > or safe if we are confident all booted cores are safe or > mitigated. > i applied this v3 series and Marc's v2 series. Now i'm getting the following on a Raspberry Pi 3 B+ : meltdown:Not affected spec_store_bypass:Not affected spectre_v1:Mitigation: __user pointer sanitization So the entries l1tf and spectre_v2 disappeared. Stefan
Re: [PATCH RT] printk: Shortcut out of waiter spinning on PREEMPT_RT
On Tue, 15 Jan 2019 19:54:33 +0100
Sebastian Andrzej Siewior wrote:
> On 2019-01-15 12:39:10 [-0500], Steven Rostedt wrote:
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -1742,6 +1742,13 @@ static int console_trylock_spinning(void)
> > if (console_trylock())
> > return 1;
> >
> > + /*
> > +* The consoles are preemptable in PREEMPT_RT, which can cause
> > +* spinning to deadlock.
> > +*/
> > + if (IS_ENABLED(CONFIG_PREEMPT_RT_FULL))
> > + return 0;
> > +
> > printk_safe_enter_irqsave(flags);
> >
> > raw_spin_lock(&console_owner_lock);
>
> So my ("printk: Make rt aware") patch does:
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 6553508ff3889..d983c509f74a2 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1617,6 +1617,7 @@ SYSCALL_DEFINE3(syslog, int, type, char __user *, buf,
> int, len)
> return do_syslog(type, buf, len, SYSLOG_FROM_READER);
> }
>
> +#ifndef CONFIG_PREEMPT_RT_FULL
> /*
> * Special console_lock variants that help to reduce the risk of
> soft-lockups.
> * They allow to pass console_lock to another printk() call using a busy
> wait.
> @@ -1757,6 +1758,15 @@ static int console_trylock_spinning(void)
> return 1;
> }
>
> +#else
> +
> +static int console_trylock_spinning(void)
> +{
> + return console_trylock();
> +}
> +
> +#endif
> +
> /*
> * Call the console drivers, asking them to write out
> * log_buf[start] to log_buf[end - 1].
>
>
> So it never gets into the codepath where you try to avoid spinning.
> Right?
>
You right! Which appears to be missing from my 4.14, and I thought I
looked for that in 4.19-rt too, but I guess I was still looking at
4.14 :-/. OK, ignore. Sorry for the noise.
Well, it wasn't a total waste. I now know what to backport to 4.14-rt
;-)
-- Steve
Re: [PATCH v11 1/9] dt-bindings: opp: Introduce opp-level bindings
On Thu, 10 Jan 2019 09:32:01 +0530, Rajendra Nayak wrote: > Add opp-level as an additional property in the OPP node to describe > the performance level of the device. > > On some SoCs (especially from Qualcomm and MediaTek) this value > is communicated to a remote microprocessor by the CPU, which > then takes some actions (like adjusting voltage values across various > rails) based on the value passed. > > Signed-off-by: Rajendra Nayak > --- > Documentation/devicetree/bindings/opp/opp.txt | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v5 2/7] nfc: pn532_uart: Add NXP PN532 to devicetree docs
On Fri, 11 Jan 2019 17:18:05 +0100, Lars Poeschel wrote: > Add a simple binding doc for the pn532. > > Cc: Johan Hovold > Signed-off-by: Lars Poeschel > --- > Changes in v4: > - Add documentation about reg property in case of i2c > > Changes in v3: > - seperate binding doc instead of entry in trivial-devices.txt > > .../devicetree/bindings/nfc/pn532.txt | 33 +++ > 1 file changed, 33 insertions(+) > create mode 100644 Documentation/devicetree/bindings/nfc/pn532.txt > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed.
Re: [PATCH v7 perf, bpf-next 6/8] perf util: handle PERF_RECORD_KSYMBOL
> On Jan 15, 2019, at 9:56 AM, Arnaldo Carvalho de Melo wrote:
>
> Em Thu, Jan 10, 2019 at 04:19:31PM -0800, Song Liu escreveu:
>> This patch handles PERF_RECORD_KSYMBOL in perf record/report.
>> Specifically, map and symbol are created for ksymbol register, and
>> removed for ksymbol unregister.
>>
>> This patch also set perf_event_attr.ksymbol properly. The flag is
>> ON by default.
>>
>> Signed-off-by: Song Liu
>> ---
>> tools/perf/util/event.c | 21 +++
>> tools/perf/util/event.h | 20 ++
>> tools/perf/util/evsel.c | 9 +++
>> tools/perf/util/evsel.h | 1 +
>> tools/perf/util/machine.c | 57 +++
>> tools/perf/util/machine.h | 3 +++
>> tools/perf/util/session.c | 4 +++
>> tools/perf/util/tool.h| 4 ++-
>> 8 files changed, 118 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
>> index 937a5a4f71cc..3c8a6a8dd260 100644
>> --- a/tools/perf/util/event.c
>> +++ b/tools/perf/util/event.c
>> @@ -24,6 +24,7 @@
>> #include "symbol/kallsyms.h"
>> #include "asm/bug.h"
>> #include "stat.h"
>> +#include "session.h"
>>
>> #define DEFAULT_PROC_MAP_PARSE_TIMEOUT 500
>>
>> @@ -45,6 +46,7 @@ static const char *perf_event__names[] = {
>> [PERF_RECORD_SWITCH]= "SWITCH",
>> [PERF_RECORD_SWITCH_CPU_WIDE] = "SWITCH_CPU_WIDE",
>> [PERF_RECORD_NAMESPACES]= "NAMESPACES",
>> +[PERF_RECORD_KSYMBOL] = "KSYMBOL",
>> [PERF_RECORD_HEADER_ATTR] = "ATTR",
>> [PERF_RECORD_HEADER_EVENT_TYPE] = "EVENT_TYPE",
>> [PERF_RECORD_HEADER_TRACING_DATA] = "TRACING_DATA",
>> @@ -1329,6 +1331,14 @@ int perf_event__process_switch(struct perf_tool *tool
>> __maybe_unused,
>> return machine__process_switch_event(machine, event);
>> }
>>
>> +int perf_event__process_ksymbol(struct perf_tool *tool __maybe_unused,
>> +union perf_event *event,
>> +struct perf_sample *sample __maybe_unused,
>> +struct machine *machine)
>> +{
>> +return machine__process_ksymbol(machine, event, sample);
>> +}
>> +
>> size_t perf_event__fprintf_mmap(union perf_event *event, FILE *fp)
>> {
>> return fprintf(fp, " %d/%d: [%#" PRIx64 "(%#" PRIx64 ") @ %#" PRIx64
>> "]: %c %s\n",
>> @@ -1461,6 +1471,14 @@ static size_t perf_event__fprintf_lost(union
>> perf_event *event, FILE *fp)
>> return fprintf(fp, " lost %" PRIu64 "\n", event->lost.lost);
>> }
>>
>> +size_t perf_event__fprintf_ksymbol(union perf_event *event, FILE *fp)
>> +{
>> +return fprintf(fp, " ksymbol event with addr %lx len %u type %u flags
>> 0x%x name %s\n",
>> + event->ksymbol_event.addr, event->ksymbol_event.len,
>> + event->ksymbol_event.ksym_type,
>> + event->ksymbol_event.flags, event->ksymbol_event.name);
>> +}
>> +
>> size_t perf_event__fprintf(union perf_event *event, FILE *fp)
>> {
>> size_t ret = fprintf(fp, "PERF_RECORD_%s",
>> @@ -1496,6 +1514,9 @@ size_t perf_event__fprintf(union perf_event *event,
>> FILE *fp)
>> case PERF_RECORD_LOST:
>> ret += perf_event__fprintf_lost(event, fp);
>> break;
>> +case PERF_RECORD_KSYMBOL:
>> +ret += perf_event__fprintf_ksymbol(event, fp);
>> +break;
>> default:
>> ret += fprintf(fp, "\n");
>> }
>> diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
>> index eb95f3384958..018322f2a13e 100644
>> --- a/tools/perf/util/event.h
>> +++ b/tools/perf/util/event.h
>> @@ -5,6 +5,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "../perf.h"
>> #include "build-id.h"
>> @@ -84,6 +85,19 @@ struct throttle_event {
>> u64 stream_id;
>> };
>>
>> +#ifndef KSYM_NAME_LEN
>> +#define KSYM_NAME_LEN 256
>> +#endif
>> +
>> +struct ksymbol_event {
>> +struct perf_event_header header;
>> +u64 addr;
>> +u32 len;
>> +u16 ksym_type;
>> +u16 flags;
>> +char name[KSYM_NAME_LEN];
>> +};
>> +
>> #define PERF_SAMPLE_MASK \
>> (PERF_SAMPLE_IP | PERF_SAMPLE_TID | \
>> PERF_SAMPLE_TIME | PERF_SAMPLE_ADDR | \
>> @@ -651,6 +665,7 @@ union perf_event {
>> struct stat_round_event stat_round;
>> struct time_conv_event time_conv;
>> struct feature_eventfeat;
>> +struct ksymbol_eventksymbol_event;
>> };
>>
>> void perf_event__print_totals(void);
>> @@ -748,6 +763,10 @@ int perf_event__process_exit(struct perf_tool *tool,
>> union perf_event *event,
>> struct perf_sample *sample,
>> struct machine *machine);
>> +int perf_event__process_ksymbol(struct perf_tool *tool,
>> +union perf_event *event,
>> +
Re: [PATCH 2/2] bpf: annotate implicit fall through
On 01/15/2019 10:03 AM, Sergei Shtylyov wrote: > On 14.01.2019 23:29, Mathieu Malaterre wrote: > >> There is a plan to build the kernel with -Wimplicit-fallthrough and >> thise place in the code produced a warnings (W=1). > > This? > >> In this particular case change a ‘:’ with a ‘,’ so as to match the >> regular expression expected by GCC. >> >> This commit remove the following warning: >> >> net/core/filter.c:5310:6: warning: this statement may fall through >> [-Wimplicit-fallthrough=] >> >> Signed-off-by: Mathieu Malaterre Please respin and also make the two subject lines not exactly the same. Thanks, Daniel >> --- >> net/core/filter.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/net/core/filter.c b/net/core/filter.c >> index 447dd1bad31f..c8069a142994 100644 >> --- a/net/core/filter.c >> +++ b/net/core/filter.c >> @@ -5309,7 +5309,7 @@ bpf_base_func_proto(enum bpf_func_id func_id) >> case BPF_FUNC_trace_printk: >> if (capable(CAP_SYS_ADMIN)) >> return bpf_get_trace_printk_proto(); >> - /* else: fall through */ >> + /* else, fall through */ > > The other patches seem to just drop "else:"... > >> default: >> return NULL; >> } >> > > MBR, Sergei
Re: [PATCH 1/5] pwm: mediatek: add a property "mediatek,num-pwms"
On Mon, Jan 14, 2019 at 04:21:20PM +0800, Ryder Lee wrote:
> This adds a property "mediatek,num-pwms" to avoid having an endless
> list of compatibles with no other differences for the same driver.
I seem to recall having said something similar before, but maybe this
was a different series (there is no v2 or higher in the Subject ...)
I think it would be sensible to drop the vendor prefix and go with plain
"num-pwms" (or "npwms" to align to "ngpios" in the gpio bindings).
> Signed-off-by: Ryder Lee
> ---
> drivers/pwm/pwm-mediatek.c | 25 +++--
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
> index eb6674c..37daa84 100644
> --- a/drivers/pwm/pwm-mediatek.c
> +++ b/drivers/pwm/pwm-mediatek.c
> @@ -55,7 +55,6 @@ enum {
> };
>
> struct mtk_pwm_platform_data {
> - unsigned int num_pwms;
> bool pwm45_fixup;
> bool has_clks;
> };
> @@ -226,10 +225,11 @@ static void mtk_pwm_disable(struct pwm_chip *chip,
> struct pwm_device *pwm)
>
> static int mtk_pwm_probe(struct platform_device *pdev)
> {
> + struct device_node *np = pdev->dev.of_node;
> const struct mtk_pwm_platform_data *data;
> struct mtk_pwm_chip *pc;
> struct resource *res;
> - unsigned int i;
> + unsigned int i, num_pwms;
> int ret;
>
> pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
> @@ -246,7 +246,13 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> if (IS_ERR(pc->regs))
> return PTR_ERR(pc->regs);
>
> - for (i = 0; i < data->num_pwms + 2 && pc->soc->has_clks; i++) {
> + ret = of_property_read_u32(np, "mediatek,num-pwms", &num_pwms);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to get pwm number: %d\n", ret);
This sounds wrong. "Failed to get number of pwms" sounds better to my
(non-native) ear.
> + return ret;
> + }
> +
> + for (i = 0; i < num_pwms + 2 && pc->soc->has_clks; i++) {
> pc->clks[i] = devm_clk_get(&pdev->dev, mtk_pwm_clk_name[i]);
> if (IS_ERR(pc->clks[i])) {
> dev_err(&pdev->dev, "clock: %s fail: %ld\n",
> @@ -260,7 +266,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> pc->chip.dev = &pdev->dev;
> pc->chip.ops = &mtk_pwm_ops;
> pc->chip.base = -1;
> - pc->chip.npwm = data->num_pwms;
> + pc->chip.npwm = num_pwms;
>
> ret = pwmchip_add(&pc->chip);
> if (ret < 0) {
> @@ -279,32 +285,23 @@ static int mtk_pwm_remove(struct platform_device *pdev)
> }
>
> static const struct mtk_pwm_platform_data mt2712_pwm_data = {
> - .num_pwms = 8,
> - .pwm45_fixup = false,
> - .has_clks = true,
> -};
> -
> -static const struct mtk_pwm_platform_data mt7622_pwm_data = {
> - .num_pwms = 6,
> .pwm45_fixup = false,
> .has_clks = true,
I agree with Matthias Brugger that at least for some time you should be
able to fall back to the right number of pwms if the device tree doesn't
have a num-pwms property.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH 3/5] arm64: dts: mt7622: add a property "mediatek,num-pwms" for PWM
Hello, On Mon, Jan 14, 2019 at 04:21:22PM +0800, Ryder Lee wrote: > This adds a property "mediatek,num-pwms" for PWM controller. > > Signed-off-by: Ryder Lee > --- > arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi > b/arch/arm64/boot/dts/mediatek/mt7622.dtsi > index 8fc4aa7..ab016cf 100644 > --- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi > @@ -436,6 +436,7 @@ ><&pericfg CLK_PERI_PWM6_PD>; > clock-names = "top", "main", "pwm1", "pwm2", "pwm3", "pwm4", > "pwm5", "pwm6"; > + mediatek,num-pwms = <6>; > status = "disabled"; Conceptually this patch must go in before the change to the driver. Otherwise the pwms are not usable with only patch 1 applied which breaks bisectability. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH V8 1/3] dt-bindings: mmc: tegra: Add supports-cqe property
On Thu, Jan 10, 2019 at 07:08:53PM -0800, Sowjanya Komatineni wrote: > Add supports-cqe optional property for Tegra SDMMC. > > Tegra186 and Tegra194 supports HW Command queue only > on SDMMC4 controller. This property is used to identify > command queue support controller in the tegra sdhci driver. > > Signed-off-by: Sowjanya Komatineni > --- > Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt > b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt > index 32b4b4e41923..fb14c2c8d7ee 100644 > --- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt > +++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt > @@ -72,6 +72,10 @@ Optional properties for Tegra210 and Tegra186: > - nvidia,default-trim : Specify the default outbound clock trimmer >value. > - nvidia,dqs-trim : Specify DQS trim value for HS400 timing > +- supports-cqe : The presence of this property indicates that the > + corresponding controller supports HW command queue feature. > + Tegra186 and Tegra194 has 4 SDMMC Controllers and only SDMMC4 > + controller supports HW Command Queue with eMMC device. Don't SDHCI capability bits do this? If not, this should probably be common. Rob
Re: [PATCH v7 1/5] dt-bindings: leds: Add pattern initialization from Device Tree
On Wed, 9 Jan 2019 15:44:45 +0100, Krzysztof Kozlowski wrote: > Document new led-pattern property for initialization of LED triggers. > The property format is trigger-specific (except being array of > integers). For pattern trigger, the explanation of pattern format was > moved to a common file shared with sysfs ABI. > > Signed-off-by: Krzysztof Kozlowski > Acked-by: Pavel Machek > --- > .../ABI/testing/sysfs-class-led-trigger-pattern| 51 > ++ > Documentation/devicetree/bindings/leds/common.txt | 12 + > .../bindings/leds/leds-trigger-pattern.txt | 49 + > 3 files changed, 64 insertions(+), 48 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt > Reviewed-by: Rob Herring
Re: [PATCH V4 1/3] dt-bindings: mmc: tegra: Add pinctrl for SDMMC drive strengths
On Thu, 10 Jan 2019 14:46:01 -0800, Sowjanya Komatineni wrote: > Add pinctrls for 3V3 and 1V8 pad drive strength configuration for > Tegra210 sdmmc. > > Tegra210 sdmmc has pad configuration registers in pinmux register > domain and handled thru pinctrl to pinmux device node. > > Tegra186 and Tegra194 has pad configuration register with in the > SDMMC register domain itself and are handles thru drive strength > properties in sdmmc device node. > > Signed-off-by: Sowjanya Komatineni > --- > Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
RE: [PATCH V8 1/3] dt-bindings: mmc: tegra: Add supports-cqe property
DKIM-Signature: v aiagnostics: x-ms-exchange-antispam-srfa-diagnostics: x-forefront-antispam-report: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-forefront-prvs:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:spamdiagnosticoutput: spamdiagnosticmetadata:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id: X-MS-Exchange-Transport-CrossTenantHeadersStamped:X-OriginatorOrg: Content-Language:Content-Type:Content-Transfer-Encoding; b
[PATCH net-next] libceph, ceph: use struct_size() in kmalloc()
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
instance = kmalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
net/ceph/osdmap.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
index 98c0ff3d6441..48a31dc9161c 100644
--- a/net/ceph/osdmap.c
+++ b/net/ceph/osdmap.c
@@ -495,9 +495,8 @@ static struct crush_map *crush_decode(void *pbyval, void
*end)
/ sizeof(struct crush_rule_step))
goto bad;
#endif
- r = c->rules[i] = kmalloc(sizeof(*r) +
- yes*sizeof(struct crush_rule_step),
- GFP_NOFS);
+ r = kmalloc(struct_size(r, steps, yes), GFP_NOFS);
+ c->rules[i] = r;
if (r == NULL)
goto badmem;
dout(" rule %d is at %p\n", i, r);
--
2.20.1
Re: [PATCH v4 1/5] dt-bindings: display: bridge: fork out ti,ds90c185 from lvds-transmitter
On Fri, 11 Jan 2019 15:18:55 +, Peter Rosin wrote: > DS90C185 has a shutdown pin which does not fit in the lvds-transmitter > binding, which is meant to be generic. > > The sister chip DS90C187 is similar to DS90C185, describe it here as well. > > Signed-off-by: Peter Rosin > --- > .../bindings/display/bridge/lvds-transmitter.txt | 10 ++-- > .../bindings/display/bridge/ti,ds90c185.txt| 55 > ++ > 2 files changed, 59 insertions(+), 6 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt > Reviewed-by: Rob Herring
Re: [PATCH v4 01/14] dt-bindings: pinctrl: qcom-pmic-gpio: add qcom,pmi8998-gpio binding
On Sun, 13 Jan 2019 10:47:03 -0500, Brian Masney wrote: > Add support for the PMI8998 GPIO variant to the Qualcomm PMIC GPIO > binding document. > > Signed-off-by: Brian Masney > --- > This is a new patch introduced in V4. > > Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring
[PATCH v2] drm/i915: Pass down rc in intel_encoder->compute_config()
Something that I completely missed when implementing the new MST VCPI
atomic helpers is that with those helpers, there's technically a chance
of us having to grab additional modeset locks in ->compute_config() and
furthermore, that means we have the potential to hit a normal modeset
deadlock. However, because ->compute_config() only returns a bool this
means we can't return -EDEADLK when we need to drop locks and try again
which means we end up just failing the atomic check permanently. Whoops.
So, fix this by modifying ->compute_config() to pass down an actual
error code instead of a bool so that the atomic check can be restarted
on modeset deadlocks.
Thanks to Ville Syrjälä for pointing this out!
Changes since v1:
* Add some newlines
* Return only -EINVAL from hsw_crt_compute_config()
* Propogate return code from intel_dp_compute_dsc_params()
* Change all of the intel_dp_compute_link_config*() variants
* Don't miss if (hdmi_port_clock_valid()) branch in
intel_hdmi_compute_config()
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
---
drivers/gpu/drm/i915/icl_dsi.c | 8 ++--
drivers/gpu/drm/i915/intel_crt.c | 35 +++---
drivers/gpu/drm/i915/intel_ddi.c | 6 +--
drivers/gpu/drm/i915/intel_display.c | 11 +++--
drivers/gpu/drm/i915/intel_dp.c | 71 +++-
drivers/gpu/drm/i915/intel_dp_mst.c | 12 ++---
drivers/gpu/drm/i915/intel_drv.h | 18 +++
drivers/gpu/drm/i915/intel_dvo.c | 11 +++--
drivers/gpu/drm/i915/intel_hdmi.c| 14 +++---
drivers/gpu/drm/i915/intel_lvds.c| 12 ++---
drivers/gpu/drm/i915/intel_sdvo.c| 14 +++---
drivers/gpu/drm/i915/intel_tv.c | 8 ++--
drivers/gpu/drm/i915/vlv_dsi.c | 14 +++---
13 files changed, 122 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index f3a5f03646ce..355b48d1c937 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
}
-static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
-struct intel_crtc_state *pipe_config,
-struct drm_connector_state *conn_state)
+static int gen11_dsi_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
{
struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
base);
@@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct intel_encoder
*encoder,
pipe_config->clock_set = true;
pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
- return true;
+ return 0;
}
static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 33bd2addcbdd..081c333f30d2 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -345,51 +345,52 @@ intel_crt_mode_valid(struct drm_connector *connector,
return MODE_OK;
}
-static bool intel_crt_compute_config(struct intel_encoder *encoder,
-struct intel_crtc_state *pipe_config,
-struct drm_connector_state *conn_state)
+static int intel_crt_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
{
struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
- return false;
+ return -EINVAL;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
- return true;
+
+ return 0;
}
-static bool pch_crt_compute_config(struct intel_encoder *encoder,
- struct intel_crtc_state *pipe_config,
- struct drm_connector_state *conn_state)
+static int pch_crt_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
{
struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
- return false;
+ return -EINVAL;
pipe_config->has_pch_encoder = true;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
-
Re: [PATCH shawn/for-next v4 1/2] dt-bindings: arm: Add Y Soft IOTA Draco, Hydra and Ursa boards
On Tue, 15 Jan 2019 14:22:44 +, =?utf-8?B?Vm9rw6HEjSBNaWNoYWw=?= wrote: > These are i.MX6DualLite/Solo based single board computers used > in various Y Soft products. > > Cc: Andrew Lunn > Signed-off-by: Michal Vokáč > --- > Changes since v2: > - New patch > > Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH 1/2] pwm: sifive: Add DT documentation for SiFive PWM Controller
Hello,
this is v3, right? It is helpful to point this out to ease reviewing.
On Fri, Jan 11, 2019 at 01:52:43PM +0530, Yash Shah wrote:
> DT documentation for PWM controller added with updated compatible
> string.
Not sure what was updated here. But assuming this is compared to v2 this
is not a helpful info in the commit log.
> Signed-off-by: Wesley W. Terpstra
> [Atish: Compatible string update]
> Signed-off-by: Atish Patra
> Signed-off-by: Yash Shah
> ---
> .../devicetree/bindings/pwm/pwm-sifive.txt | 37
> ++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> new file mode 100644
> index 000..e0fc22a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> @@ -0,0 +1,37 @@
> +SiFive PWM controller
> +
> +Unlike most other PWM controllers, the SiFive PWM controller currently only
> +supports one period for all channels in the PWM. This is set globally in DTS.
> +The period also has significant restrictions on the values it can achieve,
> +which the driver rounds to the nearest achievable frequency.
> +
> +Required properties:
> +- compatible: Please refer to sifive-blocks-ip-versioning.txt
While the description was too verbose in v2, this is too short. You
should at least mention something like "sifive,pwmX" and
"sifive,$cpuname-pwm" (or how ever that scheme works).
> +- reg: physical base address and length of the controller's registers
> +- clocks: Should contain a clock identifier for the PWM's parent clock.
> +- #pwm-cells: Should be 2.
> + The first cell is the PWM channel number
> + The second cell is the PWM polarity
I'd drop these two lines and refer to bindings/pwm/pwm.txt instead.
> +- sifive,approx-period-ns: the driver will get as close to this period as it
> can
As already said for v2: I'd drop "approx-".
> +- interrupts: one interrupt per PWM channel
> +
> +PWM RTL that corresponds to the IP block version numbers can be found
> +here:
> +
> +https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm
> +
> +Further information on the format of the IP
> +block-specific version numbers can be found in
> +Documentation/devicetree/bindings/sifive/sifive-blocks-ip-versioning.txt
> +
> +Examples:
> +
> +pwm: pwm@1002 {
> + compatible = "sifive,fu540-c000-pwm","sifive,pwm0";
> + reg = <0x0 0x1002 0x0 0x1000>;
> + clocks = <&tlclk>;
> + interrupt-parent = <&plic>;
> + interrupts = <42 43 44 45>;
> + #pwm-cells = <2>;
> + sifive,approx-period-ns = <100>;
> +};
> --
> 1.9.1
>
>
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH shawn/for-next v4 2/2] ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa boards
On Tue, 15 Jan 2019 14:22:45 +, =?utf-8?B?Vm9rw6HEjSBNaWNoYWw=?= wrote:
> These are i.MX6S/DL based SBCs embedded in various Y Soft products.
> All share the same board design but have slightly different HW
> configuration.
>
> Ursa
> - i.MX6S SoC, 512MB RAM DDR3, 4GB eMMC, microSD
> - parallel WVGA 7" LCD with touch panel
> - 1x Eth (QCA8334 switch)
> - USB OTG
> - USB host (micro-B)
>
> Draco
> - i.MX6S SoC, 512MB RAM DDR3, 4GB eMMC, microSD
> - parallel WVGA 7" LCD with touch panel
> - 2x Eth (QCA8334 switch)
> - USB OTG
> - USB host (micro-B)
> - RGB LED (I2C LP5562)
> - 3.5mm audio jack + codec (LM49350)
>
> Hydra
> - i.MX6DL SoC, 2GB RAM DDR3, 4GB eMMC, microSD
> - I2C OLED display, capacitive matrix keys
> - 2x Eth (QCA8334 switch)
> - USB OTG
> - RGB LED (I2C LP5562)
> - 3.5mm audio jack + codec (LM49350)
> - HDMI
> - miniPCIe slot
>
> Cc: Andrew Lunn
> Signed-off-by: Michal Vokáč
> ---
> Changes since v3:
> - Do not abbreviate regulator word in node names. (Shawn)
> - Sort fixed regulator nodes alphabetically.
> - Sort pmic regulator childe nodes alphabetically.
> - Use newline between properties and child node in switch node. (Shawn)
> - Sort i2c bus child nodes in order of unit-address. (Shawn)
> - Rename PWM pinctl label to be consistent with node name. (Shawn)
>
> Changes since v2:
> - Remove cpus {/delete-node/ cpu@1;}; node from i.MX6Solo based board.
> (Fabio)
> - Use "device_type = "memory";" in memory nodes. (Fabio)
> - Use GPIO_ACTIVE_LOW for fec phy-reset-gpios. (Fabio)
> - Use "-" in node names. (Rob)
> - Remove label from led-controller node. (Rob)
>
> Changes since v1:
> - Enable HDMI on Hydra board.
> - Move regulators to the root node and remove simple-bus property. (Rob)
> - Remove reg and unit-address property from regulators. (Rob)
> - Use correct names for led-controller and pmic node. (Rob)
> - Use wakeup-source instead of deprecated enable-sdio-wakeup. (Shawn)
>
> arch/arm/boot/dts/Makefile | 3 +
> arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 595
> +
> arch/arm/boot/dts/imx6dl-yapp4-draco.dts | 58 +++
> arch/arm/boot/dts/imx6dl-yapp4-hydra.dts | 50 +++
> arch/arm/boot/dts/imx6dl-yapp4-ursa.dts| 54 +++
> 5 files changed, 760 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
> create mode 100644 arch/arm/boot/dts/imx6dl-yapp4-draco.dts
> create mode 100644 arch/arm/boot/dts/imx6dl-yapp4-hydra.dts
> create mode 100644 arch/arm/boot/dts/imx6dl-yapp4-ursa.dts
>
Reviewed-by: Rob Herring
Re: [PATCH v3 10/15] dt-bindings: PCI: aardvark: Describe the PCIe endpoint card reset pins
On Tue, 8 Jan 2019 17:24:35 +0100, Miquel Raynal wrote: > A line might be used by the PCIe IP to reset the endpoint card upon: > - platform reset, > - hot reset, > - link failure. > > Describe the properties needed in this case (optional). > > Signed-off-by: Miquel Raynal > --- > Documentation/devicetree/bindings/pci/aardvark-pci.txt | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v3 2/4] dt-bindings: hwmon: add dps650ab documentation
On Thu, 10 Jan 2019 10:24:33 +0800, Xiaoting Liu wrote: > Bindings for Delta Electronics DPS-650-AB power supply. > > Signed-off-by: Xiaoting Liu > --- > v3: > Change patch commit message. > Add vendor delta to the compatible property. > --- > v2: > Change the patch subject. > --- > Documentation/devicetree/bindings/hwmon/dps650ab.txt | 11 +++ > 1 file changed, 11 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v2] drm/i915: Pass down rc in intel_encoder->compute_config()
On Tue, Jan 15, 2019 at 03:08:00PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the potential to hit a normal modeset
> deadlock. However, because ->compute_config() only returns a bool this
> means we can't return -EDEADLK when we need to drop locks and try again
> which means we end up just failing the atomic check permanently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Changes since v1:
> * Add some newlines
> * Return only -EINVAL from hsw_crt_compute_config()
> * Propogate return code from intel_dp_compute_dsc_params()
> * Change all of the intel_dp_compute_link_config*() variants
> * Don't miss if (hdmi_port_clock_valid()) branch in
> intel_hdmi_compute_config()
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
Patch looks great. Hopefully we got them all.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 8 ++--
> drivers/gpu/drm/i915/intel_crt.c | 35 +++---
> drivers/gpu/drm/i915/intel_ddi.c | 6 +--
> drivers/gpu/drm/i915/intel_display.c | 11 +++--
> drivers/gpu/drm/i915/intel_dp.c | 71 +++-
> drivers/gpu/drm/i915/intel_dp_mst.c | 12 ++---
> drivers/gpu/drm/i915/intel_drv.h | 18 +++
> drivers/gpu/drm/i915/intel_dvo.c | 11 +++--
> drivers/gpu/drm/i915/intel_hdmi.c| 14 +++---
> drivers/gpu/drm/i915/intel_lvds.c| 12 ++---
> drivers/gpu/drm/i915/intel_sdvo.c| 14 +++---
> drivers/gpu/drm/i915/intel_tv.c | 8 ++--
> drivers/gpu/drm/i915/vlv_dsi.c | 14 +++---
> 13 files changed, 122 insertions(+), 112 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index f3a5f03646ce..355b48d1c937 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
> *encoder,
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
> }
>
> -static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int gen11_dsi_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
> base);
> @@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct
> intel_encoder *encoder,
> pipe_config->clock_set = true;
> pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
>
> - return true;
> + return 0;
> }
>
> static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 33bd2addcbdd..081c333f30d2 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -345,51 +345,52 @@ intel_crt_mode_valid(struct drm_connector *connector,
> return MODE_OK;
> }
>
> -static bool intel_crt_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int intel_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> - return true;
> +
> + return 0;
> }
>
> -static bool pch_crt_compute_config(struct intel_encoder *encoder,
> -struct intel_crtc_state *pipe_config,
> -struct drm_connector_state *conn_state)
> +static int pch_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_m
Re: [PATCH v3 1/5] misc: dt-bindings: Add Qualcomm Fastrpc bindings
On Mon, Jan 14, 2019 at 07:41:08PM +, Srinivas Kandagatla wrote:
> The FastRPC driver implements an IPC (Inter-Processor Communication)
> mechanism that allows for clients to transparently make remote method
> invocations across DSP and APPS boundaries. This enables developers
> to offload tasks to the DSP and free up the application processor for
> other tasks.
>
> Co-developed-by: Thierry Escande
> Signed-off-by: Thierry Escande
> Signed-off-by: Srinivas Kandagatla
> ---
> .../devicetree/bindings/misc/qcom,fastrpc.txt | 84 +++
> 1 file changed, 84 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
> b/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
> new file mode 100644
> index ..004e636b4133
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
> @@ -0,0 +1,84 @@
> +Qualcomm Technologies, Inc. FastRPC Driver
> +
> +The FastRPC driver implements an IPC (Inter-Processor Communication)
driver or this is a h/w block?
> +mechanism that allows for clients to transparently make remote method
> +invocations across DSP and APPS boundaries. This enables developers
> +to offload tasks to the DSP and free up the application processor for
> +other tasks.
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be "qcom,fastrpc"
> +
> +- label
> + Usage: required
> + Value type:
> + Definition: should specify the dsp domain name this fastrpc
> + corresponds to. must be one of this: "adsp", "mdsp", "sdsp", "cdsp"
> +
> +- #address-cells
> + Usage: required
> + Value type:
> + Definition: Must be 1
> +
> +- #size-cells
> + Usage: required
> + Value type:
> + Definition: Must be 0
> +
> += COMPUTE BANKS
> +Each subnode of the Fastrpc node represents compute context banks available
> +on the dsp. The name of the nodes are not important. The properties of these
Please specify what the node names are.
> +nodes are defined by the individual bindings for the specific service
> +- All Compute context banks MUST contain the following property:
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be "qcom,fastrpc-compute-cb"
> +
> +- reg
> + Usage: required
> + Value type:
> + Definition: Context Bank ID.
> +
> +- secured:
> + Usage: Optional
> + Value type:
> + Defination: Indicating context bank is secured
What does 'secured' mean here?
> +
> +- nsessions:
> + Usage: Optional
> + Value type:
> + Defination: A value indicating how many sessions can share this
> + context bank. Defaults to 1 when this property
> + is not specified.
Needs a vendor prefix.
> +
> +Example:
> +
> +adsp-pil {
> + compatible = "qcom,msm8996-adsp-pil";
> + ...
> + smd-edge {
> + label = "lpass";
> + fastrpc {
> + compatible = "qcom,fastrpc";
> + qcom,smd-channels = "fastrpcsmd-apps-dsp";
> + lable = "adsp";
typo.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cb@1 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <1>;
> + };
> +
> + cb@2 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <2>;
> + };
> + ...
> + };
> + };
> +};
> --
> 2.20.1
>
[PATCH] libnvdimm/label: Clear 'updating' flag after label-set update
The UEFI 2.7 specification sets expectations that the 'updating' flag is
eventually cleared. To date, the libnvdimm core has never adhered to
that protocol. The policy of the core matches the policy of other
multi-device info-block formats like MD-Software-RAID that expect
administrator intervention on inconsistent info-blocks, not automatic
invalidation.
However, some pre-boot environments may unfortunately attempt to "clean
up" the labels and invalidate a set when it fails to find at least one
"non-updating" label in the set. Clear the updating flag after set
updates to minimize the window of vulnerability to aggressive pre-boot
environments.
Ideally implementations would not write to the label area outside of
creating namespaces.
Note that this only minimizes the window, it does not close it as the
system can still crash while clearing the flag and the set can be
subsequently deleted / invalidated by the pre-boot environment.
Fixes: f524bf271a5c ("libnvdimm: write pmem label set")
Cc:
Cc: Kelly Couch
Signed-off-by: Dan Williams
---
drivers/nvdimm/label.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index a11bf4e6b451..6d6e9a12150b 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -755,7 +755,7 @@ static const guid_t *to_abstraction_guid(enum
nvdimm_claim_class claim_class,
static int __pmem_label_update(struct nd_region *nd_region,
struct nd_mapping *nd_mapping, struct nd_namespace_pmem *nspm,
- int pos)
+ int pos, unsigned long flags)
{
struct nd_namespace_common *ndns = &nspm->nsio.common;
struct nd_interleave_set *nd_set = nd_region->nd_set;
@@ -796,7 +796,7 @@ static int __pmem_label_update(struct nd_region *nd_region,
memcpy(nd_label->uuid, nspm->uuid, NSLABEL_UUID_LEN);
if (nspm->alt_name)
memcpy(nd_label->name, nspm->alt_name, NSLABEL_NAME_LEN);
- nd_label->flags = __cpu_to_le32(NSLABEL_FLAG_UPDATING);
+ nd_label->flags = __cpu_to_le32(flags);
nd_label->nlabel = __cpu_to_le16(nd_region->ndr_mappings);
nd_label->position = __cpu_to_le16(pos);
nd_label->isetcookie = __cpu_to_le64(cookie);
@@ -1249,13 +1249,13 @@ static int del_labels(struct nd_mapping *nd_mapping, u8
*uuid)
int nd_pmem_namespace_label_update(struct nd_region *nd_region,
struct nd_namespace_pmem *nspm, resource_size_t size)
{
- int i;
+ int i, rc;
for (i = 0; i < nd_region->ndr_mappings; i++) {
struct nd_mapping *nd_mapping = &nd_region->mapping[i];
struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
struct resource *res;
- int rc, count = 0;
+ int count = 0;
if (size == 0) {
rc = del_labels(nd_mapping, nspm->uuid);
@@ -1273,7 +1273,20 @@ int nd_pmem_namespace_label_update(struct nd_region
*nd_region,
if (rc < 0)
return rc;
- rc = __pmem_label_update(nd_region, nd_mapping, nspm, i);
+ rc = __pmem_label_update(nd_region, nd_mapping, nspm, i,
+ NSLABEL_FLAG_UPDATING);
+ if (rc)
+ return rc;
+ }
+
+ if (size == 0)
+ return 0;
+
+ /* Clear the UPDATING flag per UEFI 2.7 expectations */
+ for (i = 0; i < nd_region->ndr_mappings; i++) {
+ struct nd_mapping *nd_mapping = &nd_region->mapping[i];
+
+ rc = __pmem_label_update(nd_region, nd_mapping, nspm, i, 0);
if (rc)
return rc;
}
Re: [PATCH v6] x86: load FPU registers on return to userland
On Tue, Jan 15, 2019 at 11:46 AM Dave Hansen wrote: > > On 1/15/19 4:44 AM, David Laight wrote: > > Once this is done it might be worth while adding a parameter to > > kernel_fpu_begin() to request the registers only when they don't > > need saving. > > This would benefit code paths where the gains are reasonable but not > > massive. > > > > The return value from kernel_fpu_begin() ought to indicate which > > registers are available - none, SSE, SSE2, AVX, AVX512 etc. > > So code can use an appropriate implementation. > > (I've not looked to see if this is already the case!) > > Yeah, it would be sane to have both a mask passed, and returned, say: > > got = kernel_fpu_begin(XFEATURE_MASK_AVX512, NO_XSAVE_ALLOWED); > > if (got == XFEATURE_MASK_AVX512) > do_avx_512_goo(); > else > do_integer_goo(); > > kernel_fpu_end(got) > > Then, kernel_fpu_begin() can actually work without even *doing* an XSAVE: > > /* Do we have to save state for anything in 'ask_mask'? */ > if (all_states_are_init(ask_mask)) > return ask_mask; > > Then kernel_fpu_end() just needs to zero out (re-init) the state, which > it can do with XRSTORS and a careful combination of XSTATE_BV and the > requested feature bitmap (RFBM). > > This is all just optimization, though. I don't think we'd ever want kernel_fpu_end() to restore anything, right? I'm a bit confused as to when this optimization would actually be useful. Jason Donenfeld has a rather nice API for this in his Zinc series. Jason, how is that coming?
Re: [PATCH v3 2/2] dt-bindings: iio: chemical: Add bindings for bme680
On Mon, 14 Jan 2019 15:19:14 -0500, Sebastien Bourdelin wrote: > BME680 is a pressure/temperature/humidity/voc sensor. > > Signed-off-by: Sebastien Bourdelin > --- > v2 -> v3: > - change i2c address to 0x76 as it seems more reliable: Suggested by > Himanshu Jha > - rebase on master > --- > .../devicetree/bindings/iio/chemical/bme680.txt | 11 +++ > 1 file changed, 11 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iio/chemical/bme680.txt > Reviewed-by: Rob Herring
[PATCH] Revert "mm: use early_pfn_to_nid in page_ext_init"
This reverts commit fe53ca54270a757f0a28ee6bf3a54d952b550ed0.
When booting a system with "page_owner=on",
start_kernel
page_ext_init
invoke_init_callbacks
init_section_page_ext
init_page_owner
init_early_allocated_pages
init_zones_in_node
init_pages_in_zone
lookup_page_ext
page_to_nid
The issue here is that page_to_nid() will not work since some page
flags have no node information until later in page_alloc_init_late() due
to DEFERRED_STRUCT_PAGE_INIT. Hence, it could trigger an out-of-bounds
access with an invalid nid.
[8.666047] UBSAN: Undefined behaviour in ./include/linux/mm.h:1104:50
[8.672603] index 7 is out of range for type 'zone [5]'
Also, kernel will panic since flags were poisoned earlier with,
CONFIG_DEBUG_VM_PGFLAGS=y
CONFIG_NODE_NOT_IN_PAGE_FLAGS=n
start_kernel
setup_arch
pagetable_init
paging_init
sparse_init
sparse_init_nid
memblock_alloc_try_nid_raw
It did not handle it well in init_pages_in_zone() which ends up calling
page_to_nid().
page:ea000420 is uninitialized and poisoned
raw:
raw:
page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
page_owner info is not active (free page?)
kernel BUG at include/linux/mm.h:990!
RIP: 0010:init_page_owner+0x486/0x520
This means that assumptions behind commit fe53ca54270a ("mm: use
early_pfn_to_nid in page_ext_init") are incomplete. Therefore, revert
the commit for now. A proper way to move the page_owner initialization
to sooner is to hook into memmap initialization.
Acked-by: Michal Hocko
Signed-off-by: Qian Cai
---
init/main.c | 3 ++-
mm/page_ext.c | 4 +---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/init/main.c b/init/main.c
index e2e80ca3165a..c86a1c8f19f4 100644
--- a/init/main.c
+++ b/init/main.c
@@ -695,7 +695,6 @@ asmlinkage __visible void __init start_kernel(void)
initrd_start = 0;
}
#endif
- page_ext_init();
kmemleak_init();
setup_per_cpu_pageset();
numa_policy_init();
@@ -1131,6 +1130,8 @@ static noinline void __init kernel_init_freeable(void)
sched_init_smp();
page_alloc_init_late();
+ /* Initialize page ext after all struct pages are initialized. */
+ page_ext_init();
do_basic_setup();
diff --git a/mm/page_ext.c b/mm/page_ext.c
index ae44f7adbe07..8c78b8d45117 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -398,10 +398,8 @@ void __init page_ext_init(void)
* We know some arch can have a nodes layout such as
* -pfn-->
* N0 | N1 | N2 | N0 | N1 | N2|
-*
-* Take into account DEFERRED_STRUCT_PAGE_INIT.
*/
- if (early_pfn_to_nid(pfn) != nid)
+ if (pfn_to_nid(pfn) != nid)
continue;
if (init_section_page_ext(pfn, nid))
goto oom;
--
2.17.2 (Apple Git-113)
Re: [PATCH V2 2/2] Input: rotaty-encoder - Add DT binding document
On Mon, Jan 14, 2019 at 07:52:21PM -0800, Dmitry Torokhov wrote: > On Tue, Jan 08, 2019 at 01:42:49AM +0900, Donghoon Han wrote: > > Add DT binding document for rotary-encoder, keycode options. > > > > Signed-off-by: Donghoon Han > > Cc: Dmitry Torokhov > > Cc: Daniel Mack > > Cc: devicet...@vger.kernel.org > > To: linux-in...@vger.kernel.org > > --- > > .../devicetree/bindings/input/rotary-encoder.txt | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt > > b/Documentation/devicetree/bindings/input/rotary-encoder.txt > > index f99fe5cdeaec..9986ec2af2d4 100644 > > --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt > > +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt > > @@ -12,6 +12,10 @@ Optional properties: > > - rotary-encoder,relative-axis: register a relative axis rather than an > >absolute one. Relative axis will only generate +1/-1 events on the input > >device, hence no steps need to be passed. > > +- rotary-encoder,relative-keys : generate pair of key events. This setting > > + behaves just like relative-axis, generating key events instead. > > + (Keycodes[2] corresponds to -1/1 events.) > > +- rotary-encoder,relative-keycodes : keycodes for relative-keys > > Given that keycodes are linux-specific, I think the property should be > linux,keycodes. Also, I am not sure we need separate > rotary-encoder,relative-keys property as we can infer that we want to > generate keys from presence of linux,keycodes property. > > Rob, any comments? Yes, I had similar thoughts.
linux-next: Fixes tag needs work in the usb-gadget tree
[I am experimenting with checking the Fixes tags in commits in linux-next.
Please let me know if you think I am being too strict.]
Hi Felipe,
Commit
4a995e3496de ("usb: dwc2: gadget: Fix Remote Wakeup interrupt bit clearing
Malformed Fixes tag")
has a malformed Fixes tag:
Fixes: 187c5298a122 ("usb: dwc2: gadget: Add handler for WkupAlert
interrupt")
It should not be split across to lines.
--
Cheers,
Stephen Rothwell
pgp1JjFyXf0cY.pgp
Description: OpenPGP digital signature
Re: [RFC v2 1/6] dt-bindings: Add a binding for Mediatek SCP
On Tue, Jan 08, 2019 at 01:26:01PM +0800, Pi-Hsun Shih wrote: > From: Erin Lo > > Add a DT binding documentation of SCP for the > MT8183 SoC from Mediatek. > > Signed-off-by: Erin Lo > --- > Changes from v1: > - no change No answer to my question on v1? > --- > .../devicetree/bindings/remoteproc/mtk,scp.txt | 10 ++ > 1 file changed, 10 insertions(+) > create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt > new file mode 100644 > index 00..b07e5c4ca9af1d > --- /dev/null > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt > @@ -0,0 +1,10 @@ > +Mediatek SCP Bindings > + > + > +This binding provides support for ARM Cortex M4 Co-processor found on some > +Mediatek SoCs. > + > +Required properties: > +- compatible Should be "mediatek,mt8183-scp" > +- clocks Clock for co-processor (See: > ../clock/clock-bindings.txt) > + > -- > 2.20.1.97.g81188d93c3-goog >
Re: [PATCH 2/8] libertas: change snprintf to scnprintf for possible overflow
On Tue, Jan 15, 2019 at 07:55:36AM +0200, Kalle Valo wrote: > Willy Tarreau writes: > > > From: Silvio Cesare > > > > Change snprintf to scnprintf. There are generally two cases where using > > snprintf causes problems. > > > > 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...) > > In this case, if snprintf would have written more characters than what the > > buffer size (SIZE) is, then size will end up larger than SIZE. In later > > uses of snprintf, SIZE - size will result in a negative number, leading > > to problems. Note that size might already be too large by using > > size = snprintf before the code reaches a case of size += snprintf. > > > > 2) If size is ultimately used as a length parameter for a copy back to user > > space, then it will potentially allow for a buffer overflow and information > > disclosure when size is greater than SIZE. When the size is used to index > > the buffer directly, we can have memory corruption. This also means when > > size = snprintf... is used, it may also cause problems since size may become > > large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel > > configuration. > > > > The solution to these issues is to use scnprintf which returns the number of > > characters actually written to the buffer, so the size variable will never > > exceed SIZE. > > > > Signed-off-by: Silvio Cesare > > Cc: Kalle Valo > > Cc: Dan Carpenter > > Cc: Kees Cook > > Cc: Will Deacon > > Cc: Greg KH > > Signed-off-by: Willy Tarreau > > I don't see any mention about which tree this should go to. Can I take > this to wireless-drivers-next? Possibly. It addresses a small memory disclosure issue when using debugfs, and as such it should probably also be submitted to stable branches, so please use the most suitable tree that doesn't add too much extra delay. Thanks, Willy
Re: [PATCH v2 2/2] docs-rst: userspace: update verbs API details
Jonathan Corbet wrote on 01/15/2019 08:08:54 PM: > From: Jonathan Corbet > To: "Joel Nider" > Cc: Matthew Wilcox , Doug Ledford , > Jason Gunthorpe , Leon Romanovsky , linux- > d...@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport > Date: 01/15/2019 08:09 PM > Subject: Re: [PATCH v2 2/2] docs-rst: userspace: update verbs API details > > On Tue, 15 Jan 2019 18:29:59 +0200 > "Joel Nider" wrote: > > > > I think this is a horrible direction to take. The current document is > > > clearly for _users_. All this documentation you've added is for kernel > > > hackers. It needs to go in a different file, or not be added at all. > > > > > Hmm, that's a bit heavy-handed in my opinion. If you look at what is > > currently under "Userspace API", there are a total of 4 files - not > > exactly what I would call comprehensive documentation of the Linux kernel > > interface. > > One has to start somewhere - I'm glad to see you adding to it. > > > So the option of not adding more documentation simply because > > it is in the wrong section seems a bit defeatist (I think we can all agree > > more kernel docs is a good thing). So let's assume for the moment that it > > _should_ be added, and that we are discussing _where_. > > I think we definitely want to add it. > > > Yes, the document I > > am modifying has a bit of a mash of pure userspace API - functions and > > details that application developers must know - and the lower level > > details that are more useful for someone who wishes to extend this > > interface. The existing documentation (specifically unshare) also suffers > > from the same problem. There is a section (7) called "Low Level Design" > > which documents very much the same level of detail as the Infiniband doc, > > so this seems to be at least consistent. > > I think there is a deeper issue - as an application developer, I would > > only look at this kernel documentation as a last resort. #1 is the 'man' > > pages, #2 is web search for an example (I know for many it's the other way > > around). So who really looks at this documentation? I say the vast > > majority is kernel hackers. So yes, this is about the user-facing API, but > > not from the application writer's perspective - it should be about how to > > create a consistent API for users, from the kernel hacker's perspective. > > The intent behind the user-space API manual is to document the user-space > API; it's meant to be read by people writing applications and such. > Perhaps they find it with a web search, but it will be there for them, one > hopes, when they want it. So is the intent then to duplicate what is already in 'man'? Why would we want 2 different locations for basically the same information? Wouldn't it make more sense to just put these few details into appropriate 'man' pages? > The project of reworking the kernel documentation to be more comprehensive > and more focused on its readers, rather than, as Rob Landley once put it, > "a gigantic mess, currently organized based on where random passers-by put > things down last" is still in an early stage. But that doesn't mean that > we shouldn't try to always move in the right direction. It looks like I misunderstood the purpose of the "userspace API" section then. So is there a section that is meant for a guide on how to write an interface function? > So I agree with > Willy that this particular text is better suited to the driver-API > manual. Even if a bare bit of information on its own there for now, it's > a starting place. Can I ask you to do that, please? OK, just to be clear - you are asking me to leave the original file as-is (well, after .rst conversion) but move it to the new location (Documentation/userspace-api), and put my new content into a new file in the old location (Documentation/infiniband)? > Thanks, > > jon >
Re: [PATCH v2 0/2] acpi/nfit: Fix command-supported detection
Dan Williams writes:
> On Tue, Jan 15, 2019 at 6:16 AM Jeff Moyer wrote:
>>
>> Dan Williams writes:
>>
>> > Changes since v1 [1]:
>> > * Include another patch make sure that function-number zero can be
>> > safely used as an invalid function number (Jeff)
>> > * Add a comment clarifying why zero is an invalid function number (Jeff)
>> > * Pass nfit_mem to cmd_to_func() (Jeff)
>> > * Collect a Tested-by from Sujith
>> > [1]: https://lists.01.org/pipermail/linux-nvdimm/2019-January/019435.html
>>
>> For the series:
>>
>> Reviewed-by: Jeff Moyer
>>
>> Thanks, Dan!
>
> Thanks, although I just realized one more change. The ND_CMD_CALL case
> should zero out command after the function translation, otherwise
> userspace can call functions that the kernel is blocking in the
> dsm_mask.
>
> Holler if this invalidates your "Reviewed-by".
AAAHH
:)
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index 87e02f281e51..d7747aceb7ab 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -463,6 +463,12 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor
> *nd_desc, struct nvdimm *nvdimm,
> func = cmd_to_func(nfit_mem, cmd, buf);
> if (func < 0)
> return func;
> + /*
> +* In the ND_CMD_CALL case we're now dependent on 'func'
> +* being validated by the dimm's dsm_mask
> +*/
> + if (cmd == ND_CMD_CALL)
> + cmd = 0;
> dimm_name = nvdimm_name(nvdimm);
> cmd_name = nvdimm_cmd_name(cmd);
> cmd_mask = nvdimm_cmd_mask(nvdimm);
dsm_mask = nfit_mem->dsm_mask;
desc = nd_cmd_dimm_desc(cmd);
That sure doesn't look right. Now cmd_name and desc will be wrong.
> @@ -477,8 +483,10 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor
> *nd_desc, struct nvdimm *nvdimm,
> cmd_name = nvdimm_bus_cmd_name(cmd);
> cmd_mask = nd_desc->cmd_mask;
> dsm_mask = cmd_mask;
> - if (cmd == ND_CMD_CALL)
> + if (cmd == ND_CMD_CALL) {
> dsm_mask = nd_desc->bus_dsm_mask;
> + cmd = 0;
> + }
> desc = nd_cmd_bus_desc(cmd);
And again here.
We could reorder the zeroing, or you could modify the check for a valid
comand/function. Something like this?
/*
* Check for a valid command. For ND_CMD_CALL, we also
* have to make sure that the DSM function is supported.
*/
if (cmd == ND_CMD_CALL && !test_bit(func, &dsm_mask))
return -ENOTTY;
else if (!test_bit(cmd, &cmd_mask))
return -ENOTTY;
Which way do you think is cleaner?
Cheers,
Jeff
Re: [PATCH v2 4/4] usb: musb: Add support for MediaTek musb controller
Hi Min,
very close, thanks.
Below I tried to explain a further cleanup in musb_clearb/w() and
musb_get/set_toggle() implementation. Please let me know if it is not
clear.
Basically, we don't need musb_default_clearb/w(), just assign the
musb_io function pointers to musb_readb/w().
Then the mtk platform musb_clearb/w() calls musb_readb/w() and
musb_writeb/w() to handle W1C.
On Tue, Jan 15, 2019 at 09:43:46AM +0800, min@mediatek.com wrote:
> From: Min Guo
>
> This adds support for MediaTek musb controller in
> host, peripheral and otg mode.
> There are some quirk of MediaTek musb controller, such as:
> -W1C interrupt status registers
> -Private data toggle registers
> -No dedicated DMA interrupt line
>
> Signed-off-by: Min Guo
> Signed-off-by: Yonglong Wu
> ---
> drivers/usb/musb/Kconfig | 8 +-
> drivers/usb/musb/Makefile| 1 +
> drivers/usb/musb/mediatek.c | 617
> +++
> drivers/usb/musb/musb_core.c | 69 +
> drivers/usb/musb/musb_core.h | 9 +
> drivers/usb/musb/musb_dma.h | 9 +
> drivers/usb/musb/musb_host.c | 26 +-
> drivers/usb/musb/musb_io.h | 6 +
> drivers/usb/musb/musbhsdma.c | 55 ++--
> 9 files changed, 762 insertions(+), 38 deletions(-)
> create mode 100644 drivers/usb/musb/mediatek.c
>
> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
> index ad08895..b72b7c1 100644
> --- a/drivers/usb/musb/Kconfig
> +++ b/drivers/usb/musb/Kconfig
> @@ -115,6 +115,12 @@ config USB_MUSB_JZ4740
> depends on USB_MUSB_GADGET
> depends on USB_OTG_BLACKLIST_HUB
>
> +config USB_MUSB_MEDIATEK
> + tristate "MediaTek platforms"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + depends on NOP_USB_XCEIV
> + depends on GENERIC_PHY
> +
> config USB_MUSB_AM335X_CHILD
> tristate
>
> @@ -141,7 +147,7 @@ config USB_UX500_DMA
>
> config USB_INVENTRA_DMA
> bool 'Inventra'
> - depends on USB_MUSB_OMAP2PLUS
> + depends on USB_MUSB_OMAP2PLUS || USB_MUSB_MEDIATEK
> help
> Enable DMA transfers using Mentor's engine.
>
> diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
> index 3a88c79..63d82d0 100644
> --- a/drivers/usb/musb/Makefile
> +++ b/drivers/usb/musb/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX)+=
> da8xx.o
> obj-$(CONFIG_USB_MUSB_UX500) += ux500.o
> obj-$(CONFIG_USB_MUSB_JZ4740)+= jz4740.o
> obj-$(CONFIG_USB_MUSB_SUNXI) += sunxi.o
> +obj-$(CONFIG_USB_MUSB_MEDIATEK) += mediatek.o
>
>
> obj-$(CONFIG_USB_MUSB_AM335X_CHILD) += musb_am335x.o
> diff --git a/drivers/usb/musb/mediatek.c b/drivers/usb/musb/mediatek.c
> new file mode 100644
> index 000..7221989
> --- /dev/null
> +++ b/drivers/usb/musb/mediatek.c
> @@ -0,0 +1,617 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 MediaTek Inc.
> + *
> + * Author:
> + * Min Guo
> + * Yonglong Wu
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "musb_core.h"
> +#include "musb_dma.h"
> +
> +#define USB_L1INTS 0x00a0
> +#define USB_L1INTM 0x00a4
> +#define MTK_MUSB_TXFUNCADDR 0x0480
> +
> +/* MediaTek controller toggle enable and status reg */
> +#define MUSB_RXTOG 0x80
> +#define MUSB_RXTOGEN 0x82
> +#define MUSB_TXTOG 0x84
> +#define MUSB_TXTOGEN 0x86
> +
> +#define TX_INT_STATUSBIT(0)
> +#define RX_INT_STATUSBIT(1)
> +#define USBCOM_INT_STATUSBIT(2)
missing a TAB for the alignment?
> +#define DMA_INT_STATUS BIT(3)
> +
> +#define DMA_INTR_STATUS_MSK GENMASK(7, 0)
> +#define DMA_INTR_UNMASK_SET_MSK GENMASK(31, 24)
> +
> +enum mtk_vbus_id_state {
> + MTK_ID_FLOAT = 1,
> + MTK_ID_GROUND,
> + MTK_VBUS_OFF,
> + MTK_VBUS_VALID,
> +};
> +
> +struct mtk_glue {
> + struct device *dev;
> + struct musb *musb;
> + struct platform_device *musb_pdev;
> + struct platform_device *usb_phy;
> + struct phy *phy;
> + struct usb_phy *xceiv;
> + enum phy_mode phy_mode;
> + struct clk *main;
> + struct clk *mcu;
> + struct clk *univpll;
> + struct regulator *vbus;
> + struct extcon_dev *edev;
> + struct notifier_block vbus_nb;
> + struct notifier_block id_nb;
> +};
> +
> +static int mtk_musb_clks_get(struct mtk_glue *glue)
> +{
> + struct device *dev = glue->dev;
> +
> + glue->main = devm_clk_get(dev, "main");
> + if (IS_ERR(glue->main)) {
> + dev_err(dev, "fail to get main clock\n");
> + return PTR_ERR(glue->main);
> + }
> +
> + glue->mcu = devm_clk_get(dev, "mcu");
> + if (IS_ERR(glue->mcu)) {
> + dev_err(dev, "fail to get mcu clock\n");
> + return PTR_ERR(glue->mcu);
> + }
> +
> + glue->univpll = devm_clk_get(dev, "univpll");
> + if (IS_ERR(glue->univpll)) {
> +
Re: [PATCH v2 3/4] usb: musb: Extract set toggle as a separate interface
Hi Min,
On Tue, Jan 15, 2019 at 04:19:42PM +0100, Matthias Brugger wrote:
>
>
> On 15/01/2019 02:43, min@mediatek.com wrote:
> > From: Min Guo
> >
> > Add a common interface for set data toggle
> >
> > Signed-off-by: Min Guo
> > ---
> > drivers/usb/musb/musb_host.c | 37 +++--
> > 1 file changed, 23 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> > index b59ce9a..16d0ba4 100644
> > --- a/drivers/usb/musb/musb_host.c
> > +++ b/drivers/usb/musb/musb_host.c
> > @@ -306,6 +306,25 @@ static inline void musb_save_toggle(struct musb_qh
> > *qh, int is_in,
> > usb_settoggle(urb->dev, qh->epnum, !is_in, csr ? 1 : 0);
> > }
> >
> > +static inline u16 musb_set_toggle(struct musb_qh *qh, int is_in,
> > + struct urb *urb)
> > +{
> > + u16 csr = 0;
> > + u16 toggle = 0;
> > +
> > + toggle = usb_gettoggle(urb->dev, qh->epnum, !is_in);
> > +
> > + if (is_in)
> > + csr = toggle ? (MUSB_RXCSR_H_WR_DATATOGGLE
> > + | MUSB_RXCSR_H_DATATOGGLE) : 0;
> > + else
> > + csr = toggle ? (MUSB_TXCSR_H_WR_DATATOGGLE
> > + | MUSB_TXCSR_H_DATATOGGLE)
> > + : MUSB_TXCSR_CLRDATATOG;
>
> Can we switch the if and use is_out logic as function parameter. This would
> make
> the code easier to understand.
based on the current implementation in patch 4/4, I don't think we need
this separate patch any more, but Matthias' comments still apply.
Regards,
-Bin.
Re: [PATCH v2 1/2] docs-rst: Convert user verbs doc to rst
Jonathan Corbet wrote on 01/15/2019 08:02:18 PM: > From: Jonathan Corbet > To: Jason Gunthorpe > Cc: Joel Nider , Leon Romanovsky , Doug > Ledford , Mike Rapoport , linux- > d...@vger.kernel.org, linux-kernel@vger.kernel.org > Date: 01/15/2019 08:14 PM > Subject: Re: [PATCH v2 1/2] docs-rst: Convert user verbs doc to rst > > On Tue, 15 Jan 2019 08:14:02 -0700 > Jason Gunthorpe wrote: > > > > Move user_verbs from infiniband to userspace while changing the > > > format. Replace the existing Documentation/infiniband/user_verbs.txt > > > with Documentation/userspace-api/user_verbs.rst. No substantial changes > > > to the content - just some minor reformatting to have the rendering > > > come out nicely. > > > > > > Since this documents a userspace API, its home should be with the > > > other userspace API docs. > > > > > > This is in preparation for updating the content in a subsequent > > > patch. > > > > > > Signed-off-by: Joel Nider > > > --- > > > Documentation/infiniband/user_verbs.txt| 69 - > > > Documentation/userspace-api/index.rst | 1 + > > > Documentation/userspace-api/user_verbs.rst | 70 ++ > > > 3 files changed, 71 insertions(+), 69 deletions(-) > > > delete mode 100644 Documentation/infiniband/user_verbs.txt > > > create mode 100644 Documentation/userspace-api/user_verbs.rst > > > > Need to update MAINTAINERS for the new file.. Maybe call this > > rdma_user_verbs.rst as we could also have rdma_umad, rdma_cm, etc > > Both of those suggestions make sense. Joel, can you do a quick respin > along those lines? Then I think this one is ready. Yes, if I understood your other message correctly (I'll wait to see your response on the other thread), I can make these two changes. > Thanks, > > jon >
Re: [PATCH v3 0/5] kvm "virtio pmem" device
On Tue, Jan 15, 2019 at 12:35:06AM -0500, Pankaj Gupta wrote: > > > > > On Mon, Jan 14, 2019 at 02:15:40AM -0500, Pankaj Gupta wrote: > > > > > > > > > > > > Until you have images (and hence host page cache) shared between > > > > > > > multiple guests. People will want to do this, because it means > > > > > > > they > > > > > > > only need a single set of pages in host memory for executable > > > > > > > binaries rather than a set of pages per guest. Then you have > > > > > > > multiple guests being able to detect residency of the same set of > > > > > > > pages. If the guests can then, in any way, control eviction of the > > > > > > > pages from the host cache, then we have a guest-to-guest > > > > > > > information > > > > > > > leak channel. > > > > > > > > > > > > I don't think we should ever be considering something that would > > > > > > allow a > > > > > > guest to evict page's from the host's pagecache [1]. The guest > > > > > > should > > > > > > be able to kick its own references to the host's pagecache out of > > > > > > its > > > > > > own pagecache, but not be able to influence whether the host or > > > > > > another > > > > > > guest has a read-only mapping cached. > > > > > > > > > > > > [1] Unless the guest is allowed to modify the host's file; obviously > > > > > > truncation, holepunching, etc are going to evict pages from the > > > > > > host's > > > > > > page cache. > > > > > > > > > > This is so correct. Guest does not not evict host page cache pages > > > > > directly. > > > > > > > > They don't right now. > > > > > > > > But someone is going to end up asking for discard to work so that > > > > the guest can free unused space in the underlying spares image (i.e. > > > > make use of fstrim or mount -o discard) because they have workloads > > > > that have bursts of space usage and they need to trim the image > > > > files afterwards to keep their overall space usage under control. > > > > > > > > And then > > > > > > ...we reject / push back on that patch citing the above concern. > > > > So at what point do we draw the line? > > > > We're allowing writable DAX mappings, but as I've pointed out that > > means we are going to be allowing a potential information leak via > > files with shared extents to be directly mapped and written to. > > > > But we won't allow useful admin operations that allow better > > management of host side storage space similar to how normal image > > files are used by guests because it's an information leak vector? > > First of all Thank you for all the useful discussions. > I am summarizing here: > > - We have to live with the limitation to not support fstrim and > mount -o discard options with virtio-pmem as they will evict > host page cache pages. We cannot allow this for virtio-pmem > for security reasons. These filesystem commands will just zero out > unused pages currently. Not sure I follow you here - what pages are going to be zeroed and when will they be zeroed? If discard is not allowed, filesystems just don't issue such commands and the underlying device will never seen them. > - If alot of space is unused and not freed guest can request host > Administrator for truncating the host backing image. You can't use truncate to free space in a disk image file. The only way to do it safely in a generic, filesystem agnositic way is to mount the disk image (e.g. on loopback) and run fstrim on it. The loopback device will punches holes in the file where all the free space is reported by the filesystem via discard requests. Which is kinda my point - this could only be done if the guest is shut down, which makes it very difficult for admins to manage. > We are also planning to support qcow2 sparse image format at > host side with virtio-pmem. So you're going to be remapping a huge number of disjoint regions into a linear pmem mapping? ISTR discussions about similar things for virtio+fuse+dax that came up against "large numbers of mapped regions don't scale" and so it wasn't a practical solution compared to a just using raw sparse files > - There is no existing solution for Qemu persistent memory > emulation with write support currently. This solution provides > us the paravartualized way of emulating persistent memory. Sure, but the question is why do you need to create an emulation that doesn't actually perform like pmem? The whole point of pmem is performance, and emulating pmem by mmap() of a file on spinning disks is going to be horrible for performance. Even on SSDs it's going to be orders of magnitudes slower than real pmem. So exactly what problem are you trying to solve with this driver? Cheers, Dave. -- Dave Chinner da...@fromorbit.com
linux-next: Fixes tag needs work in the amlogic tree
[I am experimenting with checking the Fixes tags in commits in linux-next.
Please let me know if you think I am being too strict.]
Hi all,
Commit
90d2bf8975cc ("ARM64: dts: meson-gxbb-odroidc2: Fix usb phy regulator power
failed warning")
has a malformed Fixes tag:
Fixes: 5a0803bd5ae (ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes)
There should be at least 12 digits of the commit SHA1 and double quotes
around the commit subject.
--
Cheers,
Stephen Rothwell
pgpGOahovCfsC.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/8] lkdtm: change snprintf to scnprintf for possible overflow
On Sat, Jan 12, 2019 at 7:28 AM Willy Tarreau wrote:
>
> From: Silvio Cesare
>
> Change snprintf to scnprintf. There are generally two cases where using
> snprintf causes problems.
>
> 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
> In this case, if snprintf would have written more characters than what the
> buffer size (SIZE) is, then size will end up larger than SIZE. In later
> uses of snprintf, SIZE - size will result in a negative number, leading
> to problems. Note that size might already be too large by using
> size = snprintf before the code reaches a case of size += snprintf.
>
> 2) If size is ultimately used as a length parameter for a copy back to user
> space, then it will potentially allow for a buffer overflow and information
> disclosure when size is greater than SIZE. When the size is used to index
> the buffer directly, we can have memory corruption. This also means when
> size = snprintf... is used, it may also cause problems since size may become
> large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
> configuration.
>
> The solution to these issues is to use scnprintf which returns the number of
> characters actually written to the buffer, so the size variable will never
> exceed SIZE.
>
> Signed-off-by: Silvio Cesare
> Cc: Dan Carpenter
> Cc: Kees Cook
> Cc: Will Deacon
> Cc: Greg KH
> Signed-off-by: Willy Tarreau
It looks like these are going via individual trees. Greg, can you
please take this into your drivers-misc tree for lkdtm?
Acked-by: Kees Cook
Thanks!
-Kees
>
> ---
> drivers/misc/lkdtm/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
> index 2837dc77478e..610aa3bfe630 100644
> --- a/drivers/misc/lkdtm/core.c
> +++ b/drivers/misc/lkdtm/core.c
> @@ -347,9 +347,9 @@ static ssize_t lkdtm_debugfs_read(struct file *f, char
> __user *user_buf,
> if (buf == NULL)
> return -ENOMEM;
>
> - n = snprintf(buf, PAGE_SIZE, "Available crash types:\n");
> + n = scnprintf(buf, PAGE_SIZE, "Available crash types:\n");
> for (i = 0; i < ARRAY_SIZE(crashtypes); i++) {
> - n += snprintf(buf + n, PAGE_SIZE - n, "%s\n",
> + n += scnprintf(buf + n, PAGE_SIZE - n, "%s\n",
> crashtypes[i].name);
> }
> buf[n] = '\0';
> --
> 2.19.2
>
--
Kees Cook
[PATCH V1] i2c: tegra: Add I2C interface timing support
This patch adds I2C interface timing register support and uses
it for clock divisor computation instead of using fixed value.
I2C_INTERFACE_TIMING_0 register contains TLOW and THIGH field
and Tegra I2C controller design uses them as a part of internal
clock divisor. TLOW and THIGH can be tuned for specific platform
to achive accurate bus rates.
Default values of TLOW and THIGH are good for existing tegra
platforms Jetson-TX1, Quill and Xavier AGX.
Signed-off-by: Sowjanya Komatineni
---
drivers/i2c/busses/i2c-tegra.c | 70 ++
1 file changed, 57 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index e417ebf7628c..2e050af6b225 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -118,6 +118,13 @@
#define I2C_MST_FIFO_STATUS_TX_MASK0xff
#define I2C_MST_FIFO_STATUS_TX_SHIFT 16
+#define I2C_INTERFACE_TIMING_0 0x94
+#define I2C_TLOW_MASK 0x3F
+#define I2C_THIGH_SHIFT 8
+#define I2C_THIGH_MASK (0x3F << I2C_THIGH_SHIFT)
+#define I2C_TLOW_NEW_MASK 0xFF
+#define I2C_THIGH_NEW_MASK (0xFF << I2C_THIGH_SHIFT)
+
/*
* msg_end_type: The bus control which need to be send at end of transfer.
* @MSG_END_STOP: Send stop pulse at end of transfer.
@@ -155,6 +162,10 @@ enum msg_end_type {
* @has_mst_fifo: The I2C controller contains the new MST FIFO interface that
* provides additional features and allows for longer messages to
* be transferred in one go.
+ * @interface_timing_enhancement: Interface Timing bit fields increased in
+ * Tegra194 compared to Prior Tegra chips for more tuning to meet
+ * I2C Timing requirements for various data rates.
+
*/
struct tegra_i2c_hw_feature {
bool has_continue_xfer_support;
@@ -167,6 +178,7 @@ struct tegra_i2c_hw_feature {
bool has_multi_master_mode;
bool has_slcg_override_reg;
bool has_mst_fifo;
+ bool interface_timing_enhancement;
};
/**
@@ -515,7 +527,36 @@ static int tegra_i2c_wait_for_config_load(struct
tegra_i2c_dev *i2c_dev)
return 0;
}
-static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
+static int tegra_i2c_set_clk_rate(struct tegra_i2c_dev *i2c_dev)
+{
+ u32 clk_multiplier = I2C_CLK_MULTIPLIER_STD_FAST_MODE;
+ u32 val;
+ u8 low_clk_period, high_clk_period;
+ int ret = 0;
+
+ val = i2c_readl(i2c_dev, I2C_INTERFACE_TIMING_0);
+
+ if (i2c_dev->hw->interface_timing_enhancement) {
+ low_clk_period = val & I2C_TLOW_NEW_MASK;
+ high_clk_period = (val & I2C_THIGH_NEW_MASK) >>
+ I2C_THIGH_SHIFT;
+ } else {
+ low_clk_period = val & I2C_TLOW_MASK;
+ high_clk_period = (val & I2C_THIGH_MASK) >> I2C_THIGH_SHIFT;
+ }
+
+ clk_multiplier = (low_clk_period + high_clk_period + 2);
+ clk_multiplier *= (i2c_dev->clk_divisor_non_hs_mode + 1);
+
+ ret = clk_set_rate(i2c_dev->div_clk,
+ i2c_dev->bus_clk_rate * clk_multiplier);
+ if (ret)
+ dev_err(i2c_dev->dev, "Clock rate change failed %d\n", ret);
+
+ return ret;
+}
+
+static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev, bool is_reinit)
{
u32 val;
int err;
@@ -549,6 +590,12 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
I2C_CLK_DIVISOR_STD_FAST_MODE_SHIFT;
i2c_writel(i2c_dev, clk_divisor, I2C_CLK_DIVISOR);
+ if (!is_reinit) {
+ err = tegra_i2c_set_clk_rate(i2c_dev);
+ if (err < 0)
+ goto err;
+ }
+
if (!i2c_dev->is_dvc) {
u32 sl_cfg = i2c_readl(i2c_dev, I2C_SL_CNFG);
@@ -747,7 +794,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
if (time_left == 0) {
dev_err(i2c_dev->dev, "i2c transfer timed out\n");
- tegra_i2c_init(i2c_dev);
+ tegra_i2c_init(i2c_dev, true);
return -ETIMEDOUT;
}
@@ -758,7 +805,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
if (likely(i2c_dev->msg_err == I2C_ERR_NONE))
return 0;
- tegra_i2c_init(i2c_dev);
+ tegra_i2c_init(i2c_dev, true);
if (i2c_dev->msg_err == I2C_ERR_NO_ACK) {
if (msg->flags & I2C_M_IGNORE_NAK)
return 0;
@@ -848,6 +895,7 @@ static const struct tegra_i2c_hw_feature tegra20_i2c_hw = {
.has_multi_master_mode = false,
.has_slcg_override_reg = false,
.has_mst_fifo = false,
+ .interface_timing_enhancement = false,
};
static const struct tegra_i2c_hw_feature tegra30_i2c_hw = {
@@ -861,6 +
Re: [PATCH V2 1/2] dt-bindings: bcm-ns-usb2-phy: rework binding to use CRU syscon
On Tue, Jan 08, 2019 at 01:39:06PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> USB 2.0 PHY is a hardware block that happens to use two registers from
> the CRU block to setup a single PLL. It's not part of the CRU or DMU
> and so its binding shouldn't cover the whole DMU.
>
> The correct way of handling this is to reference CRU block node using a
> syscon. Document that & deprecate the old way.
>
> Signed-off-by: Rafał Miłecki
> ---
> V2: use syscon@ in example (thanks Ray)
> ---
> .../devicetree/bindings/phy/bcm-ns-usb2-phy.txt| 27
> ++
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> index a7aee9ea8926..2cafee6b4a8b 100644
> --- a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
> @@ -2,19 +2,38 @@ Driver for Broadcom Northstar USB 2.0 PHY
>
> Required properties:
> - compatible: brcm,ns-usb2-phy
> -- reg: iomem address range of DMU (Device Management Unit)
> -- reg-names: "dmu", the only needed & supported reg right now
> +- syscon-cru: phandle to the CRU (Central Resource Unit) syscon
> - clocks: USB PHY reference clock
> - clock-names: "phy-ref-clk", the only needed & supported clock right now
>
> +Deprecated:
> +
> +PHY block should not claim the whole DMU so such a binding has been
> deprecated.
> +It only requires to access few CRU (a DMU subblock) registers and that
> should be
> +handled with a syscon since CRU is a MFD (Multi-Function Device).
> +
> +- reg: iomem address range of DMU (Device Management Unit)
> +- reg-names: "dmu", the only needed & supported reg right now
> +
> To initialize USB 2.0 PHY driver needs to setup PLL correctly. To do this it
> requires passing phandle to the USB PHY reference clock.
>
> Example:
> + dmu@1800c000 {
> + compatible = "simple-bus";
DMU sounds like some sort of block, not just a bus.
> + ranges = <0 0x1800c000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cru: syscon@100 {
> + compatible = "syscon", "simple-mfd";
Those 2 compatibles alone are not valid. And 'simple-mfd' implies child
nodes.
Without any knowledge of what else is in the DMU, I can't give any
advice as to what this should look like instead.
> + reg = <0x100 0x1a4>;
> + };
> + };
> +
> usb2-phy {
> compatible = "brcm,ns-usb2-phy";
> - reg = <0x1800c000 0x1000>;
> - reg-names = "dmu";
> + syscon-cru = <&cru>;
No need for this. Make it a child of cru node.
There's not a contiguous range of phy registers? If there are, keep
'reg' even if Linux doesn't (currently) use it.
> #phy-cells = <0>;
> clocks = <&genpll BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
> clock-names = "phy-ref-clk";
> --
> 2.13.7
>
Re: [PATCH v2 2/4] ASoC: add fsl_audmix DT binding documentation
On Tue, 8 Jan 2019 13:05:47 +, Viorel Suman wrote: > Add the DT binding documentation for NXP Audio Mixer > CPU DAI driver. > > Signed-off-by: Viorel Suman > --- > .../devicetree/bindings/sound/fsl,audmix.txt | 44 > ++ > 1 file changed, 44 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sound/fsl,audmix.txt > Reviewed-by: Rob Herring
Re: [PATCH v6] x86: load FPU registers on return to userland
On 1/15/19 12:26 PM, Andy Lutomirski wrote: > I don't think we'd ever want kernel_fpu_end() to restore anything, > right? I'm a bit confused as to when this optimization would actually > be useful. Using AVX-512 as an example... Let's say there was AVX-512 state, and a kernel_fpu_begin() user only used AVX2. We could totally avoid doing *any* AVX-512 state save/restore. The init optimization doesn't help us if there _is_ AVX-512 state, and the modified optimization only helps if we recently did a XRSTOR at context switch and have not written to AVX-512 state since XRSTOR. This probably only matters for AVX-512-using apps that have run on a kernel with lots of kernel_fpu_begin()s that don't use AVX-512. So, not a big deal right now.
Re: [PATCH 1/1] rtc: add AB-RTCMC-32.768kHz-EOZ9-S3 RTC support
Hello,
Thanks for the patch, a few comments:
On 15/01/2019 14:01:45+0300, Artem Panfilov wrote:
> This patch adds support for AB-RTCMC-32.768kHz-EOZ9-S3
> RTC/Calendar module w/ I2C interface.
>
> Signed-off-by: Artem Panfilov
This has to match the From: header of the email (the dot is the
difference).
> ---
> drivers/rtc/Kconfig | 10 +
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-ab-eoz9-s3.c | 412 +++
I'd remove s3 from the various file and variable names because this is
a package denomination (I know other RTCs have it but this has caused
issue in the past).
> +static int abeoz9s3_rtc_get_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct abeoz9s3_rtc_data *data = dev_get_drvdata(dev);
> + u8 regs[ABEOZ9S3_REG_SECONDS + ABEOZ9S3_SECONDS_LEN];
Why do you add ABEOZ9S3_REG_SECONDS here?
> + int ret;
> +
> + ret = regmap_bulk_read(data->regmap, ABEOZ9S3_REG_SECONDS,
> +regs, sizeof(regs));
> +
> + if (ret) {
> + dev_err(dev, "reading RTC time failed (%d)\n", ret);
> + goto err;
You can return ret directly here instead of using a goto.
> + }
> +
> + tm->tm_sec = bcd2bin(regs[ABEOZ9S3_REG_SECONDS] & 0x7F);
> + tm->tm_min = bcd2bin(regs[ABEOZ9S3_REG_MINUTES] & 0x7F);
> +
> + if (regs[ABEOZ9S3_REG_CTRL1] & ABEOZ9S3_HOURS_PM) {
> + tm->tm_hour = bcd2bin(regs[ABEOZ9S3_REG_HOURS] & 0x1f);
> + if (regs[ABEOZ9S3_REG_HOURS] & ABEOZ9S3_HOURS_PM)
> + tm->tm_hour += 12;
> + } else {
> + tm->tm_hour = bcd2bin(regs[ABEOZ9S3_REG_HOURS]);
> + }
> +
> + tm->tm_mday = bcd2bin(regs[ABEOZ9S3_REG_DAYS]);
> + tm->tm_wday = bcd2bin(regs[ABEOZ9S3_REG_WEEKDAYS]);
> + tm->tm_mon = bcd2bin(regs[ABEOZ9S3_REG_MONTHS]) - 1;
> + tm->tm_year = bcd2bin(regs[ABEOZ9S3_REG_YEARS]) + 100;
> +err:
> + return ret;
> +}
> +
> +static int abeoz9s3_rtc_set_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct abeoz9s3_rtc_data *data = dev_get_drvdata(dev);
> + u8 regs[ABEOZ9S3_REG_SECONDS + ABEOZ9S3_SECONDS_LEN];
ABEOZ9S3_REG_SECONDS is probably not needed here either.
> + int ret;
> +
> + regs[ABEOZ9S3_REG_SECONDS] = bin2bcd(tm->tm_sec);
> + regs[ABEOZ9S3_REG_MINUTES] = bin2bcd(tm->tm_min);
> + regs[ABEOZ9S3_REG_HOURS]= bin2bcd(tm->tm_hour);
> + regs[ABEOZ9S3_REG_DAYS] = bin2bcd(tm->tm_mday);
> + regs[ABEOZ9S3_REG_WEEKDAYS] = bin2bcd(tm->tm_wday);
> + regs[ABEOZ9S3_REG_MONTHS] = bin2bcd(tm->tm_mon + 1);
> + regs[ABEOZ9S3_REG_YEARS]= bin2bcd(tm->tm_year - 100);
> +
> + mutex_lock(&data->lock);
This lock doesn't actually protect anything, it can be removed.
> + ret = regmap_bulk_write(data->regmap, ABEOZ9S3_REG_SECONDS,
> + regs + ABEOZ9S3_REG_SECONDS,
> + ABEOZ9S3_SECONDS_LEN);
> + mutex_unlock(&data->lock);
> +
> + return ret;
> +}
> +
> +static int abeoz9s3_rtc_setup(struct device *dev, struct device_node *node)
> +{
> + struct abeoz9s3_rtc_data *data = dev_get_drvdata(dev);
> + struct regmap *regmap = data->regmap;
> +
> + int ret;
> +
> + /* Enable Self Recovery, Clock for Watch and EEPROM refresh functions*/
> + ret = regmap_update_bits(regmap, ABEOZ9S3_REG_CTRL1,
> + ABEOZ9S3_REG_CTRL1_MASK,
> + ABEOZ9S3_REG_CTRL1_WE |
> + ABEOZ9S3_REG_CTRL1_EERE |
> + ABEOZ9S3_REG_CTRL1_SRON);
You can just use regmap_write here and drop ABEOZ9S3_REG_CTRL1_MASK
> + if (ret < 0) {
> + dev_err(dev, "unable to set control 1 register (%d)\n", ret);
> + return ret;
> + }
> +
> + ret = regmap_update_bits(regmap, ABEOZ9S3_REG_CTRL2,
> + ABEOZ9S3_REG_CTRL2_MASK, 0);
Same here, this just write 0 in ABEOZ9S3_REG_CTRL2 as all the other bits
will read 0.
> + if (ret < 0) {
> + dev_err(dev, "unable to set control 2 register (%d)\n", ret);
> + return ret;
> + }
> +
> + ret = regmap_update_bits(regmap, ABEOZ9S3_REG_CTRL3,
> + ABEOZ9S3_REG_CTRL3_MASK, 0);
Ditto.
> + if (ret < 0) {
> + dev_err(dev, "unable to set control 3 register (%d)\n", ret);
> + return ret;
> + }
> +
> + ret = regmap_update_bits(regmap, ABEOZ9S3_REG_CTRL4,
> + ABEOZ9S3_REG_CTRL4_MASK, 0);
Ditto.
However, this loses valuable information. PON, V2F and V1F are very
important as they may indicate that the time set in the RTC is now
inaccurate. This has to be used in .read_time and reset only in
.set_time.
Also, I would rename CTRL2 to CTRL4 according to the datasheet.
> + if (ret < 0) {
> + dev_err(dev, "unable to set control 4 register (%d)\n", ret);
> + re
linux-next: Fixes tags need some work in the pm tree
[I am experimenting with checking the Fixes tags in commits in linux-next.
Please let me know if you think I am being too strict.]
Hi Rafael,
Commits
62b33d57c534 ("drivers: thermal: int340x_thermal: Make PCI dependency
explicit")
cd793ab22a93 ("x86/intel/lpss: Make PCI dependency explicit")
42ac19e7b81e ("ACPI: EC: Look for ECDT EC after calling acpi_load_tables()")
6c29b81b5695 ("platform/x86: apple-gmux: Make PCI dependency explicit")
34783dc0182a ("platform/x86: intel_pmc: Make PCI dependency explicit")
704658d1d3ae ("platform/x86: intel_ips: make PCI dependency explicit")
5df37f3a1aa9 ("vga-switcheroo: make PCI dependency explicit")
da1df6ee4296 ("ata: pata_acpi: Make PCI dependency explicit")
ce97a22a596b ("ACPI / LPSS: Make PCI dependency explicit")
Have malformed Fixes tags:
There should be double quotes around the commit subject.
--
Cheers,
Stephen Rothwell
pgpz0LmQcVbA5.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 4/4] ASoC: add imx-audmix DT binding documentation
On Tue, Jan 08, 2019 at 01:05:51PM +, Viorel Suman wrote: > Add the DT binding documentation for Audio Mixer > machine driver. > > Signed-off-by: Viorel Suman > --- > .../devicetree/bindings/sound/imx-audmix.txt | 24 > ++ > 1 file changed, 24 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sound/imx-audmix.txt > > diff --git a/Documentation/devicetree/bindings/sound/imx-audmix.txt > b/Documentation/devicetree/bindings/sound/imx-audmix.txt > new file mode 100644 > index 000..6ac1230 > --- /dev/null > +++ b/Documentation/devicetree/bindings/sound/imx-audmix.txt > @@ -0,0 +1,24 @@ > +NXP Audio Mixer (AUDMIX) machine driver. > + > +Required properties: > +=== > + - compatible : Compatible list, contains "fsl,imx-audmix" > + > + - model: Short audio card description. > + > + - dais : Must contain a list of phandles to AUDMIX connected > + DAIs. The current implementation requires two phandles > + to SAI interfaces to be provided, the first SAI in the > + list being used to route the AUDMIX output. > + > + - audmix-controller: Must contain the phandle to the AUDMIX device > node. I don't think you need 2 nodes for this as this one is just a virtual device. Just add the dais property to the audmix node. Rob
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote: > Thomas is correct that the interface you propose here doesn't work at > all for GPUs. > > The kernel driver is not informed of flush/sync, but rather just setups > coherent mappings between system memory and devices. > > In other words you have an array of struct pages and need to map that to > a specific device and so create dma_addresses for the mappings. If you want a coherent mapping you need to use dma_alloc_coherent and dma_mmap_coherent and you are done, that is not the problem. That actually is one of the vmgfx modes, so I don't understand what problem we are trying to solve if you don't actually want a non-coherent mapping. Although last time I had that discussion with Daniel Vetter I was under the impressions that GPUs really wanted non-coherent mappings. But if you want a coherent mapping you can't go to a struct page, because on many systems you can't just map arbitrary memory as uncachable. It might either come from very special limited pools, or might need other magic applied to it so that it is not visible in the normal direct mapping, or at least not access through it.
Re: Regression: spi: core: avoid waking pump thread from spi_sync instead run teardown delayed
> On 15.01.2019, at 20:26, Mark Brown wrote: > >> On Tue, Jan 15, 2019 at 06:39:27PM +0100, ker...@martin.sperl.org wrote: >> >> Is it possible that the specific flash is not using the “normal” >> spi_pump_message, but spi_controller_mem_ops operations? > > Right, that's my best guess at the minute as well. > >> Maybe we are missing the teardown in that driver or something is >> changing flags there. > >> grepping a bit: > >> I see spi_mem_access_start calling spi_flush_queue, which is calling >> pump_message, which - if there is no transfer - will trigger a delayed >> tear-down, while it maybe should not be doing that. > > If nothing else it's inefficient. > >> Maybe spi_mem_access_end needs a call to spi_flush_queue as well? > > Hrm, or needs to schedule the queue at any rate (though this will only > have an impact in the fairly unusual case where there's something > sharing the bus with a flash). > >> Unfortunately this is theoretical work and quite a lot of guesswork >> without an actual device available for testing... > > Indeed. Maybe a bigger change to the reduce the complexity of the state machine would solve that problem and also reduce code complexity... I may find some time over the weekend if no solution has been found until then. The way I would envision it it would have a “state” as a level (0=shutdown, 1=hw enabled, 2=in pump, 3=in transfer, 4=in hw-mode,...) and a complete to allow waking the shutdown thread (and by this avoiding the busy wait loop we have now). This would replace those idling, busy, and running flags. Drawback: it is invasive, but let us see what it really looks like... Martin
linux-next: Fixes tag needs work in the device-mapper tree
[I am experimenting with checking the Fixes tags in commits in linux-next.
Please let me know if you think I am being too strict.]
Hi all,
Commit
fc4d02aa0331 ("dm thin: fix passdown_double_checking_shared_status()")
has a malformed Fixes tag:
Fixes: 00a0ea33b49 ("dm thin: do not queue freed thin mapping for next stage
processing")
It should show at least 12 digits of the SHA1.
--
Cheers,
Stephen Rothwell
pgpL4Shlknfw1.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 1/5] devicetree: property-units: Add femtofarads unit
On Tue, 8 Jan 2019 19:54:10 +0100, Sam Ravnborg wrote: > When dealing with capacitance of 0.5 pF then > a smaller unit is preferred. > Add femtofarads to deal with this. > > Signed-off-by: Sam Ravnborg > Cc: Rob Herring > Cc: Mark Rutland > Cc: Alessandro Zummo > Cc: Alexandre Belloni > --- > Documentation/devicetree/bindings/property-units.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring
Re: [PATCH v2 0/2] acpi/nfit: Fix command-supported detection
On Tue, Jan 15, 2019 at 12:39 PM Jeff Moyer wrote:
>
> Dan Williams writes:
>
> > On Tue, Jan 15, 2019 at 6:16 AM Jeff Moyer wrote:
> >>
> >> Dan Williams writes:
> >>
> >> > Changes since v1 [1]:
> >> > * Include another patch make sure that function-number zero can be
> >> > safely used as an invalid function number (Jeff)
> >> > * Add a comment clarifying why zero is an invalid function number (Jeff)
> >> > * Pass nfit_mem to cmd_to_func() (Jeff)
> >> > * Collect a Tested-by from Sujith
> >> > [1]: https://lists.01.org/pipermail/linux-nvdimm/2019-January/019435.html
> >>
> >> For the series:
> >>
> >> Reviewed-by: Jeff Moyer
> >>
> >> Thanks, Dan!
> >
> > Thanks, although I just realized one more change. The ND_CMD_CALL case
> > should zero out command after the function translation, otherwise
> > userspace can call functions that the kernel is blocking in the
> > dsm_mask.
> >
> > Holler if this invalidates your "Reviewed-by".
>
> AAAHH
>
> :)
>
> > diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> > index 87e02f281e51..d7747aceb7ab 100644
> > --- a/drivers/acpi/nfit/core.c
> > +++ b/drivers/acpi/nfit/core.c
> > @@ -463,6 +463,12 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor
> > *nd_desc, struct nvdimm *nvdimm,
> > func = cmd_to_func(nfit_mem, cmd, buf);
> > if (func < 0)
> > return func;
> > + /*
> > +* In the ND_CMD_CALL case we're now dependent on 'func'
> > +* being validated by the dimm's dsm_mask
> > +*/
> > + if (cmd == ND_CMD_CALL)
> > + cmd = 0;
> > dimm_name = nvdimm_name(nvdimm);
> > cmd_name = nvdimm_cmd_name(cmd);
> > cmd_mask = nvdimm_cmd_mask(nvdimm);
> dsm_mask = nfit_mem->dsm_mask;
> desc = nd_cmd_dimm_desc(cmd);
>
> That sure doesn't look right. Now cmd_name and desc will be wrong.
Ah, whoops, yes good catch. Guess this shows there is not good
ND_CMD_CALL coverage in the unit tests...
>
> > @@ -477,8 +483,10 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor
> > *nd_desc, struct nvdimm *nvdimm,
> > cmd_name = nvdimm_bus_cmd_name(cmd);
> > cmd_mask = nd_desc->cmd_mask;
> > dsm_mask = cmd_mask;
> > - if (cmd == ND_CMD_CALL)
> > + if (cmd == ND_CMD_CALL) {
> > dsm_mask = nd_desc->bus_dsm_mask;
> > + cmd = 0;
> > + }
> > desc = nd_cmd_bus_desc(cmd);
>
> And again here.
>
> We could reorder the zeroing, or you could modify the check for a valid
> comand/function. Something like this?
>
> /*
> * Check for a valid command. For ND_CMD_CALL, we also
> * have to make sure that the DSM function is supported.
> */
> if (cmd == ND_CMD_CALL && !test_bit(func, &dsm_mask))
> return -ENOTTY;
> else if (!test_bit(cmd, &cmd_mask))
> return -ENOTTY;
>
> Which way do you think is cleaner?
Modifying the check looks cleaner. Thanks for hollering!
Re: [RFC v3 17/21] iommu/smmuv3: Report non recoverable faults
Hi Jean,
On 1/11/19 6:46 PM, Jean-Philippe Brucker wrote:
> On 08/01/2019 10:26, Eric Auger wrote:
>> When a stage 1 related fault event is read from the event queue,
>> let's propagate it to potential external fault listeners, ie. users
>> who registered a fault handler.
>>
>> Signed-off-by: Eric Auger
>> ---
>> drivers/iommu/arm-smmu-v3.c | 124
>> 1 file changed, 113 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 999ee470a2ae..6a711cbbb228 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -168,6 +168,26 @@
>> #define ARM_SMMU_PRIQ_IRQ_CFG1 0xd8
>> #define ARM_SMMU_PRIQ_IRQ_CFG2 0xdc
>>
>> +/* Events */
>> +#define ARM_SMMU_EVT_F_UUT 0x01
>> +#define ARM_SMMU_EVT_C_BAD_STREAMID 0x02
>> +#define ARM_SMMU_EVT_F_STE_FETCH0x03
>> +#define ARM_SMMU_EVT_C_BAD_STE 0x04
>> +#define ARM_SMMU_EVT_F_BAD_ATS_TREQ 0x05
>> +#define ARM_SMMU_EVT_F_STREAM_DISABLED 0x06
>> +#define ARM_SMMU_EVT_F_TRANSL_FORBIDDEN 0x07
>> +#define ARM_SMMU_EVT_C_BAD_SUBSTREAMID 0x08
>> +#define ARM_SMMU_EVT_F_CD_FETCH 0x09
>> +#define ARM_SMMU_EVT_C_BAD_CD 0x0a
>> +#define ARM_SMMU_EVT_F_WALK_EABT0x0b
>> +#define ARM_SMMU_EVT_F_TRANSLATION 0x10
>> +#define ARM_SMMU_EVT_F_ADDR_SIZE0x11
>> +#define ARM_SMMU_EVT_F_ACCESS 0x12
>> +#define ARM_SMMU_EVT_F_PERMISSION 0x13
>> +#define ARM_SMMU_EVT_F_TLB_CONFLICT 0x20
>> +#define ARM_SMMU_EVT_F_CFG_CONFLICT 0x21
>> +#define ARM_SMMU_EVT_E_PAGE_REQUEST 0x24
>> +
>> /* Common MSI config fields */
>> #define MSI_CFG0_ADDR_MASK GENMASK_ULL(51, 2)
>> #define MSI_CFG2_SH GENMASK(5, 4)
>> @@ -333,6 +353,11 @@
>> #define EVTQ_MAX_SZ_SHIFT 7
>>
>> #define EVTQ_0_ID GENMASK_ULL(7, 0)
>> +#define EVTQ_0_SUBSTREAMID GENMASK_ULL(31, 12)
>> +#define EVTQ_0_STREAMID GENMASK_ULL(63, 32)
>> +#define EVTQ_1_S2 GENMASK_ULL(39, 39)
>> +#define EVTQ_1_CLASSGENMASK_ULL(40, 41)
>> +#define EVTQ_3_FETCH_ADDR GENMASK_ULL(51, 3)
>>
>> /* PRI queue */
>> #define PRIQ_ENT_DWORDS 2
>> @@ -1270,7 +1295,6 @@ static int arm_smmu_init_l2_strtab(struct
>> arm_smmu_device *smmu, u32 sid)
>> return 0;
>> }
>>
>> -__maybe_unused
>> static struct arm_smmu_master_data *
>> arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid)
>> {
>> @@ -1296,24 +1320,102 @@ arm_smmu_find_master(struct arm_smmu_device *smmu,
>> u32 sid)
>> return master;
>> }
>>
>> +static void arm_smmu_report_event(struct arm_smmu_device *smmu, u64 *evt)
>> +{
>> +u64 fetch_addr = FIELD_GET(EVTQ_3_FETCH_ADDR, evt[3]);
>> +u32 sid = FIELD_GET(EVTQ_0_STREAMID, evt[0]);
>> +bool s1 = !FIELD_GET(EVTQ_1_S2, evt[1]);
>> +u8 type = FIELD_GET(EVTQ_0_ID, evt[0]);
>> +struct arm_smmu_master_data *master;
>> +struct iommu_fault_event event;
>> +bool propagate = true;
>> +u64 addr = evt[2];
>> +int i;
>> +
>> +master = arm_smmu_find_master(smmu, sid);
>> +if (WARN_ON(!master))
>> +return;
>> +
>> +event.fault.type = IOMMU_FAULT_DMA_UNRECOV;
>> +
>> +switch (type) {
>> +case ARM_SMMU_EVT_C_BAD_STREAMID:
>> +event.fault.reason = IOMMU_FAULT_REASON_SOURCEID_INVALID;
>> +break;
>> +case ARM_SMMU_EVT_F_STREAM_DISABLED:
>> +case ARM_SMMU_EVT_C_BAD_SUBSTREAMID:
>> +event.fault.reason = IOMMU_FAULT_REASON_PASID_INVALID;
>> +break;
>> +case ARM_SMMU_EVT_F_CD_FETCH:
>> +event.fault.reason = IOMMU_FAULT_REASON_PASID_FETCH;
>> +break;
>> +case ARM_SMMU_EVT_F_WALK_EABT:
>> +event.fault.reason = IOMMU_FAULT_REASON_WALK_EABT;
>> +event.fault.addr = addr;
>> +event.fault.fetch_addr = fetch_addr;
>> +propagate = s1;
>> +break;
>> +case ARM_SMMU_EVT_F_TRANSLATION:
>> +event.fault.reason = IOMMU_FAULT_REASON_PTE_FETCH;
>> +event.fault.addr = addr;
>> +event.fault.fetch_addr = fetch_addr;
>> +propagate = s1;
>> +break;
>> +case ARM_SMMU_EVT_F_PERMISSION:
>> +event.fault.reason = IOMMU_FAULT_REASON_PERMISSION;
>> +event.fault.addr = addr;
>> +propagate = s1;
>> +break;
>> +case ARM_SMMU_EVT_F_ACCESS:
>> +event.fault.reason = IOMMU_FAULT_REASON_ACCESS;
>> +event.fault.addr = addr;
>> +propagate = s1;
>> +break;
>> +case ARM_SMMU_EVT_C_BAD_STE:
>> +event.fault.reason =
>> IOMMU_FAULT_REASON_BAD_DEVICE_CONTEXT_ENTRY;
>> +break;
>> +case ARM_SMMU_EVT_C_BAD_CD:
>> +event.fault.reason = IOMMU_FAULT_REASON_BAD_PASID_ENTRY;
>> +
Re: [PATCH v2 2/5] dt-binding: pcf8523: add xtal load capacitance
On Tue, 8 Jan 2019 19:54:11 +0100, Sam Ravnborg wrote: > The NXP pcf8523 supports two different xtal load capacitance > - 7000fF (7pF)HW default > - 12500fF (12.5pF) Minimum power consumption, driver default > > To obtain a precise RTC the pcf8523 must be configured > with the correct capacitance load of the xtal. > > Add a property to specify the xtal capacitance load. > The default value matches that of the current Linux driver. > > With a dedicated binding remove the entry in rtc.txt > > Signed-off-by: Søren Andersen > Signed-off-by: Sam Ravnborg > Cc: Alessandro Zummo > Cc: Alexandre Belloni > Cc: Rob Herring > Cc: Mark Rutland > --- > Documentation/devicetree/bindings/rtc/nxp,pcf8523.txt | 18 ++ > Documentation/devicetree/bindings/rtc/rtc.txt | 1 - > 2 files changed, 18 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/rtc/nxp,pcf8523.txt > Reviewed-by: Rob Herring
linux-next: Fixes tag needs work in the xen-tip tree
Hi all,
Commit
786e1048e7f4 ("pvcalls-front: fix potential null dereference")
has a malformed Fixes tag:
Fixes: 9f51c05dc41a ("pvcalls-front: Avoid get_free_pages(GFP_KERNEL)
under spinlock")
It should not be split over 2 lines.
--
Cheers,
Stephen Rothwell
pgpmOizSX5F2y.pgp
Description: OpenPGP digital signature
Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component
On Tue, Jan 15, 2019 at 01:35:07PM -0600, Pierre-Louis Bossart wrote:
> On 1/14/19 6:06 PM, Mark Brown wrote:
> > just pushing the breakage around rather than fixing it. Can someone
> > with an x86 system take a look and confirm exactly what's going on with
> > binding these cards please?
> Beyond the fact that the platform_name seems to be totally useless,
> additional tests show that the patch ('ASoC: soc-core: defer card probe
> until all component is added to list') adds a new restriction which
> contradicts existing error checks.
Yes... I'd been coming to the conclusion that it was a huge red herring
here.
> So if we want to be consistent, the new code should be something like:
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index b680c673c553..2791da9417f8 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -1154,7 +1154,7 @@ static int soc_init_dai_link(struct snd_soc_card
> *card,
> * Defer card registartion if cpu dai component is not added to
> * component list.
> */
> - if (!soc_find_component(link->cpu_of_node, link->cpu_name))
> + if (!link->cpu_dai_name && !soc_find_component(link->cpu_of_node,
> link->cpu_name))
> return -EPROBE_DEFER;
>
> /*
> or try to call soc_find_component with both cpu_name or cpu_dai_name, if
> this makes sense?
I think calling _find_component() makes more sense here as it will do
the check it's actually there thing no matter how the link is
identified. Assuming that does resolve the issue do you want to make a
patch given that you got there first?
signature.asc
Description: PGP signature
Re: [PATCH v2 3/5] dt-binding: pcf85063: add xtal load capacitance
On Tue, Jan 08, 2019 at 07:54:12PM +0100, Sam Ravnborg wrote:
> The NXP pcf85063 supports two different xtal load capacitance
> - 7000fF (7pF)HW default, Linux driver default
> - 12500fF (12.5pF) Minimum power consumption
>
> To obtain a precise RTC the pcf85063 must be configured
> with the correct capacitance load of the xtal.
>
> Add a property to specify the xtal capacitance load.
> The default value matches that of the current Linux driver.
>
> With a dedicated binding remove the entry in rtc.txt
>
> Signed-off-by: Søren Andersen
> Signed-off-by: Sam Ravnborg
> Cc: Alessandro Zummo
> Cc: Alexandre Belloni
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: Urs Fässler
> ---
> Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt | 18
> ++
> Documentation/devicetree/bindings/rtc/rtc.txt | 1 -
> 2 files changed, 18 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt
> b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt
> new file mode 100644
> index ..ad5e8eaa370e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt
> @@ -0,0 +1,18 @@
> +* NXP PCF85063 Real Time Clock
> +
> +Required properties:
> +- compatible: Should contain "nxp,pcf85063".
> +- reg: I2C address for chip.
> +
> +Optional property:
> +- quartz-load-femtofarads: The capacitive load of the quartz(x-tal),
Probably should put this in rtc.txt so it can be shared.
> + expressed in femto Farad (fF). Valid values are 7000 and 12500.
> + Default value (if no value is specified) is 7000fF.
> +
> +Example:
> +
> +pcf85063: pcf85063@51 {
rtc@51
> + compatible = "nxp,pcf85063";
> + reg = <0x51>;
> + quartz-load-femtofarads = <12500>;
> +};
> diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt
> b/Documentation/devicetree/bindings/rtc/rtc.txt
> index e07b15d151ac..efac6dc5b914 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc.txt
> +++ b/Documentation/devicetree/bindings/rtc/rtc.txt
> @@ -52,7 +52,6 @@ microcrystal,rv3029 Real Time Clock Module with I2C-Bus
> nxp,pcf2127 Real-time clock
> nxp,pcf2129 Real-time clock
> nxp,pcf8563 Real-time clock/calendar
> -nxp,pcf85063 Tiny Real-Time Clock
> pericom,pt7c4338 Real-time Clock Module
> ricoh,r2025sdI2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
> ricoh,r2221tlI2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
> --
> 2.12.0
>
Re: Regression in v5.0-rc with regmap-irq level-irq changes
On Tue, Jan 15, 2019 at 11:28:40AM -0800, Tony Lindgren wrote: > Any ideas what's needed? Some triggering mapping data to palmas.c > driver? There should be a fix in -next already waiting for me to send it to Linus, can you check there (a couple actually, in my for-linus branch)? signature.asc Description: PGP signature
Re: linux-next: Fixes tags need some work in the pm tree
On 1/15/2019 3:55 PM, Stephen Rothwell wrote:
[I am experimenting with checking the Fixes tags in commits in linux-next.
Please let me know if you think I am being too strict.]
Hi Rafael,
Commits
62b33d57c534 ("drivers: thermal: int340x_thermal: Make PCI dependency
explicit")
cd793ab22a93 ("x86/intel/lpss: Make PCI dependency explicit")
42ac19e7b81e ("ACPI: EC: Look for ECDT EC after calling acpi_load_tables()")
6c29b81b5695 ("platform/x86: apple-gmux: Make PCI dependency explicit")
34783dc0182a ("platform/x86: intel_pmc: Make PCI dependency explicit")
704658d1d3ae ("platform/x86: intel_ips: make PCI dependency explicit")
5df37f3a1aa9 ("vga-switcheroo: make PCI dependency explicit")
da1df6ee4296 ("ata: pata_acpi: Make PCI dependency explicit")
ce97a22a596b ("ACPI / LPSS: Make PCI dependency explicit")
Have malformed Fixes tags:
There should be double quotes around the commit subject.
Interesting, can you add this to the checkpatch.pl script so that it doesn't
happen again?
Re: [PATCH v6] x86: load FPU registers on return to userland
On Tue, Jan 15, 2019 at 12:54 PM Dave Hansen wrote: > > On 1/15/19 12:26 PM, Andy Lutomirski wrote: > > I don't think we'd ever want kernel_fpu_end() to restore anything, > > right? I'm a bit confused as to when this optimization would actually > > be useful. > > Using AVX-512 as an example... > > Let's say there was AVX-512 state, and a kernel_fpu_begin() user only > used AVX2. We could totally avoid doing *any* AVX-512 state save/restore. > > The init optimization doesn't help us if there _is_ AVX-512 state, and > the modified optimization only helps if we recently did a XRSTOR at > context switch and have not written to AVX-512 state since XRSTOR. > > This probably only matters for AVX-512-using apps that have run on a > kernel with lots of kernel_fpu_begin()s that don't use AVX-512. So, not > a big deal right now. On top of this series, this gets rather awkward, I think -- now we need to be able to keep track of a state in which some of the user registers live in the CPU and some live in memory, and we need to be able to do the partial restore if we go back to user mode like this. We also need to be able to do a partial save if we end up context switching. This seems rather complicated. Last time I measured it (on Skylake IIRC), a full save was only about twice as slow as a save that saved nothing at all, so I think we'd need numbers.
[PATCH net-next] svcrdma: Use struct_size() in kmalloc()
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
instance = kmalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
net/sunrpc/xprtrdma/svc_rdma_rw.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/sunrpc/xprtrdma/svc_rdma_rw.c
b/net/sunrpc/xprtrdma/svc_rdma_rw.c
index dc1951759a8e..cad37c2122ab 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_rw.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_rw.c
@@ -64,8 +64,7 @@ svc_rdma_get_rw_ctxt(struct svcxprt_rdma *rdma, unsigned int
sges)
spin_unlock(&rdma->sc_rw_ctxt_lock);
} else {
spin_unlock(&rdma->sc_rw_ctxt_lock);
- ctxt = kmalloc(sizeof(*ctxt) +
- SG_CHUNK_SIZE * sizeof(struct scatterlist),
+ ctxt = kmalloc(struct_size(ctxt, rw_first_sgl, SG_CHUNK_SIZE),
GFP_KERNEL);
if (!ctxt)
goto out;
--
2.20.1
Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component
On Tue, Jan 15, 2019 at 01:35:07PM -0600, Pierre-Louis Bossart wrote:
>
> On 1/14/19 6:06 PM, Mark Brown wrote:
> > On Fri, Jan 11, 2019 at 03:49:08PM -0600, Pierre-Louis Bossart wrote:
> >
> > > Adding some traces I can see that the the platform name we use doesn't
> > > seem
> > > compatible with your logic. All the Intel boards used a constant platform
> > > name matching the PCI ID, see e.g. [1], which IIRC is used to bind
> > > components. Liam, do you recall in more details if this is really
> > > required?
> > That's telling me that either snd_soc_find_components() isn't finding
> > components in the same way that we do when we bind things which isn't
> > good or we're binding links without having fully matched everything on
> > the link which also isn't good.
> >
> > Without a system that shows the issue I can't 100% confirm but I think
> > it's the former - I'm fairly sure that those machines are relying on the
> > component name being initialized to fmt_single_name() in
> > snd_soc_component_initialize(). That is supposed to wind up using
> > dev_name() (which would be the PCI address for a PCI device) as the
> > basis of the name. What I can't currently see is how exactly that gets
> > bound (or how any of the other links avoid trouble for that matter). We
> > could revert and push this into cards but I would rather be confident
> > that we understand what's going on, I'm not comfortable that we aren't
> > just pushing the breakage around rather than fixing it. Can someone
> > with an x86 system take a look and confirm exactly what's going on with
> > binding these cards please?
>
> Beyond the fact that the platform_name seems to be totally useless,
> additional tests show that the patch ('ASoC: soc-core: defer card probe
> until all component is added to list') adds a new restriction which
> contradicts existing error checks.
>
> None of the Intel machine drivers set the dailink "cpu_name" field but use
> the "cpu_dai_name" field instead. This was perfectly legit as documented by
> the code at the end of soc_init_dai_link()
This should be fixed by the patch
"ASoC: core: Don't defer probe on optional, NULL components" which Mark
already applied to his tree. See
http://mailman.alsa-project.org/pipermail/alsa-devel/2019-January/144323.html
Maybe the defer card probe logic needs to be extended to also check if
dai_link_name had already been registered (either cpu or cpu_dai_name
needs to be set), not 100% sure which problem the defer card probe patch
was trying to solve.
so long,
Hias
>
> /*
> * At least one of CPU DAI name or CPU device name/node must be
> * specified
> */
> if (!link->cpu_dai_name &&
> !(link->cpu_name || link->cpu_of_node)) {
> dev_err(card->dev,
> "ASoC: Neither cpu_dai_name nor cpu_name/of_node are set for
> %s\n",
> link->name);
> return -EINVAL;
> }
>
> The code contributed by Qualcomm only checks for cpu_name, which prevents
> the init from completing.
>
> So if we want to be consistent, the new code should be something like:
>
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index b680c673c553..2791da9417f8 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -1154,7 +1154,7 @@ static int soc_init_dai_link(struct snd_soc_card
> *card,
> * Defer card registartion if cpu dai component is not added to
> * component list.
> */
> - if (!soc_find_component(link->cpu_of_node, link->cpu_name))
> + if (!link->cpu_dai_name && !soc_find_component(link->cpu_of_node,
> link->cpu_name))
> return -EPROBE_DEFER;
>
> /*
>
> or try to call soc_find_component with both cpu_name or cpu_dai_name, if
> this makes sense?
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Re: [PATCH] tracing: Replace kzalloc with kcalloc
On Mon, 14 Jan 2019 22:34:08 -0600 "Gustavo A. R. Silva" wrote: > Replace kzalloc() function with its 2-factor argument form, kcalloc(). > > This patch replaces cases of: > > kzalloc(a * b, gfp) > > with: > kcalloc(a * b, gfp) I think you meant: kcalloc(a, b, gfp) -- Steve > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva > --- > kernel/trace/trace_probe.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c > index 9962cb5da8ac..57f0cbaf9c58 100644 > --- a/kernel/trace/trace_probe.c > +++ b/kernel/trace/trace_probe.c > @@ -429,7 +429,7 @@ static int traceprobe_parse_probe_arg_body(char *arg, > ssize_t *size, >parg->count); > } > > - code = tmp = kzalloc(sizeof(*code) * FETCH_INSN_MAX, GFP_KERNEL); > + code = tmp = kcalloc(FETCH_INSN_MAX, sizeof(*code), GFP_KERNEL); > if (!code) > return -ENOMEM; > code[FETCH_INSN_MAX - 1].op = FETCH_OP_END; > @@ -501,7 +501,7 @@ static int traceprobe_parse_probe_arg_body(char *arg, > ssize_t *size, > code->op = FETCH_OP_END; > > /* Shrink down the code buffer */ > - parg->code = kzalloc(sizeof(*code) * (code - tmp + 1), GFP_KERNEL); > + parg->code = kcalloc(code - tmp + 1, sizeof(*code), GFP_KERNEL); > if (!parg->code) > ret = -ENOMEM; > else
Re: linux-next: Fixes tag needs work in the device-mapper tree
On Tue, Jan 15 2019 at 4:02pm -0500,
Stephen Rothwell wrote:
> [I am experimenting with checking the Fixes tags in commits in linux-next.
> Please let me know if you think I am being too strict.]
>
> Hi all,
>
> Commit
>
> fc4d02aa0331 ("dm thin: fix passdown_double_checking_shared_status()")
>
> has a malformed Fixes tag:
>
> Fixes: 00a0ea33b49 ("dm thin: do not queue freed thin mapping for next
> stage processing")
>
> It should show at least 12 digits of the SHA1.
Fixed, thanks.
Mike
Re: [PATCH] tracing: Replace kzalloc with kcalloc
On 1/15/19 3:12 PM, Steven Rostedt wrote: On Mon, 14 Jan 2019 22:34:08 -0600 "Gustavo A. R. Silva" wrote: Replace kzalloc() function with its 2-factor argument form, kcalloc(). This patch replaces cases of: kzalloc(a * b, gfp) with: kcalloc(a * b, gfp) I think you meant: kcalloc(a, b, gfp) Yep. copy/paste error. :/ Thanks -- Gustavo -- Steve This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva --- kernel/trace/trace_probe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c index 9962cb5da8ac..57f0cbaf9c58 100644 --- a/kernel/trace/trace_probe.c +++ b/kernel/trace/trace_probe.c @@ -429,7 +429,7 @@ static int traceprobe_parse_probe_arg_body(char *arg, ssize_t *size, parg->count); } - code = tmp = kzalloc(sizeof(*code) * FETCH_INSN_MAX, GFP_KERNEL); + code = tmp = kcalloc(FETCH_INSN_MAX, sizeof(*code), GFP_KERNEL); if (!code) return -ENOMEM; code[FETCH_INSN_MAX - 1].op = FETCH_OP_END; @@ -501,7 +501,7 @@ static int traceprobe_parse_probe_arg_body(char *arg, ssize_t *size, code->op = FETCH_OP_END; /* Shrink down the code buffer */ - parg->code = kzalloc(sizeof(*code) * (code - tmp + 1), GFP_KERNEL); + parg->code = kcalloc(code - tmp + 1, sizeof(*code), GFP_KERNEL); if (!parg->code) ret = -ENOMEM; else
