Re: [PATCH v7 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
Hi Liang, Liang Yang wrote on Tue, 11 Dec 2018 09:56:25 +0800: > Hi Miquel, > > On 2018/12/10 22:50, Miquel Raynal wrote: > > Hi Liang, > > > > Liang Yang wrote on Mon, 10 Dec 2018 20:12:39 > > +0800: > > > >> On 2018/12/10 19:38, Boris Brezillon wrote: > >>> On Mon, 10 Dec 2018 19:23:46 +0800 > >>> Liang Yang wrote: > >>>>> + mtd->ecc_stats.failed++; > >> + continue; > >> + } > >> + mtd->ecc_stats.corrected += ECC_ERR_CNT(*info); > >> + bitflips = max_t(u32, bitflips, ECC_ERR_CNT(*info)); > >> + } > > > > Are you sure you handle correctly empty pages with bf? > > >> if scramble is enable, i would say yes here. > when scramble is disabled, i am considering how to use the helper > nand_check_erased_ecc_chunk, but it seems that i can't get the ecc > bytes which is caculated by ecc engine.by the way, nfc dma doesn't send > out the ecc parity bytes. > >>> > >>> Even if the ECC engine is disabled? > >>>>> No. > >> When ECC engine is disabled, it can read the ecc parity bytes ; but there > >> is another problem that i need to consider how code struct looks better > >> when reading error with ecc opened and then try to raw read. > >> Is there a good idea? > > > > When reading with ECC enabled, in case of uncorrectable error you > > must re-read without ECC, then check if the page is empty or not with > > the core helpers (nand_check_erased_*()). > > > > Is this what you meant? > > > yes. when uncorrectable ECC error, i need firstly read out the ECC bytes > without ECC engine and then use the helper nand_check_erased_ecc_chunk to > check if blank page. > Of course, the precondition is without scrambler, or the bland page can be > detected by meson NFC. A suppose you meant "blank page"? If yes, then you don't need the helper to check for only-0xFF pages. If the controller tells you if the page was blank, then just check for that bit. Thanks, Miquèl
[PATCH v2 1/2] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC
AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence QSPI controller but supports Octal IO(x8 data lines) and Double Data Rate(DDR) mode. Add new compatible to support OSPI controller on TI's AM654 SoCs. Signed-off-by: Vignesh R Reviewed-by: Rob Herring --- v2 Collect Reviewed-by's Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index bb2075df9b38..4345c3a6f530 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be one of the following: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". + For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.19.2
[PATCH v2 0/2] cadence-quadspi: Add Octal mode support
This series adds support for OSPI version of Cadence QSPI controller IP. Based on top of [1][2] that add Octal mode support in spi-nor core: [1] https://patchwork.ozlabs.org/patch/1006717/ [2] https://patchwork.ozlabs.org/patch/1006715/ Changes: v2: spi-nor core patches dropped, are now part of Yogesh's series [1] Declare Octal mode capability based on compatible. Vignesh R (2): dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller .../bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 54 ++- 2 files changed, 43 insertions(+), 12 deletions(-) -- 2.19.2
[PATCH v2 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
Cadence OSPI controller IP supports Octal IO (x8 IO lines),
It also has an integrated PHY. IP register layout is very
similar to existing QSPI IP except for additional bits to support Octal
and Octal DDR mode. Therefore, extend current driver to support Octal
mode.
Signed-off-by: Vignesh R
---
v2:
Declare Octal mode capability based on compatible.
drivers/mtd/spi-nor/cadence-quadspi.c | 54 +--
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 04cedd3a2bf6..31ed50f78972 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -93,6 +93,11 @@ struct cqspi_st {
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
+struct cqspi_driver_platdata {
+ u32 hwcaps_mask;
+ u8 quirks;
+};
+
/* Operation timeout value */
#define CQSPI_TIMEOUT_MS 500
#define CQSPI_READ_TIMEOUT_MS 10
@@ -101,6 +106,7 @@ struct cqspi_st {
#define CQSPI_INST_TYPE_SINGLE 0
#define CQSPI_INST_TYPE_DUAL 1
#define CQSPI_INST_TYPE_QUAD 2
+#define CQSPI_INST_TYPE_OCTAL 3
#define CQSPI_DUMMY_CLKS_PER_BYTE 8
#define CQSPI_DUMMY_BYTES_MAX 4
@@ -911,6 +917,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
int read)
case SNOR_PROTO_1_1_4:
f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
break;
+ case SNOR_PROTO_1_1_8:
+ f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
+ break;
default:
return -EINVAL;
}
@@ -1213,21 +1222,19 @@ static void cqspi_request_mmap_dma(struct cqspi_st
*cqspi)
static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
{
- const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ |
- SNOR_HWCAPS_READ_FAST |
- SNOR_HWCAPS_READ_1_1_2 |
- SNOR_HWCAPS_READ_1_1_4 |
- SNOR_HWCAPS_PP,
- };
struct platform_device *pdev = cqspi->pdev;
struct device *dev = >dev;
+ struct cqspi_driver_platdata *ddata;
+ struct spi_nor_hwcaps hwcaps;
struct cqspi_flash_pdata *f_pdata;
struct spi_nor *nor;
struct mtd_info *mtd;
unsigned int cs;
int i, ret;
+ ddata = (struct cqspi_driver_platdata *)of_device_get_match_data(dev);
+ hwcaps.mask = ddata->hwcaps_mask;
+
/* Get flash device data */
for_each_available_child_of_node(dev->of_node, np) {
ret = of_property_read_u32(np, "reg", );
@@ -1310,7 +1317,7 @@ static int cqspi_probe(struct platform_device *pdev)
struct cqspi_st *cqspi;
struct resource *res;
struct resource *res_ahb;
- unsigned long data;
+ struct cqspi_driver_platdata *ddata;
int ret;
int irq;
@@ -1377,8 +1384,8 @@ static int cqspi_probe(struct platform_device *pdev)
}
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
- data = (unsigned long)of_device_get_match_data(dev);
- if (data & CQSPI_NEEDS_WR_DELAY)
+ ddata = (struct cqspi_driver_platdata *)of_device_get_match_data(dev);
+ if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
cqspi->master_ref_clk_hz);
@@ -1460,14 +1467,37 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
#define CQSPI_DEV_PM_OPS NULL
#endif
+#define cqspi_base_hwcaps_mask \
+ (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
+ SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
+ SNOR_HWCAPS_PP)
+
+static const struct cqspi_driver_platdata cdns_qspi = {
+ .hwcaps_mask = cqspi_base_hwcaps_mask,
+};
+
+static const struct cqspi_driver_platdata k2g_qspi = {
+ .hwcaps_mask = cqspi_base_hwcaps_mask,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
+static const struct cqspi_driver_platdata am654_ospi = {
+ .hwcaps_mask = cqspi_base_hwcaps_mask | SNOR_HWCAPS_READ_1_1_8,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
- .data = (void *)0,
+ .data = (void *)_qspi,
},
{
.compatible = "ti,k2g-qspi",
- .data = (void *)CQSPI_NEEDS_WR_DELAY,
+ .data = (void *)_qspi,
+ },
+ {
+ .compatible = "ti,am654-ospi",
+ .data = (void *)_ospi,
},
{ /* end of table */ }
};
--
2.19.2
Re: [PATCH v16 16/16] arm64: kexec_file: add kaslr support
On Tue, Dec 11, 2018 at 02:50:02PM +0900, AKASHI Takahiro wrote:
> On Fri, Nov 30, 2018 at 01:19:44PM +, Will Deacon wrote:
> > On Thu, Nov 15, 2018 at 02:52:55PM +0900, AKASHI Takahiro wrote:
> > > Adding "kaslr-seed" to dtb enables triggering kaslr, or kernel virtual
> > > address randomization, at secondary kernel boot. We always do this as
> > > it will have no harm on kaslr-incapable kernel.
> > >
> > > We don't have any "switch" to turn off this feature directly, but still
> > > can suppress it by passing "nokaslr" as a kernel boot argument.
> > >
> > > Signed-off-by: AKASHI Takahiro
> > > Cc: Catalin Marinas
> > > Cc: Will Deacon
> > > ---
> > > arch/arm64/kernel/machine_kexec_file.c | 46 +-
> > > 1 file changed, 45 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kernel/machine_kexec_file.c
> > > b/arch/arm64/kernel/machine_kexec_file.c
> > > index ab296b98d633..a0a730bd9be6 100644
> > > --- a/arch/arm64/kernel/machine_kexec_file.c
> > > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > > @@ -16,6 +16,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -28,6 +29,7 @@
> > > #define FDT_PSTR_INITRD_STA "linux,initrd-start"
> > > #define FDT_PSTR_INITRD_END "linux,initrd-end"
> > > #define FDT_PSTR_BOOTARGS"bootargs"
> > > +#define FDT_PSTR_KASLR_SEED "kaslr-seed"
> > >
> > > const struct kexec_file_ops * const kexec_file_loaders[] = {
> > > _image_ops,
> > > @@ -46,11 +48,38 @@ int arch_kimage_file_post_load_cleanup(struct kimage
> > > *image)
> > > return kexec_image_post_load_cleanup_default(image);
> > > }
> > >
> > > +/* crng needs to have been initialized for providing kaslr-seed */
> > > +static int random_ready;
> > > +
> > > +static void random_ready_notified(struct random_ready_callback *unused)
> > > +{
> > > + random_ready = 1;
> > > +}
> > > +
> > > +static struct random_ready_callback random_ready_cb = {
> > > + .func = random_ready_notified,
> > > +};
> > > +
> > > +static __init int init_random_ready_cb(void)
> > > +{
> > > + int ret;
> > > +
> > > + ret = add_random_ready_callback(_ready_cb);
> > > + if (ret == -EALREADY)
> > > + random_ready = 1;
> > > + else if (ret)
> > > + pr_warn("failed to add a callback for random_ready\n");
> > > +
> > > + return 0;
> > > +}
> > > +late_initcall(init_random_ready_cb)
> >
> > Why can't we just call crng_ready()?
>
> because crng_ready() is locally defined in drivers/char/random.c.
> Instead, I'd like to use
> wait_for_random_bytes();
> value = get_random_u64();
Correction:
After several tests, I now don't think that calling wait_for_random_bytes()
is a good idea since it can make kexec_file_load() syscall stalled.
So, I would go for
if (rng_is_initialized())
value = get_random_u64();
-Takahiro Akashi
> > > +
> > > static int setup_dtb(struct kimage *image,
> > >unsigned long initrd_load_addr, unsigned long initrd_len,
> > >char *cmdline, void *dtb)
> > > {
> > > int nodeoffset;
> > > + u64 value;
> > > int ret;
> > >
> > > nodeoffset = fdt_path_offset(dtb, "/chosen");
> > > @@ -106,12 +135,27 @@ static int setup_dtb(struct kimage *image,
> > > return -EINVAL;
> > > }
> > >
> > > + /* add kaslr-seed */
> > > + ret = fdt_delprop(dtb, nodeoffset, FDT_PSTR_KASLR_SEED);
> > > + if (ret && (ret != -FDT_ERR_NOTFOUND))
> > > + return -EINVAL;
> > > +
> > > + if (random_ready) {
> > > + get_random_bytes(, sizeof(value));
> >
> > get_random_u64() ?
>
> OK.
>
> > > + ret = fdt_setprop_u64(dtb, nodeoffset, FDT_PSTR_KASLR_SEED,
> > > + value);
> > > + if (ret)
> > > + return (ret == -FDT_ERR_NOSPACE ? -ENOMEM : -EINVAL);
> > > + } else {
> >
> > Wouldn't we be better off preserving the previous seed here, if it was
> > present?
>
> While there's no guarantee that dtb won't be (partially) broken
> on failure, I will let this function return successfully
> by deleting succeeding fdt_delprop().
>
>
> > > + pr_notice("kaslr-seed won't be fed\n");
> >
> > "fed" is probably not the right word here.
>
> => won't be *provided* on kexec?
>
> -Takahiro Akashi
>
> > Will
Re: [PATCH] sched/fair: move capacity_margin definition into #ifdef
Hi Arnd,
On Mon, 10 Dec 2018 at 22:01, Arnd Bergmann wrote:
>
> Marking the variable static showed that it's only used for
> SMP builds, as seen from this warning:
>
> kernel/sched/fair.c:119:21: error: 'capacity_margin' defined but not used
> [-Werror=unused-variable]
> static unsigned int capacity_margin = 1280;
Olof sent a similar patch 2 weeks ago: https://lkml.org/lkml/2018/11/26/115
Vincent
>
> This has apparently been true since the variable has first been
> introduced, but only now started causing a compile time warning.
>
> Fixes: ed8885a14433 ("sched/fair: Make some variables static")
> Fixes: 3273163c6775 ("sched/fair: Let asymmetric CPU configurations balance
> at wake-up")
> Signed-off-by: Arnd Bergmann
> ---
> kernel/sched/fair.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index e30dea59d215..27928809e6ed 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -110,14 +110,6 @@ int __weak arch_asym_cpu_priority(int cpu)
> unsigned int sysctl_sched_cfs_bandwidth_slice = 5000UL;
> #endif
>
> -/*
> - * The margin used when comparing utilization with CPU capacity:
> - * util * margin < capacity * 1024
> - *
> - * (default: ~20%)
> - */
> -static unsigned int capacity_margin= 1280;
> -
> static inline void update_load_add(struct load_weight *lw, unsigned long inc)
> {
> lw->weight += inc;
> @@ -3046,6 +3038,14 @@ static inline void cfs_rq_util_change(struct cfs_rq
> *cfs_rq, int flags)
> }
>
> #ifdef CONFIG_SMP
> +/*
> + * The margin used when comparing utilization with CPU capacity:
> + * util * margin < capacity * 1024
> + *
> + * (default: ~20%)
> + */
> +static unsigned int capacity_margin= 1280;
> +
> #ifdef CONFIG_FAIR_GROUP_SCHED
> /**
> * update_tg_load_avg - update the tg's load avg
> --
> 2.20.0
>
Re: [linux-sunxi] [PATCH 0/8] This is a second edition of a series that implements voltage
On Tue, 11 Dec 2018, Priit Laes wrote: > On Mon, Dec 10, 2018 at 08:42:11PM +0200, Priit Laes wrote: > > ramping for AXP209 DCDC2 and LDO3 regulators and software > > based soft-start for AXP209 LDO3 regulator. > > Ugh.. managed to botch this series. I'll send a fixed one > today. While you're at it, please don't forget to add the version number in the patch subject lines. Each patch should have read "[PATCH v2] <...>" in this submission. > > Both features are needed to work around a PMIC shutdown when > > toggling LDO3 on certain boards with high capacitance on the > > LDO3 output. > > > > Similar features (or workarounds) have been also implemented > > on u-boot side [1]. > > > > Changes since v1: > > - Rebased on top of next and dropped already merged patches. > > - Dropped LDO4 full range devicetree change for Lime2 (prev patch 9) > > in favor of general pin-bank regulator dependency [2]. > > - Fixed paths in devicetree bindings (patch 3) > > - Added note about software based soft-start for LDO3 (patch 5) > > > > [1] https://lists.denx.de/pipermail/u-boot/2018-November/348612.html > > [2] > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-December/618459.html > > > > Olliver Schinagl (8): > > mfd: axp20x: name voltage ramping define properly > > regulator: axp20x: add support for set_ramp_delay for AXP209 > > dt-bindings: mfd: axp20x: add support for regulator-ramp-delay for AXP209 > > regulator: axp20x: add software based soft_start for AXP209 LDO3 > > dt-bindings: mfd: axp20x: Add software based soft_start for AXP209 LDO3 > > regulator: dts: enable soft-start and ramp delay for the OLinuXino Lime2 > > mfd: axp20x: Clean up included headers > > mfd: axp20x: use explicit bit defines > > > > Documentation/devicetree/bindings/mfd/axp20x.txt | 9 +- > > arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 2 +- > > drivers/mfd/axp20x.c | 13 +- > > drivers/regulator/axp20x-regulator.c | 142 +++- > > include/linux/mfd/axp20x.h | 4 +- > > 5 files changed, 161 insertions(+), 9 deletions(-) > > > > base-commit: 14cf8c1d5b90a0cf6a8ba51ef59db8da8c7a2622 -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] scsi: aacraid: change wait_sem to a completion
Looks good, Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 2/2] scsi: aacraid: change event_wait to a completion
Looks good, Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
[PATCH v4 2/2] proc: add AVX-512 usage to /proc/pid/status
AVX-512 components usage could cause core turbo frequency drop. So
it's useful to expose AVX-512 components usage as a heuristic hint
for the user space job scheduler to cluster the AVX-512 using tasks
together.
Example:
$ cat /proc/pid/status | grep AVX512_hint
AVX512_hint: 1
The hint number '0' indicates the task recently didn't use AVX-512
components thus unlikely has frequency drop issue. And the number '1'
indicates the task recently used AVX-512 components thus could cause
core frequency drop. User space tools may want to further check by:
$ perf stat --pid -e core_power.lvl2_turbo_license -- sleep 1
Performance counter stats for process id '3558':
3,251,565,961 core_power.lvl2_turbo_license
1.004031387 seconds time elapsed
Non-zero counter value confirms that the task causes frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 19 +++
fs/proc/array.c | 5 +
2 files changed, 24 insertions(+)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 87a57b7642d3..98baa47c97b0 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1245,3 +1246,21 @@ int copy_user_to_xstate(struct xregs_state *xsave, const
void __user *ubuf)
return 0;
}
+
+/*
+ * Report CPU specific thread state
+ */
+void arch_task_state(struct seq_file *m, struct task_struct *task)
+{
+ /*
+* Check the processor and build option if AVX512 is supported.
+*/
+ if (!cpu_feature_enabled(X86_FEATURE_AVX512F))
+ return;
+ /*
+* Report AVX-512 components usage:
+*/
+ seq_put_decimal_ull(m, "AVX512_hint:\t",
+ task->thread.fpu.avx512_usage ? 1 : 0);
+ seq_putc(m, '\n');
+}
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 0ceb3b6b37e7..dd88c2219f08 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -392,6 +392,10 @@ static inline void task_core_dumping(struct seq_file *m,
struct mm_struct *mm)
seq_putc(m, '\n');
}
+void __weak arch_task_state(struct seq_file *m, struct task_struct *task)
+{
+}
+
int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task)
{
@@ -414,6 +418,7 @@ int proc_pid_status(struct seq_file *m, struct
pid_namespace *ns,
task_cpus_allowed(m, task);
cpuset_task_status_allowed(m, task);
task_context_switch_counts(m, task);
+ arch_task_state(m, task);
return 0;
}
--
2.17.1
[PATCH v4 1/2] x86/fpu: track AVX-512 usage of tasks
User space tools which do automated task placement need information
about AVX-512 usage of tasks, because AVX-512 usage could cause core
turbo frequency drop and impact the running task on the sibling CPU.
The XSAVE hardware structure has bits that indicate when valid state
is present in registers unique to AVX-512 use. Use these bits to
indicate when AVX-512 has been in use and add per-task AVX-512 state
tracking to context switch.
The tracking turns on the usage flag at the next context switch of
the task, but requires 3 consecutive context switches with no usage
to clear it. This decay is required because well-written AVX-512
applications are expected to clear this state when not actively using
AVX-512 registers.
Although this mechanism is imprecise and can theoretically have both
false-positives and false-negatives, it has been measured to be precise
enough to be useful under real-world workloads like tensorflow and linpack.
If higher precision is required, suggest user space tools to use the
PMU-based mechanisms in combination.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 22 ++
arch/x86/include/asm/fpu/types.h| 8
2 files changed, 30 insertions(+)
diff --git a/arch/x86/include/asm/fpu/internal.h
b/arch/x86/include/asm/fpu/internal.h
index a38bf5a1e37a..0da74d63ba14 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -275,6 +275,27 @@ static inline void copy_fxregs_to_kernel(struct fpu *fpu)
: "D" (st), "m" (*st), "a" (lmask), "d" (hmask)\
: "memory")
+#defineAVX512_STATE_DECAY_COUNT3
+/*
+ * This function is called during context switch to update AVX512 state
+ */
+static inline void update_avx512_state(struct fpu *fpu)
+{
+ /*
+* AVX512 state is tracked here because its use is known to slow
+* the max clock speed of the core.
+*
+* However, AVX512-using tasks are expected to clear this state when
+* not actively using these registers. Thus, this tracking mechanism
+* can miss. To ensure that false-negatives do not immediately show
+* up, decay the usage count over time.
+*/
+ if (fpu->state.xsave.header.xfeatures & XFEATURE_MASK_AVX512)
+ fpu->avx512_usage = AVX512_STATE_DECAY_COUNT;
+ else if (fpu->avx512_usage)
+ fpu->avx512_usage--;
+}
+
/*
* This function is called only during boot time when x86 caps are not set
* up and alternative can not be used yet.
@@ -411,6 +432,7 @@ static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
{
if (likely(use_xsave())) {
copy_xregs_to_kernel(>state.xsave);
+ update_avx512_state(fpu);
return 1;
}
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index 202c53918ecf..313b134d3ca3 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -302,6 +302,14 @@ struct fpu {
*/
unsigned char initialized;
+ /*
+* @avx512_usage:
+*
+* Records the usage of AVX512 registers. A value of non-zero is used
+* to indicate whether these AVX512 registers recently had valid state.
+*/
+ unsigned char avx512_usage;
+
/*
* @state:
*
--
2.17.1
[PATCH v3 2/8] perf cs-etm: Avoid stale branch samples when flush packet
At the end of trace buffer handling, function cs_etm__flush() is invoked
to flush any remaining branch stack entries. As a side effect, it also
generates branch sample, because the 'etmq->packet' doesn't contains any
new coming packet but point to one stale packet after packets swapping,
so it wrongly makes synthesize branch samples with stale packet info.
We could review below detailed flow which causes issue:
Packet1: start_addr=0x08b1fbf0 end_addr=0x08b1fbfc
Packet2: start_addr=0x08b1fb5c end_addr=0x08b1fb6c
step 1: cs_etm__sample():
sample: ip=(0x08b1fbfc-4) addr=0x08b1fb5c
step 2: flush packet in cs_etm__run_decoder():
cs_etm__run_decoder()
`-> err = cs_etm__flush(etmq, false);
sample: ip=(0x08b1fb6c-4) addr=0x08b1fbf0
Packet1 and packet2 are two continuous packets, when packet2 is the new
coming packet, cs_etm__sample() generates branch sample for these two
packets and use [packet1::end_addr - 4 => packet2::start_addr] as branch
jump flow, thus we can see the first generated branch sample in step 1.
At the end of cs_etm__sample() it swaps packets so 'etm->prev_packet'=
packet2 and 'etm->packet'=packet1, so far it's okay for branch sample.
If packet2 is the last one packet in trace buffer, even there have no
any new coming packet, cs_etm__run_decoder() invokes cs_etm__flush() to
flush branch stack entries as expected, but it also generates branch
samples by taking 'etm->packet' as a new coming packet, thus the branch
jump flow is as [packet2::end_addr - 4 => packet1::start_addr]; this
is the second sample which is generated in step 2. So actually the
second sample is a stale sample and we should not generate it.
This patch introduces a new function cs_etm__end_block(), at the end of
trace block this function is invoked to only flush branch stack entries
and thus can avoid to generate branch sample for stale packet.
Signed-off-by: Leo Yan
Reviewed-by: Mathieu Poirier
Cc: Mike Leach
Cc: Robert Walker
---
tools/perf/util/cs-etm.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 789707b..ffc4fe5 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1055,6 +1055,39 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
return err;
}
+static int cs_etm__end_block(struct cs_etm_queue *etmq)
+{
+ int err;
+
+ /*
+* It has no new packet coming and 'etmq->packet' contains the stale
+* packet which was set at the previous time with packets swapping;
+* so skip to generate branch sample to avoid stale packet.
+*
+* For this case only flush branch stack and generate a last branch
+* event for the branches left in the circular buffer at the end of
+* the trace.
+*/
+ if (etmq->etm->synth_opts.last_branch &&
+ etmq->prev_packet->sample_type == CS_ETM_RANGE) {
+ /*
+* Use the address of the end of the last reported execution
+* range.
+*/
+ u64 addr = cs_etm__last_executed_instr(etmq->prev_packet);
+
+ err = cs_etm__synth_instruction_sample(
+ etmq, addr,
+ etmq->period_instructions);
+ if (err)
+ return err;
+
+ etmq->period_instructions = 0;
+ }
+
+ return 0;
+}
+
static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
{
struct cs_etm_auxtrace *etm = etmq->etm;
@@ -1137,7 +1170,7 @@ static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
if (err == 0)
/* Flush any remaining branch stack entries */
- err = cs_etm__flush(etmq);
+ err = cs_etm__end_block(etmq);
}
return err;
--
2.7.4
[PATCH v3 7/8] perf cs-etm: Treat EO_TRACE element as trace discontinuity
If decoder outputs EO_TRACE element, it means the end of the trace
buffer; this is a discontinuity and in this case the end of trace data
needs to be saved.
This patch generates CS_ETM_DISCONTINUITY packet for EO_TRACE element
hereby flushing the end of trace data in cs-etm.c.
Signed-off-by: Leo Yan
Reviewed-by: Mathieu Poirier
Cc: Mike Leach
Cc: Robert Walker
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index bee026e..cda6f07 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -409,6 +409,7 @@ static ocsd_datapath_resp_t
cs_etm_decoder__gen_trace_elem_printer(
switch (elem->elem_type) {
case OCSD_GEN_TRC_ELEM_UNKNOWN:
break;
+ case OCSD_GEN_TRC_ELEM_EO_TRACE:
case OCSD_GEN_TRC_ELEM_NO_SYNC:
case OCSD_GEN_TRC_ELEM_TRACE_ON:
resp = cs_etm_decoder__buffer_discontinuity(decoder,
@@ -425,7 +426,6 @@ static ocsd_datapath_resp_t
cs_etm_decoder__gen_trace_elem_printer(
decoder->packet_buffer[decoder->tail].exc_ret = true;
break;
case OCSD_GEN_TRC_ELEM_PE_CONTEXT:
- case OCSD_GEN_TRC_ELEM_EO_TRACE:
case OCSD_GEN_TRC_ELEM_ADDR_NACC:
case OCSD_GEN_TRC_ELEM_TIMESTAMP:
case OCSD_GEN_TRC_ELEM_CYCLE_COUNT:
--
2.7.4
[PATCH v3 4/8] perf cs-etm: Refactor enumeration cs_etm_sample_type
The values in enumeration cs_etm_sample_type are defined with setting
bit N for each packet type, this is not suggested in the usual case.
This patch refactor cs_etm_sample_type by converting from bit shifting
values to continuous numbers.
Signed-off-by: Leo Yan
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Robert Walker
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
index b295dd2..3819a04 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
@@ -23,9 +23,9 @@ struct cs_etm_buffer {
};
enum cs_etm_sample_type {
- CS_ETM_EMPTY = 0,
- CS_ETM_RANGE = 1 << 0,
- CS_ETM_TRACE_ON = 1 << 1,
+ CS_ETM_EMPTY,
+ CS_ETM_RANGE,
+ CS_ETM_TRACE_ON,
};
enum cs_etm_isa {
--
2.7.4
[PATCH v3 0/8] perf cs-etm: Correct packets handling
perf cs-etm module converts decoder elements to packets and then we have
more context crossing packets to generate synthenize samples, finally
perf tool can faciliate samples for statistics and report the results.
This patch series is to address several issues found related with
packets handling and samples generation when worked firstly on branch
sample flags support for Arm CoreSight trace data, so this patch series
is dependency for sample flags setting, will send another dedicated
patch series for sample flags later.
In this patch series, the first two patches are mainly to fix issues in
cs_etm__flush(): patch 0001 corrects packets swapping in cs_etm__flush()
and this can fix the wrong branch sample caused by the missed packets
swapping; patch 0002 is to fix the wrong samples generation with stale
packets at the end of trace block.
Patch 0003 and 0004 are for minor fixing; patch 0003 removes unused field
'cs_etm_decoder::trace_on', this can simplize the switch-case code for all
discontinuity packet generation by using one code block; patch 0004 is to
refactor enumeration cs_etm_sample_type.
Patch 0005 is to rename CS_ETM_TRACE_ON to CS_ETM_DISCONTINUITY, we use
a more general packet type to present trace discontinuity, so it can be
used by TRACE_ON event, and also can be used by NO_SYNC and EO_TRACE
elements.
Patch 0006 is used to support NO_SYNC packet, otherwise the trace
decoding cannot reflect the tracing discontinuity caused by NO_SYNC
packet.
Patch 0007 is used to support EO_TRACE packet, which also introduces
the tracing discontinuity at the end of trace and we should save last
trace data for it.
Patch 0008 is used to generate branch sample for exception packets.
Credit to Mike Leach and Robert Walker who made me clear for underlying
mechanism for NO_SYNC/EO_TRACE elements, Mike also shared the detailed
explanation for why we can treat NO_SYNC and TRACE_ON elements as the
same, so except following Mike & Rob suggestion for trace discontinuity
consolidation, most commit log of patches 0006/0007 also come from
Mike's explanation.
This patch series is applied directly on the acme's perf/core branch [1]
with latest commit aaab25f03e9e ("perf trace: Allow selecting use the
use of the ordered_events code").
With applying the dependency patch, this patch series has been tested
for branch samples dumping with below command on Juno board:
# perf script -F,-time,+ip,+sym,+dso,+addr,+symoff -k vmlinux
Changes from v2:
* Addressed Mathieu's comments and suggestions for minor refactoring
for removing unused field 'cs_etm_decoder::trace_on' and added one
dedicated patch to refactor enumeration cs_etm_sample_type.
* Added Mathieu's 'reviewed' tags; Very appreciate Mathieu's many
suggestion for crossing several patch series.
Changes from v1:
* Synced the consistent code in patch 0001 for condition checking.
* Introduced new function cs_etm__end_block() for flushing packet
at the end of trace block.
* Added new patch 0003 to rename CS_ETM_TRACE_ON to
CS_ETM_DISCONTINUITY.
* Used the same one packet type CS_ETM_DISCONTINUITY for all
trace discontinuity (include support TRACE_ON/EO_TRACE/NO_SYNC
packets).
* Removed tracking exception number patch, which will be added in
sample flag patch series.
Leo Yan (8):
perf cs-etm: Correct packets swapping in cs_etm__flush()
perf cs-etm: Avoid stale branch samples when flush packet
perf cs-etm: Remove unused 'trace_on' in cs_etm_decoder
perf cs-etm: Refactor enumeration cs_etm_sample_type
perf cs-etm: Rename CS_ETM_TRACE_ON to CS_ETM_DISCONTINUITY
perf cs-etm: Treat NO_SYNC element as trace discontinuity
perf cs-etm: Treat EO_TRACE element as trace discontinuity
perf cs-etm: Generate branch sample for exception packet
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 42 +-
tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 10 ++--
tools/perf/util/cs-etm.c| 77 ++---
3 files changed, 100 insertions(+), 29 deletions(-)
--
2.7.4
[PATCH v3 1/8] perf cs-etm: Correct packets swapping in cs_etm__flush()
The structure cs_etm_queue uses 'prev_packet' to point to previous
packet, this can be used to combine with new coming packet to generate
samples.
In function cs_etm__flush() it swaps packets only when the flag
'etm->synth_opts.last_branch' is true, this means that it will not
swap packets if without option '--itrace=il' to generate last branch
entries; thus for this case the 'prev_packet' doesn't point to the
correct previous packet and the stale packet still will be used to
generate sequential sample. Thus if dump trace with 'perf script'
command we can see the incorrect flow with the stale packet's address
info.
This patch corrects packets swapping in cs_etm__flush(); except using
the flag 'etm->synth_opts.last_branch' it also checks the another flag
'etm->sample_branches', if any flag is true then it swaps packets so
can save correct content to 'prev_packet'. Finally this can fix the
wrong program flow dumping issue.
The patch has a minor refactoring to use 'etm->synth_opts.last_branch'
instead of 'etmq->etm->synth_opts.last_branch' for condition checking,
this is consistent with that is done in cs_etm__sample().
Signed-off-by: Leo Yan
Reviewed-by: Mathieu Poirier
Cc: Mike Leach
Cc: Robert Walker
---
tools/perf/util/cs-etm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 23159c33..789707b 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1042,7 +1042,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
}
swap_packet:
- if (etmq->etm->synth_opts.last_branch) {
+ if (etm->sample_branches || etm->synth_opts.last_branch) {
/*
* Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
* the next incoming packet.
--
2.7.4
[PATCH v3 8/8] perf cs-etm: Generate branch sample for exception packet
The exception packet appears as one element with 'elem_type' ==
OCSD_GEN_TRC_ELEM_EXCEPTION or OCSD_GEN_TRC_ELEM_EXCEPTION_RET,
which present for exception entry and exit respectively. The decoder
set packet fields 'packet->exc' and 'packet->exc_ret' to indicate the
exception packets; but exception packets don't have dedicated sample
type and shares the same sample type CS_ETM_RANGE with normal
instruction packets.
As result, the exception packets are taken as normal instruction packets
and this introduces confusion to mix different packet types.
Furthermore, these instruction range packets will be processed for
branch sample only when 'packet->last_instr_taken_branch' is true,
otherwise they will be omitted, this can introduce mess for exception
and exception returning due we don't have complete address range info
for context switching.
To process exception packets properly, this patch introduce two new
sample type: CS_ETM_EXCEPTION and CS_ETM_EXCEPTION_RET; for these two
kind packets, they will be handled by cs_etm__exception(). The func
cs_etm__exception() forces to set previous CS_ETM_RANGE packet flag
'prev_packet->last_instr_taken_branch' to true, this matches well with
the program flow when the exception is trapped from user space to kernel
space, no matter if the most recent flow has branch taken or not; this
is also safe for returning to user space after exception handling.
After exception packets have their own sample type, the packet fields
'packet->exc' and 'packet->exc_ret' aren't needed anymore, so remove
them.
Signed-off-by: Leo Yan
Reviewed-by: Mathieu Poirier
Cc: Mike Leach
Cc: Robert Walker
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 26 +--
tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 4 ++--
tools/perf/util/cs-etm.c| 28 +
3 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index cda6f07..8c15557 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -290,8 +290,6 @@ static void cs_etm_decoder__clear_buffer(struct
cs_etm_decoder *decoder)
decoder->packet_buffer[i].instr_count = 0;
decoder->packet_buffer[i].last_instr_taken_branch = false;
decoder->packet_buffer[i].last_instr_size = 0;
- decoder->packet_buffer[i].exc = false;
- decoder->packet_buffer[i].exc_ret = false;
decoder->packet_buffer[i].cpu = INT_MIN;
}
}
@@ -319,8 +317,6 @@ cs_etm_decoder__buffer_packet(struct cs_etm_decoder
*decoder,
decoder->packet_buffer[et].sample_type = sample_type;
decoder->packet_buffer[et].isa = CS_ETM_ISA_UNKNOWN;
- decoder->packet_buffer[et].exc = false;
- decoder->packet_buffer[et].exc_ret = false;
decoder->packet_buffer[et].cpu = *((int *)inode->priv);
decoder->packet_buffer[et].start_addr = CS_ETM_INVAL_ADDR;
decoder->packet_buffer[et].end_addr = CS_ETM_INVAL_ADDR;
@@ -397,6 +393,22 @@ cs_etm_decoder__buffer_discontinuity(struct cs_etm_decoder
*decoder,
CS_ETM_DISCONTINUITY);
}
+static ocsd_datapath_resp_t
+cs_etm_decoder__buffer_exception(struct cs_etm_decoder *decoder,
+const uint8_t trace_chan_id)
+{
+ return cs_etm_decoder__buffer_packet(decoder, trace_chan_id,
+CS_ETM_EXCEPTION);
+}
+
+static ocsd_datapath_resp_t
+cs_etm_decoder__buffer_exception_ret(struct cs_etm_decoder *decoder,
+const uint8_t trace_chan_id)
+{
+ return cs_etm_decoder__buffer_packet(decoder, trace_chan_id,
+CS_ETM_EXCEPTION_RET);
+}
+
static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
const void *context,
const ocsd_trc_index_t indx __maybe_unused,
@@ -420,10 +432,12 @@ static ocsd_datapath_resp_t
cs_etm_decoder__gen_trace_elem_printer(
trace_chan_id);
break;
case OCSD_GEN_TRC_ELEM_EXCEPTION:
- decoder->packet_buffer[decoder->tail].exc = true;
+ resp = cs_etm_decoder__buffer_exception(decoder,
+ trace_chan_id);
break;
case OCSD_GEN_TRC_ELEM_EXCEPTION_RET:
- decoder->packet_buffer[decoder->tail].exc_ret = true;
+ resp = cs_etm_decoder__buffer_exception_ret(decoder,
+ trace_chan_id);
break;
case OCSD_GEN_TRC_ELEM_PE_CONTEXT:
case OCSD_GEN_TRC_ELEM_ADDR_NACC:
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
[PATCH v3 3/8] perf cs-etm: Remove unused 'trace_on' in cs_etm_decoder
cs_etm_decoder::trace_on is being assigned when TRACE_ON or NO_SYNC
element is coming, but it is never used hence it is redundant and can
be removed.
So let's remove 'trace_on' field from cs_etm_decoder struct.
Suggested-by: Mathieu Poirier
Signed-off-by: Leo Yan
Cc: Mike Leach
Cc: Robert Walker
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 0b4c862..97b39b1 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -36,7 +36,6 @@
struct cs_etm_decoder {
void *data;
void (*packet_printer)(const char *msg);
- bool trace_on;
dcd_tree_handle_t dcd_tree;
cs_etm_mem_cb_type mem_access;
ocsd_datapath_resp_t prev_return;
@@ -411,12 +410,10 @@ static ocsd_datapath_resp_t
cs_etm_decoder__gen_trace_elem_printer(
case OCSD_GEN_TRC_ELEM_UNKNOWN:
break;
case OCSD_GEN_TRC_ELEM_NO_SYNC:
- decoder->trace_on = false;
break;
case OCSD_GEN_TRC_ELEM_TRACE_ON:
resp = cs_etm_decoder__buffer_trace_on(decoder,
trace_chan_id);
- decoder->trace_on = true;
break;
case OCSD_GEN_TRC_ELEM_INSTR_RANGE:
resp = cs_etm_decoder__buffer_range(decoder, elem,
--
2.7.4
[PATCH v3 6/8] perf cs-etm: Treat NO_SYNC element as trace discontinuity
CoreSight tracer driver might insert barrier packet between different buffers, thus the decoder can spot the boundaries based on the barrier packet; the decoder is possible to hit a barrier packet and emit a NO_SYNC element, then the decoder will find a periodic synchronisation point inside that next trace block that starts trace again but does not have the TRACE_ON element as indicator - usually because this block of trace has wrapped the buffer so we have lost the original point that trace was enabled. In upper case, it results in the trace stream only inserts the OCSD_GEN_TRC_ELEM_NO_SYNC element in the middle of tracing stream, but we don't handle NO_SYNC element properly and at the end users miss to see the info for trace discontinuity. Though OCSD_GEN_TRC_ELEM_NO_SYNC is different from CS_ETM_TRACE_ON when output from the decoder, but both of them indicate the trace data is discontinuous; this patch treats OCSD_GEN_TRC_ELEM_NO_SYNC as trace discontinuity and generates CS_ETM_DISCONTINUITY packet for it, so cs-etm can handle discontinuity for this case, finally it saves the last trace data for previous trace block and restart samples for new block. Signed-off-by: Leo Yan Reviewed-by: Mathieu Poirier Cc: Mike Leach Cc: Robert Walker --- tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c index 1039f364..bee026e 100644 --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c @@ -410,7 +410,6 @@ static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer( case OCSD_GEN_TRC_ELEM_UNKNOWN: break; case OCSD_GEN_TRC_ELEM_NO_SYNC: - break; case OCSD_GEN_TRC_ELEM_TRACE_ON: resp = cs_etm_decoder__buffer_discontinuity(decoder, trace_chan_id); -- 2.7.4
[PATCH v3 5/8] perf cs-etm: Rename CS_ETM_TRACE_ON to CS_ETM_DISCONTINUITY
TRACE_ON element is used at the beginning of trace, it also can be
appeared in the middle of trace data to indicate discontinuity; for
example, it's possible to see multiple TRACE_ON elements in the trace
stream if the trace is being limited by address range filtering.
Furthermore, except TRACE_ON element is for discontinuity, NO_SYNC and
EO_TRACE also can be used to indicate discontinuity, though they are
used for different scenarios for trace is interrupted.
This patch is to rename sample type CS_ETM_TRACE_ON to
CS_ETM_DISCONTINUITY, firstly the new name describes more closely the
purpose of the packet; secondly this is a preparation for other output
elements which also cause the trace discontinuity thus they can share
the same one packet type.
Signed-off-by: Leo Yan
Reviewed-by: Mathieu Poirier
Cc: Mike Leach
Cc: Robert Walker
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 10 +-
tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 2 +-
tools/perf/util/cs-etm.c| 12 ++--
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 97b39b1..1039f364 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -390,11 +390,11 @@ cs_etm_decoder__buffer_range(struct cs_etm_decoder
*decoder,
}
static ocsd_datapath_resp_t
-cs_etm_decoder__buffer_trace_on(struct cs_etm_decoder *decoder,
- const uint8_t trace_chan_id)
+cs_etm_decoder__buffer_discontinuity(struct cs_etm_decoder *decoder,
+ const uint8_t trace_chan_id)
{
return cs_etm_decoder__buffer_packet(decoder, trace_chan_id,
-CS_ETM_TRACE_ON);
+CS_ETM_DISCONTINUITY);
}
static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
@@ -412,8 +412,8 @@ static ocsd_datapath_resp_t
cs_etm_decoder__gen_trace_elem_printer(
case OCSD_GEN_TRC_ELEM_NO_SYNC:
break;
case OCSD_GEN_TRC_ELEM_TRACE_ON:
- resp = cs_etm_decoder__buffer_trace_on(decoder,
- trace_chan_id);
+ resp = cs_etm_decoder__buffer_discontinuity(decoder,
+ trace_chan_id);
break;
case OCSD_GEN_TRC_ELEM_INSTR_RANGE:
resp = cs_etm_decoder__buffer_range(decoder, elem,
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
index 3819a04..a272317 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
@@ -25,7 +25,7 @@ struct cs_etm_buffer {
enum cs_etm_sample_type {
CS_ETM_EMPTY,
CS_ETM_RANGE,
- CS_ETM_TRACE_ON,
+ CS_ETM_DISCONTINUITY,
};
enum cs_etm_isa {
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index ffc4fe5..cea3158 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -562,8 +562,8 @@ static inline int cs_etm__t32_instr_size(struct
cs_etm_queue *etmq,
static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
{
- /* Returns 0 for the CS_ETM_TRACE_ON packet */
- if (packet->sample_type == CS_ETM_TRACE_ON)
+ /* Returns 0 for the CS_ETM_DISCONTINUITY packet */
+ if (packet->sample_type == CS_ETM_DISCONTINUITY)
return 0;
return packet->start_addr;
@@ -572,8 +572,8 @@ static inline u64 cs_etm__first_executed_instr(struct
cs_etm_packet *packet)
static inline
u64 cs_etm__last_executed_instr(const struct cs_etm_packet *packet)
{
- /* Returns 0 for the CS_ETM_TRACE_ON packet */
- if (packet->sample_type == CS_ETM_TRACE_ON)
+ /* Returns 0 for the CS_ETM_DISCONTINUITY packet */
+ if (packet->sample_type == CS_ETM_DISCONTINUITY)
return 0;
return packet->end_addr - packet->last_instr_size;
@@ -972,7 +972,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
bool generate_sample = false;
/* Generate sample for tracing on packet */
- if (etmq->prev_packet->sample_type == CS_ETM_TRACE_ON)
+ if (etmq->prev_packet->sample_type == CS_ETM_DISCONTINUITY)
generate_sample = true;
/* Generate sample for branch taken packet */
@@ -1148,7 +1148,7 @@ static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
*/
cs_etm__sample(etmq);
break;
- case CS_ETM_TRACE_ON:
+ case CS_ETM_DISCONTINUITY:
/*
Re: [PATCH] test_rhashtable: remove semaphore usage
Hi,
On Tue, Dec 11, 2018 at 01:45:52PM +0800, Herbert Xu wrote:
> On Mon, Dec 10, 2018 at 10:17:20PM +0100, Arnd Bergmann wrote:
> > This is one of only two files that initialize a semaphore to a negative
> > value. We don't really need the two semaphores here at all, but can do
> > the same thing in more conventional and more effient way, by using a
> > single waitqueue and an atomic thread counter.
> >
> > This gets us a little bit closer to eliminating classic semaphores from
> > the kernel. It also fixes a corner case where we fail to continue after
> > one of the threads fails to start up.
> >
> > An alternative would be to use a split kthread_create()+wake_up_process()
> > and completely eliminate the separate synchronization.
> >
> > Signed-off-by: Arnd Bergmann
> > ---
> > This is part of a longer, untested, series to remove semaphores
> > from the kernel, please review as such before applying.
> > ---
> > lib/test_rhashtable.c | 28
> > 1 file changed, 16 insertions(+), 12 deletions(-)
>
> This was created by Phil Sutter so I am adding him to the cc list.
Thanks, I would have missed it otherwise. Just a minor nit:
> > diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c
> > index 18de5ff1255b..12bdea4f6c20 100644
> > --- a/lib/test_rhashtable.c
> > +++ b/lib/test_rhashtable.c
[...]
> > @@ -635,8 +636,9 @@ static int threadfunc(void *data)
> > int i, step, err = 0, insert_retries = 0;
> > struct thread_data *tdata = data;
> >
> > - up(_sem);
> > - if (down_interruptible(_sem))
> > + if (atomic_dec_and_test(_count))
> > + wake_up(_wait);
> > + if (wait_event_interruptible(startup_wait, atomic_read(_count)
> > == -1))
> > pr_err(" thread[%d]: down_interruptible failed\n", tdata->id);
The error message should probably be adjusted as well. Apart from that:
Acked-by: Phil Sutter
Thanks, Phil
Re: [PATCH] mmc: sdhci-msm: avoid unused function warning
On 10/12/18 10:45 PM, Arnd Bergmann wrote:
> The newly added sdhci_msm_restore_sdr_dll_config() function is only
> called if CONFIG_PM is enabled:
>
> drivers/mmc/host/sdhci-msm.c:1050:12: error:
> 'sdhci_msm_restore_sdr_dll_config' defined but not used
> [-Werror=unused-function]
>
> Better remove the incorrect #ifdef altogether and just use __maybe_unused,
> which is harder to get wrong.
>
> Fixes: ec3349733550 ("mmc: sdhci-msm: Re-initialize DLL if MCLK is gated
> dynamically")
> Signed-off-by: Arnd Bergmann
Acked-by: Adrian Hunter
> ---
> drivers/mmc/host/sdhci-msm.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 5497a71abe07..d6c9ebd8d263 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -1997,8 +1997,7 @@ static int sdhci_msm_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM
> -static int sdhci_msm_runtime_suspend(struct device *dev)
> +static __maybe_unused int sdhci_msm_runtime_suspend(struct device *dev)
> {
> struct sdhci_host *host = dev_get_drvdata(dev);
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> @@ -2010,7 +2009,7 @@ static int sdhci_msm_runtime_suspend(struct device *dev)
> return 0;
> }
>
> -static int sdhci_msm_runtime_resume(struct device *dev)
> +static __maybe_unused int sdhci_msm_runtime_resume(struct device *dev)
> {
> struct sdhci_host *host = dev_get_drvdata(dev);
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> @@ -2030,7 +2029,6 @@ static int sdhci_msm_runtime_resume(struct device *dev)
>
> return 0;
> }
> -#endif
>
> static const struct dev_pm_ops sdhci_msm_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>
Re: [PATCH] crypto/testmgr: fix skcipher test with CONFIG_VMAP_STACK
Le 11/12/2018 à 06:07, Herbert Xu a écrit : On Fri, Dec 07, 2018 at 09:26:15PM +0100, Ard Biesheuvel wrote: On Fri, 7 Dec 2018 at 18:33, Christophe Leroy wrote: [2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837 dma_nommu_map_page+0x44/0xd4 [2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW 4.20.0-rc5-00560-g6bfb52e23a00-dirty #531 [2.384740] NIP: c000c540 LR: c000c584 CTR: [2.389743] REGS: c95abab0 TRAP: 0700 Tainted: GW (4.20.0-rc5-00560-g6bfb52e23a00-dirty) [2.400042] MSR: 00029032 CR: 24042204 XER: [2.406669] [2.406669] GPR00: c02f2244 c95abb60 c6262990 c95abd80 256a 0001 0001 0001 [2.406669] GPR08: 2000 0010 0010 24042202 0100 c95abd88 [2.406669] GPR16: c05569d4 0001 0010 c95abc88 c0615664 0004 [2.406669] GPR24: 0010 c95abc88 c95abc88 c61ae210 c7ff6d40 c61ae210 3d68 [2.441559] NIP [c000c540] dma_nommu_map_page+0x44/0xd4 [2.446720] LR [c000c584] dma_nommu_map_page+0x88/0xd4 [2.451762] Call Trace: [2.454195] [c95abb60] [82000808] 0x82000808 (unreliable) [2.459572] [c95abb80] [c02f2244] talitos_edesc_alloc+0xbc/0x3c8 [2.465493] [c95abbb0] [c02f2600] ablkcipher_edesc_alloc+0x4c/0x5c [2.471606] [c95abbd0] [c02f4ed0] ablkcipher_encrypt+0x20/0x64 [2.477389] [c95abbe0] [c02023b0] __test_skcipher+0x4bc/0xa08 [2.483049] [c95abe00] [c0204b60] test_skcipher+0x2c/0xcc [2.488385] [c95abe20] [c0204c48] alg_test_skcipher+0x48/0xbc [2.494064] [c95abe40] [c0205cec] alg_test+0x164/0x2e8 [2.499142] [c95abf00] [c0200dec] cryptomgr_test+0x48/0x50 [2.504558] [c95abf10] [c0039ff4] kthread+0xe4/0x110 [2.509471] [c95abf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c [2.515532] Instruction dump: [2.518468] 7c7e1b78 7c9d2378 7cbf2b78 41820054 3d20c076 8089c200 3d20c076 7c84e850 [2.526127] 8129c204 7c842e70 7f844840 419c0008 <0fe0> 2f9e 54847022 7c84fa14 [2.533960] ---[ end trace bf78d94af73fe3b8 ]--- [2.539123] talitos ff02.crypto: master data transfer error [2.544775] talitos ff02.crypto: TEA error: ISR 0x2000_0040 [2.551625] alg: skcipher: encryption failed on test 1 for ecb-aes-talitos: ret=22 IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack cannot be DMA mapped anymore. This patch allocates it with kmalloc() This looks like a driver bug to me. Other accelerators in drivers/crypto all take a copy of the IV before mapping it for DMA, so it would be better if talitos did the same. Yes please fix the driver. In general, if a paramter is coming in as a pointer, you must assume that it may lie on the stack. Yes, just sent a patch for the talitos driver for it. But note that the IV is received via areq->info and not via a standalone pointer. Christophe
[PATCH] crypto: talitos - fix ablkcipher for CONFIG_VMAP_STACK
[2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837
dma_nommu_map_page+0x44/0xd4
[2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW
4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
[2.384740] NIP: c000c540 LR: c000c584 CTR:
[2.389743] REGS: c95abab0 TRAP: 0700 Tainted: GW
(4.20.0-rc5-00560-g6bfb52e23a00-dirty)
[2.400042] MSR: 00029032 CR: 24042204 XER:
[2.406669]
[2.406669] GPR00: c02f2244 c95abb60 c6262990 c95abd80 256a 0001
0001 0001
[2.406669] GPR08: 2000 0010 0010 24042202
0100 c95abd88
[2.406669] GPR16: c05569d4 0001 0010 c95abc88 c0615664
0004
[2.406669] GPR24: 0010 c95abc88 c95abc88 c61ae210 c7ff6d40
c61ae210 3d68
[2.441559] NIP [c000c540] dma_nommu_map_page+0x44/0xd4
[2.446720] LR [c000c584] dma_nommu_map_page+0x88/0xd4
[2.451762] Call Trace:
[2.454195] [c95abb60] [82000808] 0x82000808 (unreliable)
[2.459572] [c95abb80] [c02f2244] talitos_edesc_alloc+0xbc/0x3c8
[2.465493] [c95abbb0] [c02f2600] ablkcipher_edesc_alloc+0x4c/0x5c
[2.471606] [c95abbd0] [c02f4ed0] ablkcipher_encrypt+0x20/0x64
[2.477389] [c95abbe0] [c02023b0] __test_skcipher+0x4bc/0xa08
[2.483049] [c95abe00] [c0204b60] test_skcipher+0x2c/0xcc
[2.488385] [c95abe20] [c0204c48] alg_test_skcipher+0x48/0xbc
[2.494064] [c95abe40] [c0205cec] alg_test+0x164/0x2e8
[2.499142] [c95abf00] [c0200dec] cryptomgr_test+0x48/0x50
[2.504558] [c95abf10] [c0039ff4] kthread+0xe4/0x110
[2.509471] [c95abf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c
[2.515532] Instruction dump:
[2.518468] 7c7e1b78 7c9d2378 7cbf2b78 41820054 3d20c076 8089c200 3d20c076
7c84e850
[2.526127] 8129c204 7c842e70 7f844840 419c0008 <0fe0> 2f9e 54847022
7c84fa14
[2.533960] ---[ end trace bf78d94af73fe3b8 ]---
[2.539123] talitos ff02.crypto: master data transfer error
[2.544775] talitos ff02.crypto: TEA error: ISR 0x2000_0040
[2.551625] alg: skcipher: encryption failed on test 1 for ecb-aes-talitos:
ret=22
IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
cannot be DMA mapped anymore.
This patch copies the IV from areq->info to the context ctx->iv.
Fixes: 4de9d0b547b9 ("crypto: talitos - Add ablkcipher algorithms")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 6988012deca4..385ec970b639 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1668,8 +1668,11 @@ static struct talitos_edesc
*ablkcipher_edesc_alloc(struct ablkcipher_request *
struct talitos_ctx *ctx = crypto_ablkcipher_ctx(cipher);
unsigned int ivsize = crypto_ablkcipher_ivsize(cipher);
+ if (ivsize)
+ memcpy(ctx->iv, areq->info, ivsize);
+
return talitos_edesc_alloc(ctx->dev, areq->src, areq->dst,
- areq->info, 0, areq->nbytes, 0, ivsize, 0,
+ ctx->iv, 0, areq->nbytes, 0, ivsize, 0,
areq->base.flags, encrypt);
}
--
2.13.3
RE: [PATCH v2] cpuidle: Add 'above' and 'below' idle state metrics
On 2018.12.10 02:52 Peter Zijlstra wrote: >On Mon, Dec 10, 2018 at 10:36:40PM +0100, Rafael J. Wysocki wrote: >> On Mon, Dec 10, 2018 at 1:21 PM Peter Zijlstra wrote: >>> Would not a tracepoint be better?; then there is no overhead in the >>> normal case where nobody gives a crap about these here numbers. >> >> There is an existing tracepoint that in principle could be used to >> produce this information, but it is such a major PITA in practice that >> nobody does that. Guess why. :-) > > Sounds like you need to ship a convenient script or something :-) For the histogram plots of idle durations that I sometimes provide, trace is used. It is more work to do it the trace way. Very often, when the rate of idle state entries/ exits is high, turning on trace influences the system under test significantly. Also, even if I allocate the majority of my memory to the trace buffer (i.e. 15 of my 16 gigabytes), I can only acquire a few minutes of trace data before filling the buffer. Some of my tests run for hours, and these new counters provide a way to acquire potentially useful (I don't have enough experience with them yet to know how useful) information, while having no influence on the system under test because I only take samples once per minute, or sometimes 4 times per minute. >> Also, the "usage" and "time" counters are there in sysfs, so why not these >> two? I agree, how are these two counters any different? In about a week or so, I'll have some test data comparing 4.20-rc5 with teov6 teov7 along with the idle data (graphs) that I usually provide and also these new counters. ... Doug
linux-next: Tree for Dec 11
Hi all, Changes since 20181210: The arm64 tree gained a conflict against Linus' tree. The f2fs tree gained a conflict against the fscrypt tree. The ubifs tree gained a conflict against the fscrypt tree. The rdma tree still had its build failure so I used the version from next-20181203. The tip tree gained a conflict against the hwmon-staging tree. The gpio tree lost its build failure. The akpm-current tree lost its build failure but gained conflist against the arm64 tree. Non-merge commits (relative to Linus' tree): 7744 8462 files changed, 365061 insertions(+), 211977 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 288 trees (counting Linus' and 68 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (f5d582777bcb Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid) Merging fixes/master (d8c137546ef8 powerpc: tag implicit fall throughs) Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2) Merging arc-current/for-curr (4c567a448b30 ARC: perf: remove useless ifdefs) Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential uninitialized return) Merging arm64-fixes/for-next/fixes (b4aecf78083d arm64: hibernate: Avoid sending cross-calling with interrupts disabled) Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode) Merging powerpc-fixes/fixes (9ef34630a461 powerpc/mm: Fallback to RAM if the altmap is unusable) Merging sparc/master (cf76c364a1e1 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (5648451e30a0 ipv4: Fix potential Spectre v1 vulnerability) Merging bpf/master (c2a20a2731df selftests/bpf: add missing pointer dereference for map stacktrace fixup) Merging ipsec/master (4a135e538962 xfrm_user: fix freeing of xfrm states on acquire) Merging netfilter/master (530aad77010b netfilter: seqadj: re-load tcp header pointer after possible head reallocation) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (2e6e902d1850 Linux 4.20-rc4) Merging mac80211/master (312ca38ddda6 cfg80211: Fix busy loop regression in ieee80211_ie_split_ric()) Merging rdma-fixes/for-rc (47f07f03b5ee IB/mlx5: Block DEVX umem from the non applicable cases) Merging sound-current/for-linus (0bea4cc83835 ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN/UX333FA with ALC294) Merging sound-asoc-fixes/for-linus (b99f6edf9be5 Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (9ff01193a20d Linux 4.20-rc3) Merging regulator-fixes/for-linus (8852a24b6675 Merge branch 'regulator-4.20' into regulator-linus) Merging spi-fixes/for-linus (a78de6b8fb72 Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (b07b864ee423 Revert "PCI/ASPM: Do not initialize link state when aspm_disabled is set") Merging driver-core.current/driver-core-linus (2595646791c3 Linux 4.20-rc5) Merging tty.current/tty-linus (40e020c129cf Linux 4.20-rc6) Merging usb.current/usb-linus (40e020c129cf Linux 4.20-rc6) Merging usb-gadget-fixes/fixes (069caf5950df USB: omap_udc: fix reject
RE: [PATCH v6 1/2] mailbox: ZynqMP IPI mailbox controller
> -Original Message- > From: Wendy Liang [mailto:wendy.li...@xilinx.com] > Sent: Monday, November 19, 2018 1:26 PM > To: jassisinghb...@gmail.com; Michal Simek ; > robh...@kernel.org; mark.rutl...@arm.com > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; Jiaying Liang > Subject: [PATCH v6 1/2] mailbox: ZynqMP IPI mailbox controller > > This patch is to introduce ZynqMP IPI mailbox controller driver to use the > ZynqMP IPI block as mailboxes. > > Signed-off-by: Wendy Liang > --- > drivers/mailbox/Kconfig| 9 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/zynqmp-ipi-mailbox.c | 762 > + > include/linux/mailbox/zynqmp-ipi-message.h | 24 + > 4 files changed, 797 insertions(+) > create mode 100644 drivers/mailbox/zynqmp-ipi-mailbox.c > create mode 100644 include/linux/mailbox/zynqmp-ipi-message.h > > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index > 3eeb12e9..10bfe3f 100644 > --- a/drivers/mailbox/Kconfig > +++ b/drivers/mailbox/Kconfig > @@ -205,4 +205,13 @@ config MTK_CMDQ_MBOX > mailbox driver. The CMDQ is used to help read/write registers with > critical time limitation, such as updating display configuration > during the vblank. > + > +config ZYNQMP_IPI_MBOX > + tristate "Xilinx ZynqMP IPI Mailbox" > + depends on ARCH_ZYNQMP && OF > + help > + Mailbox implementation for Xilinx ZynqMP IPI controller. It is used > + to send notification or short message between processors on Xilinx > + UltraScale+ MPSoC platforms. Say Y here if you want to have this > + support. > endif > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index > c818b5d..bb3d604 100644 > --- a/drivers/mailbox/Makefile > +++ b/drivers/mailbox/Makefile > @@ -44,3 +44,5 @@ obj-$(CONFIG_TEGRA_HSP_MBOX)+= tegra- > hsp.o > obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o > > obj-$(CONFIG_MTK_CMDQ_MBOX) += mtk-cmdq-mailbox.o > + > +obj-$(CONFIG_ZYNQMP_IPI_MBOX) += zynqmp-ipi-mailbox.o > diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp- > ipi-mailbox.c > new file mode 100644 > index 000..bc02864 > --- /dev/null > +++ b/drivers/mailbox/zynqmp-ipi-mailbox.c > @@ -0,0 +1,762 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Xilinx Inter Processor Interrupt(IPI) Mailbox Driver > + * > + * Copyright (C) 2018 Xilinx Inc. > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* IPI agent ID any */ > +#define IPI_ID_ANY 0xFFUL > + > +/* indicate if ZynqMP IPI mailbox driver uses SMC calls or HVC calls */ > +#define USE_SMC 0 #define USE_HVC 1 > + > +/* Default IPI SMC function IDs */ > +#define SMC_IPI_MAILBOX_OPEN0x82001000U > +#define SMC_IPI_MAILBOX_RELEASE 0x82001001U > +#define SMC_IPI_MAILBOX_STATUS_ENQUIRY 0x82001002U > +#define SMC_IPI_MAILBOX_NOTIFY 0x82001003U > +#define SMC_IPI_MAILBOX_ACK 0x82001004U > +#define SMC_IPI_MAILBOX_ENABLE_IRQ 0x82001005U > +#define SMC_IPI_MAILBOX_DISABLE_IRQ 0x82001006U > + > +/* IPI SMC Macros */ > +#define IPI_SMC_OPEN_IRQ_MASK0x0001UL /* IRQ enable > bit in IPI > + * open SMC call > + */ > +#define IPI_SMC_NOTIFY_BLOCK_MASK0x0001UL /* Flag to > indicate if > + * IPI notification needs > + * to be blocking. > + */ > +#define IPI_SMC_ENQUIRY_DIRQ_MASK 0x0001UL /* Flag to > indicate if > + * notification interrupt > + * to be disabled. > + */ > +#define IPI_SMC_ACK_EIRQ_MASK 0x0001UL /* Flag to indicate if > + * notification interrupt > + * to be enabled. > + */ > + > +/* IPI mailbox status */ > +#define IPI_MB_STATUS_IDLE 0 > +#define IPI_MB_STATUS_SEND_PENDING 1 > +#define IPI_MB_STATUS_RECV_PENDING 2 > + > +#define IPI_MB_CHNL_TX 0 /* IPI mailbox TX channel */ #define > +IPI_MB_CHNL_RX 1 /* IPI mailbox RX channel */ > + > +/** > + * struct zynqmp_ipi_mchan - Description of a Xilinx ZynqMP IPI mailbox > +channel > + * @is_opened: indicate if the IPI channel is opened > + * @req_buf: local to remote request buffer start address > + * @resp_buf: local to remote response buffer start address > + * @req_buf_size:
RE: Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start
> Hi Saravana, > > The devfreq git repo is maintained by Myungjoo Ham. > you can check it on MAINTAINERS file. > > I think that you better to resend mail to mainline > with my reviewed tag because the devfreq core could be modified > and then merge conflict might be happen when apply this patch. > > Regards, > Chanwoo Choi > > On 2018년 12월 08일 05:29, Saravana Kannan wrote: > > > > On 11/9/16 4:10 PM, Chanwoo Choi wrote: > >> After fixing the bug of devfreq_add_device(), > >> I'll remove the unneeded 'if statement' of prev_governor in governor_store. > > > > It's been 2 years and this patch still hasn't been picked up. Can we please > > pick this up and get this into the next kernel release? > > > > Thanks, > > > > Saravana > > If that's already 2 years old, please rebase, test to see if that's still valid with today's kernel, and resubmit. Sorry for missing it, right now, after 2 years, I just can't remember this one. Cheers, MyungJoo
Re: [linux-sunxi] [PATCH 0/8] This is a second edition of a series that implements voltage
On Mon, Dec 10, 2018 at 08:42:11PM +0200, Priit Laes wrote: > ramping for AXP209 DCDC2 and LDO3 regulators and software > based soft-start for AXP209 LDO3 regulator. Ugh.. managed to botch this series. I'll send a fixed one today. > > Both features are needed to work around a PMIC shutdown when > toggling LDO3 on certain boards with high capacitance on the > LDO3 output. > > Similar features (or workarounds) have been also implemented > on u-boot side [1]. > > Changes since v1: > - Rebased on top of next and dropped already merged patches. > - Dropped LDO4 full range devicetree change for Lime2 (prev patch 9) > in favor of general pin-bank regulator dependency [2]. > - Fixed paths in devicetree bindings (patch 3) > - Added note about software based soft-start for LDO3 (patch 5) > > [1] https://lists.denx.de/pipermail/u-boot/2018-November/348612.html > [2] > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-December/618459.html > > Olliver Schinagl (8): > mfd: axp20x: name voltage ramping define properly > regulator: axp20x: add support for set_ramp_delay for AXP209 > dt-bindings: mfd: axp20x: add support for regulator-ramp-delay for AXP209 > regulator: axp20x: add software based soft_start for AXP209 LDO3 > dt-bindings: mfd: axp20x: Add software based soft_start for AXP209 LDO3 > regulator: dts: enable soft-start and ramp delay for the OLinuXino Lime2 > mfd: axp20x: Clean up included headers > mfd: axp20x: use explicit bit defines > > Documentation/devicetree/bindings/mfd/axp20x.txt | 9 +- > arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 2 +- > drivers/mfd/axp20x.c | 13 +- > drivers/regulator/axp20x-regulator.c | 142 +++- > include/linux/mfd/axp20x.h | 4 +- > 5 files changed, 161 insertions(+), 9 deletions(-) > > base-commit: 14cf8c1d5b90a0cf6a8ba51ef59db8da8c7a2622 > -- > git-series 0.9.1 > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.
Re: [PATCH v10 0/8] Introduce on-chip interconnect API
On Mon, Dec 10, 2018 at 04:50:00PM +0200, Georgi Djakov wrote: > On 12/10/18 13:00, Rafael J. Wysocki wrote: > > On Mon, Dec 10, 2018 at 11:18 AM Georgi Djakov > > wrote: > >> > >> Hi Rafael, > >> > >> On 12/10/18 11:04, Rafael J. Wysocki wrote: > >>> On Thu, Dec 6, 2018 at 3:55 PM Greg KH wrote: > > On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote: > > On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov > > wrote: > >> > >> Modern SoCs have multiple processors and various dedicated cores > >> (video, gpu, > >> graphics, modem). These cores are talking to each other and can > >> generate a > >> lot of data flowing through the on-chip interconnects. These > >> interconnect > >> buses could form different topologies such as crossbar, point to point > >> buses, > >> hierarchical buses or use the network-on-chip concept. > >> > >> These buses have been sized usually to handle use cases with high data > >> throughput but it is not necessary all the time and consume a lot of > >> power. > >> Furthermore, the priority between masters can vary depending on the > >> running > >> use case like video playback or CPU intensive tasks. > >> > >> Having an API to control the requirement of the system in terms of > >> bandwidth > >> and QoS, so we can adapt the interconnect configuration to match those > >> by > >> scaling the frequencies, setting link priority and tuning QoS > >> parameters. > >> This configuration can be a static, one-time operation done at boot > >> for some > >> platforms or a dynamic set of operations that happen at run-time. > >> > >> This patchset introduce a new API to get the requirement and configure > >> the > >> interconnect buses across the entire chipset to fit with the current > >> demand. > >> The API is NOT for changing the performance of the endpoint devices, > >> but only > >> the interconnect path in between them. > > > > For what it's worth, we are ready to land this in Chrome OS. I think > > this series has been very well discussed and reviewed, hasn't changed > > much in the last few spins, and is in good enough shape to use as a > > base for future patches. Georgi's also done a great job reaching out > > to other SoC vendors, and there appears to be enough consensus that > > this framework will be usable by more than just Qualcomm. There are > > also several drivers out on the list trying to add patches to use this > > framework, with more to come, so it made sense (to us) to get this > > base framework nailed down. In my experiments this is an important > > piece of the overall power management story, especially on systems > > that are mostly idle. > > > > I'll continue to track changes to this series and we will ultimately > > reconcile with whatever happens upstream, but I thought it was worth > > sending this note to express our "thumbs up" towards this framework. > > Looks like a v11 will be forthcoming, so I'll wait for that one to apply > it to the tree if all looks good. > >>> > >>> I'm honestly not sure if it is ready yet. > >>> > >>> New versions are coming on and on, which may make such an impression, > >>> but we had some discussion on it at the LPC and some serious questions > >>> were asked during it, for instance regarding the DT binding introduced > >>> here. I'm not sure how this particular issue has been addressed here, > >>> for example. > >> > >> There have been no changes in bindings since v4 (other than squashing > >> consumer and provider bindings into a single patch and fixing typos). > >> > >> The last DT comment was on v9 [1] where Rob wanted confirmation from > >> other SoC vendors that this works for them too. And now we have that > >> confirmation and there are patches posted on the list [2]. > > > > OK > > > >> The second thing (also discussed at LPC) was about possible cases where > >> some consumer drivers can't calculate how much bandwidth they actually > >> need and how to address that. The proposal was to extend the OPP > >> bindings with one more property, but this is not part of this patchset. > >> It is a future step that needs more discussion on the mailing list. If a > >> driver really needs some bandwidth data now, it should be put into the > >> driver and not in DT. After we have enough consumers, we can discuss > >> again if it makes sense to extract something into DT or not. > > > > That's fine by me. > > > > Admittedly, I have some reservations regarding the extent to which > > this approach will turn out to be useful in practice, but I guess as > > long as there is enough traction, the best way to find out it to try > > and see. :-) > > > > From now on I will assume that this series is going to be applied by Greg. > > That was the initial idea, but the problem is that there
Re: *powersave* governor shown despite disabled in configuration
On Mon, Dec 10, 2018 at 04:30:05PM +0100, Paul Menzel wrote: > Dear Linux folks, > > > With Linux 4.14.76, the scaling governor *powersave* is shown as > being available despite being disabled in the configuration. Which cpufreq driver do you use? Presumably intel_pstate? That driver exposes internal policies / "governors" named "performance" and "powersave", which are unrelated to CONFIG_CPU_FREQ_GOV_POWERSAVE. Thanks, Dominik
Re: [RFC] avoid indirect calls for DMA direct mappings v2
On Mon, Dec 10, 2018 at 01:51:13PM -0800, Luck, Tony wrote: > But the ia64 build fails with: Yes, I just got the same complaint form the buildbot, unfortunately I don't have a good ia64 cross compiler locally given that Debian is lacking one, and the one provided by the buildbot doesn't build on Debian either.. This should fix it: diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c index 2c51733f1dfd..a007afaa556c 100644 --- a/arch/ia64/mm/init.c +++ b/arch/ia64/mm/init.c @@ -8,6 +8,7 @@ #include #include +#include #include #include #include
Re: [PATCHv2 12/12] doc/mm: New documentation for memory performance
Hi Keith,
Thanks for the docs! :)
Some nits below...
On Mon, Dec 10, 2018 at 06:03:10PM -0700, Keith Busch wrote:
> Platforms may provide system memory where some physical address ranges
> perform differently than others, or is side cached by the system.
>
> Add documentation describing a high level overview of such systems and the
> performance and caching attributes the kernel provides for applications
> wishing to query this information.
>
> Signed-off-by: Keith Busch
> ---
> Documentation/admin-guide/mm/numaperf.rst | 171
> ++
> 1 file changed, 171 insertions(+)
> create mode 100644 Documentation/admin-guide/mm/numaperf.rst
>
> diff --git a/Documentation/admin-guide/mm/numaperf.rst
> b/Documentation/admin-guide/mm/numaperf.rst
> new file mode 100644
> index ..846b3f991e7f
> --- /dev/null
> +++ b/Documentation/admin-guide/mm/numaperf.rst
> @@ -0,0 +1,171 @@
> +.. _numaperf:
> +
> +=
> +NUMA Locality
> +=
> +
> +Some platforms may have multiple types of memory attached to a single
> +CPU. These disparate memory ranges share some characteristics, such as
> +CPU cache coherence, but may have different performance. For example,
> +different media types and buses affect bandwidth and latency.
> +
> +A system supporting such heterogeneous memory by grouping each memory
Maybe "A system supports ..."?
> +type under different "nodes" based on similar CPU locality and performance
> +characteristics. Some memory may share the same node as a CPU, and others
> +are provided as memory only nodes. While memory only nodes do not provide
> +CPUs, they may still be directly accessible, or local, to one or more
> +compute nodes. The following diagram shows one such example of two compute
> +noes with local memory and a memory only node for each of compute node:
^ attached to each ?
> +
> + +--+ +--+
> + | Compute Node 0 +-+ Compute Node 1 |
> + | Local Node0 Mem | | Local Node1 Mem |
> + ++-+ ++-+
> + ||
> + ++-+ ++-+
> + | Slower Node2 Mem | | Slower Node3 Mem |
> + +--+ ++-+
> +
> +A "memory initiator" is a node containing one or more devices such as
> +CPUs or separate memory I/O devices that can initiate memory requests. A
> +"memory target" is a node containing one or more accessible physical
> +address ranges from one or more memory initiators.
Maybe "... one or more address ranges accessible from one or more memory
initiators"
> +
> +When multiple memory initiators exist, they may not all have the same
> +performance when accessing a given memory target. The highest performing
> +initiator to a given target is considered to be one of that target's
> +local initiators. Any given target may have one or more local initiators,
> +and any given initiator may have multiple local memory targets.
> +
> +To aid applications matching memory targets with their initiators,
> +the kernel provide symlinks to each other like the following example::
^ provides
> +
> + # ls -l /sys/devices/system/node/nodeX/local_target*
> + /sys/devices/system/node/nodeX/local_targetY -> ../nodeY
> +
> + # ls -l /sys/devices/system/node/nodeY/local_initiator*
> + /sys/devices/system/node/nodeY/local_initiatorX -> ../nodeX
> +
> +The linked nodes will also have their node number set in the local_mem
> +and local_cpu node list and maps.
> +
> +An example showing how this may be used to run a particular task on CPUs
> +and memory that are both local to a particular PCI device can be done
> +using existing 'numactl' as follows::
> +
> + # NODE=$(cat /sys/devices/pci::00/.../numa_node)
> + # numactl --membind=$(cat
> /sys/devices/node/node${NODE}/local_mem_nodelist) \
> + --cpunodebind=$(cat /sys/devices/node/node${NODE}/local_cpu_nodelist) \
> + --
> +
> +
> +NUMA Performance
> +
> +
> +Applications may wish to consider which node they want their memory to
> +be allocated from based on the node's performance characteristics. If the
> +system provides these attributes, the kernel exports them under the node
> +sysfs hierarchy by appending the local_initiator_access directory under
> +the memory node as follows::
> +
> + /sys/devices/system/node/nodeY/local_initiator_access/
> +
> +The kernel does not provide performance attributes for non-local memory
> +initiators. These attributes apply only to the memory initiator nodes that
> +have a local_initiatorX link, or are set in the local_cpu_nodelist. A
> +memory initiator node is considered local to itself if it also is
> +a memory target and will be set it its node list and map, but won't
> +contain a symlink to itself.
> +
> +The performance characteristics the kernel provides for the local initiators
>
Re: [PATCH] Linux: Implement membarrier function
Hi Paul, thank you for thinking about all this.
I think the modelling you suggest captures most of the algorithms I
would want to write. I think it's slightly too weak, though, to
implement the model suggested in P1202R0[1], which permits the SC
outcome to be recovered in C-Goldblat-memb-2[2] by inserting a second
smp_memb() after the first, which is a rather nice property (and I
believe is supported by the underlying implementation options). I
afraid though that I'm not familiar enough with the Linux herd
definitions to suggest a tweak (or know how easy a tweak might be).
- David
[1] Which I think may be strengthened a little bit more even in R1.
[2] As a nit, my name has two "t"'s in it, although I'd throw into the
ring "memb-pairwise", "memb-nontransitive", and "memb-sequenced" if
these get non-placeholder names.
On Thu, Dec 6, 2018 at 1:54 PM Paul E. McKenney wrote:
>
> Hello, David,
>
> I took a crack at extending LKMM to accommodate what I think would
> support what you have in your paper. Please see the very end of this
> email for a patch against the "dev" branch of my -rcu tree.
>
> This gives the expected result for the following three litmus tests,
> but is probably deficient or otherwise misguided in other ways. I have
> added the LKMM maintainers on CC for their amusement. ;-)
>
> Thoughts?
>
> Thanx, Paul
>
>
>
> C C-Goldblat-memb-1
> {
> }
>
> P0(int *x0, int *x1)
> {
> WRITE_ONCE(*x0, 1);
> r1 = READ_ONCE(*x1);
> }
>
>
> P1(int *x0, int *x1)
> {
> WRITE_ONCE(*x1, 1);
> smp_memb();
> r2 = READ_ONCE(*x0);
> }
>
> exists (0:r1=0 /\ 1:r2=0)
>
>
>
> C C-Goldblat-memb-2
> {
> }
>
> P0(int *x0, int *x1)
> {
> WRITE_ONCE(*x0, 1);
> r1 = READ_ONCE(*x1);
> }
>
>
> P1(int *x1, int *x2)
> {
> WRITE_ONCE(*x1, 1);
> smp_memb();
> r1 = READ_ONCE(*x2);
> }
>
> P2(int *x2, int *x0)
> {
> WRITE_ONCE(*x2, 1);
> r1 = READ_ONCE(*x0);
> }
>
> exists (0:r1=0 /\ 1:r1=0 /\ 2:r1=0)
>
>
>
> C C-Goldblat-memb-3
> {
> }
>
> P0(int *x0, int *x1)
> {
> WRITE_ONCE(*x0, 1);
> r1 = READ_ONCE(*x1);
> }
>
>
> P1(int *x1, int *x2)
> {
> WRITE_ONCE(*x1, 1);
> smp_memb();
> r1 = READ_ONCE(*x2);
> }
>
> P2(int *x2, int *x3)
> {
> WRITE_ONCE(*x2, 1);
> r1 = READ_ONCE(*x3);
> }
>
> P3(int *x3, int *x0)
> {
> WRITE_ONCE(*x3, 1);
> smp_memb();
> r1 = READ_ONCE(*x0);
> }
>
> exists (0:r1=0 /\ 1:r1=0 /\ 2:r1=0 /\ 3:r1=0)
>
>
>
> On Thu, Nov 29, 2018 at 11:02:17AM -0800, David Goldblatt wrote:
> > One note with the suggested patch is that
> > `atomic_thread_fence(memory_order_acq_rel)` should probably be
> > `atomic_thread_fence (memory_order_seq_cst)` (otherwise the call would
> > be a no-op on, say, x86, which it very much isn't).
> >
> > The non-transitivity thing makes the resulting description arguably
> > incorrect, but this is informal enough that it might not be a big deal
> > to add something after "For these threads, the membarrier function
> > call turns an existing compiler barrier (see above) executed by these
> > threads into full memory barriers" that clarifies it. E.g. you could
> > make it into "turns an existing compiler barrier [...] into full
> > memory barriers, with respect to the calling thread".
> >
> > Since this is targeting the description of the OS call (and doesn't
> > have to concern itself with also being implementable by other
> > asymmetric techniques or degrading to architectural barriers), I think
> > that the description in "approach 2" in P1202 would also make sense
> > for a formal description of the syscall. (Of course, without the
> > kernel itself committing to a rigorous semantics, anything specified
> > on top of it will be on slightly shaky ground).
> >
> > - David
> >
> > On Thu, Nov 29, 2018 at 7:04 AM Paul E. McKenney
> > wrote:
> > >
> > > On Thu, Nov 29, 2018 at 09:44:22AM -0500, Mathieu Desnoyers wrote:
> > > > - On Nov 29, 2018, at 8:50 AM, Florian Weimer fwei...@redhat.com
> > > > wrote:
> > > >
> > > > > * Torvald Riegel:
> > > > >
> > > > >> On Wed, 2018-11-28 at 16:05 +0100, Florian Weimer wrote:
> > > > >>> This is essentially a repost of last year's patch, rebased to the
> > > > >>> glibc
> > > > >>> 2.29 symbol version and reflecting the introduction of
> > > > >>> MEMBARRIER_CMD_GLOBAL.
> > > > >>>
> > > > >>> I'm not including any changes to manual/ here because the set of
> > > > >>> supported operations is evolving rapidly, we could not get
> > > > >>> consensus for
> > > > >>> the language I proposed the last time, and I do not want to
> > > > >>>
Re: [PATCH] regmap: regmap-irq/gpio-max77620: add level-irq support
Hello Vladimir,
Thanks for the review.
On Mon, Dec 10, 2018 at 05:16:28PM +0200, Vladimir Zapolskiy wrote:
> On 12/10/2018 10:14 AM, Matti Vaittinen wrote:
> > Add level active IRQ support to regmap-irq irqchip. Change breaks
> > existing regmap-irq type setting. Convert the existing drivers which
> > use regmap-irq with trigger type setting (gpio-max77620) to work
> > with this new approach. So we do not magically support level-active
> > IRQs on gpio-max77620 - but add support to the regmap-irq for chips
> > which support them =)
> >
> > We do not support distinguishing situation where HW supports rising
> > and falling edge detection but not both. Separating this would require
> > inventing yet another flags for IRQ types.
> >
> > Signed-off-by: Matti Vaittinen
> > ---
> > I did both the regmap-irq and max77620 changes in same commit because
> > I'd rather not cause spot where max77620 breaks. Besides the changes in
> > max77620 driver are trivial. Please let me know if this is not Ok.
> >
> > Reason why I submit this patch now - even though my driver which would
> > use level active type setting with regmap-irq is not yet ready for
> > being submited - is that I'd like to minimize amount of existing drivers
> > we need to patch. And if we add level active irq support like this then
> > we must patch all existing drivers using type setting with regmap-irq.
> > So doing this now when only max77620 uses type setting may be easier
> > than postponing this to the future.
> >
> > And finally - I don't have max77620 so I have only done _wery_ limited
> > testing. So I would really appreciate if someone had time to review this
> > thoroughly - and even happier if someone had possibility to try this out
> > with the max77620.
> >
>
> [snip]
>
> > diff --git a/include/linux/regmap.h b/include/linux/regmap.h
> > index a367d59c301d..91c431ad98c3 100644
> > --- a/include/linux/regmap.h
> > +++ b/include/linux/regmap.h
> > @@ -1098,6 +1098,9 @@ int regmap_fields_update_bits_base(struct
> > regmap_field *field, unsigned int id,
> > * @type_reg_offset: Offset register for the irq type setting.
> > * @type_rising_mask: Mask bit to configure RISING type irq.
> > * @type_falling_mask: Mask bit to configure FALLING type irq.
> > + * @type_level_low_mask: Mask bit to configure LEVEL_LOW type irq.
> > + * @type_level_high_mask: Mask bit to configure LEVEL_HIGH type irq.
> > + * @types_supported: logical OR of IRQ_TYPE_* flags indicating supported
> > types.
>
> While the existing interface is awful, you don't make it better.
>
> .types_supported value is always derived from non-zero .type_*_mask values, so
> it is simply not needed, as well as the whole change to gpio-max77620.c
> driver.
Right. I didn't consider the "type_inverted" flag in the struct
regmap_irq_chip. I thought that "mask" is actually a register value -
which could be zero for some HWs. Thanks for pointing that out. It will
really make "types_supported" useless.
So please just drop this patch for now. There seems to be no need to
touch the existing regmap-irq users after all so I can submit this patch
together with the driver which needs to support the level active IRQs.
>
> > */
> > struct regmap_irq {
> > unsigned int reg_offset;
> > @@ -1105,6 +1108,9 @@ struct regmap_irq {
> > unsigned int type_reg_offset;
> > unsigned int type_rising_mask;
> > unsigned int type_falling_mask;
> > + unsigned int type_level_low_mask;
> > + unsigned int type_level_high_mask;
> > + unsigned int types_supported;
> > };
> >
> > #define REGMAP_IRQ_REG(_irq, _off, _mask) \
> >
>
> --
> Best wishes,
> Vladimir
--
Matti Vaittinen
ROHM Semiconductors
~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
RE: Fwd: [Bug 201647] New: Intel Wireless card 3165 does not get detected but bluetooth works
> > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=201647 > > > > > > > > Bug ID: 201647 > > > >Summary: Intel Wireless card 3165 does not get detected but > > > > bluetooth works > > > >Product: Drivers > > > >Version: 2.5 > > > > Kernel Version: 4.19.1 > > > > Hardware: Intel > > > > OS: Linux > > > > Tree: Mainline > > > > Status: NEW > > > > Severity: high > > > > Priority: P1 > > > > Component: PCI > > > > Assignee: drivers_...@kernel-bugs.osdl.org > > > > Reporter: mertar...@gmail.com > > > > Regression: No > > > > > > > > This bug affects most of the devices with a Celeron N4000 and an > > > > Intel wifi 3165 Ac adapter. > > > > > > > > When using Linux wifi is not working however, Bluetooth is working > > > > fine. Also, Bluetooth part of this chip is connected via btusb > > > > and the wifi part of this chip is connected via PCIe. > > > > > > Can you attach a screenshot of the Windows 10 device manager info > > > for the wifi adapter to the bugzilla? If you can get a raw hex dump > > > of its config space, that would be awesome. > > > > > > Also attach a copy of your kernel .config file (typically in /boot/). > > > > > > My only guess is that maybe the system keeps wifi completely powered > > > down and uses hotplug to add it when needed. [1] mentions wifi > > > being on pcibus 1 under Windows. Your lspci does show bridge > > > 00:13.0 leading to bus 01, but Linux doesn't find any devices on bus 01. > > > > > > Hotplug could be done via either acpiphp (ACPI mediated hotplug) or > > > pciehp (native PCIe hotplug). Your dmesg shows you do have acpiphp. > > > > > > I can't tell about pciehp (your .config will show that), but I think > > > pciehp will only claim bridges where SltCap contains HotPlug+, and > > > yours shows HotPlug- , so I don't think pciehp will do anything on your > system. > > > > > > Even if the system does use hotplug, I don't know what mechanism the > > > OS would use to wake up the device, since we don't know it even > > > exists. I guess there could be some magic switch accessible via USB. > > > But if that were the case, I'm sure Emmanuel would know about it. > > > > Hm... Don't be so sure... :) > > I don't think we have anything as fancy as this. > > I guess you can try to dig into the BIOS settings? > > I have heard of such a switch that would make the device disappear. > > It's worth looking, but I don't understand how a BIOS switch would solve this > problem. I assume that with the same BIOS settings, Windows works and > Linux fails. I guess I had a typo there... I have *not* heard of such a switch. > > Maybe there would be a clue in an acpidump from affected machines, e.g., > maybe we'd see some kind of ACPI hotplug notification. That seems like a > long shot because we do have acpiphp in the kernel, and it *should* be > handling such notifications, but it could always be broken. > > The Windows device manager info (requested above) would be interesting. > Indeed. FWIW: I saw another problem like this with a 9650 device. PS: PCI folks don't use bugzilla's anymore? It's all over the mailing list?
Re: [PATCH 1/5] dt-bindings: i2c: Add Mediatek MT7629 i2c binding
On Tue, 2018-12-04 at 12:19 -0800, Sean Wang wrote: > 於 2018年12月3日 週一 上午5:34寫道： > > > > From: qii wang > > > > Add MT7629 i2c binding to i2c-mt2712.txt and there is no need to > > where's i2c-mt2712.txt mentioned here? > Sorry, I will rewrite this commit. Such as: Add MT7629 i2c binding to binding file. > > modify i2c driver. > > suggest not to mention driver in any dt-binding, dt-binding self > should be os-agnostic > Yes, I will remove it. > > > > Signed-off-by: qii wang > > --- > > Documentation/devicetree/bindings/i2c/i2c-mtk.txt |1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > > b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > > index e199695..7729e57 100644 > > --- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > > +++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt > > @@ -10,6 +10,7 @@ Required properties: > >"mediatek,mt6589-i2c": for MediaTek MT6589 > >"mediatek,mt7622-i2c": for MediaTek MT7622 > >"mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623 > > + "mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek mt7629 > > change mt7629 to MT7629 to align to the others > OK. > >"mediatek,mt8173-i2c": for MediaTek MT8173 > >- reg: physical base address of the controller and dma base, length of > > memory > > mapped region. > > -- > > 1.7.9.5 > > > > > > ___ > > Linux-mediatek mailing list > > linux-media...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 28/52] Do fallocate() to grow file before mapping for file growing writes
Hi Vivek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on fuse/for-next]
[also build test WARNING on v4.20-rc6]
[cannot apply to next-20181210]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Vivek-Goyal/virtio-fs-shared-file-system-for-virtual-machines/20181211-103034
base: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
for-next
config: i386-randconfig-x000-201849 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
fs/fuse/file.c: In function 'fuse_dax_write_iter':
fs/fuse/file.c:1834:47: warning: format '%lx' expects argument of type 'long
unsigned int', but argument 3 has type 'size_t {aka unsigned int}' [-Wformat=]
printk("fallocate(offset=0x%llx length=0x%lx)"
~~^
%x
fs/fuse/file.c:1836:4:
iov_iter_count(from), ret);
fs/fuse/file.c:1834:11: warning: format '%ld' expects argument of type 'long
int', but argument 4 has type 'ssize_t {aka int}' [-Wformat=]
printk("fallocate(offset=0x%llx length=0x%lx)"
^~~
fs/fuse/file.c:1835:20: note: format string is defined here
" failed. err=%ld\n", iocb->ki_pos,
~~^
%d
In file included from include/linux/kernel.h:14:0,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from fs/fuse/fuse_i.h:13,
from fs/fuse/file.c:9:
include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 3 has type 'size_t {aka unsigned int}'
[-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:136:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~
include/linux/printk.h:346:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~
fs/fuse/file.c:1839:3: note: in expansion of macro 'pr_debug'
pr_debug("fallocate(offset=0x%llx length=0x%lx)"
^~~~
fs/fuse/file.c:1839:48: note: format string is defined here
pr_debug("fallocate(offset=0x%llx length=0x%lx)"
~~^
%x
In file included from include/linux/kernel.h:14:0,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from fs/fuse/fuse_i.h:13,
from fs/fuse/file.c:9:
>> include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of
>> type 'long int', but argument 4 has type 'ssize_t {aka int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:136:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~
include/linux/printk.h:346:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~
fs/fuse/file.c:1839:3: note: in expansion of macro 'pr_debug'
pr_debug("fallocate(offset=0x%llx length=0x%lx)"
^~~~
fs/fuse/file.c:1840:20: note: format string is defined here
" succeed. ret=%ld\n", iocb->ki_pos, iov_iter_count(from), ret);
~~^
%d
--
fs//fuse/file.c: In function 'fuse_dax_write_iter':
fs//fuse/file.c:1834:47: warning: format '%lx' expects argument of type
'long unsigned int', but argument 3 has type 'size_t {aka unsigned int}'
[-Wformat=]
printk("fallocate(offset=0x%llx length=0x%lx)"
~~^
%x
fs//fuse/file.c:1836:4:
iov_iter_count(from), ret);
Re: [PATCH v3 3/3] bus: imx-weim: guard against timing configuration conflicts
On Thu, Dec 06, 2018 at 02:26:33PM -0500, Sven Van Asbroeck wrote:
> When specifying weim child devices, there is a risk that more than
> one timing setting is specified for the same chip select.
>
> The driver cannot support such a configuration.
>
> In case of conflict, this patch will print a warning to the log,
> and will ignore the child node in question.
>
> In this example, node acme@1 will be ignored, as it tries to modify
> timing settings for CS0:
>
> {
> acme@0 {
> compatible = "acme,whatever";
> reg = <0 0 0x100>;
> fsl,weim-cs-timing = ;
> };
> acme@1 {
> compatible = "acme,whatnot";
> reg = <0 0x500 0x100>;
> fsl,weim-cs-timing = ;
> };
> };
>
> However in this example, the driver will be happy:
>
> {
> acme@0 {
> compatible = "acme,whatever";
> reg = <0 0 0x100>;
> fsl,weim-cs-timing = ;
> };
> acme@1 {
> compatible = "acme,whatnot";
> reg = <0 0x500 0x100>;
> fsl,weim-cs-timing = ;
> };
> };
>
> Signed-off-by: Sven Van Asbroeck
> ---
> drivers/bus/imx-weim.c | 33 ++---
> 1 file changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index 5452d22d1bd8..dfe74b8c512a 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -46,8 +46,18 @@ static const struct imx_weim_devtype imx51_weim_devtype = {
> };
>
> #define MAX_CS_REGS_COUNT6
> +#define MAX_CS_REGS 6
The macro name can easily confuse people with existing
MAX_CS_REGS_COUNT. By its meaning, I guess MAX_CS_COUNT should be more
accurate?
> #define OF_REG_SIZE 3
>
> +struct cs_timing {
> + bool is_applied;
> + u32 regs[MAX_CS_REGS_COUNT];
> +};
> +
> +struct cs_timing_state {
> + struct cs_timing cs[MAX_CS_REGS];
> +};
> +
> static const struct of_device_id weim_id_table[] = {
> /* i.MX1/21 */
> { .compatible = "fsl,imx1-weim", .data = _weim_devtype, },
> @@ -112,11 +122,14 @@ static int __init imx_weim_gpr_setup(struct
> platform_device *pdev)
> }
>
> /* Parse and set the timing for this device. */
> -static int __init weim_timing_setup(struct device_node *np, void __iomem
> *base,
> - const struct imx_weim_devtype *devtype)
> +static int __init weim_timing_setup(struct device *dev,
> + struct device_node *np, void __iomem *base,
> + const struct imx_weim_devtype *devtype,
> + struct cs_timing_state *ts)
> {
> u32 cs_idx, value[MAX_CS_REGS_COUNT];
> int i, ret, reg_idx, num_regs;
> + struct cs_timing *cst;
>
> if (WARN_ON(devtype->cs_regs_count > MAX_CS_REGS_COUNT))
> return -EINVAL;
> @@ -145,10 +158,23 @@ static int __init weim_timing_setup(struct device_node
> *np, void __iomem *base,
> if (cs_idx >= devtype->cs_count)
> return -EINVAL;
>
> + /* prevent re-configuring a CS that's already been configured */
> + cst = >cs[cs_idx];
> + if (cst->is_applied && memcmp(value, cst->regs,
> + devtype->cs_regs_count*sizeof(u32))) {
There should be space around *.
> + dev_err(dev, "fsl,weim-cs-timing conflict on %pOF", np);
> + return -EINVAL;
> + }
> +
> /* set the timing for WEIM */
> for (i = 0; i < devtype->cs_regs_count; i++)
> writel(value[i],
> base + cs_idx * devtype->cs_stride + i * 4);
> + if (!cst->is_applied) {
> + cst->is_applied = true;
> + memcpy(cst->regs, value,
> + devtype->cs_regs_count*sizeof(u32));
Ditto.
Shawn
> + }
> }
>
> return 0;
> @@ -162,6 +188,7 @@ static int __init weim_parse_dt(struct platform_device
> *pdev,
> const struct imx_weim_devtype *devtype = of_id->data;
> struct device_node *child;
> int ret, have_child = 0;
> + struct cs_timing_state ts = {};
>
> if (devtype == _weim_devtype) {
> ret = imx_weim_gpr_setup(pdev);
> @@ -170,7 +197,7 @@ static int __init weim_parse_dt(struct platform_device
> *pdev,
> }
>
> for_each_available_child_of_node(pdev->dev.of_node, child) {
> - ret = weim_timing_setup(child, base, devtype);
> + ret = weim_timing_setup(>dev, child, base, devtype, );
> if (ret)
> dev_warn(>dev, "%pOF set timing failed.\n",
> child);
> --
> 2.17.1
>
Re: [PATCH] thermal: tegra: add get_trend ops
Hi Rui & Eduardo,
Could you please take this patch?
Thanks.
Wei.
On 5/12/2018 4:30 PM, Wei Ni wrote:
> Hi Daniel,
> It seems no more comments, could this patch be approved?
>
> Thanks.
> Wei.
>
> On 30/11/2018 11:07 AM, Wei Ni wrote:
>>
>>
>> On 30/11/2018 1:01 AM, Eduardo Valentin wrote:
>>> On Wed, Nov 21, 2018 at 02:36:10PM +0800, Wei Ni wrote:
On 20/11/2018 11:38 PM, Thierry Reding wrote:
> On Tue, Nov 20, 2018 at 05:11:17PM +0800, Wei Ni wrote:
>> Add support for get_trend ops that allows soctherm
>> sensors to be used with the step-wise governor.
>>
>> Signed-off-by: Wei Ni
>> ---
>> drivers/thermal/tegra/soctherm.c | 34 ++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/drivers/thermal/tegra/soctherm.c
>> b/drivers/thermal/tegra/soctherm.c
>> index ed28110a3535..d2951fbe2b7c 100644
>> --- a/drivers/thermal/tegra/soctherm.c
>> +++ b/drivers/thermal/tegra/soctherm.c
>> @@ -488,9 +488,43 @@ static int tegra_thermctl_set_trip_temp(void *data,
>> int trip, int temp)
>> return 0;
>> }
>>
>> +static int tegra_thermctl_get_trend(void *data, int trip,
>> +enum thermal_trend *trend)
>> +{
>> +struct tegra_thermctl_zone *zone = data;
>> +struct thermal_zone_device *tz = zone->tz;
>> +int trip_temp, temp, last_temp, ret;
>> +
>> +if (!tz)
>> +return -EINVAL;
>> +
>> +ret = tz->ops->get_trip_temp(zone->tz, trip, _temp);
>> +if (ret)
>> +return ret;
>> +
>> +mutex_lock(>lock);
>> +temp = tz->temperature;
>> +last_temp = tz->last_temperature;
>> +mutex_unlock(>lock);
>> +
>> +if (temp > trip_temp) {
>> +if (temp >= last_temp)
>> +*trend = THERMAL_TREND_RAISING;
>> +else
>> +*trend = THERMAL_TREND_STABLE;
>> +} else if (temp < trip_temp) {
>> +*trend = THERMAL_TREND_DROPPING;
>> +} else {
>> +*trend = THERMAL_TREND_STABLE;
>> +}
>> +
>> +return 0;
>> +}
>
> This looks like a reimplementation of the get_tz_trend() helper. Is
> seems like that helper already has everything we need. Perhaps this
> isn't working because of-thermal installs of_thermal_get_trend(), a
> function that returns -EINVAL if the driver doesn't implement the
> ->get_trend() callback.
1. The get_tz_trend() helper can work, because it has:
if (tz->emul_temperature || !tz->ops->get_trend ||
tz->ops->get_trend(tz, trip, )) {
...
}
the tz->ops->get_trend is of_thermal_get_trend(). If without special
get_trend(), it will return -EINVAL, so it will implement the if block
to get the "trend". If we have the special get_trend(), then the
of_thermal_get_trend() will return 0, so this helper will not implement
the if block, it will get the "trend" from the special get_trend().
>>>
>>> The idea of the helper is to provide a trend in case drivers dont have
>>> a specific way of doing so.
>>
>> Yes, thanks for your explanation.
>>
>>>
2. There has a little difference between the helper and our special
callback. The tegra_thermctl_get_trend() consider the trip_temp, but the
get_tz_trend() helper didn't.
>>>
>>> Yeah, if you are computing trend towards a trip, then yes, that is
>>> different and this patch is needed.
>>>
>
> Perhaps a better way would be to do something like this in
> thermal_zone_of_add_sensor():
>
> if (ops->get_trend)
> tzd->ops->get_trend = of_thermal_get_trend;
>
> That's similar to how ->set_trips() and ->set_emul_temp() are set up
> and should make sure that get_tz_trend() will do the right thing for
> all drivers that don't implement a special ->get_trend().
As above description, I think the of_thermal_get_trend() already can
handle this case, doesn't need to change.
Wei.
>
> Thierry
>
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On Sat, Dec 08, 2018 at 10:09:26AM -0800, Dan Williams wrote:
> On Sat, Dec 8, 2018 at 8:48 AM Christoph Hellwig wrote:
> >
> > On Sat, Dec 08, 2018 at 11:33:53AM -0500, Jerome Glisse wrote:
> > > Patchset to use HMM inside nouveau have already been posted, some
> > > of the bits have already made upstream and more are line up for
> > > next merge window.
> >
> > Even with that it is a relative fringe feature compared to making
> > something like get_user_pages() that is literally used every to actually
> > work properly.
> >
> > So I think we need to kick out HMM here and just find another place for
> > it to store data.
> >
> > And just to make clear that I'm not picking just on this - the same is
> > true to a just a little smaller extent for the pgmap..
>
> Fair enough, I cringed as I took a full pointer for that use case, I'm
> happy to look at ways of consolidating or dropping that usage.
>
> Another fix that may put pressure 'struct page' is resolving the
> untenable situation of dax being incompatible with reflink, i.e.
> reflink currently requires page-cache pages. Dave has talked about
> silently establishing page-cache entries when a dax-page is cow'd for
> reflink,
I think you've got it the wrong way around there :)
Think of a set of files with the following physical block mappings:
index 0 1 2 3 4 5
inode W A B C D E F
inode X B C D E F A
inode Y C D E F A B
inode Z D E F A B C
Basically, each block has 4 references (one from each file), and
each reference to a block is from a diffent file offset. Now, with
DAX, each inode wants to put the same struct page into their own
address space mapping tree but have different page indexes.
i.e. for block A, inode W wants page->index = 0, X wants 5, Y wants
4 and Z wants 3.
This is not possible with a single struct page and where the
problem with DAX, struct pages and physically shared data lies.
This is where the page cache is currently required - each mapping
gets it's own copy of the shared block in volatile RAM, but when
sharing is broken (by COW) we can toss the volatile copy and go back
to using DAX for the newly allocated, single owner {block, struct
page} tuple that replaces the shared page.
> but I wonder if we could go the other way and introduce the
> mechanism of a page belonging to multiple mappings simultaneously and
> managed by the filesystem.
That's pretty much what I suggested at LSFMM. We do lookups for
shared extent mappings through the filesystem buffer cache (which is
indexed by physical location) and hold the primary struct page in
the filesystem buffer cache. We then hand out dynamically allocated
struct pages back to the caller that point to the same physical page
and place them in each inode's address space. When a write fault
occurs, we allocate a new block, grab the physical struct page, copy
the data across, and release the dynamically allocated read-only
struct page and reference to the primary struct page held in the
filesytem buffer cache.
It's essentially the same model "cached page per inode address
space" as using volatile RAM copies via the page cache, except
the struct pages point back to the same physical location rather
than having their own temporary, volatile copy of the data.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
[PATCH] nbd:clear NBD_BOUND flag when NBD connection is closed
From: Medad
If we do NOT clear NBD_BOUND flag when NBD connection is closed,
then the original NBD device could not be used again.
Signed-off-by: Medad
---
drivers/block/nbd.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 64278f4..5c88490 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -277,10 +277,14 @@ static void sock_shutdown(struct nbd_device *nbd)
struct nbd_config *config = nbd->config;
int i;
- if (config->num_connections == 0)
+ if (config->num_connections == 0) {
+ clear_bit(NBD_BOUND, >runtime_flags);
return;
- if (test_and_set_bit(NBD_DISCONNECTED, >runtime_flags))
+ }
+ if (test_and_set_bit(NBD_DISCONNECTED, >runtime_flags)) {
+ clear_bit(NBD_BOUND, >runtime_flags);
return;
+ }
for (i = 0; i < config->num_connections; i++) {
struct nbd_sock *nsock = config->socks[i];
@@ -944,7 +948,7 @@ static int nbd_reconnect_socket(struct nbd_device *nbd,
unsigned long arg)
sockfd_put(old);
clear_bit(NBD_DISCONNECTED, >runtime_flags);
-
+ clear_bit(NBD_BOUND, >runtime_flags);
/* We take the tx_mutex in an error path in the recv_work, so we
* need to queue_work outside of the tx_mutex.
*/
@@ -1020,6 +1024,7 @@ static int nbd_disconnect(struct nbd_device *nbd)
dev_info(disk_to_dev(nbd->disk), "NBD_DISCONNECT\n");
set_bit(NBD_DISCONNECT_REQUESTED, >runtime_flags);
send_disconnects(nbd);
+ clear_bit(NBD_BOUND, >runtime_flags);
return 0;
}
--
2.7.4
Re: [PATCH 28/52] Do fallocate() to grow file before mapping for file growing writes
Hi Vivek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on fuse/for-next]
[also build test WARNING on v4.20-rc6]
[cannot apply to next-20181210]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Vivek-Goyal/virtio-fs-shared-file-system-for-virtual-machines/20181211-103034
base: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
for-next
config: i386-randconfig-x005-201849 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
fs/fuse/file.c: In function 'fuse_dax_write_iter':
>> fs/fuse/file.c:1834:47: warning: format '%lx' expects argument of type 'long
>> unsigned int', but argument 3 has type 'size_t {aka unsigned int}'
>> [-Wformat=]
printk("fallocate(offset=0x%llx length=0x%lx)"
~~^
%x
fs/fuse/file.c:1836:4:
iov_iter_count(from), ret);
>> fs/fuse/file.c:1834:11: warning: format '%ld' expects argument of type 'long
>> int', but argument 4 has type 'ssize_t {aka int}' [-Wformat=]
printk("fallocate(offset=0x%llx length=0x%lx)"
^~~
fs/fuse/file.c:1835:20: note: format string is defined here
" failed. err=%ld\n", iocb->ki_pos,
~~^
%d
In file included from include/linux/kernel.h:14:0,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from fs/fuse/fuse_i.h:13,
from fs/fuse/file.c:9:
fs/fuse/file.c:1839:12: warning: format '%lx' expects argument of type 'long
unsigned int', but argument 4 has type 'size_t {aka unsigned int}' [-Wformat=]
pr_debug("fallocate(offset=0x%llx length=0x%lx)"
^
include/linux/printk.h:292:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:340:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~
>> fs/fuse/file.c:1839:3: note: in expansion of macro 'pr_debug'
pr_debug("fallocate(offset=0x%llx length=0x%lx)"
^~~~
fs/fuse/file.c:1839:48: note: format string is defined here
pr_debug("fallocate(offset=0x%llx length=0x%lx)"
~~^
%x
In file included from include/linux/kernel.h:14:0,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from fs/fuse/fuse_i.h:13,
from fs/fuse/file.c:9:
fs/fuse/file.c:1839:12: warning: format '%ld' expects argument of type 'long
int', but argument 5 has type 'ssize_t {aka int}' [-Wformat=]
pr_debug("fallocate(offset=0x%llx length=0x%lx)"
^
include/linux/printk.h:292:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:340:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~
>> fs/fuse/file.c:1839:3: note: in expansion of macro 'pr_debug'
pr_debug("fallocate(offset=0x%llx length=0x%lx)"
^~~~
fs/fuse/file.c:1840:20: note: format string is defined here
" succeed. ret=%ld\n", iocb->ki_pos, iov_iter_count(from), ret);
~~^
%d
Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_read
Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_write
Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:set_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:__set_bit
Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:clear_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:__clear_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:test_and_set_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:test_and_set_bit_lock
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:constant_test_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
Cyclomatic Complexity 1 include/l
Re: [PATCH 0/2] Graph fixes for using multiple endpoints per port
Hi Tony
> > And, your [2/2] patch,
> > I guess you are misunderstanding about "port" vs "endpoint",
> > or omap-mcbsp driver side need to update ?
>
> Yes omap-mcbsp driver needs to be updated for multiple endpoints.
>
> Adding Jarkko and Peter also to Cc, below is the WIP patch that I'm
> currently using for omap-mcbsp to add more DAIs.
>
> So far nothing else to do in the omap-mcbsp as it's the cpcap hardware
> that configures the TDM timeslots. And I'm currently assuming the
> first instance is the master, I guess that should be parsed from the
> the frame-master dts property instead.
(snip)
> + if (np)
> + mcbsp->dai_count = of_graph_get_endpoint_count(np);
OK, you have multi DAI.
Then, you need to count is "port", not "endpoint".
So, your DT will be below.
You want to have is *1 for asoc_simple_card_get_dai_id().
You want to double check is *2 (maybe).
ports {
mcbsp3_port0: port@0 {
*1 reg = <0>;
cpu_dai3: endpoint {
dai-format = "dsp_a";
frame-master = <_audio_codec1>;
bitclock-master = <_audio_codec1>;
remote-endpoint = <_audio_codec1>;
};
};
mcbsp3_port1: port@1 {
*1 reg = <1>;
cpu_dai_mdm: endpoint {
dai-format = "dsp_a";
*2 frame-master = <_audio_codec1>;
*2 bitclock-master = <_audio_codec1>;
remote-endpoint = <_mdm6600_audio_codec0>;
};
};
};
Best regards
---
Kuninori Morimoto
Re: [PATCH v16 06/16] lib: fdt: add a helper function for handling memory range property
James, On Fri, Dec 07, 2018 at 10:12:47AM +, James Morse wrote: > Hi Akashi, Will, > > On 06/12/2018 15:54, Will Deacon wrote: > > On Thu, Dec 06, 2018 at 08:47:04AM -0600, Rob Herring wrote: > >> On Wed, Nov 14, 2018 at 11:52 PM AKASHI Takahiro > >> wrote: > >>> > >>> Added function, fdt_setprop_reg(), will be used later to handle > >>> kexec-specific property in arm64's kexec_file implementation. > >>> It will possibly be merged into libfdt in the future. > >> > >> You generally can't modify libfdt files. Any changes will be blown > >> away with the next dtc sync (there's one in -next now). Though here > >> you are creating a new location with fdt code. lib/ is just a shim to > >> the actual libfdt code. Don't put any implementation there. You can > >> add this to drivers/of/fdt_address.c for the short term, but it still > >> needs to go upstream. > >> > >> Otherwise, the implementation looks fine to me. > > > > I agree, but I don't think there's a real need for us to hack > > drivers/of/fdt_address.c in the meantime -- let's just target upstream > > and not carry this in the kernel. > > > > Akashi -- for now, I'll drop the kdump parts of this series which rely > > on this helper. The majority of the series is actually independent and > > can go in as-is. > > > > I've pushed out a kexec branch to the arm64 tree for you to take a look > > at: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kexec > > I gave this a quick spin. Without the elfcorehdr/usable-memory-range arm64 > needs > to explicitly forbid kdump via kexec_file_load. (like powerpc does already). Thank you for pointing this out. > Without this kdump works, but the second kernel overwrites the first as those > DT > properties are missing. > > I'll post a patch momentarily, Fine, but anyhow I'm going to submit a new version (*without* kdump), I will fix the issue along with others. -Takahiro Akashi > > Thanks, > > James >
Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
Hi all,
[Sent to early with people missing ...]
On Tue, 11 Dec 2018 17:11:02 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/arm64/mm/proc.S
>
> between commits:
>
> 67e7fdfcc682 ("arm64: mm: introduce 52-bit userspace support")
> 68d23da4373a ("rm64: Kconfig: Re-jig CONFIG options for 52-bit VA")
>
> from the arm64 tree and commit:
>
> 089dc516f651 ("kasan, arm64: enable top byte ignore for the kernel")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/mm/proc.S
> index e05b3ce1db6b,d861f208eeb1..73886a5f1f30
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@@ -449,16 -451,8 +455,16 @@@ ENTRY(__cpu_setup
>*/
> ldr x10, =TCR_TxSZ(VA_BITS) | TCR_CACHE_FLAGS | TCR_SMP_FLAGS | \
> TCR_TG_FLAGS | TCR_KASLR_FLAGS | TCR_ASID16 | \
> - TCR_TBI0 | TCR_A1
> + TCR_TBI0 | TCR_A1 | TCR_KASAN_FLAGS
> -tcr_set_idmap_t0sz x10, x9
> +
> +#ifdef CONFIG_ARM64_USER_VA_BITS_52
> +ldr_l x9, vabits_user
> +sub x9, xzr, x9
> +add x9, x9, #64
> +#else
> +ldr_l x9, idmap_t0sz
> +#endif
> +tcr_set_t0szx10, x9
>
> /*
>* Set the IPS bits in TCR_EL1.
--
Cheers,
Stephen Rothwell
pgpU_HR0McLrt.pgp
Description: OpenPGP digital signature
Re: [PATCH 31/52] dax: Pass dax_dev to dax_writeback_mapping_range()
Hi Vivek,
I love your patch! Yet something to improve:
[auto build test ERROR on fuse/for-next]
[also build test ERROR on v4.20-rc6]
[cannot apply to next-20181210]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Vivek-Goyal/virtio-fs-shared-file-system-for-virtual-machines/20181211-103034
base: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
for-next
config: i386-randconfig-x006-201849 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
fs//ext2/inode.c: In function 'ext2_dax_writepages':
>> fs//ext2/inode.c:959:33: error: passing argument 3 of
>> 'dax_writeback_mapping_range' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
mapping->host->i_sb->s_bdev, wbc);
^~~
In file included from fs//ext2/inode.c:29:0:
include/linux/dax.h:120:19: note: expected 'struct dax_device *' but
argument is of type 'struct writeback_control *'
static inline int dax_writeback_mapping_range(struct address_space *mapping,
^~~
>> fs//ext2/inode.c:958:9: error: too few arguments to function
>> 'dax_writeback_mapping_range'
return dax_writeback_mapping_range(mapping,
^~~
In file included from fs//ext2/inode.c:29:0:
include/linux/dax.h:120:19: note: declared here
static inline int dax_writeback_mapping_range(struct address_space *mapping,
^~~
cc1: some warnings being treated as errors
vim +/dax_writeback_mapping_range +959 fs//ext2/inode.c
7f6d5b52 Ross Zwisler 2016-02-26 954
fb094c90 Dan Williams 2017-12-21 955 static int
fb094c90 Dan Williams 2017-12-21 956 ext2_dax_writepages(struct
address_space *mapping, struct writeback_control *wbc)
fb094c90 Dan Williams 2017-12-21 957 {
fb094c90 Dan Williams 2017-12-21 @958 return
dax_writeback_mapping_range(mapping,
fb094c90 Dan Williams 2017-12-21 @959
mapping->host->i_sb->s_bdev, wbc);
^1da177e Linus Torvalds 2005-04-16 960 }
^1da177e Linus Torvalds 2005-04-16 961
:: The code at line 959 was first introduced by commit
:: fb094c90748fbeba1063927eeb751add147b35b9 ext2, dax: introduce
ext2_dax_aops
:: TO: Dan Williams
:: CC: Dan Williams
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] mfd: cros_ec_dev: Add missing mfd_remove_devices() call in remove
On Mon, 10 Dec 2018, Enric Balletbo i Serra wrote:
> The driver adds different MFD child devices via mfd_add_devices() and
> hence it is required to call mfd_remove_devices() to remove MFD child
> devices.
>
> Fixes: 5e0115581bbc ("cros_ec: Move cros_ec_dev module to drivers/mfd")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Enric Balletbo i Serra
> ---
> Hi Lee,
>
> I saw that you send a mfd-fixes pull request this morning, so sorry in
> advance for sending this too late. This was broken since the driver
> moved from platform/chrome to mfd (and probably before that), so
> it's an old problem. Note that I plan to send a patch series that depends
> on this to apply cleanly. If the patch is fine with you and there is any
> possibility to go in this version that will be good, if not, let me know
> if you prefer queue this in your for-next branch or if you prefer I
> include the patch on the series I plan to send on top of it to not mess
> things.
It wouldn't have made the v4.20-rcs anyway. Even if you did send it
earlier. I only send fixes to that -rcs which fix issues introduced
during the current release cycle.
If memory serves, doesn't this driver now (or will in the very near
future) use devm_* for device creation? That would make this patch
either incorrect (should be devm_mfd_remove_devices() if really
required) or moot?
> drivers/mfd/cros_ec_dev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index b99a194ce5a4..2d0fee488c5a 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -499,6 +499,7 @@ static int ec_device_remove(struct platform_device *pdev)
>
> cros_ec_debugfs_remove(ec);
>
> + mfd_remove_devices(ec->dev);
> cdev_del(>cdev);
> device_unregister(>class_dev);
> return 0;
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
linux-next: manual merge of the akpm-current tree with the FIXME tree
Hi Andrew,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/arm64/mm/proc.S
between commits:
67e7fdfcc682 ("arm64: mm: introduce 52-bit userspace support")
68d23da4373a ("rm64: Kconfig: Re-jig CONFIG options for 52-bit VA")
from the FIXME tree and commit:
089dc516f651 ("kasan, arm64: enable top byte ignore for the kernel")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/mm/proc.S
index e05b3ce1db6b,d861f208eeb1..73886a5f1f30
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@@ -449,16 -451,8 +455,16 @@@ ENTRY(__cpu_setup
*/
ldr x10, =TCR_TxSZ(VA_BITS) | TCR_CACHE_FLAGS | TCR_SMP_FLAGS | \
TCR_TG_FLAGS | TCR_KASLR_FLAGS | TCR_ASID16 | \
- TCR_TBI0 | TCR_A1
+ TCR_TBI0 | TCR_A1 | TCR_KASAN_FLAGS
- tcr_set_idmap_t0sz x10, x9
+
+#ifdef CONFIG_ARM64_USER_VA_BITS_52
+ ldr_l x9, vabits_user
+ sub x9, xzr, x9
+ add x9, x9, #64
+#else
+ ldr_l x9, idmap_t0sz
+#endif
+ tcr_set_t0szx10, x9
/*
* Set the IPS bits in TCR_EL1.
pgp0MmWwZKBkF.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 2/3] dt-bindings: bus: imx-weim: document multiple address ranges per child node
On Thu, Dec 06, 2018 at 02:26:32PM -0500, Sven Van Asbroeck wrote: > The imx-weim driver was patched to allow correct WEIM configuration > when multiple address ranges are used in a child node. > Update the dt-bindings to reflect this. > > Signed-off-by: Sven Van Asbroeck The bindings patch should go first in the series. Shawn
Re: [PATCH v3 1/3] bus: imx-weim: support multiple address ranges per child node
On Thu, Dec 06, 2018 at 02:26:31PM -0500, Sven Van Asbroeck wrote:
> Ensure that timing values for the child node are applied to
> all chip selects in the child's address ranges.
>
> Note that this does not support multiple timing settings per
> child; this can be added in the future if required.
>
> Example:
> {
> acme@0 {
> compatible = "acme,whatever";
> reg = <0 0 0x100>, <0 0x40 0x800>,
> <1 0x40 0x800>;
> fsl,weim-cs-timing = <0x024400b1 0x1010 0x20081100
> 0x 0xa240 0x>;
> };
> };
>
> Signed-off-by: Sven Van Asbroeck
> ---
> drivers/bus/imx-weim.c | 36 +---
> 1 file changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index d84996a4528e..5452d22d1bd8 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -46,6 +46,7 @@ static const struct imx_weim_devtype imx51_weim_devtype = {
> };
>
> #define MAX_CS_REGS_COUNT6
> +#define OF_REG_SIZE 3
>
> static const struct of_device_id weim_id_table[] = {
> /* i.MX1/21 */
> @@ -115,27 +116,40 @@ static int __init weim_timing_setup(struct device_node
> *np, void __iomem *base,
> const struct imx_weim_devtype *devtype)
> {
> u32 cs_idx, value[MAX_CS_REGS_COUNT];
> - int i, ret;
> + int i, ret, reg_idx, num_regs;
As the new variables are not strictly related to the existing ones, they
can be on a new line for cleaner diff log. And to keep the reverse-tree
order, it will look like the following.
int reg_idx, num_regs;
int i, ret;
>
> if (WARN_ON(devtype->cs_regs_count > MAX_CS_REGS_COUNT))
> return -EINVAL;
>
> - /* get the CS index from this child node's "reg" property. */
> - ret = of_property_read_u32(np, "reg", _idx);
> + ret = of_property_read_u32_array(np, "fsl,weim-cs-timing",
> + value, devtype->cs_regs_count);
> if (ret)
> return ret;
>
> - if (cs_idx >= devtype->cs_count)
> + /*
> + * the child node's "reg" property may contain multiple address ranges,
> + * extract the chip select for each.
> + */
> + num_regs = of_property_count_elems_of_size(np, "reg", OF_REG_SIZE);
> + if (num_regs < 0)
> + return num_regs;
> + if (!num_regs)
> return -EINVAL;
> + for (reg_idx = 0; reg_idx < num_regs; reg_idx++) {
> + /* get the CS index from this child node's "reg" property. */
> + ret = of_property_read_u32_index(np, "reg",
> + reg_idx*OF_REG_SIZE, _idx);
There should be space before and after *.
Shawn
> + if (ret)
> + break;
>
> - ret = of_property_read_u32_array(np, "fsl,weim-cs-timing",
> - value, devtype->cs_regs_count);
> - if (ret)
> - return ret;
> + if (cs_idx >= devtype->cs_count)
> + return -EINVAL;
>
> - /* set the timing for WEIM */
> - for (i = 0; i < devtype->cs_regs_count; i++)
> - writel(value[i], base + cs_idx * devtype->cs_stride + i * 4);
> + /* set the timing for WEIM */
> + for (i = 0; i < devtype->cs_regs_count; i++)
> + writel(value[i],
> + base + cs_idx * devtype->cs_stride + i * 4);
> + }
>
> return 0;
> }
> --
> 2.17.1
>
Re: [PATCHv2 02/12] acpi/hmat: Parse and report heterogeneous memory
On Mon, Dec 10, 2018 at 5:05 PM Keith Busch wrote:
>
> Systems may provide different memory types and export this information
> in the ACPI Heterogeneous Memory Attribute Table (HMAT). Parse these
> tables provided by the platform and report the memory access and caching
> attributes.
>
> Signed-off-by: Keith Busch
> ---
> drivers/acpi/Kconfig | 8 +++
> drivers/acpi/Makefile | 1 +
> drivers/acpi/hmat.c | 192
> ++
> drivers/acpi/tables.c | 9 +++
> include/linux/acpi.h | 1 +
> 5 files changed, 211 insertions(+)
> create mode 100644 drivers/acpi/hmat.c
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 7cea769c37df..9a05af3a18cf 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -327,6 +327,14 @@ config ACPI_NUMA
> depends on (X86 || IA64 || ARM64)
> default y if IA64_GENERIC || IA64_SGI_SN2 || ARM64
>
> +config ACPI_HMAT
> + bool "ACPI Heterogeneous Memory Attribute Table Support"
> + depends on ACPI_NUMA
> + help
> +Parses representation of the ACPI Heterogeneous Memory Attributes
> +Table (HMAT) and set the memory node relationships and access
> +attributes.
> +
> config ACPI_CUSTOM_DSDT_FILE
> string "Custom DSDT Table file to include"
> default ""
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index edc039313cd6..b5e13499f88b 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -55,6 +55,7 @@ acpi-$(CONFIG_X86)+= x86/apple.o
> acpi-$(CONFIG_X86) += x86/utils.o
> acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
> acpi-$(CONFIG_ACPI_NUMA) += numa.o
> +acpi-$(CONFIG_ACPI_HMAT) += hmat.o
> acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
> acpi-y += acpi_lpat.o
> acpi-$(CONFIG_ACPI_LPIT) += acpi_lpit.o
> diff --git a/drivers/acpi/hmat.c b/drivers/acpi/hmat.c
> new file mode 100644
> index ..ef3881f0f370
> --- /dev/null
> +++ b/drivers/acpi/hmat.c
[..]
> +static __init int hmat_init(void)
> +{
> + struct acpi_subtable_proc subtable_proc;
> + struct acpi_table_header *tbl;
> + enum acpi_hmat_type i;
> + acpi_status status;
> +
> + if (srat_disabled())
> + return 0;
> +
> + status = acpi_get_table(ACPI_SIG_HMAT, 0, );
> + if (ACPI_FAILURE(status))
> + return 0;
> +
> + if (acpi_table_parse(ACPI_SIG_HMAT, parse_noop))
> + goto out_put;
> +
> + memset(_proc, 0, sizeof(subtable_proc));
> + subtable_proc.handler = hmat_parse_subtable;
> + for (i = ACPI_HMAT_TYPE_ADDRESS_RANGE; i < ACPI_HMAT_TYPE_RESERVED;
> i++) {
> + subtable_proc.id = i;
> + if (acpi_table_parse_entries_array(ACPI_SIG_HMAT,
> + sizeof(struct acpi_table_hmat),
> + _proc, 1, 0) < 0)
> + goto out_put;
> + }
> + out_put:
> + acpi_put_table(tbl);
> + return 0;
> +}
> +subsys_initcall(hmat_init);
I have a use case to detect the presence of a memory-side-cache early
at init time [1]. To me this means that hmat_init() needs to happen as
a part of acpi_numa_init(). Subsequently I think that also means that
the sysfs portion needs to be broken out to its own init path that can
probably run at module_init() priority.
Perhaps we should split this patch set into two? The table parsing
with an in-kernel user is a bit easier to reason about and can go in
first. Towards that end can I steal / refllow patches 1 & 2 into the
memory randomization series? Other ideas how to handle this?
[1]: https://lkml.org/lkml/2018/10/12/309
linux-next: manual merge of the akpm-current tree with the arm64 tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/arm64/include/asm/memory.h
between commit:
6e8830674ea7 ("arm64: kasan: Increase stack size for KASAN_EXTRA")
from the arm64 tree and commit:
2a4689e7f69c ("kasan, arm64: adjust shadow size for tag-based mode")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/include/asm/memory.h
index f771452d08c4,1235fa492307..
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@@ -77,19 -65,13 +68,18 @@@
#define KERNEL_END_end
/*
- * KASAN requires 1/8th of the kernel virtual address space for the shadow
- * region. KASAN can bloat the stack significantly, so double the (minimum)
- * stack size when KASAN is in use, and then double it again if KASAN_EXTRA is
- * on.
+ * Generic and tag-based KASAN require 1/8th and 1/16th of the kernel virtual
+ * address space for the shadow region respectively. They can bloat the stack
- * significantly, so double the (minimum) stack size when they are in use.
++ * significantly, so double the (minimum) stack size when they are in use,
++ * and then double it again if KASAN_EXTRA is on.
*/
#ifdef CONFIG_KASAN
- #define KASAN_SHADOW_SCALE_SHIFT 3
#define KASAN_SHADOW_SIZE (UL(1) << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
+#ifdef CONFIG_KASAN_EXTRA
+#define KASAN_THREAD_SHIFT2
+#else
#define KASAN_THREAD_SHIFT1
+#endif /* CONFIG_KASAN_EXTRA */
#else
#define KASAN_SHADOW_SIZE (0)
#define KASAN_THREAD_SHIFT0
pgpJK3giefAyE.pgp
Description: OpenPGP digital signature
[PATCH v10 3/3] ALSA: hda: add support for Huawei WMI micmute LED
Some of Huawei laptops come with a LED in the micmute key. This patch
enables the use of micmute LED for these devices:
1. Matebook X (19e5:3200), (19e5:3201)
2. Matebook X Pro (19e5:3204)
Reviewed-by: Takashi Iwai
Signed-off-by: Ayman Bagabas
---
sound/pci/hda/patch_realtek.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1326f32f4574..9766fd249bdf 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5776,7 +5776,9 @@ static const struct hda_fixup alc269_fixups[] = {
{0x1e, 0x41f0},
{0x21, 0x04211020},
{ }
- }
+ },
+ .chained = true,
+ .chain_id = ALC255_FIXUP_MIC_MUTE_LED
},
[ALC269_FIXUP_ASUS_X101_FUNC] = {
.type = HDA_FIXUP_FUNC,
@@ -6608,6 +6610,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
+ SND_PCI_QUIRK(0x19e5, 0x3200, "Huawei MBX", ALC255_FIXUP_MIC_MUTE_LED),
+ SND_PCI_QUIRK(0x19e5, 0x3201, "Huawei MBX", ALC255_FIXUP_MIC_MUTE_LED),
SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MBXP",
ALC256_FIXUP_HUAWEI_MBXP_PINS),
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ",
ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
--
2.19.2
[PATCH v10 2/3] x86: add support for Huawei WMI hotkeys.
This driver adds support for missing hotkeys on some Huawei laptops.
Laptops such as the Matebook X have non functioning hotkeys. Whereas
newer laptops such as the Matebook X Pro come with working hotkeys out
of the box.
Old laptops, such as the Matebook X, report hotkey events through ACPI
device "\WMI0". However, new laptops, such as the Matebook X Pro,
does not have this WMI device.
All the hotkeys on the Matebook X Pro work fine
without this patch except (micmute, wlan, and huawei key). These keys
and the brightness keys report events to "\AMW0" ACPI device. One
problem is that brightness keys on the Matebook X Pro work without this
patch. This results in reporting two brightness key press
events one is captured by ACPI and another by this driver.
A solution would be to check if such event came from the "\AMW0" WMI driver
then skip reporting event. Another solution would be to leave this to
user-space to handle. Which can be achieved by using "hwdb" tables and
remap those keys to "unknown". This solution seems more natural to me
because it leaves the decision to user-space.
Reviewed-by: Takashi Iwai
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/Kconfig | 17 +++
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/huawei-wmi.c | 220 ++
3 files changed, 238 insertions(+)
create mode 100644 drivers/platform/x86/huawei-wmi.c
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 87f70e8f4dd0..45ef4d22f14c 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1292,6 +1292,23 @@ config INTEL_ATOMISP2_PM
To compile this driver as a module, choose M here: the module
will be called intel_atomisp2_pm.
+config HUAWEI_WMI
+ tristate "Huawei WMI hotkeys driver"
+ depends on ACPI_WMI
+ depends on INPUT
+ select INPUT_SPARSEKMAP
+ select LEDS_CLASS
+ select LEDS_TRIGGERS
+ select LEDS_TRIGGER_AUDIO
+ select NEW_LEDS
+ help
+ This driver provides support for Huawei WMI hotkeys.
+ It enables the missing keys and adds support to the micmute
+ LED found on some of these laptops.
+
+ To compile this driver as a module, choose M here: the module
+ will be called huawei-wmi.
+
endif # X86_PLATFORM_DEVICES
config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 39ae94135406..d841c550e3cc 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ACERHDF) += acerhdf.o
obj-$(CONFIG_HP_ACCEL) += hp_accel.o
obj-$(CONFIG_HP_WIRELESS) += hp-wireless.o
obj-$(CONFIG_HP_WMI) += hp-wmi.o
+obj-$(CONFIG_HUAWEI_WMI) += huawei-wmi.o
obj-$(CONFIG_AMILO_RFKILL) += amilo-rfkill.o
obj-$(CONFIG_GPD_POCKET_FAN) += gpd-pocket-fan.o
obj-$(CONFIG_TC1100_WMI) += tc1100-wmi.o
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
new file mode 100644
index ..89ba7ea33499
--- /dev/null
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -0,0 +1,220 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Huawei WMI hotkeys
+ *
+ * Copyright (C) 2018 Ayman Bagabas
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Huawei WMI GUIDs
+ */
+#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
+#define AMW0_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
+
+#define WMI0_EXPENSIVE_GUID "39142400-C6A3-40fa-BADB-8A2652834100"
+
+struct huawei_wmi_priv {
+ struct input_dev *idev;
+ struct led_classdev cdev;
+ acpi_handle handle;
+ char *acpi_method;
+};
+
+static const struct key_entry huawei_wmi_keymap[] = {
+ { KE_KEY,0x281, { KEY_BRIGHTNESSDOWN } },
+ { KE_KEY,0x282, { KEY_BRIGHTNESSUP } },
+ { KE_KEY,0x284, { KEY_MUTE } },
+ { KE_KEY,0x285, { KEY_VOLUMEDOWN } },
+ { KE_KEY,0x286, { KEY_VOLUMEUP } },
+ { KE_KEY,0x287, { KEY_MICMUTE } },
+ { KE_KEY,0x289, { KEY_WLAN } },
+ // Huawei |M| key
+ { KE_KEY,0x28a, { KEY_CONFIG } },
+ // Keyboard backlight
+ { KE_IGNORE, 0x293, { KEY_KBDILLUMTOGGLE } },
+ { KE_IGNORE, 0x294, { KEY_KBDILLUMUP } },
+ { KE_IGNORE, 0x295, { KEY_KBDILLUMUP } },
+ { KE_END,0 }
+};
+
+static int huawei_wmi_micmute_led_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct huawei_wmi_priv *priv = dev_get_drvdata(led_cdev->dev->parent);
+ acpi_status status;
+ union acpi_object args[3];
+ struct acpi_object_list arg_list = {
+ .pointer = args,
+ .count = ARRAY_SIZE(args),
+ };
+
+ args[0].type = args[1].type = args[2].type = ACPI_TYPE_INTEGER;
+ args[1].integer.value = 0x04;
+
+ if (strcmp(priv->acpi_method, "SPIN") == 0) {
[PATCH v10 1/3] ALSA: hda: fix front speakers on Huawei MBXP.
This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
https://bugzilla.kernel.org/show_bug.cgi?id=200501
It enables the front speakers on Huawei Matebook X Pro laptops.
These laptops come with Dolby Atmos sound system and these pins
configuration enables the front speakers.
Reviewed-by: Takashi Iwai
Signed-off-by: Ayman Bagabas
---
sound/pci/hda/patch_realtek.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 993d34c141c2..1326f32f4574 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5490,6 +5490,7 @@ enum {
ALC298_FIXUP_TPT470_DOCK,
ALC255_FIXUP_DUMMY_LINEOUT_VERB,
ALC255_FIXUP_DELL_HEADSET_MIC,
+ ALC256_FIXUP_HUAWEI_MBXP_PINS,
ALC295_FIXUP_HP_X360,
ALC221_FIXUP_HP_HEADSET_MIC,
};
@@ -5761,6 +5762,22 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+ [ALC256_FIXUP_HUAWEI_MBXP_PINS] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ {0x12, 0x90a60130},
+ {0x13, 0x4000},
+ {0x14, 0x90170110},
+ {0x18, 0x41f0},
+ {0x19, 0x04a11040},
+ {0x1a, 0x41f0},
+ {0x1b, 0x90170112},
+ {0x1d, 0x40759a05},
+ {0x1e, 0x41f0},
+ {0x21, 0x04211020},
+ { }
+ }
+ },
[ALC269_FIXUP_ASUS_X101_FUNC] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc269_fixup_x101_headset_mic,
@@ -6591,6 +6608,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
+ SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MBXP",
ALC256_FIXUP_HUAWEI_MBXP_PINS),
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ",
ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
#if 0
--
2.19.2
[PATCH v10 0/3] Huawei laptops
This patch set is based on the new audio LED triggers in topic/leds-trigger branch from git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git Changes in v10: * Use ec_get_handle instead of acpi_get_handle since we are using the ec device * Switch to WMI0_EXPENSIVE_GUID and wmi_query_block to fetch keycode when WMI0 is used Changes in v9: * Explicitly use NULL in acpi_get_handle * Drop __initconst from huawei_wmi_keymap Changes in v8: * Switch to wmi_driver * Use devm to allocate and manage devices * Skip registering LED subsystem if a ACPI controller method was not found Changes in v7: * Use audio LED triggers patch set * Use KEY_CONFIG (XF86Tools) instead of KEY_PROG1. In Windows, the key is used to launch Huawei PC manager. XF86Tools is used by default on most desktop environments i.e. Gnome. Changes in v6: * Review tags Changes in v5: * Consistency in file names * How module would be enabled (Kconfig) * Match license in SPDX and MODULE_LICENSE Changes in v4: * Code formatting Changes in v3: * Support for Huawei MBX * Style and formatting issues Ayman Bagabas (3): ALSA: hda: fix front speakers on Huawei MBXP. x86: add support for Huawei WMI hotkeys. ALSA: hda: add support for Huawei WMI micmute LED drivers/platform/x86/Kconfig | 17 +++ drivers/platform/x86/Makefile | 1 + drivers/platform/x86/huawei-wmi.c | 220 ++ sound/pci/hda/patch_realtek.c | 22 +++ 4 files changed, 260 insertions(+) create mode 100644 drivers/platform/x86/huawei-wmi.c -- 2.19.2
Re: [PATCH net-next] ieee802154: ca8210: fix possible u8 overflow in ca8210_rx_done
From: YueHaibing
Date: Tue, 11 Dec 2018 11:13:39 +0800
> gcc warning this:
>
> drivers/net/ieee802154/ca8210.c:730:10: warning:
> comparison is always false due to limited range of data type [-Wtype-limits]
>
> 'len' is u8 type, we get it from buf[1] adding 2, which can overflow.
> This patch change the type of 'len' to unsigned int to avoid this,also fix
> the gcc warning.
>
> Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
> Signed-off-by: YueHaibing
WPAN maintainers, I am assuming that as maintainers you will be
picking this up and sending it to me.
Re: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: Add MMC/SD support
On 07/12/18 2:12 PM, Faiz Abbas wrote:
> On the am654x-evm, sdhci0 node is connected to an eMMC while sdhci1
> is connected to an SD card slot. Add nodes and pinmuxes for the same.
>
> Signed-off-by: Faiz Abbas
> ---
> .../arm64/boot/dts/ti/k3-am654-base-board.dts | 46 +++
> 1 file changed, 46 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> index bd5a0069191d..5dcd16b787eb 100644
> --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> @@ -60,6 +60,36 @@
> AM65X_IOPAD(0x0070, PIN_INPUT, 5) /* (R25)
> GPMC0_CSn2.I2C2_SDA */
> >;
> };
> +
> + main_mmc0_pins_default: main_mmc0_pins_default {
make dtbs W=12 will warn you:
Character '_' not recommended in node name
> + pinctrl-single,pins = <
> + AM65X_IOPAD(0x01a8, PIN_INPUT_PULLDOWN, 0) /* (B25)
> MMC0_CLK */
> + AM65X_IOPAD(0x01ac, PIN_INPUT_PULLUP, 0) /* (B27)
> MMC0_CMD */
> + AM65X_IOPAD(0x01a4, PIN_INPUT_PULLUP, 0) /* (A26)
> MMC0_DAT0 */
> + AM65X_IOPAD(0x01a0, PIN_INPUT_PULLUP, 0) /* (E25)
> MMC0_DAT1 */
> + AM65X_IOPAD(0x019c, PIN_INPUT_PULLUP, 0) /* (C26)
> MMC0_DAT2 */
> + AM65X_IOPAD(0x0198, PIN_INPUT_PULLUP, 0) /* (A25)
> MMC0_DAT3 */
> + AM65X_IOPAD(0x0194, PIN_INPUT_PULLUP, 0) /* (E24)
> MMC0_DAT4 */
> + AM65X_IOPAD(0x0190, PIN_INPUT_PULLUP, 0) /* (A24)
> MMC0_DAT5 */
> + AM65X_IOPAD(0x018c, PIN_INPUT_PULLUP, 0) /* (B26)
> MMC0_DAT6 */
> + AM65X_IOPAD(0x0188, PIN_INPUT_PULLUP, 0) /* (D25)
> MMC0_DAT7 */
> + AM65X_IOPAD(0x01b4, PIN_INPUT_PULLUP, 0) /* (A23)
> MMC0_SDCD */
> + AM65X_IOPAD(0x01b0, PIN_INPUT, 0) /* (C25) MMC0_DS */
> + >;
> + };
> +
> + main_mmc1_pins_default: main_mmc1_pins_default {
Same here
Regards
Vignesh
> + pinctrl-single,pins = <
> + AM65X_IOPAD(0x02d4, PIN_INPUT_PULLDOWN, 0) /* (C27)
> MMC1_CLK */
> + AM65X_IOPAD(0x02d8, PIN_INPUT_PULLUP, 0) /* (C28)
> MMC1_CMD */
> + AM65X_IOPAD(0x02d0, PIN_INPUT_PULLUP, 0) /* (D28)
> MMC1_DAT0 */
> + AM65X_IOPAD(0x02cc, PIN_INPUT_PULLUP, 0) /* (E27)
> MMC1_DAT1 */
> + AM65X_IOPAD(0x02c8, PIN_INPUT_PULLUP, 0) /* (D26)
> MMC1_DAT2 */
> + AM65X_IOPAD(0x02c4, PIN_INPUT_PULLUP, 0) /* (D27)
> MMC1_DAT3 */
> + AM65X_IOPAD(0x02dc, PIN_INPUT_PULLUP, 0) /* (B24)
> MMC1_SDCD */
> + AM65X_IOPAD(0x02e0, PIN_INPUT, 0) /* (C24) MMC1_SDWP */
> + >;
> + };
> };
>
> _pmx1 {
> @@ -125,3 +155,19 @@
> pinctrl-0 = <_i2c2_pins_default>;
> clock-frequency = <40>;
> };
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_mmc0_pins_default>;
> + bus-width = <8>;
> + non-removable;
> + ti,driver-strength-ohm = <50>;
> +};
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_mmc1_pins_default>;
> + ti,driver-strength-ohm = <50>;
> +};
>
--
Regards
Vignesh
Re: [PATCH v5 0/3] Fixes for Tegra soctherm
Hi Rui & Eduardo, It looks no more comments on this version, could you please take this serial? Thanks. Wei. On 5/12/2018 4:31 PM, Wei Ni wrote: > Hi, > Does there have any comments on this serial? > > Thanks. > Wei. > > On 3/12/2018 1:55 PM, Wei Ni wrote: >> This series fixed some issues for Tegra soctherm >> >> Main changes from v4: >> 1. fixed for the parsing sensor id. >> 2. keep warning for missing critical trips. >> >> Main changes from v3: >> 1. updated codes for parsing sensor id, per Thierry's comments >> >> Main changes from v2: >> 1. add codes to parse sensor id to avoid registration >> failure. >> >> Main changes from v1: >> 1. Acked by Thierry Reding for the patch >> "thermal: tegra: fix memory allocation". >> 2. Print out the sensor name when register failed. >> 2. Remove patch "thermal: tegra: fix coverity defect" >> >> Wei Ni (3): >> thermal: tegra: remove unnecessary warnings >> thermal: tegra: fix memory allocation >> thermal: tegra: parse sensor id before sensor register >> >> drivers/thermal/tegra/soctherm.c | 51 >> >> 1 file changed, 46 insertions(+), 5 deletions(-) >>
Re: [PATCH v1] binder: implement binderfs(Internet mail)
On Tue, Dec 11, 2018 at 03:44:48AM +, chouryzhou(周威) wrote: > > chouryzhou@, can you confirm that this implementation works for your > > android-in-container use-case? > > > > -Todd > > > We are running Android Pie in container now. If it works for later Android > release, it will works for us. The patchset is absolutely agnostic as to what Android version is running. :) It has no userspace consequences. If at all it makes it possible for Android to upgrade its userspace to use additional devices in the future without having to recompile the kernel. There's a whole lot of interesting things one could potentially do with this. :)
Re: [PATCH 00/18] my generic mmu_gather patches
Peter Zijlstra writes: > Hi, > > Here is my current stash of generic mmu_gather patches that goes on top of > Will's > tlb patches: > > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git > tlb/asm-generic > > And they include the s390 patches done by Heiko. At the end of this, there is > not a single arch left with a custom mmu_gather. > > I've been slow posting these, because the 0-day bot seems to be having trouble > and I've not been getting the regular cross-build green light emails that I > otherwise rely upon. > > I hope to have addressed all the feedback from the last time, and I've added a > bunch of missing Cc's from last time. > > Please review with care. What is the update with this patch series? Looks good to be merged upstream? You can also add Reviewed-by: Aneesh Kumar K.V to the series. -aneesh
Re: [PATCH] test_rhashtable: remove semaphore usage
On Mon, Dec 10, 2018 at 10:17:20PM +0100, Arnd Bergmann wrote:
> This is one of only two files that initialize a semaphore to a negative
> value. We don't really need the two semaphores here at all, but can do
> the same thing in more conventional and more effient way, by using a
> single waitqueue and an atomic thread counter.
>
> This gets us a little bit closer to eliminating classic semaphores from
> the kernel. It also fixes a corner case where we fail to continue after
> one of the threads fails to start up.
>
> An alternative would be to use a split kthread_create()+wake_up_process()
> and completely eliminate the separate synchronization.
>
> Signed-off-by: Arnd Bergmann
> ---
> This is part of a longer, untested, series to remove semaphores
> from the kernel, please review as such before applying.
> ---
> lib/test_rhashtable.c | 28
> 1 file changed, 16 insertions(+), 12 deletions(-)
This was created by Phil Sutter so I am adding him to the cc list.
> diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c
> index 18de5ff1255b..12bdea4f6c20 100644
> --- a/lib/test_rhashtable.c
> +++ b/lib/test_rhashtable.c
> @@ -20,11 +20,11 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> #include
> +#include
>
> #define MAX_ENTRIES 100
> #define TEST_INSERT_FAIL INT_MAX
> @@ -112,7 +112,8 @@ static struct rhashtable_params test_rht_params_dup = {
> .automatic_shrinking = false,
> };
>
> -static struct semaphore prestart_sem, startup_sem;
> +static atomic_t startup_count;
> +static DECLARE_WAIT_QUEUE_HEAD(startup_wait);
>
> static int insert_retry(struct rhashtable *ht, struct test_obj *obj,
> const struct rhashtable_params params)
> @@ -635,8 +636,9 @@ static int threadfunc(void *data)
> int i, step, err = 0, insert_retries = 0;
> struct thread_data *tdata = data;
>
> - up(_sem);
> - if (down_interruptible(_sem))
> + if (atomic_dec_and_test(_count))
> + wake_up(_wait);
> + if (wait_event_interruptible(startup_wait, atomic_read(_count)
> == -1))
> pr_err(" thread[%d]: down_interruptible failed\n", tdata->id);
>
> for (i = 0; i < tdata->entries; i++) {
> @@ -756,8 +758,7 @@ static int __init test_rht_init(void)
>
> pr_info("Testing concurrent rhashtable access from %d threads\n",
> tcount);
> - sema_init(_sem, 1 - tcount);
> - sema_init(_sem, 0);
> + atomic_set(_count, tcount);
> tdata = vzalloc(array_size(tcount, sizeof(struct thread_data)));
> if (!tdata)
> return -ENOMEM;
> @@ -783,15 +784,18 @@ static int __init test_rht_init(void)
> tdata[i].objs = objs + i * entries;
> tdata[i].task = kthread_run(threadfunc, [i],
> "rhashtable_thrad[%d]", i);
> - if (IS_ERR(tdata[i].task))
> + if (IS_ERR(tdata[i].task)) {
> pr_err(" kthread_run failed for thread %d\n", i);
> - else
> + atomic_dec(_count);
> + } else {
> started_threads++;
> + }
> }
> - if (down_interruptible(_sem))
> - pr_err(" down interruptible failed\n");
> - for (i = 0; i < tcount; i++)
> - up(_sem);
> + if (wait_event_interruptible(startup_wait, atomic_read(_count)
> == 0))
> + pr_err(" wait_event interruptible failed\n");
> + /* count is 0 now, set it to -1 and wake up all threads together */
> + atomic_dec(_count);
> + wake_up_all(_wait);
> for (i = 0; i < tcount; i++) {
> if (IS_ERR(tdata[i].task))
> continue;
> --
> 2.20.0
>
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v16 16/16] arm64: kexec_file: add kaslr support
On Fri, Nov 30, 2018 at 01:19:44PM +, Will Deacon wrote:
> On Thu, Nov 15, 2018 at 02:52:55PM +0900, AKASHI Takahiro wrote:
> > Adding "kaslr-seed" to dtb enables triggering kaslr, or kernel virtual
> > address randomization, at secondary kernel boot. We always do this as
> > it will have no harm on kaslr-incapable kernel.
> >
> > We don't have any "switch" to turn off this feature directly, but still
> > can suppress it by passing "nokaslr" as a kernel boot argument.
> >
> > Signed-off-by: AKASHI Takahiro
> > Cc: Catalin Marinas
> > Cc: Will Deacon
> > ---
> > arch/arm64/kernel/machine_kexec_file.c | 46 +-
> > 1 file changed, 45 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/machine_kexec_file.c
> > b/arch/arm64/kernel/machine_kexec_file.c
> > index ab296b98d633..a0a730bd9be6 100644
> > --- a/arch/arm64/kernel/machine_kexec_file.c
> > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -28,6 +29,7 @@
> > #define FDT_PSTR_INITRD_STA"linux,initrd-start"
> > #define FDT_PSTR_INITRD_END"linux,initrd-end"
> > #define FDT_PSTR_BOOTARGS "bootargs"
> > +#define FDT_PSTR_KASLR_SEED"kaslr-seed"
> >
> > const struct kexec_file_ops * const kexec_file_loaders[] = {
> > _image_ops,
> > @@ -46,11 +48,38 @@ int arch_kimage_file_post_load_cleanup(struct kimage
> > *image)
> > return kexec_image_post_load_cleanup_default(image);
> > }
> >
> > +/* crng needs to have been initialized for providing kaslr-seed */
> > +static int random_ready;
> > +
> > +static void random_ready_notified(struct random_ready_callback *unused)
> > +{
> > + random_ready = 1;
> > +}
> > +
> > +static struct random_ready_callback random_ready_cb = {
> > + .func = random_ready_notified,
> > +};
> > +
> > +static __init int init_random_ready_cb(void)
> > +{
> > + int ret;
> > +
> > + ret = add_random_ready_callback(_ready_cb);
> > + if (ret == -EALREADY)
> > + random_ready = 1;
> > + else if (ret)
> > + pr_warn("failed to add a callback for random_ready\n");
> > +
> > + return 0;
> > +}
> > +late_initcall(init_random_ready_cb)
>
> Why can't we just call crng_ready()?
because crng_ready() is locally defined in drivers/char/random.c.
Instead, I'd like to use
wait_for_random_bytes();
value = get_random_u64();
> > +
> > static int setup_dtb(struct kimage *image,
> > unsigned long initrd_load_addr, unsigned long initrd_len,
> > char *cmdline, void *dtb)
> > {
> > int nodeoffset;
> > + u64 value;
> > int ret;
> >
> > nodeoffset = fdt_path_offset(dtb, "/chosen");
> > @@ -106,12 +135,27 @@ static int setup_dtb(struct kimage *image,
> > return -EINVAL;
> > }
> >
> > + /* add kaslr-seed */
> > + ret = fdt_delprop(dtb, nodeoffset, FDT_PSTR_KASLR_SEED);
> > + if (ret && (ret != -FDT_ERR_NOTFOUND))
> > + return -EINVAL;
> > +
> > + if (random_ready) {
> > + get_random_bytes(, sizeof(value));
>
> get_random_u64() ?
OK.
> > + ret = fdt_setprop_u64(dtb, nodeoffset, FDT_PSTR_KASLR_SEED,
> > + value);
> > + if (ret)
> > + return (ret == -FDT_ERR_NOSPACE ? -ENOMEM : -EINVAL);
> > + } else {
>
> Wouldn't we be better off preserving the previous seed here, if it was
> present?
While there's no guarantee that dtb won't be (partially) broken
on failure, I will let this function return successfully
by deleting succeeding fdt_delprop().
> > + pr_notice("kaslr-seed won't be fed\n");
>
> "fed" is probably not the right word here.
=> won't be *provided* on kexec?
-Takahiro Akashi
> Will
Re: Can we drop upstream Linux x32 support?
On Mon, Dec 10, 2018 at 05:23:39PM -0800, Andy Lutomirski wrote: > Hi all- > > I'm seriously considering sending a patch to remove x32 support from > upstream Linux. Here are some problems with it: > > 1. It's not entirely clear that it has users. As far as I know, it's > supported on Gentoo and Debian, and the Debian popcon graph for x32 > has been falling off dramatically. I don't think that any enterprise > distro has ever supported x32. > > 2. The way that system calls work is very strange. Most syscalls on > x32 enter through their *native* (i.e. not COMPAT_SYSCALL_DEFINE) > entry point, and this is intentional. For example, adjtimex() uses > the native entry, not the compat entry, because x32's struct timex > matches the x86_64 layout. But a handful of syscalls have separate > entry points -- these are the syscalls starting at 512. These enter > through the COMPAT_SYSCALL_DEFINE entry points. > > The x32 syscalls that are *not* in the 512 range violate all semblance > of kernel syscall convention. In the syscall handlers, > in_compat_syscall() returns true, but the COMPAT_SYSCALL_DEFINE entry > is not invoked. This is nutty and risks breaking things when people > refactor their syscall implementations. And no one tests these > things. Similarly, if someone calls any of the syscalls below 512 but > sets bit 31 in RAX, then the native entry will be called with > in_compat_set(). > > Conversely, if you call a syscall in the 512 range with bit 31 > *clear*, then the compat entry is set with in_compat_syscall() > *clear*. This is also nutty. > > Finally, the kernel has a weird distinction between CONFIG_X86_X32_ABI > and and CONFIG_X86_X32, which I suspect results in incorrect builds if > the host doesn't have an x32 toolchain installed. > > I propose that we make CONFIG_X86_X32 depend on BROKEN for a release > or two and then remove all the code if no one complains. If anyone Based on the discussion we had at the beginning of the pidfd_send_signal syscall patchset I think this is a good idea. For once, the complex compat handling can make adding new syscalls that need to rely on compat types because of precedent established by older syscalls icky. > wants to re-add it, IMO they're welcome to do so, but they need to do > it in a way that is maintainable. > > --Andy
Re: [PATCH 0/2] Graph fixes for using multiple endpoints per port
* Kuninori Morimoto [181211 05:30]:
>
> Hi Tony, again
>
> > > mcbsp3_port: port {
> > > - cpu_dai3: endpoint {
> > > + cpu_dai3: endpoint@0 {
> > > dai-format = "dsp_a";
> > > frame-master = <_audio_codec1>;
> > > bitclock-master = <_audio_codec1>;
> > > remote-endpoint = <_audio_codec1>;
> > > };
> > > + cpu_dai_mdm: endpoint@1 {
> > > + dai-format = "dsp_a";
> > > + frame-master = <_audio_codec1>;
> > > + bitclock-master = <_audio_codec1>;
> > > + remote-endpoint = <_mdm6600_audio_codec0>;
> > > + };
>
> audio-graph-scu-card and my posting merged audio-graph-card
> are assuming multi-endpoint will be used for DPCM purpose.
>
> But, above endpoint connection seems you want to is
> not DPCM (?), I'm not sure.
Yes DPCM should work nicely here :)
So to recap, Sebastian already added the cpcap codec a while back,
please see arch/arm/boot/dts/omap4-droid4-xt894.dts for the soundcard
node. Then see the link below for an earlier email describing how the
various components are wired for TDM [0].
Hope that clarifies things a bit more,
Tony
[0] https://lkml.org/lkml/2018/3/28/405
Re: [PATCH 13/18] asm-generic/tlb: Introduce HAVE_MMU_GATHER_NO_GATHER
Peter Zijlstra writes: > From: Martin Schwidefsky > > Add the Kconfig option HAVE_MMU_GATHER_NO_GATHER to the generic > mmu_gather code. If the option is set the mmu_gather will not > track individual pages for delayed page free anymore. A platform > that enables the option needs to provide its own implementation > of the __tlb_remove_page_size function to free pages. Can we rename this to HAVE_NO_BATCH_MMU_GATHER? > > Cc: npig...@gmail.com > Cc: heiko.carst...@de.ibm.com > Cc: will.dea...@arm.com > Cc: aneesh.ku...@linux.vnet.ibm.com > Cc: a...@linux-foundation.org > Cc: Linus Torvalds > Cc: li...@armlinux.org.uk > Signed-off-by: Martin Schwidefsky > Signed-off-by: Peter Zijlstra (Intel) > Link: http://lkml.kernel.org/r/20180918125151.31744-2-schwidef...@de.ibm.com -aneesh
Re: [PATCH v16 15/16] arm64: kexec_file: add kernel signature verification support
On Fri, Nov 30, 2018 at 01:21:14PM +, Will Deacon wrote:
> On Thu, Nov 15, 2018 at 02:52:54PM +0900, AKASHI Takahiro wrote:
> > With this patch, kernel verification can be done without IMA security
> > subsystem enabled. Turn on CONFIG_KEXEC_VERIFY_SIG instead.
> >
> > On x86, a signature is embedded into a PE file (Microsoft's format) header
> > of binary. Since arm64's "Image" can also be seen as a PE file as far as
> > CONFIG_EFI is enabled, we adopt this format for kernel signing.
> >
> > You can create a signed kernel image with:
> > $ sbsign --key ${KEY} --cert ${CERT} Image
> >
> > Signed-off-by: AKASHI Takahiro
> > Cc: Catalin Marinas
> > Cc: Will Deacon
> > Reviewed-by: James Morse
> > ---
> > arch/arm64/Kconfig | 24
> > arch/arm64/kernel/kexec_image.c | 17 +
> > 2 files changed, 41 insertions(+)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 93dc4d36d6db..11f3e1a00588 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -867,6 +867,30 @@ config KEXEC_FILE
> > for kernel and initramfs as opposed to list of segments as
> > accepted by previous system call.
> >
> > +config KEXEC_VERIFY_SIG
> > + bool "Verify kernel signature during kexec_file_load() syscall"
> > + depends on KEXEC_FILE
> > + help
> > + Select this option to verify a signature with loaded kernel
> > + image. If configured, any attempt of loading a image without
> > + valid signature will fail.
> > +
> > + In addition to that option, you need to enable signature
> > + verification for the corresponding kernel image type being
> > + loaded in order for this to work.
> > +
> > +config KEXEC_IMAGE_VERIFY_SIG
> > + bool "Enable Image signature verification support"
> > + default y
> > + depends on KEXEC_VERIFY_SIG
> > + depends on EFI && SIGNED_PE_FILE_VERIFICATION
> > + help
> > + Enable Image signature verification support.
> > +
> > +comment "Support for PE file signature verification disabled"
> > + depends on KEXEC_VERIFY_SIG
> > + depends on !EFI || !SIGNED_PE_FILE_VERIFICATION
> > +
> > config CRASH_DUMP
> > bool "Build kdump crash kernel"
> > help
> > diff --git a/arch/arm64/kernel/kexec_image.c
> > b/arch/arm64/kernel/kexec_image.c
> > index 9f0d8b5d62d3..d1c6c54c22e3 100644
> > --- a/arch/arm64/kernel/kexec_image.c
> > +++ b/arch/arm64/kernel/kexec_image.c
> > @@ -12,7 +12,9 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -29,6 +31,10 @@ static int image_probe(const char *kernel_buf, unsigned
> > long kernel_len)
> > sizeof(h->magic)))
> > return -EINVAL;
> >
> > + pr_debug("PE format: %s\n",
> > + memcmp(&((struct mz_hdr *)h)->magic, "MZ", 2) ?
> > + "no" : "yes");
> >
>
> Is this hunk really necessary? I'd prefer not to commit pr_debug()
> invocations.
This line comes from kexec-tools' code, but I don't mind removing it.
(as lots of lines diverge now from kexec-tools.)
-Takahiro Akashi
> Will
[PATCH v5 2/2] arm: dts: mt2712: add uart APDMA to device tree
1. add uart APDMA controller device node
2. add uart 0/1/2/3/4/5 DMA function
Signed-off-by: Long Cheng
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 50 +
1 file changed, 50 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 976d92a..a59728b 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -300,6 +300,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 10
+11>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -378,6 +381,38 @@
status = "disabled";
};
+ apdma: dma-controller@11000400 {
+ compatible = "mediatek,mt2712-uart-dma",
+"mediatek,mt6577-uart-dma";
+ reg = <0 0x11000400 0 0x80>,
+ <0 0x11000480 0 0x80>,
+ <0 0x11000500 0 0x80>,
+ <0 0x11000580 0 0x80>,
+ <0 0x11000600 0 0x80>,
+ <0 0x11000680 0 0x80>,
+ <0 0x11000700 0 0x80>,
+ <0 0x11000780 0 0x80>,
+ <0 0x11000800 0 0x80>,
+ <0 0x11000880 0 0x80>,
+ <0 0x11000900 0 0x80>,
+ <0 0x11000980 0 0x80>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ clocks = < CLK_PERI_AP_DMA>;
+ clock-names = "apdma";
+ #dma-cells = <1>;
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt2712-uart",
"mediatek,mt6577-uart";
@@ -385,6 +420,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 0
+1>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -395,6 +433,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 2
+3>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -405,6 +446,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 4
+5>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -415,6 +459,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 6
+7>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -629,6 +676,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 8
+9>;
+ dma-names = "tx", "rx";
status = "disabled";
};
--
1.7.9.5
[PATCH v5 0/2] add uart DMA function
In Mediatek SOCs, the uart can support DMA function. Base on DMA engine formwork, we add the DMA code to support uart. And put the code under drivers/dma. This series contains document bindings, Kconfig to control the function enable or not, device tree including interrupt and dma device node, the code of UART DM Changes compared to v4: -modify Kconfig depends on. Changes compared to v3: -fix CONFIG_PM, will cause build fail Changes compared to v2: -remove unimportant parameters -instead of cookie, use APIs of virtual channel. -use of_dma_xlate_by_chan_id. Changes compared to v1: -mian revised file, 8250_mtk_dma.c --parameters renamed for standard --remove atomic operation Long Cheng (2): dmaengine: 8250_mtk_dma: add Mediatek uart DMA support arm: dts: mt2712: add uart APDMA to device tree arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 50 ++ drivers/dma/mediatek/8250_mtk_dma.c | 830 + drivers/dma/mediatek/Kconfig | 11 + drivers/dma/mediatek/Makefile |1 + 4 files changed, 892 insertions(+) create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c -- 1.7.9.5
[PATCH v5 1/2] dmaengine: 8250_mtk_dma: add Mediatek uart DMA support
In DMA engine framework, add 8250 mtk dma to support it.
Signed-off-by: Long Cheng
---
drivers/dma/mediatek/8250_mtk_dma.c | 830 +++
drivers/dma/mediatek/Kconfig| 11 +
drivers/dma/mediatek/Makefile |1 +
3 files changed, 842 insertions(+)
create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c
diff --git a/drivers/dma/mediatek/8250_mtk_dma.c
b/drivers/dma/mediatek/8250_mtk_dma.c
new file mode 100644
index 000..f79d180
--- /dev/null
+++ b/drivers/dma/mediatek/8250_mtk_dma.c
@@ -0,0 +1,830 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mediatek 8250 DMA driver.
+ *
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Long Cheng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../virt-dma.h"
+
+#define MTK_APDMA_DEFAULT_REQUESTS 127
+#define MTK_APDMA_CHANNELS (CONFIG_SERIAL_8250_NR_UARTS * 2)
+
+#define VFF_EN_B BIT(0)
+#define VFF_STOP_B BIT(0)
+#define VFF_FLUSH_BBIT(0)
+#define VFF_4G_SUPPORT_B BIT(0)
+#define VFF_RX_INT_EN0_B BIT(0) /*rx valid size >= vff thre*/
+#define VFF_RX_INT_EN1_B BIT(1)
+#define VFF_TX_INT_EN_BBIT(0) /*tx left size >= vff thre*/
+#define VFF_WARM_RST_B BIT(0)
+#define VFF_RX_INT_FLAG_CLR_B (BIT(0) | BIT(1))
+#define VFF_TX_INT_FLAG_CLR_B 0
+#define VFF_STOP_CLR_B 0
+#define VFF_FLUSH_CLR_B0
+#define VFF_INT_EN_CLR_B 0
+#define VFF_4G_SUPPORT_CLR_B 0
+
+/* interrupt trigger level for tx */
+#define VFF_TX_THRE(n) ((n) * 7 / 8)
+/* interrupt trigger level for rx */
+#define VFF_RX_THRE(n) ((n) * 3 / 4)
+
+#define MTK_DMA_RING_SIZE 0xU
+/* invert this bit when wrap ring head again*/
+#define MTK_DMA_RING_WRAP 0x1U
+
+#define VFF_INT_FLAG 0x00
+#define VFF_INT_EN 0x04
+#define VFF_EN 0x08
+#define VFF_RST0x0c
+#define VFF_STOP 0x10
+#define VFF_FLUSH 0x14
+#define VFF_ADDR 0x1c
+#define VFF_LEN0x24
+#define VFF_THRE 0x28
+#define VFF_WPT0x2c
+#define VFF_RPT0x30
+/*TX: the buffer size HW can read. RX: the buffer size SW can read.*/
+#define VFF_VALID_SIZE 0x3c
+/*TX: the buffer size SW can write. RX: the buffer size HW can write.*/
+#define VFF_LEFT_SIZE 0x40
+#define VFF_DEBUG_STATUS 0x50
+#define VFF_4G_SUPPORT 0x54
+
+struct mtk_dmadev {
+ struct dma_device ddev;
+ void __iomem *mem_base[MTK_APDMA_CHANNELS];
+ spinlock_t lock; /* dma dev lock */
+ struct tasklet_struct task;
+ struct list_head pending;
+ struct clk *clk;
+ unsigned int dma_requests;
+ bool support_33bits;
+ unsigned int dma_irq[MTK_APDMA_CHANNELS];
+ struct mtk_chan *ch[MTK_APDMA_CHANNELS];
+};
+
+struct mtk_chan {
+ struct virt_dma_chan vc;
+ struct list_head node;
+ struct dma_slave_config cfg;
+ void __iomem *base;
+ struct mtk_dma_desc *desc;
+
+ bool stop;
+ bool requested;
+
+ unsigned int rx_status;
+};
+
+struct mtk_dma_sg {
+ dma_addr_t addr;
+ unsigned int en;/* number of elements (24-bit) */
+ unsigned int fn;/* number of frames (16-bit) */
+};
+
+struct mtk_dma_desc {
+ struct virt_dma_desc vd;
+ enum dma_transfer_direction dir;
+
+ unsigned int sglen;
+ struct mtk_dma_sg sg[0];
+
+ unsigned int len;
+};
+
+static inline struct mtk_dmadev *to_mtk_dma_dev(struct dma_device *d)
+{
+ return container_of(d, struct mtk_dmadev, ddev);
+}
+
+static inline struct mtk_chan *to_mtk_dma_chan(struct dma_chan *c)
+{
+ return container_of(c, struct mtk_chan, vc.chan);
+}
+
+static inline struct mtk_dma_desc *to_mtk_dma_desc
+ (struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct mtk_dma_desc, vd.tx);
+}
+
+static void mtk_dma_chan_write(struct mtk_chan *c,
+ unsigned int reg, unsigned int val)
+{
+ writel(val, c->base + reg);
+}
+
+static unsigned int mtk_dma_chan_read(struct mtk_chan *c, unsigned int reg)
+{
+ return readl(c->base + reg);
+}
+
+static void mtk_dma_desc_free(struct virt_dma_desc *vd)
+{
+ struct dma_chan *chan = vd->tx.chan;
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+
+ kfree(c->desc);
+ c->desc = NULL;
+}
+
+static void mtk_dma_tx_flush(struct dma_chan *chan)
+{
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+
+ if (mtk_dma_chan_read(c, VFF_FLUSH) == 0U)
+ mtk_dma_chan_write(c, VFF_FLUSH, VFF_FLUSH_B);
+}
+
+static void mtk_dma_tx_write(struct dma_chan *chan)
+{
+ struct mtk_chan *c =
Re: [PATCH 0/2] Graph fixes for using multiple endpoints per port
* Kuninori Morimoto [181211 05:16]:
>
> Hi Tony
>
> > > This looks a little bit strange for me.
> > > Can you show me your DT for it ?
> >
> > Sure, adding also Sebastian to Cc. Here's what I currently have for droid 4
> > dts with two codecs on I2S. Please just ignore the GNSS parts there..
> >
> > The TDM configuration is all done in the cpcap_audio_codec via
> > set_tdm_slot().
> > The modem voice call codec is a serdev driver :) I'll need some more time to
> > be able to post patches but it's basically working for voice calls.
>
> Hmm... it seems strange...
> I guess you are using "ti,omap4-mcbsp" driver (=
> linux/sound/soc/omap/omap-mcbsp.c)
> Is this correct ?
Yes.
> If so, your driver is registering component as
>
> ret = devm_snd_soc_register_component(>dev,
> _mcbsp_component,
> _mcbsp_dai, 1);
>
> Your driver has only 1 DAI.
Yes I have a patch for omap-mcbsp.c too :)
> > mcbsp3_port: port {
> > - cpu_dai3: endpoint {
> > + cpu_dai3: endpoint@0 {
> > dai-format = "dsp_a";
> > frame-master = <_audio_codec1>;
> > bitclock-master = <_audio_codec1>;
> > remote-endpoint = <_audio_codec1>;
> > };
> > + cpu_dai_mdm: endpoint@1 {
> > + dai-format = "dsp_a";
> > + frame-master = <_audio_codec1>;
> > + bitclock-master = <_audio_codec1>;
> > + remote-endpoint = <_mdm6600_audio_codec0>;
> > + };
>
> And here, you have 1 port, 2 endpoint.
> Then, asoc_simple_card_get_dai_id() should return 1.
>
> And, your [2/2] patch,
> I guess you are misunderstanding about "port" vs "endpoint",
> or omap-mcbsp driver side need to update ?
Yes omap-mcbsp driver needs to be updated for multiple endpoints.
Adding Jarkko and Peter also to Cc, below is the WIP patch that I'm
currently using for omap-mcbsp to add more DAIs.
So far nothing else to do in the omap-mcbsp as it's the cpcap hardware
that configures the TDM timeslots. And I'm currently assuming the
first instance is the master, I guess that should be parsed from the
the frame-master dts property instead.
Regards,
Tony
8< --
diff --git a/sound/soc/omap/omap-mcbsp-priv.h b/sound/soc/omap/omap-mcbsp-priv.h
--- a/sound/soc/omap/omap-mcbsp-priv.h
+++ b/sound/soc/omap/omap-mcbsp-priv.h
@@ -262,6 +262,8 @@ struct omap_mcbsp {
struct omap_mcbsp_platform_data *pdata;
struct omap_mcbsp_st_data *st_data;
struct omap_mcbsp_reg_cfg cfg_regs;
+ struct snd_soc_dai_driver *dais;
+ int dai_count;
struct snd_dmaengine_dai_dma_data dma_data[2];
unsigned int dma_req[2];
int dma_op_mode;
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1318,23 +1319,53 @@ static int omap_mcbsp_remove(struct snd_soc_dai *dai)
return 0;
}
-static struct snd_soc_dai_driver omap_mcbsp_dai = {
- .probe = omap_mcbsp_probe,
- .remove = omap_mcbsp_remove,
- .playback = {
- .channels_min = 1,
- .channels_max = 16,
- .rates = OMAP_MCBSP_RATES,
- .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE,
- },
- .capture = {
- .channels_min = 1,
- .channels_max = 16,
- .rates = OMAP_MCBSP_RATES,
- .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE,
- },
- .ops = _dai_ops,
-};
+static int omap_mcbsp_init_dais(struct omap_mcbsp *mcbsp)
+{
+ struct device_node *np = mcbsp->dev->of_node;
+ int i;
+
+ if (np)
+ mcbsp->dai_count = of_graph_get_endpoint_count(np);
+
+ if (!mcbsp->dai_count)
+ mcbsp->dai_count = 1;
+
+ mcbsp->dais = devm_kcalloc(mcbsp->dev, mcbsp->dai_count,
+ sizeof(*mcbsp->dais), GFP_KERNEL);
+ if (!mcbsp->dais)
+ return -ENOMEM;
+
+ for (i = 0; i < mcbsp->dai_count; i++) {
+ struct snd_soc_dai_driver *dai = >dais[i];
+
+ dai->name = devm_kasprintf(mcbsp->dev, GFP_KERNEL, "%s-dai%i",
+ dev_name(mcbsp->dev), i);
+
+ if (i == 0) {
+ dai->probe = omap_mcbsp_probe;
+ dai->remove = omap_mcbsp_remove;
+ dai->ops = _dai_ops;
+ }
+ dai->playback.channels_min = 1;
+ dai->playback.channels_max = 16;
+ dai->playback.rates = OMAP_MCBSP_RATES;
+ if (mcbsp->pdata->reg_size == 2)
+ dai->playback.formats =
Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start
Hi Saravana,
The devfreq git repo is maintained by Myungjoo Ham.
you can check it on MAINTAINERS file.
I think that you better to resend mail to mainline
with my reviewed tag because the devfreq core could be modified
and then merge conflict might be happen when apply this patch.
Regards,
Chanwoo Choi
On 2018년 12월 08일 05:29, Saravana Kannan wrote:
>
> On 11/9/16 4:10 PM, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2016년 11월 10일 05:34, Saravana Kannan wrote:
>>> On 11/08/2016 06:38 PM, Chanwoo Choi wrote:
On 2016년 11월 09일 11:36, Chanwoo Choi wrote:
> Hi,
>
> On 2016년 11월 09일 10:33, Chanwoo Choi wrote:
>> On 2016년 11월 09일 05:52, Saravana Kannan wrote:
>>> On 11/08/2016 01:02 AM, Chanwoo Choi wrote:
Hi,
On 2016년 11월 08일 03:57, Saravana Kannan wrote:
> On 10/26/2016 05:06 PM, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2016년 10월 27일 04:17, Saravana Kannan wrote:
>>> If the new governor fails to start, switch back to old governor so
>>> that the
>>> devfreq state is not left in some weird limbo.
>>>
>>> Signed-off-by: Saravana Kannan
>>> ---
>>> * Fix NULL deref for real this time.
>>> * Addressed some style preferences.
>>>
>>> drivers/devfreq/devfreq.c | 13 +++--
>>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>> index bf3ea76..77c41a5 100644
>>> --- a/drivers/devfreq/devfreq.c
>>> +++ b/drivers/devfreq/devfreq.c
>>> @@ -919,7 +919,7 @@ static ssize_t governor_store(struct device
>>> *dev, struct device_attribute *attr,
>>> struct devfreq *df = to_devfreq(dev);
>>> int ret;
>>> char str_governor[DEVFREQ_NAME_LEN + 1];
>>> -struct devfreq_governor *governor;
>>> +const struct devfreq_governor *governor, *prev_governor;
>>>
>>> ret = sscanf(buf, "%" __stringify(DEVFREQ_NAME_LEN) "s",
>>> str_governor);
>>> if (ret != 1)
>>> @@ -944,12 +944,21 @@ static ssize_t governor_store(struct device
>>> *dev, struct device_attribute *attr,
>>> goto out;
>>> }
>>> }
>>> +prev_governor = df->governor;
>>> df->governor = governor;
>>> strncpy(df->governor_name, governor->name,
>>> DEVFREQ_NAME_LEN);
>>> ret = df->governor->event_handler(df, DEVFREQ_GOV_START,
>>> NULL);
>>> -if (ret)
>>> +if (ret) {
>>> dev_warn(dev, "%s: Governor %s not started(%d)\n",
>>> __func__, df->governor->name, ret);
>>> +if (prev_governor) {
>> I think that prev_governor is always set. You don't need to check it.
>> Why do check it?
> Not true. Even higher up in this function, we check if df->governor
> != NULL. Simple example would be that the default governor passed in
> while adding the device isn't compiled in.
I don't understand. If device is not registered by
devfreq_add_device(),
you don't change the governor by using governor_store().
If you can change the governor through governor_store(),
it means that the devfreq instance was added without any problem.
The added devfreq instance must have the sepecific governor
on df->governor variable.
So, I think that df->governor is always set and then prev_governor is
always set.
>>> Read the code more closely. add_device doesn't (and shouldn't) fail if
>>> the governor isn't present. After that, the governor could be changed
>>> from user space.
>> If governor is not present during devfreq_add_device(),
>> the devfreq instance is not able to register the devfreq framework.
>> So, the user never touch the sysfs[1] to change the governor
>> because the sysfs[1] is not created by devfreq framework.
>> [1] /sys/class/devfreq/[device name]/governor
>>
>> In summary, if governor is not present during devfreq_add_device(),
>> the devfreq framework doesn't create tye sysfs[1] for governor.
>>
>> The user-space never change the governor through sysfs[1]
>> because there is no any sysfs entry[1].
> I checked the code of devfreq_add_device().
> As you mentioned, if there is no governor,
> devfreq_add_device() don't pass wihtout calling the
> devfreq->governor->even_handler().
Wrong expression / don't pass -> pass
>>> I think it's correct as is. Just because the governor isn't there (or
>>> hasn't registered yet) doesn't mean the device add should fail.
>>>
>>> That aside, do you care to ack this patch for
Re: Can we drop upstream Linux x32 support?
On Mon, Dec 10, 2018 at 7:15 PM H.J. Lu wrote:
>
> On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski wrote:
> >
> > Hi all-
> >
> > I'm seriously considering sending a patch to remove x32 support from
> > upstream Linux. Here are some problems with it:
> >
> > 1. It's not entirely clear that it has users. As far as I know, it's
> > supported on Gentoo and Debian, and the Debian popcon graph for x32
> > has been falling off dramatically. I don't think that any enterprise
> > distro has ever supported x32.
>
> I have been posting x32 GCC results for years:
>
> https://gcc.gnu.org/ml/gcc-testresults/2018-12/msg01358.html
Right. My question wasn't whether x32 had developers -- it was
whether it had users. If the only users are a small handful of people
who keep the toolchain and working and some people who benchmark it,
then I think the case for keeping it in upstream Linux is a bit weak.
>
> > 2. The way that system calls work is very strange. Most syscalls on
> > x32 enter through their *native* (i.e. not COMPAT_SYSCALL_DEFINE)
> > entry point, and this is intentional. For example, adjtimex() uses
> > the native entry, not the compat entry, because x32's struct timex
> > matches the x86_64 layout. But a handful of syscalls have separate
>
> This becomes less an issue with 64-bit time_t.
>
> > entry points -- these are the syscalls starting at 512. These enter
> > throuh the COMPAT_SYSCALL_DEFINE entry points.
> >
> > The x32 syscalls that are *not* in the 512 range violate all semblance
> > of kernel syscall convention. In the syscall handlers,
> > in_compat_syscall() returns true, but the COMPAT_SYSCALL_DEFINE entry
> > is not invoked. This is nutty and risks breaking things when people
> > refactor their syscall implementations. And no one tests these
> > things. Similarly, if someone calls any of the syscalls below 512 but
> > sets bit 31 in RAX, then the native entry will be called with
> > in_compat_set().
> >
> > Conversely, if you call a syscall in the 512 range with bit 31
> > *clear*, then the compat entry is set with in_compat_syscall()
> > *clear*. This is also nutty.
>
> This is to share syscalls between LP64 and ILP32 (x32) in x86-64 kernel.
>
I tried to understand what's going on. As far as I can tell, most of
the magic is the fact that __kernel_long_t and __kernel_ulong_t are
64-bit as seen by x32 user code. This means that a decent number of
uapi structures are the same on x32 and x86_64. Syscalls that only
use structures like this should route to the x86_64 entry points. But
the implementation is still highly dubious -- in_compat_syscall() will
be *true* in such system calls, which means that, if someone changes:
SYSCALL_DEFINE1(some_func, struct some_struct __user *, ptr)
{
/* x32 goes here, but it's entirely non-obvious unless you read the
x86 syscall table */
native impl;
}
COMPAT_SYSCALL_DEFINE1(some_func, struct compat_some_struct __user *, ptr)
{
compat impl;
}
to the Obviously Equivalent (tm):
SYSCALL_DEFINE1(some_func, struct some_struct __user *, ptr)
{
struct some_struct kernel_val;
if (in_compat_syscall()) {
get_compat_some_struct(_val, ptr);
} else {
copy_from_user(_val, ptr, sizeof(struct some_struct));
}
do the work;
}
then x32 breaks.
And I don't even know how x32 is supposed to support some hypothetical
syscall like this:
long sys_nasty(struct adjtimex *a, struct iovec *b);
where one argument has x32 and x86_64 matching but the other has x32
and x86_32 matching.
This whole thing seems extremely fragile.
[PATCH v2] userfaultfd: clear flag if remap event not enabled
When the process being tracked do mremap() without
UFFD_FEATURE_EVENT_REMAP on the corresponding tracking uffd file
handle, we should not generate the remap event, and at the same
time we should clear all the uffd flags on the new VMA. Without
this patch, we can still have the VM_UFFD_MISSING|VM_UFFD_WP
flags on the new VMA even the fault handling process does not
even know the existance of the VMA.
CC: Andrea Arcangeli
CC: Andrew Morton
CC: Mike Rapoport
CC: Kirill A. Shutemov
CC: Hugh Dickins
CC: Pavel Emelyanov
CC: Pravin Shedge
CC: linux...@kvack.org
CC: linux-kernel@vger.kernel.org
Acked-by: Mike Rapoport
Reviewed-by: Andrea Arcangeli
Signed-off-by: Peter Xu
---
fs/userfaultfd.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index cd58939dc977..4567b5b6fd32 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -736,10 +736,18 @@ void mremap_userfaultfd_prep(struct vm_area_struct *vma,
struct userfaultfd_ctx *ctx;
ctx = vma->vm_userfaultfd_ctx.ctx;
- if (ctx && (ctx->features & UFFD_FEATURE_EVENT_REMAP)) {
+
+ if (!ctx)
+ return;
+
+ if (ctx->features & UFFD_FEATURE_EVENT_REMAP) {
vm_ctx->ctx = ctx;
userfaultfd_ctx_get(ctx);
WRITE_ONCE(ctx->mmap_changing, true);
+ } else {
+ /* Drop uffd context if remap feature not enabled */
+ vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX;
+ vma->vm_flags &= ~(VM_UFFD_WP | VM_UFFD_MISSING);
}
}
--
2.17.1
Re: [PATCH 0/2] Graph fixes for using multiple endpoints per port
Hi Tony, again
> > mcbsp3_port: port {
> > - cpu_dai3: endpoint {
> > + cpu_dai3: endpoint@0 {
> > dai-format = "dsp_a";
> > frame-master = <_audio_codec1>;
> > bitclock-master = <_audio_codec1>;
> > remote-endpoint = <_audio_codec1>;
> > };
> > + cpu_dai_mdm: endpoint@1 {
> > + dai-format = "dsp_a";
> > + frame-master = <_audio_codec1>;
> > + bitclock-master = <_audio_codec1>;
> > + remote-endpoint = <_mdm6600_audio_codec0>;
> > + };
audio-graph-scu-card and my posting merged audio-graph-card
are assuming multi-endpoint will be used for DPCM purpose.
But, above endpoint connection seems you want to is
not DPCM (?), I'm not sure.
Best regards
---
Kuninori Morimoto
RE: rcu_preempt caused oom
sure, we will update the new patch to run the test.
-Original Message-
From: Paul E. McKenney
Sent: Tuesday, December 11, 2018 12:47 PM
To: He, Bo
Cc: Steven Rostedt ; linux-kernel@vger.kernel.org;
j...@joshtriplett.org; mathieu.desnoy...@efficios.com; jiangshan...@gmail.com;
Zhang, Jun ; Xiao, Jin ; Zhang, Yanmin
; Bai, Jie A
Subject: Re: rcu_preempt caused oom
On Mon, Dec 10, 2018 at 04:38:38PM -0800, Paul E. McKenney wrote:
> On Mon, Dec 10, 2018 at 06:56:18AM +, He, Bo wrote:
> > Hi,
> >We have start the test with the CONFIG_PROVE_RCU=y, and also add one 2s
> > to detect the preempt rcu hang, hope we can get more useful logs tomorrow.
> >I also enclosed the config and the debug patches for you review.
>
> I instead suggest the (lightly tested) debug patch shown below, which
> tracks wakeups of RCU's grace-period kthreads and dumps them out if a
> given requested grace period fails to start. Again, it is necessary
> to build with CONFIG_PROVE_RCU=y, that is, with CONFIG_PROVE_LOCKING=y.
Right. This time without commenting out the wakeup as a test of the
diagnostic. :-/
Please use the patch below instead of the one that I sent in my previous email.
Thanx, Paul
commit adfc7dff659495a3433d5084256be59eee0ac6df
Author: Paul E. McKenney
Date: Mon Dec 10 16:33:59 2018 -0800
rcu: Improve diagnostics for failed RCU grace-period start
Backported from v4.21/v5.0
If a grace period fails to start (for example, because you commented
out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core()
will invoke rcu_check_gp_start_stall(), which will notice and complain.
However, this complaint is lacking crucial debugging information such
as when the last wakeup executed and what the value of ->gp_seq was at
that time. This commit therefore removes the current pr_alert() from
rcu_check_gp_start_stall(), instead invoking show_rcu_gp_kthreads(),
which has been updated to print the needed information, which is collected
by rcu_gp_kthread_wake().
Signed-off-by: Paul E. McKenney
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index
0b760c1369f7..4bcd8753e293 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -626,25 +626,57 @@ void rcu_sched_force_quiescent_state(void)
}
EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state);
+/*
+ * Convert a ->gp_state value to a character string.
+ */
+static const char *gp_state_getname(short gs) {
+ if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names))
+ return "???";
+ return gp_state_names[gs];
+}
+
+/*
+ * Return the root node of the specified rcu_state structure.
+ */
+static struct rcu_node *rcu_get_root(struct rcu_state *rsp) {
+ return >node[0];
+}
+
/*
* Show the state of the grace-period kthreads.
*/
void show_rcu_gp_kthreads(void)
{
int cpu;
+ unsigned long j;
+ unsigned long ja;
+ unsigned long jr;
+ unsigned long jw;
struct rcu_data *rdp;
struct rcu_node *rnp;
struct rcu_state *rsp;
+ j = jiffies;
for_each_rcu_flavor(rsp) {
- pr_info("%s: wait state: %d ->state: %#lx\n",
- rsp->name, rsp->gp_state, rsp->gp_kthread->state);
+ ja = j - READ_ONCE(rsp->gp_activity);
+ jr = j - READ_ONCE(rsp->gp_req_activity);
+ jw = j - READ_ONCE(rsp->gp_wake_time);
+ pr_info("%s: wait state: %s(%d) ->state: %#lx delta
->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld
->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n",
+ rsp->name, gp_state_getname(rsp->gp_state),
+ rsp->gp_state,
+ rsp->gp_kthread ? rsp->gp_kthread->state : 0x1L,
+ ja, jr, jw, (long)READ_ONCE(rsp->gp_wake_seq),
+ (long)READ_ONCE(rsp->gp_seq),
+ (long)READ_ONCE(rcu_get_root(rsp)->gp_seq_needed),
+ READ_ONCE(rsp->gp_flags));
rcu_for_each_node_breadth_first(rsp, rnp) {
if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed))
continue;
- pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed
%lu\n",
- rnp->grplo, rnp->grphi, rnp->gp_seq,
- rnp->gp_seq_needed);
+ pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed
%ld\n",
+ rnp->grplo, rnp->grphi, (long)rnp->gp_seq,
+ (long)rnp->gp_seq_needed);
if (!rcu_is_leaf_node(rnp))
continue;
for_each_leaf_node_possible_cpu(rnp, cpu) { @@ -653,8
+685,8
[GIT PULL] extcon next for v4.21
Dear Greg, This is extcon-next pull request for v4.21. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-for-4.21 for you to fetch changes up to a2dc50914744eea9f83a70a5db0486be625e5dc0: extcon: max8997: Fix lack of path setting in USB device mode (2018-11-14 09:06:32 +0900) Update extcon for 4.21 Detailed description for this pull request: 1. Fix minor issue of Maxim MUIC (Micro USB IC) device driver - Avoid forcing UART path on probe for extcon-max77843/77693/14577/8997.c - Set USB path in USB device mode for extcon-max8997.c Marek Szyprowski (5): extcon: max77843: Avoid forcing UART path on drive probe extcon: max77693: Avoid forcing UART path on drive probe extcon: max14577: Avoid forcing UART path on drive probe extcon: max8997: Avoid forcing UART path on drive probe extcon: max8997: Fix lack of path setting in USB device mode drivers/extcon/extcon-max14577.c | 15 +-- drivers/extcon/extcon-max77693.c | 16 ++-- drivers/extcon/extcon-max77843.c | 18 +++--- drivers/extcon/extcon-max8997.c | 25 + 4 files changed, 59 insertions(+), 15 deletions(-)
Re: [RFC PATCH v2 11/11] powerpc/book3s32: Implement Kernel Userspace Access Protection
On Wed, 2018-11-28 at 09:27 +, Christophe Leroy wrote: > This patch implements Kernel Userspace Access Protection for > book3s/32. > > Due to limitations of the processor page protection capabilities, > the protection is only against writing. read protection cannot be > achieved using page protection. > > In order to provide the protection, Ku and Ks keys are modified in > Userspace Segment registers, and different PP bits are used to: > > PP01 provides RW for Key 0 and RO for Key 1 > PP10 provides RW for all > PP11 provides RO for all > > Today PP10 is used for RW pages and PP11 for RO pages. This patch > modifies page protection to PP01 for RW pages. > > Then segment registers are set to Ku 0 and Ks 1. When kernel needs > to write to RW pages, the associated segment register is changed to > Ks 0 in order to allow write access to the kernel. > > In order to avoid having the read all segment registers when > locking/unlocking the access, some data is kept in the thread_struct > and saved on stack on exceptions. The field identifies both the > first unlocked segment and the first segment following the last > unlocked one. When no segment is unlocked, it contains value 0. > > Signed-off-by: Christophe Leroy Hey Christophe, I tried to test this and got a machine check after the kernel starts init. Vector: 700 (Program Check) at [ef0b5e70] pc: 0ca4 lr: b7e1a030 sp: ef0b5f30 msr: 81002 current = 0xef0b8000 pid = 1, comm = init Testing with mac99 model in qemu. - Russell
Re: [PATCH net-next] rhashtable: further improve stability of rhashtable_walk
Hi Neil: On Mon, Dec 10, 2018 at 09:50:43AM +1100, NeilBrown wrote: > I think it was agreed that I would not pursue features that were only > of use to out-of-tree code, but I don't think that applies here. This > is not a feature, this is a quality-of-implementation improvement. > There are users in the kernel today which use >rhashtable_walk_stop()/rhashtable_walk_start() > to drop out of RCU protection for periods during the walk. > Any such user might miss seeing an object that has been in the table > for a while - sure that is less than optimal, and should be fixed if > the cost is small. > > There are currently no rhlist users which use stop/start to drop out > of RCU, so there is no clear value in fixing that case, or cost in not > fixing it. I think the complexities of this patch outweighs any benefit. Walking an rhashtable is inherently unreliable, due to rehashing. If you need an 100% reliable walking mechanism, then add your own linked list alongside the hash table like xfrm does. Having said that, if the current code is missing items that existed prior to the start of the walk (in the absence of a rehash) then that would be a bug that we should fix. Anything else like duplicates just needs to be accepted by the caller. So please explain how can an object be missed then we can work on fixing that and that only. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] userfaultfd: clear flag if remap event not enabled
On Mon, Dec 10, 2018 at 03:09:25PM -0500, Andrea Arcangeli wrote:
> Hello,
>
> On Mon, Dec 10, 2018 at 07:51:16PM +0200, Mike Rapoport wrote:
> > On Mon, Dec 10, 2018 at 02:51:21PM +0800, Peter Xu wrote:
> > > When the process being tracked do mremap() without
> > > UFFD_FEATURE_EVENT_REMAP on the corresponding tracking uffd file
> > > handle, we should not generate the remap event, and at the same
> > > time we should clear all the uffd flags on the new VMA. Without
> > > this patch, we can still have the VM_UFFD_MISSING|VM_UFFD_WP
> > > flags on the new VMA even the fault handling process does not
> > > even know the existance of the VMA.
> > >
> > > CC: Andrea Arcangeli
> > > CC: Andrew Morton
> > > CC: Mike Rapoport
> > > CC: Kirill A. Shutemov
> > > CC: Hugh Dickins
> > > CC: Pavel Emelyanov
> > > CC: Pravin Shedge
> > > CC: linux...@kvack.org
> > > CC: linux-kernel@vger.kernel.org
> > > Signed-off-by: Peter Xu
> > > ---
> > > fs/userfaultfd.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> > > index cd58939dc977..798ae8a438ff 100644
> > > --- a/fs/userfaultfd.c
> > > +++ b/fs/userfaultfd.c
> > > @@ -740,6 +740,9 @@ void mremap_userfaultfd_prep(struct vm_area_struct
> > > *vma,
> > > vm_ctx->ctx = ctx;
> > > userfaultfd_ctx_get(ctx);
> > > WRITE_ONCE(ctx->mmap_changing, true);
> > > + } else if (ctx) {
> > > + vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX;
> > > + vma->vm_flags &= ~(VM_UFFD_WP | VM_UFFD_MISSING);
>
> Great catch Peter!
>
> >
> > My preference would be
> >
> > if (!ctx)
> > return;
> >
> > if (ctx->features & UFFD_FEATURE_EVENT_REMAP) {
> > ...
> > } else {
> > ...
> > }
> >
> > but I don't feel strongly about it.
>
> Yes, it'd look nicer to run a single "ctx not null" check.
I agree.
>
> >
> > I'd appreciate a comment in the code and with it
> >
> > Acked-by: Mike Rapoport
> >
>
> Reviewed-by: Andrea Arcangeli
Thanks to both! I'll repost soon.
Regards,
--
Peter Xu
Re: [PATCH 0/2] Graph fixes for using multiple endpoints per port
Hi Tony
> > This looks a little bit strange for me.
> > Can you show me your DT for it ?
>
> Sure, adding also Sebastian to Cc. Here's what I currently have for droid 4
> dts with two codecs on I2S. Please just ignore the GNSS parts there..
>
> The TDM configuration is all done in the cpcap_audio_codec via set_tdm_slot().
> The modem voice call codec is a serdev driver :) I'll need some more time to
> be able to post patches but it's basically working for voice calls.
Hmm... it seems strange...
I guess you are using "ti,omap4-mcbsp" driver (=
linux/sound/soc/omap/omap-mcbsp.c)
Is this correct ?
If so, your driver is registering component as
ret = devm_snd_soc_register_component(>dev,
_mcbsp_component,
_mcbsp_dai, 1);
Your driver has only 1 DAI.
> mcbsp3_port: port {
> - cpu_dai3: endpoint {
> + cpu_dai3: endpoint@0 {
> dai-format = "dsp_a";
> frame-master = <_audio_codec1>;
> bitclock-master = <_audio_codec1>;
> remote-endpoint = <_audio_codec1>;
> };
> + cpu_dai_mdm: endpoint@1 {
> + dai-format = "dsp_a";
> + frame-master = <_audio_codec1>;
> + bitclock-master = <_audio_codec1>;
> + remote-endpoint = <_mdm6600_audio_codec0>;
> + };
And here, you have 1 port, 2 endpoint.
Then, asoc_simple_card_get_dai_id() should return 1.
And, your [2/2] patch,
I guess you are misunderstanding about "port" vs "endpoint",
or omap-mcbsp driver side need to update ?
Best regards
---
Kuninori Morimoto
[PATCH V4 2/2] iio: accell: mma8452: add optional vdd/vddio regulator operation support
The accelerometer's power supply could be controlled by regulator
on some platforms, such as i.MX6Q-SABRESD board, the mma8451's
power supply is controlled by a GPIO fixed regulator, need to make
sure the regulator is enabled before any communication with mma8451,
this patch adds optional vdd/vddio regulator operation support.
Signed-off-by: Anson Huang
Acked-by: Martin Kepplinger
---
ChangeLog since V3:
- add disabling vdd regulator in vddio error path;
- improve regulator enable/disable sequence.
---
drivers/iio/accel/mma8452.c | 186 +---
1 file changed, 176 insertions(+), 10 deletions(-)
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 421a0a8..590a95d 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#define MMA8452_STATUS 0x00
#define MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
@@ -107,6 +108,8 @@ struct mma8452_data {
u8 data_cfg;
const struct mma_chip_info *chip_info;
int sleep_val;
+ struct regulator *vdd_reg;
+ struct regulator *vddio_reg;
};
/**
@@ -1533,10 +1536,35 @@ static int mma8452_probe(struct i2c_client *client,
data->client = client;
mutex_init(>lock);
data->chip_info = match->data;
+ data->vdd_reg = devm_regulator_get_optional(>dev, "vdd");
+ if (!IS_ERR(data->vdd_reg)) {
+ ret = regulator_enable(data->vdd_reg);
+ if (ret) {
+ dev_err(>dev, "failed to enable VDD
regulator\n");
+ return ret;
+ }
+ } else {
+ ret = PTR_ERR(data->vdd_reg);
+ if (ret != -ENODEV)
+ return ret;
+ }
+
+ data->vddio_reg = devm_regulator_get_optional(>dev, "vddio");
+ if (!IS_ERR(data->vddio_reg)) {
+ ret = regulator_enable(data->vddio_reg);
+ if (ret) {
+ dev_err(>dev, "failed to enable VDDIO
regulator\n");
+ goto disable_regulator_vdd;
+ }
+ } else {
+ ret = PTR_ERR(data->vddio_reg);
+ if (ret != -ENODEV)
+ goto disable_regulator_vdd;
+ }
ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I);
if (ret < 0)
- return ret;
+ goto disable_regulators;
switch (ret) {
case MMA8451_DEVICE_ID:
@@ -1549,7 +1577,8 @@ static int mma8452_probe(struct i2c_client *client,
break;
/* else: fall through */
default:
- return -ENODEV;
+ ret = -ENODEV;
+ goto disable_regulators;
}
dev_info(>dev, "registering %s accelerometer; ID 0x%x\n",
@@ -1566,13 +1595,13 @@ static int mma8452_probe(struct i2c_client *client,
ret = mma8452_reset(client);
if (ret < 0)
- return ret;
+ goto disable_regulators;
data->data_cfg = MMA8452_DATA_CFG_FS_2G;
ret = i2c_smbus_write_byte_data(client, MMA8452_DATA_CFG,
data->data_cfg);
if (ret < 0)
- return ret;
+ goto disable_regulators;
/*
* By default set transient threshold to max to avoid events if
@@ -1581,7 +1610,7 @@ static int mma8452_probe(struct i2c_client *client,
ret = i2c_smbus_write_byte_data(client, MMA8452_TRANSIENT_THS,
MMA8452_TRANSIENT_THS_MASK);
if (ret < 0)
- return ret;
+ goto disable_regulators;
if (client->irq) {
int irq2;
@@ -1595,7 +1624,7 @@ static int mma8452_probe(struct i2c_client *client,
MMA8452_CTRL_REG5,
data->chip_info->all_events);
if (ret < 0)
- return ret;
+ goto disable_regulators;
dev_dbg(>dev, "using interrupt line INT1\n");
}
@@ -1604,11 +1633,11 @@ static int mma8452_probe(struct i2c_client *client,
MMA8452_CTRL_REG4,
data->chip_info->enabled_events);
if (ret < 0)
- return ret;
+ goto disable_regulators;
ret = mma8452_trigger_setup(indio_dev);
if (ret < 0)
- return ret;
+ goto disable_regulators;
}
data->ctrl_reg1 = MMA8452_CTRL_ACTIVE |
@@ -1661,12 +1690,22 @@ static int mma8452_probe(struct i2c_client *client,
trigger_cleanup:
mma8452_trigger_cleanup(indio_dev);
[PATCH V4 1/2] dt-bindings: iio: accel: mma8452: add optional power supply property
The accelerometer's power supply could be controlled by regulator
on some platforms, add optional property "vdd/vddio" power supply
to let device tree to pass phandles to the regulators to driver.
Signed-off-by: Anson Huang
---
Documentation/devicetree/bindings/iio/accel/mma8452.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index 2100e9a..e132394 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -20,6 +20,10 @@ Optional properties:
- interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
interrupt line in use.
+ - vdd-supply: phandle to the regulator that provides vdd power to the
accelerometer.
+
+ - vddio-supply: phandle to the regulator that provides vddio power to the
accelerometer.
+
Example:
mma8453fc@1d {
--
2.7.4
Re: [PATCH] crypto/testmgr: fix skcipher test with CONFIG_VMAP_STACK
On Fri, Dec 07, 2018 at 09:26:15PM +0100, Ard Biesheuvel wrote: > On Fri, 7 Dec 2018 at 18:33, Christophe Leroy wrote: > > > > [2.364486] WARNING: CPU: 0 PID: 60 at > > ./arch/powerpc/include/asm/io.h:837 dma_nommu_map_page+0x44/0xd4 > > [2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW > >4.20.0-rc5-00560-g6bfb52e23a00-dirty #531 > > [2.384740] NIP: c000c540 LR: c000c584 CTR: > > [2.389743] REGS: c95abab0 TRAP: 0700 Tainted: GW > > (4.20.0-rc5-00560-g6bfb52e23a00-dirty) > > [2.400042] MSR: 00029032 CR: 24042204 XER: > > [2.406669] > > [2.406669] GPR00: c02f2244 c95abb60 c6262990 c95abd80 256a 0001 > > 0001 0001 > > [2.406669] GPR08: 2000 0010 0010 24042202 > > 0100 c95abd88 > > [2.406669] GPR16: c05569d4 0001 0010 c95abc88 c0615664 > > 0004 > > [2.406669] GPR24: 0010 c95abc88 c95abc88 c61ae210 c7ff6d40 > > c61ae210 3d68 > > [2.441559] NIP [c000c540] dma_nommu_map_page+0x44/0xd4 > > [2.446720] LR [c000c584] dma_nommu_map_page+0x88/0xd4 > > [2.451762] Call Trace: > > [2.454195] [c95abb60] [82000808] 0x82000808 (unreliable) > > [2.459572] [c95abb80] [c02f2244] talitos_edesc_alloc+0xbc/0x3c8 > > [2.465493] [c95abbb0] [c02f2600] ablkcipher_edesc_alloc+0x4c/0x5c > > [2.471606] [c95abbd0] [c02f4ed0] ablkcipher_encrypt+0x20/0x64 > > [2.477389] [c95abbe0] [c02023b0] __test_skcipher+0x4bc/0xa08 > > [2.483049] [c95abe00] [c0204b60] test_skcipher+0x2c/0xcc > > [2.488385] [c95abe20] [c0204c48] alg_test_skcipher+0x48/0xbc > > [2.494064] [c95abe40] [c0205cec] alg_test+0x164/0x2e8 > > [2.499142] [c95abf00] [c0200dec] cryptomgr_test+0x48/0x50 > > [2.504558] [c95abf10] [c0039ff4] kthread+0xe4/0x110 > > [2.509471] [c95abf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c > > [2.515532] Instruction dump: > > [2.518468] 7c7e1b78 7c9d2378 7cbf2b78 41820054 3d20c076 8089c200 > > 3d20c076 7c84e850 > > [2.526127] 8129c204 7c842e70 7f844840 419c0008 <0fe0> 2f9e > > 54847022 7c84fa14 > > [2.533960] ---[ end trace bf78d94af73fe3b8 ]--- > > [2.539123] talitos ff02.crypto: master data transfer error > > [2.544775] talitos ff02.crypto: TEA error: ISR 0x2000_0040 > > [2.551625] alg: skcipher: encryption failed on test 1 for > > ecb-aes-talitos: ret=22 > > > > IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack > > cannot be DMA mapped anymore. > > > > This patch allocates it with kmalloc() > > > > This looks like a driver bug to me. Other accelerators in > drivers/crypto all take a copy of the IV before mapping it for DMA, so > it would be better if talitos did the same. Yes please fix the driver. In general, if a paramter is coming in as a pointer, you must assume that it may lie on the stack. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH V4] iio: magnetometer: mag3110: add optional vdd/vddio regulator operation support
The magnetometer's power supply could be controlled by regulator
on some platforms, such as i.MX6Q-SABRESD board, the mag3110's
power supply is controlled by a GPIO fixed regulator, need to make
sure the regulator is enabled before any communication with mag3110,
this patch adds optional vdd/vddio regulator operation support.
Signed-off-by: Anson Huang
---
ChangeLog since V3:
- add disabling vdd in vddio error path;
- improve the regulator enable/disable sequence.
---
drivers/iio/magnetometer/mag3110.c | 96 ++
1 file changed, 88 insertions(+), 8 deletions(-)
diff --git a/drivers/iio/magnetometer/mag3110.c
b/drivers/iio/magnetometer/mag3110.c
index f063355..328c0c4 100644
--- a/drivers/iio/magnetometer/mag3110.c
+++ b/drivers/iio/magnetometer/mag3110.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#define MAG3110_STATUS 0x00
#define MAG3110_OUT_X 0x01 /* MSB first */
@@ -56,6 +57,8 @@ struct mag3110_data {
struct mutex lock;
u8 ctrl_reg1;
int sleep_val;
+ struct regulator *vdd_reg;
+ struct regulator *vddio_reg;
};
static int mag3110_request(struct mag3110_data *data)
@@ -469,17 +472,46 @@ static int mag3110_probe(struct i2c_client *client,
struct iio_dev *indio_dev;
int ret;
- ret = i2c_smbus_read_byte_data(client, MAG3110_WHO_AM_I);
- if (ret < 0)
- return ret;
- if (ret != MAG3110_DEVICE_ID)
- return -ENODEV;
-
indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
if (!indio_dev)
return -ENOMEM;
data = iio_priv(indio_dev);
+
+ data->vdd_reg = devm_regulator_get_optional(>dev, "vdd");
+ if (!IS_ERR(data->vdd_reg)) {
+ ret = regulator_enable(data->vdd_reg);
+ if (ret) {
+ dev_err(>dev, "failed to enable VDD
regulator\n");
+ return ret;
+ }
+ } else {
+ ret = PTR_ERR(data->vdd_reg);
+ if (ret != -ENODEV)
+ return ret;
+ }
+
+ data->vddio_reg = devm_regulator_get_optional(>dev, "vddio");
+ if (!IS_ERR(data->vddio_reg)) {
+ ret = regulator_enable(data->vddio_reg);
+ if (ret) {
+ dev_err(>dev, "failed to enable VDDIO
regulator\n");
+ goto disable_regulator_vdd;
+ }
+ } else {
+ ret = PTR_ERR(data->vddio_reg);
+ if (ret != -ENODEV)
+ goto disable_regulator_vdd;
+ }
+
+ ret = i2c_smbus_read_byte_data(client, MAG3110_WHO_AM_I);
+ if (ret < 0)
+ goto disable_regulators;
+ if (ret != MAG3110_DEVICE_ID) {
+ ret = -ENODEV;
+ goto disable_regulators;
+ }
+
data->client = client;
mutex_init(>lock);
@@ -499,7 +531,7 @@ static int mag3110_probe(struct i2c_client *client,
ret = mag3110_change_config(data, MAG3110_CTRL_REG1, data->ctrl_reg1);
if (ret < 0)
- return ret;
+ goto disable_regulators;
ret = i2c_smbus_write_byte_data(client, MAG3110_CTRL_REG2,
MAG3110_CTRL_AUTO_MRST_EN);
@@ -520,6 +552,13 @@ static int mag3110_probe(struct i2c_client *client,
iio_triggered_buffer_cleanup(indio_dev);
standby_on_error:
mag3110_standby(iio_priv(indio_dev));
+disable_regulators:
+ if (!IS_ERR(data->vddio_reg))
+ regulator_disable(data->vddio_reg);
+disable_regulator_vdd:
+ if (!IS_ERR(data->vdd_reg))
+ regulator_disable(data->vdd_reg);
+
return ret;
}
@@ -537,14 +576,55 @@ static int mag3110_remove(struct i2c_client *client)
#ifdef CONFIG_PM_SLEEP
static int mag3110_suspend(struct device *dev)
{
- return mag3110_standby(iio_priv(i2c_get_clientdata(
+ struct mag3110_data *data = iio_priv(i2c_get_clientdata(
+ to_i2c_client(dev)));
+ int ret;
+
+ ret = mag3110_standby(iio_priv(i2c_get_clientdata(
to_i2c_client(dev;
+ if (ret)
+ return ret;
+
+ if (!IS_ERR(data->vddio_reg)) {
+ ret = regulator_disable(data->vddio_reg);
+ if (ret) {
+ dev_err(dev, "failed to disable VDDIO regulator\n");
+ return ret;
+ }
+ }
+ if (!IS_ERR(data->vdd_reg)) {
+ ret = regulator_disable(data->vdd_reg);
+ if (ret) {
+ dev_err(dev, "failed to disable VDD regulator\n");
+ return ret;
+ }
+ }
+
+ return 0;
}
static int mag3110_resume(struct device *dev)
{
struct mag3110_data *data = iio_priv(i2c_get_clientdata(
to_i2c_client(dev)));
+ int ret;
+
+ if (!IS_ERR(data->vdd_reg)) {
+
[PATCH V5 1/2] dt-bindings: iio: light: isl29018: update power supply name
According to datasheet, the isl29018 has "vddd/vdda" power supply, the "vdda" and "vddd" MUST be shorted externally, and isl29023/isl29035 ONLY has "vdd" power supply, so just one regulator is needed for the driver, update the power supply name with "vdd" according to datasheet to avoid confusion. Signed-off-by: Anson Huang --- ChangeLog since V4: Since ONLY isl29018 has two power supplies and they are MUST shorted externally, so they can be treated as one power supply as well, remove "vdda" power supply and ONLY update the "vcc" with "vdd" according to datasheet. --- Documentation/devicetree/bindings/iio/light/isl29018.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/iio/light/isl29018.txt b/Documentation/devicetree/bindings/iio/light/isl29018.txt index b9bbde3..c4c4e9e 100644 --- a/Documentation/devicetree/bindings/iio/light/isl29018.txt +++ b/Documentation/devicetree/bindings/iio/light/isl29018.txt @@ -15,7 +15,7 @@ Optional properties: Refer to interrupt-controller/interrupts.txt for generic interrupt client node bindings. - - vcc-supply: phandle to the regulator that provides power to the sensor. + - vdd-supply: phandle to the regulator that provides power to the sensor. Example: -- 2.7.4
[PATCH V5 2/2] iio: light: isl29018: add optional vdd regulator operation support
The light sensor's power supply could be controlled by regulator
on some platforms, such as i.MX6Q-SABRESD board, the light sensor
isl29023's power supply is controlled by a GPIO fixed regulator,
need to make sure the regulator is enabled before any operation of
sensor, this patch adds optional vdd regulator operation support.
Signed-off-by: Anson Huang
---
ChangeLog since V4:
Since ONLY isl29018 has two power supplies and they are MUST shorted
externally, so they can be
treated as one power supply as well, using one regulator for driver.
---
drivers/iio/light/isl29018.c | 47 +---
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/light/isl29018.c b/drivers/iio/light/isl29018.c
index b45400f..5e3d1c1 100644
--- a/drivers/iio/light/isl29018.c
+++ b/drivers/iio/light/isl29018.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -95,6 +96,7 @@ struct isl29018_chip {
struct isl29018_scale scale;
int prox_scheme;
boolsuspended;
+ struct regulator*vdd_reg;
};
static int isl29018_set_integration_time(struct isl29018_chip *chip,
@@ -735,6 +737,19 @@ static int isl29018_probe(struct i2c_client *client,
mutex_init(>lock);
+ chip->vdd_reg = devm_regulator_get_optional(>dev, "vdd");
+ if (!IS_ERR(chip->vdd_reg)) {
+ err = regulator_enable(chip->vdd_reg);
+ if (err) {
+ dev_err(>dev, "failed to enable VDD
regulator\n");
+ return err;
+ }
+ } else {
+ err = PTR_ERR(chip->vdd_reg);
+ if (err != -ENODEV)
+ return err;
+ }
+
chip->type = dev_id;
chip->calibscale = 1;
chip->ucalibscale = 0;
@@ -747,12 +762,12 @@ static int isl29018_probe(struct i2c_client *client,
if (IS_ERR(chip->regmap)) {
err = PTR_ERR(chip->regmap);
dev_err(>dev, "regmap initialization fails: %d\n", err);
- return err;
+ goto disable_regulator;
}
err = isl29018_chip_init(chip);
if (err)
- return err;
+ goto disable_regulator;
indio_dev->info = isl29018_chip_info_tbl[dev_id].indio_info;
indio_dev->channels = isl29018_chip_info_tbl[dev_id].channels;
@@ -761,13 +776,22 @@ static int isl29018_probe(struct i2c_client *client,
indio_dev->dev.parent = >dev;
indio_dev->modes = INDIO_DIRECT_MODE;
- return devm_iio_device_register(>dev, indio_dev);
+ err = devm_iio_device_register(>dev, indio_dev);
+ if (!err)
+ return 0;
+
+disable_regulator:
+ if (!IS_ERR(chip->vdd_reg))
+ regulator_disable(chip->vdd_reg);
+
+ return err;
}
#ifdef CONFIG_PM_SLEEP
static int isl29018_suspend(struct device *dev)
{
struct isl29018_chip *chip = iio_priv(dev_get_drvdata(dev));
+ int ret;
mutex_lock(>lock);
@@ -777,6 +801,14 @@ static int isl29018_suspend(struct device *dev)
* So we do not have much to do here.
*/
chip->suspended = true;
+ if (!IS_ERR(chip->vdd_reg)) {
+ ret = regulator_disable(chip->vdd_reg);
+ if (ret) {
+ dev_err(dev, "failed to disable VDD regulator\n");
+ mutex_unlock(>lock);
+ return ret;
+ }
+ }
mutex_unlock(>lock);
@@ -790,6 +822,15 @@ static int isl29018_resume(struct device *dev)
mutex_lock(>lock);
+ if (!IS_ERR(chip->vdd_reg)) {
+ err = regulator_enable(chip->vdd_reg);
+ if (err) {
+ dev_err(dev, "failed to enable VDD regulator\n");
+ mutex_unlock(>lock);
+ return err;
+ }
+ }
+
err = isl29018_chip_init(chip);
if (!err)
chip->suspended = false;
--
2.7.4
Re: [PATCH] Add linux-unisoc mailing list to Spreadtrum SoC support
On Tue, 11 Dec 2018 at 11:57, Manivannan Sadhasivam wrote: > > Since Spreadtrum is now merged into Unisoc Communications, let's use the > newly created linux-unisoc mailing list for all discussions around the > Spreadtrum SoCs. > > Signed-off-by: Manivannan Sadhasivam Thanks. Acked-by: Baolin Wang > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6682420421c1..d1f768fd4f49 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2108,6 +2108,7 @@ ARM/SPREADTRUM SoC SUPPORT > M: Orson Zhai > M: Baolin Wang > M: Chunyan Zhang > +L: linux-uni...@lists.infradead.org (moderated for non-subscribers) > S: Maintained > F: arch/arm64/boot/dts/sprd > N: sprd > -- > 2.17.1 > -- Baolin Wang Best Regards
Re: [PATCH V4 2/2] iio: light: isl29018: add optional vdd/vdda regulator operation support
On 11/12/2018 12:29 pm, Anson Huang wrote: G'day Anson, Just pulled up the datasheet for this chip. The absolute max for Vdda is speced as Vddd ±0.5 With a note that Vdda should be externally shorted to Vddd. The data sheet says vdda should be connected to vdd externally, then I think we should just use one regulator vdd, then it will be much easier for the driver, what do you think? Yes I think that makes sense. -- Regards Phil
RE: [PATCH v5 3/7] mtd: spi-nor: add opcodes for octal Read/Write commands
Hi Tudor,
> -Original Message-
> From: tudor.amba...@microchip.com [mailto:tudor.amba...@microchip.com]
> Sent: Monday, December 10, 2018 4:15 PM
> To: Yogesh Narayan Gaur ; linux-
> m...@lists.infradead.org; boris.brezil...@bootlin.com; broo...@kernel.org;
> marek.va...@gmail.com; vigne...@ti.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org
> Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; linux-
> arm-ker...@lists.infradead.org; computersforpe...@gmail.com;
> frieder.schre...@exceet.de; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v5 3/7] mtd: spi-nor: add opcodes for octal Read/Write
> commands
>
> Hi, Yogesh,
>
> On 12/03/2018 10:39 AM, Yogesh Narayan Gaur wrote:
> > - Add opcodes for octal I/O commands
> > * Read : 1-1-8 and 1-8-8 protocol
> > * Write : 1-1-8 and 1-8-8 protocol
> > * opcodes for 4-byte address mode command
> >
> > - Entry of macros in _convert_3to4_xxx function
> >
> > - Add flag specifying flash support octal read commands.
> >
> > Signed-off-by: Vignesh R
> > Signed-off-by: Yogesh Gaur
> > ---
> > Changes for v5:
> > - Modified string 'octo' with 'octal'.
> > Changes for v4:
> > - None
> > Changes for v3:
> > - Modified string 'octal' with 'octo'.
> > Changes for v2:
> > - Incorporated review comments of Boris and Vignesh
> >
> > drivers/mtd/spi-nor/spi-nor.c | 16 ++--
> > include/linux/mtd/spi-nor.h | 8
> > 2 files changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > b/drivers/mtd/spi-nor/spi-nor.c index 398d273..7a2176d 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -90,6 +90,7 @@ struct flash_info {
> > #define NO_CHIP_ERASE BIT(12) /* Chip does not support chip
> erase */
> > #define SPI_NOR_SKIP_SFDP BIT(13) /* Skip parsing of SFDP tables */
> > #define USE_CLSR BIT(14) /* use CLSR command */
> > +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */
> >
> > int (*quad_enable)(struct spi_nor *nor);
> > };
> > @@ -209,6 +210,8 @@ static inline u8 spi_nor_convert_3to4_read(u8 opcode)
> > { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B },
> > { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B },
> > { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B },
> > + { SPINOR_OP_READ_1_1_8, SPINOR_OP_READ_1_1_8_4B },
> > + { SPINOR_OP_READ_1_8_8, SPINOR_OP_READ_1_8_8_4B },
> >
> > { SPINOR_OP_READ_1_1_1_DTR,
> SPINOR_OP_READ_1_1_1_DTR_4B },
> > { SPINOR_OP_READ_1_2_2_DTR,
> SPINOR_OP_READ_1_2_2_DTR_4B },
> > @@ -225,6 +228,8 @@ static inline u8 spi_nor_convert_3to4_program(u8
> opcode)
> > { SPINOR_OP_PP, SPINOR_OP_PP_4B },
> > { SPINOR_OP_PP_1_1_4, SPINOR_OP_PP_1_1_4_4B },
> > { SPINOR_OP_PP_1_4_4, SPINOR_OP_PP_1_4_4_4B },
> > + { SPINOR_OP_PP_1_1_8, SPINOR_OP_PP_1_1_8_4B },
> > + { SPINOR_OP_PP_1_8_8, SPINOR_OP_PP_1_8_8_4B },
> > };
> >
> > return spi_nor_convert_opcode(opcode, spi_nor_3to4_program, @@
> > -2093,7 +2098,7 @@ enum spi_nor_read_command_index {
> > SNOR_CMD_READ_4_4_4,
> > SNOR_CMD_READ_1_4_4_DTR,
> >
> > - /* Octo SPI */
> > + /* Octal SPI */
> > SNOR_CMD_READ_1_1_8,
> > SNOR_CMD_READ_1_8_8,
> > SNOR_CMD_READ_8_8_8,
> > @@ -2110,7 +2115,7 @@ enum spi_nor_pp_command_index {
> > SNOR_CMD_PP_1_4_4,
> > SNOR_CMD_PP_4_4_4,
> >
> > - /* Octo SPI */
> > + /* Octal SPI */
> > SNOR_CMD_PP_1_1_8,
> > SNOR_CMD_PP_1_8_8,
> > SNOR_CMD_PP_8_8_8,
> > @@ -3195,6 +3200,13 @@ static int spi_nor_init_params(struct spi_nor *nor,
> > SNOR_PROTO_1_1_4);
> > }
> >
> > + if (info->flags & SPI_NOR_OCTAL_READ) {
> > + params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8;
> > + spi_nor_set_read_settings(
> >reads[SNOR_CMD_READ_1_1_8],
> > + 0, 8, SPINOR_OP_READ_1_1_8,
> > + SNOR_PROTO_1_1_8);
> > + }
> > +> /* Page Program settings. */
> > params->hwcaps.mask |= SNOR_HWCAPS_PP;
> > spi_nor_set_pp_settings(>page_programs[SNOR_CMD_PP],
>
> At the end of spi_nor_init_params we check the conditions for parsing the
> sfdp.
> Shouldn't SPI_NOR_OCTAL_READ trigger the sfdp parsing when
> SPI_NOR_SKIP_SFDP is not set?
I guess for now setting only SPI_NOR_OCTAL_READ didn't trigger SFDP parsing as
SFDP parsing would start only when we have both of the below condition are true
if ((info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) &&
!(info->flags & SPI_NOR_SKIP_SFDP)) {
But for case when we have only set SPI_NOR_OCTAL_READ then first condition
check would be false and hence SFDP parsing won't occur.
I guess, we needn't to have SFDP parsing only when SPI_NOR_SKIP_SFDP is set.
Thus would going to modify the
Re: [PATCH 0/2] Graph fixes for using multiple endpoints per port
* Kuninori Morimoto [181211 03:31]:
>
> Hi Tony
>
> > Here are two fixes that allow me to have multiple endpoints defined in
> > the dts file for audio-graph-card. To do that, we need to fix up few
> > issues as the graph binding Documentation/devicetree/bindings/graph.txt
> > allows multiple endpoints per port. This allows configuring TDM codecs
> > for I2S for example.
> >
> > Kuninori-san, can you please check if this makes sense to you and
> > compare against the graph binding?
>
> This looks a little bit strange for me.
> Can you show me your DT for it ?
Sure, adding also Sebastian to Cc. Here's what I currently have for droid 4
dts with two codecs on I2S. Please just ignore the GNSS parts there..
The TDM configuration is all done in the cpcap_audio_codec via set_tdm_slot().
The modem voice call codec is a serdev driver :) I'll need some more time to
be able to post patches but it's basically working for voice calls.
Regards,
Tony
8< -
diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts
b/arch/arm/boot/dts/omap4-droid4-xt894.dts
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -653,6 +653,28 @@
pinctrl-0 = <_pins>;
interrupts-extended = < GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH
_pmx_core 0xfc>;
+
+ modem {
+ compatible = "motorola,mapphone-mdm6600-serdev";
+ phys = <_phy>;
+ phy-names = "usb";
+
+ mot_mdm6600_audio: audio-codec {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+
+ port@0 {
+ mot_mdm6600_audio_codec0: endpoint {
+ remote-endpoint = <_dai_mdm>;
+ };
+ };
+ };
+
+ gnss {
+ compatible = "motorola,mapphone-mdm6600-gnss";
+ };
+ };
};
{
@@ -746,12 +768,18 @@
status = "okay";
mcbsp3_port: port {
- cpu_dai3: endpoint {
+ cpu_dai3: endpoint@0 {
dai-format = "dsp_a";
frame-master = <_audio_codec1>;
bitclock-master = <_audio_codec1>;
remote-endpoint = <_audio_codec1>;
};
+ cpu_dai_mdm: endpoint@1 {
+ dai-format = "dsp_a";
+ frame-master = <_audio_codec1>;
+ bitclock-master = <_audio_codec1>;
+ remote-endpoint = <_mdm6600_audio_codec0>;
+ };
};
};
Re: [PATCH] mm: thp: fix soft dirty for migration when split
On Mon, Dec 10, 2018 at 07:50:52PM +0300, Konstantin Khlebnikov wrote:
> On Fri, Dec 7, 2018 at 6:34 AM Peter Xu wrote:
> >
> > On Thu, Dec 06, 2018 at 04:46:04PM +0800, Peter Xu wrote:
> > > When splitting a huge migrating PMD, we'll transfer the soft dirty bit
> > > from the huge page to the small pages. However we're possibly using a
> > > wrong data since when fetching the bit we're using pmd_soft_dirty()
> > > upon a migration entry. Fix it up.
> >
> > Note that if my understanding is correct about the problem then if
> > without the patch there is chance to lose some of the dirty bits in
> > the migrating pmd pages (on x86_64 we're fetching bit 11 which is part
> > of swap offset instead of bit 2) and it could potentially corrupt the
> > memory of an userspace program which depends on the dirty bit.
>
> It seems this code is broken in case of pmd_migraion:
>
> old_pmd = pmdp_invalidate(vma, haddr, pmd);
>
> #ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
> pmd_migration = is_pmd_migration_entry(old_pmd);
> if (pmd_migration) {
> swp_entry_t entry;
>
> entry = pmd_to_swp_entry(old_pmd);
> page = pfn_to_page(swp_offset(entry));
> } else
> #endif
> page = pmd_page(old_pmd);
> VM_BUG_ON_PAGE(!page_count(page), page);
> page_ref_add(page, HPAGE_PMD_NR - 1);
> if (pmd_dirty(old_pmd))
> SetPageDirty(page);
> write = pmd_write(old_pmd);
> young = pmd_young(old_pmd);
> soft_dirty = pmd_soft_dirty(old_pmd);
>
> Not just soft_dirt - all bits (dirty, write, young) have diffrent encoding
> or not present at all for migration entry.
Hi, Konstantin,
Actually I noticed it but I thought it didn't hurt since both
write/young flags are not used at all when applying to the small pages
when pmd_migration==true. But indeed there's at least an unexpected
side effect of an extra call to SetPageDirty() that I missed.
I'll repost soon. Thanks!
--
Peter Xu
Re: rcu_preempt caused oom
On Mon, Dec 10, 2018 at 04:38:38PM -0800, Paul E. McKenney wrote:
> On Mon, Dec 10, 2018 at 06:56:18AM +, He, Bo wrote:
> > Hi,
> >We have start the test with the CONFIG_PROVE_RCU=y, and also add one 2s
> > to detect the preempt rcu hang, hope we can get more useful logs tomorrow.
> >I also enclosed the config and the debug patches for you review.
>
> I instead suggest the (lightly tested) debug patch shown below, which
> tracks wakeups of RCU's grace-period kthreads and dumps them out if a
> given requested grace period fails to start. Again, it is necessary to
> build with CONFIG_PROVE_RCU=y, that is, with CONFIG_PROVE_LOCKING=y.
Right. This time without commenting out the wakeup as a test of the
diagnostic. :-/
Please use the patch below instead of the one that I sent in my
previous email.
Thanx, Paul
commit adfc7dff659495a3433d5084256be59eee0ac6df
Author: Paul E. McKenney
Date: Mon Dec 10 16:33:59 2018 -0800
rcu: Improve diagnostics for failed RCU grace-period start
Backported from v4.21/v5.0
If a grace period fails to start (for example, because you commented
out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core()
will invoke rcu_check_gp_start_stall(), which will notice and complain.
However, this complaint is lacking crucial debugging information such
as when the last wakeup executed and what the value of ->gp_seq was at
that time. This commit therefore removes the current pr_alert() from
rcu_check_gp_start_stall(), instead invoking show_rcu_gp_kthreads(),
which has been updated to print the needed information, which is collected
by rcu_gp_kthread_wake().
Signed-off-by: Paul E. McKenney
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0b760c1369f7..4bcd8753e293 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -626,25 +626,57 @@ void rcu_sched_force_quiescent_state(void)
}
EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state);
+/*
+ * Convert a ->gp_state value to a character string.
+ */
+static const char *gp_state_getname(short gs)
+{
+ if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names))
+ return "???";
+ return gp_state_names[gs];
+}
+
+/*
+ * Return the root node of the specified rcu_state structure.
+ */
+static struct rcu_node *rcu_get_root(struct rcu_state *rsp)
+{
+ return >node[0];
+}
+
/*
* Show the state of the grace-period kthreads.
*/
void show_rcu_gp_kthreads(void)
{
int cpu;
+ unsigned long j;
+ unsigned long ja;
+ unsigned long jr;
+ unsigned long jw;
struct rcu_data *rdp;
struct rcu_node *rnp;
struct rcu_state *rsp;
+ j = jiffies;
for_each_rcu_flavor(rsp) {
- pr_info("%s: wait state: %d ->state: %#lx\n",
- rsp->name, rsp->gp_state, rsp->gp_kthread->state);
+ ja = j - READ_ONCE(rsp->gp_activity);
+ jr = j - READ_ONCE(rsp->gp_req_activity);
+ jw = j - READ_ONCE(rsp->gp_wake_time);
+ pr_info("%s: wait state: %s(%d) ->state: %#lx delta
->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld
->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n",
+ rsp->name, gp_state_getname(rsp->gp_state),
+ rsp->gp_state,
+ rsp->gp_kthread ? rsp->gp_kthread->state : 0x1L,
+ ja, jr, jw, (long)READ_ONCE(rsp->gp_wake_seq),
+ (long)READ_ONCE(rsp->gp_seq),
+ (long)READ_ONCE(rcu_get_root(rsp)->gp_seq_needed),
+ READ_ONCE(rsp->gp_flags));
rcu_for_each_node_breadth_first(rsp, rnp) {
if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed))
continue;
- pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed
%lu\n",
- rnp->grplo, rnp->grphi, rnp->gp_seq,
- rnp->gp_seq_needed);
+ pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed
%ld\n",
+ rnp->grplo, rnp->grphi, (long)rnp->gp_seq,
+ (long)rnp->gp_seq_needed);
if (!rcu_is_leaf_node(rnp))
continue;
for_each_leaf_node_possible_cpu(rnp, cpu) {
@@ -653,8 +685,8 @@ void show_rcu_gp_kthreads(void)
ULONG_CMP_GE(rsp->gp_seq,
rdp->gp_seq_needed))
continue;
- pr_info("\tcpu %d ->gp_seq_needed %lu\n",
- cpu, rdp->gp_seq_needed);
+
Re: [PATCH v3] kbuild: Add support for DT binding schema checks
Hi Rob, On Tue, Dec 11, 2018 at 5:50 AM Rob Herring wrote: > > This adds the build infrastructure for checking DT binding schema > documents and validating dts files using the binding schema. > > Check DT binding schema documents: > make dt_binding_check > > Build dts files and check using DT binding schema: > make dtbs_check > > Optionally, DT_SCHEMA_FILES can passed in with a schema file(s) to use Perhaps, "can be passed" ? > for validation. This makes it easier to find and fix errors generated by > a specific schema. > > Currently, the validation targets are separate from a normal build to > avoid a hard dependency on the external DT schema project and because > there are lots of warnings generated. > > Cc: Jonathan Corbet > Cc: Mark Rutland > Cc: Masahiro Yamada > Cc: Michal Marek > Cc: linux-...@vger.kernel.org > Cc: devicet...@vger.kernel.org > Cc: linux-kbu...@vger.kernel.org > Signed-off-by: Rob Herring > --- > v3: > - Fix error causing only 1st schema file to get used. > - Add a more useful error message when dtc is missing YAML support > telling the user they need to install libyaml devel package. > > > .gitignore | 1 + > Documentation/Makefile | 2 +- > Documentation/devicetree/bindings/.gitignore | 1 + > Documentation/devicetree/bindings/Makefile | 33 + > Makefile | 11 -- > scripts/Makefile.lib | 37 ++-- > 6 files changed, 80 insertions(+), 5 deletions(-) > create mode 100644 Documentation/devicetree/bindings/.gitignore > create mode 100644 Documentation/devicetree/bindings/Makefile > > diff --git a/.gitignore b/.gitignore > index 97ba6b79834c..a20ac26aa2f5 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -15,6 +15,7 @@ > *.bin > *.bz2 > *.c.[012]*.* > +*.dt.yaml > *.dtb > *.dtb.S > *.dwo > diff --git a/Documentation/Makefile b/Documentation/Makefile > index 2ca77ad0f238..9786957c6a35 100644 > --- a/Documentation/Makefile > +++ b/Documentation/Makefile > @@ -2,7 +2,7 @@ > # Makefile for Sphinx documentation > # > > -subdir-y := > +subdir-y := devicetree/bindings/ > > # You can set these variables from the command line. > SPHINXBUILD = sphinx-build > diff --git a/Documentation/devicetree/bindings/.gitignore > b/Documentation/devicetree/bindings/.gitignore > new file mode 100644 > index ..d9194c02dd08 > --- /dev/null > +++ b/Documentation/devicetree/bindings/.gitignore > @@ -0,0 +1 @@ > +*.example.dts > diff --git a/Documentation/devicetree/bindings/Makefile > b/Documentation/devicetree/bindings/Makefile > new file mode 100644 > index ..43f8657ab070 > --- /dev/null > +++ b/Documentation/devicetree/bindings/Makefile > @@ -0,0 +1,33 @@ > +# SPDX-License-Identifier: GPL-2.0 > +DT_DOC_CHECKER ?= dt-doc-validate > +DT_EXTRACT_EX ?= dt-extract-example > +DT_MK_SCHEMA ?= dt-mk-schema > +DT_MK_SCHEMA_FLAGS := $(if $(DT_SCHEMA_FILES), -u) > + > +quiet_cmd_chk_binding = CHKDT $< In convention, the short log displays the target name instead of the prerequisite. If O=foo/bar is given, $< shows the full path, then log will look like follows: CHKDT /home/masahiro/ref/linux-devicetree/Documentation/devicetree/bindings/arm/calxeda.yaml DTC Documentation/devicetree/bindings/arm/calxeda.example.dtb CHKDT /home/masahiro/ref/linux-devicetree/Documentation/devicetree/bindings/arm/qcom.yaml DTC Documentation/devicetree/bindings/arm/qcom.example.dtb CHKDT /home/masahiro/ref/linux-devicetree/Documentation/devicetree/bindings/arm/xilinx.yaml DTC Documentation/devicetree/bindings/arm/xilinx.example.dtb CHKDT /home/masahiro/ref/linux-devicetree/Documentation/devicetree/bindings/arm/ti/nspire.yaml DTC Documentation/devicetree/bindings/arm/ti/nspire.example.dtb CHKDT /home/masahiro/ref/linux-devicetree/Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml DTC Documentation/devicetree/bindings/arm/ti/ti,davinci.example.dtb CHKDT /home/masahiro/ref/linux-devicetree/Documentation/devicetree/bindings/arm/altera.yaml You might think it is ugly. > + cmd_chk_binding = (set -e; \ > + $(DT_DOC_CHECKER) $< ; \ > + mkdir -p $(dir $@) ; \ > + $(DT_EXTRACT_EX) $< > $@ ) - 'set -e' is redundant because if_changed already has it. - 'mkdir mkdir -p $(dir $@)' is also redundant because scripts/Makefile.build automatically creates it. - You do not need to execute this in a sub-shell You can simplify like this: cmd_chk_binding = $(DT_DOC_CHECKER) $< ; \ $(DT_EXTRACT_EX) $< > $@ > +$(obj)/%.example.dts: $(src)/%.yaml FORCE > + $(call if_changed,chk_binding) > + > +DT_TMP_SCHEMA := .schema.yaml.tmp BTW, why does this file start with a period? What is the meaning of '.tmp' extension? > +extra-y += $(DT_TMP_SCHEMA) > + >
RE: [PATCH V4 2/2] iio: light: isl29018: add optional vdd/vdda regulator operation support
Hi, Phil
Best Regards!
Anson Huang
> -Original Message-
> From: Phil Reid [mailto:pr...@electromag.com.au]
> Sent: 2018年12月11日 11:56
> To: Anson Huang ; ji...@kernel.org;
> knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net;
> robh...@kernel.org; mark.rutl...@arm.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> feste...@gmail.com
> Cc: dl-linux-imx
> Subject: Re: [PATCH V4 2/2] iio: light: isl29018: add optional vdd/vdda
> regulator operation support
>
> G'day Anson,
>
> Just pulled up the datasheet for this chip.
>
> The absolute max for Vdda is speced as Vddd +/-0.5 With a note that Vdda
> should be externally shorted to Vddd.
The data sheet says vdda should be connected to vdd externally, then I think we
should just
use one regulator vdd, then it will be much easier for the driver, what do you
think?
Anson.
>
>
> On 11/12/2018 11:43 am, Anson Huang wrote:
> > Hi, Phil
> >
> > Best Regards!
> > Anson Huang
> >
> >> -Original Message-
> >> From: Phil Reid [mailto:pr...@electromag.com.au]
> >> Sent: 2018年12月11日 11:36
> >> To: Anson Huang ; ji...@kernel.org;
> >> knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net;
> >> robh...@kernel.org; mark.rutl...@arm.com; linux-...@vger.kernel.org;
> >> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> feste...@gmail.com
> >> Cc: dl-linux-imx
> >> Subject: Re: [PATCH V4 2/2] iio: light: isl29018: add optional
> >> vdd/vdda regulator operation support
> >>
> >> On 11/12/2018 11:24 am, Anson Huang wrote:
> >>> The light sensor's power supply could be controlled by regulator on
> >>> some platforms, such as i.MX6Q-SABRESD board, the light sensor
> >>> isl29023's power supply is controlled by a GPIO fixed regulator,
> >>> need to make sure the regulator is enabled before any operation of
> >>> sensor, this patch adds optional vdd/vdda regulator operation support.
> >>>
> >>> Signed-off-by: Anson Huang
> >>> ---
> >>> ChangeLog since V3:
> >>> - improve the error handling of devm_regulator_get_optional;
> >>> - make sure regulators are disabled in error path.
> >>> ---
> >>>drivers/iio/light/isl29018.c | 83
> >> ++--
> >>>1 file changed, 80 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/iio/light/isl29018.c
> >>> b/drivers/iio/light/isl29018.c index b45400f..a21652b 100644
> >>> --- a/drivers/iio/light/isl29018.c
> >>> +++ b/drivers/iio/light/isl29018.c
> >>> @@ -23,6 +23,7 @@
> >>>#include
> >>>#include
> >>>#include
> >>> +#include
> >>>#include
> >>>#include
> >>>#include
> >>> @@ -95,6 +96,8 @@ struct isl29018_chip {
> >>> struct isl29018_scale scale;
> >>> int prox_scheme;
> >>> boolsuspended;
> >>> + struct regulator*vdd_reg;
> >>> + struct regulator*vdda_reg;
> >>>};
> >>>
> >>>static int isl29018_set_integration_time(struct isl29018_chip
> >>> *chip, @@ -735,6 +738,34 @@ static int isl29018_probe(struct
> >>> i2c_client *client,
> >>>
> >>> mutex_init(>lock);
> >>>
> >>> + chip->vdd_reg = devm_regulator_get_optional(>dev, "vdd");
> >>> + if (!IS_ERR(chip->vdd_reg)) {
> >>> + err = regulator_enable(chip->vdd_reg);
> >>> + if (err) {
> >>> + dev_err(>dev, "failed to enable VDD
> >>> regulator\n");
> >>> + return err;
> >>> + }
> >>> + } else {
> >>> + err = PTR_ERR(chip->vdd_reg);
> >>> + if (err != -ENODEV)
> >>> + return err;
> >>> + }
> >>> +
> >>> + chip->vdda_reg = devm_regulator_get_optional(>dev,
> "vdda");
> >>> + if (!IS_ERR(chip->vdda_reg)) {
> >>> + err = regulator_enable(chip->vdda_reg);
> >>> + if (err) {
> >>> + dev_err(>dev, "failed to enable VDDA
> regulator\n");
> >>> + if (!IS_ERR(chip->vdd_reg))
> >>> + regulator_disable(chip->vdd_reg);
> >>> + return err;
> Not sure about this case at the call to enable failed so I think you only want
> the first one to be disabled.
> You could add another goto statement thou, see below.
>
>
> >>> + }
> >>> + } else {
> >>> + err = PTR_ERR(chip->vdda_reg);
> >>> + if (err != -ENODEV)
> >>> + return err;
> >> maybe goto disable_regulators; to disable vdd.
> >
> > Agree, I will use " goto disable_regulators;" in both here and upper
> > regulator
> enable fail case.
> > Please help review V5, thanks.
>
> Here its safe to call both as vdda_reg will be an error ptr.
>
> >
> > Anson
> >
> >>
> >>> + }
> >>> +
> >>> chip->type = dev_id;
> >>> chip->calibscale = 1;
> >>> chip->ucalibscale = 0;
> >>> @@ -747,12 +778,12 @@ static int isl29018_probe(struct i2c_client
> *client,
> >>> if (IS_ERR(chip->regmap)) {
> >>> err = PTR_ERR(chip->regmap);
> >>>
[PATCH] net/ibmvnic: Remove tests of member address
The driver was checking for non-NULL address.
- adapter->napi[i]
This is pointless as these will be always non-NULL, since the
'dapter->napi' is allocated in init_napi().
It is safe to get rid of useless checks for addresses to fix the
coccinelle warning:
>>drivers/net/ethernet/ibm/ibmvnic.c: test of a variable/field address
Since such statements always return true, they are redundant.
Signed-off-by: Wen Yang
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: Thomas Falcon
CC: John Allen
CC: "David S. Miller"
CC: linuxppc-...@lists.ozlabs.org
CC: net...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/ibm/ibmvnic.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index ed50b8dee44f..14d00985f087 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -773,11 +773,8 @@ static void release_napi(struct ibmvnic_adapter *adapter)
return;
for (i = 0; i < adapter->num_active_rx_napi; i++) {
- if (>napi[i]) {
- netdev_dbg(adapter->netdev,
- "Releasing napi[%d]\n", i);
- netif_napi_del(>napi[i]);
- }
+ netdev_dbg(adapter->netdev, "Releasing napi[%d]\n", i);
+ netif_napi_del(>napi[i]);
}
kfree(adapter->napi);
--
2.19.1
[PATCH] drivers: net: xgene: Remove unnecessary forward declarations
Clang warns:
drivers/net/ethernet/apm/xgene/xgene_enet_main.c:33:36: warning:
tentative array definition assumed to have one element
static const struct acpi_device_id xgene_enet_acpi_match[];
^
1 warning generated.
Both xgene_enet_acpi_match and xgene_enet_of_match are defined before
their uses at the bottom of the file so this is unnecessary. When
CONFIG_ACPI is disabled, ACPI_PTR becomes NULL so xgene_enet_acpi_match
doesn't need to be defined.
Signed-off-by: Nathan Chancellor
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 3b889efddf78..50dd6bf176d0 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -29,9 +29,6 @@
#define RES_RING_CSR 1
#define RES_RING_CMD 2
-static const struct of_device_id xgene_enet_of_match[];
-static const struct acpi_device_id xgene_enet_acpi_match[];
-
static void xgene_enet_init_bufpool(struct xgene_enet_desc_ring *buf_pool)
{
struct xgene_enet_raw_desc16 *raw_desc;
--
2.20.0
Re: [PATCH] pci: avoid bridge feature re-probing on hotplug
On Tue, Dec 11, 2018 at 02:45:44AM +, xuyandong wrote:
>
>
> > -Original Message-
> > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > Sent: Tuesday, December 11, 2018 10:19 AM
> > To: linux-kernel@vger.kernel.org
> > Cc: xuyandong ; sta...@vger.kernel.org; Yinghai
> > Lu ; Jesse Barnes ; Bjorn
> > Helgaas ; linux-...@vger.kernel.org
> > Subject: [PATCH] pci: avoid bridge feature re-probing on hotplug
> >
> > commit 1f82de10d6 ("PCI/x86: don't assume prefetchable ranges are
> > 64bit") added probing of bridge support for 64 bit memory each time bridge
> > is
> > re-enumerated.
> >
> > Unfortunately this probing is destructive if any device behind the bridge
> > is in
> > use at this time.
> >
> > There's no real need to re-probe the bridge features as the regiters in
> > question
> > never change - detect that using the memory flag being set and skip the
> > probing.
> > Avoiding repeated calls to pci_bridge_check_ranges might be even nicer would
> > be a bigger patch and probably not appropriate on stable.
> >
> > Reported-by: xuyandong
> > Cc: sta...@vger.kernel.org
> > Cc: Yinghai Lu
> > Cc: Jesse Barnes
> > Signed-off-by: Michael S. Tsirkin
>
> Tested-by: xuyandong
Bjorn could you queue this for this release?
> > ---
> >
> > This issue has been reported on upstream Linux and Centos.
> >
> > drivers/pci/setup-bus.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index
> > ed960436df5e..7ab42f76579e 100644
> > --- a/drivers/pci/setup-bus.c
> > +++ b/drivers/pci/setup-bus.c
> > @@ -741,6 +741,13 @@ static void pci_bridge_check_ranges(struct pci_bus
> > *bus)
> > struct resource *b_res;
> >
> > b_res = >resource[PCI_BRIDGE_RESOURCES];
> > +
> > + /* Don't re-check after this was called once already:
> > +* important since bridge might be in use.
> > +*/
> > + if (b_res[1].flags & IORESOURCE_MEM)
> > + return;
> > +
> > b_res[1].flags |= IORESOURCE_MEM;
> >
> > pci_read_config_word(bridge, PCI_IO_BASE, );
> > --
> > MST
Re: [PATCH net 2/4] vhost_net: rework on the lock ordering for busy polling
On Tue, Dec 11, 2018 at 11:06:43AM +0800, Jason Wang wrote:
>
> On 2018/12/11 上午9:34, Michael S. Tsirkin wrote:
> > On Mon, Dec 10, 2018 at 05:44:52PM +0800, Jason Wang wrote:
> > > When we try to do rx busy polling in tx path in commit 441abde4cd84
> > > ("net: vhost: add rx busy polling in tx path"), we lock rx vq mutex
> > > after tx vq mutex is held. This may lead deadlock so we try to lock vq
> > > one by one in commit 78139c94dc8c ("net: vhost: lock the vqs one by
> > > one"). With this commit, we avoid the deadlock with the assumption
> > > that handle_rx() and handle_tx() run in a same process. But this
> > > commit remove the protection for IOTLB updating which requires the
> > > mutex of each vq to be held.
> > >
> > > To solve this issue, the first step is to have a exact same lock
> > > ordering for vhost_net. This is done through:
> > >
> > > - For handle_rx(), if busy polling is enabled, lock tx vq immediately.
> > > - For handle_tx(), always lock rx vq before tx vq, and unlock it if
> > >busy polling is not enabled.
> > > - Remove the tricky locking codes in busy polling.
> > >
> > > With this, we can have a exact same lock ordering for vhost_net, this
> > > allows us to safely revert commit 78139c94dc8c ("net: vhost: lock the
> > > vqs one by one") in next patch.
> > >
> > > The patch will add two more atomic operations on the tx path during
> > > each round of handle_tx(). 1 byte TCP_RR does not notice such
> > > overhead.
> > >
> > > Fixes: commit 78139c94dc8c ("net: vhost: lock the vqs one by one")
> > > Cc: Tonghao Zhang
> > > Signed-off-by: Jason Wang
> > > ---
> > > drivers/vhost/net.c | 18 +++---
> > > 1 file changed, 15 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> > > index ab11b2bee273..5f272ab4d5b4 100644
> > > --- a/drivers/vhost/net.c
> > > +++ b/drivers/vhost/net.c
> > > @@ -513,7 +513,6 @@ static void vhost_net_busy_poll(struct vhost_net *net,
> > > struct socket *sock;
> > > struct vhost_virtqueue *vq = poll_rx ? tvq : rvq;
> > > - mutex_lock_nested(>mutex, poll_rx ? VHOST_NET_VQ_TX:
> > > VHOST_NET_VQ_RX);
> > > vhost_disable_notify(>dev, vq);
> > > sock = rvq->private_data;
> > > @@ -543,8 +542,6 @@ static void vhost_net_busy_poll(struct vhost_net *net,
> > > vhost_net_busy_poll_try_queue(net, vq);
> > > else if (!poll_rx) /* On tx here, sock has no rx data. */
> > > vhost_enable_notify(>dev, rvq);
> > > -
> > > - mutex_unlock(>mutex);
> > > }
> > > static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
> > > @@ -913,10 +910,16 @@ static void handle_tx_zerocopy(struct vhost_net
> > > *net, struct socket *sock)
> > > static void handle_tx(struct vhost_net *net)
> > > {
> > > struct vhost_net_virtqueue *nvq = >vqs[VHOST_NET_VQ_TX];
> > > + struct vhost_net_virtqueue *nvq_rx = >vqs[VHOST_NET_VQ_RX];
> > > struct vhost_virtqueue *vq = >vq;
> > > + struct vhost_virtqueue *vq_rx = _rx->vq;
> > > struct socket *sock;
> > > + mutex_lock_nested(_rx->mutex, VHOST_NET_VQ_RX);
> > > mutex_lock_nested(>mutex, VHOST_NET_VQ_TX);
> > > + if (!vq->busyloop_timeout)
> > > + mutex_unlock(_rx->mutex);
> > > +
> > > sock = vq->private_data;
> > > if (!sock)
> > > goto out;
> > > @@ -933,6 +936,8 @@ static void handle_tx(struct vhost_net *net)
> > > handle_tx_copy(net, sock);
> > > out:
> > > + if (vq->busyloop_timeout)
> > > + mutex_unlock(_rx->mutex);
> > > mutex_unlock(>mutex);
> > > }
> > So rx mutex taken on tx path now. And tx mutex is on rc path ... This
> > is just messed up. Why can't tx polling drop rx lock before
> > getting the tx lock and vice versa?
>
>
> Because we want to poll both tx and rx virtqueue at the same time
> (vhost_net_busy_poll()).
>
> while (vhost_can_busy_poll(endtime)) {
> if (vhost_has_work(>dev)) {
> *busyloop_intr = true;
> break;
> }
>
> if ((sock_has_rx_data(sock) &&
> !vhost_vq_avail_empty(>dev, rvq)) ||
> !vhost_vq_avail_empty(>dev, tvq))
> break;
>
> cpu_relax();
>
> }
>
>
> And we disable kicks and notification for better performance.
Right but it's all slow path - it happens when queue is
otherwise empty. So this is what I am saying: let's drop the locks
we hold around this.
>
> >
> > Or if we really wanted to force everything to be locked at
> > all times, let's just use a single mutex.
> >
> >
> >
>
> We could, but it might requires more changes which could be done for -next I
> believe.
>
>
> Thanks
I'd rather we kept the fine grained locking. E.g. people are
looking at splitting the tx and rx threads. But if not possible
let's fix it cleanly with a coarse-grained one. A mess here will
just create more trouble later.
--
MST
