* Re: [PATCH V4 5/6] arm64: mm: introduce 52-bit userspace support
From: Steve Capper @ 2018-12-06 14:52 UTC (permalink / raw)
To: Suzuki Poulose
Cc: ard.biesheuvel@linaro.org, jcm@redhat.com, Will Deacon,
linux-mm@kvack.org, Catalin Marinas, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <c87c833a-7dfc-6cd4-aad7-119df9bd7178@arm.com>
On Thu, Dec 06, 2018 at 02:35:20PM +0000, Suzuki K Poulose wrote:
>
>
> On 06/12/2018 12:26, Steve Capper wrote:
> > On Wed, Dec 05, 2018 at 06:22:27PM +0000, Suzuki K Poulose wrote:
> > > Hi Steve,
> > >
> > [...]
> > > I think we may need a check for the secondary CPUs to make sure that they have
> > > the 52bit support once the boot CPU has decided to use the feature and fail the
> > > CPU bring up (just like we do for the granule support).
> > >
> > > Suzuki
> >
> > Hi Suzuki,
> > I have just written a patch to detect a mismatch between 52-bit VA that
> > is being tested now.
> >
> > As 52-bit kernel VA support is coming in future, the patch checks for a
> > mismatch during the secondary boot path and, if one is found, prevents
> > the secondary from booting (and displays an error message to the user).
>
> Right now, it is the boot CPU which decides the Userspace 52bit VA, isn't it ?
> Irrespective of the kernel VA support, the userspace must be able to run on
> all the CPUs on the system, right ? So don't we need it now, with this series ?
Hi Suzuki,
Yes the boot CPU determines vabits_user. My idea was to have the
secondary CPUs check to see if vabits_user was 52, and if so, then check
to see if it's capable of supporting 52-bit. If not, then it stops
booting (and sets a flag to indicate why).
This check will be valid for 52-bit userspace support and also valid for
52-bit kernel support (as the check is performed before the secondary
mmu is enabled). I didn't want to write a higher level detection
routine for the userspace support and then have to re-write it later
when introducing 52-bit kernel support.
I'm happy to do what works though, I thought this way was simplest :-).
Cheers,
--
Steve
_______________________________________________
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 4/6] dts: imx: add common imx7ulp dtsi support
From: Shawn Guo @ 2018-12-06 14:51 UTC (permalink / raw)
To: A.s. Dong
Cc: devicetree@vger.kernel.org, dongas86@gmail.com,
linux@armlinux.org.uk, robh+dt@kernel.org, dl-linux-imx,
kernel@pengutronix.de, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1541862478-7839-5-git-send-email-aisheng.dong@nxp.com>
On Sat, Nov 10, 2018 at 03:13:08PM +0000, A.s. Dong wrote:
> The i.MX 7ULP family of processors features NXP's advanced implementation
> of the Arm Cortex-A7 core, the Arm Cortex-M4 core, as well as a 3D and 2D
> Graphics Processing Units (GPUs).
>
> This patch aims to add the initial support including:
> 1) CLK
> 2) GPIO PTC, PTD, PTE, PTF
> 3) uSDHC 1/2
> 4) LPUART 4/5/6/7
> 5) LPI2C 6/7
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Changed the subject prefix like 'ARM: dts: imx: ...', and applied the
patch.
Shawn
_______________________________________________
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 3/6] ARM: imx: add initial support for imx7ulp
From: Shawn Guo @ 2018-12-06 14:48 UTC (permalink / raw)
To: Fabio Estevam
Cc: Dong Aisheng, Dong Aisheng, Russell King - ARM Linux, Rob Herring,
NXP Linux Team, Sascha Hauer, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAOMZO5A1R-aoDg5d9OLApArz51daaKcpfyDYJH9hWPnjKCH5=g@mail.gmail.com>
On Sat, Nov 10, 2018 at 01:51:57PM -0200, Fabio Estevam wrote:
> On Sat, Nov 10, 2018 at 1:14 PM A.s. Dong <aisheng.dong@nxp.com> wrote:
>
> > +static void __init imx7ulp_init_machine(void)
> > +{
> > + imx7ulp_pm_init();
> > +
> > + mxc_set_cpu_type(MXC_CPU_IMX7ULP);
> > + /* FIXME: so far there is still no way to retrieve SoC version */
> > + imx_print_silicon_rev("i.MX7ULP", IMX_CHIP_REVISION_UNKNOWN);
>
> Then maybe just do not call imx_print_silicon_rev() for now?
I'm with Fabio on this. Applied the patch by dropping the call and
FIXME comment above.
Shawn
_______________________________________________
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 v16 06/16] lib: fdt: add a helper function for handling memory range property
From: Rob Herring @ 2018-12-06 14:47 UTC (permalink / raw)
To: AKASHI, Takahiro
Cc: prudo, Herbert Xu, Baoquan He, Ard Biesheuvel, Catalin Marinas,
bhsharma, Frank Rowand, Will Deacon, linux-kernel@vger.kernel.org,
Heiko Carstens, David Howells, devicetree, Arnd Bergmann,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, kexec,
Martin Schwidefsky, James Morse, dyoung, David Miller,
Vivek Goyal
In-Reply-To: <20181115055254.2812-7-takahiro.akashi@linaro.org>
On Wed, Nov 14, 2018 at 11:52 PM AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
>
> Added function, fdt_setprop_reg(), will be used later to handle
> kexec-specific property in arm64's kexec_file implementation.
> It will possibly be merged into libfdt in the future.
You generally can't modify libfdt files. Any changes will be blown
away with the next dtc sync (there's one in -next now). Though here
you are creating a new location with fdt code. lib/ is just a shim to
the actual libfdt code. Don't put any implementation there. You can
add this to drivers/of/fdt_address.c for the short term, but it still
needs to go upstream.
Otherwise, the implementation looks fine to me.
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: devicetree@vger.kernel.org
> ---
> include/linux/libfdt.h | 26 ++++++++++++++++++++
> lib/Makefile | 2 +-
> lib/fdt_addresses.c | 56 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 83 insertions(+), 1 deletion(-)
> create mode 100644 lib/fdt_addresses.c
_______________________________________________
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 2/6] dt-bindings: fsl: add imx7ulp pm related components bindings
From: Shawn Guo @ 2018-12-06 14:45 UTC (permalink / raw)
To: A.s. Dong
Cc: devicetree@vger.kernel.org, dongas86@gmail.com,
linux@armlinux.org.uk, robh+dt@kernel.org, dl-linux-imx,
kernel@pengutronix.de, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1541862478-7839-3-git-send-email-aisheng.dong@nxp.com>
On Sat, Nov 10, 2018 at 03:13:00PM +0000, A.s. Dong wrote:
> Add imx7ulp pm related components bindings
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: devicetree@vger.kernel.org
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Applied, 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 V5 1/6] dt-bindings: fsl: add compatible for imx7ulp evk
From: Shawn Guo @ 2018-12-06 14:45 UTC (permalink / raw)
To: Fabio Estevam
Cc: Dong Aisheng,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Dong Aisheng, Russell King - ARM Linux, Rob Herring,
NXP Linux Team, Sascha Hauer, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAOMZO5Cv4+s7xxibCYFQTJ=1bwshfQQ17GBmKYDu-w3cFbxLDQ@mail.gmail.com>
On Sat, Nov 10, 2018 at 01:50:13PM -0200, Fabio Estevam wrote:
> On Sat, Nov 10, 2018 at 1:13 PM A.s. Dong <aisheng.dong@nxp.com> wrote:
>
> Even a single line commit log would be better here.
+1
I added a simple commit log and applied the patch.
Shawn
>
> > Cc: devicetree@vger.kernel.org
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4.14 21/55] drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut()
From: Greg Kroah-Hartman @ 2018-12-06 14:38 UTC (permalink / raw)
To: linux-kernel
Cc: Lyude Paul, Neil Armstrong, Maxime Ripard, Greg Kroah-Hartman,
stable, Sean Paul, dri-devel, Kevin Hilman, Carlo Caione,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20181206143001.749982936@linuxfoundation.org>
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude Paul <lyude@redhat.com>
commit 97b2a3180a559a33852ac0cd77904166069484fd upstream.
Currently on driver bringup with KASAN enabled, meson triggers an OOB
memory access as shown below:
[ 117.904528] ==================================================================
[ 117.904560] BUG: KASAN: global-out-of-bounds in meson_viu_set_osd_lut+0x7a0/0x890
[ 117.904588] Read of size 4 at addr ffff20000a63ce24 by task systemd-udevd/498
[ 117.904601]
[ 118.083372] CPU: 4 PID: 498 Comm: systemd-udevd Not tainted 4.20.0-rc3Lyude-Test+ #20
[ 118.091143] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 118.099768] Call trace:
[ 118.102181] dump_backtrace+0x0/0x3e8
[ 118.105796] show_stack+0x14/0x20
[ 118.109083] dump_stack+0x130/0x1c4
[ 118.112539] print_address_description+0x60/0x25c
[ 118.117214] kasan_report+0x1b4/0x368
[ 118.120851] __asan_report_load4_noabort+0x18/0x20
[ 118.125566] meson_viu_set_osd_lut+0x7a0/0x890
[ 118.129953] meson_viu_init+0x10c/0x290
[ 118.133741] meson_drv_bind_master+0x474/0x748
[ 118.138141] meson_drv_bind+0x10/0x18
[ 118.141760] try_to_bring_up_master+0x3d8/0x768
[ 118.146249] component_add+0x214/0x570
[ 118.149978] meson_dw_hdmi_probe+0x18/0x20 [meson_dw_hdmi]
[ 118.155404] platform_drv_probe+0x98/0x138
[ 118.159455] really_probe+0x2a0/0xa70
[ 118.163070] driver_probe_device+0x1b4/0x2d8
[ 118.167299] __driver_attach+0x200/0x280
[ 118.171189] bus_for_each_dev+0x10c/0x1a8
[ 118.175144] driver_attach+0x38/0x50
[ 118.178681] bus_add_driver+0x330/0x608
[ 118.182471] driver_register+0x140/0x388
[ 118.186361] __platform_driver_register+0xc8/0x108
[ 118.191117] meson_dw_hdmi_platform_driver_init+0x1c/0x1000 [meson_dw_hdmi]
[ 118.198022] do_one_initcall+0x12c/0x3bc
[ 118.201883] do_init_module+0x1fc/0x638
[ 118.205673] load_module+0x4b4c/0x6808
[ 118.209387] __se_sys_init_module+0x2e8/0x3c0
[ 118.213699] __arm64_sys_init_module+0x68/0x98
[ 118.218100] el0_svc_common+0x104/0x210
[ 118.221893] el0_svc_handler+0x48/0xb8
[ 118.225594] el0_svc+0x8/0xc
[ 118.228429]
[ 118.229887] The buggy address belongs to the variable:
[ 118.235007] eotf_33_linear_mapping+0x84/0xc0
[ 118.239301]
[ 118.240752] Memory state around the buggy address:
[ 118.245522] ffff20000a63cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 118.252695] ffff20000a63cd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 118.259850] >ffff20000a63ce00: 00 00 00 00 04 fa fa fa fa fa fa fa 00 00 00 00
[ 118.267000] ^
[ 118.271222] ffff20000a63ce80: 00 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
[ 118.278393] ffff20000a63cf00: 00 00 00 00 00 00 00 00 00 00 00 00 04 fa fa fa
[ 118.285542] ==================================================================
[ 118.292699] Disabling lock debugging due to kernel taint
It seems that when looping through the OSD EOTF LUT maps, we use the
same max iterator for OETF: 20. This is wrong though, since 20*2 is 40,
which means that we'll stop out of bounds on the EOTF maps.
But, this whole thing is already confusing enough to read through as-is,
so let's just replace all of the hardcoded sizes with
OSD_(OETF/EOTF)_LUT_SIZE / 2.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: <stable@vger.kernel.org> # v4.10+
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181125012117.31915-1-lyude@redhat.com
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/meson/meson_viu.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -184,18 +184,18 @@ void meson_viu_set_osd_lut(struct meson_
if (lut_sel == VIU_LUT_OSD_OETF) {
writel(0, priv->io_base + _REG(addr_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(r_map[i * 2] | (r_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
writel(r_map[OSD_OETF_LUT_SIZE - 1] | (g_map[0] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(g_map[i * 2 + 1] | (g_map[i * 2 + 2] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(b_map[i * 2] | (b_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
@@ -211,18 +211,18 @@ void meson_viu_set_osd_lut(struct meson_
} else if (lut_sel == VIU_LUT_OSD_EOTF) {
writel(0, priv->io_base + _REG(addr_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_EOTF_LUT_SIZE / 2); i++)
writel(r_map[i * 2] | (r_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
writel(r_map[OSD_EOTF_LUT_SIZE - 1] | (g_map[0] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_EOTF_LUT_SIZE / 2); i++)
writel(g_map[i * 2 + 1] | (g_map[i * 2 + 2] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_EOTF_LUT_SIZE / 2); i++)
writel(b_map[i * 2] | (b_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4.14 20/55] drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config
From: Greg Kroah-Hartman @ 2018-12-06 14:38 UTC (permalink / raw)
To: linux-kernel
Cc: Lyude Paul, Neil Armstrong, Greg Kroah-Hartman, dri-devel, stable,
Sean Paul, Kevin Hilman, Daniel Vetter, Carlo Caione,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20181206143001.749982936@linuxfoundation.org>
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude Paul <lyude@redhat.com>
commit 995b278e4723b26f8ebf0e7c119286d16c712747 upstream.
Seeing as we use this registermap in the context of our IRQ handlers, we
need to be using spinlocks for reading/writing registers so that we can
still read them from IRQ handlers without having to grab any mutexes and
accidentally sleep. We don't currently do this, as pointed out by
lockdep:
[ 18.403770] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
[ 18.406744] in_atomic(): 1, irqs_disabled(): 128, pid: 68, name: kworker/u17:0
[ 18.413864] INFO: lockdep is turned off.
[ 18.417675] irq event stamp: 12
[ 18.420778] hardirqs last enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
[ 18.429510] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
[ 18.437345] softirqs last enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
[ 18.446684] softirqs last disabled at (0): [<0000000000000000>] (null)
[ 18.453979] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G W O 4.20.0-rc3Lyude-Test+ #9
[ 18.469839] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 18.480037] Workqueue: hci0 hci_power_on [bluetooth]
[ 18.487138] Call trace:
[ 18.494192] dump_backtrace+0x0/0x1b8
[ 18.501280] show_stack+0x14/0x20
[ 18.508361] dump_stack+0xbc/0xf4
[ 18.515427] ___might_sleep+0x140/0x1d8
[ 18.522515] __might_sleep+0x50/0x88
[ 18.529582] __mutex_lock+0x60/0x870
[ 18.536621] mutex_lock_nested+0x1c/0x28
[ 18.543660] regmap_lock_mutex+0x10/0x18
[ 18.550696] regmap_read+0x38/0x70
[ 18.557727] dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
[ 18.564804] __handle_irq_event_percpu+0xac/0x410
[ 18.571891] handle_irq_event_percpu+0x34/0x88
[ 18.578982] handle_irq_event+0x48/0x78
[ 18.586051] handle_fasteoi_irq+0xac/0x160
[ 18.593061] generic_handle_irq+0x24/0x38
[ 18.599989] __handle_domain_irq+0x60/0xb8
[ 18.606857] gic_handle_irq+0x50/0xa0
[ 18.613659] el1_irq+0xb4/0x130
[ 18.620394] debug_lockdep_rcu_enabled+0x2c/0x30
[ 18.627111] schedule+0x38/0xa0
[ 18.633781] schedule_timeout+0x3a8/0x510
[ 18.640389] wait_for_common+0x15c/0x180
[ 18.646905] wait_for_completion+0x14/0x20
[ 18.653319] mmc_wait_for_req_done+0x28/0x168
[ 18.659693] mmc_wait_for_req+0xa8/0xe8
[ 18.665978] mmc_wait_for_cmd+0x64/0x98
[ 18.672180] mmc_io_rw_direct_host+0x94/0x130
[ 18.678385] mmc_io_rw_direct+0x10/0x18
[ 18.684516] sdio_enable_func+0xe8/0x1d0
[ 18.690627] btsdio_open+0x24/0xc0 [btsdio]
[ 18.696821] hci_dev_do_open+0x64/0x598 [bluetooth]
[ 18.703025] hci_power_on+0x50/0x270 [bluetooth]
[ 18.709163] process_one_work+0x2a0/0x6e0
[ 18.715252] worker_thread+0x40/0x448
[ 18.721310] kthread+0x12c/0x130
[ 18.727326] ret_from_fork+0x10/0x1c
[ 18.735555] ------------[ cut here ]------------
[ 18.741430] do not call blocking ops when !TASK_RUNNING; state=2 set at [<000000006265ec59>] wait_for_common+0x140/0x180
[ 18.752417] WARNING: CPU: 0 PID: 68 at kernel/sched/core.c:6096 __might_sleep+0x7c/0x88
[ 18.760553] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod
btsdio bluetooth snd_soc_hdmi_codec dw_hdmi_i2s_audio ecdh_generic
brcmfmac brcmutil cfg80211 rfkill ir_nec_decoder meson_dw_hdmi(O)
dw_hdmi rc_geekbox meson_rng meson_ir ao_cec rng_core rc_core cec
leds_pwm efivars nfsd ip_tables x_tables crc32_generic f2fs uas
meson_gxbb_wdt pwm_meson efivarfs ipv6
[ 18.799469] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G W O 4.20.0-rc3Lyude-Test+ #9
[ 18.808858] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 18.818045] Workqueue: hci0 hci_power_on [bluetooth]
[ 18.824088] pstate: 80000085 (Nzcv daIf -PAN -UAO)
[ 18.829891] pc : __might_sleep+0x7c/0x88
[ 18.835722] lr : __might_sleep+0x7c/0x88
[ 18.841256] sp : ffff000008003cb0
[ 18.846751] x29: ffff000008003cb0 x28: 0000000000000000
[ 18.852269] x27: ffff00000938e000 x26: ffff800010283000
[ 18.857726] x25: ffff800010353280 x24: ffff00000868ef50
[ 18.863166] x23: 0000000000000000 x22: 0000000000000000
[ 18.868551] x21: 0000000000000000 x20: 000000000000038c
[ 18.873850] x19: ffff000008cd08c0 x18: 0000000000000010
[ 18.879081] x17: ffff000008a68cb0 x16: 0000000000000000
[ 18.884197] x15: 0000000000aaaaaa x14: 0e200e200e200e20
[ 18.889239] x13: 0000000000000001 x12: 00000000ffffffff
[ 18.894261] x11: ffff000008adfa48 x10: 0000000000000001
[ 18.899517] x9 : ffff0000092a0158 x8 : 0000000000000000
[ 18.904674] x7 : ffff00000812136c x6 : 0000000000000000
[ 18.909895] x5 : 0000000000000000 x4 : 0000000000000001
[ 18.915080] x3 : 0000000000000007 x2 : 0000000000000007
[ 18.920269] x1 : 99ab8e9ebb6c8500 x0 : 0000000000000000
[ 18.925443] Call trace:
[ 18.929904] __might_sleep+0x7c/0x88
[ 18.934311] __mutex_lock+0x60/0x870
[ 18.938687] mutex_lock_nested+0x1c/0x28
[ 18.943076] regmap_lock_mutex+0x10/0x18
[ 18.947453] regmap_read+0x38/0x70
[ 18.951842] dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
[ 18.956269] __handle_irq_event_percpu+0xac/0x410
[ 18.960712] handle_irq_event_percpu+0x34/0x88
[ 18.965176] handle_irq_event+0x48/0x78
[ 18.969612] handle_fasteoi_irq+0xac/0x160
[ 18.974058] generic_handle_irq+0x24/0x38
[ 18.978501] __handle_domain_irq+0x60/0xb8
[ 18.982938] gic_handle_irq+0x50/0xa0
[ 18.987351] el1_irq+0xb4/0x130
[ 18.991734] debug_lockdep_rcu_enabled+0x2c/0x30
[ 18.996180] schedule+0x38/0xa0
[ 19.000609] schedule_timeout+0x3a8/0x510
[ 19.005064] wait_for_common+0x15c/0x180
[ 19.009513] wait_for_completion+0x14/0x20
[ 19.013951] mmc_wait_for_req_done+0x28/0x168
[ 19.018402] mmc_wait_for_req+0xa8/0xe8
[ 19.022809] mmc_wait_for_cmd+0x64/0x98
[ 19.027177] mmc_io_rw_direct_host+0x94/0x130
[ 19.031563] mmc_io_rw_direct+0x10/0x18
[ 19.035922] sdio_enable_func+0xe8/0x1d0
[ 19.040294] btsdio_open+0x24/0xc0 [btsdio]
[ 19.044742] hci_dev_do_open+0x64/0x598 [bluetooth]
[ 19.049228] hci_power_on+0x50/0x270 [bluetooth]
[ 19.053687] process_one_work+0x2a0/0x6e0
[ 19.058143] worker_thread+0x40/0x448
[ 19.062608] kthread+0x12c/0x130
[ 19.067064] ret_from_fork+0x10/0x1c
[ 19.071513] irq event stamp: 12
[ 19.075937] hardirqs last enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
[ 19.083560] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
[ 19.091401] softirqs last enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
[ 19.100801] softirqs last disabled at (0): [<0000000000000000>] (null)
[ 19.108135] ---[ end trace 38c4920787b88c75 ]---
So, fix this by enabling the fast_io option in our regmap config so that
regmap uses spinlocks for locking instead of mutexes.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 3f68be7d8e96 ("drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: <stable@vger.kernel.org> # v4.12+
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181124191238.28276-1-lyude@redhat.com
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -697,6 +697,7 @@ static const struct regmap_config meson_
.reg_read = meson_dw_hdmi_reg_read,
.reg_write = meson_dw_hdmi_reg_write,
.max_register = 0x10000,
+ .fast_io = true,
};
static bool meson_hdmi_connector_is_available(struct device *dev)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4.19 19/41] drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config
From: Greg Kroah-Hartman @ 2018-12-06 14:38 UTC (permalink / raw)
To: linux-kernel
Cc: Lyude Paul, Neil Armstrong, Greg Kroah-Hartman, dri-devel, stable,
Sean Paul, Kevin Hilman, Daniel Vetter, Carlo Caione,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20181206142949.757402551@linuxfoundation.org>
4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude Paul <lyude@redhat.com>
commit 995b278e4723b26f8ebf0e7c119286d16c712747 upstream.
Seeing as we use this registermap in the context of our IRQ handlers, we
need to be using spinlocks for reading/writing registers so that we can
still read them from IRQ handlers without having to grab any mutexes and
accidentally sleep. We don't currently do this, as pointed out by
lockdep:
[ 18.403770] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
[ 18.406744] in_atomic(): 1, irqs_disabled(): 128, pid: 68, name: kworker/u17:0
[ 18.413864] INFO: lockdep is turned off.
[ 18.417675] irq event stamp: 12
[ 18.420778] hardirqs last enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
[ 18.429510] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
[ 18.437345] softirqs last enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
[ 18.446684] softirqs last disabled at (0): [<0000000000000000>] (null)
[ 18.453979] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G W O 4.20.0-rc3Lyude-Test+ #9
[ 18.469839] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 18.480037] Workqueue: hci0 hci_power_on [bluetooth]
[ 18.487138] Call trace:
[ 18.494192] dump_backtrace+0x0/0x1b8
[ 18.501280] show_stack+0x14/0x20
[ 18.508361] dump_stack+0xbc/0xf4
[ 18.515427] ___might_sleep+0x140/0x1d8
[ 18.522515] __might_sleep+0x50/0x88
[ 18.529582] __mutex_lock+0x60/0x870
[ 18.536621] mutex_lock_nested+0x1c/0x28
[ 18.543660] regmap_lock_mutex+0x10/0x18
[ 18.550696] regmap_read+0x38/0x70
[ 18.557727] dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
[ 18.564804] __handle_irq_event_percpu+0xac/0x410
[ 18.571891] handle_irq_event_percpu+0x34/0x88
[ 18.578982] handle_irq_event+0x48/0x78
[ 18.586051] handle_fasteoi_irq+0xac/0x160
[ 18.593061] generic_handle_irq+0x24/0x38
[ 18.599989] __handle_domain_irq+0x60/0xb8
[ 18.606857] gic_handle_irq+0x50/0xa0
[ 18.613659] el1_irq+0xb4/0x130
[ 18.620394] debug_lockdep_rcu_enabled+0x2c/0x30
[ 18.627111] schedule+0x38/0xa0
[ 18.633781] schedule_timeout+0x3a8/0x510
[ 18.640389] wait_for_common+0x15c/0x180
[ 18.646905] wait_for_completion+0x14/0x20
[ 18.653319] mmc_wait_for_req_done+0x28/0x168
[ 18.659693] mmc_wait_for_req+0xa8/0xe8
[ 18.665978] mmc_wait_for_cmd+0x64/0x98
[ 18.672180] mmc_io_rw_direct_host+0x94/0x130
[ 18.678385] mmc_io_rw_direct+0x10/0x18
[ 18.684516] sdio_enable_func+0xe8/0x1d0
[ 18.690627] btsdio_open+0x24/0xc0 [btsdio]
[ 18.696821] hci_dev_do_open+0x64/0x598 [bluetooth]
[ 18.703025] hci_power_on+0x50/0x270 [bluetooth]
[ 18.709163] process_one_work+0x2a0/0x6e0
[ 18.715252] worker_thread+0x40/0x448
[ 18.721310] kthread+0x12c/0x130
[ 18.727326] ret_from_fork+0x10/0x1c
[ 18.735555] ------------[ cut here ]------------
[ 18.741430] do not call blocking ops when !TASK_RUNNING; state=2 set at [<000000006265ec59>] wait_for_common+0x140/0x180
[ 18.752417] WARNING: CPU: 0 PID: 68 at kernel/sched/core.c:6096 __might_sleep+0x7c/0x88
[ 18.760553] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod
btsdio bluetooth snd_soc_hdmi_codec dw_hdmi_i2s_audio ecdh_generic
brcmfmac brcmutil cfg80211 rfkill ir_nec_decoder meson_dw_hdmi(O)
dw_hdmi rc_geekbox meson_rng meson_ir ao_cec rng_core rc_core cec
leds_pwm efivars nfsd ip_tables x_tables crc32_generic f2fs uas
meson_gxbb_wdt pwm_meson efivarfs ipv6
[ 18.799469] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G W O 4.20.0-rc3Lyude-Test+ #9
[ 18.808858] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 18.818045] Workqueue: hci0 hci_power_on [bluetooth]
[ 18.824088] pstate: 80000085 (Nzcv daIf -PAN -UAO)
[ 18.829891] pc : __might_sleep+0x7c/0x88
[ 18.835722] lr : __might_sleep+0x7c/0x88
[ 18.841256] sp : ffff000008003cb0
[ 18.846751] x29: ffff000008003cb0 x28: 0000000000000000
[ 18.852269] x27: ffff00000938e000 x26: ffff800010283000
[ 18.857726] x25: ffff800010353280 x24: ffff00000868ef50
[ 18.863166] x23: 0000000000000000 x22: 0000000000000000
[ 18.868551] x21: 0000000000000000 x20: 000000000000038c
[ 18.873850] x19: ffff000008cd08c0 x18: 0000000000000010
[ 18.879081] x17: ffff000008a68cb0 x16: 0000000000000000
[ 18.884197] x15: 0000000000aaaaaa x14: 0e200e200e200e20
[ 18.889239] x13: 0000000000000001 x12: 00000000ffffffff
[ 18.894261] x11: ffff000008adfa48 x10: 0000000000000001
[ 18.899517] x9 : ffff0000092a0158 x8 : 0000000000000000
[ 18.904674] x7 : ffff00000812136c x6 : 0000000000000000
[ 18.909895] x5 : 0000000000000000 x4 : 0000000000000001
[ 18.915080] x3 : 0000000000000007 x2 : 0000000000000007
[ 18.920269] x1 : 99ab8e9ebb6c8500 x0 : 0000000000000000
[ 18.925443] Call trace:
[ 18.929904] __might_sleep+0x7c/0x88
[ 18.934311] __mutex_lock+0x60/0x870
[ 18.938687] mutex_lock_nested+0x1c/0x28
[ 18.943076] regmap_lock_mutex+0x10/0x18
[ 18.947453] regmap_read+0x38/0x70
[ 18.951842] dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
[ 18.956269] __handle_irq_event_percpu+0xac/0x410
[ 18.960712] handle_irq_event_percpu+0x34/0x88
[ 18.965176] handle_irq_event+0x48/0x78
[ 18.969612] handle_fasteoi_irq+0xac/0x160
[ 18.974058] generic_handle_irq+0x24/0x38
[ 18.978501] __handle_domain_irq+0x60/0xb8
[ 18.982938] gic_handle_irq+0x50/0xa0
[ 18.987351] el1_irq+0xb4/0x130
[ 18.991734] debug_lockdep_rcu_enabled+0x2c/0x30
[ 18.996180] schedule+0x38/0xa0
[ 19.000609] schedule_timeout+0x3a8/0x510
[ 19.005064] wait_for_common+0x15c/0x180
[ 19.009513] wait_for_completion+0x14/0x20
[ 19.013951] mmc_wait_for_req_done+0x28/0x168
[ 19.018402] mmc_wait_for_req+0xa8/0xe8
[ 19.022809] mmc_wait_for_cmd+0x64/0x98
[ 19.027177] mmc_io_rw_direct_host+0x94/0x130
[ 19.031563] mmc_io_rw_direct+0x10/0x18
[ 19.035922] sdio_enable_func+0xe8/0x1d0
[ 19.040294] btsdio_open+0x24/0xc0 [btsdio]
[ 19.044742] hci_dev_do_open+0x64/0x598 [bluetooth]
[ 19.049228] hci_power_on+0x50/0x270 [bluetooth]
[ 19.053687] process_one_work+0x2a0/0x6e0
[ 19.058143] worker_thread+0x40/0x448
[ 19.062608] kthread+0x12c/0x130
[ 19.067064] ret_from_fork+0x10/0x1c
[ 19.071513] irq event stamp: 12
[ 19.075937] hardirqs last enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
[ 19.083560] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
[ 19.091401] softirqs last enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
[ 19.100801] softirqs last disabled at (0): [<0000000000000000>] (null)
[ 19.108135] ---[ end trace 38c4920787b88c75 ]---
So, fix this by enabling the fast_io option in our regmap config so that
regmap uses spinlocks for locking instead of mutexes.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 3f68be7d8e96 ("drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: <stable@vger.kernel.org> # v4.12+
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181124191238.28276-1-lyude@redhat.com
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -706,6 +706,7 @@ static const struct regmap_config meson_
.reg_read = meson_dw_hdmi_reg_read,
.reg_write = meson_dw_hdmi_reg_write,
.max_register = 0x10000,
+ .fast_io = true,
};
static bool meson_hdmi_connector_is_available(struct device *dev)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4.19 20/41] drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut()
From: Greg Kroah-Hartman @ 2018-12-06 14:39 UTC (permalink / raw)
To: linux-kernel
Cc: Lyude Paul, Neil Armstrong, Maxime Ripard, Greg Kroah-Hartman,
stable, Sean Paul, dri-devel, Kevin Hilman, Carlo Caione,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20181206142949.757402551@linuxfoundation.org>
4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude Paul <lyude@redhat.com>
commit 97b2a3180a559a33852ac0cd77904166069484fd upstream.
Currently on driver bringup with KASAN enabled, meson triggers an OOB
memory access as shown below:
[ 117.904528] ==================================================================
[ 117.904560] BUG: KASAN: global-out-of-bounds in meson_viu_set_osd_lut+0x7a0/0x890
[ 117.904588] Read of size 4 at addr ffff20000a63ce24 by task systemd-udevd/498
[ 117.904601]
[ 118.083372] CPU: 4 PID: 498 Comm: systemd-udevd Not tainted 4.20.0-rc3Lyude-Test+ #20
[ 118.091143] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 118.099768] Call trace:
[ 118.102181] dump_backtrace+0x0/0x3e8
[ 118.105796] show_stack+0x14/0x20
[ 118.109083] dump_stack+0x130/0x1c4
[ 118.112539] print_address_description+0x60/0x25c
[ 118.117214] kasan_report+0x1b4/0x368
[ 118.120851] __asan_report_load4_noabort+0x18/0x20
[ 118.125566] meson_viu_set_osd_lut+0x7a0/0x890
[ 118.129953] meson_viu_init+0x10c/0x290
[ 118.133741] meson_drv_bind_master+0x474/0x748
[ 118.138141] meson_drv_bind+0x10/0x18
[ 118.141760] try_to_bring_up_master+0x3d8/0x768
[ 118.146249] component_add+0x214/0x570
[ 118.149978] meson_dw_hdmi_probe+0x18/0x20 [meson_dw_hdmi]
[ 118.155404] platform_drv_probe+0x98/0x138
[ 118.159455] really_probe+0x2a0/0xa70
[ 118.163070] driver_probe_device+0x1b4/0x2d8
[ 118.167299] __driver_attach+0x200/0x280
[ 118.171189] bus_for_each_dev+0x10c/0x1a8
[ 118.175144] driver_attach+0x38/0x50
[ 118.178681] bus_add_driver+0x330/0x608
[ 118.182471] driver_register+0x140/0x388
[ 118.186361] __platform_driver_register+0xc8/0x108
[ 118.191117] meson_dw_hdmi_platform_driver_init+0x1c/0x1000 [meson_dw_hdmi]
[ 118.198022] do_one_initcall+0x12c/0x3bc
[ 118.201883] do_init_module+0x1fc/0x638
[ 118.205673] load_module+0x4b4c/0x6808
[ 118.209387] __se_sys_init_module+0x2e8/0x3c0
[ 118.213699] __arm64_sys_init_module+0x68/0x98
[ 118.218100] el0_svc_common+0x104/0x210
[ 118.221893] el0_svc_handler+0x48/0xb8
[ 118.225594] el0_svc+0x8/0xc
[ 118.228429]
[ 118.229887] The buggy address belongs to the variable:
[ 118.235007] eotf_33_linear_mapping+0x84/0xc0
[ 118.239301]
[ 118.240752] Memory state around the buggy address:
[ 118.245522] ffff20000a63cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 118.252695] ffff20000a63cd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 118.259850] >ffff20000a63ce00: 00 00 00 00 04 fa fa fa fa fa fa fa 00 00 00 00
[ 118.267000] ^
[ 118.271222] ffff20000a63ce80: 00 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
[ 118.278393] ffff20000a63cf00: 00 00 00 00 00 00 00 00 00 00 00 00 04 fa fa fa
[ 118.285542] ==================================================================
[ 118.292699] Disabling lock debugging due to kernel taint
It seems that when looping through the OSD EOTF LUT maps, we use the
same max iterator for OETF: 20. This is wrong though, since 20*2 is 40,
which means that we'll stop out of bounds on the EOTF maps.
But, this whole thing is already confusing enough to read through as-is,
so let's just replace all of the hardcoded sizes with
OSD_(OETF/EOTF)_LUT_SIZE / 2.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: <stable@vger.kernel.org> # v4.10+
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181125012117.31915-1-lyude@redhat.com
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/meson/meson_viu.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -184,18 +184,18 @@ void meson_viu_set_osd_lut(struct meson_
if (lut_sel == VIU_LUT_OSD_OETF) {
writel(0, priv->io_base + _REG(addr_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(r_map[i * 2] | (r_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
writel(r_map[OSD_OETF_LUT_SIZE - 1] | (g_map[0] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(g_map[i * 2 + 1] | (g_map[i * 2 + 2] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(b_map[i * 2] | (b_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
@@ -211,18 +211,18 @@ void meson_viu_set_osd_lut(struct meson_
} else if (lut_sel == VIU_LUT_OSD_EOTF) {
writel(0, priv->io_base + _REG(addr_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_EOTF_LUT_SIZE / 2); i++)
writel(r_map[i * 2] | (r_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
writel(r_map[OSD_EOTF_LUT_SIZE - 1] | (g_map[0] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_EOTF_LUT_SIZE / 2); i++)
writel(g_map[i * 2 + 1] | (g_map[i * 2 + 2] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_EOTF_LUT_SIZE / 2); i++)
writel(b_map[i * 2] | (b_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
_______________________________________________
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 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Russell King - ARM Linux @ 2018-12-06 14:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: mark.rutland, julien.thierry, marc.zyngier, will.deacon,
Morten.Rasmussen, Qais.Yousef, dietmar.eggemann, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPdUABPbni+1H=tTvA5wKe8Rc8EPTFKtLGMwQ8yLcb3=gg@mail.gmail.com>
On Thu, Dec 06, 2018 at 03:30:22PM +0100, Krzysztof Kozlowski wrote:
> On Thu, 6 Dec 2018 at 15:07, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> >
> > On Thu, Dec 06, 2018 at 02:54:10PM +0100, Krzysztof Kozlowski wrote:
> > > On Thu, 6 Dec 2018 at 13:40, Russell King - ARM Linux
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > On Thu, Dec 06, 2018 at 11:24:27AM +0100, Krzysztof Kozlowski wrote:
> > > > > On Thu, 6 Dec 2018 at 11:01, Russell King - ARM Linux
> > > > > <linux@armlinux.org.uk> wrote:
> > > > > > I've no idea based on what you've supplied given that the SoC
> > > > > > maintainers are responsible for writing the code to deal with hotplug
> > > > > > etc, and Exynos's code there is something of a maze. It's not clear
> > > > > > which bits are being used. I think you at the very least need to debug
> > > > > > to find out whether the problem is at CPU down or CPU up.
> > > > > >
> > > > > > From the ARM architecture point of view, for Cortex A9, all the
> > > > > > processor function instances should be identical. The only difference
> > > > > > as a result of the patch is that we'll be calling smp_processor_id()
> > > > > > early (which should be fine), and indirecting through the cpu_vtable[]
> > > > > > array rather than merely dereferencing the processor struct.
> > > > > >
> > > > > > What about checking dmesg - messages from offline CPUs do not appear
> > > > > > on the console(s) but are still logged in the kernel log.
> > > > > >
> > > > > > You could try making PROC_VTABLE() the same as PROC_TABLE() (iow,
> > > > > > always access cpu_vtable[0]) to see whether it's the smp_processor_id()
> > > > > > that's causing your problem or not. If it is, then try and work out
> > > > > > which of the processor functions is causing it by restoring
> > > > > > PROC_VTABLE() and then switching each from PROC_VTABLE() to
> > > > > > PROC_TABLE() until it does work.
> > > > >
> > > > > Thanks for hints!
> > > >
> > > > So I can plan, how long do you think it will take to get some results
> > > > from my suggestions above?
> > >
> > > For Suspend to RAM, on v4.20-rc3, this warning appears:
> > > [ 84.046722] WARNING: CPU: 1 PID: 0 at
> > > ../arch/arm/include/asm/proc-fns.h:124
> > > secondary_start_kernel+0x214/0x26c
> > > (difference between dcache_clean_area)
> > > The secondary CPUs bringup fails with ETIMEDOUT.
> >
> > That basically means that the dcache_clean_area method for CPU1
> > differs from the dcache_clean_area method for CPU0. If all your
> > CPUs are identical, that definitely should not be happening.
> >
> > Hmm. Interestingly, OMAP4430 passes hotplug tests just fine.
> >
> > Please try this patch.
>
> This fixes both hotplug and suspend to RAM. I was trying to narrow why
> the pointers to all processor functions differ. During first boot they
> were OK but it seems they were changed just before suspend.
Thanks for testing. I think this is probably a better patch which
should end up with the same result.
I suspect no one else has noticed because most people have big.Little
support disabled - that'd explain why it doesn't show up on OMAP4.
diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index 81d0efb055c6..44f9776139a8 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -274,6 +274,13 @@
.endm
.macro define_processor_functions name:req, dabort:req, pabort:req, nommu=0, suspend=0, bugs=0
+/*
+ * If we are building for big.Little with branch predictor hardening,
+ * we need the processor function tables to remain available after boot.
+ */
+#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
+ .rodata
+#endif
.type \name\()_processor_functions, #object
.align 2
ENTRY(\name\()_processor_functions)
@@ -309,6 +316,9 @@ ENTRY(\name\()_processor_functions)
.endif
.size \name\()_processor_functions, . - \name\()_processor_functions
+#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
+ .previous
+#endif
.endm
.macro define_cache_functions name:req
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 08/34] dt-bindings: arm: Convert PMU binding to json-schema
From: Will Deacon @ 2018-12-06 14:37 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Kumar Gala, ARM-SoC Maintainers,
Sean Hudson, Frank Rowand, linux-kernel@vger.kernel.org,
Grant Likely, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+YsVB8Ew=cb5W54eirMpAAOR7ApahCbHOtp2m3wpJYSg@mail.gmail.com>
On Wed, Dec 05, 2018 at 09:42:04AM -0600, Rob Herring wrote:
> On Wed, Dec 5, 2018 at 4:08 AM Will Deacon <will.deacon@arm.com> wrote:
> > On Mon, Dec 03, 2018 at 03:31:57PM -0600, Rob Herring wrote:
> > > +properties:
> > > + compatible:
> > > + oneOf:
> > > + - items:
> > > + - enum:
> > > + - apm,potenza-pmu
> > > + - arm,armv8-pmuv3
> > > + - arm,cortex-a73-pmu
> > > + - arm,cortex-a72-pmu
> > > + - arm,cortex-a57-pmu
> > > + - arm,cortex-a53-pmu
> > > + - arm,cortex-a35-pmu
> > > + - arm,cortex-a17-pmu
> > > + - arm,cortex-a15-pmu
> > > + - arm,cortex-a12-pmu
> > > + - arm,cortex-a9-pmu
> > > + - arm,cortex-a8-pmu
> > > + - arm,cortex-a7-pmu
> > > + - arm,cortex-a5-pmu
> > > + - arm,arm11mpcore-pmu
> > > + - arm,arm1176-pmu
> > > + - arm,arm1136-pmu
> > > + - brcm,vulcan-pmu
> > > + - cavium,thunder-pmu
> > > + - qcom,scorpion-pmu
> > > + - qcom,scorpion-mp-pmu
> > > + - qcom,krait-pmu
> > > + - items:
> > > + - const: arm,cortex-a7-pmu
> > > + - const: arm,cortex-a15-pmu
> >
> > What do these last two mean?
>
> The first list only allows a single compatible string. This list says
> there are 2 and that the compatible property should be:
> compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu";
>
> Which shows up here:
> arch/arm/boot/dts/sun6i-a31.dtsi: compatible =
> "arm,cortex-a7-pmu", "arm,cortex-a15-pmu";
> arch/arm/boot/dts/sun7i-a20.dtsi: compatible =
> "arm,cortex-a7-pmu", "arm,cortex-a15-pmu";
>
> Maybe the dts is wrong and should be fixed?
Yes, that's wrong and you could end up with the kernel exposing the wrong
events to userspace. So I think we can fix the .dts and leave the binding
without this.
> > > +required:
> > > + - compatible
> >
> > I probably said this before, but I do think that it's a shame to lose the
> > example binding, especially for something like the PMU where you can
> > pretty much take an example and bang in your own IRQ numbers to get it
> > up and running.
>
> I just thought it is so trivial that it didn't add much. I think most
> folks would copy-n-paste from an actual dts file which has all the
> other nodes you just need to update addresses and irq nums.
True... even more of a reason to fix thise sun* .dts files then!
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: [RESEND PATCH 2/4] mtd: spi-nor: mtk-quadspi: use ofpart for parsing partitions
From: Boris Brezillon @ 2018-12-06 14:36 UTC (permalink / raw)
To: Ryder Lee
Cc: devicetree, Guochun Mao, Weijie Gao, linux-kernel, Marek Vasut,
Rob Herring, linux-mtd, linux-mediatek, Brian Norris,
linux-arm-kernel
In-Reply-To: <6cca6844f426d4ad4e7c878420b363cfb34499aa.1543472168.git.ryder.lee@mediatek.com>
On Thu, 29 Nov 2018 14:29:54 +0800
Ryder Lee <ryder.lee@mediatek.com> wrote:
> From: Guochun Mao <guochun.mao@mediatek.com>
>
> Replace mtd_device_register with mtd_device_parse_register for
> parsing partitions and add ofpart support.
What's the problem with the default partition parser table [1]?
[1]https://elixir.bootlin.com/linux/latest/source/drivers/mtd/mtdpart.c#L793
_______________________________________________
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 5/6] arm64: mm: introduce 52-bit userspace support
From: Suzuki K Poulose @ 2018-12-06 14:35 UTC (permalink / raw)
To: Steve Capper
Cc: ard.biesheuvel@linaro.org, jcm@redhat.com, Will Deacon,
linux-mm@kvack.org, Catalin Marinas, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181206122603.GB17473@capper-debian.cambridge.arm.com>
On 06/12/2018 12:26, Steve Capper wrote:
> On Wed, Dec 05, 2018 at 06:22:27PM +0000, Suzuki K Poulose wrote:
>> Hi Steve,
>>
> [...]
>> I think we may need a check for the secondary CPUs to make sure that they have
>> the 52bit support once the boot CPU has decided to use the feature and fail the
>> CPU bring up (just like we do for the granule support).
>>
>> Suzuki
>
> Hi Suzuki,
> I have just written a patch to detect a mismatch between 52-bit VA that
> is being tested now.
>
> As 52-bit kernel VA support is coming in future, the patch checks for a
> mismatch during the secondary boot path and, if one is found, prevents
> the secondary from booting (and displays an error message to the user).
Right now, it is the boot CPU which decides the Userspace 52bit VA, isn't it ?
Irrespective of the kernel VA support, the userspace must be able to run on
all the CPUs on the system, right ? So don't we need it now, with this series ?
Cheers
Suzuki
_______________________________________________
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 1/2] ftrace: Allow ftrace_replace_code() to be schedulable
From: Anders Roxell @ 2018-12-06 14:32 UTC (permalink / raw)
To: rostedt
Cc: Kees Cook, Arnd Bergmann, Catalin Marinas, Will Deacon,
Linux Kernel Mailing List, mingo, Linux ARM
In-Reply-To: <20181205183303.828422192@goodmis.org>
On Wed, 5 Dec 2018 at 19:33, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
>
> The function ftrace_replace_code() is the ftrace engine that does the
> work to modify all the nops into the calls to the function callback in
> all the functions being traced.
>
> The generic version which is normally called from stop machine, but an
> architecture can implement a non stop machine version and still use the
> generic ftrace_replace_code(). When an architecture does this,
> ftrace_replace_code() may be called from a schedulable context, where
> it can allow the code to be preemptible, and schedule out.
>
> In order to allow an architecture to make ftrace_replace_code()
> schedulable, a new command flag is added called:
>
> FTRACE_SCHEDULABLE
>
> Which can be or'd to the command that is passed to
> ftrace_modify_all_code() that calls ftrace_replace_code() and will have
> it call cond_resched() in the loop that modifies the nops into the
> calls to the ftrace trampolines.
>
> Link: http://lkml.kernel.org/r/20181204192903.8193-1-anders.roxell@linaro.org
>
> Reported-by: Anders Roxell <anders.roxell@linaro.org>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Cheers,
Anders
> ---
> include/linux/ftrace.h | 1 +
> kernel/trace/ftrace.c | 19 ++++++++++++++++---
> 2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index dd16e8218db3..c281b16baef9 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -389,6 +389,7 @@ enum {
> FTRACE_UPDATE_TRACE_FUNC = (1 << 2),
> FTRACE_START_FUNC_RET = (1 << 3),
> FTRACE_STOP_FUNC_RET = (1 << 4),
> + FTRACE_SCHEDULABLE = (1 << 5),
> };
>
> /*
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 77734451cb05..74fdcacba514 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -77,6 +77,11 @@
> #define ASSIGN_OPS_HASH(opsname, val)
> #endif
>
> +enum {
> + FTRACE_MODIFY_ENABLE_FL = (1 << 0),
> + FTRACE_MODIFY_SCHEDULABLE_FL = (1 << 1),
> +};
> +
> static struct ftrace_ops ftrace_list_end __read_mostly = {
> .func = ftrace_stub,
> .flags = FTRACE_OPS_FL_RECURSION_SAFE | FTRACE_OPS_FL_STUB,
> @@ -2415,10 +2420,12 @@ __ftrace_replace_code(struct dyn_ftrace *rec, int enable)
> return -1; /* unknow ftrace bug */
> }
>
> -void __weak ftrace_replace_code(int enable)
> +void __weak ftrace_replace_code(int mod_flags)
> {
> struct dyn_ftrace *rec;
> struct ftrace_page *pg;
> + int enable = mod_flags & FTRACE_MODIFY_ENABLE_FL;
> + int schedulable = mod_flags & FTRACE_MODIFY_SCHEDULABLE_FL;
> int failed;
>
> if (unlikely(ftrace_disabled))
> @@ -2435,6 +2442,8 @@ void __weak ftrace_replace_code(int enable)
> /* Stop processing */
> return;
> }
> + if (schedulable)
> + cond_resched();
> } while_for_each_ftrace_rec();
> }
>
> @@ -2548,8 +2557,12 @@ int __weak ftrace_arch_code_modify_post_process(void)
> void ftrace_modify_all_code(int command)
> {
> int update = command & FTRACE_UPDATE_TRACE_FUNC;
> + int mod_flags = 0;
> int err = 0;
>
> + if (command & FTRACE_SCHEDULABLE)
> + mod_flags = FTRACE_MODIFY_SCHEDULABLE_FL;
> +
> /*
> * If the ftrace_caller calls a ftrace_ops func directly,
> * we need to make sure that it only traces functions it
> @@ -2567,9 +2580,9 @@ void ftrace_modify_all_code(int command)
> }
>
> if (command & FTRACE_UPDATE_CALLS)
> - ftrace_replace_code(1);
> + ftrace_replace_code(mod_flags | FTRACE_MODIFY_ENABLE_FL);
> else if (command & FTRACE_DISABLE_CALLS)
> - ftrace_replace_code(0);
> + ftrace_replace_code(mod_flags);
>
> if (update && ftrace_trace_function != ftrace_ops_list_func) {
> function_trace_op = set_function_trace_op;
> --
> 2.19.1
>
>
_______________________________________________
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/2] arm64: ftrace: Set FTRACE_SCHEDULABLE before ftrace_modify_all_code()
From: Anders Roxell @ 2018-12-06 14:31 UTC (permalink / raw)
To: Will Deacon
Cc: Kees Cook, Arnd Bergmann, Catalin Marinas,
Linux Kernel Mailing List, rostedt, mingo, Linux ARM
In-Reply-To: <20181206132007.GB27744@arm.com>
On Thu, 6 Dec 2018 at 14:19, Will Deacon <will.deacon@arm.com> wrote:
>
> On Wed, Dec 05, 2018 at 12:48:54PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> >
> > It has been reported that ftrace_replace_code() which is called by
> > ftrace_modify_all_code() can cause a soft lockup warning for an
> > allmodconfig kernel. This is because all the debug options enabled
> > causes the loop in ftrace_replace_code() (which loops over all the
> > functions being enabled where there can be 10s of thousands), is too
> > slow, and never schedules out.
> >
> > To solve this, setting FTRACE_SCHEDULABLE to the command passed into
> > ftrace_replace_code() will make it call cond_resched() in the loop,
> > which prevents the soft lockup warning from triggering.
> >
> > Link: http://lkml.kernel.org/r/20181204192903.8193-1-anders.roxell@linaro.org
> >
> > Reported-by: Anders Roxell <anders.roxell@linaro.org>
> > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> > ---
> > arch/arm64/kernel/ftrace.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
> > index 57e962290df3..9a8de0a79f97 100644
> > --- a/arch/arm64/kernel/ftrace.c
> > +++ b/arch/arm64/kernel/ftrace.c
> > @@ -193,6 +193,7 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
> >
> > void arch_ftrace_update_code(int command)
> > {
> > + command |= FTRACE_SCHEDULABLE;
> > ftrace_modify_all_code(command);
> > }
>
> Bikeshed: I'd probably go for FTRACE_MAY_SLEEP, but I'm not going to die
> on that hill so...
>
> Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Cheers,
Anders
>
> Thanks, Steve!
>
> 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 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Krzysztof Kozlowski @ 2018-12-06 14:30 UTC (permalink / raw)
To: linux
Cc: mark.rutland, julien.thierry, marc.zyngier, will.deacon,
Morten.Rasmussen, Qais.Yousef, dietmar.eggemann, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20181206140717.GU30658@n2100.armlinux.org.uk>
On Thu, 6 Dec 2018 at 15:07, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
>
> On Thu, Dec 06, 2018 at 02:54:10PM +0100, Krzysztof Kozlowski wrote:
> > On Thu, 6 Dec 2018 at 13:40, Russell King - ARM Linux
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Thu, Dec 06, 2018 at 11:24:27AM +0100, Krzysztof Kozlowski wrote:
> > > > On Thu, 6 Dec 2018 at 11:01, Russell King - ARM Linux
> > > > <linux@armlinux.org.uk> wrote:
> > > > > I've no idea based on what you've supplied given that the SoC
> > > > > maintainers are responsible for writing the code to deal with hotplug
> > > > > etc, and Exynos's code there is something of a maze. It's not clear
> > > > > which bits are being used. I think you at the very least need to debug
> > > > > to find out whether the problem is at CPU down or CPU up.
> > > > >
> > > > > From the ARM architecture point of view, for Cortex A9, all the
> > > > > processor function instances should be identical. The only difference
> > > > > as a result of the patch is that we'll be calling smp_processor_id()
> > > > > early (which should be fine), and indirecting through the cpu_vtable[]
> > > > > array rather than merely dereferencing the processor struct.
> > > > >
> > > > > What about checking dmesg - messages from offline CPUs do not appear
> > > > > on the console(s) but are still logged in the kernel log.
> > > > >
> > > > > You could try making PROC_VTABLE() the same as PROC_TABLE() (iow,
> > > > > always access cpu_vtable[0]) to see whether it's the smp_processor_id()
> > > > > that's causing your problem or not. If it is, then try and work out
> > > > > which of the processor functions is causing it by restoring
> > > > > PROC_VTABLE() and then switching each from PROC_VTABLE() to
> > > > > PROC_TABLE() until it does work.
> > > >
> > > > Thanks for hints!
> > >
> > > So I can plan, how long do you think it will take to get some results
> > > from my suggestions above?
> >
> > For Suspend to RAM, on v4.20-rc3, this warning appears:
> > [ 84.046722] WARNING: CPU: 1 PID: 0 at
> > ../arch/arm/include/asm/proc-fns.h:124
> > secondary_start_kernel+0x214/0x26c
> > (difference between dcache_clean_area)
> > The secondary CPUs bringup fails with ETIMEDOUT.
>
> That basically means that the dcache_clean_area method for CPU1
> differs from the dcache_clean_area method for CPU0. If all your
> CPUs are identical, that definitely should not be happening.
>
> Hmm. Interestingly, OMAP4430 passes hotplug tests just fine.
>
> Please try this patch.
This fixes both hotplug and suspend to RAM. I was trying to narrow why
the pointers to all processor functions differ. During first boot they
were OK but it seems they were changed just before suspend.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Moving ARM dts files
From: Linus Walleij @ 2018-12-06 14:30 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Andrew Lunn, ext Tony Lindgren, Liviu Dudau, Masahiro Yamada,
thierry.reding@gmail.com, Rob Herring, Florian Fainelli,
Kevin Hilman, Gregory Clement, Michal Simek, Krzysztof Kozlowski,
arm-soc, Joel Stanley, Uwe Kleine-König, Andy Gross,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Jason Cooper, Simon Horman, Linux ARM, Jisheng Zhang,
Maxime Coquelin, Shawn Guo, Andreas Färber, Daniel Mack
In-Reply-To: <20181206140531.GX8952@piout.net>
On Thu, Dec 6, 2018 at 3:05 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 06/12/2018 07:58:24-0600, Rob Herring wrote:
> > On Thu, Dec 6, 2018 at 7:39 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > Hello,
> > >
> > > On Wed, Dec 05, 2018 at 09:01:59AM -0600, Rob Herring wrote:
> > > > i.MX23 is a Sigmatel chip STMP??
> > >
> > > I think the Freescale i.MX23 didn't exist at Sigmatel back then. AFAIK
> > > this is a new design using IP from Sigmatel after the aquisition.
> >
> > It is not. I was in the i.MX group which Sigmatel was merged into at
> > the time. Purely marketing rebranding.
> >
>
> Wouldn't it be easier to name the directory to the corresponding mach-*
> entry?
>
> So, imx23 and imx28 would go to mxs/, other imx in imx/. And this also
> solves the Marvell mess with the Synaptics Socs going in berlin/ and the
> other ones in mvebu/.
I like this idea.
We discussed merging all ARM reference design mach-* to one dir
if I just name that mach-arm then we get a convergence to the
vendor name in some organic way.
Yours,
Linus Walleij
_______________________________________________
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] kvm/arm: return 0 when the number of objects is not lessthan min
From: Andrew Jones @ 2018-12-06 14:29 UTC (permalink / raw)
To: peng.hao2
Cc: marc.zyngier, linux-kernel, christoffer.dall, linux-arm-kernel,
kvmarm
In-Reply-To: <201812060956304771332@zte.com.cn>
On Thu, Dec 06, 2018 at 09:56:30AM +0800, peng.hao2@zte.com.cn wrote:
> >On Wed, Dec 05, 2018 at 09:15:51AM +0800, Peng Hao wrote:
> >> Return 0 when there is enough kvm_mmu_memory_cache object.
> >>
> >> Signed-off-by: Peng Hao <peng.hao2@zte.com.cn>
> >> ---
> >> virt/kvm/arm/mmu.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> >> index ed162a6..fcda0ce 100644
> >> --- a/virt/kvm/arm/mmu.c
> >> +++ b/virt/kvm/arm/mmu.c
> >> @@ -127,7 +127,7 @@ static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
> >> while (cache->nobjs < max) {
> >> page = (void *)__get_free_page(PGALLOC_GFP);
> >> if (!page)
> >> - return -ENOMEM;
> >> + return cache->nobjs >= min ? 0 : -ENOMEM;
> >
> >This condition will never be true here, as the exact same condition is
> >already checked above, and if it had been true, then we wouldn't be here.
> >
> >What problem are you attempting to solve?
> >
> if (cache->nobjs >= min) ------here cache->nobjs<min,it can continue downward
> return 0;
> while (cache->nobjs < max) {
> page = (void *)__get_free_page(PGALLOC_GFP);
> if (!page)
> return -ENOMEM; -----here it is possible that (cache->nobjs >= min) and (cache->nobjs<max)
> cache->objects[cache->nobjs++] = page; ---here cache->nobjs increasing
> }
>
> I just think the logic of this function is to return 0 as long as (cache->nobjs >= min).
> thanks.
Oh, I see now. This is the case where we can do enough allocating to over
the min line, but fail before we get to the max.
Thanks,
drew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: exynos: remove display-port node from Arndale
From: Andrzej Hajda @ 2018-12-06 14:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-samsung-soc, Bartlomiej Zolnierkiewicz,
Andrzej Hajda, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <CGME20181206141638eucas1p17743a2bf7d02fce13825007938e07340@eucas1p1.samsung.com>
Arndale boards have wires for DSI and eDP panels, but in-kernel support
for eDP panels is broken for long time and breaks display support even on
boards with DSI panels.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
---
arch/arm/boot/dts/exynos5250-arndale.dts | 25 ------------------------
1 file changed, 25 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index e2e5b3f28686..2ca9319f48f2 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -181,31 +181,6 @@
};
};
-&dp {
- status = "okay";
- samsung,color-space = <0>;
- samsung,color-depth = <1>;
- samsung,link-rate = <0x0a>;
- samsung,lane-count = <4>;
-
- display-timings {
- native-mode = <&timing0>;
-
- timing0: timing {
- /* 2560x1600 DP panel */
- clock-frequency = <50000>;
- hactive = <2560>;
- vactive = <1600>;
- hfront-porch = <48>;
- hback-porch = <80>;
- hsync-len = <32>;
- vback-porch = <16>;
- vfront-porch = <8>;
- vsync-len = <6>;
- };
- };
-};
-
&fimd {
status = "okay";
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] mips/kgdb: prepare arch_kgdb_ops for constness
From: Daniel Thompson @ 2018-12-06 14:09 UTC (permalink / raw)
To: Christophe Leroy
Cc: Rich Felker, Gustavo A. R. Silva, Benjamin Herrenschmidt,
Will Deacon, linux-kernel, Paul Mackerras, sparclinux,
linux-hexagon, Yoshinori Sato, linux-sh, Michael Ellerman, x86,
Russell King, Ingo Molnar, Catalin Marinas, James Hogan,
linux-snps-arc, uclinux-h8-devel, linux-mips, Borislav Petkov,
nios2-dev, Thomas Gleixner, linux-arm-kernel, Michal Simek,
Vineet Gupta, Randy Dunlap, Douglas Anderson, Ralf Baechle,
Richard Kuo, Paul Burton, Jason Wessel, kgdb-bugreport,
Ley Foon Tan, linuxppc-dev, David S. Miller
In-Reply-To: <75bbcdd1e9277d66ebb06e349dda304bd01ce761.1543957194.git.christophe.leroy@c-s.fr>
On Wed, Dec 05, 2018 at 04:41:09AM +0000, Christophe Leroy wrote:
> MIPS is the only architecture modifying arch_kgdb_ops during init.
> This patch makes the init static, so that it can be changed to
> const in following patch, as recommended by checkpatch.pl
>
> Suggested-by: Paul Burton <paul.burton@mips.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
From my side this is
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Since this is a dependency for the next patch I'd be happy to take via
my tree... but would need an ack from the MIPS guys to do that.
Daniel.
> ---
> arch/mips/kernel/kgdb.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
> index eb6c0d582626..31eff1bec577 100644
> --- a/arch/mips/kernel/kgdb.c
> +++ b/arch/mips/kernel/kgdb.c
> @@ -394,18 +394,16 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,
> return -1;
> }
>
> -struct kgdb_arch arch_kgdb_ops;
> +struct kgdb_arch arch_kgdb_ops = {
> +#ifdef CONFIG_CPU_BIG_ENDIAN
> + .gdb_bpt_instr = { spec_op << 2, 0x00, 0x00, break_op },
> +#else
> + .gdb_bpt_instr = { break_op, 0x00, 0x00, spec_op << 2 },
> +#endif
> +};
>
> int kgdb_arch_init(void)
> {
> - union mips_instruction insn = {
> - .r_format = {
> - .opcode = spec_op,
> - .func = break_op,
> - }
> - };
> - memcpy(arch_kgdb_ops.gdb_bpt_instr, insn.byte, BREAK_INSTR_SIZE);
> -
> register_die_notifier(&kgdb_notifier);
>
> return 0;
> --
> 2.13.3
>
_______________________________________________
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 v8 0/8] arm64: untag user pointers passed to the kernel
From: Catalin Marinas @ 2018-12-06 14:08 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Mark Rutland, Kate Stewart, open list:DOCUMENTATION, Will Deacon,
Kostya Serebryany, open list:KERNEL SELFTEST FRAMEWORK,
Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
Jacob Bramley, Dmitry Vyukov, Evgenii Stepanov, Kees Cook,
Ruben Ayrapetyan, Ramana Radhakrishnan, Linux ARM,
Linux Memory Management List, Greg Kroah-Hartman, LKML,
Luc Van Oostenryck, Lee Smith, Andrew Morton, Robin Murphy,
Kirill A. Shutemov
In-Reply-To: <CAAeHK+x9CuqqgvP6pZEV1Gz5cFHNpwsuUDbWQFHFzTy8GBMPKA@mail.gmail.com>
On Thu, Dec 06, 2018 at 01:44:24PM +0100, Andrey Konovalov wrote:
> On Thu, Nov 29, 2018 at 7:16 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Thu, Nov 08, 2018 at 03:48:10PM +0100, Andrey Konovalov wrote:
> > > On Thu, Nov 8, 2018 at 3:36 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > > > Changes in v8:
> > > > - Rebased onto 65102238 (4.20-rc1).
> > > > - Added a note to the cover letter on why syscall wrappers/shims that untag
> > > > user pointers won't work.
> > > > - Added a note to the cover letter that this patchset has been merged into
> > > > the Pixel 2 kernel tree.
> > > > - Documentation fixes, in particular added a list of syscalls that don't
> > > > support tagged user pointers.
> > >
> > > I've changed the documentation to be more specific, please take a look.
> > >
> > > I haven't done anything about adding a way for the user to find out
> > > that the kernel supports this ABI extension. I don't know what would
> > > the the preferred way to do this, and we haven't received any comments
> > > on that from anybody else. Probing "on some innocuous syscall
> > > currently returning -EFAULT on tagged pointer arguments" works though,
> > > as you mentioned.
> >
> > We've had some internal discussions and also talked to some people at
> > Plumbers. I think the best option is to introduce an AT_FLAGS bit to
> > describe the ABI relaxation on tagged pointers. Vincenzo is going to
> > propose a patch on top of this series.
>
> So should I wait for a patch from Vincenzo before posting v9 or post
> it as is? Or try to develop this patch myself?
The reason Vincenzo hasn't posted his patches yet is that we are still
debating internally how to document which syscalls accept non-zero
top-byte, what to do with future syscalls for which we don't know the
semantics.
Happy to take the discussion to the public list if Vincenzo posts his
patches. The conclusion of the ABI discussion may have an impact on the
actual implementation that you are proposing in this series.
--
Catalin
_______________________________________________
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 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Russell King - ARM Linux @ 2018-12-06 14:07 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: mark.rutland, julien.thierry, marc.zyngier, will.deacon,
Morten.Rasmussen, Qais.Yousef, dietmar.eggemann, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPf=nGN53EK=+bjhKyaY_knMnY5J+JSW2Jb6KRQuJy37vA@mail.gmail.com>
On Thu, Dec 06, 2018 at 02:54:10PM +0100, Krzysztof Kozlowski wrote:
> On Thu, 6 Dec 2018 at 13:40, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> >
> > On Thu, Dec 06, 2018 at 11:24:27AM +0100, Krzysztof Kozlowski wrote:
> > > On Thu, 6 Dec 2018 at 11:01, Russell King - ARM Linux
> > > <linux@armlinux.org.uk> wrote:
> > > > I've no idea based on what you've supplied given that the SoC
> > > > maintainers are responsible for writing the code to deal with hotplug
> > > > etc, and Exynos's code there is something of a maze. It's not clear
> > > > which bits are being used. I think you at the very least need to debug
> > > > to find out whether the problem is at CPU down or CPU up.
> > > >
> > > > From the ARM architecture point of view, for Cortex A9, all the
> > > > processor function instances should be identical. The only difference
> > > > as a result of the patch is that we'll be calling smp_processor_id()
> > > > early (which should be fine), and indirecting through the cpu_vtable[]
> > > > array rather than merely dereferencing the processor struct.
> > > >
> > > > What about checking dmesg - messages from offline CPUs do not appear
> > > > on the console(s) but are still logged in the kernel log.
> > > >
> > > > You could try making PROC_VTABLE() the same as PROC_TABLE() (iow,
> > > > always access cpu_vtable[0]) to see whether it's the smp_processor_id()
> > > > that's causing your problem or not. If it is, then try and work out
> > > > which of the processor functions is causing it by restoring
> > > > PROC_VTABLE() and then switching each from PROC_VTABLE() to
> > > > PROC_TABLE() until it does work.
> > >
> > > Thanks for hints!
> >
> > So I can plan, how long do you think it will take to get some results
> > from my suggestions above?
>
> For Suspend to RAM, on v4.20-rc3, this warning appears:
> [ 84.046722] WARNING: CPU: 1 PID: 0 at
> ../arch/arm/include/asm/proc-fns.h:124
> secondary_start_kernel+0x214/0x26c
> (difference between dcache_clean_area)
> The secondary CPUs bringup fails with ETIMEDOUT.
That basically means that the dcache_clean_area method for CPU1
differs from the dcache_clean_area method for CPU0. If all your
CPUs are identical, that definitely should not be happening.
Hmm. Interestingly, OMAP4430 passes hotplug tests just fine.
Please try this patch.
arch/arm/mm/proc-arm1020.S | 6 ++----
arch/arm/mm/proc-arm1020e.S | 5 ++---
arch/arm/mm/proc-arm1022.S | 5 ++---
arch/arm/mm/proc-arm1026.S | 5 ++---
arch/arm/mm/proc-arm720.S | 5 ++---
arch/arm/mm/proc-arm740.S | 4 +---
arch/arm/mm/proc-arm7tdmi.S | 4 +---
arch/arm/mm/proc-arm920.S | 5 ++---
arch/arm/mm/proc-arm922.S | 5 ++---
arch/arm/mm/proc-arm925.S | 5 ++---
arch/arm/mm/proc-arm926.S | 4 +---
arch/arm/mm/proc-arm940.S | 4 +---
arch/arm/mm/proc-arm946.S | 4 +---
arch/arm/mm/proc-arm9tdmi.S | 4 +---
arch/arm/mm/proc-fa526.S | 4 +---
arch/arm/mm/proc-feroceon.S | 4 +---
arch/arm/mm/proc-mohawk.S | 4 +---
arch/arm/mm/proc-sa110.S | 4 +---
arch/arm/mm/proc-sa1100.S | 5 +----
arch/arm/mm/proc-v6.S | 4 +---
arch/arm/mm/proc-v7.S | 4 +---
arch/arm/mm/proc-v7m.S | 3 ++-
arch/arm/mm/proc-xsc3.S | 4 +---
arch/arm/mm/proc-xscale.S | 4 +---
24 files changed, 33 insertions(+), 72 deletions(-)
diff --git a/arch/arm/mm/proc-arm1020.S b/arch/arm/mm/proc-arm1020.S
index 774ef1323554..48e72b1a6351 100644
--- a/arch/arm/mm/proc-arm1020.S
+++ b/arch/arm/mm/proc-arm1020.S
@@ -470,13 +470,11 @@ ENTRY(cpu_arm1020_set_pte_ext)
arm1020_crval:
crval clear=0x0000593f, mmuset=0x00003935, ucset=0x00001930
- __INITDATA
+ .section ".rodata"
+
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm1020, dabort=v4t_early_abort, pabort=legacy_pabort
-
- .section ".rodata"
-
string cpu_arch_name, "armv5t"
string cpu_elf_name, "v5"
diff --git a/arch/arm/mm/proc-arm1020e.S b/arch/arm/mm/proc-arm1020e.S
index ae3c27b71594..1efc99b158b4 100644
--- a/arch/arm/mm/proc-arm1020e.S
+++ b/arch/arm/mm/proc-arm1020e.S
@@ -451,12 +451,11 @@ ENTRY(cpu_arm1020e_set_pte_ext)
arm1020e_crval:
crval clear=0x00007f3f, mmuset=0x00003935, ucset=0x00001930
- __INITDATA
+ .section ".rodata"
+
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm1020e, dabort=v4t_early_abort, pabort=legacy_pabort
- .section ".rodata"
-
string cpu_arch_name, "armv5te"
string cpu_elf_name, "v5"
string cpu_arm1020e_name, "ARM1020E"
diff --git a/arch/arm/mm/proc-arm1022.S b/arch/arm/mm/proc-arm1022.S
index dbb2413fe04d..84b911236d9c 100644
--- a/arch/arm/mm/proc-arm1022.S
+++ b/arch/arm/mm/proc-arm1022.S
@@ -436,12 +436,11 @@ ENTRY(cpu_arm1022_set_pte_ext)
arm1022_crval:
crval clear=0x00007f3f, mmuset=0x00003935, ucset=0x00001930
- __INITDATA
+ .section ".rodata"
+
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm1022, dabort=v4t_early_abort, pabort=legacy_pabort
- .section ".rodata"
-
string cpu_arch_name, "armv5te"
string cpu_elf_name, "v5"
string cpu_arm1022_name, "ARM1022"
diff --git a/arch/arm/mm/proc-arm1026.S b/arch/arm/mm/proc-arm1026.S
index 0b37b2cef9d3..802a54128041 100644
--- a/arch/arm/mm/proc-arm1026.S
+++ b/arch/arm/mm/proc-arm1026.S
@@ -430,12 +430,11 @@ ENTRY(cpu_arm1026_set_pte_ext)
arm1026_crval:
crval clear=0x00007f3f, mmuset=0x00003935, ucset=0x00001934
- __INITDATA
+ .section .rodata
+
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm1026, dabort=v5t_early_abort, pabort=legacy_pabort
- .section .rodata
-
string cpu_arch_name, "armv5tej"
string cpu_elf_name, "v5"
.align
diff --git a/arch/arm/mm/proc-arm720.S b/arch/arm/mm/proc-arm720.S
index 3651cd70e418..6b2215ea8b25 100644
--- a/arch/arm/mm/proc-arm720.S
+++ b/arch/arm/mm/proc-arm720.S
@@ -169,12 +169,11 @@ ENDPROC(cpu_arm720_reset)
arm720_crval:
crval clear=0x00002f3f, mmuset=0x0000213d, ucset=0x00000130
- __INITDATA
+ .section ".rodata"
+
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm720, dabort=v4t_late_abort, pabort=legacy_pabort
- .section ".rodata"
-
string cpu_arch_name, "armv4t"
string cpu_elf_name, "v4"
string cpu_arm710_name, "ARM710T"
diff --git a/arch/arm/mm/proc-arm740.S b/arch/arm/mm/proc-arm740.S
index 024fb7732407..95a3a2ea0076 100644
--- a/arch/arm/mm/proc-arm740.S
+++ b/arch/arm/mm/proc-arm740.S
@@ -119,13 +119,11 @@ ENDPROC(cpu_arm740_reset)
.size __arm740_setup, . - __arm740_setup
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm740, dabort=v4t_late_abort, pabort=legacy_pabort, nommu=1
- .section ".rodata"
-
string cpu_arch_name, "armv4"
string cpu_elf_name, "v4"
string cpu_arm740_name, "ARM740T"
diff --git a/arch/arm/mm/proc-arm7tdmi.S b/arch/arm/mm/proc-arm7tdmi.S
index 25472d94426d..32e55e146ce1 100644
--- a/arch/arm/mm/proc-arm7tdmi.S
+++ b/arch/arm/mm/proc-arm7tdmi.S
@@ -56,13 +56,11 @@ ENDPROC(cpu_arm7tdmi_reset)
ret lr
.size __arm7tdmi_setup, . - __arm7tdmi_setup
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm7tdmi, dabort=v4t_late_abort, pabort=legacy_pabort, nommu=1
- .section ".rodata"
-
string cpu_arch_name, "armv4t"
string cpu_elf_name, "v4"
string cpu_arm7tdmi_name, "ARM7TDMI"
diff --git a/arch/arm/mm/proc-arm920.S b/arch/arm/mm/proc-arm920.S
index 7a14bd4414c9..68ffbdafe3bd 100644
--- a/arch/arm/mm/proc-arm920.S
+++ b/arch/arm/mm/proc-arm920.S
@@ -436,12 +436,11 @@ ENDPROC(cpu_arm920_do_resume)
arm920_crval:
crval clear=0x00003f3f, mmuset=0x00003135, ucset=0x00001130
- __INITDATA
+ .section ".rodata"
+
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm920, dabort=v4t_early_abort, pabort=legacy_pabort, suspend=1
- .section ".rodata"
-
string cpu_arch_name, "armv4t"
string cpu_elf_name, "v4"
string cpu_arm920_name, "ARM920T"
diff --git a/arch/arm/mm/proc-arm922.S b/arch/arm/mm/proc-arm922.S
index edccfcdcd551..dddff4955e63 100644
--- a/arch/arm/mm/proc-arm922.S
+++ b/arch/arm/mm/proc-arm922.S
@@ -414,12 +414,11 @@ ENTRY(cpu_arm922_set_pte_ext)
arm922_crval:
crval clear=0x00003f3f, mmuset=0x00003135, ucset=0x00001130
- __INITDATA
+ .section ".rodata"
+
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm922, dabort=v4t_early_abort, pabort=legacy_pabort
- .section ".rodata"
-
string cpu_arch_name, "armv4t"
string cpu_elf_name, "v4"
string cpu_arm922_name, "ARM922T"
diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S
index 32a47cc19076..0a5006a04fb9 100644
--- a/arch/arm/mm/proc-arm925.S
+++ b/arch/arm/mm/proc-arm925.S
@@ -479,12 +479,11 @@ ENTRY(cpu_arm925_set_pte_ext)
arm925_crval:
crval clear=0x00007f3f, mmuset=0x0000313d, ucset=0x00001130
- __INITDATA
+ .section ".rodata"
+
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm925, dabort=v4t_early_abort, pabort=legacy_pabort
- .section ".rodata"
-
string cpu_arch_name, "armv4t"
string cpu_elf_name, "v4"
string cpu_arm925_name, "ARM925T"
diff --git a/arch/arm/mm/proc-arm926.S b/arch/arm/mm/proc-arm926.S
index fb827c633693..e6582a96c11f 100644
--- a/arch/arm/mm/proc-arm926.S
+++ b/arch/arm/mm/proc-arm926.S
@@ -461,13 +461,11 @@ ENDPROC(cpu_arm926_do_resume)
arm926_crval:
crval clear=0x00007f3f, mmuset=0x00003135, ucset=0x00001134
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm926, dabort=v5tj_early_abort, pabort=legacy_pabort, suspend=1
- .section ".rodata"
-
string cpu_arch_name, "armv5tej"
string cpu_elf_name, "v5"
string cpu_arm926_name, "ARM926EJ-S"
diff --git a/arch/arm/mm/proc-arm940.S b/arch/arm/mm/proc-arm940.S
index ee5b66f847c4..afb2d8018bbf 100644
--- a/arch/arm/mm/proc-arm940.S
+++ b/arch/arm/mm/proc-arm940.S
@@ -331,13 +331,11 @@ ENDPROC(arm940_dma_unmap_area)
.size __arm940_setup, . - __arm940_setup
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm940, dabort=nommu_early_abort, pabort=legacy_pabort, nommu=1
- .section ".rodata"
-
string cpu_arch_name, "armv4t"
string cpu_elf_name, "v4"
string cpu_arm940_name, "ARM940T"
diff --git a/arch/arm/mm/proc-arm946.S b/arch/arm/mm/proc-arm946.S
index 7361837edc31..bff88a20c37d 100644
--- a/arch/arm/mm/proc-arm946.S
+++ b/arch/arm/mm/proc-arm946.S
@@ -386,13 +386,11 @@ ENTRY(cpu_arm946_dcache_clean_area)
.size __arm946_setup, . - __arm946_setup
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm946, dabort=nommu_early_abort, pabort=legacy_pabort, nommu=1
- .section ".rodata"
-
string cpu_arch_name, "armv5te"
string cpu_elf_name, "v5t"
string cpu_arm946_name, "ARM946E-S"
diff --git a/arch/arm/mm/proc-arm9tdmi.S b/arch/arm/mm/proc-arm9tdmi.S
index 7fac8c612134..06b3503b5513 100644
--- a/arch/arm/mm/proc-arm9tdmi.S
+++ b/arch/arm/mm/proc-arm9tdmi.S
@@ -56,13 +56,11 @@ ENDPROC(cpu_arm9tdmi_reset)
ret lr
.size __arm9tdmi_setup, . - __arm9tdmi_setup
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions arm9tdmi, dabort=nommu_early_abort, pabort=legacy_pabort, nommu=1
- .section ".rodata"
-
string cpu_arch_name, "armv4t"
string cpu_elf_name, "v4"
string cpu_arm9tdmi_name, "ARM9TDMI"
diff --git a/arch/arm/mm/proc-fa526.S b/arch/arm/mm/proc-fa526.S
index 4001b73af4ee..c54d26708961 100644
--- a/arch/arm/mm/proc-fa526.S
+++ b/arch/arm/mm/proc-fa526.S
@@ -177,13 +177,11 @@ ENTRY(cpu_fa526_set_pte_ext)
fa526_cr1_set:
.word 0x397D
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions fa526, dabort=v4_early_abort, pabort=legacy_pabort
- .section ".rodata"
-
string cpu_arch_name, "armv4"
string cpu_elf_name, "v4"
string cpu_fa526_name, "FA526"
diff --git a/arch/arm/mm/proc-feroceon.S b/arch/arm/mm/proc-feroceon.S
index 92e08bf37aad..f2e4ee0de8ba 100644
--- a/arch/arm/mm/proc-feroceon.S
+++ b/arch/arm/mm/proc-feroceon.S
@@ -568,13 +568,11 @@ ENDPROC(cpu_feroceon_do_resume)
feroceon_crval:
crval clear=0x0000773f, mmuset=0x00003135, ucset=0x00001134
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions feroceon, dabort=v5t_early_abort, pabort=legacy_pabort
- .section ".rodata"
-
string cpu_arch_name, "armv5te"
string cpu_elf_name, "v5"
string cpu_feroceon_name, "Feroceon"
diff --git a/arch/arm/mm/proc-mohawk.S b/arch/arm/mm/proc-mohawk.S
index 6f07d2ef4ff2..6de3bb48ede4 100644
--- a/arch/arm/mm/proc-mohawk.S
+++ b/arch/arm/mm/proc-mohawk.S
@@ -416,13 +416,11 @@ ENDPROC(cpu_mohawk_do_resume)
mohawk_crval:
crval clear=0x00007f3f, mmuset=0x00003905, ucset=0x00001134
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions mohawk, dabort=v5t_early_abort, pabort=legacy_pabort
- .section ".rodata"
-
string cpu_arch_name, "armv5te"
string cpu_elf_name, "v5"
string cpu_mohawk_name, "Marvell 88SV331x"
diff --git a/arch/arm/mm/proc-sa110.S b/arch/arm/mm/proc-sa110.S
index ee2ce496239f..73818d7c19d2 100644
--- a/arch/arm/mm/proc-sa110.S
+++ b/arch/arm/mm/proc-sa110.S
@@ -186,13 +186,11 @@ ENTRY(cpu_sa110_set_pte_ext)
sa110_crval:
crval clear=0x00003f3f, mmuset=0x0000113d, ucset=0x00001130
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions sa110, dabort=v4_early_abort, pabort=legacy_pabort
- .section ".rodata"
-
string cpu_arch_name, "armv4"
string cpu_elf_name, "v4"
string cpu_sa110_name, "StrongARM-110"
diff --git a/arch/arm/mm/proc-sa1100.S b/arch/arm/mm/proc-sa1100.S
index 222d5836f666..377b06831b4c 100644
--- a/arch/arm/mm/proc-sa1100.S
+++ b/arch/arm/mm/proc-sa1100.S
@@ -224,17 +224,14 @@ ENDPROC(cpu_sa1100_do_resume)
sa1100_crval:
crval clear=0x00003f3f, mmuset=0x0000313d, ucset=0x00001130
- __INITDATA
-
/*
* SA1100 and SA1110 share the same function calls
*/
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions sa1100, dabort=v4_early_abort, pabort=legacy_pabort, suspend=1
- .section ".rodata"
-
string cpu_arch_name, "armv4"
string cpu_elf_name, "v4"
string cpu_sa1100_name, "StrongARM-1100"
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 06d890a2342b..7d18cda06b35 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -253,13 +253,11 @@ ENDPROC(cpu_v6_do_resume)
v6_crval:
crval clear=0x01e0fb7f, mmuset=0x00c0387d, ucset=0x00c0187c
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions v6, dabort=v6_early_abort, pabort=v6_pabort, suspend=1
- .section ".rodata"
-
string cpu_arch_name, "armv6"
string cpu_elf_name, "v6"
.align
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 339eb17c9808..bc028c5f262a 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -552,7 +552,7 @@ ENDPROC(__v7_setup)
__v7_setup_stack:
.space 4 * 7 @ 7 registers
- __INITDATA
+ .section ".rodata"
.weak cpu_v7_bugs_init
@@ -631,8 +631,6 @@ ENDPROC(__v7_setup)
define_processor_functions pj4b, dabort=v7_early_abort, pabort=v7_pabort, suspend=1
#endif
- .section ".rodata"
-
string cpu_arch_name, "armv7"
string cpu_elf_name, "v7"
.align
diff --git a/arch/arm/mm/proc-v7m.S b/arch/arm/mm/proc-v7m.S
index 47a5acc64433..8daf1b320fb4 100644
--- a/arch/arm/mm/proc-v7m.S
+++ b/arch/arm/mm/proc-v7m.S
@@ -166,6 +166,8 @@ ENDPROC(__v7m_setup)
/*
* Cortex-M7 processor functions
*/
+ .section ".rodata"
+
globl_equ cpu_cm7_proc_init, cpu_v7m_proc_init
globl_equ cpu_cm7_reset, cpu_v7m_reset
globl_equ cpu_cm7_do_idle, cpu_v7m_do_idle
@@ -174,7 +176,6 @@ ENDPROC(__v7m_setup)
define_processor_functions v7m, dabort=nommu_early_abort, pabort=legacy_pabort, nommu=1
define_processor_functions cm7, dabort=nommu_early_abort, pabort=legacy_pabort, nommu=1
- .section ".rodata"
string cpu_arch_name, "armv7m"
string cpu_elf_name "v7m"
string cpu_v7m_name "ARMv7-M"
diff --git a/arch/arm/mm/proc-xsc3.S b/arch/arm/mm/proc-xsc3.S
index 293dcc2c441f..ceffd974dd30 100644
--- a/arch/arm/mm/proc-xsc3.S
+++ b/arch/arm/mm/proc-xsc3.S
@@ -486,13 +486,11 @@ ENDPROC(cpu_xsc3_do_resume)
xsc3_crval:
crval clear=0x04002202, mmuset=0x00003905, ucset=0x00001900
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions xsc3, dabort=v5t_early_abort, pabort=legacy_pabort, suspend=1
- .section ".rodata"
-
string cpu_arch_name, "armv5te"
string cpu_elf_name, "v5"
string cpu_xsc3_name, "XScale-V3 based processor"
diff --git a/arch/arm/mm/proc-xscale.S b/arch/arm/mm/proc-xscale.S
index 3d75b7972fd1..27e1a9df561e 100644
--- a/arch/arm/mm/proc-xscale.S
+++ b/arch/arm/mm/proc-xscale.S
@@ -586,13 +586,11 @@ ENDPROC(cpu_xscale_do_resume)
xscale_crval:
crval clear=0x00003b07, mmuset=0x00003905, ucset=0x00001900
- __INITDATA
+ .section ".rodata"
@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
define_processor_functions xscale, dabort=v5t_early_abort, pabort=legacy_pabort, suspend=1
- .section ".rodata"
-
string cpu_arch_name, "armv5te"
string cpu_elf_name, "v5"
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops
From: Daniel Thompson @ 2018-12-06 14:07 UTC (permalink / raw)
To: Christophe Leroy
Cc: Rich Felker, Gustavo A. R. Silva, Benjamin Herrenschmidt,
Will Deacon, linux-kernel, Paul Mackerras, sparclinux,
linux-hexagon, Yoshinori Sato, linux-sh, Michael Ellerman, x86,
Russell King, Ingo Molnar, Catalin Marinas, James Hogan,
linux-snps-arc, uclinux-h8-devel, linux-mips, Borislav Petkov,
nios2-dev, Thomas Gleixner, linux-arm-kernel, Michal Simek,
Vineet Gupta, Randy Dunlap, Douglas Anderson, Ralf Baechle,
Richard Kuo, Paul Burton, Jason Wessel, kgdb-bugreport,
Ley Foon Tan, linuxppc-dev, David S. Miller
In-Reply-To: <6b1a19ffa0da02cff9b82b866ba31d57478501ce.1543957194.git.christophe.leroy@c-s.fr>
On Wed, Dec 05, 2018 at 04:41:11AM +0000, Christophe Leroy wrote:
> checkpatch.pl reports the following:
>
> WARNING: struct kgdb_arch should normally be const
> #28: FILE: arch/mips/kernel/kgdb.c:397:
> +struct kgdb_arch arch_kgdb_ops = {
>
> This report makes sense, as all other ops struct, this
> one should also be const. This patch does the change.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Similar to https://patchwork.kernel.org/patch/10701129/ I would be more
comfortable to see a resend with the relevant arch maintainers
explicitly called out with a Cc: entry here.
> ---
> arch/arc/kernel/kgdb.c | 2 +-
> arch/arm/kernel/kgdb.c | 2 +-
> arch/arm64/kernel/kgdb.c | 2 +-
> arch/h8300/kernel/kgdb.c | 2 +-
> arch/hexagon/kernel/kgdb.c | 2 +-
> arch/microblaze/kernel/kgdb.c | 2 +-
> arch/mips/kernel/kgdb.c | 2 +-
> arch/nios2/kernel/kgdb.c | 2 +-
> arch/powerpc/kernel/kgdb.c | 2 +-
> arch/sh/kernel/kgdb.c | 2 +-
> arch/sparc/kernel/kgdb_32.c | 2 +-
> arch/sparc/kernel/kgdb_64.c | 2 +-
> arch/x86/kernel/kgdb.c | 2 +-
> include/linux/kgdb.h | 2 +-
> 14 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
> index 9a3c34af2ae8..bfd04b442e36 100644
> --- a/arch/arc/kernel/kgdb.c
> +++ b/arch/arc/kernel/kgdb.c
> @@ -204,7 +204,7 @@ void kgdb_roundup_cpus(unsigned long flags)
> local_irq_disable();
> }
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> /* breakpoint instruction: TRAP_S 0x3 */
> #ifdef CONFIG_CPU_BIG_ENDIAN
> .gdb_bpt_instr = {0x78, 0x7e},
> diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
> index caa0dbe3dc61..21a6d5958955 100644
> --- a/arch/arm/kernel/kgdb.c
> +++ b/arch/arm/kernel/kgdb.c
> @@ -274,7 +274,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> * and we handle the normal undef case within the do_undefinstr
> * handler.
> */
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> #ifndef __ARMEB__
> .gdb_bpt_instr = {0xfe, 0xde, 0xff, 0xe7}
> #else /* ! __ARMEB__ */
> diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> index a20de58061a8..fe1d1f935b90 100644
> --- a/arch/arm64/kernel/kgdb.c
> +++ b/arch/arm64/kernel/kgdb.c
> @@ -357,7 +357,7 @@ void kgdb_arch_exit(void)
> unregister_die_notifier(&kgdb_notifier);
> }
>
> -struct kgdb_arch arch_kgdb_ops;
> +const struct kgdb_arch arch_kgdb_ops;
>
> int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> {
> diff --git a/arch/h8300/kernel/kgdb.c b/arch/h8300/kernel/kgdb.c
> index 1a1d30cb0609..602e478afbd5 100644
> --- a/arch/h8300/kernel/kgdb.c
> +++ b/arch/h8300/kernel/kgdb.c
> @@ -129,7 +129,7 @@ void kgdb_arch_exit(void)
> /* Nothing to do */
> }
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> /* Breakpoint instruction: trapa #2 */
> .gdb_bpt_instr = { 0x57, 0x20 },
> };
> diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
> index 16c24b22d0b2..f1924d483e78 100644
> --- a/arch/hexagon/kernel/kgdb.c
> +++ b/arch/hexagon/kernel/kgdb.c
> @@ -83,7 +83,7 @@ struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
> { "syscall_nr", GDB_SIZEOF_REG, offsetof(struct pt_regs, syscall_nr)},
> };
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> /* trap0(#0xDB) 0x0cdb0054 */
> .gdb_bpt_instr = {0x54, 0x00, 0xdb, 0x0c},
> };
> diff --git a/arch/microblaze/kernel/kgdb.c b/arch/microblaze/kernel/kgdb.c
> index 6366f69d118e..130cd0f064ce 100644
> --- a/arch/microblaze/kernel/kgdb.c
> +++ b/arch/microblaze/kernel/kgdb.c
> @@ -143,7 +143,7 @@ void kgdb_arch_exit(void)
> /*
> * Global data
> */
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> #ifdef __MICROBLAZEEL__
> .gdb_bpt_instr = {0x18, 0x00, 0x0c, 0xba}, /* brki r16, 0x18 */
> #else
> diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
> index 31eff1bec577..edfdc2ec2d16 100644
> --- a/arch/mips/kernel/kgdb.c
> +++ b/arch/mips/kernel/kgdb.c
> @@ -394,7 +394,7 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,
> return -1;
> }
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> #ifdef CONFIG_CPU_BIG_ENDIAN
> .gdb_bpt_instr = { spec_op << 2, 0x00, 0x00, break_op },
> #else
> diff --git a/arch/nios2/kernel/kgdb.c b/arch/nios2/kernel/kgdb.c
> index 117859122d1c..37b25f844a2d 100644
> --- a/arch/nios2/kernel/kgdb.c
> +++ b/arch/nios2/kernel/kgdb.c
> @@ -165,7 +165,7 @@ void kgdb_arch_exit(void)
> /* Nothing to do */
> }
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> /* Breakpoint instruction: trap 30 */
> .gdb_bpt_instr = { 0xba, 0x6f, 0x3b, 0x00 },
> };
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 59c578f865aa..bdb588b1d8fb 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -477,7 +477,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> /*
> * Global data
> */
> -struct kgdb_arch arch_kgdb_ops;
> +const struct kgdb_arch arch_kgdb_ops;
>
> static int kgdb_not_implemented(struct pt_regs *regs)
> {
> diff --git a/arch/sh/kernel/kgdb.c b/arch/sh/kernel/kgdb.c
> index 4f04c6638a4d..a24c48446e98 100644
> --- a/arch/sh/kernel/kgdb.c
> +++ b/arch/sh/kernel/kgdb.c
> @@ -382,7 +382,7 @@ void kgdb_arch_exit(void)
> unregister_die_notifier(&kgdb_notifier);
> }
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> /* Breakpoint instruction: trapa #0x3c */
> #ifdef CONFIG_CPU_LITTLE_ENDIAN
> .gdb_bpt_instr = { 0x3c, 0xc3 },
> diff --git a/arch/sparc/kernel/kgdb_32.c b/arch/sparc/kernel/kgdb_32.c
> index 639c8e54530a..7580775a14b9 100644
> --- a/arch/sparc/kernel/kgdb_32.c
> +++ b/arch/sparc/kernel/kgdb_32.c
> @@ -166,7 +166,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long ip)
> regs->npc = regs->pc + 4;
> }
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> /* Breakpoint instruction: ta 0x7d */
> .gdb_bpt_instr = { 0x91, 0xd0, 0x20, 0x7d },
> };
> diff --git a/arch/sparc/kernel/kgdb_64.c b/arch/sparc/kernel/kgdb_64.c
> index a68bbddbdba4..5d6c2d287e85 100644
> --- a/arch/sparc/kernel/kgdb_64.c
> +++ b/arch/sparc/kernel/kgdb_64.c
> @@ -195,7 +195,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long ip)
> regs->tnpc = regs->tpc + 4;
> }
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> /* Breakpoint instruction: ta 0x72 */
> .gdb_bpt_instr = { 0x91, 0xd0, 0x20, 0x72 },
> };
> diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
> index 8e36f249646e..e7effc02f13c 100644
> --- a/arch/x86/kernel/kgdb.c
> +++ b/arch/x86/kernel/kgdb.c
> @@ -804,7 +804,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> (char *)bpt->saved_instr, BREAK_INSTR_SIZE);
> }
>
> -struct kgdb_arch arch_kgdb_ops = {
> +const struct kgdb_arch arch_kgdb_ops = {
> /* Breakpoint instruction: */
> .gdb_bpt_instr = { 0xcc },
> .flags = KGDB_HW_BREAKPOINT,
> diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
> index e465bb15912d..3bf313311cca 100644
> --- a/include/linux/kgdb.h
> +++ b/include/linux/kgdb.h
> @@ -281,7 +281,7 @@ struct kgdb_io {
> int is_console;
> };
>
> -extern struct kgdb_arch arch_kgdb_ops;
> +extern const struct kgdb_arch arch_kgdb_ops;
>
> extern unsigned long kgdb_arch_pc(int exception, struct pt_regs *regs);
>
> --
> 2.13.3
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Moving ARM dts files
From: Alexandre Belloni @ 2018-12-06 14:05 UTC (permalink / raw)
To: Rob Herring
Cc: Andrew Lunn, Tony Lindgren, Linus Walleij, Liviu Dudau,
Masahiro Yamada, Thierry Reding, Florian Fainelli, Kevin Hilman,
Gregory CLEMENT, Michal Simek, Krzysztof Kozlowski,
ARM-SoC Maintainers, Joel Stanley, Uwe Kleine-König,
Andy Gross, devicetree, Jason Cooper, Simon Horman,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Jisheng Zhang, Maxime Coquelin, Shawn Guo, Andreas Färber,
Daniel Mack
In-Reply-To: <CAL_Jsq+PB3Pmg1RmNqj0whapbcqRBXDNWi4LpjPqqCKeLHbR=A@mail.gmail.com>
On 06/12/2018 07:58:24-0600, Rob Herring wrote:
> On Thu, Dec 6, 2018 at 7:39 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > Hello,
> >
> > On Wed, Dec 05, 2018 at 09:01:59AM -0600, Rob Herring wrote:
> > > i.MX23 is a Sigmatel chip STMP??
> >
> > I think the Freescale i.MX23 didn't exist at Sigmatel back then. AFAIK
> > this is a new design using IP from Sigmatel after the aquisition.
>
> It is not. I was in the i.MX group which Sigmatel was merged into at
> the time. Purely marketing rebranding.
>
Wouldn't it be easier to name the directory to the corresponding mach-*
entry?
So, imx23 and imx28 would go to mxs/, other imx in imx/. And this also
solves the Marvell mess with the Synaptics Socs going in berlin/ and the
other ones in mvebu/.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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