* [RFC PATCH] drivers: soc: xilinx: Add ZynqMP power domain driver
From: Jolly Shah @ 2018-01-10 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uFGuhBzXRrnuaFbdmjXSfq8Gm+Of93e3ovzdTZN1YaF9g@mail.gmail.com>
Thanks Philippe for review,
> -----Original Message-----
> From: Philippe Ombredanne [mailto:pombredanne at nexb.com]
> Sent: Tuesday, January 09, 2018 4:48 AM
> To: Jolly Shah <JOLLYS@xilinx.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>; Andy Gross
> <andy.gross@linaro.org>; Shawn Guo <shawnguo@kernel.org>;
> geert+renesas at glider.be; Bjorn Andersson <bjorn.andersson@linaro.org>; Sean
> Wang <sean.wang@mediatek.com>; Marek Szyprowski
> <m.szyprowski@samsung.com>; Michal Simek <michal.simek@xilinx.com>;
> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE <linux-arm-
> kernel at lists.infradead.org>; LKML <linux-kernel@vger.kernel.org>; Jolly Shah
> <JOLLYS@xilinx.com>; Rajan Vaja <RAJANV@xilinx.com>
> Subject: Re: [RFC PATCH] drivers: soc: xilinx: Add ZynqMP power domain driver
>
> Jolly,
>
> On Mon, Jan 8, 2018 at 11:12 PM, Jolly Shah <jolly.shah@xilinx.com> wrote:
> > The zynqmp-genpd driver communicates the usage requirements for
> > logical power domains / devices to the platform FW.
> > FW is responsible for choosing appropriate power states, taking Linux'
> > usage information into account.
> >
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > ---
>
> <snip>
>
> > --- /dev/null
> > +++ b/drivers/soc/xilinx/zynqmp/pm_domains.c
> > @@ -0,0 +1,343 @@
> > +/*
> > + * ZynqMP Generic PM domain support
> > + *
> > + * Copyright (C) 2014-2017 Xilinx, Inc.
> > + *
> > + * Davorin Mista <davorin.mista@aggios.com>
> > + * Jolly Shah <jollys@xilinx.com>
> > + * Rajan Vaja <rajanv@xilinx.com>
> > + *
> > + * SPDX-License-Identifier: GPL-2.0+
> > + */
>
> This tag should be on the fist line as this:
>
> // SPDX-License-Identifier: GPL-2.0+
>
> --
> Cordially
> Philippe Ombredanne
Will fix it in next version
^ permalink raw reply
* [PATCH 1/3] ARM: dts: enable L2 cache parity and ecc on db-xc3-24g4xg board
From: Chris Packham @ 2018-01-10 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y3l66s0r.fsf@free-electrons.com>
Hi Gregory,
On 10/01/18 21:24, Gregory CLEMENT wrote:
> Hi Chris,
>
> On mar., janv. 09 2018, Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
>
> Could you have add a (even small) message in the commit log?
>
> Also could you improve the title by specify that it applies on
> armada-xp, like this:
>
> ARM: dts: armada-xp: enable L2 cache parity and ecc on db-xc3-24g4xg
>
Will do.
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
>> arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
>> index 06fce35d7491..00ca489fc788 100644
>> --- a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
>> +++ b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
>> @@ -70,6 +70,11 @@
>> };
>> };
>>
>> +&L2 {
>> + arm,parity-enable;
>> + marvell,ecc-enable;
>
> It is not a problem for me to already applied the device tree change
> even if the driver is not merged yet. But I would like to have an
> acked-by on this new property by either a device tree maintainer or at
> least the EDAC maintainer, of course having both acked-by would be
> perfect ! :)
Thanks, I was hoping you would say that. That way I can keep this
independent of the EDAC driver changes.
>
> Thanks,
>
> Gregory
>
>
>
>
>> +};
>> +
>> &devbus_bootcs {
>> status = "okay";
>>
>> --
>> 2.15.1
>>
>
^ permalink raw reply
* [RFC PATCH 2/2] drivers: clk: Add ZynqMP clock driver
From: Jolly Shah @ 2018-01-10 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uFnzp4xPW=65A5Xyshaj-6PJx94PLi_nm4+c+csFznz-g@mail.gmail.com>
Hi Philippe,
Thanks for the review.
Will fix all SPDX tags in next version.
Thanks,
Jolly Shah
> -----Original Message-----
> From: Philippe Ombredanne [mailto:pombredanne at nexb.com]
> Sent: Tuesday, January 09, 2018 4:53 AM
> To: Jolly Shah <JOLLYS@xilinx.com>
> Cc: Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> <sboyd@codeaurora.org>; Michal Simek <michal.simek@xilinx.com>; linux-
> clk at vger.kernel.org; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE <linux-arm-kernel@lists.infradead.org>; LKML <linux-
> kernel at vger.kernel.org>; Jolly Shah <JOLLYS@xilinx.com>; Rajan Vaja
> <RAJANV@xilinx.com>; Tejas Patel <TEJASP@xilinx.com>; Shubhrajyoti Datta
> <shubhraj@xilinx.com>
> Subject: Re: [RFC PATCH 2/2] drivers: clk: Add ZynqMP clock driver
>
> Jolly,
>
> On Mon, Jan 8, 2018 at 11:16 PM, Jolly Shah <jolly.shah@xilinx.com> wrote:
> > This patch adds CCF compliant clock driver for ZynqMP.
> > Clock driver queries supported clock information from
> > firmware and regiters pll and output clocks with CCF.
> >
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > Signed-off-by: Tejas Patel <tejasp@xilinx.com>
> > Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
> > ---
>
> <snip>
>
>
> > .../devicetree/bindings/clock/zynq_mpsoc.txt | 163 +++++
> > drivers/clk/Kconfig | 1 +
> > drivers/clk/Makefile | 1 +
> > drivers/clk/zynqmp/Kconfig | 8 +
> > drivers/clk/zynqmp/Makefile | 3 +
> > drivers/clk/zynqmp/clk-gate-zynqmp.c | 158 +++++
> > drivers/clk/zynqmp/clk-mux-zynqmp.c | 190 ++++++
> > drivers/clk/zynqmp/clkc.c | 707 +++++++++++++++++++++
> > drivers/clk/zynqmp/divider.c | 239 +++++++
> > drivers/clk/zynqmp/pll.c | 384 +++++++++++
> > include/linux/clk/zynqmp.h | 46 ++
> > 11 files changed, 1900 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/clock/zynq_mpsoc.txt
> > create mode 100644 drivers/clk/zynqmp/Kconfig
> > create mode 100644 drivers/clk/zynqmp/Makefile
> > create mode 100644 drivers/clk/zynqmp/clk-gate-zynqmp.c
> > create mode 100644 drivers/clk/zynqmp/clk-mux-zynqmp.c
> > create mode 100644 drivers/clk/zynqmp/clkc.c
> > create mode 100644 drivers/clk/zynqmp/divider.c
> > create mode 100644 drivers/clk/zynqmp/pll.c
> > create mode 100644 include/linux/clk/zynqmp.h
> >
^ permalink raw reply
* [PATCH 05/10] perf tools: Add support for decoding CoreSight trace data
From: Mathieu Poirier @ 2018-01-10 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110055926.GE16554@leoy-linaro>
On 9 January 2018 at 22:59, Leo Yan <leo.yan@linaro.org> wrote:
> Hi Mike,
>
> On Tue, Jan 09, 2018 at 12:09:58PM +0000, Mike Leach wrote:
>> Hi Leo,
>>
>> The OCSD_GEN_TRC_ELEM_ADDR_NACC element indicates that the decoder
>> does not have an code image mapping for the address contained in the
>> trace, at the location described by this element. the payload for the
>> NACC element is the memory location it could not address.
>> This means that it cannot correctly follow the instruction execution
>> sequence described by the individual trace packets.
>>
>> The dump option works because we do not need to follow the execution
>> sequence to dump raw trace packets.
>>
>> It is not clear to me if the perf script option as you specified is
>> mapping the vmlinux image into the decoder.
>
> I only can say that the 'perf script' has loaded symbol list by the
> option '--kallsyms ./System.map'. Here have one corner case is for
> option '-k vmlinux', at my side I build 'perf' tool without linking
> libelf, so perf cannot directly parse kernel symbol. If the perf
> tool is built with linking libelf, then we can directly load kernel
> symbol mapping from vmlinux and don't need specifiy option
> '--kallsyms ./System.map' anymore.
>
> Could you point which perf code will pass vmlinux mapping to the
> decoder? I don't know this before. After some debugging I only found
> perf relies on OpenCSD to return back OCSD_GEN_TRC_ELEM_INSTR_RANGE
> and then perf will do symbol/sym_off analysis, otherwise it will skip
> symbol analysis.
I have hit this problem before when trying to decode kernel traces.
When using the --kallsyms option the kernel's base address isn't
correctly set and from there no symbols can be decoded (the same
happens on PT). Looking into the root cause of the problem is on my
(long) list of things to do. In the mean time try with only the -k
vmlinux option and see how far that gets you.
Mathieu
>
> BTW, I use the same 'perf script' command with OpenCSD v0.7.5, it
> can return back OCSD_GEN_TRC_ELEM_INSTR_RANGE but not
> OCSD_GEN_TRC_ELEM_ADDR_NACC so it can print out kernel symbol, this
> is for using the same perf.data and vmlinux files.
>
> Thanks,
> Leo Yan
>
>> On 30 December 2017 at 00:33, Leo Yan <leo.yan@linaro.org> wrote:
>> > Hi Mathieu, Mike,
>> >
>> > On Fri, Dec 15, 2017 at 09:44:54AM -0700, Mathieu Poirier wrote:
>> >> Adding functionality to create a CoreSight trace decoder capable
>> >> of decoding trace data pushed by a client application.
>> >>
>> >> Co-authored-by: Tor Jeremiassen <tor@ti.com>
>> >> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>> >> ---
>> >> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 119 ++++++++++++++++++++++++
>> >> 1 file changed, 119 insertions(+)
>> >>
>> >> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> >> index 6a4c86b1431f..57b020b0b36f 100644
>> >> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> >> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> >> @@ -200,6 +200,121 @@ static void cs_etm_decoder__clear_buffer(struct cs_etm_decoder *decoder)
>> >> }
>> >> }
>> >>
>> >> +static ocsd_datapath_resp_t
>> >> +cs_etm_decoder__buffer_packet(struct cs_etm_decoder *decoder,
>> >> + const ocsd_generic_trace_elem *elem,
>> >> + const u8 trace_chan_id,
>> >> + enum cs_etm_sample_type sample_type)
>> >> +{
>> >> + u32 et = 0;
>> >> + struct int_node *inode = NULL;
>> >> +
>> >> + if (decoder->packet_count >= MAX_BUFFER - 1)
>> >> + return OCSD_RESP_FATAL_SYS_ERR;
>> >> +
>> >> + /* Search the RB tree for the cpu associated with this traceID */
>> >> + inode = intlist__find(traceid_list, trace_chan_id);
>> >> + if (!inode)
>> >> + return OCSD_RESP_FATAL_SYS_ERR;
>> >> +
>> >> + et = decoder->tail;
>> >> + decoder->packet_buffer[et].sample_type = sample_type;
>> >> + decoder->packet_buffer[et].start_addr = elem->st_addr;
>> >> + decoder->packet_buffer[et].end_addr = elem->en_addr;
>> >> + decoder->packet_buffer[et].exc = false;
>> >> + decoder->packet_buffer[et].exc_ret = false;
>> >> + decoder->packet_buffer[et].cpu = *((int *)inode->priv);
>> >> +
>> >> + /* Wrap around if need be */
>> >> + et = (et + 1) & (MAX_BUFFER - 1);
>> >> +
>> >> + decoder->tail = et;
>> >> + decoder->packet_count++;
>> >> +
>> >> + if (decoder->packet_count == MAX_BUFFER - 1)
>> >> + return OCSD_RESP_WAIT;
>> >> +
>> >> + return OCSD_RESP_CONT;
>> >> +}
>> >> +
>> >> +static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
>> >> + const void *context,
>> >> + const ocsd_trc_index_t indx __maybe_unused,
>> >> + const u8 trace_chan_id __maybe_unused,
>> >> + const ocsd_generic_trace_elem *elem)
>> >> +{
>> >> + ocsd_datapath_resp_t resp = OCSD_RESP_CONT;
>> >> + struct cs_etm_decoder *decoder = (struct cs_etm_decoder *) context;
>> >
>> > After apply this patch set and build 'perf' tool with linking
>> > OpenCSDv0.8.0 libs, I can everytime OpenCSD parses 'elem->elem_type'
>> > is OCSD_GEN_TRC_ELEM_ADDR_NACC but not OCSD_GEN_TRC_ELEM_INSTR_RANGE.
>> >
>> > As result, the 'perf' tool can dump the raw data with '-D' option but
>> > it cannot analyze the symbol and symbol offset with below command:
>> >
>> > ./perf script -v -a -F cpu,event,ip,sym,symoff -i ./perf.data -k vmlinux
>> > --kallsyms ./System.map
>> >
>> > Have uploaded perf.data/vmlinux/System.map in the folder:
>> > http://people.linaro.org/~leo.yan/binaries/perf_4.15_r4/
>> >
>> > Thanks,
>> > Leo Yan
>> >
>> >> + switch (elem->elem_type) {
>> >> + case OCSD_GEN_TRC_ELEM_UNKNOWN:
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_NO_SYNC:
>> >> + decoder->trace_on = false;
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_TRACE_ON:
>> >> + decoder->trace_on = true;
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_INSTR_RANGE:
>> >> + resp = cs_etm_decoder__buffer_packet(decoder, elem,
>> >> + trace_chan_id,
>> >> + CS_ETM_RANGE);
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_EXCEPTION:
>> >> + decoder->packet_buffer[decoder->tail].exc = true;
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_EXCEPTION_RET:
>> >> + decoder->packet_buffer[decoder->tail].exc_ret = true;
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_PE_CONTEXT:
>> >> + case OCSD_GEN_TRC_ELEM_EO_TRACE:
>> >> + case OCSD_GEN_TRC_ELEM_ADDR_NACC:
>> >> + case OCSD_GEN_TRC_ELEM_TIMESTAMP:
>> >> + case OCSD_GEN_TRC_ELEM_CYCLE_COUNT:
>> >> + case OCSD_GEN_TRC_ELEM_ADDR_UNKNOWN:
>> >> + case OCSD_GEN_TRC_ELEM_EVENT:
>> >> + case OCSD_GEN_TRC_ELEM_SWTRACE:
>> >> + case OCSD_GEN_TRC_ELEM_CUSTOM:
>> >> + default:
>> >> + break;
>> >> + }
>> >> +
>> >> + return resp;
>> >> +}
>> >> +
>> >> +static int cs_etm_decoder__create_etm_packet_decoder(
>> >> + struct cs_etm_trace_params *t_params,
>> >> + struct cs_etm_decoder *decoder)
>> >> +{
>> >> + const char *decoder_name;
>> >> + ocsd_etmv4_cfg trace_config_etmv4;
>> >> + void *trace_config;
>> >> + u8 csid;
>> >> +
>> >> + switch (t_params->protocol) {
>> >> + case CS_ETM_PROTO_ETMV4i:
>> >> + cs_etm_decoder__gen_etmv4_config(t_params, &trace_config_etmv4);
>> >> + decoder_name = OCSD_BUILTIN_DCD_ETMV4I;
>> >> + trace_config = &trace_config_etmv4;
>> >> + break;
>> >> + default:
>> >> + return -1;
>> >> + }
>> >> +
>> >> + if (ocsd_dt_create_decoder(decoder->dcd_tree,
>> >> + decoder_name,
>> >> + OCSD_CREATE_FLG_FULL_DECODER,
>> >> + trace_config, &csid))
>> >> + return -1;
>> >> +
>> >> + if (ocsd_dt_set_gen_elem_outfn(decoder->dcd_tree,
>> >> + cs_etm_decoder__gen_trace_elem_printer,
>> >> + decoder))
>> >> + return -1;
>> >> +
>> >> + return 0;
>> >> +}
>> >> +
>> >> static int
>> >> cs_etm_decoder__create_etm_decoder(struct cs_etm_decoder_params *d_params,
>> >> struct cs_etm_trace_params *t_params,
>> >> @@ -208,6 +323,10 @@ cs_etm_decoder__create_etm_decoder(struct cs_etm_decoder_params *d_params,
>> >> if (d_params->operation == CS_ETM_OPERATION_PRINT)
>> >> return cs_etm_decoder__create_etm_packet_printer(t_params,
>> >> decoder);
>> >> + else if (d_params->operation == CS_ETM_OPERATION_DECODE)
>> >> + return cs_etm_decoder__create_etm_packet_decoder(t_params,
>> >> + decoder);
>> >> +
>> >> return -1;
>> >> }
>> >>
>> >> --
>> >> 2.7.4
>> >>
>> >
>> > _______________________________________________
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>>
>> --
>> Mike Leach
>> Principal Engineer, ARM Ltd.
>> Blackburn Design Centre. UK
^ permalink raw reply
* [PATCH 2/3] ARM: dts: mvebu: add sdram controller node to Armada-38x
From: Chris Packham @ 2018-01-10 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87tvvu6ro6.fsf@free-electrons.com>
On 10/01/18 21:31, Gregory CLEMENT wrote:
> Hi Chris,
>
> On mar., janv. 09 2018, Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
>
>> The Armada-38x uses an SDRAM controller that is compatible with the
>> Armada-XP. The key difference is the width of the bus (XP is 64/32, 38x
>> is 32/16). The SDRAM controller registers are the same between the two
>> SoCs.
>>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
>> arch/arm/boot/dts/armada-38x.dtsi | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
>> index 00ff549d4e39..6d34c5ec178f 100644
>> --- a/arch/arm/boot/dts/armada-38x.dtsi
>> +++ b/arch/arm/boot/dts/armada-38x.dtsi
>> @@ -138,6 +138,11 @@
>> #size-cells = <1>;
>> ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
>>
>> + sdramc at 1400 {
>
> Could you add a label? Thanks to this it would be possible to
> enable/disable it at board level in a esay way.
>
Sure. Any suggestions for a name better than "sdramc:"?
It's probably worth adding the same label to armada-xp.dtsi and
armada-xp-98dx3236.dtsi.
>> + compatible = "marvell,armada-xp-sdram-controller";
>> + reg = <0x1400 0x500>;
>
> What about adding status = "disabled" ?
>
> Thanks to this we can enable it at board level only if we really want
> it, it would avoid nasty regression on boards that don't need it, if an
> issue occurs. Unless you are sure that it is completely safe to enable
> it for everyone.
The EDAC driver (which is default n) will not probe the device if ECC
has not been enabled so that should be safe.
Other than the EDAC driver the only other code that looks at this is in
arch/arm/mach-mvebu/pm.c and it almost seems like an omission that this
code is not active on armada-38x. The armada-38x platforms I have access
to don't use suspend/resume so I can't verify this.
^ permalink raw reply
* [RFC PATCH] drivers: soc: xilinx: Add ZynqMP PM driver
From: Jolly Shah @ 2018-01-10 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515467395.31546.11.camel@mtkswgap22>
Thanks Sean for review,
> -----Original Message-----
> From: Sean Wang [mailto:sean.wang at mediatek.com]
> Sent: Monday, January 08, 2018 7:10 PM
> To: Jolly Shah <JOLLYS@xilinx.com>
> Cc: matthias.bgg at gmail.com; andy.gross at linaro.org; shawnguo at kernel.org;
> geert+renesas at glider.be; bjorn.andersson at linaro.org;
> m.szyprowski at samsung.com; michal.simek at xilinx.com; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Jolly Shah
> <JOLLYS@xilinx.com>; Rajan Vaja <RAJANV@xilinx.com>
> Subject: Re: [RFC PATCH] drivers: soc: xilinx: Add ZynqMP PM driver
>
> On Mon, 2018-01-08 at 14:10 -0800, Jolly Shah wrote:
> > Add ZynqMP PM driver. PM driver provides power management support for
> > ZynqMP.
> >
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > ---
> > .../bindings/soc/xilinx/xlnx,zynqmp-pm.txt | 15 ++
>
>
> The patch should be split into two: one is for dt-bindings part and the other is for
> driver part. Where dt-binding part should require additionally to send to Rob and
> Cc. devicetree at vger.kernel.org.
>
Sure. Will do it in next version.
> > diff --git a/drivers/soc/xilinx/zynqmp/Makefile
> > b/drivers/soc/xilinx/zynqmp/Makefile
> > new file mode 100644
> > index 0000000..98034f7
> > --- /dev/null
> > +++ b/drivers/soc/xilinx/zynqmp/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_ZYNQMP_PM) += pm.o
> > diff --git a/drivers/soc/xilinx/zynqmp/pm.c
> > b/drivers/soc/xilinx/zynqmp/pm.c new file mode 100644 index
> > 0000000..7178fb5
> > --- /dev/null
> > +++ b/drivers/soc/xilinx/zynqmp/pm.c
> > @@ -0,0 +1,265 @@
> > +/*
> > + * Xilinx Zynq MPSoC Power Management
> > + *
> > + * Copyright (C) 2014-2017 Xilinx, Inc.
>
> should include 2018 ?
>
Will fix in next version
> > + if (!eemi_ops || !eemi_ops->get_api_version)
> > + return -ENXIO;
> > +
> > + eemi_ops->get_api_version(&pm_api_version);
> > +
> > + /* Check PM API version number */
> > + if (pm_api_version != ZYNQMP_PM_VERSION)
> > + return -ENODEV;
> > +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq <= 0)
> > + return -ENXIO;
> > +
> > + ret = request_irq(irq, zynqmp_pm_isr, IRQF_SHARED, DRIVER_NAME,
> pdev);
> > + if (ret) {
> > + dev_err(&pdev->dev, "request_irq '%d' failed with %d\n",
> > + irq, ret);
> > + return ret;
> > + }
>
>
> how about use devm_request_irq to simplify error path?
Will change in next version
Thanks,
Jolly Shah
^ permalink raw reply
* [PATCH] ARM: pxa/tosa-bt: add MODULE_LICENSE tag
From: Robert Jarzmik @ 2018-01-10 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110162816.431038-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> Without this tag, we get a build warning:
>
> WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o
>
> For completeness, I'm also adding author and description fields.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Queued into pxa/for-next, thanks.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers
From: Greg KH @ 2018-01-10 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8997e43c-683e-418d-4e2b-1fe3fefe254e@linux.intel.com>
On Wed, Jan 10, 2018 at 11:30:05AM -0800, Jae Hyun Yoo wrote:
> On 1/10/2018 11:17 AM, Greg KH wrote:
> > On Wed, Jan 10, 2018 at 11:14:34AM -0800, Jae Hyun Yoo wrote:
> > > On 1/10/2018 2:17 AM, Greg KH wrote:
> > > > On Tue, Jan 09, 2018 at 02:31:20PM -0800, Jae Hyun Yoo wrote:
> > > > > From: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
> > > > >
> > > > > Hello,
> > > > >
> > > > > This patch set provides support for PECI of AST2400/2500 which can give us PECI
> > > > > functionalities such as temperature monitoring, platform manageability,
> > > > > processor diagnostics and failure analysis. Also provides generic peci.h and
> > > > > peci_ioctl.h headers to provide compatibility to peci drivers that can be
> > > > > implemented later e.g. Nuvoton's BMC SoC family.
> > > >
> > > > What is the "dev-4.10" in the subject for? 4.10 is really old and
> > > > obsolete :(
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > >
> > >
> > > I made this patch set on top of the v4.10 which OpenBmc project is currently
> > > using. I'll rebase this patch set onto the current kernel.org mainline.
> >
> > What is "OpenBmc", and why are they using an obsolete and insecure
> > kernel for their project? That seems like a very foolish thing to do...
> >
> > thanks,
> >
> > greg k-h
> >
>
> OpenBmc is an open source project to create a highly extensible framework
> for BMC (Board Management Controller) software for data-center computer
> systems:
> https://github.com/openbmc
>
> Its current mainline is v4.10 but it is being kept upgrading so it will be
> upgraded to the latest stable or long-term version soon.
Why hasn't it been updated in the year since 4.10 was released? That's
a _very_ long time to be running on a totally insecure kernel, and no
new development should ever be done on old kernels, that's even crazier
(as we can't go back in time and accept patches for new features to old
releases...)
It sounds like the openbmc project needs to learn how to manage their
kernels a whole lot better, who do I need to go poke about this?
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Andrew Lunn @ 2018-01-10 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110170743.27082-3-gregory.clement@free-electrons.com>
On Wed, Jan 10, 2018 at 06:07:43PM +0100, Gregory CLEMENT wrote:
> On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
> is optional because not all the SoCs need them but at least for Armada
> 7K/8K it is actually mandatory.
>
> The binding documentation is updating accordingly.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> .../devicetree/bindings/i2c/i2c-mv64xxx.txt | 20 ++++++++++++++++++++
> drivers/i2c/busses/i2c-mv64xxx.c | 12 +++++++++++-
> 2 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> index 5c30026921ae..a835b724c738 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> @@ -25,6 +25,15 @@ default frequency is 100kHz
> whenever you're using the "allwinner,sun6i-a31-i2c"
> compatible.
>
> + - clocks: : pointers to the reference clocks for this device, the first
> + one is the one used for the clock on the i2c bus, the second
> + one is the clock used for the functional part of the
> + controller
> +
> + - clock-names : names of used clocks, mandatory if the second clock is
> + : used, the name must be "core", and "axi_clk" (the latter is
> + only for Armada 7K/8K).
Hi Gregory
Are these two clocks related?
Ethernet on Dove needs two clocks enabled.
static const struct clk_gating_soc_desc dove_gating_desc[] __initconst = {
{ "usb0", NULL, 0, 0 },
{ "usb1", NULL, 1, 0 },
{ "ge", "gephy", 2, 0 },
{ "sata", NULL, 3, 0 },
ge has a parent clock gephy. When you enable ge, the common clock code
walks up the tree of clocks, so will also turn on gephy.
Does this child/parent relationship exist with these i2c clocks?
Andrew
^ permalink raw reply
* [PATCH net-next 1/2 v10] net: ethernet: Add DT bindings for the Gemini ethernet
From: David Miller @ 2018-01-10 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109221053.927-1-linus.walleij@linaro.org>
From: Linus Walleij <linus.walleij@linaro.org>
Date: Tue, 9 Jan 2018 23:10:52 +0100
> This adds the device tree bindings for the Gemini ethernet
> controller. It is pretty straight-forward, using standard
> bindings and modelling the two child ports as child devices
> under the parent ethernet controller device.
>
> Cc: devicetree at vger.kernel.org
> Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
> Cc: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Applied.
^ permalink raw reply
* [PATCH net-next 2/2 v10] net: ethernet: Add a driver for Gemini gigabit ethernet
From: David Miller @ 2018-01-10 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109221053.927-2-linus.walleij@linaro.org>
From: Linus Walleij <linus.walleij@linaro.org>
Date: Tue, 9 Jan 2018 23:10:53 +0100
> The Gemini ethernet has been around for years as an out-of-tree
> patch used with the NAS boxen and routers built on StorLink
> SL3512 and SL3516, later Storm Semiconductor, later Cortina
> Systems. These ASICs are still being deployed and brand new
> off-the-shelf systems using it can easily be acquired.
>
> The full name of the IP block is "Net Engine and Gigabit
> Ethernet MAC" commonly just called "GMAC".
>
> The hardware block contains a common TCP Offload Enginer (TOE)
> that can be used by both MACs. The current driver does not use
> it.
>
> Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
> Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Applied.
^ permalink raw reply
* [PATCH net-next 2/2 v10] net: ethernet: Add a driver for Gemini gigabit ethernet
From: David Miller @ 2018-01-10 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110.154113.1759667248487481665.davem@davemloft.net>
Actually I had to revert these two patches, this stuff doesn't even
build.
[davem at dhcp-10-15-49-227 net-next]$ make -s -j16
In file included from ./include/linux/printk.h:329:0,
from ./include/linux/kernel.h:14,
from ./include/linux/list.h:9,
from ./include/linux/module.h:9,
from drivers/net/ethernet/cortina/gemini.c:16:
drivers/net/ethernet/cortina/gemini.c: In function ?geth_freeq_alloc_map_page?:
drivers/net/ethernet/cortina/gemini.c:821:21: warning: format ?%x? expects argument of type ?unsigned int?, but argument 5 has type ?dma_addr_t {aka long long unsigned int}? [-Wformat=]
dev_dbg(geth->dev, "page %d, DMA addr: %08x, page %p\n",
^
./include/linux/dynamic_debug.h:135:39: note: in definition of macro ?dynamic_dev_dbg?
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
drivers/net/ethernet/cortina/gemini.c:821:2: note: in expansion of macro ?dev_dbg?
dev_dbg(geth->dev, "page %d, DMA addr: %08x, page %p\n",
^~~~~~~
drivers/net/ethernet/cortina/gemini.c: In function ?gmac_rx?:
drivers/net/ethernet/cortina/gemini.c:1410:50: warning: format ?%x? expects argument of type ?unsigned int?, but argument 3 has type ?dma_addr_t {aka long long unsigned int}? [-Wformat=]
dev_err(geth->dev, "could not find mapping %08x (page = %08x, page off = %08x)\n",
~~~^
%08llx
drivers/net/ethernet/cortina/gemini.c:1410:63: warning: format ?%x? expects argument of type ?unsigned int?, but argument 4 has type ?long long unsigned int? [-Wformat=]
dev_err(geth->dev, "could not find mapping %08x (page = %08x, page off = %08x)\n",
~~~^
%08llx
drivers/net/ethernet/cortina/gemini.c: In function ?gemini_ethernet_port_probe?:
drivers/net/ethernet/cortina/gemini.c:2456:28: warning: format ?%x? expects argument of type ?unsigned int?, but argument 4 has type ?resource_size_t {aka long long unsigned int}? [-Wformat=]
"irq %d, DMA @ 0x%08x, GMAC @ 0x%08x\n",
~~~^
%08llx
port->irq, dmares->start,
~~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2456:43: warning: format ?%x? expects argument of type ?unsigned int?, but argument 5 has type ?resource_size_t {aka long long unsigned int}? [-Wformat=]
"irq %d, DMA @ 0x%08x, GMAC @ 0x%08x\n",
~~~^
%08llx
drivers/net/ethernet/cortina/gemini.c:2458:8:
gmacres->start);
~~~~~~~~~~~~~~
In file included from drivers/net/ethernet/cortina/gemini.c:16:0:
drivers/net/ethernet/cortina/gemini.c: At top level:
./include/linux/module.h:129:42: error: redefinition of ?__inittest?
static inline initcall_t __maybe_unused __inittest(void) \
^
./include/linux/device.h:1513:1: note: in expansion of macro ?module_init?
module_init(__driver##_init); \
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:129:42: note: previous definition of ?__inittest? was here
static inline initcall_t __maybe_unused __inittest(void) \
^
./include/linux/device.h:1513:1: note: in expansion of macro ?module_init?
module_init(__driver##_init); \
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_port_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:131:6: error: redefinition of ?init_module?
int init_module(void) __attribute__((alias(#initfn)));
^
./include/linux/device.h:1513:1: note: in expansion of macro ?module_init?
module_init(__driver##_init); \
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:131:6: note: previous definition of ?init_module? was here
int init_module(void) __attribute__((alias(#initfn)));
^
./include/linux/device.h:1513:1: note: in expansion of macro ?module_init?
module_init(__driver##_init); \
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_port_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:135:42: error: redefinition of ?__exittest?
static inline exitcall_t __maybe_unused __exittest(void) \
^
./include/linux/device.h:1518:1: note: in expansion of macro ?module_exit?
module_exit(__driver##_exit);
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:135:42: note: previous definition of ?__exittest? was here
static inline exitcall_t __maybe_unused __exittest(void) \
^
./include/linux/device.h:1518:1: note: in expansion of macro ?module_exit?
module_exit(__driver##_exit);
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_port_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:137:7: error: redefinition of ?cleanup_module?
void cleanup_module(void) __attribute__((alias(#exitfn)));
^
./include/linux/device.h:1518:1: note: in expansion of macro ?module_exit?
module_exit(__driver##_exit);
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:137:7: note: previous definition of ?cleanup_module? was here
void cleanup_module(void) __attribute__((alias(#exitfn)));
^
./include/linux/device.h:1518:1: note: in expansion of macro ?module_exit?
module_exit(__driver##_exit);
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_port_driver);
^~~~~~~~~~~~~~~~~~~~~~
make[4]: *** [scripts/Makefile.build:317: drivers/net/ethernet/cortina/gemini.o] Error 1
make[3]: *** [scripts/Makefile.build:569: drivers/net/ethernet/cortina] Error 2
make[3]: *** Waiting for unfinished jobs....
^ permalink raw reply
* [PATCH 2/2] soc: imx: gpc: Do not pass static memory as platform data
From: Stefan Agner @ 2018-01-10 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110161608.13015-2-andrew.smirnov@gmail.com>
On 2018-01-10 17:16, Andrey Smirnov wrote:
> Platform device core assumes the ownership of dev.platform_data as
> well as that it is dynamically allocated and it will try to kfree it
> as a part of platform_device_release(). Change the code to pass
> kzalloc'ed chunk of memory instead of a pointer to a static memory to
> avoid causing a BUG() when calling platform_device_put().
I tried to get around that by setting platform_data to null before
unregistring the device, see:
https://marc.info/?l=linux-arm-kernel&m=151553216030129&w=2
This solutions still seems to miss unregistering the platform devices,
which shows when binding the driver again:
root at colibri-imx6:~# echo 20dc000.gpc >
/sys/bus/platform/drivers/imx-gpc/unbind
[ 80.702627] imx-pgc-pd imx-pgc-power-domain.0: Dropping the link to
20dc000.gpc
[ 80.710808] genpd_remove: unable to remove PU
[ 80.716408] imx-pgc-pd imx-pgc-power-domain.1: Dropping the link to
20dc000.gpc
root at colibri-imx6:~# find /sys -name *pgc-power*
/sys/devices/soc0/soc/2000000.aips-bus/20dc000.gpc/imx-pgc-power-domain.0
/sys/devices/soc0/soc/2000000.aips-bus/20dc000.gpc/imx-pgc-power-domain.1
/sys/bus/platform/devices/imx-pgc-power-domain.0
/sys/bus/platform/devices/imx-pgc-power-domain.1
root at colibri-imx6:~# echo 20dc000.gpc >
/sys/bus/platform/drivers/imx-gpc/bind
[ 89.002754] ------------[ cut here ]------------
[ 89.007411] WARNING: CPU: 0 PID: 516 at fs/sysfs/dir.c:31
sysfs_warn_dup+0x64/0x74
[ 89.015057] sysfs: cannot create duplicate filename
'/devices/soc0/soc/2000000.aips-bus/20dc000.gpc/imx-pgc-power-domain.0'
>
> The problem can be reproduced by artificially enabling the error path
> of platform_device_add() call (around line 452).
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Stefan Agner <stefan@agner.ch>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
>
> This patch is a follow up to fix one of the bugs discussed in
> lkml.kernel.org/r/3f836677c6e98aaf01bc1ac8c3410083 at agner.ch
>
> drivers/soc/imx/gpc.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 47e7aa963dbb..ec8b79abebac 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -18,6 +18,7 @@
> #include <linux/pm_domain.h>
> #include <linux/regmap.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/slab.h>
>
> #define GPC_CNTR 0x000
>
> @@ -428,13 +429,19 @@ static int imx_gpc_probe(struct platform_device *pdev)
> if (domain_index >= of_id_data->num_domains)
> continue;
>
> - domain = &imx_gpc_domains[domain_index];
> + domain = kzalloc(sizeof(*domain), GFP_KERNEL);
I guess you could use just kalloc here since you memcpy below.
--
Stefan
> + if (!domain) {
> + of_node_put(np);
> + return -ENOMEM;
> + }
> + memcpy(domain, &imx_gpc_domains[domain_index], sizeof(*domain));
> domain->regmap = regmap;
> domain->ipg_rate_mhz = ipg_rate_mhz;
>
> pd_pdev = platform_device_alloc("imx-pgc-power-domain",
> domain_index);
> if (!pd_pdev) {
> + kfree(domain);
> of_node_put(np);
> return -ENOMEM;
> }
^ permalink raw reply
* [PATCH 0/7] ARM: dts: STi: Fix DT dtc warnings
From: Arnd Bergmann @ 2018-01-10 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20f04806-2f33-3c16-d790-4a93c4c7187a@st.com>
On Wed, Jan 10, 2018 at 6:17 PM, Patrice CHOTARD <patrice.chotard@st.com> wrote:
> Hi Arnd
>
> On 01/10/2018 04:52 PM, Arnd Bergmann wrote:
>> On Wed, Jan 10, 2018 at 9:21 AM, <patrice.chotard@st.com> wrote:
>>> From: Patrice Chotard <patrice.chotard@st.com>
>>>
>>> This series fixes all dtc warnings related to STi platforms dt files.
>>> It has been triggered by Rob Herring [1]
>>>
>>> [1] https://www.spinics.net/lists/devicetree/msg206209.html
>>>
>>> For most of implicated node, a simple move outside the soc node
>>> solves the warnings.
>>>
>>> Patrice Chotard (7):
>>> ARM: dts: STi: fix bindings notation
>>> ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property
>>> ARM: dts: STi: Move clocks without reg outside soc
>>> ARM: dts: STi: Move leds node outside soc node
>>> ARM: dts: STi: Move usb2_picophyX nodes without reg out of soc
>>> ARM: dts: STi: Move sound related nodes without reg out of soc
>>> ARM: dts: STi: Add fake reg property for sti-display-subsystem
>>
>> Thanks a lot for addressing these!
>>
>> As far as I can tell, there is one patch in particular that addresses a warning
>> we get at the default warning level: "ARM: dts: STi: Add gpio polarity for
>> "hdmi,hpd-gpio" property". Should we merge that one for 4.15 to get closer
>> to a clean build again? I'm not sure whether we can address the other
>
> How do you want to proceed with this particular patch ?
> Do you want me to send a pull-request with this patch ?
>
> Patrice
I'd just pick it up directly into the arm-soc fixes branch if that
works for you.
Arnd
^ permalink raw reply
* [PATCH] phy: work around 'phys' references to usb-phy devices
From: Arnd Bergmann @ 2018-01-10 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aa02104b-d80d-8b12-4403-b5cedc23f03a@ti.com>
On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi Arnd,
>
> On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote:
>> Stefan Wahren reports a problem with a warning fix that was merged
>> for v4.15: we had lots of device nodes with a 'phys' property pointing
>> to a device node that is not compliant with the binding documented in
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> This generally works because USB HCD drivers that support both the generic
>> phy subsystem and the older usb-phy subsystem ignore most errors from
>> phy_get() and related calls and then use the usb-phy driver instead.
>>
>> However, usb_add_hcd() (along with the respective functions in dwc2 and
>> dwc3) propagate the EPROBE_DEFER return code so we can try again whenever
>> the driver gets loaded. In case the driver is written for the usb-phy
>> subsystem (like usb-generic-phy aka usb-nop-xceiv), we will never load
>> a generic-phy driver for it, and keep failing here.
>>
>> There is only a small number of remaining usb-phy drivers that support
>> device tree, so this adds a workaround by providing a full list of the
>> potentially affected drivers, and always failing the probe with -ENODEV
>> here, which is the same behavior that we used to get with incorrect
>> device tree files. Since we generally want older kernels to also want
>> to work with the fixed devicetree files, it would be good to backport
>> the patch into stable kernels as well (3.13+ are possibly affected).
>> Reverting back to the DTS sources that work would in theory fix USB
>> support for now, but in the long run we'd run into the same problem
>> again when the drivers get ported from usb-phy to generic-phy.
>>
>> Fixes: 014d6da6cb25 ("ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells")
>> Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
>> Cc: stable at vger.kernel.org
>> Cc: Stefan Wahren <stefan.wahren@i2se.com>
>> Cc: Felipe Balbi <balbi@kernel.org>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> This obviously needs to be tested, I wrote this up as a reply to
>> Stefan's bug report. I'm fairly sure that I covered all usb-phy
>> driver strings here. My goal is to have a fix merged into 4.15
>> rather than reverting all the DT fixes.
>
> Shouldn't the fix be in phy consumer drivers to not return error if it's able
> to find the phy either using usb-phy or generic phy?
Stefan has posted a patch to that effect now, but I fear that might be
a little fragile, in particular this short before the release with the
regression
in place.
The main problem is that we'd have to change the generic
usb_add_hcd() function in addition to dwc2 and dwc3 to ignore
-EPROBE_DEFER from phy_get() whenever usb_get_phy_dev()
has already succeeded.
If there is any HCD that relies on usb_add_hcd() to get both the
usb_phy and the phy structures, and it may need to defer probing
when the latter one isn't ready yet, that fix would break another
driver.
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>> index b4964b067aec..bb4dd2a2de2d 100644
>> --- a/drivers/phy/phy-core.c
>> +++ b/drivers/phy/phy-core.c
>> @@ -387,6 +387,24 @@ int phy_calibrate(struct phy *phy)
>> }
>> EXPORT_SYMBOL_GPL(phy_calibrate);
>>
>> +static struct of_device_id __maybe_unused legacy_usbphy[] = {
>> + { .compatible = "fsl,imx23-usbphy" },
>> + { .compatible = "fsl,imx6q-usbphy" },
>> + { .compatible = "fsl,imx6sl-usbphy" },
>> + { .compatible = "fsl,imx6sx-usbphy" },
>> + { .compatible = "fsl,imx6ul-usbphy" },
>> + { .compatible = "fsl,vf610-usbphy" },
>> + { .compatible = "nvidia,tegra20-usb-phy" },
>> + { .compatible = "nvidia,tegra30-usb-phy" },
>> + { .compatible = "nxp,isp1301" },
>> + { .compatible = "ti,am335x-usb-ctrl-module" },
>> + { .compatible = "ti,am335x-usb-phy" },
>> + { .compatible = "ti,keystone-usbphy" },
>> + { .compatible = "ti,twl6030-usb" },
>> + { .compatible = "usb-nop-xceiv" },
>> + {},
>
> "ti,am335x-usb-ctrl-module" and "ti,twl6030-usb" are not phys.
Ok, I see.
Arnd
^ permalink raw reply
* [PATCH] arm64: dts: socfpga: add missing interrupt-parent
From: Arnd Bergmann @ 2018-01-10 21:04 UTC (permalink / raw)
To: linux-arm-kernel
The PMU node has no working interrupt, as shown by this dtc warning:
arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu
This adds an interrupt-parent property so we can correct parse
that interrupt number.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
If this looks ok, I'd apply it directly to the fixes branch
for 4.15, as the warning is one that was introduced in this
release.
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index 7c9bdc7ab50b..9db19314c60c 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -66,6 +66,7 @@
<&cpu1>,
<&cpu2>,
<&cpu3>;
+ interrupt-parent = <&intc>;
};
psci {
--
2.9.0
^ permalink raw reply related
* [PATCH v2 1/7] ARM: imx: add timer stop flag to ARM power off state
From: Stefan Agner @ 2018-01-10 21:04 UTC (permalink / raw)
To: linux-arm-kernel
When the CPU is in ARM power off state the ARM architected
timers are stopped. The flag is already present in the higher
power WAIT mode.
This allows to use the ARM generic timer on i.MX 6UL/6ULL SoC.
Without the flag the kernel freezes when the timer enters the
first time ARM power off mode.
Note: The default timer on i.MX6SX is the i.MX GPT timer which is
not disabled during CPU idle. However, the timer is not affected
by the CPUIDLE_FLAG_TIMER_STOP flag. The flag only affects CPU
local timers.
Cc: Anson Huang <anson.huang@nxp.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
---
arch/arm/mach-imx/cpuidle-imx6sx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/cpuidle-imx6sx.c b/arch/arm/mach-imx/cpuidle-imx6sx.c
index c5a5c3a70ab1..d0f14b761ff7 100644
--- a/arch/arm/mach-imx/cpuidle-imx6sx.c
+++ b/arch/arm/mach-imx/cpuidle-imx6sx.c
@@ -89,6 +89,7 @@ static struct cpuidle_driver imx6sx_cpuidle_driver = {
*/
.exit_latency = 300,
.target_residency = 500,
+ .flags = CPUIDLE_FLAG_TIMER_STOP,
.enter = imx6sx_enter_wait,
.name = "LOW-POWER-IDLE",
.desc = "ARM power off",
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/7] ARM: dts: imx6ul: update i.MX 6UltraLite iomux headers
From: Stefan Agner @ 2018-01-10 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110210453.19264-1-stefan@agner.ch>
From: Fugang Duan <fugang.duan@nxp.com>
Add previously missing daisy chain configurations and several
additional pinmux options.
Synchronized with NXP Linux 4.9.11_1.0.0 release.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Rob Herring <robh@kernel.org>
---
arch/arm/boot/dts/imx6ul-pinfunc.h | 169 +++++++++++++++++++++----------------
1 file changed, 97 insertions(+), 72 deletions(-)
diff --git a/arch/arm/boot/dts/imx6ul-pinfunc.h b/arch/arm/boot/dts/imx6ul-pinfunc.h
index 0034eeb84542..9538b0ed5c11 100644
--- a/arch/arm/boot/dts/imx6ul-pinfunc.h
+++ b/arch/arm/boot/dts/imx6ul-pinfunc.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ * Copyright 2014 - 2015 Freescale Semiconductor, Inc.
*
* 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
@@ -34,14 +34,14 @@
#define MX6UL_PAD_JTAG_MOD__ENET1_REF_CLK_25M 0x0044 0x02d0 0x0000 3 0
#define MX6UL_PAD_JTAG_MOD__CCM_PMIC_RDY 0x0044 0x02d0 0x04c0 4 0
#define MX6UL_PAD_JTAG_MOD__GPIO1_IO10 0x0044 0x02d0 0x0000 5 0
-#define MX6UL_PAD_JTAG_MOD__SDMA_EXT_EVENT00 0x0044 0x02d0 0x0000 6 0
+#define MX6UL_PAD_JTAG_MOD__SDMA_EXT_EVENT00 0x0044 0x02d0 0x0610 6 0
#define MX6UL_PAD_JTAG_TMS__SJC_TMS 0x0048 0x02d4 0x0000 0 0
#define MX6UL_PAD_JTAG_TMS__GPT2_CAPTURE1 0x0048 0x02d4 0x0598 1 0
-#define MX6UL_PAD_JTAG_TMS__SAI2_MCLK 0x0048 0x02d4 0x0000 2 0
+#define MX6UL_PAD_JTAG_TMS__SAI2_MCLK 0x0048 0x02d4 0x05f0 2 0
#define MX6UL_PAD_JTAG_TMS__CCM_CLKO1 0x0048 0x02d4 0x0000 3 0
#define MX6UL_PAD_JTAG_TMS__CCM_WAIT 0x0048 0x02d4 0x0000 4 0
#define MX6UL_PAD_JTAG_TMS__GPIO1_IO11 0x0048 0x02d4 0x0000 5 0
-#define MX6UL_PAD_JTAG_TMS__SDMA_EXT_EVENT01 0x0048 0x02d4 0x0000 6 0
+#define MX6UL_PAD_JTAG_TMS__SDMA_EXT_EVENT01 0x0048 0x02d4 0x0614 6 0
#define MX6UL_PAD_JTAG_TMS__EPIT1_OUT 0x0048 0x02d4 0x0000 8 0
#define MX6UL_PAD_JTAG_TDO__SJC_TDO 0x004c 0x02d8 0x0000 0 0
#define MX6UL_PAD_JTAG_TDO__GPT2_CAPTURE2 0x004c 0x02d8 0x059c 1 0
@@ -63,12 +63,14 @@
#define MX6UL_PAD_JTAG_TCK__SAI2_RX_DATA 0x0054 0x02e0 0x05f4 2 0
#define MX6UL_PAD_JTAG_TCK__PWM7_OUT 0x0054 0x02e0 0x0000 4 0
#define MX6UL_PAD_JTAG_TCK__GPIO1_IO14 0x0054 0x02e0 0x0000 5 0
+#define MX6UL_PAD_JTAG_TCK__REF_CLK_32K 0x0054 0x02e0 0x0000 6 0
#define MX6UL_PAD_JTAG_TCK__SIM2_POWER_FAIL 0x0054 0x02e0 0x0000 8 0
#define MX6UL_PAD_JTAG_TRST_B__SJC_TRSTB 0x0058 0x02e4 0x0000 0 0
#define MX6UL_PAD_JTAG_TRST_B__GPT2_COMPARE3 0x0058 0x02e4 0x0000 1 0
#define MX6UL_PAD_JTAG_TRST_B__SAI2_TX_DATA 0x0058 0x02e4 0x0000 2 0
#define MX6UL_PAD_JTAG_TRST_B__PWM8_OUT 0x0058 0x02e4 0x0000 4 0
#define MX6UL_PAD_JTAG_TRST_B__GPIO1_IO15 0x0058 0x02e4 0x0000 5 0
+#define MX6UL_PAD_JTAG_TRST_B__REF_CLK_24M 0x0058 0x02e4 0x0000 6 0
#define MX6UL_PAD_JTAG_TRST_B__CAAM_RNG_OSC_OBS 0x0058 0x02e4 0x0000 8 0
#define MX6UL_PAD_GPIO1_IO00__I2C2_SCL 0x005c 0x02e8 0x05ac 0 1
#define MX6UL_PAD_GPIO1_IO00__GPT1_CAPTURE1 0x005c 0x02e8 0x058c 1 0
@@ -94,22 +96,24 @@
#define MX6UL_PAD_GPIO1_IO02__ENET1_REF_CLK_25M 0x0064 0x02f0 0x0000 3 0
#define MX6UL_PAD_GPIO1_IO02__USDHC1_WP 0x0064 0x02f0 0x066c 4 0
#define MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0x0064 0x02f0 0x0000 5 0
-#define MX6UL_PAD_GPIO1_IO02__SDMA_EXT_EVENT00 0x0064 0x02f0 0x0000 6 0
+#define MX6UL_PAD_GPIO1_IO02__SDMA_EXT_EVENT00 0x0064 0x02f0 0x0610 6 1
#define MX6UL_PAD_GPIO1_IO02__SRC_ANY_PU_RESET 0x0064 0x02f0 0x0000 7 0
#define MX6UL_PAD_GPIO1_IO02__UART1_DCE_TX 0x0064 0x02f0 0x0000 8 0
#define MX6UL_PAD_GPIO1_IO02__UART1_DTE_RX 0x0064 0x02f0 0x0624 8 0
#define MX6UL_PAD_GPIO1_IO03__I2C1_SDA 0x0068 0x02f4 0x05a8 0 1
#define MX6UL_PAD_GPIO1_IO03__GPT1_COMPARE3 0x0068 0x02f4 0x0000 1 0
#define MX6UL_PAD_GPIO1_IO03__USB_OTG2_OC 0x0068 0x02f4 0x0660 2 0
+#define MX6UL_PAD_GPIO1_IO03__REF_CLK_32K 0x0068 0x02f4 0x0000 3 0
#define MX6UL_PAD_GPIO1_IO03__USDHC1_CD_B 0x0068 0x02f4 0x0668 4 0
#define MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0x0068 0x02f4 0x0000 5 0
-#define MX6UL_PAD_GPIO1_IO03__CCM_DI0_eXT_CLK 0x0068 0x02f4 0x0000 6 0
+#define MX6UL_PAD_GPIO1_IO03__CCM_DI0_EXT_CLK 0x0068 0x02f4 0x0000 6 0
#define MX6UL_PAD_GPIO1_IO03__SRC_TESTER_ACK 0x0068 0x02f4 0x0000 7 0
-#define MX6UL_PAD_GPIO1_IO03__UART1_DTE_TX 0x0068 0x02f4 0x0000 8 0
#define MX6UL_PAD_GPIO1_IO03__UART1_DCE_RX 0x0068 0x02f4 0x0624 8 1
+#define MX6UL_PAD_GPIO1_IO03__UART1_DTE_TX 0x0068 0x02f4 0x0000 8 0
#define MX6UL_PAD_GPIO1_IO04__ENET1_REF_CLK1 0x006c 0x02f8 0x0574 0 1
#define MX6UL_PAD_GPIO1_IO04__PWM3_OUT 0x006c 0x02f8 0x0000 1 0
#define MX6UL_PAD_GPIO1_IO04__USB_OTG1_PWR 0x006c 0x02f8 0x0000 2 0
+#define MX6UL_PAD_GPIO1_IO04__REF_CLK_24M 0x006c 0x02f8 0x0000 3 0
#define MX6UL_PAD_GPIO1_IO04__USDHC1_RESET_B 0x006c 0x02f8 0x0000 4 0
#define MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0x006c 0x02f8 0x0000 5 0
#define MX6UL_PAD_GPIO1_IO04__ENET2_1588_EVENT0_IN 0x006c 0x02f8 0x0000 6 0
@@ -200,7 +204,7 @@
#define MX6UL_PAD_UART2_TX_DATA__CSI_DATA06 0x0094 0x0320 0x04dc 3 0
#define MX6UL_PAD_UART2_TX_DATA__GPT1_CAPTURE1 0x0094 0x0320 0x058c 4 1
#define MX6UL_PAD_UART2_TX_DATA__GPIO1_IO20 0x0094 0x0320 0x0000 5 0
-#define MX6UL_PAD_UART2_TX_DATA__ECSPI3_SS0 0x0094 0x0320 0x0000 8 0
+#define MX6UL_PAD_UART2_TX_DATA__ECSPI3_SS0 0x0094 0x0320 0x0560 8 0
#define MX6UL_PAD_UART2_RX_DATA__UART2_DCE_RX 0x0098 0x0324 0x062c 0 1
#define MX6UL_PAD_UART2_RX_DATA__UART2_DTE_TX 0x0098 0x0324 0x0000 0 0
#define MX6UL_PAD_UART2_RX_DATA__ENET1_TDATA03 0x0098 0x0324 0x0000 1 0
@@ -232,7 +236,7 @@
#define MX6UL_PAD_UART3_TX_DATA__UART3_DTE_RX 0x00a4 0x0330 0x0634 0 0
#define MX6UL_PAD_UART3_TX_DATA__ENET2_RDATA02 0x00a4 0x0330 0x0000 1 0
#define MX6UL_PAD_UART3_TX_DATA__SIM1_PORT0_PD 0x00a4 0x0330 0x0000 2 0
-#define MX6UL_PAD_UART3_TX_DATA__CSI_DATA01 0x00a4 0x0330 0x0000 3 0
+#define MX6UL_PAD_UART3_TX_DATA__CSI_DATA01 0x00a4 0x0330 0x04d4 3 0
#define MX6UL_PAD_UART3_TX_DATA__UART2_DCE_CTS 0x00a4 0x0330 0x0000 4 0
#define MX6UL_PAD_UART3_TX_DATA__UART2_DTE_RTS 0x00a4 0x0330 0x0628 4 2
#define MX6UL_PAD_UART3_TX_DATA__GPIO1_IO24 0x00a4 0x0330 0x0000 5 0
@@ -242,7 +246,7 @@
#define MX6UL_PAD_UART3_RX_DATA__UART3_DTE_TX 0x00a8 0x0334 0x0000 0 0
#define MX6UL_PAD_UART3_RX_DATA__ENET2_RDATA03 0x00a8 0x0334 0x0000 1 0
#define MX6UL_PAD_UART3_RX_DATA__SIM2_PORT0_PD 0x00a8 0x0334 0x0000 2 0
-#define MX6UL_PAD_UART3_RX_DATA__CSI_DATA00 0x00a8 0x0334 0x0000 3 0
+#define MX6UL_PAD_UART3_RX_DATA__CSI_DATA00 0x00a8 0x0334 0x04d0 3 0
#define MX6UL_PAD_UART3_RX_DATA__UART2_DCE_RTS 0x00a8 0x0334 0x0628 4 3
#define MX6UL_PAD_UART3_RX_DATA__UART2_DTE_CTS 0x00a8 0x0334 0x0000 4 0
#define MX6UL_PAD_UART3_RX_DATA__GPIO1_IO25 0x00a8 0x0334 0x0000 5 0
@@ -251,7 +255,7 @@
#define MX6UL_PAD_UART3_CTS_B__UART3_DTE_RTS 0x00ac 0x0338 0x0630 0 0
#define MX6UL_PAD_UART3_CTS_B__ENET2_RX_CLK 0x00ac 0x0338 0x0000 1 0
#define MX6UL_PAD_UART3_CTS_B__FLEXCAN1_TX 0x00ac 0x0338 0x0000 2 0
-#define MX6UL_PAD_UART3_CTS_B__CSI_DATA10 0x00ac 0x0338 0x0000 3 0
+#define MX6UL_PAD_UART3_CTS_B__CSI_DATA10 0x00ac 0x0338 0x04ec 3 0
#define MX6UL_PAD_UART3_CTS_B__ENET1_1588_EVENT1_IN 0x00ac 0x0338 0x0000 4 0
#define MX6UL_PAD_UART3_CTS_B__GPIO1_IO26 0x00ac 0x0338 0x0000 5 0
#define MX6UL_PAD_UART3_CTS_B__EPIT2_OUT 0x00ac 0x0338 0x0000 8 0
@@ -259,7 +263,7 @@
#define MX6UL_PAD_UART3_RTS_B__UART3_DTE_CTS 0x00b0 0x033c 0x0000 0 0
#define MX6UL_PAD_UART3_RTS_B__ENET2_TX_ER 0x00b0 0x033c 0x0000 1 0
#define MX6UL_PAD_UART3_RTS_B__FLEXCAN1_RX 0x00b0 0x033c 0x0584 2 0
-#define MX6UL_PAD_UART3_RTS_B__CSI_DATA11 0x00b0 0x033c 0x0000 3 0
+#define MX6UL_PAD_UART3_RTS_B__CSI_DATA11 0x00b0 0x033c 0x04f0 3 0
#define MX6UL_PAD_UART3_RTS_B__ENET1_1588_EVENT1_OUT 0x00b0 0x033c 0x0000 4 0
#define MX6UL_PAD_UART3_RTS_B__GPIO1_IO27 0x00b0 0x033c 0x0000 5 0
#define MX6UL_PAD_UART3_RTS_B__WDOG1_WDOG_B 0x00b0 0x033c 0x0000 8 0
@@ -267,7 +271,7 @@
#define MX6UL_PAD_UART4_TX_DATA__UART4_DTE_RX 0x00b4 0x0340 0x063c 0 0
#define MX6UL_PAD_UART4_TX_DATA__ENET2_TDATA02 0x00b4 0x0340 0x0000 1 0
#define MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x00b4 0x0340 0x05a4 2 1
-#define MX6UL_PAD_UART4_TX_DATA__CSI_DATA12 0x00b4 0x0340 0x0000 3 0
+#define MX6UL_PAD_UART4_TX_DATA__CSI_DATA12 0x00b4 0x0340 0x04f4 3 0
#define MX6UL_PAD_UART4_TX_DATA__CSU_CSU_ALARM_AUT02 0x00b4 0x0340 0x0000 4 0
#define MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x00b4 0x0340 0x0000 5 0
#define MX6UL_PAD_UART4_TX_DATA__ECSPI2_SCLK 0x00b4 0x0340 0x0544 8 1
@@ -275,23 +279,23 @@
#define MX6UL_PAD_UART4_RX_DATA__UART4_DTE_TX 0x00b8 0x0344 0x0000 0 0
#define MX6UL_PAD_UART4_RX_DATA__ENET2_TDATA03 0x00b8 0x0344 0x0000 1 0
#define MX6UL_PAD_UART4_RX_DATA__I2C1_SDA 0x00b8 0x0344 0x05a8 2 2
-#define MX6UL_PAD_UART4_RX_DATA__CSI_DATA13 0x00b8 0x0344 0x0000 3 0
+#define MX6UL_PAD_UART4_RX_DATA__CSI_DATA13 0x00b8 0x0344 0x04f8 3 0
#define MX6UL_PAD_UART4_RX_DATA__CSU_CSU_ALARM_AUT01 0x00b8 0x0344 0x0000 4 0
#define MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x00b8 0x0344 0x0000 5 0
-#define MX6UL_PAD_UART4_RX_DATA__ECSPI2_SS0 0x00b8 0x0344 0x0000 8 0
+#define MX6UL_PAD_UART4_RX_DATA__ECSPI2_SS0 0x00b8 0x0344 0x0550 8 1
#define MX6UL_PAD_UART5_TX_DATA__GPIO1_IO30 0x00bc 0x0348 0x0000 5 0
#define MX6UL_PAD_UART5_TX_DATA__ECSPI2_MOSI 0x00bc 0x0348 0x054c 8 0
#define MX6UL_PAD_UART5_TX_DATA__UART5_DCE_TX 0x00bc 0x0348 0x0000 0 0
#define MX6UL_PAD_UART5_TX_DATA__UART5_DTE_RX 0x00bc 0x0348 0x0644 0 4
#define MX6UL_PAD_UART5_TX_DATA__ENET2_CRS 0x00bc 0x0348 0x0000 1 0
#define MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x00bc 0x0348 0x05ac 2 2
-#define MX6UL_PAD_UART5_TX_DATA__CSI_DATA14 0x00bc 0x0348 0x0000 3 0
+#define MX6UL_PAD_UART5_TX_DATA__CSI_DATA14 0x00bc 0x0348 0x04fc 3 0
#define MX6UL_PAD_UART5_TX_DATA__CSU_CSU_ALARM_AUT00 0x00bc 0x0348 0x0000 4 0
#define MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX 0x00c0 0x034c 0x0644 0 5
#define MX6UL_PAD_UART5_RX_DATA__UART5_DTE_TX 0x00c0 0x034c 0x0000 0 0
#define MX6UL_PAD_UART5_RX_DATA__ENET2_COL 0x00c0 0x034c 0x0000 1 0
#define MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x00c0 0x034c 0x05b0 2 2
-#define MX6UL_PAD_UART5_RX_DATA__CSI_DATA15 0x00c0 0x034c 0x0000 3 0
+#define MX6UL_PAD_UART5_RX_DATA__CSI_DATA15 0x00c0 0x034c 0x0500 3 0
#define MX6UL_PAD_UART5_RX_DATA__CSU_CSU_INT_DEB 0x00c0 0x034c 0x0000 4 0
#define MX6UL_PAD_UART5_RX_DATA__GPIO1_IO31 0x00c0 0x034c 0x0000 5 0
#define MX6UL_PAD_UART5_RX_DATA__ECSPI2_MISO 0x00c0 0x034c 0x0548 8 1
@@ -299,59 +303,61 @@
#define MX6UL_PAD_ENET1_RX_DATA0__UART4_DCE_RTS 0x00c4 0x0350 0x0638 1 0
#define MX6UL_PAD_ENET1_RX_DATA0__UART4_DTE_CTS 0x00c4 0x0350 0x0000 1 0
#define MX6UL_PAD_ENET1_RX_DATA0__PWM1_OUT 0x00c4 0x0350 0x0000 2 0
-#define MX6UL_PAD_ENET1_RX_DATA0__CSI_DATA16 0x00c4 0x0350 0x0000 3 0
+#define MX6UL_PAD_ENET1_RX_DATA0__CSI_DATA16 0x00c4 0x0350 0x0504 3 0
#define MX6UL_PAD_ENET1_RX_DATA0__FLEXCAN1_TX 0x00c4 0x0350 0x0000 4 0
#define MX6UL_PAD_ENET1_RX_DATA0__GPIO2_IO00 0x00c4 0x0350 0x0000 5 0
-#define MX6UL_PAD_ENET1_RX_DATA0__KPP_ROW00 0x00c4 0x0350 0x0000 6 0
+#define MX6UL_PAD_ENET1_RX_DATA0__KPP_ROW00 0x00c4 0x0350 0x05d0 6 0
#define MX6UL_PAD_ENET1_RX_DATA0__USDHC1_LCTL 0x00c4 0x0350 0x0000 8 0
#define MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x00c8 0x0354 0x0000 0 0
#define MX6UL_PAD_ENET1_RX_DATA1__UART4_DCE_CTS 0x00c8 0x0354 0x0000 1 0
#define MX6UL_PAD_ENET1_RX_DATA1__UART4_DTE_RTS 0x00c8 0x0354 0x0638 1 1
#define MX6UL_PAD_ENET1_RX_DATA1__PWM2_OUT 0x00c8 0x0354 0x0000 2 0
-#define MX6UL_PAD_ENET1_RX_DATA1__CSI_DATA17 0x00c8 0x0354 0x0000 3 0
+#define MX6UL_PAD_ENET1_RX_DATA1__CSI_DATA17 0x00c8 0x0354 0x0508 3 0
#define MX6UL_PAD_ENET1_RX_DATA1__FLEXCAN1_RX 0x00c8 0x0354 0x0584 4 1
#define MX6UL_PAD_ENET1_RX_DATA1__GPIO2_IO01 0x00c8 0x0354 0x0000 5 0
-#define MX6UL_PAD_ENET1_RX_DATA1__KPP_COL00 0x00c8 0x0354 0x0000 6 0
+#define MX6UL_PAD_ENET1_RX_DATA1__KPP_COL00 0x00c8 0x0354 0x05c4 6 0
#define MX6UL_PAD_ENET1_RX_DATA1__USDHC2_LCTL 0x00c8 0x0354 0x0000 8 0
#define MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x00cc 0x0358 0x0000 0 0
#define MX6UL_PAD_ENET1_RX_EN__UART5_DCE_RTS 0x00cc 0x0358 0x0640 1 3
#define MX6UL_PAD_ENET1_RX_EN__UART5_DTE_CTS 0x00cc 0x0358 0x0000 1 0
-#define MX6UL_PAD_ENET1_RX_EN__CSI_DATA18 0x00cc 0x0358 0x0000 3 0
+#define MX6UL_PAD_ENET1_RX_EN__REF_CLK_32K 0x00cc 0x0358 0x0000 2 0
+#define MX6UL_PAD_ENET1_RX_EN__CSI_DATA18 0x00cc 0x0358 0x050c 3 0
#define MX6UL_PAD_ENET1_RX_EN__FLEXCAN2_TX 0x00cc 0x0358 0x0000 4 0
#define MX6UL_PAD_ENET1_RX_EN__GPIO2_IO02 0x00cc 0x0358 0x0000 5 0
-#define MX6UL_PAD_ENET1_RX_EN__KPP_ROW01 0x00cc 0x0358 0x0000 6 0
+#define MX6UL_PAD_ENET1_RX_EN__KPP_ROW01 0x00cc 0x0358 0x05d4 6 0
#define MX6UL_PAD_ENET1_RX_EN__USDHC1_VSELECT 0x00cc 0x0358 0x0000 8 0
#define MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x00d0 0x035c 0x0000 0 0
#define MX6UL_PAD_ENET1_TX_DATA0__UART5_DCE_CTS 0x00d0 0x035c 0x0000 1 0
#define MX6UL_PAD_ENET1_TX_DATA0__UART5_DTE_RTS 0x00d0 0x035c 0x0640 1 4
-#define MX6UL_PAD_ENET1_TX_DATA0__CSI_DATA19 0x00d0 0x035c 0x0000 3 0
+#define MX6UL_PAD_ENET1_TX_DATA0__REF_CLK_24M 0x00d0 0x035c 0x0000 2 0
+#define MX6UL_PAD_ENET1_TX_DATA0__CSI_DATA19 0x00d0 0x035c 0x0510 3 0
#define MX6UL_PAD_ENET1_TX_DATA0__FLEXCAN2_RX 0x00d0 0x035c 0x0588 4 1
#define MX6UL_PAD_ENET1_TX_DATA0__GPIO2_IO03 0x00d0 0x035c 0x0000 5 0
-#define MX6UL_PAD_ENET1_TX_DATA0__KPP_COL01 0x00d0 0x035c 0x0000 6 0
+#define MX6UL_PAD_ENET1_TX_DATA0__KPP_COL01 0x00d0 0x035c 0x05c8 6 0
#define MX6UL_PAD_ENET1_TX_DATA0__USDHC2_VSELECT 0x00d0 0x035c 0x0000 8 0
#define MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x00d4 0x0360 0x0000 0 0
#define MX6UL_PAD_ENET1_TX_DATA1__UART6_DCE_CTS 0x00d4 0x0360 0x0000 1 0
#define MX6UL_PAD_ENET1_TX_DATA1__UART6_DTE_RTS 0x00d4 0x0360 0x0648 1 2
#define MX6UL_PAD_ENET1_TX_DATA1__PWM5_OUT 0x00d4 0x0360 0x0000 2 0
-#define MX6UL_PAD_ENET1_TX_DATA1__CSI_DATA20 0x00d4 0x0360 0x0000 3 0
+#define MX6UL_PAD_ENET1_TX_DATA1__CSI_DATA20 0x00d4 0x0360 0x0514 3 0
#define MX6UL_PAD_ENET1_TX_DATA1__ENET2_MDIO 0x00d4 0x0360 0x0580 4 1
#define MX6UL_PAD_ENET1_TX_DATA1__GPIO2_IO04 0x00d4 0x0360 0x0000 5 0
-#define MX6UL_PAD_ENET1_TX_DATA1__KPP_ROW02 0x00d4 0x0360 0x0000 6 0
+#define MX6UL_PAD_ENET1_TX_DATA1__KPP_ROW02 0x00d4 0x0360 0x05d8 6 0
#define MX6UL_PAD_ENET1_TX_DATA1__WDOG1_WDOG_RST_B_DEB 0x00d4 0x0360 0x0000 8 0
#define MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x00d8 0x0364 0x0000 0 0
#define MX6UL_PAD_ENET1_TX_EN__UART6_DCE_RTS 0x00d8 0x0364 0x0648 1 3
#define MX6UL_PAD_ENET1_TX_EN__UART6_DTE_CTS 0x00d8 0x0364 0x0000 1 0
#define MX6UL_PAD_ENET1_TX_EN__PWM6_OUT 0x00d8 0x0364 0x0000 2 0
-#define MX6UL_PAD_ENET1_TX_EN__CSI_DATA21 0x00d8 0x0364 0x0000 3 0
+#define MX6UL_PAD_ENET1_TX_EN__CSI_DATA21 0x00d8 0x0364 0x0518 3 0
#define MX6UL_PAD_ENET1_TX_EN__ENET2_MDC 0x00d8 0x0364 0x0000 4 0
#define MX6UL_PAD_ENET1_TX_EN__GPIO2_IO05 0x00d8 0x0364 0x0000 5 0
-#define MX6UL_PAD_ENET1_TX_EN__KPP_COL02 0x00d8 0x0364 0x0000 6 0
+#define MX6UL_PAD_ENET1_TX_EN__KPP_COL02 0x00d8 0x0364 0x05cc 6 0
#define MX6UL_PAD_ENET1_TX_EN__WDOG2_WDOG_RST_B_DEB 0x00d8 0x0364 0x0000 8 0
#define MX6UL_PAD_ENET1_TX_CLK__ENET1_TX_CLK 0x00dc 0x0368 0x0000 0 0
#define MX6UL_PAD_ENET1_TX_CLK__UART7_DCE_CTS 0x00dc 0x0368 0x0000 1 0
#define MX6UL_PAD_ENET1_TX_CLK__UART7_DTE_RTS 0x00dc 0x0368 0x0650 1 0
#define MX6UL_PAD_ENET1_TX_CLK__PWM7_OUT 0x00dc 0x0368 0x0000 2 0
-#define MX6UL_PAD_ENET1_TX_CLK__CSI_DATA22 0x00dc 0x0368 0x0000 3 0
+#define MX6UL_PAD_ENET1_TX_CLK__CSI_DATA22 0x00dc 0x0368 0x051c 3 0
#define MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x00dc 0x0368 0x0574 4 2
#define MX6UL_PAD_ENET1_TX_CLK__GPIO2_IO06 0x00dc 0x0368 0x0000 5 0
#define MX6UL_PAD_ENET1_TX_CLK__KPP_ROW03 0x00dc 0x0368 0x0000 6 0
@@ -360,7 +366,7 @@
#define MX6UL_PAD_ENET1_RX_ER__UART7_DCE_RTS 0x00e0 0x036c 0x0650 1 1
#define MX6UL_PAD_ENET1_RX_ER__UART7_DTE_CTS 0x00e0 0x036c 0x0000 1 0
#define MX6UL_PAD_ENET1_RX_ER__PWM8_OUT 0x00e0 0x036c 0x0000 2 0
-#define MX6UL_PAD_ENET1_RX_ER__CSI_DATA23 0x00e0 0x036c 0x0000 3 0
+#define MX6UL_PAD_ENET1_RX_ER__CSI_DATA23 0x00e0 0x036c 0x0520 3 0
#define MX6UL_PAD_ENET1_RX_ER__EIM_CRE 0x00e0 0x036c 0x0000 4 0
#define MX6UL_PAD_ENET1_RX_ER__GPIO2_IO07 0x00e0 0x036c 0x0000 5 0
#define MX6UL_PAD_ENET1_RX_ER__KPP_COL03 0x00e0 0x036c 0x0000 6 0
@@ -377,7 +383,7 @@
#define MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x00e8 0x0374 0x0000 0 0
#define MX6UL_PAD_ENET2_RX_DATA1__UART6_DCE_RX 0x00e8 0x0374 0x064c 1 2
#define MX6UL_PAD_ENET2_RX_DATA1__UART6_DTE_TX 0x00e8 0x0374 0x0000 1 0
-#define MX6UL_PAD_ENET2_RX_DATA1__SIM1_PORT0_cLK 0x00e8 0x0374 0x0000 2 0
+#define MX6UL_PAD_ENET2_RX_DATA1__SIM1_PORT0_CLK 0x00e8 0x0374 0x0000 2 0
#define MX6UL_PAD_ENET2_RX_DATA1__I2C3_SDA 0x00e8 0x0374 0x05b8 3 1
#define MX6UL_PAD_ENET2_RX_DATA1__ENET1_MDC 0x00e8 0x0374 0x0000 4 0
#define MX6UL_PAD_ENET2_RX_DATA1__GPIO2_IO09 0x00e8 0x0374 0x0000 5 0
@@ -400,6 +406,7 @@
#define MX6UL_PAD_ENET2_TX_DATA0__EIM_EB_B02 0x00f0 0x037c 0x0000 4 0
#define MX6UL_PAD_ENET2_TX_DATA0__GPIO2_IO11 0x00f0 0x037c 0x0000 5 0
#define MX6UL_PAD_ENET2_TX_DATA0__KPP_COL05 0x00f0 0x037c 0x0000 6 0
+#define MX6UL_PAD_ENET2_TX_DATA0__REF_CLK_24M 0x00f0 0x037c 0x0000 8 0
#define MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x00f4 0x0380 0x0000 0 0
#define MX6UL_PAD_ENET2_TX_DATA1__UART8_DCE_TX 0x00f4 0x0380 0x0000 1 0
#define MX6UL_PAD_ENET2_TX_DATA1__UART8_DTE_RX 0x00f4 0x0380 0x065c 1 0
@@ -412,7 +419,7 @@
#define MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x00f8 0x0384 0x0000 0 0
#define MX6UL_PAD_ENET2_TX_EN__UART8_DCE_RX 0x00f8 0x0384 0x065c 1 1
#define MX6UL_PAD_ENET2_TX_EN__UART8_DTE_TX 0x00f8 0x0384 0x0000 1 0
-#define MX6UL_PAD_ENET2_TX_EN__SIM2_PORT0_cLK 0x00f8 0x0384 0x0000 2 0
+#define MX6UL_PAD_ENET2_TX_EN__SIM2_PORT0_CLK 0x00f8 0x0384 0x0000 2 0
#define MX6UL_PAD_ENET2_TX_EN__ECSPI4_MOSI 0x00f8 0x0384 0x056c 3 0
#define MX6UL_PAD_ENET2_TX_EN__EIM_ACLK_FREERUN 0x00f8 0x0384 0x0000 4 0
#define MX6UL_PAD_ENET2_TX_EN__GPIO2_IO13 0x00f8 0x0384 0x0000 5 0
@@ -431,7 +438,7 @@
#define MX6UL_PAD_ENET2_RX_ER__UART8_DCE_RTS 0x0100 0x038c 0x0658 1 1
#define MX6UL_PAD_ENET2_RX_ER__UART8_DTE_CTS 0x0100 0x038c 0x0000 1 0
#define MX6UL_PAD_ENET2_RX_ER__SIM2_PORT0_SVEN 0x0100 0x038c 0x0000 2 0
-#define MX6UL_PAD_ENET2_RX_ER__ECSPI4_SS0 0x0100 0x038c 0x0000 3 0
+#define MX6UL_PAD_ENET2_RX_ER__ECSPI4_SS0 0x0100 0x038c 0x0570 3 0
#define MX6UL_PAD_ENET2_RX_ER__EIM_ADDR25 0x0100 0x038c 0x0000 4 0
#define MX6UL_PAD_ENET2_RX_ER__GPIO2_IO15 0x0100 0x038c 0x0000 5 0
#define MX6UL_PAD_ENET2_RX_ER__KPP_COL07 0x0100 0x038c 0x0000 6 0
@@ -440,7 +447,7 @@
#define MX6UL_PAD_LCD_CLK__LCDIF_WR_RWN 0x0104 0x0390 0x0000 1 0
#define MX6UL_PAD_LCD_CLK__UART4_DCE_TX 0x0104 0x0390 0x0000 2 0
#define MX6UL_PAD_LCD_CLK__UART4_DTE_RX 0x0104 0x0390 0x063c 2 2
-#define MX6UL_PAD_LCD_CLK__SAI3_MCLK 0x0104 0x0390 0x0000 3 0
+#define MX6UL_PAD_LCD_CLK__SAI3_MCLK 0x0104 0x0390 0x0600 3 0
#define MX6UL_PAD_LCD_CLK__EIM_CS2_B 0x0104 0x0390 0x0000 4 0
#define MX6UL_PAD_LCD_CLK__GPIO3_IO00 0x0104 0x0390 0x0000 5 0
#define MX6UL_PAD_LCD_CLK__WDOG1_WDOG_RST_B_DEB 0x0104 0x0390 0x0000 8 0
@@ -464,7 +471,7 @@
#define MX6UL_PAD_LCD_VSYNC__LCDIF_BUSY 0x0110 0x039c 0x05dc 1 1
#define MX6UL_PAD_LCD_VSYNC__UART4_DCE_RTS 0x0110 0x039c 0x0638 2 3
#define MX6UL_PAD_LCD_VSYNC__UART4_DTE_CTS 0x0110 0x039c 0x0000 2 0
-#define MX6UL_PAD_LCD_VSYNC__SAI3_RX_DATA 0x0110 0x039c 0x0000 3 0
+#define MX6UL_PAD_LCD_VSYNC__SAI3_RX_DATA 0x0110 0x039c 0x0604 3 0
#define MX6UL_PAD_LCD_VSYNC__WDOG2_WDOG_B 0x0110 0x039c 0x0000 4 0
#define MX6UL_PAD_LCD_VSYNC__GPIO3_IO03 0x0110 0x039c 0x0000 5 0
#define MX6UL_PAD_LCD_VSYNC__ECSPI2_SS2 0x0110 0x039c 0x0000 8 0
@@ -477,13 +484,15 @@
#define MX6UL_PAD_LCD_RESET__ECSPI2_SS3 0x0114 0x03a0 0x0000 8 0
#define MX6UL_PAD_LCD_DATA00__LCDIF_DATA00 0x0118 0x03a4 0x0000 0 0
#define MX6UL_PAD_LCD_DATA00__PWM1_OUT 0x0118 0x03a4 0x0000 1 0
+#define MX6UL_PAD_LCD_DATA00__CA7_MX6UL_TRACE0 0x0118 0x03a4 0x0000 2 0
#define MX6UL_PAD_LCD_DATA00__ENET1_1588_EVENT2_IN 0x0118 0x03a4 0x0000 3 0
#define MX6UL_PAD_LCD_DATA00__I2C3_SDA 0x0118 0x03a4 0x05b8 4 2
#define MX6UL_PAD_LCD_DATA00__GPIO3_IO05 0x0118 0x03a4 0x0000 5 0
#define MX6UL_PAD_LCD_DATA00__SRC_BT_CFG00 0x0118 0x03a4 0x0000 6 0
-#define MX6UL_PAD_LCD_DATA00__SAI1_MCLK 0x0118 0x03a4 0x0000 8 0
+#define MX6UL_PAD_LCD_DATA00__SAI1_MCLK 0x0118 0x03a4 0x05e0 8 1
#define MX6UL_PAD_LCD_DATA01__LCDIF_DATA01 0x011c 0x03a8 0x0000 0 0
#define MX6UL_PAD_LCD_DATA01__PWM2_OUT 0x011c 0x03a8 0x0000 1 0
+#define MX6UL_PAD_LCD_DATA01__CA7_MX6UL_TRACE1 0x011c 0x03a8 0x0000 2 0
#define MX6UL_PAD_LCD_DATA01__ENET1_1588_EVENT2_OUT 0x011c 0x03a8 0x0000 3 0
#define MX6UL_PAD_LCD_DATA01__I2C3_SCL 0x011c 0x03a8 0x05b4 4 2
#define MX6UL_PAD_LCD_DATA01__GPIO3_IO06 0x011c 0x03a8 0x0000 5 0
@@ -491,6 +500,7 @@
#define MX6UL_PAD_LCD_DATA01__SAI1_TX_SYNC 0x011c 0x03a8 0x05ec 8 0
#define MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x0120 0x03ac 0x0000 0 0
#define MX6UL_PAD_LCD_DATA02__PWM3_OUT 0x0120 0x03ac 0x0000 1 0
+#define MX6UL_PAD_LCD_DATA02__CA7_MX6UL_TRACE2 0x0120 0x03ac 0x0000 2 0
#define MX6UL_PAD_LCD_DATA02__ENET1_1588_EVENT3_IN 0x0120 0x03ac 0x0000 3 0
#define MX6UL_PAD_LCD_DATA02__I2C4_SDA 0x0120 0x03ac 0x05c0 4 2
#define MX6UL_PAD_LCD_DATA02__GPIO3_IO07 0x0120 0x03ac 0x0000 5 0
@@ -498,14 +508,16 @@
#define MX6UL_PAD_LCD_DATA02__SAI1_TX_BCLK 0x0120 0x03ac 0x05e8 8 0
#define MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x0124 0x03b0 0x0000 0 0
#define MX6UL_PAD_LCD_DATA03__PWM4_OUT 0x0124 0x03b0 0x0000 1 0
+#define MX6UL_PAD_LCD_DATA03__CA7_MX6UL_TRACE3 0x0124 0x03b0 0x0000 2 0
#define MX6UL_PAD_LCD_DATA03__ENET1_1588_EVENT3_OUT 0x0124 0x03b0 0x0000 3 0
#define MX6UL_PAD_LCD_DATA03__I2C4_SCL 0x0124 0x03b0 0x05bc 4 2
#define MX6UL_PAD_LCD_DATA03__GPIO3_IO08 0x0124 0x03b0 0x0000 5 0
#define MX6UL_PAD_LCD_DATA03__SRC_BT_CFG03 0x0124 0x03b0 0x0000 6 0
-#define MX6UL_PAD_LCD_DATA03__SAI1_RX_DATA 0x0124 0x03b0 0x0000 8 0
+#define MX6UL_PAD_LCD_DATA03__SAI1_RX_DATA 0x0124 0x03b0 0x05e4 8 0
#define MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x0128 0x03b4 0x0000 0 0
#define MX6UL_PAD_LCD_DATA04__UART8_DCE_CTS 0x0128 0x03b4 0x0000 1 0
#define MX6UL_PAD_LCD_DATA04__UART8_DTE_RTS 0x0128 0x03b4 0x0658 1 2
+#define MX6UL_PAD_LCD_DATA04__CA7_MX6UL_TRACE4 0x0128 0x03b4 0x0000 2 0
#define MX6UL_PAD_LCD_DATA04__ENET2_1588_EVENT2_IN 0x0128 0x03b4 0x0000 3 0
#define MX6UL_PAD_LCD_DATA04__SPDIF_SR_CLK 0x0128 0x03b4 0x0000 4 0
#define MX6UL_PAD_LCD_DATA04__GPIO3_IO09 0x0128 0x03b4 0x0000 5 0
@@ -514,6 +526,7 @@
#define MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x012c 0x03b8 0x0000 0 0
#define MX6UL_PAD_LCD_DATA05__UART8_DCE_RTS 0x012c 0x03b8 0x0658 1 3
#define MX6UL_PAD_LCD_DATA05__UART8_DTE_CTS 0x012c 0x03b8 0x0000 1 0
+#define MX6UL_PAD_LCD_DATA05__CA7_MX6UL_TRACE5 0x012c 0x03b8 0x0000 2 0
#define MX6UL_PAD_LCD_DATA05__ENET2_1588_EVENT2_OUT 0x012c 0x03b8 0x0000 3 0
#define MX6UL_PAD_LCD_DATA05__SPDIF_OUT 0x012c 0x03b8 0x0000 4 0
#define MX6UL_PAD_LCD_DATA05__GPIO3_IO10 0x012c 0x03b8 0x0000 5 0
@@ -522,6 +535,7 @@
#define MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x0130 0x03bc 0x0000 0 0
#define MX6UL_PAD_LCD_DATA06__UART7_DCE_CTS 0x0130 0x03bc 0x0000 1 0
#define MX6UL_PAD_LCD_DATA06__UART7_DTE_RTS 0x0130 0x03bc 0x0650 1 2
+#define MX6UL_PAD_LCD_DATA06__CA7_MX6UL_TRACE6 0x0130 0x03bc 0x0000 2 0
#define MX6UL_PAD_LCD_DATA06__ENET2_1588_EVENT3_IN 0x0130 0x03bc 0x0000 3 0
#define MX6UL_PAD_LCD_DATA06__SPDIF_LOCK 0x0130 0x03bc 0x0000 4 0
#define MX6UL_PAD_LCD_DATA06__GPIO3_IO11 0x0130 0x03bc 0x0000 5 0
@@ -530,6 +544,7 @@
#define MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x0134 0x03c0 0x0000 0 0
#define MX6UL_PAD_LCD_DATA07__UART7_DCE_RTS 0x0134 0x03c0 0x0650 1 3
#define MX6UL_PAD_LCD_DATA07__UART7_DTE_CTS 0x0134 0x03c0 0x0000 1 0
+#define MX6UL_PAD_LCD_DATA07__CA7_MX6UL_TRACE7 0x0134 0x03c0 0x0000 2 0
#define MX6UL_PAD_LCD_DATA07__ENET2_1588_EVENT3_OUT 0x0134 0x03c0 0x0000 3 0
#define MX6UL_PAD_LCD_DATA07__SPDIF_EXT_CLK 0x0134 0x03c0 0x061c 4 0
#define MX6UL_PAD_LCD_DATA07__GPIO3_IO12 0x0134 0x03c0 0x0000 5 0
@@ -537,56 +552,64 @@
#define MX6UL_PAD_LCD_DATA07__ECSPI1_SS3 0x0134 0x03c0 0x0000 8 0
#define MX6UL_PAD_LCD_DATA08__LCDIF_DATA08 0x0138 0x03c4 0x0000 0 0
#define MX6UL_PAD_LCD_DATA08__SPDIF_IN 0x0138 0x03c4 0x0618 1 2
-#define MX6UL_PAD_LCD_DATA08__CSI_DATA16 0x0138 0x03c4 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA08__CA7_MX6UL_TRACE8 0x0138 0x03c4 0x0000 2 0
+#define MX6UL_PAD_LCD_DATA08__CSI_DATA16 0x0138 0x03c4 0x0504 3 1
#define MX6UL_PAD_LCD_DATA08__EIM_DATA00 0x0138 0x03c4 0x0000 4 0
#define MX6UL_PAD_LCD_DATA08__GPIO3_IO13 0x0138 0x03c4 0x0000 5 0
#define MX6UL_PAD_LCD_DATA08__SRC_BT_CFG08 0x0138 0x03c4 0x0000 6 0
#define MX6UL_PAD_LCD_DATA08__FLEXCAN1_TX 0x0138 0x03c4 0x0000 8 0
#define MX6UL_PAD_LCD_DATA09__LCDIF_DATA09 0x013c 0x03c8 0x0000 0 0
-#define MX6UL_PAD_LCD_DATA09__SAI3_MCLK 0x013c 0x03c8 0x0000 1 0
-#define MX6UL_PAD_LCD_DATA09__CSI_DATA17 0x013c 0x03c8 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA09__SAI3_MCLK 0x013c 0x03c8 0x0600 1 1
+#define MX6UL_PAD_LCD_DATA09__CA7_MX6UL_TRACE9 0x013c 0x03c8 0x0000 2 0
+#define MX6UL_PAD_LCD_DATA09__CSI_DATA17 0x013c 0x03c8 0x0508 3 1
#define MX6UL_PAD_LCD_DATA09__EIM_DATA01 0x013c 0x03c8 0x0000 4 0
#define MX6UL_PAD_LCD_DATA09__GPIO3_IO14 0x013c 0x03c8 0x0000 5 0
#define MX6UL_PAD_LCD_DATA09__SRC_BT_CFG09 0x013c 0x03c8 0x0000 6 0
#define MX6UL_PAD_LCD_DATA09__FLEXCAN1_RX 0x013c 0x03c8 0x0584 8 2
#define MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x0140 0x03cc 0x0000 0 0
#define MX6UL_PAD_LCD_DATA10__SAI3_RX_SYNC 0x0140 0x03cc 0x0000 1 0
-#define MX6UL_PAD_LCD_DATA10__CSI_DATA18 0x0140 0x03cc 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA10__CA7_MX6UL_TRACE10 0x0140 0x03cc 0x0000 2 0
+#define MX6UL_PAD_LCD_DATA10__CSI_DATA18 0x0140 0x03cc 0x050c 3 1
#define MX6UL_PAD_LCD_DATA10__EIM_DATA02 0x0140 0x03cc 0x0000 4 0
#define MX6UL_PAD_LCD_DATA10__GPIO3_IO15 0x0140 0x03cc 0x0000 5 0
#define MX6UL_PAD_LCD_DATA10__SRC_BT_CFG10 0x0140 0x03cc 0x0000 6 0
#define MX6UL_PAD_LCD_DATA10__FLEXCAN2_TX 0x0140 0x03cc 0x0000 8 0
#define MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x0144 0x03d0 0x0000 0 0
#define MX6UL_PAD_LCD_DATA11__SAI3_RX_BCLK 0x0144 0x03d0 0x0000 1 0
-#define MX6UL_PAD_LCD_DATA11__CSI_DATA19 0x0144 0x03d0 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA11__CA7_MX6UL_TRACE11 0x0144 0x03d0 0x0000 2 0
+#define MX6UL_PAD_LCD_DATA11__CSI_DATA19 0x0144 0x03d0 0x0510 3 1
#define MX6UL_PAD_LCD_DATA11__EIM_DATA03 0x0144 0x03d0 0x0000 4 0
#define MX6UL_PAD_LCD_DATA11__GPIO3_IO16 0x0144 0x03d0 0x0000 5 0
#define MX6UL_PAD_LCD_DATA11__SRC_BT_CFG11 0x0144 0x03d0 0x0000 6 0
#define MX6UL_PAD_LCD_DATA11__FLEXCAN2_RX 0x0144 0x03d0 0x0588 8 2
#define MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x0148 0x03d4 0x0000 0 0
#define MX6UL_PAD_LCD_DATA12__SAI3_TX_SYNC 0x0148 0x03d4 0x060c 1 1
-#define MX6UL_PAD_LCD_DATA12__CSI_DATA20 0x0148 0x03d4 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA12__CA7_MX6UL_TRACE12 0x0148 0x03d4 0x0000 2 0
+#define MX6UL_PAD_LCD_DATA12__CSI_DATA20 0x0148 0x03d4 0x0514 3 1
#define MX6UL_PAD_LCD_DATA12__EIM_DATA04 0x0148 0x03d4 0x0000 4 0
#define MX6UL_PAD_LCD_DATA12__GPIO3_IO17 0x0148 0x03d4 0x0000 5 0
#define MX6UL_PAD_LCD_DATA12__SRC_BT_CFG12 0x0148 0x03d4 0x0000 6 0
#define MX6UL_PAD_LCD_DATA12__ECSPI1_RDY 0x0148 0x03d4 0x0000 8 0
#define MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x014c 0x03d8 0x0000 0 0
#define MX6UL_PAD_LCD_DATA13__SAI3_TX_BCLK 0x014c 0x03d8 0x0608 1 1
-#define MX6UL_PAD_LCD_DATA13__CSI_DATA21 0x014c 0x03d8 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA13__CA7_MX6UL_TRACE13 0x014c 0x03d8 0x0000 2 0
+#define MX6UL_PAD_LCD_DATA13__CSI_DATA21 0x014c 0x03d8 0x0518 3 1
#define MX6UL_PAD_LCD_DATA13__EIM_DATA05 0x014c 0x03d8 0x0000 4 0
#define MX6UL_PAD_LCD_DATA13__GPIO3_IO18 0x014c 0x03d8 0x0000 5 0
#define MX6UL_PAD_LCD_DATA13__SRC_BT_CFG13 0x014c 0x03d8 0x0000 6 0
#define MX6UL_PAD_LCD_DATA13__USDHC2_RESET_B 0x014c 0x03d8 0x0000 8 0
#define MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x0150 0x03dc 0x0000 0 0
-#define MX6UL_PAD_LCD_DATA14__SAI3_RX_DATA 0x0150 0x03dc 0x0000 1 0
-#define MX6UL_PAD_LCD_DATA14__CSI_DATA22 0x0150 0x03dc 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA14__SAI3_RX_DATA 0x0150 0x03dc 0x0604 1 1
+#define MX6UL_PAD_LCD_DATA14__CA7_MX6UL_TRACE14 0x0150 0x03dc 0x0000 2 0
+#define MX6UL_PAD_LCD_DATA14__CSI_DATA22 0x0150 0x03dc 0x051c 3 1
#define MX6UL_PAD_LCD_DATA14__EIM_DATA06 0x0150 0x03dc 0x0000 4 0
#define MX6UL_PAD_LCD_DATA14__GPIO3_IO19 0x0150 0x03dc 0x0000 5 0
#define MX6UL_PAD_LCD_DATA14__SRC_BT_CFG14 0x0150 0x03dc 0x0000 6 0
#define MX6UL_PAD_LCD_DATA14__USDHC2_DATA4 0x0150 0x03dc 0x068c 8 0
#define MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x0154 0x03e0 0x0000 0 0
#define MX6UL_PAD_LCD_DATA15__SAI3_TX_DATA 0x0154 0x03e0 0x0000 1 0
-#define MX6UL_PAD_LCD_DATA15__CSI_DATA23 0x0154 0x03e0 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA15__CA7_MX6UL_TRACE15 0x0154 0x03e0 0x0000 2 0
+#define MX6UL_PAD_LCD_DATA15__CSI_DATA23 0x0154 0x03e0 0x0520 3 1
#define MX6UL_PAD_LCD_DATA15__EIM_DATA07 0x0154 0x03e0 0x0000 4 0
#define MX6UL_PAD_LCD_DATA15__GPIO3_IO20 0x0154 0x03e0 0x0000 5 0
#define MX6UL_PAD_LCD_DATA15__SRC_BT_CFG15 0x0154 0x03e0 0x0000 6 0
@@ -594,7 +617,8 @@
#define MX6UL_PAD_LCD_DATA16__LCDIF_DATA16 0x0158 0x03e4 0x0000 0 0
#define MX6UL_PAD_LCD_DATA16__UART7_DCE_TX 0x0158 0x03e4 0x0000 1 0
#define MX6UL_PAD_LCD_DATA16__UART7_DTE_RX 0x0158 0x03e4 0x0654 1 2
-#define MX6UL_PAD_LCD_DATA16__CSI_DATA01 0x0158 0x03e4 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA16__CA7_MX6UL_TRACE_CLK 0x0158 0x03e4 0x0000 2 0
+#define MX6UL_PAD_LCD_DATA16__CSI_DATA01 0x0158 0x03e4 0x04d4 3 1
#define MX6UL_PAD_LCD_DATA16__EIM_DATA08 0x0158 0x03e4 0x0000 4 0
#define MX6UL_PAD_LCD_DATA16__GPIO3_IO21 0x0158 0x03e4 0x0000 5 0
#define MX6UL_PAD_LCD_DATA16__SRC_BT_CFG24 0x0158 0x03e4 0x0000 6 0
@@ -602,7 +626,8 @@
#define MX6UL_PAD_LCD_DATA17__LCDIF_DATA17 0x015c 0x03e8 0x0000 0 0
#define MX6UL_PAD_LCD_DATA17__UART7_DCE_RX 0x015c 0x03e8 0x0654 1 3
#define MX6UL_PAD_LCD_DATA17__UART7_DTE_TX 0x015c 0x03e8 0x0000 1 0
-#define MX6UL_PAD_LCD_DATA17__CSI_DATA00 0x015c 0x03e8 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA17__CA7_MX6UL_TRACE_CTL 0x015c 0x03e8 0x0000 2 0
+#define MX6UL_PAD_LCD_DATA17__CSI_DATA00 0x015c 0x03e8 0x04d0 3 1
#define MX6UL_PAD_LCD_DATA17__EIM_DATA09 0x015c 0x03e8 0x0000 4 0
#define MX6UL_PAD_LCD_DATA17__GPIO3_IO22 0x015c 0x03e8 0x0000 5 0
#define MX6UL_PAD_LCD_DATA17__SRC_BT_CFG25 0x015c 0x03e8 0x0000 6 0
@@ -610,7 +635,7 @@
#define MX6UL_PAD_LCD_DATA18__LCDIF_DATA18 0x0160 0x03ec 0x0000 0 0
#define MX6UL_PAD_LCD_DATA18__PWM5_OUT 0x0160 0x03ec 0x0000 1 0
#define MX6UL_PAD_LCD_DATA18__CA7_MX6UL_EVENTO 0x0160 0x03ec 0x0000 2 0
-#define MX6UL_PAD_LCD_DATA18__CSI_DATA10 0x0160 0x03ec 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA18__CSI_DATA10 0x0160 0x03ec 0x04ec 3 1
#define MX6UL_PAD_LCD_DATA18__EIM_DATA10 0x0160 0x03ec 0x0000 4 0
#define MX6UL_PAD_LCD_DATA18__GPIO3_IO23 0x0160 0x03ec 0x0000 5 0
#define MX6UL_PAD_LCD_DATA18__SRC_BT_CFG26 0x0160 0x03ec 0x0000 6 0
@@ -622,7 +647,7 @@
#define MX6UL_PAD_LCD_DATA19__LCDIF_DATA19 0x0164 0x03f0 0x0000 0 0
#define MX6UL_PAD_LCD_DATA19__PWM6_OUT 0x0164 0x03f0 0x0000 1 0
#define MX6UL_PAD_LCD_DATA19__WDOG1_WDOG_ANY 0x0164 0x03f0 0x0000 2 0
-#define MX6UL_PAD_LCD_DATA19__CSI_DATA11 0x0164 0x03f0 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA19__CSI_DATA11 0x0164 0x03f0 0x04f0 3 1
#define MX6UL_PAD_LCD_DATA20__EIM_DATA12 0x0168 0x03f4 0x0000 4 0
#define MX6UL_PAD_LCD_DATA20__GPIO3_IO25 0x0168 0x03f4 0x0000 5 0
#define MX6UL_PAD_LCD_DATA20__SRC_BT_CFG28 0x0168 0x03f4 0x0000 6 0
@@ -631,12 +656,12 @@
#define MX6UL_PAD_LCD_DATA20__UART8_DCE_TX 0x0168 0x03f4 0x0000 1 0
#define MX6UL_PAD_LCD_DATA20__UART8_DTE_RX 0x0168 0x03f4 0x065c 1 2
#define MX6UL_PAD_LCD_DATA20__ECSPI1_SCLK 0x0168 0x03f4 0x0534 2 0
-#define MX6UL_PAD_LCD_DATA20__CSI_DATA12 0x0168 0x03f4 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA20__CSI_DATA12 0x0168 0x03f4 0x04f4 3 1
#define MX6UL_PAD_LCD_DATA21__LCDIF_DATA21 0x016c 0x03f8 0x0000 0 0
#define MX6UL_PAD_LCD_DATA21__UART8_DCE_RX 0x016c 0x03f8 0x065c 1 3
#define MX6UL_PAD_LCD_DATA21__UART8_DTE_TX 0x016c 0x03f8 0x0000 1 0
-#define MX6UL_PAD_LCD_DATA21__ECSPI1_SS0 0x016c 0x03f8 0x0000 2 0
-#define MX6UL_PAD_LCD_DATA21__CSI_DATA13 0x016c 0x03f8 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA21__ECSPI1_SS0 0x016c 0x03f8 0x0540 2 0
+#define MX6UL_PAD_LCD_DATA21__CSI_DATA13 0x016c 0x03f8 0x04f8 3 1
#define MX6UL_PAD_LCD_DATA21__EIM_DATA13 0x016c 0x03f8 0x0000 4 0
#define MX6UL_PAD_LCD_DATA21__GPIO3_IO26 0x016c 0x03f8 0x0000 5 0
#define MX6UL_PAD_LCD_DATA21__SRC_BT_CFG29 0x016c 0x03f8 0x0000 6 0
@@ -644,7 +669,7 @@
#define MX6UL_PAD_LCD_DATA22__LCDIF_DATA22 0x0170 0x03fc 0x0000 0 0
#define MX6UL_PAD_LCD_DATA22__MQS_RIGHT 0x0170 0x03fc 0x0000 1 0
#define MX6UL_PAD_LCD_DATA22__ECSPI1_MOSI 0x0170 0x03fc 0x053c 2 0
-#define MX6UL_PAD_LCD_DATA22__CSI_DATA14 0x0170 0x03fc 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA22__CSI_DATA14 0x0170 0x03fc 0x04fc 3 1
#define MX6UL_PAD_LCD_DATA22__EIM_DATA14 0x0170 0x03fc 0x0000 4 0
#define MX6UL_PAD_LCD_DATA22__GPIO3_IO27 0x0170 0x03fc 0x0000 5 0
#define MX6UL_PAD_LCD_DATA22__SRC_BT_CFG30 0x0170 0x03fc 0x0000 6 0
@@ -652,7 +677,7 @@
#define MX6UL_PAD_LCD_DATA23__LCDIF_DATA23 0x0174 0x0400 0x0000 0 0
#define MX6UL_PAD_LCD_DATA23__MQS_LEFT 0x0174 0x0400 0x0000 1 0
#define MX6UL_PAD_LCD_DATA23__ECSPI1_MISO 0x0174 0x0400 0x0538 2 0
-#define MX6UL_PAD_LCD_DATA23__CSI_DATA15 0x0174 0x0400 0x0000 3 0
+#define MX6UL_PAD_LCD_DATA23__CSI_DATA15 0x0174 0x0400 0x0500 3 1
#define MX6UL_PAD_LCD_DATA23__EIM_DATA15 0x0174 0x0400 0x0000 4 0
#define MX6UL_PAD_LCD_DATA23__GPIO3_IO28 0x0174 0x0400 0x0000 5 0
#define MX6UL_PAD_LCD_DATA23__SRC_BT_CFG31 0x0174 0x0400 0x0000 6 0
@@ -660,42 +685,42 @@
#define MX6UL_PAD_NAND_RE_B__RAWNAND_RE_B 0x0178 0x0404 0x0000 0 0
#define MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x0178 0x0404 0x0670 1 2
#define MX6UL_PAD_NAND_RE_B__QSPI_B_SCLK 0x0178 0x0404 0x0000 2 0
-#define MX6UL_PAD_NAND_RE_B__KPP_ROW00 0x0178 0x0404 0x0000 3 0
+#define MX6UL_PAD_NAND_RE_B__KPP_ROW00 0x0178 0x0404 0x05d0 3 1
#define MX6UL_PAD_NAND_RE_B__EIM_EB_B00 0x0178 0x0404 0x0000 4 0
#define MX6UL_PAD_NAND_RE_B__GPIO4_IO00 0x0178 0x0404 0x0000 5 0
#define MX6UL_PAD_NAND_RE_B__ECSPI3_SS2 0x0178 0x0404 0x0000 8 0
#define MX6UL_PAD_NAND_WE_B__RAWNAND_WE_B 0x017c 0x0408 0x0000 0 0
#define MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x017c 0x0408 0x0678 1 2
#define MX6UL_PAD_NAND_WE_B__QSPI_B_SS0_B 0x017c 0x0408 0x0000 2 0
-#define MX6UL_PAD_NAND_WE_B__KPP_COL00 0x017c 0x0408 0x0000 3 0
+#define MX6UL_PAD_NAND_WE_B__KPP_COL00 0x017c 0x0408 0x05c4 3 1
#define MX6UL_PAD_NAND_WE_B__EIM_EB_B01 0x017c 0x0408 0x0000 4 0
#define MX6UL_PAD_NAND_WE_B__GPIO4_IO01 0x017c 0x0408 0x0000 5 0
#define MX6UL_PAD_NAND_WE_B__ECSPI3_SS3 0x017c 0x0408 0x0000 8 0
#define MX6UL_PAD_NAND_DATA00__RAWNAND_DATA00 0x0180 0x040c 0x0000 0 0
#define MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x0180 0x040c 0x067c 1 2
#define MX6UL_PAD_NAND_DATA00__QSPI_B_SS1_B 0x0180 0x040c 0x0000 2 0
-#define MX6UL_PAD_NAND_DATA00__KPP_ROW01 0x0180 0x040c 0x0000 3 0
+#define MX6UL_PAD_NAND_DATA00__KPP_ROW01 0x0180 0x040c 0x05d4 3 1
#define MX6UL_PAD_NAND_DATA00__EIM_AD08 0x0180 0x040c 0x0000 4 0
#define MX6UL_PAD_NAND_DATA00__GPIO4_IO02 0x0180 0x040c 0x0000 5 0
#define MX6UL_PAD_NAND_DATA00__ECSPI4_RDY 0x0180 0x040c 0x0000 8 0
#define MX6UL_PAD_NAND_DATA01__RAWNAND_DATA01 0x0184 0x0410 0x0000 0 0
#define MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x0184 0x0410 0x0680 1 2
#define MX6UL_PAD_NAND_DATA01__QSPI_B_DQS 0x0184 0x0410 0x0000 2 0
-#define MX6UL_PAD_NAND_DATA01__KPP_COL01 0x0184 0x0410 0x0000 3 0
+#define MX6UL_PAD_NAND_DATA01__KPP_COL01 0x0184 0x0410 0x05c8 3 1
#define MX6UL_PAD_NAND_DATA01__EIM_AD09 0x0184 0x0410 0x0000 4 0
#define MX6UL_PAD_NAND_DATA01__GPIO4_IO03 0x0184 0x0410 0x0000 5 0
#define MX6UL_PAD_NAND_DATA01__ECSPI4_SS1 0x0184 0x0410 0x0000 8 0
#define MX6UL_PAD_NAND_DATA02__RAWNAND_DATA02 0x0188 0x0414 0x0000 0 0
#define MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x0188 0x0414 0x0684 1 1
#define MX6UL_PAD_NAND_DATA02__QSPI_B_DATA00 0x0188 0x0414 0x0000 2 0
-#define MX6UL_PAD_NAND_DATA02__KPP_ROW02 0x0188 0x0414 0x0000 3 0
+#define MX6UL_PAD_NAND_DATA02__KPP_ROW02 0x0188 0x0414 0x05d8 3 1
#define MX6UL_PAD_NAND_DATA02__EIM_AD10 0x0188 0x0414 0x0000 4 0
#define MX6UL_PAD_NAND_DATA02__GPIO4_IO04 0x0188 0x0414 0x0000 5 0
#define MX6UL_PAD_NAND_DATA02__ECSPI4_SS2 0x0188 0x0414 0x0000 8 0
#define MX6UL_PAD_NAND_DATA03__RAWNAND_DATA03 0x018c 0x0418 0x0000 0 0
#define MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x018c 0x0418 0x0688 1 2
#define MX6UL_PAD_NAND_DATA03__QSPI_B_DATA01 0x018c 0x0418 0x0000 2 0
-#define MX6UL_PAD_NAND_DATA03__KPP_COL02 0x018c 0x0418 0x0000 3 0
+#define MX6UL_PAD_NAND_DATA03__KPP_COL02 0x018c 0x0418 0x05cc 3 1
#define MX6UL_PAD_NAND_DATA03__EIM_AD11 0x018c 0x0418 0x0000 4 0
#define MX6UL_PAD_NAND_DATA03__GPIO4_IO05 0x018c 0x0418 0x0000 5 0
#define MX6UL_PAD_NAND_DATA03__ECSPI4_SS3 0x018c 0x0418 0x0000 8 0
@@ -726,7 +751,7 @@
#define MX6UL_PAD_NAND_DATA07__RAWNAND_DATA07 0x019c 0x0428 0x0000 0 0
#define MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x019c 0x0428 0x0698 1 1
#define MX6UL_PAD_NAND_DATA07__QSPI_A_SS1_B 0x019c 0x0428 0x0000 2 0
-#define MX6UL_PAD_NAND_DATA07__ECSPI4_SS0 0x019c 0x0428 0x0000 3 0
+#define MX6UL_PAD_NAND_DATA07__ECSPI4_SS0 0x019c 0x0428 0x0570 3 1
#define MX6UL_PAD_NAND_DATA07__EIM_AD15 0x019c 0x0428 0x0000 4 0
#define MX6UL_PAD_NAND_DATA07__GPIO4_IO09 0x019c 0x0428 0x0000 5 0
#define MX6UL_PAD_NAND_DATA07__UART2_DCE_RTS 0x019c 0x0428 0x0628 8 5
@@ -748,7 +773,7 @@
#define MX6UL_PAD_NAND_READY_B__RAWNAND_READY_B 0x01a8 0x0434 0x0000 0 0
#define MX6UL_PAD_NAND_READY_B__USDHC1_DATA4 0x01a8 0x0434 0x0000 1 0
#define MX6UL_PAD_NAND_READY_B__QSPI_A_DATA00 0x01a8 0x0434 0x0000 2 0
-#define MX6UL_PAD_NAND_READY_B__ECSPI3_SS0 0x01a8 0x0434 0x0000 3 0
+#define MX6UL_PAD_NAND_READY_B__ECSPI3_SS0 0x01a8 0x0434 0x0560 3 1
#define MX6UL_PAD_NAND_READY_B__EIM_CS1_B 0x01a8 0x0434 0x0000 4 0
#define MX6UL_PAD_NAND_READY_B__GPIO4_IO12 0x01a8 0x0434 0x0000 5 0
#define MX6UL_PAD_NAND_READY_B__UART3_DCE_TX 0x01a8 0x0434 0x0000 8 0
@@ -783,7 +808,7 @@
#define MX6UL_PAD_NAND_DQS__PWM5_OUT 0x01b8 0x0444 0x0000 3 0
#define MX6UL_PAD_NAND_DQS__EIM_WAIT 0x01b8 0x0444 0x0000 4 0
#define MX6UL_PAD_NAND_DQS__GPIO4_IO16 0x01b8 0x0444 0x0000 5 0
-#define MX6UL_PAD_NAND_DQS__SDMA_EXT_EVENT01 0x01b8 0x0444 0x0000 6 0
+#define MX6UL_PAD_NAND_DQS__SDMA_EXT_EVENT01 0x01b8 0x0444 0x0614 6 1
#define MX6UL_PAD_NAND_DQS__SPDIF_EXT_CLK 0x01b8 0x0444 0x061c 8 1
#define MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x01bc 0x0448 0x0000 0 0
#define MX6UL_PAD_SD1_CMD__GPT2_COMPARE1 0x01bc 0x0448 0x0000 1 0
@@ -791,11 +816,11 @@
#define MX6UL_PAD_SD1_CMD__SPDIF_OUT 0x01bc 0x0448 0x0000 3 0
#define MX6UL_PAD_SD1_CMD__EIM_ADDR19 0x01bc 0x0448 0x0000 4 0
#define MX6UL_PAD_SD1_CMD__GPIO2_IO16 0x01bc 0x0448 0x0000 5 0
-#define MX6UL_PAD_SD1_CMD__SDMA_EXT_EVENT00 0x01bc 0x0448 0x0000 6 0
+#define MX6UL_PAD_SD1_CMD__SDMA_EXT_EVENT00 0x01bc 0x0448 0x0610 6 2
#define MX6UL_PAD_SD1_CMD__USB_OTG1_PWR 0x01bc 0x0448 0x0000 8 0
#define MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x01c0 0x044c 0x0000 0 0
#define MX6UL_PAD_SD1_CLK__GPT2_COMPARE2 0x01c0 0x044c 0x0000 1 0
-#define MX6UL_PAD_SD1_CLK__SAI2_MCLK 0x01c0 0x044c 0x0000 2 0
+#define MX6UL_PAD_SD1_CLK__SAI2_MCLK 0x01c0 0x044c 0x05f0 2 1
#define MX6UL_PAD_SD1_CLK__SPDIF_IN 0x01c0 0x044c 0x0618 3 3
#define MX6UL_PAD_SD1_CLK__EIM_ADDR20 0x01c0 0x044c 0x0000 4 0
#define MX6UL_PAD_SD1_CLK__GPIO2_IO17 0x01c0 0x044c 0x0000 5 0
@@ -878,10 +903,10 @@
#define MX6UL_PAD_CSI_DATA01__CSI_DATA03 0x01e8 0x0474 0x04c8 0 0
#define MX6UL_PAD_CSI_DATA01__USDHC2_DATA1 0x01e8 0x0474 0x0680 1 0
#define MX6UL_PAD_CSI_DATA01__SIM1_PORT1_SVEN 0x01e8 0x0474 0x0000 2 0
-#define MX6UL_PAD_CSI_DATA01__ECSPI2_SS0 0x01e8 0x0474 0x0000 3 0
+#define MX6UL_PAD_CSI_DATA01__ECSPI2_SS0 0x01e8 0x0474 0x0550 3 0
#define MX6UL_PAD_CSI_DATA01__EIM_AD01 0x01e8 0x0474 0x0000 4 0
#define MX6UL_PAD_CSI_DATA01__GPIO4_IO22 0x01e8 0x0474 0x0000 5 0
-#define MX6UL_PAD_CSI_DATA01__SAI1_MCLK 0x01e8 0x0474 0x0000 6 0
+#define MX6UL_PAD_CSI_DATA01__SAI1_MCLK 0x01e8 0x0474 0x05e0 6 0
#define MX6UL_PAD_CSI_DATA01__UART5_DCE_RX 0x01e8 0x0474 0x0644 8 1
#define MX6UL_PAD_CSI_DATA01__UART5_DTE_TX 0x01e8 0x0474 0x0000 8 0
#define MX6UL_PAD_CSI_DATA02__CSI_DATA04 0x01ec 0x0478 0x04d8 0 1
@@ -913,7 +938,7 @@
#define MX6UL_PAD_CSI_DATA05__CSI_DATA07 0x01f8 0x0484 0x04e0 0 1
#define MX6UL_PAD_CSI_DATA05__USDHC2_DATA5 0x01f8 0x0484 0x0690 1 2
#define MX6UL_PAD_CSI_DATA05__SIM2_PORT1_RST_B 0x01f8 0x0484 0x0000 2 0
-#define MX6UL_PAD_CSI_DATA05__ECSPI1_SS0 0x01f8 0x0484 0x0000 3 0
+#define MX6UL_PAD_CSI_DATA05__ECSPI1_SS0 0x01f8 0x0484 0x0540 3 1
#define MX6UL_PAD_CSI_DATA05__EIM_AD05 0x01f8 0x0484 0x0000 4 0
#define MX6UL_PAD_CSI_DATA05__GPIO4_IO26 0x01f8 0x0484 0x0000 5 0
#define MX6UL_PAD_CSI_DATA05__SAI1_TX_BCLK 0x01f8 0x0484 0x05e8 6 1
@@ -924,7 +949,7 @@
#define MX6UL_PAD_CSI_DATA06__ECSPI1_MOSI 0x01fc 0x0488 0x053c 3 1
#define MX6UL_PAD_CSI_DATA06__EIM_AD06 0x01fc 0x0488 0x0000 4 0
#define MX6UL_PAD_CSI_DATA06__GPIO4_IO27 0x01fc 0x0488 0x0000 5 0
-#define MX6UL_PAD_CSI_DATA06__SAI1_RX_DATA 0x01fc 0x0488 0x0000 6 0
+#define MX6UL_PAD_CSI_DATA06__SAI1_RX_DATA 0x01fc 0x0488 0x05e4 6 1
#define MX6UL_PAD_CSI_DATA06__USDHC1_RESET_B 0x01fc 0x0488 0x0000 8 0
#define MX6UL_PAD_CSI_DATA07__CSI_DATA09 0x0200 0x048c 0x04e8 0 1
#define MX6UL_PAD_CSI_DATA07__USDHC2_DATA7 0x0200 0x048c 0x0698 1 2
--
2.15.1
^ permalink raw reply related
* [PATCH v2 3/7] ARM: dts: imx6ull: add additional pinfunc defines for i.MX 6ULL
From: Stefan Agner @ 2018-01-10 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110210453.19264-1-stefan@agner.ch>
From: Bai Ping <ping.bai@nxp.com>
On i.MX 6ULL, the pin MUX and CTRL register of BOOT_MODEx and TAMPERx
pins are available through IOMUXC_SNVS. Add additional pinfunc defines.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
---
arch/arm/boot/dts/imx6ull-pinfunc-snvs.h | 27 +++++++++++++++++++++++++++
arch/arm/boot/dts/imx6ull.dtsi | 1 +
2 files changed, 28 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc-snvs.h
diff --git a/arch/arm/boot/dts/imx6ull-pinfunc-snvs.h b/arch/arm/boot/dts/imx6ull-pinfunc-snvs.h
new file mode 100644
index 000000000000..fa900c15405d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-pinfunc-snvs.h
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright (C) 2017 NXP
+ */
+
+#ifndef __DTS_IMX6ULL_PINFUNC_SNVS_H
+#define __DTS_IMX6ULL_PINFUNC_SNVS_H
+/*
+ * The pin function ID is a tuple of
+ * <mux_reg conf_reg input_reg mux_mode input_val>
+ */
+#define MX6ULL_PAD_BOOT_MODE0__GPIO5_IO10 0x0000 0x0044 0x0000 0x5 0x0
+#define MX6ULL_PAD_BOOT_MODE1__GPIO5_IO11 0x0004 0x0048 0x0000 0x5 0x0
+#define MX6ULL_PAD_SNVS_TAMPER0__GPIO5_IO00 0x0008 0x004C 0x0000 0x5 0x0
+#define MX6ULL_PAD_SNVS_TAMPER1__GPIO5_IO01 0x000C 0x0050 0x0000 0x5 0x0
+#define MX6ULL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x0010 0x0054 0x0000 0x5 0x0
+#define MX6ULL_PAD_SNVS_TAMPER3__GPIO5_IO03 0x0014 0x0058 0x0000 0x5 0x0
+#define MX6ULL_PAD_SNVS_TAMPER4__GPIO5_IO04 0x0018 0x005C 0x0000 0x5 0x0
+#define MX6ULL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x001C 0x0060 0x0000 0x5 0x0
+#define MX6ULL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x0020 0x0064 0x0000 0x5 0x0
+#define MX6ULL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x0024 0x0068 0x0000 0x5 0x0
+#define MX6ULL_PAD_SNVS_TAMPER8__GPIO5_IO08 0x0028 0x006C 0x0000 0x5 0x0
+#define MX6ULL_PAD_SNVS_TAMPER9__GPIO5_IO09 0x002C 0x0070 0x0000 0x5 0x0
+
+#endif /* __DTS_IMX6ULL_PINFUNC_SNVS_H */
+
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
index 0c182917b863..a58c01dc15c3 100644
--- a/arch/arm/boot/dts/imx6ull.dtsi
+++ b/arch/arm/boot/dts/imx6ull.dtsi
@@ -41,3 +41,4 @@
#include "imx6ul.dtsi"
#include "imx6ull-pinfunc.h"
+#include "imx6ull-pinfunc-snvs.h"
--
2.15.1
^ permalink raw reply related
* [PATCH v2 4/7] ARM: dts: imx6ul: add interrupt of virt-capable GIC
From: Stefan Agner @ 2018-01-10 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110210453.19264-1-stefan@agner.ch>
The Cortex-A7 and its GIC support virtualization extensions. To
make use of them the CPU private interrupt needs to be specified.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Rob Herring <robh@kernel.org>
---
arch/arm/boot/dts/imx6ul.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 1b14e4d39c26..993fbdbdd506 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -100,8 +100,10 @@
intc: interrupt-controller at a01000 {
compatible = "arm,gic-400", "arm,cortex-a7-gic";
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
#interrupt-cells = <3>;
interrupt-controller;
+ interrupt-parent = <&intc>;
reg = <0x00a01000 0x1000>,
<0x00a02000 0x2000>,
<0x00a04000 0x2000>,
--
2.15.1
^ permalink raw reply related
* [PATCH v2 5/7] ARM: dts: imx6ul: add ARM architected timer
From: Stefan Agner @ 2018-01-10 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110210453.19264-1-stefan@agner.ch>
Add per-core ARM architected timer. Unfortunately bootloaders (U-Boot)
currently do not make the necessary initialization. Also specifing the
clock manually using the clock-frequency property seems not to help.
Therefor leave the timer disabled by default for now.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Rob Herring <robh@kernel.org>
---
arch/arm/boot/dts/imx6ul.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 993fbdbdd506..4d76923e8f44 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -110,6 +110,16 @@
<0x00a06000 0x2000>;
};
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ interrupt-parent = <&intc>;
+ status = "disabled";
+ };
+
ckil: clock-cli {
compatible = "fixed-clock";
#clock-cells = <0>;
--
2.15.1
^ permalink raw reply related
* [PATCH v2 6/7] ARM: dts: imx6ull: add IOMUXC SNVS instance
From: Stefan Agner @ 2018-01-10 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110210453.19264-1-stefan@agner.ch>
The i.MX 6ULL features another IOMUX Controller called IOMUXC
SNVS which allows to control BOOT_MODE and TAMPER pins. Add the
controller to the i.MX 6ULL specific imx6ull.dtsi device tree.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
---
arch/arm/boot/dts/imx6ull.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
index a58c01dc15c3..bc2cd4fb8b12 100644
--- a/arch/arm/boot/dts/imx6ull.dtsi
+++ b/arch/arm/boot/dts/imx6ull.dtsi
@@ -42,3 +42,20 @@
#include "imx6ul.dtsi"
#include "imx6ull-pinfunc.h"
#include "imx6ull-pinfunc-snvs.h"
+
+/ {
+ soc {
+ aips3: aips-bus at 2200000 {
+ compatible = "fsl,aips-bus", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x02200000 0x100000>;
+ ranges;
+
+ iomuxc_snvs: iomuxc-snvs at 2290000 {
+ compatible = "fsl,imx6ull-iomuxc-snvs";
+ reg = <0x02290000 0x4000>;
+ };
+ };
+ };
+};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 7/7] ARM: dts: imx6ull: add UART8 support
From: Stefan Agner @ 2018-01-10 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110210453.19264-1-stefan@agner.ch>
In i.MX 6ULL UART8 is part of the AIPS-3 memory map instead of
AIPS-1. Clocks and interrupts remain the same.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
---
arch/arm/boot/dts/imx6ull.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
index bc2cd4fb8b12..571ddd71cdba 100644
--- a/arch/arm/boot/dts/imx6ull.dtsi
+++ b/arch/arm/boot/dts/imx6ull.dtsi
@@ -43,6 +43,9 @@
#include "imx6ull-pinfunc.h"
#include "imx6ull-pinfunc-snvs.h"
+/* Delete UART8 in AIPS-1 (i.MX6UL specific) */
+/delete-node/ &uart8;
+
/ {
soc {
aips3: aips-bus at 2200000 {
@@ -56,6 +59,17 @@
compatible = "fsl,imx6ull-iomuxc-snvs";
reg = <0x02290000 0x4000>;
};
+
+ uart8: serial at 2288000 {
+ compatible = "fsl,imx6ul-uart",
+ "fsl,imx6q-uart";
+ reg = <0x02288000 0x4000>;
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6UL_CLK_UART8_IPG>,
+ <&clks IMX6UL_CLK_UART8_SERIAL>;
+ clock-names = "ipg", "per";
+ status = "disabled";
+ };
};
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH] arm64: dts: add #cooling-cells to CPU nodes
From: Arnd Bergmann @ 2018-01-10 21:06 UTC (permalink / raw)
To: linux-arm-kernel
dtc complains about the lack of #coolin-cells properties for the
CPU nodes that are referred to as "cooling-device":
arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu at 0 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map at 0:cooling-device[0])
arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu at 100 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map at 1:cooling-device[0])
Apparently this property must be '<2>' to match the binding.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
If this looks ok, I'd apply it directly to the fixes branch
for 4.15, as the warning is one that was introduced in this
release.
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index b477ad790071..9fbe4705ee88 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -155,6 +155,7 @@
reg = <0x000>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
+ #cooling-cells = <2>;
clocks = <&infracfg CLK_INFRA_CA53SEL>,
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
@@ -179,6 +180,7 @@
reg = <0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
+ #cooling-cells = <2>;
clocks = <&infracfg CLK_INFRA_CA57SEL>,
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
--
2.9.0
^ permalink raw reply related
* [PATCH -next] clk: meson-axg: fix potential NULL dereference in axg_clkc_probe()
From: Stephen Boyd @ 2018-01-10 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515117059-176004-1-git-send-email-weiyongjun1@huawei.com>
On 01/05, Wei Yongjun wrote:
> platform_get_resource() may return NULL, add proper
> check to avoid potential NULL dereferencing.
>
> This is detected by Coccinelle semantic patch.
>
> @@
> expression pdev, res, n, t, e, e1, e2;
> @@
>
> res = platform_get_resource(pdev, t, n);
> + if (!res)
> + return -EINVAL;
> ... when != res == NULL
> e = devm_ioremap(e1, res->start, e2);
Can this script be put into scripts/coccinelle/? I'd like to be
able to run it instead of getting emails from you after patches
merge.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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