* Kexec on arm64
From: Arun Chandran @ 2014-07-22 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405551861.7262.26.camel@smoke>
On Thu, Jul 17, 2014 at 4:34 AM, Geoff Levand <geoff@infradead.org> wrote:
> Hi Feng,
>
> On Wed, 2014-07-16 at 10:57 -0700, Feng Kan wrote:
>> Just following up on the conversation. The cpu return address of 0 should work
>> in your case. Since thats the _start of the bootloader, it will run
>> some core init
>> code and then put the core back in wfe.
>
> OK, I fixed up my code so that zero is valid cpu return address. Arun,
> could you try my latest I pushed out today?
>
Hi Geoff,
Sorry for the late reply I was away.
Yes I tried the new code.
My dts file has the below change.
################
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index e0bf91d..b64e549 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -24,64 +24,64 @@
compatible = "apm,potenza", "arm,armv8";
reg = <0x0 0x000>;
enable-method = "spin-table";
- cpu-release-addr = <0x1 0x0000fff8>;
- cpu-return-addr = <0x0 0x0> /* Updated by bootloader */
+ cpu-release-addr = <0x40 0x0000fff8>;
+ cpu-return-addr = <0x0 0x0>; /* Updated by bootloader */
};
#################
All other cpu nodes have similar change.
1) Loading ( I don't change commandline and dtb; assuming kexec will
reuse whatever
the booted kernel has as commandline and dtb)
# kexec -l vmlinux.strip
kexec version: 14.07.17.12.17-gb6cccb4
Modified cmdline: root=/dev/nfs
Unable to find /proc/device-tree//chosen/linux,stdout-path, printing
from purgatory is diabled
Modified cmdline: root=/dev/nfs
Unable to find /proc/device-tree//chosen/linux,stdout-path, printing
from purgatory is diabled
machine_kexec_prepare:508:
kexec image info:
type: 0
start: 4000080004
head: 0
nr_segments: 2
segment[0]: 0000004000080000 - 000000400088c000, 80c000h bytes, 2060 pages
kexec_is_dtb:115: magic: 4d5a0091 : 91005a4d : no
segment[1]: 00000040008a0000 - 00000040008a3000, 3000h bytes, 3 pages
kexec_is_dtb:115: magic: d00dfeed : edfe0dd0 : yes
kexec_boot_info_init:384: cpu_count: 8
kexec_cpu_info_init:352: cpu-0: hwid-0, 'spin-table', cpu-release-addr
400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-1: hwid-1, 'spin-table', cpu-release-addr
400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-2: hwid-100, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-3: hwid-101, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-4: hwid-200, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-5: hwid-201, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-6: hwid-300, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-7: hwid-301, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_is_dtb:115: magic: 4d5a0091 : 91005a4d : no
kexec_is_dtb:115: magic: d00dfeed : edfe0dd0 : yes
kexec_boot_info_init:384: cpu_count: 8
kexec_cpu_info_init:352: cpu-0: hwid-0, 'spin-table', cpu-release-addr
400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-1: hwid-1, 'spin-table', cpu-release-addr
400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-2: hwid-100, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-3: hwid-101, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-4: hwid-200, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-5: hwid-201, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-6: hwid-300, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_cpu_info_init:352: cpu-7: hwid-301, 'spin-table',
cpu-release-addr 400000fff8, cpu-return-addr 0
kexec_cpu_check:440: hwid-0 OK
kexec_cpu_check:440: hwid-1 OK
kexec_cpu_check:440: hwid-100 OK
kexec_cpu_check:440: hwid-101 OK
kexec_cpu_check:440: hwid-200 OK
kexec_cpu_check:440: hwid-201 OK
kexec_cpu_check:440: hwid-300 OK
kexec_cpu_check:440: hwid-301 OK
2) Rebooting
#########################
# kexec -e
kexec version: 1kvm: exiting hardware virtualization
4.07.17.12.17-gbStarting new kernel
6cccb4
Ump_spin_tanblaeb_lcpeu_d ite:127: oi dh:a n7d,l holding count: 0e
kernel NULL pointer dereference at virtual address 00000291
smp_spin_Itnaibtlei_cpaul_diie:12z7:i nigd :c 3g,r oholding couunpt :s 0u
bsys cpu
smpL_isnpuixn _table_cpu_diev:e1r2s7i:o ni d: 6, hol3d.i1n6g. 0c-orucnt: 0
4+ (arun at arun-OptiPlex-9010) (gcc version 4.9.1 20140505 (prerelease)
(crosstool-NG linaro-1.13.1-4.9-2014.05 - Linaro GCC 4.9-2014.05) )
#25 SMP smp_sPpin_tablReE_EcMpPuT_ dTie:127: iude: J5u, hlo ld2ing
coun2:
37:03 IST 2014
smp_Cspin_tPabUl:e _AcApruc_die:127: id: h46,4 hPorldiong count:c e0s
or [500f0000] revision 0
smp_speifni_:t aGbeltet_cpu_die:i1n2g7 : ipd:a 2, holdinrga mceount:t e0
rs from FDT:
smep_fsip:i nC_atable_cpu_dien:'1t27: i df: 1i, holdinngd cSoyusntt:e 0
m Table in device tree!
macchimne_kexaec:: 572C: smp_pMrAo:c efsasiorl_ied = 0
d to reserve 16 MiB
dachine_kexecO:n5 7n4o:
e 0 totalpages: 4194304
a k e xec image inNfoor:m
l zone: 57344 pages used for memmap
type: 0
z sta r tN:o r m4a0000800l04
one: 4194304 pages, LIFO batch:31
head: P E R 43Cea9bPf002
U: Embedded 11 pages/cpu @ffffffc3fff7d000 s13120 r8192 d23744 u45056
nrp_cspeug-maelnltosc: 2
: s13120 r8192 d23744 u45056 alloc=11*4096
p c p usegment-[a0l]l:o c0:0 0[0000400]00 800 000[ -0 ]0000004000
881c 0[000], 280c000h bytes, [200]6 0 3pages
[0] 4 [0] 5 [0] 6 [0] 7
eexBeuc_is_dtb:1i1l5:t m1a gizc: 0 : 0 : noon
lists in Zone order, mobility grouping on. Total pages: 4136960
/ K e r segment[1]: n0e0l0 00c0o400m08a0000 m-a n0d00
00040l008ai30n00e,: 3r000ho obty=tes, 3/ dpeagesv
nfs rw nfsroot=10.162.103.228:/nfs_root/dora_june_6/apm-image-minimal-mustangbe
ip=10.162.103.21:10.162.103.228:10.162.103.1:255.255.255.0:mustangk:eextehc_0is:_odtb:1f15f:
pmaangic:i 0c =: 0 : 1no
console=ttyS0,115200 earlyprintk=uart8250-32bit,0x1c020000 debug
maxcpus=8 swiotlb=65536 log_buf_len=1M
8aclhinoeg_kex_ec:582: cobnturfo_ll_ecode_page: nf:f f1ff0fbc4edb67ee8
576
6achinee_akrelxyec: 58l4: reobogo tb_ucfo dfe_buffer_physr:e e :0
000010435eaffb00007
(92%)
macPhine_IkDexec:58 6h:a srehb otot_acode_bufferb:l e e n t
rfifffffce3se:a f4f0b000
96 (order: 3, 32768 bytes)
macDhine_kexeecn:t5r88: ryel occate_neaw_ckheer nelh:a s fffffhf
c0t0a0093b18
ble entries: 2097152 (order: 12, 16777216 bytes)
machineI_kneoxedc:5e90-: relocate_cnaecwh_ek ehransel_size: b8hh( 1t84)a bytes
ble entries: 1048576 (order: 11, 8388608 bytes)
machinMe_keemxoercy::5 913: kexec6_5d0t8b_6addr2:4 K
0/0100004600708a0000
77216K available (4360K kernel code, 299K rwdata, 1528K rodata, 6556K
init, 202K bss, 268592K reserved)
oacVhinei_kretxueacl: 595: kexec_kkeirmnaegle _mhead: e m o r0y0
00l0043eaa9bf002y
ut:
vmalloc : 0xffffff8000000000 - 0xffffffbbffff0000 (245759 MB)
vmemmap : 0xffffffbce0000000 - 0xffffffbcee000000 ( 224 MB)
0 machine_ kmeoxdecu:l597:e kexecs_ k:i m0age_xsftarft: f f
f0f0b0f0f0c04000080004
00000 - 0xffffffc000000000 ( 64 MB)
memory : 0xffffffc000000000 - 0xffffffc400000000 ( 16384 MB)
.init : 0xffffffc000642000 -machine_ke x0excf:f5f99:f
kexec_efntfrcy0_0d0ump:
ca9340 ( 6557 kB)
.text : 0xffffffc000080000 - 0xffffffc0006411c4 ( 5893 kB)
f .data : 0xffffffc000caa000 - 0xffffffc000cf4f28 (I
43ea9bf002 = 343ea9b0f000 (f0fffffc 3ekaB9)b
000)
d D 40S0LU00B8:0 0H0W1 = a4000080000l i(gfnf=f6f4ffc,00008000 0O)r
######################
This doesn't seems to be working. Random behaviors are observed. Some
times it rebooted to u-boot
prompt. Sometimes kernel soft resets itself in an endless loop
(bootlog is repeating over and over again)
To debug what is happening I put a while(1) just before jumping into
kexec reboot code.
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 31cba91..8843623 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -85,6 +85,7 @@ void soft_restart(unsigned long addr)
smp_secondary_shutdown();
+ while(1);
/* Switch to the identity mapping */
phys_reset = (phys_reset_t)virt_to_phys(cpu_reset);
phys_reset(addr);
I break into target with BDI3000 now; and see the below output
TARGET#0>state
Core#0: halted 0xffffffc000085240 External Debug Request
Core#1: halted 0x0000004000080394 External Debug Request
Core#2: halted 0x0000004000080394 External Debug Request
Core#3: halted 0x0000004000080394 External Debug Request
Core#4: halted 0xffffffc0000802f8 External Debug Request
Core#5: halted 0x0000004000080394 External Debug Request
Core#6: halted 0xffffffc0000802f8 External Debug Request
Core#7: halted 0x0000004000080394 External Debug Request
I think some of the secondary CPUs are not behaving as expected;
As of now I don't have any clues for this.
--Arun
^ permalink raw reply related
* [PATCH 2/2] ARM: multi_v7_defconfig: Enable MiPHY365x - ST's Generic (SATA & PCIe) PHY
From: Lee Jones @ 2014-07-22 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406021985-8763-1-git-send-email-lee.jones@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 1a695a5..055949c 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -369,6 +369,7 @@ CONFIG_PWM=y
CONFIG_PWM_TEGRA=y
CONFIG_PWM_VT8500=y
CONFIG_OMAP_USB2=y
+CONFIG_PHY_MIPHY365X=y
CONFIG_PHY_SUN4I_USB=y
CONFIG_EXT4_FS=y
CONFIG_VFAT_FS=y
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/2] ARM: multi_v7_defconfig: Enable ST's (S)ATA driver
From: Lee Jones @ 2014-07-22 9:39 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 5348364..1a695a5 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -127,6 +127,7 @@ CONFIG_BLK_DEV_SR=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_ATA=y
CONFIG_SATA_AHCI_PLATFORM=y
+CONFIG_AHCI_ST=y
CONFIG_AHCI_SUNXI=y
CONFIG_SATA_HIGHBANK=y
CONFIG_SATA_MV=y
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
From: Peter Griffin @ 2014-07-22 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000d01cf99e6$602096b0$2061c410$%han@samsung.com>
Hi Jingoo,
Sorry for the delay in replying. Thanks for reviewing,
see my comments inline below: -
<snip>
> > +#include <linux/module.h>
> > +#include <linux/kernel.h>
> > +#include <linux/slab.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/ioport.h>
> > +#include <linux/io.h>
> > +#include <linux/of.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/delay.h>
> > +#include <linux/regmap.h>
> > +#include <linux/reset.h>
>
> Would you re-order these headers alphabetically?
> It enhances the readability.
Ok fixed in V3
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "reg-glue");
> > + if (!res)
> > + return -ENXIO;
> > +
> > + dwc3_data->glue_base = devm_request_and_ioremap(dev, res);
>
> Please don't use devm_request_and_ioremap() any more. It was deprecated
> and will be removed from 3.17-rc1.
>
> Please, use devm_ioremap_resource() instead.
Ok changed over to use devm_ioremap_resource in V3.
>
> + dwc3_data->glue_base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(dwc3_data->glue_base))
> + return PTR_ERR(dwc3_data->glue_base);
>
> > + if (!dwc3_data->glue_base)
> > + return -EADDRNOTAVAIL;
> > +
<snip>
> > +
> > +static const struct dev_pm_ops st_dwc3_dev_pm_ops = {
> > + SET_SYSTEM_SLEEP_PM_OPS(st_dwc3_suspend, st_dwc3_resume)
> > +};
> > +
> > +static struct of_device_id st_dwc3_match[] = {
>
> Please add 'const' as below. This is because all OF functions
> handle of_device_id as const.
>
> static const struct of_device_id st_dwc3_match[] = {
Ok, fixed in V3
>
> > + { .compatible = "st,stih407-dwc3" },
> > + { /* sentinel */ },
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, st_dwc3_match);
> > +
> > +static struct platform_driver st_dwc3_driver = {
> > + .probe = st_dwc3_probe,
> > + .remove = st_dwc3_remove,
> > + .driver = {
> > + .name = "usb-st-dwc3",
> > + .owner = THIS_MODULE,
> > + .of_match_table = of_match_ptr(st_dwc3_match),
>
> You already use OF dependency as below. So, of_match_ptr() is
> NOT necessary.
>
> +config USB_DWC3_ST
> + tristate "STMicroelectronics Platforms"
> + depends on ARCH_STI && OF
>
> Please remove of_match_ptr() as below.
>
> + .of_match_table = st_dwc3_match,
Ok fixed in V3
regards,
Peter.
^ permalink raw reply
* [PATCH v2 1/1] ARM: DT: STi: STiH416: Add DT node for ST's SATA device
From: Maxime Coquelin @ 2014-07-22 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722092834.GA8406@lee--X1>
On 07/22/2014 11:28 AM, Lee Jones wrote:
> ARM: DT: STi: STiH416: Add DT node for ST's SATA device
>
> Cc: devicetree at vger.kernel.org
> Acked-by: Alexandre Torgue <alexandre.torgue@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
Thanks for the fixup.
Patch added to my queue for v3.17
Regards,
Maxime
^ permalink raw reply
* [PATCH v2 1/1] ARM: DT: STi: STiH416: Add DT node for ST's SATA device
From: Lee Jones @ 2014-07-22 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405931573-12407-1-git-send-email-lee.jones@linaro.org>
ARM: DT: STi: STiH416: Add DT node for ST's SATA device
Cc: devicetree at vger.kernel.org
Acked-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
index c3c2ac6..eb2f246 100644
--- a/arch/arm/boot/dts/stih416-b2020.dts
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -23,5 +23,9 @@
st,pcie-tx-pol-inv;
};
};
+
+ sata0: sata at fe380000{
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/stih416-b2020e.dts b/arch/arm/boot/dts/stih416-b2020e.dts
index 80aff0f..99a699e 100644
--- a/arch/arm/boot/dts/stih416-b2020e.dts
+++ b/arch/arm/boot/dts/stih416-b2020e.dts
@@ -41,5 +41,9 @@
st,pcie-tx-pol-inv;
};
};
+
+ sata0: sata at fe380000{
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 2b98a0a..060dd53 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -258,5 +258,21 @@
reg-names = "sata", "pcie", "syscfg";
};
};
+
+ sata0: sata at fe380000 {
+ compatible = "st,sti-ahci";
+ reg = <0xfe380000 0x1000>;
+ interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>;
+ interrupt-names = "hostc";
+ phys = <&phy_port0 MIPHY_TYPE_SATA>;
+ phy-names = "sata-phy";
+ resets = <&powerdown STIH416_SATA0_POWERDOWN>,
+ <&softreset STIH416_SATA0_SOFTRESET>;
+ reset-names = "pwr-dwn", "sw-rst";
+ clock-names = "ahci_clk";
+ clocks = <&clk_s_a0_ls CLK_ICN_REG>;
+
+ status = "disabled";
+ };
};
};
^ permalink raw reply related
* [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
From: Peter Griffin @ 2014-07-22 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140707124627.GG6407@lee--X1>
Hi Lee,
Thanks for reviewing, see my comments inline below: -
On Mon, 07 Jul 2014, Lee Jones wrote:
> On Sat, 05 Jul 2014, Peter Griffin wrote:
>
> > This patch adds the ST glue logic to manage the DWC3 HC
> > on STiH407 SoC family. It manages the powerdown signal,
> > and configures the internal glue logic and syscfg registers.
> >
> > Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> > drivers/usb/dwc3/Kconfig | 9 ++
> > drivers/usb/dwc3/Makefile | 1 +
> > drivers/usb/dwc3/dwc3-st.c | 325 +++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 335 insertions(+)
> > create mode 100644 drivers/usb/dwc3/dwc3-st.c
> >
> > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> > index 8eb996e..6c85c43 100644
> > --- a/drivers/usb/dwc3/Kconfig
> > +++ b/drivers/usb/dwc3/Kconfig
> > @@ -79,6 +79,15 @@ config USB_DWC3_KEYSTONE
> > Support of USB2/3 functionality in TI Keystone2 platforms.
> > Say 'Y' or 'M' here if you have one such device
> >
> > +config USB_DWC3_ST
> > + tristate "STMicroelectronics Platforms"
> > + depends on ARCH_STI && OF
> > + default USB_DWC3_HOST
> > + help
> > + STMicroelectronics SoCs with one DesignWare Core USB3 IP
> > + inside (i.e. STiH407).
> > + Say 'Y' or 'M' if you have one such device.
> > +
> > comment "Debugging features"
> >
> > config USB_DWC3_DEBUG
> > diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> > index 10ac3e7..11c9f54 100644
> > --- a/drivers/usb/dwc3/Makefile
> > +++ b/drivers/usb/dwc3/Makefile
> > @@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
> > obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
> > obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
> > obj-$(CONFIG_USB_DWC3_KEYSTONE) += dwc3-keystone.o
> > +obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o
> > diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
> > new file mode 100644
> > index 0000000..2cae9d3
> > --- /dev/null
> > +++ b/drivers/usb/dwc3/dwc3-st.c
> > @@ -0,0 +1,325 @@
> > +/**
> > + * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics platforms
> > + *
> > + * This is a small platform driver for the dwc3 to provide the glue logic
> > + * to configure the controller. Tested on STi platforms.
>
> Not sure about the use of the term 'platform driver' here and in the
> title. We don't normally differentiate. I can find examples to the
> contrary, but not many.
Ok, removed 'platform' in V3
>
> > + * Copyright (C) 2014 Stmicroelectronics
> > + *
> > + * Author: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> > + * Contributors: Aymen Bouattay <aymen.bouattay@st.com>
> > + * Peter Griffin <peter.griffin@linaro.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * Inspired by dwc3-omap.c and dwc3-exynos.c.
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/kernel.h>
> > +#include <linux/slab.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/ioport.h>
> > +#include <linux/io.h>
> > +#include <linux/of.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/delay.h>
> > +#include <linux/regmap.h>
> > +#include <linux/reset.h>
> > +
> > +#include "core.h"
> > +#include "io.h"
> > +
> > +/* Reg glue registers */
> > +#define USB2_CLKRST_CTRL 0x00
> > +#define aux_clk_en(n) ((n)<<0)
> > +#define sw_pipew_reset_n(n) ((n)<<4)
> > +#define ext_cfg_reset_n(n) ((n)<<8)
> > +#define xhci_revision(n) ((n)<<12)
>
> These all need reformatting, see CodingStyle - 3.1: Spaces
Ok I have added a space either side of the shift operator and aligned
using tabs.
>
> #define xhci_revision(n) ((n) << 12)
>
> Lining them up with TABs would make them easier to read.
Ok fixed in v3
>
> Also, I don't think there is a requirement to encapsulate the 'n'.
Ok removed brackets around the 'n'
>
> > +#define USB2_VBUS_MNGMNT_SEL1 0x2C
> > +/*
> > + * 2'b00 : Override value from Reg 0x30 is selected
> > + * 2'b01 : utmiotg_vbusvalid from usb3_top top is selected
> > + * 2'b10 : pipew_powerpresent from PIPEW instance is selected
> > + * 2'b11 : value is 1'b0
> > + */
>
> What is this documenting? Isn't documentation meant to make things
> clearer? Now I'm just really confused - by the documentation.
It is documenting the bitfields in VBUS_MNGMNT_SEL1 register. I've
hopefully made it a bit clearer by adding the following comment and
slightly adjusting the descriptions a little.
/*
* For all fields in USB2_VBUS_MNGMNT_SEL1
* 2?b00 : Override value from Reg 0x30 is selected
* 2?b01 : utmiotg_<signal_name> from usb3_top is selected
* 2?b10 : pipew_<signal_name> from PIPEW instance is selected
* 2?b11 : value is 1'b0
*/
Apart from that it's a standard way to describe bitfields. You can find
some examples in cx231xx-pcb-cfg.h, bnx2x_link.h and cx231xx-avcore.c
>
> > +#define SEL_OVERRIDE_VBUSVALID(n) ((n)<<0)
> > +#define SEL_OVERRIDE_POWERPRESENT(n) ((n)<<4)
> > +#define SEL_OVERRIDE_BVALID(n) ((n)<<8)
> > +
> > +#define USB2_VBUS_MNGMNT_VAL1 0x30
> > +#define OVERRIDE_VBUSVALID_VAL (1 << 0)
> > +#define OVERRIDE_POWERPRESENT_VAL (1 << 4)
> > +#define OVERRIDE_BVALID_VAL (1 << 8)
>
> Use BIT() for all of these bit setting macros.
Ok fixed in V3
>
> > +/* Static DRD configuration */
> > +#define USB_HOST_DEFAULT_MASK 0xffe
> > +#define USB_SET_PORT_DEVICE 0x1
> > +
> > +struct st_dwc3 {
> > + struct platform_device *dwc3; /* platform device pointer */
> > + struct device *dev; /* device pointer */
> > + void __iomem *glue_base; /* ioaddr for programming the glue */
> > + struct regmap *regmap; /* regmap for getting syscfg */
> > + int syscfg_reg_off; /* usb syscfg control offset */
> > + bool drd_device_conf; /* DRD static host/device conf */
> > + struct reset_control *rstc_pwrdn;/* Rst control for powerdown*/
> > +};
>
> This is a mess. Use kerneldoc formatting instead.
Ok, converted to kerneldoc in V3
>
> > +static inline u32 st_dwc3_readl(void __iomem *base, u32 offset)
> > +{
> > + return readl_relaxed(base + offset);
> > +}
> > +
> > +static inline void st_dwc3_writel(void __iomem *base, u32 offset, u32 value)
> > +{
> > + writel_relaxed(value, base + offset);
> > +}
>
> Why are these being abstracted?
>
> Just use {read,write}l_relaxed() directly.
Ok, unabstracted in v3
>
> > +/**
> > + * st_dwc3_drd_init: program the port
> > + * @dwc3_data: driver private structure
> > + * Description: this function is to program the port as either host or device
> > + * according to the static configuration passed from devicetree.
> > + * OTG and dual role are not yet supported!
> > + */
> > +static int st_dwc3_drd_init(struct st_dwc3 *dwc3_data)
> > +{
> > + u32 val;
> > +
> > + regmap_read(dwc3_data->regmap, dwc3_data->syscfg_reg_off, &val);
>
> Shouldn't you be checking the return value of regmap_read()?
Ok, fixed in V3
>
> > + if (dwc3_data->drd_device_conf)
> > + val |= USB_SET_PORT_DEVICE;
> > + else
> > + val &= USB_HOST_DEFAULT_MASK;
> > +
> > + return regmap_write(dwc3_data->regmap, dwc3_data->syscfg_reg_off, val);
> > +}
> > +
> > +/**
> > + * st_dwc3_init: init the controller via glue logic
> > + * @dwc3_data: driver private structure
> > + */
> > +static void st_dwc3_init(struct st_dwc3 *dwc3_data)
> > +{
> > + u32 reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > +
> > + reg |= aux_clk_en(1) | ext_cfg_reset_n(1) | xhci_revision(1);
> > + reg &= ~sw_pipew_reset_n(1);
>
> 1? Better to add defines for these magic numbers. What is 1 anyway?
They are just bit setting macros, I've converted them over to use BIT macro now,
so it no longer takes a parameter.
> Port one? If so, shouldn't this function be called
> st_dwc2_init_port_one(), or similar?
No.
>
> > + st_dwc3_writel(dwc3_data->glue_base, USB2_CLKRST_CTRL, reg);
> > +
> > + reg = st_dwc3_readl(dwc3_data->glue_base, USB2_VBUS_MNGMNT_SEL1);
> > + reg |= SEL_OVERRIDE_VBUSVALID(1) | SEL_OVERRIDE_POWERPRESENT(1) |
> > + SEL_OVERRIDE_BVALID(1);
> > + st_dwc3_writel(dwc3_data->glue_base, USB2_VBUS_MNGMNT_SEL1, reg);
> > + udelay(100);
>
> Why 100?
I've asked ST how this value was derirved and why. It came from validation.
The docs don't mention that it is necessary, and removing it
seems to have no ill effects. So I've removed this udelay in v3.
>
> > + reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > + reg |= sw_pipew_reset_n(1);
> > + st_dwc3_writel(dwc3_data->glue_base, USB2_CLKRST_CTRL, reg);
> > +}
> > +
> > +static void st_dwc3_dt_get_pdata(struct platform_device *pdev,
> > + struct st_dwc3 *dwc3_data)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > +
> > + dwc3_data->drd_device_conf =
> > + of_property_read_bool(np, "st,dwc3-drd-device");
>
> This requires a DT Ack.
Ok. Do the DT folks have any comment on this?
>
> > +}
> > +
> > +/**
> > + * st_dwc3_probe: main probe function
> > + * @pdev: platform_device
> > + * Description: this is the probe function that gets all the resources to manage
> > + * the glue-logic, setup the controller and take out of powerdown.
> > + */
>
> I've never seen .probe() documented before? I think you can safely
> remove this kerneldoc header.
Ok I have removed the documentation in V3
>
> > +static int st_dwc3_probe(struct platform_device *pdev)
> > +{
> > + struct platform_device *dwc3;
> > + struct st_dwc3 *dwc3_data;
> > + struct resource *res;
> > + struct device *dev = &pdev->dev;
> > + struct device_node *node = dev->of_node;
> > + struct regmap *regmap;
> > + int ret = 0;
>
> No need to initialise.
Ok fixed in v3
>
> > + if (!node) {
> > + dev_err(dev, "device node not found\n");
> > + return -EINVAL;
> > + }
>
> Remove this and make the driver depend on OF.
I have removed the check, as driver already depends on OF.
>
> > + dwc3_data = devm_kzalloc(dev, sizeof(*dwc3_data), GFP_KERNEL);
> > + if (!dwc3_data)
> > + return -ENOMEM;
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "reg-glue");
> > + if (!res)
> > + return -ENXIO;
>
> No need to check res here, devm_request_and_ioremap() does it for you.
Ok removed error check, and added comment explaining why there is no checking
>
> > + dwc3_data->glue_base = devm_request_and_ioremap(dev, res);
> > + if (!dwc3_data->glue_base)
> > + return -EADDRNOTAVAIL;
>
> What? Better to return the value from devm_request_and_ioremap() than
> make up your own.
Actually it isn't made up, devm_request_and_ioremap returns either the remapped
pointer or NULL on error. Returning -EADDRNOTAVAIL is
taken from the devm_request_and_ioremap kerneldoc usage example.
>
> > + regmap = syscon_regmap_lookup_by_phandle(node, "st,syscfg");
> > + if (IS_ERR(regmap))
> > + return PTR_ERR(regmap);
> > +
> > + dwc3 = platform_device_alloc("st-dwc3", PLATFORM_DEVID_AUTO);
> > + if (!dwc3) {
> > + dev_err(&pdev->dev, "couldn't allocate dwc3 device\n");
> > + return -ENOMEM;
> > + }
>
> I'm confused. What is this doing? Isn't this the DWC3 driver, which
> already had a platform device structure associated to it? Perhaps a
> small ASCII diagram describing the layers might be useful.
Your right, this was wrong. It was some legacy code which is unnecessary and
I've removed this in v3.
>
> > + dma_set_coherent_mask(&dwc3->dev, dev->coherent_dma_mask);
> > +
> > + dwc3->dev.parent = &pdev->dev;
> > + dwc3->dev.dma_mask = pdev->dev.dma_mask;
> > + dwc3->dev.dma_parms = pdev->dev.dma_parms;
> > +
> > + dwc3_data->dwc3 = dwc3;
> > + dwc3_data->dev = &pdev->dev;
>
> We're saving this twice, it's already available in dwc3, which we just
> saved.
Fixed in V3
>
> > + dwc3_data->regmap = regmap;
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "syscfg-reg");
> > + if (!res) {
> > + ret = -ENXIO;
> > + goto undo_platform_dev_alloc;
> > + }
> > +
> > + dwc3_data->syscfg_reg_off = res->start;
> > +
> > + dev_info(&pdev->dev, "glue-logic addr 0x%p, syscfg-reg offset 0x%x\n",
> > + dwc3_data->glue_base, dwc3_data->syscfg_reg_off);
>
> I think this should be removed. At the very least downgraded to
> dev_dbg().
Ok downgraded to dev_dbg in V3
>
> > + dwc3_data->rstc_pwrdn = devm_reset_control_get(dwc3_data->dev, NULL);
> > + if (IS_ERR(dwc3_data->rstc_pwrdn)) {
> > + dev_err(&pdev->dev, "could not get reset controller\n");
> > + ret = PTR_ERR(dwc3_data->rstc_pwrdn);
> > + goto undo_platform_dev_alloc;
> > + }
> > +
> > + /* Manage PowerDown */
> > + reset_control_deassert(dwc3_data->rstc_pwrdn);
> > +
> > + st_dwc3_dt_get_pdata(pdev, dwc3_data);
>
> As there is only one line in this function and this driver is DT only,
> I would bring that line directly into .probe().
Ok, fixed in v3
>
> > + /* Allocate and initialize the core */
> > + ret = of_platform_populate(node, NULL, NULL, dev);
> > + if (ret) {
> > + dev_err(dev, "failed to add dwc3 core\n");
> > + goto undo_powerdown;
> > + }
> > +
> > + /*
> > + * Configure the USB port as device or host according to the static
> > + * configuration passed from the platform.
> > + * DRD is the only mode currently supported so this will be enhanced
> > + * later as soon as OTG will be available.
> > + */
> > + ret = st_dwc3_drd_init(dwc3_data);
> > + if (ret) {
> > + dev_err(dev, "st_dwc3_drd_init failed\n");
>
> I wouldn't have names of functions in the kernel log.
>
> Swap out for something like "initialisation failed\n"
Ok, changed to "drd initialisation failed" in v3
>
> > + goto undo_powerdown;
> > + }
> > +
> > + dev_info(&pdev->dev, "configured as %s DRD\n",
> > + dwc3_data->drd_device_conf ? "device" : "host");
> > +
> > + /* ST glue logic init */
> > + st_dwc3_init(dwc3_data);
>
> Can this fail?
Intresting question, basically no it can't except if the IP is not clocked or held in
reset in which case it would hang the chip and never return.
>
> > + ret = platform_device_add_resources(dwc3_data->dwc3, pdev->resource,
> > + pdev->num_resources);
> > + if (ret) {
> > + dev_err(&pdev->dev, "couldn't add resources to dwc3 device\n");
> > + goto undo_powerdown;
> > + }
> > +
> > + ret = platform_device_add(dwc3_data->dwc3);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to register dwc3 device\n");
> > + goto undo_powerdown;
> > + }
> > +
> > + platform_set_drvdata(pdev, dwc3_data);
> > +
> > + return 0;
> > +
> > +undo_powerdown:
> > + reset_control_assert(dwc3_data->rstc_pwrdn);
> > +undo_platform_dev_alloc:
> > + platform_device_put(pdev);
> > +
> > + return ret;
> > +
>
> Remove the '\n' here.
Ok removed in V3
>
> > +}
> > +
> > +static int st_dwc3_remove(struct platform_device *pdev)
> > +{
> > + struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
> > +
> > + platform_device_unregister(dwc3_data->dwc3);
> > +
> > + return 0;
> > +}
> > +
> > +#ifdef CONFIG_PM_SLEEP
> > +static int st_dwc3_suspend(struct device *dev)
> > +{
> > + struct st_dwc3 *dwc3_data = dev_get_drvdata(dev);
> > +
> > + reset_control_assert(dwc3_data->rstc_pwrdn);
> > +
> > + pinctrl_pm_select_sleep_state(dev);
> > +
> > + return 0;
> > +}
> > +
> > +static int st_dwc3_resume(struct device *dev)
> > +{
> > + struct st_dwc3 *dwc3_data = dev_get_drvdata(dev);
> > +
> > + pinctrl_pm_select_default_state(dev);
> > +
> > + reset_control_deassert(dwc3_data->rstc_pwrdn);
> > +
> > + return 0;
> > +}
> > +
>
> Remove the '\n' here.
Ok removed in V3
>
> > +#endif /* CONFIG_PM_SLEEP */
> > +
> > +static const struct dev_pm_ops st_dwc3_dev_pm_ops = {
> > + SET_SYSTEM_SLEEP_PM_OPS(st_dwc3_suspend, st_dwc3_resume)
> > +};
>
> Use SIMPLE_DEV_PM_OPS().
Ok fixed in V3
>
> > +static struct of_device_id st_dwc3_match[] = {
> > + { .compatible = "st,stih407-dwc3" },
> > + { /* sentinel */ },
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, st_dwc3_match);
> > +
> > +static struct platform_driver st_dwc3_driver = {
> > + .probe = st_dwc3_probe,
> > + .remove = st_dwc3_remove,
> > + .driver = {
> > + .name = "usb-st-dwc3",
> > + .owner = THIS_MODULE,
>
> This is done for you elese where, you can remove.
Ok removed in V3
>
> > + .of_match_table = of_match_ptr(st_dwc3_match),
> > + .pm = &st_dwc3_dev_pm_ops,
> > + },
> > +};
> > +
> > +module_platform_driver(st_dwc3_driver);
> > +
> > +MODULE_AUTHOR("Giuseppe Cavallaro <peppe.cavallaro@st.com>");
> > +MODULE_DESCRIPTION("DesignWare USB3 STi Glue Layer");
> > +MODULE_LICENSE("GPL v2");
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v5 3/3] arm64: Add seccomp support
From: AKASHI Takahiro @ 2014-07-22 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406020499-5537-1-git-send-email-takahiro.akashi@linaro.org>
secure_computing() should always be called first in syscall_trace_enter().
If secure_computing() returns -1, we should stop further handling. Then
that system call may eventually fail with a specified return value (errno),
be trapped or the process itself be killed depending on loaded rules.
In these cases, syscall_trace_enter() also returns -1, that results in
skiping a normal syscall handling as well as syscall_trace_exit().
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
arch/arm64/Kconfig | 14 ++++++++++++++
arch/arm64/include/asm/seccomp.h | 25 +++++++++++++++++++++++++
arch/arm64/include/asm/unistd.h | 3 +++
arch/arm64/kernel/ptrace.c | 5 +++++
4 files changed, 47 insertions(+)
create mode 100644 arch/arm64/include/asm/seccomp.h
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3a18571..eeac003 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -32,6 +32,7 @@ config ARM64
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KGDB
+ select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
select HAVE_C_RECORDMCOUNT
select HAVE_DEBUG_BUGVERBOSE
@@ -259,6 +260,19 @@ config ARCH_HAS_CACHE_LINE_SIZE
source "mm/Kconfig"
+config SECCOMP
+ bool "Enable seccomp to safely compute untrusted bytecode"
+ ---help---
+ This kernel feature is useful for number crunching applications
+ that may need to compute untrusted bytecode during their
+ execution. By using pipes or other transports made available to
+ the process as file descriptors supporting the read/write
+ syscalls, it's possible to isolate those applications in
+ their own address space using seccomp. Once seccomp is
+ enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
+ and the task is only allowed to execute a few safe syscalls
+ defined by each seccomp mode.
+
config XEN_DOM0
def_bool y
depends on XEN
diff --git a/arch/arm64/include/asm/seccomp.h b/arch/arm64/include/asm/seccomp.h
new file mode 100644
index 0000000..c76fac9
--- /dev/null
+++ b/arch/arm64/include/asm/seccomp.h
@@ -0,0 +1,25 @@
+/*
+ * arch/arm64/include/asm/seccomp.h
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef _ASM_SECCOMP_H
+#define _ASM_SECCOMP_H
+
+#include <asm/unistd.h>
+
+#ifdef CONFIG_COMPAT
+#define __NR_seccomp_read_32 __NR_compat_read
+#define __NR_seccomp_write_32 __NR_compat_write
+#define __NR_seccomp_exit_32 __NR_compat_exit
+#define __NR_seccomp_sigreturn_32 __NR_compat_rt_sigreturn
+#endif /* CONFIG_COMPAT */
+
+#include <asm-generic/seccomp.h>
+
+#endif /* _ASM_SECCOMP_H */
diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index c980ab7..729c155 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -31,6 +31,9 @@
* Compat syscall numbers used by the AArch64 kernel.
*/
#define __NR_compat_restart_syscall 0
+#define __NR_compat_exit 1
+#define __NR_compat_read 3
+#define __NR_compat_write 4
#define __NR_compat_sigreturn 119
#define __NR_compat_rt_sigreturn 173
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 100d7d1..e477f6f 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -28,6 +28,7 @@
#include <linux/smp.h>
#include <linux/ptrace.h>
#include <linux/user.h>
+#include <linux/seccomp.h>
#include <linux/security.h>
#include <linux/init.h>
#include <linux/signal.h>
@@ -1115,6 +1116,10 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
saved_x0 = regs->regs[0];
saved_x8 = regs->regs[8];
+ if (secure_computing(regs->syscallno) == -1)
+ /* seccomp failures shouldn't expose any additional code. */
+ return -1;
+
if (test_thread_flag(TIF_SYSCALL_TRACE))
tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 2/3] asm-generic: Add generic seccomp.h for secure computing mode 1
From: AKASHI Takahiro @ 2014-07-22 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406020499-5537-1-git-send-email-takahiro.akashi@linaro.org>
Those values (__NR_seccomp_*) are used solely in secure_computing()
to identify mode 1 system calls. If compat system calls have different
syscall numbers, asm/seccomp.h may override them.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
include/asm-generic/seccomp.h | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 include/asm-generic/seccomp.h
diff --git a/include/asm-generic/seccomp.h b/include/asm-generic/seccomp.h
new file mode 100644
index 0000000..5e97022
--- /dev/null
+++ b/include/asm-generic/seccomp.h
@@ -0,0 +1,28 @@
+/*
+ * include/asm-generic/seccomp.h
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef _ASM_GENERIC_SECCOMP_H
+#define _ASM_GENERIC_SECCOMP_H
+
+#include <asm-generic/unistd.h>
+
+#if defined(CONFIG_COMPAT) && !defined(__NR_seccomp_read_32)
+#define __NR_seccomp_read_32 __NR_read
+#define __NR_seccomp_write_32 __NR_write
+#define __NR_seccomp_exit_32 __NR_exit
+#define __NR_seccomp_sigreturn_32 __NR_rt_sigreturn
+#endif /* CONFIG_COMPAT && ! already defined */
+
+#define __NR_seccomp_read __NR_read
+#define __NR_seccomp_write __NR_write
+#define __NR_seccomp_exit __NR_exit
+#define __NR_seccomp_sigreturn __NR_rt_sigreturn
+
+#endif /* _ASM_GENERIC_SECCOMP_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 1/3] arm64: ptrace: reload a syscall number after ptrace operations
From: AKASHI Takahiro @ 2014-07-22 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406020499-5537-1-git-send-email-takahiro.akashi@linaro.org>
Arm64 holds a syscall number in w8(x8) register. Ptrace tracer may change
its value either to:
* any valid syscall number to alter a system call, or
* -1 to skip a system call
This patch implements this behavior by reloading that value into syscallno
in struct pt_regs after tracehook_report_syscall_entry() or
secure_computing(). In case of '-1', a return value of system call can also
be changed by the tracer setting the value to x0 register, and so
sys_ni_nosyscall() should not be called.
See also:
42309ab4, ARM: 8087/1: ptrace: reload syscall number after
secure_computing() check
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
arch/arm64/kernel/entry.S | 2 ++
arch/arm64/kernel/ptrace.c | 13 +++++++++++++
2 files changed, 15 insertions(+)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 5141e79..de8bdbc 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -628,6 +628,8 @@ ENDPROC(el0_svc)
__sys_trace:
mov x0, sp
bl syscall_trace_enter
+ cmp w0, #-1 // skip syscall?
+ b.eq ret_to_user
adr lr, __sys_trace_return // return address
uxtw scno, w0 // syscall number (possibly new)
mov x1, sp // pointer to regs
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 70526cf..100d7d1 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -21,6 +21,7 @@
#include <linux/audit.h>
#include <linux/compat.h>
+#include <linux/errno.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/mm.h>
@@ -1109,9 +1110,21 @@ static void tracehook_report_syscall(struct pt_regs *regs,
asmlinkage int syscall_trace_enter(struct pt_regs *regs)
{
+ unsigned long saved_x0, saved_x8;
+
+ saved_x0 = regs->regs[0];
+ saved_x8 = regs->regs[8];
+
if (test_thread_flag(TIF_SYSCALL_TRACE))
tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
+ regs->syscallno = regs->regs[8];
+ if ((long)regs->syscallno == ~0UL) { /* skip this syscall */
+ regs->regs[8] = saved_x8;
+ if (regs->regs[0] == saved_x0) /* not changed by user */
+ regs->regs[0] = -ENOSYS;
+ }
+
if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
trace_sys_enter(regs, regs->syscallno);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 0/3] arm64: Add seccomp support
From: AKASHI Takahiro @ 2014-07-22 9:14 UTC (permalink / raw)
To: linux-arm-kernel
(Please apply this patch after my audit patch in order to avoid some
conflict on arm64/Kconfig.)
This patch enables secure computing (system call filtering) on arm64.
System calls can be allowed or denied by loaded bpf-style rules.
Architecture specific part is to run secure_computing() on syscall entry
and check the result. See [3/3]
Prerequisites are:
* "arm64: Add audit support" patch
This code is tested on ARMv8 fast model using
* libseccomp v2.1.1 with modifications for arm64 and verified by its "live"
tests, 20, 21 and 24.
* modified version of Kees' seccomp test for 'changing/skipping a syscall'
behavior
Changes v4 -> v5:
* rebased to v3.16-rc
* add patch [1/3] to allow ptrace to change a system call
(please note that this patch should be applied even without seccomp.)
Changes v3 -> v4:
* removed the following patch and moved it to "arm64: prerequisites for
audit and ftrace" patchset since it is required for audit and ftrace in
case of !COMPAT, too.
"arm64: is_compat_task is defined both in asm/compat.h and linux/compat.h"
Changes v2 -> v3:
* removed unnecessary 'type cast' operations [2/3]
* check for a return value (-1) of secure_computing() explicitly [2/3]
* aligned with the patch, "arm64: split syscall_trace() into separate
functions for enter/exit" [2/3]
* changed default of CONFIG_SECCOMP to n [2/3]
Changes v1 -> v2:
* added generic seccomp.h for arm64 to utilize it [1,2/3]
* changed syscall_trace() to return more meaningful value (-EPERM)
on seccomp failure case [2/3]
* aligned with the change in "arm64: make a single hook to syscall_trace()
for all syscall features" v2 [2/3]
* removed is_compat_task() definition from compat.h [3/3]
AKASHI Takahiro (3):
arm64: ptrace: reload a syscall number after ptrace operations
asm-generic: Add generic seccomp.h for secure computing mode 1
arm64: Add seccomp support
arch/arm64/Kconfig | 14 ++++++++++++++
arch/arm64/include/asm/seccomp.h | 25 +++++++++++++++++++++++++
arch/arm64/include/asm/unistd.h | 3 +++
arch/arm64/kernel/entry.S | 2 ++
arch/arm64/kernel/ptrace.c | 18 ++++++++++++++++++
include/asm-generic/seccomp.h | 28 ++++++++++++++++++++++++++++
6 files changed, 90 insertions(+)
create mode 100644 arch/arm64/include/asm/seccomp.h
create mode 100644 include/asm-generic/seccomp.h
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/2] drivers/i2c/busses: use correct type for dma_map/unmap
From: Ludovic Desroches @ 2014-07-22 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405935725-10457-2-git-send-email-wsa@the-dreams.de>
On Mon, Jul 21, 2014 at 11:42:03AM +0200, Wolfram Sang wrote:
> dma_{un}map_* uses 'enum dma_data_direction' not 'enum dma_transfer_direction'.
>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Thanks Wolfram.
> ---
> drivers/i2c/busses/i2c-at91.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index e95f9ba96790..83c989382be9 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -210,7 +210,7 @@ static void at91_twi_write_data_dma_callback(void *data)
> struct at91_twi_dev *dev = (struct at91_twi_dev *)data;
>
> dma_unmap_single(dev->dev, sg_dma_address(&dev->dma.sg),
> - dev->buf_len, DMA_MEM_TO_DEV);
> + dev->buf_len, DMA_TO_DEVICE);
>
> at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_STOP);
> }
> @@ -289,7 +289,7 @@ static void at91_twi_read_data_dma_callback(void *data)
> struct at91_twi_dev *dev = (struct at91_twi_dev *)data;
>
> dma_unmap_single(dev->dev, sg_dma_address(&dev->dma.sg),
> - dev->buf_len, DMA_DEV_TO_MEM);
> + dev->buf_len, DMA_FROM_DEVICE);
>
> /* The last two bytes have to be read without using dma */
> dev->buf += dev->buf_len - 2;
> --
> 2.0.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v6 3/7] arm64: kernel: introduce cpu_init_idle CPU operation
From: Lorenzo Pieralisi @ 2014-07-22 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CD9A53.5070001@codeaurora.org>
On Mon, Jul 21, 2014 at 11:55:15PM +0100, Stephen Boyd wrote:
> On 07/21/14 09:06, Lorenzo Pieralisi wrote:
> > diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
> > new file mode 100644
> > index 0000000..46eb3ea
> > --- /dev/null
> > +++ b/arch/arm64/kernel/cpuidle.c
> > @@ -0,0 +1,27 @@
> > +/*
> > + * ARM64 CPU idle arch support
> > + *
> > + * Copyright (C) 2014 ARM Ltd.
> > + * Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <asm/cpu_ops.h>
> > +
> > +int cpu_init_idle(unsigned int cpu)
>
> sparse will probably complain here unless we include <asm/cpuidle.h> right?
Yes, I missed that, now fixed, thanks a lot.
Lorenzo
^ permalink raw reply
* [RESEND PATCH 1/1] ARM: DT: STi: STiH416: Add DT node for ST's SATA device
From: Maxime Coquelin @ 2014-07-22 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405931573-12407-1-git-send-email-lee.jones@linaro.org>
Hi Lee,
On 07/21/2014 10:32 AM, Lee Jones wrote:
> Cc: devicetree at vger.kernel.org
> Acked-by: Alexandre Torgue <alexandre.torgue@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> Documentation/devicetree/bindings/ata/ahci-st.txt | 2 +-
> arch/arm/boot/dts/stih416-b2020.dts | 4 ++++
> arch/arm/boot/dts/stih416-b2020e.dts | 4 ++++
> arch/arm/boot/dts/stih416.dtsi | 16 ++++++++++++++++
> 4 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/ata/ahci-st.txt b/Documentation/devicetree/bindings/ata/ahci-st.txt
> index 0574a77..9883542 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-st.txt
> +++ b/Documentation/devicetree/bindings/ata/ahci-st.txt
> @@ -21,7 +21,7 @@ Example:
> reg = <0xfe380000 0x1000>;
> interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>;
> interrupt-names = "hostc";
> - phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
> + phys = <&phy_port0 MIPHY_TYPE_SATA>;
> phy-names = "ahci_phy";
> resets = <&powerdown STIH416_SATA0_POWERDOWN>,
> <&softreset STIH416_SATA0_SOFTRESET>;
Patch does not apply because this file does not exist in my tree.
Shouldn't be in a separate patch?
Regards,
Maxime
^ permalink raw reply
* [STLinux Kernel] [PATCH v3+1 5/5] ARM: DT: STi: STiH416: Add DT node for MiPHY365x
From: Maxime Coquelin @ 2014-07-22 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140711115406.GB2954@lee--X1>
Hi Lee,
On 07/11/2014 01:54 PM, Lee Jones wrote:
> The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> devices. It has 2 ports which it can use for either; both SATA, both
> PCIe or one of each in any configuration.
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Acked-by: Alexandre Torgue <alexandre.torgue@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
Added to my queue for v3.17.
Thanks,
Maxime
^ permalink raw reply
* [PATCH 1/7] arm: dts: omap3-gta04: Add nand support
From: Belisko Marek @ 2014-07-22 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722062442.GF18374@atomide.com>
On Tue, Jul 22, 2014 at 8:24 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Marek Belisko <marek@goldelico.com> [140721 14:08]:
>
> Can you please add the descriptions to all the patches?
OK thanks for review. I'll send v2.
> Other than that looks OK to me.
>
> Regards,
>
> Tony
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* [PATCH] drm: rcar-du: fix warnings
From: Russell King - ARM Linux @ 2014-07-22 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1X6Ho2-0006rq-Qg@rmk-PC.arm.linux.org.uk>
On Sun, Jul 13, 2014 at 12:18:58PM +0100, Russell King wrote:
> drivers/gpu/drm/rcar-du/rcar_du_drv.c:190:5: warning: "CONFIG_PM_SLEEP" is not defined [-Wundef]
>
> Always use #ifdef with CONFIG symbols, never just bare #if
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Ping?
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 792fd1d20e86..fda64b7b73e8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -187,7 +187,7 @@ static struct drm_driver rcar_du_driver = {
> * Power management
> */
>
> -#if CONFIG_PM_SLEEP
> +#ifdef CONFIG_PM_SLEEP
> static int rcar_du_pm_suspend(struct device *dev)
> {
> struct rcar_du_device *rcdu = dev_get_drvdata(dev);
> --
> 1.8.3.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] drm: shmobile: fix warnings
From: Russell King - ARM Linux @ 2014-07-22 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1X6Ho7-0006ru-U9@rmk-PC.arm.linux.org.uk>
On Sun, Jul 13, 2014 at 12:19:03PM +0100, Russell King wrote:
> drivers/gpu/drm/shmobile/shmob_drm_drv.c:300:5: warning: "CONFIG_PM_SLEEP" is not defined [-Wundef]
>
> Always use #ifdef with CONFIG symbols, never just bare #if
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Ping?
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> index 82c84c7fd4f6..ff4ba483b602 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -297,7 +297,7 @@ static struct drm_driver shmob_drm_driver = {
> * Power management
> */
>
> -#if CONFIG_PM_SLEEP
> +#ifdef CONFIG_PM_SLEEP
> static int shmob_drm_pm_suspend(struct device *dev)
> {
> struct shmob_drm_device *sdev = dev_get_drvdata(dev);
> --
> 1.8.3.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [GIT PULL] Armada DRM devel updates
From: Russell King @ 2014-07-22 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140711200344.GA7973@rmk-PC.arm.linux.org.uk>
On Fri, Jul 11, 2014 at 09:03:44PM +0100, Russell King wrote:
> David,
>
> Please incorporate the latest Armada DRM updates, which can be found at:
>
> git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-armada-devel
Ping?
>
> with SHA1 9611cb93fa65dde199f4f888bd034ffc80c7adf0, based on v3.16-rc3.
>
> This pull includes the component helpers which have been merged into
> Greg's driver-devel tree, and the new DRM OF helper file, which
> Rob has reviewed, along with the Armada DRM updates.
>
> The Armada DRM changes:
> - move the interrupt handling solely into the CRTC layer, otherwise
> we have problems as each CRTC has its own interrupt signal.
> - change the way CRTCs are numbered, to use the number of CRTCs which
> have already been registered. This ultimately equates to the same
> number, so we achieve the same thing but in a simpler way.
> - move the variant initialisation from the DRM driver layer to the CRTC
> layer, which is really where it's needed, and make the variant
> handling purely a CRTC thing.
> - augment Armada DRM with the component helper to allow multiple
> struct device's to describe the DRM subsystem. This will be necessary
> for DT support, as each LCD controller is described as a separate node
> in DT, thus creating separate device structures for each LCD controller.
> - tweak the external reference clock name to match the documentation
> more exactly - there is no underscore before the '1'.
> - allow CRTCs to be registered as separate devices, thereby allowing
> DT to describe the LCD controllers, while preserving the remainder of
> the original behaviour. (The original driver behaviour is still
> available at this time.)
> - register the CRTCs with the DT node so that the recently introduced
> DRM OF helper can be used by encoders to locate their associated
> CRTCs.
>
> This will update the following files:
>
> .../bindings/drm/armada/marvell,dove-lcd.txt | 30 +++
> drivers/base/component.c | 192 +++++++++++++---
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/armada/armada_510.c | 23 +-
> drivers/gpu/drm/armada/armada_crtc.c | 187 ++++++++++++++--
> drivers/gpu/drm/armada/armada_crtc.h | 11 +-
> drivers/gpu/drm/armada/armada_drm.h | 13 +-
> drivers/gpu/drm/armada/armada_drv.c | 245 +++++++++++++++------
> drivers/gpu/drm/drm_of.c | 67 ++++++
> include/drm/drm_crtc.h | 2 +
> include/drm/drm_of.h | 18 ++
> include/linux/component.h | 7 +
> 12 files changed, 642 insertions(+), 154 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/drm/armada/marvell,dove-lcd.txt
> create mode 100644 drivers/gpu/drm/drm_of.c
> create mode 100644 include/drm/drm_of.h
>
> through these changes:
>
> Russell King (15):
> component: fix missed cleanup in case of devres failure
> component: ignore multiple additions of the same component
> component: add support for component match array
> drm/armada: move IRQ handling into CRTC
> drm/armada: use number of CRTCs registered
> drm/armada: move variant initialisation to CRTC init
> drm/armada: make variant a CRTC thing
> component: fix bug with legacy API
> drm: add of_graph endpoint helper to find possible CRTCs
> Merge branches 'drm-devel' and 'component-for-driver' into armada-drm
> drm/armada: convert to componentized support
> drm/armada: update Armada 510 (Dove) to use "ext_ref_clk1" as the clock
> dt-bindings: add Marvell Dove LCD controller documentation
> drm/armada: permit CRTCs to be registered as separate devices
> drm/armada: register crtc with port
>
> Many thanks.
^ permalink raw reply
* [GIT PULL] msm drm update for component changes
From: Russell King @ 2014-07-22 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140709093458.GA17540@rmk-PC.arm.linux.org.uk>
On Wed, Jul 09, 2014 at 10:34:58AM +0100, Russell King wrote:
> David,
>
> Please incorporate the latest msm drm update for component changes, which can be found at:
>
> git://ftp.arm.linux.org.uk/~rmk/linux-arm.git component-for-drm
Ping?
>
> with SHA1 84448288546d13d7e06fd6638fb78ddff559b399.
>
> This updates the MSM's DRM driver for the updates merged in Greg's
> driver-core tree, converting MSM to use the pre-declared array of
> matches rather than walking the device tree each time we try to bind.
>
> This will update the following files:
>
> drivers/base/component.c | 192 ++++++++++++++++++++++++++++++++++--------
> drivers/gpu/drm/msm/msm_drv.c | 83 ++++++++----------
> include/linux/component.h | 7 ++
> 3 files changed, 199 insertions(+), 83 deletions(-)
>
> through these changes:
>
> Russell King (5):
> component: fix missed cleanup in case of devres failure
> component: ignore multiple additions of the same component
> component: add support for component match array
> component: fix bug with legacy API
> drm: msm: update to use component match support
>
> Many thanks.
^ permalink raw reply
* [PATCH] ARM: imx6: fix SMP compilation again
From: Shawn Guo @ 2014-07-22 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37015543.ZyZKZyEIPW@wuerfel>
On Tue, Jul 22, 2014 at 10:30:50AM +0200, Arnd Bergmann wrote:
> My earlier patch 1fc593feaf8e ("ARM: imx: build i.MX6 functions
> only when needed") fixed a problem with building an i.MX5 kernel,
> but missed the corner case of building a kernel for i.MX5 with
> SMP enabled. It is an extremely rare case that has only now
> happened after many thousands of randconfig kernel builds.
>
> The error message I get is
> arch/arm/mach-imx/built-in.o: In function `v7_secondary_startup':
> :(.text+0x5124): undefined reference to `v7_invalidate_l1'
I cannot reproduce it, and unsure how it happens.
The v7_invalidate_l1() is defined in arch/arm/mm/cache-v7.S, and should
be available for i.MX5 build.
Shawn
>
> This puts the code inside of an "ifdef CONFIG_SMP" to hopefully
> do the right thing in all configurations.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index ac88599ca080..23c02932bf84 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -93,9 +93,11 @@ obj-$(CONFIG_HAVE_IMX_ANATOP) += anatop.o
> obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
> obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
> obj-$(CONFIG_HAVE_IMX_SRC) += src.o
> +ifdef CONFIG_SOC_IMX6
> AFLAGS_headsmp.o :=-Wa,-march=armv7-a
> obj-$(CONFIG_SMP) += headsmp.o platsmp.o
> obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
> +endif
> obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o mach-imx6q.o
> obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o mach-imx6sl.o
> obj-$(CONFIG_SOC_IMX6SX) += clk-imx6sx.o mach-imx6sx.o
>
^ permalink raw reply
* Fix me in netx-regs.h
From: Arnd Bergmann @ 2014-07-22 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDOMVhdK67Fc5KsamL8XKdRNy0VjKB3ub24krgwmRsnZGtQNQ@mail.gmail.com>
On Tuesday 22 July 2014 00:16:26 Nick Krause wrote:
> Hey Russell,
> I did give thought to our previous conversations and I will still do
> fix mes but am going to be more careful
> with I submit them. Furthermore it seems #define
> NETX_GPIO_COUNTER_CTRL_GPIO_RE is not defined
> correctly. As the maintainer what should I define it to?
Are you offering to become the maintainer for netx?
Try to get hold of a reference manual for the chip. More importantly
than the fixme, I think we should be able to move this platform into
ARCH_MULTIPLATFORM. This means moving the contents of the header files
into the places where they are used, and finding a better home for the
pfifo driver.
Arnd
^ permalink raw reply
* [PATCH 2/2] iio: adc: exynos_adc: Add support for S3C24xx ADC
From: Arnd Bergmann @ 2014-07-22 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405995074-3271-3-git-send-email-cw00.choi@samsung.com>
On Tuesday 22 July 2014 11:11:14 Chanwoo Choi wrote:
> This patch add support for s3c2410/s3c2416/s3c2440/s3c2443 ADC. The s3c24xx
> is alomost same as ADCv1. But, There are a little difference as following:
> - ADCMUX register address to select channel
> - ADCDAT mask (10bit or 12bit ADC resolution according to SoC version)
Very good, thanks for doing this patch!
(adding Heiko to Cc, he's probably interested in seeing this as well.
One comment:
> @@ -101,12 +107,14 @@ struct exynos_adc {
> struct completion completion;
>
> u32 value;
> + u32 value2;
> unsigned int version;
> };
> ...
> @@ -365,7 +448,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> ret = -ETIMEDOUT;
> } else {
> *val = info->value;
> - *val2 = 0;
> + *val2 = info->value2;
> ret = IIO_VAL_INT;
> }
>
> @@ -377,9 +460,11 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
> {
> struct exynos_adc *info = (struct exynos_adc *)dev_id;
> + u32 mask = info->data->mask;
>
> /* Read value */
> - info->value = readl(ADC_V1_DATX(info->regs)) & ADC_DATX_MASK;
> + info->value = readl(ADC_V1_DATX(info->regs)) & mask;
> + info->value2 = readl(ADC_V1_DATY(info->regs)) & mask;
>
> /* clear irq */
> if (info->data->clear_irq)
If I understand it right, this would only be necessary if we want
to do the touchscreen driver as a separate iio client using the
in-kernel interfaces. As Jonathan Cameron commented, we probably
don't want to do that though. Even if we do, it should be a separate
patch and not mixed in with the s3c24xx support.
Aside from this:
Acked-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ permalink raw reply
* [PATCH] ARM: imx6: fix SMP compilation again
From: Arnd Bergmann @ 2014-07-22 8:30 UTC (permalink / raw)
To: linux-arm-kernel
My earlier patch 1fc593feaf8e ("ARM: imx: build i.MX6 functions
only when needed") fixed a problem with building an i.MX5 kernel,
but missed the corner case of building a kernel for i.MX5 with
SMP enabled. It is an extremely rare case that has only now
happened after many thousands of randconfig kernel builds.
The error message I get is
arch/arm/mach-imx/built-in.o: In function `v7_secondary_startup':
:(.text+0x5124): undefined reference to `v7_invalidate_l1'
This puts the code inside of an "ifdef CONFIG_SMP" to hopefully
do the right thing in all configurations.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index ac88599ca080..23c02932bf84 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -93,9 +93,11 @@ obj-$(CONFIG_HAVE_IMX_ANATOP) += anatop.o
obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
obj-$(CONFIG_HAVE_IMX_SRC) += src.o
+ifdef CONFIG_SOC_IMX6
AFLAGS_headsmp.o :=-Wa,-march=armv7-a
obj-$(CONFIG_SMP) += headsmp.o platsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
+endif
obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o mach-imx6q.o
obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o mach-imx6sl.o
obj-$(CONFIG_SOC_IMX6SX) += clk-imx6sx.o mach-imx6sx.o
^ permalink raw reply related
* iMX6Q FEC: transmit queue 0 timed out
From: Shawn Guo @ 2014-07-22 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOpc7mHvddM1bCex13yPTRrEkFqYvk2YHYajZeMn+MG83neUBA@mail.gmail.com>
On Wed, Jul 16, 2014 at 10:41:10AM +0200, Holger Schurig wrote:
> Andy,
>
> to revive an old thread: I now got ethernet working. Basically, I
> needed to set the system so that the PHY is generating the ref-clock.
> I found even code in arch/arm/mach-imx/mach-imx6q.c that controls
> setting of GPR1[21] from the device tree. However, I wasn't really
> able to come up with a device-tree that triggers the code
> IMX6Q_GPR1_ENET_CLK_SEL_PAD. For example, Neither
> Documentation/devicetree/bindings/net/fsl-fec.txt nor any other file
> there mention anything on how to do this.
>
> Currently I disable the 3rd clock. I changed the default
> clocks = <&clks 117>, <&clks 117>, <&clks 190>;
> clock-names = "ipg", "ahb", "ptp";
> (from imx6qdl.dtsi) to my dts:
> clocks = <&clks 117>, <&clks 117>;
> clock-names = "ipg", "ahb";
>
> Would I have needed to create some dummy clock, e.g. "ext-phy-clk" and
> specified that as a third clock in my dts?
Since in your setup PHY is generating the reference clock, you need to
define this clock in your board dts, and overwrite the 'ptp' clock with
it, something like the following.
clocks {
#address-cells = <1>;
#size-cells = <0>;
rmii_clk: clock at 0 {
compatible = "fixed-clock";
reg = <0>;
#clock-cells = <0>;
clock-frequency = <25000000>; /* 25MHz for example */
clock-output-names = "rmii_ref_clk";
};
};
&fec {
clocks = <&clks 117>, <&clks 117>, <&rmii_clk>;
};
^ 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