* [PATCH v5] soc: qcom: add l2 cache perf events driver
From: kbuild test robot @ 2016-09-21 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474470350-25818-1-git-send-email-nleeder@codeaurora.org>
Hi Neil,
[auto build test ERROR on next-20160921]
[cannot apply to linus/master linux/master v4.8-rc7 v4.8-rc6 v4.8-rc5 v4.8-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Neil-Leeder/soc-qcom-add-l2-cache-perf-events-driver/20160922-000500
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
drivers/soc/qcom/perf_event_l2.c: In function 'set_l2_indirect_reg':
>> drivers/soc/qcom/perf_event_l2.c:92:2: error: implicit declaration of function 'write_sysreg' [-Werror=implicit-function-declaration]
write_sysreg(reg, L2CPUSRSELR_EL1);
^~~~~~~~~~~~
>> drivers/soc/qcom/perf_event_l2.c:74:33: error: 'S3_3_c15_c0_6' undeclared (first use in this function)
#define L2CPUSRSELR_EL1 S3_3_c15_c0_6
^
>> drivers/soc/qcom/perf_event_l2.c:92:20: note: in expansion of macro 'L2CPUSRSELR_EL1'
write_sysreg(reg, L2CPUSRSELR_EL1);
^~~~~~~~~~~~~~~
drivers/soc/qcom/perf_event_l2.c:74:33: note: each undeclared identifier is reported only once for each function it appears in
#define L2CPUSRSELR_EL1 S3_3_c15_c0_6
^
>> drivers/soc/qcom/perf_event_l2.c:92:20: note: in expansion of macro 'L2CPUSRSELR_EL1'
write_sysreg(reg, L2CPUSRSELR_EL1);
^~~~~~~~~~~~~~~
>> drivers/soc/qcom/perf_event_l2.c:75:33: error: 'S3_3_c15_c0_7' undeclared (first use in this function)
#define L2CPUSRDR_EL1 S3_3_c15_c0_7
^
>> drivers/soc/qcom/perf_event_l2.c:94:20: note: in expansion of macro 'L2CPUSRDR_EL1'
write_sysreg(val, L2CPUSRDR_EL1);
^~~~~~~~~~~~~
drivers/soc/qcom/perf_event_l2.c: In function 'get_l2_indirect_reg':
>> drivers/soc/qcom/perf_event_l2.c:74:33: error: 'S3_3_c15_c0_6' undeclared (first use in this function)
#define L2CPUSRSELR_EL1 S3_3_c15_c0_6
^
drivers/soc/qcom/perf_event_l2.c:112:20: note: in expansion of macro 'L2CPUSRSELR_EL1'
write_sysreg(reg, L2CPUSRSELR_EL1);
^~~~~~~~~~~~~~~
>> drivers/soc/qcom/perf_event_l2.c:114:8: error: implicit declaration of function 'read_sysreg' [-Werror=implicit-function-declaration]
val = read_sysreg(L2CPUSRDR_EL1);
^~~~~~~~~~~
>> drivers/soc/qcom/perf_event_l2.c:75:33: error: 'S3_3_c15_c0_7' undeclared (first use in this function)
#define L2CPUSRDR_EL1 S3_3_c15_c0_7
^
drivers/soc/qcom/perf_event_l2.c:114:20: note: in expansion of macro 'L2CPUSRDR_EL1'
val = read_sysreg(L2CPUSRDR_EL1);
^~~~~~~~~~~~~
drivers/soc/qcom/perf_event_l2.c: In function 'l2_cache_pmu_probe_cluster':
>> drivers/soc/qcom/perf_event_l2.c:787:6: error: implicit declaration of function 'acpi_bus_get_device' [-Werror=implicit-function-declaration]
if (acpi_bus_get_device(ACPI_HANDLE(dev), &device))
^~~~~~~~~~~~~~~~~~~
>> drivers/soc/qcom/perf_event_l2.c:790:20: error: dereferencing pointer to incomplete type 'struct acpi_device'
if (kstrtol(device->pnp.unique_id, 10, &fw_cluster_id) < 0) {
^~
cc1: some warnings being treated as errors
vim +/write_sysreg +92 drivers/soc/qcom/perf_event_l2.c
68
69 #define L2_EVT_GROUP_MAX 7
70
71 #define L2_MAX_PERIOD U32_MAX
72 #define L2_CNT_PERIOD (U32_MAX - GENMASK(26, 0))
73
> 74 #define L2CPUSRSELR_EL1 S3_3_c15_c0_6
> 75 #define L2CPUSRDR_EL1 S3_3_c15_c0_7
76
77 static DEFINE_RAW_SPINLOCK(l2_access_lock);
78
79 /**
80 * set_l2_indirect_reg: write value to an L2 register
81 * @reg: Address of L2 register.
82 * @value: Value to be written to register.
83 *
84 * Use architecturally required barriers for ordering between system register
85 * accesses
86 */
87 static void set_l2_indirect_reg(u64 reg, u64 val)
88 {
89 unsigned long flags;
90
91 raw_spin_lock_irqsave(&l2_access_lock, flags);
> 92 write_sysreg(reg, L2CPUSRSELR_EL1);
93 isb();
> 94 write_sysreg(val, L2CPUSRDR_EL1);
95 isb();
96 raw_spin_unlock_irqrestore(&l2_access_lock, flags);
97 }
98
99 /**
100 * get_l2_indirect_reg: read an L2 register value
101 * @reg: Address of L2 register.
102 *
103 * Use architecturally required barriers for ordering between system register
104 * accesses
105 */
106 static u64 get_l2_indirect_reg(u64 reg)
107 {
108 u64 val;
109 unsigned long flags;
110
111 raw_spin_lock_irqsave(&l2_access_lock, flags);
112 write_sysreg(reg, L2CPUSRSELR_EL1);
113 isb();
> 114 val = read_sysreg(L2CPUSRDR_EL1);
115 raw_spin_unlock_irqrestore(&l2_access_lock, flags);
116
117 return val;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 59315 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160922/bf497f00/attachment-0001.gz>
^ permalink raw reply
* [PATCH] arm64: Correctly bounds check virt_addr_valid
From: Mark Rutland @ 2016-09-21 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b8f34fc7-76ac-5681-085a-8c007cd40e98@redhat.com>
On Wed, Sep 21, 2016 at 12:34:46PM -0700, Laura Abbott wrote:
> On 09/21/2016 10:58 AM, Mark Rutland wrote:
> >Are there other potentially-broken users of virt_addr_valid? It's not
> >clear to me what some drivers are doing with this, and therefore whether
> >we need to cc stable.
>
> The number of users is pretty limited. Some of them use it as a debugging
> check, others are using it more like hardened usercopy. The number of
> users that would actually affect arm64 seems so small I don't think it's
> worth trying to backport to stable.
Ok.
> Hardened usercopy was getting hit particularly hard because usercopy was
> happening on all types of memory whereas the drivers tend to be more limited
> in scope.
Sure.
> >Given the common sub-expression, perhaps it would be better to leave
> >these as-is, but prefix them with '_', and after the #endif, have
> >something like:
> >
> >#define _virt_addr_is_linear(kaddr) (((u64)(kaddr)) >= PAGE_OFFSET)
> >#define virt_addr_valid(kaddr) (_virt_addr_is_linear(kaddr) && _virt_addr_valid(kaddr))
> >
>
> Good suggestion.
FWIW, with that, feel free to add:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
^ permalink raw reply
* [PATCH] arm64: Add BCM2835 (Raspberry Pi 3) support to the defconfig
From: Florian Fainelli @ 2016-09-21 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919133150.9371-1-eric@anholt.net>
On 09/19/2016 06:31 AM, Eric Anholt wrote:
> Most of the drivers are included as modules, except for serial (needed
> for early console), WDT (required for reboot), and the dependency
> chain of RASPBERRYPI_POWER (which is currently not buildable as a
> module, but should be changed).
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
LGTM, can you queue this for the next ARM/ARM64 SoC pull request in a
separate branch for me to pull from?
Thanks!
> ---
> arch/arm64/configs/defconfig | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index fb8d84516e92..9748c4735a60 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -34,6 +34,7 @@ CONFIG_MODULE_UNLOAD=y
> # CONFIG_IOSCHED_DEADLINE is not set
> CONFIG_ARCH_SUNXI=y
> CONFIG_ARCH_ALPINE=y
> +CONFIG_ARCH_BCM2835=y
> CONFIG_ARCH_BCM_IPROC=y
> CONFIG_ARCH_BERLIN=y
> CONFIG_ARCH_EXYNOS=y
> @@ -193,6 +194,7 @@ CONFIG_USB_NET_SMSC75XX=m
> CONFIG_USB_NET_SMSC95XX=m
> CONFIG_USB_NET_PLUSB=m
> CONFIG_USB_NET_MCS7830=m
> +CONFIG_BRCMFMAC=m
> CONFIG_WL18XX=m
> CONFIG_WLCORE_SDIO=m
> CONFIG_INPUT_EVDEV=y
> @@ -205,6 +207,9 @@ CONFIG_SERIO_AMBAKMI=y
> CONFIG_LEGACY_PTY_COUNT=16
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_8250_EXTENDED=y
> +CONFIG_SERIAL_8250_SHARE_IRQ=y
> +CONFIG_SERIAL_8250_BCM2835AUX=y
> CONFIG_SERIAL_8250_DW=y
> CONFIG_SERIAL_8250_MT6577=y
> CONFIG_SERIAL_8250_UNIPHIER=y
> @@ -228,6 +233,7 @@ CONFIG_VIRTIO_CONSOLE=y
> CONFIG_I2C_CHARDEV=y
> CONFIG_I2C_MUX=y
> CONFIG_I2C_MUX_PCA954x=y
> +CONFIG_I2C_BCM2835=m
> CONFIG_I2C_DESIGNWARE_PLATFORM=y
> CONFIG_I2C_IMX=y
> CONFIG_I2C_MESON=y
> @@ -238,6 +244,8 @@ CONFIG_I2C_UNIPHIER_F=y
> CONFIG_I2C_RCAR=y
> CONFIG_I2C_CROS_EC_TUNNEL=y
> CONFIG_SPI=y
> +CONFIG_SPI_BCM2835=m
> +CONFIG_SPI_BCM2835AUX=m
> CONFIG_SPI_MESON_SPIFC=m
> CONFIG_SPI_ORION=y
> CONFIG_SPI_PL022=y
> @@ -272,6 +280,7 @@ CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
> CONFIG_CPU_THERMAL=y
> CONFIG_EXYNOS_THERMAL=y
> CONFIG_WATCHDOG=y
> +CONFIG_BCM2835_WDT=y
> CONFIG_RENESAS_WDT=y
> CONFIG_S3C2410_WATCHDOG=y
> CONFIG_MESON_GXBB_WATCHDOG=m
> @@ -294,6 +303,7 @@ CONFIG_REGULATOR_S2MPS11=y
> CONFIG_DRM=m
> CONFIG_DRM_NOUVEAU=m
> CONFIG_DRM_TEGRA=m
> +CONFIG_DRM_VC4=m
> CONFIG_DRM_PANEL_SIMPLE=m
> CONFIG_DRM_I2C_ADV7511=m
> CONFIG_DRM_HISI_KIRIN=m
> @@ -308,6 +318,7 @@ CONFIG_LOGO=y
> CONFIG_SOUND=y
> CONFIG_SND=y
> CONFIG_SND_SOC=y
> +CONFIG_SND_BCM2835_SOC_I2S=m
> CONFIG_SND_SOC_RCAR=y
> CONFIG_SND_SOC_SAMSUNG=y
> CONFIG_SND_SOC_AK4613=y
> @@ -372,6 +383,7 @@ CONFIG_RTC_DRV_XGENE=y
> CONFIG_RTC_DRV_S3C=y
> CONFIG_DMADEVICES=y
> CONFIG_PL330_DMA=y
> +CONFIG_DMA_BCM2835=m
> CONFIG_TEGRA20_APB_DMA=y
> CONFIG_QCOM_BAM_DMA=y
> CONFIG_QCOM_HIDMA_MGMT=y
> @@ -394,8 +406,10 @@ CONFIG_MSM_MMCC_8996=y
> CONFIG_HWSPINLOCK_QCOM=y
> CONFIG_MAILBOX=y
> CONFIG_ARM_MHU=y
> +CONFIG_BCM2835_MBOX=y
> CONFIG_HI6220_MBOX=y
> CONFIG_ARM_SMMU=y
> +CONFIG_RASPBERRYPI_POWER=y
> CONFIG_QCOM_SMEM=y
> CONFIG_QCOM_SMD=y
> CONFIG_QCOM_SMD_RPM=y
> @@ -403,6 +417,7 @@ CONFIG_ARCH_TEGRA_132_SOC=y
> CONFIG_ARCH_TEGRA_210_SOC=y
> CONFIG_EXTCON_USB_GPIO=y
> CONFIG_PWM=y
> +CONFIG_PWM_BCM2835=m
> CONFIG_PWM_TEGRA=m
> CONFIG_COMMON_RESET_HI6220=y
> CONFIG_PHY_RCAR_GEN3_USB2=y
> @@ -414,6 +429,7 @@ CONFIG_ACPI=y
> CONFIG_IIO=y
> CONFIG_EXYNOS_ADC=y
> CONFIG_PWM_SAMSUNG=y
> +CONFIG_RASPBERRYPI_FIRMWARE=y
> CONFIG_EXT2_FS=y
> CONFIG_EXT3_FS=y
> CONFIG_EXT4_FS_POSIX_ACL=y
>
--
Florian
^ permalink raw reply
* [PATCH] arm64: Correctly bounds check virt_addr_valid
From: Laura Abbott @ 2016-09-21 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921175855.GG18176@leverpostej>
On 09/21/2016 10:58 AM, Mark Rutland wrote:
> Hi,
>
> On Wed, Sep 21, 2016 at 10:28:48AM -0700, Laura Abbott wrote:
>> virt_addr_valid is supposed to return true if and only if virt_to_page
>> returns a valid page structure. The current macro does math on whatever
>> address is given and passes that to pfn_valid to verify. vmalloc and
>> module addresses can happen to generate a pfn that 'happens' to be
>> valid. Fix this by only performing the pfn_valid check on addresses that
>> have the potential to be valid.
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> This caused a bug at least twice in hardened usercopy so it is an
>> actual problem.
>
> Are there other potentially-broken users of virt_addr_valid? It's not
> clear to me what some drivers are doing with this, and therefore whether
> we need to cc stable.
>
The number of users is pretty limited. Some of them use it as a debugging
check, others are using it more like hardened usercopy. The number of
users that would actually affect arm64 seems so small I don't think it's
worth trying to backport to stable. Hardened usercopy was getting hit
particularly hard because usercopy was happening on all types of memory
whereas the drivers tend to be more limited in scope.
>> A further TODO is full DEBUG_VIRTUAL support to
>> catch these types of mistakes.
>> ---
>> arch/arm64/include/asm/memory.h | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index 31b7322..f741e19 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -214,7 +214,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>>
>> #ifndef CONFIG_SPARSEMEM_VMEMMAP
>> #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
>> -#define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
>> +#define virt_addr_valid(kaddr) (((u64)kaddr) >= PAGE_OFFSET && pfn_valid(__pa(kaddr) >> PAGE_SHIFT))
>> #else
>> #define __virt_to_pgoff(kaddr) (((u64)(kaddr) & ~PAGE_OFFSET) / PAGE_SIZE * sizeof(struct page))
>> #define __page_to_voff(kaddr) (((u64)(page) & ~VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
>> @@ -222,8 +222,8 @@ static inline void *phys_to_virt(phys_addr_t x)
>> #define page_to_virt(page) ((void *)((__page_to_voff(page)) | PAGE_OFFSET))
>> #define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) | VMEMMAP_START))
>>
>> -#define virt_addr_valid(kaddr) pfn_valid((((u64)(kaddr) & ~PAGE_OFFSET) \
>> - + PHYS_OFFSET) >> PAGE_SHIFT)
>> +#define virt_addr_valid(kaddr) (((u64)kaddr) >= PAGE_OFFSET && pfn_valid((((u64)(kaddr) & ~PAGE_OFFSET) \
>> + + PHYS_OFFSET) >> PAGE_SHIFT))
>> #endif
>> #endif
>
> Given the common sub-expression, perhaps it would be better to leave
> these as-is, but prefix them with '_', and after the #endif, have
> something like:
>
> #define _virt_addr_is_linear(kaddr) (((u64)(kaddr)) >= PAGE_OFFSET)
> #define virt_addr_valid(kaddr) (_virt_addr_is_linear(kaddr) && _virt_addr_valid(kaddr))
>
Good suggestion.
> Otherwise, modulo the parenthesis issue you mentioned, this looks
> logically correct to me.
>
> Thanks,
> Mark.
>
Thanks,
Laura
^ permalink raw reply
* [PATCH v2 2/2] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
From: Dave Gerlach @ 2016-09-21 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908033909.GR27345@vireshk-i7>
Viresh,
On 09/07/2016 10:39 PM, Viresh Kumar wrote:
> On 07-09-16, 10:04, Dave Gerlach wrote:
>>>> +static const struct of_device_id ti_cpufreq_of_match[] = {
>>>> + { .compatible = "operating-points-v2-ti-am3352-cpu",
>>>> + .data = &am3x_soc_data, },
>>>> + { .compatible = "operating-points-v2-ti-am4372-cpu",
>>>> + .data = &am4x_soc_data, },
>>>> + { .compatible = "operating-points-v2-ti-dra7-cpu",
>>>> + .data = &dra7_soc_data },
>>>
>>> You should be using your SoC compatible strings here. OPP compatible
>>> property isn't supposed to be (mis)used for this purpose.
>>>
>>
>> Referring to my comments in patch 1, what if we end up changing the bindings
>> based on DT maintainer comments? We will have these compatible strings, and
>> at that point is it acceptable to match against them? Or is it still better
>> to match to SoC compatibles? I think it makes sense to just probe against
>> these.
>
> But even then I think these are not correct. You should have added a
> single compatible string: operating-points-v2-ti-cpu.
>
> As the properties will stay the same across machines. And then you
> need to use SoC strings here.
>
Are you opposed to moving _of_get_opp_desc_node from
drivers/base/power/opp/opp.h to include/linux/pm_opp.h and renaming it
appropriately?
If I move the ti properties out of the cpu node, as discussed in patch 1
of this series, and into the operating-points-v2 table, I need a way to
get the operating-points-v2 device node and I think it makes sense to
reuse this as it is what the opp framework uses internally to parse the
phandle to the opp table.
Regards,
Dave
^ permalink raw reply
* [PATCH V3 3/4] ARM64 LPC: support serial based on low-pin-count
From: Arnd Bergmann @ 2016-09-21 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <815bebc1-96c9-2131-930d-bccdd4bf1c55@gmail.com>
On Wednesday, September 21, 2016 6:12:28 PM CEST zhichang wrote:
> On 2016?09?15? 05:33, Arnd Bergmann wrote:
> > On Wednesday, September 14, 2016 11:04:33 PM CEST zhichang.yuan wrote:
> >> The 8250_hisi_lpc.c support both ACPI and dts similar to 8250_dw :
> >>
> >> +static struct platform_driver hs_lpc8250_driver = {
> >> + .driver = {
> >> + .name = "hisi-lpc-uart",
> >> + .of_match_table = hs8250_of_match,
> >> + .acpi_match_table = ACPI_PTR(hs8250_acpi_match),
> >>
> >> So, I am a little confused why we need to support dts in 8250_of.c and support ACPI in another
> >> driver file.
> >>
> >
> > After looking again, I'm pretty sure that drivers/tty/serial/8250/8250_pnp.c
> > will handle the ACPI case without modifications, you just need to adapt
> > the 8250_of driver to handle IORESOURCE_IO ports. This will be required
> > anyway with the next version once the LPC bridge is on the PCI bus.
> >
>
> Yes. You are right.
>
> When the indirectIO patch is accepted, no much changes needed in these two file to support LPC UART.
>
> BTW, what is your target to change these two files to support LPC uart?
> Do you think we don't need to add many new c files??
I think by modifying 8250_of.c, you should be able to make any UART on
some LPC bus work, regardless of what controller is used.
The ACPI version (8250_pnp.c) shouldn't need any changes at all if I
read that correctly.
Arnd
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Bjorn Helgaas @ 2016-09-21 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDn4CeoB+sELQ5yQDQUS158raEu5QohPH2PsVtuGpfGKHg@mail.gmail.com>
On Wed, Sep 21, 2016 at 11:58:22AM -0700, Duc Dang wrote:
> On Wed, Sep 21, 2016 at 11:04 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote:
> > The existing x86 practice is to use PNP0C02 devices for this purpose,
> > and I think we should just follow that practice.
> >
> > ...
> >
> > My point is that the hard-coding should not be buried in a driver
> > where it's invisible to the rest of the kernel. If we hard-code it in
> > a quirk that adds _CRS entries, then the kernel will work just like it
> > would if the firmware had been correct in the first place. The
> > resource will appear in /sys/devices/pnp*/*/resources and /proc/iomem,
> > and if we ever used _SRS to assign or move ACPI devices, we would know
> > to avoid the bridge resource.
>
> Are you suggesting to add code similar to functions in
> linux/drivers/pnp/quirks.c to declare/attach the additional resource
> that the host need to have when the resource is not in MCFG table?
Yes, but what I'm suggesting is actually a little stronger. This has
nothing to do with whether a resource is in the MCFG table or not.
I'm suggesting ACPI firmware should always describe the resource. If the
firmware is defective and doesn't describe it, we should add a quirk in
pnp/quirks.c to add a resource for it.
Bjorn
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Bjorn Helgaas @ 2016-09-21 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F87CF8F@lhreml507-mbx>
On Wed, Sep 21, 2016 at 02:10:55PM +0000, Gabriele Paoloni wrote:
> Hi Bjorn
>
> [...]
>
>
> >
> > If future hardware is completely ECAM-compliant and we don't need any
> > more MCFG quirks, that would be great.
> >
> > But we'll still need to describe that memory-mapped config space
> > somewhere. If that's done with PNP0C02 or similar devices (as is done
> > on my x86 laptop), we'd be all set.
> >
> > If we need to work around firmware in the field that doesn't do that,
> > one possibility is a PNP quirk along the lines of
> > quirk_amd_mmconfig_area().
>
> So, if my understanding is correct, for platforms that have not been
> shipped yet you propose to use PNP0C02 in the ACPI table in order to
> declare a motherboard reserved resource whereas for shipped platforms
> you propose to have a quirk along pnp_fixups in order to track the
> resource usage even if values are hardcoded...correct?
Yes. I'm open to alternate proposals, but x86 uses PNP0C02, and
following existing practice seems reasonable.
> Before Tomasz came up with this patchset we had a call between the vendors
> involved in this PCI quirks saga and other guys from Linaro and ARM.
>
> Lorenzo summarized the outcome as in the following link
> http://lkml.iu.edu/hypermail/linux/kernel/1606.2/03344.html
>
> Since this quirks mechanism has been discussed for quite a long time now
> IMHO it would be good to have a last call including also you (Bjorn) so
> that we can all agree on what to do and we avoid changing our drivers again
> and again...
I think we're converging pretty fast. As far as I'm concerned, the
v6 ECAM quirks implementation is perfect. The only remaining issue is
reporting the ECAM resources, and I haven't seen objections to using
PNP0C02 + PNP quirks for broken firmware.
There is the question of how or whether to associate a PNP0A03 PCI
bridge with resources from a different PNP0C02 device, but that's not
super important. If the hard-coded resources appear both in a quirk
and in the PCI bridge driver, it's ugly but not the end of the world.
We've still achieved the objective of avoiding landmines in the
address space.
Bjorn
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Duc Dang @ 2016-09-21 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921180457.GB20006@localhost>
On Wed, Sep 21, 2016 at 11:04 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote:
>> On Tue, Sep 20, 2016 at 02:17:44PM -0500, Bjorn Helgaas wrote:
>> > On Tue, Sep 20, 2016 at 04:09:25PM +0100, Ard Biesheuvel wrote:
>>
>> [...]
>>
>> > > None of these platforms can be fixed entirely in software, and given
>> > > that we will not be adding quirks for new broken hardware, we should
>> > > ask ourselves whether having two versions of a quirk, i.e., one for
>> > > broken hardware + currently shipping firmware, and one for the same
>> > > broken hardware with fixed firmware is really an improvement over what
>> > > has been proposed here.
>> >
>> > We're talking about two completely different types of quirks:
>> >
>> > 1) MCFG quirks to use memory-mapped config space that doesn't quite
>> > conform to the ECAM model in the PCIe spec, and
>> >
>> > 2) Some yet-to-be-determined method to describe address space
>> > consumed by a bridge.
>> >
>> > The first two patches of this series are a nice implementation for 1).
>> > The third patch (ThunderX-specific) is one possibility for 2), but I
>> > don't like it because there's no way for generic software like the
>> > ACPI core to discover these resources.
>>
>> Ok, so basically this means that to implement (2) we need to assign
>> some sort of _HID to these quirky PCI bridges (so that we know what
>> device they represent and we can retrieve their _CRS). I take from
>> this discussion that the goal is to make sure that all non-config
>> resources have to be declared through _CRS device objects, which is
>> fine but that requires a FW update (unless we can fabricate ACPI
>> devices and corresponding _CRS in the kernel whenever we match a
>> given MCFG table signature).
>
> All resources consumed by ACPI devices should be declared through
> _CRS. If you want to fabricate ACPI devices or _CRS via kernel
> quirks, that's fine with me. This could be triggered via MCFG
> signature, DMI info, host bridge _HID, etc.
>
>> We discussed this already and I think we should make a decision:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414722.html
>>
>> > > > I'd like to step back and come up with some understanding of how
>> > > > non-broken firmware *should* deal with this issue. Then, if we *do*
>> > > > work around this particular broken firmware in the kernel, it would be
>> > > > nice to do it in a way that fits in with that understanding.
>> > > >
>> > > > For example, if a companion ACPI device is the preferred solution, an
>> > > > ACPI quirk could fabricate a device with the required resources. That
>> > > > would address the problem closer to the source and make it more likely
>> > > > that the rest of the system will work correctly: /proc/iomem could
>> > > > make sense, things that look at _CRS generically would work (e.g,
>> > > > /sys/, an admittedly hypothetical "lsacpi", etc.)
>> > > >
>> > > > Hard-coding stuff in drivers is a point solution that doesn't provide
>> > > > any guidance for future platforms and makes it likely that the hack
>> > > > will get copied into even more drivers.
>> > > >
>> > >
>> > > OK, I see. But the guidance for future platforms should be 'do not
>> > > rely on quirks', and what I am arguing here is that the more we polish
>> > > up this code and make it clean and reusable, the more likely it is
>> > > that will end up getting abused by new broken hardware that we set out
>> > > to reject entirely in the first place.
>> > >
>> > > So of course, if the quirk involves claiming resources, let's make
>> > > sure that this occurs in the cleanest and most compliant way possible.
>> > > But any factoring/reuse concerns other than for the current crop of
>> > > broken hardware should be avoided imo.
>> >
>> > If future hardware is completely ECAM-compliant and we don't need any
>> > more MCFG quirks, that would be great.
>>
>> Yes.
>>
>> > But we'll still need to describe that memory-mapped config space
>> > somewhere. If that's done with PNP0C02 or similar devices (as is done
>> > on my x86 laptop), we'd be all set.
>>
>> I am not sure I understand what you mean here. Are you referring
>> to MCFG regions reported as PNP0c02 resources through its _CRS ?
>
> Yes. PCI Firmware Spec r3.0, Table 4-2, note 2 says address ranges
> reported via MCFG or _CBA should be reserved by _CRS of a PNP0C02
> device.
>
>> IIUC PNP0C02 is a reservation mechanism, but it does not help us
>> associate its _CRS to a specific PCI host bridge instance, right ?
>
> Gab proposed a hierarchy that *would* associate a PNP0C02 device with
> a PCI bridge:
>
> Device (PCI1) {
> Name (_HID, "HISI0080") // PCI Express Root Bridge
> Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
> Method (_CRS, 0, Serialized) { // Root complex resources (windows) }
> Device (RES0) {
> Name (_HID, "HISI0081") // HiSi PCIe RC config base address
> Name (_CID, "PNP0C02") // Motherboard reserved resource
> Name (_CRS, ResourceTemplate () { ... }
> }
> }
>
> That's a possibility. The PCI Firmware Spec suggests putting RES0 at
> the root (under \_SB), but I don't know why.
>
> Putting it at the root means we couldn't generically associate it with
> a bridge, although I could imagine something like this:
>
> Device (RES1) {
> Name (_HID, "HISI0081") // HiSi PCIe RC config base address
> Name (_CID, "PNP0C02") // Motherboard reserved resource
> Name (_CRS, ResourceTemplate () { ... }
> Method (BRDG) { "PCI1" } // hand-wavy ASL
> }
> Device (PCI1) {
> Name (_HID, "HISI0080") // PCI Express Root Bridge
> Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
> Method (_CRS, 0, Serialized) { // Root complex resources (windows) }
> }
>
> Where you could search PNP0C02 devices for a cookie that matched the
> host bridge.
>
>> > If we need to work around firmware in the field that doesn't do that,
>> > one possibility is a PNP quirk along the lines of
>> > quirk_amd_mmconfig_area().
>>
>> You mean matching PNP0C01/PNP0c02 and create a resource (that has to
>> hardcoded in a static array in the kernel anyway, there is no way to
>> retrieve it otherwise) in the corresponding PNP quirk handler ?
>
> Right. On some hardware we can read the resource out of a
> device-specific register, as we do in quirk_intel_mch(). But if
> that's not possible, it would have to be hard-coded.
>
>> And it is not a given we can match against PNP0c01/PNP0c02.
>>
>> So it looks like the only solution is allocating an _HID for each
>> host bridge that is not ECAM compliant to add resources to its _CRS
>> (unless the MCFG quirk does not need any additional data/resource,
>> eg "use different set of PCI accessorsi 32-bit vs byte-access").
>
> It doesn't matter whether it's ECAM-compliant or not. Any
> memory-mapped config space should be reported via some device's _CRS.
>
> The existing x86 practice is to use PNP0C02 devices for this purpose,
> and I think we should just follow that practice.
>
>> For FW that is immutable I really do not see what we can do apart
>> from hardcoding the non-config resources (consumed by a bridge),
>> somehow.
>
> Right. Well, I assume you mean we should hard-code "non-window
> resources consumed directly by a bridge". If firmware in the field is
> broken, we should work around it, and that may mean hard-coding some
> resources.
>
> My point is that the hard-coding should not be buried in a driver
> where it's invisible to the rest of the kernel. If we hard-code it in
> a quirk that adds _CRS entries, then the kernel will work just like it
> would if the firmware had been correct in the first place. The
> resource will appear in /sys/devices/pnp*/*/resources and /proc/iomem,
> and if we ever used _SRS to assign or move ACPI devices, we would know
> to avoid the bridge resource.
Hi Bjorn,
Are you suggesting to add code similar to functions in
linux/drivers/pnp/quirks.c to declare/attach the additional resource
that the host need to have when the resource is not in MCFG table?
>
> Bjorn
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH] clk: mediatek: clk-mt8173: Unmap region obtained by of_iomap
From: Stephen Boyd @ 2016-09-21 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474360242-15126-1-git-send-email-arvind.yadav.cs@gmail.com>
On 09/20, Arvind Yadav wrote:
> From: Arvind Yadav <arvind.yadav.cs@gmail.com>
>
> Free memory mapping, if init is not successful.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 2/6] Documentation: dt-bindings: Add documentation for the Meson USB2 PHYs
From: Kevin Hilman @ 2016-09-21 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920142944.GA16016@rob-hp-laptop>
Rob Herring <robh@kernel.org> writes:
> On Sun, Sep 11, 2016 at 03:41:07PM +0200, Martin Blumenstingl wrote:
>> Add the documentation for the bindings for the Meson8b and GXBB USB2
>> PHYs.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> .../devicetree/bindings/phy/meson-usb2-phy.txt | 27 ++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
>>
>> diff --git a/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
>> new file mode 100644
>> index 0000000..9da5ea2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
>> @@ -0,0 +1,27 @@
>> +* Amlogic USB2 PHY
>> +
>> +Required properties:
>> +- compatible: Depending on the platform this should be one of:
>> + "amlogic,meson8b-usb2-phy"
>> + "amlogic,meson-gxbb-usb2-phy"
>> +- reg: The base address and length of the registers
>> +- #phys-cells: should be 0 (see phy-bindings.txt in this directory)
>> +- clocks: phandle and clock identifier for the phy clocks
>> +- clock-names: "usb_general" and "usb"
>> +
>> +Optional properties:
>> +- resets: reference to the reset controller
>> +- phy-supply: see phy-bindings.txt in this directory
>> +
>> +
>> +Example:
>> +
>> +usb0_phy: usb_phy at 0 {
>
> usb-phy at 0
>
> With that,
>
> Acked-by: Rob Herring <robh@kernel.org>
>
Oops, I had already merged this one.
Martin, can you send a fixup patch for the underscores?
Thanks,
Kevin
^ permalink raw reply
* [PATCH v2] drivers: psci: PSCI checker module
From: Kevin Hilman @ 2016-09-21 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921143905.36197-1-kevin.brodsky@arm.com>
Kevin Brodsky <kevin.brodsky@arm.com> writes:
> On arm and arm64, PSCI is one of the possible firmware interfaces
> used for power management. This includes both turning CPUs on and off,
> and suspending them (entering idle states).
>
> This patch adds a PSCI checker module that enables basic testing of
> PSCI operations during startup. There are two main tests: CPU
> hotplugging and suspending.
>
> In the hotplug tests, the hotplug API is used to turn off and on again
> all CPUs in the system, and then all CPUs in each cluster, checking
> the consistency of the return codes.
>
> In the suspend tests, a high-priority thread is created on each core
> and uses low-level cpuidle functionalities to enter suspend, in all
> the possible states and multiple times. This should allow a maximum
> number of CPUs to enter the same sleep state at the same or slightly
> different time.
Since you're doing it multiple times, it might be useful to track the
actual time it takes to suspend and wakeup, and possibly even warn
if the time is longer than the target_residency. This could catch
poorly configured idle states.
Kevin
^ permalink raw reply
* [PATCH 3/3] regulator: axp20x: simplify device access
From: Jean-Francois Moine @ 2016-09-21 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1474616699.git.moinejf@free.fr>
Use the pointer to the main regulator device instead of the pointer
to the child platform device.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
---
drivers/regulator/axp20x-regulator.c | 45 ++++++++++++++++++------------------
1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 7405f5b..244ddc3 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -347,9 +347,9 @@ static const struct regulator_desc axp809_regulators[] = {
AXP_DESC_SW(AXP809, SW, "sw", "swin", AXP22X_PWR_OUT_CTRL2, BIT(6)),
};
-static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
+static int axp20x_set_dcdc_freq(struct device *dev, u32 dcdcfreq)
{
- struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+ struct axp20x_dev *axp20x = dev_get_drvdata(dev);
unsigned int reg = AXP20X_DCDC_FREQ;
u32 min, max, def, step;
@@ -378,7 +378,7 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
step = 150;
break;
default:
- dev_err(&pdev->dev,
+ dev_err(dev,
"Setting DCDC frequency for unsupported AXP variant\n");
return -EINVAL;
}
@@ -388,13 +388,13 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
if (dcdcfreq < min) {
dcdcfreq = min;
- dev_warn(&pdev->dev, "DCDC frequency too low. Set to %ukHz\n",
+ dev_warn(dev, "DCDC frequency too low. Set to %ukHz\n",
min);
}
if (dcdcfreq > max) {
dcdcfreq = max;
- dev_warn(&pdev->dev, "DCDC frequency too high. Set to %ukHz\n",
+ dev_warn(dev, "DCDC frequency too high. Set to %ukHz\n",
max);
}
@@ -404,24 +404,24 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
AXP20X_FREQ_DCDC_MASK, dcdcfreq);
}
-static int axp20x_regulator_parse_dt(struct platform_device *pdev)
+static int axp20x_regulator_parse_dt(struct device *dev)
{
struct device_node *np, *regulators;
int ret;
u32 dcdcfreq = 0;
- np = of_node_get(pdev->dev.parent->of_node);
+ np = of_node_get(dev->of_node);
if (!np)
return 0;
regulators = of_get_child_by_name(np, "regulators");
if (!regulators) {
- dev_warn(&pdev->dev, "regulators node not found\n");
+ dev_warn(dev, "regulators node not found\n");
} else {
of_property_read_u32(regulators, "x-powers,dcdc-freq", &dcdcfreq);
- ret = axp20x_set_dcdc_freq(pdev, dcdcfreq);
+ ret = axp20x_set_dcdc_freq(dev, dcdcfreq);
if (ret < 0) {
- dev_err(&pdev->dev, "Error setting dcdc frequency: %d\n", ret);
+ dev_err(dev, "Error setting dcdc frequency: %d\n", ret);
return ret;
}
@@ -499,11 +499,12 @@ static u32 axp20x_polyphase_slave(struct axp20x_dev *axp20x)
static int axp20x_regulator_probe(struct platform_device *pdev)
{
+ struct device *dev = pdev->dev.parent;
struct regulator_dev *rdev;
- struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+ struct axp20x_dev *axp20x = dev_get_drvdata(dev);
const struct regulator_desc *regulators;
struct regulator_config config = {
- .dev = pdev->dev.parent,
+ .dev = dev,
.regmap = axp20x->regmap,
.driver_data = axp20x,
};
@@ -532,7 +533,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
dcdc5_ix = AXP22X_DCDC5;
dc1sw_ix = AXP22X_DC1SW;
dc5ldo_ix = AXP22X_DC5LDO;
- drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
+ drivevbus = of_property_read_bool(dev->of_node,
"x-powers,drive-vbus-en");
break;
case AXP806_ID:
@@ -555,13 +556,13 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
dc5ldo_ix = AXP809_DC5LDO;
break;
default:
- dev_err(&pdev->dev, "Unsupported AXP variant: %ld\n",
+ dev_err(dev, "Unsupported AXP variant: %ld\n",
axp20x->variant);
return -EINVAL;
}
/* This only sets the dcdc freq. Ignore any errors */
- axp20x_regulator_parse_dt(pdev);
+ axp20x_regulator_parse_dt(dev);
for (i = 0; i < nregulators; i++) {
const struct regulator_desc *desc = ®ulators[i];
@@ -580,7 +581,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
* name.
*/
if (i == dc1sw_ix && dcdc1_name) {
- new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
+ new_desc = devm_kzalloc(dev, sizeof(*desc),
GFP_KERNEL);
*new_desc = regulators[i];
new_desc->supply_name = dcdc1_name;
@@ -588,16 +589,16 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
}
if (i == dc5ldo_ix && dcdc5_name) {
- new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
+ new_desc = devm_kzalloc(dev, sizeof(*desc),
GFP_KERNEL);
*new_desc = regulators[i];
new_desc->supply_name = dcdc5_name;
desc = new_desc;
}
- rdev = devm_regulator_register(&pdev->dev, desc, &config);
+ rdev = devm_regulator_register(dev, desc, &config);
if (IS_ERR(rdev)) {
- dev_err(&pdev->dev, "Failed to register %s\n",
+ dev_err(dev, "Failed to register %s\n",
regulators[i].name);
return PTR_ERR(rdev);
@@ -608,7 +609,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
&workmode);
if (!ret) {
if (axp20x_set_dcdc_workmode(rdev, i, workmode))
- dev_err(&pdev->dev, "Failed to set workmode on %s\n",
+ dev_err(dev, "Failed to set workmode on %s\n",
rdev->desc->name);
}
@@ -630,11 +631,11 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
/* Change N_VBUSEN sense pin to DRIVEVBUS output pin */
regmap_update_bits(axp20x->regmap, AXP20X_OVER_TMP,
AXP22X_MISC_N_VBUSEN_FUNC, 0);
- rdev = devm_regulator_register(&pdev->dev,
+ rdev = devm_regulator_register(dev,
&axp22x_drivevbus_regulator,
&config);
if (IS_ERR(rdev)) {
- dev_err(&pdev->dev, "Failed to register drivevbus\n");
+ dev_err(dev, "Failed to register drivevbus\n");
return PTR_ERR(rdev);
}
}
--
2.10.0
^ permalink raw reply related
* ftrace function_graph causes system crash
From: Steven Rostedt @ 2016-09-21 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921171307.3fb84c87@xhacker>
On Wed, 21 Sep 2016 17:13:07 +0800
Jisheng Zhang <jszhang@marvell.com> wrote:
> I'm not sure whether the commit d6df3576e6b4 ("clocksource/drivers/arm_global_timer
> : Prevent ftrace recursion") can fix this issue.
>
> this commit is merged since v4.3, I noticed your kernel version is v4.0
BTW, yes, that would be the fix.
-- Steve
>
> Thanks,
> Jisheng
>
> > Do you know now how to deeply debug and trace which line is wrong through Ftrace?
> >
^ permalink raw reply
* [PATCH v6 1/3] kexec: Add common device tree routines
From: Geoff Levand @ 2016-09-21 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1474481332.git.geoff@infradead.org>
Common device tree routines that can be shared between all arches
that have device tree support.
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
kexec/Makefile | 4 ++
kexec/dt-ops.c | 145 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
kexec/dt-ops.h | 13 ++++++
3 files changed, 162 insertions(+)
create mode 100644 kexec/dt-ops.c
create mode 100644 kexec/dt-ops.h
diff --git a/kexec/Makefile b/kexec/Makefile
index e2aee84..cc3f08b 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -73,6 +73,10 @@ dist += kexec/mem_regions.c kexec/mem_regions.h
$(ARCH)_MEM_REGIONS =
KEXEC_SRCS += $($(ARCH)_MEM_REGIONS)
+dist += kexec/dt-ops.c kexec/dt-ops.h
+$(ARCH)_DT_OPS =
+KEXEC_SRCS += $($(ARCH)_DT_OPS)
+
include $(srcdir)/kexec/arch/alpha/Makefile
include $(srcdir)/kexec/arch/arm/Makefile
include $(srcdir)/kexec/arch/i386/Makefile
diff --git a/kexec/dt-ops.c b/kexec/dt-ops.c
new file mode 100644
index 0000000..915dbf5
--- /dev/null
+++ b/kexec/dt-ops.c
@@ -0,0 +1,145 @@
+#include <assert.h>
+#include <errno.h>
+#include <inttypes.h>
+#include <libfdt.h>
+#include <stdio.h>
+#include <stdlib.h>
+
+#include "kexec.h"
+#include "dt-ops.h"
+
+static const char n_chosen[] = "/chosen";
+
+static const char p_bootargs[] = "bootargs";
+static const char p_initrd_start[] = "linux,initrd-start";
+static const char p_initrd_end[] = "linux,initrd-end";
+
+int dtb_set_initrd(char **dtb, off_t *dtb_size, off_t start, off_t end)
+{
+ int result;
+ uint64_t value;
+
+ dbgprintf("%s: start %jd, end %jd, size %jd (%jd KiB)\n",
+ __func__, (intmax_t)start, (intmax_t)end,
+ (intmax_t)(end - start),
+ (intmax_t)(end - start) / 1024);
+
+ value = cpu_to_fdt64(start);
+
+ result = dtb_set_property(dtb, dtb_size, n_chosen, p_initrd_start,
+ &value, sizeof(value));
+
+ if (result)
+ return result;
+
+ value = cpu_to_fdt64(end);
+
+ result = dtb_set_property(dtb, dtb_size, n_chosen, p_initrd_end,
+ &value, sizeof(value));
+
+ if (result) {
+ dtb_delete_property(*dtb, n_chosen, p_initrd_start);
+ return result;
+ }
+
+ return 0;
+}
+
+int dtb_set_bootargs(char **dtb, off_t *dtb_size, const char *command_line)
+{
+ return dtb_set_property(dtb, dtb_size, n_chosen, p_bootargs,
+ command_line, strlen(command_line) + 1);
+}
+
+int dtb_set_property(char **dtb, off_t *dtb_size, const char *node,
+ const char *prop, const void *value, int value_len)
+{
+ int result;
+ int nodeoffset;
+ void *new_dtb;
+ int new_size;
+
+ value_len = FDT_TAGALIGN(value_len);
+
+ new_size = FDT_TAGALIGN(*dtb_size + fdt_node_len(node)
+ + fdt_prop_len(prop, value_len));
+
+ new_dtb = malloc(new_size);
+
+ if (!new_dtb) {
+ dbgprintf("%s: malloc failed\n", __func__);
+ return -ENOMEM;
+ }
+
+ result = fdt_open_into(*dtb, new_dtb, new_size);
+
+ if (result) {
+ dbgprintf("%s: fdt_open_into failed: %s\n", __func__,
+ fdt_strerror(result));
+ goto on_error;
+ }
+
+ nodeoffset = fdt_path_offset(new_dtb, node);
+
+ if (nodeoffset == -FDT_ERR_NOTFOUND) {
+ result = fdt_add_subnode(new_dtb, nodeoffset, node);
+
+ if (result) {
+ dbgprintf("%s: fdt_add_subnode failed: %s\n", __func__,
+ fdt_strerror(result));
+ goto on_error;
+ }
+ } else if (nodeoffset < 0) {
+ dbgprintf("%s: fdt_path_offset failed: %s\n", __func__,
+ fdt_strerror(nodeoffset));
+ goto on_error;
+ }
+
+ result = fdt_setprop(new_dtb, nodeoffset, prop, value, value_len);
+
+ if (result) {
+ dbgprintf("%s: fdt_setprop failed: %s\n", __func__,
+ fdt_strerror(result));
+ goto on_error;
+ }
+
+ /*
+ * Can't call free on dtb since dtb may have been mmaped by
+ * slurp_file().
+ */
+
+ result = fdt_pack(new_dtb);
+
+ if (result)
+ dbgprintf("%s: Unable to pack device tree: %s\n", __func__,
+ fdt_strerror(result));
+
+ *dtb = new_dtb;
+ *dtb_size = fdt_totalsize(*dtb);
+
+ return 0;
+
+on_error:
+ free(new_dtb);
+ return result;
+}
+
+int dtb_delete_property(char *dtb, const char *node, const char *prop)
+{
+ int result;
+ int nodeoffset = fdt_path_offset(dtb, node);
+
+ if (nodeoffset < 0) {
+ dbgprintf("%s: fdt_path_offset failed: %s\n", __func__,
+ fdt_strerror(nodeoffset));
+ return nodeoffset;
+ }
+
+ result = fdt_delprop(dtb, nodeoffset, prop);
+
+ if (result)
+ dbgprintf("%s: fdt_delprop failed: %s\n", __func__,
+ fdt_strerror(nodeoffset));
+
+ return result;
+}
diff --git a/kexec/dt-ops.h b/kexec/dt-ops.h
new file mode 100644
index 0000000..e70d15d
--- /dev/null
+++ b/kexec/dt-ops.h
@@ -0,0 +1,13 @@
+#if !defined(KEXEC_DT_OPS_H)
+#define KEXEC_DT_OPS_H
+
+#include <sys/types.h>
+
+int dtb_set_initrd(char **dtb, off_t *dtb_size, off_t start, off_t end);
+int dtb_set_bootargs(char **dtb, off_t *dtb_size, const char *command_line);
+int dtb_set_property(char **dtb, off_t *dtb_size, const char *node,
+ const char *prop, const void *value, int value_len);
+
+int dtb_delete_property(char *dtb, const char *node, const char *prop);
+
+#endif
--
2.7.4
^ permalink raw reply related
* [PATCH v6 2/3] arm64: Add arm64 kexec support
From: Geoff Levand @ 2016-09-21 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1474481332.git.geoff@infradead.org>
Add kexec reboot support for ARM64 platforms.
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
configure.ac | 3 +
kexec/Makefile | 1 +
kexec/arch/arm64/Makefile | 40 +++
kexec/arch/arm64/crashdump-arm64.c | 21 ++
kexec/arch/arm64/crashdump-arm64.h | 12 +
| 146 ++++++++
kexec/arch/arm64/include/arch/options.h | 39 ++
kexec/arch/arm64/kexec-arm64.c | 615 ++++++++++++++++++++++++++++++++
kexec/arch/arm64/kexec-arm64.h | 71 ++++
kexec/arch/arm64/kexec-elf-arm64.c | 146 ++++++++
kexec/arch/arm64/kexec-image-arm64.c | 41 +++
kexec/kexec-syscall.h | 8 +-
purgatory/Makefile | 1 +
purgatory/arch/arm64/Makefile | 18 +
purgatory/arch/arm64/entry.S | 51 +++
purgatory/arch/arm64/purgatory-arm64.c | 19 +
16 files changed, 1230 insertions(+), 2 deletions(-)
create mode 100644 kexec/arch/arm64/Makefile
create mode 100644 kexec/arch/arm64/crashdump-arm64.c
create mode 100644 kexec/arch/arm64/crashdump-arm64.h
create mode 100644 kexec/arch/arm64/image-header.h
create mode 100644 kexec/arch/arm64/include/arch/options.h
create mode 100644 kexec/arch/arm64/kexec-arm64.c
create mode 100644 kexec/arch/arm64/kexec-arm64.h
create mode 100644 kexec/arch/arm64/kexec-elf-arm64.c
create mode 100644 kexec/arch/arm64/kexec-image-arm64.c
create mode 100644 purgatory/arch/arm64/Makefile
create mode 100644 purgatory/arch/arm64/entry.S
create mode 100644 purgatory/arch/arm64/purgatory-arm64.c
diff --git a/configure.ac b/configure.ac
index 736da6e..ba89075 100644
--- a/configure.ac
+++ b/configure.ac
@@ -34,6 +34,9 @@ case $target_cpu in
ARCH="ppc64"
SUBARCH="LE"
;;
+ aarch64* )
+ ARCH="arm64"
+ ;;
arm* )
ARCH="arm"
;;
diff --git a/kexec/Makefile b/kexec/Makefile
index cc3f08b..39f365f 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -79,6 +79,7 @@ KEXEC_SRCS += $($(ARCH)_DT_OPS)
include $(srcdir)/kexec/arch/alpha/Makefile
include $(srcdir)/kexec/arch/arm/Makefile
+include $(srcdir)/kexec/arch/arm64/Makefile
include $(srcdir)/kexec/arch/i386/Makefile
include $(srcdir)/kexec/arch/ia64/Makefile
include $(srcdir)/kexec/arch/m68k/Makefile
diff --git a/kexec/arch/arm64/Makefile b/kexec/arch/arm64/Makefile
new file mode 100644
index 0000000..37414dc
--- /dev/null
+++ b/kexec/arch/arm64/Makefile
@@ -0,0 +1,40 @@
+
+arm64_FS2DT += kexec/fs2dt.c
+arm64_FS2DT_INCLUDE += -include $(srcdir)/kexec/arch/arm64/kexec-arm64.h \
+ -include $(srcdir)/kexec/arch/arm64/crashdump-arm64.h
+
+arm64_DT_OPS += kexec/dt-ops.c
+
+arm64_CPPFLAGS += -I $(srcdir)/kexec/
+
+arm64_KEXEC_SRCS += \
+ kexec/arch/arm64/kexec-arm64.c \
+ kexec/arch/arm64/kexec-image-arm64.c \
+ kexec/arch/arm64/kexec-elf-arm64.c \
+ kexec/arch/arm64/crashdump-arm64.c
+
+arm64_ARCH_REUSE_INITRD =
+arm64_ADD_SEGMENT =
+arm64_VIRT_TO_PHYS =
+arm64_PHYS_TO_VIRT =
+
+dist += $(arm64_KEXEC_SRCS) \
+ kexec/arch/arm64/Makefile \
+ kexec/arch/arm64/kexec-arm64.h \
+ kexec/arch/arm64/crashdump-arm64.h
+
+ifdef HAVE_LIBFDT
+
+LIBS += -lfdt
+
+else
+
+include $(srcdir)/kexec/libfdt/Makefile.libfdt
+
+libfdt_SRCS += $(LIBFDT_SRCS:%=kexec/libfdt/%)
+
+arm64_CPPFLAGS += -I$(srcdir)/kexec/libfdt
+
+arm64_KEXEC_SRCS += $(libfdt_SRCS)
+
+endif
diff --git a/kexec/arch/arm64/crashdump-arm64.c b/kexec/arch/arm64/crashdump-arm64.c
new file mode 100644
index 0000000..d2272c8
--- /dev/null
+++ b/kexec/arch/arm64/crashdump-arm64.c
@@ -0,0 +1,21 @@
+/*
+ * ARM64 crashdump.
+ */
+
+#define _GNU_SOURCE
+
+#include <errno.h>
+#include <linux/elf.h>
+
+#include "kexec.h"
+#include "crashdump.h"
+#include "crashdump-arm64.h"
+#include "kexec-arm64.h"
+#include "kexec-elf.h"
+
+struct memory_ranges usablemem_rgns = {};
+
+int is_crashkernel_mem_reserved(void)
+{
+ return 0;
+}
diff --git a/kexec/arch/arm64/crashdump-arm64.h b/kexec/arch/arm64/crashdump-arm64.h
new file mode 100644
index 0000000..f33c7a2
--- /dev/null
+++ b/kexec/arch/arm64/crashdump-arm64.h
@@ -0,0 +1,12 @@
+/*
+ * ARM64 crashdump.
+ */
+
+#if !defined(CRASHDUMP_ARM64_H)
+#define CRASHDUMP_ARM64_H
+
+#include "kexec.h"
+
+extern struct memory_ranges usablemem_rgns;
+
+#endif
--git a/kexec/arch/arm64/image-header.h b/kexec/arch/arm64/image-header.h
new file mode 100644
index 0000000..158d411
--- /dev/null
+++ b/kexec/arch/arm64/image-header.h
@@ -0,0 +1,146 @@
+/*
+ * ARM64 binary image header.
+ */
+
+#if !defined(__ARM64_IMAGE_HEADER_H)
+#define __ARM64_IMAGE_HEADER_H
+
+#include <endian.h>
+#include <stdint.h>
+
+/**
+ * struct arm64_image_header - arm64 kernel image header.
+ *
+ * @pe_sig: Optional PE format 'MZ' signature.
+ * @branch_code: Reserved for instructions to branch to stext.
+ * @text_offset: The image load offset in LSB byte order.
+ * @image_size: An estimated size of the memory image size in LSB byte order.
+ * @flags: Bit flags in LSB byte order:
+ * Bit 0: Image byte order: 1=MSB.
+ * Bit 1-2: Kernel page size: 1=4K, 2=16K, 3=64K.
+ * Bit 3: Image placement: 0=low.
+ * @reserved_1: Reserved.
+ * @magic: Magic number, "ARM\x64".
+ * @pe_header: Optional offset to a PE format header.
+ **/
+
+struct arm64_image_header {
+ uint8_t pe_sig[2];
+ uint16_t branch_code[3];
+ uint64_t text_offset;
+ uint64_t image_size;
+ uint64_t flags;
+ uint64_t reserved_1[3];
+ uint8_t magic[4];
+ uint32_t pe_header;
+};
+
+static const uint8_t arm64_image_magic[4] = {'A', 'R', 'M', 0x64U};
+static const uint8_t arm64_image_pe_sig[2] = {'M', 'Z'};
+static const uint64_t arm64_image_flag_be = (1UL << 0);
+static const uint64_t arm64_image_flag_page_size = (3UL << 1);
+static const uint64_t arm64_image_flag_placement = (1UL << 3);
+
+/**
+ * enum arm64_header_page_size
+ */
+
+enum arm64_header_page_size {
+ arm64_header_page_size_invalid = 0,
+ arm64_header_page_size_4k,
+ arm64_header_page_size_16k,
+ arm64_header_page_size_64k
+};
+
+/**
+ * arm64_header_check_magic - Helper to check the arm64 image header.
+ *
+ * Returns non-zero if header is OK.
+ */
+
+static inline int arm64_header_check_magic(const struct arm64_image_header *h)
+{
+ if (!h)
+ return 0;
+
+ return (h->magic[0] == arm64_image_magic[0]
+ && h->magic[1] == arm64_image_magic[1]
+ && h->magic[2] == arm64_image_magic[2]
+ && h->magic[3] == arm64_image_magic[3]);
+}
+
+/**
+ * arm64_header_check_pe_sig - Helper to check the arm64 image header.
+ *
+ * Returns non-zero if 'MZ' signature is found.
+ */
+
+static inline int arm64_header_check_pe_sig(const struct arm64_image_header *h)
+{
+ if (!h)
+ return 0;
+
+ return (h->pe_sig[0] == arm64_image_pe_sig[0]
+ && h->pe_sig[1] == arm64_image_pe_sig[1]);
+}
+
+/**
+ * arm64_header_check_msb - Helper to check the arm64 image header.
+ *
+ * Returns non-zero if the image was built as big endian.
+ */
+
+static inline int arm64_header_check_msb(const struct arm64_image_header *h)
+{
+ if (!h)
+ return 0;
+
+ return (le64toh(h->flags) & arm64_image_flag_be) >> 0;
+}
+
+/**
+ * arm64_header_page_size
+ */
+
+static inline enum arm64_header_page_size arm64_header_page_size(
+ const struct arm64_image_header *h)
+{
+ if (!h)
+ return 0;
+
+ return (le64toh(h->flags) & arm64_image_flag_page_size) >> 1;
+}
+
+/**
+ * arm64_header_placement
+ *
+ * Returns non-zero if the image has no physical placement restrictions.
+ */
+
+static inline int arm64_header_placement(const struct arm64_image_header *h)
+{
+ if (!h)
+ return 0;
+
+ return (le64toh(h->flags) & arm64_image_flag_placement) >> 3;
+}
+
+static inline uint64_t arm64_header_text_offset(
+ const struct arm64_image_header *h)
+{
+ if (!h)
+ return 0;
+
+ return le64toh(h->text_offset);
+}
+
+static inline uint64_t arm64_header_image_size(
+ const struct arm64_image_header *h)
+{
+ if (!h)
+ return 0;
+
+ return le64toh(h->image_size);
+}
+
+#endif
diff --git a/kexec/arch/arm64/include/arch/options.h b/kexec/arch/arm64/include/arch/options.h
new file mode 100644
index 0000000..a17d933
--- /dev/null
+++ b/kexec/arch/arm64/include/arch/options.h
@@ -0,0 +1,39 @@
+#if !defined(KEXEC_ARCH_ARM64_OPTIONS_H)
+#define KEXEC_ARCH_ARM64_OPTIONS_H
+
+#define OPT_APPEND ((OPT_MAX)+0)
+#define OPT_DTB ((OPT_MAX)+1)
+#define OPT_INITRD ((OPT_MAX)+2)
+#define OPT_REUSE_CMDLINE ((OPT_MAX)+3)
+#define OPT_ARCH_MAX ((OPT_MAX)+4)
+
+#define KEXEC_ARCH_OPTIONS \
+ KEXEC_OPTIONS \
+ { "append", 1, NULL, OPT_APPEND }, \
+ { "command-line", 1, NULL, OPT_APPEND }, \
+ { "dtb", 1, NULL, OPT_DTB }, \
+ { "initrd", 1, NULL, OPT_INITRD }, \
+ { "ramdisk", 1, NULL, OPT_INITRD }, \
+ { "reuse-cmdline", 0, NULL, OPT_REUSE_CMDLINE }, \
+
+#define KEXEC_ARCH_OPT_STR KEXEC_OPT_STR /* Only accept long arch options. */
+#define KEXEC_ALL_OPTIONS KEXEC_ARCH_OPTIONS
+#define KEXEC_ALL_OPT_STR KEXEC_ARCH_OPT_STR
+
+static const char arm64_opts_usage[] __attribute__ ((unused)) =
+" --append=STRING Set the kernel command line to STRING.\n"
+" --command-line=STRING Set the kernel command line to STRING.\n"
+" --dtb=FILE Use FILE as the device tree blob.\n"
+" --initrd=FILE Use FILE as the kernel initial ramdisk.\n"
+" --ramdisk=FILE Use FILE as the kernel initial ramdisk.\n"
+" --reuse-cmdline Use kernel command line from running system.\n";
+
+struct arm64_opts {
+ const char *command_line;
+ const char *dtb;
+ const char *initrd;
+};
+
+extern struct arm64_opts arm64_opts;
+
+#endif
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
new file mode 100644
index 0000000..2e8839a
--- /dev/null
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -0,0 +1,615 @@
+/*
+ * ARM64 kexec.
+ */
+
+#define _GNU_SOURCE
+
+#include <assert.h>
+#include <errno.h>
+#include <getopt.h>
+#include <inttypes.h>
+#include <libfdt.h>
+#include <limits.h>
+#include <stdlib.h>
+#include <sys/stat.h>
+#include <linux/elf-em.h>
+#include <elf.h>
+
+#include "kexec.h"
+#include "kexec-arm64.h"
+#include "crashdump.h"
+#include "crashdump-arm64.h"
+#include "dt-ops.h"
+#include "fs2dt.h"
+#include "kexec-syscall.h"
+#include "arch/options.h"
+
+/* Global varables the core kexec routines expect. */
+
+unsigned char reuse_initrd;
+
+off_t initrd_base;
+off_t initrd_size;
+
+const struct arch_map_entry arches[] = {
+ { "aarch64", KEXEC_ARCH_ARM64 },
+ { "aarch64_be", KEXEC_ARCH_ARM64 },
+ { NULL, 0 },
+};
+
+struct file_type file_type[] = {
+ {"vmlinux", elf_arm64_probe, elf_arm64_load, elf_arm64_usage},
+ {"Image", image_arm64_probe, image_arm64_load, image_arm64_usage},
+};
+
+int file_types = sizeof(file_type) / sizeof(file_type[0]);
+
+/* arm64 global varables. */
+
+struct arm64_opts arm64_opts;
+struct arm64_mem arm64_mem = {
+ .phys_offset = arm64_mem_ngv,
+ .vp_offset = arm64_mem_ngv,
+};
+
+uint64_t get_phys_offset(void)
+{
+ assert(arm64_mem.phys_offset != arm64_mem_ngv);
+ return arm64_mem.phys_offset;
+}
+
+uint64_t get_vp_offset(void)
+{
+ assert(arm64_mem.vp_offset != arm64_mem_ngv);
+ return arm64_mem.vp_offset;
+}
+
+/**
+ * arm64_process_image_header - Process the arm64 image header.
+ *
+ * Make a guess that KERNEL_IMAGE_SIZE will be enough for older kernels.
+ */
+
+int arm64_process_image_header(const struct arm64_image_header *h)
+{
+#if !defined(KERNEL_IMAGE_SIZE)
+# define KERNEL_IMAGE_SIZE MiB(16)
+#endif
+
+ if (!arm64_header_check_magic(h))
+ return -EFAILED;
+
+ if (h->image_size) {
+ arm64_mem.text_offset = arm64_header_text_offset(h);
+ arm64_mem.image_size = arm64_header_image_size(h);
+ } else {
+ /* For 3.16 and older kernels. */
+ arm64_mem.text_offset = 0x80000;
+ arm64_mem.image_size = KERNEL_IMAGE_SIZE;
+ fprintf(stderr,
+ "kexec: %s: Warning: Kernel image size set to %lu MiB.\n"
+ " Please verify compatability with lodaed kernel.\n",
+ __func__, KERNEL_IMAGE_SIZE / 1024UL / 1024UL);
+ }
+
+ return 0;
+}
+
+void arch_usage(void)
+{
+ printf(arm64_opts_usage);
+}
+
+int arch_process_options(int argc, char **argv)
+{
+ static const char short_options[] = KEXEC_OPT_STR "";
+ static const struct option options[] = {
+ KEXEC_ARCH_OPTIONS
+ { 0 }
+ };
+ int opt;
+ char *cmdline = NULL;
+ const char *append = NULL;
+
+ for (opt = 0; opt != -1; ) {
+ opt = getopt_long(argc, argv, short_options, options, 0);
+
+ switch (opt) {
+ case OPT_APPEND:
+ append = optarg;
+ break;
+ case OPT_REUSE_CMDLINE:
+ cmdline = get_command_line();
+ break;
+ case OPT_DTB:
+ arm64_opts.dtb = optarg;
+ break;
+ case OPT_INITRD:
+ arm64_opts.initrd = optarg;
+ break;
+ case OPT_PANIC:
+ die("load-panic (-p) not supported");
+ break;
+ default:
+ break; /* Ignore core and unknown options. */
+ }
+ }
+
+ arm64_opts.command_line = concat_cmdline(cmdline, append);
+
+ dbgprintf("%s:%d: command_line: %s\n", __func__, __LINE__,
+ arm64_opts.command_line);
+ dbgprintf("%s:%d: initrd: %s\n", __func__, __LINE__,
+ arm64_opts.initrd);
+ dbgprintf("%s:%d: dtb: %s\n", __func__, __LINE__, arm64_opts.dtb);
+
+ return 0;
+}
+
+/**
+ * struct dtb - Info about a binary device tree.
+ *
+ * @buf: Device tree data.
+ * @size: Device tree data size.
+ * @name: Shorthand name of this dtb for messages.
+ * @path: Filesystem path.
+ */
+
+struct dtb {
+ char *buf;
+ off_t size;
+ const char *name;
+ const char *path;
+};
+
+/**
+ * dump_reservemap - Dump the dtb's reservemap.
+ */
+
+static void dump_reservemap(const struct dtb *dtb)
+{
+ int i;
+
+ for (i = 0; ; i++) {
+ uint64_t address;
+ uint64_t size;
+
+ fdt_get_mem_rsv(dtb->buf, i, &address, &size);
+
+ if (!size)
+ break;
+
+ dbgprintf("%s: %s {%" PRIx64 ", %" PRIx64 "}\n", __func__,
+ dtb->name, address, size);
+ }
+}
+
+/**
+ * set_bootargs - Set the dtb's bootargs.
+ */
+
+static int set_bootargs(struct dtb *dtb, const char *command_line)
+{
+ int result;
+
+ if (!command_line || !command_line[0])
+ return 0;
+
+ result = dtb_set_bootargs(&dtb->buf, &dtb->size, command_line);
+
+ if (result) {
+ fprintf(stderr,
+ "kexec: Set device tree bootargs failed.\n");
+ return -EFAILED;
+ }
+
+ return 0;
+}
+
+/**
+ * read_proc_dtb - Read /proc/device-tree.
+ */
+
+static int read_proc_dtb(struct dtb *dtb)
+{
+ int result;
+ struct stat s;
+ static const char path[] = "/proc/device-tree";
+
+ result = stat(path, &s);
+
+ if (result) {
+ dbgprintf("%s: %s\n", __func__, strerror(errno));
+ return -EFAILED;
+ }
+
+ dtb->path = path;
+ create_flatten_tree((char **)&dtb->buf, &dtb->size, NULL);
+
+ return 0;
+}
+
+/**
+ * read_sys_dtb - Read /sys/firmware/fdt.
+ */
+
+static int read_sys_dtb(struct dtb *dtb)
+{
+ int result;
+ struct stat s;
+ static const char path[] = "/sys/firmware/fdt";
+
+ result = stat(path, &s);
+
+ if (result) {
+ dbgprintf("%s: %s\n", __func__, strerror(errno));
+ return -EFAILED;
+ }
+
+ dtb->path = path;
+ dtb->buf = slurp_file(path, &dtb->size);
+
+ return 0;
+}
+
+/**
+ * read_1st_dtb - Read the 1st stage kernel's dtb.
+ */
+
+static int read_1st_dtb(struct dtb *dtb)
+{
+ int result;
+
+ dtb->name = "dtb_sys";
+ result = read_sys_dtb(dtb);
+
+ if (!result)
+ goto on_success;
+
+ dtb->name = "dtb_proc";
+ result = read_proc_dtb(dtb);
+
+ if (!result)
+ goto on_success;
+
+ dbgprintf("%s: not found\n", __func__);
+ return -EFAILED;
+
+on_success:
+ dbgprintf("%s: found %s\n", __func__, dtb->path);
+ return 0;
+}
+
+/**
+ * setup_2nd_dtb - Setup the 2nd stage kernel's dtb.
+ */
+
+static int setup_2nd_dtb(struct dtb *dtb, char *command_line)
+{
+ int result;
+
+ result = fdt_check_header(dtb->buf);
+
+ if (result) {
+ fprintf(stderr, "kexec: Invalid 2nd device tree.\n");
+ return -EFAILED;
+ }
+
+ result = set_bootargs(dtb, command_line);
+
+ dump_reservemap(dtb);
+
+ return result;
+}
+
+unsigned long arm64_locate_kernel_segment(struct kexec_info *info)
+{
+ unsigned long hole;
+
+ hole = locate_hole(info,
+ arm64_mem.text_offset + arm64_mem.image_size,
+ MiB(2), 0, ULONG_MAX, 1);
+
+ if (hole == ULONG_MAX)
+ dbgprintf("%s: locate_hole failed\n", __func__);
+
+ return hole;
+}
+
+/**
+ * arm64_load_other_segments - Prepare the dtb, initrd and purgatory segments.
+ */
+
+int arm64_load_other_segments(struct kexec_info *info,
+ unsigned long image_base)
+{
+ int result;
+ unsigned long dtb_base;
+ unsigned long hole_min;
+ unsigned long hole_max;
+ char *initrd_buf = NULL;
+ struct dtb dtb;
+ char command_line[COMMAND_LINE_SIZE] = "";
+
+ if (arm64_opts.command_line) {
+ strncpy(command_line, arm64_opts.command_line,
+ sizeof(command_line));
+ command_line[sizeof(command_line) - 1] = 0;
+ }
+
+ if (arm64_opts.dtb) {
+ dtb.name = "dtb_user";
+ dtb.buf = slurp_file(arm64_opts.dtb, &dtb.size);
+ } else {
+ result = read_1st_dtb(&dtb);
+
+ if (result) {
+ fprintf(stderr,
+ "kexec: Error: No device tree available.\n");
+ return -EFAILED;
+ }
+ }
+
+ result = setup_2nd_dtb(&dtb, command_line);
+
+ if (result)
+ return -EFAILED;
+
+ /* Put the other segments after the image. */
+
+ hole_min = image_base + arm64_mem.image_size;
+ hole_max = ULONG_MAX;
+
+ if (arm64_opts.initrd) {
+ initrd_buf = slurp_file(arm64_opts.initrd, &initrd_size);
+
+ if (!initrd_buf)
+ fprintf(stderr, "kexec: Empty ramdisk file.\n");
+ else {
+ /*
+ * Put the initrd after the kernel. As specified in
+ * booting.txt, align to 1 GiB.
+ */
+
+ initrd_base = add_buffer_phys_virt(info, initrd_buf,
+ initrd_size, initrd_size, GiB(1),
+ hole_min, hole_max, 1, 0);
+
+ /* initrd_base is valid if we got here. */
+
+ dbgprintf("initrd: base %lx, size %lxh (%ld)\n",
+ initrd_base, initrd_size, initrd_size);
+
+ /* Check size limit as specified in booting.txt. */
+
+ if (initrd_base - image_base + initrd_size > GiB(32)) {
+ fprintf(stderr, "kexec: Error: image + initrd too big.\n");
+ return -EFAILED;
+ }
+
+ result = dtb_set_initrd((char **)&dtb.buf,
+ &dtb.size, initrd_base,
+ initrd_base + initrd_size);
+
+ if (result)
+ return -EFAILED;
+ }
+ }
+
+ /* Check size limit as specified in booting.txt. */
+
+ if (dtb.size > MiB(2)) {
+ fprintf(stderr, "kexec: Error: dtb too big.\n");
+ return -EFAILED;
+ }
+
+ dtb_base = add_buffer_phys_virt(info, dtb.buf, dtb.size, dtb.size,
+ 0, hole_min, hole_max, 1, 0);
+
+ /* dtb_base is valid if we got here. */
+
+ dbgprintf("dtb: base %lx, size %lxh (%ld)\n", dtb_base, dtb.size,
+ dtb.size);
+
+ elf_rel_build_load(info, &info->rhdr, purgatory, purgatory_size,
+ hole_min, hole_max, 1, 0);
+
+ info->entry = (void *)elf_rel_get_addr(&info->rhdr, "purgatory_start");
+
+ elf_rel_set_symbol(&info->rhdr, "arm64_kernel_entry", &image_base,
+ sizeof(image_base));
+
+ elf_rel_set_symbol(&info->rhdr, "arm64_dtb_addr", &dtb_base,
+ sizeof(dtb_base));
+
+ return 0;
+}
+
+/**
+ * virt_to_phys - For processing elf file values.
+ */
+
+unsigned long virt_to_phys(unsigned long v)
+{
+ unsigned long p;
+
+ p = v - get_vp_offset() + get_phys_offset();
+
+ return p;
+}
+
+/**
+ * phys_to_virt - For crashdump setup.
+ */
+
+unsigned long phys_to_virt(struct crash_elf_info *elf_info,
+ unsigned long long p)
+{
+ unsigned long v;
+
+ v = p - get_phys_offset() + elf_info->page_offset;
+
+ return v;
+}
+
+/**
+ * add_segment - Use virt_to_phys when loading elf files.
+ */
+
+void add_segment(struct kexec_info *info, const void *buf, size_t bufsz,
+ unsigned long base, size_t memsz)
+{
+ add_segment_phys_virt(info, buf, bufsz, base, memsz, 1);
+}
+
+/**
+ * get_memory_ranges_iomem_cb - Helper for get_memory_ranges_iomem.
+ */
+
+static int get_memory_ranges_iomem_cb(void *data, int nr, char *str,
+ unsigned long long base, unsigned long long length)
+{
+ struct memory_range *r;
+
+ if (nr >= KEXEC_SEGMENT_MAX)
+ return -1;
+
+ r = (struct memory_range *)data + nr;
+ r->type = RANGE_RAM;
+ r->start = base;
+ r->end = base + length - 1;
+
+ set_phys_offset(r->start);
+
+ dbgprintf("%s: %016llx - %016llx : %s", __func__, r->start,
+ r->end, str);
+
+ return 0;
+}
+
+/**
+ * get_memory_ranges_iomem - Try to get the memory ranges from /proc/iomem.
+ */
+
+static int get_memory_ranges_iomem(struct memory_range *array,
+ unsigned int *count)
+{
+ *count = kexec_iomem_for_each_line("System RAM\n",
+ get_memory_ranges_iomem_cb, array);
+
+ if (!*count) {
+ dbgprintf("%s: failed: No RAM found.\n", __func__);
+ return -EFAILED;
+ }
+
+ return 0;
+}
+
+/**
+ * get_memory_ranges - Try to get the memory ranges some how.
+ */
+
+int get_memory_ranges(struct memory_range **range, int *ranges,
+ unsigned long kexec_flags)
+{
+ static struct memory_range array[KEXEC_SEGMENT_MAX];
+ unsigned int count;
+ int result;
+
+ result = get_memory_ranges_iomem(array, &count);
+
+ *range = result ? NULL : array;
+ *ranges = result ? 0 : count;
+
+ return result;
+}
+
+int arch_compat_trampoline(struct kexec_info *info)
+{
+ return 0;
+}
+
+int machine_verify_elf_rel(struct mem_ehdr *ehdr)
+{
+ return (ehdr->e_machine == EM_AARCH64);
+}
+
+void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
+ unsigned long r_type, void *ptr, unsigned long address,
+ unsigned long value)
+{
+#if !defined(R_AARCH64_ABS64)
+# define R_AARCH64_ABS64 257
+#endif
+
+#if !defined(R_AARCH64_LD_PREL_LO19)
+# define R_AARCH64_LD_PREL_LO19 273
+#endif
+
+#if !defined(R_AARCH64_ADR_PREL_LO21)
+# define R_AARCH64_ADR_PREL_LO21 274
+#endif
+
+#if !defined(R_AARCH64_JUMP26)
+# define R_AARCH64_JUMP26 282
+#endif
+
+#if !defined(R_AARCH64_CALL26)
+# define R_AARCH64_CALL26 283
+#endif
+
+ uint64_t *loc64;
+ uint32_t *loc32;
+ uint64_t *location = (uint64_t *)ptr;
+ uint64_t data = *location;
+ const char *type = NULL;
+
+ switch(r_type) {
+ case R_AARCH64_ABS64:
+ type = "ABS64";
+ loc64 = ptr;
+ *loc64 = cpu_to_elf64(ehdr, elf64_to_cpu(ehdr, *loc64) + value);
+ break;
+ case R_AARCH64_LD_PREL_LO19:
+ type = "LD_PREL_LO19";
+ loc32 = ptr;
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + (((value - address) << 3) & 0xffffe0));
+ break;
+ case R_AARCH64_ADR_PREL_LO21:
+ if (value & 3)
+ die("%s: ERROR Unaligned value: %lx\n", __func__,
+ value);
+ type = "ADR_PREL_LO21";
+ loc32 = ptr;
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + (((value - address) << 3) & 0xffffe0));
+ break;
+ case R_AARCH64_JUMP26:
+ type = "JUMP26";
+ loc32 = ptr;
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + (((value - address) >> 2) & 0x3ffffff));
+ break;
+ case R_AARCH64_CALL26:
+ type = "CALL26";
+ loc32 = ptr;
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + (((value - address) >> 2) & 0x3ffffff));
+ break;
+ default:
+ die("%s: ERROR Unknown type: %lu\n", __func__, r_type);
+ break;
+ }
+
+ dbgprintf("%s: %s %016lx->%016lx\n", __func__, type, data, *location);
+}
+
+void arch_reuse_initrd(void)
+{
+ reuse_initrd = 1;
+}
+
+void arch_update_purgatory(struct kexec_info *UNUSED(info))
+{
+}
diff --git a/kexec/arch/arm64/kexec-arm64.h b/kexec/arch/arm64/kexec-arm64.h
new file mode 100644
index 0000000..bac62f8
--- /dev/null
+++ b/kexec/arch/arm64/kexec-arm64.h
@@ -0,0 +1,71 @@
+/*
+ * ARM64 kexec.
+ */
+
+#if !defined(KEXEC_ARM64_H)
+#define KEXEC_ARM64_H
+
+#include <stdbool.h>
+#include <sys/types.h>
+
+#include "image-header.h"
+#include "kexec.h"
+
+#define KEXEC_SEGMENT_MAX 16
+
+#define BOOT_BLOCK_VERSION 17
+#define BOOT_BLOCK_LAST_COMP_VERSION 16
+#define COMMAND_LINE_SIZE 512
+
+#define KiB(x) ((x) * 1024UL)
+#define MiB(x) (KiB(x) * 1024UL)
+#define GiB(x) (MiB(x) * 1024UL)
+
+int elf_arm64_probe(const char *kernel_buf, off_t kernel_size);
+int elf_arm64_load(int argc, char **argv, const char *kernel_buf,
+ off_t kernel_size, struct kexec_info *info);
+void elf_arm64_usage(void);
+
+int image_arm64_probe(const char *kernel_buf, off_t kernel_size);
+int image_arm64_load(int argc, char **argv, const char *kernel_buf,
+ off_t kernel_size, struct kexec_info *info);
+void image_arm64_usage(void);
+
+off_t initrd_base;
+off_t initrd_size;
+
+/**
+ * struct arm64_mem - Memory layout info.
+ */
+
+struct arm64_mem {
+ uint64_t phys_offset;
+ uint64_t text_offset;
+ uint64_t image_size;
+ uint64_t vp_offset;
+};
+
+#define arm64_mem_ngv UINT64_MAX
+struct arm64_mem arm64_mem;
+
+uint64_t get_phys_offset(void);
+uint64_t get_vp_offset(void);
+
+static inline void reset_vp_offset(void)
+{
+ arm64_mem.vp_offset = arm64_mem_ngv;
+}
+
+static inline void set_phys_offset(uint64_t v)
+{
+ if (arm64_mem.phys_offset == arm64_mem_ngv
+ || v < arm64_mem.phys_offset)
+ arm64_mem.phys_offset = v;
+}
+
+int arm64_process_image_header(const struct arm64_image_header *h);
+unsigned long arm64_locate_kernel_segment(struct kexec_info *info);
+int arm64_load_other_segments(struct kexec_info *info,
+ unsigned long image_base);
+
+#endif
diff --git a/kexec/arch/arm64/kexec-elf-arm64.c b/kexec/arch/arm64/kexec-elf-arm64.c
new file mode 100644
index 0000000..daf8bf0
--- /dev/null
+++ b/kexec/arch/arm64/kexec-elf-arm64.c
@@ -0,0 +1,146 @@
+/*
+ * ARM64 kexec elf support.
+ */
+
+#define _GNU_SOURCE
+
+#include <errno.h>
+#include <limits.h>
+#include <stdlib.h>
+#include <linux/elf.h>
+
+#include "kexec-arm64.h"
+#include "kexec-elf.h"
+#include "kexec-syscall.h"
+
+int elf_arm64_probe(const char *kernel_buf, off_t kernel_size)
+{
+ struct mem_ehdr ehdr;
+ int result;
+
+ result = build_elf_exec_info(kernel_buf, kernel_size, &ehdr, 0);
+
+ if (result < 0) {
+ dbgprintf("%s: Not an ELF executable.\n", __func__);
+ goto on_exit;
+ }
+
+ if (ehdr.e_machine != EM_AARCH64) {
+ dbgprintf("%s: Not an AARCH64 ELF executable.\n", __func__);
+ result = -1;
+ goto on_exit;
+ }
+
+ result = 0;
+on_exit:
+ free_elf_info(&ehdr);
+ return result;
+}
+
+int elf_arm64_load(int argc, char **argv, const char *kernel_buf,
+ off_t kernel_size, struct kexec_info *info)
+{
+ const struct arm64_image_header *header = NULL;
+ unsigned long kernel_segment;
+ struct mem_ehdr ehdr;
+ int result;
+ int i;
+
+ if (info->kexec_flags & KEXEC_ON_CRASH) {
+ fprintf(stderr, "kexec: kdump not yet supported on arm64\n");
+ return -EFAILED;
+ }
+
+ result = build_elf_exec_info(kernel_buf, kernel_size, &ehdr, 0);
+
+ if (result < 0) {
+ dbgprintf("%s: build_elf_exec_info failed\n", __func__);
+ goto exit;
+ }
+
+ /* Find and process the arm64 image header. */
+
+ for (i = 0; i < ehdr.e_phnum; i++) {
+ struct mem_phdr *phdr = &ehdr.e_phdr[i];
+ unsigned long header_offset;
+
+ if (phdr->p_type != PT_LOAD)
+ continue;
+
+ /*
+ * When CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET=y the image header
+ * could be offset in the elf segment. The linker script sets
+ * ehdr.e_entry to the start of text.
+ */
+
+ header_offset = ehdr.e_entry - phdr->p_vaddr;
+
+ header = (const struct arm64_image_header *)(
+ kernel_buf + phdr->p_offset + header_offset);
+
+ if (!arm64_process_image_header(header)) {
+ dbgprintf("%s: e_entry: %016llx\n", __func__,
+ ehdr.e_entry);
+ dbgprintf("%s: p_vaddr: %016llx\n", __func__,
+ phdr->p_vaddr);
+ dbgprintf("%s: header_offset: %016lx\n", __func__,
+ header_offset);
+
+ break;
+ }
+ }
+
+ if (i == ehdr.e_phnum) {
+ dbgprintf("%s: Valid arm64 header not found\n", __func__);
+ result = -EFAILED;
+ goto exit;
+ }
+
+ kernel_segment = arm64_locate_kernel_segment(info);
+
+ if (kernel_segment == ULONG_MAX) {
+ dbgprintf("%s: Kernel segment is not allocated\n", __func__);
+ result = -EFAILED;
+ goto exit;
+ }
+
+ arm64_mem.vp_offset = _ALIGN_DOWN(ehdr.e_entry, MiB(2));
+ arm64_mem.vp_offset -= kernel_segment - get_phys_offset();
+
+ dbgprintf("%s: kernel_segment: %016lx\n", __func__, kernel_segment);
+ dbgprintf("%s: text_offset: %016lx\n", __func__,
+ arm64_mem.text_offset);
+ dbgprintf("%s: image_size: %016lx\n", __func__,
+ arm64_mem.image_size);
+ dbgprintf("%s: phys_offset: %016lx\n", __func__,
+ arm64_mem.phys_offset);
+ dbgprintf("%s: vp_offset: %016lx\n", __func__,
+ arm64_mem.vp_offset);
+ dbgprintf("%s: PE format: %s\n", __func__,
+ (arm64_header_check_pe_sig(header) ? "yes" : "no"));
+
+ /* load the kernel */
+ result = elf_exec_load(&ehdr, info);
+
+ if (result) {
+ dbgprintf("%s: elf_exec_load failed\n", __func__);
+ goto exit;
+ }
+
+ result = arm64_load_other_segments(info, kernel_segment
+ + arm64_mem.text_offset);
+
+exit:
+ reset_vp_offset();
+ free_elf_info(&ehdr);
+ if (result)
+ fprintf(stderr, "kexec: Bad elf image file, load failed.\n");
+ return result;
+}
+
+void elf_arm64_usage(void)
+{
+ printf(
+" An ARM64 ELF image, big or little endian.\n"
+" Typically vmlinux or a stripped version of vmlinux.\n\n");
+}
diff --git a/kexec/arch/arm64/kexec-image-arm64.c b/kexec/arch/arm64/kexec-image-arm64.c
new file mode 100644
index 0000000..42d2ea7
--- /dev/null
+++ b/kexec/arch/arm64/kexec-image-arm64.c
@@ -0,0 +1,41 @@
+/*
+ * ARM64 kexec binary image support.
+ */
+
+#define _GNU_SOURCE
+#include "kexec-arm64.h"
+
+int image_arm64_probe(const char *kernel_buf, off_t kernel_size)
+{
+ const struct arm64_image_header *h;
+
+ if (kernel_size < sizeof(struct arm64_image_header)) {
+ dbgprintf("%s: No arm64 image header.\n", __func__);
+ return -1;
+ }
+
+ h = (const struct arm64_image_header *)(kernel_buf);
+
+ if (!arm64_header_check_magic(h)) {
+ dbgprintf("%s: Bad arm64 image header.\n", __func__);
+ return -1;
+ }
+
+ fprintf(stderr, "kexec: ARM64 binary image files are currently NOT SUPPORTED.\n");
+ return -1;
+}
+
+int image_arm64_load(int argc, char **argv, const char *kernel_buf,
+ off_t kernel_size, struct kexec_info *info)
+{
+ return -1;
+}
+
+void image_arm64_usage(void)
+{
+ printf(
+" An ARM64 binary image, compressed or not, big or little endian.\n"
+" Typically an Image, Image.gz or Image.lzma file.\n\n");
+ printf(
+" ARM64 binary image files are currently NOT SUPPORTED.\n\n");
+}
diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h
index ce2e20b..c0d0bea 100644
--- a/kexec/kexec-syscall.h
+++ b/kexec/kexec-syscall.h
@@ -39,8 +39,8 @@
#ifdef __s390__
#define __NR_kexec_load 277
#endif
-#ifdef __arm__
-#define __NR_kexec_load __NR_SYSCALL_BASE + 347
+#if defined(__arm__) || defined(__arm64__)
+#define __NR_kexec_load __NR_SYSCALL_BASE + 347
#endif
#if defined(__mips__)
#define __NR_kexec_load 4311
@@ -108,6 +108,7 @@ static inline long kexec_file_load(int kernel_fd, int initrd_fd,
#define KEXEC_ARCH_PPC64 (21 << 16)
#define KEXEC_ARCH_IA_64 (50 << 16)
#define KEXEC_ARCH_ARM (40 << 16)
+#define KEXEC_ARCH_ARM64 (183 << 16)
#define KEXEC_ARCH_S390 (22 << 16)
#define KEXEC_ARCH_SH (42 << 16)
#define KEXEC_ARCH_MIPS_LE (10 << 16)
@@ -153,5 +154,8 @@ static inline long kexec_file_load(int kernel_fd, int initrd_fd,
#ifdef __m68k__
#define KEXEC_ARCH_NATIVE KEXEC_ARCH_68K
#endif
+#if defined(__arm64__)
+#define KEXEC_ARCH_NATIVE KEXEC_ARCH_ARM64
+#endif
#endif /* KEXEC_SYSCALL_H */
diff --git a/purgatory/Makefile b/purgatory/Makefile
index 2b5c061..ca0443c 100644
--- a/purgatory/Makefile
+++ b/purgatory/Makefile
@@ -19,6 +19,7 @@ dist += purgatory/Makefile $(PURGATORY_SRCS) \
include $(srcdir)/purgatory/arch/alpha/Makefile
include $(srcdir)/purgatory/arch/arm/Makefile
+include $(srcdir)/purgatory/arch/arm64/Makefile
include $(srcdir)/purgatory/arch/i386/Makefile
include $(srcdir)/purgatory/arch/ia64/Makefile
include $(srcdir)/purgatory/arch/mips/Makefile
diff --git a/purgatory/arch/arm64/Makefile b/purgatory/arch/arm64/Makefile
new file mode 100644
index 0000000..636abea
--- /dev/null
+++ b/purgatory/arch/arm64/Makefile
@@ -0,0 +1,18 @@
+
+arm64_PURGATORY_EXTRA_CFLAGS = \
+ -mcmodel=large \
+ -fno-stack-protector \
+ -fno-asynchronous-unwind-tables \
+ -Wundef \
+ -Werror-implicit-function-declaration \
+ -Wdeclaration-after-statement \
+ -Werror=implicit-int \
+ -Werror=strict-prototypes
+
+arm64_PURGATORY_SRCS += \
+ purgatory/arch/arm64/entry.S \
+ purgatory/arch/arm64/purgatory-arm64.c
+
+dist += \
+ $(arm64_PURGATORY_SRCS) \
+ purgatory/arch/arm64/Makefile
diff --git a/purgatory/arch/arm64/entry.S b/purgatory/arch/arm64/entry.S
new file mode 100644
index 0000000..adf16f4
--- /dev/null
+++ b/purgatory/arch/arm64/entry.S
@@ -0,0 +1,51 @@
+/*
+ * ARM64 purgatory.
+ */
+
+.macro size, sym:req
+ .size \sym, . - \sym
+.endm
+
+.text
+
+.globl purgatory_start
+purgatory_start:
+
+ adr x19, .Lstack
+ mov sp, x19
+
+ bl purgatory
+
+ /* Start new image. */
+ ldr x17, arm64_kernel_entry
+ ldr x0, arm64_dtb_addr
+ mov x1, xzr
+ mov x2, xzr
+ mov x3, xzr
+ br x17
+
+size purgatory_start
+
+.ltorg
+
+.align 4
+ .rept 256
+ .quad 0
+ .endr
+.Lstack:
+
+.data
+
+.align 3
+
+.globl arm64_kernel_entry
+arm64_kernel_entry:
+ .quad 0
+size arm64_kernel_entry
+
+.globl arm64_dtb_addr
+arm64_dtb_addr:
+ .quad 0
+size arm64_dtb_addr
+
+.end
\ No newline@end of file
diff --git a/purgatory/arch/arm64/purgatory-arm64.c b/purgatory/arch/arm64/purgatory-arm64.c
new file mode 100644
index 0000000..fe50fcf
--- /dev/null
+++ b/purgatory/arch/arm64/purgatory-arm64.c
@@ -0,0 +1,19 @@
+/*
+ * ARM64 purgatory.
+ */
+
+#include <stdint.h>
+#include <purgatory.h>
+
+void putchar(int ch)
+{
+ /* Nothing for now */
+}
+
+void post_verification_setup_arch(void)
+{
+}
+
+void setup_arch(void)
+{
+}
--
2.7.4
^ permalink raw reply related
* [PATCH v6 0/3] arm64 kexec-tools patches
From: Geoff Levand @ 2016-09-21 18:14 UTC (permalink / raw)
To: linux-arm-kernel
This series adds the core support for kexec re-boot on ARM64.
Linux kernel support for ARM64 kexec reboot has been merged in v4.8-rc1 with the
expectation that it will be included in the v4.8 stable kernel release.
For ARM64 kdump support see Takahiro's latest kdump patches [1].
[1] http://lists.infradead.org/pipermail/kexec
Changes for v6 (Sep , 2016, 2m):
o Remove the get_memory_ranges_dt() routine.
o Rename dtb_[12] to dtb_{proc,sys,user}.
Changes for v5 (Sep 1, 2016, 2m):
o Add common routine arm64_locate_kernel_segment().
Changes for v4 (Aug 18, 2016, 1m):
o Fix some error return values and error messages.
o Add enum arm64_header_page_size.
o Rename page_offset to vp_offset.
Changes for v3 (Aug 10, 2016, 1m):
o Rebase to 2.0.13.
o Add support for flag bits 1-3 to arm64 image-header.h.
o Fix OPT_ARCH_MAX value.
o Use fdt_pack() in dtb_set_property().
o Remove patch ("kexec: (bugfix) calc correct end address of memory ranges in device tree").
Changes for v2 (July 26, 2016, 0m):
o Inline some small routines.
o Reformat some dbgprintf messages.
o Remove debug_brk from entry.S
o Change arm64_image_header.flags to uint64_t.
o Look in iomem then dt for mem info.
o Remove check_cpu_nodes.
o Remove purgatory printing.
First submission v1 (July 20, 2016).
-Geoff
The following changes since commit 67488beb0a6ee8ad2c0b05f721a9e00041fab93a:
kexec-tools 2.0.13 (2016-08-08 12:26:44 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git for-merge-arm64-v6
for you to fetch changes up to a9f1fafd7c248d33768177438742b90bc4338202:
arm64: Add support for binary image files (2016-09-21 11:04:03 -0700)
----------------------------------------------------------------
Geoff Levand (2):
kexec: Add common device tree routines
arm64: Add arm64 kexec support
Pratyush Anand (1):
arm64: Add support for binary image files
configure.ac | 3 +
kexec/Makefile | 5 +
kexec/arch/arm64/Makefile | 40 +++
kexec/arch/arm64/crashdump-arm64.c | 21 ++
kexec/arch/arm64/crashdump-arm64.h | 12 +
kexec/arch/arm64/image-header.h | 146 ++++++++
kexec/arch/arm64/include/arch/options.h | 39 ++
kexec/arch/arm64/kexec-arm64.c | 615 ++++++++++++++++++++++++++++++++
kexec/arch/arm64/kexec-arm64.h | 71 ++++
kexec/arch/arm64/kexec-elf-arm64.c | 146 ++++++++
kexec/arch/arm64/kexec-image-arm64.c | 80 +++++
kexec/dt-ops.c | 145 ++++++++
kexec/dt-ops.h | 13 +
kexec/kexec-syscall.h | 8 +-
purgatory/Makefile | 1 +
purgatory/arch/arm64/Makefile | 18 +
purgatory/arch/arm64/entry.S | 51 +++
purgatory/arch/arm64/purgatory-arm64.c | 19 +
18 files changed, 1431 insertions(+), 2 deletions(-)
create mode 100644 kexec/arch/arm64/Makefile
create mode 100644 kexec/arch/arm64/crashdump-arm64.c
create mode 100644 kexec/arch/arm64/crashdump-arm64.h
create mode 100644 kexec/arch/arm64/image-header.h
create mode 100644 kexec/arch/arm64/include/arch/options.h
create mode 100644 kexec/arch/arm64/kexec-arm64.c
create mode 100644 kexec/arch/arm64/kexec-arm64.h
create mode 100644 kexec/arch/arm64/kexec-elf-arm64.c
create mode 100644 kexec/arch/arm64/kexec-image-arm64.c
create mode 100644 kexec/dt-ops.c
create mode 100644 kexec/dt-ops.h
create mode 100644 purgatory/arch/arm64/Makefile
create mode 100644 purgatory/arch/arm64/entry.S
create mode 100644 purgatory/arch/arm64/purgatory-arm64.c
--
2.7.4
^ permalink raw reply
* [PATCH v6 3/3] arm64: Add support for binary image files
From: Geoff Levand @ 2016-09-21 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1474481332.git.geoff@infradead.org>
From: Pratyush Anand <panand@redhat.com>
Signed-off-by: Pratyush Anand <panand@redhat.com>
[Reworked and cleaned up]
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
kexec/arch/arm64/kexec-image-arm64.c | 49 ++++++++++++++++++++++++++++++++----
1 file changed, 44 insertions(+), 5 deletions(-)
diff --git a/kexec/arch/arm64/kexec-image-arm64.c b/kexec/arch/arm64/kexec-image-arm64.c
index 42d2ea7..960ed96 100644
--- a/kexec/arch/arm64/kexec-image-arm64.c
+++ b/kexec/arch/arm64/kexec-image-arm64.c
@@ -3,7 +3,9 @@
*/
#define _GNU_SOURCE
+
#include "kexec-arm64.h"
+#include <limits.h>
int image_arm64_probe(const char *kernel_buf, off_t kernel_size)
{
@@ -21,14 +23,53 @@ int image_arm64_probe(const char *kernel_buf, off_t kernel_size)
return -1;
}
- fprintf(stderr, "kexec: ARM64 binary image files are currently NOT SUPPORTED.\n");
- return -1;
+ return 0;
}
int image_arm64_load(int argc, char **argv, const char *kernel_buf,
off_t kernel_size, struct kexec_info *info)
{
- return -1;
+ const struct arm64_image_header *header;
+ unsigned long kernel_segment;
+ int result;
+
+ header = (const struct arm64_image_header *)(kernel_buf);
+
+ if (arm64_process_image_header(header))
+ return -1;
+
+ kernel_segment = arm64_locate_kernel_segment(info);
+
+ if (kernel_segment == ULONG_MAX) {
+ dbgprintf("%s: Kernel segment is not allocated\n", __func__);
+ result = -EFAILED;
+ goto exit;
+ }
+
+ dbgprintf("%s: kernel_segment: %016lx\n", __func__, kernel_segment);
+ dbgprintf("%s: text_offset: %016lx\n", __func__,
+ arm64_mem.text_offset);
+ dbgprintf("%s: image_size: %016lx\n", __func__,
+ arm64_mem.image_size);
+ dbgprintf("%s: phys_offset: %016lx\n", __func__,
+ arm64_mem.phys_offset);
+ dbgprintf("%s: vp_offset: %016lx\n", __func__,
+ arm64_mem.vp_offset);
+ dbgprintf("%s: PE format: %s\n", __func__,
+ (arm64_header_check_pe_sig(header) ? "yes" : "no"));
+
+ /* load the kernel */
+ add_segment_phys_virt(info, kernel_buf, kernel_size,
+ kernel_segment + arm64_mem.text_offset,
+ arm64_mem.image_size, 0);
+
+ result = arm64_load_other_segments(info, kernel_segment
+ + arm64_mem.text_offset);
+
+exit:
+ if (result)
+ fprintf(stderr, "kexec: load failed.\n");
+ return result;
}
void image_arm64_usage(void)
@@ -36,6 +77,4 @@ void image_arm64_usage(void)
printf(
" An ARM64 binary image, compressed or not, big or little endian.\n"
" Typically an Image, Image.gz or Image.lzma file.\n\n");
- printf(
-" ARM64 binary image files are currently NOT SUPPORTED.\n\n");
}
--
2.7.4
^ permalink raw reply related
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Bjorn Helgaas @ 2016-09-21 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921140549.GA11968@red-moon>
On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Sep 20, 2016 at 02:17:44PM -0500, Bjorn Helgaas wrote:
> > On Tue, Sep 20, 2016 at 04:09:25PM +0100, Ard Biesheuvel wrote:
>
> [...]
>
> > > None of these platforms can be fixed entirely in software, and given
> > > that we will not be adding quirks for new broken hardware, we should
> > > ask ourselves whether having two versions of a quirk, i.e., one for
> > > broken hardware + currently shipping firmware, and one for the same
> > > broken hardware with fixed firmware is really an improvement over what
> > > has been proposed here.
> >
> > We're talking about two completely different types of quirks:
> >
> > 1) MCFG quirks to use memory-mapped config space that doesn't quite
> > conform to the ECAM model in the PCIe spec, and
> >
> > 2) Some yet-to-be-determined method to describe address space
> > consumed by a bridge.
> >
> > The first two patches of this series are a nice implementation for 1).
> > The third patch (ThunderX-specific) is one possibility for 2), but I
> > don't like it because there's no way for generic software like the
> > ACPI core to discover these resources.
>
> Ok, so basically this means that to implement (2) we need to assign
> some sort of _HID to these quirky PCI bridges (so that we know what
> device they represent and we can retrieve their _CRS). I take from
> this discussion that the goal is to make sure that all non-config
> resources have to be declared through _CRS device objects, which is
> fine but that requires a FW update (unless we can fabricate ACPI
> devices and corresponding _CRS in the kernel whenever we match a
> given MCFG table signature).
All resources consumed by ACPI devices should be declared through
_CRS. If you want to fabricate ACPI devices or _CRS via kernel
quirks, that's fine with me. This could be triggered via MCFG
signature, DMI info, host bridge _HID, etc.
> We discussed this already and I think we should make a decision:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414722.html
>
> > > > I'd like to step back and come up with some understanding of how
> > > > non-broken firmware *should* deal with this issue. Then, if we *do*
> > > > work around this particular broken firmware in the kernel, it would be
> > > > nice to do it in a way that fits in with that understanding.
> > > >
> > > > For example, if a companion ACPI device is the preferred solution, an
> > > > ACPI quirk could fabricate a device with the required resources. That
> > > > would address the problem closer to the source and make it more likely
> > > > that the rest of the system will work correctly: /proc/iomem could
> > > > make sense, things that look at _CRS generically would work (e.g,
> > > > /sys/, an admittedly hypothetical "lsacpi", etc.)
> > > >
> > > > Hard-coding stuff in drivers is a point solution that doesn't provide
> > > > any guidance for future platforms and makes it likely that the hack
> > > > will get copied into even more drivers.
> > > >
> > >
> > > OK, I see. But the guidance for future platforms should be 'do not
> > > rely on quirks', and what I am arguing here is that the more we polish
> > > up this code and make it clean and reusable, the more likely it is
> > > that will end up getting abused by new broken hardware that we set out
> > > to reject entirely in the first place.
> > >
> > > So of course, if the quirk involves claiming resources, let's make
> > > sure that this occurs in the cleanest and most compliant way possible.
> > > But any factoring/reuse concerns other than for the current crop of
> > > broken hardware should be avoided imo.
> >
> > If future hardware is completely ECAM-compliant and we don't need any
> > more MCFG quirks, that would be great.
>
> Yes.
>
> > But we'll still need to describe that memory-mapped config space
> > somewhere. If that's done with PNP0C02 or similar devices (as is done
> > on my x86 laptop), we'd be all set.
>
> I am not sure I understand what you mean here. Are you referring
> to MCFG regions reported as PNP0c02 resources through its _CRS ?
Yes. PCI Firmware Spec r3.0, Table 4-2, note 2 says address ranges
reported via MCFG or _CBA should be reserved by _CRS of a PNP0C02
device.
> IIUC PNP0C02 is a reservation mechanism, but it does not help us
> associate its _CRS to a specific PCI host bridge instance, right ?
Gab proposed a hierarchy that *would* associate a PNP0C02 device with
a PCI bridge:
Device (PCI1) {
Name (_HID, "HISI0080") // PCI Express Root Bridge
Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
Method (_CRS, 0, Serialized) { // Root complex resources (windows) }
Device (RES0) {
Name (_HID, "HISI0081") // HiSi PCIe RC config base address
Name (_CID, "PNP0C02") // Motherboard reserved resource
Name (_CRS, ResourceTemplate () { ... }
}
}
That's a possibility. The PCI Firmware Spec suggests putting RES0 at
the root (under \_SB), but I don't know why.
Putting it at the root means we couldn't generically associate it with
a bridge, although I could imagine something like this:
Device (RES1) {
Name (_HID, "HISI0081") // HiSi PCIe RC config base address
Name (_CID, "PNP0C02") // Motherboard reserved resource
Name (_CRS, ResourceTemplate () { ... }
Method (BRDG) { "PCI1" } // hand-wavy ASL
}
Device (PCI1) {
Name (_HID, "HISI0080") // PCI Express Root Bridge
Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
Method (_CRS, 0, Serialized) { // Root complex resources (windows) }
}
Where you could search PNP0C02 devices for a cookie that matched the
host bridge.
> > If we need to work around firmware in the field that doesn't do that,
> > one possibility is a PNP quirk along the lines of
> > quirk_amd_mmconfig_area().
>
> You mean matching PNP0C01/PNP0c02 and create a resource (that has to
> hardcoded in a static array in the kernel anyway, there is no way to
> retrieve it otherwise) in the corresponding PNP quirk handler ?
Right. On some hardware we can read the resource out of a
device-specific register, as we do in quirk_intel_mch(). But if
that's not possible, it would have to be hard-coded.
> And it is not a given we can match against PNP0c01/PNP0c02.
>
> So it looks like the only solution is allocating an _HID for each
> host bridge that is not ECAM compliant to add resources to its _CRS
> (unless the MCFG quirk does not need any additional data/resource,
> eg "use different set of PCI accessorsi 32-bit vs byte-access").
It doesn't matter whether it's ECAM-compliant or not. Any
memory-mapped config space should be reported via some device's _CRS.
The existing x86 practice is to use PNP0C02 devices for this purpose,
and I think we should just follow that practice.
> For FW that is immutable I really do not see what we can do apart
> from hardcoding the non-config resources (consumed by a bridge),
> somehow.
Right. Well, I assume you mean we should hard-code "non-window
resources consumed directly by a bridge". If firmware in the field is
broken, we should work around it, and that may mean hard-coding some
resources.
My point is that the hard-coding should not be buried in a driver
where it's invisible to the rest of the kernel. If we hard-code it in
a quirk that adds _CRS entries, then the kernel will work just like it
would if the firmware had been correct in the first place. The
resource will appear in /sys/devices/pnp*/*/resources and /proc/iomem,
and if we ever used _SRS to assign or move ACPI devices, we would know
to avoid the bridge resource.
Bjorn
^ permalink raw reply
* [PATCH] arm64: Correctly bounds check virt_addr_valid
From: Mark Rutland @ 2016-09-21 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474478928-25022-1-git-send-email-labbott@redhat.com>
Hi,
On Wed, Sep 21, 2016 at 10:28:48AM -0700, Laura Abbott wrote:
> virt_addr_valid is supposed to return true if and only if virt_to_page
> returns a valid page structure. The current macro does math on whatever
> address is given and passes that to pfn_valid to verify. vmalloc and
> module addresses can happen to generate a pfn that 'happens' to be
> valid. Fix this by only performing the pfn_valid check on addresses that
> have the potential to be valid.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> This caused a bug at least twice in hardened usercopy so it is an
> actual problem.
Are there other potentially-broken users of virt_addr_valid? It's not
clear to me what some drivers are doing with this, and therefore whether
we need to cc stable.
> A further TODO is full DEBUG_VIRTUAL support to
> catch these types of mistakes.
> ---
> arch/arm64/include/asm/memory.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 31b7322..f741e19 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -214,7 +214,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>
> #ifndef CONFIG_SPARSEMEM_VMEMMAP
> #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
> -#define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
> +#define virt_addr_valid(kaddr) (((u64)kaddr) >= PAGE_OFFSET && pfn_valid(__pa(kaddr) >> PAGE_SHIFT))
> #else
> #define __virt_to_pgoff(kaddr) (((u64)(kaddr) & ~PAGE_OFFSET) / PAGE_SIZE * sizeof(struct page))
> #define __page_to_voff(kaddr) (((u64)(page) & ~VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
> @@ -222,8 +222,8 @@ static inline void *phys_to_virt(phys_addr_t x)
> #define page_to_virt(page) ((void *)((__page_to_voff(page)) | PAGE_OFFSET))
> #define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) | VMEMMAP_START))
>
> -#define virt_addr_valid(kaddr) pfn_valid((((u64)(kaddr) & ~PAGE_OFFSET) \
> - + PHYS_OFFSET) >> PAGE_SHIFT)
> +#define virt_addr_valid(kaddr) (((u64)kaddr) >= PAGE_OFFSET && pfn_valid((((u64)(kaddr) & ~PAGE_OFFSET) \
> + + PHYS_OFFSET) >> PAGE_SHIFT))
> #endif
> #endif
Given the common sub-expression, perhaps it would be better to leave
these as-is, but prefix them with '_', and after the #endif, have
something like:
#define _virt_addr_is_linear(kaddr) (((u64)(kaddr)) >= PAGE_OFFSET)
#define virt_addr_valid(kaddr) (_virt_addr_is_linear(kaddr) && _virt_addr_valid(kaddr))
Otherwise, modulo the parenthesis issue you mentioned, this looks
logically correct to me.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] arm64: Correctly bounds check virt_addr_valid
From: Laura Abbott @ 2016-09-21 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474478928-25022-1-git-send-email-labbott@redhat.com>
On 09/21/2016 10:28 AM, Laura Abbott wrote:
> virt_addr_valid is supposed to return true if and only if virt_to_page
> returns a valid page structure. The current macro does math on whatever
> address is given and passes that to pfn_valid to verify. vmalloc and
> module addresses can happen to generate a pfn that 'happens' to be
> valid. Fix this by only performing the pfn_valid check on addresses that
> have the potential to be valid.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> This caused a bug at least twice in hardened usercopy so it is an
> actual problem. A further TODO is full DEBUG_VIRTUAL support to
> catch these types of mistakes.
> ---
> arch/arm64/include/asm/memory.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 31b7322..f741e19 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -214,7 +214,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>
> #ifndef CONFIG_SPARSEMEM_VMEMMAP
> #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
> -#define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
> +#define virt_addr_valid(kaddr) (((u64)kaddr) >= PAGE_OFFSET && pfn_valid(__pa(kaddr) >> PAGE_SHIFT))
> #else
> #define __virt_to_pgoff(kaddr) (((u64)(kaddr) & ~PAGE_OFFSET) / PAGE_SIZE * sizeof(struct page))
> #define __page_to_voff(kaddr) (((u64)(page) & ~VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
> @@ -222,8 +222,8 @@ static inline void *phys_to_virt(phys_addr_t x)
> #define page_to_virt(page) ((void *)((__page_to_voff(page)) | PAGE_OFFSET))
> #define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) | VMEMMAP_START))
>
> -#define virt_addr_valid(kaddr) pfn_valid((((u64)(kaddr) & ~PAGE_OFFSET) \
> - + PHYS_OFFSET) >> PAGE_SHIFT)
> +#define virt_addr_valid(kaddr) (((u64)kaddr) >= PAGE_OFFSET && pfn_valid((((u64)(kaddr) & ~PAGE_OFFSET) \
> + + PHYS_OFFSET) >> PAGE_SHIFT))
> #endif
> #endif
>
>
Bah, I realized I butchered the macro parenthesization. I'll fix that
in a v2. I'll wait for comments on this first.
Thanks,
Laura
^ permalink raw reply
* [PATCH] clk: nxp: clk-lpc32xx: Unmap region obtained by of_iomap
From: Sylvain Lemieux (gmail) @ 2016-09-21 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <162fe71f-e190-3511-6b06-35efdbc8573f@mleia.com>
On Wed, 2016-09-21 at 13:17 +0300, Vladimir Zapolskiy wrote:
> On 20.09.2016 13:54, Arvind Yadav wrote:
> > From: Arvind Yadav <arvind.yadav.cs@gmail.com>
> >
> > Free memory mapping, if lpc32xx_clk_init is not successful.
> >
> > Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> > ---
> > drivers/clk/nxp/clk-lpc32xx.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
> > index 90d740a..34c9735 100644
> > --- a/drivers/clk/nxp/clk-lpc32xx.c
> > +++ b/drivers/clk/nxp/clk-lpc32xx.c
> > @@ -1513,6 +1513,7 @@ static void __init lpc32xx_clk_init(struct device_node *np)
> > if (IS_ERR(clk_regmap)) {
> > pr_err("failed to regmap system control block: %ld\n",
> > PTR_ERR(clk_regmap));
> > + iounmap(base);
> > return;
> > }
> >
> >
>
> Acked-by: Vladimir Zapolskiy <vz@mleia.com>
>
> Thank you for the patch.
>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
> --
> With best wishes,
> Vladimir
>
>
^ permalink raw reply
* [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms
From: Sinan Kaya @ 2016-09-21 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921173129.GA20006@localhost>
On 9/21/2016 1:31 PM, Bjorn Helgaas wrote:
> On Wed, Sep 21, 2016 at 10:07:36AM -0400, Sinan Kaya wrote:
>> On 9/21/2016 9:11 AM, Bjorn Helgaas wrote:
>>> On Tue, Sep 20, 2016 at 09:15:14PM -0400, cov at codeaurora.org wrote:
>>>> Hi Bjorn, Thomasz,
>>>>
>>
>>>>
>>>> Did you delete this because there were no current users, because you'd
>>>> prefer users just use "-1", or for some other reason?
>>>
>>> I removed it because there were no users of it and, more importantly,
>>> the code doesn't implement support for it.
>>
>> Is it possible to queue up Cov's patch as part of this effort once he
>> rebases and sends an updated version? Cov will have to implement something
>> else now.
>
> I haven't see Cov's patch (patchwork doesn't follow URLs to git trees,
> and I normally don't either). If they show up on the mailing list,
> I'll take a look, of course.
>
> Bjorn
>
Thanks, I talked to Cov today. He's getting ready to post the rebased patch
once he completes testing.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] clocksource: bcm2835_timer: Unmap region obtained by of_iomap
From: Arvind Yadav @ 2016-09-21 17:33 UTC (permalink / raw)
To: linux-arm-kernel
Free memory mapping, if bcm2835_timer_init is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/clocksource/bcm2835_timer.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/clocksource/bcm2835_timer.c b/drivers/clocksource/bcm2835_timer.c
index e71acf2..f2f29d2 100644
--- a/drivers/clocksource/bcm2835_timer.c
+++ b/drivers/clocksource/bcm2835_timer.c
@@ -96,7 +96,7 @@ static int __init bcm2835_timer_init(struct device_node *node)
ret = of_property_read_u32(node, "clock-frequency", &freq);
if (ret) {
pr_err("Can't read clock-frequency");
- return ret;
+ goto err_iounmap;
}
system_clock = base + REG_COUNTER_LO;
@@ -108,13 +108,15 @@ static int __init bcm2835_timer_init(struct device_node *node)
irq = irq_of_parse_and_map(node, DEFAULT_TIMER);
if (irq <= 0) {
pr_err("Can't parse IRQ");
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_iounmap;
}
timer = kzalloc(sizeof(*timer), GFP_KERNEL);
if (!timer) {
pr_err("Can't allocate timer struct\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_iounmap;
}
timer->control = base + REG_CONTROL;
@@ -133,7 +135,7 @@ static int __init bcm2835_timer_init(struct device_node *node)
ret = setup_irq(irq, &timer->act);
if (ret) {
pr_err("Can't set up timer IRQ\n");
- return ret;
+ goto err_iounmap;
}
clockevents_config_and_register(&timer->evt, freq, 0xf, 0xffffffff);
@@ -141,6 +143,10 @@ static int __init bcm2835_timer_init(struct device_node *node)
pr_info("bcm2835: system timer (irq = %d)\n", irq);
return 0;
+
+err_iounmap:
+ iounmap(base);
+ return ret;
}
CLOCKSOURCE_OF_DECLARE(bcm2835, "brcm,bcm2835-system-timer",
bcm2835_timer_init);
--
2.7.4
^ permalink raw reply related
* [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms
From: Bjorn Helgaas @ 2016-09-21 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <25529f96-3e80-0524-82d8-6eeb517df5b5@codeaurora.org>
On Wed, Sep 21, 2016 at 10:07:36AM -0400, Sinan Kaya wrote:
> On 9/21/2016 9:11 AM, Bjorn Helgaas wrote:
> > On Tue, Sep 20, 2016 at 09:15:14PM -0400, cov at codeaurora.org wrote:
> >> Hi Bjorn, Thomasz,
> >>
>
> >>
> >> Did you delete this because there were no current users, because you'd
> >> prefer users just use "-1", or for some other reason?
> >
> > I removed it because there were no users of it and, more importantly,
> > the code doesn't implement support for it.
>
> Is it possible to queue up Cov's patch as part of this effort once he
> rebases and sends an updated version? Cov will have to implement something
> else now.
I haven't see Cov's patch (patchwork doesn't follow URLs to git trees,
and I normally don't either). If they show up on the mailing list,
I'll take a look, of course.
Bjorn
^ 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