* Re: [PATCH v2 0/6] PAXB INTx support with proper model
From: Florian Fainelli @ 2019-09-04 17:16 UTC (permalink / raw)
To: Srinath Mannam, Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring,
Mark Rutland, Andy Shevchenko, Arnd Bergmann
Cc: linux-pci, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel, devicetree
In-Reply-To: <1566982488-9673-1-git-send-email-srinath.mannam@broadcom.com>
On 8/28/19 1:54 AM, Srinath Mannam wrote:
> This patch series adds PCIe legacy interrupt (INTx) support to the iProc
> PCIe driver by modeling it with its own IRQ domain. All 4 interrupts INTA,
> INTB, INTC, INTD share the same interrupt line connected to the GIC
> in the system. This is now modeled by using its own IRQ domain.
>
> Also update all relevant devicetree files to adapt to the new model.
>
> This patch set is based on Linux-5.2-rc4.
>
> Changes from v1:
> - Addressed Rob, Lorenzo, Arnd's comments
> - Used child node for interrupt controller.
> - Addressed Andy Shevchenko's comments
> - Replaced while loop with do-while.
Lorenzo, Bjorn, if you are good with the binding and PCI host driver
changes, you can take patches 1-2 through your tree, and I will queue up
the others through the Broadcom ARM SoC pull requests. If not, please
feel free to add a:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Ray Jui (6):
> dt-bindings: pci: Update iProc PCI binding for INTx support
> PCI: iproc: Add INTx support with better modeling
> arm: dts: Change PCIe INTx mapping for Cygnus
> arm: dts: Change PCIe INTx mapping for NSP
> arm: dts: Change PCIe INTx mapping for HR2
> arm64: dts: Change PCIe INTx mapping for NS2
>
> .../devicetree/bindings/pci/brcm,iproc-pcie.txt | 48 ++++++++--
> arch/arm/boot/dts/bcm-cygnus.dtsi | 30 ++++++-
> arch/arm/boot/dts/bcm-hr2.dtsi | 30 ++++++-
> arch/arm/boot/dts/bcm-nsp.dtsi | 45 ++++++++--
> arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 28 +++++-
> drivers/pci/controller/pcie-iproc.c | 100 ++++++++++++++++++++-
> drivers/pci/controller/pcie-iproc.h | 6 ++
> 7 files changed, 260 insertions(+), 27 deletions(-)
>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 2/3] Broadcom defconfig-arm64 changes for 5.4
From: Stefan Wahren @ 2019-09-04 17:06 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: Stefan Wahren, Kevin Hilman, arm-soc, bcm-kernel-feedback-list,
Nicolas Saenz Julienne, Olof Johansson, Linux ARM
In-Reply-To: <CAK8P3a2XbU0s0S7wsX5s+UDNc5tfDkqs2KZw+7qXNZ5RuYW8MA@mail.gmail.com>
Hi Arnd,
Am 04.09.19 um 15:02 schrieb Arnd Bergmann:
> On Mon, Aug 19, 2019 at 9:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>>
>> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>>
>> are available in the Git repository at:
>>
>> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.4/defconfig-arm64
>>
>> for you to fetch changes up to d6cc9ddd23f8b113797152896462b27e2b213ece:
>>
>> Merge tag 'tags/bcm2835-defconfig-64-next-2019-08-15' into defconfig-arm64/next (2019-08-15 11:38:29 -0700)
>>
>> ----------------------------------------------------------------
>> This pull request contains Broadcom ARM64-based SoCs defconfig updates
>> for 5.4, please pull the following:
>>
>> - Nicolas enables the Raspberry Pi CPUFREQ driver in the ARM64 defconfig file
> Pulled into arm/defconfig.
>
> The way we work at the moment, there is no real need to split changes
> to the arm32 and arm64 defconfig files into separate pull requests or even
> separate patches.
this is new to me. My understanding was to separate all changes between
arm32 and arm64 changes.
So this isn't necessary for the DT arm/arm64 changes, too?
> Since this is the same change as the previous pull
> request, having a single patch to enable cpufreq everywhere would have
> been easier.
>
> Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] net: phy: gmii2rgmii: Dont use priv field in phy device
From: Florian Fainelli @ 2019-09-04 17:11 UTC (permalink / raw)
To: Harini Katakam, andrew, hkallweit1, davem
Cc: netdev, radhey.shyam.pandey, michal.simek, harinikatakamlinux,
linux-kernel, linux-arm-kernel
In-Reply-To: <1567605621-6818-3-git-send-email-harini.katakam@xilinx.com>
On 9/4/19 7:00 AM, Harini Katakam wrote:
> Use set/get drv data in phydev's mdio device instead. Phy device priv
> field maybe used by the external phy driver and should not be
> overwritten.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 1/3] Broadcom defconfig changes for 5.4
From: Florian Fainelli @ 2019-09-04 17:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stefan Wahren, Kevin Hilman, arm-soc, bcm-kernel-feedback-list,
Stefan Wahren, Olof Johansson, Nicolas Saenz Julienne, Linux ARM
In-Reply-To: <CAK8P3a2mWkW_R7Dqd5nJgd=phEF2YLzkTO7JsD9dLYcF9zF6iQ@mail.gmail.com>
On 9/4/19 5:59 AM, Arnd Bergmann wrote:
> On Mon, Aug 19, 2019 at 9:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>>
>> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>>
>> are available in the Git repository at:
>>
>> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.4/defconfig
>>
>> for you to fetch changes up to c474106e1e8a8f335b1bd3e79e868943689ae74d:
>>
>> Merge tag 'tags/bcm2835-defconfig-next-2019-08-15' into defconfig/next (2019-08-15 11:37:54 -0700)
>>
>> ----------------------------------------------------------------
>> This pull request contains Broadcom ARM-based SoCs defconfig updates for
>> 5.4, please pull the following:
>>
>> - Nicolas enables the Raspberry Pi CPUFREQ driver in both
>> bcm2835_defconfig and multi_v7_defconfig
>
> Pulled into arm/defconfig now.
>
> Please remember to use the new soc@kernel.org address as recipient for
> pull requests in the future to make it work with the patchwork at
> https://patchwork.kernel.org/project/linux-soc/list/
Oh yes, thanks, I updated my script to included that address now.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/1] arm64: dts: qcom: Add Lenovo Yoga C630
From: Lee Jones @ 2019-09-04 17:07 UTC (permalink / raw)
To: Sudeep Holla
Cc: mark.rutland, devicetree, linux-arm-msm, linux-kernel, robh+dt,
bjorn.andersson, agross, linux-arm-kernel
In-Reply-To: <20190904165246.GA25356@bogus>
On Wed, 04 Sep 2019, Sudeep Holla wrote:
> On Wed, Sep 04, 2019 at 05:12:47PM +0100, Lee Jones wrote:
> > On Wed, 04 Sep 2019, Sudeep Holla wrote:
> >
> > > On Wed, Sep 04, 2019 at 01:16:06PM +0100, Lee Jones wrote:
> > > > From: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > >
> > > > The Lenovo Yoga C630 is built on the SDM850 from Qualcomm, but this seem
> > > > to be similar enough to the SDM845 that we can reuse the sdm845.dtsi.
> > > >
> > > > Supported by this patch is: keyboard, battery monitoring, UFS storage,
> > > > USB host and Bluetooth.
> > > >
> > >
> > > Just curious to know if the idea of booting using ACPI is completely
> > > dropped as it's extremely difficult(because the firmware is so hacked
> > > up and may violate spec, just my opinion) for whatever reasons.
> >
> > Once [0] is applied, we can boot Mainline using ACPI.
> >
>
> Good to know.
>
> > > We just made ACPI table version checking more lenient for this platform
> > > and would be good to know if we continue to run ACPI on that or will
> > > abandon and just use DT.
> >
> > Which patch are you referring to? If you mean the ACPI v5.0 vs v5.1
> > patch authored by Ard, then yes I know, I instigated it's existence
> > due to these devices.
> >
>
> Yes exactly that one.
>
> > DT will *always* be more enabled than ACPI, so it's advised that you
> > use DT for anything useful. ACPI booting is ideal for things like
> > installing distros however, since they do not tend to provide DTBs in
> > their installers.
>
> OK, as along as it gets tested/used in some form, that's fine. I do agree
> that DT will be more useful on that platform as it was derived from mobile
> based SoC SDM845 rather than solely designed for Laptops and with more
> alignment with ACPI spec. The way whole power/clock management is done
> with ACPI on this pulls me towards DT ;)
Exactly. For Power Management on ACPI, we need to re-implement the
"Windows-compatible System Power Management Controller" (PEP), which
considering there isn't any documentation and/or source, would be a
mammoth challenge, if at all possible.
Feel free to provide your {Ack,Review)ed-by for this patch. :)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] include: mdio: Add driver data helpers
From: Florian Fainelli @ 2019-09-04 17:07 UTC (permalink / raw)
To: Harini Katakam, andrew, hkallweit1, davem
Cc: netdev, radhey.shyam.pandey, michal.simek, harinikatakamlinux,
linux-kernel, linux-arm-kernel
In-Reply-To: <1567605621-6818-2-git-send-email-harini.katakam@xilinx.com>
On 9/4/19 7:00 AM, Harini Katakam wrote:
> Add set/get drv_data helpers for mdio device.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/3] perf cs-etm: Refactor instruction size handling
From: Mathieu Poirier @ 2019-09-04 17:06 UTC (permalink / raw)
To: Leo Yan
Cc: Suzuki K Poulose, Alexander Shishkin, Linux Kernel Mailing List,
Arnaldo Carvalho de Melo, Adrian Hunter, Namhyung Kim,
Robert Walker, Jiri Olsa, linux-arm-kernel, Mike Leach
In-Reply-To: <20190904091916.GB27922@leoy-ThinkPad-X240s>
On Wed, 4 Sep 2019 at 03:19, Leo Yan <leo.yan@linaro.org> wrote:
>
> Hi Mathieu,
>
> On Tue, Sep 03, 2019 at 04:22:15PM -0600, Mathieu Poirier wrote:
> > On Fri, Aug 30, 2019 at 02:24:19PM +0800, Leo Yan wrote:
> > > There has several code pieces need to know the instruction size, but
> > > now every place calculates the instruction size separately.
> > >
> > > This patch refactors to create a new function cs_etm__instr_size() as
> > > a central place to analyze the instruction length based on ISA type
> > > and instruction value.
> > >
> > > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > > ---
> > > tools/perf/util/cs-etm.c | 44 +++++++++++++++++++++++++++-------------
> > > 1 file changed, 30 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > > index b3a5daaf1a8f..882a0718033d 100644
> > > --- a/tools/perf/util/cs-etm.c
> > > +++ b/tools/perf/util/cs-etm.c
> > > @@ -914,6 +914,26 @@ static inline int cs_etm__t32_instr_size(struct cs_etm_queue *etmq,
> > > return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
> > > }
> > >
> > > +static inline int cs_etm__instr_size(struct cs_etm_queue *etmq,
> > > + u8 trace_chan_id,
> > > + enum cs_etm_isa isa,
> > > + u64 addr)
> > > +{
> > > + int insn_len;
> > > +
> > > + /*
> > > + * T32 instruction size might be 32-bit or 16-bit, decide by calling
> > > + * cs_etm__t32_instr_size().
> > > + */
> > > + if (isa == CS_ETM_ISA_T32)
> > > + insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id, addr);
> > > + /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> > > + else
> > > + insn_len = 4;
> > > +
> > > + return insn_len;
> > > +}
> > > +
> > > static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
> > > {
> > > /* Returns 0 for the CS_ETM_DISCONTINUITY packet */
> > > @@ -938,19 +958,23 @@ static inline u64 cs_etm__instr_addr(struct cs_etm_queue *etmq,
> > > const struct cs_etm_packet *packet,
> > > u64 offset)
> > > {
> > > + int insn_len;
> > > +
> > > if (packet->isa == CS_ETM_ISA_T32) {
> > > u64 addr = packet->start_addr;
> > >
> > > while (offset > 0) {
> > > - addr += cs_etm__t32_instr_size(etmq,
> > > - trace_chan_id, addr);
> > > + addr += cs_etm__instr_size(etmq, trace_chan_id,
> > > + packet->isa, addr);
> > > offset--;
> > > }
> > > return addr;
> > > }
> > >
> > > - /* Assume a 4 byte instruction size (A32/A64) */
> > > - return packet->start_addr + offset * 4;
> > > + /* Return instruction size for A32/A64 */
> > > + insn_len = cs_etm__instr_size(etmq, trace_chan_id,
> > > + packet->isa, packet->start_addr);
> > > + return packet->start_addr + offset * insn_len;
> >
> > This patch will work but from where I stand it makes things difficult to
> > understand more than anything else. It is also adding coupling between function
> > cs_etm__instr_addr() and cs_etm__instr_size(), meaning the code needs to be
> > carefully inspected in order to make changes to either one.
>
> My purpose is to use a same place to calculate the instruction
> size, rather than to spread the duplicate codes in several different
> functions.
>
> > Last but not least function cs_etm__instr_size() isn't used in the upcoming
> > patches. I really don't see what is gained here.
>
> Sorry that I forgot to commit my final change into patch 02.
>
> I planed to use cs_etm__instr_size() in patch 02; patch 02 has
> function cs_etm__add_stack_event(), which also needs to get the
> instruction size when it sends stack event.
>
> After apply patch 02, tools/perf/util/cs-etm.c will have below three
> functions to caculate instruction size; this is the main reason I want
> to refactor the code for instruction size.
>
> cs_etm__instr_addr()
> cs_etm__copy_insn()
> cs_etm__add_stack_event()
>
> If this lets code more difficult to understand, will drop it.
>
I agree with the consolidation but for that to work function
cs_etm__instr_addr() needs to be refactored. Since
cs_etm__instr_size() is already taking care of checking the ISA type
the while() loop in cs_etm__instr_addr() can be done regardless of the
operation mode. That way cs_etm__instr_size() can be changed at will
without breaking anything.
The downside is that we are doing a few more iterations... Which isn't
that big a deal considering we are in user space. We can think about
some optimisation if it is ever proven to be a bottleneck.
Let me know if you see a problem with that approach.
Regards,
Mathieu
> Thanks,
> Leo Yan
>
> > > }
> > >
> > > static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq,
> > > @@ -1090,16 +1114,8 @@ static void cs_etm__copy_insn(struct cs_etm_queue *etmq,
> > > return;
> > > }
> > >
> > > - /*
> > > - * T32 instruction size might be 32-bit or 16-bit, decide by calling
> > > - * cs_etm__t32_instr_size().
> > > - */
> > > - if (packet->isa == CS_ETM_ISA_T32)
> > > - sample->insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id,
> > > - sample->ip);
> > > - /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> > > - else
> > > - sample->insn_len = 4;
> > > + sample->insn_len = cs_etm__instr_size(etmq, trace_chan_id,
> > > + packet->isa, sample->ip);
> > >
> > > cs_etm__mem_access(etmq, trace_chan_id, sample->ip,
> > > sample->insn_len, (void *)sample->insn);
> > > --
> > > 2.17.1
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 03/15] thermal: brcmstb: use devm_platform_ioremap_resource() to simplify code
From: Florian Fainelli @ 2019-09-04 17:00 UTC (permalink / raw)
To: YueHaibing, miquel.raynal, rui.zhang, edubezval, daniel.lezcano,
amit.kucheria, eric, wahrenst, f.fainelli, rjui, sbranden, mmayer,
computersforpeace, gregory.0xf0, matthias.bgg, agross, heiko,
mcoquelin.stm32, alexandre.torgue, marc.w.gonzalez, mans, talel,
jun.nie, shawnguo, phil, gregkh, david.hernandezsanchez,
horms+renesas, wsa+renesas
Cc: linux-pm, linux-arm-msm, linux-kernel, linux-rockchip,
linux-mediatek, linux-rpi-kernel, bcm-kernel-feedback-list,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190904122939.23780-4-yuehaibing@huawei.com>
On 9/4/19 5:29 AM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/1] arm64: dts: qcom: Add Lenovo Yoga C630
From: Sudeep Holla @ 2019-09-04 16:52 UTC (permalink / raw)
To: Lee Jones
Cc: mark.rutland, devicetree, linux-arm-msm, linux-kernel, robh+dt,
bjorn.andersson, agross, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20190904161247.GP26880@dell>
On Wed, Sep 04, 2019 at 05:12:47PM +0100, Lee Jones wrote:
> On Wed, 04 Sep 2019, Sudeep Holla wrote:
>
> > On Wed, Sep 04, 2019 at 01:16:06PM +0100, Lee Jones wrote:
> > > From: Bjorn Andersson <bjorn.andersson@linaro.org>
> > >
> > > The Lenovo Yoga C630 is built on the SDM850 from Qualcomm, but this seem
> > > to be similar enough to the SDM845 that we can reuse the sdm845.dtsi.
> > >
> > > Supported by this patch is: keyboard, battery monitoring, UFS storage,
> > > USB host and Bluetooth.
> > >
> >
> > Just curious to know if the idea of booting using ACPI is completely
> > dropped as it's extremely difficult(because the firmware is so hacked
> > up and may violate spec, just my opinion) for whatever reasons.
>
> Once [0] is applied, we can boot Mainline using ACPI.
>
Good to know.
> > We just made ACPI table version checking more lenient for this platform
> > and would be good to know if we continue to run ACPI on that or will
> > abandon and just use DT.
>
> Which patch are you referring to? If you mean the ACPI v5.0 vs v5.1
> patch authored by Ard, then yes I know, I instigated it's existence
> due to these devices.
>
Yes exactly that one.
> DT will *always* be more enabled than ACPI, so it's advised that you
> use DT for anything useful. ACPI booting is ideal for things like
> installing distros however, since they do not tend to provide DTBs in
> their installers.
>
OK, as along as it gets tested/used in some form, that's fine. I do agree
that DT will be more useful on that platform as it was derived from mobile
based SoC SDM845 rather than solely designed for Laptops and with more
alignment with ACPI spec. The way whole power/clock management is done
with ACPI on this pulls me towards DT ;)
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] net: phy: gmii2rgmii: Dont use priv field in phy device
From: Andrew Lunn @ 2019-09-04 16:47 UTC (permalink / raw)
To: Harini Katakam
Cc: f.fainelli, netdev, radhey.shyam.pandey, michal.simek,
harinikatakamlinux, linux-kernel, davem, linux-arm-kernel,
hkallweit1
In-Reply-To: <1567605621-6818-3-git-send-email-harini.katakam@xilinx.com>
On Wed, Sep 04, 2019 at 07:30:21PM +0530, Harini Katakam wrote:
> Use set/get drv data in phydev's mdio device instead. Phy device priv
> field maybe used by the external phy driver and should not be
> overwritten.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] include: mdio: Add driver data helpers
From: Andrew Lunn @ 2019-09-04 16:46 UTC (permalink / raw)
To: Harini Katakam
Cc: f.fainelli, netdev, radhey.shyam.pandey, michal.simek,
harinikatakamlinux, linux-kernel, davem, linux-arm-kernel,
hkallweit1
In-Reply-To: <1567605621-6818-2-git-send-email-harini.katakam@xilinx.com>
On Wed, Sep 04, 2019 at 07:30:20PM +0530, Harini Katakam wrote:
> Add set/get drv_data helpers for mdio device.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v18 15/15] selftests, arm64: add a selftest for passing tagged pointers to kernel
From: Andrey Konovalov @ 2019-09-04 16:42 UTC (permalink / raw)
To: Cristian Marussi
Cc: Mark Rutland, kvm, Szabolcs Nagy, Catalin Marinas, Will Deacon,
dri-devel, Linux Memory Management List, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Felix Kuehling,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Dave Martin, Evgeniy Stepanov, linux-media, Kevin Brodsky,
Kees Cook, Ruben Ayrapetyan, Ramana Radhakrishnan,
Alex Williamson, Mauro Carvalho Chehab, Linux ARM,
Kostya Serebryany, Greg Kroah-Hartman, Yishai Hadas, LKML,
Jens Wiklander, Lee Smith, Alexander Deucher, Andrew Morton, enh,
Robin Murphy, Christian Koenig, Luc Van Oostenryck
In-Reply-To: <92ca7fd1-2aa7-3bec-384d-52033b6496c1@arm.com>
On Wed, Sep 4, 2019 at 6:22 PM Cristian Marussi
<cristian.marussi@arm.com> wrote:
>
> Hi Andrey !
>
> On 04/09/2019 15:52, Andrey Konovalov wrote:
> > On Fri, Aug 23, 2019 at 7:49 PM Cristian Marussi
> > <cristian.marussi@arm.com> wrote:
> >>
> >>
> >> Hi
> >>
> >> On 23/08/2019 18:16, Andrey Konovalov wrote:
> >>> On Fri, Aug 23, 2019 at 3:56 PM Cristian Marussi
> >>> <cristian.marussi@arm.com> wrote:
> >>>>
> >>>> Hi Andrey
> >>>>
> >>>> On 24/06/2019 15:33, Andrey Konovalov wrote:
> >>>>> This patch is a part of a series that extends kernel ABI to allow to pass
> >>>>> tagged user pointers (with the top byte set to something else other than
> >>>>> 0x00) as syscall arguments.
> >>>>>
> >>>>> This patch adds a simple test, that calls the uname syscall with a
> >>>>> tagged user pointer as an argument. Without the kernel accepting tagged
> >>>>> user pointers the test fails with EFAULT.
> >>>>>
> >>>>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> >>>>> ---
> >>>>> tools/testing/selftests/arm64/.gitignore | 1 +
> >>>>> tools/testing/selftests/arm64/Makefile | 11 +++++++
> >>>>> .../testing/selftests/arm64/run_tags_test.sh | 12 ++++++++
> >>>>> tools/testing/selftests/arm64/tags_test.c | 29 +++++++++++++++++++
> >>>>> 4 files changed, 53 insertions(+)
> >>>>> create mode 100644 tools/testing/selftests/arm64/.gitignore
> >>>>> create mode 100644 tools/testing/selftests/arm64/Makefile
> >>>>> create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
> >>>>> create mode 100644 tools/testing/selftests/arm64/tags_test.c
> >>>>
> >>>> After building a fresh Kernel from arm64/for-next-core from scratch at:
> >>>>
> >>>> commit 239ab658bea3b387424501e7c416640d6752dc0c
> >>>> Merge: 6bfa3134bd3a 42d038c4fb00 1243cb6a676f d55c5f28afaf d06fa5a118f1 34b5560db40d
> >>>> Author: Will Deacon <will@kernel.org>
> >>>> Date: Thu Aug 22 18:23:53 2019 +0100
> >>>>
> >>>> Merge branches 'for-next/error-injection', 'for-next/tbi', 'for-next/psci-cpuidle', 'for-next/cpu-topology' and 'for-next/52-bit-kva' into for-next/core
> >>>>
> >>>>
> >>>> KSFT arm64 tests build is broken for me, both setting or not KBUILD_OUTPUT=
> >>>>
> >>>> 13:30 $ make TARGETS=arm64 kselftest-clean
> >>>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >>>> rm -f -r /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
> >>>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >>>>
> >>>> ✔ ~/ARM/dev/src/pdsw/linux [arm64_for_next_core|…8⚑ 23]
> >>>>
> >>>> 13:30 $ make TARGETS=arm64 kselftest
> >>>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >>>> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
> >>>> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
> >>>> ARCH=arm64 -C ../../.. headers_install
> >>>> HOSTCC scripts/basic/fixdep
> >>>> HOSTCC scripts/unifdef
> >>>> ...
> >>>> ...
> >>>> HDRINST usr/include/asm/msgbuf.h
> >>>> HDRINST usr/include/asm/shmbuf.h
> >>>> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/usr/include
> >>>> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
> >>>> tags_test.c: In function ‘main’:
> >>>> tags_test.c:21:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
> >>>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >>>> ^~~~~~~~~~~~~~~~~~~~~~~
> >>>> PR_GET_TID_ADDRESS
> >>>> tags_test.c:21:12: note: each undeclared identifier is reported only once for each function it appears in
> >>>> tags_test.c:21:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
> >>>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >>>> ^~~~~~~~~~~~~~~~~~~~~
> >>>> PR_GET_DUMPABLE
> >>>> ../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test' failed
> >>>> make[3]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test] Error 1
> >>>> Makefile:136: recipe for target 'all' failed
> >>>> make[2]: *** [all] Error 2
> >>>> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1237: recipe for target 'kselftest' failed
> >>>> make[1]: *** [kselftest] Error 2
> >>>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >>>> Makefile:179: recipe for target 'sub-make' failed
> >>>> make: *** [sub-make] Error 2
> >>>>
> >>>> Despite seeing KSFT installing Kernel Headers, they cannot be found.
> >>>>
> >>>> Fixing this patch like this make it work for me:
> >>>>
> >>>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
> >>>> index a61b2e743e99..f9f79fb272f0 100644
> >>>> --- a/tools/testing/selftests/arm64/Makefile
> >>>> +++ b/tools/testing/selftests/arm64/Makefile
> >>>> @@ -4,6 +4,7 @@
> >>>> ARCH ?= $(shell uname -m 2>/dev/null || echo not)
> >>>>
> >>>> ifneq (,$(filter $(ARCH),aarch64 arm64))
> >>>> +CFLAGS += -I../../../../usr/include/
> >>>> TEST_GEN_PROGS := tags_test
> >>>> TEST_PROGS := run_tags_test.sh
> >>>> endif
> >>>>
> >>>> but is not really a proper fix since it does NOT account for case in which you have
> >>>> installed the Kernel Headers in a non standard location like when you use KBUILD_OUTPUT.
> >>>>
> >>>> Am I missing something ?
> >>>
> >>> Hm, PR_SET_TAGGED_ADDR_CTRL is defined in include/uapi/linux/prctl.h,
> >>> and the test has #include <sys/prctl.h> so as long as you've updated
> >>> your kernel headers this should work.
> >>>
> >>> (I'm OOO next week, I'll see if I can reproduce this once I'm back).
> >>
> >> Ok. Thanks for the reply.
> >>
> >> I think I've got it in my local tree having cloned arm64/for-next-core:
> >>
> >> 18:32 $ egrep -A 10 PR_SET_TAG ./include/uapi/linux/prctl.h
> >> #define PR_SET_TAGGED_ADDR_CTRL 55
> >> #define PR_GET_TAGGED_ADDR_CTRL 56
> >> # define PR_TAGGED_ADDR_ENABLE (1UL << 0)
> >>
> >> #endif /* _LINUX_PRCTL_H */
> >>
> >> and Kernel header are locally installed in my kernel src dir (by KSFT indeed)
> >>
> >> 18:34 $ egrep -RA 10 PR_SET_TAG usr/include/
> >> usr/include/linux/prctl.h:#define PR_SET_TAGGED_ADDR_CTRL 55
> >> usr/include/linux/prctl.h-#define PR_GET_TAGGED_ADDR_CTRL 56
> >> usr/include/linux/prctl.h-# define PR_TAGGED_ADDR_ENABLE (1UL << 0)
> >> usr/include/linux/prctl.h-
> >> usr/include/linux/prctl.h-#endif /* _LINUX_PRCTL_H */
> >>
> >> but how are they supposed to be found if nor the test Makefile
> >> neither the KSFT Makefile who installs them pass any -I options to the
> >> compiler ?
> >> I suppose <sys/prctl.h> tries to include arch specific headers from the regular system path,
> >> but when you are cross-compiling ?
> >>
> >> 18:34 $ make TARGETS=arm64 kselftest
> >> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
> >> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
> >> ARCH=arm64 -C ../../.. headers_install
> >> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/usr/include
> >> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -Wall -O2 -g tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test
> >> tags_test.c: In function ‘main’:
> >> tags_test.c:20:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
> >> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >> ^~~~~~~~~~~~~~~~~~~~~~~
> >> PR_GET_TID_ADDRESS
> >> tags_test.c:20:12: note: each undeclared identifier is reported only once for each function it appears in
> >> tags_test.c:20:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
> >> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >> ^~~~~~~~~~~~~~~~~~~~~
> >> PR_GET_DUMPABLE
> >> ../../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test' failed
> >> make[4]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test] Error 1
> >> Makefile:19: recipe for target 'all' failed
> >> make[3]: *** [all] Error 2
> >> Makefile:137: recipe for target 'all' failed
> >> make[2]: *** [all] Error 2
> >> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1236: recipe for target 'kselftest' failed
> >> make[1]: *** [kselftest] Error 2
> >> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >> Makefile:179: recipe for target 'sub-make' failed
> >> make: *** [sub-make] Error 2
> >>
> >>
> >> In fact many KSFT testcases seems to brutally add default headers path:
> >>
> >> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/uapi/
> >> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/
> >> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../usr/include/
> >> tools/testing/selftests/net/Makefile:CFLAGS += -I../../../../usr/include/
> >> tools/testing/selftests/membarrier/Makefile:CFLAGS += -g -I../../../../usr/include/
> >> ...
> >
> > Hi Cristian!
> >
> > Indeed, I can reproduce the issue. I don't know what's the proper way
> > to resolve this. Adding "CFLAGS += -I../../../../usr/include/" looks
> > good to me. AFAICS your series resolves this issue in a similar way,
> > but I think we should fix this before the current rc is released. Do
> > you want to submit a patch that adds this simple fix or should I do
> > that?
> >
>
> Please feel free to post the single line patch above to quickly fix this before
> release, so we don't have a broken build straight away. (our CI is already beating me...:D)
Done.
>
> On my side (01/11) in the meantime I'll fix the top level KSFT arm64 makefile so as to calculate
> and propagate once for all the headers search path down to all KSFT arm64/ in one go,
> trying to guess where they are; this is needed because the above fix works fine as long
> as you don't have KBUILD_OUTPUT set, once you set it, KSFT installs kheaders in a different
> place and the above -I fix is fooled again....but this is a general problem also in other
> KSFT tests as I can see now so I think this fix is good enough for now
> (and the fix on my side, even if trivial, is not going to go into this release for sure)
Ah, I see.
Thanks for the report!
>
> Thanks !
>
> Cheers
>
> Cristian
>
> > Thanks!
> >
> >>
> >> Cheers
> >>
> >> Cristian
> >>>
> >>>
> >>>
> >>>>
> >>>> Thanks
> >>>>
> >>>> Cristian
> >>>>
> >>>>>
> >>>>> diff --git a/tools/testing/selftests/arm64/.gitignore b/tools/testing/selftests/arm64/.gitignore
> >>>>> new file mode 100644
> >>>>> index 000000000000..e8fae8d61ed6
> >>>>> --- /dev/null
> >>>>> +++ b/tools/testing/selftests/arm64/.gitignore
> >>>>> @@ -0,0 +1 @@
> >>>>> +tags_test
> >>>>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
> >>>>> new file mode 100644
> >>>>> index 000000000000..a61b2e743e99
> >>>>> --- /dev/null
> >>>>> +++ b/tools/testing/selftests/arm64/Makefile
> >>>>> @@ -0,0 +1,11 @@
> >>>>> +# SPDX-License-Identifier: GPL-2.0
> >>>>> +
> >>>>> +# ARCH can be overridden by the user for cross compiling
> >>>>> +ARCH ?= $(shell uname -m 2>/dev/null || echo not)
> >>>>> +
> >>>>> +ifneq (,$(filter $(ARCH),aarch64 arm64))
> >>>>> +TEST_GEN_PROGS := tags_test
> >>>>> +TEST_PROGS := run_tags_test.sh
> >>>>> +endif
> >>>>> +
> >>>>> +include ../lib.mk
> >>>>> diff --git a/tools/testing/selftests/arm64/run_tags_test.sh b/tools/testing/selftests/arm64/run_tags_test.sh
> >>>>> new file mode 100755
> >>>>> index 000000000000..745f11379930
> >>>>> --- /dev/null
> >>>>> +++ b/tools/testing/selftests/arm64/run_tags_test.sh
> >>>>> @@ -0,0 +1,12 @@
> >>>>> +#!/bin/sh
> >>>>> +# SPDX-License-Identifier: GPL-2.0
> >>>>> +
> >>>>> +echo "--------------------"
> >>>>> +echo "running tags test"
> >>>>> +echo "--------------------"
> >>>>> +./tags_test
> >>>>> +if [ $? -ne 0 ]; then
> >>>>> + echo "[FAIL]"
> >>>>> +else
> >>>>> + echo "[PASS]"
> >>>>> +fi
> >>>>> diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c
> >>>>> new file mode 100644
> >>>>> index 000000000000..22a1b266e373
> >>>>> --- /dev/null
> >>>>> +++ b/tools/testing/selftests/arm64/tags_test.c
> >>>>> @@ -0,0 +1,29 @@
> >>>>> +// SPDX-License-Identifier: GPL-2.0
> >>>>> +
> >>>>> +#include <stdio.h>
> >>>>> +#include <stdlib.h>
> >>>>> +#include <unistd.h>
> >>>>> +#include <stdint.h>
> >>>>> +#include <sys/prctl.h>
> >>>>> +#include <sys/utsname.h>
> >>>>> +
> >>>>> +#define SHIFT_TAG(tag) ((uint64_t)(tag) << 56)
> >>>>> +#define SET_TAG(ptr, tag) (((uint64_t)(ptr) & ~SHIFT_TAG(0xff)) | \
> >>>>> + SHIFT_TAG(tag))
> >>>>> +
> >>>>> +int main(void)
> >>>>> +{
> >>>>> + static int tbi_enabled = 0;
> >>>>> + struct utsname *ptr, *tagged_ptr;
> >>>>> + int err;
> >>>>> +
> >>>>> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >>>>> + tbi_enabled = 1;
> >>>>> + ptr = (struct utsname *)malloc(sizeof(*ptr));
> >>>>> + if (tbi_enabled)
> >>>>> + tagged_ptr = (struct utsname *)SET_TAG(ptr, 0x42);
> >>>>> + err = uname(tagged_ptr);
> >>>>> + free(ptr);
> >>>>> +
> >>>>> + return err;
> >>>>> +}
> >>>>>
> >>>>
> >>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH ARM64] selftests, arm64: add kernel headers path for tags_test
From: Andrey Konovalov @ 2019-09-04 16:41 UTC (permalink / raw)
To: linux-arm-kernel, linux-kselftest, linux-kernel, Will Deacon
Cc: Mark Rutland, Catalin Marinas, Evgeniy Stepanov,
Kostya Serebryany, Cristian Marussi, Andrey Konovalov,
Amit Kachhap, Vincenzo Frascino, Dmitry Vyukov
tags_test.c relies on PR_SET_TAGGED_ADDR_CTRL/PR_TAGGED_ADDR_ENABLE being
present in system headers. When this is not the case the build of this
test fails with undeclared identifier errors.
Fix by providing the path to the KSFT installed kernel headers in CFLAGS.
Reported-by: Cristian Marussi <cristian.marussi@arm.com>
Suggested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
tools/testing/selftests/arm64/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
index a61b2e743e99..f9f79fb272f0 100644
--- a/tools/testing/selftests/arm64/Makefile
+++ b/tools/testing/selftests/arm64/Makefile
@@ -4,6 +4,7 @@
ARCH ?= $(shell uname -m 2>/dev/null || echo not)
ifneq (,$(filter $(ARCH),aarch64 arm64))
+CFLAGS += -I../../../../usr/include/
TEST_GEN_PROGS := tags_test
TEST_PROGS := run_tags_test.sh
endif
--
2.23.0.187.g17f5b7556c-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [GIT PULL 1/2] ti-sysc driver changes for v5.3
From: Tony Lindgren @ 2019-09-04 16:36 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <CAK8P3a1Hh8nFe7h0Jr7tf_aoarvwr3utD7LrFf9rV_OePL-+Zg@mail.gmail.com>
* Arnd Bergmann <arnd@arndb.de> [190904 15:27]:
> On Sat, Aug 24, 2019 at 12:24 AM Tony Lindgren <tony@atomide.com> wrote:
> > Driver changes for ti-sysc for v5.4
> >
> > Few changes to prepare for using a reset driver for PRM rstctrl mostly
> > to deal with the clocks for reset. Then few minor clean-up patches and
> > SPDX license identifier changes, and add a MAINTAINERs file entry.
>
> Pulled this one into an arm/late branch, together with the three
> other pull requests that depend on this one.
>
> Don't worry about the arm/late name, I expect to send this off
> together with the other branches, it's just easier for me to
> describe what's in each of the top-level branches this way.
OK sure thanks.
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Bitmain changes for v5.4
From: Manivannan Sadhasivam @ 2019-09-04 16:33 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Olof Johansson, arm-soc, Linux ARM
In-Reply-To: <CAK8P3a2gVsy8Do8Wrpu9wCTTBSb1qx-+mNtyCKKUA=hQVfDwSw@mail.gmail.com>
Hi Arnd,
On 4 September 2019 6:17:59 PM IST, Arnd Bergmann <arnd@arndb.de> wrote:
>On Sat, Aug 3, 2019 at 2:44 PM Manivannan Sadhasivam
><manivannan.sadhasivam@linaro.org> wrote:
>>
>> Hi Arnd, Olof,
>>
>> Please consider pulling the Bitmain SoC changes for v5.4. These
>changes
>> are supposed to be pulled in for 5.3 but I was waiting for the common
>> clock driver to be reviewed (still not), hence missing the timeline.
>> Details of the changes are in the signed tag.
>
>I just found this while going through old emails, it seems I never
>pulled it
>so far and did that now.
>
>Please note that our address has changed, and new pull requests and
>patches should go to soc@kernel.org so they end up in the patchwork
>at https://patchwork.kernel.org/project/linux-soc/list/ where you can
>see the status.
>
Okay, will use this address for future PR's.
Thanks,
Mani
>Sorry for missing this earlier.
>
> Arnd
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] gpio: Add in ast2600 details to Aspeed driver
From: Andy Shevchenko @ 2019-09-04 16:30 UTC (permalink / raw)
To: Rashmica Gupta
Cc: linux-aspeed, Bartosz Golaszewski, Andrew Jeffery, Linus Walleij,
Linux Kernel Mailing List, open list:GPIO SUBSYSTEM, Joel Stanley,
linux-arm Mailing List
In-Reply-To: <20190904061245.30770-3-rashmica.g@gmail.com>
On Wed, Sep 4, 2019 at 9:14 AM Rashmica Gupta <rashmica.g@gmail.com> wrote:
>
> The ast2600 has two gpio controllers, one for 3.6V GPIOS and one for 1.8V GPIOS.
>
> Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
> - for (i = 0; i < ARRAY_SIZE(aspeed_gpio_banks); i++) {
> + banks = (gpio->config->nr_gpios >> 5) + 1;
Same comment as per the other patch.
> + for (i = 0; i < banks; i++) {
> +static const struct aspeed_bank_props ast2600_bank_props[] = {
> + /* input output */
> + {5, 0xffffffff, 0x0000ffff}, /* U/V/W/X */
> + {6, 0xffff0000, 0x0fff0000}, /* Y/Z */
Perhaps GENMASK() for all values?
> + { },
Comma is not needed here.
> +};
> +
> +static const struct aspeed_gpio_config ast2600_config =
> + /* 208 3.6V GPIOs */
> + { .nr_gpios = 208, .props = ast2600_bank_props, };
Seems curly braces missed their places.
> +static const struct aspeed_bank_props ast2600_1_8v_bank_props[] = {
> + /* input output */
> + {1, 0x0000000f, 0x0000000f}, /* E */
GENMASK()?
> + { },
No comma.
> +};
> +static const struct aspeed_gpio_config ast2600_1_8v_config =
> + /* 36 1.8V GPIOs */
> + { .nr_gpios = 36, .props = ast2600_1_8v_bank_props, };
Location of the curly braces?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] gpio/aspeed: Fix incorrect number of banks
From: Andy Shevchenko @ 2019-09-04 16:27 UTC (permalink / raw)
To: Rashmica Gupta
Cc: linux-aspeed, Bartosz Golaszewski, Andrew Jeffery, Linus Walleij,
Linux Kernel Mailing List, open list:GPIO SUBSYSTEM, Joel Stanley,
linux-arm Mailing List
In-Reply-To: <20190904061245.30770-1-rashmica.g@gmail.com>
On Wed, Sep 4, 2019 at 9:14 AM Rashmica Gupta <rashmica.g@gmail.com> wrote:
>
> Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver')
>
> Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
> /* Allocate a cache of the output registers */
> - banks = gpio->config->nr_gpios >> 5;
> + banks = (gpio->config->nr_gpios >> 5) + 1;
Shouldn't be rather DIV_ROUND_UP(nr_gpios, sizeof(u32)) ?
> gpio->dcache = devm_kcalloc(&pdev->dev,
> banks, sizeof(u32), GFP_KERNEL);
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v18 15/15] selftests, arm64: add a selftest for passing tagged pointers to kernel
From: Cristian Marussi @ 2019-09-04 16:22 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Mark Rutland, kvm, Szabolcs Nagy, Catalin Marinas, Will Deacon,
dri-devel, Linux Memory Management List, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Felix Kuehling,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Dave Martin, Evgeniy Stepanov, linux-media, Kevin Brodsky,
Kees Cook, Ruben Ayrapetyan, Ramana Radhakrishnan,
Alex Williamson, Mauro Carvalho Chehab, Linux ARM,
Kostya Serebryany, Greg Kroah-Hartman, Yishai Hadas, LKML,
Jens Wiklander, Lee Smith, Alexander Deucher, Andrew Morton, enh,
Robin Murphy, Christian Koenig, Luc Van Oostenryck
In-Reply-To: <CAAeHK+xXN_oHt0rAcWdTs0XhkYRhWqf3iv-n+dYmY075xosJnw@mail.gmail.com>
Hi Andrey !
On 04/09/2019 15:52, Andrey Konovalov wrote:
> On Fri, Aug 23, 2019 at 7:49 PM Cristian Marussi
> <cristian.marussi@arm.com> wrote:
>>
>>
>> Hi
>>
>> On 23/08/2019 18:16, Andrey Konovalov wrote:
>>> On Fri, Aug 23, 2019 at 3:56 PM Cristian Marussi
>>> <cristian.marussi@arm.com> wrote:
>>>>
>>>> Hi Andrey
>>>>
>>>> On 24/06/2019 15:33, Andrey Konovalov wrote:
>>>>> This patch is a part of a series that extends kernel ABI to allow to pass
>>>>> tagged user pointers (with the top byte set to something else other than
>>>>> 0x00) as syscall arguments.
>>>>>
>>>>> This patch adds a simple test, that calls the uname syscall with a
>>>>> tagged user pointer as an argument. Without the kernel accepting tagged
>>>>> user pointers the test fails with EFAULT.
>>>>>
>>>>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
>>>>> ---
>>>>> tools/testing/selftests/arm64/.gitignore | 1 +
>>>>> tools/testing/selftests/arm64/Makefile | 11 +++++++
>>>>> .../testing/selftests/arm64/run_tags_test.sh | 12 ++++++++
>>>>> tools/testing/selftests/arm64/tags_test.c | 29 +++++++++++++++++++
>>>>> 4 files changed, 53 insertions(+)
>>>>> create mode 100644 tools/testing/selftests/arm64/.gitignore
>>>>> create mode 100644 tools/testing/selftests/arm64/Makefile
>>>>> create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
>>>>> create mode 100644 tools/testing/selftests/arm64/tags_test.c
>>>>
>>>> After building a fresh Kernel from arm64/for-next-core from scratch at:
>>>>
>>>> commit 239ab658bea3b387424501e7c416640d6752dc0c
>>>> Merge: 6bfa3134bd3a 42d038c4fb00 1243cb6a676f d55c5f28afaf d06fa5a118f1 34b5560db40d
>>>> Author: Will Deacon <will@kernel.org>
>>>> Date: Thu Aug 22 18:23:53 2019 +0100
>>>>
>>>> Merge branches 'for-next/error-injection', 'for-next/tbi', 'for-next/psci-cpuidle', 'for-next/cpu-topology' and 'for-next/52-bit-kva' into for-next/core
>>>>
>>>>
>>>> KSFT arm64 tests build is broken for me, both setting or not KBUILD_OUTPUT=
>>>>
>>>> 13:30 $ make TARGETS=arm64 kselftest-clean
>>>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>>>> rm -f -r /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
>>>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>>>>
>>>> ✔ ~/ARM/dev/src/pdsw/linux [arm64_for_next_core|…8⚑ 23]
>>>>
>>>> 13:30 $ make TARGETS=arm64 kselftest
>>>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>>>> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
>>>> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
>>>> ARCH=arm64 -C ../../.. headers_install
>>>> HOSTCC scripts/basic/fixdep
>>>> HOSTCC scripts/unifdef
>>>> ...
>>>> ...
>>>> HDRINST usr/include/asm/msgbuf.h
>>>> HDRINST usr/include/asm/shmbuf.h
>>>> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/usr/include
>>>> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
>>>> tags_test.c: In function ‘main’:
>>>> tags_test.c:21:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
>>>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>>>> ^~~~~~~~~~~~~~~~~~~~~~~
>>>> PR_GET_TID_ADDRESS
>>>> tags_test.c:21:12: note: each undeclared identifier is reported only once for each function it appears in
>>>> tags_test.c:21:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
>>>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>>>> ^~~~~~~~~~~~~~~~~~~~~
>>>> PR_GET_DUMPABLE
>>>> ../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test' failed
>>>> make[3]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test] Error 1
>>>> Makefile:136: recipe for target 'all' failed
>>>> make[2]: *** [all] Error 2
>>>> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1237: recipe for target 'kselftest' failed
>>>> make[1]: *** [kselftest] Error 2
>>>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>>>> Makefile:179: recipe for target 'sub-make' failed
>>>> make: *** [sub-make] Error 2
>>>>
>>>> Despite seeing KSFT installing Kernel Headers, they cannot be found.
>>>>
>>>> Fixing this patch like this make it work for me:
>>>>
>>>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
>>>> index a61b2e743e99..f9f79fb272f0 100644
>>>> --- a/tools/testing/selftests/arm64/Makefile
>>>> +++ b/tools/testing/selftests/arm64/Makefile
>>>> @@ -4,6 +4,7 @@
>>>> ARCH ?= $(shell uname -m 2>/dev/null || echo not)
>>>>
>>>> ifneq (,$(filter $(ARCH),aarch64 arm64))
>>>> +CFLAGS += -I../../../../usr/include/
>>>> TEST_GEN_PROGS := tags_test
>>>> TEST_PROGS := run_tags_test.sh
>>>> endif
>>>>
>>>> but is not really a proper fix since it does NOT account for case in which you have
>>>> installed the Kernel Headers in a non standard location like when you use KBUILD_OUTPUT.
>>>>
>>>> Am I missing something ?
>>>
>>> Hm, PR_SET_TAGGED_ADDR_CTRL is defined in include/uapi/linux/prctl.h,
>>> and the test has #include <sys/prctl.h> so as long as you've updated
>>> your kernel headers this should work.
>>>
>>> (I'm OOO next week, I'll see if I can reproduce this once I'm back).
>>
>> Ok. Thanks for the reply.
>>
>> I think I've got it in my local tree having cloned arm64/for-next-core:
>>
>> 18:32 $ egrep -A 10 PR_SET_TAG ./include/uapi/linux/prctl.h
>> #define PR_SET_TAGGED_ADDR_CTRL 55
>> #define PR_GET_TAGGED_ADDR_CTRL 56
>> # define PR_TAGGED_ADDR_ENABLE (1UL << 0)
>>
>> #endif /* _LINUX_PRCTL_H */
>>
>> and Kernel header are locally installed in my kernel src dir (by KSFT indeed)
>>
>> 18:34 $ egrep -RA 10 PR_SET_TAG usr/include/
>> usr/include/linux/prctl.h:#define PR_SET_TAGGED_ADDR_CTRL 55
>> usr/include/linux/prctl.h-#define PR_GET_TAGGED_ADDR_CTRL 56
>> usr/include/linux/prctl.h-# define PR_TAGGED_ADDR_ENABLE (1UL << 0)
>> usr/include/linux/prctl.h-
>> usr/include/linux/prctl.h-#endif /* _LINUX_PRCTL_H */
>>
>> but how are they supposed to be found if nor the test Makefile
>> neither the KSFT Makefile who installs them pass any -I options to the
>> compiler ?
>> I suppose <sys/prctl.h> tries to include arch specific headers from the regular system path,
>> but when you are cross-compiling ?
>>
>> 18:34 $ make TARGETS=arm64 kselftest
>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
>> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
>> ARCH=arm64 -C ../../.. headers_install
>> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/usr/include
>> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -Wall -O2 -g tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test
>> tags_test.c: In function ‘main’:
>> tags_test.c:20:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>> ^~~~~~~~~~~~~~~~~~~~~~~
>> PR_GET_TID_ADDRESS
>> tags_test.c:20:12: note: each undeclared identifier is reported only once for each function it appears in
>> tags_test.c:20:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>> ^~~~~~~~~~~~~~~~~~~~~
>> PR_GET_DUMPABLE
>> ../../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test' failed
>> make[4]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test] Error 1
>> Makefile:19: recipe for target 'all' failed
>> make[3]: *** [all] Error 2
>> Makefile:137: recipe for target 'all' failed
>> make[2]: *** [all] Error 2
>> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1236: recipe for target 'kselftest' failed
>> make[1]: *** [kselftest] Error 2
>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>> Makefile:179: recipe for target 'sub-make' failed
>> make: *** [sub-make] Error 2
>>
>>
>> In fact many KSFT testcases seems to brutally add default headers path:
>>
>> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/uapi/
>> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/
>> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../usr/include/
>> tools/testing/selftests/net/Makefile:CFLAGS += -I../../../../usr/include/
>> tools/testing/selftests/membarrier/Makefile:CFLAGS += -g -I../../../../usr/include/
>> ...
>
> Hi Cristian!
>
> Indeed, I can reproduce the issue. I don't know what's the proper way
> to resolve this. Adding "CFLAGS += -I../../../../usr/include/" looks
> good to me. AFAICS your series resolves this issue in a similar way,
> but I think we should fix this before the current rc is released. Do
> you want to submit a patch that adds this simple fix or should I do
> that?
>
Please feel free to post the single line patch above to quickly fix this before
release, so we don't have a broken build straight away. (our CI is already beating me...:D)
On my side (01/11) in the meantime I'll fix the top level KSFT arm64 makefile so as to calculate
and propagate once for all the headers search path down to all KSFT arm64/ in one go,
trying to guess where they are; this is needed because the above fix works fine as long
as you don't have KBUILD_OUTPUT set, once you set it, KSFT installs kheaders in a different
place and the above -I fix is fooled again....but this is a general problem also in other
KSFT tests as I can see now so I think this fix is good enough for now
(and the fix on my side, even if trivial, is not going to go into this release for sure)
Thanks !
Cheers
Cristian
> Thanks!
>
>>
>> Cheers
>>
>> Cristian
>>>
>>>
>>>
>>>>
>>>> Thanks
>>>>
>>>> Cristian
>>>>
>>>>>
>>>>> diff --git a/tools/testing/selftests/arm64/.gitignore b/tools/testing/selftests/arm64/.gitignore
>>>>> new file mode 100644
>>>>> index 000000000000..e8fae8d61ed6
>>>>> --- /dev/null
>>>>> +++ b/tools/testing/selftests/arm64/.gitignore
>>>>> @@ -0,0 +1 @@
>>>>> +tags_test
>>>>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
>>>>> new file mode 100644
>>>>> index 000000000000..a61b2e743e99
>>>>> --- /dev/null
>>>>> +++ b/tools/testing/selftests/arm64/Makefile
>>>>> @@ -0,0 +1,11 @@
>>>>> +# SPDX-License-Identifier: GPL-2.0
>>>>> +
>>>>> +# ARCH can be overridden by the user for cross compiling
>>>>> +ARCH ?= $(shell uname -m 2>/dev/null || echo not)
>>>>> +
>>>>> +ifneq (,$(filter $(ARCH),aarch64 arm64))
>>>>> +TEST_GEN_PROGS := tags_test
>>>>> +TEST_PROGS := run_tags_test.sh
>>>>> +endif
>>>>> +
>>>>> +include ../lib.mk
>>>>> diff --git a/tools/testing/selftests/arm64/run_tags_test.sh b/tools/testing/selftests/arm64/run_tags_test.sh
>>>>> new file mode 100755
>>>>> index 000000000000..745f11379930
>>>>> --- /dev/null
>>>>> +++ b/tools/testing/selftests/arm64/run_tags_test.sh
>>>>> @@ -0,0 +1,12 @@
>>>>> +#!/bin/sh
>>>>> +# SPDX-License-Identifier: GPL-2.0
>>>>> +
>>>>> +echo "--------------------"
>>>>> +echo "running tags test"
>>>>> +echo "--------------------"
>>>>> +./tags_test
>>>>> +if [ $? -ne 0 ]; then
>>>>> + echo "[FAIL]"
>>>>> +else
>>>>> + echo "[PASS]"
>>>>> +fi
>>>>> diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c
>>>>> new file mode 100644
>>>>> index 000000000000..22a1b266e373
>>>>> --- /dev/null
>>>>> +++ b/tools/testing/selftests/arm64/tags_test.c
>>>>> @@ -0,0 +1,29 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>> +
>>>>> +#include <stdio.h>
>>>>> +#include <stdlib.h>
>>>>> +#include <unistd.h>
>>>>> +#include <stdint.h>
>>>>> +#include <sys/prctl.h>
>>>>> +#include <sys/utsname.h>
>>>>> +
>>>>> +#define SHIFT_TAG(tag) ((uint64_t)(tag) << 56)
>>>>> +#define SET_TAG(ptr, tag) (((uint64_t)(ptr) & ~SHIFT_TAG(0xff)) | \
>>>>> + SHIFT_TAG(tag))
>>>>> +
>>>>> +int main(void)
>>>>> +{
>>>>> + static int tbi_enabled = 0;
>>>>> + struct utsname *ptr, *tagged_ptr;
>>>>> + int err;
>>>>> +
>>>>> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>>>>> + tbi_enabled = 1;
>>>>> + ptr = (struct utsname *)malloc(sizeof(*ptr));
>>>>> + if (tbi_enabled)
>>>>> + tagged_ptr = (struct utsname *)SET_TAG(ptr, 0x42);
>>>>> + err = uname(tagged_ptr);
>>>>> + free(ptr);
>>>>> +
>>>>> + return err;
>>>>> +}
>>>>>
>>>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.
From: Greg KH @ 2019-09-04 16:17 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Jon Corbet, Coresight ML, open list:DOCUMENTATION,
linux-arm-kernel, Suzuki K. Poulose, Mike Leach
In-Reply-To: <CANLsYkySX_3fGi4WLKHr7bv2=_j2UMyaTXCrwHSnzR-oH1V_ZQ@mail.gmail.com>
On Wed, Sep 04, 2019 at 10:05:51AM -0600, Mathieu Poirier wrote:
> On Tue, 3 Sep 2019 at 23:48, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Sep 03, 2019 at 04:51:40PM -0600, Mathieu Poirier wrote:
> > > On Tue, 3 Sep 2019 at 13:59, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Thu, Aug 29, 2019 at 10:33:19PM +0100, Mike Leach wrote:
> > > > > Update document to include the new sysfs features added during this
> > > > > patchset.
> > > > >
> > > > > Updated to reflect the new sysfs component nameing schema.
> > > > >
> > > > > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > > > > ---
> > > > > .../testing/sysfs-bus-coresight-devices-etm4x | 183 +++++++++++-------
> > > > > 1 file changed, 115 insertions(+), 68 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > index 36258bc1b473..112c50ae9986 100644
> > > > > --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > @@ -1,4 +1,4 @@
> > > > > -What: /sys/bus/coresight/devices/<memory_map>.etm/enable_source
> > > > > +What: /sys/bus/coresight/devices/etm<N>/enable_source
> > > >
> > > > You are renaming sysfs directories that have been around since:
> > > >
> > > > > Date: April 2015
> > > >
> > > > ???
> > > >
> > > > Really?
> > > >
> > > > That's brave.
> > >
> > >
> > > When I worked on the coresight sysfs ABI a while back I specifically
> > > added it at the "testing" level as I was well aware that things could
> > > change in the future. According to the guidelines in the
> > > documentation userspace can rely on it which was accurate since the
> > > interface didn't change for 4 years. But the guidelines also mention
> > > that changes can occur before the interfaces are move to stables, and
> > > that programs are encouraged to manifest their interest by adding
> > > their name to the "users" field.
> > >
> > > The interface was changed in 5.2 to support coresight from ACPI and
> > > make things easier to understand for users. It is a lot more
> > > intuitive to associate an ETM tracer with the CPU it belongs to by
> > > referring to the CPU number than the memory mapped address. Given the
> > > "testing" status of the interface and the absence of registered users
> > > I decided to move forward with the change. If "testing" is too strict
> > > for that I suggest to add an "experimental" category where it would be
> > > more acceptable to change things as subsystems mature.
> >
> > "testing" is not really "testing" if you have userspace tools/programs
> > assuming the location and contents of specific files in sysfs.
> >
> > You can change things in sysfs by creating new files, but to do
> > wholesale renaming like you did here can be very dangerous as you might
> > be breaking things.
>
> Yes, something I have definitely considered.
>
> > Usually new files are created, not existing ones
> > moved.
>
> In this case it would have meant a new symbolic link for every
> coresight device, so twice a many entries under
> $(SYS)/bus/coresight/device/. That would have been a lot of clutter
> and an increasing source of problems as the number of CPU and sinks
> increases. To me, and given the permissive definition of "testing"
> found in the documentation, a clean break was a better option.
Well, "testing" doesn't really matter in the end, if a tool/user relies
on it, we have to keep it working properly.
> > What tools use these today? What is going to break?
>
> Other than local shell scripts I am not aware of any tools using these
> today. I am certainly open to discuss a better alternative but right
> now, I just don't see one.
Be aware that you might have to change this back if there is any
objections.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 25/36] spi: s3c24xx: use devm_platform_ioremap_resource() to simplify code
From: Mark Brown @ 2019-09-04 16:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: tmaimon77, palmer, tali.perry1, eric, ldewangan, linux-riscv,
festevam, f.fainelli, benjaminfair, shc_work, khilman, openbmc,
YueHaibing, michal.simek, jonathanh, yuenn, wens, agross,
bcm-kernel-feedback-list, linux-imx, linux-arm-msm, linux-tegra,
Andi Shyti, rjui, s.hauer, mripard,
linux-samsung-soc@vger.kernel.org, linux-mediatek,
linux-rpi-kernel, paul.walmsley, matthias.bgg, linux-amlogic,
linux-arm-kernel, baohua, sbranden, yamada.masahiro, avifishman70,
venture, linux-kernel@vger.kernel.org, linux-spi, thierry.reding,
wahrenst, kernel, kgene, shawnguo
In-Reply-To: <CAJKOXPeRtbAvmR-=8Qa8ukGXt-cCj3ud_7y1Z4LgRpX3YCeumg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1366 bytes --]
On Wed, Sep 04, 2019 at 05:09:45PM +0200, Krzysztof Kozlowski wrote:
> On Wed, 4 Sep 2019 at 16:39, Mark Brown <broonie@kernel.org> wrote:
> > I think it's reasonable, it's giving credit to the automated system
> > they've got running coccinelle (which they do mention in their commit
> > logs). It doesn't really hurt anyone and lets people see their system
> > is finding stuff.
> Running internally coccinelle is already credited with commit author.
> The credits are coming with "From:" field.
I guess if other people look at the same CI and send patches as well
then there's some use tying them all together.
> Otherwise for commits I send I could use:
> From: krzk
> ...
> Reported-by: www.krzk.eu
> Signed-off-by: krzk
> To me it is ridiculous.
Sure, on the other hand it doesn't really cost anyone anything if you do
that.
> Different thing is that Reported-by is for fixing bugs or issues.
> There is no bug here. There is no problem solved except making the
> code smaller. That's not what is Reported-by for.
That is true, this one isn't fixing any bug but then the line does get a
bit fuzzy all round with things like warnings and coccinelle output -
even just having the warning pop up is noise for people looking at the
output even if there's no concrete problem. Again I don't see it as
something that's worth getting worked up over.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/1] arm64: dts: qcom: Add Lenovo Yoga C630
From: Lee Jones @ 2019-09-04 16:12 UTC (permalink / raw)
To: Sudeep Holla
Cc: mark.rutland, devicetree, linux-arm-msm, linux-kernel, robh+dt,
bjorn.andersson, agross, linux-arm-kernel
In-Reply-To: <20190904141257.GB6144@bogus>
On Wed, 04 Sep 2019, Sudeep Holla wrote:
> On Wed, Sep 04, 2019 at 01:16:06PM +0100, Lee Jones wrote:
> > From: Bjorn Andersson <bjorn.andersson@linaro.org>
> >
> > The Lenovo Yoga C630 is built on the SDM850 from Qualcomm, but this seem
> > to be similar enough to the SDM845 that we can reuse the sdm845.dtsi.
> >
> > Supported by this patch is: keyboard, battery monitoring, UFS storage,
> > USB host and Bluetooth.
> >
>
> Just curious to know if the idea of booting using ACPI is completely
> dropped as it's extremely difficult(because the firmware is so hacked
> up and may violate spec, just my opinion) for whatever reasons.
Once [0] is applied, we can boot Mainline using ACPI.
> We just made ACPI table version checking more lenient for this platform
> and would be good to know if we continue to run ACPI on that or will
> abandon and just use DT.
Which patch are you referring to? If you mean the ACPI v5.0 vs v5.1
patch authored by Ard, then yes I know, I instigated it's existence
due to these devices.
DT will *always* be more enabled than ACPI, so it's advised that you
use DT for anything useful. ACPI booting is ideal for things like
installing distros however, since they do not tend to provide DTBs in
their installers.
[0] https://lkml.org/lkml/2019/9/3/580
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 11/11] coresight: etm4x: docs: Adds detailed document for programming etm4x.
From: Mathieu Poirier @ 2019-09-04 16:09 UTC (permalink / raw)
To: Mike Leach
Cc: Jonathan Corbet, Greg Kroah-Hartman, Coresight ML,
Suzuki K. Poulose, open list:DOCUMENTATION, linux-arm-kernel
In-Reply-To: <CAJ9a7VhM1H+yGWCXw5q4ONELQfPX2Z+dhLqxPJ95CENV3MUarA@mail.gmail.com>
On Tue, 3 Sep 2019 at 16:47, Mike Leach <mike.leach@linaro.org> wrote:
>
> Hi Mathieu,
>
> On Tue, 3 Sep 2019 at 20:38, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >
> > Hi Mike,
> >
> > On Thu, Aug 29, 2019 at 10:33:21PM +0100, Mike Leach wrote:
> > > Add in detailed programmers reference for users wanting to program the
> > > CoreSight ETM 4.x driver using sysfs.
> > >
> > > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > > ---
> > > .../coresight/coresight-etm4x-reference.txt | 458 ++++++++++++++++++
> > > 1 file changed, 458 insertions(+)
> > > create mode 100644 Documentation/trace/coresight/coresight-etm4x-reference.txt
> > >
> > > diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.txt b/Documentation/trace/coresight/coresight-etm4x-reference.txt
> > > new file mode 100644
> > > index 000000000000..f0c370870992
> > > --- /dev/null
> > > +++ b/Documentation/trace/coresight/coresight-etm4x-reference.txt
> > > @@ -0,0 +1,458 @@
> > > +ETMv4 sysfs linux driver programming reference - v2.
> > > +====================================================
> > > +
> > > +Supplement to existing ETMv4 driver documentation.
> > > +
> > > +Sysfs files and directories
> > > +---------------------------
> > > +
> > > +Root: /sys/bus/coresight/devices/etm<N>
> > > +
> > > +
> > > +The following paragraphs explain the association between sysfs files and the
> > > +ETMv4 registers that they effect. Note the register names are given without
> > > +the ‘TRC’ prefix.
> > > +
> > > +File : mode (rw)
> > > +Trace Registers : {CONFIGR + others}
> > > +Notes : Bit select trace features. See ‘mode’ section below. Bits
> > > + in this will cause equivalent programming of trace config and
> > > + other registers to enable the features requested.
> > > +Syntax & eg : 'echo bitfield > mode'
> > > + bitfield up to 32 bits setting trace features.
> > > +Example : $> echo 0x > mode
> >
> > I suspect things look different on your end than they do on mine. The biggest
> > problem is related to multi-line fields. For instance the above looks like this
> > on my side:
> >
> > File : mode (rw)
> > Trace Registers : {CONFIGR + others}
> > Notes : Bit select trace features. See ‘mode’ section below. Bits
> > in this will cause equivalent programming of trace config and
> > other registers to enable the features requested.
> > Syntax & eg : 'echo bitfield > mode'
> > bitfield up to 32 bits setting trace features.
> > Example : $> echo 0x > mode
> >
> > It would be nicer to have multi-line fields aligned with the first line, such
> > as:
> >
> > File : mode (rw)
> > Trace Registers : {CONFIGR + others}
> > Notes : Bit select trace features. See ‘mode’ section below. Bits
> > in this will cause equivalent programming of trace config and
> > other registers to enable the features requested.
> > Syntax & eg : 'echo bitfield > mode'
> > bitfield up to 32 bits setting trace features.
> > Example : $> echo 0x > mode
> >
>
> Problem is I am not seeing any difference between what you say I am
> writing and what you prefer. When i looked at the file in my text
> editor the fields where aligned - I would not have submitted it
> otherwise.
Indeed - I suspected that much.
> I am happy to revisit it but we need a way of seeing a common view.
Agreed
>
>
> > I'm also not sure about the prompt, i.e "$>". I suspect it should be "$" and
> > an additional ">" got inserted.
>
> prompt came from examples lifted from a DB410 session. Don't really
> have any strong preference for what represents a prompt in the docs,
> so happy to change it to anything appropriate.
Ok, I wasn't sure if this was really the prompt you were getting of corruption.
>
> Regards
>
> Mike
>
> >
> > I wanted to read on but is it too difficult to know what is intentional and what
> > isn't. Please address and resend.
> >
> > Thanks,
> > Mathieu
> >
> > > +
> > > +File : reset (wo)
> > > +Trace Registers : All
> > > +Notes : Reset all programming to trace nothing / no logic programmed.
> > > +Syntax : 'echo 1 > reset'
> > > +
> > > +File : enable_source (wo)
> > > +Trace Registers : PRGCTLR, All hardware regs.
> > > +Notes : >0: Programs up the hardware with the current values held in
> > > + the driver and enables trace.
> > > + 0: disable trace hardware.
> > > +Syntax : 'echo 1 > enable_source'
> > > +
> > > +File : cpu (ro)
> > > +Trace Registers : None.
> > > +Notes : CPU ID that this ETM is attached to.
> > > +Example :$> cat cpu
> > > + $> 0
> > > +
> > > +File : addr_idx (rw)
> > > +Trace Registers : None.
> > > +Notes : Virtual register to index address comparator and range
> > > + features. Set index for first of the pair in a range.
> > > +Syntax : 'echo idx > addr_idx'
> > > + Where idx < nr_addr_cmp x 2
> > > +
> > > +File : addr_range (rw)
> > > +Trace Registers : ACVR[idx, idx+1], VIIECTLR
> > > +Notes : Pair of addresses for a range selected by addr_idx. Include
> > > + / exclude according to the optional parameter, or if omitted
> > > + uses the current ‘mode’ setting. Select comparator range in
> > > + control register. Error if index is odd value.
> > > +Depends : mode, addr_idx
> > > +Syntax : 'echo addr1 addr2 [exclude] > addr_range'
> > > + Where addr1 and addr2 define the range and addr1 < addr2.
> > > + Optional exclude value - 0 for include, 1 for exclude.
> > > +Example : $> echo 0x0000 0x2000 0 > addr_range
> > > +
> > > +File : addr_single (rw)
> > > +Trace Registers : ACVR[idx]
> > > +Notes : Set a single address comparator according to addr_idx. This
> > > + is used if the address comparator is used as part of event
> > > + generation logic etc.
> > > +Depends : addr_idx
> > > +Syntax : 'echo addr1 > addr_single'
> > > +
> > > +File : addr_start (rw)
> > > +Trace Registers : ACVR[idx], VISSCTLR
> > > +Notes : Set a trace start address comparator according to addr_idx.
> > > + Select comparator in control register.
> > > +Depends : addr_idx
> > > +Syntax : 'echo addr1 > addr_start'
> > > +
> > > +File : addr_stop (rw)
> > > +Trace Registers : ACVR[idx], VISSCTLR
> > > +Notes : Set a trace stop address comparator according to addr_idx.
> > > + Select comparator in control register.
> > > +Depends : addr_idx
> > > +Syntax : 'echo addr1 > addr_stop'
> > > +
> > > +File : addr_context (rw)
> > > +Trace Registers : ACATR[idx,{6:4}]
> > > +Notes : Link context ID comparator to address comparator addr_idx
> > > +Depends : addr_idx.
> > > +Syntax : 'echo ctxt_idx > addr_context'
> > > + Where ctxt_idx is the index of the linked context id / vmid
> > > + comparator.
> > > +
> > > +File : addr_ctxtype (rw)
> > > +Trace Registers : ACATR[idx,{3:2}]
> > > +Notes : Input value string. Set type for linked context ID comparator
> > > +Depends : addr_idx
> > > +Syntax : 'echo type > addr_ctxtype'
> > > + Type one of {all, vmid, ctxid, none}
> > > +Example : $> echo ctxid > addr_ctxtype
> > > +
> > > +File : addr_exlevel_s_ns (rw)
> > > +Trace Registers : ACATR[idx,{14:8}]
> > > +Notes : Set the ELx secure and non-secure matching bits for the
> > > + selected address comparator
> > > +Depends : addr_idx
> > > +Syntax : 'echo val > addr_exlevel_s_ns'
> > > + val is a 7 bit value for exception levels to exclude. Input
> > > + value shifted to correct bits in register.
> > > +Example : $> echo 0x4F > addr_exlevel_s_ns
> > > +
> > > +File : addr_instdatatype (rw)
> > > +Trace Registers : ACATR[idx,{1:0}]
> > > +Notes : Set the comparator address type for matching. Driver only
> > > + supports setting instruction address type.
> > > +Depends : addr_idx
> > > +
> > > +File : addr_cmp_view (ro)
> > > +Trace Registers : ACVR[idx, idx+1], ACATR[idx], VIIECTLR
> > > +Notes : Read the currently selected address comparator. If part of
> > > + address range then display both addresses.
> > > +Depends : addr_idx
> > > +Syntax : 'cat addr_cmp_view'
> > > +Example : $> cat addr_cmp_view
> > > + addr_cmp[0] range 0x0 0xffffffffffffffff include ctrl(0x4b00)
> > > +
> > > +File : nr_addr_cmp (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of address comparator pairs
> > > +
> > > +File : sshot_idx (rw)
> > > +Trace Registers : None
> > > +Notes : Select single shot register set.
> > > +
> > > +File : sshot_ctrl (rw)
> > > +Trace Registers : SSCCR[idx]
> > > +Notes : Access a single shot comparator control register.
> > > +Depends : sshot_idx
> > > +Syntax : 'echo val > sshot_ctrl'
> > > + Writes val into the selected control register.
> > > +
> > > +File : sshot_status (ro)
> > > +Trace Registers : SSCSR[idx]
> > > +Notes : Read a single shot comparator status register
> > > +Depends : sshot_idx
> > > +Syntax : 'cat sshot_status'
> > > + Read status.
> > > +Example : $> cat sshot_status
> > > + 0x1
> > > +
> > > +File : sshot_pe_ctrl (rw)
> > > +Trace Registers : SSPCICR[idx]
> > > +Notes : Access a single shot PE comparator input control register.
> > > +Depends : sshot_idx
> > > +Syntax : echo val > sshot_pe_ctrl
> > > + Writes val into the selected control register.
> > > +
> > > +File : ns_exlevel_vinst (rw)
> > > +Trace Registers : VICTLR{23:20}
> > > +Notes : Program non-secure exception level filters. Set / clear NS
> > > + exception filter bits. Setting ‘1’ excludes trace from the
> > > + exception level.
> > > +Syntax : 'echo bitfield > ns_exlevel_viinst'
> > > + Where bitfield contains bits to set clear for EL0 to EL2
> > > +Example : %> echo 0x4 > ns_exlevel_viinst
> > > + ; Exclude EL2 NS trace.
> > > +
> > > +File : vinst_pe_cmp_start_stop (rw)
> > > +Trace Registers : VIPCSSCTLR
> > > +Notes : Access PE start stop comparator input control registers
> > > +
> > > +File : bb_ctrl (rw)
> > > +Trace Registers : BBCTLR
> > > +Notes : Define ranges that Branch Broadcast will operate in.
> > > + Default (0x0) is all addresses.
> > > +Depends : BB enabled.
> > > +
> > > +File : cyc_threshold (rw)
> > > +Trace Registers : CCCTLR
> > > +Notes : Set the threshold for which cycle counts will be emitted.
> > > + Error if attempt to set below minimum defined in IDR3, masked
> > > + to width of valid bits.
> > > +Depends : CC enabled.
> > > +
> > > +File : syncfreq (rw)
> > > +Trace Registers : SYNCPR
> > > +Notes : Set trace synchronisation period. Power of 2 value, 0 (off)
> > > + or 8-20. Driver defaults to 12 (every 4096 bytes).
> > > +
> > > +File : cntr_idx (rw)
> > > +Trace Registers : none
> > > +Notes : Select the counter to access
> > > +Syntax : 'echo idx > cntr_idx'
> > > + Where idx < nr_cntr
> > > +
> > > +File : cntr_ctrl (rw)
> > > +Trace Registers : CNTCTLR[idx]
> > > +Notes : Set counter control value
> > > +Depends : cntr_idx
> > > +Syntax : 'echo val > cntr_ctrl'
> > > + Where val is per ETMv4 spec.
> > > +
> > > +File : cntrldvr (rw)
> > > +Trace Registers : CNTRLDVR[idx]
> > > +Notes : Set counter reload value
> > > +Depends : cntr_idx
> > > +Syntax : 'echo val > cntrldvr'
> > > + Where val is per ETMv4 spec.
> > > +
> > > +File : nr_cntr (ro)
> > > +Trace Registers : From IDR5
> > > +Notes : Number of counters implemented.
> > > +
> > > +File : ctxid_idx (rw)
> > > +Trace Registers : None
> > > +Notes : Select the context ID comparator to access
> > > +Syntax : 'echo idx > ctxid_idx'
> > > + Where idx < numcidc
> > > +
> > > +File : ctxid_pid (rw)
> > > +Trace Registers : CIDCVR[idx]
> > > +Notes : Set the context ID comparator value
> > > +Depends : ctxid_idx
> > > +
> > > +File : ctxid_masks (rw)
> > > +Trace Registers : CIDCCTLR0, CIDCCTLR1, CIDCVR<0-7>
> > > +Notes : Pair of values to set the byte masks for 1-8 context ID
> > > + comparators. Automatically clears masked bytes to 0 in CID
> > > + value registers.
> > > +Syntax : 'echo m3m2m1m0 [m7m6m5m4] > ctxid_masks'
> > > + 32 bit values made up of mask bytes, where mN represents a
> > > + byte mask value for Ctxt ID comparator N.
> > > + Second value not required on systems that have fewer than 4
> > > + context ID comparators
> > > +
> > > +File : numcidc (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of Context ID comparators
> > > +
> > > +File : vmid_idx (rw)
> > > +Trace Registers : None
> > > +Notes : Select the VM ID comparator to access.
> > > +Syntax : 'echo idx > vmid_idx'
> > > + Where idx < numvmidc
> > > +
> > > +File : vmid_val (rw)
> > > +Trace Registers : VMIDCVR[idx]
> > > +Notes : Set the VM ID comparator value
> > > +Depends : vmid_idx
> > > +
> > > +File : vmid_masks (rw)
> > > +Trace Registers : VMIDCCTLR0, VMIDCCTLR1, VMIDCVR<0-7>
> > > +Notes : Pair of values to set the byte masks for 1-8 VM ID
> > > + comparators. Automatically clears masked bytes to 0 in VMID
> > > + value registers.
> > > +Syntax : 'echo m3m2m1m0 [m7m6m5m4] > vmid_masks'
> > > + Where mN represents a byte mask value for VMID comparator N.
> > > + Second value not required on systems that have fewer than
> > > + 4 VMID comparators.
> > > +
> > > +File : numvmidc (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of VMID comparators
> > > +
> > > +File : res_idx (rw)
> > > +Trace Registers : None.
> > > +Notes : Select the resource selector control to access. Must be 2 or
> > > + higher as selectors 0 and 1 are hardwired.
> > > +Syntax : 'echo idx > res_idx'
> > > + Where 2 <= idx < nr_resource x 2
> > > +
> > > +File : res_ctrl (rw)
> > > +Trace Registers : RSCTLR[idx]
> > > +Notes : Set resource selector control value. Value per ETMv4 spec.
> > > +Depends : res_idx
> > > +Syntax : 'echo val > res_cntr'
> > > + Where val is per ETMv4 spec.
> > > +
> > > +File : nr_resource (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of resource selector pairs
> > > +
> > > +File : event (rw)
> > > +Trace Registers : EVENTCTRL0R
> > > +Notes : Set up to 4 implemented event fields.
> > > +Syntax : 'echo ev3ev2ev1ev0 > event'
> > > + Where evN is an 8 bit event field. Up to 4 event fields make up
> > > + the 32bit input value. Number of valid fields implementation
> > > + dependent defined in IDR0.
> > > +
> > > +File : event_instren (rw)
> > > +Trace Registers : EVENTCTRL1R
> > > +Notes : Choose events which insert event packets into trace stream.
> > > +Depends : EVENTCTRL0R
> > > +Syntax : 'echo bitfield > event_instren'
> > > + Where bitfield is up to 4 bits according to number of event
> > > + fields.
> > > +
> > > +File : event_ts (rw)
> > > +Trace Registers : TSCTLR
> > > +Notes : Set the event that will generate timestamp requests.
> > > +Depends : TS activated
> > > +Syntax : 'echo evfield > event_ts'
> > > + Where evfield is an 8 bit event selector.
> > > +
> > > +File : seq_idx (rw)
> > > +Trace Registers : None
> > > +Notes : Sequencer event register select - 0 to 2
> > > +
> > > +
> > > +File : seq_state (rw)
> > > +Trace Registers : SEQSTR
> > > +Notes : Sequencer current state - 0 to 3.
> > > +
> > > +File : seq_event (rw)
> > > +Trace Registers : SEQEVR[idx]
> > > +Notes : State transition event registers
> > > +Depends : seq_idx
> > > +Syntax : 'echo evBevF > seq_event'
> > > + Where evBevF is a 16 bit value made up of two event selectors,
> > > + evB - back, evF - forwards.
> > > +
> > > +File : seq_reset_event (rw)
> > > +Trace Registers : SEQRSTEVR
> > > +Notes : Sequencer reset event
> > > +Syntax : 'echo evfield > seq_reset_event'
> > > + Where evfield is an 8 bit event selector.
> > > +
> > > +File : nrseqstate (ro)
> > > +Trace Registers : From IDR5
> > > +Notes : Number of sequencer states (0 or 4)
> > > +
> > > +File : nr_pe_cmp (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of PE comparator inputs
> > > +
> > > +File : nr_ext_inp (ro)
> > > +Trace Registers : From IDR5
> > > +Notes : Number of external inputs
> > > +
> > > +File : nr_ss_cmp (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of Single Shot control registers
> > > +
> > > +Note: When programming any address comparator the driver will tag the
> > > +comparator with a type used - i.e. RANGE, SINGLE, START, STOP. Once this tag
> > > +is set, then only the values can be changed using the same sysfs file / type
> > > +used to program it.
> > > +
> > > +Thus:-
> > > +% echo 0 > addr_idx ; select address comparator 0
> > > +% echo 0x1000 0x5000 0 > addr_range ; set address range on comparators 0 and 1.
> > > +% echo 0x2000 > addr_start ; this will error as comparator 0 is a
> > > + ; range comparator
> > > +% echo 2 > addr_idx ; select address comparator 2
> > > +% echo 0x2000 > addr_start ; this is OK as comparator 2 is unused,
> > > +% echo 0x3000 > addr_stop ; this will error as comparator 2 a start
> > > + ; address comparator
> > > +% echo 2 > addr_idx ; select address comparator 3
> > > +% echo 0x3000 > addr_stop ; this is OK
> > > +
> > > +To remove programming on all the comparators (and all the other hardware) use
> > > +the reset parameter:
> > > +
> > > +% echo 1 > reset
> > > +
> > > +The ‘mode’ sysfs parameter.
> > > +---------------------------
> > > +
> > > +This is a bitfield selection parameter that sets the overall trace mode for the
> > > +ETM. The table below describes the bits, using the defines from the driver
> > > +source file, along with a description of the feature these represent. Many
> > > +features are optional and therefore dependent on implementation in the
> > > +hardware.
> > > +
> > > +Bit assignements shown below:-
> > > +
> > > +bit (0) : #define ETM_MODE_EXCLUDE
> > > +description : This is the default value for the include / exclude function when
> > > + setting address ranges. Set 1 for exclude range. When the mode
> > > + parameter is set this value is applied to the currently indexed
> > > + address range.
> > > +
> > > +bit (4) : #define ETM_MODE_BB
> > > +description : Set to enable branch broadcast if supported in hardware [IDR0].
> > > +
> > > +bit (5) : #define ETMv4_MODE_CYCACC
> > > +description : Set to enable cycle accurate trace if supported [IDR0].
> > > +
> > > +bit (6) : ETMv4_MODE_CTXID
> > > +description : Set to enable context ID tracing if supported in hardware [IDR2].
> > > +
> > > +bit (7) : ETM_MODE_VMID
> > > +description : Set to enable virtual machine ID tracing if supported [IDR2].
> > > +
> > > +bit (11) : ETMv4_MODE_TIMESTAMP
> > > +description : Set to enable timestamp generation if supported [IDR0].
> > > +
> > > +bit (12) : ETM_MODE_RETURNSTACK
> > > +description : Set to enable trace return stack use if supported [IDR0].
> > > +
> > > +bit (13-14) : ETM_MODE_QELEM(val)
> > > +description : ‘val’ determines level of Q element support enabled if
> > > + implemented by the ETM [IDR0]
> > > +
> > > +bit (19) : ETM_MODE_ATB_TRIGGER
> > > +description : Set to enable the ATBTRIGGER bit in the event control register
> > > + [EVENTCTLR1] if supported [IDR5].
> > > +
> > > +bit (20) : ETM_MODE_LPOVERRIDE
> > > +description : Set to enable the LPOVERRIDE bit in the event control register
> > > + [EVENTCTLR1], if supported [IDR5].
> > > +
> > > +bit (21) : ETM_MODE_ISTALL_EN
> > > +description : Set to enable the ISTALL bit in the stall control register
> > > + [STALLCTLR]
> > > +
> > > +bit (23) : ETM_MODE_INSTPRIO
> > > +description : Set to enable the INSTPRIORITY bit in the stall control register
> > > + [STALLCTLR] , if supported [IDR0].
> > > +
> > > +bit (24) : ETM_MODE_NOOVERFLOW
> > > +description : Set to enable the NOOVERFLOW bit in the stall control register
> > > + [STALLCTLR], if supported [IDR3].
> > > +
> > > +bit (25) : ETM_MODE_TRACE_RESET
> > > +description : Set to enable the TRCRESET bit in the viewinst control register
> > > + [VICTLR] , if supported [IDR3].
> > > +
> > > +bit (26) : ETM_MODE_TRACE_ERR
> > > +description : Set to enable the TRCCTRL bit in the viewinst control register
> > > + [VICTLR].
> > > +
> > > +bit (27) : ETM_MODE_VIEWINST_STARTSTOP
> > > +description : Set the initial state value of the ViewInst start / stop logic
> > > + in the viewinst control register [VICTLR]
> > > +
> > > +bit (30) : ETM_MODE_EXCL_KERN
> > > +description : Set default trace setup to exclude kernel mode trace (see note a)
> > > +
> > > +bit (31) : ETM_MODE_EXCL_USER
> > > +description : Set default trace setup to exclude user space trace (see note a)
> > > +
> > > +Note a) On startup the ETM is programmed to trace the complete address space
> > > +using address range comparator 0. ‘mode’ bits 30 / 31 modify this setting to
> > > +set EL exclude bits for NS state in either user space (EL0) or kernel space
> > > +(EL1) in the address range comparator. (the default setting excludes all
> > > +secure EL, and NS EL2)
> > > +
> > > +Once the reset parameter has been used, and/or custom programming has been
> > > +implemented - using these bits will result in the EL bits for address
> > > +comparator 0 being set in the same way.
> > > +
> > > +Note b) Bits 2-3, 8-10, 15-16, 18, 22, control features that only work with
> > > +data trace. As A profile data trace is architecturally prohibited in ETMv4,
> > > +these have been omitted here. Possible uses could be where a kernel has
> > > +support for control of R or M profile infrastructure as part of a heterogeneous
> > > +system.
> > > +
> > > +Bits 17, 28-29 are unused.
> > > --
> > > 2.17.1
> > >
>
>
>
> --
> Mike Leach
> Principal Engineer, ARM Ltd.
> Manchester Design Centre. UK
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.
From: Mathieu Poirier @ 2019-09-04 16:05 UTC (permalink / raw)
To: Greg KH
Cc: Jon Corbet, Coresight ML, open list:DOCUMENTATION,
linux-arm-kernel, Suzuki K. Poulose, Mike Leach
In-Reply-To: <20190904054809.GB4511@kroah.com>
On Tue, 3 Sep 2019 at 23:48, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Sep 03, 2019 at 04:51:40PM -0600, Mathieu Poirier wrote:
> > On Tue, 3 Sep 2019 at 13:59, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Thu, Aug 29, 2019 at 10:33:19PM +0100, Mike Leach wrote:
> > > > Update document to include the new sysfs features added during this
> > > > patchset.
> > > >
> > > > Updated to reflect the new sysfs component nameing schema.
> > > >
> > > > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > > > ---
> > > > .../testing/sysfs-bus-coresight-devices-etm4x | 183 +++++++++++-------
> > > > 1 file changed, 115 insertions(+), 68 deletions(-)
> > > >
> > > > diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > index 36258bc1b473..112c50ae9986 100644
> > > > --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > @@ -1,4 +1,4 @@
> > > > -What: /sys/bus/coresight/devices/<memory_map>.etm/enable_source
> > > > +What: /sys/bus/coresight/devices/etm<N>/enable_source
> > >
> > > You are renaming sysfs directories that have been around since:
> > >
> > > > Date: April 2015
> > >
> > > ???
> > >
> > > Really?
> > >
> > > That's brave.
> >
> >
> > When I worked on the coresight sysfs ABI a while back I specifically
> > added it at the "testing" level as I was well aware that things could
> > change in the future. According to the guidelines in the
> > documentation userspace can rely on it which was accurate since the
> > interface didn't change for 4 years. But the guidelines also mention
> > that changes can occur before the interfaces are move to stables, and
> > that programs are encouraged to manifest their interest by adding
> > their name to the "users" field.
> >
> > The interface was changed in 5.2 to support coresight from ACPI and
> > make things easier to understand for users. It is a lot more
> > intuitive to associate an ETM tracer with the CPU it belongs to by
> > referring to the CPU number than the memory mapped address. Given the
> > "testing" status of the interface and the absence of registered users
> > I decided to move forward with the change. If "testing" is too strict
> > for that I suggest to add an "experimental" category where it would be
> > more acceptable to change things as subsystems mature.
>
> "testing" is not really "testing" if you have userspace tools/programs
> assuming the location and contents of specific files in sysfs.
>
> You can change things in sysfs by creating new files, but to do
> wholesale renaming like you did here can be very dangerous as you might
> be breaking things.
Yes, something I have definitely considered.
> Usually new files are created, not existing ones
> moved.
In this case it would have meant a new symbolic link for every
coresight device, so twice a many entries under
$(SYS)/bus/coresight/device/. That would have been a lot of clutter
and an increasing source of problems as the number of CPU and sinks
increases. To me, and given the permissive definition of "testing"
found in the documentation, a clean break was a better option.
>
> What tools use these today? What is going to break?
Other than local shell scripts I am not aware of any tools using these
today. I am certainly open to discuss a better alternative but right
now, I just don't see one.
>
> thanks,
> greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] bus: imx-weim: remove incorrect __init annotations
From: Nick Desaulniers @ 2019-09-04 16:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sven Van Asbroeck, Rob Herring, Ilie Halip, Shawn Guo,
Sascha Hauer, LKML, clang-built-linux, NXP Linux Team,
Pengutronix Kernel Team, Nathan Chancellor, Fabio Estevam,
Linux ARM
In-Reply-To: <20190904160039.3350229-1-arnd@arndb.de>
On Wed, Sep 4, 2019 at 9:00 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> The probe function is no longer __init, so anything it calls now
> must also be available at runtime, as Kbuild points out when building
> with clang-9:
Thanks for the patch, this has already been addressed in:
https://patchwork.kernel.org/patch/11114307/
https://github.com/ClangBuiltLinux/linux/issues/645
>
> WARNING: vmlinux.o(.text+0x6e7040): Section mismatch in reference from the function weim_probe() to the function .init.text:imx_weim_gpr_setup()
> The function weim_probe() references
> the function __init imx_weim_gpr_setup().
> This is often because weim_probe lacks a __init
> annotation or the annotation of imx_weim_gpr_setup is wrong.
>
> WARNING: vmlinux.o(.text+0x6e70f0): Section mismatch in reference from the function weim_probe() to the function .init.text:weim_timing_setup()
> The function weim_probe() references
> the function __init weim_timing_setup().
> This is often because weim_probe lacks a __init
> annotation or the annotation of weim_timing_setup is wrong.
>
> Remove the remaining __init markings that are now wrong.
>
> Fixes: 4a92f07816ba ("bus: imx-weim: use module_platform_driver()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> I applied this on top of the patch taht introduced the build error
>
> drivers/bus/imx-weim.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index 79af0c27f5a3..28bb65a5613f 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -76,7 +76,7 @@ static const struct of_device_id weim_id_table[] = {
> };
> MODULE_DEVICE_TABLE(of, weim_id_table);
>
> -static int __init imx_weim_gpr_setup(struct platform_device *pdev)
> +static int imx_weim_gpr_setup(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct property *prop;
> @@ -126,10 +126,10 @@ static int __init imx_weim_gpr_setup(struct platform_device *pdev)
> }
>
> /* Parse and set the timing for this device. */
> -static int __init weim_timing_setup(struct device *dev,
> - struct device_node *np, void __iomem *base,
> - const struct imx_weim_devtype *devtype,
> - struct cs_timing_state *ts)
> +static int weim_timing_setup(struct device *dev,
> + struct device_node *np, void __iomem *base,
> + const struct imx_weim_devtype *devtype,
> + struct cs_timing_state *ts)
> {
> u32 cs_idx, value[MAX_CS_REGS_COUNT];
> int i, ret;
> --
> 2.20.0
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20190904160039.3350229-1-arnd%40arndb.de.
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 00/10] arm64: Stolen time support
From: Steven Price @ 2019-09-04 16:02 UTC (permalink / raw)
To: Andrew Jones
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190903084921.zikiucdruymfgfsq@kamzik.brq.redhat.com>
On 03/09/2019 09:49, Andrew Jones wrote:
> On Tue, Sep 03, 2019 at 10:03:48AM +0200, Andrew Jones wrote:
>> Hi Steven,
>>
>> I had some fun testing this series with the KVM selftests framework. It
>> looks like it works to me, so you may add
>>
>> Tested-by: Andrew Jones <drjones@redhat.com>
>>
>
> Actually, I probably shouldn't be quite so generous with this tag yet,
> because I haven't yet tested the guest-side changes. To do that I'll
> need to start prototyping something for QEMU. I need to finish some other
> stuff first, but then I can do that.
Thanks for the testing, I'll wait for your other testing before adding
your Tested-by tag.
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox