* [PATCH] ARM: multi_v7_defconfig: enable CONFIG_EFI
From: Jon Hunter @ 2016-09-30 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473949700-12814-1-git-send-email-ard.biesheuvel@linaro.org>
Hi Ard,
On 15/09/16 15:28, Ard Biesheuvel wrote:
> This enables CONFIG_EFI for multi_v7_defconfig, which adds support for
> booting via EFI, and for the EFI framebuffer as builtin options. It
> also enables the EFI rtc, the EFI variable pseudo-filesystem and the
> EFI capsule loader as modules.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> We have been happily booting multi_v7_defconfig+CONFIG_EFI=y kernels on
> kernelci for months now, so please consider enabling this by default.
> The increase in compressed kernel footprint is ~30 KB, for the uncompressed
> kernel it's ~10 KB, some of which is .init code.
After this patch was applied the Tegra automated building for
multi_v7_defconfig has been failing on -next [0]. The error I am seeing
is as follows ...
STUBCPY drivers/firmware/efi/libstub/lib-sort.stub.o
00000000 R_ARM_ABS32 sort
00000004 R_ARM_ABS32 __ksymtab_strings
drivers/firmware/efi/libstub/lib-sort.stub.o: absolute symbol references
not allowed in the EFI stub
make[4]: *** [drivers/firmware/efi/libstub/lib-sort.stub.o] Error 1
make[3]: *** [drivers/firmware/efi/libstub] Error 2
make[2]: *** [drivers/firmware/efi] Error 2
make[1]: *** [drivers/firmware] Error 2
make: *** [drivers] Error 2
The toolchain this builder uses (which is quite old admittedly) is ...
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
I am not seeing this error on other machines but for the life of me, I
cannot figure out why this one is failing. Any thoughts?
Cheers
Jon
[0] http://nvtb.github.io/linux-next/
--
nvpublic
^ permalink raw reply
* [PATCH] clk: mvebu: armada-37xx-periph: Fix the clock gate flag
From: Gregory CLEMENT @ 2016-09-30 8:33 UTC (permalink / raw)
To: linux-arm-kernel
For the gate part of the peripheral clock setting the bit disables the
clock and clearing it enables the clock. This is not the default behavior
of clk_gate component, so we need to use the CLK_GATE_SET_TO_DISABLE flag.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/clk/mvebu/armada-37xx-periph.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/mvebu/armada-37xx-periph.c b/drivers/clk/mvebu/armada-37xx-periph.c
index d5dfbad4ceab..cecb0fdfaef6 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -329,6 +329,7 @@ static int armada_3700_add_composite_clk(const struct clk_periph_data *data,
gate->lock = lock;
gate_ops = gate_hw->init->ops;
gate->reg = reg + (u64)gate->reg;
+ gate->flags = CLK_GATE_SET_TO_DISABLE;
}
if (data->rate_hw) {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller
From: Jon Hunter @ 2016-09-30 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALw8SCUK0_kvNR_juAc7N_DMQbV=voizqXE6PApc_B_CQHzzOA@mail.gmail.com>
Rob,
On 19/09/16 08:21, Mirza Krak wrote:
> 2016-09-06 12:32 GMT+02:00 Jon Hunter <jonathanh@nvidia.com>:
>>
>> On 31/08/16 12:22, Mirza Krak wrote:
>>> 2016-08-30 19:06 GMT+02:00 Rob Herring <robh@kernel.org>:
>>
>> ...
>>
>>>>> nvidia,snor-cs = <4>;
>>>>
>>>> NAK, no custom CS properties.
>>
>> Ok, so ...
>>
>>> gmi at 70090000 {
>>> compatible = "nvidia,tegra20-gmi";
>>> reg = <0x70009000 0x1000>;
>>> #address-cells = <2>;
>>> #size-cells = <1>;
>>> clocks = <&tegra_car TEGRA20_CLK_NOR>;
>>> clock-names = "gmi";
>>> resets = <&tegra_car 42>;
>>> reset-names = "gmi";
>>> ranges = <4 0 0xd0000000 0xfffffff>;
>>>
>>> status = "okay";
>>>
>>> bus at 4,0 {
>>> compatible = "simple-bus";
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> ranges = <0 4 0 0x40000>;
>>>
>>> nvidia,snor-mux-mode;
>>> nvidia,snor-adv-inv;
>>>
>>> can at 0 {
>>> reg = <0 0x100>;
>>> ...
>>> };
>>>
>>> can at 40000 {
>>> reg = <0x40000 0x100>;
>>> ...
>>> };
>>> };
>>> };
>>>
>>> Have I understood you correct?
>>>
>>> Also wanted to verify the example case where you only have on device
>>> connected to one CS#, from what I see in other implementations it
>>> seems OK to put the CS# in the reg property in that case. Is this
>>> correct?
>>>
>>> Example with one SJA1000 CAN controller connected to the GMI bus
>>> on CS4:
>>>
>>> gmi at 70090000 {
>>> compatible = "nvidia,tegra20-gmi";
>>> reg = <0x70009000 0x1000>;
>>> #address-cells = <2>;
>>> #size-cells = <1>;
>>> clocks = <&tegra_car TEGRA20_CLK_NOR>;
>>> clock-names = "gmi";
>>> resets = <&tegra_car 42>;
>>> reset-names = "gmi";
>>> ranges = <4 0 0xd0000000 0xfffffff>;
>>>
>>> status = "okay";
>>>
>>> can at 4,0 {
>>> reg = <4 0 0x100>;
>>> nvidia,snor-mux-mode;
>>> nvidia,snor-adv-inv;
>>> ...
>>> };
>>> };
>>>
>>> Jon, to be able to handle both cases in the driver we would first
>>> attempt to decode the CS# from the ranges property, and fallback to
>>> reg property if no ranges are defined. Does that sound reasonable?
>>
>> Given the above examples that may be supported, is there a
>> better/simpler way to extract the CS# than what Mirza is proposing? For
>> example, from the node-name unit-address?
>>
>
> Hi.
>
> I have been on vacation and now I am back and wanted to finalize these
> patch series.
>
> So pinging this thread to see I we can agree on a solution.
>
> Rob any comments to my proposal and Jon`s comment?
Can you comment on the above?
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH] net: ethernet: mediatek: mark symbols static where possible
From: Baoyou Xie @ 2016-09-30 7:48 UTC (permalink / raw)
To: linux-arm-kernel
We get 2 warnings when building kernel with W=1:
drivers/net/ethernet/mediatek/mtk_eth_soc.c:2041:5: warning: no previous prototype for 'mtk_get_link_ksettings' [-Wmissing-prototypes]
drivers/net/ethernet/mediatek/mtk_eth_soc.c:2052:5: warning: no previous prototype for 'mtk_set_link_ksettings' [-Wmissing-prototypes]
In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ddf20a0..ad4ab97 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2038,8 +2038,8 @@ static int mtk_cleanup(struct mtk_eth *eth)
return 0;
}
-int mtk_get_link_ksettings(struct net_device *ndev,
- struct ethtool_link_ksettings *cmd)
+static int mtk_get_link_ksettings(struct net_device *ndev,
+ struct ethtool_link_ksettings *cmd)
{
struct mtk_mac *mac = netdev_priv(ndev);
@@ -2049,8 +2049,8 @@ int mtk_get_link_ksettings(struct net_device *ndev,
return phy_ethtool_ksettings_get(ndev->phydev, cmd);
}
-int mtk_set_link_ksettings(struct net_device *ndev,
- const struct ethtool_link_ksettings *cmd)
+static int mtk_set_link_ksettings(struct net_device *ndev,
+ const struct ethtool_link_ksettings *cmd)
{
struct mtk_mac *mac = netdev_priv(ndev);
--
2.7.4
^ permalink raw reply related
* [PATCH] Adding Support for Coresight Components on Zynq 7000.
From: Muhammad Abdul WAHAB @ 2016-09-30 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929143411.GE16583@xsjsorenbubuntu>
Hi S?ren,
Thank you for your remarks. I corrected a few things as you suggested.
> I'm curious, did you test that with external debug tools. I have the
> feeling the kernel using the debug HW could interfere with JTAG
> debuggers, external trace tools, etc.
I did not test with any external debug tools. For testing, I obtained
trace for simple function (e.g. loop) on Xilinx standalone and I then
traced the same function under Linux. Then, I compare both traces
obtained under standalone and under Linux. I decoded the trace to make
sure that the trace I get corresponds to my function. The instructions
for testing here only allows users to see that coresight components
are enabled and generating traces. The trace still need to be decoded
to make sure whether the trace is correct or not. It can be done by
openCSD[1] library.
> Use labels please.
I changed the entries to use labels. I don't need phandle anymore.
>> + tpiu at F8803000 {
>>>
>>> + compatible = "arm,coresight-tpiu", "arm,primecell";
>>> + reg = <0xf8803000 0x1000>;
>>> + clocks = <&clkc 47>, <&clkc 16>;
>>
>
> I'm not sure this is correct for every setup. Sorry, that I don't recall
> all the details, I haven't used tracing in a long time. But I guess this
> clock is configurable as you're referring an fclk here. The other thing
> that makes me a little suspicious is, that nothing in here uses the
> 'dbg_trc' clock that the clock controller provides.
The TPIU setup included in my patch is specific to my configuration of TPIU.
The second clock is configurable but I didn't know how to do so. As in
Vivado setup I chose "fclk1" as the clock for TPIU, I decided to put fclk1.
But, I am not sure about this. I am having some problems when I recover the
trace from TPIU: it is not the same as in ETB even though it resembles a
lot.
I don't know if the problem is coming from the device tree or from the
driver.
I will have a look at 'dbg_trc' clock.
>>
>> + clock-names = "apb_pclk", "fclk1";
>>
> Those names (at least fclk1) is not a good name for tpiu to identify
> it's input. fclk1 is a zynq-specific clock, and as mentioned above, it
> seems likely that this could easily become a different one. The
> clock-names are meant to identify an input from the consumer's
> perspective. The correct names should be documented in the DT binding.
The first name was chosen as "apb_pclk" because it was recommended in
Documentation. On the second name, I agree with you but again for TPIU DT
entry, I am not sure how to make this clock configurable. So, that's why
I put the same clock name as I had in my Vivado setup. If you have any
leads on how to make it configurable, I will be happy to take a look
into it.
>> + clock-frequency=<0xee6b280>;
>>
> I cannot find this property in the binding.
>
This property was described in clock binding (in an example [2]) and the
value here (250MHz) corresponds to the value I had chosen in Vivado for
TPIU input clock.
> I think nodes were ordered alphabetically in our DTs.
Yes, I modified the patch to take care of it. Thank you.
Muhammad Abdul WAHAB
[1]: https://github.com/Linaro/OpenCSD
[2]: Documentation/devicetree/bindings/clock/clock-bindings.txt
---
--- linux-4.7/arch/arm/boot/dts/zynq-7000.dtsi.orig 2016-07-24
21:23:50.000000000 +0200
+++ linux-4.7/arch/arm/boot/dts/zynq-7000.dtsi 2016-09-29
20:42:44.286322433 +0200
@@ -96,6 +96,57 @@
rx-fifo-depth = <0x40>;
};
+ etb at F8801000 {
+ compatible = "arm,coresight-etb10", "arm,primecell";
+ reg = <0xf8801000 0x1000>;
+
+ coresight-default-sink;
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+
+ port {
+ etb_in_port: endpoint at 0 {
+ slave-mode;
+ remote-endpoint = <&replicator_out_port0>;
+ };
+ };
+ };
+
+ funnel at F8804000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0xf8804000 0x1000>;
+
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+ ports {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+
+ port at 0 {
+ reg = <0x0>;
+ funnel_out_port0: endpoint {
+ remote-endpoint = <&replicator_in_port0>;
+ };
+ };
+
+ port at 1 {
+ reg = <0x0>;
+ funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&ptm0_out_port>;
+ };
+ };
+
+ port at 2 {
+ reg = <0x1>;
+ funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&ptm1_out_port>;
+ };
+ };
+ };
+ };
+
gpio0: gpio at e000a000 {
compatible = "xlnx,zynq-gpio-1.0";
#gpio-cells = <2>;
@@ -311,6 +362,82 @@
clocks = <&clkc 4>;
};
+ ptm0 at F889C000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0xf889c000 0x1000>;
+
+ cpu = <&cpu0>;
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+
+ port {
+ ptm0_out_port: endpoint {
+ remote-endpoint = <&funnel_in_port0>;
+ };
+ };
+ };
+
+ ptm1 at F889D000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0xf889d000 0x1000>;
+
+ cpu = <&cpu1>;
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+
+ port {
+ ptm1_out_port: endpoint {
+ remote-endpoint = <&funnel_in_port1>;
+ };
+ };
+ };
+
+ replicator {
+ compatible = "arm,coresight-replicator";
+
+ ports {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+
+ port at 0 {
+ reg = <0x0>;
+ replicator_out_port0: endpoint {
+ remote-endpoint = <&etb_in_port>;
+ };
+ };
+
+ port at 1 {
+ reg = <0x1>;
+ replicator_out_port1: endpoint {
+ remote-endpoint = <&tpiu_in_port>;
+ };
+ };
+
+ port at 2 {
+ reg = <0x0>;
+ replicator_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&funnel_out_port0>;
+ };
+ };
+ };
+ };
+
+ tpiu at F8803000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0xf8803000 0x1000>;
+
+ clocks = <&clkc 47>, <&clkc 46>;
+ clock-names = "apb_pclk", "configurable_clk";
+ clock-frequency=<0xee6b280>;
+
+ port {
+ tpiu_in_port: endpoint at 0 {
+ slave-mode;
+ remote-endpoint = <&replicator_out_port0>;
+ };
+ };
+ };
+
ttc0: timer at f8001000 {
interrupt-parent = <&intc>;
interrupts = <0 10 4>, <0 11 4>, <0 12 4>;
^ permalink raw reply
* [PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode
From: Magnus Damm @ 2016-09-30 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWBQcvOaFNCpt8DFHbT1uTkr6Li_seTmnVese_HPKsREA@mail.gmail.com>
Hi Geert,
On Fri, Sep 30, 2016 at 4:09 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Magnus,
>
> On Fri, Sep 30, 2016 at 9:04 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> On Tue, Sep 27, 2016 at 9:37 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Mon, Aug 22, 2016 at 4:44 PM, Geert Uytterhoeven
>>> <geert+renesas@glider.be> wrote:
>>>> This patch series is an attempt to allow booting secondary CPU cores on
>>>> R-Car Gen2 when hardware debug mode is enabled. In this mode, reset
>>>> requests derived from power-shutoff to the AP-system CPU cores must be
>>>> enabled before the AP-system cores first resume from power-shutoff. Else
>>>> resume may fail, causing the system to hang during boot. Currently we
>>>> avoid the hang by prohibiting booting secondary CPU cores when hardware
>>>> debug mode is enabled.
>>>>
>>>> On all R-Car Gen2 SoCs, hardware debug mode is enabled by setting
>>>> MD21=1. On both Koelsch and Lager, this is done by setting mode switch
>>>> SW8-4 to OFF.
>>>>
>>>> Unfortunately the hang is not easy to reproduce: I only saw it (on
>>>> Koelsch) during real cold boot (power off during the night), and even
>>>> then it's not guaranteed to trigger. Pressing the reset button
>>>> afterwards recovers the system, and a subsequent boot will succeed
>>>> (incl. secondary CPU core boot).
>>>>
>>>> This series configures the reset requests as documented in the R-Car
>>>> Gen2 datasheet, and removes the check for MD21 during secondary CPU
>>>> bringup. It was inspired by CPU-specific patches in the BSP by
>>>> Nakamura-san.
>>>>
>>>> This series has been boot-tested on r8a7791/koelsch (both debug mode and
>>>> normal mode), on r8a7790/lager and r8a7793/gose (normal mode only), and
>>>> on r8a7794/alt (normal mode UP only).
>>>
>>> Any comments?
>>> Any objection to applying this series?
>>>
>>> I've been running my Koelsch with MD21=1 since I posted this series,
>>> and it has been included in renesas-drivers since the beginning of September.
>>>
>>> My main motivation to push this is that it removes two more users of
>>> rcar_gen2_read_mode_pins(). After this, the only remaining user is the
>>> clock driver, invoked from rcar_gen2_timer_init().
>>
>> I have no objections, but I'm curious if the series received enough
>> testing (with debug mode enabled) on earlier R-Car Gen2 platforms like
>> r8a7790/lager?
>
> Let's see what Hiep has to say, who tests Lager with both debug mode
> enabled and disabled...
Good idea! We probably want to know about ES version too.
Cheers,
/ magnus
^ permalink raw reply
* [PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode
From: Geert Uytterhoeven @ 2016-09-30 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoRf23PQ+HEDEHtkHwoQb325T3ibLztzwAZ81FddoZ=r-Q@mail.gmail.com>
Hi Magnus,
On Fri, Sep 30, 2016 at 9:04 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Tue, Sep 27, 2016 at 9:37 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Mon, Aug 22, 2016 at 4:44 PM, Geert Uytterhoeven
>> <geert+renesas@glider.be> wrote:
>>> This patch series is an attempt to allow booting secondary CPU cores on
>>> R-Car Gen2 when hardware debug mode is enabled. In this mode, reset
>>> requests derived from power-shutoff to the AP-system CPU cores must be
>>> enabled before the AP-system cores first resume from power-shutoff. Else
>>> resume may fail, causing the system to hang during boot. Currently we
>>> avoid the hang by prohibiting booting secondary CPU cores when hardware
>>> debug mode is enabled.
>>>
>>> On all R-Car Gen2 SoCs, hardware debug mode is enabled by setting
>>> MD21=1. On both Koelsch and Lager, this is done by setting mode switch
>>> SW8-4 to OFF.
>>>
>>> Unfortunately the hang is not easy to reproduce: I only saw it (on
>>> Koelsch) during real cold boot (power off during the night), and even
>>> then it's not guaranteed to trigger. Pressing the reset button
>>> afterwards recovers the system, and a subsequent boot will succeed
>>> (incl. secondary CPU core boot).
>>>
>>> This series configures the reset requests as documented in the R-Car
>>> Gen2 datasheet, and removes the check for MD21 during secondary CPU
>>> bringup. It was inspired by CPU-specific patches in the BSP by
>>> Nakamura-san.
>>>
>>> This series has been boot-tested on r8a7791/koelsch (both debug mode and
>>> normal mode), on r8a7790/lager and r8a7793/gose (normal mode only), and
>>> on r8a7794/alt (normal mode UP only).
>>
>> Any comments?
>> Any objection to applying this series?
>>
>> I've been running my Koelsch with MD21=1 since I posted this series,
>> and it has been included in renesas-drivers since the beginning of September.
>>
>> My main motivation to push this is that it removes two more users of
>> rcar_gen2_read_mode_pins(). After this, the only remaining user is the
>> clock driver, invoked from rcar_gen2_timer_init().
>
> I have no objections, but I'm curious if the series received enough
> testing (with debug mode enabled) on earlier R-Car Gen2 platforms like
> r8a7790/lager?
Let's see what Hiep has to say, who tests Lager with both debug mode
enabled and disabled...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode
From: Magnus Damm @ 2016-09-30 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUfV46Y_L2yformTPcnGKpbfFawNOrutyeMk5L4rL5BfA@mail.gmail.com>
Hi Geert,
On Tue, Sep 27, 2016 at 9:37 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Simon, Magnus,
>
> On Mon, Aug 22, 2016 at 4:44 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>> This patch series is an attempt to allow booting secondary CPU cores on
>> R-Car Gen2 when hardware debug mode is enabled. In this mode, reset
>> requests derived from power-shutoff to the AP-system CPU cores must be
>> enabled before the AP-system cores first resume from power-shutoff. Else
>> resume may fail, causing the system to hang during boot. Currently we
>> avoid the hang by prohibiting booting secondary CPU cores when hardware
>> debug mode is enabled.
>>
>> On all R-Car Gen2 SoCs, hardware debug mode is enabled by setting
>> MD21=1. On both Koelsch and Lager, this is done by setting mode switch
>> SW8-4 to OFF.
>>
>> Unfortunately the hang is not easy to reproduce: I only saw it (on
>> Koelsch) during real cold boot (power off during the night), and even
>> then it's not guaranteed to trigger. Pressing the reset button
>> afterwards recovers the system, and a subsequent boot will succeed
>> (incl. secondary CPU core boot).
>>
>> This series configures the reset requests as documented in the R-Car
>> Gen2 datasheet, and removes the check for MD21 during secondary CPU
>> bringup. It was inspired by CPU-specific patches in the BSP by
>> Nakamura-san.
>>
>> This series has been boot-tested on r8a7791/koelsch (both debug mode and
>> normal mode), on r8a7790/lager and r8a7793/gose (normal mode only), and
>> on r8a7794/alt (normal mode UP only).
>
> Any comments?
> Any objection to applying this series?
>
> I've been running my Koelsch with MD21=1 since I posted this series,
> and it has been included in renesas-drivers since the beginning of September.
>
> My main motivation to push this is that it removes two more users of
> rcar_gen2_read_mode_pins(). After this, the only remaining user is the
> clock driver, invoked from rcar_gen2_timer_init().
I have no objections, but I'm curious if the series received enough
testing (with debug mode enabled) on earlier R-Car Gen2 platforms like
r8a7790/lager?
Cheers,
/ magnus
^ permalink raw reply
* [PATCH v2] arm64: make rpm failed due to incorrect path to Image.gz
From: Vadim Lomovtsev @ 2016-09-30 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475160367-2633-1-git-send-email-Vadim.Lomovtsev@caviumnetworks.com>
[Adding Will Deacon]
Sorry, should do this at the very beginning. (
On Thu, Sep 29, 2016 at 07:46:07AM -0700, Vadim Lomovtsev wrote:
> The "make rpm" and "make rpm-pkg" commands for arm64 platform
> are broken due to rpmbuild couldn't find Image.gz file at
> default location (which is kernel src root):
> cp: cannot stat 'Image.gz': No such file or directory
> error: Bad exit status from /var/tmp/rpm-tmp.ocFBmP (%install)
>
> While the correct path to arm64 kernel image file
> is "arch/arm64/boot/Image.gz".
>
> The exact file name (Image.gz) is stored at KBUILD_IMAGE variable
> and read by rpmbuild with "make image_name" command at
> install phase after kernel build is complete.
>
> Accordingly to Michal's Marek comment the KBUILD_IMAGE
> variable has to be set to point to actual file.
>
> Since the KBUILD_IMAGE variable is used in general cases of
> build we need to prevent other build types breakage by changing it.
>
> The solution is to add to arch/arm64/Makefie extra target "image_name"
> with dependency "KBUILD_IMAGE:=<proper path to Image.gz file>".
> Thus it will allow to set proper path to Image.gz file only for
> the "image_name" build target and this exact value will be picked up
> while rpm build install phase.
>
> Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> ---
> arch/arm64/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index ab51aed..09926d3 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -101,6 +101,8 @@ all: $(KBUILD_IMAGE) $(KBUILD_DTBS)
>
> boot := arch/arm64/boot
>
> +image_name: KBUILD_IMAGE :=$(boot)/$(KBUILD_IMAGE)
> +
> Image: vmlinux
> $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
>
> --
> 1.8.3.1
>
^ permalink raw reply
* [PATCH] pwm: imx: Port "pwm: imx: support output polarity inversion" to Linux v4.7
From: Lukasz Majewski @ 2016-09-30 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911110112.564df4ab@jawa>
Dear all,
> Dear Lothar, Stefan,
>
> > This patch ports "pwm: imx: support output polarity inversion" patch
> > set written by Lothar Wassmann (v6 from 10.2014).
> >
>
> I've read the e-mail from Stefan regarding missing support for pwm-imx
> polarity inversion feature.
>
> I also would like to see it in ML. Hence, my patch. Lothar, please
> feel free to squash it to your patches when you (I hope :-) ) will
> prepare v7 of this feature.
>
> I hope that this would help.
Was there any decision about those patches?
Would they be included to main line anytime soon?
Best regards,
?ukasz Majewski
>
> Best regards,
> ?ukasz Majewski
>
> > It is used to control backlight of panels via inverted PWM signal.
> >
> > The "inversion" of PWM output is not an issue at such devices, since
> > separate GPIO pin is responsible for enabling and disabling the
> > panel's backlight.
> >
> > This patch should be put on top of:
> >
> > https://patchwork.kernel.org/patch/5065841/
> > https://patchwork.kernel.org/patch/5065821/
> > https://patchwork.kernel.org/patch/5065811/
> >
> >
> > Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
> > ---
> > drivers/pwm/pwm-imx.c | 20 ++++++++++++++------
> > 1 file changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > index 471a99e..c37d223 100644
> > --- a/drivers/pwm/pwm-imx.c
> > +++ b/drivers/pwm/pwm-imx.c
> > @@ -181,7 +181,7 @@ static int imx_pwm_config_v2(struct pwm_chip
> > *chip, if (enable)
> > cr |= MX3_PWMCR_EN;
> >
> > - if (pwm->polarity == PWM_POLARITY_INVERSED)
> > + if (pwm->args.polarity == PWM_POLARITY_INVERSED)
> > cr |= MX3_PWMCR_POUTC;
> >
> > writel(cr, imx->mmio_base + MX3_PWMCR);
> > @@ -201,11 +201,6 @@ static void imx_pwm_set_enable_v2(struct
> > pwm_chip *chip, bool enable) else
> > val &= ~MX3_PWMCR_EN;
> >
> > - if (chip->pwms[0].polarity == PWM_POLARITY_INVERSED)
> > - val |= MX3_PWMCR_POUTC;
> > - else
> > - val &= ~MX3_PWMCR_POUTC;
> > -
> > writel(val, imx->mmio_base + MX3_PWMCR);
> > }
> >
> > @@ -253,6 +248,19 @@ static int imx_pwm_set_polarity(struct pwm_chip
> > *chip, struct pwm_device *pwm, enum pwm_polarity polarity)
> > {
> > struct imx_chip *imx = to_imx_chip(chip);
> > + u32 val;
> > +
> > + if (polarity == pwm->args.polarity)
> > + return 0;
> > +
> > + val = readl(imx->mmio_base + MX3_PWMCR);
> > +
> > + if (polarity == PWM_POLARITY_INVERSED)
> > + val |= MX3_PWMCR_POUTC;
> > + else
> > + val &= ~MX3_PWMCR_POUTC;
> > +
> > + writel(val, imx->mmio_base + MX3_PWMCR);
> >
> > dev_dbg(imx->chip.dev, "%s: polarity set to %s\n",
> > __func__, polarity == PWM_POLARITY_INVERSED ? "inverted" :
> > "normal");
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160930/22860f65/attachment.sig>
^ permalink raw reply
* [PATCH] drm/mediatek: stop using drm_vblank_count() as the hw frame counter
From: YT Shen @ 2016-09-30 6:45 UTC (permalink / raw)
To: linux-arm-kernel
using drm_vblank_no_hw_counter() to eliminate kernel warning.
Signed-off-by: YT Shen <yt.shen@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index eebb7d8..e286193 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -239,7 +239,7 @@ static struct drm_driver mtk_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
DRIVER_ATOMIC,
- .get_vblank_counter = drm_vblank_count,
+ .get_vblank_counter = drm_vblank_no_hw_counter,
.enable_vblank = mtk_drm_crtc_enable_vblank,
.disable_vblank = mtk_drm_crtc_disable_vblank,
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] mmc: sdhci-of-arasan: mark sdhci_arasan_reset() static
From: Sören Brinkmann @ 2016-09-30 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475199459-4775-2-git-send-email-baoyou.xie@linaro.org>
On Fri, 2016-09-30 at 09:37:39 +0800, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/mmc/host/sdhci-of-arasan.c:253:6: warning: no previous prototype for 'sdhci_arasan_reset' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
There is already a patch for this:
https://patchwork.kernel.org/patch/9349805/
S?ren
^ permalink raw reply
* ARM juno R2 board USB Issue (EHCI probe failed)
From: Sajjan, Vikas C @ 2016-09-30 4:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37a463cb-86d5-e0d7-7e8f-50cec3d65c95@arm.com>
Hi Sudeep,
-----Original Message-----
From: Sudeep Holla [mailto:sudeep.holla at arm.com]
Sent: Tuesday, September 27, 2016 2:38 PM
To: Sajjan, Vikas C <vikas.cha.sajjan@hpe.com>; Vikas Sajjan <sajjan.linux@gmail.com>; linux-usb at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org
Cc: Sudeep Holla <sudeep.holla@arm.com>; mark.rutland at arm.com; lorenzo.pieralisi at arm.com
Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)
On 27/09/16 09:55, Sajjan, Vikas C wrote:
> Hi Sudeep,
>
> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
> Sent: Tuesday, September 27, 2016 2:21 PM
> To: Vikas Sajjan <sajjan.linux@gmail.com>; linux-usb at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org
> Cc: Sudeep Holla <sudeep.holla@arm.com>; mark.rutland at arm.com;
> lorenzo.pieralisi at arm.com; Sajjan, Vikas C <vikas.cha.sajjan@hpe.com>
> Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)
>
> Hi Vikas,
>
> On 27/09/16 09:14, Vikas Sajjan wrote:
>> Adding USB mailing list.
>>
>>
>> On Tue, Sep 27, 2016 at 12:33 PM, Sajjan, Vikas C
>> <vikas.cha.sajjan@hpe.com> wrote:
>>> Hi All,
>>>
>>> I working on ARM juno R2 board, with latest kernel 4.8.rc7 and I get
>>> below USB EHCI probe error while booting with acpi=force.
>>>
>
> Are you using the latest UEFI EDK2 ?
> No, I am still using the UEFI binary which came as part of the Juno board.
>
>
>>> [ 1.223662] VFIO - User Level meta-driver version: 0.3
>>> [ 1.229335] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>>> [ 1.235882] ehci-pci: EHCI PCI platform driver
>>> [ 1.240359] ehci-platform: EHCI generic platform driver
>>> [ 1.245619] ehci-platform ARMH0D20:00: Error: DMA mask configuration failed
>>> [ 1.272491] ehci-platform: probe of ARMH0D20:00 failed with error -5
>>> [ 1.278876] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>>> [ 1.285071] ohci-pci: OHCI PCI platform driver
>>> [ 1.289548] ohci-platform: OHCI generic platform driver
>>> [ 1.294884] usbcore: registered new interface driver usb-storage
>>> [ 1.301231] mousedev: PS/2 mouse device common for all mice
>>> [ 1.307197] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
>>>
>>> But this error goes off, if I don't force ACPI booting, i.e., if I
>>> remove acpi=force from kernel command line , USB is detected and my
>>> RFS which is in the usb drive, gets mounted successfully.
>>>
>
> As I mentioned in private, I do get the same error if I drop _CCA in
> USB object of ACPI DSDT. Can you give it a spin with latest UEFI ?
>
> Sure, will try with latest UEFI.
>
I bet that's 8-12 months old. It puts the banner during boot with the build date. You can try to follow [1] or access it from [2]
I was able boot the kernel without any EHCI failure and could get to the shell prompt using the EDK2 in [2].
Thanks for help.
Thanks and Regards
Vikas Sajjan
--
Regards,
Sudeep
[1] https://community.arm.com/docs/DOC-11395
[2]
http://snapshots.linaro.org/member-builds/armlt-platforms-release/32/juno-uefi.zip
^ permalink raw reply
* [PATCH 0/4] Add DMA support for ti_am335x_adc driver
From: John Syne @ 2016-09-30 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff19f584-e4e5-61ff-046d-68ec37ab51c2@ti.com>
I applied your patches to the following kernel:
github.com/RobertCNelson/bb-kernel.git
branch am33x-v4.8
Changing
#define REG_DMAENABLE_CLEAR 0x038
to
#define REG_DMAENABLE_CLEAR 0x03C
Also applying the following DTS changes:
target = <&tscadc>;
__overlay__ {
status = "okay";
adc {
ti,adc-channels = <0 1 2 3 4 5 6>;
ti,chan-step-avg = <0x1 0x1 0x1 0x1 0x1 0x1 0x1>;
ti,chan-step-opendelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
};
};
Running on a BeagleBoneBlack, I was able to stream samples at 200ksps continuously and it looked stable.
htop showed CPU utilization between 5% and 7%
Thank you for getting this to work.
Regards,
John
> On Sep 29, 2016, at 6:01 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>
> On Sunday 25 September 2016 03:11 PM, Jonathan Cameron wrote:
>> On 21/09/16 17:11, Mugunthan V N wrote:
>>>> The ADC has a 64 work depth fifo length which holds the ADC data
>>>> till the CPU reads. So when a user program needs a large ADC data
>>>> to operate on, then it has to do multiple reads to get its
>>>> buffer. Currently if the application asks for 4 samples per
>>>> channel with all 8 channels are enabled, kernel can provide only
>>>> 3 samples per channel when all 8 channels are enabled (logs at
>>>> [1]). So with DMA support user can request for large number of
>>>> samples at a time (logs at [2]).
>>>>
>>>> Tested the patch on AM437x-gp-evm and AM335x Boneblack with the
>>>> patch [3] to enable ADC and pushed a branch for testing [4]
>>>>
>>>> [1] - http://pastebin.ubuntu.com/23211490/
>>>> [2] - http://pastebin.ubuntu.com/23211492/
>>>> [3] - http://pastebin.ubuntu.com/23211494/
>>>> [4] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git iio-dma
>> Just curious. How fast is the ADC sampling at in these? Never that
>> obvious for this driver!
>>
>> I'm also curious as to whether you started to hit the limits of the
>> kfifo based interface. Might be worth considering adding alternative
>> support for the dma buffers interface which is obviously much lower
>> overhead.
>>
>> Good to have this work prior to that as the kfifo stuff is somewhat
>> easier to use.
>
> Currently ADC clock is 3MHz, which can produce a data rate of 225KBps
> per channel with no open delay and no averaging of samples. So when all
> 8 Channels are enables the data rate will be 1.75MBps
>
> ADC can be operated at 24MHz, which can generate a data rate of 28MBps
> with all 8 channels enabled and no open delay and averaging, but our
> target is to get 800K samples per second per channel which has a data
> rate of 12.5MBps
>
> I think with this data rate, DMA will be the best option to implement
> without any data loss and less cpu overload to read the ADC samples.
>
> Regards
> Mugunthan V N
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] drm/mediatek: fix a typo
From: Bibby Hsieh @ 2016-09-30 3:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f324471-bebb-c8bf-75c1-391355c50a99@gmail.com>
On Thu, 2016-09-29 at 10:46 +0200, Matthias Brugger wrote:
>
> On 29/09/16 06:01, CK Hu wrote:
> > Acked-by: CK Hu <ck.hu@mediatek.com>
> >
> > On Thu, 2016-09-29 at 11:22 +0800, Bibby Hsieh wrote:
> >> Fix the typo: OD_RELAYMODE->OD_CFG
> >>
>
Hi, Matthias
Thanks for your reply.
> Although it is quite clear what the patch does, could you write one
> sentence to explain what it does. Maybe explain even which effect it
> has, which error get fixed etc.
Ok, I will do that.
> As we are getting public available boards now, we should take more care
> about fixes. If you have a fix for a commit introduced in an earlier
> version of linux and it should be fixed for this version as well (e.g.
> v4.6 does have the feature but it does not work correctly) then please
> add these two lines before your Signed-off-by:
> Fixes: <commit-hash> ("<commit subject line>")
> Cc: stable at vger.kernel.org # v4.6+
>
> Where v4.6+ stands for the oldest version where this should get fixed.
>
Ok, but the patch hasn't been merged into v4.8 (just in drm-next [1] and
linux-next [2]), how can I mark that?
[1]
https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=7216436420414144646f5d8343d061355fd23483
[2]
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=7216436420414144646f5d8343d061355fd23483
> Thanks a lot,
> Matthias
>
> >> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> >> ---
> >> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> >> index df33b3c..aa5f20f 100644
> >> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> >> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> >> @@ -123,7 +123,7 @@ static void mtk_od_config(struct mtk_ddp_comp *comp, unsigned int w,
> >> unsigned int bpc)
> >> {
> >> writel(w << 16 | h, comp->regs + DISP_OD_SIZE);
> >> - writel(OD_RELAYMODE, comp->regs + OD_RELAYMODE);
> >> + writel(OD_RELAYMODE, comp->regs + OD_CFG);
> >> mtk_dither_set(comp, bpc, DISP_OD_CFG);
> >> }
> >>
> >
> >
--
Bibby
^ permalink raw reply
* [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
From: CK Hu @ 2016-09-30 3:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473039885-24009-3-git-send-email-hs.liao@mediatek.com>
Hi, HS:
On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> CMDQ is used to help write registers with critical time limitation,
> such as updating display configuration during the vblank. It controls
> Global Command Engine (GCE) hardware to achieve this requirement.
> Currently, CMDQ only supports display related hardwares, but we expect
> it can be extended to other hardwares for future requirements.
>
> Signed-off-by: HS Liao <hs.liao@mediatek.com>
> Signed-off-by: CK Hu <ck.hu@mediatek.com>
> ---
[snip...]
> +
> +struct cmdq_task {
> + struct cmdq *cmdq;
> + struct list_head list_entry;
> + void *va_base;
> + dma_addr_t pa_base;
> + size_t cmd_buf_size; /* command occupied size */
> + size_t buf_size; /* real buffer size */
> + bool finalized;
> + struct cmdq_thread *thread;
I think thread info could be removed from cmdq_task. Only
cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
task->thread and caller of both function has the thread info. So you
could just pass thread info into these two function and remove thread
info in cmdq_task.
> + struct cmdq_task_cb cb;
I think this callback function is equal to mailbox client tx_done
callback. It's better to use already-defined interface rather than
creating your own.
> +};
> +
[snip...]
> +
> +static int cmdq_suspend(struct device *dev)
> +{
> + struct cmdq *cmdq = dev_get_drvdata(dev);
> + struct cmdq_thread *thread;
> + int i;
> + bool task_running = false;
> +
> + mutex_lock(&cmdq->task_mutex);
> + cmdq->suspended = true;
> + mutex_unlock(&cmdq->task_mutex);
> +
> + for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
> + thread = &cmdq->thread[i];
> + if (!list_empty(&thread->task_busy_list)) {
> + mod_timer(&thread->timeout, jiffies + 1);
> + task_running = true;
> + }
> + }
> +
> + if (task_running) {
> + dev_warn(dev, "exist running task(s) in suspend\n");
> + msleep(20);
Why sleep here? It looks like a recovery but could 20ms recovery
something? I think warning message is enough because you see the warning
message, and you fix the bug, so no need to recovery anything.
> + }
> +
> + clk_unprepare(cmdq->clock);
> + return 0;
> +}
> +
Regards,
CK
^ permalink raw reply
* [PATCH 3/3] arm64: dump: Add checking for writable and exectuable pages
From: Mark Rutland @ 2016-09-30 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929213257.30505-4-labbott@redhat.com>
Hi,
On Thu, Sep 29, 2016 at 02:32:57PM -0700, Laura Abbott wrote:
> Page mappings with full RWX permissions are a security risk. x86
> has an option to walk the page tables and dump any bad pages.
> (See e1a58320a38d ("x86/mm: Warn on W^X mappings")). Add a similar
> implementation for arm64.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> @@ -31,6 +32,8 @@ struct ptdump_info {
> const struct addr_marker *markers;
> unsigned long base_addr;
> unsigned long max_addr;
(unrelated aside: it looks like max_addr is never used or even assigned to;
care to delete it in a prep patch?)
> + /* Internal, do not touch */
> + struct list_head node;
> };
> +static LIST_HEAD(dump_info);
With the EFI runtime map tables it's unfortunately valid (and very likely with
64K pages) that there will be RWX mappings, at least with contemporary versions
of the UEFI spec. Luckily, those are only installed rarely and transiently.
Given that (and other potential ptdump users), I don't think we should have a
dynamic list of ptdump_infos for W^X checks, and should instead have
ptdump_check_wx() explicitly check the tables we care about. More comments
below on that.
I think we only care about the swapper and hyp tables, as nothing else is
permanent. Does that sound sane?
> struct prot_bits {
> @@ -219,6 +223,15 @@ static void note_page(struct pg_state *st, unsigned long addr, unsigned level,
> unsigned long delta;
>
> if (st->current_prot) {
> + if (st->check_wx &&
> + ((st->current_prot & PTE_RDONLY) != PTE_RDONLY) &&
> + ((st->current_prot & PTE_PXN) != PTE_PXN)) {
> + WARN_ONCE(1, "arm64/mm: Found insecure W+X mapping at address %p/%pS\n",
> + (void *)st->start_address,
> + (void *)st->start_address);
> + st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
> + }
> +
Currently note_page() is painful to read due to the indentation and logic.
Rather than adding to that, could we factor this into a helper? e.g.
note_prot_wx(struct pg_state *st, unsigned long addr)
{
if (!st->check_wx)
return;
if ((st->current_prot & PTE_RDONLY) == PTE_RDONLY)
return;
if ((st->current_prot & PTE_PXN) == PTE_PXN)
return;
WARN_ONCE(1, "arm64/mm: Found insecure W+X mapping at address %p/%pS\n",
(void *)st->start_address, (void *)st->start_address);
st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
}
> +void ptdump_check_wx(void)
> +{
> + struct ptdump_info *info;
> +
> + list_for_each_entry(info, &dump_info, node) {
> + struct pg_state st = {
> + .seq = NULL,
> + .marker = info->markers,
> + .check_wx = true,
> + };
> +
> + __walk_pgd(&st, info->mm, info->base_addr);
> + note_page(&st, 0, 0, 0);
> + if (st.wx_pages)
> + pr_info("Checked W+X mappings (%p): FAILED, %lu W+X pages found\n",
> + info->mm,
> + st.wx_pages);
> + else
> + pr_info("Checked W+X mappings (%p): passed, no W+X pages found\n", info->mm);
> + }
> +}
As above, I don't think we should use a list of arbitrary ptdump_infos.
Given we won't log addresses in the walking code, I think that we can make up a
trivial marker array, and then just use init_mm direct, e.g. (never even
compile-tested):
void ptdump_check_wx(void)
{
struct pg_state st = {
.seq = NULL,
.marker = (struct addr_markers[]) {
{ -1, NULL},
},
.check_wx = true,
};
__walk_pgd(&st, init_mm, 0);
note_page(&st, 0, 0, 0);
if (st.wx_pages)
pr_info("Checked W+X mappings (%p): FAILED, %lu W+X pages found\n",
info->mm,
st.wx_pages);
else
pr_info("Checked W+X mappings (%p): passed, no W+X pages found\n", info->mm);
}
Otherwise, this looks good to me. Thanks for putting this together!
Mark.
^ permalink raw reply
* [PATCH v2 2/2] drm: zte: add initial vou drm driver
From: Shawn Guo @ 2016-09-30 1:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbKh9x5hxWLO2JswYH8Qw1xdB1Xc5c9nVDZ0WxsQRxhX0Q@mail.gmail.com>
Hi Sean,
On Tue, Sep 27, 2016 at 11:48:37AM -0400, Sean Paul wrote:
> On Sat, Sep 24, 2016 at 10:26 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > It adds the initial ZTE VOU display controller DRM driver. There are
> > still some features to be added, like overlay plane, scaling, and more
> > output devices support. But it's already useful with dual CRTCs and
> > HDMI monitor working.
> >
> > It's been tested on Debian Jessie LXDE desktop with modesetting driver.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>
> Hi Shawn,
> I think overall this is very well done! A couple of things stuck out
> to me, I've pointed them out below, hopefully you can use some of
> them.
Thanks for reviewing the patch. The comments are helpful, and I will
try to address them immediately once I get back from the business
travel.
> > diff --git a/drivers/gpu/drm/zte/Makefile b/drivers/gpu/drm/zte/Makefile
> > new file mode 100644
> > index 000000000000..b40968dc749f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/zte/Makefile
> > @@ -0,0 +1,8 @@
> > +zxdrm-y := \
> > + zx_drm_drv.o \
> > + zx_crtc.o \
> > + zx_plane.o \
> > + zx_hdmi.o
> > +
> > +obj-$(CONFIG_DRM_ZTE) += zxdrm.o
> > +
> > diff --git a/drivers/gpu/drm/zte/zx_crtc.c b/drivers/gpu/drm/zte/zx_crtc.c
>
> I was a little tripped up when I first read this file since I assumed
> there was one instance of this driver per-crtc. However, there's
> really N crtcs per driver. Might it be less confusing to call it
> zx_vou.c instead?
Okay, will rename it.
> > +static void zx_crtc_enable(struct drm_crtc *crtc)
> > +{
> > + struct drm_display_mode *mode = &crtc->state->adjusted_mode;
> > + struct zx_crtc *zcrtc = to_zx_crtc(crtc);
> > + struct zx_vou_hw *vou = dev_get_drvdata(zcrtc->dev);
>
> IMO, it would be better to store a pointer to vou in each zx_crtc
> rather than reaching into drvdata.
Yeah, agree on that.
> > + bool is_main = is_main_crtc(crtc);
> > + struct videomode vm;
> > + u32 pol = 0;
> > + u32 val;
> > +
> > + drm_display_mode_to_videomode(mode, &vm);
>
> Why do this conversion? You should be able to get everything you need
> from drm_display_mode
It's a helper function, and the calculation of front_porch, back_porch
and sync_len helps me.
> > +
> > + /* Set up timing parameters */
> > + val = (vm.vactive - 1) << 16;
> > + val |= (vm.hactive - 1) & 0xffff;
> > + writel(val, vou->timing + (is_main ? FIR_MAIN_ACTIVE : FIR_AUX_ACTIVE));
> > +
> > + val = ((vm.hsync_len - 1) << SYNC_WIDE_SHIFT) & SYNC_WIDE_MASK;
> > + val |= ((vm.hback_porch - 1) << BACK_PORCH_SHIFT) & BACK_PORCH_MASK;
> > + val |= ((vm.hfront_porch - 1) << FRONT_PORCH_SHIFT) & FRONT_PORCH_MASK;
> > + writel(val, vou->timing + (is_main ? FIR_MAIN_H_TIMING :
> > + FIR_AUX_H_TIMING));
> > +
> > + val = ((vm.vsync_len - 1) << SYNC_WIDE_SHIFT) & SYNC_WIDE_MASK;
> > + val |= ((vm.vback_porch - 1) << BACK_PORCH_SHIFT) & BACK_PORCH_MASK;
> > + val |= ((vm.vfront_porch - 1) << FRONT_PORCH_SHIFT) & FRONT_PORCH_MASK;
> > + writel(val, vou->timing + (is_main ? FIR_MAIN_V_TIMING :
> > + FIR_AUX_V_TIMING));
>
> It would be nice to figure out a better way of handing the main/aux
> switch as opposed to sprinkling all of these inline conditionals
> around. Perhaps you could introduce a struct which stores the
> addresses per-crtc and then reference the struct in the driver as
> opposed to the #defines.
>
> ie:
>
> writel(val, vou->timing + zcrtc->regs->v_timing);
Yeah, good suggestion.
> > +static void zx_crtc_atomic_begin(struct drm_crtc *crtc,
> > + struct drm_crtc_state *state)
> > +{
> > + struct drm_pending_vblank_event *event = crtc->state->event;
> > +
> > + if (event) {
>
> nit: you can save yourself a level of indentation by exiting early on
> !event instead of scoping the entire function on event.
Aha, right!
>
> > + crtc->state->event = NULL;
> > +
> > + spin_lock_irq(&crtc->dev->event_lock);
> > + if (drm_crtc_vblank_get(crtc) == 0)
> > + drm_crtc_arm_vblank_event(crtc, event);
> > + else
> > + drm_crtc_send_vblank_event(crtc, event);
> > + spin_unlock_irq(&crtc->dev->event_lock);
> > + }
> > +}
<snip>
> > +static struct zx_crtc *zx_crtc_init(struct drm_device *drm,
> > + enum vou_chn_type chn_type)
> > +{
> > + struct zx_drm_private *priv = drm->dev_private;
> > + struct zx_vou_hw *vou = priv->vou;
> > + struct device *dev = vou->dev;
> > + struct zx_layer_data data;
> > + struct zx_crtc *zcrtc;
> > + int ret;
> > +
> > + zcrtc = devm_kzalloc(dev, sizeof(*zcrtc), GFP_KERNEL);
> > + if (!zcrtc)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + zcrtc->dev = dev;
> > + zcrtc->chn_type = chn_type;
> > +
> > + if (chn_type == VOU_CHN_MAIN) {
> > + data.layer = vou->osd + 0x130;
> > + data.csc = vou->osd + 0x580;
> > + data.hbsc = vou->osd + 0x820;
> > + data.rsz = vou->otfppu + 0x600;
> > + zcrtc->chnreg = vou->osd + OSD_MAIN_CHN;
> > + } else {
> > + data.layer = vou->osd + 0x200;
> > + data.csc = vou->osd + 0x5d0;
> > + data.hbsc = vou->osd + 0x860;
> > + data.rsz = vou->otfppu + 0x800;
> > + zcrtc->chnreg = vou->osd + OSD_AUX_CHN;
> > + }
>
> These magic values should find their way into #defines
Yeah, will do.
> > +static void vou_dtrc_init(struct zx_vou_hw *vou)
> > +{
> > + u32 val;
> > +
> > + val = readl(vou->dtrc + DTRC_DETILE_CTRL);
> > + /* Clear bit for bypass by ID */
> > + val &= ~TILE2RASTESCAN_BYPASS_MODE;
> > + /* Select ARIDR mode */
> > + val &= ~DETILE_ARIDR_MODE_MASK;
> > + val |= DETILE_ARID_IN_ARIDR;
> > + writel(val, vou->dtrc + DTRC_DETILE_CTRL);
> > +
> > + /* Bypass decompression for both frames */
> > + val = readl(vou->dtrc + DTRC_F0_CTRL);
> > + val |= DTRC_DECOMPRESS_BYPASS;
> > + writel(val, vou->dtrc + DTRC_F0_CTRL);
> > +
> > + val = readl(vou->dtrc + DTRC_F1_CTRL);
> > + val |= DTRC_DECOMPRESS_BYPASS;
> > + writel(val, vou->dtrc + DTRC_F1_CTRL);
> > +
> > + /* Set up ARID register */
> > + val = 0x0e;
> > + val |= 0x0f << 8;
> > + val |= 0x0e << 16;
> > + val |= 0x0f << 24;
>
> #define
Okay.
> > +static int zx_crtc_bind(struct device *dev, struct device *master, void *data)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct drm_device *drm = data;
> > + struct zx_drm_private *priv = drm->dev_private;
> > + struct resource *res;
> > + struct zx_vou_hw *vou;
> > + int irq;
> > + int ret;
> > +
> > + vou = devm_kzalloc(dev, sizeof(*vou), GFP_KERNEL);
> > + if (!vou)
> > + return -ENOMEM;
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "osd");
> > + vou->osd = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(vou->osd))
> > + return PTR_ERR(vou->osd);
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "timing_ctrl");
> > + vou->timing = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(vou->timing))
> > + return PTR_ERR(vou->timing);
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dtrc");
> > + vou->dtrc = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(vou->dtrc))
> > + return PTR_ERR(vou->dtrc);
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "vou_ctrl");
> > + vou->vouctl = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(vou->vouctl))
> > + return PTR_ERR(vou->vouctl);
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otfppu");
> > + vou->otfppu = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(vou->otfppu))
> > + return PTR_ERR(vou->otfppu);
> > +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0)
> > + return irq;
> > +
> > + vou->axi_clk = devm_clk_get(dev, "aclk");
> > + if (IS_ERR(vou->axi_clk))
> > + return PTR_ERR(vou->axi_clk);
> > +
> > + vou->ppu_clk = devm_clk_get(dev, "ppu_wclk");
> > + if (IS_ERR(vou->ppu_clk))
> > + return PTR_ERR(vou->ppu_clk);
> > +
> > + clk_prepare_enable(vou->axi_clk);
> > + clk_prepare_enable(vou->ppu_clk);
> > +
> > + vou->dev = dev;
> > + priv->vou = vou;
> > + dev_set_drvdata(dev, vou);
>
> I think you should be able to avoid storing vou in priv and drvdata.
I see I can do something by avoid storing vou in priv, but not sure how
to access vou in unbind function without storing it in drvdata. Any
suggestion?
> > +
> > + vou_hw_init(vou);
> > +
> > + ret = devm_request_irq(dev, irq, vou_irq_handler, 0, "zx_vou", vou);
> > + if (ret < 0)
> > + return ret;
> > +
> > + vou->main_crtc = zx_crtc_init(drm, VOU_CHN_MAIN);
> > + if (IS_ERR(vou->main_crtc))
> > + return PTR_ERR(vou->main_crtc);
> > +
> > + vou->aux_crtc = zx_crtc_init(drm, VOU_CHN_AUX);
> > + if (IS_ERR(vou->aux_crtc))
> > + return PTR_ERR(vou->aux_crtc);
> > +
> > + return 0;
> > +}
<snip>
> > diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
> > new file mode 100644
> > index 000000000000..51fafb8e5f43
> > --- /dev/null
> > +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> > @@ -0,0 +1,258 @@
> > +/*
> > + * Copyright 2016 Linaro Ltd.
> > + * Copyright 2016 ZTE Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/spinlock.h>
> > +#include <linux/clk.h>
> > +#include <linux/component.h>
> > +#include <linux/list.h>
> > +#include <linux/of_graph.h>
> > +#include <linux/of_platform.h>
>
> nit: Alphabetical?
Okay, will do.
> > +static struct vou_inf vou_inf_hdmi = {
> > + .id = VOU_HDMI,
> > + .data_sel = VOU_YUV444,
> > + .clocks_en_bits = BIT(24) | BIT(18) | BIT(6),
> > + .clocks_sel_bits = BIT(13) | BIT(2),
> > +};
>
> This should be static const, but I suppose you can't b/c you're
> storing a pointer to encoder in vou_inf. This type of information
> lends itself well to being defined and mapped as of_device_id.data,
> you'll need to pass the encoder around in a different manner.
Okay, I will find some way to remove the encoder pointer out of the
structure.
> > +static int zx_hdmi_config_video_vsi(struct zx_hdmi *hdmi,
> > + struct drm_display_mode *mode)
> > +{
> > + union hdmi_infoframe frame;
> > + int ret;
> > +
> > + ret = drm_hdmi_vendor_infoframe_from_display_mode(&frame.vendor.hdmi,
> > + mode);
> > + if (ret)
>
> Should you log in cases of failure (here and elsewhere)?
Okay, will do.
> > + return ret;
> > +
> > + return zx_hdmi_infoframe_trans(hdmi, &frame, FSEL_VSIF);
> > +}
<snip>
> > +static void zx_hdmi_encoder_enable(struct drm_encoder *encoder)
> > +{
> > + struct zx_hdmi *hdmi = to_zx_hdmi(encoder);
> > +
> > + vou_inf_enable(hdmi->inf);
>
> I think you can remove the encoder from inf by passing encoder->crtc
> here as well. That will tell vou which encoder/crtc pair to enable
> without having that pesky static global floating around.
Yes.
> > +}
> > +
> > +static void zx_hdmi_encoder_disable(struct drm_encoder *encoder)
> > +{
> > + struct zx_hdmi *hdmi = to_zx_hdmi(encoder);
> > +
> > + vou_inf_disable(hdmi->inf);
>
> Same here
Yes.
> > +}
> > +
> > +static const struct drm_encoder_helper_funcs zx_hdmi_encoder_helper_funcs = {
> > + .enable = zx_hdmi_encoder_enable,
> > + .disable = zx_hdmi_encoder_disable,
> > + .mode_set = zx_hdmi_encoder_mode_set,
> > +};
> > +
> > +static const struct drm_encoder_funcs zx_hdmi_encoder_funcs = {
> > + .destroy = drm_encoder_cleanup,
> > +};
> > +
> > +static int zx_hdmi_get_edid_block(void *data, u8 *buf, unsigned int block,
> > + size_t len)
>
> Instead of open-coding this, consider implementing an i2c adapter for
> the DDC bus and use drm_get_edid below.
Okay. I got the same suggestion from Daniel, so it must be something
good :)
Shawn
^ permalink raw reply
* [PATCH 2/2] mmc: sdhci-of-arasan: mark sdhci_arasan_reset() static
From: Baoyou Xie @ 2016-09-30 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475199459-4775-1-git-send-email-baoyou.xie@linaro.org>
We get 1 warning when building kernel with W=1:
drivers/mmc/host/sdhci-of-arasan.c:253:6: warning: no previous prototype for 'sdhci_arasan_reset' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/mmc/host/sdhci-of-arasan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index da8e40a..e263671 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -250,7 +250,7 @@ static void sdhci_arasan_hs400_enhanced_strobe(struct mmc_host *mmc,
writel(vendor, host->ioaddr + SDHCI_ARASAN_VENDOR_REGISTER);
}
-void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
+static void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
{
u8 ctrl;
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] mmc: block: add missing header dependencies
From: Baoyou Xie @ 2016-09-30 1:37 UTC (permalink / raw)
To: linux-arm-kernel
We get 1 warning when building kernel with W=1:
drivers/mmc/card/block.c:2147:5: warning: no previous prototype for 'mmc_blk_issue_rq' [-Wmissing-prototypes]
In fact, this function is declared in drivers/mmc/card/block.h,
so this patch adds missing header dependencies.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/mmc/card/block.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c333511..0f2cc9f2 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -46,6 +46,7 @@
#include <asm/uaccess.h>
#include "queue.h"
+#include "block.h"
MODULE_ALIAS("mmc:block");
#ifdef MODULE_PARAM_PREFIX
--
2.7.4
^ permalink raw reply related
* [kernel-hardening] [PATCH 0/3] WX Checking for arm64
From: Kees Cook @ 2016-09-30 1:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929213257.30505-1-labbott@redhat.com>
On Thu, Sep 29, 2016 at 2:32 PM, Laura Abbott <labbott@redhat.com> wrote:
>
> Hi,
>
> This is an implementation to check for writable and executable pages on arm64.
> This is heavily based on the x86 version which uses the existing page table
> dumping code to do the checking. Some notes:
>
> - The W^X checking is important so this option should become defaut eventually.
> To make this feasible, the debugfs functionality has been split out as a
> separate option. I didn't see a good way to make it modular like x86 but
> an option should be good enough.
> - This checks all page tables registered with ptdump_register. I don't see this
> being called elsewhere right now though.
> - Once this is merged, I'd like to see about moving DEBUG_WX to the top level
> instead of having each arch call it in mark_rodata.
Awesome!
Yeah, I think we should take a look at refactoring x86, arm, and arm64
to use a common infrastructure with callbacks. That way other
architectures can gain all these features with just a few callbacks
implemented.
-Kees
>
> Laura Abbott (3):
> arm64: dump: Make ptdump debugfs a separate option
> arm64: dump: Make the page table dumping seq_file optional
> arm64: dump: Add checking for writable and exectuable pages
>
> arch/arm64/Kconfig.debug | 34 ++++++++++++++-
> arch/arm64/include/asm/ptdump.h | 25 ++++++++++-
> arch/arm64/mm/Makefile | 3 +-
> arch/arm64/mm/dump.c | 92 ++++++++++++++++++++++++++++-------------
> arch/arm64/mm/mmu.c | 2 +
> arch/arm64/mm/ptdump_debugfs.c | 33 +++++++++++++++
> 6 files changed, 157 insertions(+), 32 deletions(-)
> create mode 100644 arch/arm64/mm/ptdump_debugfs.c
>
> --
> 2.10.0
>
--
Kees Cook
Nexus Security
^ permalink raw reply
* [PATCH 1/3] arm64: dump: Make ptdump debugfs a separate option
From: Mark Rutland @ 2016-09-30 1:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cf3b51d5-f5ad-9fc3-7bea-7e7a5a9798c5@redhat.com>
On Thu, Sep 29, 2016 at 06:11:44PM -0700, Laura Abbott wrote:
> On 09/29/2016 05:48 PM, Mark Rutland wrote:
> >On Thu, Sep 29, 2016 at 05:31:09PM -0700, Laura Abbott wrote:
> >>On 09/29/2016 05:13 PM, Mark Rutland wrote:
> >>>On Thu, Sep 29, 2016 at 02:32:55PM -0700, Laura Abbott wrote:
> >>>>+int ptdump_register(struct ptdump_info *info, const char *name)
> >>>>+{
> >>>>+ ptdump_initialize(info);
> >>>>+ return ptdump_debugfs_create(info, name);
> >>>>}
> >I meant moving ptdump_register into ptdump_debugfs.c, perhaps renamed to make it
> >clear it's debugfs-specific.
> >
> >We could instead update existing users to call ptdump_debugfs_create()
> >directly, and have that call ptdump_initialize(), which could itself become a
> >staic inline in a header.
>
> Ah okay, I see what you are suggesting. ptdump_initialize should still
> happen regardless of debugfs status though so I guess ptdump_debugfs_create
> would just get turned into just ptdump_initialize
> which seems a little unclear. I'll come up with some other shed
> colors^W^Wfunction names.
Cheers!
FWIW, given ptsump_initialize() is only going to be called with the ptdump core
and debugfs code, I'm not all that concerned by what it's called. A few leading
underscores is about the only thing that comes to mind, but even as-is I think
it should be fine.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/3] arm64: dump: Make ptdump debugfs a separate option
From: Laura Abbott @ 2016-09-30 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930004852.GC4369@remoulade>
On 09/29/2016 05:48 PM, Mark Rutland wrote:
> On Thu, Sep 29, 2016 at 05:31:09PM -0700, Laura Abbott wrote:
>> On 09/29/2016 05:13 PM, Mark Rutland wrote:
>>> On Thu, Sep 29, 2016 at 02:32:55PM -0700, Laura Abbott wrote:
>>>> +int ptdump_register(struct ptdump_info *info, const char *name)
>>>> +{
>>>> + ptdump_initialize(info);
>>>> + return ptdump_debugfs_create(info, name);
>>>> }
>>>
>>> It feels like a layering violation to have the core ptdump code call the
>>> debugfs ptdump code. Is there some reason this has to live here?
>>
>> Which 'this' are you referring to here? Are you suggesting moving
>> the ptdump_register elsewhere or moving the debugfs create elsewhere?
>
> Sorry, I should have worded that better.
>
> I meant moving ptdump_register into ptdump_debugfs.c, perhaps renamed to make it
> clear it's debugfs-specific.
>
> We could instead update existing users to call ptdump_debugfs_create()
> directly, and have that call ptdump_initialize(), which could itself become a
> staic inline in a header.
Ah okay, I see what you are suggesting. ptdump_initialize should still
happen regardless of debugfs status though so I guess
ptdump_debugfs_create would just get turned into just ptdump_initialize
which seems a little unclear. I'll come up with some other shed
colors^W^Wfunction names.
Thanks,
Laura
^ permalink raw reply
* [PATCH 1/3] arm64: dump: Make ptdump debugfs a separate option
From: Mark Rutland @ 2016-09-30 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e17189c7-54e0-f0a1-2b16-36f486111c4c@redhat.com>
On Thu, Sep 29, 2016 at 05:31:09PM -0700, Laura Abbott wrote:
> On 09/29/2016 05:13 PM, Mark Rutland wrote:
> >On Thu, Sep 29, 2016 at 02:32:55PM -0700, Laura Abbott wrote:
> >>+int ptdump_register(struct ptdump_info *info, const char *name)
> >>+{
> >>+ ptdump_initialize(info);
> >>+ return ptdump_debugfs_create(info, name);
> >> }
> >
> >It feels like a layering violation to have the core ptdump code call the
> >debugfs ptdump code. Is there some reason this has to live here?
>
> Which 'this' are you referring to here? Are you suggesting moving
> the ptdump_register elsewhere or moving the debugfs create elsewhere?
Sorry, I should have worded that better.
I meant moving ptdump_register into ptdump_debugfs.c, perhaps renamed to make it
clear it's debugfs-specific.
We could instead update existing users to call ptdump_debugfs_create()
directly, and have that call ptdump_initialize(), which could itself become a
staic inline in a header.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v14 0/9] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Xiongfeng Wang @ 2016-09-30 0:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475086637-1914-1-git-send-email-fu.wei@linaro.org>
for sbsa watchdog part, Tested-by: wangxiongfeng2 at huawei.com on D05 board.
On 2016/9/29 2:17, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> This patchset:
> (1)Preparation for adding GTDT support in arm_arch_timer:
> 1. Move some enums and marcos to header file;
> 2. Add a new enum for spi type;
> 3. Improve printk relevant code.
>
> (2)Introduce ACPI GTDT parser: drivers/acpi/arm64/acpi_gtdt.c
> Parse all kinds of timer in GTDT table of ACPI:arch timer,
> memory-mapped timer and SBSA Generic Watchdog timer.
> This driver can help to simplify all the relevant timer drivers,
> and separate all the ACPI GTDT knowledge from them.
>
> (3)Simplify ACPI code for arm_arch_timer
>
> (4)Add GTDT support for ARM memory-mapped timer, also refactor
> original memory-mapped timer dt support for reusing some common
> code.
>
> This patchset depends on the following patchset:
> [UPDATE PATCH V11 1/8] ACPI: I/O Remapping Table (IORT) initial support
> https://lkml.org/lkml/2016/9/12/949
>
> This patchset has been tested on the following platforms:
> (1)ARM Foundation v8 model
>
> Changelog:
> v14: https://lkml.org/lkml/2016/9/28/
> Separate memory-mapped timer GTDT support into two patches
> 1. Refactor the timer init code to prepare for GTDT
> 2. Add GTDT support for memory-mapped timer
>
> v13: http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1231717.html
> Improve arm_arch_timer code for memory-mapped
> timer GTDT support, refactor original memory-mapped timer
> dt support for reusing some common code.
>
> v12: https://lkml.org/lkml/2016/9/13/250
> Rebase to latest Linux 4.8-rc6
> Delete the confusing "skipping" in the error message.
>
> V11: https://lkml.org/lkml/2016/9/6/354
> Rebase to latest Linux 4.8-rc5
> Delete typedef (suggested by checkpatch.pl)
>
> V10: https://lkml.org/lkml/2016/7/26/215
> Drop the "readq" patch.
> Rebase to latest Linux 4.7.
>
> V9: https://lkml.org/lkml/2016/7/25/345
> Improve pr_err message in acpi gtdt driver.
> Update Commit message for 7/9
> shorten the irq mapping function name
> Improve GTDT driver for memory-mapped timer
>
> v8: https://lkml.org/lkml/2016/7/19/660
> Improve "pr_fmt(fmt)" definition: add "ACPI" in front of "GTDT",
> and also improve printk message.
> Simplify is_timer_block and is_watchdog.
> Merge acpi_gtdt_desc_init and gtdt_arch_timer_init into acpi_gtdt_init();
> Delete __init in include/linux/acpi.h for GTDT API
> Make ARM64 select GTDT.
> Delete "#include <linux/module.h>" from acpi_gtdt.c
> Simplify GT block parse code.
>
> v7: https://lkml.org/lkml/2016/7/13/769
> Move the GTDT driver to drivers/acpi/arm64
> Add add the ARM64-specific ACPI Support maintainers in MAINTAINERS
> Merge 3 patches of GTDT parser driver.
> Fix the for_each_platform_timer bug.
>
> v6: https://lkml.org/lkml/2016/6/29/580
> split the GTDT driver to 4 parts: basic, arch_timer, memory-mapped timer,
> and SBSA Generic Watchdog timer
> Improve driver by suggestions and example code from Daniel Lezcano
>
> v5: https://lkml.org/lkml/2016/5/24/356
> Sorting out all patches, simplify the API of GTDT driver:
> GTDT driver just fills the data struct for arm_arch_timer driver.
>
> v4: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006667.html
> Delete the kvm relevant patches
> Separate two patches for sorting out the code for arm_arch_timer.
> Improve irq info export code to allow missing irq info in GTDT table.
>
> v3: https://lkml.org/lkml/2016/2/1/658
> Improve GTDT driver code:
> (1)improve pr_* by defining pr_fmt(fmt)
> (2)simplify gtdt_sbsa_gwdt_init
> (3)improve gtdt_arch_timer_data_init, if table is NULL, it will try
> to get GTDT table.
> Move enum ppi_nr to arm_arch_timer.h, and add enum spi_nr.
> Add arm_arch_timer get ppi from DT and GTDT support for kvm.
>
> v2: https://lkml.org/lkml/2015/12/2/10
> Rebase to latest kernel version(4.4-rc3).
> Fix the bug about the config problem,
> use CONFIG_ACPI_GTDT instead of CONFIG_ACPI in arm_arch_timer.c
>
> v1: The first upstreaming version: https://lkml.org/lkml/2015/10/28/553
>
> Fu Wei (9):
> clocksource/drivers/arm_arch_timer: Move enums and defines to header
> file
> clocksource/drivers/arm_arch_timer: Add a new enum for spi type
> clocksource/drivers/arm_arch_timer: Improve printk relevant code
> acpi/arm64: Add GTDT table parse driver
> clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
> acpi/arm64: Add memory-mapped timer support in GTDT driver
> clocksource/drivers/arm_arch_timer: Refactor the timer init code to
> prepare for GTDT
> clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped
> timer
> acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver
>
> arch/arm64/Kconfig | 1 +
> drivers/acpi/arm64/Kconfig | 3 +
> drivers/acpi/arm64/Makefile | 1 +
> drivers/acpi/arm64/gtdt.c | 309 ++++++++++++++++++++++++++++++++
> drivers/clocksource/Kconfig | 2 +-
> drivers/clocksource/arm_arch_timer.c | 331 +++++++++++++++++++++--------------
> drivers/watchdog/Kconfig | 1 +
> include/clocksource/arm_arch_timer.h | 32 ++++
> include/linux/acpi.h | 7 +
> 9 files changed, 558 insertions(+), 129 deletions(-)
> create mode 100644 drivers/acpi/arm64/gtdt.c
>
^ 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