* Re: [PATCH] ARM: pass -msoft-float to gcc earlier
From: Szabolcs Nagy @ 2020-05-20 8:36 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Arnd Bergmann, Linus Walleij, Russell King, LKML, Masahiro Yamada,
nd, Linux ARM
In-Reply-To: <CAKwvOd=EphyUWNOZ59FkrfDvDwHHU2yrXW+KML-w_6mHowK=QA@mail.gmail.com>
The 05/19/2020 17:38, Nick Desaulniers wrote:
> sorry, hit tab/enter too soon...
>
> On Tue, May 19, 2020 at 5:37 PM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> >
> > On Tue, May 19, 2020 at 3:09 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > Szabolcs Nagy ran into a kernel build failure with a custom gcc
> > > toochain that sets -mfpu=auto -mfloat-abi=hard:
> > >
> > > /tmp/ccmNdcdf.s:1898: Error: selected processor does not support `cpsid i' in ARM mode
> > >
> > > The problem is that $(call cc-option, -march=armv7-a) fails before the
> > > kernel overrides the gcc options to also pass -msoft-float.
> >
> > The call to `$(call cc-option, -march=armv7-a) is th
>
> The call to `$(call cc-option, -march=armv7-a) is the one that fails or...?
the flag -march=armv7-a is invalid if the float abi
is hard and no fpu is specified (since gcc-8).
either an fpu should be specified or -march=armv7-a+fp
(my toolchain was configured with the latter and it does
not work if the kernel overrides it with -march=armv7-a)
because of this cc-option failure the kernel goes on to
pass nonsense flags everywhere (-march=armv5t) and some
compilation eventually fails with an asm error.
> > >
> > > Move the option to the beginning the Makefile, before we call
> >
> > beginning of the
> >
> > > cc-option for the first time.
> > >
> > > Reported-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
> > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87302
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Moving this looks harmless enough, though it's not clear to me how the
> > failure you're describing would occur. I don't see calls to as-instr
> > in arch/arm/Makefile. Which object is being built before -msoft-float
> > is being set?
>
> ... ^
>
> >
> > > ---
> > > arch/arm/Makefile | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > index 7d5cd0f85461..e428ea6eb0fa 100644
> > > --- a/arch/arm/Makefile
> > > +++ b/arch/arm/Makefile
> > > @@ -16,6 +16,8 @@ LDFLAGS_vmlinux += --be8
> > > KBUILD_LDFLAGS_MODULE += --be8
> > > endif
> > >
> > > +KBUILD_CFLAGS += -msoft-float
> > > +
> > > ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
> > > KBUILD_LDS_MODULE += $(srctree)/arch/arm/kernel/module.lds
> > > endif
> > > @@ -135,7 +137,7 @@ AFLAGS_ISA :=$(CFLAGS_ISA)
> > > endif
> > >
> > > # Need -Uarm for gcc < 3.x
> > > -KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> > > +KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -Uarm
> > > KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
> > >
> > > CHECKFLAGS += -D__arm__
> > > --
> > > 2.26.2
> > >
>
> --
> Thanks,
> ~Nick Desaulniers
--
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: sram: add documentation for reserved-only flag
From: Thierry Reding @ 2020-05-20 8:40 UTC (permalink / raw)
To: Mian Yousaf Kaukab
Cc: devicetree, arnd, Stephen Warren, gregkh, linux-kernel, jonathanh,
talho, robh+dt, linux-tegra, robin.murphy, afaerber,
linux-arm-kernel
In-Reply-To: <20200513104127.GA2309@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 3083 bytes --]
On Wed, May 13, 2020 at 12:41:27PM +0200, Mian Yousaf Kaukab wrote:
> On Tue, May 12, 2020 at 01:45:28PM -0600, Stephen Warren wrote:
> > On 5/12/20 8:48 AM, Mian Yousaf Kaukab wrote:
> > > Add documentation for the new optional flag added for SRAM driver.
> >
> > > diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
> >
> > > + reserved-only:
> > > + description:
> > > + The flag indicating, that only SRAM reserved regions have to be remapped.
> > > + remapping type is selected depending upon no-memory-wc as usual.
> > > + type: boolean
> >
> > This feels a bit like a SW flag rather than a HW description, so I'm not
> > sure it's appropriate to put it into DT.
>
> Reserved regions themselves are software descriptions, no? Then we have 'pool'
> flag which is again a software flag and so on. This flag falls into same
> category and nothing out of ordinary.
> >
> > Are there any cases where the SW should map all of the SRAM, i.e. where
> > we wouldn't expect to set reserved-only? [...]
>
> Yes, here are a few examples:
> arch/arm/boot/dts/aspeed-g*.dtsi
Looking at the implementation of the sole user of this, which is in
drivers/fsi/fsi-master-ast-cf.c, it looks like this really should've
specified a partition because the driver basically goes on to allocate
a fixed 4 KiB region of memory anyway.
> arch/arm/boot/dts/at91*.dtsi
While these define SRAM nodes, I don't see them referenced anywhere.
> arch/arm/boot/dts/bcm7445.dtsi
> Then arch/arm/boot/dts/dra7.dtsi is an example where we should map everything
> except the reserved region.
The driver currently maps everything, so if this relies on this
particular reserved region not being mapped then that's already broken
anyway.
> > [...] I'd expect reserved-only to be
> > the default, and perhaps only, mode of operation for the SRAM driver.
>
> It will break compatibility with existing dtbs.
Yes, that's a bit unfortunate. I think this driver may suffer from a
slightly ambiguous device tree binding and then people just trying to
fit it to their use-cases.
However, I think we could preserve DTB backwards-compatibility while at
the same time correcting course and establish some sort of consistency.
Looking at the examples that you've provided and others, there are two
classes of users: users that don't specify any partitions either use all
of the available SRAM exclusively or manually allocate some part of it,
whereas users that have specified partitions all seem to use only the
defined partitions.
Given that, I think what we could do is check if there are any child
nodes and if not, keep the existing behaviour of mapping the whole SRAM
area. For cases where child nodes exist we could decide to go with the
default that Stephen suggested and only map regions for which a child
node has been defined.
This should allow both categories of users to work the way that they
were probably expected to work.
Any thoughts?
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] i2c: mediatek: Add i2c ac-timing adjust support
From: Qii Wang @ 2020-05-20 8:41 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
srv_heupstream, Wolfram Sang, leilk.liu,
Linux Kernel Mailing List, linux-mediatek, Linux I2C, Joe Perches,
Linux ARM
In-Reply-To: <CAMuHMdXgp85PVteunxrHYcMTqFgQWHmXXCVJM_KX76xkCADMpw@mail.gmail.com>
Hi Geert,
On Tue, 2020-05-19 at 09:14 +0200, Geert Uytterhoeven wrote:
> Hi Qii,
>
> On Tue, May 19, 2020 at 4:59 AM Qii Wang <qii.wang@mediatek.com> wrote:
> > On Mon, 2020-05-18 at 17:44 +0200, Geert Uytterhoeven wrote:
> > > On Thu, May 14, 2020 at 3:13 PM Qii Wang <qii.wang@mediatek.com> wrote:
> > > > This patch adds a algorithm to calculate some ac-timing parameters
> > > > which can fully meet I2C Spec.
> > > >
> > > > Signed-off-by: Qii Wang <qii.wang@mediatek.com>
> > > > ---
> > > > drivers/i2c/busses/i2c-mt65xx.c | 328 +++++++++++++++++++++++++++++++++-------
> > > > 1 file changed, 277 insertions(+), 51 deletions(-)
> > > >
> > > > diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> > > > index 0ca6c38a..7020618 100644
> > > > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > > > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> > >
> > > > +/*
> > > > + * Check and Calculate i2c ac-timing
> > > > + *
> > > > + * Hardware design:
> > > > + * sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src
> > > > + * xxx_cnt_div = spec->min_xxx_ns / sample_ns
> > > > + *
> > > > + * Sample_ns is rounded down for xxx_cnt_div would be greater
> > > > + * than the smallest spec.
> > > > + * The sda_timing is chosen as the middle value between
> > > > + * the largest and smallest.
> > > > + */
> > > > +static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
> > > > + unsigned int clk_src,
> > > > + unsigned int check_speed,
> > > > + unsigned int step_cnt,
> > > > + unsigned int sample_cnt)
> > > > +{
> > > > + const struct i2c_spec_values *spec;
> > > > + unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt;
> > > > + unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f;
> > > > + long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
> > >
> > > So sample_ns is a 64-bit value. Is that really needed?
> > >
> >
> > (1000000000 * (sample_cnt + 1)) / clk_src value is a 32-bit, (1000000000
> > * (sample_cnt + 1)) will over 32-bit if sample_cnt is 7.
>
> The intermediate value will indeed not fit in 32-bit.
> But that doesn't mean the end result won't fit in 32-bit.
> As you divide spec->min_low_ns and spec->min_su_dat_ns (which I assume
> are small numbers) by sample_ns below, sample_ns cannot be very large,
> or the quotient will be zero anyway.
> So just doing the multiplication in 64-bit, followed by a 64-by-32
> division is probably fine:
>
> unsigned int sample_ns = div_u64(1000000000ULL * (sample_cnt + 1), clk_src);
>
> You may want to take precautions for the case where the passed value of
> clk_src is a small number (can that happen?).
>
> BTW, clk_get_rate() returns "unsigned long", while mtk_i2c_set_speed()
> takes an "unsigned int" parent_clk, which may cause future issues.
> You may want to change that to "unsigned long", along the whole
> propagation path, and use div64_ul() instead of div_u64() above.
>
The return type of div_u64 is u64(unsigned long long), there is a
compulsory type conversion operator. Do you think it is needed?
BTW, we just need to change the type of sample_ns to unsigned int, no
matter which method is used, what is your opinion?
> > I think 1000000000 and clk_src is too big, maybe I can reduce then with
> > be divided all by 1000.
> > example:
> >
> > unsigned int sample_ns;
> > unsigned int clk_src_khz = clk_src / 1000;
>
> That may cause too much loss of precision.
>
clk_src is more than MHz and less than GHZ for MTK i2c controller, so it
wouldn't cause too much loss of precision.
> >
> > if(clk_src_khz)
> > sample_ns = (1000000 * (sample_cnt + 1)) / clk_src_khz;
> > else
> > return -EINVAL;
> >
> > > > + if (!i2c->dev_comp->timing_adjust)
> > > > + return 0;
> > > > +
> > > > + if (i2c->dev_comp->ltiming_adjust)
> > > > + max_sta_cnt = 0x100;
> > > > +
> > > > + spec = mtk_i2c_get_spec(check_speed);
> > > > +
> > > > + if (i2c->dev_comp->ltiming_adjust)
> > > > + clk_ns = 1000000000 / clk_src;
> > > > + else
> > > > + clk_ns = sample_ns / 2;
> > > > +
> > > > + su_sta_cnt = DIV_ROUND_UP(spec->min_su_sta_ns, clk_ns);
> > > > + if (su_sta_cnt > max_sta_cnt)
> > > > + return -1;
> > > > +
> > > > + low_cnt = DIV_ROUND_UP(spec->min_low_ns, sample_ns);
> > >
> > > So this is a 32-bit by 64-bit division (indeed, not 64-by-32!)
>
> Gr{oetje,eeting}s,
>
> Geert
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: BUG: sleeping function called from atomic due to "Balance initial LPI affinity across CPUs"
From: John Garry @ 2020-05-20 8:43 UTC (permalink / raw)
To: Qian Cai, Marc Zyngier, Stephen Rothwell
Cc: Thomas Gleixner, Linux Next Mailing List,
Linux Kernel Mailing List, Linux ARM
In-Reply-To: <CAG=TAF6hJL-wfGLq3oa-ZGk3-YGEtuMyO2V9ePFUcbv99NWVSw@mail.gmail.com>
On 19/05/2020 23:09, Qian Cai wrote:
> Reverted the linux-next commit f068a62c548c ("irqchip/gic-v3-its:
> Balance initial LPI affinity across CPUs") fixed these warnings during
> boot,
Thanks for the notice. So we need the following set to see this:
CONFIG_CPUMASK_OFFSTACK=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_DEBUG_PER_CPU_MAPS=y
>
> its_select_cpu at drivers/irqchip/irq-gic-v3-its.c:1572
>
> [ 332.819381][ T3359] BUG: sleeping function called from invalid
> context at mm/slab.h:568
> [ 332.827405][ T3359] in_atomic(): 1, irqs_disabled(): 128,
> non_block: 0, pid: 3359, name: irqbalance
> [ 332.836455][ T3359] INFO: lockdep is turned off.
> [ 332.841076][ T3359] irq event stamp: 0
> [ 332.844836][ T3359] hardirqs last enabled at (0): [<0000000000000000>] 0x0
> [ 332.851828][ T3359] hardirqs last disabled at (0):
> [<ffff9000101ea65c>] copy_process+0x98c/0x1f34
> [ 332.860710][ T3359] softirqs last enabled at (0):
> [<ffff9000101ea690>] copy_process+0x9c0/0x1f34
> [ 332.869586][ T3359] softirqs last disabled at (0): [<0000000000000000>] 0x0
> [ 332.876560][ T3359] CPU: 155 PID: 3359 Comm: irqbalance Tainted: G
> W L 5.7.0-rc6-next-20200519 #1
> [ 332.886563][ T3359] Hardware name: HPE Apollo 70
> /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
> [ 332.897000][ T3359] Call trace:
> [ 332.900151][ T3359] dump_backtrace+0x0/0x22c
> [ 332.904514][ T3359] show_stack+0x28/0x34
> [ 332.908543][ T3359] dump_stack+0x104/0x194
> [ 332.912738][ T3359] ___might_sleep+0x314/0x328
> [ 332.917274][ T3359] __might_sleep+0x7c/0xe0
> [ 332.921563][ T3359] slab_pre_alloc_hook+0x44/0x8c
> [ 332.926360][ T3359] __kmalloc_node+0xb0/0x618
> [ 332.930811][ T3359] alloc_cpumask_var_node+0x48/0x94
We could use GFP_ATOMIC flag at the callsite here, but maybe there is a
better solution.
> [ 332.935868][ T3359] alloc_cpumask_var+0x10/0x1c
> [ 332.940496][ T3359] its_select_cpu+0x58/0x2e4
> [ 332.944945][ T3359] its_set_affinity+0xe8/0x27c
> [ 332.949576][ T3359] msi_domain_set_affinity+0x78/0x114
> [ 332.954813][ T3359] irq_do_set_affinity+0x84/0x198
> [ 332.959697][ T3359] irq_set_affinity_locked+0x80/0x1a8
> [ 332.964927][ T3359] __irq_set_affinity+0x54/0x84
> [ 332.969637][ T3359] write_irq_affinity+0x16c/0x198
> [ 332.974520][ T3359] irq_affinity_proc_write+0x34/0x44
> [ 332.979672][ T3359] pde_write+0x5c/0x78
> [ 332.983602][ T3359] proc_reg_write+0x74/0xc0
> [ 332.987974][ T3359] __vfs_write+0x84/0x1d8
> [ 332.992163][ T3359] vfs_write+0x13c/0x1b8
> [ 332.996265][ T3359] ksys_write+0xb0/0x120
> [ 333.000385][ T3359] __arm64_sys_write+0x54/0x88
> [ 333.005017][ T3359] do_el0_svc+0x128/0x1dc
> [ 333.009213][ T3359] el0_sync_handler+0xd0/0x268
> [ 333.013836][ T3359] el0_sync+0x164/0x180
> [ 336.527739][ T3356] mlx5_core 0000:0b:00.1 enp11s0f1np1: Link down
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] mfd: stm32-timers: Use dma_request_chan() instead dma_request_slave_channel()
From: Lee Jones @ 2020-05-20 8:49 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: alexandre.torgue, linux-kernel, vkoul, mcoquelin.stm32,
fabrice.gasnier, linux-stm32, linux-arm-kernel
In-Reply-To: <20200107105959.18920-1-peter.ujfalusi@ti.com>
On Tue, 07 Jan 2020, Peter Ujfalusi wrote:
> dma_request_slave_channel() is a wrapper on top of dma_request_chan()
> eating up the error code.
>
> By using dma_request_chan() directly the driver can support deferred
> probing against DMA.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> Hi,
>
> Changes since v1:
> - Fall back to PIO mode only in case of ENODEV and report all other errors
>
> Regards,
> Peter
>
> drivers/mfd/stm32-timers.c | 32 +++++++++++++++++++++++---------
> 1 file changed, 23 insertions(+), 9 deletions(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: mfd: Convert stmfx bindings to json-schema
From: Lee Jones @ 2020-05-20 8:51 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: mark.rutland, devicetree, amelie.delaunay, alexandre.torgue,
linus.walleij, linux-kernel, linux-gpio, robh+dt, linux-stm32,
linux-arm-kernel
In-Reply-To: <20200220162246.8334-1-benjamin.gaignard@st.com>
On Thu, 20 Feb 2020, Benjamin Gaignard wrote:
> Convert stmfx bindings to json-schema
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/mfd/st,stmfx.yaml | 124 +++++++++++++++++++++
> Documentation/devicetree/bindings/mfd/stmfx.txt | 28 -----
> .../devicetree/bindings/pinctrl/pinctrl-stmfx.txt | 116 -------------------
Linus, anything from you?
> 3 files changed, 124 insertions(+), 144 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/st,stmfx.yaml
> delete mode 100644 Documentation/devicetree/bindings/mfd/stmfx.txt
> delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-stmfx.txt
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Clarification on necessary barriers before generating IPI
From: Linu Cherian @ 2020-05-20 8:53 UTC (permalink / raw)
To: Will Deacon; +Cc: maz, Linu Cherian, linux-arm-kernel
In-Reply-To: <20200520082856.GA24293@willie-the-truck>
Hi Will,
On Wed, May 20, 2020 at 1:59 PM Will Deacon <will@kernel.org> wrote:
>
> On Wed, May 20, 2020 at 01:38:24PM +0530, Linu Cherian wrote:
> > How is it ensured that system register write using msr instruction(gic_send_sgi)
> > doesnt get reordered before the stores to IPI call processing
> > list(call_single_queue in kernel/smp.c), so that IPI is guaranteed to
> > be generated after the stores get completed.
>
> I think the flow is:
>
> <store to memory>
> DSB ST
Dont we need an extra ISB here to ensure that the subsequent MSR SGI1R doesnt
get executed before <store to memory> and DSB ST ?
This is on the assumption that DSB ST doesnt enforce the ordering of MSR SGI1R.
> MSR SGI1R
> ISB
>
> and then on the receiver:
>
> <interrupt; implicit ISB/context sync>
> MRS IAR
> DSB SY
> <control dependency>
> MSR EOIR
> ISB
> <handle IPI>
>
> > CMIIW, Dont we need an isb() in addition to to the wmb() in the below code ?
>
> There is an isb?() in the code, after the loop. Are you saying it should be
> somewhere else? If so, why?
Please see above.
>
> Will
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6] arm64: Expose FAR_EL1 tag bits in sigcontext
From: Will Deacon @ 2020-05-20 8:55 UTC (permalink / raw)
To: Peter Collingbourne
Cc: Andrey Konovalov, Kevin Brodsky, Kostya Serebryany,
Evgenii Stepanov, Catalin Marinas, Vincenzo Frascino, Dave Martin,
Linux ARM, Richard Henderson
In-Reply-To: <CAMn1gO4c3-hG_i6ZWsk-+oUGQQBdzFJRMrpehT3OFERF2Z7nrg@mail.gmail.com>
On Tue, May 19, 2020 at 03:00:12PM -0700, Peter Collingbourne wrote:
> On Mon, May 18, 2020 at 2:53 AM Dave Martin <Dave.Martin@arm.com> wrote:
> > On Thu, May 14, 2020 at 05:58:21PM -0700, Peter Collingbourne wrote:
> > > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> > > index baa88dc02e5c..5867f2fdbe64 100644
> > > --- a/arch/arm64/kernel/signal.c
> > > +++ b/arch/arm64/kernel/signal.c
> > > @@ -648,6 +648,7 @@ static int setup_sigframe(struct
> > > rt_sigframe_user_layout *user,
> > > __put_user_error(ESR_MAGIC, &esr_ctx->head.magic, err);
> > > __put_user_error(sizeof(*esr_ctx), &esr_ctx->head.size, err);
> > > __put_user_error(current->thread.fault_code,
> > > &esr_ctx->esr, err);
> > > + current->thread.fault_code = 0;
> >
> > Perhaps, but we'd need to be careful. For example, can we run out of
> > user stack before this and deliver a SIGSEGV, but with the old
> > fault_code still set? Then we'd emit the old fault code with the
> > new "can't deliver signal" signal, which doesn't make sense.
> >
> > Stuff may also go wrong with signal prioritisation.
> >
> > If a higher-priority signal (say SIGINT) comes in after a data abort
> > enters the kernel but before the resulting SIGSEGV is dequeued for
> > delivery, wouldn't we deliver SIGINT first, with the bogus fault code?
> > With your change we'd then have cleared the fault code by the time we
> > deliver the SIGSEGV it actually relates to, if I've understood right.
> >
> > Today, I think we just attach that fault code to every signal that's
> > delivered until something overwrites or resets it, which means that
> > a signal that needs fault_code gets it, at the expense of attaching
> > it to a bunch of other random signals too.
> >
> >
> > Checking the signal number and si_code might help us to know what we
> > should be doing with fault_code. We need to have sure userspace can't
> > trick us with a non kernel generated signal here. It would also be
> > necessary to check how PTRACE_SETSIGINFO interacts with this.
>
> With these possible interactions in mind I think we should store the
> fault code and fault address in kernel_siginfo instead of
> thread_struct (and clear these fields when we receive a siginfo from
> userspace, i.e. in copy_siginfo_from_user which is used by
> ptrace(PTRACE_SETSIGINFO) among other places). That way, the
> information is clearly associated with the signal itself and not the
> thread, so we don't need to worry about our signal being delivered out
> of order.
Hmm, I can't see a way to do that that isn't horribly invasive in the core
signal code. Can you?
But generally, I agree: the per-thread handling of fault_address and
fault_code appears to be quite broken in the face of signal prioritisation
and signals that don't correspond directly to hardware trap. It would be
nice to have some tests for this...
If we want to pile on more bodges, perhaps we could stash the signal number
to which the fault_{address,code} relate, and then check that at delivery
and clear on a match. I hate it.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 09/19] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
From: Pratyush Yadav @ 2020-05-20 8:55 UTC (permalink / raw)
To: masonccyang
Cc: Alexandre Belloni, Vignesh Raghavendra, Tudor Ambarus, juliensu,
Richard Weinberger, Mark Brown, Sekhar Nori, linux-kernel,
linux-spi, Ludovic Desroches, Boris Brezillon, linux-mediatek,
Miquel Raynal, Matthias Brugger, linux-mtd, linux-arm-kernel
In-Reply-To: <OF83616464.480FA751-ON4825856E.002A4483-4825856E.002BE6AF@mxic.com.tw>
Hi Mason,
On 20/05/20 03:59PM, masonccyang@mxic.com.tw wrote:
>
> Hi Pratyush,
>
> > +/**
> > + * spi_nor_parse_profile1() - parse the xSPI Profile 1.0 table
> > + * @nor: pointer to a 'struct spi_nor'
> > + * @param_header: pointer to the 'struct sfdp_parameter_header'
> describing
> > + * the 4-Byte Address Instruction Table length and version.
> > + * @params: pointer to the 'struct spi_nor_flash_parameter' to be.
> > + *
> > + * Return: 0 on success, -errno otherwise.
> > + */
> > +static int spi_nor_parse_profile1(struct spi_nor *nor,
> > + const struct sfdp_parameter_header *profile1_header,
> > + struct spi_nor_flash_parameter *params)
> > +{
> > + u32 *table, opcode, addr;
> > + size_t len;
> > + int ret, i;
> > +
> > + len = profile1_header->length * sizeof(*table);
> > + table = kmalloc(len, GFP_KERNEL);
> > + if (!table)
> > + return -ENOMEM;
> > +
> > + addr = SFDP_PARAM_HEADER_PTP(profile1_header);
> > + ret = spi_nor_read_sfdp(nor, addr, len, table);
> > + if (ret)
> > + goto out;
> > +
> > + /* Fix endianness of the table DWORDs. */
> > + for (i = 0; i < profile1_header->length; i++)
> > + table[i] = le32_to_cpu(table[i]);
> > +
> > + /* Get 8D-8D-8D fast read opcode and dummy cycles. */
> > + opcode = FIELD_GET(PROFILE1_DWORD1_RD_FAST_CMD, table[0]);
> > +
> > + /*
> > + * Update the fast read settings. We set the default dummy cycles to
> 20
> > + * here. Flashes can change this value if they need to when enabling
> > + * octal mode.
> > + */
> > + spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR],
> > + 0, 20, opcode,
> > + SNOR_PROTO_8_8_8_DTR);
> > +
>
>
> I thought we have a agreement that only do parse here, no other read
> parameters setting.
Yes, and I considered it. But it didn't make much sense to me to
introduce an extra member in struct spi_nor just to make this call in
some other function later.
Why exactly do you think doing this here is bad? The way I see it, we
avoid carrying around an extra member in spi_nor and this also allows
flashes to change the read settings easily in a post-sfdp hook. The
4bait parsing function does something similar.
What are the benefits of doing it otherwise?
Note that I did remove HWCAPS selection from here, which did seem like a
sane idea.
> Driver should get dummy cycles used for various frequencies
> from 4th and 5th DWORD of xSPI table.[1]
>
> [1]
> https://patchwork.ozlabs.org/project/linux-mtd/patch/1587451187-6889-3-git-send-email-masonccyang@mxic.com.tw/
>
>
> In addition, 20 dummy cycles is for 200MHz but not for 100MHz, 133MHz and
> 166MHz
> in case of read performance concern.
>
> Given a correct dummy cycles for a specific device. [2]
>
> [2]
> https://patchwork.ozlabs.org/project/linux-mtd/patch/1587451187-6889-5-git-send-email-masonccyang@mxic.com.tw/
The problem is that we don't know what speed the controller is driving
the flash at, and whether it is using Data Strobe. BFPT tells us the
maximum speed of the flash based on if Data Strobe is being used. The
controller can also drive it slower than the maximum. And it can drive
it with or without DS.
So, we have to be conservative and just use the dummy cycles for the
maximum speed so we can at least make sure the flash works, albeit at
slightly less efficiency. I hard-coded it to 20 but I suppose we can
find it out from the Profile 1.0 table and use that (though we'd have to
round it to an even value to avoid tripping up controllers). Will fix in
next version (or, Tudor if you're fine with fixup! patches, I can send
that too because I suspect it will be a small change).
>
> > + /*
> > + * Set the Read Status Register dummy cycles and dummy address
> bytes.
> > + */
> > + if (table[0] & PROFILE1_DWORD1_RDSR_DUMMY)
> > + params->rdsr_dummy = 8;
> > + else
> > + params->rdsr_dummy = 4;
> > +
> > + if (table[0] & PROFILE1_DWORD1_RDSR_ADDR_BYTES)
> > + params->rdsr_addr_nbytes = 4;
> > + else
> > + params->rdsr_addr_nbytes = 0;
> > +
> > +out:
> > + kfree(table);
> > + return ret;
> > +}
> > +
>
--
Regards,
Pratyush Yadav
Texas Instruments India
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: sram: add documentation for reserved-only flag
From: Thierry Reding @ 2020-05-20 8:55 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, arnd, Stephen Warren, gregkh, Mian Yousaf Kaukab,
linux-kernel, jonathanh, talho, linux-tegra, robin.murphy,
afaerber, linux-arm-kernel
In-Reply-To: <20200519230326.GA827289@bogus>
[-- Attachment #1.1: Type: text/plain, Size: 5789 bytes --]
On Tue, May 19, 2020 at 05:03:26PM -0600, Rob Herring wrote:
> On Tue, May 19, 2020 at 10:16:43AM -0600, Stephen Warren wrote:
> > On 5/13/20 4:41 AM, Mian Yousaf Kaukab wrote:
> > > On Tue, May 12, 2020 at 01:45:28PM -0600, Stephen Warren wrote:
> > >> On 5/12/20 8:48 AM, Mian Yousaf Kaukab wrote:
> > >>> Add documentation for the new optional flag added for SRAM driver.
> > >>
> > >>> diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
> > >>
> > >>> + reserved-only:
> > >>> + description:
> > >>> + The flag indicating, that only SRAM reserved regions have to be remapped.
> > >>> + remapping type is selected depending upon no-memory-wc as usual.
> > >>> + type: boolean
> > >>
> > >> This feels a bit like a SW flag rather than a HW description, so I'm not
> > >> sure it's appropriate to put it into DT.
> > >
> > > Reserved regions themselves are software descriptions, no? Then we have 'pool'
> > > flag which is again a software flag and so on. This flag falls into same
> > > category and nothing out of ordinary.
> >
> > I suppose that's true to some extent. This is indeed a description of
> > the system environment presented to the SW that consumes the DT, which
> > is a bit more than pure HW description but still a description of
> > something imposed externally rather than describing something that's up
> > to the discretion of the consuming SW. So, go ahead.
> >
> > >> Are there any cases where the SW should map all of the SRAM, i.e. where
> > >> we wouldn't expect to set reserved-only? [...]
> > >
> > > Yes, here are a few examples:
> > > arch/arm/boot/dts/aspeed-g*.dtsi
> > > arch/arm/boot/dts/at91*.dtsi
> > > arch/arm/boot/dts/bcm7445.dtsi
> > > Then arch/arm/boot/dts/dra7.dtsi is an example where we should map everything
> > > except the reserved region.
> > >
> > >> [...] I'd expect reserved-only to be
> > >> the default, and perhaps only, mode of operation for the SRAM driver.
> > >
> > > It will break compatibility with existing dtbs.
> > >
> > >> If we can't do that because some SW currently expects to be able to map
> > >> arbitrary portions of the SRAM, shouldn't that SW be fixed to tell the
> > >> SRAM driver which parts it's using, hence still allowing the driver to
> > >> only map in-use portions?
> > >
> > > User doesn’t need sram driver in that case. It can use genalloc api directly.
> >
> > This sounds a bit odd. Without a driver for the reserved region, nothing
> > should be touching it, since otherwise there's no code that owns an
> > manages the region. If any code needs to consume the region, it should
> > obtain info about the region from some form of provider code that can
> > handle both the allocation and mapping. Anything else sounds like some
> > consumer code directly making use of DT nodes it doesn't own. But since
> > I'm not familiar enough with the SRAM driver and genalloc code that you
> > mention to fully understand the allocation paths I guess I won't object
> > for now, although it does still sound fishy.
>
> I'm fine with the concept, but I don't think a single flag is adequate.
> If there are reserved regions within the SRAM, then define child nodes
> to mark those regions reserved. I don't think you need a new flag. Just
> a 'reg' property and nothing else.
It sounds to me like there are two different interpretations of SRAM and
reserved regions. On one hand, as you suggest, we have one SRAM that's
made available as genalloc pool and then individual regions can be
marked as reserved so that they aren't added to that pool.
At the same time, each reserved region is also exposed as a separate
pool and that's in fact used by many consumers as a way of getting a
specific chunk of the SRAM for their own use (via phandle to the region
from the consumer's device tree node).
In addition to that, the reserved region code doesn't actually fully do
its job because while the reserved region isn't actually added to the
"top-level" SRAM pool, the memory is still mapped. At the same time this
is something that we actually want because, like I mentioned, some of
the consumers do want to get at their SRAM chunks via references to the
partitions.
The problem that this patch series is really trying to solve is another
still: the complete SRAM is always mapped to kernel memory, irrespective
of whether any regions are marked reserved or not and that can cause
speculative accesses to memory outside of the defined regions.
Stephen's suggestion is to default to only mapping memory for which a
partition has been defined in the SRAM and assuming that all SRAM
outside of those partitions is off limits. I think that's a sensible
default and it's unambiguous.
But as Yousaf points out that would break compatibility with existing
device trees. Depending on how you interpret the bindings one could
argue that those device trees are buggy and should have partitions
defined (in the cases I've looked at they end up using a fixed region
anyway, so that could've just been made explicit in the device tree).
However, it also looks like all of the users that rely on the original
behaviour where they can just access the full pool are those that don't
define any reserved regions, whereas all users that do reserve regions
will actually use those reserved regions.
So I think we can make use of this by differentiating in the driver
between SRAM nodes with or without children and change the behaviour
accordingly. I think that has the big advantage that it makes things
work as (I think) most people would expect and doesn't further
complicate the binding with extra flags.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] i2c: mediatek: Add i2c ac-timing adjust support
From: Geert Uytterhoeven @ 2020-05-20 8:58 UTC (permalink / raw)
To: Qii Wang
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
srv_heupstream, Wolfram Sang, leilk.liu,
Linux Kernel Mailing List, linux-mediatek, Linux I2C, Joe Perches,
Linux ARM
In-Reply-To: <1589964062.25512.67.camel@mhfsdcap03>
Hi Qii,
On Wed, May 20, 2020 at 10:44 AM Qii Wang <qii.wang@mediatek.com> wrote:
> On Tue, 2020-05-19 at 09:14 +0200, Geert Uytterhoeven wrote:
> > On Tue, May 19, 2020 at 4:59 AM Qii Wang <qii.wang@mediatek.com> wrote:
> > > On Mon, 2020-05-18 at 17:44 +0200, Geert Uytterhoeven wrote:
> > > > On Thu, May 14, 2020 at 3:13 PM Qii Wang <qii.wang@mediatek.com> wrote:
> > > > > This patch adds a algorithm to calculate some ac-timing parameters
> > > > > which can fully meet I2C Spec.
> > > > >
> > > > > Signed-off-by: Qii Wang <qii.wang@mediatek.com>
> > > > > ---
> > > > > drivers/i2c/busses/i2c-mt65xx.c | 328 +++++++++++++++++++++++++++++++++-------
> > > > > 1 file changed, 277 insertions(+), 51 deletions(-)
> > > > >
> > > > > diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> > > > > index 0ca6c38a..7020618 100644
> > > > > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > > > > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> > > >
> > > > > +/*
> > > > > + * Check and Calculate i2c ac-timing
> > > > > + *
> > > > > + * Hardware design:
> > > > > + * sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src
> > > > > + * xxx_cnt_div = spec->min_xxx_ns / sample_ns
> > > > > + *
> > > > > + * Sample_ns is rounded down for xxx_cnt_div would be greater
> > > > > + * than the smallest spec.
> > > > > + * The sda_timing is chosen as the middle value between
> > > > > + * the largest and smallest.
> > > > > + */
> > > > > +static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
> > > > > + unsigned int clk_src,
> > > > > + unsigned int check_speed,
> > > > > + unsigned int step_cnt,
> > > > > + unsigned int sample_cnt)
> > > > > +{
> > > > > + const struct i2c_spec_values *spec;
> > > > > + unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt;
> > > > > + unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f;
> > > > > + long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
> > > >
> > > > So sample_ns is a 64-bit value. Is that really needed?
> > > >
> > >
> > > (1000000000 * (sample_cnt + 1)) / clk_src value is a 32-bit, (1000000000
> > > * (sample_cnt + 1)) will over 32-bit if sample_cnt is 7.
> >
> > The intermediate value will indeed not fit in 32-bit.
> > But that doesn't mean the end result won't fit in 32-bit.
> > As you divide spec->min_low_ns and spec->min_su_dat_ns (which I assume
> > are small numbers) by sample_ns below, sample_ns cannot be very large,
> > or the quotient will be zero anyway.
> > So just doing the multiplication in 64-bit, followed by a 64-by-32
> > division is probably fine:
> >
> > unsigned int sample_ns = div_u64(1000000000ULL * (sample_cnt + 1), clk_src);
> >
> > You may want to take precautions for the case where the passed value of
> > clk_src is a small number (can that happen?).
> >
> > BTW, clk_get_rate() returns "unsigned long", while mtk_i2c_set_speed()
> > takes an "unsigned int" parent_clk, which may cause future issues.
> > You may want to change that to "unsigned long", along the whole
> > propagation path, and use div64_ul() instead of div_u64() above.
> >
>
> The return type of div_u64 is u64(unsigned long long), there is a
> compulsory type conversion operator. Do you think it is needed?
The result of a 64-by-32 bit division may indeed not fit in 32-bit, so that's
why it returns u64.
If you know the quotient will always fit, it's fine.
> BTW, we just need to change the type of sample_ns to unsigned int, no
> matter which method is used, what is your opinion?
Indeed.
BTW, I just realize
long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
wasn't doing what you wanted anyway, as 1000000000 is (implicit) int,
and sample_cnt is unsigned int, so the multiplication was done in 32-bit,
possible leading to a truncation. Hence that division was done in 32-bit, too,
that's why I didn't notice a call to __udivdi3() in the assembler output here.
So you have to force the multiplication to be done in 64-bit, e.g.
by changing the constant to 1000000000ULL, and use div_u64() for
the division.
>
> > > I think 1000000000 and clk_src is too big, maybe I can reduce then with
> > > be divided all by 1000.
> > > example:
> > >
> > > unsigned int sample_ns;
> > > unsigned int clk_src_khz = clk_src / 1000;
> >
> > That may cause too much loss of precision.
> >
>
> clk_src is more than MHz and less than GHZ for MTK i2c controller, so it
> wouldn't cause too much loss of precision.
OK, so that would work, too.
> > >
> > > if(clk_src_khz)
> > > sample_ns = (1000000 * (sample_cnt + 1)) / clk_src_khz;
> > > else
> > > return -EINVAL;
> > >
> > > > > + if (!i2c->dev_comp->timing_adjust)
> > > > > + return 0;
> > > > > +
> > > > > + if (i2c->dev_comp->ltiming_adjust)
> > > > > + max_sta_cnt = 0x100;
> > > > > +
> > > > > + spec = mtk_i2c_get_spec(check_speed);
> > > > > +
> > > > > + if (i2c->dev_comp->ltiming_adjust)
> > > > > + clk_ns = 1000000000 / clk_src;
> > > > > + else
> > > > > + clk_ns = sample_ns / 2;
> > > > > +
> > > > > + su_sta_cnt = DIV_ROUND_UP(spec->min_su_sta_ns, clk_ns);
> > > > > + if (su_sta_cnt > max_sta_cnt)
> > > > > + return -1;
> > > > > +
> > > > > + low_cnt = DIV_ROUND_UP(spec->min_low_ns, sample_ns);
> > > >
> > > > So this is a 32-bit by 64-bit division (indeed, not 64-by-32!)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/6] mfd: add support for the Khadas System control Microcontroller
From: Lee Jones @ 2020-05-20 9:01 UTC (permalink / raw)
To: Neil Armstrong; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <20200512132613.31507-3-narmstrong@baylibre.com>
On Tue, 12 May 2020, Neil Armstrong wrote:
> This Microcontroller is present on the Khadas VIM1, VIM2, VIM3 and Edge
> boards.
>
> It has multiple boot control features like password check, power-on
> options, power-off control and system FAN control on recent boards.
>
> This implements a very basic MFD driver with the fan control and User
> NVMEM cells.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/mfd/Kconfig | 14 ++++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/khadas-mcu.c | 143 +++++++++++++++++++++++++++++++++
> include/linux/mfd/khadas-mcu.h | 91 +++++++++++++++++++++
> 4 files changed, 249 insertions(+)
> create mode 100644 drivers/mfd/khadas-mcu.c
> create mode 100644 include/linux/mfd/khadas-mcu.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 0a59249198d3..b95091397052 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2003,6 +2003,20 @@ config MFD_WCD934X
> This driver provides common support WCD934x audio codec and its
> associated Pin Controller, Soundwire Controller and Audio codec.
>
> +config MFD_KHADAS_MCU
> + tristate "Support for Khadas System control Microcontroller"
> + depends on I2C
> + depends on OF || COMPILE_TEST
> + select MFD_CORE
> + select REGMAP_I2C
> + help
> + Support for the Khadas System control Microcontroller interface present
> + on their VIM and Edge boards.
> +
> + This driver provides common support for accessing the device,
> + additional drivers must be enabled in order to use the functionality
> + of the device.
It would be good to describe the device here.
> menu "Multimedia Capabilities Port drivers"
> depends on ARCH_SA1100
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index f935d10cbf0f..0f1633b096bb 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -257,5 +257,6 @@ obj-$(CONFIG_MFD_ROHM_BD70528) += rohm-bd70528.o
> obj-$(CONFIG_MFD_ROHM_BD71828) += rohm-bd71828.o
> obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
> obj-$(CONFIG_MFD_STMFX) += stmfx.o
> +obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o
>
> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
> diff --git a/drivers/mfd/khadas-mcu.c b/drivers/mfd/khadas-mcu.c
> new file mode 100644
> index 000000000000..6d08fa2e373a
> --- /dev/null
> +++ b/drivers/mfd/khadas-mcu.c
> @@ -0,0 +1,143 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for Khadas System control Microcontroller
> + *
> + * Copyright (C) 2020 BayLibre SAS
Nit: '\n' here please.
> + * Author(s): Neil Armstrong <narmstrong@baylibre.com>
> + */
> +#include <linux/bitfield.h>
> +#include <linux/i2c.h>
> +#include <linux/mfd/khadas-mcu.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
Alphabetical.
> +static bool khadas_mcu_reg_volatile(struct device *dev, unsigned int reg)
> +{
> + if (reg >= KHADAS_MCU_USER_DATA_0_REG &&
> + reg < KHADAS_MCU_PWR_OFF_CMD_REG)
> + return true;
> +
> + switch (reg) {
> + case KHADAS_MCU_PWR_OFF_CMD_REG:
> + case KHADAS_MCU_PASSWD_START_REG:
> + case KHADAS_MCU_CHECK_VEN_PASSWD_REG:
> + case KHADAS_MCU_CHECK_USER_PASSWD_REG:
> + case KHADAS_MCU_WOL_INIT_START_REG:
> + case KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static bool khadas_mcu_reg_writeable(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case KHADAS_MCU_PASSWD_VEN_0_REG:
> + case KHADAS_MCU_PASSWD_VEN_1_REG:
> + case KHADAS_MCU_PASSWD_VEN_2_REG:
> + case KHADAS_MCU_PASSWD_VEN_3_REG:
> + case KHADAS_MCU_PASSWD_VEN_4_REG:
> + case KHADAS_MCU_PASSWD_VEN_5_REG:
> + case KHADAS_MCU_MAC_0_REG:
> + case KHADAS_MCU_MAC_1_REG:
> + case KHADAS_MCU_MAC_2_REG:
> + case KHADAS_MCU_MAC_3_REG:
> + case KHADAS_MCU_MAC_4_REG:
> + case KHADAS_MCU_MAC_5_REG:
> + case KHADAS_MCU_USID_0_REG:
> + case KHADAS_MCU_USID_1_REG:
> + case KHADAS_MCU_USID_2_REG:
> + case KHADAS_MCU_USID_3_REG:
> + case KHADAS_MCU_USID_4_REG:
> + case KHADAS_MCU_USID_5_REG:
> + case KHADAS_MCU_VERSION_0_REG:
> + case KHADAS_MCU_VERSION_1_REG:
> + case KHADAS_MCU_DEVICE_NO_0_REG:
> + case KHADAS_MCU_DEVICE_NO_1_REG:
> + case KHADAS_MCU_FACTORY_TEST_REG:
> + case KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG:
> + return false;
> + default:
> + return true;
> + }
> +}
> +
> +static const struct regmap_config khadas_mcu_regmap_config = {
> + .reg_bits = 8,
> + .reg_stride = 1,
> + .val_bits = 8,
> + .max_register = KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
> + .volatile_reg = khadas_mcu_reg_volatile,
> + .writeable_reg = khadas_mcu_reg_writeable,
> + .cache_type = REGCACHE_RBTREE,
> +};
> +
> +static struct mfd_cell khadas_mcu_fan_cells[] = {
> + /* Feature supported only on VIM1/2 Rev13+ and VIM3 */
Doesn't read great.
Consider reversing or make the sentence more succinct.
"VIM1/2 Rev13+ and VIM3 only"
> + { .name = "khadas-mcu-fan-ctrl", },
> +};
> +
> +static struct mfd_cell khadas_mcu_cells[] = {
> + /* Features supported on all board revisions */
I think we can omit this.
> + { .name = "khadas-mcu-user-mem", },
> +};
> +
> +static int khadas_mcu_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = &client->dev;
> + struct khadas_mcu *khadas_mcu;
Prefer a rename to 'ddata'.
> + int ret;
> +
> + khadas_mcu = devm_kzalloc(dev, sizeof(*khadas_mcu), GFP_KERNEL);
> + if (!khadas_mcu)
> + return -ENOMEM;
> +
> + i2c_set_clientdata(client, khadas_mcu);
> +
> + khadas_mcu->dev = dev;
> +
> + khadas_mcu->map = devm_regmap_init_i2c(client,
> + &khadas_mcu_regmap_config);
Prefer a rename to 'regmap'.
> + if (IS_ERR(khadas_mcu->map)) {
> + ret = PTR_ERR(khadas_mcu->map);
> + dev_err(dev, "Failed to allocate register map: %d\n", ret);
> + return ret;
> + }
> +
> + ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
> + khadas_mcu_cells,
> + ARRAY_SIZE(khadas_mcu_cells),
> + NULL, 0, NULL);
> + if (ret)
> + return ret;
> +
> + if (of_find_property(dev->of_node, "#cooling-cells", NULL))
> + return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
> + khadas_mcu_fan_cells,
> + ARRAY_SIZE(khadas_mcu_fan_cells),
> + NULL, 0, NULL);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id khadas_mcu_of_match[] = {
> + { .compatible = "khadas,mcu", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, khadas_mcu_of_match);
> +
> +static struct i2c_driver khadas_mcu_driver = {
> + .driver = {
> + .name = "khadas-mcu-core",
> + .of_match_table = of_match_ptr(khadas_mcu_of_match),
> + },
> + .probe = khadas_mcu_probe,
> +};
> +module_i2c_driver(khadas_mcu_driver);
> +
> +MODULE_DESCRIPTION("Khadas MCU core driver");
> +MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/mfd/khadas-mcu.h b/include/linux/mfd/khadas-mcu.h
> new file mode 100644
> index 000000000000..2e68af21735c
> --- /dev/null
> +++ b/include/linux/mfd/khadas-mcu.h
> @@ -0,0 +1,91 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Khadas System control Microcontroller Register map
> + *
> + * Copyright (C) 2020 BayLibre SAS
Nit: '\n'
> + * Author(s): Neil Armstrong <narmstrong@baylibre.com>
> + */
> +
> +#ifndef MFD_KHADAS_MCU_H
> +#define MFD_KHADAS_MCU_H
> +
> +#define KHADAS_MCU_PASSWD_VEN_0_REG 0x0 /* RO */
Nit: Can you pad these please?
> +#define KHADAS_MCU_PASSWD_VEN_1_REG 0x1 /* RO */
> +#define KHADAS_MCU_PASSWD_VEN_2_REG 0x2 /* RO */
> +#define KHADAS_MCU_PASSWD_VEN_3_REG 0x3 /* RO */
> +#define KHADAS_MCU_PASSWD_VEN_4_REG 0x4 /* RO */
> +#define KHADAS_MCU_PASSWD_VEN_5_REG 0x5 /* RO */
> +#define KHADAS_MCU_MAC_0_REG 0x6 /* RO */
> +#define KHADAS_MCU_MAC_1_REG 0x7 /* RO */
> +#define KHADAS_MCU_MAC_2_REG 0x8 /* RO */
> +#define KHADAS_MCU_MAC_3_REG 0x9 /* RO */
> +#define KHADAS_MCU_MAC_4_REG 0xa /* RO */
> +#define KHADAS_MCU_MAC_5_REG 0xb /* RO */
> +#define KHADAS_MCU_USID_0_REG 0xc /* RO */
> +#define KHADAS_MCU_USID_1_REG 0xd /* RO */
> +#define KHADAS_MCU_USID_2_REG 0xe /* RO */
> +#define KHADAS_MCU_USID_3_REG 0xf /* RO */
> +#define KHADAS_MCU_USID_4_REG 0x10 /* RO */
> +#define KHADAS_MCU_USID_5_REG 0x11 /* RO */
> +#define KHADAS_MCU_VERSION_0_REG 0x12 /* RO */
> +#define KHADAS_MCU_VERSION_1_REG 0x13 /* RO */
> +#define KHADAS_MCU_DEVICE_NO_0_REG 0x14 /* RO */
> +#define KHADAS_MCU_DEVICE_NO_1_REG 0x15 /* RO */
> +#define KHADAS_MCU_FACTORY_TEST_REG 0x16 /* R */
> +#define KHADAS_MCU_BOOT_MODE_REG 0x20 /* RW */
> +#define KHADAS_MCU_BOOT_EN_WOL_REG 0x21 /* RW */
> +#define KHADAS_MCU_BOOT_EN_RTC_REG 0x22 /* RW */
> +#define KHADAS_MCU_BOOT_EN_EXP_REG 0x23 /* RW */
> +#define KHADAS_MCU_BOOT_EN_IR_REG 0x24 /* RW */
> +#define KHADAS_MCU_BOOT_EN_DCIN_REG 0x25 /* RW */
> +#define KHADAS_MCU_BOOT_EN_KEY_REG 0x26 /* RW */
> +#define KHADAS_MCU_KEY_MODE_REG 0x27 /* RW */
> +#define KHADAS_MCU_LED_MODE_ON_REG 0x28 /* RW */
> +#define KHADAS_MCU_LED_MODE_OFF_REG 0x29 /* RW */
> +#define KHADAS_MCU_SHUTDOWN_NORMAL_REG 0x2c /* RW */
> +#define KHADAS_MCU_MAC_SWITCH_REG 0x2d /* RW */
> +#define KHADAS_MCU_MCU_SLEEP_MODE_REG 0x2e /* RW */
> +#define KHADAS_MCU_IR_CODE1_0_REG 0x2f /* RW */
> +#define KHADAS_MCU_IR_CODE1_1_REG 0x30 /* RW */
> +#define KHADAS_MCU_IR_CODE1_2_REG 0x31 /* RW */
> +#define KHADAS_MCU_IR_CODE1_3_REG 0x32 /* RW */
> +#define KHADAS_MCU_USB_PCIE_SWITCH_REG 0x33 /* RW */
> +#define KHADAS_MCU_IR_CODE2_0_REG 0x34 /* RW */
> +#define KHADAS_MCU_IR_CODE2_1_REG 0x35 /* RW */
> +#define KHADAS_MCU_IR_CODE2_2_REG 0x36 /* RW */
> +#define KHADAS_MCU_IR_CODE2_3_REG 0x37 /* RW */
> +#define KHADAS_MCU_PASSWD_USER_0_REG 0x40 /* RW */
> +#define KHADAS_MCU_PASSWD_USER_1_REG 0x41 /* RW */
> +#define KHADAS_MCU_PASSWD_USER_2_REG 0x42 /* RW */
> +#define KHADAS_MCU_PASSWD_USER_3_REG 0x43 /* RW */
> +#define KHADAS_MCU_PASSWD_USER_4_REG 0x44 /* RW */
> +#define KHADAS_MCU_PASSWD_USER_5_REG 0x45 /* RW */
> +#define KHADAS_MCU_USER_DATA_0_REG 0x46 /* RW 56 bytes */
> +#define KHADAS_MCU_PWR_OFF_CMD_REG 0x80 /* WO */
> +#define KHADAS_MCU_PASSWD_START_REG 0x81 /* WO */
> +#define KHADAS_MCU_CHECK_VEN_PASSWD_REG 0x82 /* WO */
> +#define KHADAS_MCU_CHECK_USER_PASSWD_REG 0x83 /* WO */
> +#define KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG 0x86 /* RO */
> +#define KHADAS_MCU_WOL_INIT_START_REG 0x87 /* WO */
> +#define KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG 0x88 /* WO */
> +
> +/* Boards */
I think the names make this superfluous.
> +enum {
> + KHADAS_BOARD_VIM1 = 0x1,
> + KHADAS_BOARD_VIM2,
> + KHADAS_BOARD_VIM3,
> + KHADAS_BOARD_EDGE = 0x11,
> + KHADAS_BOARD_EDGE_V,
> +};
> +
> +/**
> + * struct khadas_mcu_data - Khadas MCU MFD structure
Doesn't match the struct name.
Prefer you drop the 'MFD' part.
> + * @device: device reference used for logs
> + * @map: register map
> + */
> +struct khadas_mcu {
> + struct device *dev;
> + struct regmap *map;
> +};
> +
> +#endif /* MFD_KHADAS_MCU_H */
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Clarification on necessary barriers before generating IPI
From: Will Deacon @ 2020-05-20 9:03 UTC (permalink / raw)
To: Linu Cherian; +Cc: maz, Linu Cherian, linux-arm-kernel
In-Reply-To: <CAAHhmWhum+s5OopKMcNOqvGN5aYek-BJRseN8wS47LiH+hJcKg@mail.gmail.com>
On Wed, May 20, 2020 at 02:23:25PM +0530, Linu Cherian wrote:
> On Wed, May 20, 2020 at 1:59 PM Will Deacon <will@kernel.org> wrote:
> >
> > On Wed, May 20, 2020 at 01:38:24PM +0530, Linu Cherian wrote:
> > > How is it ensured that system register write using msr instruction(gic_send_sgi)
> > > doesnt get reordered before the stores to IPI call processing
> > > list(call_single_queue in kernel/smp.c), so that IPI is guaranteed to
> > > be generated after the stores get completed.
> >
> > I think the flow is:
> >
> > <store to memory>
> > DSB ST
>
> Dont we need an extra ISB here to ensure that the subsequent MSR SGI1R doesnt
> get executed before <store to memory> and DSB ST ?
>
> This is on the assumption that DSB ST doesnt enforce the ordering of MSR SGI1R.
I don't think that's a valid assumption. The architecture says:
| A DSB instruction executed by a PE, PEe, completes when [...] all explicit
| memory accesses of the required access types appearing in program order
| before the DSB are complete for the set of observers in the required
| shareability domain.
and:
| In addition, no instruction that appears in program order after the DSB
| instruction can alter any state of the system or perform any part of its
| functionality until the DSB completes other than:
|
| * Being fetched from memory and decoded.
| * Reading the general-purpose, SIMD and floating-point, Special-purpose, or
| System registers that are directly or indirectly read without causing
| side-effects.
Are you seeing a problem in practice?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value
From: Lukasz Stelmach @ 2020-05-20 9:10 UTC (permalink / raw)
To: Stephan Mueller
Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger,
Greg Kroah-Hartman, Matt Mackall, linux-kernel,
Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz,
Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui,
bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel,
linux-crypto
In-Reply-To: <1748331.j7eDFAdTc1@tauon.chronox.de>
[-- Attachment #1.1: Type: text/plain, Size: 1476 bytes --]
It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote:
> Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach:
>
>> The value was estimaded with ea_iid[1] using on 10485760 bytes read from
>> the RNG via /dev/hwrng. The min-entropy value calculated using the most
>> common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464.
>
> I am sorry, but I think I did not make myself clear: testing random numbers
> post-processing with the statistical tools does NOT give any idea about the
> entropy rate. Thus, all that was calculated is the proper implementation of
> the post-processing operation and not the actual noise source.
>
> What needs to happen is that we need access to raw, unconditioned data from
> the noise source that is analyzed with the statistical methods.
I did understand you and I assure you the data I tested were obtained
directly from RNGs. As I pointed before[1], that is how /dev/hwrng
works[2].
If I am wrong, do show me the code that processes the data from a HW RNG
before copying them to user provided buffer[3].
[1] https://lkml.org/lkml/2020/5/15/252
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/hw_random.rst?h=v5.6
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/hw_random/core.c?h=v5.6#n251
Kind regards,
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value
From: Stephan Mueller @ 2020-05-20 9:18 UTC (permalink / raw)
To: Lukasz Stelmach
Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger,
Greg Kroah-Hartman, Matt Mackall, linux-kernel,
Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz,
Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui,
bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel,
linux-crypto
In-Reply-To: <dleftjr1vf2cqf.fsf%l.stelmach@samsung.com>
Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach:
Hi Lukasz,
> It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote:
> > Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach:
> >> The value was estimaded with ea_iid[1] using on 10485760 bytes read from
> >> the RNG via /dev/hwrng. The min-entropy value calculated using the most
> >> common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464.
> >
> > I am sorry, but I think I did not make myself clear: testing random
> > numbers
> > post-processing with the statistical tools does NOT give any idea about
> > the
> > entropy rate. Thus, all that was calculated is the proper implementation
> > of
> > the post-processing operation and not the actual noise source.
> >
> > What needs to happen is that we need access to raw, unconditioned data
> > from
> > the noise source that is analyzed with the statistical methods.
>
> I did understand you and I assure you the data I tested were obtained
> directly from RNGs. As I pointed before[1], that is how /dev/hwrng
> works[2].
I understand that /dev/hwrng pulls the data straight from the hardware. But
the data from the hardware usually is not obtained straight from the noise
source.
Typically you have a noise source (e.g. a ring oscillator) whose data is
digitized then fed into a compression function like an LFSR or a hash. Then a
cryptographic operation like a CBC-MAC, hash or even a DRBG is applied to that
data when the caller wants to have random numbers.
In order to estimate entropy, we need the raw unconditioned data from the,
say, ring oscillator and not from the (cryptographic) output operation.
That said, the illustrated example is typical for hardware RNGs. Yet it is
never guaranteed to work that way. Thus, if you can point to architecture
documentation of your specific hardware RNGs showing that the data read from
the hardware is pure unconditioned noise data, then I have no objections to
the patch.
>
> If I am wrong, do show me the code that processes the data from a HW RNG
> before copying them to user provided buffer[3].
I am not talking about any software post-processing. I am talking about post-
processing within the hardware.
>
> [1] https://lkml.org/lkml/2020/5/15/252
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc
> umentation/admin-guide/hw_random.rst?h=v5.6 [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri
> vers/char/hw_random/core.c?h=v5.6#n251
>
> Kind regards,
Ciao
Stephan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 01/14] dt-bindings: arm: add a binding document for MediaTek PERICFG controller
From: Bartosz Golaszewski @ 2020-05-20 9:19 UTC (permalink / raw)
To: Rob Herring
Cc: Edwin Peer, devicetree, Stephane Le Provost, Arnd Bergmann,
Bartosz Golaszewski, netdev, Sean Wang, Linux Kernel Mailing List,
David S . Miller, Fabien Parent, Pedro Tsai,
moderated list:ARM/Mediatek SoC..., Andrew Perepech, John Crispin,
Matthias Brugger, Jakub Kicinski, Mark Lee, Linux ARM,
Heiner Kallweit
In-Reply-To: <20200519182831.GA418402@bogus>
wt., 19 maj 2020 o 20:28 Rob Herring <robh@kernel.org> napisał(a):
>
> On Mon, May 11, 2020 at 05:07:46PM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > This adds a binding document for the PERICFG controller present on
> > MediaTek SoCs. For now the only variant supported is 'mt8516-pericfg'.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > ---
> > .../arm/mediatek/mediatek,pericfg.yaml | 34 +++++++++++++++++++
> > 1 file changed, 34 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
> > new file mode 100644
> > index 000000000000..74b2a6173ffb
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
> > @@ -0,0 +1,34 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml#"
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> > +
> > +title: MediaTek Peripheral Configuration Controller
> > +
> > +maintainers:
> > + - Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > +
> > +properties:
> > + compatible:
> > + oneOf:
>
> Don't need oneOf here.
>
> > + - items:
> > + - enum:
> > + - mediatek,pericfg
>
> Doesn't match the example (which is correct).
>
Hi Rob,
FYI this was superseded by v3 which should now be correct.
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] i2c: mediatek: Add i2c ac-timing adjust support
From: Qii Wang @ 2020-05-20 9:14 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
srv_heupstream, Wolfram Sang, leilk.liu,
Linux Kernel Mailing List, linux-mediatek, Linux I2C, Joe Perches,
Linux ARM
In-Reply-To: <CAMuHMdXZTU+4-WyVjvv=i28x+MRVrAdRPM0_ybvkkFuh-ps+eg@mail.gmail.com>
Hi Geert,
On Wed, 2020-05-20 at 10:58 +0200, Geert Uytterhoeven wrote:
> Hi Qii,
>
> On Wed, May 20, 2020 at 10:44 AM Qii Wang <qii.wang@mediatek.com> wrote:
> > On Tue, 2020-05-19 at 09:14 +0200, Geert Uytterhoeven wrote:
> > > On Tue, May 19, 2020 at 4:59 AM Qii Wang <qii.wang@mediatek.com> wrote:
> > > > On Mon, 2020-05-18 at 17:44 +0200, Geert Uytterhoeven wrote:
> > > > > On Thu, May 14, 2020 at 3:13 PM Qii Wang <qii.wang@mediatek.com> wrote:
> > > > > > This patch adds a algorithm to calculate some ac-timing parameters
> > > > > > which can fully meet I2C Spec.
> > > > > >
> > > > > > Signed-off-by: Qii Wang <qii.wang@mediatek.com>
> > > > > > ---
> > > > > > drivers/i2c/busses/i2c-mt65xx.c | 328 +++++++++++++++++++++++++++++++++-------
> > > > > > 1 file changed, 277 insertions(+), 51 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> > > > > > index 0ca6c38a..7020618 100644
> > > > > > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > > > > > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> > > > >
> > > > > > +/*
> > > > > > + * Check and Calculate i2c ac-timing
> > > > > > + *
> > > > > > + * Hardware design:
> > > > > > + * sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src
> > > > > > + * xxx_cnt_div = spec->min_xxx_ns / sample_ns
> > > > > > + *
> > > > > > + * Sample_ns is rounded down for xxx_cnt_div would be greater
> > > > > > + * than the smallest spec.
> > > > > > + * The sda_timing is chosen as the middle value between
> > > > > > + * the largest and smallest.
> > > > > > + */
> > > > > > +static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
> > > > > > + unsigned int clk_src,
> > > > > > + unsigned int check_speed,
> > > > > > + unsigned int step_cnt,
> > > > > > + unsigned int sample_cnt)
> > > > > > +{
> > > > > > + const struct i2c_spec_values *spec;
> > > > > > + unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt;
> > > > > > + unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f;
> > > > > > + long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
> > > > >
> > > > > So sample_ns is a 64-bit value. Is that really needed?
> > > > >
> > > >
> > > > (1000000000 * (sample_cnt + 1)) / clk_src value is a 32-bit, (1000000000
> > > > * (sample_cnt + 1)) will over 32-bit if sample_cnt is 7.
> > >
> > > The intermediate value will indeed not fit in 32-bit.
> > > But that doesn't mean the end result won't fit in 32-bit.
> > > As you divide spec->min_low_ns and spec->min_su_dat_ns (which I assume
> > > are small numbers) by sample_ns below, sample_ns cannot be very large,
> > > or the quotient will be zero anyway.
> > > So just doing the multiplication in 64-bit, followed by a 64-by-32
> > > division is probably fine:
> > >
> > > unsigned int sample_ns = div_u64(1000000000ULL * (sample_cnt + 1), clk_src);
> > >
> > > You may want to take precautions for the case where the passed value of
> > > clk_src is a small number (can that happen?).
> > >
> > > BTW, clk_get_rate() returns "unsigned long", while mtk_i2c_set_speed()
> > > takes an "unsigned int" parent_clk, which may cause future issues.
> > > You may want to change that to "unsigned long", along the whole
> > > propagation path, and use div64_ul() instead of div_u64() above.
> > >
> >
> > The return type of div_u64 is u64(unsigned long long), there is a
> > compulsory type conversion operator. Do you think it is needed?
>
> The result of a 64-by-32 bit division may indeed not fit in 32-bit, so that's
> why it returns u64.
> If you know the quotient will always fit, it's fine.
>
> > BTW, we just need to change the type of sample_ns to unsigned int, no
> > matter which method is used, what is your opinion?
>
> Indeed.
>
> BTW, I just realize
>
> long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
>
> wasn't doing what you wanted anyway, as 1000000000 is (implicit) int,
> and sample_cnt is unsigned int, so the multiplication was done in 32-bit,
> possible leading to a truncation. Hence that division was done in 32-bit, too,
> that's why I didn't notice a call to __udivdi3() in the assembler output here.
>
> So you have to force the multiplication to be done in 64-bit, e.g.
> by changing the constant to 1000000000ULL, and use div_u64() for
> the division.
>
ok, I will give a patch with your way, thanks for your opinion.
> >
> > > > I think 1000000000 and clk_src is too big, maybe I can reduce then with
> > > > be divided all by 1000.
> > > > example:
> > > >
> > > > unsigned int sample_ns;
> > > > unsigned int clk_src_khz = clk_src / 1000;
> > >
> > > That may cause too much loss of precision.
> > >
> >
> > clk_src is more than MHz and less than GHZ for MTK i2c controller, so it
> > wouldn't cause too much loss of precision.
>
> OK, so that would work, too.
>
> > > >
> > > > if(clk_src_khz)
> > > > sample_ns = (1000000 * (sample_cnt + 1)) / clk_src_khz;
> > > > else
> > > > return -EINVAL;
> > > >
> > > > > > + if (!i2c->dev_comp->timing_adjust)
> > > > > > + return 0;
> > > > > > +
> > > > > > + if (i2c->dev_comp->ltiming_adjust)
> > > > > > + max_sta_cnt = 0x100;
> > > > > > +
> > > > > > + spec = mtk_i2c_get_spec(check_speed);
> > > > > > +
> > > > > > + if (i2c->dev_comp->ltiming_adjust)
> > > > > > + clk_ns = 1000000000 / clk_src;
> > > > > > + else
> > > > > > + clk_ns = sample_ns / 2;
> > > > > > +
> > > > > > + su_sta_cnt = DIV_ROUND_UP(spec->min_su_sta_ns, clk_ns);
> > > > > > + if (su_sta_cnt > max_sta_cnt)
> > > > > > + return -1;
> > > > > > +
> > > > > > + low_cnt = DIV_ROUND_UP(spec->min_low_ns, sample_ns);
> > > > >
> > > > > So this is a 32-bit by 64-bit division (indeed, not 64-by-32!)
>
> Gr{oetje,eeting}s,
>
> Geert
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] ARM: dts: imx: Make tempmon node as child of anatop node
From: Aisheng Dong @ 2020-05-20 9:22 UTC (permalink / raw)
To: Anson Huang, robh+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <DB3PR0402MB39161EA7B95886D56EB91E8BF5B60@DB3PR0402MB3916.eurprd04.prod.outlook.com>
> From: Anson Huang <anson.huang@nxp.com>
> Sent: Wednesday, May 20, 2020 4:12 PM
>
> > Subject: RE: [PATCH] ARM: dts: imx: Make tempmon node as child of
> > anatop node
> >
> > > From: Anson Huang <anson.huang@nxp.com>
> > > Sent: Wednesday, May 20, 2020 3:47 PM
> > >
> > > > Subject: RE: [PATCH] ARM: dts: imx: Make tempmon node as child of
> > > > anatop node
> > > >
> > > > > From: Anson Huang <Anson.Huang@nxp.com>
> > > > > Sent: Wednesday, May 20, 2020 2:30 PM
> > > > >
> > > > > i.MX6/7 SoCs' temperature sensor is inside anatop module from HW
> > > > > perspective, so it should be a child node of anatop.
> > > > >
> > > > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > >
> > > > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > > >
> > > > BTW, I think you also need a binding doc for this change.
> > >
> > > The binding doc is the imx-thermal.yaml I sent out, it is suggested
> > > by Rob to move tempmon into anatop node, that is why I did this
> > > patch to align with the binding doc.
> >
> > That's thermal binding doc.
> > We need a binding doc to describe the constraints for anatop as well.
>
> anatop includes PMU, thermal etc., need to think about how to add it and
> where to put it, will think about it later.
We can combine them into one.
Regards
Aisheng
>
> Anson
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/4] kasan: record and print the free track
From: Walter Wu @ 2020-05-20 9:17 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: wsd_upstream, linux-mediatek, LKML, kasan-dev, Linux-MM,
Alexander Potapenko, Andrey Ryabinin, Linux ARM
In-Reply-To: <CACT4Y+Z42fQe4ijnA7HksAqrnpyzGU5pyY2bRFBETsL-mkB9_g@mail.gmail.com>
> On Wed, May 20, 2020 at 8:18 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > On Wed, 2020-05-20 at 13:14 +0800, Walter Wu wrote:
> > > > On Wed, May 20, 2020 at 6:03 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > > >
> > > > > > On Tue, May 19, 2020 at 4:25 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > > > > >
> > > > > > > Move free track from slub alloc meta-data to slub free meta-data in
> > > > > > > order to make struct kasan_free_meta size is 16 bytes. It is a good
> > > > > > > size because it is the minimal redzone size and a good number of
> > > > > > > alignment.
> > > > > > >
> > > > > > > For free track in generic KASAN, we do the modification in struct
> > > > > > > kasan_alloc_meta and kasan_free_meta:
> > > > > > > - remove free track from kasan_alloc_meta.
> > > > > > > - add free track into kasan_free_meta.
> > > > > > >
> > > > > > > [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> > > > > > >
> > > > > > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > > > > > > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > > > > > > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > > > > > > Cc: Dmitry Vyukov <dvyukov@google.com>
> > > > > > > Cc: Alexander Potapenko <glider@google.com>
> > > > > > > ---
> > > > > > > mm/kasan/common.c | 22 ++--------------------
> > > > > > > mm/kasan/generic.c | 18 ++++++++++++++++++
> > > > > > > mm/kasan/kasan.h | 7 +++++++
> > > > > > > mm/kasan/report.c | 20 --------------------
> > > > > > > mm/kasan/tags.c | 37 +++++++++++++++++++++++++++++++++++++
> > > > > > > 5 files changed, 64 insertions(+), 40 deletions(-)
> > > > > > >
> > > > > > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > > > > > > index 8bc618289bb1..47b53912f322 100644
> > > > > > > --- a/mm/kasan/common.c
> > > > > > > +++ b/mm/kasan/common.c
> > > > > > > @@ -51,7 +51,7 @@ depot_stack_handle_t kasan_save_stack(gfp_t flags)
> > > > > > > return stack_depot_save(entries, nr_entries, flags);
> > > > > > > }
> > > > > > >
> > > > > > > -static inline void set_track(struct kasan_track *track, gfp_t flags)
> > > > > > > +void kasan_set_track(struct kasan_track *track, gfp_t flags)
> > > > > > > {
> > > > > > > track->pid = current->pid;
> > > > > > > track->stack = kasan_save_stack(flags);
> > > > > > > @@ -299,24 +299,6 @@ struct kasan_free_meta *get_free_info(struct kmem_cache *cache,
> > > > > > > return (void *)object + cache->kasan_info.free_meta_offset;
> > > > > > > }
> > > > > > >
> > > > > > > -
> > > > > > > -static void kasan_set_free_info(struct kmem_cache *cache,
> > > > > > > - void *object, u8 tag)
> > > > > > > -{
> > > > > > > - struct kasan_alloc_meta *alloc_meta;
> > > > > > > - u8 idx = 0;
> > > > > > > -
> > > > > > > - alloc_meta = get_alloc_info(cache, object);
> > > > > > > -
> > > > > > > -#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > - idx = alloc_meta->free_track_idx;
> > > > > > > - alloc_meta->free_pointer_tag[idx] = tag;
> > > > > > > - alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
> > > > > > > -#endif
> > > > > > > -
> > > > > > > - set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
> > > > > > > -}
> > > > > > > -
> > > > > > > void kasan_poison_slab(struct page *page)
> > > > > > > {
> > > > > > > unsigned long i;
> > > > > > > @@ -492,7 +474,7 @@ static void *__kasan_kmalloc(struct kmem_cache *cache, const void *object,
> > > > > > > KASAN_KMALLOC_REDZONE);
> > > > > > >
> > > > > > > if (cache->flags & SLAB_KASAN)
> > > > > > > - set_track(&get_alloc_info(cache, object)->alloc_track, flags);
> > > > > > > + kasan_set_track(&get_alloc_info(cache, object)->alloc_track, flags);
> > > > > > >
> > > > > > > return set_tag(object, tag);
> > > > > > > }
> > > > > > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > > > > > > index 3372bdcaf92a..763d8a13e0ac 100644
> > > > > > > --- a/mm/kasan/generic.c
> > > > > > > +++ b/mm/kasan/generic.c
> > > > > > > @@ -344,3 +344,21 @@ void kasan_record_aux_stack(void *addr)
> > > > > > > alloc_info->aux_stack[1] = alloc_info->aux_stack[0];
> > > > > > > alloc_info->aux_stack[0] = kasan_save_stack(GFP_NOWAIT);
> > > > > > > }
> > > > > > > +
> > > > > > > +void kasan_set_free_info(struct kmem_cache *cache,
> > > > > > > + void *object, u8 tag)
> > > > > > > +{
> > > > > > > + struct kasan_free_meta *free_meta;
> > > > > > > +
> > > > > > > + free_meta = get_free_info(cache, object);
> > > > > > > + kasan_set_track(&free_meta->free_track, GFP_NOWAIT);
> > > > > > > +}
> > > > > > > +
> > > > > > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > + void *object, u8 tag)
> > > > > > > +{
> > > > > > > + struct kasan_free_meta *free_meta;
> > > > > > > +
> > > > > > > + free_meta = get_free_info(cache, object);
> > > > > > > + return &free_meta->free_track;
> > > > > > > +}
> > > > > > > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > > > > > > index a7391bc83070..ad897ec36545 100644
> > > > > > > --- a/mm/kasan/kasan.h
> > > > > > > +++ b/mm/kasan/kasan.h
> > > > > > > @@ -127,6 +127,9 @@ struct kasan_free_meta {
> > > > > > > * Otherwise it might be used for the allocator freelist.
> > > > > > > */
> > > > > > > struct qlist_node quarantine_link;
> > > > > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > > > > + struct kasan_track free_track;
> > > > > > > +#endif
> > > > > > > };
> > > > > > >
> > > > > > > struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
> > > > > > > @@ -168,6 +171,10 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
> > > > > > > struct page *kasan_addr_to_page(const void *addr);
> > > > > > >
> > > > > > > depot_stack_handle_t kasan_save_stack(gfp_t flags);
> > > > > > > +void kasan_set_track(struct kasan_track *track, gfp_t flags);
> > > > > > > +void kasan_set_free_info(struct kmem_cache *cache, void *object, u8 tag);
> > > > > > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > + void *object, u8 tag);
> > > > > > >
> > > > > > > #if defined(CONFIG_KASAN_GENERIC) && \
> > > > > > > (defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
> > > > > > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > > > > > > index 6f8f2bf8f53b..96d2657fe70f 100644
> > > > > > > --- a/mm/kasan/report.c
> > > > > > > +++ b/mm/kasan/report.c
> > > > > > > @@ -159,26 +159,6 @@ static void describe_object_addr(struct kmem_cache *cache, void *object,
> > > > > > > (void *)(object_addr + cache->object_size));
> > > > > > > }
> > > > > > >
> > > > > > > -static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > - void *object, u8 tag)
> > > > > > > -{
> > > > > > > - struct kasan_alloc_meta *alloc_meta;
> > > > > > > - int i = 0;
> > > > > > > -
> > > > > > > - alloc_meta = get_alloc_info(cache, object);
> > > > > > > -
> > > > > > > -#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > - for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
> > > > > > > - if (alloc_meta->free_pointer_tag[i] == tag)
> > > > > > > - break;
> > > > > > > - }
> > > > > > > - if (i == KASAN_NR_FREE_STACKS)
> > > > > > > - i = alloc_meta->free_track_idx;
> > > > > > > -#endif
> > > > > > > -
> > > > > > > - return &alloc_meta->free_track[i];
> > > > > > > -}
> > > > > > > -
> > > > > > > #ifdef CONFIG_KASAN_GENERIC
> > > > > > > static void print_stack(depot_stack_handle_t stack)
> > > > > > > {
> > > > > > > diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c
> > > > > > > index 25b7734e7013..201dee5d6ae0 100644
> > > > > > > --- a/mm/kasan/tags.c
> > > > > > > +++ b/mm/kasan/tags.c
> > > > > > > @@ -162,3 +162,40 @@ void __hwasan_tag_memory(unsigned long addr, u8 tag, unsigned long size)
> > > > > > > kasan_poison_shadow((void *)addr, size, tag);
> > > > > > > }
> > > > > > > EXPORT_SYMBOL(__hwasan_tag_memory);
> > > > > > > +
> > > > > > > +void kasan_set_free_info(struct kmem_cache *cache,
> > > > > > > + void *object, u8 tag)
> > > > > > > +{
> > > > > > > + struct kasan_alloc_meta *alloc_meta;
> > > > > > > + u8 idx = 0;
> > > > > > > +
> > > > > > > + alloc_meta = get_alloc_info(cache, object);
> > > > > > > +
> > > > > > > +#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > + idx = alloc_meta->free_track_idx;
> > > > > > > + alloc_meta->free_pointer_tag[idx] = tag;
> > > > > > > + alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
> > > > > > > +#endif
> > > > > > > +
> > > > > > > + kasan_set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
> > > > > > > +}
> > > > > > > +
> > > > > > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > > > > > + void *object, u8 tag)
> > > > > > > +{
> > > > > > > + struct kasan_alloc_meta *alloc_meta;
> > > > > > > + int i = 0;
> > > > > > > +
> > > > > > > + alloc_meta = get_alloc_info(cache, object);
> > > > > > > +
> > > > > > > +#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > > > > > + for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
> > > > > > > + if (alloc_meta->free_pointer_tag[i] == tag)
> > > > > > > + break;
> > > > > > > + }
> > > > > > > + if (i == KASAN_NR_FREE_STACKS)
> > > > > > > + i = alloc_meta->free_track_idx;
> > > > > > > +#endif
> > > > > > > +
> > > > > > > + return &alloc_meta->free_track[i];
> > > > > > > +}
> > > > > >
> > > > > > Hi Walter,
> > > > > >
> > > > > > FTR I've uploaded this for review purposes here:
> > > > > > https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2458
> > > > > >
> > > > > > Diff from the previous version is available as:
> > > > > > https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2458/1..2
> > > > > >
> > > > > > I've tested this locally and with syzkaller. This is :
> > > > > >
> > > > > > [ 80.583021][ C3] Freed by task 0:
> > > > > > [ 80.583480][ C3] kasan_save_stack+0x1b/0x40 mm/kasan/common.c:49
> > > > > > [ 80.584056][ C3] kasan_set_track+0x1c/0x30 mm/kasan/common.c:57
> > > > > > [ 80.584617][ C3] kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:354
> > > > > > [ 80.585221][ C3] __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:438
> > > > > > [ 80.585814][ C3] __cache_free mm/slab.c:3426 [inline]
> > > > > > [ 80.585814][ C3] kfree+0x10b/0x2b0 mm/slab.c:3757
> > > > > > [ 80.586291][ C3] kasan_rcu_reclaim+0x16/0x43 [test_kasan]
> > > > > > [ 80.587009][ C3] rcu_do_batch kernel/rcu/tree.c:2207 [inline]
> > > > > > [ 80.587009][ C3] rcu_core+0x59f/0x1370 kernel/rcu/tree.c:2434
> > > > > > [ 80.587537][ C3] __do_softirq+0x26c/0x9fa kernel/softirq.c:292
> > > > > > [ 80.588085][ C3]
> > > > > > [ 80.588367][ C3] Last one call_rcu() call stack:
> > > > > > [ 80.589052][ C3] kasan_save_stack+0x1b/0x40 mm/kasan/common.c:49
> > > > > > [ 80.589622][ C3] kasan_record_aux_stack+0x82/0xb0 mm/kasan/generic.c:345
> > > > > > [ 80.590254][ C3] __call_rcu kernel/rcu/tree.c:2672 [inline]
> > > > > > [ 80.590254][ C3] call_rcu+0x14f/0x7f0 kernel/rcu/tree.c:2746
> > > > > > [ 80.590782][ C3] kasan_rcu_uaf+0xe4/0xeb [test_kasan]
> > > > > > [ 80.591697][ C3] kmalloc_tests_init+0xbc/0x1097 [test_kasan]
> > > > > > [ 80.592900][ C3] do_one_initcall+0x10a/0x7d0 init/main.c:1196
> > > > > > [ 80.593494][ C3] do_init_module+0x1e6/0x6d0 kernel/module.c:3539
> > > > > > [ 80.594066][ C3] load_module+0x7464/0x9450 kernel/module.c:3890
> > > > > > [ 80.594626][ C3] __do_sys_init_module+0x1e3/0x220 kernel/module.c:3953
> > > > > > [ 80.595265][ C3] do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
> > > > > > [ 80.595822][ C3] entry_SYSCALL_64_after_hwframe+0x49/0xb3
> > > > > >
> > > > > >
> > > > > > Overall this looks very good to me.
> > > > > > But there is one aspect that bothers me. In the previous patch you had
> > > > > > code that returned NULL from kasan_get_free_track() if the object is
> > > > > > live (which means free meta is not available, it's occupied by object
> > > > > > data). Now you dropped that code, but I think we still need it.
> > > > > > Otherwise we cast user object data to free meta and print the free
> > > > > > stack/pid from whatever garbage is there. This may lead to very
> > > > > > confusing output and potentially to crashes in stackdepot.
> > > > > >
> > > > >
> > > > > Yes, I totally agree with you. In the previous email I thought that
> > > > > there is a problem with free track, but I did not point it out. Thank
> > > > > you for pointing this problem. As you mentioned, we should fix it.
> > > > >
> > > > > > What do you think about this patch on top of your patches?
> > > > > > https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2478
> > > > > > This way we very precisely mark the period of time when the object has
> > > > > > free track live and set.
> > > > > > If it looks good to you, feel free to incorporate it into your series.
> > > > > >
> > > > >
> > > > > Thank you for providing good idea solution.
> > > > >
> > > > > I saw this patch, that is a great patch. I think it can fix the issue
> > > > > which has garbage stack. it should work as described below.
> > > > >
> > > > > 1). When object is live, then don't print free stack.
> > > > > 2). When object is NOT alive, after free object:
> > > > > 2a). when object is in quarantine, then it can print free stack
> > > > > 2b). when object is NOT in quarantine, then it can NOT print free stack.
> > > > >
> > > > > I have a question about 2), why we don't directly use
> > > > > KASAN_KMALLOC_FREE? if we directly use it, then 2b) can print free
> > > > > stack? 2b) may has use-after-free? so that it may need free stack.
> > > >
> >
> > About 2b), I see another question. When do qlink_free(), it will be
> > written KASAN_KMALLOC_FREE from KASAN_KMALLOC_FREETRACK? if we don't
> > write shadow memory, it is still KASAN_KMALLOC_FREETRACK, then 2b) will
> > have free stack? Because I see you add KASAN_KMALLOC_FREETRACK to get
> > use-after-free in get_shadow_bug_type(). so should it not write
> > KASAN_KMALLOC_FREE?
>
> It may or may not work.
> The potential problem is that when qlink_free calls ___cache_free,
> slab/slub may start using object memory for its own purposes, e.g.
> store the next link. This next link may overwrite part of free meta.
> It actually may work because the slab/slib next link is likely to
> overlap with kasan_free_meta.quarantine_link only. And we may have
> kasan_free_meta.free_track intact while KASAN_KMALLOC_FREE is set. But
> this needs careful checking for both slab and slub and if they may use
> more than 1 word in some configurations.
>
This problem looks like existing, even without this change? currently
KASAN may get wrong free stack?
Regardless of whether the shadow memory content is
KASAN_KMALLOC_FREETRACK or KASAN_KMALLOC_FREE, it may have this problem?
But because of kasan_get_free_track() have conditions to get free track,
so that if shadow memory content is KASAN_KMALLOC_FREE, then it will
avoid this problem and always print right free stack.
>
> > > > We can't use KASAN_KMALLOC_FREE because of this part:
> > > >
> > > > static bool __kasan_slab_free(struct kmem_cache *cache, void *object,
> > > > unsigned long ip, bool quarantine)
> > > > {
> > > > ...
> > > > kasan_poison_shadow(object, rounded_up_size, KASAN_KMALLOC_FREE);
> > > >
> > > > if ((IS_ENABLED(CONFIG_KASAN_GENERIC) && !quarantine) ||
> > > > unlikely(!(cache->flags & SLAB_KASAN)))
> > > > return false;
> > > >
> > > > kasan_set_free_info(cache, object, tag);
> > > > ...
> > > >
> > >
> > > Ok, I see. When return false, then the shadow memory content has
> > > KASAN_KMALLOC_FREE, but it doesn't set free stack, so that we need to
> > > avoid this situation. Thank for you reminder.
> > >
> > > >
> > > > We may set KASAN_KMALLOC_FREE, but not set the track (or even have
> > > > memory for the track!).
> > > > The object may not have free meta allocated at all, e.g. very large
> > > > object with ctor (no place to store meta), or it may be in a mempool:
> > > > https://elixir.bootlin.com/linux/v5.7-rc6/source/mm/mempool.c#L109
> > > > and mempool may be using the object memory itself (for its own next
> > > > link or something).
> > > >
> > > > KASAN_KMALLOC_FREETRACK very explicitly tracks the exact condition we
> > > > want: we have meta info live now and we have free track set.
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6] arm64: Expose FAR_EL1 tag bits in sigcontext
From: Dave Martin @ 2020-05-20 9:26 UTC (permalink / raw)
To: Will Deacon
Cc: Andrey Konovalov, Kevin Brodsky, Kostya Serebryany, Linux ARM,
Catalin Marinas, Vincenzo Frascino, Peter Collingbourne,
Evgenii Stepanov, Richard Henderson
In-Reply-To: <20200520085502.GC24293@willie-the-truck>
On Wed, May 20, 2020 at 09:55:03AM +0100, Will Deacon wrote:
> On Tue, May 19, 2020 at 03:00:12PM -0700, Peter Collingbourne wrote:
> > On Mon, May 18, 2020 at 2:53 AM Dave Martin <Dave.Martin@arm.com> wrote:
> > > On Thu, May 14, 2020 at 05:58:21PM -0700, Peter Collingbourne wrote:
> > > > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> > > > index baa88dc02e5c..5867f2fdbe64 100644
> > > > --- a/arch/arm64/kernel/signal.c
> > > > +++ b/arch/arm64/kernel/signal.c
> > > > @@ -648,6 +648,7 @@ static int setup_sigframe(struct
> > > > rt_sigframe_user_layout *user,
> > > > __put_user_error(ESR_MAGIC, &esr_ctx->head.magic, err);
> > > > __put_user_error(sizeof(*esr_ctx), &esr_ctx->head.size, err);
> > > > __put_user_error(current->thread.fault_code,
> > > > &esr_ctx->esr, err);
> > > > + current->thread.fault_code = 0;
> > >
> > > Perhaps, but we'd need to be careful. For example, can we run out of
> > > user stack before this and deliver a SIGSEGV, but with the old
> > > fault_code still set? Then we'd emit the old fault code with the
> > > new "can't deliver signal" signal, which doesn't make sense.
> > >
> > > Stuff may also go wrong with signal prioritisation.
> > >
> > > If a higher-priority signal (say SIGINT) comes in after a data abort
> > > enters the kernel but before the resulting SIGSEGV is dequeued for
> > > delivery, wouldn't we deliver SIGINT first, with the bogus fault code?
> > > With your change we'd then have cleared the fault code by the time we
> > > deliver the SIGSEGV it actually relates to, if I've understood right.
> > >
> > > Today, I think we just attach that fault code to every signal that's
> > > delivered until something overwrites or resets it, which means that
> > > a signal that needs fault_code gets it, at the expense of attaching
> > > it to a bunch of other random signals too.
> > >
> > >
> > > Checking the signal number and si_code might help us to know what we
> > > should be doing with fault_code. We need to have sure userspace can't
> > > trick us with a non kernel generated signal here. It would also be
> > > necessary to check how PTRACE_SETSIGINFO interacts with this.
> >
> > With these possible interactions in mind I think we should store the
> > fault code and fault address in kernel_siginfo instead of
> > thread_struct (and clear these fields when we receive a siginfo from
> > userspace, i.e. in copy_siginfo_from_user which is used by
> > ptrace(PTRACE_SETSIGINFO) among other places). That way, the
> > information is clearly associated with the signal itself and not the
> > thread, so we don't need to worry about our signal being delivered out
> > of order.
>
> Hmm, I can't see a way to do that that isn't horribly invasive in the core
> signal code. Can you?
>
> But generally, I agree: the per-thread handling of fault_address and
> fault_code appears to be quite broken in the face of signal prioritisation
> and signals that don't correspond directly to hardware trap. It would be
> nice to have some tests for this...
>
> If we want to pile on more bodges, perhaps we could stash the signal number
> to which the fault_{address,code} relate, and then check that at delivery
> and clear on a match. I hate it.
I agree with Daniel's suggestion in principle, but I was also concerned
about whether it would be too invasive elsewhere.
Question though: does the core code take special care to make sure that
a force_sig cannot be outprioritised by a regular signal? If so,
perhaps we get away with it. I ask this, because the same same issue
may be hitting other arches otherwise.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 5/5] dt-bindings: arm: fsl: add different Protonic boards
From: Oleksij Rempel @ 2020-05-20 9:29 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, linux-kernel, Oleksij Rempel, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200520092937.15797-1-o.rempel@pengutronix.de>
Add Protonic PRTI6Q, WD2, RVT, VT7 boards.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index cd3fbe7e39487..a1657505b3357 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -119,6 +119,8 @@ properties:
- fsl,imx6q-sabreauto
- fsl,imx6q-sabrelite
- fsl,imx6q-sabresd
+ - prt,prti6q # Protonic PRTI6Q board
+ - prt,prtwd2 # Protonic WD2 board
- technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf
- technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit
- technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph
@@ -170,6 +172,8 @@ properties:
- emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base
- fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board
- fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board
+ - prt,prtrvt # Protonic RVT board
+ - prt,prtvt7 # Protonic VT7 board
- technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf
- technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit
- technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v7 4/5] ARM: dts: add Protonic RVT board
From: Oleksij Rempel @ 2020-05-20 9:29 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, Rob Herring, linux-kernel, Oleksij Rempel,
NXP Linux Team, Pengutronix Kernel Team, David Jander,
Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200520092937.15797-1-o.rempel@pengutronix.de>
Protonic RVT is an internal development platform for a wireless ISObus
Virtual Terminal based on COTS tablets, and the predecessor of the WD2
platform.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-prtrvt.dts | 182 ++++++++++++++++++++++++++++
2 files changed, 183 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-prtrvt.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 66ee89e7929f9..89842a034e4ba 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -450,6 +450,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+ imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
imx6dl-riotboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-prtrvt.dts b/arch/arm/boot/dts/imx6dl-prtrvt.dts
new file mode 100644
index 0000000000000..b7721e52a463a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-prtrvt.dts
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "Protonic RVT board";
+ compatible = "prt,prtrvt", "fsl,imx6dl";
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x10000000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&can1 {
+ pinctrl-0 = <&pinctrl_can1 &pinctrl_can1phy>;
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
+
+&ecspi3 {
+ cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ status = "okay";
+
+ nfc@0 {
+ compatible = "ti,trf7970a";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_nfc>;
+ spi-max-frequency = <2000000>;
+ interrupts-extended = <&gpio5 14 IRQ_TYPE_LEVEL_LOW>;
+ ti,enable-gpios = <&gpio5 12 GPIO_ACTIVE_LOW>,
+ <&gpio5 11 GPIO_ACTIVE_LOW>;
+ vin-supply = <®_3v3>;
+ vin-voltage-override = <3100000>;
+ autosuspend-delay = <30000>;
+ irq-status-read-quirk;
+ en2-rf-quirk;
+ t5t-rmb-extra-byte-quirk;
+ status = "okay";
+ };
+};
+
+&i2c3 {
+ adc@49 {
+ compatible = "ti,ads1015";
+ reg = <0x49>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* nc */
+ channel@4 {
+ reg = <4>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* nc */
+ channel@5 {
+ reg = <5>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_l */
+ channel@6 {
+ reg = <6>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_h */
+ channel@7 {
+ reg = <7>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+ };
+
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "disabled";
+};
+
+&vpu {
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_can1phy: can1phy {
+ fsl,pins = <
+ /* CAN1_SR */
+ MX6QDL_PAD_KEY_COL3__GPIO4_IO12 0x13070
+ /* CAN1_TERM */
+ MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
+ MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
+ MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
+ /* CS */
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x000b1
+ >;
+ };
+
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
+ MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
+ MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
+ MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x000b1
+ >;
+ };
+
+ pinctrl_leds: ledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ >;
+ };
+
+ pinctrl_nfc: nfcgrp {
+ fsl,pins = <
+ /* NFC_ASK_OOK */
+ MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 0x100b1
+ /* NFC_PWR_EN */
+ MX6QDL_PAD_DISP0_DAT16__GPIO5_IO10 0x100b1
+ /* NFC_EN2 */
+ MX6QDL_PAD_DISP0_DAT17__GPIO5_IO11 0x100b1
+ /* NFC_EN */
+ MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x100b1
+ /* NFC_MOD */
+ MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x100b1
+ /* NFC_IRQ */
+ MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14 0x100b1
+ >;
+ };
+};
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v7 0/5] mainline Protonic boards
From: Oleksij Rempel @ 2020-05-20 9:29 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, linux-kernel, Oleksij Rempel, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
changes v7:
- VT7: reorder node alphabetically
- VT7: rename "reg_12v_bl: regulator-bl-12v" to "reg_bl_12v0: regulator-bl-12v0"
- VT7: remove panel and TS nodes. This drivers are currently not
mainline.
- prti6q.dtsi: move reg_1v8 to prti6q.dts
- prti6q.dtsi: remove pinctrl from the can1 node. It is done on almost
every board file.
changes v6:
- move fsl.yaml changes to separate patch
- remove partitions, they are provided by the bootloader
- update flash compatible
- rename can3 to can
- fix fsl,mode
- fix interrupt in the wlan node on PRTI6Q
changes v5:
- PRTI6Q: remove status from the pwm-backlight node
- drop the vendor-prefixes patch, it is already taken by Rob
- add Reviewed-by: Rob Herring <robh@kernel.org>
changes v4:
- VT7: fix typo
changes v3:
- move compatible to the start of node
- move status to the end
- use generic names in compatible
- refactor dts/dtsi
- use alphabet order for pinctrl and phandels
- remove unused or currently not supported nodes
changes v2:
- squash PRTI6Q patches
Oleksij Rempel (5):
ARM: dts: add Protonic PRTI6Q board
ARM: dts: add Protonic WD2 board
ARM: dts: add Protonic VT7 board
ARM: dts: add Protonic RVT board
dt-bindings: arm: fsl: add different Protonic boards
.../devicetree/bindings/arm/fsl.yaml | 4 +
arch/arm/boot/dts/Makefile | 4 +
arch/arm/boot/dts/imx6dl-prtrvt.dts | 182 ++++++
arch/arm/boot/dts/imx6dl-prtvt7.dts | 472 ++++++++++++++++
arch/arm/boot/dts/imx6q-prti6q.dts | 529 ++++++++++++++++++
arch/arm/boot/dts/imx6q-prtwd2.dts | 188 +++++++
arch/arm/boot/dts/imx6qdl-prti6q.dtsi | 174 ++++++
7 files changed, 1553 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-prtrvt.dts
create mode 100644 arch/arm/boot/dts/imx6dl-prtvt7.dts
create mode 100644 arch/arm/boot/dts/imx6q-prti6q.dts
create mode 100644 arch/arm/boot/dts/imx6q-prtwd2.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-prti6q.dtsi
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 1/5] ARM: dts: add Protonic PRTI6Q board
From: Oleksij Rempel @ 2020-05-20 9:29 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, Rob Herring, linux-kernel, Oleksij Rempel,
NXP Linux Team, Pengutronix Kernel Team, David Jander,
Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200520092937.15797-1-o.rempel@pengutronix.de>
Protonic PRTI6Q is a development board and a base class for different
specific customer application boards based on the i.MX6 family of SoCs,
developed by Protonic Holland.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-prti6q.dts | 529 ++++++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl-prti6q.dtsi | 174 +++++++++
3 files changed, 704 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-prti6q.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-prti6q.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e8dd992013973..206a36a50575e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -538,6 +538,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-pico-nymph.dtb \
imx6q-pico-pi.dtb \
imx6q-pistachio.dtb \
+ imx6q-prti6q.dtb \
imx6q-rex-pro.dtb \
imx6q-sabreauto.dtb \
imx6q-sabrelite.dtb \
diff --git a/arch/arm/boot/dts/imx6q-prti6q.dts b/arch/arm/boot/dts/imx6q-prti6q.dts
new file mode 100644
index 0000000000000..e698149cab423
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-prti6q.dts
@@ -0,0 +1,529 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/sound/fsl-imx-audmux.h>
+
+/ {
+ model = "Protonic PRTI6Q board";
+ compatible = "prt,prti6q", "fsl,imx6q";
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0xf0000000>;
+ };
+
+ backlight_lcd: backlight-lcd {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ pwms = <&pwm1 0 5000000>;
+ brightness-levels = <0 16 64 255>;
+ num-interpolated-steps = <16>;
+ default-brightness-level = <16>;
+ power-supply = <®_3v3>;
+ enable-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ };
+
+ can3_25m_osc: can3-25m-osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-debug1 {
+ function = LED_FUNCTION_SD;
+ gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "disk-activity";
+ };
+ };
+
+ panel {
+ compatible = "kyo,tcg121xglp";
+ backlight = <&backlight_lcd>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+
+ reg_wifi: regulator-wifi {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi_npd>;
+ enable-active-high;
+ gpio = <&gpio1 26 GPIO_ACTIVE_HIGH>;
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "regulator-WL12xx";
+ startup-delay-us = <70000>;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "prti6q-sgtl5000";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Line", "Line In Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "External Speaker", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <&ssi1>;
+ system-clock-frequency = <0>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&sgtl5000>;
+ bitclock-master;
+ frame-master;
+ };
+ };
+
+ sound-spdif {
+ compatible = "fsl,imx-audio-spdif";
+ model = "imx-spdif";
+ spdif-controller = <&spdif>;
+ spdif-in;
+ spdif-out;
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>;
+ status = "okay";
+
+ mux_ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN 0
+ IMX_AUDMUX_V2_PTCR_TFSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TCSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TFSDIR 0
+ IMX_AUDMUX_V2_PTCR_TCLKDIR IMX_AUDMUX_V2_PDCR_RXDSEL(2)
+ >;
+ };
+
+ mux_pins3 {
+ fsl,audmux-port = <2>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN IMX_AUDMUX_V2_PDCR_RXDSEL(0)
+ 0 IMX_AUDMUX_V2_PDCR_TXRXEN
+ >;
+ };
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can2>;
+ status = "okay";
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ };
+};
+
+&ecspi2 {
+ cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>, <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>;
+ status = "okay";
+
+ can@0 {
+ compatible = "microchip,mcp2515";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can3>;
+ clocks = <&can3_25m_osc>;
+ interrupts-extended = <&gpio3 20 IRQ_TYPE_LEVEL_LOW>;
+ spi-max-frequency = <5000000>;
+ };
+
+ adc@1 {
+ compatible = "ti,adc128s052";
+ reg = <1>;
+ spi-max-frequency = <2000000>;
+ vref-supply = <®_3v3>;
+ };
+};
+
+&ecspi3 {
+ cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ status = "okay";
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rgmii-id";
+ phy-handle = <&rgmii_phy>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Microchip KSZ9031RNX PHY */
+ rgmii_phy: ethernet-phy@0 {
+ reg = <0>;
+ interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <300>;
+ };
+ };
+};
+
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+ ddc-i2c-bus = <&i2c2>;
+ status = "okay";
+};
+
+&i2c1 {
+ sgtl5000: audio-codec@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0xa>;
+ #sound-dai-cells = <0>;
+ clocks = <&clks 201>;
+ VDDA-supply = <®_3v3>;
+ VDDIO-supply = <®_3v3>;
+ VDDD-supply = <®_1v8>;
+ };
+};
+
+/* DDC */
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&i2c3 {
+ adc@49 {
+ compatible = "ti,ads1015";
+ reg = <0x49>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* can2_l */
+ channel@4 {
+ reg = <4>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can2_h */
+ channel@5 {
+ reg = <5>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_l */
+ channel@6 {
+ reg = <6>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_h */
+ channel@7 {
+ reg = <7>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel@0 {
+ status = "okay";
+
+ port@4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&sata {
+ status = "okay";
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&spdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spdif>;
+ status = "okay";
+};
+
+&ssi1 {
+ #sound-dai-cells = <0>;
+ fsl,mode = "ac97-slave";
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&uart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>;
+ status = "okay";
+};
+
+&usbotg {
+ pinctrl-0 = <&pinctrl_usbotg &pinctrl_usbotg_id>;
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ non-removable;
+ vmmc-supply = <®_wifi>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+ status = "okay";
+
+ wifi {
+ compatible = "ti,wl1271";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi>;
+ interrupts-extended = <&gpio1 30 IRQ_TYPE_LEVEL_HIGH>;
+ ref-clock-frequency = "38400000";
+ tcxo-clock-frequency = "19200000";
+ };
+};
+
+&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_MCLK__CCM_CLKO1 0x030b0
+ MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0
+ MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0
+ MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0
+ MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
+ >;
+ };
+
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT7__GPIO4_IO28 0x1b0b0
+ >;
+ };
+
+ pinctrl_can2: can2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x80000000
+ MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x80000000
+ >;
+ };
+
+ pinctrl_can3: can3grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x1b0b1
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
+ MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
+ MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
+ /* CS */
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x000b1
+ >;
+ };
+
+ pinctrl_ecspi2: ecspi2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
+ MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
+ MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
+ MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1
+ >;
+ };
+
+ pinctrl_ecspi2_cs: ecspi2csgrp {
+ fsl,pins = <
+ /* ADC128S022 CS */
+ MX6QDL_PAD_DISP0_DAT4__GPIO4_IO25 0x1b0b1
+ >;
+ };
+
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
+ MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
+ MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
+ MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x000b1
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b030
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b030
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b030
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x10030
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x10030
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x10030
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x10030
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x10030
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x10030
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x10030
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x10030
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x10030
+
+ /* Phy reset */
+ MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
+ MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28 0x1b0b1
+ >;
+ };
+
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <
+ /* NOTE: DDC is done via I2C2, so DON'T
+ * configure DDC pins for HDMI!
+ */
+ MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ /* DDC */
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_leds: ledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x1b0b0
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__PWM1_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_spdif: spdifgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_16__SPDIF_IN 0x1b0b0
+ MX6QDL_PAD_GPIO_19__SPDIF_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D28__UART2_DTE_CTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_D29__UART2_DTE_RTS_B 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL1__UART5_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW1__UART5_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg_id: usbotgidgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID 0x1f058
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170b9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100b9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_wifi: wifigrp {
+ fsl,pins = <
+ /* WL12xx IRQ */
+ MX6QDL_PAD_ENET_TXD0__GPIO1_IO30 0x10880
+ >;
+ };
+
+ pinctrl_wifi_npd: wifinpd {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_RXD1__GPIO1_IO26 0x1b8b0
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6qdl-prti6q.dtsi b/arch/arm/boot/dts/imx6qdl-prti6q.dtsi
new file mode 100644
index 0000000000000..ed526d185f959
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-prti6q.dtsi
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ chosen {
+ stdout-path = &uart4;
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_usb_h1_vbus: regulator-h1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "h1-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ reg_usb_otg_vbus: regulator-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "otg-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1>;
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ temperature-sensor@70 {
+ compatible = "ti,tmp103";
+ reg = <0x70>;
+ };
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ phy_type = "utmi";
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ phy_type = "utmi";
+ dr_mode = "host";
+ disable-over-current;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_can1: can1grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x80000000
+ MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x80000000
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001f8b1
+ MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001f8b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170f9
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100f9
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170f9
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170f9
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170f9
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170f9
+ MX6QDL_PAD_GPIO_1__GPIO1_IO01 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17099
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10099
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17099
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17099
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17099
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17099
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17099
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17099
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17099
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17099
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__USB_OTG_OC 0x1b0b0
+ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0
+ >;
+ };
+};
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v7 3/5] ARM: dts: add Protonic VT7 board
From: Oleksij Rempel @ 2020-05-20 9:29 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, Rob Herring, Robin van der Gracht, linux-kernel,
Oleksij Rempel, NXP Linux Team, Pengutronix Kernel Team,
David Jander, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200520092937.15797-1-o.rempel@pengutronix.de>
The Protonic VT7 is a mid-class ISObus Virtual Terminal with a 7 inch
touchscreen display.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-prtvt7.dts | 472 ++++++++++++++++++++++++++++
2 files changed, 473 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-prtvt7.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8ce744f1cbfc9..66ee89e7929f9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -450,6 +450,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+ imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
imx6dl-riotboard.dtb \
imx6dl-sabreauto.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts b/arch/arm/boot/dts/imx6dl-prtvt7.dts
new file mode 100644
index 0000000000000..70e80195d648a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -0,0 +1,472 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2016 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/sound/fsl-imx-audmux.h>
+
+/ {
+ model = "Protonic VT7";
+ compatible = "prt,prtvt7", "fsl,imx6dl";
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x20000000>;
+ };
+
+ backlight_lcd: backlight-lcd {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 500000>;
+ brightness-levels = <0 20 81 248 1000>;
+ default-brightness-level = <20>;
+ num-interpolated-steps = <21>;
+ power-supply = <®_12v_bl>;
+ enable-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ };
+
+ display {
+ compatible = "fsl,imx-parallel-display";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_disp>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interface-pix-fmt = "rgb24";
+ status = "okay";
+
+ port@0 {
+ reg = <0>;
+
+ display_in: endpoint {
+ remote-endpoint = <&ipu1_di0_disp0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ esc {
+ label = "GPIO Key ESC";
+ linux,code = <KEY_ESC>;
+ gpios = <&gpio_pca 0 GPIO_ACTIVE_LOW>;
+ };
+
+ up {
+ label = "GPIO Key UP";
+ linux,code = <KEY_UP>;
+ gpios = <&gpio_pca 1 GPIO_ACTIVE_LOW>;
+ };
+
+ down {
+ label = "GPIO Key DOWN";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpio_pca 4 GPIO_ACTIVE_LOW>;
+ };
+
+ enter {
+ label = "GPIO Key Enter";
+ linux,code = <KEY_ENTER>;
+ gpios = <&gpio_pca 3 GPIO_ACTIVE_LOW>;
+ };
+
+ cycle {
+ label = "GPIO Key CYCLE";
+ linux,code = <KEY_CYCLEWINDOWS>;
+ gpios = <&gpio_pca 2 GPIO_ACTIVE_LOW>;
+ };
+
+ f1 {
+ label = "GPIO Key F1";
+ linux,code = <KEY_F1>;
+ gpios = <&gpio_pca 14 GPIO_ACTIVE_LOW>;
+ };
+
+ f2 {
+ label = "GPIO Key F2";
+ linux,code = <KEY_F2>;
+ gpios = <&gpio_pca 13 GPIO_ACTIVE_LOW>;
+ };
+
+ f3 {
+ label = "GPIO Key F3";
+ linux,code = <KEY_F3>;
+ gpios = <&gpio_pca 12 GPIO_ACTIVE_LOW>;
+ };
+
+ f4 {
+ label = "GPIO Key F4";
+ linux,code = <KEY_F4>;
+ gpios = <&gpio_pca 11 GPIO_ACTIVE_LOW>;
+ };
+
+ f5 {
+ label = "GPIO Key F5";
+ linux,code = <KEY_F5>;
+ gpios = <&gpio_pca 10 GPIO_ACTIVE_LOW>;
+ };
+
+ f6 {
+ label = "GPIO Key F6";
+ linux,code = <KEY_F6>;
+ gpios = <&gpio_pca 5 GPIO_ACTIVE_LOW>;
+ };
+
+ f7 {
+ label = "GPIO Key F7";
+ linux,code = <KEY_F7>;
+ gpios = <&gpio_pca 6 GPIO_ACTIVE_LOW>;
+ };
+
+ f8 {
+ label = "GPIO Key F8";
+ linux,code = <KEY_F8>;
+ gpios = <&gpio_pca 7 GPIO_ACTIVE_LOW>;
+ };
+
+ f9 {
+ label = "GPIO Key F9";
+ linux,code = <KEY_F9>;
+ gpios = <&gpio_pca 8 GPIO_ACTIVE_LOW>;
+ };
+
+ f10 {
+ label = "GPIO Key F10";
+ linux,code = <KEY_F10>;
+ gpios = <&gpio_pca 9 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ panel {
+ compatible = "innolux,g070y2t0ec";
+ backlight = <&backlight_lcd>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
+
+ reg_12v_bl: regulator-bl-12v {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_12v_bl>;
+ regulator-name = "12v-bl";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "prti6q-sgtl5000";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Line", "Line In Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "External Speaker", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <&ssi1>;
+ system-clock-frequency = <0>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&sgtl5000>;
+ bitclock-master;
+ frame-master;
+ };
+ };
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL5_VIDEO_DIV>;
+};
+
+&ecspi2 {
+ cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2>;
+ status = "okay";
+
+ tsc@0 {
+ compatible = "ti,tsc2046";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tsc>;
+ spi-max-frequency = <100000>;
+ interrupts-extended = <&gpio3 20 IRQ_TYPE_EDGE_FALLING>;
+ pendown-gpio = <&gpio3 20 GPIO_ACTIVE_HIGH>;
+ vcc-supply = <®_3v3>;
+
+ ti,vref-delay-usecs = /bits/ 16 <100>;
+
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <8000>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4800>;
+ ti,x-plate-ohms = /bits/ 16 <800>;
+ ti,y-plate-ohms = /bits/ 16 <300>;
+ ti,pressure-max = /bits/ 16 <4095>;
+
+ ti,skip-samples = <2>;
+ ti,sample-period-msecs = <10>;
+ ti,report-period-msecs = <30>;
+
+ ti,filter-tolerance = <80>;
+ ti,touch-resistance-threshold = <3500>;
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>;
+ status = "okay";
+
+ mux_ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN 0
+ IMX_AUDMUX_V2_PTCR_TFSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TCSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TFSDIR 0
+ IMX_AUDMUX_V2_PTCR_TCLKDIR IMX_AUDMUX_V2_PDCR_RXDSEL(2)
+ >;
+ };
+
+ mux_pins3 {
+ fsl,audmux-port = <2>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN IMX_AUDMUX_V2_PDCR_RXDSEL(0)
+ 0 IMX_AUDMUX_V2_PDCR_TXRXEN
+ >;
+ };
+};
+
+&can1 {
+ pinctrl-0 = <&pinctrl_can1 &pinctrl_can1phy>;
+};
+
+&i2c1 {
+ sgtl5000: codec@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0xa>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_codec>;
+ #sound-dai-cells = <0>;
+ clocks = <&clks 201>;
+ VDDA-supply = <®_3v3>;
+ VDDIO-supply = <®_3v3>;
+ VDDD-supply = <®_1v8>;
+ };
+};
+
+&i2c3 {
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+
+ gpio_pca: gpio@74 {
+ compatible = "nxp,pca9539";
+ reg = <0x74>;
+ interrupts-extended = <&gpio4 5 IRQ_TYPE_LEVEL_LOW>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+};
+
+&ipu1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
+ status = "okay";
+};
+
+&ipu1_di0_disp0 {
+ remote-endpoint = <&display_in>;
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "okay";
+};
+
+&ssi1 {
+ #sound-dai-cells = <0>;
+ fsl,mode = "i2s-slave";
+ status = "okay";
+};
+
+&usbh1 {
+ status = "disabled";
+};
+
+&vpu {
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_MCLK__CCM_CLKO1 0x030b0
+ MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0
+ MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0
+ MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0
+ MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
+ >;
+ };
+
+ pinctrl_can1phy: can1phy {
+ fsl,pins = <
+ /* CAN1_SR */
+ MX6QDL_PAD_KEY_COL3__GPIO4_IO12 0x13070
+ /* CAN1_TERM */
+ MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
+ >;
+ };
+
+ pinctrl_codec: codecgrp {
+ fsl,pins = <
+ /* AUDIO_nRESET */
+ MX6QDL_PAD_CSI0_VSYNC__GPIO5_IO21 0x1f0b0
+ >;
+ };
+
+ pinctrl_ecspi2: ecspi2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
+ MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
+ MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
+ MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1
+ >;
+ };
+
+ pinctrl_ipu1_csi0: ipu1csi0grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x1b0b0
+ MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x1b0b0
+ /* ITU656_nRESET */
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ /* ITU656_nPDN */
+ MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20 0x1b0b0
+ >;
+ };
+
+ pinctrl_ipu1_disp: ipudisp1grp {
+ fsl,pins = <
+ MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0xb0
+ MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0xb0
+
+ MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0xb0
+ MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0xb0
+ MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0xb0
+ MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0xb0
+ MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0xb0
+ MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0xb0
+ MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0xb0
+ MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0xb0
+
+ MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0xb0
+ MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0xb0
+ MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0xb0
+ MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0xb0
+ MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0xb0
+ MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0xb0
+ MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0xb0
+ MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0xb0
+
+ MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0xb0
+ MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0xb0
+ MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0xb0
+ MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0xb0
+ MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0xb0
+ MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0xb0
+ MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0xb0
+ MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0xb0
+ >;
+ };
+
+ pinctrl_leds: ledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_reg_12v_bl: 12blgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x1b0b0
+ >;
+ };
+
+ pinctrl_tsc: tscgrp {
+
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x1b0b0
+ MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
+ >;
+ };
+};
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox