* [GIT PULL 4/4] Rockchip arm64 defconfig updates for 4.18 round 1
From: Heiko Stuebner @ 2018-05-15 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2000491.bLgWuj0xar@phil>
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-defconfig64-1
for you to fetch changes up to 214f2c319a140f8a0121f362ad8e73ea1576d5ad:
arm64: defconfig: enable rockchip efuse (2018-05-09 16:33:09 +0200)
----------------------------------------------------------------
Enablement of Rockchip-specific efuse, io-domain and typec drivers
as well as general cros-ec, hid, touchscreen bluetooth and wifi-drivers
on 64bit arm platforms.
----------------------------------------------------------------
Enric Balletbo i Serra (3):
arm64: defconfig: Enable typec-phy and extcon-usbc-cros-ec for rk3399
arm64: defconfig: Enable Rockchip io-domain driver
arm64: defconfig: Enable ChromeOS EC drivers for supported Chromebooks.
Ezequiel Garcia (4):
arm64: defconfig: Enable HID over I2C drivers
arm64: defconfig: Enable Atmel Maxtouch driver
arm64: defconfig: Enable Marvell WiFi-Ex PCIe driver
arm64: defconfig: Enable bluetooth USB support
Heiko Stuebner (1):
arm64: defconfig: enable rockchip efuse
arch/arm64/configs/defconfig | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
^ permalink raw reply
* [PATCH 06/18] arm64: move sve_user_{enable, disable} to <asm/fpsimd.h>
From: Mark Rutland @ 2018-05-15 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514110649.GC7753@e103592.cambridge.arm.com>
On Mon, May 14, 2018 at 12:06:50PM +0100, Dave Martin wrote:
> On Mon, May 14, 2018 at 10:46:28AM +0100, Mark Rutland wrote:
> > In subsequent patches, we'll want to make use of sve_user_enable() and
> > sve_user_disable() outside of kernel/fpsimd.c. Let's move these to
> > <asm/fpsimd.h> where we can make use of them.
> >
> > To avoid ifdeffery in sequences like:
> >
> > if (system_supports_sve() && some_condition
> > sve_user_disable();
> >
> > ... empty stubs are provided when support for SVE is not enabled.
> >
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Dave Martin <dave.martin@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > ---
> > arch/arm64/include/asm/fpsimd.h | 17 ++++++++++++++++-
> > arch/arm64/kernel/fpsimd.c | 11 -----------
> > 2 files changed, 16 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> > index aa7162ae93e3..7377d7593c06 100644
> > --- a/arch/arm64/include/asm/fpsimd.h
> > +++ b/arch/arm64/include/asm/fpsimd.h
> > @@ -16,11 +16,13 @@
> > #ifndef __ASM_FP_H
> > #define __ASM_FP_H
> >
> > -#include <asm/ptrace.h>
> > #include <asm/errno.h>
> > +#include <asm/ptrace.h>
> > +#include <asm/sysreg.h>
> >
> > #ifndef __ASSEMBLY__
> >
> > +#include <linux/build_bug.h>
> > #include <linux/cache.h>
> > #include <linux/init.h>
> > #include <linux/stddef.h>
> > @@ -81,6 +83,16 @@ extern int sve_set_vector_length(struct task_struct *task,
> > extern int sve_set_current_vl(unsigned long arg);
> > extern int sve_get_current_vl(void);
> >
> > +static inline void sve_user_disable(void)
> > +{
> > + sysreg_clear_set(cpacr_el1, CPACR_EL1_ZEN_EL0EN, 0);
> > +}
> > +
> > +static inline void sve_user_enable(void)
> > +{
> > + sysreg_clear_set(cpacr_el1, 0, CPACR_EL1_ZEN_EL0EN);
> > +}
> > +
> > /*
> > * Probing and setup functions.
> > * Calls to these functions must be serialised with one another.
> > @@ -107,6 +119,9 @@ static inline int sve_get_current_vl(void)
> > return -EINVAL;
> > }
> >
> > +static inline void sve_user_disable(void) { }
> > +static inline void sve_user_enable(void) { }
> > +
>
> Alternatively, just move the full definitions outside the #ifdef
> CONFIG_ARM64_SVE.
Can do, though I was trying to keep the exsting pattern with empty
inlines for the !CONFIG_ARM64_SVE case.
>
> All calls to these should be shadowed by an if
> (system_supports_sve()) in any case, and setting/clearing ZEN_EL0EN
> in the CPACR_EL1 ought to be harmless now that the meaning of these
> bits architecturally committed.
>
> Ideally we would have a BUG_ON(!system_supports_sve()) in those
> functions, but we won't won't to pay the cost in a production kernel.
Earlier I'd put BUILD_BUG() in the body for the !CONFIG_ARM64_SVE case,
to catch that kind of thing -- I could restore that.
> > static inline void sve_init_vq_map(void) { }
> > static inline void sve_update_vq_map(void) { }
> > static inline int sve_verify_vq_map(void) { return 0; }
> > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> > index 088940387a4d..79a81c7d85c6 100644
> > --- a/arch/arm64/kernel/fpsimd.c
> > +++ b/arch/arm64/kernel/fpsimd.c
> > @@ -159,7 +159,6 @@ static void sve_free(struct task_struct *task)
> > __sve_free(task);
> > }
> >
> > -
>
> Hmmm, Ack. Check for conflicts with the KVM FPSIMD rework [1] (though
> trivial).
I'll assume that Ack stands regardless. :)
Thanks,
Mark.
^ permalink raw reply
* [GIT PULL 3/4] Rockchip dts64 updates for 4.18 round 1
From: Heiko Stuebner @ 2018-05-15 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2000491.bLgWuj0xar@phil>
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-dts64-1
for you to fetch changes up to 17bd0737948aa841b76278a601217b914aa5f18e:
arm64: dts: rockchip: enable hdmi on rk3399-puma-haikou (2018-05-03 14:38:20 +0200)
----------------------------------------------------------------
All iommus got their clocks added and rk3399 got support for its
usb3-phy otg-port and better ajustment for the cpll child clocks.
On the board side, all rk3399 got their typec phys enabled - which
is needed for better usb support, the sapphire board got some more
properties moved to the excavator baseboard where they really belong,
kevin got a fix to use a real devicetree compatible and puma-haikou
got its hdmi port enabled.
----------------------------------------------------------------
Dmitry Torokhov (1):
arm64: dts: rockchip: use canonical compatible for touchpad/touchscreen on gru-kevin
Enric Balletbo i Serra (5):
arm64: dts: rockchip: enable typec-phy for rk3399-sapphire
arm64: dts: rockchip: enable typec-phy for rk3399-firefly
arm64: dts: rockchip: enable typec-phy1 for rk3399-puma
arm64: dts: rockchip: enable typec-phy0 for rk3399-puma-haikou
arm64: dts: rockchip: add usb3-phy otg-port support for rk3399
Jakob Unterwurzacher (1):
arm64: dts: rockchip: enable hdmi on rk3399-puma-haikou
Jeffy Chen (1):
arm64: dts: rockchip: add clocks in iommu nodes
Lin Huang (1):
arm64: dts: rockchip: assign clock rate for cpll child clocks on rk3399
Vicente Bergas (2):
arm64: dts: rockchip: move rk3399-sapphire PCIe to excavator baseboard
arm64: dts: rockchip: remove PCIe assigned-clocks in excavator baseboard
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 10 ++++++
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 10 ++++++
arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 8 +++++
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 4 +--
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 8 +++--
.../arm64/boot/dts/rockchip/rk3399-puma-haikou.dts | 25 +++++++++++++++
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 4 +++
.../dts/rockchip/rk3399-sapphire-excavator.dts | 12 ++++++++
arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 23 +++++---------
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 36 ++++++++++++++++------
10 files changed, 111 insertions(+), 29 deletions(-)
^ permalink raw reply
* [GIT PULL 2/4] Rockchip dts32 updates for 4.18 round 1
From: Heiko Stuebner @ 2018-05-15 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2000491.bLgWuj0xar@phil>
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-dts32-1
for you to fetch changes up to 08624814cbec12b1ce877bf80f6990ad2b9cdcd7:
ARM: dts: rockchip: default serial for rk3288 Tinker Board (2018-04-20 14:55:07 +0200)
----------------------------------------------------------------
Fixed pin numbers for uart4 on rk3288, iommu clocks and small changes
over multiple boards like default serial setting for rk3288-tinker,
output selection for the dp83867 on the phycore-som and the newly
added pwm-backlight delay properties for veyron boards.
----------------------------------------------------------------
Daniel Schultz (1):
ARM: dts: rockchip: Add dp83867 CLK_OUT muxing on rk3288-phycore-som
Enric Balletbo i Serra (2):
ARM: dts: rockchip: set PWM delay backlight settings for Veyron
ARM: dts: rockchip: set PWM delay backlight settings for Minnie
Heinrich Schuchardt (1):
ARM: dts: rockchip: default serial for rk3288 Tinker Board
Jacob Chen (1):
ARM: dts: rockchip: fix uart4 pin-numbers for rk3288
Jeffy Chen (1):
ARM: dts: rockchip: add clocks in iommu nodes
arch/arm/boot/dts/rk3036.dtsi | 2 ++
arch/arm/boot/dts/rk322x.dtsi | 8 ++++++++
arch/arm/boot/dts/rk3288-phycore-som.dtsi | 1 +
arch/arm/boot/dts/rk3288-tinker.dts | 4 ++++
arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 3 ++-
arch/arm/boot/dts/rk3288-veyron-minnie.dts | 2 ++
arch/arm/boot/dts/rk3288.dtsi | 20 ++++++++++++++++----
7 files changed, 35 insertions(+), 5 deletions(-)
^ permalink raw reply
* [GIT PULL 1/4] Rockchip driver updates for 4.18 round 1
From: Heiko Stuebner @ 2018-05-15 10:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin Olof,
please find below and in the replies the main pull requests for Rockchip
stuff for 4.18. Depending on timing there may or may not be a second
round but so far I don't have anything big on the radar.
The signed tags should explain the individual contents, so please pull.
Thanks
Heiko
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-drivers-1
for you to fetch changes up to 9e59c5f66c624b43c766a9fe3b2430e0e976bf0e:
soc: rockchip: power-domain: Fix wrong value when power up pd with writemask (2018-05-14 11:53:26 +0200)
----------------------------------------------------------------
Fix for an issue introduced in 2016 where some powerdomains could only
be turned off but not on again.
----------------------------------------------------------------
Finley Xiao (1):
soc: rockchip: power-domain: Fix wrong value when power up pd with writemask
drivers/soc/rockchip/pm_domains.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [PATCH v4 2/2] ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver
From: Ganapatrao Kulkarni @ 2018-05-15 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKTKpr7Q7T9ZCTBi=LQR=XaAoihbBA3OKCO7yFobzNmR8EfyjQ@mail.gmail.com>
Hi Mark,
On Sat, May 5, 2018 at 12:16 AM, Ganapatrao Kulkarni <gklkml16@gmail.com> wrote:
> Hi Mark,
>
> On Thu, Apr 26, 2018 at 4:29 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> Hi,
>>
>> On Wed, Apr 25, 2018 at 02:30:47PM +0530, Ganapatrao Kulkarni wrote:
>>> +
>>> +/* L3c and DMC has 16 and 8 channels per socket respectively.
>>> + * Each Channel supports UNCORE PMU device and consists of
>>> + * 4 independent programmable counters. Counters are 32 bit
>>> + * and does not support overflow interrupt, they needs to be
>>> + * sampled before overflow(i.e, at every 2 seconds).
>>> + */
>>> +
>>> +#define UNCORE_MAX_COUNTERS 4
>>> +#define UNCORE_L3_MAX_TILES 16
>>> +#define UNCORE_DMC_MAX_CHANNELS 8
>>> +
>>> +#define UNCORE_HRTIMER_INTERVAL (2 * NSEC_PER_SEC)
>>
>> How was a period of two seconds chosen?
>
> It has been suggested from hw team to sample before 3 to 4 seconds.
>
>>
>> What's the maximum clock speed for the L3C and DMC?
>
> L3C at 1.5GHz and DMC at 1.2GHz
>>
>> Given that all channels compete for access to the muxed register
>> interface, I suspect we need to try more often than once every 2
>> seconds...
>
> 2 seconds seems to be sufficient. So far testing looks good.
>
>>
>> [...]
>>
>>> +struct active_timer {
>>> + struct perf_event *event;
>>> + struct hrtimer hrtimer;
>>> +};
>>> +
>>> +/*
>>> + * pmu on each socket has 2 uncore devices(dmc and l3),
>>> + * each uncore device has up to 16 channels, each channel can sample
>>> + * events independently with counters up to 4.
>>> + *
>>> + * struct thunderx2_pmu_uncore_channel created per channel.
>>> + * struct thunderx2_pmu_uncore_dev per uncore device.
>>> + */
>>> +struct thunderx2_pmu_uncore_channel {
>>> + struct thunderx2_pmu_uncore_dev *uncore_dev;
>>> + struct pmu pmu;
>>
>> Can we put the pmu first in the struct, please?
>
> ok
>>
>>> + int counter;
>>
>> AFAICT, this counter field is never used.
>
> hmm ok, will remove.
>>
>>> + int channel;
>>> + DECLARE_BITMAP(counter_mask, UNCORE_MAX_COUNTERS);
>>> + struct active_timer *active_timers;
>>
>> You should only need a single timer per channel, rather than one per
>> event.
>>
>> I think you can get rid of the active_timer structure, and have:
>>
>> struct perf_event *events[UNCORE_MAX_COUNTERS];
>> struct hrtimer timer;
>>
>
> thanks, will change as suggested.
>
>>> + /* to sync counter alloc/release */
>>> + raw_spinlock_t lock;
>>> +};
>>> +
>>> +struct thunderx2_pmu_uncore_dev {
>>> + char *name;
>>> + struct device *dev;
>>> + enum thunderx2_uncore_type type;
>>> + unsigned long base;
>>
>> This should be:
>>
>> void __iomem *base;
>
> ok
>>
>> [...]
>>
>>> +static ssize_t cpumask_show(struct device *dev,
>>> + struct device_attribute *attr, char *buf)
>>> +{
>>> + struct cpumask cpu_mask;
>>> + struct thunderx2_pmu_uncore_channel *pmu_uncore =
>>> + pmu_to_thunderx2_pmu_uncore(dev_get_drvdata(dev));
>>> +
>>> + /* Pick first online cpu from the node */
>>> + cpumask_clear(&cpu_mask);
>>> + cpumask_set_cpu(cpumask_first(
>>> + cpumask_of_node(pmu_uncore->uncore_dev->node)),
>>> + &cpu_mask);
>>> +
>>> + return cpumap_print_to_pagebuf(true, buf, &cpu_mask);
>>> +}
>>
>> AFAICT cpumask_of_node() returns a mask that can include offline CPUs.
>>
>> Regardless, I don't think that you can keep track of the management CPU
>> this way. Please keep track of the CPU the PMU should be managed by,
>> either with a cpumask or int embedded within the PMU structure.
>
> thanks, will add hotplug callbacks.
>>
>> At hotplug time, you'll need to update the management CPU, calling
>> perf_pmu_migrate_context() when it is offlined.
>
> ok
>>
>> [...]
>>
>>> +static int alloc_counter(struct thunderx2_pmu_uncore_channel *pmu_uncore)
>>> +{
>>> + int counter;
>>> +
>>> + raw_spin_lock(&pmu_uncore->lock);
>>> + counter = find_first_zero_bit(pmu_uncore->counter_mask,
>>> + pmu_uncore->uncore_dev->max_counters);
>>> + if (counter == pmu_uncore->uncore_dev->max_counters) {
>>> + raw_spin_unlock(&pmu_uncore->lock);
>>> + return -ENOSPC;
>>> + }
>>> + set_bit(counter, pmu_uncore->counter_mask);
>>> + raw_spin_unlock(&pmu_uncore->lock);
>>> + return counter;
>>> +}
>>> +
>>> +static void free_counter(struct thunderx2_pmu_uncore_channel *pmu_uncore,
>>> + int counter)
>>> +{
>>> + raw_spin_lock(&pmu_uncore->lock);
>>> + clear_bit(counter, pmu_uncore->counter_mask);
>>> + raw_spin_unlock(&pmu_uncore->lock);
>>> +}
>>
>> I don't believe that locking is required in either of these, as the perf
>> core serializes pmu::add() and pmu::del(), where these get called.
without this locking, i am seeing "BUG: scheduling while atomic" when
i run perf with more events together than the maximum counters
supported
>
> thanks, it seems to be not required.
>>
>>> +
>>> +/*
>>> + * DMC and L3 counter interface is muxed across all channels.
>>> + * hence we need to select the channel before accessing counter
>>> + * data/control registers.
>>
>> Are there separate interfaces for all-dmc-channels and all-l3c-channels?
>
> separate interface for DMC and L3c.
> channels within DMC/L3C are muxed.
>
>>
>> ... or is a single interface used by all-dmc-and-l3c-channels?
>>
>>> + *
>>> + * L3 Tile and DMC channel selection is through SMC call
>>> + * SMC call arguments,
>>> + * x0 = THUNDERX2_SMC_CALL_ID (Vendor SMC call Id)
>>> + * x1 = THUNDERX2_SMC_SET_CHANNEL (Id to set DMC/L3C channel)
>>> + * x2 = Node id
>>
>> How do we map Linux node IDs to the firmware's view of node IDs?
>>
>> I don't believe the two are necessarily the same -- Linux's node IDs are
>> a Linux-specific construct.
>
> both are same, it is numa node id from ACPI/firmware.
>
>>
>> It would be much nicer if we could pass something based on the MPIDR,
>> which is a known HW construct, or if this implicitly affected the
>> current node.
>
> IMO, node id is sufficient.
>
>>
>> It would be vastly more sane for this to not be muxed at all. :/
>
> i am helpless due to crappy hw design!
>
>>
>>> + * x3 = DMC(1)/L3C(0)
>>> + * x4 = channel Id
>>> + */
>>> +static void uncore_select_channel(struct perf_event *event)
>>> +{
>>> + struct arm_smccc_res res;
>>> + struct thunderx2_pmu_uncore_channel *pmu_uncore =
>>> + pmu_to_thunderx2_pmu_uncore(event->pmu);
>>> +
>>> + arm_smccc_smc(THUNDERX2_SMC_CALL_ID, THUNDERX2_SMC_SET_CHANNEL,
>>> + pmu_uncore->uncore_dev->node,
>>> + pmu_uncore->uncore_dev->type,
>>> + pmu_uncore->channel, 0, 0, 0, &res);
>>> +
>>> +}
>>
>> Why aren't we checking the return value of the SMC call?
>
> thanks, i will add.
>
>>
>> The muxing and SMC sound quite scary. :/
>
> i too agree!, however i have no other option since the muxing register
> is a secure register.
>>
>>> +
>>> +static void uncore_start_event_l3c(struct perf_event *event, int flags)
>>> +{
>>> + u32 val;
>>> + struct hw_perf_event *hwc = &event->hw;
>>> +
>>> + /* event id encoded in bits [07:03] */
>>> + val = GET_EVENTID(event) << 3;
>>> + reg_writel(val, hwc->config_base);
>>> +
>>> + if (flags & PERF_EF_RELOAD) {
>>> + u64 prev_raw_count =
>>> + local64_read(&event->hw.prev_count);
>>> + reg_writel(prev_raw_count, hwc->event_base);
>>> + }
>>> + local64_set(&event->hw.prev_count,
>>> + reg_readl(hwc->event_base));
>>
>> It would be simpler to ignore PERF_EF_RELOAD, and always reprogram the
>> prev_count and HW to zero.
>
> ok, will change
>>
>>> +}
>>> +
>>> +static void uncore_start_event_dmc(struct perf_event *event, int flags)
>>> +{
>>> + u32 val, event_shift = 8;
>>> + struct hw_perf_event *hwc = &event->hw;
>>> +
>>> + /* enable and start counters and read current value in prev_count */
>>> + val = reg_readl(hwc->config_base);
>>> +
>>> + /* 8 bits for each counter,
>>> + * bits [05:01] of a counter to set event type.
>>> + */
>>> + reg_writel((val & ~(0x1f << (((GET_COUNTERID(event)) *
>>> + event_shift) + 1))) |
>>> + (GET_EVENTID(event) <<
>>> + (((GET_COUNTERID(event)) * event_shift) + 1)),
>>> + hwc->config_base);
>>
>> This would be far more legible if val were constructed before the
>> reg_writel(), especially if there were a helper for the event field
>> shifting, e.g.
>>
>> #define DMC_EVENT_CFG(idx, val) ((val) << (((idx) * 8) + 1))
>>
>> int id = GET_COUNTERID(event);
>> int event = GET_EVENTID(event);
>>
>> val = reg_readl(hwc->config_base);
>> val &= ~DMC_EVENT_CFG(id, 0x1f);
>> val |= DMCC_EVENT_CFG(id, event);
>> reg_writel(val, hwc->config_base));
>>
>> What are bits 7:6 and 1 used for?
>
> not used/reserved bits.
>
>>
>>> +
>>> + if (flags & PERF_EF_RELOAD) {
>>> + u64 prev_raw_count =
>>> + local64_read(&event->hw.prev_count);
>>> + reg_writel(prev_raw_count, hwc->event_base);
>>> + }
>>> + local64_set(&event->hw.prev_count,
>>> + reg_readl(hwc->event_base));
>>
>>
>> As with the L3C events, it would be simpler to always reprogram the
>> prev_count and HW to zero.
>
> ok
>>
>>> +}
>>> +
>>> +static void uncore_stop_event_l3c(struct perf_event *event)
>>> +{
>>> + reg_writel(0, event->hw.config_base);
>>> +}
>>> +
>>> +static void uncore_stop_event_dmc(struct perf_event *event)
>>> +{
>>> + u32 val, event_shift = 8;
>>> + struct hw_perf_event *hwc = &event->hw;
>>> +
>>> + val = reg_readl(hwc->config_base);
>>> + reg_writel((val & ~(0xff << ((GET_COUNTERID(event)) * event_shift))),
>>> + hwc->config_base);
>>
>>
>> This could be simplified with the helper proposed above.
>
> ok
>>
>>> +}
>>> +
>>> +static void init_cntr_base_l3c(struct perf_event *event,
>>> + struct thunderx2_pmu_uncore_dev *uncore_dev)
>>> +{
>>> +
>>> + struct hw_perf_event *hwc = &event->hw;
>>> +
>>> + /* counter ctrl/data reg offset at 8 */
>>
>> Offset 8, or stride 8?
>
> stride 8
>>
>> What does the register layout look like?
>>
>>> + hwc->config_base = uncore_dev->base
>>> + + L3C_COUNTER_CTL + (8 * GET_COUNTERID(event));
>>> + hwc->event_base = uncore_dev->base
>>> + + L3C_COUNTER_DATA + (8 * GET_COUNTERID(event));
>>> +}
>>> +
>>> +static void init_cntr_base_dmc(struct perf_event *event,
>>> + struct thunderx2_pmu_uncore_dev *uncore_dev)
>>> +{
>>> +
>>> + struct hw_perf_event *hwc = &event->hw;
>>> +
>>> + hwc->config_base = uncore_dev->base
>>> + + DMC_COUNTER_CTL;
>>> + /* counter data reg offset at 0xc */
>>
>> A stride of 0xc seems unusual.
>>
>> What does the register layout look like?
>
> the offsets are at 0x640, 0x64c, 0x658, 0x664,
>>
>>> + hwc->event_base = uncore_dev->base
>>> + + DMC_COUNTER_DATA + (0xc * GET_COUNTERID(event));
>>> +}
>>> +
>>> +static void thunderx2_uncore_update(struct perf_event *event)
>>> +{
>>> + s64 prev, new = 0;
>>> + u64 delta;
>>> + struct hw_perf_event *hwc = &event->hw;
>>> + struct thunderx2_pmu_uncore_channel *pmu_uncore;
>>> + enum thunderx2_uncore_type type;
>>> +
>>> + pmu_uncore = pmu_to_thunderx2_pmu_uncore(event->pmu);
>>> + type = pmu_uncore->uncore_dev->type;
>>
>> AFAICT this variable is not used below.
>
> thanks.
>>
>>> +
>>> + if (pmu_uncore->uncore_dev->select_channel)
>>> + pmu_uncore->uncore_dev->select_channel(event);
>>
>> This should always be non-NULL, right?
>
> yes, unwanted check at the moment, will remove.
>
>>
>> [...]
>>
>>> +static bool thunderx2_uncore_validate_event_group(struct perf_event *event)
>>> +{
>>> + struct pmu *pmu = event->pmu;
>>> + struct perf_event *leader = event->group_leader;
>>> + struct perf_event *sibling;
>>> + int counters = 0;
>>> +
>>> + if (leader->pmu != event->pmu && !is_software_event(leader))
>>> + return false;
>>> +
>>> + counters++;
>>
>> I don't think this is right when event != leader and the leader is a SW
>> event. In that case, the leader doesn't take a HW counter.
>
> I think this check to avoid the grouping of multiple hw PMUs ,
> however it is allowed to group sw events along with hw PMUs.
>
>>
>>> +
>>> + for_each_sibling_event(sibling, event->group_leader) {
>>> + if (is_software_event(sibling))
>>> + continue;
>>> + if (sibling->pmu != pmu)
>>> + return false;
>>> + counters++;
>>> + }
>>> +
>>> + /*
>>> + * If the group requires more counters than the HW has,
>>> + * it cannot ever be scheduled.
>>> + */
>>> + return counters <= UNCORE_MAX_COUNTERS;
>>> +}
>>
>> [...]
>>
>>> +static int thunderx2_uncore_event_init(struct perf_event *event)
>>> +{
>>> + struct hw_perf_event *hwc = &event->hw;
>>> + struct thunderx2_pmu_uncore_channel *pmu_uncore;
>>
>>> + pmu_uncore = pmu_to_thunderx2_pmu_uncore(event->pmu);
>>> +
>>> + if (!pmu_uncore)
>>> + return -ENODEV;
>>
>> This cannot happen, given pmu_to_thunderx2_pmu_uncore() is a wrapper
>> around container_of().
>
> thanks, unnecessary check!
>>
>>> +
>>> + /* Pick first online cpu from the node */
>>> + event->cpu = cpumask_first(
>>> + cpumask_of_node(pmu_uncore->uncore_dev->node));
>>
>> I don't believe this is safe. You must keep track of which CPU is
>> managing the PMU, with hotplug callbacks.
>
> ok, will add callbacks.
>>
>> [...]
>>
>>> +static void thunderx2_uncore_start(struct perf_event *event, int flags)
>>> +{
>>> + struct hw_perf_event *hwc = &event->hw;
>>> + struct thunderx2_pmu_uncore_channel *pmu_uncore;
>>> + struct thunderx2_pmu_uncore_dev *uncore_dev;
>>> + unsigned long irqflags;
>>> + struct active_timer *active_timer;
>>> +
>>> + hwc->state = 0;
>>> + pmu_uncore = pmu_to_thunderx2_pmu_uncore(event->pmu);
>>> + uncore_dev = pmu_uncore->uncore_dev;
>>> +
>>> + raw_spin_lock_irqsave(&uncore_dev->lock, irqflags);
>>> +
>>> + if (uncore_dev->select_channel)
>>> + uncore_dev->select_channel(event);
>>> + uncore_dev->start_event(event, flags);
>>> + raw_spin_unlock_irqrestore(&uncore_dev->lock, irqflags);
>>> +
>>> + perf_event_update_userpage(event);
>>> + active_timer = &pmu_uncore->active_timers[GET_COUNTERID(event)];
>>> + active_timer->event = event;
>>> +
>>> + hrtimer_start(&active_timer->hrtimer,
>>> + ns_to_ktime(uncore_dev->hrtimer_interval),
>>> + HRTIMER_MODE_REL_PINNED);
>>> +}
>>
>> Please use a single hrtimer, and update *all* of the events when it
>> fires.
>
> sure
>>
>> I *think* that can be done in the pmu::pmu_enable() and
>> pmu::pmu_disable() callbacks.
>
> ok
>>
>> Are there control bits to enable/disable all counters, or can that only
>> be done through the event configuration registers?
>
> only through config register.
>>
>>> +static void thunderx2_uncore_stop(struct perf_event *event, int flags)
>>> +{
>>> + struct hw_perf_event *hwc = &event->hw;
>>> + struct thunderx2_pmu_uncore_channel *pmu_uncore;
>>> + struct thunderx2_pmu_uncore_dev *uncore_dev;
>>> + unsigned long irqflags;
>>> +
>>> + if (hwc->state & PERF_HES_UPTODATE)
>>> + return;
>>> +
>>> + pmu_uncore = pmu_to_thunderx2_pmu_uncore(event->pmu);
>>> + uncore_dev = pmu_uncore->uncore_dev;
>>> +
>>> + raw_spin_lock_irqsave(&uncore_dev->lock, irqflags);
>>> +
>>> + if (uncore_dev->select_channel)
>>> + uncore_dev->select_channel(event);
>>
>> AFAICT this cannot be NULL.
>
> ok.
>>
>> [...]
>>
>>> +static int thunderx2_pmu_uncore_register(
>>> + struct thunderx2_pmu_uncore_channel *pmu_uncore)
>>> +{
>>> + struct device *dev = pmu_uncore->uncore_dev->dev;
>>> + char *name = pmu_uncore->uncore_dev->name;
>>> + int channel = pmu_uncore->channel;
>>> +
>>> + /* Perf event registration */
>>> + pmu_uncore->pmu = (struct pmu) {
>>> + .attr_groups = pmu_uncore->uncore_dev->attr_groups,
>>> + .task_ctx_nr = perf_invalid_context,
>>> + .event_init = thunderx2_uncore_event_init,
>>> + .add = thunderx2_uncore_add,
>>> + .del = thunderx2_uncore_del,
>>> + .start = thunderx2_uncore_start,
>>> + .stop = thunderx2_uncore_stop,
>>> + .read = thunderx2_uncore_read,
>>> + };
>>> +
>>> + pmu_uncore->pmu.name = devm_kasprintf(dev, GFP_KERNEL,
>>> + "%s_%d", name, channel);
>>
>> Does the channel idx take the NUMA node into account?
>
> name already has node id suffix.
>>
>> [...]
>>
>>> +static int thunderx2_pmu_uncore_add(struct thunderx2_pmu_uncore_dev *uncore_dev,
>>> + int channel)
>>> +{
>>
>>> + /* we can run up to (max_counters * max_channels) events
>>> + * simultaneously, allocate hrtimers per channel.
>>> + */
>>> + pmu_uncore->active_timers = devm_kzalloc(uncore_dev->dev,
>>> + sizeof(struct active_timer) * uncore_dev->max_counters,
>>> + GFP_KERNEL);
>>
>> Please just fold a single hrtimer into the thunderx2_pmu_uncore_channel
>> structure, and you can get rid of this allocation...
>
> sure, i will rewrite code to have timer per channel and all active
> counters are updated when timer fires.
>
>>
>>> +
>>> + for (counter = 0; counter < uncore_dev->max_counters; counter++) {
>>> + hrtimer_init(&pmu_uncore->active_timers[counter].hrtimer,
>>> + CLOCK_MONOTONIC,
>>> + HRTIMER_MODE_REL);
>>> + pmu_uncore->active_timers[counter].hrtimer.function =
>>> + thunderx2_uncore_hrtimer_callback;
>>> + }
>>
>> ... and simplify this initialization.
>
> ok
>>
>> [...]
>>
>>> +static struct thunderx2_pmu_uncore_dev *init_pmu_uncore_dev(
>>> + struct device *dev, acpi_handle handle,
>>> + struct acpi_device *adev, u32 type)
>>> +{
>>> + struct thunderx2_pmu_uncore_dev *uncore_dev;
>>> + unsigned long base;
>>
>>> + base = (unsigned long)devm_ioremap_resource(dev, &res);
>>> + if (IS_ERR((void *)base)) {
>>> + dev_err(dev, "PMU type %d: Fail to map resource\n", type);
>>> + return NULL;
>>> + }
>>
>> Please treat this as a void __iomem *base.
>
> ok
>>
>> [...]
>>
>>> +static int thunderx2_uncore_probe(struct platform_device *pdev)
>>> +{
>>> + struct device *dev = &pdev->dev;
>>> + struct arm_smccc_res res;
>>> +
>>> + set_dev_node(dev, acpi_get_node(ACPI_HANDLE(dev)));
>>> +
>>> + /* Make sure firmware supports DMC/L3C set channel smc call */
>>> + arm_smccc_smc(THUNDERX2_SMC_CALL_ID, THUNDERX2_SMC_SET_CHANNEL,
>>> + dev_to_node(dev), 0, 0, 0, 0, 0, &res);
>>> + if (res.a0) {
>>> + dev_err(dev, "No Firmware support for PMU UNCORE(%d)\n",
>>> + dev_to_node(dev));
>>> + return -ENODEV;
>>> + }
>>
>> Please re-use the uncore_select_channel() wrapper rather than
>> open-coding this.
>
> ok.
>>
>> Which FW supports this interface?
>
> it is through vendor specific ATF runtime services.
>>
>> Thanks,
>> Mark.
>
> thanks,
> Ganapat
thanks
Ganapat
^ permalink raw reply
* [RFC PATCH 00/10] Add persistent clock support
From: Daniel Lezcano @ 2018-05-15 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526285602.git.baolin.wang@linaro.org>
On Mon, May 14, 2018 at 04:55:26PM +0800, Baolin Wang wrote:
> Hi,
>
> We will meet below issues when compensating the suspend time for the timekeeping.
>
> 1. We have too many different ways of dealing with persistent timekeeping
> across architectures, so it is hard for one driver to compatable with different
> architectures.
>
> 2. On some platforms (such as Spreadtrum platform), we registered the high
> resolution timer as one clocksource to update the OS time, but the high
> resolution timer will be stopped in suspend state. So we use another one
> always-on timer (but low resolution) to calculate the suspend time to
> compensate the OS time. Though we can register the always-on timer as one
> clocksource, we need re-calculate the mult/shift with one larger conversion
> range to calculate the suspend time and need update the clock in case of
> running over the always-on timer.
First, can you elaborate what you mean by 'suspend state' ? On which power
domain the clocksource belongs to?
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 0/4] KVM: arm/arm64: Fix locking issues
From: Christoffer Dall @ 2018-05-15 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511142015.21953-1-andre.przywara@arm.com>
On Fri, May 11, 2018 at 03:20:11PM +0100, Andre Przywara wrote:
> Jan recently reported lockdep complaints regarding various locks in our
> VGIC emulation [1][2].
> This boiled down to two separate issues:
> - When promoting the vgic_irq->irq_lock to require IRQs being disabled,
> we forgot to amend some instances of this lock on the way. Also this
> needs to be applied to dependent locks as well. The first two patches
> fix that. The patch split is designed to simplify backporting.
> Those patches have been posted before, I am resending them as part
> of this series.
> - Calling kvm_read_guest() requires us to be inside an SRCU critical
> section. On some architectures we are always in it when handling VCPU
> exits, but on ARM we need to lock it individually. Patches 3 and 4
> fix that, the split is again made to ease backporting.
> Each of the hunks fix an indiviual commit, but I refrained from
> splitting this down into eight patches just to put proper Fixes: tags
> on it. Eventually those commits are part of one out of two series, I put
> the respective kernel release version as a tag to the Cc: stable line.
>
> I couldn't reproduce the full lockdep splat on my setup, but at least
> could show one instance and prove that these patches fixes that.
>
>
For the series:
Acked-by: Christoffer Dall <christoffer.dall@arm.com>
Thanks for fixing this,
-Christoffer
^ permalink raw reply
* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Daniel Vetter @ 2018-05-15 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <73fa1ca3-28e4-96c5-1fc6-23e9c0cebb49@axentia.se>
On Mon, May 14, 2018 at 10:40 PM, Peter Rosin <peda@axentia.se> wrote:
> On 2018-05-14 18:28, Daniel Vetter wrote:
>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
>>> On 2018-05-10 10:10, Andrzej Hajda wrote:
>>>> On 04.05.2018 15:52, Peter Rosin wrote:
>>>>> If the bridge supplier is unbound, this will bring the bridge consumer
>>>>> down along with the bridge. Thus, there will no longer linger any
>>>>> dangling pointers from the bridge consumer (the drm_device) to some
>>>>> non-existent bridge supplier.
>>>>>
>>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>>>> ---
>>>>> drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
>>>>> include/drm/drm_bridge.h | 2 ++
>>>>> 2 files changed, 20 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>>>> index 78d186b6831b..0259f0a3ff27 100644
>>>>> --- a/drivers/gpu/drm/drm_bridge.c
>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>>>> @@ -26,6 +26,7 @@
>>>>> #include <linux/mutex.h>
>>>>>
>>>>> #include <drm/drm_bridge.h>
>>>>> +#include <drm/drm_device.h>
>>>>> #include <drm/drm_encoder.h>
>>>>>
>>>>> #include "drm_crtc_internal.h"
>>>>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
>>>>> if (bridge->dev)
>>>>> return -EBUSY;
>>>>>
>>>>> + if (encoder->dev->dev != bridge->odev) {
>>>>
>>>> I wonder why device_link_add does not handle this case (self dependency)
>>>> silently as noop, as it seems to be a correct behavior.
>>>
>>> It's kind-of a silly corner-case though, so perfectly understandable
>>> that it isn't handled.
>>>
>>>>> + bridge->link = device_link_add(encoder->dev->dev,
>>>>> + bridge->odev, 0);
>>>>> + if (!bridge->link) {
>>>>> + dev_err(bridge->odev, "failed to link bridge to %s\n",
>>>>> + dev_name(encoder->dev->dev));
>>>>> + return -EINVAL;
>>>>> + }
>>>>> + }
>>>>> +
>>>>> bridge->dev = encoder->dev;
>>>>> bridge->encoder = encoder;
>>>>>
>>>>> if (bridge->funcs->attach) {
>>>>> ret = bridge->funcs->attach(bridge);
>>>>> if (ret < 0) {
>>>>> + if (bridge->link)
>>>>> + device_link_del(bridge->link);
>>>>> + bridge->link = NULL;
>>>>> bridge->dev = NULL;
>>>>> bridge->encoder = NULL;
>>>>> return ret;
>>>>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>>>>> if (bridge->funcs->detach)
>>>>> bridge->funcs->detach(bridge);
>>>>>
>>>>> + if (bridge->link)
>>>>> + device_link_del(bridge->link);
>>>>> + bridge->link = NULL;
>>>>> +
>>>>> bridge->dev = NULL;
>>>>> }
>>>>>
>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>>>> index b656e505d11e..804189c63a4c 100644
>>>>> --- a/include/drm/drm_bridge.h
>>>>> +++ b/include/drm/drm_bridge.h
>>>>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>>>>> * @list: to keep track of all added bridges
>>>>> * @timings: the timing specification for the bridge, if any (may
>>>>> * be NULL)
>>>>> + * @link: drm consumer <-> bridge supplier
>>>>
>>>> Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
>>>> to the bridge" would be better.
>>>
>>> I meant "<->" to indicate that the link is bidirectional, not that the
>>> relationship is in any way symmetric. I wasn't aware of any implication
>>> of a symmetric relationship when using "<->", do you have a reference?
>>> But I guess the different arrow notations in math are somewhat overloaded
>>> and that someone at some point must have used "<->" to indicate a
>>> symmetric relationship...
>>
>> Yeah I agree with Andrzej here, for me <-> implies a symmetric
>> relationship. Spelling it out like Andrzej suggested sounds like the
>> better idea.
>> -Daniel
>
> Ok, I guess that means I have to do a v3 after all. Or can this
> trivial documentation update be done by the committer? I hate to
> spam everyone with another volley...
>
> Or perhaps I should squash patches 2-23 that are all rather similar
> and mechanic? I separated them to allow for easier review from
> individual driver maintainers, but that didn't seem to happen
> anyway...
Do another volley of the full set, or in-reply-to to just replace the
patch that needs to be respun (but some people don't like that).
When resending just make sure you're picking up all the acks/r-bs you
have already.
-Daniel
> Cheers,
> Peter
>
>>
>>>
>>>> Anyway:
>>>> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
>>>
>>> Thanks!
>>>
>>> Cheers,
>>> Peter
>>>
>>>> --
>>>> Regards
>>>> Andrzej
>>>>
>>>>> * @funcs: control functions
>>>>> * @driver_private: pointer to the bridge driver's internal context
>>>>> */
>>>>> @@ -271,6 +272,7 @@ struct drm_bridge {
>>>>> struct drm_bridge *next;
>>>>> struct list_head list;
>>>>> const struct drm_bridge_timings *timings;
>>>>> + struct device_link *link;
>>>>>
>>>>> const struct drm_bridge_funcs *funcs;
>>>>> void *driver_private;
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH] ARM: dts: berlin2q: move PMU node from soc to root
From: Jisheng Zhang @ 2018-05-15 10:19 UTC (permalink / raw)
To: linux-arm-kernel
Fix "make dtbs W=1" warns about missing reg or ranges property.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
arch/arm/boot/dts/berlin2q.dtsi | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 82e176011d36..c1bf23a4412b 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -62,6 +62,18 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>,
+ <&cpu1>,
+ <&cpu2>,
+ <&cpu3>;
+ };
+
refclk: oscillator {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -76,18 +88,6 @@
ranges = <0 0xf7000000 0x1000000>;
interrupt-parent = <&gic>;
- pmu {
- compatible = "arm,cortex-a9-pmu";
- interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-affinity = <&cpu0>,
- <&cpu1>,
- <&cpu2>,
- <&cpu3>;
- };
-
sdhci0: sdhci at ab0000 {
compatible = "mrvl,pxav3-mmc";
reg = <0xab0000 0x200>;
--
2.17.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: berlin*-dts: use SPDX-License-Identifier for berlin based board
From: Jisheng Zhang @ 2018-05-15 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515181216.6d82f7fc@xhacker.debian>
Follow the recent trend for the license description, and also fix the
wrongly stated X11 to MIT.
As already pointed on the DT ML, the X11 license text [1] is explicitly
for the X Consortium and has a couple of extra clauses. The MIT
license text [2] is actually what the current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts | 33 +------------------
.../boot/dts/berlin2cd-google-chromecast.dts | 33 +------------------
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 33 +------------------
3 files changed, 3 insertions(+), 96 deletions(-)
diff --git a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
index 1c475796d17f..64a297759eb9 100644
--- a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
+++ b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
@@ -1,39 +1,8 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/*
* Device Tree file for Sony NSZ-GS7
*
* Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
*/
/dts-v1/;
diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
index ca24def0ce13..540115172d3a 100644
--- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
+++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
@@ -1,39 +1,8 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/*
* Device Tree file for Google Chromecast
*
* Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
*/
/dts-v1/;
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index 57aa5f8a7c77..c162f98cb8e8 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -1,37 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/*
* Copyright (C) 2014 Antoine T?nart <antoine.tenart@free-electrons.com>
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
*/
/dts-v1/;
--
2.17.0
^ permalink raw reply related
* [PATCH 08/18] arm64: convert raw syscall invocation to C
From: Mark Rutland @ 2018-05-15 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515100158.GC14007@isilmar-4.linta.de>
On Tue, May 15, 2018 at 12:01:58PM +0200, Dominik Brodowski wrote:
> On Tue, May 15, 2018 at 09:22:23AM +0100, Mark Rutland wrote:
> > On Mon, May 14, 2018 at 10:24:45PM +0200, Dominik Brodowski wrote:
> > > On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote:
> > > > I agree it would be nicer if it had a wrapper that took a pt_regs, even
> > > > if it does nothing with it.
> > > >
> > > > We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd
> > > > need a ksys_ni_syscall() for our traps.c logic, and adding this
> > > > uniformly would involve some arch-specific rework for x86, too, so I
> > > > decided it was not worth the effort.
> > >
> > > Couldn't you just open-code the "return -ENOSYS;" in traps.c?
> >
> > I guess so. I was just worried that debug logic might be added to the generic
> > ni_syscall() in future, and wanted to avoid potential divergence.
> >
> > > Error injection has no reasonable stable ABI/API expectations, so that's not
> > > a show-stopper either.
> >
> > If people are happy with using SYSCALL_DEFINE0() for ni_syscall, I'm happy to
> > do that -- it's just that we'll need a fixup for x86 as that will change the
> > symbol name.
>
> For me, it's less about using SYSCALL_DEFINE0() for ni_syscall, but more
> about keeping the syscall invokation easy. Therefore, we do pass a pointer
> struct pt_regs to sys_ni_syscall() on x86, even though it does not expect
> it.
>
> /* this is a lie, but it does not hurt as sys_ni_syscall just returns -EINVAL */
> extern asmlinkage long sys_ni_syscall(const struct pt_regs *);
Oh, sure, we do the same on arm64 in this series.
Having a pt_regs wrapper for it (e.g. using SYSCALL_DEFINE0()) would
allow us to avoid that lie (which might be best for CFI stuff), would
allow us to avoid some name mangling on arm64, and would seemingly
confuse people less.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] ARM: dts: berlin*.dtsi: use SPDX-License-Identifier for berlin SoCs
From: Jisheng Zhang @ 2018-05-15 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Follow the recent trend for the license description, and also fix the
wrongly stated X11 to MIT.
As already pointed on the DT ML, the X11 license text [1] is explicitly
for the X Consortium and has a couple of extra clauses. The MIT
license text [2] is actually what the current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
arch/arm/boot/dts/berlin2.dtsi | 33 +-------------------------------
arch/arm/boot/dts/berlin2cd.dtsi | 33 +-------------------------------
arch/arm/boot/dts/berlin2q.dtsi | 33 +-------------------------------
3 files changed, 3 insertions(+), 96 deletions(-)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 787a9d042ad9..db67377af266 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/*
* Device Tree Include file for Marvell Armada 1500 (Berlin BG2) SoC
*
@@ -5,38 +6,6 @@
*
* based on GPL'ed 2.6 kernel sources
* (c) Marvell International Ltd.
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
*/
#include <dt-bindings/clock/berlin2.h>
diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 501c59d97eae..387d02803690 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/*
* Device Tree Include file for Marvell Armada 1500-mini (Berlin BG2CD) SoC
*
@@ -5,38 +6,6 @@
*
* based on GPL'ed 2.6 kernel sources
* (c) Marvell International Ltd.
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
*/
#include <dt-bindings/clock/berlin2.h>
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index f11254e70f57..82e176011d36 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -1,37 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/*
* Copyright (C) 2014 Antoine T?nart <antoine.tenart@free-electrons.com>
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
*/
#include <dt-bindings/clock/berlin2q.h>
--
2.17.0
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: berlin4ct-*.dts: use SPDX-License-Identifier
From: Jisheng Zhang @ 2018-05-15 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515180826.2ab39f0c@xhacker.debian>
Follow the recent trend for the license description, and also fix the
wrongly stated X11 to MIT.
As already pointed on the DT ML, the X11 license text [1] is explicitly
for the X Consortium and has a couple of extra clauses. The MIT
license text [2] is actually what the current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts | 39 +------------------
arch/arm64/boot/dts/marvell/berlin4ct-stb.dts | 39 +------------------
2 files changed, 2 insertions(+), 76 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts b/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts
index fae6c6924705..c64a179ebbb7 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts
+++ b/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts
@@ -1,45 +1,8 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/*
* Copyright (C) 2015 Marvell Technology Group Ltd.
*
* Author: Jisheng Zhang <jszhang@marvell.com>
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPLv2 or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
index d47edad13e68..277dccfa05cb 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
+++ b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
@@ -1,45 +1,8 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/*
* Copyright (C) 2015 Marvell Technology Group Ltd.
*
* Author: Jisheng Zhang <jszhang@marvell.com>
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPLv2 or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
*/
/dts-v1/;
--
2.17.0
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: berlin4ct: use SPDX-License-Identifier
From: Jisheng Zhang @ 2018-05-15 10:08 UTC (permalink / raw)
To: linux-arm-kernel
Follow the recent trend for the license description, and also fix the
wrongly stated X11 to MIT.
As already pointed on the DT ML, the X11 license text [1] is explicitly
for the X Consortium and has a couple of extra clauses. The MIT
license text [2] is actually what the current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 39 +---------------------
1 file changed, 1 insertion(+), 38 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
index d2f88b92d8e2..216767e2edf6 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
+++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
@@ -1,45 +1,8 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/*
* Copyright (C) 2015 Marvell Technology Group Ltd.
*
* Author: Jisheng Zhang <jszhang@marvell.com>
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPLv2 or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
--
2.17.0
^ permalink raw reply related
* [PATCH v4 6/8] PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources()
From: Vladimir Zapolskiy @ 2018-05-15 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3aeb2ed038cbce8fe744b614dc19d414555a7e8f.1526375226.git.jan.kiszka@siemens.com>
On 05/15/2018 12:07 PM, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> of_pci_get_host_bridge_resources() allocates the resource structures it
> fills dynamically, but none of its callers care to release them so far.
> Rather than requiring everyone to do this explicitly, convert the
> existing function to a managed version.
>
> CC: Jingoo Han <jingoohan1@gmail.com>
> CC: Joao Pinto <Joao.Pinto@synopsys.com>
> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Now it is correct, thanks.
Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v4 5/8] PCI: Replace pr_*() with dev_*() in of_pci_get_host_bridge_resources()
From: Vladimir Zapolskiy @ 2018-05-15 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95f6ca417e2bc74d15f707e577b098e46b4b3ba4.1526375226.git.jan.kiszka@siemens.com>
On 05/15/2018 12:07 PM, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> Now that we have a device reference, make use of it for printing.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v4 4/8] PCI: Replace dev_node parameter of of_pci_get_host_bridge_resources with device
From: Vladimir Zapolskiy @ 2018-05-15 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5f2226585c6af9920b266d0503e32042d4c9e440.1526375226.git.jan.kiszka@siemens.com>
On 05/15/2018 12:07 PM, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> Another step towards a managed version of
> of_pci_get_host_bridge_resources(): Feed in the underlying device,
> rather than just the OF node. This will allow to use managed resource
> allocation internally later on.
>
> CC: Jingoo Han <jingoohan1@gmail.com>
> CC: Joao Pinto <Joao.Pinto@synopsys.com>
> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v4 3/8] PCI: Rename device node parameter of of_pci_get_host_bridge_resources()
From: Vladimir Zapolskiy @ 2018-05-15 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4df503604897aebbcb6e7ab98ef5f24916c6d382.1526375226.git.jan.kiszka@siemens.com>
On 05/15/2018 12:07 PM, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> We will add a real device parameter to this function soon.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH 08/18] arm64: convert raw syscall invocation to C
From: Dominik Brodowski @ 2018-05-15 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515082222.rcoyf6dsf2s2edgq@salmiak>
On Tue, May 15, 2018 at 09:22:23AM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 10:24:45PM +0200, Dominik Brodowski wrote:
> > On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote:
> > > I agree it would be nicer if it had a wrapper that took a pt_regs, even
> > > if it does nothing with it.
> > >
> > > We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd
> > > need a ksys_ni_syscall() for our traps.c logic, and adding this
> > > uniformly would involve some arch-specific rework for x86, too, so I
> > > decided it was not worth the effort.
> >
> > Couldn't you just open-code the "return -ENOSYS;" in traps.c?
>
> I guess so. I was just worried that debug logic might be added to the generic
> ni_syscall() in future, and wanted to avoid potential divergence.
>
> > Error injection has no reasonable stable ABI/API expectations, so that's not
> > a show-stopper either.
>
> If people are happy with using SYSCALL_DEFINE0() for ni_syscall, I'm happy to
> do that -- it's just that we'll need a fixup for x86 as that will change the
> symbol name.
For me, it's less about using SYSCALL_DEFINE0() for ni_syscall, but more
about keeping the syscall invokation easy. Therefore, we do pass a pointer
struct pt_regs to sys_ni_syscall() on x86, even though it does not expect
it.
/* this is a lie, but it does not hurt as sys_ni_syscall just returns -EINVAL */
extern asmlinkage long sys_ni_syscall(const struct pt_regs *);
Thanks,
Dominik
^ permalink raw reply
* [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()
From: Dominik Brodowski @ 2018-05-15 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515095351.lw5gxap4ii5iobtb@lakrids.cambridge.arm.com>
On Tue, May 15, 2018 at 10:53:51AM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 10:34:14PM +0200, Dominik Brodowski wrote:
> > On Mon, May 14, 2018 at 06:14:28PM +0100, Mark Rutland wrote:
> > > On Mon, May 14, 2018 at 10:46:35AM +0100, Mark Rutland wrote:
> > > > +#ifdef CONFIG_COMPAT
> > > > +int kcompat_sys_statfs64(const char __user * pathname, compat_size_t sz,
> > > > + struct compat_statfs64 __user * buf);
> > > > +int kcompat_sys_fstatfs64(unsigned int fd, compat_size_t sz,
> > > > + struct compat_statfs64 __user * buf);
> > > > +#endif
> > >
> > > I've moved these to <linux/compat.h>, so that they live with the rest of
> > > the compat syscall stuff. That should avoid build failures the kbuild
> > > test robot picked up where compat_size_t wasn't dfined.
> >
> > Please add a comment there, similar to what is in syscalls.h:
> >
> > /*
> > * Kernel code should not call syscalls (i.e., sys_xyzyyz()) directly.
> > * Instead, use one of the functions which work equivalently, such as
> > * the ksys_xyzyyz() functions prototyped below.
> > */
>
> To make the kcompat_sys_* naming scheme clearer, I've added compat references to
> the above, i.e.
>
> /*
> * Kernel code should not call compat syscalls (i.e., compat_sys_xyzyyz())
> * directly. Instead, use one of the functions which work equivalently, such
> * as the kcompat_sys_xyzyyz() functions prototyped below.
> */
That's what I meant ;)
> > Once you have done so, feel free to add my
> >
> > Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
>
> I hope that this still stands with the changes above?
It does. Thanks!
Dominik
^ permalink raw reply
* [PATCH 12/18] kernel: add ksys_personality()
From: Mark Rutland @ 2018-05-15 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514120756.GA11638@infradead.org>
On Mon, May 14, 2018 at 05:07:56AM -0700, Christoph Hellwig wrote:
> On Mon, May 14, 2018 at 10:46:34AM +0100, Mark Rutland wrote:
> > Using this helper allows us to avoid the in-kernel call to the
> > sys_personality() syscall. The ksys_ prefix denotes that this function
> > is meant as a drop-in replacement for the syscall. In particular, it
> > uses the same calling convention as sys_personality().
> >
> > This is necessary to enable conversion of arm64's syscall handling to
> > use pt_regs wrappers.
>
> Plese just opencode the trivial sys_personality logic instead.
Sure, I'll make that a static inline in <linux/syscalls.h> as with
ksys_close() and friends.
Thanks,
Mark.
^ permalink raw reply
* [PATCH V5 3/4] soc: mediatek: pwrap: add pwrap driver for mt6797 SoCs
From: Matthias Brugger @ 2018-05-15 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525957319-20557-4-git-send-email-argus.lin@mediatek.com>
On 05/10/2018 03:01 PM, argus.lin at mediatek.com wrote:
> From: Argus Lin <argus.lin@mediatek.com>
>
> mt6797 is a highly integrated SoCs, it uses mt6351 for power management.
> We need to add pwrap driver to access mt6351. Pwrap of mt6797 support
> dynamic priority meichanism, sequence monitor and starvation mechanism
> to make transaction more reliable.
>
This is drivers differs vastly from V4, but I can't find any explanation why.
Can you please elaborate. For the record the explanation should have been done
in the cover letter.
Thanks,
Matthias
> ---
> drivers/soc/mediatek/mtk-pmic-wrap.c | 50 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index 9a01e30..d03e2d4 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -366,6 +366,39 @@ enum pwrap_regs {
> [PWRAP_ADC_RDATA_ADDR2] = 0x154,
> };
>
> +static int mt6797_regs[] = {
> + [PWRAP_MUX_SEL] = 0x0,
> + [PWRAP_WRAP_EN] = 0x4,
> + [PWRAP_DIO_EN] = 0x8,
> + [PWRAP_SIDLY] = 0xC,
> + [PWRAP_RDDMY] = 0x10,
> + [PWRAP_CSHEXT_WRITE] = 0x18,
> + [PWRAP_CSHEXT_READ] = 0x1C,
> + [PWRAP_CSLEXT_START] = 0x20,
> + [PWRAP_CSLEXT_END] = 0x24,
> + [PWRAP_STAUPD_PRD] = 0x28,
> + [PWRAP_HARB_HPRIO] = 0x50,
> + [PWRAP_HIPRIO_ARB_EN] = 0x54,
> + [PWRAP_MAN_EN] = 0x60,
> + [PWRAP_MAN_CMD] = 0x64,
> + [PWRAP_WACS0_EN] = 0x70,
> + [PWRAP_WACS1_EN] = 0x84,
> + [PWRAP_WACS2_EN] = 0x98,
> + [PWRAP_INIT_DONE2] = 0x9C,
> + [PWRAP_WACS2_CMD] = 0xA0,
> + [PWRAP_WACS2_RDATA] = 0xA4,
> + [PWRAP_WACS2_VLDCLR] = 0xA8,
> + [PWRAP_INT_EN] = 0xC0,
> + [PWRAP_INT_FLG_RAW] = 0xC4,
> + [PWRAP_INT_FLG] = 0xC8,
> + [PWRAP_INT_CLR] = 0xCC,
> + [PWRAP_TIMER_EN] = 0xF4,
> + [PWRAP_WDT_UNIT] = 0xFC,
> + [PWRAP_WDT_SRC_EN] = 0x100,
> + [PWRAP_DCM_EN] = 0x1CC,
> + [PWRAP_DCM_DBC_PRD] = 0x1D4,
> +};
> +
> static int mt7622_regs[] = {
> [PWRAP_MUX_SEL] = 0x0,
> [PWRAP_WRAP_EN] = 0x4,
> @@ -641,6 +674,7 @@ enum pmic_type {
>
> enum pwrap_type {
> PWRAP_MT2701,
> + PWRAP_MT6797,
> PWRAP_MT7622,
> PWRAP_MT8135,
> PWRAP_MT8173,
> @@ -1067,6 +1101,7 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
> pwrap_writel(wrp, 1, PWRAP_CIPHER_START);
> break;
> case PWRAP_MT2701:
> + case PWRAP_MT6797:
> case PWRAP_MT8173:
> pwrap_writel(wrp, 1, PWRAP_CIPHER_EN);
> break;
> @@ -1396,6 +1431,18 @@ static irqreturn_t pwrap_interrupt(int irqno, void *dev_id)
> .init_soc_specific = pwrap_mt2701_init_soc_specific,
> };
>
> +static const struct pmic_wrapper_type pwrap_mt6797 = {
> + .regs = mt6797_regs,
> + .type = PWRAP_MT6797,
> + .arb_en_all = 0x01fff,
> + .int_en_all = 0xffffffc6,
> + .spi_w = PWRAP_MAN_CMD_SPI_WRITE,
> + .wdt_src = PWRAP_WDT_SRC_MASK_ALL,
> + .has_bridge = 0,
> + .init_reg_clock = pwrap_common_init_reg_clock,
> + .init_soc_specific = NULL,
> +};
> +
> static const struct pmic_wrapper_type pwrap_mt7622 = {
> .regs = mt7622_regs,
> .type = PWRAP_MT7622,
> @@ -1437,6 +1484,9 @@ static irqreturn_t pwrap_interrupt(int irqno, void *dev_id)
> .compatible = "mediatek,mt2701-pwrap",
> .data = &pwrap_mt2701,
> }, {
> + .compatible = "mediatek,mt6797-pwrap",
> + .data = &pwrap_mt6797,
> + }, {
> .compatible = "mediatek,mt7622-pwrap",
> .data = &pwrap_mt7622,
> }, {
> --
> 1.8.1.1.dirty
>
> ************* Email Confidentiality Notice
> ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
>
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank
> you!
>
^ permalink raw reply
* [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()
From: Mark Rutland @ 2018-05-15 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514203414.GB26773@light.dominikbrodowski.net>
On Mon, May 14, 2018 at 10:34:14PM +0200, Dominik Brodowski wrote:
> On Mon, May 14, 2018 at 06:14:28PM +0100, Mark Rutland wrote:
> > On Mon, May 14, 2018 at 10:46:35AM +0100, Mark Rutland wrote:
> > > +#ifdef CONFIG_COMPAT
> > > +int kcompat_sys_statfs64(const char __user * pathname, compat_size_t sz,
> > > + struct compat_statfs64 __user * buf);
> > > +int kcompat_sys_fstatfs64(unsigned int fd, compat_size_t sz,
> > > + struct compat_statfs64 __user * buf);
> > > +#endif
> >
> > I've moved these to <linux/compat.h>, so that they live with the rest of
> > the compat syscall stuff. That should avoid build failures the kbuild
> > test robot picked up where compat_size_t wasn't dfined.
>
> Please add a comment there, similar to what is in syscalls.h:
>
> /*
> * Kernel code should not call syscalls (i.e., sys_xyzyyz()) directly.
> * Instead, use one of the functions which work equivalently, such as
> * the ksys_xyzyyz() functions prototyped below.
> */
To make the kcompat_sys_* naming scheme clearer, I've added compat references to
the above, i.e.
/*
* Kernel code should not call compat syscalls (i.e., compat_sys_xyzyyz())
* directly. Instead, use one of the functions which work equivalently, such
* as the kcompat_sys_xyzyyz() functions prototyped below.
*/
> Once you have done so, feel free to add my
>
> Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
I hope that this still stands with the changes above?
Thanks,
Mark.
^ permalink raw reply
* [PATCH V5 2/4] soc: mediatek: pwrap: fix cipher init setting error
From: Matthias Brugger @ 2018-05-15 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525957319-20557-3-git-send-email-argus.lin@mediatek.com>
On 05/10/2018 03:01 PM, argus.lin at mediatek.com wrote:
> From: Argus Lin <argus.lin@mediatek.com>
>
> PWRAP_DEW_CIPHER_LOAD and PWRAP_DEW_CIPHER_START only exist at
> PMIC_mt6397 datasheet. We fix it before merge PMIC_mt6351 driver.
>
> Fixes: 5ae48040aa47 ("soc: mediatek: PMIC wrap: add mt6323 slave support")
Same here, you forgot Signed-off-by tag.
> ---
> drivers/soc/mediatek/mtk-pmic-wrap.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index e9e054a..9a01e30 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -1080,8 +1080,6 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
> pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_SWRST], 0x0);
> pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_KEY_SEL], 0x1);
> pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_IV_SEL], 0x2);
> - pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_LOAD], 0x1);
> - pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_START], 0x1);
>
> switch (wrp->slave->type) {
> case PMIC_MT6397:
> --
> 1.8.1.1.dirty
>
> ************* Email Confidentiality Notice ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
>
^ 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