Re: [PATCH] scsi: iscsi_tcp: set BDI_CAP_STABLE_WRITES when data digest enabled
Would anyone please take a review at this patch ?
Thanks in advace
Jianchao
On 03/07/2018 08:29 PM, Jianchao Wang wrote:
> iscsi tcp will first send out data, then calculate and send data
> digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will
> be written in spite of the on going writeback. Consequently, wrong
> digest will be got and sent to target.
>
> To fix this, set BDI_CAP_STABLE_WRITES when data digest is enabled
> in iscsi_tcp .slave_configure callback.
>
> Signed-off-by: Jianchao Wang
> ---
> drivers/scsi/iscsi_tcp.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> index 6198559..261c686 100644
> --- a/drivers/scsi/iscsi_tcp.c
> +++ b/drivers/scsi/iscsi_tcp.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -954,6 +955,12 @@ static int iscsi_sw_tcp_slave_alloc(struct scsi_device
> *sdev)
>
> static int iscsi_sw_tcp_slave_configure(struct scsi_device *sdev)
> {
> + struct iscsi_sw_tcp_host *tcp_sw_host = iscsi_host_priv(sdev->host);
> + struct iscsi_session *session = tcp_sw_host->session;
> + struct iscsi_conn *conn = session->leadconn;
> +
> + if (conn->datadgst_en)
> + sdev->request_queue->backing_dev_info->capabilities |=
> BDI_CAP_STABLE_WRITES;
> blk_queue_bounce_limit(sdev->request_queue, BLK_BOUNCE_ANY);
> blk_queue_dma_alignment(sdev->request_queue, 0);
> return 0;
>
Re: [PATCH] pinctrl: uniphier: divide I2S and S/PDIF audio out pin-mux group
2018-03-14 15:35 GMT+09:00 Katsuhiro Suzuki :
> This patch divides large pin-mux group 'aio' of UniPhier LD11/LD20
> to 2 groups as following:
> aout1 : 8ch I2S output: AO1DACCK, AO1BCK, AO1LRCK, AO1D[0-2]
> aoutiec1: S/PDIF output : AO1IEC, AO1ARC
>
> Signed-off-by: Katsuhiro Suzuki
> ---
Acked-by: Masahiro Yamada
> drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c | 15 ++-
> drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 15 ++-
> 2 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
> b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
> index 8a5ecd6277d8..5ec5afa70413 100644
> --- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
> +++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
> @@ -470,8 +470,10 @@ static const struct pinctrl_pin_desc
> uniphier_ld11_pins[] = {
> 166, UNIPHIER_PIN_PULL_DOWN),
> };
>
> -static const unsigned aout_pins[] = {135, 136, 137, 138, 139, 140, 141, 142};
> -static const int aout_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0};
> +static const unsigned aout1_pins[] = {137, 138, 139, 140, 141, 142};
> +static const int aout1_muxvals[] = {0, 0, 0, 0, 0, 0};
> +static const unsigned aoutiec1_pins[] = {135, 136};
> +static const int aoutiec1_muxvals[] = {0, 0};
> static const unsigned int emmc_pins[] = {19, 20, 21, 22, 23, 24, 25};
> static const int emmc_muxvals[] = {0, 0, 0, 0, 0, 0, 0};
> static const unsigned emmc_dat8_pins[] = {26, 27, 28, 29};
> @@ -547,7 +549,8 @@ static const unsigned int gpio_range5_pins[] = {
> };
>
> static const struct uniphier_pinctrl_group uniphier_ld11_groups[] = {
> - UNIPHIER_PINCTRL_GROUP(aout),
> + UNIPHIER_PINCTRL_GROUP(aout1),
> + UNIPHIER_PINCTRL_GROUP(aoutiec1),
> UNIPHIER_PINCTRL_GROUP(emmc),
> UNIPHIER_PINCTRL_GROUP(emmc_dat8),
> UNIPHIER_PINCTRL_GROUP(ether_rmii),
> @@ -573,7 +576,8 @@ static const struct uniphier_pinctrl_group
> uniphier_ld11_groups[] = {
> UNIPHIER_PINCTRL_GROUP_GPIO(gpio_range5),
> };
>
> -static const char * const aout_groups[] = {"aout"};
> +static const char * const aout1_groups[] = {"aout1"};
> +static const char * const aoutiec1_groups[] = {"aoutiec1"};
> static const char * const emmc_groups[] = {"emmc", "emmc_dat8"};
> static const char * const ether_rmii_groups[] = {"ether_rmii"};
> static const char * const i2c0_groups[] = {"i2c0"};
> @@ -592,7 +596,8 @@ static const char * const usb1_groups[] = {"usb1"};
> static const char * const usb2_groups[] = {"usb2"};
>
> static const struct uniphier_pinmux_function uniphier_ld11_functions[] = {
> - UNIPHIER_PINMUX_FUNCTION(aout),
> + UNIPHIER_PINMUX_FUNCTION(aout1),
> + UNIPHIER_PINMUX_FUNCTION(aoutiec1),
> UNIPHIER_PINMUX_FUNCTION(emmc),
> UNIPHIER_PINMUX_FUNCTION(ether_rmii),
> UNIPHIER_PINMUX_FUNCTION(i2c0),
> diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
> b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
> index 3be7967edae0..eb5d4cc6a3ba 100644
> --- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
> +++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
> @@ -551,8 +551,10 @@ static const struct pinctrl_pin_desc
> uniphier_ld20_pins[] = {
> 175, UNIPHIER_PIN_PULL_DOWN),
> };
>
> -static const unsigned aout_pins[] = {135, 136, 137, 138, 139, 140, 141, 142};
> -static const int aout_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0};
> +static const unsigned aout1_pins[] = {137, 138, 139, 140, 141, 142};
> +static const int aout1_muxvals[] = {0, 0, 0, 0, 0, 0};
> +static const unsigned aoutiec1_pins[] = {135, 136};
> +static const int aoutiec1_muxvals[] = {0, 0};
> static const unsigned int emmc_pins[] = {19, 20, 21, 22, 23, 24, 25};
> static const int emmc_muxvals[] = {0, 0, 0, 0, 0, 0, 0};
> static const unsigned emmc_dat8_pins[] = {26, 27, 28, 29};
> @@ -631,7 +633,8 @@ static const unsigned int gpio_range2_pins[] = {
> };
>
> static const struct uniphier_pinctrl_group uniphier_ld20_groups[] = {
> - UNIPHIER_PINCTRL_GROUP(aout),
> + UNIPHIER_PINCTRL_GROUP(aout1),
> + UNIPHIER_PINCTRL_GROUP(aoutiec1),
> UNIPHIER_PINCTRL_GROUP(emmc),
> UNIPHIER_PINCTRL_GROUP(emmc_dat8),
> UNIPHIER_PINCTRL_GROUP(ether_rgmii),
> @@ -657,7 +660,8 @@ static const struct uniphier_pinctrl_group
> uniphier_ld20_groups[] = {
> UNIPHIER_PINCTRL_GROUP_GPIO(gpio_range2),
> };
>
> -static const char * const aout_groups[] = {"aout"};
> +static const char * const aout1_groups[] = {"aout1"};
> +static const char * const aoutiec1_groups[] = {"aoutiec1"};
> static const char * const emmc_groups[] = {"emmc", "emmc_dat8"};
> static const char * const ether_rgmii_groups[] = {"ether_rgmii"};
> static const char * const ether_rmii_groups[] = {"ether_rmii"};
> @@ -679,7 +683,8 @@ static const char * const usb2_groups[] = {"usb2"};
> static const char * const usb3_groups[]
Re: perf-core build fails on powerpc
On 13/03/2018 21:18, Sukadev Bhattiprolu wrote: John Garry [john.ga...@huawei.com] wrote: On 13/03/2018 20:10, Sukadev Bhattiprolu wrote: Hi John, I have an xfs file system which seems to have d_type == DT_UNKNOWN for all entries in 'tools/perf/pmu-events/arch/power8'! readdir(3) says ->d_type may not be supported by all file systems. Not relying on ->d_type seems to fix it: Hi Sukadev, Thanks for debugging this. Jiri Olsa (cc'ed) warned me on this, so I did add the check for d_type == DT_UNKNOWN. But, if all files have d_type == DT_UNKNOWN, you're code would from visual observation look to be same as mine (apart from check for '.' or '..' filename, which I would say is already covered by stat() and S_ISDIR()). Or is d_type value just unreliable? In the current code and with DT_UNKNOWN, is_leaf_dir() returns false when it sees the "." or ".." entries right? In the new code, we skip those and return false only if we find some other directory. OK, that's the real issue, being the "." and ".." entries. @Arnaldo, I'll try to send a fix for this today. I just need to make an xfs to test. Sorry for the hassle. John Thanks, Sukadev
Re: [PATCH 18/31] perf vendor events arm64: Add armv8-recommended.json
* Arnaldo Carvalho de Melo wrote: > Em Tue, Mar 13, 2018 at 03:27:30PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Tue, Mar 13, 2018 at 03:26:18PM +0100, Ingo Molnar escreveu: > > > That's not a valid SOB chain, author != first-Signed-off-by. > > > I removed that cset for now, can you please check if the > > perf-core-for-mingo-4.17-20180313-2 tag is allright? > > So, since there is this problem with powerpc and jevents, Ingo, please > hold on a bit more... Hopefully tomorrow things will be in a better > shape. Sure, no problem! Thanks, Ingo
Re: [PATCH v3 2/2] kbuild: Don't mess with the .cache.mk when root
* Linus Torvalds wrote: > If Ingo wants to build as root, maybe we could even make him set some > environment flag to avoid errors. I only build as root infrequently, but I think PeterZ does it more frequently? Distro package builds are also often done as root. I don't mind warnings, etc. - I only objected to the workaround of silently turning off a build optimization when root. Thanks, Ingo
Re: int3403_driver_init needs over 330 ms to finish
On 二, 2018-03-13 at 20:39 +0100, Paul Menzel wrote: > Dear Linux folks, > > > Booting the Dell XPS 13 9370 with Linux 4.16-rc4+ and > `initcall_debug`, > shows it is shown that int3403_driver_init needs over 330 ms to run. > > [2.524839] initcall int3403_driver_init+0x0/0x1000 > [int3403_thermal] returned 0 after 333972 usecs > I guess most of the time are spent in evaluating ACPI ASL code. But anyway, please create a bugzilla report and attach both dmesg and acpidump there. thanks, rui > Please find all Linux messages attached. > > Is there a way to reduce that time? > > > Kind regards, > > Paul
Re: [PATCH v2] vmw_balloon: fixing double free when batching mode is off
Hello. On Wed, Mar 14, 2018 at 5:02 AM, Nadav Amit wrote: > Oleksandr, if you can confirm that it fixes the bug you encountered, it > would be great. Sure, I'm checking this possibility with a couple of customers, and will reply back once I have some inputs on it. > Greg, Arnd, on your free time, please let me know if there is any issue > with the patch, and whether you can incorporate it, preferably in 4.16, > since it is a bug-fix that was encountered by Red-Hat customers. -- Best regards, Oleksandr Natalenko (post-factum) Software Maintenance Engineer
Re: [PATCH] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling
Hi Shanker,
On Wed, 14 Mar 2018 00:50:01 +,
Shanker Donthineni wrote:
>
> The definition of the GICR_CTLR.RWP control bit was expanded to indicate
> status of changing GICR_CTLR.EnableLPI from 1 to 0 is being in progress
> or completed. Software must observe GICR_CTLR.RWP==0 after clearing
> GICR_CTLR.EnableLPI from 1 to 0 and before writing GICR_PENDBASER and/or
> GICR_PROPBASER, otherwise behavior is UNPREDICTABLE.
>
> Signed-off-by: Shanker Donthineni
> ---
> drivers/irqchip/irq-gic-v3-its.c | 30 +++---
> include/linux/irqchip/arm-gic-v3.h | 1 +
> 2 files changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index 1d3056f..85cd158 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1875,15 +1875,31 @@ static void its_cpu_init_lpis(void)
> gic_data_rdist()->pend_page = pend_page;
> }
>
> - /* Disable LPIs */
> val = readl_relaxed(rbase + GICR_CTLR);
> - val &= ~GICR_CTLR_ENABLE_LPIS;
> - writel_relaxed(val, rbase + GICR_CTLR);
>
> - /*
> - * Make sure any change to the table is observable by the GIC.
> - */
> - dsb(sy);
> + /* Make sure LPIs are disabled before programming PEND/PROP registers */
> + if (val & GICR_CTLR_ENABLE_LPIS) {
> + u32 count = 100; /* 1s! */
> +
> + /* Disable LPIs */
> + val &= ~GICR_CTLR_ENABLE_LPIS;
> + writel_relaxed(val, rbase + GICR_CTLR);
> +
> + /* Make sure any change to GICR_CTLR is observable by the GIC */
> + dsb(sy);
> +
> + /* Wait for GICR_CTLR.RWP==0 or timeout */
> + while (readl_relaxed(rbase + GICR_CTLR) & GICR_CTLR_RWP) {
> + if (!count) {
> + pr_err("CPU%d: Failed to disable LPIs\n",
> +smp_processor_id());
> + return;
> + }
> + cpu_relax();
> + udelay(1);
> + count--;
> + };
> + }
I can see a couple of issues with this patch:
- Entering the kernel with GICR_CTLR.EnableLPIs set is a recipe for
memory corruption and is likely to lead to Bad Things(tm). A loud
warning would be in order, I believe.
- If you're on a system that doesn't allow GICR_CTLR.Enable_LPIs to be
cleared, we end-up going down the polling path for nothing. It'd be
worth checking that the bit can be cleared the first place (and
shout again if it cannot).
- From a cosmetic PoV, please move this to a redist_disable_lpis()
function.
Thanks,
M.
--
Jazz is not dead, it just smell funny.
Re: [Intel-gfx] [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning
On 13/03/2018 20:10, Arnd Bergmann wrote:
On Tue, Mar 13, 2018 at 6:46 PM, Tvrtko Ursulin
wrote:
On 13/03/2018 16:19, Arnd Bergmann wrote:
The conditional spinlock confuses gcc into thinking the 'flags' value
might contain uninitialized data:
drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
Hm, how does paravirt_types.h comes into the picture?
spin_unlock_irqrestore() calls arch_local_irq_restore()
The code is correct, but it's easy to see how the compiler gets confused
here. This avoids the problem by pulling the lock outside of the function
into its only caller.
Is it specific gcc version, specific options, or specific kernel config that
this happens?
Not gcc version specific (same result with gcc-4.9 through 8, didn't test
earlier versions that are currently broken).
Strange that it hasn't been seen so far.
It seems to be a relatively rare 'randconfig' combination. Looking at
the preprocessed sources, I find:
static u64 get_rc6(struct drm_i915_private *i915, bool locked)
{
unsigned long flags;
u64 val;
if (intel_runtime_pm_get_if_in_use(i915)) {
val = __get_rc6(i915);
intel_runtime_pm_put(i915);
if (!locked)
do { do { ({ unsigned long __dummy; typeof(flags) __dummy2;
(void)(&__dummy == &__dummy2); 1; }); do { do { do { ({ unsigned long
__dummy; typeof(flags) __dummy2; (void)(&__dummy == &__dummy2); 1; });
flags = arch_local_irq_save(); } while (0); trace_hardirqs_off(); }
while (0); do { __asm__ __volatile__("": : :"memory"); do { (void)0;
(void)(spinlock_check(&i915->pmu.lock)); } while (0); } while (0); }
while (0); } while (0); } while (0);
if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
} else {
val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
}
if (!locked)
spin_unlock_irqrestore(&i915->pmu.lock, flags);
} else {
struct pci_dev *pdev = i915->drm.pdev;
struct device *kdev = &pdev->dev;
unsigned long flags2;
# 455 "/git/arm-soc/drivers/gpu/drm/i915/i915_pmu.c"
if (!locked)
do { do { ({ unsigned long __dummy; typeof(flags) __dummy2;
(void)(&__dummy == &__dummy2); 1; }); do { do { do { ({ unsigned long
__dummy; typeof(flags) __dummy2; (void)(&__dummy == &__dummy2); 1; });
flags = arch_local_irq_save(); } while (0); trace_hardirqs_off(); }
while (0); do { __asm__ __volatile__("": : :"memory"); do { (void)0;
(void)(spinlock_check(&i915->pmu.lock)); } while (0); } while (0); }
while (0); } while (0); } while (0);
do { do { ({ unsigned long __dummy; typeof(flags2) __dummy2;
(void)(&__dummy == &__dummy2); 1; }); do { do { do { ({ unsigned long
__dummy; typeof(flags2) __dummy2; (void)(&__dummy == &__dummy2); 1;
}); flags2 = arch_local_irq_save(); } while (0); trace_hardirqs_off();
} while (0); do { __asm__ __volatile__("": : :"memory"); do { (void)0;
(void)(spinlock_check(&kdev->power.lock)); } while (0); } while (0); }
while (0); } while (0); } while (0);
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
i915->pmu.suspended_jiffies_last =
kdev->power.suspended_jiffies;
val = kdev->power.suspended_jiffies -
i915->pmu.suspended_jiffies_last;
val += jiffies - kdev->power.accounting_timestamp;
spin_unlock_irqrestore(&kdev->power.lock, flags2);
val = jiffies_to_nsecs(val);
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
if (!locked)
spin_unlock_irqrestore(&i915->pmu.lock, flags);
}
return val;
}
so it seems that the spin_lock_irqsave() is completely inlined through
a macro while the unlock is not, and the lock contains a memory barrier
(among other things) that might tell the compiler that the state of the
'locked' flag could changed underneath it.
Ha, interesting. So it sounds more like us having to workaround a bug in
the paravirt spinlock macros.
I think I would prefer a different solution, where we don't end up doing
MMIO under irqsave spinlock. I'll send a patch.
Regards,
Tvrtko
It could also be the problem that arch_local_irq_restore() uses
__builtin_expect() in PVOP_TEST_NULL(op) when
CONFIG_PARAVIRT_DEBUG is enabled, see
static inline __attribute__((unused))
__attribute__((no_instrument_function))
__attribute__((no_instrument_function)) void
arch_local_irq_restore(unsigned long f)
{
({ unsigned long __eax = __eax, __edx = __edx, __ecx = __ecx;; do {
if (__builtin_expect(!!(pv_irq_ops.restore_fl.func == ((void *)0)),
0)) do { do { asm volatile("1:\t" ".byte 0x0f, 0x0b" "\n"
".pushsection __bug_table,\"aw\"\n" "2:\t" ".long " "1b" "\t#
bug_entry::bug_addr\n" "\t" ".long " "%c0" "\t# bug_entry::file\n"
"\t.word %c1" "\t# bug_entry::line\n" "\t.word %c2" "\t#
bug_entry::flags\n" "\t.org 2b+%c3\n" ".pop
Re: [PATCH V2] ZBOOT: fix stack protector in compressed boot phase
On Tue, 13 Mar 2018 17:55:53 +0900,
Huacai Chen wrote:
>
> Hi, Yoshinori, Rich and SuperH developers,
>
> I'm not familiar with SuperH assembly, but SuperH has the same bug
> obviously. Could you please fix that?
>
> Huacai
>
OK. Apply this fix.
SuperH can not handle long int directly.
diff --git a/arch/sh/boot/compressed/head_32.S
b/arch/sh/boot/compressed/head_32.S
index a3fdb053f351..7411fcb5764a 100644
--- a/arch/sh/boot/compressed/head_32.S
+++ b/arch/sh/boot/compressed/head_32.S
@@ -76,8 +76,8 @@ l1:
mov.l init_stack_addr, r0
mov.l @r0, r15
- mov.l __stack_chk_guard, r0
- mov #0x000a0dff, r1
+ mov.l __stack_chk_guard_ptr, r0
+ mov.l __stack_chk_val, r1
mov.l r1, @r0
/* Decompress the kernel */
@@ -109,6 +109,10 @@ kernel_start_addr:
#else
.long _text+PAGE_SIZE
#endif
+__stack_chk_guard_ptr:
+ .long __stack_chk_guard
+__stack_chk_val:
+ .long 0x000a0dff
.align 9
fake_headers_as_bzImage:
> On Mon, Mar 12, 2018 at 10:04 AM, Huacai Chen wrote:
> > Call __stack_chk_guard_setup() in decompress_kernel() is too late that
> > stack checking always fails for decompress_kernel() itself. So remove
> > __stack_chk_guard_setup() and initialize __stack_chk_guard before we
> > call decompress_kernel().
> >
> > Original code comes from ARM but also used for MIPS and SH, so fix them
> > together. If without this fix, compressed booting of these archs will
> > fail because stack checking is enabled by default (>=4.16).
> >
> > V2: Fix build on ARM.
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Huacai Chen
> > ---
> > arch/arm/boot/compressed/head.S| 4
> > arch/arm/boot/compressed/misc.c| 7 ---
> > arch/mips/boot/compressed/decompress.c | 7 ---
> > arch/mips/boot/compressed/head.S | 4
> > arch/sh/boot/compressed/head_32.S | 4
> > arch/sh/boot/compressed/head_64.S | 4
> > arch/sh/boot/compressed/misc.c | 7 ---
> > 7 files changed, 16 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/arm/boot/compressed/head.S
> > b/arch/arm/boot/compressed/head.S
> > index 45c8823..bae1fc6 100644
> > --- a/arch/arm/boot/compressed/head.S
> > +++ b/arch/arm/boot/compressed/head.S
> > @@ -547,6 +547,10 @@ not_relocated: mov r0, #0
> > bic r4, r4, #1
> > blnecache_on
> >
> > + ldr r0, =__stack_chk_guard
> > + ldr r1, =0x000a0dff
> > + str r1, [r0]
> > +
> > /*
> > * The C runtime environment should now be setup sufficiently.
> > * Set up some pointers, and start decompressing.
> > diff --git a/arch/arm/boot/compressed/misc.c
> > b/arch/arm/boot/compressed/misc.c
> > index 16a8a80..e518ef5 100644
> > --- a/arch/arm/boot/compressed/misc.c
> > +++ b/arch/arm/boot/compressed/misc.c
> > @@ -130,11 +130,6 @@ asmlinkage void __div0(void)
> >
> > unsigned long __stack_chk_guard;
> >
> > -void __stack_chk_guard_setup(void)
> > -{
> > - __stack_chk_guard = 0x000a0dff;
> > -}
> > -
> > void __stack_chk_fail(void)
> > {
> > error("stack-protector: Kernel stack is corrupted\n");
> > @@ -150,8 +145,6 @@ decompress_kernel(unsigned long output_start, unsigned
> > long free_mem_ptr_p,
> > {
> > int ret;
> >
> > - __stack_chk_guard_setup();
> > -
> > output_data = (unsigned char *)output_start;
> > free_mem_ptr= free_mem_ptr_p;
> > free_mem_end_ptr= free_mem_ptr_end_p;
> > diff --git a/arch/mips/boot/compressed/decompress.c
> > b/arch/mips/boot/compressed/decompress.c
> > index fdf99e9..5ba431c 100644
> > --- a/arch/mips/boot/compressed/decompress.c
> > +++ b/arch/mips/boot/compressed/decompress.c
> > @@ -78,11 +78,6 @@ void error(char *x)
> >
> > unsigned long __stack_chk_guard;
> >
> > -void __stack_chk_guard_setup(void)
> > -{
> > - __stack_chk_guard = 0x000a0dff;
> > -}
> > -
> > void __stack_chk_fail(void)
> > {
> > error("stack-protector: Kernel stack is corrupted\n");
> > @@ -92,8 +87,6 @@ void decompress_kernel(unsigned long boot_heap_start)
> > {
> > unsigned long zimage_start, zimage_size;
> >
> > - __stack_chk_guard_setup();
> > -
> > zimage_start = (unsigned long)(&__image_begin);
> > zimage_size = (unsigned long)(&__image_end) -
> > (unsigned long)(&__image_begin);
> > diff --git a/arch/mips/boot/compressed/head.S
> > b/arch/mips/boot/compressed/head.S
> > index 409cb48..00d0ee0 100644
> > --- a/arch/mips/boot/compressed/head.S
> > +++ b/arch/mips/boot/compressed/head.S
> > @@ -32,6 +32,10 @@ start:
> > bne a2, a0, 1b
> > addiu a0, a0, 4
> >
> > + PTR_LA a0, __stack_chk_guard
> > + PTR_LI a1, 0x000a0dff
> > + sw a1, 0(a0)
> > +
> > PTR_LA a0, (.heap) /* heap address */
> > PTR_LA sp, (.stack + 8192) /
[PATCH 1/1 v2] powerpc: pkey-mprotect must allow pkey-0
Once an address range is associated with an allocated pkey, it cannot be
reverted back to key-0. There is no valid reason for the above behavior. On
the contrary applications need the ability to do so.
The patch relaxes the restriction.
Tested on powerpc.
cc: Dave Hansen
cc: Michael Ellermen
cc: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/pkeys.h | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index 0409c80..3c1deec 100644
--- a/arch/powerpc/include/asm/pkeys.h
+++ b/arch/powerpc/include/asm/pkeys.h
@@ -101,10 +101,18 @@ static inline u16 pte_to_pkey_bits(u64 pteflags)
static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
{
- /* A reserved key is never considered as 'explicitly allocated' */
- return ((pkey < arch_max_pkey()) &&
- !__mm_pkey_is_reserved(pkey) &&
- __mm_pkey_is_allocated(mm, pkey));
+ /* pkey 0 is allocated by default. */
+ if (!pkey)
+ return true;
+
+ if (pkey < 0 || pkey >= arch_max_pkey())
+ return false;
+
+ /* Reserved keys are never allocated. */
+ if (__mm_pkey_is_reserved(pkey))
+ return false;
+
+ return __mm_pkey_is_allocated(mm, pkey);
}
extern void __arch_activate_pkey(int pkey);
@@ -150,7 +158,8 @@ static inline int mm_pkey_free(struct mm_struct *mm, int
pkey)
if (static_branch_likely(&pkey_disabled))
return -1;
- if (!mm_pkey_is_allocated(mm, pkey))
+ /* pkey 0 cannot be freed */
+ if (!pkey || !mm_pkey_is_allocated(mm, pkey))
return -EINVAL;
/*
--
1.8.3.1
Re: [PATCH] crypto: arm,arm64 - Fix random regeneration of S_shipped
On 14 March 2018 at 02:31, Masahiro Yamada wrote: > 2018-03-14 5:17 GMT+09:00 Leonard Crestez : >> The decision to rebuild .S_shipped is made based on the relative >> timestamps of .S_shipped and .pl files but git makes this essentially >> random. This means that the perl script might run anyway (usually at >> most once per checkout), defeating the whole purpose of _shipped. >> >> Fix by skipping the rule unless explicit make variables are provided: >> REGENERATE_ARM_CRYPTO or REGENERATE_ARM64_CRYPTO. >> >> This can produce nasty occasional build failures downstream, for example >> for toolchains with broken perl. The solution is minimally intrusive to >> make it easier to push into stable. >> >> Another report on a similar issue here: https://lkml.org/lkml/2018/3/8/1379 >> >> Signed-off-by: Leonard Crestez >> Cc: >> --- > > > > Reviewed-by: Masahiro Yamada > Acked-by: Ard Biesheuvel > > >> arch/arm/crypto/Makefile | 2 ++ >> arch/arm64/crypto/Makefile | 2 ++ >> 2 files changed, 4 insertions(+) >> >> Not clear if this needs to go through crypto or arm but all commits in these >> directories start with "crypto:". >> >> My problems were only on arm64 because of a yocto toolchain which ships a >> version >> of perl which fails on "use integer;". >> >> CC stable because this can cause trouble for downstream packagers. >> >> diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile >> index 30ef8e2..c9919c2 100644 >> --- a/arch/arm/crypto/Makefile >> +++ b/arch/arm/crypto/Makefile >> @@ -47,20 +47,22 @@ sha256-arm-y:= sha256-core.o sha256_glue.o >> $(sha256-arm-neon-y) >> sha512-arm-neon-$(CONFIG_KERNEL_MODE_NEON) := sha512-neon-glue.o >> sha512-arm-y := sha512-core.o sha512-glue.o $(sha512-arm-neon-y) >> sha1-arm-ce-y := sha1-ce-core.o sha1-ce-glue.o >> sha2-arm-ce-y := sha2-ce-core.o sha2-ce-glue.o >> aes-arm-ce-y := aes-ce-core.o aes-ce-glue.o >> ghash-arm-ce-y := ghash-ce-core.o ghash-ce-glue.o >> crct10dif-arm-ce-y := crct10dif-ce-core.o crct10dif-ce-glue.o >> crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o >> chacha20-neon-y := chacha20-neon-core.o chacha20-neon-glue.o >> >> +ifdef REGENERATE_ARM_CRYPTO >> quiet_cmd_perl = PERL$@ >>cmd_perl = $(PERL) $(<) > $(@) >> >> $(src)/sha256-core.S_shipped: $(src)/sha256-armv4.pl >> $(call cmd,perl) >> >> $(src)/sha512-core.S_shipped: $(src)/sha512-armv4.pl >> $(call cmd,perl) >> +endif >> >> .PRECIOUS: $(obj)/sha256-core.S $(obj)/sha512-core.S >> diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile >> index cee9b8d9..dfe651b 100644 >> --- a/arch/arm64/crypto/Makefile >> +++ b/arch/arm64/crypto/Makefile >> @@ -60,20 +60,22 @@ obj-$(CONFIG_CRYPTO_AES_ARM64_BS) += aes-neon-bs.o >> aes-neon-bs-y := aes-neonbs-core.o aes-neonbs-glue.o >> >> AFLAGS_aes-ce.o:= -DINTERLEAVE=4 >> AFLAGS_aes-neon.o := -DINTERLEAVE=4 >> >> CFLAGS_aes-glue-ce.o := -DUSE_V8_CRYPTO_EXTENSIONS >> >> $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE >> $(call if_changed_rule,cc_o_c) >> >> +ifdef REGENERATE_ARM64_CRYPTO >> quiet_cmd_perlasm = PERLASM $@ >>cmd_perlasm = $(PERL) $(<) void $(@) >> >> $(src)/sha256-core.S_shipped: $(src)/sha512-armv8.pl >> $(call cmd,perlasm) >> >> $(src)/sha512-core.S_shipped: $(src)/sha512-armv8.pl >> $(call cmd,perlasm) >> +endif >> >> .PRECIOUS: $(obj)/sha256-core.S $(obj)/sha512-core.S >> -- >> 2.7.4 >> > > > > -- > Best Regards > Masahiro Yamada
Re: WARN when unmounting a subvolume that is being synced
On 14.03.2018 05:10, Tycho Andersen wrote: > Hi all, > > I'm getting the WARN below. I think (?) what I'm doing when I get it > is that I'm unmounting a subvolume while it's being synced (concurrent > uses of the subvolume, at least, happy to look into it further if the > stack trace is not so useful). Anyway, I can fairly reliably reproduce > this on 4.16-rc4. > > Thoughts? Yeah, you've mounted the filesystem with flushoncommit. THe easiest thing would be to remount with that option ommitted i.e the default behavior. This is a well-known issue, unfortunately fixing it is a bit hairy and deadlock prone against fs freeze. > > Tycho > > Mar 13 22:18:53 stacker kernel: [ 1136.845064] WARNING: CPU: 2 PID: 4927 at > fs/fs-writeback.c:2339 __writeback_inodes_sb_nr+0x189/0x1d0 > Mar 13 22:18:53 stacker kernel: [ 1136.845068] Modules linked in: fuse > Mar 13 22:18:53 stacker kernel: [ 1136.845087] CPU: 2 PID: 4927 Comm: btrfs > Not tainted 4.16.0-rc4+ #121 > Mar 13 22:18:53 stacker kernel: [ 1136.845090] Hardware name: QEMU Standard > PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 > Mar 13 22:18:53 stacker kernel: [ 1136.845094] RIP: > 0010:__writeback_inodes_sb_nr+0x189/0x1d0 > Mar 13 22:18:53 stacker kernel: [ 1136.845096] RSP: 0018:88010eaff468 > EFLAGS: 00010246 > Mar 13 22:18:53 stacker kernel: [ 1136.845103] RAX: RBX: > 110021d5fe8e RCX: > Mar 13 22:18:53 stacker kernel: [ 1136.845106] RDX: 11002297444e RSI: > 457f RDI: 880114ba2270 > Mar 13 22:18:53 stacker kernel: [ 1136.845108] RBP: 88010e319100 R08: > dc00 R09: 0004 > Mar 13 22:18:53 stacker kernel: [ 1136.845110] R10: 11002142311e R11: > R12: 880114ba2200 > Mar 13 22:18:53 stacker kernel: [ 1136.845113] R13: 88010eaff490 R14: > 88008ed7e930 R15: 880112731150 > Mar 13 22:18:53 stacker kernel: [ 1136.845116] FS: 7f1c1d71c8c0() > GS:880115f0() knlGS: > Mar 13 22:18:53 stacker kernel: [ 1136.845118] CS: 0010 DS: ES: > CR0: 80050033 > Mar 13 22:18:53 stacker kernel: [ 1136.845121] CR2: 7f5ebaa3f010 CR3: > 0001121b1000 CR4: 06e0 > Mar 13 22:18:53 stacker kernel: [ 1136.845125] Call Trace: > Mar 13 22:18:53 stacker kernel: [ 1136.845139] ? > wb_wait_for_completion+0x150/0x150 > Mar 13 22:18:53 stacker kernel: [ 1136.845145] ? get_nr_inodes+0x80/0xf0 > Mar 13 22:18:53 stacker kernel: [ 1136.845152] ? > btrfs_commit_transaction+0x58c/0x1e80 > Mar 13 22:18:53 stacker kernel: [ 1136.845165] ? get_nr_dirty_pages+0x6b/0x80 > Mar 13 22:18:53 stacker kernel: [ 1136.845171] > btrfs_commit_transaction+0x13ea/0x1e80 > Mar 13 22:18:53 stacker kernel: [ 1136.845183] ? > btrfs_apply_pending_changes+0xb0/0xb0 > Mar 13 22:18:53 stacker kernel: [ 1136.845189] ? _raw_spin_unlock+0x1f/0x30 > Mar 13 22:18:53 stacker kernel: [ 1136.845194] ? > block_rsv_release_bytes+0x4f8/0x9a0 > Mar 13 22:18:53 stacker kernel: [ 1136.845203] ? > __kasan_slab_free+0x14a/0x180 > Mar 13 22:18:53 stacker kernel: [ 1136.845208] ? create_subvol+0x11d0/0x133b > Mar 13 22:18:53 stacker kernel: [ 1136.845215] create_subvol+0x12ac/0x133b > Mar 13 22:18:53 stacker kernel: [ 1136.845227] ? > may_destroy_subvol+0x478/0x478 > Mar 13 22:18:53 stacker kernel: [ 1136.845242] ? lock_pin_lock+0x2b0/0x2b0 > Mar 13 22:18:53 stacker kernel: [ 1136.845251] ? > crypto_shash_update+0xc5/0x290 > Mar 13 22:18:53 stacker kernel: [ 1136.845260] ? > __lock_acquire.isra.30+0x4e4/0x1da0 > Mar 13 22:18:53 stacker kernel: [ 1136.845267] ? > btrfs_check_dir_item_collision+0xc2/0x250 > Mar 13 22:18:53 stacker kernel: [ 1136.845272] ? kmem_cache_free+0xa9/0x240 > Mar 13 22:18:53 stacker kernel: [ 1136.845296] ? btrfs_mksubvol+0x7b3/0x12e0 > Mar 13 22:18:53 stacker kernel: [ 1136.845298] btrfs_mksubvol+0x7b3/0x12e0 > Mar 13 22:18:53 stacker kernel: [ 1136.845310] ? > _btrfs_ioctl_send+0x220/0x220 > Mar 13 22:18:53 stacker kernel: [ 1136.845316] ? __sb_start_write+0x167/0x250 > Mar 13 22:18:53 stacker kernel: [ 1136.845320] ? > mnt_want_write_file+0xe8/0x300 > Mar 13 22:18:53 stacker kernel: [ 1136.845330] > btrfs_ioctl_snap_create_transid+0x11e/0x3d0 > Mar 13 22:18:53 stacker kernel: [ 1136.845338] ? _copy_from_user+0x93/0xd0 > Mar 13 22:18:53 stacker kernel: [ 1136.845345] > btrfs_ioctl_snap_create+0xeb/0x130 > Mar 13 22:18:53 stacker kernel: [ 1136.845351] btrfs_ioctl+0x1c9c/0x6050 > Mar 13 22:18:53 stacker kernel: [ 1136.845357] ? find_held_lock+0x32/0x1c0 > Mar 13 22:18:53 stacker kernel: [ 1136.845369] ? > btrfs_ioctl_get_supported_features+0x20/0x20 > Mar 13 22:18:53 stacker kernel: [ 1136.845381] ? find_held_lock+0x32/0x1c0 > Mar 13 22:18:53 stacker kernel: [ 1136.845389] ? > __handle_mm_fault+0xc3f/0x1980 > Mar 13 22:18:53 stacker kernel: [ 1136.845394] ? lock_downgrade+0x5e0/0x5e0 > Mar 13 22:18:53 stacker kernel: [ 1136.845399] ? > mem_cgroup_
[PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0
Once an address range is associated with an allocated pkey, it cannot be
reverted back to key-0. There is no valid reason for the above behavior. On
the contrary applications need the ability to do so.
The patch relaxes the restriction.
Tested on x86_64.
cc: Dave Hansen
cc: Michael Ellermen
cc: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/x86/include/asm/pkeys.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h
index a0ba1ff..6ea7486 100644
--- a/arch/x86/include/asm/pkeys.h
+++ b/arch/x86/include/asm/pkeys.h
@@ -52,7 +52,7 @@ bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
* from pkey_alloc(). pkey 0 is special, and never
* returned from pkey_alloc().
*/
- if (pkey <= 0)
+ if (pkey < 0)
return false;
if (pkey >= arch_max_pkey())
return false;
@@ -92,7 +92,8 @@ int mm_pkey_alloc(struct mm_struct *mm)
static inline
int mm_pkey_free(struct mm_struct *mm, int pkey)
{
- if (!mm_pkey_is_allocated(mm, pkey))
+ /* pkey 0 is special and can never be freed */
+ if (!pkey || !mm_pkey_is_allocated(mm, pkey))
return -EINVAL;
mm_set_pkey_free(mm, pkey);
--
1.8.3.1
Re: [PATCH 0/4 v5 RESEND] devpts: handle bind-mounts correctly
On Tue, Mar 13, 2018 at 12:32:37PM -0500, Eric W. Biederman wrote: > Christian Brauner writes: > > > Resending to CC grekh. > > > > Acked-by: "Eric W. Biederman" > > And the first two patches can also have > Reviewed-by: "Eric W. Biederman" > > Greg this patchset looks read or just about ready to be merged. Do you > want to take this through your tty tree or should I take it through my > tree. I can take it through my tree. I'll go through the pending tty/serial patches tomorrow and pick these up. thanks, greg k-h
Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices
On 03/13/2018 06:35 PM, Jakob Unterwurzacher wrote: > The UCAN driver supports the microcontroller-based USB/CAN > adapters from Theobroma Systems. There are two form-factors > that run essentially the same firmware: > > * Seal: standalone USB stick ( https://www.theobroma-systems.com/seal ) > > * Mule: integrated on the PCB of various System-on-Modules from > Theobroma Systems like the A31-µQ7 and the RK3399-Q7 > ( https://www.theobroma-systems.com/rk3399-q7 ) > > The USB wire protocol has been designed to be as generic and > hardware-indendent as possible in the hope of being useful for > implementation on other microcontrollers. > > Signed-off-by: Martin Elshuber > Signed-off-by: Jakob Unterwurzacher > > Signed-off-by: Philipp Tomsich > --- > Documentation/networking/can_ucan_protocol.rst | 315 + > Documentation/networking/index.rst |1 + > drivers/net/can/usb/Kconfig| 10 + > drivers/net/can/usb/Makefile |1 + > drivers/net/can/usb/ucan.c | 1587 > > 5 files changed, 1914 insertions(+) > create mode 100644 Documentation/networking/can_ucan_protocol.rst > create mode 100644 drivers/net/can/usb/ucan.c > > diff --git a/Documentation/networking/can_ucan_protocol.rst > b/Documentation/networking/can_ucan_protocol.rst > new file mode 100644 > index ..d859b36200b4 > --- /dev/null > +++ b/Documentation/networking/can_ucan_protocol.rst > @@ -0,0 +1,315 @@ > += > +The UCAN Protocol > += > + > +UCAN is the protocol used by the microcontroller-based USB-CAN > +adapter that is integrated on System-on-Modules from Theobroma Systems > +and that is also available as a standalone USB stick. > + > +The UCAN protocol has been designed to be hardware-independent. > +It is modeled closely after how Linux represents CAN devices > +internally. All multi-byte integers are encoded as Little Endian. > + > +All structures mentioned in this document are defined in > +``drivers/net/can/usb/ucan.c``. > + > +USB Endpoints > += > + > +UCAN devices use three USB endpoints: > + > +CONTROL endpoint > + The driver sends device management commands on this endpoint > + > +IN endpoint > + The device sends CAN data frames and CAN error frames > + > +OUT endpoint > + The driver sends CAN data frames on the out endpoint > + > + > +CONTROL Messages > + > + > +UCAN devices are configured using vendor requests on the control pipe. > + > +To support multiple CAN interfaces in a single USB device all > +configuration commands target the corresponding interface in the USB > +descriptor. > + > +The driver uses ``ucan_ctrl_command_in/out`` and > +``ucan_device_request_in`` to deliver commands to the device. > + > +Setup Packet > + > + > += = > +``bmRequestType`` Direction | Vendor | (Interface or Device) > +``bRequest`` Command Number > +``wValue`` Subcommand Number (16 Bit) or 0 if not used > +``wIndex`` USB Interface Index (0 for device commands) > +``wLength``* Host to Device - Number of bytes to transmit > + * Device to Host - Maximum Number of bytes to > + receive. If the device send less. Commom ZLP > + semantics are used. > += = > + > +Error Handling > +-- > + > +The device indicates failed control commands by stalling the > +pipe. > + > +Device Commands > +--- > + > +UCAN_DEVICE_GET_FW_STRING > +~ > + > +*Dev2Host; optional* > + > +Request the device firmware string. > + > + > +Interface Commands > +-- > + > +UCAN_COMMAND_START > +~~ > + > +*Host2Dev; mandatory* > + > +Bring the CAN interface up. > + > +Payload Format > + ``ucan_ctl_payload_t.cmd_start`` > + > + > +mode or mask of ``UCAN_MODE_*`` > + > + > +UCAN_COMMAND_STOP > +~~ > + > +*Host2Dev; mandatory* > + > +Stop the CAN interface > + > +Payload Format > + *empty* > + > +UCAN_COMMAND_RESET > +~~ > + > +*Host2Dev; mandatory* > + > +Reset the CAN controller (including error counters) > + > +Payload Format > + *empty* > + > +UCAN_COMMAND_GET > + > + > +*Host2Dev; mandatory* > + > +Get Information from the Device > + > +Subcommands > +^^^ > + > +UCAN_COMMAND_GET_INFO > + Request the device information structure > ``ucan_ctl_payload_t.device_info``. > + > + See the ``device_info`` field for details, and > + ``uapi/linux/can/netlink.h`` for an explanation of the > + ``can_bittiming fields``. > + > + Payload Format > +``ucan_ctl_payload_t.device_info`` > + > +UCAN_COMMAND_GET_PROTOCOL_VERSION > + > + Request the device protocol version > + ``
Re: [PATCH] media: staging/imx: fill vb2_v4l2_buffer sequence entry
On Tue, Mar 13, 2018 at 09:00:54PM +0100, Peter Seiderer wrote: > Signed-off-by: Peter Seiderer > --- > drivers/staging/media/imx/imx-media-csi.c | 5 + > 1 file changed, 5 insertions(+) I know I don't take patches with an empty changelog description, but other maintainers might be much more forgiving... :)
Re: [PATCH] usb: misc: supports Apple Carplay driver
On Wed, Mar 14, 2018 at 02:02:36PM +0800, Chunfeng Yun wrote: > The driver is used to support Apple carplay feature by a debugfs > interface which can force the driver to send a USB Vendor Request > of "Apple Device to Host Mode Switch" to switch Apple Device > into host mode. While I am all for crazy debugfs interfaces, I would _strongly_ suggest not doing that here for the main API to the device. I know Android is trying to prevent any new devices from even enabling debugfs, and as the file system requires root permissions by default, you are forcing any user of your new api to run as root, which is not a good idea either. Given that all you are doing here is a single usb control message, why does this even need to be a kernel driver at all? Can't you do the same thing from userspace with a simple libusb/usbfs program? Or even a simple script? thanks, greg k-h
Re: [PATCH 4.15 000/146] 4.15.10-stable review
On Tue, Mar 13, 2018 at 03:28:00PM -0700, Guenter Roeck wrote: > On Tue, Mar 13, 2018 at 04:22:47PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.15.10 release. > > There are 146 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Mar 15 15:22:37 UTC 2018. > > Anything received after that time might be too late. > > > > Build results: > total: 147 pass: 147 fail: 0 > Qemu test results: > total: 141 pass: 141 fail: 0 > > Details are available at http://kerneltests.org/builders. Great, thanks for testing both of these and letting me know. greg k-h
Re: [PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC
On Tue, Mar 13, 2018 at 05:51:29PM +0100, Harald Geyer wrote:
> Maxime Ripard writes:
> > Hi,
> >
> > On Tue, Mar 13, 2018 at 10:18:22AM +0100, Harald Geyer wrote:
> >> Maxime Ripard writes:
> >>> On Mon, Mar 12, 2018 at 04:10:48PM +, Harald Geyer wrote:
> The A64 SoC features two display pipelines, one has a LCD output, the
> other has a HDMI output.
>
> Add support for simplefb for the LCD output. Tested on Teres I.
>
> This patch was inspired by work of Icenowy Zheng.
>
> Signed-off-by: Harald Geyer
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index ca1b365bc722..05d5e8def68a 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -52,6 +52,26 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> +chosen {
> +#address-cells = <1>;
> +#size-cells = <1>;
> +ranges;
> +
> +/*
> + * The pipeline mixer0-lcd0 depends on clock CLK_MIXER0 from DE2 CCU.
> + * However there is no support for this clock on A64 yet, so we depend
> + * on the upstream clocks here to keep them (and thus CLK_MIXER0) up.
> + */
> >>>
> >>> There's definitely support for the CLK_MIXER0 clock in the DE2 CCU
> >>> driver, so I guess this would need to be amended / fixed
> >>
> >> AFAIK on the A64 a special sram quirk is necessary, that never got merged:
> >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1574303.html
> >>
> >> I asked Icenowy if I should resubmit her patch as part of this series,
> >> but was told further discussion is necessary. I'm sure she can better
> >> explain the details than me.
> >>
> >> Actually if it wasn't for the sram quirk, there is a simplefb patch by
> >> her, that could have been merged long ago:
> >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1574304.html
> >
> > The issue with your patch is that, as soon as that clock is
> > functional, the DT with the node you were introducing here will no
> > longer be.
> >
> > And since people use their firmware DT or put them in NOR these days,
> > you can't really expect them to update them every release either.
>
> How is this a problem? - The clock can't be functional without adding
> a DT node for it's driver. So the breakage can only happen on DT update,
> which means we can avoid it, by moving the clocks to the proper places
> when we add the node actually using them for real.
Ah, sorry I missed it. Yeah, that would work.
> > I guess a proper solution would be to respin that patch.
>
> Sure, but as mentioned above I offered to do that and was told not to.
>
> As a compromise I could also move the simple framebuffer node from the
> A64 dtsi to the teres-i dts, where we know that the DT can be updated
> easily?
That's a matter of usecase, not only hardware, so this wouldn't work.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0
On 03/09/2018 09:00 PM, Ram Pai wrote: On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote: On 03/09/2018 09:12 AM, Ram Pai wrote: Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0. There is no valid reason for the above behavior. mprotect without a key does not necessarily use key 0, e.g. if protection keys are used to emulate page protection flag combination which is not directly supported by the hardware. Therefore, it seems to me that filtering out non-allocated keys is the right thing to do. I am not sure, what you mean. Do you agree with the patch or otherwise? I think it's inconsistent to make key 0 allocated, but not the key which is used for PROT_EXEC emulation, which is still reserved. Even if you change the key 0 behavior, it is still not possible to emulate mprotect behavior faithfully with an allocated key. Thanks, Florian
Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs
On 二, 2018-03-13 at 15:02 +0800, Zhang Rui wrote:
> Hi, Viresh,
>
> I will queue it for 4.17, with just one minor fix below.
>
I got the following warning from checkpatch.pl
---
WARNING: please write a paragraph that describes the config symbol
fully
#147: FILE: drivers/thermal/Kconfig:18:
+config THERMAL_STATISTICS
WARNING: Consider renaming function(s)
'thermal_cooling_device_total_trans_show' to 'total_trans_show'
#391: FILE: drivers/thermal/thermal_sysfs.c:901:
+}
WARNING: Consider renaming function(s)
'thermal_cooling_device_time_in_state_show' to 'time_in_state_show'
#395: FILE: drivers/thermal/thermal_sysfs.c:905:
+static DEVICE_ATTR(time_in_state, 0444,
WARNING: Consider renaming function(s)
'thermal_cooling_device_reset_store' to 'reset_store'
#397: FILE: drivers/thermal/thermal_sysfs.c:907:
+static DEVICE_ATTR(reset, 0200, NULL,
thermal_cooling_device_reset_store);
WARNING: Consider renaming function(s)
'thermal_cooling_device_trans_table_show' to 'trans_table_show'
#398: FILE: drivers/thermal/thermal_sysfs.c:908:
+static DEVICE_ATTR(trans_table, 0444,
total: 0 errors, 5 warnings, 366 lines checked
I'm okay with the first one because the description does not have to be
larger than 3 lines.
the last 4 warnings makes sense to me. I think we should rename the
function and use DEVICE_ATTR_RO() and DEVICE_ATTR_WO() instead.
what do you think?
thanks,
rui
> On 二, 2018-01-16 at 15:22 +0530, Viresh Kumar wrote:
> >
> > This extends the sysfs interface for thermal cooling devices and
> > exposes
> > some pretty useful statistics. These statistics have proven to be
> > quite
> > useful specially while doing benchmarks related to the task
> > scheduler,
> > where we want to make sure that nothing has disrupted the test,
> > specially the cooling device which may have put constraints on the
> > CPUs.
> > The information exposed here tells us to what extent the CPUs were
> > constrained by the thermal framework.
> >
> > The write-only "reset" file is used to reset the statistics.
> >
> > The read-only "time_in_state" file shows the clock_t time spent by
> > the
> > device in the respective cooling states, and it prints one line per
> > cooling state.
> >
> > The read-only "total_trans" file shows single positive integer
> > value
> > showing the total number of cooling state transitions the device
> > has
> > gone through since the time the cooling device is registered or the
> > time
> > when statistics were reset last.
> >
> > The read-only "trans_table" file shows a two dimensional matrix,
> > where
> > an entry (row i, column j) represents the number of
> > transitions
> > from State_i to State_j.
> >
> > This is how the directory structure looks like for a single cooling
> > device:
> >
> > $ ls -R /sys/class/thermal/cooling_device0/
> > /sys/class/thermal/cooling_device0/:
> > cur_state max_state power stats subsystem type uevent
> >
> > /sys/class/thermal/cooling_device0/power:
> > autosuspend_delay_ms runtime_active_time runtime_suspended_time
> > control runtime_status
> >
> > /sys/class/thermal/cooling_device0/stats:
> > reset time_in_state total_trans trans_table
> >
> > This is tested on ARM 64-bit Hisilicon hikey620 board running
> > Ubuntu
> > and
> > ARM 64-bit Hisilicon hikey960 board running Android.
> >
> > Signed-off-by: Viresh Kumar
> [snip]
>
> >
> > +static void cooling_device_stats_setup(struct
> > thermal_cooling_device
> > *cdev)
> > +{
> > + struct cooling_dev_stats *stats;
> > + unsigned long states;
> > + int var;
> > +
> > + if (cdev->ops->get_max_state(cdev, &states))
> > + return;
> > +
> > + states++; /* Total number of states is highest state + 1
> > */
> > +
> > + var = sizeof(*stats);
> > + var += sizeof(*stats->time_in_state) * states;
> > + var += sizeof(*stats->trans_table) * states * states;
> > +
> > + stats = kzalloc(var, GFP_KERNEL);
> > + if (!stats)
> > + return;
> > +
> > + stats->time_in_state = (ktime_t *)(stats + 1);
> > + stats->trans_table = (unsigned int *)(stats->time_in_state
> > +
> > states);
> > + cdev->stats = stats;
> > + stats->last_time = ktime_get();
> > + stats->max_states = states;
> > + cdev->stats = stats;
> > +
> cdev->stats is set twice here, I will remove the first one.
>
> thanks,
> rui
Re: [RfC PATCH] Add udmabuf misc device
Hi, > Either mlock account (because it's mlocked defacto), and get_user_pages > won't do that for you. > > Or you write the full-blown userptr implementation, including mmu_notifier > support (see i915 or amdgpu), but that also requires Christian Königs > latest ->invalidate_mapping RFC for dma-buf (since atm exporting userptr > buffers is a no-go). I guess I'll look at mlock accounting for starters then. Easier for now, and leaves the door open to switch to userptr later as this should be transparent to userspace. > > Known issue: Driver API isn't complete yet. Need add some flags, for > > example to support read-only buffers. > > dma-buf has no concept of read-only. I don't think we can even enforce > that (not many iommus can enforce this iirc), so pretty much need to > require r/w memory. Ah, ok. Just saw the 'write' arg for get_user_pages_fast and figured we might support that, but if iommus can't handle that anyway it's pointless indeed. > > Cc: David Airlie > > Cc: Tomeu Vizoso > > Signed-off-by: Gerd Hoffmann > > btw there's also the hyperdmabuf stuff from the xen folks, but imo their > solution of forwarding the entire dma-buf api is over the top. This here > looks _much_ better, pls cc all the hyperdmabuf people on your next > version. Fun fact: googling for "hyperdmabuf" found me your mail and nothing else :-o (Trying "hyper dmabuf" instead worked better then). Yes, will cc them on the next version. Not sure it'll help much on xen though due to the memory management being very different. Basically xen owns the memory, not the kernel of the control domain (dom0), so creating dmabufs for guest memory chunks isn't that simple ... Also it's not clear whenever they really need guest -> guest exports or guest -> dom0 exports. > Overall I like the idea, but too lazy to review. Cool. General comments on the idea was all I was looking for for the moment. Spare yor review cycles for the next version ;) > Oh, some kselftests for this stuff would be lovely. I'll look into it. thanks, Gerd
Re: linux-next: please clean up the clockevents tree
Hi Daniel, On Wed, 14 Mar 2018 07:56:00 +0100 Daniel Lezcano wrote: > > On 14/03/2018 00:02, Stephen Rothwell wrote: > > Hi Daniel, > > > > The clockevents tree appears to only contain an old version of patches > > that have been committed upstream. As such, it is only causing conflicts. > > Please resync with your upstream tree. > > Done. Excellent, thanks. -- Cheers, Stephen Rothwell pgpB5RME3k2c8.pgp Description: OpenPGP digital signature
Re: [PATCH] ARM: dts: sun8i-h3: Add Mali node
On Tue, Mar 13, 2018 at 11:16:45AM +0100, Giulio Benetti wrote: > The H3 has an ARM Mali 400 GPU, so add binding to our DT. > > Signed-off-by: Giulio Benetti How was this tested? Is there any specific reason not to share it with the H5? Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0
On 03/14/2018 09:00 AM, Florian Weimer wrote:
On 03/09/2018 09:00 PM, Ram Pai wrote:
On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote:
On 03/09/2018 09:12 AM, Ram Pai wrote:
Once an address range is associated with an allocated pkey, it
cannot be
reverted back to key-0. There is no valid reason for the above
behavior.
mprotect without a key does not necessarily use key 0, e.g. if
protection keys are used to emulate page protection flag combination
which is not directly supported by the hardware.
Therefore, it seems to me that filtering out non-allocated keys is
the right thing to do.
I am not sure, what you mean. Do you agree with the patch or otherwise?
I think it's inconsistent to make key 0 allocated, but not the key which
is used for PROT_EXEC emulation, which is still reserved. Even if you
change the key 0 behavior, it is still not possible to emulate mprotect
behavior faithfully with an allocated key.
Ugh. Should have read the code first before replying:
/* Do we need to assign a pkey for mm's execute-only maps? */
if (execute_only_pkey == -1) {
/* Go allocate one to use, which might fail */
execute_only_pkey = mm_pkey_alloc(mm);
if (execute_only_pkey < 0)
return -1;
need_to_set_mm_pkey = true;
}
So we do allocate the PROT_EXEC-only key, and I assume it means that the
key can be restored using pkey_mprotect. So the key 0 behavior is a
true exception after all, and it makes sense to realign the behavior
with the other keys.
Thanks,
Florian
[PATCH] pktgen: Fix memory leak in pktgen_if_write
_buf_ is an array and the one that must be freed is _tp_ instead.
Fixes: a870a02cc963 ("pktgen: use dynamic allocation for debug print buffer")
Reported-by: Wang Jian
Signed-off-by: Gustavo A. R. Silva
---
net/core/pktgen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index fd65761..545cf08 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -913,7 +913,7 @@ static ssize_t pktgen_if_write(struct file *file,
return PTR_ERR(tp);
pr_debug("%s,%zu buffer -:%s:-\n", name, count, tp);
- kfree(buf);
+ kfree(tp);
}
if (!strcmp(name, "min_pkt_size")) {
--
2.7.4
Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs
On 14-03-18, 16:01, Zhang Rui wrote: > WARNING: please write a paragraph that describes the config symbol > fully > #147: FILE: drivers/thermal/Kconfig:18: > +config THERMAL_STATISTICS > > WARNING: Consider renaming function(s) > 'thermal_cooling_device_total_trans_show' to 'total_trans_show' > #391: FILE: drivers/thermal/thermal_sysfs.c:901: > +} > > WARNING: Consider renaming function(s) > 'thermal_cooling_device_time_in_state_show' to 'time_in_state_show' > #395: FILE: drivers/thermal/thermal_sysfs.c:905: > +static DEVICE_ATTR(time_in_state, 0444, > > WARNING: Consider renaming function(s) > 'thermal_cooling_device_reset_store' to 'reset_store' > #397: FILE: drivers/thermal/thermal_sysfs.c:907: > +static DEVICE_ATTR(reset, 0200, NULL, > thermal_cooling_device_reset_store); > > WARNING: Consider renaming function(s) > 'thermal_cooling_device_trans_table_show' to 'trans_table_show' > #398: FILE: drivers/thermal/thermal_sysfs.c:908: > +static DEVICE_ATTR(trans_table, 0444, > > total: 0 errors, 5 warnings, 366 lines checked > > > I'm okay with the first one because the description does not have to be > larger than 3 lines. Right. > the last 4 warnings makes sense to me. I think we should rename the > function and use DEVICE_ATTR_RO() and DEVICE_ATTR_WO() instead. > > what do you think? I got those warnings as well, and I quietly ignored them :) I ignored the renaming part for the sake of consistency. The other existing routines for similar purpose are named as: thermal_cooling_device_type_show thermal_cooling_device_max_state_show thermal_cooling_device_cur_state_show thermal_cooling_device_cur_state_store for me it made more sense to follow that naming convention. And I didn't use the _RO and _WO variants for the same reason. Now here is what I propose now: - You apply this patch as-is and ignore the warning. - I will send few patches on top of that to do: - renaming of all such routines to shorter versions. - Use the _RO or _WO variants of the macro everywhere. What do you say ? -- viresh
BUG: unable to handle kernel paing request at fffffc0000000000
hello everyone: my kernel version is 3.10.0-327.62.59.101.x86_64, and why this Kasan's shadow memory is lost? Thanks; BUG: unable to handle kernel paging request at fc00 IP: [] kasan_mem_to_shadow include/linux/kasan.h:20 [inline] IP: [] memory_is_poisoned_4 mm/kasan/kasan.c:122 [inline] IP: [] memory_is_poisoned mm/kasan/kasan.c:244 [inline] IP: [] check_memory_region_inline mm/kasan/kasan.c:270 [inline] IP: [] __asan_load4+0x2b/0x80 mm/kasan/kasan.c:524 PGD 0 Oops: [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 21826 Comm: syz-executor0 Tainted: GB --- T 3.10.0-327.62.59.101.x86_64+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 task: 8802337ae680 ti: 880212dc8000 task.ti: 880212dc8000 RIP: 0010:[] [] kasan_mem_to_shadow include/linux/kasan.h:20 [inline] RIP: 0010:[] [] memory_is_poisoned_4 mm/kasan/kasan.c:122 [inline] RIP: 0010:[] [] memory_is_poisoned mm/kasan/kasan.c:244 [inline] RIP: 0010:[] [] check_memory_region_inline mm/kasan/kasan.c:270 [inline] RIP: 0010:[] [] __asan_load4+0x2b/0x80 mm/kasan/kasan.c:524 RSP: 0018:880212dcfba0 EFLAGS: 00010286 RAX: fbff RBX: 8802286ddd60 RCX: 8167b601 RDX: dc00 RSI: 0008 RDI: fff8 RBP: 880212dcfba0 R08: 0007 R09: R10: 8800 R11: R12: 8802286da980 R13: R14: fff8 R15: 81c9b370 FS: () GS:8800bb10() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: fc00 CR3: 0255a000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Call Trace: [] crypto_ahash_digestsize include/crypto/hash.h:148 [inline] [] hash_sock_destruct+0x81/0x160 crypto/algif_hash.c:270 [] __sk_free+0x44/0x330 net/core/sock.c:1392 [] sk_free+0x2d/0x40 net/core/sock.c:1422 [] sock_put include/net/sock.h:1722 [inline] [] af_alg_release+0x55/0x70 crypto/af_alg.c:123 [] sock_release+0x5c/0x190 net/socket.c:570 [] sock_close+0x1b/0x20 net/socket.c:1161 [] __fput+0x1bb/0x560 fs/file_table.c:246 [] fput+0x1a/0x20 fs/file_table.c:283 [] task_work_run+0x11f/0x1e0 kernel/task_work.c:87 [] exit_task_work include/linux/task_work.h:21 [inline] [] do_exit+0x68b/0x1b40 kernel/exit.c:815 [] do_group_exit+0x91/0x1f0 kernel/exit.c:948 [] SYSC_exit_group kernel/exit.c:959 [inline] [] SyS_exit_group+0x22/0x30 kernel/exit.c:957 [] system_call_fastpath+0x16/0x1b Code: 55 48 b8 ff ff ff ff ff 7f ff ff 48 39 c7 48 89 e5 48 8b 4d 08 76 43 48 89 f8 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 48 01 d0 <66> 83 38 00 75 07 5d c3 0f 1f 44 00 00 48 8d 77 03 49 89 f0 49 RIP [] kasan_mem_to_shadow include/linux/kasan.h:20 [inline] RIP [] memory_is_poisoned_4 mm/kasan/kasan.c:122 [inline] RIP [] memory_is_poisoned mm/kasan/kasan.c:244 [inline] RIP [] check_memory_region_inline mm/kasan/kasan.c:270 [inline] RIP [] __asan_load4+0x2b/0x80 mm/kasan/kasan.c:524 RSP CR2: fc00
Re: [PATCH v2 1/6] phy: rockchip-typec: fall back to working in host-mode if extcon is missing.
Hi Kishon,
Am Donnerstag, 1. März 2018, 16:25:10 CET schrieb Enric Balletbo i Serra:
> Right now the rockchip type-c phy does fail probing when no extcon is
> detected. Some boards get the cable-state via the extcon interface and
> have this supported, other boards seem to use the fusb302 chip or
> another but the driver currently does not seem to utilize the extcon
> interface to report the cable-state. And, other, just connect the type-c
> to a standard USB-A port so use no controller at all. A missing extcon
> shouldn't fail to probe, instead, should just fall back to working in
> host-mode if it cannot get the extcon.
>
> Fixes: c301b327aea898af ("arm64: dts: rockchip: add usb3-phy otg-port
> support for rk3399") Reported-by: Vicente Bergas
> Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Heiko Stuebner
I did revert the original commit mentioned in the fixes tag for 4.16-rc
but it would nevertheless be really cool if these 2 patches (code + binding)
could make it into your tree for 4.17 :-)
And ideally also with the other 5 patches from Enric starting at
[PATCH v3 1/6] phy: rockchip-typec: deprecate some DT properties for
various register fields.
from 2018-02-16.
Thanks
Heiko
[PATCH v10 2/5] iommu/arm-smmu: Add pm_runtime/sleep ops
From: Sricharan R
The smmu needs to be functional only when the respective
master's using it are active. The device_link feature
helps to track such functional dependencies, so that the
iommu gets powered when the master device enables itself
using pm_runtime. So by adapting the smmu driver for
runtime pm, above said dependency can be addressed.
This patch adds the pm runtime/sleep callbacks to the
driver and also the functions to parse the smmu clocks
from DT and enable them in resume/suspend.
Signed-off-by: Sricharan R
Signed-off-by: Archit Taneja
[vivek: Clock rework to request bulk of clocks]
Signed-off-by: Vivek Gautam
Reviewed-by: Tomasz Figa
---
- No change since v9.
drivers/iommu/arm-smmu.c | 60 ++--
1 file changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60792a8..d5873d545024 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#include
@@ -205,6 +206,8 @@ struct arm_smmu_device {
u32 num_global_irqs;
u32 num_context_irqs;
unsigned int*irqs;
+ struct clk_bulk_data*clks;
+ int num_clks;
u32 cavium_id_base; /* Specific to Cavium */
@@ -1897,10 +1900,12 @@ static int arm_smmu_device_cfg_probe(struct
arm_smmu_device *smmu)
struct arm_smmu_match_data {
enum arm_smmu_arch_version version;
enum arm_smmu_implementation model;
+ const char * const *clks;
+ int num_clks;
};
#define ARM_SMMU_MATCH_DATA(name, ver, imp)\
-static struct arm_smmu_match_data name = { .version = ver, .model = imp }
+static const struct arm_smmu_match_data name = { .version = ver, .model = imp }
ARM_SMMU_MATCH_DATA(smmu_generic_v1, ARM_SMMU_V1, GENERIC_SMMU);
ARM_SMMU_MATCH_DATA(smmu_generic_v2, ARM_SMMU_V2, GENERIC_SMMU);
@@ -1919,6 +1924,23 @@ static const struct of_device_id arm_smmu_of_match[] = {
};
MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
+static void arm_smmu_fill_clk_data(struct arm_smmu_device *smmu,
+ const char * const *clks)
+{
+ int i;
+
+ if (smmu->num_clks < 1)
+ return;
+
+ smmu->clks = devm_kcalloc(smmu->dev, smmu->num_clks,
+ sizeof(*smmu->clks), GFP_KERNEL);
+ if (!smmu->clks)
+ return;
+
+ for (i = 0; i < smmu->num_clks; i++)
+ smmu->clks[i].id = clks[i];
+}
+
#ifdef CONFIG_ACPI
static int acpi_smmu_get_data(u32 model, struct arm_smmu_device *smmu)
{
@@ -2001,6 +2023,9 @@ static int arm_smmu_device_dt_probe(struct
platform_device *pdev,
data = of_device_get_match_data(dev);
smmu->version = data->version;
smmu->model = data->model;
+ smmu->num_clks = data->num_clks;
+
+ arm_smmu_fill_clk_data(smmu, data->clks);
parse_driver_options(smmu);
@@ -2099,6 +2124,14 @@ static int arm_smmu_device_probe(struct platform_device
*pdev)
smmu->irqs[i] = irq;
}
+ err = devm_clk_bulk_get(smmu->dev, smmu->num_clks, smmu->clks);
+ if (err)
+ return err;
+
+ err = clk_bulk_prepare(smmu->num_clks, smmu->clks);
+ if (err)
+ return err;
+
err = arm_smmu_device_cfg_probe(smmu);
if (err)
return err;
@@ -2181,6 +2214,9 @@ static int arm_smmu_device_remove(struct platform_device
*pdev)
/* Turn the thing off */
writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
+
+ clk_bulk_unprepare(smmu->num_clks, smmu->clks);
+
return 0;
}
@@ -2197,7 +2233,27 @@ static int __maybe_unused arm_smmu_pm_resume(struct
device *dev)
return 0;
}
-static SIMPLE_DEV_PM_OPS(arm_smmu_pm_ops, NULL, arm_smmu_pm_resume);
+static int __maybe_unused arm_smmu_runtime_resume(struct device *dev)
+{
+ struct arm_smmu_device *smmu = dev_get_drvdata(dev);
+
+ return clk_bulk_enable(smmu->num_clks, smmu->clks);
+}
+
+static int __maybe_unused arm_smmu_runtime_suspend(struct device *dev)
+{
+ struct arm_smmu_device *smmu = dev_get_drvdata(dev);
+
+ clk_bulk_disable(smmu->num_clks, smmu->clks);
+
+ return 0;
+}
+
+static const struct dev_pm_ops arm_smmu_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(NULL, arm_smmu_pm_resume)
+ SET_RUNTIME_PM_OPS(arm_smmu_runtime_suspend,
+ arm_smmu_runtime_resume, NULL)
+};
static struct platform_driver arm_smmu_driver = {
.driver = {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v10 4/5] iommu/arm-smmu: Add the device_link between masters and smmu
From: Sricharan R
Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which gets
called once when the master is added to the smmu.
Signed-off-by: Sricharan R
Signed-off-by: Vivek Gautam
Reviewed-by: Tomasz Figa
---
Changes since v9:
- Using device_link_del_dev() to delete the device link, instead of
doing it in two steps - device_link_find() to first find the link, and
then calling device_link_del().
drivers/iommu/arm-smmu.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 56a04ae80bf3..4cf270ffd449 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1460,10 +1460,31 @@ static int arm_smmu_add_device(struct device *dev)
iommu_device_link(&smmu->iommu, dev);
+ if (pm_runtime_enabled(smmu->dev)) {
+ struct device_link *link;
+
+ /*
+* Establish the link between smmu and master, so that the
+* smmu gets runtime enabled/disabled as per the master's
+* needs.
+*/
+ link = device_link_add(dev, smmu->dev, DL_FLAG_PM_RUNTIME);
+ if (!link) {
+ dev_warn(smmu->dev,
+"Unable to add link to the consumer %s\n",
+dev_name(dev));
+ ret = -ENODEV;
+ goto out_unlink;
+ }
+ }
+
arm_smmu_rpm_put(smmu);
return 0;
+out_unlink:
+ iommu_device_unlink(&smmu->iommu, dev);
+ arm_smmu_master_free_smes(fwspec);
out_rpm_put:
arm_smmu_rpm_put(smmu);
out_cfg_free:
@@ -1486,6 +1507,9 @@ static void arm_smmu_remove_device(struct device *dev)
cfg = fwspec->iommu_priv;
smmu = cfg->smmu;
+ if (pm_runtime_enabled(smmu->dev))
+ device_link_del_dev(dev, smmu->dev);
+
ret = arm_smmu_rpm_get(smmu);
if (ret < 0)
return;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v10 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant
qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
clock and power requirements. This smmu core is used with
multiple masters on msm8996, viz. mdss, video, etc.
Add bindings for the same.
Signed-off-by: Vivek Gautam
Reviewed-by: Rob Herring
Reviewed-by: Tomasz Figa
---
- No change since v9.
.../devicetree/bindings/iommu/arm,smmu.txt | 42 ++
drivers/iommu/arm-smmu.c | 14
2 files changed, 56 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 8a6ffce12af5..7c71a6ed465a 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -17,10 +17,19 @@ conditions.
"arm,mmu-401"
"arm,mmu-500"
"cavium,smmu-v2"
+"qcom,-smmu-v2", "qcom,smmu-v2"
depending on the particular implementation and/or the
version of the architecture implemented.
+ A number of Qcom SoCs use qcom,smmu-v2 version of the IP.
+ "qcom,-smmu-v2" represents a soc specific compatible
+ string that should be present along with the "qcom,smmu-v2"
+ to facilitate SoC specific clocks/power connections and to
+ address specific bug fixes.
+ An example string would be -
+ "qcom,msm8996-smmu-v2", "qcom,smmu-v2".
+
- reg : Base address and size of the SMMU.
- #global-interrupts : The number of global interrupts exposed by the
@@ -71,6 +80,22 @@ conditions.
or using stream matching with #iommu-cells = <2>, and
may be ignored if present in such cases.
+- clock-names:List of the names of clocks input to the device. The
+ required list depends on particular implementation and
+ is as follows:
+ - for "qcom,smmu-v2":
+- "bus": clock required for downstream bus access and
+ for the smmu ptw,
+- "iface": clock required to access smmu's registers
+ through the TCU's programming interface.
+ - unspecified for other implementations.
+
+- clocks: Specifiers for all clocks listed in the clock-names property,
+ as per generic clock bindings.
+
+- power-domains: Specifiers for power domains required to be powered on for
+ the SMMU to operate, as per generic power domain bindings.
+
** Deprecated properties:
- mmu-masters (deprecated in favour of the generic "iommus" binding) :
@@ -137,3 +162,20 @@ conditions.
iommu-map = <0 &smmu3 0 0x400>;
...
};
+
+ /* Qcom's arm,smmu-v2 implementation */
+ smmu4: iommu {
+ compatible = "qcom,msm8996-smmu-v2", "qcom,smmu-v2";
+ reg = <0xd0 0x1>;
+
+ #global-interrupts = <1>;
+ interrupts = ,
+,
+;
+ #iommu-cells = <1>;
+ power-domains = <&mmcc MDSS_GDSC>;
+
+ clocks = <&mmcc SMMU_MDP_AXI_CLK>,
+<&mmcc SMMU_MDP_AHB_CLK>;
+ clock-names = "bus", "iface";
+ };
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 4cf270ffd449..03750ba15224 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -119,6 +119,7 @@ enum arm_smmu_implementation {
GENERIC_SMMU,
ARM_MMU500,
CAVIUM_SMMUV2,
+ QCOM_SMMUV2,
};
struct arm_smmu_s2cr {
@@ -1995,6 +1996,17 @@ ARM_SMMU_MATCH_DATA(arm_mmu401, ARM_SMMU_V1_64K,
GENERIC_SMMU);
ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
+static const char * const qcom_smmuv2_clks[] = {
+ "bus", "iface",
+};
+
+static const struct arm_smmu_match_data qcom_smmuv2 = {
+ .version = ARM_SMMU_V2,
+ .model = QCOM_SMMUV2,
+ .clks = qcom_smmuv2_clks,
+ .num_clks = ARRAY_SIZE(qcom_smmuv2_clks),
+};
+
static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,smmu-v1", .data = &smmu_generic_v1 },
{ .compatible = "arm,smmu-v2", .data = &smmu_generic_v2 },
@@ -2002,6 +2014,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,mmu-401", .data = &arm_mmu401 },
{ .compatible = "arm,mmu-500", .data = &arm_mmu500 },
{ .compatible = "cavium,smmu-v2", .data = &cavium_smmuv2 },
+ { .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 },
{ },
};
MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
@@ -2376,6 +2389,7 @@ IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400");
IOMMU
[PATCH v10 0/5] iommu/arm-smmu: Add runtime pm/sleep support
This series provides the support for turning on the arm-smmu's clocks/power domains using runtime pm. This is done using the recently introduced device links patches, which lets the smmu's runtime to follow the master's runtime pm, so the smmu remains powered only when the masters use it. As not all implementations support clock/power gating, we are checking for a valid 'smmu->dev's pm_domain' to conditionally enable the runtime power management for such smmu implementations that can support it. This series also adds support for Qcom's arm-smmu-v2 variant that has different clocks and power requirements. Took some reference from the exynos runtime patches [1]. With conditional runtime pm now, we avoid touching dev->power.lock in fastpaths for smmu implementations that don't need to do anything useful with pm_runtime. This lets us to use the much-argued pm_runtime_get_sync/put_sync() calls in map/unmap callbacks so that the clients do not have to worry about handling any of the arm-smmu's power. Previous version of this patch series is @ [5]. [v10] * Introduce device_link_del_dev() API to delete the link between given consumer and supplier devices. The users of device link do not need to store link pointer to delete the link later. They can straightaway use this API by passing consumer and supplier devices. * Made corresponding changes to arm-smmu driver patch handling the device links. * Dropped the patch [9] that was adding device_link_find() API to device core layer. device_link_del_dev() serves the purpose to directly delete the link between two given devices. [v9] * Removed 'rpm_supported' flag, instead checking on pm_domain to enable runtime pm. * Creating device link only when the runtime pm is enabled, as we don't need a device link besides managing the power dependency between supplier and consumer devices. * Introducing a patch to add device_link_find() API that finds and existing link between supplier and consumer devices. Also, made necessary change to device_link_add() to use this API. * arm_smmu_remove_device() now uses this device_link_find() to find the device link between smmu device and the master device, and then delete this link. * Dropped the destroy_domain_context() fix [8] as it was rather, introducing catastrophically bad problem by destroying 'good dev's domain context. * Added 'Reviwed-by' tag for Tomasz's review. [v8] * Major change - - Added a flag 'rpm_supported' which each platform that supports runtime pm, can enable, and we enable runtime_pm over arm-smmu only when this flag is set. - Adding the conditional pm_runtime_get/put() calls to .map, .unmap and .attach_dev ops. - Dropped the patch [6] that exported pm_runtim_get/put_suupliers(), and also dropped the user driver patch [7] for these APIs. * Clock code further cleanup - doing only clk_bulk_enable() and clk_bulk_disable() in runtime pm callbacks. We shouldn't be taking a slow path (clk_prepare/unprepare()) from these runtime pm callbacks. Thereby, moved clk_bulk_prepare() to arm_smmu_device_probe(), and clk_bulk_unprepare() to arm_smmu_device_remove(). - clk data filling to a common method arm_smmu_fill_clk_data() that fills the clock ids and number of clocks. * Addressed other nits and comments - device_link_add() error path fixed. - Fix for checking negative error value from pm_runtime_get_sync(). - Documentation redo. * Added another patch fixing the error path in arm_smmu_attach_dev() to destroy allocated domain context. [v7] * Addressed review comments given by Robin Murphy - - Added device_link_del() in .remove_device path. - Error path cleanup in arm_smmu_add_device(). - Added pm_runtime_get/put_sync() in .remove path, and replaced pm_runtime_force_suspend() with pm_runtime_disable(). - clk_names cleanup in arm_smmu_init_clks() * Added 'Reviewed-by' given by Rob H. [V6] * Added Ack given by Rafael to first patch in the series. * Addressed Rob Herring's comment for adding soc specific compatible string as well besides 'qcom,smmu-v2'. [V5] * Dropped runtime pm calls from "arm_smmu_unmap" op as discussed over the list [3] for the last patch series. * Added a patch to export pm_runtime_get/put_suppliers() APIs to the series as agreed with Rafael [4]. * Added the related patch for msm drm iommu layer to use pm_runtime_get/put_suppliers() APIs in msm_mmu_funcs. * Dropped arm-mmu500 clock patch since that would break existing platforms. * Changed compatible 'qcom,msm8996-smmu-v2' to 'qcom,smmu-v2' to reflect the IP version rather than the platform on which it is used. The same IP is used across multiple platforms including msm8996, and sdm845 etc. * Using clock bulk APIs to handle the cloc
[PATCH v10 1/5] driver core: Delete the link between two given devices
Given the consumer and supplier devices, add an API to
delete the link between them.
Suggested-by: Tomasz Figa
Signed-off-by: Vivek Gautam
Cc: Rafael J. Wysocki
Cc: Greg Kroah-Hartman
---
- This patch replaces an earlier patch [1] that was adding
device_link_find() API.
[1] https://patchwork.kernel.org/patch/10277975/
drivers/base/core.c| 31 +++
include/linux/device.h | 1 +
2 files changed, 32 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 5847364f25d9..e13d904e1e12 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -336,6 +336,37 @@ void device_link_del(struct device_link *link)
}
EXPORT_SYMBOL_GPL(device_link_del);
+/**
+ * device_link_del_dev - Delete a link between two given devices
+ * @consumer: Consumer end of the link.
+ * @supplier: Supplier end of the link.
+ *
+ * The caller must ensure proper synchronization of this function with runtime
+ * PM.
+ */
+void device_link_del_dev(struct device *consumer, struct device *supplier)
+{
+ struct device_link *link;
+
+ if (!consumer || !supplier)
+ return;
+
+ device_links_write_lock();
+ device_pm_lock();
+
+ list_for_each_entry(link, &supplier->links.consumers, s_node) {
+ if (link->consumer == consumer) {
+ __device_link_del(link);
+ /* just one link between the devices */
+ break;
+ }
+ }
+
+ device_pm_unlock();
+ device_links_write_unlock();
+}
+EXPORT_SYMBOL_GPL(device_link_del_dev);
+
static void device_links_missing_supplier(struct device *dev)
{
struct device_link *link;
diff --git a/include/linux/device.h b/include/linux/device.h
index b093405ed525..14508d843f67 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1278,6 +1278,7 @@ extern const char *dev_driver_string(const struct device
*dev);
struct device_link *device_link_add(struct device *consumer,
struct device *supplier, u32 flags);
void device_link_del(struct device_link *link);
+void device_link_del_dev(struct device *consumer, struct device *supplier);
#ifdef CONFIG_PRINTK
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] pktgen: use dynamic allocation for debug print buffer
Arnd:
Thanks for the fix.
On 03/13/2018 10:02 PM, Wang Jian wrote:
+ kfree(buf);
free tb? buf is an array.
Wang:
Thanks for the report. I already sent a patch to fix this:
https://patchwork.kernel.org/patch/10281587/
--
Gustavo
On Wed, Mar 14, 2018 at 8:25 AM, David Miller wrote:
From: Arnd Bergmann
Date: Tue, 13 Mar 2018 21:58:39 +0100
After the removal of the VLA, we get a harmless warning about a large
stack frame:
net/core/pktgen.c: In function 'pktgen_if_write':
net/core/pktgen.c:1710:1: error: the frame size of 1076 bytes is larger than
1024 bytes [-Werror=frame-larger-than=]
The function was previously shown to be safe despite hitting
the 1024 bye warning level. To get rid of the annoyging warning,
while keeping it readable, this changes it to use strndup_user().
Obviously this is not a fast path, so the kmalloc() overhead
can be disregarded.
Fixes: 35951393bbff ("pktgen: Remove VLA usage")
Signed-off-by: Arnd Bergmann
Applied, thanks.
[PATCHv3 1/2] zsmalloc: introduce zs_huge_class_size() function
From: Sergey Senozhatsky
Not every object can be share its zspage with other objects, e.g. when
the object is as big as zspage or nearly as big a zspage. For such
objects zsmalloc has a so called huge class - every object which belongs
to huge class consumes the entire zspage (which consists of a physical
page). On x86_64, PAGE_SHIFT 12 box, the first non-huge class size is
3264, so starting down from size 3264, objects can share page(-s) and thus
minimize memory wastage.
ZRAM, however, has its own statically defined watermark for huge objects -
"3 * PAGE_SIZE / 4 = 3072", and forcibly stores every object larger than
this watermark (3072) as a PAGE_SIZE object, in other words, to a huge
class, while zsmalloc can keep some of those objects in non-huge classes.
This results in increased memory consumption.
zsmalloc knows better if the object is huge or not. Introduce
zs_huge_class_size() function which tells if the given object can be
stored in one of non-huge classes or not. This will let us to drop ZRAM's
huge object watermark and fully rely on zsmalloc when we decide if the
object is huge.
Signed-off-by: Sergey Senozhatsky
Cc: Minchan Kim
Cc: Mike Rapoport
---
include/linux/zsmalloc.h | 2 ++
mm/zsmalloc.c| 41 +
2 files changed, 43 insertions(+)
diff --git a/include/linux/zsmalloc.h b/include/linux/zsmalloc.h
index 57a8e98f2708..2219cce81ca4 100644
--- a/include/linux/zsmalloc.h
+++ b/include/linux/zsmalloc.h
@@ -47,6 +47,8 @@ void zs_destroy_pool(struct zs_pool *pool);
unsigned long zs_malloc(struct zs_pool *pool, size_t size, gfp_t flags);
void zs_free(struct zs_pool *pool, unsigned long obj);
+size_t zs_huge_class_size(struct zs_pool *pool);
+
void *zs_map_object(struct zs_pool *pool, unsigned long handle,
enum zs_mapmode mm);
void zs_unmap_object(struct zs_pool *pool, unsigned long handle);
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 4076c406dd32..61cb05dc950c 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -193,6 +193,7 @@ static struct vfsmount *zsmalloc_mnt;
* (see: fix_fullness_group())
*/
static const int fullness_threshold_frac = 4;
+static size_t huge_class_size;
struct size_class {
spinlock_t lock;
@@ -1409,6 +1410,25 @@ void zs_unmap_object(struct zs_pool *pool, unsigned long
handle)
}
EXPORT_SYMBOL_GPL(zs_unmap_object);
+/**
+ * zs_huge_class_size() - Returns the size (in bytes) of the first huge
+ *zsmalloc &size_class.
+ * @pool: zsmalloc pool to use
+ *
+ * The function returns the size of the first huge class - any object of equal
+ * or bigger size will be stored in zspage consisting of a single physical
+ * page.
+ *
+ * Context: Any context.
+ *
+ * Return: the size (in bytes) of the first huge zsmalloc &size_class.
+ */
+size_t zs_huge_class_size(struct zs_pool *pool)
+{
+ return huge_class_size;
+}
+EXPORT_SYMBOL_GPL(zs_huge_class_size);
+
static unsigned long obj_malloc(struct size_class *class,
struct zspage *zspage, unsigned long handle)
{
@@ -2365,6 +2385,27 @@ struct zs_pool *zs_create_pool(const char *name)
pages_per_zspage = get_pages_per_zspage(size);
objs_per_zspage = pages_per_zspage * PAGE_SIZE / size;
+ /*
+* We iterate from biggest down to smallest classes,
+* so huge_class_size holds the size of the first huge
+* class. Any object bigger than or equal to that will
+* endup in the huge class.
+*/
+ if (pages_per_zspage != 1 && objs_per_zspage != 1 &&
+ !huge_class_size) {
+ huge_class_size = size;
+ /*
+* The object uses ZS_HANDLE_SIZE bytes to store the
+* handle. We need to subtract it, because zs_malloc()
+* unconditionally adds handle size before it performs
+* size class search - so object may be smaller than
+* huge class size, yet it still can end up in the huge
+* class because it grows by ZS_HANDLE_SIZE extra bytes
+* right before class lookup.
+*/
+ huge_class_size -= (ZS_HANDLE_SIZE - 1);
+ }
+
/*
* size_class is used for normal zsmalloc operation such
* as alloc/free for that size. Although it is natural that we
--
2.16.2
[PATCHv3 2/2] zram: drop max_zpage_size and use zs_huge_class_size()
From: Sergey Senozhatsky
This patch removes ZRAM's enforced "huge object" value and uses zsmalloc
huge-class watermark instead, which makes more sense.
TEST
- I used a 1G zram device, LZO compression back-end, original
data set size was 444MB. Looking at zsmalloc classes stats the
test ended up to be pretty fair.
BASE ZRAM/ZSMALLOC
=
zram mm_stat
498978816 191482495 1998315520 199831552156340
zsmalloc classes
class size almost_full almost_empty obj_allocated obj_used pages_used
pages_per_zspage freeable
...
151 2448 00 1240 1240744
30
168 2720 00 4200 4200 2800
20
190 3072 00 10100 10100 7575
30
202 3264 00 380380304
40
254 4096 00 10620 10620 10620
10
Total 7 46106982 106187 48787
0
PATCHED ZRAM/ZSMALLOC
=
zram mm_stat
498978816 182579184 1942487040 194248704156280
zsmalloc classes
class size almost_full almost_empty obj_allocated obj_used pages_used
pages_per_zspage freeable
...
151 2448 00 1240 1240744
30
168 2720 00 4200 4200 2800
20
190 3072 00 10100 10100 7575
30
202 3264 00 7180 7180 5744
40
254 4096 00 3820 3820 3820
10
Total 8 45106959 106193 47424
0
As we can see, we reduced the number of objects stored in class-4096,
because a huge number of objects which we previously forcibly stored in
class-4096 now stored in non-huge class-3264. This results in lower
memory consumption:
- zsmalloc now uses 47424 physical pages, which is less than 48787 pages
zsmalloc used before.
- objects that we store in class-3264 share zspages. That's why overall
the number of pages that both class-4096 and class-3264 consumed went
down from 10924 to 9564.
Signed-off-by: Sergey Senozhatsky
Cc: Minchan Kim
Cc: Mike Rapoport
---
drivers/block/zram/zram_drv.c | 9 -
drivers/block/zram/zram_drv.h | 16
2 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 71b449613cfa..0f3fadd71230 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -44,6 +44,11 @@ static const char *default_compressor = "lzo";
/* Module params (documentation at end) */
static unsigned int num_devices = 1;
+/*
+ * Pages that compress to sizes equals or greater than this are stored
+ * uncompressed in memory.
+ */
+static size_t huge_class_size;
static void zram_free_page(struct zram *zram, size_t index);
@@ -786,6 +791,8 @@ static bool zram_meta_alloc(struct zram *zram, u64 disksize)
return false;
}
+ if (!huge_class_size)
+ huge_class_size = zs_huge_class_size(zram->mem_pool);
return true;
}
@@ -965,7 +972,7 @@ static int __zram_bvec_write(struct zram *zram, struct
bio_vec *bvec,
return ret;
}
- if (unlikely(comp_len > max_zpage_size)) {
+ if (unlikely(comp_len >= huge_class_size)) {
if (zram_wb_enabled(zram) && allow_wb) {
zcomp_stream_put(zram->comp);
ret = write_to_bdev(zram, bvec, index, bio, &element);
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index 31762db861e3..d71c8000a964 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -21,22 +21,6 @@
#include "zcomp.h"
-/*-- Configurable parameters */
-
-/*
- * Pages that compress to size greater than this are stored
- * uncompressed in memory.
- */
-static const size_t max_zpage_size = PAGE_SIZE / 4 * 3;
-
-/*
- * NOTE: max_zpage_size must be less than or equal to:
- * ZS_MAX_ALLOC_SIZE. Otherwise, zs_malloc() would
- * always return failure.
- */
-
-/*-- End of configurable params */
-
#define SECTOR_SHIFT 9
#define SECTORS_PER_PAGE_SHIFT (PAGE_SHIFT - SECTOR_SHIFT)
#define SECTORS_PER_PAGE (1 << SECTORS_PER_PAGE_SHIFT)
--
2.16.2
Re: int3403_driver_init needs over 330 ms to finish
Dear Rui, On 03/14/2018 08:32 AM, Zhang Rui wrote: On 二, 2018-03-13 at 20:39 +0100, Paul Menzel wrote: Booting the Dell XPS 13 9370 with Linux 4.16-rc4+ and `initcall_debug`, shows it is shown that int3403_driver_init needs over 330 ms to run. [2.524839] initcall int3403_driver_init+0x0/0x1000 [int3403_thermal] returned 0 after 333972 usecs I guess most of the time are spent in evaluating ACPI ASL code. But anyway, please create a bugzilla report and attach both dmesg and acpidump there. I created bug report #199113 [1], and attached the requested files. Kind regards, Paul [1] https://bugzilla.kernel.org/show_bug.cgi?id=199113
Re: [PATCH] Add Apple Carplay driver
On Tue, 2018-03-13 at 23:53 -0700, Matthew Dharm wrote: > Why is this a kernel-level driver, rather than a userspace application > that uses libusb to send the single vendor-specific command required? > Since this command would be applicable to many CarPlay devices, with > many different VID/PIDs, it would seem to make more sense as a > userspace app that took a reference to a USB device or VID/PID. Sorry, I'm not familiar with libusb. But after I roughly read a simple example using libusb, it indeed can be realized by a userspace driver. Thanks for your useful comments > > Matt > > On Tue, Mar 13, 2018 at 11:02 PM, Chunfeng Yun > wrote: > > From bf48dcd9cb254576cfea373c9a5d2ab996408895 Mon Sep 17 00:00:00 2001 > > From: Chunfeng Yun > > Date: Tue, 13 Mar 2018 11:47:38 +0800 > > Subject: [PATCH] Add Apple Carplay driver > > > > Some Apple devices which support Carplay can enter USB Host Mode from USB > > Device Mode after receiving a specific USB Vendor Request. There is a > > requirement apply to accesssories that support the USB dual role switch > > feature, and must have a USB-A receptacle that is capable of functioning > > in both USB Host and USB Device roles. > > It means that the driver should supports manual Dual-Role switch, due to > > no IDDIG pin is avaliable. > > > > There is no suitable place to add this spicific USB Vendor Request, so > > here I extract a single driver which allow user force to send it by a debug > > interface when need it, and keep it independent on USB Dual-Role Controller > > Drivers. > > But to implement carplay feature, there are some requirments for USB > > Dual-Role > > Driver: > > 1. supports manual dual-role switch, such as, by a debug interface; > > 2. keep vbus alive even when switch host into device mode; > > > > More information please refer to "Chapter 46. USB Role Switch" in > > MFI Accessroy Interface Specification.pdf > > > > Chunfeng Yun (1): > > usb: misc: supports Apple Carplay driver > > > > drivers/usb/misc/Kconfig |9 +++ > > drivers/usb/misc/Makefile |1 + > > drivers/usb/misc/carplay.c | 193 > > > > 3 files changed, 203 insertions(+) > > create mode 100644 drivers/usb/misc/carplay.c > > > > -- > > 1.7.9.5 > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > >
[PATCHv3 0/2] zsmalloc/zram: drop zram's max_zpage_size
Hello, ZRAM's max_zpage_size is a bad thing. It forces zsmalloc to store normal objects as huge ones, which results in bigger zsmalloc memory usage. Drop it and use actual zsmalloc huge-class value when decide if the object is huge or not. v3: - add pool param to zs_huge_class_size() [Minchan] Sergey Senozhatsky (2): zsmalloc: introduce zs_huge_class_size() function zram: drop max_zpage_size and use zs_huge_class_size() drivers/block/zram/zram_drv.c | 9 - drivers/block/zram/zram_drv.h | 16 include/linux/zsmalloc.h | 2 ++ mm/zsmalloc.c | 41 + 4 files changed, 51 insertions(+), 17 deletions(-) -- 2.16.2
Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())
On 2018-03-14, Al Viro wrote:
>>> + rcu_read_lock();/* to protect parent */
>>> + spin_unlock(&dentry->d_lock);
>>> + parent = READ_ONCE(dentry->d_parent);
>>
>> The preceeding line should be removed. We already have a "parent"
>> from before we did the most recent trylock().
>
> Nope. We have parent, yes, but it had been fetched outside of
> rcu_read_lock(). So the object it used to point to might have been
> already freed and we can't do this:
>
>>> + spin_lock(&parent->d_lock);
When rcu_read_lock() is called, we are still holding dentry->d_lock. At
that point dentry->d_parent cannot have changed and cannot have been
freed. So the parent fetched outside of rcu_read_lock() is also
protected from freeing inside that rcu_read_lock().
> Come to think of that, it might make sense to lift rcu_read_lock() all
> the way out of that sucker.
Agreed.
> Objections? Below is the incremental I'd fold into that commit:
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index f0e73c93182b..0d1dac750c0a 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1000,7 +1000,6 @@ static bool shrink_lock_dentry(struct dentry *dentry)
>
> inode = dentry->d_inode;
> if (inode && unlikely(!spin_trylock(&inode->i_lock))) {
> - rcu_read_lock();/* to protect inode */
> spin_unlock(&dentry->d_lock);
> spin_lock(&inode->i_lock);
> spin_lock(&dentry->d_lock);
> @@ -1009,16 +1008,14 @@ static bool shrink_lock_dentry(struct dentry *dentry)
> /* changed inode means that somebody had grabbed it */
> if (unlikely(inode != dentry->d_inode))
> goto out;
> - rcu_read_unlock();
> }
>
> parent = dentry->d_parent;
> + /* parent will stay allocated until we drop rcu_read_lock */
I think this comment is not necessary since this function no longer
deals with dropping rcu_read_lock. But if we keep it, it should be added
for the inode above as well.
> if (IS_ROOT(dentry) || likely(spin_trylock(&parent->d_lock)))
> return true;
>
> - rcu_read_lock();/* to protect parent */
> spin_unlock(&dentry->d_lock);
> - parent = READ_ONCE(dentry->d_parent);
> spin_lock(&parent->d_lock);
> if (unlikely(parent != dentry->d_parent)) {
> spin_unlock(&parent->d_lock);
> @@ -1026,14 +1023,11 @@ static bool shrink_lock_dentry(struct dentry *dentry)
> goto out;
> }
> spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED);
> - if (likely(!dentry->d_lockref.count)) {
> - rcu_read_unlock();
> + if (likely(!dentry->d_lockref.count))
> return true;
> - }
> spin_unlock(&parent->d_lock);
> out:
> spin_unlock(&inode->i_lock);
> - rcu_read_unlock();
> return false;
> }
>
> @@ -1044,8 +1038,10 @@ static void shrink_dentry_list(struct list_head *list)
>
> dentry = list_entry(list->prev, struct dentry, d_lru);
> spin_lock(&dentry->d_lock);
> + rcu_read_lock();
> if (!shrink_lock_dentry(dentry)) {
> bool can_free = false;
> + rcu_read_unlock();
> d_shrink_del(dentry);
> if (dentry->d_lockref.count < 0)
> can_free = dentry->d_flags & DCACHE_MAY_FREE;
> @@ -1054,6 +1050,7 @@ static void shrink_dentry_list(struct list_head *list)
> dentry_free(dentry);
> continue;
> }
> + rcu_read_unlock();
> d_shrink_del(dentry);
> parent = dentry->d_parent;
> __dentry_kill(dentry);
John Ogness
Re: [PATCH V2] ZBOOT: fix stack protector in compressed boot phase
On Tue, 13 Mar 2018 17:55:53 +0900,
Huacai Chen wrote:
>
> Hi, Yoshinori, Rich and SuperH developers,
>
> I'm not familiar with SuperH assembly, but SuperH has the same bug
> obviously. Could you please fix that?
>
> Huacai
>
Sorry. Previous mail bounced. It resend.
OK. Apply this fix.
SuperH can not handle long int directly.
diff --git a/arch/sh/boot/compressed/head_32.S
b/arch/sh/boot/compressed/head_32.S
index a3fdb053f351..7411fcb5764a 100644
--- a/arch/sh/boot/compressed/head_32.S
+++ b/arch/sh/boot/compressed/head_32.S
@@ -76,8 +76,8 @@ l1:
mov.l init_stack_addr, r0
mov.l @r0, r15
- mov.l __stack_chk_guard, r0
- mov #0x000a0dff, r1
+ mov.l __stack_chk_guard_ptr, r0
+ mov.l __stack_chk_val, r1
mov.l r1, @r0
/* Decompress the kernel */
@@ -109,6 +109,10 @@ kernel_start_addr:
#else
.long _text+PAGE_SIZE
#endif
+__stack_chk_guard_ptr:
+ .long __stack_chk_guard
+__stack_chk_val:
+ .long 0x000a0dff
.align 9
fake_headers_as_bzImage:
> On Mon, Mar 12, 2018 at 10:04 AM, Huacai Chen wrote:
> > Call __stack_chk_guard_setup() in decompress_kernel() is too late that
> > stack checking always fails for decompress_kernel() itself. So remove
> > __stack_chk_guard_setup() and initialize __stack_chk_guard before we
> > call decompress_kernel().
> >
> > Original code comes from ARM but also used for MIPS and SH, so fix them
> > together. If without this fix, compressed booting of these archs will
> > fail because stack checking is enabled by default (>=4.16).
> >
> > V2: Fix build on ARM.
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Huacai Chen
> > ---
> > arch/arm/boot/compressed/head.S| 4
> > arch/arm/boot/compressed/misc.c| 7 ---
> > arch/mips/boot/compressed/decompress.c | 7 ---
> > arch/mips/boot/compressed/head.S | 4
> > arch/sh/boot/compressed/head_32.S | 4
> > arch/sh/boot/compressed/head_64.S | 4
> > arch/sh/boot/compressed/misc.c | 7 ---
> > 7 files changed, 16 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/arm/boot/compressed/head.S
> > b/arch/arm/boot/compressed/head.S
> > index 45c8823..bae1fc6 100644
> > --- a/arch/arm/boot/compressed/head.S
> > +++ b/arch/arm/boot/compressed/head.S
> > @@ -547,6 +547,10 @@ not_relocated: mov r0, #0
> > bic r4, r4, #1
> > blnecache_on
> >
> > + ldr r0, =__stack_chk_guard
> > + ldr r1, =0x000a0dff
> > + str r1, [r0]
> > +
> > /*
> > * The C runtime environment should now be setup sufficiently.
> > * Set up some pointers, and start decompressing.
> > diff --git a/arch/arm/boot/compressed/misc.c
> > b/arch/arm/boot/compressed/misc.c
> > index 16a8a80..e518ef5 100644
> > --- a/arch/arm/boot/compressed/misc.c
> > +++ b/arch/arm/boot/compressed/misc.c
> > @@ -130,11 +130,6 @@ asmlinkage void __div0(void)
> >
> > unsigned long __stack_chk_guard;
> >
> > -void __stack_chk_guard_setup(void)
> > -{
> > - __stack_chk_guard = 0x000a0dff;
> > -}
> > -
> > void __stack_chk_fail(void)
> > {
> > error("stack-protector: Kernel stack is corrupted\n");
> > @@ -150,8 +145,6 @@ decompress_kernel(unsigned long output_start, unsigned
> > long free_mem_ptr_p,
> > {
> > int ret;
> >
> > - __stack_chk_guard_setup();
> > -
> > output_data = (unsigned char *)output_start;
> > free_mem_ptr= free_mem_ptr_p;
> > free_mem_end_ptr= free_mem_ptr_end_p;
> > diff --git a/arch/mips/boot/compressed/decompress.c
> > b/arch/mips/boot/compressed/decompress.c
> > index fdf99e9..5ba431c 100644
> > --- a/arch/mips/boot/compressed/decompress.c
> > +++ b/arch/mips/boot/compressed/decompress.c
> > @@ -78,11 +78,6 @@ void error(char *x)
> >
> > unsigned long __stack_chk_guard;
> >
> > -void __stack_chk_guard_setup(void)
> > -{
> > - __stack_chk_guard = 0x000a0dff;
> > -}
> > -
> > void __stack_chk_fail(void)
> > {
> > error("stack-protector: Kernel stack is corrupted\n");
> > @@ -92,8 +87,6 @@ void decompress_kernel(unsigned long boot_heap_start)
> > {
> > unsigned long zimage_start, zimage_size;
> >
> > - __stack_chk_guard_setup();
> > -
> > zimage_start = (unsigned long)(&__image_begin);
> > zimage_size = (unsigned long)(&__image_end) -
> > (unsigned long)(&__image_begin);
> > diff --git a/arch/mips/boot/compressed/head.S
> > b/arch/mips/boot/compressed/head.S
> > index 409cb48..00d0ee0 100644
> > --- a/arch/mips/boot/compressed/head.S
> > +++ b/arch/mips/boot/compressed/head.S
> > @@ -32,6 +32,10 @@ start:
> > bne a2, a0, 1b
> > addiu a0, a0, 4
> >
> > + PTR_LA a0, __stack_chk_guard
> > + PTR_LI a1, 0x000a0dff
> > + sw a1, 0(a0)
> > +
> > PTR_LA a0, (.heap) /* heap address */
[PATCH v10 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.
Signed-off-by: Sricharan R
[vivek: Cleanup pm runtime calls]
Signed-off-by: Vivek Gautam
Reviewed-by: Tomasz Figa
---
- No change since v9.
drivers/iommu/arm-smmu.c | 95
1 file changed, 87 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index d5873d545024..56a04ae80bf3 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -268,6 +268,20 @@ static struct arm_smmu_option_prop arm_smmu_options[] = {
{ 0, NULL},
};
+static inline int arm_smmu_rpm_get(struct arm_smmu_device *smmu)
+{
+ if (pm_runtime_enabled(smmu->dev))
+ return pm_runtime_get_sync(smmu->dev);
+
+ return 0;
+}
+
+static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
+{
+ if (pm_runtime_enabled(smmu->dev))
+ pm_runtime_put(smmu->dev);
+}
+
static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
{
return container_of(dom, struct arm_smmu_domain, domain);
@@ -913,11 +927,15 @@ static void arm_smmu_destroy_domain_context(struct
iommu_domain *domain)
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_device *smmu = smmu_domain->smmu;
struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
- int irq;
+ int ret, irq;
if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)
return;
+ ret = arm_smmu_rpm_get(smmu);
+ if (ret < 0)
+ return;
+
/*
* Disable the context bank and free the page tables before freeing
* it.
@@ -932,6 +950,8 @@ static void arm_smmu_destroy_domain_context(struct
iommu_domain *domain)
free_io_pgtable_ops(smmu_domain->pgtbl_ops);
__arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
+
+ arm_smmu_rpm_put(smmu);
}
static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
@@ -1213,10 +1233,15 @@ static int arm_smmu_attach_dev(struct iommu_domain
*domain, struct device *dev)
return -ENODEV;
smmu = fwspec_smmu(fwspec);
+
+ ret = arm_smmu_rpm_get(smmu);
+ if (ret < 0)
+ return ret;
+
/* Ensure that the domain is finalised */
ret = arm_smmu_init_domain_context(domain, smmu);
if (ret < 0)
- return ret;
+ goto rpm_put;
/*
* Sanity check the domain. We don't support domains across
@@ -1230,29 +1255,47 @@ static int arm_smmu_attach_dev(struct iommu_domain
*domain, struct device *dev)
}
/* Looks ok, so add the device to the domain */
- return arm_smmu_domain_add_master(smmu_domain, fwspec);
+ ret = arm_smmu_domain_add_master(smmu_domain, fwspec);
+
+rpm_put:
+ arm_smmu_rpm_put(smmu);
+ return ret;
}
static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova,
phys_addr_t paddr, size_t size, int prot)
{
struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops;
+ struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+ struct arm_smmu_device *smmu = smmu_domain->smmu;
+ int ret;
if (!ops)
return -ENODEV;
- return ops->map(ops, iova, paddr, size, prot);
+ arm_smmu_rpm_get(smmu);
+ ret = ops->map(ops, iova, paddr, size, prot);
+ arm_smmu_rpm_put(smmu);
+
+ return ret;
}
static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
size_t size)
{
struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops;
+ struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+ struct arm_smmu_device *smmu = smmu_domain->smmu;
+ size_t ret;
if (!ops)
return 0;
- return ops->unmap(ops, iova, size);
+ arm_smmu_rpm_get(smmu);
+ ret = ops->unmap(ops, iova, size);
+ arm_smmu_rpm_put(smmu);
+
+ return ret;
}
static void arm_smmu_iotlb_sync(struct iommu_domain *domain)
@@ -1407,14 +1450,22 @@ static int arm_smmu_add_device(struct device *dev)
while (i--)
cfg->smendx[i] = INVALID_SMENDX;
+ ret = arm_smmu_rpm_get(smmu);
+ if (ret < 0)
+ goto out_cfg_free;
+
ret = arm_smmu_master_alloc_smes(dev);
if (ret)
- goto out_cfg_free;
+ goto out_rpm_put;
iommu_device_link(&smmu->iommu, dev);
+ arm_smmu_rpm_put(smmu);
+
return 0;
+out_rpm_put:
+ arm_smmu_rpm_put(smmu);
out_cfg_free:
kfree(cfg);
out_free:
@@ -1427,7 +1478,7 @@ static void arm_smmu_remove_device(struct device *dev)
Re: [PATCH] usb: misc: supports Apple Carplay driver
On Wed, 2018-03-14 at 07:16 +0100, Greg Kroah-Hartman wrote: > On Wed, Mar 14, 2018 at 02:02:36PM +0800, Chunfeng Yun wrote: > > The driver is used to support Apple carplay feature by a debugfs > > interface which can force the driver to send a USB Vendor Request > > of "Apple Device to Host Mode Switch" to switch Apple Device > > into host mode. > > While I am all for crazy debugfs interfaces, I would _strongly_ suggest > not doing that here for the main API to the device. I know Android is > trying to prevent any new devices from even enabling debugfs, and as the > file system requires root permissions by default, you are forcing any > user of your new api to run as root, which is not a good idea either. > > Given that all you are doing here is a single usb control message, why > does this even need to be a kernel driver at all? Can't you do the same > thing from userspace with a simple libusb/usbfs program? Or even a > simple script? Ok, I'll abandon this patch, and do it by libusb Thanks a lot > > thanks, > > greg k-h
Re: [PATCH v2 02/11] media: vsp1: Remove packed attributes from aligned structures
On Tue, Mar 13, 2018 at 7:05 PM, Kieran Bingham
wrote:
> The use of the packed attribute can cause a performance penalty for
> all accesses to the struct members, as the compiler will assume that the
> structure has the potential to have an unaligned base.
>
> These structures are all correctly aligned and contain no holes, thus
> the attribute is redundant and negatively impacts performance, so we
> remove the attributes entirely.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
On 13.03.2018 15:30, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi
> ---
> .../bindings/display/bridge/thine,thc63lvd1024.txt | 63
> ++
> 1 file changed, 63 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..5b5afcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,63 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> streams
> +to parallel data outputs. The chip supports single/dual input/output modes,
> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> outputs.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024",
> +
> +Optional properties:
> +- vcc-supply: Power supply for TTL output and digital circuitry
> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> +- lvcc-supply: Power supply for LVDS inputs
> +- pvcc-supply: Power supply for PLL circuitry
I wonder if it wouldn't be better to make them required (at least VCC) -
it is closer to reality.
> +- pwnd-gpios: Power down GPIO signal. Active low.
As I said before, specs[1] says about "/PDWN" pin. Is it your typo, or
different docs?
Moreover there are already bindings for THC63LVDM83D with the same
dichotomy [2].
Out of curiosity I have googled for "pwnd pin" and it looks like some
vendors use this form.
For me both forms are quite misleading: power down signal, active low,
why they couldn't call it just 'enable, active high'.
[1]: http://www.thine.co.jp/files/topics/179_ext_12_0.pdf
[2]:
https://elixir.bootlin.com/linux/v4.16-rc5/source/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
> +- oe-gpios: Output enable GPIO signal. Active high.
> +
> +The THC63LVD1024 video port connections are modeled according
> +to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
> +
> +Required video port nodes:
> +- Port@0: First LVDS input port
> +- Port@2: First digital CMOS/TTL parallel output
> +
> +Optional video port nodes:
> +- Port@1: Second LVDS input port
> +- Port@3: Second digital CMOS/TTL parallel output
> +
> +Example:
> +
> +
> + thc63lvd1024: lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> +
> + vcc-supply = <®_lvds_vcc>;
> + lvcc-supply = <®_lvds_lvcc>;
> +
> + pwdn-gpio = <&gpio4 15 GPIO_ACTIVE_LOW>;
And here another variation :), should be pdwn-gpios.
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lvds_dec_in_0: endpoint {
> + remote-endpoint = <&lvds_out>;
> + };
> + };
> +
> + port@2{
> + reg = <2>;
> +
> + lvds_dec_out_2: endpoint {
> + remote-endpoint = <&adv7511_in>;
> + };
> +
> + };
> +
> + };
> + };
Re: [PATCH] firmware: add a function to load optional firmware v2
On 3/13/2018 5:46 PM, Kalle Valo wrote:
"Luis R. Rodriguez" writes:
On Tue, Mar 13, 2018 at 03:16:34PM +0200, Kalle Valo wrote:
"Luis R. Rodriguez" writes:
+/**
+ * request_firmware_optional: - request for an optional fw module
+ * @firmware_p: pointer to firmware image
+ * @name: name of firmware file
+ * @device: device for which firmware is being loaded
+ *
+ * This function is similar in behaviour to request_firmware(), except
+ * it doesn't produce warning messages when the file is not found.
+ **/
+int
+request_firmware_optional(const struct firmware **firmware_p, const char *name,
+ struct device *device)
+{
+ int ret;
+
+ /* Need to pin this module until return */
+ __module_get(THIS_MODULE);
+ ret = _request_firmware(firmware_p, name, device, NULL, 0,
+ FW_OPT_UEVENT | FW_OPT_NO_WARN );
+ module_put(THIS_MODULE);
+ return ret;
+}
+EXPORT_SYMBOL(request_firmware_optional);
New exported symbols for the firmware API should be EXPORT_SYMBOL_GPL().
To me the word optional feels weird to me. For example, in ath10k I
suspect we would be only calling request_firmware_optional() with all
firmware and not request_firmware() at all.
How about request_firmware_nowarn()? That would even match the
documentation above.
_nowarn() works with me. Do you at least want the return value to give
an error value if no file was found? This way the driver can decide
when to issue an error if it wants to.
Yes, it would be very good to return the error value to ath10k. That way
we can give a proper error message to the user if we can't find a
suitable firmware image.
I fully agree with the _nowarn() and returning an error. However, the
firmware_p parameter (btw. do we really want the _p postfix?) is an
output parameter which will be null in case of an error so do you really
need a specific error code for the proper error message.
Regards,
Arend
[linux-next][bisected c7c133f3][gcc 4.8.5] build fail with error: first argument to ‘__builtin_choose_expr’ not a constant
Greetings, Today's next kernel fails to build with gcc 4.8.5 on powerpc machine. ./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’: ./include/linux/kernel.h:855:2: error: first argument to ‘__builtin_choose_expr’ not a constant __builtin_choose_expr(__builtin_constant_p(x) && \ ^ ./include/linux/kernel.h:867:19: note: in expansion of macro ‘__max’ #define max(x, y) __max(typeof(x), typeof(y), x, y) Machine Type: Power8 Baremetal gcc: 4.8.5 Builds fine when below patch is reverted c7c133f3 kernel.h: skip single-eval logic on literals in min()/max() -- Regard's Abdul Haleem IBM Linux Technology Centre
Re: [PATCH] media: staging/imx: fill vb2_v4l2_buffer sequence entry
We need a changelog. How does this affect user space? What bug does
this fix?
On Tue, Mar 13, 2018 at 09:00:54PM +0100, Peter Seiderer wrote:
> Signed-off-by: Peter Seiderer
> ---
> drivers/staging/media/imx/imx-media-csi.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/staging/media/imx/imx-media-csi.c
> b/drivers/staging/media/imx/imx-media-csi.c
> index 5a195f80a24d..3a6a645b9dce 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -111,6 +111,7 @@ struct csi_priv {
> struct v4l2_ctrl_handler ctrl_hdlr;
>
> int stream_count; /* streaming counter */
> + __u32 frame_sequence; /* frame sequence counter */
Use u32 because this is not a user space header.
> bool last_eof; /* waiting for last EOF at stream off */
> bool nfb4eof;/* NFB4EOF encountered during streaming */
> struct completion last_eof_comp;
regards,
dan carpenter
Re: [PATCH] hv_netvsc: Make sure out channel is fully opened on send
On Tue, Mar 13, 2018 at 08:06:50PM +0100, Mohammed Gamal wrote:
> @@ -791,6 +791,7 @@ static inline int netvsc_send_pkt(
>
> VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> }
>
> + ring_avail = hv_ringbuf_avail_percent(&out_channel->outbound);
> if (ret == 0) {
> atomic_inc_return(&nvchan->queue_sends);
>
Could you move the assignment inside the "ret == 0" path closer to where
it's used?
regards,
dan carpenter
Re: [PATCH] perf stat: Add support for s390 transaction counters
On 03/13/2018 04:23 AM, Andi Kleen wrote:
> Thomas Richter writes:
>
>> Right now there is only hard coded support for x86.
>
> That's not true. There is support for generic transaction events in perf.
>
> As far as I can tell your events would map 1:1 to the generic tx-* events.
>
> -Andi
>
I might be wrong, but when I look at function add_default_attributes()
in file buildin-stat.c the string variables transaction_attrs
and transaction_limited_attrs are used when flag T is specified on command line:
/* Default events used for perf stat -T */
static const char *transaction_attrs = {
"task-clock,"
"{"
"instructions,"
"cycles,"
"cpu/cycles-t/,"
"cpu/tx-start/,"
"cpu/el-start/,"
"cpu/cycles-ct/"
"}"
};
These PMU events show up on my x86 notebook but no on the s390.
That's why I came to this conclusion. I have not tried other architectures.
--
Thomas Richter, Dept 3303, IBM LTC Boeblingen Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB
243294
Re: [PATCH v3 2/2] kbuild: Don't mess with the .cache.mk when root
On Wed, Mar 14, 2018 at 08:23:16AM +0100, Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > If Ingo wants to build as root, maybe we could even make him set some > > environment flag to avoid errors. > > I only build as root infrequently, but I think PeterZ does it more frequently? Yeah, a bunch of my testboxes don't even have a regular user account.
Re: [PATCH] PCI/MSI: Don't set up INTx if MSI or MSI-X is enabled
Should this logic go into a little helper so that everyone is kept in sync?
[PATCH] ARM: configs: add OXNAS v6 defconfig
This patchs adds the minimal defconfig for the OXNAS ARMv6 SoCs including the OX820 SoC and needed minimal configurations. Signed-off-by: Neil Armstrong --- Hi Arnds, Can you take this directly ? It will avoid send a pull request for a single patch.. This defconfig will help adding the ox820 to a kernelci lab for testing. Thanks, Neil arch/arm/configs/oxnas_v6_defconfig | 93 + 1 file changed, 93 insertions(+) create mode 100644 arch/arm/configs/oxnas_v6_defconfig diff --git a/arch/arm/configs/oxnas_v6_defconfig b/arch/arm/configs/oxnas_v6_defconfig new file mode 100644 index 000..f6ba32c --- /dev/null +++ b/arch/arm/configs/oxnas_v6_defconfig @@ -0,0 +1,93 @@ +CONFIG_SYSVIPC=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_CGROUPS=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_EMBEDDED=y +CONFIG_PERF_EVENTS=y +CONFIG_STRICT_KERNEL_RWX=y +CONFIG_STRICT_MODULE_RWX=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_PARTITION_ADVANCED=y +CONFIG_CMDLINE_PARTITION=y +CONFIG_ARCH_MULTI_V6=y +CONFIG_ARCH_OXNAS=y +CONFIG_MACH_OX820=y +CONFIG_SMP=y +CONFIG_NR_CPUS=16 +CONFIG_CMA=y +CONFIG_FORCE_MAX_ZONEORDER=12 +CONFIG_SECCOMP=y +CONFIG_ARM_APPENDED_DTB=y +CONFIG_ARM_ATAG_DTB_COMPAT=y +CONFIG_KEXEC=y +CONFIG_EFI=y +CONFIG_CPU_IDLE=y +CONFIG_ARM_CPUIDLE=y +CONFIG_VFP=y +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y +CONFIG_IPV6_ROUTER_PREF=y +CONFIG_IPV6_OPTIMISTIC_DAD=y +CONFIG_INET6_AH=m +CONFIG_INET6_ESP=m +CONFIG_INET6_IPCOMP=m +CONFIG_IPV6_MIP6=m +CONFIG_IPV6_TUNNEL=m +CONFIG_IPV6_MULTIPLE_TABLES=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_DMA_CMA=y +CONFIG_CMA_SIZE_MBYTES=64 +CONFIG_SIMPLE_PM_BUS=y +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_OXNAS=y +CONFIG_MTD_UBI=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_SIZE=65536 +CONFIG_NETDEVICES=y +CONFIG_STMMAC_ETH=y +CONFIG_REALTEK_PHY=y +CONFIG_INPUT_EVDEV=y +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_OF_PLATFORM=y +CONFIG_GPIO_GENERIC_PLATFORM=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_CLASS_FLASH=m +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_ONESHOT=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_LEDS_TRIGGER_CPU=y +CONFIG_LEDS_TRIGGER_GPIO=y +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y +CONFIG_ARM_TIMER_SP804=y +CONFIG_EXT4_FS=y +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_TMPFS=y +CONFIG_TMPFS_POSIX_ACL=y +CONFIG_UBIFS_FS=y +CONFIG_PSTORE=y +CONFIG_PSTORE_CONSOLE=y +CONFIG_PSTORE_PMSG=y +CONFIG_PSTORE_RAM=y +CONFIG_NLS_CODEPAGE_437=y +CONFIG_NLS_ISO8859_1=y +CONFIG_NLS_UTF8=y +CONFIG_PRINTK_TIME=y +CONFIG_MAGIC_SYSRQ=y -- 2.7.4
Re: [PATCH] pktgen: Fix memory leak in pktgen_if_write
On Wed, Mar 14, 2018 at 9:07 AM, Gustavo A. R. Silva
wrote:
> _buf_ is an array and the one that must be freed is _tp_ instead.
>
> Fixes: a870a02cc963 ("pktgen: use dynamic allocation for debug print buffer")
> Reported-by: Wang Jian
> Signed-off-by: Gustavo A. R. Silva
Acked-by: Arnd Bergmann
Thanks for fixing up my mistake so quickly, and thanks to Wang for the report
I was about to send the same patch, but you got there first.
Re: [PATCH] x86, memremap: fix altmap accounting at free
Looks good, thanks for catchign this! Reviewed-by: Christoph Hellwig
Re: [linux-next][bisected c7c133f3][gcc 4.8.5] build fail with error: first argument to ‘__builtin_choose_expr’ not a constant
Hi Abdul, On Wed, 14 Mar 2018 13:59:54 +0530 Abdul Haleem wrote: > > Today's next kernel fails to build with gcc 4.8.5 on powerpc machine. Thanks for the report. Just for the future, please include the next- tag when making reports about linux-next. > ./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’: > ./include/linux/kernel.h:855:2: error: first argument to > ‘__builtin_choose_expr’ not a constant > __builtin_choose_expr(__builtin_constant_p(x) && \ > ^ > ./include/linux/kernel.h:867:19: note: in expansion of macro ‘__max’ > #define max(x, y) __max(typeof(x), typeof(y), x, y) > > Machine Type: Power8 Baremetal > gcc: 4.8.5 > > > Builds fine when below patch is reverted > c7c133f3 kernel.h: skip single-eval logic on literals in min()/max() Those patches have been removed from today's linux-next (next-20180314). -- Cheers, Stephen Rothwell pgp7yN_e1awGg.pgp Description: OpenPGP digital signature
Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
On 13.03.2018 15:30, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output decoder.
IMO converter suits here better, but it is just suggestion.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/bridge/Kconfig| 7 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/thc63lvd1024.c | 241
> ++
> 3 files changed, 249 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3b99d5a..facf6bd 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -92,6 +92,13 @@ config DRM_SII9234
> It is an I2C driver, that detects connection of MHL bridge
> and starts encapsulation of HDMI signal.
>
> +config DRM_THINE_THC63LVD1024
> + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> + depends on OF
> + select DRM_PANEL_BRIDGE
You don't use PANEL_BRIDGE, it should be possible to drop the select.
> + ---help---
> + Thine THC63LVD1024 LVDS decoder bridge driver.
Decoder to what?
Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
converter or bridge.
> +
> config DRM_TOSHIBA_TC358767
> tristate "Toshiba TC358767 eDP bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 373eb28..fd90b16 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> obj-$(CONFIG_DRM_SII902X) += sii902x.o
> obj-$(CONFIG_DRM_SII9234) += sii9234.o
> +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> b/drivers/gpu/drm/bridge/thc63lvd1024.c
> new file mode 100644
> index 000..4b059c0
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -0,0 +1,241 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> + *
> + * Copyright (C) 2018 Jacopo Mondi
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const char * const thc63_reg_names[] = {
> + "vcc", "lvcc", "pvcc", "cvcc", };
> +
> +struct thc63_dev {
> + struct device *dev;
> +
> + struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
> +
> + struct gpio_desc *pwdn;
> + struct gpio_desc *oe;
> +
> + struct drm_bridge bridge;
> + struct drm_bridge *next;
> +};
> +
> +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct thc63_dev, bridge);
> +}
> +
> +static int thc63_attach(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> +
> + return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> +}
> +
> +static void thc63_enable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + unsigned int i;
> + int ret;
> +
> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> + vcc = thc63->vccs[i];
> + if (vcc) {
> + ret = regulator_enable(vcc);
> + if (ret)
> + goto error_vcc_enable;
> + }
> + }
> +
> + if (thc63->pwdn)
> + gpiod_set_value(thc63->pwdn, 0);
> +
> + if (thc63->oe)
> + gpiod_set_value(thc63->oe, 1);
> +
> + return;
> +
> +error_vcc_enable:
> + dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
> +}
> +
> +static void thc63_disable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + unsigned int i;
> + int ret;
> +
> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> + vcc = thc63->vccs[i];
> + if (vcc) {
> + ret = regulator_disable(vcc);
> + if (ret)
> + goto error_vcc_disable;
I think in disable path you can report an error and continue - should be
safer.
> + }
> + }
> +
> + if (thc63->pwdn)
> + gpiod_set_value(thc63->pwdn, 1);
> +
> + if (thc63->oe)
> + gpiod_set_value(thc63->oe, 0);
Usually disable uses reverse order. Ie first disable oe, then, pwdn,
then regulators, also in reverse order.
Looks more reasonable.
> +
> + return;
> +
> +error_vcc_disable:
> + dev_err(thc63->dev, "Failed to disable regulator %u\n", i);
> +}
> +
> +struct drm_bridge_funcs thc63_bridge_func = {
> + .attach = thc63_attach,
> + .enable = thc63_enable,
> + .disable = th
Re: [PATCH] slab, slub: remove size disparity on debug kernel
On Tue, Mar 13, 2018 at 10:36:52AM -0700, Shakeel Butt wrote:
> On Tue, Mar 13, 2018 at 10:19 AM, Christopher Lameter wrote:
> > On Tue, 13 Mar 2018, Shakeel Butt wrote:
> >
> >> However for SLUB in debug kernel, the sizes were same. On further
> >> inspection it is found that SLUB always use kmem_cache.object_size to
> >> measure the kmem_cache.size while SLAB use the given kmem_cache.size. In
> >> the debug kernel the slab's size can be larger than its object_size.
> >> Thus in the creation of non-root slab, the SLAB uses the root's size as
> >> base to calculate the non-root slab's size and thus non-root slab's size
> >> can be larger than the root slab's size. For SLUB, the non-root slab's
> >> size is measured based on the root's object_size and thus the size will
> >> remain same for root and non-root slab.
> >
> > Note that the object_size and size may differ for SLUB based on kernel
> > parameters and slab configuration. For SLAB these are compilation options.
> >
>
> Thanks for the explanation.
>
> >> @@ -379,7 +379,7 @@ struct kmem_cache *find_mergeable(unsigned int size,
> >> unsigned int align,
> >> }
> >>
> >> static struct kmem_cache *create_cache(const char *name,
> >> - unsigned int object_size, unsigned int size, unsigned int
> >> align,
> >> + unsigned int object_size, unsigned int align,
> >> slab_flags_t flags, unsigned int useroffset,
> >
> > Why was both the size and object_size passed during cache creation in the
> > first place? From the flags etc the slab logic should be able to compute
> > the actual bytes required for each object and its metadata.
> >
>
> +Vladimir
>
> I think it was introduced by 794b1248be4e7 ("memcg, slab: separate
> memcg vs root cache creation paths") but I could not find out the
> reason.
This was a mistake - I missed that __kmem_cache_create() overwrites
kmem_cache->size. Thanks for fixing this.
[PATCH] hw_breakpoint: Fix build for disabled CONFIG_HAVE_HW_BREAKPOINT
On Tue, Mar 13, 2018 at 10:50:45AM +0100, Jiri Olsa wrote:
> On Tue, Mar 13, 2018 at 10:28:01AM +0100, Jiri Olsa wrote:
> > On Tue, Mar 13, 2018 at 07:37:47AM +0100, Ingo Molnar wrote:
> > >
> > > * Jiri Olsa wrote:
> > >
> > > > Jiri Olsa (7):
> > > > hw_breakpoint: Pass bp_type directly as find_slot_idx argument
> > > > hw_breakpoint: Pass bp_type argument to
> > > > __reserve_bp_slot|__release_bp_slot
> > > > hw_breakpoint: Add modify_bp_slot function
> > > > hw_breakpoint: Factor out __modify_user_hw_breakpoint function
> > > > hw_breakpoint: Add perf_event_attr fields check in
> > > > __modify_user_hw_breakpoint
> > > > perf/core: Move perf_event_attr::sample_max_stack into
> > > > perf_copy_attr
> > > > perf tests: Add breakpoint accounting/modify test
> > > >
> > > > Milind Chabbi (1):
> > > > perf/core: fast breakpoint modification via
> > > > _IOC_MODIFY_ATTRIBUTES.
> > > >
> > > > include/linux/hw_breakpoint.h | 7 +
> > > > include/uapi/linux/perf_event.h | 23 ---
> > > > kernel/events/core.c | 54
> > > > --
> > > > kernel/events/hw_breakpoint.c | 115
> > > > +++-
> > > > tools/include/uapi/linux/perf_event.h | 23 ---
> > > > tools/perf/tests/Build| 1 +
> > > > tools/perf/tests/bp_account.c | 195
> > > > +++
> > > > tools/perf/tests/builtin-test.c | 4 +++
> > > > tools/perf/tests/tests.h | 1 +
> > > > 9 files changed, 365 insertions(+), 58 deletions(-)
> > > > create mode 100644 tools/perf/tests/bp_account.c
> > >
> > > Note, there's a new PARISC build failure:
> > >
> > > home/mingo/tip/kernel/events/core.c:2858:2: error: implicit declaration
> > > of function 'modify_user_hw_breakpoint_check'
> > > [-Werror=implicit-function-declaration]
> > >err = modify_user_hw_breakpoint_check(bp, attr, true);
> > >
> > > will only be able to push it out to -next once this is fixed.
> >
> > ok, checking on that
>
> should be this one.. I'm checking on s390 which is also
> without breakpoint support, I'll send full patch after
and here it is
thanks,
jirka
---
We're missing stub for modify_user_hw_breakpoint_check function
when option CONFIG_HAVE_HW_BREAKPOINT is disabled. It was mixed
up in recent changes.
Fixes: f30b09b7f8ae ("perf/core: Implement fast breakpoint modification via
_IOC_MODIFY_ATTRIBUTES")
Signed-off-by: Jiri Olsa
---
include/linux/hw_breakpoint.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/hw_breakpoint.h b/include/linux/hw_breakpoint.h
index abeba094f080..6058c3844a76 100644
--- a/include/linux/hw_breakpoint.h
+++ b/include/linux/hw_breakpoint.h
@@ -101,8 +101,8 @@ static inline int
modify_user_hw_breakpoint(struct perf_event *bp,
struct perf_event_attr *attr) { return -ENOSYS; }
static inline int
-__modify_user_hw_breakpoint(struct perf_event *bp,
- struct perf_event_attr *attr) { return -ENOSYS; }
+modify_user_hw_breakpoint_check(struct perf_event *bp, struct perf_event_attr
*attr,
+ bool check) { return -ENOSYS; }
static inline struct perf_event *
register_wide_hw_breakpoint_cpu(struct perf_event_attr *attr,
--
2.13.6
[tip:x86/pti] selftests/x86/entry_from_vm86: Exit with 1 if we fail
Commit-ID: 327d53d005ca47b10eae940616ed11c569f75a9b Gitweb: https://git.kernel.org/tip/327d53d005ca47b10eae940616ed11c569f75a9b Author: Andy Lutomirski AuthorDate: Tue, 13 Mar 2018 22:03:10 -0700 Committer: Ingo Molnar CommitDate: Wed, 14 Mar 2018 09:21:01 +0100 selftests/x86/entry_from_vm86: Exit with 1 if we fail Fix a logic error that caused the test to exit with 0 even if test cases failed. Signed-off-by: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stas Sergeev Cc: Thomas Gleixner Cc: bartolde...@gmail.com Cc: sta...@vger.kernel.org Link: http://lkml.kernel.org/r/b1cc37144038958a469c8f70a5f47a6a5638636a.1521003603.git.l...@kernel.org Signed-off-by: Ingo Molnar --- tools/testing/selftests/x86/entry_from_vm86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/x86/entry_from_vm86.c b/tools/testing/selftests/x86/entry_from_vm86.c index 361466a2eaef..6e85f0d0498d 100644 --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -318,7 +318,7 @@ int main(void) clearhandler(SIGSEGV); /* Make sure nothing explodes if we fork. */ - if (fork() > 0) + if (fork() == 0) return 0; return (nerrs == 0 ? 0 : 1);
[tip:x86/pti] selftests/x86/entry_from_vm86: Add test cases for POPF
Commit-ID: 78393fdde2a456cafa414b171c90f26a3df98b20
Gitweb: https://git.kernel.org/tip/78393fdde2a456cafa414b171c90f26a3df98b20
Author: Andy Lutomirski
AuthorDate: Tue, 13 Mar 2018 22:03:11 -0700
Committer: Ingo Molnar
CommitDate: Wed, 14 Mar 2018 09:21:01 +0100
selftests/x86/entry_from_vm86: Add test cases for POPF
POPF is currently broken -- add tests to catch the error. This
results in:
[RUN]POPF with VIP set and IF clear from vm86 mode
[INFO] Exited vm86 mode due to STI
[FAIL] Incorrect return reason (started at eip = 0xd, ended at eip =
0xf)
because POPF currently fails to check IF before reporting a pending
interrupt.
This patch also makes the FAIL message a bit more informative.
Reported-by: Bart Oldeman
Signed-off-by: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stas Sergeev
Cc: Thomas Gleixner
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/a16270b5cfe7832d6d00c479d0f871066cbdb52b.1521003603.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
tools/testing/selftests/x86/entry_from_vm86.c | 30 ---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/x86/entry_from_vm86.c
b/tools/testing/selftests/x86/entry_from_vm86.c
index 6e85f0d0498d..ade443a88421 100644
--- a/tools/testing/selftests/x86/entry_from_vm86.c
+++ b/tools/testing/selftests/x86/entry_from_vm86.c
@@ -95,6 +95,10 @@ asm (
"int3\n\t"
"vmcode_int80:\n\t"
"int $0x80\n\t"
+ "vmcode_popf_hlt:\n\t"
+ "push %ax\n\t"
+ "popf\n\t"
+ "hlt\n\t"
"vmcode_umip:\n\t"
/* addressing via displacements */
"smsw (2052)\n\t"
@@ -124,8 +128,8 @@ asm (
extern unsigned char vmcode[], end_vmcode[];
extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[],
- vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[],
- vmcode_umip_str[], vmcode_umip_sldt[];
+ vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_popf_hlt[],
+ vmcode_umip[], vmcode_umip_str[], vmcode_umip_sldt[];
/* Returns false if the test was skipped. */
static bool do_test(struct vm86plus_struct *v86, unsigned long eip,
@@ -175,7 +179,7 @@ static bool do_test(struct vm86plus_struct *v86, unsigned
long eip,
(VM86_TYPE(ret) == rettype && VM86_ARG(ret) == retarg)) {
printf("[OK]\tReturned correctly\n");
} else {
- printf("[FAIL]\tIncorrect return reason\n");
+ printf("[FAIL]\tIncorrect return reason (started at eip =
0x%lx, ended at eip = 0x%lx)\n", eip, v86->regs.eip);
nerrs++;
}
@@ -264,6 +268,9 @@ int main(void)
v86.regs.ds = load_addr / 16;
v86.regs.es = load_addr / 16;
+ /* Use the end of the page as our stack. */
+ v86.regs.esp = 4096;
+
assert((v86.regs.cs & 3) == 0); /* Looks like RPL = 0 */
/* #BR -- should deliver SIG??? */
@@ -295,6 +302,23 @@ int main(void)
v86.regs.eflags &= ~X86_EFLAGS_IF;
do_test(&v86, vmcode_sti - vmcode, VM86_STI, 0, "STI with VIP set");
+ /* POPF with VIP set but IF clear: should not trap */
+ v86.regs.eflags = X86_EFLAGS_VIP;
+ v86.regs.eax = 0;
+ do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP
set and IF clear");
+
+ /* POPF with VIP set and IF set: should trap */
+ v86.regs.eflags = X86_EFLAGS_VIP;
+ v86.regs.eax = X86_EFLAGS_IF;
+ do_test(&v86, vmcode_popf_hlt - vmcode, VM86_STI, 0, "POPF with VIP and
IF set");
+
+ /* POPF with VIP clear and IF set: should not trap */
+ v86.regs.eflags = 0;
+ v86.regs.eax = X86_EFLAGS_IF;
+ do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP
clear and IF set");
+
+ v86.regs.eflags = 0;
+
/* INT3 -- should cause #BP */
do_test(&v86, vmcode_int3 - vmcode, VM86_TRAP, 3, "INT3");
[PATCH v1 0/4] Fix issues with huge mapping in ioremap
Note: I was working on these patches for quite sometime
and realized that Toshi Kani has shared some patches
addressing the same isssue with subject
"[PATCH 0/2] fix memory leak / panic in ioremap huge pages".
I've taken slightly different approach here, so sending
to the list, finally.
This patch series attempts to fix the issue described in
this discussion: https://lkml.org/lkml/2017/12/23/3
In summary, CONFIG_HAVE_ARCH_HUGE_VMAP has 2 issues
observed on ARM64
1. Stale TLB entries
2. Page table leaks
Will Deacon has by-passed huge mapping for ARM64
until these issues are fixed properly.
I've tested these patches on ARM64 based SDM845
with 4.9 kernel. Hanjun Guo
shared test-case to reproduce this issue in
https://patchwork.kernel.org/patch/10134581/
However, I had no luck reproducing this issue with
exactly this test. I added some more code to reproduce
and here is my test which surfaces this issue in some
five hours of testing.
Test Code:
#define pr_fmt(fmt) "IOREMAP_TEST: " fmt
#include
#include
#include
#include
#include
#include
#include
#include
static int io_remap_test(void *arg)
{
phys_addr_t phy_addr_1 = 0x9800;
unsigned long block_size = 0x20;
unsigned long total_size = 0x40;
unsigned long va_addr_3;
unsigned long va_addr_4;
struct vm_struct *area;
/*
* run this test for 10 hours
*/
u32 times_ms = 10 * 60 * 60 * 1000;
unsigned long timeout = jiffies + msecs_to_jiffies(times_ms);
int rand_type;
int rand_value;
u32 mem_size;
int i;
area = get_vm_area(total_size, VM_IOREMAP);
va_addr_3 = (unsigned long)area->addr;
va_addr_4 = va_addr_3 + block_size;
pr_err("Virtual area %lx -- %lx\n", va_addr_3, va_addr_3 + total_size);
ioremap_page_range(va_addr_3, va_addr_3 + block_size, phy_addr_1,
__pgprot(PROT_DEVICE_nGnRE));
pr_err("My tests will run now 2\n");
do {
get_random_bytes(&rand_value, sizeof(u32));
rand_type = rand_value % 6;
switch (rand_type) {
case 0:
mem_size = 0x1000;
break;
case 1:
mem_size = 0x8000;
break;
case 2:
mem_size = 0x20;
break;
case 3:
mem_size = 0x3;
break;
case 4:
mem_size = 0x1;
break;
case 5:
mem_size = 0x4;
break;
default:
mem_size = 0x4000;
break;
}
/*
* Prompt TLB to speculatively pre-fetch
*/
readq(va_addr_3 + block_size - 0x20);
readq(va_addr_3 + block_size - 0x18);
readq(va_addr_3 + block_size - 0x10);
readq(va_addr_3 + block_size - 0x8);
ioremap_page_range(va_addr_4, va_addr_4 + mem_size, phy_addr_1,
__pgprot(PROT_DEVICE_nGnRE));
if (mem_size >= 0x20 && !(rand_value%1)) {
schedule();
pr_err("possible error case\n");
}
/*
* Make CPU aware about our access pattern
* Also, these accesses should lead to crash
*/
for (i = 0; i < 5; i++ ) {
readq(va_addr_3 + block_size - 0x20);
readq(va_addr_3 + block_size - 0x18);
readq(va_addr_3 + block_size - 0x10);
readq(va_addr_3 + block_size - 0x8);
// Crash is expected here
readq(va_addr_4);
readq(va_addr_4 + 0x8);
readq(va_addr_4 + 0x10);
readq(va_addr_4 + 0x18);
readq(va_addr_4 + 0x20);
}
unmap_kernel_range(va_addr_4, mem_size);
} while (time_before(jiffies, timeout));
pr_err("my tests ended now\n");
return 0;
}
static int __init ioremap_testing_init(void)
{
struct task_struct *t;
pr_err("my tests will run now 1\n");
t = kthread_create(&io_remap_test, NULL, "ioremap-testing");
/*
* Do this so that we can run this thread on GOLD cores
*/
kthread_bind(t, 6);
wake_up_process(t);
return 0;
}
late_initcall(ioremap_testing_init);
Chintan Pandya (4):
asm/tlbflush: Add flush_tlb_pgtable() for ARM64
ioremap: Invalidate TLB after huge mappings
arm64: Fix the page leak in pud/pmd_set_huge
Revert "arm64: Enforce BBM for huge IO/VMAP mappings"
arch/arm64/include/asm/tlbflush.h | 5 +
arch/arm64/mm/mmu.c
[PATCH v1 1/4] asm/tlbflush: Add flush_tlb_pgtable() for ARM64
ARM64 MMU implements invalidation of TLB for
intermediate page tables for perticular VA. This
may or may not be available for other arch. So,
provide this API hook only for ARM64, for now.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/tlbflush.h | 5 +
include/asm-generic/tlb.h | 6 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
index 9e82dd7..5f656f0 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -209,6 +209,11 @@ static inline void __flush_tlb_pgtable(struct mm_struct
*mm,
dsb(ish);
}
+static inline void flush_tlb_pgtable(struct mm_struct *mm,
+ unsigned long uaddr)
+{
+ __flush_tlb_pgtable(mm, uaddr);
+}
#endif
#endif
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index faddde4..7832c0a 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -295,4 +295,10 @@ static inline void
tlb_remove_check_page_size_change(struct mmu_gather *tlb,
#define tlb_migrate_finish(mm) do {} while (0)
+#ifndef CONFIG_ARM64
+static inline void flush_tlb_pgtable(struct mm_struct *mm,
+ unsigned long uaddr)
+{
+}
+#endif
#endif /* _ASM_GENERIC__TLB_H */
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
[tip:x86/pti] x86/vm86/32: Fix POPF emulation
Commit-ID: b5069782453459f6ec1fdeb495d9901a4545fcb5
Gitweb: https://git.kernel.org/tip/b5069782453459f6ec1fdeb495d9901a4545fcb5
Author: Andy Lutomirski
AuthorDate: Tue, 13 Mar 2018 22:03:12 -0700
Committer: Ingo Molnar
CommitDate: Wed, 14 Mar 2018 09:21:01 +0100
x86/vm86/32: Fix POPF emulation
POPF would trap if VIP was set regardless of whether IF was set. Fix it.
Suggested-by: Stas Sergeev
Reported-by: Bart Oldeman
Signed-off-by: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: sta...@vger.kernel.org
Fixes: 5ed92a8ab71f ("x86/vm86: Use the normal pt_regs area for vm86")
Link:
http://lkml.kernel.org/r/ce95f40556e7b2178b6bc06ee9557827ff94bd28.1521003603.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/vm86_32.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 5edb27f1a2c4..9d0b5af7db91 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -727,7 +727,8 @@ void handle_vm86_fault(struct kernel_vm86_regs *regs, long
error_code)
return;
check_vip:
- if (VEFLAGS & X86_EFLAGS_VIP) {
+ if ((VEFLAGS & (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) ==
+ (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) {
save_v86_state(regs, VM86_STI);
return;
}
Re: [PATCH v3 3/3] Bluetooth: hci_qca: Add serdev support
On 13/03/2018 21:57, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 8:38 PM, Thierry Escande wrote: Add support for Qualcomm serial slave devices. Probe the serial device, retrieve its maximum speed and register a new hci uart device. config BT_HCIUART_QCA bool "Qualcomm Atheros protocol support" - depends on BT_HCIUART + depends on BT_HCIUART_SERDEV Consider to address Loic's comments. +#include This is still here. Why? I forgot that one. This was for struct of_device_id. I'll replace it with mod_devicetable.h. Regards, Thierry
Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend
>>> On 26.02.18 at 15:08, wrote:
> @@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled)
>
> static void xen_vcpu_notify_restore(void *data)
> {
> + if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL))
> + wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl));
> +
> /* Boot processor notified via generic timekeeping_resume() */
> if (smp_processor_id() == 0)
> return;
> @@ -44,7 +52,15 @@ static void xen_vcpu_notify_restore(void *data)
>
> static void xen_vcpu_notify_suspend(void *data)
> {
> + u64 tmp;
> +
> tick_suspend_local();
> +
> + if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) {
> + rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
> + this_cpu_write(spec_ctrl, tmp);
> + wrmsrl(MSR_IA32_SPEC_CTRL, 0);
> + }
> }
While investigating ways how to do something similar on our old,
non-pvops kernels I've started wondering if this solution is actually
correct in all cases. Of course discussing this is complicated by the
fact that the change there might be a conflict with hasn't landed
in Linus'es tree yet (see e.g.
https://patchwork.kernel.org/patch/10153843/ for an upstream
submission; I haven't been able to find any discussion on that
patch or why it isn't upstream yet), but we have it in our various
branches. The potential problem I'm seeing is with the clearing
and re-setting of SPEC_CTRL around CPUs going idle. While the
active CPU could have preemption disabled (if that isn't the case
already), the passive CPUs are - afaict - neither under full control
of drivers/xen/manage.c:do_suspend() nor excluded yet from
any further scheduling activity. Hence with code like this (taken
from one of our branches)
static void mwait_idle(void)
{
if (!current_set_polling_and_test()) {
trace_cpu_idle_rcuidle(1, smp_processor_id());
if (this_cpu_has(X86_BUG_CLFLUSH_MONITOR)) {
smp_mb(); /* quirk */
clflush((void *)¤t_thread_info()->flags);
smp_mb(); /* quirk */
}
x86_disable_ibrs();
__monitor((void *)¤t_thread_info()->flags, 0, 0);
if (!need_resched())
__sti_mwait(0, 0);
else
local_irq_enable();
x86_enable_ibrs();
...
the MSR might get set to non-zero again after having been
cleared by the code your patch adds. I therefore think that the
only race free solution would be to do the clearing from
stop-machine context. But maybe I'm overlooking something.
Jan
[PATCH v1 3/4] arm64: Fix the page leak in pud/pmd_set_huge
While setting huge page, we need to take care of previously existing next level mapping. Since, we are going to overrite previous mapping, the only reference to next level page table will get lost and the next level page table will be zombie, occupying space forever. So, free it before overriding. Signed-off-by: Chintan Pandya --- arch/arm64/mm/mmu.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index 8c704f1..c0df264 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -32,7 +32,7 @@ #include #include #include - +#include #include #include #include @@ -45,6 +45,7 @@ #include #include #include +#include #define NO_BLOCK_MAPPINGS BIT(0) #define NO_CONT_MAPPINGS BIT(1) @@ -939,6 +940,9 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t prot) return 0; BUG_ON(phys & ~PUD_MASK); + if (pud_val(*pud) && !pud_huge(*pud)) + free_page((unsigned long)__va(pud_val(*pud))); + set_pud(pudp, pfn_pud(__phys_to_pfn(phys), sect_prot)); return 1; } @@ -953,6 +957,9 @@ int pmd_set_huge(pmd_t *pmdp, phys_addr_t phys, pgprot_t prot) return 0; BUG_ON(phys & ~PMD_MASK); + if (pmd_val(*pmd) && !pmd_huge(*pmd)) + free_page((unsigned long)__va(pmd_val(*pmd))); + set_pmd(pmdp, pfn_pmd(__phys_to_pfn(phys), sect_prot)); return 1; } -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v1 4/4] Revert "arm64: Enforce BBM for huge IO/VMAP mappings"
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index c0df264..19116c6 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -935,10 +935,6 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t
prot)
pgprot_t sect_prot = __pgprot(PUD_TYPE_SECT |
pgprot_val(mk_sect_prot(prot)));
- /* ioremap_page_range doesn't honour BBM */
- if (pud_present(READ_ONCE(*pudp)))
- return 0;
-
BUG_ON(phys & ~PUD_MASK);
if (pud_val(*pud) && !pud_huge(*pud))
free_page((unsigned long)__va(pud_val(*pud)));
@@ -952,10 +948,6 @@ int pmd_set_huge(pmd_t *pmdp, phys_addr_t phys, pgprot_t
prot)
pgprot_t sect_prot = __pgprot(PMD_TYPE_SECT |
pgprot_val(mk_sect_prot(prot)));
- /* ioremap_page_range doesn't honour BBM */
- if (pmd_present(READ_ONCE(*pmdp)))
- return 0;
-
BUG_ON(phys & ~PMD_MASK);
if (pmd_val(*pmd) && !pmd_huge(*pmd))
free_page((unsigned long)__va(pmd_val(*pmd)));
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
Re: [PATCH] firmware: add a function to load optional firmware v2
Arend van Spriel writes:
> On 3/13/2018 5:46 PM, Kalle Valo wrote:
>> "Luis R. Rodriguez" writes:
>>
>>> On Tue, Mar 13, 2018 at 03:16:34PM +0200, Kalle Valo wrote:
"Luis R. Rodriguez" writes:
>> +/**
>> + * request_firmware_optional: - request for an optional fw module
>> + * @firmware_p: pointer to firmware image
>> + * @name: name of firmware file
>> + * @device: device for which firmware is being loaded
>> + *
>> + * This function is similar in behaviour to request_firmware(), except
>> + * it doesn't produce warning messages when the file is not found.
>> + **/
>> +int
>> +request_firmware_optional(const struct firmware **firmware_p, const
>> char *name,
>> + struct device *device)
>> +{
>> + int ret;
>> +
>> + /* Need to pin this module until return */
>> + __module_get(THIS_MODULE);
>> + ret = _request_firmware(firmware_p, name, device, NULL,
>> 0,
>> + FW_OPT_UEVENT | FW_OPT_NO_WARN );
>> + module_put(THIS_MODULE);
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(request_firmware_optional);
>
> New exported symbols for the firmware API should be EXPORT_SYMBOL_GPL().
To me the word optional feels weird to me. For example, in ath10k I
suspect we would be only calling request_firmware_optional() with all
firmware and not request_firmware() at all.
How about request_firmware_nowarn()? That would even match the
documentation above.
>>>
>>> _nowarn() works with me. Do you at least want the return value to give
>>> an error value if no file was found? This way the driver can decide
>>> when to issue an error if it wants to.
>>
>> Yes, it would be very good to return the error value to ath10k. That way
>> we can give a proper error message to the user if we can't find a
>> suitable firmware image.
>
> I fully agree with the _nowarn() and returning an error. However, the
> firmware_p parameter (btw. do we really want the _p postfix?)
Oh yeah, that _p is ugly. Please get rid of it, hungarian notation is
awful.
> is an output parameter which will be null in case of an error so do
> you really need a specific error code for the proper error message.
Sometimes the error code helps with debugging. But let's ask it this
way: why would we NOT return an error code? What would we gain from
that? I don't see any advantage from dropping the error code, on the
contrary better to be consistent with request_firmware() to avoid any
confusion.
--
Kalle Valo
Re: [PATCH] drm/panel: rm68200: add backlight dependency
On Wed, Mar 14, 2018 at 12:01 AM, Thierry Reding
wrote:
> On Tue, Mar 13, 2018 at 09:59:54PM +0100, Arnd Bergmann wrote:
>> Like many other panel drivers, this one fails to build
>> when backlight support is disabled:
>>
>> drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe':
>> panel-raydium-rm68200.c:(.text+0x14a): undefined reference to
>> `devm_of_find_backlight'
>>
>> This adds the appropriate dependency.
>>
>> Fixes: 2b7ed18bed1a ("drm/panel: Add support for Raydium RM68200 panel
>> driver")
>> Signed-off-by: Arnd Bergmann
>> ---
>> drivers/gpu/drm/panel/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>
> This shouldn't be necessary. include/linux/backlight.h defines a stub if
> the backlight class is not enabled.
>
> What tree are you seeing this on?
This is on linux-next.
It must be with BACKLIGHT_CLASS_DEVICE=m and
DRM_PANEL_RAYDIUM_RM68200=y, meaning that it should
be sufficient to do
depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
to force DRM_PANEL_RAYDIUM_RM68200 to be a loadable module
whenever BACKLIGHT_CLASS_DEVICE=m. For the patch, I looked at
what the other drivers in the same directory do and followed their
example.
I see three options here:
1. update my patch changelog with the explanation I wrote here but leave it
untouched
2. use the more elaborate dependency (after testing) but not change the
others
3. change all panel drivers with a backlight dependency the same way,
possibly with a helper symbol like
config BACKLIGHT_CLASS_DEVICE_OPTIONAL
tristate
default m if BACKLIGHT_CLASS_DEVICE=m
default y
Arnd
[PATCH v1 2/4] ioremap: Invalidate TLB after huge mappings
If huge mappings are enabled, they can override
valid intermediate previous mappings. Some MMU
can speculatively pre-fetch these intermediate
entries even after unmap. That's because unmap
will clear only last level entries in page table
keeping intermediate (pud/pmd) entries still valid.
This can potentially lead to stale TLB entries
which needs invalidation after map.
Some more info: https://lkml.org/lkml/2017/12/23/3
There is one noted case for ARM64 where such stale
TLB entries causes 3rd level translation fault even
after correct (huge) mapping is available.
See the case below (reproduced locally with tests),
[17505.330123] Unable to handle kernel paging request at virtual address
ff801ae0
[17505.338100] pgd = ff800a761000
[17505.341566] [ff801ae0] *pgd=00017e1be003, *pud=00017e1be003,
*pmd=00e898000f05
[17505.350704] [ cut here ]
[17505.355362] Kernel BUG at ff8008238c30 [verbose debug info unavailable]
[17505.362375] Internal error: Oops: 9607 [#1] PREEMPT SMP
[17505.367996] Modules linked in:
[17505.371114] CPU: 6 PID: 488 Comm: chintan-ioremap Not tainted 4.9.81+ #160
[17505.378039] Hardware name: Qualcomm Technologies, Inc. SDM845 v1 MTP (DT)
[17505.384885] task: ffc0e3e61180 task.stack: ffc0e3e7
[17505.390868] PC is at io_remap_test+0x2e0/0x444
[17505.395352] LR is at io_remap_test+0x2d0/0x444
[17505.399835] pc : [] lr : [] pstate:
60c5
[17505.407282] sp : ffc0e3e73d70
[17505.410624] x29: ffc0e3e73d70 x28: ff801ae8
[17505.416031] x27: ff801ae00010 x26: ff801ae00018
[17505.421436] x25: ff801ae00020 x24: ff801adfffe0
[17505.426840] x23: ff801adfffe8 x22: ff801ad0
[17505.432244] x21: ff801ad8 x20: ff801ae0
[17505.437648] x19: 0005 x18:
[17505.443052] x17: b3409452 x16: 923da470
[17505.448456] x15: 71c9763c x14: a15658fa
[17505.453860] x13: 5cae96bf x12: e6d5c44a
[17505.459264] x11: 0140 x10: ff80099a1000
[17505.464668] x9 : x8 : ffc0e3e73d68
[17505.470072] x7 : ff80099d3220 x6 : 0015
[17505.475476] x5 : 0c4ad32a x4 : 000a
[17505.480880] x3 : 0682aaab x2 : 001345c2ad2e
[17505.486284] x1 : 7d78d61de56639ba x0 : 0001
Hence, invalidate once we override pmd/pud with huge
mappings.
Signed-off-by: Chintan Pandya
---
lib/ioremap.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/ioremap.c b/lib/ioremap.c
index b808a39..c1e1341 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
static int __read_mostly ioremap_p4d_capable;
@@ -92,8 +93,10 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned
long addr,
if (ioremap_pmd_enabled() &&
((next - addr) == PMD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PMD_SIZE)) {
- if (pmd_set_huge(pmd, phys_addr + addr, prot))
+ if (pmd_set_huge(pmd, phys_addr + addr, prot)) {
+ flush_tlb_pgtable(&init_mm, addr);
continue;
+ }
}
if (ioremap_pte_range(pmd, addr, next, phys_addr + addr, prot))
@@ -118,8 +121,10 @@ static inline int ioremap_pud_range(p4d_t *p4d, unsigned
long addr,
if (ioremap_pud_enabled() &&
((next - addr) == PUD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PUD_SIZE)) {
- if (pud_set_huge(pud, phys_addr + addr, prot))
+ if (pud_set_huge(pud, phys_addr + addr, prot)) {
+ flush_tlb_pgtable(&init_mm, addr);
continue;
+ }
}
if (ioremap_pmd_range(pud, addr, next, phys_addr + addr, prot))
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
Re: [PATCH v1 2/2] usb: dwc3: Add Qualcomm DWC3 glue driver
Hi,
Manu Gautam writes:
> Hi,
>
>
> On 3/13/2018 4:38 PM, Felipe Balbi wrote:
>> Hi,
>>
>> +Andy
>>
>> Manu Gautam writes:
>>> DWC3 controller on Qualcomm SOCs has a Qscratch wrapper.
>>> Some of its uses are described below resulting in need to
>>> have a separate glue driver instead of using dwc3-of-simple:
>>> - It exposes register interface to override vbus-override
>>>and lane0-pwr-present signals going to hardware. These
>>>must be updated in peripheral mode for DWC3 if vbus lines
>>>are not connected to hardware block. Otherwise RX termination
>>>in SS mode or DP pull-up is not applied by device controller.
>> right, core needs to know that VBUS is above 4.4V. Why wasn't this a
>> problem when the original glue layer was first published?
>
> Thanks for reviewing.
> Original glue layer supported only host mode, hence this wasn't needed.
okay
>>> - pwr_events_irq_stat support to ensure USB2 PHY is in L2 state
>>>before glue driver can turn-off clocks and suspend PHY.
>> Core manages PHY suspend automatically. Isn't that working for you? Why?
>
> Yes, it is not supported with QUSB2 PHY (usb2-phy on Qualcomm SOCs).
but the PHY doesn't need to support it, DWC3 does :-)
> Issue is that If core suspends USB2 PHY (say in host mode if some SS device
> connected),
> USB2 PHY stops responding to any attach event as it can't exit suspend state
> by itself.
Okay, so we miss remote wakeup events. Fair enough.
>>> - Support to replace pip3 clock going to DWC3 with utmi clock
>>>for hardware configuration where SSPHY is not used with DWC3.
>> Is that SW configurable? Really? In any case seems like this and SESSVLD
>> valid should be handled using Hans' and Heikki's mux support.
>
> Yes, with this we can use dwc3 without using SSPHY. Please point me to
> those patches. There are only bunch of register writes in glue wrapper to
> achieve the same.
https://www.spinics.net/lists/linux-usb/msg160868.html
>>> +static int dwc3_qcom_suspend(struct dwc3_qcom *qcom)
>>> +{
>>> + struct dwc3 *dwc = platform_get_drvdata(qcom->dwc3);
>> nope! Glue shouldn't touch dwc3 at all.
> Other than PHY handles, need this to fail runtime suspend if dwc3 hasn't
> probed yet.
Will that even happen? You should pm_runtime_forbid() by default,
anyway and expect it to be enabled via sysfs later, no?
>>> + dwc3_qcom_suspend_hsphy(qcom);
>>> +
>>> + if (dwc->usb2_generic_phy)
>>> + phy_pm_runtime_put_sync(dwc->usb2_generic_phy);
>>> + if (dwc->usb3_generic_phy)
>>> + phy_pm_runtime_put_sync(dwc->usb3_generic_phy);
>> core.c should do this.
> Recommended sequence from h/w programming guide is that:
> 1. PHY autosuspend must be left disabled -
> snps,dis_u2_susphy_quirk/dis_enblslpm_quirk
> 2. During runtime-suspend (say on xhci bus_suspend) , PHY should be suspended
> using GUSB2PHYCFG register
this is something that dwc3 core can do on its own suspend implementation.
> 3. Wait until pwr_event_irq_stat in qscratch reflects PHY transition to L2.
this is interesting part. Is this register accessible by the PHY driver?
Seems like that would be the best place to stuff this...
> 3. USB2 PHY driver can suspend - enable wakeup events and turns off clocks
> etc.
... together with this.
> 4. dwc3 glue driver can suspend.
>
> Since, pwr_event_irq stat can't be checked in core driver, I added this
> handling
> in glue driver. Alternative approach I can think of is to let dwc3 core
> suspend
> PHY using GUSBPHYCFG register on suspend, add some delay before
> suspending PHY. Glue driver can check for pwr_event_irq stat and throw a
> warning if PHY not in L2.
almost :-) core_suspend fiddles with GUSB2PHYCFG for suspend and calls
phy_suspend() (or whatever the function is called heh), that will go to
your phy driver's suspend callback, which checks pwr_event_irq_stat and
then pm_runtime_put() to schedule ->runtime_suspend() so that can enable
wakeups and switch off clocks.
>>> + irq = platform_get_irq_byname(pdev, "dp_hs_phy_irq");
>>> + if (irq > 0) {
>>> + irq_set_status_flags(irq, IRQ_NOAUTOEN);
>> why do you need to set this flag?
> These wakeup_irqs should be enabled only during suspend. With this flag I
> don't need to disable irq immediately after requesting it.
oh, okay. You may want to add a comment here :-)
>
>>
>>> + ret = devm_request_threaded_irq(qcom->dev, irq, NULL,
>>> + qcom_dwc3_resume_irq,
>>> + IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
>>> + "qcom_dwc3 DP_HS", qcom);
>> this is the same as devm_request_irq()
> I am passing hard_irq handler as NULL whereas thread_fn is not NULL.
> devm_request_irq is just the opposite.
oh, indeed. I misparsed it.
>>> +static const struct dev_pm_ops dwc3_qcom_dev_pm_ops = {
>>> + SET_SYSTEM_SLEEP_PM_OPS(dwc3_qcom_pm_suspend, dwc3_qcom_pm_resume)
>>> + SET_RUNTIME_PM_OPS(dwc3_qcom_runtime_suspend,
Re: [PATCH v9 17/24] mm: Protect mm_rb tree with a rwlock
On Tue, Mar 13, 2018 at 06:59:47PM +0100, Laurent Dufour wrote:
> This change is inspired by the Peter's proposal patch [1] which was
> protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in
> that particular case, and it is introducing major performance degradation
> due to excessive scheduling operations.
Do you happen to have a little more detail on that?
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 34fde7111e88..28c763ea1036 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -335,6 +335,7 @@ struct vm_area_struct {
> struct vm_userfaultfd_ctx vm_userfaultfd_ctx;
> #ifdef CONFIG_SPECULATIVE_PAGE_FAULT
> seqcount_t vm_sequence;
> + atomic_t vm_ref_count; /* see vma_get(), vma_put() */
> #endif
> } __randomize_layout;
>
> @@ -353,6 +354,9 @@ struct kioctx_table;
> struct mm_struct {
> struct vm_area_struct *mmap;/* list of VMAs */
> struct rb_root mm_rb;
> +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
> + rwlock_t mm_rb_lock;
> +#endif
> u32 vmacache_seqnum; /* per-thread vmacache */
> #ifdef CONFIG_MMU
> unsigned long (*get_unmapped_area) (struct file *filp,
When I tried this, it simply traded contention on mmap_sem for
contention on these two cachelines.
This was for the concurrent fault benchmark, where mmap_sem is only ever
acquired for reading (so no blocking ever happens) and the bottle-neck
was really pure cacheline access.
Only by using RCU can you avoid that thrashing.
Also note that if your database allocates the one giant mapping, it'll
be _one_ VMA and that vm_ref_count gets _very_ hot indeed.
Re: [pci PATCH v6 1/5] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources
On Tue, Mar 13, 2018 at 02:28:49PM -0700, Alexander Duyck wrote:
> From: Alexander Duyck
>
> This patch adds a common configuration function called
> pci_sriov_configure_simple that will allow for managing VFs on devices
> where the PF is not capable of managing VF resources.
>
> Signed-off-by: Alexander Duyck
> ---
>
> v5: New patch replacing pci_sriov_configure_unmanaged with
> pci_sriov_configure_simple
> Dropped bits related to autoprobe changes
> v6: Defined pci_sriov_configure_simple as NULL if IOV is disabled
>
> drivers/pci/iov.c | 32
> include/linux/pci.h |3 +++
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 677924ae0350..bd7021491fdb 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -807,3 +807,35 @@ int pci_sriov_get_totalvfs(struct pci_dev *dev)
> return dev->sriov->total_VFs;
> }
> EXPORT_SYMBOL_GPL(pci_sriov_get_totalvfs);
> +
> +/**
> + * pci_sriov_configure_simple - helper to configure unmanaged SR-IOV
> + * @dev: the PCI device
> + * @nr_virtfn: number of virtual functions to enable, 0 to disable
> + *
> + * Used to provide generic enable/disable SR-IOV option for devices
> + * that do not manage the VFs generated by their driver
> + */
> +int pci_sriov_configure_simple(struct pci_dev *dev, int nr_virtfn)
> +{
> + int err = -EINVAL;
This assignment seems like it is never used..
> +
> + might_sleep();
> +
> + if (!dev->is_physfn)
> + return -ENODEV;
> +
> + if (pci_vfs_assigned(dev)) {
> + pci_warn(dev,
> + "Cannot modify SR-IOV while VFs are assigned\n");
> + err = -EPERM;
Why not:
if (pci_vfs_assigned(dev)) {
pci_warn(dev,
"Cannot modify SR-IOV while VFs are assigned\n");
return -EPERM;
}
Otherwise looks good:
Reviewed-by: Christoph Hellwig
Re: [pci PATCH v6 4/5] nvme: Migrate over to unmanaged SR-IOV support
Looks good, Reviewed-by: Christoph Hellwig
Re: [pci PATCH v6 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
Looks good, Reviewed-by: Christoph Hellwig
Re: [pci PATCH v6 5/5] pci-pf-stub: Add PF driver stub for PFs that function only to enable VFs
> +
> +/**
> + * pci_pf_stub_white_list - White list of devices to bind pci-pf-stub onto
> + *
> + * This table provides the list of IDs this driver is supposed to bind
> + * onto. You could think of this as a list of "quirked" devices where we
> + * are adding support for SR-IOV here since there are no other drivers
> + * that they would be running under.
> + *
> + * Layout of the table below is as follows:
> + * { Vendor ID, Device ID,
> + * SubVendor ID, SubDevice ID,
> + * Class, Class Mask,
> + * private data (not used) }
> + */
No need to document the PCI device table format in a random driver.
Otherwise looks fine:
Reviewed-by: Christoph Hellwig
Re: [PATCH][usb-next] usb: dwc2: ix spelling mistake: "genereted" -> "generated"
Hi, Colin King writes: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_warn warning message text. > > Signed-off-by: Colin Ian King seems like we need a patch to fix your subject ;-) I'll fix it when applying -- balbi signature.asc Description: PGP signature
Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure
>> +.dev_groups = amba_dev_groups, >> +.match = amba_match, >> +.uevent = amba_uevent, >> +.pm = &amba_pm, >> +.dma_configure = amba_dma_configure, >> +.dma_deconfigure= amba_dma_deconfigure, >> +.force_dma = true, > > This patch should also be removing force_dma because it no longer makes > sense. If DMA configuration is now done by a bus-level callback, then a bus > which wants its children to get DMA configuration needs to implement that > callback; there's nowhere to force a "default" global behaviour any more. Btw, we don't really know how many busses currently rely on OF or ACPI configuration. So maybe we need to keep those as a default?
Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure
> Agree. There is no good point in duplicating the code. > So this new API will be part of 'drivers/base/dma-mapping.c' file? Yes. > > As mention in my previous reply I think we don't even need a deconfigure > > callback at this point - just remove the ACPI and OF wrappers and > > clear the dma ops. > > > > Also in this series we should replace the force_dma flag by use of the > > proper method, e.g. give a force parameter to of_dma_configure and the > > new dma_common_configure helper that the busses that want it can set. > > I am more inclined to what Robin states in other mail to keep symmetry. > i.e. to keep dma_configure() and dma_deconfigure() and call > dev->bus->dma_configure from dma_configure(). Is this okay? Sure.
Re: [RESEND] rsi: Remove stack VLA usage
tcharding writes: > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote: >> tcharding wrote: >> >> > The kernel would like to have all stack VLA usage removed[1]. rsi uses >> > a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size >> > is defined using a magic number. We can use a pre-processor defined >> > constant and declare the array to maximum size. We add a check before >> > accessing the array in case of programmer error. >> > >> > [1]: https://lkml.org/lkml/2018/3/7/621 >> > >> > Signed-off-by: Tobin C. Harding >> >> Tobin, your name in patchwork.kernel.org is just "tcharding" then it should >> be >> "Tobin C. Harding". Patchwork is braindead in a way as it takes the name from >> it's database instead of the From header of the patch in question. >> >> I can fix that manually but it would be helpful if you could register to >> patchwork and fix your name during registration. You have only one chance to >> fix your name (another braindead feature!) so be careful :) > > Hi Kalle, > > I logged into my patchwork account but I don't see any way to set the > name. Within 'profile' there is only 'change password' and 'link > email'. I thought I could unregister then re-register but I can't see > how to do that either. Ok, maybe you have registered (=logged on for the first time) already earlier so it's not possible to change the name anymore. > Is there a maintainer of patchwork.kernel.org who I can email to > manually remove me from the system? helpd...@kernel.org should be able to fix your name in patchwork, at least they have done it in the past. This is not the first time this has happened. -- Kalle Valo
Re: [PATCH] drivers: base: add description for .coredump() callback
On 2/9/2018 10:13 AM, Arend van Spriel wrote:
Commit 3c47d19ff4dc ("drivers: base: add coredump driver ops") added
a new callback in struct device_driver, but not a kerneldoc description
so here it is.
Hi Greg,
Revisiting the header file I notice this patch is not yet applied. I am
pretty sure I got an automated email from you regarding the merge
window, but nothing else so did this one slip the cracks?
Regards,
Arend
Fixes: 3c47d19ff4dc ("drivers: base: add coredump driver ops")
Signed-off-by: Arend van Spriel
---
include/linux/device.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index b093405..0b32a42 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -256,6 +256,7 @@ enum probe_type {
*automatically.
* @pm: Power management operations of the device which matched
*this driver.
+ * @coredump: Called through sysfs to initiate a device coredump.
* @p:Driver core's private data, no one other than the driver
*core can touch this.
*
Re: [RESEND PATCH v1 5/6] i2c: i2c-stm32f7: Add DMA support
Hi Pierre-Yves,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on v4.16-rc4]
[also build test WARNING on next-20180314]
[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/Pierre-Yves-MORDRET/Add-different-features-for-I2C/20180313-193102
config: m32r-allmodconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r
All warnings (new ones prefixed by >>):
In file included from arch/m32r/include/uapi/asm/byteorder.h:8:0,
from arch/m32r/include/asm/bitops.h:22,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/clk.h:16,
from drivers/i2c/busses/i2c-stm32f7.c:17:
include/linux/byteorder/big_endian.h:8:2: warning: #warning inconsistent
configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]
#warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
^~~
In file included from include/linux/printk.h:329:0,
from include/linux/kernel.h:14,
from include/linux/clk.h:16,
from drivers/i2c/busses/i2c-stm32f7.c:17:
drivers/i2c/busses/i2c-stm32f7.c: In function 'stm32f7_i2c_isr_event_thread':
>> drivers/i2c/busses/i2c-stm32f7.c:1446:24: warning: format '%x' expects
>> argument of type 'unsigned int', but argument 5 has type 'long unsigned int'
>> [-Wformat=]
dev_dbg(i2c_dev->dev, "master evt irq (status=0x%08x, cr1=0x%08x)\n",
^
include/linux/dynamic_debug.h:135:39: note: in definition of macro
'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
>> drivers/i2c/busses/i2c-stm32f7.c:1446:2: note: in expansion of macro
>> 'dev_dbg'
dev_dbg(i2c_dev->dev, "master evt irq (status=0x%08x, cr1=0x%08x)\n",
^~~
vim +1446 drivers/i2c/busses/i2c-stm32f7.c
1423
1424 static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
1425 {
1426 struct stm32f7_i2c_dev *i2c_dev = data;
1427 struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
1428 struct stm32_i2c_dma *dma = i2c_dev->dma;
1429 u32 status;
1430 int ret;
1431
1432 /*
1433 * Wait for dma transfer completion before sending next message
or
1434 * notity the end of xfer to the client
1435 */
1436 ret = wait_for_completion_timeout(&i2c_dev->dma->dma_complete,
HZ);
1437 if (!ret) {
1438 dev_dbg(i2c_dev->dev, "<%s>: Timed out\n", __func__);
1439 stm32f7_i2c_disable_dma_req(i2c_dev);
1440 dmaengine_terminate_all(dma->chan_using);
1441 f7_msg->result = -ETIMEDOUT;
1442 }
1443
1444 status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
1445
> 1446 dev_dbg(i2c_dev->dev, "master evt irq (status=0x%08x,
> cr1=0x%08x)\n",
1447 status, readl_relaxed(i2c_dev->base + STM32F7_I2C_CR1));
1448 if (status & STM32F7_I2C_ISR_TC) {
1449 if (f7_msg->smbus) {
1450 stm32f7_i2c_smbus_rep_start(i2c_dev);
1451 } else {
1452 i2c_dev->msg_id++;
1453 i2c_dev->msg++;
1454 stm32f7_i2c_xfer_msg(i2c_dev, i2c_dev->msg);
1455 }
1456 } else {
1457 i2c_dev->master_mode = false;
1458 complete(&i2c_dev->complete);
1459 }
1460
1461 return IRQ_HANDLED;
1462 }
1463
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v3 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Andrzej,
sorry for the mess :(
On Wed, Mar 14, 2018 at 09:15:42AM +0100, Andrzej Hajda wrote:
> On 13.03.2018 15:30, Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > .../bindings/display/bridge/thine,thc63lvd1024.txt | 63
> > ++
> > 1 file changed, 63 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..5b5afcd
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,63 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> > streams
> > +to parallel data outputs. The chip supports single/dual input/output modes,
> > +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> > outputs.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024",
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
>
> I wonder if it wouldn't be better to make them required (at least VCC) -
> it is closer to reality.
In cases like our Eagle board, where VCC is directly connected to the
powering rail and not through a controllable regulator, I feel like
making this mandatory requires more effort (not much, I agree, just a
"fixed-regulator" more) with no additional benefits.
But I understand your point, and I'm open to whatever fits better with
the already existing DRM bridges bindings
>
> > +- pwnd-gpios: Power down GPIO signal. Active low.
>
> As I said before, specs[1] says about "/PDWN" pin. Is it your typo, or
> different docs?
I didn't notice the typo in first review, and I thought you were referring to
the initial '/' which I found weird to be part of the gpio name... Then I now
realized I badly typed in "pwnd" in place of "pwdn", which is not even correct
because it has to be "pdwn"... Sorry about this mess, I will fix in v4
> Moreover there are already bindings for THC63LVDM83D with the same
> dichotomy [2].
Seems like this is 'wrong' as well.. The chip manual says the pin is
named "pdwn" here too..
>
> Out of curiosity I have googled for "pwnd pin" and it looks like some
> vendors use this form.
> For me both forms are quite misleading: power down signal, active low,
> why they couldn't call it just 'enable, active high'.
>
It's not much the actual physical active level that bugs me, but the fact
that the GPIO name defines if it has to be set to "active" or
"inactive" logical state in enable/disable routines that I don't
like..
> [1]: http://www.thine.co.jp/files/topics/179_ext_12_0.pdf
> [2]:
> https://elixir.bootlin.com/linux/v4.16-rc5/source/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
>
> > +- oe-gpios: Output enable GPIO signal. Active high.
> > +
> > +The THC63LVD1024 video port connections are modeled according
> > +to OF graph bindings specified by
> > Documentation/devicetree/bindings/graph.txt
> > +
> > +Required video port nodes:
> > +- Port@0: First LVDS input port
> > +- Port@2: First digital CMOS/TTL parallel output
> > +
> > +Optional video port nodes:
> > +- Port@1: Second LVDS input port
> > +- Port@3: Second digital CMOS/TTL parallel output
> > +
> > +Example:
> > +
> > +
> > + thc63lvd1024: lvds-decoder {
> > + compatible = "thine,thc63lvd1024";
> > +
> > + vcc-supply = <®_lvds_vcc>;
> > + lvcc-supply = <®_lvds_lvcc>;
> > +
> > + pwdn-gpio = <&gpio4 15 GPIO_ACTIVE_LOW>;
> And here another variation :), should be pdwn-gpios.
Next time it will be "pndw".. Is there a prize if I do insert all
permutations of the same name in a single bindings document? :)
Will fix this shortly.
Thanks
j
signature.asc
Description: PGP signature
Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible
On Wed, 2018-03-14 at 12:11 +0800, Dou Liyang wrote: > > At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote: > > > On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy > > > > Longer term, yeah, I agree. Kernel's notion of possible CPU > > > > count > > > > should be realistic. > > > > I did a patch for that, Artem, could you help me to test it. > > > > I didn't consider the nr_cpu_ids before. please ignore the old patch > and > try the following RFC patch. Sure I can help with testing a patch, could we please: 1. Start a new thread for this 2. Include ACPI forum/folks Thanks, Artem.
Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices
On 14.03.18 08:51, Marc Kleine-Budde wrote:
+ memcpy(cf->data, m->msg.can_msg.data, cf->can_dlc);
+
+ /* don't count error frames as real packets */
+ if (!(canid & CAN_ERR_FLAG)) {
+ stats->rx_packets++;
+ stats->rx_bytes += cf->can_dlc;
+ }
Please count them, too.
We do count them, as errors!
This is what happens when you transmit a single CAN frame with nothing
connected: "TX errors" shoots up but "RX packets" stays zero.
root@rk3399-q7:~# ip -details -statistics link show can0
[...]
RX: bytes packets errors dropped overrun mcast
0 00 0 0 0
TX: bytes packets errors dropped carrier collsns
0 020425 0 0 0
Re: [RESEND] rsi: Remove stack VLA usage
"Tobin C. Harding" writes: > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding wrote: >> > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote: >> >> tcharding wrote: >> >> I'm pretty much sure it depends on the original email headers, like >> above ^^^ — no name. >> Perhaps git config on your side should be done. > > Thanks for the suggestion Andy but the 'tcharding' as the name was > munged by either Kalle or patchwork. I'm guessing patchwork. You guessed corretly, patchwork is here to blame. I sent my "please rebase" mail earlier in this thread using my custom patchwork client script (pwcli) which takes the name and address from patchwork. Andy, this is definitely a bug in patchwork and I have seen this issue multiple times already. I have understood that it has been fixed in a recent version but patchwork.kernel.org is still running an old version. In the original mail Tobin did have the correct From header which can be checked from the headers in patch page[1]: From: "Tobin C. Harding" [1] https://patchwork.kernel.org/patch/10274983/ -- Kalle Valo
[PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver
From: huang lin
Refactor Innolux P079ZCA panel driver, let it support
multi panel.
Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
Signed-off-by: Lin Huang
---
Changes in v2:
- Change regulator property name to meet the panel datasheet
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel, support
P097PFG panel in another patch
Changes in v4:
- Modify the patch which suggest by Thierry
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 142 ++
1 file changed, 101 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 57df39b..2075a9d 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,12 +20,28 @@
#include
+struct panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int bpc;
+ struct {
+ unsigned int width;
+ unsigned int height;
+ } size;
+
+ unsigned long flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+};
+
struct innolux_panel {
struct drm_panel base;
struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
struct backlight_device *backlight;
- struct regulator *supply;
+ struct regulator *vddi;
+ struct regulator *avdd;
+ struct regulator *avee;
struct gpio_desc *enable_gpio;
bool prepared;
@@ -77,9 +93,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
/* T8: 80ms - 1000ms */
msleep(80);
- err = regulator_disable(innolux->supply);
- if (err < 0)
- return err;
+ regulator_disable(innolux->avee);
+ regulator_disable(innolux->avdd);
+ regulator_disable(innolux->vddi);
innolux->prepared = false;
@@ -89,17 +105,25 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
static int innolux_panel_prepare(struct drm_panel *panel)
{
struct innolux_panel *innolux = to_innolux_panel(panel);
- int err, regulator_err;
+ int err;
if (innolux->prepared)
return 0;
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
- err = regulator_enable(innolux->supply);
+ err = regulator_enable(innolux->vddi);
if (err < 0)
return err;
+ err = regulator_enable(innolux->avdd);
+ if (err < 0)
+ goto disable_vddi;
+
+ err = regulator_enable(innolux->avee);
+ if (err < 0)
+ goto disable_avdd;
+
/* T2: 15ms - 1000ms */
usleep_range(15000, 16000);
@@ -133,12 +157,13 @@ static int innolux_panel_prepare(struct drm_panel *panel)
return 0;
poweroff:
- regulator_err = regulator_disable(innolux->supply);
- if (regulator_err)
- DRM_DEV_ERROR(panel->dev, "failed to disable regulator: %d\n",
- regulator_err);
-
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+ regulator_disable(innolux->avee);
+disable_avdd:
+ regulator_disable(innolux->avdd);
+disable_vddi:
+ regulator_disable(innolux->vddi);
+
return err;
}
@@ -162,7 +187,7 @@ static int innolux_panel_enable(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode innolux_p079zca_mode = {
.clock = 56900,
.hdisplay = 768,
.hsync_start = 768 + 40,
@@ -175,15 +200,29 @@ static const struct drm_display_mode default_mode = {
.vrefresh = 60,
};
+static const struct panel_desc innolux_p079zca_panel_desc = {
+ .modes = &innolux_p079zca_mode,
+ .bpc = 8,
+ .size = {
+ .width = 120,
+ .height = 160,
+ },
+ .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+ .format = MIPI_DSI_FMT_RGB888,
+ .lanes = 4,
+};
+
static int innolux_panel_get_modes(struct drm_panel *panel)
{
struct drm_display_mode *mode;
+ struct innolux_panel *innolux = to_innolux_panel(panel);
+ const struct drm_display_mode *m = innolux->desc->modes;
- mode = drm_mode_duplicate(panel->drm, &default_mode);
+ mode = drm_mode_duplicate(panel->drm, m);
if (!mode) {
DRM_DEV_ERROR(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- default_mode.vrefresh);
+ m->hdisplay, m->vdisplay, m->vrefresh);
return -ENOMEM;
}
@@ -191,9 +230,11 @@ static int innolux_panel_get_modes(struct drm_panel *panel)
drm_mode_probed_add(panel->connector, mode);
- panel->connector->display_info.width_mm = 120;
- panel->connector->display_inf
Re: [PATCH 0/2] Introduce STM32MP1 Reset driver
Hi Gabriel, On Tue, 2018-03-13 at 17:34 +0100, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > This patch-set enables the reset of STM32MP1. > It uses the reset simple driver by introducing the clear register offset > parameter. > STM32MP1 reset IP has a register to assert by writing '1' and another > register to de-assert by writing '1'. > The offset between this two registers is '0x4'. I worry a bit about feature creep in the simple-reset driver. Your patch on its own is simple enough, and I'm not opposed to add a SET/CLR feature on principle, but there are a few issues: The RESET_SIMPLE Kconfig description currently says: "This enables a simple reset controller driver for reset lines that that can be asserted and deasserted by toggling bits in a contiguous, exclusive register space." That would have to be extended to mention SET/CLR register pairs as an alternative. What about status (reset_simple_status)? Can current reset line status be read back from the SET register, as is currently tried? If not, is there a way to read current reset line status back at all? The data->lock spinlock is only needed to protect the read-modify-write cycle on a toggle register, for separate SET/CLR register access the locking is not necessary. At this point, it may or may not be easier to add a custom reset driver. Either way you go, this is missing binding documentation for the st,stm32mp1-rcc compatible in Documentation/devicetree/bindings/reset. > The patch 'dt-bindings: reset: add STM32MP1 resets' could be squashed > with the patch: > 'dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings' > commit 3830681d354f > > Gabriel Fernandez (2): > dt-bindings: reset: add STM32MP1 resets > reset: simple: Enable stm32mp1 reset driver > > drivers/reset/reset-simple.c| 27 +-- > drivers/reset/reset-simple.h| 1 + > include/dt-bindings/reset/stm32mp1-resets.h | 108 > > 3 files changed, 130 insertions(+), 6 deletions(-) > create mode 100644 include/dt-bindings/reset/stm32mp1-resets.h regards Philipp
[PATCH v4 3/3] dt-bindings: Add INNOLUX P097PFG panel bindings
From: huang lin The Innolux P097PFG panel is 9.7" panel with 1536X2048 resolution, it reuse P079ZCA panel driver, so improve p079ZCA dt-binding to support P097PFG. Change-Id: I8704914898fe53b734d31fbe646df8aa5fd8b30d Signed-off-by: Lin Huang --- Changes in v2: - None Changes in v3: - None Changes in v4: - None .../devicetree/bindings/display/panel/innolux,p079zca.txt | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt index d0f5516..8cadd8c 100644 --- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt +++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt @@ -1,13 +1,18 @@ Innolux P079ZCA 7.85" 768x1024 TFT LCD panel +Innolux P097PFG 9.7" 1536x2048 TFT LCD panel Required properties: -- compatible: should be "innolux,p079zca" +- compatible: should be should be one of the following. +-"innolux,p079zca" for Innolux 7.9" P079ZCA 768*1024 panel +-"innolux,p097pfg" for Innolux 9.7" P097PFG 1536*2048 panel - reg: DSI virtual channel of the peripheral -- power-supply: phandle of the regulator that provides the supply voltage - enable-gpios: panel enable gpio Optional properties: - backlight: phandle of the backlight device attached to the panel +- power-supply: phandle of the regulator that provides the supply voltage +- avdd-supply: phandle of the regulator that provides positive voltage +- avee-supply: phandle of the regulator that provides negative voltage Example: @@ -16,6 +21,8 @@ Example: compatible = "innolux,p079zca"; reg = <0>; power-supply = <...>; + avdd-supply = <...>; + avee-supply = <...>; backlight = <&backlight>; enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; }; -- 2.7.4
[PATCH v4 2/3] drm/panel: support Innolux P097PFG panel
Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse
the Innolux P079ZCA panel driver.
Change-Id: I97923aa3735f707332681691b0231c9421b427d0
Signed-off-by: Lin Huang
---
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- download panel initial code
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 192 +-
1 file changed, 187 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 2075a9d..883b279 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,6 +20,15 @@
#include
+struct panel_init_cmd {
+ int len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
struct panel_desc {
const struct drm_display_mode *modes;
unsigned int bpc;
@@ -30,6 +39,7 @@ struct panel_desc {
unsigned long flags;
enum mipi_dsi_pixel_format format;
+ const struct panel_init_cmd *init_cmds;
unsigned int lanes;
};
@@ -88,9 +98,12 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
return err;
}
+ /* p097pfg: t15 */
+ msleep(100);
+
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
- /* T8: 80ms - 1000ms */
+ /* p079zca: t8*/
msleep(80);
regulator_disable(innolux->avee);
@@ -124,13 +137,43 @@ static int innolux_panel_prepare(struct drm_panel *panel)
if (err < 0)
goto disable_avdd;
- /* T2: 15ms - 1000ms */
- usleep_range(15000, 16000);
+ /* p079zca: t2 (20ms), p097pfg: t4 (15ms) */
+ usleep_range(2, 21000);
gpiod_set_value_cansleep(innolux->enable_gpio, 1);
- /* T4: 15ms - 1000ms */
- usleep_range(15000, 16000);
+ /* p079zca: t4, p097pfg: t5 */
+ usleep_range(2, 21000);
+
+ if (innolux->desc->init_cmds) {
+ const struct panel_init_cmd *cmds =
+ innolux->desc->init_cmds;
+ int i;
+
+ for (i = 0; cmds[i].len != 0; i++) {
+ const struct panel_init_cmd *cmd = &cmds[i];
+
+ err = mipi_dsi_generic_write(innolux->link, cmd->data,
+cmd->len);
+ if (err < 0) {
+ dev_err(panel->dev,
+ "failed to write command %d\n", i);
+ goto poweroff;
+ }
+
+ /*
+* Included by random guessing, because without this
+* (or at least, some delay), the panel sometimes
+* didn't appear to pick up the command sequence.
+*/
+ err = mipi_dsi_dcs_nop(innolux->link);
+ if (err < 0) {
+ dev_err(panel->dev,
+ "failed to send DCS nop: %d\n", err);
+ goto poweroff;
+ }
+ }
+ }
err = mipi_dsi_dcs_exit_sleep_mode(innolux->link);
if (err < 0) {
@@ -213,6 +256,142 @@ static const struct panel_desc innolux_p079zca_panel_desc
= {
.lanes = 4,
};
+static const struct drm_display_mode innolux_p097pfg_mode = {
+ .clock = 229000,
+ .hdisplay = 1536,
+ .hsync_start = 1536 + 100,
+ .hsync_end = 1536 + 100 + 24,
+ .htotal = 1536 + 100 + 24 + 100,
+ .vdisplay = 2048,
+ .vsync_start = 2048 + 100,
+ .vsync_end = 2048 + 100 + 2,
+ .vtotal = 2048 + 100 + 2 + 18,
+ .vrefresh = 60,
+};
+
+static const struct panel_init_cmd innolux_p097pfg_init_cmds[] = {
+ /* page 0 */
+ _INIT_CMD(0xF0, 0x55, 0xAA, 0x52, 0x08, 0x00),
+ _INIT_CMD(0xB1, 0xE8, 0x11),
+ _INIT_CMD(0xB2, 0x25, 0x02),
+ _INIT_CMD(0xB5, 0x08, 0x00),
+ _INIT_CMD(0xBC, 0x0F, 0x00),
+ _INIT_CMD(0xB8, 0x03, 0x06, 0x00, 0x00),
+ _INIT_CMD(0xBD, 0x01, 0x90, 0x14, 0x14),
+ _INIT_CMD(0x6F, 0x01),
+ _INIT_CMD(0xC0, 0x03),
+ _INIT_CMD(0x6F, 0x02),
+ _INIT_CMD(0xC1, 0x0D),
+ _INIT_CMD(0xD9, 0x01, 0x09, 0x70),
+ _INIT_CMD(0xC5, 0x12, 0x21, 0x00),
+ _INIT_CMD(0xBB, 0x93, 0x93),
+
+ /* page 1 */
+ _INIT_CMD(0xF0, 0x55, 0xAA, 0x52, 0x08, 0x01),
+ _INIT_CMD(0xB3, 0x3C, 0x3C),
+ _INIT_CMD(0xB4, 0x0F, 0x0F),
+ _INIT_CMD(0xB9, 0x45, 0x45),
+ _INIT_CMD(0xBA, 0x14, 0x14),
+ _INIT_CMD(0xCA, 0x02),
+ _INIT_CMD(0xCE, 0x04),
+ _INIT_CMD(0xC3, 0x9B, 0x9B),
+ _INIT_CMD(0xD8, 0xC0, 0x03),
+ _INIT_CMD(0xBC, 0x82, 0x01),
+ _INIT_CMD(0xBD, 0x9E, 0x01),
+
+ /* page
Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices
On 14.03.18 10:11, Wolfgang Grandegger wrote:
+ /* handle error frames */
+ canid = le32_to_cpu(m->msg.can_msg.id);
+ if (canid & CAN_ERR_FLAG) {
+ ucan_handle_error_frame(up, m, canid);
+ /* drop frame if berr-reporting is off */
+ if (!(up->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING))
+ return;
+ }
You still do not generate error messages for state changes, IIUC.
The hardware generates error frames on state changes - is that what you
mean?
In our testing, the state shows up (and updates) correctly in
ip -details -statistics link show can0
Best regards,
Jakob
Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices
Am 14.03.2018 um 10:14 schrieb Jakob Unterwurzacher:
On 14.03.18 10:11, Wolfgang Grandegger wrote:
+ /* handle error frames */
+ canid = le32_to_cpu(m->msg.can_msg.id);
+ if (canid & CAN_ERR_FLAG) {
+ ucan_handle_error_frame(up, m, canid);
+ /* drop frame if berr-reporting is off */
+ if (!(up->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING))
+ return;
+ }
You still do not generate error messages for state changes, IIUC.
The hardware generates error frames on state changes - is that what you
mean?
In our testing, the state shows up (and updates) correctly in
ip -details -statistics link show can0
Counting the state changes is one thing but you should also generate
error messages for them.
Wolfgang.
Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices
Hello, Am 13.03.2018 um 18:35 schrieb Jakob Unterwurzacher: The UCAN driver supports the microcontroller-based USB/CAN adapters from Theobroma Systems. There are two form-factors that run essentially the same firmware: * Seal: standalone USB stick ( https://www.theobroma-systems.com/seal ) * Mule: integrated on the PCB of various System-on-Modules from Theobroma Systems like the A31-µQ7 and the RK3399-Q7 ( https://www.theobroma-systems.com/rk3399-q7 ) The USB wire protocol has been designed to be as generic and hardware-indendent as possible in the hope of being useful for implementation on other microcontrollers. Signed-off-by: Martin Elshuber Signed-off-by: Jakob Unterwurzacher Signed-off-by: Philipp Tomsich --- Documentation/networking/can_ucan_protocol.rst | 315 + Documentation/networking/index.rst |1 + drivers/net/can/usb/Kconfig| 10 + drivers/net/can/usb/Makefile |1 + drivers/net/can/usb/ucan.c | 1587 5 files changed, 1914 insertions(+) create mode 100644 Documentation/networking/can_ucan_protocol.rst create mode 100644 drivers/net/can/usb/ucan.c diff --git a/Documentation/networking/can_ucan_protocol.rst b/Documentation/networking/can_ucan_protocol.rst new file mode 100644 index ..d859b36200b4 --- /dev/null +++ b/Documentation/networking/can_ucan_protocol.rst @@ -0,0 +1,315 @@ += +The UCAN Protocol += + +UCAN is the protocol used by the microcontroller-based USB-CAN +adapter that is integrated on System-on-Modules from Theobroma Systems +and that is also available as a standalone USB stick. + +The UCAN protocol has been designed to be hardware-independent. +It is modeled closely after how Linux represents CAN devices +internally. All multi-byte integers are encoded as Little Endian. + +All structures mentioned in this document are defined in +``drivers/net/can/usb/ucan.c``. + +USB Endpoints += + +UCAN devices use three USB endpoints: + +CONTROL endpoint + The driver sends device management commands on this endpoint + +IN endpoint + The device sends CAN data frames and CAN error frames + +OUT endpoint + The driver sends CAN data frames on the out endpoint + + +CONTROL Messages + + +UCAN devices are configured using vendor requests on the control pipe. + +To support multiple CAN interfaces in a single USB device all +configuration commands target the corresponding interface in the USB +descriptor. + +The driver uses ``ucan_ctrl_command_in/out`` and +``ucan_device_request_in`` to deliver commands to the device. + +Setup Packet + + += = +``bmRequestType`` Direction | Vendor | (Interface or Device) +``bRequest`` Command Number +``wValue`` Subcommand Number (16 Bit) or 0 if not used +``wIndex`` USB Interface Index (0 for device commands) +``wLength``* Host to Device - Number of bytes to transmit + * Device to Host - Maximum Number of bytes to + receive. If the device send less. Commom ZLP + semantics are used. += = + +Error Handling +-- + +The device indicates failed control commands by stalling the +pipe. + +Device Commands +--- + +UCAN_DEVICE_GET_FW_STRING +~ + +*Dev2Host; optional* + +Request the device firmware string. + + +Interface Commands +-- + +UCAN_COMMAND_START +~~ + +*Host2Dev; mandatory* + +Bring the CAN interface up. + +Payload Format + ``ucan_ctl_payload_t.cmd_start`` + + +mode or mask of ``UCAN_MODE_*`` + + +UCAN_COMMAND_STOP +~~ + +*Host2Dev; mandatory* + +Stop the CAN interface + +Payload Format + *empty* + +UCAN_COMMAND_RESET +~~ + +*Host2Dev; mandatory* + +Reset the CAN controller (including error counters) + +Payload Format + *empty* + +UCAN_COMMAND_GET + + +*Host2Dev; mandatory* + +Get Information from the Device + +Subcommands +^^^ + +UCAN_COMMAND_GET_INFO + Request the device information structure ``ucan_ctl_payload_t.device_info``. + + See the ``device_info`` field for details, and + ``uapi/linux/can/netlink.h`` for an explanation of the + ``can_bittiming fields``. + + Payload Format +``ucan_ctl_payload_t.device_info`` + +UCAN_COMMAND_GET_PROTOCOL_VERSION + + Request the device protocol version + ``ucan_ctl_payload_t.protocol_version``. The current protocol version is 3. + + Payload Format +``ucan_ctl_payload_t.protocol_version`` + +.. note:: Devices that do not implement this command use the old + protocol version 1 + +UCAN_COMMAND_SET_BITTIMING +~~ + +*Host2Dev; mandatory* + +S
Re: [RESEND] rsi: Remove stack VLA usage
"Tobin C. Harding" writes: > Added Konstantin in case he is in charge of administering > patchwork.kernel.org? > > On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote: >> On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding wrote: >> > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: >> >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding wrote: >> >> > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote: >> >> >> tcharding wrote: >> >> >> >> I'm pretty much sure it depends on the original email headers, like >> >> above ^^^ — no name. >> >> Perhaps git config on your side should be done. >> > >> > Thanks for the suggestion Andy but the 'tcharding' as the name was >> > munged by either Kalle or patchwork. I'm guessing patchwork. >> >> Something you're sending from is using "tcharding" (see the email Andy >> quotes). I see the headers as: >> >> Date: Wed, 14 Mar 2018 07:17:57 +1100 >> From: tcharding >> ... >> Message-ID: <20180313201757.GK8631@eros> >> X-Mailer: Mutt 1.5.24 (2015-08-30) >> User-Agent: Mutt/1.5.24 (2015-08-30) >> >> Your most recently email shows "Tobin C. Harding" though, and also >> sent with Mutt... >> >> Do you have multiple Mutt configurations? Is something lacking a >> "From" header insertion and your MTA is filling it in for you from >> your username? > > Thanks for taking the time to respond Kees (and Tycho). I have mutt > configured to reply from whichever email address I receive from so if > patchwork sent an email to 'tcharding ' (which is the > details it has) and I hit reply it would have come from 'tcharding', > hence Andy's reply. I wouldn't bet my life on it but I'm kinda > confident that I cannot initiate an email from 'tcharding' with my > current set up. > > Super bad form to blame someone (or something else) but I think this is > a problem with how my patchwork account is configured. Either way, that > is still my fault I should have added my real name to patchwork when I > signed up (not just username 'tcharding'). > > Is patchwork.kernel.org administered by Konstantin Ryabitsev? Added > Konstantin to CC's. Like I said earlier, just send a request to helpd...@kernel.org and admins should fix your name. -- Kalle Valo
[PATCH v3 0/7] Add support for remoteproc modem-pil on SDM845 SoCs
This patch series add support for remoteproc Q6v5 modem-pil on Qualcomm SDM845 SoC. The second patch adds AOSS (Always on subsystem) reset driver to provide for mss reset line. The fourth patch adds the APCS offset for SDM845. The last couple of patches add the resets sequence for Q6 on SDM845 and adds helper functions for arbitrary reset assert/deassert sequences. V3: Removed syscon dependency for the aoss reset driver Split dt-bindings and the aoss reset driver into separate patches Corrected few typos and replaced misconfigured author name V2: Addressed reset-qcom-aoss review suggestions and reworked re-ordering of the active clk and reset sequence in qcom_q6v5_pil Sibi S (7): dt-bindings: reset: Add AOSS reset bindings for SDM845 SoCs reset: qcom: AOSS (always on subsystem) reset controller dt-bindings: mailbox: Add APCS global binding for SDM845 SoCs mailbox: Add support for Qualcomm SDM845 SoCs dt-bindings: remoteproc: Add Q6v5 Modem PIL binding for SDM845 remoteproc: qcom: Add support for mss remoteproc on SDM845 remoteproc: qcom: Always assert and deassert reset signals in SDM845 .../bindings/mailbox/qcom,apcs-kpss-global.txt | 1 + .../devicetree/bindings/remoteproc/qcom,q6v5.txt | 1 + .../devicetree/bindings/reset/qcom,aoss-reset.txt | 54 +++ drivers/mailbox/qcom-apcs-ipc-mailbox.c| 1 + drivers/remoteproc/qcom_q6v5_pil.c | 163 - drivers/reset/Kconfig | 10 ++ drivers/reset/Makefile | 1 + drivers/reset/reset-qcom-aoss.c| 156 include/dt-bindings/reset/qcom,sdm845-aoss.h | 17 +++ 9 files changed, 398 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt create mode 100644 drivers/reset/reset-qcom-aoss.c create mode 100644 include/dt-bindings/reset/qcom,sdm845-aoss.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 1/1] can: ucan: add driver for Theobroma Systems UCAN devices
On 14.03.18 10:17, Wolfgang Grandegger wrote:
Counting the state changes is one thing but you should also generate
error messages for them.
We do for BUS-OFF already (see below), but not for other states - will
do in v3.
+ /* we switched into a worse state */
+ up->can.state = new_state;
+ switch (new_state) {
+ case CAN_STATE_BUS_OFF:
+ can_stats->bus_off++;
+ can_bus_off(up->netdev);
+ netdev_info(up->netdev,
+ "link has gone into BUS-OFF state\n");
+ break;
Re: [PATCH] hv_netvsc: Make sure out channel is fully opened on send
On Tue, 2018-03-13 at 12:35 -0700, Stephen Hemminger wrote:
> On Tue, 13 Mar 2018 20:06:50 +0100
> Mohammed Gamal wrote:
>
> > Dring high network traffic changes to network interface parameters
> > such as number of channels or MTU can cause a kernel panic with a
> > NULL
> > pointer dereference. This is due to netvsc_device_remove() being
> > called and deallocating the channel ring buffers, which can then be
> > accessed by netvsc_send_pkt() before they're allocated on calling
> > netvsc_device_add()
> >
> > The patch fixes this problem by checking the channel state and
> > returning
> > ENODEV if not yet opened. We also move the call to
> > hv_ringbuf_avail_percent()
> > which may access the uninitialized ring buffer.
> >
> > Signed-off-by: Mohammed Gamal
> > ---
> > drivers/net/hyperv/netvsc.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/hyperv/netvsc.c
> > b/drivers/net/hyperv/netvsc.c
> > index 0265d70..44a8358 100644
> > --- a/drivers/net/hyperv/netvsc.c
> > +++ b/drivers/net/hyperv/netvsc.c
> > @@ -757,7 +757,7 @@ static inline int netvsc_send_pkt(
> > struct netdev_queue *txq = netdev_get_tx_queue(ndev,
> > packet->q_idx);
> > u64 req_id;
> > int ret;
> > - u32 ring_avail = hv_ringbuf_avail_percent(&out_channel-
> > >outbound);
> > + u32 ring_avail;
> >
> > nvmsg.hdr.msg_type = NVSP_MSG1_TYPE_SEND_RNDIS_PKT;
> > if (skb)
> > @@ -773,7 +773,7 @@ static inline int netvsc_send_pkt(
> >
> > req_id = (ulong)skb;
> >
> > - if (out_channel->rescind)
> > + if (out_channel->rescind || out_channel->state !=
> > CHANNEL_OPENED_STATE)
> > return -ENODEV;
> >
> > if (packet->page_buf_cnt) {
> > @@ -791,6 +791,7 @@ static inline int netvsc_send_pkt(
> > VMBUS_DATA_PACKET_FLAG_COMP
> > LETION_REQUESTED);
> > }
> >
> > + ring_avail = hv_ringbuf_avail_percent(&out_channel-
> > >outbound);
> > if (ret == 0) {
> > atomic_inc_return(&nvchan->queue_sends);
> >
>
> Thanks for your patch. Yes there are races with the current update
> logic. The root cause goes higher up in the flow; the send queues
> should
> be stopped before netvsc_device_remove is called. Solving it where
> you tried
> to is racy and not going to work reliably.
>
> Network patches should go to net...@vger.kernel.org
>
> You can't move the ring_avail check until after the vmbus_sendpacket
> because
> that will break the flow control logic.
>
Why? I don't see ring_avail being used before that point.
> Instead, you should just move the avail_read check until just after
> the existing rescind
> check.
>
> Also, you shouldn't need to check for OPENED_STATE, just rescind is
> enough.
That rarely mitigated the race. channel->rescind flag is set on vmbus
exit - called on module unload - and when a rescind offer is received
from the host, which AFAICT doesn't happen on every call to
netvsc_device_remove, so it's quite possible that the ringbuffer is
accessed before it's allocated again on channel open and hence the
check for OPENED_STAT - which is only set after all vmbus data is
initialized.
>
>
>
>
